Czy używasz Kubernetes? Jesteś gotów przenieść swoje instancje Camunda BPM z maszyn wirtualnych, a może po prostu spróbować uruchomić je na Kubernetes? Przyjrzyjmy się niektórym powszechnym konfiguracjom i poszczególnym elementom, które można dostosować do Twoich konkretnych potrzeb.
Zakłada się, że wcześniej korzystałeś z Kubernetes. Jeśli nie, to dlaczego nie zajrzeć do i nie uruchomić swojego pierwszego klastra?
Autorzy
- jest starszym inżynierem ds. niezawodności serwisu (Site Reliability Engineer) w zespole Camunda Cloud;
- jest inżynierem DevOps w Camunda.
Krótko mówiąc:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
No cóż, najprawdopodobniej to nie zadziałało, ponieważ nie masz zainstalowanego skaffold i kustomize. W takim razie czytaj dalej!
Czym jest Camunda BPM
Camunda BPM to platforma open source do zarządzania procesami biznesowymi i automatyzacji podejmowania decyzji, która łączy użytkowników biznesowych z programistami. Idealnie nadaje się do koordynacji i łączenia ludzi, (mikro)serwisów lub nawet botów! Więcej informacji na temat różnych zastosowań można znaleźć w .
Dlaczego warto używać Kubernetes
Kubernetes stał się standardem de facto do uruchamiania nowoczesnych aplikacji w systemie Linux. Dzięki zastosowaniu wywołań systemowych zamiast emulacji poziomu sprzętowego i możliwości rdzenia do zarządzania pamięcią i przełączaniem zadań, czas uruchamiania i czas początkowy są minimalizowane. Jednak największą korzyść może przynieść standardowy interfejs API, który Kubernetes udostępnia do konfigurowania infrastruktury wymaganej dla wszystkich aplikacji: pamięci masowej, sieci i monitoringu. W czerwcu 2020 roku obchodził swoje 6. urodziny, a to prawdopodobnie drugi co do wielkości projekt open source (po Linuksie). Ostatnio aktywnie stabilizuje swoje funkcjonalności po szybkim rozwoju w ostatnich latach, ponieważ staje się to kluczowe dla obciążeń produkcyjnych na całym świecie.
Silnik Camunda BPM może łatwo łączyć się z innymi aplikacjami działającymi w tej samej klastra, a Kubernetes zapewnia doskonałą skalowalność, pozwalając zwiększać koszty infrastruktury tylko wtedy, gdy jest to naprawdę konieczne (i łatwo je zmniejszać w razie potrzeby).
Jakość monitorowania znacznie poprawia się dzięki narzędziom takim jak Prometheus, Grafana, Loki, Fluentd i Elasticsearch, które umożliwiają centralne przeglądanie wszystkich obciążeń klastra. Dziś omówimy, jak wdrożyć eksportera Prometheus na maszynie wirtualnej Java (JVM).
Cele
Przyjrzyjmy się kilku obszarom, w których możemy skonfigurować obraz Dockera Camunda BPM (), aby dobrze współpracował z Kubernetesem.
- Dzienniki i metryki;
- Połączenia z bazą danych;
- Uwierzytelnianie;
- Zarządzanie sesjami.
Omówimy kilka sposobów realizacji tych celów i pokażemy cały proces w przejrzysty sposób.
Uwaga: Używasz wersji Enterprise? Sprawdź i zaktualizuj linki do obrazów w razie potrzeby.
Opracowywanie przepływu pracy
W tej demonstracji użyjemy Skaffold do budowania obrazów Dockera z Google Cloud Build. Posiada on dobrą obsługę różnych narzędzi (takich jak Kustomize i Helm), CI i narzędzi do budowy oraz dostawców infrastruktury. Plik skaffold.yaml.tmpl zawiera ustawienia dla Google Cloud Build i GKE, co zapewnia bardzo prosty sposób uruchomienia infrastruktury na poziomie przemysłowym.
make skaffold załadował kontekst Dockerfile do Cloud Build, zbudował obraz i zapisał go w GCR, a następnie zastosował manifesty do twojego klastra. To właśnie robi make skaffold, ale Skaffold ma wiele innych możliwości.
Dla szablonów yaml w Kubernetes używamy kustomize do zarządzania nakładkami yaml bez rozgałęzania całego manifestu, co pozwala na użycie git pull --rebase do dalszych ulepszeń. Obecnie jest to w kubectl i całkiem nieźle działa w takich przypadkach.
Używamy również envsubst do wypełnienia nazwy hosta i identyfikatora projektu GCP w plikach * .yaml.tmpl. Możesz zobaczyć, jak to działa w makefile lub po prostu kontynuować dalej.
Wymagania wstępne
- Działający klaster
- — do tworzenia własnych obrazów docker i łatwego wdrażania w GKE
- Kopia tego kodu
- Envsubst
Przepływ pracy z manifestami
Jeśli nie chcesz używać kustomize lub skaffold, możesz odwołać się do manifestów w generated-manifest.yaml i dostosować je do przepływu pracy według własnego wyboru.
Dzienniki i metryki
Prometheus stał się standardem zbierania metryk w Kubernetes. Zajmuje tę samą niszę co AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics i inne. Ma otwarty kod źródłowy i potężny język zapytań. Wizualizację zrealizujemy za pomocą Grafana — dostarczającego wiele paneli monitorujących dostępnych od ręki. Są one ze sobą powiązane i stosunkowo łatwe do zainstalowania z .
Domyślnie Prometheus używa modelu pobierania /metrics, a dodawanie kontenerów sidecar do tego jest powszechne. Niestety, metryki JMX najlepiej rejestrować wewnątrz JVM, więc kontenery sidecar nie są tak efektywne. Podłączmy z otwartym kodem źródłowym od Prometheus do JVM, dodając go do obrazu kontenera, który zapewni ścieżkę /metrics na innym porcie.
Dodaj Prometheus jmx_exporter do kontenera
-- obrazy/camunda-bpm/Dockerfile
OD zcamunda/camunda-bpm-platform:tomcat-7.11.0
## Add prometheus exporter
RUN wget https://repo1.maven.org/maven2/io/prometheus/jmx/
jmx_prometheus_javaagent/0.11.0/jmx_prometheus_javaagent-0.11.0.jar -P lib/
#9404 is the reserved prometheus-jmx port
ENV CATALINA_OPTS -javaagent:lib/
jmx_prometheus_javaagent-0.11.0.jar=9404:/etc/config/prometheus-jmx.yaml
No cóż, to było łatwe. Eksporter będzie monitorować tomcat i wyświetlać jego metryki w formacie Prometheus pod adresem :9404/metrics
Konfiguracja eksportera
Uważny czytelnik może zapytać, skąd się wziął prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Dodamy tomcat jako w Kubernetes, a następnie zamontujemy go jako wolumin.
Po pierwsze, dodajemy plik konfiguracyjny eksportera do naszego katalogu platform/config/
platform/config
└── prometheus-jmx.yaml
Następnie dodajemy do kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
To doda każdy element files[] jako element konfiguracji ConfigMap. ConfigMapGenerators są dobre, ponieważ haszują dane w konfiguracji i inicjują ponowne uruchomienie poda, jeśli się zmienia. Zmniejszają również objętość konfiguracji w Deployment, ponieważ możesz zamontować cały 'folder' plików konfiguracyjnych w jednym VolumeMount.
Na koniec musimy zamontować ConfigMap jako wolumin do poda:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
volumes:
- name: config
configMap:
name: config
defaultMode: 0744
containers:
- name: camunda-bpm
volumeMounts:
- mountPath: /etc/config/
name: config
[...]
Świetnie. Jeśli Prometheus nie jest skonfigurowany do pełnego czyszczenia, być może będziesz musiał go poprosić o usunięcie podów. Użytkownicy Prometheus Operator mogą używać service-monitor.yaml aby rozpocząć pracę. Zbadaj Service-monitor.yaml, i zanim przejdziesz dalej.
Rozprzestrzenienie tego szablonu na inne przypadki użycia
Wszystkie pliki, które dodajemy do ConfigMapGenerator, będą dostępne w nowym katalogu /etc/config. Możesz rozszerzyć ten szablon, aby zamontować wszelkie inne potrzebne pliki konfiguracyjne. Możesz nawet zamontować nowy skrypt uruchamiający. Możesz użyć do montowania pojedynczych plików. Aby zaktualizować pliki xml, rozważ użycie zamiast sed. Jest on już w obrazie.
Logi
Dobre wieści! Logi aplikacji są już dostępne na stdout, na przykład za pomocą kubectl logs. Fluentd (który jest domyślnie zainstalowany w GKE) przekieruje Twoje logi do Elasticsearch, Loki lub do Twojej firmowej platformy logowania. Jeśli chcesz użyć jsonify do logów, możesz skorzystać z powyższego szablonu, aby zainstalować .
Baza danych.
Domyślnie obraz będzie miał bazę danych H2. To nam nie odpowiada, więc będziemy używać Google Cloud SQL z Cloud SQL Proxy — to będzie potrzebne później do rozwiązywania wewnętrznych zadań. To prosta i niezawodna opcja, jeśli nie masz własnych preferencji w zakresie konfiguracji bazy danych. AWS RDS oferuje podobną usługę.
Niezależnie od wybranej bazy danych, o ile nie jest to H2, musisz ustawić odpowiednie zmienne środowiskowe w platform/deploy.yaml. Wygląda to mniej więcej tak:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
containers:
- name: camunda-bpm
środowisko:
- nazwa: DB_DRIVER
wartość: org.postgresql.Driver
- nazwa: DB_URL
wartość: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- nazwa: DB_USERNAME
wartośćZ:
secretKeyRef:
nazwa: cambpm-db-credentials
klucz: db_username
- nazwa: DB_PASSWORD
wartośćZ:
secretKeyRef:
nazwa: cambpm-db-credentials
klucz: db_password
[...]
Uwaga: Możesz użyć Kustomize do wdrożenia w różnych środowiskach korzystając z overlay: .
Uwaga: użycie valueFrom: secretKeyRef. Proszę, użyj nawet podczas rozwoju, aby chronić swoje sekrety.
Bardzo prawdopodobne, że masz już preferowany system zarządzania sekretami Kubernetes. Jeśli nie, oto kilka opcji: szyfrowanie ich za pomocą KMS swojego dostawcy chmury, a następnie wprowadzenie ich do K8S jako sekrety przez pipeline CD — bardzo dobrze współpracuje z sekretami Kustomize. Są też inne narzędzia, takie jak dotGPG — te wykonują podobne funkcje: , .
Ingress
Jeśli nie zdecydujesz się użyć przekierowania lokalnego portu, będziesz potrzebować skonfigurowanego Ingress Controller. Jeśli nie korzystasz z () to prawdopodobnie już wiesz, że musisz zainstalować odpowiednie adnotacje w ingress-patch.yaml.tmpl lub platform/ingress.yamlJeśli używasz ingress-nginx i widzisz klasę ingress nginx z balancerem obciążenia wskazującym na niego oraz zewnętrzny DNS lub rekord wildcard DNS — wszystko jest gotowe. W przeciwnym razie skonfiguruj Ingress Controller oraz DNS lub pomiń te kroki i pozostaw bezpośrednie połączenie z pod.
TLS
Jeśli korzystasz z lub kube-lego i letsencrypt — certyfikaty dla nowego wejścia będą uzyskiwane automatycznie. W przeciwnym razie otwórz ingress-patch.yaml.tmpl i dostosuj go do swoich potrzeb.
Uruchomienie!
Jeśli przestrzegałeś wszystkiego, co zostało napisane powyżej, to komenda make skaffold HOSTNAME= powinna uruchomić dostępny instancję w /camunda
Jeśli nie wystawiłeś wejścia przez publiczny adres URL, możesz przekierować go z localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda
Poczekaj kilka minut, aż tomcat będzie w pełni gotowy. Cert-manager potrzebuje trochę czasu na weryfikację nazwy domeny. Po tym możesz śledzić logi przy użyciu dostępnych narzędzi — na przykład takiego jak kubetail, lub po prostu użyć kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Następne kroki
Autoryzacja
To bardziej odnosi się do konfiguracji Camunda BPM niż do Kubernetes, ale ważne jest, aby zauważyć, że domyślnie w REST API uwierzytelnianie jest wyłączone. Możesz lub użyć innej metody, na przykład . Możesz używać configmaps i wolumenów do ładowania xml, lub xmlstarlet (patrz powyżej), aby edytować istniejące pliki w obrazie, a także albo używać wget, albo ładować je za pomocą kontenera init oraz wspólnego wolumenu.
Zarządzanie sesjami
Podobnie jak wiele innych aplikacji, Camunda BPM zarządza sesjami w JVM, więc jeśli chcesz uruchomić wiele repliki, możesz włączyć sticky sessions (), które będą istnieć, dopóki replika nie zniknie, lub ustawić atrybut Max-Age dla plików cookie. Jako bardziej niezawodne rozwiązanie można wdrożyć Session Manager w Tomcat. Lars ma na ten temat, ale coś w stylu:
wget http://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager/
2.3.2/memcached-session-manager-2.3.2.jar -P lib/ &&
wget http://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager-tc9/
2.3.2/memcached-session-manager-tc9-2.3.2.jar -P lib/ &&
sed -i '/^/i
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis-proxy.db:22121"
sticky="false"
sessionBackupAsync="false"
storageKeyPrefix="context"
lockingMode="auto"
/>' conf/context.xml
Uwaga: możesz użyć xmlstarlet zamiast sed
Używaliśmy przed Google Cloud Memorystore, z (wspiera Redis) do jego uruchomienia.
Skalowanie
Jeśli już opanowałeś sesje, to pierwszym (a często ostatnim) ograniczeniem skalowania Camunda BPM może być połączenie z bazą danych. Częściowa konfiguracja jest dostępna już. Odłączmy także intialSize w pliku settings.xml. Dodaj i będziesz mógł łatwo automatycznie skalować liczbę podów.
Żądania i limity
W platform/deployment.yaml zobaczysz, że sztywno zakodowaliśmy pole zasobów. Działa to dobrze z HPA, ale może być potrzebna dodatkowa konfiguracja. W tym celu przyda się łatka kustomize. Zob. ingress-patch.yaml.tmpl i ./kustomization.yaml.tmpl
Wnioski
Oto zainstalowaliśmy Camunda BPM na Kubernetes z metrykami Prometheus, dziennikami, bazą danych H2, TLS i Ingress. Dodaliśmy pliki jar oraz pliki konfiguracyjne, wykorzystując ConfigMaps i Dockerfile. Omówiliśmy wymianę danych z wolumenami oraz bezpośrednio w zmienne środowiskowe z sekretów. Oprócz tego przedstawiliśmy przegląd konfiguracji Camunda z wieloma replikami i uwierzytelnionym API.
Linki
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest do użycia bez kustomize
├── obrazy
│ └── camunda-bpm
│ └── Dockerfile <- nakładka na obraz dockera
├── ingress-patch.yaml.tmpl <- specyficzna konfiguracja ingressu
├── kustomization.yaml.tmpl <- główny plik Kustomization
├── Makefile <- cele make
├── namespace.yaml
├── platforma
│ ├── konfiguracja
│ │ └── prometheus-jmx.yaml <- plik konfiguracyjny eksportera prometheus
│ ├── deployment.yaml <- główny deployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "bazowa" kustomizacja
│ ├── service-monitor.yaml <- przykład konfiguracji prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- dyrektywy skaffold
05.08.2020, tłumaczenie Alastair Firth, Lars Lange
Źródło: habr.com
