Мы хотели бы получить некоторые идеи о том, как автоматически настроить виртуальные машины Ubuntu в качестве промежуточных серверов для нашего приложения, протестировать промежуточный код, а затем выполнить развертывание сценария на производственном сервере (а не человек, устанавливающий все на промежуточном сервере через ssh, копирование файлы, ручное редактирование конфигураций и т. д.)
При необходимости мы можем перейти на AWS, но пока у нас все в порядке - мы в основном получаем виртуальную машину Ubuntu с доступом по SSH в Azure, поэтому она не должна сильно отличаться от других способов настройки серверов на базе Linux. представить
Мы хотим, чтобы сценарий выполнял следующие действия:
Затем, если он работает нормально, мы хотим автоматизировать отправку нового кода в Git на наш производственный сервер без ручного редактирования файлов конфигурации wordpress и так далее. Но это немного отличается от вопроса о настройке промежуточной среды через скрипт.
До сих пор я встречал следующие инструменты (не могу предоставить ссылки из-за низкого уровня репутации аккаунта)
Прежде чем погрузиться в них, мне было интересно, есть ли у кого-нибудь представление о том, что применимо к нашим потребностям, с высоты 10 000 футов.
На самом деле вы ищете решения двух разных (но тесно связанных) проблем, которые накладываются друг на друга:
Между ними есть некоторое совпадение, и, когда вы только начинаете, вероятно, будет немного нечетко, какие инструменты использовать для каких частей вашей инфраструктуры. Вот несколько общих рекомендаций, которые помогут вам начать:
Управление конфигурацией инструменты обычно следуют ресурсоориентированный, идемпотент модель. То есть вы моделируете свою систему как набор ресурсов, имеющих состояние, и запускаете инструмент управления конфигурацией. непрерывно чтобы увидеть, не отличается ли что-нибудь от вашей спецификации. Если ресурс не находится в этом состоянии, у вас есть логика, зависящая от типа, для перевода ресурса в это состояние. Пакет или учетная запись пользователя - это простой и очевидный вид ресурса, но у вас также могут быть шаблоны ElasticSearch, записи в вашей базе данных SELinux или хосты Nagios, которые также можно объявить как ресурсы в выбранной вами системе управления конфигурацией.
В качестве быстрого примера пакет может быть установлены или не установлен, и к нему может быть прикреплена версия. Инструмент управления конфигурацией сможет принять спецификацию конфигурации, в которой говорится: пакет X должен быть установлен, убедитесь, что он не установлен, и примите правильные меры, чтобы перенести его из не установлен к установлены состояние (очевидно, установив его).
Идемпотентность означает, что вы можете применить одну и ту же конфигурацию десять, сто или тысячу раз и получить точно такой же результат - фактически изменяются только те вещи, которые нужно изменить. Это контрастирует со сценарием, который может, скажем, добавить строку в файл конфигурации сто раз (то есть вы получите одну и ту же строку в этом файле сто раз).
Недостатки системы управления конфигурацией, использующей эту модель, заключаются в том, что ассоциации между вашими ресурсами довольно слабы, они плохо сопоставляются с долгосрочными задачами, такими как импорт базы данных или миграция схемы, и обычно не дают вам контроль над тем, в каком именно порядке применяются вещи в нескольких системах в стеке.
Puppet и Chef - это примеры систем управления конфигурацией.
Автоматизация развертывания инструменты предназначены для выполнения для этого случая задачи. Другими словами, вы запускаете их явно, когда вам нужно что-то сделать. (Хорошо, иногда вы запускаете их неявно из триггера, например, из системы непрерывной интеграции.) Они часто управляют несколькими системами предсказуемым образом; например, вы можете захотеть, чтобы только один из ваших веб-серверов запускал миграцию базы данных во время обновления, и вы можете захотеть выполнить обновление своего сервера приложений только в том случае, если миграция базы данных завершится успешно, и вы можете захотеть, чтобы ваши серверы приложений перезагружались три раза в время, чтобы вы не отключили все приложение во время обновления. Самое главное, вы хотите, чтобы этот процесс только начался именно тогда, когда вы говорите это.
Capistrano и Fabric - популярные примеры средств автоматизации развертывания. Для отдельных серверов вы можете так же легко использовать такие вещи, как Makefiles, во всем приложении.
В вашем конкретном случае вы, вероятно, захотите, чтобы система управления конфигурацией обрабатывала такие вещи, как установка вашей системы баз данных и PHP, а также конфигурация вашего веб-сервера. С другой стороны, вы, вероятно, захотите, чтобы инструмент развертывания управлял созданием ваших баз данных и заполнением ваших тестовых данных в них. Загрузку кода вашего приложения из Git можно легко смоделировать с помощью средства управления конфигурацией или средства автоматизации развертывания, в зависимости от того, что лучше соответствует вашим потребностям. И независимо от того, какой метод вы выберете, у людей разные мнения о том, как файлы конфигурации ваше приложение должно попасть на сервер.
Самое главное, когда вы работаете с подобными инструментами, это то, что они бесполезны, если вы используете их неправильно. Другими словами, если вы используете модный метод автоматизированного развертывания для постановки своего приложения на промежуточную стадию, и ваш производственный сервер на самом деле не выглядит точно так же, как ваш промежуточный сервер модных штанов, вы потратили много усилий почти на нет выигрыша. Делайте все правильно, и они вам очень хорошо послужат.
Вы смотрите на две вещи:
Я бы предложил использовать Chef, и вы можете использовать chef-bootstrap, который не зависит от ОС.
В первой части вам нужно просто настроить пакеты mariadb, nginx, php и другие, что с шеф-поваром просто и понятно.
Вторая часть - это первая настройка - например, импорт базы данных, настройка DNS, разрешение пользователю входить в систему, поэтому настройте ключи ssh, вы все равно можете использовать chef и поставить проверки, чтобы мы знали, что эти скрипты должны запускаться в первый раз, например, первая загрузка во многих системы
Для третьей части, которая является непрерывным развертыванием, вам необходимо выяснить триггеры (например, каждая проверка git должна запускать обновление git на локальном компьютере, что может быть выполнено с помощью простого запланированного задания cron, которое сопоставляет номер удаленной головки с номером локальной головки, если они не совпадают, то нужно просто вытащить код)
Поскольку вы используете php, вам не нужно перезапускать сервер или что-то в этом роде, поэтому хорошо просто выполнить git pull.
так что то, что сказал jgoldschrafe, имеет смысл; Я бы просто сделал это с кучей сценариев шеф-повара, запущенных на сайте клиента. Если у вас несколько узлов, я бы также установил сервер Chef и запустил их как клиент Chef.
Я знаю, что этот ответ может показаться странным ... но подумайте об использовании Hudson, вы можете заставить его делать все, что захотите, просто немного подправив ... и написав сценарии ..
Я больше сторонник RH (и я бы использовал кикстарт, чтобы сделать основы + марионетку, чтобы сделать все остальное), но в любом случае попробуйте марионетку. Начать работу должно быть легко, поскольку некоторое время назад Викимедиа опубликовала GIT со всеми своими файлами конфигурации марионеток:
http://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia-servers-are-configured/
я хотел бы использовать Ansible - Начать работу с Ansible намного проще, чем с Chef, Puppet или Saltstack, которые выполняют аналогичную работу, но имеют гораздо более крутую кривую обучения (просто установка Puppet занимает довольно много времени из-за необходимости сервера, тогда как Ansible - это всего лишь один установить команду и не требует сервера.
Ansible отлично работает для настройки виртуальных машин Linux, работающих в Azure, и при желании также может создавать ресурсы Azure, такие как виртуальные машины, сетевые интерфейсы и группы безопасности сети. Если вы предпочитаете использовать Azure CLI, вы можете просто встроить команды CLI в Ansible, используя shell модуль, пока они идемпотентны (имеют тот же эффект, даже если запустить снова).
Посмотрите на Ansible роли (повторно используемые модули скриптов от третьих сторон) для ваших компонентов - есть роли для WordPress, MariaDB / MySQL и CloudFlare. Попробуйте Джефф Герлинг роли Во-первых, они, как правило, работают хорошо, если охватывают то, что вам нужно.
Затем вы можете написать конкретный код поверх этих ролей, чтобы делать то, что вы хотите.
Ansible также хорошо работает для автоматизации развертывания, чтобы заменить Fabric Capistrano (ищите Ansistrano, если вам нравится модель Capistrano).