# History
## 0.21.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.4/bootstrap.sh
sudo DOKKU_TAG=v0.21.4 bash bootstrap.sh
```
### Bug Fixes
- #4092: @Yihao-G Fix nginx proxy-read-timeout not set for HTTPS
- #4095: @GennadySpb Fix application removal during uninstallation
### New Features
- #4097: @josegonzalez Update herokuish
### Documentation
- #4096: @josegonzalez Clarify that special config variables are not exposed to applications
- #4007: @turicas Clarify nginx.conf.sigil path in image when deploying non-buildpack apps
- #4078: @gurpreetatwal Add more details to `nginx-dokku-template-source` trigger
- #4090: @ankane Official plugins no longer in beta
- #4085: @josegonzalez Set warning on resource type as an actual warning
### Other
- #4082: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.4 to 1.25.5 in /tests/apps/php
# History
## 0.21.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.3/bootstrap.sh
sudo DOKKU_TAG=v0.21.3 bash bootstrap.sh
```
### Bug Fixes
- #4077: @Schlepptop Fix config_all bug introduced in 0.21.2
- #4074: @josegonzalez Force set all plugin permissions on plugin:install/update
### Documentation
- #4073: @josegonzalez Document the official shell client
# History
## 0.21.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.2/bootstrap.sh
sudo DOKKU_TAG=v0.21.2 bash bootstrap.sh
```
### Bug Fixes
- #4072: @Schlepptop Fix deprecation warning in config_all
### New Features
- #4061: @josegonzalez Drop go sum and mod files from releases
### Refactors
- #4064: @hugopeixoto Use *_PATH consistently
### Documentation
- #4069: @josegonzalez Scheduler plugins are no longer beta
- #4068: @josegonzalez Official plugins are no longer in beta
- #4066: @ltalirz Add ansible as installation route
- #4063: @josegonzalez Clarify why we stop/rebuild apps during upgrade
- #4040: @fonsp Added link to the buildpack plugin docs
- #4062: @hugopeixoto Rewrite upgrade instructions
GLOBAL_VHOST_PATH and GLOBAL_VHOST_FILE were used to represent the same
thing. Same for APP_URLS_PATH and APP_VHOST_PATH.
This normalizes all of those to _PATH.
# History
## 0.21.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.0/bootstrap.sh
sudo DOKKU_TAG=v0.21.0 bash bootstrap.sh
```
### Bug Fixes
- #4058: @hugopeixoto Ensure web installer creates files with correct permissions
- #4055: @hugopeixoto Delete dokkurc recursively during uninstall
- #4057: @hugopeixoto Install sudo when installing from source
- #4045: @josegonzalez Filter gpus instead of nvidia-gpus from resource arguments
- #4029: @josegonzalez Filter args _after_ docker-args-process-deploy
- #4026: @josegonzalez Filter resource args from deploy tasks
- #4022: @josegonzalez Do not allow slashes in app names
- #4020: @josegonzalez Properly handle multiple containers in ps:inspect
- #3989: @josegonzalez Correct entering running containers
- #3977: @josegonzalez Set default port for all run commands
- #3969: @josegonzalez Do not logrotate all services files
- #3964: @josegonzalez Remove all --force-yes usage throughout the codebase
- #3955: @benwh Fix missing 502 error page
- #3953: @josegonzalez Use correct function name for cmd-tar-in and update migration guide
### New Features
- #4041: @rvanlaar feat: Add download option to the certs plugin
- #4043: @josegonzalez Allow controlling nginx proxy-read-timeout
- #4038: @josegonzalez Create proxy:build-config command
- #4021: @josegonzalez Depend on python3 binary for CentOS 8 support
- #4004: @josegonzalez Add support for moby-engine
- #3967: @josegonzalez Add Ubuntu 20.04 support
- #3988: @josegonzalez Upgrade plugn to 0.5.0
- #3987: @josegonzalez Upgrade sigil to 0.6.0
- #3986: @josegonzalez Upgrade sshcommand to 0.11.0
- #3985: @josegonzalez Upgrade go-procfile-util to 0.8.2
- #3982: @josegonzalez Allow apps named tls
- #3979: @josegonzalez Upgrade herokuish
- #3971: @josegonzalez feat: allow users to customize the source of the dokku.conf nginx template
- #3966: @josegonzalez Move domain manipulation into triggers
- #3965: @josegonzalez Drop dokku references in logging output
- #3954: @josegonzalez feat: upgrade herokuish to 0.5.12
- #3940: @josegonzalez Expose last updated time in git:report
- #3939: @josegonzalez Add support for outputting the last visited time
### Refactors
- #4035: @josegonzalez Switch to go mod
- #4008: @josegonzalez Standardize golang command code
### Documentation
- #4056: @swrobel Remove invalid help entry for dokku ps commmand
- #4039: @josegonzalez Break out bc-break and refactors in changelog
- #4025: @alexjj Switch AUR helper to yay
- #4019: @tdak Added one possible solution to an error
- #4014: @rvanlaar Update dreamhost cloudinit script
- #4003: @josegonzalez Add dokku.ai asset
- #3999: @DavidLemayian Update URL for less than 1gb memory in bootstrap.sh [ci skip]
- #3998: @josegonzalez Document the #dokku channel on slack
- #3996: @josegonzalez Clarify network aliases and add section on tld management
- #3980: @josegonzalez Clarify that the web installer is not supported in docker-based installs
- #3970: @josegonzalez Clarify the 'see the docs' internal links
- #3968: @josegonzalez Document access.conf issue
- #3957: @swrobel Add official registry plugin
- #3942: @scowalt Fix grammar in environment variables documentation
### Tests
- #4046: @rvanlaar Make `make test` pass on linting
- #4037: @josegonzalez Try to output oomkill information
- #4036: @josegonzalez Store the deb and rpm artifacts
- #4034: @josegonzalez Teardown apps and containers in global teardown
- #4031: @josegonzalez Delete old apps and ensure the test helper is quieter
- #4030: @josegonzalez Update circleci workflow
- #3947: @jayjun Scope init tests to container processes only
### Other
- #4051: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 177 to 178 in /tests/apps/php
- #4028: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 176 to 177 in /tests/apps/php
- #4016: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.29.v20200521 to 9.4.30.v20200611 in /tests/apps/java
- #4006: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 174 to 176 in /tests/apps/php
- #4001: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.28.v20200408 to 9.4.29.v20200521 in /tests/apps/java
- #4002: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.3 to 1.25.4 in /tests/apps/php
- #3993: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.1 to 1.4.2 in /tests/apps/gogrpc
- #3962: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.0 to 1.4.1 in /tests/apps/gogrpc
- #3959: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 173 to 174 in /tests/apps/php
- #3950: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.29.0 to 1.29.1 in /tests/apps/gogrpc
- #3946: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.1 to 1.29.0 in /tests/apps/gogrpc
The 'server.key' and 'server.crt' can printed to stdin.
The two options are:
`dokku certs:show <app> key > server.key`
`dokku certs:show <app> crt > server.crt`
This will create two files, `server.key` and `server.crt`.
Those files contain the private key and the certificate.
Includes tests.
This hopefully makes it a little easier to work with as the tooling is now based on something in golang core.
- move columnize usage to common plugin
- remove old vendor files
There is likely a better regex for the actually allowed names, but this will suffice for ensuring folks don't do weird things with their folder structures...
Closes#4013
Bring configuration in line with the latest Cloud init verison. Tested under 20.1.
Mainly done due to `debconf_selections` not working with the old syntac.
See the `debconf_selections` item under https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure
Changes include:
- reboot when apt deems it necessary,
- define update and upgrade with the package syntax,
- bring apt sources and keys inline with apt syntax and
- dynamically get the right release by using the var '$RELEASE'.
[ci skip]
This cloudinit script had become outdated.
Changed 4 things:
- docker repository had moved
- use current docker gpg key
- use current dokku gpg key
- move over to ubuntu focal LTS 20.20
This functionality was broken due to a refactor of argument handling in a previous release.
In addition to the fix, all the functionality was moved to scheduler-enter, which allows scheduler plugins to implement ways of entering containers in the relevant scheduler.
Closes#3972
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
These are usually not optional and actually explain what a user is interested in. As we don't have documentation partials, duplication isn't in favor of the project maintainer's benefit.
Closes#3927
In dokku/dokku#3602 a new error page for the 502 status code was
introduced.
However, this error page is not currently being used, and results in a
404 error being served instead, because nginx is trying to load a
non-existent file:
```
open() "/var/lib/dokku/data/nginx-vhosts/dokku-errors/502-error.html" failed (2: No such file or directory)
```
Fix this by copying the `502-error.html` file into the `dokku-errors`
directory upon installation.
# History
## 0.20.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.4/bootstrap.sh
sudo DOKKU_TAG=v0.20.4 bash bootstrap.sh
```
### New Features
- #3936: @josegonzalez Enable limiting and reserving gpu resources
### Documentation
- #3937: @josegonzalez Add minor documentation for the kubernetes and nomad schedulers
### Other
- #3935: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.11.1 to 2.11.2 in /tests/apps/python-flask
- #3934: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.5 to 1.4.0 in /tests/apps/gogrpc
- #3933: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.27.v20200227 to 9.4.28.v20200408 in /tests/apps/java
# History
## 0.20.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.3/bootstrap.sh
sudo DOKKU_TAG=v0.20.3 bash bootstrap.sh
```
### New Features
- #3926: @josegonzalez Add proper support for various buildpack urls
### Other
- #3928: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.0 to 1.28.1 in /tests/apps/gogrpc
- #3925: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/python-flask
- #3924: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/multi
# History
## 0.20.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.2/bootstrap.sh
sudo DOKKU_TAG=v0.20.2 bash bootstrap.sh
```
### Bug Fixes
- #3921: @josegonzalez Correct container_type handling when entering containers
- #3919: @josegonzalez Fix bug with restarting containers not being routed to because of changing IP addresses
### New Features
- #3920: @josegonzalez Add the ability to list ssh keys for a specific user
# History
## 0.20.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.1/bootstrap.sh
sudo DOKKU_TAG=v0.20.1 bash bootstrap.sh
```
### Bug Fixes
- #3916: @josegonzalez Change error exit to warning when no apps exist
### New Features
- #3918: @josegonzalez Upgrade herokuish to 0.5.11
- #3915: @josegonzalez Add ability to check if a plugin has been installed
- #3914: @josegonzalez Add ability to change or disable the access/error log path
- #3913: @josegonzalez Upgrade herokuish
### Documentation
- #3907: @josegonzalez Add sponsoring link to issue template
- #3904: @jazzzz Update dokku-apt entry
- #3902: @josegonzalez Remove extra commas from network docs
### Other
- #3909: @dependabot-preview[bot] chore(deps): bump werkzeug from 1.0.0 to 1.0.1 in /tests/apps/python-flask
- #3903: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 172 to 173 in /tests/apps/php
# History
## 0.20.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.0/bootstrap.sh
sudo DOKKU_TAG=v0.20.0 bash bootstrap.sh
```
### Bug Fixes
- #3891: @josegonzalez Add missing cpio dependency
- #3861: @josegonzalez Fix app clone and rename calls
- #3682: @josegonzalez Force tty check to run with the default language
- #3853: @josegonzalez Add missing hooks to events plugin
### New Features
- #3899: @josegonzalez Drop unnecessary quotes on docker inspect calls
- #3895: @josegonzalez Expose network listeners to nginx templates for all process types
- #3893: @josegonzalez Rewrite apps plugin in golang
- #3889: @josegonzalez Update herokuish
- #3879: @josegonzalez Drop support for unsupported Debian and Ubuntu releases …
- #3880: @josegonzalez Remove unnecessary source/import statements
- #3871: @josegonzalez Rewrite proxy plugin in golang
- #3869: @josegonzalez Standardize plugin trigger calls
- #3870: @josegonzalez Use Println in favor of Fprintln for os.Stdout
- #3868: @josegonzalez Remove ps command
- #3866: @josegonzalez Unify nginx config commands
- #3865: @josegonzalez Cleanup injected docker labels
- #3860: @josegonzalez Remove deprecated egrep calls from codebase
- #3854: @josegonzalez Remove deprecated code
- #3852: @josegonzalez Standardize plugin code
- #3850: @josegonzalez DRY up reports in golang
- #3851: @josegonzalez Update herokuish to 0.5.6
- #3847: @josegonzalez Custom docker networking
- #3848: @josegonzalez Minor logging changes
- #3843: @josegonzalez Enable HSTS by default
- #3844: @josegonzalez Add global fallback for DOKKU_PROXY_PORT and DOKKU_PROXY_SSL_PORT
- #3609: @jayjun Start long running containers with --init with tests
- #3842: @josegonzalez rework docker-args-process trigger arguments
- #3841: @josegonzalez Implement docker-options:clear
### Documentation
- #3901: @Cellane 📝 Update information about Dokku CLI installation
- #3892: @josegonzalez Move code of conduct to .github org repository
- #3888: @decentral1se Mark 9+ for Debian version
- #3874: @josegonzalez Push users to upgrade to recent versions
- #3864: @alex-galey Change docs copyright to 2020
- #3863: @josegonzalez Update issue template to remove ambiguity around reporting
- #3849: @josegonzalez Reference correct property in network docs example
- #3840: @ollej Add link to fonts plugin
- #3838: @ltalirz Expand docs surrounding access control
### Other
- #3897: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.4 to 1.3.5 in /tests/apps/gogrpc
- #3896: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 3.1.1 to 3.1.2 in /tests/apps/java
- #3894: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.1 to 1.28.0 in /tests/apps/gogrpc
- #3885: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 171 to 172 in /tests/apps/php
- #3884: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.26.v20200117 to 9.4.27.v20200227 in /tests/apps/java
- #3877: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.3 to 1.3.4 in /tests/apps/gogrpc
- #3858: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 170 to 171 in /tests/apps/php
- #3855: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 169 to 170 in /tests/apps/php
- #3846: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.1 to 1.0.0 in /tests/apps/python-flask
- #3845: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.0 to 1.27.1 in /tests/apps/gogrpc
- #3833: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.26.0 to 1.27.0 in /tests/apps/gogrpc
- #3837: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.3 to 2.11.1 in /tests/apps/python-flask
- #3836: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.2 to 1.3.3 in /tests/apps/gogrpc
- #3829: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.0 to 0.16.1 in /tests/apps/python-flask
- #3830: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 166 to 169 in /tests/apps/php
This change allows users to specify a custom nginx.conf.sigil that can expose non-web process types to the outside world in addition to the web process type.
Closes#3258
A git push requires that the first four bytes should be the line length, so not suppressing the output results in a partially failed deploy.
https://stackoverflow.com/a/8175315/1515875
While the latest packages may continue to work on other releases, we will no longer officially support these releases, nor will we distribute packages.
Supporting versions more than a year old is difficult with a quick-moving project, and not worth the time that could be better spent fixing existing bugs/adding new functionality for an OSS project.
This change removes all deprecated commands. In many cases, users have been warned for a number of releases before the commands have been removed. All commands that were removed have existing alternatives.
This standardization makes it somewhat easier to read stacktraces as the command names are all uniform, so it will be slightly easier to scan trace output.
This unifies all the report-handling code so that plugins only need to worry about the data they wish to represent, and not the logic of actually returning it.
Containers can be attached:
- after they are created, but before they are started
- after a successful deploy, but before the proxy reloads
This allows folks to have flexibility around when they would like a container to be made available to a network.
This enables the HSTS header by default when an SSL certificate is in use. HSTS options can also be managed via the nginx:set command, which also exposes the ability to disable HSTS for your application.
The IMAGE_TAG is not always available, while the IMAGE_SOURCE_TYPE is. Since the point of these triggers was to unify the argument passed and make it easier to interact with them, this version makes more sense.
Closes#3780
The deployment documentation on scoping user access pointed only to the
development documentation for implementing plugins to handle user
scoping.
Added link to the dokku-acl plugin, which already handles user scoping
out of the box.
# History
## 0.19.12
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.12/bootstrap.sh
sudo DOKKU_TAG=v0.19.12 bash bootstrap.sh
```
### New Features
- #3819: @josegonzalez Allow binding nginx to specific IPv4/IPv6 interfaces
- #3818: @josegonzalez Add support for host-mode networking
### Documentation
- #3814: @treyssatvincent Use dokku:report to for listing domains
- #3809: @josegonzalez Document nginx:show-conf
- #3650: @vincelwt Clarify resource management for docker-local scheduler
- #3806: @kimar Make default vhost example listen to ipv6
### Other
- #3816: @dependabot-preview[bot] chore(deps): bump handlebars from 4.6.0 to 4.7.1 in /tests/apps/.websocket.disabled
- #3815: @dependabot-preview[bot] chore(deps): bump handlebars from 4.5.3 to 4.6.0 in /tests/apps/.websocket.disabled
- #3811: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 165 to 166 in /tests/apps/php
- #3812: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.24.v20191120 to 9.4.25.v20191220 in /tests/apps/java
- #3810: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.2 to 1.25.3 in /tests/apps/php
- #3808: @dependabot-preview[bot] chore(deps): [security] bump rack from 1.6.11 to 1.6.12 in /tests/apps/ruby
- #3807: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.1 to 1.26.0 in /tests/apps/gogrpc
- #3804: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 164 to 165 in /tests/apps/php
In host-mode, there is no 'bridge' network by default, so we return an invalid IP address of 'no value'. Instead, return '127.0.0.1' for those containers.
As there can be custom schedulers, including scheduler-specific information on the resource management page can be a disingenuous - the values don't map to kubernetes, for example - and thus we should call out to the scheduler docs (and underlying docker docs) to make the mapping more clear.
# History
## 0.19.10
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.10/bootstrap.sh
sudo DOKKU_TAG=v0.19.10 bash bootstrap.sh
```
### Bug Fixes
- #3784: @josegonzalez Ensure checks attempts are tracked per-check instead of globally
### New Features
- #3793: @josegonzalez Omit DWARF symbol table and debug information from go binaries
- #3792: @josegonzalez Unify property function implementations
### Documentation
- #3712: @fruitl00p Added new plugin
### Other
- #3790: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/python-flask
- #3791: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/multi
- #3787: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/multi
- #3788: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/python-flask
- #3785: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/python-flask
- #3786: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/multi
- #3748: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-dokku-scale
- #3749: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noappjson
- #3747: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/config
- #3746: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile
- #3741: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express
- #3783: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.23.v20191118 to 9.4.24.v20191120 in /tests/apps/java
- #3777: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 3.4.32 to 3.4.35 in /tests/apps/php
- #3774: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/python-flask
- #3779: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.1 to 1.25.2 in /tests/apps/php
- #3782: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.22.v20191022 to 9.4.23.v20191118 in /tests/apps/java
This will reduce the size of binaries in exchange for worse debugging output. This is acceptable for our users and worth it to save money on packagecloud package hosting - which is currently free under a given repository size.
Rather than reimplementing the property functions in two different languages - and potentially having compatibility issues - standardize on golang for the implementation through the use of a generated binary.
This also implements all the list functions for use with shell-based plugins.
Note that the interface to the prop binary is experimental, and it should not be used directly.
# History
## 0.19.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.9/bootstrap.sh
sudo DOKKU_TAG=v0.19.9 bash bootstrap.sh
```
### Bug Fixes
- #3781: @michaelshobbs Respect DOKKU_APP_USER in is_image_herokuish_based
### Other
- #3773: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.0 to 1.25.1 in /tests/apps/gogrpc
- #3772: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/multi
- #3778: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 3.4.32 to 3.4.35 in /tests/apps/php
- #3768: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.24.0 to 1.25.0 in /tests/apps/gogrpc
# History
## 0.19.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.7/bootstrap.sh
sudo DOKKU_TAG=v0.19.7 bash bootstrap.sh
```
### Documentation
- #3765: @znz Fix typo in desc of is_tls13_available
### Other
- #3739: @safeforge dokku run do not supports interactive mode.
- #3762: @dependabot-preview[bot] chore(deps): bump handlebars from 4.4.5 to 4.5.1 in /tests/apps/.websocket.disabled
# History
## 0.19.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.6/bootstrap.sh
sudo DOKKU_TAG=v0.19.6 bash bootstrap.sh
```
### Other
- #3761: @pithyless Fix type-errors in dokku-installer.py
- #3759: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 163 to 164 in /tests/apps/php
- #3758: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.21.v20190926 to 9.4.22.v20191022 in /tests/apps/java
# History
## 0.19.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.3/bootstrap.sh
sudo DOKKU_TAG=v0.19.3 bash bootstrap.sh
```
### Bug Fixes
- #3753: @josegonzalez Always use python3 for the installer
### Other
- #3743: @dependabot-preview[bot] chore(deps): [security] bump express from 3.1.2 to 4.17.1 in /tests/apps/.websocket.disabled
- #3744: @dependabot-preview[bot] chore(deps): [security] bump handlebars from 1.0.12 to 4.4.5 in /tests/apps/.websocket.disabled
- #3750: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile-bad
- #3745: @dependabot-preview[bot] chore(deps): [security] bump express from 3.3.8 to 4.17.1 in /tests/apps/gitsubmodules
- #3742: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noprocfile
- #3729: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.12.0 to 1.25.1 in /tests/apps/php
- #3732: @dependabot-preview[bot] chore(deps): bump silex/silex from 1.2.3 to 2.2.4 in /tests/apps/php
- #3728: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 7.6.0.v20120127 to 9.4.21.v20190926 in /tests/apps/java
- #3730: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.15.6 to 0.16.0 in /tests/apps/python-flask
- #3737: @dependabot-preview[bot] chore(deps): bump express3-handlebars from 0.2.3 to 0.5.2 in /tests/apps/.websocket.disabled
- #3734: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 59 to 163 in /tests/apps/php
- #3735: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 2.6.4 to 2.8.51 in /tests/apps/php
- #3723: @dependabot-preview[bot] chore(deps): bump sass-globbing from 1.1.1 to 1.1.5 in /tests/apps/multi
- #3731: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.1 to 2.10.3 in /tests/apps/python-flask
- #3736: @dependabot-preview[bot] chore(deps): bump socket.io from 0.9.19 to 2.3.0 in /tests/apps/.websocket.disabled
- #3726: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.23.0 to 1.24.0 in /tests/apps/gogrpc
- #3727: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 2.4 to 3.1.1 in /tests/apps/java
- #3733: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 2.6.4 to 2.8.50 in /tests/apps/php
- #3720: @dependabot-preview[bot] chore(deps): bump compass from 1.0.1 to 1.0.3 in /tests/apps/multi
- #3721: @dependabot-preview[bot] chore(deps): bump sinatra from 1.4.4 to 1.4.8 in /tests/apps/ruby
- #3719: @dependabot-preview[bot] chore(deps): bump thin from 1.6.1 to 1.7.2 in /tests/apps/ruby
This actually breaks compatability since now we drop python2 support completely, but it's worth it to fix the weird issues with trying to support both versions.
Closes#3740Closes#3752
Refs #3717
Ideally python usage goes away - the dokku-installer should become a mandatory cli command, and the plugin is rewritten in golang - but for now, we need to use the correct binary when running dokku.
Closes#3714
This adds the Nginx Trust Proxy plugin
This plugin allows dokku to be run behind (multiple) proxies in and gives developers the opportunity to support reverse proxy layers
After a `dokku run` container is created and started, this plugin trigger will allow developers to run auxiliary commands in response to that container.
This feature is allows users to add extra label metadata to one-off containers. As this can interfere with Dokku internals if they shadow labels used by plugins, care should be taken to avoid the `com.dokku` or `org.label-schema` namespace.
Also proper name run containers so they don't get random names from docker...
This change allows supporting the openresty package as installed on Ubuntu 18.04 from the official openresty package repository, while also returning general nginx support.
Closes#3675
It may be desirable to keep the contents of the git directory for the build process. Certain build tools can extract extra information from the .git directory, and some workflows may require that the shipped artifact has the entire source code available locally for later usage.
This change refactors the compiled golang plugins into 3 distinct binaries:
- commands: already existing
- subcommands/subcommands: entrypoint into all subcommands
- triggers: entrypoint into all triggers
It then further symlinks triggers and subcommands to the built binaries. This results in both a much faster build process as well as smaller package size.
This PR uses the new syntax for commands introduced in Docker 1.13, making it a bit easier to understand just what a particular command is trying to do.
This also pushes the long-form syntax for docker command flags, which are also easier to understand at a glance.
The version in DOKKU_ROOT may be incorrect for docker-based installs if that directory is mounted from an external volume. Instead, pull it from the DOKKU_LIB_ROOT directory, and respect the STABLE_VERSION if specified (VERSION will be the entire version, including commit sha).
This will allow background processes to cleanup these files if they were unable to be cleaned up during a run of the dokku binary, as is the case for files copied by the docker binary when running in docker.
This will allow those triggers to insert and extract files from the sourcecode work directory. Note that changes are not committed to this directory, nor will they be reflected in the committed codebase.
# History
## 0.18.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.1/bootstrap.sh
sudo DOKKU_TAG=v0.18.1 bash bootstrap.sh
```
### New Features
- #3636: @josegonzalez Unify deb and rpm creation code
- #3635: @josegonzalez Upgrade herokuish to 0.5.2
# History
## 0.18.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.0/bootstrap.sh
sudo DOKKU_TAG=v0.18.0 bash bootstrap.sh
```
### Bug Fixes
- #3627: @josegonzalez Make image removal synchronous
- #3618: @josegonzalez Ensure the dokku-retire timer is properly installed
- #3614: @alexquick Validate args for config:set and config:unset
- #3605: @josegonzalez Handle case where there are empty newlines in the authorized_keys file
- #3603: @josegonzalez Drop extra % sign in common.LogVerboseQuiet
- #3597: @josegonzalez Allow default trace function to work
### New Features
- #3628: @josegonzalez Handle file copying in a secure and reliable fashion
- #3630: @josegonzalez Fix issue where push warning on bad branch was skipped
- #3629: @josegonzalez Avoid calling the user-auth trigger where possible
- #3626: @josegonzalez Builder plugins
- #3599: @josegonzalez Scope docker-cleanup to specific app
- #3589: @michaelshobbs Allow running Dokku in Docker
- #3607: @josegonzalez Purge cache using herokuish image
- #3602: @alexymik Create a 502 error page to automatically refresh if backend status changes
- #3600: @josegonzalez Refactor IsImageHerokuishBased to match shell version
### Documentation
- #3625: @josegonzalez Remove old reference to SPONSORS.md
- #3619: @josegonzalez Cleanup plugin creation docs
- #3612: @jayjun Improve testing docs
- #3613: @Lyelt Remove all uses of proxy_set_header Connection "upgrade"
- #3596: @josegonzalez Add missing hooks to events plugin and plugin triggers docs
### Tests
- #3610: @jayjun Correct Bats path in single tests
If you are running docker in docker, the permissions on the generated file are such that they may not be accessible by the normal dokku user. For dokku, it is good enough to ignore the failed removal.
If "docker cp" is run within docker, it seems the owner is root, resulting in other processes not being able to directly read the file without resorting to `cat` trickery. Doing this in a single place avoids the problem completely.
Asynchronous image removal would remove intermediate build images during the build process, causing intermittent build failures for users of multi-stage dockerfiles. While we still remove intermediate docker images that may be used in the current build, we now do so during the deploy, ensuring that there are no intermediate build failures in the future.
Closes#3474
As this trigger is always in the execution path, `plugn` starts and expensively checks to see if it can execute the trigger. Rather than call this on every invocation, skip the trigger if no non-core implementation exists.
This is a "one-shot" ability, meaning that it is highly discouraged for multiple plugins to implement the triggers.
The `builder-create-dokku-image` trigger is meant to modify the base DOKKU_IMAGE that will be used to build an application. A good use of the hook is to inject system packages by:
- calculating an image tag from the set of system packages
- checking that the image doesnt already exist
- creating the image if it does not
As the output is sent to stdout, we have to find an alternative way of fetching the new DOKKU_IMAGE. The `builder-dokku-image` trigger can output an image tag based on the calculated image tag. If no tag is output, then the DOKKU_IMAGE is used as is.
Using this pattern, users can efficiently modify the base image in use for an app without duplicating the work on every push. This is especially useful for package installation, where packages are required for app building, but may take a long time and can be error prone.
A builder plugin implements some method for 'building' artifacts from a given source code archive. This refactor moves the majority of the image building code into separate plugins, allowing us to implement other builders, but also simplifying the common pugin codebase.
Also move the pre-build-buildpack hook from the build-env plugin to builder-herokuish.
This reduces duplication and allows users to rely on global arguments to generate most labels needed.
The 'commit' command cannot have global arguments because the whitespace within the label change breaks string-based interpolation, and shell arrays cannot be exported.
The plugin creation docs were hard to follow, unnecessarily complicating issues for developers. The new format should make the recommendations clear, and align examples with the core code.
[ci skip]
In some cases, the cache directory may exist but there may be no app image to use for cache purging. This may be the case if the app was never deployed.
Instead of failing, we can simply use the configured herokuish image for clearing cache, as that image is the base image for anything that would have modified cache.
# History
## 0.17.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.9/bootstrap.sh
sudo DOKKU_TAG=v0.17.9 bash bootstrap.sh
```
### Bug Fixes
- #3593: @JakeAngell Fix nginx template for https in "Connection" header
### Documentation
- #3595: @josegonzalez Drop extra help output for trace
# History
## 0.17.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.8/bootstrap.sh
sudo DOKKU_TAG=v0.17.8 bash bootstrap.sh
```
### Bug Fixes
- #3591: @palfrey Allow SSH keys with no ending newline
### New Features
- #3587: @josegonzalez feat: drop make and gcc as dependencies
# History
## 0.17.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.6/bootstrap.sh
sudo DOKKU_TAG=v0.17.6 bash bootstrap.sh
```
### New Features
- #3578: @josegonzalez Allow omitting resource args by setting DOKKU_OMIT_RESOURCE_ARGS
This change allows operators to specify a DOCKER_BIN environment variable. This will specify a binary to run when executing docker, which is useful in cases where the 'docker' command being run must be modified in a way that would otherwise be invasive to Dokku, but minimalistic if done within a wrapper.
The post-delete hook will delete config, and thus scheduler-post-delete is the best place to actually delete resources where some local config may be necessary in order to reference resources.
# History
## 0.17.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.3/bootstrap.sh
sudo DOKKU_TAG=v0.17.3 bash bootstrap.sh
```
### Bug Fixes
- #3570: @znz Fix typos in trace help
### New Features
- #3574: @josegonzalez Add support for pulling app status from scheduler plugins
- #3571: @znz Simplify hostname_regex
`[a-z0-9\.\*-]+` includes `\.` and `[a-z0-9\*-]+`.
So I think `^([a-z0-9\.\*-]+\.)*[a-z0-9\*-]+$` means last char is `[a-z0-9\*-]`
and other optional chars are `[a-z0-9\.\*-]*`.
A DOKKU_SCALE file will always be used for managing the scale count for an app if it exists in a repository. As such, ps:scale usage should be disabled in those cases. This commit makes that more apparent.
Also document how to build a specific core plugin for testing purposes.
Closes#3544
This was removed in c9bbddcfcb as it was more complicated for operators to figure out _exactly_ which combination of limits/reservations would apply to their applications. Unfortunately, the documentation was never updated.
We may re-add this functionality in the future, but for now, cleaning up the docs is the best option.
[ci skip]
# History
## 0.16.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.4/bootstrap.sh
sudo DOKKU_TAG=v0.16.4 bash bootstrap.sh
```
### Bug Fixes
- #3547: @josegonzalez Correct retrieval of resource values for alternative schedulers
### New Features
- #3546: @josegonzalez Add ability to trigger an arbitrary plugin hook
This is useful in cases where the command output must be tested, but it is otherwise embedded in a specific part of the dokku core.
As the 'plugin' commands require root, this is safe to add to the core.
# History
## 0.16.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.3/bootstrap.sh
sudo DOKKU_TAG=v0.16.3 bash bootstrap.sh
```
### Bug Fixes
- #3541: @josegonzalez Handle case where image is null on first deploy
### New Features
- #3543: @josegonzalez Add ability to clear global domains
- #3517: @josegonzalez SSH key updates
- #3538: @josegonzalez Silence dokku run 'errors'
### Documentation
- #3523: @MarcDiethelm Add an example how to specify a Dockerfile for deployment
- #3539: @josegonzalez Warn users when ufw is enabled
If the subdomain is url-like, assume it is a valid url and use it for the default domain name. This allows users to specify the default domain for an app even if that is a subdomain of a global vhost.
Closes#3529
> If you're using Dokku - especially for commercial purposes - consider donating to project development via [OpenCollective](https://opencollective.com/dokku) or [Patreon](https://www.patreon.com/dokku). Funds go to general development, support, and infrastructure costs.
>
> If you'd like to sponsor specific functionality, see the project's [Sponsoring](https://github.com/dokku/.github/blob/master/SPONSORING.md) document.
>
> If you need help figuring out how to use a specific buildpack, or are having issues using multiple buildpacks, please see our [irc or slack channels](http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/#the-irc-and-slack-channels). Issues pertaining to buildpacks may be closed and locked.
>
> If you need support for a version of Dokku that is more than a year old, your issue may be closed without an answer. Please upgrade to a recent version.
## Description of problem
@@ -16,6 +20,8 @@
#### Expected Results
<-- Please replace APP_NAME with the name of your app -->
## Environment Information
### `dokku report APP_NAME` output
@@ -23,16 +29,14 @@
> This is required! Issues missing this information may be closed.
>
> For problems affecting all applications, the report output for a broken application is useful for our debugging.
> You may also run `dokku report` without any arguments to display the top-level reporting information.
> In these cases, you may run `dokku report` without any arguments to display the top-level reporting information.
### How (deb/make/rpm) and where (AWS, VirtualBox, physical, etc.) was Dokku installed?:
### Additional information
- Container Inspect Output (if applicable):
-0.13.0+: `dokku inspect APP_NAME`
- <0.13.0: `docker inspect CONTAINER_ID`: WARNING, `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.
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
-The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable):
- If a deploy is failing or behaving unexpectedly:
- Application name
@@ -40,5 +44,5 @@
- 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 traceon`
(BEWARE: `traceon` 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):
- 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 XXXXXX):
echo"For dokku to build containers, it is strongly suggested that you have 1024 megabytes or more of free memory"
echo"If necessary, please consult this document to setup swap: http://dokku.viewdocs.io/dokku/advanced-installation/#vms-with-less-than-1gb-of-memory"
echo"If necessary, please consult this document to setup swap: http://dokku.viewdocs.io/dokku/getting-started/advanced-installation/#vms-with-less-than-1-gb-of-memory"
print"Listening on 0.0.0.0:{0}, CTRL+C to stop".format(port)
print("Listening on 0.0.0.0:{0}, CTRL+C to stop".format(port))
httpd.serve_forever()
@@ -294,6 +360,9 @@ PAGE = """
<small class="form-text text-muted">When enabled, Nginx will be run on port 80 and proxy requests to apps based on hostname.</small>
<small class="form-text text-muted">When disabled, a specific port will be setup for each application on first deploy, and requests to that port will be proxied to the relevant app.</small>
</div>
<div class="alert alert-warning small mt-3 d-{UFW_DISPLAY}" role="alert">
<strong>Warning:</strong> UFW is active. To allow traffic to specific ports, run <code>sudo ufw allow PORT</code> for the port in question.
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](/docs/advanced-usage/persistent-storage.md) for more details.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your application.
@@ -34,7 +34,7 @@ Each "phase" has different expectations and limitations:
Please keep the above in mind when utilizing deployment tasks.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation) docs for more information on building your own custom plugin.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation.md) docs for more information on building your own custom plugin.
@@ -147,4 +147,4 @@ By default, Dokku will execute your buildpack application processes as the `hero
> NOTE: this user must exist in your herokuish image.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [scheduler-docker-local documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
You can check if a plugin has been installed via the `plugin:installed` command:
```shell
dokku plugin:installed postgres
```
Installing a plugin is easy as well using the `plugin:install` command. This command will also trigger the `install` pluginhook on all existing plugins.
@@ -16,7 +16,7 @@ The resource plugin is meant to allow users to limit or reserve resources for a
By default, Dokku allows unlimited resource access to apps deployed on a server. In some cases, it may be desirable to limit this on a per-app or per-process-type basis. The `resource` plugin allows management of both resource "limits" and resource "reservations", where each resource request type has specific meaning to the scheduler in use for a given app.
> The meaning of a values and it's units are specific to the scheduler in use for a given app. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
> Warning: The meaning of a values and it's units are specific to the scheduler in use for a given app. If a value is incorrect for a scheduler, this may result in containers failing to start correctly. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
Valid resource options include:
@@ -26,6 +26,9 @@ Valid resource options include:
-`--network`
-`--network-ingress`
-`--network-egress`
-`--nvidia-gpu`
See the [Supported Resource Management Properties](/docs/advanced-usage/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
Running the `resource:limits` command without any flags will display the currently configured app reservation.
Running the `resource:limit` command without any flags will display the currently configured default app limits.
```shell
dokku resource:limits node-js-app
=====> resource limits node-js-app information
dokku resource:limit node-js-app
```
```
=====> resource limits node-js-app information [defaults]
cpu:
memory:
memory-swap: 100
network: 100
network-ingress:
network-egress:
nvidia-gpu:
```
This may also be combined with the `--process-type` flag to see app limits on a process-type level. Note that the displayed values are not merged with the defaults.
```shell
dokku resource:limit --process-type web node-js-app
```
```
=====> resource limits node-js-app information (web)
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
```
#### Global Resource Limits
By default, Dokku does not limit any resources, though these can be specified at the server level via the `--global` flag on the `resource:limit` command.
```shell
dokku resource:limit --global --memory 200
```
```
=====> Setting default resource limits
memory: 200
```
This may also be combined with the `--process-type` flag to set global limits on a process-type level:
```shell
dokku resource:limit --global --memory 150 --process-type web node-js-app
```
```
=====> Setting default resource limits (web)
memory: 150
```
#### Displaying Global Resource Limits
Running the `resource:limit` command with only the `--global` flag will display the currently configured default limits.
```shell
dokku resource:limit --global
```
```
=====> resource limits default information
cpu:
memory: 200
memory-swap:
network:
network-ingress:
network-egress:
```
This may also be combined with the `--process-type` flag to see global limits on a process-type level:
Running the `resource:reserve` command without any flags will display the currently configured app reservation.
Running the `resource:reserve` command without any flags will display the currently configured default app reservations.
```shell
dokku resource:reserve node-js-app
=====> resource reservation node-js-app information
```
```
=====> resource reservation node-js-app information [defaults]
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
nvidia-gpu:
```
#### Global Resource Reservations
By default, Dokku does not reserve any resources, though these can be specified at the server level via the `--global` flag on the `resource:reserve` command.
This may also be combined with the `--process-type` flag to see app reservations on a process-type level. Note that the displayed values are not merged with the defaults.
```shell
dokku resource:reserve --global --memory 200
dokku resource:reserve --process-type web node-js-app
```
```
=====> Setting default resource reservation
memory: 200
```
This may also be combined with the `--process-type` flag to set global reservations on a process-type level:
```shell
dokku resource:reserve --global --memory 150 --process-type web node-js-app
```
```
=====> Setting default resource reservation (web)
memory: 150
```
#### Displaying Global Resource Reservations
Running the `resource:reserve` command with only the `--global` flag will display the currently configured default reservation.
```shell
dokku resource:reserve --global
```
```
=====> resource reservation default information
cpu:
memory: 200
=====> resource reservation node-js-app information (web)
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
```
This may also be combined with the `--process-type` flag to see global reservations on a process-type level:
```shell
dokku resource:reserve --global --process-type web
```
```
=====> resource reservation default information (web)
These scheduler implementations may not be complete, though provide enough functionality for a user to get an app deployed via the underlying scheduler.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
@@ -44,15 +44,18 @@ This plugin implements various functionality through `plugn` triggers to integra
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-app-rename-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-app-status`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-logs-failed`
-`scheduler-is-deployed`
-`scheduler-logs`
-`scheduler-logs-failed`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
@@ -65,10 +68,16 @@ The `docker-local` scheduler supports a minimal list of resource _limits_ and _r
### Resource Limits
- cpu: (docker option: `--cpus`), and is specified in number of CPUs a process can access.
-memory: (docker option: `--memory`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory-swap: (docker option: `--memory-swap`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
-See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
### Resource Reservations
- memory: (docker option: `--memory-reservation`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
The following commands were previously deprecated and were removed in this release.
-`apps`: Use `apps:list` instead.
-`certs`: Use `certs:report` instead.
-`certs:info`: Use `certs:report` instead.
-`checks`: Use `checks:report` instead.
-`docker-options`: Use `docker-options:report` instead.
-`domains`: Use `domains:report` instead.
-`plugin`: Use `plugin:list` instead.
-`proxy`: Use `proxy:report` instead.
-`trace`: Use `trace:on` or `trace:off` instead.
-`ps`: Use `enter` with a container ID instead to run `ps auxww` within a container.
The refactor of the proxy plugin removes the following functions from being sourced in plugins:
-`proxy#get_app_proxy_port_map()`
-`proxy#list_app_proxy_ports()`
-`proxy#filter_app_proxy_ports()`
-`proxy#add_proxy_ports()`
-`proxy#remove_proxy_ports()`
-`proxy#set_proxy_ports()`
The informal policy is to allow removal of functions within a `functions` file if they are not used in OSS plugins. Should you be affected by any such removals, please file an issue to expose the functionality via a plugin trigger.
### Function renames
-`tar#tar_in_cmd` was renamed to `tar#cmd-tar-in`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
-`tar#tar_from_cmd` was renamed to `tar#cmd-tar-from`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
### Remove support for Unsupported Operating Systems
Dokku will no longer distribute packages for Ubuntu versions that have reached either End of Life or End of Standard Support (for LTS releases). This currently includes the following releases:
- Ubuntu 14.04 (trusty)
- Ubuntu 14.10 (utopic)
- Ubuntu 15.04 (vivid)
- Ubuntu 15.10 (wily)
- Ubuntu 16.10 (yakkety)
- Ubuntu 17.04 (zesty)
- Ubuntu 17.10 (artful)
Dokku will no longer distribute packages for Debian versions that are not `stable` or `oldstable`. This currently includes the following releases:
- Debian 7 (wheezy)
- Debian 8 (jessie)
### App report flags
The `--git-sha` flag was moved from the `apps:report` command to the `git:report` command.
## Changes
### App report flags
The following changes on the `apps:report` command were made in this release:
- The `--deploy-source` flag was renamed to `--app-deploy-source`.
- The `--locked` flag was renamed to `--app-locked`.
### Network report flags
The following changes on the `network:report` command were made in this release:
- The `--network-listeners` flag was renamed to `--network-web-listeners`.
### Plugin Triggers
- The `network-get-port` trigger was incorrectly documented to have the `isHerokuishContainer` argument as the third argument. The code has been fixed to respect the documentation.
- The `network-get-listeners` trigger now takes an additional `processType` argument. If not specified, it defaults to `web`. This default will be removed in an upcoming release.
## Deprecations
-`nginx:show-conf` has been deprecated in favor of `nginx:show-config`.
-`proxy#is_app_proxy_enabled()` is deprecated in favor of `plugn trigger proxy-is-enabled`.
-`proxy#get_app_proxy_type()` is deprecated in favor of `plugn trigger proxy-type`.
-`apps#apps_create()` is deprecated in favor of `plugn trigger app-create`.
-`apps#apps_destroy()` is deprecated in favor of `plugn trigger app-destroy`.
-`apps#apps_exists()` is deprecated in favor of `plugn trigger app-exists`.
-`apps#apps_maybe_create()` is deprecated in favor of `plugn trigger app-maybe-create`.
-`plugin trigger network-get-listeners` usage without a second `processType` argument is deprecated.
-`.NGINX_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_PORT`.
-`.NGINX_SSL_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_SSL_PORT`.
-`.DOKKU_APP_LISTENERS` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.DOKKU_APP_WEB_LISTENERS`.
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
## Deprecations
-`git#git_deploy_branch()` is deprecated in favor of `plugn trigger git-deploy-branch`.
- The `config` command is deprecated in favor of `config:show`.
- Usage of this command in conjunction with either the `--export` or `--shell` flag is deprecated in favor of `config:export --format` with the correct format value (`exports` or `shell`, respectively).
- The `nginx:build-config` command is deprecated in favor of `proxy:build-config`.
## Removals
The `apps:destroy` command no longer takes a second argument `force`. Instead, this can be passed as the `--force` flag, either globally or as a flag to the command itself.
The `proxy:enable` and `proxy:disable` no longer restart apps when setting the `DOKKU_DISABLE_PROXY` environment variable. A future release will disable usage of `DOKKU_DISABLE_PROXY` altogether.
@@ -4,40 +4,9 @@ Given the constraints, running Dokku commands remotely via SSH is fine. For cert
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`
## Official Client
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`.
See the [remote commands documentation](/docs/deployment/remote-commands.md) for more information on how to install and use the official client.
## (nodejs) dokku-toolbelt
@@ -51,7 +20,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):
@@ -18,29 +18,30 @@ Let's take a quick look at the current Dokku nginx plugin that's shipped with Do
[See the full documentation](/docs/development/plugin-creation.md).
## Official Plugins (Beta)
## Official Plugins
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. Please file issues against their respective issue trackers.
<sup>1</sup> On Heroku similar functionality is offered by the [heroku-labs pipeline feature](https://devcenter.heroku.com/articles/labs-pipelines), which allows you to promote builds across multiple environments (staging -> production)
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>4</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>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)
domains:add <app> <domain> [<domain> ...] # Add domains to app
domains:add-global <domain> [<domain> ...] # Add global domain names
domains:clear <app> # Clear all domains for app
domains:clear-global # Clear global domain names
domains:disable <app> # Disable VHOST support
domains:enable <app> # Enable VHOST support
domains:remove <app> <domain> [<domain> ...] # Remove domains from app
@@ -27,21 +28,10 @@ scheme://subdomain.domain.tld
The `subdomain` is inferred from the pushed application name, while the `domain.tld` is set during initial dokku configuration. It can then be modified with `dokku domains:add-global` and `dokku domains:remove-global`. This value is used as a default TLD for all applications on a host.
If a FQDN such as `other.tld` is used as the application name, the global virtualhost 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`.
If an FQDN such as `dokku.org` is used as the application name, the global virtualhost will be ignored and the resulting vhost URL for that application will be `dokku.org`.
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:
You can optionally override this in a plugin by implementing the `nginx-hostname` plugin trigger. If the `nginx-hostname` plugin has no output, the normal hostname algorithm will be executed. See the [plugin trigger documentation](/docs/development/plugin-triggers.md#nginx-hostname) for more information.
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";SUBDOMAIN="$2";VHOST="$3"
NEW_SUBDOMAIN=`echo$SUBDOMAIN| rev`
echo"$NEW_SUBDOMAIN.$VHOST"
```
If the `nginx-hostname` plugin has no output, the normal hostname algorithm will be executed.
## Disabling VHOSTS
@@ -63,7 +53,7 @@ The domains plugin allows you to specify custom domains for applications. This p
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.
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
```nginx
server{
listen80default_server;
server_name_;
access_logoff;
return410;
}
# To handle HTTPS requests, you can uncomment the following section.
#
# Please note that in order to let this work as expected, you need a valid
# SSL certificate for any domains being served. Browsers will show SSL
# errors in all other cases.
#
# Note that the key and certificate files in the below example need to
# be copied into /etc/nginx/ssl/ folder.
#
# server {
# listen 443 ssl;
# server_name _;
# ssl_certificate /etc/nginx/ssl/cert.crt;
# ssl_certificate_key /etc/nginx/ssl/cert.key;
# access_log off;
# return 410;
# }
```
Make sure to reload nginx after creating this file by running `service nginx reload`.
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).
The configuration file must be loaded before `/etc/nginx/conf.d/dokku.conf`, so it can not be arranged as a vhost in `/etc/nginx/sites-enabled` that is only processed afterwards.
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.
This is specific to your proxy plugin of choice. See the [nginx documentation](/docs/configuration/nginx.md#default-site) for more information on how to configure this for the default nginx proxy implementation.
config:export (<app>|--global) [--envfile] Export a global or app environment
config:get (<app>|--global) KEY Display a global or app-specific config value
config:keys (<app>|--global) [--merged] Show keys set in environment
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
config:unset [--no-restart] (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
config:export (<app>|--global) [--envfile] Export a global or app environment
config:keys (<app>|--global) [--merged] Show keys set in environment
config:bundle (<app>|--global) [--merged] Bundle environment into tarfile
```
> 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).
The following list config variables have special meaning and can be set in a variety of ways.
The following config variables have special meanings and can be set in a variety of ways. Unless specified via global app config, the values may not be passed into applications. Usage of these values within applications should be considered unsafe, as they are an internal configuration values that may be moved to the internal properties system in the future.
> Warning: This list is not exhaustive, and may vary from version to version.
@@ -89,10 +90,11 @@ The following list config variables have special meaning and can be set in a var
| `DOKKU_EVENTS_LOGFILE` | `$DOKKU_LOGS_DIR/events.log` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where the events log file is written to. |
| `DOKKU_APP_NAME` | none | `--app APP` flag | Name of application to work on. Respected by core plugins. |
| `DOKKU_APPS_FORCE_DELETE` | none | `--force` flag | Whether to force delete an application. Also used by other plugins for destructive actions. |
| `DOKKU_CHECKS_URL` | `http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Whether to detach a container started via `dokku run`. |
| `DOKKU_QUIET_OUTPUT` | none | `--quiet` flag | Silences certain header output for `dokku` commands. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> `--rm-container` flag <br /> `--rm` flag | Whether to keep `dokku run` containers around or not. |
| `DOKKU_TRACE` | none | `dokku traceon` <br /> `dokku trace false` <br /> `--trace` flag | Turn on very verbose debugging. |
| `DOKKU_TRACE` | none | `dokku trace:on` <br /> `dokku trace:off` <br /> `--trace` flag | Turn on very verbose debugging. |
| `DOKKU_APP_SHELL` | `/bin/bash` | `dokku config:set` | Allows users to change the default shell used by Dokku for `dokku enter` and execution of deployment tasks. |
@@ -113,13 +115,15 @@ The following list config variables have special meaning and can be set in a var
| `DOKKU_SKIP_CLEANUP` | | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | When a deploy is triggered, if this is set to a non-empty value, then old docker containers and images will not be removed. |
| `DOKKU_START_CMD` | none | `dokku config:set` | Command to run instead of `/start $PROC_TYPE` |
| `DOKKU_SYSTEM_GROUP` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System group to chown files as. |
| `DOKKU_SYSTEM_USER` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System user to chown files as. |
| `DOKKU_WAIT_TO_RETIRE` | `60` | `dokku config:set` | After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections. |
nginx:validate-config [<app>] [--clean] # Validates and optionally cleans up invalid nginx configurations
```
## Binding to specific addresses
> New as of 0.19.2
By default, nginx will listen to all interfaces (`[::]` for IPv6, `0.0.0.0` for IPv4) when proxying requests to applications. This may be changed using the `bind-address-ipv4` and `bind-address-ipv6` properties. This is useful in cases where the proxying should be internal to a network or if there are multiple network interfaces that should respond with different content.
This may be reverted by setting an empty bind address.
```shell
dokku nginx:set node-js-app bind-address-ipv4
dokku nginx:set node-js-app bind-address-ipv6
```
> Warning: Validation is not performed on either value.
Users with apps that contain a custom `nginx.conf.sigil` file will need to modify the files to respect the new `NGINX_BIND_ADDRESS_IPV4` and `NGINX_BIND_ADDRESS_IPV6` variables.
## HSTS Header
> New as of 0.20.0
If SSL certificates are present, HSTS will be automatically enabled. It can be toggled via `nginx:set`:
```shell
dokku nginx:set node-js-app hsts true
dokku nginx:set node-js-app hsts false
```
The following options are also available via the `nginx:set` command:
-`hsts` (type: boolean, default: `true`): Enables or disables HSTS for your application.
-`hsts-include-subdomains` (type: boolean, default: `true`): Tells the browser that the HSTS policy also applies to all subdomains of the current domain.
-`hsts-max-age` (type: integer, default: `15724800`): Time in seconds to cache HSTS configuration.
-`hsts-preload` (type: boolean, default: `false`): Tells most major web browsers to include the domain in their HSTS preload lists.
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 until the max-age is reached.
## Checking access logs
You may check nginx access logs via the `nginx:access-logs` command. This assumes that app access logs are being stored in `/var/log/nginx/$APP-access.log`, as is the default in the generated `nginx.conf`.
@@ -37,36 +81,81 @@ You may also follow the logs by specifying the `-t` flag.
dokku nginx:error-logs node-js-app -t
```
## Regenerating nginx config
## Changing log path
In certain cases, your app nginx configs may drift from the correct config for your app. You may regenerate the config at any point via the `nginx:build-config` command. This may fail if there are no current web listeners for your app.
> New as of 0.20.1
The path to where log files are stored can be changed by calling the `nginx:set` command with the following options:
The defaults should not be changed without verifying that the paths will be writeable by nginx. However, this setting is useful for enabling or disabling logging by setting the values to `off`.
```shell
dokku nginx:build-config node-js-app
dokku nginx:set node-js-app access-log-path off
dokku nginx:set node-js-app error-log-path off
```
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app access-log-path
dokku nginx:set node-js-app error-log-path
```
In all cases, the nginx config must be regenerated after setting the above values.
## Specifying a read timeout
> New as of 0.21.0
When proxying requests to your applications, it may be useful to specify a proxy read timeout. This can be done via the `nginx:set` command as follows:
The default value is `60s`, and all numeric values _must_ have a trailing time value specified (`s` for seconds, `m` for minutes).
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app proxy-read-timeout
```
In all cases, the nginx config must be regenerated after setting the above value.
## Showing the nginx config
For debugging purposes, it may be useful to show the nginx config. This can be achieved via the `nginx:show-config` command.
```shell
dokku nginx:show-config node-js-app
```
## Validating nginx configs
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate-config` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
```shell
dokku nginx:validate
dokku nginx:validate-config
```
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate` command is the exit code of `nginx -t` against the server's real nginx config.
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate-config` command is the exit code of `nginx -t` against the server's real nginx config.
The `nginx:validate` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
The `nginx:validate-config` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
> Warning: Invalid app nginx config's will be removed _even if_ the config is valid in the global server context.
```shell
dokku nginx:validate --clean
dokku nginx:validate-config --clean
```
The `--clean` flag may also be specified for a given app:
```shell
dokku nginx:validate node-js-app --clean
dokku nginx:validate-config node-js-app --clean
```
## Customizing the nginx configuration
@@ -77,8 +166,9 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
- Copy the following example template to a file named `nginx.conf.sigil` and either:
- If using a buildpack application, you __must__ check it into the root of your app repo.
-`ADD` it to your dockerfile `WORKDIR`
-if your dockerfile has no `WORKDIR`, `ADD` it to the `/app` folder
-If using a dockerfile or docker image for deploys, either:
-If WORKDIR is specified, add the file to the `WORKDIR` specified in the last Dockerfile stage (example: `WORKDIR /app` and `ADD nginx.conf.sigil /app`).
- If no WORKDIR is specified, add the file to the root (`/`) of the docker image (example:ADD nginx.conf.sigil /`).
> When using a custom `nginx.conf.sigil` file, depending upon your application configuration, you *may* be exposing the file externally. As this file is extracted before the container is run, you can, safely delete it in a custom `entrypoint.sh` configured in a Dockerfile `ENTRYPOINT`.
@@ -90,7 +180,6 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
{{ .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
{{ .PROXY_PORT }} Non-SSL nginx listener port (same as `DOKKU_PROXY_PORT` config var)
{{ .PROXY_SSL_PORT }} SSL nginx listener port (same as `DOKKU_PROXY_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
@@ -101,6 +190,8 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an `.DOKKU_APP_${PROCESS_TYPE}_LISTENERS` variable - the `PROCESS_TYPE` will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
> Note: Application config variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
### Customizing via configuration files included by the default templates
@@ -125,7 +216,7 @@ The example above uses additional configuration files directly on the Dokku host
For PHP Buildpack users, you will also need to provide a `Procfile` and an accompanying `nginx.conf` file to customize the nginx config *within* the container. The following are example contents for your `Procfile`
Your `nginx.conf` file - not to be confused with Dokku's `nginx.conf.sigil` - would also need to be configured as shown in this example:
client_max_body_size 50m;
@@ -146,38 +237,78 @@ By default, Dokku provides custom error pages for the following three categories
These are provided as an alternative to the generic Nginx error page, are shared for _all_ applications, and their contents are located on disk at `/var/lib/dokku/data/nginx-vhosts/dokku-errors`. To customize them for a specific app, create a custom `nginx.conf.sigil` as described above and change the paths to point elsewhere.
## 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.
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
```nginx
server{
listen80default_server;
listen[::]:80default_server;
server_name_;
access_logoff;
return410;
}
# To handle HTTPS requests, you can uncomment the following section.
#
# Please note that in order to let this work as expected, you need a valid
# SSL certificate for any domains being served. Browsers will show SSL
# errors in all other cases.
#
# Note that the key and certificate files in the below example need to
# be copied into /etc/nginx/ssl/ folder.
#
# server {
# listen 443 ssl;
# listen [::]:443 ssl;
# server_name _;
# ssl_certificate /etc/nginx/ssl/cert.crt;
# ssl_certificate_key /etc/nginx/ssl/cert.key;
# access_log off;
# return 410;
# }
```
Make sure to reload nginx after creating this file by running `service nginx reload`.
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).
The configuration file must be loaded before `/etc/nginx/conf.d/dokku.conf`, so it can not be arranged as a vhost in `/etc/nginx/sites-enabled` that is only processed afterwards.
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.
## Domains plugin
See the [domain configuration documentation](/docs/configuration/domains.md).
See the [domain configuration documentation](/docs/configuration/domains.md) for more information on how to configure domains for your app.
## Customizing hostnames
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames).
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames) for more information on how to configure domains for your app.
## Disabling VHOSTS
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts).
## Default site
See the [default site documentation](/docs/configuration/domains.md#default-site).
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts) for more information on how to disable domain usage for your app.
## Running behind a load balancer
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer).
## HSTS Header
See the [HSTS documentation](/docs/configuration/ssl.md#hsts-header).
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer) for more information on how to configure your nginx config for running behind a network load balancer.
## SSL Configuration
See the [ssl documentation](/docs/configuration/ssl.md).
See the [ssl documentation](/docs/configuration/ssl.md) for more information on how to configure SSL certificates for your application.
## Disabling Nginx
See the [proxy documentation](/docs/advanced-usage/proxy-management.md).
See the [proxy documentation](/docs/advanced-usage/proxy-management.md) for more information on how to disable nginx as the proxy implementation for your app.
## Managing Proxy Port mappings
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#proxy-port-mapping).
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#proxy-port-mapping) for more information on how to manage ports proxied for your app.
## Regenerating nginx config
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#regenerating-proxy-config) for more information on how to rebuild the nginx proxy configuration for your app.
@@ -9,6 +9,7 @@ certs:add <app> CRT KEY # Add an ssl endpoint to an app. Can al
certs:generate <app> DOMAIN # Generate a key and certificate signing request (and self-signed certificate)
certs:remove <app> # Remove an SSL Endpoint from an app.
certs:report [<app>] [<flag>] # Displays an ssl report for one or more apps
certs:show <app> <crt|key> # Show the server.crt or server.key on stdout
certs:update <app> CRT KEY # Update an SSL Endpoint on an app. Can also import from a tarball on stdin
```
@@ -56,6 +57,16 @@ If you decide to obtain a CA signed certificate, you can import that certificate
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.
### Showing the certificate
The `certs:show` command can be used to show your configured certs for an app. The show command can be used for example to export Let's Encrypt certificates
after they've been generated. You can export it as follows:
You can pass flags which will output only the value of the specific information you want. For example:
```shell
dokku certs:report node-js-sample --ssl-enabled
dokku certs:report node-js-app --ssl-enabled
```
## 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 enables this header by default for HTTPS requests.
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.
See the [NGINX HSTS documentation](/docs/configuration/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
## HTTP/2 support
@@ -125,7 +136,7 @@ Certain versions of nginx have bugs that prevent [HTTP/2](https://nginx.org/en/d
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-Port` and `X-Forwarded-For`. 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](/docs/configuration/nginx.md#customizing-the-nginx-configuration)
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 a [custom nginx template](/docs/configuration/nginx.md#customizing-the-nginx-configuration). The following is a simple example of how to do so.
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.
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.
Once the deploy is complete, the application's web URL will be generated as above.
Dokku supports deploying applications via [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) with [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks), as well as by using a project's [Dockerfile](https://docs.docker.com/reference/builder/).
Dokku supports deploying applications in a few ways:
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [buildpacks documentation](/docs/deployment/methods/buildpacks.md) to learn about the different ways to specify a buildpack.
- [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/methods/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/images.md) to learn about how to deploy a Docker Image.
### Skipping deployment
@@ -121,7 +124,7 @@ If you need to redeploy or restart your app:
dokku ps:rebuild ruby-getting-started
```
See the [process scaling documentation](/docs/deployment/process-management.md) for more information.
See the [process scaling documentation](/docs/deployment/process-management.md) for more information on how to manage your app processes.
### Deploying with private Git submodules
@@ -188,36 +191,36 @@ Prior to every deployment, Dokku will execute a cleanup function. As of 0.5.x, t
## Adding deploy users
See the [user management documentation](/docs/deployment/user-management.md).
See the [user management documentation](/docs/deployment/user-management.md) for more information on how to manage users with access to your Dokku server.
## Default vhost
See the [nginx documentation](/docs/configuration/nginx.md#default-site).
See the [domains documentation](/docs/configuration/domains.md#default-site) for more information on how to manage the default site.
## Deploying non-master branch
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch).
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch) for more information on deploying a non-master branch to your application.
## Dockerfile deployment
See the [Dockerfile documentation](/docs/deployment/methods/dockerfiles.md).
See the [Dockerfile documentation](/docs/deployment/methods/dockerfiles.md) for information Dokku's Dockerfile support.
## Image tagging
See the [image tagging documentation](/docs/deployment/methods/images.md).
See the [image tagging documentation](/docs/deployment/methods/images.md) for more information on how Docker images can be tagged and deployed for a given application.
## Specifying a custom buildpack
See the [buildpack documentation](/docs/deployment/methods/buildpacks.md).
See the [buildpack documentation](/docs/deployment/methods/buildpacks.md) for more information on how to specify a set of custom buildpacks for your application.
## Removing a deployed app
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app) for more information on how to remove an application from your Dokku server.
## Renaming a deployed app
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app) for more information on how an application can be renamed and the impact of doing so upon the application and associated resources.
## Zero downtime deploy
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md).
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md) for more information on how Dokku enables zero-downtime deploys.
The `--force` flag can also be specified on the command vs globally:
```shell
dokku apps:destroy --force node-js-app
```
```
Destroying node-js-app (including all add-ons)
```
Destroying an application 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).
### Renaming a deployed app
@@ -134,6 +144,12 @@ Renaming node-js-app to io-js-app... done
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.
By default, Dokku will deploy the renamed app, though you can skip the deploy by using the `--skip-deploy` flag:
@@ -157,7 +173,7 @@ This will copy all of your app's contents into a new app directory with the name
> Warning: If you have exposed specific ports via `docker-options` plugin, or performed anything that cannot be done against multiple applications, `apps:clone` may result in errors.
By default, Dokku will deploy this new application, though you can skip the deploy by using the `--skip-deploy` flag:
By default, Dokku will deploy this new app, though you can skip the deploy by using the `--skip-deploy` flag:
@@ -36,7 +36,7 @@ will show logs continually from the web process.
### Failed deploy logs
> Warning: The default `docker-local` scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
> Warning: The default [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md) will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
In some cases, it may be useful to retrieve the logs from a previously failed deploy.
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache).
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache) for more information on how to clear buildpack build cache for an application.
The location of the `Dockerfile` may also be specified. If the location is changed, the repository **must also** have a `Dockerfile` in the root directory in order to trigger a dockerfile-based deploy.
Once set, the Dockerfile usage would be as follows:
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
# set the argument default
ARGNODE_ENV=production
@@ -44,7 +50,7 @@ RUN echo $NODE_ENV
You may also set the argument as an environment variable
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
# set the argument default
ARGNODE_ENV=production
@@ -95,7 +101,7 @@ worker: bin/run-worker.sh
And `Dockerfile`:
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
WORKDIR/app
COPY . ./
CMD["bin/run-dev.sh"]
@@ -110,4 +116,4 @@ in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instea
## Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
@@ -76,3 +76,28 @@ This behavior can be disabled entirely on a per-app basis by setting the `rev-en
# override for a specific app
dokku git:set node-js-app rev-env-var ""
```
### Keeping the `.git` directory
By default, Dokku will remove the contents of the `.git` before triggering a build for a given app. This is generally a safe default as shipping the entire source code history of your app in the deployed image artifact is unnecessary as it increases bloat and potentially can leak information if there are any security issues with your app code.
To enable the `.git` directory, run the `git:set` command as follows:
```shell
# on the Dokku host
# keep the .git directory during builds
dokku git:set node-js-app keep-git-dir true
```
The default behavior is to delete this directory and it's contents. To revert to the default behavior, the `keep-git-dir` value can be set to either an empty string or `false`.
```shell
# on the Dokku host
# delete the .git directory during builds (default)
dokku git:set node-js-app keep-git-dir false
# delete the .git directory during builds (default)
@@ -22,7 +22,7 @@ The Dokku tags plugin allows you to add Docker image tags to the currently deplo
### Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
@@ -5,7 +5,7 @@ Sometimes you need to either inspect running containers or run a one-off command
## Run a command in an app environment
```
run <app> <cmd> # Run a command in a new container using the current application image
run [ --env KEY=VALUE | -e KEY=VALUE ] <app> <cmd> # Run a command in a new container using the current application image
```
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.
@@ -13,6 +13,9 @@ The `run` command can be used to run a one-off process for a specific command. T
```shell
# runs `ls -lah` in the `/app` directory of the application `node-js-app`
dokku run node-js-app ls -lah
# optionally, run can be passed custom environment variables
dokku run --env "NODE_ENV=development" --env "PATH=/custom/path" node-js-app npm run mytask
```
The `run` command can also be used to run a command defined in your Procfile:
@@ -43,6 +46,12 @@ dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
Containers may have specific labels attached. In order to avoid issues with dokku internals, do not use any labels beginning with either `com.dokku` or `org.label-schema`.
```shell
dokku --label=com.example.test-label=value 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.
@@ -21,8 +21,75 @@ in order to avoid SSH interpretting Dokku arguments for itself.
--force force flag. currently used in apps:destroy and other ":destroy" commands
```
## Clients
## Official Client
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 the official client when connecting to the Dokku server.
Please refer to the [clients](/docs/community/clients.md) list for more details.
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.
It can be installed either via the [Homebrew](https://brew.sh) package manager (macOS only), or manually.
### Installation via Homebrew
To install, simply run the following command:
```shell
brew install dokku/repo/dokku
```
### Manual installation
To install manually, 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'
```
### Usage
All commands have the application name automatically set via the `--app` flag on the remote server, and thus the app name does not need to be specified manually for core plugins.
The client supports several environment variables:
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overriden via `--remote` flag.
-`DOKKU_PORT` (default: `22`): Used to specify a port to connect to the Dokku server on.
It also supports several flags (all flags unspecified here are passed as is to the server):
-`--app`: Override the remote app in use.
-`--trace`: Enable trace mode.
-`--remote`: Override the remote server.
-`--global`: Unsets the "app" value. May not be supported for the specified command.
In addition, the following commands have special local side-effects:
-`apps:create`:
- If no local `--app` flag is specified or detected from a `dokku` git remote, a random name is generated and used for the app.
- The `dokku` git remote is set if not already set.
-`apps:destroy`:
- Removes the local `dokku` git remote if set.
## Unofficial Clients
Please refer to the [community clients](/docs/community/clients.md) list for more details.
`KEY_NAME` is the name you want to use to refer to this particular key. Including the word `admin` in the name will grant the user privileges to add additional keys remotely.
@@ -72,7 +80,8 @@ dokku ssh-keys:remove KEY_NAME
## Scoping commands to specific users
Keys are given unique names, which can be used in conjunction with the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization. Please see the documentation on that trigger for more information.
Support for scoping commands to specific users can be added through plugins that take advantage of the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization.
See also the list of [community-provided plugins](/docs/community/plugins.md).
checks:disable <app> [process-type(s)] Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
checks:enable <app> [process-type(s)] Enable zero-downtime deployment for all processes (or comma-separated process-type list)
checks:report [<app>] [<flag>] Displays a checks report for one or more apps
@@ -123,7 +122,7 @@ To specify checks, add a `CHECKS` file to the root of your project directory. Th
- comments (lines starting with #)
- empty lines
> For Dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
> For Dockerfile and Docker Image based deploys, the file *must* be in the `WORKDIR` directory of the built image. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check instructions
@@ -327,7 +326,6 @@ curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
A plugin can be a simple implementation of [triggers](/docs/development/plugin-triggers.md) or can implement a command structure of its own. Dokku has no restrictions on the language in which a plugin is implemented; it only cares that the plugin implements the appropriate [commands](/docs/development/plugin-creation.md#command-api) or [triggers](/docs/development/plugin-triggers.md) for the API. **NOTE:** any file that implements triggers or uses the command API must be executable.
If you create your own plugin:
When creating custom plugins:
1. Take a look at [the plugins shipped with Dokku](/docs/community/plugins.md) and hack away!
2. Check out the [list of triggers](/docs/development/plugin-triggers.md) your plugin can implement
3. Upload your plugin to GitHub with a repository name following the `dokku-<name>` convention (e.g. `dokku-mariadb`)
4. Edit [this page](/docs/community/plugins.md) and add a link to your plugin
2. Check out the [list of triggers](/docs/development/plugin-triggers.md) the plugin can implement
3. Upload the plugin to GitHub with a repository name following the `dokku-<name>` convention (e.g. `dokku-mariadb`)
4. Edit [this page](/docs/community/plugins.md) and add a link to the plugin
5. Subscribe to the [dokku development blog](http://progrium.com) to be notified about API changes and releases
## Compilable plugins (Golang, Java(?), C, etc.)
When developing a plugin, you must implement the `install` trigger such that it outputs the built executable(s) using a directory structure that implements the plugin's desired command and/or triggers the API. See the [smoke-test-plugin](https://github.com/dokku/smoke-test-plugin) for an example.
When developing a plugin, the `install` trigger must be implemented such that it outputs the built executable(s) using a directory structure that implements the plugin's desired command and/or triggers the API. See the [smoke-test-plugin](https://github.com/dokku/smoke-test-plugin) for an example.
## Command API
There are 3 main integration points: `commands`, `subcommands/default`, and `subcommands/<command-name>`.
### `commands`
Primarily used to supply the plugin's usage/help output. (i.e. [plugin help](https://github.com/dokku/dokku/tree/master/plugins/plugin/commands)).
### `subcommands/default`
Implements the plugin's default command behavior. (i.e. [`dokku plugin`](https://github.com/dokku/dokku/tree/master/plugins/plugin/subcommands/default)).
### `subcommands/<command-name>`
Implements the additional command interface and will translate to `dokku plugin:cmd` on the command line. (i.e. [`dokku plugin:install`](https://github.com/dokku/dokku/tree/master/plugins/plugin/subcommands/install)).
# Plugin Building Tips
## Always create a `plugin.toml`
The `plugin.toml` file is used to describe the plugin in help output, and helps users understand the purpose of the plugin. This _must_ have a description and a version. The version _should_ be bumped at every plugin release.
```toml
[plugin]
description="dokku example plugin"
version="0.1.0"
[plugin.config]
```
## Files should be executable
Commands, subcommands, triggers and source shell scripts should all be executable. On a Unix-like machine, the following command can be used to make them executable:
```shell
chmod +x path/to/file
```
Non-executable commands, subcommands, and triggers will be ignored.
## Use the `pipefail` bash option
Consider whether to include 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
```
If `user/repo` doesn't exist, Dokku exits just before the `awk` command and the `dokku_log_fail` message will never go to `STDOUT`. printed with echo. The `set -e` option should be used in this case.
Here is the `help` entry for `set`:
```
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
```
## Support trace mode
Trace mode is useful for getting debugging output from plugins when the `--trace` flag is specified or `dokku trace:on` is triggered. This should be done at the top of each shell script:
```shell
#!/usr/bin/env bash
set -eo pipefail
[[$DOKKU_TRACE]]&&set -x
```
In the above example, the third line enables bash's debug mode, which prints command traces before executing command.
## Verify the existence of dependencies
If a plugin depends on a specific command-line tool, check whether that tool exists before utilizing it. Either `command -v` or `which` may be used to do so:
```shell
# `command -v` example
if ! command -v "nginx"&>/dev/null;then
log-fail "Missing nginx, install it"
fi
# `which` example
if ! which nginx >/dev/null 2>&1;then
log-fail "Missing nginx, install it"
fi
```
In cases where a dependency should be installed before the plugin can be used at all, use the `dependencies` plugin trigger to install the dependency.
## Implement a help command
For plugins which expose commands, implement a `help` command. This may be empty, but should contain a listing of all available commands.
Commas - `,` - are used in the help output for columnizing output. Verify that the plugin conforms to the spec by running `dokku help --all` and manually verifying the output.
See the sample plugin below for an example.
## Namespace commands
All commands *should* be namespaced. In cases where a core plugin is overriden, the plugin _may_ utilize the a namespace in use by the core, but generally this should be avoided to reduce confusion as to where the command is implemented.
## Implement a proper catch-all command
As of 0.3.3, a catch-all should be implemented that exits with a `DOKKU_NOT_IMPLEMENTED_EXIT` code. This allows Dokku to output a `command not found` message.
See the sample plugin below for an example.
## Set app config without restarting
In the case that a plugin needs to set app configuration settings and a restart should be avoided (default Heroku-style behavior) these "internal" commands provide this functionality:
To allow other plugins access to (some of) a plugin's functionality, functions can expose by including a `functions` file in the plugin for others to source. All functions in that file should be considered publicly accessible by other plugins.
Any functions that must be kept private should reside in the plugin's `trigger/` or `commands/` directories. Other files may also be used to hide private functions; the official convention for hiding private functions is to place them an `internal-functions` file.
## Use helper functions to fetch app images
> New as of 0.4.0
Dokku allows image tagging and deployment of tagged images. This means hard-coding the `$IMAGE` as `dokku/$APP` is no longer sufficient.
Plugins should use `get_running_image_tag()` and `get_app_image_name()` as sourced from `common/functions`. See the [plugin triggers](/docs/development/plugin-triggers.md) doc for examples.
> **Note:** This is only for plugins that are not `pre/post-build-*` plugins
## Use `$DOCKER_BIN` instead of `docker` directly
> New as of 0.17.5
Certain systems may require a wrapper function around the `docker` binary for proper execution. Utilizing the `$DOCKER_BIN` environment variable when calling docker for those functions is preferred.
```shell
# good
"$DOCKER_BIN" container run -d $IMAGE /bin/bash -e -c "$COMMAND"
# bad
docker run -d $IMAGE /bin/bash -e -c "$COMMAND"
```
## Include labels for all temporary containers and images
> New as of 0.5.0
As of 0.5.0, labels are used to help cleanup intermediate containers with `dokku cleanup`. Plugins that create containers and images should add the correct labels to the `build`, `commit`, and `run` docker commands.
Note that where possible, a label `com.dokku.app-name=$APP` - where `$APP` is the name of the app - should also be included. This enables `dokku cleanup APP` to cleanup the specific containers for a given app.
"$DOCKER_BIN" container run "--label=com.dokku.app-name=${APP}"$DOKKU_GLOBAL_RUN_ARGS ...
```
## Copy files from the built image using `copy_from_image`
Avoid copying files from running containers as these files may change over time. Instead copy files from the image built during the deploy process. This can be done via the `copy_from_image` helper function. This will correctly handle various corner cases in copying files from an image.
Files are copied from the `/app` directory - for images built via buildpacks - or `WORKDIR` - for images built via Dockerfile.
## Avoid calling the `dokku` binary directly
> New as of 0.6.0
Plugins should **not** call the `dokku` binary directly from within plugins because clients using the `--app` argument are potentially broken when doing so.
Plugins should instead source the `functions` file for a given plugin when attempting to call Dokku internal functions.
# Sample plugin
The below plugin is a dummy `dokku hello` plugin.
Each plugin requires a `plugin.toml` descriptor file with the following required fields:
# Use the following lines to reorder args into "$cmd $DOKKU_APP_NAME $@""
localargv=("$@")
[[${argv[0]}=="$cmd"]]&&shift1
[[ -n $DOKKU_APP_NAME]]&&set -- $DOKKU_APP_NAME$@
set -- $cmd$@
##
[[ -z $2]]&& dokku_log_fail "Please specify an app to run the command on"
verify_app_name "$2"
localAPP="$2";
cmd-hello-world(){
declaredesc="prints Hello world"
declarecmd="hello:world"
[["$1"=="$cmd"]]&&shift1
echo"Hello world"
}
hello_world_cmd"$@"
cmd-hello-world "$@"
```
`hello/commands`
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
set -eo pipefail
[[$DOKKU_TRACE]]&&set -x
case"$1" in
help| hello:help)
@@ -126,58 +312,3 @@ help_content
esac
```
Each plugin requires a `plugin.toml` descriptor file with the following required fields:
```toml
[plugin]
description="dokku hello plugin"
version="0.1.0"
[plugin.config]
```
# A few notes:
- Remember to `chmod +x` your executable files
- Always support `DOKKU_TRACE` as per the 2nd line of the above example
- If your command depends on an application, include a check for whether that application exists (see the above example)
- You must implement a `help` command, though you may leave it empty. Also, you must use commas (`,`) in the command syntax to support output in columns
- Commands **should** be namespaced
- As of 0.3.3, a catch-all should be implemented that exits with a `DOKKU_NOT_IMPLEMENTED_EXIT` code. This allows Dokku to output a `command not found` message.
- Consider whether you want to include 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
```
If `user/repo` doesn't exist, Dokku exits just before the `awk` command and the `dokku_log_fail` message will never go to `STDOUT`. printed with echo. You would want to use `set -e` in this case.
Here is the `help` entry for `set`:
```
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
```
- In the case that your plugin needs to set application configuration settings and you want to avoid having to restart (default Heroku-style behavior) these "internal" commands provide this functionality:
- If you 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
- You should consider all functions in that file to be publicly accessible by other plugins
- Any functions you want to keep private should reside in your plugin's `trigger/` or `commands/` directories
- As of 0.4.0, Dokku allows image tagging and deployment of tagged images
- This means hard-coding the `$IMAGE` as `dokku/$APP` is no longer sufficient
- You should now use `get_running_image_tag()` and `get_app_image_name()` as sourced from `common/functions` (see the [plugin triggers](/docs/development/plugin-triggers.md) doc for examples). **Note:** This is only for plugins that are not `pre/post-build-*` plugins
- As of 0.5.0, we use container labels to help cleanup intermediate containers with `dokku cleanup
- This means that if you manually call `docker run`, you should include `$DOKKU_GLOBAL_RUN_ARGS` to ensure your intermediate containers are labeled correctly
- As of 0.6.0, you should not **not** call the `dokku` binary directly from within plugins because clients using the `--app` argument are potentially broken when doing so (as well as other issues)
- You should instead source the `functions` file for a given plugin when attempting to call Dokku internal functions
@@ -29,6 +29,81 @@ The following plugin triggers describe those available to a Dokku installation.
> The example plugin trigger code is not guaranteed to be implemented as in within dokku, and are merely simplified examples. Please look at the Dokku source for larger, more in-depth examples.
### `app-create`
- Description: Creates an app
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-destroy`
- Description: Destroys an app (with confirmation if force isn't specified)
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-exists`
- Description: Creates an app
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-maybe-create`
- Description: Creates an app (gated by whether this is globally enabled or not)
- Description: Fetches the app config value for a key
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `config-get-global`
- Description: Fetches the global config value for a key
- Invoked by:
- Arguments: `$KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `core-post-deploy`
> To avoid issues with community plugins, this plugin trigger should be used *only* for core plugins. Please avoid using this trigger in your own plugins.
The default template is viewable here: [plugins/nginx-vhosts/templates/dokku.conf.sigil](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/dokku.conf.sigil)
### `nginx-hostname`
- Description: Allows you to customize the hostname for a given app
@@ -648,11 +954,27 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-app-rename-setup`
- Description: Allows you to run commands after an app is setup, and before it is rebuild. This is useful for cleaning up tasks, or ensuring configuration from an old app is copied to the new app
- Invoked by: `dokku apps:rename`
- Arguments: `$OLD_APP_NAME $NEW_APP_NAME`
- 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 apps using buildpacks.
- Invoked by: `internal function dokku_build() (build phase)`
- Arguments: `$APP`
- Arguments: `$APP``$SOURCECODE_WORK_DIR`
- Example:
```shell
@@ -727,6 +1049,20 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-container-create`
- Description: This trigger should be used to do stuff to containers after they are created but before they are started. They are explicitely for commands that may involve network traffic, and _not_ for commands that are self-contained, such as chown or tar.
- Description: Can be used to run commands after an app is created.
@@ -822,6 +1158,7 @@ REV="$3" # optional, may not be sent for tar-based builds
pushd"$TMP_WORK_DIR" >/dev/null
touch Procfile
echo"clock: some-command" >> Procfile
popd >/dev/null
```
### `post-proxy-ports-update`
@@ -846,6 +1183,8 @@ haproxy-build-config "$APP"
### `post-release-buildpack`
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using buildpacks.
- Invoked by: `internal function dokku_release() (release phase)`
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
# TODO
```
### `post-release-dockerfile`
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using a dockerfile.
- Invoked by: `internal function dokku_release() (release phase)`
- 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 apps using buildpacks.
- Invoked by: `internal function dokku_build() (build phase)`
Dokku 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.
Dokku 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/bats-core/bats-core), and a deployment suite of example apps that use the most popular languages and frameworks.
We maintain the Dokku test harness within the `tests` directory:
@@ -9,15 +9,15 @@ We maintain the Dokku test harness within the `tests` directory:
## Continuous Integration
All pull requests have tests run against them on [CircleCI](https://circleci.com/), a continuous integration platform that provides Docker support for Ubuntu Trusty 14.04.
All pull requests have tests run against them on [CircleCI](https://circleci.com/), a continuous integration platform that provides Docker support for Ubuntu Trusty 16.04.
If you wish to skip tests for a particular commit - e.g. Documentation changes - you may add the `[ci skip]` designator to your commit message. Commits that *should* be tested but have the above designator will not be merged.
If you wish to skip tests for a particular commit, e.g. documentation changes, you may add the `[ci skip]` designator to your commit message. Commits that _should_ be tested but have the above designator will not be merged.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Trusty 14.04, we only provide official installation support for that platform.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Trusty 16.04, we only provide official installation support for that platform and the latest LTS release of Ubuntu (currently 18.04).
## Local Test Execution
- Setup Dokku in a [vagrant vm](/docs/getting-started/install/vagrant.md)
- Setup Dokku in a [Vagrant VM](/docs/getting-started/install/vagrant.md).
- Run the following to setup tests and execute them:
```shell
@@ -29,8 +29,8 @@ 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
make lint copyfiles
# run linter
make lint
# execute all bats tests
make unit-tests
@@ -39,6 +39,16 @@ While we do provide official packages for a variety of platforms, as our test su
make deploy-tests
```
After making changes to your local Dokku clone, don't forget to update the Vagrant Dokku install.
```shell
# update vagrant dokku install from local git clone
make copyfiles
# build a specific plugin
make go-build-plugin copyplugin PLUGIN_NAME=apps
```
Additionally you may run a specific app deployment tests with a target similar to:
Some special characters are translated in the test listing - specifically the characters `( ) :` - while others are not. The fuzzy matching happens on the test names listed when no second character is invoked, so executing a test with a more specific name will work as expected.
Some special characters are translated in the test listing, specifically the characters `( ) :`, while others are not. The fuzzy matching happens on test names as listed by this script, so executing a test with a more specific name will work as expected.
@@ -46,7 +46,7 @@ sudo BUILD_STACK=true STACK_URL=https://github.com/gliderlabs/herokuish.git make
## Skipping Herokuish installation
The Herokuish package is recommended but not required if not using Heroku buildpacks for deployment. Debian-based OS users can run the bootstrap installer via `sudo DOKKU_NO_INSTALL_RECOMMENDS=true bash bootstrap.sh` to skip the dependency. Please note that this will _also_ skip installation of other recommended dependencies.
The Herokuish package is recommended but not required if not using Heroku buildpacks for deployment. Debian-based OS users can run the bootstrap installer via `sudo DOKKU_NO_INSTALL_RECOMMENDS=" --no-install-recommends " bash bootstrap.sh` to skip the dependency. Please note that this will _also_ skip installation of other recommended dependencies.
[DigitalOcean](https://www.digitalocean.com/products/compute/) offers a pre-installed Dokku image. You can run this image on any sized Droplet, although larger Droplets will allow you to run larger applications.
@@ -6,7 +6,7 @@
1. Login to your [DigitalOcean](https://m.do.co/c/fe06b043a083) account.
2. Click **Create a Droplet**.
3. Under **Choose an image > One-click apps**, choose the latest **Dokku** release for 16.04 _(version numbers may vary)_.
3. Under **Choose an image > One-click apps**, choose the latest **Dokku** release for 18.04 _(version numbers may vary)_.
4. Under **Choose a size**, select your machine spec.
5. Under **Choose a datacenter region**, select your region.
- The global hostname is set to `dokku.me` on boot.
- The container name is dokku.
- Container SSH port 22 is exposed on the host as 3022.
- Container HTTP port 80 is exposed on the host as 8080.
- Container HTTPS port 443 is exposed on the host as 8443.
- Data within the container is stored on the host within the `/var/lib/dokku` directory.
- The docker socket is mounted into container
- The "web installer" is not supported.
Application repositories, plugin config, and plugin data is persisted to disk within the specified host directory for `/var/lib/dokku`.
To install custom plugins, create a `plugin-list` file in the host's `/var/lib/dokku` directory. The plugins listed herein will be automatically installed by Dokku on container boot. This file should be the following format:
```yaml
plugin_name:repository_url
```
An example for installing the postgres and redis plugins follows:
@@ -6,7 +6,7 @@ Dokku is an extensible, open source Platform as a Service that runs on a single
To start using Dokku, you'll need a system that meets the following minimum requirements:
- A fresh installation of [Ubuntu x64 - Any currently supported release](https://www.ubuntu.com/download), [Debian 8.2 x64](https://www.debian.org/distrib/) or [CentOS 7 x64](https://www.centos.org/download/) *(experimental)* with the FQDN set <sup>[1]</sup>
- A fresh installation of [Ubuntu 16.04/18.04 x64](https://www.ubuntu.com/download), [Debian 9+ x64](https://www.debian.org/distrib/) or [CentOS 7 x64](https://www.centos.org/download/) *(experimental)* with the FQDN set <sup>[1]</sup>
- At least 1 GB of system memory <sup>[2]</sup>
You can *optionally* have a domain name pointed at the host's IP, though this is not necessary.
@@ -21,13 +21,13 @@ To install the latest stable version of Dokku, you can run the following shell c
The installation process takes about 5-10 minutes, depending upon internet connection speed.
If you're using Debian 8 or Ubuntu 14.04, make sure your package manager is configured to install a sufficiently recent version of nginx<sup>[3]</sup>, otherwise, the installation may fail due to `unmet dependencies` relating nginx.
If you're using Debian 9+ or Ubuntu 18.04, make sure your package manager is configured to install a sufficiently recent version of nginx<sup>[3]</sup>, otherwise, the installation may fail due to `unmet dependencies` relating nginx.
#### 2. Setup SSH key and Virtualhost Settings
@@ -54,9 +54,11 @@ For various reasons, certain hosting providers may have other steps that should
As well, you may wish to customize your installation in some other fashion. or experiment with Vagrant. The guides below should get you started:
By default, Dokku will constrain the amount of output displayed for any given command run. The verbosity of output can be increased by enabling trace mode. Trace mode will turn on the `set -x` flag for bash plugins, while other plugins are free to respect the environment variable `DOKKU_TRACE` and log differently as approprate. Trace mode can be useful to see _where_ plugins are running commands that would otherwise be unexpected.
To enable trace mode, run `trace:on`
```shell
dokku trace:on
```
```
-----> Enabling trace mode
```
Trace mode can be disabled with `trace:off`
```shell
dokku trace:off
```
```
-----> Disabling trace mode
```
## Common Problems
__Symptom:__ I deployed my app but I am getting the default nginx page.
__Solution:__
@@ -41,22 +74,10 @@ __Symptom:__ I want to deploy my app, but while pushing I get the following erro
__Solution:__
The `remote rejected` error does not give enough information. Anything could have failed.
The `remote rejected` error does not give enough information. Anything could have failed. Enable trace mode and begin debugging. If this does not help you, create a [gist](https://gist.github.com) containing the full log, and create an issue.
To enable Dokku tracing, simply run the following command:
One the reasons why you may get this error is because the command that is run in the container exited (without errors). For example, (in Procfile) when you define a new worker container to run Delayed Job and use the bin/delayed_job start command. This command deamonizes the process and exists. The container thinks it's done so it closes itself. The error you get is the one above. To fix the above problem for Delayed Job, you must define the worker to user rake jobs:work, which doesn't deamonize the process.
```shell
# since 0.3.9
dokku trace on
```
In versions older than 0.3.9, you can create a `/home/dokku/dokkurc` file containing the following:
```shell
exportDOKKU_TRACE=1
```
This will trace all of Dokku's activity. If this does not help you, create a [gist](https://gist.github.com) containing the full log, and create an issue.
***
@@ -94,6 +115,18 @@ Please see https://github.com/dokku/dokku/issues/841 and https://github.com/dokk
***
__Symptom:__ After adding an SSH key, I still see the following error on deploy:
Connection closed by <host> port 22
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Certain systems may have access to the `dokku` user via SSH disabled. Please check that the `dokku` user is allowed access to the system in the file `/etc/security/access.conf`. As Dokku does not manage this file, please consult your Operating System's documentation for more information.
***
__Symptom:__ I want to deploy my app but I am getting asked for the password of the Git user and the error message.
fatal: 'NAME' does not appear to be a git repository
@@ -180,7 +213,7 @@ __Symptom:__ I successfully deployed my application with no deployment errors bu
__Solution:__
This can occur if Dokku is running on a system with a firewall like UFW enabled (some OS versions like Ubuntu 16.04 have this enabled by default). You can check if this is your case by running the following script:
This can occur if Dokku is running on a system with a firewall like UFW enabled (some OS versions like Ubuntu have this enabled by default). You can check if this is your case by running the following script:
@@ -15,63 +15,52 @@ Your operating system may occasionally provide security updates. We recommend se
Docker releases updates periodically to their engine. We recommend reading their release notes and upgrading accordingly. Please see the [Docker documentation](https://docs.docker.com/) for more details.
Finally, we provide a helpful binary called `dokku-update`. This is a recommended package that:
- Can be installed separately, so upgrading Dokku will not affect the running of this package.
- Automates many of the upgrade instructions for you.
- Provides a clean way for us to further enhance the upgrade process in the future.
When installing from source, this is available from `contrib/dokku-update`, and is also available on Debian and RPM-based systems from our package repositories under the name `dokku-update`.
## Migration Guides
Before upgrading, check the migration guides to get comfortable with new features and prepare your deployment to be upgraded.
### 0.5 Migration Guide
- [Upgrading to 0.21](/docs/appendices/0.21.0-migration-guide.md)
- [Upgrading to 0.20](/docs/appendices/0.20.0-migration-guide.md)
- [Upgrading to 0.10](/docs/appendices/0.10.0-migration-guide.md)
- [Upgrading to 0.9](/docs/appendices/0.9.0-migration-guide.md)
- [Upgrading to 0.8](/docs/appendices/0.8.0-migration-guide.md)
- [Upgrading to 0.7](/docs/appendices/0.7.0-migration-guide.md)
- [Upgrading to 0.6](/docs/appendices/0.6.0-migration-guide.md)
- [Upgrading to 0.5](/docs/appendices/0.5.0-migration-guide.md)
After upgrading, you should rebuild the applications to take advantage of any
new buildpacks that were released:
```shell
dokku ps:rebuildall
```
> If you have any applications deployed via the `tags` or `tar` commands, do not run the `ps:rebuildall` command,
@@ -84,12 +73,36 @@ dokku ps:rebuildall # rebuilds all applications
> Please see the [images documentation](/docs/deployment/methods/images.md) and [tar documentation](/docs/deployment/methods/tar.md)
> for instructions on rebuilding applications deployed by those plugins.
### Upgrade From Source
## Upgrading using `dokku-update`
We provide a helpful binary called `dokku-update`. This is a recommended package that:
- Can be installed separately, so upgrading Dokku will not affect the running of this package.
- Automates many of the upgrade instructions for you.
- Provides a clean way for us to further enhance the upgrade process in the future.
When installing from source, this is available from `contrib/dokku-update`, and is also available on Debian and RPM-based systems from our package repositories under the name `dokku-update`.
## Upgrading using `apt`
If Dokku was installed in a Debian or Ubuntu system, via `apt install dokku` or `bootstrap.sh`, you can upgrade with `apt`:
- [Gliderlabs Slack](https://glider-slackin.herokuapp.com/) (Join the `#dokku` channel)
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.
network:create <network> # Creates an attachable docker network
network:destroy <network> # Destroys a docker network
network:exists <network> # Checks if a docker network exists
network:info <network> # Outputs information about a docker network
network:list # Lists all docker networks
network:report [<app>] [<flag>] # Displays a network report for one or more apps
network:rebuild <app> # Rebuilds network settings for an app
network:rebuildall # Rebuild network settings for all apps
@@ -13,6 +18,194 @@ The Network plugin allows developers to abstract the concept of container networ
## Usage
### Listing networks
> New as of 0.20.0, Requires Docker 1.21+
You can easily list all available networks using the `network:list` command:
```shell
dokku network:list
```
```
=====> Networks
bridge
host
none
test-network
```
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 network:list
```
```
bridge
host
none
test-network
```
### Creating a network
> New as of 0.20.0, Requires Docker 1.21+
Docker networks can be created via the `network:create` command. Executing this command will create an attachable `bridge` network. This can be used to route requests between containers without going through any public network.
```shell
dokku network:create test-network
```
```
-----> Creating network test-network
```
Specifying other additional flags or other types of networks can be created directly via the `docker` command.
### Destroying a network
> New as of 0.20.0, Requires Docker 1.21+
A Docker network without any associated containers may be destroyed via the `network:destroy` command. Docker will refuse to destroy networks that have containers attached.
```shell
dokku network:destroy test-network
```
```shell
! WARNING: Potentially Destructive Action
! This command will destroy network test.
! To proceed, type"test"
> test
-----> Destroying network test
```
As the command is destructive, it will default to asking for confirmation before executing the removal of the network. This may be avoided by providing the `--force` flag:
```shell
dokku --force network:destroy test-network
```
```shell
-----> Destroying network test
```
### Checking if a network exists
> New as of 0.20.0, Requires Docker 1.21+
For CI/CD pipelines, it may be useful to see if an network exists before creating a new network. You can do so via the `network:exists` command:
```shell
dokku network:exists nonexistent-network
```
```
Network does not exist
```
The `network:exists` command will return non-zero if the network does not exist, and zero if it does.
### Checking network info
> New as of 0.20.0, Requires Docker 1.21+
Network information can be retrieved via the `network:info` command. This is a slightly different version of the `docker network` command.
```shell
dokku network:info test-network
```
```
// TODO
```
### Attaching an app to a network
> New as of 0.20.0, Requires Docker 1.21+
Apps will default to being associated with the `bridge` network, but can be attached to `attachable` networks by changing the `attach-post-create` or `attach-post-deploy` network properties when using the [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md). A change in these values will require an app deploy or rebuild.
```shell
# associates the network after a container is created but before it is started
Setting the `attach` network property to an empty value will de-associate the container with the network.
```shell
dokku network:set node-js-app attach-post-create
dokku network:set node-js-app attach-post-deploy
```
#### Network Aliases
When a container created for a deployment is being attached to a network - regardless of which `attach` property was used - a network alias of the pattern `APP.PROC_TYPE` will be added to all containers. This can be used to load-balance requests between containers. For an application named `node-js-app` with a process type of web, the network alias - or resolvable DNS record within the network - will be:
```
node-js-app.web
```
The fully-qualified URL for the resource will depend upon the `PORT` being listened to by the application. Applications built via buildpacks will have their `PORT` environment variable set to `5000`, and as such internal network requests for the above example should point to the following:
```
http://node-js-app.web:5000
```
Dockerfile-based applications may listen on other ports. For more information on how ports are specified for applications, please refer to the [port management documentation](/docs/networking/port-management.md).
#### Specifying a custom TLD
When attaching applications to networks, a custom TLD can be specified via the `network:set` command. This TLD is suffixed to the network alias for the application/process-type combination for _all_ networks to which the application is attached, and cannot be customized per network.
To specify a TLD of `svc.cluster.local` for your application, run the following command:
With an application named `node-js-app` and a process-type named `web`, the above command will turn the network alias into:
```shell
node-js-app.web.svc.cluster.local
```
Note that this has no impact on container port handling, and users must still specify the container port when making internal network requests.
#### When to attach containers to a network
Containers can be attached to a network for a variety of reasons:
- A background process in one app needs to communicate to a webservice in another app
- An app needs to talk to a container not managed by Dokku in a secure manner
- A custom network that allows transparent access to another host exists and is necessary for an app to run
Whatever the reason, the semantics of the two network hooks are important and are outlined before.
-`attach-post-create`:
- Phase it applies to:
-`build`: Intermediate containers created during the build process.
-`deploy`: Deployed app containers.
-`run`: Containers created by the `run` command.
- Container state on attach: `created` but not `running`
- Use case: When the container needs to access a resource on the network.
- Example: The app needs to talk to a database on the same network when it first boots.
-`attach-post-deploy`
- Phase it applies to:
-`deploy`: Deployed app containers.
- Container state on attach: `running`
- Use case: When another container on the network needs to access _this_ container.
- Example: A background process needs to communicate with the web process exposed by this container.
> Warning: If the attachment fails at this stage, this may result in your application failing to respond to proxied requests once older containers are removed.
### Rebuilding network settings
There are cases where you may need to rebuild the network configuration for an app, such as on app boot or container restart. In these cases, you can use the `network:rebuild` command:
@@ -37,7 +230,7 @@ dokku network:rebuildall
> This functionality does not control the `--network` docker flag. Please use the [docker-options plugin](docs/advanced-usage/docker-options.md) to manage this flag.
By default, an application will only bind to the internal interface. This behavior can be modified per app by changing the `bind-all-interfaces` network property.
By default, an app will only bind to the internal interface. This behavior can be modified per app by changing the `bind-all-interfaces` network property.
```shell
# bind to the default docker interface (`docker0`) with a random internal ip
proxy:ports <app> # List proxy port mappings for app
proxy:ports-set <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Set proxy port mappings for app
proxy:ports-add <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Add proxy port mappings for app
proxy:ports-clear <app> # Clear all proxy port mappings for app
proxy:ports-remove <app> <host-port> [<host-port>|<scheme>:<host-port>:<container-port>...] # Unset proxy port mappings for app
proxy:ports <app> # List proxy port mappings for an app
proxy:ports-add <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Add proxy port mappings to an app
proxy:ports-clear <app> # Clear all proxy port mappings for an app
proxy:ports-remove <app> <host-port> [<host-port>|<scheme>:<host-port>:<container-port>...] # Remove specific proxy port mappings from an app
proxy:ports-set <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Set proxy port mappings for an app
```
In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into the proxy plugin. Dokku 0.6.0 introduced the ability to map host ports to specific container ports. In the future this will allow other proxy software - such as HAProxy or Caddy - to be used in place of nginx.
## Usage
### Proxy port mapping
> Warning: Mapping alternative ports may conflict with the active firewall installed on your server or hosting provider. Such software includes - but is not limited to - AWS Security Groups, iptables, and UFW. Please consult the documentation for those softwares as applicable.
> New as of 0.6.0
You can now configure `host -> container` port mappings with the `proxy:ports-*` commands. This mapping is currently supported by the built-in nginx-vhosts plugin.
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` commands detailed below.
### Listing port mappings
To inspect the port mapping for a given application, use the `proxy:ports` command:
A port mapping can be removed using the `proxy:ports-remove` command if it no longer necessary:
```shell
dokku proxy:ports-remove node-js-app http:80:5000
```
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
Ports may also be removed by specifying only the `host-port` value. This effectively acts as a wildcard and removes all mappings for that particular host port.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` syntax detailed above.
```shell
dokku proxy:ports-remove node-js-app http:80
```
## Port management by Deployment Method
@@ -124,7 +136,7 @@ For buildpack deployments, your application *must* respect the `PORT` environmen
> Changed as of 0.5.0
Dokku's default proxy implementation - nginx - only supports HTTP request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
Dokku's default proxy implementation - nginx - supports HTTP and GRPC request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
#### Applications using EXPOSE
@@ -133,7 +145,7 @@ Dokku will extract all tcp ports exposed using the `EXPOSE` directive (one port
For example, if the Dokku installation is configured with the domain `dokku.me` and an application named `node-js-app` is deployed with following Dockerfile:
proxy:build-config <app> # (Re)builds config for given app
proxy:disable <app> # Disable proxy for app
proxy:enable <app> # Enable proxy for app
proxy:report [<app>] [<flag>] # Displays a proxy report for one or more apps
@@ -13,6 +14,14 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
## Usage
### Regenerating proxy config
In certain cases, your app proxy configs may drift from the correct config for your app. You may regenerate the config at any point via the `proxy:build-config` command. This command will trigger a rebuild for the configured proxy implementation (default: nginx) for a given app. The command may fail if there are no current web listeners for your app.
```shell
dokku proxy:build-config node-js-app
```
### Container network interface binding
> Changed as of 0.11.0
@@ -69,7 +78,8 @@ The proxy port scheme is as follows:
-`SCHEME:HOST_PORT:CONTAINER_PORT`
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports both the `http` and `https` schemes.
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.
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.