12
При этом развертывание и поддержка этих служб часто отнимала у
администраторов большое количество рабочего времени[13].
Везде, где далее будут упоминаться контейнерные технологии, речь
будет идти о Docker. Это программное обеспечение для автоматизации
развёртывания и управления приложениями в среде виртуализации на уровне
операционной системы. Позволяет «упаковать» приложение со всем его
окружением и зависимостями в контейнер, который может быть перенесён на
любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет
среду по управлению контейнерами. Изначально использовал возможности
LXC, с 2015 года применял собственную библиотеку, абстрагирующую
виртуализационные возможности ядра Linux — libcontainer. С появлением
Open Container Initiative начался переход от монолитной к модульной
архитектуре.
Разрабатывается и поддерживается одноимённой компанией-
стартапом, распространяется в двух редакциях — общественной (Community
Edition) по лицензии Apache 2.0 и для организаций (Enterprise Edition) по
проприетарной лицензии. Написан на языке Go[29].
С появлением контейнерных технологий все стало значительно проще.
Контейнер представляет собой текстовый файл с простым синтаксисом,
называющийся Dockerfile, с описанием того сервиса, который в нем будет
работать. Для описания могут использоваться следующие директивы[24,25]:
FROM – имя образа, на основе которого работает контейнер. Может
быть операционной системой, другим контейнером или же иметь значение
scratch, когда контейнер создается «с нуля»
LABEL – описание контейнера
RUN – предписание выполнить команду установки или настройки
EXPOSE – сделать порт доступным из вне
VOLUME – том, подключаемый к контейнеру. Каждый раз при
построении контейнер возвращается в первоначальное состояние. Чтобы
предотвратить потерю, например, файлов баз данных, используются тома
13
ENTRYPOINT – команда или сценарий, запускающие основной сервис,
который будет работать в контейнере
CMD – аргументы для команды в ENTRYPOINT
ENV – объявление переменной окружения внутри контейнера
WORKDIR – установка текущей директории
USER – установка текущего пользователя
COPY – копирование файла с хост-системы в контейнер
ADD – то же что и COPY, но может копировать целый каталог, а также
приметено к tar-архиву, распакованное содержимое которого появится в
указанной директории.
При этом необходимо придерживаться правила – один сервис – один
контейнер, то есть, например, веб-приложение, написанное на php,
использующее веб-сервер Apache, базу данных MySQL и front-end веб-сервер
Nginx будет представлять собой, в терминах Docker, стек из трех сервисов –
бек-энд сервера Apache с приложением, базы данных и фронт-энд сервера.
Для описания подобных стеков используются специальные yaml файлы[22].
Использование контейнеров предоставляет широкие возможности по
масштабируемости приложений. Оркестрация контейнеров – это
автоматическое размещение, координация и управление сложными
компьютерными системами и службами.
В принципе, ничто не мешает создать контейнер, в котором запущены
сразу все необходимые процессы, но этот подход лишен гибкости при
масштабировании, изменении архитектуры, а также создает проблемы с
безопасностью, т.к. в этом случае процессы никак не изолированы и могут
без ограничений влиять друг на друга. Оркестрация описывает то, как
сервисы должны взаимодействовать между собой, используя для этого обмен
сообщениями, включая бизнес-логику и последовательность действий.
Оркестровка подчинена какому-то одному из участников бизнес-процесса. В
сервис-ориентированной архитектуре оркестровка сервисов реализуется
согласно стандарту Business Process Execution Language (WS-BPEL)[13].
14
В работе в качестве средства оркестрации контейнеров использован
Docker Compose. Это средство, позволяющее использовать для запуска
нескольких контейнеров их описание в одном текстовом файле и
установления между ними зависимостей друг от друга. В терминах Docker
это называется стек приложения. Файл, как правило, имеет имя docker-
compose.yml и располагается в одном каталоге с файлами стека приложения
(конфигурационные файлы сервисов и файлы приложений, копируемые в
контейнер директивой ADD или COPY, каталоги, используемые в
контейнерах в качестве томов)[23]. Обзор синтаксиса yml файлов Docker
Compose выходит за рамки работы из-за большого количества различных
директив. Пример yml файла, использованного для запуска стека
исследуемого приложения приведен в приложении 1.
Также группа контейнеров приложения может быть распределена по
разным хост-системам, при этом оставаясь в одной логической сети и
централизованно управляться. Такие возможности предоставляются
средствами для создания кластеров, например, Docker Swarm. Если перестает
хватать ресурсов для обслуживания какого-либо из сервисов приложения,
достаточно просто увеличить количество экземпляров контейнеров, на
которых он работает. Сделать это можно разными способами, в зависимости
от того, какое средство оркестрации используется. Суть состоит в том, что
контейнерная среда имеет свои собственные сети, в которых возможно
разрешение имен контейнеров и при увеличении количества контейнеров,
например, содержащих php файлы и сервер Apache, все они будут доступны
по имени и на фронт-энд сервере достаточно указать имя контейнера чтобы
запросы стали равномерно распределяться между ними[13].
В данной работе для запуска приложений будет использована
платформа Docker. Для работы приложения будет необходимо запустить три
контейнера, как в приведенном выше примере: СУБД MySQL, Apache с php
приложением и nginx. Однако по ряду причин нет возможности отказаться от
прежнего размещения приложения на отдельном сервере в локальной сети,
15
поэтому для обработки ряда запросов будет использован и он. Это не дает
возможности говорить о полном переводе исследуемого приложения в
контейнерную среду, однако, даст возможность проиллюстрировать
возможности nginx по балансировке нагрузки между несколькими
независимыми бек-энд серверами и возможности распределения запросов, в
зависимости от запрашиваемого метода.
1.1.3. Микрокэширование и CDN
Content Delivery Network - cети доставки контента. Это специальная
технология, которая позволяет посетителю получать содержимое сайта из
разных географических мест. Эта технология позволяет выравнивать время
отклика приложений и сайтов для пользователей из разных стран. Например,
у пользователя из США приложение, размещенное на серверах в США, будет
работать гораздо быстрее, чем у пользователя из Австралии. Если целевая
аудитория приложения находится не только в США, но и в Австралии, его
владелец может воспользоваться услугами CDN и разместить приложение
еще и в Австралии.
Различные CDN и особенности их функционирования выходят за
рамки данной работы, здесь необходимо рассмотреть возможности, которые
дает микрокэширование. Оно может быть реализовано в том числе с
помощью Nginx.
Микрокэширование – это создание кэша динамических страниц на
очень короткое время, например, на 1 секунду. Если статические файлы,
например, сценарии JavaScript, CSS и изображения, кэшируются легко, так
как редко изменяются, кэширование динамических страниц на сколь либо
длительное время не всегда возможно. Однако если есть страница, которая за
секунду запрашивается сразу несколькими пользователями, логично будет
реализовать ее кэширование подобным образом[8].
Объединив обозначенные в разделе технологии можно получить нечто
среднее между полноценным приложением, размещенным в определенном
16
географическом регионе, и кэширующим сервером. Вернемся к примеру с
приложением для США и Австралии. Допустим, что создание реплики
приложения не возможно по ряду причин, но для пользователей из
Австралии также необходимо обеспечить качественный доступ. Проблему
можно решить, установив и настроив в Австралии сервера, обеспечивающие
микрокэширование контента. Если еще воспользоваться директивами,
предотвращающими отправку дополнительных запросов на основной сервер
в то время как страница уже генерируется для одного пользователя
(proxy_cache_lock), можно, во-первых, снизить требования к полосе
пропускания, во-вторых, сократить количество запросов из отдаленного
региона, в-третьих, отдавать целевым пользователям запрашиваемое
содержимое практически без задержек. При этом контент будет устаревшим
максимум на секунду[32].
1.2. Возможности NGINX
1.2.1. Архитектура NGINX
NGINX - это высокопроизводительный веб-сервер, потребляющий
очень мало системных ресурсов. Первоначально NGINX задумывалась как
HTTP-сервер. Она создавалась для решения проблемы C10К, описанной
Дэниэлом Кегелем (Daniel Kegel) на странице http://www.kegel.com/c10k.html,
- проектирование веб-сервера, способного обрабатывать одновременно 10
000 соединений. NGINX может это делать за счет основанного на событиях
механизма обработки соединений и для достижения цели использует
зависящий от ОС механизм событий[2].
Среди высокопроизводительных веб-серверов NGINX отличается еще
и тем, что проектировалась для работы в качестве почтового прокси-сервера.
В зависимости от поставленной задачи NGINX можно настроить для
ускорения работы другого веб-сервера, для работы в качестве веб-сервера,
для работы в качестве почтового прокси-сервера или для всего сразу. Иногда
удобно иметь один пакет, который можно установить на любой сервер
17
внутри организации и задать роль NGINX в конфигурационном файле. А
иногда для работы в высокопроизводительных средах, где каждый килобайт
на учете, лучше подготовить урезанный двоичный файл.
Nginx имеет модульную архитектуру. Помимо основного модуля,
модулей http и mail, в дистрибутив NGINX включен еще целый ряд модулей.
Поведение Nginx полностью определяется конфигурационным файлом,
который состоит из секций. Секции устроены следующим образом:
<секция> {
<директива> <параметры>;
}
В глобальной секции задаются параметры, оказывающие влияние на
сервер в целом. Его формат отличается от описанного выше. Глобальная
секция может включать как конфигурационные директивы, например user и
worker_processes, так и секции, например events. Глобальная секция не
заключается в фигурные скобки.
Также необходимо сказать несколько слов об исполнении Nginx. Он
выполняется в нескольких процессах. Основной процесс определяется в
основной секции конфигурационного файла и исполняется от имени
пользователя, который его запустил. Он управляет поведением рабочих
процессов, которые работают от имени пользователя, указанного в директиве
user основной секции (как правило, nginx). Именно с рабочими процессами
взаимодействует пользователь, обращающийся к серверу. Это дает
возможность быть уверенным, что воздействие пользователя на рабочие
процессы не нанесет вред системе[2].
1.2.2. Балансировка нагрузки
Основное предназначение NGINX – это работа в качестве фронт-энд
веб-сервера. Балансировка нагрузки – это распределение запросов
пользователей между несколькими серверами, способными их правильно
обработать. В Nginx для балансировки нагрузки между веб-серверами
18
используется модуль ngx_http_upstream_module. Он позволяет описывать
группы серверов, которые могут использоваться в директивах proxy_pass,
fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass и grpc_pass[6].
Балансировка нагрузки между серверами включается следующим
образом: в конфигурационном файле создается секция upstream, в которой
перечисляются сервера и которой присваивается имя. После ее объявления
можно использовать это имя при перенаправлении запросов клиентов на
проксируемые сервера с учетом веса сервера. Полное описание синтаксиса
блока upstream представлено в листинге[27,28]:
upstream @name {
ip_hash;
server servername1:port;
server servername2:port;
server servername3:port;
}
При этом директива server имеет, помимо имени вышестоящего
сервера, ряд настроек, перечисляемых после имени через пробел:
- weight – относительный вес сервера
- max_fails – максимальное число таймаутов, после которого сервер
будет помечен как отказавший;
- fail_timeout – время, в течение которого NGINX ждет ответа от
сервера;
- backup – сервер будет задействован, если остальные не отказали;
- down – специальная пометка, которая предотвращает отправку
запросов на этот сервер (например, при плановом обслуживании).
Директива ip_hash предписывает серверу распределять запросы
пользователей исходя из их ip адреса. Могут применяться и другие
алгоритмы распределения: hash, least_conn и least_time (только для nginx
plus). По умолчанию используется циклический алгоритм round robin.
19
Данный блок может быть использован только в секции http
конфигурационного файла. В последствии там, где необходимо ссылаться на
сервера бек-энда, например, в директиве proxy_pass, в качестве имени
сервера или его адреса можно будет использовать http://@app
Во время настройки nginx для достижения целей работы будет
настроен блок upstream к двум серверам бекэнда.
1.2.3. Кэширование контента
Кэширование – один из основных инструментов, позволяющих в
некоторых случаях на порядки увеличить производительность приложений.
Суть кэширования заключается в хранении копии сформированной бек-энд
сервером страницы в виде файла и отдача этой копии при запросе
пользователя. С учетом возможностей Nginx очень эффективно работать со
статическими файлами, кэширование может быть эффективным
инструментом[36].
Nginx предоставляет большие возможности для кэширования
передаваемых данных как от FastCGI, так и от http серверов бек-энда. В
конфигурационном файле кеширование может быть описано в секциях http,
server и location. Основная директива, с помощью которой объявляется кэш –
это proxy_cache_path /PATH keys_zone=NAME:SIZE inactive=TIME. В ней
объявляю
В качестве простого примера приложения, требующего кэширования,
можно привести новостную ленту на каком-либо крупном сайте. Главная
страница ленты обновляется достаточно часто, и важно отдавать ее
пользователям как можно более свежей. Однако она может одновременно
запрашиваться десятками пользователей и если все их запросы передавать на
бек-энд, он будет загружен постоянной генерацией одной и той-же
информации. В данном случае приемлемо кэширование ленты, например, на
3 секунды. Это означает, что только что пришедший на сайт пользователь
получит страницу максимум трехсекундной давности. Если за секунду
20
заходят десятки новых пользователей, то все они, вместо того, чтобы
получить самую новую версию страницы прямо с бек-энда, передав ему свои
запросы и ожидая их обработки, практически мгновенно получат чуть
устаревшую версию из кэша Nginx. Когда, спустя 3 секунды, страница
устареет, один из запросов пользователей будет перенаправлен на бек-энд и
страница в кэше будет обновлена. Чтобы не заставлять ждать и его, у Nginx
существует ряд директив:
proxy_cache_background_update
proxy_cache_use_stale updating timeout errors invalid_headers http_500
http_502 http_503 http_504 http_404 http_429 off;
Первая директива говорит серверу выполнить фоновое обновление
динамической страницы, в то время как вторая позволяет вернуть ему
устаревшую версию во время выполнения запроса[32,40]. Следует отметить,
что срок жизни устаревшей страницы в кэше регулируется параметром
inactive директивы proxy_cache_path. По истечении обозначенного в нем
времени устаревшая страница удаляется из кэша. Само устаревание
определяется директивой expires. Во второй главе будет рассмотрено их
применение.
Если при этом будет добавлена директива proxy_cache_lock,
упомянутая ранее, отправка повторных запросов к серверу за уже
запрошенной страницей будет предотвращено[11].
В работе будет наглядно проиллюстрировано использование
нескольких уровней кэша:
- долгосрочного, для статического содержимого вроде изображений,
скриптов, таблиц стилей и других;
- среднесрочного, для различных страниц, которые меняются не часто;
- быстрого, для кэширования динамических страниц;
21
1.3. Основания для внедрения обратного прокси-сервера
1.3.1. Использование связки php и Apache
Одним из наиболее значимых недостатков веб-сервера Apache является
то, что каждый дополнительный файл, содержащийся на странице,
обрабатывается отдельным запросом[19]. То есть если на странице
расположено 10 изображений, для ее отображения применяются 5 файлов
CSS и подключены 6 различных сценариев JavaScript, то для ее загрузки
сервер должен обработать 1 + 10 + 5 + 6 = 22 запроса. Это будут
полноценные запросы со всеми присущими накладными расходами. Если
много пользователей запрашивают подобные страницы, то количество
одновременных запросов может стать очень большим.
В силу удобства использования в связке с php (Apache использует
модуль, позволяющий с минимальными усилиями взаимодействовать с php
сценариями) и гибкости настройки с помощью файлов .htaccess, которые, как
правило, разрешено редактировать пользователю и менять поведение
сервера, использование Apache в качестве веб-сервера очень
распространено[3,10].
Для исследуемого приложения также используется веб-сервер Apache,
со всеми присущими ему достоинствами и недостатками. Чтобы устранить
перечисленные проблемы, при этом сохранить гибкость настройки и не
вносить изменений в само приложение, можно установить кэширующий
обратный прокси-сервер на базе Nginx[18].
Можно кэшировать как страницы целиком, так и статические файлы,
которые на них присутствуют. Если настроить кэширование изображений,
скриптов и таблиц стилей на длительный срок и периодически производить
валидацию кэша, эти файлы не будут больше запрошены с Apache, если не
будут изменены. Кэшированная страница также будет представлять собой
простой html файл и возвращаться как статика, но здесь есть ряд нюансов
связанных с инвалидацией кэша и поддержанием его в актуальном
состоянии[33,37,38,39]. Этот вопрос будет рассмотрен в последующих