Ранее (11 февраля 2019) пост уже публиковался мной с таким заголовком, но был отправлен в небытие по причине смерти домена, а как следствие и сервиса с ним связанного. Причин тогда было две — статистика скачивания докер-образа оставляла желать лучшего, и цена за продление домена (что был зарегистрирован в nic) стала для меня неожиданно выше той, которую я был морально готов заплатить за него.
Но есть время не продлять домены разбрасывать камни, а есть время извиниться за сделанную ошибку. Все, кому сервис был полезен, кто им пользовался и однажды заметил что он (localhost.tools) не резолвится — приношу свои извинения, и исправляю ситуацию (лучше поздно чем никогда, верно?).
Ниже я вкратце расскажу о чем вообще идёт речь, что изменилось, и как этим всем пользоваться. Для нетерпеливых, традиционно — репозиторий и ссылочка на сайт.
Итак, докер. В личном списке технологий, что изменили индустрию в лучшую сторону — именно его бы поставил, пожалуй, на первое место. Сборка и запуск сложных сервисов (с чертовой дюжиной зависимостей в виде баз данных, коллекторов и прочего) используя его сводится к одной/двум командам, и это ли не прекрасно? Про деплой я вообще помалкиваю — красота, да и только (естественно что есть нюансы, но сейчас не о них).
Но вместе с тем, при локальной разработке порою возникает неудобство (именно неудобство, не блокер) в виде "разведения" сервисов по различным портам. И это работает здорово, пока у вас не появляется целый зоопарк приложений, переключение между которыми начинает вызывать некоторые неудобства, так как надо помнить и схему, и порт, и где-то фиксировать какие порты для какого приложения вы когда-то выделили, дабы не возникло коллизии со временем.
А потом ещё тебе хочется проверить работу используя https — и приходится либо использовать свой корневой сертификат (mkcert), либо всегда использовать curl --insecure ..., а когда над приложениями работают различные команды — количество запар начинает возрастать в прогрессии, и порою геометрической.
Столкнувшись с такой проблемой в очередной раз — в голове промелькнула мысль "хватит это терпеть!", и результатом работы на паре выходных стал сервис, который решает это неудобство, о чем будет рассказано ниже.
Мир Нас спасёт реверс-прокси
По-хорошему, нам нужна какая-то доменная зона, все под-домены из которой всегда будут резольвить локалхост (127.0.0.1). Беглые поиски навели на домены вида *.localho.st, *.lvh.me и другие, но как к ним прикрутить валидный SSL сертификат? Повозившись со своим корневым сертификатом удалось завести curl без ошибок, но не все браузеры корректно принимали его, и продолжали вываливать ошибку. Кроме того — крайне не хотелось всей этой "возни" с SSL.
"Что ж, зайдём с другой стороны!" — мной был приобретен домен с именем indocker.app, делегирован на CloudFlare, настроен требуемый резольвинг (все под-домены резольвят 127.0.0.1):
$ dig +noall +answer -t A foo.indocker.app # IPv4
foo.indocker.app. 7131 IN A 127.0.0.1
$ dig +noall +answer -t AAAA foo.indocker.app # IPv6
foo.indocker.app. 86400 IN AAAA ::1
$ dig +noall +answer foo.bar.baz.indocker.app # any depth
foo.bar.baz.indocker.app. 86400 IN A 127.0.0.1После этого был бережно взял certbot, который используя DNS верификацию и API ключ от доменной зоны выдал мне TLS сертификат на зону *.indocker.app (если что, в конце поста есть ссылка на репозиторий с исходниками, и там подробно описано как именно это делается).
Теперь у нас есть и валидный TLS сертификат (пускай и на 3 месяца, и только для под-доменов одного уровня). Остается как-то научиться проксировать все запросы, что приходят на локалхост в нужный контейнер.
И тут на сцену врывается Traefik (спойлер — он прекрасен). Запустив его локально, и пробросив в его контейнер докер-сокет — он умеет проксировать запросы в тот контейнер, у которого есть необходимый docker label. Таким образом, нам нет необходимости в какой-либо дополнительной конфигурации, кроме как при запуске указать нужный label у контейнера, к которому мы хотим получить доступ по доменному имени!
Таким образом у нас появляется артефакт в виде докер-образа с пред-настроенным Traefik-ом и wildcard SSL сертификатом (да, он публичный).
Приватный ключ от SSL в публичном образе?
Да, но я считаю что это не страшно, так как он на доменную зону, которая всегда резольвит локалхост. MitM в этом случае не имеет особого смысла в принципе.
Что делать, когда сертификат протухнет?
Просто стянуть свежий образ, перезапустив контейнер. У проекта настроен CI, который в автоматическом режиме, раз в месяц (на данный момент) обновляет сертификат и публикует свежий образ.
Хочу попробовать!
Нет ничего проще. Первым делом, убедись что локальные порты 80 и 443 у тебя свободны, и выполни:
# Создаём docker-сеть для нашего реверс-прокси
$ docker network create indocker-app-network$ docker run -d --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 80:80 -p 443:443 \
--network indocker-app-network \
--name indocker.app \
quay.io/indocker/app:1 # 1 тут - это мажорное значение версииИ теперь проверки ради создадим простой docker-compose файл, и запустим сервисы в нём описанные:
version: '3.8'
services:
my-nginx:
image: nginx:latest
labels:
- traefik.enable=true
# Router docs: https://doc.traefik.io/traefik/routing/providers/docker/#routers
- traefik.http.routers.my-nginx-router.rule=Host(`my-nginx.indocker.app`)
- traefik.http.routers.my-nginx-router.service=my-nginx-service
# Service docs: https://doc.traefik.io/traefik/routing/providers/docker/#services
- traefik.http.services.my-nginx-service.loadbalancer.server.port=80
- traefik.http.services.my-nginx-service.loadbalancer.healthcheck.path=/
- traefik.http.services.my-nginx-service.loadbalancer.healthcheck.interval=5s
networks: [indocker-app-network]
security_opt: [no-new-privileges:true]
whoami:
image: containous/whoami:latest
labels:
- traefik.enable=true
- traefik.http.routers.whoami-router.rule=Host(`whoami.indocker.app`)
- traefik.http.routers.whoami-router.entrypoints=http # force HTTP instead of HTTPS
- traefik.http.routers.whoami-router.service=whoami-service
- traefik.http.services.whoami-service.loadbalancer.server.port=8080
command: --port 8080
networks: [indocker-app-network]
security_opt: [no-new-privileges:true]
networks:
indocker-app-network:
external: true$ docker-compose up -dИ теперь можем потестировать:
$ curl -sS https://my-nginx.indocker.app | grep Welcome
<title>Welcome to nginx!</title>
<h1>Welcome to nginx!</h1>
$ curl -sS http://whoami.indocker.app
Hostname: 849834ab3299
IP: 127.0.0.1
IP: 172.20.0.3
RemoteAddr: 172.20.0.2:33734
GET / HTTP/1.1
Host: whoami.indocker.app
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept: */*
Accept-Encoding: gzip
Referer:
X-Forwarded-For: 172.20.0.1
X-Forwarded-Host: whoami.indocker.app
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: edc8405eccc6
X-Real-Ip: 172.20.0.1Как видим — работает :)
Так как домены в зоне .app находятся в HSTS preload list — при попытке открытия браузером любого поддомена используя http — запрос будет автоматически перенаправлен на схему https. Касается это только браузеров.Кроме того, можем стукнуться браузером на адрес monitor.indocker.app, и увидеть дашборд локально запущенного Traefik:
Где живёт документация, описание?
Всё, как не сложно догадаться, живёт по адресу indocker.app. Более того, морда — отзывчивая, и умеет смотреть запущен ли у тебя локально демон. Все исходники живут в этом репозитории — если у кого-то появится желание сделать нечто похожее, но со своими особенностями — дерзайте!
Сколько стоит?
Нисколько. Совсем. Сделав данную штуку для себя и своей команды, пришло понимание того, что она может пригодиться и другим разработчикам. Более того — денег стоит только доменное имя, всё остальное — юзается без необходимости в оплате.
А в чем отличие от localhost.tools, который был сдохнут?
Во-первых — это домен. Он более привлекателен (как мне кажется), и приобретен не у российского регистратора (что важно). На момент написания этих строк он оплачен до 2027 года, и в ближайшее время докину ещё на пяток лет вперёд.
Во вторых — это открытые исходники. Не вижу смысла хранить их в закрытом виде, и если у кого-то будет желание что-то улучшить или сделать подобное для своей корпы — всегда пожалуйста.
И в третьих — это автоматизация. На его обновление и поддержку врядли потребуется много ресурсов, так как всякие там renovate да dependabot (в связке CI) почти всё делают за меня.
Кстати, о планах — есть желание сделать морду более информативной, и выводить прямо там свою борду (если демон запущен) с описанием запущенных контейнеров, статистикой, конфигами и прочим. Что-то вроде dockstation, только на минималках.
Монетизировать его или ограничивать функционал для не-pro пользователей смысла не вижу и не планирую от слова совсем (docker hub — привет).
