Use correct casing for Dokku name
lowercase should only be used to refer to the binary, not the project
This commit is contained in:
Jose Diaz-Gonzalez
@@ -1,6 +1,6 @@
|
||||
# How to contribute
|
||||
|
||||
The Dokku project would love to welcome your contributions. There are
|
||||
The Dokku project would love to welcome your contributions. There are
|
||||
several ways to help out:
|
||||
|
||||
* Create an [issue](https://github.com/dokku/dokku/issues) on GitHub, if you
|
||||
@@ -11,7 +11,7 @@ several ways to help out:
|
||||
* Contribute to the [documentation](http://dokku.viewdocs.io/dokku/)
|
||||
* Come up with new ways to show off our [lovely logo](https://avatars1.githubusercontent.com/u/13455795)
|
||||
* Blog about different ways you are using dokku
|
||||
* [Sponsor](https://opencollective.com/dokku#support) the Dokku project financially
|
||||
* [Sponsor](https://opencollective.com/dokku#support) the Dokku project financially
|
||||
|
||||
There are a few guidelines that we need contributors to follow so that we have
|
||||
a chance of keeping on top of things.
|
||||
@@ -44,10 +44,10 @@ A great way to contribute to the project is to send a detailed report when you
|
||||
encounter an issue. We always appreciate a well-written, thorough bug report,
|
||||
and will thank you for it!
|
||||
|
||||
Sometimes dokku is missing a feature you need. In some cases, those features can
|
||||
Sometimes Dokku is missing a feature you need. In some cases, those features can
|
||||
be found in pre-existing [plugins](http://dokku.viewdocs.io/dokku/plugins/),
|
||||
and we encourage our users to create and contribute such packages. From time to
|
||||
time, we will also pull plugins into the dokku core when the task they solve is
|
||||
time, we will also pull plugins into the Dokku core when the task they solve is
|
||||
a common one for our users.
|
||||
|
||||
Check that [our issue database](https://github.com/dokku/dokku/issues)
|
||||
@@ -74,7 +74,7 @@ Our Issue Report Template is available [here](https://github.com/dokku/dokku/blo
|
||||
|
||||
## Contributing
|
||||
|
||||
Before you contribute to the dokku project, there are a few things that you'll
|
||||
Before you contribute to the Dokku project, there are a few things that you'll
|
||||
need to do
|
||||
|
||||
* Make sure you have a [GitHub account](https://github.com/signup/free).
|
||||
@@ -122,7 +122,7 @@ All changes should be be based on the latest master commit.
|
||||
|
||||
### When will my change be merged?
|
||||
|
||||
Be patient! The dokku maintainers will review all pull requests and comment as
|
||||
Be patient! The Dokku maintainers will review all pull requests and comment as
|
||||
quickly as possible. There may be some back and forth while the details of your
|
||||
pull request are discussed.
|
||||
|
||||
|
||||
@@ -21,12 +21,12 @@ Output of the following commands
|
||||
- If using buildpacks, which custom buildpacks are in use
|
||||
- If using a `Dockerfile`, the contents of that file
|
||||
- If it exists, the contents of your `Procfile`.
|
||||
- Output of failing dokku commands after running `dokku trace on`
|
||||
- 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):
|
||||
|
||||
Environment details (AWS, VirtualBox, physical, etc.):
|
||||
|
||||
How was dokku installed?:
|
||||
How was Dokku installed?:
|
||||
|
||||
How reproducible:
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troub
|
||||
|
||||
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](http://dokku.viewdocs.io/dokku/getting-started/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.
|
||||
While we may not merge your PR as is, they serve to start conversations and improve the general Dokku experience for all users.
|
||||
|
||||
## Sponsors
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
```shell
|
||||
git remote rm dokku
|
||||
@@ -24,14 +24,14 @@ dokku postgres:import [db_name] < [db_name].dump
|
||||
|
||||
## Volumes and Static Assets
|
||||
|
||||
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) 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.
|
||||
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) 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.
|
||||
|
||||
See the [persistent storage documentation](/dokku/advanced-usage/persistent-storage/) for more details.
|
||||
|
||||
|
||||
## 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).
|
||||
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).
|
||||
|
||||
```shell
|
||||
mkdir [app-name] ; cd !$
|
||||
|
||||
@@ -12,9 +12,9 @@ Common use cases include:
|
||||
## `app.json` and `scripts.dokku`
|
||||
|
||||
Dokku accomplishes this by using an `app.json` file. The format in use is similar to format of 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`.
|
||||
However, Dokku currently only supports the nodes `scripts.dokku.predeploy` and `scripts.dokku.postdeploy`.
|
||||
For buildpack apps, simply place an `app.json` file in the root of your repository.
|
||||
For dockerfile apps, place `app.json` in the configured `WORKDIR` directory; otherwise dokku defaults to the buildpack app behavior of looking in `/app`.
|
||||
For dockerfile apps, place `app.json` in the configured `WORKDIR` directory; otherwise Dokku defaults to the buildpack app behavior of looking in `/app`.
|
||||
>NOTE: postdeploy changes are *NOT* committed to the app image.
|
||||
|
||||
### Example app.json
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
> New as of 0.5.0
|
||||
|
||||
The preferred method to mount external containers to a dokku managed container, is to use the dokku storage plugin.
|
||||
The preferred method to mount external containers to a Dokku managed container, is to use the Dokku storage plugin.
|
||||
|
||||
|
||||
```
|
||||
@@ -63,7 +63,7 @@ Your app may have services that are running in memory and need to be backed up l
|
||||
|
||||
### Build phase
|
||||
|
||||
By default, dokku will only bind storage mounts during the deploy and run phases. Under certain conditions, one might want to bind a storage mount during the build phase. This can be accomplished by using the `docker-options` plugin directly.
|
||||
By default, Dokku will only bind storage mounts during the deploy and run phases. Under certain conditions, one might want to bind a storage mount during the build phase. This can be accomplished by using the `docker-options` plugin directly.
|
||||
|
||||
```shell
|
||||
dokku docker-options:add <app> build "-v /tmp/python-test:/opt/test"
|
||||
@@ -82,8 +82,8 @@ The storage plugin is compatible with storage mounts created with the docker-opt
|
||||
|
||||
## Application User and Persistent Storage file ownership (buildpack apps only)
|
||||
|
||||
By default, dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
|
||||
By default, Dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
|
||||
|
||||
> NOTE: this user must exist in your herokuish image.
|
||||
|
||||
Additionally, dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`.
|
||||
Additionally, Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`.
|
||||
|
||||
@@ -21,7 +21,7 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
|
||||
|
||||
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.
|
||||
|
||||
> If a proxy is disabled, dokku will bind your container's port to a random port on the host for every deploy, e.g. `0.0.0.0:32771->5000/tcp`.
|
||||
> If a proxy is disabled, Dokku will bind your container's port to a random port on the host for every deploy, e.g. `0.0.0.0:32771->5000/tcp`.
|
||||
|
||||
By way of example, in the default case, each container is bound to the docker interface:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 0.5.0 Migration Guide
|
||||
|
||||
## nginx-vhosts
|
||||
## `nginx-vhosts` plugin
|
||||
|
||||
- The nginx-vhosts template language is now [sigil](https://github.com/gliderlabs/sigil)
|
||||
- No need to escape literal `$` characters (or other "bash-isms")
|
||||
@@ -8,7 +8,7 @@
|
||||
- A detailed list of template variables can be found [here](/dokku/configuration/nginx/#available-template-variables)
|
||||
- A custom nginx-vhosts template must be named `nginx.conf.sigil`
|
||||
- The default path for this custom template is the root of your repo (i.e. `/app` in the container or `WORKDIR` if defined in a dockerfile app)
|
||||
- Dokku no longer looks for this file in `/home/dokku/myapp` on the dokku server
|
||||
- Dokku no longer looks for this file in `/home/dokku/myapp` on the Dokku server
|
||||
- Check out an example template [here](/dokku/configuration/nginx/)
|
||||
- Support for server-wide SSL certs have been dropped in favor of using the `certs` plugin
|
||||
- `dokku certs:add myapp < certs.tar`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 0.6.0 Migration Guide
|
||||
|
||||
## zero-downtime deployment
|
||||
## Zero-downtime deployment
|
||||
|
||||
- You can now **actually** disable zero-downtime deployments per-app and per-process-type
|
||||
- Some config variables have been moved around
|
||||
@@ -9,7 +9,7 @@
|
||||
- The values for the above can be a comma-separated list of process-types or the literal string `_all_`
|
||||
- See the [updated `checks`](/dokku/deployment/zero-downtime-deploys/) docs for more info
|
||||
|
||||
## proxy port mapping
|
||||
## Proxy port mapping
|
||||
|
||||
- You can now configure host -> container proxy port mappings
|
||||
- The UI is handled by the [proxy](/dokku/advanced-usage/proxy-management/) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
|
||||
@@ -20,9 +20,9 @@
|
||||
- dockerfile apps without explicitly exposed ports will behave the same as a buildpack app
|
||||
- NOTE: These defaults **are not** automatically changed on subsequent pushes and must be manipulated with the aforementioned commands
|
||||
|
||||
## calling the dokku binary
|
||||
## Calling the `dokku` binary
|
||||
|
||||
- Plugins should *not* call the dokku binary directly. Clients using the `--app` argument are potentially broken, amongst others, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call dokku internal functions. As a result, the following dokku commands are no longer publicly exposed:
|
||||
- Plugins should *not* call the `dokku` binary directly. Clients using the `--app` argument are potentially broken, amongst others, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call Dokku internal functions. As a result, the following Dokku commands are no longer publicly exposed:
|
||||
- `dokku build`
|
||||
- `dokku receive`
|
||||
- `dokku release`
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Clients
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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:
|
||||
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
|
||||
# optional: make sure that the dokku_client.sh version matches your Dokku version
|
||||
cd ~/.dokku
|
||||
git checkout <tag/branch>
|
||||
|
||||
@@ -35,13 +35,13 @@ alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
|
||||
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.
|
||||
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):
|
||||
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
|
||||
@@ -51,7 +51,7 @@ See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more
|
||||
|
||||
## (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):
|
||||
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
|
||||
@@ -61,7 +61,7 @@ See [documentation here](https://github.com/adamcharnock/dokku-client) for more
|
||||
|
||||
## (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):
|
||||
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
|
||||
@@ -71,7 +71,7 @@ See [documentation here](https://github.com/SebastianSzturo/dokku-cli) for more
|
||||
|
||||
## (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):
|
||||
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
|
||||
@@ -81,7 +81,7 @@ See [documentation here](https://github.com/netguru/dokku_client) for more infor
|
||||
|
||||
## (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):
|
||||
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
|
||||
@@ -91,7 +91,7 @@ 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):
|
||||
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
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
|
||||
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.
|
||||
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
|
||||
├── install # runs on Dokku installation
|
||||
└── post-deploy # runs after an app is deployed
|
||||
|
||||
## Installing a plugin
|
||||
@@ -20,7 +20,7 @@ Let's take a quick look at the current dokku nginx plugin that's shipped with do
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
| Plugin | Author | Compatibility |
|
||||
| ------------------------------------------------------------------------------------------------- | --------------------- | --------------------- |
|
||||
@@ -44,7 +44,7 @@ The following plugins are available and provided by dokku maintainers. Where not
|
||||
|
||||
## Community plugins
|
||||
|
||||
Note: The following plugins have been supplied by our community and may not have been tested by dokku maintainers.
|
||||
Note: The following plugins have been supplied by our community and may not have been tested by Dokku maintainers.
|
||||
|
||||
[256dpi]: https://github.com/256dpi
|
||||
[abossard]: https://github.com/dudagroup
|
||||
@@ -125,19 +125,19 @@ Note: The following plugins have been supplied by our community and may not have
|
||||
|
||||
| Plugin | Author | Compatibility |
|
||||
| ------------------------------------------------------------------------------------------------- | --------------------- | --------------------- |
|
||||
| [MariaDB](https://github.com/Kloadut/dokku-md-plugin) | [Kloadut][] | 0.3.x |
|
||||
| [MariaDB (single container)](https://github.com/ohardy/dokku-mariadb) | [ohardy][] | 0.3.x |
|
||||
| [MariaDB (single container)](https://github.com/krisrang/dokku-mariadb) | [krisrang][] | 0.3.26+ |
|
||||
| [PostgreSQL](https://github.com/jlachowski/dokku-pg-plugin) | [jlachowski][] | 0.3.x |
|
||||
| [PostgreSQL (single container)](https://github.com/ohardy/dokku-psql) | [ohardy][] | 0.3.x |
|
||||
| [PostgreSQL (single container)](https://github.com/Flink/dokku-psql-single-container) | [Flink][] | 0.3.26+ |
|
||||
| [MariaDB](https://github.com/Kloadut/dokku-md-plugin) | [Kloadut][] | 0.3.x |
|
||||
| [MariaDB (single container)](https://github.com/ohardy/dokku-mariadb) | [ohardy][] | 0.3.x |
|
||||
| [MariaDB (single container)](https://github.com/krisrang/dokku-mariadb) | [krisrang][] | 0.3.26+ |
|
||||
| [PostgreSQL](https://github.com/jlachowski/dokku-pg-plugin) | [jlachowski][] | 0.3.x |
|
||||
| [PostgreSQL (single container)](https://github.com/ohardy/dokku-psql) | [ohardy][] | 0.3.x |
|
||||
| [PostgreSQL (single container)](https://github.com/Flink/dokku-psql-single-container) | [Flink][] | 0.3.26+ |
|
||||
|
||||
#### Caching
|
||||
|
||||
| Plugin | Author | Compatibility |
|
||||
| ------------------------------------------------------------------------------------------------- | --------------------- | --------------------- |
|
||||
| [Nginx Cache](https://github.com/Aluxian/dokku-nginx-cache) | [Aluxian][] | 0.5.0+ |
|
||||
| [Redis (single container)](https://github.com/ohardy/dokku-redis) | [ohardy][] | 0.3.x |
|
||||
| [Redis (single container)](https://github.com/ohardy/dokku-redis) | [ohardy][] | 0.3.x |
|
||||
| [Varnish](https://github.com/Zenedith/dokku-varnish-plugin) | [Zenedith][] | Varnish cache between nginx and application with base configuration|
|
||||
|
||||
#### Queuing
|
||||
@@ -172,7 +172,7 @@ Note: The following plugins have been supplied by our community and may not have
|
||||
| [Dokku Registry](https://github.com/agco-adm/dokku-registry)<sup>1</sup> | [agco-adm][] | 0.4.0+ |
|
||||
| [Dokku Require](https://github.com/crisward/dokku-require)<sup>2</sup> | [crisward][] | 0.4.0+ |
|
||||
| [git rev-parse HEAD in env](https://github.com/cjblomqvist/dokku-git-rev) | [cjblomqvist][] | 0.4.0+ |
|
||||
| [Graduate (Environment Management)](https://github.com/glassechidna/dokku-graduate) | [Benjamin-Dobell][] | 0.4.0+ |
|
||||
| [Graduate (Environment Management)](https://github.com/glassechidna/dokku-graduate) | [Benjamin-Dobell][] | 0.4.0+ |
|
||||
| [Haproxy tcp load balancer](https://github.com/256dpi/dokku-haproxy) | [256dpi][] | 0.4.0+ |
|
||||
| [HTTP Auth Secure Apps](https://github.com/matto1990/dokku-secure-apps) | [matto1990][] | 0.4.0+ |
|
||||
| [Hostname](https://github.com/michaelshobbs/dokku-hostname) | [michaelshobbs][] | 0.4.0+ |
|
||||
@@ -230,7 +230,7 @@ The following plugins have been removed as their functionality is now in Dokku C
|
||||
| [Custom Domains](https://github.com/neam/dokku-custom-domains) | [motin][] | v0.3.10 (domains plugin) |
|
||||
| [Debug](https://github.com/heichblatt/dokku-debug) | [heichblatt][] | v0.3.9 (trace command) |
|
||||
| [Docker Options](https://github.com/dyson/dokku-docker-options) | [dyson][] | v0.3.17 (docker-options plugin) |
|
||||
| [Dokku Name](https://github.com/alex-sherwin/dokku-name) | [alex-sherwin][] | v0.4.2 (named containers plugin) |
|
||||
| [Dokku Name](https://github.com/alex-sherwin/dokku-name) | [alex-sherwin][] | v0.4.2 (named containers plugin) |
|
||||
| [Events Logger](https://github.com/alessio/dokku-events) | [alessio][] | v0.3.21 (events plugin) |
|
||||
| [Host Port binding](https://github.com/stuartpb/dokku-bind-port) | [stuartpb][] | v0.3.17 (docker-options plugin) |
|
||||
| [List Containers](https://github.com/heichblatt/dokku-list) | [heichblatt][] | v0.3.14 (ps plugin) |
|
||||
|
||||
@@ -14,7 +14,7 @@ Because there are so many different DNS server packages out there as well as a t
|
||||
|
||||
* We assume you have a passing familiarity with DNS. If not, you can read an [in-depth article](http://www.diaryofaninja.com/blog/2012/03/03/devops-dns-for-developers-ndash-now-therersquos-no-excuse-not-to-know) on DNS. But basically you need to know that DNS changes names (like example.tld) into addresses (like 127.0.0.1)
|
||||
* We assume you already have a domain name registered and pointed to your favorite Managed DNS Provider or have your own BIND DNS server running.
|
||||
* You have a server on the internet and are about to follow the instructions in the [README](https://github.com/dokku/dokku/blob/master/README.md) to get dokku installed. Don't do the install just yet though.
|
||||
* 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.
|
||||
|
||||
## Caching
|
||||
|
||||
@@ -29,13 +29,13 @@ Don't be afraid to ask if you need help. Create a [new issue](https://github.co
|
||||
|
||||
For the examples, we will use the domain name `example.tld` and the IP address `127.0.0.1`.
|
||||
|
||||
Dokku uses DNS to differentiate between apps on your dokku-powered server. If you are using the domain `example.tld`, and you have two apps `myapp1` and `myapp2`, dokku will make them available at `myapp1.example.tld` and `myapp2.example.tld`.
|
||||
Dokku uses DNS to differentiate between apps on your dokku-powered server. If you are using the domain `example.tld`, and you have two apps `myapp1` and `myapp2`, Dokku will make them available at `myapp1.example.tld` and `myapp2.example.tld`.
|
||||
|
||||
To get started, you need to know the IP address of your dokku server. Connect to it and run `ifconfig` or `ip addr` to see the IP address.
|
||||
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.
|
||||
|
||||
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)
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ 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).
|
||||
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).
|
||||
|
||||
```nginx
|
||||
server {
|
||||
@@ -98,4 +98,4 @@ 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.
|
||||
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.
|
||||
|
||||
@@ -69,7 +69,7 @@ upstream {{ .APP }} {
|
||||
```
|
||||
{{ .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_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)
|
||||
@@ -198,7 +198,7 @@ chown dokku:dokku /home/dokku/myapp/nginx.conf.d/upload.conf
|
||||
service nginx reload
|
||||
```
|
||||
|
||||
The example above uses additional configuration files directly on the dokku host. Unlike the `nginx.conf.sigil` file, these additional files will not be copied over from your application repo, and thus need to be placed in the `/home/dokku/myapp/nginx.conf.d/` directory manually.
|
||||
The example above uses additional configuration files directly on the Dokku host. Unlike the `nginx.conf.sigil` file, these additional files will not be copied over from your application repo, and thus need to be placed in the `/home/dokku/myapp/nginx.conf.d/` directory manually.
|
||||
|
||||
## Domains plugin
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ The `certs:remove` command only works on app-specific certificates. It will `rm`
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ git clone git@github.com:heroku/ruby-rails-sample.git
|
||||
Create the application on the Dokku host. You will need to ssh onto the host to run this command.
|
||||
|
||||
```shell
|
||||
# on your dokku host
|
||||
# on your Dokku host
|
||||
dokku apps:create ruby-rails-sample
|
||||
```
|
||||
|
||||
@@ -23,7 +23,7 @@ dokku apps:create ruby-rails-sample
|
||||
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/community/plugins/#official-plugins-beta) for common datastores. Our sample app requires a PostgreSQL service:
|
||||
|
||||
```shell
|
||||
# on your dokku host
|
||||
# on your Dokku host
|
||||
# install the postgres plugin
|
||||
# plugin installation requires root, hence the user change
|
||||
sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git
|
||||
@@ -39,7 +39,7 @@ dokku postgres:create rails-database
|
||||
Once the service creation is complete, set the `POSTGRES_URL` environment variable by linking the service.
|
||||
|
||||
```shell
|
||||
# on your dokku host
|
||||
# on your Dokku host
|
||||
# each official datastore offers a `link` method to link a service to any application
|
||||
dokku postgres:link rails-database ruby-rails-sample
|
||||
```
|
||||
@@ -97,7 +97,7 @@ You can also support pushing multiple branches using the [receive-branch](/dokku
|
||||
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:
|
||||
|
||||
``` shell
|
||||
# on your dokku host
|
||||
# on your Dokku host
|
||||
dokku config:set ruby-rails-sample DOKKU_SKIP_DEPLOY=true
|
||||
```
|
||||
|
||||
@@ -106,7 +106,7 @@ dokku config:set ruby-rails-sample DOKKU_SKIP_DEPLOY=true
|
||||
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.
|
||||
|
||||
```shell
|
||||
# on your dokku host
|
||||
# on your Dokku host
|
||||
su - dokku
|
||||
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
|
||||
ssh -T git@github.com
|
||||
|
||||
@@ -21,7 +21,7 @@ node-js-app
|
||||
python-app
|
||||
```
|
||||
|
||||
Note that you can easily hide extra output from dokku commands by using the `--quiet` flag, which makes it easier to parse on the command-line.
|
||||
Note that you can easily hide extra output from Dokku commands by using the `--quiet` flag, which makes it easier to parse on the command-line.
|
||||
|
||||
```shell
|
||||
dokku --quiet apps
|
||||
|
||||
@@ -9,9 +9,9 @@ Dokku normally defaults to using [heroku buildpacks](https://devcenter.heroku.co
|
||||
|
||||
## 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.
|
||||
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:
|
||||
To use a specific buildpack, you can run the following Dokku command:
|
||||
|
||||
```shell
|
||||
# replace APP with the name of your application
|
||||
|
||||
@@ -19,7 +19,7 @@ Dokku will extract all tcp ports exposed using the `EXPOSE` directive (one port
|
||||
|
||||
> Note: Nginx does not support proxying UDP. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`
|
||||
|
||||
If you do not explicitly `EXPOSE` a port in your `Dockerfile`, dokku will configure the nginx proxy to listen on port 80 (and 443 for TLS) and forward traffic to your app listening on port 5000 inside the container. Just like buildpack apps, you can also use the `$PORT` environment variable in your app to maintain portability.
|
||||
If you do not explicitly `EXPOSE` a port in your `Dockerfile`, Dokku will configure the nginx proxy to listen on port 80 (and 443 for TLS) and forward traffic to your app listening on port 5000 inside the container. Just like buildpack apps, you can also use the `$PORT` environment variable in your app to maintain portability.
|
||||
|
||||
When ports are exposed through the default nginx proxy, they are proxied externally as HTTP ports. At this time, in no case do we proxy plain TCP or UDP ports. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/dokku/advanced-usage/proxy-management/).
|
||||
|
||||
|
||||
@@ -7,9 +7,11 @@ tar:from <app> <url> # Loads an app tarball from url
|
||||
tar:in <app> # Reads an tarball containing the app from stdin
|
||||
```
|
||||
|
||||
## Deploying from a tarball
|
||||
## Usage
|
||||
|
||||
In some cases, it may be useful to deploy an application from a tarball. For instance, if you implemented a non-git based deployment plugin, tarring the generated artifact may be an easier route to interface with the existing dokku infrastructure.
|
||||
### Deploying from a tarball
|
||||
|
||||
In some cases, it may be useful to deploy an application from a tarball. For instance, if you implemented a non-git based deployment plugin, tarring the generated artifact may be an easier route to interface with the existing Dokku infrastructure.
|
||||
|
||||
You can place the tarball on an external webserver and deploy via the `tar:from` command.
|
||||
|
||||
@@ -17,6 +19,8 @@ You can place the tarball on an external webserver and deploy via the `tar:from`
|
||||
dokku tar:from node-js-app https://dokku.me/releases/node-js-app/v1
|
||||
```
|
||||
|
||||
### Deploying via stdin
|
||||
|
||||
As an alternative, a deploy can be trigged from a tarball read from stdin using the `tar:in` command:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -36,14 +36,14 @@ dokku config:set --global DOKKU_RM_CONTAINER=1
|
||||
dokku config:unset --global DOKKU_RM_CONTAINER
|
||||
```
|
||||
|
||||
You may also use the `--rm-container` or `--rm` dokku flags to remove the containers automatically:
|
||||
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
|
||||
```
|
||||
|
||||
Finally, you may wish to run a container in "detached" mode via the `--detach` dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as dokku will *not* automatically terminate the container.
|
||||
Finally, you may wish to run a container in "detached" mode via the `--detach` Dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
|
||||
|
||||
```shell
|
||||
dokku --detach run node-js-app ls -lah
|
||||
@@ -119,8 +119,8 @@ For tasks that will properly resume, you **should** use the above method, as run
|
||||
|
||||
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`
|
||||
- Use the `dokku` user's crontab
|
||||
- If you do not, the `dokku` binary 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.
|
||||
|
||||
@@ -12,7 +12,7 @@ Host dokku.me
|
||||
## Behavioral modifiers
|
||||
|
||||
Dokku also supports certain command-line arguments that augment it's behavior. If using these over ssh, you must use the form `ssh -t dokku@dokku.me -- <command>`
|
||||
in order to avoid ssh interpretting dokku arguments for itself.
|
||||
in order to avoid ssh interpretting Dokku arguments for itself.
|
||||
|
||||
```
|
||||
--quiet suppress output headers
|
||||
@@ -23,6 +23,6 @@ in order to avoid ssh interpretting dokku arguments for itself.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
@@ -10,7 +10,7 @@ checks:run <app> [process-type(s)] Runs zero-downtime checks for all proce
|
||||
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
|
||||
```
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
```shell
|
||||
dokku config:set --global DOKKU_DEFAULT_CHECKS_WAIT=30
|
||||
@@ -147,7 +147,7 @@ Invalid container id specified (APP.web.3)
|
||||
|
||||
If your application needs a longer period to boot up - perhaps to load data into memory, or because of slow boot time - you may also use dokku's `checks` functionality to more precisely check whether an application can serve traffic or not.
|
||||
|
||||
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, dokku will fallback to the aforementioned process uptime check.
|
||||
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, Dokku will fallback to the aforementioned process uptime check.
|
||||
|
||||
To specify checks, add a `CHECKS` file to the root of your project directory. The `CHECKS` file should be plain text and may contain:
|
||||
|
||||
@@ -203,7 +203,7 @@ 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:
|
||||
You can also override the default `WAIT`, `TIMEOUT`, and `ATTEMPTS` variables for the global Dokku installation:
|
||||
|
||||
```shell
|
||||
dokku config:set --global DOKKU_CHECKS_WAIT=30
|
||||
@@ -219,7 +219,7 @@ dokku config:set <app> DOKKU_DEFAULT_CHECKS_WAIT=0
|
||||
|
||||
### Configuring docker stop timeout
|
||||
|
||||
[By default](https://docs.docker.com/engine/reference/commandline/stop/), docker will wait 10 seconds from the time the `stop` command is passed to a container before it attempts to kill said container. This timeout can be configured on a per-app basis in dokku by setting the `DOKKU_DOCKER_STOP_TIMEOUT` configuration variable. This timeout applies to normal zero-downtime deployments as well as the `ps:stop` and `apps:destroy` commands.
|
||||
[By default](https://docs.docker.com/engine/reference/commandline/stop/), docker will wait 10 seconds from the time the `stop` command is passed to a container before it attempts to kill said container. This timeout can be configured on a per-app basis in Dokku by setting the `DOKKU_DOCKER_STOP_TIMEOUT` configuration variable. This timeout applies to normal zero-downtime deployments as well as the `ps:stop` and `apps:destroy` commands.
|
||||
|
||||
```shell
|
||||
dokku config:set $APP DOKKU_DOCKER_STOP_TIMEOUT=20
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
If you create your own plugin:
|
||||
|
||||
1. Take a look at the plugins shipped with dokku and hack away!
|
||||
1. Take a look at the plugins shipped with Dokku and hack away!
|
||||
2. Check out the [list of triggers](/dokku/development/plugin-triggers) your plugin can implement.
|
||||
3. Upload your plugin to github with a repository name in form of `dokku-<name>` (e.g. `dokku-mariadb`)
|
||||
4. Edit [this page](/dokku/community/plugins/) and add a link to it.
|
||||
@@ -124,7 +124,7 @@ A few notes:
|
||||
- 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.
|
||||
- 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 :
|
||||
|
||||
```shell
|
||||
@@ -134,7 +134,7 @@ A few notes:
|
||||
fi
|
||||
```
|
||||
|
||||
In the case where the "user/repo" is not installed, dokku exits just before the awk command,
|
||||
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:
|
||||
@@ -156,4 +156,4 @@ A few notes:
|
||||
- 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.
|
||||
- As of 0.6.0, we advise you to *not* call the dokku binary directly from within plugins. Clients using the `--app` argument are potentially broken, amongst other issues, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call dokku internal functions
|
||||
- As of 0.6.0, we advise you to *not* call the `dokku` binary directly from within plugins. Clients using the `--app` argument are potentially broken, amongst other issues, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call Dokku internal functions
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Plugin triggers
|
||||
|
||||
[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](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:
|
||||
|
||||
@@ -9,7 +9,7 @@ Plugin triggers are simply scripts that are executed by the system. You can use
|
||||
|
||||
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:
|
||||
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
|
||||
@@ -23,11 +23,11 @@ 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.
|
||||
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 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.
|
||||
> 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.
|
||||
|
||||
### `post-config-update`
|
||||
|
||||
@@ -63,7 +63,7 @@ echo false
|
||||
|
||||
### `check-deploy`
|
||||
|
||||
- Description: Allows you to run checks on a deploy before dokku allows the container to handle requests.
|
||||
- Description: Allows you to run checks on a deploy before Dokku allows the container to handle requests.
|
||||
- Invoked by: `dokku deploy`
|
||||
- Arguments: `$APP $CONTAINER_ID $PROC_TYPE $PORT $IP`
|
||||
- Example:
|
||||
@@ -312,7 +312,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
|
||||
```shell
|
||||
#!/usr/bin/env bash
|
||||
# Sets the hostname of the dokku server
|
||||
# Sets the hostname of the Dokku server
|
||||
# based on the output of `hostname -f`
|
||||
|
||||
set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
@@ -778,7 +778,7 @@ dokku hg-build $APP $REV
|
||||
|
||||
```shell
|
||||
#!/bin/bash
|
||||
# Gives dokku the ability to support multiple branches for a given service
|
||||
# Gives Dokku the ability to support multiple branches for a given service
|
||||
# Allowing you to have multiple staging environments on a per-branch basis
|
||||
|
||||
reference_app=$1
|
||||
@@ -865,7 +865,7 @@ sudo BUILD_STACK=true make install
|
||||
|
||||
### `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.
|
||||
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:
|
||||
|
||||
@@ -882,7 +882,7 @@ 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.
|
||||
- Description: Allows you to deny access to a Dokku command by either ssh user or associated ssh-command NAME user.
|
||||
- Invoked by `dokku`
|
||||
- Arguments: `$SSH_USER $SSH_NAME $DOKKU_COMMAND`
|
||||
- Example:
|
||||
|
||||
@@ -39,9 +39,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.
|
||||
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.
|
||||
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:
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ While we do provide official packages for a variety of platforms, as our test su
|
||||
|
||||
## Local Test Execution
|
||||
|
||||
- Setup dokku in a [vagrant vm](/dokku/getting-started/install/vagrant)
|
||||
- Setup Dokku in a [vagrant vm](/dokku/getting-started/install/vagrant)
|
||||
- Run the following to setup tests and execute them:
|
||||
|
||||
```shell
|
||||
@@ -29,7 +29,7 @@ While we do provide official packages for a variety of platforms, as our test su
|
||||
# execute the entire test suite (linter, bats tests, and app deployment tests)
|
||||
make test
|
||||
|
||||
# run linter & update vagrant dokku install from local git clone
|
||||
# run linter & update vagrant Dokku install from local git clone
|
||||
make lint copyfiles
|
||||
|
||||
# execute all bats tests
|
||||
@@ -45,4 +45,4 @@ Additionally you may run a specific app deployment tests with a target similar t
|
||||
make deploy-test-nodejs-express
|
||||
```
|
||||
|
||||
For a full list of test make targets check out `tests.mk` in the root of the dokku repository.
|
||||
For a full list of test make targets check out `tests.mk` in the root of the Dokku repository.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Advanced installation
|
||||
|
||||
You can always install dokku straight from the latest - potentially unstable - master release via the following bash command:
|
||||
You can always install Dokku straight from the latest - potentially unstable - master release via the following bash command:
|
||||
|
||||
```shell
|
||||
# using a branch results in installing from source
|
||||
@@ -26,7 +26,7 @@ sudo SSHCOMMAND_URL=https://raw.githubusercontent.com/yourusername/sshcommand/ma
|
||||
|
||||
## Bootstrap a server from your own repository
|
||||
|
||||
The bootstrap script allows the dokku repository URL to be overridden to bootstrap a host from your own clone of dokku using the `DOKKU_REPO` environment variable. Example:
|
||||
The bootstrap script allows the Dokku repository URL to be overridden to bootstrap a host from your own clone of Dokku using the `DOKKU_REPO` environment variable. Example:
|
||||
|
||||
```shell
|
||||
wget https://raw.githubusercontent.com/dokku/dokku/master/bootstrap.sh
|
||||
@@ -46,11 +46,11 @@ sudo BUILD_STACK=true STACK_URL=https://github.com/gliderlabs/herokuish.git make
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
*You should also stop and disable the `dokku-installer` service to remove public access to adding SSH keys.*
|
||||
|
||||
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).
|
||||
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.
|
||||
|
||||
@@ -58,7 +58,7 @@ 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).
|
||||
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.
|
||||
|
||||
|
||||
@@ -2,10 +2,10 @@
|
||||
|
||||
- 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**.
|
||||
- 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`.
|
||||
- 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`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Debian Package Installation Notes
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
```shell
|
||||
# install prerequisites
|
||||
@@ -14,7 +14,7 @@ wget -nv -O - https://get.docker.com/ | sh
|
||||
wget -nv -O - https://packagecloud.io/gpg.key | apt-key add -
|
||||
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 -qq -y dokku
|
||||
sudo apt-get install -qq -y dokku
|
||||
sudo dokku plugin:install-dependencies --core
|
||||
```
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ openstack server create \
|
||||
```
|
||||
|
||||
The content of dokku-cloudinit.sh script contains instructions to add
|
||||
Docker and Dokku's apt repositories and install dokku with the proper
|
||||
Docker and Dokku's apt repositories and install Dokku with the proper
|
||||
debconf options set. Don't forget to add the FQDN for your application
|
||||
server:
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Dokku is designed for usage on a fresh installation of Ubuntu, and should instal
|
||||
To install the latest stable version of dokku, you can run the following shell commands:
|
||||
|
||||
```shell
|
||||
# for debian systems, installs dokku via apt-get
|
||||
# for debian systems, installs Dokku via apt-get
|
||||
wget https://raw.githubusercontent.com/dokku/dokku/v0.7.1/bootstrap.sh
|
||||
sudo DOKKU_TAG=v0.7.1 bash bootstrap.sh
|
||||
```
|
||||
@@ -29,12 +29,12 @@ The installation process takes about 5-10 minutes, depending upon internet conne
|
||||
|
||||
#### 2. Setup SSH key and Virtualhost Settings
|
||||
|
||||
Once the installation is complete, you can open a browser to setup your SSH key and virtualhost settings. Open your browser of choice and navigate to the host's IP address - or the domain you assigned to that IP previously - and configure dokku via the web admin.
|
||||
Once 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.
|
||||
|
||||
*If you don't complete setup via the web installer (even if you set up SSH keys and virtual hosts otherwise) your dokku installation will remain vulnerable to anyone finding the setup page and inserting their key.*
|
||||
*If you don't complete setup via the web installer (even if you set up SSH keys and virtual hosts otherwise) your Dokku installation will remain vulnerable to anyone finding the setup page and inserting their key.*
|
||||
|
||||
#### 3. Deploy your first application
|
||||
Once you save your settings, the web admin will self-terminate and you should be able to run or deploy to the dokku installation.
|
||||
Once you save your settings, the web admin will self-terminate and you should be able to run or deploy to the Dokku installation.
|
||||
|
||||
### Installing via other methods
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ __Solution:__
|
||||
|
||||
The `remote rejected` error does not give enough information. Anything could have failed.
|
||||
|
||||
To enable dokku tracing, simply run the following command:
|
||||
To enable Dokku tracing, simply run the following command:
|
||||
|
||||
```shell
|
||||
# since 0.3.9
|
||||
@@ -60,7 +60,7 @@ This will trace all of dokku's activity. If this does not help you, create a [gi
|
||||
|
||||
***
|
||||
|
||||
__Symptom:__ I get the aforementioned error in the build phase (after turning on dokku tracing)
|
||||
__Symptom:__ I get the aforementioned error in the build phase (after turning on Dokku tracing)
|
||||
|
||||
Most errors that happen in this phase are due to transient network issues (either locally or remotely) buildpack bugs.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Upgrading
|
||||
|
||||
If your version of dokku is pre 0.3.0 (check with `dokku version`), we recommend [a fresh install](/dokku/getting-started/installation/) on a new server.
|
||||
If your version of Dokku is pre 0.3.0 (check with `dokku version`), we recommend [a fresh install](/dokku/getting-started/installation/) on a new server.
|
||||
|
||||
## Migration Guides
|
||||
|
||||
@@ -20,7 +20,7 @@ Before upgrading, check the migration guides to get comfortable with new feature
|
||||
|
||||
## Upgrade Instructions
|
||||
|
||||
If dokku was installed via `apt-get install dokku` or `bootstrap.sh` (most common), upgrade with:
|
||||
If Dokku was installed via `apt-get install dokku` or `bootstrap.sh` (most common), upgrade with:
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
@@ -32,7 +32,7 @@ dokku ps:rebuildall # restart all applications
|
||||
|
||||
### Upgrade From Source
|
||||
|
||||
If you installed dokku from source (less common), upgrade with:
|
||||
If you installed Dokku from source (less common), upgrade with:
|
||||
|
||||
```shell
|
||||
dokku apps
|
||||
|
||||
Reference in New Issue
Block a user