K8s
  • Amazon EKS
  • 1.EKS 환경 구성
    • IDE 환경 구성
    • 인증/자격증명 및 환경 구성
  • 3.VPC구성과 eksctl 기반 설치
    • Cloudformation 구성
    • eksctl 구성
    • EKS 구성확인
  • 4.EKS Service 이해
    • Cluster IP 기반 배포
    • NodePort 기반 배포
    • Loadbalancer 기반 배포
  • 5.EKS Ingress
    • AWS Load Balancer Controller
  • 6.EKS 기반 관리
    • 패키지 관리 - Helm
    • 고가용성 Health Check 구성
    • 고가용성 Health Check 구성 (작업중)
    • Assign
    • 테인트와 톨러레이션
    • Pod 오버헤드 (Pod Overhead)
  • 7.Scheduling
    • 스케쥴링 - AutoScaling 구성
    • 스케쥴링-Karpenter
      • Basic Node Pool
        • Scaling Application
        • Limit Resources
        • Disruption
        • Drift
        • RightSizing
      • Multi NodePools
        • Team Based NodePool
        • Weighting NodePool
      • Cost Optimization
        • Consolidation
          • Single Node Consolidation
          • Multi Node Consolidation
          • Using Spot Instance
          • Spot to Spot Consolidation
        • Using Graviton
        • On-Demand & Spot Ratio Split
      • Scheduling Constraints
        • Node Affinity
        • Taints and Toleration
        • Topology Spread
        • Pod Affinity
        • Persistence Volume Topology
        • Pod Disruption Budget
        • Disruption Control
        • NodePool Disruption Budgets
        • Instance type and AZ
        • Multi-Arch
      • Control Pod Density
        • Static Pod Density
        • Dynamic Pod Density
        • Restrict Instance Type
      • EC2 Node Class
        • EC2 Node Classes
        • Custom AMI
        • Node Volumes
      • Observability
      • Migrating from Cluster Autoscaler
        • Install Cluster AutoScaler (CAS)
        • AutoScaling using Cluster AutoScaler (CAS)
        • Migrate from CAS to Karpenter
    • 스케쥴링-Karpenter (Old)
    • EKS Fargate (New)
    • EKS Fargate (old)
  • 8.Observability
    • K8s Dashboard 배포
    • Prometheus-Grafana
    • EFK기반 로깅
    • Container Insights
    • X-Ray기반 추적
    • Loki
  • 9. EKS Networking
    • Multus
    • VPC Advanced
    • External SNAT (TBD)
  • 10.EKS Storage
    • 볼륨/CSI
    • Stateful Container-EBS
    • Stateful Container-EFS
  • 11.EKS Security
    • 이미지 보안
    • OPA Gatekeeper
    • Kyverno
    • RBAC
    • IAM 그룹 기반 관리
    • IRSA (IAM Roles for Service Account)
    • Pod Security (TBD)
    • KMS 기반 암호화 (TBD)
    • Calico 네트워크 정책
  • 12.EKS CI/CD
    • Code Pipeline기반 CI/CD
    • Jenkins 기반 CI
    • WEAVE Flux 기반 GitOps (TBD)
    • Argo 기반 CD
    • Github Action & ArgoCD 기반 CI/CD
  • 13.EKS Service Mesh
    • Istio
      • Istio 소개
      • istio 설치와 구성
      • istio 트래픽 관리 1
      • istio 모니터링
      • Page 1
    • App Mesh (TBD)
  • Tip
    • Kubernetes 개념
      • Overview
      • Cluster Architecture
        • 노드
        • 컨트롤플레인과 노드간 통신
        • 컨트롤러
        • 클라우드 컨트롤러 매니저
      • Containers
        • 이미지
        • 컨테이너 소개
        • 런타임클래스
        • 컨테이너 환경변수
        • 컨테이너 라이프사이클 훅
      • Workloads
        • Pod
          • Pod 개요
          • Pod
          • Pod LifeCycle
          • 컨테이너 초기화
          • Pod 프리셋
          • 파드 토폴로지 분배 제약 조건
          • Untitled
        • Controller
      • Service-LB-Networking
      • Storage
      • Configuration
      • Security
      • Policies
      • Scheduling and Eviction
      • Cluster Admin
      • Extending Kubernetes
    • shell
    • git_source
    • aws cli
    • eksctl command
    • kubectl Command
    • helm command
    • Useful URL
Powered by GitBook
On this page
  • CI/CD 소개
  • Role 구성
  • 1. IAM Role 생성
  • 2. aws-auth configmap 적용
  • Repo 구성
  • 3.Sample Repo 포크
  • 4. Github access token 구성
  • CodePipeline 구성
  • 5. Codepipeline 구성
  • 6.Codepipeline 확인
  • 7. 신규 버전 배포

Was this helpful?

  1. 12.EKS CI/CD

Code Pipeline기반 CI/CD

Update : 2024-04-10

Previous12.EKS CI/CDNextJenkins 기반 CI

Last updated 1 year ago

Was this helpful?

CI/CD 소개

CI( 지속적 통합) 및 CD( 지속적 전달)는 민첩성을 요구하는 조직에 필수적입니다. 팀은 개별 변경을 자주 수행하고 프로그래밍 방식으로 해당 변경 사항을 릴리스하고 중단 없이 업데이트를 제공할 수 있을 때 생산성이 더 높아집니다. 이 모듈에서는 AWS CodePipeline을 사용하여 CI/CD 파이프라인을 구축합니다. CI/CD 파이프라인은 샘플 Kubernetes 서비스를 배포하고 GitHub 리포지토리를 변경하고 이 변경 사항이 클러스터에 자동으로 전달되는 것을 확인합니다.

Role 구성

1. IAM Role 생성

AWS CodePipeline에서는 AWS CodeBuild를 사용하여 샘플 Kubernetes 서비스를 배포합니다. 이를 위해서는 EKS 클러스터와 상호 작용할 수 있는 AWS Identity and Access Management(IAM) 역할이 필요합니다.

이 단계에서는 IAM 역할을 생성하고, kubectl을 통해 EKS 클러스터와 상호 작용하기 위해 CodeBuild 단계에서 사용할 인라인 정책을 추가합니다.

IAM Role을 생성합니다.

cd ~/environment
TRUST="{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::${ACCOUNT_ID}:root\" }, \"Action\": \"sts:AssumeRole\" } ] }"
echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:Describe*", "Resource": "*" } ] }'
echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:Describe*", "Resource": "*" } ] }' > /tmp/iam-role-policy
aws iam create-role --role-name EksWorkshopCodeBuildKubectlRole --assume-role-policy-document "$TRUST" --output text --query 'Role.Arn'
aws iam put-role-policy --role-name EksWorkshopCodeBuildKubectlRole --policy-name eks-describe --policy-document file:///tmp/iam-role-policy

2. aws-auth configmap 적용

ConfigMap에 이 새 Role이 포함되면 파이프라인의 CodeBuild 단계에 있는 kubectl이 IAM 역할을 통해 EKS 클러스터와 상호 작용할 수 있습니다.

aws-auth configmap을 확인해 봅니다.

kubectl get -n kube-system configmap/aws-auth -o yaml

IAM Role이 생성되었으므로 EKS 클러스터에 대한 aws-auth ConfigMap에 Role을 추가합니다.

ROLE="    - rolearn: arn:aws:iam::${ACCOUNT_ID}:role/EksWorkshopCodeBuildKubectlRole\n      username: build\n      groups:\n        - system:masters"
kubectl get -n kube-system configmap/aws-auth -o yaml | awk "/mapRoles: \|/{print;print \"$ROLE\";next}1" > /tmp/aws-auth-patch.yml
kubectl patch configmap/aws-auth -n kube-system --patch "$(cat /tmp/aws-auth-patch.yml)"

[참고] 아래와 같은 kubectl 명령으로 직접 수정할 수도 있습니다. (옵션)

kubectl edit -n kube-system configmap/aws-auth

aws-auth configmap을 다시 확인해 보고 Role이 추가 되었는지 확인합니다 .

kubectl get -n kube-system configmap/aws-auth -o yaml

결과 예

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::011218731119:role/EksWorkshopCodeBuildKubectlRole
      username: build
      groups:
        - system:masters

Repo 구성

3.Sample Repo 포크

리포지토리를 수정하고 빌드를 트리거할 수 있도록 샘플 Kubernetes 서비스를 분기합니다.

GitHub에 로그인하고 샘플 서비스를 자신의 계정으로 분기합니다.

먼저 각자의 Github 계정으로 먼저 로그인하고, 아래 Repo로 이동합니다.

Sample repo

https://github.com/whchoi98/eks-workshop-sample-api-service-go

아래와 같이 이동한 Repo에서 Fork 를 수행합니다.

자신의 계정으로 분기된 Repo는 아래와 같습니다.

4. Github access token 구성

CodePipeline이 GitHub에서 Callback을 수신하려면 개인 액세스 토큰을 생성해야 합니다.

일단 생성되면 액세스 토큰을 보안 영역에 저장하고 재사용할 수 있으므로 이 단계는 처음 실행하는 동안이나 새 키를 생성해야 할 때만 필요합니다.

개인 Github 계정에서 "settings"를 선택합니다.

Profile 메뉴 하단의 "Developer settings"를 선택합니다.

  • Note - "eks-workshop"

  • repo를 선택합니다

  • 하단의 Generate token을 선택합니다.

personal access token 생성을 확인하고, 복사해 둡니다.

CodePipeline 구성

5. Codepipeline 구성

AWS CloudFormation을 사용하여 AWS CodePipeline을 생성합니다.

CloudFormation은 AWS 클라우드 환경의 모든 인프라 리소스를 설명하고 프로비저닝할 수 있는 공통 언어를 제공하는 코드형 인프라(IaC) 도구입니다. CloudFormation을 사용하면 간단한 텍스트 파일을 사용하여 모든 지역 및 계정에서 애플리케이션에 필요한 모든 리소스를 자동화되고 안전한 방식으로 모델링하고 프로비저닝할 수 있습니다.

각 EKS 배포/서비스에는 고유한 CodePipeline이 있어야 하며, 격리된 소스 리포지토리에 있어야 합니다.

이 워크샵과 함께 제공되는 CloudFormation 템플릿을 수정하고 시스템 요구 사항을 충족하여 EKS 클러스터에 새 서비스를 쉽게 적용 할 수 있습니다. 각각의 새로운 서비스에 대해 다음 단계를 반복할 수 있습니다.

Cloudformation - 스택생성 - 새 리소스 사용 (표준) 을 선택합니다.

아래 S3 URL을 입력합니다.

https://s3.amazonaws.com/eksworkshop.com/templates/main/ci-cd-codepipeline.cfn.yml
  • 스택 이름 : eksworkshop-codepipeline

  • Username : github 계정

  • Access Token : Github Access token 값

  • Repository : eks-workshop-sample-api-service-go

  • Branch: master

  • Codebuilde dockerimage : aws/codebuild/standard:4.0

  • IAM kubectl IAM Role : EksWorkshopCodeBuildKubectlRole

  • EKS cluster name: eksworkshop

다음 단계를 계속 진행해서 , Cloudformation을 완료합니다.

1분 후에 Cloudformation Stack 이 완성됩니다. (Stack Name : eksworkshop-codepipeline)

6.Codepipeline 확인

관리 콘솔에서 CodePipeline을 엽니다.

AWS 관리콘솔 - CodePipeline

eks-workshop-codepipeline으로 시작하는 CodePipeline이 표시됩니다. 이 링크를 클릭하면 세부 정보를 볼 수 있습니다.

Codepipeline에서 진행중이거나, 완료된 Pipeline을 선택하면 Build 상태를 확인 할 수 있습니다.

5분 정도 이후에, kubectl을 통해서 정상적인 배포가 이뤄졌는지 확인해 봅니다.

kubectl describe deployment hello-k8s
kubectl describe service hello-k8s
kubectl get services hello-k8s -o wide
kubectl get svc hello-k8s | tail -n 1 | awk '{ print "hello-k8s URL = http://"$4"" }'

7. 신규 버전 배포

Application의 신규 버전을 배포해 봅니다.소스 Github Repo에서 새롭게 변경하고, 배포를 합니다.

개인 계정에서 fork된 Github의 소스에서 go 파일을 변경합니다.

https://github.com/개인계정/eks-workshop-sample-api-service-go

Commit Changes에서 Commit을 합니다.

GitHub에서 변경 사항을 수정하고 커밋하면 약 1분 안에 AWS Management Console CodePipeline에서 트리거된 새 빌드가 실행되는 것을 볼 수 있습니다.

Build 상태를 통해서 , 빌드의 상세사항을 확인 할 수 있습니다.

kubectl 명령을 통해 Service URL을 확인하고, 업데이트 현황을 확인합니다.

kubectl get services hello-k8s -o wide

아래는 변경된 메세지가 포함된 결과입니다.

Jenkins 기반 CI 랩을 수행하기 위해서, 아래 작업을 통해 Codepipeline을 삭제합니다.

kubectl delete pods hello-k8s-86cffd459c-xxxxx
kubectl delete svc hello-k8s

Continuous integration
continuous delivery