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


07.08.2019

Kurzinformation it-sa, 8-10...

It-sa is one of the leading international trade fairs for IT security. With around 700...
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

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"