개발 다이어리

 다중 컨테이너를 연결하여 서로 상호 작용할 수 있는 방법

도커화된 컨테이너가 통신하는 케이스 몇가지

• HTTP를 이용한 통신
• 컨테이너에서 로컬 호스트 머신으로 통신
• 컨테이너가 또 다른 컨테이너로 통신

도커 HTTP 웹 통신

도커화된 애플리케이션은 별도 설정 없이 웹 API 및 웹 페이지와 통신 할 수 있다.

도커 컨테이너에서 호스트 머신으로 통신법

host.docker.internal 특수 도메인 사용

도커가 이해할 수 있는 특수 도메인으로 도커 컨테이너 내부의 호스트 머신 IP주소로 변환된다.

컨테이너에서 다른 컨테이너 통신

위 명령어 결과에 IP정보가 있다.

매번 이렇게 생성된 IP를 확인하며 사용하는 것은 불편하다.

컨테이너 간 좀 더 쉬운 통신방법

docker run 에 --network 옵션 사용

 볼륨과 다르게 도커가 자동으로 생성해주지 않기에 직접 network 를 만들어줘야 한다.

같은 네트워크로 묶는다.

IP하드 코딩 없이 성공

컨테이너는 도커의 핵심이며 데이터를 읽고 쓸 수 있다.

컨테이너는 빌드된 이미지 위에 얇은 read-write 레이어를 추가한다. 하지만 이 레이어는 컨테이너가 제거 될 시 같이 소거된다.

하지만 거의 모든 애플리케이션은 유지되어야할 데이터가 있다. 그렇기 때문에 볼륨을 추가해 사용한다.

데이터가 유지된다는 것은 결국 호스트 머신 어딘가에 존재한다는 뜻이다. 

볼륨은 도커에 의해 관리되며, 컨테이너에 마운트된다.

이렇게 생성된 볼륨은 컨테이너 속 데이터와 매핑되어 있기 때문에 컨테이너가 내부에 저장한 데이터가 고스란히 볼륨에도 남아 컨테이너 제거 후에도 유지된다.

볼륨은 두 가지가 존재한다. 명명된 볼륨은 컨테이너가 제거되도 유지되기에 영구 데이터에 적합하다.

익명 볼륨은 컨테이너가 제거되면 같이 제거된다. 따라서 임시 데이터를 저장하기에 적합하다.

바인딩 마운트는 명명된 볼륨과 비슷하지만 데이터가 미러링되는 호스트 머신의 경로를 알고 있고 실제로 그 경로를 사용하여 데이터를 컨테이너에 전달하여 호스트 머신에서 그 데이터를 변경할 수 있어 컨테이너에서 항상 최신 데이터를 사용할 수 있다

볼륨은 'docker run' 명령에서 '-v' 옵션으로 생성하며, 볼륨이 존재하지 않을 땐 새로 생성을 존재하면 생성되어 있는 볼륨을 사용한다.

빌드 인수와 런타임 환경 변수를 사용하면, 이미지를 빌드하거나 컨테이너를 실행할 때 외부에서 특정 데이터를 전달할 수 있습니다. Dockerfile이나 소스 코드에서 모든 것을 하드 코딩할 필요없이 대신 컨테이너를 실행할 때 값을 지정할 수 있다.

바인드 마운트 덮어씌우기 문제 해결

도커 컨테이너에 익명 볼륨을 추가해 외부에서 덮어쓰면 안될 폴더를 지정

덮어씌워지지 않는 이유, 도커는 항상 컨테이너에 설정하는 모든 볼륨을 평가하며, 충돌이 있는 경우에는 더 긴 '내부' 경로를 우선하기 때문이다.

/app 보다 /app/node_modules 가 더 구체적이므로 덮어씌워지지 않는다.

추가로 아래 설정을 하면, 런타임 환경에서 코드가 바로 반영되니 개발 시 리빌드하여 재구동할 필요가 없다.

단, 개발중에만 실시간 코드 확인을 위해 바인드 마운트를 사용하지 실제 운영에선 바인드 마운트를 사용하지 않을 것이다.

소스가 업데이트 될 일도 없고 보안 문제도 있다.

dockerignore

COPY 명령으로 복사하면 안될 것들 정의

로컬에 nodeJS 서버를 사용한다면 아래를 추가하는 것이 좋다.

만약 로컬에서  npm install로 생성된 모듈이있으면, 컨테이너 구동 시 생성된 node_modules이 덮어씌워짐

환경변수

--env, -e

docker run 시 사용할 환경변수 등록 방법

$는 환경변수임을 알리는 기호

여러 개도 가능 약어로 -e PORT=123 가능

대문자는 관례로 가급적 지키는 것이 좋다.

--env-file 은 환경변수 파일을 지정

환경변수는 직접 읽을 이름을 Dockerfile에 지정하면되기에 관례에 따른 이름을 짓는다.

./은 현재 위치

환경 변수 & 보안

환경 변수에 저장하는 데이터의 종류에 따라, 보안 데이터를 Dockerfile에 직접 포함하지 않을 때 유용하다.

환경 변수나 환경 변수 파일은 런타임 시에 적용되기 때문이다.

빌드 인수(ARG)

--build-arg

이 인수는 Dockerfile에서만 사용할 수 있다. 단, Dockerfile에서도 모든 명령에 사용할 수 있는 건 아니다

예를 들어, CMD에서 사용할 수 없다.

ARG는 컨테이너가 시작될 때 실행되는 런타임 명령이기 때문이다.

다른 모든 명령에선 'ARG'를 사용할 수 있다

바인드 마운트

바인드 마운트는 볼륨과 비슷한 점이 몇 가지 있지만, 한 가지 중요한 차이점이 있다.

도커에 의해 관리되는 볼륨의 위치 즉, 호스트 머신의 파일 시스템 상의 볼륨이 어디에 있는지 우리는 실제로 알지 못한다.

하지만 바인드 마운트의 경우, 그 위치를 알 수 있다. 

바인드 마운트의 경우, 우리는 개발자로서 호스트 머신 상에 매핑될 컨테이너의 경로를 설정하기 때문

바인드 마운트는 영구적이고 편집 가능한 데이터에 적합하다.

일반적인 볼륨과의 차이점, 명명된 볼륨은 영구 데이터에 도움이 되지만, 편집은 실제로 불가능하다.

호스트 머신의 어디에 저장되어 있는지 모르기 때문이다.

바인드 마운트 설정

바인드 마운트 설정은 컨테이너를 실행할 때 한다.

실행하는 컨테이너에만 적용되기 때문이다.

여기 예시는 폴더를 바인드 마운트한다. 알아둘 것은 단 건인 파일도 바인트 마운트할 수있다.

경로를 따옴표로 묶은 이유는 경로상에 존재할 수 있는 특수문자 같은 것들이 정확히 인식하게 하기 위함이다.

위 명령어 기준, 컨테이너 내부의 'app' 폴더에 명명된 볼륨으로 마운트된다.

위 Dockerfile으로 빌드된 이미지로 컨테이너 생성 시 컨테이너가 생성이 안된다. 

이유를 살피기 위해 --rm을 제거 후 오류를 확인(docker logs)

모듈을 찾을 수 없다고 나온다. 이는 Dockerfile 속 RUN npm install 실행이 정상적으로 안됐음을 의미한다.

좌측 폴더, 그 폴더에 있는 모든 것을 /app  폴더에 바인딩하고 있다.

 docker run -d -p 3000:80 --name app3 -v namedvol:/app/feedback -v "C:\vscode\docker\section03\01:/app" app3:volume 

위 도커파일 상 

처음에 이미지가 생성될 때, 모든 것을 app 폴더에 복사한다.

그런데, 이미지 생성을 위해 수행한 이 모든 단계가 무의미하게 된다.

바인드 마운트를 컨테이너에 바인딩하면 어쨌든 'app' 폴더의 모든 것을 로컬 폴더로 덮어쓰기 때문이다.

-v "C:\vscode\docker\section03\01:/app" //문제 부분

현재 이 로컬 폴더에는 이 앱에 필요한 모든 종속성이 있는 'node_modules' 폴더가 없다.

server.js 파일은 'Express' 패키지, 'Express' 종속성을 필요로 하며  그것은 컨테이너에만 존재한다. 

로컬 폴더에서 'npm install'을 실행하지 않았기 때문이다.

그리고 로컬 폴더를 'app' 폴더에 마운트하기 때문에 이미지와 컨테이너를 설정할 때, 여기에서 수행한 모든 작업을 덮어쓴다. 이게 문제가 된 것

데이터 종류

• 어플리케이션 데이터
  
  • 코드나 라이브러리로 이미지에 읽기 전용으로 존재
• 임시 데이터
  • 읽기,쓰기 가능하며 컨테이너가 구동하는 기간만 존재, 재시작 시 사라짐
• 영구 데이터
  • 읽기,쓰기 가능하며, 컨테이너나 볼륨에 존재, 재시작 시 존재해야 함

볼륨(VOLUME)

도커가 컨테이너 내부의 데이터를 호스트 서버 어딘가에 "미러링"해 저장하는 것

도커만이 관리하고 사용자는 찾기도 어려우며, 접근해 수정을 가해선 안됨(접근 못하도록 설계함)

볼륨 두 가지 

익명 볼륨

컨테이너 내부 경로만 지정
호스트 서버 경로를 지정하지 않아 도커가 임의로 매핑함
사용자는 위치를 모름
심지어 접근조차 할 수 없도록 설계됨

확인 명령어
docker volume ls

컨테이너 종료 시 익명볼륨도 같이 사라짐
즉, "익명 볼륨 데이터"는 수명주기를 컨테이너와 함께함
휘발성, 일회성
하나의 익명 볼륨은 하나의 컨테이너에 강하게 연결되어 있음

명명된 볼륨 (named)

익명 볼륨과 같지만 이름을 부여한다.
큰 차이는 컨테이너 제거 시 호스트 저장소에 데이터는 안지워진다.
다만 접근하면 안되도록 설계한 것은 동일하기에 편집하지 않지만 삭제되면 안되는 데이터가 오기 좋다.
컨테이너가 종료되도 호스트 서버에 있는 볼륨은 삭제되지 않음
이 볼륨은 하나의 컨테이너에만 연결되지 않음
즉, 볼륨 이름을 컨테이너 실행 시 똑같이 입력하면 여러 컨테이너가 연결될 수 있음

컨테이너를 종료해도 볼륨이 살아있는 것을 알 수 있다.

볼륨 삭제

명명된 볼륨은 컨테이너를 종료해도 남아있기에 제거 방법을 알아둬야 한다.

docker rm 볼륨이름   // 단건 제거

docker volume prune // 컨테이너 참조가 하나도 없는 모든 볼륨 제거

모든 명령어 공통 사항으로 제거 시 prune 가 들어가면, 참조되지 않고 단순히 존재만 할 시 제거 대상이 된다.

컨테이너와 이미지 동작

실행 중인 컨테이너는 실제로 그렇게 크지 않다.

이유는 이미지 위에 작은 부가 레이어인 컨테이너 레이어를 쌓아 구동하기 때문이다.

하나의 이미지로 컨테이너를 10개를 구동한다고 가정하면, 이미지는 모든 컨테이너가 공유하고 그 위에 읽기쓰기가 가능한 얇은 컨테이너 레이어만 10개가 얹힌 10개 컨테이너가 구동되는 것이다.

로컬 호스트 머신과 실행 중인 컨테이너 간 데이터 통신 방법

주의할 것은 실행 중인 컨테이너로 데이터를 복사할 수 있다고 해서 코드 변경이나 추가를 반영하는 것은 그리 좋은 생각은 아니다.

보통은 컨테이너 속 로그파일을 호스트 머신으로 가져올 때 쓰게 된다.

로컬 프로젝트에 폴더와 파일을 만듦

컨테이너를 구동하고 컨테이너 속으로 파일을 복사한다

이때, 도커는 당연히 컨테이너 이름을 알아야 특정지을 수 있다.

그렇다면 파일이 제대로 복사되었는지 확인을 해보자

파일을 삭제한다.

파일이 정상적으로 복사됐기에 다시 역으로 복사도 됐다.

이름과 태그

이미지 빌드 시 -t 옵션으로 이름을 부여할 수 있다.

이름은  "이름 : 태그 " 로 구성되어 있다.

"이름"은 범용적인 단어를 사용할 것이기에 중복되는 경우가 많을 것이다.

"태그"는 이름이라는 큰 범주에서 하나의 이미지를 특정하기 위해 주로 사용된다.

도커허브에서 node 살펴보기

이미지 공유 방법

이미지를 공유하는 방법에는 두가지가 있다.

• 하나는 Dockerfile과 그에 맞는 소스코드를 받는 방법
• 다른 하나는 이전과 같이 빌드되서 완성된 이미지를 받는 방법이다.

첫 번째 방법으로 도커 노드를 깃허브에서 소스코드를 받아 Dockerfile로 이미지 빌드해보기

코드를 받았다면, 받은 파일 속에 Dockerfile 파일이 존재한다. 

Dockerfile방식 이미지 공유 방식은 이미지에 들어가야 하는 모든 주변 코드와 폴더 구조도 필요로 한다.

반면에 이미지 공유 방식은 이미지를 다운로드하기만 하면, 즉시 컨테이너를 실행할 수 있다.

빌드할 필요가 없고, 추가 코드나 주변 폴더도 필요하지 않다. 이미 모든 것이 이미지에 포함되어 있기 때문이다. 

이러한 이점으로 주로 완성된 이미지를 공유하는 것이 일반적이다.

DockerHub에 이미지 푸시하기

완성된 이미지를 공유하는 대표적인 방법

도커에서 이미지 공유는 도커의 핵심 기능이다. 도커를 사용하는 이유는 종속성 설치나 별도의 환경설정 없이 컨테이너를 실행할 수 있는 것이다. 거기에 필수적인 것이 이미지 공유이다.

이미지 공유는 중요하기 때문에 도커는 이미지 공유를 위해 내장된 명령어가 있다.

도커 허브에 이미지 공유하는 방식은 두 가지가 있다.

공유 저장소, 개인 저장소 개인 저장소는 무료 사용자 기준 1개만 제공한다.

도커 허브에 접속해 가입 후 저장소 생성하기

도커 허브에 푸시하는 방법은 간단하다. 푸시하고자하는 로컬 이미지 이름을 위와 같이 맞춰주면 된다.

만약 이미 완성된 이미지를 푸시하고 싶다면 아래와 같은 방법으로 이름을 변경해주면 된다.

여기서 주의깊에 볼 것은 기존 이미지를 복제본을 생성한다는 것이다.

정상적으로 올라간 것을 볼 수 있다.

만약 아래와 같이 업로드가 거부됐다면, 도커허브에 로그인을 안한 것이다.

저장소에 푸시할 수 있는 자는 저장소 주인만 푸시가 된다.

로그인을 했다면 정상적으로 푸시할 수 있다.

이전에 이미 푸시를 헀다면 변경된 부분만 푸시를 한다.

따라서 위 처럼 변경되지 않은 레이어는 푸시가 안된 것을 볼 수 있다.

도커 허브에서 가져오기

공개 저장소로 올렸으니 로그아웃을 해야 완전히 정상적으로 받아지는 지 테스트 할 수 있다.

PULL로 가져온 이미지는 도커허브에 올라간 이미지 중 항상 최신 버전을 가져온다.

사실 pull을 하지 않아도 컨테이너를 구동 시킬 수 있다.

이유는 도커는 로컬에서 찾지 못하면 도커 허브에서 찾기 때문이다.

바꿔말하면, 로컬에 존재하면 도커허브에 올라간 최신의 이미지를 확인하지 않고 실행한다는 말도 된다.

따라서, PULL 후 RUN을 하는 것이 옳다.

이미지와 컨테이너 관계

이미지는 모든 설정 명령과 모든 코드가 포함된 공유 가능한 패키지이다.

즉, 이미지는 한 번 생성되면 내부 코드를 수정할 수가 없다. 

이미지는 컨테이너를 실행하기 위한 설계도와 같다. 컨테이너는 이미지를 기반으로 실행된다.

이미지 가져오기

이미지를 가져오는 대표적인 방법은 도커 허브 사이트를 이용하는 것이다.

https://hub.docker.com/

도커는 도커허브에 연결하는 기능을 내장하고 있어, 만약 로컬에서 해당하는 이름에 이미지가 없다면 추가로 도커 허브를 탐색한다.

위의 경우 도커 허브에서 공식 노드 이미지를 받아 실행하게 된다.

도커 허브에서 이미지를 받을 때 가장 최신 버전을 받게 된다.

커스텀 이미지 만들기

이미지 생성의 핵심은 Dockerfile 이다.

Dockerfile 은 도커에 의해 식별되는 특별한 이름이다.

Dockerfile을 작성했다면, 빌드하는 명령어는 아래와 같다.

docker build .

빌드 과정을 보면 도커파일에 명시한 순서대로 빌드하는 것을 알 수 있다.

도커는 레이어 기반으로 쌓아가면서 이미지 파일을 생성한다.

마지막 해시값은 이미지를 생성할 때 이름을 부여하지 않았을 시 이름 역할을 하게 된다.

이미지 기반으로 컨테이너 생성하기

생성된 이미지는 docker run 명령어로 컨테이너를 생성과 구동을 할 수 있다.

컨테이너를 구동할 때 컨테이너 내부에서 사용할 포트와 실제 호스트 머신에서 접근할 포트 정보를 매핑해줘야한다.

-p 호스트포트:도커포트  

도커 포트는 컨테이너 내부에서 외부로 노출할 포트번호다. 도커를 구동하는 호스트 머신에서 이를 변경해서 매핑할 수 있다.

코드를 변경한 후 컨테이너를 재기동

변경된 코드가 반영이 안된 것을 볼 수 있다. 이는 이미지는 빌드될 당시 상태를 스냅샷한 것과 같고, 한 번 빌드된 이미지는 읽기전용이다.  자바로 따지면 final 특성을 가진것이다. 따라서 수정을 할 수 없다. 

코드를 변경한 상태로 이미지를 다시 빌드를 해야 적용된다.

레이어 기반

이미지는 레이어 기반 구조로 이뤄진다.

이미지를 빌드하거나 이미지를 다시 빌드할 때 변경된 부분의 명령과 그 이후의 모든 명령이 재평가된다.

이미 빌드된 이미지를 다시 빌드할 때 CAHED로 빠르게 빌드가 수행된 것을 알 수 있다.

변경을 가한 WORKDIR 부터 이후 전부 재평가된 것을 볼 수 있다.

이러한 구조를 레이어 기반 아키텍처라 한다.

이 명령어 하나 하나가 레이어 처럼 쌓인다. 그렇기에 이전 명령어가 변경되면 이후 명령어는 전부 재평가되는 것이다.

다른 말로 이전 레이어의 변경은 이후 모든 레이어에 영향을 미친다.

이 레이어 기반 구조를 이해하면 빌드 시 최적화 방안을 모색할 수 있다.

앞서 빌드할 때 RUN npm install 로 종속성 다운로드 시 오래걸렸다. 이를 방지하기 위해 종속성 관련 package.json 만 앞으로 먼저 COPY한다면,  다른 소스 코드는 수정을 해도 오래걸리는 npm install 이 재평가되어 실행되지 않아 빠르게 빌드할 수 있다.

이미지와 컨테이너를 구성하고 관리

기본적으로 모든 명령어에 --help로 도움을 받을 수 있다.

자주 사용하는 핵심 명령어

docker ps -a

   모든 컨테이너 목록

docker run

   이미지를 기반으로 새 컨테이너를 만들고 새 컨테이너 시작

docker start

   기존 컨테이너 시작

attached(연결) 모드, detached(분리) 모드

docker start 로 시작하는 경우, detached 모드가 디폴트

docker run으로 실행하는 경우, attached 모드가 디폴트

attached 모드에선 컨테이너에 연결된 상태를 유지하기 때문에 서버에서 발생시킨 로그를 볼 수 있다.

detached 모드에서 서버에서 발생한 로그를 보고 싶을 땐 docker logs 명령어를 사용하면 된다.

인터렉티브 모드

컨테이너와 통신하는 방법

attached 모드는 단순히 서버로부터 출력만 받는다.

docker run 사용 시 -it 로 상호작용 가능

이미지, 컨테이너 삭제하기

사용하지 않는 컨테이너나 이미지를 일괄 삭제할 수도 있다.

자주쓰는 옵션 -rm

컨테이너를 재시작하지 않는 경우가 많다.

이유는 컨테이너를 재시작하는 시나리오는 대부분 코드의 변경이며 코드 변경은 다시 빌드해야됨을 의미한다. 즉, 기존 컨테이너는 불필요해지는 경우가 많다.

컨테이너를 매번 새로 만들어 실행하기 위한 편리한 옵션(자동제거)

도커는 컨테이너를 생성하고 관리하기 위한 도구이다.

컨테이너란?

소프트웨어 개발에서 컨테이너는 표준화된 소프트웨어 유닛이다.

컨테이너는 코드 패키지이며 해당 코드를 실행하는데 필요한 종속성과 도구가 포함되어있다

따라서 환경설정이나 의존성 같은 것을 신경 쓰지 않고 항상 표준화된 동작 결과를 보장한다.

도커는 이런 컨테이너를 구축하기 위한 도구일 뿐이다.

현재 최신 OS는 컨테이너 지원이 내장되어 있어 과거보다 도커를 설치해 실행하기 쉬워졌다.

독립적이고 표준화된 소프트웨어 유닛의 필요성

• 여러 개발자간 개발 환경을 PC마다 맞추기 얼마나 번거로운지 생각해보기
  • 종속성, 서버 설정, DB연결 등등...
• 로컬 환경, 개발 환경, 운영 환경 각기 다른 조건에서 동일한 하게 동작하기까지 환경 구축이 얼마나 힘든지 생각해보기

이처럼 독립적이고 표준화된 소프트웨어는 대단히 중요한 가치가 있음을 알 수 있다.

가상 머신과 도커의 차이는?

• 컨테이너는 코드와 종속성을 함께 패키징하는 앱 계층의 추상화 모듈이다.
• 도커 엔진 하나에 여러 컨테이너가 동일한 시스템에서 실행될 수 있으며 각각 사용자 공간에서 격리된 프로세스로 실행되는 다른 컨테이너와 OS 커널을 공유할 수 있다.
• 컨테이너는 VM보다 더 적은 리소스를 차지한다.(저장 공간, CPU 자원 등)

가상머신은 운영체제 위에 또 다른 운영체제를 설치하기 때문에 운영체제가 기본적으로 가진 애플리케이션, 필수 바이너리 및 라이브러리 등이 중복되어 리소스를 소비한다. 

컴퓨터 전체를 캡슐화 한 것과 같아 도커보다 무겁고 느리다.

windows10 home제외한 모든 버전

Hyper-V 를 사용하도록 설정한다. 

PowerShell을 관리자 권한으로 실행한다.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

두 명령어를 순차적으로 입력하고, 윈도우를 다시시작한다.( 다시시작하라고 안내가 나온다)

다시시작 이후 Hyper-V가 활성화된 것을 확인한다.

windows10 home

홈 뿐만아니라 모두 하는 것을 추천합니다.

저 같은 경우 이전 작업만 했는데 도커는 설치가 되지만 도커 실행은 알람이 뜨면서 실행이 안됩니다.

알람 내용은 WSL2가 필요하다는 것입니다.

PowerShell 관리자 권한 실행 후 아래 두 명령어 입력

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

//아래 명령어는 버전 변경이니 다 설치하고 입력
wsl --set-default-version 2

설치 이후 반드시 WSL2 Linux 커널 최신 업데이트를 진행한다. 

여기서부터는 진짜 home만 설치하면 됩니다.

리눅스 설치

우분투를 설치하는 것을 추천... 그리고 가급적 버전정보 뒤에 LTS 붙은 것을 추천

도커 설치

다운로드 후 설치한다. 이 과정에서 한 번 다시시작이 필요하다.

설치할 때 체크박스는 무조건 체크한다. (바탕화면 바로가기는 제외해도 되나 그냥 무조건 다 체크하고 나중에 필요없으면 지우면 된다)

설치 후 실행

커맨드 창에 docker를 쳐 아래와 같이 뜬다면 완료