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


23.04.2019

Optymalizacja zużycia chmury

HPE GreenLake Hybrid Cloud
23.04.2019

Zarządzanie wydajnością

VMware vRealize Operations 7.5
19.04.2019

Technologie open source

SUSECON 2019
19.04.2019

Wyjątkowo małe

OKI seria C800
19.04.2019

Łatwy montaż

Rittal AX i KX
18.04.2019

Technologie wideo

Avaya IX Collaboration Unit
18.04.2019

Krótki rzut

Optoma W318STe i X318STe
18.04.2019

Do mobilnej pracy

Jabra Evolve 65e
27.03.2019

Pożegnanie z systemem Windows...

System operacyjny Windows 7 wciąż cieszy się dużą popularnością wśród użytkowników...

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"