인프런 워밍업 클럽 4기 - DevOps 4주차 발자국

k8s 리소스를 직접 배포하는것 보다 heml Kustomize 등의 배포 패키지 툴을 사용하는게 더 좋다.헬름은 Chart라는 패키지 형태로 앱을 관리하며, 템플릿 기반 manifest에, values-{stage}.yaml, Chart.yaml, _hepers.tpl, helm command --set option 등을 활용해 동적으로 값을 주입할 수 있다.반면 Kustomize는 Base 설정에 Overlay 방식으로 특정 환경에 대한 설정들을 덮어서 환경별로 다른 설정을 적용한다.overlay하는 dir에 있는 모든 리소스를 적용하느게 아니라 kustomization.yaml 에 설정된 config에 따라 부분 적용이 가능하다.배포 파이프라인을 만들면서 드는 고민과 답변들배포에 사용되는 여러 툴 인증정보를 어떻게 관리할 것인가 > 배포툴의 Credentials 에 한번 정보를 기입해두고, 각 스테이지 별로 Credential 의 데이터를 가져와 처리하도록 한다. (cicd 서버 디스크에 직접 저장 X)젠킨스 Credential, docker-credential-helpers..)컨테이너 이미지 용량 관리 > 이미지별 LC를 두고 제거k8s 는 도커와 달리 이미지를 처리하는 gc 가 존재해, config 에 따로 설정하지 않으면 자동으로 안쓰는 이미지를 제거해준다.네임 스페이스 관리 > 특히 여러 서비스가 존재하고 독립적으로 관리된다면, NS 설정은 리소스 배포와 독립적으로 두는게 낫다배포 파드가 onService인지 확인 > helm --wait 옵션으로 배포 프로세스중 파드가 잘 뜬 다음 다음 단계로 진행시킬 수 있다.배포시 파드가 업데이트 되지 않는 경우들 > deployments 는 내부 template 프로퍼티 하위값들이 바뀌어야 config에 맞춘 파드를 다시 띄운다.template.spec.metadata에 배포를 위한 값을 넣음으로써, 배포를 강제할 수 있다.이를테면 어플리케이션 컨테이너의 변경때 사용가능!이미지별 태그 관리개발 환경처럼 잦은 배포가 있는 경우 version이 무의미할 수 있다.이 때 latest tag + Always pullPolicy 가 적합그러나 배포 관리가 필요한 운영환경에는 version이 필수이다.이 때 version tag + IfNotPresent pullpoilcy 가 적합k8s 클러스터 내부에 이미지가 있다면 굳이 허브를 거칠 필요없이 바로 세팅 가능하다.비슷하게 개발환경에도 롤백이 필요하다면 버전관리가 필요하고 해당 태그 정책을 가져가면 좋다.Argo k8s 워크플로우 및 배포 관리를 위한 오픈소스 프로젝트 모음으로, GitOps 방식으로 배포를 관리하며, CNCF 졸업 프로젝트이다.ArgoCD: GitOps 기반 배포관리 툴깃에 k8s manifest를 저장하고, ArgoCD가 이 레포를 모니터링하면서 diff 감지 및 동기화 (Sync) 해주는 툴ImageUpdater: 도커 허브에서 특정 이미지를 모니터링하면서 diff 감지해 자동 배포하는 툴Argo Wrokflow: Airflow, Kubeflow와 같은 워크플로우 매니지먼트 툴Argo Events: 카프카와 같은 이벤트 버스 툴 Argo Rollouts: 블루그린, 카나리 배포등을 지원하는 툴k8s 클러스터에 설치되는 Argo 컴포넌트들은 아래와 같다.Server: API 서버와 대시보드 역할 (웹 UI 및 API(CLI) 서버 역할)Repo Server: 깃 저장소와 연결해 배포할 yaml 가져오고 k8s 배포할 manifest 생성Application Controller: 깃에서 가져온 Desired Manifest 와 k8s 실제 적용된 Manifest를 비교하는 역할 & 필요하면 동기화 작업 수행KubeAPI: k8s 리소스에 명령을 날려주는 역할Redis: argo 시스템내 캐시 처리Dex: 외부 인증 시스템 연동AgoCD로 배포k8s 클러스터에 argoCD 배포argoCD를 통해 배포 관련 레포를 받아 k8s 클러스터에 배포Application이 배포하는 앱 단위이고, Poeject로 그룹핑 가능Source: 깃헙 소스 정보 / Destination: k8s 클러스터 정보General ~ 그룹명, 앱명, SyncPolicy (배포 정책 ~수동/자동), SyncOption(배포 상세 옵션) / PrunePolicy(리소스 삭제 정책)Desired Manifest ~ diff ~ Live Manifest, 로 Git 소스 중심의 차이점 파악IamgeUpdater도커 허브 감지하다가 이미지 업데이트시 ArgoCD에 자동 배포 명령Helm or Kustomize 를 활용해야 사용 가능하며 (내부에서 해당 패키지툴 명령어 사용)argoCD 앱 정보와 도커 허브 연결정보를 IamgeUpdater에 넣어서 감지 및 반영(배포)를 자동화Argo RolloutArgoCD 없이 사용 가능하며, CRD를 통해 k8s Deployments 리소스를 배포와 관련해 확장해 만듦블루그린 배포시 preview 서비스를 만들고, 자동으로 Service를 붙였다 떼주며.카나리 배포시 특정 조건에 따라 트래픽량 조정이 가능하며, steps를 통해 트래픽 주기 및 기타 설정을 단계별로 적용하며 배포프로세스를 유연하게 가져갈 수 있음4주차 학습 후기헬름 차트, Kustomize, Argo와 안면을 틀 수 있었던, 큰 그림을 이해해볼 수 있었던 시간!특히 헬름차트와 더욱 친해지고 내것으로 만들기위해 더 노력해야겠다!마지막 까지 다들 고생하셨습니다! & 좋은 강의 만들어주셔서 감사합니다 강사님!!

인프런 워밍업 클럽 4기 - DevOps 4주차-4 ArgoCD 빠르게 레벨업2 복습

인프런 워밍업 클럽 4기 - DevOps 4주차-3 ArgoCD 빠르게 레벨업2 복습/미션

미션ImageUpdater 없이 CICD 서버에서 업데이트한 App 이미지 버전을 깃에 넣어줘, argoCD 자동배포하기argoCD 셋업젠킨스 Credential 셋업 (깃 토큰 등록)젠킨스 파이프라인 셋업빌드 실행 (젠킨스 빌드후, argoCD 배포 확인)재배포 복습

인프런 워밍업 클럽 4기 - DevOps 4주차-2 ArgoCD 빠르게 레벨업-1 복습

인프런 워밍업 클럽 4기 - DevOps 3주차 발자국

결국 데브옵스에게 중요한건 개발 > 빌드 > 실행이다.시간이 흐름에 따라 툴들이 바뀌어도, 이 큰 흐름내의 작업이 될 것이기 때문이다. 이번주에는 cicd 서버가 띄워질 VM을 따로 띄웠고. 해당 서버에 젠킨스를 설치해, 자바로 만든 앱을 컨테이너에 올려 실제 서비스가 제공될 쿠버네티스 인프라 VM에 배포하는 환경을 만들었다.소스코드 관리는 깃헙으로 했고, 도커를 통해 jar 가 들어간 이미지를 빌드하고 허브에 저장해둔다.그리고 CICD 서버에서 kubectl 로 리모트 서버의 쿠버네티스 환경에서, kubectl apply 를 통해 리소스를 배포하면,Deployment.yaml에 적혀있는, 우리가 막 빌드한 이미지를 허브로 부터 다운받아 리소스를 다시 띄우도록 했다.이때 kubectl은 배포되는 환경의 인증서 정보가 필요해, .kube/config 파일을 scp로 받아와 설정해뒀다. CICD 배포시 고려해야 포인트들이 있다.소스 빌드, 컨테이너 빌드, 배포 ~ 의 책임소재에 따라 파이프라인을 어떻게 나눌지깃헙액션과 같은 온라인 툴 또는 젠킨스같은 오프라인 툴 중 어떤 것으로 CICD 환경을 구축할지배포툴을 하나만 두고 여러 배포환경에 대응하게해 관리적 이점을 살릴 것인지. 배포환경별 배포툴을 저마다 만들어 장애 격리등 운영 안정성을 높일 것인지컨테이너 빌드에는 도커를 사용할지 다른 툴을 사용할지.도커는 여러 기능이 있고 친숙해 다루기 편하지만, 무겁고 도커 데몬이 SingleFailurePoint가 될 수 있다.실제로 같은 이미지를 도커와 containerd에 받으면, 도커는 추가 메타데이터들을 붙여 이미지를 재구성해 이미지 사이즈가 더 커짐. (도커에서 받은 이미지를 tar로 export > 다른 컨테이너 런타임에 import 해도 도커전용의 큰 사이즈 이미지를 그대로 받아와, 이런 이미지 복사에 주의해야함!)쿠버네티스 배포에는 kubectl을 쓸지 아니면 Helm, Kustomize 처럼 패키지 관리 툴을 사용할지.배포 전략 ~ 아래중 어떤 전략으로 서비스 배포를 진행할지.다운타임이 생기지만 리소스 변화가 없는 Recreate복수 버전의 서버가 공존하지만 서비스 다운타임이 없는 RollingUpdate자원 사용량이 최대 2배까지 늘어날 수 있지만, 서비스 다운타임이 없고 롤백이 용이한 BlueGreen민감 데이터를 가진 서비스에서 신규 배포를 전부 셋업해 놓고, 따로 서비스를 붙여 테스트 하는 환경을 만들수도. 신규 배포환경을 세팅해, 트래픽을 적절히 늘려가며 배포할 수 있는 CanaryBlueGreen에서 일어날 수 있는 메모리디비, 디비 버퍼 등 콜드스타트에 따른 이슈들을 해소할 수 있고.헤더값을 통해 특정 트래픽만 v2로 보내, AB 테스트 / 배포전 QA 등을 처리할 수 있음.쿠버네티스에서 BlueGreen 배포는 젠킨스 + kubectl, argoCD 등으로 가능한데.기존 버전의 리소스들을 그대로 두고, 신규버전의 Deployment를 띄운 다음. 기존 리소스의 서비스 셀렉터를 바꿔줘 신규버전의 파드들에 트래픽을 보내는 식이다. Helm vs Kustomize둘다 복수 환경의 배포를 위한 다양한 Yaml 파일의 관리를 최적화 하는 목적에서 사용된다.Helm은 Kustomize 보다 배포 편의 기능이 많아 여러 케이스를 대응할 수 있지만 그만큼 복잡하다.HelmHelm은 kubectl 과 같이 kube-apiserver에 직접 API 요청을 한다. (인증서 정보 필수)또한 ArtifactHub라는 패키지 저장소가 존재해, 오픈소스 패키지들을 가져다 쓸 수 있다.함수방식으로메인 차트(리소스 패키지)의 리소스 yaml 파일들을 templates 하위에 둔다.그리고 각 템플릿 (.yaml)에 변수 자리를 두고, 아래 파일 혹은 명령어로부터 값을 입력받을 수 있는데.helm 명령어 (Release.X~)Chart.yaml(Chart.X~) - 차트 기본 메타데이터 선언Values.yaml(Values.x~) - 템플릿에 넣을 변수값 선언_helpers.tpl({{ include~) - values로부터 값을 받아, 로직을 통해 가공한 값 선언이런 방식으로 환경에 맞는 변수를 입력받아 최종 리소스 yaml 파일을 만들어 배포하는 형식이다. 헬름 템플릿은 go template 문법을 쓰기 때문에yaml 파일의 주석도 go template에 맞춰 {/** */} 형식으로 써야하고.{{-, nindent 등으로 우리가 보는 것과 같이 인덴트를 넣어 yaml 규격을 맞춰줘야 한다.위에 작성한 templates/xx, values.yaml, Chart.yaml 외에도 아래 파일 들이 있다..helmignore ~ 헬름 렌더링시 제외 파일 지정NOTES.txt ~ 헬름 배포 후 출력되는 일종의 안내문구 파일test ~ 앱의 통신상태 확인해주는 부가기능적 폴더charts/xx ~ 메인 차트외에 서브 앱들을 활용할 때 쓰이는 폴더

인프런 워밍업 클럽 4기 - DevOps 4주차-1 Helm & Kustomize2 복습

인프런 워밍업 클럽 4기 - DevOps 3주차-5 Helm & Kustomize1 복습

인프런 워밍업 클럽 4기 - DevOps 3주차-4 Jenkins Pipeline 복습

인프런 워밍업 클럽 4기 - DevOps 3주차-3 배포시작전 알것 복습 및 미션

미션도커미션 1~4도커미션 5~6도커 미션 7-8 ~ tar로 이미 저장 및 복구containerd미션 1~2containerd미션 3~8 > ctr default ns에 이미지 받고 태그 변경 및 도커허브에 업로드& 이후 tar로 이미지 export 후 기존 이미지 제거, 다시 importk8s.io 에도 이미지 올렸다 내릴수 있다 docker image size 비교 미션1 이미지 다운받은후 containerd와 docker에서 받은 이미지 사이즈비교2 docker -> containerd (아래 쉘 -> 위 쉘)3. containerd -> docker (위 쉘 -> 아래 쉘) ~ docker 환경에서 받은 tar 사이즈도 250mb 근데 도커에 임포트하니 500mb 복습 내용

인프런 워밍업 클럽 4기 - DevOps 3주차 손쉽게 데브옵스 환경을 구축하는 방법 복습

컨테이너 배포는, 마스터 노드에 마운트할 실제 파일경로가 없어서 에러가 났다. mkdir 2xx로 해줌 끝~