Разработка и производство веб-приложений: краткий обзор

Linux, Ubuntu, VPS | Amber | Комментировать запись

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

Читайте также: 5 вариантов настройки сервера для обслуживания веб-приложения

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

Цели

Выполнив все мануалы данной серии, вы получите сервер производства для приложения PHP и WordPress. В руководствах используется условный домен https://www.example.com/. Также вы сможете настроить дополнительные серверы, которые будут поддерживать сервер производства. Окончательная настройка будет выглядеть примерно так (не учитывая DNS и удаленные резервные копии):

Пользователь
↓
Балансировщик нагрузки
↓                 ↓
Серверы приложений
Сервер 1                Сервер2
↓                          ↓
Сервер баз данных
↓
_______________________
↓            ↓           ↓
Логирование       Мониторинг     Бэкап → План восстановления

В приведенной выше схеме все от балансировщика до сервера баз данных является частью приложения. Ети компоненты необходимы для корректной работы приложения. Остальные компоненты (бэкап, логирование, мониторинг) являются вспомогательными. Каждый компонент устанавливается на отдельный сервер Ubuntu 14.04 с включенной частной сетью.

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

• lb1: балансировщик нагрузки HAProxy, доступный через https://example.com/
• app1: сервер приложений Apache и PHP
• app2: сервер приложений Apache и PHP
• db1: сервер базы данных MySQL

Важно отметить, что этот тип настройки был выбран для демонстрации того, как можно распределить компоненты приложения между несколькими серверами. Не обязательно полностью подгонять среду производства под этот пример: в первую очередь она должна соответствовать требованиям вашего веб-приложения. Кроме того, этот пример установки сервера имеет точки отказа; чтобы устранить их, нужно добавить еще один балансировщик нагрузки (и round-robin DNS), репликацию сервера базы данных или статический IP-адрес, который указывает на активный или пассивный балансировщик нагрузки.

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

• backups: сервер резервного копирования Bacula.
• monitoring: сервер мониторинга Nagios
• logging: стек ELK (Elasticsearch, Logstash, Kibana) для централизованного логирования.

Кроме того, на диаграмме не изображены еще три вспомогательных компонента:

• ns1: первичный BIND-сервер для частного DNS-сервера.
• ns2: вторичный BIND-сервер для частного DNS.
• remotebackups: удаленный сервер для хранения резервных копий Bacula.

Также вы сможете разработать базовый план восстановления сбоев для различных компонентов приложения.

В итоге инфраструктура будет состоять из 10 серверов. Их можно создать заранее (так проще настраивать DNS), но это опционально.

Высокая доступность (опционально)

Единая точка отказа – это компонент инфраструктуры, в случае сбоя которого перестанет работать все приложение. Чтобы устранить единую точку отказа и обеспечить высокую доступность приложения, вы можете добавить еще один балансировщик. Высокодоступные сервисы в случае сбоя автоматически переходят на резервную или пассивную систему. Наличие двух балансировщиков нагрузки в режиме высокой доступности позволяет избежать простоев: пассивный балансировщик нагрузки всегда доступен для приема трафика, если активный прекращает работу.

Существует множество способов реализовать настройку высокой доступности.

Читайте также: Использование плавающих IP-адресов

Виртуальная частная сеть (опционально)

Если вы хотите защитить сетевые взаимодействия между серверами инфраструктуры, можно настроить VPN. Защита сетевых соединений с помощью шифрования особенно важна, если данные передаются через интернет. Другим преимуществом использования VPN является то, что подлинность хостов проверяется процессом аутентификации ключей: это защитит ваше приложение от несанкционированного доступа.

Если вы ищете средство для построения VPN с открытым исходным кодом, можно использовать Tinc или OpenVPN. В этом конкретном случае лучшим вариантом является Tinc, так как эта программа использует mesh-сети.

Читайте также: Установка Tinc и настройка VPN на Ubuntu 14.04

Требования

• Каждый сервер Ubuntu 14.04 должен иметь пользователя с расширенными привилегиями. Узнать больше по этой теме можно в руководстве по начальной настройке сервера.
• Знание базовых понятий безопасности Linux. Больше информации вы найдете здесь.

Доменное имя

В мануалах подразумевается, что приложение обслуживается по доменному имени. В серии используется условный домен example.com.

Домен не только помогает пользователям быстрее найти сайт, но и позволяет защитить сайт с помощью SSL-сертификата.

Сертификаты TLS/SSL

Протоколы TLS/SSL обеспечивают шифрование и подтверждают подлинность домена. В данном примере используется домен www.example.com, он указывается в параметре Common Name (CN). Сертификат устанавливается на сервер HAProxy (хост lb1).

Если вам нужен сертификат, который обеспечит проверку подлинности, вы можете получить бесплатный сертификат SSL с помощью сервиса Let’s Encrypt или приобрести его у коммерческого центра сертификации. Подробнее о сервисе Let’s Encrypt читайте в специальном разделе Информатория.

Также вы можете создать самоподписанный сертификат. Такой сертификат не подтверждает подлинность, но шифрует соединения. Для этого запустите:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crt

Рекомендации по подготовке

Теперь у вас есть общий план установки среды производства приложения.

Компоненты, составляющие приложение, являются самыми важными, поэтому их работу важно обеспечить в первую очередь. Но сначала необходимо настроить DNS.

После настройки DNS нужно настроить серверы приложения в такой последовательности:

• Сервер БД.
• Сервер приложений.
• Балансировщик нагрузки.

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

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

Заключение

Теперь у вас есть план по созданию среды производства приложения. Помните: хотя этот пример предоставит вам полностью рабочую среду производства, в первую очередь вы должны подгонять её под потребности своего приложения.

Вторая часть данной серии посвящена развертыванию.