En la era de los DevOps ganadores, los desarrolladores simplemente están obligados a saber acerca de los contenedores Docker, por qué son necesarios y cómo trabajar con ellos. Esto facilita enormemente el trabajo. Además, incluso aquellos que trabajan con .Net Core en el entorno de desarrollo de Visual Studio 2017 pueden sentir todo el poder de la contenedorización. Pavel Skiba, jefe del departamento de desarrollo de aplicaciones de servidor en la reunión
Panda-Meetup C # .Net , habló sobre las herramientas disponibles y la configuración de Docker para VS.
¿Qué debe poder hacer un desarrollador? "Programa", respondes y ... Adivina. Pero si antes la lista de conocimientos necesarios terminaba con esto, ahora en la era de DevOps apenas está comenzando. Cuando escribimos código, definitivamente necesitamos conocer la estructura de la red: qué interactúa con qué. Se requiere soporte para varios lenguajes de programación a la vez, y se pueden escribir diferentes piezas de código en un proyecto en cualquier cosa.
Necesitamos saber cómo deshacer el software si se detecta un error. Necesitamos administrar configuraciones para diferentes entornos utilizados en la empresa; estos son al menos varios entornos de desarrollo, entornos de prueba y combate. Ah, sí, aún necesita comprender los scripts en diferentes servidores / sistemas operativos, porque no todo se puede hacer usando código, a veces tiene que escribir scripts.
Necesitamos conocer los requisitos de seguridad, y se están volviendo más difíciles y consumen mucho tiempo del desarrollador. No se olvide del soporte y desarrollo de software relacionado: Git, Jenkins, etc. Como resultado, el desarrollador puede simplemente no tener suficiente tiempo para un desarrollo puro.
Que hacer Hay una salida, y se encuentra en los contenedores Docker y su sistema de gestión. Una vez que implemente todo este complejo coloso, y usted, como en los viejos tiempos, solo volverá a escribir código. Todo lo demás será controlado por otras personas o por el propio sistema.
Entendemos contenedores
¿Qué es un contenedor acoplable? Esta es una estructura que consta de varias capas. La capa superior es la capa binaria de su aplicación. La segunda y tercera capas ahora están integradas en .Net Core, el contenedor ya es SDK-shny. La siguiente capa depende del sistema operativo en el que se implementa el contenedor. Y la capa inferior es el sistema operativo en sí.
En el nivel inferior, se implementa Windows Nanoserver. Este es un apretón mega recortado de Windows Server, que no puede hacer nada más que mantener un programa de utilidad implementado. Pero su volumen es 12 veces menor.
Si comparamos los servidores y contenedores físicos y virtuales, los beneficios de este último son obvios.
Cuando todo funcionaba en servidores físicos, nos enfrentamos a un montón de problemas. No hubo aislamiento en los códigos de la biblioteca; algunas aplicaciones podrían interferir entre sí. Por ejemplo: una aplicación funcionó en .Net 1.1 y otra en .Net 2.0. Muy a menudo, esto condujo a la tragedia. Después de un tiempo, aparecieron los servidores virtuales, se resolvió el problema del aislamiento, no había bibliotecas compartidas. Es cierto que, al mismo tiempo, se volvió muy costoso en términos de recursos y mano de obra: era necesario controlar todo el tiempo cuántas máquinas virtuales giran en una máquina virtual, en Hyper-V y en una pieza de hierro.
Los contenedores fueron diseñados para ser una solución económica y conveniente, mínimamente dependiente del sistema operativo. Veamos en qué se diferencian. Los servidores virtuales dentro del sistema se encuentran aproximadamente así.
La capa inferior es el servidor host. Puede ser físico o virtual. La siguiente capa es cualquier sistema operativo con virtualización, arriba hay un hipervisor. En la parte superior están los servidores virtuales que se pueden dividir en SO y aplicaciones invitados. Es decir, debajo de cada servidor virtual, se implementa un sistema operativo invitado en la parte superior del sistema operativo, y esto es una pérdida adicional de recursos.
Veamos cómo se encuentran los contenedores de Linux en el sistema.
Como puede ver, los archivos binarios con aplicaciones se ubican inmediatamente sobre el servidor host y el sistema operativo. No se necesita SO huésped, se liberan recursos, no se necesitan licencias para SO huésped.
Los contenedores de Windows son ligeramente diferentes de Linux.
Las capas básicas son las mismas: infraestructura, sistema operativo host (pero ahora Windows). Pero los contenedores pueden funcionar directamente con el sistema operativo o implementarse en la parte superior del hipervisor. En el primer caso, existe un aislamiento de procesos y espacios, pero utilizan el mismo núcleo con otros contenedores, que desde el punto de vista de la seguridad no es hielo. Si usa contenedores a través de Hyper-V, todo estará aislado.
Aprendizaje Docker para VS
Pasemos a Docker en sí. Supongamos que tiene Visual Studio y está instalando el cliente Docker para Windows por primera vez. En este caso, Docker desplegará el servidor demonio Docker, la interfaz en reposo para acceder a él y el propio cliente: la línea de comandos de Docker. Nos permitirá gestionar todo lo relacionado con los contenedores: red, imágenes, contenedores, capas.
La diapositiva muestra los comandos más simples: extraiga el contenedor Docker, ejecútelo, recopile, confirme y envíe de vuelta.
Docker está muy orgánicamente emparejado con Visual Studio. La captura de pantalla muestra un menú de panel de Visual Studio 2017. Docker compose support está integrado directamente en Intellisense, Dockerfile es compatible y todos los artefactos funcionan en la línea de comandos.
Curiosamente, podemos Docker depurar contenedores directamente en tiempo real. Y si sus contenedores están conectados entre sí, se debatirán inmediatamente de una vez y no necesitará ejecutar varios entornos.
¿Cómo se ensamblan los contenedores? El elemento principal aquí es el dockerfile, que contiene instrucciones para construir la imagen. Cada dockerfile se crea para cada proyecto. Indica: de dónde obtenemos la imagen básica, qué argumentos pasamos, cuál es el nombre del directorio de trabajo con archivos, puertos.
Este argumento fuente tiene dos parámetros. El segundo parámetro es la ruta a lo largo de la cual se colocará el resultado del ensamblaje en el proyecto, el valor se establece de forma predeterminada. En mi opinión, esta no es una muy buena opción. A menudo hay mucha basura en esta carpeta, debe limpiarse periódicamente, y cuando limpiamos esta carpeta, podemos frotar el ensamblaje. Por lo tanto, si lo desea, puede cambiarlo, lo establece el parámetro del sistema Docker_build_source, que también se puede modificar.
La instrucción Entrypoint le permite configurar el contenedor como un archivo ejecutable. Esta línea es necesaria para .Net Core, de modo que después de que el contenedor se inicie correctamente, envíe un mensaje "Su aplicación se está ejecutando" a la línea de comando.
Ahora sobre depuración de contenedores. Todo aquí es como un .Net normal, apenas notarás la diferencia. Muy a menudo, ejecuto .Net Core como autohospedado en dotnet.exe. Utiliza el depurador CLRDBG, la caché de paquetes NuGet y el código fuente.
ASP.Net 4.5+ está alojado por IIS o IIS Express, utiliza Microsoft Visual Studio Debugger y la fuente de la raíz del sitio en IIS.
Hay dos entornos para la depuración: depuración y liberación. La etiqueta de imagen de depuración está marcada como dev y la última versión. Al depurar, el argumento de origen se establece mejor en obj / Docker / empty, para no confundirse, pero cuando libera obj / Docker / Publish. Aquí puede usar los mismos binarios, vistas, la carpeta wwwroot y todas las dependencias que existen.
Mastering Docker Compose
Pasemos a la parte divertida: la herramienta de orquestación Docker-compose. Veamos un ejemplo: tiene algún tipo de servicio comercial que afecta a 5-6 contenedores. Y necesita arreglar de alguna manera cómo deben ensamblarse, en qué orden. Aquí es donde Docker-compose es útil, lo que proporcionará todo el ensamblaje, lanzamiento y escala de contenedores. Se gestiona de forma sencilla, todo lo recoge un equipo.
Docker-compose utiliza archivos YAML que almacenan la configuración de cómo se deben ensamblar los contenedores. Describen qué configuraciones debe usar para las imágenes, ensamblajes, servicios, volúmenes, redes y entornos. La sintaxis es idéntica para su publicación en clústeres. Es decir, una vez que escribieron dicho archivo, y si en el futuro será necesario implementar un servicio comercial en un clúster, no tendrá que agregar nada más.
Considere la estructura de un archivo YAML. La imagen es una imagen de Docker. Una imagen es un contenedor sin una capa de aplicación; es inmutable.
Build indica cómo construir, dónde construir y dónde implementar.
Depends_on - Depende de qué servicios depende.
Medio ambiente: aquí establecemos el medio ambiente.
Puertos: asignación de puertos en qué puerto estará disponible su contenedor.
Considera un ejemplo. Simplemente tenemos una API sin un servicio, esencialmente 3 contenedores: hay SQL.data en Linux, hay una aplicación en sí misma, depende de webapi y webapi depende de SQL.data.
No importa en qué orden se escriben los componentes en el archivo. Si todo se describe correctamente, Compose generará automáticamente esta información en función de las dependencias del proyecto. Este archivo es suficiente para recopilar todos los contenedores a la vez, la salida será una versión finalizada.
Hay una especie de "contenedor contenedor", un contenedor especial docker-compose.ci.build.yml, en el que se ensambla toda la composición. Puede ejecutar este contenedor especial desde la línea de comandos de Visual Studio, y podrá completar el ensamblaje en un servidor de compilación, por ejemplo, en Jenkins.
Echa un vistazo dentro del archivo. El ejemplo contiene el directorio de trabajo y de dónde viene. Restaura el proyecto desde GIT, publica esta solución él mismo, configura Release y carga el resultado. Ese es todo el equipo para construir, nada más necesita ser escrito. Es suficiente registrarlo una vez, y luego comenzar la publicación con un botón.
¿A qué más vale la pena prestarle atención? Docker-compose para cada entorno recopila imágenes, para cada configuración un archivo separado. Para cada configuración en Visual Studio hay un archivo con la configuración que necesita para el entorno.
Directamente desde VS, puede comenzar de forma remota a depurar toda la composición.
Orquestadores de racimo
Finalmente, tocamos temas como los orquestadores de clúster. No debemos pensar en cómo continúan existiendo los contenedores, qué personas o sistemas se gestionan. Para esto, hay 4 de los sistemas de administración de contenedores más populares: Google Kubernetes, Mesos DC / OS, Docker Swarm y Azure Service Fabric. Le permiten gestionar el agrupamiento y la composición de los contenedores.
Estos sistemas pueden hacer frente a una enorme capa de microservicios, proporcionándoles todo lo necesario. El desarrollador solo necesitará configurar esta capa una vez.
La versión completa del rendimiento en Panda Meetup está disponible a continuación.
Para aquellos que quieran profundizar en el tema, les aconsejo que estudien los siguientes materiales:
Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com
Y finalmente, un consejo importante de la práctica: lo más difícil es recordar dónde está lo que hay.
La documentación cuando trabaje con contenedores acoplables caerá sobre sus hombros. Sin documentación, olvidará en qué contenedor está conectado qué y qué funciona. Cuantos más servicios, mayor es la red total de conexiones.