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 o 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. alpine debian-slim 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 sa 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 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 ay isang read-only, 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. Docker image layer immutable file system layer Ang mga imahe ng Docker ay binuo nang paunti-unti, patong-patong, at ang bawat layer ay tumutugma sa isang pagtuturo sa . Upang makuha ang mga layer ng imahe, maaari mong patakbuhin ang command . 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 Dahil nakapagbigay na ako ng teorya tungkol sa mga imahe, at mga layer, oras na upang galugarin ang . Simula sa Rails 7.1, ang ay nabuo gamit ang bagong Rails application. Nasa ibaba ang isang halimbawa ng maaaring hitsura nito. 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"] Sa ibaba ay magbibigay ako ng isang listahan ng mga diskarte at panuntunan na kung saan inilapat sa sa itaas upang gawing mahusay ang panghuling laki ng imahe. Dockerfile 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 mula sa Rails Dockerfile sa itaas. Ire-refer ko ito bilang isang na bersyon . ang Dockerfile na nakuha orihinal 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 . Ito ay ang imahe na ginagamit upang lumikha ng lalagyan. Ang batayang imahe ay ang unang layer sa , at ito ang tanging layer na hindi nilikha ng mismo. Dockerfile Dockerfile Dockerfile Tinukoy ang batayang larawan gamit ang utos , na sinusundan ng pangalan at tag ng larawan. Opsyonal ang tag, at kung hindi tinukoy, gagamitin ang tag. Ang batayang imahe ay maaaring maging anumang imahe na magagamit sa Docker Hub o anumang iba pang registry. FROM latest Sa tungkol sa, ginagamit namin ang na imahe na may na tag. Ang image ay na available sa Docker Hub. Ang tag ay isang slim na bersyon ng Ruby image na nakabatay sa na imahe. Habang ang 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 na imahe. Dockerfile ruby 3.4.1-slim ruby ang opisyal na Ruby image 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 Noong Enero, 2024, ang kasalukuyang release ng Debian ay tinatawag na at ang nauna ay . bookworm bullseye 219 MB sa halip na 1GB — isang malaking pagkakaiba. Ngunit paano kung ang imahe ng ay mas maliit? Ang imahe 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 library (sa halip na ) at (isang compact na hanay ng mga Unix utility) sa halip na GNU counterparts. Bagama't teknikal na posibleng gamitin ang na imahe upang patakbuhin ang Rails, hindi ko ito sasaklawin sa artikulong ito. alpine alpine musl glibc busybox alpine 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 , at na pagtuturo sa 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 . Upang ilarawan ang puntong ito, tingnan natin ang halimbawa sa ibaba. 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!"] Hinati ko ang pagtuturo sa maraming linya, na malinaw na ginagawa itong mas . Ngunit paano ito makakaapekto sa laki ng larawan? Buuin natin ang imahe at tingnan ito. RUN nababasa ng tao ➜ 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 ay tumatagal lamang ng 19 segundo ( ). orihinal na bersyon na may pinaliit na mga layer 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 . Bagama't tila isang maliit na pagkakaiba sa halimbawang ito, ang pagkakaiba ay magiging mas malaki kung hahatiin mo ang lahat ng mga tagubilin sa maraming linya. 6% na pagbawas sa laki RUN Panuntunan #3: I-install lamang ang kailangan Bilang default, ini-install ang mga inirerekomendang package pati na rin ang mga package na hiniling mong i-install nito. Ang na opsyon ay nagsasabi na i-install lamang ang mga pakete na tahasang tinukoy at hindi ang mga inirerekomenda. 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 Gaya ng nakikita mo, ang larawang walang ay 70 MB na mas malaki kaysa sa . Ito ay isang . --no-install-recommends orihinal 16% na pagtaas sa laki utility para makita kung aling mga file ang idinagdag sa larawan – magbasa pa tungkol dito sa dulo ng artikulo. Gumamit ng dive Panuntunan #4: Maglinis pagkatapos ng pag-install Kasama sa orihinal ang command pagkatapos ng 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 rm -rf /var/lib/apt/lists/* /var/cache/apt/archives apt-get install 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 at buuin ang imahe. Dockerfile nang walang anumang mga pag-optimize # 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 . Malinaw na ipinapakita nito kung gaano kahalaga ang pag-optimize ng , ang mas malalaking larawan ay tumatagal ng mas maraming oras upang bumuo at kumonsumo ng mas maraming espasyo sa disk. 200% na pagtaas sa laki Dockerfile Palaging gumamit ng .dockerignore Ang file ay katulad ng 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. .dockerignore .gitignore Kung, sa anumang kadahilanan, wala kang na file sa iyong proyekto, maaari mo itong gawin nang manu-mano. Iminumungkahi kong gamitin mo ang opisyal na Rails bilang panimulang punto. Nasa ibaba ang isang halimbawa ng maaaring hitsura nito. .dockerignore .dockerignore file template # 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* file sa proyekto ay hindi lamang nagbibigay-daan sa pagbubukod ng mga hindi kinakailangang file at direktoryo (hal., GitHub workflows mula sa folder o JavaScript dependencies mula sa ) mula sa konteksto. Nakakatulong din ito upang maiwasan ang aksidenteng pagdaragdag ng sensitibong impormasyon sa larawan. Halimbawa, ang file na naglalaman ng mga variable ng kapaligiran o ang file na ginagamit upang i-decrypt ang mga kredensyal. Ang pagkakaroon ng .dockerfile .github node_modules .env master.key 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 . 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. Dive 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 environment variable na nakatakda sa , ang output ng command ay nasa screenshot sa ibaba. CI true 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 , bukod dito, may mga third-party na tool tulad ng . --squash 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 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. --squash Sa halip na lapigin ang mga layer, inirerekumenda na gumamit ng mga multi-stage build. Gumagamit na ang Rails ng mga multi-stage build, ipapaliwanag ko kung paano ito gumagana sa susunod na artikulo. Dockerfile Mga konklusyon Ang pag-optimize ng mga imahe ng Docker, tulad ng anumang iba pang pag-optimize, . 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. ay hindi maaaring gawin nang isang beses at nakalimutan
