Комментарии 24
Если в контейнерах только стейтлесс приложения, там нечего бекапить. Зачем бекапить то, что перекатывается с нуля за секунды? Реджистри мы обычно используем файловы, бекапится он просто как директория с кучей файлов.
Если же в контнейнерах данные, нужно бекапить сами данные. Мы для этого используем Bacula (точнее Bareos) с кучей обвязок, но тут нет однозначного ответа. Любой инструмент, который вы уже сейчас используете, скорей всего может быть адаптирован.
Ощущения меня не подводят — прежде всего докер юзают в продакшене крупные компании, которые могут позволить себе штат специалистов по нему и специализированную инфраструктуру.
Не в статьях на хабре дело. Хотя для маленьких компаний полноценных мануалов по внедрению крайне мало, обычно просто введение как локально развернуть поиграться, либо общее описание архитектур на тысячи хостов.
Но в целом ощущения после попыток как-то глобально внедрить в сквозной процесс от разработки до продакшена подсказывают, что без специалистов это дело рискованное с одной стороны, но постоянную нагрузку маленькая компания даже на одного на специалиста создать не сможет, с другой.
В целом да, все так, и тут появляемся такие мы, продавая shared-команду DevOps'ов небольшим компаниям.
Интересно. Посмотрел ваш сайт и увидел вот что: "сервисы, которые не контейнеризируются: MySQL, MongoDB, RabbitMQ, Cassandra и Ceph;" Не знаю про контейнеризацию последних двух, но для первых трёх ведь существуют официальные и неофициальные образы. Или на практике не готовы поддерживать контейнеры с состоянием в продакшене?
Смысл в том, что:
- идеально и без проблем контейнеризуются — stateless приложения,
- можно контейнеризовать, но надо смотреть плюсы минусы в каждом конкретном случае:
- statefull приложения, потеря данных в которых не критична (автозаполняемые кеши, например)
- statefull приложения, которые сами умеют кластер с автовосстановлением данных И там не планируется хранить очень много данных (чтобы скорость восстановления узла не была слишком большой),
- statefull приложения, которые могут комфортно существовать на сетевых дисках (ebs, rds и пр.) — для которых 1000 IOPS достаточно.
- с трудом и с привлечением большой магии можно запихать в контейнеры большие statefull приложения (например посредством решений такого класса: https://habrahabr.ru/company/flant/blog/326414/).
Самое важное! Положить в образ можно любой бинарник, в этом нет никакой проблемы. Запускать в Docker можно ЛЮБОЕ приложение, если речь идет об одном хосте — с этим тоже нет никакой проблемы. Однако, на одном хосте все можно и без Docker запустить, какая разница? Самое интересное и самое вкусное начинается, как только дело доходит до продакшена, которому требуются отказоустойчивость и горизонтальное масштабирование — и вот тут встает вопрос не о том, как что-то запихать в контейнер, а о том как сделать orchestration, self-healing, service discovery.
Таким образом, на сайте у нас имеется ввиду, что в общем случае мы не рекомендуем передавать под управление statefull-сервисы в Kubernetes и считаем, что технологии еще не дозрели.
Если чуть-чуть влезть в детали, например по MySQL, то по нашему мнению его можно передать под управление Kubernetes в следующих случаях:
- хватает ebs/rds (хватает iops'ов) — просто один узел c MySQL и никаких проблем,
- допустимо использовать Percona XtraDB Cluster И данных не слишком много (инфраструктура позволяет поднимать ноду в разумное время).
А в общем — да, логично, что в первую очередь это крупные компании. Интересное в последних данных Datadog то, что к ним уже подтягиваются и «средние».
Не сложно базовые примеры повторить, а при попытках развернуть хотя бы дев-окружение локально по принципу "склонировал репу и запустил docker-compose up" c кучей проблем сталкиваешься. Навскидку:
- проброс секретов в билдер, не используя нерекомендуемые способы (что-то в сварм моде появилось рекомендуемое, но он же не для локального разворачивания, а для кластеров)
- то же уже в запущенный контейнер
- синхронизация запуска, чтобы зависящий от БД контейнер запускался только когда СУБД готова принимать соединения
- кэширование пакетов в билдере
- разделение генерируемых при сборке приложения файлах между контейнерами (например, статику в контейнер с nginx, всё остальное в контейнер с php-fpm)
- проблемы с правами при монтировании локальных каталогов
- проброс DNS-имён на хост, чтобы резолвилось в браузере service1.local и service2.local на разные контейнеры
- проброс DNS-сервера локальной сети в докер-контейнер (возможно специфично только для Ubuntu Desktop < 17.04), с учётом возможности подключения по VPN к сети, где свой DNS-сервер, которій должен динамически использоваться докер-демоном
- работа с логами, не заточенных под докер приложений
При работе с удаленную машину ещё больше проблем добавляется, т. к. папочки уже не примонтируешь. И єто только для дев- и тест-окружения.
Поиск решений каждой из проблем может по несколько десятков часов занимать, если хочется чтобы новій разработчик только "склонировал репу и запустил docker-compose up", а при приеме мерж-реквеста на стейж-сервере разворачивался автоматически проект из пары десятков сервисов, у половины из которых своя СУБД.
Если у каждой виртуалки единственная роль, если время от принятия решения (не важно, автоматически по данным мониторинга или людьми) о поднятии новой виртуалки до её реального включения в работу более чем устраивает, если утилизация ресурсов достаточно высока, то, навскидку, вам докер особо ни к чему.
Один производительный инстанс и куча контейнеров могут выйти дешевле чем куча виртуалок.
Во всяком случае, так было в ситуации моей компании.
www.mtv.com
www.cc.com
www.spike.com
и еще несколько десятков хостов + куа + дев окружение для каждого продакшн хоста. Сэкономили весомое количество денег, выиграли в стабильности и еще ряде вещей.
А что больше сыграло aws или docker? Ведь это никак не связано — можно докер на своем железе запускать, а можно с авс без докера работать.
Сыграла авс конечно и возможность масштабировать контейнерами, а не целые виртуалки, в рамках пары мощных инстансов в авс(Amazon EC2), к-е и выходят дешевле. Да, контейнеры в EC2 Сontainer Service как тут отметили.
Какие известные компании используют Docker в production и для чего?