일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- Ctrl
- locate 설치 방법
- 이미지
- 이미지 레지스트리
- docker logs
- LS
- mkdir
- container
- 파일
- docker create
- 도커
- 디스크
- Docker
- 리눅스
- linux
- 컨테이너
- 리눅스마스터2급
- 레드햇
- q!
- RM
- docker logout
- 자격증
- PS
- etc
- 명령어
- find
- 셸
- umask
- image
- lcoate 설치
- Today
- Total
Bae's Digital Dialogues
도커[Docker] 이미지의 메타데이터(Metadata) 본문
$docker image inspect 이미지명 #이미지의 세부 정보 조회
$docker container inspect 컨테이너명 #컨테이너의 세부 정보 조회
$docker run 이미지명 (실행명령) #컨테이너 실행 시 메타데이터의 cmd 덮어쓰기
$docker run --env KEY=VALUE 이미지명 #컨테이너 실행 시 메타데이터의 env 덮어쓰기
nginx 이미지의 메타데이터를 확인해보는 명령어를 입력해보자
$docker image inspect nginx
$docker run -d --name defaultCmd nginx #nginx 이미지를 defaultCmd 이름의 컨테이너로 실행
실행된 컨테이너를 확인해 보자
$docker ps #실행 중인 컨테이너 리스트 조회
defaultCmd 컨테이너의 메타데이터를 확인해보자
$docker container inspect defaultCmd #defaultCmd 컨테이너의 메타데이터 확인
이번에는 이미지에 있던 메타데이터에 nginx 프로그램을 실행하는 nginx -g daemon off라는 cmd필드를 덮어쓰기 해보자
$docker run --help
덮어쓰기하는 명령을 확인해보기 위해서 docker run --help를 해보자
그러면 이제 docker run 명령을 사용해서 새로운 컨테이너를 실행해보자
$docker run --name customCmd nginx cat usr/share/nginx/html/index.html #기본 이미지의 메타데이터를 사용해 컨테이너 실행
이 파일은 저번 글에 nginx 웹사이트에 접속했을 때 브라우저에 표시된 파일과 동일한 내용이다.
2024.05.20 - [Docker] - 이미지와 컨테이너
이미지와 컨테이너
$docker run -d --name {컨테이너명} 이미지명 #컨테이너 실행$docker ps #실행 중인 컨테이너 리스트 조회$docker rm -f #실행 중인 컨테이너 삭제$docker image ls(이미지명) #로컬 이미지 조회 이전 글에서 ngi
baddiehoon.tistory.com
Welcomde to nginx라는 문구를 확인할 수 있다.
그러면 이제 실행된 컨테이너의 메타데이터를 확인해 보자
$docker container inspect customCmd #customCmd 컨테이너의 메타데이터 확인
그리고 docker ps 명령어를 입력해보자
$docker ps
입력해 보면 처음에 실행했던 defaultCmd만 확인되고 customCmd는 보이지 않는데 이 customCmd 컨테이너에서 실행한 cat명령어는 파일의 내용을 출력하고 종료되는 일회성 프로세스이기 때문에 Cmd에서 지정한 cat 명령이 종료되는 순간 컨테이너도 함께 종료가 된다. 그래서 customCmd는 종료된 상태의 컨테이너이기 때문에 일반적인 docker ps 명령으로는 조회가 되지 않는다. 그래서 docker ps에 -a옵션을 하면 종료된 컨테이너까지 모두 확인할 수 있다. -a 옵션은 All을 의미한다.
$docker ps -a
customCmd는 Exited라고 해서 종료된 상태인 것을 확인할 수 있다.
이 컨테이너는 이미지의 데이터를 복사해서 만들어지기 때문에 실제로 컨테이너의 메타데이터를 바꾼다고 해서 이미지의 메타데이터가 바뀌지는 않는다.
$docker image inspect nginx
동일하게 유지가 되어 있는 것을 확인 할 수 있다
다음은 도커 run명령과 함께 사용했었던 -d 옵션에 대해서 알아보자
$docker run -d 이미지명 #컨테이너를 백그라운드에서 실행
-d 옵션 추가 시 - 지속적으로 실행되는 데몬 프로그램을 실행할 때 적합
-d 옵션 제거 시 - 실행 후 종료되는 프로그램에 적합, 실시간으로 로그를 확인할 경우
$docker run -d --name defaultCmd nginx #nginx 이미지를 defaultCmd라는 이름의 컨테이너로 실행
$docker run --name customCmd nginx cat usr/share/nginx/html/index.html #기본 이미지의 메타데이터를 사용해 컨테이너 실행
첫번째 nginx를 실행할 때는 -d 옵션을 주었었고 두 번째 cat 명령을 실행할 때는 -d 옵션이 없이 실행 했었다.
cat명령은 일회성 명령어이고 화면에 파일의 내용을 출력하고 종료되기 때문에 다시 사용자의 입력창으로 돌아올 수 있는 것이다.
하지만 nginx 같은 경우는 지속적으로 실행되는 데몬 프로세스이기 때문에(-d는 데몬의 약자) -d옵션을 주지 않으면 지속적으로 화면에 로그가 출력된다.
지속적으로 화면에 로그가 출력되는 것을 확인할 수 있다
이제 더 이상 명령어를 실행할 수 없기 때문에 추가로 명령어를 실행하기 위해서는 -d 옵션을 주어서 백그라운드에서 실행되도록 설정해야 한다.
-d 옵션을 주면 커맨드 라인에는 실행된 컨테이너의 아이디만 출력이 된다
그래서 이제 다른 명령어를 추가로 사용할 수 있게 되는 것이다.
env 필드에 대해서 공부해보자
두번째로 실행할 컨테이너는 이미지의 메타데이터에 지정된 환경 변수를 덮어씌울것이다
envsnodecolorapp이라는 애플리케이션을 써 볼건데 이 애플리케이션은 사용자에게 특정 색상의 웹페이지를 응답해준다.
컨테이너를 실행할 때 어떤 설정을 하냐에 따라서 다른 색깔의 글씨를 출력해준다.
이런 비즈니스 로직이 있는 경우에는 단순히 특정 파일을 응답해주는 웹서버만으로는 요구사항을 충족시킬 수 없다.
그래서 이 envsnodecolorapp은 Node.js라는 자바스크립트 기반으로 개발된 백앤드 애플리케이션이다.
먼저 이미지의 메타데이터를 확인하기 위해서 이미지를 다운받아 보자
$docker pull devwikirepo/envnodecolorapp #실습용 이미지 다운로드
이미지는 docker pull 명령어를 이용하여 다운 받을 수 있다
다운로드가 다 되었다면 위 명령어를 통해서 메타데이터를 확인해보자
$docker image inspect devwikirepo/envnodecolorapp #실습용 이미지 메타데이터 확인
env 필드의 내용을 보면 이렇게 color라는 키에 red라는 값을 가지고 있는 것을 확인 할 수 있다
그리고 Node.js 애플리케이션을 실행하는 npm start라는 명령이 Cmd 필드에 지정되어 있는 것을 확인할 수 있다.
이제 다운받은 이미지를 컨테이너로 실행해 보자
$docker run -d -p 8080:3000 --name defaultColorApp devwikirepo/envnodecolorapp #기본 이미지의 메타데이터를 사용해 컨테이너 실행
이미지의 env 필드를 가져오기 때문에 color라는 키의 값이 red로 되어 있을것이다.
이제 두번째 컨테이너를 실행시켜보자
$docker run -d -p 8081:3000 --name blueColorApp --env COLOR=blue devwikirepo/envnodecolorapp #새롭게 env 필드를 덮어쓰기한 컨테이너 실행
이제 두번째로 실행된 blueColorApp의 메타데이터를 확인해보자
$docker container inspect blueColorApp #blueColorApp 컨테이너의 메타데이터 확인
env 필드를 가보면 color = blue라는 값이 color=red를 덮어 씌운 것을 확인할 수 있다.
이제 브라우저를 열어서 두 개의 애플리케이션에 접속해보자
먼저 localhost:8080을 입력해 defaultColorApp으로 접속해보자
defaultColorApp에는 env필드의 color값이 red로 되어 있었기 때문에 글씨 색깔이 빨갛게 표시되는 걸 확인할 수 있다.
8081로 들어가 blue 컬러 앱을 확인할 수 있다.
마찬가지로 env필드의 color가 blue로 되어 있었기 때문에 글씨 색깔이 파란색으로 나오는 것을 확인할 수 있다.
이제 사용된 컨테이너를 모두 제거해보자
$docker rm -f defaultCmd customCmd defaultColorApp blueColorApp #모든 컨테이너 삭제
모두 제거된것을 확인할 수 있다.
이번에는 이미지와 컨테이너의 메타데이터를 공부해 보았는데 실습으로 더 익숙해질 필요성을 느꼈다.
'Docker' 카테고리의 다른 글
도커[Docker] 이미지 레지스트리 (0) | 2024.05.27 |
---|---|
도커[Docker] 컨테이너의 라이프사이클(Lifecycle) (0) | 2024.05.24 |
도커[Docker] 이미지와 컨테이너 (0) | 2024.05.20 |
도커[Docker] 컨테이너 실행 (0) | 2024.05.20 |
도커[Docker] 가상화 기술과 하이퍼바이저 가상화 (0) | 2024.05.14 |