Cloud Foun dry от контейнера к контейнеру через https - PullRequest
Новая
       89

Cloud Foun dry от контейнера к контейнеру через https

1 голос
/ 17 марта 2020

На базе ibm cloud cloud у нас есть два приложения dry (appA и appB). appA получает доступ к appB через сеть контейнер-контейнер, в то время как appB также доступен извне по маршруту Gorouter. Дело в том, что пока наше приложение работает по протоколу http-8080 - все хорошо.

Теперь нам нужно создать сеть между контейнерами через https. Мы настроили приложение для показа https-8080. 8080 используется как https://docs.cloudfoundry.org/devguide/custom-ports.html и гласит, что: 

By default, apps only receive requests on port 8080 for both HTTP and TCP routing, 
and so must be configured, or hardcoded, to listen on this port

сеть от контейнера к контейнеру работает, как и ожидалось, теперь с использованием https. Но мы больше не можем использовать appB по внешнему маршруту Gorouter.

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

1 Ответ

0 голосов
/ 18 марта 2020

Нет хорошего ответа на этот вопрос, по крайней мере, в то время, когда я пишу это.

У вас есть несколько вариантов:

  1. Вручную настроить HTTPS для внутреннего маршрута. Для этого вам нужно будет использовать инструкции для вашего приложения / сервера по выбору для настройки HTTPS. Затем используйте любую функциональность, которую предоставляет ваш buildpack-пакет, чтобы вставить это подтверждение в контейнер приложения. Это также потребует, чтобы вы связали и получили сертификаты TLS sh с вашим приложением. Платформа не предоставит вам сертификаты TLS, если вы выберете эту опцию.

    Хитрость в том, чтобы заставить работать как внутренний, так и опубликованный маршрут c, состоит в том, что ваше приложение должно прослушивать порт 8080 и порт, который вы выбираете для своего HTTPS-трафика c. Пока вы продолжаете принимать HTTP-трафик c на порт 8080, ваши publi c маршруты должны продолжать работать.

  2. Если вы хотите быстрое, но не идеальное решение, вы можете используйте порт 61001. Для более новых версий Cloud Foun dry этот порт используется Envoy для приема traffi c в ваше приложение через HTTPS. Затем Envoy передает запрос в ваше приложение через HTTP через порт 8080. Вы также можете использовать этот порт для трафика от контейнера к контейнеру c, однако настроенное имя субъекта в сертификате TLS не будет соответствовать вашему маршруту.

    Вот пример того, как будет выглядеть имя субъекта. 

    subject: OU=organization:639f74aa-5d97-4a47-a6b3-e9c2613729d8 + OU=space:10180e2b-33b9-44ee-9f8f-da96da17ac1a + OU=app:10a4752e-be17-41f5-bfb2-d858d49165f2; CN=b7520259-6428-4a52-60d4-5f25

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

Для чего бы это ни стоило, я не думаю, что вам нужно или нужно для изменения порта . Обычно это используется, если ваше приложение не является гибким и не может прослушивать порт 8080. Он изменяет порт для входящего трафика c. Поскольку вы используете только сеть C2 C, вам не нужна эта опция.

То, что вы хотите, насколько я понимаю, это то, что вы хотите HTTPS для C2 C traffi c. В этом случае publi c traffi c не имеет значения. Он все еще может go через Гороутер к порту 8080. Для вашего трафика от контейнера к контейнеру c, вы можете выбрать любой порт, который вы хотите. Вам просто нужно убедиться, что на выбранном вами порту установлена ​​сетевая политика , разрешающая этот трафик c (по умолчанию все C2 C traffi c заблокированы). Как только сетевая политика установлена, вы можете подключиться напрямую через любой назначенный порт.

...