Докерын зургуудыг оновчтой болгох нь зөвхөн нэг бөгөөд хийсэн зүйл биш юм

Энэ нийтлэл нь би Rails-ийн анхдагч Dockerfile-ийн мөр бүрийг үзэж, шилдэг туршлагууд болон оновчлолуудыг тайлбарлах цуврал нийтлэлүүдийн нэг хэсэг юм.

Докерийн зургуудыг зургийн хэмжээг багасгах, бүтээмжийг оновчтой болгох, аюулгүй байдал, засвар үйлчилгээ хийх шилдэг туршлагууд, програмын онцлогт тохирсон оновчлол зэргийг багтаасан боловч үүгээр хязгаарлагдахгүй өөр өөр аргаар оновчтой болгож болно. Эхний нийтлэлд би зөвхөн зургийн хэмжээг багасгах оновчлолыг хөндөж, яагаад чухал болохыг тайлбарлах болно.

Яагаад зургийн хэмжээг оновчтой болгох вэ?

Програм хангамж хөгжүүлэх бусад үйл явцын нэгэн адил хөгжүүлэгч бүр яагаад Docker-ийн бүтээцийг илүү хурдан болгохыг хүссэн шалтгаанаа жагсаах болно. Миний хувьд хамгийн чухал шалтгаануудыг жагсаах болно.

Илүү хурдан бүтээх, байршуулах

Цөөн файл, давхаргыг боловсруулах шаардлагатай тул жижиг зургуудыг бүтээхэд илүү хурдан байдаг. Энэ нь хөгжүүлэгчийн бүтээмжийг сайжруулдаг, ялангуяа давтагдах хөгжлийн мөчлөгийн үед. Жижиг зургуудыг байршуулах явцад бүртгэл рүү түлхэж, түүнээс татахад бага хугацаа зарцуулдаг. Энэ нь ихэвчлэн чингэлэг барьж, байрлуулдаг CI/CD дамжуулах хоолойд онцгой чухал юм.

Хадгалах зардал, сүлжээний зурвасын өргөн ашиглалтыг бууруулсан

Жижиг зургууд нь контейнерийн бүртгэл, локал хөгжүүлэлтийн машинууд болон үйлдвэрлэлийн серверүүд дээр бага хэмжээний санах ой зарцуулдаг. Энэ нь дэд бүтцийн зардал, ялангуяа томоохон хэмжээний ашиглалтын зардлыг бууруулдаг. Жижиг зургуудыг сервер хооронд шилжүүлэхэд бага зурвасын өргөнийг ашигладаг, ялангуяа та дотоод эсвэл CI/CD дамжуулах шугам дээр зураг бүтээж, бүртгэл рүү түлхэж байх үед чухал юм.

"Бид 2022 онд үүлэнд 3.2 сая доллар зарцуулсан... Бид үүлэнд гарснаар таван жилийн хугацаанд серверийн зардлыг 7 сая орчим доллар хэмнэх болно." David Heinemeier Hansson - HEY World

Гүйцэтгэл, аюулгүй байдал сайжирсан

Жижиг зургуудыг ачаалах, ажиллуулахын тулд бага нөөц (жишээ нь: CPU, RAM) шаардагддаг бөгөөд энэ нь контейнержүүлсэн програмуудын ерөнхий гүйцэтгэлийг сайжруулдаг. Илүү хурдан эхлүүлэх нь таны үйлчилгээ илүү хурдан бэлэн болно гэсэн үг бөгөөд энэ нь цар хүрээг нэмэгдүүлэх, өндөр хүртээмжтэй системд чухал ач холбогдолтой юм. alpine эсвэл debian-slim зэрэг хамгийн бага үндсэн зургууд нь урьдчилан суулгасан багцуудыг бага агуулж, засвар хийгдээгүй эсвэл шаардлагагүй программ хангамжийг ашиглах эрсдлийг бууруулдаг.

Дээр дурдсан бүх зүйлээс гадна шаардлагагүй файл, хэрэгслийг устгах нь асуудлыг оношлоход анхаарал сарниулах явдлыг багасгаж, засвар үйлчилгээг сайжруулах, техникийн өрийг бууруулахад хүргэдэг.

Docker зургуудыг шалгаж байна

Зургийн янз бүрийн параметрүүдийг, түүний дотор хэмжээг авахын тулд та Docker Desktop-г харах эсвэл терминал дахь 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

Зургийн хэмжээг мэдэх нь танд бүрэн дүр зургийг өгөхгүй. Зурган дотор юу байгаа, хэдэн давхаргатай, давхарга бүр нь хэр том болохыг та мэдэхгүй. Docker зургийн давхарга нь зөвхөн уншигдах боломжтой, хувиршгүй файлын системийн давхарга бөгөөд Docker зургийн бүрэлдэхүүн хэсэг юм. Давхарга бүр нь файл нэмэх, тохиргоог өөрчлөх, программ суулгах гэх мэт зургийн файлын системд хийсэн өөрчлөлтүүдийн багцыг илэрхийлдэг.

Докерын зургуудыг давхарга бүрээр үе шаттайгаар бүтээдэг бөгөөд давхарга бүр нь 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

Би аль хэдийн зураг, давхаргын тухай онолыг өгсөн тул Dockerfile г судлах цаг болжээ. Rails 7.1-ээс эхлэн Dockerfile нь шинэ Rails програмаар үүсгэгддэг. Доорх нь ямар харагдаж болох жишээг доор харуулав.

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

Доор би зургийн эцсийн хэмжээг үр ашигтай болгохын тулд дээрх Dockerfile -д хэрэглэгдэх арга, дүрмийн жагсаалтыг өгөх болно.

Багцын суулгацыг оновчтой болгох

Та орон нутгийн хөгжүүлэлтийн машин дээрээ зөвхөн шаардлагатай программ хангамжийг хадгалдаг гэдэгт итгэлтэй байна. Үүнтэй ижил зүйлийг Docker зургуудад ашиглах ёстой. Доорх жишээнүүдэд би дээрх Rails Dockerfile-аас гаргаж авсан Dockerfile-ийг улам бүр дордуулах болно. Би үүнийг Dockerfile анхны хувилбар гэж үзэх болно.

Дүрэм №1: Хамгийн бага үндсэн зургийг ашигла

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

Үндсэн зураг нь Dockerfile ийн эхлэлийн цэг юм. Энэ нь савыг бүтээхэд ашигладаг зураг юм. Үндсэн зураг нь Dockerfile ийн эхний давхарга бөгөөд энэ нь Dockerfile өөрөө үүсгээгүй цорын ганц давхарга юм.

Үндсэн дүрсийг FROM командын тусламжтайгаар зааж өгсний дараа зургийн нэр, шошго бичнэ. Шошго нь сонголттой бөгөөд хэрэв заагаагүй бол latest шошгыг ашиглана. Үндсэн зураг нь Docker Hub эсвэл бусад бүртгэл дээр байгаа ямар ч зураг байж болно.

Dockerfile about дээр бид 3.4.1-slim шошготой ruby дүрсийг ашиглаж байна. ruby зураг нь Docker Hub дээр байгаа албан ёсны Ruby зураг юм. 3.4.1-slim шошго нь debian-slim зураг дээр суурилсан Ruby зургийн нарийхан хувилбар юм. debian-slim дүрс нь Debian Linux зургийн хамгийн бага хувилбар бөгөөд хэмжээ нь оновчтой байдаг. 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

2024 оны 1-р сарын байдлаар Debian-ийн одоогийн хувилбарыг номын хорхой гэж нэрлэдэг бол өмнөх хувилбар нь bullseye юм.

1 ГБ-ын оронд 219 MB - асар их ялгаа. Харин alpine зураг үүнээс ч бага байвал яах вэ? alpine зураг нь Alpine Linux түгээлт дээр суурилдаг бөгөөд энэ нь хэмжээ, аюулгүй байдлын хувьд оновчтой болсон супер хөнгөн Линукс түгээлт юм. Alpine нь GNU-ийн оронд musl library ( glibc ийн оронд) болон busybox (Unix хэрэгслүүдийн авсаархан багц) ашигладаг. Rails-ийг ажиллуулахын тулд alpine зургийг ашиглах техникийн хувьд боломжтой ч би энэ нийтлэлд энэ талаар ярихгүй.

Дүрэм №2: Давхаргыг багасгах

 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

Dockerfile дахь RUN , COPY , FROM заавар бүр шинэ давхарга үүсгэдэг. Илүү олон давхарга байх тусам зургийн хэмжээ том болно. Ийм учраас олон командыг нэг 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!"]

Би RUN зааврыг олон мөрөнд хуваасан бөгөөд энэ нь тэднийг илүү хүнд уншихад хялбар болгосон нь ойлгомжтой. Гэхдээ энэ нь зургийн хэмжээнд хэрхэн нөлөөлөх вэ? Зургийг бүтээж, шалгацгаая.

 ➜ 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

Зургийг бүтээхэд 28 секунд зарцуулсан бол давхаргыг багасгасан анхны хувилбарыг бүтээхэд ердөө 19 секунд шаардлагатай ( бараг 33% хурдан ).

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

Зургуудын хэмжээг шалгацгаая.

 ➜ 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

Давхаргыг багасгасан зураг нь жижигрүүлсэн давхаргагүй зургаас 23 МБ-аар бага байна. Энэ нь хэмжээ нь 6% буурсан байна . Энэ жишээн дээр бага зэргийн ялгаа мэт санагдаж байгаа ч, хэрэв та бүх RUN зааврыг олон мөрөнд хуваавал ялгаа нь илүү их байх болно.

Дүрэм №3: Зөвхөн шаардлагатай зүйлийг суулгана уу

Анхдагч байдлаар, 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

Таны харж байгаагаар --no-install-recommends гүй зураг анхныхаасаа 70 МБ том байна. Энэ нь хэмжээ нь 16% өссөн байна .

Зурагт ямар файл нэмэгдсэнийг харахын тулд шумбах хэрэгслийг ашиглана уу - нийтлэлийн төгсгөлд энэ талаар дэлгэрэнгүй уншина уу.

Дүрэм №4: Суулгасны дараа цэвэрлэх

Анхны Dockerfile нь apt-get install командын дараа rm -rf /var/lib/apt/lists/* /var/cache/apt/archives командыг агуулдаг. Энэ тушаал нь суулгасны дараа шаардлагагүй болсон багцын жагсаалт болон архивыг устгадаг. Энэ нь зургийн хэмжээнд хэрхэн нөлөөлж байгааг харцгаая, үүнд хүрэхийн тулд би цэвэрлэх командгүйгээр шинэ Dockerfile үүсгэх болно.

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

Зургийг бүтээхэд анхныхтай бараг ижил хугацаа шаардагдах бөгөөд энэ нь утга учиртай юм.

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

Зургуудын хэмжээг шалгацгаая.

 ➜ 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

Цэвэрлэгээгүй зураг нь цэвэрлэсэн зургаас 19 МБ том бөгөөд энэ нь хэмжээ нь 5% нэмэгдсэн байна.

Хамгийн муу хувилбар

Дээр дурдсан дөрвөн оновчлолыг бүгдийг нь ашиглаагүй бол яах вэ? Ямар ч оновчлолгүйгээр шинэ Dockerfile үүсгэж, дүрсийг бүтээцгээе.

 # 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

Хөөх, зургийг бүтээхэд нэг минут гаруй хугацаа зарцуулагдсан.

 ➜ 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

Оновчлолгүй зураг нь анхныхаасаа 714 МБ том бөгөөд энэ нь хэмжээ нь 200% нэмэгдсэн байна. Энэ нь Dockerfile оновчтой болгох нь хэр чухал болохыг тодорхой харуулж байгаа тул том зургуудыг бүтээхэд илүү их цаг зарцуулж, илүү их зай эзэлдэг.

.dockerignore-г үргэлж ашиглаарай

.dockerignore файл нь Git-ийн ашигладаг .gitignore файлтай төстэй. Энэ нь барилгын контекстээс файл, лавлахыг хасахад хэрэглэгддэг. Контекст нь зураг бүтээх үед Docker дэмон руу илгээгддэг файлууд болон сангуудын багц юм. Контекстийг Docker дэмон руу tarball хэлбэрээр илгээдэг тул үүнийг аль болох бага байлгах нь чухал юм.

Хэрэв ямар нэг шалтгааны улмаас таны төсөлд .dockerignore файл байхгүй бол та үүнийг гараар үүсгэж болно. Би танд албан ёсны Rails .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*

Төсөлд .dockerfile файл байгаа нь шаардлагагүй файлууд болон сангуудыг (жишээ нь, .github фолдероос GitHub ажлын урсгал эсвэл node_modules -аас JavaScript хамаарал) контекстээс хасах боломжийг олгодоггүй. Энэ нь зураг дээр санамсаргүй байдлаар нууц мэдээллийг нэмэхээс зайлсхийхэд тусалдаг. Жишээлбэл, орчны хувьсагчдыг агуулсан .env файл эсвэл итгэмжлэлийг тайлахад ашигладаг master.key файл.

Dive ашиглана уу

Дээр дурдсан бүх оновчлолыг тайлбарлахад ойлгомжтой мэт санагдаж магадгүй юм. Хэрэв танд асар том дүр төрх байгаа бол хаанаас эхлэхээ мэдэхгүй байгаа бол яах вэ?

Миний дуртай бөгөөд хамгийн хэрэгтэй хэрэгсэл бол Dive юм. Dive нь Docker-ийн зураг, давхаргын агуулгыг судлах, зургийн хэмжээг багасгах арга замыг олоход зориулагдсан TUI хэрэгсэл юм. Dive-г өөрийн системийн багц менежерээр суулгаж болно, эсвэл албан ёсны Docker дүрсийг ашиглан ажиллуулж болно. Хамгийн муу хувилбарынхаа зургийг ашиглацгаая.

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

Дээрх дэлгэцийн агшин дээр та бидний хамгийн оновчтой бус зургийг шалгаж үзэх боломжтой. Dive нь давхарга бүрийн хэмжээ, зургийн нийт хэмжээ, давхарга бүрт өөрчлөгдсөн (нэмсэн, өөрчилсөн, устгасан) файлуудыг харуулдаг. Миний хувьд энэ бол Dive-ийн хамгийн хэрэгтэй шинж чанар юм. Баруун талын самбарт байгаа файлуудыг жагсааснаар та шаардлагагүй файлуудыг хялбархан тодорхойлж, тэдгээрийг зурган дээр нэмэх командуудыг устгаж болно.

Dive-д үнэхээр дуртай нэг зүйл бол терминалын UI-тай байхаас гадна орон нутгийн хөгжилд үр дүнтэй байж болох CI-д ээлтэй гаралтыг өгч чаддаг явдал юм. Үүнийг ашиглахын тулд Dive-г CI орчны хувьсагчийг true гэж тохируулан ажиллуулна, командын гаралтыг доорх дэлгэцийн зураг дээр харуулав.

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

Миний хувийн сонголт бол дүр төрхөө сайн байлгахын тулд Dive-г хуваарийн дагуу, жишээлбэл, долоо хоногт нэг удаа ашиглах явдал юм. Дараагийн нийтлэлүүдэд би Dockerfile-ээ шалгахдаа ашигладаг автоматжуулсан ажлын урсгалууд, үүнд Dive болон Hadolint зэрэг багтана.

Давхаргыг шахаж болохгүй

Миний харсан зургийн хэмжээг багасгах нэг арга бол давхаргыг дарах явдал юм. Зургийн хэмжээг багасгахын тулд хэд хэдэн давхаргыг нэг давхаргад нэгтгэх санаа байв. Docker-д туршилтын хувилбар байсан --squash , үүнээс гадна docker-squash гэх мэт гуравдагч талын хэрэгслүүд байсан.

Энэ арга нь өмнө нь ажиллаж байсан ч одоогоор хуучирсан бөгөөд ашиглахыг зөвлөдөггүй. Давхаргыг дарах нь Докерын давхаргын кэш хийх үндсэн шинж чанарыг устгасан. Үүнээс гадна, --squash ашиглах үед та санамсаргүйгээр өмнөх давхаргуудын мэдрэмтгий эсвэл түр зуурын файлуудыг эцсийн зурагт оруулах боломжтой. Энэ бол бүх зүйл эсвэл юу ч биш гэсэн нарийн хяналтгүй хандлага юм.

Давхаргыг шахахын оронд олон үе шаттай барилга байгууламжийг ашиглахыг зөвлөж байна. Rails Dockerfile аль хэдийн олон үе шаттай бүтээцүүдийг ашигладаг бөгөөд энэ нь хэрхэн ажилладаг талаар дараагийн өгүүллээр тайлбарлах болно.

Дүгнэлт

Бусад оновчлолын нэгэн адил Docker-ийн зургийг оновчлох нь нэг удаа хийгээд мартагдах боломжгүй . Энэ нь байнгын шалгалт, сайжруулалтыг шаарддаг тасралтгүй үйл явц юм. Би үндсийг нь тусгах гэж оролдсон ч мэдэж, ойлгоход маш чухал. Дараагийн нийтлэлүүдэд би Docker-ийн бүтээцийг илүү хурдан, үр ашигтай болгоход туслах илүү дэвшилтэт техник, хэрэгслүүдийг авч үзэх болно.