_Parametry SSM w automatyzacji AWS

Jakiś czas temu zostałem zaangażowany w projekt, który miał dostarczyć Windchilla w sposób wysoko dostępny – w sumie nic nowego, klaster załatwia sprawę i w zasadzie można by na tym zakończyć temat, ale…

Hostujemy całe rozwiązanie (PROD, QA, TEST i DEV) w AWS i fajnie by było mieć to wszystko na tyle zautomatyzowane, żeby nie zastanawiać się i nie pisać setek stron dokumentacji jak wprowadzić zmiany, albo jak naprawić jakieś środowisko.

O Windchillu i jego oporności na automatyzacje można napisać kolejny artykuł – ale to już ktoś inny, ja skupie się na automatyzacji związanej z utrzymaniem systemów przy życiu.

Kilka założeń na dobry początek:

1. Wszystko mamy zdefiniowane w szablonach CloudFormation (IaaC)
2. Używamy jednego szablonu do tworzenia zasobów na wszystkich stagach (PROD, QA, itd.)
3. Mamy gotowe AMI, które dzięki skryptom startowym umie się odnaleźć w sytuacji i się dostosować

Z wymagań projektowych przyszło też kilka wymagań, które mają istotne znaczenie na dalsze projektowanie rozwiązania:

1. Backup z kopią do zapasowej lokalizacji (inny region AWS)
2. Odtwarzanie środowiska QA z aktualnego stanu produkcji

Biorąc powyższe wymagania i założenia trzeba było zrobić tak, żeby się samo robiło, a jednocześnie było na tyle elastyczne, żeby pozwalało na wprowadzanie zmian (np. odtworzenie QA ze wskazanego AMI i Snapshota RDS)

Szablony CloudFormation

Zgodnie z założeniami, wszystko co dzieje się z zasobami ma być robione poprzez szablony CloudFormation, które dodatkowo trzymamy w repozytorium, żeby wiedzieć kto i kiedy przy tym majstrował.
Dla uproszczenia, weźmy samego Windchilla, do którego potrzebujemy dwóch szablonów CloudFormation:

• Szablon z definicją AutoScalling Group i używanego przez nią LaunchTemplate
• Szablon z definicją bazy danych (RDS)

W obu szablonach musimy podać kilka wartości parametrów, które dla każdego stage będą inne a dodatkowo będą łatwo modyfikowalne. Można użyć plików json z parametrami, ale ich automatyczna aktualizacja w repozytorium wydaje się zadaniem mało przyjemnym.

Tu z pomocą przychodzą wspomniane już parametry SSM. Czym on właściwie są?

Czym właściwie są parametry SSM

Parametry Systems Managera (Parameter Store) to w uproszczeniu system pozwalający na przetrzymywanie wartości pod określonym kluczem, z możliwością szyfrowania i pozwalające na dokładne zarządzanie dostępem do konkretnego parametru i jego wersji.

Zmiany wartości parametru można dokonać prostym wywołaniem API używając np. AWS CLI lub któregoś z dostępnych SDK (np. boto3)
Dodatkowo CloudFormation i sam SystemsManager mają wbudowaną integrację z parametrami SSM pozwalającą na odczyt wartości podczas tworzenia i aktualizacji Stacka CloudFormation lub wywoływania dokumentów SSM.

Dzięki temu mamy proste w obsłudze miejsce w którym możemy trzymać wartości parametrów szablonów CloudFormation.

Na co to pozwala?

Automatyzacja z CloudFormation i SSM.

Wróćmy do Windchilla (chociaż może być to każda inna aplikacja), mamy dwa szablony CloudFormation, które potrzebują kilku parametrów:

Szablon z AutoScaling Group i Launch Template:

• AMI ID – żeby wiedzieć, jakiego AMI użyć w Launch Template
• Desired Count – żeby wiedzieć, ile maszyn ma być uruchomionych

Szablon z bazą danych:

• RDS Snapshot Id – żeby wiedzieć z jakiego Snapshota odwinąć bazę danych

Poniżej diagram, który to obrazuje.

W sumie niewiele się różni od zakodowania tych wartości na stałe w template, a jednak się różni.

Parametry możemy modyfikować przez API, co za tym idzie możemy w łatwy sposób np. funkcją Lambda zmieniać wartość poszczególnych parametrów. Dodatkowo parametry możemy grupować ścieżką (jak katalogi). Na diagramie mamy ścieżkę „/dev/”. Dzięki temu, możemy stworzyć zestawy parametrów dla każdego stage: „/dev/”, „/qa/”, „/prod/” i trzymać tam właściwe dla danego Stage wartości.

Zmienimy wartość parametru i co?

To zależy. CloudWatch Events potrafi wykryć zmianę parametru, co możemy wykorzystać do uruchomienia funkcji Lambda, która wywoła nam aktualizację stacka CloudFormation. Np. tak

W momencie wywołania lambdy aktualizującej stack, CloudFormation pobierze aktualne parametry z SSM i zastosuje do zasobów. Oczywiście należy z tym uważać i sprawdzić w dokumentacji, zmiana jakich parametrów jest bezpieczna, a których spowoduje wymianę zasobu (np. bazy danych).

Sama funkcja update-stack ma przełącznik „–use-previous-template” który pozwala na użycie aktualnego szablonu do aktualizacji stacku co w tym przypadku jest bardzo przydatne.

Nie musimy się martwić o:

• trzymanie szablonu w S3,
• dostępem do szablonu z poziomu funkcji
• użyciem niewłaściwego szablonu

Jak to się ma do backupu?

Jako system Bakupu możemy zastosować AWS Step Functions, które pozwalają na orkiestracje funkcji Lambda. Taki system w zasadzie wykonuje 3 kroki:

1. Tworzy AMI z działającej instancji EC2
2. Aktualizuje Parametr SSM
3. Wysła AMI do regionu Disaster Recovery
4. Opcjonalnie może wywołać funkcję aktualizującą Stack, jeżeli nie jest zaimplementowane uruchamianie z poziomu CloudWatch Events

A jak sprawdzić ten backup?

Robienie backupu to jedna cześć procesu, aby mieć pewność, że backup działa i jest prawidłowy należy co jakiś czas go sprawdzać.

Tu wracamy do wymagań projektowych, które zakładają odtwarzanie środowiska QA z aktualnego stanu produkcji. Zatem codziennie rano uruchamiany jest automatyczny proces, który z tych samych szablonów CloudFormation buduje całe środowisko QA wykorzystując najświeższe AMI i Snapshoty zrobione przez system Backupowy, działając w zupełnej nieświadomości istnienia takiego systemu.

Co zyskujemy?

1. Backup takiego rozwiązania jest prosty jak budowa urządzenia do oddzielania ziarna od plew
2. Dzięki automatycznemu aktualizowaniu stacków CloudFormation po zmienia parametrów w SSM, AutoScalling Group zawsze
3. używa najświeższego dostępnego AMI (nie takiego sprzed roku)
4. W przypadku awarii dwóch nodów klastra tracimy tylko dane z okresu od awarii do ostatniego backupu (RPO ze slangu środowisk backupowych)
5. W przypadku konieczności cofnięcia się do konkretnego miejsca w czasie, ustawiamy parametry SSM na właściwe AMI i Snapshoty i aktualizujemy stacki
6. Nie trzymamy parametrów w plikach. Prostym API Call możemy wyświetlić aktualne wartości parametrów danego stage
7. Mamy granularną kontrolę dostępu do poszczególnych parametrów (DEV tylko do ścieżki /dev/
8. Wszystko się samo robi

Jeśli potrzebujesz pomocy przy automatyzacji swoich rozwiązań w chmurze skontaktuj się z nami.