CI/CD パイプラインを使用して Amazon EKS へ Java アプリケーションを自動的にビルドし、デプロイする

AWS マネジメントコンソールにサインインし、Amazon S3 コンソールを開いてから、このソリューションをデプロイする予定の AWS リージョンに S3 バケットを作成します。詳細については、Amazon EFS ユーザーガイドの「バケットの作成」を参照してください。

S3 バケットに codeという名前のフォルダを作成します。

リポジトリのクローンを作成した場所にナビゲートします。.zip 拡張子 (cicdstack.zip) でコード全体の圧縮バージョンを作成し、.zip ファイルを検証するには、以下のコマンドを順番に実行します。

注: python コマンドが失敗し、Python が見つからなかったと表示される場合は、代わりに python3 を使用します。

cd aws-codepipeline-devsecops-amazoneks
python -m zipfile -c cicdstack.zip *
python -m zipfile -t cicdstack.zip

S3 バケットで以前に作成したコードフォルダに cicdstack.zip ファイルをアップロードします。

AWS CloudFormation コンソールを開き、スタックの作成 を選択します。

[Specify Template（テンプレートを指定）] で、[Upload a template file（テンプレートファイルをアップロード）] を選択し、cf_templates/codecommit_ecr.yaml ファイルをアップロードしてから、[Next（次へ）] を選択します。

Specify stack details（スタック詳細を指定）に、スタック名を入力してから、次の入力パラメータ値を指定します。

[Next（次へ）] を選択し、スタックの設定オプションのデフォルト設定を使用してから、[Next（次へ）] を選択します。

確認セクションで、テンプレートとスタック詳細を確認してから、[Create stack（スタックを作成）] を選択します。その後、 CodeCommit および Amazon ECR リポジトリを含むスタックが作成されます。

Java CI/CD パイプラインのセットアップに必要な CodeCommit および Amazon ECR リポジトリの名前を書き留めます。

CloudFormation コンソールの スタックで、デプロイした CloudFormation スタックのステータスを確認します。スタックのステータスは作成完了になっているはずです。

さらに、コンソールから、 CodeCommit と Amazon ECR がプロビジョニングされ、準備が整っていることを確認します。

GitHub リポジトリをクローンした場所で、フォルダ に移動しますhelm_charts/aws-proserve-java-greeting。このフォルダの values.dev.yaml ファイルには、Amazon EKS へのコンテナデプロイ用に変更できる Kubernetes リソース設定に関する情報が含まれています。AWS アカウント ID、AWS リージョン、Amazon ECR リポジトリ名を指定して Docker リポジトリパラメータを更新します。

image:
  repository: <account-id>.dkr.ecr.<region>.amazonaws.com/<app-ecr-repo-name>

Java ポッドのサービスタイプは LoadBalancer に設定されます。

service:
  type: LoadBalancer
  port: 80
  targetPort: 8080
  path: /hello
  initialDelaySeconds: 60
  periodSeconds: 30

別のサービス (例、NodePort) を使用するには、パラメータを変更できます。詳細については、Kubernetes ドキュメントを参照してください。

autoscaling パラメータを enabled: true に変更することで、「Kubernetes 水平ポッドオートスケーラー」を有効化できます。

autoscaling:
  enabled: true
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

ターミナルから、次のコマンドを実行して、ローカルワークステーションに Helm v3 がインストールされていることを確認します。

helm --version

Helm v3 がインストールされていない場合は、インストールします。

ターミナルで、Helm チャートディレクトリ (helm_charts/aws-proserve-java-greeting) にナビゲートし、次のコマンドを実行します。

helm lint . -f values.dev.yaml

これで、Helm チャートの構文エラーがチェックされます。

AWS CloudFormation コンソールを開き、スタックの作成 を選択します。

テンプレートを指定で、[Upload a template file（テンプレートファイルをアップロード）] を選択し、cf_templates/build_deployment.yaml テンプレートをアップロードしてから、[Next（次へ）] を選択します。

スタック詳細を指定で、スタック名を指定し、入力パラメータに次の値を指定します。

[次へ] をクリックします。スタックオプションの設定のデフォルト設定を使用してから、[Next(次へ)] を選択します。

レビューセクションで、AWS CloudFormation テンプレートとスタックの詳細を確認し、次へ を選択します。

[スタックの作成] を選択します。 

CloudFormation スタックのデプロイ中、パラメータで指定した E メールアドレスの所有者は、SNS トピックをサブスクライブするメッセージを受け取ります。Amazon SNS をサブスクライブするには、所有者はメッセージ内のリンクを選択する必要があります。

スタックが作成されたら、スタックの[Outputs（出力）] タブを開いてから、EksCodeBuildkubeRoleARN 出力キーの ARN 値を記録します。この IAM ARN 値は、後で Amazon EKS クラスターにワークロードをデプロイするアクセス許可を CodeBuild IAM ロールに提供するために必要です。

AWS Security Hub コンソールを開き、統合へナビゲートします。

Aqua Security を検索し、[Aqua Security: Aqua Security] を選択します。

[Accept findings（検出結果を受け入れる）] を選択します。

Amazon Linux または macOS 環境で cf_templates/kube_aws_auth_configmap_patch.sh シェルスクリプトを開きます。

次のコマンドを実行して Amazon EKS クラスターを認証します。

aws eks --region <aws-region> update-kubeconfig --name <eks-cluster-name>

次のコマンドを使用してシェルスクリプトを実行し、<rolearn-eks-codebuild-kubectl> を以前記録した EksCodeBuildkubeRoleARN のARN 値に置き換えます。

bash cf_templates/kube_aws_auth_configmap_patch.sh <rolearn-eks-codebuild-kubectl> 

Checkov が Dockerfile または Helm チャートの脆弱性を検出すると、パイプラインの CodeSecurity スキャンステージは通常失敗します。ただし、この例の目的は、CI/CD パイプライン、通常はプロセスを通じて修正するのではなく、潜在的なセキュリティの脆弱性を特定する DevSecOps プロセスを確立することです。buildspec/buildspec_secscan.yaml ファイルでは、checkov コマンドは --soft-fail フラグを使用してパイプラインの障害を回避します。

      - echo -e "\n Running Dockerfile Scan"
      - checkov -f code/app/Dockerfile --framework dockerfile --soft-fail --summary-position bottom
      - echo -e "\n Running Scan of Helm Chart files"
      - cp -pv helm_charts/$EKS_CODEBUILD_APP_NAME/values.dev.yaml helm_charts/$EKS_CODEBUILD_APP_NAME/values.yaml
      - checkov -d helm_charts/$EKS_CODEBUILD_APP_NAME --framework helm --soft-fail --summary-position bottom
      - rm -rfv helm_charts/$EKS_CODEBUILD_APP_NAME/values.yaml

Dockerfile と Helm チャートの脆弱性が報告されたときにパイプラインが機能しなくなるようにするには、checkov コマンドから --soft-fail オプションを削除する必要があります。その後、開発者またはエンジニアは脆弱性を修正し、変更を CodeCommit ソースコードリポジトリにコミットできます。

CodeSecurity スキャンと同様に、ビルドステージでは、アプリケーションを Amazon ECR にプッシュする前に、Aqua Security Trivy を使用して、高およびクリティカルな Docker イメージの脆弱性を特定します。この例では、Docker イメージの脆弱性のためにパイプラインに障害が発生するようにしているわけではありません。buildspec/buildspec.yml ファイルには、trivy コマンドに値 0 が付いたフラグ --exit-code が含まれているため、Docker イメージの脆弱性が高または クリティカルであることが報告されてもパイプラインは失敗しません。

      - AWS_REGION=$AWS_DEFAULT_REGION AWS_ACCOUNT_ID=$AWS_ACCOUNT_ID trivy -d image --no-progress --ignore-unfixed --exit-code 0 --severity HIGH,CRITICAL --format template --template "@securityhub/asff.tpl" -o securityhub/report.asff $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION

HIGH, CRTICAL 脆弱性が報告されたときにパイプラインが失敗するようにするには、--exit-code の値を 1 に変更します。

その後、開発者またはエンジニアは脆弱性を修正し、変更を CodeCommit ソースコードリポジトリにコミットできます。

Aqua Security Trivy によって報告された Docker イメージの脆弱性は、Security Hub にアップロードされます。AWS Security Hub コンソールで、検出結果にナビゲートします。レコード の状態 = アクティブ、製品 = Aqua Security で結果をフィルタリングします。これで、Security Hub の Docker イメージの脆弱性が一覧表示されます。脆弱性がSecurity Hub に表示されるまでに 15 分から 1 時間かかる場合があります。

ビルドフェーズが完了すると、デプロイ承認ゲートが表示されます。レビュー担当者またはリリースマネージャーはビルドを検査し、すべての要件が満たされていれば承認する必要があります。これは、アプリケーションのデプロイに継続的デリバリーを使用するチームに推奨されるアプローチです。

承認後、パイプラインは Deploy ステージを開始します。

デプロイステージが成功すると、このステージの CodeBuild ログにアプリケーションの URL が表示されます。URL を使用してアプリケーションの準備が整っていることを確認します。