Gebruik je Kubernetes? Ben je klaar om je Camunda BPM-instanties van virtuele machines te verplaatsen, of wil je ze misschien gewoon op Kubernetes draaien? Laten we enkele veelvoorkomende configuraties en afzonderlijke componenten bekijken die je kunt aanpassen aan jouw specifieke behoeften.
We gaan ervan uit dat je al eerder met Kubernetes hebt gewerkt. Zo niet, waarom kijk je dan niet even op en start je je eerste cluster?
Auteurs
- is Site Reliability Engineer binnen het Camunda Cloud-team;
- is DevOps-engineer bij Camunda.
Kortom:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Waarschijnlijk werkt het niet, omdat je skaffold en kustomize niet hebt geïnstalleerd. Lees dan verder!
Wat is Camunda BPM
Camunda BPM is een open-source platform voor het beheren van bedrijfsprocessen en automatisering van besluitvorming, dat zakelijke gebruikers en softwareontwikkelaars verenigt. Het is ideaal voor het coördineren en samenvoegen van mensen, (micro)services of zelfs bots! Meer informatie over verschillende gebruiksmogelijkheden vind je op .
Waarom Kubernetes gebruiken
Kubernetes is de de facto standaard geworden voor het draaien van moderne applicaties in Linux. Door systeemaanroepen te gebruiken in plaats van hardware-emulatie en de mogelijkheden van de kernel om geheugen en taakverdeling te beheren, worden opstarttijden en verbindingsniveaus tot een minimum beperkt. Het grootste voordeel is echter de standaard API die Kubernetes biedt voor het configureren van de infrastructuur die alle applicaties nodig hebben: opslag, netwerken en monitoring. In juni 2020 bestond het 6 jaar en het is misschien wel het grootste open-sourceproject na Linux. De laatste tijd stabiliseert het zijn functionaliteit na snelle iteraties in de afgelopen jaren, omdat dit cruciaal wordt voor productieworkloads over de hele wereld.
De Camunda BPM-engine kan eenvoudig verbinding maken met andere applicaties die in hetzelfde cluster draaien, en Kubernetes biedt uitstekende schaalbaarheid, waardoor je de kosten van infrastructuur alleen hoeft te verhogen wanneer dat echt nodig is (en ook eenvoudig kunt verlagen wanneer dat nodig is).
De kwaliteit van de monitoring verbetert ook aanzienlijk met tools zoals Prometheus, Grafana, Loki, Fluentd en Elasticsearch, die het mogelijk maken om alle workloads van het cluster centraal te bekijken. Vandaag bekijken we hoe we de Prometheus exporter kunnen implementeren in een Java (JVM) virtuele machine.
Doelen
Laten we enkele gebieden bekijken waarin we de Docker-image van Camunda BPM () kunnen configureren zodat deze goed samenwerkt met Kubernetes.
- Logs en metrics;
- Databaseverbindingen;
- Authenticatie;
- Sessiebeheer.
We zullen verschillende manieren bespreken om deze doelen te bereiken en het hele proces duidelijk demonstreren.
Opmerking: Gebruik je de Enterprise-versie? Bekijk en update indien nodig de links naar de images.
Workflowontwikkeling
In deze demo gebruiken we Skaffold om Docker-images te bouwen met Google Cloud Build. Het biedt goede ondersteuning voor verschillende tools (zoals Kustomize en Helm), CI- en buildtools, evenals infrastructuurproviders. Het bestand skaffold.yaml.tmpl bevat instellingen voor Google Cloud Build en GKE, wat een zeer gemakkelijke manier biedt om industriële niveau-infrastructuur op te zetten.
make skaffold zal de Dockerfile-context naar Cloud Build uploaden, een image maken en deze opslaan in GCR, en dan de manifesten op je cluster toepassen. Dit is wat make skaffold, maar Skaffold heeft veel andere mogelijkheden.
Voor yaml-sjablonen in Kubernetes gebruiken we kustomize voor het beheren van yaml-overlays zonder de hele manifeststructuur te splitsen, zodat je git pull --rebase voor verdere verbeteringen kunt gebruiken. Het is nu in kubectl en werkt goed voor dit soort dingen.
Ook gebruiken we envsubst om de hostnaam en project-ID van GCP in de * .yaml.tmpl bestanden in te vullen. Je kunt zien hoe dit werkt in makefile of gewoon verder gaan.
Vereisten
- Werkcluster
- — om je eigen Docker-images te maken en eenvoudig te implementeren in GKE
- Een kopie van deze code
- Envsubst
Workflow met manifesten
Als je kustomize of skaffold niet wilt gebruiken, kun je de manifesten bekijken in generated-manifest.yaml en ze aanpassen aan de workflow van jouw keuze.
Logs en metrics
Prometheus is de standaard geworden voor het verzamelen van metrics in Kubernetes. Het neemt dezelfde rol in als AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics en anderen. Het heeft een open source-code en een krachtige query-taal. Voor de visualisatie vertrouwen we op Grafana — dit wordt geleverd met een groot aantal dashboards die direct beschikbaar zijn. Ze zijn met elkaar verbonden en relatief eenvoudig te installeren met .
Standaard gebruikt Prometheus een pull-model /metrics, en het toevoegen van sidecar-containers hiervoor is gebruikelijk. Helaas worden JMX-metrics het beste geregistreerd binnen de JVM, waardoor sidecar-containers minder efficiënt zijn. Laten we verbinding maken met de open-source oplossing van Prometheus naar de JVM door deze toe te voegen aan de containerafbeelding, die een pad zal bieden /metrics op een andere poort.
Voeg Prometheus jmx_exporter toe aan de container
-- images/camunda-bpm/Dockerfile
VAN 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
Wel, dat was eenvoudig. De exporter zal tomcat monitoren en zijn metrics weergeven in het Prometheus-formaat op :9404/metrics
Configuratie van de exporter
De oplettende lezer vraagt zich misschien af waar prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны vandaan komt. We zullen tomcat toevoegen als in Kubernetes, en vervolgens koppelen we het als een volume.
Allereerst voegen we het configuratiebestand van de exporter toe aan onze directory platform/config/
platform/config
└── prometheus-jmx.yaml
Vervolgens voegen we in kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersie: kustomize.config.k8s.io/v1beta1
soort: Kustomization
[...]
configMapGenerator:
- naam: config
bestanden:
- config/prometheus-jmx.yaml
Dit zal elk item files[] toevoegen als een element van de ConfigMap-configuratie. ConfigMapGenerators zijn handig omdat ze de gegevens in de configuratie hash'en en de pod opnieuw opstarten als deze verandert. Ze verkleinen ook de configuratie in de Deployment, omdat je de hele 'map' van configuratiebestanden in één VolumeMount kunt koppelen.
Ten slotte moeten we de ConfigMap aan de pod koppelen als een volume:
-- platform/deployment.yaml
apiVersion: apps/v1
soort: Deployment
[...]
specificatie:
sjabloon:
specificatie:
[...]
volumes:
- naam: config
configMap:
naam: config
standaardmodus: 0744
containers:
- naam: camunda-bpm
volumeBevestigingen:
- montagePad: /etc/config/
naam: config
[...]
Geweldig. Als Prometheus niet is ingesteld voor volledige opruiming, moet je misschien aangeven dat hij de pods moet opruimen. Gebruikers van Prometheus Operator kunnen service-monitor.yaml gebruiken om aan de slag te gaan. Bestudeer Service-monitor.yaml, en voordat je begint.
Het uitbreiden van deze sjabloon naar andere gebruiksscenario's
Alle bestanden die we aan de ConfigMapGenerator toevoegen, zullen beschikbaar zijn in de nieuwe directory /etc/config. U kunt deze sjabloon uitbreiden om andere vereiste configuratiebestanden te mounten. U kunt zelfs een nieuw opstartscript mounten. U kunt gebruiken om afzonderlijke bestanden te mounten. Voor het bijwerken van xml-bestanden kunt u overwegen in plaats van sed. Dit is al opgenomen in de afbeelding.
Logboeken
Goed nieuws! Toepassingslogboeken zijn al beschikbaar op stdout, bijvoorbeeld met behulp van kubectl logs. Fluentd (het is standaard geïnstalleerd in GKE) stuurt uw logboeken door naar Elasticsearch, Loki of uw bedrijfslogboekplatform. Als u jsonify voor logboeken wilt gebruiken, kunt u de bovenstaande sjabloon volgen voor de installatie .
Database
Standaard heeft de afbeelding een H2-database. Dit is niet geschikt voor ons, en we zullen Google Cloud SQL met Cloud SQL Proxy gebruiken — dit is later nodig voor het oplossen van interne taken. Dit is een eenvoudige en betrouwbare optie als u geen voorkeuren heeft voor databaseconfiguratie. AWS RDS biedt een vergelijkbare dienst.
Ongeacht welke database u kiest, zolang het geen H2 is, moet u de bijbehorende omgevingsvariabelen instellen in platform/deploy.yaml. Dit ziet er ongeveer zo uit:
-- platform/deployment.yaml
apiVersion: apps/v1
soort: Deployment
[...]
specificatie:
sjabloon:
specificatie:
[...]
containers:
- naam: camunda-bpm
omgeving:
- naam: DB_DRIVER
waarde: org.postgresql.Driver
- naam: DB_URL
waarde: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- naam: DB_USERNAME
waardeVan:
secretKeyRef:
naam: cambpm-db-credentials
sleutel: db_username
- naam: DB_PASSWORD
waardeVan:
secretKeyRef:
naam: cambpm-db-credentials
sleutel: db_password
[...]
Opmerking: U kunt Kustomize gebruiken voor implementatie in verschillende omgevingen met overlay: .
Opmerking: gebruik valueFrom: secretKeyRef. Gebruik alstublieft zelfs tijdens de ontwikkeling om uw geheimen veilig te houden.
Het is zeer waarschijnlijk dat u al een voorkeurs Kubernetes geheimenbeheer systeem heeft. Zo niet, hier zijn enkele opties: ze te versleutelen met KMS van uw cloudprovider en ze dan in K8S in te voegen als geheimen via de CD-pijplijn — werkt bijzonder goed samen met Kustomize geheimen. Er zijn ook andere tools, zoals dotGPG — zij vervullen vergelijkbare functies: , .
Ingress
Tenzij u besluit om lokale poortdoorverwijzing te gebruiken, heeft u een Ingress Controller nodig. Als u geen () weet u waarschijnlijk al dat u de nodige annotaties moet instellen in ingress-patch.yaml.tmpl of platform/ingress.yaml. Als je ingress-nginx gebruikt en je ziet een nginx ingress class met een load balancer die erop wijst en externe DNS of een wildcard DNS-record, dan is alles klaar. Anders moet je de Ingress Controller en DNS instellen of deze stappen overslaan en een directe verbinding met de pod behouden.
TLS
Als je gebruikt of kube-lego en letsencrypt, worden de certificaten voor de nieuwe ingang automatisch verkregen. Anders, open ingress-patch.yaml.tmpl en stel het in naar jouw behoeften.
Starten!
Als je je aan het bovenstaande hebt gehouden, zou het commando make skaffold HOSTNAME= een toegankelijke instantie moeten starten op /camunda
Als je de ingang niet exposeert via een publiekelijk URL, kun je het doorsturen met localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 en een werkende opdracht krijgen. localhost:8080/camunda
Wacht enkele minuten totdat tomcat volledig is opgestart. Cert-manager heeft enige tijd nodig om de domeinnaam te verifiëren. Daarna kun je de logs volgen met behulp van beschikbare tools, zoals kubetail, of gewoon met kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Volgende stappen
Autorisatie
Dit is meer gerelateerd aan het instellen van Camunda BPM dan aan Kubernetes, maar het is belangrijk op te merken dat authenticatie in de REST API standaard is uitgeschakeld. Je kunt of een andere methode gebruiken, zoals . Je kunt configmaps en volumes gebruiken om xml te laden, of xmlstarlet (zie hierboven) voor het bewerken van bestaande bestanden in de afbeelding, evenals wget gebruiken of ze uploaden met behulp van een init-container en een gedeeld volume.
Sessiebeheer
Net als veel andere applicaties beheert Camunda BPM sessies in de JVM, zodat als je meerdere replicas wilt draaien, je sticky sessions kunt inschakelen (), die zullen bestaan totdat de replica verdwijnt, of je kunt de Max-Age-attribuut voor cookies instellen. Als een betrouwbaardere oplossing kun je een Session Manager in Tomcat implementeren. Lars heeft daar iets over, 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 '/^/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
Opmerking: je kunt xmlstarlet gebruiken in plaats van sed
We hebben gebruikt voor Google Cloud Memorystore, met (ondersteunt Redis) voor zijn werking.
Schaalbaarheid
Als je al bekend bent met sessies, kan de eerste (en vaak de laatste) beperking voor de opschaling van Camunda BPM de verbinding met de database zijn. Een gedeeltelijke configuratie is al beschikbaar. Laten we ook initialSize in het settings.xml-bestand uitschakelen. Voeg toe en je kunt eenvoudig het aantal pods automatisch schalen.
Verzoeken en limieten
In platform/deployment.yaml zie je dat we het veld resources hardcoded hebben. Dit werkt goed met HPA, maar kan extra instellingen vereisen. Hiervoor is een kustomize patch geschikt. Zie ingress-patch.yaml.tmpl en ./kustomization.yaml.tmpl
Uitslag
Zo hebben we Camunda BPM op Kubernetes geïnstalleerd met Prometheus-metrics, logs, een H2-database, TLS en Ingress. We hebben jar-bestanden en configuratiebestanden toegevoegd met behulp van ConfigMaps en Dockerfile. We hebben gesproken over gegevensuitwisseling met volumes en rechtstreeks in omgevingsvariabelen vanuit geheimen. Daarnaast hebben we een overzicht gegeven van de configuratie van Camunda voor meerdere replica's en een geauthenticeerde API.
Links
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest voor gebruik zonder kustomize
├── afbeeldingen
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker afbeelding
├── ingress-patch.yaml.tmpl <- site-specifieke ingress configuratie
├── kustomization.yaml.tmpl <- hoofdkustomisatie
├── Makefile <- make-doelen
├── namespace.yaml
├── platform
│ ├── configuratie
│ │ └── prometheus-jmx.yaml <- configuratiebestand voor prometheus exporter
│ ├── deployment.yaml <- hoofddistributie
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "basis" kustomisatie
│ ├── service-monitor.yaml <- voorbeeld configuratie voor prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold richtlijnen
05-08-2020, vertaald Alastair Firth, Lars Lange
Bron: habr.com
