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

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

5.6.1. DEBUG 設定フラグ

ビルダーインスタンスが完了/障害の発生後にクリーンアップされないように、DEBUG フラグを設定できます。これを実行するには、必要な Executor 設定で DEBUG を true に設定します。以下は例になります。

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

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

以下の手順を使用します。

  1. ゲスト仮想マシンは、SSH ポート (22) をホストの (Pod) ポート 2222 に転送します。ポートはビルダー Pod のポート 2222 を localhost のポートに転送します。例:

    $ 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 は、単一の 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’