此页面由 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 Web 控制台。

将 GDC_URL 替换为 GDC 项目的基础网址。
在 GitLab 界面中，点击 SAML 登录按钮，系统会将您重定向到 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 更改，如下所示：
- 如果该文件不存在，请选择边栏中的新建文件图标。
- 在创建新文件弹出式窗口中，输入新文件的名称（包含完整路径），然后选择创建文件。
- 如果该文件存在，请在边栏中选择该文件，以便在新窗格中打开它。
- 对文件进行必要的更改。
以 Git 提交的形式上传更改，并按如下方式发送提交以进行强制性代码审核：
1. 选择边栏中的提交选项以展开更多选项。
2. 在文本区域中撰写提交消息。在消息中添加任何实用信息。
3. 选择创建新分支选项。
4. 选中启动新的合并请求复选框。
5. 点击提交，打开合并请求表单的预览。
6. 创建合并请求并进行所需的任何更改，例如：
  1. 在标题字段中，输入合并请求的名称。
  2. 在说明字段中，输入说明。
  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 shell 别名：
```
  $ 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 对象具有相同的命名空间和名称。
  
  例如，对于命名空间 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，确认注解存在，并检查 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 配置管理问题” 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 图表，确保没有缺失的 Secret。