Creativa - Fotolia

Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Supere obstáculos de portabilidad de apps en los contenedores de nube

Los contenedores tienen muchos beneficios para el desarrollo de aplicaciones, incluyendo un mayor rendimiento, en un tamaño menor. Pero algunos obstáculos obstaculizan la perfecta portabilidad de contenedores.

Los contenedores se ven como una mejor manera que las máquinas virtuales tradicionales de encapsular y administrar aplicaciones en la infraestructura compartida. Permiten a los desarrolladores lograr más rendimiento de las aplicaciones en un tamaño menor, y puede aumentar la portabilidad de aplicaciones y ayudar a facilitar el paso a la nueva infraestructura. Sin embargo, los datos y servicios envueltos alrededor de esos contenedores a menudo resultan menos portátiles que el propio contenedor.

El uso de contenedores a menudo comienza en entornos locales, donde se garantiza la portabilidad de aplicaciones a través de una pila homogénea de contenedores. Pero, a medida que más organizaciones recurren a los contenedores en la computación en nube, hay servicios en el mercado que pueden ayudar, incluido el servicio de contenedores elásticos (ECS) de Amazon Web Services (AWS), el servicio contenedor de Microsoft Azure y Google Container Engine (GKE). Si bien cada uno de estos utiliza el formato de imagen de Docker, los otros servicios en el ecosistema de contenedor –registro de imágenes, gestor de clúster, servicio de descubrimiento y almacenamiento persistente– no son necesariamente compatibles.

A continuación, se presentan algunas barreras significativas a la portabilidad sin problemas con contenedores, en la computación de nube.

Bloqueos persistentes entre plataformas en la nube

Los contenedores de aplicaciones están diseñados para ser módulos descartables sin estado que se despliegan rápida y consistentemente. Sin embargo, la mayoría de las aplicaciones no son sin estado; requieren acceso a datos persistentes que viven fuera del contenedor. Hay varias maneras de incorporar almacenamiento en un contenedor, más comúnmente almacenamiento local en un clúster de contenedores, con un plug-in de almacenamiento colocado dentro de la imagen del contenedor. Las opciones típicas incluyen volúmenes de almacenamiento conectables Docker con soporte para plug-ins como EMC libStorage, Flocker del ya desaparecido ClortHQ, y otros.

El alojamiento en nube pública hace más complicado el acceso a datos persistentes, ya que cada plataforma de nube tiene un conjunto diferente de servicios de almacenamiento. Por ejemplo, Azure admite el complemento de volumen Docker para su uso con el servicio Azure File Storage. Del mismo modo, AWS ECS admite la capacidad de almacenar datos de configuración de contenedor en Amazon Simple Storage Service, que se leen en tiempo de ejecución, pero no se pueden modificar. Sin embargo, también permite el uso de volúmenes de datos persistentes al crear definiciones de tareas de ECS.

Google Cloud proporciona una forma más flexible de interactuar con discos persistentes de GKE utilizando su gestor de clústeres Kubernetes para crear una abstracción de volumen que se comparte entre las instancias de contenedor en un pod –un host específico de aplicación para uno o más contenedores– y que sobrevive al reinicio del contenedor. El problema con todas estas no es solo que son diferentes, sino que los datos persistentes están vinculados a un servicio en la nube, creando fricción cuando una aplicación en contenedores debe moverse.

El soporte para contenedores de Windows también crea un obstáculo potencial para la portabilidad con contenedores en la computación en nube. Aunque Docker fue construido originalmente en y para Linux, el motor ha sido portado a Windows para ejecutar contenedores de Windows. Como era de esperarse, Azure está desarrollando soporte para contenedores de Windows; sin embargo, en el momento de la publicación, esto todavía estaba en desarrollo y actualmente en vista previa. Asimismo, el soporte de AWS para contenedores de Windows es limitado y está en versión beta. Aunque Google Cloud permite a los equipos de TI ejecutar contenedores de Windows en instancias de Compute Engine, el servicio de contenedor GKE administrado, no. Las diferencias en las características y la implementación dificultan el transporte de contenedores de Windows a través de las plataformas de infraestructura.

Problemas de soporte de gestión de contenedores

Otro elemento que complica la portabilidad de los contenedores es el ecosistema de software que soporta la gestión de contenedores, incluyendo el software de gestión de clúster y de orquestación, y los registros de contenedores. Hay varios productos de administración de clúster populares que automatizan la colocación de contenedores, la escalabilidad de instancias y las actualizaciones de software, cada una de las cuales utiliza semántica diferente para scripts de automatización. Por ejemplo, tanto Docker Compose para modo swarm, como Kubernetes utilizan archivos YAML para descripciones de implementación; sin embargo, la sintaxis y las capacidades varían. Y el marco meta Mesos Marathon utiliza JSON para definir aplicaciones en contenedor.

Además, varios registros de contenedores están típicamente compuestos de un repositorio de imágenes y una forma de buscar y descubrir una imagen o microservicio. Los procesos de construcción y los scripts de automatización en torno a un conjunto de herramientas de gestión de contenedores y software de registro ayudan a maximizar los beneficios de la eficiencia de la contenerización, pero también dificultan la migración a otra plataforma. Es fácil mover las cargas de trabajo, es decir, las imágenes, pero no los procesos circundantes.

Cuando se utilizan contenedores en la computación en nube, la tendencia es integrar imágenes de contenedores agnósticas de nube con servicios específicos de la nube. Por ejemplo, si una empresa utiliza AWS ECS para implementar una instancia, tendría que utilizar los anzuelos ECS propietarios. Esto empuja al equipo de TI aún más hacia servicios específicos de AWS que probablemente no son compatibles fuera de esa plataforma.

La incoherente seguridad de contenedores crea obstáculos

Al ejecutar una infraestructura híbrida, es difícil mantener políticas de seguridad coherentes. Esto no es diferente con los contenedores.

Como con cualquier infraestructura virtualizada, la seguridad del contenedor está vinculada a un directorio de usuario o grupo subyacente, y al sistema de administración de identidades que sostiene los controles de acceso y las políticas de uso. Ya sea que se trate de un directorio de protocolo de acceso a directorios ligero local, como Active Directory, o un servicio en la nube como Google Cloud Identity y Access Management, nunca es fácil integrar identidades y reglas de seguridad entre plataformas.

Mejores prácticas para la portabilidad de contenedores entre nubes

Los problemas con la imagen de la aplicación rara vez dificultan la portabilidad de contenedores entre nubes, especialmente cuando todos los principales proveedores de software y de nube han adoptado la Open Container Initiative (OCI). Sin embargo, la OCI hace hincapié en que la especificación no está vinculada a una construcción de nivel superior como un cliente o una pila; características como el nombre y la distribución dentro de la especificación están fuera del alcance.

Para maximizar la portabilidad de los contenedores en la computación en nube, construya un diseño híbrido, agnóstico de nube, que tenga un sistema de gestión y de orquestación de contenedores de ejecución local, imágenes de contenedor centralizadas, registro y motores de automatización. Estos sistemas pueden implementarse en múltiples infraestructuras de contenedores privados y públicos, entre ellos Docker, ECS y GKE, entre otros. Esencialmente, los equipos de TI deben utilizar la nube para el tiempo de ejecución del contenedor, pero no el ecosistema de desarrollo y de gestión.

Para los datos, existe una opción viable para crear un diseño híbrido en el que un estado persistente se almacena en una ubicación central que se puede sincronizar con varios servicios de tiempo de ejecución. Un complejo diseño de nube híbrida requiere que los equipos de TI dividan las funciones de las aplicaciones entre las nubes. Esto significa que algunos componentes –front-end web, lógica de negocios de middleware, motor de big data­– se ejecutarán en la nube pública y otros en una infraestructura propia.

Utilice contenedores en la computación de nube para lo que mejor saben hacer: crear funcionalidades de aplicaciones o microservicios bien enfocadas, sin tener que incorporar políticas de seguridad, datos y gobernanza. Segregue estrictamente la lógica de la aplicación de la gestión de la infraestructura y la automatización, y asegúrese de que las piezas de gestión de contenedores de un ecosistema de contenedores sean agnósticas respecto a la nube y la plataforma.

Próximos pasos

Más sobre contenedores:

¿Son los contenedores de Windows Server superiores a los contenedores de Hyper-V?

El controlador Photon es la siguiente pieza del rompecabezas de contenedores de VMware

Construir un entorno DevOps con microservicios y contenedores

Este artículo se actualizó por última vez en mayo 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close