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



08.07.2019

Narzędzie EDR

ESET Enterprise Inspector
08.07.2019

Usuwanie skutków awarii

Veeam Availability Orchestrator v2
08.07.2019

Indywidualna konfiguracja

baramundi Management Suite 2019
05.07.2019

Technologia Ceph

SUSE Enterprise Storage 6
05.07.2019

Szybkie i bezpieczne...

Konica Minolta bizhub i-Series
05.07.2019

Edge computing

Atos BullSequana Edge
04.07.2019

Terabitowa ochrona

Check Point 16000 i 26000
04.07.2019

Obsługa wideokonferencji

Poly G7500
04.07.2019

Laptop biznesowy

Fujitsu LIFEBOOK U939X

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.  

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"