Maakt u gebruik van Kubernetes? Klaar om uw Camunda BPM-instanties uit virtuele machines te verplaatsen, of misschien gewoon proberen ze op Kubernetes uit te voeren? Laten we eens kijken naar enkele veelvoorkomende configuraties en individuele items die kunnen worden aangepast aan uw specifieke behoeften.
Er wordt van uitgegaan dat u Kubernetes eerder hebt gebruikt. Zo niet, waarom zou u er dan niet eens naar kijken? en niet je eerste cluster starten?
Auteurs
- (Alastair Firth) - Senior Site Reliability Engineer bij het Camunda Cloud-team;
- (Lars Lange) - DevOps-ingenieur bij Camunda.
In het kort:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Oké, het heeft waarschijnlijk niet gewerkt omdat je skaffold en kustomize niet hebt geïnstalleerd. Wel, lees dan verder!
Wat is Camunda BPM
Camunda BPM is een open source platform voor bedrijfsprocesbeheer en beslissingsautomatisering dat zakelijke gebruikers en softwareontwikkelaars met elkaar verbindt. Het is ideaal voor het coördineren en verbinden van mensen, (micro)diensten of zelfs bots! U kunt meer lezen over de verschillende gebruiksscenario's op .
Waarom Kubernetes gebruiken?
Kubernetes is de de facto standaard geworden voor het draaien van moderne applicaties op Linux. Door systeemaanroepen te gebruiken in plaats van hardware-emulatie en door het vermogen van de kernel om geheugen en taakwisseling te beheren, worden de opstart- en opstarttijd tot een minimum beperkt. Het grootste voordeel kan echter komen van de standaard API die Kubernetes biedt om de infrastructuur te configureren die nodig is voor alle applicaties: opslag, netwerken en monitoring. Het bestond in juni 2020 zes jaar en is misschien wel het op één na grootste open source-project (na Linux). Het heeft onlangs zijn functionaliteit actief gestabiliseerd na snelle iteratie in de afgelopen jaren, omdat het van cruciaal belang wordt voor productiewerklasten over de hele wereld.
Camunda BPM Engine kan eenvoudig verbinding maken met andere applicaties die op hetzelfde cluster draaien, en Kubernetes biedt uitstekende schaalbaarheid, waardoor u de infrastructuurkosten alleen kunt verhogen wanneer dat echt nodig is (en deze indien nodig eenvoudig kunt verlagen).
Ook wordt de kwaliteit van de monitoring sterk verbeterd met tools als Prometheus, Grafana, Loki, Fluentd en Elasticsearch, waardoor je alle workloads in een cluster centraal kunt bekijken. Vandaag zullen we bekijken hoe we de Prometheus-exporteur in de Java Virtual Machine (JVM) kunnen implementeren.
doelen
Laten we eens kijken naar een paar gebieden waar we de Camunda BPM Docker-afbeelding kunnen aanpassen () zodat het goed samenwerkt met Kubernetes.
- Logboeken en statistieken;
- Databaseverbindingen;
- Authenticatie;
- Sessiebeheer.
We zullen verschillende manieren bekijken om deze doelen te bereiken en het hele proces duidelijk weergeven.
Noot: Gebruikt u de Enterprise-versie? Kijk en update afbeeldingslinks indien nodig.
Ontwikkeling van de workflow
In deze demo gebruiken we Skaffold om Docker-images te bouwen met Google Cloud Build. Het heeft goede ondersteuning voor verschillende tools (zoals Kustomize en Helm), CI- en build-tools en infrastructuurproviders. Bestand skaffold.yaml.tmpl bevat instellingen voor Google Cloud Build en GKE, waardoor een zeer eenvoudige manier wordt geboden om een infrastructuur op productieniveau uit te voeren.
make skaffold laadt de Dockerfile-context in Cloud Build, bouwt de image en slaat deze op in GCR, en past vervolgens de manifesten toe op uw cluster. Dit is wat het doet make skaffold, maar Skaffold heeft nog veel meer functies.
Voor yaml-sjablonen in Kubernetes gebruiken we kustomize om yaml-overlays te beheren zonder het hele manifest te forken, zodat u git pull --rebase voor verdere verbeteringen. Nu zit het in kubectl en het werkt best goed voor zulke dingen.
We gebruiken ook envsubst om de hostnaam en het GCP-project-ID in de *.yaml.tmpl-bestanden in te vullen. Binnen kun je zien hoe het werkt makefile of gewoon verder gaan.
voorwaarden
- Werkcluster
- - voor het maken van uw eigen docker-images en eenvoudige implementatie in GKE
- Kopie van deze code
- Envsubst
Workflow met behulp van manifesten
Als u kustomize of scaffold niet wilt gebruiken, kunt u verwijzen naar de manifesten in generated-manifest.yaml en pas ze aan de workflow van uw keuze aan.
Logboeken en statistieken
Prometheus is de standaard geworden voor het verzamelen van metrics in Kubernetes. Het bezet dezelfde niche als AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics en anderen. Het is open source en heeft een krachtige zoektaal. We vertrouwen de visualisatie toe aan Grafana; deze wordt geleverd met een groot aantal dashboards die kant-en-klaar beschikbaar zijn. Ze zijn met elkaar verbonden en relatief eenvoudig te installeren .
Standaard gebruikt Prometheus het extractiemodel <service>/metrics, en het toevoegen van zijspancontainers hiervoor is gebruikelijk. Helaas kunnen JMX-statistieken het beste binnen de JVM worden vastgelegd, dus zijspancontainers zijn niet zo efficiënt. Laten we verbinding maken open source van Prometheus naar de JVM door het toe te voegen aan de containerimage die het pad zal opleveren /metrics op een andere haven.
Voeg Prometheus jmx_exporter toe aan de container
-- 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
Nou, dat was makkelijk. De exporteur zal kater monitoren en de statistieken ervan in Prometheus-formaat weergeven op <svc>:9404/metrics
Exporteur instellen
De oplettende lezer vraagt zich misschien af waar dit vandaan komt prometheus-jmx.yaml? Er zijn veel verschillende dingen die in de JVM kunnen worden uitgevoerd, en tomcat is er slechts één van, dus de exporteur heeft wat aanvullende configuratie nodig. Standaardconfiguraties voor kater, wilde vlieg, kafka enzovoort zijn beschikbaar . We zullen kater toevoegen als in Kubernetes en koppel het vervolgens als een volume.
Eerst voegen we het configuratiebestand van de exporteur toe aan onze map platform/config/
platform/config
└── prometheus-jmx.yaml
Dan voegen wij toe в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Hierdoor wordt elk element toegevoegd files[] als een ConfigMap-configuratie-element. ConfigMapGenerators zijn geweldig omdat ze de configuratiegegevens hashen en een herstart van de pod afdwingen als deze verandert. Ze verminderen ook de hoeveelheid configuratie in Deployment, omdat u een hele "map" met configuratiebestanden in één VolumeMount kunt mounten.
Ten slotte moeten we de ConfigMap als een volume aan de pod koppelen:
-- 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
[...]
Prachtig. Als Prometheus niet is geconfigureerd om een volledige opschoning uit te voeren, moet u mogelijk aangeven dat de pods moeten worden opgeschoond. Prometheus Operator-gebruikers kunnen gebruiken service-monitor.yaml starten. Ontdekken Service-monitor.yaml, и Voordat je start.
Dit patroon uitbreiden naar andere gebruiksscenario's
Alle bestanden die we aan ConfigMapGenerator toevoegen, zullen beschikbaar zijn in de nieuwe map /etc/config. U kunt deze sjabloon uitbreiden om eventuele andere configuratiebestanden die u nodig hebt te koppelen. U kunt zelfs een nieuw opstartscript koppelen. Je kunt gebruiken om individuele bestanden te mounten. Als u XML-bestanden wilt bijwerken, kunt u overwegen om in plaats van sed. Het is al opgenomen in de afbeelding.
Tijdschriften
Geweldig nieuws! Applicatielogboeken zijn al beschikbaar op stdout, bijvoorbeeld met kubectl logs. Fluentd (standaard geïnstalleerd in GKE) stuurt uw logboeken door naar Elasticsearch, Loki of uw zakelijke logboekplatform. Als u jsonify voor logboeken wilt gebruiken, kunt u de bovenstaande sjabloon volgen om te installeren .
databank
Standaard heeft de afbeelding een H2-database. Dit is niet geschikt voor ons en we zullen Google Cloud SQL gebruiken met Cloud SQL Proxy - dit zal later nodig zijn om interne problemen op te lossen. Dit is een eenvoudige en betrouwbare optie als u geen eigen voorkeuren heeft bij het opzetten van de database. AWS RDS biedt een soortgelijke service.
Ongeacht de database die u kiest, tenzij het H2 is, moet u de juiste omgevingsvariabelen instellen platform/deploy.yaml. Het ziet er ongeveer zo uit:
-- 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
[...]
Noot: U kunt Kustomize gebruiken om in verschillende omgevingen te implementeren met behulp van een overlay: .
Noot: gebruik valueFrom: secretKeyRef. Gebruik alstublieft zelfs tijdens de ontwikkeling om uw geheimen veilig te houden.
Het is waarschijnlijk dat u al een voorkeurssysteem heeft voor het beheren van Kubernetes-geheimen. Als dit niet het geval is, zijn hier enkele opties: Ze coderen met het KMS van uw cloudprovider en ze vervolgens als geheimen in K8S injecteren via de CD-pijplijn − - zal heel goed werken in combinatie met Kustomize-geheimen. Er zijn andere tools, zoals dotGPG, die vergelijkbare functies uitvoeren: , .
Ingress
Tenzij u ervoor kiest om lokale port forwarding te gebruiken, heeft u een geconfigureerde Ingress-controller nodig. Als je niet gebruikt () dan weet je waarschijnlijk al dat je de benodigde annotaties moet installeren ingress-patch.yaml.tmpl of platform/ingress.yaml. Als u ingress-nginx gebruikt en een nginx ingress-klasse ziet met een load balancer die ernaar verwijst en een externe DNS- of wildcard DNS-invoer, bent u klaar om te gaan. Configureer anders de Ingress-controller en DNS, of sla deze stappen over en behoud de directe verbinding met de pod.
TLS
Als je gebruikt of kube-lego en letencrypt - certificaten voor de nieuwe login worden automatisch verkregen. Anders openen ingress-patch.yaml.tmpl en pas het aan uw behoeften aan.
Launch!
Als je alles hierboven hebt gevolgd, dan is het commando make skaffold HOSTNAME=<you.example.com> zou een beschikbaar exemplaar moeten starten in <hostname>/camunda
Als u uw login niet heeft ingesteld op een openbare URL, kunt u deze omleiden met localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 op localhost:8080/camunda
Wacht een paar minuten tot kater helemaal klaar is. Cert-manager heeft enige tijd nodig om de domeinnaam te verifiëren. U kunt de logboeken vervolgens controleren met behulp van beschikbare tools zoals een tool als kubetail, of eenvoudigweg met behulp van kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Volgende stappen
Machtiging
Dit is relevanter voor het configureren van Camunda BPM dan voor Kubernetes, maar het is belangrijk op te merken dat authenticatie standaard is uitgeschakeld in de REST API. Jij kan of gebruik een andere methode zoals . U kunt configmaps en volumes gebruiken om xml te laden, of xmlstarlet (zie hierboven) om bestaande bestanden in de afbeelding te bewerken, en wget gebruiken of ze laden met behulp van een init-container en een gedeeld volume.
Sessiebeheer
Net als veel andere applicaties verwerkt Camunda BPM sessies in de JVM, dus als u meerdere replica's wilt uitvoeren, kunt u sticky-sessies inschakelen (), die blijft bestaan totdat de replica verdwijnt, of stel het Max-Age-attribuut in voor cookies. Voor een robuustere oplossing kunt u Session Manager in Tomcat implementeren. Lars heeft over dit onderwerp, maar zoiets als:
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
Noot: je kunt xmlstarlet gebruiken in plaats van sed
We gebruikten voor Google Cloud Memorystore, met (ondersteunt Redis) om het uit te voeren.
scaling
Als u sessies al begrijpt, kan de eerste (en vaak de laatste) beperking bij het schalen van Camunda BPM de verbinding met de database zijn. Gedeeltelijk maatwerk is al mogelijk"" Laten we ook initialSize uitschakelen in het bestand settings.xml. Toevoegen en u kunt het aantal pods eenvoudig automatisch schalen.
Verzoeken en beperkingen
В platform/deployment.yaml U zult zien dat we het bronnenveld hardgecodeerd hebben. Dit werkt goed met HPA, maar vereist mogelijk aanvullende configuratie. De kustomize-patch is hiervoor geschikt. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Uitgang
Daarom hebben we Camunda BPM op Kubernetes geïnstalleerd met Prometheus-statistieken, logs, H2-database, TLS en Ingress. We hebben jar-bestanden en configuratiebestanden toegevoegd met behulp van ConfigMaps en Dockerfile. We hadden het over het uitwisselen van gegevens naar volumes en rechtstreeks naar omgevingsvariabelen vanuit geheimen. Daarnaast hebben we een overzicht gegeven van het instellen van Camunda voor meerdere replica's en een geverifieerde API.
referenties
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, vertaling Alastair Firth, Lars Lange
Bron: www.habr.com