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に達した場合、既存のビルダーワーカーを手動で削除する必要があります。
以下の手順で行います。
ゲスト仮想マシンは、そのSSHポート(22)をホスト(Pod)のポート2222に転送します。ビルダーPodのポート2222を、ローカルホストのポートにポートフォワードします。
$ kubectl port-forward <builder pod> 9999:2222
SSH_AUTHORIZED_KEYSのキーセットを使って、コンテナ内で動作している仮想マシンにSSH接続します。
$ ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
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’