LINUX.ORG.RU

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

 , , , ,


1

3

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

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

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

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

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

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

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

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

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

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

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

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

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

★★★★★

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

Для продакшена, когда нужно длительно сохранять настройки чего-либо, и автоматизации любой повторяющейся рутины, в том числе развёртывания точной копии продакшена для тестирования, CI и т.д.

Рецепты для оркестраторов служат хорошей документацией по проекту (но не заменяют её полностью, а дополняют).

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

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

Задаю себе вопрос «а достаточно ли я компетентен в данной области?». Пытаюсь обсудить, почитать в интернете best practices, посмотреть презентации от опытных чуваков, которые не то что собаку, а целого медведя съели на этом.

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

Отказался от самописных скриптов и тщательного документирования настроек проектов в пользу написания рецептов для оркестрации. Документация теперь носит декларативный характер, а не императивный.

anonymous00 ★★ ()

Мы хотим быть уверенны ... Это нам поможет

Они правы.

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

Тем более.

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

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

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

Скриптами устраняем оверхед, и остаёмся с одними преимуществами.

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

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

Бить в морду.

и мне надоело ради замены пары строк в конфиге на паре серверах лезть в роль и менять что-то там, проще и быстрее по ssh всё сделать.

Проще для лентяя, быстрее - навряд ли.

А ещё при обновлении ansible-а довольно часто ломаются модули, и КАЗАЛОСЬ БЫ оттестированная тобой роль падает в процессе применения.

Это жизнь. И касается всех новоиспечённых технологий. Но никто не мешает оставаться на более старой версии Ansible/etc.

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

Сравнить playbook+roles с «официальной инструкцией» получается быстрее.

Тем более, специфика такая, что одинаковых серверов не так много - дольше пишешь роль, чем всё разворачиваешь.

А может стоит подумать почему у тебя «дольше пишешь роль». При зоопарке держать в голове что, где, да как ещё сложнее.

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

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

то есть изменение конфигов/зависимостей, делается по разному на разных env? это говорит об уровне тестирование энвайронментов, а уж «ой, а на проде это обновить забыли, и всё сломалось» наверное сквозит в проекте.

Я выступал против автоматизации слишком очевидных и мелких вещей.

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

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

Опыт не пропить

В моём случае серверов меньше

Изначально мертвый проект? нет перспектив роста? Пичаль. Думаешь мы начинали с такого количества?

и пароли отсутствуют.

с каждым пользователем идёт минимум ключ и пароль, для повышения привилегий. даже на 3 сервера такое копировать достанет, уж не говоря про разные окружения. А уж если новый сервак и на нём надо всех пользователей создать....

Так же планируется SSO.

В ssh и для sudo?

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

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

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

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

за такое хочется вообще палками забивать до потери дыхания

SevikL ★★★★ ()

хз как там в Ansible, а в шефе перечисленный софт уже имеет хренову кучу темплейтов конфига

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

Бить в морду.

Простите, но я знаю этих людей, очень грамотные с огромнейшим багажом знаний люди. Они не заслужили такого обращения к себе только из-за того, что администрируют всё «классически». У нас есть желание и план перейти на configuration management, но нужно время.

Проще для лентяя, быстрее - навряд ли.

Поделитесь опытом. К примеру, есть ситуация - 3 прокси-сервера с разными конфигами acl на каждом.

Понятное дело, должны быть роли по базовой настройке сервера, роль с установкой того-же сквида и первоначальной его настройкой. Но потом то что делать? Где и как хранить индивидуальные конфиги сквида для каждого из серверов?

Можно хранить рядом с ролью в files/templates. Если нужно изменить одну acl - сначала изменяешь конфиг в роли, только потом выкатываешь изменение.

Удобнее держать эти конфиги в git прямо на сервере - изменил, зарелоадил сквид, посмотрел что всё хорошо, закоммитил изменения (по надобности, запушил в приватный удалённый гит-репозиторий). Дополнительно, тут же имеешь историю правок конфигов. (Это к вопросу автора темы «На этот раз от меня требуют чтобы КАЖДЫЙ конфиг изменялся через ansible и написать сценарии для каждого изменённого конфига.»). Этот вариант проще и быстрее предыдущего, как мне кажется.

А может стоит подумать почему у тебя «дольше пишешь роль».

Во-первых, yaml не самый человекочитаемый, у него есть нюансы. Во-вторых, модулей много, все опции сразу так не запомнить, с документацией сверяться ходить надо.

При зоопарке держать в голове что, где, да как ещё сложнее.

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

Есть разные сервисы, я в основном говорю о классических - которые один раз настроил и забыл. А вы, похоже, - о разного рода микросервисах, у которых множество компонент, все связаны, все требуют определённых последовательностей действий при обслуживании, и уже без configuration management сложно обойтись.

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

наверное сквозит в проекте.

нет не сквозит

... это не мелочи

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

В ssh и для sudo?

да. А что слабо?

Для начала ты завязал администрирование на себя

А вот и нифига. Документация в процесе и всё работает стабильно. Костыли в стиле erzent отсутсвуют. Про автобус слышал и проект не умрёт от этого.

из-за сдохшего диска

Он виртуальный.

целая эпопея и катастрофа.

Бывало восстанавливались. Брат жив. Но мне конечно не сравнится в вашими выдумаными проблемами.

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

через годы потребовали что-то изменить - идёшь и читаешь конфиг.

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

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

alpha ★★★★★ ()

В нашем проекте автоматизированные функциональные тесты тестируют всё приложение целиком, т.е. начиная от скриптов для провижонинга нод и заканичвая кодом приложения - в каждой Jenkins джобе поднимается кучка вм-ок, на них накатываются роли, запускаются тесты приложения, и в конце выносится вердикт - PASS/FAIL.

Каждый пулл реквест (коммит) в репозитарий перед тем как он будет вмержен (независимо от итогов ревью) прогоняется через такой тест, таким образом отлавливая ошибки и в скриптах автоматизации и в коде приложения.

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

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

И эту инфраструктуру трудно сделать без автоматизации всего.

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

Удобнее держать эти конфиги в git прямо на сервере - изменил, зарелоадил сквид, посмотрел что всё хорошо, закоммитил изменения (по надобности, запушил в приватный удалённый гит-репозиторий). Дополнительно, тут же имеешь историю правок конфигов. (Это к вопросу автора темы «На этот раз от меня требуют чтобы КАЖДЫЙ конфиг изменялся через ansible и написать сценарии для каждого изменённого конфига.»). Этот вариант проще и быстрее предыдущего, как мне кажется.

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

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

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

нет не сквозит

Ватой заткнули?

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

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

да. А что слабо?

нет, глупо.

А вот и нифига. Документация в процесе и всё работает стабильно. Костыли в стиле erzent отсутсвуют. Про автобус слышал и проект не умрёт от этого.

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

Он виртуальный.

удачи

Бывало восстанавливались. Брат жив. Но мне конечно не сравнится в вашими выдумаными проблемами.

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

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

Поделитесь опытом. К примеру, есть ситуация - 3 прокси-сервера с разными конфигами acl на каждом.

Начнём с «squid-cache wiki: Config Includes».

Это даёт возможность добавлять файлы в /etc/squid/conf.d/ так как нам хочется: указав параметры для собственной роли настройки Squid или создавая отдельные роли для описания требуемого действия. Это на много более гибкий подход.

Есть разные сервисы, я в основном говорю о классических - которые один раз настроил и забыл.

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

Ansible - это хороший помощник для человека с головой, а не волшебная палочка.

Удобнее держать эти конфиги в git прямо на сервере - изменил, зарелоадил сквид, посмотрел что всё хорошо, закоммитил изменения (по надобности, запушил в приватный удалённый гит-репозиторий).

А с Ansible тоже самое. Никто не отменяет ситуации, когда приходится править конфиги прямо на сервере, подбирая нужный параметр. Главное что бы в результате эти действия были зафиксированы в Ansible. Но --limit, --tags и хороший редактор/IDE в большинстве случаев делают это быстрее. Не забываем что минимально надо: исправить конфиг, перезапустить сервис. Когда-то таких действий больше. И все эти действия Ansible делает сам.

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

Ватой заткнули?

мамкой твоей

нет, глупо.

ну да конечно. Теперь сам сравни, создание пользователя на каждой ноде и правка sudo vs создание пользователя в sso.

удачи

спасибо

уже заднюю давать начал, прочитай своё изначальное сообщение

И что? там не указано что не используется автоматизация.

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

мамкой твоей

Опять врёшь, Будь там моя мамка, тебя бы там изначально не было, таких «adminов» она не держит.

ну да конечно. Теперь сам сравни, создание пользователя на каждой ноде и правка sudo vs создание пользователя в sso.

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

И что? там не указано что не используется автоматизация.

Ты сам то читал, что написал? или чукча? а именно цитирую:

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

<тут огромный список ключевых компонентов>

Если у «админа» не автоматизированна установка пакетов, то ничего не автоматизированно, так как автоматизиция установки пакетов в любом движке проще, чем даже ручками их ставить.

Блин, да признай уже, что обосрался, ну криворукий ты, ну делаешь всё через жопу, все через это проходили, и посвяти воскресенье изучению ansible.

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