이번엔 공유를 다뤄보자.
공유란 독자 여러분이 로컬 컴퓨터에서 빌드한 이미지를 다른 사람이 사용하게끔 하는 것을 말한다.
도커 플랫폼은 소프트웨어 배포 기능을 가지고 있다. 우리가 내려받은 이미지는 도커 레지스트리라고 불리는 서버에 저장된다. 도커 허브는 도커 레지스트리 중 가장 유명한 레지스트리이다. 도커 허브는 도커 엔진에 기본으로 설저오딘 레지스트리이기도 하다.즉 로컬 컴퓨터에 없는 이미지를 찾위해 가장 먼저 살펴보는 곳이 도커 허브라는 뜻이다.
도커 이미지에는 이름이 부여되는데, 이 이름에 해당 이미지를 내려받기 위해 필요한 모든 정보가 들어 있다.
우리가 사용했던 diamol/golang 이미지는 두 개의 요소로 구성되는 간단한 이름을 지녔지만 사실 전체 이름은 네 개의 요소로 구성된다.
직접 개발한 애플리케이션의 이미지를 관리하면 이미지 참조의 모든 구성요소를 다 사용해야 한다.
레지스티리와 태그 등의 정보는 따로 지정하지 않아도 도커가 미리 정해진 기본값을 사용한다.(도커 허브, latest)
해당 리포지터리는 공개 리포지터리이므로 누구든지 이미지를 내려받을 수 있다. 그러나 diamol 단체의 소속원만이 리포지터리에 이미지를 푸시할 수 있다.
가장 중요한 부분은 태그라고 책에선 소개하는데 아직은 잘 모르겠다.
푸시 하기 위해선 2가지 절차가 필요하다.
1. 도커 명령행을 통해 레지스트리에 로그인(이 과정을 통해 푸시할 권한 부여)
2. 이미지에 푸시 권한을 가진 계정명을 포함하는 이미지 참조를 붙임
독자마다 허브 계정이 다르므로 환경변수로 지정하라고 책에 명시를 해 두었다.
윈도 환경 파워셸
$dockerId="도커허브계정이름"
현재 4장에서 image-gallery이미지를 빌드한 바 있지만, 이 이미지 참조에는 계정 이름이 지정돼 있지 않기 때문에 지금 상태로는 이 이미지를 푸시할 수 없다.(이미지는 여러 개의 참조를 가질 수 있다.)
docker image tag image-gallery $dockerId/image-gallery:v1
해당 명령은 기존 이미지에 새로운 이미지 참조를 부여한 것이다. 태그는 v1으로 지정한다.
이제 이 이미지는 두 개의 이미지 참조를 갖게 됐다. 그중 하나는 계정 이름과 버전이 지정된 상태다. 또한 유일한 식별자를 갖는다. 이 식별자를 통해 여러 개의 이미지 참조가 같은 이미지를 가리키는지도 알 수 있다.
docker image ls --filter reference=image-gallery --filter reference='*/image-gallery'
해당 명령어는 image-gallery 이미지의 이미지 참조 목록이다.
이미지 ID가 같은 것을 통해 두 이미지 참조가 같은 이미지를 가리키는 것을 알 수 있다.
docker image push $dockerId/image-gallery:v1
해당 명령을 통해 $dockerId/image-gallery:v1 이미지를 레지스트리에 푸시할 수 있다.
도커 레지스티도 로컬 컴퓨터에서 동작하는 도커 엔진과 같은 방식으로 이미지 레이어를 다룬다. 이미지를 푸시할 때 실제로 업로드 대상이 되는 것은 이미지 레이어다.
이미지 레이어를 다룬다는 것은 Dockerfile 스크립트의 최적화가 중요하다는 의미이다. 레지스티리에서도 캐시상에 레이어 해시와 일치하는 레이어가 없을 경우에만 실제 업로드가 이뤄진다.
이제 웹에서 도커 허브를 열람해 새로 푸시한 이미지를 확인해 보자. 도커 허브에서 제공되는 이미지에 대한 웹 페이지 URL은 이미지 참조와 같은 방식으로 구성된다.
echo "https://hub.docker.com/r/$dockerId/image-gallery/tags"
사이트를 통해 알 수 있는 것에는 2가지가 있다.
1. 리포지터리 이름은 나의 계정 이름과 image-gallery가 합쳐져 만들어진다.
2. 이 리포지터리에는 현재 태그가 v1하나 뿐이지만, 태그가 여러 개 있을 수 있다.
도커 코어 레지스티리 서버는 도커 허브와 동일한 레이어 캐시 시스템을 통해 이미지를 내려받고 푸시하는 기본적인 기능을 제공한다. 그러나 도커 허브에서 볼 수 있는 웹 기반 UI 등의 기능이 빠져있다. 코어 레지스트리는 내가 별도로 diamol 계정에 패키징한 이미지를 사용해 컨테이너 형태로 직접 실행할 수 있다.
docker container run -d -p 5000:5000 --restart always diamol/registry
--restart 플래그는 도커를 재시작했을 때 해당 컨테이너도 자동 재시작된다.
위의 명령어는 내가 패키징한 이미지를 사용해 컨테이너 형태로 도커 레지스트리를 실행시켜보는 것이다. 즉, 로컬 컴퓨터에 나만의 전용 레지스티리가 생겼다는 의미이다. 이 명령으로 실행되는 레지스트리 서버의 기본 포트는 5000이다. 이 레지스트리의 도메인 localhost:5000을 사용해 이미지에 태그를 부여하면 새로운 레지스트리에 이미지를 푸시할 수 있다. 이 레지스트리는 로컬 컴퓨터에서만 접근 가능하기에 유용하진 않지만 제대로 된 도메인 네임을 붙인다면 활용도가 높아진다.
파워쉘에선
Add-Content -Value "127.0.0.1 registry.local" -Path /windows/system32/drivers/etc/hosts
이번 명령은 도메인 네임을 별명으로 붙이는 명령이다. 로컬 컴퓨터에 regisry.local이라는 별명을 추가하는 것이다. 도메인과 IP 주소의 연결을 기록한 작은 텍스트 파일인 hosts 파일에 새로운 도메인-주소 쌍을 추가하면 된다.
오 이런것도 뜨네?
되는 것을 확인했다.
docker image tag image-gallery registry.local:5000/gallery/ui:v1
해당 명령어는 로컬 컴퓨터의 별명을 이용해 이미지 참조를 부여하는 것이다.
로컬 컴퓨터에 실행 중인 레지스트리에는 별도의 인증 수단이 없으며, 레지스트리 운영을 위해 직접 사용할 수 있을 만한 수준은 아니다. 하지만 소규모 팀에 적합하고, 자신만의 이미지 참조 명명 체계를 만들 수 있다.
4장에서 만들었던 3개의 컨테이너를 모두 같은 방법으로 gallery 프로젝트 아래로 묶어 보자.
docker image tag image-gallery registry.local:5000/gallery/ui:v1
docker image tag image-of-the-day registry.local:5000/gallery/api:v1
docker image tag access-log registry.local:5000/gallery/logs:v1
로컬 컴퓨터의 레지스트리에 이미지를 푸시하려면 아직 한가지가 남아 있다. 레지스트리 컨테이너는 이미지를 푸시하고 내려받기 위해 보안 프로토콜인 HTTPS 대신 HTTP를 사용한다는 것이다. 도커의 기본 설정에서는 비보안 프로코콜이 적용된 레지스트리를 사용할 수 없게 돼 있다. 비보안 레지스트리를 사용하려면 로컬 컴퓨터의 레지스트리를 비보안 레지스트리 허용 목록에 추가해야한다.
도커 설정은 daemon.json이라는 설정 파일에서 할 수 있다.(저장 경로, 도커 API가 주시하는 포트 번호 등) 이 파일은 윈도에서는 "C:\Program Data\docker\config"에 위치해 있다. 도커 데스크톱을 이용 중이라면 사용자 인터페이스를 통해 설정을 수정 할 수 있다.
아 지금 맞게 하는 것인가?
그리고 나서 도커 엔진을 재시작한다.
Restart-Service *docker*
그렇게 되면
여기에 추가된 것을 확인할 수 있다.
비보안 레지스트리를 사용할 때는 주의가 필요하다. 도커 엔진과 레지스트리의 통신 내용을 제삼자가 엿볼 수 있으며 이미지 푸시과정에서 레이어가 유출될 수 있다. 하지만 로컬 컴퓨터에서 데모 용도로 사용한다면 비보안 레지스티리라도 크게 걱정할 필요는 없다.
이제 태그가 부여된 이미지를 로컬 컴퓨터의 레지스트리에 푸시할 수 있다.
이미지 참조에 레지스티리의 도메인이 포함돼 있으며 해당 도메인이 비보안 레지스트리 허용 목록에도 들어가 있으므로 사용에 문제가 없다.
docker image push registry.local:5000/gallery/ui:v1
이거를 한번 더 실행하면 아무일도 일어나지 않는다.
실제 도메인 네임이나 IP주소를 알려주면 로컬 네트워크상의 다른 사람에게 이미지를 공유할 수 있다.
대부분의 소프트웨가 소수점으로 구분된 숫자로 버전을 나타낸다. 이미지 태그도 비슷한 방법을 사용하는데 기본적인 방법은 [major].[minor].[patch]형태를 따르는 것이다.patch는 버그 수정, minor는 추가된 기능 & 기존 기능 유지, major는 완전히 다른 기능을 가진다는 뜻이다.
docker image tag image-gallery registry.local:5000/gallery/ui:latest
docker image tag image-gallery registry.local:5000/gallery/ui:2
docker image tag image-gallery registry.local:5000/gallery/ui:2.1
docker image tag image-gallery registry.local:5000/gallery/ui:2.1.106
앞서 패키징했던 Go 애플리케이션에 태그 형식을 바꾼 것이다.
멀웨어 배포를 막기 위해 도커 허브는 검증된 퍼블리셔와 공식 이미지 제도를 통해 피해를 방지한다.
도커 허브를 통해 이미지를 배포하는 단체들 중 큰 기업을 '검증된 퍼블리셔'로 지정한다.
공식 이미지는 이런 개념과는 조금 다르다. 공식 이미지로 배포되는 소프트웨어는 주로 오픈 소스 소프트웨어로, 해당 프로젝트 개발 팀과 도커가 함께 이미지를 관리한다. 공식 이미지 역시 취약점 탐색을 거치고 주기적으로 업데이트되며, 최적화된 Dockerfile 스크립트로 구성된다. 골든 이미지는 공식 이미지를 기반 이미지로 삼아 인증서나 환경 설정값 등 필요 설정을 추가한 것이다. 골든 이미지는 도커 허브의 기업 리포지터리나 자체 리포지터리에서 관리된다.
docker image build -t golden/dotnetcore-sdk:3.0 .
docker image build -t golden/aspnetcore-sdk:3.0 .
해당 명령어는 닷넷코어 애플리케이션을 위한 골든 이미지를 빌드할 수 있는 스크립트를 실행하여 이미지를 빌드하는 것이다.
골든이미지라해서 특별한 것은 없다. 다른 이미지처럼 Dockerfile 스크립트로부터 빌드하고 우리가 정한 이미지 참조 규칙을 따른다.
공식 이미지는 매달 새 버전이 릴리스되지만, 골든 이미지는 업데이트 주기를 우리 마음대로 정할 수 있다.