Vagrant Knowledge Base

Copyright notice: When reproduced, please indicate the original source and author information and this statement in the form of hyperlinks.
http://wushaobo.info/?p=83

Vagrant Let virtualization technology come close to the ordinary home. Down-to-earth, the network similar to "two minutes to get started" article there are many, but to ask for a variety of issues more posts, because the Vagrant official website of the document is too concise, there is some truth here some pits, are not involved. Even the "Vagrant:up and Running", published two days ago by O ' Reilly, has some vague questions. Therefore, Google has a variety of previous experience on the basis of their own practice, after the proof, with my article, I hope to be involved in these issues to summarize the knowledge to do a clarification, and give the reader an actionable guidance.

article Structure the convenience of vagrant
Vagrant How to play
Vagrant How to play
-vagrant Basic template where to find
-Discrimination Vagrant Box | *.box File | VMS | *.iso file
-vagrantfile how to match
——-[HOWTO] Specify the Vagrant box to use and set the VM name
——-[HOWTO] To set the VM's network connection to the host and the external machine
Run subsequent installation scripts ——-[HOWTO] After configuring and starting the VM
Difficult diseases
accessibility of the upper port of the-VM
-Modify the default SSH port
-Remove barriers to network setup before packaging VMs as *.box files
-Set shared directory location and read and write permissions
-Configuration and startup of multiple VMSThe convenience of vagrant

• When creating virtual machine, you can try it out and start installing or setting it again and again from one of the underlying templates. Can be quickly overturned, can be step by step.
• The Endtoend environment for multiple VMs can be built quickly on a single host.
• Management development environment, can be scripted replication, manipulation and other behaviors, improve the degree of automation.

Vagrant How to play

Simply put, three steps away:

• Install vagrant, VM Software (Virtualbox is the mainstream, this is the default example)
• Add Base template (box) to vagrant
• Start VM with vagrant after configuring Vagrantfile

Full of three commands, some people play to this feel is already great, so ssh VMS all kinds of abuse.

You're far from it!

Vagrant How to play Vagrant Basic template where to find

www.vagrantbox.es introduces the basic templates for vagrant and provides *.box files to download for various needs.

Recommended choice Minimal + guest additions + Puppet|chef box, for:

• Small, which means less resource consumption
• VirtualBox shared directory requires guest additions
• Preinstalled Puppet or chef is not required. They are good for future automation of VM provisioning and are not very

Discrimination Vagrant Box | *.box File | VMS | *.iso file

Explanation of vocabulary:

• *.iso files that are packaged with an operating system cannot be used directly by vagrant
• VM is a bootable/started virtual machine
• *.box file is an acceptable base template file for vagrant
• vagrant Box refers to vagrant already installed base template

Discrimination Relationship:

• *.iso files can be manually installed via the VirtualBox interface for bootable VMS
• VMS can be packaged as *.box files by the Vagrant Package command
• *.box file can be installed as vagrant box by Vagrant Box Add command
• vagrant Box can be vagrant in Vagrantfile to specify the base template to run as a VM

Vagrantfile how to match

Vagrantfile is the starting point for vagrant to configure the VM, and the fragmented instructions in the official documentation let me understand the phrase "something is simple, but it's not easy".

For Vagrantfile, there are several frequently asked HOWTO :

1. Specify the Vagrant box to use and set the VM name
2. Set up a VM's network connection to host and external machines
3. Run subsequent installation scripts after configuring and starting the VM

[HOWTO] Specify the Vagrant box to use and set the VM name

I know it at a glance.

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  endend

Reference

[HOWTO] Sets the VM's network connection to the host and the external machine

1. When the VM communicates only with the host, it can be set to a private network, which is equivalent to setting VirtualBox using the HOST-ONLY mode network adapter.

    config.vm.network :private_network, ip: "192.168.50.4"

2. When the host and multiple VMS on the same host also need to communicate with each other, set each VM as a private network, but set the fixed IP to the same network segment.
3. When the VM needs to communicate with other machines within the host network, it is set to public network, which is equivalent to setting VirtualBox using the bridged mode network adapter, and the default DHCP gets the address.

    config.vm.network :public_network   # vagrant-1.2.2之后的版本可能改用 :bridged

Reference

[HOWTO] Configure and start the VM and run a subsequent installation script

1. The pursuit of simple, then the following two configuration one is enough

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

2. When you have to be complicated, chef/puppet/ansible are available for you. Detailed configuration See reference.
3. Automating deployment is good, but it is not necessary to install fixed software every time the VM is installed. Large can be the same software installation configuration completed, the VM packaging into a *.box file static, and later with this box file as the base template for further configuration. A step-by-step upgrade-based practice accelerates the VM build process and reduces the configuration script.

accessibility of the upper port of a problematic VM

Especially for VMs that don't even have an extranet, we've worked hard to build it but can't access its ports. Firewall is to block the port access to the culprit, simply shut it down.

Centos/redhat/fedora used iptables to manage firewall, so two ways to get rid of it

1. Stop Iptables Service, refer to

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

2. Simply kill all the rules of iptables, reference

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

Ubuntu with UFW Management firewall, turn it off it is, reference

$ sudo ufw disable

Modify the default SSH port scenario

SSH Port default 22, the one who said, "Why should I change it?" I cite a scenario:

If you want to develop an application that includes SFTP server. In order to facilitate users, you'd better keep the 22 port to the user so that he can use the default way to upload files via sftp. At the same time, you want to deploy this application to the VM to do the test, then the VM SSH login can not also use 22 port, you need to specify a new port for it, such as 10022.

Difficulties

The difficulty lies in the following constraints:

• The base template for the original VM uses 22 ports by default, so vagrant cannot start off with Port 22, otherwise the VM cannot access it.
• After you change the SSH port on the VM to a new port, you need to change the vagrantfile to select the new port before restarting the VM.
• Instead of directly accessing the SSH port of the VM, the Vagrant SSH command accesses the host's 22XX port to SSH to the VM indirectly.
• The vagrant contains a mapping of port 22 from the host 22XX port to the VM, and if the new port of the VM is not specified to be mapped to a port on the host, the Vagrant SSH command will still access the original host 22XX port, which is the VM's 22 port. (Vagrant the attempt to select 22XX port is: 2222, 2201, 2202, 2203 ... to ensure that there are no port conflicts when multiple VMS start.) ）

There's a lot of pits, right? Vagrantfile's SSH settings reference and forwarded ports reference didn't make that clear.

Action Outline

It takes a few steps to solve the problem:

1. Port mapping for the new port of the VM in advance in Vagrantfile
2. Modify the port used by SSH on the VM to the new port
3. Use the new port of the VM when specifying SSH login in Vagrantfile
4. Create a new base template to solidify the above changes

Follow the steps to get started

STEP1: port mapping for the new port of the VM in Vagrantfile

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: Modify the port used by SSH on the VM to the new port

• Replace Port 22 with 10022 port on VM: VI edit sshd_config file (centos/ubuntu: /etc/ssh/sshd_config ; Mac OS X: /etc/sshd_config )

    :%s/#Port 22/Port 10022/g  :wq

• Restarting the SSHD service

    $ sudo service sshd restart

STEP3: Use the new port of the VM when specifying SSH login in Vagrantfile

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

Step4 [optional]: Create a new base template to solidify the above changes

Use the Vagrant Package command to save the VM that changed the port as a box file. In the VM generated by this new base template, 10022 is the SSH access port, which can be accessed directly via Vagrant SSH using the vagrantfile above.

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

Before generating a new *.box file, you must clean up the network setup barriers. See below.

To clean up network settings before packaging the VM as a *.box file

Repackaging a manually configured VM to generate the *.box file as a new base template, there is an obstacle to Linux-based's VMS on the network setup.

Problem performance

For example, if you set up a VM with private network (which is equivalent to VirtualBox setting host-only mode), if you are not prepared to use the Vagrant package to generate a new box file, install the box file to vagrant Box after you start the VM, you will find that the private network configuration specified by the current vagrantfile failed.

[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

The VMS that are launched are allowed to be accessed through the Vagrant SSH command, but there is no Host-only mode adapter on the network configuration.

Analytical Solutions

Remember the fixed IP address you set when configuring private network? Yes, the problem is that the persistent network device Udev rules (persistent) are set up by the original VM, and the rules need to be updated when the new VM is generated by box. This conflicts with the instructions in Vagrantfile to set the private network for the new VM.

Since it is unavoidable to set up the private network IP in the vagrantfile, it is just to kill the Udev rules before generating the box file.

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

Off Topic

Interestingly, this reference describes the cause and effect of the problem, but rather the Vagrant:up and Running published by O ' Reilly (chapter 6th) is vague about this.

The book is scheduled to be published on June 12, 2013. There is still an introduction to outdated commands (such as "repackage") in version probation, hoping that the book will not be immediately obsolete.

If you study, the official documents should be compared.

Set shared directory location and read and write permissions

The VirtualBox shared directory requires the VM to have guest additions installed. Install yourself into a VM and pack it into a box file to do the base template, or start with the right box file (mentioned earlier) and do whatever you want.

vagrant defaults to sharing the directory on the host vagrantfile to the /vagrant directory on the VM.

What we often need is to specify a directory to share, for which Vagrant supports two ways:

Simple: vboxsf

VBOXSF is the abbreviation for V irtual boxs hared F older (or vboxs hared F older). Many people know that you can specify VBOXSF as the type to mount, but do not know the full name of this word, or even misunderstood as "virtual machine file System" and mistakenly written vboxfs.

Vagrant uses this method to share the directory by default. Advantages convenient, disadvantage is poor performance. When configured, simply specify in the Vagrantfile:

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

• The previous parameter must be a directory that already exists on the host, and if it is a relative directory, it is the relative Vagrantfile directory.
• The latter parameter must be the absolute path on the VM, and if it does not exist, the vagrant will be built when the VM is started, and the multi-tiered directory is fine.

Serious: NFS

NFS is the perfect path, but it is also picky.

The vagrant has built-in coordination of support and configuration for NFS both on host and VM. If you use Windows, that vagrant as your configuration does not exist, directly ignore (I also think you are fooling around). It's easy in the Vagrantfile, mark on the line:

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

• Two directories can be the same, such as "/shared" , in order to establish a plurality of machine node shared storage.

NFS Shared Directory This approach is critical to read and write permissions within the directory.

Read and Write permissions

To create a shared storage for host and VM, for example, the goal is to:

• Unlimited read and write access to shared directories ( /shared ) on both sides
• Trouble without root privileges

If you build /shared on the host and then configure the association directly, you will fail on both targets. Follow the steps I've told you:

1. The shared directory created on the host is changed to read-write

    $ sudo chmod o+w /shared

2. Set to Non-root user-owned

    $ sudo chown <user>:<group> /shared

3. Start VM after vagrantfile configured

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

The resulting shared directory set goals for the scene are done:

• On both the host and the VM, it's not the root user.
  • The host on /shared belongs to for example Twer users.
  • The user on the VM that /shared belongs to is a number, such as 1000.
• On both hosts and VMS, it's both read-write unrestricted

Configuration and startup of multiple VMS single Vagrantfile vs multiple vagrantfile

Although vagrant supports configuring multiple VMs in one vagrantfile, I personally prefer to write individual vagrantfile for each VM.

• As a result, the configuration and startup of each VM are relatively independent, such as vagrant SSH can not specify the VM name, with the default.
• Secondly, vagrantfile is not always to change.

But the real bull man is not so petty as I am. Using a unified vagrantfile to manage multiple VMS is good for the big picture:

• A vagrantfile contains the basic configuration of all VMs in the entire environment, maintaining the context of the virtual network. You know at a glance which VMs are in the environment, and you don't need to switch directories to check the status of each VM, and not confuse the directory "throw away" which unlucky VM.
• More use of Chef/puppet to configure VMS, such as the VM's IP configuration from Vagrantfile to puppet, to maintain the simplicity of vagrantfile. The goal is to maintain a high level of consistency in the configuration of the VMS on the local environment and in the E2E environment (even in the production environment), which is advantageous for unified deployment.

Vagrant Knowledge Base