이 페이지는 Cloud Translation API를 통해 번역되었습니다.

코드형 인프라 구성

이 페이지에서는 코드형 인프라 (IaC) 워크플로의 2일차 작업을 소개합니다.

기본 요건

IaC 설정을 완료합니다.
선택사항: 디버깅을 위해 nomos 명령줄 도구 다운로드 및 설치:
에어갭 환경 외부에 있고 이 URL에 액세스할 수 있는 경우 https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command를 방문하세요.

GitLab에 로그인

https://iac.GDC_URL에서 GitLab 웹 콘솔을 엽니다.

GDC_URL를 GDC 프로젝트의 기본 URL로 바꿉니다.
GitLab UI에서 SAML 로그인 버튼을 클릭하여 Operations Center IT (OC IT) Active Directory Federation Services (ADFS) 로그인 페이지로 리디렉션합니다.
OC IT ADFS 사용자 인증 정보로 로그인하여 GitLab 홈페이지를 확인합니다.
CLI 액세스에는 개인 액세스 토큰 (PAT)이 필요합니다. GitLab 도움말 개인 액세스 토큰 만들기의 다음 단계에 따라 필요한 액세스 수준으로 사용자의 PAT를 만듭니다. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token

PAT를 만든 후에는 CLI 도구를 사용하여 인증을 수행할 수 있습니다.

참고: 비밀번호 대신 CLI 인증에 PAT가 필요합니다.

코드형 인프라 워크플로

일반적으로 IaC 워크플로는 다음 단계로 구성됩니다.

GitLab iac 저장소에서 다음과 같이 해당 YAML 변경사항을 생성합니다.
- 파일이 없으면 사이드바에서 새 파일 아이콘을 선택합니다.
- 새 파일 만들기 팝업 창에 전체 경로와 함께 새 파일의 이름을 입력하고 파일 만들기를 선택합니다.
- 파일이 있으면 사이드바에서 파일을 선택하여 새 창에서 엽니다.
- 파일을 필요한 대로 변경합니다.
변경사항을 Git 커밋으로 업로드하고 다음과 같이 필수 코드 검토를 위해 커밋을 전송합니다.
1. 사이드바에서 커밋 옵션을 선택하여 옵션을 더 펼칩니다.
2. 텍스트 영역에 커밋 메시지를 작성합니다. 메시지에 유용한 정보를 포함하세요.
3. 새 브랜치 만들기 옵션을 선택합니다.
4. 새 병합 요청 시작 체크박스를 선택합니다.
5. Commit을 클릭하여 병합 요청 양식의 미리보기를 엽니다.
6. 병합 요청을 만들고 다음과 같이 필요한 사항을 변경합니다.
  1. 제목 필드에 병합 요청의 이름을 입력합니다.
  2. 설명 필드에 설명을 입력합니다.
  3. 병합 옵션 섹션에서 병합 소스가 수락되면 소스 브랜치 삭제 체크박스를 선택합니다.
  4. 병합 요청 만들기를 클릭합니다. 병합 요청은 검토자에게 자동으로 전송됩니다.
적절한 소유자에게 다자간 승인 프로세스로 커밋을 검토하고 승인해 달라고 요청합니다.
커밋을 푸시합니다.
해당 클러스터에서 결과를 확인합니다.

디버깅 도움말

이 섹션에서는 IaC의 선택적 디버깅 팁을 설명합니다. 구성이 정확한지 확인하려면 nomos 명령줄 도구가 설치되어 있어야 합니다.

렌더링된 구성 미리보기 및 검증

구성 동기화가 구성을 렌더링하고 이를 클러스터에 동기화하기 전 nomos hydrate를 실행해서 렌더링된 구성을 미리보고, nomos vet를 실행해서 형식이 올바른지 검증하여 구성이 올바른지 확인합니다.

로컬 Git 루트 디렉터리로 전환합니다.
다음 플래그와 함께 다음 nomos hydrate를 실행합니다.
```
nomos hydrate \
    --source-format=unstructured \
    --output=OUTPUT_DIRECTORY
```
이 명령어에서
- --source-format=unstructured는 nomos hydrate가 구조화되지 않은 저장소에서 작동하도록 합니다. Kustomize 구성 및 Helm 차트를 사용하기 때문에 구조화되지 않은 저장소를 사용하고 이 플래그를 추가해야 합니다.
- --output=OUTPUT_DIRECTORY를 사용하면 렌더링된 구성에 대한 경로를 정의할 수 있습니다. OUTPUT_DIRECTORY을 출력을 저장하려는 위치로 바꿉니다.
다음 플래그와 함께 nomos vet를 실행하여 구성의 구문 및 유효성을 확인합니다.
```
nomos vet \
    --source-format=unstructured \
    --keep-output=true \
    --output=OUTPUT_DIRECTORY
```
이 명령어에서
- --source-format=unstructured는 nomos vet가 구조화되지 않은 저장소에서 작동하도록 합니다.
- --keep-output=true는 렌더링된 구성을 저장합니다.
- --output=OUTPUT_DIRECTORY는 렌더링된 구성에 대한 경로입니다.

프로세스 확인

동기화 상태를 확인하려면 다음 단계를 따르세요.

ka 셸 별칭을 사용합니다.
```
  $ alias ka='kubectl --kubeconfig $HOME/root-admin-kubeconfig'
```
ka 별칭은 root-admin 클러스터와 통신하도록 kubectl을 구성합니다.
동기화가 작동하는지 확인합니다.
```
 $ ka get rootsync/root-sync -n config-management-system
```
구성 동기화에서 사용하는 커밋과 오류가 있는 경우 오류가 표시됩니다.

동기화 상태를 확인한 후 다음 옵션 중 하나를 사용하세요.

Git 저장소의 최신 커밋이 성공적으로 적용되었는지 확인합니다.
1. RootSync 또는 RepoSync 객체의 .status.sync 필드를 확인합니다. 다음 명령어를 사용하여 .status.sync 필드에 액세스할 수 있습니다.
```
# get .status.sync of a RootSync object
ka get rootsync ROOT_SYNC -n config-management-system -o jsonpath='{.status.sync}'

# get .status.sync of a RepoSync object
ka get reposync REPO_SYNC -n REPO_SYNC_NAMESPACE -o jsonpath='{.status.sync}'
```
  ROOT_SYNC를 조회할 RootSync 객체의 이름으로 바꿉니다.
  
  REPO_SYNC를 조회할 RepoSync 객체의 이름으로 바꿉니다.
  
  REPO_SYNC_NAMESPACE를 조회할 RepoSync 객체의 이름으로 바꿉니다.
  - .status.sync.commit 필드의 값이 최신 커밋과 같아야 합니다.
  - .status.sync 필드에는 '오류'가 없습니다.
2. 최신 커밋의 리소스가 모두 조정되었는지 확인합니다. 각 RootSync 또는 RepoSync 객체에는 Git 저장소에 선언된 관리형 리소스의 조정 상태를 캡처하는 고유한 ResourceGroup 객체가 있습니다. ResourceGroup 객체는 RootSync 또는 RepoSync 객체와 동일한 네임스페이스 및 이름을 갖습니다.
  
  예를 들어 네임스페이스 config-management- system의 이름이 root-sync인 RootSync 객체의 경우 해당 ResourceGroup 객체도 네임스페이스 config-management-system의 root-sync입니다. 최신 커밋을 성공적으로 적용하면 ResourceGroup 객체에 최신 커밋의 관리형 리소스 그룹, 종류, 네임스페이스, 이름이 포함됩니다.
  
  다음 명령어를 실행하여 ResourceGroup 객체를 가져옵니다.
```
# get the ResourceGroup object for a RootSync object
ka get resourcegroup ROOT_SYNC -n config-management-system -o yaml

# get the ResourceGroup object for a RepoSync object
ka get resourcegroup REPO_SYNC -n REPO_SYNC_NAMESPACE -o yaml
```
  ROOT_SYNC를 조회할 ResourceGroup 객체의 이름으로 바꿉니다.
  
  REPO_SYNC를 조회할 ResourceGroup 객체의 이름으로 바꿉니다.
  
  REPO_SYNC_NAMESPACE를 조회할 ResourceGroup 객체의 이름으로 바꿉니다.
  - .status.observedGeneration이 ResourceGroup 객체의 .metadata.generation 필드 값과 동일한지 확인합니다.
  - Stalled 조건 및 Reconciling 조건 모두에 status가 "False"로 있는지 확인합니다.
  - .status.resourceStatuses 필드의 각 항목 상태가 Current인지 확인합니다.

YAML 파일을 사용하여 커밋하는지 확인합니다.

선택사항: kubectl 컨텍스트를 구성하는 경우 nomos 명령어를 사용합니다.

$ nomos status
Connecting to clusters...

*root-admin-admin@root-admin
  --------------------
  <root>:root-sync   https://iac.zone1.google.gdch.test/gdch/iac.git/infrastructure/zonal/zones/ZONE_NAME/root-admin@main
  SYNCED             4a276fb67d17471f1ba812c725b75a76a1715009
  Managed resources:
     NAMESPACE   NAME             STATUS
     default     service/hello    Unknown

예시 YAML 파일을 커밋하는 경우 다음을 실행합니다.
```
$ ka get svc/hello
```
예시 YAML에서 생성된 서비스가 표시됩니다.

다음 명령어를 실행합니다.

ka describe svc/hello

다음 객체가 표시됩니다.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

서비스에 새 주석을 추가합니다.
```
$ ka annotate --overwrite svc/hello google.com/test=aaa
```
describe을 다시 실행하고 주석이 있는지 확인한 후 구성 동기화가 주석을 덮어쓰지 않았는지 확인합니다.

주석이 관리하는 IaC를 재정의합니다.

$ ka annotate --overwrite svc/hello google.com/annotation-in-iac=value-from-kubectl

다음 오류 메시지에 변경이 거부되었다고 표시됩니다.

$ ka annotate --overwrite svc/hello google.com/annotation-in-iac=asfas
Error from server (Forbidden): admission webhook "v1.admission-webhook.configsync.gke.io" denied the request: kubernetes-admin cannot modify fields of object "_service_default_hello" managed by Config Sync: .metadata.annotations.google.com/annotation-in-iac

설치 문제 해결

Kustomize가 구성을 렌더링하지 않는 등의 렌더링 오류가 표시되면 다음을 사용하세요.

$ ka logs -n config-management-system deployment/root-reconciler -c hydration-controller -f

root-reconciler의 컨테이너는 다음과 같습니다.

git-sync: 원격 Git 저장소를 클론합니다.
Hydration-controller:Kustomization 구성 파일이 루트 디렉터리에 있는 경우 Kustomize 구성 및 Helm 차트를 렌더링합니다.
reconciler: 저장소 계층 구조를 평면화하고 API 서버를 통해 조정하며 오류를 확인합니다.

자세한 내용은 공식 가이드인 구성 동기화 문제 해결 구성 관리 Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync을 참고하세요.

문제 해결

디버깅을 위해 기본 비밀번호 로그인을 사용하여 초기 ioadmin 사용자로 로그인하는 것이 유용할 수 있습니다. GitLab을 통한 비밀번호 로그인을 다시 추가하려면 다음 kubectl 명령어를 실행하세요.

  export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
  # Wait for pod to be ready.
  kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
  kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)"

로컬 사용자 사용이 끝나면 다음을 사용하여 ADFS 전용 인증을 다시 사용 설정합니다.

export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
# Wait for pod to be ready.
kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: false)"

ADFS에서 새 사용자 온보딩

사용자가 ADFS를 사용하여 Distributed Cloud에 로그인합니다. 이렇게 하면 AD 계정으로 GitLab 내에 사용자 계정이 생성됩니다.

관리자는 다음 단계에 따라 새로 만든 사용자를 GitLab 그룹에 수동으로 추가합니다.

GitLab 관리자 또는 GitLab의 Distributed Cloud 그룹 관리자로 GitLab에 로그인합니다.
GitLab 또는 https://iac.GDC_URL/gdch에서 Distributed Cloud 그룹으로 이동합니다.
https://iac.GDC_URL/admin/groups/gdch의 관리자 영역에서 그룹 보기를 클릭합니다.
새로 만든 사용자의 계정을 Distributed Cloud 그룹에 개발자로 추가합니다.

조정 상태 확인

추가 문제 해결 단계는 subcomponent이 조정되었는지 확인하는 것입니다.

root@count-bootstrapper:~/adfs# kr get subcomponent -n root iac-gitlab
NAME         AGE   STATUS
iac-gitlab   10d   ReconciliationCompleted

gitlab CR이 Running 상태인지 확인합니다.

root@count-bootstrapper:~/adfs# kr get gitlab -n gitlab-system gitlab
NAME     STATUS    VERSION
gitlab   Running   7.11.10

마지막으로 이전 작업이 멈춘 것으로 보이면 하위 구성요소의 Helm 차트를 확인하고 누락된 비밀이 없는지 확인합니다.