CI/CD 파이프라인을 사용하여 Amazon EKS에 Java 애플리케이션 자동 구축 및 배포

AWS Management Console에 로그인하고 Amazon S3 콘솔을 연 다음 이 솔루션을 배포하려는 AWS 리전에 S3 버킷을 생성합니다. 자세한 내용은 Amazon S3 설명서의 버킷 생성을 참조하십시오.

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 콘솔을 열고 [스택 생성] 을 선택합니다.

템플릿 지정에서 템플릿 파일 업로드를 선택하고, cf_templates/codecommit_ecr.yaml 파일을 업로드한 후 다음을 선택합니다.

스택 세부 정보 지정에서 스택 이름을 입력하고 다음 입력 파라미터 값을 제공합니다.

다음을 선택하고 스택 구성 옵션의 기본 설정을 사용한 후 다음을 선택합니다.

검토 섹션에서 템플릿과 스택 세부 정보를 확인한 다음 스택 생성을 선택합니다. 그러면 CodeCommit 및 Amazon ECR 리포지토리를 포함한 스택이 생성됩니다.

Java CI/CD 파이프라인 설정에 필요한 CodeCommit 및 Amazon ECR 리포지토리의 이름을 기록해 둡니다.

CloudFormation 콘솔의 스택에서 배포한 CloudFormation 스택의 상태를 확인합니다. 스택의 상태는 생성 완료여야 합니다.

또한 콘솔에서 Amazon ECR이 프로비저닝되고 준비되었는지 CodeCommit 확인합니다.

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 Horizontal Pod Autoscaler를 활성화할 수 있습니다.

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

터미널에서 다음 명령을 실행하여 Helm v3가 로컬 워크스테이션에 설치되어 있는지 확인합니다.

helm --version

헬름 v3가 설치되지 않은 경우 설치하십시오.

터미널에서 차트 Helm 디렉터리 (helm_charts/aws-proserve-java-greeting) 로 이동하여 다음 명령을 실행합니다.

helm lint . -f values.dev.yaml

그러면 차트 Helm에 구문 오류가 있는지 확인할 수 있습니다.

AWS CloudFormation 콘솔을 열고 [스택 생성] 을 선택합니다.

템플릿 지정에서 템플릿 파일 업로드를 선택하고, cf_templates/build_deployment.yaml 템플릿을 업로드한 후 다음을 선택합니다.

스택 세부 정보 지정에서 스택 이름을 지정하고 다음 입력 파라미터 값을 제공합니다.

다음을 선택합니다. 스택 구성 옵션의 기본 설정을 사용한 후 다음을 선택합니다.

[Review] 섹션에서 AWS CloudFormation 템플릿과 스택 세부 정보를 확인한 후 [Next] 를 선택합니다.

스택 생성을 선택합니다. 

CloudFormation 스택 배포 중에 파라미터에 제공한 이메일 주소의 소유자는 SNS 주제를 구독하라는 메시지를 받게 됩니다. Amazon SNS를 구독하려면 소유자가 메시지의 링크를 선택해야 합니다.

스택이 생성되면 스택의 출력 탭을 열고 EksCodeBuildkubeRoleARN 출력 키의 ARN 값을 기록합니다. 이 IAM ARN 값은 나중에 Amazon EKS 클러스터에서 워크로드를 배포할 권한을 IAM 역할에 제공할 CodeBuild 때 필요합니다.

AWS Security Hub 콘솔을 열고 통합으로 이동합니다.

Aqua Security를 검색하고 Aqua Security: Aqua Security를 선택합니다.

결과 수락을 선택합니다.

Amazon Linux 또는 MacOS 환경에서 cf_templates/kube_aws_auth_configmap_patch.sh 쉘 스크립트를 엽니다.

다음 명령을 실행하여 Amazon EKS 클러스터를 인증합니다.

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

이전에 기록한 ARN 값 EksCodeBuildkubeRoleARN으로 <rolearn-eks-codebuild-kubectl>을 대체하여 다음 명령을 사용하여 쉘 스크립트를 실행합니다.

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 이미지 취약성을 식별합니다. 이 예시에서는 도커 이미지 취약성에 대한 파이프라인 장애를 만들지 않았습니다. buildspec/buildspec.yml 파일에서 trivy 명령에는 값이 0 포함된 플래그 --exit-code 가 포함되어 있기 때문에 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

HIGH, CRTICAL 취약성이 보고될 때 파이프라인이 실패하도록 하려면 --exit-code의 값을 1로 변경하십시오.

그러면 개발자 또는 엔지니어가 취약성을 수정하고 소스 코드 리포지토리에 변경 내용을 커밋할 수 있습니다. CodeCommit

qua Security Trivy에서 보고한 도커 이미지 취약점은 Security Hub에 업로드됩니다. AWS Security Hub 콘솔에서 조사 결과로 이동합니다. 검색 결과를 레코드 상태 = 활성, 제품 = Aqua Security로 필터링합니다. 여기에는 Security Hub의 도커 이미지 취약성이 나열됩니다. Security Hub에 취약점이 나타나는 데 15분에서 1시간이 걸릴 수 있습니다.

빌드 단계가 완료되면 배포 승인 게이트가 있습니다. 검토자 또는 릴리스 관리자는 빌드를 검사하고 모든 요구 사항이 충족되면 승인해야 합니다. 이는 애플리케이션 배포를 위해 지속적 딜리버리를 사용하는 팀에 권장되는 접근 방식입니다.

승인 후 파이프라인은 배포 단계를 시작합니다.

배포 단계가 성공하면 이 단계의 CodeBuild 로그에 애플리케이션의 URL이 제공됩니다. URL을 사용하여 애플리케이션의 준비 상태를 검증할 수 있습니다.