Jednym z głównych aspektów, o którym często dyskutuje się podczas migracji do chmury publicznej to zmniejszenie nakładów na koszty operacyjnie. Rzecz jasna odpadają już kwestie zawiązane z utrzymaniem i konfiguracją fizycznej infrastruktury informatycznej. Ponadto, w zależności od tego, jakiego typu serwisy wykorzystujemy (IaaS, PaaS czy SaaS), zakres prac operacyjnych może okazać się jeszcze mniejszy.
Jednak nie oznacza to, iż nie ma już pracy dla administratorów. Ta praca jest i z czasem może się okazać, że jest jej całkiem sporo.
Infrastructure as a Code – AWS CloudFormation
Istnieje wiele sposobów na ułatwienie sobie pracy i przede wszystkim automatyzację powtarzalnych zadań. Dziś pragnę skupić się na Infrastructure as a Code, czyli na definiowaniu konfiguracji infrastruktury/serwisów, jakie dla danej aplikacji mają być wykorzystane w postaci szablonu konfiguracyjnego.
AWS ma swoją własną usługę CloudFormation, która w łatwy sposób pozwala uruchamiać i zarządzać zbiorami usług AWS. Wszystko sprowadza się do przygotowania odpowiednio spreparowanego szablonu (template’u), w którym zdefiniowane są informacje o usługach i zasobach oraz sposobie ich konfiguracji i kolejności uruchamiania. Następnie za pomocą serwisu CloudFormation tworzony jest Stack (stos zasobów AWS) ze wszystkimi elementami określonymi w szablonie.
Takie podejście daje sporo korzyści jak np.:
- Automatyzacja powtarzalnych zadań. Np. uruchamianie kilku kopii tego samego środowiska aplikacyjnego. Zamiast za każdym razem klepać ręcznie nowe elementy aplikacji jak sieć, serwery, bazy, można raz napisać template i uruchamiać kolejne Stacki.
- Spójność konfiguracji środowisk. Używając template’ów mamy pewność, że kolejne kopie środowiska będą miały taką samą konfigurację.
- Zwiększenie bezpieczeństwa – ponieważ robiąc konfigurację, przez przygotowany i zatwierdzony template zmniejszamy ryzyko popełnienia błędu i np. wystawieniu bazy danych RDS na świat.
Rozważmy przykład scenariusza, o którym pisał Tomek we wpisie Budowanie prostego schedulera serwerów EC2.
Dość prosta konfiguracja, triggery CloudWatch, dwie AWS Lambdy + uprawnienia. Gdy jednak tę konfigurację chcemy zaimplementować w kilku regionach lub też na różnych kontach, za każdym razem trzeba przejść tą procedurę, o której wspominał Tomek.
Dlatego zamiast klepać w kółko to samo, lepiej przygotować sobie template i wdrożyć tę konfigurację poprzez CloudFormation.
Nowy dodatek – CloudFormation StackSets
Jednak CloudFormation ma też pewne ograniczenia – mianowicie każdy Stack, tak jak inne serwisy uruchamiany jest na danym koncie AWS i w konkretnym regionie. Jednak od niedawna to już nie jest problemem, gdyż pojawił się nowy dodatek do CloudFormation – StackSets.
Dzięki StackSets można za jednym razem wygenerować kilka Stack’ów w kilku wybranych regionach, bądź nawet na innych kontach chmurowych. Kiedy to się może przydać?
- Gdy mamy więcej niż jedno konto AWS. Wtedy bardzo łatwo i szybko można zaimplementować spójną konfigurację na kilku kontach, jak np. wymuszenie MFA na wszystkich użytkownikach należących do grupy Administratorów.
- Implementacja konfiguracji zasobów, która jest rozproszona na kilka Regionów, jak np. przeszukanie zarezerwowanych, a nie używanych Elastic IPs.
Zatem zobaczmy to w praktyce.
Demo
Weźmy przykład z wpisu Tomka z schedulerem dla wirtualnych maszyn. Ja mam akurat przygotowaną konfigurację, która na moim koncie laboratoryjnym codziennie o godzinie 22:00 wyłącza wszystkie serwery EC2. Zanim funkcjonalność StackSet ujrzała światło dzienne, miałem przygotowany template, i kolejno uruchamiałem Stacki tam, gdzie zaszła taka potrzeba.
Popatrzmy teraz, jak to można zrobić szybciej i efektywnej z użyciem Stack Set. Moimi kontami zarządzam przy użyciu AWS Organizations. Zatem postanowiłem dystrybuować konfigurację z poziomu konta głównego i wdrażać je na konta laboratoryjne we wszystkich regionach. Zmieniłem lekko template CloudFormation i wrzuciłem kod funkcji lambda do środka, aby nie zakładać bucketów w każdym regionie (Stack może pobrać kod lambda tylko z S3 bucketu w tym samym regionie).
Zatem to dzieła:
- Logujemy się do konsoli AWS (wybierz preferowany przez siebie region) i wchodzimy do usługi CloudFormation.
- W serwisie CloudFormation klikamy w lewy górny róg i przechodzimy do StackSet i wybieramy Create StackSet:
- Teraz podobnie jak poprzednio wrzucamy template, nazwa StackSet i parametry Lambda.
- Teraz pojawiają się nowe opcje.
- Wskazujemy konta, na których mają powstać Stacki. Ewentualnie cały Organization Unit w AWS Organizations.
- Wybieramy Regiony, w których konfiguracja ma zostać zaimplementowana.
- Oraz dwa dodatkowe parametry. Pierwszy – na ilu kontach jednocześnie per region chcemy instalować szablon. Drugi parametr określa na ilu kontach per region może wystąpić błąd zanim cały StackSet przejdzie w status Failed. Dla moich potrzeb domyślne opcje były zupełnie wystarczające.
5.Kontynuujemy zabawę: Next, Tags, Review i Launch.
Dalej już pozostaje nam tylko obserwowanie postępu. W zakładce Operations widać progres i historię poprzednich operacji na całym StackSet.
Z kolei zakładka Stacks pokazuje status wszystkich Stacków, które są implementowane bądź aktualizowane.
Finalnym i oczekiwanym stanem powinno być osiągnięcie statusu CURRENT dla wszystkich Stacków oraz SUCCEEDED dla całego StackSet.
Ewentualne problemy z implementacją i komentarze również pojawią tutaj w zakładce Status reason.
Słów kilka o samym StackSets
Najprościej mówiąc przez StackSet można rozumieć mechanizm generujący za jednym zamachem kilka, kilkanaście zwyczajnie znanych do tej pory Stacków CloudFormation.
StackSets to po prostu konfiguracją określająca na jakich kontach (ewentualnie OU – w przypadku korzystania z usługi AWS organizations) i w jakich regionach mają zostać stworzone Stacki CF.
Warto jednak dobrze przemyśleć strategię granularności konfiguracji jaką chcemy implementować. Edytowanie zaimplementowanego StackSets ma pewną swoją charakterystykę. Dostępne są trzy opcje:
Pierwsza Create stack umożliwia dodanie kolejnych Stacków dla dodatkowych kont i regionów. Zaimplementowany zostanie ten same template CF.
Opcja Edit stack umożliwia upload nowego template, ale nie pozwala na wybór konta czy regionu. To dość istotne, gdyż zawsze zmiana zostanie wrzucona na wszystkie konta i regiony w danym StackSets. Dlatego warto rozważyć odrębne StackSets-y dla kont PROD, TEST czy DEV.
Z kolei opcja Delete Stack pozwala już wybrać pojedyncze konta i regiony, z których stacki zostaną usunięte.
Podsumowując, możemy dodawać, usuwać daną konfigurację z poszczególnych kont albo regionów. Natomiast zmieniać (edytować) konfigurację możemy tylko dla wszystkich.
Warto też zwrócić uwagę na nazewnictwo. Niektórzy do nazw tworzonych przez cloudformation obiektów dodają również nazwę samego stacka:
PolicyName: Fn::Sub: "${AWS::StackName}-MGMTEC2StopPol"
StackName tworzone przez StackSet są dość długie i jeśli np. nazwa IAM Roli okaże się dłuższa niż 64 znaki to proces tworzenia zakończy się błędem.
No i oczywiście AWS Lambda. To pozostaje bez zmian, jeśli uploadujemy kod z S3 nadal musimy mieć bucket w każdym regionie, który dodajemy do StackSets. Usunięcie tego ograniczenia byłoby tu dość pomocne.
Na koniec uprawnienia; zwłaszcza przy deploymencie na inne konta. Przy wyborze kont w pkt. 4 jest link z opisem, jakie uprawnienia musi posiadać konto, z którego uruchamiamy StackSets. Warto na to zwrócić uwagę.
I to w sumie wszystko. Nie wiem jak Tobie, ale mi StackSets-y wydają się dobrym usprawnieniem wartym uwagi.
Kod mojego template’u znajdziesz pod tym linkiem.
Link do oficjalnej dokumentacji tutaj.
Tekst ten oryginalnie pojawił się w moim gościnnym wpisie na blogu aws-blog.pl
Dodatkowo, przygotowałem nagranie, w którym krok po kroku pokazuję jak wykonać konfigurację. Tym razem użyłem innego szablonu (z postu Tomka – Kto utworzył ten serwer?!), który tworzy konfigurację tagującą każdą nową instancję EC2 nazwą użytkownika, który ją stworzył.
https://youtu.be/85zr2RP7DEU
Kod do tego szablonu znajduje się tutaj
Cheers!
Zbuduje swoje bezpieczne środowisko AWS.
