apply rebase updates
This commit is contained in:
Jeff Escalante
parent
bd59de27a5
commit
e9db54a8b8
@ -102,7 +102,7 @@ It is a JSON document, structured in the following way:
|
||||
"providers": [
|
||||
{
|
||||
"name": "virtualbox",
|
||||
"url": "http://somewhere.com/bionic64_010_virtualbox.box",
|
||||
"url": "http://example.com/bionic64_010_virtualbox.box",
|
||||
"checksum_type": "sha1",
|
||||
"checksum": "foo"
|
||||
}
|
||||
|
||||
@ -62,7 +62,7 @@ $ vagrant init -f hashicorp/bionic64
|
||||
Create a Vagrantfile with the specific box, from the specific box URL:
|
||||
|
||||
```shell-session
|
||||
$ vagrant init my-company-box https://boxes.company.com/my-company.box
|
||||
$ vagrant init my-company-box https://example.com/my-company.box
|
||||
```
|
||||
|
||||
Create a Vagrantfile, locking the box to a version constraint:
|
||||
|
||||
@ -46,6 +46,12 @@ This is a list of all the valid experimental features that Vagrant recognizes:
|
||||
Enabling this feature allows triggers to recognize and execute `:type` triggers.
|
||||
More information about how these should be used can be found on the [trigger documentation page](/docs/triggers/configuration.html#trigger-types)
|
||||
|
||||
### `disks`
|
||||
|
||||
Enabling this feature will allow Vagrant to manage and configure virtual hard disks
|
||||
for certain providers. More information about supported providers and how to
|
||||
configure disks can be found on the [disk documentation page](/docs/disks/index.html)
|
||||
|
||||
### `dependency_provisioners`
|
||||
|
||||
Enabling this feature allows all provisioners to specify `before` and `after`
|
||||
|
||||
@ -34,7 +34,7 @@ that the node can register with the Chef Server:
|
||||
```ruby
|
||||
Vagrant.configure("2") do |config|
|
||||
config.vm.provision "chef_client" do |chef|
|
||||
chef.chef_server_url = "http://mychefserver.com"
|
||||
chef.chef_server_url = "http://example.com"
|
||||
chef.validation_key_path = "validation.pem"
|
||||
end
|
||||
end
|
||||
|
||||
@ -13,10 +13,10 @@ description: >-
|
||||
**Provisioner name: `"podman"`**
|
||||
|
||||
The Vagrant Podman provisioner can automatically install
|
||||
[Podman](https://www.podman.io) to be used as a drop in Docker replacement. This includes the ability to pull Docker containers, and configure certain containers to run on boot.
|
||||
|
||||
The podman provisioner is ideal for organizations that are using
|
||||
Podman as a means to manage and run their OCI images.
|
||||
[Podman](https://www.podman.io) to be used as a drop in Docker replacement.
|
||||
This includes the ability to pull Docker containers, and configure certain
|
||||
containers to run on boot. The podman provisioner is ideal for organizations
|
||||
that are using Podman as a means to manage and run their OCI images.
|
||||
|
||||
As with all provisioners, the Podman provisioner can be used along with
|
||||
all the other provisioners Vagrant has in order to setup your working
|
||||
@ -25,6 +25,9 @@ install services like databases or web servers but use Podman to house
|
||||
your application runtime. You can use the Puppet provisioner along
|
||||
with the Podman provisioner.
|
||||
|
||||
Note, that in order to install Podman on RHEL systems, the system must
|
||||
be registered.
|
||||
|
||||
## Options
|
||||
|
||||
The podman provisioner takes various options. None are required. If
|
||||
@ -41,6 +44,8 @@ of these functions have examples in more detailed sections below.
|
||||
|
||||
- `build_image` - Build an image from a Dockerfile.
|
||||
|
||||
- `kubic` - Boolean, install Podman from [Kubic project](https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable)
|
||||
|
||||
- `pull_images` - Pull the given images. This does not start these images.
|
||||
|
||||
- `post_install_provisioner` - A [provisioner block](/docs/provisioning) that runs post podman
|
||||
|
||||
@ -51,7 +51,7 @@ The Vagrant Push FTP and SFTP strategy is defined in the `Vagrantfile` using the
|
||||
|
||||
```ruby
|
||||
config.push.define "ftp" do |push|
|
||||
push.host = "ftp.company.com"
|
||||
push.host = "ftp.example.com"
|
||||
push.username = "username"
|
||||
push.password = "password"
|
||||
end
|
||||
|
||||
@ -21,7 +21,7 @@ Push configuration section in a `Vagrantfile`:
|
||||
|
||||
```ruby
|
||||
config.push.define "ftp" do |push|
|
||||
push.host = "ftp.company.com"
|
||||
push.host = "ftp.example.com"
|
||||
push.username = "..."
|
||||
# ...
|
||||
end
|
||||
|
||||
@ -1,123 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "Box File Format"
|
||||
sidebar_current: "boxes-format"
|
||||
description: |-
|
||||
The box file format for Vagrant has changed from only supporting VirtualBox to
|
||||
supporting a number different providers and box formats.
|
||||
---
|
||||
|
||||
# Box File Format
|
||||
|
||||
In the past, boxes were just [tar files](https://en.wikipedia.org/wiki/Tar_\(computing\))
|
||||
of VirtualBox exports. With Vagrant supporting multiple
|
||||
[providers](/docs/providers/) and [versioning](/docs/boxes/versioning.html)
|
||||
now, box files are slightly more complicated.
|
||||
|
||||
Box files made for Vagrant 1.0.x (the VirtualBox export `tar` files) continue
|
||||
to work with Vagrant today. When Vagrant encounters one of these old boxes,
|
||||
it automatically updates it internally to the new format.
|
||||
|
||||
Today, there are three different components:
|
||||
|
||||
* Box File - This is a compressed (`tar`, `tar.gz`, `zip`) file that is specific
|
||||
to a single provider and can contain anything. Vagrant core does not ever
|
||||
use the contents of this file. Instead, they are passed to the provider.
|
||||
Therefore, a VirtualBox box file has different contents from a VMware
|
||||
box file and so on.
|
||||
|
||||
* Box Catalog Metadata - This is a JSON document (typically exchanged
|
||||
during interactions with [HashiCorp's Vagrant Cloud](/docs/vagrant-cloud))
|
||||
that specifies the name of the box, a description, available
|
||||
versions, available providers, and URLs to the actual box files
|
||||
(next component) for each provider and version. If this catalog
|
||||
metadata does not exist, a box file can still be added directly, but
|
||||
it will not support versioning and updating.
|
||||
|
||||
* Box Information - This is a JSON document that can provide additional
|
||||
information about the box that displays when a user runs
|
||||
`vagrant box list -i`. More information is provided [here](/docs/boxes/info.html).
|
||||
|
||||
The first two components are covered in more detail below.
|
||||
|
||||
## Box File
|
||||
|
||||
The actual box file is the required portion for Vagrant. It is recommended
|
||||
you always use a metadata file alongside a box file, but direct box files
|
||||
are supported for legacy reasons in Vagrant.
|
||||
|
||||
Box files are compressed using `tar`, `tar.gz`, or `zip`. The contents of the
|
||||
archive can be anything, and is specific to each
|
||||
[provider](/docs/providers/). Vagrant core itself only unpacks
|
||||
the boxes for use later.
|
||||
|
||||
Within the archive, Vagrant does expect a single file:
|
||||
`metadata.json`. This is a JSON file that is completely unrelated to
|
||||
the above box catalog metadata component; there is only one
|
||||
`metadata.json` per box file (inside the box file), whereas one
|
||||
catalog metadata JSON document can describe multiple versions of the
|
||||
same box, potentially spanning multiple providers.
|
||||
|
||||
`metadata.json` must contain at least the "provider" key with the
|
||||
provider the box is for. Vagrant uses this to verify the provider of
|
||||
the box. For example, if your box was for VirtualBox, the
|
||||
`metadata.json` would look like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"provider": "virtualbox"
|
||||
}
|
||||
```
|
||||
|
||||
If there is no `metadata.json` file or the file does not contain valid JSON
|
||||
with at least a "provider" key, then Vagrant will error when adding the box,
|
||||
because it cannot verify the provider.
|
||||
|
||||
Other keys/values may be added to the metadata without issue. The value
|
||||
of the metadata file is passed opaquely into Vagrant and plugins can make
|
||||
use of it. At this point, Vagrant core does not use any other keys in this
|
||||
file.
|
||||
|
||||
## Box Metadata
|
||||
|
||||
The metadata is an optional component for a box (but highly recommended)
|
||||
that enables [versioning](/docs/boxes/versioning.html), updating, multiple
|
||||
providers from a single file, and more.
|
||||
|
||||
<div class="alert alert-block alert-info">
|
||||
<strong>You do not need to manually make the metadata.</strong> If you
|
||||
have an account with <a href="/docs/vagrant-cloud">HashiCorp's Vagrant Cloud</a>, you
|
||||
can create boxes there, and HashiCorp's Vagrant Cloud automatically creates
|
||||
the metadata for you. The format is still documented here.
|
||||
</div>
|
||||
|
||||
It is a JSON document, structured in the following way:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "hashicorp/bionic64",
|
||||
"description": "This box contains Ubuntu 18.04 LTS 64-bit.",
|
||||
"versions": [
|
||||
{
|
||||
"version": "0.1.0",
|
||||
"providers": [
|
||||
{
|
||||
"name": "virtualbox",
|
||||
"url": "http://example.com/bionic64_010_virtualbox.box",
|
||||
"checksum_type": "sha1",
|
||||
"checksum": "foo"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, the JSON document can describe multiple versions of a box,
|
||||
multiple providers, and can add/remove providers in different versions.
|
||||
|
||||
This JSON file can be passed directly to `vagrant box add` from the
|
||||
local filesystem using a file path or via a URL, and Vagrant will
|
||||
install the proper version of the box. In this case, the value for the
|
||||
`url` key in the JSON can also be a file path. If multiple providers
|
||||
are available, Vagrant will ask what provider you want to use.
|
||||
@ -1,71 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "vagrant init - Command-Line Interface"
|
||||
sidebar_current: "cli-init"
|
||||
description: |-
|
||||
The "vagrant init" command is used to initialize the current directory to be
|
||||
a Vagrant environment by creating an initial Vagrantfile.
|
||||
---
|
||||
|
||||
# Init
|
||||
|
||||
**Command: `vagrant init [name [url]]`**
|
||||
|
||||
This initializes the current directory to be a Vagrant environment
|
||||
by creating an initial [Vagrantfile](/docs/vagrantfile/) if
|
||||
one does not already exist.
|
||||
|
||||
If a first argument is given, it will prepopulate the `config.vm.box`
|
||||
setting in the created Vagrantfile.
|
||||
|
||||
If a second argument is given, it will prepopulate the `config.vm.box_url`
|
||||
setting in the created Vagrantfile.
|
||||
|
||||
## Options
|
||||
|
||||
* `--box-version` - (Optional) The box version or box version constraint to add
|
||||
to the `Vagrantfile`.
|
||||
|
||||
* `--force` - If specified, this command will overwrite any existing
|
||||
`Vagrantfile`.
|
||||
|
||||
* `--minimal` - If specified, a minimal Vagrantfile will be created. This
|
||||
Vagrantfile does not contain the instructional comments that the normal
|
||||
Vagrantfile contains.
|
||||
|
||||
* `--output FILE` - This will output the Vagrantfile to the given file.
|
||||
If this is "-", the Vagrantfile will be sent to stdout.
|
||||
|
||||
* `--template FILE` - Provide a custom ERB template for generating the Vagrantfile.
|
||||
|
||||
## Examples
|
||||
|
||||
Create a base Vagrantfile:
|
||||
|
||||
```sh
|
||||
$ vagrant init hashicorp/bionic64
|
||||
```
|
||||
|
||||
Create a minimal Vagrantfile (no comments or helpers):
|
||||
|
||||
```sh
|
||||
$ vagrant init -m hashicorp/bionic64
|
||||
```
|
||||
|
||||
Create a new Vagrantfile, overwriting the one at the current path:
|
||||
|
||||
```sh
|
||||
$ vagrant init -f hashicorp/bionic64
|
||||
```
|
||||
|
||||
Create a Vagrantfile with the specific box, from the specific box URL:
|
||||
|
||||
```sh
|
||||
$ vagrant init my-company-box https://example.com/my-company.box
|
||||
```
|
||||
|
||||
Create a Vagrantfile, locking the box to a version constraint:
|
||||
|
||||
```sh
|
||||
$ vagrant init --box-version '> 0.1.5' hashicorp/bionic64
|
||||
```
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "Vagrant Experimental Feature Flag"
|
||||
sidebar_current: "experimental"
|
||||
description: |-
|
||||
Introduction to Vagrants Experimental Feature Flag
|
||||
---
|
||||
|
||||
# Experimental Feature Flag
|
||||
|
||||
Some features that aren't ready for release can be enabled through this feature
|
||||
flag. There are a couple of different ways of going about enabling these features.
|
||||
It is also worth noting that Vagrant will not validate the existence of a feature
|
||||
flag.
|
||||
|
||||
For example if you are on Linux or Mac, and you wish to enable every single experimental feature, you can set the flag
|
||||
to "on" by setting it to `1`:
|
||||
|
||||
```shell
|
||||
export VAGRANT_EXPERIMENTAL="1"
|
||||
```
|
||||
|
||||
You can also enable some or many features if there are specific ones you would like,
|
||||
but don't want every single feature enabled:
|
||||
|
||||
```shell
|
||||
# Only enables feature_one
|
||||
export VAGRANT_EXPERIMENTAL="feature_one"
|
||||
```
|
||||
|
||||
```shell
|
||||
# Enables both feature_one and feature_two
|
||||
export VAGRANT_EXPERIMENTAL="feature_one,feature_two"
|
||||
```
|
||||
|
||||
## Valid experimental features
|
||||
|
||||
<div class="alert alert-warning">
|
||||
<strong>Advanced topic!</strong> This is an advanced topic for use only if
|
||||
you want to use new Vagrant features. If you are just getting
|
||||
started with Vagrant, you may safely skip this section.
|
||||
</div>
|
||||
|
||||
This is a list of all the valid experimental features that Vagrant recognizes:
|
||||
|
||||
### `typed_triggers`
|
||||
|
||||
Enabling this feature allows triggers to recognize and execute `:type` triggers.
|
||||
More information about how these should be used can be found on the [trigger documentation page](/docs/triggers/configuration.html#trigger-types)
|
||||
|
||||
### `disks`
|
||||
|
||||
Enabling this feature will allow Vagrant to manage and configure virtual hard disks
|
||||
for certain providers. More information about supported providers and how to
|
||||
configure disks can be found on the [disk documentation page](/docs/disks/index.html)
|
||||
|
||||
### `dependency_provisioners`
|
||||
|
||||
Enabling this feature allows all provisioners to specify `before` and `after`
|
||||
options. These options allow provisioners to be configured to run before or after
|
||||
any given "root" provisioner. more information about these options can be found
|
||||
on the [base provisioner documentation page](/docs/provisioning/basic_usage.html)
|
||||
@ -1,123 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "Chef Client - Provisioning"
|
||||
sidebar_current: "provisioning-chefclient"
|
||||
description: |-
|
||||
The Vagrant Chef Client provisioner allows you to provision the guest using
|
||||
Chef, specifically by connecting to an existing Chef Server and registering
|
||||
the Vagrant machine as a node within your infrastructure.
|
||||
---
|
||||
|
||||
# Chef Client Provisioner
|
||||
|
||||
**Provisioner name: `chef_client`**
|
||||
|
||||
The Vagrant Chef Client provisioner allows you to provision the guest using
|
||||
[Chef](https://www.chef.io/chef/), specifically by connecting
|
||||
to an existing Chef Server and registering the Vagrant machine as a
|
||||
node within your infrastructure.
|
||||
|
||||
If you are just learning Chef for the first time, you probably want
|
||||
to start with the [Chef Solo](/docs/provisioning/chef_solo.html)
|
||||
provisioner.
|
||||
|
||||
<div class="alert alert-warning">
|
||||
<strong>Warning:</strong> If you are not familiar with Chef and Vagrant already,
|
||||
it is recommended to start with the <a href="/docs/provisioning/shell.html">shell
|
||||
provisioner</a>.
|
||||
</div>
|
||||
|
||||
## Authenticating
|
||||
|
||||
The minimum required to use provision using Chef Client is to provide
|
||||
a URL to the Chef Server as well as the path to the validation key so
|
||||
that the node can register with the Chef Server:
|
||||
|
||||
```ruby
|
||||
Vagrant.configure("2") do |config|
|
||||
config.vm.provision "chef_client" do |chef|
|
||||
chef.chef_server_url = "http://example.com"
|
||||
chef.validation_key_path = "validation.pem"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
The node will register with the Chef Server specified, download the
|
||||
proper run list for that node, and provision.
|
||||
|
||||
## Specifying a Run List
|
||||
|
||||
Normally, the Chef Server is responsible for specifying the run list
|
||||
for the node. However, you can override what the Chef Server sends
|
||||
down by manually specifying a run list:
|
||||
|
||||
```ruby
|
||||
Vagrant.configure("2") do |config|
|
||||
config.vm.provision "chef_client" do |chef|
|
||||
# Add a recipe
|
||||
chef.add_recipe "apache"
|
||||
|
||||
# Or maybe a role
|
||||
chef.add_role "web"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
Remember, this will _override_ the run list specified on the Chef
|
||||
server itself.
|
||||
|
||||
## Environments
|
||||
|
||||
You can specify the [environment](https://docs.chef.io/environments.html)
|
||||
for the node to come up in using the `environment` configuration option:
|
||||
|
||||
```ruby
|
||||
Vagrant.configure("2") do |config|
|
||||
config.vm.provision "chef_client" do |chef|
|
||||
# ...
|
||||
|
||||
chef.environment = "development"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## Other Configuration Options
|
||||
|
||||
There are a few more configuration options available. These generally do not
|
||||
need to be modified but are available if your Chef Server requires customization
|
||||
of these variables.
|
||||
|
||||
* `client_key_path`
|
||||
* `node_name`
|
||||
* `validation_client_name`
|
||||
|
||||
In addition to all the options listed above, the Chef Client provisioner supports
|
||||
the [common options for all Chef provisioners](/docs/provisioning/chef_common.html).
|
||||
|
||||
## Cleanup
|
||||
|
||||
When you provision your Vagrant virtual machine with Chef Server, it creates a
|
||||
new Chef "node" entry and Chef "client" entry on the Chef Server, using the
|
||||
hostname of the machine. After you tear down your guest machine, Vagrant can be
|
||||
configured to do it automatically with the following settings:
|
||||
|
||||
```ruby
|
||||
chef.delete_node = true
|
||||
chef.delete_client = true
|
||||
```
|
||||
|
||||
If you do not specify it or set it to `false`, you must explicitly delete these
|
||||
entries from the Chef Server before you provision a new one with Chef Server.
|
||||
For example, using Chef's built-in `knife` tool:
|
||||
|
||||
```
|
||||
$ knife node delete precise64
|
||||
$ knife client delete precise64
|
||||
```
|
||||
|
||||
If you fail to do so, you will get the following error when Vagrant
|
||||
tries to provision the machine with Chef Client:
|
||||
|
||||
```
|
||||
HTTP Request Returned 409 Conflict: Client already exists.
|
||||
```
|
||||
@ -1,181 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "Podman - Provisioning"
|
||||
sidebar_current: "provisioning-podman"
|
||||
description: |-
|
||||
The Vagrant Podman provisioner can automatically install Podman, and run it as a drop in replacement for Docker.
|
||||
---
|
||||
|
||||
# Podman Provisioner
|
||||
|
||||
**Provisioner name: `"podman"`**
|
||||
|
||||
The Vagrant Podman provisioner can automatically install
|
||||
[Podman](https://www.podman.io) to be used as a drop in Docker replacement.
|
||||
This includes the ability to pull Docker containers, and configure certain
|
||||
containers to run on boot. The podman provisioner is ideal for organizations
|
||||
that are using Podman as a means to manage and run their OCI images.
|
||||
|
||||
As with all provisioners, the Podman 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 Podman to house
|
||||
your application runtime. You can use the Puppet provisioner along
|
||||
with the Podman provisioner.
|
||||
|
||||
Note, that in order to install Podman on RHEL systems, the system must
|
||||
be registered.
|
||||
|
||||
## Options
|
||||
|
||||
The podman provisioner takes various options. None are required. If
|
||||
no options are provided, the Podman provisioner will only install Podman
|
||||
for you (if it is not already installed).
|
||||
|
||||
* `images` (array) - A list of images to pull using `podman 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 Podman provisioner. Most
|
||||
of these functions have examples in more detailed sections below.
|
||||
|
||||
* `build_image` - Build an image from a Dockerfile.
|
||||
|
||||
* `kubic` - Boolean, install Podman from [Kubic project](https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable)
|
||||
|
||||
* `pull_images` - Pull the given images. This does not start these images.
|
||||
|
||||
* `post_install_provisioner` - A [provisioner block](/docs/provisioning) that runs post podman
|
||||
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 "podman" do |d|
|
||||
d.build_image "/vagrant/app"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
The argument to build an image is the path to give to `podman 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 `podman build`. Use this
|
||||
to pass in things like `-t "foo"` to tag the image.
|
||||
|
||||
## Pulling Images
|
||||
|
||||
The podman 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 "podman",
|
||||
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 "podman" do |d|
|
||||
d.pull_images "ubuntu"
|
||||
d.pull_images "vagrant"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## Running Containers
|
||||
|
||||
In addition to pulling images, the Podman 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 "podman" do |d|
|
||||
d.run "rabbitmq"
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
This will `podman 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 `podman run` (same as the extra arguments that can be specified 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 Podman.
|
||||
|
||||
* `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 `podman 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 Podman to run a container
|
||||
with the Vagrant shared directory mounted inside of it:
|
||||
|
||||
```ruby
|
||||
Vagrant.configure("2") do |config|
|
||||
config.vm.provision "podman" 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 "podman" do |d|
|
||||
d.run "db-1", image: "user/mysql"
|
||||
d.run "db-2", image: "user/mysql"
|
||||
end
|
||||
end
|
||||
```
|
||||
@ -1,64 +0,0 @@
|
||||
---
|
||||
layout: "docs"
|
||||
page_title: "Vagrant Push - FTP & SFTP Strategy"
|
||||
sidebar_current: "push-ftp"
|
||||
description: |-
|
||||
Vagrant Push FTP and SFTP strategy pushes the code in your Vagrant development
|
||||
environment to a remote FTP or SFTP server.
|
||||
---
|
||||
|
||||
# Vagrant Push
|
||||
|
||||
## FTP & SFTP Strategy
|
||||
|
||||
Vagrant Push FTP and SFTP strategy pushes the code in your Vagrant development
|
||||
environment to a remote FTP or SFTP server.
|
||||
|
||||
The Vagrant Push FTP And SFTP strategy supports the following configuration
|
||||
options:
|
||||
|
||||
- `host` - The address of the remote (S)FTP server. If the (S)FTP server is
|
||||
running on a non-standard port, you can specify the port after the address
|
||||
(`host:port`).
|
||||
|
||||
- `username` - The username to use for authentication with the (S)FTP server.
|
||||
|
||||
- `password` - The password to use for authentication with the (S)FTP server.
|
||||
|
||||
- `passive` - Use passive FTP (default is true).
|
||||
|
||||
- `secure` - Use secure (SFTP) (default is false).
|
||||
|
||||
- `destination` - The root destination on the target system to sync the files
|
||||
(default is `/`).
|
||||
|
||||
- `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.
|
||||
|
||||
|
||||
### Usage
|
||||
|
||||
The Vagrant Push FTP and SFTP strategy is defined in the `Vagrantfile` using the
|
||||
`ftp` key:
|
||||
|
||||
```ruby
|
||||
config.push.define "ftp" do |push|
|
||||
push.host = "ftp.example.com"
|
||||
push.username = "username"
|
||||
push.password = "password"
|
||||
end
|
||||
```
|
||||
|
||||
And then push the application to the FTP or SFTP server:
|
||||
|
||||
```shell
|
||||
$ vagrant push
|
||||
```
|
||||
@ -1,59 +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.
|
||||
|
||||
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.example.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"
|
||||
@ -1,33 +0,0 @@
|
||||
---
|
||||
layout: inner
|
||||
sidebar_current: "about-security"
|
||||
page_title: "Security"
|
||||
description: |-
|
||||
Vagrant takes security very seriously. Please responsibly disclose any security vulnerabilities found and we'll handle it quickly.
|
||||
---
|
||||
|
||||
<h1>Vagrant Security</h1>
|
||||
|
||||
<p>
|
||||
We understand that many users place a high level of trust in HashiCorp
|
||||
and the tools we build. We apply best practices and focus on security to
|
||||
make sure we can maintain the trust of the community.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We deeply appreciate any effort to disclose vulnerabilities responsibly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you would like to report a vulnerability, please see the <a
|
||||
href="https://www.hashicorp.com/security">HashiCorp security
|
||||
page</a>, which has the proper email to communicate with as well as our
|
||||
PGP key. Please <strong>do not create a GitHub issue for security
|
||||
concerns</strong>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you need to report a non-security related bug, please open and issue
|
||||
on the <a href="https://github.com/mitchellh/Vagrant">Vagrant
|
||||
GitHub repository</a>.
|
||||
</p>
|
||||
Loading…
x
Reference in New Issue
Block a user