# History
## 0.21.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.4/bootstrap.sh
sudo DOKKU_TAG=v0.21.4 bash bootstrap.sh
```
### Bug Fixes
- #4092: @Yihao-G Fix nginx proxy-read-timeout not set for HTTPS
- #4095: @GennadySpb Fix application removal during uninstallation
### New Features
- #4097: @josegonzalez Update herokuish
### Documentation
- #4096: @josegonzalez Clarify that special config variables are not exposed to applications
- #4007: @turicas Clarify nginx.conf.sigil path in image when deploying non-buildpack apps
- #4078: @gurpreetatwal Add more details to `nginx-dokku-template-source` trigger
- #4090: @ankane Official plugins no longer in beta
- #4085: @josegonzalez Set warning on resource type as an actual warning
### Other
- #4082: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.4 to 1.25.5 in /tests/apps/php
# History
## 0.21.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.3/bootstrap.sh
sudo DOKKU_TAG=v0.21.3 bash bootstrap.sh
```
### Bug Fixes
- #4077: @Schlepptop Fix config_all bug introduced in 0.21.2
- #4074: @josegonzalez Force set all plugin permissions on plugin:install/update
### Documentation
- #4073: @josegonzalez Document the official shell client
# History
## 0.21.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.2/bootstrap.sh
sudo DOKKU_TAG=v0.21.2 bash bootstrap.sh
```
### Bug Fixes
- #4072: @Schlepptop Fix deprecation warning in config_all
### New Features
- #4061: @josegonzalez Drop go sum and mod files from releases
### Refactors
- #4064: @hugopeixoto Use *_PATH consistently
### Documentation
- #4069: @josegonzalez Scheduler plugins are no longer beta
- #4068: @josegonzalez Official plugins are no longer in beta
- #4066: @ltalirz Add ansible as installation route
- #4063: @josegonzalez Clarify why we stop/rebuild apps during upgrade
- #4040: @fonsp Added link to the buildpack plugin docs
- #4062: @hugopeixoto Rewrite upgrade instructions
GLOBAL_VHOST_PATH and GLOBAL_VHOST_FILE were used to represent the same
thing. Same for APP_URLS_PATH and APP_VHOST_PATH.
This normalizes all of those to _PATH.
# History
## 0.21.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.21.0/bootstrap.sh
sudo DOKKU_TAG=v0.21.0 bash bootstrap.sh
```
### Bug Fixes
- #4058: @hugopeixoto Ensure web installer creates files with correct permissions
- #4055: @hugopeixoto Delete dokkurc recursively during uninstall
- #4057: @hugopeixoto Install sudo when installing from source
- #4045: @josegonzalez Filter gpus instead of nvidia-gpus from resource arguments
- #4029: @josegonzalez Filter args _after_ docker-args-process-deploy
- #4026: @josegonzalez Filter resource args from deploy tasks
- #4022: @josegonzalez Do not allow slashes in app names
- #4020: @josegonzalez Properly handle multiple containers in ps:inspect
- #3989: @josegonzalez Correct entering running containers
- #3977: @josegonzalez Set default port for all run commands
- #3969: @josegonzalez Do not logrotate all services files
- #3964: @josegonzalez Remove all --force-yes usage throughout the codebase
- #3955: @benwh Fix missing 502 error page
- #3953: @josegonzalez Use correct function name for cmd-tar-in and update migration guide
### New Features
- #4041: @rvanlaar feat: Add download option to the certs plugin
- #4043: @josegonzalez Allow controlling nginx proxy-read-timeout
- #4038: @josegonzalez Create proxy:build-config command
- #4021: @josegonzalez Depend on python3 binary for CentOS 8 support
- #4004: @josegonzalez Add support for moby-engine
- #3967: @josegonzalez Add Ubuntu 20.04 support
- #3988: @josegonzalez Upgrade plugn to 0.5.0
- #3987: @josegonzalez Upgrade sigil to 0.6.0
- #3986: @josegonzalez Upgrade sshcommand to 0.11.0
- #3985: @josegonzalez Upgrade go-procfile-util to 0.8.2
- #3982: @josegonzalez Allow apps named tls
- #3979: @josegonzalez Upgrade herokuish
- #3971: @josegonzalez feat: allow users to customize the source of the dokku.conf nginx template
- #3966: @josegonzalez Move domain manipulation into triggers
- #3965: @josegonzalez Drop dokku references in logging output
- #3954: @josegonzalez feat: upgrade herokuish to 0.5.12
- #3940: @josegonzalez Expose last updated time in git:report
- #3939: @josegonzalez Add support for outputting the last visited time
### Refactors
- #4035: @josegonzalez Switch to go mod
- #4008: @josegonzalez Standardize golang command code
### Documentation
- #4056: @swrobel Remove invalid help entry for dokku ps commmand
- #4039: @josegonzalez Break out bc-break and refactors in changelog
- #4025: @alexjj Switch AUR helper to yay
- #4019: @tdak Added one possible solution to an error
- #4014: @rvanlaar Update dreamhost cloudinit script
- #4003: @josegonzalez Add dokku.ai asset
- #3999: @DavidLemayian Update URL for less than 1gb memory in bootstrap.sh [ci skip]
- #3998: @josegonzalez Document the #dokku channel on slack
- #3996: @josegonzalez Clarify network aliases and add section on tld management
- #3980: @josegonzalez Clarify that the web installer is not supported in docker-based installs
- #3970: @josegonzalez Clarify the 'see the docs' internal links
- #3968: @josegonzalez Document access.conf issue
- #3957: @swrobel Add official registry plugin
- #3942: @scowalt Fix grammar in environment variables documentation
### Tests
- #4046: @rvanlaar Make `make test` pass on linting
- #4037: @josegonzalez Try to output oomkill information
- #4036: @josegonzalez Store the deb and rpm artifacts
- #4034: @josegonzalez Teardown apps and containers in global teardown
- #4031: @josegonzalez Delete old apps and ensure the test helper is quieter
- #4030: @josegonzalez Update circleci workflow
- #3947: @jayjun Scope init tests to container processes only
### Other
- #4051: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 177 to 178 in /tests/apps/php
- #4028: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 176 to 177 in /tests/apps/php
- #4016: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.29.v20200521 to 9.4.30.v20200611 in /tests/apps/java
- #4006: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 174 to 176 in /tests/apps/php
- #4001: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.28.v20200408 to 9.4.29.v20200521 in /tests/apps/java
- #4002: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.3 to 1.25.4 in /tests/apps/php
- #3993: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.1 to 1.4.2 in /tests/apps/gogrpc
- #3962: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.4.0 to 1.4.1 in /tests/apps/gogrpc
- #3959: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 173 to 174 in /tests/apps/php
- #3950: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.29.0 to 1.29.1 in /tests/apps/gogrpc
- #3946: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.1 to 1.29.0 in /tests/apps/gogrpc
The 'server.key' and 'server.crt' can printed to stdin.
The two options are:
`dokku certs:show <app> key > server.key`
`dokku certs:show <app> crt > server.crt`
This will create two files, `server.key` and `server.crt`.
Those files contain the private key and the certificate.
Includes tests.
This hopefully makes it a little easier to work with as the tooling is now based on something in golang core.
- move columnize usage to common plugin
- remove old vendor files
There is likely a better regex for the actually allowed names, but this will suffice for ensuring folks don't do weird things with their folder structures...
Closes#4013
Bring configuration in line with the latest Cloud init verison. Tested under 20.1.
Mainly done due to `debconf_selections` not working with the old syntac.
See the `debconf_selections` item under https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure
Changes include:
- reboot when apt deems it necessary,
- define update and upgrade with the package syntax,
- bring apt sources and keys inline with apt syntax and
- dynamically get the right release by using the var '$RELEASE'.
[ci skip]
This cloudinit script had become outdated.
Changed 4 things:
- docker repository had moved
- use current docker gpg key
- use current dokku gpg key
- move over to ubuntu focal LTS 20.20
This functionality was broken due to a refactor of argument handling in a previous release.
In addition to the fix, all the functionality was moved to scheduler-enter, which allows scheduler plugins to implement ways of entering containers in the relevant scheduler.
Closes#3972
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
These are usually not optional and actually explain what a user is interested in. As we don't have documentation partials, duplication isn't in favor of the project maintainer's benefit.
Closes#3927
In dokku/dokku#3602 a new error page for the 502 status code was
introduced.
However, this error page is not currently being used, and results in a
404 error being served instead, because nginx is trying to load a
non-existent file:
```
open() "/var/lib/dokku/data/nginx-vhosts/dokku-errors/502-error.html" failed (2: No such file or directory)
```
Fix this by copying the `502-error.html` file into the `dokku-errors`
directory upon installation.
# History
## 0.20.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.4/bootstrap.sh
sudo DOKKU_TAG=v0.20.4 bash bootstrap.sh
```
### New Features
- #3936: @josegonzalez Enable limiting and reserving gpu resources
### Documentation
- #3937: @josegonzalez Add minor documentation for the kubernetes and nomad schedulers
### Other
- #3935: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.11.1 to 2.11.2 in /tests/apps/python-flask
- #3934: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.5 to 1.4.0 in /tests/apps/gogrpc
- #3933: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.27.v20200227 to 9.4.28.v20200408 in /tests/apps/java
# History
## 0.20.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.3/bootstrap.sh
sudo DOKKU_TAG=v0.20.3 bash bootstrap.sh
```
### New Features
- #3926: @josegonzalez Add proper support for various buildpack urls
### Other
- #3928: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.28.0 to 1.28.1 in /tests/apps/gogrpc
- #3925: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/python-flask
- #3924: @dependabot-preview[bot] chore(deps): bump flask from 1.1.1 to 1.1.2 in /tests/apps/multi
# History
## 0.20.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.2/bootstrap.sh
sudo DOKKU_TAG=v0.20.2 bash bootstrap.sh
```
### Bug Fixes
- #3921: @josegonzalez Correct container_type handling when entering containers
- #3919: @josegonzalez Fix bug with restarting containers not being routed to because of changing IP addresses
### New Features
- #3920: @josegonzalez Add the ability to list ssh keys for a specific user
# History
## 0.20.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.1/bootstrap.sh
sudo DOKKU_TAG=v0.20.1 bash bootstrap.sh
```
### Bug Fixes
- #3916: @josegonzalez Change error exit to warning when no apps exist
### New Features
- #3918: @josegonzalez Upgrade herokuish to 0.5.11
- #3915: @josegonzalez Add ability to check if a plugin has been installed
- #3914: @josegonzalez Add ability to change or disable the access/error log path
- #3913: @josegonzalez Upgrade herokuish
### Documentation
- #3907: @josegonzalez Add sponsoring link to issue template
- #3904: @jazzzz Update dokku-apt entry
- #3902: @josegonzalez Remove extra commas from network docs
### Other
- #3909: @dependabot-preview[bot] chore(deps): bump werkzeug from 1.0.0 to 1.0.1 in /tests/apps/python-flask
- #3903: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 172 to 173 in /tests/apps/php
# History
## 0.20.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.20.0/bootstrap.sh
sudo DOKKU_TAG=v0.20.0 bash bootstrap.sh
```
### Bug Fixes
- #3891: @josegonzalez Add missing cpio dependency
- #3861: @josegonzalez Fix app clone and rename calls
- #3682: @josegonzalez Force tty check to run with the default language
- #3853: @josegonzalez Add missing hooks to events plugin
### New Features
- #3899: @josegonzalez Drop unnecessary quotes on docker inspect calls
- #3895: @josegonzalez Expose network listeners to nginx templates for all process types
- #3893: @josegonzalez Rewrite apps plugin in golang
- #3889: @josegonzalez Update herokuish
- #3879: @josegonzalez Drop support for unsupported Debian and Ubuntu releases …
- #3880: @josegonzalez Remove unnecessary source/import statements
- #3871: @josegonzalez Rewrite proxy plugin in golang
- #3869: @josegonzalez Standardize plugin trigger calls
- #3870: @josegonzalez Use Println in favor of Fprintln for os.Stdout
- #3868: @josegonzalez Remove ps command
- #3866: @josegonzalez Unify nginx config commands
- #3865: @josegonzalez Cleanup injected docker labels
- #3860: @josegonzalez Remove deprecated egrep calls from codebase
- #3854: @josegonzalez Remove deprecated code
- #3852: @josegonzalez Standardize plugin code
- #3850: @josegonzalez DRY up reports in golang
- #3851: @josegonzalez Update herokuish to 0.5.6
- #3847: @josegonzalez Custom docker networking
- #3848: @josegonzalez Minor logging changes
- #3843: @josegonzalez Enable HSTS by default
- #3844: @josegonzalez Add global fallback for DOKKU_PROXY_PORT and DOKKU_PROXY_SSL_PORT
- #3609: @jayjun Start long running containers with --init with tests
- #3842: @josegonzalez rework docker-args-process trigger arguments
- #3841: @josegonzalez Implement docker-options:clear
### Documentation
- #3901: @Cellane 📝 Update information about Dokku CLI installation
- #3892: @josegonzalez Move code of conduct to .github org repository
- #3888: @decentral1se Mark 9+ for Debian version
- #3874: @josegonzalez Push users to upgrade to recent versions
- #3864: @alex-galey Change docs copyright to 2020
- #3863: @josegonzalez Update issue template to remove ambiguity around reporting
- #3849: @josegonzalez Reference correct property in network docs example
- #3840: @ollej Add link to fonts plugin
- #3838: @ltalirz Expand docs surrounding access control
### Other
- #3897: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.4 to 1.3.5 in /tests/apps/gogrpc
- #3896: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 3.1.1 to 3.1.2 in /tests/apps/java
- #3894: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.1 to 1.28.0 in /tests/apps/gogrpc
- #3885: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 171 to 172 in /tests/apps/php
- #3884: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.26.v20200117 to 9.4.27.v20200227 in /tests/apps/java
- #3877: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.3 to 1.3.4 in /tests/apps/gogrpc
- #3858: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 170 to 171 in /tests/apps/php
- #3855: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 169 to 170 in /tests/apps/php
- #3846: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.1 to 1.0.0 in /tests/apps/python-flask
- #3845: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.27.0 to 1.27.1 in /tests/apps/gogrpc
- #3833: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.26.0 to 1.27.0 in /tests/apps/gogrpc
- #3837: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.3 to 2.11.1 in /tests/apps/python-flask
- #3836: @dependabot-preview[bot] chore(deps): bump github.com/golang/protobuf from 1.3.2 to 1.3.3 in /tests/apps/gogrpc
- #3829: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.16.0 to 0.16.1 in /tests/apps/python-flask
- #3830: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 166 to 169 in /tests/apps/php
This change allows users to specify a custom nginx.conf.sigil that can expose non-web process types to the outside world in addition to the web process type.
Closes#3258
A git push requires that the first four bytes should be the line length, so not suppressing the output results in a partially failed deploy.
https://stackoverflow.com/a/8175315/1515875
While the latest packages may continue to work on other releases, we will no longer officially support these releases, nor will we distribute packages.
Supporting versions more than a year old is difficult with a quick-moving project, and not worth the time that could be better spent fixing existing bugs/adding new functionality for an OSS project.
This change removes all deprecated commands. In many cases, users have been warned for a number of releases before the commands have been removed. All commands that were removed have existing alternatives.
This standardization makes it somewhat easier to read stacktraces as the command names are all uniform, so it will be slightly easier to scan trace output.
This unifies all the report-handling code so that plugins only need to worry about the data they wish to represent, and not the logic of actually returning it.
Containers can be attached:
- after they are created, but before they are started
- after a successful deploy, but before the proxy reloads
This allows folks to have flexibility around when they would like a container to be made available to a network.
This enables the HSTS header by default when an SSL certificate is in use. HSTS options can also be managed via the nginx:set command, which also exposes the ability to disable HSTS for your application.
The IMAGE_TAG is not always available, while the IMAGE_SOURCE_TYPE is. Since the point of these triggers was to unify the argument passed and make it easier to interact with them, this version makes more sense.
Closes#3780
The deployment documentation on scoping user access pointed only to the
development documentation for implementing plugins to handle user
scoping.
Added link to the dokku-acl plugin, which already handles user scoping
out of the box.
# History
## 0.19.12
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.12/bootstrap.sh
sudo DOKKU_TAG=v0.19.12 bash bootstrap.sh
```
### New Features
- #3819: @josegonzalez Allow binding nginx to specific IPv4/IPv6 interfaces
- #3818: @josegonzalez Add support for host-mode networking
### Documentation
- #3814: @treyssatvincent Use dokku:report to for listing domains
- #3809: @josegonzalez Document nginx:show-conf
- #3650: @vincelwt Clarify resource management for docker-local scheduler
- #3806: @kimar Make default vhost example listen to ipv6
### Other
- #3816: @dependabot-preview[bot] chore(deps): bump handlebars from 4.6.0 to 4.7.1 in /tests/apps/.websocket.disabled
- #3815: @dependabot-preview[bot] chore(deps): bump handlebars from 4.5.3 to 4.6.0 in /tests/apps/.websocket.disabled
- #3811: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 165 to 166 in /tests/apps/php
- #3812: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.24.v20191120 to 9.4.25.v20191220 in /tests/apps/java
- #3810: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.2 to 1.25.3 in /tests/apps/php
- #3808: @dependabot-preview[bot] chore(deps): [security] bump rack from 1.6.11 to 1.6.12 in /tests/apps/ruby
- #3807: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.1 to 1.26.0 in /tests/apps/gogrpc
- #3804: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 164 to 165 in /tests/apps/php
In host-mode, there is no 'bridge' network by default, so we return an invalid IP address of 'no value'. Instead, return '127.0.0.1' for those containers.
As there can be custom schedulers, including scheduler-specific information on the resource management page can be a disingenuous - the values don't map to kubernetes, for example - and thus we should call out to the scheduler docs (and underlying docker docs) to make the mapping more clear.
# History
## 0.19.10
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.10/bootstrap.sh
sudo DOKKU_TAG=v0.19.10 bash bootstrap.sh
```
### Bug Fixes
- #3784: @josegonzalez Ensure checks attempts are tracked per-check instead of globally
### New Features
- #3793: @josegonzalez Omit DWARF symbol table and debug information from go binaries
- #3792: @josegonzalez Unify property function implementations
### Documentation
- #3712: @fruitl00p Added new plugin
### Other
- #3790: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/python-flask
- #3791: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.3 to 20.0.4 in /tests/apps/multi
- #3787: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/multi
- #3788: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.2 to 20.0.3 in /tests/apps/python-flask
- #3785: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/python-flask
- #3786: @dependabot-preview[bot] chore(deps): bump gunicorn from 20.0.0 to 20.0.2 in /tests/apps/multi
- #3748: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-dokku-scale
- #3749: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noappjson
- #3747: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/config
- #3746: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile
- #3741: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express
- #3783: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.23.v20191118 to 9.4.24.v20191120 in /tests/apps/java
- #3777: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 3.4.32 to 3.4.35 in /tests/apps/php
- #3774: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/python-flask
- #3779: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.25.1 to 1.25.2 in /tests/apps/php
- #3782: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.22.v20191022 to 9.4.23.v20191118 in /tests/apps/java
This will reduce the size of binaries in exchange for worse debugging output. This is acceptable for our users and worth it to save money on packagecloud package hosting - which is currently free under a given repository size.
Rather than reimplementing the property functions in two different languages - and potentially having compatibility issues - standardize on golang for the implementation through the use of a generated binary.
This also implements all the list functions for use with shell-based plugins.
Note that the interface to the prop binary is experimental, and it should not be used directly.
# History
## 0.19.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.9/bootstrap.sh
sudo DOKKU_TAG=v0.19.9 bash bootstrap.sh
```
### Bug Fixes
- #3781: @michaelshobbs Respect DOKKU_APP_USER in is_image_herokuish_based
### Other
- #3773: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.25.0 to 1.25.1 in /tests/apps/gogrpc
- #3772: @dependabot-preview[bot] chore(deps): bump gunicorn from 19.9.0 to 20.0.0 in /tests/apps/multi
- #3778: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 3.4.32 to 3.4.35 in /tests/apps/php
- #3768: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.24.0 to 1.25.0 in /tests/apps/gogrpc
# History
## 0.19.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.7/bootstrap.sh
sudo DOKKU_TAG=v0.19.7 bash bootstrap.sh
```
### Documentation
- #3765: @znz Fix typo in desc of is_tls13_available
### Other
- #3739: @safeforge dokku run do not supports interactive mode.
- #3762: @dependabot-preview[bot] chore(deps): bump handlebars from 4.4.5 to 4.5.1 in /tests/apps/.websocket.disabled
# History
## 0.19.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.6/bootstrap.sh
sudo DOKKU_TAG=v0.19.6 bash bootstrap.sh
```
### Other
- #3761: @pithyless Fix type-errors in dokku-installer.py
- #3759: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 163 to 164 in /tests/apps/php
- #3758: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 9.4.21.v20190926 to 9.4.22.v20191022 in /tests/apps/java
# History
## 0.19.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.19.3/bootstrap.sh
sudo DOKKU_TAG=v0.19.3 bash bootstrap.sh
```
### Bug Fixes
- #3753: @josegonzalez Always use python3 for the installer
### Other
- #3743: @dependabot-preview[bot] chore(deps): [security] bump express from 3.1.2 to 4.17.1 in /tests/apps/.websocket.disabled
- #3744: @dependabot-preview[bot] chore(deps): [security] bump handlebars from 1.0.12 to 4.4.5 in /tests/apps/.websocket.disabled
- #3750: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/dockerfile-procfile-bad
- #3745: @dependabot-preview[bot] chore(deps): [security] bump express from 3.3.8 to 4.17.1 in /tests/apps/gitsubmodules
- #3742: @dependabot-preview[bot] chore(deps): [security] bump express from 2.5.11 to 4.17.1 in /tests/apps/nodejs-express-noprocfile
- #3729: @dependabot-preview[bot] chore(deps): bump monolog/monolog from 1.12.0 to 1.25.1 in /tests/apps/php
- #3732: @dependabot-preview[bot] chore(deps): bump silex/silex from 1.2.3 to 2.2.4 in /tests/apps/php
- #3728: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 7.6.0.v20120127 to 9.4.21.v20190926 in /tests/apps/java
- #3730: @dependabot-preview[bot] chore(deps): bump werkzeug from 0.15.6 to 0.16.0 in /tests/apps/python-flask
- #3737: @dependabot-preview[bot] chore(deps): bump express3-handlebars from 0.2.3 to 0.5.2 in /tests/apps/.websocket.disabled
- #3734: @dependabot-preview[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 59 to 163 in /tests/apps/php
- #3735: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-kernel from 2.6.4 to 2.8.51 in /tests/apps/php
- #3723: @dependabot-preview[bot] chore(deps): bump sass-globbing from 1.1.1 to 1.1.5 in /tests/apps/multi
- #3731: @dependabot-preview[bot] chore(deps): bump jinja2 from 2.10.1 to 2.10.3 in /tests/apps/python-flask
- #3736: @dependabot-preview[bot] chore(deps): bump socket.io from 0.9.19 to 2.3.0 in /tests/apps/.websocket.disabled
- #3726: @dependabot-preview[bot] chore(deps): bump google.golang.org/grpc from 1.23.0 to 1.24.0 in /tests/apps/gogrpc
- #3727: @dependabot-preview[bot] chore(deps): bump maven-dependency-plugin from 2.4 to 3.1.1 in /tests/apps/java
- #3733: @dependabot-preview[bot] chore(deps): [security] bump symfony/http-foundation from 2.6.4 to 2.8.50 in /tests/apps/php
- #3720: @dependabot-preview[bot] chore(deps): bump compass from 1.0.1 to 1.0.3 in /tests/apps/multi
- #3721: @dependabot-preview[bot] chore(deps): bump sinatra from 1.4.4 to 1.4.8 in /tests/apps/ruby
- #3719: @dependabot-preview[bot] chore(deps): bump thin from 1.6.1 to 1.7.2 in /tests/apps/ruby
This actually breaks compatability since now we drop python2 support completely, but it's worth it to fix the weird issues with trying to support both versions.
Closes#3740Closes#3752
Refs #3717
Ideally python usage goes away - the dokku-installer should become a mandatory cli command, and the plugin is rewritten in golang - but for now, we need to use the correct binary when running dokku.
Closes#3714
This adds the Nginx Trust Proxy plugin
This plugin allows dokku to be run behind (multiple) proxies in and gives developers the opportunity to support reverse proxy layers
After a `dokku run` container is created and started, this plugin trigger will allow developers to run auxiliary commands in response to that container.
This feature is allows users to add extra label metadata to one-off containers. As this can interfere with Dokku internals if they shadow labels used by plugins, care should be taken to avoid the `com.dokku` or `org.label-schema` namespace.
Also proper name run containers so they don't get random names from docker...
This change allows supporting the openresty package as installed on Ubuntu 18.04 from the official openresty package repository, while also returning general nginx support.
Closes#3675
It may be desirable to keep the contents of the git directory for the build process. Certain build tools can extract extra information from the .git directory, and some workflows may require that the shipped artifact has the entire source code available locally for later usage.
This change refactors the compiled golang plugins into 3 distinct binaries:
- commands: already existing
- subcommands/subcommands: entrypoint into all subcommands
- triggers: entrypoint into all triggers
It then further symlinks triggers and subcommands to the built binaries. This results in both a much faster build process as well as smaller package size.
This PR uses the new syntax for commands introduced in Docker 1.13, making it a bit easier to understand just what a particular command is trying to do.
This also pushes the long-form syntax for docker command flags, which are also easier to understand at a glance.
> If you're using Dokku - especially for commercial purposes - consider donating to project development via [OpenCollective](https://opencollective.com/dokku) or [Patreon](https://www.patreon.com/dokku). Funds go to general development, support, and infrastructure costs.
>
> If you'd like to sponsor specific functionality, see the project's [Sponsoring](https://github.com/dokku/.github/blob/master/SPONSORING.md) document.
>
> If you need help figuring out how to use a specific buildpack, or are having issues using multiple buildpacks, please see our [irc or slack channels](http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/#the-irc-and-slack-channels). Issues pertaining to buildpacks may be closed and locked.
>
> If you need support for a version of Dokku that is more than a year old, your issue may be closed without an answer. Please upgrade to a recent version.
## Description of problem
@@ -16,6 +20,8 @@
#### Expected Results
<-- Please replace APP_NAME with the name of your app -->
## Environment Information
### `dokku report APP_NAME` output
@@ -23,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 inspect APP_NAME`
echo"For dokku to build containers, it is strongly suggested that you have 1024 megabytes or more of free memory"
echo"If necessary, please consult this document to setup swap: http://dokku.viewdocs.io/dokku/advanced-installation/#vms-with-less-than-1gb-of-memory"
echo"If necessary, please consult this document to setup swap: http://dokku.viewdocs.io/dokku/getting-started/advanced-installation/#vms-with-less-than-1-gb-of-memory"
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) limit on apps, but it's best practice to keep binary assets outside of git. Since containers are considered volatile in Dokku, external stores like s3 or storage mounts should be used for non-volatile items like user uploads. The Dokku storage core plugin can be used to mount local directories / volumes inside the docker container.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more details.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your application.
@@ -34,7 +34,7 @@ Each "phase" has different expectations and limitations:
Please keep the above in mind when utilizing deployment tasks.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation) docs for more information on building your own custom plugin.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation.md) docs for more information on building your own custom plugin.
@@ -147,4 +147,4 @@ By default, Dokku will execute your buildpack application processes as the `hero
> NOTE: this user must exist in your herokuish image.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [scheduler-docker-local documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
You can check if a plugin has been installed via the `plugin:installed` command:
```shell
dokku plugin:installed postgres
```
Installing a plugin is easy as well using the `plugin:install` command. This command will also trigger the `install` pluginhook on all existing plugins.
@@ -16,7 +16,7 @@ The resource plugin is meant to allow users to limit or reserve resources for a
By default, Dokku allows unlimited resource access to apps deployed on a server. In some cases, it may be desirable to limit this on a per-app or per-process-type basis. The `resource` plugin allows management of both resource "limits" and resource "reservations", where each resource request type has specific meaning to the scheduler in use for a given app.
> The meaning of a values and it's units are specific to the scheduler in use for a given app. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
> Warning: The meaning of a values and it's units are specific to the scheduler in use for a given app. If a value is incorrect for a scheduler, this may result in containers failing to start correctly. If a scheduler does not support a given resource type combination, it will be ignored. All resource commands require an app rebuild or deploy in order to take effect.
Valid resource options include:
@@ -26,6 +26,9 @@ Valid resource options include:
-`--network`
-`--network-ingress`
-`--network-egress`
-`--nvidia-gpu`
See the [Supported Resource Management Properties](/docs/advanced-usage/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
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 +105,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 +202,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.
## Changes
### App report flags
The following changes on the `apps:report` command were made in this release:
- The `--deploy-source` flag was renamed to `--app-deploy-source`.
- The `--locked` flag was renamed to `--app-locked`.
### Network report flags
The following changes on the `network:report` command were made in this release:
- The `--network-listeners` flag was renamed to `--network-web-listeners`.
### Plugin Triggers
- The `network-get-port` trigger was incorrectly documented to have the `isHerokuishContainer` argument as the third argument. The code has been fixed to respect the documentation.
- The `network-get-listeners` trigger now takes an additional `processType` argument. If not specified, it defaults to `web`. This default will be removed in an upcoming release.
## Deprecations
-`nginx:show-conf` has been deprecated in favor of `nginx:show-config`.
-`proxy#is_app_proxy_enabled()` is deprecated in favor of `plugn trigger proxy-is-enabled`.
-`proxy#get_app_proxy_type()` is deprecated in favor of `plugn trigger proxy-type`.
-`apps#apps_create()` is deprecated in favor of `plugn trigger app-create`.
-`apps#apps_destroy()` is deprecated in favor of `plugn trigger app-destroy`.
-`apps#apps_exists()` is deprecated in favor of `plugn trigger app-exists`.
-`apps#apps_maybe_create()` is deprecated in favor of `plugn trigger app-maybe-create`.
-`plugin trigger network-get-listeners` usage without a second `processType` argument is deprecated.
-`.NGINX_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_PORT`.
-`.NGINX_SSL_PORT` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.PROXY_SSL_PORT`.
-`.DOKKU_APP_LISTENERS` variable usage within `nginx.conf.sigil` templates is deprecated in favor of `.DOKKU_APP_WEB_LISTENERS`.
The `tls` name is no longer a reserved app name, and can be used by applications. This was previously a reserved app name due to it's use as a place for global SSL certificate files; Dokku has not supported global SSL certificates for many releases, and thus there is no need to reserve the name.
## Deprecations
-`git#git_deploy_branch()` is deprecated in favor of `plugn trigger git-deploy-branch`.
- The `config` command is deprecated in favor of `config:show`.
- Usage of this command in conjunction with either the `--export` or `--shell` flag is deprecated in favor of `config:export --format` with the correct format value (`exports` or `shell`, respectively).
- The `nginx:build-config` command is deprecated in favor of `proxy:build-config`.
## Removals
The `apps:destroy` command no longer takes a second argument `force`. Instead, this can be passed as the `--force` flag, either globally or as a flag to the command itself.
The `proxy:enable` and `proxy:disable` no longer restart apps when setting the `DOKKU_DISABLE_PROXY` environment variable. A future release will disable usage of `DOKKU_DISABLE_PROXY` altogether.
@@ -4,40 +4,9 @@ Given the constraints, running Dokku commands remotely via SSH is fine. For cert
While Dokku does not yet have an official client, there are a multitude of ways in which you can interact with your Dokku installation. The easiest is to use the **bash** client, though you may wish to use another.
## (bash, zsh, etc.) `dokku_client.sh`
## Official Client
Of all methods, this is the *most* official method of interacting with your Dokku installation. It is a bash script that interacts with a remote Dokku installation via ssh. It is available in `contrib/dokku_client.sh` in the root of the Dokku repository.
To install, simply clone the Dokku repository down and add the `dokku` alias pointing at the script:
```shell
git clone git@github.com:dokku/dokku.git ~/.dokku
# optional: make sure that the dokku_client.sh version matches your Dokku version
cd ~/.dokku
git checkout <tag/branch>
# add the following to either your
# .bashrc, .bash_profile, or .profile file
aliasdokku='$HOME/.dokku/contrib/dokku_client.sh'
```
Alternatively, if using another shell such as **zsh**, create an alias command which invokes the script using **bash**:
```shell
# zsh: add the following to either .zshenv or .zshrc
# fish: add the following to ~/.config/fish/config.fish
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
# csh: add the following to .cshrc
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
```
Configure the `DOKKU_HOST` environment variable or run `dokku` from a repository with a git remote named `dokku` pointed at your Dokku host in order to use the script as normal.
You can also configure a `DOKKU_PORT` environment variable if you are running ssh on a non-standard port. This defaults to `22`.
See the [remote commands documentation](/docs/deployment/remote-commands.md) for more information on how to install and use the official client.
## (nodejs) dokku-toolbelt
@@ -51,7 +20,7 @@ See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more
## (python) dokku-client
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
@@ -18,29 +18,30 @@ Let's take a quick look at the current Dokku nginx plugin that's shipped with Do
[See the full documentation](/docs/development/plugin-creation.md).
## Official Plugins (Beta)
## Official Plugins
The following plugins are available and provided by Dokku maintainers. Where noted, these plugins should be considered beta software and may not have been used as thoroughly as community plugins. Please file issues against their respective issue trackers.
The following plugins are available and provided by Dokku maintainers. Please file issues against their respective issue trackers.
<sup>1</sup> On Heroku similar functionality is offered by the [heroku-labs pipeline feature](https://devcenter.heroku.com/articles/labs-pipelines), which allows you to promote builds across multiple environments (staging -> production)
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>4</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>3</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
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.
@@ -90,6 +90,7 @@ The following list config variables have special meaning and can be set in a var
| `DOKKU_EVENTS_LOGFILE` | `$DOKKU_LOGS_DIR/events.log` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where the events log file is written to. |
| `DOKKU_APP_NAME` | none | `--app APP` flag | Name of application to work on. Respected by core plugins. |
| `DOKKU_APPS_FORCE_DELETE` | none | `--force` flag | Whether to force delete an application. Also used by other plugins for destructive actions. |
| `DOKKU_CHECKS_URL` | `http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Whether to detach a container started via `dokku run`. |
| `DOKKU_QUIET_OUTPUT` | none | `--quiet` flag | Silences certain header output for `dokku` commands. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> `--rm-container` flag <br /> `--rm` flag | Whether to keep `dokku run` containers around or not. |
@@ -115,13 +116,14 @@ The following list config variables have special meaning and can be set in a var
| `DOKKU_SKIP_CLEANUP` | | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | When a deploy is triggered, if this is set to a non-empty value, then old docker containers and images will not be removed. |
| `DOKKU_START_CMD` | none | `dokku config:set` | Command to run instead of `/start $PROC_TYPE` |
| `DOKKU_SYSTEM_GROUP` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System group to chown files as. |
| `DOKKU_SYSTEM_USER` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System user to chown files as. |
| `DOKKU_WAIT_TO_RETIRE` | `60` | `dokku config:set` | After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections. |
nginx:validate-config [<app>] [--clean] # Validates and optionally cleans up invalid nginx configurations
```
## Binding to specific addresses
> New as of 0.19.2
By default, nginx will listen to all interfaces (`[::]` for IPv6, `0.0.0.0` for IPv4) when proxying requests to applications. This may be changed using the `bind-address-ipv4` and `bind-address-ipv6` properties. This is useful in cases where the proxying should be internal to a network or if there are multiple network interfaces that should respond with different content.
This may be reverted by setting an empty bind address.
```shell
dokku nginx:set node-js-app bind-address-ipv4
dokku nginx:set node-js-app bind-address-ipv6
```
> Warning: Validation is not performed on either value.
Users with apps that contain a custom `nginx.conf.sigil` file will need to modify the files to respect the new `NGINX_BIND_ADDRESS_IPV4` and `NGINX_BIND_ADDRESS_IPV6` variables.
## HSTS Header
> New as of 0.20.0
If SSL certificates are present, HSTS will be automatically enabled. It can be toggled via `nginx:set`:
```shell
dokku nginx:set node-js-app hsts true
dokku nginx:set node-js-app hsts false
```
The following options are also available via the `nginx:set` command:
-`hsts` (type: boolean, default: `true`): Enables or disables HSTS for your application.
-`hsts-include-subdomains` (type: boolean, default: `true`): Tells the browser that the HSTS policy also applies to all subdomains of the current domain.
-`hsts-max-age` (type: integer, default: `15724800`): Time in seconds to cache HSTS configuration.
-`hsts-preload` (type: boolean, default: `false`): Tells most major web browsers to include the domain in their HSTS preload lists.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails until the max-age is reached.
## Checking access logs
You may check nginx access logs via the `nginx:access-logs` command. This assumes that app access logs are being stored in `/var/log/nginx/$APP-access.log`, as is the default in the generated `nginx.conf`.
@@ -37,36 +81,81 @@ You may also follow the logs by specifying the `-t` flag.
dokku nginx:error-logs node-js-app -t
```
## Regenerating nginx config
## Changing log path
In certain cases, your app nginx configs may drift from the correct config for your app. You may regenerate the config at any point via the `nginx:build-config` command. This may fail if there are no current web listeners for your app.
> New as of 0.20.1
The path to where log files are stored can be changed by calling the `nginx:set` command with the following options:
The defaults should not be changed without verifying that the paths will be writeable by nginx. However, this setting is useful for enabling or disabling logging by setting the values to `off`.
```shell
dokku nginx:build-config node-js-app
dokku nginx:set node-js-app access-log-path off
dokku nginx:set node-js-app error-log-path off
```
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app access-log-path
dokku nginx:set node-js-app error-log-path
```
In all cases, the nginx config must be regenerated after setting the above values.
## Specifying a read timeout
> New as of 0.21.0
When proxying requests to your applications, it may be useful to specify a proxy read timeout. This can be done via the `nginx:set` command as follows:
The default value is `60s`, and all numeric values _must_ have a trailing time value specified (`s` for seconds, `m` for minutes).
The default value may be set by passing an empty value for the option:
```shell
dokku nginx:set node-js-app proxy-read-timeout
```
In all cases, the nginx config must be regenerated after setting the above value.
## Showing the nginx config
For debugging purposes, it may be useful to show the nginx config. This can be achieved via the `nginx:show-config` command.
```shell
dokku nginx:show-config node-js-app
```
## Validating nginx configs
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
It may be desired to validate an nginx config outside of the deployment process. To do so, run the `nginx:validate-config` command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which `nginx -t` will be run.
```shell
dokku nginx:validate
dokku nginx:validate-config
```
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate` command is the exit code of `nginx -t` against the server's real nginx config.
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but _also_ be valid within the global server context. As such, the exit code for the `nginx:validate-config` command is the exit code of `nginx -t` against the server's real nginx config.
The `nginx:validate` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
The `nginx:validate-config` command also takes an optional `--clean` flag. If specified, invalid nginx configs will be removed.
> Warning: Invalid app nginx config's will be removed _even if_ the config is valid in the global server context.
```shell
dokku nginx:validate --clean
dokku nginx:validate-config --clean
```
The `--clean` flag may also be specified for a given app:
```shell
dokku nginx:validate node-js-app --clean
dokku nginx:validate-config node-js-app --clean
```
## Customizing the nginx configuration
@@ -77,8 +166,9 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
- Copy the following example template to a file named `nginx.conf.sigil` and either:
- If using a buildpack application, you __must__ check it into the root of your app repo.
-`ADD` it to your dockerfile `WORKDIR`
-if your dockerfile has no `WORKDIR`, `ADD` it to the `/app` folder
-If using a dockerfile or docker image for deploys, either:
-If WORKDIR is specified, add the file to the `WORKDIR` specified in the last Dockerfile stage (example: `WORKDIR /app` and `ADD nginx.conf.sigil /app`).
- If no WORKDIR is specified, add the file to the root (`/`) of the docker image (example:ADD nginx.conf.sigil /`).
> When using a custom `nginx.conf.sigil` file, depending upon your application configuration, you *may* be exposing the file externally. As this file is extracted before the container is run, you can, safely delete it in a custom `entrypoint.sh` configured in a Dockerfile `ENTRYPOINT`.
@@ -90,7 +180,6 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
{{ .APP }} Application name
{{ .APP_SSL_PATH }} Path to SSL certificate and key
{{ .DOKKU_ROOT }} Global Dokku root directory (ex: app dir would be `{{ .DOKKU_ROOT }}/{{ .APP }}`)
{{ .DOKKU_APP_LISTENERS }} List of IP:PORT pairs of app containers
{{ .PROXY_PORT }} Non-SSL nginx listener port (same as `DOKKU_PROXY_PORT` config var)
{{ .PROXY_SSL_PORT }} SSL nginx listener port (same as `DOKKU_PROXY_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
@@ -101,6 +190,8 @@ Dokku uses a templating library by the name of [sigil](https://github.com/glider
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
```
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an `.DOKKU_APP_${PROCESS_TYPE}_LISTENERS` variable - the `PROCESS_TYPE` will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
> Note: Application config variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
### Customizing via configuration files included by the default templates
@@ -125,7 +216,7 @@ The example above uses additional configuration files directly on the Dokku host
For PHP Buildpack users, you will also need to provide a `Procfile` and an accompanying `nginx.conf` file to customize the nginx config *within* the container. The following are example contents for your `Procfile`
Your `nginx.conf` file - not to be confused with Dokku's `nginx.conf.sigil` - would also need to be configured as shown in this example:
client_max_body_size 50m;
@@ -146,38 +237,78 @@ By default, Dokku provides custom error pages for the following three categories
These are provided as an alternative to the generic Nginx error page, are shared for _all_ applications, and their contents are located on disk at `/var/lib/dokku/data/nginx-vhosts/dokku-errors`. To customize them for a specific app, create a custom `nginx.conf.sigil` as described above and change the paths to point elsewhere.
## Default site
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration.
Create the file at `/etc/nginx/conf.d/00-default-vhost.conf`:
```nginx
server{
listen80default_server;
listen[::]:80default_server;
server_name_;
access_logoff;
return410;
}
# To handle HTTPS requests, you can uncomment the following section.
#
# Please note that in order to let this work as expected, you need a valid
# SSL certificate for any domains being served. Browsers will show SSL
# errors in all other cases.
#
# Note that the key and certificate files in the below example need to
# be copied into /etc/nginx/ssl/ folder.
#
# server {
# listen 443 ssl;
# listen [::]:443 ssl;
# server_name _;
# ssl_certificate /etc/nginx/ssl/cert.crt;
# ssl_certificate_key /etc/nginx/ssl/cert.key;
# access_log off;
# return 410;
# }
```
Make sure to reload nginx after creating this file by running `service nginx reload`.
This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
The configuration file must be loaded before `/etc/nginx/conf.d/dokku.conf`, so it can not be arranged as a vhost in `/etc/nginx/sites-enabled` that is only processed afterwards.
Alternatively, you may push an app to your Dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
## Domains plugin
See the [domain configuration documentation](/docs/configuration/domains.md).
See the [domain configuration documentation](/docs/configuration/domains.md) for more information on how to configure domains for your app.
## Customizing hostnames
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames).
See the [customizing hostnames documentation](/docs/configuration/domains.md#customizing-hostnames) for more information on how to configure domains for your app.
## Disabling VHOSTS
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts).
## Default site
See the [default site documentation](/docs/configuration/domains.md#default-site).
See the [disabling vhosts documentation](/docs/configuration/domains.md#disabling-vhosts) for more information on how to disable domain usage for your app.
## Running behind a load balancer
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer).
## HSTS Header
See the [HSTS documentation](/docs/configuration/ssl.md#hsts-header).
See the [load balancer documentation](/docs/configuration/ssl.md#running-behind-a-load-balancer) for more information on how to configure your nginx config for running behind a network load balancer.
## SSL Configuration
See the [ssl documentation](/docs/configuration/ssl.md).
See the [ssl documentation](/docs/configuration/ssl.md) for more information on how to configure SSL certificates for your application.
## Disabling Nginx
See the [proxy documentation](/docs/advanced-usage/proxy-management.md).
See the [proxy documentation](/docs/advanced-usage/proxy-management.md) for more information on how to disable nginx as the proxy implementation for your app.
## Managing Proxy Port mappings
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#proxy-port-mapping).
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#proxy-port-mapping) for more information on how to manage ports proxied for your app.
## Regenerating nginx config
See the [proxy documentation](/docs/advanced-usage/proxy-management.md#regenerating-proxy-config) for more information on how to rebuild the nginx proxy configuration for your app.
@@ -9,6 +9,7 @@ certs:add <app> CRT KEY # Add an ssl endpoint to an app. Can al
certs:generate <app> DOMAIN # Generate a key and certificate signing request (and self-signed certificate)
certs:remove <app> # Remove an SSL Endpoint from an app.
certs:report [<app>] [<flag>] # Displays an ssl report for one or more apps
certs:show <app> <crt|key> # Show the server.crt or server.key on stdout
certs:update <app> CRT KEY # Update an SSL Endpoint on an app. Can also import from a tarball on stdin
```
@@ -56,6 +57,16 @@ If you decide to obtain a CA signed certificate, you can import that certificate
The `certs:remove` command only works on app-specific certificates. It will `rm` the app-specific tls directory, rebuild the nginx configuration, and reload nginx.
### Showing the certificate
The `certs:show` command can be used to show your configured certs for an app. The show command can be used for example to export Let's Encrypt certificates
after they've been generated. You can export it as follows:
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does not, by default, enable this header. It is thus left up to you, the user, to enable it for your site.
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does enables this header by default for HTTPS requests.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails.
See the [NGINX HSTS documentation](/docs/configuration/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
## HTTP/2 support
@@ -125,7 +136,7 @@ Certain versions of nginx have bugs that prevent [HTTP/2](https://nginx.org/en/d
Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarded-Port` and `X-Forwarded-For`. These headers indicate the protocol of the original request (HTTP or HTTPS), the port number, and the IP address of the client making the request, respectively. The default configuration is for Nginx to set these headers.
If your server runs behind an HTTP/S load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by using the following [nginx custom template](/docs/configuration/nginx.md#customizing-the-nginx-configuration)
If your server runs behind an HTTP(S) load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by using a [custom nginx template](/docs/configuration/nginx.md#customizing-the-nginx-configuration). The following is a simple example of how to do so.
```go
server{
@@ -150,7 +161,7 @@ server {
}
upstream{{.APP}}{
{{range.DOKKU_APP_LISTENERS|split" "}}
{{range.DOKKU_APP_WEB_LISTENERS|split" "}}
server{{.}};
{{end}}
}
@@ -160,7 +171,7 @@ Only use this option if:
1. All requests are terminated at the load balancer, and forwarded to Nginx
2. The load balancer is configured to send the `X-Forwarded-` headers (this may be off by default)
If it's possible to make HTTP/S requests directly to Nginx, bypassing the load balancer, or if the load balancer is not configured to set these headers, then it becomes possible for a client to set these headers to arbitrary values.
If it's possible to make HTTP(S) requests directly to Nginx, bypassing the load balancer, or if the load balancer is not configured to set these headers, then it becomes possible for a client to set these headers to arbitrary values.
This could result in security issue, for example, if your application looks at the value of the `X-Forwarded-Proto` to determine if the request was made over HTTPS.
Once the deploy is complete, the application's web URL will be generated as above.
Dokku supports deploying applications via [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) with [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks), as well as by using a project's [Dockerfile](https://docs.docker.com/reference/builder/).
Dokku supports deploying applications in a few ways:
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [buildpacks documentation](/docs/deployment/methods/buildpacks.md) to learn about the different ways to specify a buildpack.
- [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/methods/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/images.md) to learn about how to deploy a Docker Image.
### Skipping deployment
@@ -121,7 +124,7 @@ If you need to redeploy or restart your app:
dokku ps:rebuild ruby-getting-started
```
See the [process scaling documentation](/docs/deployment/process-management.md) for more information.
See the [process scaling documentation](/docs/deployment/process-management.md) for more information on how to manage your app processes.
### Deploying with private Git submodules
@@ -188,36 +191,36 @@ Prior to every deployment, Dokku will execute a cleanup function. As of 0.5.x, t
## Adding deploy users
See the [user management documentation](/docs/deployment/user-management.md).
See the [user management documentation](/docs/deployment/user-management.md) for more information on how to manage users with access to your Dokku server.
## Default vhost
See the [nginx documentation](/docs/configuration/nginx.md#default-site).
See the [domains documentation](/docs/configuration/domains.md#default-site) for more information on how to manage the default site.
## Deploying non-master branch
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch).
See the [Git documentation](/docs/deployment/methods/git.md#changing-the-deploy-branch) for more information on deploying a non-master branch to your application.
## Dockerfile deployment
See the [Dockerfile documentation](/docs/deployment/methods/dockerfiles.md).
See the [Dockerfile documentation](/docs/deployment/methods/dockerfiles.md) for information Dokku's Dockerfile support.
## Image tagging
See the [image tagging documentation](/docs/deployment/methods/images.md).
See the [image tagging documentation](/docs/deployment/methods/images.md) for more information on how Docker images can be tagged and deployed for a given application.
## Specifying a custom buildpack
See the [buildpack documentation](/docs/deployment/methods/buildpacks.md).
See the [buildpack documentation](/docs/deployment/methods/buildpacks.md) for more information on how to specify a set of custom buildpacks for your application.
## Removing a deployed app
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#removing-a-deployed-app) for more information on how to remove an application from your Dokku server.
## Renaming a deployed app
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app).
See the [application management documentation](/docs/deployment/application-management.md#renaming-a-deployed-app) for more information on how an application can be renamed and the impact of doing so upon the application and associated resources.
## Zero downtime deploy
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md).
See the [zero-downtime deploy documentation](/docs/deployment/zero-downtime-deploys.md) for more information on how Dokku enables zero-downtime deploys.
The `--force` flag can also be specified on the command vs globally:
```shell
dokku apps:destroy --force node-js-app
```
```
Destroying node-js-app (including all add-ons)
```
Destroying an application will unlink all linked services and destroy any config related to the application. Note that linked services will retain their data for later use (or removal).
### Renaming a deployed app
@@ -134,6 +144,12 @@ Renaming node-js-app to io-js-app... done
This will copy all of your app's contents into a new app directory with the name of your choice, delete your old app, then rebuild the new version of the app and deploy it. All of your config variables, including database urls, will be preserved.
By default, Dokku will deploy the renamed app, though you can skip the deploy by using the `--skip-deploy` flag:
@@ -157,7 +173,7 @@ This will copy all of your app's contents into a new app directory with the name
> Warning: If you have exposed specific ports via `docker-options` plugin, or performed anything that cannot be done against multiple applications, `apps:clone` may result in errors.
By default, Dokku will deploy this new application, though you can skip the deploy by using the `--skip-deploy` flag:
By default, Dokku will deploy this new app, though you can skip the deploy by using the `--skip-deploy` flag:
@@ -36,7 +36,7 @@ will show logs continually from the web process.
### Failed deploy logs
> Warning: The default `docker-local` scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
> Warning: The default [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md) will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
In some cases, it may be useful to retrieve the logs from a previously failed deploy.
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache).
See the [repository management documentation](/docs/advanced-usage/repository-management.md#clearing-app-cache) for more information on how to clear buildpack build cache for an application.
Once set, the Dockerfile usage would be as follows:
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
# set the argument default
ARGNODE_ENV=production
@@ -50,7 +50,7 @@ RUN echo $NODE_ENV
You may also set the argument as an environment variable
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
# set the argument default
ARGNODE_ENV=production
@@ -101,7 +101,7 @@ worker: bin/run-worker.sh
And `Dockerfile`:
```Dockerfile
FROMdebian:jessie
FROMubuntu:18.04
WORKDIR/app
COPY . ./
CMD["bin/run-dev.sh"]
@@ -116,4 +116,4 @@ in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instea
## Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
@@ -76,3 +76,28 @@ This behavior can be disabled entirely on a per-app basis by setting the `rev-en
# override for a specific app
dokku git:set node-js-app rev-env-var ""
```
### Keeping the `.git` directory
By default, Dokku will remove the contents of the `.git` before triggering a build for a given app. This is generally a safe default as shipping the entire source code history of your app in the deployed image artifact is unnecessary as it increases bloat and potentially can leak information if there are any security issues with your app code.
To enable the `.git` directory, run the `git:set` command as follows:
```shell
# on the Dokku host
# keep the .git directory during builds
dokku git:set node-js-app keep-git-dir true
```
The default behavior is to delete this directory and it's contents. To revert to the default behavior, the `keep-git-dir` value can be set to either an empty string or `false`.
```shell
# on the Dokku host
# delete the .git directory during builds (default)
dokku git:set node-js-app keep-git-dir false
# delete the .git directory during builds (default)
@@ -22,7 +22,7 @@ The Dokku tags plugin allows you to add Docker image tags to the currently deplo
### Exposed ports
See the [port management documentation](/docs/networking/port-management.md).
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
@@ -46,6 +46,12 @@ dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
Containers may have specific labels attached. In order to avoid issues with dokku internals, do not use any labels beginning with either `com.dokku` or `org.label-schema`.
```shell
dokku --label=com.example.test-label=value run node-js-app ls -lah
```
Finally, you may wish to run a container in "detached" mode via the `--detach` Dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
@@ -21,8 +21,75 @@ in order to avoid SSH interpretting Dokku arguments for itself.
--force force flag. currently used in apps:destroy and other ":destroy" commands
```
## Clients
## Official Client
You may optionally use a client to connect to your Dokku server. Most clients use the configured `git remote` to locate the Dokku server, though some allow for overriding this via an environment variable or flag.
You may optionally use the official client when connecting to the Dokku server.
Please refer to the [clients](/docs/community/clients.md) list for more details.
Of all methods, this is the *most* official method of interacting with your Dokku installation. It is a bash script that interacts with a remote Dokku installation via `ssh`. It is available in `contrib/dokku_client.sh` in the root of the Dokku repository.
It can be installed either via the [Homebrew](https://brew.sh) package manager (macOS only), or manually.
### Installation via Homebrew
To install, simply run the following command:
```shell
brew install dokku/repo/dokku
```
### Manual installation
To install manually, simply clone the Dokku repository down and add the `dokku` alias pointing at the script:
```shell
git clone git@github.com:dokku/dokku.git ~/.dokku
# optional: make sure that the dokku_client.sh version matches your Dokku version
cd ~/.dokku
git checkout <tag/branch>
# add the following to either your
# .bashrc, .bash_profile, or .profile file
aliasdokku='$HOME/.dokku/contrib/dokku_client.sh'
```
Alternatively, if using another shell such as **zsh**, create an alias command which invokes the script using **bash**:
```shell
# zsh: add the following to either .zshenv or .zshrc
# fish: add the following to ~/.config/fish/config.fish
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
# csh: add the following to .cshrc
alias dokku 'bash $HOME/.dokku/contrib/dokku_client.sh'
```
### Usage
All commands have the application name automatically set via the `--app` flag on the remote server, and thus the app name does not need to be specified manually for core plugins.
The client supports several environment variables:
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overriden via `--remote` flag.
-`DOKKU_PORT` (default: `22`): Used to specify a port to connect to the Dokku server on.
It also supports several flags (all flags unspecified here are passed as is to the server):
-`--app`: Override the remote app in use.
-`--trace`: Enable trace mode.
-`--remote`: Override the remote server.
-`--global`: Unsets the "app" value. May not be supported for the specified command.
In addition, the following commands have special local side-effects:
-`apps:create`:
- If no local `--app` flag is specified or detected from a `dokku` git remote, a random name is generated and used for the app.
- The `dokku` git remote is set if not already set.
-`apps:destroy`:
- Removes the local `dokku` git remote if set.
## Unofficial Clients
Please refer to the [community clients](/docs/community/clients.md) list for more details.
`KEY_NAME` is the name you want to use to refer to this particular key. Including the word `admin` in the name will grant the user privileges to add additional keys remotely.
@@ -72,7 +80,8 @@ dokku ssh-keys:remove KEY_NAME
## Scoping commands to specific users
Keys are given unique names, which can be used in conjunction with the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization. Please see the documentation on that trigger for more information.
Support for scoping commands to specific users can be added through plugins that take advantage of the [user-auth](/docs/development/plugin-triggers.md#user-auth) plugin trigger to handle command authorization.
See also the list of [community-provided plugins](/docs/community/plugins.md).
checks:disable <app> [process-type(s)] Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
checks:enable <app> [process-type(s)] Enable zero-downtime deployment for all processes (or comma-separated process-type list)
checks:report [<app>] [<flag>] Displays a checks report for one or more apps
@@ -123,7 +122,7 @@ To specify checks, add a `CHECKS` file to the root of your project directory. Th
- comments (lines starting with #)
- empty lines
> For Dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
> For Dockerfile and Docker Image based deploys, the file *must* be in the `WORKDIR` directory of the built image. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check instructions
@@ -327,7 +326,6 @@ curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
@@ -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
@@ -143,7 +203,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
- Description: Fetches the app config value for a key
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `config-get-global`
- Description: Fetches the global config value for a key
- Invoked by:
- Arguments: `$KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `core-post-deploy`
> To avoid issues with community plugins, this plugin trigger should be used *only* for core plugins. Please avoid using this trigger in your own plugins.
The default template is viewable here: [plugins/nginx-vhosts/templates/dokku.conf.sigil](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/dokku.conf.sigil)
### `nginx-hostname`
- Description: Allows you to customize the hostname for a given app
@@ -741,6 +954,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.
@@ -820,6 +1049,20 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `post-container-create`
- Description: This trigger should be used to do stuff to containers after they are created but before they are started. They are explicitely for commands that may involve network traffic, and _not_ for commands that are self-contained, such as chown or tar.
- Description: Can be used to run commands after an app is created.
@@ -940,6 +1183,8 @@ haproxy-build-config "$APP"
### `post-release-buildpack`
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using buildpacks.
- Invoked by: `internal function dokku_release() (release phase)`
> Warning: Image mutation in this trigger may result in an invalid run state, and is heavily discouraged.
- Description: Allows you to run commands after environment variables are set for the release step of the deploy. Only applies to apps using a dockerfile.
- Invoked by: `internal function dokku_release() (release phase)`
@@ -9,11 +9,11 @@ We maintain the Dokku test harness within the `tests` directory:
## Continuous Integration
All pull requests have tests run against them on [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).
@@ -6,7 +6,7 @@ Dokku is an extensible, open source Platform as a Service that runs on a single
To start using Dokku, you'll need a system that meets the following minimum requirements:
- A fresh installation of [Ubuntu x64 - Any currently supported release](https://www.ubuntu.com/download), [Debian 8.2 x64](https://www.debian.org/distrib/) or [CentOS 7 x64](https://www.centos.org/download/) *(experimental)* with the FQDN set <sup>[1]</sup>
- A fresh installation of [Ubuntu 16.04/18.04 x64](https://www.ubuntu.com/download), [Debian 9+ x64](https://www.debian.org/distrib/) or [CentOS 7 x64](https://www.centos.org/download/) *(experimental)* with the FQDN set <sup>[1]</sup>
- At least 1 GB of system memory <sup>[2]</sup>
You can *optionally* have a domain name pointed at the host's IP, though this is not necessary.
@@ -21,13 +21,13 @@ To install the latest stable version of Dokku, you can run the following shell c
The installation process takes about 5-10 minutes, depending upon internet connection speed.
If you're using Debian 8 or Ubuntu 14.04, make sure your package manager is configured to install a sufficiently recent version of nginx<sup>[3]</sup>, otherwise, the installation may fail due to `unmet dependencies` relating nginx.
If you're using Debian 9+ or Ubuntu 18.04, make sure your package manager is configured to install a sufficiently recent version of nginx<sup>[3]</sup>, otherwise, the installation may fail due to `unmet dependencies` relating nginx.
#### 2. Setup SSH key and Virtualhost Settings
@@ -58,6 +58,7 @@ As well, you may wish to customize your installation in some other fashion. or e
The `remote rejected` error does not give enough information. Anything could have failed. Enable trace mode and begin debugging. If this does not help you, create a [gist](https://gist.github.com) containing the full log, and create an issue.
One the reasons why you may get this error is because the command that is run in the container exited (without errors). For example, (in Procfile) when you define a new worker container to run Delayed Job and use the bin/delayed_job start command. This command deamonizes the process and exists. The container thinks it's done so it closes itself. The error you get is the one above. To fix the above problem for Delayed Job, you must define the worker to user rake jobs:work, which doesn't deamonize the process.
***
__Symptom:__ I get the aforementioned error in the build phase (after turning on Dokku tracing).
@@ -112,6 +115,18 @@ Please see https://github.com/dokku/dokku/issues/841 and https://github.com/dokk
***
__Symptom:__ After adding an SSH key, I still see the following error on deploy:
Connection closed by <host> port 22
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Certain systems may have access to the `dokku` user via SSH disabled. Please check that the `dokku` user is allowed access to the system in the file `/etc/security/access.conf`. As Dokku does not manage this file, please consult your Operating System's documentation for more information.
***
__Symptom:__ I want to deploy my app but I am getting asked for the password of the Git user and the error message.
fatal: 'NAME' does not appear to be a git repository
@@ -198,7 +213,7 @@ __Symptom:__ I successfully deployed my application with no deployment errors bu
__Solution:__
This can occur if Dokku is running on a system with a firewall like UFW enabled (some OS versions like Ubuntu 16.04 have this enabled by default). You can check if this is your case by running the following script:
This can occur if Dokku is running on a system with a firewall like UFW enabled (some OS versions like Ubuntu have this enabled by default). You can check if this is your case by running the following script:
@@ -15,63 +15,52 @@ Your operating system may occasionally provide security updates. We recommend se
Docker releases updates periodically to their engine. We recommend reading their release notes and upgrading accordingly. Please see the [Docker documentation](https://docs.docker.com/) for more details.
Finally, we provide a helpful binary called `dokku-update`. This is a recommended package that:
- Can be installed separately, so upgrading Dokku will not affect the running of this package.
- Automates many of the upgrade instructions for you.
- Provides a clean way for us to further enhance the upgrade process in the future.
When installing from source, this is available from `contrib/dokku-update`, and is also available on Debian and RPM-based systems from our package repositories under the name `dokku-update`.
## Migration Guides
Before upgrading, check the migration guides to get comfortable with new features and prepare your deployment to be upgraded.
### 0.5 Migration Guide
- [Upgrading to 0.21](/docs/appendices/0.21.0-migration-guide.md)
- [Upgrading to 0.20](/docs/appendices/0.20.0-migration-guide.md)
- [Upgrading to 0.10](/docs/appendices/0.10.0-migration-guide.md)
- [Upgrading to 0.9](/docs/appendices/0.9.0-migration-guide.md)
- [Upgrading to 0.8](/docs/appendices/0.8.0-migration-guide.md)
- [Upgrading to 0.7](/docs/appendices/0.7.0-migration-guide.md)
- [Upgrading to 0.6](/docs/appendices/0.6.0-migration-guide.md)
- [Upgrading to 0.5](/docs/appendices/0.5.0-migration-guide.md)
After upgrading, you should rebuild the applications to take advantage of any
new buildpacks that were released:
```shell
dokku ps:rebuildall
```
> If you have any applications deployed via the `tags` or `tar` commands, do not run the `ps:rebuildall` command,
@@ -84,12 +73,36 @@ dokku ps:rebuildall # rebuilds all applications
> Please see the [images documentation](/docs/deployment/methods/images.md) and [tar documentation](/docs/deployment/methods/tar.md)
> for instructions on rebuilding applications deployed by those plugins.
### Upgrade From Source
## Upgrading using `dokku-update`
We provide a helpful binary called `dokku-update`. This is a recommended package that:
- Can be installed separately, so upgrading Dokku will not affect the running of this package.
- Automates many of the upgrade instructions for you.
- Provides a clean way for us to further enhance the upgrade process in the future.
When installing from source, this is available from `contrib/dokku-update`, and is also available on Debian and RPM-based systems from our package repositories under the name `dokku-update`.
## Upgrading using `apt`
If Dokku was installed in a Debian or Ubuntu system, via `apt install dokku` or `bootstrap.sh`, you can upgrade with `apt`:
- [Gliderlabs Slack](https://glider-slackin.herokuapp.com/) (Join the `#dokku` channel)
If you’re stumped, give us a holler in the Dokku IRC or Slack channels. Someone from the development team is usually there, especially during the daylight hours for North and South America users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate your brand new sports car.
network:create <network> # Creates an attachable docker network
network:destroy <network> # Destroys a docker network
network:exists <network> # Checks if a docker network exists
network:info <network> # Outputs information about a docker network
network:list # Lists all docker networks
network:report [<app>] [<flag>] # Displays a network report for one or more apps
network:rebuild <app> # Rebuilds network settings for an app
network:rebuildall # Rebuild network settings for all apps
@@ -13,6 +18,194 @@ The Network plugin allows developers to abstract the concept of container networ
## Usage
### Listing networks
> New as of 0.20.0, Requires Docker 1.21+
You can easily list all available networks using the `network:list` command:
```shell
dokku network:list
```
```
=====> Networks
bridge
host
none
test-network
```
Note that you can easily hide extra output from Dokku commands by using the `--quiet` flag, which makes it easier to parse on the command line.
```shell
dokku --quiet network:list
```
```
bridge
host
none
test-network
```
### Creating a network
> New as of 0.20.0, Requires Docker 1.21+
Docker networks can be created via the `network:create` command. Executing this command will create an attachable `bridge` network. This can be used to route requests between containers without going through any public network.
```shell
dokku network:create test-network
```
```
-----> Creating network test-network
```
Specifying other additional flags or other types of networks can be created directly via the `docker` command.
### Destroying a network
> New as of 0.20.0, Requires Docker 1.21+
A Docker network without any associated containers may be destroyed via the `network:destroy` command. Docker will refuse to destroy networks that have containers attached.
```shell
dokku network:destroy test-network
```
```shell
! WARNING: Potentially Destructive Action
! This command will destroy network test.
! To proceed, type"test"
> test
-----> Destroying network test
```
As the command is destructive, it will default to asking for confirmation before executing the removal of the network. This may be avoided by providing the `--force` flag:
```shell
dokku --force network:destroy test-network
```
```shell
-----> Destroying network test
```
### Checking if a network exists
> New as of 0.20.0, Requires Docker 1.21+
For CI/CD pipelines, it may be useful to see if an network exists before creating a new network. You can do so via the `network:exists` command:
```shell
dokku network:exists nonexistent-network
```
```
Network does not exist
```
The `network:exists` command will return non-zero if the network does not exist, and zero if it does.
### Checking network info
> New as of 0.20.0, Requires Docker 1.21+
Network information can be retrieved via the `network:info` command. This is a slightly different version of the `docker network` command.
```shell
dokku network:info test-network
```
```
// TODO
```
### Attaching an app to a network
> New as of 0.20.0, Requires Docker 1.21+
Apps will default to being associated with the `bridge` network, but can be attached to `attachable` networks by changing the `attach-post-create` or `attach-post-deploy` network properties when using the [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md). A change in these values will require an app deploy or rebuild.
```shell
# associates the network after a container is created but before it is started
Setting the `attach` network property to an empty value will de-associate the container with the network.
```shell
dokku network:set node-js-app attach-post-create
dokku network:set node-js-app attach-post-deploy
```
#### Network Aliases
When a container created for a deployment is being attached to a network - regardless of which `attach` property was used - a network alias of the pattern `APP.PROC_TYPE` will be added to all containers. This can be used to load-balance requests between containers. For an application named `node-js-app` with a process type of web, the network alias - or resolvable DNS record within the network - will be:
```
node-js-app.web
```
The fully-qualified URL for the resource will depend upon the `PORT` being listened to by the application. Applications built via buildpacks will have their `PORT` environment variable set to `5000`, and as such internal network requests for the above example should point to the following:
```
http://node-js-app.web:5000
```
Dockerfile-based applications may listen on other ports. For more information on how ports are specified for applications, please refer to the [port management documentation](/docs/networking/port-management.md).
#### Specifying a custom TLD
When attaching applications to networks, a custom TLD can be specified via the `network:set` command. This TLD is suffixed to the network alias for the application/process-type combination for _all_ networks to which the application is attached, and cannot be customized per network.
To specify a TLD of `svc.cluster.local` for your application, run the following command:
With an application named `node-js-app` and a process-type named `web`, the above command will turn the network alias into:
```shell
node-js-app.web.svc.cluster.local
```
Note that this has no impact on container port handling, and users must still specify the container port when making internal network requests.
#### When to attach containers to a network
Containers can be attached to a network for a variety of reasons:
- A background process in one app needs to communicate to a webservice in another app
- An app needs to talk to a container not managed by Dokku in a secure manner
- A custom network that allows transparent access to another host exists and is necessary for an app to run
Whatever the reason, the semantics of the two network hooks are important and are outlined before.
-`attach-post-create`:
- Phase it applies to:
-`build`: Intermediate containers created during the build process.
-`deploy`: Deployed app containers.
-`run`: Containers created by the `run` command.
- Container state on attach: `created` but not `running`
- Use case: When the container needs to access a resource on the network.
- Example: The app needs to talk to a database on the same network when it first boots.
-`attach-post-deploy`
- Phase it applies to:
-`deploy`: Deployed app containers.
- Container state on attach: `running`
- Use case: When another container on the network needs to access _this_ container.
- Example: A background process needs to communicate with the web process exposed by this container.
> Warning: If the attachment fails at this stage, this may result in your application failing to respond to proxied requests once older containers are removed.
### Rebuilding network settings
There are cases where you may need to rebuild the network configuration for an app, such as on app boot or container restart. In these cases, you can use the `network:rebuild` command:
@@ -37,7 +230,7 @@ dokku network:rebuildall
> This functionality does not control the `--network` docker flag. Please use the [docker-options plugin](docs/advanced-usage/docker-options.md) to manage this flag.
By default, an application will only bind to the internal interface. This behavior can be modified per app by changing the `bind-all-interfaces` network property.
By default, an app will only bind to the internal interface. This behavior can be modified per app by changing the `bind-all-interfaces` network property.
```shell
# bind to the default docker interface (`docker0`) with a random internal ip
@@ -16,12 +16,16 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
> Warning: Mapping alternative ports may conflict with the active firewall installed on your server or hosting provider. Such software includes - but is not limited to - AWS Security Groups, iptables, and UFW. Please consult the documentation for those softwares as applicable.
### Proxy port mapping
> New as of 0.6.0
You can now configure `host -> container` port mappings with the `proxy:ports-*` commands. This mapping is currently supported by the built-in nginx-vhosts plugin.
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` commands detailed below.
### Listing port mappings
To inspect the port mapping for a given application, use the `proxy:ports` command:
A port mapping can be removed using the `proxy:ports-remove` command if it no longer necessary:
```shell
dokku proxy:ports-remove node-js-app http:80:5000
```
By default, buildpack apps and dockerfile apps **without** explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on port `80` (and additionally a listener on 443 if ssl is enabled) that will proxy to the application container on port `5000`. Dockerfile apps **with** explicitly exposed ports will be configured with a listener on each exposed port and will proxy to that same port of the deployed application container.
Ports may also be removed by specifying only the `host-port` value. This effectively acts as a wildcard and removes all mappings for that particular host port.
> Note: This default behavior **will not** be automatically changed on subsequent pushes and must be manipulated with the `proxy:ports-*` syntax detailed above.
```shell
dokku proxy:ports-remove node-js-app http:80
```
## Port management by Deployment Method
@@ -126,7 +136,7 @@ For buildpack deployments, your application *must* respect the `PORT` environmen
> Changed as of 0.5.0
Dokku's default proxy implementation - nginx - only supports HTTP request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
Dokku's default proxy implementation - nginx - supports HTTP and GRPC request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
#### Applications using EXPOSE
@@ -135,7 +145,7 @@ Dokku will extract all tcp ports exposed using the `EXPOSE` directive (one port
For example, if the Dokku installation is configured with the domain `dokku.me` and an application named `node-js-app` is deployed with following Dockerfile:
proxy:build-config <app> # (Re)builds config for given app
proxy:disable <app> # Disable proxy for app
proxy:enable <app> # Enable proxy for app
proxy:report [<app>] [<flag>] # Displays a proxy report for one or more apps
@@ -13,6 +14,14 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
## Usage
### Regenerating proxy config
In certain cases, your app proxy configs may drift from the correct config for your app. You may regenerate the config at any point via the `proxy:build-config` command. This command will trigger a rebuild for the configured proxy implementation (default: nginx) for a given app. The command may fail if there are no current web listeners for your app.
```shell
dokku proxy:build-config node-js-app
```
### Container network interface binding
> Changed as of 0.11.0
@@ -69,7 +78,8 @@ The proxy port scheme is as follows:
-`SCHEME:HOST_PORT:CONTAINER_PORT`
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports both the `http` and `https` schemes.
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.