Diminua o tempo dos builds com Maven Daemon

Desde sua versão inicial, em 13 de julho de 2004, o Apache Maven promoveu uma revolução na forma como projetos Java são desenvolvidos. Esse projeto, que começou com um subprojeto do Apache Turbine em 2002, modernizou a forma como o projetos gerenciavam as dependências em Java (entre muitas outras inovações, na verdade). Até então, as estratégias mais comum para construir projetos em Java eram baseados no Apache Ant, Makefiles ou Shell Scripts.

Após todos esses anos o Maven continua sendo uma ferramenta poderosa e popular. Entretanto, tendo sido inicialmente desenvolvido em uma época que as CPUs mais comuns eram Pentium 4 e semelhantes, ou até mesmo, com as Intel Core 2 Duo, populares por volta de 2010 quando a atual série 3.x do Maven foi lançada, o Maven mostra algumas limitações em utilizar todo o poder de processamento em paralelo das CPUs da atualidade.

Embora o Maven tenha suporte a paralelização do processo de build, esse processo é bastante rudimentar e não costuma ser muito confiável ou estável. Com os projetos atuais se tornando cada vez maiores e mais complexos, utilizar todo o poder de processamento disponível para diminuir o tempo de build se tornou cada vez mais urgente.

Pensando nisso, um grupo de programadores da comunidade open source resolveu utilizar o técnicas utilizadas em outros sistemas de build, como o Gradle, para melhorar a capacidade do Maven em utilizar esse poder de processamento disponível, otimizar a utilização de recursos e diminuir o tempo de build dos projetos.

O resultado desse trabalho é o Maven Daemon (também conhecido como mvnd). Esse projeto, desenvolvido em cima do próprio Maven, utiliza as seguintes técnicas para aumentar o desempenho do Maven:

  • Usa um daemon, mantido em memória para rodar os builds, evitando múltiplas execuções da JVM.
  • Utiliza um cliente nativo, construído com a GraalVM, para uma inicialização quase imediata.
  • Cache de classes dos plugins do Maven, reutilizado entre múltiplos builds.
  • Utilização de builds em paralelo por padrão, fazendo melhor uso do poder de processamento disponível no sistema.

Todo esse trabalho de otimização resulta numa considerável diminuição do tempo de build. Usando, por exemplo, um dos projetos que contribuo com frequência, esse tempo cai de 32 minutos e 51 segundos com o Maven para 7 minutos e 16 segundos com o mvnd.

Em comparação com um build feito com o mvnd, o build Maven padrão fica parecendo uma lesma com preguiça numa segunda-feira de manhã 🐌:

O processo de instalação do mvnd é bastante simples e não difere muito do que já ocorre com o Maven. Basta extrair os arquivos de instalação de exportar o diretório bin para o PATH. Usuários do igualmente fantástico SDKMAN! podem instalá-lo ainda mais facilmente usando o seguinte comando:

sdk install mvnd 0.0.9

Para rodar os builds com o mvnd, basta utilizar o comando mvnd ao invés do tradicional mvn. Todas as opções do Maven são completamente aceitas e compatíveis e não é necessário fazer nada mais.

Por fim, é possível que alguns builds apresentem problemas ao rodarem em paralelo. Isso geralmente é causado por plugins desatualizados ou, infelizmente, incompatíveis. Nesse caso, a recomendação é atualizar ou desabilitar o plugin mal comportado.

Pacotes do OpenPHT para o Fedora

Eu empacotei o OpenPHT, um fork do Plex Home Theater mantido pela comunidade. O Plex Home Theater faz parte de um conjunto de aplicações para “media centers” e roda em diversos sistemas operacionais.

Os pacotes podem ser baixados desse link (no futuro espero contribuir o spec do pacote para o projeto upstream mas, antes disso, pretendo garantir que eles estão plenamente funcionais).

Para os interessados, as instruções de compilação podem ser encontradas nesse gist ou então, na especificação do arquivo RPM que está disponível neste link.

Atualizando o hostname de um Foreman Proxy

Recentemente tive que reconfigurar um dos meus proxies Foreman (cuja instalação e configuração em conjunto com a libvirt eu detalhei nesse post aqui) para que ele passasse a usar um hostname diferente do que eu tinha originalmente configurado. A princípio, essa era uma alteração, acredito eu, deveria ser possível fazer somente através do foreman-installer. Infelizmente não parece ser o caso, já que o instalador parece não atualizar todas as referências ao hostname antigo. Como não encontrei nada na documentação que explicasse isso, compartilho aqui os passos que usei para fazer a alteração na marra. Considerando que o hostname anterior do servidor não está mais disponível e o servidor já encontra-se devidamente configurado com o novo hostname, os passos para reconfigura-lo são os seguintes:

1. Gerar o novo certificado puppet para o servidor:

puppet cert generate <novo fqdn>

2. Editar o arquivo answers, localizado em /etc/foreman-installer/scenarios.d/foreman-answers.yaml, alterando todas as ocorrências do hostname anterior para o novo hostname. E, sim, isso inclui alterar as configurações de certificados para que elas apontem para novo certificado (ex.: websockets_ssl_key, websockets_ssl_cert, puppet_ssl_key, etc).

3. Rodar novamente o instalador do proxy:

foreman-installer \
     --no-enable-foreman \
     --no-enable-foreman-cli \
     --no-enable-puppet \
     --enable-foreman-compute-libvirt \
     --enable-foreman-proxy \
     --foreman-proxy-dns=true \
     --foreman-proxy-dns-provider=virsh \
     --foreman-proxy-dns-interface=virbr0 \
     --foreman-proxy-dhcp=true \
     --foreman-proxy-dhcp-managed=false \
     --foreman-proxy-dhcp-interface=virbr0 \
     --foreman-proxy-dhcp-vendor=virsh \
     --foreman-proxy-dhcp-gateway=192.168.122.1 \
     --foreman-proxy-dhcp-range="192.168.122.2 192.168.122.254" \
     --foreman-proxy-dhcp-nameservers="192.168.122.1" \
     --foreman-proxy-tftp=true \
     --foreman-proxy-tftp-servername=<endereço IP do servidor TFTP> \
     --foreman-proxy-foreman-base-url=<url do servidor Foreman usando o novo FQDN> \
     --foreman-proxy-trusted-hosts=<hostname do servidor Foreman> \
     --foreman-proxy-oauth-consumer-key=<oauth consumer key> \
     --foreman-proxy-oauth-consumer-secret=<oauth consumer key>

Obs.: não esqueça de ajustar o comando do instalador de acordo com o seu ambiente, as funcionalidades gerenciadas pelo foreman e qualquer outra configuração do seu ambiente. O comando acima deve ser utilizado como um exemplo.

4. Revogar os certificados antigos:

puppet cert revoke <fqdn antigo>

E pronto. Depois feito isso, o proxy deve passar a usar o novo hostname.

Configurando o Foreman para Provisionamento com a Libvirt

Introdução

O objetivo desse artigo é fornecer um guia rápido de como configurar o Foreman para que ele possa provisionar máquinas virtuais usando as funcionalidades fornecidas pela libvirt. Ele fornece um material adicional de apoio à excelente documentação fornecida pelo projeto. Esse guia foi feito levando em conta um ambiente com Red Hat Enterprise Linux 6.7 ou 7.2, devendo funcionar sem maiores problemas em ambientes baseados em CentOS 6 ou 7.

Sobre o Foreman

O Foreman é uma ferramenta que permite gerenciar o ciclo de vida de servidores físicos ou virtuais, facilitando o provisionamento de sistemas e aplicações, automação de tarefas e, de modo geral, facilitando o gerenciamento de servidores. Entre outras coisas, ele permite a instalação desassistida de máquinas virtuais e o seu provisionamento em “Compute Resources” como OpenStack, Amazon EC2 e libvirt. Para ter uma ideia de como ele funciona, recomendo esse vídeo:

Continue reading “Configurando o Foreman para Provisionamento com a Libvirt”

Ebook: Integração de Sistemas com Apache Camel

Eu escrevi um mini-livro que descreve os conceitos básicos do Apache Camel e padrões de integração. Dois exemplos de integração de sistemas acompanha o conteúdo do livro: o primeiro deles contém uma implementação básica de um sistema back-end usando Active MQ e Apache Camel e o segundo contém uma implementação simples de um broker usando Apache Camel.

O livro pode ser baixado, em PDF, aqui. Os exemplos estão disponíveis no meu GitHub ou aqui.