работает.
Допустим у меня есть 1 (одна) виртуалка в Compute, слушающая https порт.
Хочу выставить её наружу, но так чтобы с SSL и с сертификатами не париться.
Если делать это через гугловый Load Balancer, то возникает проблема с тем что для региональных LB гугл не хочет сам рулить сертификатами, то есть их надо как-то отдельно будет перевыпускать и обновлять в том же GCP.
То есть мне сам балансировщик не нужен по-сути, только реверс-прокси и SSL. В таком случае наверное проще в сторону Cloudflare смотреть?
клаудфлер решит проблему, да. у гугла шо нету встроенной сертификатилки?
Есть, но она не для такого конфига: > Google-managed certificates aren't currently supported with regional external HTTP(S) load balancers.
Certbot поставить и всё
хах. Ну тогда или ручками (через сертбот) или 3-пати
кстати не уверен что он сможет обновить на облаке серт сам
А какая разница, если по http
Ну или глобальный лб использовать
Для единственной виртуалки жирно как-то получается. Cloudflare пока что самым простым вариантом выглядит, но и там не без подводных типа лимита на размер загружаемых файлов.
Я бы цертбот поставил. Но тебе любой вариант советовать неправильно, потому что у тебя подход кривой. В облаке не хостят приложение просто на одной виртуалке.
Посоветуй пожалуйста как правильно, я ж не против. Почему всё так криво: изначально была конфигурация на своём железе: виртуалка-прокси, которая смотрела наружу, запускала тот же certbot и проксировала запросы во внутреннюю сеть. Теперь пытаемся в GCP переехать, но на старте сделали максимально простую конструкцию: одна виртуалка, на которой и приложение, и реверс-прокси. И вот пришло время с этой единственной виртуалки выносить компоненты в отдельные сервисы GCP где это возможно. Ещё один вариант, конечно, поднять рядом вторую виртуалку-прокси и на ней уже запускать certbot и запросы проксировать, но это по-сути получается повторение старой конфигурации.
используй принцип KISS
Правильно, это надо сначала ознакомиться с архитектурой приложения, потом по ней ,и по требованиям сделать архитектуру в облаке, потом деплоить. Это не сложно, но в чате не решается. Я только могу сказать, почему один в один неправильно переносить. В облаке виртуалки считаются эфемерными сущностями, на них нет и не будет никогда sla по доступности. В любой момент погасят для мейнтенанс и даже не предупредят.
AWS дает 99,5% SLA для отдельных EC2 instance
haproxy умеет certbot
Сам по себе haproxy про certbot ничего не знает
Обсуждают сегодня