вот обратный проксик способный сам себя обслужить в Let's Encrypt
reproxy.io
reproxy.io
meme-arsenal.com
У нас было 2 yaml-погромиста 75 тестовых приложений, 5 продуктовых кластеров, полудохлый ArgoCD и целое множество пайплайнов всех годов и окружений, плэйбуки, а также TFS (Azure DevOps), SLA, conf-call-ы, обучение по интеграционной шине и 2 дюжины не-lint-ующихся конфигов. Не то чтобы это был необходимый запас для деплоя, но если начал собирать устойчивую инфраструктуру, становится трудно остановиться. Единственное, что вызывало у меня опасение — это DRP. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем kernel panic. Я знал, что рано или поздно мы перейдем и на эту дрянь.
У нас было 2 yaml-погромиста 75 тестовых приложений, 5 продуктовых кластеров, полудохлый ArgoCD и целое множество пайплайнов всех годов и окружений, плэйбуки, а также TFS (Azure DevOps), SLA, conf-call-ы, обучение по интеграционной шине и 2 дюжины не-lint-ующихся конфигов. Не то чтобы это был необходимый запас для деплоя, но если начал собирать устойчивую инфраструктуру, становится трудно остановиться. Единственное, что вызывало у меня опасение — это DRP. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем kernel panic. Я знал, что рано или поздно мы перейдем и на эту дрянь.
Наконец-то мой воркфлоу ужался до одного экрана вширь. Но это не предел
Такая ситуация.
Разработчик что-то разработывает, заливает код на git, откуда его забирает jenkins, собирает из него на удалённой машине образ docker и куда-то там отдаёт. Вроде всё классно, но возникает один вопрос. Тесты-то где должны запускаться? На каком этапе? У разработчика? На дженкинсе? На машине с гитом? Внутри докера отдельным шагом перед сборкой основного образа?
Разработчик что-то разработывает, заливает код на git, откуда его забирает jenkins, собирает из него на удалённой машине образ docker и куда-то там отдаёт. Вроде всё классно, но возникает один вопрос. Тесты-то где должны запускаться? На каком этапе? У разработчика? На дженкинсе? На машине с гитом? Внутри докера отдельным шагом перед сборкой основного образа?
О, наконец-то в Интернете нарисовали дево-пса:
Окружения разработчика с помощью Docker + sshd + PAM medium.com
Я правильно понимаю, что кроме sendmail вообще никто не умеет "попробовали постучаться в MTA, не получилось — положили в очередь"?
В 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-доступ или тупо пересоздать её.
Докер же решает не всё и не полностью и создаёт новые проблемы, вводя лишний уровень абстракции.
Вот представьте, у вас есть, допустим, фронтендер, у него мак. Ну хоть не шинда, спасибо б-женьке. Так вот, фронтовик в ентих ваших терминалах ничего не кумекает, т.к. он погромист на хтмл^w жквере^w бэкбоне, деньги плотютъ, чего ж голову забивать. И вот нужно для него поднять и обновлять ваше уеб-творение у него на компе. А сделать это не так-то просто, ведь платформа заточена для.. думанья по-другому, а не для (уеб-)разработки.
Да и сетап приложения уже разросся сам по себе, требует увесистой инструкции в вики, и в инструкции уже то тут, то там — копипасты из деплой-скриптов.
И тут некие очередные продавцы облаков придумали новое™ простое™ решение. Заключается оно в том, чтобы принять их философию™, отрезать себе руки и ноги, забыть все сложности, и проблема уйдёт сама собой! А если не уйдёт или если будет непонятно как решать пачку новых проблем, купить консультации у Docker Inc, конечно же.
А суть проблемы простая: 1) издревле существует стопицот способов вообще организовать среду 2) вся эта мотня должна одинаково работать локально и на сервере 3) использование и поддержка деплоя должны быть простыми, автоматизированными.
1) Поэтому нужен единый "стандарт", который можно просто продвигать в качестве best practices. Что-нибудь вроде "раскладывать всё в opt, крутить под supervisor (или systemd — он уже фактически стал стандартом), для деплоя использовать X способами Y", "настроить особым образом openvz". И вокруг этого стандарта развивать тулчейн. И даже консалтинг интерпрайз-лохам можно тоже впаривать.
2) Как на маке сделать, чтоб всё нужное было как на линуксе? Поставить линукс — только в виртуалку. Докер для мака, кстати, это ведь сборочка виртуалбокса от васяна666. Потому что докер фундаментально завязан на фичи ядра линукса ("ship anywhere", ага, ага).
3) Систему деплоя организовать, чтобы она деплоила и на локальную тачку.
Таким образом, локальный деплой будет выглядеть так: поставил виртуалку (если нужно), запустил в ней деплой, всё. Также, при проблемах в виртуалку можно пробросить ssh-доступ или тупо пересоздать её.
Докер же решает не всё и не полностью и создаёт новые проблемы, вводя лишний уровень абстракции.
А подскажите, плиз, как принято называть в девопсовой традиции совокупность каких-то серверов, на которую разворачивается проект в какой-то конкретной конфигурации (притом что на другую такую совокупность он разворачивается в другой)?
Типа, «у нас есть пять серверов, на которые наш проект развёрнут для обычных пользователей; три сервера, на которые он развёрнут для тестирования разработчиками; два сервера, куда он разворачивается для автотестов; и ещё шесть серверов, куда он развёрнут в white-label-ой конфигурации для оплатившей это компании» — вот как назвать эти «пять серверов», «три сервера» и т.п.?
Типа, «у нас есть пять серверов, на которые наш проект развёрнут для обычных пользователей; три сервера, на которые он развёрнут для тестирования разработчиками; два сервера, куда он разворачивается для автотестов; и ещё шесть серверов, куда он развёрнут в white-label-ой конфигурации для оплатившей это компании» — вот как назвать эти «пять серверов», «три сервера» и т.п.?
забыть прописать в hosts две строчки это =______=
о, первый написанный и собранный Dockerfile. спасибо @Zert за сообщение, что Dockerfile build надо запускать в отдельной папке, либо создавать .dockerignore
А 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 (или куда?), откуда это потом можно как-то автоматически выдернуть на мыло? Или, как обычно, бардак, и надо выгребать руками из разных зассанных мейлистов и тикет-трекеров?
Например, об обновлениях надо узнавать. Это уведомления на мыло. Неужели велосипедить скрипт в крон, парсящий apt-get upgrade -s?
Обновление некоторых пакетов может потребовать рестарт чего-угодно, от всякой мелочи до всей системы. Например, какой-нибудь софт юзает либу libsdelatzaebis, а она юзает libkorovniki, для последней выходит секьюрити апдейт, закрывающий возможность выполнить удалённо rm -rf, послав пакет с цитатой из библии, соотв после апдейта софт надо рестартнуть. Как это определять автоматически?
Ах да, некоторый софт ставится не из пакетов.
Бонус-челленж-уровень. Т.к. между публичным обнаружением уязвимости и выкладыванием пакета с поправленным софтом в стабильный репозиторий дистрибутива проходит понятная неминуемая задержка, иногда может хотеться не ждать. Достаточно ли распространена практика, допустим, сразу постить в CVE (или куда?), откуда это потом можно как-то автоматически выдернуть на мыло? Или, как обычно, бардак, и надо выгребать руками из разных зассанных мейлистов и тикет-трекеров?
Ну и хипстерская движуха по замене админов на девопсов тоже правильная, ящитаю. Админ — это жырный уёбок в свитере из собственной бороды, который постоянно ноет, что ему сложно конфигурять, дрочит на аптайм системы (и на фрипзд частенько), тусуется на форумах с такими же уёбками, которые обсирают программистов, маркетологов и начальство (ведь всем понятно, что админ — главный человек в конторе, он приносит бабло, программисты с маркетологами его тратят, а начальство заставляет ставить гадкий линупс вместо Святого ФриПЗД).
Девопс же наоборот, добрый адекватный чувак, который стремится минимизировать трудозатраты и идёт на контакт (иначе это не девопс, а сраный быдлоадмин из 90-х). Т.е. по сути человек делает одно и то же, но подход различается, админом быть не модно, а девопсом модно. Уёбищным мудаком с перлом и фрипзд быть не модно, а чотким хипстером с докером быть модно. Одобрено.
Девопс же наоборот, добрый адекватный чувак, который стремится минимизировать трудозатраты и идёт на контакт (иначе это не девопс, а сраный быдлоадмин из 90-х). Т.е. по сути человек делает одно и то же, но подход различается, админом быть не модно, а девопсом модно. Уёбищным мудаком с перлом и фрипзд быть не модно, а чотким хипстером с докером быть модно. Одобрено.
Вот именно подход к конфигурянию системы с помощью написания Dockerfile (или nix-конфига) я считаю самым правильным и естественным, а всякие puppet и chef (и даже ansible, чо уж там) — говно и пидерсия.
К вопросу о том, почему мы флюссоник деплоим под рутом. Мы насчитали уже 4 разных варианта создания пользователя под линуксом. Один правильный и три разных rpm-ных
HashiCorp опять собираются что-то новое релизить на днях.
тех, кто пользуется Puppet, наверняка заинтересует дашборд от Spotify: github.com
очень интересный блог про operations (по нашему системное администрирование) dev117.livejournal.com
Я понял, какая работа в ИТ самая дерьмовая. DevOps. Я просто статистику настраиваю, а уже заебался.
Сочуствую вам, господа девопсы.
Сочуствую вам, господа девопсы.
Посоветуйте костылей чтобы деплоить конфигурации, всякие там ssh ключи, алиасы и прочее говно на машинки.
только что дженкинс собрал билд с версией 1.0.192.168.
Обновил дженкинс. Теперь ссылка login русифицируется как iibrikov, а подпись "Password" к окну ввода пароля — как "xc46f3s" (там другой пароль, на самом деле, но суть вам ясна).
Само собой, юзера iibrikov на моем сервере нет.
Само собой, юзера iibrikov на моем сервере нет.
Кстати Питер кто интересуется темой DevOps: vk.com — это в субботу, 12, т.е. завтра.
Ежели кто ещё не видел coreos.com , то смотрите. Вроде бы похоже на сбычу мечт.
А я правильно понимаю, что этот ваш DevOps — это мастер на все руки, работающий постоянно в авральном режиме? Если да, то зачем надо этим гордиться и дальше в это углубляться?
Посоветуйте гит-сервер (~ 30 пользователей/50 проектов, желательна веб-морда для управления правами), на котором можно было бы запилить такую схему:
Сервер в локальной сети, сервер в датацентре.
По-умолчанию, все изменения пушатся на локальный сервер("зеркало"), который по крону синхронизируется с датацентром.
Если локальный сервер выключен — можно пушить прямо на сервер в датацентре.
Или локальное гит-зеркало — "ересь" и "ненужно"?
Сервер в локальной сети, сервер в датацентре.
По-умолчанию, все изменения пушатся на локальный сервер("зеркало"), который по крону синхронизируется с датацентром.
Если локальный сервер выключен — можно пушить прямо на сервер в датацентре.
Или локальное гит-зеркало — "ересь" и "ненужно"?
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
scriptrock.com