Kubernetes에서 Camunda BPM 실행

쿠버네티스를 사용하고 있나요? 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가 설치되어 있지 않기 때문에 아마도 작동하지 않았을 것입니다. 그럼 계속 읽어보세요!

Camunda BPM이란 무엇입니까?

Camunda BPM은 비즈니스 사용자와 소프트웨어 개발자를 연결하는 오픈 소스 비즈니스 프로세스 관리 및 의사결정 자동화 플랫폼입니다. 사람, (마이크로) 서비스 또는 봇을 조정하고 연결하는 데 이상적입니다! 다양한 사용 사례에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 링크.

쿠버네티스를 사용하는 이유

Kubernetes는 Linux에서 최신 애플리케이션을 실행하기 위한 사실상의 표준이 되었습니다. 하드웨어 에뮬레이션 대신 시스템 호출을 사용하고 커널의 메모리 및 작업 전환 관리 기능을 사용하여 부팅 시간과 시작 시간을 최소화합니다. 그러나 가장 큰 이점은 스토리지, 네트워킹, 모니터링 등 모든 애플리케이션에 필요한 인프라를 구성하기 위해 Kubernetes가 제공하는 표준 API에서 나올 수 있습니다. 2020년 6월에 XNUMX주년을 맞이했으며 아마도 (Linux 다음으로) 두 번째로 큰 오픈 소스 프로젝트일 것입니다. 이는 전 세계 프로덕션 워크로드에 중요해짐에 따라 지난 몇 년간 빠른 반복을 거쳐 최근 적극적으로 기능을 안정화해 왔습니다.

Camunda BPM 엔진은 동일한 클러스터에서 실행되는 다른 애플리케이션에 쉽게 연결할 수 있으며 Kubernetes는 뛰어난 확장성을 제공하므로 실제로 필요할 때만 인프라 비용을 늘릴 수 있습니다(필요에 따라 쉽게 줄일 수 있음).

Prometheus, Grafana, Loki, Fluentd 및 Elasticsearch와 같은 도구를 사용하면 모니터링 품질도 크게 향상되어 클러스터의 모든 워크로드를 중앙에서 볼 수 있습니다. 오늘은 Prometheus 내보내기 프로그램을 JVM(Java Virtual Machine)으로 구현하는 방법을 살펴보겠습니다.

대상

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에 쉽게 배포
• 이 코드의 사본
• Envsubst

매니페스트를 사용한 워크플로

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에서 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, 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 구성 요소로 사용됩니다. ConfigMapGenerator는 구성 데이터를 해시하고 변경된 경우 포드를 강제로 다시 시작하기 때문에 훌륭합니다. 또한 하나의 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 파일을 업데이트하려면 다음을 사용하는 것이 좋습니다. xmlstarlet sed 대신. 이미 이미지에 포함되어 있습니다.

잡지

좋은 소식! 애플리케이션 로그는 이미 stdout에서 사용할 수 있습니다. 예를 들어 다음과 같습니다. kubectl logs. Fluentd(GKE에 기본적으로 설치됨)는 로그를 Elasticsearch, Loki 또는 엔터프라이즈 로깅 플랫폼으로 전달합니다. 로그에 jsonify를 사용하려면 위 템플릿을 따라 설치할 수 있습니다. 로그백.

데이터베이스

기본적으로 이미지에는 H2 데이터베이스가 있습니다. 이는 우리에게 적합하지 않으며 Cloud SQL 프록시와 함께 Google 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로 암호화한 다음 CD 파이프라인을 통해 K8S에 비밀로 삽입합니다. 모질라SOPS - Kustomize 비밀과 함께 매우 잘 작동합니다. 유사한 기능을 수행하는 dotGPG와 같은 다른 도구가 있습니다. HashiCorp 금고, 비밀 값 플러그인 사용자 정의.

입구

로컬 포트 ​​전달을 사용하도록 선택하지 않는 한 구성된 수신 컨트롤러가 필요합니다. 사용하지 않으면 수신-nginx (헬름 차트) 그렇다면 필요한 주석을 설치해야 한다는 것을 이미 알고 있을 것입니다. ingress-patch.yaml.tmpl 또는 platform/ingress.yaml. ingress-nginx를 사용 중이고 이를 가리키는 로드 밸런서가 있는 nginx 수신 클래스와 외부 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의 경우) 복제본이 사라질 때까지 존재하거나 쿠키에 대한 Max-Age 속성을 설정합니다. 보다 강력한 솔루션을 위해 Tomcat에 Session Manager를 배포할 수 있습니다. 라스는 별도의 게시물 이 주제에 대해서는 다음과 같습니다.

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을 사용할 수 있습니다.

우리는 사용했었다 템프록시 Google Cloud Memorystore 앞에 memcached-세션-관리자 (Redis 지원)을 실행합니다.

스케일링

세션을 이미 이해하고 있다면 Camunda BPM 확장에 대한 첫 번째(그리고 종종 마지막) 제한은 데이터베이스에 대한 연결일 수 있습니다. 부분적인 맞춤화가 이미 가능합니다."박스에서" settings.xml 파일에서 intialSize도 비활성화해 보겠습니다. 추가하다 수평형 포드 자동 확장 처리(HPA) Pod 수를 자동으로 쉽게 확장할 수 있습니다.

요청 및 제한 사항

В platform/deployment.yaml 리소스 필드를 하드 코딩했음을 알 수 있습니다. 이는 HPA와 잘 작동하지만 추가 구성이 필요할 수 있습니다. Kustomize 패치가 이에 적합합니다. 센티미터. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

출력

그래서 우리는 Prometheus 메트릭, 로그, H2 데이터베이스, TLS 및 Ingress를 사용하여 Kubernetes에 Camunda BPM을 설치했습니다. 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