Kubernetes'i mi kullanıyorsunuz? Camunda BPM örneklerinizi sanal makinelerin dışına taşımaya veya onları Kubernetes'te çalıştırmayı denemeye hazır mısınız? Özel ihtiyaçlarınıza göre uyarlanabilecek bazı genel konfigürasyonlara ve bireysel öğelere bakalım.
Daha önce Kubernetes kullandığınızı varsayar. Değilse, neden bir göz atmıyorsunuz? ve ilk kümenizi başlatmıyor musunuz?
Yazarlar
- (Alastair Firth) - Camunda Cloud ekibinde Kıdemli Site Güvenilirliği Mühendisi;
- (Lars Lange) - Camunda'da DevOps mühendisi.
Kısacası, o zaman:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Tamam, muhtemelen skafold ve özelleştirme kurulu olmadığı için işe yaramadı. O halde okumaya devam edin!
Camunda BPM nedir?
Camunda BPM, iş kullanıcılarını ve yazılım geliştiricilerini birbirine bağlayan açık kaynaklı bir iş süreci yönetimi ve karar otomasyon platformudur. İnsanları, (mikro) hizmetleri ve hatta botları koordine etmek ve birbirine bağlamak için idealdir! Farklı kullanım durumları hakkında daha fazla bilgiyi şu adreste bulabilirsiniz: .
Kubernetes'i neden kullanmalı?
Kubernetes, Linux'ta modern uygulamaları çalıştırmak için fiili standart haline geldi. Donanım öykünmesi yerine sistem çağrıları ve çekirdeğin belleği ve görev değiştirmeyi yönetme yeteneği kullanılarak, önyükleme süresi ve başlatma süresi minimumda tutulur. Ancak en büyük fayda, Kubernetes'in tüm uygulamaların gerektirdiği altyapıyı yapılandırmak için sağladığı standart API'den gelebilir: depolama, ağ oluşturma ve izleme. Haziran 2020'de 6 yaşına girdi ve belki de ikinci en büyük açık kaynak projesidir (Linux'tan sonra). Dünya çapındaki üretim iş yükleri için kritik hale geldiğinden, son birkaç yılda hızlı bir yinelemenin ardından işlevselliğini aktif olarak stabil hale getiriyor.
Camunda BPM Engine, aynı küme üzerinde çalışan diğer uygulamalara kolayca bağlanabilir ve Kubernetes mükemmel ölçeklenebilirlik sunarak altyapı maliyetlerini yalnızca gerçekten ihtiyaç duyulduğunda artırmanıza (ve gerektiğinde bunları kolayca azaltmanıza) olanak tanır.
Prometheus, Grafana, Loki, Fluentd ve Elasticsearch gibi araçlarla izleme kalitesi de büyük ölçüde artırılarak bir kümedeki tüm iş yüklerini merkezi olarak görüntülemenize olanak tanır. Bugün Prometheus dışa aktarıcısını Java Sanal Makinesine (JVM) nasıl uygulayacağımıza bakacağız.
Amacı
Camunda BPM Docker görüntüsünü özelleştirebileceğimiz birkaç alana bakalım () böylece Kubernetes ile iyi etkileşime girer.
- Günlükler ve ölçümler;
- Veritabanı bağlantıları;
- Kimlik doğrulama;
- Oturum yönetimi.
Bu hedeflere ulaşmanın çeşitli yollarına bakacağız ve tüm süreci açıkça göstereceğiz.
Dikkat: Enterprise sürümünü mü kullanıyorsunuz? Bakmak ve resim bağlantılarını gerektiği gibi güncelleyin.
İş akışı geliştirme
Bu demoda Google Cloud Build'i kullanarak Docker görüntüleri oluşturmak için Skaffold'u kullanacağız. Çeşitli araçlar (Kustomize ve Helm gibi), CI ve derleme araçları ve altyapı sağlayıcıları için iyi bir desteğe sahiptir. Dosya skaffold.yaml.tmpl Google Cloud Build ve GKE ayarlarını içerir ve üretim düzeyinde altyapıyı çalıştırmanın çok basit bir yolunu sunar.
make skaffold Dockerfile bağlamını Cloud Build'e yükleyecek, görüntüyü oluşturup GCR'de depolayacak ve ardından bildirimleri kümenize uygulayacaktır. Yaptığı şey bu make skaffold, ancak Skaffold'un başka birçok özelliği var.
Kubernetes'teki yaml şablonları için, bildirimin tamamını çatallamadan yaml katmanlarını yönetmek için özelleştirmeyi kullanırız; git pull --rebase daha fazla iyileştirme için. Şimdi kubectl'de ve bu tür şeyler için oldukça iyi çalışıyor.
*.yaml.tmpl dosyalarındaki ana makine adını ve GCP proje kimliğini doldurmak için de envsubst'u kullanırız. Nasıl çalıştığını görebilirsiniz makefile veya daha fazla devam edin.
Ön şartlar
- İş kümesi
- - kendi liman işçisi görüntülerinizi oluşturmak ve GKE'ye kolay dağıtım için
- Bu kodun kopyası
- Envsubst
Bildirimleri kullanan iş akışı
Eğer özelleştirme veya iskeleyi kullanmak istemiyorsanız, şuradaki manifestlere başvurabilirsiniz: generated-manifest.yaml ve bunları seçtiğiniz iş akışına uyarlayın.
Günlükler ve ölçümler
Prometheus, Kubernetes'te metriklerin toplanmasında standart haline geldi. AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics ve diğerleriyle aynı alanda yer alır. Açık kaynak kodludur ve güçlü bir sorgulama diline sahiptir. Görselleştirmeyi Grafana'ya emanet edeceğiz; kutudan çıktığı gibi çok sayıda kontrol paneliyle birlikte geliyor. Birbirlerine bağlanırlar ve kurulumu nispeten kolaydır. .
Prometheus varsayılan olarak çıkarma modelini kullanır <service>/metricsve bunun için sepet kapları eklemek yaygındır. Ne yazık ki, JMX ölçümleri en iyi şekilde JVM'de kaydedilir, bu nedenle sepet konteynerleri o kadar verimli değildir. Haydi bağlanalım yolu sağlayacak konteyner görüntüsüne ekleyerek Prometheus'tan JVM'ye açık kaynak /metrics farklı bir limanda.
Prometheus jmx_exporter'ı konteynere ekleyin
-- 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
Eh, bu kolaydı. İhracatçı Tomcat'i izleyecek ve ölçümlerini Prometheus formatında görüntüleyecektir. <svc>:9404/metrics
Dışa aktarıcı kurulumu
Dikkatli okuyucu bunun nereden geldiğini merak edebilir prometheus-jmx.yaml? JVM'de çalıştırılabilecek pek çok farklı şey vardır ve Tomcat bunlardan yalnızca biridir, dolayısıyla dışa aktarıcının bazı ek yapılandırmalara ihtiyacı vardır. Tomcat, wildfly, kafka vb. için standart konfigürasyonlar mevcuttur . Tomcat'i şu şekilde ekleyeceğiz: Kubernetes'te ve ardından onu bir birim olarak monte edin.
Öncelikle ihracatçı konfigürasyon dosyasını platform/config/ dizinimize ekliyoruz.
platform/config
└── prometheus-jmx.yaml
Sonra ekliyoruz в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Bu, her bir öğeyi ekleyecektir files[] ConfigMap yapılandırma öğesi olarak. ConfigMapGenerators harikadır çünkü konfigürasyon verilerini karma hale getirirler ve değişirse podu yeniden başlatmaya zorlarlar. Ayrıca, yapılandırma dosyalarının bir "klasörünün" tamamını tek bir VolumeMount'a bağlayabildiğiniz için Dağıtımdaki yapılandırma miktarını da azaltırlar.
Son olarak, ConfigMap'i bir birim olarak bölmeye bağlamamız gerekiyor:
-- 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
[...]
Müthiş. Prometheus tam bir temizlik yapacak şekilde yapılandırılmamışsa, ona bölmeleri temizlemesini söylemeniz gerekebilir. Prometheus Operatörü kullanıcıları kullanabilir service-monitor.yaml başlamak. Keşfetmek Service-monitor.yaml, и başlamadan önce.
Bu modeli diğer kullanım durumlarına genişletme
ConfigMapGenerator'a eklediğimiz tüm dosyalar yeni dizinde mevcut olacak /etc/config. İhtiyacınız olan diğer yapılandırma dosyalarını eklemek için bu şablonu genişletebilirsiniz. Hatta yeni bir başlangıç betiği bile bağlayabilirsiniz. Kullanabilirsiniz bireysel dosyaları monte etmek için. Xml dosyalarını güncellemek için şunu kullanmayı düşünün: sed'in yerine. Zaten görselde yer alıyor.
dergi
Harika haber! Uygulama günlükleri stdout'ta zaten mevcuttur; örneğin kubectl logs. Fluentd (GKE'de varsayılan olarak yüklüdür) günlüklerinizi Elasticsearch, Loki veya kurumsal günlük kaydı platformunuza iletir. Günlükler için jsonify'ı kullanmak istiyorsanız yüklemek için yukarıdaki şablonu takip edebilirsiniz. .
veritabanı
Varsayılan olarak görüntünün bir H2 veritabanı olacaktır. Bu bizim için uygun değil ve Google Cloud SQL'i Cloud SQL Proxy ile kullanacağız - buna daha sonra dahili sorunları çözmek için ihtiyaç duyulacak. Veritabanını ayarlarken kendi tercihleriniz yoksa bu basit ve güvenilir bir seçenektir. AWS RDS benzer bir hizmet sağlar.
Seçtiğiniz veritabanı ne olursa olsun, H2 olmadığı sürece uygun ortam değişkenlerini ayarlamanız gerekir. platform/deploy.yaml. Şunun gibi bir şeye benziyor:
-- 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
[...]
Dikkat: Bir katman kullanarak farklı ortamlara dağıtım yapmak için Özelleştirme'yi kullanabilirsiniz: .
Dikkat: kullanım valueFrom: secretKeyRef. Lütfen kullan sırlarınızı güvende tutmak için geliştirme sırasında bile.
Kubernetes sırlarını yönetmek için zaten tercih ettiğiniz bir sisteme sahip olmanız muhtemeldir. Değilse, bazı seçenekler şunlardır: Bunları bulut sağlayıcınızın KMS'si ile şifrelemek ve ardından bunları CD hattı aracılığıyla sır olarak K8S'ye enjekte etmek – - Özelleştirme sırlarıyla birlikte çok iyi çalışacaktır. Benzer işlevleri yerine getiren dotGPG gibi başka araçlar da vardır: , .
Giriş
Yerel bağlantı noktası yönlendirmeyi kullanmayı seçmediğiniz sürece yapılandırılmış bir Giriş Denetleyicisine ihtiyacınız olacaktır. Eğer kullanmıyorsan () o zaman büyük olasılıkla gerekli ek açıklamaları yüklemeniz gerektiğini zaten biliyorsunuzdur. ingress-patch.yaml.tmpl veya platform/ingress.yaml. Ingress-nginx kullanıyorsanız ve ona işaret eden bir yük dengeleyici ve harici bir DNS veya joker karakterli DNS girişi olan bir nginx giriş sınıfı görüyorsanız, hazırsınız. Aksi halde Giriş Denetleyicisini ve DNS'yi yapılandırın veya bu adımları atlayın ve bölmeyle doğrudan bağlantıyı sürdürün.
TLS
Eğer kullanıyorsanız veya kube-lego ve letsencrypt - yeni giriş için sertifikalar otomatik olarak alınacaktır. Aksi halde aç ingress-patch.yaml.tmpl ve ihtiyaçlarınıza uyacak şekilde özelleştirin.
Öğle yemeği!
Yukarıda yazılan her şeyi takip ettiyseniz, komut make skaffold HOSTNAME=<you.example.com> kullanılabilir bir örneği başlatmalı <hostname>/camunda
Giriş bilgilerinizi genel bir URL'ye ayarlamadıysanız, şunu kullanarak yeniden yönlendirebilirsiniz: localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 üzerinde localhost:8080/camunda
Tomcat tamamen hazır olana kadar birkaç dakika bekleyin. Sertifika yöneticisinin alan adını doğrulaması biraz zaman alacaktır. Daha sonra kubetail gibi mevcut araçları veya sadece kubectl'i kullanarak günlükleri izleyebilirsiniz:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Takibin Shui
Yetki
Bu, Camunda BPM'yi yapılandırmak için Kubernetes'ten daha uygundur ancak kimlik doğrulamanın varsayılan olarak REST API'de devre dışı bırakıldığını unutmamak önemlidir. Yapabilirsiniz veya bunun gibi başka bir yöntem kullanın . Xml yüklemek için configmap'leri ve birimleri veya görüntüdeki mevcut dosyaları düzenlemek için xmlstarlet'i (yukarıya bakın) kullanabilirsiniz ve bunları wget kullanabilir veya bir init kapsayıcısı ve paylaşılan birim kullanarak yükleyebilirsiniz.
Oturum yönetimi
Diğer birçok uygulama gibi Camunda BPM de JVM'deki oturumları yönetir; dolayısıyla birden fazla kopya çalıştırmak istiyorsanız yapışkan oturumları etkinleştirebilirsiniz (), kopya kaybolana kadar mevcut olacak veya çerezler için Maksimum Yaş özelliğini ayarlayacaktır. Daha sağlam bir çözüm için Session Manager'ı Tomcat'te dağıtabilirsiniz. Lars'ın sahip olduğu bu konuyla ilgili ama şunun gibi bir şey:
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
Dikkat: sed yerine xmlstarlet'i kullanabilirsiniz
Kullandığımız Google Cloud Memorystore'un önünde, (Redis'i destekler) çalıştırmak için.
Ölçeklendirme
Oturumları zaten anlıyorsanız, Camunda BPM'yi ölçeklendirmenin ilk (ve genellikle son) sınırlaması veritabanına bağlantı olabilir. Kısmi özelleştirme zaten mevcut "" Ayrıca settings.xml dosyasındaki intialSize'ı devre dışı bırakalım. Eklemek ve bölme sayısını otomatik olarak kolayca ölçeklendirebilirsiniz.
İstekler ve kısıtlamalar
В platform/deployment.yaml Kaynaklar alanını sabit kodladığımızı göreceksiniz. Bu, HPA ile iyi çalışır ancak ek yapılandırma gerektirebilir. Özelleştirme yaması bunun için uygundur. Santimetre. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Aviator apk
Bu nedenle Prometheus metrikleri, günlükleri, H2 veritabanı, TLS ve Ingress ile Camunda BPM'yi Kubernetes'e kurduk. ConfigMaps ve Dockerfile kullanarak jar dosyalarını ve konfigürasyon dosyalarını ekledik. Sırlardan hacimlere ve doğrudan ortam değişkenlerine veri alışverişi yapmaktan bahsettik. Ek olarak, Camunda'nın birden çok replika ve kimliği doğrulanmış bir API için kurulumuna ilişkin bir genel bakış sunduk.
referanslar
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, çeviri Alastair Firth, Lars Lange
Kaynak: habr.com