Когда к нам приходит клиент с сервером под столом, одним приложением в проде и без единой резервной копии, первый разговор идёт не про сайт и не про CRM. Мы выясняем, можно ли вообще воспроизвести то, что сейчас работает, если эта железка завтра не включится.
Почему сервер, настроенный руками, нельзя повторить
Голый сервер с приложением, установленным руками по инструкции 3-летней давности, повторить невозможно. Через 6 месяцев никто не помнит, какие пакеты ставили, какие версии и что правили в конфигах в 3 часа ночи, чтобы наконец заработало. Человек, который это делал, может уже не работать в компании.
Контейнер решает ровно эту задачу. Контейнер Docker это приложение, упакованное вместе с окружением по текстовому описанию, которое лежит рядом с кодом: какая база, какие версии, какие переменные. Собрать такое же окружение на другой машине можно за минуты, и оно будет точно таким же, а не похожим.
Для нас как для обслуживающей команды это ещё и вопрос управляемости. Когда инфраструктура устроена по единому стандарту, с одинаковыми логами и одинаковым способом обновления, разбор проблемы занимает минуты. Когда у каждого своя самодельная конструкция, каждый инцидент превращается в отдельное расследование.
Что контейнеризация даёт бизнесу
Самое заметное: откат после неудачного обновления за секунды, мы просто запускаем предыдущий образ. Без контейнеров это восстановление из бэкапа, минимум час, и то если бэкап проверяли. Как проверять, что копия действительно восстановится, мы разбирали в статье Backup и облако.
Тестовая среда перестаёт быть роскошью. Поднять копию боевого окружения для проверки обновления становится дешёвой операцией вместо проекта на неделю.
И масштабирование. Если сервис держит поток заявок и в сезон нагрузка вырастает в 3 раза, добавить экземпляры можно правкой конфигурации.
Когда контейнеры не нужны и что ставить вместо них
Есть места, где контейнеризация только усложняет жизнь, и честнее сказать об этом сразу. Вот как мы выбираем между Docker, гипервизором и вариантом ничего не трогать:
| Ситуация | Что делаем |
|---|---|
| Приложение часто обновляется, нужны тестовая копия и быстрый откат | Переносим в Docker |
| В сезон нагрузка вырастает в 3 раза | Docker, экземпляры добавляем правкой конфигурации |
| Legacy-приложение под Windows Server, которому нужна изоляция на уровне операционной системы | Hyper-V или аналогичный гипервизор |
| Сервер 1С с лицензией, привязанной к железу или конкретной машине | В контейнер не переносим |
| Маленький сервис, который годами работает, не обновляется и держит стабильную нагрузку | Ничего, оставляем как есть |
С 1С история отдельная: попытка засунуть сервер с такой лицензией в контейнер обычно заканчивается разговором с лицензионным отделом, поэтому 1С мы обслуживаем в том окружении, которое допускает лицензия. А перевод в контейнеры стабильного сервиса, который годами не меняется, это работа ради работы, и мы в таких случаях прямо говорим клиенту, что трогать не надо.
Как проходит переход на контейнеры
- Инвентаризация: что вообще крутится, на чём, кто это поддерживает и что произойдёт, если оно остановится.
- Выбор первого кандидата. Обычно это то, что чаще всего ломается или чаще всего обновляется.
- Перенос одного сервиса и 2 недели жизни с ним, с наблюдением за логами.
- Только после этого берёмся за остальное.
Новым клиентам мы закладываем контейнеризацию сразу при проектировании инфраструктуры, старые проекты переводим постепенно и только там, где это окупается. Если вы не знаете, что у вас сейчас крутится и переживёт ли бизнес отказ одного сервера, начните с аудита инфраструктуры: от 1 недели и 55 000 - 100 000 ₽, инженер приедет в офис по Москве и области или подключится удалённо. На выходе карта того, что есть, и план, что переносить первым, а что не трогать вовсе.