😎 Agile vs Waterfall

워터풀(=폭포수모델)은 프로젝트의 각 단계가 구분이 뚜렷하게 나눠져 있다.

• 각 단계는 이전 단계가 완료된 후에만 진행이 될 수가 있다.

• 기본적으로 요구사항, 분석, 설계, 구현, 테스트, 운영 이런 단계를 가지고 있다.

• 한 번 완료된 단계는 폭포가 거꾸로 올라갈 수 없는 것처럼 이전 단계로 돌아가기가 상당히 어렵다는 단점을 가지고 있다.

• 그러나 최근의 추세처럼 시시각각으로 변경되는 고객의 요구사항을 반영한다든가 다양한 요구사항을 수용하기 위해서는 적합하지 않은 구조기도 하다.

애자일 개발 프로세스는 폭포수 모델의 단점을 최소화하려고 하고 있다.

• 애자의 방법론이 기존의 소프트 개발 방법에 있어서 아무런 계획이 없었던 개발 방법, 그다음에 계획이 지나치게 많았던 개발 방법들 사이에서 타협점을 찾는다.

• 프로젝트의 생명 주기 동안 반복적인 과정을 통해서 점점 소프트웨어가 진화되고 사용자의 니즈를 만족시켜가는 과정

진화과정을 살펴보면 위와 같다.

먼저 1980~1990 대를 살펴보면

• 워터폴 방식은 상당히 오랫동안 사용되었던 방법이었다.

• 이 시기에 모노리스라는 방식도 있었고, 물리적인 하드웨어가 중심이 되었다.

• 인하우스에서 데이터 센터를 구축했던, 구축하고 있었던 그런 특징도 가지고 있다.

2000년도 까지는

• 애자일 방법론이 도입되었던 시기이다.

• 분산 그 다음에 가상이란 키워드에서 볼 수 있는 것처럼 가상 환경이라든가 분산 프로그래밍이 널리 사용되었던 시기라고 볼 수 있다.

이후 2010년도까지 도표를 보면

• 최근까지 IT 시스템에서 나타나는 가장 큰 특징 중에 하나인 DevOps, 마이크로 서비스 아키텍처 그리고 가상화 클라우드라는 키워드가 있다.

• 최근 IT 산업 분야에서 이러한 특징과 트렌드는 바로 클라우드 네이티브 아키텍처라고 볼 수 있다.

😎 클라우드 네이티브 아키텍처 및 기술

클라우드 네이티브 아키텍처 및 기술은 클라우드에서 빌드되고 클라우드 컴퓨터 모델을 최대한 활용하는 워크로드를 디자인 생성 및 운영하는 접근 방식이다.

클라우드 네이티브 기술을 통해 조직은 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 최신 동적 환경에서 확장 가능한 애플리케이션을 빌드하고 실행할 수 있다.

컨테이너, 서비스 메시, 마이크로 서비스, 변경할 수 없는 인프라 및 선언적 API는 이 접근 방식을 예로 들 수 있다.

이러한 기술을 사용하면 복원력, 관리 가능 및 관찰 가능한 느슨하게 결합된 시스템을 사용할 수 있다. 강력한 자동차와 결합되어 엔지니어는 최소한의 수고로 자주 예측 가능하게 높은 영향을 미치는 변경을 할 수 있다.

-> 한마디로 클라우드 인프라 환경에서 운영되기 위한 어플리케이션이나 서비스들을 최적의 상태로 유지를 하고 사용할 수 있도록 해주는 아키텍처라고 보면 된다.

😚 Cloud Native Application의 구성요소

• 클라우드 네이티브 아키텍처에 의해 설계되고 구현되는 어플리케이션은 클라우드 네이티브 어플리케이션이라고 할 수 있다.

• 클라우드 네이티브 어플리케이션의 구성요소는 크게 4가지 형태로 구성되어 있다.

1. 마이크로 서비스로 개발된다는 점

2. 컨테이너 가상화 기술
   어플리케이션을 구성하고 있는 마이크로 서비스들을 클라우드 환경에 배포하고 사용하기 위해서 컨테이너 가상화 기술이 거의 표준처럼 사용되고 있다는 점

3. Devops
   서비스에 문제가 발생했을 경우에 사용자의 니즈가 생겼을 경우에 바로바로 수정해주고 반영해주기 위해 다시 배포해주려고 개발과 운영 조치 간의 유기적인 협력을 통해 지속적인 서비스의 개선을 해나가는 방법

4. CI/CD
   마지막으로 이렇게 개발된 마이크로 서비스들은 CI/CD 자동화 파이프라인에 의해서 자동으로 통합되고 빌드 테스트 배포 과정을 거쳐서 운영 상태가 되게 된다.

🙄 Cloud Native - MSA

클라우드 네이티브의 특징중에 첫번째인 마이크로서비스 아키텍처에 대해 살펴보자.

다음은 이너 아키텍처하고 아우터 아키텍처로 되어 있다.

• 남색: 이너 아키텍처(Inner Architecture)
• 하늘색: 아우터 아키텍처(Outer Architecture)

이너 아키텍처하고 아우터 아키텍처를 나누는 방법

• 이너 아키텍처는 단순한 도메인에 대한 부분을 가지고 비즈니스 로직을 갖고 서비스를 개발
• 아우터 아키텍처는 그러한 이너 아키텍처로 구성되어 있는 어플리케이션들이 운영하고 작동될 수 있도록 지원해주는 서포티드 시스템

External Gateway

• 아우터 아키텍처의 왼쪽에 보면 External Gateway라고 해서 api 게이트웨이라든가 사용자 인증에 관련된 부분이 있고,

Servcie Mesh

• 다음에 이 아우터 아키텍처의 가장 핵심적인 부분 중에 하나인 Servcie Mesh 부분에서는 Router라든가 Load Balancing라든가 Service Discovery 같은 내용이 있고 환경 설정의 외부 구성이라고 불리는 Config. Store도 있다.

Runtime Platform

• 그 다음에 개발, 실제 개발을 했던 마이크로 서비스가 작동되고 운영되기 위한 환경, Runtime Platform으로서 다양한 프로그래밍 언어라든가 플랫폼을 사용할 수 있다. 그런 구조에 기반해서 마이크로 서비스 어플리케이션이 만들어지면 그게 이너 아키텍처라고 보면 된다.

CI/CD Authomation

• 하단에 보면 본 과정에서 핵심적으로 다루고자 하는 CI/CD Authomation 부분이 있는데 이것도 아우터 아키텍처에 속한다.

• 어플리케이션의 빌드라던가 저장, 배포에 관련된 자동화 파이프라인을 볼 수 있다.

Baking Services

• 본 과정하고 좀 관계는 없지만 아우터 아키텍처 중에서 Baking Services이라고 해서 스토리지라던가 스토어에 관련된 부분이다.

Telemetry

• 하단에 Telemetry라고 해서 모니터링이라던가 진단에 관련된 부분도 살펴보실 수가 있다.

🙄 Cloude Native - Containerization

클라우드 네이티브 어플리케이션의 구성 요소 중에서 마이크로 서비스 어플리케이션으로 개발된 결과물은 컨테이너 기반의 가상화에 의해서 실행된 경우가 많다.

수많은 마이크로 서비스 어플리케이션을 가상화 방식이 아니라 실제 서버를 통해서 기동하게 되는 것은 리소스의 낭비뿐만 아니라 많은 비용을 발생시킨다.

컨테이너 가상화는 기존의 물리적인 서버를 운영하는 것처럼 사용되는 서버 가상화에 비해서 적은 리소스를 사용한다.

그리고 공유할 수 있는 부분에 대해서는 각각의 컨테이너 가상화 인스턴트들이 레이어 로 구분되어 있는 상태에서 공유를 해주므로서 최소한의 리소스를 통해서 어플리케이션이라던가 미들웨어 운영체제 등을 기동할 수가 있다.

컨테이너 가상화의 대표적인 제품으로써 도커가 있다.

도커는 가상화를 위한 이미지 생성을 위해서 자체 정의 언어인 dsl(Domain-Specific Languages) 라고 하는 도커 파일을 사용하고 있다.

도커 파일에 명시된 내용을 토대로 이미지가 생성이 되면 해당한 이미지를 가지고 컨테이터는 인스턴스를 생성하게 된다.

이렇게 생성된 이미지 파일은 Container Registry라는 저장소에 저장이 되고, 다른 시스템이라던가 환경에서도 사용할 수 있게 된다.

이미지를 통해서 실체화된 컨테이너 가상화가 개발 환경이라던가 테스트 환경 또는 운영환경으로 구분되어서 실행할 수 있기 때문에 마이크로 서비스와 같은 많은 서비스의 개발이라던가 테스트 배포와 같은 작업 환경을 진행하는 데는 최적의 조건을 제시한다고 볼 수 있다.

🙄 Cloude Native - DevOps

DevOps는 단순한 의미로 개발과 운영 조직을 단일화해서 개발에서 운영에 이르기까지 필요한 프로세스를 단순화한다.

고객으로부터의 피드백이라든가 요청사항, 시스템 변화에 신속하게 대응하기 위한 개발 프로세스라고 볼 수가 있다.

이름에서 보실 수 있는 것처럼 DevOps라는 것은 Development+Operation 이 두 가지가 혼합된 합성이다.

데브(dev) 쪽에서는 변화라든가 변경에 대해서 주로 작업을 하려고 하고, 오퍼레이션 쪽에서는 안정성을 주로 작업을 하려고 한다.

이런 각각의 요구사항에 맞춰서 작업을 하다 보니까 서로 이해관계가 충돌하게 될 수밖에 없다.

이런 기존 방식에서 서로 유기적으로 통합할 수 있도록 진행을 하고, 시스템의 개선작업을 지속적으로 할 수 있는 문화, 개발 프로세스를 devOps라고 보면 된다.

앞에 있는 인프라로 코드를 관리하는 부분이라든가 agile에 관련된 부분, 그리고 지속적인 통합이라든가 배포에 관련된 부분 이런 것들이 DevOps에서 주로 얘기하고 있는 특징이다.

DevOps를 한마디로 정의하게 되면

• 엔지니어가 프로그래밍을 하고, 그 다음에 빌드를 한 후 배포하고 시스템을 운영하고 있는 과정이라고 볼 수가 있다.

• 서비스의 개선을 위해서 사용자라든가 지속적인 커뮤니케이션을 해나가는 과정이고 조직의 문화를 말한다고 볼 수 있다.

이러한 DevOps를 도입하기 위해서 각 단계별로 사용되고 있는 대표적인 툴을 소개하면 위 그림과 같다.

• (주황색 부분) 처음에 프로젝트를 기획(PLAN)을 한다. 그리고 구현(CODE)을 하게 되고 빌드(BUILD)를 하게 되고 다음에 테스트(TEST)를 거쳐서 운영 단계(파란색 부분)로 넘어가게 된다.

• (파란색 부분) 운영 단계에서는 배포(DEPLOY)라고 표현되고 있는 단계가 있고, 모니터링(MONITOR) 하는 단계도 포함되어 있다.

• 이런 과정이 끝나면 종료되는 것이 아니라 다시(주황색 부분) 원래 있었던 플랜(PLAN)으로 돌아감으로써 계속적으로 이 사이클을 반복적으로 실행하는 것이 DevOps의 핵심이라고 보면 된다.

플랜(PLAN) & 코드(CODE) : Git, SVN, Jira

빌드(BUILD) : Maven, Gradle

테스트(TEST) : 단위 테스트(JUnit), Selenium

시스템 통합(Integration) : 젠킨스(JenKins)

배포(DEPLOY) & 운영(OPERATE) : Docker,Vagrant,Ansible,Terraform

모니터링(MONITORE) & 로그 파일 수집 : Nagios, Fluentd

데브옵스 각 단계에서 사용되는 툴들을 조금 더 소개해 보면 다음과 같다.

각각의 단계를 Gateway, Service Mesh, RunTime, Framworks, Automation과 Telementry, Backing Services로 구분할 수 있다.

이번에 Docker, Kubernetes 그리고 Maven 그 다음에 Jenkins, Ansible 이런 제품들을 이용해서 전체 CICD 자동화 부분을 처리하며 공부해보려고 한다.

🙄 Cloude Native - CI/CD

클라우드 네이티브 어플리케이션의 구성 요소 중에서 마지막 단계는 CI-CD이다.

CI-CD는 개발자 및 팀에 의해서 개발된 결과물에 대해 지속적인 통합과 지속적인 배포를 하는 프로세스를 말한다.

CI-CD는 개발된 어플리케이션을 통합하고 빌드, 테스트, 배포에 이르기까지 전 과정에 대한 자동화 처리를 담당하게 된다.

CI 작업

• 작업된 코드의 컴파일, 테스트, 패키징 작업이 포함

• 주기적으로 빈번하게 배포를 하겠다는 의미를 뜻

• 레포지토리에서 Merge와 충돌을 해결함에 있어서 가끔 하게 되면 문제가 커지기 때문에 작은 단위로 여러 번 자주 배포하는 것을 강조

• 거기에 따라서 코드의 품질이 전체적으로 향상되는 특징을 가지고 왔다. 왜냐하면 CI 작업에서는 단위 테스트를 포함시켜서 코드의 검증을 하고 있기 때문에 코드의 품질이 올라갔다고 볼 수 있다.

CD 작업

• CI에 의해서 패키지된 결과물을 다시 개발 서버라던가 테스트 서버 또는 운영 서버로 배포하는 작업

• CD는 지속적인 배포(Continuous Delivery)와 지속적인 제공(Continuous Deployment)이라는 두가지 의미

• CI에서 통합된 데이터를 검증하고 최종 배포를 수동으로 하는 작업이 Delivery이고 자동으로 전 과정을 배포하는 것은 Deployment 이다.

위 그림은 아마존 AWS에서 사용하고 있는 CI-CD 관련되어 있는 파이프라인 그림 이미지이다.

소스코드에서 만들어진 결과물을 최종적으로 배포(Deploy) 작업을 하며 있어서 수작업을 한다, 아니면 자동화 처리를 한다에 따라서 Continuous Delivery와 Continuous Deployment 이렇게 나눠지고 있다.

마이크로서비스 아키텍처는 하나의 단일 어플리케이션이 아니라 어플리케이션을 구성하고 있는 서비스들을 서로 독립적인 형태로 개발을 한다.

이렇게 배포하는 개발 아키텍처를 말한다.

이렇게 개발된 서비스는 하나의 단일 서버에 통합되어 운영되기 보다는 물리적으로 또는 논리적으로 분리되어 있는 상태의 분산된 서버에서 실행을 하게 된다.

따라서 개발하는 서비스들의 개수만큼 서버가 필요하게 되는 경우가 많은데 이렇게 수많은 서버에 배포하는 과정이 단순화 그리고 자동화가 되어있지 않다라고 하면 개발에 필요한 업무 외에 결과물을 테스트하고 배포하기 위해 상당한 시간을 할애해야만 된다.

따라서 지금 설명하고 있는 CI-CD에 대한 자동화 배포는 마이크로서비스 아키텍처에서 빼놓으면 안되는 아주 중요한 구성요소라고 볼 수 있다.

What is Continuous Integration?

사용하려고 하는 CI-CD 워크플로우에 대해서 설명하기에 앞서서 CI가 어떤 역할을 하는지에 대해서 조금 더 알아보자.

개발자들이 각자 개발한 소스코드에 대해서 소스 컨트롤 매니지먼트 시스템, 간단하게 SCM 또는 VCS라고 불리는 형상관리 시스템에다가 업로드를 하게 된다.

업로드를 할 때 우리는 commit 이라는 용어를 주로 사용하게 된다.

이때 서로 다른 코드의 경우에 단순히 히스토리 관리만 하게 되겠지만, 같은 코드를 여러명의 사용자가 여러 명의 개발자가 다루는 경우에는 코드의 버전 관리를 하는게 필요하다.

중복된 부분에 있어서 사용할 코드와 사용하지 않아야 될, 버려야 될 코드를 구별하고, 선택을 하고, 최종적으로 충돌이 발생하지 않은 클린 상태의 코드가 마지막 상태여야 한다.

이렇게 버전 관리와 소스 코드의 트래킹 관리를 해주는 것이 VCS 또는 SCM 이라고 불리는 도구이다.

• 최근에는 Git 이라는 SCM이 많이 사용되고 있다.

이것 외에도 Purpose 라든가 다양한 형태의 제품들이 사용되고 있었지만 최근에는 분산형태로 관리할 수 있는 Git을 자주 쓴다.

다음으로 CI 도구에 해당하는 Jenkins라는 도구의 역할을 한번 확인해보자.

• SCM에 저장된 코드를 불러온 후 소스코드의 빌드라던가 그리고 테스트, 패키징하는 작업, 이런 일괄적인 작업을 처리해주는 것을 CI 도구라고 볼 수 있다.

• 이때 테스트 단계에서는 단위 테스트를 통과한 코드들에 대해서 배포 작업을 하겠다는 규칙을 세운다.

• 단일 테스트가 통과하지 못한 코드가 있다고 하면 fail을 돌려서 작업자들한테 다시 알려줌으로써 코드의 개선, 코드의 변경을 요청할 것이다.

• 코드가 전체가 다 통과됐을 경우에 한해서 이 작업을 갖고 다음 단계인 배포 작업으로 넘어가게 된다.

이렇게 CI에서 SCM에 저장된 코드들의 지속적인 통합, 빌드, 테스트를 거쳐서 패키징하는 작업이 진행이 된 다음에 패키지된 결과물이 운영하려고 하는 운영 서버 또는 테스트 서버에 배포가 되는 과정이다.

그래서 Jenkins라는 도구를 사용하시게 되면 CI에 해당한 부분도 우리가 다 커버할 수가 있다.

다음에 결과물을 가지고 압축되어 있는 또는 패키징되어 있는 결과물을 가지고 원했던 환경, 서버에 배포하는 작업도 같이 할 수 있다.

😁 CI/CD Flow

사용할 전체 CI-CD의 구성도에 대해서 살펴보자.

먼저 조금 전에 살펴봤던 Jenkins처럼 사용될 수 있는 CI 도구로서 여러가지 형태가 제공되고 있지만, Travis CI, Circle CI, TeamCT 등의 도구들도 있다.

나는 Open Source로 사용할 수 있는 Jenkins를 선택했다.

이 Jenkins를 통해서 CI-CD 자동화 파이프라인 처리를 할 것이다.

Jenkins를 통해서 빌드하고 배포하려고 하는 어플리케이션 자체가 스프링 부트로 개발된 형태이기 때문에 이러한 코드를 빌드하기 위한 도구로써 Maven 또는 Grade를 사용하실 수가 있다.

난 간단하게 쓸 수 있는 Maven으로 시작을 하겠다.

다음으로 빌드된 결과물을 운영 서버에 배포를 해야 된다.

운영하려고 하는 서버는 컨테이너 가상화 형태로 운영될 것이기 때문에 컨테이너 런타임 중에 하나인 도커를 사용할 것이다.

이러한 도커 컨테이너들의 배포 관리, 시스템 관리를 위해서 오케스트레이션(Orchestration) 도구인 Kubernetes를 사용할 것이다.

그림을 보면 도커 외에 또 다른 옵션으로서 Cri-o를 적어놨는데 도커라든가 Cri-o라든가 컨테이너D라든가 컨테이너 D라든 이런 모든 것들이 다 흔히 말해서 컨테이너 런타임 이라고 불리는 부분이어서 어떤걸 사용해도 상관은 없지만 도커가 가장 널리 사용되고 있다.

다음에 Jenkins 하고 그리고 Kubernetes 사이에 보시게 되면 Ansible 이라던가 Terraform이 위치하고 있는데 Ansible과 Terraform은 IAC라고 불리는 부분이다.

Infrastructure as Code 라고 해서 서버의 인프라 스트럭처 관리를 스크립트에 의해서 하겠다는 소리이다. 즉, 코드에 의해서 관리해주는 시스템을 얘기한다.

클라우드에서 사용되는 가상화 서버 또는 미들웨어 서비스들의 관리를 스크립트에 의해서 프로그래밍 한 다음에 관리할 수 있다는 특징을 가지고 있다.

IAC 부분 중에서 ANSIBLE을 가지고 젠킨스에서 패키징되어 있는 결과물을 도커라든가 그냥 WAS라든가 또는 쿠버네티스에 배포하는 작업으로 파이프라인을 연결해서 테스트해보자.

처음엔 모든 과정이 전부 다 로컬에서 진행될 예정이고, 후반부에서는 로컬에서 구축했던 이런 인프라 스트럭처를 클라우드 환경으로 옮겨서 동일하게 한번 운영을 해보도록 하자.

😀 Jenkins를 사용하여 Docker에 배포

'

Jenkins하고 Git 그리고 Mave를 연동을 해서 대상 어플리케이션을 배포하기 위한 자동화 파이프라인을 구축을 할 것이다.

아까 배포하려고 하는 결과물은 Spring Boot를 이용한다고 말했듯이 Java로 만들어져 있는 웹 어플리케이션을 압축할 때 사용하는 확장자가 웹 아카이브 파일, War 파일 형태로 사용을 하게 될 것이다.

WAR 파일 또는 이러한 파일을 실행할 수 있는 환경 자체를 컨테이너 가상화 환경에 구축한 다음에 배포하는 이러한 형태로 실행을 해보자.

Jenkins가 배포하고자 하는 대상은 다이렉트로 Apache 웹서버에 배포할 수도 있고, Tomcat의 도커에 직접 배포할 수도 있다.
그리고 화면의 표시는 되어 있지 않지만, Kubernetes 상태에서 배포할 수도 있다. 어떤 형태로도 운영할 수 있는 환경에 배포를 해보도록 하자.

다음으로 도커 또는 쿠버네티스 톰캣에 배포를 할 때 중간 단계에 IAC(Infrastructure as Code)를 두어서 파이프라인을 연결하는 방법에 대해서도 살펴볼 것이다.

젠킨스에서 해주는 역할은 빌드가 되어 있는, 즉 패키징 형태가 만들어져 있다고 말했다. 패키징 형태가 만들어져 있을 때 그걸 다이렉트로 톰캣 혹은 도커에다가 배포를 했었는데, 이제 중간 단계에 있는 IAC, Infrastructure as Code로 관리할 수 있는 시스템인 Ansible 혹은 Terraform을 이용해서 배포 작업을 같이 파이프라인으로 연결해 볼 것이다.

😀 Kubernetes에 배포

그 다음에 Docker 가상화 도구의 관리를 위해서 Kubernetes를 도입할 것이다.

Kubernetes 도입해서 배포된 컨테이너에 대한 간단한 스케줄링 관리도 하실 수가 있다.

Kubernetes에서는 빌드 된 결과물의 컨테이너 관리 작업을 위해서 Container Registry를 사용할 수 있다.

물론 빌드를 한 다음에 해당하는 이미지 파일을 등록할 수 있는 저장소로써 컨테이너 레지스트리를 사용을 할거고, 또한 Jenkins에서 SonaCube 라든가 다양한 플러그인들을 통해 연결하는 것도 가능하다.

이 Kubernetes에서는 Registry에서 등록되어진 결과물을 가지고 와서 필요로 하는 패키징, 배포 작업을 할 수 있게끔 작업을 처리할 수 있다.

이런 작업에 있어서 필요로 하면 플러그인을 더 Jenkins에서 추가로 계속 확장하는 방법도 같이 살펴볼 것이다.

위 그림을 처음부터 살펴보자. 먼저 코드가 만들어지고 배포가 되는 시점에서 빌드를 하고 테스트를 하고 패키징을 한다.

테스트를 할 때 단위 테스트가 기본적으로 실행이 될텐데 이거 외에도 정적인 테스트를 하기 위해서 분석자료를 뽑아보기 위해서 소나큐브(sonarqube)라는 오픈소스로 연동할 수 있다. 이거 역시 Jenkins에서 지원해주는 플러그인이다.

다음에 최종 목적지에 해당하는 도커라든가 아니면 was라든가 쿠버네티스라든가 이런 쪽에 배포를 함에 있어서 중간에 IAC를 도입 해서 배포 관리를 한번 해보려고 한다.

컨테이너 가상화에서 관리할 수 있는 이미지 형태는 Docker public registry를 사용하거나 Amazon ECR이라고 하는 레지스트리 서비스를 사용할 수 있다.

왼쪽에 해당하는 부분이 CI(Continuous Integration) 이다.

CI 부분에서는 Jenkins를 이용해서 코드의 지속적인 빌드와 패키징을 한다.

그 다음 오른쪽은 CD(Continuous Delivery) 이다. (Deployment도 개념을 포함)

빌드 된 결과물에 컨테이너 가상화된 이미지 생성하는 것도 필요하다.

이미지 저장소에다가 이미지를 올려주는 등록하는 작업도 있고, 컨테이너 레지스트리 즉 저장소에 저장된 이미지를 이용해서 컨테이너 인스터를 생성하기 위해서 이미지를 가져오는 부분, 스케줄링 관리라던가, 스케일링, 스케줄, 스케일링 등 이런 작업들을 하기 위해서 Kubernetes를 연동할 수 있다.

그때도 역시 Jenkins에서 필요한 명령어를 처리를 할 것이다.

😀 EC2/VM에 구축

먼저 초반엔 구축한 모든 인프라들은 로컬 환경에서 진행을 할 것이다.

필요로 하는 Jenkins 라든가 다음에 Docker 라든가 Kubernetes 라든가 이런 것들에 대한 준비가 완료가 되어 있다고 하면 로컬에서 테스트했던 것과 동일하게 클라우드에서 할 수 있다.

( 로컬 보다는 클라우드에 올리는 것을 추천한다. 이유는 로컬 상태에서 이 부분을 설정하시게 되면 윈도우즈를 사용하게 된다. 하지만 대체로 CI/CD 이용해서 배포 작업을 하거나 시스템 운영 작업, 실제 운영 서버 같은 부분들은 대체로 리눅스 환경에서 실행되는 경우가 많기 때문이다. )

이와 같은 이유로 로컬 환경에서 모든 진행이 끝나면 클라우드로 바로 옮길 것이다.

출처

Jenkins를 이용한 CI/CD Pipeline 구축