# History
## 0.30.4
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.4/bootstrap.sh
sudo DOKKU_TAG=v0.30.4 bash bootstrap.sh
```
### Bug Fixes
- #5786: @obrienmd Detect id_ed25519.pub in git:public-key command
- #5758: @josegonzalez Support pack-based images that do not have a Procfile
### New Features
- #5851: @josegonzalez Allow setting _ as domain name for default nginx routing
### Documentation
- #5853: @josegonzalez Always overwrite bootstrap install file
- #5828: @josegonzalez Add a note to the troubleshooting docs pointing developers to bind to all interfaces
- #5827: @josegonzalez Add permalink support to headers
### Tests
- #5850: @josegonzalez Only run packer validation if any packer-related files were changed
### Dependencies
- #5837: @dependabot[bot] chore(deps): bump golang from 1.20.3 to 1.20.4 in /tests/apps/zombies-dockerfile-tini
- #5836: @dependabot[bot] chore(deps): bump golang from 1.20.3 to 1.20.4 in /tests/apps/gogrpc
- #5832: @dependabot[bot] chore(deps): bump flask from 2.3.1 to 2.3.2 in /tests/apps/multi
- #5831: @dependabot[bot] chore(deps): bump flask from 2.3.1 to 2.3.2 in /tests/apps/python-flask
- #5839: @dependabot[bot] chore(deps): bump mkdocs from 1.4.2 to 1.4.3 in /docs/_build
- #5835: @dependabot[bot] chore(deps): bump golang from 1.20.3 to 1.20.4 in /tests/apps/zombies-dockerfile-no-tini
- #5838: @dependabot[bot] chore(deps): bump golang from 1.20.3 to 1.20.4 in /tests/apps/go-fail-predeploy
- #5841: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.9.0 to 0.10.0 in /tests/apps/gogrpc
- #5842: @dependabot[bot] chore(deps): bump werkzeug from 2.3.1 to 2.3.4 in /tests/apps/python-flask
- #5844: @dependabot[bot] chore(deps): bump django from 4.1.7 to 4.1.9 in /tests/apps/dockerfile-release
- #5848: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.8 to 9.1.12 in /docs/_build
- #5840: @dependabot[bot] chore(deps): bump golang from 1.20.3 to 1.20.4 in /tests/apps/go-fail-postdeploy
- #5823: @dependabot[bot] chore(deps): bump flask from 2.2.3 to 2.3.1 in /tests/apps/python-flask
- #5825: @dependabot[bot] chore(deps): bump flask from 2.2.3 to 2.3.1 in /tests/apps/multi
- #5826: @dependabot[bot] chore(deps): bump werkzeug from 2.2.3 to 2.3.1 in /tests/apps/python-flask
If no Procfile is set, we'll leave the entrypoint alone, resulting in the default launcher for the web process (or whatever pack decided was default) executing.
Closes#5753
# History
## 0.30.3
Install/update via the bootstrap script:
```shell
wget https://dokku.com/install/v0.30.3/bootstrap.sh
sudo DOKKU_TAG=v0.30.3 bash bootstrap.sh
```
### Bug Fixes
- #5763: @josegonzalez Set dokku version correctly for digitalocean image build
### New Features
- #5799: @josegonzalez Add ability to run dokku report without downloading herokuish image
### Documentation
- #5810: @strugee Fix typo in 0.30.x migration guide
- #5820: @tylercrumpton Fix "cotainer" typo in one-off tasks docs page.
- #5800: @josegonzalez Fix indentation in registry configuration documentation
### Dependencies
- #5809: @dependabot[bot] chore(deps): bump pygments from 2.15.0 to 2.15.1 in /docs/_build
- #5811: @dependabot[bot] chore(deps): bump node from 19-alpine to 20-alpine in /tests/apps/dockerfile-noexpose
- #5812: @dependabot[bot] chore(deps): bump node from 19-alpine to 20-alpine in /tests/apps/dockerfile-procfile
- #5813: @dependabot[bot] chore(deps): bump node from 19-alpine to 20-alpine in /tests/apps/dockerfile-procfile-bad
- #5814: @dependabot[bot] chore(deps): bump node from 19-alpine to 20-alpine in /tests/apps/dockerfile
- #5815: @dependabot[bot] chore(deps): bump node from 19-alpine to 20-alpine in /tests/apps/dockerfile-app-json-formations
- #5816: @dependabot[bot] chore(deps): bump sqlparse from 0.4.3 to 0.4.4 in /tests/apps/dockerfile-release
- #5818: @dependabot[bot] chore(deps): bump importlib-metadata from 6.5.0 to 6.6.0 in /docs/_build
- #5821: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.6 to 9.1.8 in /docs/_build
- #5805: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.14 to 11.0.15 in /tests/apps/java
- #5808: @dependabot[bot] chore(deps): bump importlib-metadata from 6.3.0 to 6.5.0 in /docs/_build
- #5802: @dependabot[bot] chore(deps): bump packaging from 23.0 to 23.1 in /docs/_build
- #5806: @dependabot[bot] chore(deps): bump soupsieve from 2.4 to 2.4.1 in /docs/_build
- #5779: @dependabot[bot] chore(deps): bump golang from 1.20.2 to 1.20.3 in /tests/apps/gogrpc
- #5782: @dependabot[bot] chore(deps): bump golang from 1.20.2 to 1.20.3 in /tests/apps/go-fail-postdeploy
- #5788: @dependabot[bot] chore(deps): bump python from 3.11.2-alpine to 3.11.3-alpine in /docs/_build
- #5795: @dependabot[bot] chore(deps): bump pygments from 2.14.0 to 2.15.0 in /docs/_build
- #5796: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.12.0 to 4.12.2 in /docs/_build
- #5797: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.4 to 9.1.6 in /docs/_build
- #5801: @dependabot[bot] chore(deps): bump sinatra from 3.0.5 to 3.0.6 in /tests/apps/ruby
- #5794: @dependabot[bot] chore(deps): bump pymdown-extensions from 9.10 to 9.11 in /docs/_build
- #5793: @dependabot[bot] chore(deps): bump importlib-metadata from 6.1.0 to 6.3.0 in /docs/_build
- #5791: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.8.0 to 0.9.0 in /tests/apps/gogrpc
- #5789: @dependabot[bot] chore(deps): bump python from 3.11.2-buster to 3.11.3-buster in /tests/apps/dockerfile-release
- #5783: @dependabot[bot] chore(deps): bump golang from 1.20.2 to 1.20.3 in /tests/apps/zombies-dockerfile-tini
- #5781: @dependabot[bot] chore(deps): bump golang from 1.20.2 to 1.20.3 in /tests/apps/zombies-dockerfile-no-tini
- #5780: @dependabot[bot] chore(deps): bump golang from 1.20.2 to 1.20.3 in /tests/apps/go-fail-predeploy
- #5775: @dependabot[bot] chore(deps): bump ruby from 3.2.1 to 3.2.2 in /tests/apps/dockerfile-entrypoint
- #5774: @dependabot[bot] chore(deps): bump thin from 1.8.1 to 1.8.2 in /tests/apps/ruby
- #5765: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.3 to 9.1.4 in /docs/_build
# History
## 0.30.2
Install/update via the bootstrap script:
```shell
wget https://dokku.com/install/v0.30.2/bootstrap.sh
sudo DOKKU_TAG=v0.30.2 bash bootstrap.sh
```
### Bug Fixes
- #5749: @josegonzalez Keep image specified by git:from-image on app rebuild
- #5750: @josegonzalez Return an error when an invalid scale count is encountered
- #5748: @josegonzalez Correct set source type and source metadata
### New Features
- #5754: @josegonzalez Ignore release branches in changelog output
### Removals
- #5756: @josegonzalez Drop code supporting git versions without worktree support
### Documentation
- #5744: @josegonzalez Add DOKKU_LIB_HOST_ROOT to docker usage docs
- #5740: @josegonzalez Add a note about how running plugin:install does not apply for docker-based installs
- #5719: @TkTech Give a quick example of what to do after disabling the proxy to expose a UDP port
- #5737: @Samuelodan Update instructions for setting letsencrypt global email
- #5736: @josegonzalez Remove extra backtick from nginx docs
- #5725: @IgnisDa Add surrealdb community plugin
### Tests
- #5755: @josegonzalez Ignore issue where errors are required to be lowercased
### Dependencies
- #5762: @dependabot[bot] chore(deps): bump watchdog from 2.3.1 to 3.0.0 in /docs/_build
- #5760: @dependabot[bot] chore(deps): bump importlib-metadata from 6.0.0 to 6.1.0 in /docs/_build
- #5761: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.11.2 to 4.12.0 in /docs/_build
- #5745: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.2 to 9.1.3 in /docs/_build
- #5746: @dependabot[bot] chore(deps): bump rack from 2.2.6.3 to 2.2.6.4 in /tests/apps/ruby
- #5732: @dependabot[bot] chore(deps): bump github.com/golang/protobuf from 1.5.2 to 1.5.3 in /tests/apps/gogrpc
- #5727: @dependabot[bot] chore(deps): bump golang from 1.20.1 to 1.20.2 in /tests/apps/zombies-dockerfile-tini
- #5708: @dependabot[bot] chore(deps): bump zipp from 3.14.0 to 3.15.0 in /docs/_build
- #5734: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.0 to 9.1.2 in /docs/_build
- #5731: @dependabot[bot] chore(deps): bump rack from 2.2.6.2 to 2.2.6.3 in /tests/apps/ruby
- #5730: @dependabot[bot] chore(deps): bump golang from 1.20.1 to 1.20.2 in /tests/apps/go-fail-predeploy
- #5729: @dependabot[bot] chore(deps): bump golang from 1.20.1 to 1.20.2 in /tests/apps/zombies-dockerfile-no-tini
- #5728: @dependabot[bot] chore(deps): bump golang from 1.20.1 to 1.20.2 in /tests/apps/gogrpc
- #5726: @dependabot[bot] chore(deps): bump golang from 1.20.1 to 1.20.2 in /tests/apps/go-fail-postdeploy
- #5723: @dependabot[bot] chore(deps): bump pymdown-extensions from 9.9.2 to 9.10 in /docs/_build
- #5722: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.7.0 to 0.8.0 in /tests/apps/gogrpc
- #5721: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.0.0-20220225172249-27dd8689420f to 0.7.0 in /plugins/common
- #5715: @dependabot[bot] chore(deps): bump luizm/action-sh-checker from 0.5.0 to 0.7.0
- #5712: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.13 to 11.0.14 in /tests/apps/java
- #5713: @dependabot[bot] chore(deps): bump watchdog from 2.3.0 to 2.3.1 in /docs/_build
- #5717: @dependabot[bot] chore(deps): bump mkdocs-material from 9.0.14 to 9.1.0 in /docs/_build
- #5703: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.0.0-20190813141303-74dc4d7220e7 to 0.7.0 in /tests/apps/gogrpc
- #5705: @dependabot[bot] chore(deps): bump mkdocs-material from 9.0.13 to 9.0.14 in /docs/_build
- #5704: @dependabot[bot] chore(deps): bump watchdog from 2.2.1 to 2.3.0 in /docs/_build
- #5698: @dependabot[bot] chore(deps): bump golang.org/x/text from 0.3.7 to 0.3.8 in /plugins/common
- #5697: @dependabot[bot] chore(deps): bump golang.org/x/text from 0.3.2 to 0.3.8 in /tests/apps/gogrpc
### Other
- #5751: @josegonzalez Update all golang dependencies to fix go.0 tests
This was necessary on Ubuntu 14.04 (and maybe 16.04) due to using a version of Dokku older than #2699, so we can safely drop the support here as we haven't supported either in a few years.
This change allows us to have an integration branch for each release that contains tested changes for each minor. Rather than have to block merging until a minor is ready for release - and subsequently have to deal with constant rebase issues - we will now have an integration branch per-release. This will be the target for minor-related changes - mostly new features, but also refactors and bc-breaks - while the trunk branch will stay safe for merging patch changes.
Note that we'll still need to rebase the integration branch every so often, but at least this allows us to avoid many long-running MRs.
Rather than always delete the image, we will now check if the alt image tag is equivalent to the source-image specified by the git:from-image command. If it is, we will ignore deletion.
Closes#5702
Since there's no instruction for how to use the DOKKU_LETSENCRYPT_EMAIL env variable, I'm not sure why it's included here.
So, instead, I'm proposing to include the step for directly setting the global email for `dokku-letsencrypt`.
(It'll be nice to also get some explanation behind creating that env variable)
# History
## 0.30.1
Install/update via the bootstrap script:
```shell
wget https://dokku.com/install/v0.30.1/bootstrap.sh
sudo DOKKU_TAG=v0.30.1 bash bootstrap.sh
```
### Bug Fixes
- #5690: @josegonzalez Update dependencies for golang code to fix builds
- #5683: @josegonzalez Ensure the services directory also exists
- #5688: @josegonzalez Set custom entrypoint for pack-based containers so custom command/argument combinations are respected
### New Features
- #5682: @josegonzalez Build Digitalocean image automatically upon release
- #5675: @josegonzalez Add new sections to release notes
### Documentation
- #5695: @josegonzalez Add a note about required upgrade to 0.29.x for versions prior to 0.25.x
- #5689: @josegonzalez Add note about ubuntu 18.04 being deprecated
- #5684: @josegonzalez Note that the app.json is pulled from the specified image when deploying via git:from-image
- #5679: @josegonzalez Revert invalid replacement in homepage html path objects
- #5678: @josegonzalez Cleanup docs on homepage for installation
### Dependencies
- #5693: @dependabot[bot] chore(deps): bump mkdocs-material from 9.0.12 to 9.0.13 in /docs/_build
- #5694: @dependabot[bot] chore(deps): bump zipp from 3.13.0 to 3.14.0 in /docs/_build
- #5677: @dependabot[bot] chore(deps): bump flask from 2.2.2 to 2.2.3 in /tests/apps/multi
- #5676: @dependabot[bot] chore(deps): bump flask from 2.2.2 to 2.2.3 in /tests/apps/python-flask
We introduced a method of migrating from DOKKU_SCALE to app.json in 0.25.x. This was removed in 0.30.x, so users need to ensure they either set their own scale manually _or_ upgrade. The upgrade is probably the safest bet.
The following script was run from within the `plugins` directory:
for plugin in *; do
if [[ ! -f "/root/go/src/github.com/dokku/dokku/plugins/$plugin/go.mod" ]]; then continue; fi;
echo "$plugin"
pushd /root/go/src/github.com/dokku/dokku/plugins/$plugin;
go mod tidy;
go mod download;
popd >/dev/null;
done
While these don't (yet?) get submitted to the Digitalocean marketplace, it should bring us most of the way of making that possible.
The next step would be to somehow get notifications of the new image snapshot sent... Somewhere and have the lovely DO folks test/release it for us.
- Use linebreaks in a standard way
- Use the short url to get the bootstrap.sh script
- Store public key in a variable and reference that variable to avoid word-wrapping
- Use a shorter final sentence
- Remove console.log
- removals: things being removed in this release
- deprecations: things being deprecated in this release, for later removal
- dependencies: dependency updates (typically by dependabot)
# History
## 0.30.0
Install/update via the bootstrap script:
```shell
wget https://dokku.com/install/v0.30.0/bootstrap.sh
sudo DOKKU_TAG=v0.30.0 bash bootstrap.sh
```
See the [0.30.0 migration guide](/docs/appendices/0.30.0-migration-guide.md) for more information on migrating to 0.30.0.
### Bug Fixes
- #5674: @josegonzalez Use authenticated requests to the github api in order to generate changelogs for a release
- #5604: @josegonzalez Trigger nginx proxy rebuild early to avoid downtime if deploying large numbers of processes
- #5589: @josegonzalez Use warning_scheme variable instead of bare word in caddy-vhosts warning output
- #5580: @josegonzalez Do not attempt to reinstall already installed plugins
### New Features
- #5663: @josegonzalez Update build-base docker image to ensure we can build on all supported platforms without stalling
- #5308: @josegonzalez Implement haproxy proxy plugin
- #5633: @josegonzalez Add auto-updates to docs python dependencies
- #5603: @josegonzalez Add ability to deploy images generated via docker save with git:load-image
- #5591: @josegonzalez Allow the herokuish builder to be detected when the computed allowed value is set not set to false
- #5570: @josegonzalez Add support for customizing the remote in use for all commands sent via the official client
- #5581: @josegonzalez Use short url for installation
### Refactors
- #5659: @josegonzalez Remove deprecated functions and commands
### Documentation
- #5658: @mpslanker Updated debian install docs to work on both debian and ubuntu
- #5657: @josegonzalez Use correct version of Markdown for mkdocs
- #5656: @josegonzalez Add "new as of" prefix to version in user management docs
- #5645: @josegonzalez Update mkdocs-material features to cope with upgrade to 9.x
- #5632: @josegonzalez Add a note mentioning that network aliases only work when attached to a network other than bridge
- #5630: @josegonzalez Remove extra location block from built docs nginx config
- #5616: @jcalfee Add a note about reloading nginx to troubleshooting docs
- #5590: @josegonzalez Note that connecting to vagrant should be done via vagrant ssh
- #5588: @josegonzalez Document how to route to server-local apps via a service proxy
- #5585: @NicolasLM Improve instructions for disabling the default nginx site
### Tests
- #5673: @josegonzalez Cancel in progress builds when a new commit is pushed
- #5611: @josegonzalez Add more debugging output to deploy tests
- #5587: @josegonzalez Timeout build jobs within 45 minutes
### Other
- #5671: @dependabot[bot] chore(deps): bump soupsieve from 2.3.2.post1 to 2.4 in /docs/_build
- #5666: @dependabot[bot] chore(deps): bump golang from 1.20.0 to 1.20.1 in /tests/apps/go-fail-predeploy
- #5672: @dependabot[bot] chore(deps): bump django from 4.1.6 to 4.1.7 in /tests/apps/dockerfile-release
- #5670: @dependabot[bot] chore(deps): bump golang from 1.20.0 to 1.20.1 in /tests/apps/zombies-dockerfile-no-tini
- #5669: @dependabot[bot] chore(deps): bump golang from 1.20.0 to 1.20.1 in /tests/apps/go-fail-postdeploy
- #5668: @dependabot[bot] chore(deps): bump golang from 1.20.0 to 1.20.1 in /tests/apps/gogrpc
- #5667: @dependabot[bot] chore(deps): bump golang from 1.20.0 to 1.20.1 in /tests/apps/zombies-dockerfile-tini
- #5665: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 230 to 231 in /tests/apps/php
- #5664: @dependabot[bot] chore(deps): bump werkzeug from 2.2.2 to 2.2.3 in /tests/apps/python-flask
- #5559: @josegonzalez Move app.json extraction from built image artifact to source code
- #5661: @dependabot[bot] chore(deps): update markdown requirement from <3.4,>=3.2.1 to >=3.2.1,<3.5 in /docs/_build
- #5655: @dependabot[bot] chore(deps): bump zipp from 3.12.1 to 3.13.0 in /docs/_build
- #5654: @dependabot[bot] chore(deps): bump mkdocs-material from 9.0.11 to 9.0.12 in /docs/_build
- #5648: @dependabot[bot] chore(deps): bump markdown from 3.3.7 to 3.4.1 in /docs/_build
- #5650: @dependabot[bot] chore(deps): bump python from 3.11.1-buster to 3.11.2-buster in /tests/apps/dockerfile-release
- #5651: @dependabot[bot] chore(deps): bump ruby from 3.2.0 to 3.2.1 in /tests/apps/dockerfile-entrypoint
- #5652: @dependabot[bot] chore(deps): bump python from 3.11.1-alpine to 3.11.2-alpine in /docs/_build
- #5647: @dependabot[bot] chore(deps): bump importlib-metadata from 4.12.0 to 6.0.0 in /docs/_build
- #5646: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 229 to 230 in /tests/apps/php
- #5634: @dependabot[bot] chore(deps): bump mkdocs-material from 8.4.2 to 9.0.11 in /docs/_build
- #5637: @dependabot[bot] chore(deps): bump packaging from 21.3 to 23.0 in /docs/_build
- #5643: @dependabot[bot] chore(deps): bump watchdog from 2.1.9 to 2.2.1 in /docs/_build
- #5642: @dependabot[bot] chore(deps): bump pymdown-extensions from 9.5 to 9.9.2 in /docs/_build
- #5639: @dependabot[bot] chore(deps): bump mkdocs from 1.3.1 to 1.4.2 in /docs/_build
- #5638: @dependabot[bot] chore(deps): bump mkdocs-material-extensions from 1.0.3 to 1.1.1 in /docs/_build
- #5631: @dependabot[bot] chore(deps): bump socket.io from 4.5.4 to 4.6.0 in /tests/apps/.websocket.disabled
- #5636: @dependabot[bot] chore(deps): bump markupsafe from 2.1.1 to 2.1.2 in /docs/_build
- #5641: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.11.1 to 4.11.2 in /docs/_build
- #5635: @dependabot[bot] chore(deps): bump pygments from 2.13.0 to 2.14.0 in /docs/_build
- #5640: @dependabot[bot] chore(deps): bump zipp from 3.8.1 to 3.12.1 in /docs/_build
- #5629: @josegonzalez Update list indentation explaining network property utilization
- #5617: @dependabot[bot] chore(deps): bump golang from 1.19.5 to 1.20.0 in /tests/apps/go-fail-predeploy
- #5620: @dependabot[bot] chore(deps): bump golang from 1.19.5 to 1.20.0 in /tests/apps/gogrpc
- #5618: @dependabot[bot] chore(deps): bump golang from 1.19.5 to 1.20.0 in /tests/apps/go-fail-postdeploy
- #5625: @dependabot[bot] chore(deps): bump django from 4.1.2 to 4.1.6 in /tests/apps/dockerfile-release
- #5619: @dependabot[bot] chore(deps): bump golang from 1.19.5 to 1.20.0 in /tests/apps/zombies-dockerfile-no-tini
- #5621: @dependabot[bot] chore(deps): bump golang from 1.19.5 to 1.20.0 in /tests/apps/zombies-dockerfile-tini
- #5615: @dependabot[bot] chore(deps): bump ludeeus/action-shellcheck from 1.1.0 to 2.0.0
- #5610: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 227 to 229 in /tests/apps/php
- #5608: @josegonzalez tests: refactor the config test to use a simple python codebase instead
- #5606: @josegonzalez Ensure the mounted services directory is symlinked correctly
- #5558: @josegonzalez Remove references to ubuntu 18.04 ahead of EOL
- #5600: @dependabot[bot] chore(deps): bump rack from 2.2.4 to 2.2.6.2 in /tests/apps/ruby
- #5598: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 3.0.0 to 3.1.0
- #5595: @josegonzalez Remove deprecated ability to call logs:failed without specifying an app or --all flag
- #5594: @josegonzalez Remove deprecated builder-specific post-release hooks
- #5593: @josegonzalez Remove deprecated --detach flag
- #5592: @josegonzalez Remove support for DOKKU_SCALE file
- #5560: @josegonzalez Drop SPDY support from nginx plugin
- #5579: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.4.0 to 3.5.0 in /tests/apps/java
Because the app-json extraction happens before the build-dir is set, it doesn't end up respecting the value, and thus the user might get the wrong app.json file.
This takes advantage of path.Join()'s default of ignoring empty paths.
The image can now be built via:
docker buildx build --platform linux/arm,linux/arm64,linux/amd64 --progress plain --push --tag dokku/build-base:latest --tag dokku/build-base:0.0.1 -f contrib/build-base.Dockerfile .
Due to how the nginx proxy implementation works, if an app has either many process types or many containers for a process type other than web, it is possible to see downtime on the web process due to the old web containers rotating out _before_ we reload the nginx config.
The correct fix would be to use some sort of dns-based resolution for the nginx config, but pending that change, we reload nginx twice now - ugh - to avoid this.
While we will still build for 18.04, we will now stop testing against it. Instead, we will test against 20.04, the next EOL release after 18.04.
Once Ubuntu 18.04 is EOL, any references to it will also be removed.
Note that 18.04 support was already deprecated in Dokku 0.28.0, so this change is just acknowledging that deprecation.
The previous static-web-listener network property doesn't work with caddy and traefik as resolution of requests works quite differently given that they only proxy to docker containers. The new method uses the dokku/service-proxy docker image to proxy requests in a lightweight manner.
Closes#5409Closes#5586
The previous instructions for disabling the default site left things in
an in-between state: it still returned an error page and did not disable
the default HTTPS site unless the user figured out how to generate
a valid SSL certificate.
The changes made in this commit assume that the user actively disabling
the default site considers all requests to unknown vhosts as bogus.
Therefore there is no point in responding and providing a valid SSL
certificate to them.
As such, the recommended error code is now `444` to close the connection
without responding and the HTTPS default site is disabled with
a self-signed certificate.
Also as all distributions supported by Dokku use systemd, make use of it
instead of the legacy `service` command which does not work anymore on
some distributions like Arch.
# History
## 0.29.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.4/bootstrap.sh
sudo DOKKU_TAG=v0.29.4 bash bootstrap.sh
```
### Bug Fixes
- #5571: @josegonzalez Ensure we properly setup all data directories on app install and creation
- #5555: @josegonzalez Drop debugging code from ps plugin
### Documentation
- #5563: @kbuilds Clarify documentation for default site under nginx
### Tests
- #5557: @josegonzalez Update GitHub actions
### Other
- #5577: @dependabot[bot] chore(deps): bump golang from 1.19.4 to 1.19.5 in /tests/apps/gogrpc
- #5573: @dependabot[bot] chore(deps): bump golang from 1.19.4 to 1.19.5 in /tests/apps/go-fail-postdeploy
- #5574: @dependabot[bot] chore(deps): bump golang from 1.19.4 to 1.19.5 in /tests/apps/zombies-dockerfile-tini
- #5575: @dependabot[bot] chore(deps): bump golang from 1.19.4 to 1.19.5 in /tests/apps/go-fail-predeploy
- #5576: @dependabot[bot] chore(deps): bump golang from 1.19.4 to 1.19.5 in /tests/apps/zombies-dockerfile-no-tini
# History
## 0.29.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.3/bootstrap.sh
sudo DOKKU_TAG=v0.29.3 bash bootstrap.sh
```
### Bug Fixes
- #5544: @josegonzalez Exit non-zero when git:from-image deploys fail to start the app
- #5543: @josegonzalez Properly parse arguments for git:status command
### Tests
- #5554: @josegonzalez Validate that procfile-path is respected
### Other
- #5551: @dependabot[bot] chore(deps): bump ruby from 3.1.3 to 3.2.0 in /tests/apps/dockerfile-entrypoint
- #5547: @dependabot[bot] chore(deps): bump setuptools from 65.5.0 to 65.5.1 in /tests/apps/dockerfile-release
- #5542: @josegonzalez Add json output format support to storage:list
# History
## 0.29.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.1/bootstrap.sh
sudo DOKKU_TAG=v0.29.1 bash bootstrap.sh
```
### Bug Fixes
- #5532: @josegonzalez Fix issue where git:from-image deploys may result in extracted files not being respected
### Documentation
- #5531: @josegonzalez Fix indentation on heading in where to get help
- #5521: @AlejandroAkbal Remove reference to `--rm` flag cron task documentation
- #5517: @josegonzalez Fix reference to scheduler name in kubernetes docs
- #5516: @josegonzalez Fix reference to scheduler name in nomad docs
### Tests
- #5533: @josegonzalez Add a test case for nested vector-sink values with plus signs
### Other
- #5534: @dependabot[bot] chore(deps): bump sinatra from 3.0.4 to 3.0.5 in /tests/apps/ruby
- #5514: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/go-fail-predeploy
- #5512: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/go-fail-postdeploy
- #5513: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/zombies-dockerfile-no-tini
- #5511: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/zombies-dockerfile-tini
- #5510: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/gogrpc
- #5525: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.12 to 11.0.13 in /tests/apps/java
- #5519: @dependabot[bot] chore(deps): bump python from 3.11.0-buster to 3.11.1-buster in /tests/apps/dockerfile-release
- #5520: @dependabot[bot] chore(deps): bump python from 3.11.0-alpine to 3.11.1-alpine in /docs/_build
# History
## 0.29.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.0/bootstrap.sh
sudo DOKKU_TAG=v0.29.0 bash bootstrap.sh
```
See the [0.29.0 migration guide](/docs/appendices/0.29.0-migration-guide.md) for more information on migrating to 0.29.0.
### Bug Fixes
- #5506: @josegonzalez Add support for escaped plus (+) signs in vector configurations
- #5505: @josegonzalez Add missing event hooks
- #5493: @josegonzalez Correct issue with detection of non-https port mapping as https port mapping
- #5499: @josegonzalez Do not use traefik priority in service name
- #5491: @josegonzalez Add missing http part to traefik routing rule
- #5477: @josegonzalez Add missing config_sub entry to config gitignore
- #5474: @josegonzalez Add missing source call
- #5345: @esirK Always set app created-at via property instead of introspecting on folder creation time
- #5456: @cooperaj Ensure Traefik only attempts to obtain certificate for api when enabled
- #5466: @josegonzalez Drop the app argument when calling storage:ensure-directory from remote client
- #5458: @cooperaj Ensure the TLS resolver is specifed for HTTPS enabled apps
- #5448: @josegonzalez Do not attempt to attach a network to a container that already has it
### New Features
- #5494: @josegonzalez Silence the warning message when there are no dokku apps on install
- #5490: @josegonzalez Add ability to set a custom priority for traefik routing rules
- #5489: @josegonzalez Use exit code 137 to signify a lock was unable to be retrieved when calling ps:retire
- #5487: @josegonzalez Use a priority when routing requests with traefik
- #5481: @josegonzalez Drop installation of nginx ppa
- #5478: @josegonzalez Allow users to enable herokuish usage on arm/arm64 platforms
- #5479: @josegonzalez Cleanup builder code and docs
- #5476: @josegonzalez Add fileutils plugin to the devcontainer
- #5473: @josegonzalez Add warning when a user is attempting to deploy with an ipv4/ipv6 domain name and has the default nginx site file available
- #5451: @josegonzalez Add git:status subcommand
- #5349: @josegonzalez Error out when executing caddy and traefik commands without the compose plugin installed
- #5322: @josegonzalez Implement run:logs command
- #5321: @josegonzalez Implement run:stop command
- #5434: @josegonzalez Upgrade to go 1.19 everywhere
- #5320: @josegonzalez Add json format output to run:list
### Refactors
- #5488: @josegonzalez De-duplicate proxy building and simplify url generation
- #5454: @josegonzalez Switch from base64-encoding to base36-encoding of cron task IDs
### Documentation
- #5509: @josegonzalez Update data loss blockquote to be warning
- #5507: @josegonzalez Add tutorials link to navigation
- #5503: @josegonzalez Document potential deployment downtime
- #5484: @IgnisDa Add edgedb community plugin
- #5482: @JonathanMH Fixes minor typos in proxy docs
- #5465: @josegonzalez Fix embedded lists on deployment tasks
- #5430: @pablobm Clarify that proxy:build-config is required for any nginx:set call
- #5447: @josegonzalez Specify correct command for builder-lambda:report
- #5429: @pablobm Clarify details of the default template
### Tests
- #5449: @josegonzalez Install goverage via go get
### Other
- #5500: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.3.0 to 3.4.0 in /tests/apps/java
- #5472: @josegonzalez Start started proxies automatically during ps:restore
- #5497: @dependabot[bot] chore(deps): bump ruby from 3.1.2 to 3.1.3 in /tests/apps/dockerfile-entrypoint
- #5496: @dependabot[bot] chore(deps): bump sinatra from 3.0.3 to 3.0.4 in /tests/apps/ruby
- #5480: @josegonzalez Cleanup zero'd out processes when a Procfile omitting those process types is set
- #5475: @josegonzalez Refactor nginx.conf.sigil to be extracted from a specified path in source code instead of the built image
- #5467: @josegonzalez Move DOKKU_WAIT_TO_RETIRE to a checks property
- #5455: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 2.1.0 to 3.0.0
- #5463: @dependabot[bot] chore(deps): bump sinatra from 3.0.2 to 3.0.3 in /tests/apps/ruby
- #5450: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 226 to 227 in /tests/apps/php
- #5437: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/zombies-dockerfile-tini
- #5441: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/gogrpc
- #5440: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/go-fail-predeploy
- #5439: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/zombies-dockerfile-no-tini
- #5438: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/go-fail-postdeploy
- #5431: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 225 to 226 in /tests/apps/php
- #5426: @dependabot[bot] chore(deps): bump python from 3.10.0-buster to 3.11.0-buster in /tests/apps/dockerfile-release
- #5319: @josegonzalez Use container name instead of container id for run:detached output
- #5427: @dependabot[bot] chore(deps): bump python from 3.10.8-alpine to 3.11.0-alpine in /docs/_build
The URLS file is no longer necessary as urls are now generated directly from the app VHOST file.
This also moves all the url generation logic to the domains plugin.
This allows us to be backwards compatible when executing git:from-image.
The nice thing about this pattern is we can also extend it to other parts of the deployment as well, such asn nginx-vhosts fetching
This change also moves the referenced Procfile out to a host path once on deploy vs potentially several times, which should speed up deploys a small amount and simplify reasoning about the file.
Closes#5112
While the majority of buildpacks do not work on non-amd64 platforms, this will at least allow developers the option to choose when to override this setting.
The previous method was a bit more difficult for users to interact with as they needed to ensure the file was at a certain path in the built image. This change divorces the file from the built artifact, better aligning the nginx.conf.sigil handling with the rest of Dokku's monorepo support.
A side effect of this is now building proxy configurations does not require access to the built image.
Closes#5207
You can then proceed to configure your server domain (via `dokku domains:set-global`) and user access (via `dokku ssh-keys:add`) to complete the installation.
echo -en "We did not detect any issues with this image. Please be sure to manually ensure that all software installed on the base system is functional, secure and properly configured (or facilities for configuration on first-boot have been created).\n\n"
exit 0
elif [[ $STATUS == 1 ]]; then
echo -en "Please review all [WARN] items above and ensure they are intended or resolved. If you do not have a specific requirement, we recommend resolving these items before image submission\n\n"
exit 0
else
echo -en "Some critical tests failed. These items must be resolved and this scan re-run before you submit your image to the DigitalOcean Marketplace.\n\n"
if OUTPUT=$(curl -u "$RELEASE_GITHUB_USERNAME:$RELEASE_GITHUB_API_TOKEN" --fail -sS "https://api.github.com/repos/dokku/dokku/issues/${PULL_REQUEST_ID}" 2>&1); then
echo "$OUTPUT" >"$ISSUE_FILE"
break
fi
log-error "Error while fetching info for pull/$PULL_REQUEST_ID, sleeping for 5 seconds"
@@ -28,11 +58,11 @@ The storage plugin supports the following mount points:
A storage directory can be created with the `storage:ensure-directory` command. This command will create a subdirectory in the recommended `/var/lib/dokku/data/storage` path - created during Dokku installation - and prepare it for use with an app.
You cannot use mounted volumes during the build phase of a Dockerfile deploy. This is because Docker does not support volumes when executing `docker build`.
> Note: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
> Warning: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
## App User and Persistent Storage file ownership (buildpack apps only)
> Warning: All plugin commands other than `plugin:list` and `plugin:help` require sudo access and must be run directly from the Dokku server.
@@ -78,6 +78,8 @@ dokku plugin:installed postgres
### Installing a plugin
> Note: Plugins installed in this method within a [docker-based installation](/docs/getting-started/install/docker.md) of Dokku do not persist across installs. Please see the [plugin installation section](/docs/getting-started/install/docker.md#plugin-installation) of the docker-based installation docs for further details.
Installing a plugin is easy as well using the `plugin:install` command. This command will also trigger the `install` pluginhook on all existing plugins.
The most common usage is to install a plugin from a url. This url may be any of the following:
- notes: The `$AWS_ACCOUNT_ID` and `$AWS_REGION` should match the values for your account and region, respectively. Additionally, an IAM profile that allows `push` access to the repository specified by `image-repo` should be attached to your Dokku server.
- notes: The `$AWS_ACCOUNT_ID` and `$AWS_REGION` should match the values for your account and region, respectively. Additionally, an IAM profile that allows `push` access to the repository specified by `image-repo` should be attached to your Dokku server.
- Azure Container Registry:
- value `$REGISTRY_NAME.azurecr.io/`
- notes: The `$AKS_REGISTRY_NAME` should match the name of the registry created on your account.
- value `$REGISTRY_NAME.azurecr.io/`
- notes: The `$AKS_REGISTRY_NAME` should match the name of the registry created on your account.
- Docker Hub:
- value: `docker.io/`
- notes: Requires owning the namespace used in the `image-repo` value.
- value: `docker.io/`
- notes: Requires owning the namespace used in the `image-repo` value.
- Digitalocean:
- value: `registry.digitalocean.com/`
- notes: Requires setting the correct `image-repo` value for your registry.
- value: `registry.digitalocean.com/`
- notes: Requires setting the correct `image-repo` value for your registry.
- Github Container Registry:
- value: `ghcr.io/`
- notes: Requires that the authenticated user has access to the namespace used in the `image-repo` value.
- value: `ghcr.io/`
- notes: Requires that the authenticated user has access to the namespace used in the `image-repo` value.
- The output of `run:detached` now uses the container name - eg. `node-js-app.run.1` - vs the container id.
- The ID of `cron` tasks is now base36-encoded instead of base64-encoded.
- The `nginx.conf.sigil` is now extracted when source code is extracted for a build and not from the built image. Users can specify alternative paths via the `nginx-conf-sigil-path` property of the `nginx` plugin. See the [nginx documentation](/docs/networking/proxies/nginx.md#customizing-the-nginx-configuration) for more information on how to configure the `nginx.conf.sigil` path for your application.
- For deploys via `git:from-image`, the `nginx.conf.sigil` file will be extracted from the source image, respecting the value of `nginx-conf-sigil-path`.
- The `Procfile` is now extracted when source code is extracted for a build and not from the built image. Users can specify alternative paths via the `procfile-path` property of the `ps` plugin. See the [process management documentation](/docs/processes/process-management.md#changing-the-procfile-location) for more information on how to configure the `Procfile` path for your application.
- For deploys via `git:from-image`, the `Procfile` file will be extracted from the source image, respecting the value of `procfile-path`.
- The existing `pre-restore` hook has been renamed to `scheduler-pre-restore`. There is a new `pre-restore` hook that is triggered within the `ps:restore` command prior to restoring any apps.
- Nginx init commands are now performed via systemctl on Ubuntu systems when `/usr/bin/systemctl` is available.
## Removals
- The `DOKKU_WAIT_TO_RETIRE` environment variable has been migrated to a `checks` property named `wait-to-retire` and will be ignored if set as an environment variable.
- The `domains-setup` trigger has been removed. Initial app domains will now be automatically setup during app creation.
- The `URLS` file containing generated urls for an app is no longer generated or referenced. Users should retrieve app urls via the new `domains-urls` plugin trigger.
- The common function `get_app_urls` has been removed. Users should retrieve app urls via the new `domains-urls` plugin trigger.
> **Important**: Due to the removal of `DOKKU_SCALE` support, users with a version older than 0.25.x are heavily encouraged to upgrade to 0.29.x prior to 0.30.x. Not doing so will result in all app containers stopping on rebuild due to having no scale settings.
## Deprecations
- Support for Ubuntu 18.04 has been deprecated. Please upgrade your host OS in advance of the [End Of Life in April 2023](https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes).
## Changes
- The `app.json` file is now extracted from the source code instead of the built image. For deploys via `git:from-image`, the file is extracted from the built image.
## Removals
- Support for [SPDY](https://en.wikipedia.org/wiki/SPDY) has been removed. No major browser supports it as of 2021. Custom `nginx.conf.sigil` templates referencing spdy-related variables will continue to build until the 1.0.0 release.
- Support for the `DOKKU_SCALE` file - deprecated in 0.25.0 - has been removed in favor of the `formation` key in the `app.json` file. Please see the [process management documentation](/docs/processes/process-management.md#manually-managing-process-scaling) for more information on how to use the `formation` key of the `app.json` file.
- The deprecated `--detach` global flag for `dokku run` was removed. Please see the [one-off tasks documentation](/docs/processes/one-off-tasks.md#running-a-detached-container) for more information on running detached containers.
- The following deprecated trigger have been removed in favor of the `post-release-builder` trigger. See the [plugin triggers documentation](https://dokku.com/docs/development/plugin-triggers/#post-release-builder) for more details.
-`post-release-buildpack`
-`post-release-dockerfile`
-`post-release-pack`
- The ability to call `logs:failed` without specifying an app or `--all` flag has been removed. This was deprecated in 0.22.0. Please see the [logs:failed](/docs/deployment/logs.md#failed-deploy-logs).
- The following app shell functions - deprecated since 0.20.0 - have been removed in favor of their plugin trigger equivalents. Sourcing the `app/functions` file will fail going forward.
-`apps#apps_create()` is removed in favor of `plugn trigger app-create`.
-`apps#apps_destroy()` is removed in favor of `plugn trigger app-destroy`.
-`apps#apps_exists()` is removed in favor of `plugn trigger app-exists`.
-`apps#apps_maybe_create()` is removed in favor of `plugn trigger app-maybe-create`.
- The following common shell functions have been removed:
-`common#is_container_running()` (deprecated since 0.12.6) is removed in favor of `common#is_container_status()`.
-`common#is_app_running()` (deprecated since 0.22.0) is removed in favor of `ps#fn-ps-is-app-running()`.
- The global `--rm-container` and `--rm` flags - deprecated since 0.25.0 - have been removed.
- The following git shell functions have been removed:
-`git#use_git_worktree()` (deprecated since 0.23.7) has been removed. There is no alternative as the function has been made internal.
-`git#git_deploy_branch()`(deprecated since 0.21.0) has been removed in favor of `plugn trigger git-deploy-branch`.
- The following nginx commands - deprecated since 0.20.0 - have been removed:
-`nginx:show-conf` has been removed in favor of `nginx:show-config`.
-`nginx:validate` has been removed in favor of `nginx:validate-config`.
-`nginx:build-config` - deprecated since 0.21.0 - has been removed in favor of `proxy:build-config`.
- The following proxy functions - deprecated since 0.20.0 - have been removed in favor of their plugin trigger equivalents. Sourcing the `proxy/functions` file will fail going forward.
-`proxy#is_app_proxy_enabled()` is removed in favor of `plugn trigger proxy-is-enabled`.
-`proxy#get_app_proxy_type()` is removed in favor of `plugn trigger proxy-type`.
In order to leverage cloud-provider facilities like _attachable volumes_, (_a.k.a. block storage_)
the following is an easy tutorial to achieve Dokku runs on them.
> Warning: If the block storage is not available and attached on boot it is possible that containers will not correctly start. Please keep this in mind when considering moving Dokku and/or Docker to network attached storage.
## Tutorial
The following is intended to be executed on the dokku host machine as `root`.
Say, _for instance_, that our volume is mapped into the systems as `/dev/vdb1`.
Stop docker daemon
```shell
systemctl stop docker
```
Prepare the filesystem:
```shell
mkfs -t ext4 /dev/vdb1
mkdir /mnt/volume
mount /dev/vdb1 /mnt/volume
```
Move the old data directories:
```shell
mv /home/dokku /home/dokku.OLD
mv /var/lib/docker /var/lib/docker.OLD
mv /var/lib/dokku /var/lib/dokku.OLD
```
Move the data on the volume
```shell
mkdir /mnt/volume/home/
mkdir -p /mnt/volume/var/lib/
mv /home/dokku.OLD /mnt/volume/home/dokku
mv /var/lib/dokku.OLD /mnt/volume/var/lib/dokku
mv /var/lib/docker.OLD /mnt/volume/var/lib/docker
```
Prepare the mountpoints
```shell
mkdir /home/dokku
mkdir /var/lib/dokku
mkdir /var/lib/docker
chown dokku:dokku /home/dokku # respect the original ownership
chmod 711 /var/lib/docker # respect the original permissions
```
Mount bind
```shell
mount -o bind /mnt/volume/home/dokku /home/dokku
mount -o bind /mnt/volume/var/lib/dokku /var/lib/dokku
mount -o bind /mnt/volume/var/lib/docker /var/lib/docker
```
Start docker daemon
```shell
systemctl start docker
```
At this point all should be working fine, please check it out.
Then, let the changes be reboot-persistent
```shell
echo'/dev/vdb1 /mnt/volume ext4 defaults 0 2'| sudo tee -a /etc/fstab
echo'/mnt/volume/home/dokku /home/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/dokku /var/lib/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/docker /var/lib/docker none defaults,bind 0 0'| sudo tee -a /etc/fstab
@@ -92,7 +92,6 @@ The following config variables have special meanings and can be set in a variety
| `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` | `https://dokku.com/docs/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 | Deprecated: 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 /> | Deprecated: Whether to keep `dokku run` containers around or not. |
| `DOKKU_TRACE` | none | `dokku trace:on` <br /> `dokku trace:off` <br /> `--trace` flag | Turn on very verbose debugging. |
@@ -125,4 +124,3 @@ The following config variables have special meanings and can be set in a variety
| `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. |
builder-dockerfile:report [<app>] [<flag>] # Displays a builder-dockerfile report for one or more apps
builder-dockerfile:set <app> <key> (<value>) # Set or clear a builder-dockerfile property for an app
```
While Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, you can also use Docker's native `Dockerfile` system to define a container.
> Dockerfile support is considered a *power user* feature. By using Dockerfile-based deployment, you agree that you will not have the same comfort as that enjoyed by buildpack users, and Dokku features may work differently. Differences between the two systems will be documented here.
@@ -12,6 +12,11 @@ buildpacks:set [--index 1] <app> <buildpack> # Set new app buildpack
buildpacks:set-property [--global|<app>] <key> <value> # Set or clear a buildpacks property for an app
```
```
builder-herokuish:report [<app>] [<flag>] # Displays a builder-herokuish report for one or more apps
builder-herokuish:set <app> <key> (<value>) # Set or clear a builder-herokuish property for an app
```
> Warning: If using the `buildpacks` plugin, be sure to unset any `BUILDPACK_URL` and remove any such entries from a committed `.env` file. A specified `BUILDPACK_URL` will always override a `.buildpacks` file or the buildpacks plugin.
Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
By default, the builder-herokuish plugin is not enabled for non-amd64 platforms, and attempting to use it is blocked. This is because the majority of buildpacks are not cross-platform compatible, and thus building apps will either be considerably slower - due to emulating the amd64 platform - or won't work - due to building amd64 packages on arm/arm64 platforms.
To force-enable herokuish on non-amd64 platforms, the `allowed` property can be set via `builder-herokuish:set`. The default value depends on the host platform architecture (`true` on amd64, `false` otherwise).
The default value may be set by passing an empty value for the option:
```shell
dokku builder-herokuish:set node-js-app allowed
```
The `allowed` property can also be set globally. The global default is platform-dependent, and the global value is used when no app-specific value is set.
```shell
dokku builder-herokuish:set --global allowed true
```
The default value may be set by passing an empty value for the option.
```shell
dokku builder-herokuish:set --global allowed
```
### Displaying buildpack reports for an app
You can get a report about the app's buildpacks status using the `buildpacks:report` command:
@@ -211,6 +246,54 @@ You can pass flags which will output only the value of the specific information
builder-lambda:report [<app>] [<flag>] # Displays a builder-lambda report for one or more apps
builder-lambda:set <app> <key> (<value>) # Set or clear a builder-lambda property for an app
```
The `lambda` builder builds AWS Lambda functions in an environment simulating AWS Lambda runtimes via [lambda-builder](https://github.com/dokku/lambda-builder). Apps built via this builder can run natively in Dokku and may also have their artifacts scheduled to Lambda via an appropriate scheduler.
@@ -7,11 +7,13 @@ git:allow-host <host> # Adds a host to known_hosts
git:auth <host> [<username> <password>] # Configures netrc authentication for a given git server
git:from-archive [--archive-type ARCHIVE_TYPE] <app> <archive-url> [<git-username> <git-email>] # Updates an app's git repository with a given archive file
git:from-image [--build-dir DIRECTORY] <app> <docker-image> [<git-username> <git-email>] # Updates an app's git repository with a given docker image
git:load-image [--build-dir DIRECTORY] <app> <docker-image> [<git-username> <git-email>] # Updates an app's git repository with a docker image loaded from stdin
git:sync [--build] <app> <repository> [<git-ref>] # Clone or fetch an app from remote git repo
git:initialize <app> # Initialize a git repository for an app
git:public-key # Outputs the dokku public deploy key
git:report [<app>] [<flag>] # Displays a git report for one or more apps
git:set <app> <key> (<value>) # Set or clear a git property for an app
git:status <app> # Show the working tree status for an app
git:unlock <app> [--force] # Removes previous git clone folder for new deployment
```
@@ -135,6 +137,8 @@ In the above example, Dokku will build the app as if the repository contained _o
FROMdokku/node-js-getting-started:latest
```
If the specified image already exists on the Dokku host, it will not be pulled again, though this behavior may be changed using [build phase docker-options](/docs/advanced-usage/docker-options.md).
Triggering a build with the same arguments multiple times will result in Dokku exiting `0` early as there will be no changes detected. If the image tag is reused but the underlying image is different, it is recommended to use the image digest instead of the tag. This can be retrieved via the following command:
If the image is a private image that requires a docker login to access, the `registry:login` command should be used to log into the registry. See the [registry documentation](/docs/advanced-usage/registry-management.md#logging-into-a-registry) for more details on this process.
Building an app from an image will result in the following files being extracted from the source image (with all custom paths specified for each file being respected):
-`app.json`
-`nginx.conf.sigil`
-`Procfile`
In the case where the repository is later modified to manually add any of the above files and deployed via `git push`, the files will still be extracted from the initial source image. To avoid this, please clear the `source-image` git property. It will be set back to the original source image on any subsequent `git:from-image` calls.
```shell
# sets an empty value
dokku git:set node-js-app source-image
```
Finally, certain images may require a custom build context in order for `ONBUILD ADD` and `ONBUILD COPY` statements to succeed. A custom build context can be specified via the `--build-dir` flag. All files in the specified `build-dir` will be copied into the repository for use within the `docker build` process. The build context _must_ be specified on each deploy, and is not otherwise persisted between builds.
```shell
@@ -196,6 +213,62 @@ Finally, if the archive url is specified as `--`, the archive will be fetched fr
### Initializing an app repository from a remote image without a registry
> New as of 0.30.0
A Dokku app repository can be initialized or updated from the contents of an image archive tar file via the `git:load-image` command. This method can be used when a Docker Registry is unavailable to act as an intermediary for storing an image, such as when building an image in CI and deploying directly from that image.
```shell
docker image save dokku/node-js-getting-started:latest | ssh dokku@dokku.me git:load-image node-js-app dokku/node-js-getting-started:latest
```
In the above example, we are saving the image to a tar file via `docker image save`, streaming that to the Dokku host, and then running `git:load-image` on the incoming stream. Dokku will build the app as if the repository contained _only_ a `Dockerfile` with the following content:
```Dockerfile
FROMdokku/node-js-getting-started:latest
```
When deploying an app via `git:load-image`, it is highly recommended to use a unique image tag when building the image. Not doing so will result in Dokku exiting `0` early as there will be no changes detected. If the image tag is reused but the underlying image is different, it is recommended to use the image digest instead of the tag. This can be retrieved via the following command:
The resulting `git:load-image` call would then be:
```shell
# where the image sha is: sha256:9d187c3025d03c033dcc71e3a284fee53be88cc4c0356a19242758bc80cab673
docker image save dokku/node-js-getting-started:latest | ssh dokku@dokku.me git:load-image node-js-app dokku/node-js-getting-started@sha256:9d187c3025d03c033dcc71e3a284fee53be88cc4c0356a19242758bc80cab673
```
The `git:load-image` command can optionally take a git `user.name` and `user.email` argument (in that order) to customize the author. If the arguments are left empty, they will fallback to `Dokku` and `automated@dokku.sh`, respectively.
Building an app from an image will result in the following files being extracted from the source image (with all custom paths specified for each file being respected):
-`app.json`
-`nginx.conf.sigil`
-`Procfile`
In the case where the repository is later modified to manually add any of the above files and deployed via `git push`, the files will still be extracted from the initial source image. To avoid this, please clear the `source-image` git property. It will be set back to the original source image on any subsequent `git:load-image` calls.
```shell
# sets an empty value
dokku git:set node-js-app source-image
```
Finally, certain images may require a custom build context in order for `ONBUILD ADD` and `ONBUILD COPY` statements to succeed. A custom build context can be specified via the `--build-dir` flag. All files in the specified `build-dir` will be copied into the repository for use within the `docker build` process. The build context _must_ be specified on each deploy, and is not otherwise persisted between builds.
@@ -89,6 +89,22 @@ In addition, the following commands have special local side-effects:
-`apps:destroy`:
- Removes the local `dokku` git remote if set.
#### Specifying a remote
While many users will only ever push to a single dokku remote from a given repository, it may be useful to point the same repository at multiple remotes, especially in the case of pre-production environments. This can be done via the `remote` commands. These commands are _only_ available within the official remote client, and are not server-side commands.
To see your currently configured remote, run `dokku remote`. This will respect the `--remote` flag.
To list all available remotes, run `dokku remote:list`. This is equivalent to running `git remote`.
To add a remote, run `dokku remote:add $REMOTE_NAME dokku@dokku.me:$APP_NAME`, replacing `$REMOTE_NAME` with your desired remote name, the `$APP_NAME` with your desired app name and the host `dokku.me` with your Dokku host. This is equivalent to running `git remote add $REMOTE_NAME dokku@dokku.me:$APP_NAME`.
To remove a remote, run `dokku remote:remove $REMOTE_NAME`. This is equivalent to running `git remote remove $REMOTE_NAME`.
By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote _must_ be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
To clear the configured remote, run `dokku remote:unset`. The client will unset the configured remote, and will default back to `dokku`, or the value of `--remote` if specified.
## Unofficial Clients
Please refer to the [community clients](/docs/community/clients.md) list for more details.
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
checks:run <app> [process-type(s)] Runs zero-downtime checks for all processes (or comma-separated process-type list)
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
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
checks:run <app> [process-type(s)] Runs zero-downtime checks for all processes (or comma-separated process-type list)
checks:set [--global|<app>] <key> <value> Set or clear a logs property for an app
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
```
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds *after* the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
@@ -22,13 +23,24 @@ You may both create user-defined checks for web processes using a `CHECKS` file,
> - Allow checks from all hostnames: Modify your application to accept a dynamically provided hostname.
> - Specify the domain within the check: See below for further documentation.
## Configuring checks settings
### wait-to-retire
After a successful deploy, the grace period given to old containers before they are stopped/terminated is determined by the value of `wait-to-retire`. This is useful for ensuring completion of long-running HTTP connections.
```shell
dokku checks:set node-js-app wait-to-retire 30
```
Defaults to `60`.
## Configuring check settings using the `config` plugin
There are certain settings that can be configured via environment variables:
-`DOKKU_DEFAULT_CHECKS_WAIT`: (default: `10`) If no user-defined checks are specified - or if the process being checked is not a `web` process - this is the period of time Dokku will wait before checking that a container is still running.
-`DOKKU_DOCKER_STOP_TIMEOUT`: (default: `10`) Configurable grace period given to the `docker stop` command. If a container has not stopped by this time, a `kill -9` signal or equivalent is sent in order to force-terminate the container. Both the `ps:stop` and `apps:destroy` commands *also* respect this value. If not specified, the Docker defaults for the [`docker stop` command](https://docs.docker.com/engine/reference/commandline/stop/) will be used.
-`DOKKU_WAIT_TO_RETIRE`: (default: `60`) 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.
The following settings may also be specified in the `CHECKS` file, though are available as environment variables in order to ease application reuse.
- Description: Allows modification of the used dokku-image.
@@ -221,6 +221,52 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `builder-get-property`
- Description: Return the value for an app's builder property
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";PROPERTY="$2"
# TODO
```
### `builder-image-is-cnb`
- Description: Checks if an image is cnb-based
- Invoked by: unit tests
- Arguments: `$APP``$IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `builder-image-is-herokuish`
- Description: Checks if an image is herokuish-based
- Invoked by: unit tests
- Arguments: `$APP``$IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `builder-release`
- Description: Triggers the artifact release process
@@ -236,6 +282,21 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `certs-exists`
- Description: Echos `true` if certs exists for the app, `false` otherwise
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `check-deploy`
- Description: Allows you to run checks on a deploy before Dokku allows the container to handle requests.
@@ -262,6 +323,22 @@ if [[ "$DOKKU_DISABLE_DEPLOY" = "true" ]]; then
fi
```
### `checks-get-property`
- Description: Return the value for an app's checks property
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";PROPERTY="$2"
# TODO
```
### `commands help` and `commands <PLUGIN_NAME>:help`
- Description: Your plugin should implement a `help` command in your `commands` file to take advantage of this plugin trigger. `commands help` is used by `dokku help` to aggregate all plugins abbreviated `help` output. Implementing `<PLUGIN_NAME>:help` in your `commands` file gives users looking for help, a more detailed output. 'commands help' must be implemented inside the `commands` plugin file. It's recommended that `PLUGIN_NAME:help` be added to the commands file to ensure consistency among community plugins and give you a new avenue to share rich help content with your user.
@@ -697,11 +774,11 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `domains-setup`
### `domains-urls`
- Description: Initializes domains for an app if enabled
- Description: Gets an app's url(s)
- Invoked by:
- Arguments: `$APP`
- Arguments: `$APP $URL_TYPE`
- Example:
```shell
@@ -742,6 +819,22 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `git-get-property`
- Description: Return the value for an app's git property
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";PROPERTY="$2"
# TODO
```
### `git-from-archive`
- Description: Updates an app's git repository from an archive and then triggers a build
@@ -869,9 +962,9 @@ fi
### `logs-get-property`
- Description: Fetches a given logs property value
- Description: Return the value for an app's log property
- Invoked by:
- Arguments: `$APP``$PROPERTY`
- Arguments: `$APP $KEY`
- Example:
```shell
@@ -990,7 +1083,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
### `network-get-property`
- Description: Return the network value for an app's property
- Description: Return the value for an app's network property
> Warning: The arguments INTERNAL_PORT and INTERNAL_IP_ADDRESS are no longer sufficient to retrieve all app listeners. Please run `plugn trigger network-get-listeners APP` within any implementation of `nginx-pre-reload` in order to retrieve all application listeners.
> Warning: Deprecated, please use `post-release-builder` instead
> 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)`
> Warning: Deprecated, please use `post-release-builder` instead
> 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)`
@@ -9,11 +9,11 @@ We maintain the Dokku test harness within the `tests` directory:
## Continuous Integration
All pull requests have tests run against them on [GitHub Actions](https://github.com/features/actions), a continuous integration platform that provides Docker support for Ubuntu Trusty 18.04.
All pull requests have tests run against them on [GitHub Actions](https://github.com/features/actions), a continuous integration platform that provides Docker support for Ubuntu Focal 20.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.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Trusty 18.04, we only provide official installation support for that platform and the latest LTS release of Ubuntu (currently 20.04).
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Focal 20.04, we only provide official installation support for that platform and the latest LTS release of Ubuntu (currently 20.04).
The bootstrap script allows the Dokku repository URL to be overridden to bootstrap a host from your own clone of Dokku using the `DOKKU_REPO` environment variable. Example:
The above command will start a new docker container that is ready when a message similar to `Runit started as PID 12345` appears.
@@ -40,6 +41,8 @@ Other docker container options can also be used when running Dokku, though the s
## Plugin Installation
### On Dokku start
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:
The alternative is to build a custom docker image via a custom Dockerfile. This Dockerfile can run any `plugin:install` command. Note that the version installed at that time will be the one that persists. Below is an example Dockerfile showing this method.
```Dockerfile
FROMdokku/dokku:0.30.4
RUN dokku plugin:install https://github.com/dokku/dokku-postgres.git postgres
RUN dokku plugin:install https://github.com/dokku/dokku-redis.git redis
```
## SSH Key Management
To initialize ssh-keys within the container, use `docker exec` to enter the container and run the appropriate ssh-keys commands.
> For users that have customized the IP address of their VM - either in a custom `Vagrantfile` or via the `DOKKU_IP` environment variable - and are not using `10.0.0.2` for the Vagrant IP, you'll need to instead use the output of `vagrant ssh-config dokku` for your `~/.ssh/config` entry.
6. Connect to the server and add your ssh key to the install. Additionally, set the global domain name to `dokku.me`.
6. Connect to the server via `vagrant ssh` and add your ssh key to the install. Additionally, set the global domain name to `dokku.me`.
```shell
# usually your key is already available under the current user's `~/.ssh/authorized_keys` file
@@ -167,7 +167,11 @@ When specifying your port you may want to use something similar to:
varport=process.env.PORT||3000
```
Please see https://github.com/dokku/dokku/issues/282.
Please see [#282](https://github.com/dokku/dokku/issues/282).
Additionally, your application should listen/bind to all interfaces (`0.0.0.0`). Many frameworks default to listening on `127.0.0.1`.
Please see [#5798](https://github.com/dokku/dokku/issues/5798).
### Deployment fails because of slow internet connection, messages shows `gzip: stdin: unexpected end of file`.
@@ -241,3 +245,22 @@ This could be a result of a bad proxy configuration (`http:5000:5000` may be inc
```
Set `dokku proxy:ports-set front http:80:5000` to get proxy correctly configured for http endpoint.
### I deployed a new app but now subdomains are miss-routed
Sometimes nginx does something funky and cant actually reload for whatever reason.
```bash
# Validate the configuration
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo service nginx restart
# Re-enable Letsencrypt
```
Example: existing AppA (https) and AppB(https), deployed NEW (non-https) then noticed right away NEW's subdomain showed AppB's content and cert but under its own subdomain (cert miss-match of course). AppB still works. AppA also changed to show AppB content and cert.. Other apps were unaffected.
Consider caddy and traefik support via docker containers if this continues to be an issue.
<gid="mysql"data-bs-toggle="svg-tooltip"data-bs-placement="bottom"title="MySQL"filter="url(#filter9_d_55_77)"transform="translate(79.2566,394.257) translate(-79.2566,-394.257)"style="animation: 30s linear infinite both mysql_t;">
In some cases, it may be necessary to route an app to an existing `$IP:$PORT` combination. This is particularly the case for internal admin tools or services that aren't run by Dokku but have a web ui that would benefit from being exposed by Dokku. This can be done by setting a value for `static-web-lister` and running a few other commands when creating an app.
In some cases, it may be necessary to route an app to an existing `$IP:$PORT` combination. This is particularly the case for internal admin tools or services that aren't run by Dokku but have a web ui that would benefit from being exposed by Dokku. This can be done by using a proxy application and routing requests through that.
```shell
# for a service listening on:
@@ -137,25 +135,23 @@ In some cases, it may be necessary to route an app to an existing `$IP:$PORT` co
# create the app
dokku apps:create local-app
# set the builder to the null builder, which does nothing
dokku builder:set local-app selected null
# add an extra host that maps host.docker.internal to the docker gateway
Only a single `$IP:$PORT` combination can be routed to for a given app, and that `$IP:$PORT` combination _must_ be accessible to the proxy, or requests to the app may not resolve.
Only a single `$IP:$PORT` combination can be routed to for a given app, and that `$IP:$PORT` combination _must_ be accessible to the service proxy on initial deploy, or the service proxy won't start.
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:
> Note: This feature is only available when an app has been attached to a network other than the default `bridge` network.
When a container created for a deployment is being attached to a network - regardless of which network 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
@@ -262,27 +260,27 @@ Containers can be attached to a network for a variety of reasons:
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.
- 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.
- 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.
-`initial-network`:
- 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`
- Use case: When another container on the network is already running and needed by this container.
- Example: A key-value store exposing itself to all your apps may be on the `initial-network`.
- 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`
- Use case: When another container on the network is already running and needed by this container.
- Example: A key-value store exposing itself to all your apps may be on the `initial-network`.
> Warning: If the attachment fails during the `running` container state, this may result in your application failing to respond to proxied requests once older containers are removed.
@@ -138,7 +138,7 @@ For buildpack deployments, your application _must_ respect the `PORT` environmen
> Changed as of 0.5.0
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/networking/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` and manually exposing the ports via the `docker-options` plugin. For example, `dokku docker-options:add myapp deploy "-p 2456:2456/udp'`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/networking/proxy-management.md).
#### Applications using EXPOSE
@@ -147,7 +147,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:
@@ -15,7 +15,7 @@ caddy:stop # Stops the caddy server
## Requirements
Using the `caddy` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/compose-plugin/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
Using the `caddy` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
Dokku provides integration with the [Haproxy](http://www.haproxy.org) proxy service by utilizing the Docker label-based integration implemented by [EasyHaproxy](https://github.com/byjg/docker-easy-haproxy).
```
haproxy:report [<app>] [<flag>] # Displays a haproxy report for one or more apps
Using the `caddy` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
## Usage
> Warning: As using multiple proxy plugins on a single Dokku installation can lead to issues routing requests to apps, doing so should be avoided. As the default proxy implementation is nginx, users are encouraged to stop the nginx service before switching to Haproxy.
The Haproxy plugin has specific rules for routing requests:
- Haproxy integration is exposed via docker labels attached to containers. Changes in labels require either app deploys or rebuilds.
- While Haproxy will respect labels associated with other containers, only `web` containers have Haproxy labels injected by the plugin.
- Only `http:80` and `https:443` port mappings are supported at this time.
- Requests are routed as soon as the container is running and passing healthchecks.
### Switching to Haproxy
To use the Haproxy plugin, use the `proxy:set` command for the app in question:
```shell
dokku proxy:set node-js-app haproxy
```
This will enable the docker label-based Haproxy integration. All future deploys will inject the correct labels for Haproxy to read and route requests to containers. Due to the docker label-based integration used by Haproxy, a single deploy or rebuild will be required before requests will route successfully.
```shell
dokku ps:rebuild node-js-app
```
Any changes to domains or port mappings will also require either a deploy or rebuild.
### Starting Haproxy container
Haproxy can be started via the `haproxy:start` command. This will start a Haproxy container via the `docker compose up` command.
```shell
dokku haproxy:start
```
### Stopping the Haproxy container
Haproxy may be stopped via the `haproxy:stop` command.
```shell
dokku haproxy:stop
```
The Haproxy container will be stopped and removed from the system. If the container is not running, this command will do nothing.
### Showing the Haproxy compose config
For debugging purposes, it may be useful to show the Haproxy compose config. This can be achieved via the `haproxy:show-config` command.
```shell
dokku haproxy:show-config
```
### Customizing the Haproxy container image
While the default Haproxy image is hardcoded, users may specify an alternative by setting the `image` property with the `--global` flag:
It may be necessary to check the Haproxy container's logs to ensure that Haproxy is operating as expected. This can be performed with the `haproxy:logs` command.
```shell
dokku haproxy:logs
```
This command also supports the following modifiers:
```shell
--num NUM # the number of lines to display
--tail # continually stream logs
```
You can use these modifiers as follows:
```shell
dokku haproxy:logs --tail --num 10
```
The above command will show logs continually from the vector container, with an initial history of 10 log lines
### Changing the Haproxy log level
Haproxy log output is set to `ERROR` by default. It may be changed by setting the `log-level` property with the `--global` flag:
```shell
dokku haproxy:set --global log-level DEBUG
```
After modifying, the Haproxy container will need to be restarted.
### SSL Configuration
The haproxy plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
#### Enabling letsencrypt integration
By default, letsencrypt is disabled and https port mappings are ignored. To enable, set the `letsencrypt-email` property with the `--global` flag:
After enabling, the Haproxy container will need to be restarted and apps will need to be rebuilt. All http requests will then be redirected to https.
#### Customizing the letsencrypt server
The letsencrypt integration is set to the production letsencrypt server by default. To change this, set the `letsencrypt-server` property with the `--global` flag:
@@ -23,6 +23,8 @@ By default, the `web` process is the only process proxied by the nginx proxy imp
Nginx will proxy the requests in a [round-robin balancing fashion](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream) to the different deployed (scaled) containers running the `web` proctype. This way, the host's resources can be fully leveraged for single-threaded applications (e.g. `dokku ps:scale node-js-app web=4` on a 4-core machine).
> Note: Due to how the plugin is implemented, if an app successfully starts up `web` containers but fails to deploy some other containers, nginx may eventually stop routing requests. Users should revert their code in these cases, or manually trigger `dokku proxy:build-config $APP` in order to ensure requests route to the new web containers.
### Starting nginx
> New as of 0.28.0
@@ -31,7 +33,7 @@ The nginx server can be started via `nginx:start`.
```shell
dokku nginx:start
````
```
### Stopping nginx
@@ -41,12 +43,14 @@ The nginx server can be stopped via `nginx:stop`.
```shell
dokku nginx:stop
````
```
### Binding to specific addresses
> New as of 0.19.2
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
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.
```shell
@@ -69,6 +73,8 @@ Users with apps that contain a custom `nginx.conf.sigil` file will need to modif
> New as of 0.20.0
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
If SSL certificates are present, HSTS will be automatically enabled. It can be toggled via `nginx:set`:
```shell
@@ -87,7 +93,9 @@ Beware that if you enable the header and a subsequent deploy of your application
#### Globally disabling the HSTS Header
HSTS Header can be disabled for all apps by setting the `hsts` property to false after passing the `--global` flag to `nginx:set`. Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
HSTS Header can be disabled for all apps by setting the `hsts` property to false after passing the `--global` flag to `nginx:set`.
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
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`.
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
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:
```shell
@@ -217,6 +233,8 @@ In all cases, the nginx config must be regenerated after setting the above value
> New as of 0.23.0
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
Users can override the default `client_max_body_size` value - which limits file uploads - via `nginx:set`. Changing this value will only apply to every `server` stanza of the default `nginx.conf.sigil`; users of custom `nginx.conf.sigil` files must update their templates to support the new value.
Dokku uses a templating library by the name of [sigil](https://github.com/gliderlabs/sigil) to generate nginx configuration for each app. You may also provide a custom template for your application as follows:
Dokku uses a templating library by the name of [sigil](https://github.com/gliderlabs/sigil) to generate nginx configuration for each app. This may be overriden by committing the [default configuration template](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/nginx.conf.sigil) to a file named `nginx.conf.sigil` in the root of the app repository.
- 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.
- 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 deploying a monorepo, it may be desirable to specify the specific path of the `nginx.conf.sigil` file to use for a given app. This can be done via the `nginx:set` command. If a value is specified and that file does not exist in the app's build directory, Dokku will continue the build process as if the repository has no`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`.
> The default template is available [here](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/nginx.conf.sigil), and can be used as a guide for your own, custom `nginx.conf.sigil` file. Please refer to the appropriate template file version for your Dokku version.
This property can also be changed globally, which will take into effect if there is no value at the app level.
In either case, the value can be reset by specifying an empty value.
```shell
dokku nginx:set node-js-app nginx-conf-sigil-path
dokku nginx:set --global nginx-conf-sigil-path
```
> The [default template](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/nginx.conf.sigil) may change with new releases of Dokku. Please refer to the appropriate template file version for your Dokku version, and make sure to look out for changes when you upgrade.
#### Disabling custom nginx config
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
While enabled by default, using a custom nginx config can be disabled via `nginx:set`. This may be useful in cases where you do not want to allow users to override any higher-level customization of app nginx config.
@@ -364,7 +397,17 @@ These are provided as an alternative to the generic Nginx error page, are shared
### 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.
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. This means that accessing the dokku server via its IP address or a bogus domain name may return a seemingly random website.
> Warning: some versions of Nginx may create a default site when installed. This site is simply a static page which says "Welcome to Nginx", and if this default site is enabled, Nginx will not route any requests with an unknown HOST header to Dokku. If you want Dokku to receive all requests, run the following commands:
>
> ```
> rm /etc/nginx/sites-enabled/default
> dokku nginx:stop
> dokku nginx:start
> ```
If services should only be accessed via their domain name, you may want to disable the default site by adding the following configuration to the global nginx configuration.
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
@@ -373,34 +416,28 @@ server {
listen80default_server;
listen[::]:80default_server;
# If services hosted by dokku are available via HTTPS, it is recommended
# to also uncomment the following section.
#
# Please note that in order to let this work, you need an SSL certificate. However
# it does not need to be valid. Users of Debian-based distributions can install the
# `ssl-cert` package with `sudo apt install ssl-cert` to automatically generate
# a self-signed certificate that is stored at `/etc/ssl/certs/ssl-cert-snakeoil.pem`.
# 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`.
Make sure to reload nginx after creating this file by running `systemctl reload nginx.service`.
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).
This will catch all unknown HOST header values and close the connection without responding. You can replace the `return 444;` with `return 410;` which will cause nginx to respond with an error page.
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.
@@ -15,7 +15,7 @@ traefik:stop # Stops the traefik server
## Requirements
Using the `traefik` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/compose-plugin/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
Using the `traefik` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
## Usage
@@ -112,7 +112,17 @@ Traefik log output is set to `ERROR` by default. It may be changed by setting th
dokku traefik:set --global log-level DEBUG
```
After modifying, the Traefik container will need to be restarted.
After modifying, the Traefik container will need to be restarted.
### Setting rule priority
By default, app deployments will result in the newer traefik rules using a higher priority in order to have any newer rules respected by Traefik. Rule priorities will always increase according to the current unix timestamp. The priority may be fixed by setting the app-level `priority` property:
```shell
dokku traefik:set node-js-app priority 12345
```
After modifying, the app container will need to be recreated via a `ps:rebuild` or an app deployment.
run [-e|--env KEY=VALUE] [--no-tty] <app> <cmd> # Run a command in a new container using the current app image
run:detached [-e|-env KEY=VALUE] [--no-tty] <app> <cmd> # Run a command in a new detached container using the current app image
run:list [<app>] # List all run containers for an app
run [-e|--env KEY=VALUE] [--no-tty] <app> <cmd> # Run a command in a new container using the current app image
run:detached [-e|-env KEY=VALUE] [--no-tty] <app> <cmd> # Run a command in a new detached container using the current app image
run:list [--format json|stdout] [<app>] # List all run containers for an app
run:logs <app|--container CONTAINER> [-h] [-t] [-n num] [-q] # Display recent log output for run containers
run:stop <app|--container CONTAINER> # Stops all run containers for an app or a specified run container
```
Sometimes it is necessary to run a one-off command under an app. Dokku makes it easy to run a fresh container via the `run` command.
@@ -68,6 +70,35 @@ dokku run:detached node-js-app ls -lah
# returns the ID of the new container
```
### Displaying one-off container logs
You can easily get logs of all one-off containers for an app using the `logs` command:
```shell
dokku run:logs node-js-app
```
Logs are pulled via integration with the scheduler for the specified application via "live tailing". As such, logs from previously running deployments are usually not available. Users that desire to see logs from previous deployments for debugging purposes should persist those logs to external services. Please see Dokku's [vector integration](/docs/deployment/logs.md#vector-logging-shipping) for more information on how to persist logs across deployments to ship logs to another service or a third-party platform.
#### Behavioral modifiers
Dokku also supports certain command-line arguments that augment the `run:log` command's behavior.
```
--container NAME # the name of a specific container to show logs for
-n, --num NUM # the number of lines to display
-t, --tail # continually stream logs
-q, --quiet # display raw logs without colors, time and names
@@ -43,7 +43,6 @@ When running scheduled cron tasks, there are a few items to be aware of:
- Schedules are performed on the hosting server's timezone, which is typically UTC.
- At this time, only the `PATH` and `SHELL` environment variables are specified in the cron template.
- Each scheduled task is executed within a one-off `run` container, and thus inherit any docker-options specified for `run` containers.Resources are never shared between scheduled tasks.
- Tasks are always executed using the `--rm` flag, and are never executed in detached mode.
- Scheduled cron tasks are supported on a per-scheduler basis, and are currently only implemented by the `docker-local` scheduler.
- Tasks for _all_ apps managed by the `docker-local` scheduler are written to a single crontab file owned by the `dokku` user. The `dokku` user's crontab should be considered reserved for this purpose.
@@ -106,8 +105,7 @@ Some installations may require more fine-grained control over cron usage. The fo
You can always use a one-off container to run an app task:
```shell
dokku --rm run node-js-app some-command
dokku --rm-container run node-js-app some-command
dokku run node-js-app some-command
```
For tasks that should not be interrupted, run is the _preferred_ method of handling cron tasks, as the container will continue running even during a deploy or scaling event. The trade-off is that there will be an increase in memory usage if there are multiple concurrent tasks running.
@@ -183,7 +181,7 @@ SHELL=/bin/bash
### PLACE ALL CRON TASKS BELOW
# removes unresponsive users from the subscriber list to decrease bounce rates
declare desc="reports dokku vitals for troubleshooting"
declare cmd="url"
declare APP="$2"
declare URL_TYPE="$1" APP="$2"
verify_app_name "$APP"
get_app_urls "$@"
plugn trigger domains-urls "$APP" "$URL_TYPE"
}
cmd-urls "$@"
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.