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

이번 주차는 Argo CD를 이용한 배포와 Blue/Green, Canary 배포 전략을 간단하게 사용할 수 있는 방법을 공부하고 실습했다. Argo CD는 GitOps 기반으로 관련된 Release Repo에서 수정이 발생하면 주기적으로 데이터를 가져와 운영 중인 서버와 비교하는 일을 자동으로 해줌. Git Repo와 kube-apiserver와도 연결이 되어 있기 때문에, CD 역할을 하면서 각 Resource의 상태를 그래프를 이용해 표시해줘서 이 부분은 Jenkins보다 좋았던 것 같다. 게다가, Argo CD의 ImageUpdater를 통해 Docker Hub의 Image가 업데이트 되는 것을 감지하여 Applications에 Annotations을 주는 것으로 특정 Image가 정해둔 패턴에 맞추어 업데이트가 되면 미리 설정해둔 배포 전략에 맞추어 자동으로 업그레이드가 진행되는 툴이었다. 솔직히, Deployment를 이용한 Blue/Green과 Canary 배포는 강의를 듣고 실습하면서 이것을 실전에 적용해볼 생각을 하니 조금 막막했다.. ㅎㅎ 하지만, Argo Rollouts를 이용한 방식은 너무 간편했고 미리 YAML 파일만 잘 짜두면 클릭 한 번으로 귀찮은 모든 일들이 이루어졌다. (Argo 그는... 신이야)복습 시간을 조금 가지고, 다시 일프로 강사님의 Sprint3과 4를 수강할 생각인데, 아직까지 지상편이라는 생각과 강사님이 첫 강의에서 보여주신 사진 때문에 조금 무섭긴 하다(저기서 익숙한 애들보다 처음 보는 애들이 더 많은 것 같다.. ㅎㅎ)드디어, 모든 강의가 끝나고 워밍업 클럽이 끝났다 !!k8s를 공부해야지.. 항상 생각했지만, 막막함에 계속 미루고 있었는데, 인프런의 워밍업 클럽 덕분에 좋은 강사님을 만나게 되어서 정말 좋은 경험이라고 생각한다

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

이번 주차에서는 본격적으로 배포 Tools를 이용하여 기존 배포와 k8s를 적용시킨 배포의 차이점에 대해 배우고 실제로 적용시켜 보았다. Jenkins를 이용하여 실제로 App을 빌드하여 실행 파일을 만들고 그 실행 파일을 Container Image 파일로 만들어 Docker Hub에 업로드하고 k8s에 kubectl 명령어를 이용해 실제로 배포 명령을 내리는 것까지 했다. Docker와 Containerd의 차이는 앞의 강의를 통해 배워서, 그냥 이론적으로만 알고 있었다. 하지만, 이번 미션을 통해 Docker로 생성되는 Image의 경우, Docker가 제공하는 다양한 기능들을 위해 메타데이터를 재구성해 Containerd보다 용량이 크다는 것을 확실히 알게되었다. Helm은 아직까지는 좀 사용하기 힘든 것 같다. 뭔가 잘 배우면 무조건 편해질 것 같은데, 아직 익숙해지지 않아서 그런 것 같다.

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

지난 주차에서는 쿠버네티스 동작의 큰 흐름을 잡았다면, 이번 주차는 각 Resources의 역할과 각 Pod들이 어떻게 상호작용하여 유기적으로 연결되어 있는 지 다루는 내용이었다. 공부를 할 수록 느끼는 것은 문서화를 잘 해야겠다는 것이다. 최대한 일정에 맞추어 강의를 따라가려고 노력하다 보니 어떻게든 이해하고 진행하고 있지만, 그 양이 너무 많아 정리를 잘해두어야 나중에 찾아봤을 때 기억을 되살리고 활용하기에 훨씬 수월할 것 같다. 이번 강의에는 각 Resources의 동작에 대한 내용이 대부분이었기 때문에 미션에 큰 어려움은 없었던 것 같다. 미션을 해결하기 위한 웬만한 내용들은 강의에 있었고 강사님께서 카페에 참고하면 좋은 관련 공식문서도 첨부해주신 덕분이다. 새롭게 알게 된 점은 Deployment를 통해 ReplicaSet을 생성하고 그 정보를 바탕으로 Pod가 생성된다는 것은 기존에 알았지만, Deployment의 Pod와 관련된 정보를 정의하는 부분인 template 속성 아래의 내용이 수정되었을 때, kubernetes에서는 새로운 ReplicaSet을 생성하고 문제가 생길 것은 대비해 기존의 ReplicaSet은 남겨둔다는 것은 몰랐다.처음에는 Deployment의 yaml 파일을 수정할 때마다 ReplicaSet이 그 횟수만큼 증식하여 내가 뭘 잘못한 건지 좀 무서웠지만, Roll Back을 위한 이유라는 것을 알고나서는 자연스럽게 행동하게 된 것 같다. Sprint 1은 쿠버네티스가 무엇이고 어떻게 동작하는 지 큰 흐름을 체험하기에는 좋은 강의라고 생각한다. 다만, 아직까지는 이 지식을 가지고 응용하여 무언가를 만들기에는 무리가 있는 것 같다.Sprint 2가 기대된다.

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

이번 주차는 쿠버네티스의 설치와 각 Object간의 연결에 대한 큰 흐름을 다루는 내용이었다. 사실, 큰 흐름 자체는 이해가 되지만 아직 이 환경을 내가 직접 만들어보라고 한다면 못 할 것 같다. 하지만, 완강 후에는 이 생각 또한 달라져 있을 것이라고 믿는다. 쿠버네티스를 공부하기 전에 Container를 좀 더 편하게 관리하고 이것을 모니터링하며 자동화 할 수 있다는 것은 알고 있었다.하지만, 추상적으로만 알고 있었지 무엇을 어떻게 한다는 것인지는 잘 모르는 상태였다. Docker를 공부할 때는 큰 어려움은 없었기에 쿠버네티스도 비슷한 것이라는 안일함으로 강의에 발을 들였다.하지만, 실상은 생소한 개념들과 무수한 yaml파일, 명령어들이 기다리고 있었다. 그래도 다행인지 큰 개념은 어느 정도 잡힌 것 같다. 쿠버네티스는 Pod라는 작은 단위로 배포를 하며, 이것은 1개 이상의 Container를 담을 수 있다는 것Pod에서 메모리 누수와 같은 문제로 서버가 다운되었을 때, 자동으로 재시작을 해준다는 것 (Self-Healing)Pod의 정의된 CPU 사용량을 초과할 경우 미리 yaml에 정의해둔 기준으로 Pod를 증가/감소 시킬 수 있다는 것 (Auto-Scaling)Rolling Update, Traffic Routing 등도 있지만 생략하겠다. 하지만, 여전히 개념이 잘 잡히지 않는 부분이 있다. Pod란 도대체 무엇인가?쿠버네티스에 배포하는 가장 작은 단위로 Pod를 사용한다는 것은 알겠다. 1개의 Pod에 Container를 여러 개 담을 수 있다는데, 아직까지 Pod를 여러 개 사용하는 상황과 1개의 Pod에서 여러 Container를 사용해 운영하는 환경의 차이를 잘 모르겠다. 이번 한 주는 아직 쿠버네티스에 익숙하지 않던 내가 점점 익숙해지는 과정이라고 생각한다. 그리고 강의를 진행하면서 지식이 부족했던 부분은 아무래도 개인적으로 정리해두고 따로 공부해야 될 부분인 것 같다. 다음 주차는 세부적인 개념에 대한 궁금증은 잠시 다른 곳에 접어두고 큰 그림을 보며 이해하려고 노력해봐야겠다.