# History
## 0.24.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.4/bootstrap.sh
sudo DOKKU_TAG=v0.24.4 bash bootstrap.sh
```
### Bug Fixes
- #4526: @josegonzalez Do not cut off builder arguments that have a 'v-' substring
- #4523: @josegonzalez Ignore set pipefail errors when DOKKU_SHELL is set to sh
- #4516: @josegonzalez Properly handle letsencrypt certs in certs:report output
- #4510: @josegonzalez Reformat existing buildpacks files
### New Features
- #4525: @josegonzalez Update error for git:from- commands when the artifact is already synced
- #4524: @josegonzalez Allow skipping entrypoint detection if entrypoint is tini
### Documentation
- #4531: @elamje Update config command to config:show
- #4528: @grantjenks Fix typo in persistent storage docs
- #4530: @Tobbe deployment docs: fix letsencrypt plugin name
- #4517: @illgitthat Update README with correct link to docs
- #4513: @josegonzalez Add a note on ssl and letsencrypt usage to the setup docs
- #4511: @josegonzalez Document removal of nginx site-enabled files for first time installers
- #4506: @josegonzalez Add full example for custom nginx log format
- #4504: @josegonzalez Clarify permissions on persistent storage paths
- #4503: @josegonzalez Drop dead newsletter link
### Other
- #4540: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.5.1 to 1.5.2 in /tests/apps/gogrpc
- #4535: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.4 to 20.1.0 in /tests/apps/multi
- #4536: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 11.0.1 to 11.0.2 in /tests/apps/java
- #4537: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.4 to 20.1.0 in /tests/apps/python-flask
- #4527: @Cellane Remove all traces of dokku-update
Previously, the shorthand was not properly supported. While this _should_ be the domain of the gliderlabs/herokuish repository, we do it here as a courtesy to Dokku users.
Additionally, support the heroku-community => heroku mapping.
Closes#4452
CNB uses a custom user/group id depending on the image.
Also cleanup the entire doc to make it generally more readable with less repetition.
Closes#4479
# History
## 0.24.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.3/bootstrap.sh
sudo DOKKU_TAG=v0.24.3 bash bootstrap.sh
```
### Bug Fixes
- #4496: @josegonzalez Ensure existing apps are initialized before modifying with code
### Documentation
- #4492: @josegonzalez Set better header colors for dark mode
- #4481: @bfontaine docs: fix a broken link
### Other
- #4495: @dependabot[bot] chore(deps): bump djangorestframework from 3.11.0 to 3.11.2 in /tests/apps/dockerfile-release
- #4494: @dependabot[bot] chore(deps): bump django from 3.0.7 to 3.1.6 in /tests/apps/dockerfile-release
- #4491: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.3 to 1.5.1 in /tests/apps/gogrpc
Prior to 0.24.0, not all applications would have their repositories initialized. This was especially the case for tags and tarball deploys.
This state is now correctly detected and the repository is initialized as expected.
Closes#4485
# History
## 0.24.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.2/bootstrap.sh
sudo DOKKU_TAG=v0.24.2 bash bootstrap.sh
```
### Bug Fixes
- #4473: @josegonzalez Add the correct log mount for app logs
### Other
- #4465: @Akirtovskis Add git:unlock command
- #4470: @dependabot-preview[bot] chore(deps): bump socket.io from 3.1.2 to 4.0.0 in /tests/apps/.websocket.disabled
- #4462: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 189 to 190 in /tests/apps/php
As per documentation, the `/var/log/dokku/apps` should be mounted from the host to the container. The existing mount was `/var/log/dokku` mounted to `/var/logs/dokku/apps`.
The broken mount will be removed in the next minor.
# History
## 0.24.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.1/bootstrap.sh
sudo DOKKU_TAG=v0.24.1 bash bootstrap.sh
```
### Bug Fixes
- #4454: @josegonzalez Use proper title for azure releases and fix tmp dir creation
### Documentation
- #4461: @josegonzalez Add dark mode support to documentation site
- #4457: @Cellane Rename 0.24.0 migration guide
- #4456: @josegonzalez Fix doc link and add 0.24.0 appendix to migration guides
# History
## 0.24.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.0/bootstrap.sh
sudo DOKKU_TAG=v0.24.0 bash bootstrap.sh
```
See the [0.24.0 migration guide](/docs/appendices/0.24.0-migration-guide.md) for more information on migrating to 0.24.0.
### Bug Fixes
- #4449: @josegonzalez Gitignore trigger symlink
- #4447: @josegonzalez Checkout code to ensure the bump-azure script is available
### New Features
- #4453: @josegonzalez Simplify tar and zip deploys via git:from-archive
- #4450: @josegonzalez Simplify docker image deploys via git:from-image
- #4379: @josegonzalez Allow builders to be detected based on repository contents
- #4425: @josegonzalez Implement heroku's postdeploy deployment task
- #4424: @josegonzalez Implement git:auth command
- #4419: @josegonzalez Add parallelism to certain proxy commands
### Refactors
- #4374: @josegonzalez Change exit code when app does not exist
### Documentation
- #4451: @josegonzalez Update links to builder documentation to avoid extra rewrite
- #4448: @josegonzalez Add documentation for git push to dokku-in-docker
The previous tar support lacked the ability to track changes between tarball deploys. Critically, it also failed to be handled correctly when there was _also_ a git deployment done on the app, resulting in odd deployment states depending on the angles of the moon and the sun in the sky.
Rather than try to "fix" this through some hokey mechanism, importing the tar file contents into the git repository is preferred, as then the user can refer to the repository for commit history.
Additionally, we add support for non-tar files (tar.gz and zip), enabling deployments from systems that do not create tar files, such as Github (their tarball url is a tar.gz file).
Finally, this deprecates the tar plugin, and sets it to be removed in the next minor release (in addition to the tags plugin).
Closes#3458Closes#4207
The new command superscedes the previous tags plugin, and integrates docker image deployment with the general build process.
While `docker image load` is not supported, this otherwise completely handles all previous workflows supported by the `tags:deploy` command, while doing so in a much easier to use interface.
Closes#4296
Rather than hardcode two builders, allow builders to specify a `builder-detect` trigger. This trigger can be used to specify if the builder should or should not be used for an application. Each builder takes stdin and can decide if it wants to emit it or emit it's own image source type.
If the final value is empty, then Dokku will default to herokuish (and cnb once that is stable). In addition, a future change may allow users to manually specify a builder in the case they wish to override the choice selected by Dokku.
This change enables users to build custom builder plugins and have those plugins used for building an image asset. By way of example, an enterprising user could create a `builder-lambda` based on lambci, and then pair this with a scheduler plugin that updates a lambda function on AWS. Alternatively, a user might decide they wish to place their Dockerfile in a specific directory for their applications - such as an `_infrastructure` directory - and create a plugin to override how that is detected within Dokku.
This occurs during the postdeploy on the first deploy of an app, mimicking heroku. It currently happens _after_ the `postdeploy` and `release` deploy tasks.
# History
## 0.23.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.9/bootstrap.sh
sudo DOKKU_TAG=v0.23.9 bash bootstrap.sh
```
### Refactors
- #4445: @josegonzalez Bump azure template and formula directly on release
### Documentation
- #4444: @josegonzalez Uuse updated links for documentation
- #4439: @RyukerLiu View Doc redirect not working. Change to use direct link
Rather than try and do something fancy on tag creation via workflows - which won't trigger due to workflows not being able to trigger other workflows without using workflow_run on the downstream workflow as a trigger - we just do all the releasing at once. This makes it easy to understand whether a release fully completed.
# History
## 0.23.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.8/bootstrap.sh
sudo DOKKU_TAG=v0.23.8 bash bootstrap.sh
```
### Bug Fixes
- #4437: @josegonzalez Switch to using GIT_DIR environment variable to fix Centos 7 support
- #4436: @josegonzalez Properly handle directory change when cleaning .git directory
### New Features
- #4428: @josegonzalez Bump azure ARM quickstart template on release
### Documentation
- #4435: @josegonzalez Change page title based on current page
- #4427: @josegonzalez Change process management doc references to make more sense
### Other
- #4438: @josegonzalez Split out nginx tests further to decrease overall CI runtime
- #4430: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 11.0.0 to 11.0.1 in /tests/apps/java
# History
## 0.23.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.7/bootstrap.sh
sudo DOKKU_TAG=v0.23.7 bash bootstrap.sh
```
### Bug Fixes
- #4421: @josegonzalez Keep the git directory for worktree-enabled installations
### New Features
- #4420: @josegonzalez Add ability to specify X-Forwarded-Ssl header for proxied requests
### Documentation
- #4422: @josegonzalez Add warning regarding shallow clone pushes
- #4417: @andrewk17 Correct vector sink example command
- #4414: @josegonzalez Use correct html for offsite digitalocean link
- #4413: @josegonzalez Fix SSL documentation link in troubleshooting docs
### Other
- #4423: @josegonzalez Drop unused sigil packaging code
- #4418: @josegonzalez Drop unused skip-restart flag for proxy:disable
Git worktrees do not include the full .git directory - only a pointer to the actual directory - when keep-git-dir is set to true, which is incorrect for built containers. This change special-cases that combination, allowing folks on newer git installs to actually keep the .git directory during the build process.
Closes#4415
There was a missing placeholder in the template string.
That caused that `%!(EXTRA string=...` is added to the crontab file which causes commands to fail.
Previously, checking if an app was deployed actually checked if there were any running processes. This is not only incorrect, but also fails to take into account applications that do not have running processes and are only used for one-off commands.
This fix migrates apps to the new "deployed" property which is set in core-post-deploy. The result is a slightly faster "deployed" check that is correct and allows non-scaled apps to actually work.
Closes#4398
# History
## 0.23.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.3/bootstrap.sh
sudo DOKKU_TAG=v0.23.3 bash bootstrap.sh
```
### Bug Fixes
- #4397: @josegonzalez Correctly handle environment variables in deployment tasks for Cloud Native Buildpacks
- #4394: @josegonzalez Swap order of arguments on config-get call
### New Features
- #4395: @josegonzalez Add environment variable support to CNB-based containers
### Refactors
- #4393: @josegonzalez Use docker-image-labeler in cnb builder-build trigger
### Documentation
- #4396: @nerg4l Invalid link to Herokuish Buildpack Deployment in Cloud Native Buildpacks
### Tests
- #4390: @josegonzalez Run tests faster by not cloning the buildpack each time
### Other
- #4389: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 188 to 189 in /tests/apps/php
This will allow dropping many of the "source config/functions" calls littered over the codebase. Plugin triggers are the way to perform cross-plugin communication :)
They are not baked into the image like they are for herokuish, so we need to manually set them via --env. Additionally, due to newline constraints in docker, we need to use `--env=key` format to correctly pull the values into place.
# History
## 0.23.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.2/bootstrap.sh
sudo DOKKU_TAG=v0.23.2 bash bootstrap.sh
```
### Bug Fixes
- #4388: @josegonzalez Do not inject max-size option when not using local or json-file log-drivers
- #4386: @josegonzalez Update to docker-image-labeler that handles in-use images
### New Features
- #4387: @josegonzalez Only warn if the vector container is stopped when fetching logs
- #4372: @josegonzalez Add ability to clear an individual resource
- #4384: @josegonzalez Add support for injected cron entries from external plugins
### Refactors
- #4373: @josegonzalez Do not attempt to extract Procfile in ps:scale
### Documentation
- #4377: @josegonzalez Add note about the dokku user cron being overwritten by Dokku
### Other
- #3757: @pickettd Add provision line to Windows Vagrant box for dokku-installer
This allows alternative plugins - such as dokku-letsencrypt - to inject scheduled cron tasks into the cron system used by Dokku. Cron systems can choose to include or not include a cron task based on the specified scheduler, and can also optionally use a third parameter to store arbitrary information.
The Procfile is now extracted in the pre-deploy step for every deploy and otherwise not removed. Thus, it should always exist when necessary - web will be scale to 1 automatically and it won't need to be present on future ps:scale calls since we'll have the scale file - and the command can execute faster.
# History
## 0.23.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.0/bootstrap.sh
sudo DOKKU_TAG=v0.23.0 bash bootstrap.sh
```
See the [0.23.0 migration guide](/docs/appendices/0.23.0-migration-guide.md) for more information on migrating to 0.23.0.
### Bug Fixes
- #4356: @josegonzalez Do not retag images unnecessarily
- #4355: @josegonzalez Allow underscores in vector schemes
- #4350: @josegonzalez Add missing trigger to events plugin
- #4348: @josegonzalez Correct app-specific shell handling
- #4333: @josegonzalez Drop tmpdir environment variables when not running as dokku user
### New Features
- #4336: @josegonzalez Add ability to manage stacks on an app or global level …
- #4354: @josegonzalez Log all triggers called by golang in trace output
- #4300: @AubreyHewes allow disabling hsts globally and explicitly enable per app
- #4337: @josegonzalez Add logrotation to container log files
- #4318: @josegonzalez Add ability to set client max body size via nginx:set
- #4343: @josegonzalez feat: add initial scheduled task implementation
- #4297: @josegonzalez Add support for cloning/syncing from a remote repository
- #4340: @bjornpost Allow configuring x-forwarded-* proxy headers via nginx:set
### Refactors
- #4349: @josegonzalez Remove need for internal dokku calls
### Documentation
- #4347: @fomojola Add post-deploy webhook to list of community plugins
- #4342: @AubreyHewes Point to current testing docs
- #4341: @josegonzalez Add testing link to contributing.md
### Tests
- #4352: @josegonzalez Add a test for application renames
- #4351: @josegonzalez Set hostname for CI runs
- #4322: @josegonzalez Switch to Github Actions for CI
### Other
- #4353: @josegonzalez Drop unused flag introduced by logs max-size feature
This change minimizes the work needed to be done when tagging images. It edits the image manifest directly only when necessary, allowing restarts of an app to avoid having an extra layer.
This also additionally allows to deploy images with ONBUILD directives without running the ONBUILD directives.
Lastly, users building docker images that run Dokku will need to use a new sudoer wrapper for the `docker-image-labeler` binary to work correctly. A reference version has been placed in the `docker` skeleton directory.
Closes#3931
Refs #4226
Trace mode is useful for shell code, but less so for golang. Adding debug logging in golang for trigger calls makes it a little easier to see what is happening.
The previous lever for manipulating this was the DOKKU_IMAGE environment variable. While this is all well and good, it only works for CNB and is yet another `DOKKU_*` environment variable that need not exist.
While this does not add support for manipulating the CNB stack just yet, the groundwork is set for the future.
Closes#4306
The default for an app is empty, meaning it will fallback to the global value (which defaults to true). This will allow users to properly override the global value, regardless of what it is.
This functionality enables users to manage a global crontab for the Dokku user that contains all scheduled tasks across all apps. Alternative schedulers can implement cron tasks as desired.
# History
## 0.22.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.9/bootstrap.sh
sudo DOKKU_TAG=v0.22.9 bash bootstrap.sh
```
### Bug Fixes
- #4334: @josegonzalez allow git pushes to apps that already exist but have old names
- #4335: @josegonzalez Add error checking to plugin:install and plugin:update
- #4338: @josegonzalez Strip trailing slashes in hostname from web installer
- #4332: @josegonzalez Correct aws release check in release-plugin script
- #4311: @nisseknudsen Allow named volume mounts in regex
- #4320: @josegonzalez Hardcode cnb workdir to /workspace
### New Features
- #4321: @josegonzalez Add git version to output
### Refactors
- #4329: @josegonzalez Standardize apt-get usage
### Documentation
- #4323: @stianlik Fix typo in nginx documentation
### Tests
- #4331: @josegonzalez Switch to upstream bats-core
- #4330: @josegonzalez Switch to using uuidgen for unique app names
### Other
- #4325: @WaviestBalloon Updated bootstrap.sh to not show when $DOKKU_TAG equals nothing
- #4324: @dependabot-preview[bot] chore(deps): bump socket.io from 3.0.5 to 3.1.0 in /tests/apps/.websocket.disabled
- #4319: @josegonzalez Update ruby dependencies in test app
- #4312: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 187 to 188 in /tests/apps/php
The web installer needs work to add proper validation of input, but for now, this change will ensure folks don't accidentally add an extra slash to the global domain.
Closes#4106
[ci skip]
This ensures that tmpdir (and related calls) respect the system defaults for temporary directory access. Critically, changing user via 'sudo' will leave the root temp directory in place, which causes dokku to have undefined behavior when writing to temporary files under libpam-tmpdir.
This may break cases where users have redefined tmpdir or related variables, but those cases can be remedied by specifying a value for TMPDIR (and related variables) in /etc/default/dokku.
Closes#3149
# History
## 0.22.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.8/bootstrap.sh
sudo DOKKU_TAG=v0.22.8 bash bootstrap.sh
```
### Bug Fixes
- #4309: @josegonzalez Correct issue where verifying an app name would bail early
### Documentation
- #4307: @josegonzalez Specify that the dokku logo is for non-commercial use
# History
## 0.22.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.6/bootstrap.sh
sudo DOKKU_TAG=v0.22.6 bash bootstrap.sh
```
### Bug Fixes
- #4295: @josegonzalez Update ps subcommands and triggers
### New Features
- #4286: @josegonzalez Add support for templated CHECKS files
- #4294: @josegonzalez Enhance ssh client logging output
- #4291: @josegonzalez Add log aggregation support via Vector
- #4288: @josegonzalez Add the pid of the dokku process to event logs
- #4289: @josegonzalez Clean precheck tmp file on exit
### Refactors
- #4287: @josegonzalez Refactor parallelized goroutines to use error groups
### Documentation
- #4292: @thomasfedb Update docs to note support for Ubuntu 20.04
- #4293: @ltalirz Fix path in persistent storage docs
### Other
- #4290: @josegonzalez Add support for debug logging plugin trigger stderr and stdout
Not all properties can be set globally, and the "appName" in the global case is currently defaulted to `--global`. This is okay because domain label names cannot start with hyphens, and all app names must be valid domain label names.
dburl adds aliases for everything, which breaks if two schemes are similar enough (anything with `aws_` as a prefix broke scheme registration). It does not appear to add anything, so we'll drop that dependency.
Also remove go-jsonmerge, as this was refactored to use structs instead of byte manipulation...
This is a fairly slow operation currently done serially, making ps:scale output brutally slow. Using an error group to parallelize the output is also pleasing to the eyes :)
Previously, this could get a bit hazy when running the command within a goroutine. The new method creates pipes for writing stdout/stderr for each call to PluginTriggerOutput, then debug logs if if trace mode is on.
While it is a bit weird to read, it is more correct and should get rid of any parallel processing issues.
# History
## 0.22.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.5/bootstrap.sh
sudo DOKKU_TAG=v0.22.5 bash bootstrap.sh
```
### Bug Fixes
- #4279: @josegonzalez Allow vmware-based vm to work on big sur
### Refactors
- #4282: @josegonzalez Cleanup brew-bump integration
- #4280: @josegonzalez Parallelize report and scheduler retrieval
### Documentation
- #4285: @josegonzalez Reference official gitlab-ci integration
- #4284: @josegonzalez Drop old doc link to gitlab ci docs
- #4283: @josegonzalez Add CI documentation section for Github Actions and Gitlab
- #4281: @josegonzalez Add forum link to documentation
In many cases, a user may only set a global scheduler, and as such we waste the initial call to get the app scheduler. Parallelizing the fetch increases the speed at which we can check for the scheduler.
# History
## 0.22.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.4/bootstrap.sh
sudo DOKKU_TAG=v0.22.4 bash bootstrap.sh
```
### Bug Fixes
- #4274: @josegonzalez Use correct warning message for deprecated code
### New Features
- #4273: @josegonzalez Upgrade to golang 1.15
### Refactors
- #4275: @josegonzalez Add calls to verify app name in subcommands
### Documentation
- #4272: @josegonzalez Correct help output for ssh-keys command
### Tests
- #4276: @josegonzalez Upgrade version of plugn used in tests
Moving verification of input to the earliest place is the best way to decrease the need to validate this further downstream.
Additionally, some of the existing checks were.... lacking :)
# History
## 0.22.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.3/bootstrap.sh
sudo DOKKU_TAG=v0.22.3 bash bootstrap.sh
```
### Bug Fixes
- #4268: @josegonzalez Properly parse flags for logs command
- #4264: @josegonzalez Correct argument handling when setting the `--app` flag
- #4252: @magikid Allow symbolic links for certificate and key files
### New Features
- #4270: @josegonzalez Allow renaming old applications to new format
- #4261: @josegonzalez Add remove by fingerprint and json format output to ssh-keys plugin
- #4262: @josegonzalez Improve ps:restore logging
- #4263: @josegonzalez Bump the dokku client formula on release
### Documentation
- #4253: @guettli Highlight the default build method used by Dokku
- #4250: @rlnd1 Update upgrading.md
- #4249: @guettli Fix typo in zero downtime docs
- #4247: @josegonzalez Clarify the domain name setting in the docs
### Tests
- #4269: @josegonzalez Rename duplicate test
- #4266: @josegonzalez Update junit test files when a bats retry is successful
- #4265: @josegonzalez Retry failing and skipped tests once
0.22.0 changed allowed values for app names, making it more difficult for users to fix their app names - you need to either downgrade+rename or recreate the app. The `apps:rename` command can now rename these old applications to the new standard.
Also drop some app name verification from internal commands. Duplicate verification doesn't help much, and though it isn't excessively slow, it does prevent us from running commands against old apps that exist.
Refs #4267
When setting the `--app` flag, there was a special case for the config plugin. This plugin used to take the `--no-restart` flag as the first argument - and still did until this change - resulting in an invalid call to the plugin subcommands. What is worse is that this functionality carried over to all other plugins as they were rewritten in golang, and thus the issue spread without us knowing.
The fix is to support GNU flag parsing rules, which Golang does not do by default (Because Of Reasons™). Switching to `github.com/spf13/pflag` fixes this issue, and also allows positional arguments to be placed wherever, even in the middle of flags.
Closes#4255
This corrects an issue where if a symbolic link was given to the
`certs:add` command, an error would be thrown even though the file was
valid.
Issue: #4251
# History
## 0.22.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.2/bootstrap.sh
sudo DOKKU_TAG=v0.22.2 bash bootstrap.sh
```
### Bug Fixes
- #4243: @josegonzalez Do not delete app when the app name is invalid
### New Features
- #4141: @josegonzalez Always initialize git repository
### Other
- #4244: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.5 to 1.26.0 in /tests/apps/php
This fixes issues where alternative tools that don't trigger the init via sshcommand - such as git-http-backend - are not able to setup applications correctly.
Note that those apps could always manually trigger git:initialize if desired, but if the app already exists, then this should already _just work_ without that extra initialization.
# History
## 0.22.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.1/bootstrap.sh
sudo DOKKU_TAG=v0.22.1 bash bootstrap.sh
```
### Bug Fixes
- #4238: @josegonzalez Ensure dead files are created for docker object retirement
- #4239: @josegonzalez Ensure all byte output is trimmed of whitespace
- #4228: @Cellane Fix tags:deploy command for images that contain ONBUILD directive
- #4233: @josegonzalez Properly parse releease command when there is an entrypoint
- #4215: @josegonzalez Implement missing cleanup routines
- #4212: @josegonzalez Cleanup docker options during post-delete
- #4211: @ml-milan-vit Make the dokku-update command compatible with Dokku 0.22+
### New Features
- #4242: @josegonzalez Remove reference to 'whitelist'
- #4220: @josegonzalez Update plugn from 0.5.0 to 0.5.1
- #4241: @josegonzalez Properly handle stdout when capturing plugn output
- #4237: @josegonzalez Release dokku-update 0.2.0
- #4225: @znz Accept first pushed branch as deploy-branch
### Documentation
- #4236: @josegonzalez Remove note regarding not having an official client
- #4234: @josegonzalez Switch to bats --filter for running a single test
- #4222: @leopolicastro Fix typo in deployment tasks documentation
- #4221: @srr013 Updating readme for clarity on git push step
- #4214: @josegonzalez Expand backup and restore documentation
- #4213: @josegonzalez Enhance the 'plugin' plugin documentation
### Tests
- #4218: @josegonzalez Enable compilation cache
### Other
- #4230: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 186 to 187 in /tests/apps/php
- #4223: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.35.v20201120 to 11.0.0 in /tests/apps/java
- #4224: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 185 to 186 in /tests/apps/php
The previous output would also include a message like `exit status 1`. This allows us to silence that output and instead only capture that which was return from the subprocess.
This documentation should fill the need for users that wish to backup and restore their installations. While there are certainly other methods to trigger this process - and many caveats - this should give users more confidence as to how to approach the general problem.
Closes#4180
# History
## 0.22.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.22.0/bootstrap.sh
sudo DOKKU_TAG=v0.22.0 bash bootstrap.sh
```
See the [0.22.0 migration guide](/docs/appendices/0.22.0-migration-guide.md) for more information on migrating to 0.22.0.
### Bug Fixes
- #4204: @josegonzalez Ensure the image is not an empty string
- #4198: @josegonzalez Reference extracted Procfile
- #4194: @josegonzalez Drop appName check in apps:report
- #4183: @josegonzalez Embed pb.UnimplementedGreeterServer to avoid linting issues
- #4182: @josegonzalez Upgrade herokuish to fix nodejs tests
- #4173: @karimsan Add build-essential to Vagrant provision
- #4181: @josegonzalez Conditionally mount the dokku-arch folder if it exists
- #4130: @josegonzalez Clear proxy configs on boot
- #4131: @josegonzalez Bump minimum docker version
- #4123: @fomojola Support for expected CHECKS text with special characters
- #4115: @josegonzalez Add missing labels to built images
- #4116: @Schlepptop Ensure config:clear an be called
### New Features
- #4209: @josegonzalez Add experimental support for Cloud Native Buildpacks (CNB)
- #4210: @josegonzalez Add migration guide link to release notes
- #4203: @josegonzalez Cleanup log output for failure case
- #4208: @ankane Add ability to change the access log format
- #4202: @josegonzalez Schedule related images for cleanup when retiring containers
- #4197: @josegonzalez Retire intermediate containers after use
- #4128: @fomojola Added the container index to the network-compute-ports trigger
- #4191: @josegonzalez Create codeql-analysis.yml
- #4139: @Yihao-G Allow controlling Nginx proxy-buffer-size, proxy-buffering, proxy-buffers, proxy-busy-buffers-size
- #4156: @ltalirz When `cert:add` remove previous cert before copying the new cert
- #4129: @josegonzalez Prohibit non-dns names for apps and process types
- #4125: @josegonzalez Allow customizing the various nginx templates
- #4121: @josegonzalez Add ability to disable custom ninx.conf.sigil extraction
### Refactors
- #4160: @nerg4l Rewrite logs plugin in Go
- #4149: @josegonzalez Rewrite ps plugin in golang
- #4080: @hugopeixoto Stop using VHOST when listing app domains and urls
- #4117: @josegonzalez Rewrite app-json plugin in golang
- #4113: @josegonzalez Drop herokuish release code
### Documentation
- #4196: @josegonzalez Correctly doc apps:report output
- #4195: @luizpicolo Fix whitespace in process-management docs
- #4184: @badsyntax Add note regarding using plugin triggers instead of sourcing functions
- #4188: @fomojola Added the autosync community plugin
- #4187: @nahtnam Add `-p` flag to "Run on External Volume" tutorial
- #4186: @badsyntax Add dokku-discourse to community plugins list
- #4170: @chrisjsimpson Add note on how to enable buildkit usage
- #4168: @josegonzalez Revert "The default branch for ruby-getting-started is 'main', not 'master"
- #4167: @nateww The default branch for ruby-getting-started is 'main', not 'master
- #4135: @znz Fix broken table
- #4140: @swrobel Note Ubuntu 20.04 support in README
- #4136: @hugopeixoto Update push command for sample app in docs
- #4124: @josegonzalez Note that docker options require app rebuilds
- #4098: @carlosgeos Add a note on how nginx handles load balancing
- #4111: @josegonzalez Add large version of dokku image
- #4100: @turicas Fix markdown syntax in nginx docs
### Other
- #4201: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.34.v20201102 to 9.4.35.v20201120 in /tests/apps/java
- #4200: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 183 to 185 in /tests/apps/php
- #4189: @dependabot-preview[bot] chore(deps): bump thin from 1.7.2 to 1.8.0 in /tests/apps/ruby
- #4175: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.33.v20201020 to 9.4.34.v20201102 in /tests/apps/java
- #4172: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.2 to 1.4.3 in /tests/apps/gogrpc
- #4185: @dependabot-preview[bot] chore(deps): bump socket.io from 2.3.0 to 3.0.1 in /tests/apps/.websocket.disabled
- #4190: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 182 to 183 in /tests/apps/php
- #4165: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.31.v20200723 to 9.4.33.v20201020 in /tests/apps/java
- #4153: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 181 to 182 in /tests/apps/php
- #4144: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 180 to 181 in /tests/apps/php
- #4137: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 179 to 180 in /tests/apps/php
- #4118: @dependabot[bot] chore(deps): bump django from 3.0.2 to 3.0.7 in /tests/apps/dockerfile-release
- #4103: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 178 to 179 in /tests/apps/php
- #4091: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.30.v20200611 to 9.4.31.v20200723 in /tests/apps/java
This change adds a new builder - builder-cnb - via the 'DOKKU_CNB_EXPERIMENTAL' environment variable. While support for customizing pack builds is not currently implemented and there may be other missing functionality, this initial implementation allows folks to start playing with CNB.
Future releases of Dokku will provide tighter CNB integration and eventually switch to CNB for default building, as well as allow users to better select builders needed for their applications.
All new code for CNB support should be considered experimental and subject to change as the support evolves over time.
If the containers no longer exist and the images are unused, we should remove the images as well.
Note that images may sometimes stick around for a little while, depending on the retire schedule and the wait time specified for the container.
Closes#4104
Rather than attempting to always extract the Procfile, reference the one that was extracted by the last deploy. This fixes issues where 'docker container cp' may fail intermittently for lord knows what reason.
Closes#4083
Rather than waiting for the next deploy, take advantage of the retire system to retire these containers immediately.
Note that since the retire process happens out of band, the containers may stick around for up to 5 minutes, after which point they will be removed.
Customization of the wait time to retire - currently 60 seconds - is up for future debate. The containers ultimately haven't been useful for debugging, so keeping them around for longer won't help in most cases, and folks can disable the dokku-retire service (or cron) if that is desired.
There are other places in the codebase that currently act on all apps or could benefit from being able to do so. Being able to run `common.RunCommandAgainstAllApps()` and get that for free will be a boon to implementing this functionality elsewhere.
Better would be to separate the release and deploy aspects into distinct triggers - as well as have it release a specific image - but this is a good first pass.
This fixes when a user (or plugin) has replaced the cert with a symlink; else the symlinked file would be overwritten.
This mainly is in the case of a global-cert (plugin) wildcard cert
Heroku's ruby project changed its default branch from master to main.
This broke the examples in the documentation. This change explicitly
names main and master.
Unfortunately, Docker does not persist container IPs on boot, so containers may come up with the wrong IP, resulting in proxying to the incorrect app after a server restart. Instead, we should delete the configs and let ps:restore rebuild the proxy config correctly.
Closes#3932
This is necessary for ensuring ssl certificates can be auto-retrieved for apps, and also easing integration into schedulers that use names and process types as part of DNS records.
As well, this fixes an issue where we may potentially have invalid DNS entries when adding apps to custom networks.
Closes#4102Closes#4114
Dokku internals shouldn't be exposed in docs. Additionally, the internals here are likely to change in the future as this moves to the upcoming prop binary, so having incorrect docs will hinder that move.
Added a quote around the "$EXPECTED" to deal with text with restricted characters. While deploying a Spring Boot application, the content of the built-in health check is {"status":"UP"}. Unfortunately all my checks failed, because for some reason the comparison didn't like this content.
remote: ! http://localhost/actuator/health: expected to but did not find: "{"status":"UP"}"
remote: ! Check attempt 7/10 failed.
After making this change, it works: I'm assuming the difference is that the presence of the quote characters in the content.
This fixes an issue where disk space is not recouped after deploys unless 'dokku cleanup' without arguments is called.
Also injects the label-schema labels as necessary.
Refs #4099
Previous versions extracted the values as strings, prefixing the values with `/bin/sh -c '$CMD'` unnecessarily. This caused issues where we would incorrectly overrride these values when an app had a predeploy script.
Closes#3143
# History
## 0.21.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.4/bootstrap.sh
sudo DOKKU_TAG=v0.21.4 bash bootstrap.sh
```
### Bug Fixes
- #4092: @Yihao-G Fix nginx proxy-read-timeout not set for HTTPS
- #4095: @GennadySpb Fix application removal during uninstallation
### New Features
- #4097: @josegonzalez Update herokuish
### Documentation
- #4096: @josegonzalez Clarify that special config variables are not exposed to applications
- #4007: @turicas Clarify nginx.conf.sigil path in image when deploying non-buildpack apps
- #4078: @gurpreetatwal Add more details to `nginx-dokku-template-source` trigger
- #4090: @ankane Official plugins no longer in beta
- #4085: @josegonzalez Set warning on resource type as an actual warning
### Other
- #4082: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.4 to 1.25.5 in /tests/apps/php
# History
## 0.21.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.3/bootstrap.sh
sudo DOKKU_TAG=v0.21.3 bash bootstrap.sh
```
### Bug Fixes
- #4077: @Schlepptop Fix config_all bug introduced in 0.21.2
- #4074: @josegonzalez Force set all plugin permissions on plugin:install/update
### Documentation
- #4073: @josegonzalez Document the official shell client
# History
## 0.21.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.2/bootstrap.sh
sudo DOKKU_TAG=v0.21.2 bash bootstrap.sh
```
### Bug Fixes
- #4072: @Schlepptop Fix deprecation warning in config_all
### New Features
- #4061: @josegonzalez Drop go sum and mod files from releases
### Refactors
- #4064: @hugopeixoto Use *_PATH consistently
### Documentation
- #4069: @josegonzalez Scheduler plugins are no longer beta
- #4068: @josegonzalez Official plugins are no longer in beta
- #4066: @ltalirz Add ansible as installation route
- #4063: @josegonzalez Clarify why we stop/rebuild apps during upgrade
- #4040: @fonsp Added link to the buildpack plugin docs
- #4062: @hugopeixoto Rewrite upgrade instructions
GLOBAL_VHOST_PATH and GLOBAL_VHOST_FILE were used to represent the same
thing. Same for APP_URLS_PATH and APP_VHOST_PATH.
This normalizes all of those to _PATH.
# History
## 0.21.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.0/bootstrap.sh
sudo DOKKU_TAG=v0.21.0 bash bootstrap.sh
```
### Bug Fixes
- #4058: @hugopeixoto Ensure web installer creates files with correct permissions
- #4055: @hugopeixoto Delete dokkurc recursively during uninstall
- #4057: @hugopeixoto Install sudo when installing from source
- #4045: @josegonzalez Filter gpus instead of nvidia-gpus from resource arguments
- #4029: @josegonzalez Filter args _after_ docker-args-process-deploy
- #4026: @josegonzalez Filter resource args from deploy tasks
- #4022: @josegonzalez Do not allow slashes in app names
- #4020: @josegonzalez Properly handle multiple containers in ps:inspect
- #3989: @josegonzalez Correct entering running containers
- #3977: @josegonzalez Set default port for all run commands
- #3969: @josegonzalez Do not logrotate all services files
- #3964: @josegonzalez Remove all --force-yes usage throughout the codebase
- #3955: @benwh Fix missing 502 error page
- #3953: @josegonzalez Use correct function name for cmd-tar-in and update migration guide
### New Features
- #4041: @rvanlaar feat: Add download option to the certs plugin
- #4043: @josegonzalez Allow controlling nginx proxy-read-timeout
- #4038: @josegonzalez Create proxy:build-config command
- #4021: @josegonzalez Depend on python3 binary for CentOS 8 support
- #4004: @josegonzalez Add support for moby-engine
- #3967: @josegonzalez Add Ubuntu 20.04 support
- #3988: @josegonzalez Upgrade plugn to 0.5.0
- #3987: @josegonzalez Upgrade sigil to 0.6.0
- #3986: @josegonzalez Upgrade sshcommand to 0.11.0
- #3985: @josegonzalez Upgrade go-procfile-util to 0.8.2
- #3982: @josegonzalez Allow apps named tls
- #3979: @josegonzalez Upgrade herokuish
- #3971: @josegonzalez feat: allow users to customize the source of the dokku.conf nginx template
- #3966: @josegonzalez Move domain manipulation into triggers
- #3965: @josegonzalez Drop dokku references in logging output
- #3954: @josegonzalez feat: upgrade herokuish to 0.5.12
- #3940: @josegonzalez Expose last updated time in git:report
- #3939: @josegonzalez Add support for outputting the last visited time
### Refactors
- #4035: @josegonzalez Switch to go mod
- #4008: @josegonzalez Standardize golang command code
### Documentation
- #4056: @swrobel Remove invalid help entry for dokku ps commmand
- #4039: @josegonzalez Break out bc-break and refactors in changelog
- #4025: @alexjj Switch AUR helper to yay
- #4019: @tdak Added one possible solution to an error
- #4014: @rvanlaar Update dreamhost cloudinit script
- #4003: @josegonzalez Add dokku.ai asset
- #3999: @DavidLemayian Update URL for less than 1gb memory in bootstrap.sh [ci skip]
- #3998: @josegonzalez Document the #dokku channel on slack
- #3996: @josegonzalez Clarify network aliases and add section on tld management
- #3980: @josegonzalez Clarify that the web installer is not supported in docker-based installs
- #3970: @josegonzalez Clarify the 'see the docs' internal links
- #3968: @josegonzalez Document access.conf issue
- #3957: @swrobel Add official registry plugin
- #3942: @scowalt Fix grammar in environment variables documentation
### Tests
- #4046: @rvanlaar Make `make test` pass on linting
- #4037: @josegonzalez Try to output oomkill information
- #4036: @josegonzalez Store the deb and rpm artifacts
- #4034: @josegonzalez Teardown apps and containers in global teardown
- #4031: @josegonzalez Delete old apps and ensure the test helper is quieter
- #4030: @josegonzalez Update circleci workflow
- #3947: @jayjun Scope init tests to container processes only
### Other
- #4051: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 177 to 178 in /tests/apps/php
- #4028: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 176 to 177 in /tests/apps/php
- #4016: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.29.v20200521 to 9.4.30.v20200611 in /tests/apps/java
- #4006: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 174 to 176 in /tests/apps/php
- #4001: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.28.v20200408 to 9.4.29.v20200521 in /tests/apps/java
- #4002: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.3 to 1.25.4 in /tests/apps/php
- #3993: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.1 to 1.4.2 in /tests/apps/gogrpc
- #3962: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.0 to 1.4.1 in /tests/apps/gogrpc
- #3959: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 173 to 174 in /tests/apps/php
- #3950: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.29.0 to 1.29.1 in /tests/apps/gogrpc
- #3946: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.1 to 1.29.0 in /tests/apps/gogrpc
The 'server.key' and 'server.crt' can printed to stdin.
The two options are:
`dokku certs:show <app> key > server.key`
`dokku certs:show <app> crt > server.crt`
This will create two files, `server.key` and `server.crt`.
Those files contain the private key and the certificate.
Includes tests.
This hopefully makes it a little easier to work with as the tooling is now based on something in golang core.
- move columnize usage to common plugin
- remove old vendor files
There is likely a better regex for the actually allowed names, but this will suffice for ensuring folks don't do weird things with their folder structures...
Closes#4013
Bring configuration in line with the latest Cloud init verison. Tested under 20.1.
Mainly done due to `debconf_selections` not working with the old syntac.
See the `debconf_selections` item under https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure
Changes include:
- reboot when apt deems it necessary,
- define update and upgrade with the package syntax,
- bring apt sources and keys inline with apt syntax and
- dynamically get the right release by using the var '$RELEASE'.
[ci skip]
This cloudinit script had become outdated.
Changed 4 things:
- docker repository had moved
- use current docker gpg key
- use current dokku gpg key
- move over to ubuntu focal LTS 20.20
This functionality was broken due to a refactor of argument handling in a previous release.
In addition to the fix, all the functionality was moved to scheduler-enter, which allows scheduler plugins to implement ways of entering containers in the relevant scheduler.
Closes#3972
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
These are usually not optional and actually explain what a user is interested in. As we don't have documentation partials, duplication isn't in favor of the project maintainer's benefit.
Closes#3927
In dokku/dokku#3602 a new error page for the 502 status code was
introduced.
However, this error page is not currently being used, and results in a
404 error being served instead, because nginx is trying to load a
non-existent file:
```
open() "/var/lib/dokku/data/nginx-vhosts/dokku-errors/502-error.html" failed (2: No such file or directory)
```
Fix this by copying the `502-error.html` file into the `dokku-errors`
directory upon installation.
# History
## 0.20.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.4/bootstrap.sh
sudo DOKKU_TAG=v0.20.4 bash bootstrap.sh
```
### New Features
- #3936: @josegonzalez Enable limiting and reserving gpu resources
### Documentation
- #3937: @josegonzalez Add minor documentation for the kubernetes and nomad schedulers
### Other
- #3935: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.11.1 to 2.11.2 in /tests/apps/python-flask
- #3934: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.5 to 1.4.0 in /tests/apps/gogrpc
- #3933: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.27.v20200227 to 9.4.28.v20200408 in /tests/apps/java
# History
## 0.20.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.3/bootstrap.sh
sudo DOKKU_TAG=v0.20.3 bash bootstrap.sh
```
### New Features
- #3926: @josegonzalez Add proper support for various buildpack urls
### Other
- #3928: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.0 to 1.28.1 in /tests/apps/gogrpc
- #3925: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/python-flask
- #3924: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/multi
# History
## 0.20.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.2/bootstrap.sh
sudo DOKKU_TAG=v0.20.2 bash bootstrap.sh
```
### Bug Fixes
- #3921: @josegonzalez Correct container_type handling when entering containers
- #3919: @josegonzalez Fix bug with restarting containers not being routed to because of changing IP addresses
### New Features
- #3920: @josegonzalez Add the ability to list ssh keys for a specific user
# History
## 0.20.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.1/bootstrap.sh
sudo DOKKU_TAG=v0.20.1 bash bootstrap.sh
```
### Bug Fixes
- #3916: @josegonzalez Change error exit to warning when no apps exist
### New Features
- #3918: @josegonzalez Upgrade herokuish to 0.5.11
- #3915: @josegonzalez Add ability to check if a plugin has been installed
- #3914: @josegonzalez Add ability to change or disable the access/error log path
- #3913: @josegonzalez Upgrade herokuish
### Documentation
- #3907: @josegonzalez Add sponsoring link to issue template
- #3904: @jazzzz Update dokku-apt entry
- #3902: @josegonzalez Remove extra commas from network docs
### Other
- #3909: @dependabot-preview[bot] chore(deps): bump werkzeug from 1.0.0 to 1.0.1 in /tests/apps/python-flask
- #3903: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 172 to 173 in /tests/apps/php
# History
## 0.20.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.0/bootstrap.sh
sudo DOKKU_TAG=v0.20.0 bash bootstrap.sh
```
### Bug Fixes
- #3891: @josegonzalez Add missing cpio dependency
- #3861: @josegonzalez Fix app clone and rename calls
- #3682: @josegonzalez Force tty check to run with the default language
- #3853: @josegonzalez Add missing hooks to events plugin
### New Features
- #3899: @josegonzalez Drop unnecessary quotes on docker inspect calls
- #3895: @josegonzalez Expose network listeners to nginx templates for all process types
- #3893: @josegonzalez Rewrite apps plugin in golang
- #3889: @josegonzalez Update herokuish
- #3879: @josegonzalez Drop support for unsupported Debian and Ubuntu releases …
- #3880: @josegonzalez Remove unnecessary source/import statements
- #3871: @josegonzalez Rewrite proxy plugin in golang
- #3869: @josegonzalez Standardize plugin trigger calls
- #3870: @josegonzalez Use Println in favor of Fprintln for os.Stdout
- #3868: @josegonzalez Remove ps command
- #3866: @josegonzalez Unify nginx config commands
- #3865: @josegonzalez Cleanup injected docker labels
- #3860: @josegonzalez Remove deprecated egrep calls from codebase
- #3854: @josegonzalez Remove deprecated code
- #3852: @josegonzalez Standardize plugin code
- #3850: @josegonzalez DRY up reports in golang
- #3851: @josegonzalez Update herokuish to 0.5.6
- #3847: @josegonzalez Custom docker networking
- #3848: @josegonzalez Minor logging changes
- #3843: @josegonzalez Enable HSTS by default
- #3844: @josegonzalez Add global fallback for DOKKU_PROXY_PORT and DOKKU_PROXY_SSL_PORT
- #3609: @jayjun Start long running containers with --init with tests
- #3842: @josegonzalez rework docker-args-process trigger arguments
- #3841: @josegonzalez Implement docker-options:clear
### Documentation
- #3901: @Cellane 📝 Update information about Dokku CLI installation
- #3892: @josegonzalez Move code of conduct to .github org repository
- #3888: @decentral1se Mark 9+ for Debian version
- #3874: @josegonzalez Push users to upgrade to recent versions
- #3864: @alex-galey Change docs copyright to 2020
- #3863: @josegonzalez Update issue template to remove ambiguity around reporting
- #3849: @josegonzalez Reference correct property in network docs example
- #3840: @ollej Add link to fonts plugin
- #3838: @ltalirz Expand docs surrounding access control
### Other
- #3897: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.4 to 1.3.5 in /tests/apps/gogrpc
- #3896: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 3.1.1 to 3.1.2 in /tests/apps/java
- #3894: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.1 to 1.28.0 in /tests/apps/gogrpc
- #3885: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 171 to 172 in /tests/apps/php
- #3884: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.26.v20200117 to 9.4.27.v20200227 in /tests/apps/java
- #3877: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.3 to 1.3.4 in /tests/apps/gogrpc
- #3858: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 170 to 171 in /tests/apps/php
- #3855: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 169 to 170 in /tests/apps/php
- #3846: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.1 to 1.0.0 in /tests/apps/python-flask
- #3845: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.0 to 1.27.1 in /tests/apps/gogrpc
- #3833: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.26.0 to 1.27.0 in /tests/apps/gogrpc
- #3837: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.3 to 2.11.1 in /tests/apps/python-flask
- #3836: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.2 to 1.3.3 in /tests/apps/gogrpc
- #3829: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.0 to 0.16.1 in /tests/apps/python-flask
- #3830: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 166 to 169 in /tests/apps/php
This change allows users to specify a custom nginx.conf.sigil that can expose non-web process types to the outside world in addition to the web process type.
Closes#3258
A git push requires that the first four bytes should be the line length, so not suppressing the output results in a partially failed deploy.
https://stackoverflow.com/a/8175315/1515875
While the latest packages may continue to work on other releases, we will no longer officially support these releases, nor will we distribute packages.
Supporting versions more than a year old is difficult with a quick-moving project, and not worth the time that could be better spent fixing existing bugs/adding new functionality for an OSS project.
This change removes all deprecated commands. In many cases, users have been warned for a number of releases before the commands have been removed. All commands that were removed have existing alternatives.
This standardization makes it somewhat easier to read stacktraces as the command names are all uniform, so it will be slightly easier to scan trace output.
This unifies all the report-handling code so that plugins only need to worry about the data they wish to represent, and not the logic of actually returning it.
Containers can be attached:
- after they are created, but before they are started
- after a successful deploy, but before the proxy reloads
This allows folks to have flexibility around when they would like a container to be made available to a network.
This enables the HSTS header by default when an SSL certificate is in use. HSTS options can also be managed via the nginx:set command, which also exposes the ability to disable HSTS for your application.
The IMAGE_TAG is not always available, while the IMAGE_SOURCE_TYPE is. Since the point of these triggers was to unify the argument passed and make it easier to interact with them, this version makes more sense.
Closes#3780
The deployment documentation on scoping user access pointed only to the
development documentation for implementing plugins to handle user
scoping.
Added link to the dokku-acl plugin, which already handles user scoping
out of the box.
# History
## 0.19.12
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.12/bootstrap.sh
sudo DOKKU_TAG=v0.19.12 bash bootstrap.sh
```
### New Features
- #3819: @josegonzalez Allow binding nginx to specific IPv4/IPv6 interfaces
- #3818: @josegonzalez Add support for host-mode networking
### Documentation
- #3814: @treyssatvincent Use dokku:report to for listing domains
- #3809: @josegonzalez Document nginx:show-conf
- #3650: @vincelwt Clarify resource management for docker-local scheduler
- #3806: @kimar Make default vhost example listen to ipv6
### Other
- #3816: @dependabot-preview[bot] chore(deps): bump handlebars from 4.6.0 to 4.7.1 in /tests/apps/.websocket.disabled
- #3815: @dependabot-preview[bot] chore(deps): bump handlebars from 4.5.3 to 4.6.0 in /tests/apps/.websocket.disabled
- #3811: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 165 to 166 in /tests/apps/php
- #3812: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.24.v20191120 to 9.4.25.v20191220 in /tests/apps/java
- #3810: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.2 to 1.25.3 in /tests/apps/php
- #3808: @dependabot-preview[bot] chore(deps): [security] bump rack from 1.6.11 to 1.6.12 in /tests/apps/ruby
- #3807: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.1 to 1.26.0 in /tests/apps/gogrpc
- #3804: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 164 to 165 in /tests/apps/php
In host-mode, there is no 'bridge' network by default, so we return an invalid IP address of 'no value'. Instead, return '127.0.0.1' for those containers.
As there can be custom schedulers, including scheduler-specific information on the resource management page can be a disingenuous - the values don't map to kubernetes, for example - and thus we should call out to the scheduler docs (and underlying docker docs) to make the mapping more clear.
# History
## 0.19.10
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.10/bootstrap.sh
sudo DOKKU_TAG=v0.19.10 bash bootstrap.sh
```
### Bug Fixes
- #3784: @josegonzalez Ensure checks attempts are tracked per-check instead of globally
### New Features
- #3793: @josegonzalez Omit DWARF symbol table and debug information from go binaries
- #3792: @josegonzalez Unify property function implementations
### Documentation
- #3712: @fruitl00p Added new plugin
### Other
- #3790: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/python-flask
- #3791: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/multi
- #3787: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/multi
- #3788: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/python-flask
- #3785: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/python-flask
- #3786: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/multi
- #3748: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-dokku-scale
- #3749: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noappjson
- #3747: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/config
- #3746: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile
- #3741: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express
- #3783: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.23.v20191118 to 9.4.24.v20191120 in /tests/apps/java
- #3777: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 3.4.32 to 3.4.35 in /tests/apps/php
- #3774: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/python-flask
- #3779: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.1 to 1.25.2 in /tests/apps/php
- #3782: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.22.v20191022 to 9.4.23.v20191118 in /tests/apps/java
This will reduce the size of binaries in exchange for worse debugging output. This is acceptable for our users and worth it to save money on packagecloud package hosting - which is currently free under a given repository size.
Rather than reimplementing the property functions in two different languages - and potentially having compatibility issues - standardize on golang for the implementation through the use of a generated binary.
This also implements all the list functions for use with shell-based plugins.
Note that the interface to the prop binary is experimental, and it should not be used directly.
# History
## 0.19.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.9/bootstrap.sh
sudo DOKKU_TAG=v0.19.9 bash bootstrap.sh
```
### Bug Fixes
- #3781: @michaelshobbs Respect DOKKU_APP_USER in is_image_herokuish_based
### Other
- #3773: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.0 to 1.25.1 in /tests/apps/gogrpc
- #3772: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/multi
- #3778: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 3.4.32 to 3.4.35 in /tests/apps/php
- #3768: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.24.0 to 1.25.0 in /tests/apps/gogrpc
# History
## 0.19.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.7/bootstrap.sh
sudo DOKKU_TAG=v0.19.7 bash bootstrap.sh
```
### Documentation
- #3765: @znz Fix typo in desc of is_tls13_available
### Other
- #3739: @safeforge dokku run do not supports interactive mode.
- #3762: @dependabot-preview[bot] chore(deps): bump handlebars from 4.4.5 to 4.5.1 in /tests/apps/.websocket.disabled
# History
## 0.19.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.6/bootstrap.sh
sudo DOKKU_TAG=v0.19.6 bash bootstrap.sh
```
### Other
- #3761: @pithyless Fix type-errors in dokku-installer.py
- #3759: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 163 to 164 in /tests/apps/php
- #3758: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.21.v20190926 to 9.4.22.v20191022 in /tests/apps/java
# History
## 0.19.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.3/bootstrap.sh
sudo DOKKU_TAG=v0.19.3 bash bootstrap.sh
```
### Bug Fixes
- #3753: @josegonzalez Always use python3 for the installer
### Other
- #3743: @dependabot-preview[bot] chore(deps): [security] bump express from 3.1.2 to 4.17.1 in /tests/apps/.websocket.disabled
- #3744: @dependabot-preview[bot] chore(deps): [security] bump handlebars from 1.0.12 to 4.4.5 in /tests/apps/.websocket.disabled
- #3750: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile-bad
- #3745: @dependabot-preview[bot] chore(deps): [security] bump express from 3.3.8 to 4.17.1 in /tests/apps/gitsubmodules
- #3742: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noprocfile
- #3729: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.12.0 to 1.25.1 in /tests/apps/php
- #3732: @dependabot-preview[bot] chore(deps): bump silex/silex from 1.2.3 to 2.2.4 in /tests/apps/php
- #3728: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 7.6.0.v20120127 to 9.4.21.v20190926 in /tests/apps/java
- #3730: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.15.6 to 0.16.0 in /tests/apps/python-flask
- #3737: @dependabot-preview[bot] chore(deps): bump express3-handlebars from 0.2.3 to 0.5.2 in /tests/apps/.websocket.disabled
- #3734: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 59 to 163 in /tests/apps/php
- #3735: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 2.6.4 to 2.8.51 in /tests/apps/php
- #3723: @dependabot-preview[bot] chore(deps): bump sass-globbing from 1.1.1 to 1.1.5 in /tests/apps/multi
- #3731: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.1 to 2.10.3 in /tests/apps/python-flask
- #3736: @dependabot-preview[bot] chore(deps): bump socket.io from 0.9.19 to 2.3.0 in /tests/apps/.websocket.disabled
- #3726: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.23.0 to 1.24.0 in /tests/apps/gogrpc
- #3727: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 2.4 to 3.1.1 in /tests/apps/java
- #3733: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 2.6.4 to 2.8.50 in /tests/apps/php
- #3720: @dependabot-preview[bot] chore(deps): bump compass from 1.0.1 to 1.0.3 in /tests/apps/multi
- #3721: @dependabot-preview[bot] chore(deps): bump sinatra from 1.4.4 to 1.4.8 in /tests/apps/ruby
- #3719: @dependabot-preview[bot] chore(deps): bump thin from 1.6.1 to 1.7.2 in /tests/apps/ruby
This actually breaks compatability since now we drop python2 support completely, but it's worth it to fix the weird issues with trying to support both versions.
Closes#3740Closes#3752
Refs #3717
Ideally python usage goes away - the dokku-installer should become a mandatory cli command, and the plugin is rewritten in golang - but for now, we need to use the correct binary when running dokku.
Closes#3714
This adds the Nginx Trust Proxy plugin
This plugin allows dokku to be run behind (multiple) proxies in and gives developers the opportunity to support reverse proxy layers
After a `dokku run` container is created and started, this plugin trigger will allow developers to run auxiliary commands in response to that container.
This feature is allows users to add extra label metadata to one-off containers. As this can interfere with Dokku internals if they shadow labels used by plugins, care should be taken to avoid the `com.dokku` or `org.label-schema` namespace.
Also proper name run containers so they don't get random names from docker...
This change allows supporting the openresty package as installed on Ubuntu 18.04 from the official openresty package repository, while also returning general nginx support.
Closes#3675
It may be desirable to keep the contents of the git directory for the build process. Certain build tools can extract extra information from the .git directory, and some workflows may require that the shipped artifact has the entire source code available locally for later usage.
This change refactors the compiled golang plugins into 3 distinct binaries:
- commands: already existing
- subcommands/subcommands: entrypoint into all subcommands
- triggers: entrypoint into all triggers
It then further symlinks triggers and subcommands to the built binaries. This results in both a much faster build process as well as smaller package size.
This PR uses the new syntax for commands introduced in Docker 1.13, making it a bit easier to understand just what a particular command is trying to do.
This also pushes the long-form syntax for docker command flags, which are also easier to understand at a glance.
The version in DOKKU_ROOT may be incorrect for docker-based installs if that directory is mounted from an external volume. Instead, pull it from the DOKKU_LIB_ROOT directory, and respect the STABLE_VERSION if specified (VERSION will be the entire version, including commit sha).
This will allow background processes to cleanup these files if they were unable to be cleaned up during a run of the dokku binary, as is the case for files copied by the docker binary when running in docker.
This will allow those triggers to insert and extract files from the sourcecode work directory. Note that changes are not committed to this directory, nor will they be reflected in the committed codebase.
# History
## 0.18.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.1/bootstrap.sh
sudo DOKKU_TAG=v0.18.1 bash bootstrap.sh
```
### New Features
- #3636: @josegonzalez Unify deb and rpm creation code
- #3635: @josegonzalez Upgrade herokuish to 0.5.2
# History
## 0.18.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.0/bootstrap.sh
sudo DOKKU_TAG=v0.18.0 bash bootstrap.sh
```
### Bug Fixes
- #3627: @josegonzalez Make image removal synchronous
- #3618: @josegonzalez Ensure the dokku-retire timer is properly installed
- #3614: @alexquick Validate args for config:set and config:unset
- #3605: @josegonzalez Handle case where there are empty newlines in the authorized_keys file
- #3603: @josegonzalez Drop extra % sign in common.LogVerboseQuiet
- #3597: @josegonzalez Allow default trace function to work
### New Features
- #3628: @josegonzalez Handle file copying in a secure and reliable fashion
- #3630: @josegonzalez Fix issue where push warning on bad branch was skipped
- #3629: @josegonzalez Avoid calling the user-auth trigger where possible
- #3626: @josegonzalez Builder plugins
- #3599: @josegonzalez Scope docker-cleanup to specific app
- #3589: @michaelshobbs Allow running Dokku in Docker
- #3607: @josegonzalez Purge cache using herokuish image
- #3602: @alexymik Create a 502 error page to automatically refresh if backend status changes
- #3600: @josegonzalez Refactor IsImageHerokuishBased to match shell version
### Documentation
- #3625: @josegonzalez Remove old reference to SPONSORS.md
- #3619: @josegonzalez Cleanup plugin creation docs
- #3612: @jayjun Improve testing docs
- #3613: @Lyelt Remove all uses of proxy_set_header Connection "upgrade"
- #3596: @josegonzalez Add missing hooks to events plugin and plugin triggers docs
### Tests
- #3610: @jayjun Correct Bats path in single tests
If you are running docker in docker, the permissions on the generated file are such that they may not be accessible by the normal dokku user. For dokku, it is good enough to ignore the failed removal.
If "docker cp" is run within docker, it seems the owner is root, resulting in other processes not being able to directly read the file without resorting to `cat` trickery. Doing this in a single place avoids the problem completely.
Asynchronous image removal would remove intermediate build images during the build process, causing intermittent build failures for users of multi-stage dockerfiles. While we still remove intermediate docker images that may be used in the current build, we now do so during the deploy, ensuring that there are no intermediate build failures in the future.
Closes#3474
As this trigger is always in the execution path, `plugn` starts and expensively checks to see if it can execute the trigger. Rather than call this on every invocation, skip the trigger if no non-core implementation exists.
This is a "one-shot" ability, meaning that it is highly discouraged for multiple plugins to implement the triggers.
The `builder-create-dokku-image` trigger is meant to modify the base DOKKU_IMAGE that will be used to build an application. A good use of the hook is to inject system packages by:
- calculating an image tag from the set of system packages
- checking that the image doesnt already exist
- creating the image if it does not
As the output is sent to stdout, we have to find an alternative way of fetching the new DOKKU_IMAGE. The `builder-dokku-image` trigger can output an image tag based on the calculated image tag. If no tag is output, then the DOKKU_IMAGE is used as is.
Using this pattern, users can efficiently modify the base image in use for an app without duplicating the work on every push. This is especially useful for package installation, where packages are required for app building, but may take a long time and can be error prone.
A builder plugin implements some method for 'building' artifacts from a given source code archive. This refactor moves the majority of the image building code into separate plugins, allowing us to implement other builders, but also simplifying the common pugin codebase.
Also move the pre-build-buildpack hook from the build-env plugin to builder-herokuish.
This reduces duplication and allows users to rely on global arguments to generate most labels needed.
The 'commit' command cannot have global arguments because the whitespace within the label change breaks string-based interpolation, and shell arrays cannot be exported.
The plugin creation docs were hard to follow, unnecessarily complicating issues for developers. The new format should make the recommendations clear, and align examples with the core code.
[ci skip]
In some cases, the cache directory may exist but there may be no app image to use for cache purging. This may be the case if the app was never deployed.
Instead of failing, we can simply use the configured herokuish image for clearing cache, as that image is the base image for anything that would have modified cache.
# History
## 0.17.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.9/bootstrap.sh
sudo DOKKU_TAG=v0.17.9 bash bootstrap.sh
```
### Bug Fixes
- #3593: @JakeAngell Fix nginx template for https in "Connection" header
### Documentation
- #3595: @josegonzalez Drop extra help output for trace
# History
## 0.17.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.8/bootstrap.sh
sudo DOKKU_TAG=v0.17.8 bash bootstrap.sh
```
### Bug Fixes
- #3591: @palfrey Allow SSH keys with no ending newline
### New Features
- #3587: @josegonzalez feat: drop make and gcc as dependencies
# History
## 0.17.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.6/bootstrap.sh
sudo DOKKU_TAG=v0.17.6 bash bootstrap.sh
```
### New Features
- #3578: @josegonzalez Allow omitting resource args by setting DOKKU_OMIT_RESOURCE_ARGS
This change allows operators to specify a DOCKER_BIN environment variable. This will specify a binary to run when executing docker, which is useful in cases where the 'docker' command being run must be modified in a way that would otherwise be invasive to Dokku, but minimalistic if done within a wrapper.
The post-delete hook will delete config, and thus scheduler-post-delete is the best place to actually delete resources where some local config may be necessary in order to reference resources.
# History
## 0.17.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.17.3/bootstrap.sh
sudo DOKKU_TAG=v0.17.3 bash bootstrap.sh
```
### Bug Fixes
- #3570: @znz Fix typos in trace help
### New Features
- #3574: @josegonzalez Add support for pulling app status from scheduler plugins
- #3571: @znz Simplify hostname_regex
`[a-z0-9\.\*-]+` includes `\.` and `[a-z0-9\*-]+`.
So I think `^([a-z0-9\.\*-]+\.)*[a-z0-9\*-]+$` means last char is `[a-z0-9\*-]`
and other optional chars are `[a-z0-9\.\*-]*`.
A DOKKU_SCALE file will always be used for managing the scale count for an app if it exists in a repository. As such, ps:scale usage should be disabled in those cases. This commit makes that more apparent.
Also document how to build a specific core plugin for testing purposes.
Closes#3544
This was removed in c9bbddcfcb as it was more complicated for operators to figure out _exactly_ which combination of limits/reservations would apply to their applications. Unfortunately, the documentation was never updated.
We may re-add this functionality in the future, but for now, cleaning up the docs is the best option.
[ci skip]
# History
## 0.16.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.4/bootstrap.sh
sudo DOKKU_TAG=v0.16.4 bash bootstrap.sh
```
### Bug Fixes
- #3547: @josegonzalez Correct retrieval of resource values for alternative schedulers
### New Features
- #3546: @josegonzalez Add ability to trigger an arbitrary plugin hook
This is useful in cases where the command output must be tested, but it is otherwise embedded in a specific part of the dokku core.
As the 'plugin' commands require root, this is safe to add to the core.
# History
## 0.16.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.3/bootstrap.sh
sudo DOKKU_TAG=v0.16.3 bash bootstrap.sh
```
### Bug Fixes
- #3541: @josegonzalez Handle case where image is null on first deploy
### New Features
- #3543: @josegonzalez Add ability to clear global domains
- #3517: @josegonzalez SSH key updates
- #3538: @josegonzalez Silence dokku run 'errors'
### Documentation
- #3523: @MarcDiethelm Add an example how to specify a Dockerfile for deployment
- #3539: @josegonzalez Warn users when ufw is enabled
If the subdomain is url-like, assume it is a valid url and use it for the default domain name. This allows users to specify the default domain for an app even if that is a subdomain of a global vhost.
Closes#3529
# History
## 0.16.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.1/bootstrap.sh
sudo DOKKU_TAG=v0.16.1 bash bootstrap.sh
```
### New Features
- #3532: @josegonzalez refactor: allow the scheduler to decide if an app is deployed
### Documentation
- #3530: @jhstatewide Updated info about supported Ubuntu versions
The previous output required too much parsing to be used in an automated fashion. This change makes that a bit easier, without sacrificing usability.
Note that the output is quite a bit different from heroku. This is purposeful as we do not have the concept of dynos.
Closes#3520
Use `GIT_STRATEGY: none` in `stop_review_app` to make job work after successful
merges and when the branch was deleted.
Without this, the application is not stopped when the branch is deleted on merge as the runner pulls the git repository by default, but cannot find the tree in this moment.
[skip ci]
# History
## 0.15.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.15.5/bootstrap.sh
sudo DOKKU_TAG=v0.15.5 bash bootstrap.sh
```
### New Features
- #3511: @josegonzalez Add json output to config:export
### Documentation
- #3510: @josegonzalez Remove SPONSORS doc in favor of OpenCollective
- #3509: @Neamar Missing space in markdown formatting
- #3507: @renestalder Fix GitLab CI examples
This change adds json output as both key/value as well as a list of objects. The former can be used in quick scripting environments, while the latter allows higher-level languages to have a bit more structure around how environment variables are declared. Specifically, systems such as kubernetes understand the latter method, while the former can be used within Nomad job files.
The GitLab CI examples used `$CI_ENVIRONMENT_SLUG` for defining the environment names
of the deploy jobs. But this variable is actually the OUTPUT of setting the environment name,
thus, it tries to reference itself, but does not exist in that moment.
The correct way to set this is to use `$CI_COMMIT_REF_NAME` as based on the documentation
of GitLab's dynamic environments.
With the introduciton of procfile-util, scaling a non-existent process to 0 was disabled. This brings back that functionality, allowing users to scale all processes to 0. This is especially useful when a user has accidentally scaled a non-existent process up, causing deploys to fail without any way to revert outside of manually editing files.
Closes#3428
The `domains` command previously had this functionality, but is deprecated, and thus we should provide an alternative method of presenting the information.
This moves the base image from Xenial to Bionic, which is the latest supported LTS release of Ubuntu. Note that all previous releases of herokuish are no longer supported, and users are encouraged to upgrade where possible.
In the case of upgrades, a 'dokku repo:purge-cache APP' should be called for each app, or built applications may include code linked to non-ABI compatible libraries due to the OS upgrade.
This sort of change is usually performed _only_ during a minor release, but as the window since the release is fairly small, the risk to our users is negligible in comparison to the inability to stay on a maintained herokuish release.
Global limits make it harder to reason about the inheritance in the system. Rather than support global limits, Dokku should provide primitives to automatically set them on an app at provision time, or explicitly set them for an app. Both of these are likely best suited for a higher-level provisioner, or a community plugin.
This will allow validation to work if the default logging locations cannot be written to but the configuration is otherwise okay. This will be the case for users with custom nginx configurations that log to other places, such as syslog.
When setting environment variables, we should respect a passed `--quiet` flag - and the respective environment variable. This will allow users to have a nicer experience when using the config functions within their own plugins.
Rather than always assuming a missing `WORKDIR` means herokuish, we instead inspect the image to verify that it is. If it is, then and _only_ then do we set WORKDIR. Otherwise, we respect the decision of `docker cp` to execute from within the last known `WORKDIR` context, which is inherited at the image level, not image metadata level.
Additionally, speed up `is_image_herokuish_based` by inspecting the environment variables on the image. When there is a "USER=herokuishuser", we can more or less safely assume it is an image that Dokku built, and is therefore a herokuish image. While possible, it would be very strange if a non-herokuish image had this environment variable set, so it is a relatively safe change.
- ensure nginx is always installed
- install nginx in the same way for apt-using distros
- do not install software-properties-common or python-software-properties if not needed
Log output for ps:retire was previously a bit too verbose because we weren't handling the following edge-cases.
- if a container doesn't exist, remove it from the dead container list
- ensure a restarting container is properly killed
- only attempt to stop/kill if the state is not dead or exited
- do not attempt to do anything if the container doesn't exist
- correct check on running state
Previously, if running 'dokku report --all', the early exit 1 in apps:report would cause the entire process to bail, resulting in a partial report. Instead, we exit 0, allowing plugn to continue.
Technically a non-deployed app is not an error case at this position.
# History
## 0.14.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.14.1/bootstrap.sh
sudo DOKKU_TAG=v0.14.1 bash bootstrap.sh
```
### Bug Fixes
- #3386: @josegonzalez Ensure we can deploy code when there is no pre or post-deploy script defined
# History
## 0.14.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.14.0/bootstrap.sh
sudo DOKKU_TAG=v0.14.0 bash bootstrap.sh
```
### Bug Fixes
- #3384: @josegonzalez fix: use updated gpg key for apt repository
- #3382: @josegonzalez Set cleanup to global when no application is specified
- #3350: @josegonzalez Do not build the proxy config when there are no app listeners
- #3366: @josegonzalez Add post-app-clone-setup to network clean make target
- #3349: @josegonzalez Ensure apps are cleanly cloned
- #3356: @josegonzalez Move storage directory into DOKKU_LIB_ROOT
- #3341: @baikunz Select only default dokku network IP
- #3348: @josegonzalez Use correct name for packagecloud token when running CI commands
- #3339: @josegonzalez Properly check args when calling cleanup globally
- #3344: @josegonzalez Allow running dokku report without needing an interactive shell
### New Features
- #3381: @josegonzalez Add support for the Procfile release command
- #3380: @josegonzalez Install stable docker when using bootstrap script
- #3378: @josegonzalez Make admin setup UI look nicer
- #3369: @josegonzalez Pull invalid nginx configuration when the nginx configs fail to validate
- #3371: @josegonzalez Add tests section to changelog
- #3358: @josegonzalez Image tag deploy workflow cleanup
- #3351: @josegonzalez Do not clone URLS and VHOST files to new apps
- #3357: @josegonzalez Add support for building arbitrary releases
- #3354: @josegonzalez Drop default dhparam key size to 2048
- #3347: @josegonzalez Upgrade herokuish
- #3352: @josegonzalez Increase security of default SSL setup
- #3353: @josegonzalez Normalize tests
- #3345: @josegonzalez Allow triggering the full report for all apps via --all flag
- #3346: @josegonzalez Always overwrite the dokku.conf file for nginx
### Documentation
- #3377: @josegonzalez Remove team member section on homepage in favor of sponsor section
- #3376: @josegonzalez Switch from rawgit to jsdelivr
- #3365: @josegonzalez Remove extra tags:create call from docs
### Tests
- #3379: @josegonzalez Run mvdan/shfmt on test runs
- #3370: @josegonzalez Add junit support to shellcheck output
- #3308: @josegonzalez Add timing info to test runs on CircleCI
- #3367: @josegonzalez Run tests from built artifact
- #3368: @josegonzalez Balance circleci tests
- #3363: @josegonzalez Add a wrapper for invoking a single test
- #3362: @josegonzalez Allow tests to be run from any directory
- #3360: @josegonzalez Switch to bats-core
- #3361: @josegonzalez Do not generate dhparam for tests
### Other
- #3279: @fruitl00p Make sure the universe repo is loaded into APT
This script previously ran through the docker installation process with the edge channel on each run. Instead, we only run the docker installation if docker is not available. In addition, we force set the channel to stable, ensuring the script installs the correct channel for stable docker installations.
Closes#3269
While I do not agree with _every_ style change, this will force Dokku to have consistent formatting across all shell scripts, which is arguably a Good Thing™.
The command used to reprocess everything is:
```shell
shfmt -l -bn -ci -i 2 -w .
```
The initial admin setup UI is a bit of a hack, but could also be a bit frustrating to new users as the settings are unclear. Rather than throw them to the wolves, include some useful information to allow them to make good decisions when setting up Dokku.
- Upgrade to latest bootstramp and latest jquery 1.x release
- Add a warning for people who might miss this setup page
- Add placeholder text to both the ssh key area and the hostname
- Add descriptions to all form fields to further explain the consequences of a particular field
- Add links where necessary for users who wish to explore how to change settings in the future
- Make the "result" message on submission red or green depending on the success or failure of the submission.
- Wait 3 seconds before redirecting on success
On Ubuntu within AWS environments, the default user is the `ubuntu` user, and this is where the ssh key should be pulled from. CentOS has a tendency to use `ec2-user`.
On all other environments, the `root` user is typically the only user provisioned.
Closes#3372
The checkstyle xslt wasn't quite good enough, resulting in missing/malformatted output. Note that this now excludes _passing_ tests, which also isn't quite right, but a fair bit closer to the xsd here: https://github.com/windyroad/JUnit-Schema
This requires us to run shellcheck twice, as the first pass doesn't output anything human readable - both because of the redirect and because shellcheck doesn't directly support it - which increases lint runtime but allows us to have both the junit information and the normal human-readable output.
Note that the checkstyle output does not contain timing info.
This removes outdated information on the main page in favor of the "official" ways of sponsoring Dokku.
Also update the contributing note to mention where to post
Are you a crypto-user and want other options? Feel free to send bitcoin to 3MY2HxMVsxuWmhQkgYBsE3iZFjJgkjNPyQ
Closes#3374
Rawgit is no longer being offered due to spammers, but jsdelivr has graciously allowed folks to use their cdn to mirror assets from github.
Closes#3284
- expose an nginx:validate command that can be used to show validation information
- properly reference the invalid nginx config, rather than tell the user that another app's nginx config is invalid when deploying their own app
- allow a user to cleanup bad nginx config files out of band when they are blocking a deploy _without_ requiring knowing where that nginx config is
Note that this may have issues with generated nginx.conf files that depend on other apps or other parts of the nginx config. For now, this is acceptable, though it is something that needs to be field tested.
Closes#3162
This avoids cases where a developer believes they should be able to provision an nginx proxy but is unable to as no web process is configured to listen for the app.
Also silence stderr when extracting custom nginx templates. If there is stderr, that means we were not able to retrieve the template, but it's of no consequence for debugging.
Closes#3262
Rather than testing against an install from source, ensure that all tests run from what _would_ be installed on a user's server. This ensures that the build process is sound, regardless of what code changes are implemented.
This switches from the older, unmaintained version of bats to one that _is_ maintained. In particular, this fork of the community version - bats-core/bats-core - adds junit timing support, which can be used to track down slow tests.
Once the bats-core/bats-core repository merges junit support, we will switch back to upstream.
Note that tests on OS X will still run using a version that _does not_ have junit timing support.
The cipher list is from from https://cipherli.st/ and will remove a few older browsers:
- Android 5.0
- Android 6.0
- Chrome 49 / XP SP3
- Firefox 31.3.0 ESR / Win 7
- Firefox 47 / Win 7 R
- IE 11 / Win Phone 8.1
I _think_ thats an okay drop - dropping Android kinda hurts, but we're far from the only ones dropping them from being served, and our users are free to override these settings on their own servers.
Closes#3343
This is necessary as sometimes older config is shipped with Dokku, meaning that security directives - amongst others - are not properly updated.
Refs #3342
# History
## 0.13.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.4/bootstrap.sh
sudo DOKKU_TAG=v0.13.4 bash bootstrap.sh
```
### Bug Fixes
- #3337: @josegonzalez Use correct container id variable for killing containers
### New Features
- #3338: @josegonzalez Redirect ps:retire output to a log file
This will allow systems to properly monitor whether retiring old containers works.
Note that the file will be logrotated by the 20_events logrotate config.
# History
## 0.13.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.3/bootstrap.sh
sudo DOKKU_TAG=v0.13.3 bash bootstrap.sh
```
### Bug Fixes
- #3330: @josegonzalez Ensure chowned properties always have a user and group set
### New Features
- #3334: @josegonzalez refactor: run every 5 minutes instead of 2
# History
## 0.13.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.2/bootstrap.sh
sudo DOKKU_TAG=v0.13.2 bash bootstrap.sh
```
### Bug Fixes
- #3329: @josegonzalez Avoid parsing missing file when retiring containers
- #3325: @wcalandro Add "--global" to dokku cleanup on dokku update
### Documentation
- #3326: @josegonzalez Add note to release on how to upgrade via the bootstrap script
# History
## 0.13.0
### Bug Fixes
- #3312: @josegonzalez fix: keep track of failed containers regardless of docker kill output
- #3299: @josegonzalez Wrap script_bin in double-quotes
- #3295: @alexquick Sort config:show by key name
- #3288: @josegonzalez Wrap script binary in single quotes during executable check
### New Features
- #3302: @josegonzalez Add ability to check on app lock status via apps:locked command
- #3315: @aokon Upgrade herokuish to 0.4.5 version
- #3236: @josegonzalez Retire old containers
- #3307: @josegonzalez Add support for docker.io package
- #3301: @josegonzalez Add ability to sync packages to a new version of ubuntu
- #3286: @josegonzalez Sanitize docker inspect output with ps:inspect
- #3240: @josegonzalez Refactor Procfile handling to use go-procfile-util
- #3282: @josegonzalez Use create instead of run for faster and more reliable file copy from docker images
- #3280: @josegonzalez Better scheduler support
- #3259: @josegonzalez Check if script is executable when a full path is specified
### Documentation
- #3314: @royklutman Remove reference to non-existent DigitalOcean hosting plan
- #3313: @morenoh149 Indicate to user to specify hostname
- #3310: @josegonzalez Add a note to our issue template begging for money
- #3281: @josegonzalez Add documentation on custom error pages
This is new in Ubuntu Bionic, and should allow users to install without using upstream docker.
Note that we recommend installing from upstream where possible.
Closes#3297
These will be killed on a cron schedule, allowing us to ensure old containers don't run once memory pressure clears up - even across restarts.
Closes#3225
Often-times, we will want to have the container inspect output for debugging purposes, but this process is:
- error prone, as the user needs to know what their containers are
- potentially insecure, as the output must be sanitized of sensitive data
Instead of making users wade through this process, we provide a helper `ps:inspect` command, that can be used to diagnose problems associated with containers that may or may not exist for an application.
This allows us to force another plugin as the default vhost implementation, or disable it altogether in favor of some higher-level proxy implementation, such as one that integrates with service discovery.
Some systems - such as a mounted read-only CIFS filesystem - do not fully support chown, and chowning should be considered optional for cases when the host os has already taken care of permissioning. This commit allows users to disable chown by setting a property on the scheduler-docker-local plugin.
# History
## 0.12.11
### Bug Fixes
- #3238: @josegonzalez Handle proxy issues in app renaming
- #3234: @mashrikt Unset GIT_QUARANTINE_PATH when updating repo submodule
- #3223: @josegonzalez Get the global scheduler if no app is specified
- #3218: @wcalandro Fix error text when using "dokku plugin:uninstall"
### New Features
- #3242: @josegonzalez Upgrade herokuish to 0.4.3
- #3241: @josegonzalez Add a subcommand for retrieving failed app deploy logs
- #3237: @josegonzalez Support --quiet header when showing all environment variables
### Documentation
- #3235: @josegonzalez Switch from ps:rebuild to ps:restart
- #3221: @josegonzalez Better callout for why env vars do not get applied to dockerfile builds
This can be useful in cases where a developer wishes to see what error messages are available for a failed deploy, but does not wish to spelunk around `docker ps -a` output.
Note that the logs are not made available once a further deploy is triggered, or after the containers have been garbage collected.
This will allow us to kill stale proxy configuration within apps, which is critical during application renames.
- redirect rmdir output to dev-null
- trigger a proxy-clear-config (new trigger) when renaming an application
- The configuration will be rebuilt during the later `ps_rebuild`
Closes#3231
Ubuntu has been slimming down their installations recently, so requiring net-tools fixes usage issues for many commonly installed plugins (such as the datastore plugins).
- reorder things to make it clearer to the user what they are filing
- use headers for various sections
- separate the `dokku report` section to increase its importance
[ci skip]
# History
## 0.12.6
### Bug Fixes
- #3193: @josegonzalez Install bash-completion files correctly
- #3179: @josegonzalez Ignore issues with popd when OS versions with stricter security
- #3177: @philm ensure dokku-redeploy runs when docker is stopped then started
- #3176: @josegonzalez Detect mixed running status on service start
### New Features
- #3195: @josegonzalez Allow lower versions of docker-engine
- #3181: @malixsys Adding support for `http2_push_preload` to nginx 1.13.9+ configuration
- #3183: @josegonzalez Unskip initial herokuish test
- #3175: @josegonzalez Implement bash-completion for commands
### Documentation
- #3197: @josegonzalez Add a tutorial for deploying applications via gitlab ci
- #3194: @josegonzalez Clarify why dokku report information is useful
- #3189: @josegonzalez Correct issue with adding a user remotely
In some cases, a single allocation for a service may not be running, but the others will, and `is_app_running` will return the wrong thing.
Closes#2772
This will allow us to _actually_ introspect on the running state of an application. In certain cases, the detected state can be "mixed", meaning that we may need to take action, depending on what we want to do in mixed mode.
This only completes the command names - not any arguments - and also relies on a completion cache as the response from Dokku for help output can be slow.
Closes#2095
# History
## 0.12.5
### Bug Fixes
- #3173: @josegonzalez fix: do not output error message twice
### New Features
- #3172: @josegonzalez feat: Add the ability to ignore existing applications during a git clone
- #3171: @josegonzalez Allow users to override the reported app url
- #3170: @josegonzalez Add ps:startall command
### Documentation
- #3159: @zuck Improve docs for default site with HTTPS
This is useful in cases where the app url has some "interesting" structure - such as a subdomain or scheme change - for a specific installation.
Closes#3160
# History
## 0.12.3
### Bug Fixes
- #3156: @josegonzalez fix: ensure we _always_ include all types in history output
### Documentation
- #3163: @josegonzalez Better apt install formatting
### Other
- #3153: @scjody Allow specifying a separate DOKKU_HOST_ROOT
In some cases, we might miss pull requests where there is more than one 'type' label, causing that pull request to be omitted from the history. This change ensures we always include pull requests in the change log
As this was not strictly announced in our migration guide, removing it is a bc-incompatible change we are not comfortable with. We may wish to remove it in the future
This is to be used in place of `DOKKU_ROOT` when we need to refer to a
path on the system where the Docker daemon is being run; if `dokku` is
running in a container this may be different from the regular
`DOKKU_ROOT`.
# History
## 0.12.0
### Bug Fixes
- #3146: @josegonzalez Fix non ubuntu installs
- #3138: @josegonzalez Use correct path for /etc/default file
- #3137: @josegonzalez Ensure we can disable setting the rev-env-var
- #3131: @axilleas Capitalize log sentence when renaming containers
- #3128: @Modicrumb Improve windows vagrant experience
- #3105: @znz Follow renaming from deploy-method to deploy-source
- #3101: @josegonzalez Handle stopped nginx during debian installation
### New Features
- #3141: @josegonzalez Centralize app existence checks into the apps plugin
- #3147: @josegonzalez Create proxy:ports-set call
- #3145: @josegonzalez Add report trigger
- #3144: @josegonzalez Increase curl max timeout to 600 seconds (10 minutes)
- #3107: @znz Remove unused password in ssl cert generation
- #3095: @josegonzalez Migrate env for NGINX_* to PROXY_*
- #3140: @josegonzalez Add newline to config:get output
- #3139: @josegonzalez Add ability to initialize a git repository out of band
- #3111: @josegonzalez Upgrade herokuish to 0.4.0
- #3110: @josegonzalez Upgrade herokuish to 0.3.36
- #3106: @znz Remove unnecessary shellcheck disable
- #3098: @josegonzalez Pull herokuish from docker hub when installing via package
- #3100: @josegonzalez Properly handle invalid process type entries during DOKKU_SCALE generation
- #3097: @josegonzalez Update herokuish to 0.3.35
### Documentation
- #3148: @josegonzalez Use consistent terms for domains, apps, and commands
- #3135: @josegonzalez Revert "Clarify that the checks plugin only matches content start"
- #3134: @tomdyson Fix typo in upgrading docs
- #3119: @TomasHubelbauer Link through to the application deployment page after the installation
- #3118: @Tyilo Clarify that the checks plugin only matches content start
- #3113: @ilyapoz Fix proxy management link
- #3112: @josegonzalez Minor doc css fixes
- #3104: @sarendsen Add dokku-limit to plugins documentation
- #3108: @znz Update plugin list output
In some cases, it may be useful to completely override the set ports for a given application - such as on initial deploy when there is no global domain set. This change also further allows us to handle automation in a smoother fashion.
This allows users to quickly show the state of any configured application, as well as the state of their server. In doing so, we make it easy for them to provide information necessary for debugging in a single command.
The correct way to handle getting the status should be ps:report.
Also cleaned up an issue where ps:report failed to catch errors for non-running containers.
This is useful in contexts where the repository directory may be created and interacted with via git-http-backend or other methods of updating a repository.
- add `report` and `set` subcommands to the git plugin
- move configuring the DOKKU_DEPLOY_BRANCH to the git plugin
- implement configurable GIT_REV support
- migrate DOKKU_DEPLOY_BRANCH settings
- add a golang-compatible, shell based method of setting plugin configuration variables
Deprecates the community dokku-git-rev plugin.
Closes#2621
Refs dokku-community/dokku-git-rev#9
# History
## 0.11.6
### Bug Fixes
- #3091: @josegonzalez Properly trigger tar-based deploys on git-deployed repositories
- #3076: @Kjwon15 Prune worktree after build
- #3090: @josegonzalez Ensure all plugin triggers have docs and events integration
- #3089: @josegonzalez Use a longer password for self-signed certificates
### New Features
- #2950: @adelq Add configuration option to disable automatic app creation
- #3093: @josegonzalez Add subcommands to allow app locking and unlocking
- #3092: @josegonzalez Add support for configuring the app shell
### Documentation
- #3096: @josegonzalez docs: Document how to check on a running dokku-installer
This removes the ability to support http proxy directly, but fixes issues where users may not
be using exactly the same herokuish as we expect.
Closes#2828
[ci skip]
Unlocking an app will not stop running deploys, so users may need to clean up. However, it is useful for deploys that fail in unusual ways that cause the lock to stay around.
Closes#2883
This allows developers to change the shell from /bin/bash to any other when executing
`dokku enter` or pre/post deployment tasks. Ideally we could detect the shells available,
but that is slow and potentially error prone.
Closes#2572
# History
## 0.11.5
### Bug Fixes
- #3088: @josegonzalez Silence port retrieval stderr
- #3086: @josegonzalez Fix help output for golang plugins
- #3079: @josegonzalez Move container status exclusively to ps plugin
### New Features
- #3085: @josegonzalez Add support for checking if an application exists
- #3032: @josegonzalez Add support for arbitrary ubuntu versions
- #3074: @josegonzalez Add the ability to disable ANSI prefixes via DOKKU_DISABLE_ANSI_PREFIX_REMOVAL
- #3083: @josegonzalez Source /etc/defaults/dokku if available
### Documentation
- #2958: @silverfix Add tutorial for running Dokku on an external volume
- #3082: @josegonzalez Switch from Gratipay to Patreon
- #3081: @josegonzalez Add docs for switching between deployment methodologies
This allows users to override - at a top-level - the DOKKU_ROOT, DOKKU_LIB_ROOT, and other
configuration variables. If specified, this should begin to enable users to move their
Dokku installations to mounted drives.
Note that items installed from packages may not respect these paths, so further work may be in order.
Closes#2958
These should never have been in common, and more directly relate to domain handling than anything else.
As this is a BC-break, merging will need to wait until the next minor.
# History
## 0.11.4
### Bug Fixes
- #3071: @josegonzalez Do not grab restart policies if the deploy phase cannot be read
- #3065: @josegonzalez Check if dokkurc files are readable before attempting to source
- #3066: @josegonzalez Validate that all application names are valid domain names
- #3052: @alexquick Remove bad config keys on load from app/global envfiles
### New Features
- #3073: @josegonzalez Add support for rhel
- #3039: @josegonzalez Enhance security-related upgrade process
- #3038: @shrmnk Add ps:stopall subcommand
- #3055: @michaelshobbs Update to herokuish v0.3.34
- #3045: @jcrben Remove nginx configuration files on debian purge
### Documentation
- #3072: @josegonzalez Remove all references to VHOST files from documentation
- #3069: @josegonzalez Remove potentially bad nginx template examples
- #3059: @lwm Add note for runtime host configuration for checks.
- #3041: @jcrben Point to unattended install instructions
- #3053: @mimischi Add plugin to manage Dockerfile location to documentation
- #3062: @shannara Change help run command be more explicit
- #3034: @znz Fix a typo in golang config.go source
- #3061: @tomdyson Fix plugin-triggers docs typo
- #3056: @raine Fix typo in config help output
- #3044: @takuti Fix links to port-management
- #3042: @josegonzalez Improve documentation around port handling.
The centos rpm packages should be installable on centos once this is merged and released. However, Dokku will not maintain an Rhel-specific repository as there is no way for us to feasibly test it.
Closes#3046
Users should never be in a position where they need to manually edit files managed by Dokku, and should be pushed to using the `domains` plugin where necessary.
Closes#3064
[ci skip]
These examples do not include _all_ of the contents of the original template. Rather than having to keep them up to date and confuse users when we don't, lets just remove them. The section above contains a link to the current `nginx.conf.sigil` and should be referenced by our users instead.
Closes#3068
[ci skip]
While there are a number of enhancements we could do to make port handling more seamless, this is a first step towards documenting the various oddities around port management for Docker vs Buildpack deploys.
Refs #2903Closes#2970
[ci skip]
# History
## 0.11.3
### Bug Fixes
- #3031: @josegonzalez fix: ensure we respect DOKKU_DEPLOY_BRANCH when rebuilding applications
### New Features
- #3028: @josegonzalez Ensure parallel runs properly for non-restorable apps and moreutils parallel
- #3030: @josegonzalez feat: allow changing the system user the properties plugin uses
- #3024: @jcrben Use high-availability pool keyserver during tests
- #3017: @josegonzalez feat: add pre-start trigger for notifying on application start
### Documentation
- #3020: @gliwka Point to docs in the right version
- #3016: @josegonzalez Update nginx template example to use http2 when available
# History
## 0.11.2
### Bug Fixes
- #3014: @josegonzalez fix: handle case where DOKKU_DOCKERFILE_PORTS is an empty string
- #3013: @alexquick Fix some issues with config/network/repo help output
- #3012: @alexquick Fail when setting/unsetting invalid keys
- #3011: @alexquick Forward output from plugn triggers to user
- #3004: @josegonzalez Return/Exit 1 when an image being deployed is invalid
### Documentation
- #3015: @elia Tiny fixes to triggers documentation
# History
## 0.11.1
### Bug Fixes
- #3010: @josegonzalez fix: route config_all to the `config` command to fix datastore plugin usage
- #3009: @josegonzalez fix: correct the guard around the config_export call in config_sub
- #3006: @josegonzalez fix: do not allow shadowing of the CACHE_DIR variable
- #3005: @josegonzalez fix: persist users in the dokku group through installations
- #3003: @josegonzalez Fix issues in apps:clone calls
- #3001: @josegonzalez fix: allow applications to begin with numeric values
### New Features
- #3002: @josegonzalez fix: omit redirection of docker build output
- #3000: @josegonzalez fix: remove golang files and triggers directory for packaging
# History
## 0.11.0
### Bug Fixes
- #2998: @josegonzalez Fix issues in release process
- #2993: @josegonzalez Add config_all alias for plugin usage
- #2972: @buckle2000 Correct typo in docker-options:remove error output
- #2964: @znz Remove unused variable
- #2967: @znz Fix indentation in test file
- #2963: @znz Correct typos in config plugin and remove potential infinite recursion issue
- #2951: @josegonzalez Handle case where the app directory is a symlink
- #2939: @znz Remove unnecessary lines
- #2945: @znz Fix network plugin version
- #2937: @michaelshobbs Strip restart flag from app_user_pre_deploy_trigger
- #2931: @josegonzalez Upgrade git package for CI
- #2928: @silverfix Do not overwrite the VHOST file during installation if it exists
- #2926: @vtavernier Remove leading forward slash from app name in git-upload-pack
### New Features
- #2985: @bitmand Build a custom dhparam file once for nginx and include it as default
- #2974: @josegonzalez Upgrade to herokuish 0.3.33
- #2973: @josegonzalez Allow usage of git 2.13.0+ by unsetting GIT_QUARANTINE_PATH during git worktree usage
- #2971: @miraculixx Add support for older virtualbox versions in official Dokku Vagrantfile
- #2966: @znz Simplify internal config functions to reduce duplication
- #2751: @alexquick Move config plugin to golang
- #2938: @michaelshobbs Upgrade to golang 1.9.1
- #2736: @josegonzalez Implement Network Plugin
- #2929: @michaelshobbs Add codacy config and coverage targets
### Documentation
- #2935: @jcrben Document how to make herokuish optional during the bootstrap installation
- #2982: @agorf Correct typo in user management docs
- #2981: @agorf Correct typos in process management docs
- #2969: @znz Correct comments on network triggers
- #2965: @znz Remove spaces from config subcommand help output to mirror help output of other subcommands
- #2954: @mrname Add vernemq community datastore plugin to docs
- #2944: @axilleas Fix syntax typo in debian installation docs
- #2932: @znz Update code comment to match documentation
- #2933: @znz Fix version number for network binding documentation
- use a plugin trigger to see whether we should bind to all interfaces
- create a generic way of setting properties for a plugin
- migrate proxy-enabled to the new network property "bind-all-interfaces"
- add network:set subcommand
- Add proxy-build-config hook to rebuild network and proxy settings for an application
- Scope nginx:build-config to work only when it is the configured proxy for an application
- Refactor deploy code to interact with network plugin for computed and actual ipaddr/port settings
- Ensure the proxy-build-config plugin trigger is called on ps:restore
- Expose a few plugin triggers for retrieving networking information for a given APP/PROC_TYPE/CONTAINER_ID combination
Add forward slash cleanup of the app name for the git-upload-pack
command. Prevents is_valid_app_name from removing the application folder
on `git fetch`.
# History
## 0.10.5
### Bug Fixes
- #2912: @josegonzalez Add missing depends statement for rsyslog
- #2906: @manuel-colmenero Check the location of nginx in a central way
- #2895: @josegonzalez cd to app directory when calling git worktree add
### Documentation
- #2922: @axilleas Clarify the minimum Nginx version for HTTP/2 support
- #2919: @wootwoot1234 Update nginx documentation surrounding file uploading for php buildpack users
- #2913: @znz Fix a typo in the rpm release script
- #2910: @buckle2000 Add a note about using the full git url for non-compliant toolchains
You can now set b64encoded values. They are
stored decoded, this is so dokku over ssh can set
odd config values
```
config:set --encoded KEY=BASE_64_VALUE
```
still to do:
* Rework disk format to be okay with quotes
* Fix Dockerfile deployments
* Dedup code in the subcommands
* Add --encode
* Add deploytests for the new stuff
* Restore some log messages (should I make some helpers in common?)
* Restore some functions that may be used by 3d-party plugins
# History
## 0.10.4
### Bug Fixes
- #2894: @josegonzalez fix: bail if any step in the release process fails
- #2880: @josegonzalez fix: properly detect empty subcommands
- #2881: @josegonzalez Verify app name on git push
- #2858: @cstroe Use correct port number for the upstream.
- #2848: @josegonzalez Ensure https applications return an https url from `dokku url`
- #2839: @josegonzalez fix: skip clearing cache if we are not building a herokuish image
### New Features
- #2890: @michaelshobbs use circleci 2.0
- #2847: @scjody Add nginx ppa before installing Dokku
- #2850: @michaelshobbs add optional PROC_TYPE and CONTAINER_INDEX to docker-args-deploy plugn trigger
- #2840: @josegonzalez Add DYNO environment variable to run containers
- #2824: @josegonzalez Upgrade herokuish to version 0.3.31
### Documentation
- #2861: @adelq Use non-deprecated apps command
- #2878: @m0rth1um Add telegram notifications plugin
- #2876: @josegonzalez docs: clarify storage documentation caveats
- #2873: @josegonzalez docs: add a note on which docs to look at for customizing nginx docs
- #2867: @josegonzalez docs: cleanup help output for dokku shell
- #2859: @josegonzalez docs: use relative link for application deployment doc
- #2866: @josegonzalez Add missing migration guides
- #2863: @josegonzalez docs: fix syntax on getting started docs
- #2836: @fishnux Add a note regarding nginx dependency to installation docs
- #2834: @iansu Clarify port exposure in Dockerfile documentation
On hosts where python3 is the system default python env and there is a minimal server installation, Dokku will silently fail to return the values of json keys.
# History
## 0.10.0
### Bug Fixes
- #2820: @josegonzalez Require netcat in debian packaging
- #2774: @fruitl00p Include docker-options in the default `dokku`
- #2778: @zarqman Fix /etc/logrotate.d/dokku on debian
- #2747: @ebeigarts Update herokuish base image on updates using --pull
- #2739: @josegonzalez Use listener_port in nginx.conf.sigil
- #2735: @josegonzalez Ensure we can call ps:report without specifying an application
- #2733: @josegonzalez Add support for new docker package names
- #2730: @weyert Ignore the cache directory when cloning an app
- #2723: @weyert Call non-deprecated plugin:list method
### New Features
- #2803: @iSDP Adding related articles on the Docker Image Deployment page
- #2798: @znz Update CURL_CONNECT_TIMEOUT in docs
- #2795: @josegonzalez docs: Add documentation around adding build-time configuration variables
- #2791: @yazinsai Correct typo in persistent storage docs
- #2789: @h4ckninja Subject-verb agreement
- #2790: @flyinggrizzly Add entry for insecure connection issue in Rails
- #2788: @josegonzalez Flesh out uninstallation documentation
- #2784: @josegonzalez Document special dokku environment variables
- #2773: @znz Update year in footer [ci skip]
- #2768: @znz Ubuntu 12.04 is EOL
- #2769: @lucianopf Fix SlackButton for mobile devices.
- #2763: @ZiadSalah Update vagrant documentation for windows users
- #2764: @joshmanders Create PULL_REQUEST_TEMPLATE.md
- #2758: @AxelTheGerman Update doc location for dokku-git-rev community plugin
- #2757: @nodanaonlyzuul Fix typo from "To use a dockerfiles" to "To use a dockerfile" singular
- #2753: @abrkn Use short-hand method for shutting down all applications in upgrade docs
- #2746: @josegonzalez Add redirect for installation to advanced install docs
- #2738: @josegonzalez Add missing `NO_SSL_SERVER_NAME` to example template
- #2457: @john-doherty Update Digitalocean installation instructions
- #2725: @timaschew Fix typo in application management docs
- #2719: @joshco Clarify that nginx.conf.sigil must be committed to repository
- #2715: @josegonzalez Use urls that are linkable on github
### Documentation
- #2822: @josegonzalez refactor: allow skipping cleanup on a per-application basis
- #2754: @fzerorubigd Add support for set DOKKU_IMAGE per app
- #2815: @markstory Add stickler-ci configuration.
- #2809: @oliw Remove aufs step from Makefile
- #2785: @josegonzalez Add a release-plugin binary
- #2777: @stokarenko Turn on ps-post-stop hook.
- #2781: @fruitl00p Adds docker.io support
- #2766: @josegonzalez Upgrade to herokuish 0.3.29
- #2765: @josegonzalez Install python3-software-properties as an alternative to python-software-properties
- #2642: @chiedo Added better default nginx error pages
- #2678: @callahad Default to secure PCI-compliant SSL setup
- #2734: @josegonzalez Allow quieter report output
In talking with @josegonzalez, stickler-ci.com helps reduce the amount of
time maintainers spend reviewing code by automatically giving style
feedback as pull request comments.
I've added linters for shell scripts and go files based on the linting
I could find in the existing make files.
If an application is configured to enforce secure connections and SSL isn't configured for Dokku or the application, browsers will raise an Invalid Connection error.
Entry describes issue, a code resolution for Rails, and points users to the SSL docs.
This adds a table of environment variables that Dokku will use to change internal behavior.
Not all are fully documented/listed, but this should be enough to get people hacking.
[ci skip]
Herokuish update fails if existing herokuish is used by other containers,
using docker build --pull will force to update also the base image.
Setting up herokuish (0.3.28) ...
Removing old herokuish image
Failed to remove image (gliderlabs/herokuish): Error response from daemon: conflict: unable to remove repository reference "gliderlabs/herokuish" (must force) - container dbf2298ab5a5 is using its referenced image 7d4a8d661476
Importing herokuish into docker (around 5 minutes)
Docker has this thing where they rebrand the debian package name once a year, and as YUM doesn't resolve anything like a "Provides" field, this is the best we can do (unless they all required the same metapackage).
Note that now we can't ensure a specific minor docker version via RPM, though I feel as though if you choose a crappy OS/package manager and we fail you, thats on you, not Dokku.
Closes#2732
Developers can override this in a custom nginx.conf.sigil.
While it may be backwards incompatible - and will therefore require a minor release - it does make things much more secure.
# History
## 0.9.3
### Bug Fixes
- #2706: @josegonzalez fix: ensure nginx conf.d directory exists when running nginx install hook
- #2701: @scjody Set SSH_USER for root commands
### New Features
- #2708: @josegonzalez Document that we will not do buildpack support in the issue tracker
### Documentation
- #2709: @michaelshobbs increase CURL_TIMEOUT and CURL_CONNECT_TIMEOUT defaults
- #2699: @mbreit Add support for git >= 2.11
Git 2.11.0 breaks the git clone approach in git_build_app_repo() in
25ab004c53
git worktree is a much simpler approach but only works for git >= 2.5
so it is not available in Ubuntu 14.04.
Fixes#2512.
# History
## 0.9.2
### New Features
- #2698: @josegonzalez docs: Document that we only care about specific sections
- #2697: @callahad Restore installer note regarding AUFS on Linode
- #2694: @scjody Add documentation note re: git-pre-pull vs. auth
### Documentation
- #2695: @michaelshobbs add tests for pre/post deploy tasks
# History
## 0.9.0
### Bug Fixes
- #2691: @josegonzalez Fix package building when golang binaries are available
- #2671: @znz Fix variable name
- #2672: @callahad Fix logrotate on Debian
- #2666: @josegonzalez Use correct flag for build arguments when installing herokuish
- #2664: @pvalentim Fix remote name when using --remote option with apps:create
### New Features
- #2689: @mbreit Add dokku-monit to community plugin list
- #2683: @josegonzalez Ensure we have an example for adding keys as another user
- #2682: @josegonzalez Clarify supported stanzas in app.json
- #2679: @callahad Remove unnecessary Linode-specific instructions
- #2670: @znz Remove duplicated `(i.e. `
### Documentation
- #2685: @josegonzalez Pass shellcheck on os x
- #2677: @callahad Prefer HTTP2 to SPDY in nginx-vhosts
- #2673: @michaelshobbs Update to herokuish 0.3.27
- #2674: @michaelshobbs Update sshcommand to 0.7.0
- #2654: @ebeigarts Enable nginx and docker on system startup when using bootstrap.sh on CentOS
- #2546: @michaelshobbs Convert repo plugin to golang
- Requires docker, git, and package_cloud gems
- Requires the PACKAGECLOUD_API_TOKEN environment variable
- Builds both a deb and rpm, pushing both to packagecloud
- Upgrades the golang build environment to 1.7.5
- Combines both build Dockerfiles into a single, generic env
- Fixes issue where internal-functions file for tar plugin was not executable
- Ensures that built plugins have a callback to clean up their source files before packaging
- Adds support for “betafish” releases, which are untested versions of Dokku that are available via a separate packagecloud repository.
1. SPDY has been deprecated and removed from modern browsers:
http://caniuse.com/#feat=spdy
2. HTTP/2 is present in all modern browsers:
http://caniuse.com/#feat=http2
3. SPDY and HTTP/2 are mutually exclusive in port-based `listen` directives:
http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
Caniuse suggests that 74% of global users have a browser that supports
HTTP/2, while only 27% have a browser that supports SPDY. Only IE11 and
Safari support both.
Therefore, when both are available, Dokku should choose HTTP/2 to
maximize the benefit to users.
This trigger allows you to modify the contents of an application *after* it has been extracted from git/tarball but *before* the image source type is detected. For example, you may wish to autogenerate a Dockerfile based on some other application contents before detecting what type of build process - herokuish or docker file - to use.
[ci skip]
Linode now supports KVM virtualization on all VMs by default. So, this verbiage was completely removed.
GRUB 2 is now one of the default options in the Kernel Menu. The additional Ubuntu packages are no longer required. Wording changed to reflect updated instructions.
Inject http proxy envvars to docker build command to allow package installation behind corporate proxies.
These envvars (http_proxy and https_proxy) are standard, and usually configured via system-wide /etc/profile.d files.
In cases where these envvars are not configured, the additions appear to be mute and non-destructive.
Application cloning can be used to setup review applications based on an existing application. This is useful in CI/CD pipelines where a developer may wish to verify code in a custom environment without overwriting a shared staging environment.
- Respect the --app flag
- Respect the --trace flag
- Skip the second argument after both --app and --remote flags
- The `--global` flag should be set as is when specified after a “valid” command
- Fix issues when checking if the --app flag should be passed via ssh
- Use APP as the variable name for the current app
`SSL_SERVER_NAME` should contain items found in the ssl certs
(E.G. CommonName and AltNames), but not already in the `NOSSL_SERVER_NAME`
list. That will avoid the dups in the `nginx.conf` and kill the warning
initially cited in dokku/dokku#2474
Certain versions of nginx have bugs that prevent HTTP/2 from properly responding to all clients, thus causing applications to be unavailable.
Closes#2435
Add new community plugin build hook.
This plugin provide a way for application to define scripts in their codebase to be executed before the project build (Dockerfile or Herokuish).
Use case :
A Java application with only an ADD of the generated fat jar in the Dockerfile.
The plugin allow the user to define a script to run the compilation before the docker build execution.
This is a proposed change for addressing GH #2446 "Adding a file with
two ssh-keys can result in an error" (see
https://github.com/dokku/dokku/issues/2446).
The following checks are performed:
- validity of key contents when read from a file
- key contents only contains one single line/key
- authorized_keys file is ultimately valid
The last test is an extension over the previous implementation in that
all lines in the file are checked.
The commit also includes extensions to the relevant test file to
excercise the new checks. It also takes care to save and then restore
the authorized_keys file.
Ref dokku/dokku-letsencrypt#76
Certificates provided by Let's Encrypt can have the domain provided in
the Subject Name field listed again in the Subject Alt Name fields,
leading to the same domain getting listed twice by get_ssl_hostnames()
that in turn leads to a duplicate server_name field in the nginx
configuration.
This patch adds a sort -u to ensure that every SSL hostname will only be
listed once.
As deployment tasks can fail due to non-dokku related issues, moving them to post-deploy will ensure that dokku does not accidentally orphan applications.
Closes#2367
Since they are separate resources, triggering the normal app creation flow makes the most sense.
We still remove the cache directory because we want the correct cache permissions for the new application.
> If you're using Dokku - especially for commercial purposes - consider donating to project development via [OpenCollective](https://opencollective.com/dokku) or [Patreon](https://www.patreon.com/dokku). Funds go to general development, support, and infrastructure costs.
>
> If you'd like to sponsor specific functionality, see the project's [Sponsoring](https://github.com/dokku/.github/blob/master/SPONSORING.md) document.
>
> If you need help figuring out how to use a specific buildpack, are seeing an issue in during the buildpack process, or are having issues using multiple buildpacks, please see our [slack channels or github discussion board](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations). Issues pertaining to buildpacks may be closed and locked.
>
> If you need support for a version of Dokku that is more than a year old, your issue may be closed without an answer. Please upgrade to a recent version.
## Description of problem
Output of the following commands
### How reproducible
-`uname -a`:
-`free -m`:
-`docker version`:
-`docker -D info`:
-`sigil -v`:
-`docker run -ti gliderlabs/herokuish:latest herokuish version`:
-`dokku version`:
-`dokku plugin`:
-`docker inspect CONTAINER_ID` (if applicable):
(BEWARE: `docker inspect` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX):
<-- Please replace APP_NAME with the name of your app -->
## Environment Information
### `dokku report APP_NAME` output
> This is required! Issues missing this information may be closed.
>
> For problems affecting all applications, the report output for a broken application is useful for our debugging.
> In these cases, you may run `dokku report` without any arguments to display the top-level reporting information.
### How (deb/make/rpm) and where (AWS, VirtualBox, physical, etc.) was Dokku installed?:
### Additional information
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable):
- If a deploy is failing or behaving unexpectedly:
- Application name
@@ -21,25 +44,5 @@ Output of the following commands
- If using buildpacks, which custom buildpacks are in use
- If using a `Dockerfile`, the contents of that file
- If it exists, the contents of your `Procfile`.
- Output of failing Dokku commands after running `dokku traceon`
(BEWARE: `traceon` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX):
- Output of failing Dokku commands after running `dokku trace:on`
(BEWARE: `trace:on` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXX):
[View the docs for upgrading](http://dokku.viewdocs.io/dokku/getting-started/upgrading/) from an older version of Dokku.
## Documentation
Full documentation - including advanced installation docs - are available online at [docs](http://dokku.viewdocs.io/dokku/)
## Support
You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](http://dokku.viewdocs.io/dokku/getting-started/troubleshooting/) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku)
## Contribution
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](http://dokku.viewdocs.io/dokku/getting-started/troubleshooting/) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
While we may not merge your PR as is, they serve to start conversations and improve the general Dokku experience for all users.
## Sponsors
See our list of past sponsors in the [SPONSORS](https://github.com/dokku/dokku/blob/master/SPONSORS.md) file.
Become a sponsor and get your logo on our README on Github with a link to your site. [[Become a sponsor](https://opencollective.com/dokku#sponsor)]
You can then proceed to the ip address or domain name associated with your server to complete the web-based installation.
If you wish for a more unattended installation method, see [these](https://dokku.com/docs/getting-started/install/debian/#unattended-installation) docs.
### Upgrade
[View the docs](https://dokku.com/docs/getting-started/upgrading/) for upgrading from an older version of Dokku.
## Documentation
Full documentation - including advanced installation docs - are available online at [https://dokku.com/docs/getting-started/installation/](https://dokku.com/docs/getting-started/installation/).
## Support
You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](https://dokku.com/docs/getting-started/troubleshooting/) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku).
## Contribution
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](https://dokku.com/docs/getting-started/troubleshooting/) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
While we may not merge your PR as is, they serve to start conversations and improve the general Dokku experience for all users.
echo"For dokku to build containers, it is strongly suggested that you have 1024 megabytes or more of free memory"
echo"If necessary, please consult this document to setup swap: http://dokku.viewdocs.io/dokku/advanced-installation/#vms-with-less-than-1gb-of-memory"
echo"If necessary, please consult this document to setup swap: https://dokku.com/docs/getting-started/advanced-installation/#vms-with-less-than-1-gb-of-memory"
fi
}
install-requirements(){
echo"--> Ensuring we have the proper dependencies"
apt-get update -qq > /dev/null
if[[$(lsb_release -sr)=="12.04"]];then
apt-get -qq -y install python-software-properties
fi
case"$DOKKU_DISTRO" in
debian)
if ! dpkg -l | grep -q software-properties-common;then
<strong>Warning:</strong> The SSH key filled out here can grant root access to the server. Please complete the setup as soon as possible.
</div>
<div class="checkbox">
<label><input id="vhost" name="vhost" type="checkbox" value="true"> Use <abbr title="Nginx will be run on port 80 and backend to your apps based on hostname">virtualhost naming</abbr> for apps</label>
<div class="row">
<div class="col">
<h3>Admin Access</h3>
<div class="form-group">
<label for="key">Public SSH Keys</label><br />
<textarea class="form-control" name="keys" rows="5" id="key" placeholder="Begins with 'ssh-rsa', 'ssh-dss', 'ssh-ed25519', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-nistp384', or 'ecdsa-sha2-nistp521'">{ADMIN_KEYS}</textarea>
<small class="form-text text-muted">Public keys allow users to ssh onto the server as the <code>dokku</code> user, as well as remotely execute Dokku commands. They are currently auto-populated from: <code>{AUTHORIZED_KEYS_LOCATION}</code>, and can be changed later via the <a href="https://dokku.com/docs/deployment/user-management/" target="_blank"><code>dokku ssh-keys</code></a> plugin.</small>
<input class="form-control" type="text" id="hostname" name="hostname" value="{HOSTNAME}" placeholder="A hostname or ip address such as {HOSTNAME}" />
<small class="form-text text-muted">This will be used as the default host for all applications, and can be changed later via the <a href="https://dokku.com/docs/configuration/domains/" target="_blank"><code>dokku domains:set-global</code></a> command.</small>
<label class="form-check-label" for="vhost">Use virtualhost naming for apps</label>
<small class="form-text text-muted">When enabled, Nginx will be run on port 80 and proxy requests to apps based on hostname.</small>
<small class="form-text text-muted">When disabled, a specific port will be setup for each application on first deploy, and requests to that port will be proxied to the relevant app.</small>
</div>
<div class="alert alert-warning small mt-3 d-{UFW_DISPLAY}" role="alert">
<strong>Warning:</strong> UFW is active. To allow traffic to specific ports, run <code>sudo ufw allow PORT</code> for the port in question.
if [[ -f "docs/appendices/${NEXT_VERSION}-migration-guide.md" ]]; then
HISTORY="${HISTORY}"$'\n\n'"See the [${NEXT_VERSION} migration guide](/docs/appendices/${NEXT_VERSION}-migration-guide.md) for more information on migrating to ${NEXT_VERSION}."
> The backup plugin was deprecated in 0.4.x, below are backup recommendations for 0.5.x and later.
## Backup and Migration Tutorial
The best plan for disaster recovery is to always keep multiple (remote) copies of your local repo, static assets and periodic database dumps. Backups should be regularly tested for data integrity and completeness.
## TLDR
> Warning: This method has many caveats. Please read this entire document before assuming these backups work as expected, and test your backups on a regular basis.
### Creating a backup
To create a backup, run the following command at a time when not executing any Dokku commands or app deployments:
```shell
exportBACKUP_TIME=$(date +%Y-%m-%d-%H-%M)
sudo mkdir -p /var/lib/dokku/services
sudo chown dokku:dokku /var/lib/dokku/services
mkdir -p /tmp/dokku-backups/
sudo tar -czvf "/tmp/dokku-backups/${BACKUP_TIME}.tar.gz" /home/dokku /var/lib/dokku/config /var/lib/dokku/data /var/lib/dokku/services /var/lib/dokku/plugins
```
This will create a point-in-time backup of your entire Dokku installation in the `/tmp/dokku-backups` directory. This backup may be moved offsite to another location via rsync, sftp, or some other protocol.
It is recommended that backups are regularly cleaned from the originating server and tested as necessary.
### Restoring a backup
To extract the backup onto another server, copy the backup to the server and extract it using the following command.
```shell
sudo tar -xzvf path/to/dokku/backup.tar.gz -C /
```
At this point, all datastores should be individually started and checked for data integrity. Once this is complete, individual applications can be rebuilt. Please consult the [process management documentation](/docs/processes/process-management.md#rebuilding-apps) for more information on how to rebuild applications.
## Caveats
### App config
Application config is largely held in a small number of places:
-`/var/lib/dokku/config`: Properties set and managed by plugins
-`/var/lib/dokku/data`: Files generated or extracted by various plugins
-`/home/dokku`: Certain parts of Dokku core store data in this location
Compressing these directories when no Dokku commands are running is enough to ensure a complete backup of the system.
### Code Repositories
Because Dokku is git based, rebuilding a deployed app is as easy as pushing from git. You can push to a new server by updating the `dokku` remote in you local app's repo.
@@ -11,7 +55,14 @@ git remote rm dokku
git remote add dokku dokku@[dokku.me:dokku.me]
git push dokku [master]
```
## Databases
### Docker Image and Tar-based Apps
These applications may fail to rebuild via the normal `ps:rebuild` method. Redeploy these apps by running the original commands used to deploy them
### Datastores
> Please note that point-in-time backups of the `/var/lib/dokku/services` directory may contain partially written data due to how various datastores work. Consult the official datastore documentation for the best documentation surrounding proper backup and restore procedures.
Some plugins, like the official [dokku-postgres](https://github.com/dokku/dokku-postgres) plugin, have built-in commands that allow non-volatile data be exported and imported.
Additionally, data for official datastores is located in the `/var/lib/dokku/services` directory. If the directory is restored and the plugin is available, a `dokku $SERVICE:start` may be enough to restart the service with the underlying data, so long as the datastore version does not change and the underlying data is not corrupt. If this is the case, it may be necessary to re-import all the data onto a fresh version of the datastore service.
### Plugins
The plugin directory is contained at the `/var/lib/dokku/plugins` directory. Core plugins will automatically be included in new installs, but custom plugins may not. The aforementioned `tar` creation command will back all plugins up, and the `tar` extract command will restore the plugins.
Note that restoring a plugin will not trigger any `install` or `dependencies` triggers. You will need to run these manually. See the [plugin management documentation](/docs/advanced-usage/plugin-management.md#installing-a-plugin) for more information on how to trigger these two hooks.
### Volumes and Static Assets
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) limit on apps, but it's best practice to keep binary assets outside of git. Since containers are considered volatile in Dokku, external stores like s3 or storage mounts should be used for non-volatile items like user uploads. The Dokku storage core plugin can be used to mount local directories / volumes inside the docker container.
See the [persistent storage documentation](/dokku/advanced-usage/persistent-storage/) for more details.
System administrators are highly encouraged to store persistent data in app-specific subdirectories of the path `/var/lib/dokku/data/storage`. This will help ensure restores of the aforementioned primary Dokku directories will restore service to all apps.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your application.
## Disaster Recovery
## Recovering app code
The best plan for disaster recovery is to always keep multiple (remote) copies of your local repo, static assets and periodic database dumps. In case of an emergency when your git repo and backups are completely lost, you can recover the last pushed copy from your remote Dokku server (assuming you still have the ssh key).
In case of an emergency when your git repo and backups are completely lost, you can recover the last pushed copy from your remote Dokku server (assuming you still have the ssh key).
Sometimes you need to run a command on at deployment time, but before an app is completely deployed.
Common use cases include:
Sometimes you need to run a command on deployment time, but before an app is completely deployed. Common use cases include:
* Checking a database is initialized
* Running database migrations
* Any commands required to set up the server (e.g. something like a Django `collectstatic`)
## `app.json` and `scripts.dokku`
To support this, Dokku provides support for a special `release` command within your app's `Procfile`, as well as a special `scripts.dokku` key inside of your app's `app.json` file. Be aware that all commands are run within the context of the built docker image - no commands affect the host unless there are volume mounts attached to your app.
Dokku accomplishes this by using an `app.json` file. The format in use is similar to format of Heroku's [app.json](https://devcenter.heroku.com/articles/app-json-schema).
However, Dokku currently only supports the nodes `scripts.dokku.predeploy` and `scripts.dokku.postdeploy`.
For buildpack apps, simply place an `app.json` file in the root of your repository.
For dockerfile apps, place `app.json` in the configured `WORKDIR` directory; otherwise Dokku defaults to the buildpack app behavior of looking in `/app`.
>NOTE: postdeploy changes are *NOT* committed to the app image.
Each "phase" has different expectations and limitations:
### Example app.json
-`app.json`: `scripts.dokku.predeploy`
- When to use: This should be used if your app does not support arbitrary build commands and you need to make changes to the built image.
- Are changes committed to the image at this phase: Yes
- Example use-cases
- Bundling assets in a slightly different way
- Installing a custom package from source or copying a binary into place
-`app.json`: `scripts.dokku.postdeploy`
- When to use: This should be used in conjunction with external systems to signal the completion of your deploy.
- Are changes committed to the image at this phase: No
- Example use-cases
- Notifying slack that your app is deployed
- Coordinating traffic routing with a central load balancer
-`app.json`: `scripts.postdeploy`
- When to use: This should be used when you wish to run a command _once_, after the app is created and not on subsequent deploys to the app.
- Are changes committed to the image at this phase: No
- Example use-cases
- Setting up OAuth clients and DNS
- Loading seed/test data into the app’s test database
-`Procfile`: `release`
- When to use: This should be used in conjunction with external systems to signal the completion of your app image build.
- Are changes committed to the image at this phase: No
- Example use-cases
- Sending CSS, JS, and other assets from your app’s slug to a CDN or S3 bucket
- Priming or invalidating cache stores
- Running database migrations
Additionally, if using a Dockerfile with an `ENTRYPOINT`, the deployment task is passed to that entrypoint as is. The exceptions are if the entrypoint is one of the following:
-`["/tini", "--"]`
-`["/bin/tini", "--"]`
-`["/usr/bin/tini", "--"]`
-`["/usr/local/bin/tini", "--"]`
Please keep the above in mind when utilizing deployment tasks.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation.md) docs for more information on building your own custom plugin.
## `app.json` deployment tasks
Dokku provides limited support for the `app.json` manifest from Heroku (documentation available [here](https://devcenter.heroku.com/articles/app-json-schema)). The keys available for use with Deployment Tasks are:
-`scripts.dokku.predeploy`: This is run _after_ an app's docker image is built, but _before_ any containers are scheduled. Changes made to your image are committed at this phase.
-`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.
```json
{
"name":"barebones nodejs",
"description":"A barebones Node.js app using Express 4.",
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). This command is executed _after_ an app's docker image is built, but _before_ any containers are scheduled. This is also run _after_ any command executed by `scripts.dokku.predeploy`.
To use the `release` command, simply add a `release` stanza to your Procfile.
@@ -22,59 +23,103 @@ Dokku deploys your application in multiple "phases" and the `docker-options` plu
-`build`: the container that executes the appropriate buildpack
-`deploy`: the container that executes your running/deployed application
-`run`: the container that executes any arbitrary command via `dokku run myapp`
-`run`: the container that executes any arbitrary command via `dokku run`
Manipulation of docker options will not restart running containers. This enables multiple options to be set/unset before final application. As such, changing an app's docker options must be followed by a `dokku ps:rebuild` in order to take effect.
More information on supported Docker options can be found here: https://docs.docker.com/engine/reference/commandline/run/.
## Examples
### Add Docker options
Add some options for the deployed/running app and when executing [`dokku run`](/dokku/deployment/one-off-processes/):
Add some options for the deployed/running app and when executing [`dokku run`](/docs/processes/one-off-tasks.md):
```shell
# Mount a host volume in a Docker container: "-v /host/path:/container/path"
dokku docker-options:add node-js-app run "-v /var/log/node-js-app:/app/logs"
```
> Note: When [mounting a host directory](https://docs.docker.com/engine/reference/run/#volume-shared-filesystems) in a Dokku app you should first create that directory as user `dokku` and then mount the directory under `/app` in the container using `docker-options` as above. Otherwise the app will lack write permission in the directory.
### Output Docker options
```shell
dokku docker-options myapp
```
```
Deploy options:
-v /home/dokku/logs/myapp:/app/logs
Run options:
-v /home/dokku/logs/myapp:/app/logs
```
### Remove a Docker option
```shell
dokku docker-options:remove myapp run "-v /home/dokku/logs/myapp:/app/logs"
dokku docker-options:remove node-js-app run "-v /var/log/node-js-app:/app/logs"
```
## Advanced usage
### Clear all Docker options for an app
In your applications folder `/home/dokku/app_name` create a file called `DOCKER_OPTIONS_RUN` (or `DOCKER_OPTIONS_BUILD` or `DOCKER_OPTIONS_DEPLOY`).
Inside this file list one Docker option per line. For example:
Docker options can be removed for a specific app using the `docker-options:clear` command.
```shell
--link container_name:alias
-v /host/path:/container/path
-v /another/container/path
dokku docker-options:clear node-js-app
```
The above example will result in the following options being passed to Docker during `dokku run`:
```
-----> Clearing docker-options for node-js-app on all phases
```
One or more valid phases can also be specified. Phases are comma delimited, and specifying an invalid phase will result in an error.
@@ -8,41 +8,108 @@ The preferred method to mount external containers to a Dokku managed container,
```
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
```
## Ideology and Background
> The storage plugin is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy/run phase.
The storage plugin requires explicit paths on the host side. This is intentional to ensure that new users avoid running into unexpected results with implicit paths that may not exist (a feature deprecate in [Docker 1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0])). The container directory is created for the mount point in the container. Any existing directory contents are not accessible after a mount is added to the container. Dokku creates a new directory `/var/lib/dokku/data/storage` during installation, it's the general consensus that new users should use this directory. Mounts are only available at run and deploy times, you must redeploy (restart) an app to mount or unmount to an existing app's container.
The storage plugin supports the following mount points:
- explicit paths that exist on the host
- docker volumes
## Usage
This example demonstrates how to mount the recommended directory to `/storage` inside the container:
This example demonstrates how to mount the recommended directory to `/storage` inside an application called `node-js-app`. For simplicity, the Dokku project recommends using the directory `/var/lib/dokku/data/storage` directory as the root host path for mounts. This directory is created on Dokku installation.
Dokku will then mount the shared contents of `/var/lib/dokku/data/storage` to `/storage` inside the container.
Dokku will then mount the shared contents of `/var/lib/dokku/data/storage/node-js-app` to `/storage` inside the container. Mounts are only available for containers crated via `run` and by the deploy process, and not during the build process. In addition, the host path is never auto-created by either Dokku or Docker, and should be an explicit path, not one relative to the current working directory.
A more complete workflow may require making a custom directory for your application and mounting it within your `/app/storage` directory instead. The mount point is *not*relative to your application's working directory, and is instead relative to the root of the container.
> If the `/storage` path within the container had pre-existing content, the container files will be overrwritten. This may be an issue for users that create assets at build time but then mount a directory at the same place during runtime. Files are not merged.
Once you have mounted persistent storage, you will also need to restart the application. See the
[process scaling documentation](/docs/processes/process-management.md) for more information.
```shell
# creating storage for the app 'ruby-rails-sample'
A more complete workflow may require making a custom directory for your application and mounting it within your `/app/storage` directory instead. The mount point is *not* relative to your application's working directory, and is instead relative to the root (`/`) of the container.
# as of 0.7.x, you should chown using the `32767` user and group id
You can mount one or more directories as desired by following the above pattern.
### Directory Permissions
The host directory should always be owned by the container user and group id. If this is not the case, files may not persist when written to mounted storage.
- Buildpacks via Herokuish: Use `32767:32767` as the file permissions
- For Cloud Native Buildpacks: This will depend on the builder in question, but can be retrieved via the `CNB_USER_ID` and `CNB_GROUP_ID` environment variables on the builder image. Common builders are as follows:
- heroku/buildpacks: `1000:1000`
- cloudfoundry/cnb: `2000:2000`
- packeto: `2000:2000`
- Dockerfile and Docker Image: Use the user and group id which corresponds to the one running the process within the container.
### Displaying storage reports for an app
> New as of 0.8.1
You can get a report about the app's storage status using the `storage:report` command:
@@ -66,24 +133,19 @@ Your app may have services that are running in memory and need to be backed up l
By default, Dokku will only bind storage mounts during the deploy and run phases. Under certain conditions, one might want to bind a storage mount during the build phase. This can be accomplished by using the `docker-options` plugin directly.
You cannot use mounted volumes during the build phase of a Dockerfile deploy. This is because Docker does not support volumes when executing `docker build`.
> Note: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
## Docker-Options Note
The storage plugin is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy phase.
## Application User and Persistent Storage file ownership (buildpack apps only)
> New as of 0.7.1
## Application User and Persistent Storage file ownership (buildpack apps only)
By default, Dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
> NOTE: this user must exist in your herokuish image.
Additionally, Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
> Warning: All plugin commands other than `plugin:list` and `plugin:help` require sudo access and must be run directly from the Dokku server.
### Checking if a plugin is installed
You can check if a plugin has been installed via the `plugin:installed` command:
```shell
dokku plugin:installed postgres
```
### Installing a plugin
Installing a plugin is easy as well using the `plugin:install` command. This command will also trigger the `install` pluginhook on all existing plugins.
The most common usage is to install a plugin from a url. This url may be any of the following:
-`git`: For git+ssh based plugin repository clones.
-`ssh`: For git+ssh based plugin repository clones.
-`file`: For copying plugins from a path on disk.
-`https`: For http based plugin repository clones.
Additionally, any urls with the extensions `.tar.gz` or `.tgz` are treated as Gzipped Tarballs for installation purposes and will be downloaded and extracted into place.
You can also uninstall a third-party plugin using the `plugin:uninstall` command:
For git-based plugin installation, a commit SHA-like object may be specified (tag/branch/commit sha) via the `--committish` argument and Dokku will attempt to install the specified commit object.
Plugin names are interpolated based on the repository name minus the `dokku-` prefix. If the plugin being installed has a name other than what matches the repository name - or another name is desired - the `--name` flag can be used to override this interpolation.
The `--core` flag may also be indicated as the sole argument, though it is only for installation of core plugins, and thus not useful for end-user installations.
```shell
dokku plugin:install --core
```
Finally, all flags may be omitted to trigger the `install` procedures for both core and third-party plugins:
```shell
dokku plugin:install
```
### Installing plugin dependencies
In some cases, plugins will have system-level dependencies. These are not automatically installed via `plugin:install`, and must be separately via the `plugin:install-dependencies` command. This will run through all the `dependencies` trigger for all plugins.
```shell
dokku plugin:install-dependencies
```
This command may also target _just_ core plugins via the `--core` flag. This is usually only useful for source-based installs of Dokku.
```shell
dokku plugin:install-dependencies --core
```
### Updating a plugin
An installed, third-party plugin can be updated can updated via the `plugin:update` command. This should be done after any upgrades of Dokku as there may be changes in the internal api that require an update of how the plugin interfaces with Dokku.
Please note that this command is only valid for plugin installs that were backed by a git-repository.
```shell
dokku plugin:update postgres
```
```
Plugin (postgres) updated
```
An optional commit SHA-like object may be specified.
```shell
dokku plugin:update postgres 2.0.0
```
### Uninstalling a plugin
Third party plugins can be uninstalled using the `plugin:uninstall` command:
Enabling or disabling a plugin can also be useful in cases where you are debugging whether a third-party plugin is causing issues in your Dokku installation:
### Disabling a plugin
Disabling a plugin can also be useful for debugging whether a third-party plugin is causing issues in a Dokku installation. Another common use case is for disabling core functionality for replacement with a third-party plugin.
Finally, you can update an installed third-party plugin. This should be done after any upgrades of Dokku as there may be changes in the internal api that require an update of how the plugin interfaces with Dokku.
### Triggering a plugin trigger
The `plugin:trigger` can be used to call any internal plugin trigger. This may have unintended consequences, and thus should only be called for development or debugging purposes.
proxy:ports <app> # List proxy port mappings for app
proxy:ports-add <app> <scheme>:<host-port>:<container-port> [<scheme>:<host-port>:<container-port>...] # Set proxy port mappings for app
proxy:ports-clear <app> # Clear all proxy port mappings for app
proxy:ports-remove <app> <host-port> [<host-port>|<scheme>:<host-port>:<container-port>...] # Unset proxy port mappings for app
proxy:set <app> <proxy-type> # Set proxy type for 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.
## Container network interface binding
> New as of 0.5.0
By default, the deployed docker container running your app's web process will bind to the internal docker network interface (i.e. `docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CONTAINER_ID`). This behavior can be modified per app by disabling the proxy (i.e. `dokku proxy:disable <app>`). In this case, the container will bind to an external interface (i.e. `0.0.0.0`) and your app container will be directly accessible by other hosts on your network.
> If a proxy is disabled, Dokku will bind your container's port to a random port on the host for every deploy, e.g. `0.0.0.0:32771->5000/tcp`.
By way of example, in the default case, each container is bound to the docker interface:
```shell
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1b88d8aec3d1 dokku/node-js-app:latest "/bin/bash -c '/star About a minute ago Up About a minute node-js-app.web.1
```
As such, the container's IP address will be an internal IP, and thus it is only accessible on the host itself:
However, you can disable the internal proxying via the `proxy:disable` command so that it will listen on the host's IP address:
```shell
dokku proxy:disable node-js-app
# container bound to all interfaces
docker ps
```
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6499edb0edb dokku/node-js-app:latest "/bin/bash -c '/star About a minute ago Up About a minute 0.0.0.0:49153->5000/tcp node-js-app.web.1
```
## Proxy port mapping
> 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.
To inspect the port mapping for a given application, use the `proxy:ports` command:
```shell
dokku proxy:ports node-js-app
```
```
-----> Port mappings for node-js-app
-----> scheme host port container port
http 80 5000
```
The above application is listening on the host's port `80`, which we can test via curl:
```shell
curl http://node-js-app.dokku.me
```
```
Hello World!
```
There are cases where we may wish for the service to be listening on more than one port, such as port 8080. Normally, this would not be possible:
```shell
curl http://node-js-app.dokku.me:8080
```
```
curl: (7) Failed to connect to node-js-app.dokku.me port 8080: Connection refused
```
However, we can use the `proxy:ports-add` command to add a second external port mapping - `8080` - to our application's port `5000`.
We can now test that port 80 still responds properly:
```shell
curl http://node-js-app.dokku.me
```
```
Hello World!
```
And our new listening port of `8080` also works:
```shell
curl http://node-js-app.dokku.me:8080
```
```
Hello World!
```
You can also remove a port mapping that is no longer necessary:
```shell
dokku proxy:ports-remove node-js-app http:80:5000
```
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` syntax detailed above.
## Proxy 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 both the `http` and `https` schemes.
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:
resource:limit [--process-type <process-type>] [RESOURCE_OPTS...] <app> # Limit resources for a given app/process-type combination
resource:limit-clear [--process-type <process-type>] <app> # Limit resources for a given app/process-type combination
resource:report [<app>] [<flag>] # Displays a resource report for one or more apps
resource:reserve [--process-type <process-type>] [RESOURCE_OPTS...] <app> # Reserve resources for a given app/process-type combination
resource:reserve-clear [--process-type <process-type>] <app> # Reserve resources for a given app/process-type combination
```
The resource plugin is meant to allow users to limit or reserve resources for a given app/process-type combination.
## Usage
By default, Dokku allows unlimited resource access to apps deployed on a server. In some cases, it may be desirable to limit this on a per-app or per-process-type basis. The `resource` plugin allows management of both resource "limits" and resource "reservations", where each resource request type has specific meaning to the scheduler in use for a given app.
> Warning: The meaning of a values and it's units are specific to the scheduler in use for a given app. If a value is incorrect for a scheduler, this may result in containers failing to start correctly. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
Valid resource options include:
-`--cpu`
-`--memory`
-`--memory-swap`
-`--network`
-`--network-ingress`
-`--network-egress`
-`--nvidia-gpu`
See the [Supported Resource Management Properties](/docs/advanced-usage/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
### Resource Limits
When specified and supported, a resource limit will ensure that your app does not go _over_ the specified value. If this occurs, the underlying scheduler may either cap resource utilization, or it may decide to terminate and reschedule your process.
Resource limits may be set via the `resource:limit` command:
```shell
dokku resource:limit --memory 100 node-js-app
```
```
=====> Setting resource limits for node-js-app
memory: 100
```
Multiple resources can be limited in a single call:
=====> Setting resource limits for node-js-app (worker)
cpu: 100
memory: 100
```
A resource value can be individually cleared by setting the value to the special value `clear`.
```shell
dokku resource:limit --cpu clear node-js-app
```
```
=====> Setting resource limits for node-js-app
cpu: cleared
```
#### Displaying Resource Limits
Running the `resource:limit` command without any flags will display the currently configured default app limits.
```shell
dokku resource:limit node-js-app
```
```
=====> resource limits node-js-app information [defaults]
cpu:
memory:
memory-swap: 100
network: 100
network-ingress:
network-egress:
nvidia-gpu:
```
This may also be combined with the `--process-type` flag to see app limits on a process-type level. Note that the displayed values are not merged with the defaults.
```shell
dokku resource:limit --process-type web node-js-app
```
```
=====> resource limits node-js-app information (web)
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
nvidia-gpu:
```
#### Clearing Resource Limits
In cases where the values are incorrect - or there is no desire to limit resources - resource limits may be cleared using the `resource:limit-clear` command.
```shell
dokku resource:limit-clear node-js-app
```
```
-----> Clearing resource limit for node-js-app
```
Defaults can also be cleared by leaving the app unspecified.
```shell
dokku resource:limit-clear
```
```
-----> Clearing default resource limits
```
### Resource Reservations
When specified and supported, a resource reservation will ensure that your server has _at least_ the specified resources before placing a given app's process. If there a resource exhaustion, future rebuilds and deploys may fail.
Resource reservations may be set via the `resource:reserve` command:
```shell
dokku resource:reserve --memory 100 node-js-app
```
```
=====> Setting resource reservation for node-js-app
memory: 100
```
Multiple resources can be limited in a single call:
=====> Setting resource reservation for node-js-app (worker)
cpu: 100
memory: 100
```
A resource value can be individually cleared by setting the value to the special value `clear`.
```shell
dokku resource:reserve --cpu clear node-js-app
```
```
=====> Setting resource reservation for node-js-app
cpu: cleared
```
#### Displaying Resource Reservations
Running the `resource:reserve` command without any flags will display the currently configured default app reservations.
```shell
dokku resource:reserve node-js-app
```
```
=====> resource reservation node-js-app information [defaults]
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
nvidia-gpu:
```
This may also be combined with the `--process-type` flag to see app reservations on a process-type level. Note that the displayed values are not merged with the defaults.
```shell
dokku resource:reserve --process-type web node-js-app
```
```
=====> resource reservation node-js-app information (web)
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
nvidia-gpu:
```
#### Clearing Resource Reservations
In cases where the values are incorrect - or there is no desire to reserve resources - resource reservations may be cleared using the `resource:reserve-clear` command.
```shell
dokku resource:reserve-clear node-js-app
```
```
-----> Clearing resource reservation for node-js-app
```
Defaults can also be cleared by leaving the app unspecified.
```shell
dokku resource:reserve-clear
```
```
-----> Clearing default resource reservation
```
### Displaying resource reports for an app
You can get a report about the app's resource status using the `resource:report` command:
```shell
dokku resource:report
```
```
=====> node-js-app resource information
web limit cpu:
web limit memory: 1024
web limit memory swap: 0
web limit network: 10
web limit network ingress:
web limit network egress:
web limit nvidia gpu:
web reservation cpu:
web reservation memory: 512
web reservation memory swap:
web reservation network: 8
web reservation network ingress:
web reservation network egress:
web reservation nvidia gpu:
=====> python-sample resource information
web limit cpu:
web limit memory:
web limit memory swap:
web limit network:
web limit network ingress:
web limit network egress:
web limit nvidia gpu:
web reservation cpu:
web reservation memory:
web reservation memory swap:
web reservation network:
web reservation network ingress:
web reservation network egress:
web reservation nvidia gpu:
=====> ruby-sample resource information
web limit cpu:
web limit memory:
web limit memory swap:
web limit network:
web limit network ingress:
web limit network egress:
web limit nvidia gpu:
web reservation cpu:
web reservation memory:
web reservation memory swap:
web reservation network:
web reservation network ingress:
web reservation network egress:
web reservation nvidia gpu:
```
You can run the command for a specific app also.
```shell
dokku resource:report node-js-app
```
```
=====> node-js-app resource information
web limit cpu:
web limit memory: 1024
web limit memory swap: 0
web limit network: 10
web limit network ingress:
web limit network egress:
web limit nvidia gpu:
web reservation cpu:
web reservation memory: 512
web reservation memory swap:
web reservation network: 8
web reservation network ingress:
web reservation network egress:
web reservation nvidia gpu:
```
You can pass flags which will output only the value of the specific information you want. For example:
These scheduler implementations may not be complete, though provide enough functionality for a user to get an app deployed via the underlying scheduler.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
scheduler-docker-local:report [<app>] [<flag>] # Displays a scheduler-docker-local report for one or more apps
scheduler-docker-local:set <app> <key> (<value>) # Set or clear a scheduler-docker-local property for an app
```
> New as of 0.12.0
Dokku natively includes functionality to manage application lifecycles for a single server using the `scheduler-docker-local` plugin. It is the default scheduler, but as with all schedulers, it is set on a per-application basis. The scheduler can currently be overridden by running the following command:
As it is the default, unsetting the `DOCKER_SCHEDULER` config variable is also a valid way to reset the scheduler.
```shell
dokku config:unset node-js-app DOCKER_SCHEDULER
```
## Usage
### Disabling chown of persistent storage
The `scheduler-docker-local` plugin will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. You may disable this by running the following `scheduler-docker-local:set` command for your application:
This plugin implements various functionality through `plugn` triggers to integrate with Docker for running apps on a single server. The following functionality is supported by the `scheduler-docker-local` plugin.
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-app-rename-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-app-status`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-is-deployed`
-`scheduler-logs`
-`scheduler-logs-failed`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
-`scheduler-tags-create`
-`scheduler-tags-destroy`
## Supported Resource Management Properties
The `docker-local` scheduler supports a minimal list of resource _limits_ and _reservations_. The following properties are supported:
### Resource Limits
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
- See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
### Resource Reservations
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
By default, Dokku will ship a PCI Compliant nginx configuration. For developers whose users are on older browsers or mobile devices, you may need to ship a custom `nginx.conf.sigil` to enable ciphers for older browsers.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
## Nginx Error Pages
We now ship with nicer error pages by default. You are free to customize your Dokku installation via a custom `nginx.conf.sigil` to change what error pages are displayed in different circumstances.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
The following commands were previously deprecated and were removed in this release.
-`apps`: Use `apps:list` instead.
-`certs`: Use `certs:report` instead.
-`certs:info`: Use `certs:report` instead.
-`checks`: Use `checks:report` instead.
-`docker-options`: Use `docker-options:report` instead.
-`domains`: Use `domains:report` instead.
-`plugin`: Use `plugin:list` instead.
-`proxy`: Use `proxy:report` instead.
-`trace`: Use `trace:on` or `trace:off` instead.
-`ps`: Use `enter` with a container ID instead to run `ps auxww` within a container.
The refactor of the proxy plugin removes the following functions from being sourced in plugins:
-`proxy#get_app_proxy_port_map()`
-`proxy#list_app_proxy_ports()`
-`proxy#filter_app_proxy_ports()`
-`proxy#add_proxy_ports()`
-`proxy#remove_proxy_ports()`
-`proxy#set_proxy_ports()`
The informal policy is to allow removal of functions within a `functions` file if they are not used in OSS plugins. Should you be affected by any such removals, please file an issue to expose the functionality via a plugin trigger.
### Function renames
-`tar#tar_in_cmd` was renamed to `tar#cmd-tar-in`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
-`tar#tar_from_cmd` was renamed to `tar#cmd-tar-from`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
### Remove support for Unsupported Operating Systems
Dokku will no longer distribute packages for Ubuntu versions that have reached either End of Life or End of Standard Support (for LTS releases). This currently includes the following releases:
- Ubuntu 14.04 (trusty)
- Ubuntu 14.10 (utopic)
- Ubuntu 15.04 (vivid)
- Ubuntu 15.10 (wily)
- Ubuntu 16.10 (yakkety)
- Ubuntu 17.04 (zesty)
- Ubuntu 17.10 (artful)
Dokku will no longer distribute packages for Debian versions that are not `stable` or `oldstable`. This currently includes the following releases:
- Debian 7 (wheezy)
- Debian 8 (jessie)
### App report flags
The `--git-sha` flag was moved from the `apps:report` command to the `git:report` command.
## App report output
When an app is not deployed, the `apps:report` command no longer shows the message `not deployed`. Please use the `--deployed` flag on `ps:report` instead to see if the app has been deployed.
## Changes
### App report flags
The following changes on the `apps:report` command were made in this release:
- The `--deploy-source` flag was renamed to `--app-deploy-source`.
- The `--locked` flag was renamed to `--app-locked`.
### Network report flags
The following changes on the `network:report` command were made in this release:
- The `--network-listeners` flag was renamed to `--network-web-listeners`.
### Plugin Triggers
- The `network-get-port` trigger was incorrectly documented to have the `isHerokuishContainer` argument as the third argument. The code has been fixed to respect the documentation.
- The `network-get-listeners` trigger now takes an additional `processType` argument. If not specified, it defaults to `web`. This default will be removed in an upcoming release.
## Deprecations
-`nginx:show-conf` has been deprecated in favor of `nginx:show-config`.
-`proxy#is_app_proxy_enabled()` is deprecated in favor of `plugn trigger proxy-is-enabled`.
-`proxy#get_app_proxy_type()` is deprecated in favor of `plugn trigger proxy-type`.
-`apps#apps_create()` is deprecated in favor of `plugn trigger app-create`.
-`apps#apps_destroy()` is deprecated in favor of `plugn trigger app-destroy`.
-`apps#apps_exists()` is deprecated in favor of `plugn trigger app-exists`.
-`apps#apps_maybe_create()` is deprecated in favor of `plugn trigger app-maybe-create`.
-`plugin trigger network-get-listeners` usage without a second `processType` argument is deprecated.
-`.NGINX_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_PORT`.
-`.NGINX_SSL_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_SSL_PORT`.
-`.DOKKU_APP_LISTENERS` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.DOKKU_APP_WEB_LISTENERS`.
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
## Deprecations
-`git#git_deploy_branch()` is deprecated in favor of `plugn trigger git-deploy-branch`.
- The `config` command is deprecated in favor of `config:show`.
- Usage of this command in conjunction with either the `--export` or `--shell` flag is deprecated in favor of `config:export --format` with the correct format value (`exports` or `shell`, respectively).
- The `nginx:build-config` command is deprecated in favor of `proxy:build-config`.
## Removals
The `apps:destroy` command no longer takes a second argument `force`. Instead, this can be passed as the `--force` flag, either globally or as a flag to the command itself.
The `proxy:enable` and `proxy:disable` no longer restart apps when setting the `DOKKU_DISABLE_PROXY` environment variable. A future release will disable usage of `DOKKU_DISABLE_PROXY` altogether.
- Calling `logs:failed` without either a `<name>` or the `--all` flag is deprecated.
## Changes
- Underscores are no longer valid characters in app names. Please rename applications before upgrading.
- Process type names specified in Procfile may no longer use characters not valid in DNS Label Names ([RFC 1123](https://tools.ietf.org/html/rfc1123)).
- The minimum Docker version is now 17.05.0.
- The `common.GetDeployingAppImageName()` function now returns an `error` as the second return argument instead of calling `common.LogFail()` internally.
- Setting `DOKKU_DISABLE_ANSI_PREFIX_REMOVAL` is deprecated; Dokku 0.23.0 will avoid removing the `remote:` ansi prefix entirely. No warning will be added in this release.
## Removals
The `ps` command has had a few removals as a result of a rewrite to Golang:
- The `ps:set-restart-policy` command has been removed in favor the `ps:set` command.
- The `ps:restart-policy` command has been removed in favor of the `ps:report` command.
- The `ps:rebuildall` command has been removed in favor of calling the `ps:rebuild` with the `--all` flag instead of an app name.
- The `ps:restartall` command has been removed in favor of calling the `ps:restart` with the `--all` flag instead of an app name.
- The `ps:stopall` command has been removed in favor of calling the `ps:stop` with the `--all` flag instead of an app name.
- The `ps:startall` command has been removed in favor of calling the `ps:start` with the `--all` flag instead of an app name.
- The `DOKKU_PROCFILE` file is no longer located in the git directory for a given app on the server. It's location is currently not exposed.
- The `procfile-get-command` plugin trigger no longer takes a `procfile path` as the final argument.
- All `ps` functions have been removed. Please us a trigger as appropriate or file a PR to have a new trigger/wrapper function added.
- The `plugin:list` command no longer outputs the version for the `plugn` binary.
- Users building docker images that run Dokku will need to use a new sudoer wrapper for the `docker-image-labeler` 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 `dokku` user's cron is now in use by Dokku itself. Customizations will be overwritten. Users are encouraged to use a cron entry in `/etc/cron.d/dokku` to avoid this issue.
- As of 0.23.0, Dokku will now inject the `max-size` log driver option for applications. This is restricted to app-configured log driver values empty, `local` or `json-file` in 0.23.1 to increase setup compatibility. Users who configure alternative log drivers at the system level will need to either set the global `max-size` property to `unlimited` or switch to the built-in `vector` logging support.
- The commands `proxy:enable`, `proxy:disable` and `proxy:build-config` now support the `--all` flag in addition to general parallelism.
- The `builder-cnb` plugin has been renamed `builder-pack`, and all related plugin triggers have had the suffix `-cnb` changed to `-pack`.
## Deprecations
- The 1.0.0 release of Dokku will no longer select buildpack builders over dockerfile builders if both builders match. Instead, Dokku will choose the first builder that responds to the `builder-detect` trigger. Users that wish to use a specific builder may set a builder using the `builder:set` command, which will force Dokku to use the specified builder regardless of what might be auto-detected.
- The `tags` plugin is deprecated in favor of the [`git:from-image`](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) command. It will be removed in the next minor release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-image`.
- The `tar` plugin is deprecated in favor of the [`git:from-archive`](/docs/deployment/methods/git.md#initializing-an-app-repository-from-an-archive-file) command. It will be removed in the next minor release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-archive`.
-`DOKKU_CHECKS_ENABLED` has been migrated to `DOKKU_CHECKS_SKIPPED`
-`DOKKU_CHECKS_DISABLED` is now a thing
- The values for the above can be a comma-separated list of process-types or the literal string `_all_`
- See the [updated `checks`](/dokku/deployment/zero-downtime-deploys/) docs for more info
- See the [updated `checks`](/docs/deployment/zero-downtime-deploys.md) docs for more info
## Proxy port mapping
- You can now configure host -> container proxy port mappings
- The UI is handled by the [proxy](/dokku/advanced-usage/proxy-management/) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
- The UI is handled by the [proxy](/docs/networking/proxy-management.md) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
- Default port mappings
- buildpack apps will be set to `http:80:5000` and will also include `https:443:5000` if SSL is enabled.
- dockerfile apps with explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on each exposed port that proxies to the same port of the deployed application container.
- You may override this behavior with the [`proxy:ports-*` commands](/dokku/advanced-usage/proxy-management/) or by directly setting `DOKKU_PROXY_PORT_MAP` with the `config:set` command
- You may override this behavior with the [`proxy:ports-*` commands](/docs/networking/proxy-management.md) or by directly setting `DOKKU_PROXY_PORT_MAP` with the `config:set` command
- dockerfile apps without explicitly exposed ports will behave the same as a buildpack app
- NOTE: These defaults **are not** automatically changed on subsequent pushes and must be manipulated with the aforementioned commands
We should now properly handle file ownership for mounted directories. This was enhanced in 0.7.1. See the [persistent storage documentation](/dokku/advanced-usage/persistent-storage/) for more details.
We should now properly handle file ownership for mounted directories. This was enhanced in 0.7.1. See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more details.
## Restart Policies
If you previously managed container restart policies via docker-options, these can now be managed natively via the built-in `ps` plugin. There is no migration necessary. See the [restart policy documentation](/dokku/deployment/process-management/#restart-policies) for more details.
If you previously managed container restart policies via docker-options, these can now be managed natively via the built-in `ps` plugin. There is no migration necessary. See the [restart policy documentation](/docs/processes/process-management.md#restart-policies) for more details.
## SSH Keys
Dokku now has an `ssh-keys` plugin that can be used to manage ssh keys for the `dokku` user on the host operating system. See the [user management documentation](/dokku/deployment/user-management/) for more details.
Dokku now has an `ssh-keys` plugin that can be used to manage ssh keys for the `dokku` user on the host operating system. See the [user management documentation](/docs/deployment/user-management.md) for more details.
You can now set global and app domains via `domains:set` and `domains:set-global`. See the [domains documentation](/docs/configuration/domains/) for more details.
## Plugin Uninstallation
A new `uninstall` plugin trigger was introduced. This functionality may be in use for newer plugins, so be aware that older Dokku versions may require manual cleanup.
See the [uninstall trigger documentation](/docs/development/plugin-triggers/#uninstall) for implementation instructions.
## Deployment Tasks
Should a pre or post deployment task fail, we now fail the entire deploy.
## Nginx HTTP2 Support
Due to bugs in Nginx, the minimum version for HTTP2 is now 1.11.5.
There is an ongoing migration to rewrite Dokku in Golang. The reasons are beyond the scope of this document, but this may impact any patches you have for Dokku. As of 0.9.0, only the `repo` plugin is in Golang.
The following shall remain true, regardless of the state of our rewrite:
- You will be able to write custom plugins in any language.
- You will be able to enable or disable core plugins.
-`plugn` will continue to be used for executing plugin triggers.
- We will provide bash wrappers that can be sourced to execute core functionality that is implemented in golang.
Given the constraints, running Dokku commands remotely via SSH is fine. For certain configurations, the extra complication of manually invoking ssh can be a burden.
While Dokku does not yet have an official client, there are a multitude of ways in which you can interact with your Dokku installation. The easiest is to use the **bash** client, though you may wish to use another.
The easiest way to interact with Dokku remotely is by using the official client. Documented below are the various clients that you may wish to use.
## (bash, zsh, etc.) `dokku_client.sh`
## Official Client
Of all methods, this is the *most* official method of interacting with your Dokku installation. It is a bash script that interacts with a remote Dokku installation via ssh. It is available in `contrib/dokku_client.sh` in the root of the Dokku repository.
To install, simply clone the Dokku repository down and add the `dokku` alias pointing at the script:
```shell
git clone git@github.com:dokku/dokku.git ~/.dokku
# optional: make sure that the dokku_client.sh version matches your Dokku version
cd ~/.dokku
git checkout <tag/branch>
# add the following to either your
# .bashrc, .bash_profile, or .profile file
aliasdokku='$HOME/.dokku/contrib/dokku_client.sh'
```
Alternatively, if using another shell such as **zsh**, create an alias command which invokes the script using **bash**:
```shell
# zsh: add the following to either .zshenv or .zshrc
# fish: add the following to ~/.config/fish/config.fish
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
# csh: add the following to .cshrc
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
```
Configure the `DOKKU_HOST` environment variable or run `dokku` from a repository with a git remote named `dokku` pointed at your Dokku host in order to use the script as normal.
You can also configure a `DOKKU_PORT` environment variable if you are running ssh on a non-standard port. This defaults to `22`.
See the [remote commands documentation](/docs/deployment/remote-commands.md) for more information on how to install and use the official client.
## (nodejs) dokku-toolbelt
@@ -51,7 +20,7 @@ See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more
## (python) dokku-client
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
@@ -12,39 +12,40 @@ Let's take a quick look at the current Dokku nginx plugin that's shipped with Do
## Installing a plugin
[See the plugin management documentation](/dokku/advanced-usage/plugin-management/).
[See the plugin management documentation](/docs/advanced-usage/plugin-management.md).
## Creating your own plugin
[See the full documentation](/dokku/development/plugin-creation/).
[See the full documentation](/docs/development/plugin-creation.md).
## Official Plugins (Beta)
## Official Plugins
The following plugins are available and provided by Dokku maintainers. Where noted, these plugins should be considered beta software and may not have been used as thoroughly as community plugins. Please file issues against their respective issue trackers.
The following plugins are available and provided by Dokku maintainers. Please file issues against their respective issue trackers.
<sup>1</sup> On Heroku similar functionality is offered by the [heroku-labs pipeline feature](https://devcenter.heroku.com/articles/labs-pipelines), which allows you to promote builds across multiple environments (staging -> production)
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>4</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>4</sup> Adds the ability to sync an application repo with a remote Github repo (useful for automated rebuilds without needing a git push from an external system
<sup>5</sup> Adds the ability to invoke a post-deploy webhook with the IP, port and app name, all with a single config:set).
In order to leverage cloud-provider facilities like _attachable volumes_, (_a.k.a. block storage_)
the following is an easy tutorial to achieve Dokku runs on them.
> Warning: If the block storage is not available and attached on boot it is possible that containers will not correctly start. Please keep this in mind when considering moving Dokku and/or Docker to network attached storage.
## Tutorial
The following is intended to be executed on the dokku host machine as `root`.
Say, _for instance_, that our volume is mapped into the systems as `/dev/vdb1`.
Stop docker daemon
```shell
systemctl stop docker
```
Prepare the filesystem:
```shell
mkfs -t ext4 /dev/vdb1
mkdir /mnt/volume
mount /dev/vdb1 /mnt/volume
```
Move the old data directories:
```shell
mv /home/dokku /home/dokku.OLD
mv /var/lib/docker /var/lib/docker.OLD
mv /var/lib/dokku /var/lib/dokku.OLD
```
Move the data on the volume
```shell
mkdir /mnt/volume/home/
mkdir -p /mnt/volume/var/lib/
mv /home/dokku.OLD /mnt/volume/home/dokku
mv /var/lib/dokku.OLD /mnt/volume/var/lib/dokku
mv /var/lib/docker.OLD /mnt/volume/var/lib/docker
```
Prepare the mountpoints
```shell
mkdir /home/dokku
mkdir /var/lib/dokku
mkdir /var/lib/docker
chown dokku:dokku /home/dokku # respect the original ownership
chmod 711 /var/lib/docker # respect the original permissions
```
Mount bind
```shell
mount -o bind /mnt/volume/home/dokku /home/dokku
mount -o bind /mnt/volume/var/lib/dokku /var/lib/dokku
mount -o bind /mnt/volume/var/lib/docker /var/lib/docker
```
Start docker daemon
```shell
systemctl start docker
```
At this point all should be working fine, please check it out.
Then, let the changes be reboot-persistent
```shell
echo'/dev/vdb1 /mnt/volume ext4 defaults 0 2'| sudo tee -a /etc/fstab
echo'/mnt/volume/home/dokku /home/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/dokku /var/lib/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/docker /var/lib/docker none defaults,bind 0 0'| sudo tee -a /etc/fstab
domains:add <app> <domain> [<domain> ...] # Add domains to app
domains:add-global <domain> [<domain> ...] # Add global domain names
domains [<app>] # List domains
domains:clear <app> # Clear all domains for app
domains:clear-global # Clear global domain names
domains:disable <app> # Disable VHOST support
domains:enable <app> # Enable VHOST support
domains:remove <app> <domain> [<domain> ...] # Remove domains from app
domains:remove-global <domain> [<domain> ...] # Remove global domain names
domains:report [<app>|--global] [<flag>] # Displays a domains report for one or more apps
domains:set <app> <domain> [<domain> ...] # Set domains for app
domains:set-global <domain> [<domain> ...] # Set global domain names
```
> Adding a domain before deploying an application will result in port mappings being set. This may cause issues for applications that use non-standard ports, as those will not be automatically detected. Please refer to the [proxy documentation](/dokku/advanced-usage/proxy-management/) for information as to how to reconfigure the mappings.
> Adding a domain before deploying an application will result in port mappings being set. This may cause issues for applications that use non-standard ports, as those will not be automatically detected. Please refer to the [proxy documentation](/docs/networking/proxy-management.md) for information as to how to reconfigure the mappings.
## Customizing hostnames
@@ -23,79 +26,93 @@ Applications typically have the following structure for their hostname:
scheme://subdomain.domain.tld
```
The `subdomain` is inferred from the pushed application name, while the `domain.tld` is set during initial configuration and stored in the `$DOKKU_ROOT/VHOST` file. It can then be modified with `dokku domains:add-global` and `dokku domains:remove-global`. This value is used as a default TLD for all applications on a host.
The `subdomain` is inferred from the pushed application name, while the `domain.tld` is set during initial dokku configuration. It can then be modified with `dokku domains:add-global` and `dokku domains:remove-global`. This value is used as a default TLD for all applications on a host.
If a FQDN such as `other.tld` is used as the application name, the default `$DOKKU_ROOT/VHOST` will be ignored and the resulting vhost URL for that application will be `other.tld`. The exception to this rule being that if the FQDN has the same ending as the default vhost (such as `subdomain.domain.tld`), then the entire FQDN will be treated as a subdomain. The application will therefore be deployed at `subdomain.domain.tld.domain.tld`.
If an FQDN such as `dokku.org` is used as the application name, the global virtualhost will be ignored and the resulting vhost URL for that application will be `dokku.org`.
You can optionally override this in a plugin by implementing the `nginx-hostname` plugin trigger. For example, you can reverse the subdomain with the following sample `nginx-hostname` plugin trigger:
You can optionally override this in a plugin by implementing the `nginx-hostname` plugin trigger. If the `nginx-hostname` plugin has no output, the normal hostname algorithm will be executed. See the [plugin trigger documentation](/docs/development/plugin-triggers.md#nginx-hostname) for more information.
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";SUBDOMAIN="$2";VHOST="$3"
NEW_SUBDOMAIN=`echo$SUBDOMAIN| rev`
echo"$NEW_SUBDOMAIN.$VHOST"
```
If the `nginx-hostname` has no output, the normal hostname algorithm will be executed.
## Disabling VHOSTS
If desired, it is possible to disable vhosts with the domains plugin.
```shell
dokku domains:disable myapp
dokku domains:disable node-js-app
```
On subsequent deploys, the nginx virtualhost will be discarded. This is useful when deploying internal-facing services that should not be publicly routeable. As of 0.4.0, nginx will still be configured to proxy your app on some random high port. This allows internal services to maintain the same port between deployments. You may change this port by setting `DOKKU_NGINX_PORT` and/or `DOKKU_NGINX_SSL_PORT` (for services configured to use SSL.)
On subsequent deploys, the nginx virtualhost will be discarded. This is useful when deploying internal-facing services that should not be publicly routeable. As of 0.4.0, nginx will still be configured to proxy your app on some random high port. This allows internal services to maintain the same port between deployments. You may change this port by setting `DOKKU_PROXY_PORT` and/or `DOKKU_PROXY_SSL_PORT` (for services configured to use SSL.)
The domains plugin allows you to specify custom domains for applications. This plugin is aware of any ssl certificates that are imported via `certs:add`. Be aware that disabling domains (with `domains:disable`) will override any custom domains.
```shell
# where `myapp` is the name of your app
# where `node-js-app` is the name of your app
# add a domain to an app
dokku domains:add myapp example.com
dokku domains:add node-js-app dokku.me
# list custom domains for app
dokku domains myapp
dokku domains:report node-js-app
# clear all custom domains for app
dokku domains:clear myapp
dokku domains:clear node-js-app
# remove a custom domain from app
dokku domains:remove myapp example.com
dokku domains:remove node-js-app dokku.me
# set all custom domains for app
dokku domains:set node-js-app dokku.me dokku.org
```
## Displaying domains reports for an app
> New as of 0.8.1
You can get a report about the app's domains status using the `domains:report` command:
```shell
dokku domains:report
```
```
=====> node-js-app domains information
Domains app enabled: true
Domains app vhosts: node-js-app.dokku.org
Domains global enabled: true
Domains global vhosts: dokku.org
=====> python-app domains information
Domains app enabled: true
Domains app vhosts: python-app.dokku.org
Domains global enabled: true
Domains global vhosts: dokku.org
=====> ruby-app domains information
Domains app enabled: true
Domains app vhosts: ruby-app.dokku.org
Domains global enabled: true
Domains global vhosts: dokku.org
```
You can run the command for a specific app also.
```shell
dokku domains:report node-js-app
```
```
=====> node-js-app domains information
Domains app enabled: true
Domains app vhosts: node-js-app.dokku.org
Domains global enabled: true
Domains global vhosts: dokku.org
```
You can pass flags which will output only the value of the specific information you want. For example:
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration. This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
```nginx
server{
listen80default_server;
listen[::]:80default_server;
server_name_;
return410;
log_not_foundoff;
}
```
You may also wish to use a separate vhost in your `/etc/nginx/sites-enabled` directory. To do so, create the vhost in that directory as `/etc/nginx/sites-enabled/00-default.conf`. You will also need to change two lines in the main `nginx.conf`:
```nginx
# Swap both conf.d include line and the sites-enabled include line. From:
include/etc/nginx/conf.d/*.conf;
include/etc/nginx/sites-enabled/*;
# to the following
include/etc/nginx/sites-enabled/*;
include/etc/nginx/conf.d/*.conf;
```
Alternatively, you may push an app to your Dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
This is specific to your proxy plugin of choice. See the [nginx documentation](/docs/configuration/nginx.md#default-site) for more information on how to configure this for the default nginx proxy implementation.
config:export (<app>|--global) [--envfile] Export a global or app environment
config:get (<app>|--global) KEY Display a global or app-specific config value
config:keys (<app>|--global) [--merged] Show keys set in environment
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
config:unset [--no-restart] (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
```
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available *only* during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860).
The variables are available both at run time and during the application build/compilation step for buildpack-based deploys. For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available *only* during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860).
Environment variables are available both at run time and during the application build/compilation step for buildpack-based deploys.
For buildpack deploys, Dokku will create a `/app/.env` file that can be used for legacy buildpacks. Note that this is *not* updated when `config:set` or `config:unset` is called, and is only written during a `deploy` or `ps:rebuild`. Developers are encouraged to instead read from the application environment directly, as the proper values will be available then.
@@ -23,10 +28,15 @@ You can set multiple environment variables at once:
When setting variables with whitespaces, you need to escape them:
> Note: Whitespace and special characters get tricky. If you are using dokku locally you don't need to do any special escaping. If you are using dokku over ssh you will need to backslash-escape spaces:
Dokku can also read base64 encoded values. That's the easiest way to set a value with newlines or spaces. To set a value with newlines you need to base64 encode it first and pass the `--encoded` flag:
When setting or unsetting environment variables, you may wish to avoid an application restart. This is useful when developing plugins or when setting multiple environment variables in a scripted manner. To do so, use the `--no-restart` flag:
@@ -35,25 +45,84 @@ When setting or unsetting environment variables, you may wish to avoid an applic
If you wish to have the variables output in an `eval`-compatible form, you can use the `--export`flag:
If you wish to have the variables output in an `eval`-compatible form, you can use the `config:export`command
```shell
dokku config node-js-app --export
dokku config:export node-js-app
# outputs variables in the form:
#
# export ENV='prod'
# export COMPILE_ASSETS='1'
# source in all the node-js-app app environment variables
eval$(dokku config node-js-app --export)
eval$(dokku config:export node-js-app)
```
You can also output the variables in a single-line for usage in command-line utilities with the `--shell` flag:
You can control the format of the exported variables with the `--format` flag.
`--format=shell` will output the variables in a single-line for usage in command-line utilities:
```shell
dokku config node-js-app --shell
dokku config:export --format shell node-js-app
# outputs variables in the form:
#
# ENV='prod' COMPILE_ASSETS='1'
```
## Special Config Variables
The following config variables have special meanings and can be set in a variety of ways. Unless specified via global app config, the values may not be passed into applications. Usage of these values within applications should be considered unsafe, as they are an internal configuration values that may be moved to the internal properties system in the future.
> Warning: This list is not exhaustive, and may vary from version to version.
| `DOKKU_ROOT` | `~dokku` | `/etc/environment` | The root directory where dokku will store application repositories, as well as certain configuration files. |
| `DOKKU_IMAGE` | `gliderlabs/herokuish` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The default image to use when building herokuish containers. Deprecated in favor of using `buildpacks:set-property` |
| `DOKKU_LIB_ROOT` | `/var/lib/dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory where plugins, certain data, and general configuration is stored. |
| `PLUGIN_PATH` | `$DOKKU_LIB_ROOT/plugins"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The top-level directory where plugins are stored. |
| `PLUGIN_AVAILABLE_PATH` | `$PLUGIN_PATH/available"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory that holds all available plugins, including core. |
| `PLUGIN_ENABLED_PATH` | `$PLUGIN_PATH/enabled"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory that holds all enabled plugins, including core. |
| `PLUGIN_CORE_PATH` | `$DOKKU_LIB_ROOT/core-plugins"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory that stores all core plugins. |
| `PLUGIN_CORE_AVAILABLE_PATH` | `$PLUGIN_CORE_PATH/available"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory that stores all available core plugins. |
| `PLUGIN_CORE_ENABLED_PATH` | `$PLUGIN_CORE_PATH/enabled"` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | The directory that stores all enabled core plugins. |
| `DOKKU_LOGS_DIR` | `/var/log/dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where dokku logs should be written to. |
| `DOKKU_LOGS_HOST_DIR` | `$DOKKU_LOGS_DIR` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | A path on the host that will be mounted into the vector logging container. |
| `DOKKU_EVENTS_LOGFILE` | `$DOKKU_LOGS_DIR/events.log` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where the events log file is written to. |
| `DOKKU_APP_NAME` | none | `--app APP` flag | Name of application to work on. Respected by core plugins. |
| `DOKKU_APPS_FORCE_DELETE` | none | `--force` flag | Whether to force delete an application. Also used by other plugins for destructive actions. |
| `DOKKU_CHECKS_URL` | `https://dokku.com/docs/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Whether to detach a container started via `dokku run`. |
| `DOKKU_QUIET_OUTPUT` | none | `--quiet` flag | Silences certain header output for `dokku` commands. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> `--rm-container` flag <br /> `--rm` flag | Whether to keep `dokku run` containers around or not. |
| `DOKKU_TRACE` | none | `dokku trace:on` <br /> `dokku trace:off` <br /> `--trace` flag | Turn on very verbose debugging. |
| `DOKKU_APP_SHELL` | `/bin/bash` | `dokku config:set` | Allows users to change the default shell used by Dokku for `dokku enter` and execution of deployment tasks. |
| `DOKKU_APP_TYPE` | `herokuish` | Auto-detected by using buildpacks or dockerfile | |
| `DOKKU_CHECKS_WAIT` | `5` | `dokku config:set` | Wait this many seconds for the container to start before running checks.
| `DOKKU_CHECKS_TIMEOUT` | `30` | `dokku config:set` | Wait this many seconds for each response before marking it as a failure.
| `DOKKU_CHECKS_ATTEMPTS` | `5` | `dokku config:set` | Number of retries for to run for a specific check before marking it as a failure
| `DOKKU_DEFAULT_CHECKS_WAIT` | `10` | `dokku config:set` | 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_DISABLE_PROXY` | none | `dokku proxy:disable` <br /> `dokku proxy:enable` | Disables the proxy in front of your application, resulting in publicly routing the docker container. |
| `DOKKU_DISABLE_ANSI_PREFIX_REMOVAL` | none | `dokku config:set` <br /> `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Disables removal of the ANSI prefix during deploys. Can be used in cases where the client deployer does not understand ansi escape codes. |
| `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. |
| `DOKKU_START_CMD` | none | `dokku config:set` | Command to run instead of `/start $PROC_TYPE` |
| `DOKKU_SYSTEM_GROUP` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System group to chown files as. |
| `DOKKU_SYSTEM_USER` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System user to chown files as. |
| `DOKKU_WAIT_TO_RETIRE` | `60` | `dokku config:set` | After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections. |
nginx:validate-config [<app>] [--clean] # Validates and optionally cleans up invalid nginx configurations
```
## Customizing the nginx configuration
## Usage
### Request Proxying
By default, the `web` process is the only process proxied by the nginx proxy implementation. Proxying to other process types may be handled by a custom `nginx.conf.sigil` file, as generally described [below](/docs/configuration/nginx.md#customizing-the-nginx-configuration)
Nginx will proxy the requests in a [round-robin balancing fashion](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream) to the different deployed (scaled) containers running the `web` proctype. This way, the host's resources can be fully leveraged for single-threaded applications (e.g. `dokku ps:scale node-js-app web=4` on a 4-core machine)
### Binding to specific addresses
> New as of 0.19.2
By default, nginx will listen to all interfaces (`[::]` for IPv6, `0.0.0.0` for IPv4) when proxying requests to applications. This may be changed using the `bind-address-ipv4` and `bind-address-ipv6` properties. This is useful in cases where the proxying should be internal to a network or if there are multiple network interfaces that should respond with different content.
This may be reverted by setting an empty bind address.
```shell
dokku nginx:set node-js-app bind-address-ipv4
dokku nginx:set node-js-app bind-address-ipv6
```
> Warning: Validation is not performed on either value.
Users with apps that contain a custom `nginx.conf.sigil` file will need to modify the files to respect the new `NGINX_BIND_ADDRESS_IPV4` and `NGINX_BIND_ADDRESS_IPV6` variables.
### HSTS Header
> New as of 0.20.0
If SSL certificates are present, HSTS will be automatically enabled. It can be toggled via `nginx:set`:
```shell
dokku nginx:set node-js-app hsts true
dokku nginx:set node-js-app hsts false
```
The following options are also available via the `nginx:set` command:
-`hsts` (type: boolean, default: `true`): Enables or disables HSTS for your application.
-`hsts-include-subdomains` (type: boolean, default: `true`): Tells the browser that the HSTS policy also applies to all subdomains of the current domain.
-`hsts-max-age` (type: integer, default: `15724800`): Time in seconds to cache HSTS configuration.
-`hsts-preload` (type: boolean, default: `false`): Tells most major web browsers to include the domain in their HSTS preload lists.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails until the max-age is reached.
#### Globally disabling the HSTS Header
HSTS Header can be disabled for all apps by setting the `hsts` property to false after passing the `--global` flag to `nginx:set`. Changing this value globally or on a per-app basis will require rebuilding the nginx config via the `proxy:build-config` command.
```shell
dokku nginx:set --global hsts false
```
Once the HSTS setting is disabled globally, it can be re-enabled on a per-app basis by setting the `hsts` property as normal.
```shell
dokku nginx:set node-js-app hsts true
```
### Checking access logs
You may check nginx access logs via the `nginx:access-logs` command. This assumes that app access logs are being stored in `/var/log/nginx/$APP-access.log`, as is the default in the generated `nginx.conf`.
```shell
dokku nginx:access-logs node-js-app
```
You may also follow the logs by specifying the `-t` flag.
```shell
dokku nginx:access-logs node-js-app -t
```
### Checking error logs
You may check nginx error logs via the `nginx:error-logs` command. This assumes that app error logs are being stored in `/var/log/nginx/$APP-error.log`, as is the default in the generated `nginx.conf`.
```shell
dokku nginx:error-logs node-js-app
```
You may also follow the logs by specifying the `-t` flag.
```shell
dokku nginx:error-logs node-js-app -t
```
### Changing log path
> New as of 0.20.1
The path to where log files are stored can be changed by calling the `nginx:set` command with the following options:
The defaults should not be changed without verifying that the paths will be writeable by nginx. However, this setting is useful for enabling or disabling logging by setting the values to `off`.
```shell
dokku nginx:set node-js-app access-log-path off
dokku nginx:set node-js-app error-log-path off
```
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app access-log-path
dokku nginx:set node-js-app error-log-path
```
In all cases, the nginx config must be regenerated after setting the above values.
### Changing log format
> New as of 0.22.0
The format of the access log can be changed by calling the `nginx:set` command as follows:
Prior to changing the log-format, log formats should be specified at a file such as `/etc/nginx/conf.d/00-log-formats.conf`. This will ensure they are available within your app's nginx context. For instance, the following may be added to the above file. It only needs to be specified once to be used for all apps.
Finally, a proxy rebuild will change the format as desired.
```shell
dokku proxy:build-config node-js-app
```
### Specifying a read timeout
> New as of 0.21.0
When proxying requests to your applications, it may be useful to specify a proxy read timeout. This can be done via the `nginx:set` command as follows:
The default value is `60s`, and all numeric values _must_ have a trailing time value specified (`s` for seconds, `m` for minutes).
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app proxy-read-timeout
```
In all cases, the nginx config must be regenerated after setting the above value.
### Specifying a custom client_max_body_size
> New as of 0.23.0
Users can override the default `client_max_body_size` value - which limits file uploads - via `nginx:set`. Changing this value will only apply to every `server` stanza of the default `nginx.conf.sigil`; users of custom `nginx.conf.sigil` files must update their templates to support the new value.
The default value is empty string, which will result in nginx falling back to any configured, higher-level defaults (or `1m` if unconfigued; all numerical values _must_ have a size unit specified (`k` for kilobytes, `m` for megabytes).
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app client-max-body-size
```
In all cases, the nginx config must be regenerated after setting the above value.
Changing this value when using the PHP buildpack (or any other buildpack that uses an intermediary server) will require changing the value in the server config shipped with that buildpack. Consult your buildpack documentation for further details.
### Showing the nginx config
For debugging purposes, it may be useful to show the nginx config. This can be achieved via the `nginx:show-config` command.
```shell
dokku nginx:show-config node-js-app
```
### Validating nginx configs
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate-config` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
```shell
dokku nginx:validate-config
```
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate-config` command is the exit code of `nginx -t` against the server's real nginx config.
The `nginx:validate-config` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
> Warning: Invalid app nginx config's will be removed _even if_ the config is valid in the global server context.
```shell
dokku nginx:validate-config --clean
```
The `--clean` flag may also be specified for a given app:
```shell
dokku nginx:validate-config node-js-app --clean
```
### Customizing the nginx configuration
> New as of 0.5.0
Dokku uses a templating library by the name of [sigil](https://github.com/gliderlabs/sigil) to generate nginx configuration for each app. You may also provide a custom template for your application as follows:
- Copy the following example template to a file named `nginx.conf.sigil` and either:
- check it into the root of your app repo for buildpack applications
-`ADD` it to your dockerfile `WORKDIR`
-if your dockerfile has no `WORKDIR`, `ADD` it to the `/app` folder
- If using a buildpack application, you __must__ check it into the root of your app repo.
-If using a dockerfile or docker image for deploys, either:
-If `WORKDIR` is specified, add the file to the `WORKDIR` specified in the last Dockerfile stage (example: `WORKDIR /app` and `ADD nginx.conf.sigil /app`).
- If no `WORKDIR` is specified, add the file to the root (`/`) of the docker image (example: `ADD nginx.conf.sigil /`).
> When using a custom `nginx.conf.sigil` file, depending upon your application configuration, you *may* be exposing the file externally. As this file is extracted before the container is run, you can, safely delete it in a custom `entrypoint.sh` configured in a Dockerfile `ENTRYPOINT`.
### Example Custom Template
> The default template is available [here](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/nginx.conf.sigil), and can be used as a guide for your own, custom `nginx.conf.sigil` file. Please refer to the appropriate template file version for your Dokku version.
Use case: add an `X-Served-By` header to requests
While enabled by default, using a custom nginx config can be disabled via `nginx:set`. This may be useful in cases where you do not want to allow users to override any higher-level customization of app nginx config.
Unsetting this value is the same as enabling custom nginx config usage.
#### Available template variables
```
{{ .APP }} Application name
{{ .APP_SSL_PATH }} Path to SSL certificate and key
{{ .DOKKU_ROOT }} Global Dokku root directory (ex: app dir would be `{{ .DOKKU_ROOT }}/{{ .APP }}`)
{{ .DOKKU_APP_LISTENERS }} List of IP:PORT pairs of app containers
{{ .NGINX_PORT }} Non-SSL nginx listener port (same as `DOKKU_NGINX_PORT` config var)
{{ .NGINX_SSL_PORT }} SSL nginx listener port (same as `DOKKU_NGINX_SSL_PORT` config var)
{{ .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)
@@ -81,157 +288,127 @@ upstream {{ .APP }} {
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an `.DOKKU_APP_${PROCESS_TYPE}_LISTENERS` variable - the `PROCESS_TYPE` will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
> Note: Application config variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
### Example HTTP to HTTPS Custom Template
Use case: a simple dockerfile app that includes `EXPOSE 80`
The example above uses additional configuration files directly on the Dokku host. Unlike the `nginx.conf.sigil` file, these additional files will not be copied over from your application repo, and thus need to be placed in the `/home/dokku/myapp/nginx.conf.d/` directory manually.
The example above uses additional configuration files directly on the Dokku host. Unlike the `nginx.conf.sigil` file, these additional files will not be copied over from your application repo, and thus need to be placed in the `/home/dokku/node-js-app/nginx.conf.d/` directory manually.
## Domains plugin
For PHP Buildpack users, you will also need to provide a `Procfile` and an accompanying `nginx.conf` file to customize the nginx config *within* the container. The following are example contents for your `Procfile`
See the [domain configuration documentation](/dokku/configuration/domains/).
Your `nginx.conf` file - not to be confused with Dokku's `nginx.conf.sigil` - would also need to be configured as shown in this example:
See the [customizing hostnames documentation](/dokku/configuration/domains/#customizing-hostnames).
client_header_timeout 50s;
location / {
index index.php;
try_files $uri $uri/ /index.php$is_args$args;
}
## Disabling VHOSTS
Please adjust the `Procfile` and `nginx.conf` file as appropriate.
See the [disabling vhosts documentation](/dokku/configuration/domains/#disabling-vhosts).
### Custom Error Pages
## Default site
By default, Dokku provides custom error pages for the following three categories of errors:
See the [default site documentation](/dokku/configuration/domains/#default-site).
- 4xx: For all non-404 errors with a 4xx response code.
- 404: For "404 Not Found" errors.
- 5xx: For all 5xx error responses
## Running behind a load balancer
These are provided as an alternative to the generic Nginx error page, are shared for _all_ applications, and their contents are located on disk at `/var/lib/dokku/data/nginx-vhosts/dokku-errors`. To customize them for a specific app, create a custom `nginx.conf.sigil` as described above and change the paths to point elsewhere.
See the [load balancer documentation](/dokku/configuration/ssl/#running-behind-a-load-balancer).
### Default site
## HSTS Header
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration.
See the [HSTS documentation](/dokku/configuration/ssl/#hsts-header).
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
## SSL Configuration
```nginx
server{
listen80default_server;
listen[::]:80default_server;
See the [ssl documentation](/dokku/configuration/ssl/).
server_name_;
access_logoff;
return410;
}
## Disabling Nginx
# To handle HTTPS requests, you can uncomment the following section.
#
# Please note that in order to let this work as expected, you need a valid
# SSL certificate for any domains being served. Browsers will show SSL
# errors in all other cases.
#
# Note that the key and certificate files in the below example need to
# be copied into /etc/nginx/ssl/ folder.
#
# server {
# listen 443 ssl;
# listen [::]:443 ssl;
# server_name _;
# ssl_certificate /etc/nginx/ssl/cert.crt;
# ssl_certificate_key /etc/nginx/ssl/cert.key;
# access_log off;
# return 410;
# }
```
See the [proxy documentation](/dokku/advanced-usage/proxy-management/).
Make sure to reload nginx after creating this file by running `service nginx reload`.
## Managing Proxy Port mappings
This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
See the [proxy documentation](/dokku/advanced-usage/proxy-management/#proxy-port-mapping).
The configuration file must be loaded before `/etc/nginx/conf.d/dokku.conf`, so it can not be arranged as a vhost in `/etc/nginx/sites-enabled` that is only processed afterwards.
Alternatively, you may push an app to your Dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
## Other
### Domains plugin
See the [domain configuration documentation](/docs/configuration/domains.md) for more information on how to configure domains for your app.
### Customizing hostnames
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames) for more information on how to configure domains for your app.
### Disabling VHOSTS
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.
### Disabling Nginx
See the [proxy documentation](/docs/networking/proxy-management.md) for more information on how to disable nginx as the proxy implementation for your app.
### Managing Proxy Port mappings
See the [proxy documentation](/docs/networking/proxy-management.md#proxy-port-mapping) for more information on how to manage ports proxied for your app.
### Regenerating nginx config
See the [proxy documentation](/docs/networking/proxy-management.md#regenerating-proxy-config) for more information on how to rebuild the nginx proxy configuration for your app.
@@ -7,8 +7,9 @@ Dokku supports SSL/TLS certificate inspection and CSR/Self-signed certificate ge
```
certs:add <app> CRT KEY # Add an ssl endpoint to an app. Can also import from a tarball on stdin.
certs:generate <app> DOMAIN # Generate a key and certificate signing request (and self-signed certificate)
certs:info <app> # Show certificate information for an ssl endpoint.
certs:remove <app> # Remove an SSL Endpoint from an app.
certs:report [<app>] [<flag>] # Displays an ssl report for one or more apps
certs:show <app> <crt|key> # Show the server.crt or server.key on stdout
certs:update <app> CRT KEY # Update an SSL Endpoint on an app. Can also import from a tarball on stdin
```
@@ -17,7 +18,7 @@ certs:update <app> CRT KEY # Update an SSL Endpoint on an app. Can
dokku nginx:import-ssl <app> < certs.tar
```
> Adding an ssl certificate before deploying an application will result in port mappings being updated. This may cause issues for applications that use non-standard ports, as those may not be automatically detected. Please refer to the [proxy documentation](/dokku/advanced-usage/proxy-management/) for information as to how to reconfigure the mappings.
> Adding an ssl certificate before deploying an application will result in port mappings being updated. This may cause issues for applications that use non-standard ports, as those may not be automatically detected. Please refer to the [proxy documentation](/docs/networking/proxy-management.md) for information as to how to reconfigure the mappings.
## Per-application certificate management
@@ -29,8 +30,7 @@ The `certs:add` command can be used to push a `tar` containing a certificate `.c
```shell
tar cvf cert-key.tar server.crt server.key
# replace APP with the name of your application
dokku certs:add <app> < cert-key.tar
dokku certs:add node-js-app < cert-key.tar
```
> Note: If your `.crt` file came alongside a `.ca-bundle`, you'll want to concatenate those into a single `.crt` file before adding it to the `.tar`.
When an SSL certificate is associated to an application, the certificate will be associated with *all* domains currently associated with said application. Your certificate _should_ be associated with all of those domains, otherwise accessing the application will result in SSL errors. If you wish to remove one of the domains from the application, refer to the [domain configuration documentation](/dokku/configuration/domains/).
When an SSL certificate is associated to an application, the certificate will be associated with *all* domains currently associated with said application. Your certificate _should_ be associated with all of those domains, otherwise accessing the application will result in SSL errors. If you wish to remove one of the domains from the application, refer to the [domain configuration documentation](/docs/configuration/domains.md).
Note that with the default nginx template, requests will be redirected to the `https` version of the domain. If this is not the desired state of request resolution, you may customize the nginx template in use. For more details, see the [nginx documentation](/dokku/configuration/nginx/).
Note that with the default nginx template, requests will be redirected to the `https` version of the domain. If this is not the desired state of request resolution, you may customize the nginx template in use. For more details, see the [nginx documentation](/docs/configuration/nginx.md).
### Certificate generation
@@ -51,82 +51,118 @@ Note that with the default nginx template, requests will be redirected to the `h
The `certs:generate` command will walk you through the correct `openssl` commands to create a key, csr and a self-signed cert for a given app/domain. We automatically put the self-signed cert in place as well as add the specified domain to the application configuration.
If you decide to obtain a CA signed certficate, you can import that certificate using the aformentioned `dokku certs:add` command.
### Certificate information
The `certs:info` command will simply inspect the install SSL cert and print out details. NOTE: The server-wide certificate will be inspect if installed and no app-specific certificate exists.
```shell
dokku certs:info node-js-app
```
```
-----> Fetching SSL Endpoint info for node-js-app...
If you decide to obtain a CA signed certificate, you can import that certificate using the aforementioned `dokku certs:add` command.
### Certificate removal
The `certs:remove` command only works on app-specific certificates. It will `rm` the app-specific tls directory, rebuild the nginx configuration, and reload nginx.
### Showing the certificate
The `certs:show` command can be used to show your configured certs for an app. The show command can be used for example to export Let's Encrypt certificates
after they've been generated. You can export it as follows:
```shell
dokku certs:show node-js-app crt > server.crt
dokku certs:show node-js-app key > server.key
```
### Displaying certificate reports for an app
> New as of 0.8.1
You can get a report about the apps ssl status using the `certs:report` command:
```shell
dokku certs:report
```
```
=====> node-js-app
Ssl dir: /home/dokku/node-js-app/tls
Ssl enabled: true
Ssl hostnames: *.node-js-app.org node-js-app.org
Ssl expires at: Oct 5 23:59:59 2019 GMT
Ssl issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Ssl starts at: Oct 5 00:00:00 2016 GMT
Ssl subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.node-js-app.org
Ssl verified: self signed.
=====> python-app
Ssl dir: /home/dokku/python-app/tls
Ssl enabled: false
Ssl hostnames:
Ssl expires at:
Ssl issuer:
Ssl starts at:
Ssl subject:
Ssl verified:
```
You can run the command for a specific app also.
```shell
dokku certs:report node-js-app
```
```
=====> node-js-app ssl information
Ssl dir: /home/dokku/node-js-app/tls
Ssl enabled: true
Ssl hostnames: *.dokku.org dokku.org
Ssl expires at: Oct 5 23:59:59 2019 GMT
Ssl issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Ssl starts at: Oct 5 00:00:00 2016 GMT
Ssl subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.dokku.org
Ssl verified: self signed.
```
You can pass flags which will output only the value of the specific information you want. For example:
```shell
dokku certs:report node-js-app --ssl-enabled
```
## HSTS Header
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does not, by default, enable this header. It is thus left up to you, the user, to enable it for your site.
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does enables this header by default for HTTPS requests.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails.
See the [NGINX HSTS documentation](/docs/configuration/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
## HTTP/2 support
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-For` and `X-Forwarded-Port`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-Port` and `X-Forwarded-For`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
If your server runs behind an HTTP/S load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by using the following [nginx custom template](/dokku/configuration/nginx/#customizing-the-nginx-configuration)
If your server runs behind an HTTP(S) load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application 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.
If it's possible to make HTTP(S) requests directly to Nginx, bypassing the load balancer, or if the load balancer is not configured to set these headers, then it becomes possible for a client to set these headers to arbitrary values.
This could result in security issue, for example, if your application looks at the value of the `X-Forwarded-Proto` to determine if the request was made over HTTPS.
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 proxy:ports-add <APP> https:443:99999`.
> Note: This walkthrough uses the hostname `dokku.me` in commands. When deploying to your own server, you should substitute the domain `dokku.me` for the domain name or IP address associated with your server. Users of the Vagrant VM included with Dokku can use `dokku.me` which points to the IP of the VM.
## Deploy tutorial
Once Dokku has been configured with at least one user, applications can be deployed via a`git push` command. To quickly see Dokku deployment in action, you can use the Heroku Ruby on Rails example app.
Once you have configured Dokku with at least one user, you can deploy applications using`git push`. To quickly see Dokku deployment in action, try using [the Heroku Ruby on Rails "Getting Started" app](https://github.com/heroku/ruby-getting-started).
Create the application on the Dokku host. You will need to ssh onto the host to run this command.
SSH into the Dokku host and create the application as follows:
```shell
# on your Dokku host
dokku apps:create ruby-rails-sample
# on the Dokku host
dokku apps:create ruby-getting-started
```
### Create the backing services
When you create a new app, Dokku by default *does not* provide any datastores such as MySQL or PostgreSQL. You will need to install plugins to handle that, but fortunately [Dokku has official plugins](/dokku/community/plugins/#official-plugins-beta) for common datastores. Our sample app requires a PostgreSQL service:
Dokku by default **does not** provide datastores (e.g. MySQL, PostgreSQL) on a newly created app. You can add datastore support by installing plugins, and the Dokku project [provides official plugins](/docs/community/plugins.md#official-plugins-beta) for common datastores.
The Getting Started app requires a PostgreSQL service, so install the plugin and create the related service as follows:
```shell
# on your Dokku host
# on the Dokku host
# install the postgres plugin
# plugin installation requires root, hence the user change
> You can link a single service to multiple applications or use one service per application.
Dokku supports linking a single service to multiple applications as well as linking only one service per application.
### Deploy the app
Now you can deploy the `ruby-rails-sample` app to your Dokku server. All you have to do is add a remote to name the app. Applications are created on-the-fly on the Dokku server.
> Warning: Your app should respect the `PORT` environment variable, otherwise it may not respond to web requests. You can find more information in the [port management documentation](/docs/networking/port-management.md).**
Now you can deploy the `ruby-getting-started` app to your Dokku server. All you have to do is add a remote to name the app. Applications are created on-the-fly on the Dokku server.
> Note: Some tools may not support the short-upstream syntax referenced above, and you may need to prefix
> the upstream with the scheme `ssh://` like so: `ssh://dokku@dokku.me:ruby-getting-started`
> Please see the [Git](https://git-scm.com/docs/git-clone#_git_urls_a_id_urls_a) documentation for more details.
> 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:
When the deploy finishes, the application's URL will be shown as seen above.
Once the deploy is complete, the application's web URL will be generated as above.
Dokku supports deploying applications via [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) with [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks) or using a project's [dockerfile](https://docs.docker.com/reference/builder/).
Dokku supports deploying applications in a few ways:
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) to learn about the different ways to specify a buildpack.
- This is the default method used by Dokku.
- [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/builders/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/images.md) to learn about how to deploy a Docker Image.
### Deploying non-master branch
### Setting up SSL
Dokku only supports deploying from its master branch, so if you'd like to deploy a different local branch use: ```git push dokku <local branch>:master```
> While SSL certificates can be imported, automated SSL via Letsencrypt requires that all domains on an app correctly point at your server's public ip address. Please keep this in mind when using Letsencrypt.
You can also support pushing multiple branches using the [receive-branch](/dokku/development/plugin-triggers/#receive-branch) plugin trigger in a custom plugin.
For many users, responding to requests via `https` will be desirable. Dokku has a complete [ssl plugin](/docs/configuration/ssl.md) built in that can be used to import SSL certificates (below is a short example, please refer to the [ssl documentation](/docs/configuration/ssl.md) for more information):
Dokku uses git locally (i.e. not a docker image) to build its own copy of your app repo, including submodules. This is done as the `dokku` user. Therefore, in order to deploy private git submodules, you'll need to drop your deploy key in `/home/dokku/.ssh/` and potentially add github.com (or your VCS host key) into `/home/dokku/.ssh/known_hosts`. The following test should help confirm you've done it correctly.
If you need to redeploy or restart your app:
```shell
# on your Dokku host
# on the Dokku host
dokku ps:rebuild ruby-getting-started
```
See the [process scaling documentation](/docs/processes/process-management.md) for more information on how to manage your app processes.
### Deploying with private Git submodules
Dokku uses Git locally (i.e. not a Docker image) to build its own copy of your app repo, including submodules, as the `dokku` user. This means that in order to deploy private Git submodules, you need to put your deploy key in `/home/dokku/.ssh/` and potentially add `github.com` (or your VCS host key) into `/home/dokku/.ssh/known_hosts`. You can use the following test to confirm your setup is correct:
Dokku is, at its core, a docker container manager. Thus, it does not necessarily play well with other out-of-band processes interacting with the docker daemon. One thing to note as in [issue #1220](https://github.com/dokku/dokku/issues/1220), dokku executes a cleanup function prior to every deployment.
Dokku is, at its core, a Docker container manager. Thus, it does not necessarily play well with other out-of-band processes interacting with the Docker daemon.
As of 0.5.x, this function removes all containers with the label `dokku` where the status is either `dead` or `exited`, as well as all `dangling` images. Previous versions would remove `dead` or `exited` containers, regardless of their label.
Prior to every deployment, Dokku will execute a cleanup function. As of 0.5.x, the cleanup removes all containers with the `dokku` label where the status is either `dead` or `exited` (previous versions would remove _all_ `dead` or `exited` containers). The cleanup function also removes all images with `dangling` status.
## Adding deploy users
See the [user management documentation](/dokku/deployment/user-management).
See the [user management documentation](/docs/deployment/user-management.md) for more information on how to manage users with access to your Dokku server.
## Default vhost
See the [nginx documentation](/dokku/configuration/nginx/#default-site).
See the [domains documentation](/docs/configuration/domains.md#default-site) for more information on how to manage the default site.
## Deploying non-master branch
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch) for more information on deploying a non-master branch to your application.
## Dockerfile deployment
See the [dockerfile documentation](/dokku/deployment/methods/dockerfiles/).
## Specifying a custom buildpack
See the [buildpack documentation](/dokku/deployment/methods/buildpacks/).
See the [Dockerfile documentation](/docs/deployment/builders/dockerfiles.md) for information Dokku's Dockerfile support.
## Image tagging
See the [image tagging documentation](/dokku/deployment/methods/images/).
See the [image tagging documentation](/docs/deployment/methods/images.md) for more information on how Docker images can be tagged and deployed for a given application.
## Specifying a custom buildpack
See the [herokuish buildpack documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how to specify a set of custom buildpacks for your application.
## Removing a deployed app
See the [application management documentation](/dokku/deployment/application-management/#removing-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app) for more information on how to remove an application from your Dokku server.
### Renaming a deployed app
## Renaming a deployed app
See the [application management documentation](/dokku/deployment/application-management/#renaming-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app) for more information on how an application can be renamed and the impact of doing so upon the application and associated resources.
## Zero downtime deploy
See the [zero-downtime deploy documentation](/dokku/deployment/zero-downtime-deploys/).
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md) for more information on how Dokku enables zero-downtime deploys.
apps:locked <app> # Checks if an app is locked for deployment
apps:rename <old-app> <new-app> # Rename an app
apps:report [<app>] [<flag>] # Display report about an app
apps:unlock <app> # Unlocks an app for deployment
```
## Usage
### Listing Applications
### Listing applications
You can easily list all available applications using the `apps` command:
> New as of 0.8.1. Use the `apps` command for older versions.
You can easily list all available applications using the `apps:list` command:
```shell
dokku apps
dokku apps:list
```
```
@@ -25,10 +33,10 @@ node-js-app
python-app
```
Note that you can easily hide extra output from Dokku commands by using the `--quiet` flag, which makes it easier to parse on the command-line.
Note that you can easily hide extra output from Dokku commands by using the `--quiet` flag, which makes it easier to parse on the commandline.
```shell
dokku --quiet apps
dokku --quiet apps:list
```
```
@@ -36,6 +44,20 @@ node-js-app
python-app
```
### Checking if an application exists
For CI/CD pipelines, it may be useful to see if an application exists before creating a "review" application for a specific branch. You can do so via the `apps:exists` command:
```shell
dokku apps:exists node-js-app
```
```
App does not exist
```
The `apps:exists` command will return non-zero if the application does not exist, and zero if it does.
### Manually creating an application
A common pattern for deploying applications to Dokku is to configure an application before deploying it. You can do so via the `apps:create` command:
@@ -50,9 +72,9 @@ Creating node-js-app... done
Once created, you can configure the application as normal, and deploy the application whenever ready. This is useful for cases where you may wish to do any of the following kinds of tasks:
The `--force` flag can also be specified on the command vs globally:
```shell
dokku apps:destroy --force node-js-app
```
```
Destroying node-js-app (including all add-ons)
```
Destroying an application will unlink all linked services and destroy any config related to the application. Note that linked services will retain their data for later use (or removal).
@@ -112,3 +143,136 @@ Renaming node-js-app to io-js-app... done
```
This will copy all of your app's contents into a new app directory with the name of your choice, delete your old app, then rebuild the new version of the app and deploy it. All of your config variables, including database urls, will be preserved.
By default, Dokku will deploy the renamed app, though you can skip the deploy by using the `--skip-deploy` flag:
You can clone an existing app using the `apps:clone` command. Note that the application *must* have been deployed at least once, or cloning will not complete successfully:
```shell
dokku apps:clone node-js-app io-js-app
```
```
Cloning node-js-app to io-js-app... done
```
This will copy all of your app's contents into a new app directory with the name of your choice and then rebuild the new version of the app and deploy it with the following caveats:
- All of your environment variables, including database urls, will be preserved.
- Custom domains are not applied to the new app.
- SSL certificates will not be copied to the new app.
- Port mappings with the scheme `https` and host-port `443` will be skipped.
> Warning: If you have exposed specific ports via `docker-options` plugin, or performed anything that cannot be done against multiple applications, `apps:clone` may result in errors.
By default, Dokku will deploy this new app, though you can skip the deploy by using the `--skip-deploy` flag:
Finally, if the application already exists, you may wish to ignore errors resulting from attempting to clone over it. To do so, you can use the `--ignore-existing` flag. A warning will be emitted, but the command will return `0`.
If you wish to disable deploying for a period of time, this can be done via deploy locks. Normally, deploy locks exist only for the duration of a deploy so as to avoid deploys from colliding, but a deploy lock can be created by running the `apps:lock` command.
```shell
dokku apps:lock node-js-app
```
```
-----> Deploy lock created
```
### Unlocking app deploys
> New as of 0.11.6
In some cases, it may be necessary to remove an existing deploy lock. This can be performed via the `apps:unlock` command.
> Warning: Removing the deploy lock *will not* stop in progress deploys. At this time, in progress deploys will need to be manually terminated by someone with server access.
```shell
dokku apps:unlock node-js-app
```
```
! A deploy may be in progress.
! Removing the app lock will not stop in progress deploys.
-----> Deploy lock removed.
```
### Checking lock status
> New as of 0.13.0
In some cases, you may wish to inspect the state of an app lock. To do so, you can issue an `apps:lock` command. This will exit non-zero if there is no app lock in place.
```shell
dokku apps:locked node-js-app
```
```
Deploy lock does not exist
```
### Displaying reports for an app
> New as of 0.8.1
You can get a report about the deployed apps using the `apps:report` command:
```shell
dokku apps:report
```
```
=====> node-js-app app information
App dir: /home/dokku/node-js-app
App deploy source: git
App locked: false
=====> python-sample app information
App dir: /home/dokku/python-sample
App deploy source:
App locked: false
=====> ruby-sample app information
App dir: /home/dokku/ruby-sample
App deploy source: git
App locked: false
```
You can run the command for a specific app also.
```shell
dokku apps:report node-js-app
```
```
=====> node-js-app app information
App dir: /home/dokku/node-js-app
App deploy source: git
App locked: false
```
You can pass flags which will output only the value of the specific information you want. For example:
builder:report [<app>] [<flag>] # Displays a builder report for one or more apps
builder:set <app> <key> (<value>) # Set or clear a builder property for an app
```
Builders are a way of customizing how an app is built from a source, allowing users flexibility in how artifacts are created for later scheduling.
## Usage
### Builder selection
Dokku supports the following built-in builders:
-`builder-dockerfile`: Builds apps using a `Dockerfile` via `docker build`. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how this builder functions.
-`builder-herokuish`: Builds apps with Heroku's v2a Buildpack specification via `gliderlabs/herokuish`. See the [herokuish builder documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how this builder functions.
-`builder-pack`: Builds apps with Cloud Native Buildpacks via the `pack-cli` tool. See the [cloud native buildpacks builder documentation](/docs/deployment/builders/cloud-native-buildpacks.md) for more information on how this builder functions.
Builders run a detection script against a source code repository, and the first detected builder will be used to build the app artifact. The exception to this is when a `Dockerfile` is detected and the app is also able to use either `herokuish` or `pack-cli` for building, in which case one of the latter will be chosen.
### Overriding the auto-selected builder
If desired, the builder can be specified via the `builder:set` command by speifying a value for `selected`. The selected builder will always be used.
```shell
dokku builder:set node-js-app selected dockerfile
```
The default value may be set by passing an empty value for the option:
```shell
dokku builder:set node-js-app selected
```
The `selected` property can also be set globally. The global default is an empty string, and auto-detection will be performed when no value is set per-app or globally.
```shell
dokku builder:set --global selected herokuish
```
The default value may be set by passing an empty value for the option.
```shell
dokku builder:set --global selected
```
### Displaying builder reports for an app
You can get a report about the app's builder status using the `builder:report` command:
```shell
dokku builder:report
```
```
=====> node-js-app builder information
Builder computed selected: herokuish
Builder global selected: herokuish
Builder selected: herokuish
=====> python-sample builder information
Builder computed selected: dockerfile
Builder global selected: herokuish
Builder selected: dockerfile
=====> ruby-sample builder information
Builder computed selected: herokuish
Builder global selected: herokuish
Builder selected:
```
You can run the command for a specific app also.
```shell
dokku builder:report node-js-app
```
```
=====> node-js-app builder information
Builder selected: herokuish
```
You can pass flags which will output only the value of the specific information you want. For example:
- description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
-`builder-detect`:
- arguments: `APP``SOURCECODE_WORK_DIR`
- description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
-`builder-release`:
- arguments: `BUILDER_TYPE``APP``IMAGE_AG`
- description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
Custom plugins names _must_ have the prefix `builder-` or builder overriding via `builder:set` may not function as expected.
Builders can use any tools available on the system to build the docker image, and may even be used to schedule building off-server. The only current requirement is that the image must exist on the server at the end of the `builder-build` command, though this requirement may be relaxed in a future release.
For a simple example of how to implement this trigger, see `builder-pack`, which utilizes a cli tool - `pack-cli` - to generate an OCI image that is compatible with Docker and can be scheduled by the official scheduling plugins.
buildpacks:set-property [--global|<app>] <key> <value> # Set or clear a buildpacks property for an app
```
Cloud Native Buildpacks are an evolution over the Buildpacks technology provided by the Herokuish builder. See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how to clear buildpack build cache for an application.
> Warning: This functionality uses the `pack` cli from the [Cloud Native Buildpacks](https://buildpacks.io) project to build apps. As the integration is experimental in Dokku, it is likely to change over time.
## Usage
### Detection
This builder will be auto-detected in either the following cases:
- The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
- A `.project.toml` file exists in the root of the app repository.
- This file is consumed by `pack-cli` and used to describe how the app is built.
The builder can also be specified via the `builder:set` command:
```shell
dokku builder:set node-js-app selected pack
```
> Dokku will only select the `dockerfile` builder if both the `herokuish` and `pack` builders are not detected and a Dockerfile exists. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how that builder functions.
### Requirements
The `pack` cli tool is not included by default with Dokku or as a dependency. It must also be installed as shown on [this page](https://buildpacks.io/docs/tools/pack/).
Builds will proceed with the `pack` cli for the app from then on.
### Caveats
As this functionality is highly experimental, there are a number of caveats. Please note that not all issuesare listed below.
- Specifying specific buildpacks is not currently possible.
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
- There is currently no way to specify extra arguments for `pack` cli invocations.
- A future release will add support for injecting extra arguments during the build process.
- The default process type is `web`.
- Build cache is stored in Docker volumes instead of on disk. As such, `repo:purge-cache` currently has no effect.
- A future version will add integration with the `repo` plugin.
- `pack` is not currently included with Dokku, nor is it added as a package dependency.
- A future version will include it as a package dependency.
### Customizing the Buildpack stack builder
> 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 specified stack builder can also be unset by omitting the name of the stack builder when calling `buildpacks:set-property`.
```shell
dokku buildpacks:set-property node-js-app stack
```
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_STACK` environment variable (`heroku/buildpacks` by default).
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.