Comments 59
Вот первая ссылка из гугла про это: http://www.dc-perekrestock.ru/use704.php
Я сам не маргинал, но у меня в команде парень с дредами, кто-то с татухами, другой любит ходить босым, а девчонка-тестер фанат тяжелой музыки и кожи. Выступают на конференциях, успешно контрибутят в open-source и вообще, ложили с прибором на тех, кого ебет их внешний вид. Все интересные личности, а с буквоедами энциклопедий я чувствую усну еще до того, как принесут меню на обеденном перерыве. Но это Берлин да, нам далеко до ваших арийских скреп и идеалов.
Чего только стоит: «Женщине шапку с большими полями нельзя носить после 5 вечера». А мужчине можно. А женщина значит должна всегда носить запасную шапку в кармане, а то вдруг 5 вечера а она еще не вернулась домой.
Или например то что мужчине предлагается снимать на улице шапку если он слышит гимн (кстати, гимн какой страны? Обязательно ли знать гимны всех стран?) или говорит с женщиной.
Даром что сжигать никого в этой статье не предлагают.
Не всякий головной убор является шляпой. Засим предлагаю спор считать завершённым.
Двадцать первый век на дворе, конференция для гиков, а мы обсуждаем шапки.
Планируете ли открыть baDocker сообществу?
И еще не увидел ни слова (в статье, видео не смотрел) про Docker volume.
Т.е по крайней мере первые грабли изза того что готовили докер не в концепции докера, а как то по своему.
Часть хостовой системы в контейнер – это вы про /dev/log или что-то еще? если будет более конкретный вопрос, то я попробую на него ответить.
Блочное устройство для docker root – это затем, что мы не хотели и не хотим получить BTRFS by default, именно поэтому был сделан отдельный том для docker root на BTRFS.
Код как таковой внутри контейнеров у нас не распространяется, т.к. большая часть сервисов, про которые я говорил — это binary.
Как вообще разработчики живут со всем этим?
Нужно ставить весь стак компонентов и приложений локально?
Вы используете докер для девелопер среды тоже?
Насколько проблематично поддерживать контейнеры в актуальной версии?
спасибо
Нужно ставить весь стак компонентов и приложений локально?
Не обязательно. Разрабатывать можно как тебе удобно. Докер даёт возможность запустить приложение в конфигурации "как в продакшене". Для запуска нескольких связанных контейнеров используют Docker Compose
Насколько проблематично поддерживать контейнеры в актуальной версии?
Не проблематично, если деплой выглядит так:
- Собираем контенер.
- Тегируем его номером билда.
- На сервере загружаем контейнер нужной версии.
- Запускаем скачанную версию.
Немного офтоп.
Как вообще разработчики живут со всем этим?
Вот и я задаю этот вопрос – как с этим жить?
Нужно ставить весь стак компонентов и приложений локально?
Нет, для этого у нас есть несколько devel площадок, которые представляют собой уменьшенную копию нашего production окружения. Именно там они занимаются разработкой, тестированием и прочими прелестями, которые им нравятся.
Вы используете докер для девелопер среды тоже?
на данный момент нет, но для среды тестирования используем.
Насколько проблематично поддерживать контейнеры в актуальной версии?
что именно вы имели ввиду? актуальность пакетов ОС и их обновления? Не могли бы вы уточнить вопрос, а я попробую дать более полный ответ.
Спасибо
Т.е. у нас скорее это выглядит так:
— ручное принятие решение о поднятии сервиса/инстанса
— подготовка инстанса
— поднятие
— проверка, что все хорошо
— добавление информации о том, что сервис есть и им можно пользоваться
На самом деле рассмотрение etcd/zookeeper у нас также идет, но я не могу сказать, что на данный момент есть готовое внедрение и полноценное использование, так что на данный момент вот так.
Смотрели Kubernetes?
Ну вот логи ваши, например. В kubernetes основная единица не контейнер, а pod — это набор сгруппированных контейнеров, которые имеют доступ к одним и тем же ресурсам. Скажем, вы можете создать отдельный контейнер с syslog, который будет доступен в рамках pod по заданному порту на localhost.
Потом этот контейнер с syslog можете просто подключать к своим сервисным pod'ам. Деплоймент, обнаружение сервисов, балансировка нагрузки на сервисы, поддержка заданного количества инстансов — все делает сам. Сетевая модель — на выбор тот же WeaveNet, Flannel, Calico.
Докер отдельно для серьезных проектов всё равно нуждается в системе оркестрации. Без Swarm, Mesos или Kubernetes от него мало прока в продакшне. Можно, конечно, многое допиливать и додумывать (что и пришлось вам делать), а можно взять полноценную систему оркестрации и сильно упростить себе жизнь.
Собственно Docker сейчас делает собственную оркестрацию — Swarm mode (в 1.12 появился впервые), который только пытается делать часть из того, что уже умеет Kubernetes для продакшна.
Ну и не стоит забывать, что Kubernetes — это опыт Гугла в управлении своими сервисами (те же инженеры пишут, что рулят их production-серверами)
Что-то доступно по localhost в рамках pod – это также не чудо и имеет довольно простое объяснение. Данный бонус скорее относится к тем, кто приложение разрабатывает, чем к улучшению чего-то в production.
Балансировка – это прекрасно… RR, ну хорошо – есть еще healthcheck(не ох какой, но есть). То, куда приземляется трафик этого балансировщика… Вас все это устраивает?
Swarm mode не совместим с "--live-restore", как минимум. Swarm – это окончательно подсесть на Docker.
Stateful контейнеры – «не Docker way», но ничего не поделаешь – они есть и с этим как-то нужно жить. Мы приходим к тому, что желательно растянуть сторадж между хостами, на которых в случае чего pod/service может продолжить работу. Цепочку хотелок и зависимостей можно продолжать дальше долго.
К опыту Гугла я отношусь с большим уважением, также как и ко всем тем, кто занимается разработкой продуктов, которые в свою очередь оказывают неоценимую помощь остальным.
И как только я найду ответы хотябы на те сомнения и вопросы, что я написал – я непременно буду готов рассмотреть Kubernetes.
Если собираетесь работать с docker'ом в продакшне, то рано или поздно — все эти 100500 проблем вы поимеете всё равно.
Собираемся и спасибо за Ваши добрые пожелания :)
Просто любопытно. Вы по сути делаете свой orchestration на докере. Интересно было узнать чем не устраивают существующие решения.
Давайте я попробую привести несколько пунктов:
— у нас мало сервисов, которые мажутся горизонтально просто включением новых инстансов
— на начальном этапе внедрения нам нужно было «оркестрировать» максимально одинаково то, что в Docker и то, что нет
— сетевой аспект меня тоже довольно сильно тревожит
Т.е. основных поинтов два — сеть и изначально отличная от нашей архитектура.
Спасибо. В любом случае интересно было почитать топик и комментарии. Понимаю, что с вашим масштабом лучше быть консервативнее %)
Docker в работе. Взгляд на его использование в Badoo (год спустя)