LINUX.ORG.RU

Накипело Ansible/Devops/CTO и разумности трэд

 , , , ,


1

3

Здравствуй лорчик, сегодня я решил поделится о накипевшем и заодно спросить совета.

Ситуация такая: Работаю удалённо админом на одном проекте. Команда состоит из нескольких программистов и меня ( единственного админа ).

Проблема заключается в том что CTO и некоторые члены команды слышали про администрирование только из фильмов и картинок, но это не мешает им частенько предлагать использовать ту или иную технологию когда в этом нету необходимости.

На этот раз от меня требуют чтобы КАЖДЫЙ конфиг изменялся через ansible и написать сценарии для каждого изменённого конфига. С моей точки зрения это дичайщий overkill учитывая тот факт что в инфраструктуре есть сервисы в которых конфиг меняется раз в пол года, или вовсе не менялся с момента установки, в некоторых местах в конфиге были подправлены всего 2 строки. А так же у нас нету похожих виртуальных машин, каждая вм выполняет свою уникальную роль.

С одной стороны я могу не парится, т.к. всё равно у меня оплата почасовая, но с другой стороны напрегает разумность данной задачи.

При попытке всё это оспорить я получил следующий ответы:

  • Мы хотим быть уверенны что в случае потери сервера сможем воспроизвести всю инфраструктуру
  • Это нам поможет при миграции или масштабировании

Мои попытки разубедить этих техно-хипстеров были безуспешными.

Нет не думайте что я не боюсь ansible. Я даже умею им пользоваться на базовом уровне, иногда прибегал к его помощи при необходимость.

В инфраструктуре много чего было сделано руками:

  • Установлены пакеты
  • Подправлены конфиги для:
    • nginx
    • elasticsearch
    • mongodb
    • postgresql
    • redis
    • logrotate
    • sudoers
    • sysctl.conf
  • Созданы пользователи
  • импортированы публичные ключи для ssh
  • Изменены права на некоторые файлы
  • И многое другое

К чему я всё это? Меня интересует ответ на следующие вопросы.

Когда стоит и не стоит использовать ansible ( и прочие оркестраторы ) ?
Что вы делаете когда вам дают неразумные задачи?
И как вы решаете подобные вопросы?

★★★★★

они правы.
да и тебя потом можно будет заменить\уволить безболезненно.

system-root ★★★ ()

Ты это, быстрее делай, а не разглагольствуй, а то наймут индуса.
Их доводы имеют более чем здравый смысл.

Deleted ()

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

Deleted ()
Ответ на: комментарий от system-root

Я не против автоматизировать рутину. Но от меня требуют автоматизировать то что не трогается месяцами. Это уже слишком.

snaf ★★★★★ ()
Ответ на: комментарий от snaf

то что не трогается месяцами

потом случись что, будешь хлестать успокоительные, потому что сервисы не поднимаются, за месяцы\годы забыл важные мелочи, а документации нет, ведь стартап, всё меняется. сидишь и думаешь, что значит «Изменены права на некоторые файлы» в shpargalka.txt
оркестраторы нужны, оркестраторы важны.

system-root ★★★ ()
Последнее исправление: system-root (всего исправлений: 1)

Писать рецептики для всякой ерунды это явно бред. А вот иметь план разворачивания серверов это нужная штука.

GoNaX ★★★ ()
Ответ на: комментарий от system-root

Есть приложение в конфиг которого было внесёно следующее изменение:

listen=127.0.0.1
изменён на
listen=0.0.0.0

Таких примеров десятки. Не вижу смысла для этого городить оркестрацию.

а документации нет, ведь стартап, всё меняется.

Раньше не было, но сейчас медленными шагами пишется.

snaf ★★★★★ ()
Последнее исправление: snaf (всего исправлений: 1)

Дичайше поддерживаю. Жутко бесит когда отконфигурено 2 строчки методом раскомментирования где-то в дефолтном конфиге, и ты сидишь пытаешься понять чем эта конфа отличается от дефолтной и отличается ли в принципе. Все изменения должны проходить через систему управления конфигурацией и храниться в vcs. Как минимум это должно выполняться для прод площадки.

trancefer ★★ ()
Ответ на: комментарий от snaf

Таких примеров десятки

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

system-root ★★★ ()
Ответ на: комментарий от snaf

по идее, должно быть автоматизировано всё с нуля, т.е. сплошь, исчерпывающим образом. Другой вопрос, будут ли они сами (!) это запускать, потому что

слышали про администрирование только из фильмов и картинок

но

сможем воспроизвести всю инфраструктуру

early_britney_fun ★★★★ ()
Последнее исправление: early_britney_fun (всего исправлений: 1)
Ответ на: комментарий от snaf

Думаю, они хотят IaC, а не «автоматизировать». И я их люто в этом поддерживаю!

staseg ★★★★★ ()
Ответ на: комментарий от snaf

Не вижу смысла для этого городить оркестрацию.

Не видишь — не городи. Делов-то?

С одной стороны я могу не парится, т.к. всё равно у меня оплата почасовая, но с другой стороны напрегает разумность данной задачи.

Заказчик сказал «надо». И требование разумно. Если «всё через ansible», то и s/127.0.0.1/0.0.0.0/ тоже через ansible. Денег дофига? Опубликуй в job, раз тебе не надо.

Что вы делаете когда вам дают неразумные задачи? И как вы решаете подобные вопросы?

Увольняюсь.

mogwai ★★★ ()
Последнее исправление: mogwai (всего исправлений: 1)
Ответ на: комментарий от system-root

если тебе виднее, то почему появился запрос «сверху»?

Сверху было много вопросов. Пожалуйста укажите какой именно. В любом случае я хотел услышать мнение других админов/девопсов.

хайпанули

эээ.. что?

snaf ★★★★★ ()
Ответ на: комментарий от Deleted

теперь можно ныть весь тред

даже не думал об этом.

snaf ★★★★★ ()

потом твое тело заболело, а сервак упал и девелоперам надо сутками искать эту единственную сраную строчку в файле которую ты поменял и забыл: «ну вот там дето среди тысяч конфигов nginx толи default345.cfg толи tmp915.cfg, только не смотри на файлы с _ перед именем» - вещаешь ты хриплым голосом в телефон

subwoofer ★★★★★ ()
Ответ на: комментарий от snaf

запрос «сверху» — это когда начальство просит фичи, соответственно запрос «снизу» — это инициативы на местах, с которыми идут к начальству.
исторически сложившиеся термины в иерархической структуре управления.
про «хайпанули» есть линк объясняющий что такое hype:
Кто пробовал server side rendering на VUE? (комментарий)

system-root ★★★ ()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от system-root

Мой косяк. Слово «запрос» прочитал как «вопрос». Спасибо за видос, выглядит интересным.

snaf ★★★★★ ()
Последнее исправление: snaf (всего исправлений: 1)
Ответ на: комментарий от subwoofer

не было такого. Все изменения nginx успешно автоматически пушатся в git репу

snaf ★★★★★ ()
Ответ на: комментарий от snaf

Эта автоматизации работает как документация в том числе. Что вообще особенно критично для сервисов которые правится раз в пол года.

Делай что умные люди говорят и мотай на ус.

alpha ★★★★★ ()
Ответ на: комментарий от early_britney_fun

Смогут нанять другого который воспроизведет.

С ansible инфру вообще можно на аутсорс отдавать. Поскольку для администрирования серваках не надо давать админский доступ во внутренние сети. Достаточно ревьюить и принимать патчи. Это громадный бонус по сравнению с админом по старинке, которого не уволить никак потому что он там царь и бог и назаводил себе бекдоров (см. erzent)

alpha ★★★★★ ()

Такие вещи как

  • пакеты,
  • конфиги,
  • права на файлы.

делай только через Ansible/etc, особенно если:

Есть приложение в конфиг которого было внесёно следующее изменение:

listen=127.0.0.1
изменён на
listen=0.0.0.0
Таких примеров десятки. Не вижу смысла для этого городить оркестрацию.

Это делается одноразово и быстро забывается. Относись к этому как к документации твоей проделанной работы. Т.е. в комментариях в файлах и в коммитах DVCS пиши: зачем ты это сделал и что читал.

Помни, что когда-то либо ты вернёшься к этой задаче, либо ты передашь свою работу другому человеку.

Есть задачи которые трудозатратно делать через Ansible/etc. Например, управление пользователями. Так, что думай как эти действия будут бэкапится.

Мы хотим быть уверенны что в случае потери сервера сможем воспроизвести всю инфраструктуру

Увы, не всегда текущая конфигурация в Ansible/etc описывает путь, как она была получена. Поэтому надо активней вести документацию и качественно описывать действия в DVCS.

В любом случае, это всё повышает твои скилы. А накопленная коллекция ролей, правил и т.п. рано или поздно будет ускорять твою работу по настройке.

AlexVR ★★★★★ ()
Ответ на: комментарий от alpha

Достаточно ревьюить и принимать патчи.

Вот тут поподробнее. Т.е. человек пишет плейбуку, не имея доступа совсем никуда, а значит и не тестируя это на конкретных системах? За него это тестирует кто-то более доверенный?

early_britney_fun ★★★★ ()
Последнее исправление: early_britney_fun (всего исправлений: 2)

Они во многом правы. Меня ansible спасал именно в ситуациях когда «срочно подними такой же сервер». Ситуаций может быть много: сервер не оплатили, а после оплаты не все включают мгновенно, или просто авария в ДЦ. Если серверов около 5, то никто не будет делать резерв для каждого.

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

Единственный минус, что нельзя смешивать конфигурирование через ansible с ручной правкой конфигов, что-то где-то по-любому забудится. Для этого в начале каждого конфига в темплейте ставлю

# {{ ansible_managed }}

чтобы случайно не менять его руками.

Так вот если срочно нужно поднять этот «такой же сервер», а там другая серсия ОС, то легко поломать всё простым копированием /etc. ansible применяет всё выборочно. И относится к этому как в бекапам: время от времени по плейбукам поднимать тестовый сервер в виртуалке и проверять или он работает и в актуальном состоянии

paganmind ()

А еще ansible управляется около 50 рабочих станций на Ubuntu. Так вот после 50 однотипных делать отдельную роль для 1 сервера кажется мега-оверкилом, но всё равно оно того стоит.

paganmind ()
Ответ на: комментарий от early_britney_fun

Если у тебя всё под ansible, то многое тестируется до выкатки на конкретную систему. На уровне vagrant или stage environment.

Кто-то доверенный должен быть конечно, но он работает как принимающая сторона. Дает финальный аппрув и выкатывает.

alpha ★★★★★ ()

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

VladimirMalyk ★★★★★ ()

Ну я вот тоже так думал, а потом выкинул нахрен генту с серверов, накатил Ansible'ом Alpine и действительно стало удобнее.

Это не отменяет того, что в ansible чудовищно убогий вывод (привет u'string'), кривой синтаксис (привет {{ item }}, который в зависимости от положения в строке может вызывать синтаксические ошибки, которые надо ковычками закрывать) и половина модулей написана утырками.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)

Все они правильно говорят, полное покрытие конфигурации заметно упрощает дальнейшее обслуживание.

local_root ()

Нужно делать так, как принято в команде. Я целиком за автоматизацию, как начал применять ansible, поначалу была эйфория «вон оно как всё просто теперь, всё заранее можно протестировать в вагранте, а потом выкатить на продакшн, и всё в git-е хранится!». А на деле - спустя некоторое время, мой энтузиазм приутих, потому что кому-нибудь другому из команды проще зайти и поменять пару строк в конфиге, чем лезть в эти ваши анзиблы.

Ничего плохого в этом нет, со временем - и мне надоело ради замены пары строк в конфиге на паре серверах лезть в роль и менять что-то там, проще и быстрее по ssh всё сделать. Тем более, специфика такая, что одинаковых серверов не так много - дольше пишешь роль, чем всё разворачиваешь. А ещё при обновлении ansible-а довольно часто ломаются модули, и КАЗАЛОСЬ БЫ оттестированная тобой роль падает в процессе применения. А ещё бывает, что написал и оттестировал роль для сервиса одной версии, затем сервис обновляется, и твоя роль уже неактуальна - а самое западло, что это ты можешь узнать только во время разворачивания роли, когда «сервер упал, нужно быстро поднять такой же!!», и ты сидишь и думашь - ковырять и обновлять ansible роль, теряя время и деньги, или по-быстрому всё сделать руками по официальной инструкции.

Как итог - многие базовые вещи накатываю анзиблом, а вся текучка и мелкий тюнинг - вручную.

pod ★★ ()
Ответ на: комментарий от paganmind

Это не документация. Точно так же как и исходный код это не документация к бинарнику.

snaf ★★★★★ ()
Ответ на: комментарий от snaf

Более-менее можно считать документацией последовательность действий, описанных в пределах одного ansible playbook. Потому-что, там более-менее понятно описывается вся последовательность, по модулям и аргументам модулей можно восстановить порядок действий. А вот когда всё разрастается на несколько ролей, ещё и с разными when и прочим - тогда это вообще ниразу не документация.

pod ★★ ()

О, кажется я знаю твоих хипстеров, хотя нет, они все такие. И да, они правы, я их поддержу.

peregrine ★★★★★ ()
Ответ на: комментарий от pod

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

и второму проще

и третьему

а потом никто не знает что происходит на серваке

Как итог - многие базовые вещи накатываю анзиблом, а вся текучка и мелкий тюнинг - вручную.

Я бы на твоем месте стеснялась такое в публичном доступе писать

alpha ★★★★★ ()
Ответ на: комментарий от pod

Плэйбук != документация.

Более-менее можно считать документацией последовательность действий

С таким размахом можно и исходный код прировнять к документации, там же тоже описывается последовательность действий для компилятора/интерпретатора.

snaf ★★★★★ ()
Ответ на: комментарий от snaf

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

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Откуда такая уверенность?

Может по тому что вероятность крайне мала?

snaf ★★★★★ ()
Ответ на: комментарий от alpha

и второму проще ... а потом никто не знает что происходит на серваке

У вас сервак - проходной двор? Все в команде, кто администрирует тот или иной сервис, видит его конфиг и представляет, что там происходит.

Я бы на твоем месте стеснялась такое в публичном доступе писать

Вот и не пишите. Конечно, если у вас задача - поднять 500 совершенно одинаковых нод, то это просто и нужно автоматизировать, чтобы каждый раз руками не лезть. Но бывают и другие задачи, и КАЖДЫЙ индивидуальный случай описывать в отдельной роли - времени не хватит.

pod ★★ ()
Ответ на: комментарий от snaf

Ну вот, сам признал что такие требования стандартная практика.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

кажется я знаю твоих хипстеров
Ну вот, сам признал

Стесняюсь спросить, откуда вы черпаете свои мысли?

snaf ★★★★★ ()
Ответ на: комментарий от snaf

плейбук — это возможность формально описать то, что ты делаешь руками. в противном случае конфиг либо у тебя в голове, либо кое-как неофрмально описан словами в традиционной документации.

VladimirMalyk ★★★★★ ()
Ответ на: комментарий от pod

КАЖДЫЙ индивидуальный случай описывать в отдельной роли - времени не хватит

У тебя есть выбор: описывать каждый случай текстом в документации или описывать его в ansible. И при таком раскладе ansible сильно дешевле по времени.

При этом варианта «не описывать вообще» у приличных админов нет.

С ansible/puppet/salt/whatever действительно есть проблема: когда люди слишком сильно увлекаются принципом infrastructure as a code и начинают там реально программировать. Тогда действительно, правка одной строки конфига на одном серваке превращается в эпопею, потому что очень трудно отследить сколько ещё ролей и серваков затронет это изменение, тестирование становится проблемой и т.д. и т.п.

Поэтому в configuration management нельзя увлекаться принципами code reuse, и очень часто лучше выбрать понятный copy-paste вместо сложной абстракции.

Если же ansible playbook использовать не как фреймворк для программирования, а как аннотированный bash-скрипт, то есть максимально self-contained независимые роли - то он становится очень быстрым, самодокументируемым и удобным инструментом, и абсолютно не важно сколько нод у тебя в итоге.

alpha ★★★★★ ()
Ответ на: комментарий от snaf

Ты жалуешься в ОП посте на какие-то требования, считая их необоснованными. Значит ты считаешь людей, которые их выдвинули мягко говоря странными и чудными (а чудаков с одинаковыми чудачествами не так уж и много). Я утверждаю, что знаю таких «чудных» (прямо слово в слово, как у тебя в посте требования, правда чуть больше измененных конфигов) людей, ты утверждаешь, что вероятность этого крайне мала. Вывод - ты понимаешь, что подобные требования не редкость, в противном случае вероятность была бы очень велика.

Где ошибка?

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)

Дык, они правы. Погугли «фактор автобуса». Мне конечно понятно, что благодаря ручным правкам ты будешь незаменимым, и это правильно. Но вообще они 100% правы.

bitfroster ★★ ()
Ответ на: комментарий от alpha

Да, примерно эти же мысли я для себя и определил. Тут нельзя бросаться в крайности и сильно переусложнять роли\плейбуки.

При этом варианта «не описывать вообще» у приличных админов нет.

Например, какой-нибудь сервис, у которого надо всего лишь изменить listen/bind адрес относительно стандартного конфига, роли ansible нет, времени писать роль, сервис хотят видеть рабочим уже «вчера». Приличному админу даже в документацию ходить не надо, чтобы такое сделать.

pod ★★ ()

С одной стороны я могу не парится, т.к. всё равно у меня оплата почасовая, но с другой стороны напрегает разумность данной задачи.

Дело не в умении, не в желании, и вообще ни в чём. Дело в самом пришивании подворотничка.

А если серьезно, тебе уже объяснили, почему требования заказчика имеют смысл. Это у тебя почасовая оплата на которую ты можешь забить болт и уйти в запой/умереть/жениться, а у них проект (поди еще и стартап), им нужна стабильность, предсказуемость и чтобы следующий админ в случае чего мог разгрести то, что ты делал, а не тупить в скрипты и не городить всю инфраструктуру с нуля.

Раньше бы ты вообще каждый чих записывал в бумажку с датой, временем, версиями затронутых сервисов и сдавал под роспись начальству.

Neurotizer ()

Когда стоит и не стоит использовать ansible ( и прочие оркестраторы ) ?

на локалхосте с youtube и одноклассниками.

Что вы делаете когда вам дают неразумные задачи?

Я их ставлю.

И как вы решаете подобные вопросы?

Увольняю таких админов, как ты.

У нас все, абсолютно все, изменения проходят через automation engine, ибо ручками гимор, серверов много, да и запуск новых/перепровижонинг серверов происходит быстрее, вычищать/создавать пользователя с 20 серверов в маленьком стартапе ручками, с его любимым shell , настройками и паролем тот ещё гимор. уж не представляю как управлять зависимостями пакетов для 25 микросервисов, компоновать их по серверам вручную, а уж правила firewall для каждого или захотел поднять ещё один worker или webserver, даже страшно подумать. А теперь добавить staging и test environments, и без автоматизации всё превращается в АДЪ. И можешь не говорить про то, что вам не нужно, вам нужно, просто с тобой, в роли админа, это невозможно.

ksim ()
Ответ на: комментарий от ksim

А теперь добавить staging и test environments, и без автоматизации всё превращается в АДЪ

Staging/tesging уже как бы есть и в другом нету необходимости.

И можешь не говорить про то, что вам не нужно, вам нужно

Я нигде не указывал что автоматизация не нужна и это отстой.Так же я не говорил что мы её не используем. Я выступал против автоматизации слишком очевидных и мелких вещей.

Я негодую как мимо проходящий человек отлично знает что нужно проекту а что нет.

Раз вы уже указали «вам нужно», то я готов выслушать продолжение мысли.

вычищать/создавать пользователя с 20 серверов в маленьком стартапе ручками
настройками и паролем тот ещё гимор

В моём случае серверов меньше и пароли отсутствуют. Так же планируется SSO.

вам нужно, просто с тобой, в роли админа, это невозможно.

Вы обо мне совершено ничего не знаете, хотя это вам не мешает делать таких громких заявлений.

snaf ★★★★★ ()

Задай им простой вопрос:
Ansible ещё не подразумевает, что все всё будут делают правильно.
Ansible ещё не подразумевает, что всё будет работать когда даже тогда, когда все начнут всё делать правильно.
Ansible не формирует автоматически дерева поиска решения вопросов в голове пользователя.
Автоматизация вещь хорошая, и городить её никогда не вредно, но это срабатывет, когда оператор всё делает правильно.

TomBOY ()
Ответ на: комментарий от pod

Приличному админу даже в документацию ходить не надо, чтобы такое сделать.

Документация пишется не для того чтобы сделать. А для того чтобы знать что было сделано.

alpha ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.