Riot Games

w tym pierwszym samouczku z serii Docker dowiesz się:

• co staramy się osiągnąć W Riot

• podstawowa konfiguracja Dockera

• podstawowe polecenia docker Pull

• jak uruchamiać kontenery Docker jako demony

• podstawowe opcje konfiguracji Jenkins

kiedy rok temu zacząłem uczyć się o Dockerze i eksplorować jego użycie, miałem problem ze znalezieniem świetnej dokumentacji i przykładów – nawet dzisiaj wiele opisuje proste przypadki użycia, które ostatecznie nie są gotowe do produkcji. Tworzenie aplikacji za pomocą kontenerów Docker wymaga dostosowania ich efemerycznego charakteru i skupienia na jednym procesie. Stwarza to wyzwania dla aplikacji wymagających trwałości danych lub architektur wieloprocesowych.

jak wspomniałem w moim ostatnim poście, używamy Jenkinsa jako fundamentalnego oprogramowania open source, na którym budujemy naszą automatyzację. Jenkins jest również świetną aplikacją, aby zademonstrować jeden sposób myślenia o „dokowaniu” aplikacji. Wdrażamy Jenkins z myślą o tych komponentach architektonicznych:

• Jenkins master server (proces Java)

• Dane podstawowe Jenkins (wtyczki, definicje zadań itp)

• Nginx web proxy (używamy certyfikatów SSL itp., z NGINX jest łatwym wyborem tutaj)

• budowanie agentów slave (maszyny będące SSH ’ d do lub łączące się z JNLP, Jenkins Master)

to dobry początek. W tej serii postów na blogu omówię sposoby myślenia o wszystkich powyższych kontenerach i zakończę zaawansowanym spojrzeniem na sposoby używania kontenerów Docker jako niewolników budowania. Na początek stworzymy główny serwer Jenkins w kontenerze Docker. Następnie przejdziemy do radzenia sobie z trwałością danych i dodaniem serwera proxy z NGINX.

cała ta seria blogów obejmie następujące koncepcje Dockera:

• tworzenie własnych plików dokujących

• minimalizacja zależności obrazu od obrazów publicznych

• Tworzenie i używanie woluminów danych, w tym kopii zapasowych

• Tworzenie kontenerowych „środowisk budowania” przy użyciu kontenerów

• Obsługa „tajnych” danych za pomocą obrazów i Jenkins

jeśli nie przyjrzałeś się obrazowi Cloudbees Jenkins Docker, zacznij od niego, ponieważ jest naprawdę całkiem dobry. To był mój punkt odniesienia, kiedy po raz pierwszy myślałem o uruchomieniu Jenkinsa w kontenerze Docker i dla wielu osób może to być wystarczające. Ich dokumentację można znaleźć tutaj, a plik repo/Dockerfile Git tutaj.

ten pierwszy blog jest podzielony na dwa plany lekcji. Każdy rozmiar zajmuje około 30 minut. Po pierwsze, część pierwsza to przygotowanie środowiska programistycznego i nauka pracy z domyślnym kontenerem Docker Jenkins, który oferuje Cloudbees. Część druga dotyczy stworzenia podstaw do zawinięcia tego obrazu we własnym pliku Dockerfile i uzyskania bardziej eleganckiej kontroli nad obrazem. Są one zaprojektowane tak, aby umożliwić Ci rozpoczęcie pracy, zwłaszcza jeśli nigdy wcześniej nie pracowałeś z Dockerem lub jesteś stosunkowo nowy w Dockerze—chociaż zakładają, że już wiesz i rozumiesz, jak pracować z Jenkinsem. Jeśli masz doświadczenie z Dockerem, część materiału z lekcji 1 będzie nieco powtórzeniem rzeczy, które prawdopodobnie już znasz.

Lekcja 1: Skonfiguruj i uruchom swój pierwszy obraz

przygotujmy Cię do pracy. W Riot pracujemy z Dockerem (i Jenkinsem) na systemach Windows, Mac OSX i Linux. Wolę pracować z Dockerem na OSX, chociaż jest on doskonale funkcjonalny na Windows od Docker 1.6. Obecnie istnieją doskonałe instalatory dla obu systemów operacyjnych. Będę pracował z perspektywy OSX, ale te same narzędzia istnieją Dla Windows.

WYMAGANIA WSTĘPNE:

1. Będziesz potrzebował systemu Windows 10 Pro lub Mac OSX Yosemite 10.10.3 (lub nowszego)

2. Jeśli używasz systemu Windows, aby upewnić się, że masz włączoną wirtualizację systemu Windows (zobacz dokumentację dostarczoną przez Docker)

krótka notatka na temat KITEMATIC

z Dockerem 1.8 i wydaniem Docker Toolbox, Docker zawiera teraz „Kitematic”, sprytne narzędzie GUI, które pomaga zarządzać i wizualizować to, co dzieje się z obrazami Dockera i kontenerami. Większość tego samouczka skupia się na używaniu argumentów wiersza poleceń i pracy z Dockerem bez Kitematic GUI. Ma to na celu lepsze narażenie Cię na podstawowe mechanizmy. Podobnie, w późniejszych blogach zaczynam opisywać użycie Compose do uruchamiania i zatrzymywania wielu kontenerów na raz.

KROK 1: ZAINSTALUJ DOCKER

1. Idź do: https://www.docker.com/docker-mac lub https://www.docker.com/docker-windows

2. Pobierz i zainstaluj odpowiednią wersję Dockera dla Twojego systemu operacyjnego

3. Postępuj zgodnie ze wszystkimi instrukcjami konfiguracji.

4. Sprawdź, czy instalacja działa, otwierając zalecaną powłokę dla Twojego systemu operacyjnego (Terminal dla OSX, Powershell dla windows), uruchamiając „Docker Quickstart Terminal”. W systemie Windows będzie to skrót na pulpicie. Na OSX znajdziesz go w folderze applications/Docker. Sprawdź poniższe polecenia i upewnij się, że nie pojawią się żadne błędy

docker ps

docker info

5. Zanim zrobimy cokolwiek innego, powinniśmy zwiększyć domyślne ustawienia pamięci i procesora, których używa Docker. Później dostroimy Jenkinsa, aby używał więcej pamięci i jeśli nie dostosujemy tych ustawień, Jenkins może się zawiesić.

• przejdź do widżetu Docker na pasku narzędzi i wybierz „Preferencje”

• przejdź do zakładki Konfiguracja zaawansowana

• zwiększ zużycie procesora do co najmniej 4 Rdzeni

6. Zwiększ zużycie pamięci do co najmniej 8 GB, najlepiej więcej, coś w rodzaju 12 Gb, aby być bezpiecznym (jeśli masz je dostępne)

Krok 2: pociągnij i uruchom kontener CLOUDBEES JENKINS

1. Pozostań w oknie terminala Docker.

2. Wyciągnij Jenkinsa z publicznego repo, uruchamiając:

docker pull jenkins/jenkins

docker run -p 8080:8080 --name=jenkins-master jenkins/jenkins

3. Zauważ, że komunikat” Jenkins initial setup ” w oknie powłoki wygeneruje dla Ciebie hasło. Zapisz to, jak będziesz tego potrzebował później. Jeśli go zgubisz, możesz uruchomić ’ Docker exec jenkins-master cat / var / jenkins_home / secrets / initialAdminPassword` z uruchomionym kontenerem, aby go odzyskać.

4. Otwórz swoją ulubioną przeglądarkę i wskaż http://localhost:8080

zauważ, że używam flagi Docker — name i nazwy kontenera jenkins-master – jest to konwencja, której będę używał w całym tym blogu. Nazewnictwo kontenerów to przydatna najlepsza praktyka z trzema korzyściami:

1. To sprawia, że są łatwe do zapamiętania i interakcji z

2. Docker nie zezwala na to, aby dwa kontenery miały tę samą nazwę, co zapobiega błędom, takim jak przypadkowe uruchomienie dwóch identycznych kontenerów

3. Wiele popularnych narzędzi Dockera (takich jak Docker Compose) używa określonych nazw kontenerów, więc przyzwyczajenie się do nazywania kontenerów jest dobrą praktyką.

Krok 3: uczynienie tego nieco bardziej praktycznym

poprzedni krok uruchamia Jenkinsa z jego najbardziej podstawowymi ustawieniami uruchamiania. Możesz nawet zobaczyć, że Jenkins potrzebuje podstawowej konfiguracji i prosi Cię o hasło administratora(które możesz uzyskać z dzienników wyświetlanych na ekranie podczas uruchamiania). Jeśli jesteś jak Riot, jest mało prawdopodobne, aby uruchomić Jenkins na domyślnych ustawieniach. Przejdźmy przez dodanie kilku przydatnych opcji. Nie będziemy się jeszcze trudzić konfiguracją Jenkinsa; wystarczy wiedzieć, że może się on uruchamiać i uruchamiać.

krok 3A: demonizowanie

prawdopodobnie nie chcesz, aby dzienniki Jenkinsa wypluwały się do standardu przez większość czasu. Więc użyj flagi demona Docker, aby uruchomić kontener (-d).

1. Ctrl-c w oknie terminala uruchamiającym kontener, aby go zatrzymać

2. Uruchom następujące polecenia

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d jenkins/jenkins

teraz powinieneś po prostu wyświetlić ciąg skrótu i zostać zwrócony do terminala. Jeśli dopiero zaczynasz korzystać z Dockera, ten łańcuch skrótu jest unikalnym identyfikatorem kontenera (przydatne, jeśli zaczniesz automatyzować te polecenia).

krok 3B: ustawienia pamięci

Zwykle uruchamiamy Jenkinsa z pewnymi silnymi ustawieniami W Riot. Pamiętasz, kiedy zwiększyłeś Ilość CPU/pamięci używanej wcześniej? To jest główny powód. Aby rozpocząć, uruchom następujące polecenia

docker stop jenkins-master

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" jenkins/jenkins

to powinno dać Jenkinsowi ładną pulę pamięci 8 GB i miejsce na usuwanie śmieci.

krok 3C: zwiększenie puli połączeń

W Riot mamy dużo ruchu na naszym serwerze Jenkins, więc nauczyliśmy się dawać Jenkinsowi trochę więcej miejsca na oddech. Uruchom następujące

docker stop jenkins-master

docker rm jenkins-master

to da Jenkinsowi niezłą bazę handlarzy i czapkę. Przypadkowo nauczyłeś się używać zarówno opcji JAVA, jak i opcji JENKINS jako zmiennych środowiskowych w znaczący sposób. Należy pamiętać, że działa to ze względu na sposób, w jaki Cloudbees wygodnie ustrukturyzował swój plik dokujący Jenkins.

KROK 4: składając to wszystko razem

umieściłem wszystko, czego się tutaj nauczyliśmy, w prostym pliku makefile, dzięki czemu możesz użyć poleceń make do kontrolowania działania kontenera dokowania Jenkins. Znajdziesz go tutaj:

• https://github.com/maxfields2000/docker Jenkins_tutorial / tree / master / tutorial_01

możesz użyć następujących poleceń:

• make build-ściąga Obraz Jenkinsa

• make run-uruchamia kontener

• make stop-zatrzymuje kontener

• Wyczyść-zatrzymuje i usuwa istniejący kontener

nie musisz używać makefile, po prostu uważam, że jest to łatwiejsze niż wpisanie całej komendy run. Możesz łatwo umieścić je w wybranym przez siebie skrypcie.

mam nadzieję, że widzisz, jak łatwo jest uruchomić Dockera i Jenkinsa. Próbowałem dać ci kilka podstawowych opcji, aby wziąć domyślny kontener Cloudbees Jenkins i uczynić go nieco bardziej użytecznym. Cloudbees ma wiele przydatnych samouczków do uruchamiania kontenera, takich jak jak preinstalować wtyczki i przechowywać dane Jenkins.

to sprowadza mnie do kolejnych postów w tym temacie. Ten kontener / obraz jest przydatny, ale ma kilka wad: brak spójnego logowania, brak trwałości, brak serwera proxy serwera www przed nim i brak czystego sposobu na zagwarantowanie, że użyjesz żądanej wersji Jenkinsa. To rodzi pytania, takie jak: co, jeśli chcesz trzymać się starszej wersji? Albo co, jeśli chcesz skorzystać z najnowszego dostępnego okresu wydania?

w następnej lekcji omówię uczynienie tego pojemnika trochę bardziej wytrzymałym. W szczególności:

• Tworzenie własnego pliku dokującego do zawijania bazy Cloudbees

• przeniesienie niektórych zmiennych środowiskowych do nowego obrazu

• Tworzenie folderu dziennika, ustawianie uprawnień i innych przydatnych katalogów Jenkins oraz pobieranie dzienników Jenkins podczas jego działania

Lekcja 2-podstawowe opakowanie obrazu Jenkinsa

w poprzedniej lekcji omówiłem Konfigurowanie środowiska programistycznego do uruchamiania Dockera i eksperymentowałem z obrazem Dockera Jenkinsa dostarczonym przez Cloudbees. Okazało się, że jest prosty i łatwy w użyciu, z kilkoma świetnymi funkcjami po wyjęciu z pudełka. Aby poczynić postępy w obszarach usprawnień, które zidentyfikowaliśmy, koncepcje Dockera omówione w tej lekcji są następujące:

• Tworzenie własnego pliku Dockerfile

• Ustawianie zmiennych środowiskowych w pliku dokującym

• Tworzenie folderów i uprawnień w pliku Dockerfile

• używanie docker exec do uruchamiania poleceń przeciwko działającemu kontenerowi

tworzenie podstawowego pliku dokującego

chcemy wprowadzić pewne zmiany do domyślnego uruchamiania Jenkinsa. W ostatnim blogu zajęliśmy się tym, tworząc plik makefile, który przekazywał argumenty jako zmienne środowiskowe. Biorąc pod uwagę, że chcemy to robić za każdym razem, możemy po prostu przenieść je do naszego własnego pliku dokującego. Dodatkowo, nasz własny plik Dockerfile pozwoli nam zablokować wersję Jenkinsa, której używamy w przypadku, gdy Cloudbees zaktualizuje ich wersję i nie będziemy gotowi na aktualizację.

robimy to w czterech krokach:

1. Utwórz katalog roboczy

2. W ulubionym edytorze tekstu utwórz nowy plik o nazwie „Dockerfile”

3. Dodaj następujące elementy do pliku i zapisz go:

FROM jenkins/jenkins:2.112LABEL maintainer=""

4. Następnie w wierszu poleceń wpisz:

docker build -t myjenkins .

to, co zrobiliśmy, to wyciągnięcie konkretnej wersji obrazu Jenkinsa z publicznego repo Dockera. Wszystkie dostępne wersje znajdziesz tutaj:

• zawsze możesz ustawić klauzulę FROM na dowolną wersję obrazu. Nie można jednak po prostu ustawić wersji na dowolną wersję Jenkinsa. Jest to wersja obrazu ” tag ” lub „label”, a Cloudbees jest na tyle Ładna, że pasuje do wersji Jenkinsa wewnątrz obrazu. Cloudbees oferuje „jenkins / jenkins” jako wygodny sposób na uzyskanie najnowszej wersji lub” jenkins/jenkins:LTS”, aby uzyskać najnowszą wersję” Long Term Support”. W tym przykładzie używam konkretnej wersji. Znaczniki etykietujące Wydania są świetne, ale użycie ich oznacza, że wersja Jenkinsa może się zmienić pod tobą, co może spowodować komplikacje, jeśli nie jesteś gotowy do aktualizacji. Zalecam „blokowanie wersji” jako ogólną najlepszą praktykę w przypadku wszelkich zależności w Dockerze lub innych narzędziach do zarządzania zależnościami. Chcesz, żeby wszystko się zmieniło, kiedy tego chcesz, a nie wcześniej. Dlatego używam tutaj konkretnej wersji.

  testując nowy plik DOCKERFILE

  możemy bardzo łatwo przełączyć się na obraz, modyfikując nasze polecenie docker run na następujące:

  docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" --env JENKINS_OPTS=" --handlerCountMax=300" myjenkins

  teraz możemy wyczyścić te zmienne środowiskowe umieszczając je we własnym pliku Dockerfile.

  dodawanie zmiennych środowiskowych do naszego pliku DOCKERFILE

  łatwo jest dodać domyślne ustawienia zmiennych środowiskowych do plików Dockerfile. Zapewnia to również ładną dokumentację własną. A ponieważ zawsze można je nadpisać podczas uruchamiania kontenera Docker, nie ma naprawdę żadnych wad.

  1. W pliku Dockerfile dodaj następujące wiersze po wierszu” opiekun”:

  ENV JAVA_OPTS="-Xmx8192m"ENV JENKINS_OPTS=" --handlerCountMax=300"

  2. Zapisz i odbuduj swój wizerunek:

  • docker build-t myjenkins .

  docker build -t myjenkins .

  całkiem proste! Możesz sprawdzić, czy nadal działa, wprowadzając następujące trzy polecenia:

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  

  Twój wizerunek powinien zacząć się od razu! Ale skąd wiesz, że zmienne środowiskowe działały? Proste: w ten sam sposób można sprawdzić, jakie argumenty uruchomiły aplikację Jenkins normalnie używającą ps. I to działa, nawet jeśli rozwijasz się w systemie Windows.

  uruchamianie komendy BASIC przeciwko kontenerowi

  aby potwierdzić, że opcje Java i Jenkins są ustawione poprawnie możemy uruchomić ps w naszym kontenerze i zobaczyć uruchomiony proces Java Jenkins używając docker exec

  docker exec jenkins-master ps -ef | grep java

  powinieneś zobaczyć coś podobnego wróć

  jenkins 1 0 99 21:28 ? 00:00:35 java -Xmx8192m -jar /usr/share/jenkins/jenkins.war --handlerCountMax=300

  

  dzięki temu możesz łatwo zobaczyć, że nasze ustawienia utknęły. docker exec to prosty sposób na wykonywanie poleceń powłoki wewnątrz kontenera, a także niezwykle prosty sposób na ich sprawdzenie. Działa to nawet w systemie Windows, ponieważ, pamiętaj, polecenie po „exec” jest uruchamiane wewnątrz kontenera, a zatem jest oparte na dowolnym obrazie bazowym, którego używa kontener.

  konfigurowanie folderu dziennika

  w poprzednim blogu zauważyliśmy, że straciliśmy wgląd w dzienniki Jenkinsa podczas uruchamiania naszego kontenera z flagą daemonize (-d). Chcemy użyć wbudowanej funkcji Jenkins, aby ustawić folder dziennika. Będziemy musieli to zrobić w naszym Pliku Dockerfile, a następnie przekazać opcję logowania do Jenkinsa.

  ponownie edytujmy nasz plik Dockerfile. Pomiędzy „opiekunem” a pierwszą linią ENV dodamy następującą

  RUN mkdir /var/log/jenkins

  umieszczamy polecenie w tym miejscu w pliku, aby postępować zgodnie z najlepszymi praktykami. Jest bardziej prawdopodobne, że zmienimy zmienne środowiskowe niż te katalogi instalacyjne, a każda linia poleceń w pliku Dockerfile stanie się zasadniczo własną warstwą obrazu. Maksymalizujesz ponowne użycie warstwy, umieszczając często zmieniane elementy w pobliżu dołu.

  teraz Zbuduj swój wizerunek na nowo:

  docker build -t myjenkins

  pojawi się błąd, który wygląda jak

  ---> Running in 0b5ac2bce13bmkdir: cannot create directory '/var/log/jenkins': Permission denied

  

  bez obaw. Dzieje się tak, ponieważ domyślny kontener Cloudbees ustawia uruchomionego użytkownika na użytkownika „Jenkins”. Jeśli spojrzysz na ich plik Dockerfile (znaleziony tutaj: https://github.com/ Jenkinsci/Docker/blob/master/Dockerfile), powinieneś zobaczyć, u dołu

  USER ${user}

  ta składnia może być nieco myląca. Używa „argumentów” kompilacji Dockera, aby umożliwić Ci zdefiniowanie użytkownika. Jeśli przejrzysz dalej plik Docker, znajdziesz wartość domyślną. Spójrz na górę pliku dokującego dla

  ARG user=jenkins

  to tworzy argument „user” (ARG) i ustawia go na użytkownika Jenkinsa. Pozwala to na zmianę nazwy użytkownika używanej przez Jenkinsa podczas wywołania docker build — build-arg somevariable=somewalue. Pamiętaj, że działa to tylko wtedy, gdy tworzysz plik Dockerfile od zera. Wartości tych nie można zmienić za pomocą przycisku Docker pull lub uruchomienia docker run. Możesz przeczytać więcej o argumentach budowania tutaj. Ponieważ używamy wbudowanej wersji w naszej klauzuli FROM, kończymy z domyślnym użytkownikiem: „jenkins”.

  w normalnym Linuksie wystarczy użyć SUDO lub innego środka do utworzenia folderu (/var/log jest własnością roota). Na szczęście Docker pozwala nam zmieniać użytkowników.

  Dodaj do pliku Dockerfile:

  1. Przed uruchomieniem linii mkdir dodaj

  USER root

  2. Po uruchomieniu linii mkdir dodaj

  RUN chown -R jenkins:jenkins /var/log/jenkins

  3. Po uruchomieniu chown line dodaj:

  USER jenkins

  zauważ, że musieliśmy również dodać komendę chown, ponieważ chcemy, aby użytkownik Jenkinsa mógł pisać do folderu. Następnie ustawiamy root, a następnie resetujemy Jenkinsa, aby zachowanie pliku Dockerfile zostało zachowane.

  teraz Zbuduj swój wizerunek na nowo:

  docker build -t myjenkins .

  

  i… twoje błędy powinny zniknąć.

  z ustawionym katalogiem log (uwaga: możesz umieścić ten folder gdziekolwiek chcesz, używamy /var/log dla spójności) możemy teraz powiedzieć Jenkinsowi, aby zapisywał do tego folderu podczas uruchamiania, modyfikując zmienne środowiskowe JENKINS_OPTS.

  w pliku Dockerfile edytuj linię JENKINS_OPTS, aby wyglądała tak:

  • ENV JENKINS_OPTS= ” –handlerCountMax=300 –logfile = /var/log/jenkins / jenkins.log”

  ENV JENKINS_OPTS="--handlerCountMax=300 --logfile=/var/log/jenkins/jenkins.log"

  teraz Zbuduj swój obraz jeszcze raz

  docker build -t myjenkins .

  przetestujmy nasz nowy obraz i jeśli uda nam się śledzić plik dziennika! Wypróbuj następujące polecenia

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  po uruchomieniu kontenera możemy śledzić plik dziennika, jeśli wszystko działa

  docker exec jenkins-master tail -f /var/log/jenkins/jenkins.log

  Odzyskaj logi, jeśli Jenkins ulegnie awarii

  czas na dodatkową rundę! Dopóki omawiamy logi, Docker stanowi interesujący problem w przypadku awarii Jenkinsa. Kontener przestanie działać, a docker exec przestanie działać. Więc co robić?

  omówimy bardziej zaawansowane sposoby utrzymywania pliku dziennika później. Na razie, ponieważ kontener jest zatrzymany możemy skopiować z niego pliki za pomocą polecenia docker cp. Zasymulujmy awarię, zatrzymując kontener, a następnie pobierając dzienniki:

  1. ctrl-c, aby wyjść z ogona pliku dziennika

  2. Uruchom następujące polecenia

  docker stop jenkins-master

  docker cp jenkins-master:/var/log/jenkins/jenkins.log jenkins.log

  cat jenkins.log

  

  podsumowanie

  wszystkie prace znajdziesz w moim tutorialu Git repo (oraz zaktualizowanym pliku makefile) tutaj:

  • https://github.com/maxfields2000/docker Jenkins_tutorial / tree / master / tutorial_02

  tworząc własny plik Dockerfile, który zawija plik Cloudbees, byliśmy w stanie ułatwić sobie życie. Stworzyliśmy wygodne miejsce do przechowywania dzienników i nauczyliśmy się, jak na nie patrzeć za pomocą polecenia docker exec. Przenieśliśmy nasze domyślne ustawienia do pliku Dockerfile i teraz możemy przechowywać je w kontroli źródłowej jako dobry fragment dokumentacji własnej.

  wciąż mamy problem z utrzymaniem danych. Nauczyliśmy się, jak wyciągać pliki dziennika z zatrzymanego kontenera (przydatne podczas awarii Jenkinsa). Ale ogólnie rzecz biorąc, jeśli nasz kontener się zatrzyma, nadal tracimy wszystkie miejsca pracy, które stworzyliśmy. Tak więc bez trwałości Ten obraz Jenkinsa jest przydatny tylko do lokalnego rozwoju i testowania.

  to prowadzi nas do następnego artykułu. Dzięki naszym fundamentom – naszemu własnemu pakietowi plików Dockerfile, zamkniętemu w poręcznej wersji Jenkinsa – możemy rozwiązać problem trwałości. W następnym artykule omówimy te pojęcia:

  • zachowanie danych Zadań Jenkins i wtyczek

  • trwałość danych Dockera z woluminami

  • Tworzenie pojemnika na dane

  • udostępnianie danych w woluminach z innymi kontenerami

  aby uzyskać więcej informacji, zapoznaj się z resztą tej serii:

  część i: myślenie wewnątrz kontenera
  Część II: umieszczanie Jenkinsa w kontenerze Dockera (ten artykuł)
  Część III: Docker & Jenkins: dane, które utrzymują się
  Część IV: Jenkins, Docker, Proxy i Compose
  Część V: Przejmowanie kontroli nad obrazem Dockera
  Część VI: budowanie za pomocą Jenkinsa wewnątrz efemerycznego kontenera Dockera
  Część VII: samouczek:budowanie za pomocą Jenkinsa wewnątrz efemerycznego kontenera Dockera
  Część VIII: DockerCon Talk and the Story So Far