Несколько Vagrant VM через PuPHPet с разными конфигурациями

Я чувствую, что упускаю что-то фундаментальное. Как использовать PuPHPet для определения двух машин в одном vagrantfile, обе Ubuntu 14.04, но одна с установленным mysql, а другая с elasticsearch? Я вижу, как определить несколько машин, но конфигурация каждой из них кажется одинаковой???


person Matt Fletcher    schedule 09.06.2016    source источник
comment
Конфиг, вероятно, один и тот же, но если вы посмотрите puphpet/config.yaml для каждой машины, он будет другим.   -  person Frederic Henri    schedule 09.06.2016
comment
@FrédéricHenri, спасибо, но я имею в виду несколько машин, созданных из одного (сгенерированного PuPHPet) Vagrantfile. PuPHPet позволяет создавать несколько машин в одном файле, но, похоже, кроме самой основной информации (имя хоста и IP-адрес), они являются клонами друг друга. Это сильно отличается от вариантов использования, описанных по адресу: vagrantup.com/docs/multi-machine< /а>   -  person Matt Fletcher    schedule 10.06.2016
comment
puppet multi-machine основан на бродячей мультимашине (см. блог .puphpet.com/blog/2016/03/04/multi-machine-support : С помощью этого недавнего обновления вы можете создавать идентичные машины, которые вы можете развернуть у любого поставщика, которого пожелаете ), однако вы можете легко продублировать config.yaml и создать по одному для каждой машины, чтобы вы могли предоставлять другое программное обеспечение.   -  person Frederic Henri    schedule 10.06.2016
comment
И как бы вы указывали один Vagrantfile на несколько config.yaml?   -  person Matt Fletcher    schedule 10.06.2016


Ответы (1)


Это изначально не поддерживается через графический интерфейс PuPHPet, но... вы можете легко реализовать это.

Примечание. Я не буду предлагать поддержку для следующего через трекер PuPHPet на github. Пожалуйста, не размещайте билеты для этого. Тем не менее, я использую что-то похожее на некоторых внештатных клиентов, и это работает хорошо.

PuPHPet поддерживает несколько файлов конфигурации, каждый из которых расширяет и переопределяет предыдущий.

Взгляните на puphpet/puppet/hiera.yaml:

---
:backends: yaml
:yaml:
    :datadir: '/'
:hierarchy:
    - vagrant/puphpet/config-custom
    - vagrant/puphpet/config-%{::provisioner_type}
    - vagrant/puphpet/config
:merge_behavior: deeper
:logger: console

Hiera загружает файлы конфигурации в обратном порядке, поэтому он идет config.yaml -> config-%{::provisioner_type}.yaml -> config-custom.yaml.

Вы можете вставить новую строку ниже config-custom: - vagrant/puphpet/config-%{::server_type}

Это добавит любые пользовательские настройки из этого файла в среду Puppet. Однако вам все равно нужно, чтобы Vagrant знал об этом, потому что Vagrant читает из Vagrantfile для выполнения команд. Вам также может потребоваться выполнить некоторые специальные действия для каждого отдельного типа сервера. Обратите внимание, что server_type в этом контексте может означать что-то вроде proxy, app, db, jenkins и т. д.

В корневом каталоге PuPHPet, где существуют каталоги Vagrantfile и puphpet, создайте новые каталоги, названные в соответствии с вашими типами серверов.

Например, создайте новый каталог db, удалите свой Vagrantfile и создайте новый в этом новом каталоге, а также создайте config-db.yaml внутри каталога puphpet:

$ tree -L 2
.
├── db
│   └── Vagrantfile
└── puphpet
    ├── config-custom.yaml
    ├── config-custom.yaml.dist
    ├── config-db.yaml
    ├── config.yaml
    ├── files
    ├── puppet
    ├── ruby
    ├── shell
    └── vagrant

Содержимое вашего db/Vagrantfile может выглядеть следующим образом:

# -*- mode: ruby -*-

dir = File.dirname(File.expand_path(__FILE__))
dir = "#{dir}/.."

server_type = 'proxy'

VAGRANT_DOTFILE_PATH = "#{dir}/.vagrant";
currpath = ENV['VAGRANT_DOTFILE_PATH'];
if(currpath.nil?)
    currpath = '.vagrant';
end
if(currpath != VAGRANT_DOTFILE_PATH)
    ENV['VAGRANT_DOTFILE_PATH'] = VAGRANT_DOTFILE_PATH
    args = ARGV.join(' ');
    system "vagrant #{args}"

    if Dir.exists?('Directory Name')
        FileUtils.rm_r(currpath)
    end

    abort "Finished"
end

require 'yaml'
require "#{dir}/puphpet/ruby/deep_merge.rb"
require "#{dir}/puphpet/ruby/to_bool.rb"
require "#{dir}/puphpet/ruby/puppet.rb"

configValues = YAML.load_file("#{dir}/puphpet/config.yaml")

provider = ENV['VAGRANT_DEFAULT_PROVIDER'] ? ENV['VAGRANT_DEFAULT_PROVIDER'] : 'local'
if File.file?("#{dir}/puphpet/config-#{provider}.yaml")
  custom = YAML.load_file("#{dir}/puphpet/config-#{provider}.yaml")
  configValues.deep_merge!(custom)
end

if File.file?("#{dir}/puphpet/config-#{server_type}.yaml")
  custom = YAML.load_file("#{dir}/puphpet/config-#{server_type}.yaml")
  configValues.deep_merge!(custom)
end

if File.file?("#{dir}/puphpet/config-custom.yaml")
  custom = YAML.load_file("#{dir}/puphpet/config-custom.yaml")
  configValues.deep_merge!(custom)
end

data = configValues['vagrantfile']

Vagrant.require_version '>= 1.8.1'

Vagrant.configure('2') do |config|
  eval File.read("#{dir}/puphpet/vagrant/Vagrantfile-#{data['target']}")
end

Теперь мы рассказали Vagrant о новом файле конфигурации по адресу #{dir}/puphpet/config-#{server_type}.yaml -> #{dir}/puphpet/config-db.yaml -> ..

Создайте столько из них для столько типов серверов, сколько вам нужно.

Если вы хотите, чтобы Puppet знал о значении server_type, вы можете передать его как фактор. Обновите файлы vagrant/Vagrantfile-* с помощью:

puppet.facter = {
    'server_name'      => "#{machine['id']}",
    'server_type'      => "#{server_type}",
    'fqdn'             => "#{machine_id.vm.hostname}",
    'ssh_username'     => "#{ssh_username}",
    'provisioner_type' => 'local',
}

и он будет доступен в ваших манифестах Puppet как $::server_type.

Так что же на самом деле здесь происходит?

Что ж, в вашем config.yaml (т. е. в основном файле конфигурации) вы можете настроить самые основы вашей фермы серверов. Каждому серверу могут потребоваться такие пакеты, как git, или определенные порты, открытые брандмауэром. Вы можете добавить эти значения туда.

Настройте серверные приложения так, чтобы они не устанавливались в вашем config.yaml:

mongodb:
    install: '0'
    settings:
        bind_ip: 127.0.0.1
        port: '27017'
    globals:
        version: 2.6.0
    databases: {  }

В вашем config-db.yaml вы можете установить значения для БД по своему усмотрению:

mongodb:
    install: '1'
    settings:
        ensure: true
        package_name: mongodb-org-server
        bind_ip: "%{::ipaddress_tun0}"
        port: '27017'
        config: /etc/mongod.conf
        replset: rsmain
    globals:
        bind_ip: "%{::ipaddress_tun0}"
        version: 3.2.6
        service_name: mongodb
    databases:
         your_db:
             name: db_name
             user: db_user
             password: 'awesome_password'

Теперь ваш сервер базы данных подхватит эти изменения и применит их по мере необходимости. Ваш сервер приложений (или jenkins/proxy/etc) по-прежнему будет видеть mongodb как не требующий установки из config.yaml. Таким образом вы можете создавать довольно сложные фермы с помощью нескольких простых файлов YAML.

Последнее, что нужно отметить, это то, что, поскольку это многосерверная среда, Vagrant должен знать, на каком сервере работать, когда вы запускаете большинство команд. Вы делаете это, используя идентификатор машины, который вы хотите установить в каждом файле config-#{server_type}.yaml. Каждый файл может иметь несколько машин, определенных для его типа. Затем просто добавьте идентификатор машины к бродячим командам:

vagrant up db1, vagrant destroy -f db1 и т. д.

Я надеюсь, что это ответит на все ваши вопросы или, по крайней мере, поможет вам достичь большей части того, чего вы пытаетесь достичь!

person Juan Treminio    schedule 21.06.2016