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-runnerDeployment 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を新しいバージョンのバックアップに更新します。
今後のパイプラインでは、テスト時に新しいバックアップアーティファクトが使用されます。
