github/dokku
0
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

Fix Deployment guides style

Browse Source
This commit is contained in:
Jay Jun
2019-02-19 20:01:24 +08:00
parent 42b6876f2c
commit e839c29916
14 changed files with 142 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
docs/deployment/zero-downtime-deploys.md
View File

@@ -11,7 +11,7 @@ checks:run <app> [process-type(s)] Runs zero-downtime checks for all proce
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
```
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by for an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds _after_ the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by for an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds *after* the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
You may both create user-defined checks for web processes using a `CHECKS` file, as well as customize any and all parts of this experience using the checks plugin.
@@ -19,17 +19,17 @@ You may both create user-defined checks for web processes using a `CHECKS` file,
> as the Django framework - checks for specific hostnames or header values, these
> checks will fail. To avoid this:
>
> - Remove such checks from your code: Modify your application to remove the hostname check completely
> - Allow checks from all hostnames: Modify your application to accept a dynamically provided hostname
> - Specify the domain within the check: See below for further documentation
> - Remove such checks from your code: Modify your application to remove the hostname check completely.
> - Allow checks from all hostnames: Modify your application to accept a dynamically provided hostname.
> - Specify the domain within the check: See below for further documentation.
## Configuring Check Settings using the `config` plugin
## Configuring check settings using the `config` plugin
There are certain settings that can be configured via environment variables:
- `DOKKU_DEFAULT_CHECKS_WAIT`: (default: `10`) If no user-defined checks are specified - or if the process being checked is not a `web` process - this is the period of time Dokku will wait before checking that a container is still running.
- `DOKKU_DOCKER_STOP_TIMEOUT`: (default: `10`) Configurable grace period given to the `docker stop` command. If a container has not stopped by this time, a `kill -9` signal or equivalent is sent in order to force-terminate the container. Both the `ps:stop` and `apps:destroy` commands _also_ respect this value. If not specified, the docker defaults for the [docker stop command](https://docs.docker.com/engine/reference/commandline/stop/) will be used.
- `DOKKU_WAIT_TO_RETIRE`: (default: `60`) After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections.
- `DOKKU_DOCKER_STOP_TIMEOUT`: (default: `10`) Configurable grace period given to the `docker stop` command. If a container has not stopped by this time, a `kill -9` signal or equivalent is sent in order to force-terminate the container. Both the `ps:stop` and `apps:destroy` commands *also* respect this value. If not specified, the Docker defaults for the [`docker stop` command](https://docs.docker.com/engine/reference/commandline/stop/) will be used.
- `DOKKU_WAIT_TO_RETIRE`: (default: `60`) After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running HTTP connections.
The following settings may also be specified in the `CHECKS` file, though are available as environment variables in order to ease application reuse.
@@ -56,7 +56,7 @@ dokku checks:skip node-js-app worker,web
DOKKU_CHECKS_SKIPPED: worker,web
```
Zero-downtime checks can also be disabled completely. This will stop old containers **before** new ones start, which may result in broken connections and downtime if your application fails to boot properly.
Zero downtime checks can also be disabled completely. This will stop old containers *before* new ones start, which may result in broken connections and downtime if your application fails to boot properly.
```shell
dokku checks:disable node-js-app worker
@@ -110,22 +110,22 @@ You can pass flags which will output only the value of the specific information
dokku checks:report node-js-sample --checks-disabled-list
```
## Customizing Checks
## Customizing checks
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.
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.
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, Dokku will fallback to the aforementioned process uptime check.
To specify checks, add a `CHECKS` file to the root of your project directory. The `CHECKS` file should be plain text and may contain:
- Check instructions
- Settings (NAME=VALUE)
- Comments (lines starting with #)
- Empty lines
- check instructions
- settings (NAME=VALUE)
- comments (lines starting with #)
- empty lines
> For dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
> For Dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check Instructions
### Check instructions
The format of a check instruction is a path or relative URL, optionally followed by the expected content:
@@ -156,9 +156,9 @@ https://admin.dokku.me Admin Dashboard
https://static.dokku.me/logo.png
```
While a full url may be used in order to invoke checks, if you are using relative urls, the port *must* be omitted.
While a full URL may be used in order to invoke checks, if you are using relative URLs, the port *must* be omitted.
### Check Settings
### Check settings
The default behavior is to wait for `5` seconds before running the checks, to timeout the checks after `30` seconds, and to attempt the checks `5` times. If the checks fail `5` times, the deployment is considered failed and the old container will continue serving traffic.
@@ -172,7 +172,7 @@ ATTEMPTS=10 # Attempt checks 10 times
/ My Amazing App
```
## Manually Invoking Checks
## Manually invoking checks
Checks can also be manually invoked via the `checks:run` command. This can be used to check the status of an application via cron to provide integration with external healthchecking software.
@@ -220,7 +220,7 @@ dokku checks:run node-js-app worker
-----> Default container check successful!
```
An app process id may also be specified:
An app process ID may also be specified:
```shell
dokku checks:run node-js-app web.2
@@ -247,7 +247,7 @@ dokku checks:run node-js-app non-existent
Invalid process type specified (APP.non-existent)
```
Non-existent process ids will *also* result in an error
Non-existent process IDs will *also* result in an error
```shell
dokku checks:run node-js-app web.3
@@ -258,11 +258,11 @@ dokku checks:run node-js-app web.3
Invalid container id specified (APP.web.3)
```
## Example: Successful Rails Deployment
## Example: Successful Rails deployment
In this example, a Rails application 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. `WAIT` is set to `10` because our application takes a while to boot up. `ATTEMPTS` is set to `6`, but the third attempt succeeds.
In this example, a Rails application 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. `WAIT` is set to `10` because our application takes a while to boot up. `ATTEMPTS` is set to `6`, but the third attempt succeeds.
### CHECKS file
### `CHECKS` file
```
WAIT=10
@@ -276,9 +276,9 @@ For this check to work, we've added a line to `config/routes.rb` that simply ret
get '/check.txt', to: proc {[200, {}, ['simple_check']]}
```
### Deploy Output
### Deploy output
> Note: The output has been trimmed for brevity
> Note: The output has been trimmed for brevity.
```shell
git push dokku master
@@ -334,13 +334,13 @@ curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
http://myapp.dokku.me
```
## 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.
In this example, a Rails application fails to deploy. The reason for the failure is that the PostgreSQL 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 PostgreSQL database connection failure.
Once the attempts have been exceeded, the deployment fails and we see the container output, which shows the Postgres connection errors.
Once the attempts have been exceeded, the deployment fails and we see the container output, which shows the PostgreSQL connection errors.
### CHECKS file
### `CHECKS` file
```
WAIT=10
@@ -348,11 +348,11 @@ ATTEMPTS=6
/
```
> The check to the root url '/' would normally access the database.
> The check to the root url `/` would normally access the database.
### Deploy Output
### Deploy output
> Note: The output has been trimmed for brevity
> Note: The output has been trimmed for brevity.
```shell
git push dokku master