From 2475b9e7ea4363190addcca0360980879925a6a6 Mon Sep 17 00:00:00 2001 From: Luke Murphy Date: Sat, 3 Feb 2018 16:49:51 +0100 Subject: [PATCH 1/2] Add note for runtime host configuration for checks. Please see https://github.com/dokku/dokku/issues/2159 for motivation. [ci skip] --- docs/deployment/zero-downtime-deploys.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/deployment/zero-downtime-deploys.md b/docs/deployment/zero-downtime-deploys.md index 69c05730b..7da630130 100644 --- a/docs/deployment/zero-downtime-deploys.md +++ b/docs/deployment/zero-downtime-deploys.md @@ -250,6 +250,22 @@ dokku checks:run node-js-app web.3 Invalid container id specified (APP.web.3) ``` +## `CHECKS` and your Application + +Some applications, for example, Django, make a point of mandating that the host +header of the incoming request is defined in the configuration. This is for +security purposes. This can result in errors when checks are being performed. +Dokku cannot make decisions here because it is the responsibility of the +application to configure this. + +One potential solution is to dynamically configure your hosts at run-time. In +the case of Django, this might look like: + +``` +from socket import gethostname, gethostbyname +ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ] +``` + ## 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. From d8878fdfe237c3bcc08676311713b00229c79587 Mon Sep 17 00:00:00 2001 From: Jose Diaz-Gonzalez Date: Tue, 13 Feb 2018 02:38:57 -0500 Subject: [PATCH 2/2] docs: remove reference to django application and make it a warning This further clarifies the responsibility of the developer around managing checks in relation to their framework. --- docs/deployment/zero-downtime-deploys.md | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/docs/deployment/zero-downtime-deploys.md b/docs/deployment/zero-downtime-deploys.md index 7da630130..41d9d6833 100644 --- a/docs/deployment/zero-downtime-deploys.md +++ b/docs/deployment/zero-downtime-deploys.md @@ -15,6 +15,14 @@ By default, Dokku will wait `10` seconds after starting each container before as 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. +> Web checks are performed via `curl` on Dokku host. Some application code - such +> 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 + ## Configuring Check Settings using the `config` plugin There are certain settings that can be configured via environment variables: @@ -250,22 +258,6 @@ dokku checks:run node-js-app web.3 Invalid container id specified (APP.web.3) ``` -## `CHECKS` and your Application - -Some applications, for example, Django, make a point of mandating that the host -header of the incoming request is defined in the configuration. This is for -security purposes. This can result in errors when checks are being performed. -Dokku cannot make decisions here because it is the responsibility of the -application to configure this. - -One potential solution is to dynamically configure your hosts at run-time. In -the case of Django, this might look like: - -``` -from socket import gethostname, gethostbyname -ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ] -``` - ## 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.