El año pasado, Sitecore anunció un soporte limitado para ejecutar nuestros productos dentro de contenedores. Puede leer más sobre el modelo de soporte actual en este Artículo de la base de conocimientos. Con cada versión futura, planeamos aumentar nuestro soporte para ejecutar nuestros productos en contenedores. Para cualquier persona nueva en la ejecución de aplicaciones de esta manera, esta publicación proporcionará una descripción general de algunos de los conceptos clave y proporcionará enlaces para un mayor aprendizaje sobre cada uno.
Mira el video que acompaña a este artículo a continuación, que incluye demostraciones de estos conceptos. O míralo en Discover Sitecore en YouTube.
Lo que todos estos problemas tienen en común tiene en torno a cuestiones de consistencia, aislamiento y reproducibilidad. Estos son los problemas para los que se crearon Docker, y los contenedores en general.
Cuando implementa un contenedor, en realidad está implementando todo lo que se requiere para ejecutar esa aplicación, dentro de un solo artefacto.
Como puede ver en la imagen, no solo está empaquetando su aplicación, sino también sus dependencias y bibliotecas, sus activos de configuración y cualquier otra cosa que necesite para ejecutarse. Todo envuelto muy bien en un solo activo que puede mover entre sus diferentes entornos.
Una pregunta común es en qué se diferencia un contenedor de una máquina virtual. Tienen cierta superposición en la funcionalidad que proporcionan, pero la forma en que lo logran es fundamentalmente diferente.
Si observa el diagrama de máquinas virtuales de la izquierda, cada uno de los cuadros verdes representa un sistema operativo completo. Esto significa que hay cuatro sistemas operativos completos presentes en esa infraestructura de host y esto puede suponer una gran carga para los recursos del sistema y el espacio en disco necesario.
Compare eso con el enfoque basado en contenedores a la derecha. Aquí, el kernel y los recursos del sistema operativo host son compartidos directamente por los contenedores a través del demonio Docker. Esto significa que los contenedores son mucho más livianos que una máquina virtual, lo que significa que puede ejecutar muchos más de ellos en la misma cantidad de hardware.
Ahora los contenedores vistos en el ejemplo anterior se habrán creado a partir de una imagen. Una imagen es una plantilla de solo lectura con instrucciones para crear un contenedor de Docker. Las imágenes en sí mismas se basan en el concepto de capas, cada capa se basa en la capa debajo de ella. Este concepto significa que hace que sea muy simple personalizar las imágenes existentes para desarrollar su funcionalidad personalizada.
Si observa la imagen anterior, puede ver que la imagen de Sitecore® Experience Platform™ (XP) se basa en la imagen 4.8-windowsservercore-ltsc2019. Tomamos la imagen de Windows Server Core lanzada por Microsoft y agregamos una capa personalizada encima de ella para incluir el código de Sitecore. Esta podría ser una imagen para crear un rol de administración de contenido (CM) o un rol de entrega de contenido (CD), pero el concepto sigue siendo el mismo.
También podemos tomar esa imagen de Sitecore XP y construir sobre ella para proporcionar más funcionalidad. La imagen del medio que se muestra arriba toma la imagen de XP y, a continuación, coloca Sitecore PowerShell Extensions (SPE) en la parte superior. El diagrama de la derecha lleva esto un paso más allá, utilizando la imagen SPE que acabamos de crear y agregando una capa para Sitecore Experience Accelerator (SXA) además de eso.
El poderoso concepto con el enfoque en capas es que estas capas se comparten. Por lo tanto, esa imagen de Windows Server Core con la que comenzamos solo necesita existir en el disco una vez, y las tres imágenes anteriores se basan en ella.
Puede leer una buena descripción general de Docker, sus casos de uso y la arquitectura de la aplicación en Documentos de Docker.
Quizás se pregunte de dónde provienen originalmente todas estas imágenes. Bueno, se almacenan en registros — Puede tener registros públicos o privados. El registro público más popular es Docker Hub. ¡Allí, puede encontrar imágenes para casi cualquier software moderno que se le ocurra! Para llevar una imagen a su máquina local, usaría un comando de extracción de Docker, p. ej.
docker pull mcr.microsoft.com/dotnet/samples:dotnetappEste comando desplegará la imagen mcr.microsoft.com/dotnet/core/samples que tiene la etiqueta dotnetapp. Una vez que se ha extraído, puede usarlo localmente para crear contenedores basados en él. Para hacer eso, usaría un simple comando de ejecución de Docker, por ejemplo,
docker run mcr.microsoft.com/dotnet/samples:aspnetappPuede leer más sobre los registros en Documentos de Docker.
Los volúmenes son otro de los conceptos clave a la hora de trabajar con contenedores. Hay muchas ocasiones en las que es útil compartir archivos entre el host y el contenedor. Un par de buenos ejemplos de esto son:
Se crean volúmenes para resolver este problema : le permiten designar una carpeta en la máquina host para que se comparta y esté disponible en el contenedor. Esta es una característica poderosa, ya que cualquier cambio que realice en el contenido del volumen se refleja instantáneamente dentro del contenedor.
Puede leer más sobre los volúmenes en Documentos de Docker.
El último concepto clave a cubrir aquí es la creación de redes. Una de las razones por las que los contenedores y servicios de Docker son tan poderosos es que puede conectarlos en una red interna creada por el demonio de Docker. Un buen ejemplo de esto sería un sistema compuesto por una aplicación .NET Core con un back-end de SQL Server. En este escenario, puede poner en marcha dos contenedores, uno que contenga la aplicación de .NET Core y el otro que contenga SQL Server, y hacer que Docker cree una red entre los dos para permitir que se comuniquen entre sí.
Puede leer más sobre la creación de redes en Documentos de Docker.
El sitio web de Docker tiene un gran conjunto de tutoriales para que pueda comenzar a usar Docker para el desarrollo de su aplicación, que puede ver aquí:
¡Gracias por leer y asegúrate de seguir #LearnSitecore para contenido futuro!
Rob Earlam, evangelista técnico, Sitecore
https://robearlam.com/