トラブルシューティング

1+ year ago2 min read
Last updated • Read time
クラウド
This document is applicable to CircleCI クラウド
Server v4.x
This document is applicable to CircleCI Server v4.x
Server v3.x
This document is applicable to CircleCI Server v3.x
このページの内容

This page offers troubleshooting suggestions for the following aspects of CircleCI:

Orb

未承認 Orb を使用しようとするとエラーメッセージが出るのはなぜですか?

未承認 Orb の使用を有効にするには、お客様の組織の設定ページから Security タブをクリックします。 その後、yes をクリックして未承認 Orb を許可するを有効にします。

ローカルでのテストで以下のエラーが表示されるのはなぜですか?

コマンド:

circleci build -c .circleci/jobs.yml --job test

エラー:

Error:
You attempted to run a local build with version 2.1 of configuration.

このエラーを解決するには、設定で circleci config process を実行し、その設定をディスクに保存します。 次に、処理された設定に対して circleci local execute を実行します。

名前空間を要求または安定版(Production)Orb をパブリッシュしようとするとエラーが発生します。

お客様は組織オーナーまたは管理者でない可能性があります。

組織が要求できる名前空間は 1 つだけです。 組織の名前空間を要求するには、認証を行うユーザーがその組織内でオーナーまたは管理者の権限を持っている必要があります。

必要な権限レベルがない場合、下記のようなエラーが表示されることがあります。

Error: Unable to find organization YOUR_ORG_NAME of vcs-type GITHUB: Must have member permission.: the organization 'YOUR_ORG_NAME' under 'GITHUB' VCS-type does not exist. Did you misspell the organization or VCS?

詳細については、 Orb CLI の権限リストを参照してください。

パイプライン

パイプラインのスケジュール実行が実行されないのはなぜですか?

パイプラインのスケジュール実行が実行されない場合、以下を確認してください。

  • スケジュール化されたパイプラインに設定されている実行ユーザーは現在も組織の一員ですか? この設定を確認するには、Webアプリのトリガー(Triggers)セクションのアトリビューション (Attribution) を選択します。

  • スケジュールに設定されたブランチが削除されていないかを確認する

  • お客様の VCS 組織が SAML 保護を使用してませんか? SAML トークンは頻繁に失効します。失効している場合、リクエストが失敗します。

コミットをプッシュしてもジョブが実行されません。

CircleCI アプリケーションで、各ジョブやワークフローの画面にエラーメッセージがないか確認してください。 多くの場合、.circleci/config.yml ファイルのフォーマットの誤りが原因となってエラーが発生しています。

詳細については、 YAML に関するページを参照してください。

.circleci/config.yml のフォーマットミスを確認し、それでも解決しない場合は、 CircleCI サポートセンターで検索してみてください。

ジョブがキューイングするのはなぜですか?

お客様の組織のプランによっては同時実行に制限があり、ジョブがキューイングする場合があります。 ジョブが頻繁にキューイングする場合は、 ご利用プランのアップグレードをご検討ください。

Performance プランを利用しているのに、ジョブがキューイングするのはなぜですか?

CircleCI のすべてのお客様にシステムを安定した状態で利用していただけるよう、 リソースクラスごとに同時実行数のソフト制限が設けられています。 ジョブのキューイングが発生する場合は、この制限に達している可能性が考えられます。 CircleCI サポートに制限値の引き上げを依頼してください。

プロジェクトダッシュボード上にプロジェクトがないのはなぜですか?

ビルドしようとしているプロジェクトが表示されておらず、CircleCI 上で現在ビルド中のものではない場合は、CircleCI アプリケーションの左上隅で組織を確認してください。 左上にユーザー my-user が表示されている場合、my-user に属するプロジェクトだけが Projects の下に表示されます。 your-org/project というプロジェクトをビルドする場合は、アプリケーションの組織切替メニューの組織を your-org に切り替える必要があります。

Docker イメージの名前はどのように機能していますか? どこからプルされていますか?

CircleCI では、現在 Docker Hub からの Docker イメージのプル (と Docker Engine のプッシュ) をサポートしています。 公式の Docker イメージの場合、単純にイメージ名やタグを指定してプルできます。

golang:1.7.1-jessie
redis:3.0.7-jessie

Docker Hub のパブリックイメージの場合は、下記のようにアカウント名やチームのユーザー名を付加してプルすることも可能です。

my-user/couchdb:1.6.1

Docker イメージのバージョンを指定するときのベストプラクティスは?

latest タグを付けずにイメージのバージョンを指定することをお勧めします。 もしくは、特定のバージョンやタグを付けるのも良い方法です。ベースとなるイメージのディストリビューションに変更があったとき、イメージを固定し、コンテナへのアップストリームの変更を防ぐには、例えば cimg/ruby:3.0.4-browsers のように指定します。 例えば、cimg/ruby:3.0.4 のみを指定した場合、browsers から node に予期せぬ変更が加えられる場合があります。 その他の応用例は、 Docker イメージのベストプラクティス CircleCI イメージのベストプラクティスを参照してください。

イメージのバージョン指定に関するベスト プラクティスを教えてください。

Docker イメージのタイムゾーンを設定するには、環境変数 TZ を使用します。 定義された変数 TZ を使った .circleci/config.yml の設定例は以下のようになります。

version: 2.1
jobs:
  build:
    docker:
      - image: your/primary-image:version-tag
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
      - image: mysql:5.7
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
        environment:
           TZ: "America/Los_Angeles"
    working_directory: ~/your-dir
    environment:
      TZ: "America/Los_Angeles"

この例では、プライマリ イメージと mySQL イメージの両方にタイムゾーンを設定しています。

設定できるタイムゾーンの一覧は、 Wikipedia でご確認ください。

コンテナランナー

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

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

ディスク容量の不足により 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 が必要です。

インフラに問題があった場合

もし、「Oops, there was an issue with your infrastructure」というメッセージが表示された場合。 セルフホストランナーのインフラストラクチャが動作していることを確認し、ジョブを再実行してみてください。 それでも問題が解決しない場合は、ジョブのページにある「トラブルシューティングガイド」を参照するか、タスクのライフサイクルステップにコンテンツがない場合(図のような場合)、以下に説明する潜在的な原因を検討する必要があります:

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 のセルフホストランナーに必要な接続 についてのセクションが含まれる「よく寄せられるご質問」のリンクへの接続を確認することを推奨します。

  • リソースの枯渇: Pod がジョブを終了し、リソースが解放されている可能性があるため、ポッドがクラスタ内のリソース制限に達しているかどうかを確認してください。 リソース制限の設定は、 values.yaml 内で、または config.yaml 内で行うことを推奨します。

リソースの使用量を監視できる外部ツールもあります。 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 を使用したデバッグをご覧ください。