Pull to refresh
18
0
Send message

отличная статья, спасибо! Вы разложили по полочкам то, что обычно linux инженером кажется чем-то запредельно тяжелым.

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

Всё верно, в явном виде в статье этого нет. Одна из причин заключается в том, что цель — это донесение мысли «Бэкапы важны, бэкапы нужны. Не забывайте проверять и восстанавливаться», но при этом очень не хотелось получить на выходе «очередной скучный доклад(статью) про бэкапы», коих, признаться честно, я видел довольно много.
Если хочется поговорить подробнее по данной тематике, то есть отличное место — https://t.me/pro_ru_bareos. Савелия там, конечно, не найти, а меня вполне.
Отличная статья, спасибо.

Спасибо.
Как мотивируете читать чат с репортами коллег?

По-разному. Для кого-то работает: «там уведомление горит, прочту», а для кого-то «холодный душ по телефону», например «вот ты не читал, а я про это писал сегодня/вчера и т.д. Ай-яй! читай, пожалуйста». Пару-тройку таких итераций и подобного более не повторяется.
Т.е. основная идея тут – это общая польза как для «читателя», так и для «писателя».
Конечно есть. Более того – всегда был. Роль, про которую я говорил – это не менеджер был :)
Т.е. вы наделили чувака доп. обязанностями (менеджерскими, как я понимаю), но подчеркиваете, что это не повышение. На мой взгляд не совсем «здоровая» ситуация

Вы всё верно поняли. Данный подход показал себя в нашем случае как «не рабочий».
Вот здесь (и далее по статье) я так и не понял, как у вас в итоге распределяются задачи?

Я рассказывал в течении доклада, что людям нравится формат – «Мне нравится задача, я могу и хочу ей заниматься», вот такой формат и остается по сей день. Да, бывает такое, что менеджер видит срочность и принимает решение, пообщавшись с исполнителем, что именно он возьмет и будет заниматься задачей.
А в целом с выводами полностью согласен. Жаль только, что совесть может быть далеко не у всех людей в коллективе.

Спасибо. Люди – не роботы :)
Это единственная причина задать вопрос?
Про putty, к сожалению, ничего сказать не могу.
40-50 – это не так много.
Да, так, к сожалению, бывает. Автоматизация и слежение за тем, что делают люди – в нашем случае работники ДЦ – трудоемкая задача, т.к. не очень просто уследить за тем, произошел ли демонтаж или нет.
Я ж «набросил»!
В GLPI для сервера/любой железки прописаны:
— стойка
— юнит в стойке
, при условии, что у вас:
— должны быть заведены параметры стойки
— должны быть заведены параметры «железки» (сколько юнитов та или иная платформа занимает)
Вопрос заполнения данной информации – это вопрос целой дискуссии. Решение зависит от того как много оборудования, как далеко от вас ДЦ, как часто вы что-то переставляете/добавляете и тд.
Используется плагин Rack enclosures management
В этот раз вышло так, что содержание не совсем соответствует тому, что написано на упаковке. Да, я про название и, в итоге, содержание.
В следующий раз постараюсь так не делать :)
дирижёр не осилил
дожили и даже пережили!
можно относительно легко сделать
это в теории, а на деле ты сам все прекрасно помнишь!
Доставку вообще никто не мешает делать не через docker distribution!
Привет.
Зачем? – Для привлечения внимания.
Как она помогает? – Раз появился такой вопрос, то внимание она привлекает! Значит работает!
Привет!
Docker в production используем, про последние актуальные цифры(что где и сколько) вы можете посмотреть в моем докладе на мероприятии habrahabr.ru/company/yamoney/blog/339350. Ссылка на видео – youtu.be/pp9nTXa2DTQ.

— используете ли вы 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, свои решения, что-то еще?)

Стабильный и основной инструмент:
Если кратко, то у нас на хостах запущен «мониторинговый» контейнер, который:
  • — читает эвенты от демона docker
  • — читает системные метрики
  • — отправляет это в zabbix/graphite

Если чуть подробнее, то советую посмотреть на вот эти 2 выступления, где я касался данного вопроса: tech.badoo.com/ru/presentation/191/docker-v-badoo и tech.badoo.com/ru/presentation/137/docker-v-rabote-vzglyad-na
Параллельный, находящийся в разработке инструмент:
  • — prometheus
  • — grafana
  • — telegraf

Telegraf запускается на хосте, собирает host & dockerd related информацию и открывает порт, на котором готов отдавать статистику для и в формате Prometheus. Prometheus берет информацию из Consul по маске наличия сервиса docker на хосте. Далее в grafana рисуем картинки + тестируем алертинг от Prometheus.
На данный момент это прототип, хоть лично мне он очень нравится :)
— перечислите, какие docker-контейнеры используете. Например, у меня в стеке разворачиваются:

Это не будет иметь никакого смысла, т.к. 90% названий вам, скорее всего, ничего не скажут. Мы не используем контейнеры с dockerhub(за редчайшим исключением) и собираем их самостоятельно, даже если это просто nginx || redis – это будет собранный нами контейнер на базе SLES.
Спасибо, я слышал, что k8s хорош. Девопсов у нас нет, а разработчики до нас, скорее всего, не добегут.
Процесс деплоя сервиса на prod окружение несколько сложнее, чем просто «разработчик захотел», а раз это так, то как вывод – мы не упираемся в скорость поднятия в облаке. Облака-то тоже нет :)

Information

Rating
Does not participate
Registered
Activity