Tengo 3 entornos, cada uno en su propia red virtual con sus propias configuraciones. ¿Necesito tener 3 instancias separadas de Jenkins si debo realizar implementaciones continuas en cada uno de los entornos? ¿Cuáles son algunas de las mejores prácticas para mejorar la implementación en una arquitectura de múltiples entornos?
Respuestas:
Esta es una muy buena pregunta, ya que es un antipatrón común para unir ci/cdherramientas con entornos.
Jenkins es una fábrica de construcción. Como tal, debe ser totalmente independiente de la noción de medio ambiente, o incluso la entrega.
La mejor práctica es tener algún tipo de proceso de puesta en escena y / o interfaz (si puede permitírselo: un software de entrega dedicado).
Debe intentar crear algún tipo de trabajos de preparación para cada entorno, en el que definirá la configuración del entorno y empaquetará el paquete final con él.
A continuación, tendrá trabajos de entrega para cada entorno.
Para ello crear las tareas de almacenamiento intermedio y entrega, puede utilizar herramientas muy básicas de scripting, como shell, pero hay herramientas de scripting más adaptados, como Ansible, puppet, chef...
Si puede pagar el gasto, puede considerar invertir en un software de implementación (mencionaré algunos con los que trabajé en la sección de comentarios).
Tenga en cuenta que esos softwares gestionan algún tipo de proceso de organización del entorno.
Obviamente, tiene mucho sentido combinar softwares de implementación y secuencias de comandos.
Dado que solicitó las mejores prácticas, me parece que vale la pena mencionar otro antipatrón que se encuentra comúnmente: el acoplamiento de herramientas SCM y el proceso de entrega.
Es una muy buena práctica almacenar la configuración del entorno (no contraseñas o información confidencial, por supuesto) y activar scripts en vivo en herramientas SCM (como svno git...). Sin embargo, es una práctica muy mala verificar la configuración del entorno e iniciar scripts en vivo DURANTE el lanzamiento en vivo. Puede que simplemente no esté disponible cuando lo necesite.
Esta fase de salida debería ser parte del proceso de preparación que mencioné antes.
Otra mejor práctica es que sus scripts deberían ser idem-potent: esto significa que debería poder reproducir sus scripts una vez para realizar la puesta en escena y la entrega. Entonces debería poder reproducirlos una y otra vez, y no cambiarían el estado de su sistema a menos que haya algo bloqueado en la configuración.
Como una mejor práctica final que compartiré de la experiencia directa es escalar Jenkins: diferentes equipos tienen diferentes necesidades y usos de Jenkins. Cuando muchos equipos comparten un Jenkins común, puede haber problemas con los recursos. El peor de los casos es cuando un equipo requiere reiniciar el maestro Jenkins mientras otro necesita entregarlo.
Lo ideal sería tener un Jenkins por equipo o por grupo de equipos que compartan la misma meta y planificación de entrega.
Acabo de pasar de tener trabajos de estilo libre de Jenkins y de tener un trabajo separado para cada entorno para usar tuberías de Jenkins (sintaxis declarativa).
En las tuberías de Jenkins tenemos un solo archivo (Jenkinsfile) y definimos diferentes etapas para nuestros diferentes entornos (Dev / Staging / Prod) y en esas etapas simplemente definimos diferentes comportamientos para cada entorno. Por ejemplo, nuestra etapa de 'Implementación' la implementaremos en un espacio de nombres / clúster de kubernetes diferente dependiendo de si es el entorno de desarrollo o de preparación.
Me gusta este enfoque, ya que solo tiene un Jenkinsfile por proyecto que existe en todas las sucursales.
La respuesta corta a su pregunta es no. Jenkins no tiene necesidad de hablar con sus entornos de producción, pero puede hacerlo si lo necesita. En otras palabras, si Jenkins puede alcanzar estos entornos, es probable que pueda interactuar con ellos.
Desde un enfoque de mejores prácticas, generalmente recomiendo usar un software que hará que su implementación sea lo más simple y repetible posible (por ejemplo, make, Ansible, Terraform, Cloud Formation o Kubernetes).
Las tuberías son capaces de manejar objetivos paralelos, lo que significa que puede construir e implementar en los tres entornos al mismo tiempo si lo desea.
Es posible que desee hacer su pregunta más precisa o detallada para obtener más comentarios.
Podemos usar un solo Jenkinsfile para diferentes entornos. Pero necesitamos algo para diferenciar entre este entorno, puede ser una variable de entorno o un parámetro en un trabajo parametrizado para controlar lo que necesitamos hacer en cada entorno. Es posible que queramos hacer compilar, probar, realizar e2e e insertar imágenes en un repositorio en un entorno. Luego use la misma imagen y despliegue en la siguiente (puesta en escena, puede ser) y realice una prueba de humo. Luego use la misma imagen para implementar en producción.