vagrant 知识库

时间 2019-11-09

标签 vagrant 知识库繁體版

原文原文链接

版权声明：转载时请以超连接形式标明文章原始出处和做者信息及本声明
http://wushaobo.info/?p=83

Vagrant让虚拟化技术走近寻常家。脚踏实地地说，网络上相似“两分钟入门”的文章有很多，但求助各类问题的帖子更多，由于vagrant官网的文档太简洁了，这里头有些道理有些坑，都没涉及到。即使是O’Reilly两天前出版的《Vagrant: Up and Running》也含糊着某些问题。于是在Google了各类的前人零碎经验的基础上、以本身实践证实以后，有了我这篇文章，但愿对涉及到的这些问题能汇总知识作一个澄清，并给读者一个可操做的指导。html

文章结构

vagrant 的便利
vagrant 怎么玩
vagrant 到底怎么玩
— vagrant 基础模板哪儿找
— 辨析 vagrant box | .box文件 | VM | .iso文件
— Vagrantfile 怎么配
——- [HOWTO] 指定要使用的vagrant box和设置VM名称
——- [HOWTO] 设置VM对宿主机和外部机器的网络链接
——- [HOWTO] 配置并启动VM后运行后续安装脚本
疑难杂症
— VM上端口的可访问性
— 修改默认ssh端口
— 将VM打包成*.box文件前清理网络设置上的障碍
— 设置共享目录位置与读写权限
— 多个VM的配置和启动

vagrant 的便利

打造Virtual Machine的过程当中可放手作尝试，反复从某个基础模板开始安装或设置。可快速推倒重来，可步步为营。
可快速在一台宿主机上搭建多VM的EndToEnd环境。
管理开发环境，可脚本化复制、操纵等行为，提升自动化程度。

vagrant 怎么玩

简单点说，三步走：linux

安装 vagrant 、VM软件（ Virtualbox 是主流，后文也默认以此为例）
给vagrant添加基础模板（box）
配置Vagrantfile后用vagrant启动VM

满共就三个命令，有些人玩到这就以为已经伟大的不得了了，至此ssh上VM各类虐。web

你还差得远 !shell

vagrant 到底怎么玩

vagrant 基础模板哪儿找

www.vagrantbox.es 介绍了vagrant的基础模板，并提供了知足各类需求的*.box文件供下载。apache

推荐选择 minimal + guest additions + puppet|chef 的box，理由：ubuntu

小，就意味着资源占用少
Virtualbox共享目录须要guest additions
预装puppet或chef并不是必选。它们对将来提高VM配置自动化有好处，自己不大

辨析 vagrant box | .box文件 | VM | .iso文件

解释词汇：windows

打包了操做系统的 *.iso文件是没法被vagrant直接使用的
VM 是可启动/已启动的虚拟机
*.box文件是vagrant可接受的基础模板文件
vagrant box 指vagrant已安装好的基础模板

辨析关系：centos

*.iso文件可经Virtualbox界面的手动安装获得可启动的 VM
VM 可被vagrant package命令打包成为 *.box文件
*.box文件可被vagrant box add命令安装为 vagrant box
vagrant box 可被vagrant在Vagrantfile中指定为 VM 运行的基础模板

Vagrantfile 怎么配

Vagrantfile是vagrant配置VM的起点，官方文档里零零散散的说明让我明白了“东西很简单，但找对不容易”这句话。网络

对Vagrantfile，有几个常问 HOWTO ：ssh

指定要使用的vagrant box和设置VM名称
设置VM对宿主机和外部机器的网络链接
配置并启动VM后运行后续安装脚本

[HOWTO] 指定要使用的vagrant box和设置VM名称

一看便知。

Vagrant.configure("2") do |config|      # ‘2’的意思是我所用的vagrant-1.2.2属于内部v2版 
  config.vm.define :web do |web_config| # 设置此VM名称为web
    web_config.vm.box = "apache-centos" # 指定使用已安装的名为“apache-centos”的vagrant box
  end
end

参考

[HOWTO] 设置VM对宿主机和外部机器的网络链接

当VM只与宿主机通讯时，可设置为私有网络，等效于设置virtualbox使用host-only模式网络适配器。
```
config.vm.network :private_network, ip: "192.168.50.4"
```
当寄宿与同一宿主机上的多台VM之间也需相互通讯时，设置各VM为私有网络，但将固定IP设为同一网段。
当VM须要与宿主机网络内的其余机器通讯时，设置为公开网络，等效于设置virtualbox使用bridged模式网络适配器，默认DHCP获取地址。
```
config.vm.network :public_network   # vagrant-1.2.2以后的版本可能改用 :bridged
```

参考

[HOWTO] 配置并启动VM后运行后续安装脚本

追求简单，那么下面两条配置其一就够用了

config.vm.provision :shell, :inline => "ifconfig"  # inline script

 config.vm.provision :shell, :path => "initialize.sh"  # external script

不得不复杂时， Chef / Puppet / Ansible 都是可供你用的。细致配置见参考。
自动化部署是好的，但若是是VM每次安装固定软件，那么就没必要了。大能够将不变的软件安装配置完成后，将VM打包成为*.box文件静态化，之后以此box文件做为基础模板作进一步配置。步步为营的提高基础的实践，会加速VM搭建过程并减小配置脚本。

疑难杂症

VM上端口的可访问性

尤为对不连外网的VM，咱们辛苦建了它却不能访问它的端口，那要它何用？防火墙是阻止端口访问的罪魁，索性关了它吧。

Centos/Redhat/Fedora 用iptables管理firewall，因此两个办法搞掉它

停掉iptables的服务, 参考

$ sudo service iptables save
 $ sudo service iptables stop
 $ sudo iptables off

索性干掉iptables的全部规则, 参考

$ sudo iptables -F
 $ sudo iptables -X
 $ sudo service iptables save

Ubuntu 用ufw管理firewall，关掉它就是了，参考

$ sudo ufw disable

修改默认ssh端口

场景

ssh端口默认22，那位说“为何我要改它呢”，我例举一个场景：

假如你要开发一个包含SFTP server的应用。为了给使用者提供便利，你最好保留22端口给用户，使他能使用默认方式经过SFTP传文件。同时，你要将这个应用部署到VM上作测试，那么VM的ssh login就不能同时也用22端口了，你须要为它指定新端口，如 10022。

难点

难点在于下面的约束条件：

原有VM的基础模板默认使用22端口，因此vagrant 不能一开始就弃用22端口，不然VM没法访问。
VM上ssh端口的改变为新端口后，再重启VM前须要更改Vagrantfile以选用新端口。
vagrant ssh命令并不直接访问VM的ssh端口，而是经过访问宿主机的22XX端口来间接ssh login到VM上。
vagrant内置了从宿主机22XX端口向VM的22端口的映射，若是VM的新端口并无被指定映射到宿主机的某个端口上，vagrant ssh命令仍会访问原来的宿主机22XX端口即VM的22端口。（vagrant选择22XX端口时的尝试路线是：2222 -> 2201 -> 2202 -> 2203 -> … ，以此保证多台VM启动时不会有端口冲突。）

坑是挺多的吧？Vagrantfile的 ssh settings参考和 forwarded ports参考可没把这事儿说这么清楚。

行动大纲

解决问题需要分几步走：

预先在Vagrantfile中为VM的新端口作端口映射
VM上修改ssh使用的端口到新端口
在Vagrantfile中指定ssh login时使用VM的新端口
[非必作] 创建新基础模板以固化上述更改

按步骤走起

Step1: 在Vagrantfile中为VM的新端口作端口映射

config.vm.network :forwarded_port, guest: 10022, host: 2255
# config.ssh.port = 2255            # port of host  # commented in step1
# config.ssh.guest_port = 10022     # port of VM    # commented in step1

Step2: VM上修改ssh使用的端口到新端口

VM上将22端口换为10022端口：vi编辑sshd_config文件（ Centos/Ubuntu: /etc/ssh/sshd_config ；Mac OS X: /etc/sshd_config ）
```
:%s/#Port 22/Port 10022/g
  :wq
```
重启sshd服务
```
$ sudo service sshd restart
```

Step3: 在Vagrantfile中指定ssh login时使用VM的新端口

config.vm.network :forwarded_port, guest: 10022, host: 2255
config.ssh.port = 2255          # port of host  # uncommented in step3
config.ssh.guest_port = 10022   # port of VM    # uncommented in step3

Step4 [optional]: 创建新基础模板以固化上述更改

使用vagrant package命令将改过端口的VM保存为box文件。由这个新基础模板所产生的VM中，10022即为ssh访问端口，使用上述的Vagrantfile可直接经过vagrant ssh访问。

vagrant package <vm-name> --output <new-base.box>

生成新*.box文件前须清理网络设置上的障碍。详见下文。

将VM打包成*.box文件前清理网络设置上的障碍

将手动配置过的VM从新打包生成*.box文件做为新基础模板，在这件事上对linux-based的VM有个关于网络设置的障碍。

问题表现

例如设置了private network（等同于virtualbox设置host-only模式的网络适配器）的VM，若不作准备而直接使用vagrant package生成新box文件，那么安装此box文件到vagrant box后在启动VM时，会发现当前Vagrantfile指定的private network配置失败。

[default] Configuring and enabling network interfaces…

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifup eth1 2> /dev/null

被启动的VM以让能够经过vagrant ssh命令去访问，但网络配置上却没有host-only模式的适配器。

分析解决

还记得配置private network时设置的固定ip地址么？是的，问题就在持久网络设备udev规则（persistent network device udev rules）是被原VM设置好的，再用box生成新VM时，这些rules须要被更新。而这和Vagrantfile里对新VM设置private network的指令发生冲突。

既然之后在Vagrantfile里显示地设置private network ip是免不了的，那么只要在生成box文件前干掉udev规则就是了。

sudo rm -f /etc/udev/rule.d/70-persistent-net.rules

题外话

有趣的是这篇参考细述了这个问题的因果与对策，反却是O’Reilly出版的《Vagrant: Up and Running》一书中（第6章）对此含糊带过。

该书计划于2013年6月12日出版。试读版中尚仍有对过期命令的介绍（如“repackage”），但愿正书出来了不会当即过期。

学习的话，官网文档仍是应该对照的。

设置共享目录位置与读写权限

Virtualbox共享目录须要VM上装有Guest Additions。本身安装到VM再打包成box文件作基础模板，或者一开始就找好合适的box文件（前文提到过），随便你怎么整好。

vagrant 默认将宿主机上Vagrantfile所载目录共享至VM上的 /vagrant 目录。

咱们常须要的是指定共享某个目录，为此vagrant 支持两种方式：

简单：vboxsf

vboxsf是 V irtual boxS hared F older（或 VboxS hared F older）的缩写。不少人知道能够指定vboxsf做类型来mount，殊不知这个这个词全称，甚至误解为“虚拟机文件系统”而错写成vboxfs。

vagrant默认使用这种方式共享目录。优势方便，缺点是性能很差。配置时，只要在Vagrantfile里指明：

config.vm.synced_folder "path/on/host", "/absolute/path/on/vm"

前一个参数须是宿主机上已存在的目录，若为相对目录，那是相对Vagrantfile所在目录。
后一个参数须是VM上的绝对路径，若不存在，vagrant会在启动VM时建好，多层的目录也不要紧。

正经：NFS

NFS是正途，不过它也挑剔。

vagrant 内置了宿主机和VM两端对NFS的支持与配置的协调。若是你用windows，那vagrant看成你的配置不存在，直接忽略（我也以为你在瞎胡闹）。Vagrantfile里很容易，标上标记就好了：

config.vm.synced_folder "path/on/host", "/absolute/path/on/vm", :nfs => true

两个目录能够同样，如都用 “/shared” ，藉此创建多个机器节点的共享存储了。

NFS的共享目录这种方式的挑剔之处在于目录内的读写权限。

读写权限

以创建宿主机与VM的共享存储这个应用场景为例，目标是：

两端对共享目录（ /shared ）的读写无限制
没有root权限的麻烦

若是你在宿主机建 /shared ，而后直接配置关联，那对上述两个目标你都会失败。按我说的步骤来吧：

宿主机上将创建的共享目录改成可读写
```
$ sudo chmod o+w /shared
```
设置为non-root用户全部
```
$ sudo chown <user>:<group> /shared
```

配置了Vagrantfile后启动VM

config.vm.synced_folder "/shared", "/shared", :nfs => true

这样获得的共享目录对场景设定的目标已大功告成了：

在宿主机和VM两端都它都不是root用户全部
- 宿主机上 /shared 属于例如twer用户。
- VM上 /shared 所属的用户会是个数字，如1000。
在宿主机和VM两端它都对读写无限制

多个VM的配置和启动

单Vagrantfile vs 多Vagrantfile

虽然vagrant支持在一个Vagrantfile中配置多个VM，但我我的喜欢为各VM写各自的Vagrantfile。

一来，各个VM的配置和启动都相对独立，如vagrant ssh时可不指定VM名，用默认。
二来，Vagrantfile也不至于经常要改。

不过真正的牛人没我这么小家子气。用统一的一个Vagrantfile来管理多个VM，从大局着眼确是有好处的：

一个Vagrantfile收录了整个大环境中全部VM的基本配置，维持了虚拟网络的上下文完成。你一眼就知道环境里共有哪些VM，也不须要切换目录来检查各VM的状态，跟不会搞混了目录“丢掉”哪一个倒霉的VM。
更多地使用Chef/Puppet来配置各VM，好比把VM的ip配置从Vagrantfile后推到puppet进行，保持Vagrantfile的简洁。目的是在对本地环境的VM配置与E2E环境（甚至生产环境）的节点配置上，保持较高的一致性，有利于统一部署方式。