Section2 Docker

드디어 도커가 시작됐다!

일할때 도커도커 얘기는 많이 들었어서

컨테이너 방식으로 뭐 서버를 어쩌구.. 이런 것 만 알았는데 이번에 제대로 공부할거당

---

• 컨테이너 : 도커라는 기술 위에 의존성, 네트워크 환경, 파일 시스템에 구애받지 않고 실행될 수 있도록 만든 기
• 이미지 : 애플리케이션 및 애플리케이션 구성을 함께 담아놓은 템플릿. 이미지를 이용하여 즉시 컨테이너를 만들 수 있다.
• 레지스트리 : 이미지가 저장되는 저장소

컨테이너 방식의 장점

1. 의존성 충돌 해소

애플리케이션을 컨테이너로 패키징하여 동일한 환경에서 실행시킬 수 있도록 환경을 격리시킨다.

예를 들어 여러 애플리케이션이 같은 라이브러리의 다른 버전을 필요로 한는 경우, 도커는 각 애플리케이션을 해당 버전의 라이브러리가 포함된 독립적인 컨테이너를 생성하고 실행할 수 있다.

컨테이너는 프로세스, 네트워크, 파일 시스템을 격리하고 독립적으로 소유한다.

 

• Docker vs VM

 

VM : 하이퍼바이저 위에 가상환경을 만들어 OS를 설치하여 가상환경을 만든다. (운영체제를 무조건 설치해야함. 많은 컴퓨팅 자원 필요)

Docker :  컨테이너에 OS를 설치하지않고 호스트 OS 커널을 공유하여 패키지만 있으면 구동이 가능하다. (애플리케이션 단위의 이미지로 구성. 컴퓨터에 큰 무리 없이 작동)

 

2. 개발과 배포 환경을 일치시켜준다

개발 환경 : OS에 상관없이 즉시 애플리케이션 실행 환경을 만들 수 있고 개발을 컨테이너 위에서 진행할 경우 개발팀 모두 동일한 환경하에 진행할 수 있다.

 

배포환경 : 컨테이너 자체를 배포하는 방식을 사용하여 애플리케이션 하나 하나 배포할 필요가 없이 편하게 배포할 수 있다. (EC2에 도커를 설치하거나 ECS를 사용)

3. 수평 확장과 CDC

CDC : 변경된 데이터를 실시간으로 감지하여 도커 컨테이너의 반영. 수정한 부분만 감지하여 컨테이너에 반영할 수 있다. 

 

오케스트레이션 도구 : 동일한 이미지를 바탕으로 새로운 서버에 애플리케이션을 컨테이너로 실행하고 로드밸런서에 추가하면 간편하게 서버 확장이 가능하다.

ex) 쿠버네티스

 

---

Sprint

도커를 사용하여 프론트앤드 서버와 백엔드 서버를 만들어보자

 

각 도커를 build하는 방식인 Dockerfile 을 만들고 두 이미지를 동시에 실행하는 docke-compose.yml 파일을 작성해보자

 

이미지를 생성하고 관리하는 방법에는 commit 과 build가 있는데 조금 헷갈려서 개념을 잡아보았다.

• build : Dockerfile이라는 파일을 사용하여 이미지를 빌드한다. dockerfile에 작성된 지침에 따라 이미지를 만든다. 일반적으로 build 명령으로 이미지를 생성.
• commit : 실행중인 컨테이너에서 변경된 내용을 새로운 이미지로 만든다. 

 

* frontend Dockerfile

FROM httpd:2.4s

COPY ./ /usr/local/apache2/htdocs/

 

* backend Dockerfile

FROM node:16-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 80

CMD [ "node", "app.js" ]

* docker-compose.yml

version: "3.0"

services:
  nginx:
    build:
      # context : 빌드할 Dockerfile의 위치
      context: ./frontend
      # dockerfile : 빌드할 dockerfile의 파일명
      dockerfile: Dockerfile
      # 캐쉬 유무
      no_cache: true
      # 이미지 이름과 태그
    image: frontend:1.0
    ports:
      - "80:80"
    container_name: "frontend"

  node:
    build:
      context: ./backend
      dockerfile: Dockerfile
      no_cache: true
    image: backend:1.0
    ports:
      - "3333:80"
    container_name: "backend"

스프린트에서 에러가 났던 부분

 

1. build 작성 부분

: 각각 이미지를 빌드하는 것 보다 한번에 compose 시에 빌드하도록 하기 위해 yml 파일에 빌드 부분을 작성했다.

context 키의 밸류값을 dockerfile의 경로로 작성해주고 dockerfile 키의 밸류값은 dockerfile 의 파일 이름을 작성해주면 docker-compose up 구문을 실행할때 두 이미지 모두 정상적으로 빌드 되는 것을 볼 수 있었다.

 

2. 이미지의 캐시 저장

스프린트를 진행하면서 이미지를 삭제했다가 다시 빌드해도 이전에 만든 이미지로 다시 만들어지는 현상을 발견했다. 아무리 지워도 몇시간 전 빌드했던 이미지가 다시 올라갔다. 캐시를 저장하나.. 생각이 들어 구글링을 해봤더니 도커 이미지도 캐시를 저장한다고 하여 캐시를 저장하지 않도록 yml 파일을 작성하는 키값을 찾아 작성했다.

no_cache 키에 true 밸류를 작성하면 캐시를 저장하지 않는 이미지 빌드 성공한다.

하지만 매번 빌드를 다시해 시간이 오래걸린다.

이미지 캐시 유효시간을 정할 수 있나..? 해서 찾아봤더니 그런건 없다고 한다...ㅎ

---

오늘의 회고

 

움 도커 재밌당

너무 재밌고 신기하다.

예제가 흥미로워서 그런가..?

암튼 실습을 너무 재밌게 했다

개념도 진짜 신박하고 어캐 이런걸 생각했지..?

 

ECS랑 EC2에 적용하는 것도 너무 궁금하다

아직 오케스트레이션이 좀 감이 안오는데.. 직접 경험해보고싶다.