Sitecore, Docker y la integración continua

Con el lanzamiento de Sitecore 10, introdujimos soporte para ejecutar Sitecore dentro de contenedores Docker. Esto permitió una experiencia de desarrollo fantástica, lo que le permitió crear y eliminar entornos completos de Sitecore de su máquina local de forma rápida y sencilla. ¡Los días de instalaciones largas y prolongadas finalmente son cosa del pasado!

Es comprensible que la comunidad de desarrollo esté entusiasmada con este cambio para trabajar con Sitecore. Pero, ¿qué sucede cuando pasa del desarrollo y desea comenzar a implementar su solución en sus entornos de producción y no producción? Bueno, al igual que cuando trabaja fuera de los contenedores, querrá configurar una canalización de integración continua (CI) para automatizar este proceso por usted.

Vea el vídeo que acompaña a este artículo, que incluye demostraciones de estos conceptos en nuestro Discover el canal de YouTube de Sitecore.

Al configurar una canalización de CI para contenedores, las cosas se configuran de manera un poco diferente. Cuando se trabaja fuera de los contenedores, normalmente se compila la aplicación y, a continuación, se inserta directamente en las instancias de IaaS o PaaS que las hospedan. El uso de contenedores cambia ligeramente este proceso.

Cuando trabajas con contenedores, el objetivo de tu proceso de CI es crear un nuevo conjunto de imágenes y enviarlas a tu Container Registry. Una vez completada esta acción, se realiza la fase de CI de la implementación.

Lo bueno de esta fase de CI de la implementación es que podemos aprovechar el Docker Compose que usamos para nuestra configuración de desarrollo local para automatizar también nuestras compilaciones de imágenes. Lo mejor de esto es que podemos usar las mismas instrucciones que usamos en nuestra máquina de desarrollo para construir las imágenes que se usarán en nuestras instancias de producción y no producción. Esto aumenta la confianza que tiene en lo que está implementando al tiempo que disminuye los problemas de "¡Funciona en mi máquina!" que todos conocemos.

Cuando se trabaja con contenedores, el concepto de etiquetado de imágenes es fundamental, ya que le permite controlar qué versión de su aplicación se implementa en qué entorno. Hay dos tipos diferentes de etiquetas de imagen cuando se trabaja con contenedores: etiquetas estables y etiquetas únicas.

Etiquetas estables

Etiquetas estables, represented by the green boxes above, are primarily used for base images — you inherit from them to build your images, and they're rarely used for deployments themselves. The reason? They change over time. If you pull the same stable image tag today and then again next week, you could actually get two different images. This is because the images using these tags are re-issued over time to represent versions updates, or base image changes.

Etiquetas únicas

Etiquetas únicas, represented by the dark grey boxes above, are primarily used for deployments, especially in environments that scale to multiple nodes, or running inside of an orchestrator like Kubernetes. This is because the image behind a unique tag won't change, giving you confidence that the image you pull today is the same as the image you pulled at a previous time.

(Si está buscando más, Microsoft tiene un buen artículo sobre la diferencia entre estos tipos de etiquetas aquí.)

Las actualizaciones de imagen se pueden desencadenar por diferentes motivos, pero los dos más comunes son un cambio de código o una actualización de imagen base. Un cambio de código requeriría que las imágenes se reconstruyeran para incluir los cambios realizados en el código base. 

Con las actualizaciones de imágenes base, tu base de código no ha cambiado mientras se ha actualizado una de las imágenes base de las que dependes. Esta podría ser una de las imágenes de Sitecore o tal vez una de las imágenes MS base. Esto también requiere que se publique una nueva imagen para incluir actualizaciones importantes, como correcciones de errores y actualizaciones de seguridad.

Una vez compiladas las imágenes, la última acción que debe realizar en la canalización de CI es insertarlas en un registro de contenedor, como Azure Container Registry. Esto los pone a disposición de otros desarrolladores de su equipo y también significa que están disponibles para su uso en sus entornos de producción y no producción.

Si desea ver un ejemplo de cómo configurar una canalización como esta, puede echar un vistazo al proyecto MVP Site. Esto tiene una canalización de CI/CD en pleno funcionamiento en la que puede basar la suya. Puede ver la configuración de YAML para su uso en Azure DevOps aquí.