# Задания ### 1. Установите пакет nginx. ### 2. Запустите исполняемый файл nginx. Проверьте, что он запустился `ps aux`. ### 3. После запуска nginx им можно управлять, вызывая исполняемый файл с параметром -s. Попробуйте команды: - stop — быстрое выключение, - quit — завершение работы с ожиданием завершения обслуживания текущих запросов рабочими процессами, - reload — перезагрузка файла конфигурации, - reopen — повторное открытие лог-файлов, используя следующий синтаксис: ``` $ nginx -s signal ``` Команда должна выполняться под тем же пользователем, который запустил nginx. ### 4. Сигнал также может быть отправлен процессам nginx с помощью инструментов Unix, таких как утилита kill. Идентификатор процесса главного процесса nginx по умолчанию записывается в файл `nginx.pid` в каталоге `/usr/local/nginx/logs` или `/var/run`. Завершите корректно работу nginx командой `kill -s QUIT`. ### 5. Настройте сервис nginx, установленный вместе с пакетом. Активируйте его и запустите командой `systemctl`. ### 6. Nginx состоит из модулей, которые управляются директивами, указанными в файле конфигурации. Директивы делятся на простые директивы и блочные директивы. Простая директива состоит из имени и параметров, разделенных пробелами, и заканчивается точкой с запятой `;`. Блочная директива имеет ту же структуру, что и простая директива, но вместо точки с запятой она заканчивается набором дополнительных инструкций, заключенных в фигурные скобки `{` и `}`. Если директива блока может иметь другие директивы внутри фигурных скобок, она называется контекстом (примеры: `events`, `http`, `server` и `location`). Директивы, размещенные в конфигурационном файле вне каких-либо контекстов, считаются находящимися в основном контексте. События и директивы `http` находятся в основном контексте, сервер — в `http`, а местоположение — в server. Оставшаяся часть строки после знака # считается комментарием. Откройте в любом редакторе файл `/etc/nginx/nginx.conf`, посмотрите настройки по-умолчанию. Обратите внимание, что в блок `http` включаются все файлы из директории `sites-enabled`. ### 7. Запустите команду `tree` для директории `/etc/nginx`. Следующие две директории будут представлять для нас интерес - `sites-available` и `sites-enabled`. Директория sites-available будет содержать наши конфигурации, а `sites-enabled` символические ссылки на них. Конфигурационный файл `sites-available/default` по умолчанию уже включает несколько примеров блока сервера, в основном закомментированных. Удалите ссылку по-умолчанию в папке `sites-enabled` перед следующим заданием. ### 8.1 Важной задачей веб-сервера является отдача статического содержимого (например, изображений или HTML-страниц). Сконфигурируем веб-сервер, в котором, в зависимости от запроса, файлы будут браться из разных локальных каталогов: `/data/www` (HTML-файлы) и `/data/images` (изображения). Для этого отредактируем файл конфигурации, настроем блок сервера внутри блока http, затем настроем два блока местоположения. Создайте каталог `/data/www` и поместите в него файл `index.html` с любым текстовым содержимым, создайте каталог `/data/images` и поместите в него несколько изображений. Далее откройте файл конфигурации `static-server.conf` в `/etc/nginx/sites-available`. Добавьте новый серверный блок: ``` server { } ``` ### 8.2 Файл конфигурации может включать в себя несколько серверных блоков, отличающихся портами, которые они прослушивают, и именами серверов. Как только nginx решает, какой сервер обрабатывает запрос, он проверяет URI, указанный в заголовке запроса, на соответствие параметрам директив местоположения, определенных внутри блока сервера. Добавьте внутрь предыдущего блока блок местоположения: ``` location / { root /data/www; } ``` Этот блок местоположения указывает префикс `/` относительно URI из запроса. Для совпадающих запросов к пути, указанному в корневой директиве, то есть к `/data/www`, будет добавлен URI для формирования пути к запрашиваемому файлу в локальной файловой системе. Если есть несколько совпадающих блоков местоположения, nginx выбирает блок с самым длинным префиксом. Для ссылки http://193.32.63.171/images/1.jpg подходят местоположения `/` и `/images/`. Выбрано будет последнее местоположение. ### 8.3 Добавьте второй блок местоположения: ``` location /images/ { root /data; } ``` Он будет соответствовать запросам, начинающимся с `/images/` (местоположение `/` также соответствует таким запросам, но имеет более короткий префикс). В результате конфигурация блока сервера `static-server.conf` должна выглядеть так: ``` server { location / { root /data/www; } location /images/ { root /data/; } } ``` Это уже рабочая конфигурация сервера, который слушает стандартный порт 80 и доступен на локальной машине по адресу http://localhost/. В ответ на запросы с URI, начинающимися с `/images/`, сервер будет отправлять файлы из каталога `/data/images`. Например, в ответ на запрос http://localhost/images/example.png nginx отправит файл `/data/images/example.png`. Если такого файла не существует, nginx отправит ответ с указанием ошибки 404. Запросы с URI, не начинающимися с `/images/`, будут отображаться в каталоге `/data/www`. Например, в ответ на запрос http://localhost/some/example.html nginx отправит файл `/data/www/some/example.html`. ### 8.4 Скачайте любую картинку в /data/images/: ``` wget -O /data/images/example.jpg https://cdna.artstation.com/p/assets/images/images/052/919/542/large/yucong-tang-0818.jpg?1660995410 ``` Активируйте сервер, создав символическую ссылку на файл конфигурации в директории `sites-enabled`: ``` ln -s /etc/nginx/sites-available/static-server.conf /etc/nginx/sites-enabled/static-server.conf ``` Примените новую конфигурацию, запустите nginx, если он еще не запущен, или отправьте сигнал перезагрузки главному процессу nginx. Проверьте, что веб-сервер работает по адресу 193.32.63.170+X, где X ваши идентификатор. Если что-то не работает должным образом, вы можете попытаться выяснить причину в файлах `access.log` и `error.log` в каталоге `/usr/local/nginx/logs` или `/var/log/nginx`. ### 9.1 Переведите веб-сервер на https. Измените порт прослушивания на `443 ssl`, сгенерируйте сертификаты и ключ командой openssl в директорию `/data/certs/`. Вам понадобятся следующие параметры в блоке server: - listen, - ssl_certificate, - ssl_certificate_key. ``` server { listen 443 ssl; ssl_certificate /data/certs/cert.pem; ssl_certificate_key /data/certs/key.pem; root /data/www; location / { } } ``` ### 9.2 Переведите веб-сервер на https с сертификатом, полученным утилитой `certbot`` от Letsencrypt. ### 10.1 Одним из частых применений nginx является его настройка в качестве прокси-сервера, что означает сервер, который получает запросы, передает их на проксируемые серверы, получает от них ответы и отправляет их клиентам. Настройте базовый прокси-сервер, который обслуживает запросы изображений с файлами из локального каталога и отправляет все остальные запросы на проксируемый-сервер. В этом примере оба сервера будут определены на одном экземпляре nginx. Для усложнения задания попробуйте выполнить задание на двух виртуальных машинах: 10.160.179.10+X для прокси сервера, 10.160.179.10+20+X для сервера с контентом. Сконфигурируйте сеть и установите на 10.160.179.10+20+X nginx. Сначала определите проксируемый сервер (в усложнённом варианте 10.160.179.10+20+X), добавив ещё один блок сервера в файл конфигурации nginx со следующим содержимым: ``` server { listen 80; root /data/www; location / { } } ``` Это будет простой сервер, который прослушивает порт 80 ( директиву listen можно не указывать, если используется стандартный порт 80) и отображает все запросы в каталог `/data/www` локальной файловой системе. Создайте этот каталог и поместите в него файл `index.html` с содержимым "Hello from internal server!". Обратите внимание, что корневая директива находится в контексте сервера. Такая корневая директива используется, когда блок местоположения, выбранный для обслуживания запроса, не включает собственную корневую директиву. ### 10.2 Используйте конфигурацию сервера из предыдущего задания 7 в качестве основы конфигурации прокси-сервера. В первый блок location поместите директиву `proxy_pass` с указанным в параметре протоколом, именем и портом проксируемого сервера (в вашем случае это http://10.160.179.10+X:80): ``` server { location / { proxy_pass http://10.160.179.10+X:80; } location /images/ { root /data; } } ``` ### 10.3 Изменим второй блок местоположения, который в настоящее время сопоставляет запросы с префиксом `/images/` с файлами в каталоге `/data/images`, чтобы он соответствовал запросам изображений с типичными расширениями файлов. Измененный блок местоположения выглядит следующим образом: ``` location ~ \.(gif|jpg|png)$ { root /data/images; } ``` Параметр представляет собой регулярное выражение, соответствующее всем URI, оканчивающимся на `.gif`, `.jpg` или `.png`. Перед регулярным выражением должен стоять символ тильда `~`. Соответствующие запросы будут сопоставлены с каталогом `/data/images`. Когда nginx выбирает блок местоположения для обслуживания запроса, он сначала проверяет директивы местоположения, которые указывают префиксы, запоминая местоположение с самым длинным префиксом, а затем проверяет регулярные выражения. Если есть совпадение с регулярным выражением, nginx выбирает это местоположение или, в противном случае, выбирает то, которое было запомнено ранее. ### 10.4 В результате конфигурация прокси-сервера будет выглядеть так: ``` server { location / { proxy_pass http://10.160.179.10+20+X:80/; } location ~ \.(gif|jpg|png)$ { root /data/images; } } ``` Этот сервер будет фильтровать запросы, оканчивающиеся на `.gif`, `.jpg` или `.png`, и сопоставлять их с каталогом `/data/images` (путем добавления URI к параметру корневой директивы). Все остальные запросы будут передаваться на сервер, настроенный выше. Чтобы применить новую конфигурацию, отправьте сигнал перезагрузки в nginx, как описано в предыдущих разделах. Проверьте, что прокси сервер работает по адресу 193.32.63.170+X и возвращает как html с проксируемого сервера (10.160.179.10+20+X), так и изображения с собственной машины (10.160.179.10+20+X).