From e9db54a8b84d4b1e9d34478a55308ce2b7df02aa Mon Sep 17 00:00:00 2001 From: Jeff Escalante Date: Thu, 21 May 2020 16:56:28 -0400 Subject: [PATCH] apply rebase updates --- website/pages/docs/boxes/format.mdx | 2 +- website/pages/docs/cli/init.mdx | 2 +- website/pages/docs/experimental.mdx | 6 + .../pages/docs/provisioning/chef_client.mdx | 2 +- website/pages/docs/provisioning/podman.mdx | 13 +- website/pages/docs/push/ftp.mdx | 2 +- website/pages/docs/push/index.mdx | 2 +- website/source/docs/boxes/format.html.md | 123 ------------ website/source/docs/cli/init.html.md | 71 ------- .../source/docs/experimental/index.html.md | 62 ------ .../docs/provisioning/chef_client.html.md | 123 ------------ .../source/docs/provisioning/podman.html.md | 181 ------------------ website/source/docs/push/ftp.html.md | 64 ------- website/source/docs/push/index.html.md | 59 ------ website/source/security.html.erb | 33 ---- 15 files changed, 20 insertions(+), 725 deletions(-) delete mode 100644 website/source/docs/boxes/format.html.md delete mode 100644 website/source/docs/cli/init.html.md delete mode 100644 website/source/docs/experimental/index.html.md delete mode 100644 website/source/docs/provisioning/chef_client.html.md delete mode 100644 website/source/docs/provisioning/podman.html.md delete mode 100644 website/source/docs/push/ftp.html.md delete mode 100644 website/source/docs/push/index.html.md delete mode 100644 website/source/security.html.erb diff --git a/website/pages/docs/boxes/format.mdx b/website/pages/docs/boxes/format.mdx index ab8ae9917..7c7581633 100644 --- a/website/pages/docs/boxes/format.mdx +++ b/website/pages/docs/boxes/format.mdx @@ -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" } diff --git a/website/pages/docs/cli/init.mdx b/website/pages/docs/cli/init.mdx index d597f019f..df7e2da3f 100644 --- a/website/pages/docs/cli/init.mdx +++ b/website/pages/docs/cli/init.mdx @@ -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: diff --git a/website/pages/docs/experimental.mdx b/website/pages/docs/experimental.mdx index 1bf6539e2..1c02394ab 100644 --- a/website/pages/docs/experimental.mdx +++ b/website/pages/docs/experimental.mdx @@ -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` diff --git a/website/pages/docs/provisioning/chef_client.mdx b/website/pages/docs/provisioning/chef_client.mdx index da143b9b0..b29540c03 100644 --- a/website/pages/docs/provisioning/chef_client.mdx +++ b/website/pages/docs/provisioning/chef_client.mdx @@ -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 diff --git a/website/pages/docs/provisioning/podman.mdx b/website/pages/docs/provisioning/podman.mdx index 2e7aae6a6..149f68f3d 100644 --- a/website/pages/docs/provisioning/podman.mdx +++ b/website/pages/docs/provisioning/podman.mdx @@ -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 diff --git a/website/pages/docs/push/ftp.mdx b/website/pages/docs/push/ftp.mdx index 737192c7b..995f53d18 100644 --- a/website/pages/docs/push/ftp.mdx +++ b/website/pages/docs/push/ftp.mdx @@ -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 diff --git a/website/pages/docs/push/index.mdx b/website/pages/docs/push/index.mdx index 8b212da16..338ed768d 100644 --- a/website/pages/docs/push/index.mdx +++ b/website/pages/docs/push/index.mdx @@ -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 diff --git a/website/source/docs/boxes/format.html.md b/website/source/docs/boxes/format.html.md deleted file mode 100644 index 5f971f8b2..000000000 --- a/website/source/docs/boxes/format.html.md +++ /dev/null @@ -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. - -
- You do not need to manually make the metadata. If you - have an account with HashiCorp's Vagrant Cloud, you - can create boxes there, and HashiCorp's Vagrant Cloud automatically creates - the metadata for you. The format is still documented here. -
- -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. diff --git a/website/source/docs/cli/init.html.md b/website/source/docs/cli/init.html.md deleted file mode 100644 index a52c0f17c..000000000 --- a/website/source/docs/cli/init.html.md +++ /dev/null @@ -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 -``` diff --git a/website/source/docs/experimental/index.html.md b/website/source/docs/experimental/index.html.md deleted file mode 100644 index 06c437867..000000000 --- a/website/source/docs/experimental/index.html.md +++ /dev/null @@ -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 - -
- Advanced topic! 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. -
- -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) diff --git a/website/source/docs/provisioning/chef_client.html.md b/website/source/docs/provisioning/chef_client.html.md deleted file mode 100644 index 6fd49118b..000000000 --- a/website/source/docs/provisioning/chef_client.html.md +++ /dev/null @@ -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. - -
- Warning: If you are not familiar with Chef and Vagrant already, - it is recommended to start with the shell - provisioner. -
- -## 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. -``` diff --git a/website/source/docs/provisioning/podman.html.md b/website/source/docs/provisioning/podman.html.md deleted file mode 100644 index c03140c6b..000000000 --- a/website/source/docs/provisioning/podman.html.md +++ /dev/null @@ -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 -``` diff --git a/website/source/docs/push/ftp.html.md b/website/source/docs/push/ftp.html.md deleted file mode 100644 index 43cab4587..000000000 --- a/website/source/docs/push/ftp.html.md +++ /dev/null @@ -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 -``` diff --git a/website/source/docs/push/index.html.md b/website/source/docs/push/index.html.md deleted file mode 100644 index 4cc52d555..000000000 --- a/website/source/docs/push/index.html.md +++ /dev/null @@ -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" diff --git a/website/source/security.html.erb b/website/source/security.html.erb deleted file mode 100644 index c3342dc31..000000000 --- a/website/source/security.html.erb +++ /dev/null @@ -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. ---- - -

Vagrant Security

- -

- 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. -

- -

- We deeply appreciate any effort to disclose vulnerabilities responsibly. -

- -

- If you would like to report a vulnerability, please see the HashiCorp security - page, which has the proper email to communicate with as well as our - PGP key. Please do not create a GitHub issue for security - concerns. -

- -

- If you need to report a non-security related bug, please open and issue - on the Vagrant - GitHub repository. -