Чтобы добавлять сообщения и комментарии, .

@fillest:
fillest

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

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

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

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

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

@amyodov:
amyodov

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

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

@SpringStorm:
SpringStorm

забыть прописать в hosts две строчки это =______=

@SpringStorm:
SpringStorm

о, первый написанный и собранный Dockerfile. спасибо @Zert за сообщение, что Dockerfile build надо запускать в отдельной папке, либо создавать .dockerignore

@SpringStorm:
SpringStorm

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

@fillest:
fillest

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

@fillest:
fillest

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

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

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

@Zert:
Zert

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

@Zert:
Zert

Вот именно подход к конфигурянию системы с помощью написания Dockerfile (или nix-конфига) я считаю самым правильным и естественным, а всякие puppet и chef (и даже ansible, чо уж там) — говно и пидерсия.

@maxlapshin:
maxlapshin

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

@erthad:
erthad

HashiCorp опять собираются что-то новое релизить на днях.

@erthad:
erthad

тех, кто пользуется Puppet, наверняка заинтересует дашборд от Spotify: github.com

@erthad:
erthad

очень интересный блог про operations (по нашему системное администрирование) dev117.livejournal.com

@folex:
folex

Я понял, какая работа в ИТ самая дерьмовая. DevOps. Я просто статистику настраиваю, а уже заебался.
Сочуствую вам, господа девопсы.

@4DA:
4DA

Посоветуйте костылей чтобы деплоить конфигурации, всякие там ssh ключи, алиасы и прочее говно на машинки.

@bitfield:
bitfield

только что дженкинс собрал билд с версией 1.0.192.168.

@longbow:
longbow

Начали делать деньги на devops. Теперь я знаю как это делать.

@bitfield:
bitfield

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

@aim:
aim

Кстати Питер кто интересуется темой DevOps: vk.com — это в субботу, 12, т.е. завтра.

@Zert:
Zert

Ежели кто ещё не видел coreos.com , то смотрите. Вроде бы похоже на сбычу мечт.

@norguhtar:
norguhtar

devopsreactions.tumblr.com
ЖЫР

@glupovat:
glupovat

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

@bitfield:
bitfield

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

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

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

@CoolCold:
CoolCold

The cliched image for this is a group of developers and sysadmins standing hand in hand, naked in the woods, singing kumbayah until shit just works. It should also include testers, security specialists and environment and release managers too (sorry architects*, we’re getting stuff done here ;) )

scriptrock.com