[워밍업 클럽: 쿠버네티스] 4주차 발자국

[강의 수강 후 소감]4주간의 쿠버네티스 여정이 끝났다. 백엔드 개발자로 취업준비를 하고있었지만, 막상 인프라에 대해 깊게 이해하지 못하고 있었고, 쿠버네티스 강의를 인프런에서 우연히 마주해 수강을 시작했다.처음 시작했을 때는 꾸준히 강의듣고, 열심히 해보자고 의지를 다졌는데, 중간에 2주차부터 자꾸 미뤄왔던 것을 시작으로 성실히 수행하는 것과 거리가 멀어졌다. 그래도 틈틈히 강의를 들으면서 진도를 따라갔고, 처음으로 인프런 강의를 모두 수강해 수료증을 받아봤다! 워밍업 클럽이 없었다면, 계속 강의를 미루고 미루다가 수강 완료까지 많은 시간이 걸릴거라 예상된다. 쿠버네티스 Object에 대해 공부하고, CI/CD 배포와 연계해 쿠버네티스를 쓰는 방법을 배우며 실제로 앱을 만든 이후 이 인프라 환경을 구축하는 데 이번에 배운 내용을 꼭 써먹어봤으면 좋겠다. 나에게 의미있는 강의였고, 의미있는 4주간의 스터디였다.

[워밍업클럽: 쿠버네티스] 미션 #6. ArgoCD - Github 업데이트

큐브옵스 카페의 실습 미션을 기반으로 작성한 내용이다.https://cafe.naver.com/kubeops/553 1. ArgoCD로 App 생성 및 배포1-1. App 생성 하기▶ GENERALApplication Name : api-tester-2232-build-push-git Project Name : default SYNC POLICY : Manual▶ SOURCE※ 은 본인의 Username으로 수정Repository URL : https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2.git Revision : main Path : 2232-build-push-git/deploy/helm/api-tester▶ DESTINATIONCluster URL : https://kubernetes.default.svc Namespace : anotherclass-223▶ HELM 확인 후 Values files 지정VALUES FILES : values-dev.yamlCreate 버튼으로 App 생성을 하면다음과 같은 ArgoCD App이 만들어지게 된다(Healthy 같이 초록창이 뜨지는 않음). 1-2. 자동 배포 설정api-tester-2232-build-push-git > details > SYNC POLICY 순서로 클릭을 해서 아래와 같이 만들자.1-3. 자동 배포 확인잠시 기다리면 Healthy 상태가 되며 파드가 생성될거고, 대시보드를 확인하면 anotherclass-223 ns에 파드가 생성된 걸 볼수 있다. 2. Jenkins에 Github Token 등록카페에 가면 Github에서 토큰을 생성하는 방법이 자세하게 나와있다. 가서 배우자.토큰을 받은 후에 젠킨스 설정에 토큰을 등록하게 되면,Jenkins관리 > Credentials에서 github_token을 확인할 수 있다. Jekninsfile 에서 Credential 사용 확인▶ 2232-build-push-git > JenkinsfileJenkinsfile을 보면, github_token으로 github USERNAME과 PASSWORD로 깃허브에 파일을 업데이트하는 동작을 수행한다. 3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기3-1.새보기 및 item 생성[새보기] 만들기 -> 조회명 : 223, Type : List View [item name] 만들기 -> item name :2232-build-push-git, [Pipeline] 선택 3-2. Configure▶ Configure > General > GitHub project > Project urlProject url : https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2/▶ Configure > Advanced Project Options > Pipeline > [저장]※ 은 본인의 Username으로 수정Definition : Pipeline script from SCM Definition > SCM : Git Definition > SCM > Repositories > Repository URL : https://github.com//kubernetes-anotherclass-sprint2.git Definition > SCM > Branches to build > Branch Specifier : */main Definition > SCM > Branches to build > Additional Behaviours > Sparse Checkout paths > Path : 2232-build-push-git Definition > Script Path : 2232-build-push-git/Jenkinsfile3-3.[저장] 후 [지금 빌드] 실행 (이때는 파라미터가 없어서 실행되지 않아요!)3-4.[파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행3-5.Stage View결과 확인​3-6. ArgoCD에서 자동 배포 확인​새로운 이미지가 들어온 걸 인식해서 생성한 후,이미지가 교체된 모습을 볼 수 있다.3-7. 다시 빌드 후 재확인깃허브에도 변경내용이 잘 반영된걸 볼 수 있다.

[워밍업 클럽: 쿠버네티스] 3주차 발자국

3주차 발자국을 정리하고 있지만,4주차 마무리까지 이틀을 남겨둔 시점이다 😅많이 밀리고 밀렸지만, 그래도 이번주에 여유가 생겨서 그동안 미뤄뒀던 강의를 수강하고, 복습해서 이제 마지막 ArgoCD강의 만을 남겨두고 있다..!2주차까지 쿠버네티스의 Object, 환경구성에 대해 배웠다면,3주차부터는 쿠버네티스와 연결되는 CI/CD 환경을 구축하는 법을 배웠고,주로 Jenkins를 사용해 어떻게 CI/CD 서버를 설치하고, Jenkins로 어떻게 빌드와 배포 흐름을 구성하고,파이프라인을 어떻게 구성하고, 스크립트를 어떻게 해석하고 봐야하는지에 대해 배웠다.배포를 하는 Blue/Green 방식을 추가로 배우고 실습까지 해봤고,마지막에는 Helm과 Kustomize에 대해 배웠다.수강을 하고 복습을 하니 어렵고 어려운 개념이라는 생각이 들었다.4주간 꾸준히 달려오지는 못했지만, 틈틈히 공부하고 복습해 어느덧 마지막 실습강의만을 남겨둔 상태다.남은 시간동안 마무리까지 잘 해서 최종적으로 수료해보도록 하겠다..!

[워밍업클럽: 쿠버네티스] #13. Helm과 Kustomize 비교하기 (3주차)

Helm, Kustomize 내용정리 kubectl -> Helm, Kustomize 사용해보기쿠버네티스 배포를 위한 배포툴로 (jenkins, argoCD) 등을 사용한다.지금까지 배포 툴 위에서 kubectl로 쿠버네티스에 배포 명령(create, apply)을 해왔으나, CLI 명령으론 배포를 위한 부가적인 기능을 기대하기는 어렵다.실무에서는 자원 생성 간 대부분 헬름, 커스터마이즈를 이용해 생성하며, App을 빠르게 조회하거나, 급한 수정이 있을 경우에만 kubectl을 활용한다.헬름과 커스터마이즈는 배포툴에서 동작하는 패키지 매니저 이며, kubectl과는 다르게 앱을 구성하는 yaml 파일들을 패키지 단위로 관리를 한다. 이는 kubectl처럼 여러 yaml 파일을 apply 해줄 필요 없이 한꺼번에 패키지로 처리해주는 것이다. Helm vs Kustomize 비교 정리공통 부분사용하는 목적이 동일하다. 배포를 위한 여러 yaml 파일들을 중복 관리하는 걸 최소화한다. App 종류가 많아지면(MSA 방식 채택 시) 다양한 yaml파일들을 관리해야 하는 불편함이 생기고, 이때 패키지 단위로 yaml을 관리하게 되면 중복으로 yaml파일들을 관리할 필요가 없어진다. 다양한 배포 툴(argoCD, github actions 등)에서 헬름과 커스터마이즈를 지원해준다.차이점배포 편의기능 수 Helm : 200개 ↔ Kustomize : 10개패키지 하나 당 사용하는 활용 범위(권고사항) Helm : MSA 이용하는 경우 And 다양한 배포 환경 (두 목적 모두 가능) Kustomize : MSA 이용 경우 OR 다양한 배포 환경 (둘 중 하나만) →커스터마이즈는 활용 범위가 늘어날 수록 패키지 내부 파일량이 많아지는 구조 (파일관리 복잡해질 수 있음)사용 목적 Helm: 프로젝트관리 패키지용 + 기업 제품 패키지용 Kustomize: 프로젝트관리 패키지용유즈케이스 Helm : 대형 프로젝트에 사용 (App 종류 5개 이상) Kustomize: 간단한 프로젝트에 사용 (5개 미만)Helm은 깃허브에서 다운 받아 설치해서, helm이 동작할 폴더를 생성하는 helm command를 사용해 세팅한다(helm create). Artifact HUB라는 Helm 패키지 저장소를 이용한다(Docker Hub느낌). Kustomize는 kubectl에 포함되어있어서 kubectl -k 명령어로 바로 사용할 수 있다(따로 설치 x).사용 방식 Helm : 템플릿 및 변수주입 방식template 폴더 안에 많은 yaml 파일들이 들어있는 구조이다. helm command로 변수를 주입하는 경우, helm install api-tester-32222 ./app -set port=’80’ -set profile=’dev’ -set nodeport=’32222’ 이렇게 파라미터 값을 주게되면, yaml 파일에 해당되는 파라미터 값을 채워준다.command를 쓰지 않고 파일에 변수 값을 주는 경우, values.yaml, Chart.yaml 등의 파일에 해당 값에 맞는 파라미터를 주입하는 방식을 많이 사용한다.Kustomize : 오버레이 방식 base 폴더 안에 파라미터 값이 없는 yaml 파일이 주어지고, kubectl apply -k ./app/overlays/dev 명령어를 주게 되면, 해당 명령어 뒤에 표시한 파일을 베이스 파일에 덮어쓴다. 즉, 기본 base에 있는 값은 그대로 반영을 하되, 같은 내용이 있는 파일을 덮어 쓸 경우 오버레이한 값으로 수정하고, 내용이 없는 경우 base에 추가를 한다(덮어쓰기). Helm 폴더 살펴보기helm create api-tester 명령어로 api-tester폴더 생성하면 아래와 같이 자동으로 패키지들이 만들어짐Helm 공식문서에 나온 helm create 명령어.생성한 폴더 아래에 yaml파일, ignore파일, charts와 templates 폴더가 생성된다..helmignorehelm은 폴더에 있는 내용 전체를 가지고 배포 yaml 파일을 만들게 되는데, 이때 ignore 파일에 배포하고 싶지 않은 파일목록을 추가해 헬름 차트에서 배포할 파일을 제외할 수 있다. 즉, 배포안할 yaml 파일을 여기에 선언하면됨이런식으로 gitignore같이 파일에 적어두면 여기에 적힌 파일은 배포간에 제외된다.Chart.yaml차트 자체의 기본정보를 선언하는 파일이다. 파일 내에 차트 이름, 버전, App 버전(image) 등이 선언된다.values.yaml배포할 yaml 파일에 들어가는 변수들의 기본값 선언하는 파일이다.templates 폴더 및 하위 파일쿠버네티스에서 필요한 각 yaml들이 여기에 담긴다. tests 폴더 : 메인 App이 배포된 후에 통신이 되는지 체크하는 용도(이번 강의에선 삭제)_helpers.tpl : 사용자 전역변수를 선언하는 파일, 이전에 valus.yaml에서 변수들의 기본값을 선언했지만, 추가로 변수 값들을 가공해 임의의 전역 값을 만들 수 있다.NOTES.txt : 배포 후 안내문구이외의 yaml파일 : 배포때 사용되는 yaml파일들 Kustomize 폴더 살펴보기helm과는 다르게 커스터마이즈는 폴더를 직접 만들어야한다. 심지어 하위 폴더 구성까지도..base 폴더 디폴트로 포맷이 될 yaml파일들을 넣는 폴더이다(helm에서 templates와 유사).kustomization 파일: 이 파일을 통해 우리가 배포할 파일들을 선택하고(helm에서 ignore와 유사), yaml파일에서 공통값(파라미터)를 설정한다(helm에서 values와 유사). 즉, helm에서 ignore와 values의 역할을 모두 맡은 파일이다.역할 : resources 배포 파일 선택 해당 영역에서 내가 배포할 파일을 명시한다. (헬름에서는 values.yaml에서 각 배포파일의 파라미터로 false를 설정해 배포하지 못하게 했음) 역할 : commonLabels 공통값 설정해당 파일에서 commonLabels 요소에 넣고싶은 값들을 넣으면, 모든 yaml 파일에 해당 내용이 labels로 들어간다. (헬름에서는 Deployment 템플릿에 변수를 설정하고, 특정 파일들마다 변수를 주입하는 방식이 다양했음)overlays 폴더오버레이를 할 영역에 대한 상위 폴더이고,(dev,qa,prod 등) 해당 폴더마다 각 환경에 맞게 오버레이할 파일을 넣어야한다.개발 환경을 배포하는경우 kubectl apply -k ./app/overlays/dev 이런 식으로 배포 명령을 준다.반면 Helm의 경우,values.yaml 파일을 환경별로 values-dev / values-qa / values-prod .yaml 이렇게 구분하고, 배포 명령을 할 때 -f 옵션을 추가해서helm install api-tester-32222 ./app -f ./app/values-dev.yaml 이렇게 선택한다.배포 파이프라인 구축 후 생기는 고민들 인증서 보안배포에 필요한 쿠버네티스 인증서, config.json(Docker로그인 정보) 가 서버에 노출되고,이 파일들은 암호화되지 않은 파일이다.config.json은 base64로, 디코딩하면 정보를 알 수 있는 파일이며,쿠버네티스 인증서 (kubeconfig)도 파일 자체로 관리자 권한 인증서라 관리자 권한으로 쿠버네티스 클러스터에 API를 호출할 수 있게 된다.그래서 우리는 이 중요 데이터들을 타인이 활용하지 못하도록 암호화하는 과정이 필요하다.Jenkins의 Credential을 이용하면 암호화할 수 있고, 추가로 도커 config.json은 도커에 로그인 할때마다 추가로 config 파일이 새로 만들어지기 떄문에, 배포시마다 도커허브로 업로드할 때 로그인한 이후에 종료시점에는 항상 로그아웃을 해야한다.(로그아웃 시 접속정보 삭제됨) 물론 Docker-credential-helpers 를 이용하게되면 파일을 열어도 비밀번호가 노출이 안되는 기능을 제공한다. 컨테이너 이미지 제거CICD 서버에서 컨테이너 빌드를 계속 하다보면 이미지들이 쌓이게 되고, 디스크 용량이 다 차게 되면 jenkins가 죽게된다.컨테이너 업로드가 완료되면 서버에 만들어진 이미지는 삭제해야한다.Helm으로 앱을 배포할 때 앱 하나마다 네임스페이스를 만들지 않고,네임스페이스를 미리 만들어두고, 여러 앱들을 한 네임스페이스 안에서 그룹으로 생성될 수 있다.네임스페이스는 배포와 별도로 관리하는 것이 좋다.인스톨 할때는 네임스페이스를 자동으로 만들어주는 기능이 있지만, 언인스톨 할 때는 네임스페이스를 자동삭제해주지 않음(여러 앱들이 한 네임스페이스에 있을 경우 다른 앱들도 같이 삭제될수 있어서) Helm 부가기능 (wait)배포 명령 실행 이후 wait 옵션을 주면 파드가 정상기동이 되는 지 확인을 해주고, 정상적으로 파드와 통신이 되면 배포 종료라는 결과를 보내준다.Helm 부가기능 (Annotations)배포를 했지만 파드가 업그레이드 되지 않는 경우가 있다.위 경우는 Deployment파일에서 templates 스크립트 밑으로 내용의 변경이 있어야 업그레이드가 진행된다.이를 위해 metadata.annotations를 제공해 새 배포마다 랜덤값을 생성해 항상 업그레이드 되도록 한다. Tag (image에 붙이는 버전)Tag는 배포 환경마다 tag를 붙이는 성질이 달라진다.개발 환경에서는 잦은 배포로 versioning이 무의미해 지게 되고, 이 때 tag는 항상 latest로(최신버전의 App), pullPolicy: Always로 한다.Always는 이미지가 없을 때 항상 도커허브에서 이미지를 가져오는 방식이다.HUb가 미연동되어있는 경우, Pod 생성에 에러가 생긴다.Test(검증)나 Prop(운영)환경의 경우는 계획된 배포를 하며, versioning이 필수가 된다.이때 tag는 버전의 유의를 하게되고(항상 latest x), pullPolicy: IfNotPresent를 사용한다.IfNotPresent는 노드에 해당 이미지가 있는 경우 그것을 사용하고, 없을 때 도커허브에서 가져오는 방식이다.운영환경에서는 파드가 scale-out, scale-in 되는 경우가 자주 발생할 상황이 많고, 그럴 떄마다 이미지를 허브에서 가져오게 되면 비효율적이고, 허브에 연결되어있지 않은 경우 파드가 만들어지지 못하게 된다.프로젝트 규모가 커지게 되면, 개발 환경의 버전별로 롤백을 해서 다시 개발을 하는 상황도 생겨서, 빌드한 소스코드의 날짜를 기반으로 tag를 만드는 것이 좋고,latest 버전은 항상 새로운 버전마다 latest를 붙이는 것보단, 운영환경에서 안정적으로 쓰였던 가장 최신의 버전을 latest로 tag해 latest를 최신 안정화 버전으로 사용하는 것이 낫다.

[워밍업클럽: 쿠버네티스] #12. Jenkins Pipeline (3주차)

이번 내용은 Jenkins Pipeline의 기본 구성에 대해 살펴보고,GitHub에서 JenkinsFile을 통해 파이프라인을 더 세분화해서 살펴보고,Blue/Green 배포 방식을 체험해보고,파이프라인을 스크립트로 완전 자동화해볼 것이다. 모든 실습과정은 아래 큐브옵스 카페에 내용대로 진행했습니다.https://cafe.naver.com/f-e/cafes/30725715/articles/87 Jenkins Pipeline 기본 구성jenkins dashboard에서 pipeline item 을 선택한 후, Pipeline script에 직접 복사해 구성한 방식이다. script 내용을 살펴보자.pipieline{ } 코드 안에 여러 스크립트들이 들어가는 구조이다.중요한 것부터 흐름대로 정리해봤다.스크립트 내의 stage는 파이프라인의 흐름을 나타낸다. stages{ } 내에 여러 stage를 순서대로 나열하면 된다.각 stage마다 소스코드 빌드 / 컨테이너 빌드 / 쿠버네티스 배포 이렇게 나누었다.// 소스 빌드 // 755권한 필요 (윈도우에서 Git으로 소스 업로드시 권한은 644) sh "chmod +x ./gradlew" sh "gradle clean build"소스코드를 다운받고, 해당 소스코드에 대한 권한 부여하는 코드도 중요하고, 릴리즈파일 체크아웃에 대한 코드는 pipeline Syntax에서 Sample Step의 checkout 부분을 확인하면 관련 코드를 알 수 있다. 이 구조처럼 파이프라인을 구축할 수 도 있다.젠킨스를 마스터 슬레이브 구조로 설치를 하게 됐을떄, 슬레이브에서 스크립트를 돌리겠다는 의미이다.여러 스크립트를 돌릴 때 로드를 분산해주기 위함이다. Github 연결 및 파이프라인 세분화위 스크립트와 거의 동일하지만, 각 단계별로 스크립트를 더 세분화 했고,이번에는 GitHub에 Jenkinsfile로, jenkins dashboard에서 pipeline script from scm(소스관리도구, 즉 git)을 선택해 위 젠킨스파일의 경로를 표시해주면 스크립트 코드로 파이프라인을 읽어주게 된다.젠킨스 파일을 자세하게 분석하려면 아래 코드에서 확인할 수 있다.https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2/blob/main/2212/JenkinsfileBlue/Green 배포 적용전 단계와 파이프라인 구축은 유사하지만, 파이프라인 내용에 Blue/Green 배포를 적용한 개념이 들어가있다.https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2/blob/main/2213/Jenkinsfile파일 내에 Blue / Green 폴더를 구분해서 Blue폴더 내 파일들을 먼저 빌드한 후, 파드들이 Running 될 걸 확인한 후에,Green으로 배포하는 걸 눌러야한다.Green으로 배포하면 어떤 파일이 생성되고, 전환이 어떻게 이루어지는 지 스크립트에 나와있다. 파이프라인을 스크립트로 자동화https://github.com/wnsrlf0721/kubernetes-anotherclass-sprint2/blob/main/2214/Jenkinsfile 각 파이프라인 별로 어떻게 stage가 구성이 되는지, 또 Blue/Green 배포를 할 때 어떤 파일들을 배포해서 파드를 바꾸는지 흐름을 알게 되었다.

[워밍업 클럽:쿠버네티스] 미션#5. 컨테이너 이미지 사례 실습

해당 실습과정은 큐브옵스 카페의 미션을 실습한 과정입니다. Docker와 Containerd 명령 실습https://cafe.naver.com/f-e/cafes/30725715/articles/137 도커 (Docker)CI/CD 환경이 구축된 서버에서 진행▶ 사전 준비사항# 도커 파일 및 App 소스 다운로드 curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/Dockerfile curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/etc/docker/hello.js curl 명령어로 Dockerfile과 hello.js를 CI/CD 서버에 다운받았다. ​1. 빌드2. 이미지 리스트 조회docker image로 hello가 있는걸 확인 3. 태그 변경태크가 다른 이미지가 하나 더 생겼다. 4-1&2. 로그인 및 이미지 업로드Docker Hub를 확인하면 새로만든 hello image가 hub저장소에 있는 걸 확인 5. 이미지 삭제hello 이미지 1.0과 2.0 이 모두 CI/CD 서버에서 제거 된걸 확인 6. 이미지 다운로드Docker Hub에 저장된 hello 이미지를 서버로 다운로드함새로 1.0 hello가 생긴 걸 확인 7. 이미지 -> 파일로 변환hello 이미지를 file.tar로 변환하여 저장▶ 이미지 삭제8. 파일 -> 이미지로 변환file.tar 파일에 저장된 정보를 바탕으로 image load -> hello image 생성확인▶ 정리컨테이너디 (Containerd)쿠버네티스가 있는 인프라 환경에서 진행 ​1. 네임스페이스 조회2. 특정 네임스페이스 내 이미지 조회3. 다운로드 및 이미지 확인 (이미지는 default라는 네임스페이스에 다운 받아집니다.)default 네임스페이스가 생성되어졌고,default 에 hello image 생성을 확인 4. 태그 변경태그를 변경한 결과,이미지 1.0과 2.0이 존재하는 걸 확인 5. 업로드도커허브 상에 2.0 tag가 올라간걸 확인 6. 이미지 (namespace : default) -> 파일로 변환hello:1.0.0이 file.tar로 변환된걸 확인 7. 파일 -> 이미지로 변환 (namespace : k8s.io)k8s.io 네임스페이스에 file.tar 파일을 이미지로 변환해 저장한다.저장 결과 k8s.io 에 hello 이미지가 생성된걸 확인 8. 삭제 (namespace : k8s.io)같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유https://cafe.naver.com/f-e/cafes/30725715/articles/158 ▶ Docker Hub (248.26 MB)Docker Hub의 1pro/api-tester 이미지 중 latest tag를 다운받고 비교할 예정이다. ▶ Docker (490MB)▶ Containerd (248.3 MiB) 가정 1. Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다. ▶ Docker (amd64가 보임)▶ Containerd (amd64, arm64)가 보임containerd는 amd64와 arm64 두 버전을 모두 지원하는 이미지임에도 불구하고,amd64 한 버전만 지원하는 Docker의 이미지보다 크기가 작다.따라서 amd64이건 arm64이건 플랫폼에 따라 크기가 달라지는 건 아닌것 같다. 가정 2. Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회 됐을 것이다. 위 가정이 맞는 지 확인을 위해 전 가정에서 설치했던 Docker image -> Containerd 옮겨보고,Containerd image -> Docker 환경으로 옮겨보며 사이즈가 어떻게 바뀌나 확인해보겠습니다.▶ Docker -> ContainerdIMG -> 파일로 변환1pro/api-tester image 를 파일로 변환시킨 후 (docker-image.tar 생성)[root@cicd-server ~]# docker save -o docker-image.tar 1pro/api-tester:latest크기를 확인해보니 490MB -> 472MB 로 조금 줄어들었다.파일 복사 (CI/CD -> k8s 서버로)아래와 같이 파일을 인프라 환경에 복사시키고, k8s-master 서버에서 결과를 확인해보겠습니다.정상적으로 잘 받아온 걸 확인했고, 이제 이미지로 변환해서 자료 크기를 확인해야겠죠?파일 -> IMG 변환기존에 존재했던 이미지를 삭제시킨 후, 복사한 파일을 image로 변환시킵니다.이후 k8s 상 동작하는 image 사이즈를 확인하니, 472MB -> 248.3MiB로 바뀌었습니다.▶ Containerd -> DockerIMG -> 파일로 변환k8s 상 존재하는 이미지는 Docker에서 가져온 파일을 통해 만든 것이므로, Docker Hub에서 pull로 이미지를 다시 다운받음.이 이미지를 이제 파일로 변환하면 되겠죠?IMG (248.3MiB) -> 파일 (249M) 변환 완료파일 복사 (CI/CD -> k8s 서버로)CI/CD 환경 상에 잘 복사가 된걸 확인파일 -> IMG 변환기존 이미지 삭제 후 containerd에서 가져온 파일을 img로 변환사이즈 확인 (490MB) 가정 3. 쿠버네티스에는 다른 Runtime을 사용 했을 수 있고, 같은 이미지더라도 사용하는 Runtime에 따라서 이미지의 크기는 달라질 것이다.일프로 님의 설명에 따르면, Docker는 다른 많은 기능들을 지원해 주기 때문에 (ContainerD 외에도) 실제 이미지가 248.26MB라고 하더라도, 다운 받은 이후 자신의 매타데이터 규격에 맞게 데이터들을 더 추가하고 이미지를 재구성 합니다. 그래서 490MB로 사이즈가 늘어난것!Containerd에서 이미지를 파일로 바꿔 복사를 해도, Docker 상에서 돌아가는 이미지를 구성할 때 데이터들을 추가해주니 사이즈가 늘어난거라 이해하면 될것 같다.즉, 우리는 컨테이너 이미지를 받을 때, 쿠버네티스에서 ContainerD를 사용해 컨테이너를 동작시키는 경우, Docker를 통해 이미지를 만들 경우 불필요한 데이터로 인해 이미지 사이즈가 더 커지게 될 수 있다는 걸 확인했다.

[워밍업클럽: 쿠버네티스] #11. 배포 전에 알아줘야 할 것들

CI/CD 배포 환경을 만들 때, 몇가지 고려할 요소들을 생각한 후에 환경 구성방법을 선정해주는 것이 좋다.배포 환경 안에서 담당부분이 나누어 지는 경우. 운영 정책 상 한 배포 구성에서 개발 과 운영 파트를 분리하는 경우배포한 툴 제품 선정 시 보안 및 유지보수에 따라 선택하는 경우 로 하나씩 요소들을 살펴보겠다. 배포 환경 안에서 담당부분이 나누어 지는 경우CI/CD 환경에서 소스코드를 빌드하고, 컨테이너에 담아 배포하는 과정을 분리해서 담당하는 경우와, 파이프라인을 구축해 과정 전체를 한번에 배포까지 하는 경우로 구분할 수 있다.파이프라인을 구축해 자동화하는 것이 효과적으로 보일 수 있지만, 프로젝트 규모가 커지면서 관리해야하는 담당이 정해져 있는 경우엔 과정 하나하나를 분리해 업무를 분장하는 것이 효율적이다.각 상황에 맞추어서 소스 빌드는 개발자가 담당하고, 컨테이너를 빌드하고 배포하는 역할은 Devops 엔지니어가 담당하는 것과 같이 유동적으로 선정을 할 줄 아는 것이 좋다. 운영 정책 상 한 배포 구성에서 개발 과 운영 파트를 분리하는 경우젠킨스 빌드 환경 안에서 배포를 하는 경우도 가능하지만, ArgoCD를 통해 배포를 구성하는 경우도 가능하다.즉, 빌드 파트와 배포 파트를 분리하는 것이며, 이때 배포 환경과 인프라 환경을 구축할 때 1:N 관계로 한 배포 구성에서 개발과 운영 인프라를 구성하는 방법과1:1 관계로 인프라 환경마다 배포 환경을 구성하는 경우 (개발, 운영 인프라 분리) 로 구분할 수 있다.각 인프라마다 배포 환경을 구성하는 경우(1:1) , 이중 관리가 필요해지지만 서로의 환경에 영향을 주는 것이 없어 한 인프라에 장애가 발생해도 다른 인프라에 영향도가 없다.반면 배포 환경 하나로 여러 인프라를 구성하는 경우(1:N), 관리의 부담은 줄어들지만 개발 인프라에서 장애가 발생하는 경우 운영 인프라에서도 장애를 받아 배포를 못하게 되는 등 영향을 받게된다.이렇게 어떤 구성을 하는 지에 따라 각각의 장단점이 존재하므로, 운영 정책에 따라 관리 편의성을 중시할 지 / 장애 영향도를 중시할 지 적절히 선택을 해야한다. 배포 툴 제품 선정 요소CI/CD 제품은 온라인용으로 GitHub Actions, CI tool로는 TravisCI, circleCI, 오프라인용으로 Jenkins, JenkinsX, Tenton, CD tool로 argoCD, Sprinaker 등이 있다.온라인용을 선택할 시 따로 CI/CD 서버를 별도 구성할 필요가 없다는 장점이 있으며, 오프라인용은 인터넷에 App의 데이터를 올리면 안되는 경우 선택을 한다. 금융권이나 의료기관 등 시스템에서 다루는 데이터가 중요한 경우 인터넷 영역으로 올리지 않으며, 오프라인 툴을 선택을 하는 것이다. 또한 컨테이너 빌드 시 도커를 쓰지 않고 다른 툴들을 사용하기도 한다. 도커는 기능이 많아 제품이 무겁다는 것과(자원 차지 많음), Daemon을 항상 유지해야하는 단점이 있다(리눅스 OS 백그라운드에 항상 실행되어야한다). 반대 개념인 Daemon리스트 앱, kubectl은 별도로 실행유지를 하지 않고 명령어만 사용할 때 실행을 하는 구조이다.그래서 도커로 컨테이너를 여러개 띄운 상태에서 데몬이 죽으면 컨테이너가 모두 다운된다는 단점이 존재한다. 그치만 CI/CD 환경에서 도커는 컨테이너 빌드용으로 사용되고, 인프라 환경에서 쿠버네티스를 통해 컨테이너를 띄우기 때문에 치명적인 단점이 되지는 않는다. 그래도 자원을 잘 활용하려는 상황에선 다른 툴을 사용하는 것이 좋고,대표적인 컨테이너 빌드 툴로 builah가 있다. 도커허브에서 podman으로 jdk 이미지를 받고, 컨테이너 빌드 후 skopeo로 이미지를 허브에 업로드 해주는 과정은 도커와 유사하지만, 자원사용량이 낮다는 장점이 있다. 배포전략배포 전략으로 Recreate, RollingUpdate, Blue/Green, Canary 가 있다.Recreate새로운 파드를 배포를 하게 되면, 기존의 파드들은 운영을 멈추고, 새로운 파드를 생성해 운영하는 방식이다.새로운 파드가 동작하기 전까지 기존 서비스가 운영하지 못하는 Downtime이 존재한다.RollingUpdate새로운 파드를 배포할 때, 기존 파드를 얼마나 줄이고, 새로운 파드를 얼마나 늘릴지 정해서 단계적으로 파드를 교체해나가는 방식이다. 서비스는 중단되지 않고 계속해서 운영된다는 특징이 있다.Recreate와 RollingUpdate 방식은 Deployment를 업데이트하면 자동으로 배포되는 방식이고,배포되는 동안 중지하거나, 기존 버전으로 롤백이 가능하다.또한 각 파드에 대한 트래픽을 조정하는 것은 불가능하며, 파드 개수만큼 트래픽이 1/n 분배되는 방식이다. Blue/Green기존 버전 v1의 Deployment를 업데이트하는 것이 아닌, 새로운 버전으로 v2 Deployment를 생성하면, 관련된 파드들이 추가로 생성이 된다. 이후 Service에서 기존 v1에서 v2로 selector를 변경해 새로운 파드에 트래픽이 들어오도록 변경해주면, 기존의 v1 Deployment를 삭제해주는 방식이 Blue/Green이다.이 방식은 수동으로 배포를 해주는 방식이라 도중에 문제를 발견하면 바로 롤백이 가능하다는 장점과, 배포 과정을 Script로 작성을 하게 되면 자동 배포도 가능해진다는 장점을 가진다.하지만 새로운 버전 v2로 전환한 직후 트래픽이 과도하게 들어올 경우 문제가 발생할 수 있다.앱이 처음 기동을 하면 memory, DB를 최적화하는 과정이 필요해 CPU 사용량이 늘어나게 되고, 해당 과정동안 트래픽이 많아지게 되면 파드가 죽어버리는 경우가 생길 수 있다. -> 사전에 부하 테스트를 통해 배포가 가능한 지 미리 확인하는 과정이 필요하다.또한 운영 DB에서만 테스트가 가능한 유즈케이스의 경우 Blue/Green 배포 방식이 최적의 케이스가 된다.CanaryBlue/Green 방식에서 각 서비스에 Ingress 리소스를 추가해 서비스마다 들어오는 트래픽 양을 조절할 수 있는 방식이다.Nginx 같은 Ingress Controller로 각 서비스의 Ingress마다 트래픽 수치를 조정할 수 있다는 장점을 가진다.Canary 방식은 특정 헤더 값에 한해서 다른 서비스에 트래픽 유입을 조정할 수 있다. SourcePort, User, Language 등 원하는 값을 설정해 특정 트래픽으로 다른 서비스에 유입시키는 방식의 유즈케이스에서 유용하다. 사실 Recreate 방식을 제외하면 모두 무중단배포라는 특징을 가진다. 하지만 무중단배포가 무조건 좋은것은 아니며,상황에 맞게 배포방식을 선택하는 것이 좋다. DB schema를 변경해야하는 경우 서버를 내리고 DB 작업을 마친 후에 다시 서버를 운영하는 것이 맞는 방식이다. 파이프라인 단계별로 구축하는 방법배포 방식으로 여러 방식을 사용하는 걸 앞서 요소 별로 살펴보았는데, 처음부터 파이프라인을 만들고, 배포 툴을 사용해서 CI/CD 환경을 구축하는 것보다, 최대한 간단한 방식으로 먼저 배포 구성을 해보고, 점차 방식을 바꿔가면서 툴을 추가하는 것이 안정적으로 구성하는 방법이다.Jenkins 기본 구성 -> 실습했던 방식처럼 Jenkins 환경 세팅 후, 소스코드 빌드, 컨테이너 빌드, 배포 방식을 구분해서 실행하는 방식이다. Jenkins Pipeline 구성jenkins Pipeline은 배포때 사용한 yaml파일, DockerFile처럼 JenkinsFile이라는 스크립트를 기반으로 파이프라인을 관리할 수 있다. 처음부터 Script를 구성하기 보단, Jenkins Dashboard에서 제공하는 UI로 먼저 만들어보고, 해당 구성에 맞게 샘플 코드를 알려주니 이후 Script 코드를 짜는 방식으로 나아가는 게 좋다.Kustomize, Helm 배포 툴 사용인프라 환경 별로 배포를 하려면 기존에는 각 환경마다 yaml파일을 복사해 값을 수정하는 방식을 사용했다면,배포 툴에선 Package를 통해 각 환경마다 다르게 줘야 할 변수들을 지정해 한 yaml 파일에 동적으로 값을 주는 방식을 사용할 수있다. 덕분에 yaml 여러개를 구성해 관리하지 않고, 하나의 yaml로 관리가 가능해졌다.ArgoCD로 빌드와 배포 분리Jenkins 환경에서 배포를 하는 것이 아닌, 새로운 배포 환경을 구성해 ArgoCD 환경에서 Helm 같은 배포 툴을 사용하는 방식이다. ArgoCD는 기존 yaml 파일 같은 스크립트 파일을 원격 저장소에 저장을 하면, 인프라 환경에 존재하는 파일과 비교를 하며 원격 저장소에서 값이 바뀌면 인프라에도 반영하거나, 인프라에서 수정되면 저장소 상에도 반영을 해주는 동기화를 제공한다. 또한 대시보드를 통해 k8s와 Resource 간의 관계도를 표현해주는 기능도 있어 유용하게 사용할 수 있다.

[워밍업클럽: 쿠버네티스] #10. Devops 환경 구축하기 (3주차)

강의 수강일자: 25.06.11(수)블로그 복습일자: 25.06.12(목) 이번 강의에서는 CI/CD 환경을 VM 가상환경으로 구성하고, VM에서 동작하는 각종 빌드 도구들을 설치하고 초기 세팅을 구성한다.Jenkins를 초기 세팅하고, Github에서 Spring App 소스코드를 받고, Gradle 빌드 툴로 빌드해 jar파일을 만들고,Docker를 통해 컨테이너 환경을 구성하고, 해당 컨테이너 내부에 jar 파일을 복사하고, 컨테이너 빌드를 한다.단계별로 구분을 하자면vagrant로 VM환경 세팅하기mobaxterm으로 CI/CD 프롬프트 구성하기 4. Jenkins 대시보스 초기환경 세팅하기 5. 6. VM서버에 Docker 사용 설정하기 7. 쿠버네티스 마스터노드에서 인증서 복사 -> CI/CD 서버에서 kubectl을 사용하기 위함 8. 9. 소스코드 빌드 및 컨테이너 빌드, 컨테이너 배포이렇게 구분할 수 있다. https://cafe.naver.com/f-e/cafes/30725715/articles/84위 카페 링크를 통해 자세한 실습 과정을 볼 수 있으니 궁금하면 참고하면 되겠다!

[워밍업클럽: 쿠버네티스] #9. Devops 한방정리

강의 수강일자: 25.06.10(화)블로그 복습일자: 25.06.12(목) 가볍게 데브옵스에 대해 흐름을 살펴보는 강의였다.앱 개발 -> 빌드 -> 배포 및 실행 을 내 pc환경에서 지금까지 실행했다면, 데브옵스를 적용하면 앱 개발 파트를 내 pc에서 개발 및 테스트 이후 소스코드를 깃허브에 올리고,깃허브에 여러 사람들이 올린 코드를 빌드 툴(jenkens 등) 을 이용해 자동 빌드하고, 빌드 후 만들어진 jar 파일을 도커 허브에 업로드하는 과정을 거친다. 도커 허브에 올리려면 파일을 컨테이너에 올려야 하는데, 도커로 컨테이너를 빌드하고, 해당 컨테이너에 파일을 올린 후, 해당 컨테이너를 내 도커허브에 올린다.이후 젠킨스에서 배포를 진행하면, kubectl을 통해 쿠버네티스 상에 컨테이너 생성 명령을 내리고, 컨테이너에 생성되는 이미지 주소를 확인해 도커허브에서 이미지를 다운받고, 해당 이미지에 대한 컨테이너 생성을 런타임에 요청한다. 이후 쿠버네티스 상에서 컨테이너를 운영을 해준다. 운영간에 사용되는 쿠버네티스의 클러스터, 오브젝트들은 sprint1에서 배웠던 내용이다. 인프라 환경에서 App을 실행한 후, 잘 돌아가는 지. loki나 grafana로 모니터링도 가능하다. 구체적으로 CI/CD 환경을 구축하고, 인프라 환경에 App을 배포하는 과정은 다음 강의에서 다룰 예정이라,이번 강의에서는 전체적인 흐름을 다시 짚고 넘어가는 느낌이 들었다. 정말 가볍게 강의를 듣고, 흐름을 파악하는 정도로 들었다.

[워밍업클럽: 쿠버네티스] 2주차 발자국

어느덧 sprint1 을 마무리하고, 쿠버네티스에 대해 전체적인 흐름을 배우게 됐습니다.1주차까지 잘 따라왔지만, 2주차에는 학습을 하는 것이 계획대로 원활하게 흘러가지 못했습니다.연휴동안 부산여행을 즐기면서 잠시 공부를 내려놨고, 2주차 공부 계획이 3주차까지 미뤄졌습니다.강의를 듣는 것 까진 수월했는데, 역시 복습을 하고 블로그를 쓰고, 미션을 진행하며 기록하는 게 생각보다 시간이 많이 걸리는 일입니다. 2주차에 배운 내용을 간략하게 돌아보면, 1주차에서 설치했던 쿠버네티스 스크립트를 정밀하게 분석해보는 내용이라 느꼈습니다.Probe, Deployment, Configmap, Secret, PVC, PV, HPA, Service 등등 생각나는 오브젝트 이름들을 적어보고 각각 어떤 기능들을 담당하는지 조금은 알것 같습니다. 스토리지에 관련된 PV 오브젝트에서는 솔루션을 어떻게 사용하는지 자세하게 다루지는 않았지만, 이후에 천천히 공부해보고 싶은 생각도 들었습니다.스크립트 기반으로 어떤 코드가 어떤 역할을 하는 지 배우는 것도 좋았지만, 마지막에 컴포넌트 기반으로 흐름을 정리해보는게 가장 와닿았습니다. 대시보드 기반으로 오브젝트를 보고 수정했지만, kubectl을 사용해 파드를 보고, 클러스터들이 각각 담당하는 업무들이 연계되어 쿠버네티스가 동작하는 모습이 복잡하지만 대략적으로 이해가 되는 느낌입니다. 쿠버네티스가 담당하는 각 오브젝트들의 특성을 이해하고, 이 내용을 기반으로 다음 sprint2에서 잘 연결해 CICD까지 학습하고, 데브옵스에 대한 지식을 내걸로 만들 수 있게 기록하며 한걸음씩 성장하겠습니다. 백엔드 개발자로 취업을 하기 위해 각종 공부들을 하고 있지만, 아직 어떤 일을 하고 싶은지는 잘 와닿지 않습니다.여러 경험들을 겪으면서 얕지만 넓게 배워보고, 관심있는 분야를 찾아보고 싶습니다!