[DevOps] CI/CD 툴, 컨테이너 런타임

클라우드

[DevOps] CI/CD 툴, 컨테이너 런타임

dayeonsheep 2023. 6. 22. 04:38

CI/CD

:애플리케이션 개발 단계에 자동화를 도입하여 개발된 애플리케이션을 최종 사용자에게 전달하는 데 사용되는 순차적 방법론

CI/CD에 포함된 주요 개념은 지속적인 통합, 전달 및 배포

CI/CD Tool

개발, 배포, 테스트를 자동화 해주는 도구
DevOps 엔지니어가 사용하는 대표적인 CI/CD 툴로는, Jenkins / Travis CI / Bamboo
주요 퍼블릭 클라우드 공급업체는 모두 GitLab, CircleCI, Travis CI, Bamboo 등과 함께 CI/CD 솔루션을 제공
뿐만 아니라 DevOps의 기본 툴은 CI/CD 프로세스에 속해 있을 가능성이 높음
구성 자동화, 컨테이너 런타임(예: Docker, rkt, cri-o), 컨테이너 오케스트레이션(쿠버네티스)을 위한 툴은 엄밀하게는 CI/CD 툴이 아니지만 많은 CI/CD 워크플로우에 표시됨

주요 툴 목록: Jenkins, GitLab, Travis CI, Github action, Tekton, Azure Devops, codefresh, Buildkite, Buildbot, semaphore, go CD, Cloud Bees Codeship, Teamcity, circle CI, Bamboo, Weave Flux 등...

TeamCity 는 UI적으로 사용하기 편하고 많은 이점을 가져다주지만 VSC IDE와 연동이 어려움
Bamboo는 회사 내부적으로 JIRA를 사용하지 않으므로 연동했을 때의 이점이 크게 없음
Travis CI는 github와 연동했을 때 좋은 퍼포먼스를 보여주지만 무료용으로 사용하기엔 회사 플젝 레포가 private Repo 이므로 비용 지불이 큼
Circle CI는 github와 연동하기 쉽고 일정수준까지 무료로 사용가능, 하지만 실제로 사용시 비용지불은 피할 수 없음
젠킨스는 오픈 소스 Java 기반 서버로 완전 무료로 사용할 수 있고 레퍼런스도 많은 편. 하지만 젠킨스 서버가 죽거나 문제가 생길 경우에 대한 대처가 어렵고 또 플랫폼 자체의 UI가 타 플랫폼에 비해 세련되지 않은 편임

Q. 그럼 Kubernetes는 Docker에 종속되나요? Docker가 없으면 Kubernetes도 사용할 수 없나요?

A. 아닙니다! Kubernetes는 OCI(Open Container Initiative) 표준을 준수하는 다른 컨테이너 런타임도 지원합니다.

예를 들어, Containerd, CRI-O, rkt 등의 다른 컨테이너 런타임을 사용할 수 있습니다.

>>컨테이너 런타임이 무엇인고?

: 컨테이너 실행을 담당하는 SW

(Docker 자체가 컨테이너 런타임인가? kubelet은 Docker와 어떤 방식으로 상호작용하여서 컨테이너를 실행하는가?)

<Docker가 컨테이너 런타임으로서, 컨테이너를 실행하는 순서>

컨테이너 이미지 다운로드
이미지를 압축해제하여, 컨테이너의 파일시스템 'Bundle' 생성
Bundle로부터 컨테이너 생성

- 가상머신과 마찬가지로 컨테이너도 컨테이너 내부에 저장되는 소프트웨어를 담고 있는 파일들을 패키징할 수 있는 포맷이 필요한데, 가상머신의 OVF에 해당하는 표준이 OCI (Open Container Initiative)임.

*OVF => OVF는 여러 파일을 패키지로 포함하는 개방형 표준입니다. 예를 들어 .ovf, .vmdk, .nvram 등이 있음. OVF는 제품 및 플랫폼 간의 가상 장치 교환을 지원함.

- Docker는 세번째 단계, 즉 컨테이너 생성 기술에 대한 표준을 정해 runC라는 툴을 OCI에 제공하였음.

- 다만 1,2단계의 경우 표준화 및 분리되지 않은 상태로 꽤 오랜 시간이 지났고, 대다수의 사람들은 모든 컨테이너 런타임이 Docker처럼 1,2,3 단계를 전부 지원하는 것으로 착각할 수 밖에 없음.

- 그리고 컨테이너 시장 또한 1,2단계가 섞인 High Level Container Runtime 그리고 3단계만 담당하는 Low Level Container Runtime으로 나뉘어지는 계기가 됨.

Low Level Container Runtime

- Low Level Container Runtime은 오로지 컨테이너를 실행하는 기능만 제공

- OCI Runtime으로 부르기도 함

- 일반적으로 간단한 CLI 형태의 실행파일 또는 라이브러리로 존재하며, 개발자가 디버깅 목적으로 사용하는 경우를 제외하곤 High Level Container Runtime에 의해 호출되는 것이 일반적인 케이스

- 컨테이너는 namespace와 cgroups를 통해 구현됨

- namespace는 시스템 리소스(Filesystem, Network 등)의 가상화 및 격리를 가능케하고, cgroups는 컨테이너 안에서 사용할 수 있는 리소스의 양을 제한하는데 쓰임

- Low Level Container Runtime은 이러한 namespace와 cgroup의 설정 및 실행을 담당

- lmctfy, rkt, railcar 등 다양한 Low Level Container Runtime이 존재했지만, 현재 OCI 표준 스펙을 지키면서 살아남은 건 많지않으며 runC가 사실상 시장을 지배

High Level Container Runtime

- High Level Container Runtime은 이미지 관리, 압축해제, Low Level Container Runtime으로 전달 등 조금 더 고수준 작업을 수행

- 보통은 Daemon 방식으로 동작하며 Remote API를 제공하기 때문에, 외부에서 컨테이너를 실행하거나 모니터링이 가능

출처 https://cwal.tistory.com/category/Kubernetes/Architecture

- Docker는 원래 Low Level, High Level 모두 구현하였으나, 이후 여러개의 프로젝트로 분리되었으며 이는 각각 runC와 containerd로 발전

출처 https://www.samsungsds.com/kr/insights/docker.html

Docker 구성요소

- Docker는 위에서 설명한 것과 같이 더 이상 Monolithic 방식이 아닌 High Level/Low Level Container Runtime으로 분리되어 아래와 같은 모듈로 구성

dockerd

Docker Daemon으로 HTTP 기반 REST API를 제공하여 Client가 Container를 제어하고 이용할 수 있게 하는 Docker Daemaon 역할 수행 = Docker 데몬(dockerd)은 API 요청을 수신하고 이미지, 컨테이너, 네트워크 및 볼륨과 같은 Docker 객체를 관리

대부분은 containerd로 위임하지만, 일부 요청 작업(이미지 빌드, 네트워킹 등)은 직접 처리
containerd 구동, Docker Image Build (Dockerfile), Container Network 설정 (Bridge, iptables), Container Log 기록, docker-proxy 구동 등의 역할을 수행
기본값은 Unix Domain Socket이지만, TCP 방식으로 변경 가능하다.

containerd

containerd는 OCI (Open Container Initiative) Runtime Spec을 준수하는 dockerd에 요청에 따라서 config.json (Container Config) 파일을 생성하고 containerd-shim, runc를 이용하여 container를 생성하는 Daemon 역할을 수행
High Level Container Runtime 기능을 담당하며 Daemon 방식으로 REST API를 제공

runc

runc는 containerd가 생성한 config.json (Container Config) 파일을 통해서 Container를 실제로 생성하는 역할을 수행
Low Level Container Runtime 기능을 담당하고, runc의 원래 역할인 컨테이너 생성 후 바로 종료

containerd-shim

runc는 컨테이너를 생성한 후 즉시 종료되므로 컨테이너 안에서 생성되는 프로세스의 부모가 될 프로세스가 필요함, containerd-shimd은 컨테이너마다 배정되어 runc와 컨테이너 간의 가교 역할을 하는데, 예를 들어 컨테이너의 로그(stdout/stderr)을 가져오거나, 새로운 프로세스를 생성하는 등의 동작이 가능

<참고 레퍼런스>

<실제 실무 환경에서 CI/CD 를 어떻게 이용하는지 알 수 있어서 좋았던 글들>

https://engineering.linecorp.com/ko/blog/build-a-continuous-cicd-environment-based-on-data

데이터 기반으로 지속적인 CI/CD 개선 환경 만들기

들어가며 지난 1993년에 개봉했던 사랑의 블랙홀이라는 영화를 기억하시나요? 남자 주인공이 2월 2일 성촉절(Groundhog Day, 미국에서 마멋이 겨울잠에서 깨어난다고 여기는 날) 하루를 끊임없이

engineering.linecorp.com

https://engineering.linecorp.com/ko/blog/line-ads-devops-culture

LINE 광고 서버 개발 팀의 DevOps 문화

안녕하세요. LINE Ads에서 DSP(Demand Side Platform)를 개발하는 Demand Side Dev 3팀의 김남우입니다. Demand Side Dev 3팀은 일본과 태국, 대만 등 전 세계 LINE 사용자 및 LINE Ads 네트워크의 수많...

engineering.linecorp.com

*더 공부할 것 : CRI(Container Runtime Interface)

:Kublet과 컨테이너를 통합시키기 위한 API

Kubernetes 1.5부터 도입된 개념으로 kubelet이 컨테이너 런타임을 호출할 수 있는 인터페이스를 의미한다. High Level Container Runtime과 k8s가 연계되기 위해선 반드시 CRI를 구현해야 하며, Image 및 컨테이너 관리 및 Pod 생성이 가능해야 한다.

현재 CRI를 지원하는 컨테이너 런타임은 containerd, cri-o 가 대표적이다. Docker는 dockerd가 CRI를 구현하지 않았기 때문에 kubelet과 dockerd 사이에 'dockerd-shim'를 구현하여 이 역할을 대신 담당해왔다. 하지만 이제 Docker도 containerd를 기본으로 사용하기 때문에 더 이상 dockerd-shim 존재 이유가 없어졌으며, K8s를 위해 Docker를 의무적으로 설치할 필요는 더더욱 없다. 이러한 사정으로 Kubernetes v1.20부터 Docker 지원을 중단하게 되었다.

**부디 다시 재복습할 것!! -> https://chemical-jet-b49.notion.site/AWS-CodeSeries-779c2c73831141e89642d9515cbe315c#d6fa20fc0fdb405392592b04f3f6a628

***도커 데몬

<관련 최신 기사>

https://www.itworld.co.kr/news/295759