GitLab CI/Kubernetes - テスト環境用のpostgresマイグレーションを実行します。

Question

私はGitLabを介してテストするためにKubernetesクラスターにPhoenixアプリケーションを送り出しています。私のgitlab-ci.ymlスクリプトにmix ecto.migrateスクリプトを実行すると、私のアプリとpostgresサービスが準備完了です。ここでgitlab-ci.ymlファイルからの抜粋です：

review: 
    stage: review 
    image: dtzar/helm-kubectl 

    environment: 
    name: review/$CI_COMMIT_REF_NAME 
    url: https://$CI_PROJECT_NAME-${CI_ENVIRONMENT_SLUG}.$KUBE_DOMAIN 
    on_stop: stop_review 

    before_script: 
    - command deploy/kinit.sh 

    script: 
    - helm upgrade --install db --wait --set postgresDatabase=app_db stable/postgresql 
    - helm upgrade --install app ./deploy/app_chart --wait --set env.DATABASE_URL="${DATABASE_URL}" 

    - export POD_NAME=`kubectl get pod -l "app=${CI_ENVIRONMENT_SLUG}" -o jsonpath='{.items[0].metadata.name}'` 
    - kubectl exec $POD_NAME -- mix ecto.migrate 

私が理解から、--waitパラメータは、各展開が移動する前に（その全体が）を完了することを意味します。私が見つけたのは、postgresのデプロイメントは完了していますが、それはpostgresサーバーが準備完了しているということではありません。

多くの場合

、 kubectl execコマンドを実行すると、私は次のエラーを取得する：

：私はKubernetesのUIを見てみると

** (exit) exited in: :gen_server.call(#PID<0.183.0>, {:checkout, #Reference<0.0.1.2678>, true, :infinity}, 5000) 
    ** (EXIT) time out 
    (db_connection) lib/db_connection/poolboy.ex:112: DBConnection.Poolboy.checkout/3 
    (db_connection) lib/db_connection.ex:919: DBConnection.checkout/2 
    (db_connection) lib/db_connection.ex:741: DBConnection.run/3 
    (db_connection) lib/db_connection.ex:1132: DBConnection.run_meter/3 
    (db_connection) lib/db_connection.ex:584: DBConnection.prepare_execute/4 
    (ecto) lib/ecto/adapters/postgres/connection.ex:93: Ecto.Adapters.Postgres.Connection.execute/4 
    (ecto) lib/ecto/adapters/sql.ex:243: Ecto.Adapters.SQL.sql_call/6 
    (ecto) lib/ecto/adapters/sql.ex:193: Ecto.Adapters.SQL.query!/5 

、私はpostgresのポッドに対して次のようなエラーを見ることができます

SchedulerPredicates failed due to PersistentVolumeClaim is not bound: "db-postgresql", which is unexpected. 

このメッセージが表示された後、私はポッドを監視し、すべてがうまくいきます。しかし、私の展開スクリプトが失敗する前ではありません。

私の最初の考えは、psqlを使ってサーバーに接続し、 "app_db"データベースの存在を確認する私のアプリケーション用にinitContainerを作成できるということです。そうすれば、タイムアウトや再試行のための自分のコードを書くことについて心配する必要はありません。クーベルネットが提供する組み込みのメカニズムを利用することができます。

しかし、私は本番環境でこれをしたくありません（本番システムでmix ecto.migrateを手動で実行したい）。この場合、initContainerは単にシステムリソースの無駄になります。

gitlab-ci.ymlスクリプトでこれを達成するには堅牢な方法がありますか？ビューの概念的な観点から

Answer 1

私はなります

1. 設定私のPostgresのコンテナにreadiness probe、ポッドは、エンジンが起動するまで、「実行中」とはみなされませんように。

   # in the Pod template: 
   # spec.containers['postgres'] 
   
   readinessProbe: 
       exec: 
       command: 
       - psql 
       - -U 
       - postgres 
       - -c 
       - 'SELECT 1' 
       initialDelaySeconds: 5 
       periodSeconds: 5 
   

2. ミックスタスクを実行する前に、ポッドが「実行中」の状態になるのを待ちます。良いアイデアのように聞こえるん

   # in gitlab-ci.yml, before "mix ecto.migrate" 
   
   - | 
       while [ "$(kubectl get pod $POD_NAME -o jsonpath='{$.status.phase}')" != "Running" ]; do 
        sleep 1; 
       done