本頁面由 Cloud Translation API 翻譯而成。

設定基礎架構即程式碼

本頁面介紹基礎架構即程式碼 (IaC) 工作流程的第 2 天作業。

必要條件

完成 IaC 設定。
選用：下載並安裝 nomos 指令列工具，以便進行偵錯：
在非氣隙環境中，如果可以存取 https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command 這個網址，請前往該網頁。

登入 GitLab

前往 https://iac.GDC_URL 開啟 GitLab 網路控制台。

將 GDC_URL 替換為 GDC 專案的基本網址。
在 GitLab 使用者介面中，按一下「SAML Login」按鈕，系統會將您重新導向 Operations Center IT (OC IT) Active Directory 同盟服務 (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 變更，方法如下：
- 如果沒有這個檔案，請選取側欄中的「新檔案」圖示。
- 在「Create new file」(建立新檔案) 彈出式視窗中，輸入新檔案的名稱和完整路徑，然後選取「Create file」(建立檔案)。
- 如果檔案存在，請在側欄中選取檔案，即可在新窗格中開啟。
- 對檔案進行必要變更。
將變更上傳為 Git 修訂版本，並按照下列步驟送交強制性程式碼審查：
1. 選取側欄中的「Commit」(提交) 選項，展開更多選項。
2. 在文字區域中撰寫提交訊息。在訊息中加入任何實用資訊。
3. 選取「建立新分支」選項。
4. 選取「Start a new merge request」(發起新的合併要求) 核取方塊。
5. 按一下「Commit」，開啟合併要求表單的預覽畫面。
6. 建立合併要求，並進行所有必要的變更，例如：
  1. 在「Title」(標題) 欄位中，輸入合併要求的名稱。
  2. 在「Description」(說明) 欄位中輸入說明。
  3. 在「合併選項」部分，選取「接受合併來源時刪除來源分支」核取方塊。
  4. 按一下「建立合併要求」。系統會自動將合併要求傳送給審查員。
請適當的擁有者以多方核准程序審查並核准提交。
推送修訂版本。
在對應的叢集中驗證結果。

偵錯提示

本節說明 IaC 的選用偵錯提示。如要確認設定是否正確，您必須安裝 nomos 指令列工具。

預覽及驗證已算繪的設定

在 Config Sync 算繪設定並同步至叢集之前，請先執行 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 別名會設定 kubectl，以便與 root-admin 叢集通訊。
確認同步處理功能是否正常運作：
```
 $ ka get rootsync/root-sync -n config-management-system
```
您會看到 Config Sync 使用的提交內容，以及任何錯誤 (如有)。

驗證同步狀態後，請使用下列任一選項：

檢查是否已在 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 物件都有專屬的 ResourceGroup 物件，可擷取在 Git 存放區中宣告的受管理資源協調狀態。ResourceGroup 物件的命名空間和名稱與 RootSync 或 RepoSync 物件相同。
  
  舉例來說，如果 RootSync 物件在命名空間 config-management- system 中名為 root-sync，則對應的 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 檔案進行提交：

選用步驟：如果您設定 kubectlcontexts，請使用 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，確認註解存在，並檢查 Config Sync 是否未覆寫該註解。

覆寫註解 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 伺服器進行協調，並檢查錯誤。

如需更多資訊，請參閱官方指南「排解 Config Sync 問題」 Config Management 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。這樣一來，系統就會在 GitLab 中建立使用者帳戶，並連結至 AD 帳戶。

管理員可以按照下列步驟，手動將新建立的使用者加入 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 圖表，確保沒有遺漏任何密鑰。