Teníamos muchas preguntas al final de la sesión, y no hubo tiempo suficiente para responderlas todas. Aquí están las preguntas que se perdieron.
Q. Dijiste que puedes ejecutar tu aplicación de votación en tu portátil, pero es una mezcla de contenedores de Linux y Windows. Eso no funcionará, ¿verdad?
A. No, no puedes hacer funcionar una mezcla de contenedores de Linux y Windows en una sola máquina. Necesitas tener un clúster que ejecute Docker Swarm con una mezcla de servidores Linux y Windows para hacerlo. La aplicación de votación de ejemplo tiene diferentes versiones, por lo que puede funcionar en todos los entornos de Linux, todos los de Windows o híbridos.
Q. ¿Compilar [tus aplicaciones de origen usando contenedores Docker] con qué? ¿MSBuild en este caso?
A. Sí, escribes un Dockerfile multi-etapa donde la primera etapa compila tu aplicación. Esa etapa usa una imagen Docker que tiene tu conjunto de herramientas ya desplegadas. Microsoft tiene imágenes SDK de .NET Framework e imágenes Core de .NET, y hay imágenes Docker oficiales para otras plataformas como Go, y Maven para Java. Puedes construir tu propia imagen SDK y empaquetar las herramientas que necesites.
Q. ¿Cómo mantenemos sesiones pegajosas con el enjambre de Docker o Kubernetes si la aplicación heredada está instalada en el cluster?
A. Tendrás un balanceador de carga en tus nodos de clúster, así que el tráfico podría llegar a cualquier servidor, y entonces podrías estar ejecutando múltiples contenedores en ese servidor. Ni Docker Swarm ni Kubernetes proporcionan afinidad de sesión a los contenedores de forma inmediata, pero puede hacerlo ejecutando un proxy inverso como Traefik o un controlador de entrada con conocimiento de sesión para Kubernetes como Nginx.
Q. ¿Cómo funcionan los diferentes requisitos del sistema operativo cuando se realizan pruebas en un escritorio? (por ejemplo, algunos contenedores necesitan Linux, otros necesitan Windows, y se utiliza un Mac para el desarrollo)
A. Los contenedores son tan eficientes porque utilizan el sistema operativo subyacente del host en el que se están ejecutando. Esto significa que los contenedores Linux necesitan ejecutarse en un host Linux y los contenedores Windows en un host Windows. Docker Desktop lo hace fácil – aprovisiona y gestiona una VM Linux para usted. Docker Desktop para Mac solo te permite ejecutar contenedores Linux, pero Docker Desktop para Windows es compatible con Windows y Linux.
Q. ¿Cómo encajan los IDEs en Docker (por ejemplo, asegurándose de que todos los miembros del equipo de desarrollo están usando configuraciones IDE compatibles)?
A. La belleza de compilar y empaquetar tus aplicaciones de origen usando Docker es que no importa qué IDEs esté usando la gente. Cuando los desarrolladores prueben la aplicación localmente, la construirán y ejecutarán usando contenedores Docker con los mismos scripts de construcción que usa la IC. Así que la compilación es consistente, y el equipo no necesita usar el mismo IDE – la gente podría usar Visual Studio, VS Code o Rider en el mismo proyecto.
Q. ¿Cuál es la mejor manera de orquestar los contenedores de Windows?
A. Ahora mismo sólo Docker Swarm soporta los nodos de Windows en producción. Puedes unir varios servidores Windows junto con Docker Swarm o aprovisionar un clúster mixto Linux-Windows con Docker Enterprise. Se espera que el soporte de los nodos Windows por parte de los Kubernetes llegue a GA a finales de 2018.
Q. ¿Necesito un hipervisor para gestionar el hardware subyacente en el que funciona mi entorno Docker? Mejor aún, ¿el uso de Docker obvia la necesidad de VMware?
A. Docker puede funcionar con metal desnudo o con un VM. Un servidor Docker de producción sólo tiene un mínimo de sistema operativo instalado (digamos Ubuntu Server o Windows Server Core) y Docker funcionando.
Q. ¿Puede el SQL Server que se ejecuta en un contenedor utilizar la autenticación de Windows?
A. Sí. Los contenedores no están unidos al dominio de forma predeterminada, pero puede ejecutarlos con una especificación de credenciales, lo que significa que pueden acceder a AD utilizando las credenciales de una cuenta de servicio gestionada por grupos.
Q. ¿Algún consejo para construir/compilar Java dentro del contenedor… para los antiguos dependientes del IDE de Eclipse?
A. Necesitas llegar al punto en el que puedas construir tu aplicación a través de scripts sin ningún tipo de IDE. Si puedes migrar tu compilación para usar Maven (por ejemplo), entonces puedes compilar y empaquetar con tu configuración de Maven en el Dockerfile.
Q. Entonces, ¿el servidor tiene que tener todas las aplicaciones que los contenedores necesitarán? ¿Qué pasa si el servidor no tiene alguna aplicación que el contenedor necesita?
A. No, ¡exactamente lo contrario! La imagen del Docker es el paquete que tiene todo lo que el contenedor necesita. Así que, una aplicación ASP.NET en una imagen Docker tendrá el .NET Framework, IIS y ASP.NET instalados y no necesitas ninguno de esos componentes instalados en el servidor que está ejecutando el contenedor.
Q. Si necesitas varias tecnologías para ejecutar tu aplicación, ¿cómo creas una imagen Docker que las soporte en un solo paquete? ¿Y si necesitas una pila de tecnología específica que no está fácilmente disponible?
A. La imagen de tu aplicación necesita todos los requisitos previos para la aplicación instalada. Puedes usar una imagen existente si eso te da todo lo que necesitas o construir la tuya propia. Siempre que puedas hacer un script, puedes ponerlo en un Dockerfile, de modo que un Dockerfile de Windows podría usar Chocolatey para instalar dependencias.
Q. ¿Cómo decide Docker qué bibliotecas/tiempo de funcionamiento formarán parte del contenedor? ¿Cómo se demarca entre el sistema operativo y otro tiempo de ejecución?
A. Docker no decide eso. Depende de quien construya la imagen de la aplicación. El objetivo es hacer que la imagen en tiempo de ejecución sea lo más pequeña posible con sólo las dependencias que la aplicación realmente necesita. Eso te da una superficie más pequeña para los ataques y reduce el tiempo de construcción e implementación.