Настройка Prometheus, Grafana и Loki на виртуальной машине Azure с использованием HTTPS с использованием шлюза приложений Azure

...настройка шлюза приложений Azure для правильной маршрутизации трафика в Prometheus, Grafana и Loki на основе поддоменов.

Предполагая, что вы настроили прослушиватели внешнего интерфейса для каждого приложения (дифференцированные по порту), у вас также должны быть разные внутренние пулы, соответствующие каждому внешнему интерфейсу.

1. Настройте параметры HTTP для серверов. Убедитесь, что протокол соответствует тому, который использовался бы, если бы вы просматривали непосредственно виртуальную машину. Т.е. В большинстве случаев обычный HTTP. Если вы хотите использовать HTTPS, вам необходимо убедиться, что вы настроили каждое из своих приложений соответствующим образом и либо использовать сертификат, выданный общедоступным центром сертификации, либо импортировать сертификат центра сертификации в App Gateway в доверенных центрах сертификации.
2. Создайте карты URL-путей в App Gateway. Вам понадобится одна карта путей для каждого приложения. Путь должен быть /, и вы должны указать в условии, что заголовок хоста должен соответствовать имени домена для этого конкретного приложения.
3. Настройте правила маршрутизации, которые сопоставляют ваш интерфейсный прослушиватель HTTPS с созданными вами картами путей. Одно правило для каждого серверного приложения.

Каковы наилучшие методы настройки проверок состояния здоровья для этих служб?

Вам необходимо выбрать стратегию либо из документации по продукту, либо придумав ее самостоятельно. Обычно зонда, настроенного на выполнение GET /, достаточно, чтобы убедиться, что хост доступен и что веб-сервер отвечает нормально. Если корень перенаправляет с помощью 301 или 302, вместо этого используйте путь, на который он перенаправляет. Например, /login.php. Вам следует искать код ответа HTTP 20x.

Как я могу гарантировать, что HTTP-запросы перенаправляются на HTTPS для всех поддоменов?

1. Создайте внешний прослушиватель для простого HTTP, порт 80. Оставьте имя хоста пустым, чтобы оно применялось ко всем входящим простым HTTP-запросам.
2. В App Gateway -> Settings -> Redirect Configurations добавьте конфигурацию. Выберите цель в качестве прослушивателя HTTPS. Выберите вариант включения строки запроса. Решите, хотите ли вы постоянное перенаправление 301, которое кэшируется вышестоящими прокси-серверами и браузерами, или временное 302, которое просто означает, что клиент будет каждый раз делать запрос, чтобы проверить, что перенаправление все еще на месте. 301 постоянный подойдет, если вы никогда не собираетесь обслуживать HTTP на этом шлюзе.

Есть ли в Azure встроенный менеджер сертификатов, аналогичный диспетчеру сертификатов AWS? Если да, то как я могу использовать его для управления своими SSL-сертификатами? Альтернативно, как я могу управлять сертификатами SSL без создания сертификатов вручную или без использования Let's Encrypt?

Не совсем. Существуют управляемые сертификаты Azure для служб приложений, а Azure KeyVault поддерживает создание закрытых ключей и CSR, но для подписи сертификата вам нужен общедоступный центр сертификации, например GlobalSign, Digicert и т. д. Если у вас уже есть сертификат с подстановочными знаками для *.example.com, вы можете использовать это . Или вы действительно можете использовать Let's Encrypt с проверкой DNS01. В конечном итоге вы можете загрузить подписанную цепочку сертификатов формата PFX (должна включать промежуточные и корневой центр сертификации) и закрытый ключ непосредственно в App Gateway или сослаться на существующий сертификат в KeyVault (который вам потребуется создать или загрузить). Я не буду здесь описывать шаги KeyVault, потому что это отходит от темы.

В результате в настоящее время не существует готовых функций для выпуска или продления сертификатов. Однако вы можете использовать проблемы с сертификатами в AWS Certificate Manager.