Я думаю, вы имеете в виду это Shopify Настройка DNS.
Укажите А запись на Shopify IP-адрес 23.227.38.65.
Укажите CNAME запись с именем www к магазины.myshopify.com
корневой домен (@)
Ну, как вы знаете, вы не можете иметь CNAME в корне (@), поэтому корневой домен необходимо обрабатывать с помощью А и АААА записи, указывающие на фиксированные IP-адреса.
Способ, которым крупные компании масштабируют это глобально, использует «любую передачу», когда один и тот же IP-адрес объявляется по BGP из нескольких разных центров обработки данных.
Вы можете думать о Anycast как о балансировке нагрузки, обрабатываемой маршрутизаторами, когда несколько серверов в одном или разных центрах обработки данных могут получать и обрабатывать трафик для одного IP-адреса.
Если вы еще не являетесь AS со своим собственным IP-пространством, то Anycast определенно вам не подходит.
Самый простой способ начать здесь — не запускать какой-либо хостинг в корневом домене, а просто делать перенаправления на www. Тогда один блок перенаправления nginx (или несколько за балансировщиком нагрузки уровня 4/tcp) может обрабатывать довольно много перенаправлений домена.
Если вам нужно много ящиков из-за огромного количества запросов, используйте балансировку нагрузки tcp/layer4 для ваших серверов перенаправления, чтобы вы могли выполнять приложение (http) и завершение ssl на боксах за балансировщиком нагрузки для большей масштабируемости (один балансировщик нагрузки может обрабатывать больше трафика).
Используйте постоянные редиректы (301), которые кешировать на неопределенный срок сокращение повторяющегося трафика от одних и тех же клиентов.
Лучшие практики здесь. Используйте letsencrypt/certbot для автоматического создания/обновления доменов перенаправления после настройки DNS. Всегда перенаправлять на https на том же домене (например. http://example.com --> https://example.com) перед перенаправлением на другой домен (https://www.example.com).
www
Глядя на Shopify магазины.myshopify.com (где www CNAME должен указать) вы можете видеть, что у него есть один А запись, которая на данный момент 23.227.38.74.
Используя инструмент глобального пинга вы можете видеть, что этот IP-адрес имеет задержку в несколько миллисекунд из многих мест по всему миру. Это означает, что это определенно не один сервер в одном месте (трансатлантическая задержка обычно составляет 60 мс в лучшем случае ... поэтому, когда вы видите пинг 4 мс из США и ЕС для одного и того же IP ... вы знаете, что эти пинги не t собирается на тот же сервер). Вы также можете проверить это, запустив traceroute на один и тот же IP-адрес с разных серверов в разных регионах.
На каждой из их конечных точек, отвечающих на этот IP-адрес, у них, вероятно, есть балансировщик нагрузки, направляющий запросы на другое оборудование.
Итак, за Shopify CNAME стоит Anycast с одним IP-адресом. Преимущество предоставления вашим клиентам CNAME заключается в том, что вы можете свободно изменять IP-адреса, скрывающиеся за этим именем, без необходимости вашим клиентам обновлять DNS на своей стороне. На этой ноте... когда вы даете своим клиентам А запись для их корня (@) перенаправитель домена... вы хотите убедиться, что это IP-адрес, который вы можете контролировать и переназначать другому оборудованию, если у вас есть проблемы с сервером/балансировщиком нагрузки (например, эластичный IP-адрес AWS или ваше собственное IP-пространство если вы АС).
Насколько я знаю, в DNS-запросе (и в части кэширования DNS-преобразователя) не дается никаких «подсказок», когда ваш компьютер следует цепочке CNAME при разрешении имени, чтобы сообщить конечному DNS-серверу, что такое исходный домен. что вы просили. Если бы это было так, вы могли бы представить, что DNS-сервер имеет условные правила для возврата разных IP-адресов для одного и того же имени в зависимости от имени, которое за ним стоит.
Так что, если вы не собираетесь делать это в магазине (bgp/anycast). Самое простое — дать своим клиентам уникальные CNAME. Таким образом, вы можете выполнять балансировку нагрузки на уровне DNS (возвращая разные IP-адреса для каждого уникального клиентского CNAME).
Вы можете следовать некоторому соглашению, например customerdomain.tld.example.com и настроить DNS автоматически на основе вашей базы данных активов клиентов.
А для корневого домена (@) вы по-прежнему можете использовать один IP-адрес перенаправителя (один или несколько ящиков за одним IP-адресом/балансировщиком нагрузки), управляющий перенаправлением для всех доменов на www.customerdomain.tld какие CNAME в customerdomain.tld.example.com.
Обновление ... может быть, я упустил суть вашего вопроса.
Это очень помогло бы, когда мне нужно перенести много веб-сайтов на новую инфраструктуру.
Как я уже упоминал выше, по крайней мере для root/@ В этом случае вам НЕОБХОДИМО контролировать этот IP-адрес и иметь возможность назначать его другой инфраструктуре... в противном случае всем вашим клиентам придется обновлять свой DNS при изменении этого IP-адреса из-за миграции.
Для www/CNAME В этом случае это не проблема, потому что вы можете просто обновить IP-адрес за CNAME в своем собственном DNS.
Поэтому я сосредоточусь на параметрах только для корневого домена (@), так как это наиболее проблематично (требуется действие клиента для обновления DNS при изменении IP-адреса их службы). Параметры...
вариант 0 - не поддерживать рут/@ домен для клиентов
Что бы вы ни размещали, размещайте это на поддомене (www или другой).
Если клиенты хотят перенаправления, они могут управлять этим со своей стороны со своими ИТ-специалистами.
Это полностью устраняет проблему DNS клиента, указывающую на фиксированный IP-адрес. Вы можете обновить IP-адреса CNAME(s) на своей стороне, и любое перемещение инфраструктуры или изменение IP станет простым.
вариант 1 - назначаемые IP-адреса
Вы можете использовать такие вещи, как назначаемые IP-адреса (вещь с эластичным IP-адресом AWS, большинство серьезных провайдеров VPS предлагают что-то подобное).
Это позволяет вам развернуть новый сервер (у этого провайдера), а затем переключить IP на новый сервер.
Проблема в том, что у вас есть привязка к поставщику/поставщику, потому что IP-адреса принадлежат поставщику. Поэтому, если вы хотите перейти с AWS на Google-Cloud или на собственное оборудование, вы не можете взять с собой эти IP-адреса... Обновление DNS для ваших клиентов. Кроме того, IP-адреса могут быть привязаны к региону, поэтому вы не можете легко назначить IP-адрес другому серверу у провайдера в другом центре обработки данных.
вариант 2 - стать AS и получить собственное IP-пространство
Если вы делаете серьезный хостинг, это только вопрос времени, когда вам нужно будет стать AS (Автономная система) с помощью АРИН или же СПЕЛЫЙ или другую организацию, если ваша компания находится за пределами Северной Америки и Европы.
Затем вам необходимо приобрести (или арендовать) собственный блок IP-адресов. Обычно вы можете получить ipv6 бесплатно. ipv4 закончился, но, по крайней мере, RIPE позволяет вам попасть в список ожидания для /24 (256 адресов), когда со временем они их восстановят. В противном случае вам придется покупать адресное пространство у кого-то (есть торговые площадки, к которым вы можете присоединиться).
И, конечно же, вам нужно работать с провайдерами, которые позволяют вам использовать свои собственные IP-адреса.
Вот пара практических ссылок, которые помогут вам настроить Anycast. Но для начала проигнорируйте биты произвольной рассылки и сосредоточьтесь на настройке в качестве AS, получении IP-пространства и поиске подходящих инфраструктурных партнеров. (Поскольку запуск BGP/anycast не тривиален.)
Недостатки:
- затраты времени на настройку и обучение (например, BGP, если ваш вышестоящий провайдер не справится с этим за вас).
- финансовые вложения (плата за членство/IP для RIPE/ARIN и потенциально большие затраты на приобретение/аренду блоков IPv4).
- ограничено работой с провайдерами VPS, которые позволяют вам использовать свои собственные IP-адреса
- Или вам нужно арендовать место в стойке и заниматься пирингом/маршрутизацией/коммутацией/BGP/и т. д., аппаратными сбоями, мониторингом оборудования SNMP и т. д.
- новые отвлекающие факторы, такие как необходимость подавать заявки и рассматривать жалобы на злоупотребления, связанные с вашим IP-пространством.
Определенно имеет смысл в определенном масштабе или если у вас уже есть навыки и инструменты для управления им.
вариант 3 - нестандартный DNS
Некоторые провайдеры управляемых DNS добавили CNAME-подобная поддержка голого/корневого домена.
Если вы используете одного из этих провайдеров или реализуете его самостоятельно, если используете свой собственный DNS... тогда это может решить проблему.
Смотрите этот ответ
Если вы полагаетесь на это, то вы привязаны к поставщику DNS-провайдеров, которые поддерживают эту нестандартную функцию. Или вам нужно запустить свой собственный DNS и реализовать это самостоятельно.
вариант 4 - CDN
В зависимости от вашего приложения вы можете поместить перед ним другую службу. т. е. служба, подобная CDN (stackpath, cloudflare, aws-cloudfront и т. д.). Эти ребята будут заниматься DNS/любым вещанием и смежными темами, и вы можете попросить своих клиентов указать на службу CDN и запускать свои службы за CDN.
Изменение серверных служб становится изменением конфигурации в CDN (или аналогичном), чтобы сообщить CDN имена/ip-адреса ваших конечных точек, из которых следует запрашивать контент.
Недостатки:
- дополнительные расходы, если вам это не нужно.
- необходимо убедиться, что кешированные и некэшированные (например, приложения) конечные точки настроены в CDN в соответствии с тем, как работают ваши приложения.
- дополнительный уровень, который необходимо отладить, если ваше приложение не работает (CDN прервал запрос или ваше приложение?).
- обычно это означает, что запись CNAME вашего клиента будет указывать на домен CDN, а не на ваш. Ваш домен указан в конфигурации приложения CDN как вышестоящий сервер. Таким образом, у вас есть привязка к поставщику ... если вы хотите переключить CDN, всем вашим клиентам нужно будет обновить свои DNS CNAME, чтобы они указывали на новый. Вы можете смягчить это, поместив 2 уровня CNAME (клиент -> вы -> CDN), но это не очень хорошо с перспектива производительности.
что бы я сделал
Без подробностей о размере вашей клиентской базы, навыках (например, BGP), о том, используете ли вы собственное оборудование или арендуете дешевый VPS...
Я люблю простое, потом всегда можно усложнить. Что может быть самым простым, что снижает мои расходы, не занимает много времени, обеспечивает хороший пользовательский опыт для моих клиентов и, в конечном счете, позволяет мне вернуться к приносящей доход деятельности (вместо того, чтобы тратить время на техническую поддержку, которая имеет временные/финансовые затраты в надежде на снижение общих затрат в масштабе). Я не гугл, поэтому я предпочитаю увеличивать свою прибыль, чем микрооптимизировать прибыль... особенно если в этом нет технической необходимости (пока).
Я бы сделал следующее...
- нет поддержки голого/корневого домена клиентов. клиенты, которым нужна переадресация, могут настроить ее на своей стороне у своих ИТ-специалистов. Одной серьезной головной болью меньше.
- Или, если вы хотите поддерживать это, вы настраиваете один IP-адрес перенаправителя, который, как вы знаете, вы не потеряете (например, эластичный IP-адрес AWS), и настраиваете клиентов.
А и АААА записи. Остальные ваши сервисы не должны размещаться в одном и том же месте (например, редиректор может быть AWS с ELB, если вам нужно масштабировать перенаправление, а клиентские ящики могут быть на дешевых VPS).
- каждый клиент получает предсказуемый (уникальный для него) CNAME на основе его размещенного домена или идентификатора клиента (
CUS1234.example.com имеет больше смысла, если вы даете клиентам возможность легко изменить домен, под которым они размещаются).
- Мой DNS автоматически обновляется на основе моей базы данных клиентов (домены клиентов -> CNAME для конкретного клиента -> IP-адрес, на котором размещено приложение клиента).
- Я могу легко отслеживать DNS этого клиента, и все мои DNS указывают на нужное место.
- Я могу отслеживать DNS-трафик/злоупотребления для каждого клиента отдельно (поскольку у них уникальные имена) с конечной точки клиента.
Клиенты устанавливают свой DNS один раз и никогда не должны менять его, если только они не хотят изменить свой размещенный домен.
Инфра-миграции относительно просты, если у вас есть хорошие механизмы резервного копирования/восстановления/репликации, которые работают в тандеме с некоторой формой обнаружения служб на уровне подготовки вашего сервера/vps/приложения.
- установите низкий DNS TTL в ваших DNS-записях (т. е. имя, на которое указывает CNAME клиента
CUST1234.example.com A 10.0.0.1) за некоторое время до миграции.
- Развернуть новую инфраструктуру, включая репликацию данных из старой инфраструктуры (базы данных, загруженный пользователем контент и т. д.).
- Переключите записи DNS ваших клиентов (
А, АААА), чтобы указать на новые IP-адреса
- Снимите старую инфраструктуру после истечения DNS TTL + margin.
Если ваш сервер данных не может одновременно обрабатывать записи с двух активных конечных точек клиента, вам может потребоваться отключение для миграции... потому что будет некоторое перекрытие по мере истечения срока действия старого кэша DNS.
Преимущество этого типа установки в том, что я могу работать практически с любым авторитетным провайдером VPS, которого захочу (моя автоматическая подготовка не привередлива). Мне не нужно вкладывать средства, чтобы стать AS и справляться с дополнительными накладными расходами по управлению моим собственным IP-пространством (определенно имеет смысл делать это в определенном масштабе... но я не знаю ситуации в вашей компании) .
Я могу делать такие вещи, как балансировка географической нагрузки на основе DNS (возвращать разные IP-адреса для одного и того же имени в зависимости от региона запрашивающего сервера). Это позволяет вам предоставить клиенту несколько серверов под одним и тем же именем в разных регионах (чтобы им не приходилось сталкиваться с трансамериканской или трансатлантической задержкой при загрузке приложения). Вы можете предлагать это отдельно для каждого клиента в качестве дополнительной или дополнительной продажи.
Примечание о балансировке нагрузки...
Я несколько раз упоминал балансировку нагрузки tcp/layer4, не вдаваясь в подробности. Как правило, у вас есть два распространенных типа балансировки нагрузки. layer4/transport/tcp и layer7/application/http(s).
Балансировщик нагрузки layer7/application/http «говорит» на http и завершает ssl-соединение перед передачей запроса (обычно незашифрованного http) на один из нескольких серверов за балансировщиком/прокси. Это просто, но может привести к проблемам, когда серверы за балансировщиком нагрузки не знают, что они должны притворяться, что говорят по протоколу https при написании заголовков, безопасных файлов cookie, перенаправлениях и т. д. Это также означает, что ваш балансировщик нагрузки должен выполнять больше работы. за запрос (анализ http и работа с накладными расходами SSL). Эта дополнительная работа ограничивает масштабируемость балансировщика нагрузки, который обычно представляет собой один узел/машину/vps.
Балансировщику нагрузки уровня 4/tcp не нужно анализировать HTTP-запрос или иметь накладные расходы на завершение SSL. Он ничего не знает о http. Запрос направляется на один из нескольких серверов, которые обрабатывают завершение ssl и обрабатывают HTTP-запрос.
Если вас беспокоит повторное использование сеанса TLS (или его отсутствие), влияющее на производительность, обычно используется Redis или memcached в качестве общего кэша сеанса TLS между несколькими веб-серверами, поэтому вам не нужно беспокоиться о том, что балансировщик нагрузки удерживает пользователей «привязанными» к определенный ящик за балансировщиком нагрузки. нгинкс похоже, что он не поддерживает кеш сеанса TLS вне коробки (кэш используется только между рабочими nginx в одном окне). хапрокси кажется, есть что-то но я не пробовал и не знаю, как это будет работать в haproxy/level4 перед пулом nginx, где происходит завершение ssl.
Вы можете использовать nginx или haproxy в качестве балансировщика нагрузки layer4/tcp, оба довольно просты в настройке. Для более продвинутых вариантов использования (и, возможно, лучшей производительности) вы также можете взглянуть на виртуальный сервер Linux (LVS).
Другой способ распределения нагрузки — возврат нескольких записей A или AAAA для одного имени. В идеале DNS-клиент выбирает случайным образом из возвращаемых адресов, поэтому вы получаете некоторое распределение нагрузки по нескольким IP-адресам. Если вы начинаете сталкиваться с проблемами масштабирования на уровне балансировщика нагрузки, это низкотехнологичный способ добавить еще немного масштаба (просто добавьте еще один балансировщик нагрузки для того же или другого пула серверов приложений). Однако ничто не заставляет клиентов циклически перебирать ваши IP-адреса... так что это не дает вам большого контроля над тем, какие IP-адреса получают нагрузку... но это лучше, чем ничего.
