Εκτέλεση του Camunda BPM στο Kubernetes

Εκτέλεση του Camunda BPM στο Kubernetes

Χρησιμοποιείτε Kubernetes; Είστε έτοιμοι να μετακινήσετε τις παρουσίες Camunda BPM από εικονικές μηχανές ή μήπως απλώς δοκιμάστε να τις εκτελέσετε στο Kubernetes; Ας δούμε μερικές κοινές διαμορφώσεις και μεμονωμένα στοιχεία που μπορούν να προσαρμοστούν στις συγκεκριμένες ανάγκες σας.

Προϋποθέτει ότι έχετε χρησιμοποιήσει το Kubernetes στο παρελθόν. Αν όχι, γιατί να μην ρίξετε μια ματιά οδηγός και να μην ξεκινήσετε το πρώτο σας σύμπλεγμα;

Συγγραφείς

  • Άλαστερ Φερθ (Alastair Firth) - Ανώτερος μηχανικός αξιοπιστίας τοποθεσίας στην ομάδα Camunda Cloud.
  • Λαρς Λανγκ (Lars Lange) - Μηχανικός DevOps στην Camunda.

Εν συντομία:

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

Εντάξει, μάλλον δεν λειτούργησε γιατί δεν έχεις εγκαταστήσει το skaffold and kustomize. Λοιπόν, διαβάστε!

Τι είναι το Camunda BPM

Η Camunda BPM είναι μια πλατφόρμα διαχείρισης επιχειρηματικών διαδικασιών και αυτοματισμού αποφάσεων ανοιχτού κώδικα που συνδέει επιχειρηματικούς χρήστες και προγραμματιστές λογισμικού. Είναι ιδανικό για συντονισμό και σύνδεση ατόμων, (μικρο) υπηρεσιών ή ακόμα και bots! Μπορείτε να διαβάσετε περισσότερα για τις διαφορετικές περιπτώσεις χρήσης στο σύνδεσμος.

Γιατί να χρησιμοποιήσετε το Kubernetes

Το Kubernetes έχει γίνει το de facto πρότυπο για την εκτέλεση σύγχρονων εφαρμογών σε Linux. Χρησιμοποιώντας κλήσεις συστήματος αντί για εξομοίωση υλικού και την ικανότητα του πυρήνα να διαχειρίζεται τη μνήμη και την εναλλαγή εργασιών, ο χρόνος εκκίνησης και ο χρόνος εκκίνησης περιορίζονται στο ελάχιστο. Ωστόσο, το μεγαλύτερο όφελος μπορεί να προέλθει από το τυπικό API που παρέχει η Kubernetes για τη διαμόρφωση της υποδομής που απαιτείται από όλες τις εφαρμογές: αποθήκευση, δικτύωση και παρακολούθηση. Έγινε 2020 ετών τον Ιούνιο του 6 και είναι ίσως το δεύτερο μεγαλύτερο έργο ανοιχτού κώδικα (μετά το Linux). Πρόσφατα σταθεροποιεί ενεργά τη λειτουργικότητά του μετά από ταχεία επανάληψη τα τελευταία χρόνια, καθώς γίνεται κρίσιμο για τον φόρτο εργασίας παραγωγής σε όλο τον κόσμο.

Το Camunda BPM Engine μπορεί εύκολα να συνδεθεί με άλλες εφαρμογές που εκτελούνται στο ίδιο σύμπλεγμα και το Kubernetes παρέχει εξαιρετική επεκτασιμότητα, επιτρέποντάς σας να αυξήσετε το κόστος υποδομής μόνο όταν πραγματικά χρειάζεται (και να το μειώσετε εύκολα όπως χρειάζεται).

Η ποιότητα της παρακολούθησης βελτιώνεται επίσης σημαντικά με εργαλεία όπως Prometheus, Grafana, Loki, Fluentd και Elasticsearch, επιτρέποντάς σας να βλέπετε κεντρικά όλους τους φόρτους εργασίας σε ένα σύμπλεγμα. Σήμερα θα δούμε πώς να εφαρμόσουμε τον εξαγωγέα Prometheus στην εικονική μηχανή Java (JVM).

Στόχοι

Ας δούμε μερικές περιοχές όπου μπορούμε να προσαρμόσουμε την εικόνα Camunda BPM Docker (GitHub) ώστε να αλληλεπιδρά καλά με το Kubernetes.

  1. Αρχεία καταγραφής και μετρήσεις.
  2. Συνδέσεις βάσεων δεδομένων.
  3. Αυθεντικοποίηση;
  4. Διαχείριση συνεδρίας.

Θα εξετάσουμε διάφορους τρόπους για να επιτύχουμε αυτούς τους στόχους και θα δείξουμε ξεκάθαρα ολόκληρη τη διαδικασία.

Σημείωση: Χρησιμοποιείτε την έκδοση Enterprise; Κοίτα εδώ και ενημερώστε τους συνδέσμους εικόνων όπως απαιτείται.

Ανάπτυξη ροής εργασιών

Σε αυτήν την επίδειξη, θα χρησιμοποιήσουμε το Skaffold για να δημιουργήσουμε εικόνες Docker χρησιμοποιώντας το Google Cloud Build. Έχει καλή υποστήριξη για διάφορα εργαλεία (όπως Kustomize και Helm), εργαλεία CI και build και παρόχους υποδομής. Αρχείο skaffold.yaml.tmpl περιλαμβάνει ρυθμίσεις για το Google Cloud Build και το GKE, παρέχοντας έναν πολύ απλό τρόπο εκτέλεσης υποδομής ποιότητας παραγωγής.

make skaffold θα φορτώσει το περιβάλλον του Dockerfile στο Cloud Build, θα δημιουργήσει την εικόνα και θα την αποθηκεύσει στο GCR και, στη συνέχεια, θα εφαρμόσει τις δηλώσεις στο σύμπλεγμα σας. Αυτό κάνει make skaffold, αλλά το Skaffold έχει πολλά άλλα χαρακτηριστικά.

Για τα πρότυπα yaml στο Kubernetes, χρησιμοποιούμε το kustomize για να διαχειριστούμε τις επικαλύψεις yaml χωρίς να διαχωρίσουμε ολόκληρο το μανιφέστο, επιτρέποντάς σας να χρησιμοποιήσετε git pull --rebase για περαιτέρω βελτιώσεις. Τώρα είναι στο kubectl και λειτουργεί αρκετά καλά για τέτοια πράγματα.

Χρησιμοποιούμε επίσης το envsubst για να συμπληρώσουμε το όνομα κεντρικού υπολογιστή και το αναγνωριστικό έργου GCP στα αρχεία *.yaml.tmpl. Μπορείτε να δείτε πώς λειτουργεί μέσα makefile ή απλά συνεχίστε περαιτέρω.

Προϋποθέσεις

  • Ομάδα εργασίας Kubernetes
  • Προσαρμογή
  • Σκαλωσιά - για τη δημιουργία των δικών σας εικόνων docker και την εύκολη ανάπτυξη στο GKE
  • Αντίγραφο αυτού του κωδικού
  • Envsubst

Ροή εργασίας με χρήση μανιφέστων

Εάν δεν θέλετε να χρησιμοποιήσετε το kustomize ή το skaffold, μπορείτε να ανατρέξετε στις εκδηλώσεις στο generated-manifest.yaml και προσαρμόστε τα στη ροή εργασίας της επιλογής σας.

Αρχεία καταγραφής και μετρήσεις

Ο Prometheus έχει γίνει το πρότυπο για τη συλλογή μετρήσεων στο Kubernetes. Καταλαμβάνει την ίδια θέση με τα AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics και άλλα. Είναι ανοιχτού κώδικα και έχει μια ισχυρή γλώσσα ερωτημάτων. Θα εμπιστευτούμε την οπτικοποίηση στην Grafana - συνοδεύεται από μεγάλο αριθμό ταμπλό που διατίθενται εκτός συσκευασίας. Συνδέονται μεταξύ τους και τοποθετούνται σχετικά εύκολα προμηθέας-χειριστής.

Από προεπιλογή, ο Prometheus χρησιμοποιεί το μοντέλο εξαγωγής <service>/metrics, και η προσθήκη κοντέινερ πλευρικών καρτών για αυτό είναι συνηθισμένη. Δυστυχώς, οι μετρήσεις JMX καταγράφονται καλύτερα στο JVM, επομένως τα κοντέινερ sidecar δεν είναι τόσο αποτελεσματικά. Ας συνδεθούμε jmx_exporter ανοιχτού κώδικα από τον Prometheus στο JVM προσθέτοντάς το στην εικόνα του κοντέινερ που θα παρέχει τη διαδρομή /metrics σε διαφορετικό λιμάνι.

Προσθέστε το Prometheus jmx_exporter στο κοντέινερ

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

Λοιπόν, ήταν εύκολο. Ο εξαγωγέας θα παρακολουθεί το tomcat και θα εμφανίζει τις μετρήσεις του σε μορφή Prometheus στο <svc>:9404/metrics

Ρύθμιση εξαγωγέα

Ο προσεκτικός αναγνώστης μπορεί να αναρωτηθεί από πού προήλθε prometheus-jmx.yaml? Υπάρχουν πολλά διαφορετικά πράγματα που μπορούν να εκτελεστούν στο JVM, και το tomcat είναι μόνο ένα από αυτά, επομένως ο εξαγωγέας χρειάζεται κάποια πρόσθετη διαμόρφωση. Διατίθενται τυπικές διαμορφώσεις για γάτο, αγριόμυγα, κάφκα και ούτω καθεξής εδώ. Θα προσθέσουμε tomcat ως ConfigMap στο Kubernetes και στη συνέχεια τοποθετήστε το ως τόμο.

Αρχικά, προσθέτουμε το αρχείο διαμόρφωσης εξαγωγέα στον κατάλογό μας πλατφόρμα/config/

platform/config
└── prometheus-jmx.yaml

Στη συνέχεια προσθέτουμε ConfigMapGenerator в kustomization.yaml.tmpl:

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

Αυτό θα προσθέσει κάθε στοιχείο files[] ως στοιχείο διαμόρφωσης ConfigMap. Τα ConfigMapGenerators είναι υπέροχα επειδή κατακερματίζουν τα δεδομένα διαμόρφωσης και αναγκάζουν την επανεκκίνηση ενός pod εάν αλλάξει. Μειώνουν επίσης τον όγκο των ρυθμίσεων στο Deployment, καθώς μπορείτε να προσαρτήσετε έναν ολόκληρο "φάκελο" αρχείων διαμόρφωσης σε ένα VolumeMount.

Τέλος, πρέπει να προσαρτήσουμε το ConfigMap ως τόμο στο pod:

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

Εκπληκτικός. Εάν ο Prometheus δεν έχει ρυθμιστεί να κάνει πλήρη καθαρισμό, ίσως χρειαστεί να του πείτε να καθαρίσει τα pods. Οι χρήστες Prometheus Operator μπορούν να χρησιμοποιήσουν service-monitor.yaml για να ξεκινήσετε. Εξερευνώ Service-monitor.yaml, σχεδιασμός χειριστή и ServiceMonitorSpec πριν ξεκινήσεις.

Επέκταση αυτού του μοτίβου σε άλλες περιπτώσεις χρήσης

Όλα τα αρχεία που προσθέτουμε στο ConfigMapGenerator θα είναι διαθέσιμα στον νέο κατάλογο /etc/config. Μπορείτε να επεκτείνετε αυτό το πρότυπο για να προσαρτήσετε οποιαδήποτε άλλα αρχεία διαμόρφωσης χρειάζεστε. Μπορείτε ακόμη και να προσαρτήσετε ένα νέο σενάριο εκκίνησης. Μπορείς να χρησιμοποιήσεις υποδιαδρομή για προσάρτηση μεμονωμένων αρχείων. Για να ενημερώσετε αρχεία xml, σκεφτείτε να χρησιμοποιήσετε xmlstarlet αντί για sed. Περιλαμβάνεται ήδη στην εικόνα.

Περιοδικά

Θαυμάσια νέα! Τα αρχεία καταγραφής εφαρμογών είναι ήδη διαθέσιμα στο stdout, για παράδειγμα με kubectl logs. Το Fluentd (εγκατεστημένο από προεπιλογή στο GKE) θα προωθήσει τα αρχεία καταγραφής σας στο Elasticsearch, στο Loki ή στην πλατφόρμα καταγραφής της επιχείρησής σας. Εάν θέλετε να χρησιμοποιήσετε το jsonify για αρχεία καταγραφής, μπορείτε να ακολουθήσετε το παραπάνω πρότυπο για εγκατάσταση logback.

Βάση δεδομένων

Από προεπιλογή, η εικόνα θα έχει μια βάση δεδομένων H2. Αυτό δεν είναι κατάλληλο για εμάς και θα χρησιμοποιήσουμε το Google Cloud SQL με διακομιστή μεσολάβησης Cloud SQL - αυτό θα χρειαστεί αργότερα για την επίλυση εσωτερικών προβλημάτων. Αυτή είναι μια απλή και αξιόπιστη επιλογή εάν δεν έχετε τις δικές σας προτιμήσεις στη ρύθμιση της βάσης δεδομένων. Η AWS RDS παρέχει παρόμοια υπηρεσία.

Ανεξάρτητα από τη βάση δεδομένων που θα επιλέξετε, εκτός εάν είναι H2, θα πρέπει να ορίσετε τις κατάλληλες μεταβλητές περιβάλλοντος στο platform/deploy.yaml. Μοιάζει κάπως έτσι:

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

Σημείωση: Μπορείτε να χρησιμοποιήσετε το Kustomize για ανάπτυξη σε διαφορετικά περιβάλλοντα χρησιμοποιώντας μια επικάλυψη: παράδειγμα.

Σημείωση: χρήση valueFrom: secretKeyRef. Παρακαλώ χρησιμοποιήστε αυτό το χαρακτηριστικό Kubernetes ακόμα και κατά την ανάπτυξη για να κρατήσετε τα μυστικά σας ασφαλή.

Είναι πιθανό να έχετε ήδη ένα προτιμώμενο σύστημα για τη διαχείριση των μυστικών του Kubernetes. Εάν όχι, ακολουθούν ορισμένες επιλογές: Κρυπτογράφηση με το KMS του παρόχου cloud και μετά εισαγωγή τους στο K8S ως μυστικά μέσω του αγωγού CD − Mozilla SOPS - θα λειτουργήσει πολύ καλά σε συνδυασμό με τα μυστικά Kustomize. Υπάρχουν άλλα εργαλεία, όπως το dotGPG, που εκτελούν παρόμοιες λειτουργίες: HashiCorp Vault, Προσαρμόστε τα πρόσθετα μυστικής αξίας.

Είσοδος

Αν δεν επιλέξετε να χρησιμοποιήσετε τοπική προώθηση θύρας, θα χρειαστείτε έναν διαμορφωμένο ελεγκτή εισόδου. Εάν δεν χρησιμοποιείτε είσοδος-nginx (Διάγραμμα τιμόνι) τότε πιθανότατα γνωρίζετε ήδη ότι πρέπει να εγκαταστήσετε τους απαραίτητους σχολιασμούς ingress-patch.yaml.tmpl ή platform/ingress.yaml. Εάν χρησιμοποιείτε το ingress-nginx και βλέπετε μια κλάση εισόδου nginx με έναν εξισορροπητή φορτίου να δείχνει προς αυτήν και μια εξωτερική καταχώρηση DNS ή μπαλαντέρ DNS, είστε έτοιμοι. Διαφορετικά, διαμορφώστε τον ελεγκτή εισόδου και το DNS ή παραλείψτε αυτά τα βήματα και διατηρήστε την απευθείας σύνδεση με το pod.

TLS

Εάν χρησιμοποιείτε διευθυντής πιστοποιητικών ή kube-lego και letsencrypt - τα πιστοποιητικά για τη νέα σύνδεση θα ληφθούν αυτόματα. Διαφορετικά, ανοίξτε ingress-patch.yaml.tmpl και προσαρμόστε το σύμφωνα με τις ανάγκες σας.

Εκτόξευση!

Εάν ακολουθήσατε όλα όσα γράφτηκαν παραπάνω, τότε η εντολή make skaffold HOSTNAME=<you.example.com> θα πρέπει να ξεκινήσει μια διαθέσιμη παρουσία στο <hostname>/camunda

Εάν δεν έχετε ορίσει τη σύνδεσή σας σε μια δημόσια διεύθυνση URL, μπορείτε να την ανακατευθύνετε με localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 επί localhost:8080/camunda

Περιμένετε μερικά λεπτά έως ότου το tomcat είναι εντελώς έτοιμο. Ο διαχειριστής πιστοποιητικών θα χρειαστεί λίγο χρόνο για να επαληθεύσει το όνομα τομέα. Στη συνέχεια, μπορείτε να παρακολουθείτε τα αρχεία καταγραφής χρησιμοποιώντας διαθέσιμα εργαλεία όπως ένα εργαλείο όπως το kubetail ή απλά χρησιμοποιώντας το kubectl:

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

Επόμενα βήματα

Είσοδος

Αυτό είναι πιο σχετικό με τη διαμόρφωση του Camunda BPM από το Kubernetes, αλλά είναι σημαντικό να σημειωθεί ότι από προεπιλογή, ο έλεγχος ταυτότητας είναι απενεργοποιημένος στο REST API. Μπορείς ενεργοποιήστε τον βασικό έλεγχο ταυτότητας ή χρησιμοποιήστε άλλη μέθοδο όπως J.W.T.. Μπορείτε να χρησιμοποιήσετε χάρτες διαμόρφωσης και τόμους για να φορτώσετε xml ή xmlstarlet (δείτε παραπάνω) για να επεξεργαστείτε υπάρχοντα αρχεία στην εικόνα και είτε να χρησιμοποιήσετε το wget είτε να τα φορτώσετε χρησιμοποιώντας ένα κοντέινερ init και έναν κοινόχρηστο τόμο.

Διαχείριση συνεδρίας

Όπως πολλές άλλες εφαρμογές, η Camunda BPM χειρίζεται συνεδρίες στο JVM, επομένως, εάν θέλετε να εκτελέσετε πολλά αντίγραφα, μπορείτε να ενεργοποιήσετε τις σταθερές συνεδρίες (για παράδειγμα για ingress-nginx), το οποίο θα υπάρχει μέχρι να εξαφανιστεί το αντίγραφο ή ορίστε το χαρακτηριστικό Max-Age για τα cookies. Για μια πιο ισχυρή λύση, μπορείτε να αναπτύξετε το Session Manager στο Tomcat. Ο Λαρς έχει ξεχωριστή ανάρτηση σε αυτό το θέμα, αλλά κάτι σαν:

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

Σημείωση: μπορείτε να χρησιμοποιήσετε xmlstarlet αντί για sed

Συνηθίζαμε twemproxy μπροστά από το Google Cloud Memorystore, με memcached-session-manager (υποστηρίζει το Redis) για να το εκτελέσετε.

Κλιμάκωση

Εάν καταλαβαίνετε ήδη τις συνεδρίες, τότε ο πρώτος (και συχνά ο τελευταίος) περιορισμός στην κλιμάκωση του Camunda BPM μπορεί να είναι η σύνδεση με τη βάση δεδομένων. Η μερική προσαρμογή είναι ήδη διαθέσιμη "από το κουτί" Ας απενεργοποιήσουμε επίσης το intialSize στο αρχείο settings.xml. Προσθήκη Horizontal Pod Autoscaler (HPA) και μπορείτε εύκολα να κλιμακώσετε αυτόματα τον αριθμό των λοβών.

Αιτήματα και περιορισμοί

В platform/deployment.yaml Θα δείτε ότι έχουμε κωδικοποιήσει σκληρά το πεδίο πόρων. Αυτό λειτουργεί καλά με το HPA, αλλά μπορεί να απαιτεί πρόσθετη διαμόρφωση. Το patch kustomize είναι κατάλληλο για αυτό. Εκ. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Παραγωγή

Έτσι εγκαταστήσαμε το Camunda BPM στο Kubernetes με μετρήσεις Prometheus, αρχεία καταγραφής, βάση δεδομένων H2, TLS και Ingress. Προσθέσαμε αρχεία jar και αρχεία διαμόρφωσης χρησιμοποιώντας ConfigMaps και Dockerfile. Μιλήσαμε για την ανταλλαγή δεδομένων σε όγκους και απευθείας σε μεταβλητές περιβάλλοντος από μυστικά. Επιπλέον, παρέχουμε μια επισκόπηση της ρύθμισης του Camunda για πολλαπλά αντίγραφα και ένα πιστοποιημένο API.

παραπομπές

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, μετάφραση Άρθρο Alastair Firth, Lars Lange

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο