GitLabチャート開発環境のトラブルシューティング
ここに書かれているすべての手順は開発環境専用です。管理者はこの情報をインサイトと感じるかもしれませんが、概要を説明した修正は破壊的で、本番システムには大きな悪影響を与えるでしょう。
パスワードとシークレットが失敗する、または同期されない
開発者は通常、リリースを同じクラスターに複数回デプロイ、削除、再デプロイします。StatefulSetsによって作成されたKubernetesシークレットと永続ボリュームクレームは、helm delete RELEASE_NAME
によって意図的に削除されません。
Kubernetesシークレットだけを削除すると、興味深い問題が発生します。たとえば、パスワードが間違っているためにGitLab Railsがデータベースに接続できないため、新しいデプロイのマイグレーションポッドが失敗します。
シークレットを含む開発環境からリリースを完全に消去するには、開発者はシークレットと永続ボリュームクレームの両方を削除する必要があります。
# DO NOT run these commands in a production environment. Disaster will strike.
kubectl delete secrets,pvc -lrelease=RELEASE_NAME
データベースが壊れているのでリセットが必要
データベース環境のリセットは、開発環境で以下の方法で行います:
- PostgreSQL StatefulSetを削除します。
- PostgreSQL PersistentVolumeClaim の削除
- で GitLab を再度デプロイします。
helm upgrade --install
テスト用のバックアップを更新する必要があります。
CI の特定のジョブは、テスト中に GitLab のバックアップを使用します。必要に応じてこのバックアップを更新するために、以下のステップを完了してください:
- 一致する安定ブランチに対して CI パイプラインを実行して、必要なバックアップを生成します。
- 例: 現在のリリースが
5-5-stable
の場合、ブランチ5-4-stable
に対して CI パイプラインを実行し、14.4 のバックアップを作成します。 - これにはメンテナーのロールが必要です。
- 例: 現在のリリースが
- このパイプラインでは、QAジョブをキャンセルして(しかしspecテストは残して)、バックアップに余計なデータが入らないようにします。
- 仕様テストを終了させます。古いバックアップをインストールし、インスタンスを必要なバージョンにマイグレーションします。
-
gitlab-runner
Deployment replicasを0に編集し、Runnerをオフにします。 - UIにログインし、管理セクションからRunnerを削除します。これで、後で暗号エラーが発生するのを防ぐことができます。
- バックグラウンドマイグレーションがすべて完了したことを確認し、必要であれば強制的に完了させます。
-
toolbox
ポッドを削除して、既存のtmp
データがないことを確認し、バックアップを小さく保ちます。 - バックアップの内容を変更するために手動作業が必要な場合は、次のステップに進む前にそれを完了してください。
- 新しい
toolbox
ポッドから新しいバックアップを作成します。 -
gitlab-backups
バケットの MinIO の CI インスタンスから新しいバックアップをダウンロードします。 - バックアップの名前を変更し、Google Cloud Storage(GCS) の適切な場所にアップロードします:
- プロジェクト
cloud-native-182609
パスgitlab-charts-ci/test-backups/
- 名前フォーマット:
$VERSION_gitlab_backup.tar
(例:14.4.2_gitlab_backup.tar
) - アクセスを編集し、
Entity=Public
、Name=allUsers
、Access=Reader
を追加。
- プロジェクト
- 最後に、
.gitlab-ci.yml
の.variables.TEST_BACKUP_PREFIX
を新しいバージョンのバックアップに更新します。
今後のパイプラインでは、テスト時に新しいバックアップアーティファクトが使用されます。