Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


10.06.2019

Inteligentne zarządzanie...

W dniach 11, 12 i 13 czerwca – odpowiednio – w Gdańsku, w Warszawie i w Katowicach,...
27.05.2019

Rozwiązania na platformie GCP

Citrix SD-WAN i Citrix ADC
27.05.2019

Chmura hybrydowa

Dell Technologies Cloud
27.05.2019

Uproszczona komunikacja

Cisco Webex
24.05.2019

Konferencja IT Manager of...

W dniach 12–14 czerwca w Sopocie odbędzie się konferencja IT Manager of Tomorrow 2019. To...
24.05.2019

Ochrona sieci

Fortinet FortiOS 6.2
24.05.2019

Mniejsza złożoność

Rittal VX25 Ri4Power
24.05.2019

All-in-one NAS

QNAP TDS-16489U R2
24.05.2019

Układy SoC

AMD Ryzen Embedded R1000

Zaawansowana automatyzacja AWS

Data publikacji: 21-01-2019 Autor: Grzegorz Adamowicz
Sieć VPC stworzona przez...

Terraform jest jednym z otwartych i darmowych narzędzi tworzonych przez firmę HashiCorp. Służy do zarządzania infrastrukturą w różnych typach chmury (jak Google Cloud Platform lub AWS) oraz w wybranych rozwiązaniach SaaS (np. CloudFlare).

 

W poprzednim numerze przyjrzeliśmy się temu, jak wygląda interakcja z Terraformem. Tym razem zorganizujemy swój kod tak, żeby mógł obsłużyć wiele zróżnicowanych infrastruktur przy użyciu modułów dostępnych online (Terraform Registry, Git­Hub) i w naszym repozytorium. Kod prezentowany poniżej będzie działał w wersji Terraforma 0.11.x – wersja 0.12 wymaga już znacznych zmian.

Centralnym i najważniejszym elementem, na który musimy zwrócić uwagę niezależnie od wersji Terraforma, jest plik stanu. Służy on zarówno do śledzenia utworzonych zasobów, jak i do zmian w infrastrukturze. Terraform bez pliku stanu nie będzie mógł zarządzać już istniejącą infrastrukturą i będzie próbował utworzyć od nowa zasoby zdefiniowane w kodzie. W AWS zaleca się zapisywanie pliku stanu w usłudze S3 i uruchomienie blokowania zmian, stosując DynamoDB. Będziemy mogli tego dokonać, konfigurując Terraforma przy użyciu dyrektywy backend.

> SPOSÓB ORGANIZACJI KODU TERRAFORMA

Jeśli obsługujemy wewnątrz naszej organizacji kilku klientów, warto zaplanować, w jaki sposób odseparujemy kod dla poszczególnych kont. Powinniśmy też założyć, że klient będzie planował wprowadzenie modelu kont dla organizacji w AWS. Poniższy model sprawdza się w obu przypadkach.


W katalogu bin umieścimy wszelkie skrypty automatyzujące uruchomienie Terraforma. Czasem łącznie z samym skompilowanym plikiem terraform.

Katalog customers zawiera podkatalog oddzielnie dla każdego klienta, wewnątrz niego umieścimy kod, który będzie zarządzał daną infrastrukturą. Każdy z klientów, w tym wypadku some-customer, powinien zawierać co najmniej dwa zestawy kodu: bootstrap i main.

Z zestawu bootstrap korzystamy do utworzenia zasobów używanych później przez Terraforma. Jest to bu­cket S3 na plik stanu, tabela w DynamoDB do blokowania stanu i użytkownik, na którym będzie działał sam Terraform. W katalogu bootstrap umieszczamy również plik stanu, ponieważ nie mamy jeszcze gdzie go zapisać. Z kolei main dzielimy na regiony w AWS (tu: eu-west-1) i umieszczamy tam już właściwy kod zarządzający infrastrukturą.

Katalog modules służy do zapisywania naszych modułów lub modułów, które skopiowaliśmy z publicznych zasobów, np. z repozytorium GitHub.

Ponieważ Terraform działa tak, że wczytuje wszystkie pliki z rozszerzeniem .tf z katalogu, z którego go uruchamiamy, wystarczy teraz zadbać o dostarczenie odpowiednich kluczy dostępu, a następnie przejść do katalogu klienta i odpowiedniego podkatalogu oraz regionu i uruchomić komendę terraform plan. Pozostaje jeszcze tylko zautomatyzować proces i wydelegować to zadanie do wybranego narzędzia CI, na przykład Jenkins.

> PRZYGOTOWANIE KONTA – BOOTSTRAPING

Wspomniany specjalny katalog bootstrap, z którego korzystamy do tworzenia zasobów później używanych przez Terraforma, będzie zawierał trzy elementy: skonfigurowany lokalny plik stanu, prywatny bucket S3 do przechowywania pliku stanu przez główny kod tworzący całość infrastruktury oraz tabelę DynamoDB używaną jako rozproszona blokada zmian pliku stanu, w razie gdyby Terraform został uruchomiony kilka razy (np. przez kilku użytkowników). Opcjonalnie możemy tam również umieścić użytkownika, z którego później będzie korzystał Terrraform. Warto też zadbać o to, aby bucket S3 był szyfrowany i miał włączone wersjonowanie.

 

[...]

 

Doświadczony inżynier systemów. Specjalizuje się w automatyzacji procesów i monitoringu aplikacji rozproszonych. Propagator ruchu open source. Organizator wydarzeń związanych z IT. Freelancer. W wolnych chwilach twórca fantastyki i fantastyki naukowej.  

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"