예전 국비시절에 도커를 살짝 맛봤는데 맛났던 기억이 있다. 시스템 엔지니어로 취업하고 나름 혼자서 공부 해보려 했지만 일과 병행하기가 쉽지않더라.(는핑계) 지금은 개발자로 취직을 준비하고 있지만 데브옵스 직무에 대한 열망이 아직 남아있어서 인프런의 [초보를 위한 도커 안내서] 강의가 세일하길래 냉큼 사봤다.
각설하고 어여 공부한 내용을 정리해보쟈.
서버를 관리한다는 것
개인적인 경험에 빗대어 얘기하자면 서버관리는 복잡하고 쉽지않다. (매 순간이 기도메타..)
강의에서 선생님이 말씀해주신 경험이 너무나 공감되었다. 나도 엔지니어 처음 입사했을땐 apache-mysql-php 설치 요청을 받았던 기억이 있다. 이후엔 좀 더 복잡한 설치 요청이나 계속해서 바뀌는 서버 환경에 맞춰 세팅해야하는 일이 빈번했다.
서버관리 방식의 변화
전통적인 서버관리 방식은 다음과 같다.
너무 많고 길다. 나는 IDC에서 이 방식으로 한땀한땀 서버를 쌓아 올렸다.
도커가 등장하고부터는 서버관리/개발 방식이 완전히 바뀌게 되었다고 한다. 서로 다른 프로그램들을 공통적인 어떠한 형태, 즉 컨테이너로 만들 수 있고 컨테이너로 만들어두면 어디서든 실행이 가능하다.
VM vs Container
도커를 설명할때 빼먹을 수 없는 비교이다.
VM
- 구현 방법에 따라 다르지만 하이퍼바이저를 이용해서 여러 개의 운영체제를 하나의 Host OS에서 생성해서 사용하는 방식
- 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 하이퍼바이저를 거치기 때문에 일반 호스트에 비해 성능의 손실이 발생
Container
- 리눅스 자체 기능을 사용함으로써 프로세스 단위의 격리된 환경을 만들기 때문에 성능 손실이 거의 없음
- 컨테이너를 이미지로 만들어 배포하는 시간이 VM에 비해 쉽고 빠르며, 효울적
도커가 등장하기까지
전통적인 서버 관리 방식을 떠올려보자. 열심히 쌓아 올렸지만 어디 한군데에서 문제가 생기면 와르르 무너질 수 있다.
전동적인 방식 -> 컨테이너 방식 어떻게 등장하게 된걸까? 서버 상태 관리를 위한 노력에서 비롯되었다고 볼 수 있다.
서버 운영하기
1. 문서 작성
나도 신입 시절에 받아봤다. 선배가 작성해놓은 설치가이드..!
문서 그대로 잘 되면 정말 감사한 일이지만 대부분의 경우가 눈물 콧물 쏙빠지는 일이었다.
- 똑같이 해도 안됨
- OS 별 설치 방법이 달라서 한정적임
- 중간에 버전이 바뀌면 어떤 일이 벌어질지 모름
- 문서 업데이트가 느림
이밖에 많은 문제점이 많아서 결국엔 혼자서 싸워나가야 한다. 어쩌면 강해지라는 회사의 큰그림일지도 모른다.
2. 상태관리 도구
CHEF, puppet 등과 같은 도구로 설정파일로 관리하는 것이다. 설정 공유가 가능해서 문서보단 관리가 용이하지만 버전관 리가 어렵고 자칫하면 덮어씌워지는 대참사가 일어날 수 있다.
3. 가상머신
한 서버에 여러개를 설치할 수 있고 현재 상태를 이미지로 저장이 용이하다는 장점이 있지만 용량이 너무 크다는 단점도 존재한다. 또한 속도 저하라는 고질적인 문제도 존재한다.
4. 자원격리
프로세스, 파일, 디렉토리를 가상으로 분리하고 서버 자원을 그룹별로 제한하는 방법이다. 리눅스 기능을 이용한 빠르고 효율적으로 서버 관리가 가능하지만 사용이 너무 어려운 큰 단점이 있다.
결국 도커는 서버의 상태를 관리하기 위한 노력으로 등장하게 되었다.
도커란?
Go언어로 작성된 리눅스 컨테이너를 기반으로 하는 오픈소스 가상화 플랫폼으로 특정한 서비스를 패키징하고 배포하는데 유용한 오픈소스 프로그램이다.
도커의 특징
확장성/이식성
- 도커가 설치되어 있다면 어디서든 컨테이너를 실행할 수 있음
- 특정 회사나 서비스에 종속적이지 않음
- 개발 서버와 테스트 서버를 쉽고 간편하게 만들 수 있음
표준성
- 도커를 사용하지 않는 경우 여러 언어로 만든 서비스들의 배포 방식은 제각각 다른데, 컨테이너를 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일해짐
이미지
- 이미지에서 컨테이너를 생성하기 때문에 반드시 이미지를 만드는 과정이 필요함
- Dockerfile(스크립트 파일)을 이용하여 이미지를 만들고 처음부터 재현이 가능함
- 빌드 서버에서 이미지를 만들면 해당 이미지를 이미지 저장소에 저장하고 필요한 운영서버에서 이미지를 불러옴
설정관리
- 환경변수로 제어함
- 컨테이너를 띄울때 환경변수를 같이 지정할 수 있음
- 하나의 이미지가 환경변수에 따라 동적으로 설정파일을 생성하도록 만들어져야함
자원관리
- 컨테이너는 삭제 후 새로 만들면 모든 데이터가 초기화되기 때문에 업로드 파일을 외부 스토리지와 링크하여 사용하거나 S3같은 별도의 저장소가 필요함
- 세션이나 캐시를 memcached나 redis와 같은 외부로 분리해야함
도커가 가져온 변화!
- 클라우드 이미지보다 관리하기 쉬움
- 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하가 거의 없음
- 리눅스의 복잡한 기술을 몰라도 사용할 수 있음
- 이미지 빌드 기록이 남음
- 코드와 설정으로 관리할 수 있고 재현 및 수정이 가능함
- 오픈소스라는 장점때문에 특정 회사 기술에 종속적이지 않음
도커의 미래? = 컨테이너의 미래
도커가 하나의 프로그램을 관리하는 방식이라고 하면 쿠버네티스는 여러대의 서버와 여러개의 서비스를 관리하는 방식이다. 쿠버네티스 안에 도커가 여러개로 이루어져있다고 볼 수 있다.
간단하게 대표적인 기능을 소개해보자.
스케줄링
- 컨테이너를 적당한 서버에 배포해주는 작업, 즉 효율적으로 서버관리가 가능함
- 여러 대의 서버 중 가장 할일 없는 서버에 배포하거나 그냥 차례대로 배포 또는 아예 랜덤하게 배포함
- 컨테이너 개수를 여러 개로 늘리면 적당히 나눠서 배포하고 서버가 죽으면 실행 중이던 컨테이너를 다른 서버에 띄워줌
클러스터링
- 여러 개의 서버를 하나의 서버처럼 사용
- 작게는 몇 개 안 되는 서버부터 많게는 수천 대의 서버를 하나의 클러스터로 사용
- 여기저기 흩어져 있는 컨테이너도 가상 네트워크를 이용하여 마치 같은 서버에 있는 것처럼 쉽게 통신
서비스 디스커버리
- 서비스를 찾아주는 기능
- 클러스터 환경에서 컨테이너는 어느 서버에 생성될지 알 수 없고 다른 서버로 이동할 수도 있음
- 따라서 컨테이너와 통신을 하기 위해서 어느 서버에서 실행중인지 알아야하고 컨테이너가 생성되고 중지될 때 어딘가에 IP와 Port같은 정보를 업데이트 해줘야함
- 키-벨류 스토리지에 정보를 저장할 수도 있고 내부 DNS 서버를 이용
오랜만에 도커를 공부하니 감회가 새롭다. 왜 내가 국비시절 도커강의를 열심히 들었는지 다시한번 떠올렸달까!!! 해승몬의 즐거운 도커 포스팅은 계속됩니다!
