Продукт може працювати на комп’ютері розробника й ламатися після перенесення на сервер. Docker пакує застосунок і потрібні залежності в образ, із якого запускається контейнер. Так середовища стають більш повторюваними, а реліз - зрозумілішим. Але контейнери самі не створюють резервних копій, не забезпечують безпеку й моніторинг і не рятують систему в разі відмови сервера.
Що включати в образ
В образі мають бути застосунок і залежності, потрібні для запуску. Паролі та налаштування конкретного середовища зберігайте окремо. Закріплюйте версії залежностей і перезбирайте образи після оновлень безпеки. Невеликий передбачуваний образ простіше перевіряти й розгортати, ніж той, що непомітно встановлює інструменти при кожному запуску.
Для даних потрібен інший підхід
Контейнер можуть замінити будь-якої миті. Завантаження клієнтів і файли бази потребують постійного сховища й резервних копій, а не тимчасового шару контейнера. Перш ніж довірити конфігурації реальні дані, перевірте перезапуск і відновлення після збою.
Використовуйте там, де важлива повторюваність
Docker допомагає узгодити середовища розробки, автоматичних тестів і сервера. Він особливо корисний, коли продукт має кілька сервісів або потребує відтворюваного релізу. Для простого застосунку на керованій платформі складна оркестрація може додати більше проблем, ніж користі. Обирайте мінімальну схему, яка забезпечує потрібну надійність.
Дисципліну релізів ніхто не скасовував
Перевіряйте нову версію до перемикання трафіку, зберігайте попередню збірку та заздалегідь знайте, як відкотитися. Збирайте журнали помилок поза контейнером і стежте за роботою сервісу з погляду користувача. Образ - лише одиниця доставки; для надійного релізу потрібен перевірений процес навколо нього.
