to post messages and comments.

В The Myth of the Root Cause: How Complex Web Systems Fail и Each necessary, but only jointly sufficient пишут о том, что при анализе падения, выхода из строя сложной системы не следует искать единую корневую причину. Анализируя произошедшее падение постфактум нам свойственно выделять одни события и недооценивать другие, а также неправильно выстраивать их во времени, путая причину и следствие. Также, когда объяснение требуют как можно скорее, нам свойственно упрощать и не докапываться до истинных причин. Нахождение единственной причины падения сложной системы сравнивают с поиском единственной причины успеха человека / бизнеса. На самом деле причин много, но каждая из них по отдельности не является достаточной, а только некоторая их комбинация. Надо перестать воспринимать сложную систему как линейную, а в нелинейной системе, как известно, даже небольшие отклонения значений ее параметров могут приводить к существенным изменениям всей системы. Утверждается, что сложную систему следует считать сломанной по умолчанию.
Опасность сведения падения системы к единственной корневой причине заключается еще и в том, что по результатам анализа обычно принимаются меры по недопущению предполагаемой причины повторно, которые сами по себе могут стать причиной следующего падения.

Я недавно, наконец, понял, какую проблему будто бы хотели решить докером, и как её надо было бы решать.

Вот представьте, у вас есть, допустим, фронтендер, у него мак. Ну хоть не шинда, спасибо б-женьке. Так вот, фронтовик в ентих ваших терминалах ничего не кумекает, т.к. он погромист на хтмл^w жквере^w бэкбоне, деньги плотютъ, чего ж голову забивать. И вот нужно для него поднять и обновлять ваше уеб-творение у него на компе. А сделать это не так-то просто, ведь платформа заточена для.. думанья по-другому, а не для (уеб-)разработки.
Да и сетап приложения уже разросся сам по себе, требует увесистой инструкции в вики, и в инструкции уже то тут, то там — копипасты из деплой-скриптов.

И тут некие очередные продавцы облаков придумали новое™ простое™ решение. Заключается оно в том, чтобы принять их философию™, отрезать себе руки и ноги, забыть все сложности, и проблема уйдёт сама собой! А если не уйдёт или если будет непонятно как решать пачку новых проблем, купить консультации у Docker Inc, конечно же.

А суть проблемы простая: 1) издревле существует стопицот способов вообще организовать среду 2) вся эта мотня должна одинаково работать локально и на сервере 3) использование и поддержка деплоя должны быть простыми, автоматизированными.

1) Поэтому нужен единый "стандарт", который можно просто продвигать в качестве best practices. Что-нибудь вроде "раскладывать всё в opt, крутить под supervisor (или systemd — он уже фактически стал стандартом), для деплоя использовать X способами Y", "настроить особым образом openvz". И вокруг этого стандарта развивать тулчейн. И даже консалтинг интерпрайз-лохам можно тоже впаривать.
2) Как на маке сделать, чтоб всё нужное было как на линуксе? Поставить линукс — только в виртуалку. Докер для мака, кстати, это ведь сборочка виртуалбокса от васяна666. Потому что докер фундаментально завязан на фичи ядра линукса ("ship anywhere", ага, ага).
3) Систему деплоя организовать, чтобы она деплоила и на локальную тачку.
Таким образом, локальный деплой будет выглядеть так: поставил виртуалку (если нужно), запустил в ней деплой, всё. Также, при проблемах в виртуалку можно пробросить ssh-доступ или тупо пересоздать её.
Докер же решает не всё и не полностью и создаёт новые проблемы, вводя лишний уровень абстракции.

А подскажите, плиз, как принято называть в девопсовой традиции совокупность каких-то серверов, на которую разворачивается проект в какой-то конкретной конфигурации (притом что на другую такую совокупность он разворачивается в другой)?

Типа, «у нас есть пять серверов, на которые наш проект развёрнут для обычных пользователей; три сервера, на которые он развёрнут для тестирования разработчиками; два сервера, куда он разворачивается для автотестов; и ещё шесть серверов, куда он развёрнут в white-label-ой конфигурации для оплатившей это компании» — вот как назвать эти «пять серверов», «три сервера» и т.п.?

А ansible 1.7 и 1.9 сильно отличаются =) никто не посоветует случаем как лучше сделать docker pull image из приватного репозитория с помощью ansible? Или ещё какие способы, как образ загрузить на десяток серверов. можно конечно Dockerfile написать, но пока не пробовала.

Всласть поебстясь с celery+redis (redis патамушта #2763390) продолжительно и в различных позах, могу утверждать, что оно вполне работает как надо. Пришлось дописать немного пришлёпок типа авторетрая и лока вокруг периодик-тасков (смешно, но этого до сих пор нет искаропки) и прошерстить кучу текста и конфигурацию (по дефолту оно почему-то сильно перекошено на скорость в ущерб надёжности — наверно для каргокультистов, которые бенчат факториалы и бегут срать на HN). Но не пришлось с пылающей жопой плевать и всё велосипедить — это уже прогресс и радость.
Доприкручивал вот агрегацию логов, и, вроде, всё — можно, наконец, забыть надолго, пока не начнёт тормозить. Надоело оно сильно.

А есть какие best practices процессов обновления пакетов на серваках?

Например, об обновлениях надо узнавать. Это уведомления на мыло. Неужели велосипедить скрипт в крон, парсящий apt-get upgrade -s?
Обновление некоторых пакетов может потребовать рестарт чего-угодно, от всякой мелочи до всей системы. Например, какой-нибудь софт юзает либу libsdelatzaebis, а она юзает libkorovniki, для последней выходит секьюрити апдейт, закрывающий возможность выполнить удалённо rm -rf, послав пакет с цитатой из библии, соотв после апдейта софт надо рестартнуть. Как это определять автоматически?
Ах да, некоторый софт ставится не из пакетов.

Бонус-челленж-уровень. Т.к. между публичным обнаружением уязвимости и выкладыванием пакета с поправленным софтом в стабильный репозиторий дистрибутива проходит понятная неминуемая задержка, иногда может хотеться не ждать. Достаточно ли распространена практика, допустим, сразу постить в CVE (или куда?), откуда это потом можно как-то автоматически выдернуть на мыло? Или, как обычно, бардак, и надо выгребать руками из разных зассанных мейлистов и тикет-трекеров?

Ну и хипстерская движуха по замене админов на девопсов тоже правильная, ящитаю. Админ — это жырный уёбок в свитере из собственной бороды, который постоянно ноет, что ему сложно конфигурять, дрочит на аптайм системы (и на фрипзд частенько), тусуется на форумах с такими же уёбками, которые обсирают программистов, маркетологов и начальство (ведь всем понятно, что админ — главный человек в конторе, он приносит бабло, программисты с маркетологами его тратят, а начальство заставляет ставить гадкий линупс вместо Святого ФриПЗД).
Девопс же наоборот, добрый адекватный чувак, который стремится минимизировать трудозатраты и идёт на контакт (иначе это не девопс, а сраный быдлоадмин из 90-х). Т.е. по сути человек делает одно и то же, но подход различается, админом быть не модно, а девопсом модно. Уёбищным мудаком с перлом и фрипзд быть не модно, а чотким хипстером с докером быть модно. Одобрено.

К вопросу о том, почему мы флюссоник деплоим под рутом. Мы насчитали уже 4 разных варианта создания пользователя под линуксом. Один правильный и три разных rpm-ных

Обновил дженкинс. Теперь ссылка login русифицируется как iibrikov, а подпись "Password" к окну ввода пароля — как "xc46f3s" (там другой пароль, на самом деле, но суть вам ясна).
Само собой, юзера iibrikov на моем сервере нет.

А я правильно понимаю, что этот ваш DevOps — это мастер на все руки, работающий постоянно в авральном режиме? Если да, то зачем надо этим гордиться и дальше в это углубляться?

Посоветуйте гит-сервер (~ 30 пользователей/50 проектов, желательна веб-морда для управления правами), на котором можно было бы запилить такую схему:

Сервер в локальной сети, сервер в датацентре.
По-умолчанию, все изменения пушатся на локальный сервер("зеркало"), который по крону синхронизируется с датацентром.
Если локальный сервер выключен — можно пушить прямо на сервер в датацентре.

Или локальное гит-зеркало — "ересь" и "ненужно"?