Argo CD의 파란색 녹색 depro, 로컬 환경에서 GitOps 시도
24636 단어 KubernetesGitOpsArgo CDtech
개시하다
이전에 제작된 로컬 k8s에서 실행된 프로그램에서 다음과 같은 내용을 가져왔습니다.
코드 여기 있어요.
skaffold、kustomize
스카프폴드,kustomize를 활용해 이런 디렉터리를 구성했다.
kustomize 합병 후 선언
k8s/manifest/app/app.yml이 토로됐다.├── k8s
│ ├── kustomize
│ │ ├── base
│ │ │ ├── app
│ │ │ │ ├── deployment.yml
│ │ │ │ ├── ingress.yml
│ │ │ │ ├── kustomization.yml
│ │ │ │ ├── nginx-default-configmap.yml
│ │ │ │ ├── nginx-nginx-configmap.yml
│ │ │ │ └── service.yml
│ │ │ └── redis
│ │ │ ├── deployment.yml
│ │ │ ├── kustomization.yml
│ │ │ └── service.yml
│ │ └── overlays
│ │ └── local
│ │ ├── build.sh
│ │ └── kustomization.yml
│ ├── manifest
│ │ └── app
│ │ └── app.yml
│ └── skaffold.yml
k8s/skaffold.yml
apiVersion: skaffold/v2beta10
kind: Config
metadata:
name: app
build:
artifacts:
- image: pokoytan/k8s-request-counter-emitter
context: ./
docker:
dockerfile: ./Dockerfile
tagPolicy:
sha256: {}
local:
push: false
useBuildkit: true
profiles:
- name: local
deploy:
kustomize:
paths: ["k8s/kustomize/overlays/local"]
ArgoCD
참조: https://qiita.com/ttr_tkmkb/items/ff4d88f3a91db982b0ab
Argo CD 설치, Argo CD 비밀번호 설정.
Argo CD의 GUI에 액세스할 포트 피드백을 설정합니다.
방문
kubectl port-forward svc/argocd-server -n argocd 8080:443
https://localhost:8080/하면 이런 화면이 되기 때문에 설정된 비밀번호로 로그인합니다.
Argo CD를 개체로 하는 클러스터를 로컬 docker desktop으로 만듭니다.
argocd cluster add docker-desktop
argocd app create, Argo CD 응용 프로그램을 만들고 창고를 감시합니다.argocd app create k8s-request-counter-emitter \
--repo https://github.com/pokotyan/k8s-request-counter-emitter \
--path k8s/kustomize/overlays/local \
--dest-server https://kubernetes.default.svc \
--dest-namespace default \
--sync-policy automated \
--auto-prune \
--self-heal
이 창고의
--repo https://github.com/pokotyan/k8s-request-counter-emitter이 경로의 선언에서--path k8s/kustomize/overlays/local만약 어떤 변화가 있으면 자동으로 설계를 진행할 수 있다--sync-policy automated argocd app create가 완료되면 Argo CD를 통해 로컬 환경에 애플리케이션을 개발합니다.GUI에도 애플리케이션이 추가되어 창고와의 동기화 상태와 동작 상태를 알 수 있습니다.
여러가지 방법이 있는 Argo CD의 앱 제작.
위에서 설명한
argocd app create 후에는 Argo CD의 애플리케이션 리소스가 만들어지지만 다른 방법도 있습니다.이런 느낌의 선언을 준비하고
kubectl apply 하면 만들 수도 있어요.k8s/manifest/argo/application.yml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: k8s-request-counter-emitter
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/pokotyan/k8s-request-counter-emitter
targetRevision: HEAD
path: k8s/kustomize/overlays/local
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
CI/CD
참조:
Argo CD는 창고의 변경 사항을 감지하면 자동으로 지정된 클러스터를 사전 처리합니다.그래서 코드가 창고에 통합되면
이를 위해 이런 느낌의 지허브액션을 만들었다.
.github/workflows/main.yml
name: ci
on:
push:
branches: main
jobs:
push-image-to-docker-hub:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Login to DockerHub
uses: docker/login-action@v1
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Build Image
run: |-
docker build --tag pokotyan/k8s-request-counter-emitter:${GITHUB_SHA} .
- name: Push Image
run: |-
docker push pokotyan/k8s-request-counter-emitter:${GITHUB_SHA}
deploy-local:
runs-on: ubuntu-latest
needs: push-image-to-docker-hub
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Set up Kustomize
run: |-
curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
chmod +x ./kustomize
- name: Set up Git
run: |
git config --local user.email "[email protected]"
git config --local user.name "pokotyan"
- name: Set up kubeval
run: |-
wget https://github.com/instrumenta/kubeval/releases/latest/download/kubeval-linux-amd64.tar.gz
tar xf kubeval-linux-amd64.tar.gz
sudo cp kubeval /usr/local/bin
- name: Commit after Build manifest
run: |
bash ./k8s/kustomize/overlays/local/build.sh pokotyan/k8s-request-counter-emitter:${GITHUB_SHA}
git commit -am "Update image to pokotyan/k8s-request-counter-emitter:$GITHUB_SHA"
git pull
git push origin main
탭을 동적으로 다시 쓸 때 실행되는build입니다.sh는 이런 느낌의 스크립트
kustomize edit set image로 동적으로kustomize base가 된 선언 내의 app-image에 대한 기술를 현재 응용되고 있는 이미지로 바꿨다.k8s/kustomize/overlays/local/build.sh
#!/bin/bash
set -euo pipefail
cd $(dirname $0)
IMAGE_NAME="$1"
kustomize edit set image app-image="${IMAGE_NAME}"
kustomize build . >../../../manifest/app/app.yml | kubeval --strict --ignore-missing-schemas
kubeval에 대한 CRD 리소스가 없습니다. 따라서 kubeval을 직접 더하면 Rollout에서 오류가 발생할 수 있습니다.따라서 추가
--ignore-missing-schemas 옵션이 CRD라면 검사를 통과합니다.별말씀을요. 메일 지점의 변경을 촉발점으로 하는 Giithub Actions의 처리 내에서push에서main 지점으로 이동하면 Github Action의 무한 순환이 될 것 같지만 특별히 그렇게 된 동작은 없습니다.
ArgoCD Rollouts
참조:
Argo CD Rollouts의 컨트롤러 및 Argo CD Rollouts의 cli 설치.
Deployment의 yaml을 Rollout의 yaml로 변경합니다.
이런 느낌으로 두 가지 서비스를 준비합니다.
active 서비스는 실제 응용에 참고할 수 있는 서비스입니다
preview-서비스는 새로 개발한pod가 준비가 완료되기 전에 해야 할 서비스라는 인상을 준다.
k8s/kustomize/base/app/service.yml
apiVersion: v1
kind: Service
metadata:
name: active-service
labels:
app: app
spec:
type: NodePort
selector:
app: app
ports:
- port: 80
targetPort: 80
protocol: TCP
---
kind: Service
apiVersion: v1
metadata:
name: preview-service
spec:
type: NodePort
selector:
app: app
ports:
- port: 80
targetPort: 80
protocol: TCP
청록색 depro가 되는 상황을 바라보다
kubectl argo rollouts get rollout app --watch --cluster docker-desktop
실제로 표시된 변화가 어떤지 확인해 보자.
8877ec 이미지를 이용한pod가 active-service에 걸려 있습니다.
main 지점에 코드 변경을 하는push
(이곳은main분지에 직접 들어가는 것으로 실제 운용된다면main분지에 대한 수법 합병은 촉발이 될 것이다.)
main 분기의 push를 통해 GiithubAction 이동
GiithubActions 처리에서 응용된 이미지를 만들고 선언된 이미지 라벨을 업데이트하여main 지점의commiit,push로 진행합니다
현재 커밋된 해싱된 35308c로 이미지 태그 업데이트
Argo CD가 저장소의 업데이트를 감지하고 청록색 프리프로세싱이 시작됩니다.
우선preview-서비스와 관련된pod의 제작 시작 동작입니다.pod에서 사용하는 이미지 탭은
35308c 새 것입니다.
pod의 제작을 완성하고
35308c의 이미지를 이용하여pod를 active-service에 연결합니다.
오래된
8877ec 이미지의pod 삭제 처리를 시작합니다.
8877ec를 이용한 이미지의pod는 모두 사라지고 35308c를 이용한 이미지의pod만 active 서비스에 걸려 있는 형태로 남는다.
푹 빠진 곳
개발 중
skaffold dev -p local --port-forward -f k8s/skaffold.yml
이 상태에서 실행
argocd app create할 때skaffold를 통해 로컬 환경에 대한 디자인과 Argo CD를 통해 로컬 환경에 대한 디자인이 모두 동작하여 응용 프로그램이 정상적으로 작동하지 못할 것 같다.
따라서 집행
argocd app create을 하기 전에 스카프폴드를 미리 제거할 필요가 있다.(반대로 skaffold로 이동하면
argocd app delete ArgoCD 프로그램을 삭제합니다)Argo CD가 GitOps에 도입된 경우 Argo CD를 대상으로 한 클러스터링은 공식 환경이기 때문에 현지에서 Argo CD를 시도할 때만 가능한 가장 적합한 부분이라고 생각한다.
최후
이번에는 번거롭기 때문에 응용 프로그램의 코드와 k8s의 선언은 모두 같은 창고로 관리해야 하기 때문에 분리하는 것이 좋다.Argo CD의 모범 사례에도 기재되어 있다)
만약 응용 프로그램의 코드와 선언이 같은 창고로 관리된다면 매번 코드의 수정에 해당하는 프로그램이 있을 것이다.예처리 시간과 예처리를 수행할 수 있는 구성원을 관리하려면 선언의 창고를 분리하는 것이 쉽다.
Reference
이 문제에 관하여(Argo CD의 파란색 녹색 depro, 로컬 환경에서 GitOps 시도), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/pokotyan/articles/81446f1c0b48a1텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
