Galaxy это dependency manager и он очень хреновый.
Еденица исполнения может и плейбук, а вот еденица разработки - роль. И ее действительно очень тяжело разрабатывать отдельно в Ansible. Коллекции конечно есть, но это тоже умножение сущностей, из-за странностей архитектуры. Получается что все роли организации должны быть в одной коллекции чтобы их можно было использовать без заморочек, но тогда все должны использовать latest роли, а так в жизни не получается.
Вы ярый фанат Ansible, это я понял ;) Попробуйте Chef + Test Kitchen + InSpec, хотя бы для саморазвития и расширения горизонтов, если что спрашивайте в PM.
Мне не нравится что Ansible плодит сущности для того что называется ресурс (без привязки к СМ).
Ansible изначально был "SSH на стероидах", а уже потом стали изобретать архитектуру, отсюда все эти сложности: plugin, filter, lookup, action, module (хотя это все ресурс, еденица конфигурирования).
Роли до сих пор не оформились как самостоятельная еденица, как библиотека в этом нашем программировании, которую можно разрабатывать независимо от других библиотек. FQCN даже в документации используются не везде, и т.д.
При чем тут плейбук, еденица разработки - роль, вы же не плейбуки тестировать будете. P.S. Как вы код вставляете? У меня в редактировании все ок, в конечном результате вот такое вот.
ansible-galaxy не тянет dependency дальше первого уровня, самому нужно подбирать для каждой роли, что капец как неудобно если ты разрабатываешь большой проект.
Ну что же вы так, YAML единственное тем и удобен, что он не JSON, на этом его удобство "всё". Это действительно язык описания структуры, поэтому он хорошо подходит для описания состояния системы...пока вам не нужна логика. Как только нужна логика, начинается веселуха со всякими ужасами типа TOML (Helm) или Jinja (Ansible, SaltStack). Для Jinja получается что языка три, YAML, Python, Jinja.
Вот пару примеров того что мне не нравится в Ansible:
Сможете с ходу ответить в чем разница между Action и Module в Ansible и зачем их делить?
Перепишите на Ansible:
services = ['jboss1', 'jboss2', 'jboss3'] services.each do |svc| template "/etc/jboss/conf/#{svc}.conf" do source "#{svc}.conf.erb" notify :reload, "service[#{svc}]", :delayed end service svc do action :nothing notify :reload, 'service[nginx]', :delayed end end
# Task with '*', restart nginx now, without reloading JBosses before run end template '/etc/nginx/nging.conf' do source 'nginx.conf.erb' notify :restart, 'service[nginx]', :immidiately end
describe package('clamav') do
it { should be_installed }
its('version') { should eq '0.98.7' }
end
describe service('clamd') do
it { should be_enabled }
it { should be_installed }
it { should be_latest }
it { should be_running }
end
В том-то и дело что это любой другой язык, но не YAML, т.е. я не совсем понимаю зачем нужен YAML в ролях, если что-то сложнее install, restart нужно писать на Python. Плюс Jinja, это третий DSL, это и не Python и не YAML, после ERubis в Chef, где все, от метадаты в кукбуке до темплейтов в конфигах это Ruby код, это все очень напрягает.
Не поймите меня неправильно, я в равной мере владею и Ansible и Chef и мое недовольство не идет от незнания технических деталей, исключительно из опыта применения обеих CM в больших проектах.
Ansible победил всех своей простотой входа, но повторюсь еще раз, для сложных вещей он становится слишком громоздким.
У меня есть опыт написания автоматизации на Chef для огромного monolith приложения, 12 разработчиков на Chef, ~290k строк кода. На Ansible это был бы ужас, особенно если учесть что дело было почти 7 лет назад, когда у Ansible даже Ansible-lint не было, не то что Molecule.
В плане IaaC, я имею ввиду ВСЮ инфраструктуру, не считая деплоймента приложения, от промпта в bash до настройки Application Server (Tomcat/JBoss/LAMP).
Больше всего бести, что нельзя в dependency, когда твоя роль:
Тут скорее пробема в том, что Ansible использует Push-model, и там где я могу вызвать нативный метод Ruby, приходится иногда писать много Python обвязок для Shell.
По поводу сложных вещей, даже просто (не)запускать какой-то ресурс в зависимости от того есть файл или нет, нужно писать много кода.
При написании собственных модулей в Ansible мне не хватает Chef`овского LWRP, когда в коде ресурса ты используешь тот же код что и в рецепте. В Ansible ты пишешь на дргугом языке - Python.
Ну и в целом я не фанат Jinja программирования, что в Ansible что в SaltStack.
Chef уже давно устоялся, что то новое про него и не напишешь. Статьи 2012 скорее всего актуальны сегодня и будут работать, в этом его фишка.
Ansible все еще сырой в плане IaaC, Molecule конечно шаг вперёд по сравнению с тем же Test Kitchen, но местами недопилен. Написание своих модулей после Chef кажется странным, сильно много шела.
Для действительно сложного проекта всегда предпочитайте Chef, порог входа выше, но сложные вещи на нем делаются проще чем в Ansible.
Айтишники всегда говорили на Рунглише, вас с филологического перевели?
Что то вы интересное рассуждаете, но Вам формата не хватает.
Могли бы вы немного расширить и «для тупых», а то я себя на гешефте квантовых физиков почувствовал…
В 2024 году Jenkins? Вы серьезно?!
В заголовке прекрасно все!
Ну Docker вряд ли в сыром виде кто то использует, хотя да, правильнее оркестрация.
Но, Kubernetes это точно не про инфраструктуру (IaaS) это платформа (PaaS) ;)
* я DevOps-зануда
Все бы хорошо, но однажды вы уволитесь и кто то придет на ваше место.
И вот это вот все ему нужно откуда-то взять (пул, клин и т.д.) и это хорошо если он имел опыт с spring boot а не с Django пришел фронтенд сапортить.
DevOps упрощает вход и выход, помимо прочего.
Мы с Вами друг-друга не понимаем :D
Galaxy это dependency manager и он очень хреновый.
Еденица исполнения может и плейбук, а вот еденица разработки - роль. И ее действительно очень тяжело разрабатывать отдельно в Ansible. Коллекции конечно есть, но это тоже умножение сущностей, из-за странностей архитектуры. Получается что все роли организации должны быть в одной коллекции чтобы их можно было использовать без заморочек, но тогда все должны использовать latest роли, а так в жизни не получается.
Вы ярый фанат Ansible, это я понял ;) Попробуйте Chef + Test Kitchen + InSpec, хотя бы для саморазвития и расширения горизонтов, если что спрашивайте в PM.
Мне не нравится что Ansible плодит сущности для того что называется ресурс (без привязки к СМ).
Ansible изначально был "SSH на стероидах", а уже потом стали изобретать архитектуру, отсюда все эти сложности: plugin, filter, lookup, action, module (хотя это все ресурс, еденица конфигурирования).
Роли до сих пор не оформились как самостоятельная еденица, как библиотека в этом нашем программировании, которую можно разрабатывать независимо от других библиотек. FQCN даже в документации используются не везде, и т.д.
В Chef и Puppet это все было в ~2009 году.
Это штатные фреймворки для тестирования. Не будете же вы роль писать без тестов?
При чем тут плейбук, еденица разработки - роль, вы же не плейбуки тестировать будете.
P.S. Как вы код вставляете? У меня в редактировании все ок, в конечном результате вот такое вот.
handlers, будет в другом файле если это роль ;)
Заставьте flush_handlers не перезапускать nginx :D
Chef Supermarket был уже старым когда Ansible Galaxy еще не было)))
Chef и Puppet програли массового пользователя, технологически они взрослее Ansible.
ansible-galaxy не тянет dependency дальше первого уровня, самому нужно подбирать для каждой роли, что капец как неудобно если ты разрабатываешь большой проект.
Еще раз, мне нравится Chef больше но я прекрасно понимаю что массового пользователя он програл )))
Ну что же вы так, YAML единственное тем и удобен, что он не JSON, на этом его удобство "всё". Это действительно язык описания структуры, поэтому он хорошо подходит для описания состояния системы...пока вам не нужна логика. Как только нужна логика, начинается веселуха со всякими ужасами типа TOML (Helm) или Jinja (Ansible, SaltStack). Для Jinja получается что языка три, YAML, Python, Jinja.
В Ansible, сколько нибудь сложный проект превращается вот в это - https://github.com/splunk/splunk-ansible/blob/develop/roles/splunk_cluster_master/tasks/main.yml, код не мой, но мне приходилось его адаптировать, лучше чем он есть его и не напишешь.
Вот пару примеров того что мне не нравится в Ansible:
Сможете с ходу ответить в чем разница между Action и Module в Ansible и зачем их делить?
Перепишите на Ansible:
services = ['jboss1', 'jboss2', 'jboss3']
services.each do |svc|
template "/etc/jboss/conf/#{svc}.conf" do
source "#{svc}.conf.erb"
notify :reload, "service[#{svc}]", :delayed
end
service svc do
action :nothing
notify :reload, 'service[nginx]', :delayed
end
end
# Task with '*', restart nginx now, without reloading JBosses before run end
template '/etc/nginx/nging.conf' do
source 'nginx.conf.erb'
notify :restart, 'service[nginx]', :immidiately
end
service 'nginx'
# Some other actions
# ...
Сравните код для InSpec и TestInfra:
def test_nginx_is_installed(host): nginx = host.package("nginx") assert nginx.is_installed assert nginx.version.startswith("1.2") def test_nginx_running_and_enabled(host): nginx = host.service("nginx") assert nginx.is_running assert nginx.is_enabled
InSpec:
describe package('clamav') do it { should be_installed } its('version') { should eq '0.98.7' } end describe service('clamd') do it { should be_enabled } it { should be_installed } it { should be_latest } it { should be_running } endВ том-то и дело что это любой другой язык, но не YAML, т.е. я не совсем понимаю зачем нужен YAML в ролях, если что-то сложнее install, restart нужно писать на Python. Плюс Jinja, это третий DSL, это и не Python и не YAML, после ERubis в Chef, где все, от метадаты в кукбуке до темплейтов в конфигах это Ruby код, это все очень напрягает.
Не поймите меня неправильно, я в равной мере владею и Ansible и Chef и мое недовольство не идет от незнания технических деталей, исключительно из опыта применения обеих CM в больших проектах.
Ansible победил всех своей простотой входа, но повторюсь еще раз, для сложных вещей он становится слишком громоздким.
Not always, I dont care about thrird level dependencies when setting up infra for app ;)
У меня есть опыт написания автоматизации на Chef для огромного monolith приложения, 12 разработчиков на Chef, ~290k строк кода. На Ansible это был бы ужас, особенно если учесть что дело было почти 7 лет назад, когда у Ansible даже Ansible-lint не было, не то что Molecule.
В плане IaaC, я имею ввиду ВСЮ инфраструктуру, не считая деплоймента приложения, от промпта в bash до настройки Application Server (Tomcat/JBoss/LAMP).
Больше всего бести, что нельзя в dependency, когда твоя роль:
AppRole -- depends --> base_linux_role -- depends --> sudo_role
sudo_role нужно ЯВНО указать в requirements.yml для AppRole, а если таких dependency 60?
Это был не я :)
Тут скорее пробема в том, что Ansible использует Push-model, и там где я могу вызвать нативный метод Ruby, приходится иногда писать много Python обвязок для Shell.
По поводу сложных вещей, даже просто (не)запускать какой-то ресурс в зависимости от того есть файл или нет, нужно писать много кода.
При написании собственных модулей в Ansible мне не хватает Chef`овского LWRP, когда в коде ресурса ты используешь тот же код что и в рецепте. В Ansible ты пишешь на дргугом языке - Python.
Ну и в целом я не фанат Jinja программирования, что в Ansible что в SaltStack.
Chef уже давно устоялся, что то новое про него и не напишешь. Статьи 2012 скорее всего актуальны сегодня и будут работать, в этом его фишка.
Ansible все еще сырой в плане IaaC, Molecule конечно шаг вперёд по сравнению с тем же Test Kitchen, но местами недопилен. Написание своих модулей после Chef кажется странным, сильно много шела.
Для действительно сложного проекта всегда предпочитайте Chef, порог входа выше, но сложные вещи на нем делаются проще чем в Ansible.