Esta publicação foi criada por Michael Haigh, engenheiro técnico de marketing da Nutanix
O Nutanix Calm é um gerenciador de ciclo de vida de aplicativos para várias nuvens, o que significa que permite modelar seus aplicativos em blueprints fáceis de consumir, implantar esses aplicativos em uma variedade de nuvens locais e públicas e gerenciá-los durante todo o ciclo de vida. Combine essa funcionalidade com um mercado focado no autoatendimento, política e governança robustas e demonstração, e o Calm permite que a TI e os desenvolvedores transformem rapidamente operações complexas em uma solicitação simples com apenas um clique.
Embora o conhecimento profundo dos projetos de aplicativos não seja necessário para a maioria dos usuários do Calm, é necessário para os operadores e desenvolvedores de TI que desejam criar projetos personalizados a partir do zero. Este blog é direcionado aos usuários que desejam aprender mais sobre os objetos em um plano Calm e como eles interagem.
Primeiro, iremos importar um exemplo de modelo para o seu próprio ambiente Calm, que é uma etapa opcional. A seguir, abordaremos algumas terminologias básicas do Calm, seguidas de práticas recomendadas para escolher onde adicionar operações do Calm às várias ações do blueprint. Por fim, concluiremos tudo mostrando as várias estratégias para introduzir dependências entre serviços.
Começando
Para manter este blog o mais curto possível, trabalharemos em um exemplo de blueprint armazenado no GitHub . Se você é o tipo de pessoa que aprende melhor através do trabalho prático, use uma ferramenta como o wget ou seu navegador favorito para baixar o seguinte arquivo:
Como alternativa, você pode avançar para a próxima seção e seguir as fotos e descrições.
Abra uma página do navegador no Prism Central e navegue até o serviço Calm . No lado esquerdo, abra a página de plantas e clique no botão Carregar planta . Na janela exibida, selecione o JSON do blueprint que acabou de ser baixado. Nomeie o blueprint como desejar e selecione o projeto de sua escolha (de preferência um com vários fornecedores adicionados).
Uma vez carregado, o primeiro passo é clicar no botão Credenciais na parte superior e colar em uma Chave Privada SSH na credencial do CENTOS. Em seguida, clique em Voltare, em seguida, clique em Salvar . Se o blueprint puder salvar sem erros, vá para a próxima seção.
Se você receber erros ao salvar, isso provavelmente significa que você não possui o AHV ou o AWS configurado para este projeto em particular. Você pode mudar o provedor ausente para um provedor associado a este projeto ou simplesmente ignorar os erros. Se você ignorar os erros, não poderá iniciar o blueprint, mas como esse é apenas um blueprint de demonstração, não há problema nisso.
Noções básicas de terminologia calma
Para ter uma compreensão sólida da ordenação e execução de tarefas, precisamos garantir que entendemos os principais componentes de um plano Calm. Analisaremos algumas capturas de tela do nosso modelo, onde os números verdes se correlacionarão com as listas numeradas abaixo.
Os perfis de aplicativos expõem opções simples para seus usuários finais. Freqüentemente, essas opções estão no local em que um aplicativo deve ser executado (AHV ou AWS), mas também podem ser usadas para o tamanho de "camiseta" (Pequeno ou Grande), ou uma combinação dos dois (AHV Pequeno ou AHV Grande ou AWS Pequeno) ) Você, como operador ou desenvolvedor de TI, deve ter uma boa noção das diferenças subjacentes a essas opções, enquanto abstrai essa complexidade de seus usuários finais. Observe a linha azul à esquerda do perfil do aplicativo "AHV" na imagem abaixo, que designa em qual perfil do aplicativo estamos trabalhando.
Os serviços são entidades lógicas expostas por um IP, que abrangem todos os perfis de aplicativos e são gerenciados pelo Calm. Usuários e serviços finais se comunicam através de uma rede através de seus IPs e portas expostos.
Os substratos são uma combinação da nuvem subjacente e da instância da máquina virtual. Quando a nuvem desejada é selecionada na interface do usuário calma, todos os campos necessários para criar uma instância de máquina virtual nessa nuvem específica são exibidos - a combinação de todos esses campos compõe um substrato. Os substratos não abrangem perfis de aplicativos, portanto, é uma prática recomendada nomear substratos como uma combinação do nome do serviço e do nome do perfil do aplicativo (DB_AHV ou DB_AWS ou DB_Small ou DB_Large).
As Ações de perfil de aplicativo (ou Ações de perfil para abreviar) são um conjunto de operações que você pode executar no seu aplicativo. Por exemplo, ao iniciar um blueprint, a ação "Criar" é executada. Se seu aplicativo não for necessário por um período de tempo, você poderá executar a ação "Stop" para interromper seu aplicativo normalmente. Quando você estiver pronto para retomar o trabalho, a execução da ação "Iniciar" trará o aplicativo de volta. Existem dois tipos diferentes de ações de perfil, a seguir.
As ações de perfil definido pelo sistema são criadas automaticamente pela Calm em todos os modelos e aplicativos subjacentes. Como eles foram criados para você, não é possível editar diretamente as tarefas ou a ordem das tarefas na tela. No entanto, existem maneiras de controlar a ordem das operações, que abordaremos durante a seção final deste blog, Calm Dependencies .
Ações de perfil personalizadas são criadas pelo desenvolvedor do blueprint e devem ser adicionadas sempre que você precisar expor um conjunto de operações ao usuário final. As ações comuns do perfil personalizado são "Upgrade", "Expand In" e "Scale Out". Como as ações são personalizadas, tarefas individuais podem ser adicionadas manualmente em qualquer ordem desejada pelo desenvolvedor. Novamente, mais sobre isso durante a seção final deste blog.
Ações de Serviço são um conjunto de operações a serem executadas em um serviço individual. No momento da publicação deste blog, eles não podem ser invocados diretamente pelo usuário final do aplicativo, no entanto, são invocados indiretamente por meio de ações de perfil ou operações de desinstalação (10) do pacote. Conforme mencionado no ponto 2, os serviços abrangem perfis de aplicativos, assim como suas ações (e as operações subjacentes a essas ações). Se você criar uma ação de serviço no perfil "AHV", a mesma ação de serviço estará disponível no perfil "AWS". Existem dois tipos diferentes de ações de serviço, a seguir.
As ações de serviço definido pelo sistema são criadas automaticamente pela Calm em todos os modelos e aplicativos subjacentes. Embora essas ações não possam ser invocadas individualmente, elas são chamadas quando a ação de perfil correspondente é executada. Por exemplo, quaisquer operações colocadas sob a ação de serviço "Stop" quando executadas quando um usuário final chama a ação do perfil "Stop".
Ações de serviço personalizadas são criadas pelo desenvolvedor do blueprint e devem ser adicionadas para quaisquer operações repetíveis dentro do blueprint, como uma definição de "função" em uma linguagem de programação. Por exemplo, digamos, durante as ações de perfil "Criar" e "Atualizar", o serviço "Aplicativo" deve obter um novo código do git. Em vez de manter duas tarefas separadas que executam o mesmo conjunto de operações, você pode criar uma única ação de serviço personalizada que é referenciada nas ações "Criar" e "Atualizar".
Instalação / Desinstalação de Pacote são operações executadas durante as ações de perfil "Criar" ou "Excluir". Em outras palavras, são operações executadas quando um usuário inicia um blueprint ou, finalmente, exclui o aplicativo inteiro. Mais sobre a lógica por trás disso na próxima seção, Melhores práticas de ações e tarefas . A instalação e desinstalação de pacotes são exclusivas para cada perfil de aplicativo, o que significa que suas tarefas ou o conteúdo da tarefa pode variar dependendo da nuvem subjacente ou do tamanho da camiseta do aplicativo.
Pré-criação / Pós-exclusão da VM são operações executadas antes da criação do substrato ou após a exclusão. Um caso de uso comum para isso é fazer uma chamada de API em um sistema IPAM (Gerenciamento de Endereço IP) para obter um IP para uma VM a ser criada. Como outras operações descritas até o momento são executadas após o substrato já ter sido criado, a pré-criação da VM é necessária se uma propriedade do substrato depender de um sistema de terceiros.
Práticas recomendadas de ações e tarefas
Quando clientes e parceiros estão desenvolvendo seu primeiro projeto Calm, geralmente perguntam “Onde devo colocar esse script? Em pré-criação de VM, instalação de pacote ou criação? ”Minha resposta típica é“ depende ”e, embora seja precisa sem conhecimento adicional sobre o aplicativo, não é muito útil. Portanto, agora que temos uma linha de base da terminologia Calm definida, vamos mergulhar nas melhores práticas de onde colocar várias operações dentro do seu modelo. No final desta seção, você poderá responder à pergunta anterior!
Existem dois fatores críticos para responder a essa pergunta, o primeiro dos quais é a ordem em que o Calm executa essas ações. A maneira mais fácil de lembrar disso é selecionar a Ação de perfil definido pelo sistema "Criar" em qualquer um dos perfis de aplicativos. Vamos examiná-los individualmente em ordem de operação. Nota: as setas laranja em Calm representam a ordem de execução.
Pré-criação da VM (não na foto) - conforme mencionado na seção anterior, a pré-criação da VM acontece antes da criação do substrato. Portanto, ele não é representado na interface do usuário, no entanto, as tarefas colocadas nesta seção são executadas antes de qualquer uma das ações mostradas na imagem acima.
Criar implantação - uma implantação é uma construção Calm interna e fora do escopo deste blog.
Buscar CentOS_Image - quando a opção “Downloadable Image Configuration” é usada (na seção “Configuration” de um blueprint), esta é a próxima ação executada. Se não houver uma imagem com um "URI de origem" correspondente no Prism Central, o Calm criará uma nova imagem. Se a opção de configuração de imagem para download não for usada, essa ação não será mostrada na interface do usuário.
Criação de substrato - essa operação cria o substrato, o que significa que o Calm executará uma chamada de API na nuvem correspondente para criar uma nova instância de máquina virtual.
Instalação de pacote - esta é a primeira ação na qual os desenvolvedores podem colocar tarefas manualmente. Esta seção é comumente usada para instalar pacotes de software, por exemplo, podemos instalar o PostgreSQL com o sudo yum -y install postgresql-server postgresql-contrib . A instalação do pacote e suas tarefas subjacentes são executadas apenas uma única vez, quando um usuário inicia um blueprint (ação de perfil "criar").
Criar - esta é a próxima ação na qual os desenvolvedores podem colocar tarefas manualmente. Esta seção é comumente usada para configurar os componentes de serviço; por exemplo, podemos configurar o PostgreSQL com o sudo postgresql-setup initdb . Como a instalação do pacote, a ação de criação e suas tarefas subjacentes são executadas apenas uma única vez.
Iniciar - esta é a ação final em que os desenvolvedores podem colocar tarefas manualmente. Esta seção é comumente usada para iniciar os componentes de serviço, por exemplo, poderíamos iniciar o PostgreSQL com o sudo systemctl start postgresql . Não apenas essa ação e suas tarefas subjacentes são executadas quando um usuário inicia um blueprint (ação de perfil "criar"), mas também sempre que o usuário executa a ação de perfil "iniciar" (para trazer o aplicativo de volta depois de executar "parar" )
Como mencionado, entender a ordem em que o Calm inicia as várias ações é um dos fatores críticos. Sem esse conhecimento, você poderia colocar acidentalmente um script de instalação antes de um script de instalação, o que causaria falha na implantação do aplicativo.
O segundo fator crítico para determinar onde colocar suas várias tarefas depende dos perfis de aplicativos . Se você se lembrar da seção anterior, os serviços (e, portanto, suas ações de serviço) abrangem perfis de aplicativos, enquanto as instalações de pacotes não. Portanto, se você tiver operações dependentes da nuvem subjacente ou do tamanho de "camiseta" do seu aplicativo, é melhor colocar essas operações na seção de instalação do pacote.
Em nosso exemplo de modelo, no serviço DB, temos uma tarefa de instalação do pacote "Install_DB_Software" nos perfis de aplicativos AHV e AWS. No entanto, se você visualizar o script de exemplo nessas tarefas, verá que elas são diferentes:
Observe que a última linha desses dois scripts possui uma instrução "eco" diferente. As diferenças nas instalações de pacotes podem ir além do conteúdo do script, você pode adicionar qualquer número de novas tarefas ou ações de serviço em um perfil de aplicativo e essas operações não serão adicionadas ao segundo perfil de aplicativo.
Compare isso às ações de serviço, que abrangem os perfis de aplicativos. No nosso exemplo de modelo, atualmente não temos tarefas na ação de serviço "criar" do banco de dados, que pode ser verificada selecionando nosso perfil de aplicativo AHV , o serviço de banco de dados e, finalmente, a ação Criar . Vamos mudar isso e criar uma tarefa clicando no botão + Tarefa no bloco de serviço do DB na tela do blueprint e, no painel direito, nomeie a tarefa, selecione Executar , Shell , CENTOS e, finalmente, cole no script a seguir :
#!/bin/bash
set -ex
cat << EOF > configure_db
"Created in AHV app profile,
since service actions span
app profiles, this will also
appear in AWS app profile."
EOF
Se você está acompanhando, seu modelo Calm deve ficar assim:
Depois de criar a tarefa acima, mude para o perfil da AWS , expanda o serviço DB , selecione a ação Criar serviço e clique na tarefa Configure_DB :
Como esperado, nossa tarefa recém-criada em nossa ação de criação de serviço também está presente em nosso perfil de aplicativo da AWS. Para resumir nossas descobertas nesta seção:
As operações de pré-criação da VM são executadas antes que o substrato seja criado, nas propriedades pares do substrato dependem de um sistema de terceiros.
As operações de instalação do pacote são executadas primeiro e apenas uma vez quando o blueprint é iniciado. As tarefas e seu conteúdo podem variar entre os vários perfis de aplicativos.
As operações de criação são executadas a seguir e também apenas uma vez quando o blueprint é iniciado. Todas as tarefas e seu conteúdo são exatamente os mesmos nos vários perfis de aplicativos.
As operações de início são as últimas a serem executadas quando um blueprint é iniciado, e essas mesmas operações são executadas sempre que um usuário chama a ação de perfil "iniciar". Todas as tarefas e seu conteúdo são exatamente os mesmos nos vários perfis de aplicativos.
Dependências calmas
Ações de perfil definido pelo sistema
Na seção Noções básicas de terminologia calma, falamos sobre os dois tipos de ações de perfil, ações de perfil definidas pelo sistema e ações de perfil personalizadas e a capacidade de ordenar as operações subjacentes. Como o Calm realiza automaticamente a maior parte do trabalho pesado para ações de perfil definidas pelo sistema (como criar uma API para criar uma VM ou executar um desligamento de convidado), não há como desenhar diretamente as setas laranja que representam a ordem da orquestração. No entanto, existem dois métodos para desenhar indiretamente as setas laranja, que serão a maioria desta seção.
Faça referência a uma macro que contenha uma propriedade do "Serviço A" em uma tarefa do "Serviço B"Desenhe uma seta branca de dependência de "Serviço B" para "Serviço A"
Referências de macro
Antes de modificarmos nossos scripts para conter referências de macro, vamos dar uma olhada no nosso estado atual. Em nosso exemplo de modelo, em qualquer um dos perfis de aplicativo, selecione a ação Criar e visualize a falta de setas laranja entre os serviços.
Em um aplicativo Web real de três camadas, o nível do aplicativo precisará ter conhecimento do endereço IP do banco de dados (entre outras propriedades) para enviar as informações a serem armazenadas no banco de dados. Da mesma forma, o balanceador de carga precisará conhecer os endereços IP dos servidores da Web para rotear as solicitações do usuário final adequadamente. Vamos modificar alguns scripts de instalação de pacotes que armazenam esses IPs em um arquivo de configuração no aplicativo e nos serviços do balanceador de carga.
No painel de configuração esquerdo, selecione o perfil do aplicativo AHV , expanda o serviço Aplicativo , expanda a seção Pacote , clique na ação Instalar e, na tela do blueprint, clique na tarefa Install_App_Software no bloco App. No painel direito que aparece, anexe as seguintes linhas ao script existente:
echo "DB_IP=@@@@" \ > db_config
A macro @@@@ será corrigida com o endereço IP do banco de dados real durante a implantação do aplicativo. Agora vamos expandir o serviço LB no painel de configuração esquerdo e siga as mesmas etapas para anexar as seguintes linhas à tarefa de instalação do pacote do balanceador de carga:
echo "APP_IP=@@@@" \
> app_config
Agora que criamos nossos scripts, vá em frente e clique no botão Salvar na parte superior da interface do usuário calma. Após o blueprint ter sido salvo, selecione a ação Criar perfil em qualquer perfil do aplicativo AHV . Se tudo foi feito corretamente, a tela do seu blueprint deve ficar assim.
Observe a presença de duas novas setas laranja, uma que vai da tarefa "DB Start" para a tarefa "App - Package Install" e a segunda que vai da tarefa "App Start" para a tarefa "LB - Package Install". Desde uma tarefa dentro do pacote de instalação do aplicativo faz referência a uma propriedade do serviço DB, calma sabe que não pode executar pacote de instalação de aplicativos tarefas até que após o serviço DB está totalmente instalado e funcionando. Cada vez que você salva um blueprint, o Calm analisa os scripts subjacentes para qualquer referência de macro e desenha automaticamente essas setas laranja.
Setas de dependência em branco
Embora nossa ação de criação tenha dependências adequadas introduzidas devido às referências de macro, e a nossa ação de parada? Se expandirmos um de nossos perfis de aplicativos e selecionar Parar , veremos que nossos serviços não contêm setas laranja entre eles.
Embora isso possa parecer bom à primeira vista, isso pode causar uma experiência ruim para nossos usuários finais. Se o serviço de banco de dados recebeu instruções para desligar um pouco antes dos serviços do aplicativo ou do balanceador de carga, você pode entrar em uma situação em que o serviço da web aceita uma solicitação que, posteriormente, gera erros devido ao banco de dados desativado. Isso significa que precisamos de alguma forma para que o banco de dados seja desativado por último e, quando o aplicativo for reiniciado, precisamos que ele seja o primeiro.
Para corrigir esta situação, clique no bloco de serviço LB , no pequeno menu que aparece à esquerda do bloco, clique no ícone de seta branca com a dica de ferramenta Criar dependência e clique no bloco de serviço de aplicativo . Isso criará uma linha branca grossa apontando do serviço LB para o serviço de aplicativo e significa que o serviço do balanceador de carga depende do serviço de aplicativo. Repita o mesmo processo para criar outra linha branca grossa apontando do serviço de aplicativo para o serviço de banco de dados. Clique em Salvar para permitir que o Calm receba essas alterações e desenhe as setas laranja da orquestração.
Como lembrete, as setas laranja representam a ordem direta da orquestração, enquanto as setas brancas representam uma visão lógica das dependências. Vemos que a tarefa "LB Stop" é executada primeiro, seguida pela "App Stop" e, finalmente, pela "DB Stop". Agora dê uma olhada na ação do perfil Iniciar .
Observe que as setas laranja estão apontando na direção oposta. Embora isso possa parecer estranho a princípio, ele está alinhado com o nosso objetivo de fazer com que o banco de dados inicie primeiro e diminua por último, para evitar a situação descrita anteriormente.
Antes de avançarmos para a próxima seção, vale a pena falar sobre um erro comum que os desenvolvedores iniciantes de blueprint cometem ao combinar referências de macro e setas brancas de dependência. Se excluirmos essas setas de dependência brancas que acabamos de criar e desenhá-las na direção oposta (DB para App, App para LB), você consegue adivinhar o que pode acontecer?
Com as setas brancas desenhadas nessa direção, dizemos à Calm que o serviço de banco de dados depende do serviço de aplicativo, mas a referência de macro que criamos anteriormente está dizendo à Calm o contrário. Isso resulta em uma dependência circular das operações subjacentes, que são impossíveis de executar. A Calma capta corretamente esse erro e impede que um usuário inicie um blueprint nesse estado.
Ações de perfil personalizadas
Agora que abordamos as ações de perfil definidas pelo sistema, vamos nos aprofundar nas ações de perfil personalizadas, que são bastante diretas. No blueprint de exemplo, no perfil do aplicativo AHV , selecione a ação customizada Upgrade .
Como você pode ver, o Calm oferece a capacidade de desenhar diretamente as setas laranja selecionando uma tarefa (“Start_App” por exemplo), clicando no ícone de seta pequena e, em seguida, selecionando a próxima tarefa (“Start_LB”, por exemplo). Isso instrui o Calm que a tarefa "Start_LB" só pode começar a ser executada após a conclusão da tarefa "Start_App". Você pode desenhar essas setas de orquestração laranja da maneira que desejar, desde que não introduza um fluxo circular.
Sumário
Nesta postagem do blog, abordamos uma variedade de tópicos voltados para operadores e desenvolvedores de TI que desejam aprender tópicos mais detalhados sobre os Calm blueprints para ajudar melhor no desenvolvimento do blueprint. Iniciamos as coisas importando um exemplo de planta para o PC local e depois definindo uma terminologia básica do Calm. Analisamos as diferenças nas várias ações e as práticas recomendadas para colocar tarefas corretamente. Por fim, encerramos o blog abordando as diferentes maneiras de introduzir dependências entre serviços.
ASG
https://www.asgit.com.br/
contato@asg.com.br
(51) 3376.1210