이전 포스팅에서는 ArgoCD와 Argo Rollout 컨트롤러를 통한 CD 환경을 구축했다. 이번 포스팅에서는 GitOps 상에서 CI 툴인 Jenkins가 Rollout Manifest 파일을 변경시킴으로써 CD 과정이 자동으로 트리거 되는 시나리오를 구축한다. 최종 GitOps 아키텍처 1) 사용자가 Git에 소스코드를 커밋/푸시 2) Jenkins가 커밋 감지 및 Jenkins Pipeline 실행 2-1) gradle 등의 빌드 툴로 빌드 2-2) 컨테이너 이미지 빌드 2-3) 컨테이너 레지스트리 푸시 (신규 태그 생성) 2-4) Git의 Manifest 레포지토리에 Rollout Manifest 수정(보통 컨테이너 이미지 tag 수정) 3) ArgoCD가 Git의 Rollout Manifest..

jib 개요 Jib은 Docker 데몬 없이 Java 애플리케이션에 최적화된 Docker 및 OCI 이미지를 빌드하고 Docker Hub와 같은 레지스트리로 저장하는 '플러그인'이다. jib은 gradle, maven과 같은 빌드툴과 함께 사용된다. jib과 기존 Dockerfile 기반 빌드 비교 위 그림과 같이 jib은 빌드와 Dockerfile 작성의 과정을 하나의 파이프라인으로 단일화한다. jib은 프로젝트를 빌드함과 동시에 컨테이너 이미지까지 만들어서 Docker Hub, AWS ECR 등 원하는 레지스트리에 푸시까지 해준다. jib 장점 1) Fast Jib은 애플리케이션을 여러 계층으로 분리하여 클래스에서 종속성을 분리한다. 이제 Docker가 전체 Java 애플리케이션을 다시 빌드할 때까지..

이번 포스팅에서는 Jenkins를 기반으로 CI(Continuous Integration)를 구축했던 과정을 다룬다. Jenkins에서 제공하는 플러그인들과 기능들을 활용하여 빌드 파이프라인 구성뿐만 아니라, 빌드 자동화, 테스트 자동화, 코드 품질 자동화 등의 작업을 파이프라인 상에 같이 연동시켜 사용하는 경우가 많다. 이번 포스팅에서는 Jenkins를 설치하고 간단한 빌드 파이프라인을 구축하는 과정만 다룰 것이고 아래와 같은 순서로 구성된다. 1) Jenkins 설치 및 기본 설정 (컨테이너 기반 Jenkins 설치, 플러그인 설치, SSH 셋업) 2) CI/CD Pipeline Job 구성 (GitHub 연동, Jenkinsfile 작성) 3) 이슈 처리 cf. Jenkins는 Java 프로그램이기..

containerd 등장 배경 - OCI 표준 초기 docker engine은 Monolithic한 구조였고 이를 나누는 작업이 시작되었다. 이러한 Monolithic한 구조의 docker engine에는 API, CLI, 네트워크, 스토리지 등 여러 기능들이 한 곳에 담기게 되었고 Docker에 의존적이던 kubernetes에서는 docker 버전이 새로 나올 때마다 영향을 받을 수밖에 없었다. 이를 계기로 2015년에 Linux Foundation에서는 '컨테이너 기술에 대한 표준'을 정하는 프로젝트(OCI)가 시작되었다. 이 프로젝트는 2016년 12월에 Container Runtime에 대한 표준을 만들고 이를 실행할 수 있는 추상화된 인터페이스인 CRI(Container Runtime Inter..

1. 문제 설명 kubectl 커맨드가 정상적으로 실행되다가 어느 순간 다시 아래와 같이 connection이 refused 되는 문제가 발생했다. 약 3~5분 간격으로 API 서버가 죽고, controller-namager나 scheduler도 죽었다 살아나기를 반복한다. root@master:~# kubectl get nodes the connection to the server :6443 was refused - did you specify the right host or port 모든 kubectl 커맨드는 API 서버로 가기 때문에 API 서버에 문제가 있을 거라 생각했다. kubectl 커맨드가 정상적으로 실행되지 않았기 때문에 API 서버를 포함한 쿠버네티스 컴포넌트들이 잘 실행 중인지 확인..

구성도 이번 포스팅에서 구축할 master, worker 노드의 구성도이다. 하나의 master 노드와 두 개의 worker 노드를 구축하고 OS 설치, 네트워크 구성, 도커 설치 등을 진행한다. 이번 포스팅에서 다룰 내용은 다음과 같다. - VM 기반으로 Master, Worker 노드를 구축 - 노드 간 네트워킹 설정 (NAT) - 호스트에서 SSH 접속 설정 - 각 노드에 docker를 설치 쿠버네티스 설치 과정은 다른 포스팅에서 다룬다. 0. 사전준비 1) Ubuntu iso 이미지 파일 다운로드 - 22.04에 containerd를 설치할 경우 일종의 버그가 있어 20.04를 추천한다. - 설치 편리를 위해 server 대신 desktop iso를 사용했다. 2) Virtual Box 설치 1...

도커를 기반으로 배포를 하다가 컨테이너로 들어가서(docker exec) 작업이 잘 수행되었는지 확인할 경우가 있었다. 들어가서 ps 명령어를 사용하기 위해 apt 커맨드로 procps 패키지를 설치했는데, apt가 지원이 되지 않았다. yum으로 변경하니 패키지가 설치되었다. 호스트 OS는 우분투를 사용하고 있었는데 컨테이너 OS는 centos였던 것이다. 컨테이너의 개념이 호스트 OS를 공유하는 것으로 알고 있었는데 이렇게 리눅스 배포판이 바뀔 수 있던 이유가 궁금해서 찾아보았다. 1. 리눅스 구조 리눅스는 kernel space와 user space로 나뉜다. 1) user space application들이 실행되는 공간으로 이 application이 실행되는데 필요한 library나 환경을 제공..

VM, 컨테이너, 멀티호스트 컨테이너 플랫폼, 컨테이너 오케스트레이션까지의 발전과정에 대한 포스팅이다. '가상화' 개념의 등장 가상화 개념이 처음 등장했던 1960년대에, 무어의 법칙에 의해 HW의 성능이 빠르게 발전하는데 SW는 이만큼 발전을 하지 못했던 상황이 발생했다. 즉, HW는 빠르게 발전하는데 SW가 이를 제대로 활용하지 못하는 상황이 발생한 것이다. 또한 그 당시 컴퓨터 HW 자원의 가격은 매우 비싼 편이었다. 여러 대의 비싼 컴퓨터를 사용해서 애플리케이션을 띄우는 것은 매우 비효율적이라는 문제가 있었던 것이다. 이러한 문제점을 해결하고자 등장한 것이 '가상화'이다. 한 대의 컴퓨터의 자원을 가상화해 여러 대인 것처럼 보이게 하자는 것이다. 하나의 물리적인 컴퓨터 위에 여러 대의 OS가 구동..

Microservice - 기존 모놀리틱 구조에서 모든 도메인과 기능이 하나의 시스템에 담겨있고 서비스가 방대해짐에 따라 복잡성이 커졌다. - Microservice는 기존 모놀리틱 구조에서 방대한 시스템을 적절하게 나눈 구조로 설명된다. - 'API Gateway'를 두고 기능별/도메인별로 요청이 '분기'하도록 구성된다. 특징 [장점] - 기존 모놀리틱 구조에서는 장애 발생 시 서비스 전체가 마비될 것이다. Microservice는 분리한 서비스 단위로 배포가 가능하기 때문에 자유롭게, 가볍게 배포가 가능하며 확장도 용이하다.(서비스 간 의존도가 떨어지기 때문) - 애플리케이션 재기동 시간이 크게 단축된다. (보통 모놀리틱은 한번 빌드하는데 엄청난 시간이 소요) - 다른 서비스와는 API로 연동되기 때..