[Перевод] Docker в продакшене — чему мы научились, запустив более 300 миллионов контейнеров15.01.2015 16:03

Docker в продакшене на Iron.ioРанее в этом году (прим. 2014 г.), мы приняли решение запускать каждую задачу на IronWorker внутри своего собственного Docker контейнера. С тех пор мы запустили более 300 000 000 программ внутри собственных Docker контейнеров в облаке.

После нескольких месяцев использования, мы хотели бы поделиться с сообществом некоторыми из проблем, с которыми мы столкнулись в построении инфраструктуры, основанной на Docker’e, как мы преодолели их, и почему это стоило того.IronWorker — это сервис выполнения задач, который позволяет разработчикам планировать, обрабатывать и масштабировать задачи, не заботясь о создании и поддержке инфраструктуры. Когда мы запустили сервис более трех лет назад, мы использовали единственный LXC контейнер, содержащий все языки и пакеты для запуска задач. Docker дал нам возможность легко обновлять и управлять набором контейнеров, что позволяет предлагать нашим клиентам гораздо больший спектр языковых сред и установленных пакетов.

Мы начали работать с Docker версии 0.7.4 где было замечено несколько багов (один из самых больших — контейнер не закрывался должным образом, позднее он был поправлен). Мы преодолели почти все из них, постепенно обнаруживая, что Docker не только удовлетворяет наши потребности, но и даже превосходит наши ожидания, настолько, что мы даже расширили масштабы использования Docker во всей нашей инфраструктуре. Учитывая наш опыт на сегодняшний день, это имело смысл.

Вот список лишь некоторых преимуществ, которые мы увидели: Немного цифр

Лёгкость в обновлении и поддержке образов Git-овый подход в Docker является очень мощным и позволяет легко управлять большим количеством постоянно развертывающихся сред, и его система работы с образами позволяет нам тонко настраивать детализацию отдельных образов, экономя дисковое пространство. Теперь мы в состоянии идти в ногу с быстро обновляемыми языками, а также мы можем предложить специальные образы, как например новый стек FFmpeg, разработанный специально для обработки медиа. Сейчас у нас около 15 различных стеков и этот список быстро растет.Распределение ресурсов и анализ LXC-контейнеры являются методом виртуализации на уровне операционной системы и позволяют контейнерам разделять между собой ядро, но таким образом, что каждый контейнер может быть ограничен в использовании определенного количества ресурсов, таких как процессор, память и устройства ввода / вывода. Docker предоставляет эти возможности, а также и многие другие, в том числе REST API, систему контроля версий, обновление образов и легкий доступ к различным метрикам. Кроме того, Docker поддерживает более безопасный способ изоляции данных, используя файловую систему CoW. Это означает, что все изменения, внесенные в файлы в рамках задачи, хранятся отдельно и могут быть очищены с помощью одной команды. LXC не в состоянии отслеживать такие изменения.Простая интеграция с Dockerfiles Наши команды разбросаны по всему миру. Тот факт, что мы в состоянии опубликовать простой Dockerfile и чувствовать себя спокойно, зная, что проснувшись, кто-то другой будет в состоянии собрать точно такой же образ, как и вы — огромный выигрыш для каждого из нас и наших режимов сна. Наличие чистых образов также делает намного более быстрыми развёртку и тестирование. Циклы нашей разработки стали гораздо быстрее, а все члены команды намного счастливее.Пользовательские среды, построенные с помощью Docker’a

Растущее сообщество Обновления на Docker выходят очень часто (даже чаще, чем на Chrome). Степень участия сообщества в добавлении новых функций и устранении ошибок стремительно растет. Будь то поддержка образов, обновления самого Docker’а, или даже добавление дополнительных инструментов для работы с Docker, говорит о большом количестве умных людей, занимающихся этими проблемами, так что нам этого делать не приходится. Мы видим, что Docker-сообщество чрезвычайно позитивно и участие в нём приносит много пользы, и мы рады быть его частью.Docker + CoreOS Мы все еще в процессе исследования, но сочетание Docker и CoreOS обещает занять серьёзные позиции в нашем стеке. Docker обеспечивает стабильное управление образами и контейнеризацией. CoreOS обеспечивает урезанную облачную ОС, распределенное управление и управление конфигурациями. Это сочетание позволяет более логично разделить проблемы и лучше наладить стек инфраструктуры, чем мы имеем сейчас. Каждая серверная технология требует тонкой настройки, особенно при масштабировании, и Docker не является исключением. (Представьте себе, мы запускаем около 50 миллионов задач и 500000 часов процессорного времени в месяц, при этом быстро обновляем образы, которые мы сделали доступными.)Вот несколько проблем, с которыми мы столкнулись при использовании Docker на больших объемах:

Ошибки Docker — небольшие и поправимые

Ограниченная обратная совместимость Быстрый темп развития, безусловно, преимущество, но у него есть свои недостатки. Один из них — ограниченная обратная совместимость. В большинстве случаев то, с чем мы сталкиваемся — изменения в синтаксисе командной строки и API методов и поэтому это не такой важный вопрос с точки зрения продакшена.В других случаях, однако, это повлияло на эксплуатационные характеристики. Например, в случае каких-либо ошибок Docker после запуска контейнеров, мы анализируем STDERR и реагируем в зависимости от типа ошибки (например — повторной попыткой запуска задачи). К сожалению формат вывода ошибок менялся от версии к версии и поэтому мы решили делать отладку на лету.

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

Ограниченные средства и библиотеки В то время как у Docker был стабильный релиз 4 месяца назад, многие инструменты, сделанные для него, по-прежнему остаются нестабильными. Применение большого количества инструментов в системе Docker означает также принятие больших накладных расходов. Кому-то из вашей команды придется оставаться в курсе всего и много возиться для того, чтобы учесть новые функции и исправить ошибки. Тем не менее, нам нравятся многие инструменты, которые сделаны для Docker, и нам не терпится дождаться кто победит в этих сражениях (глядя на управление инфраструктурой). Особый интерес для нас представляют etcd, fleet и kubernetes. Чтобы раскрыть наш опыт немного глубже, ниже представлены некоторые проблемы, с которыми мы столкнулись и их решения.Выдержка из сеанса отладкиЭтот список предоставил Роман Кононов, наш ведущий разработчик IronWorker и директор по управлению инфраструктурой, и Sam Ward, который также играет важную роль в отладке и оптимизации нашей работы с Docker.

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

Длительный процесс удаления Решение проблемы Медленного Удаления КонтейнераУдаление контейнеров занимает слишком много времени, также требуется много операций чтения/записи. Это вызвало значительные задержки и выявило уязвимости в наших системах. Мы должны были увеличить количество ядер, доступных нам, до большего количества, в чем не было необходимости.После изучения и исследования devicemapper (драйвера файловой системы Docker), мы обнаружили специальную опцию `--storage-opt dm.blkdiscard=false`. Эта опция говорит Docker, что нужно пропустить тяжелую дисковую операцию при удалении контейнеров, что значительно ускоряет процесс отключения контейнера. С тех пор проблема была решена.

Не отмонтировывающиеся тома Контейнеры не завершали работу корректно, потому что Docker не размонтировал тома должным образом. Из-за этого контейнеры работали без остановки, даже после того, как задача была завершена. Другой путь — размонтировать тома и удалить папки явно с помощью набора стандартных скриптов. К счастью, это было давно, когда мы использовали Docker v0.7.6. Мы удалили этот длинный скрипт так как эта проблема размонтирования была решена в Docker версии 0.9.0.Распределение использования стеков

Переключение лимита памяти В один из релизов Docker вдруг добавили возможность ограничения памяти и убрали опции LXC. В результате этого, некоторые из рабочих процессов превысили ограничения памяти, и вся система перестала отвечать на запросы. Это застало нас врасплох, потому что Docker никогда не ломался, даже используя неподдерживаемые опции. Исправить было несложно — применить ограничения памяти в Docker —, но всё равно изменения застали нас врасплох. Как вы уже заметили, мы довольно активно вкладываем в Docker и продолжаем это делать каждый день. В дополнение к использованию его как контейнера для запуска пользовательского кода в IronWorker, мы находимся в процессе внедрения его в ряд других сфер нашей деятельности.Эти области включают в себя:

IronWorker Backend В дополнение к использованию Docker как контейнера для задач, мы находимся в процессе внедрения его как инструмента управления обработкой на каждом сервере, который контролирует и запускает рабочие задачи. (Главная задача на каждом исполнителе берет задание из очереди, загружает в соответствующую среду Docker, выполняет задание, контролирует его, а затем, после окончания выполнения задания, очищает среду.) Интересно, что мы будем иметь в контейнере код, управляющий другими контейнерами на тех же машинах. Переложение всей нашей инфрастуктуры IronWorker на Docker контейнеры позволяет довольно легко запускать их на CoreOS.API IronWorker, IronMQ и IronCache Мы ничем не отличается от других команд разработчиков, которые не любят заниматься настройкой и развертыванием. И поэтому мы очень рады возможности упаковки всех наших сервисов в Docker контейнеры для создания простых и предсказуемых рабочих сред. Больше не нужно настраивать сервера. Все что нам нужно это серверы, на которых можно запускать Docker контейнеры и… наши сервисы работают! Следует также отметить, что мы заменяем наши серверы сборки — серверы, которые строят релизы наших программных продуктов в определенных средах — Docker контейнерами. Преимущества здесь в большей гибкости и более простом, надежном стеке. Оставайтесь на связи.Cборка и загрузка Worker’ов Мы также экспериментируем с использованием Docker контейнеров для создания и загрузки задач в IronWorker. Большим преимуществом здесь является то, что это обеспечивает пользователям удобный способ настраивать нагрузку и рабочие процессы конкретных задач, загружать их, а затем запускать и масштабировать. Другим плюсом здесь является то, что пользователи могут тестировать воркеры локально в тех же средах что и наш сервис.Внедрение On-Premise сборки Использование Docker в качестве основного метода распределения нашего IronMQ Enterprise последней версии упрощает нашу работу и обеспечивает простоту и универсальный способ развертывания в практически любой облачной среде. Помимо сервисов, которые мы запускаем в облаке, всем клиентам нужны серверы, которые могут запускать Docker контейнеры и они с относительной легкостью могут получить мульти-серверные облачные сервисы в тестовой или продакшен среде. Эволюция технологий (Взято с docker.com)За последние полтора года, с тех пор как Solomon Hykes представил демо версию на GoSF meetup, Docker прошел долгий путь. С момента выпуска версии 1.0 Docker показал себя как достаточно стабильный и действительно готовый к продакшену.

Развитие Docker’a очень впечатляет. Как видно из приведенного выше списка, мы с нетерпением ждем новых возможностей, но мы также рады и нынешним его возможностям.

Если бы мы только могли заполучить инструмент для управления инфраструктурой на базе Docker.