Reducir, Reusar, Reemplazar: Contenedores sostenibles con Buildpacks
La construcción de contenedores puede ser desmedido. Cada actualización en el sistema operativo, nueva versión de dependencias y actualización de la cadena de herramientas (toolchain) resulta en una cantidad copiosa de energía usada para construir y reconstruir nuestras imágenes para los contenedores; a menudo innecesarias. Puede ser costoso a gran escala, por lo que Cloud Native Buildpacks fueron diseñados para realizar builds completos solo cuando un rebuild es realmente requerida.
Buildpacks transforman el código fuente en imágenes para contenedores. Pueden ser usados con o sin Docker para encapsular patrones comúnes en todos los builds, lo que hace la conteinerización más fácil y consistente para desarrolladores de aplicaciones. Buildpacks también provee caché avanzado y mecanismos de parchado para hacerlo una opción más amigables con el medio ambiente para la construcción de contenedores. En ciertos casos, Los Buildpacks previenen que muchas imágenes sean reconstruidas totalmente. Se trata de un gran cambio con respecto a otras tecnologías Cloud Native que pueden suponer que hay disponibles recursos limitados en la nube.
Sobre el impacto ambiental de Cloud Native
Previo a la aparición del ecosistema de Cloud Native y al uso generalizado de la imágenes para los contenedores, nuestras apliaciones se desplegaban en servidores construidos a partir de machine images que eran actualizadas con poca frecuencia y en una cadencia distinta que la de las aplicaciones.
Hoy día, muchas aplicaciones están acopladas al sistema operativo y sus paquetes dado a que usan un Dockerfile para definir sus imágenes. Como resultado, esas imagenes necesitan de reconstrucción frecuentemente para aplicar parches a los componentes a nivel de Sistema Operativo o simplemente, para actualizar las herramientas que ni siquiera son usadas por las aplicaciones. Peor, el mecanismo encargado del caché de las capas impuesto por el Dockerfile nos forza a reconstruir las capas que no necesitan ser reconstruidas.
El ecosistema cloud-native ha aportado productividad y mejoras operacionales al desarrollo de software. Pero hemos perdido de vista el desperdicio que esas tecnologías puede generar. Buildpacks, por otro lado, han sido diseñados para trabajar a gran escala (decenas de millones de imágenes) donde generar desperdicio tiene un costo real. Es por eso que los Buildpacks implementan mecanismos que requieren recursos mínimos.
Reducir, Reusar, Reemplazar
Las imágenes de contenedores construidas a partir de un Dockerfile requieren una construcción completa cuando una nueva actualización del sistema opeartivo se encuentra disponible, incluso si tu aplicación no necesita una recompilación o reinstalación para ser compatible con la actualización (Por ejemplo, la actualización es
compatible con ABI. Este no es el caso cuando se usa Buildpacks.
Cuando una imágen base del sistema opeartivo se encuentra disponible para una imagen generada a través de un buildpack, las capas existentes que se posan sobre el sistema operativo son reusadas. Este proceso, ilustrado abajo, se le conoce como rebasing o reconstrucción de la base. Las capas de la aplicación, con el mismo SHA, pueden ser posicionadas sobre las capas del nuevo sistema operativo.
El proceso que Buildpacks usa para rebase en imágenes finalmente usa tanto capas existentes como nuevas capas de sistema opeartivo, sin necesidad de hacer una construcción. En esencia, rebasing es un proceso simple. Inspeccionando una imágen de una aplicación, el proceso de rebase puede determinar si se necesita o no una nueva versión base de la imagen de la aplicación existente (sea local o de un registry). Si una nueva versión existe, el proceso de rebase actualiza la metadata de las capas de la aplicación para hacer referencia a una nueva versión de la imagen base. Esto es esencialmente una operación que edita un archivo JSON. Toma unos milisegundos y usa pocos recursos computacionales.
El proceso rebase permite a desarrolladores de aplicaciones u operadores la actualización rápida de la imagen de sus aplicaciones cuando su imagen de ejecución haya cambiado. Usando el proceso de reconstrucción o rebasing de capas, este comando evita una reconstrucción completa de la aplicación.
Puedes
aprender más del proceso rebase en la documentación de Buildpacks. Pero rebase no es el único mecanismo que es más sostenible que la construcción a través de un Dockerfile. Buildpacks pueden poner en caché artefactos para la construcción lo cuál habilita una compilación incremental y otras técnicas de ahorro. Estas capas puestas en caché no siempre se descartarán cuando sea necesario reconstruirlas, com lo harían las compilaciones hechas usando un Dockerfile
Se tan verde como tus tests unitarios
La construcción de contenedores no son los mayores infractores cuando se trata del impacto ambiental del software. La electricidad requerida para minar bitcoin es más que la usada por paises enteros, pero el crecimiento del software que usa técnias de criptografía ha traído nueva conciencia de como nuesro código afecta el mundo alrededor de nosotros. Eso es algo bueno.
Nosotros tenemos la responsabilidad de pensar en como minimizar los recursos producidos para el software que producimos. El código qque escribimos tiene un impacto en el mundo, y nuestras decisiones importan.
Para aprender más sobre la relación entre el desarrollo de software open source y el ambiente, visita el Grupo Asesor Técnico de Sostenibilidad Ambiental (TAG).