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:
- Wszystko mamy zdefiniowane w szablonach CloudFormation (IaaC)
- Używamy jednego szablonu do tworzenia zasobów na wszystkich stagach (PROD, QA, itd.)
- 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:
- Backup z kopią do zapasowej lokalizacji (inny region AWS)
- 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:
- Tworzy AMI z działającej instancji EC2
- Aktualizuje Parametr SSM
- Wysła AMI do regionu Disaster Recovery
- 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?
- Backup takiego rozwiązania jest prosty jak budowa urządzenia do oddzielania ziarna od plew
- Dzięki automatycznemu aktualizowaniu stacków CloudFormation po zmienia parametrów w SSM, AutoScalling Group zawsze
- używa najświeższego dostępnego AMI (nie takiego sprzed roku)
- W przypadku awarii dwóch nodów klastra tracimy tylko dane z okresu od awarii do ostatniego backupu (RPO ze slangu środowisk backupowych)
- 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
- Nie trzymamy parametrów w plikach. Prostym API Call możemy wyświetlić aktualne wartości parametrów danego stage
- Mamy granularną kontrolę dostępu do poszczególnych parametrów (DEV tylko do ścieżki /dev/
- Wszystko się samo robi
Jeśli potrzebujesz pomocy przy automatyzacji swoich rozwiązań w chmurze skontaktuj się z nami.