AWS CodePipeline​ 内に位置している
ユーザーガイド (API バージョン 2015-07-09)

このガイドの手順では、新しいコンソールデザインがサポートされています。古いバージョンのコンソールを選択すると、古い概念が反映され、本ガイドの基本的な手順がそのまま適用されます。新しいコンソールのヘルプにアクセスするには、情報アイコンを選択します。

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

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

トピック

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

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

可能な変更: 最も簡単な方法は、デフォルトの AWS 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 デプロイアクションで設定したパイプラインは、失敗することなく中止します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パイプラインのエラー: 次のメッセージのパイプラインエラーが表示されます。「PermissionError: GitHub リポジトリにアクセスできませんでした」

問題: AWS CodePipeline は OAuth トークンを使用して GitHub と統合します。AWS CodePipeline の OAuth トークンのアクセス権限を取り消した可能性があります。さらに、トークンの数は限られています (詳細については、「GitHubのドキュメント」を参照)。AWS CodePipeline がその制限に達すると、古いトークンは機能しなくなり、そのトークンに依存するパイプラインのアクションは失敗します。

解決方法: AWS CodePipeline のアクセス許可が取り消されたかどうかを確認します。GitHub にサインインし、[アプリケーション] に進み、[Authorized OAuth Apps (承認された OAuth アプリ)] を選択します。リストに AWS CodePipeline が表示されない場合は、AWS CodePipeline コンソールを開いてパイプラインを編集し、[GitHub に接続] を選択して認証を復元します。

GitHub の認定アプリケーションのリストに AWS CodePipeline が存在する場合、許容されるトークン数を超えている可能性があります。この問題を解決するには、手動で 1 つの OAuth トークンを個人用のアクセストークンとして設定し、そのトークンを使用するように AWS アカウントのすべてのパイプラインを設定します。

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

GitHub からの個人用のアクセストークンを使用するようにパイプラインを設定するには

  1. GitHub アカウントにサインインし、GitHub のドキュメントの「個人用のアクセストークンの作成 」の指示に従います。トークンが GitHub スコープ (admin:repo_hookrepo) を持つように設定されていることを確認します。トークンをコピーします。

  2. ターミナル (Linux, macOS, or Unix) またはコマンドプロンプト (Windows) で、OAuth トークンを変更するパイプラインに対して get-pipeline コマンドを実行し、コマンドの出力を JSON ファイルにコピーします。たとえば、MyFirstPipeline という名前のパイプラインに対しては、以下のようなコマンドを入力します。

    aws codepipeline get-pipeline --name MyFirstPipeline >pipeline.json

    コマンドの出力は pipeline.json ファイルに送られます。

  3. プレーンテキストエディタでファイルを開き、GitHub アクションの OAuthTokenField の値を編集します。アスタリスク (****) を GitHub からコピーしたトークンに置き換えます。例:

    "configuration": { "Owner": "MyGitHubUserName", "Repo": "test-repo", "Branch": "master", "OAuthToken": "Replace the **** with your personal access token" },
  4. get-pipeline コマンドを使用して取得されたパイプライン構造を操作している場合、ファイルから metadata 行を削除して JSON ファイルの構造を変更する必要があります。そうしないと、update-pipeline コマンドはこのファイルを使用することができません。JSON ファイルのパイプライン構造からセクションを削除します ("metadata": { } 行と、その中の created"、"pipelineARN"、および "updated" の各フィールド)。

    たとえば、構造から以下の行を削除します。

    "metadata": { "pipelineArn": "arn:aws:codepipeline:region:account-ID:pipeline-name", "created": "date", "updated": "date" }
  5. ファイルを保存したら、先ほど編集した JSON ファイルを --cli-input-json パラメータで指定して、update-pipeline を実行します。たとえば、MyFirstPipeline という名前のパイプラインを更新するには、以下のように入力します。

    重要

    ファイル名の前に必ず file:// を含めてください。このコマンドでは必須です。

    aws codepipeline update-pipeline --cli-input-json file://pipeline.json
  6. GitHub アクションを含むパイプラインごとにステップ 2 〜 4 を繰り返します。

  7. パイプラインの更新が完了したら、それらのパイプラインの更新に使用した .json ファイルを削除します。

パイプラインのエラー: 別の 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

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

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

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

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

注記

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

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

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

このページの内容: