Você está usando Kubernetes? Pronto para tirar suas instâncias do Camunda BPM das máquinas virtuais ou talvez apenas tentar executá-las no Kubernetes? Vejamos algumas configurações comuns e itens individuais que podem ser adaptados às suas necessidades específicas.
Presume-se que você já usou o Kubernetes antes. Se não, por que não dar uma olhada e não iniciar seu primeiro cluster?
Autores
- (Alastair Firth) – Engenheiro Sênior de Confiabilidade de Site na equipe Camunda Cloud;
- (Lars Lange) - Engenheiro DevOps na Camunda.
Em suma, então:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Ok, provavelmente não funcionou porque você não tem o skaffold e o kustomize instalados. Bem, então continue lendo!
O que é Camunda BPM
Camunda BPM é uma plataforma de código aberto de gerenciamento de processos de negócios e automação de decisões que conecta usuários de negócios e desenvolvedores de software. É ideal para coordenar e conectar pessoas, (micro)serviços ou até bots! Você pode ler mais sobre os diferentes casos de uso em .
Por que usar o Kubernetes
Kubernetes se tornou o padrão de fato para execução de aplicativos modernos no Linux. Ao usar chamadas de sistema em vez de emulação de hardware e a capacidade do kernel de gerenciar memória e alternância de tarefas, o tempo de inicialização e o tempo de inicialização são reduzidos ao mínimo. No entanto, o maior benefício pode vir da API padrão que o Kubernetes fornece para configurar a infraestrutura exigida por todos os aplicativos: armazenamento, rede e monitoramento. Completou 2020 anos em junho de 6 e é talvez o segundo maior projeto de código aberto (depois do Linux). Recentemente, ele estabilizou ativamente sua funcionalidade após rápida iteração nos últimos anos, à medida que se tornou crítico para cargas de trabalho de produção em todo o mundo.
Camunda BPM Engine pode se conectar facilmente a outros aplicativos em execução no mesmo cluster, e o Kubernetes oferece excelente escalabilidade, permitindo aumentar os custos de infraestrutura apenas quando realmente necessário (e reduzi-los facilmente conforme necessário).
A qualidade do monitoramento também é bastante melhorada com ferramentas como Prometheus, Grafana, Loki, Fluentd e Elasticsearch, permitindo visualizar centralmente todas as cargas de trabalho em um cluster. Hoje veremos como implementar o exportador Prometheus na Java Virtual Machine (JVM).
Objetivos
Vejamos algumas áreas onde podemos personalizar a imagem Camunda BPM Docker () para que interaja bem com o Kubernetes.
- Logs e métricas;
- Conexões de banco de dados;
- Autenticação;
- Gerenciamento de sessão.
Veremos várias maneiras de atingir esses objetivos e mostraremos claramente todo o processo.
Nota: Você está usando a versão Enterprise? Olhar e atualize os links das imagens conforme necessário.
Desenvolvimento de fluxo de trabalho
Nesta demonstração, usaremos Skaffold para construir imagens Docker usando o Google Cloud Build. Possui bom suporte para várias ferramentas (como Kustomize e Helm), ferramentas de CI e construção e provedores de infraestrutura. Arquivo skaffold.yaml.tmpl inclui configurações para Google Cloud Build e GKE, fornecendo uma maneira muito simples de executar infraestrutura de nível de produção.
make skaffold carregará o contexto do Dockerfile no Cloud Build, criará a imagem e a armazenará no GCR e, em seguida, aplicará os manifestos ao seu cluster. Isso é o que faz make skaffold, mas o Skaffold tem muitos outros recursos.
Para modelos yaml no Kubernetes, usamos kustomize para gerenciar sobreposições yaml sem bifurcar todo o manifesto, permitindo que você use git pull --rebase para novas melhorias. Agora está no kubectl e funciona muito bem para essas coisas.
Também usamos envsubst para preencher o nome do host e o ID do projeto GCP nos arquivos *.yaml.tmpl. Você pode ver como funciona em makefile ou simplesmente continue mais.
Pré-requisitos
- Cluster de trabalho
- - para criar suas próprias imagens do Docker e facilitar a implantação no GKE
- Cópia deste código
- Substância Ambiental
Fluxo de trabalho usando manifestos
Se não quiser usar kustomize ou skaffold, você pode consultar os manifestos em generated-manifest.yaml e adapte-os ao fluxo de trabalho de sua escolha.
Registros e métricas
O Prometheus se tornou o padrão para coleta de métricas no Kubernetes. Ocupa o mesmo nicho que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics e outros. É de código aberto e possui uma linguagem de consulta poderosa. Confiaremos a visualização ao Grafana - ele vem com um grande número de painéis disponíveis imediatamente. Eles estão conectados entre si e são relativamente fáceis de instalar com .
Por padrão, o Prometheus usa o modelo de extração <service>/metrics, e adicionar contêineres secundários para isso é comum. Infelizmente, as métricas JMX são melhor registradas na JVM, portanto, os contêineres secundários não são tão eficientes. Vamos nos conectar código aberto do Prometheus para a JVM adicionando-o à imagem do contêiner que fornecerá o caminho /metrics em uma porta diferente.
Adicione Prometheus jmx_exporter ao contêiner
-- 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
Bem, isso foi fácil. O exportador monitorará o Tomcat e exibirá suas métricas no formato Prometheus em <svc>:9404/metrics
Configuração do exportador
O leitor atento pode se perguntar de onde veio prometheus-jmx.yaml? Há muitas coisas diferentes que podem ser executadas na JVM, e o Tomcat é apenas uma delas, portanto, o exportador precisa de algumas configurações adicionais. Configurações padrão para tomcat, wildfly, kafka e assim por diante estão disponíveis . Adicionaremos tomcat como no Kubernetes e monte-o como um volume.
Primeiro, adicionamos o arquivo de configuração do exportador ao nosso diretório platform/config/
platform/config
└── prometheus-jmx.yaml
Então adicionamos в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Isto irá adicionar cada elemento files[] como um elemento de configuração do ConfigMap. ConfigMapGenerators são ótimos porque fazem hash dos dados de configuração e forçam a reinicialização do pod se ele mudar. Eles também reduzem a quantidade de configuração no Deployment, pois você pode montar uma “pasta” inteira de arquivos de configuração em um VolumeMount.
Finalmente, precisamos montar o ConfigMap como um volume no 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
[...]
Maravilhoso. Se o Prometheus não estiver configurado para fazer uma limpeza completa, talvez seja necessário instruí-lo a limpar os pods. Os usuários do Operador Prometheus podem usar service-monitor.yaml para começar. Explorar Service-monitor.yaml, и antes que você comece.
Estendendo esse padrão para outros casos de uso
Todos os arquivos que adicionarmos ao ConfigMapGenerator estarão disponíveis no novo diretório /etc/config. Você pode estender este modelo para montar quaisquer outros arquivos de configuração necessários. Você pode até montar um novo script de inicialização. Você pode usar para montar arquivos individuais. Para atualizar arquivos xml, considere usar em vez de sed. Já está incluído na imagem.
Revistas
Boas notícias! Os logs do aplicativo já estão disponíveis no stdout, por exemplo, com kubectl logs. O Fluentd (instalado por padrão no GKE) encaminhará seus logs para Elasticsearch, Loki ou para sua plataforma de registro empresarial. Se você quiser usar jsonify para logs, você pode seguir o modelo acima para instalar .
Banco de dados
Por padrão, a imagem terá um banco de dados H2. Isso não é adequado para nós e usaremos o Google Cloud SQL com o Cloud SQL Proxy - isso será necessário mais tarde para resolver problemas internos. Esta é uma opção simples e confiável se você não tiver preferências próprias na configuração do banco de dados. AWS RDS fornece um serviço semelhante.
Independentemente do banco de dados escolhido, a menos que seja H2, você precisará definir as variáveis de ambiente apropriadas em platform/deploy.yaml. Parece algo assim:
-- 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
[...]
Nota: você pode usar o Kustomize para implantar em diferentes ambientes usando uma sobreposição: .
Nota: uso valueFrom: secretKeyRef. Por favor, use mesmo durante o desenvolvimento para manter seus segredos seguros.
É provável que você já tenha um sistema preferencial para gerenciar segredos do Kubernetes. Caso contrário, aqui estão algumas opções: Criptografá-los com o KMS do seu provedor de nuvem e injetá-los no K8S como segredos por meio do pipeline de CD - - funcionará muito bem em combinação com os segredos do Kustomize. Existem outras ferramentas, como o dotGPG, que executam funções semelhantes: , .
Ingresso
A menos que você opte por usar o encaminhamento de porta local, você precisará de um Ingress Controller configurado. Se você não usar (), então você provavelmente já sabe que precisa instalar as anotações necessárias em ingress-patch.yaml.tmpl ou platform/ingress.yaml. Se você estiver usando ingress-nginx e vir uma classe de entrada nginx com um balanceador de carga apontando para ela e um DNS externo ou entrada DNS curinga, você está pronto para prosseguir. Caso contrário, configure o Ingress Controller e o DNS ou ignore estas etapas e mantenha a conexão direta com o pod.
TLS
Se você estiver usando ou kube-lego e letsencrypt - os certificados para o novo login serão obtidos automaticamente. Caso contrário, abra ingress-patch.yaml.tmpl e personalize-o para atender às suas necessidades.
Lançar!
Se você seguiu tudo escrito acima, então o comando make skaffold HOSTNAME=<you.example.com> deve lançar uma instância disponível em <hostname>/camunda
Se você não configurou seu login para um URL público, você pode redirecioná-lo com localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 em localhost:8080/camunda
Aguarde alguns minutos até que o Tomcat esteja completamente pronto. O Cert-manager levará algum tempo para verificar o nome de domínio. Você pode então monitorar os logs usando ferramentas disponíveis, como kubetail, ou simplesmente usando kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Próximos passos
Autorização
Isso é mais relevante para configurar o Camunda BPM do que o Kubernetes, mas é importante observar que por padrão, a autenticação está desabilitada na API REST. Você pode ou use outro método como . Você pode usar configmaps e volumes para carregar xml ou xmlstarlet (veja acima) para editar arquivos existentes na imagem e usar wget ou carregá-los usando um contêiner init e um volume compartilhado.
Gerenciamento de sessão
Como muitos outros aplicativos, o Camunda BPM lida com sessões na JVM, portanto, se você deseja executar múltiplas réplicas, você pode habilitar sessões fixas (), que existirá até que a réplica desapareça ou defina o atributo Max-Age para cookies. Para uma solução mais robusta, você pode implantar o Session Manager no Tomcat. Lars tem sobre este tópico, mas algo como:
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
Nota: você pode usar xmlstarlet em vez de sed
Nós costumavamos na frente do Google Cloud Memorystore, com (suporta Redis) para executá-lo.
Escala
Se você já entende de sessões, então a primeira (e muitas vezes a última) limitação para escalar o Camunda BPM pode ser a conexão com o banco de dados. A personalização parcial já está disponível "" Também vamos desabilitar intialSize no arquivo settings.xml. Adicionar e você pode dimensionar automaticamente o número de pods com facilidade.
Solicitações e restrições
В platform/deployment.yaml Você verá que codificamos o campo de recursos. Isso funciona bem com HPA, mas pode exigir configuração adicional. O patch kustomize é adequado para isso. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Jogar aviator online grátis: hack aviator funciona
Por isso instalamos Camunda BPM no Kubernetes com métricas Prometheus, logs, banco de dados H2, TLS e Ingress. Adicionamos arquivos jar e arquivos de configuração usando ConfigMaps e Dockerfile. Falamos sobre a troca de dados para volumes e diretamente para variáveis de ambiente a partir de segredos. Além disso, fornecemos uma visão geral da configuração do Camunda para múltiplas réplicas e uma API autenticada.
referências
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, tradução Alastair Firth, Lars Lange
Fonte: habr.com