Docker-compose для создания Caddy Entrypoint
Обновлено:
Опубликовано:
Используемые термины: Caddy, docker, веб-сервер.
В инструкции рассказано, как развернуть веб-сервер Caddy для http-проксирования на другие сервисы, работающие в качестве контейнеров docker.
Хотя NGINX — лидер в области обратного проксирования, для Docker-окружения Caddy предлагает ключевые преимущества:
- Простота конфигурации — автоматический HTTPS, минимальный синтаксис Caddyfile.
- Отказоустойчивость — Caddy стартует даже при недоступности проксируемых сервисов (в отличие от NGINX, который может отказать целиком).
- Автоматизация — встроенная поддержка Let's Encrypt без дополнительных скриптов.
Таким образом, Caddy является отличным кандидатом для настройки прокси в докере.
Предварительная настройка
Пример файла docker-compose
Описание файла docker-compose
Запуск контейнера с caddy
Настройка сети для взаимодействия с другими контейнерами
Конфигурирование обратного прокси на контейнер
Настройка SSL
Примеры конфигураций
Дополнительная информация
Подготовка
Для работы и запуска сценария на сервере должны быть установлены docker и docker-compose. Подробное описание по их инсталляции можно найти в инструкции Установка Docker на Linux.
Выполним предварительные действия. Предполагается, что мы будем хранить наш файл docker-compose в каталоге /opt/caddy.
Создаем и переходим в него:
mkdir /opt/caddy
cd /opt/caddy
И сразу создаем файл docker-compose.yml:
vi docker-compose.yml
Мы готовы к написанию сценария.
Docker-compose
Пример нашего файла compose:
- services:
- caddy:
- image: caddy:2.10
- hostname: caddy
- container_name: caddy
- restart: unless-stopped
- environment:
- TZ: "Europe/Moscow"
- ports:
- - 80:80
- - 443:443
- volumes:
- - ./Caddyfile:/etc/caddy/Caddyfile
- - ./data:/data
- - ./ssl:/etc/caddy/ssl
- networks:
- - cnet
- healthcheck:
- test: ["CMD-SHELL", "curl -fI http://127.0.0.1:2019/metrics"]
- interval: 30s
- timeout: 5s
- retries: 3
- start_period: 10s
- networks:
- cnet:
- name: cnet
- driver: bridge
Описание сценария
Кратко опишем, что выполнит наш сценарий. Подробнее про работу с docker-compose можно прочитать в инструкции Шпаргалка по работе с docker-compose.
| Строки | Описание |
|---|---|
| 3 - 24 | Поднимаем контейнер с caddy прокси. |
| 4 | Мы используем официальный образ. Обратите внимание, что лучше указывать тег с версией. Более актуальное значение можно посмотреть на Docker Hub. |
| 14 | Основной конфигурационный файл для caddy. |
| 15 | Хранит автоматически полученные сертификаты Let's Encrypt. |
| 16 | Хранение самоподписанных или платных сертификатов. |
| 26 - 29 | Общая сеть. Ее мы будем добавлять к другим службам других контейнеров для обеспечения сетевой доступности между данным контейнерами и нашим entrypoint. |
Создание конфигурации и запуск
Caddyfile является конфигурационным файлом, в котором описано поведение веб-сервера, а также правила проксирования.
Продолжая находиться в каталоге с docker-compose, создадим простой вариант конфигурации для работы caddy:
vi Caddyfile
:80 {
respond "Hello, World!" 200
}
* в данном примере веб-сервер будет принимать запросы только по http и отдавать ответ «Hello, World!».
Для запуска контейнера выполним команду:
docker-compose up -d
При первом запуске система загрузит образ с caddy и запустит контейнер. Посмотреть его состояние можно командой:
docker-compose ps
Также можно отправить запрос веб-серверу:
curl http://127.0.0.1
В ответ мы должны получить строку «Hello, World!».
Идем дальше.
Настройка других docker-compose
Для сетевого взаимодействия контейнеров, они должны находится в одной сети. В нашем примере мы создали подсеть cnet. Ее нужно указать в других файлах docker-compose. Приведем небольшой пример:
services:
service_name:
...
networks:
- default
- cnet
...
networks:
...
cnet:
name: cnet
external: true
* итого, чтобы все работало, среди перечня сетей должна быть перечислена та, в которой находится caddy-entrypoint (то есть, cnet).
Чтобы данные настройки применились, запускаем команду:
docker-compose up -d
Будут перезапущены контейнеры, которых коснулись изменения.
Пример конфигурации
Теперь можно настроить первое проксирование на приложение docker. Предположим, что у нас есть контейнер my_site_container, приложение которого принимает http запросы на порту 3000. Открываем конфигурацию кадди:
vi Caddyfile
И заменим предыдущее содержимое на:
http://test.domain.ru {
reverse_proxy my_site_container:3000
}
* обратите внимание на:
- http — мы указали конкретный протокол. Если этого не сделать, caddy попытается запустить прослушиватель для домена на порту https, что потребует сертификата. Пока нам это не нужно.
- test.domain.ru — будут приниматься только http запросы с заголовком host = test.domain.ru.
- reverse_proxy — данная опция указывает, что все запросы нужно спроксировать на другой адрес.
Чтобы изменения вступили в силу, перезапустим контейнер:
docker-compose restart
Можно проверить работу прокси с помощью команды:
curl --header "Host: test.domain.ru" http://127.0.0.1
Получение сертификата (настройка HTTPS)
Рассмотрим некоторые нюансы при работе с HTTPS в caddy.
1. По умолчанию, все обслуживаемые домены запускаются с прослушивателями на 443 порту. А сертификат автоматически запрашивается у Let's Encrypt.
Например, конфигурация:
test.domain.ru {
respond "Hello from test domain!"
}
... без указания протокола запустит процесс получения сертификата для домена test.domain.ru.
2. Если нам достаточно самоподписанного сертификата, то добавляем tls internal:
test.domain.ru {
tls internal
respond "Hello from test domain!"
}
3. Если у нас свой сертификат, то указываем пути до файлов с помощью опции tls:
example.com {
tls /etc/caddy/ssl/cert.pem /etc/caddy/ssl/cert.key
respond "Hello with custom cert!"
}
* обязательно первый файл должен быть с открытыми ключами, второй — приватным.
Не забываем перезапустить контейнер:
docker-compose restart
Небольшие примеры конфигурирования Caddy
Приведем немного примеров настройки через Caddyfile.
1. Разные прокси для разных суффиксов (locations):
handle /admin/* {
reverse_proxy admin:8000
}
handle {
reverse_proxy front:3000
}
* в данном примере запросы на /admin/ будут проксироваться на admin:8000, а все остальные — front:3000.
2. Robots.txt без файла:
handle /robots.txt {
header Content-Type "text/plain; charset=utf-8"
respond `User-agent: *
Disallow: /
`
}
* на запрос /robots.txt отдаст содержимое respond. В данном случае, которое запретит индексирование сайта.
Читайте также
Другая полезная информация про docker и веб-сервисы:
2. Шпаргалка по работе с docker-compose.
