GitLab Managed Appsからクラスター管理プロジェクトへのマイグレーション（非推奨）

GitLab Managed AppsはGitLab 14.0で廃止され、ユーザーが管理するクラスター管理プロジェクトが採用されました。プロジェクトを通してクラスタアプリケーションを管理することで、後発のGitLab Managed Appsを通して管理するよりもはるかに柔軟にクラスターを管理することができます。クラスター管理プロジェクトにマイグレーションするには、GitLab Runnerが利用可能で、Helmに精通している必要があります。

クラスター管理プロジェクトへのマイグレーション

GitLab Managed Appsからクラスター管理プロジェクトにマイグレーションするには、以下の手順に従ってください。例付きのビデオウォークスルーもご覧ください。

  1. Cluster Management Project テンプレートに基づいて新しいプロジェクトを作成します。
  2. このプロジェクトのエージェントをクラスターにインストールします。
  3. .gitlab-ci.yml from the Project Template の指示に従って、KUBE_CONTEXT CI/CD 変数を新しくインストールしたエージェントのコンテキストに設定します。

  4. 事前に設定された.gitlab-ci.yml ファイルを使用して、Helm v2 リリースを通じてデプロイされたアプリを検出します：

    • デフォルトの GitLab Managed Apps 名前空間を上書きしていた場合は、.gitlab-ci.yml を編集して、スクリプトが正しい名前空間を引数として受け取っていることを確認してください：

       script:
   - gl-fail-if-helm2-releases-exist <your_custom_namespace>

    • デフォルトの名前 (gitlab-managed-apps) のままであれば、スクリプトはすでに設定されています。

    いずれにせよ、パイプラインを手動で実行し、detect-helm2-releases ジョブのログを読んで、Helm v2 のリリースの有無とそのリリースを確認してください。

  5. Helm v2のリリースがない場合は、この手順を飛ばしてください。そうでない場合は、Helmv2からHelm v3へのマイグレーション方法に関するHelmの公式ドキュメントに従い、Helm v2リリースが正常にマイグレーションされたことを確認してからクリーンアップしてください。

  6. このステップでは、すでにHelm v3のリリースしかないはずです。このプロジェクトで管理したいアプリケーションのパスを./helmfile.yaml からアンコメントします。一度に管理したいすべてのアプリのコメントを解除することもできますが、プロセス中に迷子にならないように、アプリごとに以下の手順を繰り返す必要があります。

  7. アプリにデプロイされたChartのバージョンに合わせて、関連するapplications/{app}/helmfiles.yaml 。GitLab Runner Helm v3リリースを例にしてみましょう：

    次のコマンドはリリースとそのバージョンを一覧表示します：

    helm ls -n gitlab-managed-apps
   
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0

    CHART {release}-v{chart_version} 、./applications/gitlab-runner/helmfile.yamlのversion: 属性を編集して、デプロイしたバージョンと一致するようにします。これは、マイグレーション中のバージョンアップを避けるための安全なステップです。アプリを別のネームスペースにデプロイしている場合は、上記のコマンドでgitlab-managed-apps を置き換えてください。

  8. アプリに関連付けられているapplications/{app}/values.yaml をデプロイされた値と一致するように編集します。例えば、GitLab Runnerの場合：

    1. 以下のコマンドの出力をコピーしてください（大きいかもしれません）：

      helm get values runner -n gitlab-managed-apps -a --output yaml

    2. applications/gitlab-runner/values.yaml を前のコマンドの出力で上書きします。

    この安全なステップは、予期しないデフォルト値がデプロイした値を上書きしないことを保証します。例えば、GitLab Runnerが誤ってgitlabUrl やrunnerRegistrationToken を上書きしてしまう可能性があります。

  9. アプリによっては特別な注意が必要です：

    • Ingress：内部イシューにより、./gl-helmfile コマンドを実行しようとするとspec.clusterIP: Invalid value が表示される場合があります。これを回避するには、applications/ingress/values.yaml のリリース値を上書きした後、omitClusterIP: falseをすべて上書きし、omitClusterIP: trueに設定する必要があります。もう1つの方法は、kubectl get services -n gitlab-managed-apps を実行してこれらのIPを収集し、ClusterIP の各コマンドから取得した値で上書きすることです。

    • Vault：このアプリは、Helm v2で使用していたチャートからHelm v3で使用するチャートへの変更をもたらします。そのため、このクラスタ管理プロジェクトとインテグレーションする唯一の方法は、このアプリを実際にアンインストールし、applications/vault/values.yaml で提案されているチャートバージョンを受け入れることです。

    • Cert-manager：

      • Kubernetesバージョン1.20以上のユーザーにとって、非推奨のcert-manager v0.10はもはや有効ではなく、アップグレードには破壊的な変更が含まれています。そのため、cert-manager v0.10をバックアップしてアンインストールし、代わりに最新のcert-managerをインストールすることをお勧めします。このバージョンをインストールするには、./helmfile.yaml からapplications/cert-manager/helmfile.yaml をアンコメントしてください。 これにより、新しいバージョンをインストールするパイプラインが起動します。

      • Kubernetesのバージョンが1.20より低いユーザーの場合は、プロジェクトのメインHelmfile (./helmfile.yaml) でapplications/cert-manager-legacy/helmfile.yaml のコメントを解除することで、v0.10に固執することができます。

        caution
        Kubernetesがバージョン1.20以降にアップグレードされると、Cert-manager v0.10は壊れます。

  10. これまでのすべてのステップを実行した後、パイプラインを手動で実行し、apply ジョブログを見て、アプリケーションが正常に検出されたか、インストールされたか、予期しないアップデートが行われたかどうかを確認します。

    いくつかの注釈チェックサムは、この属性と同様に更新されることが期待されます：

    --- heritage: Tiller
+++ heritage: Tiller

成功したパイプラインを取得したら、クラスター管理プロジェクトで管理したい他のデプロイ済みアプリについてもこの手順を繰り返します。

cert-manager v0.10のバックアップとアンインストール

  1. cert-manager v0.10のデータをバックアップする方法については、公式ドキュメントに従ってください。
  2. applications/cert-manager/helmfile.yaml ファイルのinstalled: true をinstalled: false に編集し、cert-manager をアンインストールします。
  3. 次のコマンドkubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager を実行して、残っているリソースを検索します。
  4. 前のス テ ッ プで見つか っ た リ ソ ース それぞれについて、kubectl delete -n gitlab-managed-apps {ResourceType} {ResourceName} を実行 し て削除 し ます。た と えば、cert-manager-controller というConfigMap 型の リ ソ ース が見つか っ た場合は、kubectl delete configmap -n gitlab-managed-apps cert-manager-controllerを実行 し てそれを削除 し ます。

ビデオ・ウォークスルー

GMAからクラスター管理プロジェクトにマイグレーションする方法の例をビデオでご覧いただけます：