Proveedor de servidores y redes en Chihuahua

Proveedor de servidores y redes en Chihuahua. Por ahora, es muy probable que haya oído hablar de los contenedores Docker, Docker y, con la introducción de Windows Server 2016, contenedores integrados de Windows Server.

Realmente creo que dentro de unos años los contenedores Docker se convertirán en el estándar de funcionamiento de sitios web, aplicaciones y otros sistemas, en lugar de depender de ejecutar máquinas virtuales (VM) para admitir aplicaciones.

El uso de Docker ha permitido la escalabilidad, el aislamiento y la seguridad, al tiempo que garantiza que las aplicaciones y los sistemas estén configurados correctamente con poco soporte desde el punto de vista de la implementación.

En comparación con la complejidad de configurar una VM y configurar todas las funciones necesarias, la simplicidad de la configuración Docker es muy beneficiosa. Del mismo modo que las solicitudes de máquinas físicas fueron gradualmente eliminadas a favor de las máquinas virtuales,

En este artículo me centraré en cómo aproveché un enfoque de contenedor, utilizando Windows Server 2016, compartiendo archivos y comunicaciones de socket con Windows Server Containers, para modernizar varias aplicaciones .NET.

Proporcionaré detalles sobre cómo utilicé Windows PowerShell para crear una imagen de Docker y compartir archivos y conexiones entre un sistema host de Windows Server 2016 y un contenedor de servidor de Windows. Es probable que muchas de sus aplicaciones tengan una funcionalidad común como esta que deba habilitar para asegurarse de que su aplicación .NET pueda ser portada a un contenedor Docker. Muchas de las funciones que reviso no son específicas de Windows Server Container y podrían aprovecharse para cualquier aplicación que tenga una funcionalidad similar.

The Business Challenge: una aplicación .NET de CPU, memoria y disco intensivo

El reto de mi negocio era modernizar varias aplicaciones de consola .NET y C ++ existentes, responsables de manejar grandes volúmenes de datos, lo que implicaba un procesamiento intensivo de CPU, memoria y disco. Necesitaba exponer estas aplicaciones de consola en un modelo web más tradicional donde el sistema migraría de un sistema de usuario único a una configuración compatible con varios usuarios. Teniendo en cuenta cómo se configuraron las aplicaciones y el volumen de datos que se procesan, no quería administrar varias copias de los datos o ejecutables en las máquinas virtuales.

Como parte de este desafío empresarial, necesitaba determinar cómo podía escalar mejor estas aplicaciones, así como minimizar la latencia de la red y la administración de archivos en toda la red. El rendimiento de las aplicaciones fue crítico, y cualquier uso de compartir en red, compartir archivos u otro procesamiento distribuido tendría un impacto significativo en su rendimiento. Por lo tanto, para que este desafío empresarial se considere exitoso, necesitaba proporcionar un modelo escalable que también produjera un alto nivel de rendimiento (con respecto a CPU, memoria y disco IO), sin tener que mantener copias múltiples de mis datos. Al igual que con la mayoría de los proyectos, la línea de tiempo para entregar una versión modernizada y escalable de estas aplicaciones fue muy limitada, eliminando la posibilidad de un rediseño completo.

Entérese: Fibra optica en México: en el Top10 de la OCDE

Características importantes: Uso compartido de archivos, Socket Connections y .NET en Docker

Para mis aplicaciones particulares, consideré varias opciones antes de aterrizar para usar Docker y, más específicamente, en contenedores de servidor de Windows. Como parte de mi evaluación, tuve tres desafíos técnicos muy específicos para probar a fin de migrar las aplicaciones con éxito a Docker:

Ejecutando una aplicación .NET tradicional en Docker.
Aprovechando el intercambio de archivos entre el sistema host y mi contenedor Docker.
Habilitar la comunicación de socket entre el host y el contenedor Docker.
Le mostraré en detalle cómo superar estos desafíos técnicos y cómo implementar los conceptos con Docker y Windows Server Containers que se ejecutan en Windows Server 2016. Los conceptos mismos son solo el comienzo al considerar cuántas de sus aplicaciones .NET podrían ser potencialmente migrado a Docker o Contenedores de Servidor de Windows. Los ejemplos que revisaré se pueden aplicar o ampliar de forma más amplia para abordar diversas características de la aplicación, lo que a su vez puede proporcionar a sus aplicaciones una implementación más moderna.

Rendimiento de la aplicación: 8 GB de RAM, 10 TB de procesamiento de archivos

Antes de profundizar en las opciones y los conceptos que considero, quiero proporcionar un poco más de detalle sobre las aplicaciones y sistemas que moví a los contenedores Docker. En primer lugar, las aplicaciones son bastante únicas en el tipo de trabajo que realizan, y son muy intensivas en procesos, memoria y disco. Además, la velocidad a la que se realizan las aplicaciones es fundamental para el éxito del sistema.

Mis aplicaciones, diseñadas principalmente para un solo usuario, realizan cálculos muy complejos al procesar archivos de datos y se crearon con una combinación de C ++ y .NET Framework. Para darle una idea de los desafíos de rendimiento de mi sistema, se necesitan aproximadamente 8 GB de RAM por usuario para realizar cálculos en archivos de datos de hasta 10 TB de tamaño, y requiere memoria preasignada y velocidades de disco extremadamente rápidas para procesar el gran tamaño volúmenes de datos en segundos. El sistema también usa conexiones de socket para la invocación y notificación del solicitante. A medida que evolucionaban las aplicaciones y los sistemas, descubrí que necesitaba una forma rápida de escalar el sistema y admitir el procesamiento de múltiples usuarios. Espero que muchos de ustedes puedan pensar en aplicaciones similares que podrían beneficiarse al ser trasladadas a un contenedor.

Opciones de solución: Reingeniería, Escala automática, Docker

Los desafíos técnicos que enfrenté implicaron evaluar las diferentes maneras en que podría lograr mis objetivos. Consideré tres opciones.

1.- Reingeniería: una opción era rediseñar todo el conjunto de aplicaciones. Esto seguramente funcionaría, pero dado el tamaño y la complejidad de mi sistema, necesitaba una solución que presentara menos riesgos y no tomara tanto tiempo en completarse. Esperar un año o incluso varios meses para rediseñar el sistema no sería aceptable. Sin embargo, aún era importante evaluar esta opción en caso de que pudiera llegar a ser una solución razonable.

Léase también: La neutralidad de la red

2.-Auto-Scaling: Otra opción fue evaluar cómo podía aprovechar las VM y escalar automáticamente. Esto definitivamente sería más rápido que reescribir la aplicación y disminuiría el riesgo general. Sin embargo, agregaría una gran sobrecarga debido al tiempo que llevaría asignar una máquina virtual, especialmente una máquina virtual con 10 TB de almacenamiento. Aunque pude encontrar soluciones para esto, como usar instancias en espera y luego manejar el aprovisionamiento y desaprovisionamiento de los servidores a través de una capa o aplicación adicional, todavía no parecía el mejor enfoque. Sin embargo, esta opción definitivamente me estaba moviendo en la dirección correcta porque no involucraba reingeniería de toda la aplicación y podía implementar múltiples ejecutables por VM y escalar las máquinas virtuales automáticamente.

3.-Contenedor Docker: la última opción que consideré fue usar Docker, con interoperabilidad entre el sistema host y los contenedores Docker. Usar contenedores Docker me permitiría escalar el sistema según sea necesario sin tener que rediseñar todo el sistema. Este enfoque disminuiría los riesgos involucrados con la reingeniería de la aplicación, proporcionaría un nivel de aislamiento por motivos de seguridad y me permitiría implementar estas actualizaciones rápidamente al mismo tiempo que proporcioné el nivel de escala que necesitaba.

Implementación de aplicaciones .NET con Docker

Los principales problemas que tuve con la opción Docker fue que la aplicación se escribió en .NET y C ++ y me preocupaba que mi aplicación no se pudiera ejecutar directamente en Docker. Tan pronto como comencé a investigar cómo migrar mis aplicaciones .NET / C ++ a Docker, aprendí que requeriría una actualización o rediseño. Teniendo en cuenta que mi enfoque tenía que ser rápido, comencé a aprender más sobre Windows Server 2016 y los contenedores de servidor de Windows totalmente integrados.

Al aprovechar Windows Server Containers, esperaba poder dejar la aplicación tal como está y desplegar todas las dependencias junto con la otra configuración requerida en mi contenedor.

El desafío técnico inicial que encontré fue que los contenedores tradicionales Docker para aplicaciones .NET requieren .NET Core.

Mientras que mi aplicación se escribió con .NET y C ++. Por supuesto, podría haber actualizado la aplicación a. NET Core, pero esto habría implicado un esfuerzo significativo y estaba tratando de implementar una solución lo más rápido posible con la menor cantidad de riesgo. También estaba tratando de garantizar que incluyera la capacidad de escalar, junto con un nivel de aislamiento y seguridad para mi aplicación.

Aunque el uso de Windows Server Containers empezaba a parecer muy prometedor, aún necesitaba probar una serie de conceptos diferentes, como compartir archivos y conexiones de socket, que también podría resultarle muy útil. Si bien gran parte de lo que describo es exclusivo de mi configuración en particular, las opciones y los conceptos no se pueden aprovechar para otros sistemas que necesitan este tipo de migración o escala sin tener que rediseñar o reescribir la aplicación. Por supuesto, este enfoque no reemplaza el rediseño de una aplicación, pero ofrece tiempo para que un equipo rediseñe la aplicación si esa es la dirección deseada. Como parte de ese rediseño, el equipo puede rediseñar la aplicación compatible o compatible con Docker.

Conócenos en Facebook