1. Вступление
2. Предпосылки
3. Настройка прокси
4. Тестирование прокси
5. Настройка кеширования
6. Тестирование кеша
7. Настройка TLS / SSL
8. Заключение

Примечание. За время, прошедшее с момента публикации этого руководства, DigitalOcean Spaces добавила бесплатную опцию CDN с настраиваемыми поддоменами конечных точек. Эта функция CDN обеспечивает большинство функций, описанных ниже, включая кэширование, настраиваемые домены, SSL и перемещение ресурсов ближе к вашим пользователям.

Пожалуйста, прочитайте официальная документация по продуктам Spaces для получения информации о том, как включить CDN а также настроить конечную точку CDN ,

Вступление

DigitalOcean Spaces является хранение объектов сервис, который совместим с S3 API. В этом уроке мы покажем вам, как использовать Nginx для прокси-запросов на объекты в вашем Пространстве. Nginx будет получать запросы HTTP (S) от ваших пользователей и передавать их службе Spaces, которая отправит результаты обратно через Nginx.

Некоторые причины, по которым вы можете захотеть разместить прокси Nginx перед Spaces:

• добавить пользовательский домен
• добавить свой собственный кеширование
• используйте свой собственный сертификат SSL
• использовать разные механизмы контроля доступа
• кэшировать ресурсы в центре обработки данных, который ближе к вашим пользователям

В этом руководстве мы настроим Nginx для ответа на запросы в нашем собственном домене (с дополнительными SSL-сертификатами Let's Encrypt) и перенаправляем эти запросы в пространство с открытыми ресурсами. Затем мы добавим кеширование, чтобы ускорить последующие ответы для часто используемых объектов.

Предпосылки

Чтобы пройти этот урок, у вас должно быть следующее:

• Сервер Ubuntu 16.04 с установленным Nginx, как описано в нашем руководстве Как установить Nginx на Ubuntu 16.04
• Доменное имя, указанное на вашем сервере, согласно Как настроить имя хоста с помощью DigitalOcean , Мы будем использовать assets.example.com в этом руководстве

• DigitalOcean Space. Вы можете узнать, как создать новое пространство, прочитав Введение в DigitalOcean Spaces ,

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

  

  Вам также понадобится файл, загруженный в ваш Space для проверки. Вышеупомянутая статья Spaces показывает, как вы можете загружать файлы с помощью веб-интерфейса Spaces. Мы будем использовать example.png для этого урока.

Настройка прокси

Установка Nginx по умолчанию в Ubuntu вернет страницу-заполнитель Welcome to Nginx для всех запросов. Нам нужно добавить новую конфигурацию, чтобы Nginx делал что-то еще с запросами к нашему домену.

Для этого откройте новый файл конфигурации в / etc / nginx / sites-available:

• sudo nano / etc / nginx / sites-available / assets.example.com

Это откроет пустой файл в текстовом редакторе Nano. Вставьте следующую конфигурацию, убедившись, что выделенные части заменены на ваше собственное доменное имя и URL пробелов:

/etc/nginx/sites-available/assets.example.com

сервер {слушай 80; слушать [::]: 80; имя_сервера assets.example.com; location / {proxy_pass https://example.nyc3.digitaloceanspaces.com/; proxy_hide_header Strict-Transport-Security; }}

Сохраните файл и выйдите из редактора, когда закончите. Это стандартный серверный блок Nginx. Сначала мы говорим ему прослушивать порт 80 на IPv4 и IPv6 и указывать имя_сервера, на которое Nginx должен отвечать.

Далее мы создаем блок местоположения. Все директивы конфигурации в этом блоке (между фигурными скобками {и}) будут применяться только к определенным URL-адресам. В этом случае мы указываем /, корневой URL-адрес, поэтому этот блок будет сопоставлять все местоположения.

Директива proxy_pass указывает Nginx передавать запросы на указанный сервер. Строка proxy_hide_header удаляет заголовок Strict-Transport-Security перед передачей ответа клиенту. Пробелы используют этот заголовок для принудительного подключения всех соединений к HTTPS. Передача этого заголовка вашим пользователям может иметь непредвиденные последствия, если ваш сайт доступен как по HTTP, так и по HTTPS-соединениям.

Теперь, когда наша конфигурация установлена, нам нужно ее включить. Это делается путем создания ссылки на файл конфигурации в каталоге / etc / nginx / sites-enabled /:

• sudo ln -s / etc / nginx / sites-available / assets.example.com / etc / nginx / sites-enabled /

Чтобы проверить наш синтаксис конфигурации, запустите nginx -t от имени пользователя root:

Выход

nginx: файл конфигурации /etc/nginx/nginx.conf в порядке. nginx: файл конфигурации /etc/nginx/nginx.conf успешно пройден

Наконец, перезагрузите Nginx, чтобы выбрать новую конфигурацию:

• sudo systemctl перезагрузить nginx

С нашим настроенным файлом конфигурации давайте протестируем прокси.

Тестирование прокси

Мы можем проверить прокси-соединение, используя curl в командной строке. curl -I вернет только HTTP-заголовки ответа. Этого достаточно, чтобы определить, что все работает хорошо.

Сначала извлеките объект прямо из своего пространства, используя URL-адрес digitaloceanspaces.com . Мы будем использовать наш файл example.png:

• curl -I https://example.nyc3.digitaloceanspaces.com/example.png

Выход

HTTP / 1.1 200 OK Длина содержимого: 81173 Диапазон принятия: байты Последнее изменение: вторник, 28 ноября 2017 г. 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx000000000000000002398-005a1edfcdbaa Content-Type: image / png Дата: среда, 29 ноя. 2017 16:26:53 GMT Строгая транспортная безопасность: max-age = 15552000; IncludeSubdomains; предварительная нагрузка

По 200 OK в первой строке вывода мы видим, что это был успешный запрос. Сервер вернул размер файла (Content-Length), тип файла (Content-Type) и некоторую другую информацию, связанную с датой и кэшем.

Теперь загрузите тот же файл через прокси:

• curl -I http://assets.example.com/example.png

Выход

HTTP / 1.1 200 OK Сервер: nginx / 1.10.3 (Ubuntu) Дата: среда, 29 ноября 2017 г. 16:27:24 GMT Тип контента: image / png Длина контента: 81173 Соединение: keep-alive Принять-диапазоны: байты Последнее изменение: вторник, 28 ноября 2017 г. 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx00000000000000000a045-005a1edfec-a89a3-nyc3a

Ответ в основном одинаков. Основным изменением является заголовок сервера, который идентифицирует Nginx. Если ваш вывод похож, ваш прокси работает правильно!

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

Настройка кеширования

Для кэширования ответов Nginx требуется место для хранения ключей, метаданных и фактического содержимого ответа. Мы создадим каталог кеша в системном каталоге / tmp. Для этого мы добавим фрагмент конфигурации в новый файл в /etc/nginx/conf.d/. Откройте этот файл сейчас:

• sudo nano /etc/nginx/conf.d/example-cache.conf

Вставьте следующую строку, затем сохраните и закройте файл:

/etc/nginx/conf.d/example-cache.conf

proxy_cache_path / tmp / example-cache / level = 1: 2 keys_zone = example-cache: 16m max_size = 10g неактивно = 60m use_temp_path = off;

Эта строка определяет несколько характеристик кеша. Давайте рассмотрим варианты:

• / tmp / example-cache / - это путь к кешу.
• level = 1: 2 устанавливает двухуровневую иерархию каталогов для хранения кэшированного содержимого. Помещение слишком большого количества файлов в один каталог может вызвать проблемы со скоростью и надежностью, поэтому Nginx будет разделять файлы между несколькими каталогами на основе этой опции.
• keys_zone = example-cache: 16m именует наш кэш и устанавливает 16 мегабайт памяти для хранения ключей. Этого должно быть достаточно для хранения данных для более чем 100 000 ключей.
• max_size = 10g ограничивает размер кэша до 10 гигабайт. Вы можете настроить это в соответствии с вашими потребностями хранения и использования.
• inactive = 60m означает, что Nginx удалит кэшированные файлы через 60 минут, если к ним не было доступа в это время (даже если файл все еще действителен и не имеет срока действия). Если у вас есть много редко используемых объектов, вы можете попробовать увеличить это.
• use_temp_path = off предписывает Nginx записывать временные файлы в каталог кэша, что потенциально исключает необходимость копирования файлов между файловыми системами, что может снизить производительность.

Теперь, когда мы определили кэш, нам нужно включить его в нашем блоке сервера и установить некоторые дополнительные параметры. Снова откройте файл конфигурации вашего сайта:

• sudo nano / etc / nginx / sites-available / assets.example.com

Добавьте следующее в конец вашего местоположения / блока (после директивы proxy_hide_header, но до закрывающей скобки}):

/etc/nginx/sites-available/assets.example.com

, , , proxy_cache example-cache; proxy_cache_valid 200 60m; тайм-аут ошибки proxy_cache_use_stale обновление http_500 http_502 http_503 http_504; proxy_cache_revalidate on; proxy_cache_lock on; proxy_ignore_headers Set-Cookie; add_header X-Cache-Status $ upstream_cache_status; , , ,

Сохраните и закройте файл. Давайте пройдемся по этим параметрам конфигурации по очереди:

• proxy_cache сообщает Nginx, какой кеш использовать. В этом случае мы указываем example-cache, который мы только что установили в файле example-cache.conf.
• proxy_cache_valid инструктирует Nginx считать любой ответ 200 действительным в течение 60 минут. Это означает, что после того, как прокси-сервер успешно выберет файл из Spaces, в течение следующих 60 минут Nginx будет использовать кэшированную копию, даже не запрашивая обновления у Spaces. Обратите внимание, что если у ваших объектов установлен заголовок Cache-Control, значение заголовка переопределит эту конфигурацию.
• proxy_cache_use_stale позволяет Nginx возвращать устаревший (просроченный) ответ, если время на сервере Spaces истекает, возвращается ошибка или если кэшированный ответ находится в процессе обновления.
• proxy_cache_revalidate позволяет прокси-серверу повторно проверять кэшированные файлы, используя условные запросы GET . Это означает, что когда срок действия кэшированного файла истекает, а Nginx необходимо проверять пробелы на наличие изменений, Nginx будет использовать заголовки If-Modified-Since или If-None-Match для выборки объекта, только если он действительно изменился. Если он не был обновлен, Spaces вернет ответ 304 Not Modified, а Nginx просто пометит существующий кэшированный ответ как снова действительный.
• proxy_cache_lock блокирует последующие запросы к объекту, когда прокси-сервер уже получает его с внутреннего сервера. Когда первый запрос будет выполнен, остальные запросы будут обслуживаться из кэша.
• proxy_ignore_headers Set-Cookie игнорирует файлы cookie, которые могут помешать кешированию.
• add_header X-Cache-Status ... добавляет заголовок с информацией о том, обслуживался ли запрос из кэша (HIT) или нет (MISS). Если запрос был в кеше, но срок его действия истек, вместо этого вы увидите (REVALIDATED).

Теперь мы готовы проверить, что в нашей конфигурации нет ошибок, и в случае успеха перезагрузите Nginx:

• sudo nginx -t
• sudo systemctl перезагрузить nginx

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

Тестирование кеша

Чтобы убедиться, что кеш работает, мы можем снова использовать curl и искать заголовок X-Cache-Status:

• curl -I http://assets.example.com/example.png

Выход

HTTP / 1.1 200 OK Сервер: nginx / 1.10.3 (Ubuntu) Дата: среда, 29 ноября 2017 18:40:28 GMT Тип контента: image / png Длина контента: 81173 Соединение: keep-alive Последнее изменение: Вторник , 28 ноября 2017 21:19:37 GMT ETag: «7b2d05a5bd1bfeebcac62990daeafd14» x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a Статус X-Cache: диапазоны MISS Accept-bytes: bytes

Первый запрос должен быть MISS. Попробуйте второй раз:

• curl -I http://assets.example.com/example.png

Выход

HTTP / 1.1 200 OK Сервер: nginx / 1.10.3 (Ubuntu) Дата: среда, 29 ноября 2017 18:40:53 GMT Тип контента: image / png Длина контента: 81173 Соединение: keep-alive Последнее изменение: Вторник , 28 ноября 2017 21:19:37 GMT ETag: "7b2d05a5bd1bfeebcac62990daeafd14" x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a X-Cache-Status: HIT Accept-Ranges: байты

УДАР! Теперь мы проксируем и кешируем объекты из Spaces. На следующем шаге мы настроим SSL-сертификаты для безопасной связи с нашим прокси.

Настройка TLS / SSL

Хотя этот шаг не является обязательным, настоятельно рекомендуется, чтобы ваш веб-сайт и ресурсы были доступны через безопасное соединение HTTPS. Вы можете узнать, как загрузить и установить бесплатные сертификаты из центра сертификации Let's Encrypt, прочитав наш учебник Как настроить Давайте зашифруем с помощью блоков серверов Nginx в Ubuntu 16.04 ,

Заключение

В этом руководстве мы создали конфигурацию Nginx для прокси-запросов на объекты к службе Spaces. Затем мы добавили кеширование для повышения производительности и сертификат TLS / SSL для улучшения конфиденциальности и безопасности.

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