Обнаружение провайдера инфраструктуры в Puppet
Примечание: мы используем Puppet standalone (master-less), т. Е. Puppet apply.
Обычно при развертывании веб-приложения существует ряд внутренних служб и приложений, которые работают за внешним приложением - такие как база данных, сервер поиска, сервер кэширования, другие внутренние службы и т. Д. Эти службы не должны прослушивать. на общедоступных сетевых интерфейсах. Вместо этого они могут прослушивать интерфейс частной сети, и все приложения могут безопасно обмениваться данными. Это то, что я уже делаю.
Проблема возникает, когда вы хотите автоматически развернуть эти службы. Мы используем Puppet для обеспечения. Когда эти службы развернуты, мы полагаемся на факты, чтобы подобрать такие вещи, как ipaddress и hostname. В зависимости от того, где находится ваша машина, имя интерфейса может отличаться. Например, идентификаторы в машинах, предоставляемых Soft Layer, - это bond0, bond1 и т. Д., А Digital Ocean предоставляет идентификаторы eth0, eth1 и т. Д. Из них, скажем, bond0 и eth0 являются открытыми интерфейсами, а bond1 и eth1 являются частными.,
В идеале, мы должны использовать одни и те же сценарии Puppet для обеспечения инфраструктуры независимо от того, где вы осуществляете подготовку. И мы используем hiera для выбора значений по умолчанию для классов. Поэтому в идеале я хотел бы, чтобы такие факты, как ipaddress_public, ipaddress_private, были доступны, и тогда я мог бы использовать их так, как хочу для любого класса в Puppet. И этот факт должен скрыть мрачные детали выяснения, где находится машина, то есть Soft Layer, Digital Ocean, AWS и т. Д., И получить мне факт для работы. Или я могу создать иерархию для поставщика инфраструктуры в hiera и иметь разные значения по умолчанию для разных поставщиков инфраструктуры.
Проблема в том, что я не знаю, как определить поставщика для конкретной машины. Так, например, если я дам вам машину для запуска Puppet, есть ли надежный способ выяснить, работает ли она на Soft Layer, Digital Ocean, AWS и т. Д.? Как вы, ребята, решаете подобные проблемы?
1 ответ
Очевидно, что это не так просто, как кажется. В случае с AWS есть пользовательские факты, которые сообщают вам, что вы находитесь на AWS, например:
# facter -p | grep ^ec2 |wc -l
33
Публичный IP-адрес сохраняется в факте ec2_public_ipv4. Таким образом, AWS легко обнаружить.
Но в DigitalOcean - внутри самой виртуальной машины нет ничего, что указывало бы на то, что она работает в DigitalOcean. Единственный интересный факт, который я вижу:
# facter -p | grep kvm
virtual => kvm
Амазонка использует xenhvm. Если SoftLayer использует что-то другое, а не xen/kvm, вы можете использовать этот факт в качестве отправной точки. Конечно, этот метод не очень надежен, потому что каждый из них может в какой-то момент изменить виртуальную технологию, что может привести к неработоспособности всех ваших виртуальных машин на этом поставщике.
Я хотел бы предложить вам написать свой собственный факт, который будет учитывать все ваши знания о различных облачных провайдерах, которых вы используете, а затем решать, какие IP-адреса будут предлагаться вам сценариями. К сожалению, другого пути нет.