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

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

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

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

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

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

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 スタックのステータスを確認します。スタックのステータスは作成完了になっているはずです。

コンソールで、CloudFormation リポジトリと Amazon ECR リポジトリがプロビジョニングされ、準備が整っていることを確認します。

GitHub リポジトリのクローンを作成した場所で、フォルダ helm_charts/aws-proserve-java-greeting にナビゲートします。このフォルダの values.dev.yaml ファイルには、Amazon EKS へのコンテナデプロイ用に変更できる Kubernetes リソース設定に関する情報が含まれています。 AWS アカウント ID、および Amazon ECR リポジトリ名を指定して AWS リージョン、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

<ENV> が開発、本番環境、UAT、または QA 環境である、values.<ENV>.yaml ファイル内の値を変更することで、Kubernetes ワークロードのさまざまな機能を有効にできます。

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

helm --version

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

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

helm lint . -f values.dev.yaml

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

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

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

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

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

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

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

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

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

AWS Security Hub CSPM コンソールを開き、[統合] へ移動します。

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 Scan ステージは通常、失敗します。ただし、この例の目的は、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 Scan と同様に、ビルドステージは Aqua Security Trivy を使用して、アプリケーションを Amazon ECR にプッシュする前に Docker イメージの HIGH と CRITICAL の脆弱性を特定します。

- 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

この例では、Docker イメージの脆弱性が報告されてもパイプラインは失敗しません。これは、buildspec/buildspec.yml ファイルの trivy コマンドに 0 値を持つフラグ --exit-code が含まれているためです。HIGH および CRTICAL の脆弱性が報告されたときにパイプラインが失敗するようにするには、--exit-code の値を 1 に変更します。その後、開発者またはエンジニアは脆弱性を修正し、その変更を CodeCommit ソースコードリポジトリにコミットできます。

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

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

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

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