Anypoint Runtime Fabric é um serviço de contêiner que automatiza a implantação e orquestração de aplicativos Mule e gateways API. O Runtime Fabric é executado em uma infraestrutura gerenciada pelo cliente em AWS, Azure, máquinas virtuais (VMs) e servidores bare-metal.
Alguns dos recursos do Anypoint Runtime Fabric incluem:
- Isolamento entre aplicativos executando um mecanismo de tempo de execução Mule separado por aplicativo.
- Capacidade de executar várias versões do Mule no mesmo conjunto de recursos.
- Escalando aplicativos em várias réplicas.
- Failover de aplicativo automatizado.
- Gerenciamento de aplicativos com Anypoint Runtime Manager.
Contents
Opções de implantação atuais
As instruções atuais de implantação do Runtime Fabric para nuvens públicas incluem implantação em AWS e Azure. Não há documentação de implantação para Oracle Cloud. Este artigo o orientará no processo de instalação e implantação manual do Runtime Fabric em uma infraestrutura Oracle Cloud. Ele também destaca algumas alterações necessárias para instalar o Runtime Fabric com êxito.
Certifique-se de atender aos requisitos de instalação – mencionados aqui – antes de continuar a configuração. Anypoint Runtime Fabric oferece suporte a configuração de desenvolvimento e produção. Cada uma dessas configurações com suporte especifica os nós e recursos mínimos necessários.
Nesta configuração, usaremos a configuração de desenvolvimento. Esta configuração requer pelo menos um controlador e dois nós de trabalho.
Precisamos primeiro criar a infraestrutura necessária no Oracle Cloud. A configuração mínima necessária para uma configuração de desenvolvimento está listada abaixo.
Construir a infraestrutura em Oracle Cloud
Em primeiro lugar, você precisa construir a infraestrutura necessária para implantar o Runtime Fabric. Como vamos implantar uma configuração de desenvolvimento com um controlador e dois nós de trabalho, precisaremos de três máquinas virtuais que atendam aos requisitos de infraestrutura e sistema operacional.
Lançar máquinas virtuais
Crie três VMs. Um para o nó controlador e um para dois nós de trabalho com os requisitos mínimos abaixo. Você pode escolher RHEL ou Centos OS dentro das versões com suporte listadas nos requisitos do sistema operacional.
Além disso, crie e anexe volumes de bloco a cada uma das VMs correspondentes. Esses volumes de block também devem atender aos requisitos de armazenamento e aos requisitos de IOPS mencionados na documentação.
Nó controlador:
Nó / s de trabalho:
Requisitos de porta de rede
É recomendável abrir apenas as portas do firewall conforme documentado nos requisitos de porta de rede.
A imagem a seguir representa as portas de entrada que foram abertas para permitir o tráfego para as instâncias e permitir o acesso ao centro de operações a partir da web. 
Instalação do Runtime Fabric
Faça login no nó do controlador e siga as etapas de instalação manual conforme descrito aqui.
- Base64 codifica suas chaves de licença Mule.
- Defina as variáveis:
- RTF_CONTROLLER_IPS = ”172.31.1.9 ″
- RTF_WORKER_IPS = ”172.31.1.7 172.31.1.8 ″
- RTF_ACTIVATION_DATA = ”YW55cG9pbnQubXVsZXNvxxxxxxmQ4NzViYjQ5LTFjZTktNDk0NC05ZjlmLTFkMjQ4YTE0NDczMQ ==”
- RTF_DOCKER_DEVICE: / dev / sdb2
- RTF_ETCD_DEVICE: / dev / sdb1
- RTF_MULE_LICENSE: == “2414asdfgdDSFSDFSD31234098f”
- Use o script ./generate-configs.sh para gerar as variáveis de ambiente para cada VM. Isso deve gerar um conjunto de instruções e um script para executar em cada uma das VMs (controlador, nó de trabalho um e nó de trabalho dois).
- Execute o snippet gerado acima em cada VM (nó controlador e os dois nós de trabalho) com base no endereço IP para aplicar as variáveis de ambiente.
- Em cada VM, copie o arquivo ./scripts/init.sh para / opt / anypoint / runtimefabric e torne-o executável.
- Execute o script init.sh em um modo privilegiado.
|
[opc@devops runtimefabric]$ sudo chmod +x /optar/qualquer ponto/runtimefabric/iniciar.sh |
- Isso deve iniciar o processo de instalação. O processo de instalação será executado por meio de algumas pré-verificações e disponibilidade dos pacotes necessários. Se todos os requisitos forem atendidos, o script continuará o processo de instalação. A instalação é concluída após a execução de 15 etapas.
Se você tiver problemas durante a instalação, será necessário monitorar o erro na janela do terminal ou visualizar os logs no arquivo /var/log/rtf-init.log. Você então precisará corrigir o problema e executar novamente o script init.sh.
Coisas a serem observadas durante a instalação no Oracle Cloud
Para sobreviver a uma reinicialização da VM e conectar o dispositivo de bloco à instância de computação
Edite o arquivo / etc / fstab para incluir a opção ‘_netdev’ nas duas linhas adicionadas automaticamente pelo programa de instalação do Runtime Fabric.
|
[opc@devops runtimefabric]$ gato /etc/fstab .... ... UUID=f7012342–32ba–1234–b207–13123470741b /Onde/lib/gravidade xfs padrões,_netdev,nofail 0 2 # Adicionado por RTF UUID=fe4e4de2–8b0f–4c83–84d8–2a44321c93b8 /Onde/lib/gravidade/planeta/etcd xfs padrões,_netdev,nofail 0 2 # Adicionado por RTF |
Resolução de depuração de DNS
Crie um pod simples para usar como ambiente de teste. Em seguida, crie um pod de busybox chamado ‘busybox’ usando o seguinte comando:
|
[root@devops ~]# kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml debaixo/caixa ocupada criada |
Depois que o pod estiver em execução, você pode executar nslookup nesse ambiente. Se você vir algo como o seguinte, o DNS está funcionando corretamente.
|
[root@devops ~]# kubectl exec -ti busybox – nslookup kubernetes.default 
Servidor: 10.100.174.177 Endereço 1: 10.100.174.177 estar–dns–trabalhador.estar–sistema.svc.grupo.local Nome: governadores.padrão Endereço 1: 10.100.0.1 governadores.padrão.svc.grupo.local [root@devops ~]# |
Se o comando nslookup falhar, verifique o seguinte:
- Verifique a configuração DNS local.
- Dê uma olhada dentro do arquivo resolv.conf.
- Verifique se o caminho de pesquisa e o servidor de nomes estão configurados da seguinte forma:
|
[root@devops ~]# kubectl exec busybox cat /etc/resolv.conf nome do servidor 10.100.174.177 nome do servidor 10.100.210.58 procurar padrão.svc.grupo.local svc.grupo.local grupo.local rtfvcn.devvcn.com publicsubnetad1.rtfvcn.devvcn.com opções ndots:5 [root@devops ~]# |
Erros como os seguintes indicam um problema com os coredns ou serviços associados:
|
kubectl exec –vocês caixa ocupada – nslookup governadores.padrão Servidor: 10.100.174.177 Endereço 1: 10.100.174.177 nslookup: pode‘não resolver’governadores.padrão‘ |
Para resolver isso, verifique se o pod DNS está em execução. Em seguida, use o comando kubectl get pods para verificar se o pod DNS está em execução.
|
[root@devops ~]# kubectl get pods –namespace = kube-system -l k8s-app = kube-dns NOME PRONTO STATUS RESTARTS ERA Coredns–kpxmr 1/1 Corrida 0 6d21h [root@devops ~]# |
Se você notar que nenhum pod está em execução ou que o pod falhou / foi concluído, o complemento DNS pode não ser implantado por padrão em seu ambiente atual e você terá que implantá-lo manualmente.
Verifique se o serviço DNS está ativo usando o comando kubectl get service.
|
[root@devops ~]# kubectl get svc –namespace = kube-system NOME TIPO GRUPO–IP EXTERNO–IP PORTA(S) ERA gravidade–local Balanceador de carga 10.100.200.123 <pendente> 3009:32009/TCP 6d21h estar–dns ClusterIP 10.100.210.58 <Nenhum> 53/UDP,53/TCP 6d21h estar–dns–trabalhador ClusterIP 10.100.174.177 <Nenhum> 53/UDP,53/TCP 6d21h registro–colecionador ClusterIP 10.100.144.45 <Nenhum> 514/UDP,514/TCP,8083/TCP 6d21h [root@devops ~]# |
Você pode verificar se os pontos de extremidade DNS estão expostos usando o comando kubectl get endpoints.
|
[root@devops ~]# kubectl get ep kube-dns –namespace = kube-system NOME ENDPOINTS ERA estar–dns 10.244.22.3:53,10.244.22.3:53 6d21h [root@devops ~]# |
Saiba mais sobre o produto e o processo de instalação manual na documentação. Comece sua avaliação gratuita da plataforma Anypoint e teste o Anypoint Runtime Fabric agora.
