Docker publica su primera autopsia pública sobre un incidente interno

De acuerdo con su estrategia esbozada en noviembre pasado, Docker se está acercando a los desarrolladores. En marzo, les comunicó su hoja de ruta solicitando sus comentarios y, este mes, acaba de publicar para ellos una "autopsia" que detalla un incidente interno en sus servicios en la nube. Esta es la primera vez que el especialista en contenedores lo hace públicamente, con el objetivo declarado de construir una relación de confianza entre sus usuarios y sus equipos. En noviembre, después de vender su negocio Enterprise a Mirantis, Docker anunció su intención de volver a centrarse en los desarrolladores con sus soluciones de escritorio y concentrador.

La publicación publicada el 12 de agosto por Brett Inman, gerente senior de ingeniería del proveedor, describe un incidente que ocurrió a principios de julio en el repositorio de almacenamiento de imágenes de contenedores de Docker Hub. Esta descripción de resolución de problemas ilustra un caso de interacción compleja entre diferentes operadores de servicios en la nube. Entre las 7:00 p.m. (UTC) el 5 de julio y las 6:30 a.m. del 6 de julio, los usuarios de Amazon Linux en varias regiones experimentaron interrupciones en la descarga de imágenes de Docker almacenadas en Docker Hub. “El problema fue con un mecanismo de protección anti-botnet implementado por nuestro proveedor de CDN Cloudflare”, explica Brett Inman. Los equipos de Docker, Cloudflare y AWS trabajaron juntos para identificarlo y el mecanismo en cuestión se deshabilitó, lo que permitió restaurar el servicio.

Autopsia de un incidente en la nube

Alrededor de la 1:45 am UTC del lunes 6 de julio, nuevamente el domingo en la costa del Pacífico, AWS se comunicó con Docker con respecto a la imposibilidad de que varios servicios y usuarios extraigan imágenes de Docker Hub, dijo Brett Inman. Los equipos de infraestructura y repositorio abordan inmediatamente el mal funcionamiento. Después de comprobarlo, no encuentran nada anormal en el repositorio en sí ni en la infraestructura de AWS. "Esto nos indicó que el problema estaba más bien ligado a una región oa un mecanismo en los servicios descompuestos", continúa el gerente de ingeniería. AWS notificó que los sistemas afectados eran los que ejecutaban Amazon Linux (incluidos servicios de alto nivel como Fargate), el equipo de Docker comienza a lanzar instancias con Amazon Linux y con otro sistema operativo en diferentes regiones de AWS. Resulta que ambos sistemas operativos funcionan bien en la región us-east-1, mientras que en otras regiones Amazon Linux no puede extraer las imágenes mientras que el otro sistema operativo sí. "El hecho de que us-east-1 funcionara para ambos sistemas operativos hizo que pareciera que el problema estaba en nuestra CDN, Cloudflare". De hecho, en la región us-east-1, las imágenes de Docker Hub se almacenan en depósitos de S3 y las solicitudes son atendidas directamente por S3. En otras regiones, lo hicieron a través de la CDN.

Luego, Docker se acerca a Cloudflare para abrir un incidente y los tres proveedores estudian el problema juntos. En un descubrimiento de AWS realizado al comparar las diferencias entre Amazon Linux y el otro sistema operativo, Cloudflare se da cuenta de que parte del tráfico a Docker Hub se está cayendo debido a un sistema de mitigación anti-botnet que agregó una detección que marca los paquetes con un determinado atributo como potencialmente parte de un ataque. Aunque está supervisada por Cloudfare, esta interacción en particular aún no se había detectado. Después de que se desactivó el mecanismo, el tráfico de Docker Hub pudo reanudarse y el incidente se cerró a las 6.30 am UTC.

Eliminación de imágenes de contenedores inactivos durante 6 meses

En cuanto a su repositorio de almacenamiento de imágenes de contenedores, Docker también anunció hace unos días que había cambiado su política de retención de datos. En las cuentas gratuitas de Docker Hub, el proveedor acaba de introducir un período de retención máximo de 6 meses para las imágenes inactivas. Después de 6 meses de inactividad, se programará la destrucción de las imágenes. Para mantenerlos por más tiempo, los usuarios solo necesitan registrarse para obtener una cuenta paga, Pro o Team, que comienza en $ 5 o $ 7 por mes.