Três soluções para estruturar uma implantação com o Ansible?

7

No momento, estou implantando um novo produto e me deparei com alguns problemas para estruturar meu Playbook e Funções. Eu tenho três soluções diferentes e espero obter algumas sugestões sobre qual caminho pode ser o melhor.

O produto é um aplicativo da web em um servidor Windows. As etapas a seguir são necessárias para implantar (alto nível):

instalar javajdk
instalar o tomcat
instalar win_service
configurar java regkes
configurar o tomcat
instalar webapp
Começar serviço

Uso inventários estáticos para prod e encenação, grupos_vars, papéis (criados com a galáxia ansible), para que haja algum tipo de estrutura.

Solução 1 Coloque tudo em uma cartilha enorme. Isso não soa bem, mas tem a vantagem de que você conhece as variáveis de instalações anteriores, por exemplo, tomcatprecisa saber onde JAVA_HOMEestá ... que estava com a javajdkinstalação, devido a mais de um java nas máquinas, não existe um ambiente global JAVA_HOME...

Solução 2 Divida tudo em papéis pequenos. Parece ótimo, mas os papéis devem ser independentes um do outro. Não encontrei um método para dissociar tarefas. Faria sentido ter papéis únicos para install_tomcat, por exemplo , config_tomcate criar um manual que possua os papéis mencionados em sequência?

Mas como uma função conhece, por exemplo, um nome de caminho que é necessário na próxima função. -> A instalação define o caminho, a configuração precisa saber .. Eu realmente não tenho certeza para tornar as funções independentes.

Solução 3 Tipo de solução 2. Tenha um manual principal que contenha apenas funções, divida o máximo possível em funções. Ter nomes de variáveis independentes em./roles/vars/main.yml

De alguma forma (?), Encontre um lugar mais alto na variável precedência com o manual onde todas as vardefinições necessárias vão. Internamente, direcione uma variável para a função ou simplesmente substitua uma variável de função.

Por exemplo, um produto tem um serviço, o nome do serviço geralmente faz parte de um nome de caminho tomcat. O tomcatnome não deve depender do serviço; portanto, deve haver um tomcat_install_pathna função, mas também um service_nameno produto. Portanto, caso o manual do produto seja chamado de nome do serviço faça parte do nome, ele tomcat_installé chamado com uma implantação totalmente diferente, não deve haver mexer no nome do serviço.

Eu iria com a solução 3, mas ainda não encontrei uma maneira de configurá-lo. Qual é a opinião dos especialistas, a solução 3 é factível, é uma das outras uma vez melhor ou existe uma quarta solução?

ansible structure

— MBushveld
fonte

3

Eu recomendaria estruturar o código conforme definido no documento Ansible Best Practices :

e seguir a estrutura que os principais colaboradores da plataforma de galáxia ansível usam, como geerlingguy .

Se alguém seguir uma estrutura diferente e significativa, será muito difícil no futuro reutilizar papéis da comunidade ansível de galáxias e é preciso reinventar a roda.

— 030
fonte

Obrigado. E concreto no que diz respeito à minha pergunta: como você desacopla e reutiliza, por exemplo, a instalação do javajdk e a reutilização em uma instalação do tomcat? Quando eles são dissociados do que as variáveis, por exemplo, o pat to javaddk precisará estar "dentro" da função. Como você lida com isso em uma instalação do tomcat sem alterar variáveis em todo o lugar? Existe um conceito comum para usar precedência de variável? Então é qual?

— MBushveld

Eu verificaria a galáxia ansible e instalaria uma função jdk e tomcat. Eu não vou escrever um papel a menos que não esteja disponível. Por exemplo, github.com/silpion/ansible-tomcat eansiblebit.oracle-java

— 030

Observe que eu não testei a função do tomcat. Você pode testar a função do tomcat localmente. Se isso não funcionar, você poderá usar outra função do tomcat da galáxia.

— 030

1

Resposta curta: Você faz programação aqui. Considere os Padrões de programação (código limpo) como "empacotar por recurso" e crie funções reutilizáveis e expressem a razão da função. por exemplo

roles:
  - role: jdk
  - role: tomcat  
      (contains tasks with 'install tomcat', 'configure tomcat' ) 
      (requires jdk)
  - role: the_wepapp 
      (requires tomcat)

Além disso: O papel subjacente, por exemplo, o jdk nunca deve saber sobre o papel do tomcat, etc.

— schmichri
fonte