Если отвечать тут, не переходя по ссылкам: смотрели на все, на которые стоило смотреть, в том числе K8S, Mesos, Nomad. Конкретных планов по внедрению не было и нет. Они могут появиться, если внезапно в какой-то день мы на нашем тестовом стенде поймем, что «вот она серебряная пуля».
Добрый день,
только что заметил сообщение. Да используем по сей день. Изменения произошли хотябы потому, что перешли на использование puppetserver, который на Java, в отличии от Rails.
Если кратко, то:
— добавился PuppetDB
— репорты и profiler уехали в Elasticsearch
— остался LB в виде nginx
Т.е. как мне кажется, если смотреть на схему в общем виде, то она стала проще с точки зрения эксплуатации.
Доброго времени суток, у меня к Вам несколько вопросов:
1. Какую сборку ESXi используете? Если это 6+ ветка, то интересно услышать точную версию сборки.
2. Делаете ли вы верифай(проверку на то, что бекапится не мусор, а то, что забекапили – восстановимо) для того, что бекапите?
3. Не было ли проблем с рестором цепочки Full -> Incr1 -> Incr2… -> IncrN => RESTORE?
Я не скажу на 100%, но скорее всего раз мои коллеги говорили о том, что это было, то скорее всего это так и осталось для каких-то специфичных сервисов/задач. Глобально такого нет.
Тут дело не совсем в одном только консерватизме. Скорее я бы назвал это «разумная осторожность», которая должна гарантировать нам возможность сделать пару шагов назад, если что-то пойдет не так при том, чтобы ничего не поломать.
Если вам не сложно – вы можете посмотреть видео с моими докладами, в том числе по Docker. Очень часто в самом их начале я рассказываю о причинах того, почему нам довольно не просто взять и начать использовать что-то готовое. Это все не от того, что нам очень просто брать и делать что-то самостоятельно, а часто от того, что в готовом нет минимума, без которого мы не можем «взлететь».
Давайте я попробую привести несколько пунктов:
— у нас мало сервисов, которые мажутся горизонтально просто включением новых инстансов
— на начальном этапе внедрения нам нужно было «оркестрировать» максимально одинаково то, что в Docker и то, что нет
— сетевой аспект меня тоже довольно сильно тревожит
Т.е. основных поинтов два — сеть и изначально отличная от нашей архитектура.
Чудес не бывает: WeaveNet, Flannel, Calico – это мало того, что новые компоненты, так это еще и оверхед, от которого пострадает latency & throughput.
Что-то доступно по localhost в рамках pod – это также не чудо и имеет довольно простое объяснение. Данный бонус скорее относится к тем, кто приложение разрабатывает, чем к улучшению чего-то в production.
Балансировка – это прекрасно… RR, ну хорошо – есть еще healthcheck(не ох какой, но есть). То, куда приземляется трафик этого балансировщика… Вас все это устраивает?
Swarm mode не совместим с "--live-restore", как минимум. Swarm – это окончательно подсесть на Docker.
Stateful контейнеры – «не Docker way», но ничего не поделаешь – они есть и с этим как-то нужно жить. Мы приходим к тому, что желательно растянуть сторадж между хостами, на которых в случае чего pod/service может продолжить работу. Цепочку хотелок и зависимостей можно продолжать дальше долго.
К опыту Гугла я отношусь с большим уважением, также как и ко всем тем, кто занимается разработкой продуктов, которые в свою очередь оказывают неоценимую помощь остальным.
И как только я найду ответы хотябы на те сомнения и вопросы, что я написал – я непременно буду готов рассмотреть Kubernetes.
Если собираетесь работать с docker'ом в продакшне, то рано или поздно — все эти 100500 проблем вы поимеете всё равно.
Да, смотрели. Более того – продолжаю смотреть на него с разных сторон. До сих пор не могу понять как и с какой стороны это нам может подойти… к сожалению.
Да, все верно поняли. На данный момент это самописное к docker ecosystem не имеет никакого отношения. Одна из основных причин – сервисы у нас не подходят под определение микросервисов и мы не можем так просто взять и поднять N-инстансов одного сервиса(верно не для всех сервисов, но для большей их части), что хорошо подходит для того service discovery, про который вы спрашиваете.
Т.е. у нас скорее это выглядит так:
— ручное принятие решение о поднятии сервиса/инстанса
— подготовка инстанса
— поднятие
— проверка, что все хорошо
— добавление информации о том, что сервис есть и им можно пользоваться
На самом деле рассмотрение etcd/zookeeper у нас также идет, но я не могу сказать, что на данный момент есть готовое внедрение и полноценное использование, так что на данный момент вот так.
ssh внутри контейнеров у нас нет. Для web-терминала есть клиент-серверное приложение(я не помню название, но если очень нужно – могу вспомнить), которое у нас крутится на baDocker-сервере. По сути используется ssh соединение между baDocker сервером и docker хостом, где на последнем используется docker exec. Основная идея именно такая, если не лезть в дебри.
Немного офтоп.
Как вообще разработчики живут со всем этим?
Вот и я задаю этот вопрос – как с этим жить?
Нужно ставить весь стак компонентов и приложений локально?
Нет, для этого у нас есть несколько devel площадок, которые представляют собой уменьшенную копию нашего production окружения. Именно там они занимаются разработкой, тестированием и прочими прелестями, которые им нравятся.
Вы используете докер для девелопер среды тоже?
на данный момент нет, но для среды тестирования используем.
Насколько проблематично поддерживать контейнеры в актуальной версии?
что именно вы имели ввиду? актуальность пакетов ОС и их обновления? Не могли бы вы уточнить вопрос, а я попробую дать более полный ответ.
«Концепция Docker» – это безусловно прекрасно. Вы не пробовали смотреть на инструмент, как на инструмент для достижения поставленных целей и решения конкретных задач? Иногда получается так, что для достижения решения нужно поскупиться концепцией и подойти к решению иначе…
Часть хостовой системы в контейнер – это вы про /dev/log или что-то еще? если будет более конкретный вопрос, то я попробую на него ответить.
Блочное устройство для docker root – это затем, что мы не хотели и не хотим получить BTRFS by default, именно поэтому был сделан отдельный том для docker root на BTRFS.
Код как таковой внутри контейнеров у нас не распространяется, т.к. большая часть сервисов, про которые я говорил — это binary.
Хорошо, что Вам моя шапка не мешает воспринимать информацию. Да мы планируем это сделать, как только осознаем что это можно выкладывать, также как и часть других наработок, про которые в том числе я рассказывал ранее.
Конечно не серчаю, мы же просто обсуждали предложенную вами идею. Обсуждать, предлагать, да и вообще думать – очень полезно.
Изначально, когда вы абстрактно предложили свою идею, без подробностей – она казалась вполне себе состоятельной, я воспринял некоторые моменты по-своему. Далее, когда вы начали более подробно раскрывать её – стало понятно, что не всё можно сделать так просто и прозрачно, а значит это скорее всего приведет к некоторым дополнительным костылям/сервисам и т.д. (не обязательно, но на основании написанного – приведет).
Где-то в середине дискуссии мы говорили о том, что можно упростить предложенную мной строку запуска(про linux capabilities продолжать не будем) – я согласен, можно. Но приведенная строка запуска не дает до конца расслабиться инженеру в те моменты, когда он запускает сервис или диагностирует его, т.е. глядя на строку запуска он уже имеет некоторое понимание о том, с чем ему придется иметь дело. Можем упростить команду и скрыть детали? Да! Проблема лишь в том, что это мы уберем в дебри инита нашего контейнера, тем самым осложним диагностику, если это потребуется. А самое главное – человеку придется меньше думать и работать со «сферическим конем в вакууме» =)
p.s.: самое главное и хорошее – это то, что у вам есть мысли и идеи, а также и то, что вы не боитесь и не стесняетесь ими делиться. Так держать!
docker run -d \
// здесь мы выбираем тип сети для контейнера, выдаем ему ip-адрес:
// Этого можно было бы не делать будь у вас DHCP
--net=c_services --ip=1.1.2.17 \
Неважно есть у нас dhcp или нет, но указать тип сети для контейнера мы должны, а иначе мы используем default bridge, так? Изначально я говорю о том, что нам нужен и мы используем MACVLAN.
Идем дальше. Можно не указывать --ip=. Можно, но тогда нам либо pool адресов при создании macvlan сети для docker нужно как-то обозначить, либо как-то блеклистить те адреса, которые мы не хотим получить в своем контейнере, так?
// это опять же приятнее рандомайза, т.е. дело эстетики. Можно не указывать.
// Это необходимо для системы мониторинга, но можно через dhcp проставлять
-h $VARIABLE.local \
Для какой системы мониторинга?
// да, тут чуть сложнее и мне это нужно:
// это так же решается dhcp сервером
--cap-add=NET_ADMIN \
мы меняем default gw, который мы проставляли при создании MACVLAN сети на .254, что сделать без NET_ADMIN не получится(да, можно через pipework, но мне не нравится такой вариант)
// добавить запись в /etc/hosts. Можно сделать иначе, но так оно прозрачнее.
// если у нас есть dhcp значит и dns можно поставить и управлять этим можно будет централизованно
--add-host='nginx.localhost:1.1.1.17' \
эта запись будет разной, в зависимости от хоста, на котором запускам контейнер. Да, тоже самое значение я передаю позже в -e HOST_IP=1.1.1.17, его можно использовать. Но т.к. сущности разные, то и указываю отдельно там и там.
// этого тоже можно избежать забирая $VARIABLE из хостнейма и присвоенный адрес из системы
-e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 \
можно завязаться на hostname, но т.к. мы обеспечиваем работу сервиса, то сущностью «сервис» оперировать логичнее.
// Это сугубо специфичное и должно указываться в dockerfile
--volumes-from=badoo_loop \
нет, нельзя это указывать в Dockerfile, т.к. там мы можем указать какие директории будем экспортировать, а нам нужен еще и импорт.
Можно с лёгкостью уменьшить до
VARIABLE=SERVICE;docker run -d \
// Это необходимо для создания фильтрации в централизованном лог сервере, можно наверно не указывать
--name=$VARIABLE \
// имя образа:
cteam/$VARIABLE:2.30.0_994
если SERVICE == 'ubuntu', а версия == 'latest'(кстате, почему вы ее в переменную не вынесли?), то конструкция:
VARIABLE=ubuntu;docker run -d --name=$VARIABLE cteam/$VARIABLE:latest
работать не будет.
Если говорить серьезно, то все, что вы сочли лишним и решили не указывать – нам важно и нужно. Например через --volumes-from мы добавим или не добавим интерпретатор php, если он по какой-то причине нужен внутри контейнера. Мы также прокинем в контейнер служебные директории, откуда потом будем собирать статистику – да это все про работу одного сервиса.
В данном случае мы не рассматриваем один сервис, как один *nix сервис. Сервис в данном случае – это некоторое приложение, которое должно выдавать ожидаемый нами результат. Да, часто получается так, что для работы данного сервиса может потребоваться более одного *nix сервиса.
Через -e мы передаем параметры, на основании которых мы должны сделать вывод о том, какой тип данного сервиса мы хотим запускать… Опять же – это не указывать нельзя.
лучше всего посмотреть вот тут: habrahabr.ru/company/yamoney/blog/339350, youtu.be/pp9nTXa2DTQ. Буквально менее месяца назад я рассказывал в том числе про это.
Если отвечать тут, не переходя по ссылкам: смотрели на все, на которые стоило смотреть, в том числе K8S, Mesos, Nomad. Конкретных планов по внедрению не было и нет. Они могут появиться, если внезапно в какой-то день мы на нашем тестовом стенде поймем, что «вот она серебряная пуля».
только что заметил сообщение. Да используем по сей день. Изменения произошли хотябы потому, что перешли на использование puppetserver, который на Java, в отличии от Rails.
Если кратко, то:
— добавился PuppetDB
— репорты и profiler уехали в Elasticsearch
— остался LB в виде nginx
Т.е. как мне кажется, если смотреть на схему в общем виде, то она стала проще с точки зрения эксплуатации.
1. Какую сборку ESXi используете? Если это 6+ ветка, то интересно услышать точную версию сборки.
2. Делаете ли вы верифай(проверку на то, что бекапится не мусор, а то, что забекапили – восстановимо) для того, что бекапите?
3. Не было ли проблем с рестором цепочки Full -> Incr1 -> Incr2… -> IncrN => RESTORE?
Спасибо.
Давайте я попробую привести несколько пунктов:
— у нас мало сервисов, которые мажутся горизонтально просто включением новых инстансов
— на начальном этапе внедрения нам нужно было «оркестрировать» максимально одинаково то, что в Docker и то, что нет
— сетевой аспект меня тоже довольно сильно тревожит
Т.е. основных поинтов два — сеть и изначально отличная от нашей архитектура.
Что-то доступно по localhost в рамках pod – это также не чудо и имеет довольно простое объяснение. Данный бонус скорее относится к тем, кто приложение разрабатывает, чем к улучшению чего-то в production.
Балансировка – это прекрасно… RR, ну хорошо – есть еще healthcheck(не ох какой, но есть). То, куда приземляется трафик этого балансировщика… Вас все это устраивает?
Swarm mode не совместим с "--live-restore", как минимум. Swarm – это окончательно подсесть на Docker.
Stateful контейнеры – «не Docker way», но ничего не поделаешь – они есть и с этим как-то нужно жить. Мы приходим к тому, что желательно растянуть сторадж между хостами, на которых в случае чего pod/service может продолжить работу. Цепочку хотелок и зависимостей можно продолжать дальше долго.
К опыту Гугла я отношусь с большим уважением, также как и ко всем тем, кто занимается разработкой продуктов, которые в свою очередь оказывают неоценимую помощь остальным.
И как только я найду ответы хотябы на те сомнения и вопросы, что я написал – я непременно буду готов рассмотреть Kubernetes.
Собираемся и спасибо за Ваши добрые пожелания :)
Т.е. у нас скорее это выглядит так:
— ручное принятие решение о поднятии сервиса/инстанса
— подготовка инстанса
— поднятие
— проверка, что все хорошо
— добавление информации о том, что сервис есть и им можно пользоваться
На самом деле рассмотрение etcd/zookeeper у нас также идет, но я не могу сказать, что на данный момент есть готовое внедрение и полноценное использование, так что на данный момент вот так.
Вот и я задаю этот вопрос – как с этим жить?
Нет, для этого у нас есть несколько devel площадок, которые представляют собой уменьшенную копию нашего production окружения. Именно там они занимаются разработкой, тестированием и прочими прелестями, которые им нравятся.
на данный момент нет, но для среды тестирования используем.
что именно вы имели ввиду? актуальность пакетов ОС и их обновления? Не могли бы вы уточнить вопрос, а я попробую дать более полный ответ.
Спасибо
Часть хостовой системы в контейнер – это вы про /dev/log или что-то еще? если будет более конкретный вопрос, то я попробую на него ответить.
Блочное устройство для docker root – это затем, что мы не хотели и не хотим получить BTRFS by default, именно поэтому был сделан отдельный том для docker root на BTRFS.
Код как таковой внутри контейнеров у нас не распространяется, т.к. большая часть сервисов, про которые я говорил — это binary.
Изначально, когда вы абстрактно предложили свою идею, без подробностей – она казалась вполне себе состоятельной, я воспринял некоторые моменты по-своему. Далее, когда вы начали более подробно раскрывать её – стало понятно, что не всё можно сделать так просто и прозрачно, а значит это скорее всего приведет к некоторым дополнительным костылям/сервисам и т.д. (не обязательно, но на основании написанного – приведет).
Где-то в середине дискуссии мы говорили о том, что можно упростить предложенную мной строку запуска(про linux capabilities продолжать не будем) – я согласен, можно. Но приведенная строка запуска не дает до конца расслабиться инженеру в те моменты, когда он запускает сервис или диагностирует его, т.е. глядя на строку запуска он уже имеет некоторое понимание о том, с чем ему придется иметь дело. Можем упростить команду и скрыть детали? Да! Проблема лишь в том, что это мы уберем в дебри инита нашего контейнера, тем самым осложним диагностику, если это потребуется. А самое главное – человеку придется меньше думать и работать со «сферическим конем в вакууме» =)
p.s.: самое главное и хорошее – это то, что у вам есть мысли и идеи, а также и то, что вы не боитесь и не стесняетесь ими делиться. Так держать!
Неважно есть у нас dhcp или нет, но указать тип сети для контейнера мы должны, а иначе мы используем default bridge, так? Изначально я говорю о том, что нам нужен и мы используем MACVLAN.
Идем дальше. Можно не указывать --ip=. Можно, но тогда нам либо pool адресов при создании macvlan сети для docker нужно как-то обозначить, либо как-то блеклистить те адреса, которые мы не хотим получить в своем контейнере, так?
Для какой системы мониторинга?
мы меняем default gw, который мы проставляли при создании MACVLAN сети на .254, что сделать без NET_ADMIN не получится(да, можно через pipework, но мне не нравится такой вариант)
эта запись будет разной, в зависимости от хоста, на котором запускам контейнер. Да, тоже самое значение я передаю позже в -e HOST_IP=1.1.1.17, его можно использовать. Но т.к. сущности разные, то и указываю отдельно там и там.
можно завязаться на hostname, но т.к. мы обеспечиваем работу сервиса, то сущностью «сервис» оперировать логичнее.
нет, нельзя это указывать в Dockerfile, т.к. там мы можем указать какие директории будем экспортировать, а нам нужен еще и импорт.
если SERVICE == 'ubuntu', а версия == 'latest'(кстате, почему вы ее в переменную не вынесли?), то конструкция:
работать не будет.
Если говорить серьезно, то все, что вы сочли лишним и решили не указывать – нам важно и нужно. Например через --volumes-from мы добавим или не добавим интерпретатор php, если он по какой-то причине нужен внутри контейнера. Мы также прокинем в контейнер служебные директории, откуда потом будем собирать статистику – да это все про работу одного сервиса.
В данном случае мы не рассматриваем один сервис, как один *nix сервис. Сервис в данном случае – это некоторое приложение, которое должно выдавать ожидаемый нами результат. Да, часто получается так, что для работы данного сервиса может потребоваться более одного *nix сервиса.
Через -e мы передаем параметры, на основании которых мы должны сделать вывод о том, какой тип данного сервиса мы хотим запускать… Опять же – это не указывать нельзя.