Оглавление для непрерывной доставки конфигураций сервера
- Превращение 5-часового ручного создания и развертывания в единый кодовый коммит — часть 1
- Часть 2
- Испытание дворецкого — Часть 3
Я играл с Capistrano в течение последних нескольких недель, и недавно я создал способ использовать возможности Capistrano для «развертывания» и «отката» с Puppet и MCollective, чтобы дать мне полный контроль над развертыванием мои системные настройки.Мы начнем с Capistrano, так как это ключ ко всему этому — вам понадобятся следующие гемы:
- Capistrano
- Капистрано-доб
- railsless-развернуть
Я привык к минималистским файлам заглавных букв, чтобы в ваших кукольных манифестах появился «cd» и набрал следующее:
capify
Теперь отредактируйте Capfile так, чтобы он выглядел следующим образом:
load 'deploy' if respond_to?(:namespace) # cap2 differentiator require 'capistrano' require 'rubygems' require 'railsless-deploy' load 'config/deploy'
Мы также собираемся использовать расширение ‘multistage’, чтобы убедиться, что мы только намеренно развертываем в нашей производственной среде, поэтому обновите файл config / deploy.rb и сделайте так, чтобы он выглядел следующим образом:
set :stages, %w[staging production] set :deploy_to, "/usr/share/puppet/configuration" set :deploy_via, :export set :application, "Puppet Manifests" set :repository, "git://gitserver/puppet.git" set :scm, :git set :default_stage, "staging" set :use_sudo, false require 'capistrano/ext/multistage'
Обратите внимание, что этапы должны быть установлены до включения многоступенчатого расширения, иначе они не будут настроены.
Если вы теперь запустите команду cap -vT, вы должны увидеть следующее среди других задач:
cap production # Установите целевую стадию на «производство».
cap staging # Установите целевую сцену на «staging».
Это означает, что теперь мы можем запускать «развертывание с ограниченным доступом» или «развертывание с ограниченным производством» в зависимости от того, что мы хотим сделать. Также обратите внимание, что мы установили стадию по умолчанию для промежуточной, так что мы должны явно указать, когда мы хотим развернуть в производство — это, мы надеемся, сократит любые случайные случаи непроверенных конфигураций, попадающих на живые серверы!
Наконец, обратите внимание, что мы отключили sudo — это делает вещи более безопасными (вы не можете заставить своего пользователя развертывания выполнять произвольный код на серверах!), А также упрощает настройку сервера (без редактирования / etc / sudoers) ,
Следующим шагом является создание учетной записи пользователя на puppetmaster для развертывания. Для простоты мы создадим пользователя с именем «deploy»:
root @ puppetmaster # useradd -m deploy
И назначьте его владельцем каталога декларации puppet (в нашем случае / usr / share / puppet / configuration):
root @ puppetmaster # chown -Rvf deploy: / usr / share / puppet / configuration
Насколько я могу судить, Puppet не заботится о разрешениях записи в каталогах манифестов / модулей, пока пользователь «puppet» может читать манифесты / модули, у нас все хорошо.
Теперь настройте доступ для пользователя. Я специально не установил пароль для этой учетной записи, так как я использую ssh-ключи, которые не так легко взломать!
root @ puppetmaster # su — развернуть
deploy @ puppetmaster> vim ~ / .ssh / authorized_keys
Поместите открытый SSH-ключ пользователя, который будет выполнять команду «cap production deploy», в файл author_keys, указанный выше.
Небольшое затруднение: если вы собираетесь использовать промежуточный сервер с SSH-ключами, убедитесь, что ключ учетной записи пользователя, выполняющего «cap production deploy», находится как на сервере шлюза, так и на puppetmaster, иначе это не удастся!
SSH для puppetmaster в качестве вашего пользователя развертывания из учетной записи, которая будет выполнять «cap production deploy», чтобы вы не получили никаких ошибок SSH-Key.
Теперь настройте ваш конфиг для промежуточной среды в config / deploy / staging.rb:
set :user, "deploy" role :web, "staging" after 'deploy:symlink', 'puppet:run'
и сделайте то же самое для config / deploy / production.rb:
set :gateway, "deploy@support-gateway" set :user, "deploy" set :deploy_via, :copy role :web, "puppetmaster" # set this to the fully qualified domain name of your puppetmaster after 'deploy:symlink', 'puppet:run' after 'deploy:rollback', 'puppet:run'
Это означает, что мы можем переопределить «значения по умолчанию» из deploy.rb для каждой среды.
Возможно, вы заметили следующую строку:
после ‘deploy: Symlink’, ‘Puppet: Run’
Это выполняет пользовательскую задачу в пользовательском пространстве имен, как только «текущая» символическая ссылка была обновлена для принудительного запуска марионетки. Проблема в том, что эта задача еще не существует!
Обновите config / deploy.rb, чтобы он выглядел следующим образом:
set :stages, %w[staging production]
set :application, "Puppet Manifests"
set :repository, "git://localhost/puppet.git"
set :scm, :git
role :web, "puppetmaster" # set this to the fully qualified domain name of your puppetmaster
require 'capistrano/ext/multistage'
require 'mcollective'
#### MCOLLECTIVE STUFF ####
class MCProxy
include MCollective::RPC
def initialize(agent)
@agent = rpcclient(agent)
end
def runaction(action, args)
printrpc @agent.send(action, args)
end
end
namespace :puppet do
desc <<-DESC
Run Puppet to pull the latest versions
DESC
task :run do
puppet = MCProxy.new("puppetd")
puppet.runaction("runonce",:concurrency => '2')
end
end
Важными моментами, на которые следует обратить внимание, являются «require ‘mcollective» (который загружает библиотеки MCollective ) и класс MCProxy (спасибо @ripienaar за помощь в этом!).
Класс MCProxy позволяет нам создавать задачу puppet: run и вызывать агент «puppetd» — обратите внимание, что вы можете вызывать любого агента с любым аргументом, который вам здесь нужен, мы просто вызываем оператор puppet.
Теперь я оставлю вам остальную часть конфигурации (настройка ключей / пользователей SSH и т. Д.), Однако, когда вы сейчас запускаете «cap production deploy», вы должны увидеть, как ваши конфиги марионеток извлекаются из git и SCP’d через шлюз к вашему хозяину марионеток, за которым MCollective выполняет запуск кукол по всему вашему серверу.
Последняя задача — настроить Puppet для чтения новых конфигов. Я предполагаю, что у вас есть все ваши манифесты в одном огромном репо здесь, так что просто обновите ваш конфиг puppet, чтобы он указывал на правильный каталог:
[puppetmasterd]
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
modulepath = /usr/share/puppet/configuration/current/manifests
Если вы не знаете Capistrano, «current» — это символическая ссылка, которая обновляется при каждом успешном развертывании / откате. Puppet не позволит вам установить / etc / puppet в качестве символической ссылки, поэтому вы должны настроить конфиги так, чтобы они указывали на «текущий» выпуск ваших конфигов.
Теперь сделайте начальную настройку:
cap production deploy: setup # создает необходимые каталоги
root @ puppetmaster # служба перезапуск puppetmaster
и разверните первую версию ваших модулей:
развёртывание производства
Дайте мне знать, как вы попали …