🐳 Docker study 4th

앞선 <Docker study 3rd>포스팅에서는 Kaggle Image를 이용해 컨테이너 즉, 가상환경에서 Python을 사용할 수 있는 환경을 구축했다. 이번 4주차에는 대표적인 데이터 분석 환경인 R을 Kaggle Image를 이용해 빌드해보는 실습을 진행했다. ‘Dockerfile’에 대해서 조금 더 깊게 다뤘는데 분명 지난 3주차에 다룬 내용임에도 불구하고 응용 쪽으로 들어오니 뭔가 다시 머리가 새하얘지는 기분이었다. (전생에 금붕어였나보다.🤦‍♀️) 아마 새로운 개념의 연속이다 보니 조금 이해가 느린 것 같은 데, 문제를 해결해야 한다는 의지는 들어 다행인 듯 싶다.

혹시 이번 포스팅에 들어가기 앞서 ‘Dockerfile’이 무엇인지 딱 한번에 한줄로 정리 되지 않았다면 이전 포스팅 중 📂 Dockerfile? 이 부분을 후딱 읽고 오는 걸 추천한다! 🏁

1. Setting up a R analysis environment

1.1 Installing a Kaggle GPU image for R

’Kaggle gpu R image’ 라고 검색하면 컨테이너에서 R을 사용할 수 있기 위한 이미지를 다운 받을 수 있는 링크가 나온다. 앞서 Kaggle의 Python 환경을 구축하기 위한 이미지 빌드와 유사한 방법으로 진행되기 때문에 이 부분은 쉽게 진행이 가능했다. 설치 시점(2024.10.14) 기준 R의 최신 버전은 v59이다.

나는 docker pull gcr.io/kaggle-gpu-images/rstats:v59 로 가상머신에 설치했다.

1.2 Running an R container in the RStudio Server IDE environment

지금까지 도커를 사용함에 있어 먼저 필요한 이미지를 다운받고 이를 해당 컨테이너, 즉 가상환경의 터미널에서 실행시키는 방법으로 진행했다. 이번에는 IDE 환경(Web)에서 컨테이너를 실행시켜보는 방법을 RStudio Server를 이용해 시도해보았다.

아래 사진은 실제로 R 컨테이너를 통해 IDE에 접근한 결과인데, 보면 웹에서 성공적으로 실행되고 있음을 확인할 수 있다.

이를 위한 방법은 이 명령어 한 줄 이면 가능하다. 조금 길긴 하지만 하나하나 읽어보면 또 완전히 못 할 것도 아닌 듯 싶다.

✅ Rstudio Web Browser connect code  docker run -d -p 8787:8787 --gpus all -v "/home/Arielle/rproject:/home/rstudio/rproject" --name rstudio-container gcr.io/kaggle-gpu-images/rstats:v59 /bin/bash -c "rstudio-server start && tail -f /dev/null"

docker run -d는 새로운 컨테이너를 지정된 이미지를 사용해 실행시키는 명령어이다. -d 옵션을 사용하면 “Detached mode”로 컨테이너가 백그라운드에서 실행되는데, 덕분에 터미널이 컨테이너에 묶이지 않고 다른 작업을 계속할 수 있다! 만약 해당 옵션을 사용하지 않으면 컨테이너가 실행되는 동안 터미널이 그 작업에만! 붙잡혀 있어 다른 명령어를 입력할 수가 없는 상황이 되기 때문에 주의가 필요하다!

-p 8787:8787 의 경우 포트 포워딩을 설정하는 옵션으로 컨테이너의 8787 포트(즉, RStudio Server가 실행되는 기본 포트)를 호스트 시스템의 동일한 8787 포트와 연결하는 역할을 한다. 이 설정 덕분에 웹 브라우저에서 ‘http://localhost:8787’을 입력하면 RStudio Server에 접근할 수 있게 되는 것이다.

그런데 이렇게 간단하게 문장으로 설명하기는 했지만, 사실 나는 포트에 대한 개념이 딱 정리되어 있지는 않은 상태에서 강의를 듣다보니 내가 제대로 이해한 게 맞는지 혼란스러웠다.(아마 내가 아는 포트는 1004, 22번 포트 정도??🤨)그래서 다시는 포트에 대해서 헷갈리지 않겠다는 다짐으로 이에 대해서 잠깐 정리하고 넘어가도록 하고자 한다!

🚪 Port?

일단 나는 Port가 정확히 모르지만 알게모르게 여기저기 사용하고 있긴 했다. 앞서 RDP 방식으로 MAC 가상환경을 구축할 때가 대표적이다. 아래 사진은 내가 이해한 Port의 개념을 정리한 그림이다.

클라이언트와 서버의 측면에서 이해하고자 한다면 좌측처럼 서버에게 사용하려고 하는 서비스 각각에게 부여된 특정 포트번호를 통해 클라이언트와 연결할 수 있다. 대표적으로 위에서 언급한 RDP 방식은 3389 포트를, SSH는 22번 포트를, 그리고 VNC는 5900번 포트를 이용해 연결한다.

그렇다면 도커 컨테이너 관점에서 이해해보면 어떨까? 이 관점에서는 기존의 클라이어트가 로컬 호스트(Local Host)로 서버는 컨테이너(Container) 개념으로 바꾸어 생각해볼 수 있다. 이 때 컨테이너는 마이크로 서비스(하나의 특정 프로그램)을 사용하기 위한 독립된 컴퓨터로 이해하면 된다. 그림에도 나와 있듯이 컨테이너는 ‘User Space’라는 하나의 Operating system 위에 실행하고자 하는 서비스(Image)로 구성되어 있다는 점도 꼭 기억하도록 하자!

포트 이야기 하다가 왜 컨테이너 구조에 대해서 이야기 하는지 의문이 들 수도 있다고 생각한다. 앞서 포트번호에 대해 이야기 할 때 각각의 서비스 별로 고유한 번호가 부여된다고 언급했다. 그럼 분명 지금 내가 다운 받은 RStudio 서비스 역시 분명 고유한 포트번호가 있을 것이다. 그게 바로 -p 8787:8787 이 명령어에 보이는 8787번 포트인 것이다! 그런데 보면 8787이 ‘:’를 기준으로 앞뒤 두번 쓰여 있는 걸 알 수 있는 데 앞의 8787은 로컬 호스트에 부여된 포트 번호이고, 뒤에 있는 8787은 컨테이너에 부여된 포트 번호이다. 기존 클라이언트 서버의 관점에서 서버 한쪽에만 부여 되었던 포트와는 달리 양쪽 다 포트 번호를 부여하고 있다.(차이점이다!!) 한가지 더 주목할만한 점은 로컬 호스트에 부여되는 포트 번호는 8787이 아닌 사용자 임의 지정이 가능하다는 점이다. 그럼 또 궁금한 게 생긴다. 언제 이 로컬 호스트의 번호를 임의로 지정할까? 그건 바로 동일한 머신에서 여러 개의 RStudio Server 컨테이너를 실행할 때이다. 이때는 각 컨테이너에 서로 다른 로컬 포트를 지정함으로써 유연성(Piability)을 제공할 수 있다.

하지만 그럼에도 불구하고 로컬 호스트와 컨테이너의 포트 번호를 동일하게 설정하는 이유는 편리성과 더불어 격리성(Isolation) 때문이다. 만약 컨테이너가 여러 개 있을 경우 포트 번호가 같다면 각각의 포트를 찾는 데 쉬워지게 된다. 이 개념의 연장선으로 Isolation에 대해 설명할 수 있는데, 컨테이너는 기본적으로 외부와 완전히 분리된 상태에서 동작한다. 이때 포트 페어를 지정해 로컬과 컨테이너 간 통신을 설정하게 되면 격리된 컨테이너가 외부에서 접근 가능한 상태로 되는 Docker의 진짜 힘을 발휘하게 되는 것이다!

다시 웹에서 컨테이너를 실행하는 명령어로 돌아와 이야기 해보도록 하자! 포트 지정까지 완료된 상태에서 뒤를 보면 -gpus all 이 있다. 이건 딱 적혀있듯이 실행하고자 하는 로컬의 GPU 자원을 컨테이너에서도 사용할 수 있게 설정하는 것으로 만약 로컬 호스트에 GPU가 탑재 되어 있다면 생략해도 무관하다.

v "/home/Arielle/rproject:/home/rstudio/rproject" 이 부분은 볼륨 마운트(Volume Mount)라는 개념으로 Docker에서 호스트 시스템의 파일이나 디렉토리를 컨테이너 내부와 연결하는 기능을 말한다. 지금 여기서는 로컬 호스트의 /home/Arielle/rproject 디렉토리와 컨테이너 내부의 /home/rstudio/rproject 디렉토리를 페어링함으로써 로컬에서 작성한 파일을 컨테이너 내부에서 사용할 수도 있고 반대로 컨테이너에서 생성한 파일도 로컬에서 바로 확인할 수 있다. 아래 사진처럼 실제로 로컬에서 mkdir testforlder 명령어 실행을 통해 좌측(Container with WEB)의 ‘testfolder’ 생성을 확인할 수 있다.

-name rstudio-container 이 옵션은 생성된 컨테이너의 이름을 지정해주는 부분으로 여기서는 rstudio-container 라는 이름을 지정하고 있는 것이고, 마지막 gcr.io/kaggle-gpu-images/rstats:v59 부분은 Docker 이미지(RStudio)의 경로와 버전을 나타내고 있다.

2. How to work Python package in R?

컨테이너를 통해 로컬 호스트에 잘 접속 했다면 아래처럼 R프로그램을 만나게 되는데, 사실 나는 R 프로그램을 다뤄 본 적이 없어서 저게 무슨 문법인가 했다. 일단 reticulate::py_config()는 R에서 Python 환경을 설정하고 그 환경의 정보를 출력하는 함수이다. 특이하게 R에서는reticulate 패키지를 통해 Python을 연동할 수 있는데 실행시켜 보니 “Would you like to create a default Python environment for the reticulate package? (Yes/no/cancel)” 문구가 콘솔에 뜨는 걸 확인할 수 있었다. 이 문구는 R과 연동할 Python 환경이 아직 없는 상태로 reticulate 패키지가 자동으로 새로운 Python 환경 설치를 물어보는 문구였다. 그래서 일단 YES! 로 Python을 설치해 주었다.

참고로 위에서는 RStudio IDE를 이용해 시각적으로 확인할 수 있었다면 이번에는 컨테이너의 터미널 방식으로 RStudio를 확인해 보았다.(어쨋든 GUI, 터미널 둘 다 배워두면 좋으니까요!) docker ps로 해당 컨테이너의 이름(rstudio-container)을 먼저 확인해 주었고, 이어서 docker exec -it rstudio-container R로 RStudio 경로를 직접 지정해주어 접속했다. 그러면 아래 사진처럼 정상적으로 컨테이너 내부의 터미널에서도 R이 잘 작동하는 것을 확인할 수 있었다.

✅  docker exec -it rstudio-container R 여기서 -it 는 -i (interactive), -t (tty)가 합쳐진 명령어로 컨테이너 내부에서 명령어를 실행할 수 있게 해주면서 동시에 터미널에서 입력한 명령어와 출력을 보기 위해 화면을 터미널처럼 만들어주는 기능을 한다! (참고로 해당 터미널에서 exit하고 싶으면 q() 로 나오면 된다!)

아까 RStudio(WEB)에서 Python을 설치해 주었다. 설치 여부를 물어보길래 얼래벌래 설치를 하기는 했는데 어디에 설치 되었는지 한번 쯤은 확인할 필요가 있을 것 같다. reticulate::py_config() 로 터미널에서 확인해보니 /root/.local/share/r-minicconda/env/r-reticulate/bin/python 경로에 위치해 있음을 확인했다. 그런데 지금 보면 r-miniconda 라는 폴더의 하위 경로에 python이 설치되어 있는 걸로 보이는데, 나는 해당 폴더를 생성한 적이 분명 없다.

이를 제대로 이해하기 위해서는 Docker 컨테이너 내부에서 RStudio와 Python 환경을 어떻게 연결하고 상호작용하는지 이해할 필요가 있다.

바로 위 그림으로 이해해보도록 하자! 파이썬 패키지를 이용해 Keras, Tensorflow가 R에서 어떻게 작동하는지 플로우를 그린 그림으로 총 5단계로 진행 된다.

1️⃣ R에서 딥러닝을 수행하려면 R Keras 패키지를 사용해야 한다. 하지만, R 자체에는 Keras나 TensorFlow가 내장되어 있지 않기 때문에 Python 패키지를 불러와 사용해야 한다.

2️⃣ 자 이제 Python 패키지가 필요함을 알았으니 R로 가져와야 하는데 특이하게 R에서는 reticulate 라는 패키지가 필요하다. 그래서 /root/.local/share/r-minicconda/env/r-reticulate/bin/python 이 경로처럼 r-reticulate 가 python의 상위 경로에 있었던 것이다!

3️⃣ 현재 Python 패키지의 경우 reticulate가 사용하는 Python 환경으로 들어오게 된다. 이게 무슨 말이라면 만약 reticulate가 miniconda라는 가상 환경을 사용하고 있다면, Python 패키지는 miniconda 환경 안에 설치되어 miniconda가 Python 패키지를 저장하고 관리하는 공간이 되는 것이다. 반면에 만약 reticulate가 다른 Python 환경을 사용 중이라면,그 환경에 Python 패키지가 설치된다는 뜻이다! 예를 들어 시스템에 미리 설치된 Python이 있다면 그 환경으로 Python 패키지가 설치될 수도 있다.

아무튼 포인트는 reticulate가 사용하는 Python 환경에 따라 Python 패키지가 설치되는 위치가 달라진다는 것이다!

4️⃣ 위의 단계가 정상적으로 진행되면 Python을 위해 keras, tensorflow를 사용할 수 있게 된다. keras는 RStudio에서 알고리즘을 생성할 수 있게 된다.(UI)

5️⃣ 이후 Tensorflow는 Keras의 백엔드로 작동하며 실질적인 연산을 하게 된다.

3. Custom Dockerfile

앞서 Docker study 3rd에서 Dockerfile에 대해서 알아봤었다. 그때는 붕어빵을 예로 들면서 Dockerfile을 붕어빵 틀을 만드는 레시피 정도로 설명 했었는데, 이번에는 조금 더 소프트웨어 관점에서 생각해보고자 한다.

📂 Dockerfile? (’👉🏻Docker study 3rd’)

#붕어빵 틀을 만드는 레시피

Dockerfile을 컨테이너에서 실행할 환경을 만드는 레시피로 생각해 봤다(붕어빵🐟🍞 다시 등장). 우리가 어떤 프로그램을 실행하려면 그 프로그램이 돌아가게 할 환경이 필요하다. 예를 들어 프로그램이 Python으로 짜여 있으면 Python을 설치해야 하는 것처럼, Dockerfile은 그런 것들을 자동으로 설정해주는 파일이라고 이해하면 된다.

A. 베이스 이미지 설정: 붕어빵을 만들 때 어떤 맛의 반죽을 쓸지 정하는 개념으로 Python이나 Ubuntu 같은 기본 이미지를 설정한다!

B. 필요한 프로그램 설치: 붕어빵 반죽에 필요한 재료를 넣는 것과 같다! 프로그램이 실행되기 위해 필요한 라이브러리나 패키지를 설치할 수 있다는 뜻으로 예를 들어, 붕어빵 반죽에 초콜릿 칩을 넣듯, 프로그램에 필요한 라이브러리를 추가한다!

C. 실행 명령어: 붕어빵이 완성된 후에 어떻게 구울지 정하는 것처럼 컨테이너가 켜졌을 때 어떤 프로그램을 실행할지 설정할 수 있다! 예를 들어 붕어빵을 굽는 온도와 시간을 정할 수 있는 것처럼 프로그램 역시 자동으로 실행될 명령어를 설정할 수 있다!

Dockrfile은 우리가 해당 프로그램을 돌아가게 할 수 있는 기본 환경을 만들어주는 파일로 베이스 이미지를 설정하고, 필요한 패키지도 설정하고, 실행 명령어도 직접 설정할 수 있다고 배웠다. 아래 사진은 위에서 우리가 컨테이너 이미지로 사용한 Kaggle R 이미지의 Dockerfile이다. RUN, ADD, ENV, ARG, LABEL, CMD 같은 명령어들로 파일이 구성되어 있는 걸 확인할 수 있는데 이들의 기능을 하나씩 정리해보도록 하자!

💻 Related Commands

✅ ADD : 로컬 호스트 내 파일이나 폴더를 Docker 이미지로 복사

• 로컬 파일을 컨테이너로 복사하거나 URL에서 파일을 가져올 수도 있고 만약 해당 파일이 압축파일일 경우 자동으로 풀리기도 함
• ADD kaggle/ /kaggle/
  • 로컬 호스트의 kaggle/ 폴더를 컨테이너의 /kaggle/ 폴더로 복사

✅ RUN : 이미지를 빌드할 때 실행할 명령어를 지정

• 주로 프로그램을 설치하거나 스크립트를 실행할 때 사용되고, 이 명령어를 쓸 때마다 새로운 레이어가 만들어짐!
• 🤔 ’새로운 레이어가 만들어진다’는 뜻은 도커의 이미지 관리 측면에서 이해해야 하는데, Docker 이미지는 여러 개의 읽기 전용 레이어로 이루어져 있어 각 레이어는 이전 레이어의 변경 사항을 기억한다. 예를 들어 하나의 이미지를 빌드할 때 우분투 운영체제 → 패키지 설치 → 파일 복사 단계를 거치게 되는데 이 한 스텝을 이 레이어(layer)가 관리한다는 의미다! 효율성, 캐싱을 고려했을 때 매우 합리적인 방법임이 분명한데 새로운 RUN 명령을 실행할 때마다 새로운 레이어가 생성되기 때문에, 불필요한 RUN 명령어를 많이 사용하면 이미지가 불필요하게 커질 수 있다. 따라서 여러 명령을 한 RUN 명령어에 묶어서 실행하는 것을 추천함!👍
• RUN R -e "keras::install_keras(tensorflow = \"${TENSORFLOW_VERSION}\", extra_packages = c(\"pandas\"))"
  • R을 실행해서 keras, tensorflow, pandas 같은 패키지를 설치함

✅ ENV : 컨테이너 안에서 사용할 환경 변수를 설정(docker run)

• 이 명령으로 설정된 환경 변수는 Docker 이미지 빌드 후 컨테이너 실행 시에도 유지가 가능함
• ENV R_HOME=/usr/local/lib/R
  • R_HOME이라는 환경 변수를 /usr/local/lib/R로 설정

✅ ARG : 이미지 빌드(docker build) 시에 사용할 변수 정의

• ARG로 정의된 변수는 빌드 타임(이미지를 만들 때)까지만 사용되고 실행될 때는 사용할 수 없음
• ARG GIT_COMMIT=unknown ARG BUILD_DATE_RSTATS=unknown
  • GIT_COMMIT과 BUILD_DATE_RSTATS라는 이름을 가지고 있고, 기본값은 ‘unknown’

✅ LABEL : 이미지에 메타데이터(이미지를 설명하는 정보)를 추가함

• 이미지를 만든 날짜나 커밋 정보 등을 넣어서 버전 관리에 도움이 돼요. key-value 형식으로 데이터 저장
• LABEL git-commit=$GIT_COMMIT LABEL build-date=$BUILD_DATE_RSTATS
  • git-commit과 build-date라는 이름으로 GIT_COMMIT과 BUILD_DATE_RSTATS 값을 라벨로 지정함

✅ CMD : 컨테이너가 시작될 때 기본적으로 실행할 명령을 지정

• docker run 명령어로 컨테이너를 실행할 때, 추가 명령을 지정하지 않으면 CMD에서 정한 명령어가 실행됨
• CMD ["R"]
  • 이 명령어는 컨테이너가 시작될 때 기본적으로 R 프로그램을 실행

이렇게 정리해봤는데, 지금 이 글을 읽고 있는 분이 있다면 이해가 되는지 걱정이다. 사실 명령어 개념 같은 부분은 실제로 내가 직접 실습을 해보는게 가장 빠른 이해 루트라고 생각하다. 그래서 나 역시 위에서 설치한 Kaggle RStudio의 도커파일을 분석해보기로 했다.

아래 코드는 RStudio 서버 환경을 구축하기 위해 작성된 Dockerfile이다. 간단히 살펴보면 FROM gcr.io/kaggle-gpu-images/rstats:${rstats_version} 을 통해 베이스 이미지(gcr.io/kaggle-gpu-images/rstats)를 설정하고 있다. 이는 Kaggle GPU 이미지를 기반으로 하여 R과 RStudio 서버를 사용할 수 있게 해준다. 바로 밑의 RUN 부분도 중요한데, 뒤의 명령어들을 통해 실질적으로 RStudio 서버를 다운로드 후 설치하고 있다. 관련 명령어들을 구체적으로 설명하지는 않을거지만(검색을 추천합니다!) 아까 위에서 레이어 개념을 설명했는데 연장선으로 && 를 사용해 레이어를 줄이고 있다는 점도 확인 가능하다!

WORKDIR /home/rstudio 위에서 다룬 명령어는 아니지만 단어에서 유추할 수 있듯이 구체적으로 작업 디렉토리를 설정해 줄 수도 있다.

USER rstudio 를 통해 해당 컨테이너의 사용자를 ‘rstudio’로 지정해 주었다. 기본적으로 Docker는 root 사용자로 실행된다. 다만 보안이나 파일 권한 문제로 인해 특정 작업을 일반 사용자로 지정하는 경우가 많은데 이 때 USER 명령어를 이용해 권한을 바꿔줄 수 있다.

그 외에는 위에서 다뤘던 포트가 눈에 띄는데 EXPOSE 8787 지정해주면서 RStudio Server 쪽에 8787번 포트를 열어주었다.

👇 RStudio server .Dockerfile

  RG rstats_version=v56 

#base image(도커파일의 기본 베이스)는 from으로 불러오기
FROM gcr.io/kaggle-gpu-images/rstats:${rstats_version} 
ARG rstudio_version=2021.09.0-351
RUN apt-get update && \
    apt-get install -y gdebi-core && \
    wget https://download2.rstudio.org/server/focal/amd64/rstudio-server-${rstudio_version}-amd64.deb && \ 
    gdebi -n rstudio-server-${rstudio_version}-amd64.deb && \ 
    apt-get clean && \
    rm rstudio-server-${rstudio_version}-amd64.deb

WORKDIR /home/rstudio
COPY setup.R ./setup.R
RUN chown rstudio:rstudio ./setup.R
RUN chmod +x ./setup.R
USER rstudio
RUN Rscript ./setup.R && \
    rm ./setup.R
USER root


EXPOSE 8787
# LABEL revised_by="Daniel Youk" \
#       revised_date="2023-12-24"
ENTRYPOINT [ "/bin/bash"]
CMD ["-c", "rstudio-server start && tail -f /dev/null"]

그리고 한가지 중요한 점은 CMD ["-c", "rstudio-server start && tail -f /dev/null"] 이 명령어다. 위에서 CMD 를 ‘컨테이너가 시작될 때 기본적으로 실행할 명령을 지정’한다고 설명했다. 이 부분은 내 경험 상 예시 하나의 비교를 통해 바로 이해가 가능했다.

아래 사진은 위에서 다룬 Kaggle R 이미지의 Dockerfile의 가장 마지막 줄의 캡쳐 부분이다. 보면 CMD [”R”] 이라고 적혀있는데, CMD 로 컨테이너 시작 명령어를 지정할 수 있기 때문에 해당 컨테이너를 실행하기 위한 기본 명령어(docker exec)를 응용해 docker exec -it rstudio-container R 이렇게 사용할 수 있다. 이 명령어로 바로 rstudio-container의 R 프로그램에 접근할 수 있는 것이다.

그런데 RStudio Server를 구축하는 도커파일에도 CMD 명령어가 있다. 그런데 분명 생김새가 다른 걸로 보아 차이점이 있는 것이 확실하다.(뭐지..) 결론부터 말하자면 CMD ["-c", "rstudio-server start && tail -f /dev/null"] 명령어는 RStudio 서버를 시작하고 컨테이너가 종료되지 않게 유지하는 기능을 한다. /dev/null은 리눅스 시스템에서 특별한 파일로 입력된 데이터를 모두 버리는 역할을 하는데 tail -f 명령어로 /dev/null 파일을 계속 찾으려고 한다. 하지만 해당 파일은 앞서 말했듯이 무언가 입력되면 데이터를 모두 버리는 역할을 하기 때문에 무한루프에 빠지게 되고 컨테이너가 종료되지 않게 유지하는 기능을 할 수 있는 것이다!

3.1 Difference Between Docker CMD and ENTRYPOINT: When and How to Use Them?

Dockerfile을 작성할 때 CMD와 ENTRYPOINT 두 명령어가 계속 나왔다. 둘다 컨테이너가 시작될 때 실행될 명령을 지정하는 데 사용되는 건 똑같지만 그 역할과 동작 방식에 차이가 있는 것 같다. 이 부분도 다시는 헷갈리기 싫으니 여기서 정리해 보려고 한다!

🚪 CMD

계속 언급되었던 CMD는 컨테이너가 실행될 때마다 수행되지만 덮어쓰기가 가능하다. 만약 사용자가 docker run 명령어를 실행하면서 다른 명령을 입력하면 CMD에서 지정한 명령은 실행되지 않고 새로 입력한 명령이 대신 실행이 가능하다. 예시를 통해 이해해보도록 하자!

우리는 CMD ["R"] 이 코드를 이용해 컨테이너가 시작되면 R 콘솔이 기본으로 실행됨을 위에서 확인했다. 그런데 만약 사용자가 컨테이너를 실행 하면서 다른 명령을 입력한다면 CMD에서 지정한 R은 무시되고 새로운 명령이 실행된다. 이게 무슨 말인가 하면 docker run <image> /bin/bash 로 명령어를 실행하면 R 대신 /bin/bash가 실행 된다는 말이다.

🚪 Entry Point

ENTRYPOINT는 항상 실행될 명령을 지정하는 데 사용된다. CMD와 달리 docker run에서 다른 명령을 입력해도 ENTRYPOINT에서 지정한 명령은 덮어쓰이지 않으며 그대로 실행되는 게 둘의 가장 큰 특징이다. 이것도 예시를 통해 이해해보록 하자!

ENTRYPOINT ["/bin/bash", "-c"] 이 코드는 컨테이너가 실행될 때 항상 /bin/bash -c를 실행하도록 한다. 그런데 만약 사용자가 docker run을 이용해 docker run <image> "echo Hello"를 실행하면 그 명령은 /bin/bash -c 의 인자로 전달되어 /bin/bash -c "echo Hello"로 실행된다!

👇 summary

결론적으로 두 명령어 모두 컨테이너가 시작될 때 실행될 명령을 지정하지만 CMD는 기본 실행 명령을, ENTRYPOINT는 항상 실행되어야 하는 필수 명령을 설정하는 데 사용된다는 점을 꼭기억하길 바란다! 아래 코드는 실제 프로젝트에서 많이 사용하는 조합이니 참고하면 좋을 듯 하다!

ENTRYPOINT ["/bin/bash", "-c"]
CMD ["rstudio-server start && tail -f /dev/null"]

4. Docker Pipeline

이번 포스팅을 마무리 하기 전에 지금까지의 학습 과정을 시각적으로 정리해 보려고 한다. 지금까지의 포스팅은 Dockerfile을 통해 이미지 생성하고 그 이미지를 통해 컨테이너 실행하는 부분까지 진행되었다. (Dockerfile → 이미지 생성 → Registry 저장 → 이미지 가져오기 → 컨테이너 실행)

지금이야 이미지를 만들고 로컬에서 실행하는 데 큰 문제가 없었다. 하지만 컨테이너에서 사용하는 이미지들이 많아진다면 로컬이라는 한정된 공간에서 효율성이 떨어지게 된다. 그래서 보통은 Docker Registry라는 곳에 이미지를 저장(push)하고 필요할 때마다 당겨와(pull) 로컬 혹은 가상머신에서 사용하는 게 일반적이다. 다음 포스팅 부터는 이 이야기를 중심으로 진행되니 기대해 주길 바란다! 😎

이번 주차는 지금까지 도커를 공부하며 비유적으로 이해했던 부분들에 대해 조금 더 소프트웨어 측면에서 이론을 다루었다. 그러다보니 뭐랄까.. 분명 내가 알고 있던 내용이였던 것 같은데 또다시 새로운 내용이 되어버린 것 같았다. 특히 Dockerfile의 ENV, ARG 명령어에 대해서는 이미지를 빌드할 때, 컨테이너를 실행할 때로 구분되는데, 구체적으로 도커파일을 직접 생성해보면서 개념을 다질 필요가 있다고 느꼈다.

아무튼 이번주차를 기점으로 도커 포스팅 시리즈도 반환점을 돌았다. 여전히 많이 부족한 글이지만 분명 글로 남기고 정리하는 건 이해의 농도가 다를 거라고 생각한다. 이번주는 유난히 뭘 해도 집중이 안되는 날이었는데 일단 버텨보는 걸로 하자!👊

Reference

Kaggle_R_Dockerfile

Please allow me to introduce myself: Torch for R