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

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

@@ -1,196 +0,0 @@
----
-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.
-
-* `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 a shell provisioner before the Docker provisioner
-that sets this file up. The Docker provisioner will not modify this file
-in a destructive way.

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

@@ -1,51 +0,0 @@
----
-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
-
-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".

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/provisioning/salt.html.md

@@ -1,183 +0,0 @@
----
-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.
-
-## 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}`
-
-## 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-5333e60e2d38/website/source/docs/push/atlas.html.md

@@ -1,68 +0,0 @@
----
-layout: "docs"
-page_title: "Vagrant Push - Atlas Strategy"
-sidebar_current: "push-atlas"
-description: |-
-  Atlas is HashiCorp's commercial offering to bring your Vagrant development
-  environments to production. The Vagrant Push Atlas strategy pushes your
-  application's code to HashiCorp's Atlas service.
----
-
-# Vagrant Push
-
-## Atlas Strategy
-
-[Atlas][] is HashiCorp's commercial offering to bring your Vagrant development
-environments to production. You can read more about HashiCorp's Atlas and all
-its features on [the Atlas homepage][Atlas]. The Vagrant Push Atlas strategy
-pushes your application's code to HashiCorp's Atlas service.
-
-The Vagrant Push Atlas strategy supports the following configuration options:
-
-- `app` - The name of the application in [HashiCorp's Atlas][Atlas]. If the
-  application does not exist, it will be created with user confirmation.
-
-- `exclude` - Add a file or file pattern to exclude from the upload, relative to
-  the `dir`. This value may be specified multiple times and is additive.
-  `exclude` take precedence over `include` values.
-
-- `include` - Add a file or file pattern to include in the upload, relative to
-  the `dir`. This value may be specified multiple times and is additive.
-
-- `dir` - The base directory containing the files to upload. By default this is
-  the same directory as the Vagrantfile, but you can specify this if you have
-  a `src` folder or `bin` folder or some other folder you want to upload.
-
-- `vcs` - If set to true, Vagrant will automatically use VCS data to determine
-  the files to upload. Uncommitted changes will not be deployed.
-
-Additionally, the following options are exposed for power users of the Vagrant
-Atlas push strategy. Most users will not require these options:
-
-- `address` - The address of the Atlas server to upload to. By default this will
-  be the public Atlas server.
-
-- `token` - The Atlas token to use. If the user has run `vagrant login`, this
-  will the token generated by that command. If the environment variable
-  `ATLAS_TOKEN` is set, the uploader will use this value. By default, this is
-  nil.
-
-
-### Usage
-
-The Vagrant Push Atlas strategy is defined in the `Vagrantfile` using the
-`atlas` key:
-
-```ruby
-config.push.define "atlas" do |push|
-  push.app = "username/application"
-end
-```
-
-And then push the application to Atlas:
-
-```shell
-$ vagrant push
-```
-
-[Atlas]: /docs/other/atlas.html "HashiCorp's Atlas Service"

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

@@ -1,61 +0,0 @@
----
-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 or
-[HashiCorp's Atlas][Atlas].
-
-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.
-
-[Atlas]: https://atlas.hashicorp.com/  "HashiCorp's Atlas Service"
-[Vagrant Providers]: /docs/providers/  "Vagrant Providers"

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

@@ -1,57 +0,0 @@
----
-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`. This will automatically share as many ports as
-possible for remote connections. If the Vagrant environment has a static IP or
-DNS address, then almost every port will be available (although some must be
-explicitly enabled for security reasons). Otherwise, Vagrant will only
-expose forwarded ports on the machine. 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`, 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.