CodePipeline
ユーザーガイド (API バージョン 2015-07-09)

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

以下の情報は、AWS CodePipeline での一般的な問題のトラブルシューティングに役立ちます。

トピック

パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッセージを返します。「デプロイに失敗しました。提供されたロールに十分なアクセス権限がありません: サービス: AmazonElasticLoadBalancing」

問題: CodePipeline のサービスロールには、AWS Elastic Beanstalk に対する十分なアクセス権限がありません。ただし、Elastic Load Balancing の一部の操作を含みますが、これに限定されません。この問題に対処するために、CodePipeline のサービスロールが 2015 年 8 月 6 日に更新されました。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。

可能な変更: 最も簡単な方法は、デフォルトの CodePipeline サービスロールのポリシーの確認 のサービスロールの更新されたポリシーステートメントをコピーし、サービスロールを編集し、古いポリシーステートメントを現在のポリシーで上書きすることです。このポリシーステートメントの部分は、次のように、Elastic Beanstalk に適用されます。

{ "Action": [ "elasticbeanstalk:*", "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "cloudformation:*", "rds:*", "sqs:*", "ecs:*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" },

編集済みのポリシーを適用したら、「AWS CodePipeline でパイプラインを手動で開始する 」のステップに従って Elastic Beanstalk を使用するパイプラインを手動で再実行します。

セキュリティのニーズに応じて、他の方法でアクセス権限を変更することもできます。

デプロイエラー: 「DescribeEvents」アクセス権限がない場合、AWS Elastic Beanstalk デプロイアクションで設定したパイプラインは、失敗することなく中止します。

問題: CodePipeline のサービスロールに、AWS Elastic Beanstalk を使用するパイプラインの "elasticbeanstalk:DescribeEvents" アクションが含まれている必要があります。このアクセス権限がないと、AWS Elastic Beanstalk のデプロイアクションは失敗やエラーになることなく中止します。このアクションがサービスロールに欠落している場合、CodePipeline はユーザーに代わって AWS Elastic Beanstalk のパイプラインデプロイステージを実行するアクセス権限がありません。

修正案: CodePipeline のサービスロールを確認します。"elasticbeanstalk:DescribeEvents" アクションが欠落している場合は、「他の AWS サービスのアクセス許可の追加」の手順に従い、IAM コンソールで [ポリシーの編集] 機能を使用してこのアクションを追加します。

編集済みのポリシーを適用したら、「AWS CodePipeline でパイプラインを手動で開始する 」のステップに従って Elastic Beanstalk を使用するパイプラインを手動で再実行します。

デフォルトのサービスロールの詳細については、「デフォルトの CodePipeline サービスロールのポリシーの確認」を参照してください。

パイプラインエラー: ソースアクションは次のような不十分な権限メッセージを返します。「CodeCommit リポジトリ repository-name にアクセスできませんでした。リポジトリにアクセスするための十分な権限がパイプラインの IAM ロールにあることを確認してください。」

問題: CodePipeline のサービスロールには CodeCommit に対する十分な権限がなく、CodeCommit リポジトリを使用するためのサポートが、2016 年 4 月 18 日に追加される前に作成された可能性があります。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。

修正案: CodeCommit に必要な権限を CodePipeline サービスロールのポリシーに追加します。詳細については、「他の AWS サービスのアクセス許可の追加」を参照してください。

パイプラインのエラー: Jenkins のビルドまたはテストアクションは長期間実行されるため、認証情報や権限がないと失敗します。

問題: Jenkins サーバーが Amazon EC2 インスタンスにインストールされている場合、インスタンスは CodePipeline に必要な権限を持つインスタンスロールで作成されていない可能性があります。Jakins サーバー、オンプレミスインスタンス、または必要な IAM ロールなしで作成された Amazon EC2 インスタンスで IAM ユーザーを使用している場合、IAM ユーザーには必要な権限がないか、Jenkins サーバーがサーバー上に設定されたプロファイル介してこれらの認証情報にアクセスできません。

修正案: Amazon EC2 インスタンスロールまたは IAM ユーザーが、AWSCodePipelineCustomActionAccess 管理されたポリシーまたは同等の権限で設定されていることを確認します。詳細については、「CodePipeline の AWS 管理 (定義済み) ポリシー」を参照してください。

IAM ユーザーを使用している場合は、インスタンスで設定された AWS プロファイルが正しい権限で設定された IAM ユーザーを使用していることを確認してください。Jenkins と CodePipeline の統合のために設定した IAM ユーザー認証情報を Jenkins UI に直接提供する必要があります。これは推奨されるベストプラクティスではありません。その必要がある場合は、Jenkins サーバーが保護されており、HTTP ではなく HTTPS を使用していることを確認してください。

パイプラインのエラー: GitHub ステージ自分のソースは Git サブモジュールが含まれているが、CodePipeline 初期化されていません

問題: CodePipeline は git サブモジュールをサポートしていません。CodePipeline は、サブモジュールをサポートしていない GitHub のアーカイブリンク API を使用しています。

可能な変更: 別スクリプトの一部として直接 GitHub リポジトリをクローンすることを検討してください。たとえば、Jenkins スクリプトにクローンアクションを含めることができます。

パイプラインのエラー : 「GitHubリポジトリにアクセスできませんでした」または「GitHubリポジトリに接続できませんでした」というパイプラインエラーが表示されます。

問題: CodePipeline は OAuth トークンを使用して GitHub と統合します。GitHub ソースプロバイダを使用してパイプラインを作成すると、CodePipeline はデフォルトの OAuth トークンを作成して GitHub の認証情報を管理します。パイプラインがリポジトリに接続すると、GitHub 認証情報を使用して GitHub に接続します。OAuth トークンの認証情報は CodePipeline によって管理されています。トークンを表示または管理することは一切ありません。GitHub への接続に使用できるその他の種類の認証情報は、OAuth アプリではなくユーザーが作成した個人用アクセストークンです。個人用アクセストークンは、CodePipelineではなく、ユーザーが管理します。

これらのアクセス権限が取り消されたり、無効になったりした場合は、GitHub トークンを使用してリポジトリに接続できないと、パイプラインは失敗します。

セキュリティのベストプラクティスは、個人アクセストークンを定期的にローテーションすることです。詳細については、「GitHub 個人用のアクセストークンを定期的にローテーションする (GitHub と CLI)」を参照してください。

解決方法:

CodePipeline が GitHub リポジトリに接続できない場合は、2 つのトラブルシューティングのオプションがあります。

  • パイプラインをリポジトリに手動で再接続するだけで済む場合があります。CodePipeline の OAuth トークンの権限を取り消した可能性があり、それらを復元するだけで済みます。これを行うには、以下の手順を参照してください。

  • デフォルトの OAuth トークンを個人用アクセストークンに変更する必要がある場合があります。OAuth トークンの数には制限があります。詳細については、「GitHub のドキュメント」を参照してください。CodePipeline がその制限に達すると、古いトークンは機能しなくなり、そのトークンに依存するパイプラインのアクションは失敗します。

  1. CodePipeline のアクセス権限が取り消されたかどうかを確認してください。GitHub の Authorized OAuth Apps リストを確認する手順については、「認定された OAuth アプリを表示する」を参照してください。リストに CodePipeline が表示されない場合は、コンソールを使用してパイプラインを GitHub に再接続する必要があります。

    1. コンソールでパイプライン開き、[編集] を選択します。GitHub ソースアクションを含むソースステージで、[ステージの編集] を選択します。

    2. GitHub のソースアクションで、編集アイコンを選択します。

    3. [アクションの編集] ページで、[GitHub に接続] を選択して認証を復元します。

      
                パイプラインには、アクションを含むステージがあり、無効や有効にできる移行によって区切られています。

      プロンプトが表示された場合は、アクションのリポジトリブランチを再入力する必要があります。[完了] を選択します。ステージ編集ページで [完了] を選択してから、パイプライン編集ページで [保存] を選択します。パイプラインを実行します。

  2. これでエラーが修正されないが、GitHub の Authorized OAuth Apps リストに CodePipeline が表示されている場合は、許可されているトークン数を超えている可能性があります。この問題を解決するには、1 つの OAuth トークンを個人用アクセストークンとして手動で構成し、AWS アカウントのすべてのパイプラインでそのトークンを使用するように構成します。詳細については、「個人用のアクセストークンを使用するようにパイプラインを設定する (GitHub と CLI)」を参照してください。

パイプラインエラー: 別の AWS リージョンに作成されたバケットを使用して 1 つの AWS リージョンに作成されたパイプラインは、コード「JobFailed」を持つ「InternalError」を返します。

問題: パイプラインとバケットが異なる AWS リージョンに作成されていると、Amazon S3 バケットに格納されたアーティファクトのダウンロードは失敗します。

解決方法: アーティファクトが格納されている Amazon S3 バケットが、作成したパイプラインと同じ AWS リージョンにあることを確認します。

デプロイのエラー: WAR ファイルを含む ZIP ファイルは AWS Elastic Beanstalk に正常にデプロイされますが、アプリケーションの URL に 404 Not Found エラーが報告されます

問題: WAR ファイルは AWS Elastic Beanstalk 環境に正常にデプロイされますが、アプリケーションの URL は 404 Not Found エラーを返します。

解決方法: AWS Elastic Beanstalk は ZIP ファイルを展開できますが、ZIP ファイルに含まれている WAR ファイルは展開できません。buildspec.yml ファイルに WAR ファイルを指定する代わりに、デプロイするコンテンツを含むフォルダを指定します。以下に例を示します。

version: 0.1 phases: post_build: commands: - mvn package - mv target/my-web-app ./ artifacts: files: - my-web-app/**/* discard-paths: yes

たとえば、「CodeBuild の AWS Elastic Beanstalk サンプル」を参照してください。

ZIP が外部属性を保持しないときは、ソースファイルに GitHub からのファイルアクセス権限は保持されません。

問題: GitHub からのソースファイルを持つユーザーは、パイプラインの Amazon S3 アーティファクトバケットに保存されると、入力アーティファクトがファイルのアクセス権限を失うという問題に直面するかもしれません。GitHub からのファイルを圧縮する CodePipeline ソースアクションは、外部属性を保持しない ZIP ファイルのプロセスを使用するため、ファイルはファイルのアクセス権限を保持しません。

解決方法: chmod コマンド経由でアーティファクトが消費される場所からファイルのアクセス権限を変更する必要があります。CodeBuild などのビルドプロバイダのビルドスペックファイルを更新し、ビルドステージが実行されるたびにファイルのアクセス権限を復元します。次の例では build: セクションで、chmod コマンドを使用した CodeBuild のビルドスペックを示します。

version: 0.2 phases: build: commands: - dotnet restore - dotnet build - chmod a+x bin/Debug/myTests - bin/Debug/myTests artifacts: files: - bin/Debug/myApplication

注記

CodePipeline コンソールを使用してビルド入力アーティファクトの名前を確認するには、パイプラインを表示した後、ビルド アクションで、ツールヒントの上にマウスを合わせます。入力アーティファクトの値をメモします (MyApp など)。AWS CLI を使用して S3 アーティファクトバケットの名前を取得するには、AWS CodePipeline get-pipeline コマンドを実行します。出力には artifactStore オブジェクトと、バケットの名前を表示する location フィールドが含まれます。

パイプラインのアーティファクトフォルダ名が切り詰められているように見えます

問題: パイプラインのアーティファクト名を CodePipeline で表示すると、名前が切り詰められているように見えます。これにより、複数の名前が同じように表示されたり、パイプライン名全体の表示が失われたりしたように見えます。

説明: CodePipeline はアーティファクト名を切り詰めることにより、CodePipeline でジョブワーカーの一時的な認証情報を生成するときに、Amazon S3 のフルパスがポリシーサイズの上限を超えないようにします。

アーティファクト名が切り詰められたように見えても、CodePipeline は、名前が切り詰められたアーティファクトに影響されない方法でアーティファクトバケットにマッピングします。パイプラインは正常に動作します。これは、フォルダやアーティファクトでは問題となりません。パイプライン名には 100 文字の制限があります。アーティファクトフォルダ名は、短縮されたように見えても、パイプラインに対して依然として一意です。

別の問題で支援が必要ですか?

これらの他のリソースを試してください。

このページの内容: