Este artículo es parte de una serie de publicaciones en las que recorreré cada línea del Dockerfile predeterminado de Rails y explicaré las mejores prácticas y optimizaciones. Las imágenes de Docker se pueden optimizar de diferentes maneras, entre ellas, la reducción del tamaño de la imagen, la optimización del rendimiento de la compilación, las mejores prácticas de seguridad y mantenimiento, y las optimizaciones específicas de la aplicación. En el primer artículo, solo abordaré la optimización de la reducción del tamaño de la imagen y explicaré por qué es importante. ¿Por qué optimizar el tamaño de la imagen? Como en cualquier otro proceso de desarrollo de software, cada desarrollador enumerará las razones por las que desea que sus compilaciones de Docker sean más rápidas. Enumeraré las razones que para mí son las más importantes. Compilaciones e implementaciones más rápidas Las imágenes más pequeñas se crean más rápido porque se necesitan procesar menos archivos y capas. Esto mejora la productividad del desarrollador, especialmente durante los ciclos de desarrollo iterativos. Las imágenes más pequeñas tardan menos en enviarse a un registro y extraerse de él durante las implementaciones. Esto es especialmente crítico en los procesos de CI/CD donde los contenedores se crean e implementan con frecuencia. Reducción de costes de almacenamiento y uso de ancho de banda de red Las imágenes más pequeñas consumen menos almacenamiento en los registros de contenedores, las máquinas de desarrollo locales y los servidores de producción. Esto reduce los costos de infraestructura, especialmente para implementaciones a gran escala. Las imágenes más pequeñas utilizan menos ancho de banda cuando se transfieren entre servidores, lo que es especialmente importante cuando se crean imágenes localmente o en procesos de CI/CD y se envían a un registro. “Gastamos 3,2 millones de dólares en la nube en 2022... Ahorraremos unos 7 millones de dólares en gastos de servidores en cinco años desde que abandonemos la nube”. David Heinemeier Hansson — HEY World Rendimiento y seguridad mejorados Las imágenes más pequeñas requieren menos recursos (por ejemplo, CPU, RAM) para cargarse y ejecutarse, lo que mejora el rendimiento general de las aplicaciones en contenedores. Los tiempos de inicio más rápidos significan que sus servicios están listos más rápidamente, lo que es crucial para los sistemas de escalabilidad y alta disponibilidad. Las imágenes base mínimas como o contienen menos paquetes preinstalados, lo que reduce el riesgo de que se explote software innecesario o sin parches. alpine debian-slim Además de todo lo mencionado anteriormente, eliminar archivos y herramientas innecesarios minimiza las distracciones al diagnosticar problemas y conduce a una mejor capacidad de mantenimiento y una menor deuda técnica. Inspección de imágenes de Docker Para obtener diferentes parámetros de la imagen, incluido el tamaño, puede mirar Docker Desktop o ejecutar el comando en la terminal. docker images ➜ docker images REPOSITORY TAG IMAGE ID CREATED SIZE kamal-dashboard latest 673737b771cd 2 days ago 619MB kamal-proxy latest 5f6cd8983746 6 weeks ago 115MB docs-server latest a810244e3d88 6 weeks ago 1.18GB busybox latest 63cd0d5fb10d 3 months ago 4.04MB postgres latest 6c9aa6ecd71d 3 months ago 456MB postgres 16.4 ced3ad69d60c 3 months ago 453MB Conocer el tamaño de la imagen no le permite tener una visión completa. No sabe qué hay dentro de la imagen, cuántas capas tiene ni qué tamaño tiene cada capa. Una es una y de solo lectura que es un componente de una imagen de Docker. Cada capa representa un conjunto de cambios realizados en el sistema de archivos de la imagen, como agregar archivos, modificar configuraciones o instalar software. capa de imagen de Docker capa de sistema de archivos inmutable Las imágenes de Docker se crean de forma incremental, capa por capa, y cada capa corresponde a una instrucción en el . Para obtener las capas de la imagen, puedes ejecutar el comando . Dockerfile docker history ➜ docker history kamal-dashboard:latest IMAGE CREATED CREATED BY SIZE COMMENT 673737b771cd 4 days ago CMD ["./bin/thrust" "./bin/rails" "server"] 0B buildkit.dockerfile.v0 <missing> 4 days ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 <missing> 4 days ago ENTRYPOINT ["/rails/bin/docker-entrypoint"] 0B buildkit.dockerfile.v0 <missing> 4 days ago USER 1000:1000 0B buildkit.dockerfile.v0 <missing> 4 days ago RUN /bin/sh -c groupadd --system --gid 1000 … 54MB buildkit.dockerfile.v0 <missing> 4 days ago COPY /rails /rails # buildkit 56.2MB buildkit.dockerfile.v0 <missing> 4 days ago COPY /usr/local/bundle /usr/local/bundle # b… 153MB buildkit.dockerfile.v0 <missing> 4 days ago ENV RAILS_ENV=production BUNDLE_DEPLOYMENT=1… 0B buildkit.dockerfile.v0 <missing> 4 days ago RUN /bin/sh -c apt-get update -qq && apt… 137MB buildkit.dockerfile.v0 <missing> 4 days ago WORKDIR /rails 0B buildkit.dockerfile.v0 <missing> 3 weeks ago CMD ["irb"] 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; mkdir "$GEM_HOME";… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV PATH=/usr/local/bundle/bin:/usr/local/sb… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV GEM_HOME=/usr/local/bundle 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; savedAptMark="$(a… 78.1MB buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_DOWNLOAD_SHA256=018d59ffb52be3c0a6d… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_DOWNLOAD_URL=https://cache.ruby-lan… 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV RUBY_VERSION=3.4.1 0B buildkit.dockerfile.v0 <missing> 3 weeks ago ENV LANG=C.UTF-8 0B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; mkdir -p /usr/loca… 19B buildkit.dockerfile.v0 <missing> 3 weeks ago RUN /bin/sh -c set -eux; apt-get update; a… 43.9MB buildkit.dockerfile.v0 <missing> 3 weeks ago # debian.sh --arch 'arm64' out/ 'bookworm' '… 97.2MB debuerreotype 0.15 Dado que ya he proporcionado la teoría sobre las imágenes y las capas, es hora de explorar el . A partir de Rails 7.1, el se genera con la nueva aplicación Rails. A continuación, se muestra un ejemplo de cómo podría verse. Dockerfile Dockerfile # syntax=docker/dockerfile:1 # check=error=true # Make sure RUBY_VERSION matches the Ruby version in .ruby-version ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base # Rails app lives here WORKDIR /rails # Install base packages # Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives # Set production environment ENV RAILS_ENV="production" \ BUNDLE_DEPLOYMENT="1" \ BUNDLE_PATH="/usr/local/bundle" \ BUNDLE_WITHOUT="development" # Throw-away build stage to reduce size of final image FROM base AS build # Install packages needed to build gems RUN apt-get update -qq && \ apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives # Install application gems COPY Gemfile Gemfile.lock ./ RUN bundle install && \ rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \ bundle exec bootsnap precompile --gemfile # Copy application code COPY . . # Precompile bootsnap code for faster boot times RUN bundle exec bootsnap precompile app/ lib/ # Precompiling assets for production without requiring secret RAILS_MASTER_KEY RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile # Final stage for app image FROM base # Copy built artifacts: gems, application COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}" COPY --from=build /rails /rails # Run and own only the runtime files as a non-root user for security RUN groupadd --system --gid 1000 rails && \ useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \ chown -R rails:rails db log storage tmp USER 1000:1000 # Entrypoint prepares the database. ENTRYPOINT ["/rails/bin/docker-entrypoint"] # Start server via Thruster by default, this can be overwritten at runtime EXPOSE 80 CMD ["./bin/thrust", "./bin/rails", "server"] A continuación, proporcionaré una lista de enfoques y reglas que se aplicaron al anterior para hacer que el tamaño de la imagen final sea eficiente. Dockerfile Optimizar instalaciones de paquetes Estoy seguro de que solo mantienes el software necesario en tu máquina de desarrollo local. Lo mismo debería aplicarse a las imágenes de Docker. En los ejemplos a continuación, empeoraré constantemente del Dockerfile de Rails anterior. Lo mencionaré como una versión . el Dockerfile extraído original Dockerfile Regla n.° 1: use imágenes base mínimas FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base La imagen base es el punto de partida del . Es la imagen que se utiliza para crear el contenedor. La imagen base es la primera capa del y es la única capa que no crea el propio . Dockerfile Dockerfile Dockerfile La imagen base se especifica con el comando , seguido del nombre de la imagen y la etiqueta. La etiqueta es opcional y, si no se especifica, se utiliza la etiqueta . La imagen base puede ser cualquier imagen disponible en Docker Hub o en cualquier otro registro. FROM latest En el , usamos la imagen con la etiqueta . La imagen es disponible en Docker Hub. La etiqueta es una versión reducida de la imagen Ruby que se basa en la imagen . Mientras que la imagen es una versión mínima de la imagen Debian Linux que está optimizada para el tamaño. Observa la tabla a continuación para tener una idea de qué tan pequeña es la imagen . Dockerfile ruby 3.4.1-slim ruby la imagen Ruby oficial 3.4.1-slim debian-slim debian-slim slim ➜ docker images --filter "reference=ruby" REPOSITORY TAG IMAGE ID CREATED SIZE ruby 3.4.1-slim 0bf957e453fd 5 days ago 219MB ruby 3.4.1-alpine cf9b1b8d4a0c 5 days ago 99.1MB ruby 3.4.1-bookworm 1e77081540c0 5 days ago 1.01GB A partir de enero de 2024, la versión actual de Debian se llama y la anterior es . bookworm bullseye 219 MB en lugar de 1 GB: una diferencia enorme. Pero, ¿qué pasa si la imagen es incluso más pequeña? La imagen se basa en la distribución de Linux Alpine, que es una distribución de Linux superligera que está optimizada para el tamaño y la seguridad. Alpine utiliza la biblioteca (en lugar de ) y (un conjunto compacto de utilidades de Unix) en lugar de sus contrapartes GNU. Si bien es técnicamente posible utilizar la imagen para ejecutar Rails, no lo abordaré en este artículo. alpine alpine musl glibc busybox alpine Regla n.° 2: minimizar las capas RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \ rm -rf /var/lib/apt/lists /var/cache/apt/archives Cada instrucción , y en crea una nueva capa. Cuantas más capas tenga, mayor será el tamaño de la imagen. Por eso, la mejor práctica es combinar varios comandos en una sola instrucción . Para ilustrar este punto, veamos el siguiente ejemplo. RUN COPY FROM Dockerfile RUN # syntax=docker/dockerfile:1 # check=error=true # Make sure RUBY_VERSION matches the Ruby version in .ruby-version ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base RUN apt-get update -qq RUN apt-get install --no-install-recommends -y curl RUN apt-get install --no-install-recommends -y libjemalloc2 RUN apt-get install --no-install-recommends -y libvips RUN apt-get install --no-install-recommends -y libpq-dev RUN rm -rf /var/lib/apt/lists /var/cache/apt/archives CMD ["echo", "Whalecome!"] He dividido la instrucción en varias líneas, lo que obviamente las hace más . Pero, ¿cómo afectará esto al tamaño de la imagen? Construyamos la imagen y veámosla. RUN legibles para los humanos ➜ time docker build -t no-minimize-layers --no-cache -f no-minimize-layers.dockerfile . 0.31s user 0.28s system 2% cpu 28.577 total Se necesitaron 28 segundos para construir la imagen, mientras que construir la toma solo 19 segundos ( ). versión original con capas minimizadas casi un 33% más rápido ➜ time docker build -t original --no-cache -f original.dockerfile . 0.25s user 0.28s system 2% cpu 19.909 total Vamos a comprobar el tamaño de las imágenes. ➜ docker images --filter "reference=*original*" --filter "reference=*no-minimize*" REPOSITORY TAG IMAGE ID CREATED SIZE original latest f1363df79c8a 8 seconds ago 356MB no-minimize-layers latest ad3945c8a8ee 43 seconds ago 379MB La imagen con capas minimizadas es 23 MB más pequeña que la que no tiene capas minimizadas. Esto supone una . Aunque parece una diferencia pequeña en este ejemplo, la diferencia será mucho mayor si divide todas las instrucciones en varias líneas. reducción del tamaño del 6 % RUN Regla n.° 3: Instale solo lo necesario De forma predeterminada, instala los paquetes recomendados y los paquetes que le solicitaste que instalara. La opción le indica que instale solo los paquetes que se especifican explícitamente y no los recomendados. apt-get install --no-install-recommends apt-get ➜ time docker build -t without-no-install-recommends --no-cache -f without-no-install-recommends.dockerfile . 0.33s user 0.30s system 2% cpu 29.786 total ➜ docker images --filter "reference=*original*" --filter "reference=*recommends*" REPOSITORY TAG IMAGE ID CREATED SIZE without-no-install-recommends latest 41e6e37f1e2b 3 minutes ago 426MB minimize-layers latest dff22c85d84c 17 minutes ago 356MB Como puede ver, la imagen sin es 70 MB más grande que la . Esto representa un . --no-install-recommends original aumento del 16 % en el tamaño la utilidad para ver qué archivos se agregaron a la imagen; lea más sobre ello al final del artículo. Utilice Dive Regla n.° 4: Limpiar después de las instalaciones El original incluye el comando después del comando . Este comando elimina las listas de paquetes y los archivos que ya no son necesarios después de la instalación. Veamos cómo afecta al tamaño de la imagen. Para lograrlo, crearé un nuevo . Dockerfile rm -rf /var/lib/apt/lists/* /var/cache/apt/archives apt-get install Dockerfile sin el comando de limpieza RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev Construir las imágenes lleva casi el mismo tiempo que la original, lo cual tiene sentido. ➜ time docker build -t without-cleaning --no-cache -f without-cleaning.dockerfile . 0.28s user 0.30s system 2% cpu 21.658 total Vamos a comprobar el tamaño de las imágenes. ➜ docker images --filter "reference=*original*" --filter "reference=*cleaning*" REPOSITORY TAG IMAGE ID CREATED SIZE without-cleaning latest 52884fe50773 2 minutes ago 375MB original latest f1363df79c8a 16 minutes ago 356MB La imagen sin limpieza es 19 MB más grande que la que tiene limpieza, esto es un . aumento del 5% en el tamaño El peor escenario ¿Qué sucede si no se aplican las cuatro optimizaciones mencionadas anteriormente? Creemos un nuevo y construyamos la imagen. Dockerfile sin ninguna optimización # syntax=docker/dockerfile:1 # check=error=true ARG RUBY_VERSION=3.4.1 FROM docker.io/library/ruby:$RUBY_VERSION AS base RUN apt-get update -qq RUN apt-get install -y curl RUN apt-get install -y libjemalloc2 RUN apt-get install -y libvips RUN apt-get install -y libpq-dev CMD ["echo", "Whalecome!"] ➜ time docker build -t without-optimizations --no-cache -f without-optimizations.dockerfile . 0.46s user 0.45s system 1% cpu 1:02.21 total Vaya, tardó más de un minuto construir la imagen. ➜ docker images --filter "reference=*original*" --filter "reference=*without-optimizations*" REPOSITORY TAG IMAGE ID CREATED SIZE without-optimizations latest 45671929c8e4 2 minutes ago 1.07GB original latest f1363df79c8a 27 hours ago 356MB La imagen sin optimizaciones es 714 MB más grande que la original, esto es un . Esto demuestra claramente lo importante que es optimizar el , las imágenes más grandes tardan más en compilarse y consumen más espacio en disco. aumento de tamaño del 200% Dockerfile Utilice siempre .dockerignore El archivo es similar al archivo que utiliza Git. Se utiliza para excluir archivos y directorios del contexto de la compilación. El contexto es el conjunto de archivos y directorios que se envían al demonio de Docker cuando se crea una imagen. El contexto se envía al demonio de Docker como un archivo tar, por lo que es importante mantenerlo lo más pequeño posible. .dockerignore .gitignore Si, por alguna razón, no tienes el archivo en tu proyecto, puedes crearlo manualmente. Te sugiero que uses la de Rails como punto de partida. A continuación, se muestra un ejemplo de cómo podría verse. .dockerignore plantilla oficial de archivo .dockerignore # See https://docs.docker.com/engine/reference/builder/#dockerignore-file for more about ignoring files. # Ignore git directory. /.git/ /.gitignore # Ignore bundler config. /.bundle # Ignore all environment files. /.env* # Ignore all default key files. /config/master.key /config/credentials/*.key # Ignore all logfiles and tempfiles. /log/* /tmp/* !/log/.keep !/tmp/.keep # Ignore pidfiles, but keep the directory. /tmp/pids/* !/tmp/pids/.keep # Ignore storage (uploaded files in development and any SQLite databases). /storage/* !/storage/.keep /tmp/storage/* !/tmp/storage/.keep # Ignore assets. /node_modules/ /app/assets/builds/* !/app/assets/builds/.keep /public/assets # Ignore CI service files. /.github # Ignore development files /.devcontainer # Ignore Docker-related files /.dockerignore /Dockerfile* archivo en el proyecto no solo permite excluir archivos y directorios innecesarios (por ejemplo, flujos de trabajo de GitHub de la carpeta o dependencias de JavaScript de ) del contexto. También ayuda a evitar agregar información confidencial accidentalmente a la imagen. Por ejemplo, el archivo que contiene las variables de entorno o el archivo que se usa para descifrar las credenciales. Tener un .dockerfile .github node_modules .env master.key Utilice Dive Todas las optimizaciones mencionadas anteriormente pueden parecer obvias cuando se explican. ¿Qué hacer si ya tienes una imagen enorme y no sabes por dónde empezar? Mi herramienta favorita y más útil es . Dive es una herramienta TUI para explorar una imagen de Docker, el contenido de las capas y descubrir formas de reducir el tamaño de la imagen. Dive se puede instalar con el administrador de paquetes del sistema o se puede usar su imagen oficial de Docker para ejecutarlo. Usemos la imagen de nuestro peor escenario. Dive docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations En la captura de pantalla anterior, puede ver la inspección de nuestra imagen menos óptima. Dive muestra el tamaño de cada capa, el tamaño total de la imagen y los archivos que se cambiaron (agregaron, modificaron o eliminaron) en cada capa. Para mí, esta es la característica más útil de Dive. Al enumerar los archivos en el panel derecho, puede identificar fácilmente los archivos que no son necesarios y eliminar los comandos que los agregan a la imagen. Una cosa que realmente me encanta de Dive es que, además de tener una interfaz de usuario de terminal, también puede proporcionar una salida compatible con CI, que también puede ser eficaz en un desarrollo local. Para usarlo, ejecute Dive con la variable de entorno establecida en , la salida del comando se muestra en la captura de pantalla a continuación. CI true docker run -e CI=true --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations Mi preferencia personal es usar Dive de forma programada, por ejemplo, una vez a la semana, para asegurarme de que las imágenes sigan en buen estado. En los próximos artículos, hablaré sobre los flujos de trabajo automatizados que utilizo para verificar mi Dockerfile, incluidos Dive y . Hadolint No aplastes las capas Un enfoque que he visto para minimizar el tamaño de la imagen es intentar comprimir las capas. La idea era combinar varias capas en una sola para reducir el tamaño de la imagen. Docker tenía una opción experimental , además de esto, había herramientas de terceros como . --squash docker-squash Si bien este enfoque funcionó en el pasado, actualmente está en desuso y no se recomienda su uso. La combinación de capas destruyó la característica fundamental de Docker de almacenamiento en caché de capas. Además de eso, al usar podría incluir involuntariamente archivos confidenciales o temporales de capas anteriores en la imagen final. Este es un enfoque de todo o nada que carece de un control detallado. --squash En lugar de comprimir las capas, se recomienda utilizar compilaciones de varias etapas. Rails ya utiliza compilaciones de varias etapas. Explicaré cómo funciona en el próximo artículo. Dockerfile Conclusiones La optimización de imágenes de Docker, al igual que cualquier otra optimización, . Es un proceso continuo que requiere controles y mejoras regulares. Intenté cubrir los conceptos básicos, pero es fundamental conocerlos y comprenderlos. En los próximos artículos, cubriré técnicas y herramientas más avanzadas que pueden ayudar a que sus compilaciones de Docker sean más rápidas y eficientes. no se puede hacer una sola vez y olvidarse
