2d8a048946
This introduces the new network configuration syntax for Vagrant 1.1
and forward.
== The Problem
With multiple providers, the concept of networking as it stands in Vagrant
1.0.x becomes really muddy. We have `config.vm.forward_port` and
`config.vm.network :hostonly` and `config.vm.network :bridged`. But what
if someone writes an AWS provider? What is a bridged network in AWS? It
just doesn't make sense.
Networking working out of the box with Vagrant is a core part of what
makes Vagrant "magic" to new users. It is a core part of what makes Vagrant
simple to use. One option to punt networking to provider-specific
configuration was considered, but I found the whole idea of networking
too core to Vagrant to simply punt.
Because of this, a whole new method of networking is introduced.
== The Solution
The solution is to have a high-level notion of networking for Vagrant
configuration. This should cover the most _common_ cases of networking, and
every provider should do their best to implement these high-level
abstractions, to ensure the "just works" nature of Vagrant.
In addition to this high-level networking, low-level networking options
should be exposed on the provider configuration. This allows users to do
advanced provider-specific networking configuration if they want, but aren't
required to.
== High-Level Abstractions
=== Available Types
The high-level abstractions built into Vagrant will be the following:
* Forwarded ports - A mapping of host port to guest port that one can hit
using `localhost`.
* Private network - A private network, the machine should ideally be
protected from public access.
* Public network - A public network, one that is easily accessible by
others.
I'm not sure if these are the proper abstractions. They can change up
until 2.0, but these are what we have so far.
Theoretically, here is how mappings would work. Note that this is just
an example, and the mappings in practice of such providers may or
may not map to this as follows.
**VirtualBox**
* Forwarded ports - NAT network, forwared ports.
* Private network - Hostonly network, static IP assigned.
* Public network - Bridged network, IP assigned via DHCP from router.
**VMWare**
* Forwarded ports - NAT network, forwarded ports.
* Private network - Hostonly network, static IP assigned.
* Public network - Bridged network, IP assigned via DHCP from router.
**AWS**
* Forwarded ports - Unimplemented.
* Private network - Public DNS in EC2, private IP in VPC.
* Public network - Elastic IP in EC2 and VPC.
=== Syntax
Networks are configured at the top-level of a Vagrantfile:
```ruby
Vagrant.configure("2") do |config|
# ...
config.vm.network :forwarded_port, 80, 8080
config.vm.network :private_network, "192.168.1.12"
config.vm.network :public_network
end
```
Providers should do their best to honor these configurations.
=== Advanced Options
While providers should do their best to satisfy the requirements for the
high-level abstractions, it is expected that provider-specific configuration
may be possible per network, even for the high-level configurations. For
this, provider-prefixed configuration options should be done:
```ruby
config.vm.network :forwarded_port, 80, 8000,
:vmware__device => "vmnet8"
config.vm.network :public_network,
:aws__elastic_ip => "1.2.3.4",
:vmware__device => "en0"
```
If at all possible, providers should **not** require advanced options for
these to function.
== Low-level Configuration
While the high-level configuration should satisfy the common case and make
Vagrant work out of the box for most providers, one of the large benefits of
many providers is the ability to do certain networking tricks. For example,
KVM, Hyper-V, vSphere, etc. can create and be a part of true VLANs, which
may be required for certain upstream networking rules/ACLs. For things like
this, the network configuration should go directly into the provider
configuration in some way.
Examples:
```ruby
config.vm.provider :virtualbox do |vb|
vb.network_adapter 2, :hostonly
vb.network_adapter 3, :nat
end
config.vm.provider :aws do |aws|
aws.routing_table = "route-123456"
end
```
It is up to the provider implementation to define the configuration
syntax as well as the implementation details of such an option. Other
providers are unable to see provider configurations other than their own
so it is truly private to the provider.
|
||
|---|---|---|
| bin | ||
| config | ||
| contrib | ||
| keys | ||
| lib | ||
| plugins | ||
| tasks | ||
| templates | ||
| test | ||
| .gitignore | ||
| .yardopts | ||
| CHANGELOG.md | ||
| Gemfile | ||
| LICENSE | ||
| README.md | ||
| Rakefile | ||
| vagrant.gemspec | ||
README.md
Vagrant
- Website: http://vagrantup.com
- Source: https://github.com/mitchellh/vagrant
- IRC:
#vagranton Freenode - Mailing list: Google Groups
Vagrant is a tool for building and distributing virtualized development environments.
By providing automated creation and provisioning of virtual machines using Oracle’s VirtualBox, Vagrant provides the tools to create and configure lightweight, reproducible, and portable virtual environments. For more information, see the part of the getting started guide on “Why Vagrant?”
Quick Start
First, make sure your development machine has VirtualBox
installed. After this, download the appropriate Vagrant package for your OS and install that. If you're not on Mac OS X or Windows, you'll need
to add /opt/vagrant/bin to your PATH. After this, you're ready to go!
To build your first virtual environment:
vagrant init lucid32 http://files.vagrantup.com/lucid32.box
vagrant up
Note: The above vagrant up command will also trigger Vagrant to download the
lucid32 box via the specified URL. Vagrant only does this if it detects that
the box doesn't already exist on your system.
Getting Started Guide
To learn how to build a fully functional rails development environment, view the getting started guide.
Installing the Gem from Git
If you want the bleeding edge version of Vagrant, we try to keep master pretty stable and you're welcome to give it a shot. The following is an example showing how to do this:
rake install
Contributing to Vagrant
Dependencies and Unit Tests
To hack on vagrant, you'll need bundler which can
be installed with a simple gem install bundler. Afterwords, do the following:
bundle install
rake
This will run the unit test suite, which should come back all green! Then you're good to go!
If you want to run Vagrant without having to install the gem, you may use bundle exec,
like so:
bundle exec bin/vagrant help
Acceptance Tests
Vagrant also comes with an acceptance test suite which runs the system end-to-end, without mocking out any dependencies. Note that this test suite is extremely slow, with the test suite taking hours on even a decent system. A CI will be setup in due time to run these tests automatically. However, it is still useful to know how to run these tests since it is often useful to run a single test if you're working on a specific feature.
The acceptance tests have absolutely zero dependence on the Vagrant
source. Instead, an external configuration file must be used to give
the acceptance tests some parameters (such as what Vagrant version is
running, where the Vagrant vagrant binary is, etc.). If you want to
run acceptance tests against source, or just want to see an example of
this file, you can generate it automatically for the source code:
rake acceptance:config
This will drop an acceptance_config.yml file in your working directory.
You can then run a specific acceptance test like so:
ACCEPTANCE_CONFIG=./acceptance_config.yml ruby test/acceptance/version_test.rb
That's it!
If you're developing an acceptance test and you're unsure why things might be failing, you can also view log output for the acceptance tests, which can be very verbose but are a great help in finding bugs:
ACCEPTANCE_LOGGING=debug ACCEPTANCE_CONFIG=./acceptance_config.yml ruby test/acceptance/version_test.rb