Está usando Kubernetes? Pronto para mover suas instâncias do Camunda BPM de máquinas virtuais ou simplesmente tentar executá-las no Kubernetes? Vamos explorar algumas configurações comuns e elementos separados que podem ser adaptados às suas necessidades específicas.
Suponha que você já tenha usado Kubernetes antes. Se não, por que não dar uma olhada em e iniciar seu primeiro cluster?
Autores
- é engenheiro sênior de confiabilidade de site (Site Reliability Engineer) na equipe do Camunda Cloud;
- é engenheiro DevOps na Camunda.
Resumindo:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Bem, provavelmente isso não funcionou, já que você não tem o skaffold e o kustomize instalados. Então continue lendo!
O que é Camunda BPM
Camunda BPM é uma plataforma de código aberto para gerenciamento de processos de negócios e automação de decisões que reúne usuários de negócios e desenvolvedores de software. É ideal para coordenar e conectar pessoas, (micro) serviços ou até mesmo robôs! Leia mais sobre vários casos de uso em .
Por que usar Kubernetes
Kubernetes se tornou o padrão de fato para executar aplicativos modernos no Linux. Com o uso de chamadas de sistema em vez da emulação do nível de hardware e as capacidades do núcleo de gerenciar memória e alternância de tarefas, o tempo de inicialização e o tempo de execução são reduzidos ao mínimo. No entanto, o maior benefício pode ser o padrão de API que o Kubernetes fornece para configurar a infraestrutura necessária para todos os aplicativos: armazenamento, rede e monitoramento. Em junho de 2020, completou 6 anos e é, sem dúvida, o segundo maior projeto de código aberto (depois do Linux). Recentemente, ele está estabilizando ativamente sua funcionalidade após uma rápida iteração nos últimos anos, pois isso se torna crítico para cargas de trabalho de produção em todo o mundo.
O Camunda BPM Engine pode facilmente se conectar a outros aplicativos que estão no mesmo cluster, enquanto o Kubernetes oferece excelente escalabilidade, permitindo aumentar os custos de infraestrutura apenas quando realmente necessário (e facilmente reduzi-los quando necessário).
A qualidade da monitoria é também significativamente aprimorada com ferramentas como Prometheus, Grafana, Loki, Fluentd e Elasticsearch, permitindo visualizar centralizadamente todas as cargas de trabalho do cluster. Hoje, veremos como implementar o exportador Prometheus em uma máquina virtual Java (JVM).
Objetivos
Vamos analisar algumas áreas onde podemos configurar a imagem Docker do Camunda BPM (), para que funcione bem com o Kubernetes.
- Logs e métricas;
- Conexões com o banco de dados;
- Autenticação;
- Gerenciamento de sessões.
Veremos algumas maneiras de alcançar esses objetivos e mostraremos visualmente todo o processo.
Nota: Está usando a versão Enterprise? Veja e atualize os links das imagens, se necessário.
Desenvolvimento de workflow
Nesta demonstração, usaremos o Skaffold para construir imagens Docker com o Google Cloud Build. Ele tem um bom suporte para várias ferramentas (como Kustomize e Helm), CI e ferramentas de build, bem como provedores de infraestrutura. O arquivo skaffold.yaml.tmpl inclui configurações para o Google Cloud Build e GKE, o que oferece uma maneira muito simples de implementar infraestrutura de nível industrial.
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 possui muitas outras funcionalidades.
Para templates yaml no Kubernetes, usamos o kustomize para gerenciar sobreposições yaml sem ramificar todo o manifesto, permitindo que você use git pull --rebase para melhorias adicionais. Agora está no kubectl e isso funciona razoavelmente bem para tais 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 isso funciona em makefile ou simplesmente continuar em frente.
Pré-requisitos
- Cluster de trabalho
- — para criar suas próprias imagens Docker e facilitar a implantação no GKE
- Uma cópia deste código
- Envsubst
Workflow com manifestos
Se você não quiser usar kustomize ou skaffold, pode consultar os manifestos em generated-manifest.yaml e adaptá-los ao workflow de sua escolha.
Logs e métricas
Prometheus se tornou o padrão para coleta de métricas no Kubernetes. Ele ocupa o mesmo espaço que o AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics e outros. Possui código aberto e uma linguagem de consulta poderosa. Vamos deixar a visualização para o Grafana — ele vem com uma grande quantidade de painéis de monitoramento, disponíveis pronto para uso. Eles são interconectados e relativamente simples de instalar com .
Por padrão, o Prometheus utiliza o modelo de extração /metrics, e a adição de contêineres sidecar para isso é uma prática comum. Infelizmente, as métricas JMX são melhores registradas dentro da JVM, portanto, os contêineres sidecar não são tão eficazes. Vamos conectar de código aberto do Prometheus à JVM, adicionando-o à imagem do contêiner, que fornecerá um caminho /metrics em outra porta.
Adicione o 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, foi fácil. O exportador irá monitorar o tomcat e exibir suas métricas no formato Prometheus no endereço :9404/metrics
Configuração do exportador
O atento leitor pode se perguntar, de onde veio prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Nós adicionaremos o tomcat como no Kubernetes, e então o montaremos como um volume.
Primeiro, adicionamos o arquivo de configuração do exportador ao nosso diretório platform/config/
plataforma/config
└── prometheus-jmx.yaml
Em seguida, adicionamos em kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Isso adicionará cada item files[] como um item de configuração ConfigMap. Os ConfigMapGenerators são bons porque eles hash os dados de configuração e iniciam a reinicialização do pod se forem alterados. Eles também reduzem a quantidade de configuração no Deployment, já que você pode montar toda a "pasta" de arquivos de configuração em um único VolumeMount.
Finalmente, precisamos montar o ConfigMap como um volume ao pod:
-- plataforma/deployment.yaml
apiVersion: apps/v1
tipo: Implantação
[...]
especificação:
modelo:
especificação:
[...]
volumes:
- name: config
configMap:
nome: config
modoPadrão: 0744
contêineres:
- nome: camunda-bpm
montagensDeVolume:
- caminhoDeMontagem: /etc/config/
nome: config
[...]
Ótimo. Se o Prometheus não estiver configurado para limpeza total, talvez você precise informá-lo para limpar os pods. Os usuários do Prometheus Operator podem usar service-monitor.yaml para começar a trabalhar. Explore Service-monitor.yaml, e antes de prosseguir.
A disseminação desse modelo para outros casos de uso
Todos os arquivos que adicionamos ao ConfigMapGenerator estarão disponíveis em um novo diretório /etc/config. Você pode expandir este modelo para montar quaisquer outros arquivos de configuração necessários. Você pode até montar um novo script de inicialização. Pode usar para montar arquivos individuais. Para atualizar arquivos xml, considere usar em vez de sed. Ele já está incluído na imagem.
Logs
Ótimas notícias! Os logs de aplicações já estão disponíveis em stdout, por exemplo, com agora pode. O Fluentd (já instalado por padrão no GKE) redirecionará seus logs para Elasticsearch, Loki ou para sua plataforma corporativa de logs. Se você quiser usar jsonify para logs, pode seguir o modelo acima para instalar .
Banco de dados
Por padrão, a imagem terá um banco de dados H2. Isso não nos atende, e vamos usar o Google Cloud SQL com o Cloud SQL Proxy — isso será necessário depois para resolver tarefas internas. É uma opção simples e confiável se você não tiver preferências próprias na configuração do banco de dados. O AWS RDS oferece um serviço semelhante.
Independentemente do banco de dados que você escolher, a menos que seja H2, você precisará definir as variáveis de ambiente apropriadas em platform/deploy.yaml. Isso se parece aproximadamente com:
-- plataforma/deployment.yaml
apiVersion: apps/v1
tipo: Implantação
[...]
especificação:
modelo:
especificação:
[...]
contêineres:
- nome: camunda-bpm
ambiente:
- nome: DB_DRIVER
valor: org.postgresql.Driver
- nome: DB_URL
valor: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- nome: DB_USERNAME
valorDe:
referênciaChaveSecreta:
nome: cambpm-db-credentials
chave: db_username
- nome: DB_PASSWORD
valorDe:
referênciaChaveSecreta:
nome: cambpm-db-credentials
chave: db_password
[...]
Nota: Você pode usar o Kustomize para a implantação em diferentes ambientes usando sobreposições: .
Nota: usando valueFrom: secretKeyRef. Por favor, use mesmo durante o desenvolvimento, para manter seus segredos seguros.
É muito provável que você já tenha um sistema de gerenciamento de segredos preferido do Kubernetes. Se não, aqui estão algumas opções: criptografá-los usando o KMS do seu provedor de nuvem e, em seguida, injetá-los no K8S como segredos através do pipeline de CI/CD — funcionará muito bem em conjunto com os segredos do Kustomize. Existem outras ferramentas como o dotGPG — elas desempenham funções semelhantes: , .
Ingress
A menos que você decida usar o redirecionamento de porta local, você precisará de um Ingress Controller configurado. Se você não estiver usando () então, provavelmente, você já sabe que precisa instalar as anotações necessárias em ingress-patch.yaml.tmpl ou platform/ingress.yaml. Se você está usando ingress-nginx e vê a classe de ingress do nginx com um balanceador de carga apontando para ele e DNS externo ou um registro DNS cúmplice, tudo está pronto. Caso contrário, configure o Ingress Controller e o DNS ou pule 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 ingresso serão obtidos automaticamente. Caso contrário, abra ingress-patch.yaml.tmpl e configure-o de acordo com suas necessidades.
Iniciar!
Se você seguiu tudo o que foi escrito acima, o comando make skaffold HOSTNAME= deve iniciar uma instância acessível em /camunda
Se você não expôs o ingresso através de uma URL pública, pode redirecioná-lo de localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 para 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. Depois disso, você pode monitorar os logs com ferramentas disponíveis — como uma ferramenta como kubetail, ou simplesmente com kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Próximos passos
Autorização
Isso está mais relacionado à configuração do Camunda BPM do que ao Kubernetes, mas é importante notar que por padrão a autenticação na API REST está desativada. Você pode ou usar outro método, como . Você pode usar configmaps e volumes para carregar xml, ou xmlstarlet (veja acima) para editar arquivos existentes na imagem, além de usar wget ou fazer o upload através de um contêiner init e um volume compartilhado.
Gerenciamento de Sessões
Como muitos outros aplicativos, o Camunda BPM gerencia sessões na JVM, portanto, se você quiser executar várias réplicas, pode ativar sessões persistentes (), que existirão até que a réplica desapareça, ou definir o atributo Max-Age para cookies. Como uma solução mais confiável, você pode implantar um Gerenciador de Sessões no Tomcat. Lars tem sobre o assunto, 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 '/^/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 usamos antes do Google Cloud Memorystore, com (suporta Redis) para executá-lo.
Escalabilidade
Se você já entendeu sobre 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 configuração parcial já está disponível "". Também vamos desativar o initialSize no arquivo settings.xml. Adicione e você poderá escalar automaticamente o número de pods com facilidade.
Requisições e Limitações
Em platform/deployment.yaml você verá que codificamos rigidamente o campo de recursos. Isso funciona bem com HPA, mas pode precisar de configuração adicional. Para isso, um patch do kustomize é adequado. Veja ingress-patch.yaml.tmpl e ./kustomization.yaml.tmpl
Saída
Aqui instalamos o Camunda BPM no Kubernetes com métricas do 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 com volumes e diretamente nas variáveis de ambiente a partir de segredos. Além disso, fornecemos uma visão geral da configuração do Camunda para várias réplicas e uma API autenticada.
Links
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifesto para uso sem kustomize
├── imagens
│ └── camunda-bpm
│ └── Dockerfile <- imagem docker sobreposta
├── ingress-patch.yaml.tmpl <- configuração de ingress específica do site
├── kustomization.yaml.tmpl <- Kustomização principal
├── Makefile <- alvos do make
├── namespace.yaml
├── plataforma
│ ├── config
│ │ └── prometheus-jmx.yaml <- arquivo de configuração do exportador prometheus
│ ├── deployment.yaml <- implantação principal
│ ├── ingress.yaml
│ ├── kustomization.yaml <- kustomização "base"
│ ├── service-monitor.yaml <- configuração de exemplo do prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- diretrizes do skaffold
05.08.2020, tradução Alastair Firth, Lars Lange
Fonte: habr.com
