[미션6] ArgoCD - Github 업데이트

1. ArgoCD로 App 생성 및 배포 - 2232-build-push-git2. Jenkins에 Github Token 등록 3. Jeknins에서 Source/Container 빌드 후 Docker로 업로드 하기 4. ArgoCD에서 자동 배포 확인4-1. 다시 빌드 후 재확인

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

쿠버네티스에 대해 1도 몰랐던 내가,불과 4주 만에 이렇게 성장할 줄 누가 알았을까? 처음 인프런에서 '인프런 워밍업 클럽 4기’ 모집 메일을 받았을 때가장 눈에 들어온 건 ‘데브옵스’라는 단어였다.백엔드, CS, 데브옵스... 다양한 분야가 있었지만나는 왠지 모르게 데브옵스가 궁금했고, 직접 해보고 싶었다.도대체 데브옵스가 뭔데 이렇게 자주 나오는 걸까? 사실 나는 취준생이고, 인프라나 시스템 쪽은 낯설기만 했다.공고를 보다 보면 ‘쿠버네티스’, ‘도커’ 같은 단어들이 눈에 들어오는데,보는 순간 겁부터 났다. ‘나는 저런 거 몰라... 어렵겠다...’그런 생각이 계속 들었다. 역시 이럴때! 직접 해봐야 안다.4주 전만 해도 쿠버네티스에 쫄아 있던 내가,지금은 쿠버네티스, 도커, 데브옵스 보면왠지 친근하고 반갑다. ㅎㅎㅎ 이 정도면 대성공 아닌가?! 인프런 워밍업 클럽 4기 참여와 ‘쿠버네티스 어나더 클래스’ sprint1, sprint2를 통해나는 쿠버네티스를 단순히 ‘해봤다’에서 끝나는 게 아니라,‘계속 공부하고 싶다’, ‘더 알고 싶다’는 마음이 생겼다. 그리고 새로운 목표도 생겼다.나도 일프로님처럼 멋진 지식공유자가 되고 싶다!그러기 위해서:아는 것을 정리하고, 기록해서 내 것으로 만들기새로운 기술 앞에서 주저하지 않고 먼저 도전하기 비록 지금은 대기업에 다니는 것도, 엄청난 커리어를 가진 것도 아니지만,현실에 주저앉지 않고, ‘나도 1%의 삶을 누릴 수 있다’는 믿음을 가지고 나아가려고 한다. 나는 할 수 있다. 그리고, 끝까지 해볼 거다.앞으로도 나의 여정은 계속된다. 🔥🔥🔥

[미션5] 컨테이너 이미지 사례 실습

이번 미션을 통해 일잘러가 되어보자!🔥🔥🔥실무에서 많이 쓰는 명령어들 위주로 따라해보면 일잘러가 될 수 있도록 정리했다. Docker와 Containerd 명령 실습 도커 (Docker)사전 준비사항업로드 실습을 해보기 위해서는 본인의 도커 허브 Username 필요 --> wnnsla09전체 실습 명령어를 참고하여 실습 시작!빌드 2. 이미지 리스트 조회3. 태그 변경4-1. 로그인4-2. 이미지 업로드5. 이미지 삭제6. 이미지 다운로드7. 이미지 -> 파일로 변환▶ 이미지 삭제8. 파일 -> 이미지로 변환▶ 정리 컨테이너디 (Containerd)1. 네임스페이스 조회2. 특정 네임스페이스 내 이미지 조회3. 다운로드 및 이미지 확인 (이미지는 default라는 네임스페이스에 다운 받아진다.)4. 태그 변경5. 업로드6. 이미지 (namespace : default) -> 파일로 변환7. 파일 -> 이미지로 변환(namespace : k8s.io)8. 삭제(namespace : k8s.io)같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유 ▶Docker (490MB)▶ Containerd (248.3 MiB)Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다. Docker (amd64)Containerd (amd64, arm64) Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회Docker -> Containerd Containerd -> Docker도커는 "이미지 재구성"을 한다. 도커는 단순히 이미지를 다운로드하는 데서 끝나는 게 아니라, 자신의 포맷(도커 이미지 형식)에 맞게 레이어를 재정렬하고 필요한 메타데이터나 manifest 정보를 추가해서 재구성한다. 그래서 도커에서 보면: 원래 이미지 용량: 248MB → 도커에선: 490MB 이런 식으로 사이즈가 커진 이미지가 생긴다.이러한 사실을 바탕으로 나중에 혹시나.. 인터넷이 연결되지 않는 환경에서는 이미지들을 다운 받아서 파일 형태로 복사해야한다면 이때 쿠버네티스에서 컨테이너를 사용한다고 Docker로 받은 이미지를 복사해 넣을 경우 불필요하게 이미지 사이즈가 커지게 되는 상황을 만들지 않도록 주의해야한다. 꼭 명심하자🌟🌟🌟

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

데브옵스 한방 정리다른 내용도 있었지만 가장 흥미롭게 봤던 부분을 요약했다!GitOps: 데브옵스 파이프라인을 Git 하나로 통일/ 이슈, 협업관리,빌드, 테스트, 배포DevSecOps: 보안적인 요소까지 고려 및 자동화, 취약점 검사 체크MLOps: 머신너링 상품추천 사용자 행동 예측LLMOps: GPT 처럼 방대한 규모 머신너링에 특화덴 데브옵스 파이라인 필요FinOps: 클라우드 환경 비용 절감 포커스 손쉽게 데브옵스 환경을 구축하는 방법 배포를 시작하기 전에 반드시 알아야 할 것들강의도 듣고 미션5도 열심히 진행했다~미션5 진행 과정을 잘 작성해서 인프런 블로그에 남겨야겠다. 이번 미션5는 같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유와 Docker와 Containerd 명령 실습을 했다. 이번 실습에서 기억남은 것은 같은 이미지를 도커, 쿠버네티스에서 받았을 때 사이즈가 다른 이유와 관련된 실습이다. 도커는 "이미지 재구성"을 한다. 도커는 단순히 이미지를 다운로드하는 데서 끝나는 게 아니라, 자신의 포맷(도커 이미지 형식)에 맞게 레이어를 재정렬하고 필요한 메타데이터나 manifest 정보를 추가해서 재구성한다. 그래서 도커에서 보면: 원래 이미지 용량: 248MB → 도커에선: 490MB 이런 식으로 사이즈가 커진 이미지가 생긴다.이러한 사실을 바탕으로 나중에 혹시나.. 인터넷이 연결되지 않는 환경에서는 이미지들을 다운 받아서 파일 형태로 복사해야한다면 이때 쿠버네티스에서 컨테이너를 사용한다고 Docker로 받은 이미지를 복사해 넣을 경우 불필요하게 이미지 사이즈가 커지게 되는 상황을 만들지 않도록 주의해야한다. 꼭 명심하기! Jenkins Pipeline (기초부터 Blue/Green 까지) Helm과 Kustomize 비교하며 사용-1 회고벌써 4주차라니, 시간이 정말 빠르게 지나간다. 쿠버네티스랑 조금씩 친해지고 있는 느낌도 들고 ^^하하....실습하면서 “이건 왜 안 되지?”, “저건 왜 이러지?” 싶은 순간들이 아직 많다. 강의 들어도 한 번에 딱 이해되는 건 아니지만 신기하게도, 복습을 위해 다시 강의를 들으면 “아~ 그 말이었구나” 하고 이해되는 순간이 오기도 해서 재밌다.블로그를 쓰다 보면 “아, 이런 과정을 거쳤었구나” 하면서 다시 한 번 정리되고, 여러 감정이 스쳐 지나간다.매일 강의 하나씩 듣고 실습하고 복습하는 루틴을 이어왔을 뿐인데, 벌써 15개 넘는 블로그 글이 쌓였다는 게 뿌듯하다.마지막 미션도 열심히 해보려고 한다. 아직 1주차 복습 글을 쓰지 못했는데, 조만간 꼭 정리해서 마무리해야겠다.

Jenkins Pipeline (기초부터 Blue/Green 까지)

0. New view 만들기✅이전 작업 [새 보기] 만들어서 정리해 놓기✅[새 보기] 만들기 1. Jenkins Pipeline 기본 구성 만들기 (Step 1) - 2211✅Pipeline scriptDOCKERHUB_USERNAME과 GITHUB_USERNAME에 hyojung-leona 넣기✅Github에서 deployment.yaml 파일의 Image 수정image에서 1pro/api-tester:v1.0.0를 wnnsla09/api-tester:v1.0.0로 수정✅소스 빌드 Jenkins Pipeline 구조 이해 정리Agent- agent any : 사용가능한 에이전트에서 파이프라인 Stage를 실행, Master나 Salve 아무곳에서나 Stage가 실행- agent label(node) : 지정된 레이블(노드)에서 Stage가 실행- agent docker : Docker 빌드를 제공해주는 Agent 사용- agent dockerfile : Dockerfile 을 직접 쓸 수 있는 Agent 사용 2. Github 연결 및 파이프라인 세분화 (Step 2) - 2212✅2-1) item name 입력 및 Pipeline 선택✅2-2) [저장] 후 [지금 빌드] 실행 (이때는 파라미터가 없어서 실행되지 않는다)✅2-3) [파라미터와 함께 빌드] 선택 후 본인의 DockerHub와 Github의 Username 입력 후 [빌드] 실행✅tage View 결과 확인 ​3. Blue/Green 배포 만들기 및 특징 실습 (Step 3) - 2213✅3-1) item name 입력 및 Pipeline 선택 ✅3-2) Configure > Additional Behaviours 및 Script Path 수정 후 저장 ✅3-3) Master Node에서 version 조회 시작✅[Green 전환] yes 클릭 및 version 2로 버전 변경 확인✅3-4) 롤백 여부 선택 4. Blue/Green 자동 배포 Script 만들기 (Step 4) - 2214 ✅4-1) configure > Additional Behaviours 및 Script Path 수정 후 저장 ✅4-2) Master Node에서 version 조회 시작✅4-3) 진행 과정 확인✅4-4) Green 배포 확인 v2.0.0으로 변경 확인

배포를 시작하기 전에 반드시 알아야 할 것들

CI/CD 파이프라인을 구성할 때 고려해야 하는 요소 [CI/CD환경]빌드-> 컨테이너 빌드 -> kubectl , helm으로 배포Jenkins로 파이프라인을 구축( 빌드-> 컨테이너 빌드 -> 배포)개발자 빌드 -> DevOps엔지니어 Jenkins 파이프라인 구축 2번이 편한 것처럼 보이지만 수정할 일이 생겼을 때 1번처럼 담당하는 사람에 따라 분리하는 것이 좋다.1번으로 구성하고 각 과정에 트리거만 걸어놓으면 자동 배포가 된다. [배포와 인프라 환경 관계]1:NJenkins (소스빌드 컨테이너 빌드) -> ArgoCD를 통해 배포(kubectl, helm)장점: 관리 편의성 / 단점: 장애시 운영 환경에 영향도 높음 1:1(더 많이 사용)개발, 운영 환경마다 ArogoCD를 두기장점: 운영 환경에서 장애 영향 없음 / 단점: 이중 관리에 대한 부담 [CI/CD Tool]온라인: 깃허브 액션------------------------> 보안 good오프라인: jenkins , jenkinsX, Tekton------> 공공, 의료, 금융기관은 데이터가 인터넷 영역으로 올라가면 안됨. 그래서 오프라인 툴을 사용한다. [Docker 대체]도커 대체 이유: 무겁다, Daemon 필요(리눅스의 background에서 항상 돌아가야 사용 가능하다)대체제: buildahpodman과 skopeo 함께 사용배포 전략을 세울 때 고려해야 하는 요소 [Recreate]v1->v2 하고싶으면 기존 pod 삭제시킨다. 이때 downtime발생한다. 그리고 v2 새로운 파드가 만들어진다.배포는 Deployment 업데이트 하면 된다. / 에러 롤백 가능,트래픽 제어 불가능 [RollingUpdate]v1 서비스 진행->v2동시에 파드가 호출되는 구간있고 v2파드로 전환된다.배포는 Deployment 업데이트 하면 된다. / 에러 롤백 가능,트래픽 제어 불가능, 서비스 중단 없음 [Bule/Green]v2 deployment 만든다. label은 v2로 만든다. 서비스 셀렉터는 v1에서 v2로 수정한다. 트래픽이 v2으로만 들어가게 된다.수동 배포 시 롤백 빠름 / 스크립트를 통해 자동 배포 가능 / v2에 과도한 트래픽 유입시 문제 발생운영에서만 테스트한다--> blue/green 배포 쓰세요~ [Canary]배포용으로 새 서비스 만든다. Ingress 컨트롤러인 엔진 X 랑 각 서비스에 Ingress라는 리소스도 만들어 준다.트래픽 양을 조절할 수 있다.특정 헤더 값에 한해서만 v2 트래픽 유입콜드 스타트 방지, 두 버전 비교 가능 (A/B 테스트)단계별로 구축해보는 배포 파이프라인 Level1: 초반 구성할 때는 간단하고 직관적인 형태로 완성하기 Level2: Jenkins Pipeline 사용 Level3: Kustomize, Helm 배포쿠버네티스 앱들을 늘리기는 쉬워졌다. 하지만 하나씩 복사해서 네임이나 env를 수정하는 것도 귀찮다이렇게 동적 구성으로 한다면 조금 더 편해집니다. 출처: [인프런 쿠버네티스 어나더 클래스] 강좌 자료 Level4: ArgoCD 배포 분리

손쉽게 데브옵스 환경을 구축하는 방법

sprint1에서는 CI/CD 환경이 없었다. 인프라 환경에서 실습 했다.[전반적인 실습 & 구성]본격적인 sprint2이다. VirtualBox랑 Vagrant--> guest OS 만든다. -> 스크립트를 통해서 Liunx OS( Rocky Linux, kubectl), 컨테이너 빌드( docker), 빌드, 배포(git, gradle, jenkins, OpenJDK) 설치-> 설치 완료 -> 내 PC 브라우저에서 Jenkins dashboard 접속 -> 빌드 실행-> git hub 소스 다운-> 빌드 실행 내 도커 저장소에 이미지를 올린다.자신이 가입한 이름으로 변경 /app-tester깃허브에 내가 사용하는 Dockerhub 사용자 이름이 있어야 한다. 1. Vagrant 스크립트 실행2. CI/CD 서버로 접속 (Windows) 3. Jenkins 초기 세팅 4. 전역 설정 (JDK, Gradle)5. Docker Hub 가입6. Docker 사용 설정Login Succeeded 결과 확인7. Master Node에서 인증서 복사8. GitHub 가입9. 빌드/배포 파이프라인을 위한 스크립트 작성 및 실행마지막. Dashboard 확인하기

데브옵스 한방 정리

내가 데브옵스 엔지니어라면 어떻게 할까? 데브옵스에서 가장 중요한 것은 '개발을 하고 빌드하며실행가능한 파일들로 만든다' ✅개발환경: 내PC, intellJ 개발 툴킷 OpenJDK, spring framework 빌드 Gradle, jar 실행 파일--> OpenJDK에 있는 JVM 위에서 실행중요한 점! 빌드하고 실행하는데 OpenJDK 항상 필요하다. ✅인프라 환경: 실행파일과 JVM 필요, OpenJDK 만 있어도 된다. ✅CI/CD : 배포 과정 추가dev: App이 하나만 있는것은 아니다. 여러개가 있기에 개발자 통합 테스트용이다.qa: 전문 테스트 담당자용이다. 이 환경은 실제 운영할때처럼 세팅해야한다.prod: 이중화 필수!서버 다운이나 여러 장애가 발생했을 때를 대비한다. 2가지 케이스기존 구성: 컨테이너 도입 이전(jenkins, gradle로 빌드하겠다고 세팅) /만들어진 jar파일 인프라 환경으로 복사, 실행하라고 명령 보내기인프라 환경: 개발환경(무료OS+OpenJDK)과 운영환경(Redhat+OpenJDK)/ 개발환경에는 여러 개발자들이, 운영환경에는 외부 사용자들이 들어올 수 있다. 데브옵스를 구성하는 오픈소스CI: 통합된 소스를 가지고 테스트 자동화 시키는 기능을 만든다. / CD: 배포를 자동화 시킴 계획주로 노션 , slack기업은 내부 데이터를 외부에서 사용하려고 하는것을 꺼려한다. 그래서 기업 내부에 GitLab, 도커 레지스토리 제품 설치함. 개발JUnit: test용 빌드Gradle. Maven,docker 소스/컨테이너 테스트Junit 통합된 코드에서 오류가 생기거나 다른 결과가 나올 수 있으니까..기능/성능/커버리지 릴리즈배포가능한 패키지 만들기yaml파일 사전에 만들기, 깃허브에 미리 올리기 배포커스터마이즈 helm, Argo CD 운영NGINX, lstio 모니터링트래픽 흐름, Grafana, ZIPKIN (트래픽 확인)데브옵스 외 다른 Ops GitOps: 데브옵스 파이프라인을 Git 하나로 통일,이슈, 협업관리,빌드, 테스트, 배포DevSecOps: 보안적인 요소까지 고려 및 자동화, 취약점 검사 체크MLOps: 머신러닝 상품추천 사용자 행동 예측LLMOps: GPT 처럼 방대한 규모 머신너링에 특화된 데브옵스 파이라인 필요FinOps: 클라우드 환경 비용 절감 포커스

[미션4] PVC/PV, Deployment, Service, HPA 이해하기

▶PV, PVC😆local, hostPath 미션을 진행해보자!😆1) local 동작 확인 API - 파일 생성http://192.168.56.30:31231/create-file-podhttp://192.168.56.30:31231/create-file-pv// Container 임시 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it -- ls /usr/src/myapp/tmp // Container 영구저장 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it -- ls /usr/src/myapp/files/dev // master node 폴더 확인 [root@k8s-master ~]# ls /root/k8s-local-volume/1231// Pod 삭제 [root@k8s-master ~]# kubectl delete -n anotherclass-123 pod Pod 삭제 후 master node 폴더 확인했다.tmp삭제 되었고 dev에 있던 data는 남아 있다! 2) hostPath 동작 확인▶ Deployment😃Deployment 미션 진행 시작!😃1) RollingUpdate 하기// 1) HPA minReplica 2로 바꾸기 (이전 강의에서 minReplicas를 1로 바꿔놨었음) kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}'// 2) 지속적으로 Version호출 하기 (업데이트 동안 리턴 값 관찰) while true; do curl http://192.168.56.30:31231/version; sleep 2; echo ''; done; // 3) 별도의 원격 콘솔창을 열어서 업데이트 실행 kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 kubectl set image -n anotherclass-123 deployment/api-tester-1231 별도의 원격 콘솔창 열어서 업데이트 실행v1.0.0 , v2.0.0 반복되면서 점차 App Version이 업데이트 되고 있다!😁업데이트 완료!! 2) RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기maxUnavailable:25%->0% 수정 maxSurge:25%->100% 수정3) Recreate 하기4) Rollback ▶ Service1) Pod 내부에서 Service 명으로 API 호출 (서비스 디스커버리)2) Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정그리고 다시 Pod 내부에서 Service 명으로 API 호출▶HPA1) 부하 발생 & 확인2) behavior 미사용으로 적용 & 부하 발생 미션 끝~~~!! 길고 길었던 이번 미션… 그래도 이렇게 정리 딱! 하고 나니까… 뿌듯함이 솟아나는 중💛수고했당 나 자신 ✨

[미션3] Application 기능으로 이해하기 - Configmap, Secret

▶응용1 : Configmap의 환경변수들을 Secret을 사용해서 작성하고, App에서는 같은 결과가 나오도록 확인해 보세요 😃Step1. Secret 생성- dashboardStep2. Deployment의 envFrom.secretRef 부분 업데이트▶응용2 : 반대로 Secret의 DB정보를 Configmap으로 만들어보고 App을 동작시켜 보세요 😀쿠버네티스에서 configmap은 애플리케이션에 설정값(config)을 전달하는 방법configmap을 Volume에 연결해서 쓰는 케이스는 매우 많다.Deployment의 volumeMounts.name과 volumes 부분 업데이트