🥇Camunda BPM palaišana Kubernetes

Vai izmantojat Kubernetes? Vai esat gatavi pārvietot savus Camunda BPM instance no virtuālajām mašīnām, vai arī vienkārši izmēģināt tās palaist Kubernetes? Apskatīsim dažas izplatītas konfigurācijas un atsevišķus elementus, kurus var pielāgot jūsu specifiskajām vajadzībām.

Tiek pieņemts, ka jums jau ir pieredze ar Kubernetes. Ja nē, kāpēc gan neapmeklēt rokasgrāmatu un nepalaist savu pirmo klasteri?

Autori

Alastair Firth (Alastair Firth) – vecākais vietnes pieejamības inženieris (Site Reliability Engineer) Camunda Cloud komandā;
Lars Lange (Lars Lange) – DevOps inženieris Camunda.

Īsumā, tas ir:

git clone https://github.com/camunda-cloud/camunda-examples.git cd camunda-examples/camunda-bpm-demo make skaffold

Labi, visdrīzāk tas nedarbosies, jo jums nav instalēts skaffold un kustomize. Nu tad turpiniet lasīt!

Kas ir Camunda BPM

Camunda BPM ir atvērtā koda platforma biznesa procesu pārvaldībai un lēmumu automatizēšanai, kas apvieno biznesa lietotājus un programmatūras izstrādātājus. Tā ir ideāli piemērota cilvēku, (mikro) pakalpojumu vai pat robotu koordinēšanai un apvienošanai! Vairāk par dažādām lietošanas iespējām varat izlasīt saišu.

Kāpēc izmantot Kubernetes

Kubernetes ir kļuvis par de facto standartu modernu lietotņu palaišanai Linux vidē. Pateicoties sistēmisko izsaukumu izmantošanai, nevis aparatūras līmeņa emulācijai, kā arī kodola iespējām pārvaldīt atmiņu un uzdevumu maiņu, ielādes un palaišanas laiks tiek samazināts līdz minimumam. Tomēr vislielākais ieguvums ir standarta API saskarne, ko Kubernetes nodrošina infrastruktūras konfigurēšanai, kas nepieciešama visām lietojumprogrammām: uzglabāšanai, tīklam un monitorēšanai. 2020. gada jūnijā tā svinēja savu 6. jubileju, un tā ir, iespējams, otra lielākā atvērtā koda projekta vieta (pēc Linux). Pēdējā laikā tā aktīvi stabilizē savu funkcionalitāti pēc ātrām iterācijām pēdējo gadu laikā, jo tas kļūst kritiski svarīgi ražošanas slodzēm visā pasaulē.

Camunda BPM dzinējs var viegli savienoties ar citām lietojumprogrammām, kas darbojas tajā pašā klasterī, un Kubernetes nodrošina izcilu mērogojamību, ļaujot palielināt infrastruktūras izdevumus tikai tad, kad tas ir patiešām nepieciešams (un viegli tos samazināt pēc vajadzības).

Monitoring quality is also significantly enhanced by tools such as Prometheus, Grafana, Loki, Fluentd, and Elasticsearch, which allow centralized monitoring of all cluster workloads. Today, we will discuss how to integrate the Prometheus exporter into a Java Virtual Machine (JVM).

Es neteikšu, ka šis raksts var beznosacījuma saukt par „mācību rokasgrāmatu”. Tas ir drīzāk dokuments, kurā es stāstu par to, ko esmu uzzinājusi, un aprakstu procesu, kas man ir piemērots koda testēšanai un izvietošanai produkcijā, kas tiek veikta vienā automatizētā apgājienā.

Let's explore some areas where we can configure the Camunda BPM Docker image (github), so that it works well with Kubernetes.

Logs and metrics;
Database connections;
Authentication;
Session management.

We will explore several ways to achieve these goals and showcase the entire process visually.

Piezīme: Are you using the Enterprise version? Check out šeit and update image references as needed.

Workflow development

In this demonstration, we will use Skaffold to build Docker images with Google Cloud Build. It has robust support for various tools (such as Kustomize and Helm), CI and build tools, as well as infrastructure providers. The file skaffold.yaml.tmpl includes settings for Google Cloud Build and GKE, providing a very simple way to launch production-grade infrastructure.

make skaffold will upload the Dockerfile context to Cloud Build, create the image, and save it to GCR, then apply the manifests to your cluster. This is what make skaffold, but Skaffold has many other capabilities.

For yaml templates in Kubernetes, we use kustomize to manage yaml overlays without branching the entire manifest, allowing you to use git pull --rebase for further enhancements. It is currently in kubectl and works reasonably well for such tasks.

We also use envsubst to populate the hostname and GCP project ID in * .yaml.tmpl files. You can see how this works in makefile or just move on.

Prerequisites

Working cluster Kubernetes
Kustomize
Skaffold — for building custom docker images and easy deployment to GKE
A copy of this code
Envsubst

Workflow using manifests

If you do not want to use kustomize or skaffold, you can refer to the manifests in generated-manifest.yaml and adapt them to your workflow of choice.

Logs and metrics

Prometheus ir kļuvis par standartu metrikas vākšanai Kubernetes. Tas ieņem to pašu nišu kā AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics un citi. Tam ir atvērts kods un jaudīga vaicājumu valoda. Vizualizāciju uzticēsim Grafana — tā piedāvā lielu skaitu paneļu, kas pieejami no kastes. Tie ir saistīti savā starpā un salīdzinoši viegli uzstādāmi ar prometheus-operator.

Noklusējumā Prometheus izmanto vilkšanas modeli /metrics, un sidecar konteineru pievienošana ir izplatīta prakse. Diemžēl JMX metrikas vislabāk tiek reģistrētas iekšpusē JVM, tāpēc sidecar konteineri nevar būt tik efektīvi. Pievienosim jmx_exporter ar atvērtu kodu no Prometheus uz JVM, pievienojot to konteineru attēlam, kurš nodrošinās ceļu /metrics uz citā portā.

Pievienojiet Prometheus jmx_exporter konteineram

-- 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

Nu, tas bija viegli. Eksportētājs uzraudzīs tomcat un rādīs tā metrikas Prometheus formātā adresē :9404/metrics

Eksportētāja konfigurācija

Uzmanīgs lasītājs varētu jautāt, no kurienes nāk prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны šeit. Mēs pievienosim tomcat kā ConfigMap Kubernetes un pēc tam piestiprināsim to kā apjomu.

Vispirms mēs pievienojam eksportētāja konfigurācijas failu mūsu direktorijā platform/config/

platform/config └── prometheus-jmx.yaml

Tad mēs pievienojam ConfigMapGenerator par kustomization.yaml.tmpl:

-- platform/kustomization.yaml.tmpl apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization [...] configMapGenerator: - name: config files: - config/prometheus-jmx.yaml

Tas pievienos katru elementu files[] kā konfigurācijas ConfigMap elementu. ConfigMapGenerators ir labas, jo tās hashē datus konfigurācijā un iniciē podus restartēt, ja tie mainās. Tās arī samazina konfigurācijas apjomu Deployment, jo varat piestiprināt visu "mapi" konfigurācijas failu vienā VolumeMount.

Visbeidzot, mums ir nepieciešams piestiprināt ConfigMap kā apjomu podam:

-- 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 [...]

Lieliski. Ja Prometheus nav konfigurēts uz pilnīgu tīrīšanu, iespējams, ka jums būs jānorāda tam, lai iztīrītu podus. Prometheus Operator lietotāji var izmantot service-monitor.yaml lai uzsāktu darbu. Izpētiet Service-monitor.yaml, operator design un ServiceMonitorSpec pirms sākt.

Šī šablona izplatīšana citiem lietojumiem

Visi faili, kurus mēs pievienojam ConfigMapGenerator, būs pieejami jaunā direktorijā /etc/config. Jūs varat paplašināt šo veidni, lai montētu jebkurus citus nepieciešamos konfigurācijas failus. Jūs pat varat montēt jaunu palaišanas skriptu. Varat izmantot subPath atsevišķu failu montēšanai. XML failu atjaunināšanai ieteicams izmantot xmlstarlet vietā, lai izmantotu sed. Tas jau ir iekļauts attēlā.

Žurnāli

Lieliskas ziņas! Lietojumprogrammu žurnāli jau ir pieejami stdout, piemēram, izmantojot kubectl logs. Fluentd (tas pēc noklusējuma ir instalēts GKE) pāradresēs jūsu žurnālus Elasticsearch, Loki vai uz jūsu korporatīvo žurnālu platformu. Ja vēlaties izmantot jsonify žurnāliem, varat sekot iepriekš minētajai veidnei, lai instalētu logback.

Datu bāze

Noklusējuma attēlam būs H2 datubāze. Tas mums neder, un mēs izmantosim Google Cloud SQL ar Cloud SQL Proxy — tas būs nepieciešams vēlāk, lai risinātu iekšējās problēmas. Tas ir vienkāršs un uzticams risinājums, ja jums nav personīgu priekšroku datubāzes iestatīšanā. AWS RDS piedāvā līdzīgu pakalpojumu.

Neatkarīgi no tā, kuru datubāzi izvēlējāties, ja vien tā nav H2, jums būs jāsagatavo atbilstošās vides mainīgās vērtības platform/deploy.yaml. Tas izskatās aptuveni šādi:

-- 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 [...]

Piezīme: Jūs varat izmantot Kustomize, lai izvietotu dažādās vidēs, izmantojot pārklājumu: piemērs.

Piezīme: izmantošana valueFrom: secretKeyRef. Lūdzu, izmantojiet šo Kubernetes funkciju pat izstrādes laikā, lai saglabātu savus noslēpumus drošībā.

Ir ļoti iespējams, ka jums jau ir izvēlēta Kubernetes noslēpumu pārvaldības sistēma. Ja nē, šeit ir daži varianti: to šifrēšana, izmantojot sava mākoņu pakalpojuma sniedzēja KMS, un pēc tam to ieviešana K8S kā noslēpumiem caur CD cauruļvadu — MozillaSOPS — lieliski darbosies kopā ar Kustomize noslēpumiem. Ir arī citi rīki, piemēram, dotGPG — tie veic līdzīgas funkcijas: HashiCorp Vault, Kustomize Secret Value Plugins.

Egress

Ja vien jūs nolemjat neizmantot lokālā porta pāradresēšanu, jums būs nepieciešams konfigurēts Ingress kontrolieris. Ja nelietojat ingress-nginx (Helm chart) tad, visticamāk, jau zināt, ka jums jāinstalē nepieciešamās anotācijas ingress-patch.yaml.tmpl vai platform/ingress.yaml. Ja jūs izmantojat ingress-nginx un redzat nginx ingress klasi ar slodzes balansētāju, kas uz to norāda, un ārējo DNS vai vietas DNS ierakstu — viss ir gatavs. Citādi iestatiet Ingress Controller un DNS vai izlaidiet šos soļus un atstājiet tiešo savienojumu ar podu.

TLS

Ja jūs izmantojat cert-manager vai kube-lego un letsencrypt — jaunajiem ienākošajiem sertifikāti tiek iegūti automātiski. Citādi atveriet ingress-patch.yaml.tmpl un pielāgojiet to savām vajadzībām.

Palaišana!

Ja esat ievērojis visu iepriekš minēto, komanda make skaffold HOSTNAME= jāuzsāk pieejams instants /camunda

Ja neesat izveidojis ievadi caur publisko URL, varat to pāradresēt no localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 uz localhost:8080/camunda

Pagaidiet dažas minūtes, kamēr tomcat pilnībā ir gatavs. Cert-manageri vajadzēs laiku, lai pārbaudītu domēna vārdu. Pēc tam varat sekot žurnāliem, izmantojot pieejamos rīkus — piemēram, tādu rīku kā kubetail, vai vienkārši ar kubectl:

kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f

Nākamie soļi

Autorizācija

Tas vairāk attiecas uz Camunda BPM konfigurāciju nekā uz Kubernetes, bet svarīgi atzīmēt, ka pēc noklusējuma REST API autentifikācija ir atslēgta. Jūs varat ieslēgt pamata autentifikāciju vai izmantot citu metodi, piemēram, JWT. Jūs varat izmantot configmaps un apjomus, lai augšupielādētu xml, vai xmlstarlet (skatīt iepriekš) esošo failu rediģēšanai attēlā, kā arī izmantot wget vai augšupielādēt tos ar init konteineru un kopīgu apjomu.

Sesiju pārvaldība

Kā daudzas citas lietojumprogrammas, Camunda BPM apstrādā sesijas JVM, tāpēc, ja vēlaties palaist vairākas replikas, varat ieslēgt sticky sessions (piemēram, ieceļot ingress-nginx), kas pastāvēs līdz replikai izzudīs, vai iestatīt Max-Age atribūtu sīkdatnēm. Kā uzticamāku risinājumu varat izvietot sesiju pārvaldnieku Tomcat. Larsam ir atsevišķs ieraksts par šo tēmu, bet kaut kas līdzīgs:

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

Piezīme: var koristiti xmlstarlet vietā sed

Mēs izmantojām twemproxy pirms Google Cloud Memorystore, ar memcached-session-manager (atbalsta Redis) tā darbības nodrošināšanai.

Mērogošana

Ja jūs jau sapratāt sesijas, tad pirmais (un bieži arī pēdējais) ierobežojums Camunda BPM mērogošanā var būt savienojums ar datubāzi. Daļēja konfigurācija ir pieejama jau «no kastes». Arī atspējosim intialSize failā settings.xml. Pievienojiet HorizontalPodAutoscaler (HPA) un jūs varēsiet viegli automātiski mērogot podu skaitu.

Pieprasījumi un ierobežojumi

No platform/deployment.yaml jūs redzēsiet, ka mēs stingri esam ierakstījuši resursu lauku. Tas labi darbojas ar HPA, taču var būt nepieciešama papildu konfigurācija. Tam derēs kustomize plāksters. Sk. ingress-patch.yaml.tmpl un ./kustomization.yaml.tmpl

Izvade

Lūk, mēs esam uzstādījuši Camunda BPM Kubernetes ar Prometheus metriku, žurnāliem, H2 datubāzi, TLS un Ingress. Mēs pievienojām jar failus un konfigurācijas failus, izmantojot ConfigMaps un Dockerfile. Mēs runājām par datu apmaiņu ar apjomiem un tieši vides mainīgajos no slepenajiem datiem. Turklāt sniedzām pārskatu par Camunda konfigurāciju vairākām replikām un autentificētu API.

Saites

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifests bez kustomize izmantošanas ├── images │ └── camunda-bpm │ └── Dockerfile <- pārklājuma docker attēls ├── ingress-patch.yaml.tmpl <- vietēji specifiska ingress konfigurācija ├── kustomization.yaml.tmpl <- galvenā Kustomization ├── Makefile <- izpildes mērķi ├── namespace.yaml ├── platform │ ├── config │ │ └── prometheus-jmx.yaml <- prometheus eksportētāja konfigurācijas fails │ ├── deployment.yaml <- galvenais izvietojums │ ├── ingress.yaml │ ├── kustomization.yaml <- "pamats" kustomization │ ├── service-monitor.yaml <- piemērs prometheus-operator konfigurācijai │ └── service.yaml └── skaffold.yaml.tmpl <- skaffold direktīvas