GitHub을 사용한 Kubernetes CI/CD 및 용골

본고에서 우리의 목표는 매우 간단한 CI/CD 파이프를 사용하여 Kubernetes에 용기화 프로그램을 설정하여 GitHub 작업과 Keel 관리 배치를 사용하는 방법을 보여주는 것이다.

시작하기 전에:


Kubernetes는 K8s라고도 부르며 자동화 배치, 확장과 관리에 사용되는 소스 용기 배열 시스템이다.
Keel는 헬멧, 수호 프로그램, 상태, 배치를 자동으로 업데이트하는 K8s 운영자다.그것은 CLI/API에 대한 요구가 없고 아름답고 통찰력 있는 계기판을 가지고 있는 원천적이고 위탁 관리적이다.
GitHub Actions 세계적인 CI/CD를 사용하여 모든 소프트웨어 워크플로우를 손쉽게 자동화할 수 있습니다.GitHub에서 코드를 직접 구축, 테스트 및 배포합니다.

워크플로우:



워크플로에는 기본적으로 두 단계가 있습니다.
  • GitHub 재구매 계약의 일부 변경 사항을 추진합니다.응용 프로그램의 docker 이미지를 구축하고 이 이미지를 docker 등록표로 전송하는 작업 흐름을 터치합니다.
  • 이미지를 업데이트하라는 메시지가 표시됩니다.업데이트 정책에 따라 구성된 클러스터에서 배포가 업데이트됩니다.
  • 첫 번째 단계:


    첫 번째 단계에서는 워크플로우를 트리거하기 위해 GitHub 재구매 계약을 준비합니다.
    repoaka-achu/go-kube는golang으로 작성된 간단한 웹 응용 프로그램과 docker 파일을 포함하고 이 파일은 응용 프로그램의 docker 이미지를 구축하는 데 사용됩니다.생산, QnA, 무대 오르기, 개발 등 응용 프로그램에 대한 임의의 환경을 유지할 수 있습니다. 간단하게 보기 위해서, 우리는 응용 프로그램의 두 가지 배치 환경만 유지할 것입니다.
    환매 협의 중에는 단지 두 개의 지점만 있다.
  • 주요 지사(운영 환경용)
  • name: Stable Build
    on:
      push:
        tags:
          - "*.*.*"
    ...
          - name: Set tag in env
            run: echo "TAG=${GITHUB_REF#refs/*/}" >> $GITHUB_ENV
    ...
              tags: runq/go-kube:${{ env.TAG }}, runq/go-kube:latest
    
    태그를 GitHub로 밀어넣으면 트리거stable workflow가 발생합니다.워크플로우에서 제출과 관련된 태그는 docker image 태그로 사용됩니다.
  • 개발 지점(개발/등단 환경용)
  • name: Development Build
    on:
      push:
        branches: [ dev ]
    ...
          - name: Set short commit hash in env
            run: echo "COMMIT_SHA=$(echo $GITHUB_SHA | cut -c1-7)" >> $GITHUB_ENV
    ...
              tags: runq/go-kube:dev-${{ env.COMMIT_SHA }}
    
    변경 사항을 dev 지점으로 전송할 때 dev workflow 터치합니다.개발 구축에 있어서 GitHub에서 흔히 볼 수 있는 길이 7의 짧은 제출 산열을 사용합니다.빌드 이미지를 개발하는 docker 이미지 레이블은 dev-SHORT COMMIT SHA가 됩니다.
    이 두 작업 흐름은 모두 코드를 통합하는 데 목적을 두고 있으며, 테스트를 실행하고, docker 이미지를 구축하며, 이미지 등록표를 업데이트할 수도 있다.지금까지 우리는 지속적인 통합과 지속적인 납품을 완성했다.

    2단계:


    이 단계에서 우리는 자동으로 업데이트를 배치할 것이다.작업 프로세스에서 K8s LoadBalancer 서비스를 사용할 예정입니다.따라서 로컬 그룹을 사용한다면 MetalLB 을 사용할 수 있습니다. 이것은 나체 Kubernetes 그룹의 부하 균형기입니다.

    설치 용골:
    Keel은 데이터베이스를 필요로 하지 않습니다.Keel은 영구 디스크를 필요로 하지 않습니다.그것은 집단에서 필요한 모든 정보를 얻는다
    kubectl apply -f https://sunstone.dev/keel?namespace=keel&username=admin&password=admin&tag=latest
    
    위의 명령은 기본 인증 및 관리 대시보드를 활성화한 상태에서 Keel-to-Keel 네임스페이스를 배치합니다.리스트를 적용할 때 관리자 비밀번호를 제공할 수도 있고, 다운로드manifest를 해서 기본 비밀번호를 바꿀 수도 있습니다.
                # Basic auth (to enable UI/API)
                - name: BASIC_AUTH_USER
                  value: admin
                - name: BASIC_AUTH_PASSWORD
                  value: admin
                - name: AUTHENTICATED_WEBHOOKS
                  value: "false"
    

    용골 정책:
    keel에서, 우리는 정책을 사용하여 언제 응용 프로그램/배치를 업데이트할 것인지를 정의합니다.다음semver 모범 사례를 통해 애플리케이션 업데이트를 안전하게 자동화할 수 있습니다.Keel은 다양한 업데이트 리소스policies를 지원합니다.현재 우리는 allglob 전략만 사용하여 배치를 갱신할 것이다.
  • 모두: 버전 업그레이드(1.0.0->1.0.1)가 있거나 새로운 릴리스(즉:1.0.0->1.0.1-rc1)
  • 가 만들어지면 업데이트
  • glob: 어댑터를 사용하여 버전을 일치시킨다(예를 들어 우리 장면에서:dev-*

  • Keel이 알림을 받는 방법:
  • 웹훅 - 새 이미지가 등록표에 전송될 때keel은 DockerHub에 추가된 웹훅에 대한 알림을 받고 설정된 업데이트 정책에 따라 배치를 업데이트합니다.
  • 폴링 - semver 스타일 태그가 없는 이미지를 사용할 때(즉, 최신) Keel이 SHA 요약을 모니터링합니다.탭이 semver라면, 새 버전이 사용 가능할 때 추적하고 공급자에게 알립니다.

  • 웹훅을 구성하려면:
    우선, keel 서비스의 외부 IP 주소를 가져와야 합니다.
    kubectl get all -n keel
    
    출력은 다음과 같습니다.

    현재, 우리는 service/keel 외부 주소가 있습니다. DockerHub에 우리의 저장소에 웹훅을 추가할 것입니다.갈고리의 URL은 http://<External-IP>:9300/v1/webhooks/dockerhub입니다.새 docker 이미지를 밀어넣으면 HTTP 콜백이 트리거됩니다.
    만약 당신의 용골 서비스를 공개하고 싶지 않다면, 추천하는 해결 방안은 webhookrelay 이다. 그것은 옆차 용기를 통해 웹훅을 당신의 내부 용골 서비스에 전달할 수 있다.Here는 사이드카를 설치하는 방법이다.

    구성 배포 인벤토리:
  • 무대 위 배치를 설정하려면 dev-SHORT_COMMIT_SHA라는 라벨의 이미지를 실행하고 glob 정책을 사용합니다.우리는 정책/업데이트 규칙을 지정하기 위해 배포 목록 데이터 아래의 주석을 사용할 것입니다.마치-
  • ...
      annotations:
        keel.sh/policy: "glob:dev-*"
    ...
    
  • semver가 표시된 이미지를 실행하는 우리의 생산 배치를 설정합니다. all 정책을 사용할 것입니다.우리의 생산 배치가 탭의 모든 버전이 충돌할 때, 이것은 그것을 업데이트할 것입니다.우리는 정책/업데이트 규칙을 지정하기 위해 배포 목록 데이터 아래의 주석을 사용할 것입니다.마치-
  • ...
      annotations:
        keel.sh/policy: all
    ...
    

    워크플로우를 테스트하려면 다음과 같이 하십시오.


    현재 설치를 완료하고 dev 지점으로 전송하여 임시 저장 배치를 업데이트하고 표시된 발표는 생산 배치를 업데이트합니다.
  • 변경 사항을 dev 분기
  • 로 푸시
  • 개발 작업 프로세스를 터치하고 이 작업 프로세스는 docker 이미지를 구축합니다
  • 태그dev-SHORT_COMMIT_SHA가 있는 Docker 이미지는 DockerHub 레지스트리로 전송됩니다.
  • DockerHub에서 웹훅
  • 을 사용하여 Keel에게 알림
  • Keel은 새 이미지 레이블이 지정된 정책dev-으로 시작하는 모든 레이블이 업데이트 프로세스의 조건에 맞는지 확인합니다.예: dev-c722d00, dev-0ca740e
  • 탭이 업데이트 조건에 부합되면keel은 새 이미지로 새 복사 집합을 만듭니다.POD가 준비되면 keel은 오래된 Replicaset의 복사본 수량을 0으로 축소합니다.
  • 탭의 방출은 유사한 이벤트 흐름을 촉발합니다.

    용골 계기판을 사용하여 가시화:


    외부 IP:9300 또는 노드 포트를 사용하여 대시보드에 액세스할 수 있습니다.용골을 설정할 때 설정한 증빙서류를 사용합니다.
    너는 할 수 있어-
  • keel이 관리하는 자원 보기
  • keel
  • 의 변경에 대한 감사
  • 리소스 변경/업데이트 일시 중지 정책
  • 업데이트 승인
  • 다음은요?


    keel 문서를 보고 더 많은 기능을 알 수 있습니다.
  • UDPATE 승인 지원
  • 알림 파이프 설치
  • 지원하는 웹훅 트리거와 퀴즈
  • 헬멧 템플릿으로 업데이트
  • 데몬, 상태 세트 업데이트
  • Here는 모든 업무 흐름과 배치 목록이다.

    좋은 웹페이지 즐겨찾기