website/www: push post
This commit is contained in:
Mitchell Hashimoto
parent
09cc1f1d73
commit
1be7529b17
|
|
@ -0,0 +1,122 @@
|
|||
---
|
||||
page_title: "Vagrant Push: One Command to Deploy Any Application"
|
||||
title: "Vagrant Push: One Command to Deploy Any Application"
|
||||
author: "Mitchell Hashimoto"
|
||||
author_url: https://github.com/mitchellh
|
||||
---
|
||||
|
||||
Vagrant 1.7 comes with a new command: `vagrant push`. Just as "vagrant up"
|
||||
creates a development environment for any application, `vagrant push` is
|
||||
a single command to _deploy_ any application.
|
||||
|
||||
The goal of Vagrant is to give developers a single workflow to develop
|
||||
applications effectively. "vagrant up" creates a development for any
|
||||
applications, "vagrant share" enables collaboration for any application.
|
||||
Deploying was the next logical step for Vagrant, now possible with
|
||||
"vagrant push".
|
||||
|
||||
Like every other component of Vagrant, push can be configured using multiple
|
||||
strategies. "vagrant push" can deploy via FTP, Heroku,
|
||||
[Atlas](https://atlas.hashicorp.com), or by executing any local script.
|
||||
Other strategies can be added via plugins and more will be added to core
|
||||
as time goes on.
|
||||
|
||||
Read on to learn more.
|
||||
|
||||
READMORE
|
||||
|
||||
### Demo
|
||||
|
||||
We've prepared a short video showing Vagrant Push in action.
|
||||
|
||||
<iframe src="//player.vimeo.com/video/114328000" width="680" height="382" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
|
||||
|
||||
### Push to Deploy
|
||||
|
||||
`vagrant push` works like anything else in Vagrant: configure it in the
|
||||
Vagrantfile, and it is immediately available to every developer. Push
|
||||
configuration is simple and easy to understand:
|
||||
|
||||
```
|
||||
config.push.define "ftp" do |push|
|
||||
push.host = "ftp.company.com"
|
||||
push.username = "username"
|
||||
push.password = "mypassword"
|
||||
end
|
||||
```
|
||||
|
||||
And then to push the application to the FTP or SFTP server:
|
||||
|
||||
```
|
||||
$ vagrant push
|
||||
...
|
||||
```
|
||||
|
||||
Multiple `config.push.define` declarations can be in a Vagrantfile to
|
||||
define multiple pushes, perhaps one to staging and one to production, for
|
||||
example.
|
||||
|
||||
### A Single Command
|
||||
|
||||
The biggest benefit of Vagrant Push is defining a single command
|
||||
to deploy any application. Whether the deploy process is complex or
|
||||
is just a simple push to Heroku, developers only need to know that any
|
||||
application within their organizations can be deployed with `vagrant push`.
|
||||
|
||||
For complicated deploys, the benefit is obvious. For simpler deploys, such
|
||||
as a push to Heroku, Vagrant Push is still useful. Besides not having
|
||||
to know that Heroku is being used under the hood, Vagrant Push will
|
||||
automatically configure your Git remote so the push works. Prior to this,
|
||||
you'd at least have to know the Heroku application name and configure
|
||||
your local repository to be able to push to it.
|
||||
|
||||
Of course, not applications stay that simple, and if your application
|
||||
outgrows Heroku, then the deploy process doesn't change with Vagrant:
|
||||
`vagrant push`, to deploy any application.
|
||||
|
||||
### Push Strategies
|
||||
|
||||
Like providers, provisioners, and other features in Vagrant, pushes can
|
||||
be configured with multiple _strategies_. Vagrant 1.7 ships with four
|
||||
strategies:
|
||||
|
||||
* [Atlas](https://docs.vagrantup.com/v2/push/atlas.html) - Push application
|
||||
to [Atlas](https://atlas.hashicorp.com), a commercial
|
||||
product from HashiCorp.
|
||||
|
||||
* [FTP/SFTP](https://docs.vagrantup.com/v2/push/ftp.html) - Upload files
|
||||
via FTP or SFTP to a remote server. This is great for static sites,
|
||||
PHP, etc.
|
||||
|
||||
* [Heroku](https://docs.vagrantup.com/v2/push/heroku.html) - Push your
|
||||
Git repository to Heroku, and configure the Git remote for you if
|
||||
it doesn't already exist.
|
||||
|
||||
* [Local Exec](https://docs.vagrantup.com/v2/push/local-exec.html) -
|
||||
Executes a local script on the system using a shell, deferring deployment
|
||||
logic to the user. This is for custom behavior or more complicated
|
||||
interactions with systems.
|
||||
|
||||
In addition to these built-in strategies, new strategies can be
|
||||
[built just like any other Vagrant plugin](https://docs.vagrantup.com/v2/plugins/development-basics.html).
|
||||
This allows 3rd parties to extend the capabilities of `vagrant push`, and
|
||||
will surely result in future versions of Vagrant shipping with more push
|
||||
strategies.
|
||||
|
||||
### Next
|
||||
|
||||
This is a historic day for Vagrant. Vagrant 0.1 came out and defined
|
||||
"vagrant up" to build a development environment for any application.
|
||||
Vagrant 1.1 made it possible to have development environments on top of
|
||||
any provider (VMware, Docker, etc.). Vagrant 1.5 introduced the "share"
|
||||
command to collaborate. And now, Vagrant 1.7 completes the development
|
||||
process with "push" to deploy.
|
||||
|
||||
The mission of Vagrant has been the same since day one: development
|
||||
environments made easy. This mission spans any language choice, any
|
||||
provider choice, and likewise any choice of how to deploy these
|
||||
applications. Push continues this mission by adding a necessary
|
||||
feature to the development workflow.
|
||||
|
||||
With Vagrant 1.7 available, we'll be blogging about more of the features
|
||||
as well as creeping towards a 2.0!
|
||||
Loading…
Reference in New Issue