Flesh out initial application deployment docs

- Move some docs to nginx and checks pages
- Flesh out dockerfiles and image tagging documentation a bit on their own pages
This commit is contained in:
Jose Diaz-Gonzalez
2015-10-14 05:20:20 -04:00
parent 1424df5697
commit 9010bc8fa4
5 changed files with 333 additions and 181 deletions

View File

@@ -1,4 +1,54 @@
# Checks Examples
# Zero Downtime Deploys
> New as of 0.3.0
Following a deploy, dokku will now wait `10` seconds before routing traffic to the nwe container. If the container is not running after this time, then the deploy is failed and your old container will continue serving traffic. You can configure this time using the following command:
```shell
dokku config:set --global DOKKU_DEFAULT_CHECKS_WAIT=30
```
If your application needs a longer period to boot up - perhaps to load data into memory, or because of slow boot time - you may also use dokku's `checks` functionality to more precisely check whether an application can serve traffic or not.
To specify checks, add a `CHECKS` file to the root of your project directory. This is a text file with one line per check. Empty lines and lines starting with `#` are ignored.
A check is a relative URL and may be followed by expected content from the page, for example:
```
/about Our Amazing Team
```
Dokku will wait `5` seconds before running the checks to give server time to start. This time can be overridden on a per-app basis in the `CHECKS` file by setting `WAIT=nn`. You may also override this for the global dokku installation:
```shell
dokku config:set --global DOKKU_CHECKS_WAIT=15
```
Dokku will wait `60` seconds before stopping the old container so that existing connections are given a chance to complete. This time is also configurable globally:
```shell
dokku config:set --global DOKKU_WAIT_TO_RETIRE=120
```
> Note that during this time, multiple containers may be running on your server, which can be an issue for memory-hungry applications on memory-constrained servers.
Dokku will retry the checks `5` times until the checks are successful. If all 5 checks fail, the deployment is considered failed. This can be overridden in the `CHECKS` file by setting `ATTEMPTS=nn`. This number is also configurable globally:
```shell
dokku config:set --global DOKKU_CHECKS_ATTEMPTS=2
```
You can also choose to skip checks completely either globally or on a per-application basis:
```shell
# globally
dokku config:set --global DOKKU_SKIP_ALL_CHECKS=true
# for APP
dokku config:set APP DOKKU_SKIP_ALL_CHECKS=true
```
## Checks Examples
The CHECKS file may contain empty lines, comments (lines starting with #),
settings (NAME=VALUE) and check instructions.
@@ -6,36 +56,49 @@ settings (NAME=VALUE) and check instructions.
The format of a check instruction is a path, optionally followed by the
expected content. For example:
/ My Amazing App
/stylesheets/index.css .body
/scripts/index.js $(function()
/images/logo.png
```
/ My Amazing App
/stylesheets/index.css .body
/scripts/index.js $(function()
/images/logo.png
```
To check an application that supports multiple hostnames, use relative URLs
that include the hostname, for example:
//admin.example.com Admin Dashboard
//static.example.com/logo.png
```
//admin.example.com Admin Dashboard
//static.example.com/logo.png
```
You can also specify the protocol to explicitly check HTTPS requests.
The default behavior is to wait for 5 seconds before running the first check,
and timeout each check to 30 seconds.
```
https://admin.example.com Admin Dashboard
https://static.example.com/logo.png
```
The default behavior is to wait for 5 seconds before running the first check, and timeout each check to 30 seconds.
By default, checks will be attempted 5 times. (Retried 4 times)
You can change these by setting WAIT, TIMEOUT and ATTEMPTS to different values, for
You can change these by setting `WAIT`, `TIMEOUT` and `ATTEMPTS` to different values, for
example:
WAIT=30 # Wait 1/2 minute
TIMEOUT=60 # Timeout after a minute
ATTEMPTS=10 # attempt checks 10 times
```
WAIT=30 # Wait 1/2 minute
TIMEOUT=60 # Timeout after a minute
ATTEMPTS=10 # attempt checks 10 times
# Example: Successful Rails Deployment
In this example, a rails applicaiton is successfully deployed to dokku. The initial round of checks fails while the server is starting, but once it starts they succeed and the deployment is successful.
ATTEMPTS is set to 6, but the third attempt succeeds.
/ My Amazing App
```
## CHECKS file
## Example: Successful Rails Deployment
In this example, a rails applicaiton is successfully deployed to dokku. The initial round of checks fails while the server is starting, but once it starts they succeed and the deployment is successful. `ATTEMPTS` is set to 6, but the third attempt succeeds.
### CHECKS file
````
WAIT=5
@@ -45,7 +108,7 @@ ATTEMPTS=6
> check.txt is a text file returning the string 'simple_check'
## Deploy Output
### Deploy Output
> Note: The output has been trimmed for brevity
@@ -101,12 +164,12 @@ curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
http://myapp.dokku.example.com
````
# Example: Failing Rails Deployment
## Example: Failing Rails Deployment
In this example, a Rails application fails to deploy. The reason for the failure is that the postgres database connection fails. The initial checks will fail while we wait for the server to start up, just like in the above example. However, once the server does start accepting connections, we will see an error 500 due to the postgres database connection failure.
Once the attempts have been exceeded, the deployment fails and we see the container output, which shows the Postgres connection errors.
## CHECKS file
### CHECKS file
````
WAIT=5
@@ -116,7 +179,7 @@ ATTEMPTS=6
> The check to the root url '/' would normally access the database.
## Deploy Output
### Deploy Output
> Note: The output has been trimmed for brevity