KOMAS

Data

Docker에서 볼륨을 지정할 때, -v 옵션 뒤에 경로가 아닌 단순한 문자열(예: myvolume)을 지정하면, 

Docker는 이를 네임드 볼륨(named volume)으로 간주합니다. 반면에 슬래시(/)를 포함한 경로 형태(예: /path/on/host:/path/in/container)를 지정하면 바인드 마운트(bind mount)로 간주합니다.

예를 들면:

네임드 볼륨:
docker run -v myvolume:/path/in/container my_image
위의 명령어는 myvolume이라는 네임드 볼륨을 컨테이너의 /path/in/container 위치에 마운트합니다.

바인드 마운트:
docker run -v /path/on/host:/path/in/container my_image
위의 명령어는 호스트의 /path/on/host 디렉토리를 컨테이너의 /path/in/container 위치에 마운트합니다.

결론적으로, 슬래시(/)가 없는 단순한 문자열을 지정하면 Docker는 이를 네임드 볼륨으로 인식합니다.

바인드 마운트

호스트의 특정 디렉토리를 컨테이너에 마운트합니다.
-v 왼쪽경로디렉토리(로컬):오른쪽 경로디렉토리(컨테이너)
이 명령어를 사용하여 호스트의 디렉토리를 컨테이너에 마운트합니다.
주의점으로 bind mount가 컨테이너 내부의 폴더에 우선시 되므로, 기존에 컨테이너 안에 있던 데이터가 덮어쓰일 수 있습니다.
로컬 디렉토리가 우선되며, 로컬을 변경하면 컨테이너에 즉시 반영

도커 파일 캐싱

Docker는 이미지를 빌드할 때 효율적으로 처리하기 위해 캐싱 메커니즘이 있습니다.

Dockerfile의 각 줄은 독립적인 레이어로 생성되며, 이전에 빌드했을 때 변경되지 않은 레이어는 캐싱되어 재사용됩니다.

이 Dockerfile을 처음 빌드할 때, 모든 단계가 실행되어 새 이미지가 생성됩니다. 

하지만 COPY 단계에서 소스 코드에 변경사항이 발생하면, 이후의 모든 단계는 캐시를 사용하지 않고 다시 실행됩니다.

캐싱 전략
변경 빈도가 높은 단계는 Dockerfile의 하단에 위치시키는 것이 좋습니다. 

그렇게 하면 변경 빈도가 낮은 단계는 최대한 캐싱을 활용할 수 있습니다.

예를 들어, 애플리케이션의 종속성을 설치하는 단계와 소스 코드를 복사하는 단계가 있다면, 

종속성 설치 단계를 먼저 위치시키고 소스 코드 복사 단계를 그 이후에 위치시키는 것이 좋습니다. 

그러면 종속성 변경이 없는 경우에는 캐싱을 효율적으로 활용할 수 있습니다.

도커 컴포즈의 목적

다중 컨테이너 관리: docker-compose는 여러 서비스로 구성된 애플리케이션을

각 서비스의 이미지, 환경 변수, 포트, 볼륨 등을 설정

의존성 관리: 서비스 간의 의존 관계를 정의

예를 들어, 백엔드 서비스가 데이터베이스 서비스를 필요로 할 경우,

docker-compose를 사용하여 백엔드가 데이터베이스가 준비된 후에 시작

일관된 환경: 개발, 테스팅, 스테이징, 프로덕션 등 다양한 환경에서

동일한 docker-compose.yml 파일을 사용하여 애플리케이션을 실행

한 번의 명령으로 서비스 관리: 

docker-compose up 명령을 사용하여 모든 서비스를 시작하거나 

docker-compose down 명령을 사용하여 모든 서비스를 종료

이미지 다운로드: docker-compose를 사용하면 docker-compose.yml에 정의된 모든 이미지를 

한 번의 명령으로 다운로드 (docker-compose pull). 

배포 순서: ci.yml build -> docker-compose.yml -> cd.yml deploy

[ local 작업 ]
1. jar 파일 만들기
2. dockerfile 작성
3. docker 이미지 만들기
4. docker push

[ server 작업 ]
5. docker pull
6. docker run

1. jar 파일 만들기

Gradle bootJar로 jar 파일을 만든다.

build/libs 경로에 jar파일이 생성된다.

2. dockerfile 수정

FROM adoptopenjdk/openjdk11:alpine-slim

WORKDIR /chat

COPY build/libs/map-chat-v1.jar .

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "map-chat-v1.jar"]

도커 파일을 작성하여 이미지를 생성할 준비를 한다.

컨테이너 구동시 jar파일이 실행되도록 했다.

3. docker 이미지 만들기

docker build

-t 저장소명:태그

.

경로를 못찾는다고 할 경우

docker build

-f dockerfile경로

-t 저장소명/이미지명:태그

4. docker push

docker hub push가 간혹 안되는 경우가 있는데,

docker hub repository 이름과, push할 이미지 이름이 같아야 한다.

docker push 저장소명:태그

[ 여기서부터는 서버에서 작업 ]

5. docker pull

docker login -u 아이디

docker pull 저장소명:태그

6. docker run

docker run

-p 80:8080

저장소명:태그

도커

도커는 컨테이너때문에 쓰는 것이다.

컨테이너는 어느 환경에서건 같은 환경을 구축할 수 있다.

기존 가상머신 방식이 비효율적인 이유

하나의 운영체제에 여러 가상머신을 설치해서 각 가상머신마다 다른 버전, 다른 구성으로 software 구축할 수 있다.

하지만 각 가상 머신 마다 OS가 필요하므로 메모리, 드라이브 공간을 낭비한다.

컨테이너 방식이 효율적인 이유

하나의 운영체제에 하나의 docker engine을 설치하여 여러 컨테이너를 도커가 관리한다.

docker engine에서 동작하는 컨테이너들은 가상 머신보다 빠르고 효율적이다.

이미지로 만들어서 어떤 환경에서든 이미지가 같으면 같은 컨테이너가 생성된다.

공유, 재구축, 배포가 쉬워진다.

설치

window10 pro 이상이면 docker desktop (window10에서 제공하는 가상 머신 사용)

linux는 도커 엔진 설치가 간단하다.

이미지와 컨테이너

이미지 -> 클래스

docker hub에 이미 만들어진 이미지 사용하거나 커스텀, 그 위에 레이어를 쌓는 방식

이미지는 빌드되면 닫힌다. ReadOnly . 

변경사항을 적용하려면 이미지를 다시 빌드해줘야 한다.

컨테이너 -> 인스턴스

컨테이너는 하나의 머신으로 생각, shell로 안에서 작업을 진행할 수 있다. 

하나의 이미지로 여러개의 컨테이너 인스턴스를 실행할 수 있다.

컨테이너끼리는 전혀 관계가 없다.

컨테이너마다 버전을 다르게 할 수 있다.

도커 이미지 만들기 [Dockerfile]

FROM   base 이미지 지정

ARG   이미지 빌드타임 KEY=VALUE로 사용할 수 있다.

ENV  PORT 80      환경 변수 설정, 사용시에는 $PORT, 런타임시에도 사용가능

WORKDIR   [컨테이너에서 작업폴더가 되는 곳    COPY, RUN 등은 이곳을 기준으로 동작]

COPY   [이미지에 들어갈 로컬 파일]  [WORKDIR이 기준] 

RUN   이미지를 빌드(생성)할 때 마다 실행할 명령어

컨테이너가 된 이후

EXPOSE $PORT         포트 80 노출, host와 포트 포워딩 필요

CMD 컨테이너가 실행될 때 동작할 명령어 [배열로 명령어 작성, shell이 있다면 string 가능]  

Dockfile 한줄 한줄이 layer다.

변경이 자주되는 layer를 아래에 두면, 윗 layer는 이전 레이어로 caching 된다.

변경 사항이 일어난 layer 밑은 전부 다시 빌드 작업을 진행한다.

역 슬래시를 이용해서 여러줄 작성이 가능.

데이터 volumes & bind mounts

데이터를 도커가 관리하고, 직접 접근은 할 필요가 없는 경우

✔ 익명 볼륨

컨테이너가 삭제되면 같이 제거된다.

하나의 컨테이너에서 데이터 사용

명령어: -v 볼륨경로 (볼륨명을 주지않는다. 컨테이너를 생성할 때 지정)

✔ 네임드 볼륨

컨테이너가 삭제되도 유지된다.

여러 컨테이너에서 데이터를 공유, 생성, 유지하고 싶을 때

명령어:-v 볼륨명:볼륨경로 (볼륨명을 준다. 컨테이너를 생성할 때 지정)

✔ bind mounts

host에서 직접 접근해서 사용할 필요가 있는 경우. 주로 편집을 위해 사용

도커와 host가 같이 사용하는 바인딩하여 관리하는 데이터

명령어: -v 왼쪽경로디렉토리(로컬):오른쪽 경로디렉토리(컨테이너)

bind mounts주의점

도커 컨테이너 내부 폴더보다, bind mount가 우선된다. (덮어씌운다)

컨테이너 내부가 bind mounts된 로컬 폴더로 뒤집어 씌어지면서 이미지 빌드할 때 설정한 종속성이 없어졌다.

덮어씌워지기 전에 이때 필요한 종속성 이미지 파일들을 익명 볼륨에 넣어 유지시켜줘야 한다.

도커파일에 설치명령은 먼저 동작하여 익명 볼륨에 관리시키고 (충돌이 발생하면 도커가 경로가 긴 볼륨을 먼저 보고 적용한다.)

로컬파일을 덮어씌우는 방식

컨테이너에서 유지되어야 하는 것

DB 데이터

서버 log 등...

네트워킹

✔ 컨테이너 app <ㅡ> host DB 연동

호스트 database와 컨테이너 app이 통신할 수 있다.

host.docker.internal

✔ 수동 컨테이너 app <ㅡ> 컨테이너 DB 연동

컨테이너 app에서 DB를 연동

database 컨테이너를 띄우고

docker container inspect로 [ip:port]를 확인한다.

✔ 더 개선된 컨테이너 app <ㅡ> 컨테이너 DB 연동

컨테이너들을 하나에서 네트워크로 사용하면 된다. 도커에서는 이러한 네트워크를 제공한다.

docker network create [네트워크명]

컨테이너를 생성할 때 --network [네트워크명]

컨테이너 app에서 DB를 연동하는 코드에 [ip]대신 [컨테이너DB명]:port 를 입력

도커 네트워크가 같다면 컨테이너 명으로 접근할 수 있다.

내부에서 사용되는 컨테이너 DB는 컨테이너 생성 명령어에서 -p 작업을 해주지 않아도 된다. 

외부에서 요청을 받게되는 컨테이너 app은 포트번호를 노출시켜줘야 한다.

docker compose

자체 네트워크로 여러 컨테이너를 동시에 띄우고 --rm default로 제거한다.

자체 네트워크를 사용하므로 네트워크를 지정해주지 않아도 된다.

이미지를 빌드하고, 컨테이너를 실행하는 과정을 한번에 과정으로 실행

docker-compose up

docker-compose down

docker-compose run [services 등록명]

일부만 컨테이너로 실행할 경우

docker-compose.yml

version: '3.4'

services:
  webmvc:
    image: eshop/webmvc
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
      - BasketUrl=http://basket-api
    ports:
      - "5100:80"
    depends_on:
      - catalog-api
      - ordering-api
      - basket-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=Services.OrderingDb;User Id=sa;Password=[PLACEHOLDER]
    ports:
      - "5102:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  basket-api:
    image: eshop/basket-api
    environment:
      - ConnectionString=sqldata
    ports:
      - "5103:80"
    depends_on:
      - sqldata

  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5434:1433"

  basketdata:
    image: redis

Dockerfile을 만들어서 참조해서 사용해도 되고, docker-compose에 모든 내용을 작성해도 된다.

Docker util container

로컬에 환경설정을 하기 위해 사용되는 이미지와 컨테이너

도커 이미지를 기반으로 컨테이너화를 할 때,

이미지마다 해당되는 명령어를 사용하여, 추가적인 환경 설정과 툴을 설치해줄 수 있다.

바인드 마운트를 같이 진행하면 로컬에 환경 설정이 된다.

주의점

docker run ... [명령어] 를 실행하면

Dockerfile의 [CMD 명령어]를 덮어씌운다.

이를 방지하고자 [ENTRYPOINT 명령어]를 사용하면 ENTRYPOINT 명령어 뒤에 이어서 진행한다.

Docker 배포 시

도커를 이용해 배포할 때는 바인드 마운트 사용을 권장하지 않는다.

도커 컨테이너의 기본 아이디어는 컨테이너의 캡슐화이고,

바운드 마운트는 개발할 때의 편의성으로 사용한다.

AWS ECS를 이용하면 컨테이너가 동일 머신에서 동작할 것이 보장되지 않기 때문에,

도커 네트워크를 사용할 수 없다.

환경 변수 설정으로 ip를 지정하게 하자.

명령어

docker ps -a 모두 보기

이미지 명령어

docker build

-t repository명칭:tag명칭

-f 경로 

도커파일위치 보통 .

컨테이너 명령어

docker run   새로운 컨테이너 실행  

docker run -i   stdin 열린 상태로 사용

docker run -t   터미널을 생성

docker start    컨테이너를 재실행  

docker stop     컨테이너 중지

docker rm        컨테이너를 완전히 제거

--name      컨테이너 이름 지정

docker run -p 80:80 이미지명      포트연결

attach & detach

실행중인 컨테이너는 attach, detach 할 수 있다.

attach 모드면 실행중인 container log를 계속 수신

detach모드:   -d 추가

attach모드:   -a 추가

다시연결:   docker attach 컨테이너명

attach 컨테이너 종료시키지 않고 나오기:   ctrl + p + q

로그보기: docker [-f] logs 컨테이너명

interactive terminal

간단한 프로그램 실행

-it

shell로 접근

docker exec -it 컨테이너 bin/bash