CoreOS: введите настоящий частный IP-адрес в etcd2 cloud-config

У меня есть три сети в Rackspace:

  1. Публичная сеть
  2. Сервисная сеть 10.181.XXX.XXX (иногда они называют это частной сетью, но она не является частной по сути, она является частной для всего центра обработки данных, поэтому ее арендаторы могут делиться ею)
  3. Настоящая частная сеть 192.168.3.0/24 созданный через сетевой интерфейс

Я планирую запустить безопасный кластер CoreOS, etcd сверстники и клиенты ограничены реальной частной сетью, поэтому она недоступна для внешнего мира.

Итак, я запустил сервер CoreOS, и у него было три интерфейса:

  1. eth0 имеет IP-адрес публичной сети - хорошо
  2. eth1 есть IP адрес сервисной сети - хорошо
  3. eth2 имеет IP-адрес частной сети - отлично!

Все выглядело хорошо, но etcd связан с сервисной сетью, а не с частной, которую я создал вручную. Вот кусок cloud-config:

#cloud-config
    coreos:
      etcd2:
        discovery: https://discovery.etcd.io/XXX
        advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001
        initial-advertise-peer-urls: http://$private_ipv4:2380
        listen-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001
        listen-peer-urls: http://$private_ipv4:2380

Который означает, что $private_ipv4 переменная расширяется до eth1 IP-адрес, вот содержимое /etc/environment:

COREOS_PUBLIC_IPV4=166.78.XXX.XXX
COREOS_PRIVATE_IPV4=10.181.XXX.XXX

Хорошо, похоже, что Rackspace внедряет свои собственные сети, это объяснимо. Но значит ли это, что etcd заблокирован только для первых двух сетей, и нет способа настроить его на использование настоящей частной сети?

Я пробовал кучу хаков, таких как это:

listen-peer-urls: http://`/usr/bin/ifconfig eth2 | /usr/bin/grep --word-regexp inet | /usr/bin/awk '{print $2}'`:2380

и другие, но не были должным образом выполнены или заменены в cloud-config,

Мои вопросы:

  1. Я делаю что-то странное с точки зрения поля настройки кластера CoreOS, чтобы я не мог достичь цели легко и естественно? Если да, то как бы вы выложили безопасный кластер, etcd работает в реальной частной сети?
  2. Есть ли способы "вставить" динамические значения в cloud-init файл, так что он интерполируется во время выполнения? Проблема в том, что IP-адрес не известен заранее, поэтому я думаю, что его нужно получить и ввести как-то.
Источник

2 ответа

Решение

Это решено. Etcd2 теперь работает в реальной частной сети по сравнению с ServiceNet. Вот как - я создал системный плагин для etcd2.service где он явно устанавливает конфигурацию среды, такую ​​как ETCD_ADVERTISE_CLIENT_URLS=${URL}:2379 вместо того, чтобы полагаться на переменные, такие как $private_ipv4 а также $public_ipv4,

Я написал быстрый инструмент для этой работы - реализацию, образцы и документацию можно найти здесь. Оставьте строку, если у вас есть какие-либо вопросы или предложения!

Источник

Они также предоставляют способ создать свою собственную частную сеть и подключить к ней свой сервер. Как объяснил КБ, ID статьи: 2163. Если вы это сделаете и удалите интерфейс, связанный с servicenet, это больше не будет проблемой. Однако предостережение от этого заключается в том, что у вас больше не будет возможности использовать службы, связанные с servicenet. Подробнее о хитросплетениях можно узнать из их статьи в КБ: 2250.

Или вы можете настроить брандмауэр так, чтобы только те службы, для которых вы используете / нуждаетесь в servicenet, могли получить доступ к вашему серверу. Вы даже можете пойти в мир организации настоящей частной сети через облачное устройство vyatta и при этом сохранить доступ к сервисам Rackspace, как описано в статье KB ID: 3454.

Все эти статьи можно найти по адресу: http://www.rackspace.com/knowledge_center/

В конечном счете, вам придется взвесить, какой вариант подходит вам лучше всего.

НТН

Источник
Другие вопросы по тегам