📒 Docker(4)

📌 Docker 정리

1. Docker 관련 용어

• Dcoekr Image
  -> 경량화 되어있고 간편하게 분리된 환경에서 사용가능하다는 장점을 가졌다.
  • Dockerfile : SW의 세팅파일
• Docker Container
• Docker Hub(hub.docker.com)
• Docker Compose
  • 다수의 Docker Container들을 관리
  • docker-compose.yml
    • Service
    • Networks
    • Volumes: host/anonymous/named volumes

2. Docker를 실제 Production 환경에서 사용할 때 유념할 점

• Docker volumes
  • Host volume은 보통 개발시 소스코드를 바로 container안으로 마운트하기 위함이다.
  • Production에서는 named volumes를 써야한다.
• Docker container는 read-only로 사용한다.
  • 내용을 바꿔야한다면 실행 중인 컨테이너를 수정하면 안된다.
  • 항상 이미지를 새로 빌드하고 다시 컨테이너들을 새로 Launch해야한다.
  • 자동화가 중요해졌다. : CI/CD 프로세스
• 다수의 Docker Container들을 다수의 Host들에서 실행이 필요하다.
  • 용량 문제와 Fail-over(또는 fail-tolerant)

3. Docker를 개인 생산성을 향상시키기 위해서 사용

• 개발시 필요한 모듈을 Docker Image로 받아와서 Container로 실행
• 여러 SW를 연동하여 개발하는 경우 이 것들을 docker-compose로 설정
• 장점
  • 일관된 방식으로 SW설치(문서화하고 매뉴얼하게 설치 불필요)
  • 분리된 충돌없는 환경에서 SW설치/실행

---

📌 서버 관리의 어려움

해결방안

1. 문서화

• 지금 서비스 상황과 셋업 방법 문서화
• 다양한 문제 발생시 해결 방법 문서화
• 문서를 현재 상황에 맞게 업데이트하는 것은 엄청난 노력이다.
• 또한 상황에 따라 의미가 없는 경유도 많다.
• 또 몇백대의 서버를 일일히 관리하고 명령을 실행한다는 것은 거의 불가능하다.

2. 코드로 관리

• Infrastructure As Code : DevOps 엔지니어가 꼭 알아야하는 기술
• 문서보다는 코드로 관리한다.
  • 대화형 명령보다는 자동화된 스크립트로 해결한다.
  • 다수의 서버들에 명령을 대신 실행해준다.
• 다양한 툴들이 쏟아져 나온다.
  • Chef
  • Puppet
  • Ansible
  • Terraform
  • ...
• 단점
  • Learning curve가 높다.
  • 설치시 SW 충돌 문제에는 크게 도움되지 않는다.

3. VM 도입

• SW 충돌 해결을 위해 VM을 사용
  • 한 Physical Server에 다수의 VM을 올리고 서비스별로 VM을하나씩 할당
• 단점
  • VM이 전반적으로 리소스 소비가 크고 느리다.
  • 결정적으로 특정 VM 벤더 혹은 클라우드에게 종속되어 버린다.(Lock-in)

4. Docker의 도입

• 모든 SW를 Docker Image로 만들면 간편하게 어디서든 동작 가능하다.
  • 기본적으로리눅스 환경에 최적화 되어있다.
• VM에비해 리소스 낭비도 적고 실행 시간도 빠르다.
• 오픈소스이기 때문에 클라우드나 특정업체 Lock-in 이슈도 없다.
• 단점의 적다.
  • Docker Container의 수가 늘어나면 관리가 어렵다.

정리

1. Docker의 장점

• Container 생성이 쉽고 빠르다.(VM과 비교했을때)
• Image를 통해 버전 관리, 배포하며 문제 발생시 롤백이 용이하다.
• 사용 언어등의 환경에 따른 관리방법에 차이가 없다.
  • 개발, 빌드, 등록, 실행 정차가일관되게 만들어졌다.(Dev, Test, Production)
• 오픈 소스이기 때문에 특정 클라우드 벤더나업체와 독립적이다.

2. Docker는 서비스 배포의 기본이 되었다.

• 많은 DevOps 엔지니어들은 모든 서비스를 Docker Image로 만들어 운영한다.
• 빌드 프로세스 출력물은 Docker Image가 되고 있다.
  • Github에서 빌드 프로세스를 보면 docker image를 만들고 이를 내부 Registry에 등록하는 것이 일반적이다.
• 다수의 Docker Image들을 더 많은 수의 Docker Container로 실행/관리 하는것이 필요해졌다.
• 모든 것의 컨테이너화 -> Containerization

---

📌 Container Orchestration

• Container Orchestration : 다수의 Container들을 잘 관리하는 것을 의미한다.
  -> DevOps 팀의 불필요한 작업들을 줄이는 것이다.

1. Container Orchestration 기능 - 요약

• 한 클러스터 안에 다양한 서비스들이 공존 DB, Web Service, Backend. ...
  • 자원 요청을 받아 마스터가 자원을 할당한다.
• 다양한 기능 제공 : 배포, 스케일링, 네트워크, 인사이트 등등

2. Container Orchestration 기능 - SW 배포

• 서비스 이미지를 Container로 배포한다.

• 이상이 감지되면 이전 안정 버전으로 롤백!

  • v1에서 v2로 배포가 되는 경우 문제가 생기면 v1으로 롤백
  • Container의 수가 많을수록 큰 이슈가 된다.
  • DevOps 팀 관점에서 보면 가장 중요한 기능이다.

3. Container Orchestration 기능 - 스케일링

• 특정 서비스의 Container 수를 쉽게 늘리고 줄이는 것
• 이때 서버의 Utilization도 고려해야한다.

4. Container Orchestration 기능 - 네트워크

• 서비스가 다수의 컨테이너로 나눠지면서 이들을 대표하는 Load Balancer를 만들어주어야 한다.
• 서비스들간에 서로를 쉽게 찾을 수 있어야한다.
  • 서비스 디스커버리

5. Container Orchestration 기능 - 인사이트

• 노드/컨테이너 문제시 해결
  • 서버 2의 F가 다운되면 이를 서버 3에 재실행
  • F 로드밸런서 정보도 맞게 수정
• Logging/Analytics 등등의 기능 제공
  • 외부 서비스 plug and play
• 전체 서비스 분석
  • 시각화
  • 문제 분석

6. Container Orchestration Tool

• Mesos
• Marathon
• DEIS
• Rancher
• Nomad
• Docker Swarm
• K8s(Kubernetes)

---

📌 K8s

컨테이너 기반 서비스 배포/스케일/관리 자동화를해주는 오픈소스 프레임워크

• 구글에서 사용하던 Borg 서비스를 오픈소스화한 것이다 (2015년)
• 클라우드나 on-prem 모두에서 잘 동작한다.
• 어느 컨테이너이던 가능하지만 주로 Docker Container들이 대상이 된다.
• 물리서버나 가상서버 위에서 모두 동작한다.
• 지금은 Cloud Native Computing Foundation이라는 비영리 단체에서 운영한다.
  • 클라우드 환경에서 어떻게 SW를 배포하는 것이 효율적일까?
    • 컨테이너, 서비스메시, 마이크로서비스, API, DevOps, On-demand Infra

가장많이 사용되는 컨테이너 관리 (Orchestration) System

• 사용회사와 커뮤니티 활동이 굉장히 많고 활발하다.
• 카카오, 네이버, 라인, 쿠팡 등의 국내 업체도 활발히 사용한다.
• K8s위에 기능을 추가한 Container Orchestration 툴들이 생겨났다.
• 모든 글로벌클라우드 업체들이 지원한다. : EKS, AKS, GKE

확장성이 좋아서 다양한 환경에서 사용된다.

• ML : Kubeflow
• CI/CD : Tekton
• Service Mesh : Istio
• Serverless : Kubeless

다수의 서버에 컨테이너 기반프로그램을 실행하고 관리한다.

• 컨테이너 기반 프로그램 == Docker Container
• 보통 Docker와 K8s는 같이 사용된다.
• Pod : 같은 디스크와 네트워크를 공유하는 1+ 컨테이너들의 집합

---

📌 K8s 아키텍처

1. 기본 구조 : 마스터 - 노드

• 노드는 물리서버이거나 가상 서버이다.
• 클러스터는 1+ 노드의 집합이다.
• 마스터는 클러스터를 관리해주는 역할을 수행한다.
• Kubelet : 마스터와 통신하는 에이전트

2. 기본 구조 : K8s 프로세스

• Master 안에는 여러 프로세스들이 돌고 있다.
  • API Server(Container로 동작) : kube-apiserver
    • Entrypoint of K8s cluster
    • Web UI, CLI(kubectl), API
  • Scheduler
    • Pods 생성과 할당(노드들의 상황을 고려 - Utilization)
  • Controller Manager
    • 전체 상황을 모니터링하고 fault tolerance 보장
  • Master는 High Availability가 중요하다.
  • etcd
    • K8s 환경 설정 정보가 저장되는 key/value 스토어로 백업된다.
• Controller runtime
  • 대부분 Docker가 사용된다.

3. Kubectl : 커맨드라인 툴

• kubectl run hello-minikube
• kubectl cluster-info
• kubectl get node

4. Pod란?

• 다시 한번 K8s 사용시 컨테이너를 바로 다루지 않는다.
• Pod : K8s 사용자가 사용하는 가장 작은 빌딩 블록
• 1 Pod : 보통은 하나의 Container로 구성
  • 하나보다 많은 경우에는 보통 helper container가 같이 사용된다.
  • 같은 pod 안에서는 디스크와 네트워크가 공유된다.
  • Fail-over를 위해서 replicas를 지정하는 것이 일반적이다.
    • 다양한 방법으로 복제본을 유지한다.
• Pod는 네트워크 주소를 갖는 self-contained server

5. Yaml 환경 설정 예시

apiVersion: apps/v1
kind: Pod
metadata:
	name: nginx
spec:
	containers:
    - name: nginx
    	image: nginx

6. Pod 생성 예시

• kubectl create -f pod-definition.yml
• kubectl get pods
• kubectl describe pod nginx
• kubectl run nginx --image nginx

---