Nível: Avançado W. David Ashley, Senior IT Specialist, IBM
14/Jul/2009 Construa um serviço de compilação de software on-demand usando ooRexx que usa a Linux® Kernel Virtual Machine (KVM) para melhor desempenho. KVM age como o host para os sistemas operacionais guest que compilam o software de destino para o usuário. O servidor da Web Apache controla as compilações e armazena os resultados para recuperação posterior pelo usuário. Aprenda como configurar o servidor de compilação e criar guests, customizar pedidos de compilação e organizar e acessar resultados de compilação.
Recentemente, o projeto Open Object Rexx (ooRexx; consulte
Recursos posteriormente neste artigo para obter informações adicionais) converteu seu sistema de compilação de software on-demand antigo de sistemas operacionais guest hospedados por VMware em guests hospedados pela
Linux Kernel Virtual Machine (KVM).
Essa mudança forneceu um ambiente de compilação mais eficiente e reduziu o tempo de compilação para usuários.
O sistema de compilação de software ooRexx permite que desenvolvedores construam pacotes de software ooRexx para diversas plataformas e sistemas operacionais baseados em x86.
Atualmente, os sistemas operacionais guest suportados incluem o Windows® XP
(i386), o Fedora 10 (i386 e x86_64) e o Ubuntu 8.04 (i386). Esses sistemas operacionais guest podem produzir pacotes de instalação e documentação ooRexx para Windows (EXE), Fedora e openSUSE (RPM) e Ubuntu (DEB).
Outros sistemas operacionais baseados em x86 serão colocados on-line conforme demanda de desenvolvedores e usuários do ooRexx.
Este artigo mostra como criar seu próprio sistema de compilação de software, usando a configuração da equipe de desenvolvimento do ooRexx como um exemplo e incluindo dicas e instruções, conforme necessário para desenvolvedores experientes com ooRexx, Apache e Linux. É possível fazer
download dos scripts do servidor e do guest
no final deste artigo.
Conforme projetado, o sistema é especificamente para construir o software ooRexx, mas os conceitos podem ser aplicados para um sistema de compilação de propósito geral para qualquer software.
Os requisitos amplos para esse sistema incluem o seguinte:
- É necessário ter uma interface da Web para gerar o pedido de compilação.
- É necessário ter uma interface da Web para recuperar os resultados da compilação.
- É necessário ter suporte para diversos sistemas operacionais guest.
- Os sistemas operacionais guest devem executar compilações integralmente automatizadas.
- Um e-mail deve ser gerado e enviado ao usuário solicitante no final da compilação.
Para acomodar esses requisitos, a equipe de desenvolvimento e eu usamos um servidor baseado no Xeon quad-core. O servidor contém 4 GB de memória e 250 GB de espaço em disco.
Escolhemos a distribuição Fedora 10 x86_64 como o sistema operacional principal devido, principalmente, à estabilidade e ao release atualizado da KVM usado pela distribuição.
Sua opção de hardware e software pode ser diferente, mas o principal critério de hardware é que seu processador deve ter virtualização de hardware disponível
—é uma exigência para usar
KVM.
Configurar o Servidor
A primeira etapa na configuração do servidor de compilação é determinar o esquema de particionamento.
Decidimos segregar o armazenamento da Web e as imagens para os sistemas operacionais guest em partições separadas.
Separamos 50 GB para o armazenamento na Web e, aproximadamente, 150 GB para a partição /var onde as imagens guest são colocadas.
O restantes foi dividido entre a partição /home e a partição /root.
 |
Requisitos Gerais de um Sistema de Compilação
Alguns dos requisitos mais básicos de um sistema de compilação incluem:
- Compilações frequentes para captar problemas o quanto antes
- Compilações mais rápidas (quanto mais rápidas forem, mais é possível fazer)
- Processamento de compilação incremental (ou evitar construir do zero) para refletir
pequenas atualizações de desenvolvimento
- Suporte para gerenciar as dependências do código de origem (pelo menos o nível inferior) para manter seu sistema o mais flexível possível
- Recursos de extração/relatório em uso de construção, compilação e link
- Um sistema de relatório que pode rastrear código fonte para correspondência binária (comparando de forma eficiente o antigo e o novo)
- A capacidade de relatar sobre status da compilação e coisas como aprovação ou reprovação em testes
- A capacidade de criar notas sobre e release e documentação do sistema
|
|
Em seguida, instalamos o sistema operacional principal usando a distribuição de release Fedora 10 x86_64.
Se estiver configurando seu próprio sistema, evitará muitos problemas se fizer o seguinte:
- Ative a virtualização de hardware através do BIOS da máquina antes de iniciar a instalação para que Fedora veja que KVM está disponível.
- Execute uma instalação customizada dos componentes de software para que possa selecionar as opções de virtualização do Fedora.
Após termos instalado o sistema operacional do servidor, configuramos o mesmo para acesso pelos sistemas operacionais guest.
Isso envolveu ativar Samba para os guests Windows e NFS para os guests Linux. Isso fornece aos guests acesso à partição de resultados da compilação para que possam armazenar seus arquivos de compilação para acesso pelo usuário.
O compartilhamento Samba principal e a exportação NFS principal apontam para o mesmo local para todos os guests.
Em seguida, configuramos o servidor da Web Apache para fornecer acesso ao sistema de pedido de compilação, que discuto sob
Os Pedidos de Compilação e o repositório de resultados de compilação.
Uma decisão de configuração que precisará ser tomada refere-se à opção de rede para os guests. A instalação padrão é configurada para fornecer uma rede interna privada para todos os guests.
Uma rede classe C é fornecida juntamente com um servidor DHCP para fornecer endereços IP aos guests.
A outra opção é configurar o sistema para que um dos dispositivos de rede aja como uma ponte para a rede externa do servidor.
Isso precisará ser configurado à mão.
É possível ver um exemplo de como configurar seu servidor para essa opção no Wiki
libvirt (consulte Recursos para um
link).
Criar os Guests
Há duas abordagens para criar guests para uso por KVM. Na primeira abordagem, cria-se somente os guests necessários para atender seus requisitos.
A segunda maneira é uma abordagem mais longa para a criação de guests. Esse é o método usado para criar guests e recomendamos o mesmo como uma abordagem padrão se os recursos necessários estiverem disponíveis.
Primeiro determinados o número e os tipos de guests dos requisitos.
Precisávamos de sistemas operacionais para criar compilação de software para esses ambientes e outro sistema operacional para criar a documentação.
No final, em nosso caso, as tarefas de documentação e i386 RPM poderiam ser combinadas e tratadas por um único guest.
Seguem os guests e tarefas designados a elas:
- Windows XP (i386): Compilar o executável de instalação do Windows.
- Fedora 10 (i386): Compilar o arquivo i386 RPM e o arquivo ZIP da documentação.
- Fedora 10 (x86_64): Compilar o arquivo x86_64 RPM.
- Ubuntu 8.04 (i386): Compilar o arquivo DEB.
A abordagem usada para criar os guests anteriormente mencionados como imagens que poderiam ser clonadas posteriormente.
Portanto, cada guest tinha uma versão básica que mantivemos para clonagem posterior e um clone customizado desse guest que executou a tarefa de compilação real.
Clonar um guest KVM é realmente fácil. O script
virt-clone fornecido pelo Fedora 10 pode automatizar completamente a tarefa.
Lista 1. Script virt-clone do Fedora 10
$ virt-clone --original=Fedora10-i386-Base \
--name=Fedora10-i386-Build \
--file=/var/lib/libvirt/images/Fedora10-i386-Build.img
|
A opção original especifica o nome do sistema operacional guest como é conhecido para o gerenciador da máquina virtual. A opção
name especifica o nome do novo guest.
A opção file especifica o nome do arquivo do novo arquivo de imagem para o guest.
Isso irá clonar completamente um guest existente e copiá-lo para uma nova versão do guest.
Também irá modificar o endereço MAC do novo guest, assim como o UUID. Assim, o guest original é preservado para clonagem adicional, se necessário, e um novo guest é fornecido para sua customização.
Uma coisa sobre o script virt-clone deveria ser observada: se o guest original tiver um dispositivo desconectado, como um CD-ROM, o script falhará.
Todos os dispositivos desconectados devem ser removidos antes da clonagem do guest.
Se necessário, é possível incluí-los novamente após a operação de clonagem.
Quando os guests de compilação básicos foram criados, cada um foi,então, customizado para a tarefa de compilação.
O guest o Windows XP foi o mais desafiador nessa área, pois o compilador
Visual C++ e o Software Development Kit precisavam ser instalados como parte da customização.
Os guests do Linux praticamente não precisaram de nenhuma customização, exceto a instalação do NFS no guest do Ubuntu.
Os Pedidos de Compilação
Todos os guests de compilação requerem uma customização adicional: o Open Object Rexx
versão 3.2 deve ser instalado em cada um deles. Por quê? Porque um script gravado em ooRexx controla o processo de pedido e compilação em cada guest.
O script acessa uma porta TCP/IP em um servidor da máquina de compilação para procurar pedidos de compilação.
Se um pedido for localizado, o processo de compilação é chamado e um conjunto de arquivos de instalação (RPM, DEB, EXE), juntamente com um relatório de compilação, é criado e armazenado no servidor da máquina de compilação para acesso através de HTTP pelo usuário.
O script de pedido de compilação ooRexx é inteligente o suficiente para não duplicar uma versão do software já compilada.
Também notifica o usuário por e-mail que a compilação está concluída e fornece uma URL para o local no servidor da máquina de compilação onde a compilação foi armazenada.
Pedidos de compilação são gerados através de um script CGI no servidor da máquina de compilação.
O usuário visita uma página da Web HTTP e solicita uma compilação em sua opção de sistema operacional.
O servidor Apache chama então o script CGI, que coloca o pedido em uma fila.
Os guests de compilação são então responsáveis por acessar esses pedidos e executar a operação solicitada.
Os resultados da compilação também estão disponíveis através do Web site para download.
Conforme mencionado acima, o código para o servidor e para os clientes guests de compilação está disponível para
download abaixo. Todos os scripts são gravados em ooRexx e devem ser fáceis de acompanhar.
Os arquivos a seguir são incluídos:
- buildserver.rex: Esse script é executado no servidor da Web e mantém as filas que os sistemas operacionais guest usam para procurar trabalho.
- buildd.rex: Esse script é executado em cada sistema operacional guest e acessa as filas no servidor da Web procurando trabalho.
Cada guest possui somente uma fila pela qual é responsável e, assim, compilará somente um tipo de arquivo de saída.
- simq.cls: Esse arquivo não é um script, mas é um arquivo de classe usado pelo script buildserver.rex.
- socket.cls: Esse arquivo de classe é usado pelo script buildd.rex.
- streamsocket.cls: Esse arquivo de classe também é usado pelo script buildd.rex.
Os Resultados de Compilação
Os resultados de uma compilação são colocados no Web site pelos guests de compilação. As compilações são organizadas de forma que cada revisão de Subversão tem seu próprio subdiretório que contém todas as compilações de guests de plataformas para essa revisão.
Além disso, cada guest de plataforma produz um relatório de compilação que também é armazenado no subdiretório de revisão.
O relatório de compilação é uma necessidade absoluta para que tudo isso realmente funcione. Se ocorrer um erro durante a compilação e os arquivos de saída finais não forem produzidos, o usuário deve ter uma maneira para descobrir o que saiu errado.
Portanto, o processo de compilação em cada guest sempre produz um relatório de compilação e armazena-o no repositório de compilação.
O repositório de compilação separa as compilações de software ooRexx das compilações de documentações.
A compilação de documentação produz um grande número de arquivos de saída, assim, foi considerado conveniente separar essas compilações das compilações de software.
Atualmente, não há nenhum processo de limpeza de compilação. O projeto não produz saída suficiente para tornar isso necessário no momento.
Conclusão
Ao alternar de guests de compilação VMware para guests Linux KVM, os tempos de compilação para cada guest são reduzidos por até 50 por cento.
Isso significa que o ciclo de desenvolvimento para o ooRexx também foi reduzido.
A equipe de desenvolvimento do ooRexx é de longe o maior grupo de usuários da máquina de compilação, mas durante os ciclos alfa e beta dos releases principais, um grande número de usuários do ooRexx também usam o ambiente.
Isso permite que os usuários forneçam feedback em tempo para quaisquer correções de erros ou aprimoramentos feitos no
ooRexx.
Um dos guests de compilação mais usados é o compilador de documentação. Toda a documentação ooRexx é codificada em DocBook. Isso torna a documentação difícil de compilar em um sistema Windows sem alguma experiência com DocBook nesse ambiente.
Isso é um problema real para a maioria de seus desenvolvedores e usuários.
Ao fornecer um processo de compilação de documentação que todos possam acessar, asseguramos que desenvolvedores e usuários possam contribuir e manter a documentação.
Isso produziu documentação para o ooRexx que é muito melhor do que a maioria dos projetos de software livre, o que é motivo de orgulho de nossa equipe de desenvolvimento.
Download | Descrição | Nome | Tamanho | Método de download |
|---|
| Build server and guest scripts | buildserver.zip | 23KB | HTTP |
|---|
Recursos Aprender
Obter produtos e tecnologias
- SourceForge hospeda downloads do
Open Object Rexx
.
- A
família IBM REXX
inclui o Compiler and Library para REXX em zSeries, REXX para VSE e
REXX para CICS.
-
Com o
software de avaliação da IBM, disponível para download diretamente a partir do developerWorks, construa seu próximo projeto de desenvolvimento no Linux.
Discutir
-
Envolva-se com a
comunidade My developerWorks; com seu perfil pessoal e página inicial customizada, é possível padronizar o developerWorks para seus interesses e interagir com outros usuários do developerWorks.
Sobre o autor | | | David é um Especialista em TI sênior para os Serviços de Laboratório da IBM. Ele tem mais de 25 anos de experiência no desenvolvimento de software de TI. |
Avalie esta página
| 
