
Cloud & DevOps: от локального приложения до надёжного сервиса Урок 21 из 24
Домен, reverse proxy и автоматический HTTPS
Направляем DNS на сервер, отдаём CloudLab через Caddy и проверяем цепочку TLS снаружи.
Текст переведён с помощью ИИ.
Этот урок начинается с нуля. Незнакомое слово здесь не считается вашим пробелом: мы сначала создадим образ, затем дадим точное значение и только потом применим его.
Где мы находимся
Полётное повторение. В прошлом уроке была опора provider console → user+public key → second login → firewall → updates → app. Не подглядывая, назовите её четыре звена и только затем сравните с записью.
Результат урока
Направляем DNS на сервер, отдаём CloudLab через Caddy и проверяем цепочку TLS снаружи. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.
Сначала знакомый образ
В большом здании посетитель приходит к общей стойке, а не ищет внутреннюю комнату сотрудника. Reverse proxy — такая стойка: принимает публичное защищённое соединение, проверяет адрес запроса и передаёт его приложению во внутренней сети. Сертификат похож на удостоверение стойки для конкретного имени.
Аналогия помогает начать рассуждение, но не заменяет устройство технологии. Ниже мы уточним каждое слово.
Опорный сигнал урока
domain → DNS → public 443 → Caddy → private app:8080; certificate proves name
Прочитайте цепочку слева направо. Она отвечает не на вопрос «какую команду запомнить», а на вопрос «почему следующий шаг следует из предыдущего».
Новые слова простыми словами
- Reverse proxy — Публичный посредник перед приложением, принимающий и направляющий запросы.
- HTTPS — HTTP внутри соединения, защищённого TLS.
- Certificate — Подписанный документ, связывающий открытый ключ с доменным именем.
- Port 443 — Стандартный публичный порт HTTPS; это соглашение, а не шифрование само по себе.
Разбираем без спешки
Reverse proxy принимает публичное соединение, завершает TLS и передаёт запрос частному приложению. Для автоматического сертификата домен должен разрешаться в правильный IP, а порты 80 и 443 — быть доступны. Не публикуйте порт приложения наружу без необходимости.
Сейчас не нужно запоминать формулировку дословно. Найдите в ней причинную связь и привяжите её к опорному сигналу выше.
Сначала предскажите результат
До запуска ответьте на бумаге: что должно измениться, что должно остаться прежним и какой вывод команды подтвердит ваш прогноз? Даже неверный прогноз полезен, если после опыта вы можете объяснить расхождение.
Опыт маленькими шагами
Выполните команды из корня course/cloud-devops-lab. Команды рассчитаны на учебную среду. Перед командой, меняющей сервер или данные, прочитайте её целиком и проверьте текущий каталог. Запускайте блок по одной смысловой группе. После каждой остановитесь и сопоставьте результат со своим прогнозом.
export CLOUDLAB_DOMAIN=cloudlab.example.com
getent hosts "$CLOUDLAB_DOMAIN" 2>/dev/null || true
printf 'Caddy route:\n'
sed -n '1,80p' deploy/caddy/Caddyfile
printf 'After real DNS: curl -v https://%s/readyz\n' "$CLOUDLAB_DOMAIN"
Что именно делает этот опыт
DNS сначала должен указывать на сервер. Caddy читает домен, получает сертификат и передаёт запрос на частный адрес приложения. curl без -k одновременно проверяет доверие сертификату и HTTP-ответ.
Что должно получиться
- Приложение доступно через proxy, а не публичный порт 8080.
- Команда завершается предсказуемым кодом.
- Результат можно повторить на чистой среде.
Соберите целое по опорной схеме
Проведите пальцем или карандашом по четырём блокам и расскажите весь урок одним связным объяснением.
Воспроизведите без подсказки
- Закройте схему и нарисуйте четыре блока по памяти.
- Объясните каждый переход словами «потому что».
- Дайте определение одному новому термину, не повторяя текст дословно.
- Назовите один сигнал, который доказывает результат.
Найдите и исправьте ошибку
Ошибка: «Если страница открывается с -k, HTTPS настроен правильно». Исправление: -k отключает важную проверку личности и может скрыть неверный сертификат.
Задание
Теперь соберите тот же смысл самостоятельно. Можно смотреть на опорную схему; цель — не экзамен на память, а воспроизводимый результат.
Обязательное. Напишите POSIX sh-проверку HTTPS URL: потребовать успешную проверку сертификата, HTTP 200 от /readyz и вывести дату окончания сертификата без -k. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.
Критерии готовности
- Вы понимаете каждую запускаемую строку.
- Повторный запуск даёт ожидаемый результат или безопасно объяснённое отличие.
- В выводе нет настоящих ключей, токенов и паролей.
- Вы можете показать факт, который подтверждает успех.
Если проверка не прошла, зафиксируйте ожидаемое и фактическое, вернитесь к одному разорванному звену опоры и повторите. Ошибка не отнимает у вас право продолжать обучение.
По желанию. Запишите один возможный отказ и сигнал, по которому вы его заметите.
Открытая перспектива
Следующий урок добавит новую опору: OpenTofu и Ansible: инфраструктура и настройка как код.
Если вы нашли ошибку или опечатку в тексте статьи, то сообщите нам об этом
Комментарии (0)
Войдите, чтобы оставить комментарий →
Пока нет комментариев. Будьте первым.