AWS EKS - GitOps - Flux

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 7주차
# EKS Workshop 참고

✅ GitOps

• GitOps는 소프트웨어 배포 및 인프라 관리 방법론 중 하나로, Git을 사용하여 애플리케이션 및 인프라의 상태를 관리하는 방식입니다. 이를 통해 개발자와 운영팀은 Git을 통해 애플리케이션 코드, 설정 및 인프라 구성을 추적하고 관리하여 일관된 상태로 유지할 수 있습니다.
• Git을 사용하여 소프트웨어와 인프라에 대한 모든 정보를 저장하고 관리합니다. 애플리케이션의 상태를 설명하는 모든 것(코드, 설정, 인프라)은 Git 리포지토리에 커밋됩니다. 그런 다음 CI/CD 파이프라인과 GitOps 도구가 이 리포지토리를 모니터링하고 변경 사항을 감지하여 클러스터 또는 인프라에 적용합니다.
• 변경 사항이 발생할 때마다 인프라나 애플리케이션의 상태를 수동으로 조작하는 대신 GitOps 시스템이 이를 자동으로 처리한다

  

---

✅ Flux

• Flux는 Kubernetes 클러스터의 애플리케이션 배포를 자동화하기 위한 도구입니다.
• Flux는 GitOps 방식을 구현하는 데 사용되며, Git 리포지토리에 저장된 Kubernetes manifest 파일을 기반으로 클러스터를 관리합니다.
  1. Git 리포지토리 연동: Flux는 Git 리포지토리와 연동하여 Kubernetes 클러스터의 상태를 Git에 저장된 manifest 파일과 동기화합니다.
  2. 자동화된 배포: Git 리포지토리에 변경 사항이 발생하면 Flux가 이를 감지하고 자동으로 Kubernetes 클러스터에 변경 사항을 반영하여 애플리케이션을 배포합니다.
  3. 상태 추적 및 롤백: Flux는 클러스터의 상태를 지속적으로 추적하여 상태가 원하는 상태와 일치하지 않을 때 경고를 발생시키고, 필요한 경우 이전 상태로 롤백할 수 있는 기능을 제공합니다.
  4. 다양한 배포 전략 지원: Flux는 다양한 배포 전략을 지원하여 롤아웃 전략, 버전 관리, Canary 배포 등을 구현할 수 있습니다.
  5. 안정성과 신뢰성: GitOps 방식을 통해 Flux를 사용하면 변경 사항을 추적하고, 롤백 및 재배포를 통해 안정적이고 신뢰성 있는 배포 프로세스를 구축할 수 있습니다.

Flux는 Kubernetes 클러스터의 애플리케이션 배포를 자동화하고 GitOps 원칙을 준수하여 애플리케이션 배포의 안정성과 신뢰성을 향상시키는 도구

---

✅ 실습준비

• AWS CodeCommit 리포지토리 만들기
• CodeCommit 리포지토리에 대한 액세스 권한이 있는 IAM 사용자 만들기
• 샘플 애플리케이션 UI 구성 요소에 대한 지속적 통합 파이프라인 만들기

---

✅ AWS 코드 커밋에 액세스

• 실습 환경에서 AWS CodeCommit 리포지토리가 생성되었지만 Cloud9에서 연결하기 전에 몇 가지 단계를 완료해야 합니다.
• known hosts 파일에 CodeCommit용 SSH 키를 추가하여 나중에 경고를 방지할 수 있습니다:

• 그리고 Git이 커밋에 사용할 ID를 설정할 수 있습니다:

 

✅ 클러스터 부트스트랩

• Flux의 "Cluster bootstrap"은 Flux를 처음부터 클러스터에 설치하고 구성하는 프로세스를 가리킵니다. 이 프로세스는 GitOps 워크플로를 구축하기 위한 첫 번째 단계이며, 클러스터에 Flux를 설치하고 초기 구성을 수행하여 GitOps 작업을 시작하는 것을 목표로 합니다.
• 부트스트랩 프로세스는 클러스터에 Flux 구성 요소를 설치하고 리포지토리 내에 관련 파일을 생성하여 Flux로 GitOps를 사용하여 클러스터 개체를 관리합니다.

• Flux의 클러스터 부트스트래핑 프로세스
  1. Flux 설치: 먼저 클러스터에 Flux를 설치합니다. 이를 위해 Flux의 컴포넌트를 클러스터에 배포하고 시작해야 합니다. 대개는 Helm을 사용하여 Flux Helm 차트를 이용하여 이를 수행합니다.
  2. Flux 구성: Flux는 클러스터와 Git 리포지토리 간의 연결을 설정해야 합니다. 이 과정에서 Flux에게 어떤 Git 리포지토리를 사용할지, 어떤 경로에 있는 Kubernetes manifest 파일을 사용할지 등을 지정합니다.
  3. SSH 키 등록: Flux는 Git 리포지토리에 액세스하기 위해 SSH 키를 사용할 수 있습니다. 따라서 Flux가 Git 리포지토리에 액세스할 수 있도록 SSH 키를 등록해야 합니다.
  4. GitOps 워크플로 구성: 클러스터 부트스트래핑 과정에서는 GitOps 워크플로를 설정합니다. 이는 Git 리포지토리의 변경 사항이 자동으로 클러스터에 반영되도록 하는데 필요한 모든 구성과 프로세스를 설정하는 것을 의미합니다.

• 클러스터를 부트스트랩하기 전에 Flux는 모든 것이 올바르게 설정되었는지 확인하기 위해 사전 부트스트랩 검사를 실행할 수 있습니다. 다음 명령을 실행하여 Flux CLI에서 검사를 수행하세요:

• 이제 CodeCommit 리포지토리를 사용하여 EKS 클러스터에서 Flux를 부트스트랩해 보겠습니다:

• 먼저 Flux에 상태를 저장하는 데 사용할 Git 리포지토리를 알려줍니다.
• 그 후, 동일한 Git 저장소에 여러 개의 브랜치가 있는 패턴이 있으므로 이 Flux 인스턴스가 사용할 Git 브랜치를 전달합니다.
• 마지막으로 Flux용 SSH를 사용하여 /home/ec2-user/gitops_ssh.pem 에서 SSH 키를 사용하여 연결하고 인증합니다.
• 다음 명령을 실행하여 부트스트랩 프로세스가 성공적으로 완료되었는지 확인해 보겠습니다:
• Flux가 기본 사용자 정의가 생성되었으며 클러스터와 동기화되어 있음을 보여줍니다.

1. NAME: Kustomization의 이름을 나타냅니다. Kustomization은 Kubernetes 애플리케이션을 정의하는 Kustomize의 구성 파일입니다. 여기서는 "flux-system"이라는 Kustomization이 보입니다.
2. REVISION: Kustomization이 적용된 Git 리포지토리의 리비전을 나타냅니다. 여기서는 "main@sha1:dba4fa68"로 표시되는데, 이는 Git 리포지토리의 "main" 브랜치에서 해당 리비전(해시 값이 "dba4fa68"인)을 가리킵니다.
3. SUSPENDED: Kustomization이 일시 중단되었는지 여부를 나타냅니다. "False"는 일시 중단되지 않았음을 나타내며, "True"는 일시 중단되었음을 나타냅니다.
4. READY: Kustomization이 현재 준비된 상태인지 여부를 나타냅니다. "True"는 준비된 상태를 의미하며, "False"는 준비되지 않은 상태를 의미합니다.
5. MESSAGE: Kustomization의 상태 메시지를 나타냅니다. 여기서는 "Applied revision: main@sha1:dba4fa68"로 표시되는데, 이는 해당 리비전이 성공적으로 적용되었음을 나타냅니다.

---

✅ 애플리케이션 배포 

• 클러스터에서 Flux를 성공적으로 부트스트랩했으므로 이제 애플리케이션을 배포할 수 있습니다. 애플리케이션의 GitOps 기반 배포와 다른 방법의 차이점을 보여주기 위해, 현재 kubectl apply -k 접근 방식을 사용하고 있는 샘플 애플리케이션의 UI 구성 요소를 새로운 Flux 배포 방식으로 마이그레이션해 보겠습니다.
• 먼저 기존 UI 컴포넌트를 제거하여 이를 대체할 수 있도록 하겠습니다:

• 다음으로, 이전 섹션에서 Flux를 부트스트랩하는 데 사용한 리포지토리를 복제합니다:

• 이제 복제된 리포지토리로 이동하여 GitOps 구성 만들기를 시작하겠습니다. UI 서비스에 대한 기존 kustomize 구성을 복사합니다:

• 그런 다음 앱 디렉토리에 사용자 정의 항목을 만들어야 합니다.
• ~/environment/eks-workshop/modules/automation/gitops/flux/apps-kustomization.yaml

• 이 파일을 Git 리포지토리 디렉터리에 복사합니다:

• 변경 사항을 푸시하기 전 마지막 단계는 Flux가 앱 디렉토리를 인식하도록 하는 것입니다. 이를 위해 flux 디렉터리에 추가 파일을 생성합니다:
• ~/environment/eks-workshop/modules/automation/gitops/flux/flux-kustomization.yaml

• 이 파일을 Git 리포지토리 디렉터리에 복사합니다:

• 이제 Git 디렉터리가 다음과 같이 표시되며 트리 ~/environment/flux 를 실행하여 유효성을 검사할 수 있습니다:

• 마지막으로 설정을 CodeCommit에 푸시할 수 있습니다:

• Flux가 CodeCommit의 변경 사항을 알아차리고 조정하는 데는 다소 시간이 걸립니다. Flux CLI를 사용하여 새로운 앱 커스터마이징이 나타나는지 확인할 수 있습니다:

• 다음과 같이 수동으로 Flux를 트리거하여 조정할 수도 있습니다:

• 이제 UI 서비스와 관련된 모든 리소스가 한 번 더 배포되었을 것입니다. 확인하려면 다음 명령을 실행합니다:

• 이제 Flux를 사용하여 배포하도록 UI 구성 요소를 성공적으로 마이그레이션했으며, Git 리포지토리에 푸시된 모든 추가 변경 사항은 자동으로 EKS 클러스터로 조정됩니다.

✅ 지속적 통합 및 GitOps

• EKS 클러스터에서 Flux를 성공적으로 부트스트랩하고 애플리케이션을 배포했습니다. 
• 애플리케이션의 소스 코드를 변경하고, 새 컨테이너 이미지를 빌드하고, GitOps를 활용하여 클러스터에 새 이미지를 배포하는 방법을 시연하기 위해 지속적 통합 파이프라인을 소개합니다. 
• AWS 개발자 도구와 DevOps 원칙을 활용하여 Amazon ECR용 멀티 아키텍처 컨테이너 이미지를 빌드합니다.
• 환경 준비 단계에서 지속적 통합 파이프라인을 만들었으므로 이제 이를 구성하고 실행해야 합니다.

  

• 먼저 애플리케이션 소스에 대한 CodeCommit 리포지토리를 복제합니다:

• 그런 다음, 샘플 애플리케이션의 공개 리포지토리에 있는 소스로 CodeCommit 리포지토리를 채웁니다:

• AWS CodeBuild를 사용하고 buildspec.yml을 정의하여 새로운 x86_64 및 arm64 이미지를 병렬로 빌드합니다.
• ~/environment/eks-workshop/modules/automation/gitops/flux/buildspec.yml

• buildspec-manifest.yml 을 사용하여 멀티 아키텍처 이미지에 대한 이미지 인덱스를 빌드하는 데에도 AWS CodeBuild를 사용합니다.
• ~/environment/eks-workshop/modules/automation/gitops/flux/buildspec-manifest.yml

• 이제 코드 커밋에 변경 사항을 푸시하고 코드 파이프라인을 시작할 준비가 되었습니다.

• AWS 콘솔에서 CodePipeline으로 이동하여 eks-workshop-retail-store-sample 파이프라인을 탐색할 수 있습니다:

• CodeBuild로 코드파이프라인을 실행한 결과 ECR에 새 이미지가 생성됩니다.

• Flux 이미지 자동화 컨트롤러를 사용하여 Git에 대한 이미지 업데이트를 자동화해 보겠습니다.
• 먼저 Flux 컴포넌트를 설치해야 합니다.

• 그런 다음 deployment.yaml 파일을 편집하고 새 컨테이너 이미지 URL에 대한 플레이스홀더를 추가합니다:

• 이러한 변경 사항을 deployment 에 커밋합니다:

• ECR에서 새 컨테이너 이미지를 모니터링하고 GitOps를 사용하여 자동화된 배포를 활성화하려면 Flux용 사용자 정의 리소스 정의(ImageRepository, ImagePolicy, ImageUpdateAutomation)를 배포해야 합니다.
• ~/environment/eks-workshop/modules/automation/gitops/flux/imagerepository.yaml

• ~/environment/eks-workshop/modules/automation/gitops/flux/imagepolicy.yaml

• ~/environment/eks-workshop/modules/automation/gitops/flux/imageupdateautomation.yaml

• 이러한 파일을 애플리케이션 저장소에 추가하고 적용합니다:

• 다음과 같은 아키텍처를 만들었습니다:

  

• 이제 변경 사항을 조정해 보겠습니다.

• 배포에서 이미지가 새 태그로 업데이트된 것을 확인할 수 있습니다.

• 브라우저를 사용하여 UI에 액세스하려면 다음 매니페스트가 포함된 Ingress 리소스를 생성하여 노출해야 합니다:
• ~/environment/eks-workshop/modules/automation/gitops/flux/ci-ingress/ingress.yaml

• 이렇게 하면 AWS 로드 밸런서 컨트롤러가 애플리케이션 로드 밸런서를 프로비저닝하고 트래픽을 UI 애플리케이션의 파드로 라우팅하도록 구성합니다.

• 생성된 인그레스 객체를 살펴보겠습니다:

• 애플리케이션 로드 밸런서가 프로비저닝될 때까지 2~5분 정도 기다렸다가 인그레스의 URL을 사용하여 UI 페이지를 확인합니다.

• 샘플 애플리케이션의 소스 코드에 대한 변경 사항을 소개하겠습니다.

 

• 24줄 변경
• <a class="navbar-brand" href="/home">Retail Store Sample</a>
  • <a class="navbar-brand" href="/home">Retail Store Sample New</a>
• 변경 사항을 커밋합니다.

• 코드파이프라인 실행이 완료될 때까지 기다립니다

• 그런 다음 Flux를 트리거하여 새 이미지가 조정되는지 확인할 수 있습니다

• Git 리포지토리를 가져오면 로그에서 변경된 내용을 볼 수 있습니다

• 마찬가지로 CodeCommit 커밋 보기에도 활동이 표시됩니다

• 또한 파드를 확인하여 이미지가 업데이트되었는지 확인할 수 있습니다