Управление конфигурацией и Chef
Расскажу одну очень поучительную и одновременно типичную историю, которая случилась со мною года 3 назад. Однажды один из наших серверов вышел из строя. Казалось бы, обычная ситуация, но беда была в том, что работа приложения была сильно завязано на 10-15 различных cron-задач, которые были прописаны на этой машине. Еще большая проблема была в том, что писались скрипты, которые вызывались по cron, различными людьми, многие их которых к тому времени не работали в компании.
Помимо того, на этом же сервере крутилось несколько сервисов, которые были крайне необходимы для работы системы, и которые нигде больше не крутились.
Суммарно мы с коллегой подымали все заново чуть более суток, постоянно перечитывая исходники, чтобы понять с какими ключами какой скрипт вызывать и как часто это делать. Нам очень повезло, что у нас нашелся в почте дамп crontab, не очень древний. У нас были свободные серверные мощности, но мы не знали, что там запустить и не знали, как это сделать быстро. А как бы хотелось просто сказать системе: «Запусти-ка эти сервисы на другом сервере».
С похожими проблемами прогрессивное человечество встречалось уже много раз. Решение этой проблемы называется «управление конфигурацией». Существует множество открытых решений для управления конфигурацией.
Их внедрение, конечно, дольше, чем настроить один новый сервер, но в долгосрочной перспективе, судя по словам моих коллег, оно себя окупает.
К несчастью, я нередко встречал системных администраторов, которые предпочитают «произведения искусства» — уникальным образом настроенные сервера. Да, я видел одно web-приложение, на котором использовались 4 различные версии FreeBSD и две версии Ruby (1.8.6 и 1.8.7). Просто потому, что там был такой системный администратор. Я бы хотел верить, что это исключение, но я постоянно сталкиваюсь с его коллегами, которые за хорошие деньги долго, плохо и неповторяемым образом делают свою работу.
На данный момент, по-моему мнению, наиболее развивающимся и интересным продуктом для управления конфигурацией является Chef от Opscode.
На всех управляемых машинах запускается chef-client, который раз в какое-то время обращается к chef-server. Сервер говорит, какие рецепты необходимо выполнить на этой машине, chef-client их выполняет. Рецепты позволяют устанавливать ПО, раскладывать файлы конфигурации, стартовать сервисы, а так же делать любые другие операции, которые вам необходимы. В идеале, вам больше нет необходимости заходить на сервера, чтобы что-то там настроить. Так же большой плюс в том, что все изменения в настройке всего комплекса, фиксируются в системе контроля версий. Поэтому всегда можно узнать, что, кто и когда поменял, в случае нештатных ситуаций.
Я сейчас активно увлекся этой темой, поэтому буду иногда писать в этот блог статьи про Chef.
PS Я выступал в Минске с докладом «Continuous Delivery — как перестать релизиться и начать жить», который был основан на материале хорошей книги «Continuous Delivery» и нашего практического опыта в компании Scalaxy. Эта книга из серии Martin Fowler Signature Book, которая достаточно сильно прояснила для меня многие вопросы в отношении управления конфигурацией.
PPS Говоря о Chef, было бы грешно не упомянуть моего дважды коллегу и хорошего друга Александра Титова, который является главным пропагандистом Chef в России. Посмотрите презентацию с его доклада на конференции Rit++.