- unified css between home and template layouts
- use same version of bootstrap everywhere
- add our cute whale sushi logo to the homepage
- use fewer styles
- add a better installation section to point out different installation methods
- add navigation bar items
[ci skip]
- Tone down "new as of version" boxes
- Replace all "New as of 0.5" with "yet to be released" text
- Use strong red only for "yet to be released" boxes
Fixes#1989
- Briefly cover sshcommand internals
- Show several examples for using sshcommand
- Split out docs onto a new page and relink to it where necessary
- Refer to user-auth plugin trigger for scoping commands to specific users.
[ci skip]
This will allow a user to browse the documentation as it was at any point in time. In doing so, this allows us to more easily deprecate/remove features without worrying about having to duplicate old documentation in the future.
[ci skip]
- Refer to checks plugin in zero-downtime deploy link
- Refer to cron in one off processes link
- Add an "Advanced Usage" section
- Add links to proxy management and deployment tasks
- Move container options and persistent storage to advanced usage
[ci skip]
This change sets a DOKKU_APP_NAME env var, which can be used by plugins as a replacement for the `app` param if specified. Note that each plugin will have to manually shift it's arguments if necessary
* fix rsyslog handling
* don't hardcode dokku path
* add documentation for ArchLinux package build
* add vagrant machine to run the ArchLinux specific steps
* add step in release process for ArchLinux
* enhance docs for easy ArchLinux steps
This pr makes it slightly easier to support dockerfile installations
- "simplifies" the bootstrap process by dividing it into distinct chunks
- Allows specifying `--no-install-recommends` when a dockerfile installation is detected
- Uses functions everywhere
- Removes global variables where possible
- Fixes shellcheck issues
- Allows specifying debconf via the command-line
[ci skip]
There are cases where we don't want the check for keyfile, this will add a
config option, that allows you to skip this particular check.
Fixes#1851
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
OSX creates hidden files: `./._server.key` and `./._server.crt`. The Dokku cert
plugin is choking on those files. We should probably just ignore them, and go on
with our lives
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
I was running into issues with the IP addresses, and it seems
that it's using an incorrect/outdated syntax for retrieving
the container's IP Address. In multi-host networking
`NetworkSettings.IPAddress` is empty.
The docker documentation at https://docs.docker.com/engine/reference/commandline/inspect/
uses a different syntax which I've tested to work both on multi-host and
standard bridge networking.
If you're interested in the other issues and the work/hacks I've been doing related
to #1795, let me know. In the meantime, I think this fix is needed.
- remove deployed applications during dpkg purge
- disable all core plugins during dpkg purge
- ensure init files are removed
- ensure motd is removed
- remove all core plugins, dokku config files (including tls/sshcommand entries etc.) during purge
- remove all empty directories and broken symlinks in the DOKKU_ROOT and DOKKU_LIB_ROOT directories during purge
Note that we do not delete the dokku user itself as there might be other data we don't know about in this directory.
We previously assumed that systemd was detectable by the existence of certain directories. Unfortunately, it seems 14.04 already has these directories, so we need to handle this case separately.
One other note is that dokku-installer will fail to "start" if already started on certain systems, thus the previous grep was more accurate in it's running.
- Use the nginx.conf file's existence as a check for whether we should start the service or not
- Create the init files with the dokku-installer.py file. This adds actual systemd support.
- Also ensure we *always* start the service, regardless of it's status. This fixes an issue with processing systemd output
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 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.
2014-08-16 19:05:20 -07:00
445 changed files with 16727 additions and 2035 deletions
-`docker run -ti gliderlabs/herokuish:latest herokuish version`:
-`dokku version`:
-`dokku plugin`:
-`docker inspect CONTAINER_ID` (if applicable):
(BEWARE: `docker inspect` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX):
- Link to the exact repository being deployed (if possible/applicable):
- If a deploy is failing:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- Whether or not you have a `Dockerfile` in the root of your repository
- If using buildpacks, which custom buildpacks are in use
- If it exists, the contents of your `Procfile`.
- Output of failing dokku commands after running `dokku trace on`
(BEWARE: `trace on` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX):
[View the docs for upgrading](http://dokku.viewdocs.io/dokku/upgrading) from an older version of Dokku.
## Documentation
Full documentation - including advanced installation docs - are available online at [docs](http://progrium.viewdocs.io/dokku/index)
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](https://webchat.freenode.net/?channels=%23dokku)
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)
## Contribution
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.
While we may not merge your PR as is, they serve to start conversations and improve the general dokku experience for all users.
## Sponsors
@@ -26,4 +37,4 @@ Dokku is currently sponsored by the enterprise grade, multi-host PaaS project [D
<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:
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:
```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:
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.
```shell
git clone https://github.com/dokku/dokku.git
cd dokku
sudo BUILD_STACK=trueSTACK_URL=https://github.com/gliderlabs/herokuish.git make install
```
## Configuring
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).
Follow the [user management documentation](/dokku/deployment/user-management) in order to add users to dokku.
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:
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.
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.
Dokku only supports deploying from its master branch, so if you'd like to deploy a different local branch use: ```git push progrium <local branch>:master```
Create the application on the Dokku host. You will need to ssh onto the host to run this command.
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.
## Specifying a custom buildpack
If buildpack detection isn't working well for you or you want to specify a custom buildpack for one repository you can create & commit a file in the root of your git repository named `.env` containing `export BUILDPACK_URL=<repository>` before pushing. This will tell buildstep to fetch the specified buildpack and use it instead of relying on the built-in buildpacks & their detection methods.
## Default vhost
You might notice the default vhost for Nginx will be one of the apps. If an app doesn't exist, it will use this vhost and it may be confusing for it to go to another app. You can create a default vhost using a configuration under `sites-enabled`. You just have to change one thing 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
```
include /etc/nginx/sites-enabled/*;
include /etc/nginx/conf.d/*.conf;
```shell
# on your dokku host
dokku apps:create ruby-rails-sample
```
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.
### 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
# on your dokku host
# 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
# on your dokku host
# 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
# on your dokku host
# 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
# on your dokku host
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.
### Deploying non-master branch
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.
```bash
dokku delete myapp
```
As of 0.5.x, this function removes all containers with the label `dokku` where the status is either `dead` or `exited`, as well as all `dangling` images. Previous versions would remove `dead` or `exited` containers, regardless of their label.
### Adding deploy users
See the [user management documentation](/dokku/deployment/user-management).
## Default vhost
See the [nginx documentation](/dokku/nginx/#default-site).
## Dockerfile deployment
See the [dockerfile documentation](/dokku/deployment/dockerfiles/).
### Specifying a custom buildpack
See the [buildpack documentation](/dokku/deployment/buildpacks/).
## Image tagging
See the [image tagging documentation](/dokku/deployment/images).
## Zero downtime deploy
See the [zero-downtime deploy documentation](/dokku/checks-examples/).
> The backup plugin was deprecated in 0.4.x, below are backup recommendations for 0.5.x and later.
## Backup and Migration Tutorial
Because Dokku is git based, rebuilding a deployed app is as easy as pushing from git. You can push to a new server by updating the dokku remote in you local app's repo.
```
$ git remote rm dokku
$ git remote add dokku dokku@[dokku.me:dokku.me]
$ git push dokku [master]
```
## Databases
Some plugins, like the official [dokku-postgres] plugin, have built-in commands that allow non-volatile data be exported and imported.
For [dokku-postgres], use:
```
dokku postgres:export [db_name] > [db_name].dump
dokku postgres:import [db_name] < [db_name].dump
```
## Volumes and Static Assets
Dokku doesn't enforce a [300mb] limit on apps, but it's best practice to keep binary assets outside of git. Since containers are considered volatile in Dokku, external stores like s3 or storage mounts should be used for non-volatile items like user uploads. The dokku storage core plugin can be used to mount local directories / volumes inside the docker container.
```
storage:list <app>, List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir>, Create a new bind mount
storage:unmount <app> <host-dir:container-dir>, Remove an existing bind mount
```
## Disaster Recovery
The best plan for disaster recovery is to always keep multiple (remote) copies of your local repo, static assets and periodic database dumps. In case of an emergency when your git repo and backups are completely lost, you can recover the last pushed copy from your remote dokku server (assuming you still have the ssh key).
Following a deploy, dokku will wait `10` seconds before routing traffic to the new container to give your application time to boot up. If the application is not running after this time, then the deploy is failed and your old container will continue serving traffic. You can modify this value globally or on a per-application basis:
You can also choose to skip checks completely on a per-application basis:
```shell
dokku checks:disable <app>
```
Dokku will wait `60` seconds before stopping the old container so that existing connections are given a chance to complete. You can modify this value globally or on a per-application basis:
> 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.
## Checks
If your application needs a longer period to boot up - perhaps to load data into memory, or because of slow boot time - you may also use dokku's `checks` functionality to more precisely check whether an application can serve traffic or not.
To specify checks, add a `CHECKS` file to the root of your project directory. The `CHECKS` file should be plain text and may contain:
* Check instructions
* Settings (NAME=VALUE)
* Comments (lines starting with #)
* Empty lines
> For dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check Instructions
The format of a check instruction is a path or relative URL, optionally followed by the expected content:
```
/about Our Amazing Team
```
The `CHECKS` file can contain multiple checks:
```
/ 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:
```
//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
```
### Check Settings
The default behavior is to wait for `5` seconds before running the checks, to timeout the checks after `30` seconds, and to attempt the checks `5` times. If the checks fail `5` times, the deployment is considered failed and the old container will continue serving traffic.
You can change the default behavior by setting `WAIT`, `TIMEOUT`, and `ATTEMPTS` to different values in the `CHECKS` file:
```
WAIT=30 # Wait 1/2 minute
TIMEOUT=60 # Timeout after a minute
ATTEMPTS=10 # Attempt checks 10 times
/ My Amazing App
```
You can also override the default `WAIT`, `TIMEOUT`, and `ATTEMPTS` variables for the global dokku installation:
If your application runs multiple processes (a background worker configured in your `Procfile`, for example) and you have checks to ensure that your web application has booted up, you may want to disable the default check wait time for that application to avoid the `10` second wait per non-web process:
In this example, a Rails application is successfully deployed to dokku. The initial round of checks fails while the server is starting, but once it starts they succeed and the deployment is successful. `WAIT` is set to `10` because our application takes a while to boot up. `ATTEMPTS` is set to `6`, but the third attempt succeeds.
### CHECKS file
````
WAIT=10
ATTEMPTS=6
/check.txt simple_check
````
For this check to work, we've added a line to `config/routes.rb` that simply returns a string:
````
get '/check.txt', to: proc {[200, {}, ['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 10 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 10 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 10 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=10
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 10 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 10 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 10 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 10 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 10 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 10 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
# optional: make sure that the dokku_client.sh version matches your dokku version
cd ~/.dokku
git checkout <tag/branch>
# 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.
You can also configure a `DOKKU_PORT` environment variable if you are running ssh on a non-standard port. This defaults to `22`.
## (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> - 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
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 by default available only at run time, i.e. not when the application is being built/compiled. However there are [plugins](http://progrium.viewdocs.io/dokku/plugins) that can change that.
The variables are available both at run time and during the application build/compilation step for buildpack-based deploys. For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available *only* during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860).
> 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
# example: using a specific ruby buildpack version
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:
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
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:
Sometimes you need to run a command on at deployment time, but before an app is completely deployed.
Common use cases include:
* Checking a database is initialised
* Running database migrations
* Any commands required to set up the server (e.g. something like a Django `collectstatic`)
## `app.json` and `scripts.dokku`
Dokku accomplishes this by using an `app.json` file. We (mostly) use the same format as Heroku's [app.json](https://devcenter.heroku.com/articles/app-json-schema).
However, dokku currently only supports the nodes `scripts.dokku.predeploy` and `scripts.dokku.postdeploy`.
Simply place an `app.json` file in the root of your repository or for dockerfile apps, `ADD` it to /app.
>NOTE: postdeploy changes are *NOT* committed to the app image.
### Example app.json
```
{
"name": "barebones nodejs",
"description": "A barebones Node.js app using Express 4.",
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`.
### Procfiles and Multiple Processes
> New as of 0.5.0
You can also customize the run command using a `Procfile`, much like you would on Heroku or
with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process
types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types).
When you deploy your app a Docker image will be built, the `Procfile` will be extracted from the image
(it must be in the folder defined in your `Dockerfile` as `WORKDIR` or `/app`) and the commands
in it will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
```
web: bin/run-prod.sh
worker: bin/run-worker.sh
```
And `Dockerfile`:
```
FROM debian:jessie
WORKDIR /app
COPY . ./
CMD ["bin/run-dev.sh"]
```
When you deploy this app the `web` process will automatically be scaled to 1 and your Docker container
will be started basically using the command `docker run bin/run-prod.sh`. If you want to also run
a worker container for this app, you can run `dokku ps:scale worker=1` and a new container will be
started by running `docker run bin/run-worker.sh` (the actual `docker run` commands are a bit more
complex, but this is the basic idea). If you use an `ENTRYPOINT` in your `Dockerfile`, the lines
in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instead of being executed.
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.
- Use the dokku user's crontab
- If you do not, dokku will attempt to execute with sudo dokku, and your cron run with fail with `sudo: no tty present and no askpass program specified`
- 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
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 using the following [nginx custom template](/dokku/nginx/#customizing-the-nginx-configuration)
include {{ .DOKKU_ROOT }}/{{ .APP }}/nginx.conf.d/*.conf;
upstream {{ .APP }}{
{{ range .DOKKU_APP_LISTENERS | split " "}}
server {{ . }};
{{ end }}
}
}
```
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.
While it is possible to use password-based authorization to push to Dokku, it is preferable to use key-based authentication for security.
Users in dokku are managed via the `~/dokku/.ssh/authorized_keys` file. While you *can* manually edit this file, it is **highly** recommended that you follow the below steps to manage users on a dokku server.
## SSHCommand
Dokku uses the [`sshcommand`](https://github.com/dokku/sshcommand) utility to manage ssh keys for the dokku user. The following is the usage output for sshcommand.
```
sshcommand create <user> <command> # creates a user forced to run command when SSH connects
sshcommand acl-add <user> <ssh-key-name> # adds named SSH key to user from STDIN
sshcommand acl-remove <user> <ssh-key-name> # removes SSH key by name
sshcommand help # displays the usage help message
```
In dokku's case, the `<user>` section is *always*`dokku`, as this is the system user that the dokku binary performs all it's actions. Keys are given unique names, which can be used in conjunction with the [user-auth](/dokku/development/plugin-triggers/#user-auth) plugin trigger to handle command authorization.
## Adding deploy users
You can add your public key to the dokku user's `~/dokku/.ssh/authorized_keys` file with the following command:
```shell
# from your local machine
# replace dokku.me with your domain name or the host's IP
# replace root with your server's root user
# USER is the username you use to refer to this particular key
At it's base, the `sshcommand`*must* be run under a user with sudo access, as it sets keys for the dokku user.
For instance, if you stored your public key at `~/.ssh/id_rsa.pub-open` and are deploying to EC2 where the default root-enabled user is `ubuntu`, you can run the following command to add your key under the `superuser` username:
If you are using the vagrant installation, you can also use the `make vagrant-acl-add` target to add your public key to dokku (it will use your host username as the `USER`):
```
cat ~/.ssh/id_rsa.pub | make vagrant-acl-add
```
## Scoping commands to specific users
See the [user auth plugin trigger documentation](/dokku/development/plugin-triggers/#user-auth).
[[ -z $2]]&&echo"Please specify an app to run the command on"&&exit1
verify_app_name "$2"
localAPP="$2";
echo"Hello world"
}
hello_world_cmd "$@"
```
hello/commands
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
case"$1" in
help| hello:help)
help_content_func (){
declaredesc="return help_content string"
cat<<help_content
hello <app>, Says "Hello <app>"
hello:world, Says "Hello world"
help_content
}
if[[$1="hello:help"]];then
echo -e 'Usage: dokku hello[:world] [<app>]'
echo''
echo'Say Hello World.'
echo''
echo'Example:'
echo''
echo'$ dokku hello:world'
echo'Hello world'
echo''
echo'Additional commands:'
help_content_func | sort | column -c2 -t -s,
else
help_content_func
fi
;;
*)
exit$DOKKU_NOT_IMPLEMENTED_EXIT
;;
esac
```
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](/dokku/development/plugin-triggers) doc for examples.
- As of 0.5.0, we use container labels to help cleanup intermediate containers with `dokku cleanup`. If manually calling `docker run`, include `$DOKKU_GLOBAL_RUN_ARGS`. This will ensure you intermediate containers labeled correctly.
[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/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
```
### `comands help` and `commands <PLUGIN_NAME>:help`
- Description: Your plugin should implement a `help` command in your `commands` file to take advantage of this plugin trigger. `commands help` is used by `dokku help` to aggregate all plugins abbreviated `help` output. Implementing `<PLUGIN_NAME>:help` in your `commands` file gives users looking for help, a more detailed output. 'commands help' must be implemented inside the `commands` plugin file. It's recommended that `PLUGIN_NAME:help` be added to the commands file to ensure consistency among community plugins and give you a new avenue to share rich help content with your user.
- Invoked by: `dokku help` and `commands <PLUGIN_NAME>: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| hello:help)
help_content_func (){
declaredesc="return help_content string"
cat<<help_content
hello <app>, Says "Hello <app>"
hello:world, Says "Hello world"
help_content
}
if[[$1="hello:help"]];then
echo -e 'Usage: dokku hello[:world] [<app>]'
echo''
echo'Say Hello World.'
echo''
echo'Example:'
echo''
echo'$ dokku hello:world'
echo'Hello world'
echo''
echo'Additional commands:'
help_content_func | sort | column -c2 -t -s,
else
help_content_func
fi
;;
*)
exit$DOKKU_NOT_IMPLEMENTED_EXIT
;;
esac
```
### `pre-build-buildpack`
- 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 $DOKKU_GLOBAL_RUN_ARGS -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 $DOKKU_GLOBAL_RUN_ARGS -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:
- Update all blockquote references of `not yet released and only available in master` to point to release version.
- 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 or added to the `docs/assets/versions.json` 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.
- ArchLinux package description *must* be updated via `vagrant up build-arch` (needs to be done after the tag is pushed to GitHub, because it is based on that)
## 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.
## ArchLinux Packages
ArchLinux packages are not really build, because all that is needed for an Arch User Repo (AUR) package is the description of how to build the package. To make this process as easy as possible there is a vagrant box called `build-arch` that updates the version of this build description (a file called `PKGBUILD`), then runs some helper scripts to fill all additional information and does test if the package could be build. Then only those changes need to be pushed to the AUR repo and an updated version of the package is ready for usage for our ArchLinux users. For detailed information see the section below.
The workflow looks like this:
```shell
# having dokku-arch in ../dokku-arch
vagrant up build-arch
# wait for "==> build-arch: ==> Finished making: dokku 0.5.0-2 (Mon Feb 22 23:20:37 CET 2016)"
cd ../dokku-arch
git add PKGBUILD .SRCINFO
git commit -m 'Update to dokku 0.9.9'
git push aur master
```
> If you are a maintainer and need access to the AUR repositories in order to make a release, please contact @morrisjobke or @josegonzalez to get this co-maintainership.
## 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.
### New Features
- #SOME_ID: @pull-request-creator Description
### Bug Fixes
- #SOME_ID: @pull-request-creator Description
### Docs Changes
- #SOME_ID: @pull-request-creator Description
```
## Detailed information for ArchLinux packages
All of the information to build the ArchLinux package is in the AUR git repository (see [dokku AUR page](https://aur.archlinux.org/packages/dokku/)). The release of a AUR package only consists of pushing the package information into the AUR git repo. Then users could use that information to build the package on their machines.
To update the package clone the repository and adjust the files in the repository. Then a helper script - `updpkgsums` - to update the SHA sum could be called (check against the original SHA sum). Another helper script - `mksrcinfo` - needs to be called to update the meta information of the package in a file called `.SRCINFO`. The next step builds the package locally for verification - `makepkg`. As last step commit your changes and push the commit.
* dependencies are defined in the `depends` attribute in `PKGBUILD`
* build steps during package build time are defined in the `package()` method in `PKGBUILD`
* steps that should be executed during install/update/remove time are defined in the file `dokku.install`
* detailed information about all attributes in `PKGBUILD` could be found in the [ArchLinux wiki](https://wiki.archlinux.org/index.php/PKGBUILD)
* detailed information about the AUR workflow could be found in the [AUR article](https://wiki.archlinux.org/index.php/Arch_User_Repository) in the ArchLinux wiki
That is the usual workflow:
```shell
updpkgsums # update sha sums - compare them with the original ones
mksrcinfo # update package metadata for AUR
makepkg # test package builds
git add PKGBUILD .SRCINFO
git commit -m 'Update to dokku 0.9.9'
git push
```
> If there is something unclear simply ask @morrisjobke for help.
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](/dokku/getting-started/install/vagrant)
- Test setup and execution
```shell
$ vagrant ssh
$ sudo su -
$ cd ~/dokku
$ make ci-dependencies setup-deploy-tests
$ make test # execute the entire test suite (linter, bats tests, and app deployment tests)
$
$ make lint copyfiles # run linter & update vagrant dokku install from local git clone
$ make unit-tests # execute all bats tests
$ make deploy-tests # execute all 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
### 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
### 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/progrium/dokku/blob/master/README.md) to get dokku installed. Don't do the install just yet though.
* 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!
### HELP!
Don't be afraid to ask if you need help. Create a [new issue](https://github.com/progrium/dokku/issues) and someone will be glad to assist you.
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'.
For the examples, we will use the domain name `example.tld` and the IP address `127.0.0.1`.
Dokku uses a 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'.
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 in to it and run 'ifconfig' or 'ip addr' to see the IP address.
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.
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?
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?
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.
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.
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.
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:
@@ -55,28 +55,25 @@ $ORIGIN example.tld
$TTL 5m
myserver IN A 127.0.0.1
*.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
*`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:
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 test.myserver.example.tld`
*`host xyzzy.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.
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/progrium/dokku/blob/master/README.md)
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)
@@ -84,5 +81,5 @@ 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
* 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`:
The preferred method to mount external containers to a dokku managed container, is to use the dokku storage plugin.
```shell
storage:list <app>, List bind mounts for app's container(s)(host:container)
storage:mount <app> <host-dir:container-dir>, Create a new bind mount
storage:unmount <app> <host-dir:container-dir>, Remove an existing bind mount
```
## Ideology and Background
The storage plugin requires explicit paths on the host side. This is intentional to ensure that new users avoid running into unexpected results with implicit paths that may not exist (a feature deprecate in [Docker 1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0])). The container directory is created for the mount point in the container. Any existing directory contents are not accessible after a mount is added to the container. Dokku creates a new directory `/var/lib/dokku/data/storage` during installation, it's the general consensus that new users should use this directory. Mounts are only available at run and deploy times, you must redeploy (restart) an app to mount or unmount to an existing app's container.
## Usage
This example demonstrates how to mount the recommended directory to `/storage` inside the container:
Dokku will then mount the shared contents of`/var/lib/dokku/storage` to `/storage` inside the container.
## Use Cases
### Persistent storage
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web applications, like user uploads or large binary assets like images, a directory outside the container should be mounted.
### Shared storage between containers
When scaling your app, you may require a common location to access shared assets between containers, a storage mount can be used in this situation.
### Shared storage across environments
Your app may be used in a cluster that requires containers or resources not running on the same host access your data. Mounting a shared file service (like S3FS or EFS) inside your container will give you great flexibility.
### Backing up
Your app may have services that are running in memory and need to be backed up locally (like a key store). Mount a non ephemeral storage mount will allow backups that are not lost when the app is shut down.
## Docker-Options Note
The storage plugins is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy phase.
- 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://github.com/azure/azure-quickstart-templates/tree/master/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:
| dokku/hostname | string | dokku.me | Hostname, used as vhost domain and for showing app URL after deploy |
| dokku/skip_key_file| boolean | false | Don't check for the existence of the dokku/key_file. Warning: This setting this to true, will require you to manually add an SSH key later on. |
| dokku/key_file | string | /root/.ssh/id_rsa.pub | SSH key to add to the Dokku user (Will be ignored on `dpkg-reconfigure`) |
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](/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.
If you’re stuck, there are a number of places you can get help:
## The Official Dokku Website
[http://dokku.viewdocs.io/dokku](/dokku)
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.
If you’re stumped, give us a holler in the Dokku IRC or Slack channels. 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.
## Stack Overflow
http://stackoverflow.com/
Tag your questions with `dokku` to enable existing users of Stack Overflow to find your questions.
<spanclass="command">echo "deb $SOURCE trusty main" | tee /etc/apt/sources.list.d/dokku.list</span>
</p>
<pclass="line">
<spanclass="path"></span>
<spanclass="prompt">$</span>
<spanclass="command">apt-get update</span>
</p>
<pclass="line">
<spanclass="output"> # install dokku</span>
</p>
<pclass="line">
<spanclass="path"></span>
<spanclass="prompt">$</span>
<spanclass="command">apt-get install dokku</span>
</p>
<pclass="line">
<spanclass="path"></span>
<spanclass="prompt">$</span>
<spanclass="command">dokku plugin:install-dependencies --core <spanclass="output"># run with root!</span></span>
</p>
<pclass="line">
<spanclass="output"> # go to your server's IP and follow the web installer</span>
</p>
</div>
<divclass="shell shell-arch">
<pclass="line">
<spanclass="output"> # install dokku via yaourt</span>
</p>
<pclass="line">
<spanclass="path"></span>
<spanclass="prompt">$</span>
<spanclass="command">yaourt -S dokku</span>
</p>
</div>
</div>
<divclass="alternate-instructions">
<p>Hate <code>curl | bash</code>? See our official <ahref="https://github.com/Azure/azure-quickstart-templates/tree/master/dokku-vm"target="_blank">Azure</a>, <ahref="https://www.digitalocean.com/features/one-click-apps/dokku/"target="_blank">DigitalOcean</a>, and <ahref="/{{NAME}}~{{REF}}/getting-started/install/linode/"target="_blank">Linode</a> instructions.<p>
<p>Still no love? <ahref="https://github.com/dokku/dokku/blob/master/CONTRIBUTING.md"target="_blank">Contributions welcome</a>!</a>
</div>
<!-- START THE FEATURETTES -->
<hrclass="featurette-divider">
<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>
<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>
* **Multi-host.** Not a huge leap, but this isn't the project for it. Have a look at [Deis](http://deis.io/).
* **Multitenancy.** It's ready for it, but again, have a look at [Deis](http://deis.io/).
* **Client app.** Given the constraints, running commands remotely via SSH is fine.
<hr class="featurette-divider">
## Sponsors
<div class="row featurette">
<div class="col-md-7 col-md-push-5">
<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>
Though we love everybody doing open source, we especially love [Deis](http://deis.io/) for sponsoring Dokku.
<hr class="featurette-divider">
<div class="row featurette">
<div class="col-md-7">
<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>
Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice.
Ubuntu 14.04 x64 x64. 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.
To start using Dokku, you'll need a system that meets the following minimum requirements:
## Installing the latest Stable version
- A fresh installation of [Ubuntu 14.04 x64](http://www.ubuntu.com/download/) with the FQDN set <sup>[1]</sup>
- At least `1GB` of system memory <sup>[2]</sup>
To install the latest stable version of dokku, you can run the following bootstrapper command:
You can *optionally* have a domain name pointed at the host's IP, though this is not necessary.
The installation process takes about 5-10 minutes, depending upon internet connection speed.
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).
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.
You'll have to add a public key associated with a username by doing something like this from your local machine:
Once you save your settings, the web admin will self-terminate and you should be able to run or deploy to the dokku installation.
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:
This may take around 5 minutes. Certainly better than the several hours it takes to bootstrap Cloud Foundry.
---
You may also wish to take a look at the [advanced installation](http://progrium.viewdocs.io/dokku/advanced-installation) document for additional installation options.
### Development From Source
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:
Dokku ships with a pre-built version of the [buildstep](https://github.com/progrium/buildstep) component by
default. If you want to build your own version you can specify that with an env
variable.
```bash
git clone https://github.com/progrium/dokku.git
cd dokku
sudo BUILD_STACK=true make install
```
### Install Dokku using Vagrant
- 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/progrium/dokku.git
```
- Setup SSH hosts in your `/etc/hosts`
```
10.0.0.2 dokku.me
```
- Setup SSH Config in `~/.ssh/config`
```
Host dokku.me
Port 2222
```
- Create VM
```
# Optional ENV arguments:
# - `BOX_NAME`
# - `BOX_URI`
# - `BOX_MEMORY`
# - `DOKKU_DOMAIN`
# - `DOKKU_IP`.
vagrant up
```
- 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.
### Installing on Linode
#### Using StackScript
Deploy using the following StackScript:
* https://www.linode.com/stackscripts/view/8552
#### Without StackScript
* Build a Ubuntu 13.04 instance
* Follow these instructions: https://www.linode.com/wiki/index.php/PV-GRUB#Ubuntu_12.04_Precise
* If `apt-get update` no longer works:
* Verify if apt-get is trying to use ipv6 instead of ipv4 (e.g. you read something like "[Connecting to us.archive.ubuntu.com (2001:67c:1562::14)]" and apt-get would not proceed). In that case, follow these instructions: http://unix.stackexchange.com/questions/9940/convince-apt-get-not-to-use-ipv6-method (append "precedence ::ffff:0:0/96 100" to /etc/gai.conf)
* OR: change `/etc/apt/sources.list` to one mentioned in http://mirrors.ubuntu.com/mirrors.txt
- <sup>[1]: To check whether your system has an fqdn set, run `sudo hostname -f`</sup>
- <sup>[2]: If your system has less than 1GB of memory, you can use [this workaround](/dokku/advanced-installation/#vms-with-less-than-1gb-of-memory).</sup>
Dokku uses nginx as it's server for routing requests to specific applications.
## TLS/SPDY support
Dokku provides easy TLS/SPDY support out of the box. This can be done app-by-app or for all subdomains at once. Note that whenever TLS support is enabled SPDY is also enabled.
### Per App
To enable TLS connection to to one of your applications, copy or symlink the `.crt`/`.pem` and `.key` files into the application's `/home/dokku/:app/tls` folder (create this folder if it doesn't exist) as `server.crt` and `server.key` respectively.
Redeployment of the application will be needed to apply TLS configuration. Once it is redeployed, the application will be accessible by `https://` (redirection from `http://` is applied as well).
### All Subdomains
To enable TLS connections for all your applications at once you will need a wildcard TLS certificate.
To enable TLS across all apps, copy or symlink the `.crt`/`.pem` and `.key` files into the `/home/dokku/tls` folder (create this folder if it doesn't exist) as `server.crt` and `server.key` respectively. Then, enable the certificates by editing `/etc/nginx/conf.d/dokku.conf` and uncommenting these two lines (remove the #):
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
```
ssl_certificate /home/dokku/tls/server.crt;
ssl_certificate_key /home/dokku/tls/server.key;
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:error-logs <app> [-t] Show the nginx error logs for an application (-t follows)
```
The nginx configuration will need to be reloaded in order for the updated TLS configuration to be applied. This can be done either via the init system or by re-deploying the application. Once TLS is enabled, the application will be accessible by `https://` (redirection from `http://` is applied as well).
## Customizing the nginx configuration
**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)
> New as of 0.5.0
### HSTS Header
Dokku uses a templating library by the name of [sigil](https://github.com/gliderlabs/sigil) to generate nginx configuration for each app. If you'd like to provide a custom template for your application, there are a couple options:
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.
- Copy the following example template to a file named `nginx.conf.sigil` and either:
- check it into the root of your app repo
-`ADD` it to your dockerfile `WORKDIR`
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.
### Example Custom Template
```
server {
listen [::]:{{ .NGINX_PORT }};
listen {{ .NGINX_PORT }};
server_name {{ .NOSSL_SERVER_NAME }};
access_log /var/log/nginx/{{ .APP }}-access.log;
error_log /var/log/nginx/{{ .APP }}-error.log;
### Importing ssl certificates
# set a custom header for requests
add_header X-Served-By www-ec2-01;
You can import ssl certificates via tarball using the following command:
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;
This archive should is expanded via `tar xvf`. It should contain `server.crt` and `server.key`.
The above is a sample http configuration that adds an `X-Served-By` header to requests.
## Disabling VHOSTS
If desired, it is possible to disable vhosts by setting the `NO_VHOST` environment variable:
```bash
dokku config:set myapp NO_VHOST=1
### Available template variables
```
{{ .APP }} Application name
{{ .APP_SSL_PATH }} Path to SSL certificate and key
{{ .DOKKU_ROOT }} Global dokku root directory (ex: app dir would be `{{ .DOKKU_ROOT }}/{{ .APP }}`)
{{ .DOKKU_APP_LISTENERS }} List of IP:PORT pairs of app containers
{{ .NGINX_PORT }} Non-SSL nginx listener port (same as `DOKKU_NGINX_PORT` config var)
{{ .NGINX_SSL_PORT }} SSL nginx listener port (same as `DOKKU_NGINX_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
{{ .RAW_TCP_PORTS }} List of exposed tcp ports as defined by Dockerfile `EXPOSE` directive (**Dockerfile apps only**)
{{ .SSL_INUSE }} Boolean set when an app is SSL-enabled
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
On subsequent deploys, the nginx virtualhost will be discarded. This is useful when deploying internal-facing services that should not be publicly routeable.
### Customizing via configuration files included by the default templates
The default nginx.conf template 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
@@ -61,11 +92,13 @@ 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.
The `subdomain` is inferred from the pushed application name, while the `domain.tld` is set during initial configuration and stored in the `$DOKKU_ROOT/VHOST` file. It can then be modified with `dokku domains:set-global`. This value is used as a default TLD for all applications on a host.
You can optionally override this in a plugin by implementing the `nginx-hostname` pluginhook. For example, you can reverse the subdomain with the following sample `nginx-hostname` pluginhook:
If a FQDN such as `other.tld` is used as the application name, the default `$DOKKU_ROOT/VHOST` will be ignored and the resulting vhost URL for that application will be `other.tld`. The exception to this rule being that if the FQDN has the same ending as the default vhost (such as `subdomain.domain.tld`), then the entire FQDN will be treated as a subdomain. The application will therefore be deployed at `subdomain.domain.tld.domain.tld`.
```bash
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
@@ -76,3 +109,95 @@ 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:
### Domains plugin
> New as of 0.3.10
```shell
domains:add <app> DOMAIN Add a domain to app
domains [<app>] List domains
domains:clear <app> Clear all domains for app
domains:disable <app> Disable VHOST support
domains:enable <app> Enable VHOST support
domains:remove <app> DOMAIN Remove a domain from app
domains:set-global <domain> Set global domain name
```
### Disabling VHOSTS
If desired, it is possible to disable vhosts with the domains plugin.
```shell
dokku domains:disable myapp
```
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.)
The domains plugin allows you to specify custom domains for applications. This plugin is aware of any ssl certificates that are imported via `certs:add`. Be aware that disabling domains (with `domains:disable`) will override any custom domains.
```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
```
## 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/).
## Disabling Nginx
See the [proxy documentation](/dokku/deployment/proxy/).
Dokku itself is built out of plugins and uses [pluginhook](https://github.com/progrium/pluginhook) for its plugin system. In essence a plugin is a collection of scripts that will be run based on naming convention.
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
```bash
```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.
# 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
```
> todo: add a command to dokku to install a plugin, given a git repository `dokku plugin:install <git url>`?
## Creating your own plugin
If you create your own plugin:
[See the full documentation](/dokku/development/plugin-creation).
1. take a look at the plugins shipped with dokku and hack away!
2. upload your plugin to github with a repository name in form of `dokku-<name>` (e.g. `dokku-mariadb`)
3. edit this page and add a link to it below!
4. subscribe to the [dokku development blog](http://progrium.com) to be notified about API changes and releases
## 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.
| [PostgreSQL](https://github.com/Kloadut/dokku-pg-plugin) | [Kloadut][] | Compatible with 0.2.0 |
| [PostgreSQL](https://github.com/jezdez/dokku-postgres-plugin) | [jezdez][] | Compatible with 0.2.0 |
| [PostgreSQL](https://github.com/jlachowski/dokku-pg-plugin) | [jlachowski][] | IP & PORT available directly in linked app container env variables (requires link plugin)|
| [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). |
| [Memcached](https://github.com/jezdez/dokku-memcached-plugin) | [jezdez][] | Compatible with 0.2.0 |
| [Memcached](https://github.com/jlachowski/dokku-memcached-plugin) | [jlachowski][] | IP & PORT available directly in linked app container env variables (requires link plugin)|
| [RabbitMQ](https://github.com/jlachowski/dokku-rabbitmq-plugin) | [jlachowski][] | IP & PORT available directly in linked app container env variables (requires link plugin)|
| [RabbitMQ (single container)](https://github.com/jlachowski/dokku-rabbitmq-single-plugin) | [jlachowski][] | IP & PORT available directly in linked app container env variables (requires link plugin)|
<sup>1</sup> Similar to the heroku-labs feature (see https://devcenter.heroku.com/articles/labs-user-env-compile)
<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>4</sup> Conflicts with [VHOSTS Custom Configuration](https://github.com/neam/dokku-nginx-vhosts-custom-configuration)
<sup>5</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>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.
As of dokku 0.5.0, the proxy functionality has been decoupled from the nginx-vhosts plugin into the proxy plugin. In the future this will allow other proxy software (HAproxy for example) to be used instead of nginx.
```
proxy:disable <app> Disable proxy for app
proxy:enable <app> Enable proxy for app
proxy:set <app> <proxy_type> NOT IMPLEMENTED YET!!
```
## Container network interface binding
By default, the deployed docker container running your app's web process will bind to the internal docker network interface (i.e. `docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CONTAINER_ID`). This behavior can be modified per app by disabling the proxy (i.e. `dokku proxy:disable <app>`). In this case, the container will bind to an external interface (i.e. 0.0.0.0) and your app container will be directly accessible by other hosts on your network.
```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 node-js-app.web.1
Dokku commands can be run over ssh. Anywhere you would run `dokku <command>`, just run `ssh -t dokku@progriumapp.com <command>`
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 progriumapp.com
Host dokku.me
RequestTTY yes
```
## Run a command in the app environment
## Behavioral modifiers
It's possible to run commands in the environment of the deployed application:
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.
```bash
dokku run node-js-app ls -alh
dokku run <app> <cmd>
```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.
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.