Este artigo faz parte de uma série de postagens onde abordarei cada linha do Dockerfile padrão do Rails e explicarei as melhores práticas e otimizações. As imagens do Docker podem ser otimizadas de diferentes maneiras que incluem, mas não estão limitadas a, redução do tamanho da imagem, otimização do desempenho da compilação, práticas recomendadas de segurança e manutenibilidade e otimizações específicas do aplicativo. No primeiro artigo, abordarei apenas a otimização da redução do tamanho da imagem e explicarei por que elas são importantes. Por que otimizar o tamanho da imagem? Como em qualquer outro processo de desenvolvimento de software, cada desenvolvedor listará seus motivos pelos quais ele quer tornar suas compilações Docker mais rápidas. Listarei os motivos que são mais importantes para mim. Construções e implantações mais rápidas Imagens menores são mais rápidas de construir porque menos arquivos e camadas precisam ser processados. Isso melhora a produtividade do desenvolvedor, especialmente durante ciclos de desenvolvimento iterativos. Imagens menores levam menos tempo para enviar para um registro e extrair dele durante as implantações. Isso é especialmente crítico em pipelines de CI/CD, onde os contêineres são construídos e implantados com frequência. Custos de armazenamento reduzidos e uso de largura de banda de rede Imagens menores consomem menos armazenamento em registros de contêineres, máquinas de desenvolvimento local e servidores de produção. Isso reduz os custos de infraestrutura, especialmente para implantações em larga escala. Imagens menores usam menos largura de banda quando transferidas entre servidores, especialmente importante quando você está criando imagens localmente ou em pipelines de CI/CD e enviando-as para um registro. “Gastamos US$ 3,2 milhões na nuvem em 2022... Podemos economizar cerca de US$ 7 milhões em despesas com servidores ao longo de cinco anos com nossa saída da nuvem.” David Heinemeier Hansson — HEY World Desempenho e segurança aprimorados Imagens menores exigem menos recursos (por exemplo, CPU, RAM) para carregar e executar, melhorando o desempenho geral de aplicativos em contêineres. Tempos de inicialização mais rápidos significam que seus serviços estão prontos mais rapidamente, o que é crucial para sistemas de escalonamento e alta disponibilidade. Imagens de base mínimas como ou contêm menos pacotes pré-instalados, diminuindo o risco de software sem patch ou desnecessário ser explorado. alpine debian-slim Além de tudo o que foi mencionado acima, remover arquivos e ferramentas desnecessários minimiza distrações ao diagnosticar problemas e leva a uma melhor manutenibilidade e redução da dívida técnica. Inspecionando imagens do Docker Para obter diferentes parâmetros da imagem, incluindo o tamanho, você pode consultar o Docker Desktop ou executar o comando no 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 Saber o tamanho da imagem não lhe dá a imagem completa. Você não sabe o que está dentro da imagem, quantas camadas ela tem ou quão grande é cada camada. Uma é uma e somente leitura que é um componente de uma imagem Docker. Cada camada representa um conjunto de alterações feitas no sistema de arquivos da imagem, como adicionar arquivos, modificar configurações ou instalar software. camada de imagem Docker camada de sistema de arquivos imutável As imagens do Docker são construídas incrementalmente, camada por camada, e cada camada corresponde a uma instrução no . Para obter as camadas da imagem, você pode executar o 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 Como já forneci teoria sobre imagens e camadas, é hora de explorar o . A partir do Rails 7.1, o é gerado com o novo aplicativo Rails. Abaixo está um exemplo de como ele pode se parecer. 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"] Abaixo, fornecerei uma lista de abordagens e regras que foram aplicadas ao acima para tornar o tamanho da imagem final eficiente. Dockerfile Otimizar instalações de pacotes Tenho certeza de que você mantém apenas o software necessário em sua máquina de desenvolvimento local. O mesmo deve ser aplicado às imagens do Docker. Nos exemplos abaixo, vou consistentemente piorar do Rails Dockerfile acima. Vou referenciá-lo como uma versão . o Dockerfile extraído original Dockerfile Regra nº 1: Use o mínimo de imagens de base FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base A imagem base é o ponto de partida para o . É a imagem que é usada para criar o contêiner. A imagem base é a primeira camada no e é a única camada que não é criada pelo próprio . Dockerfile Dockerfile Dockerfile A imagem base é especificada com o comando , seguido pelo nome da imagem e tag. A tag é opcional e, se não for especificada, a tag será usada. A imagem base pode ser qualquer imagem disponível no Docker Hub ou qualquer outro registro. FROM latest No about, estamos usando a imagem com a tag . A imagem é disponível no Docker Hub. A tag é uma versão slim da imagem Ruby que é baseada na imagem . Enquanto a imagem é uma versão mínima da imagem do Debian Linux que é otimizada para tamanho. Veja a tabela abaixo para ter uma ideia de quão menor é a imagem . Dockerfile ruby 3.4.1-slim ruby a imagem oficial do Ruby 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 Em janeiro de 2024, a versão atual do Debian é chamada de e a anterior é . bookworm bullseye 219 MB em vez de 1 GB — uma diferença enorme. Mas e se a imagem for ainda menor? A imagem é baseada na distribuição Alpine Linux, que é uma distribuição Linux superleve que é otimizada para tamanho e segurança. Alpine usa a biblioteca (em vez de ) e (um conjunto compacto de utilitários Unix) em vez de equivalentes GNU. Embora seja tecnicamente possível usar a imagem para executar Rails, não vou abordá-la neste artigo. alpine alpine musl glibc busybox alpine Regra nº 2: Minimize as camadas 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 instrução , e no cria uma nova camada. Quanto mais camadas você tiver, maior será o tamanho da imagem. É por isso que a melhor prática é combinar vários comandos em uma única instrução . Para ilustrar esse ponto, vamos dar uma olhada no exemplo abaixo. 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!"] Eu dividi a instrução em várias linhas, o que obviamente as torna mais . Mas como isso afetará o tamanho da imagem? Vamos construir a imagem e dar uma olhada. RUN legíveis para 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 Foram necessários 28 segundos para construir a imagem, enquanto construir a leva apenas 19 segundos ( ). versão original com camadas minimizadas quase 33% mais rápido ➜ time docker build -t original --no-cache -f original.dockerfile . 0.25s user 0.28s system 2% cpu 19.909 total Vamos verificar o tamanho das imagens. ➜ 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 A imagem com camadas minimizadas é 23 MB menor do que aquela sem camadas minimizadas. Isso é uma . Embora pareça uma pequena diferença neste exemplo, a diferença será muito maior se você dividir todas as instruções em várias linhas. redução de 6% no tamanho RUN Regra nº 3: Instale apenas o necessário Por padrão, instala os pacotes recomendados, assim como os pacotes que você pediu para ele instalar. A opção diz para instalar somente os pacotes que são explicitamente especificados e não os 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 você pode ver, a imagem sem é 70 MB maior que a . Isso é um . --no-install-recommends original aumento de 16% no tamanho o utilitário para ver quais arquivos foram adicionados à imagem – leia mais sobre isso no final do artigo. Use dive Regra nº 4: Limpe após as instalações O original inclui o comando após o comando . Este comando remove as listas de pacotes e arquivos que não são mais necessários após a instalação. Vamos ver como isso afeta o tamanho da imagem, para conseguir isso, criarei um novo . Dockerfile rm -rf /var/lib/apt/lists/* /var/cache/apt/archives apt-get install Dockerfile sem o comando cleaning RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev A criação das imagens leva quase o mesmo tempo que a original, o que faz 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 verificar o tamanho das imagens. ➜ 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 A imagem sem limpeza é 19 MB maior que a com limpeza, o que representa um . aumento de 5% no tamanho O pior cenário E se todas as quatro otimizações mencionadas acima não forem aplicadas? Vamos criar um novo e construir a imagem. Dockerfile sem nenhuma otimização # 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 Uau, demorou mais de um minuto para construir a imagem. ➜ 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 A imagem sem otimizações é 714 MB maior que a original, o que é um . Isso mostra claramente o quão importante é otimizar o , imagens maiores levam mais tempo para serem construídas e consomem mais espaço em disco. aumento de 200% no tamanho Dockerfile Sempre use .dockerignore O arquivo é semelhante ao arquivo usado pelo Git. Ele é usado para excluir arquivos e diretórios do contexto da compilação. O contexto é o conjunto de arquivos e diretórios que são enviados ao daemon do Docker ao compilar uma imagem. O contexto é enviado ao daemon do Docker como um tarball, então é importante mantê-lo o menor possível. .dockerignore .gitignore Se, por algum motivo, você não tiver o arquivo no seu projeto, você pode criá-lo manualmente. Eu sugiro que você use o oficial do Rails como ponto de partida. Abaixo está um exemplo de como ele pode parecer. .dockerignore modelo de arquivo .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* arquivo no projeto não só permite excluir arquivos e diretórios desnecessários (por exemplo, fluxos de trabalho do GitHub da pasta ou dependências JavaScript do ) do contexto. Também ajuda a evitar adicionar acidentalmente informações confidenciais à imagem. Por exemplo, o arquivo que contém as variáveis de ambiente ou o arquivo que é usado para descriptografar as credenciais. Ter um .dockerfile .github node_modules .env master.key Usar mergulho Todas as otimizações mencionadas acima podem parecer óbvias quando explicadas. O que fazer se você já tem uma imagem enorme e não sabe por onde começar? Minha ferramenta favorita e mais útil é . O Dive é uma ferramenta TUI para explorar uma imagem Docker, conteúdo de camadas e descobrir maneiras de reduzir o tamanho da imagem. O Dive pode ser instalado com o gerenciador de pacotes do seu sistema, ou você pode usar sua imagem oficial do Docker para executá-lo. Vamos usar a imagem do nosso pior cenário. o Dive docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations Na captura de tela acima, você pode ver a inspeção da nossa imagem menos otimizada. O Dive mostra o tamanho de cada camada, o tamanho total da imagem e os arquivos que foram alterados (adicionados, modificados ou excluídos) em cada camada. Para mim, esse é o recurso mais útil do Dive. Ao listar os arquivos no painel direito, você pode identificar facilmente os arquivos que não são necessários e remover comandos que os adicionam à imagem. Uma coisa que eu realmente amo sobre o Dive é que, além de ter uma UI de terminal, ele também pode fornecer uma saída amigável ao CI, o que pode ser eficaz em um desenvolvimento local também. Para usá-lo, execute o Dive com a variável de ambiente definida como , a saída do comando está na captura de tela abaixo. CI true docker run -e CI=true --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations Minha preferência pessoal é usar o Dive em uma base programada, por exemplo, uma vez por semana, para garantir que suas imagens ainda estejam em boas condições. Nos próximos artigos, abordarei fluxos de trabalho automatizados que uso para verificar meu Dockerfile, incluindo Dive e . Hadolint Não esmague as camadas Uma abordagem para minimizar o tamanho da imagem que eu vi é tentar comprimir as camadas. A ideia era combinar várias camadas em uma única camada para reduzir o tamanho da imagem. O Docker tinha uma opção experimental , além disso, havia ferramentas de terceiros como . --squash docker-squash Embora essa abordagem tenha funcionado no passado, atualmente ela está obsoleta e não é recomendada para uso. O esmagamento de camadas destruiu o recurso fundamental do Docker de cache de camadas. Além disso, ao usar você pode incluir involuntariamente arquivos sensíveis ou temporários de camadas anteriores na imagem final. Essa é uma abordagem do tipo tudo ou nada que carece de controle refinado. --squash Em vez de esmagar camadas, é recomendado usar builds multi-stage. O Rails já usa builds multi-stage, explicarei como funciona no próximo artigo. Dockerfile Conclusões Otimizar imagens do Docker, assim como qualquer outra otimização, . É um processo contínuo que requer verificações e melhorias regulares. Tentei cobrir o básico, mas é essencial conhecê-lo e entendê-lo. Nos próximos artigos, abordarei técnicas e ferramentas mais avançadas que podem ajudar a tornar suas compilações do Docker mais rápidas e eficientes. não pode ser feito uma vez e esquecido
