Implantação contínua com os encantos de Juju

Question

Estou explorando a possibilidade de implantar nossa infraestrutura de aplicativos usando o Juju.

Meu aplicativo é criado usando o Play Framework e executado na Java Virtual Machine. Eu imagino a seguinte configuração:

• Servidor proxy para descarregamento de SSL (talvez redundante, se isso não for muito difícil)
• Nó primário que executa o aplicativo e a JVM
• Aplicativo em execução do nó secundário (hot spare) e JVM

O servidor proxy só deve usar o nó secundário se o nó primário estiver inativo. Deve haver apenas um único nó de aplicativo recebendo solicitações. Escalar horizontalmente é algo que não precisamos e complica a lógica de negócios.

A configuração acima parece bastante factível. Torna-se (na minha opinião) mais complicado quando penso na parte de implantação contínua.

Meus aplicativos são criados com uma máquina Jenkins privada e resultam em um arquivo zip contendo o aplicativo (como um script bash executável) com todas as suas dependências.

Os seguintes passos devem ser tomados para implantá-lo:

• Envie o zip para um servidor
• Implantar um novo proxy, nó primário e secundário com o aplicativo
• Mudar para o novo proxy

Eu quero criar um charme para isso, mas não sei como proceder.

É possível implantar um pacote de charme de dentro de um encanto? Se sim, como?

Note que qualquer conselho é bem-vindo. Eu não preciso de implementações concretas, apenas ponteiros e direções gerais.

    

Answer 1

O envio de um aplicativo 'construído' para o seu ambiente é, na verdade, uma técnica bastante comum, especialmente para aqueles que usam ferramentas como o docker.

Normalmente, você desejará criar um charme para cada componente em seu ambiente. Nesse caso, parece que você teria 'proxy' e 'aplicativo'.

Assim, você criaria um charme de proxy que, além dos scripts install e start , um relation-joined e relation-broken hook scripts. Esses scripts modificarão as configurações de proxy quando uma relação for unida para adicionar o novo local do aplicativo e, posteriormente, remover um local do aplicativo quebrado. Isso permitirá que você mantenha o proxy em funcionamento e troque os servidores de aplicativos à vontade.

O serviço de aplicativo terá scripts de gancho semelhantes para enviar sua localização para o serviço de proxy. Ele também precisará de uma opção de configuração de charme para o local do arquivo zip do aplicativo para o qual ele precisa ser implementado. Quando os aplicativos install hook forem executados, ele puxará para baixo o arquivo zip na extração fornecida pelo local e, em seguida, o executará no start hook.

A implantação contínua é onde o Juju realmente brilha. Primeiro, você precisará de um ambiente de bootstrap juju bootstrap <your-env-name> e juju switch <your-env-name> .

Sua instância do Jenkins criará o arquivo zip do proxy e do aplicativo e, em seguida, fará o upload deles para um local em que os servidores possam acessar. Se você está no EC2, isso provavelmente seria no S3. Em seguida, anotaria os caminhos de localização e o número de compilação, além dos nomes de serviço dos serviços de aplicativo e proxy em execução no momento.

Em seguida, ele será executado:

juju deploy your-proxy your-proxy-<build-number>
juju deploy your-application your-application-<build-number>
juju add-unit your-application-<build-number> -n 2

Neste ponto, você provavelmente desejará algo em uma verificação de intervalo periodicamente para ver quando seus serviços de proxy e de aplicativo estão ativos e em execução. Nesse ponto, você desejará conectar o novo serviço de aplicativo ao proxy, alternar o tráfego para seu novo proxy e derrubar os serviços antigos.

juju add-relation your-proxy-<build-number> your-application-<build-number>
# add code here to switch to new proxy
juju destroy your-proxy-<old-build-number>
juju destroy your-application-<old-build-number> 

Isso pressupõe que você estará reconstruindo seu proxy sempre que seu aplicativo for alterado. Se não, basta remover as etapas do proxy dos comandos acima. Isso também pressupõe que os aplicativos demorem para serem iniciados e você não desejaria incorrer nesse tempo de inatividade, portanto, um simples upgrade-charm hook não funcionaria.