Англійська для Docker Multi-Stage Builds

Виробничий образ, який доставляє весь ланцюжок інструментів компілятора разом з скомпільованим бінарним файлом, роздутий і важче забезпечити безпеку - багатоетапні збірки вирішують це, відокремлюючи «збирання середовища» від «средства выполнения», і називаючи це розділення саме тим, що робить перегляд Dockerfile продуктивним.

Ключовий словник

** Фаза збирання ** — розділ з назвою файла Dockerfile ( FROM node AS builder ), який виконує компіляцію, встановлення залежностей або з’ єднання, проміжні шари якого ніколи не надсилаються у кінцевий штамп, якщо їх не було явно скопійовано. “На етапі збирання встановлюються всі залежності від розробника і запускається компілятор TypeScript, але жодна з цих частин не потрапляє до кінцевого образу — це робить тільки скомпільований JavaScript.”

** COPY — from ** — інструкція, яка витягує певні файли або каталоги з попереднього етапу збирання до поточного, механізм, який фактично пересуває зкомпільовані артефакти між етапами. “Ми використовуємо COPY --from=builder /app/dist ./dist, щоб перенести тільки скомпільований вивід на стадію виконання, залишаючи весь node_modules dev-встановлення позаду.”

** Фаза виконання ** — остання стадія багатоетапного файла Docker, зазвичай заснована на мінімальному штампі, який містить лише те, що потрібно для запуску програми, а не для її збирання. “Стадія виконання заснована на node:slim без будь-яких компіляторів — вона просто запускає JavaScript, який було скопійовано зі стадії збирання.”

** Базовий штамп ** — штамп, на який посилається інструкція FROM, на основі якого буде збудовано етап, вибір якого залежить від того, що дійсно потрібно для цього етапу (повний SDK для збирання, мінімальний дистрибутив для запуску). “Ми вибрали повний базовий образ SDK для стадії збирання і базовий образ без дистрибутиву для стадії виконання — різні завдання, різні вимоги.”

** Кешування шарів ** — Механізм Docker для повторного використання незмінних проміжних шарів у збірках, з якими багатоетапні збірки взаємодіють, дозволяючи шарам встановлення залежностей залишатися в кеші навіть тоді, коли змінюється тільки код програми. “Записання кроку COPY package.json і встановлення перед копіюванням решти коду означає, що кешування шарів пропускає перевстановлення, якщо залежності не змінилися.”

Звичайні фрази

• Чи потрібна ця залежність на етапі виконання, чи тільки для будівництва?»
• «Ми копіюємо скомпільований бінарний код через COPY --from, тому інструменти збирання ніколи не досягають виробництва»
• Чи можемо ми зменшити це, перемикаючи стадію виконання на менший базовий образ?»
• «Цей шар не кешується, тому що порядок копіювання анульує його при кожній зміні джерела.»
• «На якій стадії знаходиться ця інструкція — build або runtime?»

Приклади висловлювань

Пояснення зменшення розміру зображення у PR: “Ця багатоетапна збірка скоротила кінцевий штамп з 1. 2 ГБ до 180 МБ — стадія збирання все ще має повний ланцюжок інструментів компілятора, але стадія виконання тільки копіює зібраний бінарний файл через COPY --from=builder.”

Перегляд файла Docker, який пропустив перевірку:

• “Зараз все відбувається на одній стадії, отже, надісланий штамп містить весь ланцюжок інструментів збирання. Розділення цього на стадію збирання і тонку стадію виконання значно зменшить поверхню атаки. ”*

Діагностика повільної збірки CI: “Етап збирання перевстановлює залежності при кожному запуску, оскільки COPY . . відбувається перед кроком встановлення — зміна порядку, щоб файли залежностей копіювалися спочатку, дозволить кешуванню шарів дійсно почати працювати.”

Професійні поради

• Явно називайте ** стадію збирання ** і ** стадію виконання ** під час перегляду файла Docker — переглядачі часто не можуть сказати на перший погляд, які інструкції належать до яких без міток.
• Вказуйте на непотрібні інструменти або залежності, які потрапили на ** стадію виконання ** — звичайний коментар перегляду: «чи це має бути тут, чи це залежність тільки для збирання?»
• Рекомендуйте COPY --from явно замість встановлення інструментів збирання безпосередньо на останньому етапі — це єдина зміна, яка найбільше зменшує розмір зображення і поверхню CVE.
• Згадувати про порядок кешування шарів, якщо збирання відбувається повільніше, ніж очікувалося — копіювання коду до того, як буде створено маніфест залежностей, є частою, але легкою причиною.

Практичні вправи

1. Напишіть речення, у якому пояснюється, чому у стадії виконання не слід включати ланцюжок інструментів компілятора.
2. Поясніть, що робить COPY --from=builder вашими словами.
3. Описує, як порядок інструкцій впливає на кешування шарів у багатоетапному збиранні.

На практиці: Навігація та співпраця

Погляньмо правді в очі - технічне спілкування не просто про написання коду. Це важлива навичка при роботі в командах, особливо при роботі зі складними процесами, такими як багатоетапні збірки Docker. Для не-рідних носіїв англійської мови, нюанси професійного фразування можуть бути особливо викликом. Розглянемо цей сценарій: Сара, розробник проекту, що використовує Docker, переглядає запит на звантаження, надісланий Марком. Марк використовував багатоетапну збірку для створення штампу для своєї нової служби API. Опис PR… рідкісний. Він просто говорить «Будує API»

Відсутність деталей Марка негайно піднімає прапор. Хороший коментар до перегляду не просто про вказівку на проблеми; це про полегшення розуміння і забезпечення майбутнього підтримування. Замість того, щоб сказати: «Ця збірка неясна», Сара може відповісти в Slack щось на зразок: «Привіт, Марк, чи можете ви розібратися у стадіях, використаних в цій збірці? Зокрема, я хотів би знати, з якого базового штампу ви починаєте і які кроки потрібно виконати для копіювання залежностей до кінцевого артефакту. Знаючи це, ми можемо оцінити потенційне збільшення розміру і переконатися, що наш процес розгортання залишається ефективним.» Ця фраза використовує точний словник — « базовий штамп », « залежності », « артефакт » — терміни, які часто зустрічаються під час обговорення процесів збирання. Вона фокусується на тому, чому ясність важлива («оцінити потенційне збільшення розміру», «забезпечити, щоб наш процес розгортання залишався ефективним»), а не просто заявляє про попит на більше інформації.

Інша поширена ситуація виникає під час самих описів PR. При запропонуванні нової багатоетапної збірки, важливо бути ясним про обґрунтування за кожним етапом. Сказати «Це збирає програму» недостатньо. Замість цього ви можете написати: «Ця багатоетапна збірка використовує базовий образ Node.js ( node:16 ) для компіляції фронтенду і бекенду. Перший етап компілює код до оптимізованого пакету JavaScript, який потім копіюється до меншого базового штампу Alpine Linux на другому етапі. Це зменшує кінцевий розмір штампу за рахунок виключення непотрібних інструментів розробки.» Такий рівень деталізації демонструє професіоналізм і надає змогу рецензентам швидко зрозуміти мету збирання і його потенційний вплив. Це про передачу наміру - що ви розглядали оптимізацію і найкращі практики безпеки.

Нарешті, пам’ятайте, що коротка мова є ключем. Уникайте надто довгих описів. Сфокусуйтесь на ефективному передачі важливої інформації. Використання таких термінів, як «проміжний артефакт» або «шар» при обговоренні збірок Docker часто може спрощувати комунікацію, але тільки якщо ваша аудиторія розуміє ці терміни.

Ось простий приклад, який показує, як вказати інструкцію Dockerfile для копіювання файлів між стадіями:

FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
# Build the application
RUN npm run build

FROM alpine:latest AS final
COPY --from=builder /app/dist ./public