Infrastructure as Code を構成する

このページでは、Infrastructure as Code（IaC）ワークフローの 2 日目の運用について説明します。

前提条件

GitLab にログインする

  1. https://iac.GDC_URL で GitLab ウェブ コンソールを開きます。

    GDC_URL は、GDC プロジェクトのベース URL に置き換えます。

  2. GitLab UI で [SAML Login] ボタンをクリックすると、Operations Center IT（OC IT）Active Directory フェデレーション サービス（ADFS）ログインページにリダイレクトされます。

  3. OC IT ADFS 認証情報でログインして、GitLab のホームページを表示します。

  4. CLI アクセスには個人用アクセス トークン（PAT）が必要です。GitLab の記事「個人用アクセス トークンを作成する」の手順（https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token）に沿って、必要なアクセスレベルでユーザーの PAT を作成します。

    PAT を作成したら、CLI ツールを使用して認証を行うことができます。

Infrastructure as Code のワークフロー

一般に、IaC ワークフローは次の手順で構成されます。

  1. 次のように、対応する YAML の変更を GitLab iac リポジトリに生成します。

    • ファイルが存在しない場合は、サイドバーの [新しいファイル] アイコンを選択します。

    [New File] オプションを含むリポジトリ メニュー

    • [新しいファイルを作成] ポップアップ ウィンドウで、新しいファイルの名前と完全なパスを入力し、[ファイルを作成] を選択します。

    テキスト ボックスにファイルパスを入力するための新しいファイル ポップアップを作成

    • ファイルが存在する場合は、サイドバーでファイルを選択して新しいペインで開きます。

    • ファイルに必要な変更を加えます。

  2. 変更を Git commit としてアップロードし、次のように必須のコードレビューのために commit を送信します。

    1. サイドバーで [Commit] オプションを選択して、その他のオプションを展開します。

    2. テキスト エリアにコミット メッセージを記述します。メッセージに役立つ情報を含めます。

    3. [Create a new branch] オプションを選択します。

    4. [新しいマージ リクエストを開始する] チェックボックスをオンにします。

    5. [Commit] をクリックして、マージ リクエスト フォームのプレビューを開きます。

    6. マージ リクエストを作成し、次のような必要な変更を加えます。

      1. [タイトル] フィールドに、統合リクエストの名前を入力します。
      2. [説明] フィールドに説明を入力します。
      3. [マージ オプション] セクションで、[マージ ソースが承認されたときにソースブランチを削除する] チェックボックスをオンにします。
      4. [Create merge request] をクリックします。マージ リクエストは審査担当者に自動的に送信されます。

  3. 適切なオーナーに、複数の関係者による承認プロセスとしてコミットを確認して承認するよう依頼します。

  4. commit を push します。

  5. 対応するクラスタで結果を確認します。

デバッグのヒント

このセクションでは、IaC のデバッグに関するオプションのヒントについて説明します。構成が正確であることを確認するには、nomos コマンドライン ツールをインストールする必要があります。

レンダリングされた構成ファイルをプレビューして検証する

Config Sync が構成ファイルをレンダリングしてクラスタに同期する前に、構成ファイルが正確であることを確認します。それには、nomos hydrate を実行してレンダリングされた構成ファイルをプレビューし、nomos vet を実行して形式が正しいことを検証します。

  1. ローカル git ルート ディレクトリに切り替えます。

  2. 次のフラグを使用して、次の nomos hydrate を実行します。

    nomos hydrate \
    --source-format=unstructured \
    --output=OUTPUT_DIRECTORY

    コマンドの内容:

    • --source-format=unstructured を使用すると、nomos hydrate は非構造化リポジトリで機能できます。Kustomize の構成と Helm チャートを使用しているため、非構造化リポジトリを使用してこのフラグを追加する必要があります。
    • --output=OUTPUT_DIRECTORY を使用すると、レンダリングされた構成ファイルのパスを定義できます。OUTPUT_DIRECTORY は、出力を保存する場所に置き換えます。

  3. 次のフラグを指定して nomos vet を実行し、構成ファイルの構文と有効性を確認します。

    nomos vet \
    --source-format=unstructured \
    --keep-output=true \
    --output=OUTPUT_DIRECTORY

    コマンドの内容:

    • --source-format=unstructured を使用すると、nomos vet は非構造化リポジトリで機能できます。
    • --keep-output=true ではレンダリングされた構成ファイルが保存されます。
    • --output=OUTPUT_DIRECTORY はレンダリングされた構成ファイルのパスです。

プロセスを確認する

同期の状態を確認するには、次の手順を行います。

  1. ka シェル エイリアスを使用します。

      $ alias ka='kubectl --kubeconfig $HOME/root-admin-kubeconfig'

    ka エイリアスは、root-admin クラスタと通信するように kubectl を構成します。

  2. 同期が機能していることを確認します。

     $ ka get rootsync/root-sync -n config-management-system

    Config Sync が使用する commit と、エラーがある場合はそのエラーが表示されます。

同期状態を確認したら、次のいずれかのオプションを使用します。

  • Git リポジトリの最新の commit が正常に適用されているかどうかを確認します。

    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 の値は、最新の commit と同じである必要があります。
      • フィールド .status.sync にエラーはありません。

    2. 最新の commit のリソースがすべて調整されていることを確認します。RootSync オブジェクトまたは RepoSync オブジェクトごとに、Git リポジトリで宣言されたマネージド リソースの調整ステータスを取得する一意の ResourceGroup オブジェクトがあります。ResourceGroup オブジェクトは、RootSync オブジェクトまたは RepoSync オブジェクトと同じ Namespace と名前を使用します。

      たとえば、Namespace config-management- system に root-sync という名前の RootSync オブジェクトがある場合、対応する ResourceGroup オブジェクトも Namespace config-management-system の root-sync を使用します。最新の commit が正常に適用されると、ResourceGroup オブジェクトには、最新の commit のマネージド リソースのグループ、種類、Namespace、名前が含まれます。

      次のコマンドを実行して 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 ファイルを使用して commit を作成したかどうかを確認します。

    1. 省略可: 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

    2. YAML ファイルの例を commit した場合は、次のコマンドを実行します。

      $ ka get svc/hello

      YAML の例から作成されたサービスが表示されます。

    3. 次のコマンドを実行します。

      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]

    4. サービスに新しいアノテーションを追加します。

      $ ka annotate --overwrite svc/hello google.com/test=aaa

      describe をもう一度実行し、アノテーションが存在することを確認して、Config Sync がアノテーションを上書きしていないことを確認します。

    5. 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 をご覧ください。

トラブルシューティング

ADFS のみのログインをロールバックする

デバッグの目的で、デフォルトのパスワードを使用して初期 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 グループに手動で追加します。

  1. GitLab の GitLab 管理者または Distributed Cloud グループの管理者として GitLab にログインします。

  2. GitLab または https://iac.GDC_URL/gdch で Distributed Cloud グループに移動します。

  3. https://iac.GDC_URL/admin/groups/gdch の [管理エリア] で [グループを表示] をクリックします。

  4. 新しく作成したユーザーのアカウントを、Developer として 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 チャートを確認し、シークレットが欠落していないことを確認します。