GitLab管理のKubernetesアプリから移行する方法
GitLab Managed Appsは、プラットフォームのKubernetes統合の機能であり、一般的なクラスタアプリケーションをワンクリックでインストールできるものでした。この機能のこのバージョンは、GitLab 13のリリースサイクル中に非推奨となり、6月の14.0リリースで完全に削除されました。次に、あなたのManaged Appsをサポートされているデプロイメントモデルに移行する方法を説明します。
管理されたアプリからの移行
Managed Appsは、新しいKubernetesクラスターの立ち上げを簡素化する方法として開発されました。GitLabは、NGINX Ingress、Cert Manager、Prometheusなどのアプリケーション用のテンプレートを提供しました。
2つの異なるインストール方法が提供されました：ワンクリックとCI/CDです。ワンクリックの方法は、利用可能なアプリを一覧表示し、クリックしてインストールできるGitLab内のUIを提供しました。一部のアプリは基本的な設定も公開していました。CI/CDの方法は、パイプラインの一部としてアプリをクラスターに追加するためのGitLab CIテンプレートを提供しました。
ワンクリックインストールは完全になくなりました。CIメソッドは機能しますが、非推奨とされ、GitLab 15.0で削除される予定です。マネージドアプリはインストールを大幅に簡素化しましたが、クラスタのライフサイクルのこの段階にのみ対応していました。アプリはインストールするかアンインストールするかのいずれかだったため、メンテナンスやカスタマイズを行うためには、通常のKubernetes管理ツールにすぐに移行する必要がありました。
機能が削除されても、既存のManaged AppのインストールはGitLab 14.0で引き続き動作します。クラスターのダウンタイムを心配することなく、安全にGitLabをアップグレードできます。ただし、アップグレードを行うとManaged Apps UIが削除されるため、GitLab内からアプリを表示したりアンインストールしたりすることはできなくなります。
アプリのコントロールを得る
管理されたアプリから移行することは、必ずしもあなたの側で直ちに行動を必要とするわけではありません。アプリは稼働し続けるため、gitlab-managed-apps ネームスペースにそのまま存在させたい場合は、何も変更する必要はありません。
アプリは単にクラスター内のHelmデプロイメントであるため、それらを管理することができます。
kubectlおよびHelmコマンドラインバイナリ。それらは通常のKubernetesリソースとして表示されます。
GitLabによってインストールされたクラスタ資源を一覧表示するには、このKubectlコマンドを使用します:
kubectl get all -n gitlab-managed-appsこれにより、GitLabの古い「アプリケーション」ページがない場合に、クラスターで何が実行されているかを確認できます。
古いGitLabバージョンによってインストールされたアプリで問題が発生することがあります。これらはHelm v2を使って追加された可能性があり、これは現代のHelm v3クライアントと互換性がありません。v2のアプリがインストールされているかどうか不明な場合は、以下のコマンドを使用して確認してください:
kubectl get all -n gitlab-managed-apps | grep 'helm.sh/release'このコマンドの出力に表示されるアプリは、Helm v3によってインストールされました。以前のget allコマンドとリストを比較して、Helm v2によって追加されたアプリを特定してください。
もしあなたのアプリがHelm v2を使用していることが判明した場合、アプリを最新の状態にするためにHelm移行ガイドを手動で確認する必要があります。アプリを長期間保持する予定であれば、Helm v3に移行することをお勧めします。代替手段として、マシンにHelm v2をインストールすることで、アプリと対話して即時の修正やメンテナンスを行うことができます。
GitLabの新しいクラスタアプリモデルへのアップグレード
Managed Appsの主な目的であるクラスターセットアップの簡素化は、GitLabによって完全に無視されているわけではありません。GitLab 14.0は、クラスターのプロビジョニングの新しいデプロイメントモデルとして「管理プロジェクト」に焦点を当てています。
GitLabは、Kubernetesクラスターにアプリをインストールするために使用できるプロジェクトテンプレートを提供します。これは、デプロイされるHelmチャートに完全な管理権限を持つことを保証することで、Managed Appsに関する元の問題に対処します。テンプレートをクローンし、プロジェクトをクラスターに接続し、必要に応じて個々のアプリチャートを編集および削除します。CIパイプラインを実行すると、選択したアプリがクラスターにデプロイされます。
既存のマネージドアプリを管理プロジェクトフォーマットに移行することができます。これにより、GitLabが推奨するアプローチを使用して引き続き運用することができます。既存のデプロイメントのおかげで、すでにKubernetesクラスタがあなたのGitLabインスタンスに接続されていると仮定します。
新しいGitLabプロジェクトを作成するには、右上のプラスボタンを使います。「テンプレートから作成」をクリックし、次に「GitLabクラスタ管理」テンプレートまでスクロールします。「テンプレートを使用」ボタンをクリックします。次の画面でプロジェクトに名前を付け、「プロジェクトを作成」を押します。
このテンプレートは、アプリをクラスターにデプロイするための一連のHelmチャートを提供します。個々のアプリチャートはapplicationsディレクトリに保存されています。各アプリには独自のサブディレクトリが与えられます。
プロジェクトのルートにある helmfile.yaml を編集することから始めます。これは、GitLab Web IDE で行うか、リポジトリを Git を使ってクローンすることで行います。このファイルは、個々のアプリケーションテンプレートを参照しています。使用しているアプリケーションの関連する行のコメントを外して有効化します。この例では、以前に Ingress と Cert Manager を GitLab Managed Apps としてインストールしているので、クラスター管理プロジェクトでそれらを有効にします。
次に、どのチャートのバージョンがすでにクラスターにデプロイされているかを確認する必要があります。このステップは、異なるバージョンでアプリを意図せず置き換えないようにするために重要です。
アプリのバージョンは、helm ls -n gitlab-managed-appsを実行することで確認できます。出力テーブルでアプリを探し、CHART列に表示されているバージョンをメモしてください。これはapp-name-X.Y.Zの形式になりますので、X.Y.Zの部分だけが必要です。
新しいGitLabプロジェクトに戻り、アプリケーションに関連するhelmfile.yaml（例：applications/ingress/helmfile.yaml）を開いてください。versionフィールドをメモしたバージョンに合わせて変更します。
最後に、デフォルトのvalues.yamlを既存のHelm値のセットに置き換えます。Helmを使用して、アプリの値ファイルのYAML表現を読み込みます:
helm get values ingress -n gitlab-managed-apps -a --output yamlingressをあなたのアプリのデプロイメントの名前に置き換えます。全体のYAML出力をコピーして、applications/ingress/values.yamlファイルを上書きします。ファイルパスがあなたのアプリに合うように調整してください。これで、クラスター管理プロジェクトのデプロイメントを実行する準備が整いました。
デフォルトブランチ（通常は GitLab 14.0 の新しいプロジェクトでは main）に変更をマージすると、デプロイパイプラインが自動的に開始されます。Git を使用して変更をコミットし、マージしてください:
git checkout -b my-branch
git add .
git commit -m "Migrate existing GitLab Managed Apps"
git checkout main
git merge my-branch
git push -u origin main
パイプラインは実行されます。テンプレートの変更が正しければ、実行中のアプリケーションには影響はないはずです。デプロイメントメカニズムの変更により、一部の無害なメタデータが変更される可能性があります。
これで、アプリの継続的なメンテナンスのためにクラスタ管理プロジェクトを使用する準備が整いました。例えば、helmfile.yaml内のversionフィールドを編集することで、アプリの新しいバージョンに更新することができます。変更をmainにマージすることで、Helmがクラスタ内で変更を適用するように促されます。
結論
GitLab管理アプリは、多くのユーザーがKubernetesを始めるための第一歩を踏み出すのを助けました。しかし、その機能のシンプルさは最終的には限界があることが証明されたため、現在は段階的に削除されています。
幸いなことに、Managed Apps からの移行は非常に簡単です。彼らについて特別なことは何もありません - 彼らは単にクラスターの gitlab-managed-apps 名前空間に存在する通常の Helm デプロイメントです。これは、GitLab 14.0 にアップグレードしてもワークロードが利用可能なままであることを意味し、自分のペースで移行する自由があります。
今後、クラスター管理プロジェクトは、Kubernetes上で人気のアプリをインストールするためにGitLabを使用する際の推奨アプローチです。少し技術的に要求されますが、このモデルはより多くの制御を提供し、コードとしてインフラストラクチャを管理するのに役立ちます。