Proponuję przeczytać transkrypcję raportu Alexandra Sigaczowa z Inventos „Development and testing process with Docker + Gitlab CI”
Ci, którzy dopiero zaczynają wdrażać proces developmentu i testowania w oparciu o Docker + Gitlab CI często zadają podstawowe pytania. Gdzie zacząć? Jak zorganizować? Jak przetestować?
Ten raport jest dobry, ponieważ w uporządkowany sposób mówi o procesie programowania i testowania przy użyciu Dockera i Gitlab CI. Sam raport pochodzi z 2017 roku. Myślę, że z tego raportu można poznać podstawy, metodologię, ideę, doświadczenie użytkowania.
Kogo to obchodzi, proszę pod kotem.
Nazywam się Aleksander Sigaczow. Pracuję w Inventos. Opowiem o moich doświadczeniach z używaniem Dockera i jak sukcesywnie wdrażamy go na projektach w firmie.
Temat prezentacji: Proces deweloperski z wykorzystaniem Dockera i Gitlab CI.
To moja druga rozmowa o Dockerze. W czasie tworzenia pierwszego raportu używaliśmy Dockera w fazie rozwoju tylko na komputerach deweloperskich. Liczba pracowników korzystających z Dockera wynosiła około 2-3 osób. Stopniowo zdobywaliśmy doświadczenie i posuwaliśmy się trochę dalej. Link do naszego .
Co będzie w tym raporcie? Podzielimy się naszymi doświadczeniami na temat tego, jaki rake zebraliśmy, jakie problemy rozwiązaliśmy. Nie wszędzie było pięknie, ale pozwolono ruszyć dalej.
Nasze motto brzmi: dokuj wszystko, co wpadnie nam w ręce.
Jakie problemy rozwiązujemy?
Gdy w firmie jest kilka zespołów, programista jest zasobem współdzielonym. Są etapy, kiedy programista jest wyciągany z jednego projektu i oddawany na jakiś czas do innego projektu.
Aby programista szybko zrozumiał, musi pobrać kod źródłowy projektu i jak najszybciej uruchomić środowisko, które pozwoli mu przejść dalej rozwiązując problemy tego projektu.
Zwykle, jeśli zaczynasz od zera, w projekcie jest niewiele dokumentacji. Informacje o tym, jak skonfigurować, są dostępne tylko dla starych wyjadaczy. Pracownicy sami organizują swoje miejsce pracy w ciągu jednego lub dwóch dni. Aby to przyspieszyć, użyliśmy Dockera.
Kolejnym powodem jest standaryzacja ustawień w Development. Z mojego doświadczenia wynika, że programiści zawsze przejmują inicjatywę. W co piątym przypadku wpisywana jest niestandardowa domena, na przykład vasya.dev. Obok niego siedzi jego sąsiad Petya, którego domeną jest petya.dev. Opracowują stronę internetową lub jakiś komponent systemu używając tej nazwy domeny.
Kiedy system się rozrasta i te nazwy domen zaczynają wchodzić w konfiguracje, powstaje konflikt środowiska programistycznego i ścieżka witryny jest przepisywana.
To samo dzieje się z ustawieniami bazy danych. Ktoś nie przejmuje się bezpieczeństwem i pracuje z pustym hasłem roota. Na etapie instalacji MySQL poprosił kogoś o hasło i okazało się, że to 123. Często zdarza się, że konfiguracja bazy danych ciągle się zmienia w zależności od zaangażowania programisty. Ktoś poprawił, ktoś nie poprawił konfiguracji. Były sztuczki, kiedy wyjmowaliśmy jakąś konfigurację testową .gitignore i każdy programista musiał zainstalować bazę danych. Utrudniało to rozpoczęcie pracy. Należy pamiętać między innymi o bazie danych. Należy zainicjować bazę danych, wprowadzić hasło, zarejestrować użytkownika, utworzyć tabelę i tak dalej.
Innym problemem są różne wersje bibliotek. Często zdarza się, że programista pracuje nad różnymi projektami. Istnieje projekt Legacy, który rozpoczął się pięć lat temu (od 2017 r. – przyp. red.). W momencie uruchomienia zaczynaliśmy od MySQL 5.5. Są też nowoczesne projekty, w których staramy się wdrażać nowsze wersje MySQL, np. 5.7 lub starsze (w 2017 r. – przyp. red.)
Każdy, kto pracuje z MySQL, wie, że te biblioteki niosą ze sobą zależności. Prowadzenie 2 baz razem jest dość problematyczne. Przynajmniej starzy klienci mają problem z połączeniem z nową bazą danych. To z kolei stwarza kilka problemów.
Kolejnym problemem jest to, że gdy programista pracuje na lokalnej maszynie, wykorzystuje lokalne zasoby, lokalne pliki, lokalną pamięć RAM. Cała interakcja w czasie opracowywania rozwiązania problemów odbywa się w ramach tego, że działa na jednej maszynie. Przykładem jest sytuacja, gdy mamy serwery zaplecza w Production 3, a programista zapisuje pliki do katalogu głównego, a stamtąd nginx pobiera pliki, aby odpowiedzieć na żądanie. Gdy taki kod dostanie się do Produkcji, okazuje się, że plik znajduje się na jednym z 3 serwerów.
Obecnie rozwija się kierunek mikroserwisów. Kiedy dzielimy nasze duże aplikacje na kilka małych komponentów, które wchodzą ze sobą w interakcje. Pozwala to na wybór technologii dla określonego stosu zadań. Pozwala także dzielić pracę i obowiązki między programistami.
Frondend-developer, rozwijający się w JS, nie ma prawie żadnego wpływu na Backend. Backend developer z kolei rozwija w naszym przypadku Ruby on Rails i nie ingeruje we Frondend. Interakcja odbywa się za pomocą API.
Jako bonus, z pomocą Dockera, byliśmy w stanie przetworzyć zasoby na Stagingu. Każdy projekt, ze względu na swoją specyfikę, wymagał określonych ustawień. Fizycznie konieczne było przydzielenie serwera wirtualnego i skonfigurowanie ich osobno lub udostępnienie pewnego rodzaju zmiennego środowiska, a projekty mogły, w zależności od wersji bibliotek, wpływać na siebie.
Narzędzia. Czego używamy?
- samego Dockera. Dockerfile opisuje zależności pojedynczej aplikacji.
- Docker-compose to pakiet łączący kilka naszych aplikacji Docker.
- Używamy GitLab do przechowywania kodu źródłowego.
- Do integracji systemów używamy GitLab-CI.
Raport składa się z dwóch części.
Pierwsza część opowie o tym, jak Docker działał na maszynach programistów.
W drugiej części porozmawiamy o tym, jak wchodzić w interakcje z GitLabem, jak przeprowadzamy testy i jak wprowadzamy do Stagingu.
Docker to technologia, która pozwala (w podejściu deklaratywnym) opisać niezbędne komponenty. To jest przykład pliku Docker. Tutaj deklarujemy, że dziedziczymy z oficjalnego obrazu Ruby:2.3.0 Docker. Zawiera zainstalowaną wersję Ruby 2.3. Instalujemy wymagane biblioteki kompilacji i NodeJS. Opisujemy, że tworzymy katalog /app. Ustaw katalog aplikacji jako katalog roboczy. W tym katalogu umieszczamy wymagane minimalne pliki Gemfile i Gemfile.lock. Następnie budujemy projekty, które instalują ten obraz zależności. Wskazujemy, że kontener będzie gotowy do nasłuchiwania na porcie zewnętrznym 3000. Ostatnia komenda to komenda, która bezpośrednio uruchamia naszą aplikację. Jeśli wykonamy polecenie uruchomienia projektu, aplikacja spróbuje uruchomić i uruchomić określone polecenie.
To jest minimalny przykład pliku do tworzenia dokerów. W tym przypadku pokazujemy, że istnieje połączenie między dwoma kontenerami. Jest to bezpośrednio do usługi bazy danych i usługi internetowej. Nasze aplikacje internetowe w większości przypadków wymagają pewnego rodzaju bazy danych jako zaplecza do przechowywania danych. Ponieważ używamy MySQL, przykładem jest MySQL - ale nic nie stoi na przeszkodzie, aby użyć innej bazy danych (PostgreSQL, Redis).
Pobieramy z oficjalnego źródła z huba Docker obraz MySQL 5.7.14 bez zmian. Z bieżącego katalogu pobieramy obraz odpowiedzialny za naszą aplikację internetową. Zbiera dla nas obraz podczas pierwszego uruchomienia. Następnie uruchamia polecenie, które tutaj wykonujemy. Jeśli wrócimy, zobaczymy, że polecenie uruchomienia przez Pumę zostało zdefiniowane. Puma to usługa napisana w języku Ruby. W drugim przypadku nadpisujemy. To polecenie może być dowolne w zależności od naszych potrzeb lub zadań.
Opisujemy również, że musimy przekierować port na naszym komputerze hosta programisty z 3000 na 3000 na porcie kontenera. Odbywa się to automatycznie za pomocą iptables i jego mechanizmu, który jest bezpośrednio osadzony w Dockerze.
Deweloper może również, tak jak poprzednio, uzyskać dostęp do dowolnego dostępnego adresu IP, na przykład 127.0.0.1 to lokalny lub zewnętrzny adres IP maszyny.
Ostatni wiersz mówi, że kontener WWW jest zależny od kontenera db. Gdy wywołamy początek kontenera WWW, docker-compose najpierw uruchomi dla nas bazę danych. Już na starcie bazy danych (a właściwie już po uruchomieniu kontenera! Nie gwarantuje to gotowości bazy danych) uruchomi się aplikacja, czyli nasz backend.
Pozwala to uniknąć błędów, gdy baza danych nie jest wywoływana i oszczędza zasoby, gdy zatrzymujemy kontener bazy danych, uwalniając w ten sposób zasoby dla innych projektów.
Co daje nam zastosowanie dokeryzacji bazy danych w projekcie. Naprawiamy wersję MySQL dla wszystkich programistów. Pozwala to uniknąć niektórych błędów, które mogą wystąpić, gdy wersje różnią się, gdy zmienia się składnia, konfiguracja, ustawienia domyślne. Pozwala to na określenie wspólnej nazwy hosta dla bazy danych, loginu, hasła. Odchodzimy od zoo nazw i konfliktów w plikach konfiguracyjnych, które mieliśmy wcześniej.
Mamy możliwość zastosowania bardziej optymalnej konfiguracji dla środowiska deweloperskiego, która będzie różnić się od domyślnej. MySQL jest domyślnie skonfigurowany dla słabych maszyn, a jego wydajność po wyjęciu z pudełka jest bardzo słaba.
Docker pozwala na użycie interpretera Pythona, Ruby, NodeJS, PHP wybranej wersji. Pozbywamy się konieczności korzystania z jakiegoś menedżera wersji. Wcześniej Ruby używał pakietu rpm, który pozwalał na zmianę wersji w zależności od projektu. Pozwala również, dzięki kontenerowi Docker, na płynną migrację kodu i wersjonowanie go wraz z zależnościami. Nie mamy problemu ze zrozumieniem wersji zarówno interpretera, jak i kodu. Aby zaktualizować wersję, opuść stary kontener i podnieś nowy. Jeśli coś poszło nie tak, możemy opuścić nowy kontener, podnieść stary kontener.
Po zbudowaniu obrazu kontenery zarówno w fazie rozwoju, jak i produkcji będą takie same. Dotyczy to zwłaszcza dużych instalacji.
Na Frontendzie używamy JavaScipt i NodeJS.
Teraz mamy ostatni projekt w ReacJS. Deweloper uruchomił wszystko w kontenerze i opracował za pomocą przeładowania na gorąco.
Następnie uruchamiane jest zadanie asemblera JavaScipt, a kod skompilowany do statyki jest przekazywany za pośrednictwem zasobów zapisujących nginx.
Tutaj podałem schemat naszego ostatniego projektu.
Jakie zadania zostały rozwiązane? Mieliśmy potrzebę zbudowania systemu, z którym współpracują urządzenia mobilne. Otrzymują dane. Jedną z możliwości jest wysyłanie powiadomień push na to urządzenie.
Co zrobiliśmy w tym celu?
Na aplikację podzieliliśmy takie komponenty jak: część administracyjna na JS, backend, który działa poprzez interfejs REST pod Ruby on Rails. Backend współpracuje z bazą danych. Wygenerowany wynik jest przekazywany klientowi. Panel administracyjny współpracuje z backendem i bazą danych poprzez interfejs REST.
Mieliśmy również potrzebę wysyłania powiadomień push. Wcześniej mieliśmy projekt, który zaimplementował mechanizm odpowiedzialny za dostarczanie powiadomień na platformy mobilne.
Opracowaliśmy następujący schemat: operator z przeglądarki wchodzi w interakcję z panelem administracyjnym, panel administracyjny wchodzi w interakcję z backendem, zadaniem jest wysyłanie powiadomień Push.
Powiadomienia push wchodzą w interakcję z innym komponentem zaimplementowanym w NodeJS.
Budowane są kolejki, a następnie wysyłane są powiadomienia zgodnie z ich mechanizmem.
Tutaj rysowane są dwie bazy danych. W tej chwili z pomocą Dockera korzystamy z 2 niezależnych baz danych, które nie są ze sobą w żaden sposób powiązane. Ponadto mają wspólną sieć wirtualną, a dane fizyczne są przechowywane w różnych katalogach na maszynie programisty.
To samo, ale w liczbach. W tym miejscu ważne jest ponowne użycie kodu.
Jeśli wcześniej mówiliśmy o ponownym wykorzystaniu kodu w postaci bibliotek, to w tym przykładzie nasz serwis odpowiadający na powiadomienia Push jest ponownie wykorzystywany jako kompletny serwer. Zapewnia interfejs API. A nasz nowy projekt już z nim współdziała.
W tym czasie korzystaliśmy z wersji 4 NodeJS. Teraz (w 2017 r. - przyp. red.) w ostatnich opracowaniach używamy wersji 7 NodeJS. Nie ma problemu, aby nowe komponenty obejmowały nowe wersje bibliotek.
W razie potrzeby możesz refaktoryzować i podnosić wersję NodeJS z usługi powiadomień Push.
A jeśli uda nam się zachować kompatybilność API, to możliwe będzie zastąpienie go innymi projektami, które były wcześniej używane.
Co jest potrzebne do dodania Dockera? Do naszego repozytorium dodajemy Dockerfile, który opisuje niezbędne zależności. W tym przykładzie komponenty są podzielone logicznie. Jest to minimalny zestaw programisty backendu.
Tworząc nowy projekt tworzymy Dockerfile, opisujemy pożądany ekosystem (Python, Ruby, NodeJS). W docker-compose opisuje niezbędną zależność - bazę danych. Opisujemy, że potrzebujemy bazy danych takiej a takiej wersji, przechowujemy dane tam i tam.
Używamy osobnego trzeciego kontenera z nginx do obsługi statycznej. Istnieje możliwość wgrania zdjęć. Backend umieszcza je we wcześniej przygotowanym wolumenie, który jest również montowany w kontenerze z nginxem, co daje static.
Aby przechowywać konfigurację nginx, mysql, dodaliśmy folder Docker, w którym przechowujemy niezbędne konfiguracje. Kiedy programista robi klon repozytorium w git na swojej maszynie, ma już gotowy projekt do lokalnego rozwoju. Nie ma wątpliwości, jaki port lub jakie ustawienia zastosować.
Dalej mamy kilka komponentów: admin, inform-API, powiadomienia push.
Aby to wszystko rozpocząć, stworzyliśmy kolejne repozytorium, które nazwaliśmy dockerized-app. W tej chwili używamy kilku repozytoriów przed każdym komponentem. Są po prostu logicznie różne - w GitLab wygląda to jak folder, ale na maszynie programisty folder dla konkretnego projektu. Poziom niżej to komponenty, które zostaną połączone.
To jest przykład samej zawartości pliku dockerized-app. Wprowadzamy tutaj również katalog Docker, w którym wypełniamy konfiguracje wymagane do interakcji wszystkich komponentów. Istnieje plik README.md, który krótko opisuje, jak uruchomić projekt.
Tutaj zastosowaliśmy dwa pliki tworzenia dokerów. Odbywa się to, aby móc biegać krokami. Kiedy programista pracuje z rdzeniem, nie potrzebuje powiadomień push, po prostu uruchamia plik docker-compose i odpowiednio zasób jest zapisywany.
Jeśli zachodzi potrzeba integracji z powiadomieniami push, to uruchamiane są docker-compose.yaml oraz docker-compose-push.yaml.
Ponieważ docker-compose.yaml i docker-compose-push.yaml znajdują się w folderze, pojedyncza sieć wirtualna jest tworzona automatycznie.
Opis komponentów. Jest to bardziej zaawansowany plik, który odpowiada za zbieranie komponentów. Co jest tutaj niezwykłego? Tutaj przedstawiamy komponent balansera.
Jest to gotowy obraz Dockera, który uruchamia nginx i aplikację nasłuchującą na gnieździe Dockera. Dynamiczny, ponieważ kontenery są włączane i wyłączane, regeneruje konfigurację nginx. Dystrybuujemy obsługę komponentów według nazw domen trzeciego poziomu.
Dla środowiska Developerskiego używamy domeny .dev - api.informer.dev. Aplikacje z domeną .dev są dostępne na lokalnym komputerze programisty.
Ponadto konfiguracje są przenoszone do każdego projektu i wszystkie projekty są uruchamiane razem w tym samym czasie.
Graficznie okazuje się, że klientem jest nasza przeglądarka lub jakieś narzędzie, za pomocą którego wykonujemy żądania do balancera.
System równoważenia nazw domen określa, z którym kontenerem należy się skontaktować.
Może to być nginx, który daje administratorowi JS. Może to być nginx, który udostępnia API, lub pliki statyczne, które są przekazywane do nginx w postaci przesłanych obrazów.
Diagram pokazuje, że kontenery są połączone siecią wirtualną i ukryte za serwerem proxy.
Na maszynie programisty można uzyskać dostęp do kontenera znając adres IP, ale w zasadzie tego nie używamy. Praktycznie nie ma potrzeby bezpośredniego dostępu.
Na który przykład spojrzeć, aby zdokować aplikację? Moim zdaniem dobrym przykładem jest oficjalny obraz dokera dla MySQL.
To dość trudne. Istnieje wiele wersji. Ale jego funkcjonalność pozwala na zaspokojenie wielu potrzeb, które mogą pojawić się w procesie dalszego rozwoju. Jeśli poświęcisz czas i dowiesz się, jak to wszystko współgra, myślę, że nie będziesz miał problemów z samodzielną realizacją.
Hub.docker.com zwykle zawiera linki do github.com, który zawiera surowe dane bezpośrednio z których możesz samodzielnie zbudować obraz.
Dalej w tym repozytorium znajduje się skrypt docker-endpoint.sh, który odpowiada za wstępną inicjalizację i dalsze przetwarzanie uruchamiania aplikacji.
Również w tym przykładzie istnieje możliwość konfiguracji przy użyciu zmiennych środowiskowych. Definiując zmienną środowiskową podczas uruchamiania pojedynczego kontenera lub za pomocą docker-compose, możemy powiedzieć, że musimy ustawić puste hasło, aby docker mógł zrootować MySQL lub cokolwiek zechcemy.
Istnieje możliwość stworzenia losowego hasła. Mówimy, że potrzebujemy użytkownika, musimy ustawić hasło dla użytkownika i musimy utworzyć bazę danych.
W naszych projektach ujednoliciliśmy nieco plik Dockerfile, który odpowiada za inicjalizację. Tam poprawiliśmy go na nasze potrzeby, aby był tylko rozszerzeniem uprawnień użytkownika, z których korzysta aplikacja. Pozwoliło nam to później po prostu utworzyć bazę danych z poziomu konsoli aplikacji. Aplikacje Ruby mają polecenia do tworzenia, modyfikowania i usuwania baz danych.
To jest przykład tego, jak wygląda konkretna wersja MySQL na github.com. Możesz otworzyć plik Dockerfile i zobaczyć, jak przebiega tam instalacja.
docker-endpoint.sh to skrypt odpowiedzialny za punkt wejścia. Podczas początkowej inicjalizacji wymagane są pewne kroki przygotowawcze, a wszystkie te działania są wykonywane tylko w skrypcie inicjującym.
Przejdźmy do drugiej części.
Aby przechowywać kody źródłowe, przeszliśmy na gitlab. Jest to dość potężny system, który ma interfejs wizualny.
Jednym z komponentów Gitlab jest Gitlab CI. Pozwala opisać sekwencję poleceń, które później posłużą do zorganizowania systemu dostarczania kodu lub uruchomienia testów automatycznych.
Dyskusja na temat Gitlab CI 2 - relacja z klubu Ruby Russia - dość szczegółowa i być może Was zainteresuje.
Teraz przyjrzymy się, co jest wymagane, aby aktywować Gitlab CI. Aby uruchomić Gitlab CI wystarczy umieścić plik .gitlab-ci.yml w katalogu głównym projektu.
Tutaj opisujemy, że chcemy wykonać sekwencję stanów, takich jak test, wdrożenie.
Wykonujemy skrypty, które bezpośrednio wywołują docker-compose w celu zbudowania naszej aplikacji. To tylko przykład z backendu.
Następnie mówimy, że konieczne jest przeprowadzenie migracji w celu zmiany bazy danych i przeprowadzenia testów.
Jeśli skrypty zostaną wykonane poprawnie i nie zwrócą kodu błędu, system przechodzi do drugiego etapu wdrożenia.
Etap wdrażania jest obecnie zaimplementowany na potrzeby przemieszczania. Nie zorganizowaliśmy restartu bez przestojów.
Siłą gasimy wszystkie pojemniki, a następnie ponownie podnosimy wszystkie pojemniki zebrane w pierwszym etapie podczas testów.
Uruchamiamy dla bieżącej zmiennej środowiskowej migracje bazy danych, które zostały napisane przez programistów.
Jest uwaga, że dotyczy to tylko gałęzi master.
Podczas zmiany innych gałęzi nie jest wykonywana.
Istnieje możliwość organizacji rolloutów według oddziałów.
Aby to dalej zorganizować, musimy zainstalować Gitlab Runner.
To narzędzie jest napisane w Golang. Jest to pojedynczy plik, jak to zwykle bywa w świecie Golanga, który nie wymaga żadnych zależności.
Podczas uruchamiania rejestrujemy Gitlab Runner.
Klucz dostajemy w interfejsie webowym Gitlab.
Następnie wywołujemy polecenie inicjalizacji w wierszu poleceń.
Skonfiguruj interaktywnie Gitlab Runner (Shell, Docker, VirtualBox, SSH)
Kod w Gitlab Runner będzie wykonywany przy każdym zatwierdzeniu, w zależności od ustawienia .gitlab-ci.yml.
Jak to wygląda wizualnie w Gitlabie w interfejsie webowym. Po podłączeniu GItlab CI mamy flagę, która pokazuje aktualny stan kompilacji.
Widzimy, że 4 minuty temu dokonano zatwierdzenia, które przeszło wszystkie testy i nie spowodowało żadnych problemów.
Możemy przyjrzeć się bliżej budynkom. Tutaj widzimy, że minęły już dwa stany. Stan testowania i stan wdrożenia podczas przemieszczania.
Jeśli klikniemy na konkretną kompilację, pojawi się wyjście konsoli poleceń, które zostały uruchomione w procesie zgodnie z .gitlab-ci.yml.
Tak wygląda historia naszych produktów. Widzimy, że próby były udane. Po przesłaniu testów nie przechodzi do następnego kroku, a kod przemieszczania nie jest aktualizowany.
Jakie zadania rozwiązaliśmy na etapie inscenizacji, kiedy wdrożyliśmy dockera? Nasz system składa się z komponentów i musieliśmy zrestartować tylko część komponentów, które zostały zaktualizowane w repozytorium, a nie cały system.
Aby to zrobić, musieliśmy rozbić wszystko do osobnych folderów.
Po zrobieniu tego mieliśmy problem z tym, że Docker-compose tworzy własną przestrzeń sieciową dla każdego tatusia i nie widzi komponentów sąsiada.
Aby się obejść, stworzyliśmy sieć w Dockerze ręcznie. Napisano w Docker-compose, że używasz takiej sieci do tego projektu.
W ten sposób każdy komponent rozpoczynający się od tej siatki widzi komponenty w innych częściach systemu.
Następną kwestią jest podział etapów na wiele projektów.
Ponieważ aby to wszystko wyglądało pięknie i jak najbardziej zbliżone do produkcyjnego, dobrze jest użyć portu 80 lub 443, który jest używany wszędzie w WEBIE.
Jak to rozwiązaliśmy? Do wszystkich większych projektów przypisaliśmy jednego Gitlab Runnera.
Gitlab pozwala uruchomić kilka rozproszonych Gitlab Runners, które po prostu wykonają wszystkie zadania po kolei w chaotyczny sposób i uruchomią je.
Żeby nie mieć domu ograniczyliśmy grupę naszych projektów do jednego Gitlab Runnera, który bez problemu radzi sobie z naszymi wolumenami.
Przenieśliśmy nginx-proxy do osobnego skryptu startowego i dodaliśmy siatki dla wszystkich projektów w nim zawartych.
Nasz projekt ma jedną siatkę, a balancer ma kilka siatek według nazw projektów. Może dalej pośredniczyć według nazw domen.
Nasze żądania przechodzą przez domenę na porcie 80 i są rozdzielane na grupę kontenerów obsługującą tę domenę.
Jakie były inne problemy? To właśnie domyślnie wszystkie kontenery działają jako root. To jest root nierówne hostowi root systemu.
Jeśli jednak wejdziesz do kontenera, będzie to root, a plik, który utworzymy w tym kontenerze, otrzyma prawa roota.
Jeśli programista wszedł do kontenera i wykonał tam jakieś polecenia generujące pliki, a następnie opuścił kontener, to ma w swoim katalogu roboczym plik, do którego nie ma dostępu.
Jak to rozwiązać? Możesz dodać użytkowników, którzy będą w kontenerze.
Jakie problemy pojawiły się, gdy dodaliśmy użytkownika?
Podczas tworzenia użytkownika często nie mamy tego samego identyfikatora grupy (UID) i identyfikatora użytkownika (GID).
Aby rozwiązać ten problem w kontenerze używamy użytkowników o ID 1000.
W naszym przypadku zbiegło się to z faktem, że prawie wszyscy programiści korzystają z systemu operacyjnego Ubuntu. W systemie Ubuntu pierwszy użytkownik ma identyfikator 1000.
Czy mamy plany?
Przeczytaj dokumentację Dockera. Projekt aktywnie się rozwija, zmienia się dokumentacja. Dane, które otrzymano dwa, trzy miesiące temu, już powoli się dezaktualizują.
Niektóre problemy, które rozwiązaliśmy, prawdopodobnie zostały już rozwiązane za pomocą standardowych środków.
Więc chcę już iść dalej, aby przejść bezpośrednio do orkiestracji.
Jednym z przykładów jest wbudowany mechanizm Dockera o nazwie Docker Swarm, który wychodzi z pudełka. Chcę uruchomić coś produkcyjnego w oparciu o technologię Docker Swarm.
Spawning kontenerów sprawia, że praca z dziennikami jest niewygodna. Teraz logi są izolowane. Są rozrzucone po pojemnikach. Jednym z zadań jest umożliwienie wygodnego dostępu do logów poprzez interfejs webowy.
Źródło: www.habr.com