Continuous integration#03: Docker. Containers. Swarm.

C

Trzeci post nt. Continuous Integration.  Omówienie i krótki wstęp do inicjalizacji docker swarm, w celu utworzenia środowiska dla testów build serwerów.

  1. „Warsztat smokogromcy”
  2. „Atrybuty smoczego pogromcy”
  3. „Docker. Containers. Swarm.”

Podejście kolejne

Od czasu ostatniego wpisu dotyczącego Continous Integration, Continous Delivery, Continous Deployment, w kontekście testu build serwerów, minęło kilka miesięcy. W tym czasie popełniłem kilka mniej wymagających (ale nie mniej znaczących!) postów. Nabrałem trochę wprawy w blogowaniu i w wyrażaniu własnych myśli, a także nauczyłem się sporo w dziedzinie samej „developerki”. Uznałem, że czas powrócić do tematu automatyzacji, pobawić się trochę DevOpsowymi zabawkami.

 

Na dobrej zabawie, czas szybko płynie.

 

W tym wpisie wyjaśniam, jak widzę dalszą pracę z przygotowaniem środowiska i jak widzę kolejne kroki. Zastrzegam również, że jestem przygotowany na „bunt maszyn”, przez co założenia mogą się zmieniać w trakcie pracy i testów.

 

Zatem do dzieła!

Pierwszym krokiem, jest przygotowanie środowiska testowego i produkcyjnego. Od początku do końca, tzn. hardware też jest ważny, dlatego zabrałem się do pracy również od tej strony. W poprzednich wpisach.

Nie zmieniam tych postów i nie modyfikuję. Będzie można zobaczyć moją ewolucję ideową w kwestii tego felietonu.

 

Sytuacja sprzętowa, na tę chwilę, wygląda tak:

  • Komputer z zainstalowanym Dockerem
  • 1x Raspberry Pi 3 z Raspbian Stretch i Dockerem
  • 2x Raspberry Pi 3+ z Raspbian Stretch i Dockerem

Czyli, teoretycznie mam dostępne 4 maszyny które mogę wykorzystać.

Komputer, prawdopodobnie, będzie maszyną developerską, jak również managerem dla Dockerowego swarma. Jeszcze nie wiem jak będzie się sprawdzał jako build serwer. Jeśli będzie możliwość postawienia Jenkinsa, TeamCity,  czy innego ustrojstwa w kontenerze, zrobię to. Dzięki temu nie będę musiał konfigurować specjalnie w tym celu swojego systemu. Repozytorium? Github, a jakże?

Poniżej przedstawiam na schemacie moją wizję. Domyślam się, że osoba bardziej obeznana z tematem Dockera i kontenerów, zauważy błędy lub nawet niezrozumienie tematu, ale hey…nauczmy się razem 🙂

Uwaga. Schemat poglądowy 🙂 BTW: Znacie grę „Patapon„?

 

Lekcja środowisko

Osobnego środowiska developerskiego nie będę tworzył, myślę, że te dwa – produkcyjne i testowe – do moich testów, wystarczą w zupełności. Tradycyjnie rzecz ujmując, musiałbym przygotować dwie maszyny wirtualne, tożsame ze sobą. Od biedy jedną, ale środowisko testowe i produkcyjne na jednej maszynie to raczej średni pomysł.

Pierwszy problem do rozwiązania, tzn. jak zapewnić, żeby maszyna testowa była dokładnie takim samym środowiskiem jak maszyna produkcyjna? To jest jedna z podstawowych zasad kierujących procesem Continous Delivery – wszystkie testy integracyjne i manualne są wykonywane w środowisku tożsamym ze środowiskiem produkcyjnym.

W różnym szambie człowiek musiał nurkować godzinami, czasem dniami, żeby doprowadzić jakiś system do stanu używalności. Dlatego wiem, że doprowadzenie do sytuacji, gdzie środowisko testowe jest identyczne z produkcyjnym, jest trudne do ogarnięcia w sensownym czasie. Nie dość, że przecież nie będziemy działać na danych produkcyjnych w przypadku środowiska testowego, to prawdopodobnie stanie nam na drodze szeroko pojęty biznes, lub management który powie, że to wszystko niepotrzebne i da się mniej, taniej, szybciej.

 

„Tyle serwerów? Tyle mocy? A po co to? Żeby poklikać?”

 

Życie…

W takiej sytuacji przybywa z odsieczą Docker i niesiony przez niego kaganek ideii „paczkowania obrazów w celu wirtualizacji”?

 

Mięsko

Podzielę się tym, w jaki sposób konstruowałem opisane powyżej środowisko, tak żebyście mieli lepszy pogląd na to, jak to wygląda.

Zacznę od samego początku czyli od tworzenia swarma.

Instalujemy docker na każdym sprzęcie. Na Windows odpalasz instalator, a na Raspbery robisz tak:

 

  • update środowiska
sudo apt-get update && sudo apt-get upgrade

 

  • instalacja dockera
curl -sSL https://get.docker.com | sh

 

  • dodanie domyślnego użytkownika „pi” do grupy „docker”
sudo usermod -aG docker pi

 

 

Potem, na „głównej” maszynie inicjalizujemy „tryb swarm”

docker swarm init --advertise-addr X.X.X.X:2377

(advertise addr – (uproszczając) to adres używany przez inne węzły do połączenia)

 

…i po uzyskaniu join-tokena podłączamy resztę maszyn do głównej, każdą jako node, używając uzyskanego tokena. Zwyczajnie odpalamy tę komendę w terminalach raspberry.

docker swarm join --token SWMTKN-1-6ced29kapo22gp0tanz6kwzoo2ejb11i2icc61k2kvdom7lbbq-0ngr9b9s80pof70hvb676rfoe X.X.X.X:2377

 

Jeszcze tylko komenda sprawdzająca nasze działania i voilà! Mamy gotowy docker swarm.

(u mnie jeden z węzłów „leży” – to efekt moich wcześniejszych zabaw  🙂 . Dokładnie, to nie „wypiąłem” jednego z node’ów za pomocą komendy docker swarm leave, i zmieniłem system na tym właśnie raspberry, co zaowocowało tym rezultatem)

 

Następnym krokiem będą baza danych i moje WebAPI postawione jako usługi i wyskalowane w węzłach (boshe, jak to głupio brzmi). Po prostu stworzę obrazy i odpalę serwisy na node’ach. Napiszę jakieś sensowne Dockerfile dla każdego obrazu. Tak żeby kolejnym krokiem już było tylko instalowanie build serwera i testowanie i zabawa i testowanie i zabawa…

Zapowiada się całkiem fajnie, dlatego zostań ze mną!

 

Stick with me!

 

 

Tymczasem napisz komentarz! Daj znać, czy w ogóle moje podejście do tematu ma ręce i nogi.

Zapisz się do newslettera! Będziesz mógł śledzić moje poczynania na bieżąco.

Czołem!

 



 

 

About the author

2 komentarze

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi