Ang Pag-optimize sa Mga Imahe ng Docker ay Higit pa sa Isa at Tapos na Bagay

Ang artikulong ito ay bahagi ng isang serye ng mga post kung saan tatahakin ko ang bawat linya ng Rails default na Dockerfile at ipapaliwanag ang pinakamahuhusay na kagawian at pag-optimize.

Maaaring i-optimize ang mga larawan ng Docker sa iba't ibang paraan na kinabibilangan, ngunit hindi limitado sa, pagbawas sa laki ng imahe, pagbuo ng pag-optimize ng pagganap, seguridad, at pinakamahuhusay na kagawian sa pagpapanatili, at mga pag-optimize na partikular sa application. Sa unang artikulo, hahawakan ko lamang ang pag-optimize ng pagbawas ng laki ng imahe at ipaliwanag kung bakit mahalaga ang mga ito.

Bakit i-optimize ang laki ng larawan?

Tulad ng sa bawat iba pang proseso ng software development, ililista ng bawat developer ang kanyang mga dahilan kung bakit gusto niyang gawing mas mabilis ang kanyang Docker build. Ililista ko ang mga dahilan na pinakamahalaga sa akin.

Mas mabilis na mga build at deployment

Mas mabilis na buuin ang mas maliliit na larawan dahil mas kaunting mga file at layer ang kailangang iproseso. Pinapabuti nito ang pagiging produktibo ng developer, lalo na sa panahon ng umuulit na mga siklo ng pag-unlad. Ang mas maliliit na larawan ay tumatagal ng mas kaunting oras upang itulak sa isang registry at hilahin mula dito sa panahon ng mga pag-deploy. Ito ay partikular na kritikal sa mga pipeline ng CI/CD kung saan ang mga container ay binuo at madalas i-deploy.

Binawasan ang mga gastos sa storage at paggamit ng bandwidth ng network

Ang mas maliliit na larawan ay kumokonsumo ng mas kaunting storage sa mga container registry, local development machine, at production server. Binabawasan nito ang mga gastos sa imprastraktura, lalo na para sa malalaking deployment. Ang mas maliliit na larawan ay gumagamit ng mas kaunting bandwidth kapag inilipat sa pagitan ng mga server, lalo na mahalaga kapag gumagawa ka ng mga imahe nang lokal o sa mga pipeline ng CI/CD at itinutulak ang mga ito sa isang registry.

“Gumastos kami ng $3.2m sa cloud noong 2022... Naninindigan kaming makatipid ng humigit-kumulang $7m sa mga gastos sa server sa loob ng limang taon mula sa aming cloud exit.” David Heinemeier Hansson — HOY Mundo

Pinahusay na pagganap at seguridad

Ang mas maliliit na larawan ay nangangailangan ng mas kaunting mga mapagkukunan (hal., CPU, RAM) upang mag-load at tumakbo, na pagpapabuti sa pangkalahatang pagganap ng mga containerized na application. Ang mas mabilis na mga oras ng pagsisimula ay nangangahulugan na ang iyong mga serbisyo ay handa nang mas mabilis, na mahalaga para sa pag-scale at mga system na may mataas na kakayahang magamit. Ang mga pinakamababang larawan tulad ng alpine o debian-slim ay naglalaman ng mas kaunting paunang naka-install na mga pakete, na nagpapababa sa panganib ng hindi na-patch o hindi kinakailangang software na pinagsamantalahan.

Bukod sa lahat ng nabanggit sa itaas, ang pag-alis ng mga hindi kinakailangang file at tool ay nagpapaliit ng mga abala kapag nag-diagnose ng mga isyu at humahantong sa mas mahusay na pagpapanatili at nabawasan ang teknikal na utang.

Sinusuri ang mga larawan ng Docker

Upang makakuha ng iba't ibang mga parameter ng imahe, kabilang ang laki, maaari mong tingnan ang Docker Desktop o patakbuhin ang command ng docker images sa terminal.

 ➜ 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

Ang pag-alam sa laki ng larawan ay hindi nagbibigay sa iyo ng buong larawan. Hindi mo alam kung ano ang nasa loob ng larawan, kung gaano karaming mga layer mayroon ito, o kung gaano kalaki ang bawat layer. Ang Docker image layer ay isang read-only, immutable file system layer na bahagi ng isang Docker image. Ang bawat layer ay kumakatawan sa isang hanay ng mga pagbabagong ginawa sa file system ng imahe, tulad ng pagdaragdag ng mga file, pagbabago ng mga configuration, o pag-install ng software.

Ang mga imahe ng Docker ay binuo nang paunti-unti, patong-patong, at ang bawat layer ay tumutugma sa isang pagtuturo sa Dockerfile . Upang makuha ang mga layer ng imahe, maaari mong patakbuhin ang command 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

Dahil nakapagbigay na ako ng teorya tungkol sa mga imahe, at mga layer, oras na upang galugarin ang Dockerfile . Simula sa Rails 7.1, ang Dockerfile ay nabuo gamit ang bagong Rails application. Nasa ibaba ang isang halimbawa ng maaaring hitsura nito.

 # 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"]

Sa ibaba ay magbibigay ako ng isang listahan ng mga diskarte at panuntunan na kung saan inilapat sa Dockerfile sa itaas upang gawing mahusay ang panghuling laki ng imahe.

I-optimize ang mga pag-install ng package

Natitiyak kong pinapanatili mo lamang ang kinakailangang software sa iyong lokal na makina ng pagpapaunlad. Ang parehong ay dapat ilapat sa mga imahe ng Docker. Sa mga halimbawa sa ibaba ay patuloy kong papalalain ang Dockerfile na nakuha mula sa Rails Dockerfile sa itaas. Ire-refer ko ito bilang isang orihinal na bersyon Dockerfile .

Panuntunan #1: Gumamit ng kaunting mga batayang larawan

 FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

Ang batayang imahe ay ang panimulang punto para sa Dockerfile . Ito ay ang imahe na ginagamit upang lumikha ng lalagyan. Ang batayang imahe ay ang unang layer sa Dockerfile , at ito ang tanging layer na hindi nilikha ng Dockerfile mismo.

Tinukoy ang batayang larawan gamit ang utos FROM , na sinusundan ng pangalan at tag ng larawan. Opsyonal ang tag, at kung hindi tinukoy, gagamitin ang latest tag. Ang batayang imahe ay maaaring maging anumang imahe na magagamit sa Docker Hub o anumang iba pang registry.

Sa Dockerfile tungkol sa, ginagamit namin ang ruby na imahe na may 3.4.1-slim na tag. Ang ruby image ay ang opisyal na Ruby image na available sa Docker Hub. Ang 3.4.1-slim tag ay isang slim na bersyon ng Ruby image na nakabatay sa debian-slim na imahe. Habang ang debian-slim na imahe ay isang minimal na bersyon ng imahe ng Debian Linux na na-optimize para sa laki. Tingnan ang talahanayan sa ibaba upang makakuha ng ideya kung gaano kaliit ang slim na imahe.

 ➜ 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

Noong Enero, 2024, ang kasalukuyang release ng Debian ay tinatawag na bookworm at ang nauna ay bullseye .

219 MB sa halip na 1GB — isang malaking pagkakaiba. Ngunit paano kung ang imahe ng alpine ay mas maliit? Ang imahe alpine ay batay sa pamamahagi ng Alpine Linux, na isang napakagaan na pamamahagi ng Linux na na-optimize para sa laki at seguridad. Ginagamit ng Alpine ang musl library (sa halip na glibc ) at busybox (isang compact na hanay ng mga Unix utility) sa halip na GNU counterparts. Bagama't teknikal na posibleng gamitin ang alpine na imahe upang patakbuhin ang Rails, hindi ko ito sasaklawin sa artikulong ito.

Panuntunan #2: I-minimize ang mga layer

 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

Ang bawat RUN , COPY at FROM na pagtuturo sa Dockerfile ay lumilikha ng bagong layer. Kung mas maraming layer ang mayroon ka, mas malaki ang laki ng larawan. Ito ang dahilan kung bakit ang pinakamahusay na kasanayan ay upang pagsamahin ang maramihang mga utos sa isang solong pagtuturo RUN . Upang ilarawan ang puntong ito, tingnan natin ang halimbawa sa ibaba.

 # 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!"]

Hinati ko ang pagtuturo RUN sa maraming linya, na malinaw na ginagawa itong mas nababasa ng tao . Ngunit paano ito makakaapekto sa laki ng larawan? Buuin natin ang imahe at tingnan ito.

 ➜ 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

Tumagal ng 28 segundo upang mabuo ang imahe, habang ang pagbuo ng orihinal na bersyon na may pinaliit na mga layer ay tumatagal lamang ng 19 segundo ( halos 33% na mas mabilis ).

 ➜ time docker build -t original --no-cache -f original.dockerfile . 0.25s user 0.28s system 2% cpu 19.909 total

Suriin natin ang laki ng mga larawan.

 ➜ 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

Ang larawang may pinaliit na mga layer ay 23 MB na mas maliit kaysa sa isang walang pinaliit na mga layer. Ito ay isang 6% na pagbawas sa laki . Bagama't tila isang maliit na pagkakaiba sa halimbawang ito, ang pagkakaiba ay magiging mas malaki kung hahatiin mo ang lahat ng mga tagubilin RUN sa maraming linya.

Panuntunan #3: I-install lamang ang kailangan

Bilang default, ini-install apt-get install ang mga inirerekomendang package pati na rin ang mga package na hiniling mong i-install nito. Ang --no-install-recommends na opsyon ay nagsasabi apt-get na i-install lamang ang mga pakete na tahasang tinukoy at hindi ang mga inirerekomenda.

 ➜ 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

Gaya ng nakikita mo, ang larawang walang --no-install-recommends ay 70 MB na mas malaki kaysa sa orihinal . Ito ay isang 16% na pagtaas sa laki .

Gumamit ng dive utility para makita kung aling mga file ang idinagdag sa larawan – magbasa pa tungkol dito sa dulo ng artikulo.

Panuntunan #4: Maglinis pagkatapos ng pag-install

Kasama sa orihinal Dockerfile ang rm -rf /var/lib/apt/lists/* /var/cache/apt/archives command pagkatapos ng apt-get install command. Inaalis ng command na ito ang mga listahan ng package at mga archive na hindi na kailangan pagkatapos ng pag-install. Tingnan natin kung paano ito nakakaapekto sa laki ng imahe, para makamit iyon, gagawa ako ng bagong Dockerfile nang walang cleaning command .

 RUN apt-get update -qq && \ apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev

Ang pagbuo ng mga imahe ay tumatagal ng halos kapareho ng oras ng orihinal, na may katuturan.

 ➜ time docker build -t without-cleaning --no-cache -f without-cleaning.dockerfile . 0.28s user 0.30s system 2% cpu 21.658 total

Suriin natin ang laki ng mga larawan.

 ➜ 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

Ang larawang walang nililinis ay 19 MB na mas malaki kaysa sa isang may paglilinis, ito ay isang 5% na pagtaas sa laki .

Ang pinakamasamang senaryo

Paano kung ang lahat ng apat na pag-optimize na nabanggit sa itaas ay hindi nailapat? Gumawa tayo ng bagong Dockerfile nang walang anumang mga pag-optimize at buuin ang imahe.

 # 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

Wow, tumagal ng higit sa isang minuto upang mabuo ang imahe.

 ➜ 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

Ang larawang walang mga pag-optimize ay 714 MB na mas malaki kaysa sa orihinal, ito ay isang 200% na pagtaas sa laki . Malinaw na ipinapakita nito kung gaano kahalaga ang pag-optimize ng Dockerfile , ang mas malalaking larawan ay tumatagal ng mas maraming oras upang bumuo at kumonsumo ng mas maraming espasyo sa disk.

Palaging gumamit ng .dockerignore

Ang .dockerignore file ay katulad ng .gitignore file na ginamit ng Git. Ginagamit ito upang ibukod ang mga file at direktoryo mula sa konteksto ng build. Ang konteksto ay ang hanay ng mga file at direktoryo na ipinadala sa Docker daemon kapag bumubuo ng isang imahe. Ang konteksto ay ipinadala sa Docker daemon bilang isang tarball, kaya mahalagang panatilihin itong maliit hangga't maaari.

Kung, sa anumang kadahilanan, wala kang .dockerignore na file sa iyong proyekto, maaari mo itong gawin nang manu-mano. Iminumungkahi kong gamitin mo ang opisyal na Rails .dockerignore file template bilang panimulang punto. Nasa ibaba ang isang halimbawa ng maaaring hitsura nito.

 # 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*

Ang pagkakaroon ng .dockerfile file sa proyekto ay hindi lamang nagbibigay-daan sa pagbubukod ng mga hindi kinakailangang file at direktoryo (hal., GitHub workflows mula sa .github folder o JavaScript dependencies mula sa node_modules ) mula sa konteksto. Nakakatulong din ito upang maiwasan ang aksidenteng pagdaragdag ng sensitibong impormasyon sa larawan. Halimbawa, ang .env file na naglalaman ng mga variable ng kapaligiran o ang master.key file na ginagamit upang i-decrypt ang mga kredensyal.

Gumamit ng Dive

Ang lahat ng mga pag-optimize na nabanggit sa itaas ay maaaring mukhang halata kapag ipinaliwanag. Ano ang gagawin kung mayroon ka nang napakalaking imahe, at hindi mo alam kung saan magsisimula?

Ang paborito at pinakakapaki-pakinabang kong tool ay Dive . Ang Dive ay isang tool ng TUI para sa paggalugad ng imahe ng Docker, mga nilalaman ng layer, at pagtuklas ng mga paraan upang paliitin ang laki ng larawan. Maaaring mai-install ang dive sa iyong system package manager, o maaari mong gamitin ang opisyal na larawan ng Docker nito upang patakbuhin ito. Gamitin natin ang larawan mula sa pinakamasama nating senaryo.

 docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations 

Sa screenshot sa itaas, makikita mo ang inspeksyon ng aming pinaka-hindi-optimal na larawan. Ipinapakita ng dive ang laki ng bawat layer, ang kabuuang sukat ng imahe, at ang mga file na binago (idinagdag, binago, o tinanggal) sa bawat layer. Para sa akin, ito ang pinakakapaki-pakinabang na feature ng Dive. Sa pamamagitan ng paglilista ng mga file sa kanang panel, madali mong matukoy ang mga file na hindi kailangan at maalis ang mga command na nagdaragdag sa mga ito sa larawan.

Ang isang bagay na talagang gusto ko tungkol sa Dive ay na, bukod sa pagkakaroon ng terminal UI, maaari rin itong magbigay ng isang CI-friendly na output, na maaaring maging epektibo din sa isang lokal na pag-unlad. Para magamit ito, patakbuhin ang Dive gamit ang CI environment variable na nakatakda sa true , ang output ng command ay nasa screenshot sa ibaba.

 docker run -e CI=true --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations 

Ang aking personal na kagustuhan ay ang paggamit ng Dive sa isang naka-iskedyul na batayan, halimbawa, isang beses sa isang linggo, upang matiyak na ang iyong mga larawan ay nasa magandang hugis pa rin. Sa mga paparating na artikulo, tatalakayin ko ang mga awtomatikong daloy ng trabaho na ginagamit ko upang suriin ang aking Dockerfile, kasama ang Dive at Hadolint .

Huwag mag-squash ng mga layer

Ang isang diskarte sa pagliit ng laki ng imahe na nakita ko ay ang subukang i-squash ang mga layer. Ang ideya ay upang pagsamahin ang ilang mga layer sa isang solong layer upang mabawasan ang laki ng imahe. Ang Docker ay may isang pang-eksperimentong opsyon --squash , bukod dito, may mga third-party na tool tulad ng docker-squash .

Bagama't nagtrabaho ang diskarteng ito sa nakaraan, sa kasalukuyan ay hindi na ito ginagamit at hindi inirerekomendang gamitin. Sinira ng mga squashing layer ang pangunahing tampok ng Docker ng layer caching. Bukod doon, habang gumagamit ng --squash maaari mong hindi sinasadyang isama ang mga sensitibo o pansamantalang file mula sa mga naunang layer sa huling larawan. Isa itong all-or-nothing approach na walang pinong kontrol.

Sa halip na lapigin ang mga layer, inirerekumenda na gumamit ng mga multi-stage build. Gumagamit na ang Rails Dockerfile ng mga multi-stage build, ipapaliwanag ko kung paano ito gumagana sa susunod na artikulo.

Mga konklusyon

Ang pag-optimize ng mga imahe ng Docker, tulad ng anumang iba pang pag-optimize, ay hindi maaaring gawin nang isang beses at nakalimutan . Ito ay isang patuloy na proseso na nangangailangan ng mga regular na pagsusuri at pagpapahusay. Sinubukan kong saklawin ang mga pangunahing kaalaman, ngunit ang mga ito ay kritikal na malaman at maunawaan. Sa mga susunod na artikulo, tatalakayin ko ang mas advanced na mga diskarte at tool na makakatulong upang gawing mas mabilis at mas mahusay ang iyong Docker.