# History
## 0.16.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.16.1/bootstrap.sh
sudo DOKKU_TAG=v0.16.1 bash bootstrap.sh
```
### New Features
- #3532: @josegonzalez refactor: allow the scheduler to decide if an app is deployed
### Documentation
- #3530: @jhstatewide Updated info about supported Ubuntu versions
The previous output required too much parsing to be used in an automated fashion. This change makes that a bit easier, without sacrificing usability.
Note that the output is quite a bit different from heroku. This is purposeful as we do not have the concept of dynos.
Closes#3520
Use `GIT_STRATEGY: none` in `stop_review_app` to make job work after successful
merges and when the branch was deleted.
Without this, the application is not stopped when the branch is deleted on merge as the runner pulls the git repository by default, but cannot find the tree in this moment.
[skip ci]
# History
## 0.15.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.15.5/bootstrap.sh
sudo DOKKU_TAG=v0.15.5 bash bootstrap.sh
```
### New Features
- #3511: @josegonzalez Add json output to config:export
### Documentation
- #3510: @josegonzalez Remove SPONSORS doc in favor of OpenCollective
- #3509: @Neamar Missing space in markdown formatting
- #3507: @renestalder Fix GitLab CI examples
This change adds json output as both key/value as well as a list of objects. The former can be used in quick scripting environments, while the latter allows higher-level languages to have a bit more structure around how environment variables are declared. Specifically, systems such as kubernetes understand the latter method, while the former can be used within Nomad job files.
The GitLab CI examples used `$CI_ENVIRONMENT_SLUG` for defining the environment names
of the deploy jobs. But this variable is actually the OUTPUT of setting the environment name,
thus, it tries to reference itself, but does not exist in that moment.
The correct way to set this is to use `$CI_COMMIT_REF_NAME` as based on the documentation
of GitLab's dynamic environments.
With the introduciton of procfile-util, scaling a non-existent process to 0 was disabled. This brings back that functionality, allowing users to scale all processes to 0. This is especially useful when a user has accidentally scaled a non-existent process up, causing deploys to fail without any way to revert outside of manually editing files.
Closes#3428
The `domains` command previously had this functionality, but is deprecated, and thus we should provide an alternative method of presenting the information.
This moves the base image from Xenial to Bionic, which is the latest supported LTS release of Ubuntu. Note that all previous releases of herokuish are no longer supported, and users are encouraged to upgrade where possible.
In the case of upgrades, a 'dokku repo:purge-cache APP' should be called for each app, or built applications may include code linked to non-ABI compatible libraries due to the OS upgrade.
This sort of change is usually performed _only_ during a minor release, but as the window since the release is fairly small, the risk to our users is negligible in comparison to the inability to stay on a maintained herokuish release.
Global limits make it harder to reason about the inheritance in the system. Rather than support global limits, Dokku should provide primitives to automatically set them on an app at provision time, or explicitly set them for an app. Both of these are likely best suited for a higher-level provisioner, or a community plugin.
This will allow validation to work if the default logging locations cannot be written to but the configuration is otherwise okay. This will be the case for users with custom nginx configurations that log to other places, such as syslog.
When setting environment variables, we should respect a passed `--quiet` flag - and the respective environment variable. This will allow users to have a nicer experience when using the config functions within their own plugins.
Rather than always assuming a missing `WORKDIR` means herokuish, we instead inspect the image to verify that it is. If it is, then and _only_ then do we set WORKDIR. Otherwise, we respect the decision of `docker cp` to execute from within the last known `WORKDIR` context, which is inherited at the image level, not image metadata level.
Additionally, speed up `is_image_herokuish_based` by inspecting the environment variables on the image. When there is a "USER=herokuishuser", we can more or less safely assume it is an image that Dokku built, and is therefore a herokuish image. While possible, it would be very strange if a non-herokuish image had this environment variable set, so it is a relatively safe change.
- ensure nginx is always installed
- install nginx in the same way for apt-using distros
- do not install software-properties-common or python-software-properties if not needed
Log output for ps:retire was previously a bit too verbose because we weren't handling the following edge-cases.
- if a container doesn't exist, remove it from the dead container list
- ensure a restarting container is properly killed
- only attempt to stop/kill if the state is not dead or exited
- do not attempt to do anything if the container doesn't exist
- correct check on running state
Previously, if running 'dokku report --all', the early exit 1 in apps:report would cause the entire process to bail, resulting in a partial report. Instead, we exit 0, allowing plugn to continue.
Technically a non-deployed app is not an error case at this position.
# History
## 0.14.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.14.1/bootstrap.sh
sudo DOKKU_TAG=v0.14.1 bash bootstrap.sh
```
### Bug Fixes
- #3386: @josegonzalez Ensure we can deploy code when there is no pre or post-deploy script defined
# History
## 0.14.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.14.0/bootstrap.sh
sudo DOKKU_TAG=v0.14.0 bash bootstrap.sh
```
### Bug Fixes
- #3384: @josegonzalez fix: use updated gpg key for apt repository
- #3382: @josegonzalez Set cleanup to global when no application is specified
- #3350: @josegonzalez Do not build the proxy config when there are no app listeners
- #3366: @josegonzalez Add post-app-clone-setup to network clean make target
- #3349: @josegonzalez Ensure apps are cleanly cloned
- #3356: @josegonzalez Move storage directory into DOKKU_LIB_ROOT
- #3341: @baikunz Select only default dokku network IP
- #3348: @josegonzalez Use correct name for packagecloud token when running CI commands
- #3339: @josegonzalez Properly check args when calling cleanup globally
- #3344: @josegonzalez Allow running dokku report without needing an interactive shell
### New Features
- #3381: @josegonzalez Add support for the Procfile release command
- #3380: @josegonzalez Install stable docker when using bootstrap script
- #3378: @josegonzalez Make admin setup UI look nicer
- #3369: @josegonzalez Pull invalid nginx configuration when the nginx configs fail to validate
- #3371: @josegonzalez Add tests section to changelog
- #3358: @josegonzalez Image tag deploy workflow cleanup
- #3351: @josegonzalez Do not clone URLS and VHOST files to new apps
- #3357: @josegonzalez Add support for building arbitrary releases
- #3354: @josegonzalez Drop default dhparam key size to 2048
- #3347: @josegonzalez Upgrade herokuish
- #3352: @josegonzalez Increase security of default SSL setup
- #3353: @josegonzalez Normalize tests
- #3345: @josegonzalez Allow triggering the full report for all apps via --all flag
- #3346: @josegonzalez Always overwrite the dokku.conf file for nginx
### Documentation
- #3377: @josegonzalez Remove team member section on homepage in favor of sponsor section
- #3376: @josegonzalez Switch from rawgit to jsdelivr
- #3365: @josegonzalez Remove extra tags:create call from docs
### Tests
- #3379: @josegonzalez Run mvdan/shfmt on test runs
- #3370: @josegonzalez Add junit support to shellcheck output
- #3308: @josegonzalez Add timing info to test runs on CircleCI
- #3367: @josegonzalez Run tests from built artifact
- #3368: @josegonzalez Balance circleci tests
- #3363: @josegonzalez Add a wrapper for invoking a single test
- #3362: @josegonzalez Allow tests to be run from any directory
- #3360: @josegonzalez Switch to bats-core
- #3361: @josegonzalez Do not generate dhparam for tests
### Other
- #3279: @fruitl00p Make sure the universe repo is loaded into APT
This script previously ran through the docker installation process with the edge channel on each run. Instead, we only run the docker installation if docker is not available. In addition, we force set the channel to stable, ensuring the script installs the correct channel for stable docker installations.
Closes#3269
While I do not agree with _every_ style change, this will force Dokku to have consistent formatting across all shell scripts, which is arguably a Good Thing™.
The command used to reprocess everything is:
```shell
shfmt -l -bn -ci -i 2 -w .
```
The initial admin setup UI is a bit of a hack, but could also be a bit frustrating to new users as the settings are unclear. Rather than throw them to the wolves, include some useful information to allow them to make good decisions when setting up Dokku.
- Upgrade to latest bootstramp and latest jquery 1.x release
- Add a warning for people who might miss this setup page
- Add placeholder text to both the ssh key area and the hostname
- Add descriptions to all form fields to further explain the consequences of a particular field
- Add links where necessary for users who wish to explore how to change settings in the future
- Make the "result" message on submission red or green depending on the success or failure of the submission.
- Wait 3 seconds before redirecting on success
On Ubuntu within AWS environments, the default user is the `ubuntu` user, and this is where the ssh key should be pulled from. CentOS has a tendency to use `ec2-user`.
On all other environments, the `root` user is typically the only user provisioned.
Closes#3372
The checkstyle xslt wasn't quite good enough, resulting in missing/malformatted output. Note that this now excludes _passing_ tests, which also isn't quite right, but a fair bit closer to the xsd here: https://github.com/windyroad/JUnit-Schema
This requires us to run shellcheck twice, as the first pass doesn't output anything human readable - both because of the redirect and because shellcheck doesn't directly support it - which increases lint runtime but allows us to have both the junit information and the normal human-readable output.
Note that the checkstyle output does not contain timing info.
This removes outdated information on the main page in favor of the "official" ways of sponsoring Dokku.
Also update the contributing note to mention where to post
Are you a crypto-user and want other options? Feel free to send bitcoin to 3MY2HxMVsxuWmhQkgYBsE3iZFjJgkjNPyQ
Closes#3374
Rawgit is no longer being offered due to spammers, but jsdelivr has graciously allowed folks to use their cdn to mirror assets from github.
Closes#3284
- expose an nginx:validate command that can be used to show validation information
- properly reference the invalid nginx config, rather than tell the user that another app's nginx config is invalid when deploying their own app
- allow a user to cleanup bad nginx config files out of band when they are blocking a deploy _without_ requiring knowing where that nginx config is
Note that this may have issues with generated nginx.conf files that depend on other apps or other parts of the nginx config. For now, this is acceptable, though it is something that needs to be field tested.
Closes#3162
This avoids cases where a developer believes they should be able to provision an nginx proxy but is unable to as no web process is configured to listen for the app.
Also silence stderr when extracting custom nginx templates. If there is stderr, that means we were not able to retrieve the template, but it's of no consequence for debugging.
Closes#3262
Rather than testing against an install from source, ensure that all tests run from what _would_ be installed on a user's server. This ensures that the build process is sound, regardless of what code changes are implemented.
This switches from the older, unmaintained version of bats to one that _is_ maintained. In particular, this fork of the community version - bats-core/bats-core - adds junit timing support, which can be used to track down slow tests.
Once the bats-core/bats-core repository merges junit support, we will switch back to upstream.
Note that tests on OS X will still run using a version that _does not_ have junit timing support.
The cipher list is from from https://cipherli.st/ and will remove a few older browsers:
- Android 5.0
- Android 6.0
- Chrome 49 / XP SP3
- Firefox 31.3.0 ESR / Win 7
- Firefox 47 / Win 7 R
- IE 11 / Win Phone 8.1
I _think_ thats an okay drop - dropping Android kinda hurts, but we're far from the only ones dropping them from being served, and our users are free to override these settings on their own servers.
Closes#3343
This is necessary as sometimes older config is shipped with Dokku, meaning that security directives - amongst others - are not properly updated.
Refs #3342
# History
## 0.13.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.4/bootstrap.sh
sudo DOKKU_TAG=v0.13.4 bash bootstrap.sh
```
### Bug Fixes
- #3337: @josegonzalez Use correct container id variable for killing containers
### New Features
- #3338: @josegonzalez Redirect ps:retire output to a log file
This will allow systems to properly monitor whether retiring old containers works.
Note that the file will be logrotated by the 20_events logrotate config.
# History
## 0.13.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.3/bootstrap.sh
sudo DOKKU_TAG=v0.13.3 bash bootstrap.sh
```
### Bug Fixes
- #3330: @josegonzalez Ensure chowned properties always have a user and group set
### New Features
- #3334: @josegonzalez refactor: run every 5 minutes instead of 2
# History
## 0.13.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.13.2/bootstrap.sh
sudo DOKKU_TAG=v0.13.2 bash bootstrap.sh
```
### Bug Fixes
- #3329: @josegonzalez Avoid parsing missing file when retiring containers
- #3325: @wcalandro Add "--global" to dokku cleanup on dokku update
### Documentation
- #3326: @josegonzalez Add note to release on how to upgrade via the bootstrap script
# History
## 0.13.0
### Bug Fixes
- #3312: @josegonzalez fix: keep track of failed containers regardless of docker kill output
- #3299: @josegonzalez Wrap script_bin in double-quotes
- #3295: @alexquick Sort config:show by key name
- #3288: @josegonzalez Wrap script binary in single quotes during executable check
### New Features
- #3302: @josegonzalez Add ability to check on app lock status via apps:locked command
- #3315: @aokon Upgrade herokuish to 0.4.5 version
- #3236: @josegonzalez Retire old containers
- #3307: @josegonzalez Add support for docker.io package
- #3301: @josegonzalez Add ability to sync packages to a new version of ubuntu
- #3286: @josegonzalez Sanitize docker inspect output with ps:inspect
- #3240: @josegonzalez Refactor Procfile handling to use go-procfile-util
- #3282: @josegonzalez Use create instead of run for faster and more reliable file copy from docker images
- #3280: @josegonzalez Better scheduler support
- #3259: @josegonzalez Check if script is executable when a full path is specified
### Documentation
- #3314: @royklutman Remove reference to non-existent DigitalOcean hosting plan
- #3313: @morenoh149 Indicate to user to specify hostname
- #3310: @josegonzalez Add a note to our issue template begging for money
- #3281: @josegonzalez Add documentation on custom error pages
This is new in Ubuntu Bionic, and should allow users to install without using upstream docker.
Note that we recommend installing from upstream where possible.
Closes#3297
These will be killed on a cron schedule, allowing us to ensure old containers don't run once memory pressure clears up - even across restarts.
Closes#3225
Often-times, we will want to have the container inspect output for debugging purposes, but this process is:
- error prone, as the user needs to know what their containers are
- potentially insecure, as the output must be sanitized of sensitive data
Instead of making users wade through this process, we provide a helper `ps:inspect` command, that can be used to diagnose problems associated with containers that may or may not exist for an application.
This allows us to force another plugin as the default vhost implementation, or disable it altogether in favor of some higher-level proxy implementation, such as one that integrates with service discovery.
Some systems - such as a mounted read-only CIFS filesystem - do not fully support chown, and chowning should be considered optional for cases when the host os has already taken care of permissioning. This commit allows users to disable chown by setting a property on the scheduler-docker-local plugin.
# History
## 0.12.11
### Bug Fixes
- #3238: @josegonzalez Handle proxy issues in app renaming
- #3234: @mashrikt Unset GIT_QUARANTINE_PATH when updating repo submodule
- #3223: @josegonzalez Get the global scheduler if no app is specified
- #3218: @wcalandro Fix error text when using "dokku plugin:uninstall"
### New Features
- #3242: @josegonzalez Upgrade herokuish to 0.4.3
- #3241: @josegonzalez Add a subcommand for retrieving failed app deploy logs
- #3237: @josegonzalez Support --quiet header when showing all environment variables
### Documentation
- #3235: @josegonzalez Switch from ps:rebuild to ps:restart
- #3221: @josegonzalez Better callout for why env vars do not get applied to dockerfile builds
This can be useful in cases where a developer wishes to see what error messages are available for a failed deploy, but does not wish to spelunk around `docker ps -a` output.
Note that the logs are not made available once a further deploy is triggered, or after the containers have been garbage collected.
This will allow us to kill stale proxy configuration within apps, which is critical during application renames.
- redirect rmdir output to dev-null
- trigger a proxy-clear-config (new trigger) when renaming an application
- The configuration will be rebuilt during the later `ps_rebuild`
Closes#3231
Ubuntu has been slimming down their installations recently, so requiring net-tools fixes usage issues for many commonly installed plugins (such as the datastore plugins).
- reorder things to make it clearer to the user what they are filing
- use headers for various sections
- separate the `dokku report` section to increase its importance
[ci skip]
# History
## 0.12.6
### Bug Fixes
- #3193: @josegonzalez Install bash-completion files correctly
- #3179: @josegonzalez Ignore issues with popd when OS versions with stricter security
- #3177: @philm ensure dokku-redeploy runs when docker is stopped then started
- #3176: @josegonzalez Detect mixed running status on service start
### New Features
- #3195: @josegonzalez Allow lower versions of docker-engine
- #3181: @malixsys Adding support for `http2_push_preload` to nginx 1.13.9+ configuration
- #3183: @josegonzalez Unskip initial herokuish test
- #3175: @josegonzalez Implement bash-completion for commands
### Documentation
- #3197: @josegonzalez Add a tutorial for deploying applications via gitlab ci
- #3194: @josegonzalez Clarify why dokku report information is useful
- #3189: @josegonzalez Correct issue with adding a user remotely
In some cases, a single allocation for a service may not be running, but the others will, and `is_app_running` will return the wrong thing.
Closes#2772
This will allow us to _actually_ introspect on the running state of an application. In certain cases, the detected state can be "mixed", meaning that we may need to take action, depending on what we want to do in mixed mode.
This only completes the command names - not any arguments - and also relies on a completion cache as the response from Dokku for help output can be slow.
Closes#2095
# History
## 0.12.5
### Bug Fixes
- #3173: @josegonzalez fix: do not output error message twice
### New Features
- #3172: @josegonzalez feat: Add the ability to ignore existing applications during a git clone
- #3171: @josegonzalez Allow users to override the reported app url
- #3170: @josegonzalez Add ps:startall command
### Documentation
- #3159: @zuck Improve docs for default site with HTTPS
This is useful in cases where the app url has some "interesting" structure - such as a subdomain or scheme change - for a specific installation.
Closes#3160
# History
## 0.12.3
### Bug Fixes
- #3156: @josegonzalez fix: ensure we _always_ include all types in history output
### Documentation
- #3163: @josegonzalez Better apt install formatting
### Other
- #3153: @scjody Allow specifying a separate DOKKU_HOST_ROOT
In some cases, we might miss pull requests where there is more than one 'type' label, causing that pull request to be omitted from the history. This change ensures we always include pull requests in the change log
As this was not strictly announced in our migration guide, removing it is a bc-incompatible change we are not comfortable with. We may wish to remove it in the future
This is to be used in place of `DOKKU_ROOT` when we need to refer to a
path on the system where the Docker daemon is being run; if `dokku` is
running in a container this may be different from the regular
`DOKKU_ROOT`.
# History
## 0.12.0
### Bug Fixes
- #3146: @josegonzalez Fix non ubuntu installs
- #3138: @josegonzalez Use correct path for /etc/default file
- #3137: @josegonzalez Ensure we can disable setting the rev-env-var
- #3131: @axilleas Capitalize log sentence when renaming containers
- #3128: @Modicrumb Improve windows vagrant experience
- #3105: @znz Follow renaming from deploy-method to deploy-source
- #3101: @josegonzalez Handle stopped nginx during debian installation
### New Features
- #3141: @josegonzalez Centralize app existence checks into the apps plugin
- #3147: @josegonzalez Create proxy:ports-set call
- #3145: @josegonzalez Add report trigger
- #3144: @josegonzalez Increase curl max timeout to 600 seconds (10 minutes)
- #3107: @znz Remove unused password in ssl cert generation
- #3095: @josegonzalez Migrate env for NGINX_* to PROXY_*
- #3140: @josegonzalez Add newline to config:get output
- #3139: @josegonzalez Add ability to initialize a git repository out of band
- #3111: @josegonzalez Upgrade herokuish to 0.4.0
- #3110: @josegonzalez Upgrade herokuish to 0.3.36
- #3106: @znz Remove unnecessary shellcheck disable
- #3098: @josegonzalez Pull herokuish from docker hub when installing via package
- #3100: @josegonzalez Properly handle invalid process type entries during DOKKU_SCALE generation
- #3097: @josegonzalez Update herokuish to 0.3.35
### Documentation
- #3148: @josegonzalez Use consistent terms for domains, apps, and commands
- #3135: @josegonzalez Revert "Clarify that the checks plugin only matches content start"
- #3134: @tomdyson Fix typo in upgrading docs
- #3119: @TomasHubelbauer Link through to the application deployment page after the installation
- #3118: @Tyilo Clarify that the checks plugin only matches content start
- #3113: @ilyapoz Fix proxy management link
- #3112: @josegonzalez Minor doc css fixes
- #3104: @sarendsen Add dokku-limit to plugins documentation
- #3108: @znz Update plugin list output
In some cases, it may be useful to completely override the set ports for a given application - such as on initial deploy when there is no global domain set. This change also further allows us to handle automation in a smoother fashion.
This allows users to quickly show the state of any configured application, as well as the state of their server. In doing so, we make it easy for them to provide information necessary for debugging in a single command.
The correct way to handle getting the status should be ps:report.
Also cleaned up an issue where ps:report failed to catch errors for non-running containers.
This is useful in contexts where the repository directory may be created and interacted with via git-http-backend or other methods of updating a repository.
- add `report` and `set` subcommands to the git plugin
- move configuring the DOKKU_DEPLOY_BRANCH to the git plugin
- implement configurable GIT_REV support
- migrate DOKKU_DEPLOY_BRANCH settings
- add a golang-compatible, shell based method of setting plugin configuration variables
Deprecates the community dokku-git-rev plugin.
Closes#2621
Refs dokku-community/dokku-git-rev#9
# History
## 0.11.6
### Bug Fixes
- #3091: @josegonzalez Properly trigger tar-based deploys on git-deployed repositories
- #3076: @Kjwon15 Prune worktree after build
- #3090: @josegonzalez Ensure all plugin triggers have docs and events integration
- #3089: @josegonzalez Use a longer password for self-signed certificates
### New Features
- #2950: @adelq Add configuration option to disable automatic app creation
- #3093: @josegonzalez Add subcommands to allow app locking and unlocking
- #3092: @josegonzalez Add support for configuring the app shell
### Documentation
- #3096: @josegonzalez docs: Document how to check on a running dokku-installer
This removes the ability to support http proxy directly, but fixes issues where users may not
be using exactly the same herokuish as we expect.
Closes#2828
[ci skip]
Unlocking an app will not stop running deploys, so users may need to clean up. However, it is useful for deploys that fail in unusual ways that cause the lock to stay around.
Closes#2883
This allows developers to change the shell from /bin/bash to any other when executing
`dokku enter` or pre/post deployment tasks. Ideally we could detect the shells available,
but that is slow and potentially error prone.
Closes#2572
# History
## 0.11.5
### Bug Fixes
- #3088: @josegonzalez Silence port retrieval stderr
- #3086: @josegonzalez Fix help output for golang plugins
- #3079: @josegonzalez Move container status exclusively to ps plugin
### New Features
- #3085: @josegonzalez Add support for checking if an application exists
- #3032: @josegonzalez Add support for arbitrary ubuntu versions
- #3074: @josegonzalez Add the ability to disable ANSI prefixes via DOKKU_DISABLE_ANSI_PREFIX_REMOVAL
- #3083: @josegonzalez Source /etc/defaults/dokku if available
### Documentation
- #2958: @silverfix Add tutorial for running Dokku on an external volume
- #3082: @josegonzalez Switch from Gratipay to Patreon
- #3081: @josegonzalez Add docs for switching between deployment methodologies
This allows users to override - at a top-level - the DOKKU_ROOT, DOKKU_LIB_ROOT, and other
configuration variables. If specified, this should begin to enable users to move their
Dokku installations to mounted drives.
Note that items installed from packages may not respect these paths, so further work may be in order.
Closes#2958
These should never have been in common, and more directly relate to domain handling than anything else.
As this is a BC-break, merging will need to wait until the next minor.
# History
## 0.11.4
### Bug Fixes
- #3071: @josegonzalez Do not grab restart policies if the deploy phase cannot be read
- #3065: @josegonzalez Check if dokkurc files are readable before attempting to source
- #3066: @josegonzalez Validate that all application names are valid domain names
- #3052: @alexquick Remove bad config keys on load from app/global envfiles
### New Features
- #3073: @josegonzalez Add support for rhel
- #3039: @josegonzalez Enhance security-related upgrade process
- #3038: @shrmnk Add ps:stopall subcommand
- #3055: @michaelshobbs Update to herokuish v0.3.34
- #3045: @jcrben Remove nginx configuration files on debian purge
### Documentation
- #3072: @josegonzalez Remove all references to VHOST files from documentation
- #3069: @josegonzalez Remove potentially bad nginx template examples
- #3059: @lwm Add note for runtime host configuration for checks.
- #3041: @jcrben Point to unattended install instructions
- #3053: @mimischi Add plugin to manage Dockerfile location to documentation
- #3062: @shannara Change help run command be more explicit
- #3034: @znz Fix a typo in golang config.go source
- #3061: @tomdyson Fix plugin-triggers docs typo
- #3056: @raine Fix typo in config help output
- #3044: @takuti Fix links to port-management
- #3042: @josegonzalez Improve documentation around port handling.
The centos rpm packages should be installable on centos once this is merged and released. However, Dokku will not maintain an Rhel-specific repository as there is no way for us to feasibly test it.
Closes#3046
Users should never be in a position where they need to manually edit files managed by Dokku, and should be pushed to using the `domains` plugin where necessary.
Closes#3064
[ci skip]
These examples do not include _all_ of the contents of the original template. Rather than having to keep them up to date and confuse users when we don't, lets just remove them. The section above contains a link to the current `nginx.conf.sigil` and should be referenced by our users instead.
Closes#3068
[ci skip]
While there are a number of enhancements we could do to make port handling more seamless, this is a first step towards documenting the various oddities around port management for Docker vs Buildpack deploys.
Refs #2903Closes#2970
[ci skip]
# History
## 0.11.3
### Bug Fixes
- #3031: @josegonzalez fix: ensure we respect DOKKU_DEPLOY_BRANCH when rebuilding applications
### New Features
- #3028: @josegonzalez Ensure parallel runs properly for non-restorable apps and moreutils parallel
- #3030: @josegonzalez feat: allow changing the system user the properties plugin uses
- #3024: @jcrben Use high-availability pool keyserver during tests
- #3017: @josegonzalez feat: add pre-start trigger for notifying on application start
### Documentation
- #3020: @gliwka Point to docs in the right version
- #3016: @josegonzalez Update nginx template example to use http2 when available
# History
## 0.11.2
### Bug Fixes
- #3014: @josegonzalez fix: handle case where DOKKU_DOCKERFILE_PORTS is an empty string
- #3013: @alexquick Fix some issues with config/network/repo help output
- #3012: @alexquick Fail when setting/unsetting invalid keys
- #3011: @alexquick Forward output from plugn triggers to user
- #3004: @josegonzalez Return/Exit 1 when an image being deployed is invalid
### Documentation
- #3015: @elia Tiny fixes to triggers documentation
# History
## 0.11.1
### Bug Fixes
- #3010: @josegonzalez fix: route config_all to the `config` command to fix datastore plugin usage
- #3009: @josegonzalez fix: correct the guard around the config_export call in config_sub
- #3006: @josegonzalez fix: do not allow shadowing of the CACHE_DIR variable
- #3005: @josegonzalez fix: persist users in the dokku group through installations
- #3003: @josegonzalez Fix issues in apps:clone calls
- #3001: @josegonzalez fix: allow applications to begin with numeric values
### New Features
- #3002: @josegonzalez fix: omit redirection of docker build output
- #3000: @josegonzalez fix: remove golang files and triggers directory for packaging
# History
## 0.11.0
### Bug Fixes
- #2998: @josegonzalez Fix issues in release process
- #2993: @josegonzalez Add config_all alias for plugin usage
- #2972: @buckle2000 Correct typo in docker-options:remove error output
- #2964: @znz Remove unused variable
- #2967: @znz Fix indentation in test file
- #2963: @znz Correct typos in config plugin and remove potential infinite recursion issue
- #2951: @josegonzalez Handle case where the app directory is a symlink
- #2939: @znz Remove unnecessary lines
- #2945: @znz Fix network plugin version
- #2937: @michaelshobbs Strip restart flag from app_user_pre_deploy_trigger
- #2931: @josegonzalez Upgrade git package for CI
- #2928: @silverfix Do not overwrite the VHOST file during installation if it exists
- #2926: @vtavernier Remove leading forward slash from app name in git-upload-pack
### New Features
- #2985: @bitmand Build a custom dhparam file once for nginx and include it as default
- #2974: @josegonzalez Upgrade to herokuish 0.3.33
- #2973: @josegonzalez Allow usage of git 2.13.0+ by unsetting GIT_QUARANTINE_PATH during git worktree usage
- #2971: @miraculixx Add support for older virtualbox versions in official Dokku Vagrantfile
- #2966: @znz Simplify internal config functions to reduce duplication
- #2751: @alexquick Move config plugin to golang
- #2938: @michaelshobbs Upgrade to golang 1.9.1
- #2736: @josegonzalez Implement Network Plugin
- #2929: @michaelshobbs Add codacy config and coverage targets
### Documentation
- #2935: @jcrben Document how to make herokuish optional during the bootstrap installation
- #2982: @agorf Correct typo in user management docs
- #2981: @agorf Correct typos in process management docs
- #2969: @znz Correct comments on network triggers
- #2965: @znz Remove spaces from config subcommand help output to mirror help output of other subcommands
- #2954: @mrname Add vernemq community datastore plugin to docs
- #2944: @axilleas Fix syntax typo in debian installation docs
- #2932: @znz Update code comment to match documentation
- #2933: @znz Fix version number for network binding documentation
- use a plugin trigger to see whether we should bind to all interfaces
- create a generic way of setting properties for a plugin
- migrate proxy-enabled to the new network property "bind-all-interfaces"
- add network:set subcommand
- Add proxy-build-config hook to rebuild network and proxy settings for an application
- Scope nginx:build-config to work only when it is the configured proxy for an application
- Refactor deploy code to interact with network plugin for computed and actual ipaddr/port settings
- Ensure the proxy-build-config plugin trigger is called on ps:restore
- Expose a few plugin triggers for retrieving networking information for a given APP/PROC_TYPE/CONTAINER_ID combination
Add forward slash cleanup of the app name for the git-upload-pack
command. Prevents is_valid_app_name from removing the application folder
on `git fetch`.
# History
## 0.10.5
### Bug Fixes
- #2912: @josegonzalez Add missing depends statement for rsyslog
- #2906: @manuel-colmenero Check the location of nginx in a central way
- #2895: @josegonzalez cd to app directory when calling git worktree add
### Documentation
- #2922: @axilleas Clarify the minimum Nginx version for HTTP/2 support
- #2919: @wootwoot1234 Update nginx documentation surrounding file uploading for php buildpack users
- #2913: @znz Fix a typo in the rpm release script
- #2910: @buckle2000 Add a note about using the full git url for non-compliant toolchains
You can now set b64encoded values. They are
stored decoded, this is so dokku over ssh can set
odd config values
```
config:set --encoded KEY=BASE_64_VALUE
```
still to do:
* Rework disk format to be okay with quotes
* Fix Dockerfile deployments
* Dedup code in the subcommands
* Add --encode
* Add deploytests for the new stuff
* Restore some log messages (should I make some helpers in common?)
* Restore some functions that may be used by 3d-party plugins
# History
## 0.10.4
### Bug Fixes
- #2894: @josegonzalez fix: bail if any step in the release process fails
- #2880: @josegonzalez fix: properly detect empty subcommands
- #2881: @josegonzalez Verify app name on git push
- #2858: @cstroe Use correct port number for the upstream.
- #2848: @josegonzalez Ensure https applications return an https url from `dokku url`
- #2839: @josegonzalez fix: skip clearing cache if we are not building a herokuish image
### New Features
- #2890: @michaelshobbs use circleci 2.0
- #2847: @scjody Add nginx ppa before installing Dokku
- #2850: @michaelshobbs add optional PROC_TYPE and CONTAINER_INDEX to docker-args-deploy plugn trigger
- #2840: @josegonzalez Add DYNO environment variable to run containers
- #2824: @josegonzalez Upgrade herokuish to version 0.3.31
### Documentation
- #2861: @adelq Use non-deprecated apps command
- #2878: @m0rth1um Add telegram notifications plugin
- #2876: @josegonzalez docs: clarify storage documentation caveats
- #2873: @josegonzalez docs: add a note on which docs to look at for customizing nginx docs
- #2867: @josegonzalez docs: cleanup help output for dokku shell
- #2859: @josegonzalez docs: use relative link for application deployment doc
- #2866: @josegonzalez Add missing migration guides
- #2863: @josegonzalez docs: fix syntax on getting started docs
- #2836: @fishnux Add a note regarding nginx dependency to installation docs
- #2834: @iansu Clarify port exposure in Dockerfile documentation
On hosts where python3 is the system default python env and there is a minimal server installation, Dokku will silently fail to return the values of json keys.
# History
## 0.10.0
### Bug Fixes
- #2820: @josegonzalez Require netcat in debian packaging
- #2774: @fruitl00p Include docker-options in the default `dokku`
- #2778: @zarqman Fix /etc/logrotate.d/dokku on debian
- #2747: @ebeigarts Update herokuish base image on updates using --pull
- #2739: @josegonzalez Use listener_port in nginx.conf.sigil
- #2735: @josegonzalez Ensure we can call ps:report without specifying an application
- #2733: @josegonzalez Add support for new docker package names
- #2730: @weyert Ignore the cache directory when cloning an app
- #2723: @weyert Call non-deprecated plugin:list method
### New Features
- #2803: @iSDP Adding related articles on the Docker Image Deployment page
- #2798: @znz Update CURL_CONNECT_TIMEOUT in docs
- #2795: @josegonzalez docs: Add documentation around adding build-time configuration variables
- #2791: @yazinsai Correct typo in persistent storage docs
- #2789: @h4ckninja Subject-verb agreement
- #2790: @flyinggrizzly Add entry for insecure connection issue in Rails
- #2788: @josegonzalez Flesh out uninstallation documentation
- #2784: @josegonzalez Document special dokku environment variables
- #2773: @znz Update year in footer [ci skip]
- #2768: @znz Ubuntu 12.04 is EOL
- #2769: @lucianopf Fix SlackButton for mobile devices.
- #2763: @ZiadSalah Update vagrant documentation for windows users
- #2764: @joshmanders Create PULL_REQUEST_TEMPLATE.md
- #2758: @AxelTheGerman Update doc location for dokku-git-rev community plugin
- #2757: @nodanaonlyzuul Fix typo from "To use a dockerfiles" to "To use a dockerfile" singular
- #2753: @abrkn Use short-hand method for shutting down all applications in upgrade docs
- #2746: @josegonzalez Add redirect for installation to advanced install docs
- #2738: @josegonzalez Add missing `NO_SSL_SERVER_NAME` to example template
- #2457: @john-doherty Update Digitalocean installation instructions
- #2725: @timaschew Fix typo in application management docs
- #2719: @joshco Clarify that nginx.conf.sigil must be committed to repository
- #2715: @josegonzalez Use urls that are linkable on github
### Documentation
- #2822: @josegonzalez refactor: allow skipping cleanup on a per-application basis
- #2754: @fzerorubigd Add support for set DOKKU_IMAGE per app
- #2815: @markstory Add stickler-ci configuration.
- #2809: @oliw Remove aufs step from Makefile
- #2785: @josegonzalez Add a release-plugin binary
- #2777: @stokarenko Turn on ps-post-stop hook.
- #2781: @fruitl00p Adds docker.io support
- #2766: @josegonzalez Upgrade to herokuish 0.3.29
- #2765: @josegonzalez Install python3-software-properties as an alternative to python-software-properties
- #2642: @chiedo Added better default nginx error pages
- #2678: @callahad Default to secure PCI-compliant SSL setup
- #2734: @josegonzalez Allow quieter report output
In talking with @josegonzalez, stickler-ci.com helps reduce the amount of
time maintainers spend reviewing code by automatically giving style
feedback as pull request comments.
I've added linters for shell scripts and go files based on the linting
I could find in the existing make files.
If an application is configured to enforce secure connections and SSL isn't configured for Dokku or the application, browsers will raise an Invalid Connection error.
Entry describes issue, a code resolution for Rails, and points users to the SSL docs.
This adds a table of environment variables that Dokku will use to change internal behavior.
Not all are fully documented/listed, but this should be enough to get people hacking.
[ci skip]
Herokuish update fails if existing herokuish is used by other containers,
using docker build --pull will force to update also the base image.
Setting up herokuish (0.3.28) ...
Removing old herokuish image
Failed to remove image (gliderlabs/herokuish): Error response from daemon: conflict: unable to remove repository reference "gliderlabs/herokuish" (must force) - container dbf2298ab5a5 is using its referenced image 7d4a8d661476
Importing herokuish into docker (around 5 minutes)
Docker has this thing where they rebrand the debian package name once a year, and as YUM doesn't resolve anything like a "Provides" field, this is the best we can do (unless they all required the same metapackage).
Note that now we can't ensure a specific minor docker version via RPM, though I feel as though if you choose a crappy OS/package manager and we fail you, thats on you, not Dokku.
Closes#2732
Developers can override this in a custom nginx.conf.sigil.
While it may be backwards incompatible - and will therefore require a minor release - it does make things much more secure.
# History
## 0.9.3
### Bug Fixes
- #2706: @josegonzalez fix: ensure nginx conf.d directory exists when running nginx install hook
- #2701: @scjody Set SSH_USER for root commands
### New Features
- #2708: @josegonzalez Document that we will not do buildpack support in the issue tracker
### Documentation
- #2709: @michaelshobbs increase CURL_TIMEOUT and CURL_CONNECT_TIMEOUT defaults
- #2699: @mbreit Add support for git >= 2.11
Git 2.11.0 breaks the git clone approach in git_build_app_repo() in
25ab004c53
git worktree is a much simpler approach but only works for git >= 2.5
so it is not available in Ubuntu 14.04.
Fixes#2512.
# History
## 0.9.2
### New Features
- #2698: @josegonzalez docs: Document that we only care about specific sections
- #2697: @callahad Restore installer note regarding AUFS on Linode
- #2694: @scjody Add documentation note re: git-pre-pull vs. auth
### Documentation
- #2695: @michaelshobbs add tests for pre/post deploy tasks
# History
## 0.9.0
### Bug Fixes
- #2691: @josegonzalez Fix package building when golang binaries are available
- #2671: @znz Fix variable name
- #2672: @callahad Fix logrotate on Debian
- #2666: @josegonzalez Use correct flag for build arguments when installing herokuish
- #2664: @pvalentim Fix remote name when using --remote option with apps:create
### New Features
- #2689: @mbreit Add dokku-monit to community plugin list
- #2683: @josegonzalez Ensure we have an example for adding keys as another user
- #2682: @josegonzalez Clarify supported stanzas in app.json
- #2679: @callahad Remove unnecessary Linode-specific instructions
- #2670: @znz Remove duplicated `(i.e. `
### Documentation
- #2685: @josegonzalez Pass shellcheck on os x
- #2677: @callahad Prefer HTTP2 to SPDY in nginx-vhosts
- #2673: @michaelshobbs Update to herokuish 0.3.27
- #2674: @michaelshobbs Update sshcommand to 0.7.0
- #2654: @ebeigarts Enable nginx and docker on system startup when using bootstrap.sh on CentOS
- #2546: @michaelshobbs Convert repo plugin to golang
- Requires docker, git, and package_cloud gems
- Requires the PACKAGECLOUD_API_TOKEN environment variable
- Builds both a deb and rpm, pushing both to packagecloud
- Upgrades the golang build environment to 1.7.5
- Combines both build Dockerfiles into a single, generic env
- Fixes issue where internal-functions file for tar plugin was not executable
- Ensures that built plugins have a callback to clean up their source files before packaging
- Adds support for “betafish” releases, which are untested versions of Dokku that are available via a separate packagecloud repository.
1. SPDY has been deprecated and removed from modern browsers:
http://caniuse.com/#feat=spdy
2. HTTP/2 is present in all modern browsers:
http://caniuse.com/#feat=http2
3. SPDY and HTTP/2 are mutually exclusive in port-based `listen` directives:
http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
Caniuse suggests that 74% of global users have a browser that supports
HTTP/2, while only 27% have a browser that supports SPDY. Only IE11 and
Safari support both.
Therefore, when both are available, Dokku should choose HTTP/2 to
maximize the benefit to users.
This trigger allows you to modify the contents of an application *after* it has been extracted from git/tarball but *before* the image source type is detected. For example, you may wish to autogenerate a Dockerfile based on some other application contents before detecting what type of build process - herokuish or docker file - to use.
[ci skip]
Linode now supports KVM virtualization on all VMs by default. So, this verbiage was completely removed.
GRUB 2 is now one of the default options in the Kernel Menu. The additional Ubuntu packages are no longer required. Wording changed to reflect updated instructions.
Inject http proxy envvars to docker build command to allow package installation behind corporate proxies.
These envvars (http_proxy and https_proxy) are standard, and usually configured via system-wide /etc/profile.d files.
In cases where these envvars are not configured, the additions appear to be mute and non-destructive.
Application cloning can be used to setup review applications based on an existing application. This is useful in CI/CD pipelines where a developer may wish to verify code in a custom environment without overwriting a shared staging environment.
- Respect the --app flag
- Respect the --trace flag
- Skip the second argument after both --app and --remote flags
- The `--global` flag should be set as is when specified after a “valid” command
- Fix issues when checking if the --app flag should be passed via ssh
- Use APP as the variable name for the current app
`SSL_SERVER_NAME` should contain items found in the ssl certs
(E.G. CommonName and AltNames), but not already in the `NOSSL_SERVER_NAME`
list. That will avoid the dups in the `nginx.conf` and kill the warning
initially cited in dokku/dokku#2474
Certain versions of nginx have bugs that prevent HTTP/2 from properly responding to all clients, thus causing applications to be unavailable.
Closes#2435
Add new community plugin build hook.
This plugin provide a way for application to define scripts in their codebase to be executed before the project build (Dockerfile or Herokuish).
Use case :
A Java application with only an ADD of the generated fat jar in the Dockerfile.
The plugin allow the user to define a script to run the compilation before the docker build execution.
This is a proposed change for addressing GH #2446 "Adding a file with
two ssh-keys can result in an error" (see
https://github.com/dokku/dokku/issues/2446).
The following checks are performed:
- validity of key contents when read from a file
- key contents only contains one single line/key
- authorized_keys file is ultimately valid
The last test is an extension over the previous implementation in that
all lines in the file are checked.
The commit also includes extensions to the relevant test file to
excercise the new checks. It also takes care to save and then restore
the authorized_keys file.
Ref dokku/dokku-letsencrypt#76
Certificates provided by Let's Encrypt can have the domain provided in
the Subject Name field listed again in the Subject Alt Name fields,
leading to the same domain getting listed twice by get_ssl_hostnames()
that in turn leads to a duplicate server_name field in the nginx
configuration.
This patch adds a sort -u to ensure that every SSL hostname will only be
listed once.
Throughout the docs the app named `node-js-app` is used. An alternative app name, named `api` was used in this example. I propose an update for consistency.
I was working on a Dockerfile deploy that was setup to listen on port 8844. I wanted to add ssl and couldn't figure out why adding the ssl cert didn't making things 'just work'. Since the `proxy:ports-add` step I discuss in this commit is run both `under the hood` and `sometimes`, I thought it might be worth issuing a PR for.
The tags and tar plugins do not necessarily build from source, and running `ps:rebuild` can have some unexpected output in certain cases. Rather than try to handle that complexity - it's a lot - documenting the edge cases is the most appropriate way forward.
Given a user wants to manually override the `vhost_enable` debian config, a user has to specify both $DOKKU_VHOST_ENABLE and $VHOST_ENABLE. This patch makes it rely on $DOKKU_VHOST_ENABLE like the others which use the `$DOKKU_` prefix
As deployment tasks can fail due to non-dokku related issues, moving them to post-deploy will ensure that dokku does not accidentally orphan applications.
Closes#2367
Since they are separate resources, triggering the normal app creation flow makes the most sense.
We still remove the cache directory because we want the correct cache permissions for the new application.
All process manager functionality has been merged into the Dokku core:
- v0.3.14: `ps` plugin to manage process scaling
- v0.7.0: restart-policy handling by the ps plugin
Users are encouraged to stop installing old process managers and use the core functionality.
[ci skip]
- Simplify test location documentation
- Add documentation surrounding our existing CI environment
- Dedent items that shouldn't be in a list
[ci skip]
- Add missing "New as of" banner
- Ensure we list commands at the top
- Add reference to sshcommand
- Callout that the NAME must be unique
- Add an example for removing keys
[ci skip]
When configuring domains/ssl certificates, the port mappings for an application may be automatically set. This can cause issues for applications which will use non-standard ports - ie. for Dockerfile deploys.
[ci skip]
An application which has not been deployed will not have an image
available, and therefore attempting to remove an (empty) cache directory
will fail. Rather than checking for the image - which we should
still do, as not having an image for a deployed app is an error state -
we should instead only attempt the docker cache removal if the directory
cannot be removed via rmdir.
Closes#2294
Rather than removing all port mappings, we simply remap port 80 mappings to 443. The previous behavior would remove custom port mappings for all applications and reset them on any certificate change, preventing automation from plugins such as letsencrypt. While this behavior doesn't matter for buildpack deploys - which only expose a single port on container port 5000 - Dockerfile deploys would frequently be affected by such a change, requiring a remapping of all custom ports.
This commit also standardizes on the method used to source the proxy functions
Checks can be run in several ways:
- checks:run APP
- checks:run APP PROCESS_TYPE
- checks:run APP PROCESS_TYPE.CONTAINER_INDEX
This will reuse the existing checks infrastructure as defined by the checks plugin, and therefore if no checks file is defined, it will default to the normal Dokku container check.
Closes#2218
Edited the "unattended script" in the documentation so that apt-get
doesn't wait for input on the Dokku install.
modified: getting-started/install/debian.md
This hook will allow users to modify the repo in use for deployed applications. An example use case would be one where the image being deployed is from a remote docker registry where the `dokku` username is taken and the app will be deployed from a separate username.
- Ensure we document all commands being run
- Highlight that we are mapping the same port twice
- Clarify how dokku binds containers to listening interfaces
[ci skip]
Applications without a restart-policy will have their policies set to `on-failure:10`. Users can completely unset the restart-policy using the `docker-options` plugin, though this will be equivalent to setting it explicitly to `no`.
Restart policies must be explicitly set, and the following are all valid:
- no
- unless-stopped
- always
- on-failure
- on-failure:NUMBER
Fixesdokku/dokku-letsencrypt#67
Change the certs:add command to use a file import without trying to
detect a piped-in tarball if server.crt and server.key files were passed
in as arguments and those files exist.
Fixes hangs on certificate imports by filename when the check for a
STDIN pipe fails e.g. when running dokku remotely using a SSH command.
- note that the port changes on every deploy when the proxy is disabled
- make it clear that the proxy is being disabled for the app
- note that the nginx-vhosts plugin supports the proxy plugin mapping
- minor formatting changes
[ci skip]
This allows users to specify port 80 after an application has had domain added. Normally, when we first add an extra domain, the following tuple is added:
http:80:5000
A user might then want to remap port 80 to another port, such as port 8080:
dokku proxy:ports-add APP http:80:8080
The application would then have the following proxy map:
http:80:5000 http:80:8080
As nginx vhosts are resolved in FIFO order, the "correct" upstream of 8080 would basically be ignored. The workaround would be to remove the original port mapping, but the following:
dokku proxy:ports-remove APP 80
Would remove *both* entries and then re-add the default of `http:80:5000`. Thus it was not possible to use the porcelain to correct the port mapping and a user would have to fall back to using the following hack to fix their mapping:
dokku config:set APP DOKKU_PROXY_PORT_MAP='http:80:8080'
You can now use the previous syntax *as well as* the following to remove a port mapping:
dokku proxy:ports-remove APP http:80:5000
Newer versions of nginx drop spdy support in favor of http2, and thus the nginx config that we bundle with dokku causes nginx to fail to reload in certain cases. This change drops spdy support in favor of http2 for versions of nginx greater than 1.9.5.
Closes#2216
These are helper plugins that mimic the repo plugin: https://github.com/heroku/heroku-repo
The following commands will remain unimplemented:
- `clone`: not useful for the host client to clone
- `download`: currently not possible for us to "host" a tarball of the repo
- `reset`: we still store files in the repo (though we shouldn't) so we cannot easily reinitialize the repository.
Also fixes a potential race condition if two separate processes create an application's `$CACHE_DIR`.
Closes#1570
In at least one case a customer of ours added a domain including
a schema, as in “http://domain.tld/”. That is obviously incorrect, but
then they couldn't remove it using the dokku command:
$ dokku domains:remove app7 http://domain.tld/
sed: -e expression #1, char 9: unknown command: `/'
This patch changes the sed command to use the "\CregexpC" syntax. The
character used is a vertical pipe, which is far less likely to be used
in a URL. After the change:
$ dokku domains:remove app7 http://domain.tld/
-----> Removed http://domain.tld/ from app7
Signed-off-by: Michael Hanselmann <hansmi@vshn.ch>
When rebooting a Dokku host the init process tries to restore all apps
using `dokku ps:restore`, alphabetically. If an app is defined but not
deployed, the function `ps_start` called by `dokku ps:restore` will
exit 0 and stop trying to restore the other apps later in the alphabet.
This change fixes the restore behaviour.
Currently we exit when trying to add a duplicated domain, even if we give a list
of domain names. This behaviour is not as it suppose to work.
**Expected behaviour**
When adding a domain, and the domain already exists, just skip that domain, and
continue with the world. This is no problem since we are already in the state we
want to be in.
**New behaviour**
When you try to add a domain that is already added, we notify the user of this
by showing a log message: `Skipping: example.com already added to example app`,
and then we continue with the list of domain names.
Fixes#2165
Clearly stress the fact, that there are more steps than only running the bash commands. You also have to navigate to the website and finish the configuration.
- unified css between home and template layouts
- use same version of bootstrap everywhere
- add our cute whale sushi logo to the homepage
- use fewer styles
- add a better installation section to point out different installation methods
- add navigation bar items
[ci skip]
- Tone down "new as of version" boxes
- Replace all "New as of 0.5" with "yet to be released" text
- Use strong red only for "yet to be released" boxes
Fixes#1989
- Briefly cover sshcommand internals
- Show several examples for using sshcommand
- Split out docs onto a new page and relink to it where necessary
- Refer to user-auth plugin trigger for scoping commands to specific users.
[ci skip]
This will allow a user to browse the documentation as it was at any point in time. In doing so, this allows us to more easily deprecate/remove features without worrying about having to duplicate old documentation in the future.
[ci skip]
- Refer to checks plugin in zero-downtime deploy link
- Refer to cron in one off processes link
- Add an "Advanced Usage" section
- Add links to proxy management and deployment tasks
- Move container options and persistent storage to advanced usage
[ci skip]
This change sets a DOKKU_APP_NAME env var, which can be used by plugins as a replacement for the `app` param if specified. Note that each plugin will have to manually shift it's arguments if necessary
* fix rsyslog handling
* don't hardcode dokku path
* add documentation for ArchLinux package build
* add vagrant machine to run the ArchLinux specific steps
* add step in release process for ArchLinux
* enhance docs for easy ArchLinux steps
This pr makes it slightly easier to support dockerfile installations
- "simplifies" the bootstrap process by dividing it into distinct chunks
- Allows specifying `--no-install-recommends` when a dockerfile installation is detected
- Uses functions everywhere
- Removes global variables where possible
- Fixes shellcheck issues
- Allows specifying debconf via the command-line
[ci skip]
There are cases where we don't want the check for keyfile, this will add a
config option, that allows you to skip this particular check.
Fixes#1851
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
OSX creates hidden files: `./._server.key` and `./._server.crt`. The Dokku cert
plugin is choking on those files. We should probably just ignore them, and go on
with our lives
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
I was running into issues with the IP addresses, and it seems
that it's using an incorrect/outdated syntax for retrieving
the container's IP Address. In multi-host networking
`NetworkSettings.IPAddress` is empty.
The docker documentation at https://docs.docker.com/engine/reference/commandline/inspect/
uses a different syntax which I've tested to work both on multi-host and
standard bridge networking.
If you're interested in the other issues and the work/hacks I've been doing related
to #1795, let me know. In the meantime, I think this fix is needed.
- remove deployed applications during dpkg purge
- disable all core plugins during dpkg purge
- ensure init files are removed
- ensure motd is removed
- remove all core plugins, dokku config files (including tls/sshcommand entries etc.) during purge
- remove all empty directories and broken symlinks in the DOKKU_ROOT and DOKKU_LIB_ROOT directories during purge
Note that we do not delete the dokku user itself as there might be other data we don't know about in this directory.
We previously assumed that systemd was detectable by the existence of certain directories. Unfortunately, it seems 14.04 already has these directories, so we need to handle this case separately.
One other note is that dokku-installer will fail to "start" if already started on certain systems, thus the previous grep was more accurate in it's running.
- Use the nginx.conf file's existence as a check for whether we should start the service or not
- Create the init files with the dokku-installer.py file. This adds actual systemd support.
- Also ensure we *always* start the service, regardless of it's status. This fixes an issue with processing systemd output
Fixes the following warning:
```
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 6 package 'dokku':
`Depends' field, reference to `lxc-docker':
`>' is obsolete, use `>=' or `>>' instead
```
Refs #1776
The python version should allow us to remove any ruby dependencies and should also slightly speed up dokku installation. All LSB-compliant distributions should have python, so we should be okay depending upon it.
Closes#1783Closes#1786
It's not possible to checkout a specific commit into a new repository
using ``git fetch`` and so a temporary tag is added to the host
repository, then fetched.
This adds a hook that will send in the $APP, action name and config vars.
By adding this, we allow plugin creators to handle this kind of events as well.
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
The version of docker.io in jessie-backports is 1.6.2~dfsg1-1~bpo8+1.
This is regarded as lower than 1.6.2 by dpkg because `~` has a special meaning
in regards to version sort in dpkg.
This leads to:
```
The following packages have unmet dependencies:
dokku : Depends: docker-engine-cs but it is not installable or
docker-engine but it is not installable or
lxc-docker (>= 1.6.2) but it is not installable or
docker.io (>= 1.6.2) but 1.6.2~dfsg1-1~bpo8+1 is to be installed
Recommends: herokuish but it is not going to be installed
```
By changing the contraints the version in backports will be accepted by dpkg.
Add this point you only get information that "something" happend on the given
hook. By adding more information to the hook, plugin creators can do more
interesting stuff.
* The first params remains the $APP name (to maintain backwards compatability)
* The second params sends in the action that happend, for domain this can be:
"add", "clear" or "remove"
* The third param sends in the argument that was passed to the original
function, for domain that would be a list of all the domains that was given.
One reason this addition would be great for plugin owners, is that when you have
a web tool over Dokku, and someone creates a domain over the CLI, we a plugin
can send back information about the event to the webapp over an API. That way
the webapp is always up-to-date with the Dokku installation.
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
In order to be one step closer to lintian compliance, lets remove the shebang
from this file so it doesn;t have to be executable
See #1641
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
Changing the herokuish package to Recommends instead of Depends allows users to skip the installation of that package by specifying --no-install-recommends. Herokuish will still be installed by default using apt-get
Adds unit test for new apps:rename function.
Add example in the docs for new apps:rename function.
Add apps:rename command to help command.
Delete cache directory before copying old app directory to new app directory.
deploy_app instead of create_app for apps:rename testing.
Change app url to match new name. Fix unit tests.
Add some more tests, plugn triggers.
As of 15.10, we are graced with a relatively recent version of nginx, and thus no longer need access to the ppa. Assuming this is the only such issue, this should also allow us to support Ubuntu 16.04 without any future changes.
I have created a plugin for installing a specific library that is not working properly when installed using dokku-apt.
It took me a lot of time to figure out how to properly install it and therefore I wanted to share it.
- Add note to avoid problems with shared volumes permissions
- Restructure the doc to help comprehension
- Make command examples consistent
- Improve wording in some places
- Advanced usage: remove "avoid if possible". It made little sense.
- docker (project) --> Docker
- dokku (project) --> Dokku
- dokku (command) --> `dokku`
- add `shell` to code blocks
This should consolidate a lot of knowledge around how dokku deals with buildpacks, as well as clears up a few misconceptions - mainly that dokku doesn't support multiple/custom buildpacks.
By bringing this information front-and-center, we can avoid a lot of questions by users trying to use dokku.
[ci skip]
This plugin trigger should allow users to pair down the available commands for a given user. While this does not affect help output - or any output at all - this is a good first step in allowing administrative access to certain commands while still allowing users to deploy/manage given applications.
Note that because of how dokku works, all parsing of commands must be done within the pluginhook, and we cannot give visibility into the actual command or application that will be affected by a given run.
* Bump `Version` field.
* Set minimum nginx version to 1.4.6, per #1654
* Depend on both `rubygem-foo` (Ubuntu) and `ruby-foo` (Debian).
* Add distro-default `docker.io (>= 1.6.2)` as an alternative.
Version 1.6.2 is in both `trusty-updates` and `jessie-backports`,
while `trusty` itself has `0.9.1`. We seriously want to avoid that.
This also updates the docs so people don't forget to bump the version
field in the future. Even though we really do that for them with sed.
In this case, Bats sets $status, $output, and $lines, but ShellCheck
doesn't statically know that. Therefore, we ignore SC2154 when those
variables are first introduced in ./tests/unit/test_helper.bash
https://github.com/koalaman/shellcheck/wiki/SC2154
New version of the logs plugin broke compatibility (as reported in #1534).
So options have been added to handle display:
* -t/--tail to tail logs (already existed)
* -n/--num NUM to display only this number of lines
* -p/--ps PS to display logs only from provided process
* -q/--quiet to display raw logs without color, time and names
This should close#1534
Which is quite useful in some situations, for example when you want each app to point to a DB with the same name as the app (reducing the amount of app-specific config).
I've not yet tested with 0.4.x but asap we upgrade our environment I'll ensure it's compatible (should be super simple since it's a super simple plugin).
This ensures that we can call apt-get update after adding a new apt source. Debian needs a bit more time to refresh it's own caches, so we just force it's cache to be clean before calling apt-get update again.
This package is the version we use for as a dokku dependency, and thus there is no need to specify a *specific* version when building the deb packages.
Refs #976
Blockquote elements that call out a new feature are given a "pink" background, whereas all others are given a "blue" background. This is to help avoid cases where users expect a feature to work for their version when they are several versions behind when a feature was introduced.
Fixes#1495
Log user name and fingerprint in events
Clarify bootstrap installation documentation
We actually have the reverse situation where the bootstrap.sh uses the web installer by default.
[ci skip]
dokku-apt compatibility
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Fix for issue #1487:
Created a separated VM environments for developers and users.
Adjusting space
Clarify bootstrap installation documentation
We actually have the reverse situation where the bootstrap.sh uses the web installer by default.
[ci skip]
dokku-apt compatibility
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Fix for issue #1487:
Created a separated VM environments for developers and users.
Changing default to linux users
Making dokku the default
Adjusting space
2015-09-27 23:43:20 -07:00
847 changed files with 41996 additions and 7800 deletions
> If you're using Dokku - especially for commercial purposes - consider donating to project development via [OpenCollective](https://opencollective.com/dokku) or [Patreon](https://www.patreon.com/dokku). Funds go to general development, support, and infrastructure costs.
>
> If you need help figuring out how to use a specific buildpack, or are having issues using multiple buildpacks, please see our [irc or slack channels](http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/#the-irc-and-slack-channels). Issues pertaining to buildpacks may be closed and locked.
## Description of problem
### How reproducible
### Steps to Reproduce
1.
2.
3.
#### Actual Results
#### Expected Results
## Environment Information
### `dokku report APP_NAME` output
> This is required! Issues missing this information may be closed.
>
> For problems affecting all applications, the report output for a broken application is useful for our debugging.
> You may also 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):
- 0.13.0+: `dokku inspect APP_NAME`
- <0.13.0: `docker inspect CONTAINER_ID`: WARNING, `docker inspect` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX.
- Link to the exact repository being deployed (if possible/applicable):
- If a deploy is failing or behaving unexpectedly:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- If using buildpacks, which custom buildpacks are in use
- If using a `Dockerfile`, the contents of that file
- If it exists, the contents of your `Procfile`.
- Output of failing Dokku commands after running `dokku trace on`
(BEWARE: `trace on` will print environment variables for some commands, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXXX):
[View the docs for upgrading](http://progrium.viewdocs.io/dokku/upgrading) from an older version of Dokku.
## Documentation
Full documentation - including advanced installation docs - are available online at [docs](http://progrium.viewdocs.io/dokku/)
## Support
You can use [Github Issues](https://github.com/progrium/dokku/issues), check [Troubleshooting](http://progrium.viewdocs.io/dokku/troubleshooting) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku)
## Contribution
After checking [Github Issues](https://github.com/progrium/dokku/issues), the [Troubleshooting Guide](http://progrium.viewdocs.io/dokku/troubleshooting) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
While we may not merge your PR as is, they serve to start conversations and improve the general dokku experience for all users.
Docker powered mini-Heroku. The smallest PaaS implementation you've ever seen.
## Sponsors
Dokku is currently sponsored by the enterprise grade, multi-host PaaS project [Deis](http://deis.io/).
See our list of past sponsors in the [SPONSORS](https://github.com/dokku/dokku/blob/master/SPONSORS.md) file.
Become a sponsor and get your logo on our README on Github with a link to your site. [[Become a sponsor](https://opencollective.com/dokku#sponsor)]
You can then proceed to the ip address or domain name associated with your server to complete the web-based installation.
If you wish for a more unattended installation method, see [these](http://dokku.viewdocs.io/dokku/getting-started/install/debian/#unattended-installation) docs.
### Upgrade
[View the docs](http://dokku.viewdocs.io/dokku/getting-started/upgrading/) for upgrading from an older version of Dokku.
## Documentation
Full documentation - including advanced installation docs - are available online at [http://dokku.viewdocs.io/dokku/](http://dokku.viewdocs.io/dokku/).
## Support
You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](http://dokku.viewdocs.io/dokku/getting-started/troubleshooting/) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku).
## Contribution
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](http://dokku.viewdocs.io/dokku/getting-started/troubleshooting/) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
While we may not merge your PR as is, they serve to start conversations and improve the general Dokku experience for all users.
<strong>Warning:</strong> The SSH key filled out here can grant root access to the server. Please complete the setup as soon as possible.
</div>
<div class="row">
<div class="col">
<h3>Admin Access</h3>
<div class="form-group">
<label for="key">Public SSH Keys</label><br />
<textarea class="form-control" name="keys" rows="5" id="key" placeholder="Begins with 'ssh-rsa', 'ssh-dss', 'ssh-ed25519', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-nistp384', or 'ecdsa-sha2-nistp521'">{ADMIN_KEYS}</textarea>
<small class="form-text text-muted">Public keys allow users to ssh onto the server as the <code>dokku</code> user, as well as remotely execute Dokku commands. They are currently auto-populated from: <code>{AUTHORIZED_KEYS_LOCATION}</code>, and can be changed later via the <a href="http://dokku.viewdocs.io/dokku/deployment/user-management/" target="_blank"><code>dokku ssh-keys</code></a> plugin.</small>
</div>
</div>
</div>
<div class="row">
<div class="col">
<h3>Hostname Configuration</h3>
<div class="form-group">
<label for="hostname">Hostname</label>
<input class="form-control" type="text" id="hostname" name="hostname" value="{HOSTNAME}" placeholder="A hostname or ip address such as {HOSTNAME}" />
<small class="form-text text-muted">This will be used as the default host for all applications, and can be changed later via the <a href="http://dokku.viewdocs.io/dokku/configuration/domains/" target="_blank"><code>dokku domains:set-global</code></a> command.</small>
<label class="form-check-label" for="vhost">Use virtualhost naming for apps</label>
<small class="form-text text-muted">When enabled, Nginx will be run on port 80 and proxy requests to apps based on hostname.</small>
<small class="form-text text-muted">When disabled, a specific port will be setup for each application on first deploy, and requests to that port will be proxied to the relevant app.</small>
<label><input id="vhost" name="vhost" type="checkbox" value="true"> Use <abbr title="Nginx will be run on port 80 and backend to your apps based on hostname">virtualhost naming</abbr> for apps</label>
# <UDF name="hostname" default="" label="Hostname for dokku instance" example="example.com">
# <UDF name="ssh_key" default="" label="Public SSH Key for root user" example="Sets the root user's public ssh key, which is also automatically imported into the dokku installer">
# <UDF name="notify_email" default="" Label="Send Finish Notification To" example="Email address to send notification to when finished." />
logit(){
# Simple logging function that prepends an easy-to-find marker '=> ' and a timestamp to a message
TIMESTAMP=$(date -u +'%m/%d %H:%M:%S')
MSG="=> ${TIMESTAMP}$1"
echo${MSG}
}
set_ssh_key(){
if[[ -n "${SSH_KEY}"]];then
logit "Setting root ssh key"
mkdir -p /root/.ssh
chmod 700 /root/.ssh
echo"$SSH_KEY" > /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh
fi
}
set_passwordless_ssh(){
logit "Turn off password authentication and root login for SSH"
#/usr/sbin/postconf -e "local_transport = error:local delivery is disabled"
touch /tmp/restart-postfix
}
notify_install_via_email(){
if[[ -n "${NOTIFY_EMAIL}"]];then
logit "Sending notification email to ${NOTIFY_EMAIL}"
/usr/sbin/sendmail "${NOTIFY_EMAIL}"<<EOD
To: ${NOTIFY_EMAIL}
Subject: Dokku installation is complete
From: Dokku StackScript <no-reply@${HOSTNAME}>
Your Dokku installation is complete and now ready to be configured: http://$(system_primary_ip) . Please visit this url to complete the setup of your Dokku instance.
Enjoy using Dokku!
EOD
fi
}
notify_restart_via_email(){
if[[ -n "${NOTIFY_EMAIL}"]];then
logit "Sending notification email to ${NOTIFY_EMAIL} of required restart"
Then click "Edit" next to the selected configuration profile and make the following changes:
- Change the "Kernel" option to the current "pv-grub" release
- Set the "Distro helper" option to "no"
Then save your changes. Next, reboot the instance from the Linode Dashboard. You'll receive an email once the instance is available to continue the dokku installation.
If you plan on developing dokku, the easiest way to install from your own repository is cloning the repository and calling the install script. Example:
The `Makefile` allows source URLs to be overridden to include customizations from your own repositories. The `DOCKER_URL`, `PLUGN_URL`, `SSHCOMMAND_URL` and `STACK_URL` environment variables may be set to override the defaults (see the `Makefile` for how these apply). Example:
```shell
sudo SSHCOMMAND_URL=https://raw.githubusercontent.com/yourusername/sshcommand/master/sshcommand make install
```
## Bootstrap a server from your own repository
The bootstrap script allows the dokku repository URL to be overridden to bootstrap a host from your own clone of dokku using the `DOKKU_REPO` environment variable. Example:
Dokku ships with a pre-built version of version of the [herokuish](https://github.com/gliderlabs/herokuish) component by default. If you want to build your own version you can specify that with an env variable.
```shell
git clone https://github.com/progrium/dokku.git
cd dokku
sudo BUILD_STACK=trueSTACK_URL=https://github.com/gliderlabs/herokuish.git make install
```
## Configuring
Once dokku is installed, if you are not using the web-installer, you'll want to configure a the virtualhost setup as well as the push user. If you do not, your installation will be considered incomplete and you will not be able to deploy applications.
Set up a domain and a wildcard domain pointing to that host. Make sure `/home/dokku/VHOST` is set to this domain. By default it's set to whatever hostname the host has. This file is only created if the hostname can be resolved by dig (`dig +short $(hostname -f)`). Otherwise you have to create the file manually and set it to your preferred domain. If this file still is not present when you push your app, dokku will publish the app with a port number (i.e. `http://example.com:49154` - note the missing subdomain).
You'll have to add a public key associated with a username by doing something like this from your local machine:
If you are using the vagrant installation, you can use the following command to add your public key to dokku:
$ cat ~/.ssh/id_rsa.pub | make vagrant-acl-add
That's it!
## VMs with less than 1GB of memory
Having less than 1GB of system memory available for dokku and its containers, for example Digital Ocean's small 512MB machines, might result in unexpected errors, such as **! [remote rejected] master -> master (pre-receive hook declined)** during installation of NPM dependencies (https://github.com/npm/npm/issues/3867).
To work around this issue, it might suffice to augment the linux swap file size to a maximum of twice the physical memory size.
To resize the swap file of a 512MB machine to 1GB, follow these steps while in SSH within your machine:
> The backup plugin was deprecated in 0.4.x, below are backup recommendations for 0.5.x and later.
## Backup and Migration Tutorial
Because Dokku is git based, rebuilding a deployed app is as easy as pushing from git. You can push to a new server by updating the `dokku` remote in you local app's repo.
```shell
git remote rm dokku
git remote add dokku dokku@[dokku.me:dokku.me]
git push dokku [master]
```
## Databases
Some plugins, like the official [dokku-postgres](https://github.com/dokku/dokku-postgres) plugin, have built-in commands that allow non-volatile data be exported and imported.
For [dokku-postgres](https://github.com/dokku/dokku-postgres), use:
```shell
dokku postgres:export [db_name] > [db_name].dump
dokku postgres:import [db_name] < [db_name].dump
```
## Volumes and Static Assets
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) limit on apps, but it's best practice to keep binary assets outside of git. Since containers are considered volatile in Dokku, external stores like s3 or storage mounts should be used for non-volatile items like user uploads. The Dokku storage core plugin can be used to mount local directories / volumes inside the docker container.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more details.
## Disaster Recovery
The best plan for disaster recovery is to always keep multiple (remote) copies of your local repo, static assets and periodic database dumps. In case of an emergency when your git repo and backups are completely lost, you can recover the last pushed copy from your remote Dokku server (assuming you still have the ssh key).
Sometimes you need to run a command on at deployment time, but before an app is completely deployed. Common use cases include:
* Checking a database is initialized
* Running database migrations
* Any commands required to set up the server (e.g. something like a Django `collectstatic`)
To support this, Dokku provides support for a special `release` command within your app's `Procfile`, as well as a special `scripts.dokku` key inside of your app's `app.json` file. Be aware that all commands are run within the context of the built docker image - no commands affect the host unless there are volume mounts attached to your app.
Each "phase" has different expectations and limitations:
-`app.json`: `scripts.dokku.predeploy`
- When to use: This should be used if your app does not support arbitrary build commands and you need to make changes to the built image.
- Are changes committed to the image at this phase: Yes
- Example use-cases
- Bundling assets in a slightly different way
- Installing a custom package from source or copying a binary into place
-`app.json`: `scripts.dokku.postdeploy`
- When to use: This should be used in conjunction with external systems to signal the completion of your deploy.
- Are changes committed to the image at this phase: No
- Example use-cases
- Notifying slack that your app is deployed
- Coordinating traffic routing with a central load balancer
-`Procfile`: `release`
- When to use: This should be used in conjunction with external systems to signal the completion of your app image build.
- Are changes committed to the image at this phase: No
- Example use-cases
- Sending CSS, JS, and other assets from your app’s slug to a CDN or S3 bucket
- Priming or invalidating cache stores
- Running database migrations
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.
## `app.json` deployment tasks
Dokku provides limited support for the `app.json` manifest from Heroku (documentation available [here](https://devcenter.heroku.com/articles/app-json-schema)). The keys available for use with Deployment Tasks are:
-`scripts.dokku.predeploy`: This is run _after_ an app's docker image is built, but _before_ any containers are scheduled. Changes made to your image are committed at this phase.
-`scripts.dokku.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are *not* committed at this phase.
For buildpack-based deployments, the location of the `app.json` file should be at the root of your repository. Dockerfile-based app deploys should have the `app.json` in the configured `WORKDIR` directory; otherwise Dokku defaults to the buildpack app behavior of looking in `/app`.
> Warning: Any failed `app.json` deployment task will fail the deploy. In the case of either phase, a failure will not affect any running containers.
The following is an example `app.json` file. Please note that only the `scripts.dokku.predeploy` and `scripts.dokku.postdeploy` tasks are supported by Dokku at this time. All other fields will be ignored and can be omitted.
The `Procfile` also supports a special `release` command which acts in a similar way to the [Heroku Release Phase](https://devcenter.heroku.com/articles/release-phase). This command is executed _after_ an app's docker image is built, but _before_ any containers are scheduled. This is also run _after_ any command executed by `scripts.dokku.predeploy`.
To use the `release` command, simply add a `release` stanza to your Procfile.
dokku docker-options:add node-js-app run "-v /var/log/node-js-app:/app/logs"
```
> Note: When [mounting a host directory](https://docs.docker.com/engine/reference/run/#volume-shared-filesystems) in a Dokku app you should first create that directory as user `dokku` and then mount the directory under `/app` in the container using `docker-options` as above. Otherwise the app will lack write permission in the directory.
### Remove a Docker option
```shell
dokku docker-options:remove node-js-app run "-v /var/log/node-js-app:/app/logs"
```
### Displaying docker-options reports for an app
> New as of 0.8.1
You can get a report about the app's docker-options status using the `docker-options:report` command:
Docker provides an _events_ command to show system's real time events. Likewise, Dokku can record events as syslog entries and also provides a plugin to display the last ones.
```
events [-t] Show the last events (-t follows)
events:list List logged events
events:on Enable events logger
events:off Disable events logger
events [-t] # Show the last events (-t follows)
events:list # List logged events
events:on # Enable events logger
events:off # Disable events logger
```
## Usage
Enable the plugin:
```shell
dokku events:on
```
```
$ dokku events:on
Enabling dokku events logger
```
Dokku will then write log entries to ``/var/log/syslog`` as well as a Dokku-specific logs sub-directory ``/var/log/dokku/events.log``, which can be easily displayed with the command `dokku events`:
Dokku will then write log entries to `/var/log/syslog` as well as a Dokku-specific logs sub-directory `/var/log/dokku/events.log`, which can be easily displayed with the command `dokku events`:
The preferred method to mount external containers to a Dokku managed container, is to use the Dokku storage plugin.
```
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
```
> The storage plugin is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy/run phase.
The storage plugin supports the following mount points:
- explicit paths that exist on the host
- docker volumes
There are a few caveats to using the persistent storage plugin:
- Using implicit paths that do not exist are no longer supported, and actually deprecated in [Docker 1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0). When you specify a persistent storage mount, the host directory is **not** autocreated by either Dokku or Docker.
- We recommend using the directory `/var/lib/dokku/data/storage` directory as the root host path for mounts, and we create this on Dokku installation.
- Mounts are only available at run and deploy times, and you **must** redeploy (restart) an app to mount or unmount to an existing app's container.
- When a directory is mounted, any existing files within the container will be overwritten. If you are writing assets during the build process and then replace the directory with a mount, those files will no longer exist. This is a Docker limitation.
- Paths are mounted within the container at the root of the disk - `/` - and are **not** relative to `/app` (for buildpacks deploys) or the `WORKDIR` (for Dockerfile/Docker images).
- For applications using buildpack deploys, the host directory should be owned by the user and group id `32767`. This is due to how permissions within Herokuish - which builds the Docker images - works. For Dockerfile or Docker image deployments, please use the user and group id which corresponds to the one running the process within the container.
## Usage
This example demonstrates how to mount the recommended directory to `/storage` inside an application called `node-js-app`:
```shell
# we use a subdirectory inside of the host directory to scope it to just the app
Dokku will then mount the shared contents of `/var/lib/dokku/data/storage` to `/storage` inside the container.
Once you have mounted persistent storage, you will also need to restart the application. See the
[process scaling documentation](/docs/deployment/process-management.md) for more information.
```shell
dokku ps:restart app-name
```
A more complete workflow may require making a custom directory for your application and mounting it within your `/app/storage` directory instead. The mount point is *not* relative to your application's working directory, and is instead relative to the root of the container.
```shell
# creating storage for the app 'node-js-app'
mkdir -p /var/lib/dokku/data/storage/node-js-app
# ensure the proper user has access to this directory
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web applications, like user uploads or large binary assets like images, a directory outside the container should be mounted.
### Shared storage between containers
When scaling your app, you may require a common location to access shared assets between containers, a storage mount can be used in this situation.
### Shared storage across environments
Your app may be used in a cluster that requires containers or resources not running on the same host access your data. Mounting a shared file service (like S3FS or EFS) inside your container will give you great flexibility.
### Backing up
Your app may have services that are running in memory and need to be backed up locally (like a key store). Mount a non ephemeral storage mount will allow backups that are not lost when the app is shut down.
### Build phase
By default, Dokku will only bind storage mounts during the deploy and run phases. Under certain conditions, one might want to bind a storage mount during the build phase. This can be accomplished by using the `docker-options` plugin directly.
You cannot use mounted volumes during the build phase of a Dockerfile deploy. This is because Docker does not support volumes when executing `docker build`.
> Note: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
## Application User and Persistent Storage file ownership (buildpack apps only)
> New as of 0.7.1
By default, Dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
> NOTE: this user must exist in your herokuish image.
Additionally, 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.
plugin:disable <name> # Disable an installed plugin (third-party only)
plugin:enable <name> # Enable a previously disabled plugin
plugin:install [--core|git-url [--committish tag|branch|commit|--name custom-plugin-name]] # Optionally download git-url (with custom tag/committish) & run install trigger for active plugins (or only core ones)
plugin:install-dependencies [--core] # Run install-dependencies trigger for active plugins (or only core ones)
plugin:list # Print active plugins
plugin:uninstall <name> # Uninstall a plugin (third-party only)
plugin:update [name [committish]] # Optionally update named plugin from git (with custom tag/committish) & run update trigger for active plugins
```
```shell
# for 0.3.x
cd /var/lib/dokku/plugins
git clone <git url>
dokku plugins-install
```
> These commands require `root` permissions as the `install` and `install-dependencies` plugin triggers may utilize commands such as `apt-get`. For non-core plugins, please inspect those plugins before running the following command as `root` user.
## Usage
You can list all installed plugins using the `plugin` command:
```shell
dokku plugin
```
```
plugn: dev
00_dokku-standard 0.16.2 enabled dokku core standard plugin
Installing a plugin is easy as well using the `plugin:install` command. This command will also trigger the `install` pluginhook on all existing plugins.
You can also uninstall a third-party plugin using the `plugin:uninstall` command:
```shell
dokku plugin:uninstall postgres
```
```
-----> Plugin postgres uninstalled
```
Enabling or disabling a plugin can also be useful in cases where you are debugging whether a third-party plugin is causing issues in your Dokku installation:
```shell
dokku plugin:disable postgres
```
```
-----> Plugin postgres disabled
```
```shell
dokku plugin:enable postgres
```
```
-----> Plugin postgres enabled
```
Finally, you can update an installed third-party plugin. This should be done after any upgrades of Dokku as there may be changes in the internal api that require an update of how the plugin interfaces with Dokku.
repo:gc <app> # Runs 'git gc --aggressive' against the application's repo
repo:purge-cache <app> # Deletes the contents of the build cache stored in the repository
```
The repository plugin is meant to allow users to perform management commands against a repository.
## Usage
### Git Garbage Collection
This will run a git gc --aggressive against the applications repo. This is performed on the Dokku host, and not within an application container.
```shell
dokku repo:gc node-js-app
```
```
Counting objects: 396, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (365/365), done.
Writing objects: 100% (396/396), done.
Total 396 (delta 79), reused 315 (delta 0)
```
### Clearing Application cache
Building containers with buildpacks currently results in a persistent `cache` directory between deploys. If you need to clear this cache directory for any reason, you may do so by running the following shell command:
resource:limit [--process-type <process-type>] [RESOURCE_OPTS...] <app> # Limit resources for a given app/process-type combination
resource:limit-clear [--process-type <process-type>] <app> # Limit resources for a given app/process-type combination
resource:report [<app>] [<flag>] # Displays a resource report for one or more apps
resource:reserve [--process-type <process-type>] [RESOURCE_OPTS...] <app> # Reserve resources for a given app/process-type combination
resource:reserve-clear [--process-type <process-type>] <app> # Reserve resources for a given app/process-type combination
```
The resource plugin is meant to allow users to limit or reserve resources for a given app/process-type combination.
## Usage
By default, Dokku allows unlimited resource access to apps deployed on a server. In some cases, it may be desirable to limit this on a per-app or per-process-type basis. The `resource` plugin allows management of both resource "limits" and resource "reservations", where each resource request type has specific meaning to the scheduler in use for a given app.
> 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.
Valid resource options include:
-`--cpu`
-`--memory`
-`--memory-swap`
-`--network`
-`--network-ingress`
-`--network-egress`
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
### Resource Limits
When specified and supported, a resource limit will ensure that your app does not go _over_ the specified value. If this occurs, the underlying scheduler may either cap resource utilization, or it may decide to terminate and reschedule your process.
Resource limits may be set via the `resource:limit` command:
```shell
dokku resource:limit --memory 100 node-js-app
```
```
=====> Setting resource limits for node-js-app
memory: 100
```
Multiple resources can be limited in a single call:
=====> Setting resource limits for node-js-app (worker)
cpu: 100
memory: 100
```
#### Displaying Resource Limits
Running the `resource:limits` command without any flags will display the currently configured app reservation.
```shell
dokku resource:limits node-js-app
=====> resource limits node-js-app information
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
```
#### Global Resource Limits
By default, Dokku does not limit any resources, though these can be specified at the server level via the `--global` flag on the `resource:limit` command.
```shell
dokku resource:limit --global --memory 200
```
```
=====> Setting default resource limits
memory: 200
```
This may also be combined with the `--process-type` flag to set global limits on a process-type level:
```shell
dokku resource:limit --global --memory 150 --process-type web node-js-app
```
```
=====> Setting default resource limits (web)
memory: 150
```
#### Displaying Global Resource Limits
Running the `resource:limit` command with only the `--global` flag will display the currently configured default limits.
```shell
dokku resource:limit --global
```
```
=====> resource limits default information
cpu:
memory: 200
memory-swap:
network:
network-ingress:
network-egress:
```
This may also be combined with the `--process-type` flag to see global limits on a process-type level:
```shell
dokku resource:limit --global --process-type web
```
```
=====> resource limits default information (web)
cpu:
memory-swap:
memory: 150
network-egress:
network-ingress:
network:
```
#### Clearing Resource Limits
In cases where the values are incorrect - or there is no desire to limit resources - resource limits may be cleared using the `resource:limit-clear` command.
```shell
dokku resource:limit-clear node-js-app
```
```
-----> Clearing resource limit for node-js-app
```
Defaults can also be cleared by leaving the app unspecified.
```shell
dokku resource:limit-clear
```
```
-----> Clearing default resource limits
```
### Resource Reservations
When specified and supported, a resource reservation will ensure that your server has _at least_ the specified resources before placing a given app's process. If there a resource exhaustion, future rebuilds and deploys may fail.
Resource reservations may be set via the `resource:reserve` command:
```shell
dokku resource:reserve --memory 100 node-js-app
```
```
=====> Setting resource reservation for node-js-app
memory: 100
```
Multiple resources can be limited in a single call:
=====> Setting resource reservation for node-js-app (worker)
cpu: 100
memory: 100
```
#### Displaying Resource Reservations
Running the `resource:reserve` command without any flags will display the currently configured app reservation.
```shell
dokku resource:reserve node-js-app
=====> resource reservation node-js-app information
cpu: 100
memory: 100
memory-swap:
network:
network-ingress:
network-egress:
```
#### Global Resource Reservations
By default, Dokku does not reserve any resources, though these can be specified at the server level via the `--global` flag on the `resource:reserve` command.
```shell
dokku resource:reserve --global --memory 200
```
```
=====> Setting default resource reservation
memory: 200
```
This may also be combined with the `--process-type` flag to set global reservations on a process-type level:
```shell
dokku resource:reserve --global --memory 150 --process-type web node-js-app
```
```
=====> Setting default resource reservation (web)
memory: 150
```
#### Displaying Global Resource Reservations
Running the `resource:reserve` command with only the `--global` flag will display the currently configured default reservation.
```shell
dokku resource:reserve --global
```
```
=====> resource reservation default information
cpu:
memory: 200
memory-swap:
network:
network-ingress:
network-egress:
```
This may also be combined with the `--process-type` flag to see global reservations on a process-type level:
```shell
dokku resource:reserve --global --process-type web
```
```
=====> resource reservation default information (web)
cpu:
memory-swap:
memory: 150
network-egress:
network-ingress:
network:
```
#### Clearing Resource Reservations
In cases where the values are incorrect - or there is no desire to reserve resources - resource reservations may be cleared using the `resource:reserve-clear` command.
```shell
dokku resource:reserve-clear node-js-app
```
```
-----> Clearing resource reservation for node-js-app
```
Defaults can also be cleared by leaving the app unspecified.
```shell
dokku resource:reserve-clear
```
```
-----> Clearing default resource reservation
```
### Displaying resource reports for an app
You can get a report about the app's resource status using the `resource:report` command:
```shell
dokku resource:report
```
```
=====> node-js-app resource information
web limit cpu:
web limit memory: 1024
web limit memory swap: 0
web limit network: 10
web limit network ingress:
web limit network egress:
web reservation cpu:
web reservation memory: 512
web reservation memory swap:
web reservation network: 8
web reservation network ingress:
web reservation network egress:
=====> python-sample resource information
web limit cpu:
web limit memory:
web limit memory swap:
web limit network:
web limit network ingress:
web limit network egress:
web reservation cpu:
web reservation memory:
web reservation memory swap:
web reservation network:
web reservation network ingress:
web reservation network egress:
=====> ruby-sample resource information
web limit cpu:
web limit memory:
web limit memory swap:
web limit network:
web limit network ingress:
web limit network egress:
web reservation cpu:
web reservation memory:
web reservation memory swap:
web reservation network:
web reservation network ingress:
web reservation network egress:
```
You can run the command for a specific app also.
```shell
dokku resource:report node-js-app
```
```
=====> node-js-app resource information
web limit cpu:
web limit memory: 1024
web limit memory swap: 0
web limit network: 10
web limit network ingress:
web limit network egress:
web reservation cpu:
web reservation memory: 512
web reservation memory swap:
web reservation network: 8
web reservation network ingress:
web reservation network egress:
```
You can pass flags which will output only the value of the specific information you want. For example:
scheduler-docker-local:report [<app>] [<flag>] # Displays a scheduler-docker-local report for one or more apps
scheduler-docker-local:set <app> <key> (<value>) # Set or clear a scheduler-docker-local property for an app
```
> New as of 0.12.0
Dokku natively includes functionality to manage application lifecycles for a single server using the `scheduler-docker-local` plugin. It is the default scheduler, but as with all schedulers, it is set on a per-application basis. The scheduler can currently be overridden by running the following command:
As it is the default, unsetting the `DOCKER_SCHEDULER` config variable is also a valid way to reset the scheduler.
```shell
dokku config:unset node-js-app DOCKER_SCHEDULER
```
## Usage
### Disabling chown of persistent storage
The `scheduler-docker-local` plugin will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. You may disable this by running the following `scheduler-docker-local:set` command for your application:
This plugin implements various functionality through `plugn` triggers to integrate with Docker for running apps on a single server. The following functionality is supported by the `scheduler-docker-local` plugin.
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-logs-failed`
-`scheduler-logs`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
-`scheduler-tags-create`
-`scheduler-tags-destroy`
## Supported Resource Management Properties
The `docker-local` scheduler supports a minimal list of resource _limits_ and _reservations_. The following properties are supported:
### Resource Limits
- cpu: (docker option: `--cpus`), 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)
### Resource Reservations
- memory: (docker option: `--memory-reservation`) and should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
By default, Dokku will ship a PCI Compliant nginx configuration. For developers whose users are on older browsers or mobile devices, you may need to ship a custom `nginx.conf.sigil` to enable ciphers for older browsers.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
## Nginx Error Pages
We now ship with nicer error pages by default. You are free to customize your Dokku installation via a custom `nginx.conf.sigil` to change what error pages are displayed in different circumstances.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
- You can now **actually** disable zero-downtime deployments per-app and per-process-type
- Some config variables have been moved around
-`DOKKU_CHECKS_ENABLED` has been migrated to `DOKKU_CHECKS_SKIPPED`
-`DOKKU_CHECKS_DISABLED` is now a thing
- The values for the above can be a comma-separated list of process-types or the literal string `_all_`
- See the [updated `checks`](/docs/deployment/zero-downtime-deploys.md) docs for more info
## Proxy port mapping
- You can now configure host -> container proxy port mappings
- The UI is handled by the [proxy](/docs/advanced-usage/proxy-management.md) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
- Default port mappings
- buildpack apps will be set to `http:80:5000` and will also include `https:443:5000` if SSL is enabled.
- dockerfile apps with explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on each exposed port that proxies to the same port of the deployed application container.
- You may override this behavior with the [`proxy:ports-*` commands](/docs/advanced-usage/proxy-management.md) or by directly setting `DOKKU_PROXY_PORT_MAP` with the `config:set` command
- dockerfile apps without explicitly exposed ports will behave the same as a buildpack app
- NOTE: These defaults **are not** automatically changed on subsequent pushes and must be manipulated with the aforementioned commands
## Calling the `dokku` binary
- Plugins should *not* call the `dokku` binary directly. Clients using the `--app` argument are potentially broken, amongst others, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call Dokku internal functions. As a result, the following Dokku commands are no longer publicly exposed:
We should now properly handle file ownership for mounted directories. This was enhanced in 0.7.1. See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more details.
## Restart Policies
If you previously managed container restart policies via docker-options, these can now be managed natively via the built-in `ps` plugin. There is no migration necessary. See the [restart policy documentation](/docs/deployment/process-management.md#restart-policies) for more details.
## SSH Keys
Dokku now has an `ssh-keys` plugin that can be used to manage ssh keys for the `dokku` user on the host operating system. See the [user management documentation](/docs/deployment/user-management.md) for more details.
You can now set global and app domains via `domains:set` and `domains:set-global`. See the [domains documentation](/docs/configuration/domains/) for more details.
## Plugin Uninstallation
A new `uninstall` plugin trigger was introduced. This functionality may be in use for newer plugins, so be aware that older Dokku versions may require manual cleanup.
See the [uninstall trigger documentation](/docs/development/plugin-triggers/#uninstall) for implementation instructions.
## Deployment Tasks
Should a pre or post deployment task fail, we now fail the entire deploy.
## Nginx HTTP2 Support
Due to bugs in Nginx, the minimum version for HTTP2 is now 1.11.5.
There is an ongoing migration to rewrite Dokku in Golang. The reasons are beyond the scope of this document, but this may impact any patches you have for Dokku. As of 0.9.0, only the `repo` plugin is in Golang.
The following shall remain true, regardless of the state of our rewrite:
- You will be able to write custom plugins in any language.
- You will be able to enable or disable core plugins.
-`plugn` will continue to be used for executing plugin triggers.
- We will provide bash wrappers that can be sourced to execute core functionality that is implemented in golang.
Now you can deploy apps on your Dokku. Let's deploy the [Heroku Node.js sample app](https://github.com/heroku/node-js-sample). All you have to do is add a remote to name the app. It's created on-the-fly.
Dokku only supports deploying from its master branch, so if you'd like to deploy a different local branch use: ```git push dokku <local branch>:master```
Right now Herokuish supports buildpacks for Node.js, Ruby, Python, [and more](https://github.com/gliderlabs/herokuish#buildpacks).
Please check the documentation for your particular build pack as you may need to include configuration files (such as a Procfile) in your project root.
## Deploying to server over SSH
Pushing to the dokku remote may prompt you to input a password for the dokku user. It's preferable, however, to use key-based authentication, and you can add your public key to the dokku user's authorized_keys file with:
Dokku uses git locally (i.e. not a docker image) to build its own copy of your app repo, including submodules. This is done as the `dokku` user. Therefore, in order to deploy private git submodules, you'll need to drop your deploy key in `~dokku/.ssh` and potentially add github.com (or your VCS host key) into `~dokku/.ssh/known_hosts`. A decent test like this should help confirm you've done it correctly.
If buildpack detection isn't working well for you or you want to specify a custom buildpack for one repository you can create & commit a file in the root of your git repository named `.env` containing `export BUILDPACK_URL=<repository>` before pushing. This will tell herokuish to fetch the specified buildpack and use it instead of relying on the built-in buildpacks & their detection methods.
## Dockerfile deployment
Deployment of `Dockerfile` repos is supported as of v0.3.15. Simply place a Dockerfile in the root of your repo and push to dokku. If you are converting from a heroku/dokku buildpack deployment, ensure you are not setting `$BUILDPACK_URL` or including a `.buildpacks` file in the root of your repo.
By default, we will extract the first `EXPOSE` port and tell nginx to proxy your app to that port. Alternatively, you can set `$DOKKU_DOCKERFILE_PORT` in your app's dokku configuration.
By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base nodejs image, with the following `ENTRYPOINT`:
Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disable docker's image layer cache. Lastly, for more granular build control, you may also pass any `docker build` option to `docker`, by setting `$DOKKU_DOCKER_BUILD_OPTS`.
## Default vhost
You might notice the default vhost for Nginx will be one of the apps. If an app doesn't exist, it will use this vhost and it may be confusing for it to go to another app. You can create a default vhost using a configuration under `sites-enabled`. You just have to change one thing in the main nginx.conf:
Swap both conf.d include line and the sites-enabled include line. From:
```
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
```
to
```
include /etc/nginx/sites-enabled/*;
include /etc/nginx/conf.d/*.conf;
```
Alternatively, you may push an app to your dokku host with a name like "00-default". As long as it lists first in `ls /home/dokku/*/nginx.conf | head`, it will be used as the default nginx vhost.
## Deploying to subdomains
The name of remote repository is used as the name of application to be deployed, as for example above:
$ git remote add dokku dokku@dokku.me:node-js-app
$ git push dokku master
Is deployed to,
remote: -----> Application deployed:
remote: http://node-js-app.dokku.me
You can also specify fully qualified names, say `app.dokku.me`, as
So, after deployment the application will be available at,
remote: -----> Application deployed:
remote: http://app.dokku.me
This is in particular useful, then you want to deploy to root domain, as
$ git remote add dokku dokku@dokku.me:dokku.me
$ git push dokku master
... deployment ...
remote: -----> Application deployed:
remote: http://dokku.me
## Zero downtime deploy
Following a deploy, dokku will now wait `DOKKU_DEFAULT_CHECKS_WAIT` seconds (default: `10`), and if the container is still running, then route traffic to the new container.
This can be problematic for applications whose boot up time can vary and can lead to `502 Bad Gateway` errors.
Dokku provides a way to run a set of more precise checks against the new container, and only switch traffic over if all checks complete successfully.
To specify checks, add a `CHECKS` file to the root of your project directory. This is a text file with one line per check. Empty lines and lines starting with `#` are ignored.
A check is a relative URL and may be followed by expected content from the page, for example:
```
/about Our Amazing Team
```
Dokku will wait `DOKKU_CHECKS_WAIT` seconds (default: `5`) before running the checks to give server time to start. For shorter/longer wait, change the `DOKKU_CHECKS_WAIT` environment variable. This can also be overridden in the CHECKS file by setting WAIT=nn.
Dokku will wait `DOKKU_WAIT_TO_RETIRE` seconds (default: `60`) before stopping the old container such that no existing connections to it are dropped.
Dokku will retry the checks DOKKU_CHECKS_ATTEMPTS times until the checks are successful or DOKKU_CHECKS_ATTEMPTS is exceeded. In the latter case, the deployment is considered failed. This can be overridden in the CHECKS file by setting ATTEMPTS=nn.
Checks can be skipped entirely by setting `DOKKU_SKIP_ALL_CHECKS` to `true` either globally or per application. You can choose to skip only default checks by setting `DOKKU_SKIP_DEFAULT_CHECKS` to `true` either globally or per application.
See [checks-examples.md](checks-examples.md) for examples and output.
## Removing a deployed app
SSH onto the server, then execute:
```shell
dokku apps:destroy myapp
```
## Image tagging
The dokku tags plugin allows you to add docker image tags to the currently deployed app image for versioning and subsequent deployment.
```
tags <app> List all app image tags
tags:create <app> <tag> Add tag to latest running app image
tags:deploy <app> <tag> Deploy tagged app image
tags:destroy <app> <tag> Remove app image tag
```
Example:
```
root@dokku:~# dokku tags node-js-app
=====> Image tags for dokku/node-js-app
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
dokku/node-js-app latest 936a42f25901 About a minute ago 1.025 GB
Dokku is, at it's core, a docker container manager. Thus, it does not necessarily play well with other out-of-band processes interacting with the docker daemon. One thing to note as in [issue #1220](https://github.com/progrium/dokku/issues/1220), dokku executes a cleanup function prior to every deployment. This function removes all exited containers and all 'unattached' images.
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.