Jeśli chcesz zobaczyć kilka sposobów tagowania zasobów w chmurze AWS oraz poznać przykładowe wykorzystanie tego mechanizmu, to zapraszam Cię do przeczytania poniższego tekstu.
Jak tagować zasoby?
W artykule o zarządzaniu tagami wspominałem już czym są tagi oraz jak nimi zarządzać z poziomu organizacji AWS. Dzisiaj przyjrzyjmy się w jaki sposób możemy dodawać tagi do zasobów ze szczególnym uwzględnieniem Lambd, SQS, StepFunctions i LogGroups.
Ręcznie
Pierwszy oczywisty sposób, to użycie portalu AWS i dodanie tagów ręcznie. Zobaczmy jak to zrobić na przykładnie AWS Lambda.
Cel osiągnięty, ale oczywiście nie jest to najlepszy sposób, ponieważ jest kompletnie nie utrzymywalny. Jeżeli będziemy potrzebowali postawić stacka jeszcze raz, to tagów po prostu nie będzie.
Jeśli chodzi o inne wspomniane wcześniej zasoby, to dokładnie w taki sam sposób możemy dodać tagi do SQS i StepFunctions, ale niestety LogGroups tak nie obsłużymy.
AWS CLI
Inny sposób na dodanie tagów to użycie AWS CLI. Właśnie tego sposobu możemy użyć, by edytować tagi w LogGrupach.
By to zrobić skorzystamy z dwóch komend:
aws logs list-tags-log-groupaws logs tag-log-group
Na portalu AWS nie ma możliwości sprawdzenia jakie tagi przypięte są do LogGroup. Do sprawdzenia tego wykorzystamy pierwszą komendę. Potrzebujemy tylko nazwę zasobu.
PS > aws logs list-tags-log-group --log-group-name /aws/lambda/resources-tagging-app-ReceiveEventLambda-LV0Y851C6C2Y
{
"tags": {}
}Nie ma aktualnie żadnego taga, więc dodajmy go.
PS > aws logs tag-log-group --log-group-name /aws/lambda/resources-tagging-app-ReceiveEventLambda-LV0Y851C6C2Y --tags service-name=resource-taggingNa koniec sprawdźmy, czy tag faktycznie został dodany.
PS > aws logs list-tags-log-group --log-group-name /aws/lambda/resources-tagging-app-ReceiveEventLambda-LV0Y851C6C2Y
{
"tags": {
"service-name": "resource-tagging"
}
}Użycie AWS CLI pozwala oskryptować i zautomatyzować dodawanie tagów do zasobów, niemniej nadal wymaga od nas trochę zaangażowania i powoduje, że musimy pamiętać o modyfikacjach, gdy dodajemy nowe zasoby.
Przejdźmy więc do lepszych rozwiązań.
Tagi w CloudFormation
Z pomocą przychodzi mechanizm infrastructure as a code. Dzięki temu mechanizmowi możemy oznaczać zasoby tagami zapisując infrastrukturę w pliku yaml lub xml.
Przykładowe przypisanie tagów do kolejki SQS.
Queue:
Type: AWS::SQS::Queue
Properties:
Tags:
- Key: service-name
Value: resource-taggingRozwiązanie bardzo dobre, ponieważ pozwala zarządzać tagami w tym samym miejscu, co całą infrastrukturą oraz w pełni automatyzuje ten proces.
Niestety jest również kilka minusów. Po pierwsze dodając nowe zasoby musimy pamiętać o oznaczeniu ich wszystkimi stosowanymi przez nas tagami, co również powoduje rozrastanie się pliku z infrastrukturą. Największym jednak problemem jest to, że niektóre zasoby nadal nie mogą być oznaczane. Przykładem znowu są nieszczęsne LogGroupy.
Tagi na poziomie stacka CloudFormation
Innym sposobem tagowania zasobów przy użyciu CloudFormation są tagi na poziomie stacka CloudFormation. Tym razem nie dodajemy tagów podczas definiowania poszczególnych zasobów, a podczas deployowania stacka.
Możemy to zrobić używając AWS CLI,
PS > aws cloudformation deploy --tags "service-name=resource-tagging" "environment=dev"AWS SAM,
PS > sam deploy --tags service-name=resource-tagging environment=devczy dotnet lambda.
PS > dotnet lambda deploy-serverless --tags "service-name=resource-tagging;environment=dev"Dodanie taga na poziomie stacka CloudFormation powoduje propagowanie go podczas wdrażania do każdego zasobu zdefiniowanego w tym stacku. Niestety są wyjątki, które sprawiają, że nie jest to rozwiązanie idealne, którym zdecydowanie mogłoby być.
Żeby nie być gołosłownym, oto kilka problematycznych zasobów:
- LogGruop – tagi w ogóle nie są propagowane
- SQS – tagi są propagowane tylko podczas tworzenia zasobu, natomiast podczas updatów już nie
- StepFunctions – dokładnie tak jak przy SQS
- WAFv2 WebACL – tagi nie są propagowane
Lambda do tagowania zasobów
Łącząc kilka z wyżej wymienionych sposobów jesteśmy w stanie uzyskać zadowalający efekt. Na przykład tagując problematyczne zasoby w pliku z infrastrukturą oraz oznaczając stacka podczas wdrożenia, pokryjemy większość zasobów(oczywiście bez wspomnianych LogGroups).
Innym ciekawym rozwiązaniem jest wykorzystanie mechanizmów znanych z AWS CLI w kodzie. Możemy napisać prostą Lambdę, która na podstawie tagów, zdefiniowanych na poziomie stacka CloudFormation, będzie je przypinała do problematycznych zasobów.
Wspomnianą wyżej Lambdę możemy automatycznie wywoływać, gdy nastąpiło uaktualnienie jakiegokolwiek stacka CloudFormation. Wykorzystamy do tego subskrypcję na zdarzenia publikowane na EventBridge. Utworzymy subskrypcję na zdarzenie typu ExecuteChangeSet publikowane przez CloudFormation do CloudTrail, a później na EventBridge. Więcej o strukturze zdarzeń w EventBridge możesz przeczytać tutaj.
Poniżej znajduje się przykładowa implementacja przy użyciu AWS SAM.
TagResources:
Type: AWS::Serverless::Function
Properties:
Events:
CloudFormationEvent:
Type: CloudWatchEvent
Properties:
Pattern:
source:
- aws.cloudformation
detail-type:
- AWS API Call via CloudTrail
detail:
eventSource:
- cloudformation.amazonaws.com
eventName:
- ExecuteChangeSetPodczas pisania kodu do propagacji tagów wykorzystamy AWS SDK. By dowiedzieć się jak dodać tag do LogGroup w .Net Core zajrzyj tutaj, a jeśli wolisz Node.js, tutaj. Oczywiście analogiczne metody dostępne są w każdym wspieranym języku programowania.
Tego typu mechanizm przygotowany w formie opensource przez Lumigo można znaleźć w AWS Serverless Application Repository oraz na GitHubie. Na chwilę obecną wspierane są tylko LogGroups, SQS oraz StepFunctions. Oczywiście jako, że jest to rozwiązanie opensource, nic nie stoi na przeszkodzie, by dołożyć wsparcie dla innych zasobów.
Dzięki temu, że aplikacja dostępna jest poprzez AWS Serverless Application Repository, jesteśmy w stanie łatwo ją wdrożyć oraz utrzymywać.
Tag Editor
Warto jeszcze wspomnieć o Tag Editorze, w którym możemy wyszukać zasoby i edytować tagi dla całej grupy. Poniżej zobaczysz również jak używać tej usługi do wyszukiwania zasobów oznaczonych tym samym tagiem.
Po co tagować zasoby?
Skoro już wiemy jak tagować zasoby, to warto również pochylić się nad tym po co w ogóle nam te tagi. Przyjrzyjmy się kilku głównym strategiom oznaczania zasobów.
Grupowanie zasobów
Najbardziej oczywistym zastosowaniem tagów w chmurze AWS jest grupowanie zasobów. Przyjrzyjmy się kilku przykładom:
- service-name – grupowanie wszystkich zasobów należących do jednej aplikacji
- product-names – wszystkie zasoby należące do danego produktu
- processing-plane – rozróżnienie między zasobami do przetwarzania wsadowego, API oraz innymi typami
- owner – grupowanie po właścicielu zasobu, którym może być na przykład zespół
- security-sensitive – wyróżnienie zasobów posiadających wrażliwe dane
Tagi tego typu spełniają przede wszystkim dwa zadania. Po pierwsze łatwo można dowiedzieć się do kogo lub jakiej aplikacji należy zasób, wystarczy spojrzeć na tagi w jego konfiguracji.
Po drugie łatwo odnaleźć całą grupę zasobów, gdy poszukujemy na przykład wszystkich zasobów w obrębie aplikacji lub należących do tego samego właściciela.
Do wyszukiwania tego typu możemy wykorzystać AWS Resource Groups oraz Tag Editor.
W AWS Resource Groups możemy utworzyć i zapisać grupę zasobów na podstawie tagów.
Mierzenie kosztów
Wspomniane wcześniej tagi grupujące możemy również wykorzystać, by mierzyć koszta poszczególnych grup z podziałem na typy zasobów.
By to zrobić trzeba aktywować dany tag jako “Cost allocation tag”. Jak to zrobić? Wystarczy wejść na Cost allocation tags w Billing, zaznaczyć wybrane tagi i aktywować.
Teraz już możemy zacząć monitorować koszta poprzez Cost Explorer. Warto jednak pamiętać, że zliczanie kosztów rozpoczyna się w momencie aktywacji “Cost allocation taga”, a nie w oznaczenia zasobu, czyli aktywacja taga musi nastąpić jak najwcześniej.
By zobaczyć dane o konkretnej grupie musimy wybrać filtrowanie po tagu i jego wartości.
Teraz pozostało już tylko przeglądanie i analizowanie kosztów aplikacji z np. podziałem na typ zasobu. Jak łatwo zauważyć, czym więcej zasobów posiada tag informujący o tym do jakiej aplikacji należą, tym dane o kosztach będą dokładniejsze.
Jako, że kryterium grupowania zasoby zależy tylko i wyłącznie od nas, to koszta również możemy mierzyć na różnym poziomie. Nie tylko na poziomie aplikacji, ale również całego produktu oraz na przykład możemy sprawdzić ile kosztują zasoby zarządzane przez dany zespół.
Automatyka
Jednym z przykładów na wykorzystanie tagów do automatyzacji jest Lifecycle Manager, a dokładnie Snapshot Lifecycle Policy.
Zdefiniujmy nowy tag na instancji EC2, np. daily-snapshot o wartości 3 days.
Teraz możemy utworzyć politykę w Lifecycle Managerze, która będzie codziennie robić snapshot każdej instancji EC2, która jest oznaczona wyżej wspomnianym tagiem.
Nic nie stoi na przeszkodzie, by utworzyć drugą politykę, dla tego samego taga, ale z inną wartością, np. 7 days, która snapshoty będzie przechowywała przez 7 dni.
Monitoring
Jeszcze jednym sposobem wykorzystania tagów jest monitoring.
Przykładowo, jeżeli wszystkie kolejki SQS, które działają jako dead letter queue oznaczamy tagiem is-dlq o wartości true, to jesteśmy w stanie ustawić alert, który powiadomi nas o każdym nowym elemencie, który wpadnie na kolejkę tego typu. Dzięki temu możemy globalnie zdefiniować informowanie o błędach i nie martwić się obsługą w poszczególnych aplikacjach. Niestety aktualnie AWS nie daje takiej możliwości out of the box, ale jest powszechnie dostępna w narzędziach do monitorowania usług chmurowych, takich jak DataDog.
