Comments 32
питона (который так же установлен на любой Linux системе из коробки)
Далеко не в любой, и это делает всю затею сомнительной. Странно, что в зависимостях не Ruby, а именно Python, учитывая Вагрантоориентированность.
Python используется только в модуле read для парсинга INI, JSON, Yaml и Java Properties файлов. Другие модули его не используют, так что зависимость опциональная.
Кроме того, если уж Python не установлен, то он всегда есть в стандартных репозиториях. Чего не скажешь о Ruby, который из коробки не установлен вообще, а в репозиториях часто лежит древняя версия, под которой половина новых пакетов уже не работает. Ну а, если очень хочется использовать Ruby, вы всегда можете прислать патч для модуля ext.
Кроме того, если уж Python не установлен, то он всегда есть в стандартных репозиториях. Чего не скажешь о Ruby, который из коробки не установлен вообще, а в репозиториях часто лежит древняя версия, под которой половина новых пакетов уже не работает. Ну а, если очень хочется использовать Ruby, вы всегда можете прислать патч для модуля ext.
Я-то как раз ни Ruby, ни Python, ни bash, если уж на то пошло, для такой сложной задачи как управление конфигурациями использовать совершенно не хочу и не использую. Просто обратил внимание на одно сомнительное предположение с вашей стороны и сомнительное архитектурное решение со стороны авторов bash booster.
О гуру, подскажи другие языки с таким же удобным синтаксисом, подходящим для написания деплой-скриптов.
Уже подсказывал. В процессе написания ещё пара «подсказок».
Дык, Python входит в LSB и должен быть в любом современном дистрибутиве в минимальной конфигурации. Я это принципиально для администрировании.
А кому, простите, должен?
$ sudo debootstrap --arch=amd64 testing $(pwd)/vm-tst1 http://ftp.jp.debian.org/debian/
[...]
$ sudo find vm-tst1 | grep -i python
vm-tst1/usr/share/gcc-4.9/python
vm-tst1/usr/share/gcc-4.9/python/libstdcxx
vm-tst1/usr/share/gcc-4.9/python/libstdcxx/v6
vm-tst1/usr/share/gcc-4.9/python/libstdcxx/v6/__init__.py
vm-tst1/usr/share/gcc-4.9/python/libstdcxx/v6/printers.py
vm-tst1/usr/share/gcc-4.9/python/libstdcxx/__init__.py
vm-tst1/usr/share/nano/python.nanorc
vm-tst1/usr/lib/python2.7
vm-tst1/usr/lib/python2.7/dist-packages
vm-tst1/usr/lib/python2.7/dist-packages/debconf.py
vm-tst1/usr/lib/python3
vm-tst1/usr/lib/python3/dist-packages
vm-tst1/usr/lib/python3/dist-packages/debconf.py
lxc например создает убунту конейнеры без него, приходится ансиблом в рамках развертывания вм в raw режиме его ставить, иначе тот же ансибл не работает
Неплохо бы в таких статьях показывать, чем выгодно отличается от того же упомянутого Chef?
То, что я прочитал в этой статье, как бы говлорит: ещё один велосипед, ни комьюнити, ни интеграции нормальной с Vagrant: создавать свой скрипт для провижина и тд.
То, что я прочитал в этой статье, как бы говлорит: ещё один велосипед, ни комьюнити, ни интеграции нормальной с Vagrant: создавать свой скрипт для провижина и тд.
От Chef выгодно отличается тем, что «я быстрей на баше напишу» становится еще быстрей.
Вообще мое субъективное мнение о Chef следующее: это крутая вещь, когда нужно централизованно развернуть парк серверов (8 и более) на том же Amazon. Но для управления парой-тройкой машин, его использование больше напрягает, чем помогает. Для этих целей этот велосипед и был изобретен. Я и мои коллеги успешно на нем ездим уже полгода и пока довольны.
Вообще мое субъективное мнение о Chef следующее: это крутая вещь, когда нужно централизованно развернуть парк серверов (8 и более) на том же Amazon. Но для управления парой-тройкой машин, его использование больше напрягает, чем помогает. Для этих целей этот велосипед и был изобретен. Я и мои коллеги успешно на нем ездим уже полгода и пока довольны.
Никогда не мог понять, что сложного в нем? Приведите пример чем он вас напрягает? Действительно интересно.
Опыт годичной давности и сугубо субъективный.
Во-первых, документация написана маркетологами в стиле «Chef умеет вот так, купите платный саппорт и мы сделаем вам хорошо». Я конечно разобрался, но осадок остался.
Во-вторых, для установки Chef-solo нужен Ruby. В то время в репозиторях Ubuntu 12.04 был Ruby 1.8.4. Chef на нем заводится отказался без внятных сообщений об ошибках. На установленном через RVM, Ruby 2.1 (или 2.0 не помню точно версию) он заработал, но периодически падал опять же без внятных сообщений. Опытным путем удалось его завести на Ruby 1.9.х. Этого конечно можно было бы избежать, если бы не первый пункт.
В-третьих, будь я рубистом, я бы наверное жутко тащился бы от кукбуков на Ruby, но к сожалению я не рубист. Поэтому там где декларативная магия переставала работать и нужно было написать немного императивного кода, меня немного напрягал весьма экзотический синтаксис Ruby. Но это, конечно, вкусовщина.
Если использовать Chef на Amazon OpsWorks, где все инструменты уже интегрированы и нужно просто подсунуть нужные кукбуки, то таких проблем не возникает. И лично у меня осталось хорошее впечатление от него. Но для одиночных образов в Vagrant у меня нет желания его использовать.
Еще следует оговориться, что я не администратор, а программист. И мой девопсовский опыт был получен в тот момент, когда я ждал нового проекта, а в соседней команде не хватало инженера по развертыванию. В моей повседневной работе Chef и другие «большие» SCM системы — явный перебор. Все что мне нужно — это настроить виртуалку в Vagrant и положить настройки в репозиторий с кодом, чтобы от остальной команды никогда не слышать: «Не знаю, у меня все работает». Если вас Chef полностью устраивает, значит Bash Booster просто не для ваших задач.
Во-первых, документация написана маркетологами в стиле «Chef умеет вот так, купите платный саппорт и мы сделаем вам хорошо». Я конечно разобрался, но осадок остался.
Во-вторых, для установки Chef-solo нужен Ruby. В то время в репозиторях Ubuntu 12.04 был Ruby 1.8.4. Chef на нем заводится отказался без внятных сообщений об ошибках. На установленном через RVM, Ruby 2.1 (или 2.0 не помню точно версию) он заработал, но периодически падал опять же без внятных сообщений. Опытным путем удалось его завести на Ruby 1.9.х. Этого конечно можно было бы избежать, если бы не первый пункт.
В-третьих, будь я рубистом, я бы наверное жутко тащился бы от кукбуков на Ruby, но к сожалению я не рубист. Поэтому там где декларативная магия переставала работать и нужно было написать немного императивного кода, меня немного напрягал весьма экзотический синтаксис Ruby. Но это, конечно, вкусовщина.
Если использовать Chef на Amazon OpsWorks, где все инструменты уже интегрированы и нужно просто подсунуть нужные кукбуки, то таких проблем не возникает. И лично у меня осталось хорошее впечатление от него. Но для одиночных образов в Vagrant у меня нет желания его использовать.
Еще следует оговориться, что я не администратор, а программист. И мой девопсовский опыт был получен в тот момент, когда я ждал нового проекта, а в соседней команде не хватало инженера по развертыванию. В моей повседневной работе Chef и другие «большие» SCM системы — явный перебор. Все что мне нужно — это настроить виртуалку в Vagrant и положить настройки в репозиторий с кодом, чтобы от остальной команды никогда не слышать: «Не знаю, у меня все работает». Если вас Chef полностью устраивает, значит Bash Booster просто не для ваших задач.
1. У Chef нормальная документация и всегда такой была: docs.chef.io/. Но если не знать где искать, на их сайте она немного неочевидно ищется.
2. Chef тащит весь свой руби с собой (да, это пара сотен мегабайт). Но если вы не пишете на руби и не используете RVM, проблем это никаких не создает (кроме занятого места на диске). Не используйте Chef с RVM и системным руби — это не поддерживается и если вы пытаетесь так делать, вы должны знать как все возможные проблемы исправить.
4. В Vagrant он подсовывается прямо из вагрантфайла: docs.vagrantup.com/v2/provisioning/chef_solo.html
Но вообще, если нужно что-то действительно легковесное, я бы лучше посоветовал Ansible. Он действительно простой и из зависимостей у него только Python.
2. Chef тащит весь свой руби с собой (да, это пара сотен мегабайт). Но если вы не пишете на руби и не используете RVM, проблем это никаких не создает (кроме занятого места на диске). Не используйте Chef с RVM и системным руби — это не поддерживается и если вы пытаетесь так делать, вы должны знать как все возможные проблемы исправить.
4. В Vagrant он подсовывается прямо из вагрантфайла: docs.vagrantup.com/v2/provisioning/chef_solo.html
Но вообще, если нужно что-то действительно легковесное, я бы лучше посоветовал Ansible. Он действительно простой и из зависимостей у него только Python.
1. У Chef нормальная документация и всегда такой была: docs.chef.io/. Но если не знать где искать, на их сайте она немного неочевидно ищется.
Ну не скажите, последние полтора-два года chef сообщество приложило чудовищные усилия что бы облегчить жизнь новичкам и улучшить документацию в частности.
Я с chef работаю года два-три всего, и все изменения, относящиеся к докам, которые я заметил — выпилили wiki, который устарел и сбивал с толку, и спрятали с главной страницы ссылку на доки куда-то вглубь. Конкретно эта страница как была, так и осталась, только на другой домен переехала.
Ну Омнибус сделали, конечно, за это им большое спасибо, но это не доки, про которые мы здесь говорим :-)
Ну Омнибус сделали, конечно, за это им большое спасибо, но это не доки, про которые мы здесь говорим :-)
Только что проглядел их сайт — за год многое изменилось.
Первое, что бросается в глаза, появилась возможность скачать готовую сборку под нужную платформу. Например, есть deb-пакеты под Ubuntu. Год назад их не было. Я, конечно, допускаю возможность, что плохо искал, но я их сайт в течении двух недель излазил вдоль и поперек. Если они и были, то прятали их очень хорошо. А про веселую инсталляцию руками я уже выше писал.
Второе, появился внятный пошаговый туториал для новичков. Этого тоже год назад не было. Было что-то вроде известной картинки «Как нарисовать филина».
Я это и имел ввиду, когда сказал про плохую документацию. Если она устарела и на каждой странице написано «купите саппорт» — это разочаровывает.
Первое, что бросается в глаза, появилась возможность скачать готовую сборку под нужную платформу. Например, есть deb-пакеты под Ubuntu. Год назад их не было. Я, конечно, допускаю возможность, что плохо искал, но я их сайт в течении двух недель излазил вдоль и поперек. Если они и были, то прятали их очень хорошо. А про веселую инсталляцию руками я уже выше писал.
Второе, появился внятный пошаговый туториал для новичков. Этого тоже год назад не было. Было что-то вроде известной картинки «Как нарисовать филина».
выпилили wiki, который устарел и сбивал с толку
Я это и имел ввиду, когда сказал про плохую документацию. Если она устарела и на каждой странице написано «купите саппорт» — это разочаровывает.
Велосипед 2.0. По-мойму тем, кому лень понять всю простоту папета/шефа самое оно. Конечно простые вещи на таком велосипеде можно сделать, однако что-то сложное уже не уверен.
И да — даже на одной машинке можно сделать что-то сложное. Число машинок не должно пугать настоящего DevOps'а.
Хотя реализация мне нравится. Как только у вас появится репозиторий с готовыми рецептами — зовите на чай ))
И да — даже на одной машинке можно сделать что-то сложное. Число машинок не должно пугать настоящего DevOps'а.
Хотя реализация мне нравится. Как только у вас появится репозиторий с готовыми рецептами — зовите на чай ))
Конечно простые вещи на таком велосипеде можно сделать, однако что-то сложное уже не уверен.
А не могли бы вы привести пример чего-то сложного? Возможно, мне удастся убедить вас в обратном.
Океюшки, как грят бабушки, как грит Задорнов.
Вот что-то типа такого: github.com/garex/puppet-module-nginx
Чтоб там снаружи подключил, какой-нить дёрнул один точка с параметрами и оно всё далее само?
Т.е. не god-mode скрипт который на любой штуке возможен, а что-то модульное. А-ля тот же докер. И чтобы внутри были всякие события, шаблоны и всё такое.
Вот что-то типа такого: github.com/garex/puppet-module-nginx
Чтоб там снаружи подключил, какой-нить дёрнул один точка с параметрами и оно всё далее само?
Т.е. не god-mode скрипт который на любой штуке возможен, а что-то модульное. А-ля тот же докер. И чтобы внутри были всякие события, шаблоны и всё такое.
1. Объясните в чем ценность примера, в котором для выполнения двух команд вы ставите отдельную софтину и пишете скрипт-костыль, который по своей логике ни чем не отличается от того-же скрипта но без bashbooster?
2. В первом абзаце на сайте написано — что нужен только bash. Амелким шрифтом в описании модуля read — используйте python. Это даже не смешно.
Объясню суть комментария — у нас есть некоторое ПО, которые мы ставим на всякие разные Unix системы(Linux\AIX\HP-UX\Solaris и аналогичное ...). Компилировать под них python\ruby\%another_interpreted_lang% — достаточно ресурсозатратно и не интересно. Bash для нужд выполнения простых консольных команд в готовой последовательность идеально подходит. Но у него есть свои проблемы — например парсинг файлов приходится делать только с учетом платформонезависимых ключей к awk \ grep и т.п. Для себя мы какое-то решение нашли, но иногда хочется взять что-то работающее, вместо допила домашнего костыля.
Если кто-то чем-то подобным занималя (не [только] на linux) — расскажите как решали проблемы с платформозависимыми командами.
2. В первом абзаце на сайте написано — что нужен только bash. А
Объясню суть комментария — у нас есть некоторое ПО, которые мы ставим на всякие разные Unix системы(Linux\AIX\HP-UX\Solaris и аналогичное ...). Компилировать под них python\ruby\%another_interpreted_lang% — достаточно ресурсозатратно и не интересно. Bash для нужд выполнения простых консольных команд в готовой последовательность идеально подходит. Но у него есть свои проблемы — например парсинг файлов приходится делать только с учетом платформонезависимых ключей к awk \ grep и т.п. Для себя мы какое-то решение нашли, но иногда хочется взять что-то работающее, вместо допила домашнего костыля.
Если кто-то чем-то подобным занималя (не [только] на linux) — расскажите как решали проблемы с платформозависимыми командами.
По первому вопросу. Вероятно, вы не уловили суть той части, где обновляется конфигурация nginx — перезагрузка веб сервера осуществляется по событию. Т.е. создается функция-обработчик события nginx-updated и эта функция вызывается только в том случае, если событие возникло. В чем здесь ценность? Скрипт делает ровно то что нужно: если конфигурация не обновлялась — нет смысла перезагружать сервис.
Представьте более сложный пример. У нас есть nginx, который отдает статику и проксирует запросы к серверу приложений uWSGI. Под uWSGI крутится несколько веб-сервисов на Python. Веб-сервисы используют MySQL. Настройки nginx, uWSGI, исходный код и конфиги веб-сервисов, а так же миграции модели базы данных лежат в одном репозитории с кодом.
Задача: сделать автоматический деплой всех обновлений, которые появляются в репозитории.
Какие действия возможны? Если изменились конфиги nginx — перезагрузить nginx. Если изменились конфиги uWSGI — перезагрузить uWSGI. Если изменились конфиги веб-сервисов — перезагрузить uWSGI. Если изменились исходники веб-сервисов — переустановить их в виртуальное окружение и перезагрузить uWSGI. Если изменилась модель — выключить uWSGI (нужен монопольный доступ к базе), выполнить миграцию, включить uWSGI.
Если попытаться написать этот скрипт без использования событий — получится лапша из операторов if, в которой уже через неделю сам автор без бутылки не разберется.
Это пример из жизни. Я не стал его использовать в статье, что бы не загружать читателя ненужными подробностями.
По второму вопросу. Я не вижу ничего криминального в использовании Python для чтения конфигов. Для каких целей это задумывалось? Есть приложение, которое использует базу данных. Логин/пароль от нее лежат в конфиге приложения. Нужно рядом положить скрипт, который периодически (через CRON) делает резервную копию базы. Что-то вроде:
Проблема: где взять username, password и databasename? Можно захардкодить, но тогда придется дублировать настройки, что не очень хорошо. А можно распарсить конфиг скриптом и взять оттуда нужные значения.
Я в своей работе чаще всего использую Ubuntu, Debian или CentOS. На всех из них Python есть. Насколько я знаю, во FreeBSD его нет, но он есть в портах. Из того, что мне приходит в голову, сложности могут возникнуть только с выполнением в Linux на роутере или холодильнике, но в данном случае у вас просто не будет возможности парсить конфиги. Все остальное будет работать без проблем.
Представьте более сложный пример. У нас есть nginx, который отдает статику и проксирует запросы к серверу приложений uWSGI. Под uWSGI крутится несколько веб-сервисов на Python. Веб-сервисы используют MySQL. Настройки nginx, uWSGI, исходный код и конфиги веб-сервисов, а так же миграции модели базы данных лежат в одном репозитории с кодом.
Задача: сделать автоматический деплой всех обновлений, которые появляются в репозитории.
Какие действия возможны? Если изменились конфиги nginx — перезагрузить nginx. Если изменились конфиги uWSGI — перезагрузить uWSGI. Если изменились конфиги веб-сервисов — перезагрузить uWSGI. Если изменились исходники веб-сервисов — переустановить их в виртуальное окружение и перезагрузить uWSGI. Если изменилась модель — выключить uWSGI (нужен монопольный доступ к базе), выполнить миграцию, включить uWSGI.
Если попытаться написать этот скрипт без использования событий — получится лапша из операторов if, в которой уже через неделю сам автор без бутылки не разберется.
Это пример из жизни. Я не стал его использовать в статье, что бы не загружать читателя ненужными подробностями.
По второму вопросу. Я не вижу ничего криминального в использовании Python для чтения конфигов. Для каких целей это задумывалось? Есть приложение, которое использует базу данных. Логин/пароль от нее лежат в конфиге приложения. Нужно рядом положить скрипт, который периодически (через CRON) делает резервную копию базы. Что-то вроде:
mysqldump -u username -p password databasename > dump.sqlПроблема: где взять username, password и databasename? Можно захардкодить, но тогда придется дублировать настройки, что не очень хорошо. А можно распарсить конфиг скриптом и взять оттуда нужные значения.
Я в своей работе чаще всего использую Ubuntu, Debian или CentOS. На всех из них Python есть. Насколько я знаю, во FreeBSD его нет, но он есть в портах. Из того, что мне приходит в голову, сложности могут возникнуть только с выполнением в Linux на роутере или холодильнике, но в данном случае у вас просто не будет возможности парсить конфиги. Все остальное будет работать без проблем.
>> Задача: сделать автоматический деплой всех обновлений, которые появляются в репозитории.
Тут уж извините — ребята писавшие про Chef\Puppet\Ansible — возможно чуть более правы. Но холивар на эту тему разводить не буду — я этими средствами не пользуюсь в силу того, что нам оно не подошло.
Тут уж извините — ребята писавшие про Chef\Puppet\Ansible — возможно чуть более правы. Но холивар на эту тему разводить не буду — я этими средствами не пользуюсь в силу того, что нам оно не подошло.
Ммм, автоматический деплой на роутер или холодильник…
Перечитал еще раз второй пункт в вашем комментарии. Парсить JSON или INI при помощи awk — это ад. Изначально в Bash Booster применялся такой подход для Java Properties файлов. Работало не везде. Потому было решено использовать для этих целей Python, т.к. он работает всегда предсказуемо. Ну а раз впилили Python, заодно впилили поддержку INI, JSON и Yaml (если стоит PyYaml).
Почему бы вам не поделиться своим домашним костылем? Думаю можно было бы добавить в модуль read в качестве резервного варианта, если вдруг Python не установлен.
Для себя мы какое-то решение нашли, но иногда хочется взять что-то работающее, вместо допила домашнего костыля.
Почему бы вам не поделиться своим домашним костылем? Думаю можно было бы добавить в модуль read в качестве резервного варианта, если вдруг Python не установлен.
JSON — парсится через JSON.sh, например. Есть еще разные реализации, но этот наиболее вменяемый.
У нас достаточно специфичный набор самоделок. Как только оно будет отполировано до соответствующего состояния — думаю что поделимся. Тем более что суть решаемых, которые можно решать эти bash booster достаточно похожа.
У нас достаточно специфичный набор самоделок. Как только оно будет отполировано до соответствующего состояния — думаю что поделимся. Тем более что суть решаемых, которые можно решать эти bash booster достаточно похожа.
Есть еще augeas, но у него чуть великоват порог входа и он временами слишком строгий.
Sign up to leave a comment.
Bash Booster — SCM инструмент на чистом баше