Migração no local para Cloudhub | MuleSoft Blog

Migração no local para Cloudhub | MuleSoft Blog

Migração no local para Cloudhub | MuleSoft Blog
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Sua organização está passando por uma transformação digital? Seu departamento de TI está sob pressão para mover todos os aplicativos e infraestrutura para a nuvem? Atualmente, um número crescente de organizações procura soluções iPaaS que fornecem pilhas integradas de software e hardware para implantações rápidas, gerenciamento e um ROI mais alto. Produtos SaaS como Salesforce, Workday e ServiceNow têm o sistema de registros na nuvem, que é outra razão pela qual as empresas estão migrando para a nuvem. Isso reduz o custo de manutenção da infraestrutura e as dependências de diferentes equipes, como Rede, InfoSec, Equipe de infraestrutura etc.

CloudHub é a oferta iPaaS da MuleSoft, uma solução totalmente baseada em nuvem que fornece uma verdadeira plataforma de conectividade unificada para os desenvolvedores criarem aplicativos de integração em pacote. Cada vez mais as organizações estão transferindo seus aplicativos MuleSoft do local para o CloudHub, para uma abordagem moderna que melhora a eficiência operacional e promove ciclos de desenvolvimento mais rápidos. A migração para o CloudHub pode parecer uma tarefa assustadora, pois requer uma abordagem holística com um forte entendimento das melhores práticas de desenvolvimento do CloudHub Architecture e CloudHub Application para ser bem-sucedida. No entanto, com um planejamento cuidadoso e a alavancagem dos recursos disponíveis, vimos muitas migrações bem-sucedidas para aplicativos MuleSoft do local para o CloudHub.

Este guia o ajudará a abordar algumas das considerações iniciais sobre a migração da configuração local para o CloudHub (VPC / VPN / DLB).

Fig: Arquitetura de rede do CloudHub VPC.

Provisionamento do CloudHub vCore:

  • Para implantar aplicativos no CloudHub, você precisa provisionar vCores para a organização. Você pode comprar novos vCores ou usar os núcleos locais existentes que podem ser convertidos em CloudHub vCores. Nota: 1 núcleo local = 1vCore.
  • Considere adotar uma abordagem em fases convertendo alguns núcleos locais em vCores. O dimensionamento do aplicativo precisa ser feito nas fases iniciais para planejar as migrações futuras. O CloudHub possui diferentes tamanhos de trabalhadores para executar um aplicativo. 0,1 vCore e 0,2 vCore, que oferecem CPU e memória limitadas para integrações simples. Integrações mais complexas podem usar tamanhos de trabalhadores maiores (1vCore, 2vCore e assim por diante) para necessidades de armazenamento extras e mais recursos de processamento.

Configuração de VPC

  • A assinatura base do Anypoint VPC inclui dois AnyPC VPCs e cada Anypoint VPC pode ser associado a vários ambientes. Se você não criar uma VPC, os aplicativos serão implantados na Shared Worker Cloud. Por exemplo, a configuração mais comum tem uma rede isolada para o seu ambiente de produção e outra para os ambientes que não são de produção, que podem ser controle de qualidade e preparação.
  • Coloque uma VPC na organização Anypoint no grupo de negócios da organização principal. Geralmente, crie a VPC na sua organização principal e, em seguida, ela poderá ser compartilhada com diferentes grupos de negócios.
  • O Anypoint VPC suporta diferentes regiões da Amazônia. Durante a configuração da VPC, você precisará atribuir a região Amazon que será usada para hospedar os trabalhadores do CloudHub. Geralmente, a região selecionada é a mais próxima do data center do cliente.
  • Determine o tamanho e o intervalo do bloco CIDR da VPC. A VPC não pode ser redimensionada depois que o aplicativo é implantado, portanto, uma etapa muito importante dimensiona a VPC grande o suficiente para acomodar IPs suficientes para todos os serviços e instâncias.
    • Regra prática: Instâncias de aplicativo esperadas * 10 para permitir a expansão.
    • O espaço de endereço reservado pelos trabalhadores da MuleSoft não deve entrar em conflito com o espaço de endereço no data center do cliente.
  • Configure as regras de firewall da VPC. Antes de implementar regras de firewall ou fazer alterações nas regras existentes, você deve entender completamente todas as implicações de segurança
  • Adicione os domínios de pesquisa DNS para poder usar os nomes de host internos da sua rede privada.
  • Identifique os aplicativos que precisam de IPs estáticos, pois uma VPC fornece apenas dois IPs estáticos.

Crie VPN para conectar-se a centros de dados

  • A assinatura base da plataforma Anypoint vem com 2VPCs + 4 VPNs. Não há custo na configuração da VPN, pois é um processo de autoatendimento. A documentação aqui mostra as etapas para criar uma VPN do Anypoint.
  • Algumas das opções de conectividade disponíveis com suporte comum são: VPC Peering, IPSec VPN, AWS Direct Connect.
  • Após a conclusão da configuração da conexão VPN, a conectividade com outras redes pode ser testada usando o aplicativo Ferramentas de rede.
  • Para obter mais informações, leia mais em nossa Central de Ajuda: https://help.mulesoft.com/s/article/Anypoint-VPN-Knowledge-Articles

Balanceador de carga compartilhada

  • O SLB (Shared Load Balancer) fornece os recursos básicos de balanceamento de carga. Você não pode adicionar nenhum certificado SSL personalizado no balanceador de carga compartilhado.
  • O SLB envia o tráfego HTTPS para a porta 8082 e o tráfego HTTP para a porta 8081.
  • Se você precisar de uma configuração personalizada do balanceador de carga, precisará fornecer uma autorização do Dedicated Load Balancer.
  • Mais detalhes sobre a conectividade podem ser encontrados aqui.

Configurar balanceador de carga dedicado

  • O DLB (Dedicated Load Balancer) é um componente opcional da plataforma Anypoint. A configuração do DLB será diferente do balanceador de carga local existente. O balanceador de carga dedicado roteia o tráfego externo e interno da VPC para os funcionários do CloudHub implantados na AnyPC VPC. Ele atua como um único ponto de entrada de redes externas.
  • A melhor prática recomendada é provisionar um DLB para cada VPC, mas um VPC pode ter vários DLBs.
  • Ao configurar o DLB, crie padrões de nome da API. Por exemplo: –Api.seuaempresa.com/ api //
  • Os clientes podem criar domínios personalizados com seu próprio URL personalizado usando o DLB.
  • Crie regras de mapeamento que possam oferecer suporte ao roteamento para diferentes versões de uma API.
  • Adicione um certificado de CA da sua empresa. O DLB exige ter pelo menos um certificado.
  • Determine as regras de entrada para bloquear o HTTP e permitir apenas HTTPS (conforme o requisito). Esta é uma etapa importante e envolva suas equipes de segurança para garantir que você siga as diretrizes padrão em sua organização.
  • Aqui estão as etapas para criar um balanceador de carga dedicado.

Alta disponibilidade e recuperação de desastres

  • A alta disponibilidade no MuleSoft pode ser alcançada implantando o aplicativo Mule em vários trabalhadores em uma região.
  • Para a recuperação de falhas, implante o aplicativo Mule em várias regiões. Você precisará usar seu próprio balanceador de carga ou proxy para distribuir o tráfego entre esses aplicativos.

IP / portas / URLs a serem incluídos na lista de permissões

  • Envolva suas equipes de segurança de rede para verificar se todas as portas e IPs estão na lista de permissões da lista mencionada aqui.

Desenvolvendo aplicativos para CloudHub

Depois de concluir as configurações do seu ambiente CloudHub, categorize os aplicativos locais em ordem de prioridade e comece a implantar em ambientes que não sejam de produção. Pense em redesenhar o aplicativo ao mudar para o CloudHub para aproveitar os recursos avançados, por exemplo: Object Store (V2).

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
  • Recursos compartilhados: o CloudHub não suporta o uso de recursos compartilhados do domínio. A arquitetura do CloudHub garante que sempre haja um aplicativo implantado em um único Mule Runtime dedicado. Se seu aplicativo local tiver um projeto de domínio com configurações compartilhadas, será necessário refatorar essas configurações e ter configurações locais para cada aplicativo no CloudHub. Por exemplo: ouvintes HTTP / HTTPS, configuração de banco de dados etc.
  • Em alguns cenários, pode ser necessário compartilhar a lógica do aplicativo no CloudHub. Por exemplo: tratamento de erros. Você pode conseguir isso criando um projeto separado, empacotado como jar. Este projeto pode ser adicionado como uma dependência usando uma ferramenta de gerenciamento de dependências, como Maven ou Gradle. Mais detalhes sobre as etapas são mencionados aqui.
  • As portas para o ouvinte HTTP são diferentes para aplicativos CloudHub. Os aplicativos Mule implantados no CloudHub devem escutar no host 0.0.0.0 e na porta HTTP (8081) ou na porta HTTPS (8082). Se você deseja restringir o acesso aos aplicativos diretamente da Internet, pode usar a porta HTTP da porta (8091) e a porta HTTPS (8092), que aceitarão a solicitação recebida apenas na rede privada.
  • As propriedades do ambiente definidas no tempo de execução local precisam ser movidas para as propriedades do CloudHub no gerenciador de tempo de execução.
  • A lógica de transformação do DataWeave nos aplicativos locais existentes pode ser reutilizada nos aplicativos CloudHub.
  • Faça alterações nos aplicativos que usam conectores não suportados no CloudHub. Por exemplo: O File Connector pode ser substituído pelo conector FTP.
  • Dois IPs estáticos são alocados para cada VPC. Isso pode ser necessário se você tiver aplicativos de consumidor que precisem colocar na lista branca o IP do servidor.
  • Diferenças entre filas persistentes de VM, ObjectStores e Schedule Services.
  • Se o servidor local fosse uma máquina Windows, você poderá executar a autenticação do usuário no Runtime usando a autenticação de domínio. No CloudHub, você precisará configurar o SSO ou usar a conta de serviço para entrar na plataforma para acessar o tempo de execução do CloudHub. Se o tempo de execução do Windows local se conectar ao MS Dynamics, PowerShell etc., você precisará instalar os serviços do Windows Gateway na máquina Windows para poder se conectar ao CloudHub.
  • A fila de VM persistente do CloudHub não mantém a ordem da mensagem enviada devido às limitações subjacentes da arquitetura. Se você precisar preservar a ordem das mensagens, considere o Anypoint MQ (é necessário uma assinatura) para a funcionalidade de sistema de mensagens persistente.
  • Armazenamento em cache no CloudHub: os trabalhadores do CloudHub não estão agrupados em cluster e, portanto, o ObjectStore na memória padrão que deve ser usado em um cluster por meio da replicação de hazelcast como mecanismo de back-end, falha quando implantado no CloudHub. O cache pode ser implementado no CloudHub usando o ObjectStore v2. O armazenamento de objetos pode ser usado para armazenar os dados em um aplicativo Mule de um único trabalhador ou vários trabalhadores. Se houver necessidade de compartilhar os dados entre diferentes componentes, o OSv2 fornece a API REST para acessar as entradas.
  • O ajuste no nível da JVM não está disponível no CloudHub. Os trabalhadores do CloudHub são alocados com o conjunto de parâmetros padrão da JVM.

Monitoramento e registro

  • Se o sistema local tiver agentes de agregação de log instalados, como SPLUNK ou ELK, será necessário alterar a estratégia, pois o CloudHub não permite a instalação de agentes externos no tempo de execução.
  • O log4j.xml compartilhado para vários aplicativos Mule não é suportado no CloudHub. Cada aplicativo CloudHub precisará empacotar um log4j.xml personalizado com anexadores adicionados ao sistema de log externo, se necessário. Exemplo: SPLUNK ou ELK. Solicitação do recurso “Desativar logs do CloudHub” para enviar eventos para os sistemas externos. Observe que esta solução faz com que os logs não sejam mais armazenados em nossa plataforma.
  • Os logs do CloudHub também podem ser extraídos e publicados nos sistemas de log externos usando a API TCP ou a API HTTP. Você pode usar a ferramenta de linha de comando comandos do Anypoint da CLI ou a API do CloudHub para baixar os logs.
  • As perguntas frequentes sobre o registro estão aqui.
  • Faça as alterações necessárias nos alertas existentes na plataforma ou adicione novos alertas específicos ao tempo de execução do CloudHub. Mais informações sobre os alertas disponíveis para o CloudHub podem ser encontradas aqui.
  • Os clientes do Enterprise License Agreement (ELA) podem ter o recurso Auto-Scaling no CloudHub, que pode ser usado para aumentar e diminuir os recursos de processamento de um aplicativo.

DevOps

  • Faça as alterações necessárias no pipeline do CICD para implantar as novas integrações no CloudHub.
  • Se você estiver usando o Mule Maven Plugin para implantar no CloudHub, altere o pom.xml para os projetos do Mule e, no elemento plugin, configure sua implantação do CloudHub.
  • Algumas das outras opções são:

Teste

  • Após a conclusão do desenvolvimento, promova os aplicativos para o ambiente de controle de qualidade e execute um conjunto completo de testes de regressão.
  • O teste de desempenho é uma etapa muito importante ao migrar os aplicativos para o CloudHub para garantir que o dimensionamento seja adequado aos picos de carga na produção. Para o tempo de execução local do Mule, todos os aplicativos compartilham o mesmo tempo de execução e recursos e, portanto, podem suportar cargas de pico diferentes. A alocação de CPU e memória dos aplicativos CloudHub é determinada pelo tamanho do trabalhador alocado a ele.
  • O CloudHub fornece recursos de burst para 0.1vCore e 0.2vCore e é importante ter métricas quantificáveis ​​após a realização de testes de desempenho para tomar decisões de arquitetura informadas para o dimensionamento dos aplicativos Mule. Mais detalhes sobre a capacidade de burst podem ser encontrados na documentação.
  • O teste de penetração, se necessário, pode ser realizado nos tempos de execução do CloudHub após a notificação da equipe do MuleSoft Security. Mais detalhes podem ser encontrados na documentação para políticas de teste de penetração.

As etapas acima mencionadas não são um plano de migração de ponta a ponta para o CloudHub, mas um resumo dos recursos do Anypoint que serão necessários e o código do aplicativo é alterado para os aplicativos Mule. Para reduzir a dívida técnica, considere a adoção do tempo de execução avançado do Mule 4 ao migrar do local para aplicativos existentes do Mule 3. Se você precisar de orientação sobre o plano de migração específico para os aplicativos MuleSoft da sua organização, entre em contato com o MuleSoft Professional Services ou com um parceiro MuleSoft.

No meu próximo blog, abordaremos as etapas da migração de aplicativos Mule locais para o Runtime Fabric.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso