Fixes the following warning:
```
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 6 package 'dokku':
`Depends' field, reference to `lxc-docker':
`>' is obsolete, use `>=' or `>>' instead
```
Refs #1776
The python version should allow us to remove any ruby dependencies and should also slightly speed up dokku installation. All LSB-compliant distributions should have python, so we should be okay depending upon it.
Closes#1783Closes#1786
It's not possible to checkout a specific commit into a new repository
using ``git fetch`` and so a temporary tag is added to the host
repository, then fetched.
This adds a hook that will send in the $APP, action name and config vars.
By adding this, we allow plugin creators to handle this kind of events as well.
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
The version of docker.io in jessie-backports is 1.6.2~dfsg1-1~bpo8+1.
This is regarded as lower than 1.6.2 by dpkg because `~` has a special meaning
in regards to version sort in dpkg.
This leads to:
```
The following packages have unmet dependencies:
dokku : Depends: docker-engine-cs but it is not installable or
docker-engine but it is not installable or
lxc-docker (>= 1.6.2) but it is not installable or
docker.io (>= 1.6.2) but 1.6.2~dfsg1-1~bpo8+1 is to be installed
Recommends: herokuish but it is not going to be installed
```
By changing the contraints the version in backports will be accepted by dpkg.
Add this point you only get information that "something" happend on the given
hook. By adding more information to the hook, plugin creators can do more
interesting stuff.
* The first params remains the $APP name (to maintain backwards compatability)
* The second params sends in the action that happend, for domain this can be:
"add", "clear" or "remove"
* The third param sends in the argument that was passed to the original
function, for domain that would be a list of all the domains that was given.
One reason this addition would be great for plugin owners, is that when you have
a web tool over Dokku, and someone creates a domain over the CLI, we a plugin
can send back information about the event to the webapp over an API. That way
the webapp is always up-to-date with the Dokku installation.
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
In order to be one step closer to lintian compliance, lets remove the shebang
from this file so it doesn;t have to be executable
See #1641
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
Changing the herokuish package to Recommends instead of Depends allows users to skip the installation of that package by specifying --no-install-recommends. Herokuish will still be installed by default using apt-get
Adds unit test for new apps:rename function.
Add example in the docs for new apps:rename function.
Add apps:rename command to help command.
Delete cache directory before copying old app directory to new app directory.
deploy_app instead of create_app for apps:rename testing.
Change app url to match new name. Fix unit tests.
Add some more tests, plugn triggers.
As of 15.10, we are graced with a relatively recent version of nginx, and thus no longer need access to the ppa. Assuming this is the only such issue, this should also allow us to support Ubuntu 16.04 without any future changes.
I have created a plugin for installing a specific library that is not working properly when installed using dokku-apt.
It took me a lot of time to figure out how to properly install it and therefore I wanted to share it.
- Add note to avoid problems with shared volumes permissions
- Restructure the doc to help comprehension
- Make command examples consistent
- Improve wording in some places
- Advanced usage: remove "avoid if possible". It made little sense.
- docker (project) --> Docker
- dokku (project) --> Dokku
- dokku (command) --> `dokku`
- add `shell` to code blocks
This should consolidate a lot of knowledge around how dokku deals with buildpacks, as well as clears up a few misconceptions - mainly that dokku doesn't support multiple/custom buildpacks.
By bringing this information front-and-center, we can avoid a lot of questions by users trying to use dokku.
[ci skip]
This plugin trigger should allow users to pair down the available commands for a given user. While this does not affect help output - or any output at all - this is a good first step in allowing administrative access to certain commands while still allowing users to deploy/manage given applications.
Note that because of how dokku works, all parsing of commands must be done within the pluginhook, and we cannot give visibility into the actual command or application that will be affected by a given run.
* Bump `Version` field.
* Set minimum nginx version to 1.4.6, per #1654
* Depend on both `rubygem-foo` (Ubuntu) and `ruby-foo` (Debian).
* Add distro-default `docker.io (>= 1.6.2)` as an alternative.
Version 1.6.2 is in both `trusty-updates` and `jessie-backports`,
while `trusty` itself has `0.9.1`. We seriously want to avoid that.
This also updates the docs so people don't forget to bump the version
field in the future. Even though we really do that for them with sed.
In this case, Bats sets $status, $output, and $lines, but ShellCheck
doesn't statically know that. Therefore, we ignore SC2154 when those
variables are first introduced in ./tests/unit/test_helper.bash
https://github.com/koalaman/shellcheck/wiki/SC2154
New version of the logs plugin broke compatibility (as reported in #1534).
So options have been added to handle display:
* -t/--tail to tail logs (already existed)
* -n/--num NUM to display only this number of lines
* -p/--ps PS to display logs only from provided process
* -q/--quiet to display raw logs without color, time and names
This should close#1534
Which is quite useful in some situations, for example when you want each app to point to a DB with the same name as the app (reducing the amount of app-specific config).
I've not yet tested with 0.4.x but asap we upgrade our environment I'll ensure it's compatible (should be super simple since it's a super simple plugin).
This ensures that we can call apt-get update after adding a new apt source. Debian needs a bit more time to refresh it's own caches, so we just force it's cache to be clean before calling apt-get update again.
This package is the version we use for as a dokku dependency, and thus there is no need to specify a *specific* version when building the deb packages.
Refs #976
Blockquote elements that call out a new feature are given a "pink" background, whereas all others are given a "blue" background. This is to help avoid cases where users expect a feature to work for their version when they are several versions behind when a feature was introduced.
Fixes#1495
Log user name and fingerprint in events
Clarify bootstrap installation documentation
We actually have the reverse situation where the bootstrap.sh uses the web installer by default.
[ci skip]
dokku-apt compatibility
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Fix for issue #1487:
Created a separated VM environments for developers and users.
Adjusting space
Clarify bootstrap installation documentation
We actually have the reverse situation where the bootstrap.sh uses the web installer by default.
[ci skip]
dokku-apt compatibility
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Making dokku the default
Adjusting space
Because of how plugin commands are implemented, their output can be incredibly verbose. Rather than executing even the `set -eo pipefail` parts of a plugin, we immediately check if the command is implemented by a plugin. If it is not, then we continue on as normal.
One side-effect of this change is that plugin commands need to be duplicated again:
- once in the command array
- once for the actual body of the command
- once in the help output
This is also quite hackish, and probably not the best way to decrease trace output. Note that we drop approximately 2k lines worth of logs with this change.
This reduces deploy output by moving `config:get` calls out of the main loop. Since the values are the same for each iteration, it does not make sense to re-retrieve them each time.
Previously a crashed container would stay down, regardless of exit status. In some cases, it may be useful to restart the container. For example, an application may not be correctly implementing their error handling, or the crash may be caused by a transient error.
By setting the restart policy to `on-failure:N` - where N is a number of max restarts - we can help developers guard against crashing applications. Note that this is not a replacement for proper error handling, nor does this include notifications to a developer when a container is restarted. Those patterns should be implemented application side, or via a feature request to docker.
The value is configurable at the app-level by setting DOKKU_RESTART_LIMIT to a number. By default, containers will be restarted a max of 10 times. If a container crashes during the check-deploy plugin trigger, then the deploy will be marked as a failure.
Closes#216Closes#398Closes#1327
This will allow developers to run an `upgrade` on existing installations without breaking because docker-engine isn't yet in their apt lists...
[ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred.
Better that we solve a problem problem than with a hack that we'll need to roll back in the future.
Refs #1220
[ci skip]
We had an issue with third party plugins installing things via apt while
already installing dokku itself via apt.
To resolve this, `plugins-install` and `plugins-install-dependencies`
now can take a `--core` flag allowing to execute the install hook only
on core plugins and not on third party plugins.
Another feature with this modification is the ability to disable/enable
plugins. Two new commands now exist:
* `plugins:enable <name>` to enable a previously disabled plugin
* `plugins:disable <name>` to disable an installed plugin. This won’t
work on core plugins.
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred.
Better that we solve a problem problem than with a hack that we'll need to roll back in the future.
Refs #1220
[ci skip]
This can be used as an alternative to importing via stdin, which may be preferred when working directly on a server, or via scripted installation/deployments.
This should theoretically be safe, as "--export" forces the `dokku config` command to return 0 in all cases, and it should only output lines that are "valid" environment variables
This function - `is_container_status` - can be used to inspect whether a container is any of the following:
- Dead
- OOMKilled
- Paused
- Restarting
- Running
It can be useful for deeper inspection as to plugin state
As briefly discussed in #1425, source the `common/functions` file via an
absolute path, rather than determining the relative path by using
`dirname`. 3rd-party plugins should follow suit and use the new
`$PLUGIN_PATH` convention too.
This will allow users to inspect the underlying environment and conditionally run different commands based upon the `DYNO_TYPE_NUMBER`. The values will be set in the following format:
web.1
web.2
worker.1
worker.2
clock.1
Users of process managing plugins and dockerfiles can check the `DYNO_TYPE_NUMBER` and set a specific command to run.
Closes#1350
This command can be used to enter a running container. The following variations of the command exist:
dokku enter api web
dokku enter api web.1
dokku enter api --container-id ID
By default, it runs a `/bin/bash`, but can also be used to run a custom command:
# just echo hi
dokku enter api web echo hi
# run a long-running command, as one might for a cron task
dokku enter api web python script/background-worker.py
Closes#1332
You can now use the following to narrow down the search for a container id:
get_app_container_ids app web
get_app_container_ids app worker
You can also specify a specific type "id" like so:
get_app_container_ids app web.1
get_app_container_ids app worker.3
Specifying an invalid type or id will result in an empty response
This should allow installation of the dokku packages on debian jessie. Upstream docker created this package in response to an issue where `cgroup-bin` could not be installed at the same time as lxc.
Closes#1236
Refs #1076
[ci skip]
This reverts commit 1bf30bdcb1.
Commit was reverted as this breaks installs of core plugins. It is also a hack around broken plugins that don't use the `dependencies` pluginhook.
All core plugins that require debian packages already have those packages specified in the `depends` stanza of the `control` file, so no need to respecify them here.
`bootstrap.sh` fails to acknowledge the `DEBIAN_FRONTEND=noninteractive` envvar because of the use of `sudo`, because the -E flag is not set. However, the script also assumes that it will be run with `sudo` in the first place, so it shouldn't be needed. In the event that it is needed, it can be run with -E instead.
Setting `DOKKU_SKIP_ALL_CHECKS` globally or for a given app will skip
all checks.
Setting `DOKKU_SKIP_DEFAULT_CHECKS` globally or for a given app will skip
default checks only.
Record events (i.e. pluginhook's calls) as syslog entries and
provide a shortcut command to display the last part of the log
file.
A brief summary of the changes follows:
dokku:
- New DOKKU_EVENTS_LOGFILE envvar to hold logfile location.
plugins/20_events/commands:
- events output log entries, a tail's follow-like mode is
provided too.
- events:[on|off] enables/disables logging.
- events:list lists events that are logged.
plugins/20_events/hook:
- Generic hook that writes log entries. All the events are
registered via symlink to this script.
plugins/common/functions:
- dokku_log_event() writes log entries via logger.
- dokku_log_pluginhook_call() formats log entries and writes
them via dokku_log_event().
Since `docker build` is only invoked when actually building a new image
from a Dockerfile, using `--no-cache` allows to have an updated image
even if the Dockerfile hasn't changed.
This works well with Dockerfiles using `git` or packages referencing
latest versions instead of "static" ones.
My changes may not be quite correct, but as far as I can tell, DOCKER_OPTIONS now requires specifying a phase explicitly.
Also updated references to `--link` since `-link` has been deprecated in Docker.
When we will use `kill` command on `docker` main process will receive
`SIGKILL` signal. This will result in immediate termination of
processes. We need to send a signal `SIGTERM` to main process and give
the opportunity to close application in correct way.
Piping the output of `curl` or `wget -O-` to a shell is a very bad idea for multiple reasons; security concerns aside, doing so provides no opportunity for the script's download to finish before execution starts, so if the download is interrupted for some reason (perhaps because of an intermittent network failure), the incompletely-downloaded script will still run with potentially disastrous results. See [here](http://www.seancassidy.me/dont-pipe-to-your-shell.html) for a more in-depth description.
ATTEMPTS=0 means don't run the checks. Useful if you want to skip the checks and can be overridden by DOKKU_CHECKS_ATTEMPTS
ATTEMPTS=1 means run only once
Previously this script was matching for a remote named 'dokku' even
when DOKKU_HOST is provided and completely custom. I have a case where
I have 2 remotes with dokku, one on a staging server and another on a
production server.
So by matching for 'dokku@$DOKKU_HOST' instead, the script can determine
correctly which remote to use.
http://xip.io
xip.io is a service by Basecamp that provides a wildcard DNS service on the public internet. Any <ip address>.xip.io will return a DNS response for the IP address, same with <subdomain>.<ip address>.xip.io.
The domains plugin in dokku uses a regex to match IP4 and IP6 addresses in the VHOST file, and disables VHOST support if found. This PR changes those patterns to require that the VHOST entry **ends with** the IP address.
This is a gist where my VHOST setting is "127.0.0.1.xip.io" that demonstrates the original output, linked directly to the line from `plugins/domains/commands`: https://gist.github.com/anonymous/c529177f20b36beda80d#file-debug-log-L1373
- Specify how long to wait before running first check
- Specify timeout for each check
- Check specific hosts, e.g. http://signin.example.com
- Check both HTTP and HTTPS resources
As per RFC 2818 [0], a CN of *.dokku.me will only match direct
subdomains of dokku.me, not sub-subdomains like www.test.dokku.me, but
Dokku currently enables TLS for subdomains of all levels.
I have changed the regex from .*\.dokku\.me to [^.]*\.dokku\.me so TLS
is only enabled for direct subdomains.
[0] - http://tools.ietf.org/html/rfc2818#section-3.1
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Previously, the presence of TLS certificates would cause `dokku urls` to
output all https URLs, even for domains which were not configured to use
TLS.
This change introduces a URLS file in the app's directory which contains
the URLs with schemes based on whether they have been configured to use
TLS in the nginx config.
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Previous to this change, each TLS domain would be written to nginx.conf
using the nginx.ssl.conf template (lines 69-73) but with an empty
"server_name" directive (because NOSSL_SERVER_NAME was not set).
This would then become irrelevant because nginx.conf would get truncated
on line 88, and a single parsing of the template would then be written to
nginx.conf on line 89, meaning only the last TLS domain would be set up to
actually use TLS.
This patch changes this behaviour so that all TLS domains get added to
nginx.conf using the nginx.ssl.conf template (which includes redirecting
HTTP -> HTTPS), and all non-TLS domains get added using the nginx.conf
template, so do not get redirected to a TLS domain.
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Placing `COPY` (or `ADD`) of the application directory after the `RUN apt-get install ...` statements will allow the layers created from those statements to be retrieved from docker's cache on subsequent runs.
During an upgrade, the output of `git describe --tags` is written to the VERSION file, so we need to pull the tags otherwise it looks like we're running an old version.
herokuish defaults to /tmp/cache, so the build cache don't work without giving the CACHE_PATH environment variable. You can test it with buildstep herokuish branch. cc @progrium
- don't match substrings in VHOSTS
- handle case where NOSSL_SERVER_NAME is \' \'
- rebuild nginx config on ssl import
- prevent cwd errors after we rm the temp dir
This allows us to configure dokku env-vars individually. Such a feature is useful if a developer would like to enable or disable DOKKU_TRACE without parsing a dokkurc file.
The URL file is being rewritten on every deploy by `dokku deploy` and thus that file was incorrect. Instead, we just reuse the old logic from the nginx-vhosts plugin to handle creation of the VHOST file
This helps remove duplication and also ensures that all hosts have a proper setup after running `make copyfiles`
Note that this command is not exposed in help as it is not generally useful to developers
Adding a hostname to the $APP/VHOST file will enable it as a virtualhost for the application.
In addition, any hostname set that matches an associated ssl certificate will also be set as an ssl host. Note that if a hostname does not have a matching SSL host, then it will result in an erroring application.
For the moment, running `dokku url` on an app may not correctly display the current hostnames for said app.
This fixes a bug introduced when deploying apps where the
nginx-vhosts plugin runs ``dokku config:get $APP NO_VHOST``. The initial
run of this actually was creating the ``ENV`` file and dumping to
stdout the value "NO_VHOST=-----> Creating /home/dokku/foo/ENV". This
was obviously no good because nginx-vhosts was considering this to be a
value of true.
I've modified this to simply not return anything when the value does not
exist. A better update may be to output the messages to stderr instead
of stdout.
- Uses ENV and APP/ENV files
- Supports old BUILD_ENV files (which are likely in wide-use)
- Allows user's to override globals with app-specific configuration
Closes#284Closes#683Closes#763
Refs #503
Refs #678
To be able to switch the plugin path i have removed the hard coded
plugin path from the catch all section of the switch within the main
dokku executable.
To be able to set some other environment variables even if dokku gets
called from a different user we have to keep the environment with sudo
intact, so i added the -E option.
Plugins with commands will need to implement a catch-all command that exits with the `DOKKU_NOT_IMPLEMENTED_EXIT`` code (10). This signals to dokku that a given plugin has indeed not executed anything for a plugin (which may not always be the case).
Using plugins that do not implement this pattern will result in those plugins silencing the error message.
I have done the first steps to get dokku running for other distros like
openSUSE. I have simply replaced the important places within the core
plugins with a check for DOKKU_DISTRO that gets exported by dokku
itself. It just replaces the apt-get and service start/restart/reload
functionality with the openSUSE counterparts.
In order to be able to use a different base image i have added another
environment variable where everybody can switch the used base container
for the applications directly through the environment variable
DOKKU_IMAGE or with the help of the dokkurc configuration.
This creates the following commands:
- apps
- apps:create <app>
- apps:destroy <app>
It also:
- makes `delete` an alias for `apps:destroy`
- adds confirmation to `apps:destroy`
- allows a developer to remove apps that have been created via apps:create but have not been deployed
Refs #87
Refs #543
Refs #586Closes#599
Refs #655
Refs #656
Refs #685Closes#757
Since curl is running quietly it may give the impression that the installation hanged with the last message on the terminal being: "sleep 2 # give docker a moment i guess". In my case I thought it gave it a huge moment and not 2 seconds. It wasn't until the third time that I actually checked the processes on the machine and saw there it was curl downloading stuff quietly.
Avoids
```
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
```
that can occur on certain Vagrant images. Since we need readonly anyway, might as well use HTTPS instead of SSH.
This is adapted from the one I use in my shell profile scripts. This
kinda-sorta-maybe acts like the `heroku` or `deis` commands and does
some clever reorganization of data before sending it to the server.
To use the app name generator, install the `elfs` rock from Moonrocks.
This change makes Dokku start up the new container, run a set of checks
against it, and only switch traffic over to the new containers if all
checks complete successfully. No requests are dropped during the switch
over.
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
Even if you don’t use any checks, this change will prevent downtime
during switching from old to new container.
See: https://labnotes.org/zero-downtime-deploy-with-dokku/
After reading the source code for hints on how to deploy wildcard ssls I found it was already supported.
The proposed change should make this feature easier to find.
There was a bug in the setup page where valid domains that start with a number
would be captured by the validation check designed to detect IP
addresses. This check detects IPs by comparing the host name to a regex,
instead of simply detecting whether the first character is a number.
When an app directory (i.e. `/home/dokku/myapp`) is created before the
app is pushed for the first time (which may occur if config files such
as `ENV` are added before the initial push), then the app directory will
not be initialized to a bare git repo nor will the pre-receive hook be
installed because `plugins/git/commands` assumes that if `$APP_PATH`
exists, then the directory must also be git initialized too. This fix
checks for `$APP_PATH/refs` instead.
As discussed in #313, dokku base commands such as build, release, and
deploy require specifying both `$APP` and `$IMAGE` as arguments where
`IMAGE="app/$APP"`. Thus, the `$IMAGE` parameter is currently redudant.
This patch removes the need to specify `$IMAGE` for these base commands
and is backwards compatible. If, in the future, the base commands expect
and `$IMAGE` different than `app/$APP`, then the `$IMAGE` parameter will
be re-added for those specific commands.
Starting apps on daemon start has been handed by the upstart 'dokku-redeploy' script for a while. (Also, the format of /etc/init/docker.conf changed and rendered the sed useless.)
Fixes#322.
Buildpacks write into /cache as root, which made the delete command unable
to delete it.
Its contents are now deleted using "docker run", and thus as root.
2013-11-20 20:42:15 +00:00
350 changed files with 13740 additions and 874 deletions
If upgrading to 0.4.8, please note that we have tightened the application naming schema, per docker requirements. Upgrade your dokku installation to 0.4.7 first to take advantage of the `dokku apps:rename` command if you are having issues with the new requirement.
### Bug Fixes
-#1804:@josegonzalez Fix deprecated version constraint usage in debian control file
-#1798:@michaelshobbs Ensure app name begins with lowercase alphanumeric character
-#1808:@josegonzalez Fix path to dokku-installer
### New Features
-#1801:@josegonzalez Allow setting DOKKU_LIB_ROOT env var to modify the lib path on install
-#1803:@michaelshobbs update plugn download url and version
### Documentation
-#1809:@josegonzalez Remove non-zero downtime version of letsencrypt plugin
## 0.4.7
A few notable new features:
- The new `dokku apps:rename` command. It does not update linked containers, but is useful in many other cases.
- Updated git clone methodology to be more performant for large repositories.
- Moved the dokku-installer from Ruby to Python, allowing us to drop Ruby as a dependency. Python comes with the linux standard base, and should therefore be accessible on more systems.
### Bug Fixes
-#1776:@t-8ch Fix docker version constraints on jessie systems
-#1777:@michaelshobbs Format test labels
-#1782:@michaelshobbs make docker cp work on circleci
-#1788:@michaelshobbs Updates for moving of dokku sshcommand and plugn repos
-#1791:@michaelshobbs Don't run app deploy tests and spread out unit tests to 4 containers
-#1793:@michaelshobbs Filter out Procfile comments
### New Features
-#1670:@zachfeldman Add apps:rename
-#1771:@jvanbaarsen Make plugin hooks send out more information
-#1778:@mmerickel Optimize git clone for large repositories
-#1781:@jvanbaarsen Add post config update hook
-#1789:@lvillani Make it possible to skip a deploy
-#1790:@michaelshobbs Use pgup/pgdown for history shortcut in dev env
-#1794:@josegonzalez Replace dokku-installer.rb with dokku-installer.py
-#1797:@michaelshobbs Ensure we run plugin commands as root
-#1799:@josegonzalez Add support for tutum-agent as docker alternative
-#1800:@josegonzalez Respect DOKKU_ROOT in debian/postint
### Documentation
-#1779:@sseemayer Add link to new zero-downtime Let's Encrypt Plugin to docs
-#1780:@jvanbaarsen Add documentation for the new domain plugin hooks
-#1784:@duboff Tiny fix in SSL documentation
## 0.4.6
This is mostly a documentation change. A few notable changes:
- Rebooting dokku servers should properly handle not starting stopped services.
- Better support for newer versions of Debian/Ubuntu.
- Moved the dokku project to the dokku github organization.
Thanks to all the contributors who helped with this release!
### Bug Fixes
-#1717:@josegonzalez Avoid using the PPA for ubuntu versions 15.10 and higher
-#1732:@michaelshobbs do not chown file that doesn't exist
-#1745:@beverku Change herokuish to recommended package
-#1767:@jvanbaarsen Remove shebang from config/functions
-#1775:@Flink Match complete container name in named-containers plugin
### New Features
-#1718:@josegonzalez Add post-create hook
-#1735:@michaelshobbs use ps:restore on instance boot
### Documentation
-#1720:@josegonzalez Add memory usage output as desired data for reporting issues
-#1723:@josegonzalez Add herokuish version to desired debugging info
-#1739:@michaelshobbs clarify location of nginx.conf.template in app repo
-#1747:@josegonzalez Add Lets Encrypt plugin
-#1748:@byrnedo Added unofficial Nats plugin to plugins.md
-#1750:@jlachowski New graphite & statsd plugin with grafana frontend added
-#1751:@josegonzalez Use flat-square style on image badges
-#1752:@byrnedo Moved dokku-nats into official plugins section
-#1753:@hhff Add .ca-bundle information to SSL docs
-#1754:@josegonzalez Update all links to dokku repo
-#1757:@josegonzalez Add DigitalOcean as a sponsor
-#1761:@josegonzalez Fix link to docker-options documentation
## 0.4.5
This release is mostly a bugfix release. Two notable changes:
- It is now possible to build complex authentication layers around dokku using the new user auth plugin trigger introduced in #1671.
- We have a Code of Conduct in our repository. Please refer to this document if you have any questiosn regarding what is acceptable in the Dokku community.
Thanks to all the contributors who helped with this release!
### Bug Fixes
-#1666:@michaelshobbs Revert dokku group changes and add dokku user to adm group
-#1667:@u2mejc Fix dokku certs:add file input bug
-#1682:@michaelshobbs Aet nullglob when looking for PORT files
-#1684:@u2mejc Cause certs:remove to return non zero on error
-#1690:@u2mejc Fix "App tls has not been deployed" error
-#1696:@michaelshobbs chown plugins paths to dokku:dokku
-#1698:@pmvieira Ensure curl is installed inside of source-based installations
-#1700:@michaelshobbs copy nginx.ssl.template from app container
-#1677:@ignlg Added dokku-builders-plugin to plugins page
-#1681:@josegonzalez Fix email in code of conduct
-#1694:@MarcDiethelm Improve docker-options doc
-#1713:@mbriskar Wkhtmltopdf plugin
## 0.4.4
This release adds a few interesting changes:
- The `dokku logs` command now roughly maps to the `heroku logs` command, and supports most available options.
- Native Microsoft Azure support is now available!
- Quite a few shellcheck issues were fixed thanks to @callahad!
- Experimental debian installation support. Going forward, we will try and make dokku compatible with all systemd installations, as well as investigate dockerfile-based deployment to continue simplifying installation.
Thanks to all our contributors for making this release great!
### Bug Fixes
-#1606:@josegonzalez Install plugn 0.2.0 in Makefile installs
-#1643:@Flink Fix generated nginx config when NO_VHOST=1
-#1644:@mmerickel Watch dokku events through a logrotate
-#1647:@callahad Resolve SC2115: 'Use "${var:?}" to ensure this never expands to /'
-#1648:@callahad Resolve SC2154: 'variable is referenced but not assigned'
-#1649:@callahad Resolve SC2164: 'Use cd ... || exit in case cd fails.'
-#1650:@callahad Resolve SC2148: 'target shell is unknown'
-#1651:@callahad Resolve SC2029: 'this expands on client side'
-#1652:@callahad Resolve SC2143: 'Instead of [ -n $(foo | grep bar) ], use foo | grep -q bar'
-#1653:@callahad Resolve SC2145: 'Argument mixes string and array.'
-#1655:@callahad Resolve SC2162: 'read without -r mangles backslashes'
-#1656:@callahad Resolve SC2001: 'See if you can use ${var//search/replace} instead'
-#1660:@callahad Fixup debian/control for Debian
-#1662:@xadh00m Only return users of group 'adm'
### New Features
-#1607:@josegonzalez Dokku support for Debian Jessie installation
-#1610:@kdomanski Add post-stop plugn trigger
-#1612:@Flink Add multiple options to the logs plugin
-#1613:@kdomanski Add ps:restore to start applications which weren't manually stopped
-#1628:@michaelshobbs Move RESTORE variable to DOKKU_APP namespace
-#1634:@callahad Allow installation of bats via homebrew
-#1645:@rvalyi Add ability to access git repo via ssh
-#1664:@michaelshobbs Add $REV to pre-receive-app call
### Documentation
-#1605:@josegonzalez Make commented output a bit more readable
-#1621:@josegonzalez Document `--force` option for `:destroy` commands
-#1623:@sedouard Add Azure Documentation
-#1624:@u2mejc Add trace to help output
-#1626:@josegonzalez Add official dokku-copy-files-to-image plugin
-#1630:@adamwolf Enabling tracing is actually 'dokku trace on'
-#1633:@elia Add a warning regarding the use of `trace on`
This release was mainly a documentation release/bugfix.
One major removal was is that as of 0.4.3, we no longer restart containers automatically on failure via docker. This feature was introduced in 0.4.0, and caused issues with duplicate containers being started on server reboot. Until the docker api for container restarts stabilizes, we will not be able to provide this functionality within Dokku.
If desired, you may replicate this functionality using the official `docker-options` plugin.
### Bug Fixes
-#1560:@darklow Fixes issue where SSL and non-SSL templates cannot be used at the same time
-#1566:@michaelshobbs Fix logic error in enabling nginx
-#1568:@josegonzalez Remove 'connection closed' messages from dokku ssh client
-#1574:@josegonzalez Ensure the user has a valid hostname set during installation
-#1585:@michaelshobbs Ensure dokku can read nginx logs and don't remove other perms
-#1556:@josegonzalez Use proper cdn link for css asset
-#1557:@josegonzalez Code styling changes
-#1561:@josegonzalez Set dokku-acl compatibility to 0.4.0+
-#1562:@josegonzalez Documentation Overhaul
-#1573:@mateusortiz Add link to license
-#1577:@Flink Add official redirect plugin
-#1587:@josegonzalez Update "reporting other issues" to include `docker inspect`
-#1598:@adamwolf Add missing bootstrap.sh step
-#1599:@ssd532 Fix a few grammatical mistakes
-#1601:@ojacquemart Fix typo
-#1604:@josegonzalez Add every type of favicon to all templates
## 0.4.2
This release was mainly a documentation release, with a few notable features:
- You can now use the commercial version of docker-engine with dokku.
- You can now name your containers using the official `named-containers` plugin
Huge thanks to @Flink for working on our official plugins and adding official [basic auth](https://github.com/dokku/dokku-http-auth), [couchdb](https://github.com/dokku/dokku-couchdb), and [site maintenance](https://github.com/dokku/dokku-maintenance) plugins!
### Bug Fixes
-#1530:@Flink Fix nginx configuration for SSL
### New Features
-#1515:@leonardodino Allow local prebuilt stack sourcing
-#1536#1537:@josegonzalez Add docker-engine-cs as docker-engine alternative
-#1511:@Flink Add `named-containers` as a core plugin
### Documentation
-#1520:@kimausloos Add `dokku` command-prefix to `plugin:install` command
-#1519:@3onyc Fix typos in documentation
-#1521:@edm00se Use correct url to bootstrap.sh in README.md
-#1522:@josegonzalez Avoid redirects and use raw.githubusercontent.com for github links
-#1523#1548:@callahad Make room for the longer bootstrap.sh URL
-#1524:@callahad Document idiosyncracies with Linode
-#1529:@pzula Adds helpful information regarding whitespacing when setting config
-#1525#1550:@josegonzalez Add gratipay shield to readme
-#1544#1545#1547#1551:@josegonzalez@Flink Update compatibility for community plugins
-#1546:@josegonzalez Add missing description to history output in HISTORY.md
-#1552#1553#1555:@josegonzalez Various documentation styling tweaks
## 0.4.1
This release is primarily a bugfix and documentation update. In 0.4.0, we incorrectly handled setting environment variables in certain cases, resulting in misconfigured applications. We recommend that all users upgrade from 0.4.1 as soon as possible.
One new feature is colorized logging output, which should make it easier to debug application logging output when deploying multiple processes.
### Bug Fixes
-#1494:@callahad Correctly install packages for DOKKU_TAG=v0.4.0
-#1496:@callahad Don't prompt users when installing dokku package
-#1514:@michaelshobbs Do not use exit 0 in config functions and fix CURL environment variable setting
### New Features
-#1482:@Flink Strip the `dokku-` part from plugins on install
-#1500:@jazzzz Log user name and fingerprint in events
-#1488:@josegonzalez Update plugins list with compatibility changes
-#1491:@josegonzalez Promote [maintenance](https://github.com/dokku/dokku-maintenance) and [http basic auth](https://github.com/dokku/dokku-http-auth) plugins to official status
-#1492:@josegonzalez Upgrade hostname plugin to 0.4.0+ compatibility
-#1504:@michaelshobbs Change plugin install doc to show one-step method
## 0.4.0
This is our first minor release in almost a year. Many new features and removals have occurred, so here is a neat summary:
- Plugins are now triggered via `plugn`. Notably, you'll need add a `plugin.toml` to describe the plugin as well as use `plugn trigger` instead of `pluginhook` to trigger plugin callbacks. Please see the [plugin creation documentation](http://dokku.viewdocs.io/dokku/development/plugin-creation/) for more details.
- A few new official plugins have been added to the core, including [image tagging](http://dokku.viewdocs.io/dokku/application-deployment/), [certificate management](http://dokku.viewdocs.io/dokku/deployment/ssl-configuration/), a tar-based deploy solution, and much more. Check out the *New Features* section for more details.
- We've removed a few deprecated plugin callbacks. Please see the [plugin triggers documentation](http://dokku.viewdocs.io/dokku/development/plugin-triggers/) to see what is available.
- [Official datastorage plugins](https://github.com/dokku) have been created for the most commonly used datastores. If you previously used/maintained a community contributed plugin, please check these out. We'll be adding more official plugins as time goes on.
Thanks to the *many* contributors for making this release our best release so far, and special thanks to both @michaelshobbs and @Flink for pushing along the `0.4.0` release!
### Deprecations and Removals
-#1372:@SonicHedgehog Do no longer force-install a default nginx.conf
-#1450:@michaelshobbs Rename event plugin buildstep hooks to buildpack
### Bug Fixes
-#1344:@AdamVig Add better error checking on nginx:import-ssl
-#1417:@josegonzalez Expose host and port in vagrant build vm
-#1418:@josegonzalez Use cgroupfs-mount as alternative package to cgroup-lite dependency
-#1419:@u2mejc Fix dokku ps <app> over ssh
-#1422:@josegonzalez Guard against missing VHOST files when listing domains
-#1428:@jimeh Use `$PLUGIN_PATH` instead of `$(dirname $0)/..`
-#1430:@lubert Update vagrant box name to `bento/ubuntu-14.04`
-#1439:@michaelshobbs Fix tar tests by sleeping for 5 seconds
-#1447:@alanjds Properly detect app name in the official cli client
-#1449:@josegonzalez Match herokuish deb with released version number
-#1457:@lukechilds Bashstyle fixes
-#1463:@josegonzalez Update `Xenify Distro` option for linode stackscript
-#1464:@josegonzalez Limit number of log lines when calling `dokku logs -t`
-#1466:@josegonzalez Follow bashstyle conventions where possible
-#1471:@michaelshobbs Make the default scaling logic clearer
-#1475:@josegonzalez Fix issue where restart on failure option overrode existing DOCKER_ARGS
### New features
-#1225:@michaelshobbs Add tags plugin to handle image tagging and deployment of tagged app images
-#1228:@michaelshobbs Use plugn instead of pluginhook to trigger plugin hooks
-#1402:@josegonzalez Consolidate configuration management into config plugin
-#1414:@michaelshobbs Add certs plugin for certificate management
-#1420:@josegonzalez Add `dokku enter` for connecting to an app container
-#1421:@basicer Add tar plugin to manage tar-based deployments
-#1423:@josegonzalez Set `DYNO_TYPE_NUMBER` environment variable for each container
-#1431:@josegonzalez Add helper function for inspecting the state of a container
-#1444:@josegonzalez Extract cleanup command into common function
-#1445:@josegonzalez Create CONTRIBUTING.md
-#1455:@michaelshobbs Continue and log an event if/when container retirement fails
-#1458:@michaelshobbs Set Herokuish `TRACE=true` when `DOKKU_TRACE` is set
-#1460:@michaelshobbs Bump herokuish version to 0.3.3
-#1465:@josegonzalez Set DYNO environment variable to heroku-compatible value
-#1467:@josegonzalez Upgrade dokku installation to use docker-engine
-#1468:@michaelshobbs Clean up semver logic and run install-dependencies after package installation
-#1469:@isundaylee Add nginx:access-logs and nginx:error-logs commands
-#1470:@assaf Add nginx configuration for running behind load balancer
-#1472:@michaelshobbs Use processes defined in `Procfile` when generating `DOKKU_SCALE` file
-#1473:@josegonzalez Handle crashing containers by using restart=on-failure policy
-#1476:@michaelshobbs Support static nginx port when deploying without an application VHOST
-#1476: nginx proxy without VHOST
-#1477:@arthurschreiber Support removing config variables that contain `\n`.
### Documentation
-#1407:@ertrzyiks Correct DOKKU_DOCKERFILE_PORT variable name in docs
-#1408:@josegonzalez Add links to official dokku datastorage plugins
-#1426:@henrik Update memcached link to maintained fork
-#1437:@Flink Update compatibility version for several plugins
-#1446:@johnfraney Correct nginx documentation
-#1478:@eljojo Fix naming of herokuish package in installation docs
## 0.3.26
This release has a few new features, the largest of which is switching from buildstep to herokuish for building containers. Going forward, this should help ensure that built containers are as close to heroku containers as possible, and also allow us to be on the cutting edge of heroku buildpack support. Props to @michaelshobbs for his work on herokuish.
### Bug Fixes
-#1401:@josegonzalez Install apt-transport-https before adding https-backed apt sources
### New Features
-#1128:@michaelshobbs Switch from buildstep to herokuish
-#1399:@basicer Make dokku play nice when there are multiple receive-app hooks
-#1413:@michaelshobbs support comments in DOKKU_SCALE and print contents on deploy
### Documentation
-#1400:@josegonzalez Fix HISTORY.md formatting
-#1410:@josegonzalez Clarify DOKKU_SCALE usage
-#1411:@josegonzalez Clarify `ps:scale` example
## 0.3.25
This release is a bugfix release fixing a broken 0.3.25 apt-get installation.
### Bug Fixes
-#1398@josegonzalez Revert "Remove `dokku plugins-install` from postinst hook
## 0.3.24
This release is a bugfix release covering dokku packaging.
### Bug Fixes
-#1397:@josegonzalez Use https docker apt repo
-#1394:@josegonzalez Remove `dokku plugins-install` from postinst hook
### Documentation
-#1395:@adrianmoya Adding fqdn requirement
## 0.3.23
This release is a bugfix release mostly covering installation and nginx issues. As well, we launched a nicer documentation site [here](http://dokku.viewdocs.io/dokku/). Thanks to all of our contributors for making this a great release!
### Bug Fixes
-#1334:@josegonzalez Fix pluginhook building and update package version
-#1335:@josegonzalez Fix name for michaelshobbs
-#1341:@michaelshobbs Honor $DOKKU_DOCKERFILE_PORT when binding the docker container to an external IP.
-#1357:@michaelshobbs only run domains and nginx config if we have a port and ip
-#1366:@omeid Make bootstrap.sh safe from bad connection
-#1370:@SamuelMarks Switch from /dev/null to -qq, from --silent to -sL, and sudo
-#1380:@emdantrim Removed uses of `sudo` from `bootstrap.sh`
-#1383:@michaelshobbs fix downscaling from 10+
### New Features
-#1292:@michaelshobbs use column to format help output
-#1337:@josegonzalez Update PREBUILT_STACK_URL to latest buildstep release
-#1354:@alessio Log receive-branch pluginhook
-#1359:@michaelshobbs allow DOKKU_WAIT_TO_RETIRE to be defined per app
-#1365:@michaelshobbs support dockerfile images that don't include bash
### Documentation
-#1305:@josegonzalez Updated documentation site
-#1321:@fwolfst Mention alternative to nginx.conf templates: include-dir.
-#1346:@michaelshobbs document dokku cleanup and the potential of compat issues
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Docker powered mini-Heroku. The smallest PaaS implementation you've ever seen. Sponsored by our friends at [Deis](http://deis.io/).
## Requirements
Assumes Ubuntu 13 x64 right now. Ideally have a domain ready to point to your host. It's designed for and is probably
best to use a fresh VM. The bootstrapper will install everything it needs.
**Note: There are known issues with docker and Ubuntu 13.10 ([1](https://github.com/dotcloud/docker/issues/1300), [2](https://github.com/dotcloud/docker/issues/1906)) - use of 13.04 is recommended until these issues are resolved.**
You may also wish to take a look at the [advanced installation](http://progrium.viewdocs.io/dokku/advanced-installation) document for aditional installation options.
### Upgrading
## Configuring
[View the docs for upgrading](http://dokku.viewdocs.io/dokku/upgrading) from an older version of Dokku.
Set up a domain and a wildcard domain pointing to that host. Make sure `/home/dokku/VHOST` is set to this domain. By default it's set to whatever the hostname the host has. This file only created if the hostname can be resolved by dig (`dig +short $HOSTNAME`). Otherwise you have to create the file manually and set it to your prefered domain. If this file still not present when you push your app, dokku will publish the app with a port number (i.e. `http://example.com:49154` - note the missing subdomain).
## Documentation
You'll have to add a public key associated with a username by doing something like this from your local machine:
Now you can deploy apps on your Dokku. Let's deploy the [Heroku Node.js sample app](https://github.com/heroku/node-js-sample). All you have to do is add a remote to name the app. It's created on-the-fly.
Right now Buildstep supports buildpacks for Node.js, Ruby, Python, [and more](https://github.com/progrium/buildstep#supported-buildpacks). It's not hard to add more, [go add more](https://github.com/progrium/buildstep#adding-buildpacks)!
Please check the documentation for your particular build pack as you may need to include configuration files (such as a Procfile) in your project root.
## Run a command in the app environment
It's possible to run commands in the environment of the deployed application:
$ dokku run node-js-app ls -alh
$ dokku run <app> <cmd>
## Plugins
Dokku itself is built out of plugins. Checkout the wiki for information about
creating your own and a list of existing plugins:
https://github.com/progrium/dokku/wiki/Plugins
## Removing a deployed app
SSH onto the server, then execute:
$ dokku delete myapp
## Environment variable management
Typically an application will require some environment variables to run properly. Environment variables may contain private data, such as passwords or API keys, so it is not recommend to store them in your application's repository.
The `config` plugin provides the following commands to manage your variables:
```
config <app> - display the config vars for an app
config:get <app> KEY - display a config value for an app
config:set <app> KEY1=VALUE1 [KEY2=VALUE2 ...] - set one or more config vars
config:unset <app> KEY1 [KEY2 ...] - unset one or more config vars
```
## SSL support
Dokku provides easy SSL support from the box. To enable SSL connection to your application, copy `.crt` and `.key` file into `/home/dokku/:app/ssl` folder (notice, file names should be `server.crt` and `server.key`, respectively). Redeployment of application will be needed to apply SSL configuration. Once it redeployed, application will be accessible by `https://` (redirection from `http://` is applied as well).
## Upgrading
Dokku is in active development. You can update the deployment step and the build step separately.
**Note**: If you are upgrading from a revision prior to [27d4bc8c3c](https://github.com/progrium/dokku/commit/27d4bc8c3c19fe580ef3e65f2f85b85101cd83e4), follow the instructions in [this wiki entry](https://github.com/progrium/dokku/wiki/Migrating-to-Dokku-0.2.0).
To update the deploy step (this is updated less frequently):
$ cd ~/dokku
$ git pull origin master
$ sudo make install
Nothing needs to be restarted. Changes will take effect on the next push / deployment.
This will build a fresh Ubuntu Quantal image, install a number of packages, and
eventually replace the Docker image for buildstep.
Full documentation - including advanced installation docs - are available online at [docs](http://dokku.viewdocs.io/dokku/)
## Support
You can use [Github Issues](https://github.com/progrium/dokku/issues), check [Troubleshooting](https://github.com/progrium/dokku/wiki/Troubleshooting) on the wiki, or join us on Freenode in #dokku
You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](http://dokku.viewdocs.io/dokku/troubleshooting) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku)
## Components
## Contribution
* [Docker](https://github.com/dotcloud/docker) - Container runtime and manager
* [pluginhook](https://github.com/progrium/pluginhook) - Shell based plugins and hooks
* [sshcommand](https://github.com/progrium/sshcommand) - Fixed commands over SSH
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](http://dokku.viewdocs.io/dokku/troubleshooting) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
Looking to keep codebase as simple and hackable as possible, so try to keep your line count down.
While we may not merge your PR as is, they serve to start conversations and improve the general dokku experience for all users.
## Things this project won't do
## Sponsors
* **Multi-host.** Not a huge leap, but this isn't the project for it. Have a look at [Flynn](https://flynn.io/).
* **Multitenancy.** It's ready for it, but again, have a look at [Flynn](https://flynn.io/).
* **Client app.** Given the constraints, running commands remotely via SSH is fine.
Dokku is currently sponsored by the enterprise grade, multi-host PaaS project [Deis](http://deis.io/).
<label><input id="vhost" name="vhost" type="checkbox" value="true"> Use <abbr title="Nginx will be run on port 80 and backend to your apps based on hostname">virtualhost naming</abbr> for apps</label>
<label><input id="vhost" name="vhost" type="checkbox" value="true"> Use <abbr title="Nginx will be run on port 80 and backend to your apps based on hostname">virtualhost naming</abbr> for apps</label>
If you plan on developing dokku, the easiest way to install from your own repository is cloning
the repository and calling the install script. Example:
If you plan on developing dokku, the easiest way to install from your own repository is cloning the repository and calling the install script. Example:
The `Makefile` allows source URLs to be overridden to include customizations from your own
repositories. The `DOCKER_URL`, `PLUGINHOOK_URL`, `SSHCOMMAND_URL` and `STACK_URL`
environment variables may be set to override the defaults (see the `Makefile` for how these
apply). Example:
The `Makefile` allows source URLs to be overridden to include customizations from your own repositories. The `DOCKER_URL`, `PLUGN_URL`, `SSHCOMMAND_URL` and `STACK_URL` environment variables may be set to override the defaults (see the `Makefile` for how these apply). Example:
$ sudo SSHCOMMAND_URL=https://raw.github.com/yourusername/sshcommand/master/gitreceive make install
```shell
sudo SSHCOMMAND_URL=https://raw.githubusercontent.com/yourusername/sshcommand/master/sshcommand make install
```
## Bootstrap a server from your own repository
The bootstrap script allows the dokku repository URL to be overridden to bootstrap a host from
your own clone of dokku using the `DOKKU_REPO` environment variable. Example:
The bootstrap script allows the dokku repository URL to be overridden to bootstrap a host from your own clone of dokku using the `DOKKU_REPO` environment variable. Example:
Dokku ships with a pre-built version of version of the [buildstep] component by
default. If you want to build your own version you can specify that with an env
variable.
Dokku ships with a pre-built version of version of the [herokuish](https://github.com/gliderlabs/herokuish) component by default. If you want to build your own version you can specify that with an env variable.
$ git clone https://github.com/progrium/dokku.git
$ cd dokku
$ sudo BUILD_STACK=true make install
```shell
git clone https://github.com/dokku/dokku.git
cd dokku
sudo BUILD_STACK=trueSTACK_URL=https://github.com/gliderlabs/herokuish.git make install
Once dokku is installed, if you are not using the web-installer, you'll want to configure a the virtualhost setup as well as the push user. If you do not, your installation will be considered incomplete and you will not be able to deploy applications.
Set up a domain and a wildcard domain pointing to that host. Make sure `/home/dokku/VHOST` is set to this domain. By default it's set to whatever hostname the host has. This file is only created if the hostname can be resolved by dig (`dig +short $(hostname -f)`). Otherwise you have to create the file manually and set it to your preferred domain. If this file still is not present when you push your app, dokku will publish the app with a port number (i.e. `http://example.com:49154` - note the missing subdomain).
You'll have to add a public key associated with a username by doing something like this from your local machine:
If you are using the vagrant installation, you can use the following command to add your public key to dokku:
$ cat ~/.ssh/id_rsa.pub | make vagrant-acl-add
That's it!
## VMs with less than 1GB of memory
Having less than 1GB of system memory available for dokku and its containers, for example Digital Ocean's small 512MB machines, might result in unexpected errors, such as **! [remote rejected] master -> master (pre-receive hook declined)** during installation of NPM dependencies (https://github.com/npm/npm/issues/3867).
To work around this issue, it might suffice to augment the linux swap file size to a maximum of twice the physical memory size.
To resize the swap file of a 512MB machine to 1GB, follow these steps while in SSH within your machine:
Once Dokku has been configured with at least one user, applications can be deployed via a `git push` command. To quickly see Dokku deployment in action, you can use the Heroku Ruby on Rails example app.
Create the application on the Dokku host. You will need to ssh onto the host to run this command.
```shell
dokku apps:create ruby-rails-sample
```
### Create the backing services
When you create a new app, Dokku by default *does not* provide any datastores such as MySQL or PostgreSQL. You will need to install plugins to handle that, but fortunately [Dokku has official plugins](/dokku/plugins/#official-plugins-beta) for common datastores. Our sample app requires a PostgreSQL service:
```shell
# install the postgres plugin
# plugin installation requires root, hence the user change
> You can link a single service to multiple applications or use one service per application.
### Deploy the app
Now you can deploy the `ruby-rails-sample` app to your Dokku server. All you have to do is add a remote to name the app. Applications are created on-the-fly on the Dokku server.
Fetching gem metadata from https://rubygems.org/...........
Fetching version metadata from https://rubygems.org/...
Fetching dependency metadata from https://rubygems.org/..
Using rake 10.4.2
...
```
When the deploy finishes, the application's URL will be shown.
```shell
=====> Application deployed:
http://ruby-rails-sample.dokku.me
```
Dokku supports deploying applications via [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) with [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks) or using a project's [dockerfile](https://docs.docker.com/reference/builder/).
### Removing a deployed app
You can also remove an application from your Dokku installation. This will unlink all linked services and destroy any config related to the application. Note that linked services will retain their data for later use (or removal).
```shell
# replace APP with the name of your application
dokku apps:destroy APP
```
This will prompt you to verify the application's name before destroying it. You may also use the `--force` flag to circumvent this verification process:
```shell
# replace APP with the name of your application
dokku --force apps:destroy APP
```
### Renaming a deployed app
> New as of 0.4.7
You can rename a deployed app using the `apps:rename` CLI tool:
```shell
dokku apps:rename OLD_NAME NEW_NAME
```
This will copy all of your app's contents into a new app directory with the name of your choice, delete your old app, then rebuild the new version of the app and deploy it. All of your config variables, including database urls, will be preserved.
### Adding deploy users
While it is possible to use password-based authorization to push to Dokku, it is preferable to use key-based authentication for security. You can add your public key to the dokku user's `authorized_keys` file with the following command:
```shell
# replace dokku.me with your domain name or the host's IP
Dokku only supports deploying from its master branch, so if you'd like to deploy a different local branch use: ```git push dokku <local branch>:master```
You can also support pushing multiple branches using the [receive-branch](/dokku/development/plugin-triggers/#receive-branch) plugin trigger in a custom plugin.
### Skipping deployment
If you only want to rebuild and tag a container, you can skip the deployment phase by setting `$DOKKU_SKIP_DEPLOY` to `true` by running:
Dokku uses git locally (i.e. not a docker image) to build its own copy of your app repo, including submodules. This is done as the `dokku` user. Therefore, in order to deploy private git submodules, you'll need to drop your deploy key in `/home/dokku/.ssh/` and potentially add github.com (or your VCS host key) into `/home/dokku/.ssh/known_hosts`. The following test should help confirm you've done it correctly.
Dokku is, at its core, a docker container manager. Thus, it does not necessarily play well with other out-of-band processes interacting with the docker daemon. One thing to note as in [issue #1220](https://github.com/dokku/dokku/issues/1220), dokku executes a cleanup function prior to every deployment. This function removes all exited containers and all 'unattached' images.
### Specifying a custom buildpack
See the [buildpack documentation](/dokku/deployment/buildpacks/).
## Default vhost
See the [nginx documentation](/dokku/nginx/#default-site).
## Dockerfile deployment
See the [dockerfile documentation](/dokku/deployment/dockerfiles/).
## Zero downtime deploy
See the [zero-downtime deploy documentation](/dokku/checks-examples/).
## Image tagging
See the [image tagging documentation](/dokku/deployment/images).
Following a deploy, dokku will now wait `10` seconds before routing traffic to the new 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 modify this value using the following command:
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 the server time to start. This value 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 value is also configurable globally:
> 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:
The CHECKS file may contain empty lines, comments (lines starting with #),
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
```
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
```
You can also specify the protocol to explicitly check HTTPS requests.
```
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
example:
```
WAIT=30 # Wait 1/2 minute
TIMEOUT=60 # Timeout after a minute
ATTEMPTS=10 # attempt checks 10 times
/ My Amazing App
```
## 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
ATTEMPTS=6
/check.txt simple_check
````
> check.txt is a text file returning the string 'simple_check'
### Deploy Output
> Note: The output has been trimmed for brevity
````
git push dokku master
-----> Cleaning up...
-----> Building myapp from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.0.0
.....
-----> Discovering process types
Procfile declares types -> web
-----> Releasing myapp...
-----> Deploying myapp...
-----> Running pre-flight checks
-----> Attempt 1/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
!
curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
! Check attempt 1/6 failed.
-----> Attempt 2/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
!
curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
! Check attempt 2/6 failed.
-----> Attempt 3/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
-----> All checks successful!
=====> myapp container output:
=> Booting Thin
=> Rails 4.2.0 application starting in production on http://0.0.0.0:5000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:5000, CTRL+C to stop
=====> end myapp container output
-----> Running post-deploy
-----> Configuring myapp.dokku.example.com...
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
Reloading nginx
-----> Shutting down old container in 60 seconds
=====> Application deployed:
http://myapp.dokku.example.com
````
## 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
````
WAIT=5
ATTEMPTS=6
/
````
> The check to the root url '/' would normally access the database.
### Deploy Output
> Note: The output has been trimmed for brevity
````
git push dokku master
-----> Cleaning up...
-----> Building myapp from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.0.0
.....
Discovering process types
Procfile declares types -> web
Releasing myapp...
Deploying myapp...
Running pre-flight checks
-----> Attempt 1/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (7) Failed to connect to 172.17.0.188 port 5000: Connection refused
! Check attempt 1/6 failed.
-----> Attempt 2/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (7) Failed to connect to 172.17.0.188 port 5000: Connection refused
! Check attempt 2/6 failed.
-----> Attempt 3/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 3/6 failed.
-----> Attempt 4/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 4/6 failed.
-----> Attempt 5/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 5/6 failed.
-----> Attempt 6/6 Waiting for 5 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
Could not start due to 1 failed checks.
! Check attempt 6/6 failed.
=====> myapp container output:
=> Booting Thin
=> Rails 4.2.0 application starting in production on http://0.0.0.0:5000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:5000, CTRL+C to stop
Started GET "/" for 172.17.42.1 at 2015-03-26 21:36:47 +0000
Is the server running on host "172.17.42.1" and accepting
TCP/IP connections on port 5431?
PG::ConnectionBad (could not connect to server: Connection refused
Is the server running on host "172.17.42.1" and accepting
Given the constraints, running dokku commands remotely via SSH is fine. For certain configurations, the extra complication of manually invoking ssh can be a burden.
While dokku does not yet have an official client, there are a multitude of ways in which you can interact with your dokku installation. The easiest is to use the **bash** client, though you may wish to use another.
## (bash, zsh, etc.) `dokku_client.sh`
Of all methods, this is the *most* official method of interacting with your dokku installation. It is a bash script that interacts with a remote dokku installation via ssh. It is available in `contrib/dokku_client.sh` in the root of the dokku repository.
To install, simply clone the dokku repository down and add the `dokku` alias pointing at the script:
```shell
git clone git@github.com:dokku/dokku.git ~/.dokku
# add the following to either your
# .bashrc, .bash_profile, or .profile file
aliasdokku='$HOME/.dokku/contrib/dokku_client.sh'
```
Alternatively, if using another shell such as **zsh**, create an alias command which invokes the script using **bash**:
```shell
# zsh: add the following to either .zshenv or .zshrc
# fish: add the following to ~/.config/fish/config.fish
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
# csh: add the following to .cshrc
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
```
Configure the `DOKKU_HOST` environment variable or run `dokku` from a repository with a git remote named dokku pointed at your dokku host in order to use the script as normal.
## (nodejs) dokku-toolbelt
Dokku-toolbelt is a node-based cli wrapper that proxies requests to the dokku command running on remote hosts. You can install it via the following shell command (assuming you have nodejs and npm installed):
```shell
npm install -g dokku-toolbelt
```
See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more information.
## (python) dokku-client
dokku-client is an extensible python-based cli wrapper for remote dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
```shell
pip install dokku-client
```
See [documentation here](https://github.com/adamcharnock/dokku-client) for more information.
## (ruby) Dokku CLI
Dokku CLI is a rubygem that acts as a client for your dokku installation. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dokku-cli
```
See [documentation here](https://github.com/SebastianSzturo/dokku-cli) for more information.
## (ruby) DokkuClient
DokkuClient is another rubygem that acts as a client for your dokku installation with built-in support for certain external plugins. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dokku_client
```
See [documentation here](https://github.com/netguru/dokku_client) for more information.
## (ruby) Dokkufy
Dokkufy is a rubygem that handles automation of certain tasks, such as dokku setup, plugin installation, etc. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dokkufy
```
See [documentation here](https://github.com/cbetta/dokkufy) for more information.
## (ruby) Dockland
Dockland is a rubygem that acts as a client for your dokku installation. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dockland
```
See [documentation here](https://github.com/uetchy/dockland) for more information.
Typically an application will require some configuration to run properly. Dokku supports application configuration via environment variables. Environment variables may contain private data, such as passwords or API keys, so it is not recommended to store them in your application's repository.
The `config` plugin provides the following commands to manage your variables:
```
config (<app>|--global) Display all global or app-specific config vars
config:get (<app>|--global) KEY Display a global or app-specific config value
config:set (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
config:unset (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
```
The variables are available both at run time and during the application build/compilation step.
> Note: Global `ENV` files are sourced before app-specific `ENV` files. This means that app-specific variables will take precedence over global variables. Configuring your global `ENV` file is manual, and should be considered potentially dangerous as configuration applies to all applications.
You can set multiple environment variables at once:
When setting or unsetting environment variables, you may wish to avoid an application restart. This is useful when developing plugins or when setting multiple environment variables in a scripted manner. To do so, use the `--no-restart` flag:
Dokku normally defaults to using [heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
- Use `dokku config:set` to set the `BUILDPACK_URL` environment variable.
- Add `BUILDPACK_URL` to a committed `.env` file in the root of your repository.
- Create a `.buildpacks` file in the root of your repository.
## Specifying a custom buildpack
In certain cases you may want to specify a custom buildpack. While dokku uses herokuish to support all the [official heroku buildpacks](https://github.com/gliderlabs/herokuish#buildpacks), it is possible that the buildpack detection does not work well for your application. As well, you may wish to use a custom buildpack to handle specific application logic.
To use a specific buildpack, you can run the following dokku command:
```shell
# replace APPwith the name of your application
# replace REPOSITORY_URL with your buildpack's url
dokku config:set APP BUILDPACK_URL=REPOSITORY_URL
```
Please check the documentation for your particular buildpack as you may need to include configuration files (such as a Procfile) in your project root.
## Using multiple buildpacks
You can only set a single buildpack using the `BUILDPACK_URL`, though there may be times when you wish to use multiple buildpacks. To do so, simply create a `.buildpacks` file in the base of your repository. This file should list all the buildpacks, one-per-line. For instance, if you wish to use both the `nodejs` and `ruby` buildpacks, your `.buildpacks` file should contain the following:
You may also choose to set just a single buildpack in this file, though that is up to you.
Please check the documentation for your particular buildpack(s) as you may need to include configuration files (such as a Procfile) in your project root.
## Using a specific buildpack version
As Dokku pins all buildpacks via herokuish releases, there may be occasions where a local buildpack version is out of date. If you wish to use a more recent version of the buildpack, you may use any of the above methods to specify a buildpack **without** the git sha attached like so:
Building containers with buildpacks currently results in a persistent `cache` directory between deploys. If you need to clear this cache directory for any reason, you may do so by running the following shell command:
```shell
# replace APPwith the name of your application
sudo rm -rf /home/dokku/APP/cache/*
```
### Curl Build Timeouts
Certain buildpacks may time out in retrieving dependencies via curl. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a curl command.
If you see output similar this when deploying , you may need to override the curl timeouts to increase the length of time allotted to those tasks. You can do so via the `config` plugin:
While Dokku normally defaults to using [heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, you can also use docker's native `Dockerfile` system to define a container.
To use a dockerfiles for deployment, commit a valid `Dockerfile` to the root of your repository and push the repository to your Dokku installation. If this file is detected, Dokku will default to using it to construct containers **except** in the following two cases:
- The application has a `BUILDPACK_URL` environment variable set via the `dokku config:set` command or in a committed `.env` file. In this case, Dokku will use your specified buildpack.
- The application has a `.buildpacks` file in the root of the repository. In this case, Dokku will use your specified buildpack(s).
## Exposed ports
By default, Dokku will extract the first `EXPOSE` tcp port and use said port with nginx to proxy your app to that port. For applications that have multiple ports exposed, you may override this port via the following command:
```shell
# replace APP with the name of your application
dokku config:set APP DOKKU_DOCKERFILE_PORT=8000
```
Dokku will not expose other ports on your application without a [custom docker-option](/dokku/docker-options/).
If you do not have a port explicitly exposed, Dokku will automatically expose port `5000` for your application.
## Customizing the run command
By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base nodejs image, with the following `ENTRYPOINT`:
Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disable docker's image layer cache. Lastly, for more granular build control, you may also pass any `docker build` option to `docker`, by setting `$DOKKU_DOCKER_BUILD_OPTS`.
Sometimes you need to either inspect running containers or run a one-off command under an application. In those cases, Dokku makes it easy to either connect to a running container or run a fresh container.
## Run a command in an app environment
```
run <app> <cmd> Run a command in the environment of an application
```
The `run` command can be used to run a one-off process for a specific command. This will start a new container and run the desired command within that container. Note that this container will be stay around even after command completes. The container will be the same container as was used to start the currently deployed application.
```shell
# runs `ls -lah` in the `/app` directory of the application `node-js-app`
dokku run node-js-app ls -lah
```
If you want to remove the container after a command has started, you can run the following command:
```shell
# keep `run` containers around
dokku config:set --global DOKKU_RM_CONTAINER=1
# revert the above setting and keep containers around
dokku config:unset --global DOKKU_RM_CONTAINER
```
You may also use the `--rm-container` or `--rm` dokku flags to remove the containers automatically:
```shell
dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
### Using `run` for cron tasks
You can always use a one-off container to run an application task:
```shell
dokku --rm run node-js-app some-command
dokku --rm-container run node-js-app some-command
```
For tasks that should not be interrupted, run is the **preferred** method of handling cron tasks, as the container will continue running even during a deploy or scaling event. The trade-off is that there will be an increase in memory usage if there are multiple concurrent tasks running.
## Entering existing containers
> New as of 0.4.0
```
enter <app> [<container-type> || --container-id <container-id>] Connect to a specific app container
```
The `enter` command can be used to enter a running container. The following variations of the command exist:
```shell
dokku enter node-js-app web
dokku enter node-js-app web.1
dokku enter node-js-app --container-id ID
```
By default, it runs a `/bin/bash`, but can also be used to run a custom command:
```shell
# just echo hi
dokku enter node-js-app web echo hi
# run a long-running command, as one might for a cron task
dokku enter node-js-app web python script/background-worker.py
```
### Using `enter` for cron tasks
Your procfile can have the following entry:
```
cron: while true; do sleep 10; done
```
With the `cron` process scaled to `1`:
```shell
dokku ps:scale node-js-app cron=1
```
You can now run all your commands in that container:
```shell
dokku enter api cron some-command
```
Note that you can also run multiple commands at the same time to reduce memory usage, though that may result in polluting the container environment.
For tasks that will properly resume, you **should** use the above method, as running tasks will be interrupted during deploys and scaling events, and subsequent commands will always run with the latest container. Note that if you scale the cron container down, this may interrupt proper running of the task.
## General Cron Recommendations
Regularly scheduled tasks can be a bit of a pain with dokku. The following are general recommendations to follow to help ensure successful task runs.
- Add a `MAILTO` environment variable to ship cron emails to yourself.
- Add a `PATH` environment variable or specify the full path to binaries on the host.
- Add a `SHELL` environment variable to specify bash when running commands.
- Keep your cron tasks in time-sorted order.
- Keep your server time in UTC so you don't need to translate daylight saving's time when reading the cronfile.
- Run tasks at the lowest traffic times if possible.
- Use cron to **trigger** jobs, not run them. Use a real queuing system such as rabbitmq to actually process jobs.
- Try to keep tasks quiet so that mails only send on errors.
- Do not silence standard error or standard out. If you silence the former, you will miss failures. Silencing the latter means you should actually make application changes to handle log levels.
- Use a service such as [Dead Man's Snitch](https://deadmanssnitch.com) to verify that cron tasks completed successfully.
- Add lots of comments to your cronfile, including what a task is doing, so that you don't spend time deciphering the file later.
- Place your cronfiles in a pattern such as `/etc/cron.d/APP`.
- Do not use non-ascii characters in your cronfile names. Cron is finicky.
- Remember to have trailing newlines in your cronfile! Cron is finicky.
The following is a sample cronfile that you can use for your applications:
```
# server cron jobs
MAILTO="mail@example.com"
PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
# m h dom mon dow username command
# * * * * * dokku command to be executed
# - - - - -
# | | | | |
# | | | | +----- day of week (0 - 6) (Sunday=0)
# | | | +------- month (1 - 12)
# | | +--------- day of month (1 - 31)
# | +----------- hour (0 - 23)
# +----------- min (0 - 59)
### HIGH TRAFFIC TIME IS B/W 00:00 - 04:00 AND 14:00 - 23:59
### RUN YOUR TASKS FROM 04:00 - 14:00
### KEEP SORTED IN TIME ORDER
### PLACE ALL CRON TASKS BELOW
# removes unresponsive users from the subscriber list to decrease bounce rates
Dokku supports SSL/TLS certificate inspection and CSR/Self-signed certificate generation via the `certs` plugin. Note that whenever SSL/TLS support is enabled SPDY is also enabled.
```
certs:add <app> CRT KEY Add an ssl endpoint to an app. Can also import from a tarball on stdin.
certs:generate <app> DOMAIN Generate a key and certificate signing request (and self-signed certificate)
certs:info <app> Show certificate information for an ssl endpoint.
certs:remove <app> Remove an SSL Endpoint from an app.
certs:update <app> CRT KEY Update an SSL Endpoint on an app. Can also import from a tarball on stdin
# for 0.3.x
dokku nginx:import-ssl <app> < certs.tar
```
## Per-application certificate management
Dokku provides built-in support for managing SSL certificates on a per-application basis. SSL is managed via nginx outside of application containers, and as such can be updated on-the-fly without rebuilding containers. At this time, applications only support a single SSL certificate at a time. To support multiple domains for a single application, wildcard certificate usage is encouraged.
### Certificate setting
The `certs:add` command can be used to push a `tar` containing a certificate `.crt` and `.key` file to a single application. The command should correctly handle cases where the `.crt` and `.key` are not named properly or are nested in a subdirectory of said `tar` file. You can import it as follows:
```shell
tar cvf cert-key.tar server.crt server.key
# replace APP with the name of your application
dokku certs:add <app> < cert-key.tar
```
> Note: If your `.crt` file came alongside a `.ca-bundle`, you'll want to concatenate those into a single `.crt` file before adding it to the `.tar`.
> Note: Using this method will create a self-signed certificate, which is only recommended for development or staging use, not production environments.
The `certs:generate` command will walk you through the correct `openssl` commands to create a key, csr and a self-signed cert for a given app/domain. We automatically put the self-signed cert in place as well as add the specified domain to the application configuration.
If you decide to obtain a CA signed certficate, you can import that certificate using the aformentioned `dokku certs:add` command.
### Certificate information
The `certs:info` command will simply inspect the install SSL cert and print out details. NOTE: The server-wide certificate will be inspect if installed and no app-specific certificate exists.
```
root@dokku:~/dokku# dokku certs:info node-js-app
-----> Fetching SSL Endpoint info for node-js-app...
The `certs:remove` command only works on app-specific certificates. It will `rm` the app-specific tls directory, rebuild the nginx configuration, and reload nginx.
## Global Certification
Global certificate management is a manual process. To enable TLS connections for all your applications at once you will need a wildcard TLS certificate.
To enable TLS across all apps, you can run the following commands:
```shell
mkdir -p /home/dokku/tls
cp server.crt /home/dokku/tls/server.crt
cp server.key /home/dokku/tls/server.key
```
Next, you will want to enable the certificates by editing `/etc/nginx/conf.d/dokku.conf` and uncommenting these two lines (remove the `#`):
```
ssl_certificate /home/dokku/tls/server.crt;
ssl_certificate_key /home/dokku/tls/server.key;
```
The settings will take affect at the next deploy. If you would like to propagate the change to all apps immediately, you can also run the following command:
```shell
dokku ps:restartall
```
Once TLS is enabled, the application will be accessible by `https://` (redirection from `http://` is applied as well).
> Note: TLS will not be enabled unless the application's VHOST matches the certificate's name. (i.e. if you have a cert for `*.example.com` TLS won't be enabled for `something.example.org` or `example.net`)
## HSTS Header
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. dokku does not, by default, enable this header. It is thus left up to you, the user, to enable it for your site.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails.
## Running behind a load balancer
> New as of 0.3.17
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-For` and `X-Forwarded-Port`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
If your server runs behind an HTTP/S load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by setting the `DOKKU_SSL_TERMINATED` environment variable:
```shell
dokku config:set myapp DOKKU_SSL_TERMINATED=1
```
Only use this option if:
1. All requests are terminated at the load balancer, and forwarded to Nginx
2. The load balancer is configured to send the `X-Forwarded-` headers (this may be off by default)
If it's possible to make HTTP/S requests directly to Nginx, bypassing the load balancer, or if the load balancer is not configured to set these headers, then it becomes possible for a client to set these headers to arbitrary values.
This could result in security issue, for example, if your application looks at the value of the `X-Forwarded-Proto` to determine if the request was made over HTTPS.
Each plugin requires a `plugin.toml` descriptor file with the following required fields:
```shell
[plugin]
description="dokku hello plugin"
version="0.1.0"
[plugin.config]
```
A few notes:
- You should always support `DOKKU_TRACE` as specified on the 2nd line of the plugin.
- If your command requires that an application exists, ensure you check for it's existence in the manner prescribed above.
- A `help` command is required, though it is allowed to be empty. Also, the command syntax will need to separated by `, ` in order to maintain columnar output alignment.
- Commands *should* be namespaced.
- As of 0.3.3, a catch-all should be implemented which exits with a `DOKKU_NOT_IMPLEMENTED_EXIT` code. This allows dokku to output a `command not found` message.
- Be sure you want the "set -eo pipefail" option. Look at the following example :
dokku_log_fail "user/repo image not found... Did you run 'dokku plugin:install'?"
fi
```
In the case where the "user/repo" is not installed, dokku exits just before the awk command,
you will never see the message printed with echo. You just want "set -e" in this case.
Here is the documentation of the 'set -eo pipefail' option:
```
help set
Options:
-e Exit immediately if a command exits with a non-zero status.
-o option-name
pipefail the return value of a pipeline is the status of
the last command to exit with a non-zero status,
or zero if no command exited with a non-zero status
```
- As some plugins require access to set app config settings and do not want/require the default Heroku-style behavior of a restart, we have the following "internal" commands that provide this functionality :
- From time to time you may want to allow other plugins access to (some of) your plugin's functionality. You can expose this by including a `functions` file in your plugin for others to source. Consider all functions in that file to be publicly accessible by other plugins. Any functions not wished to be made "public" should reside within your plugin trigger or commands files.
- As of 0.4.0, we allow image tagging and deployment of said tagged images. Therefore, hard-coding of `$IMAGE` as `dokku/$APP` is no longer sufficient. Instead, for non `pre/post-build-*` plugins, use `get_running_image_tag()` & `get_app_image_name()` as sourced from common/functions. See the [plugin triggers](http://dokku.viewdocs.io/dokku/development/plugin-triggers) doc for examples.
[Plugin triggers](https://github.com/dokku/plugn) (formerly [pluginhooks](https://github.com/progrium/pluginhook)) are a good way to jack into existing dokku infrastructure. You can use them to modify the output of various dokku commands or override internal configuration.
Plugin triggers are simply scripts that are executed by the system. You can use any language you want, so long as the script:
- Is executable
- Has the proper language requirements installed
For instance, if you wanted to write a plugin trigger in PHP, you would need to have `php` installed and available on the CLI prior to plugin trigger invocation.
The following is an example for the `nginx-hostname` plugin trigger. It reverses the hostname that is provided to nginx during deploys. If you created an executable file named `nginx-hostname` with the following code in your plugin trigger, it would be invoked by dokku during the normal app deployment process:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";SUBDOMAIN="$2";VHOST="$3"
NEW_SUBDOMAIN=`echo$SUBDOMAIN| rev`
echo"$NEW_SUBDOMAIN.$VHOST"
```
## Available plugin triggers
There are a number of plugin-related triggers. These can be optionally implemented by plugins and allow integration into the standard dokku setup/backup/teardown process.
The following plugin triggers describe those available to a dokku installation. As well, there is an example for each trigger that you can use as templates for your own plugin development.
> The example plugin trigger code is not guaranteed to be implemented as in within dokkku, and are merely simplified examples. Please look at the dokku source for larger, more in-depth examples.
### `install`
- Description: Used to setup any files/configuration for a plugin.
- Invoked by: `dokku plugin:install`.
- Arguments: None
- Example:
```shell
#!/usr/bin/env bash
# Sets the hostname of the dokku server
# based on the output of `hostname -f`
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
if[[ ! -f "$DOKKU_ROOT/HOSTNAME"]];then
hostname -f > $DOKKU_ROOT/HOSTNAME
fi
```
### `dependencies`
- Description: Used to install system-level dependencies. Invoked by `plugin:install-dependencies`.
- Invoked by: `dokku plugin:install-dependencies`
- Arguments: None
- Example:
```shell
#!/usr/bin/env bash
# Installs nginx for the current plugin
# Supports both opensuse and ubuntu
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
exportDEBIAN_FRONTEND=noninteractive
case"$DOKKU_DISTRO" in
debian|ubuntu)
apt-get install --force-yes -qq -y nginx
;;
opensuse)
zypper -q in -y nginx
;;
esac
```
### `update`
- Description: Can be used to run plugin updates on a regular interval. You can schedule the invoker in a cron-task to ensure your system gets regular updates.
- Invoked by: `dokku plugin:update`.
- Arguments: None
- Example:
```shell
#!/usr/bin/env bash
# Update the herokuish image from git source
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
cd /root/dokku
sudo BUILD_STACK=true make install
```
### `commands help`
- Description: Used to aggregate all plugin `help` output. Your plugin should implement a `help` command in your `commands` file to take advantage of this plugin trigger. This must be implemented inside the `commands` plugin file.
- Invoked by: `dokku help`
- Arguments: None
- Example:
```shell
#!/usr/bin/env bash
# Outputs help for the derp plugin
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
case"$1" in
help| derp:help)
cat<<EOF
derp:herp, Herps the derp
derp:serp [file], Shows the file's serp
EOF
;;
*)
exit$DOKKU_NOT_IMPLEMENTED_EXIT
;;
esac
```
### `backup-export`
- Description: Used to backup files for a given plugin. If your plugin writes files to disk, this plugin trigger should be used to echo out their full paths. Any files listed will be copied by the backup plugin to the backup tar.gz.
- Invoked by: `dokku backup:export`
- Arguments: `$VERSION $DOKKU_ROOT`
- Example:
```shell
#!/usr/bin/env bash
# Echos out the location of every `REDIRECT` file
# that are used by the apps
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
shopt -s nullglob
VERSION="$1"
DOKKU_ROOT="$2"
cat;for i in $DOKKU_ROOT/*/REDIRECT;doecho$i;done
```
### `backup-check`
- Description: Checks that a backup being imported passes sanity checks.
- Description: Allows you to run commands before the build image is created for a given app. For instance, this can be useful to add env vars to your container. Only applies to applications using buildpacks.
- Invoked by: `dokku build`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `post-build-buildpack`
- Description: Allows you to run commands after the build image is create for a given app. Only applies to applications using buildpacks.
- Invoked by: `dokku build`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `pre-build-dockerfile`
- Description: Allows you to run commands before the build image is created for a given app. For instance, this can be useful to add env vars to your container. Only applies to applications using a dockerfile.
- Invoked by: `dokku build`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `post-build-dockerfile`
- Description: Allows you to run commands after the build image is create for a given app. Only applies to applications using a dockerfile.
- Invoked by: `dokku build`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `pre-release-buildpack`
- Description: Allows you to run commands before environment variables are set for the release step of the deploy. Only applies to applications using buildpacks.
- Invoked by: `dokku release`
- Arguments: `$APP $IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
# Installs the graphicsmagick package into the container
ID=$(docker run -i -a stdin $IMAGE /bin/bash -c "$CMD")
test$(docker wait$ID) -eq 0
docker commit $ID$IMAGE > /dev/null
```
### `post-release-buildpack`
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to applications using buildpacks.
- Invoked by: `dokku release`
- Arguments: `$APP $IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
# Installs a package specified by the `CONTAINER_PACKAGE` env var
ID=$(docker run -i -a stdin $IMAGE /bin/bash -c "$CMD")
test$(docker wait$ID) -eq 0
docker commit $ID$IMAGE > /dev/null
```
### `pre-release-dockerfile`
- Description: Allows you to run commands before environment variables are set for the release step of the deploy. Only applies to applications using a dockerfile.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to applications using a dockerfile.
- Description: Allows you to disable binding to the external box ip
- Invoked by: `dokku deploy`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
# Force always binding to the docker ip, no matter
# what the settings are for a given app.
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
echofalse
```
### `post-domains-update`
- Description: Allows you to run commands once the domain for an application has been updated. It also sends in the command that has been used. This can be "add", "clear" or "remove". The third argument will be the optional list of domains
- Description: Allows you to customize the contents of an application directory before they are processed for deployment. The `IMAGE_SOURCE_TYPE` can be any of `[herokuish, dockerfile]`
docker tag -f $IMAGE_ID$DOCKER_HUB_USER/$APP:$IMAGE_TAG
docker push $DOCKER_HUB_USER/$APP:$IMAGE_TAG
```
### `tags-destroy`
- Description: Allows you to run commands once a tag for an application image has been removed
- Invoked by: `dokku tags:destroy`
- Arguments: `$APP $IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
# Remove an image tag from docker hub
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";IMAGE_TAG="$2"
some code to remove a docker hub tag because it's not implemented in the CLI....
```
### `retire-container-failed`
- Description: Allows you to run commands if/when retiring old containers has failed
- Invoked by: `dokku deploy`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
# Send an email when a container failed to retire
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";HOSTNAME=$(hostname -s)
mail -s "$APP containers on $HOSTNAME failed to retire" ops@example.com
```
### `user-auth`
This is a special plugin trigger that is executed on *every* command run. As dokku sometimes internally invokes the `dokku` command, special care should be taken to properly handle internal command redirects.
Note that the trigger should exit as follows:
-`0` to continue running as normal
-`1` to halt execution of the command
The `SSH_USER` is the original ssh user. If you are running remote commands, this user will typically be `dokku`, and as such should not be trusted when checking permissions. If you are connected via ssh as a different user who then invokes `dokku`, the value of this variable will be that user's name (`root`, `myuser`, etc.).
The `SSH_NAME` is the `NAME` variable set via the `sshcommand acl-add` command. If you have set a user via the `dokku-installer`, this value will be set to `admin`. For installs via debian package, this value *may* be `default`. For reference, the following command can be run as the root user to specify a specific `NAME` for a given ssh key:
```shell
sshcommand acl-add dokku NAME < $PATH_TO_SSH_KEY
```
Note that the `NAME` value is set at the first ssh key match. If an ssh key is set in the `/home/dokku/.ssh/authorized_keys` multiple times, the first match will decide the value.
- Description: Allows you to deny access to a dokku command by either ssh user or associated ssh-command NAME user.
Dokku is released in intervals *at most* three weeks apart, though may be released much quicker.
To propose a release, the following tasks need to be performed:
- The installable version must be changed in the `contrib/dokku-installer.py` file.
- The installable version must be changed in the `debian/control` file.
- The installable version must be changed in the `docs/home.html` file
- The installable version must be changed in the `docs/index.md` file
- The installable version must be changed in the `docs/installation.md` file.
- The installable version must be changed in the `docs/template.html` file.
- The installable version must be changed in the `README.md` file.
- The embedded css should be cleared in the `docs/template.html` file.
- The versioned links should be updated in the `docs/assets/favicons/browserconfig.xml` file.
- The versioned links should be updated in the `docs/assets/favicons/manifest.json` file.
- The versioned links should be updated in the `docs/assets/style.css` file.
- The versioned links should be updated in the `docs/home.html` file.
- The versioned links should be updated in the `docs/template.html` file.
- The versioned links should be updated in the `docs/template.html` file.
- A list of changes must be made in the `HISTORY.md`.
- A tag must be created locally with your release version
- Debian packages *must* be created via `vagrant up build`
- The packages should be uploaded to packagecloud.io
- All changes are pushed to master and the tag should be turned into a release which will contain the changelog.
## Versioning
Dokku follows semver standards. As we are not yet at a stable release, breaking changes will require *only* a minor release, while all other changes only require a patch release. Once we hit stable, breaking changes will require a major release.
Tags should be created via the following method:
```shell
git tag v0.9.9
```
At the moment, tags need not be signed, though that may change in the future.
## Debian Packages
The `build` target in the dokku `Vagrantfile` creates debian packages for dokku at a point in time. The version will be based upon the latest local tag - you may create your own, internal tags/releases if that is so desired.
Debian package information is held in the `debian` directory of the dokku project.
For the public project, releases should be pushed to packagecloud.io *after* a tag is created but *before* said tag is pushed to github. The following may be the release workflow:
If new versions of other packages were created, these should also be pushed at this time.
> If you are a maintainer and need the PACKAGECLOUD_TOKEN in order to make a release, please contact @josegonzalez to get this information.
## Changelog format
The `HISTORY.md` should be added to based on the changes made since the previous release. This can be done by reviewing all merged pull requests to the master branch on github. The format is as follows:
```
## 0.9.9
Some description concerning major changes in this release, or potential incompatibilities.
Dokku now has a full test suite to assist in quick iterating development. These tests include a linter using [shellcheck](https://github.com/koalaman/shellcheck), functional unit tests using the [bats testing framework](https://github.com/sstephenson/bats), and a deployment suite of example apps that use the most popular languages and frameworks.
Bats tests can be found here:
```
tests/unit/*.bats
```
Example apps can be found here:
```
tests/apps/
```
### Executing tests locally
- Setup dokku in a [vagrant vm](http://dokku.viewdocs.io/dokku/getting-started/install/vagrant)
- Test setup and execution
```shell
$ vagrant ssh
$ sudo su -
$ cd ~/dokku
$ make ci-dependencies setup-deploy-tests
$ make test # run the entire test suite (linter, bats tests, and app deployment tests)
$
$ make lint # linter
$ make unit-tests # bats tests
$ make deploy-tests # app deployment tests
```
- Additionally you may run a specific app deployment tests with a target similar to:
```shell
make deploy-test-nodejs-express
```
- For a full list of test make targets check out `tests.mk` in the root of the dokku repository.
There are many different DNS servers 'in the wild'. Some of the popular ones on Linux are BIND, dnsmasq, and pdns. Windows has its own built-in DNS server as well as Unbound, Posadis, and more. A full list of DNS packages can be found on Wikipedia under [Comparison of DNS Server Software](http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software). In addition to the various DNS packages, there are tens of thousands of [Managed DNS Providers](http://en.wikipedia.org/wiki/List_of_managed_DNS_providers) out that all have different DNS interfaces.
### Focus
Because there are so many different DNS server packages out there as well as a tremendous number of Managed DNS Providers, we will focus on the concepts of DNS as well as providing examples in the 'BIND' format so you can adapt the information to your own server package or managed DNS provider.
### Assumptions
* We assume you have a passing familiarity with DNS. If not, you can read an [in-depth article](http://www.diaryofaninja.com/blog/2012/03/03/devops-dns-for-developers-ndash-now-therersquos-no-excuse-not-to-know) on DNS. But basically you need to know that DNS changes names (like example.tld) into addresses (like 127.0.0.1)
* We assume you already have a domain name registered and pointed to your favorite Managed DNS Provider or have your own BIND DNS server running.
* You have a server on the internet and are about to follow the instructions in the [README](https://github.com/dokku/dokku/blob/master/README.md) to get dokku installed. Don't do the install just yet though.
### HELP!
Don't be afraid to ask if you need help. Create a [new issue](https://github.com/dokku/dokku/issues) and someone will be glad to assist you.
# Getting started
For the examples, we will use the domain name `example.tld` and the IP address `127.0.0.1`.
Dokku uses DNS to differentiate between apps on your dokku-powered server. If you are using the domain `example.tld`, and you have two apps `myapp1` and `myapp2`, dokku will make them available at `myapp1.example.tld` and `myapp2.example.tld`.
To get started, you need to know the IP address of your dokku server. Connect to it and run `ifconfig` or `ip addr` to see the IP address.
# Caching
Please remember that DNS relies heavily on _caching_. Changes you make to DNS could take anywhere from a few seconds to a few *days* to propagate. If you tried surfing to example.tld, then changed the IP address in DNS, it could be a while before your computer picks up on the changes.
## The two methods
Now you have to make a decision about your domain. Do you want everything and anything at `example.tld` to go to your dokku server, or would you rather use a 'sub domain' for your dokku server?
In other words, do you want your applications on your dokku server accessible via `myapp.example.tld` or via `myapp.myserver.example.tld`?
### Using a sub-domain (myapp.myserver.example.tld)
Using a sub-domain is easy. When you set up your server, you probably gave it a name like `myserver.example.tld`.
Go in to your Managed DNS provider and create an `A` record named `myserver` and put in the IP address you got from your server a few moments ago.
Hopefully your managed DNS provider also supports wildcards. Create a second `A` record named `*.myserver` along with the IP address you got from your server a few moments ago.
If you are using BIND, your zone file will look similar to this:
```
$ORIGIN example.tld
$TTL 5m
myserver IN A 127.0.0.1
*.myserver IN A 127.0.0.1
```
You can verify your changes in Linux by trying one or more of the following commands:
*`host myserver.example.tld`
*`dig -t A myserver.example.tld`
*`nslookup myserver.example.tld`
Now is a good time to remind you that the answers you get MAY BE CACHED.
If everything is working correctly, you should also be able to query for any other name under `myserver.example.tld` and get back the IP address of your server. Try:
*`host test.myserver.example.tld`
*`host xyzzy.myserver.example.tld`
If they all return your IP address, you have set DNS up properly for dokku. You should also be able to `ssh root@myserver.example.tld` and access your server.
Proceed with the setup instructions in the [README](https://github.com/dokku/dokku/blob/master/README.md)
### Using the root of your domain (myapp.example.tld)
This section is a work in progress. It is incomplete.
Using the 'root' of your domain is nearly identical to the previous example.
* hostname is under `example.tld`, still needs `A` record
* Need to modify `/home/dokku/HOSTNAME` and `/home/dokku/VHOST`
dokku docker-options:add myapp run "-v /home/dokku/logs/myapp:/app/logs"
```
> Note: When [mounting a host directory](https://docs.docker.com/engine/reference/run/#volume-shared-filesystems) in a Dokku app you should first create that directory as user `dokku` and then mount the directory under `/app` in the container using `docker-options` as above. Otherwise the app will lack write permission in the directory.
### Output Docker options
```shell
dokku docker-options myapp
# Deploy options:
# -v /home/dokku/logs/myapp:/app/logs
# Run options:
# -v /home/dokku/logs/myapp:/app/logs
```
### Remove a Docker option
```shell
dokku docker-options:remove myapp run "-v /home/dokku/logs/myapp:/app/logs"
```
## Advanced usage
In your applications folder `/home/dokku/app_name` create a file called `DOCKER_OPTIONS_RUN` (or `DOCKER_OPTIONS_BUILD` or `DOCKER_OPTIONS_DEPLOY`).
Inside this file list one Docker option per line. For example:
```shell
--link container_name:alias
-v /host/path:/container/path
-v /another/container/path
```
The above example will result in the following options being passed to Docker during `dokku run`:
Docker provides an _events_ command to show system's real time events. Likewise, Dokku can record events as syslog entries and also provides a plugin to display the last ones.
```
events [-t] Show the last events (-t follows)
events:list List logged events
events:on Enable events logger
events:off Disable events logger
```
## Usage
Enable the plugin:
```
$ dokku events:on
Enabling dokku events logger
```
Dokku will then write log entries to ``/var/log/syslog`` as well as a Dokku-specific logs sub-directory ``/var/log/dokku/events.log``, which can be easily displayed with the command `dokku events`:
- If you don't already have one [generate an SSH key pair](https://help.github.com/articles/generating-ssh-keys/).
- Go to the [dokku on azure deployment page](https://azure.microsoft.com/en-us/documentation/templates/dokku-vm/) and click **Deploy to Azure**.
- You'll be prompted to enter a few parameters, including a unique storage account name and a unique name for the sub-domain used for your public IP address. For the `sshKeyData` parameter, copy and paste the contents of the **public** key file you just created. After a few minutes the Dokku instance will be deployed.
- In your browser of choice, navigate to `http://[[dnsNameForPublicIP]].[[location]].cloudapp.azure.com`. Where `[[dnsNameForPublicIP]]` and `[[location]]` are template parameters you used to deploy the template.
- Finish your dokku setup like you normally would by creating a **new** public/private key pair for your deployments using `ssh-keygen` (don't use the same one as you created in the first step). You should select 'Use Virtual Host Naming' and set the `Hostname` to a **public dns name** that you own such as one you would purchase from [namecheap](http://namecheap.com). Alternatively thanks to [xip.io]( http://xip.io/) you can just use yourAzurePublicIP.xip.io for free. For example, if your public IP is `44.44.44.44` then you would set it to `44.44.44.44.xip.io`.
As of 0.3.18, dokku defaults to being installed via debian package. While certain hosts may require extra work to get running, you may optionally wish to automate the installation of dokku without the use of our `bootstrap.sh` bash script. The following are the steps run by said script:
echo"deb https://packagecloud.io/dokku/dokku/ubuntu/ trusty main"| sudo tee /etc/apt/sources.list.d/dokku.list
sudo apt-get update -qq > /dev/null
sudo apt-get install dokku
sudo dokku plugin:install-dependencies --core
```
## Unattended installation
In case you want to perform an unattended installation of dokku, this is made possible through [debconf](https://en.wikipedia.org/wiki/Debconf_%28software_package%29), which allows you to configure a package before installing it.
You can set any of the below options through the `debconf-set-selections` command, for example to enable vhost-based deployments:
On Digital Ocean, there is a pre-made image that can be run for Dokku. You can choose to run this image on any sized droplet, though larger droplets will allow you to run larger applications.
When choosing your Droplet configuration, please disable IPv6 on the droplet. There are known issues with IPv6 on Digital Ocean and Docker, and many have been reported to the Dokku issue tracker.
If you would like to run Dokku on an IPv6 Digital Ocean Droplet, please consult [this guide](https://jeffloughridge.wordpress.com/2015/01/17/native-ipv6-functionality-in-docker/) for modifying Docker to run under the Digital Ocean IPv6 configuration.
When installing Dokku on a Linode server, you'll likely see an error during Docker installation:
> Warning: current kernel is not supported by the linux-image-extra-virtual package. We have no AUFS support. Consider installing the packages linux-image-virtual kernel and linux-image-extra-virtual for AUFS support.
After 10 seconds, the installation will continue as normal.
This warning is the result of Linode using its own kernel, which does not support AUFS, instead of using the kernel supplied by Ubuntu. If you ignore the warning, Docker will fall back to using the DeviceMapper storage backend and Dokku will work normally. However, AUFS is better tested and will perform better.
If you would like to use AUFS, follow the steps below to install Ubuntu's kernel and configure your server to boot it instead of Linode's.
## Preparing your Linode for AUFS
__Warning__: These steps will delete *everything* on your Linode.
1. Open your server's dashboard in the [Linode Manager](https://manager.linode.com/).
2. Make sure your Linode is [using KVM](https://www.linode.com/docs/platform/kvm#how-to-enable-kvm), not Xen, for virtualization.
3. In the "Rebuild" tab, select "Ubuntu 14.04 LTS", set a root password, and rebuild.
4. Once your Linode has been created, click "Boot" and wait for it to complete.
5. SSH into your Linode as root and run the following commands:
6. When prompted, install Grub onto the first hard drive.
7. Back in your server's dashboard, click "Edit" on its Configuration Profile
8. Change the "Kernel" option to "GRUB 2" and save your changes.
9. Lastly, reboot the Linode.
Once your server comes back online, you'll be running Ubuntu's default kernel. You can now follow Dokku's [normal installation instructions](http://dokku.viewdocs.io/dokku/installation) and `bootstrap.sh` will take care of everything else.
- Download and install [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
- Download and install [Vagrant](http://www.vagrantup.com/downloads.html)
- Clone Dokku
```
git clone https://github.com/dokku/dokku.git
```
- Setup SSH hosts in your `/etc/hosts`
```
10.0.0.2 dokku.me
```
- Create VM
```
# Optional ENV arguments:
# - `BOX_NAME`
# - `BOX_URI`
# - `BOX_MEMORY`
# - `DOKKU_DOMAIN`
# - `DOKKU_IP`
# - `FORWARDED_PORT`.
cd path/to/dokku
vagrant up
```
- Setup SSH Config in `~/.ssh/config`. The port listed here is usually correct, though you may want to verify that it is the same as the one listed in the output of `vagrant ssh-config dokku`
```
Host dokku.me
Port 22
```
- Copy your SSH key via `cat ~/.ssh/id_rsa.pub | pbcopy` and paste it into the dokku-installer at http://dokku.me . Change the `Hostname` field on the Dokku Setup screen to your domain and then check the box that says `Use virtualhost naming`. Then click *Finish Setup* to install your key. You'll be directed to application deployment instructions from here.
You are now ready to deploy an app or install plugins.
For a different, complete, example see https://github.com/RyanBalfanz/dokku-vagrant-example.
The Official Dokku website is always a great place to visit. It features links to oft-used developer tools, community plugins, and guides on using dokku.
## The IRC Channel
IRC Channel on irc.freenode.net:
-#dokku– General Discussion
If you’re stumped, give us a holler in the Dokku IRC channel. Someone from the development team is usually there, especially during the daylight hours for North and South America users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate your brand new sports car.
If [here](http://webchat.freenode.net/?channels=dokku) for a web-based client IRC client.
## Stack Overflow
http://stackoverflow.com/
Tag your questions with `dokku` to enable existing users of Stack Overflow to find your questions.
<spanclass="output"># => Go to your server's IP and follow the web installer</span>
</p>
</div>
</div>
<hrclass="featurette-divider">
<!-- START THE FEATURETTES -->
<divclass="row featurette">
<divclass="col-md-7">
<h2class="featurette-heading">Own Your PaaS. <spanclass="text-muted">Infrastructure at a fraction of the cost.</span></h2>
<pclass="lead">Powered by Docker, you can install Dokku on any hardware. Use it on inexpensive cloud providers. Use the extra cash to buy a pony or feed kittens. You'll save tens of dollars a year on your dog photo sharing website.</p>
<h2class="featurette-heading">Easy Git Deploys. <spanclass="text-muted">From your command-line to the cloud.</span></h2>
<pclass="lead">Once it's set up on a host, you can push Heroku-compatible applications to it via Git. They'll build using Heroku buildpacks and then run in isolated containers. The end result is your own, single-host version of Heroku.</p>
<h2class="featurette-heading">Extensible Platform. <spanclass="text-muted">Customize your PaaS.</span></h2>
<pclass="lead">Write dokku plugins in any language. Share them online with others, and extend those already available. Dokku's simple core is easy to hack and add the features you need to get your job done.</p>
<span class="output"># => Go to your server's IP and follow the web installer</span>
</p>
</div>
</div>
<hr class="featurette-divider">
<!-- START THE FEATURETTES -->
<div class="row featurette">
<div class="col-md-7">
<h2 class="featurette-heading">Own Your PaaS. <span class="text-muted">Infrastructure at a fraction of the cost.</span></h2>
<p class="lead">Powered by Docker, you can install Dokku on any hardware. Use it on inexpensive cloud providers. Use the extra cash to buy a pony or feed kittens. You'll save tens of dollars a year on your dog photo sharing website.</p>
<h2 class="featurette-heading">Easy Git Deploys. <span class="text-muted">From your command-line to the cloud.</span></h2>
<p class="lead">Once it's set up on a host, you can push Heroku-compatible applications to it via Git. They'll build using Heroku buildpacks and then run in isolated containers. The end result is your own, single-host version of Heroku.</p>
<h2 class="featurette-heading">Extensible Platform. <span class="text-muted">Customize your PaaS.</span></h2>
<p class="lead">Write dokku plugins in any language. Share them online with others, and extend those already available. Dokku's simple core is easy to hack and add the features you need to get your job done.</p>
The installation process takes about 5-10 minutes, depending upon internet connection speed.
Once the installation is complete, you can open a browser to setup your SSH key and virtualhost settings. Open your browser of choice and navigate to the host's IP address - or the domain you assigned to that IP previously - and configure dokku via the web admin.
Once you save your settings, the web admin will self-terminate and you should be able to run or deploy to the dokku installation.
### Installing via other methods
For various reasons, certain hosting providers may have other steps that should be preferred to the above. If hosted on any of the following popular hosts, please follow the linked to instructions:
Dokku uses nginx as its server for routing requests to specific applications. By default, access and error logs are written for each app to `/var/log/nginx/${APP}-access.log` and `/var/log/nginx/${APP}-error.log` respectively
```
nginx:access-logs <app> [-t] Show the nginx access logs for an application (-t follows)
nginx:build-config <app> (Re)builds nginx config for given app
nginx:disable <app> Disable nginx for an application (forces container binding to external interface)
nginx:enable <app> Enable nginx for an application
nginx:error-logs <app> [-t] Show the nginx error logs for an application (-t follows)
```
## Customizing the nginx configuration
> New as of 0.3.10.
Dokku currently templates out an nginx configuration that is included in the `nginx-vhosts` plugin. If you'd like to provide a custom template for your application, there are a few options:
- Copy the existing pertinent (ssl or non-ssl) template found (by default) in `/var/lib/dokku/plugins/available/nginx-vhosts/templates`, place it either in `/home/dokku/APP` or check it into the root of your app repo, and name it one of the following:
> If placed on the dokku server, the template file **must** be owned by user and group `dokku:dokku`.
For instance - assuming defaults - to customize the nginx template in use for the `myapp` application, create the file `nginx.conf.template` in your repo or on disk with the with the following contents:
```
server {
listen [::]:80;
listen 80;
server_name $NOSSL_SERVER_NAME;
access_log /var/log/nginx/${APP}-access.log;
error_log /var/log/nginx/${APP}-error.log;
# set a custom header for requests
add_header X-Served-By www-ec2-01;
location / {
proxy_pass http://$APP;
proxy_http_version 1.1;
proxy_set_header Upgrade \$http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host \$http_host;
proxy_set_header X-Forwarded-Proto \$scheme;
proxy_set_header X-Forwarded-For \$remote_addr;
proxy_set_header X-Forwarded-Port \$server_port;
proxy_set_header X-Request-Start \$msec;
}
include $DOKKU_ROOT/$APP/nginx.conf.d/*.conf;
}
```
The above is a sample http configuration that adds an `X-Served-By` header to requests.
A few tips for custom nginx templates:
- Special characters - dollar signs, spaces inside of quotes, etc. - should be escaped with a single backslash or can cause deploy failures.
- Templated files will be validated via `nginx -t`.
- Application environment variables can be used within your nginx configuration.
After your changes a `dokku deploy myapp` will regenerate the `/home/dokku/myapp/nginx.conf` file which is then used.
### Customizing via configuration files included by the default templates
The default nginx.conf- templates will include everything from your apps `nginx.conf.d/` subdirectory in the main `server {}` block (see above):
```
include $DOKKU_ROOT/$APP/nginx.conf.d/*.conf;
```
That means you can put additional configuration in separate files, for example to limit the uploaded body size to 50 megabytes, do
Applications typically have the following structure for their hostname:
```
scheme://subdomain.domain.tld
```
The `subdomain` is inferred from the pushed application name, while the `domain` is set during initial configuration in the `$DOKKU_ROOT/VHOST` file.
You can optionally override this in a plugin by implementing the `nginx-hostname` plugin trigger. For example, you can reverse the subdomain with the following sample `nginx-hostname` plugin trigger:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";SUBDOMAIN="$2";VHOST="$3"
NEW_SUBDOMAIN=`echo$SUBDOMAIN| rev`
echo"$NEW_SUBDOMAIN.$VHOST"
```
If the `nginx-hostname` has no output, the normal hostname algorithm will be executed.
You can also use the built-in `domains` plugin to handle:
### Disabling VHOSTS
If desired, it is possible to disable vhosts by setting the environment variable `NO_VHOST=1`:
```shell
dokku config:set myapp NO_VHOST=1
```
On subsequent deploys, the nginx virtualhost will be discarded. This is useful when deploying internal-facing services that should not be publicly routeable. As of 0.4.0, nginx will still be configured to proxy your app on some random high port. This allows internal services to maintain the same port between deployments. You may change this port by setting `DOKKU_NGINX_PORT` and/or `DOKKU_NGINX_SSL_PORT` (for services configured to use SSL.)
### Domains plugin
> New as of 0.3.10
```shell
domains:add <app> DOMAIN Add a custom domain to app
domains <app> List custom domains for app
domains:clear <app> Clear all custom domains for app
domains:remove <app> DOMAIN Remove a custom domain from app
```
The domains plugin allows you to specify custom domains for applications. This plugin is aware of any ssl certificates that are imported via `nginx:import-ssl`. Be aware that setting `NO_VHOST` will override any custom domains.
Custom domains are also backed up via the built-in `backup` plugin
```shell
# where `myapp` is the name of your app
# add a domain to an app
dokku domains:add myapp example.com
# list custom domains for app
dokku domains myapp
# clear all custom domains for app
dokku domains:clear myapp
# remove a custom domain from app
dokku domains:remove myapp example.com
```
## Container network interface binding
> New as of 0.3.13
The deployed docker container running your app's web process will bind to either the internal docker network interface (i.e. `docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CONTAINER_ID`) or an external interface (i.e. 0.0.0.0) depending on dokku's VHOST configuration. Dokku will attempt to bind to the internal docker network interface unless you specifically set NO_VHOST for the given app or your dokku installation is not setup to use VHOSTS (i.e. $DOKKU_ROOT/VHOST is missing or $DOKKU_ROOT/HOSTNAME is set to an IPv4 or IPv6 address)
```shell
# container bound to docker interface
root@dokku:~/dokku# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1b88d8aec3d1 dokku/node-js-app:latest "/bin/bash -c '/star About a minute ago Up About a minute goofy_albattani
# container bound to all interfaces (previous default)
root@dokku:/home/dokku# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6499edb0edb dokku/node-js-app:latest "/bin/bash -c '/star About a minute ago Up About a minute 0.0.0.0:49153->5000/tcp nostalgic_tesla
```
## Default site
By default, dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration. This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
```
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 410;
log_not_found off;
}
```
You may also wish to use a separate vhost in your `/etc/nginx/sites-enabled` directory. To do so, create the vhost in that directory as `/etc/nginx/sites-enabled/00-default.conf`. You will also need to change two lines in the main `nginx.conf`:
```
# Swap both conf.d include line and the sites-enabled include line. From:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
# to the following
include /etc/nginx/sites-enabled/*;
include /etc/nginx/conf.d/*.conf;
```
Alternatively, you may push an app to your dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
## Running behind a load balancer
See the [load balancer documentation](/dokku/deployment/ssl-configuration/#running-behind-a-load-balancer).
## HSTS Header
See the [HSTS documentation](/dokku/deployment/ssl-configuration/#hsts-header).
## SSL Configuration
See the [ssl documentation](/dokku/deployment/ssl-configuration/).
Dokku itself is built out of plugins and uses [plugn](https://github.com/dokku/plugn) for its plugin system. In essence a plugin is a collection of scripts that will be run based on naming convention.
Let's take a quick look at the current dokku nginx plugin that's shipped with dokku by default.
nginx-vhosts/
├── plugin.toml # plugin metadata
├── commands # contains additional commands
├── install # runs on dokku installation
└── post-deploy # runs after an app is deployed
## Installing a plugin
```shell
# This command requires `root` permissions as the `install` and `install-dependencies`
# plugin triggers may utilize commands such as `apt-get`. For non-core plugins, please
# inspect those plugins before running the following command as `root` user.
sudo dokku plugin:install <git_url>
# previous versions (0.3.x and below) of dokku require a manual process to install plugins
cd /var/lib/dokku/plugins
git clone <git url>
dokku plugins-install
```
## Creating your own plugin
[See the full documentation](http://dokku.viewdocs.io/dokku/development/plugin-creation).
## Official Plugins (Beta)
The following plugins are available and provided by dokku maintainers. Where noted, these plugins should be considered beta software and may not have been used as thoroughly as community plugins. Please file issues against their respective issue trackers.
<sup>1</sup> On Heroku similar functionality is offered by the [heroku-labs pipeline feature](https://devcenter.heroku.com/articles/labs-pipelines), which allows you to promote builds across multiple environments (staging -> production)
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>1</sup> Forked from [jezdez/dokku-elasticsearch-plugin](https://github.com/jezdez/dokku-elasticsearch-plugin): uses Elasticsearch 1.2 (instead of 0.90), doesn't depend on dokku-link, runs as elasticsearch user instead of root, and turns off multicast autodiscovery for use in a VPS environment.
### Deprecated Plugins
The following plugins have been removed as their functionality is now in Dokku Core.
| [PostgreSQL (single container)](https://github.com/jeffutter/dokku-postgresql-plugin) | [jeffutter][] | This plugin creates a single postgresql container that all your apps can use. Thus only one instance of postgresql running (good for servers without a ton of memory). |
| [RiakCS (single container)](https://github.com/jeffutter/dokku-riakcs-plugin) | [jeffutter][] | Incompatible with 0.2.0 (checked at [dccee02][]) |
Dokku supports rudimentary process (really container) management via the `ps` plugin.
```
ps <app> List processes running in app container(s)
ps:rebuildall Rebuild all apps
ps:rebuild <app> Rebuild an app
ps:restartall Restart all deployed app containers
ps:restart <app> Restart app container(s)
ps:scale <app> <proc>=<count> [<proc>=<count>] Set how many processes of a given process to run
ps:start <app> Start app container(s)
ps:stop <app> Stop app container(s)
```
## Scaling
Dokku allows you to run multiple process types at different container counts. For example, if you had an app that contained 1 web app listener and 1 background job processor, dokku can, spin up 1 container for each process type defined in the Procfile. *By default, dokku will only start a single web process (if defined.)* However, if you wanted, for example, 2 job processors running simultaneously, you can modify this behavior in one of the following ways.
### DOKKU_SCALE file
You can optionally create a `DOKKU_SCALE` file in the root of your repository. Dokku expects this file to contain one line for every process defined in your Procfile.
Example:
```
web=1
worker=2
```
### `ps:scale` command
Dokku can also manage scaling itself via the `ps:scale` command. This command can be used to scale multiple process types at the same time.
```
dokku ps:scale app_name web=1 worker=2
```
*NOTE*: Dokku will always use the DOKKU_SCALE file that ships with the repo to override any local settings.
## The web proctype
Like Heroku, we handle the `web` proctype differently from others. The `web` proctype is the only proctype that will invoke custom checks as defined by a CHECKS file. It is also the only proctype that will be launched in a container that is either proxied via nginx or bound to an external port.
Dokku commands can be run over ssh. Anywhere you would run `dokku <command>`, just run `ssh -t dokku@dokku.me <command>`
The `-t` is used to request a pty. It is highly recommended to do so.
To avoid the need to type the `-t` option each time, simply create/modify a section in the `.ssh/config` on the client side, as follows:
```
Host dokku.me
RequestTTY yes
```
## Behavioral modifiers
Dokku also supports certain command-line arguments that augment it's behavior. If using these over ssh, you must use the form `ssh -t dokku@dokku.me -- <command>`
in order to avoid ssh interpretting dokku arguments for itself.
```shell
--quiet suppress output headers
--trace enable DOKKU_TRACE for current execution only
--rm|--rm-container remove docker container after successful dokku run <app> <command>
--force force flag. currently used in apps:destroy and other ":destroy" commands
```
## Clients
You may optionally use a client to connect to your dokku server. Most clients use the configured `git remote` to locate the dokku server, though some allow for overriding this via an environment variable or flag.
Please refer to the [clients](/dokku/community/clients/) list for more details.
The `remote rejected` error does not give enough information. Anything could have failed.
To enable dokku tracing, simply run the following command:
# Since 0.3.9
dokku trace on
In versions older than 0.3.9, you can create a `/home/dokku/dokkurc` file containing the following :
export DOKKU_TRACE=1
This will trace all of dokku's activity. If this does not help you, create a [gist](https://gist.github.com) containing the full log, and create an issue.
***
__Symptom:__ I get the aforementioned error in the build phase (after turning on dokku tracing)
Most errors that happen in this phase are due to transient network issues (either locally or remotely) buildpack bugs.
__Solution (Less solution, more helpful troubleshooting steps):__
Find the failed phase's container image (*077581956a92* in this example)
```
root@dokku:~# docker ps -a | grep build
94d9515e6d93 077581956a92 "/build" 29 minutes ago Exited (0) 25 minutes ago cocky_bell
```
Start a new container with the failed image and poke around (i.e. ensure you can access the internet from within the container or attempt the failed command, if known)
```
root@dokku:~# docker run -ti 077581956a92 /bin/bash
Sometimes (especially on DO) deploying again seems to get past these seemingly transient issues
Additionally we've seen issues if changing networks that have different DNS resolvers. In this case, you can run the following to update your resolv.conf
```
root@dokku:~# resolvconf -u
```
Please see https://github.com/dokku/dokku/issues/841 and https://github.com/dokku/dokku/issues/649
***
__Symptom:__ I want to deploy my app but I am getting asked for the password of the git user and the error message
fatal: 'NAME' does not appear to be a git repository
fatal: Could not read from remote repository.
__Solution:__
You get asked for a password because your ssh secret key can't be found. This may happen if the private key corresponding to the public key you added with `sshcommand acl-add` is not located in the default location `~/.ssh/id_rsa`.
You have to point ssh to the correct secret key for your domain name. Add the following to your `~/.ssh/config`:
Host DOKKU_HOSTNAME
IdentityFile "~/.ssh/KEYNAME"
Also see [issue #116](https://github.com/dokku/dokku/issues/116)
***
__Symptom:__ I successfully deployed my application with no deployment errors and receiving Bad Gateway when attempting to access the application
__Solution:__
In many cases the application will require the a `process.env.PORT` port opposed to a specified port.
When specifying your port you may want to use something similar to:
var port = process.env.PORT || 3000
Please see https://github.com/dokku/dokku/issues/282
***
__Symptom:__ Deployment fails because of slow internet connection, messages shows `gzip: stdin: unexpected end of file`
it might that the curl command that is supposed to fetch the buildpack (anything in the low megabyte file size range) takes too long to finish, due to slowish connection. To overwrite the default values (connection timeout: 3 seconds, total maximum time for operation: 30 seconds), set the following environment variables:
This document covers upgrades for the 0.3.0 series and up. If upgrading from older versions, we recommend [a fresh install](http://dokku.viewdocs.io/dokku/installation) on a new server.
> As of 0.3.18, dokku is installed by default via a debian package. Source-based installations are still available, though not recommended.
## Dokku
If dokku was installed via a debian package, you can upgrade dokku via the following command:
```shell
sudo apt-get install dokku
```
For unattended upgrades, you may run the following command:
```shell
sudo apt-get install -qq -y dokku
```
If you have installed dokku from source, you may run the following commands to upgrade:
```shell
cd ~/dokku
git pull --tags origin master
# continue to install from source
sudo DOKKU_BRANCH=master make install
# upgrade to debian package-based installation
sudo make install
```
All changes will take effect upon next application deployment. To trigger a rebuild of every application, simply run the following command:
```shell
dokku ps:rebuildall
```
## Herokuish image
If dokku was installed via a debian package, you can upgrade herokuish via the following command:
```shell
sudo apt-get install herokuish
```
For unattended upgrades, you may run the following command:
```shell
sudo apt-get install -qq -y herokuish
```
In some cases, it may be desirable to run a specific version of herokuish. To install/upgrade herokuish from source, run the following commands:
echo "\nTo avoid cli-based dokku configuration, use the web installer"
echo "Debian-based installs should have this running and available"
echo "on port 80. You can also install it via the following commands:"
echo ""
echo " cd /root/dokku"
echo " sudo make dokku-installer\n"
fi
EOF
chmod +x /etc/update-motd.d/99-dokku
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.