[산대특] Docker와 Kubernetes

1030

 

  Docker와 Kubernetes

  가상 컨테이너에서 실행되는 Docker(API 이미지)

Docker Orchestration (운영 관리) => Kubernetes(Kube, K8s) 

 

AI Labs에서 사용 중인 도구들은

▪ Openstack

(가상 컨테이너는 소프트웨어를 연결하기 위한

소프트웨어적인 스위치와 라우터를 구축해주는 오픈 소스 프로그램) => 사내 클라우드 구축 

▪ Docker / Kubernetes 등으로 환경 구성과 서비스 지원

▪ Helm(Kubernetes 패키지 매니저)으로 서비스 설정과 지원

▪ Prometheus(Helm에서의 정보 수집) / Grafana(오픈소스 메트릭/로그 시각화 대시보드 제공)로 클라우드 모니터링 

▪ Terraform(오픈소스 클라우드 인프라스트럭처 자동화)으로 인프라 자동화 구축

식으로 운영

인프라스트럭처 : 기본적인 구조나 시스템을 의미

 

  Docker 

컨테이너 기반 가상화 도구

Go언어

리눅스 상에서 계층화된 파일 시스템을 기반

효율적으로 도커 이미지 API를 외부 호스트의 CPU 프로세스를 격리한

프로세스 실행환경(VMware에서의 각 가상머신과 같은 개념)에서 컨테이너 방식으로 실행 및 관리. 

 

만들어진 이미지는 파일로 보관 or GitHub(원격 저장소로 쉽게 공유)

도커 API만 설치되어 있다면 필요할 때 언제 어디서나 새롭게 컨테이너로 실행시키는 것이 가능

 

각 컨테이너는 독립적

 

API : 소프트웨어 응용 프로그램 간의 상호작용을 가능하게 하는 규칙과 도구의 집합

 

  VM(Virtual Machine) API와 Container API 

컨테이너는 호스트의 CPU 프로세스를 격리해서 각 컨테이너가 각 프로세스에서 독립적으로 실행

각 컨테이너는 단순히 CPU의 각 프로세스에 불과, 도커를 컨테이너형 가상화

도커는 이런 컨테이너형 가상화를 지원하는 도구 중 하나

 

컨테이너는 호스트 OS나 VMware/KVM(Linux 서버에서 생성)/Hyper-V(Windows 서버에서 생성) 위에서

각 컨테이너 별로 binary/library를 분리해서 사용함

이미지 APPs가 필요로 하는 라이브러리와 설정만 가지고 있다.

 

=> Hyper-Visor > VM > Container 순으로 오버헤드가 크다. (시스템 리소스 관리와 관련된 것)

osi 7계층의 오버헤드와 다름 (네트워크 데이터 전송과 관련된 것)

 

도커 컨테이너 이미지는 라이브러리와 실행 파일만 가지고 있어 이미지 크기가 작다.

Monolithic 방식 X

MicroService 방식(대입해야 하는 값을 하나하나 개별적으로 불러들이는 방식)으로 운영

특정 언어에 종속적이지 않고 모듈 관리가 쉽다.

 

  Docker는 소프트웨어 배포와 테스팅을 위해서 만들어짐

=> (CI(Continuous Integration)/CD(Continuous Development/Deployment)).

컨테이너는 실행 코드와 그에 종속적인 것들을 묶어서 응용층에 둔 추상화 개념

 

외부 호스트 머신의 OS 커널을 다른 컨테이너들과 공유

=> 각각 격리된 프로세스로 실행

VMware같은 가상머신들은 OS 커널을 독립적으로 가지고 실행 => 도커보다 무겁다.

==> Docker는 OS가 필요 없고 디스크, 메모리 등 리소스를 적게 사용

 

VM은 서비스에 목적, Container는 빠른 솔루션 배포에 목적. 

 

  컨테이너의 네트워크 OSI상 계층구조 [인터뷰]

Layer 6 => 표현층 Development WorkFlow,  Opinionated Containers	Docker Cloud, OpenShift, Cloud Foundry, Deis, Flynn, ...
Layer 5 => 세션층 Orchestration/Scheduling Service Model	Kubernetes, docker Swarm, Marathon/Mesos, Nomad, Diego, ...
Layer 4 => 전송층 Container Engine	Docker, Rocket, RunC(OCI), Osv, LSC, LXD, ...
Layer 3 => 네트워크층 Operating System	Ubuntu, RHEL, CentOS, Unikernels, ...
Layer 2 => 데이터링크층 Virtual Infrastructure	OpenStack, vSphere, EC2, GCP, AWS, Azure, ...
Layer 1 => 물리층 Physical Infrastructure	Raw Computer, Network, Storage, ...

 

▪ 도커는 Software Container Platform으로써 Linux 컨테이너 기술을 적용한 Docker Engine, Docker Hub Registry를 통한 Docker Image로 구성된다. 

 

▪ CI(Continuous Integration)/CD(Continuous Delivery/Deployment)

  CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법이다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 서비스 배포이다. CI/CD는 새로운 코드를 통합하는 방식이므로 개발 및 운영팀에서 발생하는 문제(일명 "통합 지옥(integration hell)")를 해결해주는 솔루션이다.

  "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미하는데 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항을 정기적으로 빌드하고 테스트를 거쳐서 공유 리포지토리에 병합시킴으로써 여러 명의 개발자들이 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 해결할 수 있다. 

  "CD"는 지속적인 서비스 제공(Continuous Delivery) and/or 지속적인 서비스 배포(Continuous Deployment)를 의미하는데 이 두 용어는 혼용되어 사용된다. 두 가지 모두 작업의 연계를 위한 파이프 라인의 추가와 같은 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해서 별도로 사용되기도 한다. 

 

  CD를 좀 더 세분화

▸ 지속적인 서비스 제공(CD: Continuous Delivery)란 

개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결

지속적인 서비스 제공의 최종 목표인 최소한의 노력으로 새로운 코드를 배포

▸ 지속적인 배포(CD: Continuous Deployment)란 

운영팀에서 수동 프로세스로 인해서 애플리케이션 제공을 느려지는 단점을 해결.

지속적인 배포는 파이프라인을 통해서 다음 단계를 자동화하여 지속적인 서비스를 원활히 제공

 

  CI/CD에서의 파이프 라인

애플리케이션의 통합 및 테스트 단계로부터 서비스 제공 및 배포에 이르는 애플리케이션의 라이프 사이클 전체에 걸친 지속적인 자동화와 지속적인 모니터링을 제공하는데 이러한 구축을 일반적으로 “CI/CD 파이프 라인”이라고 부른다. 

  개발 및 운영팀의 Agile([애자일] 신속한 반복 작업을 통해서 실제 작동 가능한 소프트웨어를 개발하고 지속적으로 제공해주는 소프트웨어 개발 방식) 방식의 협력을 통해서 DevOps([데브옵스] 소프트웨어의 개발과 운영의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화) 또는 

SRE(사이트 신뢰성 엔지니어링: IT 운영에 대한 소프트웨어 엔지니어링 접근 방식으로 SRE 팀은 소프트웨어를 툴로 활용하여 시스템을 관리하고, 문제를 해결하고, 운영 태스크의 자동화) 방식으로 지원된다. 

=>여기에는 Jenkins, CircleCI, Teamcity, Bamboo, GitLab 등의 도구가 사용되고 있다. 

 

AWS(Amazon Web Service)의 Kubernetes 적용도 널리 사용된다. 

 

 Kube는 체계적인 컨테이너 조작과 관리를 위한 도구

=> 운영[Orchestration으로 부름] 을 통해

Kube의 Computing(연산)능력으로 Virtual Server와 Auto Scaling, Management를 통한 Monitoring을 수행한다. 

 

컨테이너에서 할 수 있는 것들
환경설정	컨테이너 서비스 선정, 저장 용량 산정, 개발 환경 검토 및 산정
환경구성	개발환경 개발/도입, 플랫폼 아키텍처 구성, 컨테이너 서비스 설치/설정
전환교육	컨테이너 플랫폼 교육, MSA 개발교육
App개발	App 아키텍처 수립, App 설계/개발, 개발자 기술지원, 성능 테스트 지원,  성능 모니터링 체계 구축(로그, App 상태 등)
플랫폼	운영과 유지 모니터링, 백업/복구, 알림(Alert),  변경관리(플랫폼 패치 및 업그레이드), 장애관리, 기술지원, 성능 점검 등

 

  기업들은 클라우드에서의 Docker와 같은 컨테이너 운영을 통해서 

▪ H/W 초기 투자비용 절감, Add-on 서비스 개발/구축비용 절감, 운영 비용절감 

 

docker [OPTION] COMMAND 형식으로 사용

∎ start는 죽어있는(exited) 컨테이너를 시작

∎ exec는 이미 실행 중인 컨테이너 접속

∎ run은 새로운 이미지를 생성해서 컨테이너 안에서 실행

∎ create는 run과 같게 새로운 컨테이너 생성에만 사용

∎ docker images 해서 다운된 이미지를 확인

 

특정한 이미지를 만들고 싶으면 Bare 한 이미지를 받아서 내가 원하는대로 설정 한 뒤

docker commit 커밋할컨테이너 이미지이름

해주면 됨.

 

docker rename A B 하면 기존 A를 B 이름으로 변경

 

create ~	스크립트로 새로운 컨테이너를 생성할 때 사용
run ~	다운받거나 생성한 이미지를 실행할 때 사용
start ~	docker ps -a 해서 Exited 된 컨테이너를 시작할 때 사용
exec -it ~	백그라운드(-d로 실행한 컨테이너) 실행시켜둔 기존 컨테이너에서 콘솔로 들어가거나, exited 된 컨테이너를 docker start 해서 살린 뒤 콘솔로 들어갈 때 사용 =>docker ps -a 해서 보았을 때 Exited는 죽은 것이 아니라 컨테이너 쉘에서 벗어난 것을 의미
stop ~	docker ps 해서 확인했을 때 실행 중인 컨테이너를 일시 정지할 때 사용
restart ~	docker stop ~ 해서 일시 정지된 컨테이너를 재시작할 때 사용 이어서 docker exec ~ 해서 쉘로 들어갈 수 있다.