Uruchamianie kontenerów w środowisku Nomad
Instalacja i uruchomienie usług
Instalacja usługi została przedstawiona w poprzednim wpisie dokumentującym cały proces instalacji i uruchomienia usługi Nomad, zarówno części serwerowej odpowiadającej za komunikację z klientami oraz części odpowiedzialnej za uruchamianie samych kontenerów. Na tym etapie zakłada się, że całość została uruchomiona i mamy dostęp do maszyn. Domyślnie polecenie nomad komunikuje się z maszyną pod adresem http://localhost:4646. Uruchamiając więc polecenie na maszynie na której został wcześniej zainstalowany i uruchomiony Nomad powinniśmy uzyskać połączenie automatycznie. Aby zmienić połączenie, możemy użyć do tego zmiennej środowiskowej NOMAD_ADDR, albo przy wykonywaniu poleceń ustawić odpowiednio opcje -address=<addres>, co zaskutkuje zmianą adresu na który będą wykonywane polecenia. Poniżej wynik wykonania poleceń nomad version i nomad status jako przykład sprawdzający aktualną wersję aplikacji i status wykonanych zadań.
pmazur@pmazur-P8Z68-V ~ $ nomad version
Nomad v1.5.3
BuildDate 2023-04-04T20:09:50Z
Revision 434f7a1745c6304d607562daa9a4a635def7153f
pmazur@pmazur-P8Z68-V ~ $ nomad status
No running jobsPrzygotowanie zadania
Aby wykonać zadanie publikacji usługi na naszym serwerze należy przygotować plik w formacie HCL, odpowiedzialny za definicję zadania które chcemy uruchomić. Wg. dokumentacji jest to job, po szczegóły odsyłam na stronę specyfikacji. Na potrzeby tego artykułu posłużymy się prostym obrazem hashicorp/demo-webapp, pozwalającym sprawdzić uruchomić kontener www, do którego uzyskamy dostęp na zadanym porcie sieciowym z wykorzystaniem protokołu http. To od czego musimy zacząć, to stworzyć plik opisujący zadanie któremu nadamy nazwę „demo-webapp”. Po tej nazwie będziemy się odnosić wykonując polecenia nomadowi.
job "demo-webapp" {
task "server" {
driver = "docker"
config {
image = "hashicorp/demo-webapp:v3"
}
}
}Uruchomienie zadania
Kolejnym krokiem jest zlecenie uruchomienia zadania wspomniany kontener przy użyciu polecenia nomad run.
pmazur@pmazur-P8Z68-V ~/nomad $ nomad run demo-webapp.nomad
==> 2023-06-02T16:30:10+02:00: Monitoring evaluation "1ba764aa"
2023-06-02T16:30:10+02:00: Evaluation triggered by job "demo-webapp"
2023-06-02T16:30:11+02:00: Evaluation within deployment: "22943434"
2023-06-02T16:30:11+02:00: Allocation "581771f2" created: node "cd74249a", group "server"
2023-06-02T16:30:11+02:00: Evaluation status changed: "pending" -> "complete"
==> 2023-06-02T16:30:11+02:00: Evaluation "1ba764aa" finished with status "complete"
==> 2023-06-02T16:30:11+02:00: Monitoring deployment "22943434"
✓ Deployment "22943434" successful
2023-06-02T16:30:22+02:00
ID = 22943434
Job ID = demo-webapp
Job Version = 0
Status = successful
Description = Deployment completed successfully
Deployed
Task Group Desired Placed Healthy Unhealthy Progress Deadline
server 1 1 1 0 2023-06-02T16:40:21+02:00Po przetworzeniu polecenia możemy sprawdzić status naszych zadań z użyciem polecenia nomad status demo-webap.
pmazur@pmazur-P8Z68-V ~/nomad $ nomad status
ID Type Priority Status Submit Date
demo-webapp service 50 running 2023-06-02T16:30:10+02:00Oraz uzyskać więcej szczegółów podając jako ostatni parametr nazwę zadania.
pmazur@pmazur-P8Z68-V ~/nomad $ nomad status demo-webapp
ID = demo-webapp
Name = demo-webapp
Submit Date = 2023-06-02T16:30:10+02:00
Type = service
Priority = 50
Datacenters = *
Namespace = default
Status = running
Periodic = false
Parameterized = false
Summary
Task Group Queued Starting Running Failed Complete Lost Unknown
server 0 0 1 0 0 0 0
Latest Deployment
ID = 22943434
Status = successful
Description = Deployment completed successfully
Deployed
Task Group Desired Placed Healthy Unhealthy Progress Deadline
server 1 1 1 0 2023-06-02T16:40:21+02:00
Allocations
ID Node ID Task Group Version Desired Status Created Modified
581771f2 cd74249a server 0 run running 4m12s ago 4m2s agoTe same informacje uzyskamy także przechodząc do panelu www zarządzającego Nomadem.
Konfiguracja sieci
Na tym etapie nasz kontener został uruchomiony, jednak nie został jeszcze skonfigurowany port pozwalający na komunikację sieciową. Możemy to zrealizować poprzez zdefiniowanie dostępnych portów i odnieść się do nich jako serwisu w konfiguracji zadania. Całość powinna też zostać umieszczona w grupie, co oznacza konieczność wydania wszystkich zadań docelowo na jednej maszynie. W tym przykładzie posłużymy się usługą typu „nomad”. Domyślnie istnieje możliwość rejestrowania usług w narzędziu Consul, jednak wymaga ona uruchomienia dodatkowego narzędzia. Do usługi zostały także przekazane dwie zmienne środowiskowe wymagane do nasłuchiwania przez kontener na zadanym porcie. Po zmianach nasz plik zadania powinien wyglądać w następujący sposób.
job "demo-webapp" {
group www {
network {
port "http" {
to = 80
}
}
service {
provider = "nomad"
port = "http"
}
task "server" {
driver = "docker"
env {
PORT = "${NOMAD_PORT_http}"
NODE_IP = "${NOMAD_IP_http}"
}
config {
image = "hashicorp/demo-webapp:v3"
ports = ["http"]
}
}
}
}Dla tak przygotowanej i uruchomionej konfiguracji, możemy sprawdzić uruchomione usługi.
Nasz kontener jest teraz dostępny pod zaprezentowanym adresem, na losowo wygenerowanym porcie na naszym kliencie, kierującym ruch do kontenera na porcie 80.
Podsumowanie
Powyższy artykuł przedstawia jedynie podstawowe możliwości jakie dostarcza nam nowe dla Nas narzędzie do konteneryzacji naszych usługi i nie wyczerpuje jego ogromnych możliwości konfiguracyjnych. W kolejnym artykule na pewno podzielimy się z Wami naszymi dalszymi doświadczeniami z wykorzystania tego orkiestratora. Na tym etapie, pozwoliło nam na wdrożenie podstawowej wersji procesu CI, która docelowa zastąpi dotychczas używany przez nas proces wydawania z użyciem narzędzia jakim jest Deployer.
Dodaj komentarz