Мы сократили время развертывания в многоконтекстной среде в 10 раз благодаря использованию Docker, а также сэкономили две должности операционного обслуживания для команды из 10 человек.

В прошлом месяце наша небольшая команда SaaS электронной коммерции в Сингапуре чуть не рухнула - перед большим продвижением мы обновили функцию синхронизации инвентаря для трех сайтов в Юго-Восточной Азии, локальные тесты были хороши, как только мы отправили облачный сервер в Индонезию, коллективно сообщали о недостаточной зависимости, 2 сервера и 1 операционное обслуживание потребовали 18 часов, чтобы спасти, задерживая план стрессового теста на 3 дня раньше.

Сначала нужно понять: что такое развертывание в Docker.

Проще говоря, это о том, что вы упаковываете весь код вашего приложения, зависимые библиотеки, конфигурационные файлы, а также параметры ядра операционной системы в стандартный «образ контейнера». Как ваша программа работает на вашем компьютере, так она будет работать на любом сервере, на котором установлен движок Docker.Минимальная загрузка одного зеркала может быть 20MB, время загрузки не превышает 1 секунду。

Мы использовали реальные доходы за 3 месяца.

Во-первых, была полностью решена проблема несоответствия условий разработки (инсайдерских конфликтов). Раньше на настройку каждого сайта с разными версиями Node.js и драйверами баз данных уходило по полдня. Теперь готовые образы сразу загружаются в репозиторий образов, и можно одним кликом запустить все три сайта. Время развертывания сократилось с среднего значения в 4 часа до 24 минут. Также больше не нужно всю ночь ждать обновлений версий перед акциями с большими скидками.

Во-вторых, использование серверных ресурсов прямо удвоилось.Ранее мы арендовали отдельный облачный сервер с 2 ядрами 4G на каждом сайте, коэффициент использования процессора в бездействии составлял менее 10%, теперь мы использовали Docker для загрузки приложений, кэширования и задач временного хранения на трех сайтах на один сервер с 4 ядрами 8G, ресурсов просто достаточно,Ежемесячные затраты на обслуживание сервера сократились на 620 долларов.Для небольшой команды из менее чем 10 человек это не маленькая сумма.

В конце концов, скорость масштабирования системы полностью соответствует уровню внезапного потока пользователей. В прошлом году во время праздника Черной пятницы нам потребовалось почти 2 часа, чтобы временно добавить серверы и настроить систему, а в этом году за 10 минут до пикового периода мы запустили 12 копий контейнеров, которые смогли выдержать трафик, в 3 раза превышающий обычный. Более того, ни один запрос не был отклонен из-за превышения времени выполнения.

Не спешите садиться в машину — мы уже прошли через все эти препятствия вместе с вами.

Первая яма была слишком раздутой, чтобы написать зеркало.Сначала мы использовали официальный полный функциональный зеркальный образ Node.js непосредственно для упаковки, один зеркальный образ приложения имеет 1.2G, передаваемый в склады зеркальных образов за рубежом занимает более 20 минут, позже мы перешли на базовый зеркальный образ Alpine, убрали все бесполезные зависимости, и в конечном итоге зеркальный образ только 90MB, скорость передачи более чем в 10 раз быстрее.

Вторая проблема заключалась в том, что данные хранились внутри контейнера. Сначала мы этого не заметили и просто сохраняли пользовательские загруженные изображения товаров в локальном каталоге контейнера. Позже контейнер был перезагружен, и все изображения исчезли; на восстановление ушел целый день. После этого мы решили перенести все персистентные данные в локальный каталог сервера или в облачное хранилище объектов, и с тех пор больше никаких проблем не возникло.

Третья ошибка заключалась в отсутствии ограничений на использование ресурсов. При первом запуске системы не были установлены верхние пределы для использования процессорных ресурсов (CPU) и памяти контейнерами. Однажды из-за ошибки в таймерных задачах одного из сайтов были полностью использованы все процессорные ресурсы сервера, в результате чего работа двух других сайтов была прервана. Позже для каждого контейнера были установлены ограничения на использование ресурсов, что предотвратило возможность одной неисправности сервиса отказа всей системы.

Должны ли мы использовать Docker? Наши критерии оценки очень просты.

Ситуации, когда это может быть полезно: вам необходимо развернуть одно и то же приложение на нескольких серверах, часто переключаться между разработочной, тестовой и производственной средами, если ваша команда насчитывает более трех человек, и у каждого из них своя собственная среда разработки. В таких случаях использование Dockerа позволит повысить эффективность работы.

Ситуации, когда использование Docker нецелесообразно: у вас есть всего один небольшой блог, который работает на одном сервере, и вы обновляете код раз в полгода. В таких случаях нет никакой необходимости тратить время на изучение Docker. Проще воспользоваться сервисом Паота (Baota) или провести ручную развертку.

Три конкретных совета для тех, кто впервые берется за это дело:

• Первые 3 раза при создании образов следует использовать официальные шаблоны лучших практик — не пытайтесь самостоятельно писать Dockerfile. Так вы сможете избежать 80% проблем, связанных с избыточным размером образов и ошибками в правах доступа.
• В начале можно вообще не использовать сложные инструменты для управления кластерами вроде K8s, а просто использовать Docker Compose для управления не более чем тремя сервисами – это вполне достаточно.
• Для хранения образов используйте зарубежные узлы облачных провайдеров — не создавайте их самостоятельно. Сэкономленное время позволит вам разработать ещё несколько новых функций.

Общие ответы на распространенные вопросы

Вопрос: Не приведет ли использование Docker к дополнительному расходу ресурсов сервера? Мы провели тестирование, и выяснилось, что потери производительности составляют менее 5%, что практически незаметно для большинства небольших и средних команд.

Вопрос: Можно ли мигрировать старые приложения на Docker? Конечно, можно. У нас есть старый проект на PHP, который работает уже 3 года, и мы создали его образ за 2 дня – это гораздо быстрее, чем настройка новой среды.