Kubernetes (AWS EKS) 및 Jenkins로 미래의 CI / CD 구축

이 자습서에서는 Cloudify.co 의 DevOps 엔지니어로서 Kubernetes (AWS EKS)에서 CI / CD를 만들고 Jenkins 및 스팟 인스턴스를 클러스터의 작업자 노드로 사용하는 경험을 공유 합니다.

미래의 CI / CD 구축 튜토리얼은 이미 게시 된 게시물 :

  • 모범 사례를 사용하여 클러스터 용 AWS에서 VPC를 생성하는 방법
  • EKS 클러스터의 아키텍처, 생성 된 VPC를 기반으로 EKS 클러스터를 생성하는 방법, 고 가용성 및 내결함성을 제공하는 방법, 스팟 인스턴스를 클러스터의 작업자 노드로 사용하는 방법
  • 워크로드를 실행하는 데 필요한 노드 그룹 (AWS 자동 확장 그룹) 수.
  • 'Cluster Autoscaler'를 사용하여 부하에 따라 클러스터를 동적으로 확장하는 방법
  • EKS 클러스터 용 Ingress Nginx를 설치하고 구성하는 방법
  • Ingress 진입 점을 가리키는 route53을 사용하여 DNS 레코드를 만듭니다.
  • CertManager 및 Let 's Encrypt 인증서를 사용하는 EKS 클러스터에 대한 'cert-manager'를 설치하고 구성하는 방법
  • Helm을 사용하여 Jenkins를 설치하는 방법
  • Jenkins 마스터에 영구 볼륨을 연결하는 방법
  • Jenkins에 대한 백업을 구성하는 방법
  • Jenkins 및 모범 사례를 보호하는 방법
  • 우리가 사용하는 일반 Jenkins 플러그인
  • Jenkins에서 k8s 클러스터에 액세스하기 위해 서비스 계정을 만들고 자격 증명을 구성하는 방법
  • Jenkins에서 첫 번째 파이프 라인 작업을 생성하고 Kubernetes 플러그인을 사용하는 방법

하지만 실제로 시작하기 전에 Pull Request와 같은 몇 가지 용어를 설명하고 개발 프로세스에서 왜 사용합니까? CI 란 무엇이며 해결하려는 문제는 무엇입니까?

Pull Request는 무엇이며 개발 과정에서 사용 된 이유는 무엇입니까?

풀 요청을 사용하면 GitHub의 저장소에있는 브랜치에 푸시 한 변경 사항을 다른 사람에게 알릴 수 있습니다. 풀 리퀘스트가 열리면 공동 작업자와 잠재적 인 변경 사항을 논의하고 검토하고 변경 사항이 기본 브랜치에 병합되기 전에 후속 커밋을 추가 할 수 있습니다.

https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

  • 모든 사람의 코드 기반을 실제로 파괴하기 전에 프로세스 초기에 주요 변경 사항을 감지합니다.
  • 다른 동료가 검토 할 수 있도록 코드를 게시하여 코드의 품질을 보장합니다.
  • 다른 개발자가 다른 관점에서 논리를 검증합니다.

코드 커밋 후 지속적 통합에서는 소프트웨어가 즉시 빌드되고 테스트됩니다. 개발자가 많은 대규모 프로젝트에서는 하루에 여러 번 커밋이 이루어집니다. 각 커밋 코드가 빌드되고 테스트됩니다. 테스트를 통과하면 배포를 위해 빌드가 테스트됩니다. 배포가 성공하면 코드가 프로덕션으로 푸시됩니다. 이 커밋, 빌드, 테스트 및 배포는 지속적인 프로세스이므로 지속적인 통합 / 배포라고합니다.

https://www.guru99.com/jenkin-continuous-integration.html

CI가 왜 필요한가요?

빌드하는 코드의 유효성을 검사하려면 생산을 중단하지 마십시오.

  • Pull Request의 일부로 브랜치에 대한 모든 푸시에서 단위 테스트 실행
  • Pull Request의 일부로 브랜치로 푸시 할 때마다 통합 테스트 실행
  1. Pull Request가 생성되었습니다.
  2. Github의 웹훅이 트리거 됨
  3. 빌드는 Jenkins에서 실행됩니다.
  4. PR에서받은 빌드 상태

또한 Jenkins CI, 다중 브랜치 파이프 라인 및 autostatus 플러그인을 사용하는 Github의 내 게시물, Perfect PR 프로세스 를 읽어 보는 것이 좋습니다.

Jenkins와 같은 CI를 사용하여 다중 분기 파이프 라인 및 자동 상태 플러그인으로 PR 프로세스를 구축하는 방법을 자세히 설명합니다.

Jenkins는 무엇입니까?

Jenkins는 소프트웨어 빌드, 테스트, 제공 또는 배포와 관련된 모든 종류의 작업을 자동화하는 데 사용할 수있는 독립형 오픈 소스 자동화 서버입니다. https://jenkins.io/doc/

Amazon EKS 란 무엇입니까?

Amazon Elastic Kubernetes Service (Amazon EKS)는 자체 Kubernetes 제어 플레인을 세우거나 유지 관리 할 필요없이 AWS에서 Kubernetes를 쉽게 실행할 수있게 해주는 관리 형 서비스입니다. Kubernetes는 컨테이너화 된 애플리케이션의 배포, 확장 및 관리를 자동화하기위한 오픈 소스 시스템입니다.

Amazon EKS는 고 가용성을 보장하기 위해 여러 가용 영역에서 Kubernetes 제어 플레인 인스턴스를 실행합니다. Amazon EKS는 비정상적인 제어 플레인 인스턴스를 자동으로 감지하고 교체하며 이에 대한 자동 버전 업그레이드 및 패치를 제공합니다.

https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html

이 자습서에서 구축 한 EKS 클러스터의 아키텍처

  • Amazon EKS는 단일 장애 지점으로부터 보호하기 위해 두 개의 AZ에서 두 개의 마스터로 K8을 자동으로 실행합니다.
  • 이 다중 AZ 아키텍처는 AWS 가용 영역 손실에 대한 복원력을 제공합니다.
  • EKS는 마스터 노드를 처리합니다.
  • 자가 치유 제어 플레인이므로 마스터 노드에 대한 모니터링 / 경고가 필요하지 않습니다.
  • 일반적으로 AWS 서비스와 매우 잘 통합됩니다.

EKS와 함께 스팟 인스턴스를 사용하는 이유는 무엇입니까?

애플리케이션의 성능이나 가용성을 저하시키지 않고 EC2 온 디맨드 가격을 최대 90 % 할인합니다.

스팟 인스턴스와 관련된 EKS의 구성 요소

  • 다양한 노드 그룹 (자동 확장 그룹)은 유사한 스팟 인스턴스로 구성된 AZ를 교차합니다.
  • 클러스터의 부하에 따라 스팟 인스턴스 노드 그룹의 크기를 자동으로 조정하는 구성 요소 인 Cluster Autoscaler.

Ingress 는 클러스터 외부의 HTTP 및 HTTPS 경로를 클러스터 내의 서비스에 노출 합니다. 트래픽 라우팅은 Ingress 리소스에 정의 된 규칙에 의해 제어됩니다.

internet
|
[ Ingress ]
--|-----|--
[ Services ]

인 그레스는 서비스에 외부 적으로 연결할 수있는 URL, 부하 분산 트래픽, SSL / TLS 종료 및 이름 기반 가상 호스팅을 제공하도록 구성 될 수 있습니다. 인 그레스 컨트롤러 는 일반적으로로드 밸런서를 사용하여 인 그레스를 수행 할 책임이 있지만 트래픽을 처리하는 데 도움이되도록 에지 라우터 또는 추가 프런트 엔드를 구성 할 수도 있습니다.

https://kubernetes.io/docs/concepts/services-networking/ingress/

EKS 클러스터에서 사용될 NGINX Ingress Controller

ingress-nginx는 NGINX 를 역방향 프록시 및로드 밸런서로 사용하는 Kubernetes 용 Ingress 컨트롤러입니다 .

https://github.com/kubernetes/ingress-nginx

https://www.nginx.com/products/nginx/kubernetes-ingress-controller/

EKS 클러스터에서 Let 's Encrypt와 함께 Cert Manager 사용

cert-manager는 기본 Kubernetes 인증서 관리 컨트롤러입니다. Let 's Encrypt , HashiCorp Vault , Venafi , 단순 서명 키 쌍 또는 자체 서명 과 같은 다양한 소스에서 인증서를 발급하는 데 도움이 될 수 있습니다 .

인증서가 유효하고 최신 상태인지 확인하고 만료되기 전에 구성된 시간에 인증서 갱신을 시도합니다.

https://cert-manager.io/docs/

EKS 클러스터의 Jenkins 설치 및 구성

  • Jenkins 마스터는 특정 플러그인 세트와 함께 공개 helm 차트를 사용하여 설치됩니다.
  • 일일 백업은 s3 버킷과 함께 사용됩니다.
  • 영구 볼륨은 Jenkins의 데이터 / 구성을 저장하는 데 사용됩니다.
  • Jenkins는 HashiCorp의 Vault와 통합됩니다.
  • Kubernetes 플러그인은 k8s에서 Jenkins 동적 에이전트를 구성하고 사용하는 데 사용됩니다.

https://github.com/jenkinsci/kubernetes-plugin

Vault를 Jenkins에 통합하는 데 필요한 사항을 자세히 찾고 이해하려면 내 게시물을 읽으십시오. https://codeburst.io/read-vaults-secrets-from-jenkin-s-declarative-pipeline-50a690659d6

소개 부분에 대한 결론

모범 사례를 사용한 EKS 클러스터 생성, Jenkins 설치 및 구성과 같이 구축 할 CI / CD의 모든 구성 요소를 일반적으로 설명하려고했습니다. 이 튜토리얼의 다음 게시물에 대한 소개 일뿐입니다. 여기서는 각 구성 요소를 자세히 살펴보고 AWS 및 EKS 클러스터에서 VPC 생성을 시작으로 함께 구축 할 것입니다.

이 튜토리얼의 다음 게시물이 게시 될 때 알림을 받고 싶다면 여기 매체와 Twitter (@warolv) 에서 저를 팔로우하십시오 .

이 튜토리얼을 복제 할 개인 블로그 : http://igorzhivilo.com/,이 자습서에서 만든 모든 구성을 Github (warolv)에 저장 합니다.

읽어 주셔서 감사합니다. 즐거웠기를 바랍니다. 다음 게시물에서 뵙겠습니다.

참고 문헌

https://levelup.gitconnected.com/perfect-pr-process-on-github-with-jenkins-ci-multi-branch-pipeline-and-autostatus-plugin-33e1805dc619

https://codeburst.io/read-vaults-secrets-from-jenkin-s-declarative-pipeline-50a690659d6

https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

https://www.guru99.com/jenkin-continuous-integration.html

https://jenkins.io/doc/

https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html

https://kubernetes.io/docs/concepts/services-networking/ingress/

https://github.com/kubernetes/ingress-nginx

https://cert-manager.io/docs/

https://www.vaultproject.io/

https://github.com/jenkinsci/kubernetes-plugin

Suggested posts

AKS 성능 여정 : 1 부 — 모든 크기 조정

AKS 성능 여정 : 1 부 — 모든 크기 조정

2019 년과 2020 년 동안 ASOS Web 내의 저희 팀은 개선 된 서비스 밀도, 확장성에 대한 잠재력을 탐색하고 활용하기 위해 Azure Cloud Services의 일부 프런트 엔드 마이크로 서비스를 AKS (Azure Kubernetes Service)로 마이그레이션하는 여정을 시작했습니다. , 성능 및 애플리케이션 제어. ASOS의 주요 아키텍처 변경의 일환으로 일련의 게이트에서 새로운 설정을 면밀히 조사하여 고객에게 최상의 경험을 제공 할 수 있도록합니다.

첫 번째 Kubernetes 입학 웹훅 작성 시작하기 2 부 ✨

첫 번째 Kubernetes 입학 웹훅 작성 시작하기 2 부 ✨

이전 게시물에서 우리는 대부분 operator-sdk 도구를 사용하여 Kubernetes Admission Webhooks를 작성하는 것에 대해 이야기했고 사용자 지정 리소스 유형에 대해 첫 번째 Mutating Admission Webhook을 만들었습니다. 그러나 이번에는 Deployment, Pod 등과 같은 핵심 유형에 대해 "Validating"이라는 또 다른 유형의 Admission Webhook을 만들 것입니다.