Navegue uma Carga de Trabalho de Serviços Compartilhados no PureApplication System

Saiba como desenvolver serviços compartilhados, uma carga de trabalho que oferece recursos em comum para outras cargas

IBM® PureApplication™ System e IBM Workload Deployer oferecem recursos para executar muitas cargas de trabalho diferentes na nuvem — um deles é serviços compartilhados, um tipo de carga de trabalho que ajuda os clientes a fornecer recursos em comum para outras cargas de trabalho. Esses recursos e serviços de tempo de execução comuns melhoram a densidade de nuvem enquanto simplificam o uso de recursos complexos ou avançados. Neste artigo, os autores explicam alguns conceitos básicos de serviços compartilhados e descrevem os plug-ins de serviço compartilhados de amostra no Plug-in Development Kit (PDK) que é um bom ponto de partida para criar serviços compartilhados. Também explicam como converter o serviço compartilhado de amostra em um serviço compartilhado de mídia genérica funcional, um repositório de armazenamento de arquivos genérico no qual implementações de cliente podem obter arquivos em comum.

Jim Riordan, Developer, IBM

Jim Riordan trabalha na IBM há 10 anos e escreveu vários testes de caso, documentação de desenvolvimento interna (como documentos de design, guias de desenvolvedor e guias de usuário) e analisou e escreveu documentação de centros de informações externos para diversos produtos IBM, incluindo WebSphere®, WebSphere Business Integration/Connect e IBM Workload Deployer. Atualmente ele trabalha como desenvolvedor nas tecnologias IBM Workload Deployer e IBM PureApplication System.



James Kochuba, Security Test Architect, IBM

James Kochuba photoJames Kochuba é arquiteto de serviços compartilhados em nuvem e líder de capacidade de manutenção do WebSphere, e trabalha atualmente nos aplicativos Workload Deployer e PureScale Application System. O autor também foi arquiteto de testes de segurança do WebSphere Application Server e participou das equipes de suporte do WebSphere Application Server e de suporte premium do AIM. Ele é líder técnico para serviços compartilhados (como criação de logs, monitoramento e serviços de armazenamento em cache) e serviços (solução de problemas) para produtos IBM Platform as a Service. Embasado em sua experiência técnica, Jim ajuda a produzir serviços de maior qualidade para atender às necessidades de uso dos clientes.



23/Out/2012

Um serviço compartilhado é um padrão pré-definido que é implementado e compartilhado por várias implementações de aplicativo cliente (como aplicativos virtuais, sistemas virtuais e dispositivos virtuais) na nuvem. Um serviço compartilhado oferece alguns serviços de tempo de execução a diversos aplicativos ou serviços ao usuário final em nome de diversos aplicativos.

Geralmente encontramos uma única referência ao serviço compartilhado por grupo de nuvem (que é um grupo físico de hardware que define uma nuvem) — esse serviço compartilhado pode ser usado por todas as implementações de aplicativo no grupo de nuvens. Isso significa que o serviço compartilhado precisa oferecer acesso a diversos arrendatários.

Figura 1. Um serviço compartilhado é um padrão predefinido, implementado e compartilhado por várias implementações de aplicativo
Um serviço compartilhado é um padrão predefinido, implementado e compartilhado por várias implementações de aplicativo

Para os fins deste artigo, definimos um serviço compartilhado como uma única implementação que pode ser usada por outras implementações de aplicativo virtual (implementações cliente). Uma ou mais implementações clientes podem conectar-se à implementação única de serviço compartilhado para acessar um repositório de dados em comum.

Este artigo descreve as etapas para importar e customizar o serviço compartilhado de amostra do Plug-in Development Kit (PDK), chamado de serviço compartilhado de amostra ou serviço de mídia.

Para alguns bons recursos de aprendizado que complementam este artigo (talvez até pré-requisitos, dependendo do seu nível de experiência com esse tópico), consulte a barra lateral.

Conceito de serviço de mídia compartilhada

Com frequência, uma implementação de aplicativo virtual exige alguma forma de mídia binária para instalar; por exemplo, binários em um servidor de desenvolvimento ou imagens de DVD ISO. Pode haver motivos para não empacotar esses binários com o padrão de aplicativo ou plug-ins de componente, como licenciamento, questões de distribuição de código, ou necessidade de atualizar o binário de forma independente do padrão de aplicativo.

Para começar

Antes de começar com este artigo, pode ser útil familiarizar-se com os conceitos de aplicativo virtual e do Plug-in Development Kit (PDK) mencionado no resumo. Esses recursos podem ajudar:

Aqueles em negrito são altamente recomendados pelos autores. Editor

Em um ambiente de nuvem, diversas implementações de aplicativo podem precisar fazer referência aos mesmos arquivos de mídia. Se os arquivos exigidos estiverem em uma rede mais lenta (talvez remota) fora da nuvem, pode demorar muito para fazer download dos arquivos em cada aplicativo virtual implementado.

Para solucionar esses problemas, sugerimos criar um novo serviço compartilhado de mídia que hospede um repositório de arquivo binário para uso por qualquer aplicativo virtual no grupo de nuvens. O serviço de mídia pode ser implementado e carregado com arquivos de pré-requisito de forma independente dos aplicativos virtuais e plug-ins.

Em vez de copiar os arquivos de algo fora da nuvem cada vez que novas implementações de aplicativos são iniciadas, é possível copiar os arquivos uma vez na máquina virtual (VM) de serviço de mídia, disponibilizando-os localmente na nuvem. Isso permite que o administrador gerencie esse serviço com um design mais centralizado, em vez de ter VMs independentes que não compartilham uma estrutura em comum.

A velocidade de cópia de arquivo do serviço de mídia para o aplicativo virtual será muito mais rápida, já que tudo ocorre dentro do rack (ou seja, o PureApplication System) e da nuvem de grupo, permitindo que diversas implementações acessem rapidamente os dados.

O exemplo a seguir é um fluxo típico do serviço de mídia:

  1. Implemente o serviço compartilhado/serviço de mídia.
  2. A VM do serviço de mídia começa e é carregada com arquivos binários para compartilhar através de NFS no grupo de nuvens.
  3. Implemente um aplicativo virtual que usa o serviço de mídia (sinalizador de componente ou política no padrão).
  4. O aplicativo virtual solicita ao serviço de mídia a localização dos arquivos binários e/ou informações de conexão.
  5. O aplicativo virtual pode montar em NFS o arquivo de repositório vindo da VM de serviço de mídia.
  6. Repita para mais de uma implementação de aplicativo virtual. Cada uma recebe acesso ao(s) arquivo(s) compartilhado(s) através do serviço de mídia.

Primeiro, veremos o serviço compartilhado de amostra fornecido no Plug-in Development Kit, analisando os elementos fornecidos e, em seguida, importando o serviço compartilhado para o produto IBM PureApplication System ou IBM Workload Deployer para implementar na nuvem. Essa é uma visão geral de como incluir um serviço compartilhado genérico.

Em seguida, explicaremos como modificar os plug-ins de serviço compartilhado de amostra para que se tornem um serviço de mídia compartilhado, mostrando como é fácil incluir um novo serviço compartilhado. Após essa seção estão as etapas e fragmentos de código de como fazer isso, para que seja possível, a partir do que é fornecido, criar facilmente um serviço compartilhado de mídia e futuros serviços compartilhados customizados.


Desenvolvendo e instalando o PDK, serviço e aplicativo virtual de cliente

O serviço compartilhado de amostra no PDK v1.0.0.4 é um bom esqueleto para a customização. Ele define a estrutura de arquivo necessária e scripts principais, definindo o seguinte:

  • Um serviço compartilhado de amostra com uma interface administrativa de API REST.
  • Um componente de aplicativo virtual cliente que usa o serviço compartilhado de amostra para chamar a interface administrativa de API REST.

Comece importando o código de exemplo e, em seguida, inclua a funcionalidade customizada.

Faça o download do PDK v1.0.0.4. O requisito mínimo para implementar os plug-ins é IBM Workload Deployer 3.1.0.2 ou IBM PureApplication System v1.0. Consulte as referências da barra lateral para instruções sobre como usar o PDK.

Algumas coisas para se ter em mente:

  1. Certifique-se de importar todos os projetos, incluindo o serviço compartilhado e o cliente de serviço compartilhado.
  2. Acesse o projeto plug-in.depends e use ANT para executar build.xml. Execute a limpeza e publique os destinos nessa ordem. Isso desenvolverá todos os projetos de plug-in, incluindo o serviço compartilhado e o cliente de serviço compartilhado.
  3. Acesse patterntype.hello e use ANT para executar build.patterntype.xml. Execute a limpeza e publique os destinos nessa ordem. Isso empacota a saída de plug-in.depends em um único padrão para a importação.

Agora, vamos instalar o tipo de padrão no Workload Deployer ou PureApplication System.


Instalando o tipo de padrão no IWD ou IBM PureApplication System

Para instalar o tipo de padrão, que contém os plug-ins de serviço compartilhado de amostra:

  1. No console do IBM Workload Deployer ou no console do PureApplication System Workload, acesse Cloud > Pattern types.
  2. Se o tipo de padrão pattnertype.hello já existir, selecione e clique em Delete.
  3. Observação: Certifique-se de que nenhuma implementação em execução esteja usando os plug-ins desse tipo de padrão; caso contrário não será possível excluí-lo. Aguarde um momento para que o processo seja concluído e a página seja atualizada.
  4. Clique no sinal de mais verde para importar o novo tipo de padrão.
  5. Importe o arquivo da área de trabalho do Eclipse: arquivo patterntype.hello/export/ptype.hello-2.0.0.2.tgz.
  6. Após a importação ser concluída, selecione o padrão patterntype.hello e aceite a licença para ativá-lo.

Observação: Caso queira modificar ou reimplementar o cliente sem reimplementar o serviço compartilhado, é possível empacotá-lo separadamente, alterar o número de versão (apenas versões exclusivas podem ser importadas) e fazer upload através da página Cloud > System Plug-ins.

Em seguida, implemente o serviço compartilhado de amostra.


Implementando o serviço compartilhado de amostra

Para implementar o serviço compartilhado de amostra em um grupo de nuvem, para que esse serviço compartilhado esteja pronto para uso:

  1. No console do Workload Deployer ou no console do PureApplication System Workload, acesse Cloud > Shared Services.
  2. Selecione Sample Shared Service abaixo do cabeçalho do serviço compartilhado de amostra.
  3. Clique em Deploy.
  4. Insira os parâmetros de implementação necessários:
    1. Enable REST API: marcado.
    2. Management VM Number: 1.
    3. Service VM Number: 0.
    Figura 2. Os parâmetros de implementação do serviço compartilhado de amostra
    Os parâmetros de implementação do serviço compartilhado de amostra
  5. Clique em OK.
  6. Na tela a seguir, especifique os parâmetros de implementação corretos para seu ambiente e clique em OK.
  7. Visualize a implementação em Instances > Shared Services.

Aguarde até que o serviço compartilhado de amostra implementado fique verde e esteja pronto para uso antes de passar para a próxima etapa, implementação do cliente de serviço compartilhado.


Implementando o cliente de serviço compartilhado

Crie um padrão para o cliente de serviço compartilhado que irá usar o serviço compartilhado de amostra. Observe que é necessário que o serviço compartilhado de amostra esteja sendo executado para que o cliente de serviço compartilhado seja implementado com êxito.

  1. No console do Workload Deployer ou no console do PureApplication System Workload, acesse Patterns > Virtual Applications.
  2. Selecione patterntype.hello na lista suspensa e selecione o sinal de mais para criar um padrão.
  3. No Pattern Editor, arraste o Shared Service Client Sample do quadro esquerdo para o centro.
    Figura 3. Criando um padrão para o cliente de serviço compartilhado
    Criando um padrão para o cliente de serviço compartilhado
  4. Clique em Save e dê um nome ao novo aplicativo. Nós o chamamos de SharedServiceClient.
  5. Feche a janela do App Builder e atualize a tela Virtual Application Patterns.
  6. Selecione o novo cliente SharedServiceClient.
  7. Clique em Deploy.
  8. Especifique os parâmetros de implementação corretos para seu ambiente e clique em OK.
  9. Visualize a implementação em Instances > Virtual Applications.

Aguarde até que o padrão de cliente implementado esteja verde e pronto para usar para passar para a próxima etapa: acessar o console de Management Operations, onde é possível interagir com as VMs implementadas.


Descobrindo a tela do console Management Operations

A tela Management Operations permite que os usuários interajam com VMs implementadas. Há uma tela Management Operations para a implementação do serviço compartilhado de amostra e para a implementação do aplicativo cliente do serviço compartilhado.

Para visualizar a tela Management Operations para o serviço compartilhado de amostra:

  1. Visualize a implementação em Instances > Shared Services > Sample Shared Service.
  2. Quando estiver em execução, clique em Manage link.
  3. Clique na guia Operation.
  4. Clique na função SharedService-Management.ServiceSample. Observe que esse link não existe até que você inclua algumas operações nele. Você fará isso mais tarde.

Para visualizar a tela Management Operations para o cliente de serviço compartilhado:

  1. Visualize a implementação em Instances > Virtual Applications.
  2. Quando estiver em execução, clique em Manage link.
  3. Clique na guia Operation.
  4. Clique na função SharedService-Client.ServiceClient.
Figura 4. A página Management Operations do cliente de serviço compartilhado
A página Management Operations do cliente de serviço compartilhado

No código de exemplo, é possível usar o Management Operations do cliente para interagir com as APIs REST do serviço compartilhado de amostra. Para ver a interação, é possível suar a tela Operation para enviar uma chamada REST ao serviço compartilhado. Por exemplo:

  1. Expanda a seção REST Calls.
  2. Insira o seguinte:
    URL:  test
    REST METHOD:  PUT
    JSON:  {}
  3. Clique em Submit.

Isso chama a API REST no serviço compartilhado, mas ainda não faz nada de realmente útil.

Essa é uma maneira pela qual o administrador da implementação pode fazer o cliente interagir com o serviço compartilhado. Também seria possível que o script de ciclo de vida do cliente chamasse automaticamente o serviço compartilhado para realizar ações sem a exigência do usuário. Isso tudo se baseia em como o cliente quer expor a interação ao serviço compartilhado. Veremos um exemplo de implementação disso nas próximas seções.

Vamos examinar o código do serviço compartilhado para transformar o serviço compartilhado de amostra em um serviço de mídia.


Exame do código do serviço e cliente de amostra

O plug-in de serviço compartilhado de amostra (do PDK) que fornece os scripts de ciclo de vida e padrão predefinido para criar e gerenciar o serviço compartilhado chama-se plug-in.com.ibm.sample.sharedservcie.service. Ele cria uma ou mais VMs e executa uma API REST para uso dos clientes. Você irá customizá-lo para criar um serviço de mídia.

Os arquivos a seguir também estão dentro do pacote de plug-in obtido do PDK:

  • src / com.ibm.service.internal / SampleRegistryProvider.java: esse arquivo define as informações de resposta de registro desse serviço compartilhado. Por exemplo, o código cliente chama getRegistry e esse método retorna o IP desse serviço compartilhado. O objeto de registro retornado é um objeto JSON, portanto, pode conter dados adicionais também. Esse código está executando no processo de gerenciamento do sistema (por exemplo, no dispositivo IBM Workload Deployer ou no nó de gerenciador do PureApplication System). Observe que o nome e pacote desse arquivo podem ser customizados, mas é necessário também atualizar o nome do arquivo OSGI-INF (OSGI-INF / serviceRegistryProvider.xml).
  • OSGI-INF / serviceRegistryProvider.xml: esse arquivo contém os detalhes de OSGI do pacote configurável, criando uma referência para que outros chamem esse pacote e sejam executados corretamente. O nome desse arquivo pode ser customizado, o que exige que o arquivo de manifesto (META-INF / MANIFEST.MF) do plug-in note o nome customizado.
  • plug-in / appmodel / metadata.json: define os parâmetros de implementação quando o usuário implementa o serviço compartilhado. Nesse caso, o usuário pode ativar ou desativar a API REST e definir o número de VMs para criar para VM de gerenciamento e de serviço. O nome desse arquivo não pode ser customizado.

    O serviço compartilhado de amostra permite implementar diversas VMs — uma VM de gerenciamento e uma ou mais VMs de serviço. O conceito é que as VMs de serviço são escaláveis para permitir failover ou fornecimento de recursos adicionais quando necessário.

    • A VM de gerenciamento hospeda a API REST e executa os seus scripts.
    • As VMs de serviço também hospedam uma API REST, mas ela é redundante.
    A ideia é que o usuário pode implementar a lógica de redundância de dados e comunicação entre VMs de serviço, além de configurar métricas de ajuste de escala para criar e remover dinamicamente VMs de serviço. Esses são tópicos mais avançados e estão além do escopo deste artigo.

    Para os propósitos deste artigo, supomos que apenas uma VM de serviço compartilhado de amostra seja implementada: a VM de gerenciamento. Ignoramos as VMs de serviço para evitar confusão.

  • plug-in / templates / servicesample.vm: é o arquivo de modelo de VM que define as VMs que são criadas. Nesse arquivo, são definidos dois tipos de VMs:
    • SharedService-Management para as VMs de gerenciamento.
    • SharedService-Service para as VMs de serviço.
    Os atributos referenciados no arquivo são fornecidos pelo usuário no tempo de implementação ao mapear diretamente para metadata.json. Por exemplo, servicesample.vm contém ${attributes.managementNum} que é definido em metadata.json: "id":"managementNum".

    O modelo de VM é baseado em Apache Velocity, portanto, é possível incluir lógica nisso para alterar dinamicamente a topologia final gerada. Como é possível observar, a lógica #if define a VM SharedService-Service apenas se o usuário tiver inserido um número maior que 0 no tempo de implementação: #if (${attributes.serviceNum} > 0). Para este artigo, não implementamos VMs de SharedService-Service, portanto attributes.serviceNum é 0.

  • plug-in / nodeparts / servicesampleapi / common / install / 7_servicesampleapi.py: esse script é executado durante a instalação de VM para configurar a API REST. O nome precisa começar com um número para ser executado na ordem esperada quando nodeparts for executado, mas o nome após o sublinhado (servicesampleapi.py) pode ser customizado.
  • plug-in / nodeparts / servicesampleapi / servicesampleapi / properties / servicesampleapi.json: esse arquivo JSON define os métodos de API REST a serem expostos.
  • plug-in / parts / servicesample.scripts / scripts / ServiceSample / restapi.py: é o script de Python que é executado quando a API REST é chamada. É referenciado em servicesampleapi.json para cada chamada de API REST. O nome do arquivo pode ser customizado, mas é necessário certificar-se de que servicesampleapi.json use adequadamente o nome customizado.

O plug-in do cliente de serviço compartilhado é plug-in.com.ibm.sample.sharedservcie.client. Quando é implementado, permite à implementação de cliente interagir com o serviço compartilhado. Os seguintes arquivos também estão dentro do pacote de plug-in:

  • src / com.ibm.service.internal / SampleServiceProvisioner.java: é o fornecedor do serviço cliente. É executado quando o cliente é implementado, antes de as VMs clientes serem criadas. Mostra como levar a referência ao serviço compartilhado e chamar a API REST do serviço compartilhado.

    Um exemplo de uso de um fornecedor é informar ao serviço compartilhado que outro cliente está sendo fornecido. Por exemplo, usando uma API REST, o serviço compartilhado pode criar um novo usuário/senha e retornar os dados para uso pelas conexões clientes. Isso não é necessário, mas permite que a implementação de cliente falhe graciosamente se o serviço compartilhado não for correto para essa implementação. Outro exemplo: se as expectativas do serviço não forem corretas, isso pode impedir a implementação de cliente de acontecer. O usuário precisaria então trabalhar com o administrador do serviço compartilhado para corrigir o serviço antes de gastar recursos em VMs de implementação de aplicativo com falhas.

  • plug-in / appmodel / operation.json: esse arquivo JSON define as operações disponíveis na tela de console Management Operations para a implementação. Isso permite ao administrador da implementação cliente ter operações fáceis de usar. O nome desse arquivo não pode ser customizado. Quando a operação é executada, ela chama o script action.py como definido por esta linha: "script": "action.py call".
  • plug-in / parts / clientsample / scripts / ServiceClient / action.py: Esse script é executado quando o usuário executa uma operação no console Management Operations. Ele gera uma chamada REST ao serviço compartilhado e, em seguida, usa o comando maestro.pcurl para executar a chamada HTTP.

Agora você deve entender melhor as peças que formam o relacionamento entre cliente e serviço em um cenário de serviço compartilhado. Vamos passar adiante e ver como customizar o serviço compartilhado de amostra em um serviço de mídia. Descreveremos as modificações simples necessárias para criar um serviço de mídia customizado.


Detalhes do serviço de mídia

Faça as seguintes alterações no projeto plug-in.com.ibm.sample.sharedservcie.service.

  1. Inclua mais uma informação no registro de serviço compartilhado. Edite o arquivo src / com.ibm.service.internal / SampleRegistryProvider.java para incluir essa linha no comando getRegistry logo antes do registro ser retornado:
    registry.put("mountPoint", "/shared_repository");

    Essa informação extra é o caminho de arquivo do ponto de montagem NFS que está sendo criado. O código do cliente deve ler esse valor para saber como montar em NFS o repositório.

  2. Inclua na API REST do serviço compartilhado. Modifique o arquivo plug-in / nodeparts / servicesampleapi / servicesampleapi / properties / servicesampleapi.json incluindo a nova função para listRepository na seção GET:
    { "resource":"listRepository", 
    "clientdeploymentexposure":true, 
    "role":"SharedService-Management.ServiceSample", 
    "script": "restapi.py listRepository", 
    "timeout" : 60000},

    Isso define o seguinte:

    • Uma chamada GET para listRepository.
    • Que está disponível para outras implementações de cliente (não apenas o código principal de IBM Workload Deployer/IPAS).
    • Que é executado pelo tipo de função de VM SharedService-Management.ServiceSample.
    • Que, quando chamado, executa o script restapi.py e passa listRepository como parâmetro. Você logo atualizará o script restapi.py para usar esse novo parâmetro.
    • Esse tempo limite de resposta está configurado para 60 segundos.
  3. Inclua as mesmas operações para que esse serviço seja exposto na tela Management Operations. Defina duas operações: listRepository e importFile.

    Crie um nome arquivo chamado plug-in/appmodel/operation.json:

    {
         "ServiceSample": [
              {
                   "id": "listRepository", 
                   "label": "List repository", 
                   "description": "List files in the repository", 
                   "script": "action.py listRepository"               
              },
              {
                "id": "importFile",                
                "label": "Import file via HTTP", 
                "description": "Import a single file into the repository via http url.", 
                "script": "action.py importFile", 
                "attributes": [                         
                        {
                             "label": "URL to import", 
                             "type": "string", 
                             "id": "url", 
                             "required": true, 
                             "description": "HTTP URL of a single file to import into 
                                             the repository."
                        },                                   
                   ]
              }
         ]
    }
  4. Escreva os métodos Python que são executados quando as operações são executadas. Crie um arquivo chamado parts/servicesample.scripts/scripts/ServiceSample/action.py. Esse script é chamado quando uma operação é executada na página Management Operations. Contém os dois novos métodos e a lógica de estrutura necessária para executá-los.
  5. Atualize o script parts/servicesample.scripts/scripts/ServiceSample/restapi.py e inclua a nova API REST. Para incluir um novo método no script:
    def listRepository():
        logger.debug('Called listRepository in restapi')
        ret = os.listdir(SHARED_REPOSITORY_PATH)
        #create JSON string out of return value
        ret = '{"fileList":"'+str(ret)+'"}'
        logger.debug('return value = ' + str(ret))
        maestro.operation['return_value'] = ret

    Para atualizar o método run() principal para chamar o novo método:

    def run():
         ...
        elif mode == "listRepository":
            listRepository()
  6. Inclua a lógica no script de ciclo de vida start.py para criar de fato o compartilhamento NFS.

Com essas modificações, você criou um serviço de mídia que está pronto para ser construído e implementado.

Agora, é possível testar o serviço compartilhado. Desenvolva o tipo de padrão, reinstale e reimplemente o serviço compartilhado. Após a implementação, acesse a tela Operations e tente importar um arquivo e listar o repositório.

Observe que as URLs de importação de arquivo devem ser visíveis para essa VM na rede. Caso prefira, é possível usar o comando scp ou mesmo um compartilhamento NFS para customizar os parâmetros de operação e script Python a ser importado. Os scripts Python também podem chamar um shell script, portanto, há muitas possibilidades.

Figura 5. A página Management Operations após fazer upload de um arquivo para o serviço de mídia
A página Management Operations após fazer upload de um arquivo para o serviço de mídia

Opcional: Carregar arquivos antes de implementar

Até agora, este exercício tem sido bom para carregar arquivos após o tempo de implementação, mas e se quisermos especificar os arquivos a serem carregados antes de implementar? Não incluímos isso no código de exemplo, mas aqui estão algumas dicas.

É possível incluir um campo de entrada de usuário opcional nos parâmetros de implementação, metadata.json:

         {
            "id":"filesToLoad",
            "label":"URL listing of files to load",
            "description":"List one or more URLs of files to import into the repository.
                           Multiple URLs must be separated by a comma.",
            "required":false,
            "type":"string",            
         }

E colocar a entrada do usuário no documento de topologia, templates/servicesample.vm.

Em vm-template do SharedService-Management, edite o bloco de funções para incluir a seção parms:

            "roles": [
                 {
                    "type": "ServiceSample", 
                    "name": "ServiceSample"
                    "parms":{
                        #if ( ${attributes.filesToLoad })
                        "filesToLoad":"${attributes.filesToLoad }",
                        #end                        
                      }
                }

Estes parms estão disponíveis para os scripts de ciclo de vida na função ServiceSample. Por exemplo, parts/servicesample.scripts/scripts/ServiceSample/install.py:

if 'filesToLoad' in maestro.parms:
     filesToLoad = maestro.parms['filesToLoad']

Em seguida, o script precisa analisar a entrada do usuário e fazer download dos arquivos. É possível testar essa funcionalidade você mesmo enquanto prosseguimos com a configuração do cliente.


Detalhes do cliente de serviço de mídia

Crie o plug-in do lado do cliente para usar de fato o serviço de mídia criado. Comece fazendo as seguintes alterações no projeto plug-in.com.ibm.sample.sharedservcie.client.

  1. Quando o cliente é implementado, um dos primeiros lugares que é executado e o fornecedor do cliente SampleServiceProvisioner.java. Nesse arquivo, há vários exemplos de chamadas a API REST para o serviço compartilhado vinculado. Atualmente essas chamadas não fazem muito, mas elas podem ser modificadas para o serviço de mídia. A nova chamada testa a API REST listRepository e emite uma exceção se um erro for retornado. Essa exceção para imediatamente a implementação (antes de qualquer VM ser criado) e faz log dos seus detalhes.

    Você está apenas verificando a chamada de retorno HTTP, mas é possível verificar dados específicos na resposta também. Observe que esse código é opcional e pode ser totalmente removido, mas a detecção de um pré-requisito ausente antes do início da VM economiza tempo para o implementador e recursos de sistema na nuvem.

    No método createService(), logo abaixo das chamadas de API REST existentes, inclua uma outra chamada:

              // Make a call to the Shared Service, and throw an exception if a valid 
                 response is not returned.
              response = this.registrySvc.callOperationOnSharedService(serviceName,
                    clientCloudGroup, clientVersion, ip, "listRepository", "GET", null);
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                          Provisioner: Called example GET listRepository REST call to the
                          shared service: {0}  URL: {1}",
                        new Object[] { serviceName, "listRepository"});
              int statusCode = response.getStatusCode();
              JSONObject responseData = response.getOperationResponse();
              logger.logp(Level.INFO, CLASS_NAME, METHOD_NAME, "Client Sample Service
                       Provisioner: Response back from the REST call was response status
                          code: {0}  Data: {1}",
                   new Object[] { statusCode, responseData });
              if (statusCode!= HttpURLConnection.HTTP_OK) {
                // there was a problem with the REST call to the shared service. It may 
                      not be running.
                   // Throw an exception which will stop the deployment 
                   logger.logp(Level.SEVERE, CLASS_NAME, METHOD_NAME, "Client Service
                               Provisioner: There was a problem with the response.");
                   throw new Exception ("The required Shared Service did not return a
                                         valid response. Please ensure the Shared 
                                         Service is running.");
              }
  2. Chame a API REST listRepository nos scripts de ciclo de vida do cliente (install.py), de modo que a VM saiba quais arquivos estão no serviço de mídia. É necessário criar outro install.py para instalar a função ServiceClient, portanto, crie um arquivo chamado plug-in / parts / clientsample / scripts / ServiceClient / install.py.
  3. Inclua código que recupera as informações de registro do serviço compartilhado:
    regInfo = maestro.registry.getRegistry("sample", "1.0")        
    ipAddr = regInfo['ip']
    mountPoint = regInfo['mountPoint']
  4. Inclua código que chama a API REST:
    # Drive pcurl method
    jsonResults = pcurlInvoke(ipAddr, "sample", method, sslOpts, url, str(json))
    # now use the results however you wish
    logger.debug('return value of listRepository = ' + str(jsonResults))
  5. Inclua código que monta o repositório compartilhado a partir do serviço de mídia e copia todos os arquivos:
    mountCommand = 'mount ' +ipAddr+":/"+mountPoint+" "+ localMountPoint
    logger.debug('mount command = ' + str(mountCommand))
    rc = maestro.trace_call(logger, mountCommand , shell=True)
    logger.debug('return value mount command = ' + str(rc))
    
    logger.debug('Copying all files')
    rc = maestro.trace_call(logger, 'cp -r '+ localMountPoint+"/* 
         " +localRepository, shell=True)
    logger.debug('return value from copy command = ' + str(rc))
  6. Visualize o código fonte completo da implementação de arquivo completa.

Nesse exemplo, você consulta o registro do serviço compartilhado usando o nome do serviço (nesse caso, "sample") que foi registrado em plug-in / applications / servicesample / appmodel.json do serviço compartilhado: "servicename": "sample". Isso retorna o objeto JSON que foi criado no método getRegistry de SampleRegistryProvider.java. Nesse caso, o endereço IP e o ponto de montagem do serviço compartilhado são retornados. Quando tiver essa informação, é possível montar o sistema de arquivos e copiar seus arquivos. O script pode assim ser modificado para usar os arquivos copiados no aplicativo virtual; por exemplo, descompactar e iniciar um instalador.

Com todas as modificações feitas, você criou um plug-in de cliente para um serviço de mídia que está pronto para ser construído e implementado.

Agora é possível desenvolver e testar o projeto do cliente. Siga as instruções anteriores para desenvolver, reinstalar e implementar o serviço compartilhado e aplicativo virtual do cliente.

Após implementar o serviço de mídia, use o console de Management Operations para fazer upload de um arquivo para ele e, em seguida, implemente o aplicativo virtual de cliente. Verifique nos arquivos de log do serviço compartilhado e do cliente de serviço compartilhado. Eles devem mostrar o cliente conectar-se ao serviço de mídia fazer download do arquivo.


Ideias para melhoria

Incluímos algumas ideias para melhorias nesse processo, mas deixamos essas ideias para você explorar.

  • Fazer backup de mídia de VM de gerenciamento do serviço compartilhado para qualquer VM de serviço.
  • Criar uma política de ajuste de escala na VM de serviço do serviço de mídia e implementar a replicação de dados.
  • Inclui mais inteligência na API REST para obter informações de conexão (é possível usar roteamento round-robin para as várias VMs de serviço).
  • Usar conectividade alternada ou mais segura:
    • Fornecer endereços IP de cliente na chamada da API REST, para que o serviço de mídia abra apenas as portas de firewall para os IPs permitidos.
    • Usar uma montagem segura alternada e cópia de arquivo além de NFS ou HTTP.
  • Métodos adicionais de upload de mídia com validação de arquivo com base em metadados carregados.
  • Filtragem adicional de cópia de arquivo do serviço de mídia para o cliente.
  • Validar a entrada do usuário para melhorar a segurança. Incluir entrada do usuário e validação de parâmetro da API REST para evitar que comandos indesejados sejam executados. Em nosso código, o parâmetro de entrada da operação de importação de arquivo do serviço de mídia é passado diretamente à linha de comando, permitindo que um usuário possa executar um comando malicioso na nossa VM de serviço de mídia.
  • O código que conecta o cliente de serviço de mídia ao serviço de mídia é fortemente acoplado e bem integrado ao cliente. Isso funciona bem se você tiver apenas um padrão de cliente de serviço de mídia, mas, caso crie mais de um padrão de aplicativo cliente usando o serviço de mídia, será necessário copiar os mesmos scripts de conexão do serviço de mídia em cada plug-in. Nesse caso, é melhor separar a lógica do cliente de serviço de mídia em seu próprio plug-in. Isso consiste em um fragmento de plug-in genético que contém apenas os scripts de lógica de conexão para conectar-se ao serviço de mídia e fazer o download dos arquivos necessários. Por exemplo, tem um script de ciclo de vida install.py ou configure.py que conecta-se ao serviço de mídia e faz o download de um arquivo. Clientes novos podem ser escritos sem a lógica do cliente de serviço de mídia. Precisam apenas fazer referência a esse plug-in de cliente de serviço de mídia. Na implementação do novo aplicativo virtual, os scripts de plug-in do cliente de serviço de mídia são colocados na máquina virtual e executados junto com o aplicativo.

Conclusão

Neste artigo, explicamos os plug-ins de serviço compartilhado de amostra fornecidos pela IBM para ajudar a demonstrar um serviço compartilhado e como ele fornece um bom esqueleto para serviços compartilhados futuros. Mostramos como tomar esse esqueleto e criar um serviço compartilhado de mídia que hospeda um repositório compartilhado, que pode ser carregado com arquivos por meio do console Management Operations. Em seguida, examinamos a customização de um aplicativo virtual para criar um cliente para esse serviço compartilhado, conectando ao repositório compartilhado de serviço de mídia. Na inicialização, o NFS da VM cliente monta o repositório e copia os arquivos.

Agora você tem um simples repositório compartilhado na nuvem para que os aplicativos virtuais usem. É possível modificá-lo para que seja mais complexo, incluindo elementos de segurança, diferentes repositórios etc. — qualquer aprimoramento que você imaginar.


Download

DescriçãoNomeTamanho
Sample code for this articlesharedservice-workspace.zip86.9KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Participe da Comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing
ArticleID=841963
ArticleTitle=Navegue uma Carga de Trabalho de Serviços Compartilhados no PureApplication System
publish-date=10232012