Практическая работа №13 по размещению статического контента сводится к четырём действиям: подготовить файлы сайта, положить их в каталог веб-сервера, описать этот каталог в конфиге и убедиться, что страница открывается по URL. Базы данных, бэкенд и языки программирования в задании не участвуют: сервер возвращает браузеру готовый index.html как есть.
Проверяемый результат один: по адресу http://IP-адрес или http://имя-домена открывается ваша страница, а команда curl -I в терминале показывает код 200 OK. Остальные пункты отчёта служат доказательством того, что вы понимаете, откуда взялся этот результат.
Формулировки задания в разных учебных заведениях отличаются, смысл остаётся одинаковым. Работать можно в виртуальной машине с Ubuntu или Debian, в контейнере Docker, а при отсутствии ПК в Termux на Android. Готовой методички именно по этой работе в собранных источниках нет, поэтому последовательность ниже построена на общепринятой практике администрирования Nginx: сверяйте пути, имя домена и требования к отчёту с заданием своего преподавателя.
Что требуется в практической работе №13 по размещению статического контента
Типовое задание состоит из трёх проверяемых блоков. Первый: на сервере создан каталог с файлами сайта, где есть как минимум index.html. Второй: веб-сервер настроен на отдачу файлов из этого каталога, конфиг проходит проверку синтаксиса. Третий: сайт доступен по URL, что подтверждается выводом curl и скриншотом браузера. Отчёт с командами и их выводом закрывает четвёртый, формальный блок.
Критерии сдачи: что проверит преподаватель
- Рабочий URL: страница открывается в браузере, в адресной строке виден IP-адрес или домен.
- Код ответа 200 OK с локального и внешнего адреса, без 403 и 404.
- Конфиг Nginx с корректным server block: директивы listen, server_name, root, index, location.
- Вывод команды sudo nginx -t: syntax is ok, test is successful.
- Скриншоты терминала с командами и результатом, а не пересказ действий.
- Раздел с пояснением, что делает каждая директива и каждая команда.
Работу чаще всего возвращают на доработку в двух случаях: сайт открывается по http://localhost, но не открывается с другой машины, и в отчёте нет доказательств проверки прав доступа. Оба пункта закрываются за пять минут, если проверить их до сдачи.
Какие инструменты понадобятся
- Виртуальная машина с Ubuntu 22.04/24.04 LTS или Debian 12, доступ по SSH либо через консоль гипервизора.
- Nginx из штатного репозитория пакетов и права sudo.
- Текстовый редактор nano или vim.
- curl для проверки HTTP-ответов и любой браузер для скриншота.
- Для контейнерного варианта: Docker и плагин Docker Compose.
- Для варианта на роутере: устройство MikroTik с RouterOS v7.
Команды установки и первичной настройки виртуального хоста собраны в статье быстрая установка и базовая настройка Nginx на Ubuntu 22.04/24.04 LTS. Если вы впервые работаете в Linux, начните с практического руководства по Linux для IT-специалистов: там разобраны apt, работа с файловой системой и сетевые настройки, без которых дальнейшие шаги выглядят набором магии.
Termux на Android пригодится как вспомогательная среда: подготовить файлы, увидеть, как выглядит отдача статики, потренироваться в командной строке. Полноценный веб-сервер для отчёта разворачивайте на Linux.
Подготовка статических файлов и структуры каталогов
Рабочая схема каталогов для одного сайта: /var/www/имя-сайта/html. Внутри html лежат index.html, стили, изображения и шрифты. Каталог html становится документным корнем (document root): именно от него Nginx отсчитывает путь из URL, поэтому запрос /about.html превращается в файл /var/www/example.com/html/about.html.
Создание index.html и проверка прав
sudo mkdir -p /var/www/example.com/html sudo chown -R $USER:$USER /var/www/example.com/html sudo chmod -R 755 /var/www nano /var/www/example.com/html/index.html
Минимальное содержимое страницы, которого достаточно для сдачи:
<!DOCTYPE html> <html lang="ru"> <head> <meta charset="utf-8"> <title>Практическая работа №13</title> </head> <body> <h1>Статический контент размещён</h1> <p>Страница отдаётся веб-сервером Nginx.</p> </body> </html>
Права доступа разбираются просто. Каталоги получают 755: владелец читает, пишет и заходит, остальные читают и заходят. Файлы получают 644: владелец читает и пишет, остальные только читают. Рабочие процессы Nginx отдают файлы от пользователя, заданного директивой user; в стандартной конфигурации Ubuntu это www-data, и при необходимости его можно изменить на другого пользователя. Поэтому каталог не должен быть закрыт от посторонних: если убрать у www-data право на чтение или на вход в каталог, сервер не сможет открыть файл и вернёт ошибку доступа.
Проверка:
ls -l /var/www/example.com/html namei -l /var/www/example.com/html/index.html
namei показывает права на каждом уровне пути. Если хотя бы один каталог в цепочке закрыт для www-data, сайт не откроется.
На CentOS, RHEL, Fedora и AlmaLinux добавьте контекст SELinux, иначе Nginx получит отказ на чтение файла при формально верных правах Unix. Каталогу назначается тип httpd_sys_content_t, после чего выполняется restorecon:
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com/html(/.*)?" sudo restorecon -Rv /var/www/example.com/html
Если веб-приложение должно писать в каталог (загрузки, кэш, временные файлы, сессии), ему назначают тип httpd_sys_rw_content_t. Для чистой статики это не требуется.
Разбор кодов 401, 403, 404 и 502 с командами диагностики есть в статье права доступа к данным в Nginx: аутентификация и контроль. Она полезна, если преподаватель просит закрыть часть статики паролем или ограничить доступ по IP.
Вариант для Docker: монтирование статики в контейнер
Если Nginx ставить на хост не хочется, статика монтируется в официальный образ:
docker run -d --name my-nginx -p 80:80 -v /var/www/example.com/html:/usr/share/nginx/html:ro nginx
Флаг ro запрещает контейнеру запись в каталог, для статики этого достаточно. На хостах с SELinux к опции монтирования добавляют суффикс :z или :Z: эти суффиксы указывают Docker выполнить relabel файловых объектов на общем томе, то есть настроить SELinux-разметку. Без такой разметки контейнер может не получить доступ к файлам:
-v /var/www/example.com/html:/usr/share/nginx/html:ro,z
Требования к правам на хосте здесь мягче, но каталог должен быть читаем для процессов внутри контейнера. Порт 80 на хосте должен быть свободен: если Nginx уже установлен системно, остановите его либо публикуйте контейнер на 8080.
Настройка Nginx для статического контента
В Ubuntu и Debian конфиги сайтов держат в /etc/nginx/sites-available, а активные включают символической ссылкой в /etc/nginx/sites-enabled. В семействе RHEL используют /etc/nginx/conf.d с файлами вида имя.conf. Оба подхода равнозначны, различается только раскладка файлов.
Базовый конфиг server block
sudo nano /etc/nginx/sites-available/example.com
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Что делает каждая строка:
- listen 80 принимает HTTP-запросы на порту 80 всех интерфейсов.
- server_name сопоставляет запрос с доменом по заголовку Host. Для лабораторной работы допустимо указать IP-адрес или оставить подчёркивание как значение по умолчанию.
- root задаёт документный корень, от которого строятся все пути.
- index называет файл, отдаваемый при запросе каталога без имени файла.
- location / обрабатывает все запросы, а try_files проверяет файл, затем каталог и при промахе возвращает 404 вместо невнятной ошибки.
Активация сайта и удаление дефолтной заглушки:
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ sudo rm /etc/nginx/sites-enabled/default
Если оставить стандартный конфиг включённым, по IP-адресу вы увидите страницу Welcome to nginx вместо своей. Причина в том, что для запроса без совпадения по server_name срабатывает сервер по умолчанию, обычно это default.
Проверка синтаксиса и перезагрузка
sudo nginx -t sudo systemctl reload nginx
Успешная проверка выглядит так:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Команда reload перечитывает конфиг без разрыва уже установленных соединений, в отличие от restart. Для учебного стенда разница не критична, в рабочей среде reload безопаснее. Если nginx -t вернул ошибку, в выводе указаны файл и номер строки: начинайте правку с них, а не с переустановки пакета.
Проверка доступности сайта по URL
Локальная проверка: curl и браузер
curl -I http://localhost curl http://localhost
Ожидаемый ответ на первую команду:
HTTP/1.1 200 OK Server: nginx/1.24.0 Content-Type: text/html Content-Length: 245
Код 200 означает успех, Content-Type: text/html подтверждает, что файл определён как HTML. Вторая команда без флага -I печатает тело страницы. Если домен в конфиге отличается от localhost, проверьте адресацию через заголовок Host:
curl -I -H 'Host: example.com' http://127.0.0.1
Скриншот браузера с открытой страницей делайте так, чтобы в кадр попала адресная строка целиком.
Проверка извне и настройка firewall
Узнайте адрес машины командой ip -4 addr show и проверьте сайт с другого компьютера в той же сети. На Ubuntu порт 80 открывается правилом:
sudo ufw allow 80/tcp sudo ufw status
Если с локальной машины сайт открывается, а извне нет, ищите причину в трёх местах: правило файрвола, режим сети виртуальной машины (NAT без проброса портов не пускает входящие подключения, bridged пускает) и настройки NAT на роутере. Для MikroTik проверка выполняется со стороны самого устройства:
/tool fetch url=http://IP-адрес-сервера
Строка status: finished в выводе означает, что сервер ответил на запрос.
Коды ответов при диагностике: 200 успех, 301 и 302 перенаправление, 403 права или SELinux, 404 неверный root либо отсутствие файла, 502 Nginx не смог связаться с бэкендом (в этой работе он не появляется, но встречается, если добавить проксирование). Алгоритм поиска проблем с маршрутизацией запросов, логированием и приоритетом location-блоков разобран в статье отладка маршрутизации Nginx: логирование, проверка location и устранение ошибок.
Типичные ошибки и как их исправить
| Симптом | Причина | Что проверить |
|---|---|---|
| 403 Forbidden | Нет прав на чтение файла или каталога, закрыт один из уровней пути, запрет SELinux | ls -l, namei -l, ls -lZ, запись avc: denied в /var/log/audit/audit.log |
| 404 Not Found | root указывает не на тот каталог, файла нет, ошибка в имени index-файла | grep root в конфиге, ls в каталоге, имя файла с учётом регистра |
| Welcome to nginx | Активен сервер по умолчанию, ваш конфиг не включён | ls -l /etc/nginx/sites-enabled, наличие симлинка на ваш файл |
| nginx: [emerg] | Синтаксическая ошибка: пропущена точка с запятой, незакрытая скобка, лишний пробел | nginx -t, номер строки из вывода, nginx -T для полного дампа конфигов |
| Изменения не применились | Конфиг сохранён, но сервис не перечитал файлы | systemctl reload nginx, systemctl status nginx |
| В контейнере пустая страница | Неверный путь монтирования или блокировка SELinux | docker logs my-nginx, docker exec my-nginx ls /usr/share/nginx/html, суффикс :z в опции -v |
Основной источник деталей: журнал ошибок веб-сервера. Две команды дают почти всю нужную информацию:
sudo tail -n 50 /var/log/nginx/error.log sudo nginx -T | less
Систематический разбор прав доступа, виртуальных хостов, PHP-FPM и SELinux с готовыми командами приведён в статье диагностика и устранение ошибок веб-сервера: 403, 404, 500 и проблемы виртуальных хостов.
Оформление отчёта и скриншоты для защиты
Шаблон отчёта
- Цель работы: разместить статический контент на веб-сервере и обеспечить доступ по URL.
- Используемое ПО: версия ОС, версия Nginx из nginx -v, при необходимости версия Docker.
- Исходные данные: IP-адрес сервера, домен или имя хоста, путь к документному корню.
- Выполнение: пошагово команды и содержимое конфига, каждая команда с кратким пояснением.
- Результаты проверки: вывод nginx -t, вывод curl -I, скриншот браузера.
- Затруднения и их решение: опишите ошибку, команду диагностики и что помогло.
- Вывод: сформулируйте, что обеспечивает отдачу статики и как вы это подтвердили.
Список обязательных скриншотов
- Создание каталога и файла index.html, виден путь.
- Права доступа: вывод ls -l по каталогу и файлу.
- Полный текст конфига Nginx в редакторе.
- Вывод sudo nginx -t с сообщением test is successful.
- Вывод curl -I с кодом 200 OK и заголовком Content-Type.
- Браузер с открытой страницей, в кадре адресная строка с URL.
Для контейнерного варианта добавьте вывод docker ps и docker logs, для варианта на роутере скриншот вывода /tool fetch или веб-интерфейса. Скриншоты должны читаться: не обрезайте URL и путь к файлу, увеличивайте шрифт терминала до сдачи, а не после замечания.
Адаптация инструкции под свою среду: Docker, MikroTik, Termux
Шаги выше воспроизводятся почти без изменений в любой среде, где есть Linux и веб-сервер. Ниже короткие варианты для случаев, когда виртуальной машины с Ubuntu под рукой нет.
Docker: Nginx в контейнере
Конфиг по умолчанию в образе nginx уже отдаёт файлы из /usr/share/nginx/html, поэтому достаточно смонтировать туда свою статику и опубликовать порт. Проверка та же: curl -I http://localhost должен вернуть 200 OK. Полезные команды: docker ps подтверждает, что контейнер запущен, docker logs my-nginx показывает ошибки старта, docker exec my-nginx nginx -t проверяет ваш конфиг, если он добавлен внутрь через дополнительный volume. При обновлении файлов на хосте перезапуск контейнера не нужен: изменения видны сразу, потому что каталог смонтирован.
MikroTik RouterOS v7: встроенный веб-сервер
RouterOS v7 умеет запускать контейнеры: это реализация Linux-контейнеров, позволяющая запускать контейнеризованные окружения внутри RouterOS, и функция работает в актуальных версиях RouterOS v7.x. Контейнеры совместимы с образами из Docker Hub, GCR, Quay и других провайдеров, а также собранными на других устройствах в поддерживаемых этими провайдерами форматах. Важное ограничение: по умолчанию поддержка контейнеров отключена, и для её включения нужен физический доступ к устройству.
При этом штатные механизмы RouterOS рассчитаны на задачи самого роутера и не заменяют Nginx: привычной раскладки виртуальных хостов, как в конфигах Nginx, здесь нет, а возможности встроенного веб-сервера ограничены. Для учебной работы это допустимо, если преподаватель засчитывает любой работающий веб-сервер, но для полноценного сайта надёжнее вынести статику на Linux VM и оставить роутеру маршрутизацию. Проверка доступности с самого устройства выполняется командой /tool fetch url=http://адрес, успешный ответ отображается как status: finished.
Типовой сценарий, где Linux VM и MikroTik работают в связке, описан в проекте The333-bgp: ему нужна Linux VM с Ubuntu или Debian и systemd, заранее установленные Docker и плагин Docker Compose либо возможность их поставить, статический IPv4 для VM и MikroTik с RouterOS v7. Минимальный объём памяти 1 ГБ, рекомендуется 2 ГБ и больше. Для быстрой установки готовых образов требуется 2 ГБ свободного места при готовом Docker или 3 ГБ, если установщик должен поставить Docker, рекомендуется 4 ГБ и выше. Для резервной сборки из исходников нужно 4 ГБ при готовом Docker или 5 ГБ вместе с установкой Docker, рекомендуется 6-8 ГБ. Виртуальной машине нужен доступ в Интернет для загрузки образов и списков маршрутов. Страница проекта The333-bgp на GitHub подтверждает, что конфигурация рабочая: стенд на отдельной VM в локальной сети публикует маршруты в MikroTik больше месяца, а готовые GHCR-образы дополнительно проверяются автоматической чистой установкой. К практической работе №13 этот проект отношения не имеет, он приведён как пример требований к инфраструктуре вокруг Docker и RouterOS.
Termux: подготовка файлов и запуск простого сервера
Termux это приложение-терминал и одновременно минимальная Linux-подобная среда для Android: после установки появляется командная строка, пакетный менеджер, домашний каталог и набор инструментов, знакомых пользователям Debian, Ubuntu, Fedora или Arch Linux, как описано в руководстве по установке Linux на Android через Termux. Команды выполняются в пользовательском пространстве Android, а не в виртуальной машине, поэтому запуск быстрый. Ограничение тоже важно: Termux использует ядро Android и не даёт полного контроля над драйверами, сетевыми интерфейсами и системными службами, поэтому как основной веб-сервер для отчёта он не подходит.
Практический сценарий без ПК: подготовить index.html в домашнем каталоге Termux и отдать его простым HTTP-сервером.
pkg install python mkdir -p ~/site nano ~/site/index.html cd ~/site python -m http.server 8080
Проверка с того же устройства:
curl -I http://localhost:8080
Порт 8080 выбран как непривилегированный: в Android привилегированные порты вроде 80 требуют root, а Nginx в Termux не стартует на порту 80 даже при наличии root-доступа. Такой сервер отдаёт статику и годится для демонстрации самой механики, но конфига Nginx и проверки nginx -t в нём нет, а именно эти пункты чаще всего фигурируют в критериях сдачи. Если нужен полноценный дистрибутив Linux, в Termux применяют утилиту, которая скачивает корневую файловую систему выбранного дистрибутива и запускает её в пользовательском режиме: так внутри Android получают Debian, Ubuntu, Alpine или Arch Linux со своим пакетным менеджером.
Что сделать после прочтения: поднимите стенд в своей среде, добейтесь ответа 200 OK по внешнему адресу и соберите шесть скриншотов из списка. Такой набор доказательств закрывает защиту практической работы №13 без дополнительных вопросов.