Мы переносим наше развертывание с обычного EC2 на VPC, у нас есть два балансировщика нагрузки в общедоступном облаке, на которые указано несколько записей домена «A», однако я не понимал, что общедоступный эластичный IP-адрес не может быть подключенный к экземпляру VPC, вы должны использовать эластичные IP-адреса на основе VPC.
Итак, вы знаете, что наши LB - это экземпляры на основе HAProxy, а НЕ эластичные балансировщики нагрузки. Итак, у нас есть Apache, с которым можно поработать, если это поможет ответить на мой вопрос или предложит альтернативу.
Поскольку не все рассматриваемые домены, указывающие на общедоступные LB, находятся под моим контролем, очень сложно запланировать изменение DNS для всех, позвольте назвать это невозможным.
Итак, у меня вопрос: могу ли я перенаправить вызовы наших публичных LB на их замену в VPC? Это должно быть прозрачным, пока мы просматриваем наших клиентов и заставляем их обновлять свои DNS.
Любые предложения будут ценны!
РЕДАКТИРОВАТЬ: Чтобы немного расширить, было бы полезно, если бы я мог сделать это, просто используя функции EC2, поэтому мне не нужно поддерживать работу двух общедоступных экземпляров LB. В противном случае мне нужно знать, как именно выполнить «перенаправление», выполняется ли это в DNS или где-то еще?
РЕДАКТИРОВАТЬ 2: Никто не смог предложить какое-либо понимание конкретного разрешения Amazon, которое не требовало, чтобы экземпляры LB оставались включенными, поэтому я обрисовал, что мы сделали с HAProxy в выбранном ответе ниже.
Вы можете перенаправить запросы к обычным балансировщикам нагрузки EC2 на балансировщики нагрузки VPC. Это дополнительный шаг для всех, кто не обновлял свой DNS, но это лишь временная и хорошая мотивация для ваших клиентов обновить как можно скорее.
Поскольку никто не смог предоставить подробностей, вот что мы сделали:
Во-первых, мы клиент RightScale, поэтому, если вы тоже, вам нужно отключить reconverge сценарий, который запускается каждые 15 минут или около того с использованием предоставленного операционного сценария. Это предотвратит перезапись сценария ваших изменений, если он не найдет активных серверов приложений и удалит все ссылки.
Далее в /etc/haproxy мы обновили haproxy.cfg backend, последняя строка того, что выглядит по умолчанию:
# Special server line that allow HAProxy to start with cookies enabled and no valid servers.
server disabled-server 127.0.0.1:1 disabled
Итак, чуть ниже того места, где будут определены серверы приложений, мы включили:
server THE-INSTANCE-REF_ID 123.123.123.123:80 check inter 3000 rise 2 fall 3 maxconn 500
У нас есть два LB, поэтому мы просто указали один старый на один новый соответственно. Все работает как шарм. Мы оставим эти два старых LB на пару недель, пока наши клиенты обновляют свои DNS, а затем отключают их, избавляя от многих головных болей, вместо того, чтобы пытаться организовать ИТ всех по расписанию!
Если вы пытаетесь скрыть локальную информацию DNS, я предлагаю вам один из лучших вариантов:
a) Установите внутренний DNS-сервер, должным образом защищенный брандмауэром, чтобы обслуживать только DNS-запросы в вашей системе.
б) Автоматизировать управление отдельными файлами / etc / hosts (Chef, Puppet, CFEngine, Ansible и т. д.)
Если вас не интересует раскрытие информации DNS через общедоступный запрос, почему бы просто не использовать информацию CNAME у вашего внешнего поставщика DNS (или AWS Route53), например:
example.yourdomain.com => ec2-10-10-10-10.compute-1.amazonaws.com