Docker hub 등의 Public registry를 사용하지 않고, 별도 private registry를 구축해 실제 운영 환경에 사용하는 경우가 있다. 대규모의 클러스터 운영 환경일수록 registry는 컨테이너로 기동되는 서비스의 빌드 및 배포에 매우 중요한 역할을 하기에 가용성 및 안정성에 압박을 받게 될 것이다.
Registry를 이중화 하는 것은 일반적인 DB이중화에 비해 간단하다. docker docs에서 기술하고 있는 다음 3가지만 지켜주면 된다.
The most important aspect is that a load balanced cluster of registries must share the same resources. For the current version of the registry, this means the following must be the same:
- Storage Driver
- HTTP Secret
- Redis Cache (if configured)
Registry 인스턴스를 2개 올리고 이를 load balanc한다고 할때, 각 Registry 인스턴스는 다음 3가지를 동일하게 유지해야 한다.
1. Storage driver (file system이던 S3건..)를 같은 곳을 바라보게 한다.
2중화를 하건 3중화를 하건 실제 물리 데이터가 저장될 장소는 동일해야 한다. 이게 일반적인 RDB와 다른 점인데, DB의 경우에는 애초에 하나의 스토리지는 하나의 인스턴스밖에 바라보지 못한다. 이미 하나의 DB인스턴스가 물고 있는 스토리지를 다른 인스턴스가 물고 뜰 수가 없다.
반면, Docker registry의 경우 몇 개의 인스턴스라도 하나의 스토리지를 바라보고 실행될 수 있으며, 이중화를 위해서는 이렇게 구성 해야한다.
2. 동일한 HTTP Secret을 준다.
이부분을 놓치는 바람에 고생을 많이 했는데.. registry의 config.yaml파일이나 환경변수에 REGISTRY_HTTP_SECRET 값으로 secret을 줄 수 있다. 만약 시크릿을 별도로 설정하지 않는다면, Registry 인스턴스가 처음 시작될 때 임의의 값을 생성해서 실행한다. 이 경우에 이중화된 각각의 Registry 인스턴스는 secret 값이 다르기 때문에 docker는 이 두 인스턴스가 유효한 하나의 서비스가 아니라고 판단해서 pull / push 등의 작업이 정상적으로 되지 않는다.
따라서 config.yaml의 http.secret에 문자열로 된 시크릿을 설정해 주거나, REGISTRY_HTTP_SECRET 환경변수로 시크릿 값을 모든 인스턴스에 동일하게 설정해야 한다.
3. Redis cache
docker registry는 registry에 저장된 이미지의 layer metadata 캐시를 위해 inmemory와 redis를 지원한다. inmemory로 설정할 경우 해당 registry 인스턴스의 로컬 inmemory를 캐시 저장소로 사용하고, redis로 설정할 경우 별도의 redis 서버를 캐시 서버로 연결해 줘야 한다.
registry를 이중화 하는 경우에 캐시를 inmemory로 하게되면 각 인스턴스가 캐싱하고 있는 정보가 다르기 때문에 정상적으로 사용이 불가능하다. 반드시 별도의 redis 서버를 두고 모든 registry 인스턴스가 동일한 redis에 연결되어야 한다.
