Prywatne repozytorium obrazów przeznaczonych dla Docker’a? Czym jest, dlaczego wypada je mieć oraz w jaki sposób je skonfigurować i zabezpieczyć? Zagadnienie to jest dość rozbudowane, ale musisz je rozumieć jeżeli planujesz certyfikację z Docker’a na poziomie DCA.
Krótki opis prywatnego repozytorium Docker
Przechodząc do rzeczy, prywatne repozytorium to kontener (a jakże), w którym możesz przy odpowiedniej konfiguracji oraz zabezpieczeniu przechowywać własne obrazy. W celu ułatwienia sobie pracy możesz skorzystać z gotowego rozwiązania, którym jest obraz registry:2. Warto również zadbać o bezpieczeństwo obrazów przechowywanych w repozytorium, w tym celu skonfigurujesz oparty o certyfikat dostęp do repozytorium. Ze względu na dość rozbudowane zagadnienie przewiduję dwa wpisy, które pozwolą skonfigurować takie środowisko.
Praktyczne zastosowanie prywatnego repozytorium
Na początek potrzebujesz mieć przygotowaną maszynę, która będzie pełniła funkcję magazynu. Idealnie, gdyby była to maszyna wirtualna, która nie będzie pełniła żadnej innej funkcji. Druga maszyna będzie stacją testową, również na niej potrzebny będzie Docker, który pomoże przy logowaniu zdalnym do repozytorium. Ja korzystam z chmury, w której generuję maszyny wirtualne. Ty możesz skorzystać z narzędzia Play with Docker, które pozwala za darmo generować środowisko dla Dockera. Pisałem o tym narzędziu na mojej stronie na facebook.com, we wpisie 01.02.2020. Jeżeli wolisz przygotować maszynę wirtualną lokalnie opis instalacji Dockera znajdziesz w tym wpisie.
Mając już przygotowane środowisko musisz uruchomić kontener oparty o obraz registry:2. Poniżej polecenie, przy pomocy którego uruchomisz taki kontener.
1 |
docker run -d -p 5000:5000 --restart=always --name registry registry:2 |
Kontener jest dość prosty, działa w trybie odłączenia (-d), otwarty zostanie port 5000 zarówno dla kontenera, jak i dostępu z zewnątrz (port 5000 jest domyślny dla obrazu registry:2), oczywiście po restarcie hosta kontener zostanie uruchomiony, nadasz również nazwę dla kontenera registry.
Jednak ostateczna konfiguracja będzie bardziej skomplikowana, więc na razie kontener możesz usunąć.
1 2 |
docker container stop registy docker container rm -v registry |
Kolejnym krokiem, który musisz wykonać jest przeciążenie (zamiana domyślnej wartości) zmiennej przy tworzeniu kontenera. Dla przećwiczenia zmienisz domyślny tryb logowania pracy kontenera. Domyślnie powinien pojawić się tryb info, natomiast musisz go zmienić na debug.
1 |
docker logs registry |

Następnie użyj nieco zmodyfikowanego polecenia do przeciążenia trybu pracy logera.
1 |
docker run -d -p 5000:5000 --restart=always --name registry -e REGISTRY_LOG_LEVEL=debug registry:2 |
Po ponownym użyciu
1 |
docker logs registry |
otrzymasz informację o zmianie trybu pracy logera.

Usuń również ten kontener, aby nie przeszkadzał w wykonaniu głównej części przygotowującej prywatny rejestr obrazów.
1 |
docker container stop registry |
1 |
docker container rm -v registry |
Wykonaj teraz kroki prowadzące do wygenerowania pliku htpasswd, w którym pojawi się testowy użytkownik oraz jego hasło. Do wykonania tych czynności potrzebujesz nowych katalogów oraz ponownie użycia registry:2
Utwórz katalogi, w których znajdzie się miejsce na utworzony plik z użytkownikiem.
1 |
mkdir -p ~/registry/auth |
1 |
cd ~/registry |
Sam plik utwórz przy pomocy obrazu registry:2. Użycie entrypoint, pozwala na uruchomienie htpasswd, które to wygeneruje hash hasła naszego użytkownika.
Jeżeli przy wykonaniu poniższego polecenia pojawi się następujący błąd:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused „exec: \”htpasswd\”: executable file not found in $PATH”: unknown.ERRO[0000] error waiting for container: context canceled
Należy uruchomić obraz nie registry: 2 ale registry: 2.7.0.
Sprawdzone na Centos 7.8 2003 oraz Docker 19.03.13.
1 |
docker run --entrypoint htpasswd registry:2 -Bbn testuser testuser_pass > auth/htpasswd |
Plik htpasswd powinien wyglądać mniej więcej jak poniżej.

Następnie w katalogu registry utwórz kolejny katalog o nazwie certs, w którym zapiszesz wygenerowany własny certyfikat. W trakcie generowania certyfikatu w polu Common Name koniecznie wpisz nazwę serwera lub jego adres ip (na którym pracujesz) wraz z jego domeną, np. privateregistry.com lub 192.168.0.1. Na serwerze (maszynie nr.1) uruchom polecenie echo „$HOSTNAME”, aby uzyskać nazwę tej maszyny lub ip addr w celu pozyskania adresu IP. Pozostałe pola pozostaw domyślnie puste, przechodząc przez nie przy użyciu Enter’a.
1 |
mkdir -p ~/registry/certs |
1 |
echo "HOSTNAME" lub ip addr |
1 |
openssl req -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key -x509 -days 365 -out certs/domain.crt |
Po zakończeniu wygenerowania certyfikatu w katalogu certs, pojawią się dwa pliki: domain.key oraz domain.crt
Ostatnim krokiem jest stworzenie kontenera, który będzie pełnił rolę prywatnego repozytorium obrazów Docker’a.
Tym razem portem, którego użyjesz będzie 443 (czyli port szyfrowany dla TLS), przełączniki -v generuje wolumen w kontenerze, w którym znajdą się wygenerowane pliki na maszynie lokalnej (hosta), czyli plik htpasswd oraz domain.crt oraz domain.key. Kolejny wiersz to nadpisanie zmiennej, która skonfiguruje nasłuch z zewnątrz kontenera, dzięki temu dostaniesz się do repozytorium z dowolnego adres IP wskazując port :443. Dalej wskażesz gdzie wewnątrz kontenera znajduje się certyfikat oraz klucz. Zdefiniujesz typ uwierzytelenienia jako htpasswd. Ostatnim punktem jest wskazanie pliku z danymi uwierzytelnienia testowego użytkownika, czyli /auth/htpasswd.
Uruchom kontener zatwierdzając polecenia poprzez Enter. Popraw ewentualnie ścieżki do plików, jeżeli nazwa twojego użytkownika w systemie jest inna niż user.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
docker run -d -p 443:443 --restart=always --name registry \ -v /home/user/registry/certs:/certs \ -v /home/user/registry/auth:/auth \ -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \ -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \ -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \ -e REGISTRY_AUTH=htpasswd \ -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \ -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ registry:2 |
W celu sprawdzenia czy kontener działa poprawnie użyj narzędzia curl, aby połączyć się z kontenerem. Przełącznik -k ignoruje sprawdzenie poprawności certyfikatu, ponieważ został on wygenerowany lokalnie i nie jest potwierdzony przez żaden urząd certyfikujący jako prawidłowy.
1 |
curl -k https://localhost:443 |
Polecenie nie powinno zwrócić żadnej wartości co będzie świadczyło o poprawności wykonanych kroków.
Zapraszam na kolejny wpis, w którym uruchomisz prywatne repozytorium, w którym umieścisz obraz.
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).
Niestety po wywołaniu docker run —entrypoint htpasswd registry:2 –Bbn testuser testuser_pass > auth/htpasswd
otrzymuję błąd:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused „exec: \”htpasswd\”: executable file not found in $PATH”: unknown.ERRO[0000] error waiting for container: context canceled
Co mam zrobić?
Dziekuję
Wersja systemu operacyjnego, wersja Dockera?
Zakualizowałem wpis, przyczyną błędu była wersja registry. Zamiast registry: 2 trzeba użyć registry: 2.7.0, wtedy plik htpasswd zostanie wygenerowany. Sprawdzone na Centos 7.8 (2003) oraz docker 19.03.13.
mam ten sam błąd
Docker version 19.03.13,
Zakualizowałem wpis, przyczyną błędu była wersja registry. Zamiast registry: 2 trzeba użyć registry: 2.7.0, wtedy plik htpasswd zostanie wygenerowany. Sprawdzone na Centos 7.8 (2003) oraz docker 19.03.13.