Como estruturar o código e as configurações relacionadas ao DevOps em um repositório de códigos?

Crescemos como empresa, nossos produtos estão se expandindo e nossas atividades e esforços relacionados ao DevOps também estão crescendo - passamos do Bamboo para um Jenkins mais flexível e configurável, usando pipelines de implantação e outros plugins; mudou para Ansible e começou a usar o Docker aqui e ali internamente.

Todas essas coisas exigem algum nível de codificação ou configuração - scripts e configurações Ansible, scripts groovy do Jenkins, Dockerfiles e configurações YAML.

Por agora, criamos um separado "ops" repositório com diretórios de alto nível para jenkins, ansible, dockere other(o que é um nome terrível, mas agora todas as coisas "outros" DevOps automação estão lá).

Nossa abordagem não parece correta e pode não ser dimensionada, mas quais são as melhores práticas e recomendações para manter o código relacionado ao DevOps em um repositório ou repositórios de código?

A organização atual do código e da configuração que você descreve é ​​estruturada pelas soluções técnicas envolvidas. Esse é um design ruim que adicionará muita sobrecarga em nossas atividades de manutenção e também incluirá muitas armadilhas em nosso caminho. Em vez disso, essa organização deve ser estruturada em torno dos artefatos que estamos implantando.

A razão para isso é que queremos considerar artefatos ( por exemplo, uma imagem do docker ou um pacote de software) como os objetos dos seguintes verbos:

• Construir
• teste
• implantar

considerar um conjunto mínimo de tarefas automatizadas que queremos executar. Se quisermos mudar algo sobre como o verbo de teste é implementado, é fácil visitar a pasta correspondente a esse artefato no repositório apropriado e descobrir os itens de automação específicos de jenkins que precisam ser atualizados. Em vez disso, se as receitas de automação são estruturadas em torno de soluções técnicas, precisamos descobrir do nada que jenkins está envolvido nos procedimentos de teste e encontrar lá os itens de automação relacionados ao artefato. Em situações complexas, a organização em torno das soluções técnicas dificulta muito as atualizações, porque precisamos conhecer a priori todas as soluções técnicas envolvidas em algum serviço para atualizá-las adequadamente.

Por exemplo, um repositório contendo o código de um site e um microsserviço "a" pode ter os seguintes subdiretórios dedicados às operações:

./ops/website
./ops/micro-service-a

cada um com três roteiros chamado build, teste deploy. Agora que a organização dos itens de automação foi esclarecida de alguma forma, vamos voltar nossa atenção para a configuração.

As principais condições e requisitos sobre a organização de configuração são definidas pelo deployverbo quando aplicadas a um artefato semelhante a um serviço. O deployverbo deve ter os seguintes parâmetros:

• a versão do artefato a ser implantada,
• o destino de implantação do artefato, que descreve o ambiente concreto em que o artefato implantado será executado ( por exemplo, um cluster e pontos de extremidade com os quais deve conversar)
• as credenciais que ele deve usar para se conectar a outros pontos de extremidade ( por exemplo, bancos de dados)
• a configuração de tempo de execução de (por quanto tempo as entradas de cache devem permanecer, etc.)

Da perspectiva operacional, esse detalhamento da parametrização corresponde aos graus naturais de liberdade do problema de implantação - além das credenciais que podem ser incluídas na configuração do tempo de execução, mas é melhor separá-las para evitar espalhá-las descuidadamente.

Posso responder sobre o docker, uma das práticas recomendadas para usar o docker é manter o arquivo do docker e os arquivos de composição no mesmo repositório do projeto; portanto, sempre que você clonar o projeto, poderá criar a imagem do docker, e é bom mantenha várias versões do docker para compor arquivos, por exemplo (prod, staging, dev), para que você possa construir a imagem e executar o contêiner com uma opção específica para cada ambiente, por exemplo, para uma máquina dev.

O código de cada ferramenta entra em seu próprio repositório. por exemplo

1. Jenkins Groovy template em um repo Jenkins
2. Playbooks YAML Ansible em seu próprio repositório (com as funções, tarefas, subdiretórios de inventário
3. Modelos Cloudformation / Terrform em seu próprio repositório
4. Arquivos Docker em seus próprios 5 .. E assim por diante

Isso ajudaria você a escalar melhor em termos de orquestração de processos e manter várias ramificações para cada ambiente

Isso daria a você um controle mais granular e descarregaria toda a sobrecarga de versão para os sistemas de controle de versão. Crie também ramificações separadas para cada ambiente e marque o código para cada release de produção (como fazemos para a base de código do aplicativo). Pense em Infra e processe em termos de código. (Qualquer alteração no processo deve ser codificada e enviada ao controle de qualidade, SIT, UAT e, em seguida, ao PROD) semelhante à aplicação.

Por exemplo, você pode ter a V2.1 do Ansible em execução na Produção (ramificação mestre), mas a V2.0 dos contêineres de docker em execução na Prod (ramificação mestre)

Da mesma forma, mantenha seus scripts de banco de dados / scripts bash em seus próprios repositórios e talvez você possa ter um arquivo de verificação de integridade (JSON / YAML) configurado para mostrar as versões de todas as ferramentas / partes em cada URL implementada para fins de rastreamento e automação. (Para que seus webhooks leiam a URL e automatizem implantações)

Fazendo uma distinção entre Ops, o Dev e o DevOps promove o isolamento e impõe uma mentalidade "jogue-o por cima do muro". Para aumentar a cooperação entre equipes, deve-se colocar tudo em um repositório necessário para construir e implantar o projeto.

Dito isto, a resposta para a pergunta:

Como estruturar o código e as configurações relacionadas ao DevOps em um repositório de códigos?

é que, se for necessária a configuração para executar o projeto, deve-se colocá-lo no mesmo diretório.