отличная статья, спасибо! Вы разложили по полочкам то, что обычно linux инженером кажется чем-то запредельно тяжелым.
XDP - это сейчас прям такой горячий пирожок, но при этом при первом приближении уровень вхождения кажется высоким. Очень надеюсь, что после Вашей статьи тех, кто в первый или не в первый раз решит посмотреть на XDP еще раз станет чуточку больше.
Всё верно, в явном виде в статье этого нет. Одна из причин заключается в том, что цель — это донесение мысли «Бэкапы важны, бэкапы нужны. Не забывайте проверять и восстанавливаться», но при этом очень не хотелось получить на выходе «очередной скучный доклад(статью) про бэкапы», коих, признаться честно, я видел довольно много.
Если хочется поговорить подробнее по данной тематике, то есть отличное место — https://t.me/pro_ru_bareos. Савелия там, конечно, не найти, а меня вполне.
По-разному. Для кого-то работает: «там уведомление горит, прочту», а для кого-то «холодный душ по телефону», например «вот ты не читал, а я про это писал сегодня/вчера и т.д. Ай-яй! читай, пожалуйста». Пару-тройку таких итераций и подобного более не повторяется.
Т.е. основная идея тут – это общая польза как для «читателя», так и для «писателя».
Т.е. вы наделили чувака доп. обязанностями (менеджерскими, как я понимаю), но подчеркиваете, что это не повышение. На мой взгляд не совсем «здоровая» ситуация
Вы всё верно поняли. Данный подход показал себя в нашем случае как «не рабочий».
Вот здесь (и далее по статье) я так и не понял, как у вас в итоге распределяются задачи?
Я рассказывал в течении доклада, что людям нравится формат – «Мне нравится задача, я могу и хочу ей заниматься», вот такой формат и остается по сей день. Да, бывает такое, что менеджер видит срочность и принимает решение, пообщавшись с исполнителем, что именно он возьмет и будет заниматься задачей.
А в целом с выводами полностью согласен. Жаль только, что совесть может быть далеко не у всех людей в коллективе.
40-50 – это не так много.
Да, так, к сожалению, бывает. Автоматизация и слежение за тем, что делают люди – в нашем случае работники ДЦ – трудоемкая задача, т.к. не очень просто уследить за тем, произошел ли демонтаж или нет.
В GLPI для сервера/любой железки прописаны:
— стойка
— юнит в стойке
, при условии, что у вас:
— должны быть заведены параметры стойки
— должны быть заведены параметры «железки» (сколько юнитов та или иная платформа занимает)
Вопрос заполнения данной информации – это вопрос целой дискуссии. Решение зависит от того как много оборудования, как далеко от вас ДЦ, как часто вы что-то переставляете/добавляете и тд.
Используется плагин Rack enclosures management
В этот раз вышло так, что содержание не совсем соответствует тому, что написано на упаковке. Да, я про название и, в итоге, содержание.
В следующий раз постараюсь так не делать :)
— используете ли вы data-only контейнеры для доставки кода или упаковываете код сразу в контейнер (например, с php)?
Контейнеры с php кодом приложения(читай Badoo) мы как таковые не используем. Причина тому – наличие отдельных(выделенных) машин, на которых кроме nginx+php-fpm, а также кода, более ничего нет. Применение контейнеров там, по нашему мнению, не оправдано и не нужно.
Однако у нас есть некоторые сервисы, которым нужно:
php
наличие кода
Для таких случаев делаем так:
— на машине, на которой предположительно планируется запуск сервиса, который требует вышеописанное, создается «data-»/«mapping-» контейнер, который содержит в себе все необходимые маунты. Обычно это php, code, которые в свою очередь линкуются на директории хост системы.
— управление версиями кода и php выполняется стандартными инструментами НЕ для контейнеров
— запускается тот самый сервис, используя инструкцию "--volumes-from mapping_container"
— актуальность маунтов «вспомогательного» контейнера, конечно мониторится
Еще бывает такое, что сервис должен где-то хранить statefull данные – для этого мы применяем named volumes, что удобно и, скорее всего, очевидно.
— какой оркестратор используете и почему?
На данный момент самописный свой. Ответ на этот вопрос скрывается также в ссылках на последнее видео.
— сколько нод в docker-кластере, в скольки датацентрах и на скольки континентах они расположены?
Нод: # mco find hosts -F docker_package=true | wc -l
687 Дата центры:
4 или 6(смотря как считать); 2 континента
— чем мониторите docker-контейнеры (cAdvisor, свои решения, что-то еще?)
Стабильный и основной инструмент:
Если кратко, то у нас на хостах запущен «мониторинговый» контейнер, который:
Telegraf запускается на хосте, собирает host & dockerd related информацию и открывает порт, на котором готов отдавать статистику для и в формате Prometheus. Prometheus берет информацию из Consul по маске наличия сервиса docker на хосте. Далее в grafana рисуем картинки + тестируем алертинг от Prometheus.
На данный момент это прототип, хоть лично мне он очень нравится :)
— перечислите, какие docker-контейнеры используете. Например, у меня в стеке разворачиваются:
Это не будет иметь никакого смысла, т.к. 90% названий вам, скорее всего, ничего не скажут. Мы не используем контейнеры с dockerhub(за редчайшим исключением) и собираем их самостоятельно, даже если это просто nginx || redis – это будет собранный нами контейнер на базе SLES.
Спасибо, я слышал, что k8s хорош. Девопсов у нас нет, а разработчики до нас, скорее всего, не добегут.
Процесс деплоя сервиса на prod окружение несколько сложнее, чем просто «разработчик захотел», а раз это так, то как вывод – мы не упираемся в скорость поднятия в облаке. Облака-то тоже нет :)
отличная статья, спасибо! Вы разложили по полочкам то, что обычно linux инженером кажется чем-то запредельно тяжелым.
XDP - это сейчас прям такой горячий пирожок, но при этом при первом приближении уровень вхождения кажется высоким. Очень надеюсь, что после Вашей статьи тех, кто в первый или не в первый раз решит посмотреть на XDP еще раз станет чуточку больше.
Если хочется поговорить подробнее по данной тематике, то есть отличное место — https://t.me/pro_ru_bareos. Савелия там, конечно, не найти, а меня вполне.
Спасибо.
По-разному. Для кого-то работает: «там уведомление горит, прочту», а для кого-то «холодный душ по телефону», например «вот ты не читал, а я про это писал сегодня/вчера и т.д. Ай-яй! читай, пожалуйста». Пару-тройку таких итераций и подобного более не повторяется.
Т.е. основная идея тут – это общая польза как для «читателя», так и для «писателя».
Вы всё верно поняли. Данный подход показал себя в нашем случае как «не рабочий».
Я рассказывал в течении доклада, что людям нравится формат – «Мне нравится задача, я могу и хочу ей заниматься», вот такой формат и остается по сей день. Да, бывает такое, что менеджер видит срочность и принимает решение, пообщавшись с исполнителем, что именно он возьмет и будет заниматься задачей.
Спасибо. Люди – не роботы :)
Да, так, к сожалению, бывает. Автоматизация и слежение за тем, что делают люди – в нашем случае работники ДЦ – трудоемкая задача, т.к. не очень просто уследить за тем, произошел ли демонтаж или нет.
— стойка
— юнит в стойке
, при условии, что у вас:
— должны быть заведены параметры стойки
— должны быть заведены параметры «железки» (сколько юнитов та или иная платформа занимает)
Вопрос заполнения данной информации – это вопрос целой дискуссии. Решение зависит от того как много оборудования, как далеко от вас ДЦ, как часто вы что-то переставляете/добавляете и тд.
Используется плагин Rack enclosures management
В следующий раз постараюсь так не делать :)
1. старое, но инструменты теже – events.yandex.ru/lib/talks/1123/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
2. habrahabr.ru/company/badoo/blog/133387/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
3. habrahabr.ru/company/badoo/blog/134228/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base%3BXnAhThbkTce%2FTd2Xe7Nmnw%3D%3D
4. ну и чуть обновленная информация будет в рамках доклада на HL++ 2017
Зачем? – Для привлечения внимания.
Как она помогает? – Раз появился такой вопрос, то внимание она привлекает! Значит работает!
Docker в production используем, про последние актуальные цифры(что где и сколько) вы можете посмотреть в моем докладе на мероприятии habrahabr.ru/company/yamoney/blog/339350. Ссылка на видео – youtu.be/pp9nTXa2DTQ.
Контейнеры с php кодом приложения(читай Badoo) мы как таковые не используем. Причина тому – наличие отдельных(выделенных) машин, на которых кроме nginx+php-fpm, а также кода, более ничего нет. Применение контейнеров там, по нашему мнению, не оправдано и не нужно.
Однако у нас есть некоторые сервисы, которым нужно:
Для таких случаев делаем так:
На данный момент самописный свой. Ответ на этот вопрос скрывается также в ссылках на последнее видео.
Нод:
# mco find hosts -F docker_package=true | wc -l687
Дата центры:
4 или 6(смотря как считать); 2 континента
Стабильный и основной инструмент:
Если кратко, то у нас на хостах запущен «мониторинговый» контейнер, который:
Если чуть подробнее, то советую посмотреть на вот эти 2 выступления, где я касался данного вопроса: tech.badoo.com/ru/presentation/191/docker-v-badoo и tech.badoo.com/ru/presentation/137/docker-v-rabote-vzglyad-na
Параллельный, находящийся в разработке инструмент:
Telegraf запускается на хосте, собирает host & dockerd related информацию и открывает порт, на котором готов отдавать статистику для и в формате Prometheus. Prometheus берет информацию из Consul по маске наличия сервиса docker на хосте. Далее в grafana рисуем картинки + тестируем алертинг от Prometheus.
На данный момент это прототип, хоть лично мне он очень нравится :)
Это не будет иметь никакого смысла, т.к. 90% названий вам, скорее всего, ничего не скажут. Мы не используем контейнеры с dockerhub(за редчайшим исключением) и собираем их самостоятельно, даже если это просто nginx || redis – это будет собранный нами контейнер на базе SLES.
Процесс деплоя сервиса на prod окружение несколько сложнее, чем просто «разработчик захотел», а раз это так, то как вывод – мы не упираемся в скорость поднятия в облаке. Облака-то тоже нет :)