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


05.09.2019

Cloudya – nowa usługa NFON

Po ponad dekadzie ciągłego rozwoju technologii Cloudya, swobodna i niczym nie ograniczona...
02.09.2019

Na dużą skalę

Kaspersky Hybrid Cloud Security
02.09.2019

Bezpieczny brzeg sieci

Fortinet Secure SD-Branch
02.09.2019

Nowoczesne centra danych

AMD EPYC
30.08.2019

Dostęp do AI i ML

VMware Cloud Foundation
30.08.2019

Lekkość i moc

Toshiba Portégé A30-E
30.08.2019

Bez przestojów

APC Easy UPS On-Line
29.08.2019

Duże moce

Lenovo ThinkSystem SR635 i SR655
29.08.2019

Lekkie drukarki

Lexmark GO Line

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"