Статьи

Как настроить WordPress на EC2 с помощью Puppet и Git


Начав с устройства
Joyent , мигрировав на Linode и, наконец, на Amazon со
стеком Bitnami , мы заметили общую боль ручной настройки каждой из этих сред. Bitnami вызвал у нас еще большую головную боль, так как его было очень трудно обновить (apt-get не обновляет стек AMP, упакованный в bitnami). Мы решили получить полный контроль над нашей коробкой, настроив стандартный стек Debian LAMP на AWS, используя Puppet и git для управления нашими сайтами. Вот небольшое введение в то, как мы это сделали.

AWS и развернуть

Настройте экземпляр t1.micro с aws.amazon.com для своего блога. Помните, что если у вас еще нет учетной записи AWS, этот микроэкземпляр бесплатный в течение 12 месяцев! Мы получаем ~ 20KPI в месяц, поэтому микроэкземпляра достаточно, чтобы покрыть это (со значительной настройкой).

Зарегистрируйтесь на unfuddle.com и получите 200 МБ бесплатных частных репозиториев git.

Установить и настроить Puppet автономно

$ apt-get install puppetmaster puppet
$ vi /etc/hosts
127.0.0.1 master.successfulengineering.com
...
$ vi /etc/puppet/puppet.conf
...
[agent]
server = master.successfulengineering.com

Настройте свое Git-репо

у unfuddle есть хороший справочный документ для этого, но суть состоит в том, чтобы добавить базовый каталог установки puppet на вашем экземпляре в git repo unfuddle:

$ cd /etc/puppet
$ git remote add unfuddle git@successfulengineering.unfuddle.com:successfulengineering/puppetmaster.git
$ git config remote.unfuddle.push refs/heads/master:refs/heads/master
$ git add *
$ git commit -am "initial commit"
$ git push unfuddle master

Теперь вы можете клонировать это в вашу локальную среду разработки и начать создавать манифесты! После того, как вы поместите свои локальные изменения в git, выполните git pull на удаленном экземпляре. Чтобы применить обновления манифеста при создании сайта, используйте параметр —test (в противном случае puppet запустится в режиме демона).

$ puppet agent --test

Поздравляем! Теперь у вас есть работающая марионеточная автономная среда с git-репозиторием. Время для настоящей работы.

Базовая среда (L)

Вот как выглядит наш файл node.pp:

node default {
  include setenv
  include ntp
  include users
 
  include mysql
  include apache
  include php
 
  include blogs
}

Модуль setenv устанавливает мои пакеты по умолчанию (htop, unzip, wget, git-core, vim, fail2ban), устанавливает vi в качестве редактора по умолчанию и устанавливает языковой стандарт по умолчанию в / etc / default / locale следующим образом:

LANG="en_US.UTF-8"
LC_ALL="en_US.UTF8"

NTP должен быть очевиден, а пользовательский модуль гарантирует, что Матиас и мои пользователи существуют с соответствующими ключами SSH и ролями группы администраторов.

Базовые приложения (AMP)

Теперь, когда наша базовая среда Linux настроена, давайте перейдем к разделу «AMP».
Мы настраиваем наш базовый сервер MySQL со следующим манифестом:

class mysql {
  package { "mysql-server":
    ensure => present,
  }
  service { "mysql":
    ensure => running,
    enable => true,
    hasstatus => true,
    require => Package["mysql-server"], 
  }
  file { "/etc/mysql/my.cnf":
    ensure => present,
    content => template("mysql/my.cnf.erb"),
    notify => Service["mysql"],
    require => Package["mysql-server"],
  }
  exec { "set mysql root password":
    path => "/usr/bin",
    unless => "mysql -uroot -p${root_mysql_password}",
    command => "mysqladmin -u root password ${root_mysql_password}",
    require => Service['mysql'],
  }
}

Переменная $ root_mysql_password объявлена ​​в нашем файле site.pp.

Apache немного сложнее:

class apache {
  include apache::install
  include apache::conf
  include apache::sites
  include apache::mods
}

Для сайтов и модов я определяю собственный метод, который позволяет нам легко включать / отключать новые сайты и необходимые модули. Вот фрагмент из класса apache :: mods:

  define mods_stats ( $ensure = 'present') {
    case $ensure {
      'present' : {
        exec { "/usr/sbin/a2enmod $name":
          unless => "/bin/sh -c '[ -L /etc/apache2/mods-enabled/$name.load ] \\
            && [ /etc/apache2/mods-enabled/${name}.load -ef /etc/apache2/mods-available/${name}.load ]'",
            notify => Exec["force-reload-apache"],
 	    require => Package["apache"],
        }
      }
      'absent': {
        exec { "/usr/sbin/a2dismod $name":
          onlyif => "/bin/sh -c '[ -L /etc/apache2/mods-enabled/${name}.load ] \\
            && [ /etc/apache2/mods-enabled/${name}.load -ef /etc/apache2/mods-available/${name}.load ]'",
            notify => Exec["force-reload-apache"],
            require => Package["apache"],
        }
      }
      default: { err ( "Unknown ensure value: '$ensure'" ) }
    }
  }
  apache::mods::mods_stats { 
    "rewrite" : ensure => present, 
    notify => Service["apache"], 
  }
  apache::mods::mods_stats { 
    "deflate" : ensure => present, 
    notify => Service["apache"], 
  }

Хотя определение mods_stats может показаться немного длинным, оно окупается довольно быстро, когда вы можете легко включать / отключать любые моды во всех ваших манифестах.

Модуль PHP — это то же самое, использующий шаблоны марионеток для управления распределением памяти для apc.ini и php.ini. Напишите мне для получения более подробной информации.

WordPress сайты

Таким образом, у нас есть стандартная настройка стека LAMP и инициализация с нашими паролями, модулями и ограничениями памяти Давайте приступим к делу, а именно к модулю блогов.

class blogs {
  include blogs::agileweboperations
  include blogs::successfulengineering
}

Давайте посмотрим на манифест этого блога:

class blogs::agileweboperations {
  # Apache website
  file { "/etc/apache2/sites-available/agileweboperations.com":
      ensure => present,
      owner   => root,
      group   => root,
      mode    => 644,
      source => "puppet:///modules/blogs/etc/apache2/sites-available/agileweboperations.com.conf",
      require => Package["apache"],
      notify => Service["apache"],
  }
  apache::sites::site { "agileweboperations.com" : ensure => present }  
 
  exec { "setup awo db":
    path => "/usr/bin",
    unless => "mysql -uroot -p${root_mysql_password} ${awo_mysql_db}",
    command => "mysql -uroot -p${root_mysql_password} -e \"\
CREATE DATABASE ${awo_mysql_db} DEFAULT CHARACTER SET UTF8;\"",
    require => Exec["set mysql root password"],
  }  
 
  exec { "setup awo user":
    path => "/usr/bin",
    unless => "mysql -u${awo_mysql_user} -p${awo_mysql_pass}",
    command => "mysql -uroot -p${root_mysql_password} -e \"\
CREATE USER '${awo_mysql_user}'@'localhost' IDENTIFIED BY '${awo_mysql_pass}'; \
GRANT ALL PRIVILEGES ON ${awo_mysql_db}.* TO '${awo_mysql_user}'@'localhost' WITH GRANT OPTION;\"",
    require => Exec["setup awo db"],
  }
}

Это объединяет все части головоломки: нашу пользовательскую конфигурацию apache, делает сайт простым однострочным и загружает базу данных и пользователя WordPress (только если они не существуют).

Мы не делаем установку WordPress как таковую. Мы работаем над этим сайтом почти четыре года, и у нас он есть в репозитории git (удобно размещается рядом с репозиторием Puppet с unuddle). Все миграции, которые мы выполнили в прошлом, показали, что «знаменитая 5-минутная установка» не может сравниться с легкостью клонирования git.

Создание и нахождение вышеупомянутых манифестов в Интернете заняло у меня около 12 часов общей рабочей нагрузки, но у меня также есть несколько лет опыта работы с куклами. Надеемся, что это руководство даст вам некоторые идеи и советы о том, как получить контроль над вашей средой WordPress с помощью Puppet. Дайте знать, если у вас появятся вопросы!