Примечание: мы используем автономный Puppet (без мастера), т.е.
Обычно при развертывании веб-приложения существует ряд серверных служб и приложений, которые запускаются за клиентским приложением - такие вещи, как база данных, поисковый сервер, кэширующий сервер, другие внутренние службы и т. Д. Эти службы не нуждаются в прослушивании. на интерфейсах общедоступной сети. Вместо этого они могут прослушивать частный сетевой интерфейс, и все приложения могут безопасно обмениваться данными через него. Я уже этим занимаюсь.
Проблема возникает, когда вы хотите автоматически развернуть эти службы. Мы используем 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 и т. Д.? Как вы, ребята, решаете подобные проблемы?
Это явно не так просто, как кажется на первый взгляд. В случае с AWS существуют специальные факты, которые говорят о том, что вы используете AWS, например:
# facter -p | grep ^ec2 |wc -l
33
Общедоступный IP-адрес сохраняется в факте ec2_public_ipv4. Итак, AWS легко обнаружить.
Но в DigitalOcean - в самой виртуальной машине нет ничего, что указывало бы на то, что она работает в DigitalOcean. Единственный интересный факт, который я вижу:
# facter -p | grep kvm
virtual => kvm
Amazon использует xenhvm. Если SoftLayer использует что-то другое, кроме xen / kvm, вы можете использовать этот факт в качестве отправной точки. Вне всяких сомнений, этот метод не очень надежен, потому что каждый из них может изменить технологию virt в какой-то момент времени, что может сделать все ваши виртуальные машины на этом провайдере неработоспособными.
Я бы посоветовал вам написать свой собственный факт, который будет учитывать все ваши знания о различных облачных провайдерах, которые вы используете, а затем решать, какие IP-адреса предоставлять вам скрипты. К сожалению, другого пути нет.