Розгортання коду на декількох серверах переднього кінця

У нас ситуація, коли у нас є кілька серверів, збалансованих навантаженнями, які вказують на загальну базу даних.

При нормальному виконанні речей це працює чудово і дає надмірність, масштабованість тощо.

Однак ми вважаємо, що розгортання є дещо справою.

Ми широко використовуємо функції та намагаємось автоматизувати розгортання. Розгортання на даний момент не дуже надійне.

У спрощеній формі сценарій розгортання для кожного сервера має два етапи

1. Оновлення файлів

2. Повернути функції (які керуватимуть залежностями, змінами налаштувань тощо)

Чи є найкращі практики для розгортання на декількох серверах, не приводячи їх у невідповідний стан?

Наскільки я бачу, якщо розгорнути кроки 1 і 2 на сервері А, це призведе до розриву сервера В, якщо ви спробуєте крок перший на обох серверах, перш ніж перейти до кроку 2, вони обидва будуть порушені на деякий час.

Вам, мабуть, варто заглянути в Aegir , який на сьогодні є найбільш гнучкою та потужною системою управління / розгортання Drupal-сайтів. Він здатний керувати "платформами", що охоплюють кілька веб-головок або "кластерів", а також різноманітні інші конфігурації.

Я б запропонував ознайомитись із документацією їх спільноти, яка, як правило, досить добре, а також прочитати чудовий огляд та вступну статтю mig5 та деякі інші його статті, як ця .

Ви також можете отримати хорошу підтримку на #aegir IRC-каналі.

Це буде дещо змінити робочий процес, який, безумовно, може зайняти деякий час, щоб обернутися головою, але, як тільки ви там, ви не озирніться.

У нашій компанії ми підтримуємо багато сайтів Drupal, наша поточна установка працює приблизно так:

• Кодова база кожного сайту має власне git repo
• Нові функції, які, ймовірно, не будуть досить стабільними для наступного випуску, отримують власну гілку функцій у git

Сказане я б сказав, досить поширене для більшості Drupal-сайтів.

Ми особливі для нашої компанії - пакуємо пакунки для debian, розміщені на сайтах для розгортання за допомогою спеціальної команди drush - " Drush Debian Packaging ".

Drush Debian Packaging надає команду Drush для створення пакунків Debian на сайтах Drupal як засобу розгортання Drupal-сайтів на серверах Debian або Ubuntu.

Drush Debian Packaging використовує систему гачків Drupal для створення пакету Debian, який найкраще відповідає потребам ваших сайтів. Особливості включають:

• Автоматична конфігурація віртуального хоста для веб-серверів Apache2 та Nginx
• Налаштування кронів у /etc/cron.d
• Автоматизоване розгортання коду з розділенням розділів для сайтів / за замовчуванням / файлів
• Автоматизована конфігурація через інструмент налаштування dpkg debconf
• Автоматизований процес розгортання
• нестандартний обробник Git VCS для створення пакетів від Git

Що це означає?

Щоб створити реліз:

cd /path/to/drupal-root
drush dh-make

Для розгортання випуску спочатку SCP .deb на всіх веб-серверах кластера. Потім на всіх веб-серверах запущено (ви можете використовувати пакет lss cssh, щоб одночасно набрати команду на всіх серверах ферми):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

На одному веб-сервері запустіть:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Зроблено

Звичайно, щоб повернути це назад, це банально з точки зору бази даних, просто встановіть попередню версію .deb на всі веб-сервери та відкатуйте базу даних.

Раді відповісти на будь-які запитання з цього приводу

Яка частина процесу розгортання є рутинною / ненадійною?

Якщо це проблема "сервера оновлень A, то B / неузгодженість", що робити з розміщенням сторінки обслуговування на час ваших натискань? Сторінка технічного обслуговування вгору, оновлення коду на обох веб-головах, запустіть update.php на одній з них, сторінку технічного обслуговування вниз. Це досить легко прописано.

Інший варіант: залежно від типу веб-сайту, на якому ви запускаєте, ви можете створити режим "лише для читання", який запускає всіх користувачів в автономному режимі та відключає вхід / реєстрацію. Клоніруйте свою БД до другої БД у тому самому вікні db, клонуйте її передній кінець до нової docroot, зробіть там свої оновлення, а потім позначте докроот Apache до нового docroot переднього кінця. Робочий процес - це щось на зразок:

1. Увімкнено лише режим читання
2. SELECT current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. оновити код на new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Вимкнено режим лише для читання.

Це залежатиме від змін, які ви вносите, як пропонує Ентенду. Яка частка оновлень коду може бути запущена без помилок, якщо база даних ще не оновлена? Для всього, що не залежить від оновлень бази даних (і, можливо, ви можете трохи змінити процес розробки, щоб зробити це більш поширеним), насправді нічого особливого робити не потрібно. Я припускаю, що ви хочете робити розгортання з мінімальним простоєм, інакше це займе лише деякі основні операції синхронізації. У цьому випадку завжди знайдеться вікно часу з небажаними ефектами (навіть якщо сайт просто у режимі лише для читання), але я думаю, що це може бути досить мало часу.

Ви можете виконати основну оптимізацію, наприклад, встановити "новий" каталог на кожному сервері заздалегідь, а потім перемкнути їх у всьому, щоб одночасно вказувати на новий каталог (можливо, використовуючи посилання, як у відповіді Ентеду), щоб ви могли отримати все сервери перейшли на нові файли протягом 5-10 секунд.

Це залишає питання оновлення бази даних. Якщо вони виглядають лише з одного сервера, ви можете перевести інших в режим технічного обслуговування або налаштувати балансир навантаження, щоб не використовувати їх, поки це відбувається. Звичайно, якщо їх не вдається зробити під час активних користувачів на сайті, вам просто потрібно буде мати все в режимі обслуговування, але для простих оновлень це можна зробити приблизно за 30 секунд або менше.

Можливо, варто мати різні сценарії розгортання для різних типів змін, тому ви можете запустити мінімально необхідний процес, будь то просто копіювання файлів, запуск невеликого оновлення бази даних або велика зміна бази даних.

Якщо ви можете оптимізувати оновлення файлів і баз даних і подивитися, чи є прості зміни, які ви можете внести до способу розробки, що може вас зблизити, але я не знаю, чи щось із цього вам нове :)

Aegir корисно керувати мережею сайтів. Я використовував його для розгортання та управління понад 2000 сайтів для одного клієнта.

Ваше запитання говорить про те, що ви хочете керувати одним сайтом з кількома веб-головами. У такому випадку Aegir може бути для вас менш корисним. Замість цього я б запропонував вам переглянути файлову систему, яка підтримує мережу. Це не лише забезпечує синхронізацію вашого коду, це означає, що ваші завантаження доступні на всіх вузлах.

Історично люди використовували NFS, який дозволяє ділитися файловою системою одного сервера з іншими вузлами. На жаль, це вводить єдину точку відмови, оскільки якщо сервер NFS заблокується або вмирає, ваш сайт не може обслуговуватися.

Якщо ви готові трохи піти на компроміс з роботою io на користь більш надійного сервера, то я б рекомендував GlusterFS . Я використовував у кількох виробничих середовищах. Це не ідеально, але краще, ніж NFS. Gluster дозволяє веб-голові завжди читати локально, а записи записуються в інші вузли.

З точки зору вашої стратегії розгортання, ви повинні мати друк як перший інструмент у своєму списку. За допомогою барабану ви повинні мати можливість автоматизувати кроки свого розгортання. Вам слід розглянути можливість додавання Дженкінса до суміші, щоб ви могли відслідковувати завдання щодо розгортання та виявляти шаблони, якщо щось не вдасться. Capistrano може бути корисним для автоматизації кроків, що беруть участь у розгортанні. Якщо ви робите все правильно, ви можете зробити це так, щоб ваші користувачі навіть не знали, що ви зробили розгортання.