Pull to refresh

Comments 24

Тут в другом месте интересовались про бэкапы, как вы их делаете? Что используете? Что сохраняете? Выключаете ли контейнеры для бэкапов?

Если в контейнерах только стейтлесс приложения, там нечего бекапить. Зачем бекапить то, что перекатывается с нуля за секунды? Реджистри мы обычно используем файловы, бекапится он просто как директория с кучей файлов.


Если же в контнейнерах данные, нужно бекапить сами данные. Мы для этого используем Bacula (точнее Bareos) с кучей обвязок, но тут нет однозначного ответа. Любой инструмент, который вы уже сейчас используете, скорей всего может быть адаптирован.

Да я имел ввиду контейнеры, где есть данные. Сам я использую самописную программу, она очень гибкая и удобная получилась, но всегда есть надежда, что может быть есть, что-то лучше.

Ощущения меня не подводят — прежде всего докер юзают в продакшене крупные компании, которые могут позволить себе штат специалистов по нему и специализированную инфраструктуру.

Подводят, смысл «маленьким» компаниям пилить одинаковые статьи на хабру о том как они используют докер?)

Не в статьях на хабре дело. Хотя для маленьких компаний полноценных мануалов по внедрению крайне мало, обычно просто введение как локально развернуть поиграться, либо общее описание архитектур на тысячи хостов.


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

В целом да, все так, и тут появляемся такие мы, продавая shared-команду DevOps'ов небольшим компаниям.

Интересно. Посмотрел ваш сайт и увидел вот что: "сервисы, которые не контейнеризируются: MySQL, MongoDB, RabbitMQ, Cassandra и Ceph;" Не знаю про контейнеризацию последних двух, но для первых трёх ведь существуют официальные и неофициальные образы. Или на практике не готовы поддерживать контейнеры с состоянием в продакшене?

UFO just landed and posted this here

Смысл в том, что:


  • идеально и без проблем контейнеризуются — 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", а при приеме мерж-реквеста на стейж-сервере разворачивался автоматически проект из пары десятков сервисов, у половины из которых своя СУБД.

Тестовый робот. Запустили посредством VBox, с использованием контейнеров, в которых запускается Ubuntu, NodeJS, и по-моему, на основе SeleniumWebdriver. Получившаяся связка позволяет отделу QA писать и скармливать роботу BD-тесты на русском языке.
Имеем крупный проект. Используем Nutanix. Там вируталки. Зачем ещё внутри Docker?
Зависит от того, как их используете (как/что в них деплоите), и ваших потребностей (в частности — частота и скорость деплоя). В статье есть конкретный пример с переходом на Docker в случае PayPal, где как раз были только виртуалки.

Если у каждой виртуалки единственная роль, если время от принятия решения (не важно, автоматически по данным мониторинга или людьми) о поднятии новой виртуалки до её реального включения в работу более чем устраивает, если утилизация ресурсов достаточно высока, то, навскидку, вам докер особо ни к чему.

всё упирается в ресурсы, с докером надо меньше ресурсов
Например выиграть в цене.
Один производительный инстанс и куча контейнеров могут выйти дешевле чем куча виртуалок.
Во всяком случае, так было в ситуации моей компании.
Компания крупная, все сайты крупные с кучей посещаемости. Переехали с виртуалок в openstack на aws + docker.

www.mtv.com
www.cc.com
www.spike.com
и еще несколько десятков хостов + куа + дев окружение для каждого продакшн хоста. Сэкономили весомое количество денег, выиграли в стабильности и еще ряде вещей.

А что больше сыграло aws или docker? Ведь это никак не связано — можно докер на своем железе запускать, а можно с авс без докера работать.

Да, докер можно юзать и без амазона на своем железе. Но речь шла о виртуалках и докеру как в замену им.
Сыграла авс конечно и возможность масштабировать контейнерами, а не целые виртуалки, в рамках пары мощных инстансов в авс(Amazon EC2), к-е и выходят дешевле. Да, контейнеры в EC2 Сontainer Service как тут отметили.
Sign up to leave a comment.