W sierpniu 2013 r. Jérôme Petazzoni stworzył Docker in Docker, co dindw skrócie pozwoliło na utworzenie kontenerów Docker wewnątrz kontenerów Docker, ta funkcja okazała się bardzo popularna, dzięki czemu repozytorium GitHub Jérôme'a otrzymało ponad tysiąc gwiazd i trzysta widelców.

Począwszy od wersji Docker 1.8, wydanej dwa lata później w sierpniu 2015 roku, Docker w Docker jest bezpośrednio obsługiwany przez Docker po wyjęciu z pudełka. Jednak użycie Dockera w Dockerze zawiera ostrzeżenie, najwyraźniej związane z postem Jérôme: Używanie Docker-in-Docker dla twojego CI lub środowiska testowego? Pomyśl dwa razy. który koncentruje się na powodach, dla których Docker in Docker nie jest doskonałym wyborem do ciągłej integracji.

Dlaczego używanie Dockera w Dockerze jest uważane za złe? Czy to po prostu przypadek, by unikać Żółwi aż do samego końca? lub względy wydajności?

Obawy dotyczące ciągłej integracji

W skrócie: Docker in Docker (dind) nie obsługuje dobrze współbieżności.

Powodem, dla którego nie powinieneś używać dind dla CI, jest to, że Docker został zaprojektowany tak, aby mieć wyłączny dostęp do katalogu, którego używa do przechowywania (zwykle /var/lib/docker). Dind nie przestrzega tego, ponieważ wszystkie procesy potomne korzystają z tego katalogu jednocześnie. Za każdym razem, gdy przebudowujesz (na przykład z CI), wszystko związane z twoją aplikacją w tym katalogu może zostać usunięte i zmuszone do uruchomienia od zera. Jakim użytkownikom podobałoby się to, gdyby wprowadzili szczegóły płatności, kliknęli „Kup” i nagle znaleźli się z powrotem na ekranie logowania, jakby nigdy nic nie zrobili? To po prostu nie jest dobry UX. Dwie odbudowy występują jednocześnie? To naprawdę źle skończy się dla wszystkich zaangażowanych (w tym integralności danych).

Inne obawy

Z linku opublikowanego przez PO powstają obawy związane z bezpieczeństwem, ponieważ system będzie próbował zastosować zasady bezpieczeństwa w sposób bardzo „podobny do CSS”, w którym niższy pojemnik może mieć dostęp do zasobów zewnętrznego pojemnika, chyba że jest to wyraźnie zabronione. Pamiętasz, kiedy możesz uzyskać dostęp do zasobów serwera WWW, robiąc coś takiego jak „mywebsite.com/../another_folder/private_resource.txt”? Czasami systemy plików po prostu nie działają ze sobą dobrze, gdy są zagnieżdżone w ten sposób.

Poprawka

Na szczęście post na blogu w PO ma dobre rozwiązanie tego problemu. O ile twoje potrzeby nie są zaspokojone przez „budowanie / uruchamianie / wypychanie kontenerów Docker z samego systemu CI działającego na Docker”, możesz użyć -vtrybu (dodaj wolumin danych do kontenera) na gnieździe Docker (zwykle /var/run/docker.sock:/var/run/docker.sock), aby umożliwić rodzaj potrzebujesz dostępu do „udostępnionego” woluminu danych. Kontenery te zostaną uruchomione razem z rodzicem, a nie pod nim, wymuszając synchroniczne we / wy. Teraz masz to samo (prawie) jak dind, ale bez wad, które wynikają z tego, że Docker nie jest budowany dla współbieżności.

Odniesienia (z OP): Używasz Docker-in-Docker dla swojego CI lub środowiska testowego? Pomyśl dwa razy.