В документации Cloud Foundry рекомендуется настроить запись DNS с подстановочными знаками, чтобы маршруты ко всем приложениям, развернутым в PaaS, были известны DNS. Но многие корпоративные ИТ-отделы и облачные провайдеры запрещают использование подстановочных знаков в своих службах DNS.
В этом блоге рассматривается использование DNS с подстановочными знаками в Cloud Foundry и обсуждаются альтернативы для сред, в которых подстановочные знаки недоступны.
Cloud Foundry Routing: учебник для начинающих
Когда приложение развертывается в Cloud Foundry, создается связанный маршрут . Маршрут представляет собой стандартную строку URI и является идентификатором, используемым всеми клиентами для доступа к приложению через HTTP.
Этот маршрут, как и большинство хороших URL, включает имя хоста и имя домена.
Например, я только что развернул приложение конвертации валют Python в своем экземпляре Stackato, размещенном в openstack. Созданный им URI выглядит так:
http://bottle-currency.demo.stacktest.io
Здесь часть имени узла — «бутылка-валюта», а часть имени домена — «demo.stacktest.io».
Когда я набираю это в своем браузере, браузер обращается к DNS, который сопоставляет «bottle-currency.demo.stacktest.io» с IP-адресом PaaS. Cloud Controller (CC) сидит на этом IP-адресе, прослушивая порты 80 и 443. Когда приходит мой запрос, CC проверяет заголовки HTTP, чтобы извлечь строку входящего URL, сопоставляет ее с маршрутом, назначенным приложению, и направляет запрос к экземпляру этого приложения, запущенного в PaaS.
Только HTTP / S и без портов
Маршрутизатор Cloud Foundry поддерживает только протокол HTTP. В настоящее время маршрутизатор Cloud Foundry не поддерживает трафик не HTTP, хотя эта функция в настоящее время разрабатывается для diego .
Вы заметите, что в строке URI маршрута не указан порт. Это связано с тем, что Cloud Foundry прослушивает только стандартные порты http / s (80 и 443) и не использует порты для различения целевых приложений.
Стоит отметить, что компонент Stackato Harbour расширяет Cloud Foundry для поддержки любого протокола как по TCP, так и по UDP, и Harbour предоставляет дополнительные порты для включения этого.
Подстановочный знак DNS
Чтобы все это работало, DNS, очевидно, должен иметь возможность разрешать имя хоста / имя домена. Часть имени хоста соответствует приложению, и, поскольку имена приложений не обязательно известны заранее, было бы удобно, если бы DNS мог соответствовать любому имени хоста в этом поддомене, вместо того, чтобы требовать обновления DNS каждый раз, когда новое приложение толкнул.
Именно здесь вводится DNS с подстановочными знаками. Как следует из названия, DNS-записи с подстановочными знаками соответствуют произвольным именам хостов, указанным звездочкой в записи DNS.
В приведенном выше примере запись DNS для demo.stacktest.io выглядит следующим образом:
*.demo IN CNAME demo.stacktest.io.
Который сопоставляет любое имя хоста в поддомене demo.stacktest.io с моим IP-адресом PaaS.
Когда DNS-символ подстановки изгнан
Подстановочные знаки DNS работают очень хорошо для этой цели, но, к сожалению, многие ИТ-политики запрещают использование подстановочных знаков DNS. Причины, которые я слышу, различны, в основном из соображений безопасности. Например, несколько лет назад eBay был целью фишинговых атак , использующих подстановочный DNS. Следовательно, многие ИТ-отделы неохотно разрешают использование подстановочных знаков, даже для DNS, предназначенного только для внутреннего использования.
Другие избегают подстановочных знаков DNS, поскольку это может скрывать ошибки и вводить пользователей в заблуждение.
Независимо от причин, если ваш провайдер или ИТ-отдел запрещает использование подстановочных знаков DNS, вам потребуется обходной путь, чтобы PaaS мог создавать произвольные имена приложений.
Не решение
Я уберу это с дороги первым. Может возникнуть соблазн попытаться получить доступ к приложениям, размещенным на PaaS, напрямую через IP-адрес PaaS, минуя разрешение имен в целом. Это естественная техника, которую разработчики, использующие tomcat, WSGI и другие контейнеры, успешно использовали целую вечность. Но это не будет работать с Cloud Foundry. Запросы, содержащие только IP-адрес вместо полностью определенного доменного имени, будут правильно маршрутизироваться в PaaS, но URL-адрес не содержит фактического имени приложения, поэтому PaaS не может определить, для какого размещенного приложения предназначен запрос. Таким образом, имя требуется, и это имя должно быть как-то разрешено.
Решения
Вот несколько методов, которые будут работать для обеспечения правильного разрешения имен приложений.
1. Поддерживать статический пул имен приложений (имен хостов) в DNS
Быстрый, но негибкий обходной путь для ИТ-специалистов заключается в том, чтобы выделить и поддерживать пул статических имен приложений в DNS и сообщить разработчикам, что они должны использовать одно из этих имен при развертывании приложений. Это жестко и обременительно, так как мешает разработчикам динамически создавать имена приложений для экспериментов или управления версиями, если только имена приложений не имеют смысла (например, app1, app2, app9999), и в этом случае сопоставления трудно контролировать и понимать.
2. Используйте xip.io для разрешения имен
С их сайта xip.io — это «волшебное доменное имя, которое предоставляет подстановочный DNS для любого IP-адреса». Он работает путем анализа переданного имени хоста / домена, а также извлечения и возврата встроенного IP-адреса.
Например, скажем, ваш PaaS находится по IP-адресу 123.123.123.123. Вы можете назвать свой PaaS 123.123.123.123.xip.io, и все ссылки на * .123.123.123.123.xip.io будут правильно разрешены средством разрешения xip.io.
Как это ни удобно, но обычно это не очень хорошее решение. Любой ИТ-отдел, который отказывается от подстановочного DNS, предположительно, скептически относится к отправке DNS-запросов вне офиса при каждом доступе к приложению изнутри. Также это зависит от доступности xip.io. А схема именования, введенная xip.io со встроенным IP-адресом, громоздка и ломается, если / когда кластер перемещается по сети.
3. Динамически добавлять имена приложений с помощью поддерживаемого ИТ-интерфейса DNS API (если доступно)
Некоторые ИТ-отделы предоставляют API для управления своими DNS, что позволяет (помимо прочего) динамически добавлять и удалять новые имена хостов. Если такое доступно, вы можете организовать вызов этого API для динамического сопоставления нового имени хоста / имени приложения с DNS во время развертывания приложения.
Обратите внимание, если вы используете Stackato, вы можете использовать хуки для этого. Staging_hook, встроенный в манифест, может включать прямой вызов DNS API для добавления имени хоста для развертываемого приложения.
4. Использование делегирования DNS. При делегировании DNS уникальный субдомен назначается для кластера PaaS, а отдельный DNS-сервер, не управляемый ИТ-отделом, во внутренней сети используется для разрешения всех запросов для этого субдомена. Для этого требуется добавить одну запись «IN NS» на управляемый ИТ-сервером DNS-сервер, который указывает на DNS-сервер, выделенный для разрешения имен PaaS.
Многие ИТ-отделы разрешают использование подстановочного DNS на делегированном DNS-сервере, и в этом случае это решение работает очень хорошо. Но даже без подстановочного DNS добавление новых имен хостов на локальный DNS-сервер, управляемый командой, обычно выполняется намного быстрее, чем отправка заявки на обслуживание.
5. Тонкая настройка / etc / hosts
Для полноты я должен упомянуть, что если у вас есть доступ ко всем клиентам, которые будут обращаться к PaaS, и контроль над ними, вам, возможно, удастся добавить записи хоста для каждого приложения в файл / etc / hosts (или эквивалентный) на каждом клиенте. , Это не рекомендуется или даже невозможно в большинстве производственных установок, но может быть полезно во многих средах разработки и эксперимента.
6. Подстановочный знак DNS
Конечно, предложенное выше решение с использованием подстановочных знаков DNS является лучшим выбором, если ваш ИТ-отдел допускает это. Он прост в настройке и не требует дополнительных вызовов API, отдельных DNS-серверов или ручного обслуживания имен хостов.
В заключении
Чтобы успешно предоставлять приложения для Cloud Foundry, полезно иметь представление о том, как используется DNS, и о некоторых параметрах настройки DNS. Дополнительные соображения DNS включают настройку PaaS для поддержки домена apex (root) и резервных маршрутов. См. Документацию по Cloud-Foundry для получения более подробной информации.