1. Беремо тільки офіційний образ Docker як основу для застосунку
Наприклад, ви пишете свій застосунок на Node.js і вам потрібно зібрати та запустити його в Docker.
Беремо офіційний образ node
Що це нам дасть?
- Менше сміття в dockerfile
- image, оптимізований для Node.js
2. Версійність вашого Docker image
Ми взяли image. Тепер нам потрібно вказати версію, оскільки за замовчуванням береться latest версія.
Навіщо це робити?
❌ - Можна отримати версію, яка відрізнятиметься від попередньої збірки або збірки на DEV-майданчиках
❌ - У новішій версії можуть бути проблеми або вона може не зібратися
❌ - latest означає, що вона тестова й не гарантує стабільної роботи
Як ви вже зрозуміли, нам варто вказати конкретну версію.
3. Беремо тільки найменші образи
У Node.js є доволі багато image. Вони відрізняються не тільки версіями, а й великим списком систем:
1) Розмір образу
❌ При використанні повноцінного дистрибутива, наприклад Centos, у комплекті ви отримаєте багато додаткових компонентів, які займатимуть місце і навряд чи вам знадобляться.
✅ Краще використовувати урізану версію дистрибутива й доінсталювати потрібні вам компоненти. Так ви отримаєте менший розмір образу, а для зберігання й розгортання середовища знадобиться менше місця та часу.
2) Безпека
❌ Чим більше компонентів системи, тим вища ймовірність вразливості у вашому образі.🙉
✅ Практика показує: чим менше компонентів входить до дистрибутива, тим менша ймовірність зламу вашого середовища й доступу до вашого проєкту.
4. Кешування під час збирання власних образів
1) Що таке шари?
Образи Docker створюються на основі Dockerfile.
Кожна команда або інструкція, прописана у Dockerfile, створює «шар»:
2) А що з кешуванням?
Docker зберігатиме всі шари в кеші. 👍
Тому, якщо немає змін, Docker використовує кеш для створення image.
Переваги кешування шарів:
✅ - Швидке створення шарів
3) Кешування та його оптимізація
Що потрібно знати:
Після змін у шарі все потрібно створювати заново: змінили щось у Dockerfile — кеш усіх наступних шарів буде створено заново, оскільки вони вважатимуться застарілими. 😣
Складіть список усіх команд у Dockerfile від найрідше використовуваної до тієї, яку використовуєте постійно, так ви зможете правильно використовувати свій кеш і оптимізуєте швидкість створення образу 🚀
5. Користуйтеся файлом .dockerignore
Туди можна додати такі папки, як target и build файл readme вони вам не потрібні, і постійно генерувати їх вам точно не потрібно. 🤔
👉 Используем.dockerignore.
Усе, що знаходиться всередині файлу, ігнорується під час створення. Вам потрібно лише перелічити каталоги й файли.
6. Користуємося Multi-Stage
Є набір інструментів, потрібних лише для розробки й тестування вашого проєкту. У PROD вони не потрібні.
Такі інструменти зазвичай мають більше вразливостей і збільшують розмір вашого проєкту🧐
Приберіть усе зайве: для цього потрібно використовувати multi-stage builds 💡 Вони дадуть змогу використовувати кілька тимчасових образів під час збирання, але залишать лише фінальну версію образу для середовища PROD:
7. Використовуємо користувача з мінімально можливими правами
Користувач за замовчуванням для Dockerfile root 🙉 нам точно не підходить, і з цією проблемою потрібно щось робити.
❌ Ви ж знаєте, що це анітрохи не безпечно.
Якщо хтось отримає доступ до root ви можете втратити доступ до обладнання, а весь ваш проєкт можуть злити й отримати повний доступ до бази 🤯 завжди є ймовірність використання бібліотеки з вразливістю.
✅ Створюємо користувача, який має права на конкретну директорію та певні застосунки, а також окрему групу в образі Docker для запуску вашого проєкту:
8. Перевіряємо свої image на наявність дір у безпеці системи
Як же нам переконатися, що дір у безпеці немає? 🧐
Використовуємо команду для перевірки безпеки docker scan. 🔍
У фоновому режимі Docker використовує сервіс snyk для перевірки образів на вразливості.
Наприклад, output’а
