지식 줍줍 🐿️

목적

소스코드를 github에 반영 & Local 서버(Mac OS) 내 docker 에 배포해보기 (+dockerHub에도 반영)
‣ jenkins pipeline 이용 

작업순서

1️⃣ 프로젝트 셋팅 및 github push

1-1. 프로젝트 생성
‣ 나의 경우, spring Initializr or https://start.spring.io으로 프로젝트 생성 

# DockerFile
FROM openjdk:11
EXPOSE 8081
ADD build/libs/cicd-study.jar cicd-study.jar
ENTRYPOINT ["java", "-jar", "/cicd-study.jar"]



...
# application.yml
server:
  port: 8081
  
  
  
...
@RestController
@SpringBootApplication
public class MainApplication {

	@GetMapping
	public String message() {
		return "HELLO !!!!!!!!!!";
	}
	public static void main(String[] args) {
		SpringApplication.run(MainApplication.class, args);
	}

}

1-2. github 프로젝트 생성 및 push

$ git init
$ add .
$ git commit -m "first commit"
$ git branch -M main
$ git remote add origin git@github.com:mumgmangmange/test2.git
$ push -u origin main

만약, git add . 가 안되거든, ./gradlew clean 실행

※ gradle or gradlew 사용의 차이?
Wrapper는 선언된 버전의 Gradle을 호출하고 필요에 따라 미리 다운로드하는 스크립트이다.
작업환경 내 다른버전의 gradle이 있더라도 따로 설치가 필요 없음 (시간 및 돈 절약 가능)

http://daplus.net/gradle-gradlew%EC%99%80-gradle-%EC%82%AC%EC%9A%A9%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90/

2️⃣ docker 실행 (서버 내 없으면 설치 필요)

...칩셋 확인 (인텔칩,,맥칩,,)

3️⃣ jenkins 실행 (서버 내 없으면 설치 필요)
‣ 나는 brew 으로 설치함
‣ 그리고 jenkins 계정생성 관련 → 해당 링크 내 2-5 확인 

-- jenkins 설치
$ brew install jenkins 

-- jenkins 실행
$ brew services start jenkins

4️⃣ jenkins 프로젝트 셋팅 및 배포환경 설정 

↓↓↓ 파이프라인 스크립트 내용 ↓↓↓

pipeline {
    agent any
    stages { 
        stage('Build Gradle') { // github 의 소스파일 불러오고, build clean 및 build
            steps {
                checkout([$class: 'GitSCM', branches: [[name: '*/main']], extensions: [], userRemoteConfigs: [[url: 'git@github.com:xxxxx/xxx.git']]])
                sh './gradlew clean build'
            }
        }
        stage('Build docker image') { // 도커 이미지 빌드 
            steps {
                // withEnv 블록 내 환경변수 설정 가능하도록 함 
                withEnv(['PATH+EXTRA=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin']) {
                    sh 'docker rmi -f 도커이미지명[:TAG]'
                    sh 'docker build -t 도커이미지명[:TAG] .'
                }
            }
        }
        stage('Push image to Hub') { // docker hub 에 image 푸시 
            steps {
                withEnv(['PATH+EXTRA=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin']) { // /usr/local/bin 사용 위해 withEnv 사용 
                    withCredentials([string(credentialsId: 'docker계정명', variable: 'dockerpwd')]) {
                        sh 'docker login -u 도커계정아이디 -p ${dockerpwd}'
                    }
                    sh 'docker push [OPTIONS] 도커이미지명[:TAG]'
                }
            }
        }
        stage('Image Execute') { // 이미지 컨테이너 실행 
            steps {
                withEnv(['PATH+EXTRA=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin']) {
                        sh '''docker run --name cicd-study \
    -v //var/run/docker.sock:/var/run/docker.sock  \
    --privileged \
    -p 8081:8081 \
    -d \
     도커이미지명[:TAG]'''
                }
            }
        }
    }
}

❗️❗️ dockerHub 업로드 생략하려면 파이프라인 소스 관련 주석처리해도될듯!
그렇지 않다면, https://hub.docker.com/settings/security?generateToken=true 접속 및 accessToken 생성해두고, jenkins credentials 에 등록

5️⃣ 빌드 및 배포 성공 

참고

https://bcp0109.tistory.com/352

https://chinsun9.github.io/2020/10/22/denied-requested-access-to-the-resource-is-denied/

https://i5i5.tistory.com/527

https://www.inflearn.com/questions/229989

https://m.blog.naver.com/wideeyed/221533279838

https://unix.stackexchange.com/questions/4186/what-is-usr-local-bin

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=special9486&logNo=220274932377

VM(Virtual machine)

▪︎ 하이퍼바이저(hypervisor)라는 소프트웨어를 이용해 하나의 시스템에서 여러개의 운영체제를 사용
▪︎ 게스트 os을 관리로 인한 오버헤드 발생, 이미지도 큼
▪︎ 배포속도 및 부팅속도 느림

Container

▪︎ 하이퍼바이저(hypervisor) 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성
▪︎ 호스트의 커널 공유함 
▪︎ 애플리케이션 실행 위한 라이브러리 & 실행파일만 존재
▪︎ 용량 적고, 커널을 포함하지 않기 때문에 배포 빠르고 성능 손실이 거의 없음
▪︎ 마이크로 서비스에 용이 
▪︎ 관련 기술로 도커(Docker)를 많이 사용

Docker

▪︎ 어플리케이션을 관리하는 것과 동일한 방식으로 인프라 관리 가능.
▪︎ 이식성, 신속성, 재사용성 
▪︎ Dockerfile 로 도커 이미지 생성 자동화 

❉ 도커 이미지는 실행환경, 소스코드, 쉘 스크립트 등을 파일을 묶은 형태이고, 컨테이너는 이미지를 실행한 상태

+ 그리고 컨테이너들을 관리하기 위한 기술이 컨테이너 오케스트레이션!
컨테이너 오케스트레이션 관련 도구로 유명한것이 k8s (쿠버네티스!)

참고

- 책: 도메인 주도 설계로 시작하는 마이크로서비스 개발 
- 링크: http://koushki.net/2018/06/the-difference-between-vm-and-container/

- 링크: https://docs.docker.com/get-docker/

CI/CD 란

설명

• 각각의 개발자들이 개발하는 환경을 사용자가 사용 가능한 서비스로 전달하는 모든 과정을 
지속 가능한 형태로 혹은 자동으로 하여 개발자 및 사용자 사이의 격차를 없애는것
• 빌드 및 배포를 함!

개발자 → 코드작성 → 빌드(webpack, javac..) → 테스트(junit..) → 배포(ecs update,,) → 사용자  

► Continuous Integration (지속적 통합)
• 통합의 대상? 코드!
• 여러 개발자들의 코드베이스를 계속해서 통합하는것.

► Continuous Delivery (서비스 배달)
• 사용자에게 제품을 서비스를 지속적으로 배달!
• 코드베이스가 항상 배포가능한 상태를 유
• Blue/green, Rolling update, Canary

► Continuous Deployment 
• 코드베이스를 사용자가 사용가능한 환경에 배포하는 것을 자동화함.
• 피드백 반영하는 개발 문화를 강조

CI/CD 해야하는 이유

• 코드 관리의 어려움 때문 (여러명의 개발자가 같은영역을 개발할때 충돌등이 발생할 수 있기 때문. 이를방지)
• 빨리 코드를 코드베이스에 안착!

Jenkins

설명

• Java Runtime 위에서 동작하는 자동화 서버
• 빌드, 테스트, 배포 등 모든것을 자동화 해주는 자동화 서버
• 다양한 플러그인들을 활용해서 각종 자동화 작업을 처리할 수 있음
• 일련의 자동화 작업의 순서들의 집합인 Pipeline을 통해 CI/CD 파이프라인을 구축함
• Credentials Plugins(중요정보 aws token, git acccess token 등 저장해주는 플러그인), Gid Plugin, Pipeline, Docker plugin 등의 플러그인이 존재

Pipeline

설명

• CI/CD 파이프라인을 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 구성. 
• 파이프라인을 통해 서비스가 배포됨.
• 작업명세서.
• DSL(Domain Specific Language) 으로 작성.
• 두가지 형태의 Pipeline syntax가 존재 (Declarative, Scripted Pipeline)

Pipeline 구성 요소

● Sections
• Agent section : 어떤 젠킨스에게 일을 시킬지 지정! (젠킨스 노드 새로 띄우거나, docker 이미지를 통해 사용)
• Post section : 스테이지 끝난 후 후속조치 취할 수 있음.
• Stages section : 어떤일을 처리할지 stage 정의
• Step section : 단계별 스텝 정의 

● Declaratives
• Environment : 어떤 파이프라인이나 stage scope의 환경변수 설정
• Parameter : 파이프라인 실행 시 파라미터 받음
• Triggers : 어떤 주기로 실행
• When : 언제 실행되는가

● Steps
• 여러 작업들 실행 가능.

무중단 배포 방식 3가지

❖ Rolling Update
• 컨테이너 이미지를 새 버전으로 하나씩 교체
• 최소한의 오버헤드/성능 영향/중단

❖ Canary
• 새로운 배포 버전과 현행 버전을 Prod 환경에서 동시에 검증하고자 할때 활용
• 위험 감지 배포 기법

❖ Blue/Green
• 완전하게 준비된 상황에서 서비스 교체 
• 높은 오버헤드와 서비스 장애 최소화 간 조율 

참고

- 링크: https://www.youtube.com/watch?v=JPDKLgX5bRg&list=PL9mhQYIlKEhfgLHvRBRKmTg6HmfSDe8tr&index=1 

- 링크: https://onlywis.tistory.com/10

- 강의: https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0

목적

작업 결과물(Springboot jar file, gradle 이용)을 AWS EC2에 반영해보기
‣ jenkins 서버에 작업 결과물을 빌드 / 배포하는 셈.
‣ 작업 결과물은 개인 github 에서 가져옴! (github 의 webhook 기능 이용) 

작업순서

1️⃣ EC2 생성 및 터미널 접속
‣ EC2 생성방법은 생략함. (t2.micro 이용 (메모리 1GB..jenkins 배포는 되긴함!..), aws linux 이용)
‣ pem key 소중하게 보관하도록하기 (ssh 폴더에 이동시키는 등)

1-1. EC2 보안그룹 설정하기 (인바운드 규칙 설정)

1-2. EC2 인스턴스 서버 접속 시도 (2가지)

- pem key 을 .ssh 폴더로 옮겨주는 작업을 추가함.

$ sudo mv {pem key 위치경로}/jenkins.pem ~/.ssh

⭐️ 참고로 실습의 상황이기에 EC2 서버를 내리고 올리는 경우가 존재한다면
[1. ssh 으로 접속하는 방법] 으로 하는것이 맞을듯. (IPv4가 서버 재시작시 바뀜)

  1-2-1. ssh 으로 접속하는 방법

# ssh -i {pem key 경로} {ec2 인스턴스 계정ID}@{퍼블릭 IPv4 DNS or 퍼블릭 IPv4 IP}
$ ssh -i ~/.ssh/jenkins.pem ec2-user@ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com

# root 권한이 아닌 경우 
$ sudo ssh -i ~/.ssh/jenkins.pem ec2-user@ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com

  1-2-2. ~/.ssh/config file 에 접속정보 추가 후, Host 명으로 접속하는 방법

$ vi ~/.ssh/config 

# 열어서 아래내용 추가
Host test_jenkins

 User ec2-user
 HostName ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com
 IdentityFile ~/.ssh/jenkins.pem
 
# 그리고 저장 (:wq!)
 
# 접속시도는 아래와 같이 함. (root 권한 아닌 경우 sudo ssh ~)
$ ssh test_jenkins

💥 그런데, Host 명으로 접속 시도중 오류가 발생했다면 ? 

> pem key 권한을 변경해주니 접속이 가능함! (chmod 400 ~ 나에게만 읽기 권한 설정) 

2️⃣ EC2 서버 접속 후, 프로그램 설치 및 서버 셋팅

2-1. java 설치
   ‣ 나의 경우, aws linux을 사용했기에 해당문서 ← 를 참고하여 설치함 

2-2. 타임존 변경 (한국 시간)

$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

# 날짜 확인
$ date

2-3. 호스트네임 변경

$ sudo hostnamectl set-hostname mungmang-jenkins
$ sudo reboot

# 몇분 후 다시접속

# 확인
$ hostname

2-4. jenkins 설치

# jenkins repository 에 설정파일 생성 
$ sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
$ sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

# jenkins 설치
$ sudo yum install jenkins

# jenkins 실행
$ sudo systemctl start jenkins

# 만약 부팅시 가능하게 설정하려면 다음도 추가
$ sudo systemctl enable jenkins

2-5. jenkins 접속 및 플러그인 설치

.. 플러그인 설치 후,
jenkins 유저 등록 화면에서 로그인할 계정정보 입력 ↓ ↓ ↓ (계정명 및 암호로 jenkins 로그인 가능!)

2-6. gradle 설치 https://docs.gradle.org/6.9.1/userguide/installation.html 참고함

$ mkdir /opt/gradle
$ unzip -d /opt/gradle gradle-6.9.1-bin.zip
$ ls /opt/gradle/gradle-6.9.1

$ export PATH=$PATH:/opt/gradle/gradle-6.9.1/bin
$ gradle -version

2-7. git 설치 https://gamoo12.tistory.com/205 참고함

$ sudo yum update -y
$ sudo yum install git -y
$ git version

3️⃣ github 설정

3-0. 반영할 프로젝트는 있다고 가정 (작업 결과물)
3-1. EC2에서 ssh key 생성

$ cd ~/.ssh
$ ssh-keygen

# id_rsa key 생성

3-2. github project 내 XXX.pub key 등록 필요
    3-2-1. https://github.com/{git계정}/{git프로젝트}/settings/keys/new 이동 

$ cat ~/.ssh/id_rsa.pub

# ssh-rsa ~ 내용을 복사

3-3. github 프로젝트 내 webhook 설정필요
    3-2-1.https://github.com/{git계정}/{git프로젝트}/settings/hooks/new 이동 
        • Payload URL : http://{ec2에 jenkins 띄운 주소 (ex. ec2~~:8080}/github-webhook/ 입력
        • Content type :  application/json

4️⃣ jenkins 설정

1. Credentials 등록 필요 (github 🔛 jenkins 연결유도)

Jenkins 관리 > Manage Credentials > Stores scoped Jenkins 의 Jenkins 클릭 > Global credentials
 
Kind : SSH Username with private key 선택
Private Key: .ssh/id_rsa 을 입력

2. 빌드 및 실행 (Dashboard > 대상 프로젝트 > 구성) 

빌드유발
GitHub hook trigger for GITScm polling 선택 

[플러그인 설치 필요] post build task (아래의 내용 기입, 작업 결과물 jar 파일로 만든 것을 실행)
JAR=$(ls -tr /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs | grep jar | tail -n 1)
echo $JAR
nohup java -jar /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs/$JAR &

• $(ls -tr /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs | grep jar | tail -n 1) : jar 파일명 추출 위함.
• nohup java -jar /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs/$JAR & : jar 실행위함, nohup 을 붙임으로써 백그라운드에서 실행! (터미널 종료 하더라도 작업 결과물은 계속 서버에 실행되어 있도록 하기위함)

느낀점

‣ 삽질을 줄일 필요성이있겠다.
‣ 파이프라인 작성을 이용한 배포도 한번 해보아야 할것같다. 
‣ docker..kubernetes 등을 이용한 배포방법도 해보아야 할것같다. + 다른 서버에 배포하는 방법 등 

참고

책: 스프링 부트와 AWS로 혼자 구현하는 웹 서비스

링크: https://lemontia.tistory.com/656

쿠버네티스
(k8s = kubernetes)

설명

• 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼
• 쉽게말해, 다수의 컨테이너를 관리하는데 사용
• 구글에서 만들었고 borg 기반
•컨테이너 오케스트레이션(container orchestration)의 표준 
  ↑↑↑ click-! ↑↑↑

※ 컨테이너
• 하나의 운영체제(OS) 커널 에서 다른 프로세스에 영향받지 않고 독립적으로 실행되는 프로세스 상태
• 운영체제 환경에 관계 없이 독립적인 환경에서 일관된 결과 보장
• 어플리케이션 간 운영체제(OS)을 공유
• 컨테이너 내에는 자체 파일시스템, CPU점유율, 메모리, 프로세스 공간 등이 존재.
• 클라우드 or OS 배포본에 모두 이식 가능.

쿠버네티스를 사용하는 이유?

• 분산시스템을 탄력적으로 실행하기 위해 사용. (배포 관리등을 시스템이 알아서 처리해줌으로써 안정성에 기여함)

Desired State (원하는 상태)

• 상태 체크(Observe) 중 현재상태(Current State)에서 차이점(Diff)이 발견시 조치(Act)를 취하여 원하는 상태로 만듬
• 비교하고 비교하고 비교하여 다르면 그에 맞게 상태를 변경함
• API 가 현재상태를 갖고 있으며, 이를 보존하기 위해 etcd가 필요 (한몸으로 움직임)

쿠버네티스 컴포넌트

• 쿠버네티스를 배포하였을때 생성

쿠버네티스 아키텍처

❁ 마스터노드와 워커노드로 구성 ❁ 
    ‣ 마스터 노드에는 kubectl, API 서버, etcd, 컨트롤러 매니저, 스케줄러 등이 존재. (선언적 시스템)
    ‣워커노드에는 kubelet, 컨테이너 런타임, Pod, 네트워크플러그인, CoreDNS 가 존재함. (워커노드는 워커플로 구조)

❖ Kubernetes cluster
    ‣ 컨테이너화된 어플리케이션을 실행하는 노드라고 하는 (컨테이너 실행위함) 의 워커 머신의 집합

❖ Control Plane
    ‣ 끊임없이 상태를 체크하고 원하는 상태를 유지함 (새로생긴 Pod을 계속 체크함)
    ‣ etcd, API 서버, Scheduler, 컨트롤러매니저, 클라우드 컨트롤러 매니저 등의 컴포넌트로 구성 → 이를 실행해주는 것이 Master
    ‣ 마스터노드

❖ Controller
    ‣ 끊임없이 상태를 체크하고 원하는 상태를 유지함 (새로생긴 Pod을 계속 체크함, API 서버를 통해 클러스터의 공유 상태 감시)
    ‣ 단일 프로세스로 실행 (복잡성 낮춤)
    ‣ 무한반복으로 돌면서 체크
    ‣논리적으로 다양한 컨테이너가 존재함 (복제컨트롤러,, 노드컨트롤러,, 엔드포인트 컨트롤러,, 10개..20개..)

❖ Scheduler
    ‣ Node 현재 상태를 체크함
    ‣ 새로 생성된 Pod을 감지하고 실행할 노드를 선택함. (할당요청 Pod을 확인함)
    ‣ 노드의 현재 상태와 Pod의 요구사항을 체크함

❖ API Server
    ‣etcd 와 유일하게 통신하는 모듈 **
    ‣ 상태를 바꾸거나 조회하는 기능 (조회 및 요청은 무조건 API Server을 통해서 함)
    ‣ REST API 형태로 제공
    ‣ 권한체크, 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신함
    ‣ 수평으로 확장되도록 디자인

❖ etcd
    ‣ 상태 및 데이터를 저장 (날라가지않게,, 보통 3대로 관리,, 백업 필수)
    ‣ 복구 가능하도록 함
    ‣ 고가용성, 일관성
    ‣ Key, Value 형태 및 TTL(time to live), watch 같은 부가 기능 제공

쿠버네티스 노드(Node) 컴포넌트

▪︎ 컨테이너화된 어플리케이션을 실행
▪︎ 클러스터에 따라 가상 or 물리적일 수 있다.
▪︎Control Plain 에 의해 관리되며, Pod을 실행하는 데 필요한 서비스를 포함함.
▪︎ 하나의 클러스터에는 여러개의 노드가 존재.

    ❖ kubelet
        ‣ Pod 을 실행/중지하고 상태를 체크함 (각 노드에서 실행, 미실행 Pod을 확인하여 Pod을 생성함)
        ‣ 다 실행되어 있어야 함.
        ‣ 컨테이너를 직접 쓰지 않고 Pod라는 걸로 감싸서 사용함.

    ❖ kube-proxy
        ‣ 네트워크 프록시와 부하 분산 역할, iptables or IPVS을 사용 (설정만 관리)
 
    ❖ 컨테이너 런타임
        ‣컨테이너 실행을 담당하는 소프트웨어  

Kubectl

▪︎ 명령형 커맨드.. 이를 이용하여 쿠버네티스 오브젝트를 관리함

쿠버네티스 오브젝트

❖ Pod
    ‣ 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위
    ‣ 전체 클러스터에서 고유한 IP을 할당 (Pod 별로 IP 할당)
    ‣ 하나의 Pod 안에 여러개의 컨테이너 속할 수 있다.

❖ ReplicaSet
    ‣ Pod을 단독으로 만든상황에서 pod가 사라지는경우(서버가죽음) 자동복구가 되지 않는데, 이러한 pod을 자동 복제 관리해주는것.
    ‣ 여러개의 Pod 을 관리 (몇개의 Pod을 관리할지 결정)
    ‣ 무중단배포 하고싶을때 사용
    ‣ 신규 Pod을 생성하거나 기존의 Pod을 제거하여 원하는 수 (Replicas)을 유지

❖ Deployment
    ‣ 배포버전 관리 (ReplicaSet을 이용하여 버전관리를 함)
    ‣ 내부적으로 ReplicaSet 을 이용함

❖ Workload
    ‣ 클러스터 내에서 Pod 실행중 집합 나타냄

❖ Service
    ‣ 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법.
    ‣ Pod 을 연결하고 외부에 노출

❖ Service > ClusterIP
    ‣ Pod을 로드밸런서 하는 서비스
    ‣ 클러스터 내부에서 사용하는 프록시 
    ‣ Pod는 동적이지만, Service는 고유 IP을 가짐
    ‣ 클러스터 내부에서 서비스 연결은 DNS 이용

❖ Service > NodePort
    ‣ 노드에 노출되어 외부에서 접근 가능한 서비스 (브라우저가 접근 가능 등)
    ‣ 모든 노드에 동일한 포트로 생성

❖ Service > LoadBalancer
    ‣ 하나의 IP주소를 외부에 노출

❖ Ingress
    ‣ URL, path 기반 라우팅 정의 
    ‣ SSL 보안 연결
    ‣ domain path에 따라 내부 ClusterIp에 접근 가능하도록 처리
    ‣ 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP을 관리함.

❖ Volume 
    ‣ 데이터를 포함하고 있는 디렉터리이며, Pod의 컨테이너에서 접근 가능.

❖ ConfigMap
    ‣ key-value 쌍인 데이터를 저장하는데 사용하는 API 오브젝트.
    ‣ 설정 값을 Pod 에 전달
    ‣ 컨테이너 설정 정보를 저장 해 놓는 일종의 저장소 (key / value 형식)
    ‣ 컨테이너에서 필요한 환경 설정 내용을 컨테이너와 분리해서 제공
    ‣ 설정 값이 변경되었을 때마다 컨테이너의 재배포 없이 적용 가능

※ 참고
- 인프런 강의: 초보를 위한 쿠버네티스 안내서

- 책: 컨테이너 인프라 환경 구축을 위한 쿠버네티스 / 도커 

- 링크: https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

- 링크: https://subicura.com/2019/05/19/kubernetes-basic-1.html

컨테이너 오케스트레이션 (container orchestration)

설명

◦ 복잡한 컨테이너 환경을 효율적으로 관리 하기 위한 도구
◦ 서버 관리자가 해야하는 일을 대신 해주는 프로그램을 만드는것
◦ 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의 해 손쉽게 사용할 수 있는 서비스
◦ 쿠버네티스가 이의 표준이라고 함.

※ 오케스트레이션
서버 구성 관리 자동화 = 컴퓨터 시스템과 소프트웨어의 자동화된 구성, 조율 관리
관련 도구로 Ansible, Puppet, Salt, 테라폼, AWS CloudeFormation..

..컨테이너 관리를 자동화 한다는 것?

특징

◦ 클러스터 단위 관리가 가능하다. (마스터 서버에서 각 노드별 관리..)
◦ 오토스케일링 가능
◦ 배포관리 알아서 함
◦ 서버 롤백등을 중앙에서 관리함
◦ 새로 등록되거나 변경되는 서버 IP를 자동으로 관리해줌 
◦ 볼륨 스토리지 마운트 설정 가능

※ 클러스터
여러대의 서버들을 하나의 시스템으로 동작하게 함으로써, 클라이언트들에게 고가용성(=오랜기간동안 정상운영 가능)을 제공

・ 쿠버네티스 클러스터 = 노드머신 (컨테이너 실행위함) 의 워커 머신의 집합
→ 쿠버네티스 실행중 ? 클러스터 실행중 !

※ 참고
- inflearn: 초보를 위한 쿠버네티스 안내서

- book: 컨테이너 인프라 환경 구축을 위한 쿠버네티스 / 도커 

- search: https://ko.wikipedia.org/wiki/%EC%98%A4%EC%BC%80%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%9D%B4%EC%85%98_(%EC%BB%B4%ED%93%A8%ED%8C%85) 

https://wooody92.github.io/kubernetes/Kubernetes-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EC%98%A4%EC%BC%80%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%9D%B4%EC%85%98/

https://www.redhat.com/ko/topics/containers/what-is-a-kubernetes-cluster

https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0