Комментарии 26
v1
[acme]
email = "mail@domain.ru"
storage = "acme.json"
caServer = "https://acme-v02.api.letsencrypt.org/directory"
entryPoint = "https"
[acme.httpChallenge]
entryPoint = "http"
[[acme.domains]]
main = "domain.ru"
v2
[certificatesResolvers.sample.acme]
caServer = "https://acme-v02.api.letsencrypt.org/directory"
email = "mail@domain.ru"
storage = "acme.json"
[certificatesResolvers.sample.acme.httpChallenge]
# used during the challenge
entryPoint = "web"
[http.routers.api]
rule = "Host(`traefik.domain.ru`)"
entrypoints = ["websecure"]
service = "api@internal"
middlewares = ["auth"]
[http.routers.api.tls]
certResolver = "sample"
Согласен, если вы не Netflix — ставьте traefik и забудьте про остальное. Traefik ваш царь и бог в роутинге, SSL и проксировании
Потому что traefik разрабатывался как более дружелюбный к человеку прокси-сервер, чем nginx. Особенность traefik, что это именно ПРОКСИ, т.е. статику он отдавать не умеет. Ну, и то, что он всего лишь чутка медленнее nginx — никак не может быть аргументов в выборе в пользу nginx.
Как сказал gecube — некорректно сравнивать. Вот haproxy VS traefik ещё можно сравнить)
Тема поста «SSL сертификат для Docker web-app»
Ты б еще предложил балансер поднять, на нем терминейтить серты и дальше тупо через http ходить в контейнер
Вобщем если нечего сказать по теме — лучше помолчать.
А вместо того, чтобы накидывать агрессию — лучше было бы включить голову и узнать, что Traefik умеет внутри себя получать сертификаты LE и не нужно придумывать какие-то костыли. Я уж не говорю о том, что им очень удобно проксировать докер-контейнеры, т.к. он умеет определять их наличие по лейблам (меткам) и по ним же строить свою конфигурацию. Для тестовой среды почти идеально.
Traefik бесплатен только до 5 проксируемых сервисов
awsswa.livejournal.com/41766.html
Docker
…
В первую очередь мы установили на сервер certbot
*фейспалм* Кхм…
А если по теме, может кто понятно объяснить, зачем вообще такое городить? Кажется очевидным, что обычная схема сервера выглядит как один nginx, установленный на сервере, смотрящий наружу и проксирующий все запросы дальше куда надо. Как там умными словами, SSL Terminator это вроде называется. Соответственно, все сертификаты кладутся туда. А ваше приложение из докера должно экспозить чистый HTTP порт и не заботиться о сертификатах вообще. Ваш докер-компоуз приложения даже не должен знать, какие где там сертификаты — это все разруливается на внешнем nginx. Зачем делать иначе?
Вы про схему 2 nginx и fpm в одном docker-compose? Или про отдельный nginx со своим Докер-композит и демоном, который следит за докер-сокетом, перегенерирует конфиги nginx, если поднялся новый nginx с определёнными параметрами?
Иногда мне кажется, что с разделением ответственностей и автоматизации люди перегибают. Поднимать 2 или даже 5 иногда nginx (tsl терминатор, роутер, генерируемая статика а-ля SPA приложения на реакт, пользовательские файлы, морда для fpm) для сайта-визитки или простого mvp какого-то…
Я про схему «один обычный nginx на сервере (не в докере), он же SSL Terminator, проксирующий запросы в нужные контейнеры» + все ваши докер-компоузы
Т.е. в случае простого веб-приложения с докер-компоузом из трех сервисов (входной nginx для вашего приложения, он же раздает статику; БД; контейнер, исполняющий логику (uWSGI в случае Питона и Django, например)) внешний nginx должен просто все запросы проксировать в ваш открытый порт, раскрывая SSL.
Итого для N приложений на одном сервере у вас 1 nginx + N компоузов. В каждом компоузе nginx, fpm/uwsgi/unicorn и MySQL. Единственный софт, который стоит на сервере — nginx, докер и компоуз. Все.
Да и вообще — выясняется, что на целевом сервере компоуз-то и не нужен. Во-первых, он прекрасно работает с удаленным докер демоном. А, во-вторых, вместо компоуза намного более веселее использовать ansible для управления контейнерами, т.к. те же миграции и очередность запуска контейнеров через компоуз очень плохо реализовывать.
А с чего Вы решили, что автор девопс? Если б он был девопсом, то знал, что
- Есть образ jwilder/nginx, который умеет тоже самое и выписывать сертификаты автоматически. Ну, или traefik как выше вспомнили
- Можно автоматизировать создание TXT-записи отделегировав или перенеся зону на Cloudflare, route53 или любой другой днс-хостинг с поддерживаемым certbot'ом api.
VolCh я могу представить зачем нужны пляски именно с https — т.к. хочется отлаживать веб-приложенте именно в той конфигурации, которая поедет на продакшн. Там много нюансов с cors, hsts, mixed content etc.
На проде использовал следующую схему:
— каждый микросервис (golang + mysql) в своем docker compose
— vps 1CPU + 1GB Ram (около 8ми микросервисов, пришлось мускл потюнить чтобы меньше в холостую озу жрал, с 150мб в пике получилось 57-60мб)
— nginx смотрит в мир, а микросервисы из докера прокинул через unix-socket (кроме мускл естественно)
— ssl получаю тем-же lets encrypt на 90дней + крон автопродлевает
профит:
— ssl-сертификат обновляется за 1 раз для всех микросервисов\хостов
— все настройки микросервисов (читай веб-контейнеров) в одной папке nginx на vps
— уменьшается к-тво контейнеров для управления
очень простая и удобная схема… до этого разные варианты перепробовал, вплоть до извращения:
— собираем образ ubuntu -> golang -> mysql -> nginx -> lets encrypt
— билдим, настраиваем докер файл
— 1 контейнер на микросервис
:)
и кстати, certbot иногда глюкает, и если слишком рано запустить обновление (до expire time) ничего не произойдет, хз почему так, устанавливался как с офф пакета, так и с репы.
Подскажите пожалуйста, если после ввода комманды:
sudo certbot certonly -d {domen}.ru -d *.{domen}.ru -d {domen}.com -d *.{domen}.com --manual --preferred-challenges dns;для доменов при генерации некоего домена указаны TXT записи типа:
_acme-challenge.{domen}.ru TXT {тотКлючКоторыйВамВыдалCertBot}
Добавить даннцю запись в DNS зону нужно прежде чем продолжить процесс формированиия сертификата? Вот кусок лога:
Please deploy a DNS TXT record under the name
_acme-challenge.{domen}.ru with the following value:
nG1_sgbfTM_SpB3lHN_n556R8Guu0l2n-jUhID98fIQ
Before continuing, verify the record is deployed.
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)
После того, как я продолжил, словил:
Press Enter to Continue
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. {domen}.com (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.{domen}.com, {domen}.ru (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.{domen}.ru, {domen}.com (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.{domen}.com, {domen}.ru (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.{domen}.ru
IMPORTANT NOTES:
— The following errors were reported by the server:
Domain: {domen}.com
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.{domen}.com
Domain: {domen}.ru
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.{domen}.ru
Domain: {domen}.com
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.{domen}.com
Domain: {domen}.ru
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
Может ли эту проблему исправить порядок действий, если сперва добавить TXT записи в DNS зону, а уже после продолжить процесс формирования сертификата?
На дворе 2021, а это все еще единственная инструкция на русском как завести сертификат на nginx в docker-контейнере.
Спасибо автору.
SSL сертификат для Docker web-app