워밍업클럽4기 DevOps 4주차 발자국

Helm과 Kustomize 비교하며 사용-2Helm과 Kustomize는 무엇이 더 좋다기보단, 서로 지향하는 방향이 극명히 다른 것 같다. 대규모 배포를 사용하게 될지 아직은 잘 모르겠어서... 약간은 더 직관적으로 느껴지는 Kustomizee부터 사용하게 될 것 같다.최근 보안과 관련해 안좋은 소식들이 많이 있었기에, 도커 허브와 쿠버네티스 클러스터에 대한 접근 제어를 강화하는 방법을 실습할 수 있어서 좋았다.컴퓨터가 좋지 않아 빌드를 계속한다.... 10분이 넘어도 멈추지 않는다.... ArgoCD 빠르게 레벨업-1ArgoCD가 Git을 필요로 하는 만큼, 불필요한 업데이트가 발생하지 않도록 Git 레포지토리를 분리해서 관리하는게 정말 중요할 것 같다.Jenkins Pipeline과 비교해 배포가 간단하고, 무엇보다 쿠버네티스와 동기화되어 배포 상태를 그래픽으로 한번에 조회할 수 있어서 좋다.로그도 Jenkins는 각 파이프마다 클릭해서 페이지가 이동되고 봐야했는데, ArgoCD는 실시간으로 Pod 로그도 볼 수 있어서 매우 편리했다. ArgoCD 빠르게 레벨업-2ArgoCD Image Update를 사용해야하는 이유를 처음에 이해하지 못했는데 3번 구간 반복하니 이해가 되었다.Git과 완전히 동일한 환경을 구현하고자 할 때 도움되는 옵션도 알게되어, 테스트 환경을 만들 때 유용하게 사용할 수 있을 것 같다.다만... 컨테이너 빌드를 완료했는데 감지하는데 실패했다...(컴퓨터가 너무 느림) - 그치만 미션에선 이미지 변경 감지 성공! ArgoCD 빠르게 레벨업-3CLI를 사용해 모니터링할 수 있다니 ArgoCD는 정말 완벽한 것 같아요YAML 파일의 구성도 기존 쿠버네티스 환경과 호환되도록 세심하게 배려한 게 정말 잘 만든 솔루션이라고 느낍니다Jenkins를 사용해서 Blue/Green과 Canary 배포를 진행할 때는 이론은 쉽지만 막상 스크립도 구현하는 것은 까다로운 배포 작업이라고 생각된 것에 반해, ArgoCD는 정말 딸깍으로 배포할 수 있는 강력한 솔류션 같습니다.

쿠버네티스 어나더 클래스 지상편: Sprint2 Day17 ArgoCD 3

Argo RolloutsArgoCD 없이도 Rollouts(Blue/Green, Canary) 배포가 가능하다.ArgoCD와 독립적인 솔루션이며, ArgoCD와 함께 사용하면 ArgoCD 대시보드에서 Rollouts 버튼이 생긴다. Blue/Green 배포운영 환경에서만 테스트가 가능한 환경에서 주로 사용하는 배포 전략이다.배포 시 롤백이 빠르다.배포 중 V1 과 V2 간의 동시 호출이 발생하지 않는다.Script를 사용해 자동 배포가 가능하다.V2에 과도한 트래픽이 유입될 경우 문제가 발생할 수 있다. Rollouts을 사용한 Blue/Green 배포 과정Rollout 컨테이너 → Service 2개 지정: Active(서비스 사용자 접근), Preview(V2로만 접근) V1(Blue) 배포Rollout → Replica Set V1 → Pod V1 ← Active / Preview Service배포 이전에는 2개 서비스 모두 Blue를 바라본다 V2(Green) 배포Rollout → Replica Set V1 → Pod V1 ← Active ServiceRollout → Replica Set V2 → Pod V2 ←Preview Service ← QA담당자배포 이후에 Preview Service만 Green을 바라본다. PromotePod V1 삭제 ← Promote → Active / Preview Service → Pod V2Promote를 진행하면 Blue는 제거한다 Canary 배포특정 헤더 값에 한해 트래픽이 유입되도록 할 수 있다.서서히 트래픽을 전환하므로 콜드 스타트를 방지할 수 있다.업그레이드 목적 이외에도 두 버전을 비교하기 위한 A/B 테스트에도 사용된다. Rollouts을 사용한 Canary 배포 과정Blue/Green처럼 새 서비스를 만들지 않아도 트래픽을 조절할 수 있다. V1 배포Rollout → Replica Set V1 → Pod V1 ← Service V2(Canary) 배포Rollout → Replica Set V1 → Pod V1 ← ServiceRollout → Replica Set V2 → Canary Pod ← Service Promote순차적으로 Cananry Pod의 비중을 늘림setWeight: 전체 Pod에서 Canary가 차지하는 비중pause: {} : Promote가 올 때까지 무한정 대기 5. Argo Rollouts를 이용한 Blue-Green 배포 - 22335-2. App 생성 하기 - [+ NEW APP] 클릭5-3. 배포하기 - [SYNC] 클릭 > [SYNCHRONIZE] 클릭5-4. 배포 확인배포 완료 5-5. 트래픽 보내기 5-6. ArgoCD UI에서 Blue/Green 배포 시작하기rollout.yaml spec: replicas: 2 strategy: blueGreen: activeService: api-tester-2233-active previewService: api-tester-2233-preview autoPromotionEnabled: falseRollout을 사용하기 위해 배워야할 부분은 spec - strategy - blueGreen 뿐 autoPromotionEnabled: falsetrue일 경우 Green 파드가 정상 작동하면 Promote가 자동으로 반영된다. 5-6-3. Git에서 image의 tag 변경5-6-4. ArgoCD에서 Applications > api-tester-2233 > [SYNC] 클릭Git의 수정 사항을 감지함 5-6-5. 트래픽 확인rollouts-pod-template-hash 를 사용해 트래픽을 전환할 수 있다. 5-6-6. Promote 진행Rollout 대시보드는 기본적으로 안만들어짐Rollback: Green 파드 삭제Restart: Blue/Green 파드 모두 재시작, 원하는 파드를 K8s에서 삭제하여 재시작하는 방법이 더 좋음Promote: 다음 단계PromoteFull: 배포 완료 Promote를 진행한다. 5-6-7. 트래픽 확인 5-7. Rollout CLI로 조회 해보기배포 상황을 모니터링해줌 6. Argo Rollouts를 이용한 Carary 배포 - 22346-1. Master에서 Kubectl로 Rollouts 배포하기 6-2. 배포 모니터링6-3. 트래픽 보내기 (1.0.0 App 연결) 6-5. Argo Rollouts CLI로 Canary 배포 시작하기 (1.0.0 -> 2.0.0로 변경)Canary Pod가 만들어졌다. 6-7. 트래픽 확인 (1.0.0 App 연결, 2.0.0 App 연결)트래픽이 Canary로 분산되고 있다. Promote를 진행해 다음 단계로 넘어간다. 전체 Pod중 66%의 Canary Pod가 생성되었다. 6-8. 트래픽 확인 (2.0.0 App 연결) 배포가 모두 완료되었다! 6-9. 리소스 정리하기

워밍업클럽4기 DevOps 미션6: ArgoCD Github 업데이트

1. ArgoCD로 App 생성 및 배포 - 2232-build-push-git1-2. 자동 배포 설정 - api-tester-2232-build-push-git > details > SYNC POLICY1-3. 자동 배포 확인 - ArgoCD 상태 및 Dashboard Pod 생성 유무2. Jenkins에 Github Token 등록Github의 새 기능인 Fine-grained 토큰을 사용했습니다.3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기3-3.[저장] 후 [지금 빌드] 실행3-4.[파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행3-5.Stage View결과 확인3-6. ArgoCD에서 자동 배포 확인배포 성공! 3-7. 다시 빌드 후 재확인

쿠버네티스 어나더 클래스 지상편: Sprint2 Day16 ArgoCD 2

DevOps 엔지니어가 배포를 해야되는 상황DevOps 엔지니어는 리소스 스펙 변경이 필요할 때, App 버전이 업그레이드 될 때 컨테이너 이미지를 변경해 배포를 해야 한다.원래 DevOps 엔지니어는 App 버전을 교체할 때 YAML 파일을 수정해야하지만, Helm을 사용하면 배포 명령에 이미지 태그를 동적으로 부여하므로 YAML 파일 수정 없이 자동 배포가 가능하다. ArgoCD Image Updater를 사용해야 하는 이유ArgoCD가 이미지 변경을 감지하여 자동으로 K8s로 배포한다.다만 Jenkins가 아닌 ArgoCD가 감지하여 배포하므로, 컨테이너 빌드가 끝난 이후에 자동 배포가 어려워졌다. → Jenkins가 YAML파일을 수정하고 Git에 업그레이드 하는 방법은 로직이 복잡해진다.⇒ ArgoCD Image Update가 도커 허브를 모니터링하고 이미지 업데이트가 감지되면 ArgoCD에 배포 명령을 전송, K8s로 자동 배포를 수행한다. ArgoCD Image Update 요구사항ArgoCD Image Update는 내부적으로 --set image.tag 명령을 사용하기 때문에 Helm, Kustomize 배포 시에만 사용 가능하다.Image Update와 도커 허브 연결 설정이 필요하다.배포시 태그 규칙 추가가 필요하다. 4. Argo Image Updater 를 이용한 이미지 자동 배포 (helm) - 22324-1. Image Updater values-dev.yaml 파일 확인4-3. Jenkins에서 배포4-4. Image Updater 동작 확인설정한 로그가 없어 정보가 결과가 없음. 각 이미지마다 alias를 설정해야한다. Git에서 삭제하더라도 K8s에서 리소스를 유지할 지 여부, 내용 출돌시 Git의 변경을 자동으로 반영할 지 여부: Git과 항상 동일한 형상을 유지하고 싶을 때 사용할 수 있다. → K8s의 오토스케일링이 발생해도 Git과 형상을 유지하기 위해 다시 돌아간다.(강의 영상처럼 분명 SYNC 켰는데 들어가보면 꺼져있음) 4-6. 도커 빌드 Job 생성 3가지 환경에 배포해봤지만 변화가 없다...

쿠버네티스 어나더 클래스 지상편: Sprint2 Day15 ArgoCD 1

ArgoCD 아키텍처ArgoCD는 K8s 전용 배포 툴이며 릴리즈 파일 저장소로 반드시 Git을 필요로 한다. 타 시스템⏬Events: 이벤트 버스 구조의 아키텍처 도구⏬Workflow: 워크플로우 매니지먼트 도구 → 받은 이벤트의 조건에 따라 실행 순서를 생성⏬CD (Image Update: 도커 컨테이너 이미지 변경을 감지)⏬Rollouts: 고급 배포 지원 → 특정 배포 전략으로 K8s 자원 생성⏬Kubernetes Git 레파지토리 분리접근 유저별 권한을 관리할 수 있고, 불필요한 코드를 다운로드 받지 않도록 방지한다.App 소스 코드 전용 - 개발자, 소스 빌드App 릴리즈 전용 - 데브옵스 엔지니어 / 개발자Addon 설치 전용 - 운영자 ArgoCD 배포의 필요 정보Application: 하나의 App을 배포하는 단위, Jenkins의 Project JobProject: Application 그룹, Default가 기본값Source: 연동할 Git 정보Destination: 연동할 K8s 클러스터 정보Refresh: 변경 사항 측정 주기Synchronize: K8s 배포 실행 주기GenernalSync Policy: 변경 사항 발생 시 자동 / 수동 배포 지정Sync Option: 배포 상세 옵션 (Namespcae 자동 생성 등)Prune Policy: 리소스 삭제 정책Desired Manifrest: Git에서 다운로드 받은 Manifest, Git에서 수정하고 Refrest 해야한다.Live Manifrest: K8s의 리소스를 조회한 Manifest → diff는 Git에 변경 사행이 반영될 Live와 현재 Live를 비교해 보여준다. ArgoCD 설치 및 배포 (kubectl, helm) 2. App 배포하기 (kubectl) - 22313. App 배포하기 (helm) - 2232Helm의 -f와 동일

쿠버네티스 어나더 클래스 지상편: Sprint2 Day14 Helm과 Kustomize 2

Kustomize 구조Kustomize는 폴더를 수작업으로 생성해야한다.메인폴더디폴트 포맷 폴더kustomization.yaml ← 배포할 파일 선택 및 공통값 설정베이스 YAML 파일오버레이 영역 폴더배포 환경을 각 폴더로 구분해 선택적으로 배포할 수 있음kustomization.yaml ← 배포할 파일 선택 및 공통값 설정배포 환경에 맞게 오버레이 될 파일 배포할 파일 선택에 대한 차이점Helm: hpa.yml 파일에서 선언한 조건문이 values.yaml 파일에 의해 제어되어 배포됨Kustomize: kutomization.yaml 파일에 배포할 파일을 명시적으로 선언해 배포 공통값 설정에 대한 차이점Helm: YAML 템플릿 내에 다른 파일에서 변수를 주입됨Kustomize: Kustomization.yaml 파일 내 coomonLabels 키의 Lables가 모든 YAML 파일에 주입됨 환경별 설정에 대한 차이점Heml: values-dev.yaml, values-qa.yaml, values-prod.yaml 로 구별배포 명령에 -f 옵션으로 환경 파일를 선택: helm install api-tester-32222 ./app -f ./app/values-dev.yamlKustomize: 각 환경 폴더 dev, qa, prod 로 구별배포 명령에 폴더를 선택: kubectl apply -k ./app/overlays/dev 1. 다양한 배포 환경을 위한 Kustomize 배포하기 - 2222dev 개발환경이 선택되어 있다. -> Jenkins 파일 내에 있지만 처음 배포에 인식 안됨 dev 환경으로 배포 시작 실제 실무 환경에서는 K8s 네임스페이스 구분이 없어도 문제되지 않는다. 2. 다양한 배포 환경을 위한 Helm 배포하기 - 2223배포 파이프라인 구축 후 마주하게 되는 고민들컨테이너 빌드 후 도커 허브에 업로드할 때 사용되는 config.json에는 도커 허브의 사용자 정보가 저장된다. config.json 파일은 암호화가 되지 않기 때문에 인증 정보가 노출될 수 있다. Helm에서 사용하는 K8s 클러스터의 인증서는 리눅스 ROOT 권한으로 관리되어 인증서 파일을 복사하면 누구나 K8s 클러스터에 API 요청을 진행할 수 있다.⇒ CI/CD 서버의 접근 제어를 강화해야한다.⇒ 도커 허브 계정 정보와 K8s 클러스터 인증서를 Jenkins의 Credential로 등록하고 암호화하여 관리한다.⇒ 도커의 경우 Jenkins에서 암호화하더라도 config.json은 암호화되지 않는다, 배포시마다 로그인/로그아웃을 해 접속 정보를 삭제해야 한다.⇒ docker-credential-helpers는 config.json에 대한 암호화를 제공한다. 컨테이너 빌드가 지속적으로 진행되면서 CI/CD에 컨테이너 이미지가 누적된다. 서버의 디스크가 모두 사용되면 Jenkins 서비스가 중단된다.⇒ 도커 허브에 업로드 후 CI/CD 서버에 만들어진 이미지를 삭제한다. Helm을 통해 여러 App을 배포할 때 지난 실습처럼 App 하나마다 네임스페이스를 만들지 않고, 별도의 그룹 개념으로 App을 묶어 관리하는 경우가 많다.⇒ 네임스페이스는 배포와 별도로 관리하는게 좋다, Helm 앱을 삭제할 때 네임스페이스를 제거하면 네임스페이스에 포함된 리소스가 삭제되므로 Helm은 의도적으로 삭제하지 않는다. 배포 이후에 Pod가 완전히 정상적으로 기동됐는지 체크가 필요하다.⇒ Helm의 자주 쓰는 부가 기능으로 --wait 옵션을 사용한다. K8s는 Deployment의 Template 영역의 수정이 발생해야 업그레이드를 진행하므로 Helm 배포를 해도 업그레이드가 되지 않는 경우가 있다.⇒ Helm의 자주 쓰는 부가 기능으로 annotations를 사용해 새 배포시마다 랜덤 값 생성해 Helm 배포시마다 K8s가 업그레이드를 수행하도록 한다. 컨테이너 이미지의 태그 관리에서 개발환경은 잦은 배포를 진행하므로 versioning의 의마가 없지만, 검증/운영 환경은 계획된 배포를 진행해 versioning이 필수이다.⇒ 컨테이너 이미지의 버전 명명 규칙상 v를 제거하는게 맞다.⇒ 개발 환경은 이미지 태그로 latest를 사용하고, pullPolicy로 Always(항상 도커 허브에서 이미지를 가져온다)를 사용한다. 단, 인터넷 연결이 없으면 도커 허브에 접근을 못하므로 Pod 생성이 실패되고, Heml의 annotations을 사용하지 않는다면 이미지 태그가 latest로 고정되어 Template 수정이 없으므로 K8s가 업그레이드를 전혀 수행하지 못한다.⇒ 검증/운영 환경은 이미지 태그에 버전을 명시하고, pullPolicy로 IfNotPresent(K8s Node에 해당 이미지가 있으면 사용, 없으면 도커 허브에서 다운로드)를 사용한다. 운영 환경에서 Pod가 재시작되거나 스케일링이 작업 중인 상태에서 이미지를 도커 허브에서 다운로드받는 비효율적인 작업이 생략된다. 개발 환경에서 컨테이너 이미지에 대란 롤백을 요청하는 경우⇒ 개발 환경의 빌드부터 버전 관리를 시작해 개발자가 요청하는 버전으로 교체될 수 있도록 대응한다.매 배포시마다 이미지 태그가 변하므로 pullPolicy를 IfNotPresent로 변경해도 K8s에서 업그레이드를 수행할 수 있다.컨테이너 이미지를 받는 사람은 Latest가 단순 최신 개발 버전이 아닌, 운영환경까지 배포된 최신 안정화 버전으로 기대하고 다운로드 받는다.⇒ 프로젝트가 커질 수록 개발 이미지를 버전 관리하면서 바꿔가는게 좋다. CI/CD 서버와 마찬가지로 K8s 클러스터도 이미지를 계속 다운로드 받는다.⇒ Kubernetes Garbage Collector에서 사용하지 않는 이미지는 자동으로 삭제된다. 3. 배포 파이프라인 구축 후 마주하게 되는 고민들 2224 3-3-1. 중요 데이터 암호화 관리 3-3-1-1. 도커 접속 정보 및 쿠버네티스 config를 위한 New credentials 생성 ● Docker 접속정보 Credentials 등록 3-3-1-3. CI/CD Server에서 Docker Logout 및 kubeconfig 삭제 3-4. [파라미터와 함께 빌드] 실행 후 PROFILE을 [dev]로 선택하고 [빌드하기] 클릭 (빌드를 계속 하는 중,.,,,,)

워밍업클럽4기 DevOps 미션5: 컨테이너 이미지 사례 실습

Docker와 Containerd 명령 실습▶ 사전 준비사항1. 빌드2. 이미지 리스트 조회3. 태그 변경4-1. 로그인4-2. 이미지 업로드5. 이미지 삭제6. 이미지 다운로드7. 이미지 -> 파일로 변환8. 파일 -> 이미지로 변환 컨테이너디 (Containerd)1. 네임스페이스 조회2. 특정 네임스페이스 내 이미지 조회3. 다운로드 및 이미지 확인4. 태그 변경5. 업로드6. 이미지(namespace : default)-> 파일로 변환7. 파일 -> 이미지로 변환(namespace : k8s.io)8. 삭제 (namespace : k8s.io) 같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유▶ Docker (490MB)▶ Containerd (248.3 MiB)1. Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다? X PLATFORMS는 그냥 해당 이미지가 어떤 플랫폼을 지원하는지 정보 2. Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회 됐을 것이다.▶ Containerd -> Docker3. 쿠버네티스에는 다른 Runtime을 사용 했을 수 있고, 같은 이미지더라도 사용하는 Runtime에 따라서 이미지의 크기는 달라질 것이다.Docker는 다른 많은 기능들을 지원해 주기 때문에 다운 받은 이후 자신의 매타데이터 규격에 맞게 데이터들을 더 추가하고 이미지를 재구성 합니다. 반대로 Docker의 이미지를 Contaienrd로 가져가게 됐을 때, Docker에서 재구성을 하느라 커진 불필요한 메타데이터들이 그대로 들어간다.

워밍업클럽4기 DevOps 3주차 발자국

데브옵스 한방 정리개발과 빌드에서 실행 파일을 생성하는 것은 항상 존재한다는 핵심 개념을 이해했습니다.DevOps 환경을 만들기 위한 다양한 오픈소스에 대해 알아볼 수 있었고, DevOps 이외의 다양한 Ops에 대해 알 수 있었습니다. 손쉽게 데브옵스 환경을 구축하는 방법Jenkins를 실행하여 전역 빌드 환경을 만들어보았습니다.GitHub의 소스 코드를 사용해 Jenkins에서 빌드하고 K8s로 배포를 진행했습니다. 배포를 시작하기 전에 반드시 알아야 할 것들K8s에서 기본적으로 제공하는 방식이 아닌 Blue/green과 Canary 배포 방식을 알 수 있었습니다.각 배포 방법의 사용 케이스를 참고하여 앞으로 프로젝트에 적합한 배포 방식을 채택하겠습니다. Jenkins Pipeline (기초부터 Blue/Green 까지)Jenkins 파이프라인을 사용해 시각 테이블을 직접 확인했습니다.kubectl create, apply, patch 명령의 차이점을 구분했습니다.Blue/Green 배포를 수행하며 K8s 서비스를 Label과 Selector를 사용해 Blue와 Green간 트래픽 전환 방식 구현 방법을 이해했고, Green의 상태에 따라 Blue 자원 제거 또는 롤백 과정을 진행했습니다. Helm과 Kustomize 비교하며 사용-1Helm과 Kustomize의 특장점을 비교하며, Jenkins에서 Helm 배포를 진행했습니다.Helm 차트의 구조를 파악하고 K8s 배포에서 사용된 yaml를 기반으로 Helm 차트를 수정했습니다.K8s 배포를 위해 잘 짜여진 yaml 파일은 언제든 Helm으로 전환할 수 있으니, K8s 배포를 위한 yaml부터 차근차근 작성하는게 중요하다는 점이 와닿습니다.Jinja2와 비슷한 문법이 Helm에서도 사용되어 신기합니다.

쿠버네티스 어나더 클래스 지상편: Sprint2 Day14 Helm과 Kustomize 1

Helm VS Kustomize 비교공통점Helm과 Kustomize는 App을 패키지 단위로 관리하는 패키지 매니저이다.배포를 할 때 발생하는 yaml파일에 대해 중복 관리 최소화하기 위해 사용한다.다양한 배포 툴에서 부가적인 기능을 지원한다. 차이점배포 편의기능이 Helm은 200개인데 반해 Kustomize는 10개이다. → Kustomize는 심플하다Kustomize는 점점 패키지 내부에 파일이 많아지는 구조로 마이크로 서비스 배포와 다양한 배포 환경을 구성하는데 동시에 사용하기엔 부적합하다.Helm은 기업 제품을 패키지용으로 설치하는데도 사용된다. 설치 구성의 차이점Kustomize는 K8s 1.14 버전부터 kubectl 기능으로 통합되었다.Helm은 패키지 저장소를 별도로 제공한다. 사용 방식의 차이점Heml: 함수 방식, 파라미터를 주입시켜 yaml 파일을 생성한다. → 배포 환경이 많을 수록 명령어가 늘어남Kustomioze: 오버레이 방식, 아무런 처리가 되지 않는 yaml 파일에 덮어써서 yaml 파일을 생성한다. → 배포 환경이 많을 수록 파일이 늘어남 Helm 차트 구조api-testesr: 메인 차트chats: 서브 차트templates: 메인 차트의 yaml 파일 폴더tests: App의 통신 상태를 확인하게 해주는 Helm의 부가기능_helpers.tpl 사용자 정의 전역 변수 선언.yml 배포될 파일NOTES.txt Helm 배포 후 안내 문구.helmignore: Helm 차트를 배포할 때 제외할 파일Charts.yml: 차트 기본정보 선언values.yaml: 배포될 yaml 파일에 들어가 있는 변수들의 기본값 선언 [1] Helm(Ver. 3.13.2) 설치[2] Kustomize(Ver. 5.0.1) 설치1. Helm 배포 시작하기 - 2221

쿠버네티스 어나더 클래스 지상편: Sprint2 Day13 Jenkins Pipeline

0. New view 만들기1. Jenkins Pipeline 기본 구성 만들기 (Step 1)오류가 발생해 자세한 로그을 보니 파이프라인은 성공적으로 실행됐다... 2. Github 연결 및 파이프라인 세분화폴더의 스크립트 파일 이름이 Jenkinsfile이다. 3. Blue/Green 배포 만들기 및 특징 실습Blue 버전으로 계속 호출하는 중 그린 파드로 호출 롤백 버튼으로 블루 파드로 다시 전환 Blue/Green시 고려해야 하는 요소블루 그린에 CPU가 꼭 2배가 필요한 것은 아니다, Pod 기동시에는 이론상 200% 사용 메모리의 경우 App 마다 무조건 할당하는 자원이므로 200% 사용된다.Blue-Green 배포를 고려한 Deployment 네이밍이 필요하다. Blue-green은 기존 배포와 나중 배포에 대한 상징적인 표현일 뿐, 배포를 할 때 마다 새 Deployment를 만들어야 한다.Blue-Green 배포를 위한 추가 Label 및 Selector가 필요하다. Label과 Selector가 동일하면 Green 배포와 동시에 Green에도 서비스가 연결된다. Blue/Green 수동 배포 방법Green Deployment 생성, 테스트를 위한 Service 생성Service의 Selector의 Blue-green-no를 2로 변경하여 트래픽을 Green으로 전환Green에 문제가 없다면 Blue의 Deployment 삭제, Green의 테스트 Service 삭제, 모든 리소스의 레이블 정보를 변경(Version) Green에 문제가 있다면 Service의 Selector의 Blue-green-no를 1로 변경하여 트래픽을 Blue로 전환 4. Blue/Green 자동 배포 Script 만들기kubectl create → 동일 리소스 존재시 충돌kubectl apply → 동일 리소스 존재시 업데이트kubectl patch → -p 옵션으로 특정 속성만 변경 Blue -> Green 트래픽 전환 kubectl get -n anotherclass-221 pods -l instance='api-tester-2214',blue-green-no='2' 그린의 파드 조회 명령이번 강의의 Blue-green은 실무용은 아니다. 실무에서는 ArgoCD를 주로 사용한다.