我想说,您选择 Vagrant 已经是您正在寻找的一个好的开始,但现在您需要更深入地研究 Chef 或 Puppet,以进一步自动化您的配置过程。
我想在您的场景中一个不错的选择是首先将 Vagrantfile 和相应的 Puppet 清单作为项目的一部分置于版本控制之下。此外,关于这台机器的所有配置也应该被放入版本控制和/或通过某种工件存储库提供。
其次,在团队中建立规则,如果认为环境的更改(至少应该持续更长时间)需要为其他团队成员准备好,则需要签入这些更改。
关于您的第二个问题,回到我的开头:Puppet(我喜欢)或 Chef 是您选择的工具,可以为您和您的同事在未来节省大量工作。我会在这里坚持 Puppet,因为我不太了解 Chef。
使用 puppet,您可以管理所有您想要的东西,包的安装,更改配置并确保某些服务正在运行,或者通常系统具有您想要的状态。更好的是,如果您或其他团队成员对他/她的盒子进行了一些恶意更改,您可以回滚您的 Vagrantfile/Puppet 清单中的更改,输入
vagrant destroy && vagrant up
并且该框很容易恢复到最后的版本化状态。
例如,采用以下清单文件:
package { "mysql-server-5.1":
ensure => present
}
file { "/etc/mysql/my.cnf":
owner => "root",
content => "http://myrepository.local/myProject/configurations/mysql/my.cnf",
require => Package["mysql-server-5.1"]
}
service { "mysql":
ensure => running,
subscribe => File["/etc/mysql/my.cnf"],
require => File["/etc/mysql/my.cnf"]
}
它的作用是,它首先检查你的盒子中操作系统的包机制(示例中的名称假设是最近的 Ubuntu)是否安装了包“mysql-server-5.1”,如果没有安装,它将安装它。通过 'require' 属性,第二个指令将在第一个指令之后执行(并且仅当它有效时),将 MySQL 配置更改为您也已签入和/或发布到您可以访问的位置的配置(也可以是放入与 Vagrantfile 相同的文件夹中,然后将在 /vagrant 下的框中可用)。最后一步,只有在配置更改有效时才会执行,这将确保“mysql”服务启动并运行,或者如果在更改配置时它已经在运行,它将重新启动。
现在你可以在你的 Vagrantfile 中连接这个清单:
Vagrant::Config.run do |config|
config.vm.box = "lucid32"
config.vm.box_url = "http://files.vagrantup.com/lucid32.box"
config.vm.define "node1" do |cfg|
cfg.vm.network "10.23.5.11"
cfg.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.manifest_file = "node1.pp"
end
end
end
除了像这样对环境进行的“尝试性”之外的所有更改,所有团队成员都可以轻松地进行相同的设置,并且触手可及。
我个人喜欢在盒子上手动尝试一些东西,当我找到正确的设置和配置时,将其转换为 Puppet 清单,以备日后使用并与团队成员共享。
由于 Puppet(和 Chef 也)几乎可以管理您需要的所有内容(用户、cron 作业、包、服务、文件……),因此它是解决此类问题的好选择,您甚至可以使用如果您愿意,可以在以后配置登台或测试环境。它们是 Puppet 的更多选择,通读语言指南应该会让您很好地了解您可以用它做些什么。
希望我能帮忙:)