TOC

Как прокси-серверы DigitalOcean с Nginx в Ubuntu 16.04

Вступление

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

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

  • добавить пользовательский домен

  • добавить свой собственный кеширование

  • используйте свой собственный сертификат SSL

  • использовать разные механизмы контроля доступа

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

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

Предпосылки

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

  • Сервер Ubuntu 16.04 с установленным Nginx, как описано в нашем руководстве Как установить Nginx в Ubuntu 16.04

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

  • DigitalOcean Space. Вы можете узнать, как создать новое Пространство, прочитав An Введение в DigitalOcean Spaces. + Вам нужно знать URL вашего индивидуального пространства. Вы можете найти это, перейдя к своему Пространству в Панели управления DigitalOcean. URL-адрес находится непосредственно под именем пробела в пользовательском интерфейсе. Это выделено на снимке экрана ниже: + image: https: //assets.digitalocean.com/articles/proxy-spaces/space-shot.png [Пользовательский интерфейс DigitalOcean Spaces с выделенным URL-адресом пространства. URL-адрес находится непосредственно под именем пробела в заголовке пользовательского интерфейса] + Вам также понадобится файл, загруженный в вашу пробел, чтобы проверить что-либо. Вышеупомянутая статья Spaces показывает, как вы можете загружать файлы с помощью веб-интерфейса Spaces. Мы будем использовать + example.png + для этого урока.

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

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

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

sudo nano /etc/nginx/sites-available/

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

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

server {
   listen 80;
   listen [::]:80;
   server_name ;

   location / {
       proxy_pass ;
       proxy_hide_header      Strict-Transport-Security;
   }
}

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

Затем мы создаем блок + location +. Любые директивы конфигурации в этом блоке (между фигурными скобками + {+ и +} +) будут применяться только к определенным 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/ /etc/nginx/sites-enabled/

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

sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl reload nginx

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

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

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

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

curl -I
OutputHTTP/1.1 200 OK
Content-Length: 81173
Accept-Ranges: bytes
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000002398-005a1edfcd-afba2-nyc3a
Content-Type: image/png
Date: Wed, 29 Nov 2017 16:26:53 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

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

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

curl -I
OutputHTTP/1.1 200 OK

Date: Wed, 29 Nov 2017 16:27:24 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Accept-Ranges: bytes
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx00000000000000000a045-005a1edfec-a89a3-nyc3a

Ответ в основном одинаков. Основным изменением является заголовок + Server +, который идентифицирует 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/ levels=1:2 keys_zone=example-cache:16m max_size=10g inactive=60m use_temp_path=off;

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

  • + / tmp / example-cache / + - это путь к кешу.

  • + levels = 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/

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

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

. . .
       proxy_cache            example-cache;
       proxy_cache_valid      200 60m;
       proxy_cache_use_stale  error timeout updating 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 + позволяет прокси-серверу повторно проверять кэшированные файлы, используя conditional GET запросы. Это означает, что когда срок действия кэшированного файла истекает, и Nginx необходимо проверять пробелы на наличие изменений, Nginx будет использовать заголовки + If-Modified-Since + или + If-None-Match +, чтобы извлекать объект, только если он действительно изменился , Если он не был обновлен, Spaces вернет ответ «+304 Не изменен +», а Nginx просто пометит существующий кэшированный ответ как снова действительный.

  • + proxy_cache_lock + блокирует последующие запросы к объекту, когда прокси уже извлекает его с внутреннего сервера. Когда первый запрос будет выполнен, остальные запросы будут обслуживаться из кэша.

  • + proxy_ignore_headers Set-Cookie + игнорирует куки, которые могут помешать кешированию.

  • + add_header X-Cache-Status …​ + добавляет заголовок с информацией о том, обслуживался ли запрос из кэша (+ HIT +) или нет (+ MISS +). Если запрос был в кеше, но срок его действия истек, вместо этого вы увидите (+ REVALIDATED +).

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

sudo nginx -t
sudo systemctl reload nginx

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

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

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

curl -I
OutputHTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 29 Nov 2017 18:40:28 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a

Accept-Ranges: bytes

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

curl -I
OutputHTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 29 Nov 2017 18:40:53 GMT
Content-Type: image/png
Content-Length: 81173
Connection: keep-alive
Last-Modified: Tue, 28 Nov 2017 21:19:37 GMT
ETag: "7b2d05a5bd1bfeebcac62990daeafd14"
x-amz-request-id: tx000000000000000013841-005a1eff1b-a89e4-nyc3a

Accept-Ranges: bytes

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

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

Хотя этот шаг не является обязательным, настоятельно рекомендуется, чтобы ваш веб-сайт и ресурсы были доступны через безопасное соединение HTTPS. Вы можете узнать, как загрузить и установить бесплатные сертификаты из центра сертификации Let’s Encrypt, прочитав наш учебник https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with- nginx-server-blocks-on-ubuntu-16-04 [Как настроить Давайте зашифруем с помощью блоков серверов Nginx в Ubuntu 16.04].

Заключение

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

Настройки, показанные здесь, являются хорошей отправной точкой, но вы можете оптимизировать некоторые параметры кэша на основе ваших собственных уникальных моделей трафика и потребностей. Https://nginx.org/en/docs/[Nginx document], в частности ngxhttpproxy_module, может предоставить более подробную информацию о доступных параметрах конфигурации ,

Related