GitHub을 사용한 Kubernetes CI/CD 및 용골
9755 단어 devopskubernetesgodocker
시작하기 전에:
Kubernetes는 K8s라고도 부르며 자동화 배치, 확장과 관리에 사용되는 소스 용기 배열 시스템이다.
Keel는 헬멧, 수호 프로그램, 상태, 배치를 자동으로 업데이트하는 K8s 운영자다.그것은 CLI/API에 대한 요구가 없고 아름답고 통찰력 있는 계기판을 가지고 있는 원천적이고 위탁 관리적이다.
GitHub Actions 세계적인 CI/CD를 사용하여 모든 소프트웨어 워크플로우를 손쉽게 자동화할 수 있습니다.GitHub에서 코드를 직접 구축, 테스트 및 배포합니다.
워크플로우:
워크플로에는 기본적으로 두 단계가 있습니다.
첫 번째 단계:
첫 번째 단계에서는 워크플로우를 트리거하기 위해 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를 지원합니다.현재 우리는
all
와 glob
전략만 사용하여 배치를 갱신할 것이다.dev-*
Keel이 알림을 받는 방법:
웹훅을 구성하려면:
우선, 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-*"
...
all
정책을 사용할 것입니다.우리의 생산 배치가 탭의 모든 버전이 충돌할 때, 이것은 그것을 업데이트할 것입니다.우리는 정책/업데이트 규칙을 지정하기 위해 배포 목록 데이터 아래의 주석을 사용할 것입니다.마치-...
annotations:
keel.sh/policy: all
...
워크플로우를 테스트하려면 다음과 같이 하십시오.
현재 설치를 완료하고
dev
지점으로 전송하여 임시 저장 배치를 업데이트하고 표시된 발표는 생산 배치를 업데이트합니다.dev
분기dev-SHORT_COMMIT_SHA
가 있는 Docker 이미지는 DockerHub 레지스트리로 전송됩니다.dev-
으로 시작하는 모든 레이블이 업데이트 프로세스의 조건에 맞는지 확인합니다.예: dev-c722d00
, dev-0ca740e
용골 계기판을 사용하여 가시화:
외부 IP:9300 또는 노드 포트를 사용하여 대시보드에 액세스할 수 있습니다.용골을 설정할 때 설정한 증빙서류를 사용합니다.
너는 할 수 있어-
다음은요?
keel 문서를 보고 더 많은 기능을 알 수 있습니다.
Reference
이 문제에 관하여(GitHub을 사용한 Kubernetes CI/CD 및 용골), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/achu1612/ci-cd-for-kubernetes-using-github-actions-and-keel-4b7c텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)