Выкатка (или deployment) новых версий Web приложений имеет ряд трудностей, т.к. необходимо быстро и одновременно выполнять группы действий на разных серверах. Процесс обычно включает в себя обновление кода (php) и статики (js/css/картинки), изменение баз данных и настроек системы.

Когда-то давно, новые версии появлялись очень редко (раз в год или даже реже). Тогда происходили сложные и длительные процессы обновления, а пользователи получали сразу огромный пакет изменений. Такой трудоемкий процесс иногда уничтожал целые бизнесы. Сейчас понятие новой версии минимизировано до малейших изменений. Динамика разработки современных приложений огромная, а выкатки обновлений могут происходит каждый день.

Поэтому к процессу выкатки добавился целый ряд требований:

  • Минимум (лучше ноль) ручного вмешательства.
  • Максимальная скорость выполнения (секунды или минуты, но не часы или дни).
  • Возможность быстрого возврата на последнюю рабочую версию.
  • Масштабируемость, а значит независимость скорости выполнения от количества серверов.

Основные компоненты любой крупной Web системы — это фронтенды, бекенды, базы данных и сервера специального назначения (например, почтовые либо медиа-хранилища).

Выкатка фронтендов

Фронтенды обычно выполняют две функции:

  • Раздают клиентам статические файлы (css, js, картинки).
  • Балансируют запросы к приложению и проксируют их на бекенды.

Таким образом, для обновления фронтенда необходимо загрузить новые файлы статики. После этого, выполнить минификацию css/js при необходимости.

На практике это обычно делают так:

  1. Создают дубликат папки проекта на сервере (например /production_b, если основная папка /production_a).
  2. Обновляют эту папку (/production_b) до последней версии. Удобно использовать системы контроля версий, чтобы упростить обновление. Например, Git.
  3. Выполняют необходимые манипуляции (минификация, склеивание и т.п.).
  4. Меняют папку назначения в конфигурации Nginx'a и перезапускают сервер.

Такой подход позволяет мгновенно выполнить перевод всех пользователей на новую версию.

Конфигурация Nginx'a

Представим, что мы используем такую конфигурацию Web сервера: 

server {
        index index.html;
        root /production_a;
}

Тогда после выкатки необходимо заменить директиву root на новый путь. Можно использовать простой php скрипт: 

<?
$config = file_get_contents('site.conf');
$current_version = strpos($config, '/production_a') ? 'a' : 'b';
$new_version = $current_version == 'a' ? 'b' : 'a';
$config = str_replace('/production_' . $current_version, '/production_' . $new_version, $config);
file_put_contents('site.conf', $config);

# Скрипт для последовательного переключения между папками

После обновления и подготовки кода достаточно будет вызывать этот скрипт. Он изменит текущую папку на соседнюю. Если в текущий момент рабочая папка "production_a", выкатку делаем в "production_b" и переключаемся на нее. Если "production_b", то выкатку делаем в "production_a". Таким образом рабочая папка постоянно меняется, а соседняя всегда будет содержать предыдущую рабочую версию.

После изменения файла конфигурации обновляем настройки Nginx'a: 

/etc/init.d/nginx reload

Выкатка бекендов

Выкатка бекендов во многом похожа на выкатку фронтендов.

На всех серверах необходимо обновить код во второстепенной папке (/production_b). После чего переключить конфигурацию Nginx'a на нужную папку: 

server {
		...
        root /production_a;
        index index.php;

        location ~* \.(php)$ {
        	fastcgi_pass 127.0.0.1:9000;
        	fastcgi_index index.php;
        	include fastcgi_params;
        	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    	}
}

# Выделенную папку необходимо заменить на "production_b"

Разогрев приложения

PHP использует различные кэши операционного кода, чтобы экономить на повторной интерпретации файлов. Поэтому, перед тем как переключать пользователей в новую папку, полезно сделать "разогрев" кэша.

Для этого достаточно иметь отдельный хост в Nginx, например: 

server {
		host lambda.ruhighload.com;
        root /production_b;
        index index.php;

        location ~* \.(php)$ {
        	fastcgi_pass 127.0.0.1:9000;
        	fastcgi_index index.php;
        	include fastcgi_params;
        	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    	}
}

# Отдельный хост lambda.ruhighload.com для разогрева кэша новой версии

После этого открыть специальную страницу, которая просто подключит все файлы проекта (preload.php): 

<?
if ( $_GET['key'] != 12345 ) exit;

$it = new RecursiveDirectoryIterator("/production_b");
foreach(new RecursiveIteratorIterator($it) as $file)
{
	if ( pathinfo($file, PATHINFO_EXTENSION) == 'php' ) include $file;
}

# Подключаем все php файлы проекта

Вызов этой страницы следует добавить в скрипт выкатки, чтобы не делать этого руками: 

wget http://lambda.ruhighload.com/preload.php?key=12345

# Ключ для безопасности

Миграции баз данных

Изменение данных и их структуры (или миграция) — наиболее сложная задача при выкатке новых версий. Во-первых изменение структуры данных может занимать достаточно много времени. Во-вторых, ошибки в выкатке могут привести к потерям данных.

Прежде, чем построить систему миграции данных, необходимо обеспечить выполнение следующих правил:

  1. Избегайте изменений в структуре больших таблиц. По возможности, используйте дополнительные таблицы для хранения данных. Например, вместо того, чтобы иметь таблицу users с колонками [name, gender, email, password], можно иметь две таблицы:
    • user_auth [email, password]
    • user_info [name, gender]
  2. Никогда не используйте удаление колонок, таблиц или данных в миграциях. Эти операции должны выполняться отдельными процедурами под внимательным наблюдением администраторов. Миграции должны содержать только добавление колонок/таблиц/данных.
  3. Не добавляйте создание индексов в миграции кроме логически требуемых (например, уникальные ключи). Индексы должны создаваться исключительно под профиль нагрузки на рабочей базе данных. И также под пристальным наблюдением администраторов.
  4. Используйте вертикальные таблицы для случаев, когда колонки таблицы могут часто изменяться. Например, структура таблицы для разных свойств продукта:
    • product_id
    • property_name
    • property_value
    Такую структуру не нужно будет изменять, чтобы добавить новое свойство для продукта.

Технически миграции обычно организуют в виде набора файлов, содержащих SQL запросы, собранных в отдельной папке: 

# ls highloadcomua/data/migrations/	    
15.comments.add.post_id.sql		    
16.comments.add.content.sql		    
17.comments.add.user_id.sql		    
18.tags.add.titl.sql			    
...

Процесс выкатки миграций происходит с использованием отдельного сервера. На нем происходит обновление папки с миграциями (используя систему контроля версий). После этого исполняются SQL-запросы, которые появились в новых файлах миграций.

Пример скрипта, который определит новые файлы после обновления и выполнит миграции из них: 

<?

# Получаем список выполненных миграций
$executed = file('executed.migrations');


# Получаем список всех миграций
$files = glob('data/migrations/*');
foreach ( $files as $file )
{
	if ( in_array($file, $executed) ) continue;

	# Выполняем миграцию
	exec('mysql database -u root -p12345 < ' . $file, $o, $r);

	# Если нет ошибки, помечаем миграцию, как выполненную
	if ( !$r ) $executed[] = $file;
}

file_put_contents('executed.migrations', implode("\n", $executed));

Обновление конфигураций

На серверах специального назначения (например, почтовые сервера) потребность вносить изменения бывает реже, чем на серверах приложения. Однако, иногда приходится делать изменения в конфигурациях. Для таких целей удобно хранить все конфигурации в репозитории. Тогда, для смены настроек, достаточно будет обновить файлы конфигураций на всех серверах.

Например для обновления конфигурации почтового сервера можно было бы использовать приблизительно такой скрипт: 

cd /etc/exim4
git pull
update-exim4.conf
/etc/init.d/exim4 restart

Для более сложных задач управления конфигурациями лучше использовать Chef.

Параллельная выкатка

В случае, если в системе присутствуют несколько десятков или более серверов, последовательное обновление кода на всех серверах может занять много времени: 

for ip in `cat servers.list`; do
    echo "Updating $ip..."
    ssh $ip 'git -C /production_b pull'
done

# Последовательное обновление кода

С помощью фоновых процессов можно выполнить все эти команды параллельно: 

for ip in `cat servers.list`; do
    echo "Updating $ip..."
    ssh $ip 'git -C /production_b pull' >> /var/log/deploy.log &
done

# Параллельное обновление кода на всех серверах в фоне

Возврат к рабочей версии

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

Со всеми узлами в описанном процессе это сделать очень просто. Достаточно изменить рабочую директорию Web сервера с текущей (например, production_b) на предыдущую (production_a).

Для баз данных очень важно соблюдать правило — отсутствие удаления данных любого вида в миграциях. Тогда возврат к предыдущей версии не потребует обратного изменения структуры. Удаление устаревших колонок, таблиц и данных следует планировать с задержкой (например, не ранее, чем через неделю). Это даст запас времени для возможного возврата.

Часть аудитории

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

Поэтому, крупные и важные изменения удобно выкатывать таким образом, чтобы они были доступны только для части аудитории. Например, только для одного процента всех пользователей. В этом случае, негативные последствия будут ограничены только небольшой частью аудитории.

На практике это можно реализовать с помощью установки избранным пользователям кук. Например, установим каждому сотому пользователю куку "tester": 

<?
if ( session::get('id') % 100 == 1 ) setcookie('tester', 1);
...

Тогда в Nginx'e можно будет использовать это значение, чтобы отправлять пользователей с этой кукой в другую (новую) папку: 

server {
		server_name ruhighload.com;

        set $rt '/production_a';

        if ($http_cookie ~* " tester=1") {
            set $rt '/production_b';
        }

        root $rt;

        location ~* \.(php)$ {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi_params;

                fastcgi_param SCRIPT_FILENAME $rt$fastcgi_script_name;
        }
}

# Если установлена кука tester, изменяем переменную $rt на другой путь

Валидация выкатки

Последним шагом в процессе выкатки следует делать проверку доступности приложения. Это нужно, чтобы убедиться, что нет критических ошибок. В самом простом случае это может быть тестовая страница, которая содержит проверки самых важных компонент: 

<?

# проверяем подключение к базе данных
$time = mysql::col('SELET NOW()');
if ( !$time ) echo 'error getting time from mysql';


# проверяем код 200 от основных страниц
$pages = ['/', '/speed', '/server'];
foreach ( $pages as $page )
{
	$c = curl_init('http://ruhighload.com' . $page);
	$result = curl_exec($c);
	$status = curl_getinfo($c, CURLINFO_HTTP_CODE);
	curl_close($c);
	if ( $status != 200 ) echo 'error on page ' . $page;
}


# еще можно проверить php_error.log на наличие ошибок
# еще можно проверить php-fpm.slow-log на появление медленных скриптов
# и т.п.

# hearbeat.php — простой скрипт для быстрой проверки важных компонент сайта

При наличии unit-тестов, имеет смысл использовать их часть для валидации выкатки. В случае обнаружения ошибок лучше всего автоматически откатиться на предыдущую версию, после чего чинить неисправности.

Самое важное

В качестве самого важного — описание общего процесса выкатки:

  1. Обновление файлов в специально отведенной папке (/production_b) с помощью системы контроля версий (Git, SVN и т.п.).
  2. Предварительная подготовка (минификация, разогрев кэшей, миграция данных).
  3. Переключение аудитории или ее части на новую версию (смена пути с /production_a на /production_b на Web сервере).
  4. Проверка основных компонент системы (например, код HTTP ответа от основных страниц) и возврат к предыдущей версии, если обнаружены ошибки.

Подсистема выкатки — это такая же динамическая компонента приложения, как и любая другая. Ее постоянно необходимо дорабатывать и усовершенствовать. Хорошее правило — иметь автономную систему выкатки, которая не требует ручных операций.

Не торопитесь использовать навороченные системы управления выкатками с кучей интеграций всего во все. Собственные решения часто являются намного более простыми, поэтому легче в управлении и более гибкие в использовании.

Не смотря на максимальную автоматизацию, любая выкатка должна всегда происходить под контролем администраторов или разработчиков. Никогда не делайте слепые выкатки, всегда дожидайтесь "Deployment finished successfully" от своей системы.

ID: 166