vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/getting-started/rebuild.html.md

@@ -0,0 +1,26 @@
+---
+layout: "intro"
+page_title: "Rebuild - Getting Started"
+sidebar_current: "gettingstarted-rebuild"
+description: |-
+  When you are ready to come back to your project, whether it is tomorrow,
+  a week from now, or a year from now, getting it up and running is easy:
+---
+
+# Rebuild
+
+When you are ready to come back to your project, whether it is tomorrow,
+a week from now, or a year from now, getting it up and running is easy:
+
+```
+$ vagrant up
+```
+
+That's it! Since the Vagrant environment is already all configured via
+the Vagrantfile, you or any of your coworkers simply have to run
+`vagrant up` at any time and Vagrant will recreate your work environment.
+
+## Next Steps
+
+You have successfully managed the full lifecycle of your Vagrant environment.
+Read on to learn about [providers](/intro/getting-started/providers.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/getting-started/share.html.md

@@ -0,0 +1,57 @@
+---
+layout: "intro"
+page_title: "Share - Getting Started"
+sidebar_current: "gettingstarted-share"
+description: |-
+  Now that we have a web server up and running and accessible from your machine,
+  we have a fairly functional development environment. But in addition to
+  providing a development environment, Vagrant also makes it easy to share
+  and collaborate on these environments. The primary feature to do this in
+  Vagrant is called Vagrant Share.
+---
+
+# Share
+
+Now that we have a web server up and running and accessible from your machine,
+we have a fairly functional development environment. But in addition to
+providing a development environment, Vagrant also makes it easy to share
+and collaborate on these environments. The primary feature to do this in
+Vagrant is called [Vagrant Share](/docs/share/).
+
+Vagrant Share lets you share your Vagrant environment to anyone around the
+world with an Internet connection. It will give you a URL that will route
+directly to your Vagrant environment from any device in the world that is
+connected to the Internet.
+
+Run `vagrant share`:
+
+```
+$ vagrant share
+...
+==> default: Creating Vagrant Share session...
+==> default: HTTP URL: http://b1fb1f3f.ngrok.io
+...
+```
+
+Your URL will be different, so do not try the URL above. Instead, copy
+the URL that `vagrant share` outputted for you and visit that in a web
+browser. It should load the Apache page we setup earlier.
+
+If you modify the files in your shared folder and refresh the URL, you will
+see it update! The URL is routing directly into your Vagrant environment,
+and works from any device in the world that is connected to the internet.
+
+To end the sharing session, hit `Ctrl+C` in your terminal. You can refresh
+the URL again to verify that your environment is no longer being shared.
+
+Vagrant Share is much more powerful than simply HTTP sharing. For more
+details, see the [complete Vagrant Share documentation](/docs/share/).
+
+~> **Vagrant share is not designed to serve production traffic!** Please do not
+rely on Vagrant share outside of development or Q/A. The Vagrant share service
+is not designed to carry production-level traffic.
+
+## Next Steps
+
+You have successfully shared your environment with the world. Congratulations!
+Read on to learn about the [teardown process](/intro/getting-started/teardown.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/getting-started/synced_folders.html.md

@@ -0,0 +1,64 @@
+---
+layout: "intro"
+page_title: "Synced Folders - Getting Started"
+sidebar_current: "gettingstarted-syncedfolders"
+description: |-
+  While it is cool to have a virtual machine so easily, not many people
+  want to edit files using just plain terminal-based editors over SSH.
+  Luckily with Vagrant you do not have to. By using synced folders, Vagrant
+  will automatically sync your files to and from the guest machine.
+---
+
+# Synced Folders
+
+While it is cool to have a virtual machine so easily, not many people
+want to edit files using just plain terminal-based editors over SSH.
+Luckily with Vagrant you do not have to. By using _synced folders_, Vagrant
+will automatically sync your files to and from the guest machine.
+
+By default, Vagrant shares your project directory (remember, that is the
+one with the Vagrantfile) to the `/vagrant` directory in your guest machine.
+
+Note that when you `vagrant ssh` into your machine, you're in `/home/vagrant`.
+`/home/vagrant` is a different directory from the synced `/vagrant` directory.
+
+If your terminal displays an error about incompatible guest additions (or no
+guest additions), you may need to update your box or choose a different box such
+as `hashicorp/precise64`. Some users have also had success with the
+[vagrant-vbguest](https://github.com/dotless-de/vagrant-vbguest) plugin, but it
+is not officially supported by the Vagrant core team.
+
+Run `vagrant up` again and SSH into your machine to see:
+
+```
+$ vagrant up
+...
+$ vagrant ssh
+...
+vagrant@precise64:~$ ls /vagrant
+Vagrantfile
+```
+
+Believe it or not, that Vagrantfile you see inside the virtual machine
+is actually the same Vagrantfile that is on your actual host machine.
+Go ahead and touch a file to prove it to yourself:
+
+```
+vagrant@precise64:~$ touch /vagrant/foo
+vagrant@precise64:~$ exit
+$ ls
+foo Vagrantfile
+```
+
+Whoa! "foo" is now on your host machine. As you can see, Vagrant kept
+the folders in sync.
+
+With [synced folders](/docs/synced-folders/), you can continue
+to use your own editor on your host machine and have the files sync
+into the guest machine.
+
+## Next Steps
+
+You have successfully interacted with your host machine via synced folders on
+the guest machine. Read on to learn about installing packages, users, and more
+with [provisioning](/intro/getting-started/provisioning.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/getting-started/teardown.html.md

@@ -0,0 +1,53 @@
+---
+layout: "intro"
+page_title: "Teardown - Getting Started"
+sidebar_current: "gettingstarted-teardown"
+description: |-
+  We now have a fully functional virtual machine we can use for basic
+  web development. But now let us say it is time to switch gears, maybe work
+  on another project, maybe go out to lunch, or maybe just time to go home.
+  How do we clean up our development environment?
+---
+
+# Teardown
+
+We now have a fully functional virtual machine we can use for basic
+web development. But now let us say it is time to switch gears, maybe work
+on another project, maybe go out to lunch, or maybe just time to go home.
+How do we clean up our development environment?
+
+With Vagrant, you _suspend_, _halt_, or _destroy_ the guest machine.
+Each of these options have pros and cons. Choose the method that works
+best for you.
+
+**Suspending** the virtual machine by calling `vagrant suspend` will
+save the current running state of the machine and stop it. When you are
+ready to begin working again, just run `vagrant up`, and it will be
+resumed from where you left off. The main benefit of this method is that it
+is super fast, usually taking only 5 to 10 seconds to stop and start your
+work. The downside is that the virtual machine still eats up your disk space,
+and requires even more disk space to store all the state of the virtual
+machine RAM on disk.
+
+**Halting** the virtual machine by calling `vagrant halt` will gracefully
+shut down the guest operating system and power down the guest machine.
+You can use `vagrant up` when you are ready to boot it again. The benefit of
+this method is that it will cleanly shut down your machine, preserving the
+contents of disk, and allowing it to be cleanly started again. The downside is
+that it'll take some extra time to start from a cold boot, and the guest machine
+still consumes disk space.
+
+**Destroying** the virtual machine by calling `vagrant destroy` will remove
+all traces of the guest machine from your system. It'll stop the guest machine,
+power it down, and remove all of the guest hard disks. Again, when you are ready to
+work again, just issue a `vagrant up`. The benefit of this is that _no cruft_
+is left on your machine. The disk space and RAM consumed by the guest machine
+is reclaimed and your host machine is left clean. The downside is that
+`vagrant up` to get working again will take some extra time since it
+has to reimport the machine and re-provision it.
+
+## Next Steps
+
+You have successfully suspended, halted, and destroyed your virtual environment
+with Vagrant. Read on to learn how to
+[rebuild the environment](/intro/getting-started/rebuild.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/getting-started/up.html.md

@@ -0,0 +1,55 @@
+---
+layout: "intro"
+page_title: "Up and SSH - Getting Started"
+sidebar_current: "gettingstarted-up"
+description: |-
+  It is time to boot your first Vagrant environment. Run the following from your
+  terminal - "vagrant up"
+---
+
+# Up And SSH
+
+It is time to boot your first Vagrant environment. Run the following from your
+terminal:
+
+```
+$ vagrant up
+```
+
+In less than a minute, this command will finish and you will have a
+virtual machine running Ubuntu. You will not actually _see_ anything though,
+since Vagrant runs the virtual machine without a UI. To prove that it is
+running, you can SSH into the machine:
+
+```
+$ vagrant ssh
+```
+
+This command will drop you into a full-fledged SSH session. Go ahead and
+interact with the machine and do whatever you want. Although it may be tempting,
+be careful about `rm -rf /`, since Vagrant shares a directory at `/vagrant`
+with the directory on the host containing your Vagrantfile, and this can
+delete all those files. Shared folders will be covered in the next section.
+
+Take a moment to think what just happened: With just one line of configuration
+and one command in your terminal, we brought up a fully functional, SSH accessible
+virtual machine. Cool. The SSH session can be terminated with `CTRL+D`.
+
+```
+vagrant@precise64:~$ logout
+Connection to 127.0.0.1 closed.
+```
+
+When you are done fiddling around with the machine, run `vagrant destroy`
+back on your host machine, and Vagrant will terminate the use of any resources
+by the virtual machine.
+
+-> The `vagrant destroy` command does not actually remove the downloaded box
+file. To _completely_ remove the box file, you can use the `vagrant box remove`
+command.
+
+## Next Steps
+
+You have successfully created and interacted with your first Vagrant
+environment! Read on to learn more about
+[synced folders](/intro/getting-started/synced_folders.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/index.html.md

@@ -0,0 +1,74 @@
+---
+layout: "intro"
+sidebar_current: "intro-home"
+page_title: "Introduction"
+description: |-
+  Vagrant is a tool for building complete development environments. With an
+  easy-to-use workflow and focus on automation, Vagrant lowers development
+  environment setup time, increases development/production parity, and makes
+  the "works on my machine" excuse a relic of the past.
+---
+
+# Introduction to Vagrant
+
+
+Vagrant is a tool for building and managing virtual machine environments in a
+single workflow. With an easy-to-use workflow and focus on automation, Vagrant
+lowers development environment setup time, increases production parity, and
+makes the "works on my machine" excuse a relic of the past.
+
+If you are already familiar with the basics of Vagrant, the
+[documentation](/docs/index.html) provides a better reference build for all
+available features and internals.
+
+## Why Vagrant?
+
+Vagrant provides easy to configure, reproducible, and portable work environments
+built on top of industry-standard technology and controlled by a single
+consistent workflow to help maximize the productivity and flexibility of you and
+your team.
+
+To achieve its magic, Vagrant stands on the shoulders of giants. Machines
+are provisioned on top of VirtualBox, VMware, AWS, or
+[any other provider](/docs/providers/). Then, industry-standard
+[provisioning tools](/docs/provisioning/)
+such as shell scripts, Chef, or Puppet, can automatically install
+and configure software on the virtual machine.
+
+### For Developers
+
+If you are a **developer**, Vagrant will isolate dependencies and their
+configuration within a single disposable, consistent environment, without
+sacrificing any of the tools you are used to working with (editors, browsers,
+debuggers, etc.). Once you or someone else creates a single
+[Vagrantfile](/docs/vagrantfile/), you just need to `vagrant up` and everything
+is installed and configured for you to work. Other members of your team create
+their development environments from the same configuration, so whether you are
+working on Linux, Mac OS X, or Windows, all your team members are running code
+in the same environment, against the same dependencies, all configured the same
+way. Say goodbye to "works on my machine" bugs.
+
+### For Operators
+
+If you are an **operations engineer** or **DevOps engineer**, Vagrant gives you a disposable
+environment and consistent workflow for developing and testing infrastructure
+management scripts. You can quickly test things like shell scripts, Chef
+cookbooks, Puppet modules, and more using local virtualization such as
+VirtualBox or VMware. Then, with the _same configuration_, you can test these
+scripts on remote clouds such as AWS or RackSpace with the _same workflow_.
+Ditch your custom scripts to recycle EC2 instances, stop juggling SSH prompts to
+various machines, and start using Vagrant to bring sanity to your life.
+
+### For Designers
+
+If you are a **designer**, Vagrant will automatically set everything up that is
+required for that web app in order for you to focus on doing what you do best:
+design. Once a developer configures Vagrant, you do not need to worry about how
+to get that app running ever again. No more bothering other developers to help
+you fix your environment so you can test designs. Just check out the code,
+`vagrant up`, and start designing.
+
+### For Everyone
+
+Vagrant is designed for everyone as the easiest and fastest way to create a
+virtualized environment!

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/vs/cli-tools.md

@@ -0,0 +1,38 @@
+---
+layout: "intro"
+page_title: "Vagrant vs. CLI Tools"
+sidebar_current: "vs-cli-tools"
+description: |-
+  Virtualization software like VirtualBox and VMware come with command line
+  utilities for managing the lifecycle of machines on their platform. Vagrant
+  actually uses many of these utilities internally. The difference between these
+  CLI tools and Vagrant is that Vagrant provides a declarative, reproducible,
+  idempotent workflow.
+---
+
+# Vagrant vs. CLI Tools
+
+Virtualization software like VirtualBox and VMware come with command line
+utilities for managing the lifecycle of machines on their platform. Many
+people make use of these utilities to write their own automation. Vagrant
+actually uses many of these utilities internally.
+
+The difference between these CLI tools and Vagrant is that Vagrant builds
+on top of these utilities in a number of ways while still providing a
+consistent workflow. Vagrant supports multiple synced folder types, multiple
+provisioners to setup the machine, automatic SSH setup, creating HTTP tunnels
+into your development environment, and more. All of these can be configured
+using a single simple configuration file.
+
+Vagrant still has a number of improvements over manual scripting even if you
+ignore all the higher-level features Vagrant provides. The command-line
+utilities provided by virtualization software often change each version
+or have subtle bugs with workarounds. Vagrant automatically detects the
+version, uses the correct flags, and can work around known issues. So if
+you're using one version of VirtualBox and a co-worker is using a different
+version, Vagrant will still work consistently.
+
+For highly-specific workflows that don't change often, it can still be
+beneficial to maintain custom scripts. Vagrant is targeted at building
+development environments but some advanced users still use the CLI tools
+underneath to do other manual things.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/vs/docker.html.md

@@ -0,0 +1,34 @@
+---
+layout: "intro"
+page_title: "Vagrant vs. Docker"
+sidebar_current: "vs-docker"
+description: |-
+  Vagrant and Docker both provide isolation primitives. This page details the
+  differences between them.
+---
+
+# Vagrant vs. Docker
+
+Vagrant is a tool focused on providing a consistent development environment
+workflow across multiple operation systems. Docker is a container management
+that can consistently run software as long as a containerization system exists.
+
+Containers are generally more lightweight than virtual machines, so starting
+and stopping containers is extremely fast. Most common development machines
+don't have a containerization system built-in, and Docker uses a virtual machine
+with Linux installed to provide that.
+
+Currently, Docker lacks support for certain operating systems (such as
+BSD). If your target deployment is one of these operating systems,
+Docker will not provide the same production parity as a tool like Vagrant.
+Vagrant will allow you to run a Windows development environment on Mac or Linux,
+as well.
+
+For microservice heavy environments, Docker can be attractive because you
+can easily start a single Docker VM and start many containers above that
+very quickly. This is a good use case for Docker. Vagrant can do this as well
+with the Docker provider. A primary benefit for Vagrant is a consistent workflow
+but there are many cases where a pure-Docker workflow does make sense.
+
+Both Vagrant and Docker have a vast library of community-contributed "images"
+or "boxes" to choose from.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/vs/index.html.md

@@ -0,0 +1,21 @@
+---
+layout: "intro"
+page_title: "Vagrant vs. Other Software"
+sidebar_current: "vs"
+description: |-
+  Vagrant is not the only tool to manage virtual machines and development
+  environments. These pages detail similar tools to Vagrant.
+---
+
+# Vagrant vs. Other Software
+
+Vagrant is not the only tool to manage virtual machines and development
+environments. This section compares Vagrant to these other software choices.
+
+Due to the bias of the comparisons, we attempt to only use facts. If you find
+something that is invalid or out of date in the comparisons, please [open an
+issue](https://github.com/hashicorp/vagrant/issues) and we'll address it as soon
+as possible.
+
+Use the navigation on the left to read comparisons of Vagrant versus similar
+software.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/intro/vs/terraform.html.md

@@ -0,0 +1,37 @@
+---
+layout: "intro"
+page_title: "Vagrant vs. Terraform"
+sidebar_current: "vs-terraform"
+description: |-
+  Vagrant is a tool for managing virtual machines. Terraform is another open
+  source tool from HashiCorp which enables infrastructure as code.
+---
+
+# Vagrant vs. Terraform
+
+Vagrant and [Terraform][terraform] are both projects from [HashiCorp][hashicorp].
+Vagrant is a tool focused for managing development environments and
+Terraform is a tool for building infrastructure.
+
+Terraform can describe complex sets of infrastructure that exists
+locally or remotely. It is focused on building and changing that infrastructure
+over time. The minimal aspects of virtual machine lifecycle can be reproduced
+in Terraform, sometimes leading to confusion with Vagrant.
+
+Vagrant provides a number of higher level features that Terraform doesn't.
+Synced folders, automatic networking, HTTP tunneling, and more are features
+provided by Vagrant to ease development environment usage. Because Terraform
+is focused on infrastructure management and not development environments,
+these features are out of scope for that project.
+
+The primary usage of Terraform is for managing remote resources in cloud
+providers such as AWS. Terraform is designed to be able to manage extremely
+large infrastructures that span multiple cloud providers. Vagrant is designed
+primarily for local development environments that use only a handful of
+virtual machines at most.
+
+Vagrant is for development environments. Terraform is for more general
+infrastructure management.
+
+[hashicorp]: https://www.hashicorp.com
+[terraform]: https://www.terraform.io

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/layouts/_sidebar.erb

@@ -0,0 +1,31 @@
+<div class="sidebar-overlay"></div>
+
+<aside class="sidebar" role="navigation">
+  <div class="sidebar-header">
+    <%= inline_svg "logo-text.svg", height: 42, class: "logo" %>
+  </div>
+
+  <ul class="nav sidebar-nav">
+    <li><a href="/intro/index.html">Intro</a></li>
+    <li><a href="/docs/index.html">Docs</a></li>
+    <li><a href="https://www.amazon.com/gp/product/1449335837/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1449335837&linkCode=as2&tag=vagrant-20" target="_TOP">Book</a></li>
+    <li><a href="/vmware/index.html">VMware</a></li>
+    <li><a href="/community.html">Community</a></li>
+    <li><a href="/assets/files/press-kit.zip">Press Kit</a></li>
+  </ul>
+
+  <div class="divider"></div>
+
+  <ul class="external nav sidebar-nav">
+    <li>
+      <a href="/downloads.html">
+        <%= inline_svg "download.svg" %> Download
+      </a>
+    </li>
+    <li>
+      <a href="https://github.com/hashicorp/vagrant">
+        <%= inline_svg "github.svg" %> GitHub
+      </a>
+    </li>
+  </ul>
+</aside>