{"id":6041,"date":"2018-06-14T18:40:33","date_gmt":"2018-06-14T23:40:33","guid":{"rendered":"https:\/\/www.bhinfo.com.mx\/cursos\/?p=6041"},"modified":"2018-06-14T19:29:25","modified_gmt":"2018-06-15T00:29:25","slug":"contenedores-docker-windows-y-tendencias","status":"publish","type":"post","link":"https:\/\/www.bhinfo.com.mx\/cursos\/2018\/06\/14\/contenedores-docker-windows-y-tendencias\/","title":{"rendered":"Contenedores: Docker, Windows y Tendencias"},"content":{"rendered":"

Por: Mark Russinovich CTO, Microsoft Azure<\/strong><\/p>\n

No se puede debatir sobre la computaci\u00f3n en la nube \u00faltimamente sin hablar de contenedores. Las organizaciones de todos los segmentos comerciales, desde bancos y grandes empresas de servicios financieros hasta sitios de comercio electr\u00f3nico, quieren saber qu\u00e9 son los contenedores, qu\u00e9 significan para las aplicaciones en la nube y c\u00f3mo usarlos mejor para su desarrollo espec\u00edfico y escenarios de operaciones de TI. Desde los conceptos b\u00e1sicos de qu\u00e9 son los contenedores y c\u00f3mo funcionan, hasta los escenarios en los que se usan m\u00e1s ampliamente hoy, las tendencias emergentes que apoyan la \u00abcontenedorizaci\u00f3n\u00bb, pens\u00e9 que compartir\u00eda mis perspectivas para ayudarlo a comprender mejor c\u00f3mo abrazar mejor este importante desarrollo de la computaci\u00f3n en la nube para construir, probar, implementar y administrar sus aplicaciones en la nube de manera m\u00e1s uniforme.<\/p>\n

Resumen de contenedores<\/strong><\/h3>\n

En t\u00e9rminos abstractos, toda la inform\u00e1tica se basa en ejecutar alguna \u00abfunci\u00f3n\u00bb en un conjunto de recursos \u00abf\u00edsicos\u00bb, como procesador, memoria, disco, red, etc., para realizar una tarea, ya sea un c\u00e1lculo matem\u00e1tico simple, como 1+ 1, o una aplicaci\u00f3n compleja que abarca varias m\u00e1quinas, como Exchange. Con el tiempo, a medida que los recursos f\u00edsicos se hicieron m\u00e1s y m\u00e1s poderosos, a menudo las aplicaciones no utilizaban ni una fracci\u00f3n de los recursos proporcionados por la m\u00e1quina f\u00edsica. Por lo tanto, se crearon recursos \u00abvirtuales\u00bb para simular el hardware f\u00edsico subyacente, lo que permite que varias aplicaciones se ejecuten simult\u00e1neamente, cada una de las cuales utiliza fracciones de los recursos f\u00edsicos de la misma m\u00e1quina f\u00edsica. Com\u00fanmente nos referimos a estas t\u00e9cnicas de simulaci\u00f3n como virtualizaci\u00f3n. Si bien muchas personas piensan de inmediato en m\u00e1quinas virtuales cuando oyen virtualizaci\u00f3n, esa es solo una implementaci\u00f3n de la virtualizaci\u00f3n. La memoria virtual, un mecanismo implementado por todos los sistemas operativos de prop\u00f3sito general (OS), da a las aplicaciones la ilusi\u00f3n de que la memoria de una computadora est\u00e1 dedicada a ellas e incluso puede darle a una aplicaci\u00f3n la experiencia de tener acceso a mucha m\u00e1s RAM de la que la computadora tiene disponible. Los contenedores son otro tipo de virtualizaci\u00f3n, tambi\u00e9n conocida como virtualizaci\u00f3n del sistema operativo. Los contenedores de hoy en Linux crean la percepci\u00f3n de un sistema operativo totalmente aislado e independiente para la aplicaci\u00f3n. Para el contenedor en ejecuci\u00f3n, el disco local se ve como una copia pr\u00edstina de los archivos del sistema operativo, la memoria solo aparece para contener archivos y datos de un sistema operativo reci\u00e9n iniciado, y lo \u00fanico que se ejecuta es el sistema operativo. Para lograr esto, la m\u00e1quina \u00abhost\u00bb que crea un contenedor hace algunas cosas inteligentes. La primera t\u00e9cnica es el aislamiento del espacio de nombres. Los espacios de nombre incluyen todos los recursos con los que una aplicaci\u00f3n puede interactuar, incluidos los archivos, los puertos de red y la lista de procesos en ejecuci\u00f3n.El aislamiento del espacio de nombres permite que el host le d\u00e9 a cada contenedor un espacio de nombres virtualizado que incluye solo los recursos que deber\u00eda ver. Con esta vista restringida, un contenedor no puede acceder a los archivos no incluidos en su espacio de nombres virtualizado, independientemente de sus permisos, ya que simplemente no puede verlos. Tampoco puede listar o interactuar con aplicaciones que no forman parte del contenedor, lo que lo enga\u00f1a y le hace creer que es la \u00fanica aplicaci\u00f3n que se ejecuta en el sistema cuando puede haber docenas o cientos de otras. Para mayor eficiencia, muchos de los archivos del sistema operativo, directorios y servicios en ejecuci\u00f3n se comparten entre contenedores y se proyectan en el espacio de nombres de cada contenedor. Solo cuando una aplicaci\u00f3n realiza cambios en sus contenedores, por ejemplo modificando un archivo existente o creando uno nuevo, el contenedor obtiene copias distintas del sistema operativo host subyacente, pero solo se cambian esas partes, utilizando la funci\u00f3n de copiar y escribir de Docker. \u00abOptimizaci\u00f3n\u00bb Este intercambio es parte de lo que hace que la implementaci\u00f3n de m\u00faltiples contenedores en un \u00fanico servidor sea extremadamente eficiente. En segundo lugar, el host controla la cantidad de recursos del host que puede usar un contenedor. Los recursos gubernamentales, como la CPU, la RAM y el ancho de banda de la red, garantizan que un contenedor obtenga los recursos que espera y que no afecte el rendimiento de otros contenedores que se ejecutan en el host. Por ejemplo, un contenedor puede estar restringido para que no pueda usar m\u00e1s del 10% de la CPU. Eso significa que incluso si la aplicaci\u00f3n dentro de ella intenta, no puede acceder al otro 90%, que el host puede asignar a otros contenedores o para su propio uso. Linux implementa dicha gobernanza utilizando una tecnolog\u00eda llamada \u00abcgroups\u00bb. La gobernanza de recursos no es necesaria en casos donde los contenedores colocados en el mismo host son cooperativos, lo que permite la asignaci\u00f3n de recursos din\u00e1micos est\u00e1ndar del SO que se adapta a las demandas cambiantes del c\u00f3digo de la aplicaci\u00f3n.La combinaci\u00f3n de inicio instant\u00e1neo que proviene de la virtualizaci\u00f3n del sistema operativo y la ejecuci\u00f3n confiable que proviene del aislamiento del espacio de nombres y la administraci\u00f3n de los recursos hace que los contenedores sean ideales para el desarrollo y la prueba de aplicaciones. Durante el proceso de desarrollo, los desarrolladores pueden iterar r\u00e1pidamente. Debido a que su entorno y el uso de recursos son consistentes en todos los sistemas, una aplicaci\u00f3n en contenedor que funcione en un sistema de desarrollador funcionar\u00e1 de la misma manera en un sistema de producci\u00f3n diferente. El inicio instant\u00e1neo y el tama\u00f1o reducido tambi\u00e9n benefician a los escenarios en la nube, ya que las aplicaciones pueden escalar r\u00e1pidamente y muchas m\u00e1s instancias de aplicaci\u00f3n pueden caber en una m\u00e1quina que si estuvieran en una VM, lo que maximiza la utilizaci\u00f3n de recursos. Comparar un escenario similar que usa m\u00e1quinas virtuales con uno que usa contenedores resalta la eficiencia ganada por el intercambio. En el ejemplo que se muestra a continuaci\u00f3n, la m\u00e1quina host tiene tres m\u00e1quinas virtuales. Para proporcionar a las aplicaciones en el aislamiento completo de las m\u00e1quinas virtuales, cada una de ellas tiene sus propias copias de los archivos del sistema operativo, las bibliotecas y el c\u00f3digo de la aplicaci\u00f3n, junto con una instancia completa en la memoria de un sistema operativo. Iniciar una VM nueva requiere arrancar otra instancia del sistema operativo, incluso si el host o las VM existentes ya tienen instancias en ejecuci\u00f3n de la misma versi\u00f3n y cargar las bibliotecas de aplicaciones en la memoria. Cada VM de aplicaciones paga el costo del arranque del sistema operativo y la huella en memoria de sus propias copias privadas, lo que tambi\u00e9n limita el n\u00famero de instancias de aplicaciones (VM) que se pueden ejecutar en el host.<\/p>\n

Link<\/a><\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

La figura siguiente muestra el mismo escenario con contenedores. Aqu\u00ed, los contenedores simplemente comparten el sistema operativo del host, incluido el kernel y las bibliotecas, por lo que no necesitan iniciar un sistema operativo, cargar bibliotecas o pagar un costo de memoria privada para esos archivos. El \u00fanico espacio incremental que toman es la memoria y el espacio en disco necesarios para que la aplicaci\u00f3n se ejecute en el contenedor. Si bien el entorno de la aplicaci\u00f3n se siente como un sistema operativo dedicado, la aplicaci\u00f3n se despliega como lo har\u00eda en un host dedicado. La aplicaci\u00f3n en contenedor comienza en segundos y muchas m\u00e1s instancias de la aplicaci\u00f3n pueden caber en la m\u00e1quina que en la carcasa de VM.<\/p>\n

\"\"<\/a><\/p>\n

Apelaci\u00f3n de Docker<\/strong><\/h3>\n

El concepto de aislamiento del espacio de nombres y la gobernanza de los recursos relacionados con los SO ha existido durante mucho tiempo, volviendo a las C\u00e1rceles de BSD, a las Zonas de Solaris e incluso al mecanismo chroot (cambio de ra\u00edz) b\u00e1sico de UNIX. Sin embargo, al crear un conjunto de herramientas com\u00fan, un modelo de empaque y un mecanismo de implementaci\u00f3n, Docker simplific\u00f3 enormemente la contenedorizaci\u00f3n y distribuci\u00f3n de aplicaciones que luego pueden ejecutarse en cualquier lugar en cualquier host de Linux. Esta tecnolog\u00eda omnipresente no solo simplifica la administraci\u00f3n al ofrecer los mismos comandos de administraci\u00f3n contra cualquier host, sino que tambi\u00e9n crea una oportunidad \u00fanica para DevOps sin problemas. Desde el escritorio de un desarrollador hasta una m\u00e1quina de prueba y un conjunto de m\u00e1quinas de producci\u00f3n, se puede crear una imagen Docker que se implementar\u00e1 de manera id\u00e9ntica en cualquier entorno en segundos. Esta historia ha creado un ecosistema masivo y creciente de aplicaciones empaquetadas en contenedores Docker, con DockerHub, el registro p\u00fablico de aplicaciones en contenedores que Docker mantiene, que actualmente publica m\u00e1s de 180,000 aplicaciones en el repositorio comunitario p\u00fablico. Adem\u00e1s, para garantizar que el formato de empaquetado siga siendo universal, Docker organiz\u00f3 recientemente la Iniciativa de contenedor abierto (OCI), con el objetivo de garantizar que el empaquetado de los contenedores siga siendo un formato abierto y basado en fundaciones, con Microsoft como uno de los miembros fundadores.<\/p>\n

Servidor Windows y contenedores<\/strong><\/h3>\n

Para llevar el poder de los contenedores a todos los desarrolladores, en octubre pasado anunciamos planes para implementar tecnolog\u00eda de contenedores en Windows Server. Para permitir a los desarrolladores que usan contenedores Docker de Linux con la misma experiencia en Windows Server, tambi\u00e9n anunciamos nuestra asociaci\u00f3n con Docker para ampliar la API de Docker y el conjunto de herramientas para admitir Contenedores de servidor de Windows. Para nosotros, esta fue una oportunidad para beneficiar a todos nuestros clientes, tanto Linux como Windows por igual. Tal como lo demostr\u00e9 recientemente en DockerCon, estamos entusiasmados de crear una experiencia unificada y abierta para que los desarrolladores y administradores de sistemas implementen sus aplicaciones contenerizadas que incluyen Windows Server y Linux. Estamos desarrollando esto en el repositorio Docker GitHub abierto. En Windows Server 2016, lanzaremos dos sabores de contenedores, los cuales se podr\u00e1n implementar utilizando las API de Docker y el cliente de Docker: Contenedores de Windows Server y Contenedores de Hyper-V. Los contenedores Linux requieren API de Linux del kernel de host y los contenedores de servidor de Windows requieren las API de Windows de un Kernel de Windows host, por lo que no puede ejecutar contenedores Linux en un servidor de Windows Server o un contenedor de servidor de Windows en un host de Linux. Sin embargo, el mismo cliente de Docker puede administrar todos estos contenedores, y aunque no puede ejecutar un contenedor de Windows empaquetado en Linux, un paquete de contenedor de Windows funciona con Contenedores de Windows Server y Contenedores de Hyper-V porque ambos utilizan el kernel de Windows. Existe la cuesti\u00f3n de cu\u00e1ndo es posible que desee utilizar un contenedor de servidor de Windows frente a un contenedor de Hyper-V. Si bien el intercambio de kernel permite una r\u00e1pida puesta en marcha y un embalaje eficiente, los contenedores de servidor de Windows comparten el sistema operativo con el host y entre ellos. La cantidad de datos compartidos y API significa que puede haber formas, ya sea por dise\u00f1o o debido a un error de implementaci\u00f3n en el aislamiento del espacio de nombres o la gobernanza de los recursos, para que una aplicaci\u00f3n escape de su contenedor o niegue el servicio al host u otros contenedores. La elevaci\u00f3n local de vulnerabilidades de privilegios que el parche de proveedores de sistemas operativos es un ejemplo de un defecto que una aplicaci\u00f3n podr\u00eda aprovechar. Por lo tanto, los contenedores de servidor de Windows son ideales para escenarios donde el sistema operativo conf\u00eda en las aplicaciones que se alojar\u00e1n en \u00e9l, y todas las aplicaciones tambi\u00e9n conf\u00edan entre s\u00ed. En otras palabras, el sistema operativo host y las aplicaciones se encuentran dentro del mismo l\u00edmite de confianza. Eso es cierto para muchas aplicaciones de varios contenedores, aplicaciones que componen un servicio compartido de una aplicaci\u00f3n m\u00e1s grande y, a veces, aplicaciones de la misma organizaci\u00f3n. Sin embargo, hay casos donde es posible que desee ejecutar aplicaciones desde diferentes l\u00edmites de confianza en el mismo host. Un ejemplo es si est\u00e1 implementando una oferta PaaS o SaaS multiusuario donde permite que sus clientes suministren su propio c\u00f3digo para extender la funcionalidad de su servicio. No desea que el c\u00f3digo de un cliente interfiera con su servicio u obtenga acceso a los datos de sus otros clientes, pero necesita un contenedor que sea m\u00e1s \u00e1gil que una VM y que aproveche el ecosistema de Docker. Tenemos varios ejemplos de dichos servicios en Azure, como Azure Automation y Machine Learning. Llamamos al entorno que ellos manejan en \u00abmulti-tenencia hostil\u00bb, ya que tenemos que suponer que hay clientes que deliberadamente buscan subvertir el aislamiento. En este tipo de entornos, el aislamiento de los Contenedores de Servidor de Windows puede no proporcionar la seguridad suficiente, lo que motiv\u00f3 nuestro desarrollo de Contenedores de Hyper-V. Los contenedores Hyper-V adoptan un enfoque ligeramente diferente a la contenedorizaci\u00f3n. Para crear un mayor aislamiento, los contenedores de Hyper-V tienen cada uno su propia copia del kernel de Windows y tienen memoria asignada directamente a ellos, un requisito clave de un fuerte aislamiento. Usamos Hyper-V para CPU, memoria y aislamiento IO (como red y almacenamiento), ofreciendo el mismo nivel de aislamiento que se encuentra en las m\u00e1quinas virtuales. Al igual que para las VM, el host solo expone una interfaz peque\u00f1a y restringida al contenedor para la comunicaci\u00f3n y el intercambio de recursos de host. Esta compartici\u00f3n muy limitada significa que los Contenedores Hyper-V tienen menos eficiencia en tiempos de inicio y densidad que los Contenedores de Servidor de Windows, pero el aislamiento requerido para permitir que las aplicaciones no confiables y \u00abhostiles multi-tenant\u00bb se ejecuten en el mismo host. Entonces, \u00bfno son los Contenedores Hyper-V lo mismo que las m\u00e1quinas virtuales? Adem\u00e1s de las optimizaciones para el sistema operativo que resultan de que es totalmente consciente de que est\u00e1 en un contenedor y no en una m\u00e1quina f\u00edsica, Hyper-V Containers se implementar\u00e1 utilizando la magia de Docker y puede usar exactamente los mismos paquetes que se ejecutan en Windows Server Containers. Por lo tanto, la compensaci\u00f3n de nivel de aislamiento versus eficiencia \/ agilidad es una decisi\u00f3n de tiempo de implementaci\u00f3n, no una decisi\u00f3n de tiempo de desarrollo, una decisi\u00f3n tomada por el propietario del host.<\/p>\n

Orquestaci\u00f3n<\/strong><\/h3>\n

A medida que adoptaron contenedores, los clientes descubrieron un desaf\u00edo. Cuando implementan docenas, cientos o miles de contenedores que conforman una aplicaci\u00f3n, el seguimiento y la administraci\u00f3n de la implementaci\u00f3n requieren avances en la administraci\u00f3n y la orquestaci\u00f3n. Container orchestration se ha convertido en una nueva e interesante \u00e1rea de innovaci\u00f3n con m\u00faltiples opciones y soluciones. A los orquestadores de contenedores se les asigna un conjunto de servidores (VM o servidores bare metal), com\u00fanmente llamados \u00abcl\u00fasteres\u00bb, y \u00abprogramaci\u00f3n\u00bb la implementaci\u00f3n de contenedores en esos servidores. Algunos orquestadores van m\u00e1s all\u00e1 y configuran la conexi\u00f3n en red entre contenedores en diferentes servidores, mientras que algunos incluyen balanceo de carga, resoluci\u00f3n de nombre de contenedor, actualizaciones continuas y m\u00e1s. Algunos son extensibles y permiten que los marcos de aplicaci\u00f3n traigan estas capacidades adicionales. Si bien una discusi\u00f3n m\u00e1s profunda sobre las soluciones de orquestaci\u00f3n podr\u00eda requerir una publicaci\u00f3n completa por s\u00ed misma, aqu\u00ed hay un resumen breve de algunas de las tecnolog\u00edas, todas compatibles con Azure:<\/p>\n

Docker Compose permite la definici\u00f3n de aplicaciones simples de varios contenedores.<\/p>\n

Docker Swarm administra y organiza contenedores Docker en varios hosts a trav\u00e9s de la misma API utilizada por un solo host Docker.<\/p>\n

Swarm y Compose se unen para ofrecer una tecnolog\u00eda de orquestaci\u00f3n completa construida por Docker.<\/p>\n

Mesos es una soluci\u00f3n de orquestaci\u00f3n y administraci\u00f3n que, en realidad, es anterior a Docker, pero recientemente agreg\u00f3 soporte para Docker en su marco de aplicaciones integrado Marathon. Es una soluci\u00f3n abierta y dirigida por la comunidad construida por Mesosphere. Recientemente demostramos la integraci\u00f3n con Mesos y DCOS en Azure.<\/p>\n

Kubernetes es una soluci\u00f3n de c\u00f3digo abierto creada por Google que ofrece agrupaci\u00f3n de contenedores en \u00abPods\u00bb para la gesti\u00f3n en m\u00faltiples hosts. Esto tambi\u00e9n es compatible con Azure.<\/p>\n

Deis es una plataforma de c\u00f3digo abierto de PaaS para implementar y administrar aplicaciones integradas con Docker. Tenemos una manera f\u00e1cil de implementar un cl\u00faster Deis en Azure.<\/p>\n

Nos entusiasma contar con el respaldo de Azure para la mayor\u00eda de las soluciones de orquestaci\u00f3n populares y esperamos involucrarnos m\u00e1s en estas comunidades a medida que aumenta el inter\u00e9s y el uso con el tiempo.
\n <\/p>\n

Microservicios<\/strong><\/h3>\n

El uso m\u00e1s inmediato y lucrativo para los contenedores se ha centrado en simplificar DevOps con un desarrollador f\u00e1cil para probar los flujos de producci\u00f3n de los servicios desplegados en la nube o en las instalaciones. Pero hay otro escenario en crecimiento donde los contenedores se vuelven muy convincentes. Microservicios es un enfoque para el desarrollo de aplicaciones donde cada parte de la aplicaci\u00f3n se implementa como un componente completamente aut\u00f3nomo, llamado microservicio que se puede escalar y actualizar de forma individual. Por ejemplo, el subsistema de una aplicaci\u00f3n que recibe solicitudes de Internet p\u00fablico puede estar separado del subsistema que pone la solicitud en una cola para que un subsistema de fondo pueda leerla y colocarla en una base de datos. Cuando la aplicaci\u00f3n se construye utilizando microservicios, cada subsistema es un microservicio. En un entorno de desarrollo \/ prueba en un solo cuadro, los microservicios pueden tener una sola instancia, pero cuando se ejecutan en producci\u00f3n, cada uno puede escalar a diferentes n\u00fameros de instancias en un cl\u00faster de servidores seg\u00fan las demandas de recursos a medida que aumentan y disminuyen los niveles de solicitud del cliente. . Si los diferentes equipos los producen, los equipos tambi\u00e9n pueden actualizarlos de manera independiente. Microservicios no es un nuevo enfoque de programaci\u00f3n, ni est\u00e1 vinculado expl\u00edcitamente a contenedores, pero los beneficios de los contenedores Docker se magnifican cuando se aplican a una aplicaci\u00f3n compleja basada en microervicios. Agilidad significa que un microservicio puede escalar r\u00e1pidamente para cumplir con una mayor carga, el espacio de nombres y el aislamiento de recursos de contenedores evita que una instancia de microservicio interfiera con otros, y el uso del formato de empaque Docker y las API desbloquean el ecosistema Docker para el desarrollador de microservicios y el operador de aplicaciones . Con una buena arquitectura de microservicio, los clientes pueden resolver las necesidades de administraci\u00f3n, implementaci\u00f3n, orquestaci\u00f3n y parcheo de un servicio basado en contenedores con un menor riesgo de p\u00e9rdida de disponibilidad y al mismo tiempo mantener una gran agilidad. Hoy en d\u00eda existen varias soluciones para crear modelos de aplicaciones que utilizan microservicios y nos asociamos con muchos de ellos en Azure. Docker Compose y Mesosphere Marathon son dos ejemplos. Poco antes de \/\/ build, anunciamos y luego lanzamos una vista previa de desarrollador de Service Fabric, nuestra propia plataforma de aplicaciones de microservicios. Incluye una amplia colecci\u00f3n de capacidades de administraci\u00f3n del ciclo de vida de microservicios, incluida la actualizaci\u00f3n continua con reversiones, particiones, restricciones de ubicaci\u00f3n y m\u00e1s.
\nCabe destacar que, adem\u00e1s de los microservicios sin estado, es compatible con microservicios con estado, que se diferencian por el hecho de que el microservicio administra los datos que conviven con \u00e9l en el mismo servidor. De hecho, Service Fabric es la \u00fanica plataforma PaaS que ofrece microservicios con estado con administraci\u00f3n de estado y marcos de replicaci\u00f3n integrados directamente en su administraci\u00f3n de cl\u00faster. Desarrollamos este modelo de aplicaci\u00f3n para que los servicios internos puedan escalar a hiperescala con replicaci\u00f3n con estado, y servicios como Cortana, Azure SQL Database y Skype for Business se basan en \u00e9l. Lanzaremos una vista previa p\u00fablica de Service Fabric a finales de este a\u00f1o, pero mientras tanto puedes consultar m\u00e1s en Service Fabric aqu\u00ed. Espero que lo anterior ayude a dar una imagen \u00fatil de la visi\u00f3n de contenedores de Microsoft, los casos de uso de contenedores m\u00e1s comunes y tambi\u00e9n algunas de las tendencias emergentes de la industria en torno a los contenedores. Como siempre, nos encantar\u00eda recibir sus comentarios, especialmente si hay \u00e1reas en las que desea obtener m\u00e1s informaci\u00f3n.
\n <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Por: Mark Russinovich CTO, Microsoft Azure No se puede debatir sobre la computaci\u00f3n en la nube \u00faltimamente sin hablar de contenedores. Las organizaciones de todos los segmentos comerciales, desde bancos y grandes empresas de servicios financieros hasta sitios de comercio electr\u00f3nico, quieren saber qu\u00e9 son los contenedores, qu\u00e9 significan para las aplicaciones en la nube […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[446,445],"class_list":["post-6041","post","type-post","status-publish","format-standard","hentry","category-servidores-infraestructura","tag-contenedores","tag-dockers"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/posts\/6041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/comments?post=6041"}],"version-history":[{"count":5,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/posts\/6041\/revisions"}],"predecessor-version":[{"id":6048,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/posts\/6041\/revisions\/6048"}],"wp:attachment":[{"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/media?parent=6041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/categories?post=6041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bhinfo.com.mx\/cursos\/wp-json\/wp\/v2\/tags?post=6041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}