A maioria dos projetos de migração começa com uma decisão: passar do Oracle Java SE para o OpenJDK, substituir uma distribuição Linux em fim de vida ou consolidar servidores numa cloud privada. No papel, o plano costuma parecer simples. Depois, a equipa do projeto descobre runtimes Java de que ninguém tinha conhecimento, servidores sem responsável e aplicações que dependem discretamente de uma versão antiga. Os prazos derrapam e os orçamentos aumentam.

A forma de evitar isto é começar pelo levantamento: um inventário completo e factual do que está efetivamente instalado. Este artigo explica o que recolher, como fazê-lo em Windows e Linux, que surpresas esperar e como transformar os resultados num plano de migração.

Porque é que o levantamento vem antes da migração

Uma migração só é tão boa quanto a informação em que se baseia. Sem inventário, está a estimar o âmbito com base na memória, em folhas de cálculo antigas e em registos de licenças, e nenhum deles reflete o que está realmente em execução hoje.

Um bom inventário dá-lhe três coisas:

• Âmbito: quantas máquinas, runtimes e aplicações são afetados, para poder estimar o esforço e o custo de forma realista.
• Risco: que sistemas executam versões sem suporte ou sem atualizações de segurança, e quais são críticos para o negócio.
• Responsabilidade: quem é responsável por cada sistema, para que os testes e a aprovação tenham um responsável claro.

Também o protege nas discussões sobre licenciamento. Se um fornecedor lhe perguntar quantas instalações tem, um inventário atualizado permite-lhe responder com factos em vez de suposições.

O que recolher: versões, fornecedores, caminhos e responsáveis

Para cada instalação de Java, recolha pelo menos o seguinte:

• Anfitrião: nome da máquina, endereço IP e se é um servidor, uma máquina virtual ou um PC de secretária.
• Versão: a string de versão completa, por exemplo 1.8.0_202 ou 17.0.10, e não apenas “Java 8” ou “Java 17”.
• Fornecedor: quem compilou o runtime, como a Oracle ou uma distribuição OpenJDK. A versão, por si só, não lhe diz isto.
• Tipo e caminho: se é um JDK completo ou apenas um JRE, e o diretório em que está instalado.
• Utilização: que aplicações ou serviços o utilizam, se for possível apurar.
• Responsável: a equipa ou pessoa responsável pela máquina ou aplicação.

Para os servidores Linux, recolha também a distribuição e a versão, a versão do kernel, os principais pacotes instalados e os serviços em execução. Isto indica-lhe que servidores fazem parte de uma migração de Linux, além de uma migração de Java.

Windows, Linux e PCs de secretária: abordagens diferentes

Cada ambiente exige um método ligeiramente diferente. Os comandos abaixo são pontos de partida; na prática, as equipas integram-nos num script e executam-no em todas as máquinas com as ferramentas de gestão que já utilizam.

Servidores Windows

Os runtimes Java instalados registam-se frequentemente na chave de registo do Windows HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, mas nem todos o fazem. Pesquisar o sistema de ficheiros é mais fiável:

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

Verifique todas as unidades, não apenas a C:, porque os servidores aplicacionais são muitas vezes instalados numa unidade de dados separada.

Servidores Linux

Em Linux, combine o gestor de pacotes com uma pesquisa de ficheiros, porque muitos runtimes Java são descompactados a partir de um arquivo em vez de serem instalados como pacote:

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

Em Debian ou Ubuntu, utilize dpkg -l | grep -i -E 'jdk|jre' em vez de rpm. Para cada binário java encontrado, executá-lo com -version mostra a versão e, normalmente, o fornecedor. A maioria dos diretórios do JDK contém também um ficheiro release que indica o implementador.

PCs de secretária

Os computadores de secretária são a parte do inventário mais frequentemente esquecida. Os programadores instalam os seus próprios JDK e algumas aplicações de negócio instalam um runtime Java sem aviso. Como existem muitos postos de trabalho, utilize sempre que possível o inventário de software da sua ferramenta de gestão de endpoints e execute um script ligeiro apenas onde essa informação estiver em falta.

Surpresas frequentes (JRE incluídos em aplicações, servidores esquecidos)

Quase todos os projetos de levantamento encontram coisas que ninguém esperava. As mais frequentes são:

• Runtimes incluídos: muitas aplicações comerciais trazem o seu próprio runtime Java privado dentro do diretório de instalação. Pode não aparecer no registo nem em nenhuma lista de pacotes.
• Várias versões na mesma máquina: os runtimes antigos raramente são removidos quando se instala um novo, pelo que um servidor pode ter três ou quatro.
• Servidores esquecidos: máquinas de teste, servidores batch antigos e máquinas virtuais que nunca foram desativados, muitas vezes com versões desatualizadas e sem atualizações de segurança.
• Responsáveis desconhecidos: máquinas que ninguém reivindica. Exigem uma decisão antes de a migração começar, mesmo que essa decisão seja desligá-las.

Do inventário ao plano de migração

Depois de recolhidos os dados, consolide-os num único local e reveja-os com os responsáveis pelos sistemas. Em seguida, agrupe as instalações por categorias:

Grupo	O que contém	O que fazer
Remover	Runtimes que já não são utilizados	Desinstalá-los já, para reduzir o risco e a exposição em termos de licenciamento
Substituir	Runtimes geridos internamente	Migrar para uma build OpenJDK com suporte, após testes
Coordenar	Runtimes incluídos em aplicações de terceiros	Obter primeiro a declaração de suporte do fornecedor da aplicação
Investigar	Tudo o que não tenha responsável ou finalidade clara	Identificar o responsável ou decidir desligar

A partir destes grupos, pode construir um calendário realista: comece pelos sistemas de baixo risco para validar o processo e passe depois aos sistemas críticos para o negócio, com um procedimento de reversão testado.

Como a LOGIQ pode ajudar

A LOGIQ realiza projetos de levantamento e migração para ambientes Java e Linux, com scripts e procedimentos aperfeiçoados em projetos reais de clientes em servidores Windows, servidores Linux e PCs de secretária. Se pretende ajuda para construir o seu inventário ou transformá-lo num plano de migração, contacte a LOGIQ.