W tym artykule przyjrzymy się ArgoCD Notifications — rozszerzeniu dla ArgoCD, które jest częścią ekosystemu narzędzi Argo. To rozszerzenie usprawnia proces CI/CD poprzez automatyzację powiadomień o zmianach statusu aplikacji.
Zagadnienia omawiane:
- Czym jest ArgoCD Notifications
- Instalacja przez Helm
- Konfiguracja
- Przypadek użycia: Rozszerzenie procesu CI/CD
ArgoCD Notifications – Wprowadzenie
ArgoCD Notifications wpisuje się w filozofię GitOps, pozwalając zespołom DevOps na automatyczne monitorowanie zmian w stanie aplikacji i reagowanie na nie. Dzięki integracji z różnymi serwisami powiadomień stanowi najważniejszy element usprawniający proces automatyzacji wdrożeń.
Kluczowe zalety ArgoCD Notifications to:
- Automatyzacja powiadomień – eliminacja manualnego monitorowania i informowania o zmianach
- Elastyczna konfiguracja – możliwość dostosowania triggerów i szablonów do potrzeb zespołu
- Integracja z popularnymi serwisami – wsparcie dla Slack, MS Teams, Email i innych
- Łatwa instalacja i konfiguracja – wykorzystanie Helm charts i ConfigMap
Rozszerzenie to jest szczególnie przydatne w dużych zespołach, gdzie koordynacja wdrożeń i szybka reakcja na zmiany są najważniejsze dla efektywności procesu CI/CD. Pozwala ono na natychmiastowe powiadamianie odpowiednich osób o statusie aplikacji, problemach z synchronizacją czy innych istotnych zdarzeniach.
W kontekście GitOps, ArgoCD Notifications zapewnia pełną transparentność procesu wdrożeniowego, umożliwiając zespołom DevOps skupienie się na rozwoju i optymalizacji, zamiast na ręcznym monitorowaniu statusów.
ArgoCD Notifications – Instalacja przez Helm
Instalacja jest prosta i szybka dzięki oficjalnemu chart’owi Helm:
helm repo add argo <https://argoproj.github.io/argo-helm> helm repo update helm upgrade --install argocd-notifications argo/argocd-notifications --namespace argocd
Proces instalacji ArgoCD Notifications rozpoczynamy od dodania repozytorium Argo poprzez ‘helm repo add argo https://argoproj.github.io/argo-helm‘. Ten krok jest konieczny tylko jeżeli nie mamy jeszcze skonfigurowanego repozytorium Argo.
Następnie wykonujemy polecenie:
helm repo update
które aktualizuje informacje o dostępnych pakietach w repozytorium. Jest to najważniejszy krok, który zapewnia dostęp do najnowszych wersji komponentów.
Ostatnim krokiem jest wykonanie adekwatnej instalacji poprzez:
helm upgrade --install argocd-notifications argo/argocd-notifications --namespace argocd
Flaga –install zapewnia, iż jeżeli komponent nie był wcześniej zainstalowany, zostanie utworzony, a jeżeli już istnieje – zostanie zaktualizowany do najnowszej wersji.
ArgoCD Notifications – Konfiguracja
Konfiguracja ArgoCD Notifications odbywa się głównie przez ConfigMap, który zawiera definicje triggerów, szablonów i serwisów powiadomień.
Komponenty konfiguracji:
Service (service.webhook.*):
- Definiuje konfigurację usługi do której będą wysyłane powiadomienia,
- Może być skonfigurowany dla różnych serwisów (Slack, Email, Webhook itp.)
Oto lista dostępnych serwisów do notyfikacji w Argo CD:
Alertmanager: Umożliwia wysyłanie alertów do Prometheus Alertmanager, co pozwala na centralne zarządzanie powiadomieniami o stanie aplikacji.
AWS SQS: Pozwala na wysyłanie powiadomień do kolejek Amazon Simple Queue Service, co umożliwia asynchroniczne przetwarzanie wiadomości.
Email: Umożliwia wysyłanie powiadomień e-mail, co pozwala na bezpośrednią komunikację z użytkownikami poprzez ich skrzynki pocztowe.
GitHub: Pozwala na aktualizację statusów commitów w repozytorium GitHub, co umożliwia śledzenie zmian w kodzie źródłowym.
Google Chat: Umożliwia wysyłanie powiadomień do przestrzeni i wątków Google Chat, co wspiera komunikację zespołową w czasie rzeczywistym.
Grafana: Pozwala na tworzenie i aktualizację adnotacji w Grafana, co ułatwia wizualizację danych i monitorowanie stanu aplikacji.
Mattermost: Umożliwia wysyłanie powiadomień do kanałów i użytkowników Mattermost, co wspiera współpracę zespołową.
NewRelic: Pozwala na integrację z platformą monitoringu NewRelic, co umożliwia śledzenie wydajności aplikacji.
Opsgenie: Umożliwia tworzenie i aktualizację alertów w systemie Opsgenie, co wspiera zarządzanie incydentami.
PagerDuty: Pozwala na tworzenie i aktualizację incydentów w systemie PagerDuty, co wspiera zarządzanie kryzysowe.
PagerDuty V2: Nowsza wersja integracji z PagerDuty, oferująca rozszerzone możliwości zarządzania incydentami.
Pushover: Umożliwia wysyłanie powiadomień push do urządzeń mobilnych dzięki usługi Pushover, co zapewnia szybkie informowanie użytkowników o ważnych zdarzeniach.
Rocket.Chat: Pozwala na wysyłanie powiadomień do kanałów Rocket.Chat, co wspiera komunikację zespołową.
Slack: Umożliwia wysyłanie powiadomień do kanałów i użytkowników Slack, co jest popularnym rozwiązaniem dla zespołów pracujących w trybie zdalnym.
Teams: Pozwala na wysyłanie powiadomień do kanałów Microsoft Teams, co wspiera współpracę zespołową w środowisku korporacyjnym.
Telegram: Umożliwia wysyłanie powiadomień do kanałów i użytkowników Telegram, co jest wygodnym sposobem komunikacji.
Webex Teams: Pozwala na wysyłanie powiadomień do przestrzeni Webex Teams, co wspiera współpracę zespołową.
Każdy z tych serwisów wymaga odpowiedniej konfiguracji w pliku ConfigMap `argocd-notifications-cm` oraz, w przypadku serwisów wymagających uwierzytelnienia, w sekrecie argocd-notifications-secret.
Template (template.*):
- Określa format i strukturę wysyłanego powiadomienia,
- Umożliwia przekazywanie wszystkich parametrów aplikacji ArgoCD dostępnych w kontekście, takich jak metadane, status, specyfikacja i inne adekwatności (np. {{.app.status.health.status}})
Każdy szablon może korzystać z następujących pól:
- app: Obiekt aplikacji, zawierający jej dane.
- context: Mapa klucz-wartość definiowana przez użytkownika, pozwalająca na dodanie dodatkowych informacji do powiadomień.
- secrets: Dostęp do danych wrażliwych przechowywanych w `argocd-notifications-secret`.
- serviceType: Typ serwisu notyfikacyjnego, np. “slack” lub “email”, umożliwiający warunkowe renderowanie pól specyficznych dla serwisu.
- recipient: Nazwa odbiorcy powiadomienia.
Dodatkowe funkcjonalności:
- Możliwość definiowania strefy czasowej w powiadomieniach dzięki funkcji `time`.
- Wykorzystanie wbudowanych funkcji, takich jak `strings.ReplaceAll`, `repo.GetCommitMetadata`, czy `sync.GetInfoItem`, do dynamicznego generowania treści powiadomień.
Szablony są wielokrotnego użytku i mogą być przypisane do wielu triggerów, co pozwala na elastyczne dostosowanie systemu powiadomień do potrzeb użytkownika.
Trigger (trigger.*):
- Określa warunki, które muszą zostać spełnione, aby wysłać powiadomienie
- Wykorzystuje warunki logiczne (when) do sprawdzania stanu aplikacji
- Wskazuje, który szablon (template) ma zostać użyty poprzez parametr send
W Argo CD dostępnych jest kilka wbudowanych triggerów, które można wykorzystać do automatyzacji powiadomień o zmianach stanu aplikacji. Oto lista najważniejszych triggerów wraz z krótkim opisem każdego z nich:
on-sync-status-unknown: Uruchamia się, gdy status synchronizacji aplikacji zmienia się na “Unknown”. Pozwala to gwałtownie zareagować na potencjalne problemy z aplikacją.
on-sync-failed: Aktywuje się, gdy proces synchronizacji aplikacji zakończył się niepowodzeniem. Umożliwia to natychmiastowe powiadomienie zespołu o problemach z wdrożeniem.
on-sync-running: Uruchamia się w momencie rozpoczęcia procesu synchronizacji aplikacji. Informuje to o trwających aktualizacjach aplikacji.
on-sync-succeeded: Aktywuje się po pomyślnym zakończeniu procesu synchronizacji aplikacji. Potwierdza to udane wdrożenie zmian.
on-health-degraded: Uruchamia się, gdy stan zdrowia aplikacji ulega pogorszeniu. Pozwala to gwałtownie zidentyfikować problemy z działaniem aplikacji.
on-deployed: Aktywuje się, gdy aplikacja jest zsynchronizowana i zdrowa. Informuje o pomyślnym wdrożeniu i prawidłowym działaniu aplikacji.
on-created: Uruchamia się w momencie utworzenia nowej aplikacji w Argo CD. Umożliwia to śledzenie dodawania nowych aplikacji do systemu.
on-deleted: Aktywuje się, gdy aplikacja zostaje usunięta z Argo CD. Pozwala to monitorować usuwanie aplikacji z systemu.
sync-operation-change: Obejmuje różne fazy operacji synchronizacji (Succeeded, Running, Error, Failed)
Każdy z tych triggerów można skonfigurować w pliku ConfigMap argocd-notifications-cm, dostosowując warunki ich uruchamiania oraz powiązane z nimi szablony powiadomień.
Dodawanie subskrypcji do aplikacji
Po skonfigurowaniu triggerów i szablonów, kolejnym krokiem jest dodanie subskrypcji do aplikacji ArgoCD. Dokonujemy tego poprzez dodanie odpowiednich adnotacji w manifeście aplikacji.
Format adnotacji jest następujący:
notifications.argoproj.io/subscribe.[trigger-name].[notification-service]W powyższym przykładzie:
- Aplikacja subskrybuje różne triggery: sync-operation-change, on-health-degraded, on-health-healthy i on-health-progressing.
- Wszystkie powiadomienia są kierowane do serwisu http-webhook
Dzięki tym adnotacjom, ArgoCD Notifications będzie automatycznie wysyłać powiadomienia do skonfigurowanego webhooka przy każdej zmianie stanu synchronizacji lub zdrowia aplikacji.
Restart kontrolera
Po wprowadzeniu zmian w ConfigMap, konieczne jest zrestartowanie kontrolera ArgoCD Notifications, aby zmiany zostały zastosowane. Możemy to zrobić dzięki następującego polecenia:
kubectl rollout restart deployment argocd-notifications-controller -n argocd
To polecenie spowoduje ponowne uruchomienie poda kontrolera, który odczyta zaktualizowaną konfigurację z ConfigMap. Restart jest bezpieczną operacją i nie wpływa na działające aplikacje – powoduje jedynie krótką przerwę w wysyłaniu powiadomień.
Należy pamiętać, iż niektóre serwisy powiadomień (np. Slack, Microsoft Teams) wymagają dodatkowej konfiguracji sekretów przed restartem kontrolera. Sekrety te zawierają tokeny dostępowe i są przechowywane w obiekcie Secret argocd-notifications-secret.
Przykładowo dla Slack należy rozbudować secret argocd-notifications-secret o token w sekcji stringData:
Dokumentacja konfiguracji: https://argo-cd.readthedocs.io/en/stable/operator-manual/notifications/
Przypadek użycia: Rozszerzenie procesu CI/CD
W moim scenariuszu użycia, ArgoCD Notifications rozwiązało istotną lukę w procesie CI/CD. Przed wprowadzeniem tego narzędzia proces wyglądał następująco:
- Odesłanie zmian przez programistę
- Zbudowanie kodu i obrazu dockerowego przez GitHub Actions
- W ostatnim kroku procesu CI, wyzwolenie workflow GitHub Actions na repozytorium z konfiguracją aplikacji ArgoCD
- Modyfikacja przez workflow GitHub Actions konfiguracji ArgoCD w repozytorium
- W ostatnim kroku procesu, request do webhooka make.com
- Scenariusz make.com przypisuje zadania do testerów
- Równolegle, w wyniku modyfikacji konfiguracji w repozytorium, ArgoCD zmienia konfigurację klastra
Problem polegał na tym, iż tester mógł otrzymać powiadomienie o możliwości testów zanim zmiany pojawiły się na klastrze lub gdy nie pojawiły się wcale z powodu błędu.
Po wprowadzeniu ArgoCD Notifications, proces został znacznie ulepszony i wygląda następująco:
- Odesłanie zmian przez programistę
- Zbudowanie kodu i obrazu dockerowego przez GitHub Actions
- W ostatnim kroku procesu CI, wyzwolenie workflow GitHub Actions na repozytorium z konfiguracją aplikacji ArgoCD
- Modyfikacja przez workflow GitHub Actions konfiguracji ArgoCD w repozytorium
- ArgoCD Notifications monitoruje status synchronizacji i zmiany stanu aplikacji
- Po pomyślnym wdrożeniu, ArgoCD Notifications automatycznie wysyła powiadomienie do webhooka make.com
- Scenariusz make.com przypisuje zadania do testerów tylko po otrzymaniu potwierdzenia sukcesu wdrożenia
Dzięki takiemu podejściu, proces jest w pełni zautomatyzowany i zsynchronizowany. Testerzy otrzymują powiadomienia tylko wtedy, gdy aplikacja jest rzeczywiście gotowa do testów, a w przypadku problemów z wdrożeniem, odpowiednie osoby są natychmiast informowane.
Podsumowanie
ArgoCD Notifications to narzędzie, które znacząco podnosi jakość procesu ciągłej integracji i wdrażania (CI/CD). Automatyzacja komunikacji o zmianach statusu aplikacji pozwala zespołom DevOps na natychmiastową reakcję na wszelkie zdarzenia w procesie wdrożeniowym, od pomyślnych deploymentów po potencjalne problemy.
W praktyce, wykorzystanie tego rozwiązania prowadzi do znaczącej poprawy efektywności zespołu poprzez eliminację manualnego monitorowania statusu wdrożeń. Automatyczne powiadomienia nie tylko oszczędzają czas, ale również redukują ryzyko przeoczenia istotnych zmian w infrastrukturze.
Autor
Emil Juchnikowski — pracuje jako Architekt Oprogramowania. Swoją karierę rozpoczął jako .NET Developer ponad 10 lat temu. Teraz już z technologią .NET ma bardzo mało wspólnego. Rozwija się w technologiach JS, w różnych kierunkach: frontend Angular i Ionic, backend NodeJS i NestJS, bazy danych MongoDB. Poza tym zajmuje się też zagadnieniami DevOps, GitOps opartymi o konteneryzację w Kubernetes. Poza pracą lubi biegać na długie dystanse oraz trenuje boks. Jego motto to: Jedynym ograniczeniem jest nasza wyobraźnia… a niektórzy twierdzą, iż jeszcze czas i pieniądze.
