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 и куда-то там отдаёт. Вроде всё классно, но возникает один вопрос. Тесты-то где должны запускаться? На каком этапе? У разработчика? На дженкинсе? На машине с гитом? Внутри докера отдельным шагом перед сборкой основного образа?
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-ой конфигурации для оплатившей это компании» — вот как назвать эти «пять серверов», «три сервера» и т.п.?
@Zert за сообщение, что Dockerfile build надо запускать в отдельной папке, либо создавать .dockerignore
о, первый написанный и собранный Dockerfile. спасибо
celery+redis (redis патамушта #2763390) продолжительно и в различных позах, могу утверждать, что оно вполне работает как надо. Пришлось дописать немного пришлёпок типа авторетрая и лока вокруг периодик-тасков (смешно, но этого до сих пор нет искаропки) и прошерстить кучу текста и конфигурацию (по дефолту оно почему-то сильно перекошено на скорость в ущерб надёжности — наверно для каргокультистов, которые бенчат факториалы и бегут срать на HN). Но не пришлось с пылающей жопой плевать и всё велосипедить — это уже прогресс и радость.
Доприкручивал вот агрегацию логов, и, вроде, всё — можно, наконец, забыть надолго, пока не начнёт тормозить. Надоело оно сильно.
Всласть поебстясь с Доприкручивал вот агрегацию логов, и, вроде, всё — можно, наконец, забыть надолго, пока не начнёт тормозить. Надоело оно сильно.
Например, об обновлениях надо узнавать. Это уведомления на мыло. Неужели велосипедить скрипт в крон, парсящий apt-get upgrade -s?
Обновление некоторых пакетов может потребовать рестарт чего-угодно, от всякой мелочи до всей системы. Например, какой-нибудь софт юзает либу libsdelatzaebis, а она юзает libkorovniki, для последней выходит секьюрити апдейт, закрывающий возможность выполнить удалённо rm -rf, послав пакет с цитатой из библии, соотв после апдейта софт надо рестартнуть. Как это определять автоматически?
Ах да, некоторый софт ставится не из пакетов.
Бонус-челленж-уровень. Т.к. между публичным обнаружением уязвимости и выкладыванием пакета с поправленным софтом в стабильный репозиторий дистрибутива проходит понятная неминуемая задержка, иногда может хотеться не ждать. Достаточно ли распространена практика, допустим, сразу постить в CVE (или куда?), откуда это потом можно как-то автоматически выдернуть на мыло? Или, как обычно, бардак, и надо выгребать руками из разных зассанных мейлистов и тикет-трекеров?
Девопс же наоборот, добрый адекватный чувак, который стремится минимизировать трудозатраты и идёт на контакт (иначе это не девопс, а сраный быдлоадмин из 90-х). Т.е. по сути человек делает одно и то же, но подход различается, админом быть не модно, а девопсом модно. Уёбищным мудаком с перлом и фрипзд быть не модно, а чотким хипстером с докером быть модно. Одобрено.
Сочуствую вам, господа девопсы.
Само собой, юзера iibrikov на моем сервере нет.
vk.com — это в субботу, 12, т.е. завтра.
Кстати Питер кто интересуется темой DevOps:
coreos.com , то смотрите. Вроде бы похоже на сбычу мечт.
Ежели кто ещё не видел Сервер в локальной сети, сервер в датацентре.
По-умолчанию, все изменения пушатся на локальный сервер("зеркало"), который по крону синхронизируется с датацентром.
Если локальный сервер выключен — можно пушить прямо на сервер в датацентре.
Или локальное гит-зеркало — "ересь" и "ненужно"?