느슨한 알림을 포함한 Github 작업을 사용하여 Kubernetes 배포

이 설명서에서는 Kubernetes에 배치되는 전체 주기 Github Actions 를 설명합니다.배터리는 다음과 같습니다.

Kubernetes 클러스터가 실행 중AWS EKS

에 저장된 Docker 이미지

보상:슬랙 알림

요청을 제출할 때마다 Github 워크플로가 트리거되며, 다음 단계에 대해 설명합니다.

git결산

AWS ECR 로그인(자격 증명 필요)

Docker 미러링 구축

Docker 이미지를 ECR로 푸시

EKS에 kubectl 구축

슬랙에 알림 보내기(webhook URL 필요)

AWS ECR
Github 작업
서류를 .github/workflows/release.yml 아래에 놓으세요.그런 다음 워크플로우 트리거 구성부터 시작합니다.

name: Release

on:
  pull_request:
    branches: [main]

이 트리거는 우리가 열면 바로 실행되며, 요청을 제출할 때마다 실행됩니다.
그런 다음 여러 단계에서 사용할 환경 변수를 정의합니다.

env:
  RELEASE_REVISION: "pr-${{ github.event.pull_request.number }}-${{ github.event.pull_request.head.sha }}"
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  AWS_REGION: ${{ secrets.AWS_REGION }}
  KUBE_CONFIG_DATA: ${{ secrets.KUBE_CONFIG_DATA }}
  KUBE_NAMESPACE: production
  ECR_REPOSITORY: my-cool-application
  SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

환경부는 다음과 같이 설명합니다.

RELEASE_REVISION: Docker 이미지

에 사용할 태그

AWS_ACCESS_KEY_ID | AWS_SECRET_ACCESS_KEY:

KUBE_CONFIG_DATA: configure aws credentials action

ECR_REPOSITORY: kubectl aws eks action

SLACK_WEBHOOK_URL: aws ecr action

이제 작업을 시작하고 다음 단계를 발표합니다.

jobs:                                            
  release:                                       
    name: Release                                
    runs-on: ubuntu-latest                       
    steps:                                       
     ... [steps be at this level]

slack notification action
단계 - 이전 실행 취소
이 단계는 Github에 이 저장소에서 이 작업의 현재 실행을 취소하도록 지시합니다.

- name: Cancel Previous Runs               
  uses: styfle/[email protected]
  with:                                    
    access_token: ${{ github.token }}      

단계 - 체크아웃
이 특정 제출 시git 서명을 실행합니다.

- name: Checkout                                  
  uses: actions/checkout@v2                       
  with:                                           
    ref: ${{ github.event.pull_request.head.sha }}

단계 - AWS 자격 증명 구성
이 단계에서는 env 섹션에 정의된 AWS 자격 증명을 사용합니다.

- name: Configure AWS credentials                          
  uses: aws-actions/configure-aws-credentials@v1           
  with:                                                    
    aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}        
    aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}
    aws-region: ${{ env.AWS_REGION }}

단계 - AWS ECR 로그인
이전 단계에서 구성한 AWS 자격 증명을 사용하여 AWS ECR에 로그인합니다.

- name: Login to Amazon ECR            
  id: login-ecr                        
  uses: aws-actions/amazon-ecr-login@v1

단계 - Docker buildx 캐시 설정
이 두 단계는 건축 이미지의 표현에 매우 중요하다.다음은 몇 가지 주요 고려 사항입니다.

Github 작업은 클라우드의 모든 CI 실행 프로그램과 마찬가지로 짧다. 이것은 새로운 작업 흐름 작업을 수행할 때마다 새로운 실례를 가상화한다는 것을 의미한다

이러한 잠정성 때문에 우리는 본 컴퓨터 Docker층 캐시에 의존할 수 없습니다

이러한 제한은 Dockerfile의 모든 계층이 구축을 평가하기 때문에 구축 시간을 매우 느리게 할 것입니다.
그러나 이것 덕분에 우리는 action 캐시 Docker층을 이용할 수 있다.그리고 결합buildkit CLI하면 우리는 이런 캐시 정책에 의존하여 구축 시간을 최적화할 수 있다.

- name: Set up Docker Buildx                             
  id: buildx                                             
  uses: docker/setup-buildx-action@master                
- name: Docker cache layers                              
  uses: actions/cache@v2                                 
  with:                                                  
    path: /tmp/.buildx-cache                             
    key: ${{ runner.os }}-single-buildx-${{ github.sha }}
    restore-keys: |                                      
      ${{ runner.os }}-single-buildx                     

native Github actions cache
단계 - 이미지를 레지스트리로 구축 및 푸시
이 단계는 구축 시간을 최적화하기 위해 buildx를 사용하여 Docker 이미지를 구축하고 AWS ECR로 전송하는 것을 포함한다. 이것은 이전에'아마존 ECR 로그인'에서 설정한 것이다.
이 예에서는 Dockerfile에 "release"라는 대상이 있다고 가정합니다.

- name: Build & Push Image                                                                                      
  env:                                                                                                          
    ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}                                                       
    RELEASE_IMAGE: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.RELEASE_REVISION }}
  run: |
    docker buildx create --use

    docker buildx build \                                
      --cache-from=type=local,src=/tmp/.buildx-cache \   
      --cache-to=type=local,dest=/tmp/.buildx-cache-new \
      --tag ${{ env.RELEASE_IMAGE }} \                           
      --target release \                                 
      --push \                                           
      .                                                  

    rm -rf /tmp/.buildx-cache
    mv /tmp/.buildx-cache-new /tmp/.buildx-cache

단계 설명:

docker buildx create --use:buildx에 새로운 생성 상하문을 만들고 현재 상하문으로 설정합니다

docker buildx build ...: 이전 단계의 Docker 캐시 레이어에서 구성/복원된 캐시를 사용하여 이미지를 구성합니다.구축 후 --push 옵션

을 사용하여 미리 구성된 레지스트리에 이미지를 업로드합니다.

rm | mv ...: 실행할 때마다 캐시를 업데이트해야 합니다. 그렇지 않으면 Githb Actions

에서 5GB의 스토리지 한계를 달성할 수 있습니다.

단계 - Kubernetes 클러스터에 배포
그림을 등록표에 올리면kubernetes에 명령을 보내서 배치를 수행할 수 있습니다.

- name: Deploy to Kubernetes cluster                                                                            
  uses: kodermax/kubectl-aws-eks@master                                                                         
  env:                                                                                                          
    RELEASE_IMAGE: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ env.RELEASE_REVISION }}
  with:                                                                                                         
    args: set image deployment/my-pod app=${{ env.RELEASE_IMAGE }} --record -n $KUBE_NAMESPACE   

여기서 우리가 사용하는 것은 kubectl set image이지만 kubectl rollout 또는 기타 필요한 명령일 수도 있다.
또한 배포를 확인하는 단계도 포함할 수 있습니다.

- name: Verify Kubernetes deployment                               
  uses: kodermax/kubectl-aws-eks@master                            
  with:                                                            
    args: rollout status deploy my-pod -n $KUBE_NAMESPACE 

단계 - 느슨한 공지
배포가 완료되면 를 사용하여 슬랙에 알림을 보낼 수 있습니다.

- name: Slack notification                                
  uses: rtCamp/action-slack-notify@master                 
  env:                                                    
    SLACK_CHANNEL: my_cool_channel                   
    SLACK_MESSAGE: 'Just deployed our cool application!'
    SLACK_TITLE: 'Deploy'                         
    SLACK_USERNAME: 'Some Bot'                           
    SLACK_ICON: "[icon URL]"
    SLACK_COLOR: '#228B22'                                
    SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}       
    MSG_MINIMAL: true  

this action
마무리
이 설명서에서는 Docker 이미지 구축, 레지스트리에 업로드, Kubernetes에 배포 및 Slack에 알림을 보내는 전체 주기를 구성합니다.
다음 글은 AWS S3에 의존하는 캐시 정책을 어떻게 사용하고 Docker 이미지(즉 루비 개발자의 a.k.abundle install에서 의존항 설치의 구축 시간을 최적화하는지 보여 준다.