Conheça a principal novidade do novo Magic xpi 4.14: um novo orquestrador para o sistema de mensageria.
A nova versão (4.14) do Magic xpi já está disponível:
e traz uma série de novidades e recursos.
Mas nesta publicação, vamos focar naquela que certamente é a mais impactante: o novo orquestrador de mensagens e processos, InMemoryMiddleware (IMM).
Estão saindo de cena (presentes desde a versão 4.0 até a 4.13.6):
- GigaSpaces XAP
- RTView
- Banco interno em SQL
e chegando para assumir a orquestra (a partir da versão 4.14):
O InMemoryMiddleware (IMM) é um produto (tecnologia) próprio da Magic Software, que combina as soluções destacadas acima e objetiva além de acompanhar as mais avançadas tecnologias atuais, continuar evoluindo o Magic xpi em robustez e escalabilidade.
Não dá para falar com justiça de todas os novos recursos da versão nova do Magic xpi em um único post.
Por isso vamos destacar a partir de agora o primeiro impacto dessa mudança: o processo de instalação com o IMM.
A partir desta versão 4.14 conseguimos ver este processo claramente separado em 3 fases distintas:
- Pré-Instalação
- Instalação
- Pós-Instalação
Pré – Instalação
Embora o Magic xpi Studio e o Magic xpi Server sigam disponíveis também na versão Windows (Microsoft), que é o SO onde o Magic xpi predomina desde sempre, o InMemoryMiddleware (IMM) obrigatoriamente requer um ambiente Linux (por conta do Docker/Kubernetes).
Pode ser um servidor real ou servidor virtual (VMWare, VirtualBox, WSL2).
*Nota: Se o Linux ainda é um desconhecido para você, reserve um tempo para conhecê-lo.
Focando na praticidade do desenvolvedor (que usa primariamente o Magic xpi Studio no Windows), neste post vamos abordar a opção de uso do WSL2 (que é mais prático para os usuários Windows).
Mas como o nosso foco aqui é o Magic xpi e o IMM, nossa passagem sobre o Linux será superficial. Ele não é a nossa estrela.
Por isso, necessitando de mais detalhes sobre Linux, Docker ou Kubernetes, boas fontes de referência: OpenAI e/ou Google.
Para começar, você precisará ter:
- Windows 10 ou Windows 11
- Recurso do “Hyper-V” ativado no seu Windows
- Recurso do “WSL2” instalado no seu Windows
*Nota: aqui, um detalhe muito importante: precisa ser a opção de WSL2 da "Microsoft Store", e não o que está nos "Programas e Recursos" do Windows. Isso porque essa 1ª tem suporte ao systemd, e a segunda, não tem.
Uma vez que estas instalações/configurações iniciais foram concluídas com sucesso, basta abrir o prompt do DOS como “Admistrador” e digitar:
wsl -l -o
para ver que opções (versões) do Linux estarão disponíveis na web (Microsoft).
Nós usaremos a Ubuntu 22.04 LTS (Jammy Jellyfish). Ex:
wsl --install Ubuntu-22.04
Então, com o comando:
wsl --version
podemos confirmar a nossa versão do WSL2:
Com o comando:
wsl -l -v
podemos ver quais Linux temos instalados em nossa máquina:
E com o comando:
wsl -d Ubuntu-22.04
iniciamos nossa sessão (ou máquina virtual) Linux:
*Nota: Neste ambiente do post, as interações Linux são feitas com um usuário chamado magicxpi (não com o root).
Após, precisamos criar/editar o arquivo /etc/wsl.conf (no Linux ) e garantir que existam as chaves: systemd=true e swap=0 (zero):
reiniciando o WSL2/Linux em seguida. Este reinício pode ser com esta sequência de comandos:
exit (no Linux) wsl --shutdown (no Widows) wsl -d Ubuntu-22.04 (no Windows)
Podemos confirmar que o swap está desligado com o comando:
free
*Nota: Caso você deseje ter esta inicialização do Ubuntu/WSL2 de forma automática no boot do seu Windows, pode pesquisar na internet sobre como automatizar este processo.
Com o Linux pronto, a nossa primeira instalação precisa ser do Docker.
Uma sugestão de guia de instalação Docker para Linux, pode ser esta: https://phoenixnap.com/kb/install-docker-on-ubuntu-20-04 ou esta: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-22-04 (mas você está livre para buscar outras. Nós seguimos estas dicas para montar este ambiente)
Para confirmar a instalação bem sucedida, execute (no Linux ) os comandos:
sudo systemctl status docker
sudo systemctl status containerd
A saída de “serviço ativo” informa que está OK o Docker.
*Nota: O systemd é um pré-requisito para esses serviços. Por isso o destaque anterior sobre a necessidade dele.
Em seguida, executamos os comandos:
sudo docker info
sudo docker run hello-world
E vemos novamente que até aqui foi completado com sucesso.
Nossa segunda instalação precisa ser do MicroK8s Kubernetes (que depende do systemd ativado e swap desativado).
Uma sugestão de guia de instalação MicroK8s para Linux, pode ser esta: https://microk8s.io/ ou esta: https://microk8s.io/docs/install-wsl2 (mas você está livre para buscar outras. Nós seguimos estas dicas para montar este ambiente)
Antes de começar esta parte, precisamos capturar o IP do adaptador eth0 da máquina Linux (e guardá-lo). Isso é feito com o comando:
ifconfig
Prosseguindo e após concluir a instalação do MicroK8s Kubernetes, precisamos adicionar dois addOns a ele: dns e metallb.
*Nota: Existem vários outros addOns que podem aparecer an web como sugestão de instalação, mas o nosso ambiente só necessita destes dois, e por isso incluiremos somente estes dois.
Isso é feito com os comandos:
sudo microk8s enable dns sudo microk8s enable metallb
Nesse momento, será solicitada uma faixa de IPs para o metallb. Devemos informar o valor que capturamos antes, no formato <IP>-<IP>, ex:
172.25.142.51-172.25.142.51
*Nota: Se no futuro o IP mudar, você pode executar estes comandos em sequência:
sudo microk8s disable dns sudo microk8s disable metallb sudo microk8s enable dns sudo microk8s enable metallb
e informar o novo número, quando for novamente perguntado.
Em seguida, executamos o comando:
sudo microk8s status --wait-ready
E vemos que está OK o MicroK8s/Kubernetes.
Rodando os comandos:
sudo microk8s kubectl version --client --output=yaml
sudo microk8s kubectl get pod --all-namespaces
Vemos novamente que até aqui foi completado com sucesso.
Em seguida, precisamos rodar o comando:
sudo microk8s kubectl config view --raw
e guardar este resultado, junto com o IP da máquina Linux (obtido anteriormente).
Esta é a configuração de acesso a este ambiente Kubernetes.
Para finalizar do lado Linux , existem algumas portas TCPs que precisam ser abertas no firewall: 27017, 6739, 80, 53, 9153, 443, 6443 e 16443.
Nós fazemos isso (no Linux Ubuntu) com o comando:
sudo ufw allow <nro porta TCP>
Nossa terceira instalação precisa ser do Kubernetes for Windows (fora do Linux agora).
Por isso deixamos o Linux de lado um momento (mas sem desligá-lo) e vamos ao prompt do DOS do Windows (host do WSL2 neste caso) como “Adminitrador“.
Começamos adicionando uma entrada no arquivo \Windows\System32\drivers\etc\hosts com o IP da máquina Linux e o nome “kubernetes.default.svc.cluster.local“, assim:
172.25.142.51 kubernetes.default.svc.cluster.local
de forma que esta máquina Linux seja acessível por este nome:
*Nota: Na instalação padrão do microk8s, é gerado um certificado digital (X.509) para os nomes de domínio: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster e kubernetes.default.svc.cluster.local. Por isso a escolha deste nome.
Em seguida, vamos instalar o Chocolatey, rodando este comando no Windows PowerShell (como “Administrador“):
powershell Set-ExecutionPolicy Bypass -Scope Process -Force;[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
Uma vez que ele esteja instalado (estará na pasta %ProgramData%\chocolatey), podemos conferir com o comando abaixo:
%ProgramData%\chocolatey\bin\choco
Na sequência precisamos instalar o “kubernetes-cli” e o “kubernetes-helm“. Isso é feito com estes dois comandos:
%ProgramData%\chocolatey\bin\choco install -y kubernetes-cli
%ProgramData%\chocolatey\bin\choco install -y kubernetes-helm
À continuação, temos de criar o arquivo %USERPROFILE%\.kube\config, com o mesmo conteúdo que copiamos e guardamos acima (sudo microk8s kubectl config view –raw), porém, substituindo a referência de servidor que está no Linux (ex: 127.0.0.1) por este nome que adicionamos no “hosts” do Windows (ex: kubernetes.default.svc.cluster.local), assim:
Estas configurações ficam iguais no Linux e no Windows, exceto pela identificação do servidor (neste caso de uso do WSL2).
*Nota: Se por acaso já tiver um arquivo .kube\config para outro ambiente ou propósito, pode usar o recurso do %KUBECONFIG% e unir múltiplas configurações, usando o comando kubectl config use-context para alternar entre as opções.
À continuação, adicionamos a pasta %ProgramData%\chocolatey\bin no PATH do Windows e podemos rodar os comandos:
kubectl version --client --output=yaml
helm version
E vemos que estão OK o Kbernetes-Cli/Helm-Cli.
Se executarmos os comandos:
kubectl config view
kubectl cluster-info
Podemos confirmar que nosso arquivo de confirmação no Windows está devidamente reconhecido e permite a comunicação com o Kubernetes no Linux..
Podemos rodar também o comando:
kubectl get pod --all-namespaces
e veremos o mesmo output dos pods Kubernetes que vimos anteriormente (no Linux ).
Isso é porque kubectl (no Windows) e sudo microk8s kubectl (no Linux) fazem a mesma coisa, porém um em cada SO.
Dessa forma, podemos monitorar/gerenciar o Kubernetes tanto internamente do Linux quanto externamente do Windows.
Com estas etapas, finalizamos nossa pré-instalação (preparação dos pré-requisitos).
Lembrando:
- As etapas 1 e 2 (acima: Docker/Microk8) foram no Linux (neste exemplo, um Ubutun22.04 no WSL2).
- A etapa 3 (acima: Chocolatey/Kubernetes-Cli/Helm-Cli) foi no Windows (neste exemplo, um Windows11).
Como antecipamos, nosso foco aqui não são os detalhes sobre Linux/Docker/Kubernetes. Mas como estamos no ambiente gráfico Windows, cabe um comentário: existem diversas interfaces GUI disponíveis para instalação, que permitem monitorar e gerenciar graficamente o Kubernetes, como o Octant por exemplo:
Instalação
Esta fase é tranquila e satisfatoriamente simples. Não há muitas mudanças em relação as versões anteriores:
exceto uma nova tela que pergunta informações do servidor Linux preparado previamente:
É importante que aqui seja informado aquele nome que adicionamos ao arquivo “hosts” do Windows, o mesmo nome que também informamos no arquivo %USERPROFILE%\.kube\config.
Finalizada esta parte, haverá uma pequena alteração nos serviços instalados do lado do Windows.
Não existe mais o serviço do “Magic xpi Monitor” (lembre-se que o RTView não faz mais parte do Magic xpi), e o serviço que anteriormente chamava-se “Magic xpi GSA” agora se chama: Magic xpi IMM Agent:
O IMM Agent é o módulo/componente do lado Windows que vai iniciar e executar o Magic xpi Server, e coordenar a comunicação dele com o InMemoryMiddleware que está lá no Linux .
Quando o Magic xpi Server inicia a executar um projeto de integração/automação, ele inicia como um subprocesso do IMM Agent:
Também não foi criado nenhum banco de dados “interno” (SQLServer, Oracle, MySQL).
Com estas etapas, finalizamos nossa instalação.
Pós – Instalação
Também bastante tranquila, nesta fase nós precisamos entrar na pasta %XPI_HOME%\InMemoryMiddleware\deploy:
e vamos abrir e editar (com o Bloco de Notas por exemplo) o arquivo “values.yaml“:
substituindo as informações de ‘LOG_LEVEL’ de “info” para “warn”:
Na sequência, usando o prompt do DOS (como “Administrador“), executaremos o comando:
deploy-imm.bat
Este comando faz o deploy dos pods do Magic xpi lá no Kubernetes (Linux):
e agora ao executarmos novamente o comando:
kubectl get pod --all-namespaces
podemos confirmar os pods do Magic xpi já disponíveis.
Se executarmos este comando, por exemplo, podemos ver o conteúdo da pasta $HOME (~/) do pod:
kubectl -n <namespace> exec <pod> -- ls -lart ./
Com estas etapas, finalizamos nossa pós-instalação.
E pronto. Conclui-se assim a instalação do novo Magic xpi 4.14.
Nota*: Importante destacar que todo este processo precisa ser 100% on-line, com conexão à internet, visto que muitas informações (como o deploy dos "pods") são trazidas de servidores remotos nesta hora. Além disso, este deploy precisa ser feito na instalação e também sempre que alguma destas configurações (globalsettings.properties, db_alert_config.properties, logback.xml, config.json) precisar ser alterada.
Magic xpi Monitor
Este assunto merece e receberá uma publicação só para ele, mas tem algo importante que não pode ser deixado de lado neste momento.
Durante a 3a. fase (Pós-Instalação), um breve relatório é gerado em tela e também salvo no arquivo %XPI_HOME%\InMemoryMiddleware\deploy\EndPoints.txt.
O RTView, relembrando, não faz mais parte do produto.
O Magic xpi Monitor agora é uma aplicação que roda e é distribuída diretamente no Docker/Kubernetes (como um pod).
Neste exemplo de ambiente aqui do post, está publicada a url:
http://kubernetes.default.svc.cluster.local/magicmonitor
e acessando-a, teremos então acesso ao (novo e remodelado) Magic xpi Monitor:
Para finalizarmos, aqui tem um PDF oficial do produto que aborda também (em outro formato) este novo ambiente de instalação.
Fique ligado no Blog MagicBR, para mais dicas.
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui