VM 세팅

• Docker를 실습했던 VM의 이름을 Manager1로 바꾼다.
• Manager1을 연결된 복제로 Worker1~2를 만들어준다.
• 다만 메모리를 줄여 자원을 보존해야한다.
• 매니저 : RAM:4Gb , CPU:2c
• 워커 : RAM:1Gb, CPU: 1c

Docker Ochestration

• 쿠버네티스에 앞서서 도커에서도 오케스트레이션 서비스를 제공했다.
• Dockerfile을 각각 build 하는 것이 아니라, ansible의 playbook처럼 여러 Dockerfile을 한번에 build할 수 있도록 해준다.
  • 워드프레스설치에서도 DB서버와 wordpress를 나눠서 build했는데 한번에 build 할 수 있다.

복습

Docker 데이터 관리

Docker volume

• Docker 볼륨이다 이전에 생성된 볼륨들이 있다.
  
• docker create volume my-vol01
• 도커에서 사용할 볼륨을 이렇게 생성할 수 있다.

Docker network

• 현재 사용하고 있는 네트워크이다.
  
• docker network create new-net --subnet 10.28.0.0/16 --ip-range 10.28.0.0/20 --gateway 10.28.0.1
  • 새로운 네트워크를 생성해준다.

Onbuild

운영자 역할

• mkdir onbuild && cd $_
  • 새로 작업 디렉토리를 생성한다.
• vi Dockerfile.base

FROM ubuntu:18.04
RUN sed -i 's/archive.ubuntu.com/ftp.daumkakao.com/g' /etc/apt/sources.list
RUN apt-get -y update
RUN apt-get -y install nginx
EXPOSE 80
#ONBUILD ADD명령어로, 개발자가 website.tar파일을 만들면, BUILD할 때, 개발자가 가지고있는 website*.tar파일을 /var/www/html로 복사한다.
ONBUILD ADD website*.tar /var/www/html/
CMD ["nginx", "-g", "daemon off;"]

• docker build -t jo1132/web-base:v2.0 -f Dockerfile.base .
  • base Dockerfile을 build해준다.
  • -f 옵션으로 Dockerfile.base를 지정해준다.
  • -t 옵션으로 이미지의 이름을 붙혀준다.
    
• docker login
• docker push jo1132/web-base:v2.0
• vi Dockerfile

FROM jo1132/web-base:v2.0

개발자 역할

• mkdir onbuild && cd $_
• ls
  • website.tar
    • 개발자는 website*.tar 이름을 지켜줘야 한다.
  • Dockerfile
    • 이렇게 website.tar와 Dockerfile이 하나의 폴더에 있어야한다.
• docker build -t jo1132/web-site:v2.0 .
  • jo1132/web-site:v2.0 이미지를 가져와서 ONBUILD ADD 명령어를 통해, 개발자가 가지고 있는 website.tar를 가지고 컨테이너에 복사해준다.
  • 이름은 web-site:v2.0으로 이미지를 만들어준다.
• docker run -d -p 80:80 --name web-site jo1132/web-site:v2.0
  
• 웹서버가 잘 생성되었고, 템플릿이 잘 적용되었다.
• docker login
• docker push jo1132/web-site:v2.0
  • web-base:v2.0을 이용한 web-site:v2.0을 push해준다.
    
• 잘 push 되었다.

운영자 역할 (AWS EC2)

• 개발자가 PUSH 해놓은상태에서, 서비스를 제공할 서버에서 Docker run을 실행한다.
• 사용자 데이터

# AWS에서 Docker설치
sudo amazon-linux-extras install docker -y
sudo systemctl start docker && systemctl enable docker
curl https://raw.githubusercontent.com/docker/docker-ce/master/components/cli/contrib/completion/bash/docker -o /etc/bash_completion.d/docker.sh
sudo usermod -a -G docker ec2-user

# 
docker run -d -p 80:80 --name=test-site jo1132/web-site:v2.0

도커 사설 레지스트리(AWS)

• 도커 호스트를 하나만 두는것이 아니라, 호스트서버를 여러개 두어서, 한 호스트에 문제가 생겨도 무중단 서비스를 이어가기 위함이다.
• docker run -d -p 5000:5000 --restart=always --name private-docker-registry registry # 저장소 서버
• vi /etc/docker/daemon.json # 클라이언트

{ "insecure-registries":["docker.cocudeny.shop:5000"] }

• systemctl restart docker

Docker 컴포즈

도커 컴포즈란?

• Compose 는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구이다.
• YAML파일을 사용한다.

Compose사용은 기본적으로 3단계 프로세스이다.

• Dockerfile 어디서나 재현할 수 있도록 앱의 환경을 정의한다.
• 앱을 구성하는 서비스를 정의하기 위해 doker-compose.yml 형식의 스크립트로 격리된 환경에서 함께 실행한다.
• 실행 Docker compose up하면 Docker compose 명령 이 전체 앱을 시작하고 실행한다.
  • 또는 Docker-compose updocker-compose 바이너리를 사용하여 실행할 수 있다.

도커 컴포즈 설치

• curl -L "https://github.com/docker/compose/releases/download/1.26.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
  • /usr/local/bin 아래 도커 컴포즈를 설치해준다.
• chmod +x /usr/local/bin/docker-compose
  • 도커 컴포즈에게 실행권한을 부여한ㄷ.
• mkdir my_wordpress && cd $_
  • 도커 컴포즈를 실습할 폴더 생성

vi docker-compose.yml

• 동시에 두가지가 선언된다.
• 앞 간격은 한번에 두칸씩 들여쓰자.
• 띄워지기만 하면되서 굳이 두칸일 필요없다.

version: "3.3"    				# 도커 컴포즈의 버전
services:
  dbserver:						#  DB서버라는 이름의 컨테이너정의
    image: mysql:5.7			# 이미지 mysql:5.7사용			
    volumes:					# 볼륨 정의
      - db_data:/var/lib/mysql	# mysql의 정보들이 이 경로에 저장된다.
      							# DB컨테이너가 지워지더라도, 이 경로의 볼륨에 mysql의 데이터가 남아있도록 한다.
                                # Persistance볼륨
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password	# MYSQL에서 기본으로 제공하는 변수들에 값을 넣어서 기본 환경변수를 설정한다.
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppass
  wordpress:					# 워드프레스 컨테이너
    depends_on:					# Depends_on : 정의된 서비스보다 뒤에 생성되야 한다.
    							# 워드프레스 서비스는  dbserver가 서비스 된 후에 생성되어야 한다.
      - dbserver
    image: wordpress:latest		# wordpress를 따로 다운받지 않고, wordpress 이미지를 사용한다.
    volumes:
      - wordpress_data:/var/www/html
    ports:
      - "8888:80"				# 포트 포워딩을 8888-> 80으로 진행한다.
    restart: always
    environment:				# 환경변수를 정의한다.
      WORDPRESS_DB_HOST: dbserver:3306	#워드프레스와 DB사이 연결할 떄 필요한 Host 주소, IP, PW, DB Name을 미리 정의해준다.
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wppass
      WORDPRESS_DB_NAME: wordpress
volumes:						# 실제로 사용한다는 부분. 
								# 위에서 정의된 db_data, wordpress_data 볼륨을 사용하기위해 따로 선선하는 곳이다. 또, {}로 초기화해준다.
  db_data: {}
  wordpress_data: {}

도커 컴포즈 실행

• docker-compose up -d
  • 도커 컴포즈를 실행한다.
    
• docker-compose ps
  • 도커 컴포즈 실행 목록을 보면 두 서비스가 Up, 잘 실행되고 있다.
    
• 워드프레스 첫화면이 잘 나온다.
  
• 설치 및 실행도 잘 된다.
  
• 글과 댓글을 남겨본다.
• 이 데이터들은 백업되고있을 것이다.

도커 컴포즈 볼륨

• 도커 컴포즈에 정의한 대로 db볼륨과 wordpress볼륨이 존재한다.
  
• DB볼륨의 inspect를 살펴보면 Mountpoint가 있다.

docker-compose pause, unpose

• 도커 컴포스 컨테이너들을 일시정지 시킨다.
  
• 또, unpose명령어로 일시정지에서 다시 실행으로 돌릴 수 있다.

docker-compose port [container이름][port번호]

• docker-compose port 명령어로 열려있는 port정보를 확인할 수 있다.
• 현재 0.0.0.0 80으로 모든 IP주소에대해 80번 포트로 열려있는 것을 볼 수 있다.

docker-compose config

• 현재 올라와있는 docker-compose 서비스의 정보를 보여준다.

docker-compose stop

• 도커 컴포즈 컨테이너를 정지한다. pause가 일시정지라면 stop은 아예 프로세스에서 내려서 대기상태로 있는 것이다.

docker-compose rm, docker-compose down

• docker-compose rm 은 정지되어있는 컨테이너를 삭제한다.
• 또, docker-compose down은 아직 실행되고 있는 컨테이너를 stop하여 정지시키고 rm까지하는, 한번에 정지 및 삭제하는 명령어이다.

docker-compose up -d

• 도커컴포즈를 다시 실행시킨다.
  
• 분명히 삭제시켰다가 다시 실행했는데 글이 남아있는 것을 볼 수 잇다.
  
• 볼륨이 삭제되지 않고 남아있기 때문이다.

도커 컨테이너 모니터링

cadvisor

• VERSION=v0.44.0
  • 가장 최신의 버전을 사용한다.

docker run \						# 도커 컨테이너를 생성한다.
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  --privileged \
  --device=/dev/kmsg \
  gcr.io/cadvisor/cadvisor:$VERSION	#Cadvisor 최신버전이미지로 실행

• 컨테이너가 생성되었고, 스스로 헬스체크도 하고있다.
  
• IP주소와 run에서 설정한 포트번소(8080)으로 들어가면 cAdvisor에 접속할 수 있다.
  
• CPU정보를 알려준다.
  
• 메모리의 사용량도 체크 할 수 있다.
  
• 네트워크의 사용량도 체크해준다.

Docker Containers

• 현재 사용하고 있는 컨테이너들의 리스트를 보여준다.

도커 스웜

How nodes work (Cluster)

• 워커 안에 컨테이너들이 생성되서 작업을 할 것이다.
• 이때, Manager들이 워커들을 관리하게 된다.

도커스웜(Cluster)

• firewall-cmd --permanent --zone=public --add-port=2377/tcp
  • 방화벽이 켜져있다면 이렇게 포트를 열어줘야한다.
• firewall-cmd --reload
  • 그러나 현재 방화벽을 꺼놨기때문에 넘어간다.

호스트 정의

• cat <<EOF >> /etc/hosts

  192.168.1.93 manager1
  192.168.0.192 worker1
  192.168.0.141 worker2
  EOF

• docker swarm init --advertise-addr 192.168.1.93
  
• 매니저에서 도커 swarm을 생성한다.
• 스웜이 생성되어, 다음 worker등에서 join명령어가 포함된 위 명령어를 입력하여 스웜에 join하면 된다.
  
• This node joined a swarm as a worker 메세지가 나온다.
  
• 매니저에서 docker node ls 명령어로 연결된 node들이 잘 나오는 것을 볼 수 있다.

Desired state

• AutoScaling을 설정할 떄, 원하는 상태(Desired state)를 설정해놓으면, 기본 컨테이너의 개수를 원하는 상태만큼 만든다.
• docker service create --name my_web --replicas 3 --publish published=8080,target=80 nginx
  • container가 아니라 service를 생성한다.
  • publish 옵션은 -p옵션을 뜻한다.
  • target은 컨테이너의 포트 (목적지 포트)를 뜻한다.
  • 마지막 nginx는 사용할 이미지를 뜻한다.
    
• 매니저 안에 Service가 정의된다.
• 또, Task안에 container가 포함된다.
  • Container가 최소단위가 되는것이 아니라, Task가 최소 단위가 된다.
  • 이 Task가 나중에 kubernetes에서 Pods가 된다.

도커 스웜 실습

• 먼저 8080포트를 사용하고 있는 cAdvisor를 정지시켜준다.
  
• docker stop cadvisor
  • cadvisor를 정지시켜준다.
    
• docker service가 Desired state 3으로 실행중이다.
  
• 또, 매니저 VM에서 하나의 컨테이너가 실행중이다.
• 각 VM 에서도 하나씩의 컨테이너가 실행중이다.
• docker exec [컨테이너ID] sh -c "echo "[매니저 or 워커이름]" >> /usr/share/nginx/html/index.html"
• 이렇게 각 VM에 넣어주면 로드 밸런싱이 되는지 확인할 수 있다.
  
• 현재 크롬과 파이어폭스를 사용하여 maager1, worker2를 확인할 수 있다.
  
  
  
• 3개의 컨테이너에 모두 로드밸런싱이 되었다.

도커 서비스 살펴보기

• docker service ps my-web
  
• docker logs my_web
  • 서비스를 진행하며 출력된 로그들을 볼 수 있다.
    
• docker service inspect --pretty my-web
  • my-web의 inspect를 볼 수 있다.

도커 서비스 스케일업

• docker service scale my-web=5
  • my-web서비스의 Desired State를 5개로 올린다.
    
• 도커 서비tm의 REPLICAS가 5개가 되었다.
• 현재 worker2에만 부족한데 REPLICAS를 6개를 주면 worker2에 생길 것이라 예측할 수 있다.
  
• 도커 스케줄러가 VM에 공평하게 작업을 분배하는것을 스케쥴링이라 한다.

도커 서비스 스케일 인

• docker service scale my-web=2
  • 스케일 업했던 서비스를 다시 2로 내려본다.

롤링 업데이트

update

• 전체를 업데이트를 하는 것이 아닌, 조금씩, 일부를 지우고, 일부는 남기는, 이미지를 바꾸는 업데이트이다.
• docker service update --image jo1132/web-site:v2.0 my_web
  • 계속 새로고침을 하다가 보면 업데이트된 모습을 볼 수 있다.
    
• 옛날 페이지를 유지하면서, 업데이트 할 수 있는 컨테이너를 조금씩 업데이트한다.
• 한번에 중단하지 않고, 서비스를 유지하며 업데이트 하는 방법이다.
  
• 한 컨테이너당 이전 이미지와 새로운 이미지 각각의 컨테이너가 있다.
• 또, 새로운 버전이 Running중이고, 구버전은 Shutdown되어있다.

rollback

• rollback 명령어는 업데이트 이전으로 돌리는 명령어이다.
  
• nginx이미지를 가지고 있는 컨테이너가 Running중이고, 이전 버전의 컨테이너들은 Shutdown상태다.

rm

• 이 Shutdown은 계속 들어나게 된다.
  
• docker service rm my-web
  • my-web명령어로 정리해준다.

클러스터에서 특정 노드 드레인하기

서비스 생성

• docker service create --name my-web --replicas 3 --publish published=8080,target=80 jo1132/web-site:v2.0
  
• 새로 서비스를 생성한다.

드레인

• 드레인 : 물을 빼다.
• 한 node가 어떤 수정이 필요해서 Shutdown이 필요하다면, 그 node에서 작업중인 컨테이너 부하를 다른 node로 옮겨주는 명령어다.
  
• docker node update --availability drain worker1
  • worker1의 컨테이너를 종료하고 다른 노드에서 그 컨테이너를 생성하여 Desired State를 맞춘다.
  • 마치 worker1의 컨테이너를 manager1로 옮긴 것 같지만 ID를 비교하면 다른것을 볼 수 있다.
    
• 여기서 새로 생긴 컨테이너를 삭제해도 컨테이너의 수는 유지된다.
  • 이미지에서 보면 삭제하자마자 바로 다른 컨테이너가 생성되는 것을 볼 수 잇다.

드레인 해제

• docker node update --availability active worker1
  • worker1을 active상태로 다시 복구해준다.
• 이미지에 다시 Active상태로 돌아왔다.

그러나...

• 그러나 컨테이너의 재배치는 일어나지 않아, 드레인이 해제되어도 작업이 나눠지지 않아 컨테이너가 놀게된다.
• 이때 스케일업 혹은 스케일 다운을 하고 다시 원상복귀하면, 제대로 컨테이너 작업이 분배된다.
  
• drain으로 worker1이 쉬고잇다.
  
• worker1이 active되었지만 그대로 작업이 없다.
  
• 잘 분배 되었다.

pause

• docker node update --availability pause worker1
  • 현재 docker node ls 명령어로 보면, worker1이 pause되어있다.
  • 그러나 정지되는 것이 아니고, docker service ps my-web에서는 하나의 컨테이너가 작업되고있다.
  • pause는 정지는 아니지만, 더이상의 부하가 들어나지 않는다.
• docker service scale my-web=6 도서의 desired state를 6으로 늘려본다.
  • 6개로 늘리면 보통은 하나의 노드에 2개의 컨테이너씩 작업해야한다.
    
• 6개의 작업이 생겼지만, worker1에는 1개의 컨테이너만 ㅏㅈㄱ업하고 있다. 마스터:2, worker2:3, worker1:1 개로 worker1의 작업이 1 고정으로 늘어나지 않았다.

Kubernetes

Kubernetes의 이해

• 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
• 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 한다.
  • 선언적 구성(replicas=3, desired state)
• 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다.
  • 그러나 CNCF 단체에서 굉장히 상업적으로 운영하고있다.

쿠버네티스 아키텍처

• worker node들이 API서버에 접속해와서 정보를 가지고 작업한다.
  • API서버 아래 kube-scheduler가 노드들의 상태를 보고 작업(Pods)을 분산한다.
• kubelet(도커)이 API에게 수시로 물어서 pods를 할당받고, Pods 안에 컨테이너가 돌아가게 된다.
  • 즉, 작은 배(node)의 선장이 kubelet이다.
• Control Plane의 선장은 API가 된다.
• Controller Manager(CM)에서 Scheduler를 보고 Node를 컨트롤한다.
• Cloud Controller Manager(CCM)은 Cloud를 위한 것이다.

컨트롤 플레인 컴포넌트

• 컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인결정 (스케쥴링)을 수행하고, 클러스터 이벤트(예: 디플로이먼트의 replicas필드에 대한 요구조건이 충족되지 않을 경우 새로운 pod를 시작하는것, 자가치유)

Kube-apiserver

etcd

• 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소(BackEnd, 보안필요)로 사용되는 일관성, 고가용성의 키-값 저장소(NoSQL, KVS, Key-Value Store)
• 쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

kube-scheduler

• 노드가 배정되지 않은 새로 생성된 파드(Pod)를 감지하고
• 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트 스케줄링 결정을 위해서 고려되는 요소
  • 리소스에 대한 개별 및 총체적 요구 사항
  • 하드웨어/소프트웨어/정책적 제약,
  • 어피니티(affinity) 및 안티-어피니티(anti-affinity)명세,
  • 데이터 지역성,
  • 워크로드-간 간섭,
  • 데드라인
    을 보고, 스케줄을 고려하게 된다.