[Docker] Docker Registry(Private Repository, Http)

 

Docker Private Registry

사내에서 사용되는 Docker Image 같은 경우, Public 하게 관리되어서는 안되는 경우들이 존재한다. 백엔드 서버 라던지 OS정보, 네트워크, 설정 정보와 같은것들이 Image 파일안에 전부 들어가 있기 때문이다.

Docker Hub 에도 Private 하게 image push 할 수 있지만, 무료계정의 경우 제한이 존재한다(용량, 횟수) 

 

Docker Registry는 사내 서버, 혹은 서버중 하나에 프라이빗한 자체 Docker Hub 를 구축한다고 생각하면 될것 같다.

외부에 공개되지 않으면서, 사내에서 자체적으로 제한 없이 관리할 수 있기에 자체적인 Infra 를 구축하는데 있어서 좋은 선택지 인것 같다.

필자의 경우, 홈서버에서 테스트할 서버들 Image 를 push 할 목적으로 구성하게 되었다.

 

 

Docker 에서 제공하는 Docker Registry 를 이용해 private docker hub 를 구축해볼 예정이다.

필자의 환경은 Registry 를 설치할 Ubuntu Server 와, push 테스트할 Mac os 에서 진행했다.

 

 

Docker Compose.yml File

version: "3.8"

services:
  registry:
    image: registry:2
    container_name: docker_registry
    restart: always
    ports:
      - "5000:5000"
    environment:
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
      REGISTRY_STORAGE_DELETE_ENABLED: "true"  # 이미지 삭제 활성화
    volumes:
      - /data/services/registry:/var/lib/registry

 

간단하게 docker pull 로 진행하는 방법도 존재한다.

voulmes 로 서버의 dir path 와 docker container 내부의 dir 을 연결했다. 추후 Registry 를 삭제하더라도 정보는 남아있기에 언제든지 다시 기동시켰을때 정보는 그대로 남아있기 때문이다.

 

$sudo docker compose up -d

해당 명령어를 통해 간단하게 기동 시킬 수 있다.

docker compose up -d

 

참고로 기본적으로는 TLS/SSL 인증서를 발급받아서 HTTPS 로 사용해야 한다.

해당 글에서는 HTTP Registry 를 허용하도록 설정하여 사용할 예정이다.

 

 

 

- HTTP Registry 허용

우선 Docker Registry 가 설치되어있는 서버에서 HTTP 허용을 위한 설정을 해주도록 하겠다.

$sudo vim /etc/docker/daemon.json

{
  "insecure-registries": ["서버IP:5000"]
}

해당 경로에 daemon.json 파일을 생성하고, "insecure-registries" 를 작성 후 저장해주도록 하자.

이때 서버의 IP 란 Docker Registry 가 설치되어있는 PC 의 IP 이다.

 

 

- Push 할 PC 에서의 HTTP 허용

docker 가 설치되어있는 경로에 위와 똑같이 작성을 해주어도 되고, Docker Desktop 을 사용하는 유저라면

아래와 같이 Docker Engine 설정에서 "insecure-registries" 와 대상 IP 를 추가해주도록 하자.

 

 

설정을 해준 디바이스에서 Docker 를 재시작해 주도록하자.

$sudo systemctl restart docker

 

재기동 이후 Docker Registry Container 가 정상 동작하는지 확인해 보자.

curl -X GET http://{IP}:5000/v2/_catalog

docker registry 에는 현재 아무것도 push 되어 있지 않아서 [] 으로 출력되게 된다.

 

 

Docker Registry Push

docker 에서 제공하는 test container 인 "hello-world" 이미지를 pull 받아서 registry 에 push 까지 진행해보도록 하겠다.

docker pull hello-world

# Test Image pull
$docker pull hello-world


# Image Tagging
$docker tag hello-world:latest {ip:port}/my-hello


# Image Push
$docker push {IP:PORT}/{image 명}:{tag 없으면 생략}

tag 키워드를 사용해 image 명을 변경한다 :{tag} 에 아무것도 적지않으면 default : latest 로 지정된다.

이후 Docker Registry 에 push 를 해주도록 하자.

정상적으로 Push 가 되었다면 아래와 같이 조회가 된다.

 

 

만약 아래 처럼 HTTPS failed to Request 로그가 남는다면, insecure 설정을 제대로 했는지 다시 확인 해보도록 하자.

 

 

/v2/_catalog 말고 아래의 API 를 사용하면 해당 Image 의 태그들을 가져올 수 있다.(이후 Registry 삭제때 확인)

curl -X GET http://localhost:5000/v2/{Image 명}/tags/list # image tag 확인

 

pull 의 경우도 push 때와 같이 진행하면된다. 

docker pull {IP:Port}/{image 명}:{tag}

 

 

 

Docker Registry 삭제

push, pull 은 상대적으로 쉬운방면에 Registry 에 올라간 Image 를 삭제하는것은 꽤나 복잡한 과정들을 거쳐야 한다..

꽤나 복잡한 과정을 거쳐야 하기 때문에 순서를 먼저 적고, 명령어를 한번에 올리도록 하겠다.

여기서 부터는 모두 Registry 가 설치 되어있는 서버에서 진행하도록 하겠다.

 

1. Registry 내에 Image, Tag 정보 조회
2. Content Digest 정보 조회
3. Manifest 정보 삭제
4. GC(Garbage Collection) 실행
5. Docker 재실행 || 물리 폴더 삭제

여기서 1번의 Image, Tag 정보 조회는 이미 기술되어있으니, 2번 부터 시작하도록 하겠다.

 

2번의 Digest 정보 조회의 경우 Header 를 추가하여 조회를 하게된다.

vnd.docker -> 이걸로 오류가 난다면 vnd.oci 로 변경해서 실행시켜보도록 하자.

# Digest 조회
curl -i --header "Accept: application/vnd.docker.image.manifest.v1+json" \
http://localhost:5000/v2/{Image Name}/manifests/{Tag}

 

조회 이후 "layers" 안에 "digest" 를 참조하도록 하자.

우리가 필요한 부분은 sha256: 으로 시작하는 부분이다.

 

 

# Manifest 삭제
curl -X DELETE -v http://localhost:5000/v2/{Image}/manifests/{digest 값}

 

Manifest 정보를 삭제 한 이후에는 Docker Registry 내부의 GC 를 실행시키자.

docker exec -it docker_registry bin/registry garbage-collect /etc/docker/registry/config.yml

 

이후 Docker 재시작시 Image 에 대한 정보가 삭제되지만, 재시작 이후에도 삭제가 되어있지 않다면 물리 파일을 직접 삭제시키도록 하자.

해당글의 Compose 파일을 그대로 사용했다면, Docker 의 Data Path 와 연동되어있는 path 에서 Image 디렉토리를 찾아서 삭제시키면 된다.

 

위의 과정이 시간소모가 너무 되고 중간에 실수가 발생할 수도 있기때문에 쉘스크립트로 만들어서 사용중이다.

이미지명, 태그만 기입하면 물리파일까지 싹 삭제해주는 쉘스크립트이다.

 

 

Private 한 Docker Registry 가 생겼으니, 여기에 Jenkins, Gitlab Runner, Github Actions 등을 이용하여 자동배포 인프라를 구축하는데에 조금 더 수월해질 수 있을것 같다.