6.6. ビルドのトラブルシューティング

ビルドマネージャーが起動したビルダーインスタンスは、一時的なものです。これは、タイムアウト/失敗時にRed Hat Quayによってシャットダウンされるか、コントロールプレーン（EC2/K8s）によってガベージコレクションされることを意味します。つまり、ビルダーログを取得するには、ビルドの実行中に取得する必要があります。

6.6.1. DEBUG設定フラグ

DEBUGフラグを設定することで、完了/失敗後にビルダーのインスタンスがクリーンアップされるのを防ぐことができます。そのためには、目的のエクゼキュータの設定で、DEBUGをtrueに設定します。例: 

  EXECUTORS:
    - EXECUTOR: ec2
      DEBUG: true
      ...
    - EXECUTOR: kubernetes
      DEBUG: true
      ...

DEBUGをtrueに設定すると、quay-builderサービスが終了した後や失敗した後にビルドノードがシャットダウンするのを防ぎ、ビルドマネージャーがインスタンスをクリーンアップする（EC2インスタンスの終了やk8sジョブの削除）のを防ぐことができます。これはビルダーノードの問題をデバッグするためのもので、本番環境では設定すべきではありません。ライフタイムサービスは引き続き存在します。つまり、インスタンスはそれでも約2時間後にシャットダウンします (EC2 インスタンスが終了し、k8s ジョブが完了する)。EBUGを設定すると、終了していないインスタンスやジョブが稼働中のワーカーの総数にカウントされるため、ALLOWED_WORKER_COUNTにも影響します。このため、新しいビルドをスケジュールするためには、ALLOWED_WORKER_COUNTに達した場合、既存のビルダーワーカーを手動で削除する必要があります。

以下の手順で行います。

  1. ゲスト仮想マシンは、そのSSHポート（22）をホスト（Pod）のポート2222に転送します。ビルダーPodのポート2222を、ローカルホストのポートにポートフォワードします。 

    $ kubectl port-forward <builder pod> 9999:2222

  2. SSH_AUTHORIZED_KEYSのキーセットを使って、コンテナ内で動作している仮想マシンにSSH接続します。 

    $ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost

  3. quay-builderのサービスログを取得します。 

    $ systemctl status quay-builder
$ journalctl -f -u quay-builder

    • ステップ2-3は、1つのSSHコマンドで行うこともできます。 

      $ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost ‘systemctl status quay-builder’
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost ‘journalctl -f -u quay-builder’