컨테이너 사용법 6 | Docker&Kubernetes 학습 29

컨테이너의 개조

• 도커를 실제 운용하는 현장에서는 사내에서 개발한 시스템을 운영하는 경우가 많다.
• 사내 개발 시스템이 아니더라도, 공식 배포되는 소프트웨어 역시 수정해야 할 필요가 종종 있다.
  • 큰 수정은 아니지만 설정 파일 따위를 매번 작성하기는 귀찮기 때문
• 컨테이너를 개조하는 방법은 두 가지 이며, 보통 이 두 가지 방법을 혼용한다.
• 파일 복사와 마운트를 이용한 방법 하나와, 컨테이너에서 리눅스 명령어를 실행하는 방법이 있다.

컨테이너에서 명령어를 실행하려면, 셸이 필요하다

• 컨테이너에서 리눅스 명령어를 실행하려면, 리눅스에 우리의 명령을 전달해 주는 프로그램인 shell(셸)이 필요하다.
• 컨테이너를 아무 설정없이 실행하면 bash가 동작하지 않는 상태로 실행된다.
• 아래의 인자를 컨테이너 실행 시 전달하면, bash가 실행되어, 컨테이너가 입력을 받을 수 있는 상태가 된다.
  • /bin/bash: docker run 또는 docker exec 명령어와 함께 사용한다.
  • docker exec: 컨테이너 속에서 명령어를 실행하는 명령어
  • 실행중인 컨테이너에 run 명령어는 사용 못하므로, exec 명령어를 사용한다.
• docker run 명령어에 bash 인자를 붙이게 된다면?
  • 컨테이너에 들어있는 SW를 실행하지 않고 bash가 실행된다.
  • 즉 컨테이너는 실행 중인데, SW는 실행 중이 아닌 상태가 된다.
  • bash를 사용한 컨테이너 조작이 끝나고 나면 다시 docker start 명령어로 컨테이너를 재시작해야 한다.

 

exec 명령어에 인자를 추가한 예: docker exec (옵션) 컨테이너_이름 /bin/bash
run 명령어에 인자를 추가한 예: docker run (옵션) 이미지_이름/bin/bash
exec 명령어에 인자를 추가한 예: docker exec -it apa00ex23 /bin/bash
run 명령어에 인자를 추가한 예: docker run --name apa00ex23 -it -p 8089:80 httpd /bin/bash

• run 명령어로 아파치가 있는 컨테이너를 실행하지만, 아파치가 실행되지 않음
• bash가 실행되면 셸에 입력된 명령은 도커 엔진이 아니라 컨테이너로 전달된다.
• 명령을 입력받는 대상이 바뀌어 프롬프트도 바뀐다.
• bash를 통해 컨테이너 내부를 조작하는 동안 도커 명령어를 사용할 순 없다.

  

  
  
• 컨테이너 생성, 삭제, 컨테이너 자체에 대한 명령은 도커 엔진을, 컨테이너 내부를 다루는 명령은 bash를 통한다.
• 그래서, 컨테이너 안에서 할 일을 마쳤다면 다시 컨테이너에서 나와야 한다.
  • 컨테이너에서 나와 도커 엔진에 명령을 내릴 수 있도록 해주는 명령어: exit
• bash를 통해 사용하는 명령어는 linux 명령어다.

 

 

도커의 구조, 도커 엔진을 통해야 하는 명령과 컨테이너 안에서 실행해야 하는 명령 간의 차이는 무엇일까

도커 엔진을 통한 명령과 컨테이너 내부에서 실행하는 명령

• 도커 엔진을 통한 명령어는 컨테이너 전체에 대한 관리 작업이다.
  • 도커 엔진 자체의 시작 또는 종료, 네트워크, 디스크 설정, 컨테이너 생성, 실행, 종료 등
• 컨테이너 내부에서 실행하는 명령어는 컨테이너 속에 새로운 SW 추가, 컨테이너 속 SW의 실행 및 종료, 설정 변경, 컨테이너 안과 밖의 파일 복사 및 이동, 삭제 작업이다.

도커와 컨테이너는 별개의 언어를 사용한다.

• 컨테이너 내부에서 사용하는 명령어가 약간씩 달라짐
  • 컨테이너에 들어있는 '운영체제 비슷한 것'의 종류가 무엇이냐에 따라서.
• 컨테이너 A가 데비안, 컨테이너 B가 레드햇 계열을 사용한다면 똑같이 도커에서 실행중인 컨테이너라도 컨테이너 내부에서 사용하는 명령의 스타일이 달라진다.

  

  
  
• 만약 도커 리눅스 버전을 사용할 때 도커 엔진이 설치된 호스트 컴퓨터는 CentOS(레드햇 계열), 컨테이너 A는 우분투(데비안 계열), 컨테이너 B는 알파인 리눅스를 사용한다면 약간 골치아픈 상황이 벌어지긴 한다.

  

  
  
• 그렇다고 엄청난 차이가 있는 것은 아니다.
• 몇 가지 명령어를 빼면 대부분은 공통이라, 가끔 명령어가 달라진다고 생각하면 된다.
  • 데비안 계열에서 아파치를 설치하는 명령어: apt install apache2
  • 레드햇 계열에서 아파치를 설치하는 명령어: yum install httpd
• 도커에서 공식적으로 "특별한 이유가 없다면 데비안 계열을 기반으로 하는 것이 좋다"고 방침을 밝혔다.
• 그래서 대부분의 컨테이너와 특히 컨테이너 내부를 통해 개조 작업을 하는 컨테이너는 데비안 계열이다.

 

다른 사람과 이미지를 공유하는 방법은 뭘까

이미지를 내려받는 곳

• docker run 명령어를 사용할 때 자동으로 이미지를 내려 받은 곳이 도커 허브이다.
• 직접 만든 이미지도 도커 허브에 올릴 수 있으며, 비공개로 사용하는 도커 허브 같은 장소도 만들 수 있다.

 

도커 허브와 도커 레지스트리

• 이미지를 배포하는 장소를 도커 레지스트리 라고 한다. 어디든 이미지가 배포되는 곳은 모두 도커 레지스트리이다.
• 도커 허브는 도커 제작사에서 운영하는 공식 도커 레지스트리를 말한다.
• 대부분의 공식 이미지는 모두 도커 허브에서 공식 이미지를 배포한다.
• 도커 레지스트리는 도커 제작사 외의 다른 기업이나 개인도 운영할 수 있어, 전 세계적으로 많다.
  • 다만 외부에 공개되지 않은 도커 레지스트리는 우락 접속할 수 없으므로, 사용할 일이 없을 뿐이다.

레지스트리와 리포지토리

• 레지스트리는 이미지를 배포하는 장소이고, 리포지토리는 레지스트리를 구성하는 단위이다.
• 예를 들면, 레지스트리는 회사나 부서 단위로 만들지만, 리포지토리는 SW 단위로 한다.
• 도커 허브에서는 리포지토리가 각각 ID를 갖게 돼 있다.
• 따라서 도커 허브는 각가의 회사나 개인이 가진 레지스트리가 여럿 모인 형태가 된다.

도커 허브에 공개로 업로드하든, 비공개 리포지토리에 업로드하든 이미지를 업로드하려면 이미지에 태그를 부여해야 한다.

이미지 이름과 태그

• #docker 와 같은 해시태그랑 여기서 말하는 태그와 다르다.
• 도커의 태그는 레지스트리에 업로드를 상정한 이미지 이름에 가깝다.
• 태그를 붙이는 방법: myapa00ex22 → charmcharm.comm/myapache:13
  • charmcharm.comm : 레지스트리 주소
  • myapache : 리포지토리 이름
  • 13 : 버전
• 태그는 '레지스트리_주소(도커 허브라면 ID)/리포지토리)이름:버전'의 형식을 띤다.
• 버전은 생략해도 되지만, 나중에 다루기 복잡해질 수 있으니 붙이는 게 좋다.
• 비공개 레지스트리의 태그 명명 예

  비공개 레지스트리의 태그	레지스트리_주소/리포지토리_이름:버전
  자신의 PC에 만든 레지스트리, 리포지토리 이름은 myapache, ver13	localhost:5000/myapache:13
  레지스트리 도메인은 charmcharm.comm, 리포지토리 이름은 myapache, ver13	charmcharm.comm/myapache:13

• 도커 허브의 태그 명명 예

도커 허브의 태그	도커_허브_ID/리포지토리_이름:버전
도커 허브 ID는 charmcharmuse, 리포지토리 이름은 myapache, ver13	charmcharmuse/myaphache:13

 

이미지에 태그를 부여해 복제하는 명령어 docker tag(=docker image tag)

• 원래 있던 이미지 이름을 태그로 바꾸고 이미지를 복제하라는 의미
• 명령어 실행 후 image ls 명령어로 목록을 보면, 원래 이름의 이미지와 태그가 부여된 이미지가 둘 다 존재한다.
• 이 두 개의 이미지 ID는 동일하지만, 별개의 이미지로 취급되므로 이미지를 삭제할 때는 두 가지 모두 삭제해야 한다.
• 명령어 예: docker tage 원래_이미지_이름 레지스트리_주소/리포지토리_이름:버전
  • 예: docker tag apa00ex22 charmcharm.comm/myapache:13

 

이미지를 업로드 하는 명령어 docker push(=docker image push)

• 태그는 '레지스트리_주소(도커 허브라면 ID)/리포지토리)이름:버전' 형태로 길어서 알아보기 힘들다.
• 하지만 그 자체로 하나의 이름이고, 어느 레지스트리에 업로드할지도 태그로 판단한다.
• 다시말해, 도커 엔진은 태그에 포함된 레지스트리 주소의 도메인에 있는 레지스트리로 업로드를 시도한다.
• 리포지토리는 처음 업로드 할 때는 존재하지 않고, push 명령어를 실행하며 만들어진다.
• 레지스트리에 따라 로그인을 요구하는 경우도 있다.
• 명령어 예: docker push 레지스트리_주소/리포지토리_이름:버전
  • 예: docker push charmcharm.comm/myapche:13

 

개발회사는 대개 사내용 도커 레지스트리를 만들고 여기에 개발환경 이미지를 올려 배포하는 체계를 갖추고 있을 것이다. 외부 공개를 목적으로 한다면 도커 허브가 가장 이상적이다.

비공개 레지스트리를 만드는 방법

• 레지스트리용 컨테이너가 따로 있어 이를 사용하면 된다. 즉 레지스트리도 도커를 통해 운영할 수 있다.
• 레지스트리를 만드는 명령어 예: docker run -d -p 5000:5000 registry

 

도커 허브 사용

• 이메일 주소만 있으면 누구든지 도커 허브에 가입할 수 있다.
• 도커 허브: https://hub.docker.com
• 도커 허브에 이미지를 업로드하면, 전 세계 사람들에게 이미지를 배포할 수 있다.
  • 비공개 설정을 하면 이미지를 공개하지 않을 수도 있다.
• push 명령어로 리포지토리를 만들면 자동적으로 공개 상태(public)가 된다.