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 победил всех своей простотой входа, но повторюсь еще раз, для сложных вещей он становится слишком громоздким.
А можно использовать софт с которым онбординг не требует отдельной страницы - https://github.com/devopspass/devopspass/
Если мы конечно про технических специалистов :)
Вы сравниваете кого попало со здоровыми отношениями. Такое
Это МДП, алкоголь это действительно побочка.
Таблетки нужно не пропускать. Но все это страшно
Забыли Варлордов, Периметр и Казаки.
Айтишники всегда говорили на Рунглише, вас с филологического перевели?
Что то вы интересное рассуждаете, но Вам формата не хватает.
Могли бы вы немного расширить и «для тупых», а то я себя на гешефте квантовых физиков почувствовал…
В 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 победил всех своей простотой входа, но повторюсь еще раз, для сложных вещей он становится слишком громоздким.