vagrant-aws-mkubenka 0.7.2.pre.14 → 0.7.2.pre.16

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/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-1ee58c40e3f5/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-1ee58c40e3f5/website/source/docs/provisioning/salt.html.md

@@ -0,0 +1,187 @@
+---
+layout: "docs"
+page_title: "Salt - Provisioning"
+sidebar_current: "provisioning-salt"
+description: |-
+  The Vagrant Salt provisioner allows you to provision the guest using
+  Salt states.
+---
+# Salt Provisioner
+
+**Provisioner name: `salt`**
+
+The Vagrant Salt provisioner allows you to provision the guest using
+[Salt](http://saltstack.com/) states.
+
+Salt states are  [YAML](https://en.wikipedia.org/wiki/YAML) documents
+that describes the current state a machine should be in, e.g. what
+packages should be installed, which services are running, and the
+contents of arbitrary files.
+
+_NOTE: The Salt provisioner is builtin to Vagrant. If the `vagrant-salt`
+plugin is installed, it should be uninstalled to ensure expected behavior._
+
+## Masterless Quickstart
+
+What follows is a basic Vagrantfile that will get salt working
+on a single minion, without a master:
+
+
+```ruby
+  Vagrant.configure("2") do |config|
+    ## Choose your base box
+    config.vm.box = "precise64"
+
+    ## For masterless, mount your salt file root
+    config.vm.synced_folder "salt/roots/", "/srv/salt/"
+
+    ## Use all the defaults:
+    config.vm.provision :salt do |salt|
+
+      salt.masterless = true
+      salt.minion_config = "salt/minion"
+      salt.run_highstate = true
+
+    end
+  end
+```
+
+This sets up a shared folder for the salt root, and copies
+the minion file over, then runs `state.highstate` on the
+machine. Your minion file must contain the line
+`file_client: local`  in order to work in a
+masterless setup.
+
+## Install Options
+
+* `install_master`  (boolean) - Should vagrant install the salt-master
+on this machine. Not supported on Windows guest machines.
+
+* `no_minion`  (boolean) - Do not install the minion, default `false`. Not supported on Windows guest machines.
+
+* `install_syndic`   (boolean) - Install the salt-syndic, default
+`false`. Not supported on Windows guest machines.
+
+* `install_type`  (stable | git | daily | testing) - Whether to install from a
+distribution's stable package manager, git tree-ish, daily ppa, or testing repository.
+
+* `install_args` (string, default: "develop") - When performing a git install, you can specify a branch, tag, or any treeish. Not supported on Windows.
+
+* `always_install`   (boolean) - Installs salt binaries even
+ if they are already detected, default `false`
+
+* `bootstrap_script` (string) - Path to your customized salt-bootstrap.sh script. Not supported on Windows guest machines.
+
+* `bootstrap_options` (string) - Additional command-line options to
+  pass to the bootstrap script.
+
+* `version`  (string, default: "2016.11.3") - Version of minion to be installed. Only supported on Windows guest machines.
+
+## Minion Options
+These only make sense when `no_minion` is `false`.
+
+* `minion_config`    (string, default: "salt/minion") - Path to
+a custom salt minion config file.
+
+* `minion_key`  (string, default: "salt/key/minion.key") - Path to your minion key
+
+* `minion_id`  (string) - Unique identifier for minion. Used for masterless and preseeding keys.
+
+* `minion_pub`  (string, default: "salt/key/minion.pub") - Path to your minion
+public key
+
+* `grains_config`  (string) - Path to a custom salt grains file. On Windows, the minion needs `ipc_mode: tcp` set otherwise it will [fail to communicate](https://github.com/saltstack/salt/issues/22796) with the master.
+
+* `masterless`  (boolean) - Calls state.highstate in local mode. Uses `minion_id` and `pillar_data` when provided.
+
+* `salt_call_args` (array) - An array of additional command line flag arguments to be passed to the `salt-call` command when provisioning with masterless.
+
+## Master Options
+These only make sense when `install_master` is `true`. Not supported on Windows guest machines.
+
+* `master_config` (string, default: "salt/master")
+  Path to a custom salt master config file.
+
+* `master_key` (string, default: "salt/key/master.pem") - Path to your master key.
+
+* `master_pub` (string, default: "salt/key/master.pub") - Path to your master public key.
+
+* `seed_master`  (dictionary) - Upload keys to master, thereby
+pre-seeding it before use. Example: `{minion_name:/path/to/key.pub}`
+
+* `salt_args` (array) - An array of additional command line flag arguments to be passed to the `salt` command when provisioning with masterless.
+
+## Execute States
+
+Either of the following may be used to actually execute states
+during provisioning.
+
+* `run_highstate` - (boolean) Executes `state.highstate` on
+vagrant up. Can be applied to any machine.
+
+## Execute Runners
+
+Either of the following may be used to actually execute runners
+during provisioning.
+
+* `run_overstate` - (boolean) Executes `state.over` on
+vagrant up. Can be applied to the master only. This is superseded by
+orchestrate. Not supported on Windows guest machines.
+
+* `orchestrations` - (array of strings) Executes `state.orchestrate` on
+vagrant up. Can be applied to the master only. This is superseded by
+run_overstate. Not supported on Windows guest machines.
+
+## Output Control
+
+These may be used to control the output of state execution:
+
+* `colorize` (boolean) - If true, output is colorized. Defaults to false.
+
+* `log_level` (string) - The verbosity of the outputs. Defaults to "debug".
+  Can be one of "all", "garbage", "trace", "debug", "info", or
+  "warning". Requires `verbose` to be set to "true".
+
+* `verbose` (boolean) - The verbosity of the outputs. Defaults to "false".
+  Must be true for log_level taking effect and the output of the salt-commands being displayed.
+
+## Pillar Data
+
+You can export pillar data for use during provisioning by using the ``pillar``
+command. Each call will merge the data so you can safely call it multiple
+times. The data passed in should only be hashes and lists. Here is an example::
+
+```ruby
+      config.vm.provision :salt do |salt|
+
+        # Export hostnames for webserver config
+        salt.pillar({
+          "hostnames" => {
+            "www" => "www.example.com",
+            "intranet" => "intranet.example.com"
+          }
+        })
+
+        # Export database credentials
+        salt.pillar({
+          "database" => {
+            "user" => "jdoe",
+            "password" => "topsecret"
+          }
+        })
+
+        salt.run_highstate = true
+
+      end
+```
+
+## Preseeding Keys
+
+Preseeding keys is the recommended way to handle provisioning
+using a master.
+On a machine with salt installed, run
+`salt-key --gen-keys=[minion_id]` to generate the necessary
+.pub and .pem files
+
+For a an example of a more advanced setup, look at the original
+[plugin](https://github.com/saltstack/salty-vagrant/tree/develop/example).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/push/index.html.md

@@ -0,0 +1,59 @@
+---
+layout: "docs"
+page_title: "Vagrant Push"
+sidebar_current: "push"
+description: |-
+  Vagrant Push is a revolutionary feature that allows users to push the code in
+  their Vagrant environment to a remote location.
+---
+
+# Vagrant Push
+
+As of version 1.7, Vagrant is capable of deploying or "pushing" application code
+in the same directory as your Vagrantfile to a remote such as an FTP server.
+
+Pushes are defined in an application's `Vagrantfile` and are invoked using the
+`vagrant push` subcommand. Much like other components of Vagrant, each Vagrant
+Push plugin has its own configuration options. Please consult the documentation
+for your Vagrant Push plugin for more information. Here is an example Vagrant
+Push configuration section in a `Vagrantfile`:
+
+```ruby
+config.push.define "ftp" do |push|
+  push.host = "ftp.company.com"
+  push.username = "..."
+  # ...
+end
+```
+
+When the application is ready to be deployed to the FTP server, just run a
+single command:
+
+```shell
+$ vagrant push
+```
+
+Much like [Vagrant Providers][], Vagrant Push also supports multiple backend
+declarations. Consider the common scenario of a staging and QA environment:
+
+```ruby
+config.push.define "staging", strategy: "ftp" do |push|
+  # ...
+end
+
+config.push.define "qa", strategy: "ftp" do |push|
+  # ...
+end
+```
+
+In this scenario, the user must pass the name of the Vagrant Push to the
+subcommand:
+
+```shell
+$ vagrant push staging
+```
+
+Vagrant Push is the easiest way to deploy your application. You can read more
+in the documentation links on the sidebar.
+
+[Vagrant Providers]: /docs/providers/  "Vagrant Providers"

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/share/connect.html.md

@@ -0,0 +1,54 @@
+---
+layout: "docs"
+page_title: "Vagrant Connect - Vagrant Share"
+sidebar_current: "share-connect"
+description: |-
+  Vagrant can share any or every port to your Vagrant environment, not
+  just SSH and HTTP.
+---
+
+# Vagrant Connect
+
+Vagrant can share any or _every_ port to your Vagrant environment, not
+just SSH and HTTP. The `vagrant connect` command gives the connecting person
+a static IP they can use to communicate to the shared Vagrant environment.
+Any TCP traffic sent to this IP is sent to the shared Vagrant environment.
+
+## Usage
+
+Just call `vagrant share --full`. This will automatically share as many ports as
+possible for remote connections. Please see
+[the Vagrant share security page](/docs/share/security.html) for more
+information.
+
+Note the share name at the end of calling `vagrant share --full`, and give this to
+the person who wants to connect to your machine. They simply have to call
+`vagrant connect NAME`. This will give them a static IP they can use to access
+your Vagrant environment.
+
+## How does it work?
+
+`vagrant connect` works by doing what Vagrant does best: managing virtual
+machines. `vagrant connect` creates a tiny virtual machine that takes up
+only around 20 MB in RAM, using VirtualBox or VMware (more provider support
+is coming soon).
+
+Any traffic sent to this tiny virtual machine is then proxied through to
+the shared Vagrant environment as if it were directed at it.
+
+## Beware: Vagrant Insecure Key
+
+If the Vagrant environment or box you are using is protected with the
+Vagrant insecure keypair (most public boxes are), then SSH will be easily
+available to anyone who connects.
+
+While hopefully you are sharing with someone you trust, in certain environments
+you might be sharing with a class, or a conference, and you do not want them
+to be able to SSH in.
+
+In this case, we recommend changing or removing the insecure key from
+the Vagrant machine.
+
+Finally, we want to note that we are working on making it so that when
+Vagrant share is used, the Vagrant private key is actively rejected unless
+explicitly allowed. This feature is not yet done, however.