Kubernetes で Camunda BPM を実行する

Kubernetes を使用していますか? Camunda BPM インスタンスを仮想マシンから移動する準備はできていますか? それとも、Kubernetes 上で実行してみてはいかがですか? いくつかの一般的な構成と、特定のニーズに合わせてカスタマイズできる個別の項目を見てみましょう。

以前に Kubernetes を使用したことがあることが前提となっています。 そうでない場合は、見てみてはいかがでしょうか руководство 最初のクラスターを開始しないのですか?

著者

• アラステア・ファース (Alastair Firth) - Camunda Cloud チームのシニア サイト信頼性エンジニア。
• ラース・ランゲ (Lars Lange) - Camunda の DevOps エンジニア。

要するに、

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


skaffold と kusTOMize がインストールされていないため、おそらく機能しませんでした。 それでは続きを読んでください！

カムンダBPMとは

Camunda BPM は、ビジネス ユーザーとソフトウェア開発者を結び付ける、オープンソースのビジネス プロセス管理および意思決定自動化プラットフォームです。 人々、(マイクロ) サービス、さらにはボットを調整し接続するのに最適です。 さまざまな使用例の詳細については、次の Web サイトを参照してください。 リンク.

Kubernetes を使用する理由

Kubernetes は、Linux 上で最新のアプリケーションを実行するための事実上の標準になっています。 ハードウェア エミュレーションの代わりにシステム コールを使用し、メモリとタスクの切り替えを管理するカーネルの機能を使用することにより、ブート時間と起動時間が最小限に抑えられます。 ただし、最大の利点は、ストレージ、ネットワーキング、監視など、すべてのアプリケーションに必要なインフラストラクチャを構成するために Kubernetes が提供する標準 API から得られる可能性があります。 2020 年 6 月で XNUMX 周年を迎え、おそらく (Linux に次ぐ) XNUMX 番目に大きなオープンソース プロジェクトです。 世界中の運用ワークロードにとって重要になっているため、過去数年間の急速な反復を経て、最近ではその機能の安定化に積極的に取り組んでいます。

Camunda BPM Engine は、同じクラスター上で実行されている他のアプリケーションに簡単に接続でき、Kubernetes は優れたスケーラビリティを提供するため、本当に必要な場合にのみインフラストラクチャ コストを増やすことができます (必要に応じて簡単に削減できます)。

Prometheus、Grafana、Loki、Fluentd、Elasticsearch などのツールによってモニタリングの品質も大幅に向上し、クラスター内のすべてのワークロードを一元的に表示できるようになります。 今日は、Prometheus エクスポーターを Java 仮想マシン (JVM) に実装する方法を見ていきます。

目標

Camunda BPM Docker イメージをカスタマイズできるいくつかの領域を見てみましょう (githubの) これにより、Kubernetes と適切に対話できるようになります。

1. ログとメトリクス。
2. データベース接続。
3. 認証;
4. セッション管理。

これらの目標を達成するためのいくつかの方法を検討し、プロセス全体を明確に示します。

注意: Enterprise バージョンを使用していますか? 見て ここで 必要に応じて画像リンクを更新します。

ワークフロー開発

このデモでは、Skaffold を使用して、Google Cloud Build を使用して Docker イメージを構築します。 さまざまなツール (KusTOMize や Helm など)、CI およびビルド ツール、インフラストラクチャ プロバイダーを適切にサポートしています。 ファイル skaffold.yaml.tmpl には、Google Cloud Build と GKE の設定が含まれており、本番グレードのインフラストラクチャを実行するための非常に簡単な方法を提供します。

make skaffold Dockerfile コンテキストを Cloud Build に読み込み、イメージをビルドして GCR に保存し、マニフェストをクラスタに適用します。 これがやっていることです make skaffold, しかし、Skaffold には他にも多くの機能があります。

Kubernetes の yaml テンプレートの場合、マニフェスト全体をフォークせずに kusTOMize を使用して yaml オーバーレイを管理します。 git pull --rebase さらなる改善のために。 現在は kubectl に組み込まれており、そのような用途には非常にうまく機能します。

また、envsubst を使用して、*.yaml.tmpl ファイルにホスト名と GCP プロジェクト ID を入力します。 それがどのように機能するかを見ることができます makefile またはさらに続行します。

前提条件

• 作業クラスター Kubernetes
• カスタマイズ
• 足場 - 独自の Docker イメージを作成し、GKE に簡単にデプロイするため
• このコードのコピー
• 環境サブスト

マニフェストを使用したワークフロー

kusTOMize または skaffold を使用したくない場合は、次のマニフェストを参照できます。 generated-manifest.yaml 選択したワークフローに適応させます。

ログとメトリクス

Prometheus は、Kubernetes でメトリクスを収集するための標準になっています。 これは、AWS Cloudwatch Metrics、Cloudwatch Alerts、Stackdriver Metrics、StatsD、Datadog、Nagios、vSphere Metrics などと同じニッチな分野を占めています。 これはオープンソースであり、強力なクエリ言語を備えています。 視覚化は Grafana に任せます。Grafana には、すぐに利用できる多数のダッシュボードが付属しています。 これらは相互に接続されており、比較的簡単にインストールできます。 プロメテウスオペレーター.

デフォルトでは、Prometheus は抽出モデルを使用します。 <service>/metrics、このためにサイドカー コンテナーを追加するのが一般的です。 残念ながら、JMX メトリクスは JVM 内でログに記録されるのが最適であるため、サイドカー コンテナはそれほど効率的ではありません。 つながりましょう jmx_exporter パスを提供するコンテナー イメージに Prometheus を追加することで、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 はそのうちの XNUMX つにすぎないため、エクスポーターには追加の構成が必要です。 Tomcat、Wildfly、Kafka などの標準構成が利用可能 ここで。 Tomcat を次のように追加します 構成マップ Kubernetes でそれをボリュームとしてマウントします。

まず、エクスポーター設定ファイルを platform/config/ ディレクトリに追加します。

platform/config
└── prometheus-jmx.yaml


次に追加します 構成マップジェネレーター в 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 は、構成データをハッシュし、変更された場合にポッドの再起動を強制するため、優れています。 また、構成ファイルの「フォルダー」全体を XNUMX つの VolumeMount にマウントできるため、展開時の構成の量も削減されます。

最後に、ConfigMap をボリュームとしてポッドにマウントする必要があります。

-- 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 が完全なクリーンアップを実行するように構成されていない場合は、Pod をクリーンアップするように指示する必要がある場合があります。 Prometheus Operator ユーザーが使用できるのは service-monitor.yaml 始めるために。 探検する Service-monitor.yaml, オペレーターのデザイン и サービスモニターの仕様 始める前に。

このパターンを他のユースケースに拡張する

ConfigMapGenerator に追加するすべてのファイルは、新しいディレクトリで使用できるようになります。 /etc/config。 このテンプレートを拡張して、必要な他の構成ファイルをマウントすることができます。 新しい起動スクリプトをマウントすることもできます。 使用できます サブパス 個々のファイルをマウントします。 XML ファイルを更新するには、次の使用を検討してください。 xmlスターレット セドの代わりに。 すでに画像に含まれております。

雑誌

素晴らしいニュース！ アプリケーション ログはすでに標準出力で利用可能です。たとえば、 kubectl logs。 Fluentd（GKE にデフォルトでインストールされます）は、ログを Elasticsearch、Loki、またはエンタープライズ ログ プラットフォームに転送します。 ログに jsonify を使用したい場合は、上記のテンプレートに従ってインストールできます。 ログバック.

データベース

デフォルトでは、イメージには H2 データベースが含まれます。 これは私たちには適していないため、Google Cloud SQL と Cloud SQL Proxy を使用します。これは後で内部問題を解決するために必要になります。 データベースの設定に独自の設定がない場合、これはシンプルで信頼性の高いオプションです。 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で暗号化し、CDパイプライン経由でシークレットとしてK8Sに挿入します- モジラSOPS - KusTOMize シークレットと組み合わせると非常にうまく機能します。 dotGPG など、同様の機能を実行するツールは他にもあります。 HashiCorp 保管庫, シークレット値プラグインのカスタマイズ.

進入

ローカル ポート転送の使用を選択しない場合は、構成済みの Ingress コントローラーが必要になります。 使用しない場合 イングレスnginx (ヘルムチャート) その場合、必要なアノテーションを ingress-patch.yaml.tmpl または platform/ingress.yaml。 ingress-nginx を使用していて、ロード バランサーがそれを指している nginx ingress クラスと、外部 DNS またはワイルドカード DNS エントリが表示されれば、問題ありません。 それ以外の場合は、イングレス コントローラーと DNS を構成するか、これらの手順をスキップしてポッドへの直接接続を維持します。

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 の準備が完全に完了するまで数分間待ちます。 Cert-manager がドメイン名を確認するのに時間がかかります。 その後、kubetail などの利用可能なツールを使用するか、単純に kubectl を使用してログを監視できます。

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


次のステップ

承認

これは、Kubernetes よりも Camunda BPM の構成に関連していますが、デフォルトでは REST API で認証が無効になっていることに注意することが重要です。 あなたはできる 基本認証を有効にする または次のような別の方法を使用します JWT。 configmap とボリュームを使用して xml をロードするか、xmlstarlet (上記を参照) を使用してイメージ内の既存のファイルを編集し、wget を使用するか、init コンテナーと共有ボリュームを使用してファイルをロードできます。

セッション管理

他の多くのアプリケーションと同様に、Camunda BPM は JVM でセッションを処理するため、複数のレプリカを実行したい場合は、スティッキー セッションを有効にすることができます (たとえば ingress-nginx の場合）、レプリカが消滅するまで存在するか、Cookie の Max-Age 属性を設定します。 より堅牢なソリューションとして、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


注意: sed の代わりに xmlstarlet を使用できます

私たちが使用した temproxy Google Cloud Memorystore の前で、 memcached-セッションマネージャー (Redis をサポート) して実行します。

スケーリング

すでにセッションを理解している場合は、Camunda BPM のスケーリングに対する最初 (そして多くの場合最後) の制限は、データベースへの接続である可能性があります。 部分的なカスタマイズはすでに利用可能です」箱から」 settings.xml ファイルの intialSize も無効にしましょう。 追加 水平ポッドオートスケーラー (HPA) ポッドの数を簡単に自動的にスケールすることができます。

お願いと制限事項

В platform/deployment.yaml リソースフィールドがハードコーディングされていることがわかります。 これは HPA ではうまく機能しますが、追加の構成が必要な場合があります。 kusTOMize パッチはこれに適しています。 Cm。 ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

出力

そこで、Prometheus メトリクス、ログ、H2 データベース、TLS、Ingress を備えた Camunda BPM を Kubernetes にインストールしました。 ConfigMaps と Dockerfile を使用して、jar ファイルと構成ファイルを追加しました。 データをボリュームに交換し、シークレットから環境変数に直接交換することについて説明しました。 さらに、複数のレプリカと認証された API 用の Camunda のセットアップの概要を説明しました。

リファレンス

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、翻訳 記事 アラステア・ファース、ラース・ラング

出所： habr.com