# 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
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
> 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 need help figuring out how to use a specific buildpack, or are having issues using multiple buildpacks, please see our [irc or slack channels](http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/#the-irc-and-slack-channels). Issues pertaining to buildpacks may be closed and locked.
> If you'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
@@ -16,6 +20,8 @@
#### Expected Results
<-- Please replace APP_NAME with the name of your app -->
## Environment Information
### `dokku report APP_NAME` output
@@ -23,14 +29,14 @@
> This is required! Issues missing this information may be closed.
>
> For problems affecting all applications, the report output for a broken application is useful for our debugging.
> You may also run `dokku report` without any arguments to display the top-level reporting information.
> In these cases, you may run `dokku report` without any arguments to display the top-level reporting information.
### How (deb/make/rpm) and where (AWS, VirtualBox, physical, etc.) was Dokku installed?:
### Additional information
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
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](http://dokku.viewdocs.io/dokku/getting-started/install/debian/#unattended-installation) docs.
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](http://dokku.viewdocs.io/dokku/getting-started/upgrading/) for upgrading from an older version of Dokku.
[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 [http://dokku.viewdocs.io/dokku/](http://dokku.viewdocs.io/dokku/).
Full documentation - including advanced installation docs - are available online at [https://dokku.com/docs/](https://dokku.com/docs/).
## 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).
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](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.
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
}
@@ -35,13 +46,13 @@ install-requirements() {
debian)
if ! dpkg -l | grep -q software-properties-common;then
@@ -161,9 +200,11 @@ class GetHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
if'selfdestruct'insys.argv:
DeleteInstallerThread()
content=json.dumps({'status':'ok'})
self.send_response(200)
self.end_headers()
self.wfile.write(json.dumps({'status':'ok'}))
self.write_content(content)
defweb_admin_user_exists(self):
returnself.user_exists('web-admin(\d+)')
@@ -178,11 +219,11 @@ class GetHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
max_num=0
exists=False
forlineinproc.stdout:
m=pattern.search(line)
m=pattern.search(bytes_to_string(line))
ifm:
# User of the form `user` or `user#` exists
exists=True
max_num=max(max_num,m.group(1))
max_num=max(max_num,int(m.group(1)))
ifexists:
returnmax_num
else:
@@ -300,7 +341,7 @@ PAGE = """
<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="http://dokku.viewdocs.io/dokku/deployment/user-management/" target="_blank"><code>dokku ssh-keys</code></a> plugin.</small>
<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>
</div>
</div>
</div>
@@ -311,7 +352,7 @@ PAGE = """
<div class="form-group">
<label for="hostname">Hostname</label>
<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="http://dokku.viewdocs.io/dokku/configuration/domains/" target="_blank"><code>dokku domains:set-global</code></a> command.</small>
<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>
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](/docs/advanced-usage/persistent-storage.md) 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
@@ -24,6 +24,12 @@ Each "phase" has different expectations and limitations:
- 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
@@ -32,9 +38,11 @@ Each "phase" has different expectations and limitations:
- 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.
Please keep the above in mind when utilizing deployment tasks.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation) docs for more information on building your own custom plugin.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation.md) docs for more information on building your own custom plugin.
## `app.json` deployment tasks
@@ -42,6 +50,7 @@ Dokku provides limited support for the `app.json` manifest from Heroku (document
-`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`.
@@ -55,7 +64,8 @@ The following is an example `app.json` file. Please note that only the `scripts.
@@ -6,6 +6,7 @@ Pass [options](https://docs.docker.com/engine/reference/run/) to Docker during D
```
docker-options:add <app> <phase(s)> OPTION # Add Docker option to app for phase (comma-separated phase list)
docker-options:clear <app> [<phase(s)>...] # Clear a docker options from application
docker-options:remove <app> <phase(s)> OPTION # Remove Docker option from app for phase (comma-separated phase list)
docker-options:report [<app>] [<flag>] # Displays a docker options report for one or more apps
```
@@ -24,11 +25,15 @@ Dokku deploys your application in multiple "phases" and the `docker-options` plu
-`deploy`: the container that executes your running/deployed application
-`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`](/docs/deployment/one-off-processes.md):
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"
@@ -44,6 +49,37 @@ dokku docker-options:add node-js-app run "-v /var/log/node-js-app:/app/logs"
dokku docker-options:remove node-js-app run "-v /var/log/node-js-app:/app/logs"
```
### Clear all Docker options for an app
Docker options can be removed for a specific app using the `docker-options:clear` command.
```shell
dokku docker-options:clear node-js-app
```
```
-----> 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.
```shell
dokku docker-options:clear node-js-app run
```
```
-----> Clearing docker-options for node-js-app on phase run
```
```shell
dokku docker-options:clear node-js-app build,run
```
```
-----> Clearing docker-options for node-js-app on phase build
-----> Clearing docker-options for node-js-app on phase run
```
### Displaying docker-options reports for an app
> New as of 0.8.1
@@ -87,25 +123,3 @@ You can pass flags which will output only the value of the specific information
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.
Once you have mounted persistent storage, you will also need to restart the application. See the
[process scaling documentation](/docs/deployment/process-management.md) for more information.
[process scaling documentation](/docs/processes/process-management.md) for more information.
```shell
dokku ps:restart app-name
@@ -147,4 +147,4 @@ By default, Dokku will execute your buildpack application processes as the `hero
> NOTE: this user must exist in your herokuish image.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [scheduler-docker-local documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
> 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.
@@ -16,7 +16,7 @@ The resource plugin is meant to allow users to limit or reserve resources for a
By default, Dokku allows unlimited resource access to apps deployed on a server. In some cases, it may be desirable to limit this on a per-app or per-process-type basis. The `resource` plugin allows management of both resource "limits" and resource "reservations", where each resource request type has specific meaning to the scheduler in use for a given app.
> The meaning of a values and it's units are specific to the scheduler in use for a given app. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
> Warning: The meaning of a values and it's units are specific to the scheduler in use for a given app. If a value is incorrect for a scheduler, this may result in containers failing to start correctly. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
Valid resource options include:
@@ -26,6 +26,9 @@ Valid resource options include:
-`--network`
-`--network-ingress`
-`--network-egress`
-`--nvidia-gpu`
See the [Supported Resource Management Properties](/docs/advanced-usage/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
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.
@@ -101,6 +116,7 @@ dokku resource:limit --process-type web node-js-app
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.
@@ -196,6 +224,7 @@ dokku resource:reserve --process-type web node-js-app
These scheduler implementations may not be complete, though provide enough functionality for a user to get an app deployed via the underlying scheduler.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
@@ -44,15 +44,18 @@ This plugin implements various functionality through `plugn` triggers to integra
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-app-rename-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-app-status`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-logs-failed`
-`scheduler-is-deployed`
-`scheduler-logs`
-`scheduler-logs-failed`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
@@ -65,10 +68,16 @@ The `docker-local` scheduler supports a minimal list of resource _limits_ and _r
### Resource Limits
- cpu: (docker option: `--cpus`), and is specified in number of CPUs a process can access.
-memory: (docker option: `--memory`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory-swap: (docker option: `--memory-swap`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
-See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
### Resource Reservations
- memory: (docker option: `--memory-reservation`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
The following commands were previously deprecated and were removed in this release.
-`apps`: Use `apps:list` instead.
-`certs`: Use `certs:report` instead.
-`certs:info`: Use `certs:report` instead.
-`checks`: Use `checks:report` instead.
-`docker-options`: Use `docker-options:report` instead.
-`domains`: Use `domains:report` instead.
-`plugin`: Use `plugin:list` instead.
-`proxy`: Use `proxy:report` instead.
-`trace`: Use `trace:on` or `trace:off` instead.
-`ps`: Use `enter` with a container ID instead to run `ps auxww` within a container.
The refactor of the proxy plugin removes the following functions from being sourced in plugins:
-`proxy#get_app_proxy_port_map()`
-`proxy#list_app_proxy_ports()`
-`proxy#filter_app_proxy_ports()`
-`proxy#add_proxy_ports()`
-`proxy#remove_proxy_ports()`
-`proxy#set_proxy_ports()`
The informal policy is to allow removal of functions within a `functions` file if they are not used in OSS plugins. Should you be affected by any such removals, please file an issue to expose the functionality via a plugin trigger.
### Function renames
-`tar#tar_in_cmd` was renamed to `tar#cmd-tar-in`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
-`tar#tar_from_cmd` was renamed to `tar#cmd-tar-from`. Users should avoid using `cmd-*` commands directly, and instead file an issue to have them exposed via a plugin trigger.
### Remove support for Unsupported Operating Systems
Dokku will no longer distribute packages for Ubuntu versions that have reached either End of Life or End of Standard Support (for LTS releases). This currently includes the following releases:
- Ubuntu 14.04 (trusty)
- Ubuntu 14.10 (utopic)
- Ubuntu 15.04 (vivid)
- Ubuntu 15.10 (wily)
- Ubuntu 16.10 (yakkety)
- Ubuntu 17.04 (zesty)
- Ubuntu 17.10 (artful)
Dokku will no longer distribute packages for Debian versions that are not `stable` or `oldstable`. This currently includes the following releases:
- Debian 7 (wheezy)
- Debian 8 (jessie)
### App report flags
The `--git-sha` flag was moved from the `apps:report` command to the `git:report` command.
## 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`.
- You can now configure host -> container proxy port mappings
- The UI is handled by the [proxy](/docs/advanced-usage/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.
- 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](/docs/advanced-usage/proxy-management.md) 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
@@ -6,7 +6,7 @@ We should now properly handle file ownership for mounted directories. This was e
## 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](/docs/deployment/process-management.md#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.
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):
@@ -18,29 +18,30 @@ Let's take a quick look at the current Dokku nginx plugin that's shipped with Do
[See the full documentation](/docs/development/plugin-creation.md).
## Official Plugins (Beta)
## Official Plugins
The following plugins are available and provided by Dokku maintainers. Where noted, these plugins should be considered beta software and may not have been used as thoroughly as community plugins. Please file issues against their respective issue trackers.
The following plugins are available and provided by Dokku maintainers. Please file issues against their respective issue trackers.
<sup>1</sup> On Heroku similar functionality is offered by the [heroku-labs pipeline feature](https://devcenter.heroku.com/articles/labs-pipelines), which allows you to promote builds across multiple environments (staging -> production)
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>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).
Gitlab-CI can be used to automatically deploy a Dokku application using the [ilyasemenov/gitlab-ci-git-push image](https://github.com/IlyaSemenov/gitlab-ci-git-push) docker image.
## Prerequisites
Make sure you have a Gitlab account and a Dokku project hosted on Gitlab. This method works whether if you are using buildpacks or Dockerfile.
Make sure you have set up an app on the remote machine following [these instructions](http://dokku.viewdocs.io/dokku/deployment/application-deployment/) and can successfully deploy to it from the local machine.
## Deploy automatically to production
### Add a secret variable
Browse to the repository in question and visit the following path: `the Gitlab project > Settings > CI/CD.`
Click on `Secret variables > Expand` and fill in the blanks.
- Key: `SSH_PRIVATE_KEY`
- Value: paste in an SSH private key registered in Dokku:
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
- Environment scope: `production` (This make sure that `SSH_PRIVATE_KEY` is not available on merge requests or tests)
- Protected: Do not check this checkbox unless you know what you are doing
### Add CI script
Create a file named `.gitlab-ci.yml` at the root directory of the repository with the following contents:
```yaml
stages:
- deploy
variables:
APP_NAME:node-js-app
deploy:
image:ilyasemenov/gitlab-ci-git-push
stage:deploy
environment:
name:production
url:https://$APP_NAME.dokku.me/
only:
- master
script:
- git-push ssh://dokku@dokku.me:22/$APP_NAME
```
You will need to modify the `APP_NAME` variable to the correct value for your application name.
Running `git push origin master` will now trigger a gitlab-ci pipeline that will automatically deploy your application to your Dokku server. Go to your project on Gitlab and visit "Project > Pipelines" to see the deployment log.
## Review Applications
One useful feature of gitlab is to be able to create review applications for non-production branches. This allows teams to review changes _before_ they are pushed to production. First, recreate the `SSH_PRIVATE_KEY` secret - do not delete the existing secret - but scoped to the `review/*` environment. This will allow non-production gitlab environments access to the secret.
Next, we'll need to create the `review_app` gitlab job in our `.gitlab-ci.yaml`.
The first two lines ensure that Gitlab can talk to the Dokku server. Next, we take advantage of the `apps:clone` command, and clone the existing application and all of it's configuration to a new location. If the new application already exists, the third line of the `script` step will be ignored. We also ignore the first deploy script to speed up the cloning process. Finally, the fourth line of the `script` step will deploy the code as normal.
The above only runs for non-master branches, and will _also_ trigger an `on_stop` job called `stop_review_app`. When the branch is deleted or the code is merged, the `stop_review_app` job will be triggered.
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration.
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
```nginx
server{
listen80default_server;
server_name_;
access_logoff;
return410;
}
# To handle HTTPS requests, you can uncomment the following section.
#
# Please note that in order to let this work as expected, you need a valid
# SSL certificate for any domains being served. Browsers will show SSL
# errors in all other cases.
#
# Note that the key and certificate files in the below example need to
# be copied into /etc/nginx/ssl/ folder.
#
# server {
# listen 443 ssl;
# server_name _;
# ssl_certificate /etc/nginx/ssl/cert.crt;
# ssl_certificate_key /etc/nginx/ssl/cert.key;
# access_log off;
# return 410;
# }
```
Make sure to reload nginx after creating this file by running `service nginx reload`.
This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
The configuration file must be loaded before `/etc/nginx/conf.d/dokku.conf`, so it can not be arranged as a vhost in `/etc/nginx/sites-enabled` that is only processed afterwards.
Alternatively, you may push an app to your Dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
This is specific to your proxy plugin of choice. See the [nginx documentation](/docs/configuration/nginx.md#default-site) for more information on how to configure this for the default nginx proxy implementation.
The following list config variables have special meaning and can be set in a variety of ways.
The following config variables have special meanings and can be set in a variety of ways. Unless specified via global app config, the values may not be passed into applications. Usage of these values within applications should be considered unsafe, as they are an internal configuration values that may be moved to the internal properties system in the future.
> Warning: This list is not exhaustive, and may vary from version to version.
| `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. |
| `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. |
@@ -87,10 +87,11 @@ The following list config variables have special meaning and can be set in a var
| `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` | `http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_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. |
@@ -110,14 +111,12 @@ The following list config variables have special meaning and can be set in a var
| `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. |
nginx:validate-config [<app>] [--clean] # Validates and optionally cleans up invalid nginx configurations
```
## Checking access logs
## 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`.
@@ -23,9 +89,9 @@ You may also follow the logs by specifying the `-t` flag.
dokku nginx:access-logs node-js-app -t
```
## Checking error logs
### Checking error logs
You may check nginx error logs via the `nginx:access-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`.
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
@@ -37,39 +103,116 @@ You may also follow the logs by specifying the `-t` flag.
dokku nginx:error-logs node-js-app -t
```
## Regeneratingnginx config
### Changing log path
In certain cases, your app nginx configs may drift from the correct config for your app. You may regenerate the config at any point via the `nginx:build-config` command. This may fail if there are no current web listeners for your app.
> New as of 0.20.1
The path to where log files are stored can be changed by calling the `nginx:set` command with the following options:
The defaults should not be changed without verifying that the paths will be writeable by nginx. However, this setting is useful for enabling or disabling logging by setting the values to `off`.
```shell
dokku nginx:build-config node-js-app
dokku nginx:set node-js-app access-log-path off
dokku nginx:set node-js-app error-log-path off
```
## Validating nginx configs
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:validate
dokku nginx:set node-js-app access-log-path
dokku nginx:set node-js-app error-log-path
```
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate` command is the exit code of `nginx -t` against the server's real nginx config.
In all cases, the nginx config must be regenerated after setting the above values.
The `nginx:validate` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
### 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:
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 --clean
dokku nginx:validate-config --clean
```
The `--clean` flag may also be specified for a given app:
```shell
dokku nginx:validate node-js-app --clean
dokku nginx:validate-config node-js-app --clean
```
## Customizing the nginx configuration
### Customizing the nginx configuration
> New as of 0.5.0
@@ -77,20 +220,33 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
- Copy the following example template to a file named `nginx.conf.sigil` and either:
- If using a buildpack application, you __must__ check it into the root of your app repo.
-`ADD` it to your dockerfile `WORKDIR`
-if your dockerfile has no `WORKDIR`, `ADD` it to the `/app` folder
-If using a dockerfile or docker image for deploys, either:
-If `WORKDIR` is specified, add the file to the `WORKDIR` specified in the last Dockerfile stage (example: `WORKDIR /app` and `ADD nginx.conf.sigil /app`).
- If no `WORKDIR` is specified, add the file to the root (`/`) of the docker image (example: `ADD nginx.conf.sigil /`).
> When using a custom `nginx.conf.sigil` file, depending upon your application configuration, you *may* be exposing the file externally. As this file is extracted before the container is run, you can, safely delete it in a custom `entrypoint.sh` configured in a Dockerfile `ENTRYPOINT`.
> 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.
### Available template variables
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
{{ .PROXY_PORT }} Non-SSL nginx listener port (same as `DOKKU_PROXY_PORT` config var)
{{ .PROXY_SSL_PORT }} SSL nginx listener port (same as `DOKKU_PROXY_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
@@ -101,9 +257,11 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an `.DOKKU_APP_${PROCESS_TYPE}_LISTENERS` variable - the `PROCESS_TYPE` will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
> Note: Application config variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
### Customizing via configuration files included by the default templates
#### Customizing via configuration files included by the default templates
The default nginx.conf template will include everything from your apps `nginx.conf.d/` subdirectory in the main `server {}` block (see above):
@@ -111,11 +269,11 @@ The default nginx.conf template will include everything from your apps `nginx.co
include {{ .DOKKU_ROOT }}/{{ .APP }}/nginx.conf.d/*.conf;
```
That means you can put additional configuration in separate files, for example to limit the uploaded body size to 50 megabytes, do
That means you can put additional configuration in separate files. To increase the client request header timeout, the following can be performed:
@@ -125,10 +283,10 @@ The example above uses additional configuration files directly on the Dokku host
For PHP Buildpack users, you will also need to provide a `Procfile` and an accompanying `nginx.conf` file to customize the nginx config *within* the container. The following are example contents for your `Procfile`
Your `nginx.conf` file - not to be confused with Dokku's `nginx.conf.sigil` - would also need to be configured as shown in this example:
client_max_body_size 50m;
client_header_timeout 50s;
location / {
index index.php;
try_files $uri $uri/ /index.php$is_args$args;
@@ -136,7 +294,7 @@ Your `nginx.conf` file - not to be confused with Dokku's `nginx.conf.sigil` - wo
Please adjust the `Procfile` and `nginx.conf` file as appropriate.
## Custom Error Pages
### Custom Error Pages
By default, Dokku provides custom error pages for the following three categories of errors:
@@ -146,38 +304,80 @@ By default, Dokku provides custom error pages for the following three categories
These are provided as an alternative to the generic Nginx error page, are shared for _all_ applications, and their contents are located on disk at `/var/lib/dokku/data/nginx-vhosts/dokku-errors`. To customize them for a specific app, create a custom `nginx.conf.sigil` as described above and change the paths to point elsewhere.
## Domains plugin
### Default site
See the [domain configuration documentation](/docs/configuration/domains.md).
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.
## Customizing hostnames
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames).
```nginx
server{
listen80default_server;
listen[::]:80default_server;
## Disabling VHOSTS
server_name_;
access_logoff;
return410;
}
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts).
# 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;
# }
```
## Default site
Make sure to reload nginx after creating this file by running `service nginx reload`.
See the [default site documentation](/docs/configuration/domains.md#default-site).
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).
## Running behind a load balancer
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.
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer).
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.
## HSTS Header
## Other
See the [HSTS documentation](/docs/configuration/ssl.md#hsts-header).
### Domains plugin
## SSL Configuration
See the [domain configuration documentation](/docs/configuration/domains.md) for more information on how to configure domains for your app.
See the [ssl documentation](/docs/configuration/ssl.md).
### Customizing hostnames
## Disabling Nginx
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames) for more information on how to configure domains for your app.
See the [proxy documentation](/docs/advanced-usage/proxy-management.md).
### Disabling VHOSTS
## Managing Proxy Port mappings
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts) for more information on how to disable domain usage for your app.
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#proxy-port-mapping).
### 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.
@@ -9,6 +9,7 @@ certs:add <app> CRT KEY # Add an ssl endpoint to an app. Can al
certs:generate <app> DOMAIN # Generate a key and certificate signing request (and self-signed certificate)
certs:remove <app> # Remove an SSL Endpoint from an app.
certs:report [<app>] [<flag>] # Displays an ssl report for one or more apps
certs:show <app> <crt|key> # Show the server.crt or server.key on stdout
certs:update <app> CRT KEY # Update an SSL Endpoint on an app. Can also import from a tarball on stdin
```
@@ -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](/docs/advanced-usage/proxy-management.md) 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
@@ -56,6 +57,16 @@ If you decide to obtain a CA signed certificate, you can import that certificate
The `certs:remove` command only works on app-specific certificates. It will `rm` the app-specific tls directory, rebuild the nginx configuration, and reload nginx.
### Showing the certificate
The `certs:show` command can be used to show your configured certs for an app. The show command can be used for example to export Let's Encrypt certificates
after they've been generated. You can export it as follows:
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does not, by default, enable this header. It is thus left up to you, the user, to enable it for your site.
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does enables this header by default for HTTPS requests.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails.
See the [NGINX HSTS documentation](/docs/configuration/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
## HTTP/2 support
@@ -125,44 +136,32 @@ Certain versions of nginx have bugs that prevent [HTTP/2](https://nginx.org/en/d
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-Port` and `X-Forwarded-For`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
If your server runs behind an HTTP/S load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by using the following [nginx custom template](/docs/configuration/nginx.md#customizing-the-nginx-configuration)
If your server runs behind an HTTP(S) load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application 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.
> Note: This walkthrough uses the hostname `dokku.me` in commands. When deploying to your own server, you should set the `DOKKU_DOMAIN` value in the `Vagrantfile` before you initialize the Vagrant VM.
> 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
@@ -62,7 +62,7 @@ Now you can deploy the `ruby-getting-started` app to your Dokku server. All you
# the remote username *must* be dokku or pushes will fail
> Note: Some tools may not support the short-upstream syntax referenced above, and you may need to prefix
@@ -71,7 +71,7 @@ git push dokku master
> Note: Your private key should be registered with `ssh-agent` in your local development environment. If you get a `permission denied` error when pushing, you can register your private key as follows: `ssh-add -k ~/<your private key>`.
After running `git push dokku master`, you should have output similar to this in your terminal:
After running `git push dokku main:master`, you should have output similar to this in your terminal:
Once the deploy is complete, the application's web URL will be generated as above.
Dokku supports deploying applications via [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) with [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks), as well as by using a project's [Dockerfile](https://docs.docker.com/reference/builder/).
Dokku supports deploying applications in a few ways:
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [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.
### Skipping deployment
@@ -121,7 +125,7 @@ If you need to redeploy or restart your app:
dokku ps:rebuild ruby-getting-started
```
See the [process scaling documentation](/docs/deployment/process-management.md) for more information.
See the [process scaling documentation](/docs/processes/process-management.md) for more information on how to manage your app processes.
### Deploying with private Git submodules
@@ -143,8 +147,9 @@ If you do not enter a fully qualified domain name when pushing your app, Dokku d
```shell
# from your local machine
# the remote username *must* be dokku or pushes will fail
# the below example assumes your app server domain or IP is dokku.me. Push in the form of: dokku@{serveripordomain}:{dokkuappname}
@@ -158,7 +163,7 @@ You can also specify the fully qualified name as follows:
# from your local machine
# the remote username *must* be dokku or pushes will fail
git remote add dokku dokku@dokku.me:app.dokku.me
git push dokku master
git push dokku main:master
```
```
@@ -172,7 +177,7 @@ This is useful when you want to deploy to the root domain:
# from your local machine
# the remote username *must* be dokku or pushes will fail
git remote add dokku dokku@dokku.me:dokku.me
git push dokku master
git push dokku main:master
```
... deployment ...
@@ -188,36 +193,36 @@ Prior to every deployment, Dokku will execute a cleanup function. As of 0.5.x, t
## Adding deploy users
See the [user management documentation](/docs/deployment/user-management.md).
See the [user management documentation](/docs/deployment/user-management.md) for more information on how to manage users with access to your Dokku server.
## Default vhost
See the [nginx documentation](/docs/configuration/nginx.md#default-site).
See the [domains documentation](/docs/configuration/domains.md#default-site) for more information on how to manage the default site.
## Deploying non-master branch
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch).
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch) for more information on deploying a non-master branch to your application.
## Dockerfile deployment
See the [Dockerfile documentation](/docs/deployment/methods/dockerfiles.md).
See the [Dockerfile documentation](/docs/deployment/builders/dockerfiles.md) for information Dokku's Dockerfile support.
## Image tagging
See the [image tagging documentation](/docs/deployment/methods/images.md).
See the [image tagging documentation](/docs/deployment/methods/images.md) for more information on how Docker images can be tagged and deployed for a given application.
## Specifying a custom buildpack
See the [buildpack documentation](/docs/deployment/methods/buildpacks.md).
See the [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](/docs/deployment/application-management.md#removing-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app) for more information on how to remove an application from your Dokku server.
## Renaming a deployed app
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app) for more information on how an application can be renamed and the impact of doing so upon the application and associated resources.
## Zero downtime deploy
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md).
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md) for more information on how Dokku enables zero-downtime deploys.
The `--force` flag can also be specified on the command vs globally:
```shell
dokku apps:destroy --force node-js-app
```
```
Destroying node-js-app (including all add-ons)
```
Destroying an application will unlink all linked services and destroy any config related to the application. Note that linked services will retain their data for later use (or removal).
### Renaming a deployed app
@@ -134,6 +144,12 @@ Renaming node-js-app to io-js-app... done
This will copy all of your app's contents into a new app directory with the name of your choice, delete your old app, then rebuild the new version of the app and deploy it. All of your config variables, including database urls, will be preserved.
By default, Dokku will deploy the renamed app, though you can skip the deploy by using the `--skip-deploy` flag:
@@ -157,7 +173,7 @@ This will copy all of your app's contents into a new app directory with the name
> Warning: If you have exposed specific ports via `docker-options` plugin, or performed anything that cannot be done against multiple applications, `apps:clone` may result in errors.
By default, Dokku will deploy this new application, though you can skip the deploy by using the `--skip-deploy` flag:
By default, Dokku will deploy this new app, though you can skip the deploy by using the `--skip-deploy` flag:
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).
@@ -6,12 +6,20 @@ While Dokku normally defaults to using [Heroku buildpacks](https://devcenter.her
> Dockerfile support is considered a *power user* feature. By using Dockerfile-based deployment, you agree that you will not have the same comfort as that enjoyed by buildpack users, and Dokku features may work differently. Differences between the two systems will be documented here.
To use a Dockerfile for deployment, commit a valid `Dockerfile` to the root of your repository and push the repository to your Dokku installation. If this file is detected, Dokku will default to using it to construct containers *except* in the following two cases:
## Usage
- The application has a `BUILDPACK_URL` environment variable set via the `dokku config:set` command or in a committed `.env` file. In this case, Dokku will use your specified buildpack.
- The application has a `.buildpacks` file in the root of the repository. In this case, Dokku will use your specified buildpack(s).
### Detection
## Switching from buildpack deployments
This builder will be auto-detected in the following case:
- A `Dockerfile` exists in the root of the app repository.
Dokku will only select the `dockerfile` builder if both the `herokuish` and `pack` builders are not detected and a Dockerfile exists. For more information on how those are detected, see the following links:
For security reasons - and as per [Docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available only during runtime.
Once set, the Dockerfile usage would be as follows:
```Dockerfile
FROM debian:jessie
FROM ubuntu:18.04
# set the argument default
ARG NODE_ENV=production
@@ -50,7 +58,7 @@ RUN echo $NODE_ENV
You may also set the argument as an environment variable
```Dockerfile
FROM debian:jessie
FROM ubuntu:18.04
# set the argument default
ARG NODE_ENV=production
@@ -65,7 +73,11 @@ ENV NODE_ENV ${NODE_ENV}
RUN echo $NODE_ENV
```
## Customizing the run command
### Building images with Docker Buildkit
If your Dockerfile is using Docker engine's [buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set. One way to do this is to edit `/etc/environment` on your dokku host and reboot your instance. Note, for complete build log output, you should also set `BUILDKIT_PROGRESS=plain` in the same file.
### Customizing the run command
By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base Node.js image, with the following `ENTRYPOINT`:
@@ -101,7 +113,7 @@ worker: bin/run-worker.sh
And `Dockerfile`:
```Dockerfile
FROM debian:jessie
FROM ubuntu:18.04
WORKDIR /app
COPY . ./
CMD ["bin/run-dev.sh"]
@@ -114,6 +126,6 @@ started by running `docker run bin/run-worker.sh` (the actual `docker run` comma
complex, but this is the basic idea). If you use an `ENTRYPOINT` in your `Dockerfile`, the lines
in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instead of being executed.
## Exposed ports
### Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
buildpacks:add [--index 1] <app> <buildpack> # Add new app buildpack while inserting into list of buildpacks if necessary
buildpacks:clear <app> # Clear all buildpacks set on the app
buildpacks:list <app> # List all buildpacks for an app
buildpacks:remove <app> <buildpack> # Remove a buildpack set on the app
buildpacks:report [<app>] [<flag>] # Displays a buildpack report for one or more apps
buildpacks:set [--index 1] <app> <buildpack> # Set new app buildpack at a given position defaulting to the first buildpack if no index is specified
buildpacks:add [--index 1] <app> <buildpack> # Add new app buildpack while inserting into list of buildpacks if necessary
buildpacks:clear <app> # Clear all buildpacks set on the app
buildpacks:list <app> # List all buildpacks for an app
buildpacks:remove <app> <buildpack> # Remove a buildpack set on the app
buildpacks:report [<app>] [<flag>] # Displays a buildpack report for one or more apps
buildpacks:set [--index 1] <app> <buildpack> # Set new app buildpack at a given position defaulting to the first buildpack if no index is specified
buildpacks:set-property [--global|<app>] <key> <value> # Set or clear a buildpacks property for an app
```
> Warning: If using the `buildpacks` plugin, be sure to unset any `BUILDPACK_URL` and remove any such entries from a committed `.env` file. A specified `BUILDPACK_URL` will always override a `.buildpacks` file or the buildpacks plugin.
@@ -24,6 +25,23 @@ This page will cover usage of the `buildpacks` plugin.
## Usage
### Detection
This builder will be auto-detected in either the following cases:
- The `BUILDPACK_URL` app environment variable is set.
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
- A `.buildpacks` file exists in the root of the app repository.
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
The builder can also be specified via the `builder:set` command:
```shell
dokku builder:set node-js-app selected herokuish
```
> 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.
### Listing Buildpacks in Use
The `buildpacks:list` command can be used to show buildpacks that have been set for an app. This will omit any auto-detected buildpacks.
@@ -123,6 +141,34 @@ The `buildpacks:clear` command can be used to clear all configured buildpacks fo
dokku buildpacks:clear node-js-app
```
### Customizing the Buildpack stack builder
> New as of 0.23.0
The default stack builder in use by Herokuish buildpacks in Dokku is based on `gliderlabs/herokuish:latest`. Typically, this is installed via an OS package which pulls the requisite Docker image. 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_IMAGE` environment variable (`gliderlabs/herokuish:latest` by default).
While many buildpacks have a default command that is run when a detected repository is pushed, it is possible to override this command via a Procfile. A Procfile can also be used to specify multiple commands, each of which is subject to process scaling. See the [process scaling documentation](/docs/deployment/process-management.md) for more details around scaling individual processes.
While many buildpacks have a default command that is run when a detected repository is pushed, it is possible to override this command via a Procfile. A Procfile can also be used to specify multiple commands, each of which is subject to process scaling. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
A Procfile is a file named `Procfile`. It should be named `Procfile` exactly, and not anything else. For example, `Procfile.txt` is not valid. The file should be a simple text file.
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/deployment/process-management.md) for more details around scaling individual processes.
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache).
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache) for more information on how to clear buildpack build cache for an application.
In cases where there is no direct or documented integration available, the Dokku project provides an [Official Docker Image](https://github.com/dokku/ci-docker-image) for use in Continuous Integration/Continuous Deployment (CI/CD) systems.
Assuming a Docker image can be run as a CI task with environment variables injected, the following CI systems will have their variables automatically detected:
The Dokku project has an official Githb Action available on the [Github Marketplace](https://github.com/marketplace/actions/dokku). The simplest usage example is as follows:
```yaml
---
name:'deploy'
on:
push:
branches:
- master
jobs:
deploy:
runs-on:ubuntu-latest
steps:
- name:Cloning repo
uses:actions/checkout@v2
with:
fetch-depth:0
- name:Push to dokku
uses:dokku/github-action@v1
with:
git_remote_url:'ssh://dokku@dokku.me:22/appname'
ssh_private_key:${{ secrets.SSH_PRIVATE_KEY }}
```
For further usage documentation and other advanced examples, see the entry on the [Github Marketplace](https://github.com/marketplace/actions/dokku).
Gitlab-CI can be used to automatically deploy a Dokku application via the official the [dokku/ci-docker-image](https://github.com/dokku/ci-docker-image). The simplest example is as follows:
```
---
image: dokku/ci-docker-image
stages:
- deploy
variables:
GIT_DEPTH: 0
deploy:
stage: deploy
only:
- master
variables:
GIT_REMOTE_URL: ssh://dokku@dokku.me:22/appname
script: dokku-deploy
after_script: dokku-unlock
```
For further usage documentation and other advanced examples, see Dokku's [gitlab-ci](https://github.com/dokku/gitlab-ci) repository.
logs:vector-start # Start the vector logging container
logs:vector-stop # Stop the vector logging container
```
## Usage
@@ -36,18 +41,137 @@ will show logs continually from the web process.
### Failed deploy logs
> Warning: The default `docker-local` scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
> Warning: The default [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md) will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
In some cases, it may be useful to retrieve the logs from a previously failed deploy.
You can retrieve these logs by using the `logs:failed` command
You can retrieve these logs by using the `logs:failed` command.
```shell
dokku logs:failed node-js-app
```
You can also retrieve the failed logs for each app:
You may also fetch all failed app logs by using the `--all` flag.
```shell
dokku logs:failed node-js-app
dokku logs:failed --all
```
### Docker Log Retention
Docker log retention can be specified via the `logs:set` command by specifying a value for `max-size`. Log retention is set via injected docker options for all applications, but is also available via the `logs-get-property` trigger for alternative schedulers.
```shell
dokku logs:set node-js-app max-size 20m
```
The default value may be set by passing an empty value for the option:
```shell
dokku logs:set node-js-app max-size
```
Valid values include any integer number followed by a unit of measure (`k`, `m`, or `g`) or the string `unlimited`. Setting to `unlimited` will result in Dokku omitting the log option.
The `max-size` property can also be set globally. The global default is `10m`, and the global value is used when no app-specific value is set.
```shell
dokku logs:set --global max-size 20m
```
The default value may be set by passing an empty value for the option.
```shell
dokku logs:set --global max-size
```
### Vector Logging Shipping
> New as of 0.22.6
Vector is an open-source, lightweight and ultra-fast tool for building observability pipelines. Dokku integrates with it for shipping container logs for the `docker-local` scheduler. Users may configure log-shipping on a per-app or global basis, neither of which interfere with the `dokku logs` commands.
#### Starting the Vector container
> Warning: While the default vector image may be updated over time, this will not impact running vector containers. Users are encouraged to view any Dokku and Vector changelogs to ensure their system will continue running as expected.
Vector may be started via the `logs:vector-start` command.
```shell
dokku logs:vector-start
```
This will start a new container named `vector` with Dokku's vector config mounted and ready for use. If a running container already exists, this command will do nothing. Additionally, if a container exists but is not running, this command will attempt to start the container.
While the default vector image is hardcoded, users may specify an alternative via the `--vector-image` flag:
The final volume mount - `/var/log/dokku/apps` - may be used for users that wish to ship logs to a file on disk that may be later logrotated. This directory is owned by the `dokku` user and group, with permissions set to `0755`. At this time, log-rotation is not configured for this directory.
#### Stopping the Vector container
Vector may be stopped via the `logs:vector-stop` command.
```shell
dokku logs:vector-stop
```
The `vector` container will be stopped and removed from the system. If the container is not running, this command will do nothing.
#### Configuring a log sink
Vector uses the concept of log "sinks" to send logs to a given endpoint. Log sinks may be configured globally or on a per-app basis by specifying a `vector-sink` in DSN form with the `logs:set` command. Specifying a sink value will reload any running vector container.
```shell
# setting the sink value in quotes is encouraged to avoid
# issues with ampersand encoding in shell commands
As with app-specific sink settings, the global value may also be cleared by setting no value.
```shell
dokku logs:set --global vector-sink
```
##### Log Sink DSN Format
The DSN form of a sink is as follows:
```
SINK_TYPE://?SINK_OPTIONS
```
Valid values for `SINK_TYPE` include all log vector log sinks, while `SINK_OPTIONS` is a query-string form for the sink's options. The following is a short description on how to set various values:
-`bool`: form: `key=bool`
-`string`: form: `key=string`
-`int`: form: `key=int`
-`[string]`: form: `key[]=string`
-`[int]`: form: `key[]=int`
-`table`: form: `option[key]=value
Please read the [sink documentation](https://vector.dev/docs/reference/sinks/) for your sink of choice to configure the sink as desired.
git:initialize <app> # Initialize a git repository for an app
git:report [<app>] [<flag>] # Displays a git report for one or more apps
git:set <app> <key> (<value>) # Set or clear a git property for an app
git:allow-host <host> # Adds a host to known_hosts
git:auth <host> [<username> <password>] # Configures netrc authentication for a given git server
git:from-archive [--archive-type ARCHIVE_TYPE] <app> <archive-url> [<git-username> <git-email>] # Updates an app's git repository with a given archive file
git:from-image [--build-dir DIRECTORY] <app> <docker-image> [<git-username> <git-email>] # Updates an app's git repository with a given docker image
git:sync [--build] <app> <repository> [<git-ref>] # Clone or fetch an app from remote git repo
git:initialize <app> # Initialize a git repository for an app
git:public-key # Outputs the dokku public deploy key
git:report [<app>] [<flag>] # Displays a git report for one or more apps
git:set <app> <key> (<value>) # Set or clear a git property for an app
```
Git-based deployment has been the traditional method of deploying applications in Dokku. As of v0.12.0, Dokku introduces a few ways to customize the experience of deploying via `git push`. A Git-based deployment currently supports building applications via both [Buildpack](/docs/deployment/methods/buildpacks.md) and [Dockerfile](/docs/deployment/methods/dockerfiles.md).
Git-based deployment has been the traditional method of deploying applications in Dokku. As of v0.12.0, Dokku introduces a few ways to customize the experience of deploying via `git push`. A Git-based deployment currently supports building applications via:
> Warning: Pushing from a shallow clone is not currently supported and may have undefined behavior. Please unshallow your local repository before pushing to a Dokku app to avoid potential errors in the deployment process.
### Initializing an application
When an application is created via `git push`, Dokku will create the proper `pre-receive` hook in order to execute the build pipeline. In certain cases - such as when fronting deploys with the [`git-http-backend`](https://git-scm.com/docs/git-http-backend) - this may not be correctly created. As an alternative, the `git:initialize` command can be used to trigger this creation:
# delete the .git directory during builds (default)
dokku git:set node-js-app keep-git-dir ""
```
Please keep in mind that setting `keep-git-dir` to `true` may result in unstaged changes shown within the built container due to the build process generating application changes within the built app directory.
### Initializing an app repository from a docker image
> New as of 0.24.0
A Dokku app repository can be initialized or updated from a Docker image via the `git:from-image` command. This command will either initialize the app repository or update it to include the specified Docker image via a `FROM` stanza. This is an excellent way of tracking changes when deploying only a given docker image, especially if deploying an image from a remote CI/CD pipeline.
In the above example, Dokku will build the app as if the repository contained _only_ a `Dockerfile` with the following content:
```Dockerfile
FROMdokku/node-js-getting-started:latest
```
Triggering a build with the same arguments multiple times will result in Dokku exiting `0` early as there will be no changes detected.
The `git:from-image` command can optionally take a git `user.name` and `user.email` argument (in that order) to customize the author. If the arguments are left empty, they will fallback to `Dokku` and `automated@dokku.sh`, respectively.
Finally, certain images may require a custom build context in order for `ONBUILD ADD` and `ONBUILD COPY` statements to succeed. A custom build context can be specified via the `--build-dir` flag. All files in the specified `build-dir` will be copied into the repository for use within the `docker build` process. The build context _must_ be specified on each deploy, and is not otherwise persisted between builds.
See the [dockerfile documentation](/docs/deployment/methods/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
### Initializing an app repository from an archive file
> New as of 0.24.0
A Dokku app repository can be initialized or updated from the contents of an archive file via the `git:from-archive` command. This is an excellent way of tracking changes when deploying pre-built binary archives, such as java jars or go binaries. This can also be useful when deploying directly from a Github repository at a specific commit.
In the above example, Dokku will build the app as if the repository contained the extracted contents of the specified archive file.
Triggering a build with the same archive file multiple times will result in Dokku exiting `0` early as there will be no changes detected.
The `git:from-archive` command can optionally take a git `user.name` and `user.email` argument (in that order) to customize the author. If the arguments are left empty, they will fallback to `Dokku` and `automated@dokku.sh`, respectively.
The default archive type is always set to `.tar`. To use a different archive type, specify the `--archive-type` flag. Failure to do so will result in a failure to extract the archive.
```shell
dokku git:from-archive --archive-type zip node-js-app https://github.com/dokku/smoke-test-app/archive/2.0.0.zip "Camila""camila@example.com"
```
Finally, if the archive url is specified as `--`, the archive will be fetched from stdin.
### Initializing an app repository from a remote repository
> New as of 0.23.0
A Dokku app repository can be initialized or updated from a remote git repository via the `git:sync` command. This command will either clone or fetch updates from a remote repository and has undefined behavior if the history cannot be fast-fowarded to the referenced repository reference. Any repository that can be cloned by the `dokku` user can be specified.
> The application must exist before the repository can be initialized
Initializing from a private repository requires one of the following:
- A Public SSH Key (`id_rsa.pub` file) configured on the remote server, with the associated private key (`id_rsa`) in the Dokku server's `/home/dokku/.ssh/` directory.
- A configured [`.netrc`](https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html) entry.
Dokku provides the `git:auth` command which can be used to configure a `netrc` entry for the remote server. This command can be used to add or remove configuration for any remote server.
For syncing to a private repository stored on a remote Git product such as Github or Gitlab, Dokku's recommendation is to use a personal access token on a bot user where possible. Please see your service's documentation for information regarding the recommended best practices.
### Allowing remote repository hosts
By default, the Dokku host may not have access to a server containing the remote repository. This can be initialized via the `git:allow-host` command.
```shell
dokku git:allow-host github.com
```
Note that this command is currently not idempotent and may add duplicate entries to the `~dokku/.ssh/known_hosts` file.
### Verifying the cloning public key
In order to clone a remote repository, the remote server should have the Dokku host's public key configured. This plugin does not currently create this key, but if there is one available, it can be shown via the `git:public-key` command.
```shell
dokku git:public-key
```
If there is no key, an error message is shown that displays the command that can be run on the Dokku server to generate a new public/private ssh key pair.
> Warning: As of 0.24.0, this functionality 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 a future release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-image`.
>
> New as of 0.4.0
```
@@ -22,7 +24,7 @@ The Dokku tags plugin allows you to add Docker image tags to the currently deplo
### Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
> Warning: As of 0.24.0, this functionality 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 a future release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-arhive`.
Sometimes you need to either inspect running containers or run a one-off command under an application. In those cases, Dokku makes it easy to either connect to a running container or run a fresh container.
## Run a command in an app environment
```
run [ --env KEY=VALUE | -e KEY=VALUE ] <app> <cmd> # Run a command in a new container using the current application image
```
The `run` command can be used to run a one-off process for a specific command. This will start a new container and run the desired command within that container. Note that this container will be stay around even after command completes. The container will be the same container as was used to start the currently deployed application.
```shell
# runs `ls -lah` in the `/app` directory of the application `node-js-app`
dokku run node-js-app ls -lah
# optionally, run can be passed custom environment variables
dokku run --env "NODE_ENV=development" --env "PATH=/custom/path" node-js-app npm run mytask
```
The `run` command can also be used to run a command defined in your Procfile:
```
console: bundle exec racksh
```
```shell
# runs `bundle exec racksh` in the `/app` directory of the application `my-app`
dokku run my-app console
```
If you want to remove the container after a command has started, you can run the following command:
```shell
# don't keep `run` containers around
dokku config:set --global DOKKU_RM_CONTAINER=1
# revert the above setting and keep containers around
dokku config:unset --global DOKKU_RM_CONTAINER
```
You may also use the `--rm-container` or `--rm` Dokku flags to remove the containers automatically:
```shell
dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
Containers may have specific labels attached. In order to avoid issues with dokku internals, do not use any labels beginning with either `com.dokku` or `org.label-schema`.
```shell
dokku --label=com.example.test-label=value run node-js-app ls -lah
```
Finally, you may wish to run a container in "detached" mode via the `--detach` Dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
```shell
dokku --detach run node-js-app ls -lah
# returns the ID of the new container
```
> Note that you may not use the `--rm-container` or `--rm` flags when running containers in detached mode, and attempting to do so will result in the `--detach` flag being ignored.
### Using `run` for cron tasks
You can always use a one-off container to run an application task:
```shell
dokku --rm run node-js-app some-command
dokku --rm-container run node-js-app some-command
```
For tasks that should not be interrupted, run is the *preferred* method of handling cron tasks, as the container will continue running even during a deploy or scaling event. The trade-off is that there will be an increase in memory usage if there are multiple concurrent tasks running.
## Entering existing containers
> New as of 0.4.0
```
enter <app> [<container-type> || --container-id <container-id>] # Connect to a specific app container
```
The `enter` command can be used to enter a running container. The following variations of the command exist:
```shell
dokku enter node-js-app web
dokku enter node-js-app web.1
dokku enter node-js-app --container-id ID
```
Additionally, you can run `enter` with no `<container-type>`. If only a single `<container-type>` is defined in your app, you will be dropped into the only running container. This behavior is not supported when specifying a custom command; as described below.
By default, it runs a `/bin/bash`, but can also be used to run a custom command:
```shell
# just echo hi
dokku enter node-js-app web echo hi
# run a long-running command, as one might for a cron task
dokku enter node-js-app web python script/background-worker.py
```
### Using `enter` for cron tasks
Your Procfile can have the following entry:
```Procfile
cron: sleep infinity
```
With the `cron` process scaled to `1`:
```shell
dokku ps:scale node-js-app cron=1
```
You can now run all your commands in that container:
```shell
dokku enter node-js-app cron some-command
```
Note that you can also run multiple commands at the same time to reduce memory usage, though that may result in polluting the container environment.
For tasks that will properly resume, you *should* use the above method, as running tasks will be interrupted during deploys and scaling events, and subsequent commands will always run with the latest container. Note that if you scale the cron container down, this may interrupt proper running of the task.
## General cron recommendations
Regularly scheduled tasks can be a bit of a pain with Dokku. The following are general recommendations to follow to help ensure successful task runs.
- Use the `dokku` user's crontab.
- If you do not, the `dokku` binary will attempt to execute with `sudo`, and your cron run with fail with `sudo: no tty present and no askpass program specified`.
- Add a `MAILTO` environment variable to ship cron emails to yourself.
- Add a `PATH` environment variable or specify the full path to binaries on the host.
- Add a `SHELL` environment variable to specify Bash when running commands.
- Keep your cron tasks in time-sorted order.
- Keep your server time in UTC so you don't need to translate daylight savings time when reading the cronfile.
- Run tasks at the lowest traffic times if possible.
- Use cron to *trigger* jobs, not run them. Use a real queuing system such as rabbitmq to actually process jobs.
- Try to keep tasks quiet so that mails only send on errors.
- Do not silence standard error or standard out. If you silence the former, you will miss failures. Silencing the latter means you should actually make application changes to handle log levels.
- Use a service such as [Dead Man's Snitch](https://deadmanssnitch.com) to verify that cron tasks completed successfully.
- Add lots of comments to your cronfile, including what a task is doing, so that you don't spend time deciphering the file later.
- Place your cronfiles in a pattern such as `/etc/cron.d/APP`.
- Do not use non-ASCII characters in your cronfile names. cron is finicky.
- Remember to have trailing newlines in your cronfile! cron is finicky.
The following is a sample cronfile that you can use for your applications:
```cron
# server cron jobs
MAILTO="mail@dokku.me"
PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
# m h dom mon dow username command
# * * * * * dokku command to be executed
# - - - - -
# | | | | |
# | | | | +----- day of week (0 - 6) (Sunday=0)
# | | | +------- month (1 - 12)
# | | +--------- day of month (1 - 31)
# | +----------- hour (0 - 23)
# +----------- min (0 - 59)
### HIGH TRAFFIC TIME IS B/W 00:00 - 04:00 AND 14:00 - 23:59
### RUN YOUR TASKS FROM 04:00 - 14:00
### KEEP SORTED IN TIME ORDER
### PLACE ALL CRON TASKS BELOW
# removes unresponsive users from the subscriber list to decrease bounce rates
By default, Dokku will only start a single `web` process - if defined - though process scaling can be managed by the `ps` plugin or [via a custom `DOKKU_SCALE` file](/docs/deployment/process-management.md#manually-managing-process-scaling).
> The `web` proctype is the only proctype that will invoke custom checks as defined by a `CHECKS` file. It is also the only process type that will be launched in a container that is either proxied via nginx or bound to an external port.
## Usage
### Listing processes running in an app container
To find out if your application's containers are running the commands you expect, simply run the `ps` command against that application.
```shell
dokku ps node-js-app
```
### Inspecting app containers
> New as of 0.13.0
A common administrative task to perform is calling `docker inspect` on the containers that are running for an application. This can be an error-prone task to perform, and may also reveal sensitive environment variables if not done correctly. Dokku provides a wrapper around this command via the `ps:inspect` command:
```shell
dokku ps:inspect node-js-app
```
This command will gather all the running container IDs for your application and call `docker inspect`, sanitizing the output data so it can be copy-pasted elsewhere safely.
### Rebuilding applications
There are some Dokku commands which will not automatically rebuild an application's environment, or which can be told to skip a rebuild. For instance, you may wish to run multiple `config:set` commands without a restart so as to speed up configuration. In these cases, you can ultimately trigger an application rebuild using `ps:rebuild`
```shell
dokku ps:rebuild node-js-app
```
You may also rebuild all applications at once, which is useful when enabling/disabling a plugin that modifies all applications:
```shell
dokku ps:rebuildall
```
> The `ps:rebuild` and `ps:rebuildall` commands only work for applications for which there is a source, and thus
> will only always work deterministically for Git-deployed application. Please see
> the [images documentation](/docs/deployment/methods/images.md) and [tar documentation](/docs/deployment/methods/tar.md)
> in for more information concerning rebuilding those applications.
### Restarting applications
Applications can be restarted, which is functionally identical to calling the `release_and_deploy` function on an application. Please note that any linked containers *must* be started before the application in order to have a successful boot.
```shell
dokku ps:restart node-js-app
```
You may also trigger a restart on all applications at one time:
```shell
dokku ps:restartall
```
### `ps:scale` command
Dokku can also manage scaling itself via the `ps:scale` command. This command can be used to scale multiple process types at the same time.
```shell
dokku ps:scale node-js-app web=1
```
Multiple process types can be scaled at once:
```shell
dokku ps:scale node-js-app web=1worker=1
```
Issuing the `ps:scale` command with no process type argument will output the current scaling settings for an application:
```shell
dokku ps:scale node-js-app
```
```
-----> Scaling for node-js-app
-----> proctype qty
-----> -------- ---
-----> web 1
-----> worker 1
```
### Stopping applications
Deployed applications can be stopped using the `ps:stop` command. This turns off all running containers for an application, and will result in a **502 Bad Gateway** response for the default nginx proxy implementation.
```shell
dokku ps:stop node-js-app
```
You may also stop all applications at once:
```shell
dokku ps:stopall
```
### Starting applications
All stopped containers can be started using the `ps:start` command. This is similar to running `ps:restart`, except no action will be taken if the application containers are running.
```shell
dokku ps:start node-js-app
```
### Starting all applications
In some cases, it may be necessary to start all applications from scratch - e.g. if all Docker containers have been manually stopped. This can be executed via the `ps:startall` command, which supports parallelism in the same manner `ps:rebuildall`, `ps:restartall`, and `ps:stopall` do.
Be aware that no action will be taken if the application containers are running.
```shell
dokku ps:startall
```
## Restart policies
> New as of 0.7.0
By default, Dokku will automatically restart containers that exit with a non-zero status up to 10 times via the [on-failure Docker restart policy](https://docs.docker.com/engine/reference/run/#restart-policies-restart).
### Showing the current restart policy
The `ps:restart-policy` command will show the currently configured restart policy for an application. The default policy is `on-failure:10`
```shell
dokku ps:restart-policy node-js-app
```
```
=====> node-js-app restart-policy:
on-failure:10
```
### Setting the restart policy
You can configure this via the `ps:set-restart-policy` command:
```shell
# always restart an exited container
dokku ps:set-restart-policy node-js-app always
```
```
-----> Setting restart policy: always
```
```shell
# never restart an exited container
dokku ps:set-restart-policy node-js-app no
```
```
-----> Setting restart policy: no
```
```shell
# only restart it on Docker restart if it was not manually stopped
Restart policies have no bearing on server reboot, and Dokku will always attempt to restart your applications at that point unless they were manually stopped.
## Manually managing process scaling
You can optionally *commit* a `DOKKU_SCALE` file to the root of your repository - *not* to the `/home/dokku/APP` directory. Dokku expects this file to contain one line for every process defined in your Procfile.
Example:
```Procfile
web=1
worker=2
```
If it is not committed to the repository, the `DOKKU_SCALE` file will otherwise be automatically generated based on your `ps:scale` settings.
> *NOTE*: Dokku will always use the `DOKKU_SCALE` file that ships with the repo to override any local settings.
@@ -21,8 +21,75 @@ in order to avoid SSH interpretting Dokku arguments for itself.
--force force flag. currently used in apps:destroy and other ":destroy" commands
```
## Clients
## Official Client
You may optionally use a client to connect to your Dokku server. Most clients use the configured `git remote` to locate the Dokku server, though some allow for overriding this via an environment variable or flag.
You may optionally use the official client when connecting to the Dokku server.
Please refer to the [clients](/docs/community/clients.md) list for more details.
Of all methods, this is the *most* official method of interacting with your Dokku installation. It is a bash script that interacts with a remote Dokku installation via `ssh`. It is available in `contrib/dokku_client.sh` in the root of the Dokku repository.
It can be installed either via the [Homebrew](https://brew.sh) package manager (macOS only), or manually.
### Installation via Homebrew
To install, simply run the following command:
```shell
brew install dokku/repo/dokku
```
### Manual installation
To install manually, simply clone the Dokku repository down and add the `dokku` alias pointing at the script:
```shell
git clone git@github.com:dokku/dokku.git ~/.dokku
# optional: make sure that the dokku_client.sh version matches your Dokku version
cd ~/.dokku
git checkout <tag/branch>
# add the following to either your
# .bashrc, .bash_profile, or .profile file
aliasdokku='$HOME/.dokku/contrib/dokku_client.sh'
```
Alternatively, if using another shell such as **zsh**, create an alias command which invokes the script using **bash**:
```shell
# zsh: add the following to either .zshenv or .zshrc
# fish: add the following to ~/.config/fish/config.fish
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
# csh: add the following to .cshrc
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
```
### Usage
All commands have the application name automatically set via the `--app` flag on the remote server, and thus the app name does not need to be specified manually for core plugins.
The client supports several environment variables:
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overriden via `--remote` flag.
-`DOKKU_PORT` (default: `22`): Used to specify a port to connect to the Dokku server on.
It also supports several flags (all flags unspecified here are passed as is to the server):
-`--app`: Override the remote app in use.
-`--trace`: Enable trace mode.
-`--remote`: Override the remote server.
-`--global`: Unsets the "app" value. May not be supported for the specified command.
In addition, the following commands have special local side-effects:
-`apps:create`:
- If no local `--app` flag is specified or detected from a `dokku` git remote, a random name is generated and used for the app.
- The `dokku` git remote is set if not already set.
-`apps:destroy`:
- Removes the local `dokku` git remote if set.
## Unofficial Clients
Please refer to the [community clients](/docs/community/clients.md) list for more details.
`KEY_NAME` is the name you want to use to refer to this particular key. Including the word `admin` in the name will grant the user privileges to add additional keys remotely.
@@ -66,13 +88,20 @@ cat ~/.ssh/id_rsa.pub | make vagrant-acl-add
As key names are unique, they can be used to remove a public SSH key.
```SHELL
```shell
dokku ssh-keys:remove KEY_NAME
```
An SSH Key can also be removed by fingerprint.
```shell
dokku ssh-keys:remove --fingerprint FINGERPRINT
```
## Scoping commands to specific users
Keys are given unique names, which can be used in conjunction with the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization. Please see the documentation on that trigger for more information.
Support for scoping commands to specific users can be added through plugins that take advantage of the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization.
See also the list of [community-provided plugins](/docs/community/plugins.md).
checks:disable <app> [process-type(s)] Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
checks:enable <app> [process-type(s)] Enable zero-downtime deployment for all processes (or comma-separated process-type list)
checks:report [<app>] [<flag>] Displays a checks report for one or more apps
@@ -11,7 +10,7 @@ checks:run <app> [process-type(s)] Runs zero-downtime checks for all proce
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
```
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by for an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds *after* the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds *after* the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
You may both create user-defined checks for web processes using a `CHECKS` file, as well as customize any and all parts of this experience using the checks plugin.
While a full URL may be used in order to invoke checks, if you are using relative URLs, the port *must* be omitted.
> Changed as of 0.22.5
Please note that dollar sign bracket characters (`{` and `}`) must be escaped when used within a `CHECKS` file. Escaping follows golang template rules. The proper way to do this is via one of the following methods:
```
# escaping the `{` character
# using double-quotes
{{"{"}}
# using raw string constants
{{`{`}}
# escaping the `}` character
# using double-quotes
{{"}"}}
# using raw string constants
{{`}`}}
```
### Templating Checks Files
> New as of 0.22.5
An app's `CHECKS` file is sent through a single pass of the [`sigil`](https://github.com/gliderlabs/sigil/) templating tool. This enables usage of Golang templating within application `CHECKS` files. In addition to general templating access, access to app environment variables is also allowed via the `var` function:
```
{{ var "SOME_ENV_VAR" }}
```
This may be useful if certain zero-downtime checks require access to an app-specific value, such as a domain name.
### Check settings
The default behavior is to wait for `5` seconds before running the checks, to timeout the checks after `30` seconds, and to attempt the checks `5` times. If the checks fail `5` times, the deployment is considered failed and the old container will continue serving traffic.
@@ -186,19 +217,19 @@ dokku checks:run APP
-----> Running pre-flight checks
-----> Running checks for app (APP.web.1)
For more efficient zero downtime deployments, create a file CHECKS.
See http://dokku.viewdocs.io/dokku/checks-examples.md for examples
See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples
CHECKS file not found in container: Running simple container check...
-----> Waiting for 10 seconds ...
-----> Default container check successful!
-----> Running checks for app (APP.web.2)
For more efficient zero downtime deployments, create a file CHECKS.
See http://dokku.viewdocs.io/dokku/checks-examples.md for examples
See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples
CHECKS file not found in container: Running simple container check...
-----> Waiting for 10 seconds ...
-----> Default container check successful!
-----> Running checks for app (APP.worker.1)
For more efficient zero downtime deployments, create a file CHECKS.
See http://dokku.viewdocs.io/dokku/checks-examples.md for examples
See https://dokku.com/docs/deployment/zero-downtime-deploys/ for examples
CHECKS file not found in container: Running simple container check...
@@ -97,12 +97,12 @@ If a plugin depends on a specific command-line tool, check whether that tool exi
```shell
# `command -v` example
if ! command -v "nginx"&>/dev/null;then
log-fail "Missing nginx, install it"
dokku_log_fail "Missing nginx, install it"
fi
# `which` example
if ! which nginx >/dev/null 2>&1;then
log-fail "Missing nginx, install it"
dokku_log_fail "Missing nginx, install it"
fi
```
@@ -210,7 +210,7 @@ Files are copied from the `/app` directory - for images built via buildpacks - o
Plugins should **not** call the `dokku` binary directly from within plugins because clients using the `--app` argument are potentially broken when doing so.
Plugins should instead source the `functions` file for a given plugin when attempting to call Dokku internal functions.
Plugins should instead source the `functions` file for a given plugin when attempting to call Dokku internal functions. In cases where plugin functions cannot be sourced (eg if a plugin is implemented in Golang), then call the relevant [plugin triggers](/docs/development/plugin-triggers.md) instead.
@@ -29,6 +29,66 @@ The following plugin triggers describe those available to a Dokku installation.
> The example plugin trigger code is not guaranteed to be implemented as in within dokku, and are merely simplified examples. Please look at the Dokku source for larger, more in-depth examples.
### `app-create`
- Description: Creates an app
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-destroy`
- Description: Destroys an app (with confirmation if force isn't specified)
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-exists`
- Description: Creates an app
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-maybe-create`
- Description: Creates an app (gated by whether this is globally enabled or not)
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-restart`
- Description: Triggers an app restart
@@ -83,6 +143,24 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `builder-detect`
- Description: Allows overriding the auto-detected `herokuish` builder in favor of a custom one. Dockerfile gets lowest builder precedence.
- Description: Allows modification of the configured dokku-image
@@ -201,6 +279,51 @@ help_content
esac
```
### `config-export`
- Description: Returns the environment variables in a specified format
- Invoked by: app-json plugin
- Arguments: `$APP $GLOBAL $MERGED $FORMAT`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `config-get`
- Description: Fetches the app config value for a key
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `config-get-global`
- Description: Fetches the global config value for a key
- Invoked by:
- Arguments: `$KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `core-post-deploy`
> To avoid issues with community plugins, this plugin trigger should be used *only* for core plugins. Please avoid using this trigger in your own plugins.
@@ -219,6 +342,40 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
curl "http://httpstat.us/200"
```
### `cron-write`
- Description: Force triggers writing out cron entries
- Description: Allows injecting cron entries into the written out scheduled cron task list. Each entry is newline delimited, and individual entries come in the form `$SCHEDULE;$FULL_COMMAND;$ARBITRARY_DATA`. Individual implementations of cron writing can decide whether and how to include these cron entries. The `ARBITRARY_DATA` includes the log file path for the basic `docker-local` cron implementation.
The default template is viewable here: [plugins/nginx-vhosts/templates/dokku.conf.sigil](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/dokku.conf.sigil)
### `nginx-hostname`
- Description: Allows you to customize the hostname for a given app
@@ -741,6 +1062,22 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-app-rename-setup`
- Description: Allows you to run commands after an app is setup, and before it is rebuild. This is useful for cleaning up tasks, or ensuring configuration from an old app is copied to the new app
- Invoked by: `dokku apps:rename`
- Arguments: `$OLD_APP_NAME $NEW_APP_NAME`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `post-build-buildpack`
- Description: Allows you to run commands after the build image is create for a given app. Only applies to apps using buildpacks.
@@ -756,6 +1093,24 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-build-pack`
> Warning: The pack plugin trigger apis are under development and may change
> between minor releases until the 1.0 release.
- Description: Allows you to run commands after the build image is create for a given app. Only applies to apps using pack.
- Invoked by: `internal function dokku_build() (build phase)`
- Arguments: `$APP``$SOURCECODE_WORK_DIR`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `post-build-dockerfile`
- Description: Allows you to run commands after the build image is create for a given app. Only applies to apps using a dockerfile.
@@ -783,7 +1138,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
@@ -820,6 +1175,20 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-container-create`
- Description: This trigger should be used to do stuff to containers after they are created but before they are started. They are explicitely for commands that may involve network traffic, and _not_ for commands that are self-contained, such as chown or tar.
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using buildpacks.
- Invoked by: `internal function dokku_release() (release phase)`
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using a dockerfile.
- Invoked by: `internal function dokku_release() (release phase)`
- Description: Can be used to run commands after an app is manually stopped
- Invoked by: `dokku ps:stop` and `dokku ps:stopall`
- Invoked by: `dokku ps:stop`
- Arguments: `$APP`
- Example:
@@ -1017,6 +1400,24 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `pre-build-pack`
> Warning: The pack plugin trigger apis are under development and may change
> between minor releases until the 1.0 release.
- Description: Allows you to run commands before the build image is created for a given app. For instance, this can be useful to add env vars to your container. Only applies to apps using pack.
- Invoked by: `internal function dokku_build() (build phase)`
- Arguments: `$APP``$SOURCECODE_WORK_DIR`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `pre-build-dockerfile`
- Description: Allows you to run commands before the build image is created for a given app. For instance, this can be useful to add env vars to your container. Only applies to apps using a dockerfile.
@@ -1047,7 +1448,6 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
- Description: Allows you to run commands before environment variables are set for the release step of the deploy. Only applies to apps using a dockerfile.
@@ -9,11 +9,11 @@ We maintain the Dokku test harness within the `tests` directory:
## Continuous Integration
All pull requests have tests run against them on [CircleCI](https://circleci.com/), a continuous integration platform that provides Docker support for Ubuntu Trusty 14.04.
All pull requests have tests run against them on [CircleCI](https://circleci.com/), a continuous integration platform that provides Docker support for Ubuntu Trusty 16.04.
If you wish to skip tests for a particular commit, e.g. documentation changes, you may add the `[ci skip]` designator to your commit message. Commits that _should_ be tested but have the above designator will not be merged.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Trusty 14.04, we only provide official installation support for that platform.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Trusty 16.04, we only provide official installation support for that platform and the latest LTS release of Ubuntu (currently 18.04).
Some special characters are translated in the test listing, specifically the characters `( ) :`, while others are not. The fuzzy matching happens on test names as listed by this script, so executing a test with a more specific name will work as expected.
[DigitalOcean](https://www.digitalocean.com/products/compute/) offers a pre-installed Dokku image. You can run this image on any sized Droplet, although larger Droplets will allow you to run larger applications.
[DigitalOcean](https://marketplace.digitalocean.com/apps/dokku?refcode=fe06b043a083) offers a pre-installed Dokku image. You can run this image on any sized Droplet, although larger Droplets will allow you to run larger applications.
> **Please disable IPv6**. There are known issues with IPv6 on DigitalOcean and Docker. If you would like to run Dokku on an IPv6 DigitalOcean Droplet, please consult [this guide](https://jeffloughridge.wordpress.com/2015/01/17/native-ipv6-functionality-in-docker/).
1. Login to your [DigitalOcean](https://m.do.co/c/fe06b043a083) account.
2. Click **Create a Droplet**.
3. Under **Choose an image > One-click apps**, choose the latest **Dokku** release for 16.04 _(version numbers may vary)_.
3. Under **Choose an image > Marketplace**, search latest **Dokku** release for Ubuntu 20.04 _(version numbers may vary)_.
4. Under **Choose a size**, select your machine spec.
5. Under **Choose a datacenter region**, select your region.
- The global hostname is set to `dokku.me` on boot.
- The container name is dokku.
@@ -29,8 +29,13 @@ Dokku is run with the following options:
- Container HTTPS port 443 is exposed on the host as 8443.
- Data within the container is stored on the host within the `/var/lib/dokku` directory.
- The docker socket is mounted into container
- The "web installer" is not supported.
Application repositories, plugin config, and plugin data is persisted to disk within the specified host directory for `/var/lib/dokku`.
Application repositories, plugin config, as well as plugin data are persisted to disk within the specified host directory for `/var/lib/dokku`.
Other docker container options can also be used when running Dokku, though the specific outcome will depend upon the specified options. For example, the Dokku container's nginx port can be bound to a specific host ip by specifying `--publish $HOST_IP:8080:80`, where `$HOST_IP` is the IP desired. Please see the [docker container run documentation](https://docs.docker.com/engine/reference/commandline/run/) for further explanation for various docker arguments.
## Plugin Installation
To install custom plugins, create a `plugin-list` file in the host's `/var/lib/dokku` directory. The plugins listed herein will be automatically installed by Dokku on container boot. This file should be the following format:
To initialize ssh-keys within the container, use `docker exec` to enter the container and run the appropriate ssh-keys commands.
```shell
@@ -52,3 +59,15 @@ docker exec -it dokku bash
```
Please see the [user management documentation](/docs/deployment/user-management.md) for more information.
## Pushing Applications
When exposing the Dokku container's SSH port (22) on 3022, something similar to the following will need to be setup within the user's `~/.ssh/config`:
```
Host dokku.docker
HostName 127.0.0.1
Port 3022
```
In the above example, the hostname `127.0.0.1` is being aliased to `dokku.docker`, while the port is being overriden to `3022`. All SSH commands - including git pushes - for the hostname `dokku.docker` will be transparently sent to `127.0.0.1:3022`.
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.