Používate Kubernetes? Ste pripravení presunúť svoje inštancie Camunda BPM z virtuálnych počítačov alebo ich možno len skúsiť spustiť na Kubernetes? Pozrime sa na niektoré bežné konfigurácie a jednotlivé položky, ktoré je možné prispôsobiť vašim špecifickým potrebám.
Predpokladá sa, že ste už Kubernetes používali. Ak nie, prečo sa nepozrieť a nezačať svoj prvý klaster?
Autori
- (Alastair Firth) - Senior Site Reliability Engineer v tíme Camunda Cloud;
- (Lars Lange) – inžinier DevOps v Camunde.
V skratke:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Dobre, asi to nefungovalo, pretože nemáte nainštalované skaffold a kustomize. Tak čítajte ďalej!
Čo je Camunda BPM
Camunda BPM je open source platforma pre riadenie obchodných procesov a automatizáciu rozhodovania, ktorá spája podnikových používateľov a vývojárov softvéru. Je ideálny na koordináciu a spájanie ľudí, (mikro) služieb alebo dokonca robotov! Viac o rôznych prípadoch použitia si môžete prečítať na .
Prečo používať Kubernetes
Kubernetes sa stal de facto štandardom pre spustenie moderných aplikácií na Linuxe. Použitím systémových volaní namiesto emulácie hardvéru a schopnosti jadra spravovať prepínanie pamäte a úloh sú časy zavádzania a spúšťania obmedzené na minimum. Najväčšiu výhodu však môže priniesť štandardné API, ktoré Kubernetes poskytuje na konfiguráciu infraštruktúry vyžadovanej všetkými aplikáciami: úložisko, sieťovanie a monitorovanie. V júni 2020 mal 6 rokov a je možno druhým najväčším open source projektom (po Linuxe). Nedávno aktívne stabilizoval svoju funkčnosť po rýchlej iterácii za posledných niekoľko rokov, pretože sa stala kritickou pre produkčné pracovné zaťaženie na celom svete.
Camunda BPM Engine sa dokáže jednoducho pripojiť k iným aplikáciám bežiacim na rovnakom klastri a Kubernetes poskytuje vynikajúcu škálovateľnosť, ktorá vám umožní zvýšiť náklady na infraštruktúru len vtedy, keď je to skutočne potrebné (a jednoducho ich podľa potreby znížiť).
Kvalita monitorovania je tiež výrazne vylepšená pomocou nástrojov ako Prometheus, Grafana, Loki, Fluentd a Elasticsearch, ktoré vám umožňujú centrálne prezerať všetky pracovné zaťaženia v klastri. Dnes sa pozrieme na to, ako implementovať exportér Prometheus do Java Virtual Machine (JVM).
ciele
Pozrime sa na niekoľko oblastí, v ktorých môžeme prispôsobiť obrázok Camunda BPM Docker (), aby dobre spolupracoval s Kubernetes.
- Protokoly a metriky;
- Pripojenie k databáze;
- Overenie;
- Správa relácií.
Pozrieme sa na niekoľko spôsobov, ako tieto ciele dosiahnuť a názorne si ukážeme celý proces.
Poznámka: Používate verziu Enterprise? Pozri a podľa potreby aktualizujte odkazy na obrázky.
Rozvoj pracovného toku
V tejto ukážke použijeme Skaffold na vytváranie obrázkov Docker pomocou služby Google Cloud Build. Má dobrú podporu pre rôzne nástroje (napríklad Kustomize a Helm), nástroje CI a zostavovania a poskytovateľov infraštruktúry. Súbor skaffold.yaml.tmpl obsahuje nastavenia pre Google Cloud Build a GKE, ktoré poskytujú veľmi jednoduchý spôsob spustenia infraštruktúry na produkčnej úrovni.
make skaffold načíta kontext Dockerfile do Cloud Build, vytvorí obraz a uloží ho do GCR a potom použije manifesty na váš klaster. Toto robí make skaffold, ale Skaffold má mnoho ďalších funkcií.
Pre šablóny yaml v Kubernetes používame kustomize na správu prekrytí yaml bez rozvetvenia celého manifestu, čo vám umožňuje používať git pull --rebase pre ďalšie vylepšenia. Teraz je to v kubectl a na takéto veci to funguje celkom dobre.
Envsubst tiež používame na vyplnenie názvu hostiteľa a ID projektu GCP v súboroch *.yaml.tmpl. Môžete vidieť, ako to funguje v makefile alebo pokračujte ďalej.
predpoklady
- Pracovný klaster
- - na vytváranie vlastných obrazov dockerov a jednoduché nasadenie do GKE
- Kópia tohto kódu
- Envsubst
Pracovný postup pomocou manifestov
Ak nechcete použiť kustomize alebo skaffold, môžete si pozrieť manifesty v generated-manifest.yaml a prispôsobte ich pracovnému postupu podľa vášho výberu.
Protokoly a metriky
Prometheus sa stal štandardom pre zhromažďovanie metrík v Kubernetes. Zaberá rovnaké miesto ako AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics a ďalšie. Je to open source a má výkonný dopytovací jazyk. Vizualizáciu zveríme spoločnosti Grafana – dodáva sa s veľkým množstvom dashboardov dostupných hneď po vybalení. Sú navzájom prepojené a ich inštalácia je pomerne jednoduchá .
Prometheus štandardne používa model extrakcie <service>/metricsa pridávanie kontajnerov postranných vozíkov je bežné. Bohužiaľ, metriky JMX sa najlepšie zaznamenávajú v rámci JVM, takže kontajnery postranných vozíkov nie sú také efektívne. Poďme sa spojiť open source z Prometheus do JVM jeho pridaním do obrazu kontajnera, ktorý poskytne cestu /metrics v inom prístave.
Pridajte Prometheus jmx_exporter do kontajnera
-- images/camunda-bpm/Dockerfile
FROM camunda/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 to bolo ľahké. Exportér bude sledovať kocúra a zobrazí jeho metriky vo formáte Prometheus na <svc>:9404/metrics
Nastavenie exportéra
Pozorný čitateľ sa môže čudovať, odkiaľ sa to vzalo prometheus-jmx.yaml? V JVM je možné spustiť veľa rôznych vecí a kocúr je len jednou z nich, takže exportér potrebuje nejakú dodatočnú konfiguráciu. K dispozícii sú štandardné konfigurácie pre kocúra, divú mušku, kafku a tak ďalej . Pridáme kocúra ako v Kubernetes a potom ho pripojte ako zväzok.
Najprv pridáme konfiguračný súbor exportéra do nášho adresára platform/config/
platform/config
└── prometheus-jmx.yaml
Potom pridáme в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Tým sa pridá každý prvok files[] ako konfiguračný prvok ConfigMap. ConfigMapGenerators sú skvelé, pretože hashujú konfiguračné údaje a vynútia reštart modulu, ak sa zmenia. Tiež znižujú množstvo konfigurácie v Deployment, pretože môžete pripojiť celý „priečinok“ konfiguračných súborov do jedného VolumeMount.
Nakoniec musíme pripojiť ConfigMap ako zväzok k modulu:
-- 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
[...]
úžasné. Ak Prometheus nie je nakonfigurovaný na úplné vyčistenie, možno mu budete musieť povedať, aby vyčistil struky. Používatelia Prometheus Operator môžu používať service-monitor.yaml začať. Preskúmajte Service-monitor.yaml, и predtým ako začneš.
Rozšírenie tohto vzoru na ďalšie prípady použitia
Všetky súbory, ktoré pridáme do ConfigMapGenerator, budú dostupné v novom adresári /etc/config. Túto šablónu môžete rozšíriť na pripojenie akýchkoľvek iných konfiguračných súborov, ktoré potrebujete. Môžete dokonca pripojiť nový spúšťací skript. Môžeš použiť na pripojenie jednotlivých súborov. Ak chcete aktualizovať súbory xml, zvážte použitie namiesto sed. Je už zahrnutý na obrázku.
Časopisy
Skvelá správa! Protokoly aplikácií sú už dostupné na stdout, napríklad s kubectl logs. Fluentd (štandardne nainštalovaný v GKE) odošle vaše záznamy do Elasticsearch, Loki alebo vašej podnikovej logovacej platformy. Ak chcete používať jsonify pre protokoly, môžete nainštalovať podľa vyššie uvedenej šablóny .
databázy
V predvolenom nastavení bude mať obrázok databázu H2. Toto pre nás nie je vhodné a budeme používať Google Cloud SQL s Cloud SQL Proxy – to bude potrebné neskôr na riešenie interných problémov. Toto je jednoduchá a spoľahlivá možnosť, ak nemáte svoje vlastné preferencie pri nastavovaní databázy. AWS RDS poskytuje podobnú službu.
Bez ohľadu na databázu, ktorú si vyberiete, pokiaľ to nie je H2, budete musieť nastaviť príslušné premenné prostredia v platform/deploy.yaml. Vyzerá to asi takto:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
containers:
- name: camunda-bpm
env:
- name: DB_DRIVER
value: org.postgresql.Driver
- name: DB_URL
value: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: cambpm-db-credentials
key: db_username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: cambpm-db-credentials
key: db_password
[...]
Poznámka: Kustomize môžete použiť na nasadenie do rôznych prostredí pomocou prekrytia: .
Poznámka: použitie valueFrom: secretKeyRef. Prosím použite aj počas vývoja, aby boli vaše tajomstvá v bezpečí.
Je pravdepodobné, že už máte preferovaný systém na správu tajomstiev Kubernetes. Ak nie, tu je niekoľko možností: Zašifrovať ich pomocou KMS vášho poskytovateľa cloudu a potom ich vložiť do K8S ako tajomstvá prostredníctvom kanála CD − - bude fungovať veľmi dobre v kombinácii s tajomstvom Kustomize. Existujú aj iné nástroje, ako napríklad dotGPG, ktoré vykonávajú podobné funkcie: , .
Ingress
Ak sa nerozhodnete použiť lokálne presmerovanie portov, budete potrebovať nakonfigurovaný kontrolér vstupu. Ak nepoužívate (), potom už s najväčšou pravdepodobnosťou viete, že musíte nainštalovať potrebné anotácie ingress-patch.yaml.tmpl alebo platform/ingress.yaml. Ak používate ingress-nginx a vidíte vstupnú triedu nginx s nástrojom na vyrovnávanie záťaže, ktorý na ňu ukazuje, a externým záznamom DNS alebo zástupným znakom DNS, môžete začať. V opačnom prípade nakonfigurujte Ingress Controller a DNS alebo tieto kroky preskočte a ponechajte priame pripojenie k modulu.
TLS
Ak používate alebo kube-lego a letsencrypt - certifikáty pre nové prihlásenie sa získajú automaticky. V opačnom prípade otvorte ingress-patch.yaml.tmpl a prispôsobte si ho tak, aby vyhovoval vašim potrebám.
Spustiť!
Ak ste dodržali všetko napísané vyššie, potom príkaz make skaffold HOSTNAME=<you.example.com> by mal spustiť dostupnú inštanciu v <hostname>/camunda
Ak ste svoje prihlásenie nenastavili na verejnú adresu URL, môžete ju presmerovať pomocou localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda
Počkajte niekoľko minút, kým nebude kocúr úplne pripravený. Správcovi certifikátov bude chvíľu trvať, kým overí názov domény. Potom môžete sledovať protokoly pomocou dostupných nástrojov, ako je nástroj ako kubetail, alebo jednoducho pomocou kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Ďalšie kroky
Povolenie
Toto je dôležitejšie pre konfiguráciu Camunda BPM ako Kubernetes, ale je dôležité poznamenať, že v predvolenom nastavení je autentifikácia v REST API zakázaná. Môžeš alebo použite inú metódu, napr . Môžete použiť konfiguračné mapy a zväzky na načítanie xml alebo xmlstarlet (pozri vyššie) na úpravu existujúcich súborov v obraze a buď použiť wget alebo ich načítať pomocou init kontajnera a zdieľaného zväzku.
Správa relácií
Rovnako ako mnoho iných aplikácií, aj Camunda BPM spracováva relácie v JVM, takže ak chcete spustiť viacero replík, môžete povoliť trvalé relácie (), ktorý bude existovať, kým replika nezmizne, alebo nastavte atribút Max-Age pre súbory cookie. Pre robustnejšie riešenie môžete nasadiť Session Manager v Tomcat. Lars má na túto tému, ale niečo ako:
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 '/^</Context>/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
Poznámka: namiesto sed môžete použiť xmlstarlet
Použili sme pred úložiskom Google Cloud Memorystore s (podporuje Redis), aby ste ho spustili.
Škálovanie
Ak už rozumiete reláciám, potom prvým (a často aj posledným) obmedzením škálovania Camunda BPM môže byť pripojenie k databáze. Čiastočné prispôsobenie je už k dispozícii "" Zakážme tiež intialSize v súbore settings.xml. Pridať a môžete ľahko automaticky meniť počet strukov.
Žiadosti a obmedzenia
В platform/deployment.yaml Uvidíte, že sme napevno zakódovali pole zdrojov. Funguje to dobre s HPA, ale môže to vyžadovať ďalšiu konfiguráciu. Na to je vhodná náplasť kustomize. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Výkon
Nainštalovali sme Camunda BPM na Kubernetes s metrikami Prometheus, protokolmi, databázou H2, TLS a Ingress. Pridali sme jar súbory a konfiguračné súbory pomocou ConfigMaps a Dockerfile. Hovorili sme o výmene údajov do zväzkov a priamo do premenných prostredia z tajomstiev. Okrem toho sme poskytli prehľad nastavenia Camundy pre viaceré repliky a overené API.
referencie
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest for use without kustomize
├── images
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker image
├── ingress-patch.yaml.tmpl <- site-specific ingress configuration
├── kustomization.yaml.tmpl <- main Kustomization
├── Makefile <- make targets
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- prometheus exporter config file
│ ├── deployment.yaml <- main deployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "base" kustomization
│ ├── service-monitor.yaml <- example prometheus-operator config
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold directives
05.08.2020/XNUMX/XNUMX, preklad Alastair Firth, Lars Lange
Zdroj: hab.com