Header Ads Widget

Ticker

6/recent/ticker-posts

Contenedores y API de Docker: una breve descripción general

 

Docker-contenedores-y-apis-a-brief-overview-nordic-apis

Uno de los principales problemas que se enfrentan universalmente en el desarrollo de API es la administración, el empaquetado y la distribución de dependencias. El conjunto de dependencias requerido por una API puede hacerlo extensible, maravilloso de usar y extremadamente poderoso. Sin embargo, si es difícil de manejar, las dependencias podrían significar un limbo de adopción.

Sin embargo, una solución a este antiguo problema ha aparecido en escena en los últimos años. Docker es un sistema mediante el cual se puede contener, empaquetar y enviar un ecosistema completo, integrando “código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, cualquier cosa que pueda instalar en un servidor” .

En esta pieza, vamos a echar un vistazo a Docker y su sistema de contenedores. Analizaremos algunos casos en los que usar Docker es una buena idea, algunos casos en los que puede no ser la mejor solución y las fortalezas y debilidades del sistema en su conjunto.

¿Qué es Docker?

Antes de poder criticarlo, debemos comprender completamente qué es Docker y cómo funciona. En pocas palabras, Docker es una plataforma y una metodología abiertas mediante las cuales se puede proporcionar todo el ecosistema de desarrollo a los usuarios y consumidores de API en una aplicación singular. Docker es una metodología para manejar dependencias y simplificar la funcionalidad, y se puede usar con una variedad de lenguajes de microservicios .

El enfoque de API "clásico"

Docker-classic-approach-containers-nordic-apis-diagram

Considere el método “clásico” de manejo de dependencias y manejo de ecosistemas. Se desarrolla una API que emite llamadas remotas a un servidor o servicio. Estas llamadas son manejadas por un marco al que se hace referencia externa a la API . Este marco luego solicita recursos externos al servidor API en forma de dependencias , que permiten que el código funcione en la metodología para la que fue diseñado. Finalmente, los datos se entregan al cliente en el formato restringido determinado por la API.

Pesado y difícil de manejar, este sistema está anticuado en muchos sentidos. Depende de los desarrolladores de dependencias para actualizar sus sistemas, mantener controles de versiones efectivos y manejar las vulnerabilidades de seguridad externas.

Además, muchas de estas dependencias son propietarias o, al menos, están en manos de un único desarrollador. Esto significa que el código se mantiene externo a la API y cualquier cambio en la funcionalidad, falla en la seguridad, modificación de dependencias adicionales utilizadas por el autor de la dependencia, etc., puede causar fallas catastróficas.

Salvo los problemas de dependencia, el enfoque "clásico" es simplemente lento y pesado en recursos . Requiere que los desarrolladores alojen todo el sistema en una red de API entrelazadas, intentando piratear un sistema que funcione. Es un ecosistema delicado y funcional que impresiona por su complejidad, pero con esta complejidad surge el potencial para que el enfoque clásico se convierta en un verdadero "castillo de naipes".

El enfoque de Docker

Docker-enfoque-API-nordic-apis

Docker ha creado un enfoque completamente diferente. En lugar de depender de múltiples fuentes externas para la funcionalidad, Docker permite el uso remoto de imágenes e infraestructura del sistema operativo de una manera que distribuye todas las dependencias, funcionalidades del sistema y servicios centrales dentro de la propia API.

Docker los llama "contenedores". Piense en los contenedores como máquinas virtuales , pero mejor.

Una máquina virtual (VM) empaqueta una aplicación con binarios, bibliotecas, dependencias y un sistema operativo, y todo lo que viene con él. Esto está bien para el uso de estaciones de trabajo empresariales y escritorios remotos, pero genera una tonelada de desperdicio de ancho de banda y no es realmente un gran enfoque para las API.

Los contenedores Docker, por otro lado, son más autosuficientes . Contienen la aplicación y todas sus dependencias, pero utilizan un núcleo común con otras aplicaciones en el espacio de usuario del sistema operativo host. Esto libera el contenedor para que funcione en cualquier sistema y elimina la totalidad del exceso de sistema operativo de las máquinas virtuales al restringir el contenido solo a lo que necesita la API o la aplicación.

Fuente de la imagen: Windows IT Pro

¿Por qué Docker?

Con sus similitudes con las máquinas virtuales, es probable que muchos desarrolladores se pregunten cuál es el rumor sobre Docker. ¿Qué, específicamente, lo hace tan grandioso? Hay muchas razones para amar la ventana acoplable:

  • Código abierto : Docker está diseñado para aprovechar la amplia gama de estándares abiertos presentes tanto en el ecosistema del sistema operativo Linux como en el de Microsoft. Esto le permite admitir prácticamente cualquier configuración de infraestructura que le arroje, al tiempo que permite la transparencia en la base del código.

A diferencia de los sistemas cerrados, los que los usan revisan rutinariamente los sistemas abiertos para detectar vulnerabilidades de seguridad y, por lo tanto, muchos los consideran “más seguros”. Además, debido a que estos estándares están destinados a promover la interoperabilidad entre sistemas dispares, la compatibilidad entre sistemas en la base de código o la funcionalidad de la biblioteca es inexistente.

  • Seguridad a través del espacio aislado: es posible que Docker no lo llame "espacio aislado", pero eso es esencialmente lo que es: cada aplicación está aislada de otras aplicaciones debido a la naturaleza de los contenedores Docker, lo que significa que cada una se ejecuta en su propio ecosistema separado, pero conectado.

Esto da como resultado una enorme capa de seguridad que no se puede ignorar. En el enfoque clásico, las API son tan interdependientes entre sí que, al violar una, a menudo todo el sistema se vuelve vulnerable a menos que se implementen sistemas de seguridad complejos . Con las aplicaciones en espacio aislado, esto ya no es un problema.

  • Desarrollo más rápido e iteración más fácil : debido a que se puede crear, replicar y aumentar una amplia gama de entornos, las API se pueden desarrollar para que funcionen con una variedad de sistemas que de otro modo no estarían disponibles para muchos desarrolladores.

Como parte de este beneficio, las API se pueden probar en entornos empresariales, pilas variables e incluso entornos en vivo antes de la implementación completa sin un costo significativo. Este proceso se integra maravillosamente con las estrategias de desarrollo de TI de dos velocidades , lo que permite la iteración y la estabilidad en un servicio. Esto tiene el beneficio adicional de admitir un estilo de arquitectura de microservicios verdaderamente efectivo, debido en gran parte a la reducción general del tamaño y la metodología enfocada en la estrategia ajustada.

  • Reducción ligera de la redundancia : por la propia naturaleza de los contenedores Docker, las API comparten un kernel base. Esto significa menos recursos del sistema dedicados a dependencias redundantes y menos instancias para consumir la RAM del servidor y los fragmentos de procesamiento.

Los sistemas de archivos y las imágenes comunes solo hacen que esta sea una propuesta más atractiva, aliviando la carga de espacio creado por las API de dependencia múltiple en órdenes de magnitud. Esto hace que el contenedor de API sea fácil de usar y comprender, lo que hace que la API sea realmente funcional y útil .

Banner básico-01

Comandos simples de Docker

Parte del atractivo de Docker es lo simples que son los comandos y las variables que contiene. Por ejemplo, para crear un contenedor, simplemente realice la siguiente llamada:

POST /containers/create

Usando una lista de variables, puede cambiar completamente cómo funciona este contenedor, cuál es su nombre y qué contiene el contenedor. Puedes cambiar todo desde el nombre usando:

 –name=""

A la dirección MAC del propio contenedor:

  –mac-address=""

Incluso puede cambiar la forma en que funciona el contenedor con el servidor mismo, asignando el contenedor para que se ejecute en núcleos de CPU específicos por ID:

 –cpuset-cpus=""

Cuando se ejecuta el comando "docker create", se crea una capa de escritura sobre el kernel de la imagen que permite la modificación de toda la funcionalidad de la aplicación.

Estas variables también están disponibles para el comando "ejecutar". Lo más importante es que el comando "ejecutar" también puede adjuntar una dirección estática al contenedor de API utilizando las llamadas "-p" y "–expose":

docker run -p 192.168.0.1:8910
docker runexpose 8910

Estas dos llamadas primero asignarán el contenedor al puerto 8910 de la IP 192.168.0.1, y luego expondrán ese puerto al tráfico orientado hacia adelante (de hecho, abrirán el puerto por completo para la funcionalidad API).

Para que estos contenedores sean funcionales, por supuesto, un contenedor debe conectarse a una imagen. Estas imágenes se crean utilizando la llamada "build":

docker build -t ubuntu

Esto crea una imagen simple, a la que luego se le asigna una variable "ID DE IMAGEN" que se puede llamar mediante la llamada "imágenes de docker":

docker images -a –no-trunc=false

Esta llamada enumera la totalidad de la biblioteca de imágenes de Docker sin truncamiento, que luego se puede llamar y utilizar mediante las variables de ejecución.

Docker evita gran parte de la carga de dependencia inherente al proceso de la API, simplificando el código y creando una métrica de utilización del sistema y de la red más ágil. Por ejemplo, vea una importación personalizada teórica en Golang :

package main
 
import (
     "encoding/json"
     "fmt"
     "net/http"
     “customlib”
     “main”
     “golang-local/issr”
     “functionreader”
     “payment_processor”
     “maths”
 )

En Docker, una solicitud equivalente sería simplemente:

docker run –name tracecrt
Leer más: Escribir microservicios en Go

Caveat Emptor

Los contenedores Docker son una buena solución para un problema muy común, pero no son para todos. Si bien simplifica significativamente el sistema API en tiempo de ejecución, esto viene con la advertencia de una mayor complejidad en la configuración de los contenedores.

Además, debido a que los contenedores comparten núcleos, existe una gran cantidad de redundancia que se pierde por diseño. Si bien esto es bueno en términos de gestión del alcance del proyecto , también significa que cuando hay un problema con el kernel, con una imagen o con el propio host, todo un ecosistema se ve amenazado.

Una de las mayores advertencias aquí no es la de Docker en sí, sino la comprensión del sistema. Muchos desarrolladores están interesados ​​en tratar a Docker como una plataforma para el desarrollo en lugar de como lo que es: funcionalmente hablando, una gran herramienta de optimización y racionalización. Estos desarrolladores estarían mejor si adoptaran sistemas de plataforma como servicio (PaaS) en lugar de administrar las minucias de los servidores lógicos o virtuales autohospedados y administrados.

Conclusión

Los contenedores Docker son increíblemente poderosos, al igual que el lenguaje que los respalda. Teniendo esto en cuenta, los contenedores ciertamente no son para todos: las API simples, como las API de llamada URI estrictamente estructuradas , no utilizarán los contenedores de manera efectiva, y la complejidad adicional puede dificultar que los desarrolladores novatos manejen API y sistemas más grandes.

Dicho esto, los contenedores son una gran solución para un gran problema, y ​​si un desarrollador se siente cómodo con la administración de imágenes y los servidores o sistemas físicos en los que se ejecutan, los contenedores son una bendición y pueden conducir a un crecimiento y creatividad explosivos .

Publicar un comentario

0 Comentarios