Спасибо за статью. Можете поподробнее рассказать как устроен ваш репозиторий на aptly? Полное зеркало официального + снэпшоты? Делаете ли deb пакеты со своими разработками или собираете бинарь в докере? Фиксируете ли версии того, что сами пишите в Dockerfile? Кто дергает API? curl в недрах CI или что-то другое?
Может быть тут проблема именно в терминах. Например есть буддизм и есть буддисты — люди, которые буддизм исповедуют. За счет наличия в языке двух слов мы не путаем религию и ее адептов. Другой пример — scrum master, никто же не рассказывает, что scrum master это не человек, так как ценности скрама должным разделять все участники команды. А вот devops, это обе вещи сразу, и набор практик и человек, который призван способствовать их внедрению. О том, что мы в каждом конкретном случае имеем в виду собеседник должен догадываться по контексту и это иногда приводит к недопониманию, но это не означает, что нельзя нанять человека, который принесет в вашу команду/компанию ценности и практики devops.
У меня совершенно противоположный взгляд на вещи. Я пришел в devops из разработчиков, так как понимал, что чем больше я понимаю про окружение в котором работает моя программа, тем лучше я смогу ее спроектировать. Ну и еще, если честно, было безумно интересно поработать с модными облаками. Так вот, там где вы видите проблему — на devops вешают много пролем, я вижу возможность — ты именно тот человек, который может построить для разработчиков ту инфраструктуру о которой сам мечтал когда был маленьким программистом. Если ты тот самый человек к которому придут в случае сбоя в инфраструктуре, то ты по определению обладаешь определенным весом в глазах начальства, они обычно не глупые люди понимают, что не хотят сами чинить сервера. Так что можно действительно сделать что-то полезное для разработки являясь техническим парнем (или девушкой) к которому иногда прислушиваются.
Да, возможно это code smell, но кажется это единственное, что решает проблему. То, что вы предложили на мой взгляд не решает и очень трудозатратно в поддержке, но в любом случае спасибо за интересную дискуссию.
Поясню, я хотел бы иметь указанную выше структуру в каждой из папок:
* /srv/test, при этом чтобы в темплейтах поле user имедо значение test, а password 'testpass';
* /srv/staging c user=staging и password='stagingPassword';
* /srv/prod с user=admin, password='prodP@sswo0rd'.
При этом мне не требуется каждый раз писать отдельный комментарий для файла foo.conf, вместо этого мне бы хотелось иметь возможность добавить файл newfoo.com один раз, но чтобы он появился правильно заполненным в каждой из папок (test, staging, prod), и возможность добавить новое окружение (например preprod) со своими параметрами.
Я верю, что ansible не язык программирования. Теперь мне нужно найти разумное решение для задачи, когда нужно создать несколько директорий %main_dir% с контентом: %main_dir%/
------ b/foo.conf
------ c/bar.conf
------- /foobar.conf
где каждый файл конфига генерируется со своими параметрами для каждой из %main_dir%.
Формально это данные, но они настолько сильно сильно влияют на ход выполнения вашей программы, что думать о последствиях изменений в них так же трудно как про код. Плюс ко всему у вас появляется еще весь комплекс проблем связанный с актуальностью и валидностью данных в вашем инвентори.
А что делать, если надо сделать 100 почти одинаковых наборов действий, например создать десяток каталогов и заполнить их файлами из темплейтов с разными параметрами?
Да, ансибл не язык программирования, тут я с вами полностью согласен.
Вот есть задача — сделать несколько однотипных вещей отличающихся отдельными элементами, например десяток конфигов в conf.d или скажем несколько папочек со стандартной структурой. Есть несколько вариантов:
1) написать десять почти одинаковых блоков — прямое дублирование, большой объем глупой ручной работы и ошибок в случае последующих изменений
2) include_role — получим все проблемы с приоритетами
3) модуль — сложно, долго и не очень понятно зачем тогда ансибл нужен, если все равно программируем
У нас вместо монорепы много ролей, но пока не договорились бывало, что запуск вида `-e target_ip=...` неожиданно затрагивал более одной роли. -С и --diff конечно спасают, но люди склонны совершать ошибки.
Иногда не хватает возможности запустить роль A из ролей B и C с разными параметрами. Это позволило бы уменьшить дублирование, да и вообще сделало бы ансибл более интуитивным для людей привыкших программировать.
Мы в команде стараемся себе не позволять такого экстрима с инклудами как вы описываете, просто в силу того, что сложно. Но еще мы например пришли к ряду простых соглашений, которые немного упрощают жизнь, например, что все переменные ролей имеют префикс с названием роли или что мы используем `defaults` и не используем `vars` (в силу приоритетов). Хочется узнать есть ли у вас что-то похожее.
Статья прям про Боль. Скажите, а будет ли статья про best practices, использование которых позволило бы снизить боль до разумных пределов? Например соглашения об именовании, договоренностей о том где объявлять переменные или скажем стандартных приемов, позволяющих выяснить объявлена переменная или нет.
Конечно, если сравнивать скажем скорость вызова метода в сишечке и в питоне, то первая выиграет по скорости. Тем не менее быстродействие прграмм зависит от очень многих факторов, а языки отличаются не только по скороти выполнения программ, но и по скорости их написания.
Тем не менее заголовок не врет: "Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью", так как ее автор скорее всего специалист в области перфоманса, нежели программист.
маленькимпрограммистом. Если ты тот самый человек к которому придут в случае сбоя в инфраструктуре, то ты по определению обладаешь определенным весом в глазах начальства, они обычно не глупые люди понимают, что не хотят сами чинить сервера. Так что можно действительно сделать что-то полезное для разработки являясь техническим парнем (или девушкой) к которому иногда прислушиваются.* /srv/test, при этом чтобы в темплейтах поле user имедо значение test, а password 'testpass';
* /srv/staging c user=staging и password='stagingPassword';
* /srv/prod с user=admin, password='prodP@sswo0rd'.
При этом мне не требуется каждый раз писать отдельный комментарий для файла foo.conf, вместо этого мне бы хотелось иметь возможность добавить файл newfoo.com один раз, но чтобы он появился правильно заполненным в каждой из папок (test, staging, prod), и возможность добавить новое окружение (например preprod) со своими параметрами.
%main_dir%/
------ b/foo.conf
------ c/bar.conf
------- /foobar.conf
где каждый файл конфига генерируется со своими параметрами для каждой из %main_dir%.
Вот есть задача — сделать несколько однотипных вещей отличающихся отдельными элементами, например десяток конфигов в conf.d или скажем несколько папочек со стандартной структурой. Есть несколько вариантов:
1) написать десять почти одинаковых блоков — прямое дублирование, большой объем глупой ручной работы и ошибок в случае последующих изменений
2) include_role — получим все проблемы с приоритетами
3) модуль — сложно, долго и не очень понятно зачем тогда ансибл нужен, если все равно программируем
как правильнее всего решать задачу?
Конечно, если сравнивать скажем скорость вызова метода в сишечке и в питоне, то первая выиграет по скорости. Тем не менее быстродействие прграмм зависит от очень многих факторов, а языки отличаются не только по скороти выполнения программ, но и по скорости их написания.
Тем не менее заголовок не врет: "Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью", так как ее автор скорее всего специалист в области перфоманса, нежели программист.