# History
## 0.31.0
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.31.0/bootstrap.sh
sudo DOKKU_TAG=v0.31.0 bash bootstrap.sh
```
See the [0.31.0 migration guide](/docs/appendices/0.31.0-migration-guide.md) for more information on migrating to 0.31.0.
### Backwards Compatibility Breaks
- #6102: @josegonzalez Deprecate ARM as a build target
- #6029: @josegonzalez Provide users the ability to override auto-detected port mappings
### Bug Fixes
- #6110: @josegonzalez Correctly handle rebase when generating release notes for minor/major releases
- #6081: @josegonzalez Use correct namespace for haproxy service state tracking
- #6079: @josegonzalez Remove debugging code from builder-dockerfile plugin
- #6078: @josegonzalez Use correct quoting in format template when fetching exposed image ports
- #6070: @josegonzalez Do not write empty values for nginx container labels
- #6014: @josegonzalez Automatically clear the git source-image property when changing deployment methodologies
- #5985: @josegonzalez Mount the traefik data directory instead of the acme.json file when starting traefik
- #5979: @josegonzalez Do not start proxy implementations during server restore if they weren't manually started via the :start command
- #5973: @josegonzalez Remove all containers and images by label on app destroy
### New Features
- #6100: @josegonzalez Add support for non-web healthchecks via app.json
- #6098: @josegonzalez Upgrade traefik image from v2.8 to v2.10
- #6097: @josegonzalez Upgrade caddy image from 2.7 to 2.8
- #6082: @josegonzalez Add openresty proxy implementation
- #6057: @josegonzalez Inject docker labels when nginx proxy implementation is in use
- #6043: @josegonzalez Write auto-detected port mappings during a deploy
- #6013: @josegonzalez Export environment variables during dockerfile builds for use with value-less --build-arg flags
- #6007: @Firfi Add application/wasm to nginx.conf.sigil gzip
- #5993: @josegonzalez Un-deprecate apps and config cli aliases
- #5992: @josegonzalez Mount the vector data directory instead of the vector file
- #5991: @josegonzalez Add the ability to execute a cron task on the fly
- #5990: @josegonzalez Add json format output to cron:list command
- #5989: @josegonzalez Skip scaled processes that are missing in the Procfile
- #5978: @josegonzalez Export environment variables during dockerfile builds for use with value-less --build-arg flags
- #5908: @josegonzalez Generate jobs for crontab in parallel
- #5891: @josegonzalez Add support for specifying multiple networks on a given app
### Refactors
- #6042: @josegonzalez Rename port-map property to port
- #6021: @josegonzalez Simplify ports-configure codebase
- #6018: @josegonzalez Move code that fetches raw tcp ports for dockerfile deploys to ports plugin
- #6017: @josegonzalez Deprecate proxy-configure-ports plugin trigger in favor of ports-configure
- #6011: @josegonzalez Use ports-get plugn trigger for fetching port mappings
- #6010: @josegonzalez Use ports-clear plugn trigger to manage clearing the port map
- #5988: @josegonzalez Move crontab writing code to scheduler-docker-local plugin
- #5975: @josegonzalez Standardize on shorthand for redirecting all output to /dev/null
- #5974: @josegonzalez Standardize on ls subcommand when interacting with the docker binary
### Documentation
- #6116: @josegonzalez Remove extra newline in migration docs
- #6099: @josegonzalez Clean up references in proxy plugins
- #5987: @josegonzalez Clarify that a branch can be specified when updating a plugin
### Tests
- #6103: @josegonzalez Timeout docker image builds in CI
- #6101: @josegonzalez Make it possible to specify an alternative base domain for tests
- #6095: @josegonzalez Remove assertion for unconsumed build arguments
- #6094: @josegonzalez Correct assertion for dockerfile builds when a variable is eval'd
- #6080: @josegonzalez Add assertions to various bats tests
- #6076: @josegonzalez Use assert_output_not_exists instead of asserting output is empty string
- #6075: @josegonzalez Use an alternative curl request to ensure requests go to the local nginx
- #6074: @josegonzalez Fix issue where networks weren't being torn down during testing
- #6012: @josegonzalez Use ports:report to get the list of port mappings
- #5977: @josegonzalez Move all shellcheck disable definitions to .shellcheckrc
- #5976: @josegonzalez Remove Stickler configuration
### Other
- #6109: @josegonzalez Make heroku-22/jammy the default stack for cnb/herokuish builds
- #6096: @josegonzalez Upgrade vector image from 0.23.x to 0.31.x
- #6019: @josegonzalez Move code for fetching an available port to the ports plugin
- #6015: @josegonzalez Move CHECKS file extraction to the beginning of the deploy
- #5995: @josegonzalez Migrate the proxy port map from config variable to property system
- #5986: @josegonzalez Move all port management code to standalone ports plugin
- #5495: @josegonzalez Move herokuish app cache from the filesystem into a docker volume
With the integration branch where pull requests are merged prior to a release, we require a rebase every so often to ensure there aren't any issues upon merging to master. Unfortunately, this breaks the link between the original PR and the integration PR, thus causing changelog generation to fail as it depended upon those - now removed - merge request commits.
With this change, we introduce usage of milestones in order to track what is getting merged into a release. Milestones are only used for major/minor releases, and all others will fall back to the default git log method.
ARM usually takes quite a while to build. If it takes more than ~15 minutes, then it is usually going to fail anyways, so timeout early.
AMD64 takes ~3 minutes, and ARM64 appears to take 15 minutes.
AMD64 and ARM64 continue to be supported, but ARM in CI is not currently supported and doesn't get local testing either, so deprecating it now and removing it in the future makes most sense for the project.
This change converts existing CHECKS files into a healthchecks key that is understood by 'docker-container-healthchecker'. This tool supports a number of different types of container healthchecks - command, http, uptime - and can perform healthchecks against non-web processes.
The use of the old CHECKS file is now deprecated, and will be removed in the next minor version. Users can use the 'docker-container-healthchecker' to convert existing CHECKS files to the new format automatically.
Closes#2760
This plugin is mostly compatible with the nginx plugin, but runs the proxy within a docker container. Users do not have direct access to add custom openresty configuration at this time, but instead receive the ability to setup automatic ssl on first request via letsencrypt integration.
When developing Dokku, it is useful to use a real domain to test actual functionality. This is impossible if the domain is hardcoded to dokku.me in testing.
Previously, we would always set the port mapping during a dockerfile build, making it difficult for users to override mappings. We also only _sometimes_ updated the detected port mapping, further confusing issues when users were migrating from Dockerfile to Buildpacks for builds.
Now, we always detect the port mapping during the build process, and only use that detected port mapping if an override is not specified. This greatly simplifies the experience around port mapping, as now a user can create an app, set a port mapping, and that first deploy will respect the port mapping without an additional deploy.
The builder always has the best context for what the app should be listening on, and thus we can always specify a "default" port mapping at this stage. Users can override this map as desired later.
This change also results in the removal of a ton of internal code that is now centralized in the ports plugin.
Closes#4067
Due to how the variable was assigned, there were cases where the network was specified twice with a := as a delimiter. This would result in no network being removed.
This will allow users to switch to a docker label-based nginx proxy server transparently without rebuilds (after the first one), which would mimic how the caddy, haproxy, and traefik proxy implementations work.
See https://github.com/dokku/nginx-docker-proxy for an example server implementation.
During an app build, we now auto-detect ports based on the source code. This is usually http:80:5000, with Dockerfile-based deploys having their ports extracted from the docker image or Dockerfile. Additionally, we add an https:443 mapping for any detected http:80 mapping when there is an ssl certificate, and all http port mappings are transformed to https mappings for Dockerfile-based deploys.
While the ports aren't currently consumed, a future refactor will provide the ability to fallback to the new detected ports when there is no user-specified port mapping.
This makes deploys faster for any that are built from source as the image artifact isn't involved in those cases while also unifying how the file is handled.
Refs #2760
Exposing all config values will allow users to skip setting environment variables twice - once as a docker option and once as an env var. Docker will automatically pull the value from the environment if none is set for the --build-arg flag.
Users will still be required to specify each desired env var via --build-arg as otherwise docker builds will complain about unused build arguments.
Re-implements #5978 (lost in a rebase)
Closes#5903
This ensures users don't have issues with cached state in regards to files pulled from the repo/image.
Also add missing docs for deploy-source-set trigger.
Closes#5963
This better follows Heroku's output and is more useful to users. The subcommands will be treated as the primary, documented versions, while the aliases are there for convenience.
Closes#5362
The implementation was very heavily docker-local specific and thus didn't make a ton of sense to keep in the cron plugin.
This also re-introduces changes from #5908 to parallelize the crontab generation (which is also specific to the docker-local scheduler) that were lost during a rebase.
The impetus for this change was implementing a `cron:run` command. The logic for actually running the command isn't scheduler specific - merely invoking `dokku run` with the appropriate arguments - but all the logic around how the commands were retrieved were, so the change was made pre-emptively.
This allows folks to deploy apps that don't have a web process without needing to scale that process down before/after the first deploy. Note that the formations key in the app.json or a manual scale of other processes will be necessary to start anything non-web.
Closes#5700
This change makes interacting with port mappings more clear - folks might previously set the port mapping to the proxy type or vice-versa.
The existing proxy:ports* commands still exist but will show a deprecation warning for a single minor release.
Without this change, Docker - at least on arm64 - appears to mount the file as 0755 instead of 0600. We can trick docker by mounting the folder and then referencing _that_ instead.
This change ensures users don't have unnecessary proxies starting on their servers and potentially have apps not routing correctly due to another proxy squatting on a port.
Closes#5846
The shorthand is more prevalent in this codebase, and is something that bash supports, so we should just use the same thing everywhere.
Note that we do not use shorthand redirect in Makefile as shell parsing is a bit different in Make and the shorthand redirect doesn't seem to be properly supported, causing CI errors.
This makes standard use of shellcheck work without needing to provide extra configuration anywhere.
Also remove use of inline 'shellcheck disable' calls that are already defined in the .shellcheckrc and don't need to be set inline.
Previously, we would filter containers and images by name, which could be fail if the app was renamed or no longer was tagged "correctly" due to a rebuild. Now, we filter by label, ensuring an app is completely cleaned up on deletion.
Also:
- Move docker image cleanup from apps plugin to builder plugin: This isn't where it belongs - images should be cleaned up in a builder plugin (or the builders plugin) and not in the apps plugin, which has nothing to do with docker images anyways.
- Remove the code from the scheduler plugin, as that will only do anything if the scheduler is enabled for the app.
- Bypass image removal if there are no images to remove
- Always delete app containers: The herokuish builder creates intermediate build containers - something that should be refactored - and ideally this gets run in that builder plugin, but keeping the logic here ensures we don't have code duplication. This is otherwise safe as it will be a no-op if there are no containers to clean up.
Stickler-CI was shutdown in May 2023 - https://stickler-ci.com/shutting-down - and thus we no longer need configuration for it.
So long, and thanks for all the fish :)
# History
## 0.30.11
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.11/bootstrap.sh
sudo DOKKU_TAG=v0.30.11 bash bootstrap.sh
```
### Dependencies
- #6091: @dependabot[bot] chore(deps): bump mkdocs from 1.5.1 to 1.5.2 in /docs/_build
- #6093: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.5.1 to 37.5.2
- #6088: @dependabot[bot] chore(deps): bump golang from 1.20.6 to 1.20.7 in /tests/apps/gogrpc
- #6087: @dependabot[bot] chore(deps): bump golang from 1.20.6 to 1.20.7 in /tests/apps/zombies-dockerfile-no-tini
- #6086: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.12.0 to 0.13.0 in /tests/apps/gogrpc
- #6085: @dependabot[bot] chore(deps): bump golang from 1.20.6 to 1.20.7 in /tests/apps/go-fail-postdeploy
- #6084: @dependabot[bot] chore(deps): bump golang from 1.20.6 to 1.20.7 in /tests/apps/go-fail-predeploy
- #6083: @dependabot[bot] chore(deps): bump golang from 1.20.6 to 1.20.7 in /tests/apps/zombies-dockerfile-tini
- #6072: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.5.0 to 37.5.1
- #6073: @dependabot[bot] chore(deps): bump pyparsing from 3.1.0 to 3.1.1 in /docs/_build
# History
## 0.30.10
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.10/bootstrap.sh
sudo DOKKU_TAG=v0.30.10 bash bootstrap.sh
```
### Bug Fixes
- #6036: @l3x4 Remove auth middleware from traefik compose setup when basic auth is not enabled
- #6041: @josegonzalez Use updated path for devcontainer vscode extensions
- #6022: @iphoting Fix issue with docker plugin-list install failing boot for docker-based installations
- #6028: @josegonzalez Detect and use systemd on Debian systems when interacting with nginx
### Documentation
- #6068: @nickgal Fix typo in port management docs
- #6063: @PabloCastellano Fix typo in nginx docs
### Tests
- #6035: @iphoting Allow the check-commit CI job to work with PRs from other repos
### Dependencies
- #6065: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.19 to 9.1.21 in /docs/_build
- #6064: @dependabot[bot] chore(deps): bump mkdocs from 1.4.3 to 1.5.1 in /docs/_build
- #6059: @josegonzalez Update go packages to fix build issues
- #6058: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.4.0 to 37.5.0
- #6053: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.3.0 to 37.4.0
- #6049: @dependabot[bot] chore(deps): bump gunicorn from 21.1.0 to 21.2.0 in /tests/apps/multi
- #6050: @dependabot[bot] chore(deps): bump click from 8.1.5 to 8.1.6 in /docs/_build
- #6051: @dependabot[bot] chore(deps): bump gunicorn from 21.1.0 to 21.2.0 in /tests/apps/python-flask
- #6052: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.1.2 to 37.3.0
- #6048: @dependabot[bot] chore(deps): bump pyyaml from 6.0 to 6.0.1 in /docs/_build
- #6047: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.18 to 9.1.19 in /docs/_build
- #6046: @dependabot[bot] chore(deps): bump gunicorn from 20.1.0 to 21.1.0 in /tests/apps/python-flask
- #6045: @dependabot[bot] chore(deps): bump gunicorn from 20.1.0 to 21.1.0 in /tests/apps/multi
- #6044: @dependabot[bot] chore(deps): bump zipp from 3.16.1 to 3.16.2 in /docs/_build
- #6038: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.0.1 to 10.1 in /docs/_build
- #6039: @dependabot[bot] chore(deps): bump click from 8.1.4 to 8.1.5 in /docs/_build
- #6040: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.1.1 to 37.1.2
- #6037: @dependabot[bot] chore(deps): bump zipp from 3.16.0 to 3.16.1 in /docs/_build
- #6034: @dependabot[bot] chore(deps): bump golang from 1.20.5 to 1.20.6 in /tests/apps/zombies-dockerfile-tini
- #6032: @dependabot[bot] chore(deps): bump golang from 1.20.5 to 1.20.6 in /tests/apps/zombies-dockerfile-no-tini
- #6033: @dependabot[bot] chore(deps): bump golang from 1.20.5 to 1.20.6 in /tests/apps/gogrpc
- #6031: @dependabot[bot] chore(deps): bump golang from 1.20.5 to 1.20.6 in /tests/apps/go-fail-postdeploy
- #6030: @dependabot[bot] chore(deps): bump golang from 1.20.5 to 1.20.6 in /tests/apps/go-fail-predeploy
- #6027: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.1.0 to 37.1.1
- #6024: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.0.5 to 37.1.0
- #6026: @dependabot[bot] chore(deps): bump importlib-metadata from 6.7.0 to 6.8.0 in /docs/_build
- #6025: @dependabot[bot] chore(deps): bump zipp from 3.15.0 to 3.16.0 in /docs/_build
### Other
- #6056: @Coffee2CodeNL Add debian bookworm to release and bootstrap script
# History
## 0.30.9
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.9/bootstrap.sh
sudo DOKKU_TAG=v0.30.9 bash bootstrap.sh
```
### Bug Fixes
- #6009: @josegonzalez Properly set the plugin repository name when installing in a docker-based dokku install
- #5999: @caplod Fix http to https redirect in traefik
### Documentation
- #6006: @josegonzalez Clarify how to specify the contents of an ssh key for dokku
- #5998: @kleutzinger Fix typo in scheduled cron task documentation
- #5984: @josegonzalez Unify all Procfile-handling documentation under the process management docs
- #5982: @josegonzalez Update docs to mention that files are extracted from source where source code is available
### Dependencies
- #6008: @dependabot[bot] chore(deps): bump click from 8.1.3 to 8.1.4 in /docs/_build
- #6003: @dependabot[bot] chore(deps): bump django from 4.1.9 to 4.1.10 in /tests/apps/dockerfile-release
- #6005: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.11.0 to 0.12.0 in /tests/apps/gogrpc
- #6000: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.17 to 9.1.18 in /docs/_build
Recent Dokku changes invalidate a bunch of docs around where files need to be placed in order for Dokku to respect them. This doc change clarifies where files are extracted from in cases where source code is available, which should hopefully make users less confused about how the system works.
See https://railsnotes.xyz/blog/deploying-ruby-on-rails-with-dokku-redis-sidekiq-arm-docker-hetzner for the inspiration - I was reading through it and was like 'these docs are definitely incorrect...'.
# History
## 0.30.8
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.8/bootstrap.sh
sudo DOKKU_TAG=v0.30.8 bash bootstrap.sh
```
### Bug Fixes
- #5941: @josegonzalez Use github token to avoid rate limiting during packer init
- #5930: @michaelmulley Fix issue with docker plugin-list install failing boot for docker-based installations
### New Features
- #5962: @jaytula Add Debian 12 support to the bootstrap install script
- #5926: @josegonzalez Update default herokuish version to 0.6.0
### Documentation
- #5943: @josegonzalez Add a note for each network type mentioning when they are best used
- #5938: @josegonzalez Add build-base to ensure gcc is available
- #5927: @aradalvand Improve docs about `X-Forwarded-*` headers and move it to nginx.md
- #5921: @aradalvand Update dockerfiles.md to mention that BuildKit is the default builder from Docker v24 onwards
- #5923: @aradalvand Remove `:master` from `git push` commands in the documentation
### Tests
- #5972: @josegonzalez Add permissions to allow publishing test results for pull requests
- #5944: @josegonzalez Add the ability to skip ci when commit message includes a ci skip message or are docs related
### Dependencies
- #5971: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.0.4 to 37.0.5
- #5967: @dependabot[bot] chore(deps): bump socket.io from 4.6.2 to 4.7.1 in /tests/apps/.websocket.disabled
- #5968: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 37.0.3 to 37.0.4
- #5966: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.16 to 9.1.17 in /docs/_build
- #5965: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.4.1 to 37.0.3
- #5957: @josegonzalez chore: update go packages to fix build issues
- #5956: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.4.0 to 36.4.1
- #5949: @dependabot[bot] chore(deps): bump github.com/otiai10/copy from 1.11.0 to 1.12.0 in /plugins/builder
- #5951: @dependabot[bot] chore(deps): bump github.com/otiai10/copy from 1.11.0 to 1.12.0 in /plugins/ps
- #5952: @dependabot[bot] chore(deps): bump github.com/otiai10/copy from 1.11.0 to 1.12.0 in /plugins/common
- #5953: @dependabot[bot] chore(deps): bump github.com/otiai10/copy from 1.11.0 to 1.12.0 in /plugins/app-json
- #5948: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.3.0 to 36.4.0
- #5950: @dependabot[bot] chore(deps): bump importlib-metadata from 6.6.0 to 6.7.0 in /docs/_build
- #5954: @dependabot[bot] chore(deps): bump pyparsing from 3.0.9 to 3.1.0 in /docs/_build
- #5946: @josegonzalez Update to actions/checkout@v3
- #5940: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.15 to 9.1.16 in /docs/_build
- #5939: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.2.1 to 36.3.0
- #5937: @josegonzalez chore: update go packages to fix build issues
- #5934: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.2.0 to 0.3.0 in /plugins/app-json
- #5933: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.1.0 to 36.2.1
- #5935: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.2.0 to 0.3.0 in /plugins/common
- #5928: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.10.0 to 0.11.0 in /tests/apps/gogrpc
- #5922: @dependabot[bot] chore(deps): bump werkzeug from 2.3.5 to 2.3.6 in /tests/apps/python-flask
- #5919: @dependabot[bot] chore(deps): bump python from 3.11.3-buster to 3.11.4-buster in /tests/apps/dockerfile-release
- #5913: @dependabot[bot] chore(deps): bump golang from 1.20.4 to 1.20.5 in /tests/apps/go-fail-predeploy
- #5915: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.27.7 to 1.27.8 in /plugins/config
- #5916: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.27.7 to 1.27.8 in /plugins/common
- #5917: @dependabot[bot] chore(deps): bump werkzeug from 2.3.4 to 2.3.5 in /tests/apps/python-flask
- #5918: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.0.18 to 36.1.0
- #5920: @dependabot[bot] chore(deps): bump python from 3.11.3-alpine to 3.11.4-alpine in /docs/_build
- #5914: @dependabot[bot] chore(deps): bump golang from 1.20.4 to 1.20.5 in /tests/apps/zombies-dockerfile-no-tini
- #5912: @dependabot[bot] chore(deps): bump golang from 1.20.4 to 1.20.5 in /tests/apps/go-fail-postdeploy
- #5911: @dependabot[bot] chore(deps): bump golang from 1.20.4 to 1.20.5 in /tests/apps/gogrpc
- #5910: @dependabot[bot] chore(deps): bump golang from 1.20.4 to 1.20.5 in /tests/apps/zombies-dockerfile-tini
- #5909: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.0.17 to 36.0.18
- #5906: @dependabot[bot] chore(deps): bump markupsafe from 2.1.2 to 2.1.3 in /docs/_build
- #5907: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.0.15 to 36.0.17
### Other
- #5945: @josegonzalez tests: split out image building into it's own job to speed up ci
- #5942: @josegonzalez Move the times function to functions.go
Previously, we would build the dokku package and install it in the same step. While the package building was relatively quick, because of our multi-architecture support, we would end up spending a large amount of time waiting for arm/arm64 images to build.
This change splits those builds out, allowing unit tests to start much quicker and each platform to be tested in parallel.
When upgrading from an older install of Dokku with the old community registry plugin, newlines could be available in the properties set on disk. Trim them so any usage of the properties continues to work as expected by users.
# History
## 0.30.6
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.6/bootstrap.sh
sudo DOKKU_TAG=v0.30.6 bash bootstrap.sh
```
### Bug Fixes
- #5889: @josegonzalez Respect dashboard disabling properties in traefik
- #5890: @josegonzalez Add missing report triggers and omitted proxy functionality
- #5757: @josegonzalez Ensure users can push from an image-deploy repository and respect deploy-branch
### New Features
- #5873: @josegonzalez Add dependabot to all plugin dependencies
### Dependencies
- #5877: @dependabot[bot] chore(deps): bump github.com/multiformats/go-base36 from 0.1.1-0.20220823151017-f5af2eed4d9c to 0.2.0 in /plugins/cron
- #5886: @josegonzalez chore: bump github.com/otiai10/copy from 1.9.0 to 1.11.0
- #5875: @dependabot[bot] chore(deps): bump github.com/gofrs/flock from 0.8.0 to 0.8.1 in /plugins/ps
- #5885: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 36.0.3 to 36.0.6
- #5871: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 35.9.2 to 36.0.3
### Other
- #5887: @josegonzalez chore: bump github.com/ryanuber/columnize from 1.1.2-0.20190319233515-9e6335e58db3 to 2.1.2+incompatible
- #5872: @Samuelodan Fix typo in upgrading docs
In the case where a repository is new, the check to see if it is an empty repo during clone fails. We therefore create the initial repo via the fn-git-create-hook call when initializing the repo.
Previously, we created this weird bare repo that didn't do set all the normal git config. This change switches to cloning the local temp directory, fixing the `receive.denyCurrentBranch` property that blocked pushing to this weird bare repo after calling git:from-image or git:from-archive.
Additionally, since we now use a git clone, we set the default branch correctly, ensuring git pushes later on that branch work as expected (and not on master if it was customized prior to app creation).
Closes#5601Closes#5662
# History
## 0.30.5
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.30.5/bootstrap.sh
sudo DOKKU_TAG=v0.30.5 bash bootstrap.sh
```
### New Features
- #5862: @edmorley Stop using the `latest` tag for the default `DOKKU_CNB_BUILDER`
### Documentation
- #5870: @josegonzalez Repair malformed code-block
- #5863: @joker234 Remove reference to ssh github clone from app deployment docs
### Tests
- #5867: @josegonzalez Update linuxserver image used in tests to one that is compatible with arm64
### Dependencies
- #5868: @josegonzalez Update all golang dependencies to fix go.0 tests
- #5856: @dependabot[bot] chore(deps): bump pymdown-extensions from 9.11 to 10.0.1 in /docs/_build
- #5865: @dependabot[bot] chore(deps): bump requests from 2.27.1 to 2.31.0 in /tests/apps/lambda-python
- #5864: @dependabot[bot] chore(deps): bump mkdocs-material from 9.1.12 to 9.1.14 in /docs/_build
- #5866: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.5.0 to 3.6.0 in /tests/apps/java
Previously the default value for `DOKKU_CNB_BUILDER` was `heroku/buildpacks`,
which for Docker is equivalent to `heroku/buildpacks:latest`.
The `latest` tag is about to be deleted (see heroku/builder#344), so this
switches the default value to `heroku/buildpacks:20` - which is what the
`latest` tag is currently as alias for.
Longer term, `DOKKU_CNB_BUILDER` should be switched to the non-deprecated
`heroku/builder:*` images, however, that's potentially a breaking change,
so is out of scope of this bug-fix PR.
For the list of available builders/tags, see:
https://github.com/heroku/builder#heroku-builder-imagesFixes#5861.
# 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
# SC1001 - This \/ will be a regular '/' in this context - https://github.com/koalaman/shellcheck/wiki/SC1001
# SC1003 - Want to escape a single quote? echo 'This is how it'\''s done' - https://github.com/koalaman/shellcheck/wiki/SC1003
# SC1090 - Can't follow non-constant source. Use a directive to specify location - https://github.com/koalaman/shellcheck/wiki/SC1090
# SC1091 - Not following: FILE: does not exist (No such file or directory) - https://github.com/koalaman/shellcheck/wiki/SC1091
# - used for sourcing function files throughout the codebase
# SC1117 - Backslash is literal in "\n". Prefer explicit escaping: "\\n" - https://github.com/koalaman/shellcheck/wiki/SC1117
# SC2029 - Note that, unescaped, this expands on the client side - https://github.com/koalaman/shellcheck/wiki/SC2029
# SC2030 - Modification of var is local (to subshell caused by pipeline). - https://github.com/koalaman/shellcheck/wiki/SC2030
# SC2031 - var was modified in a subshell. That change might be lost. - https://github.com/koalaman/shellcheck/wiki/SC2031
# SC2034 - VAR appears unused - https://github.com/koalaman/shellcheck/wiki/SC2034
# - used for declaring desc and deprecated function variables
# SC2046 - Quote this to prevent word splitting - https://github.com/koalaman/shellcheck/wiki/SC2046
# SC2064 - Use single quotes, otherwise this expands now rather than when signalled. - https://github.com/koalaman/shellcheck/wiki/SC2064
# - used for traps
# SC2068 - Double quote array expansions to avoid re-splitting elements - https://github.com/koalaman/shellcheck/wiki/SC2068
# SC2086 - Double quote to prevent globbing and word splitting - https://github.com/koalaman/shellcheck/wiki/SC2086
# SC2119 - Use 'function "$@"' if function's $1 should mean script's $1 - https://github.com/koalaman/shellcheck/wiki/SC2119
# SC2120 - Function references arguments, but none are ever passed - https://github.com/koalaman/shellcheck/wiki/SC2120
# SC2128 - Expanding an array without an index only gives the first element - https://github.com/koalaman/shellcheck/wiki/SC2128
# SC2148 - Tips depend on target shell and yours is unknown. Add a shebang - https://github.com/koalaman/shellcheck/wiki/SC2148
# SC2153 - Possible misspelling: DOKKU_ROOT may not be assigned, but DOKKU_PORT is - https://github.com/koalaman/shellcheck/wiki/SC2153
# SC2154 - Var is referenced but not assigned - https://github.com/koalaman/shellcheck/wiki/SC2154
# SC2155 - Declare and assign separately to avoid masking return values - https://github.com/koalaman/shellcheck/wiki/SC2155
# - used throughout the codebase
disable=SC1091,SC2034,SC2064,SC2155
# SC2162 - read without -r will mangle backslashes - https://github.com/koalaman/shellcheck/wiki/SC2162
# SC2174 - When used with -p, -m only applies to the deepest directory - https://github.com/koalaman/shellcheck/wiki/SC2174
# SC2179 - Use array+=("item") to append items to an array - https://github.com/koalaman/shellcheck/wiki/SC2179
# SC2191 - The = here is literal. To assign by index, use ( [index]=value ) with no spaces. To keep as literal, quote it - https://github.com/koalaman/shellcheck/wiki/SC2191
# SC2199 - Arrays implicitly concatenate in [[ ]]. Use a loop (or explicit * instead of @) - https://github.com/koalaman/shellcheck/wiki/SC2199
# SC2207 - Prefer mapfile or read -a to split command output (or quote to avoid splitting) - https://github.com/koalaman/shellcheck/wiki/SC2207
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.
@@ -57,8 +57,11 @@ Please keep the above in mind when utilizing deployment tasks.
When deploying a monorepo, it may be desirable to specify the specific path of the `app.json` file to use for a given app. This can be done via the `app-json:set` command. If a value is specified and that file does not exist within the repository, Dokku will continue the build process as if the repository has no `app.json` file.
For deploys via the `git:from-image` and `git:load-image` commands, the `app.json` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `app.json` extracted directly from the source code. Both cases will respect the configured `appjson-path` property value.
The default value may be set by passing an empty value for the option:
@@ -137,8 +140,6 @@ Dokku provides limited support for the `app.json` manifest from Heroku (document
-`scripts.dokku.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are _not_ committed at this phase.
-`scripts.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are _not_ committed at this phase.
For buildpack-based deployments, the location of the `app.json` file should be at the root of your repository. Dockerfile-based app deploys should have the `app.json` in the configured `WORKDIR` directory; otherwise Dokku defaults to the buildpack app behavior of looking in `/app`.
> Warning: Any failed `app.json` deployment task will fail the deploy. In the case of either phase, a failure will not affect any running containers.
The following is an example `app.json` file. Please note that only the `scripts.dokku.predeploy` and `scripts.dokku.postdeploy` tasks are supported by Dokku at this time. All other fields will be ignored and can be omitted.
plugin:disable <name> # Disable an installed plugin (third-party only)
plugin:enable <name> # Enable a previously disabled plugin
plugin:install [--core|git-url [--committish tag|branch|commit|--name custom-plugin-name]] # Optionally download git-url (with custom tag/committish) & run install trigger for active plugins (or only core ones)
plugin:install [--core|--git-url] [--committish branch|commit|tag] [--name custom-plugin-name] # Optionally download git-url (and pin to the specified branch/commit/tag) & run install trigger for active plugins (or only core ones)
plugin:installed <name> # Checks if a plugin is installed
plugin:install-dependencies [--core] # Run install-dependencies trigger for active plugins (or only core ones)
plugin:list # Print active plugins
plugin:trigger <args...>. # Trigger an arbitrary plugin hook
plugin:uninstall <name> # Uninstall a plugin (third-party only)
plugin:update [name [committish]] # Optionally update named plugin from git (with custom tag/committish) & run update trigger for active plugins
plugin:update [name [branch|commit|tag]] # Optionally update named plugin from git (and pin to the specified branch/commit/tag) & run update trigger for active plugins
```
```shell
@@ -35,35 +35,35 @@ dokku plugin:list
```
plugn: dev
00_dokku-standard 0.30.2 enabled dokku core standard plugin
> Warning: All plugin commands other than `plugin:list` and `plugin:help` require sudo access and must be run directly from the Dokku server.
@@ -165,6 +165,12 @@ An optional commit SHA-like object may be specified.
dokku plugin:update postgres 2.0.0
```
Any future invocation of `plugin:update` will respect the previously specified SHA-like object. To follow a particular branch again, specify that branch:
```shell
dokku plugin:update postgres main
```
### Uninstalling a plugin
Third party plugins can be uninstalled using the `plugin:uninstall` command:
- 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.
- 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 `formations` 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.
- 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.
- Herokuish build cache is now mounted from a docker volume - eg. `cache-node-js-app` - instead of the local filesystem. All existing app cache will be cleared upon upgrading past 0.29.0.
- The `vector` container integration now mounts config to `/etc/vector` instead of the path `/etc/vector/vector.json`, allowing users the ability to provide extra configuration for Vector Sinks. To take advantage of the new functionality, the vector container should be stopped (via `dokku logs:vector-stop`) and then started (via `dokku logs:vector-start`).
- The `traefik` integration now mounts config to `/data` instead of the path `/acme.json`, fixing permissions issues under certain architectures. To take advantage of the new functionality, the traefik container should be stopped (via `dokku traefik:stop`) and then started (via `dokku traefik:start`).
- Users no longer need to clear the `source-image` git property when transitioning from image-based deploys (`git:from-image` and `git:load-image`) to other deployment methods (git push, `git:from-archive`, `git:sync`).
- For deploys via the `git:from-image` and `git:load-image` commands, the `CHECKS` file is now extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `CHECKS` extracted directly from the source code. The filename in both cases is `CHECKS` and cannot be modified.
- Port mappings are now auto-detected during the build process. Users may override detected port mappings via the `ports` plugin. A default port mapping of `http:80:5000` will be used if none is otherwise specified.
- Users building docker images that run Dokku will need to use a new sudoer wrapper for the `docker-container-healthchecker` binary to work correctly. A reference version has been placed in the `docker` skeleton directory. This should only impact platform developers, and users of our Docker image will already have the file available.
- The default image used for Herokuish Buildpack builds is now `gliderlabs/herokuish:latest-22`, and is based on both the `heroku-22` stack as well as Ubuntu 22.04. Users that wish to stick with the old, `heroku-20`/Ubuntu 20.04 builder may specify `gliderlabs/herokuish:latest-20` as their builder image. Please see the [herokuish buildpack deployment documentation](/docs/deployment/builders/herokuish-buildpacks.md#customizing-the-buildpack-stack-builder) for more information on how to specify a custom buildpack stack builder.
- The default image used for Cloud Native Buildpack builds is now `heroku/builder:22`, and is based on both the `heroku-22` stack as well as Ubuntu 22.04. Users that wish to stick with the old, `heroku-20`/Ubuntu 20.04 builder may specify `heroku/buildpacks:20` as their builder image. Please see the [herokuish buildpack deployment documentation](/docs/deployment/builders/herokuish-buildpacks.md#customizing-the-buildpack-stack-builder) for more information on how to specify a custom buildpack stack builder.
## Deprecations
- The `proxy:ports*` commands have been replaced with the new `ports` plugin. Users will be able to use the old `proxy:ports*` commands for a single minor release, and they will be removed in the next minor release.
- The `common#get_available_port()` function has been deprecated and will be removed in the next release. Users should avoid interacting with this function and instead use the `ports-get-available` plugin trigger for fetching an available port.
- The `proxy-configure-ports` plugin trigger has been deprecated and will be removed in the next release. Users should instead trigger the `ports-configure` plugin trigger.
- The `common#get_dockerfile_exposed_ports()` function is deprecated and will be removed in the next release. There is no replacement for this as it's only use in Dokku core was in the `builder-dockerfile` plugin.
- The `common#get_exposed_ports_from_image()` function is deprecated and will be removed in the next release. There is no replacement for this as it's only use in Dokku core was during the build process.
- The environment variable `DOKKU_PROXY_PORT_MAP` has been migrated to the properties system. Direct changes to the value will be ignored, and users should interact with port maps via the `ports` plugin.
- The `CHECKS` file is deprecated in favor of defining healthchecks in the `app.json` file. The [docker-container-healthchecker](https://github.com/dokku/docker-container-healthchecker) tool can be used to generate healthcheck entries in `app.json` format from existing `CHECKS` files. See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md) for more information on how the new zero downtime check format works.
- ARM support is now deprecated, and will be removed in the next minor release. ARM releases are not tested in CI and do not get testing locally. Users of ARM installations on platforms such as the Raspberry PI should consider migrating to ARM64. ARM64 will continue to be supported by Dokku, and there are no plans to remove support for ARM64.
## Un-Deprecations
- The bare `apps` and `config` cli aliases are no longer deprecated. This better follows Heroku's output and is more useful to users. The subcommands will be treated as the primary, documented versions, while the aliases are there for convenience.
## Removals
- The variable `RAW_TCP_PORTS` is no longer exposed for `nginx.conf.sigil` templating.
- The environment variable `DOKKU_DOCKERFILE_PORTS` is no longer in use. Users wishing to change port mappings should instead use the `ports` plugin.
- The `common#get_app_raw_tcp_ports()` function has been removed in the next release. Users should instead use the `ports-get` plugin trigger for fetching ports for an app.
- The plugin trigger `network-compute-ports` has been removed. It's only use was in the `scheduler-docker-local` plugin, for exposing ports. It's functionality is now implemented via the `ports` plugin.
- The plugin trigger `network-get-port` has been removed. It's only use was in the `scheduler-docker-local` plugin, for recording ports. It's functionality is now implemented via the `ports` plugin.
@@ -111,12 +111,10 @@ The following config variables have special meanings and can be set in a variety
| `DOKKU_DISABLE_APP_AUTOCREATION` | none | `dokku config:set` | Disables automatic creation of a non-existent app on deploy. |
| `DOKKU_DOCKER_STOP_TIMEOUT` | `10` | `dokku config:set` | 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_SKIP_CLEANUP` | | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | When a deploy is triggered, if this is set to a non-empty value, then old docker containers and images will not be removed. |
@@ -132,37 +132,12 @@ See the [NGINX HSTS documentation](/docs/networking/proxies/nginx.md#hsts-header
Certain versions of nginx have bugs that prevent [HTTP/2](https://nginx.org/en/docs/http/ngx_http_v2_module.html) from properly responding to all clients, thus causing applications to be unavailable. For HTTP/2 to be enabled in your applications' nginx configs, you need to have installed nginx 1.11.5 or higher. See [issue 2435](https://github.com/dokku/dokku/issues/2435) for more details.
## Running behind a load balancer
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-Port` and `X-Forwarded-For`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
If your server runs behind an HTTP(S) load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application via `nginx:set`:
1. All requests are terminated at the load balancer, and forwarded to Nginx
2. The load balancer is configured to send the `X-Forwarded-` headers (this may be off by default)
If it's possible to make HTTP(S) requests directly to Nginx, bypassing the load balancer, or if the load balancer is not configured to set these headers, then it becomes possible for a client to set these headers to arbitrary values.
The `x-forwarded-ssl` property may also be set for application frameworks that require this value. Note that this is a non-standard version of setting `x-forwarded-proto` to `https`, and should only be done as a last resort.
```shell
# force-setting value to `on`
dokku nginx:set node-js-app x-forwarded-ssl on
# force-setting value to `off`
dokku nginx:set node-js-app x-forwarded-ssl on
# removing the value from nginx.conf (default)
dokku nginx:set node-js-app x-forwarded-ssl
```
### SSL Port Exposure
When your app is served from port `80` then the `/home/dokku/APP/nginx.conf` file will automatically be updated to instruct nginx to respond to ssl on port 443 as a new cert is added. If your app uses a non-standard port (perhaps you have a dockerfile deploy exposing port `99999`) you may need to manually expose an ssl port via `dokku proxy:ports-add <APP> https:443:99999`.
When your app is served from port `80` then the `/home/dokku/APP/nginx.conf` file will automatically be updated to instruct nginx to respond to ssl on port 443 as a new cert is added. If your app uses a non-standard port (perhaps you have a dockerfile deploy exposing port `99999`) you may need to manually expose an ssl port via `dokku ports:add <APP> https:443:99999`.
## Other
### Running behind a proxy (`X-Forwarded-Ssl`, etc.)
See the [running behind another proxy documentation](/docs/networking/proxies/nginx.md#running-behind-another-proxy--configuring-x-forwarded--headers) for more information on how to configure your Nginx config when your server is running behind a proxy (e.g. load balancer, etc.).
> Note: Some tools may not support the short-upstream syntax referenced above, and you may need to prefix
@@ -71,7 +70,7 @@ git push dokku main:master
> Note: Your private key should be registered with `ssh-agent` in your local development environment. If you get a `permission denied` error when pushing, you can register your private key as follows: `ssh-add -k ~/<your private key>`.
After running `git push dokku main:master`, you should have output similar to this in your terminal:
After running `git push dokku main`, you should have output similar to this in your terminal:
```
Counting objects: 231, done.
@@ -180,7 +179,7 @@ If you do not enter a fully qualified domain name when pushing your app, Dokku d
# the remote username *must* be dokku or pushes will fail
# the below example assumes your app server domain or IP is dokku.me. Push in the form of: dokku@{serveripordomain}:{dokkuappname}
Remember to also change your git remote on your local machine in order to make `git push dokku main:master` work again. For this you can use `git remote set-url`.
Remember to also change your git remote on your local machine in order to make `git push dokku main` work again. For this you can use `git remote set-url`.
When deploying a monorepo, it may be desirable to specify the specific path of the `project.toml` file to use for a given app. This can be done via the `builder-pack:set` command. If a value other than `project.toml` 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 `project.toml`.
For deploys via the `git:from-image` and `git:load-image` commands, the `project.toml` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `project.toml` extracted directly from the source code. Both cases will respect the configured `projecttoml-path` property value.
The default value may be set by passing an empty value for the option:
@@ -134,7 +136,7 @@ project2.toml
> New as of 0.23.0
The default stack builder in use by CNB buildpacks in Dokku is based on `heroku/buildpacks`. Users may desire to switch the stack builder to a custom version, either to update the operating system or to customize packages included with the stack builder. This can be performed via the `buildpacks:set-property` command.
The default stack builder in use by CNB buildpacks in Dokku is based on `heroku/builder:22`. Users may desire to switch the stack builder to a custom version, either to update the operating system or to customize packages included with the stack builder. This can be performed via the `buildpacks:set-property` command.
A change in the stack builder value will execute the `post-stack-set` trigger.
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_CNB_BUILDER` environment variable (`heroku/buildpacks` by default).
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_CNB_BUILDER` environment variable (`heroku/builder:22` by default).
See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.
When deploying a monorepo, it may be desirable to specify the specific path of the `Dockerfile` file to use for a given app. This can be done via the `builder-dockerfile:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
For git push, `git:from-archive`, and `git:sync` workflows, the `Dockerfile` is extracted directly from the source code, respecting the configured `dockerfile-path` property value.
For security reasons - and as per [Docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available only during runtime.
For users that require customization in the `build` phase, you may use build arguments via the [docker-options plugin](/docs/advanced-usage/docker-options.md):
For users that require customization in the `build` phase, you may use build arguments via the [docker-options plugin](/docs/advanced-usage/docker-options.md). All environment variables set by the `config` plugin are automatically exported during a docker build, and thus `--build-arg` only requires setting a key without a value.
Once set, the Dockerfile usage would be as follows:
@@ -148,18 +150,18 @@ ENV NODE_ENV ${NODE_ENV}
RUNecho$NODE_ENV
```
### Building images with Docker Buildkit
### Building images with Docker BuildKit
If your Dockerfile is using Docker engine's [buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set. Additionally, complete build log output can be forced via `BUILDKIT_PROGRESS=plain`. Both of these environment variables can be set as follows:
If your Dockerfile is using Docker Engine's [BuildKit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set (unless you're using Docker Engine v24 or higher, which [uses BuildKit by default](https://docs.docker.com/build/buildkit/#getting-started)). Additionally, complete build log output can be forced via `BUILDKIT_PROGRESS=plain`. Both of these environment variables can be set as follows:
```shell
echo"export DOCKER_BUILDKIT=1"| sudo tee -a /etc/default/dokku
echo"export BUILDKIT_PROGRESS=plain"| sudo tee -a /etc/default/dokku
```
#### Buildkit directory caching
#### BuildKit directory caching
Buildkit implements the `RUN --mount` option, enabling mount directory caches for `RUN` directives. The following is an example that mounts debian packaging related directories, which can speed up fetching of remote package data.
BuildKit implements the `RUN --mount` option, enabling mount directory caches for `RUN` directives. The following is an example that mounts debian packaging related directories, which can speed up fetching of remote package data.
```Dockerfile
FROMdebian:latest
@@ -196,32 +198,7 @@ Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disa
> New as of 0.5.0
You can also customize the run command using a `Procfile`, much like you would on Heroku or
with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types).
When you deploy your app, a Docker image will be built. The `Procfile` will be extracted from the image
(it must be in the folder defined in your `Dockerfile` as `WORKDIR` or `/app`) and the commands
in it will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
```Procfile
web: bin/run-prod.sh
worker: bin/run-worker.sh
```
And `Dockerfile`:
```Dockerfile
FROMubuntu:20.04
WORKDIR/app
COPY . ./
CMD["bin/run-dev.sh"]
```
When you deploy this app the `web` process will automatically be scaled to 1 and your Docker container
will be started basically using the command `docker run bin/run-prod.sh`. If you want to also run
a worker container for this app, you can run `dokku ps:scale worker=1` and a new container will be
started by running `docker run bin/run-worker.sh` (the actual `docker run` commands are a bit more
complex, but this is the basic idea). If you use an `ENTRYPOINT` in your `Dockerfile`, the lines
in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instead of being executed.
See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.
A change in the stack builder value will execute the `post-stack-set` trigger.
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_IMAGE` environment variable (`gliderlabs/herokuish:latest-20` by default).
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_IMAGE` environment variable (`gliderlabs/herokuish:latest-22` by default).
While many buildpacks have a default command that is run when a detected repository is pushed, it is possible to override this command via a Procfile. A Procfile can also be used to specify multiple commands, each of which is subject to process scaling. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
A Procfile is a file named `Procfile`. It should be named `Procfile` exactly, and not anything else. For example, `Procfile.txt` is not valid. The file should be a simple text file.
The file must be placed in the root directory of your application. It will not function if placed in a subdirectory.
If the file exists, it should not be empty, as doing so may result in a failed deploy.
The syntax for declaring a `Procfile` is as follows. Note that the format is one process type per line, with no duplicate process types.
```
<process type>: <command>
```
If, for example, you have multiple queue workers and wish to scale them separately, the following would be a valid way to work around the requirement of not duplicating process types:
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
### `curl` build timeouts
Certain buildpacks may time out in retrieving dependencies via `curl`. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a `curl` command.
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache) for more information on how to clear buildpack build cache for an application.
### Specifying commands via Procfile
See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.
@@ -43,8 +43,10 @@ The `lambda` builder plugin delegates all build logic to [lambda-builder](https:
When deploying a monorepo, it may be desirable to specify the specific path of the `lambda.yml` file to use for a given app. This can be done via the `builder-lambda:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
For deploys via the `git:from-image` and `git:load-image` commands, the `lambda.yml` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `lambda.yml` extracted directly from the source code. Both cases will respect the configured `lambdayml-path` property value.
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
@@ -248,19 +235,6 @@ The `git:load-image` command can optionally take a git `user.name` and `user.ema
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.
@@ -82,15 +82,9 @@ Note that increasing the value of `parallel-schedule-count` may significantly im
By default, Dokku will deploy one instance of a given process type at a time. This can be increased by customizing the `app.json``formation` key to include a `max_parallel` key for the given process type.
An `app.json` file can be committed to the root of the pushed app repository, and must be within the built image artifact in the image's working directory as shown below.
- Buildpacks: `/app/app.json`
- Dockerfile: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
- Docker Image: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
The `formation` key should be specified as follows in the `app.json` file:
```Procfile
```json
{
"formation":{
"web":{
@@ -107,6 +101,8 @@ Omitting or removing the entry will result in parallelism for that process type
Note that increasing the value of `max_parallel` may significantly impact CPU utilization on your host as your app containers - and their respective processes - start up. Setting a value higher than the number of available CPUs is discouraged. It is recommended that users carefully set this value so as not to overburden their server.
See the [app.json location documentation](/docs/advanced-usage/deployment-tasks.md#changing-the-appjson-location) for more information on where to place your `app.json` file.
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `docker-local` scheduler.
You can add your public key to Dokku with the `ssh-keys:add` command. The output will be the fingerprint of the SSH key:
You can add your public key to Dokku with the `ssh-keys:add` command. The path specified must contain your desired public ssh key contents and must exist on the server. Any special characters - such as `~` - are interpreted under the `dokku` user context. The output will be the fingerprint of the SSH key:
> `KEY_NAME` is a unique name which is used to identify public keys. Attempting to re-use a key name will result in an error. The SSH (Git) user is *always* `dokku`, as this is the system user that the `dokku` binary uses to perform all its actions.
Alternatively, you may pipe the contents of your ssh key via `cat` or `echo` into the `ssh-keys:add` command instead of specifying a path to the ssh key:
@@ -13,7 +13,7 @@ checks:skip <app> [process-type(s)] Skip zero-downtime checks for all proc
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.
You may both create user-defined checks for web processes using a `CHECKS` file, as well as customize any and all parts of this experience using the checks plugin.
You may both create user-defined checks for web processes using the `healthchecks` key in the `app.json` file, as well as customize any and all parts of this experience using the checks plugin.
> Web checks are performed via `curl` on Dokku host. Some application code - such
> as the Django framework - checks for specific hostnames or header values, these
@@ -42,7 +42,7 @@ 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.
The following settings may also be specified in the `CHECKS` file, though are available as environment variables in order to ease application reuse.
The following settings may also be specified in the `app.json` file, though are available as environment variables in order to ease application reuse.
-`DOKKU_CHECKS_WAIT`: (default: `5`) Wait this many seconds for the container to start before running checks.
-`DOKKU_CHECKS_TIMEOUT`: (default: `30`) Wait this many seconds for each response before marking it as a failure.
If your application needs a longer period to boot up - perhaps to load data into memory, or because of slow boot time - you may also use Dokku's `checks` functionality to more precisely check whether an application can serve traffic or not.
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, Dokku will fallback to the aforementioned process uptime check.
Healthchecks are run against all process from your application's `Procfile`. When no healthcheck is defined, Dokku will fallback to a process uptime check.
To specify checks, add a `CHECKS` file to the root of your project directory. The `CHECKS` file should be plain text and may contain:
One or more healthchecks can be defined in the `app.json` file - see the [deployment task documentation](/docs/advanced-usage/deployment-tasks.md) for more information on how this is extracted - under the `healthchecks.web` path:
- check instructions
- settings (NAME=VALUE)
- comments (lines starting with #)
- empty lines
> For Dockerfile and Docker Image based deploys, the file *must* be in the `WORKDIR` directory of the built image. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check instructions
The format of a check instruction is a path or relative URL, optionally followed by the expected content:
```
/about Our Amazing Team
```json
{
"healthchecks":{
"web":[
{
"type":"startup",
"name":"web check",
"description":"Checking if the app responds to the /health/ready endpoint",
"path":"/health/ready",
"attempts":3
}
]
}
```
The `CHECKS` file can contain multiple checks:
A healthcheck entry takes the following properties:
```
/ My Amazing App
/stylesheets/index.css .body
/scripts/index.js $(function()
/images/logo.png
```
-`attempts`: (default: `3` seconds) Number of retry attempts to perform on failure.
-`command`: (default `''` - empty string) Command to execute within container.
-`content`: (default: `''` - empty string) Content to search in http path check output.
initialDelay default: 0, unit: seconds) Number of seconds to wait after a container has started before triggering the healthcheck.
-`name`: (default: autogenerated) The name of the healthcheck. If unspecified, it will be autogenerated from the rest of the healthcheck information.
-`path`: (default: `/` - for http checks): An http path to check.
-`timeout`: (default: `5` seconds): Number of seconds to wait before timing out a healthcheck.
-`type`: (default: `""` - none): Type of the healthcheck. Options: liveness, readiness, startup.
-`uptime`: (default: `""` - none): Amount of time the container must be alive before the container is considered healthy. Any restarts will cause this to check to fail, and this check does not respect retries.
-`wait`: (default: `5` seconds): Number of seconds to wait between healthcheck attempts.
To check an application that supports multiple hostnames, use relative URLs that include the hostname:
> Warning: Healthchecks are implemented by specific scheduler plugins, and not all plugins support all options. Please consult the scheduler documentation for further details on what is supported.
```
//admin.dokku.me Admin Dashboard
//static.dokku.me/logo.png
```
You can also specify the protocol to explicitly check HTTPS requests:
```
https://admin.dokku.me Admin Dashboard
https://static.dokku.me/logo.png
```
While a full URL may be used in order to invoke checks, if you are using relative URLs, the port *must* be omitted.
> Changed as of 0.22.5
Please note that dollar sign bracket characters (`{` and `}`) must be escaped when used within a `CHECKS` file. Escaping follows golang template rules. The proper way to do this is via one of the following methods:
```
# escaping the `{` character
# using double-quotes
{{"{"}}
# using raw string constants
{{`{`}}
# escaping the `}` character
# using double-quotes
{{"}"}}
# using raw string constants
{{`}`}}
```
### Templating Checks Files
> New as of 0.22.5
An app's `CHECKS` file is sent through a single pass of the [`sigil`](https://github.com/gliderlabs/sigil/) templating tool. This enables usage of Golang templating within application `CHECKS` files. In addition to general templating access, access to app environment variables is also allowed via the `var` function:
```
{{ var "SOME_ENV_VAR" }}
```
This may be useful if certain zero-downtime checks require access to an app-specific value, such as a domain name.
### Check settings
The default behavior is to wait for `5` seconds before running the checks, to timeout the checks after `30` seconds, and to attempt the checks `5` times. If the checks fail `5` times, the deployment is considered failed and the old container will continue serving traffic.
You can change the default behavior by setting `WAIT`, `TIMEOUT`, and `ATTEMPTS` to different values in the `CHECKS` file:
```
WAIT=30 # Wait 1/2 minute
TIMEOUT=60 # Timeout after a minute
ATTEMPTS=10 # Attempt checks 10 times
/ My Amazing App
```
See the [docker-container-healthchecker](https://github.com/dokku/docker-container-healthchecker) documentation for more details on how healthchecks are interpreted.
In this example, a Rails application is successfully deployed to Dokku. The initial round of checks fails while the server is starting, but once it starts they succeed and the deployment is successful. `WAIT` is set to `10` because our application takes a while to boot up. `ATTEMPTS` is set to `6`, but the third attempt succeeds.
### Successful `CHECKS` file
```
WAIT=10
ATTEMPTS=6
/check.txt simple_check
```
For this check to work, we've added a line to `config/routes.rb` that simply returns a string:
```
get '/check.txt', to: proc {[200, {}, ['simple_check']]}
```
### Successful deploy output
> Note: The output has been trimmed for brevity.
```shell
git push dokku master
```
```
-----> Cleaning up...
-----> Building node-js-app from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.0.0
.....
-----> Discovering process types
Procfile declares types -> web
-----> Releasing node-js-app...
-----> Deploying node-js-app...
-----> Running pre-flight checks
-----> Attempt 1/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
!
curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
! Check attempt 1/6 failed.
-----> Attempt 2/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
!
curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
! Check attempt 2/6 failed.
-----> Attempt 3/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/check.txt => "simple_check"
-----> All checks successful!
=====> node-js-app container output:
=> Booting Thin
=> Rails 4.2.0 application starting in production on http://0.0.0.0:5000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:5000, CTRL+C to stop
=====> end node-js-app container output
-----> Running post-deploy
-----> Configuring myapp.dokku.me...
-----> Creating http nginx.conf
Reloading nginx
-----> Shutting down old container in 60 seconds
=====> Application deployed:
http://myapp.dokku.me
```
## Example: Failing Rails deployment
In this example, a Rails application fails to deploy. The reason for the failure is that the PostgreSQL database connection fails. The initial checks will fail while we wait for the server to start up, just like in the above example. However, once the server does start accepting connections, we will see an error 500 due to the PostgreSQL database connection failure.
Once the attempts have been exceeded, the deployment fails and we see the container output, which shows the PostgreSQL connection errors.
### Failing `CHECKS` file
```
WAIT=10
ATTEMPTS=6
/
```
> The check to the root url `/` would normally access the database.
### Failing deploy output
> Note: The output has been trimmed for brevity.
```shell
git push dokku master
```
```
-----> Cleaning up...
-----> Building node-js-app from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.0.0
.....
Discovering process types
Procfile declares types -> web
Releasing node-js-app...
Deploying node-js-app...
Running pre-flight checks
-----> Attempt 1/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (7) Failed to connect to 172.17.0.188 port 5000: Connection refused
! Check attempt 1/6 failed.
-----> Attempt 2/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (7) Failed to connect to 172.17.0.188 port 5000: Connection refused
! Check attempt 2/6 failed.
-----> Attempt 3/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 3/6 failed.
-----> Attempt 4/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 4/6 failed.
-----> Attempt 5/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
! Check attempt 5/6 failed.
-----> Attempt 6/6 Waiting for 10 seconds ...
CHECKS expected result:
http://localhost/ => ""
!
curl: (22) The requested URL returned error: 500 Internal Server Error
Could not start due to 1 failed checks.
! Check attempt 6/6 failed.
=====> node-js-app container output:
=> Booting Thin
=> Rails 4.2.0 application starting in production on http://0.0.0.0:5000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:5000, CTRL+C to stop
Started GET "/" for 172.17.42.1 at 2015-03-26 21:36:47 +0000
Is the server running on host "172.17.42.1" and accepting
TCP/IP connections on port 5431?
PG::ConnectionBad (could not connect to server: Connection refused
Is the server running on host "172.17.42.1" and accepting
- Description: Return the value for an app's network property
@@ -1226,6 +1241,97 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
nginx -t
```
### `ports-clear`
- Description: Clears the ports for a given app without triggering further restarts or rebuilds
- Invoked by: internally
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `ports-configure`
- Description: Configures the initial proxy ports
- Invoked by: `internally triggered by proxy plugins`
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `ports-get`
- Description: Returns a list of port mappings, newline delimited
- Invoked by: Various networking plugins
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `ports-get-available`
- Description: Prints out an available port greater than 1024
- Invoked by: Various networking plugins
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `ports-get-property`
- Description: Return the value for an app's ports property
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";PROPERTY="$2"
# TODO
```
### `ports-set-detected`
- Description: Allows builders to specify detected port mappings for a given app
- Invoked by: Builder plugins
- Arguments: `$APP [$PORT_MAPPING...]`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `post-app-clone`
- Description: Allows you to run commands after an app was cloned.
@@ -1388,7 +1494,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
- Description: This trigger should be used to do stuff to containers after they are created but before they are started. They are explicitely for commands that may involve network traffic, and _not_ for commands that are self-contained, such as chown or tar.
- Description: Allows you to run commands once the proxy port mappings for an app have been updated. It also sends the invoking command. This can be "add", "clear" or "remove".
- Description: Allows you to run commands once the port mappings for an app have been updated. It also sends the invoking command. This can be "add", "clear" or "remove".
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 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.2
FROMdokku/dokku:0.31.0
RUN dokku plugin:install https://github.com/dokku/dokku-postgres.git postgres
RUN dokku plugin:install https://github.com/dokku/dokku-redis.git redis
@@ -58,10 +58,8 @@ A value of 64 would allow domains with up to 64 characters. Set it to 128 if you
Save the file and try stopping nginx and starting it again:
```shell
/etc/init.d/nginxstop
## * Stopping nginx nginx [ OK ]
/etc/init.d/nginx start
## * Starting nginx nginx [ OK ]
dokku nginx:stop
dokku nginx:start
```
---
@@ -74,12 +72,12 @@ For example, if you have an `EXPOSE` directive like so:
EXPOSE8000
```
The proxy port mapping will be `http:8000:8000`.
The port mapping will be `http:8000:8000`.
To avoid this issue, either of the following can be done:
- Remove `EXPOSE` directive: This will require respecting the `$PORT` environment variable (automatically set by Dokku). Once that change is deployed, the port mapping should be cleared via the `dokku proxy:ports-clear $APP` command (where `$APP` is your app name).
- Update the port mapping: Updating the port mapping to redirect port `80` to your app's exposed port via `dokku proxy:ports-set $APP http:80:$EXPOSED_PORT` can also fix the issue. This will also allow certificate management and the letsencrypt plugin to work correctly.
- Remove `EXPOSE` directive: This will require respecting the `$PORT` environment variable (automatically set by Dokku). Once that change is deployed, the port mapping should be cleared via the `dokku ports:clear $APP` command (where `$APP` is your app name).
- Update the port mapping: Updating the port mapping to redirect port `80` to your app's exposed port via `dokku ports:set $APP http:80:$EXPOSED_PORT` can also fix the issue. This will also allow certificate management and the letsencrypt plugin to work correctly.
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
@@ -167,7 +165,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`.
@@ -231,16 +233,14 @@ If this solves the issue temporarily, longer term you should consider [configuri
### My application deploys properly, but won't load in browser "connection refused"
This could be a result of a bad proxy configuration (`http:5000:5000` may be incorrect). Run `dokku proxy:report myapp` to check if your app has the correct proxy configuration. It should show something like the following.
This could be a result of a bad proxy configuration (`http:5000:5000` may be incorrect). Run `dokku ports:report node-js-app` to check if your app has the correct proxy configuration. It should show something like the following.
```
=====> myapp proxy information
Proxy enabled: true
Proxy port map: http:80:5000 https:443:5000
Proxy type: nginx
=====> node-js-app ports information
Port map: http:80:5000 https:443:5000
```
Set `dokku proxy:ports-set front http:80:5000` to get proxy correctly configured for http endpoint.
Set `dokku ports:set node-js-app http:80:5000` to get proxy correctly configured for http endpoint.
### I deployed a new app but now subdomains are miss-routed
<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;">
> New as of 0.31.0, replaces the previous `proxy:ports*` commands
```
proxy:ports <app> # List proxy port mappings for an app
proxy:ports-add <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Add proxy port mappings to an app
proxy:ports-clear <app> # Clear all proxy port mappings for an app
proxy:ports-remove <app> <host-port> [<host-port>|<scheme>:<host-port>:<container-port>...] # Remove specific proxy port mappings from an app
proxy:ports-set <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Set proxy port mappings for an app
ports:list <app> # List port mappings for an app
ports:add <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Add port mappings to an app
ports:clear <app> # Clear all port mappings for an app
ports:remove <app> <host-port> [<host-port>|<scheme>:<host-port>:<container-port>...] # Remove specific port mappings from an app
ports:set <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Set port mappings for an app
```
In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into the proxy plugin. Dokku 0.6.0 introduced the ability to map host ports to specific container ports. In the future this will allow other proxy software - such as HAProxy or Caddy - to be used in place of nginx.
## Usage
> Warning: Mapping alternative ports may conflict with the active firewall installed on your server or hosting provider. Such software includes - but is not limited to - AWS Security Groups, iptables, and UFW. Please consult the documentation for those softwares as applicable.
>
> Users should also avoid setting the `PORT` environment variable. Dokku will use port mappings to set this value. Overriding this manually may cause issues in application routing.
> New as of 0.6.0
You can now configure `host -> container` port mappings with the `proxy:ports-*` commands. This mapping is currently supported by the built-in nginx-vhosts plugin.
You can now configure `host -> container` port mappings with the `ports:*` commands. This mapping is currently supported by the built-in nginx-vhosts plugin.
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` commands detailed below.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `ports:*` commands detailed below.
### Port Scheme
The proxy port scheme is as follows:
-`SCHEME:HOST_PORT:CONTAINER_PORT`
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.
To change the proxy implementation in use for an application, use the `proxy:set` command:
```shell
# no validation will be performed against
# the specified proxy implementation
dokku proxy:set node-js-app nginx
```
### Listing port mappings
To inspect the port mapping for a given application, use the `proxy:ports` command:
To inspect the port mapping for a given application, use the `ports:list` command:
A port mapping can be removed using the `proxy:ports-remove` command if it no longer necessary:
A port mapping can be removed using the `ports:remove` command if it no longer necessary:
```shell
dokku proxy:ports-remove node-js-app http:80:5000
dokku ports:remove node-js-app http:80:5000
```
Ports may also be removed by specifying only the `host-port` value. This effectively acts as a wildcard and removes all mappings for that particular host port.
```shell
dokku proxy:ports-remove node-js-app http:80
dokku ports:remove node-js-app http:80
```
## Port management by Deployment Method
> Warning: If you set a proxy port map but _do not have a global domain set_, Dokku will reset that map upon first deployment.
> Warning: If you set a port map but _do not have a global domain set_, Dokku will reset that map upon first deployment.
### Buildpacks
@@ -138,7 +149,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` 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).
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
@@ -156,10 +167,10 @@ The application would be exposed to the user at `node-js-app.dokku.me:1234`. If
@@ -169,24 +180,40 @@ Any application that does not use an `EXPOSE` directive will result in Dokku def
- modify your application to support the `PORT` environment variable.
- switch to using an `EXPOSE` directive in your Dockerfile.
#### Switching between `EXPOSE` usage modes
### Displaying ports reports for an app
When switching between `EXPOSE` usage modes, it is important to reset your port management. The following two commands can be used to reset your state and redeploy your application.
You can get a report about the app's ports status using the `ports:report` command:
```shell
# assuming your application is called `node-js-app`
dokku config:unset --no-restart node-js-app DOKKU_DOCKERFILE_PORTS PORT
dokku proxy:ports-clear node-js-app
dokku ports:report
```
### Docker Image
```
=====> node-js-app ports information
Port map detected: http:80:5000
Port map: http:80:5000 https:443:5000
=====> python-sample ports information
Port map detected: http:80:5000
Port map: http:80:5000
=====> ruby-sample ports information
Port map detected: http:80:5000
Port map: http:80:5000
```
When deploying an image, we will use `docker inspect` to extract the `ExposedPorts` configuration and if defined, use that to populate port mapping. If this behavior is not desired, you can override that configuration variable with the following commands.
You can run the command for a specific app also.
```shell
# assuming your application is called `node-js-app`
@@ -15,7 +15,7 @@ haproxy:stop # Stops the haproxy server
## Requirements
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`.
Using the `haproxy` 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`.
@@ -107,6 +107,42 @@ Once the HSTS setting is disabled globally, it can be re-enabled on a per-app ba
dokku nginx:set node-js-app hsts true
```
### Running behind another proxy — configuring `X-Forwarded-*` headers:
Dokku's default Nginx configuration passes the de-facto standard HTTP headers [`X-Forwarded-For`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [`X-Forwarded-Proto`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto), and `X-Forwarded-Port` to your application.
These headers indicate the IP address of the original client making the request, the protocol of the original request (HTTP or HTTPS), and the port number of the original request, respectively.
If you have another HTTP proxy sitting in between the end user and your server (for example, a load balancer, or a CDN), then the values of these headers will contain information about (e.g. the IP address of) the the closest proxy, and not the end user.
To fix this, assuming that the other proxy also passes `X-Forwarded-*` headers, which in turn contain information about the end user, you can tell Nginx include those values in the `X-Forwarded-*` headers that it sends to your application. You can do this via `nginx:set`, like so:
1. Requests to your website always go through a trusted proxy.
2. That proxy is configured to send the aforementioned `X-Forwarded-*` headers.
Otherwise, if it's possible for clients to make HTTP requests directly against your server, bypassing the other proxy, or if the other proxy is not configured to set these headers, then a client can basically pass any arbitrary values for these headers (which your app then presumably reads) and thereby fake an IP address, for example.
There's also the `X-Forwarded-Ssl` header which a less common alternative to `X-Forwarded-Proto` — and because of that, isn't included in Dokku's default Nginx configuration.
But you can tell Nginx to send this header as well, if necessary.
```shell
# force-setting value to `on`
dokku nginx:set node-js-app x-forwarded-ssl on
# force-setting value to `off`
dokku nginx:set node-js-app x-forwarded-ssl off
# removing the value from nginx.conf (default)
dokku nginx:set node-js-app x-forwarded-ssl
```
### Checking access logs
> Note: Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
@@ -293,14 +329,17 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
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`.
For deploys via the `git:from-image` and `git:load-image` commands, the `nginx.conf.sigil` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `nginx.conf.sigil` extracted directly from the source code. Both cases will respect the configured `nginx-conf-sigil-path` property value.
In either case, the value can be reset by specifying an empty value.
@@ -337,9 +376,8 @@ Unsetting this value is the same as enabling custom nginx config usage.
{{ .PROXY_PORT }} Non-SSL nginx listener port (same as `DOKKU_PROXY_PORT` config var)
{{ .PROXY_SSL_PORT }} SSL nginx listener port (same as `DOKKU_PROXY_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
{{ .PROXY_PORT_MAP }} List of port mappings (same as `DOKKU_PROXY_PORT_MAP` config var)
{{ .PROXY_UPSTREAM_PORTS }} List of configured upstream ports (derived from `DOKKU_PROXY_PORT_MAP` config var)
{{ .RAW_TCP_PORTS }} List of exposed tcp ports as defined by Dockerfile `EXPOSE` directive (**Dockerfile apps only**)
{{ .PROXY_PORT_MAP }} List of port mappings (same as the `map` ports property)
{{ .PROXY_UPSTREAM_PORTS }} List of configured upstream ports (derived from the `map` ports property)
{{ .SSL_INUSE }} Boolean set when an app is SSL-enabled
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
@@ -457,10 +495,6 @@ See the [customizing hostnames documentation](/docs/configuration/domains.md#cus
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts) for more information on how to disable domain usage for your app.
### Running behind a load balancer
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer) for more information on how to configure your nginx config for running behind a network load balancer.
### SSL Configuration
See the [ssl documentation](/docs/configuration/ssl.md) for more information on how to configure SSL certificates for your application.
@@ -471,7 +505,7 @@ See the [proxy documentation](/docs/networking/proxy-management.md) for more inf
### Managing Proxy Port mappings
See the [proxy documentation](/docs/networking/proxy-management.md#proxy-port-mapping) for more information on how to manage ports proxied for your app.
See the [ports documentation](/docs/networking/port-management.md) for more information on how to manage ports proxied for your app.
Dokku can provide integration with the [OpenResty](https://openresty.org/) proxy service by utilizing the Docker label-based integration implemented by [openresty-docker-proxy](https://github.com/dokku/openresty-docker-proxy).
```
openresty:report [<app>] [<flag>] # Displays a openresty report for one or more apps
Using the `openresty` 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 OpenResty.
The OpenResty plugin has specific rules for routing requests:
- OpenResty integration is exposed via docker labels attached to containers. Changes in labels require either app deploys or rebuilds.
- While OpenResty will respect labels associated with other containers, only `web` containers have OpenResty 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 OpenResty
To use the OpenResty plugin, use the `proxy:set` command for the app in question:
```shell
dokku proxy:set node-js-app openresty
```
This will enable the docker label-based OpenResty integration. All future deploys will inject the correct labels for OpenResty to read and route requests to containers. Due to the docker label-based integration used by OpenResty, 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 OpenResty container
OpenResty can be started via the `openresty:start` command. This will start a OpenResty container via the `docker compose up` command.
```shell
dokku openresty:start
```
### Stopping the OpenResty container
OpenResty may be stopped via the `openresty:stop` command.
```shell
dokku openresty:stop
```
The OpenResty container will be stopped and removed from the system. If the container is not running, this command will do nothing.
### Showing the OpenResty compose config
For debugging purposes, it may be useful to show the OpenResty compose config. This can be achieved via the `openresty:show-config` command.
```shell
dokku openresty:show-config
```
### Customizing the OpenResty container image
While the default OpenResty image is hardcoded, users may specify an alternative by setting the `image` property with the `--global` flag:
It may be necessary to check the OpenResty container's logs to ensure that OpenResty is operating as expected. This can be performed with the `openresty:logs` command.
```shell
dokku openresty: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 openresty:logs --tail --num 10
```
The above command will show logs continually from the openresty container, with an initial history of 10 log lines
### SSL Configuration
The OpenResty 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 OpenResty 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:
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.
To change the proxy implementation in use for an application, use the `proxy:set` command:
```shell
# no validation will be performed against
# the specified proxy implementation
dokku proxy:set node-js-app nginx
```
See the [port scheme documentation](/docs/networking/port-management.md#port-scheme) for more information on the port mapping scheme used by dokku.
### Proxy port mapping
@@ -136,7 +117,7 @@ From Dokku versions `0.5.0` until `0.11.0`, enabling or disabling an application
Custom plugins names _must_ have the suffix `-vhosts` or scheduler overriding via `proxy:set` may not function as expected.
At this time, the following dokku commands are used to implement a complete proxy implementation.
At this time, the following dokku commands are used to interact with a complete proxy implementation.
-`domains:add`: Adds a given domain to an app.
- triggers: `post-domains-update`
@@ -158,13 +139,13 @@ At this time, the following dokku commands are used to implement a complete prox
- triggers: `proxy-disable`
-`proxy:enable`: Enables the proxy configuration for an app.
- triggers: `proxy-enable`
-`proxy:ports-add`: Adds one or more port mappings to an app
-`ports:add`: Adds one or more port mappings to an app
- triggers: `post-proxy-ports-update`
-`proxy:ports-clear`: Clears out all port mappings for an app.
-`ports:clear`: Clears out all port mappings for an app.
- triggers: `post-proxy-ports-update`
-`proxy:ports-remove`: Removes one or more port mappings from an app.
-`ports:remove`: Removes one or more port mappings from an app.
- triggers: `post-proxy-ports-update`
-`proxy:ports-set`: Sets all port mappings for an app.
-`ports:set`: Sets all port mappings for an app.
- triggers: `post-proxy-ports-update`
Proxy implementations may decide to omit some functionality here, or use plugin triggers to supplement config with information from other plugins.
> Note: Dokku supports the Procfile format as defined in [this document](https://github.com/dokku/procfile-util/blob/master/PROCFILE_FORMAT.md) under "Strict Mode" parsing rules.
Apps can define processes to run by using a `Procfile`. A `Procfile` is a simple text file that can be used to specify multiple commands, each of which is subject to process scaling. In the case where the built image sets a default command to run - either through usage of `CMD` for Dockerfile-based builds, a default process for buildpack-based builds, or any other method for the builder in use - the `Procfile` will take precedence.
If the file exists, it should not be empty, as doing so may result in a failed deploy.
The syntax for declaring a `Procfile` is as follows. Note that the format is one process type per line, with no duplicate process types.
```
<process type>: <command>
```
If, for example, you have multiple queue workers and wish to scale them separately, the following would be a valid way to work around the requirement of not duplicating process types:
If the app build declares an `ENTRYPOINT`, the command defined in the `Procfile` is passed as an argument to that entrypoint. This is the case for all Dockerfile-based, Docker Image, and Cloud Native Buildpack deployments.
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [web process scaling documentation](/docs/processes/process-management.md#the-web-process) for more details around scaling individual processes.
See the [Procfile location documentation](/docs/processes/process-management.md#changing-the-procfile-location) for more information on where to place your `Procfile` file.
#### The `web` process
For initial app deploys, Dokku will default to starting a single `web` process for each app. This process may be defined within the `Procfile` or as the `CMD` (for Dockerfile or Docker image deploys). Scaling of the `web` process - and all other processes - may be managed via `ps:scale` or the `formation` key in the `app.json` file either before or after the initial deploy.
There are also a few other exceptions for the `web` process.
- By default, the built-in nginx proxy implementation only proxies the `web` process (others may be handled via a custom `nginx.conf.sigil`).
- See the [nginx request proxying documentation](/docs/networking/proxies/nginx.md#request-proxying) for more information on how nginx handles proxied requests.
- Only the `web` process may be bound to an external port.
#### The `release` process
The `Procfile` also supports a special `release` command which acts in a similar way to the [Heroku Release Phase](https://devcenter.heroku.com/articles/release-phase). See the [Release deployment task documentation](/docs/advanced-usage/deployment-tasks.md#procfile-release-command) for more information on how Dokku handles this process type.
#### Changing the `Procfile` location
When deploying a monorepo, it may be desirable to specify the specific path of the `Procfile` file to use for a given app. This can be done via the `ps:set` command. If a value is specified and that file does not exist within the repository, Dokku will continue the build process as if the repository has no `Procfile`.
For deploys via the `git:from-image` and `git:load-image` commands, the `Procfile` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `Procfile` extracted directly from the source code. Both cases will respect the configured `procfile-path` property value.
The default value may be set by passing an empty value for the option:
```shell
dokku ps:set node-js-app procfile-path
```
The `procfile-path` property can also be set globally. The global default is `Procfile`, and the global value is used when no app-specific value is set.
> Using a `formation` key in an `app.json` file with _any_ `quantity` specified disables the ability to use `ps:scale` for scaling. All processes not specified in the `app.json` will have their process count set to zero.
An `app.json` file can be committed to the root of the pushed app repository, and must be within the built image artifact in the image's working directory as shown below.
- Buildpacks: `/app/app.json`
- Dockerfile: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
- Docker Image: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
The `formation` key should be specified as follows in the `app.json` file:
Users can also configure scaling within the codebase itself to manage process scaling. The `formation` key should be specified as follows in the `app.json` file:
```Procfile
{
@@ -154,44 +219,9 @@ The `formation` key should be specified as follows in the `app.json` file:
}
```
Removing the file will result in Dokku respecting the `ps:scale` command for setting scale values. The values set via the `app.json` file from a previous deploy will be respected.
Removing the `formation` key or removing the `app.json` file from your repository will result in Dokku respecting the `ps:scale` command for setting scale values. The values set via the `app.json` file from a previous deploy will be respected.
#### The `web` process
For initial app deploys, Dokku will default to starting a single `web` process for each app. This process may be defined within the `Procfile` or as the `CMD` (for Dockerfile or Docker image deploys). Scaling of the `web` process - and all other processes - may be managed via `ps:scale` or the `formation` key in the `app.json` file either before or after the initial deploy.
There are also a few other exceptions for the `web` process.
- Custom checks defined by a `CHECKS` file only apply to the `web` process type.
- By default, the built-in nginx proxy implementation only proxies the `web` process (others may be handled via a custom `nginx.conf.sigil`).
- See the [nginx request proxying documentation](/docs/networking/proxies/nginx.md#request-proxying) for more information on how nginx handles proxied requests.
- Only the `web` process may be bound to an external port.
#### Changing the `Procfile` location
When deploying a monorepo, it may be desirable to specify the specific path of the `Procfile` file to use for a given app. This can be done via the `ps:set` command. If a value is specified and that file does not exist within the repository, Dokku will continue the build process as if the repository has no `Procfile`.
```shell
dokku ps:set node-js-app procfile-path Procfile2
```
The default value may be set by passing an empty value for the option:
```shell
dokku ps:set node-js-app procfile-path
```
The `procfile-path` property can also be set globally. The global default is `Procfile`, and the global value is used when no app-specific value is set.
The default value may be set by passing an empty value for the option.
```shell
dokku ps:set --global procfile-path
```
See the [app.json location documentation](/docs/advanced-usage/deployment-tasks.md#changing-the-appjson-location) for more information on where to place your `app.json` file.
cron:list <app> # List scheduled cron tasks for an app
cron:report [<app>] [<flag>] # Display report about an app
cron:list <app> [--format json|stdout] # List scheduled cron tasks for an app
cron:report [<app>] [<flag>] # Display report about an app
cron:run <app> <cron_id> [--detach] # Run a cron task on the fly
```
## Usage
@@ -35,6 +36,8 @@ A cron entry takes the following properties:
Zero or more cron commands can be specified per app. Cron entries are validated after the build artifact is created but before the app is deployed, and the cron schedule is updated during the post-deploy phase.
See the [app.json location documentation](/docs/advanced-usage/deployment-tasks.md#changing-the-appjson-location) for more information on where to place your `app.json` file.
#### Task Environment
When running scheduled cron tasks, there are a few items to be aware of:
@@ -42,7 +45,7 @@ When running scheduled cron tasks, there are a few items to be aware of:
- Scheduled cron tasks are performed within the app environment available at runtime. If the app image does not exist, the command may fail to execute.
- 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.
- 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.
- 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.
By default, the task is run in an attached container - as supported by the scheduler. To run in a background detached container, specify the `--detach` flag:
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.