Start Building for Free
CircleCI.comアカデミーブログコミュニティサポート

セルフホストランナーのトラブルシューティング

3 days ago1 min read
クラウド

このページでは、コンテナランナーとマシンランナーのエラーとトラブルシューティングについて説明します。

コンテナランナーのトラブルシューティング

コンテナランナーを使用する際、下記のようなエラーが発生する場合があります。

ディスク容量が原因でコンテナを起動できない

ディスク容量の不足により Pod へのボリュームマウントが失敗する旨の警告が表示され、タスクは Preparing Environment ステップで停滞します。

Events:
  Type     Reason       Age   From               Message
  ----     ------       ----  ----               -------
  Normal   Scheduled    67s   default-scheduler  Successfully assigned default/ccita-62e94fd3faccc34751f72803-0-7hrpk8xv to node3
  Warning  FailedMount  68s   kubelet            MountVolume.SetUp failed for volume "kube-api-access-52lfn" : write /var/snap/microk8s/common/var/lib/kubelet/pods/4cd5057f-df97-41c4-b5ef-b632ce74bf45/volumes/kubernetes.io~projected/kube-api-access-52lfn/..2022_08_02_16_24_55.1533247998/ca.crt: no space left on device

十分なディスク容量があることを確認してください。

Pod ホストノードがメモリ不足になる

Pod がホストされているノードのメモリが不足すると、タスクが失敗し、 Runner Instance Failure という名前の失敗ステップと以下のメッセージが表示されます。

could not run task: launch circleci-agent on "container-0" failed: command terminated with exit code 137.

kubectl を使って Kubernetes で表示すると、Pod のステータスは OOMKilled になります。 タスク Pod の設定を使って、ジョブ自体のメモリーの割り当てを管理できます。

Pod ホストノードのディスク容量が不足する

ノードがいっぱいになると、 node.kuberenetes.io/disk-pressure という Taint が表示され、新しいタスク Pod をスケジュールできなくなります。 この Pod のすべての有効なノードに同じ Taint またはスケジュールを妨げるその他の条件があると、そのタスク Pod は Taint されていない有効なノードが使用できるようになるまで保留状態になります。 これにより、このジョブが UI の Preparing Environment ステップで停滞しているように見えます。

この状態にならないよう、クラスタをより効果的にスケーリングるする必要があります。

タスクを実行しているノードが突然停止する

コンテナランナーが別の Node でホストされている場合、タイムアウトになるまでタスクは CircleCI UI で実行されているように見えます。 kubectl も、クラスタの liveness Probe のタイムアウトになるまで、Pod を実行中として表示します。 Podは terminating 状態になり、そのまま停滞します。 この時点で、Pod を強制的に削除する必要があります。 強制的に削除しないと、kubectl がハングする場合があります。

kubectl delete pod $POD_NAME --force

イメージに無効なエントリポイントがある

イメージに指定されたエントリポイントが無効な場合、タスクが失敗し、エラーになります。

could not run task: launch circleci-agent on "container-0" failed: command terminated with exit code 139.

コンテナランナーとクラウド版 CircleCI では、 プライマリコンテナ のエントリポイントの設定方法が異なります。 クラウドの場合、プライマリコンテナのエントリポイントは com.circleci.preserve-entrypoint=true LABEL 指示を使用して保持されていない限り無視されます ( エントリポイントの追加 を参照)。 一方コンテナランナーの場合、常にシェル (/bin/sh) がデフォルト設定されるか、ジョブ設定でエントリポイントが指定されている場合はそれが設定されます。

注: エントリポイントは、失敗せずに最後まで実行される必要があります。 失敗した場合、またはビルドの途中で停止した場合は、ビルドも停止します。 ログまたはビルドステータスにアクセスする必要がある場合は、エントリポイントの代わりにバックグラウンドステップを使用します。

このエラーを減らすには、 エントリポイントの追加 に関するドキュメントに沿ってエントリポイントを指定します。 カスタムビルドされた Docker イメージの使用 に記載されているようにエントリポイントを明示的に設定します。

イメージのアーキテクチャが異なる

ジョブのイメージがデプロイされているノードと異なるアーキテクチャを使用している場合、コンテナランナーはエラーになります。

19:30:12 eb1a4 11412.984ms service-work error=1 error occurred:
        * could not start task containers: pod failed to start: :

タスク Pod にはエラーステータスも表示されます。 CircleCI UI で失敗したジョブとしてエラーとともにに表示されます。

could not start task containers: pod failed to start: :

ジョブを使ってノードに使用されている基盤アーキテクチャをジョブで使用されているイメージのアーキテクチャに合わせて修正する必要があります。

タスク Pod の設定が誤っている

リソースクラスのタスク Pod の設定が誤っている場合、タスクは要求されると失敗します。 UI では、このエラーは Runner Instance Failure ステップに入り、以下のようなメッセージが表示されます。

could not start task containers: error creating task pod: Pod "ccita-62ea7dff36e977580a329a9d-0-uzz1y8xi" is invalid: [spec.containers[0].resources.limits[eppemeral-storage]: Invalid value: "eppemeral-storage": must be a standard resource type or fully qualified, spec.containers[0].resources.limits[eppemeral-storage]: Invalid value: "eppemeral-storage": must be a standard resource for containers, spec.containers[0].resources.requests[eppemeral-storage]: Invalid value: "eppemeral-storage": must be a standard resource type or fully qualified, spec.containers[0].resources.requests[eppemeral-storage]: Invalid value: "eppemeral-storage": must be a standard resource for containers]

Kuberenetes クラスタで Pod が一つも作成されていない タスク Pod の設定を、 コンテナランナー に記載されているように修正する必要があります。

Bash がない

"could not start task containers: exec into build container "container-0" failed: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "bb04485b9ef2386dee5e44a92bfe512ed786675611b6a518c3d94c1176f9a8aa": OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown"

コンテナランナーで実行されるジョブで使用するカスタムイメージには Bash が必要です。

ジョブの要求後、10 分以上経っても開始されない

ジョブのページに「This job was claimed but has not started in over 10 minutes」というメッセージが表示されている場合、またはタスクのライフサイクルステップにコンテンツがない場合 (図を参照)、

Image showing the task lifecycle with no content message
Figure 1. タスクのライフサイクルにコンテンツがない

以下のような原因が考えられます。

  • Pod の再起動: ワークフローが実行される前後のタイミングでコンテナエージェントの Pod が再起動されていないか確認してください。 Pod がその前後のタイミングで再起動されていた場合、ジョブは処理されません。 その場合、そのジョブをもう一度再実行することを推奨します。

    `kubectl logs -n circleci <full pod name> --previous` コマンドにより、それまでのすべての実行のログを確認できます。
  • ネットワーク接続の問題: 特にこの問題が断続的に発生する場合は、コンテナエージェントのネットワーク接続を確認してください。 この問題は、タスクを要求した後にコンテナエージェントがネットワーク接続を失うと発生する場合があります。

kubectl exec --stdin --tty -n circleci < full pod name > — /bin/sh コマンドを使って Pod に接続し、ping テストを長時間実行することを推奨します。 また、 CircleCI のセルフホストランナーに必要な接続 についてのセクションが含まれる「よく寄せられるご質問」のリンクへの接続を確認することを推奨します。

リソースの使用量を監視できる外部ツールもあります。 Kubernetes のドキュメント をご覧ください。

マシンランナーのトラブルシューティング

マシンランナーをご使用の際に、下記のようなエラーが発生する可能性があります。

macOS に初めてセルフホストランナーをインストールしましたが、ジョブが "Preparing Environment" の状態でスタックしました。エラーは表示されていません。どうすれば良いですか。

場合によっては、root で実行できるように、ローンチエージェントの実行権限を更新する必要があります。 以下の 2 つのコマンドを実行してください。

sudo chmod +x /opt/circleci/circleci-launch-agent
sudo /opt/circleci/circleci-launch-agent --config=/Library/Preferences/com.circleci.runner/launch-agent-config.yaml

ジョブをキャンセルし、再実行します。 それでもジョブが実行されない場合は、 サポートチケット を送信してください。

SSH 接続でのデバッグ

CircleCI マシンランナーでは、デバッグのために SSH 接続でジョブを再実行することが可能です。 この機能の使用に関する詳細は、 SSH を使用したデバッグをご覧ください。


ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。

サポートが必要ですか

CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。

または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。