Уже не раз сталкивался, что многие почему-то считают, что ТАМ (в США, реже — в Европе) намного лучше, чем тут. Типа тут нет квартиры в собствености, денег платят мало, законы плохие, ну и всё такое. Что характерно — многие в городе, где хотели бы работать, никогда в жизни не были. Некоторые считают, что они были в США, проведя неделю в Нью-Йорке, хотя айтишники работать будут почти наверняка в Долине. Что странно — эти же люди не особо хотят делать что нибудь, чтобы жизнь тут стала лучше.
В общем, люди ожидают, что жизнь у них сложится как в голливудском фильме, причём без особых на то усилий.
В итоге будет кучка разных реп. Как их потом деплоить? Для 1-2 серверов может и прокатит. Для десятков и сотен нужны уже другие тулзы, типа puppet/chef, и (я всё же рекомендую) пакетные менеджеры. Для тысяч и десятков тысяч серверов возникают совсем другие проблемы, типа физической невозможности разложить файл/пакет на все эти машины традиционными способами.
Эта статья про вторую категорию.
Кстати, Aecktann, предлагаю сегодня после ваших занятий обсудить третью категорию :)
На какой машине? На девелоперской? Или на тестинге? Весь /etc в один VCS положить? А если у меня на девелоперской машине 5 компонентов сервиса стоят вместе, а в продакшене это будут 5 разных групп машин, то как поступать?
А, тогда puppet обязательно попробуйте, вне зависимости от того, как конфиги будете хранить. Наша штука вроде бы не опенсорс и поэтому порекомендовать её не могу.
Я попробую призвать кого нибудь из админов:) Я то разработчик, тоже пакеты собираю, но не раскатываю. У нас есть штука, которую используют админы, работает примерно так: я запушил в гит новую версию своего софта, он на билдферме собрался. Я иду на сайт и делаю тикет на выкладку пакета (или нескольких) с указанием версий, пишу комментарий. Для каждого пакета в этой системе прописано, в каких проектах и на каких группах серверов он должен быть установлен. Админ получает нотификацию, что я сделал тикет, и, если ничего не мешает, запускает деплоймент. Для девелоперских кластеров иногда делают автовыкатывание, если разработчики и админы не против. У админов ещё есть спец. тулза, которая позволяет делать всякие операции на группах серверов.
Чем хороши конфиги в пакетах: в системе просто нету файлов, которые админ правил руками. Есть либо автосгенерённые в postinst (их стараемся избегать), либо файлы, установленные из пакета. Следовательно, dpkg -S на любой файл в системе с большой долей вероятности скажет, откуда он был установлен, какой версии пакет и можно ли его обновить. Если накосячили — легко и быстро можно откатиться. Для софта, который требует каких-то параметров машины в конфиге (скажем, адрес) пишем инит скрипты так, чтобы они по шаблону при старте эти конфиги генерировали. Шаблон, естественно, тоже в пакете.
Так я ж не против Puppet как такового, мне просто странно видеть, что конфиги просто пишутся как файлы. Есть некоторое ощущение, что из этого может получиться каша в /etc серверов. Впрочем, т.к. я не администратор, и к тому же puppet не использовал, то это ощущение может оказаться и ложным. Я только dpkg -S умею делать, чтобы понять, откуда конфиг взялся и где его править :)
Вкратце, моя позиция такова: я настоятельно рекомендую всем админам использовать puppet/chef как только количество серверов, выполняющих одинаковые функции, станет больше одного. Пакеты не перпендикулярны puppet, эти два механизма отлично дополняют друг друга.
dpkg ругается, если файл — не конфиг. А если конфиг — то не ругается.
Как дяди в большой компании раскатывают пакеты на сотни серверов и я так каждый день вижу. Исходя из этого опыта и говорю, что пакеты не так плохи и сложны, как многим кажется.
Возни в принципе столько же — сначала поправить файлик-конфиг, потом закоммитить его, потом задеплоить. Если пару алиасов написать — то по количеству команд одинаково получится, разве что чуть дольше. Что хорошо в пакетах — есть зависимости, можно у совершенно разных сервисов использовать общие части. Я вижу в вашем примере, что в принципе зависимости есть. Но может ли один манифест зависеть от другого? Грубо говоря, есть какие-то базовые настройки нгинкса, которые вы записываете в /etc/nginx/nginx.conf (всякие там количества воркеров, логирование и т.д.), и есть конфиги для сервисов-сайтов, которые вы укладываете в /etc/nginx/sites-enabled/siteN.conf. Может ли манифест для siteN зависеть от манифеста, в котором создаётся конфиг nginx.conf?
Про пересборку пакета — вы не совсем правы, это ж не плитку таскать пешком на 12 этаж :) Пакет с конфигами за несколько секунд собирается, за 1 команду. Можно хоть в git hook добавить при желании.
а. Так конфиг положить не в пакет openssh, а в mycompany-openssh-config конечно же! Сам сервер при этом будет из апстрима ставиться. А именно в конфигурационных пакетах уже писать postinstall скрипты, запускающие сервисы.
б. Кажется, создание уникальных конфигов — это изначально плохая идея, и мне в голову сходу не приходит, где это может быть нужно в гомогенной серверной среде.
Зачем вы запихиваете конфиги в манифесты вместо того, чтобы положить их в пакеты, и уже пакеты накатывать с помощью puppet? Ведь именно пакетный менеджер описывает состояние системы, и позволяет переводить это самое состояние в целевое путём установки пакетов правильных версий.
И второй момент, как решить проблему dev-testing-stable версий с помощью puppet?
Не, я патчик делает распределённый кэш, если одна нода вылетит — просто потеряется часть ключей. Или, если места не жалко, на каждой ноде копию хранить. Никакого SPOF, никакой синхронизации файликов по-отдельности.
Это вы сейчас http сервер, который раздаёт лекции и сопутствующие материалы облаком назвали? Или красивый веб-интерфейс на нём? Сейчас уже самый обычный вордпресс, установленный в режиме шаред директории, называют SaaS и облачным решением. Это глупо.
В общем, люди ожидают, что жизнь у них сложится как в голливудском фильме, причём без особых на то усилий.
michelebavaro.blogspot.ru/2012/08/the-gps-tracker-to-beat-smallest.html
ipnpr.jpl.nasa.gov/progress_report/42-131/131E.pdf
Эта статья про вторую категорию.
Кстати, Aecktann, предлагаю сегодня после ваших занятий обсудить третью категорию :)
В общем, так себе идея.
Чем хороши конфиги в пакетах: в системе просто нету файлов, которые админ правил руками. Есть либо автосгенерённые в postinst (их стараемся избегать), либо файлы, установленные из пакета. Следовательно, dpkg -S на любой файл в системе с большой долей вероятности скажет, откуда он был установлен, какой версии пакет и можно ли его обновить. Если накосячили — легко и быстро можно откатиться. Для софта, который требует каких-то параметров машины в конфиге (скажем, адрес) пишем инит скрипты так, чтобы они по шаблону при старте эти конфиги генерировали. Шаблон, естественно, тоже в пакете.
А как вы раскатываете пакеты по машинам сейчас?
Вкратце, моя позиция такова: я настоятельно рекомендую всем админам использовать puppet/chef как только количество серверов, выполняющих одинаковые функции, станет больше одного. Пакеты не перпендикулярны puppet, эти два механизма отлично дополняют друг друга.
Как дяди в большой компании раскатывают пакеты на сотни серверов и я так каждый день вижу. Исходя из этого опыта и говорю, что пакеты не так плохи и сложны, как многим кажется.
Про пересборку пакета — вы не совсем правы, это ж не плитку таскать пешком на 12 этаж :) Пакет с конфигами за несколько секунд собирается, за 1 команду. Можно хоть в git hook добавить при желании.
б. Кажется, создание уникальных конфигов — это изначально плохая идея, и мне в голову сходу не приходит, где это может быть нужно в гомогенной серверной среде.
И второй момент, как решить проблему dev-testing-stable версий с помощью puppet?
Кэш на трёх фронтах никак не синхронизируете, они в этом плане полностью независимы?