vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/provisioning/chef_solo.html.md

@@ -0,0 +1,202 @@
+---
+layout: "docs"
+page_title: "Chef Solo - Provisioning"
+sidebar_current: "provisioning-chefsolo"
+description: |-
+  The Vagrant Chef Solo provisioner allows you to provision the guest using
+  Chef, specifically with chef-solo.
+---
+
+# Chef Solo Provisioner
+
+**Provisioner name: `chef_solo`**
+
+The Vagrant Chef Solo provisioner allows you to provision the guest using
+[Chef](https://www.chef.io/chef/), specifically with
+[Chef Solo](https://docs.chef.io/chef_solo.html).
+
+Chef Solo is ideal for people who are already experienced with Chef,
+already have Chef cookbooks, or are looking to learn Chef. Specifically,
+this documentation page will not go into how to use Chef or how to write
+Chef cookbooks, since Chef is a complete system that is beyond the scope
+of a single page of documentation.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Chef and Vagrant already,
+  I recommend starting with the <a href="/docs/provisioning/shell.html">shell
+  provisioner</a>. However, if you are comfortable with Vagrant already, Vagrant
+  is the best way to learn Chef.
+</div>
+
+## Options
+
+This section lists the complete set of available options for the Chef Solo
+provisioner. More detailed examples of how to use the provisioner are
+available below this section.
+
+* `cookbooks_path` (string or array) - A list of paths to where cookbooks
+  are stored. By default this is "cookbooks", expecting a cookbooks folder
+  relative to the Vagrantfile location.
+
+* `data_bags_path` (string or array) - A path where data bags are stored. By
+  default, no data bag path is set. Chef 12 or higher is required to use the
+  array option. Chef 11 and lower only accept a string value.
+
+* `environments_path` (string) - A path where environment definitions are
+  located. By default, no environments folder is set.
+
+* `nodes_path` (string or array) - A list of paths where node objects (in JSON format) are stored. By default, no
+  nodes path is set.
+
+* `environment` (string) - The environment you want the Chef run to be
+  a part of. This requires Chef 11.6.0 or later, and that `environments_path`
+  is set.
+
+* `recipe_url` (string) - URL to an archive of cookbooks that Chef will download
+  and use.
+
+* `roles_path` (string or array) - A list of paths where roles are defined.
+  By default this is empty. Multiple role directories are only supported by
+  Chef 11.8.0 and later.
+
+* `synced_folder_type` (string) - The type of synced folders to use when
+  sharing the data required for the provisioner to work properly. By default
+  this will use the default synced folder type. For example, you can set this
+  to "nfs" to use NFS synced folders.
+
+In addition to all the options listed above, the Chef Solo provisioner supports
+the [common options for all Chef provisioners](/docs/provisioning/chef_common.html).
+
+## Specifying a Run List
+
+The easiest way to get started with the Chef Solo provisioner is to just
+specify a [run list](https://docs.chef.io/nodes.html#about-run-lists). This looks like:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.add_recipe "apache"
+  end
+end
+```
+
+This causes Vagrant to run Chef Solo with the "apache" cookbook. The cookbooks
+by default are looked for in the "cookbooks" directory relative to your
+project root. The directory structure ends up looking like this:
+
+```
+$ tree
+.
+|-- Vagrantfile
+|-- cookbooks
+|   |-- apache
+|       |-- recipes
+|           |-- default.rb
+```
+
+The order of the calls to `add_recipe` will specify the order of the run list.
+Earlier recipes added with `add_recipe` are run before later recipes added.
+
+## Custom Cookbooks Path
+
+Instead of using the default "cookbooks" directory, a custom cookbooks
+path can also be set via the `cookbooks_path` configuration directive:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.cookbooks_path = "my_cookbooks"
+  end
+end
+```
+
+The path can be relative or absolute. If it is relative, it is relative
+to the project root.
+
+The configuration value can also be an array of paths:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.cookbooks_path = ["cookbooks", "my_cookbooks"]
+  end
+end
+```
+
+## Roles
+
+Vagrant also supports provisioning with [Chef roles](https://docs.chef.io/roles.html).
+This is done by specifying a path to a roles folder where roles are defined
+and by adding roles to your run list:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.roles_path = "roles"
+    chef.add_role("web")
+  end
+end
+```
+
+Just like the cookbooks path, the roles path is relative to the project
+root if a relative path is given.
+
+The configuration value can also be an array of paths on Chef 11.8.0 and newer.
+On older Chef versions only the first path is used.
+
+**Note:** The name of the role file must be the same as the role name.
+For example the `web` role must be in the `roles_path` as web.json or web.rb.
+This is required by Chef itself, and is not a limitation imposed by
+Vagrant.
+
+## Data Bags
+
+[Data bags](https://docs.chef.io/data_bags.html) are also
+supported by the Chef Solo provisioner. This is done by specifying
+a path to your data bags directory:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.data_bags_path = "data_bags"
+  end
+end
+```
+
+## Custom JSON Data
+
+Additional configuration data for Chef attributes can be passed in
+to Chef Solo. This is done by setting the `json` property with a Ruby
+hash (dictionary-like object), which is converted to JSON and passed
+in to Chef:
+
+```
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    # ...
+
+    chef.json = {
+      "apache" => {
+        "listen_address" => "0.0.0.0"
+      }
+    }
+  end
+end
+```
+
+Hashes, arrays, etc. can be used with the JSON configuration object. Basically,
+anything that can be turned cleanly into JSON works.
+
+## Custom Node Name
+
+You can specify a custom node name by setting the `node_name` property. This
+is useful for cookbooks that may depend on this being set to some sort
+of value. Example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_solo" do |chef|
+    chef.node_name = "foo"
+  end
+end
+```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/provisioning/chef_zero.html.md

@@ -0,0 +1,92 @@
+---
+layout: "docs"
+page_title: "Chef Zero - Provisioning"
+sidebar_current: "provisioning-chefzero"
+description: |-
+  The Vagrant Chef Zero provisioner allows you to provision the guest using
+  Chef, specifically with chef-zero.
+---
+
+# Chef Zero Provisioner
+
+**Provisioner name: `chef_zero`**
+
+The Vagrant Chef Zero provisioner allows you to provision the guest using
+[Chef](https://www.getchef.com/chef/), specifically with
+[Chef Zero/local mode](https://docs.getchef.com/ctl_chef_client.html#run-in-local-mode).
+
+This new provisioner is a middle ground between running a full blown
+Chef Server and using the limited [Chef Solo](/docs/provisioning/chef_solo.html)
+provisioner. It runs a local in-memory Chef Server and fakes the validation
+and client key registration.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Chef and Vagrant already,
+  I recommend starting with the <a href="/docs/provisioning/shell.html">shell
+  provisioner</a>. However, if you are comfortable with Vagrant already, Vagrant
+  is the best way to learn Chef.
+</div>
+
+## Options
+
+This section lists the complete set of available options for the Chef Zero
+provisioner. More detailed examples of how to use the provisioner are
+available below this section.
+
+* `cookbooks_path` (string or array) - A list of paths to where cookbooks
+  are stored. By default this is "cookbooks", expecting a cookbooks folder
+  relative to the Vagrantfile location.
+
+* `data_bags_path` (string or array) - A path where data bags are stored. By
+  default, no data bag path is set. Chef 12 or higher is required to use the
+  array option. Chef 11 and lower only accept a string value.
+
+* `environments_path` (string) - A path where environment definitions are
+  located. By default, no environments folder is set.
+
+* `nodes_path` (string or array) - A list of paths where node objects
+  (in JSON format) are stored. By default, no nodes path is set. This value is
+  required.
+
+* `environment` (string) - The environment you want the Chef run to be
+  a part of. This requires Chef 11.6.0 or later, and that `environments_path`
+  is set.
+
+* `roles_path` (string or array) - A list of paths where roles are defined.
+  By default this is empty. Multiple role directories are only supported by
+  Chef 11.8.0 and later.
+
+* `synced_folder_type` (string) - The type of synced folders to use when
+  sharing the data required for the provisioner to work properly. By default
+  this will use the default synced folder type. For example, you can set this
+  to "nfs" to use NFS synced folders.
+
+
+In addition to all the options listed above, the Chef Zero provisioner supports
+the [common options for all Chef provisioners](/docs/provisioning/chef_common.html).
+
+## Usage
+
+The Chef Zero provisioner is configured basically the same way as the Chef Solo
+provisioner. See the [Chef Solo documentations](/docs/provisioning/chef_solo.html)
+for more information.
+
+A basic example could look like this:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_zero" do |chef|
+    # Specify the local paths where Chef data is stored
+    chef.cookbooks_path = "cookbooks"
+    chef.data_bags_path = "data_bags"
+    chef.nodes_path = "nodes"
+    chef.roles_path = "roles"
+
+    # Add a recipe
+    chef.add_recipe "apache"
+
+    # Or maybe a role
+    chef.add_role "web"
+  end
+end
+```

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

@@ -0,0 +1,208 @@
+---
+layout: "docs"
+page_title: "Docker - Provisioning"
+sidebar_current: "provisioning-docker"
+description: |-
+  The Vagrant Docker provisioner can automatically install Docker, pull Docker
+  containers, and configure certain containers to run on boot.
+---
+
+# Docker Provisioner
+
+**Provisioner name: `"docker"`**
+
+The Vagrant Docker provisioner can automatically install
+[Docker](https://www.docker.io), pull Docker containers, and configure certain
+containers to run on boot.
+
+The docker provisioner is ideal for organizations that are using
+Docker as a means to distribute things like their application or services.
+Or, if you are just getting started with Docker, the Docker provisioner
+provides the easiest possible way to begin using Docker since the provisioner
+automates installing Docker for you.
+
+As with all provisioners, the Docker provisioner can be used along with
+all the other provisioners Vagrant has in order to setup your working
+environment the best way possible. For example, perhaps you use Puppet to
+install services like databases or web servers but use Docker to house
+your application runtime. You can use the Puppet provisioner along
+with the Docker provisioner.
+
+<div class="alert alert-info">
+  <strong>Note:</strong> This documentation is for the Docker
+      <em>provisioner</em>. If you are looking for the Docker
+  <em>provider</em>, visit the
+  <a href="/docs/docker/">Docker provider documentation</a>.
+</div>
+
+## Options
+
+The docker provisioner takes various options. None are required. If
+no options are required, the Docker provisioner will only install Docker
+for you (if it is not already installed).
+
+* `images` (array) - A list of images to pull using `docker pull`. You
+  can also use the `pull_images` function. See the example below this
+  section for more information.
+
+In addition to the options that can be set, various functions are available
+and can be called to configure other aspects of the Docker provisioner. Most
+of these functions have examples in more detailed sections below.
+
+* `build_image` - Build an image from a Dockerfile.
+
+* `pull_images` - Pull the given images. This does not start these images.
+
+* `post_install_provisioner` - A [provisioner block](/docs/provisioning) that runs post docker
+   installation.
+
+* `run` - Run a container and configure it to start on boot. This can
+  only be specified once.
+
+## Building Images
+
+The provisioner can automatically build images. Images are built prior to
+any configured containers to run, so you can build an image before running it.
+Building an image is easy:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.build_image "/vagrant/app"
+  end
+end
+```
+
+The argument to build an image is the path to give to `docker build`. This
+must be a path that exists within the guest machine. If you need to get data
+to the guest machine, use a synced folder.
+
+The `build_image` function accepts options as a second parameter. Here
+are the available options:
+
+* `args` (string) - Additional arguments to pass to `docker build`. Use this
+  to pass in things like `-t "foo"` to tag the image.
+
+## Pulling Images
+
+The docker provisioner can automatically pull images from the
+Docker registry for you. There are two ways to specify images to
+pull. The first is as an array using `images`:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker",
+    images: ["ubuntu"]
+end
+```
+
+This will cause Vagrant to pull the "ubuntu" image from the registry
+for you automatically.
+
+The second way to pull images is to use the `pull_images` function.
+Each call to `pull_images` will _append_ the images to be pulled. The
+`images` variable, on the other hand, can only be used once.
+
+Additionally, the `pull_images` function cannot be used with the
+simple configuration method for provisioners (specifying it all in one line).
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.pull_images "ubuntu"
+    d.pull_images "vagrant"
+  end
+end
+```
+
+## Running Containers
+
+In addition to pulling images, the Docker provisioner can run and start
+containers for you. This lets you automatically start services as part of
+`vagrant up`.
+
+Running containers can only be configured using the Ruby block syntax with
+the `do...end` blocks. An example of running a container is shown below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.run "rabbitmq"
+  end
+end
+```
+
+This will `docker run` a container with the "rabbitmq" image. Note that
+Vagrant uses the first parameter (the image name by default) to override any
+settings used in a previous `run` definition. Therefore, if you need to run
+multiple containers from the same image then you must specify the `image`
+option (documented below) with a unique name.
+
+In addition to the name, the `run` method accepts a set of options, all optional:
+
+* `image` (string) - The image to run. This defaults to the first argument
+  but can also be given here as an option.
+
+* `cmd` (string) - The command to start within the container. If not specified,
+  then the container's default command will be used, such as the
+  "CMD" command [specified in the `Dockerfile`](https:/docs.docker.io/en/latest/use/builder/#cmd).
+
+* `args` (string) - Extra arguments for [`docker run`](https:/docs.docker.io/en/latest/commandline/cli/#run)
+  on the command line. These are raw arguments that are passed directly to Docker.
+
+* `auto_assign_name` (boolean) - If true, the `--name` of the container will
+  be set to the first argument of the run. By default this is true. If the
+  name set contains a "/" (because of the image name), it will be replaced
+  with "-". Therefore, if you do `d.run "foo/bar"`, then the name of the
+  container will be "foo-bar".
+
+* `daemonize` (boolean) - If true, the "-d" flag is given to `docker run` to
+  daemonize the containers. By default this is true.
+
+* `restart` (string) - The restart policy for the container. Defaults to
+  "always"
+
+For example, here is how you would configure Docker to run a container
+with the Vagrant shared directory mounted inside of it:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.run "ubuntu",
+      cmd: "bash -l",
+      args: "-v '/vagrant:/var/www'"
+  end
+end
+```
+
+In case you need to run multiple containers based off the same image, you can do
+so by providing different names and specifying the `image` parameter to it:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.run "db-1", image: "user/mysql"
+    d.run "db-2", image: "user/mysql"
+  end
+end
+```
+
+## Other
+
+This section documents some other things related to the Docker provisioner
+that are generally useful to know if you are using this provisioner.
+
+### Customize `/etc/default/docker`
+
+To customize this file, use the `post_install_provisioner` shell provisioner.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "docker" do |d|
+    d.post_install_provision "shell", inline:"echo export http_proxy='http://127.0.0.1:3128/' >> /etc/default/docker"
+    d.run "ubuntu",
+      cmd: "bash -l",
+      args: "-v '/vagrant:/var/www'"
+  end
+end
+```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/provisioning/file.html.md

@@ -0,0 +1,120 @@
+---
+layout: "docs"
+page_title: "File Uploads - Provisioning"
+sidebar_current: "provisioning-file"
+description: |-
+  The Vagrant file provisioner allows you to upload a file or directory from the
+  host machine to the guest machine.
+---
+
+# File Provisioner
+
+**Provisioner name: `"file"`**
+
+The Vagrant file provisioner allows you to upload a file or directory from the
+host machine to the guest machine.
+
+File provisioning is a simple way to, for example, replicate your local
+~/.gitconfig to the vagrant user's home directory on the guest machine so
+you will not have to run `git config --global` every time you provision a
+new VM.
+
+    Vagrant.configure("2") do |config|
+      # ... other configuration
+
+      config.vm.provision "file", source: "~/.gitconfig", destination: ".gitconfig"
+    end
+
+If you want to upload a folder to your guest system, it can be accomplished by
+using a file provisioner seen below. When copied, the resulting folder on the guest will
+replace `folder` as `newfolder` and place its on the guest machine. Note that if
+you'd like the same folder name on your guest machine, make sure that the destination
+path has the same name as the folder on your host.
+
+    Vagrant.configure("2") do |config|
+      # ... other configuration
+
+      config.vm.provision "file", source: "~/path/to/host/folder", destination: "$HOME/remote/newfolder"
+    end
+
+Prior to copying `~/path/to/host/folder` to the guest machine:
+
+        folder
+        ├── script.sh
+        ├── otherfolder
+        │   └── hello.sh
+        ├── goodbye.sh
+        ├── hello.sh
+        └── woot.sh
+
+        1 directory, 5 files
+
+After to copying `~/path/to/host/folder` into `$HOME/remote/newfolder` to the guest machine:
+
+        newfolder
+        ├── script.sh
+        ├── otherfolder
+        │   └── hello.sh
+        ├── goodbye.sh
+        ├── hello.sh
+        └── woot.sh
+
+        1 directory, 5 files
+
+Note that, unlike with synced folders, files or directories that are uploaded
+will not be kept in sync. Continuing with the example above, if you make
+further changes to your local ~/.gitconfig, they will not be immediately
+reflected in the copy you uploaded to the guest machine.
+
+The file uploads by the file provisioner are done as the
+_SSH or PowerShell user_. This is important since these users generally
+do not have elevated privileges on their own. If you want to upload files to
+locations that require elevated privileges, we recommend uploading them
+to temporary locations and then using the
+[shell provisioner](/docs/provisioning/shell.html)
+to move them into place.
+
+## Options
+
+The file provisioner takes only two options, both of which are required:
+
+* `source` (string) - Is the local path of the file or directory to be
+  uploaded.
+
+* `destination` (string) - Is the remote path on the guest machine where
+  the source will be uploaded to. The file/folder is uploaded as the SSH user
+  over SCP, so this location must be writable to that user. The SSH user can be
+  determined by running `vagrant ssh-config`, and defaults to "vagrant".
+
+## Caveats
+
+While the file provisioner does support trailing slashes or "globing", this can
+lead to some confusing results due to the underlying tool used to copy files and
+folders between the host and guests. For example, if you have a source and
+destination with a trailing slash defined below:
+
+      config.vm.provision "file", source: "~/pathfolder", destination: "/remote/newlocation/"
+
+You are telling vagrant to upload `~/pathfolder` under the remote dir `/remote/newlocation`,
+which will look like:
+
+        newlocation
+        ├── pathfolder
+        │   └── file.sh
+
+        1 directory, 2 files
+
+This behavior can also be achieved by defining your file provisioner below:
+
+      config.vm.provision "file", source: "~/pathfolder", destination: "/remote/newlocation/pathfolder"
+
+Another example is using globing on the host machine to grab all files within a
+folder, but not the top level folder itself:
+
+      config.vm.provision "file", source: "~/otherfolder/.", destination: "/remote/otherlocation"
+
+The file provisioner is defined to include all files under `~/otherfolder`
+to the new location `/remote/otherlocation`. This idea can be achieved by simply
+having your destination folder differ from the source folder:
+
+      config.vm.provision "file", source: "/otherfolder", destination: "/remote/otherlocation"

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

@@ -0,0 +1,49 @@
+---
+layout: "docs"
+page_title: "Provisioning"
+sidebar_current: "provisioning"
+description: |-
+  Provisioners in Vagrant allow you to automatically install software, alter configurations, and more on the machine as part of the `vagrant up` process.
+---
+
+# Provisioning
+
+Provisioners in Vagrant allow you to automatically install software, alter configurations,
+and more on the machine as part of the `vagrant up` process.
+
+This is useful since [boxes](/docs/boxes.html) typically are not
+built _perfectly_ for your use case. Of course, if you want to just use
+`vagrant ssh` and install the software by hand, that works. But by using
+the provisioning systems built-in to Vagrant, it automates the process so
+that it is repeatable. Most importantly, it requires no human interaction,
+so you can `vagrant destroy` and `vagrant up` and have a fully ready-to-go
+work environment with a single command. Powerful.
+
+Vagrant gives you multiple options for provisioning the machine, from
+simple shell scripts to more complex, industry-standard configuration
+management systems.
+
+If you've never used a configuration management system before, it is
+recommended you start with basic [shell scripts](/docs/provisioning/shell.html)
+for provisioning.
+
+You can find the full list of built-in provisioners and usage of these
+provisioners in the navigational area to the left.
+
+## When Provisioning Happens
+
+Provisioning happens at certain points during the lifetime of your
+Vagrant environment:
+
+* On the first `vagrant up` that creates the environment, provisioning is run.
+  If the environment was already created and the up is just resuming a machine
+  or booting it up, they will not run unless the `--provision` flag is explicitly
+  provided.
+
+* When `vagrant provision` is used on a running environment.
+
+* When `vagrant reload --provision` is called. The `--provision` flag must
+  be present to force provisioning.
+
+You can also bring up your environment and explicitly _not_ run provisioners
+by specifying `--no-provision`.