Автоматизация конфигурации сервера: Ubuntu в Windows Azure (+ WordPress, Nginx, Мерзавец)
Причина, почему не достаточно удалить папку профиля, состоит в том, что существует один ключ реестра ниже HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList на профиль. Если тот ключ существует, Windows думает, что профиль все еще несколько "жив" и не создаст новый. Вместо этого Вы получаете временный профиль. Это происходит начиная с Vista в XP Вы могли простой удалять папку профиля, не заботясь о ключе реестра ProfileList.
Я объяснил это подробно в моей статье Deleting a Local User Profile – Не столь легкий, как Можно было бы Принять.
На самом деле вы ищете решения двух разных (но тесно связанных) проблем, которые накладываются друг на друга:
- Управление конфигурацией
- Автоматизация развертывания
Между ними есть некоторое совпадение, и, когда вы только начинаете, вероятно, будет немного нечетко, какие инструменты использовать для каких частей вашей инфраструктуры. Вот несколько общих рекомендаций, которые помогут вам начать работу:
Инструменты управления конфигурацией обычно следуют ресурсно-ориентированной , идемпотентной модели. То есть вы моделируете свою систему как набор ресурсов, имеющих состояние, и вы постоянно запускаете инструмент управления конфигурацией , чтобы увидеть, не отличается ли что-нибудь от вашей спецификации. Если ресурс не в этом состоянии, у вас есть логика, зависящая от типа, чтобы привести ресурс в это состояние. Пакет или учетная запись пользователя - это простой и очевидный вид ресурса, но у вас также могут быть шаблоны ElasticSearch, записи в базе данных SELinux или хосты Nagios, которые также можно объявить как ресурсы в выбранной вами системе управления конфигурацией.
В качестве быстрого примера, пакет может быть установлен или не установлен , и к нему может быть прикреплена версия. Инструмент управления конфигурацией сможет принять спецификацию конфигурации, в которой говорится, что пакет X должен быть установлен , убедиться, что он в настоящее время не установлен, и предпринять правильные шаги, чтобы перенести его из не установлен в установленное состояние (очевидно, установив его).
Идемпотентность означает, что вы можете применить одну и ту же конфигурацию десять, сто или тысячу раз и получить точно такой же результат - фактически изменяются только те вещи, которые нужно изменить. Это контрастирует со сценарием, который может, скажем, добавить строку в файл конфигурации сто раз (то есть вы получите одну и ту же строку в этом файле сто раз).
Недостатки системы управления конфигурацией, использующей эта модель заключается в том, что связи между вашими ресурсами довольно слабы, они плохо сопоставляются с долгосрочными задачами, такими как импорт базы данных или миграция схемы, и обычно не дают вам тонны контроля над тем, в каком порядке применяются вещи в нескольких системах в стеке.
Puppet и Chef являются примерами систем управления конфигурацией.
Инструменты автоматизации развертывания предназначены для выполнения специальных задач. Другими словами, вы запускаете их явно, когда вам нужно что-то сделать. (Хорошо, иногда вы запускаете их неявно из триггера, например, из системы непрерывной интеграции.) Они часто управляют несколькими системами предсказуемым образом; например, вы можете захотеть, чтобы только один из ваших веб-серверов запускал миграцию базы данных во время обновления, и вы можете захотеть выполнить обновление своего сервера приложений, только если миграция базы данных завершится успешно, и вы можете захотеть, чтобы ваши серверы приложений перезапустили три по время, чтобы вы не отключили все приложение во время обновления. Самое главное, вы хотите, чтобы этот процесс запускался именно тогда, когда вы сообщаете об этом .
Capistrano и Fabric - популярные примеры средств автоматизации развертывания. Для отдельных серверов вы можете так же легко использовать такие вещи, как Makefiles, на всем протяжении вашего приложения.
В вашем конкретном случае вам, вероятно, понадобится система управления конфигурацией, обрабатывающая такие вещи, как установка вашей системы базы данных и PHP, а также конфигурация вашего веб-сервера. С другой стороны, вы, вероятно, захотите, чтобы инструмент развертывания управлял созданием ваших баз данных и заполнением ваших тестовых данных в них. Загрузку кода вашего приложения из Git можно легко смоделировать с помощью средства управления конфигурацией или средства автоматизации развертывания, в зависимости от того, что лучше соответствует вашим потребностям. И независимо от того, какой метод вы выберете, люди расходятся во мнениях относительно того, как файлы конфигурации вашего приложения должны попасть на сервер.
Самое главное, когда вы ' Повторная работа с такими инструментами заключается в том, что они бесполезны, если вы используете их неправильно. Другими словами, если вы используете модный метод автоматизированного развертывания, чтобы поместить свое приложение на промежуточную стадию, и ваш производственный сервер на самом деле не выглядит так же, как ваш промежуточный сервер модных штанов, вы потратили много усилий почти на нет выигрыша. Делайте все правильно, и они вам очень хорошо послужат.
Я больше отношусь к RH (и я бы использовал кикстарт, чтобы сделать основы + puppet, чтобы сделать все остальное), но в любом случае попробуйте puppet. Начать работу должно быть легко, поскольку некоторое время назад Викимедиа опубликовала GIT со всеми своими файлами конфигурации марионеток:
http://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia -servers-are-configure /
Я знаю, что этот ответ может показаться странным ... но подумайте об использовании Hudson, вы можете заставить его делать все, что захотите, просто немного настроив ... и написав скрипты ..
Use Tungsten Replicator - это позволит вам репликацию из экземпляра без RDS в Amazon RDS, который официально не поддерживается, http://code.google.com/p/tungsten-replicator/ . В качестве альтернативы вы можете попробовать что-то вроде maatkit (теперь Percona Toolkit - http://www.percona.com/software/percona-toolkit ) с помощью команды pt-sync-tables и запустить ее в cron или, возможно, сервис на стороннем устройстве (я не знаком с Hetzner).
если они не соответствуют друг другу, то нужно просто вытащить код)Поскольку вы используете php, вам не нужно перезапускать сервер или что-то в этом роде, поэтому можно просто выполнить git pull.
, так что то, что сказал jgoldschrafe, имеет смысл; Я бы просто сделал это с кучей сценариев шеф-повара, запущенных на сайте клиента. Если у вас несколько узлов, я бы также установил сервер Chef и запустил их как клиент Chef.
Я бы использовал Ansible - гораздо проще начать работу с Ansible, чем с Chef, Puppet или Saltstack, которые выполняют аналогичную работу, но требуют гораздо более крутого обучения ( простая установка Puppet занимает довольно много времени из-за необходимости в сервере, тогда как Ansible - это всего лишь одна команда установки и не требует сервера.
Ansible отлично работает для настройки виртуальных машин Linux, работающих в Azure, и при желании также может создавать ресурсы Azure таких как виртуальные машины, сетевые интерфейсы и группы безопасности сети. Если вы предпочитаете использовать Azure CLI, вы можете просто встроить команды CLI в Ansible с помощью модуля оболочки , если они являются идемпотентными (имеют тот же эффект даже при повторном запуске).
Найдите роли Ansible (повторно используемые модули сценариев от третьих сторон) для своих компонентов - есть роли для WordPress, MariaDB / MySQL и CloudFlare. Попробуйте Роли Джеффа Герлинга во-первых, они, как правило, работают хорошо, если охватывают то, что вы eed.
Затем вы можете написать некоторый конкретный код поверх этих ролей, чтобы делать то, что вы хотите.
Ansible также хорошо работает для автоматизации развертывания, чтобы заменить Fabric Capistrano (ищите Ansistrano, если вам нравится модель Capistrano).