Eu tenho 3 ambientes, cada um em sua própria rede virtual com suas próprias configurações. Preciso ter 3 instâncias separadas do Jenkins para fazer implantações contínuas em cada um dos ambientes? Quais são algumas das práticas recomendadas para reorganizar a implantação em uma arquitetura de vários ambientes?
Respostas:
Essa é uma pergunta muito boa, pois é um antipadrão comum para acoplar ci/cdferramentas a ambientes.
Jenkins é uma fábrica de construção. Como tal, deve ser totalmente independente da noção de ambiente, ou mesmo entrega.
A melhor prática é ter algum tipo de processo de preparação e / ou interface (se você puder pagar: um software de entrega dedicado).
Você deve tentar criar algum tipo de trabalho temporário para cada ambiente, no qual definirá a configuração do ambiente e agrupará o pacote final.
Em seguida, você terá trabalhos de entrega para cada ambiente.
Para fazer criar as tarefas de teste e entrega, você pode usar ferramentas básicas de script, como shell, mas existem ferramentas de script mais adaptadas, como Ansible, puppet, chef...
Se você puder arcar com as despesas, considere investir em um software de implantação (mencionarei alguns com os quais trabalhei na seção de comentários).
Observe que esses softwares gerenciam algum tipo de processo de preparação do ambiente.
Obviamente, faz muito sentido combinar a implantação de softwares e scripts.
Como você pediu as melhores práticas, parece-me que vale a pena mencionar outro anti-padrão comumente encontrado: acoplamento de ferramentas SCM e processo de entrega.
É uma prática muito boa armazenar a configuração do ambiente (não senhas ou informações confidenciais, é claro) e passar scripts ao vivo nas ferramentas do SCM (como svnou git...). No entanto, é uma prática muito ruim fazer check-out da configuração do ambiente e ativar scripts ao vivo DURANTE a ativação. Pode estar simplesmente indisponível quando você precisar.
Essa fase de check-out deve fazer parte do processo de preparação que eu mencionei antes.
Outra prática recomendada é que seus scripts sejam idem-potent: isso significa que você poderá reproduzir seus scripts uma vez para executar a preparação e a entrega. Então você deve poder reproduzi-los repetidamente, e eles não mudariam o estado do seu sistema, a menos que algo ocorresse na configuração.
Como prática recomendada final, compartilharei com a experiência direta a assustadora Jenkins: equipes diferentes têm necessidades e usos diferentes da Jenkins. Quando muitas equipes compartilham um Jenkins comum, pode haver problemas com os recursos. O pior caso é quando uma equipe precisa reiniciar o mestre Jenkins enquanto outra precisa entregar.
O ideal seria ter um Jenkins por equipe ou por grupo de equipes que compartilham o mesmo objetivo e planejamento de entrega.
Acabei de deixar de ter trabalhos de estilo livre Jenkins e ter um trabalho separado para cada ambiente para usar pipelines Jenkins (sintaxe declarativa).
Nos pipelines Jenkins, temos um único arquivo (Jenkinsfile) e definimos diferentes estágios para nossos diferentes ambientes (Dev / Staging / Prod) e, nesses estágios, apenas definimos comportamentos diferentes para cada ambiente. Por exemplo, em nosso estágio 'Deploy', implantaremos em um namespace / cluster kubernetes diferente, dependendo do ambiente de desenvolvimento ou de preparação.
Eu gosto dessa abordagem, pois você tem apenas um arquivo Jenkins por projeto que existe em todas as filiais.
A resposta curta para sua pergunta é não. O Jenkins não precisa conversar com seus ambientes de produção, mas pode, se precisar. Em outras palavras, se o Jenkins puder alcançar esses ambientes, provavelmente poderá interagir com eles.
Em uma abordagem de práticas recomendadas, geralmente recomendo usar um software que torne sua implantação o mais simples e repetível possível (por exemplo, make, Ansible, Terraform, Cloud Formation ou Kubernetes).
Os pipelines são capazes de lidar com destinos paralelos, o que significa que você pode construir e implantar nos três ambientes ao mesmo tempo, se desejar.
Convém tornar sua pergunta mais precisa ou detalhada para obter mais feedback.
Podemos usar o arquivo Jenkins único para um ambiente diferente. Mas precisamos de algo para diferenciar esse ambiente, pode ser uma variável de ambiente ou um parâmetro em um trabalho parametrizado para controlar o que precisamos fazer em cada ambiente. Pode ser que desejemos criar, testar, executar o e2e e enviar a imagem para um repositório em um ambiente. Em seguida, use a mesma imagem e implante no próximo (teste, pode ser) e execute o teste de fumaça. Em seguida, use a mesma imagem para implantar em produção.