Ebook grátis: Camel Passo a Passo

Em 2014 eu escrevi um mini e-book sobre integração de sistemas com Apache Camel. Naquela época o Apache Camel encontrava-se por volta da sua versão 2.10.x. Desde então, graças a velocidade de inovação da comunidade Open Source, inúmeras mudanças e melhorias foram feitas no Apache Camel (que hoje está em sua versão 3.6 ou 3.4.4 na versão LTS). Além disso, ao longo dos anos o projeto Camel foi adicionando números subprojetos novos, como o Camel Quarkus, o Camel Kafka Connector e o Camel K.

Para atualizar o livro para as versões atuais do Camel e cobrir um pouco sobre os novos subprojetos eu resolvi fazer uma extensa atualização na edição passada. Essa nova atualização também conta com algumas atualizações de cenários de integração, dando maior enfoque nos projetos de integração da Apache como o Apache Kafka e o Apache Artemis (futura nova geração do Apache ActiveMQ).

Hoje eu resolvi liberar uma versão preliminar do ebook que, ressalto, está disponível completamente de graça e sem custo algum. Essa é uma versão preliminar que cobre, no momento, detalhes básicos sobre integração de sistemas com Camel e uma introdução sobre o Camel Quarkus (para integrações subatômicas e supersônicas com Java). O livro vêm com alguns exemplos comentados que dão uma noção básica do funcionamento e servem de acompanhamento para os trechos de código do ebook.

Como o livro ainda é uma versão preliminar, é bastante possível que contenha alguns erros e pequenas inconsistências. Neste caso, eu agradeceria comentários e correções que pudessem ajudar a melhorar o conteúdo do livro através do meu email pessoal (angusyoung@gmail.com).

Os livros estão disponíveis em formato PDF e epub em formato amigável para leitura em tablets (como o iPad) e podem ser baixados nos seguintes links:

Obs.: alguns leitores de epub podem exibir a formatação de código levemente diferente do esperado, mas sem implicar em qualquer perda de conteúdo.

Projetos interessantes pra acompanhar no universo Kafka

Recentemente um amigo me perguntou sobre alguns projetos interessantes no universo Kafka. E eu separei 3 projetos que eu acompanho, 1 dos quais eu contribuo, e que acho interessantes. É uma lista bem pessoal e nem de longe representa toda a riqueza do universo Kafka.

O Strimzi é um projeto que facilita o trabalho de rodar o Kafka em Kubernetes (k8s) e suas distribuições (OpenShift, GKS, k3s, etc). O Kafka é relativamente complicado para gerenciar e botar em produção, e ainda mais complicado de rodar dentro de Kubernetes. Esse projeto abstrai a maior parte da complexidade de manter um cluster Kafka rodando nesse tipo de ambiente.

O Camel Kafka Connector (disclaimer: eu contribuo com esse projeto) é um runtime do Apache Camel que envelopa todos os mais de 300 componentes do Camel e permite roda-los como conectores dentro de uma instância do Kafka Connect. O Kafka Connect é um componente do Kafka pra rodar programas que movem dados pra dentro ou pra fora do Kafka. Na maior parte das vezes você consegue fazer integrações pra dentro ou fora do Kafka sem precisar escrever uma linha de código sequer.

O Debezium é um projeto pra Change Data Capture (CDC) e que permite capturar as alterações que ocorrem e um banco de dados e publicá-las no Kafka. O Debezium usa a API do Kafka Connect para rodar seus “source connectors”.

Criando um switch KVM por software

Nessa postagem mostrarei como fazer um KVM-switch para Linux usando apenas software e um pouco de hardware compatível.

Para começar você precisa dos seguintes dispositivos:

E dos seguintes softwares instalados: ddcutil e Solaar. A instalação deles no Fedora é bastante simples, já que eles estão nos repositórios oficiais do projeto:

sudo dnf install -y solaar ddcutil

Mouse e Teclado

É bem provável que você já tenha o Solaar instalado se você tem o teclado e o mouse da Logitech. De qualquer maneira, a documentação do projeto fornece os passos iniciais para configurar o Solaar, caso seja necessário.

Você pode inspecionar a configuração dos dispositivos usando o comando solaar show. Pessoalmente acho mais simples verificar na GUI do Solaar, já que ela também mostra quais os valores aceitáveis para o comando que usaremos adiante. A informação relevante para nós é a mostrada em “Change Host“. Ela mostra os nomes dos hosts com os quais seu dispositivo está pareado.

Usando as informações mostradas na UI, podemos usar a linha de comando para trocar o host ativo:

solaar config "MX Keys" change-host 1:mercury

Note que o nome do host tem que ser igual ao mostrado na UI e em alguns casos pode ser que somente o número do ID seja mostrado.

Repita o mesmo para o mouse, tomando cuidado de garantir que o ID utilizado é o ID do dispositivo, pois é possível que os eles sejam diferentes entre o mouse e o teclado (ex.: o host 1 do teclado é o host 2 do mouse, etc):

solaar config "MX Master 3" change-host 1:mercury

Monitor

Para controlar o monitor, usamos o programa ddcutil, que serve para interagir com o software do monitor através do conjunto de protocolos DDC-CI. Nesse link aqui, que serviu de referência pra implementar o controle do monitor, você encontra algumas dicas legais sobre o ddcutil.

O primeiro passo é detectar o monitor e ver quais as funcionalidades estão disponíveis:

sudo ddcutil detect

Em algumas distribuições pode ser necessário carregar o módulo i2c-dev. O Fedora já costuma fazer isso por padrão, então nenhum passo a mais é necessário. Se estiver usando outra distro, consulte a documentação.

Se executado com sucesso, o comando vai mostrar uma saída semelhante a esta aqui:

Display 1
I2C bus: /dev/i2c-2
EDID synopsis:
Mfg id: GSM
Model: LG Ultra HD
Serial number:
Manufacture year: 2017
EDID version: 1.3
VCP version: 2.1

Se você estiver usando um laptop, o comando também vai mostrar a informação do monitor embutido. Esse monitor embutido não é relevante para o KVM-switch virtual, portanto podemos ignorar as mensagens de erro referentes a ele.

A informação relevante mostrada pelo comando acima é o I2C bus. Mais especificamente, o número do bus (2, no caso de /dev/i2c-2). Tendo a informação do bus, podemos usa-la para descobrir as funcionalidades do monitor. Para o KVM-switch estamos interessados na funcionalidade “Input Source“. Podemos usar o seguinte comando para descobrir o ID da feature e os valores aceitáveis para configura-la.

sudo ddcutil capabilities --bus=2 | grep -A 5 "Input Source"

Feature: 60 (Input Source)
Values:
11: HDMI-1
12: HDMI-2
0f: DisplayPort-1
10: DisplayPort-2

Isso nos mostra que para mudar o dispositivo de entrada do monitor, podemos usar a feature ID 60 usando os valores (em hexadecimal) 0x11, 0x12, 0x0f e 0x10. Para testar, nesse caso:

sudo ddcutil --bus=2 setvcp 60 0x0f &

Executando esse comando já é possível trocar a entrada do monitor usando apenas a linha de comando.

Finalizando e Integrando no Gnome

Tendo em mãos os comandos para mudar o mouse, teclado e monitor. Podemos colocar tudo isso num script:

sudo ddcutil --bus=2 setvcp 60 0x0f &
solaar config "MX Keys" change-host 2
solaar config "MX Master 3" change-host 2

Repita o processo para outros hosts do seu KVM-switch virtual (ex.: micro 1, micro 2, etc). Não esqueça de dar permissão de execução nos scripts.

Por fim, podemos criar atalhos de teclado no Gnome para que execute esses scripts.

Como funciona?

No meu caso eu configurei os atalhos Ctrl+F2 para alternar para o laptop do trabalho e Ctrl+F3 para alternar para o laptop pessoal.

Obs.:

  • Imagino que funciona com qualquer teclado Logitech com suporte a múltiplos dispositivos (tipo o K810), mas eu não testei.
  • Assim como o teclado, acredito que deve funcionar com outros mouses com suporte a múltiplos dispositivos, tipo o Logitech M720 Triathlon.
  • É possível usar o ddcutil sem sudo e o artigo de referência mostra como fazer isso, porém fiz isso aqui.

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.

Distribuições Linux compatíveis com o padrão Unix

Estava acompanhando uma discussão sobre sistemas Unix no grupo de usuários Fedora Brasil e resolvi pesquisar, a título de curiosidade, se existiam e quais as distribuições Linux certificadas dentro da Especificação Única do Unix (Single Unix Specification – SUS).

Segundo o artigo da Wikipedia que fala a respeito da SUS, existem duas distribuições Linux certificadas como Unix 03:

Ambas são distribuição Linux da família “Red Hat”. O artigo não diz, exatamente, se é uma variante do Red Hat Enterprise Linux – RHEL, portanto cito-o exatamente como descrito no artigo.

Obs.: a versão em português do artigo da Especificação Única do Unix também cita uma distribuição chamada Linux-FT, mas não encontrei nada recente sobre essa distribuição. Esse artigo do Linux Journal de Agosto de 1996 fala um pouco sobre ela. Parece que a distribuição/produto (???) foi adquirida pela Caldera.

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.

Configuração do touchpad do Macbook no Fedora

Caso você esteja rodando Fedora em um Macbook e esteja descontente com o comportamento do touchpad, recomendo dar uma olhada nesse meu repositório Copr. Conforme eu expliquei nesse post em inglês, eu empacotei uma configuração do Synclient/Synaptics que deixa o comportamento do touchpad parecido com o do OS X.

A instalação é abusrdamente simples:

dnf copr enable orpiske/synconf
dnf install -y synconf

Basta reiniciar o sistema e o comportamento do touchpad deve ficar semelhante ao do OS X.

 

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”