어떤 이유 때문에 지금 도커를 쓰고 있는가?
- 배포가 아니더라도 로컬 테스트할 때 환경 맞추기 편리해요
- 로컬에서 테스트를 할 때 편하다
- DB 구분 하거나
- 도커 컴포즈로 여러 서비스를 한 번에 올리자
- 서버를 3개의 환경으로 구성
- 배포할 때 버전별로 저장 후, 문제 있을 때 롤백
- 대부분의 회사에서 도커를 쓰고 있기 때문에 일단 학습
- 여러 개의 VM을 여러 인스턴스로 띄워버렸는데, node 버젼등을 한번에 관리하기가 어려워서 하나의 인스턴스를 띄우고 컨테이너를 나누면 어땠을까? 라는 의문때문에 도커 이야기가 나왔었습니다.
- 여러 개의 node 버전을 관리할 이유가 있을까요? → 어떤 이유 때문에 이런 과정이 필요한가
- github actions에서 nvm 때문에 문제가 터졌었는데, 도커를 통해서 node 버젼을 설정했다면 가능하다고 생각했었습니다!
- github actions의 실행환경과 node version의 차이? 때문인가?
- Dockerfile, docker-compose 파일들을 남겨서 배포시 어떤과정을 거치면서 했는지 확인할 수 있다.
- 서버를 여러개 사용하다보니 도커를 사용하면 한번의 액션으로 배포 과정을 단순화하고 서버 환경 설정 처리를 통일성 있게 지정할 수 있어 도입하였어요
- React를 썼어요
- 어떤 상황에서는 React를 안 쓰는게 좋을까요?
- 무지성으로 우리가 Docker를 쓰거나 React를 쓰거나 하는게 아닌가?
- 기술을 쓰는 것에 대한 “명확한” 이유가 필요하다
- 끼워맞추기라도 필요하다
- 이유를 알아야 된다.
어떤 이유 때문에 지금 도커를 쓰고 있는가?1. Docker란?도커컨테이너가상화활용2. 도커의 동작Dockerfile 작성buildpushpullrun3. 파이프라인을 설계해본다면?etc. 알면 좋은 것들 (키워드)
1. Docker란?
“격리된” 환경에서 실행하자
Docker 이전
- 서버를 구매
- mysql 설치
- nginx 설치
- apache 설치
- java 설치
- ….
- 이 중에 하나라도 터지면?
- “사이드 이펙트”가 있고, 한 번 문제가 발생하면 심각하다.
Docker 이후
- MySQL Image
- Nginx Image
- …
- “사이드 이펙트”가 없다. 내 문제는 나만 책임진다.
- 도커 이전에도 VM을 쓰긴 했으나 무척 무겁고 사용성도 좋지 않았음
도커
- 도커는 컨테이너를 이미지 파일로 빌드하고 배포하여 어디서나 실행할 수 있도록 해주는 오픈소스이다.
- 컨테이너를 git 에 저장된 소스처럼 build/push/pull 할 수 있는 방법을 먼저 제공하면서 주목 받았다.
컨테이너
- 컨테이너는 어플리케이션의 런타임 인스턴스이다.
- 컨테이너 단위로 OS, 라이브러리, 어플리케이션을 패키징 할 수 있다.
- 컨테이너는 OS 에 여러 어플리케이션을 독립적으로 실행할 수 있도록 해준다.
- 즉, 컨테이너는 여러 어플리케이션의 격리된 환경을 지원하는 가상화 기술로 볼 수 있다.
- 리스크 관리
- A에서 문제가 터져도 B에는 영향이 없어야된다.
- 격리가 안되어있으면
- A가 문제가 생겼을 때 B에도 문제가 생긴다.
- 커플링
- 여자친구한테 문제가 있을 때
- 나한테도 영향이 있네
- 좋은 인간관계
- 감정적으로 격리가 잘 된 사람들을 다양하게 사귀는 것
가상화
- 컨테이너는 하나의 OS 위에서 여러개가 실행된다.
- 각각의 컨테이너는 사용자 영역에서 격리된다.
- 컨테이너는 VM 보다 가볍고 빠르다.
활용
- 서비스에 필요한 OS, 라이브러리, 어플리케이션을 컨테이너로 묶을 수 있어서 업데이트나 롤백 시 안정적이다.
- 컨테이너는 가볍고 빠르기 때문에 서비스 배포 시 빠르게 반영할 수 있다.
- 컨테이너 실행 환경만 갖춰져 있으면 어디서나 실행되기 때문에 신속한 서비스 스케일링이 가능하다.
- 단일 호스트의 장애를 컨테이너의 이동으로 대응하여 보다 빠르게 복구할 수 있다.
- 서비스와 운영을 분리할 수 있어서 컨테이너 실행 환경을 더이상 신경쓰지 않아도 된다.
2. 도커의 동작
- 클라이언트 (docker) 와 서버 (dockerd) 로 구성할 수 있다.
- 모든 명령은 클라이언트에서 REST 로 서버에 요청되어 서버에서 수행한다.
- 간단한 동작 방식은 아래와 같다.
- 도커 이미지를 빌드하기 위해 Dockerfile 을 작성한다.
- Dockerfile 과 함께 도커 빌드 요청을 보낸다.
- 도커 서버에서는 도커 이미지를 빌드하여 로컬 저장소에 저장한다.
- 도커 push 명령을 받으면 도커 서버는 로컬의 도커 이미지를 도커 레지스트리에 올린다.
- 도커 run 명령을 배포할 도커 서버에 전송한다.
- 도커 run 명령을 받은 도커 서버는 도커 레지스트리에 이미지를 로컬 저장소로 다운 받는다.
- 도커 이미지를 이용하여 컨테이너를 시작한다.
Dockerfile 작성
// main.js const axios = require('axios'); axios.post('https://api.github.com/repos/junilhwang/docker-tutorial/issues/1/comments', { body: 'current timestamp: ' + Date.now() }, { headers: { Authorization: "Bearer ...." }, });
FROM node:16-alpine USER boostcamp WORKDIR /home/boostcamp COPY . . RUN npm install CMD npm run start
build
$ cat Dockerfile $ docker build -t github-issue-maker:junilhwang . $ docker image ls $ docker ps -a
push
# Usage: docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG] $ docker tag github-issue-maker:junilhwang junilhwang/github-issue-maker:0.0.1 $ docker image ls $ docker push junilhwang/github-issue-maker:0.0.1
pull
- image를 실행하고 싶은 server로 접속
$ docker push junilhwang/github-issue-maker:0.0.1
run
$ docker run -d --github-issue-maker junilhwang/github-issue-maker:0.0.1
3. 파이프라인을 설계해본다면?
- Dockerfile 작성
- github actions로 workflow 작성
- merge가 되면 실행 or workflow_dispatch로 실행
- step1: docker build, tag, push
- step2: ssh 접속
- step3: docker pull, run
- 근데 이거 굳이 docker로 해야돼?
- 그냥 ssh로 접근해서 git pull, install, build, 하면 더 간단하지 않나?
- 그럼 언제 docker를 써야 좋은거지?
etc. 알면 좋은 것들 (키워드)
- 네임스페이스
- docker hub를 스스로 구축해보기 (opensource 활용)
- cgroup → cpu 우선순위 할당 → 특정 컨테이너의 cpu 점유율 우선순위 정하기