Implemente Novos Aplicativos no IBM PureSystems com Plug-ins – Parte 02

Na Parte 01 desta série, os especialistas da equipe de laboratórios da Nuvem IBM descrevem os esforços de desenvolvimento para ativar o SugarCRM, um aplicativo fornecedor de software independente, no IBM PureSystems. O SugarCRM é um aplicativo PHP que requer a pilha LAMP (Linux, Apache, MySQL, PHP). LAMP não é suportado pelo IBM PureSystems simples de instalar, portanto, a equipe desenvolveu um novo tipo de padrão e um conjunto de plug-ins que oferecem suporte à modelagem, implementação e operação do aplicativo sobre a imagem base do Linux e IBM AIX. Este artigo aborda as lições aprendidas do projeto.

As lições aprendidas com o desenvolvimento de um plug-in para o aplicativo SugarCRM de terceiro existente abordam estes tópicos:

• Suportando várias plataformas;
• Gerenciando MySQL e DB2;
• Desenvolvendo scripts;
• Depurando plug-ins;
• Executando um script de ciclo de vida;
• Excluindo um plug-in não excluível;
• Importando plug-ins individuais versus plug-ins empacotados;
• Usando versões para acelerar o desenvolvimento;
• Manipulando binários grandes;
• Estendendo a imagem de base.

Suportando várias plataformas

Os plug-ins do IBM PureSystems são, por natureza, de plataforma neutra. Os desenvolvedores do plug-in devem desenvolver um plano de execução para suportar várias plataformas em diferentes fases dos ciclos de vida do plug-in e do aplicativo. Caso contrário, o desenvolvimento, a manutenção e a depuração em andamento podem se tornar muito difíceis rapidamente.

As seguintes áreas são especialmente importantes para o nosso projeto:

• Declarando suporte e requisitos da plataforma;
• Organizando arquivos e scripts para várias plataformas;
• Reunindo a entrada de ativação de plug-in para várias plataformas;
• Gravando scripts de plataforma neutra e específicos à plataforma;
• Gerenciando plataformas suportadas versus não suportadas.

Vamos ver as áreas mais detalhadamente.

Declarando suporte e requisitos da plataforma

O arquivo de configuração de plug-in, config.json, possui uma seção requer para cada instância de pacote. Se um plug-in suporta várias plataformas com o mesmo conjunto de arquivos, não é necessário declarar a plataforma.

Caso contrário, como em nosso caso, com grandes diferenças entre os arquivos e scripts do Linux e AIX, a cláusula arch deve ser usada, junto com outros atributos, como memória e CPU, para indicar que a definição de pacote está limitada a suportar uma plataforma específica. Como mostram os resultados, nosso pacote tem duas definições, cada uma com requisitos e partes do sistema independentes.

Organizando arquivos e scripts para várias plataformas

A estrutura de pasta no plug-in é altamente relacionada à definição de pacote. Para facilitar a manutenção, sempre considere o uso do mesmo conjunto de arquivos e scripts para várias plataformas. Escolhemos indicar claramente a plataforma em nossos nomes de diretório, conforme descrito na Parte 01, design e desenvolvimento.

Reunindo a entrada de ativação de plug-in para várias plataformas

A interface com o usuário de configuração de plug-in é definida no arquivo config_meta.json do plug-in. A abordagem declarativa facilita a construção da interface com o usuário e, ao mesmo tempo, é restrita em termos de flexibilidade para suportar várias plataformas, caso os requisitos sejam diferentes.

Com a lista de arquivos descrita na primeira parte deste artigo, Empacotamento da solução para o Linux e a mais longa para o AIX, decidimos utilizar genericamente uma entrada de um arquivo empacotado com todos os arquivos pré-requisitos compactados em uma estrutura de pasta predefinida para cada um de nossos plug-ins funcionais. Esse design permite que o administrador de nuvem colete apenas arquivos suficientes para a plataforma de destino, enquanto nossos plug-ins suportam o Linux e AIX.

Gravando scripts de plataforma neutra e específicos à plataforma

O princípio é gravar o mesmo conjunto de scripts para plataformas Linux e AIX onde quer que seja possível. Finalmente, gravamos dois conjuntos devido aos processos drasticamente diferentes para colocar o PHP em funcionamento.

Além disso, aprendemos a importância de conhecer as limitações da plataforma em termos de comandos e scripts. Por exemplo, no AIX, a primeira linha de um shell script deve ser #!/bin/sh ou #!/bin/ksh, em vez de #!/bin/bash, e gunzip seguido de tar deve ser usado, porque o comando tar não possui a opção-z.

Gerenciando uma plataforma suportada versus não suportada

Nossa plataforma inicial de destino para a implementação em nuvem é o System p; no entanto, devido a vários motivos de logística e planejamento, achamos necessário também oferecer suporte ao System x.

Um padrão de aplicativo virtual é independente da plataforma, portanto, a necessidade de oferecer suporte a várias plataformas não afeta o aspecto de modelagem, mas tem impacto sobre a implementação do plug-in, porque requer que ele forneça suporte integral para todas as plataformas.

No nosso caso, não foi possível cobrir totalmente a matriz de suporte devido ao nosso recurso limitado. Essa limitação expõe o risco de uma experiência do usuário inesperada quando um padrão falha ao ser implementado em uma plataforma não suportada. Nossa solução alternativa atual para essa situação é fornecer modelos com um nome associado à plataforma suportada, por exemplo, “SugarCRM com DB2 no AIX”. 

Gerenciando MySQL e DB2

Tecnicamente, o MySQL e o DB2 têm o mesmo propósito de um banco de dados de backend para aplicativos SugarCRM. Usamos os modelos Velocity semelhantes para modelagem e transformação, que reduziram nosso tempo de desenvolvimento. No entanto, o aspecto de propriedade do software teve um impacto importante na topologia e implementação suportadas em nossa solução. A IBM possui o DB2; portanto, desenvolvemos nossas soluções para integração com plug-ins do DB2 simples de instalar naturalmente, conforme descrito na Parte 01, Reutilize plug-ins existentes.

Contrariamente, aplicamos a abordagem fracamente acoplada para suportar o MySQL existente. 

Desenvolvendo o script

Ao instalar a pilha de software necessária pelo SugarCRM na imagem de base, constatamos que diversos pacotes (RPMs) não estão incluídos na imagem. Consequentemente, o plug-in precisa incluir e instalar esses RPMs ausentes.

Uma solução possível é fornecer um serviço durante a ativação que satisfaça automaticamente as dependências e instale os pacotes ausentes. A implementação do plug-in simplesmente lista os pacotes obrigatórios e não precisa manipulá-los.

Uma condição de erro encontrada envolvia uma condição de disputa entre duas funções (uma condição de disputa ocorre quando a saída ou resultado do processo é inesperada e criticamente dependente da sequência ou sincronização de outros eventos). É importante observar que os scripts de ciclo de vida de diferentes funções são chamados em paralelo; portanto, é necessário cuidado para evitar conflito quando os scripts gerenciam recursos compartilhados.

Em uma instância, descobrimos que um script de uma função estava interrompendo o Apache, enquanto um script da outra função estava iniciando o Apache. Isso levava a um comportamento inesperado quando o Apache não operava corretamente. É necessário identificar os serviços ou recursos compartilhados e desenvolver o código para gerenciá-los de forma correta.

Depurando plug-ins

Ao desenvolver os shell scripts, achamos que demorou muito passar pelo ciclo de editar o script no Eclipse, desenvolver o plug-in, excluí-lo no IBM PureSystems e, em seguida, reimplementá-lo. Além disso, a VM e os padrões que utilizam o plug-in precisavam ser excluídos e recriados.

Na prática, aproveitamos o suporte de depuração no PDK para expedir o desenvolvimento do script. Isso foi feito primeiro incluindo todos os artefatos necessários e os arquivos de script básicos no plug-in. Implementamos o padrão com o componente de depuração para criar um ambiente com os artefatos no armazém e os diretórios de ativação contendo os arquivos JSON. Depois, acessamos a VM e chamamos os scripts individualmente para desenvolvimento e depuração adicionais. Os scripts foram copiados de volta para os projetos Eclipse.

Executando um script de ciclo de vida

Ao desenvolver scripts Python de ciclo de vida, o desenvolvedor deve prestar muita atenção aos eventos de ciclo de vida que acionam cada script para execução. Alguns scripts são executados somente uma vez em todo o tempo de vida de uma VM, outros são executados em diversos eventos de ciclo de vida.

Por exemplo, install.py só é executado uma vez para inicialização, enquanto configure.py, start.py e stop.py também são chamados em cada reinicialização da VM.

Tínhamos um requisito específico de executar a instalação do SugarCRM no script changed.py do plug-in de link do banco de dados depois que o Apache, PHP e o banco de dados fossem todos configurados corretamente. O script de instalação deve ser executado somente uma vez para definir e configurar o conteúdo do SugarCRM, não toda vez que changed.py também é chamado para cada reinicialização da VM.

Um atributo de função pode ser introduzido no Python para indicar o status da instalação. No changed.py, verificamos a existência de um arquivo persistente produzido pelo SugarCRM no final da instalação para assegurar que não seja executado várias vezes.

Os detalhes dos scripts do ciclo de vida podem ser encontrados no IBM Workload Deployer Information Center and Plug-in Development Guide.

Excluindo um plug-in não excluível

Durante o desenvolvimento, geralmente enfrentamos uma situação em que um plug-in não pode ser excluído no IBM PureSystems porque algum elemento dele ainda está em uso. Embora a mensagem de erro simplesmente informe que o plug-in está em uso e não forneça as informações sobre onde ou como, achamos que uma limpeza completa das instâncias do aplicativo implementado, padrões de aplicativo e modelos de aplicativos relacionadas ao plug-in geralmente resolve o erro.

Importando plug-ins individuais versus plug-ins empacotados

Embora finalmente tenhamos compactado todos os nossos plug-ins em um tipo de padrão, aprendemos que é mais eficiente e oportuno importar plug-ins individuais para o IBM PureSystems durante o desenvolvimento. O tipo de padrão primário ainda precisa ser importado separadamente, de forma que plug-ins individuais possam ser configurados e ativados.

Esse mecanismo de ligação tardia permite que qualquer um de nós altere e depure apenas um plug-in, sem afetar o tipo de padrão e os demais plug-ins. O ciclo de desenvolvimento reduzido é extremamente útil porque alguns de nossos plug-ins transportam conjuntos de arquivos grandes e demoram muito tempo para reimportar e reativar.

Com isso, descobrimos uma situação em que não podemos mais configurar ou excluir um plug-in importado individualmente se o tipo de padrão primário for excluído do IBM PureSystems. O cenário pode ocorrer quando um desenvolvedor tenta excluir um plug-in e outro desenvolvedor está no meio da atualização do tipo de padrão. Quando o tipo de padrão primário é retornado, o plug-in problemático pode ser totalmente gerenciado. Os plug-ins empacotados do tipo de padrão não apresentam esse problema, porque eles vêm e vão com o tipo de padrão.

Sugerimos que a equipe do produto IBM PureSystems permita a exclusão do tipo de padrão somente se não houver plug-ins dependentes importados individualmente; o recurso não será entregue em um release futuro.

Usando versões para acelerar o desenvolvimento

Cada tipo de padrão tem uma versão no formato major.minor. Durante o desenvolvimento, ocasionalmente queríamos implementar e comparar várias versões de um tipo de padrão ou simplesmente não queríamos passar pelo ciclo de limpeza do tipo de padrão. Achamos que seria conveniente usar uma versão principal diferente para construir e instalar o tipo de padrão.

Os plug-ins empacotados no tipo de padrão também precisavam ter uma nova versão principal e se referirem à versão do novo tipo de padrão. Por exemplo, se a versão do tipo de padrão instalada atualmente for 1.0.0.1 e a versão do novo tipo de padrão for 2.0.0.1, os plug-ins devem ter a configuração de acordo com o seguinte segmento de amostra em config.json:

"name": "sugarcrm",
"version": "2.0.0.2",
"patterntypes": {
    "primary": {
        "sugarcrm": "2.0"
    }   
},

Essa técnica não somente suporta a verificação rápida de implementação de um novo tipo de padrão, mas também permite que diversos desenvolvedores compartilhem o mesmo ambiente do IBM PureSystems.

Manipulando binários grandes

Devido à consideração de licenciamento descrita anteriormente, devemos empacotar alguns softwares separadamente do plug-in e fazer upload deles quando o plug-in for implementado. Essa etapa é executada somente uma vez no cenário normal; no entanto, durante o desenvolvimento do plug-in, o upload repetido de binários grandes, na faixa de 500 MB, pode ser inibidor, especialmente em uma rede lenta.

Uma técnica usada pela equipe de desenvolvimento de plug-in é adotar uma variante do processo de desenvolvimento que permita o carregamento de arquivos binários separadamente dos plug-ins. Isso é possível com um ambiente de desenvolvimento interno. A equipe de desenvolvimento de plug-in está trabalhando para fornecer o recurso a todos os desenvolvedores de plug-in.

Estendendo a imagem de base

Para fornecer o conjunto de software obrigatório para um aplicativo, uma troca geralmente considerada é instalar o software na imagem de base ou incluir o software como parte da imagem de base. Como o IBM PureSystems permite que o usuário estenda a imagem base, consideramos criar uma nova com os RPMs necessários para o SugarCRM. Isso simplifica o esforço de desenvolvimento inicial e o esforço de manutenção no futuro, pois o plug-in será isolado das mudanças na imagem base.

No entanto, como uma imagem base personalizada seria comum a todos os padrões, não está claro se essa abordagem é viável na prática. Parece que certa flexibilidade na associação da imagem base, talvez em conjunto com uma ferramenta de desenvolvimento de imagem, como o ICON, inclui novas possibilidades no design do plug-in. Em geral, é mais fácil para o cliente usar uma imagem base. A inclusão desse recurso requer considerações cuidadosas.

Conclusão

Nesta série conseguimos demonstrar as considerações de design que nossa equipe usou como um modelo para nos guiar na criação de um plug-in a fim de permitir a implementação da solução SugarCRM existente no IBM PureSystems; também mostramos os esforços de desenvolvimento realizados e detalhamos as lições aprendidas com este projeto.

Esperamos que nossas experiências práticas possam facilitar muito a composição de plug-ins do IBM PureSystems para aplicativos existentes.

Após testes bem-sucedidos dos casos de uso, declaramos que a solução SugarCRM está “pronta para o IBM PureSystems”. Além de adquirir uma experiência valiosa no desenvolvimento de plug-ins complexos, acreditamos que nosso projeto atingiu estes resultados significantes:

• Entrega bem-sucedida do primeiro padrão de aplicativo no IBM PureSystems com base em uma pilha de software não padrão. Isso contribuirá para o sucesso do IBM PureSystems e do SugarCRM, permitindo que um importante ISV ofereça seu software como parte do catálogo do IBM PureSystems;
• Demonstração clara de que o IBM PureSystems não está limitado aos padrões do aplicativo fornecidos de forma simples de instalar. Ao desenvolver novos plug-ins, novos aplicativos de clientes e ISVs podem ser integrados para aproveitar a eficiência do IBM PureSystems;
• Exercício rigoroso do suporte para desenvolvimento de plug-in no IBM PureSystems. Esse suporte deve ser robusto para desenvolver um rico catálogo de padrões do aplicativo. Expondo a estrutura de plug-in a cenários diferentes do conjunto atual de softwares IBM, ajudamos a equipe do IBM PureSystems a identificar áreas que precisam de melhorias e o esforço levou a diversos recursos novos que ajudarão no desenvolvimento futuro.

O IBM PureSystems oferece o potencial de aumentar substancialmente a produtividade na nuvem, permitindo que os usuários enfoquem seus padrões de aplicativo sem se preocupar com a infraestrutura subjacente. Acreditamos que a proliferação de novos plug-ins assegurará o sucesso do IBM PureSystems, oferecendo aos usuários um rico conjunto de opções de padrões de aplicativo.

***

Faça o download do PureSystems – IBM Virtual Pattern Kit for Developers e descubra a flexibilidade de sistemas integrados especiais e o valor ao utilizar padrões comprovados e implementáveis de especialistas. Com ele, você pode alavancar ou estender os padrões IBM localmente em seu próprio sistema!

Agradecimentos

Gostaríamos de agradecer aos principais apoiadores deste projeto:

• Willy Chiu, Larry Hsiung, Thomas Truong, Jeffrey Coveyduc, Kai Young, Nauman Fakhar, Chris Kiernan, Raymond Wong dos laboratórios de nuvem e da equipe HiPODS
• Steve Ims, Lin Sun, Ted Kirby da equipe de desenvolvimento do IBM Workload Deployer
• Ning Wang, Qi Rong Wang da equipe de desenvolvimento do IBM Database as a Service
• Nasser Momtaheni, Joseph Peterson, Rodney Johnson da equipe do IBM Innovation Center
• Stas Malyshev do SugarCRM

Recursos

Aprender

• Saiba mais sobre o IBM PureSystems.
• Encontre recursos do IBM PureSystems no developerWorks
• 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 durante a execução.
  • Abordagens com ênfaseno Windows para fornecimento na nuvem IBM.
  • Implemente produtos usando o serviço de implementação rápida.
  • Integre a 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 envolve 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; o desenvolvimento no SmartCloud é uma ótima maneira de praticar o desenvolvimento para o IBM PureSystems.

Obter produtos e tecnologias

• Consulteas imagens do produto disponíveis para o IBM SmartCloud Enterprise.

Discutir

• Participe de um grupo sobre computação em nuvem no developerWorks.
• Leia todos os ótimos blogs sobre nuvem no developerWorks.
• Participe da comunidade do developerWorks, uma rede profissional e um conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.

***

Sobre o autor:

• Ton Ngo é arquiteto de soluções de nuvem e desenvolvedor senior no Laboratório do Vale do Silício da IBM, em San Jose, Califórnia. Recentemente, trabalhou como arquiteto para a Nuvem do High Performance Computing na Nanyang Technological University, Singapura, e para a Nuvem de Teste e Desenvolvimento no Royal Bank of Canada. Antes disso, trabalhou como pesquisador no IBM T.J. Watson Research Center e Almaden Research Center por 17 anos e publicou artigos de diversos assuntos.
• Chin Huang é arquiteto de soluções de nuvem especializado em TI e arquitetura de software. Possui experiência profissional no desenvolvimento de soluções avançadas, incluindo a plataforma IaaS, integração SaaS, nuvem analítica, serviços da web e plug-ins IWD. Chin é consultor de solução de computação em nuvem certificado e autor de mais de 10 artigos técnicos. Vive e trabalha no Vale do Silício, Califórnia.