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’
