Aplicativos em nuvem continuam a ficar mais complexos, dificultando a tarefa de fornecer rapidamente uma solução em nuvem, — um aplicativo de nível de produção exclusivo, um aplicativo dentro de um pacote de implementação juntamente com o sistema operacional ou mesmo um padrão de aplicativo virtual intrincado (um componente de nuvem/serviço de middleware e uma política para fins de configuração) ou padrão de sistema virtual (uma ou mais imagens e aplicativos virtuais que implementem uma topologia de implementação)— .
Para enfrentar esse desafio e examinar essa complexidade, este artigo demonstra como estabelecer um sistema Collaborative Lifecycle Management funcional e facilmente repetido que seja executado em um WebSphere Application Server usando o DB2 como banco de dados. O IBM Workload Deployer e o recurso CLM do Rational® Team Concert são usados. O resultado final é uma topologia que os testadores podem reproduzir em um desenvolvimento diário e instantâneo para verificar defeitos e construções, executar testes rápidos e ativar outras atividades de teste.
O IBM Workload Deployer (IWD) é um dispositivo de hardware que fornece aos usuários um ambiente no qual eles podem implementar padrões repetidos (ou soluções repetidas) de middleware em uma nuvem privada.
O problema inicial apresentado à equipe envolvia como superar os desafios da complexidade de estabelecer um sistema de CLM funcional que fosse executado no WebSphere utilizando o DB2 como fornecedor de banco de dados de uma maneira que economizasse tempo repetidamente. Os parâmetros do problema incluíam:
- Os testadores precisam conseguir reproduzir essa topologia com desenvolvimentos diários instantâneos para verificação de defeitos, verificação de construção, testes rápidos (uma visão não granular de se um sistema inteiro funciona de uma maneira geral), etc.
- O testador médio gastava aproximadamente de 3 a 5 dias instalando e configurando um sistema de teste antes que os cenários de teste pudessem ser executados.
Para mudar essa cultura, o IWD e as funções de automação integradas (como scripts bash e Python e WSAdmin) foram usados por meio do desenvolvimento de pacotes de scripts IWD para oferecer uma solução repetida. Isso tomou 60 minutos da equipe usando as seguintes etapas.
A topologia padrão da solução neste artigo utiliza uma imagem virtual do Red Hat Enterprise Linux ® WebSphere 8.0.0.1 Network Deployment de 64 bits simples de instalar (imagem virtual pré-instalada com o WebSphere ND versão 8.0.0.1 e o IBM Installation Manager 1.4.4) e, com pacotes de scripts incluídos, ela instala, configura e implementa o CLM na imagem virtual juntamente com uma imagem virtual RHEL DB2 V9.7.4 de 64 bits simples de instalar. A Figura 1 ilustra a topologia do CLM para a qual o IWD VSP mapeia, uma representação visual do VSP discutida por este artigo.
Figura 1. A topologia do CLM para a qual o IWD VSP mapeia
Nesse caso, o CLM está sendo executado em um servidor WebSphere V8.0.0.1 com os dados do CLM sendo hospedados em um servidor DB2 V9.7.4.
Um dos grandes ativos do IWD é a sua capacidade de estabelecer o relacionamento entre as diferentes imagens virtuais no padrão. O relacionamento existente (mostrado pela seta entre as partes do sistema virtual) permite que a comunicação aberta entre os dados do CLM e o próprio aplicativo, resultando assim em um ambiente muito mais amigável ao desenvolvedor para designs com diversos servidores. A Figura 2 ilustra o relacionamento estabelecido pelo IWD.
Figura 2. O relacionamento estabelecido pelo IWD
A seta mostra que o servidor WebSphere 8.0.0.1 reconhece o servidor DB2 9.7.4. Assim, a comunicação entre os dois servidores não é uma batalha complicada que o usuário tem de travar (abrindo caminho entre firewalls, proxies, etc.).
Depois que a base da solução estiver estabelecida, as próximas etapas são preparar o servidor WebSphere e o servidor DB2 para a implementação do aplicativo CLM.
Etapa 2: Crie bancos de dados (JTS, CCM, QM, DW)
Desenvolvemos um pacote de scripts composto de um script bash Linux para chamar o db2admin (comando do servidor de administração do DB2) para criar silenciosamente os bancos de dados exigidos pelo CLM para cada um dos aplicativos.
O script bash pai:
#!/bin/sh su - db2inst1 -c "sh /tmp/createDatabases.sh" |
O script bash filho:
#!/bin/sh db2 CREATE DATABASE jtsDB AUTOMATIC STORAGE YES ON '/db2fs' DBPATH ON '/db2fs' USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM PAGESIZE 16384 |
Etapa 3: Atualize o Installation Manager pré-instalado para a versão 1.5.2
O CLM 4.0 tem uma dependência do Installation Manager; ele precisa da versão 1.5.2. Atualizamos a versão simples de instalar usando um arquivo de resposta do Installation Manager encapado em um pacote de scripts do IWD.
O script bash de amostra:
echo "Enter IM Directory" cd /opt/IBM/InstallationManager/eclipse echo "Launching IM 1.5.2 Update" ./IBMIM --launcher.ini silent-install.ini -input $IMFilePath/imUpdate152.xml -keyring $IMFilePath/im.keyring -accessRights admin -acceptLicense |
O modelo do arquivo de resposta de atualização do IM de amostra:
<?xml version="1.0"?> <agent-input clean="true" temporary="true"> <server> <repository location="<IM repository>"/> </server> <install> <offering features="agent_core,agent_jre" id="com.ibm.cic.agent" version="<IM BUILD Version>"/> </install> <profile id="IBM Installation Manager" installLocation="/opt/IBM/InstallationManager" kind="self"><data key="eclipseLocation" value="/opt/IBM/InstallationManager"/> </profile> </agent-input> |
Etapa 4: Instale o CLM em um servidor WebSphere
A próxima etapa é inserir os bits do CLM no WebSphere Application Server. Nesse cenário, os usuários precisam da capacidade de obter desenvolvimentos específicos do CLM. Levando isso em consideração, a equipe usou os IDs de Desenvolvimento como um parâmetro de especificação no pacote de scripts para a instalação do CLM.
No tempo de fornecimento, o ID de Desenvolvimento é solicitado ao usuário, que é substabelecido nos arquivos de resposta gerados do Installation Manager usando comandos bash.
O script bash de chamada:
#!/bin/sh . /etc/virtualimage.properties echo "CLM Build to be installed: "$CLM_BUILD_ID echo "Substitute CLM Build ID" sed -i s%CLM_BUILD_ID_1%$CLM_BUILD_ID% /tmp/CLM/CLM.xml sed -i s%CLM_BUILD_ID_2%$CLM_BUILD_ID% /tmp/CLM/CLM.xml echo "Install CLM 4.x via Installation Manager" cd /opt/IBM/InstallationManager/eclipse ./IBMIM --launcher.ini silent-install.ini -input /tmp/CLM/CLM.xml -keyring /tmp/CLM/im.keyring -acceptLicense -accessRights admin Sair |
Etapa 5: Configure o WebSphere Server/Implemente os aplicativos CLM
A etapa final da solução padrão é configurar o WebSphere com as configurações apropriadas exigidas antes que os arquivos WAR do CLM possam ser implementados no servidor.
A fim de permitir a configuração do servidor WebSphere para nossas necessidades, a equipe criou um script Python que chama o AdminTask :
print "-------Set Run as User to Root------"
#Set Run as Root
AdminConfig.modify('(cells/CloudBurstCell_1/nodes/CloudBurstNode_1/servers/
server1|server.xml#ProcessExecution_1183122130078)', '[[runAsUser "root"]
[runAsGroup ""] [runInProcessGroup "0"] [processPriority "20"] [umask "022"]]')
print "-------Save Master Configuration-------"
#Save to Master Config
AdminConfig.save()
|
Após configurar o WebSphere, temos de configurar os arquivos teamserver.properties, criar tabelas de banco de dados e implementar os arquivos WAR do CLM no servidor.
A equipe incluiu os modelos teamserver.properties no pacote de scripts de configuração. Os modelos são preenchidos com os nomes do host e as sequências de banco de dados corretos usando substabelecimentos de sequência bash.
Após os substabelecimentos da sequência, os arquivos teamserver.properties para cada aplicativo são substituídos pelo modelo customizado.
A partir desse ponto, é apenas uma questão de usar as ferramentas fornecidas pela instalação do CLM. A instalação do CLM fornece um conjunto de ferramentas de repositório (repotools) que podem ser usadas para criar as tabelas nos bancos de dados preexistentes, removendo assim outra etapa do usuário durante o assistente de configuração do Jazz Team Server (JTS).
Exemplo de repotool:
echo "------Run Repo Tools for JTS Tables------" cd /opt/IBM/JazzTeamServer/server ./repotools-jts.sh -createTables teamserver.properties= "/opt/IBM/JazzTeamServer/server/conf/jts/teamserver.properties" logFile=repotools.log |
Finalmente, implementamos os arquivos WAR do aplicativo no servidor WebSphere usando um script Python. O script é passado para o programa WebSphere Admin (wsadmin.sh) e a partir dali ele é chamado para executar a implementação do aplicativo.
O scrip Python de amostra para implementação do aplicativo:
def deployJazzApp(app_name):
print "====== installing " + app_name + " Web Application on WAS ======\n"
app_war= app_name + '.war'
installed_appname = app_name + '_war'
app_ctx = '/' + app_name
appfile = properties.getProperty("CLM_HOME") + "/server/webapps/" + app_war
installcmd = ""
AdminApp.install(appfile, installcmd)
AdminConfig.save()
print "====== application " + app_name + " is installed on WAS =========\n"
print "====== Install completed. Please restart your WAS server.============\n"
|
Após a implementação do aplicativo, o servidor WebSphere é reiniciado e os usuários estão prontos para percorrer o assistente de configuração do JTS e registrar qualquer um dos aplicativos CLM que desejarem. A Figura 3 mostra com o que o padrão se parece no final do processo.
Figura 3. Visualização do padrão final
A equipe desenvolveu esse padrão para fornecer aos testadores a capacidade de implementar rapidamente uma topologia CLM/WebSphere/DB2 a qualquer momento com o recurso flexível adicional de conseguir selecionar desenvolvimentos específicos. Porém, o design provou ser mais útil que nossas intenções originais. É uma tecnologia que pode ser utilizada por qualquer engenheiro de software do Rational e os tipos de pessoas que a usam vão além dos testadores de verificação, incluindo:
- Testadores de verificação funcional que testam as entradas de código mais recentes.
- Testadores de verificação de desenvolvimento que verificam se os desenvolvimentos diários estão estáveis.
- Desenvolvedores que criam produtos que testam integrações com o CLM.
A solução padrão do CLM é uma pequena amostra do que o IWD pode fornecer e é também uma exibição de como a qualidade do software pode ser aumentada a partir da inovação em todos os níveis do processo de desenvolvimento. Ao implementar a solução no Rational, a equipe conseguiu fornecer aos usuários a capacidade de realocar o precioso recurso de tempo, o tempo gasto configurando e definindo o CLM; a maior parte desse tempo pode ser gasta desenvolvendo e testando.
O IWD permitiu a dissolução da complexidade do sistema de teste em simplicidade.
Aprender
-
Para saber mais sobre como realizar tarefas na nuvem IBM, visite estes recursos:
- Faça upload e download de arquivos a partir de uma instância do Windows.
- Instale o servidor da web IIS no Windows 2008 R2.
- Crie uma instância da nuvem IBM com a linha de comando do Linux.
- Crie uma instância da nuvem IBM com a linha de comando do Windows.
- Estenda a sua rede corporativa com a nuvem IBM.
- Aplicativos de alta disponibilidade na nuvem IBM.
- Parametrize imagens de nuvem para instâncias customizadas dinamicamente.
- Abordagens focadas no Windows para fornecimento na Nuvem IBM.
- Implemente produtos usando o serviço de implementação rápida.
- Integre sua política de autenticação usando um proxy.
- Configure o Linux Logical Volume Manager.
- Implemente uma topologia complexa usando uma ferramenta de utilitário de implementação.
- Forneça e configure uma instância que envolva uma VLAN pública e privada.
- Proteja o acesso à Nuvem IBM para dispositivos Android.
- Recupere dados no IBM SmartCloud Enterprise.
- Proteja instâncias de máquina virtual na nuvem.
-
Nos recursos para desenvolvedores de nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo seus projetos de implementação de nuvem.
-
Descubra como acessar o IBM SmartCloud Enterprise.
Obter produtos e tecnologias
-
Consulte as imagens do produto disponíveis para o IBM SmartCloud Enterprise.
Discutir
-
Participe de um grupo de computação em nuvem no developerWorks.
-
Leia todos os ótimos blogs sobre nuvem no developerWorks.
-
Participe da comunidade do developerWorks, uma rede profissional e conjunto unificado de ferramentas comunitárias para conectar, compartilhar e colaborar.
Herrin começou a trabalhar para a IBM como estagiário enquanto concluía seu curso de graduação em Ciências da Computação na Universidade do Estado da Carolina do Norte, nos Estados Unidos. Iniciou sua carreira com a equipe de teste do Rational Application Developer (RAD), com foco nas ferramentas da web JSF e JPA. Enquanto trabalhava com a equipe do RAD, Herrin teve a chance de desenvolver uma automação de instalação/configuração altamente ágil usando o Rational Build Forge; essa oportunidade abriu a porta para uma mudança para a Equipe de Automação do Núcleo Rational, na qual seu foco atual é o aproveitamento de tecnologias de nuvem com automação integrada. Herrin tem um sólido conhecimento em teste de produtos, computação em nuvem, ferramentas de fornecimento rápido, automação e Linux. O uso da nuvem com automação é a sua verdadeira paixão de software e é uma tecnologia que ele sente que revolucionará a maneira como testamos os produtos do futuro.