mirror of
https://github.com/dokku/dokku.git
synced 2025-12-14 19:17:41 +01:00
docs: update markdownlint rules for better formatting
This commit is contained in:
Jose Diaz-Gonzalez
27
.github/linters/.markdown-lint.yml
vendored
27
.github/linters/.markdown-lint.yml
vendored
@@ -8,3 +8,30 @@ MD013: false
|
||||
# Inline HTML
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md033
|
||||
MD033: false
|
||||
|
||||
# List indentation
|
||||
# 2 spaces breaks list formatting in mkdocs
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md007
|
||||
MD007:
|
||||
indent: 4
|
||||
|
||||
# Fenced code blocks should have a language specified
|
||||
# We use a second, un-languaged code block to denote the output
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md040
|
||||
MD040: false
|
||||
|
||||
# Blank line inside blockquote
|
||||
# This is typically done when a section has a "New as of" or "Warning" in addition to a note
|
||||
# May wish to take advantage of github-style admonitions
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md028
|
||||
MD028: false
|
||||
|
||||
# No duplicate headers
|
||||
# HISTORY.md has a ton of these
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md024
|
||||
MD024: false
|
||||
|
||||
# First line h1
|
||||
# The issue template doesn't have one
|
||||
# https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md041
|
||||
MD041: false
|
||||
|
||||
14
.github/workflows/lint.yml
vendored
14
.github/workflows/lint.yml
vendored
@@ -27,12 +27,16 @@ jobs:
|
||||
steps:
|
||||
- name: Clone
|
||||
uses: actions/checkout@v3
|
||||
- name: Run markdown-lint
|
||||
uses: avto-dev/markdown-lint@04d43ee9191307b50935a753da3b775ab695eceb
|
||||
# v1.5.0 => 04d43ee9191307b50935a753da3b775ab695eceb
|
||||
- name: Setup node
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
config: '.github/linters/.markdown-lint.yml'
|
||||
args: './README.md'
|
||||
node-version: '20'
|
||||
cache: 'npm'
|
||||
cache-dependency-path: '.github/workflows/lint.yml'
|
||||
- name: Install markdownlint-cli
|
||||
run: npm install -g markdownlint-cli@0.35.0
|
||||
- name: Run markdown-lint
|
||||
run: markdownlint -c .github/linters/.markdown-lint.yml *.md **/*.md
|
||||
|
||||
packer:
|
||||
name: packer
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@@ -11,3 +11,4 @@ test-results/
|
||||
stack.tgz
|
||||
tmp
|
||||
coverage.out
|
||||
site
|
||||
|
||||
@@ -19,11 +19,11 @@ a chance of keeping on top of things.
|
||||
- [Reporting Security Issues](#reporting-security-issues)
|
||||
- [Reporting Issues](#reporting-other-issues)
|
||||
- [Contributing](#contributing)
|
||||
- [Making Changes](#making-changes)
|
||||
- [Which branch to base the work](#which-branch-to-base-the-work)
|
||||
- [Submitting Changes](#submitting-changes)
|
||||
- [When will my change be merged?](#when-will-my-change-be-merged)
|
||||
- [Running tests locally](#running-tests-locally)
|
||||
- [Making Changes](#making-changes)
|
||||
- [Which branch to base the work](#which-branch-to-base-the-work)
|
||||
- [Submitting Changes](#submitting-changes)
|
||||
- [When will my change be merged?](#when-will-my-change-be-merged)
|
||||
- [Running tests locally](#running-tests-locally)
|
||||
- [Additional Resources](#additional-resources)
|
||||
|
||||
## Reporting security issues
|
||||
@@ -65,24 +65,24 @@ need to do
|
||||
|
||||
- Make sure you have a [GitHub account](https://github.com/signup/free).
|
||||
- Submit an [issue](https://github.com/dokku/dokku/issues), assuming one does not already exist.
|
||||
- Clearly describe the issue including steps to reproduce when it is a bug.
|
||||
- Make sure you fill in the earliest version that you know has the issue.
|
||||
- Clearly describe the issue including steps to reproduce when it is a bug.
|
||||
- Make sure you fill in the earliest version that you know has the issue.
|
||||
- Fork the repository on GitHub.
|
||||
|
||||
### Making Changes
|
||||
|
||||
- Create a topic branch from where you want to base your work.
|
||||
- This is usually the master branch.
|
||||
- Only target an existing branch if you are certain your fix must be on that
|
||||
branch.
|
||||
- To quickly create a topic branch based on master; `git checkout -b my_contribution origin/master`.
|
||||
It is best to avoid working directly on the `master` branch. Doing so will
|
||||
- This is usually the master branch.
|
||||
- Only target an existing branch if you are certain your fix must be on that
|
||||
branch.
|
||||
- To quickly create a topic branch based on master; `git checkout -b my_contribution origin/master`.
|
||||
It is best to avoid working directly on the `master` branch. Doing so will
|
||||
help avoid conflicts if you pull in updates from origin.
|
||||
- Make commits of logical units. Implementing a new function and calling it in
|
||||
another file constitute a single logical unit of work.
|
||||
- Before you make a pull request, squash your commits into logical units of work
|
||||
using `git rebase -i` and `git push -f`.
|
||||
- A majority of submissions should have a single commit, so if in doubt,
|
||||
- Before you make a pull request, squash your commits into logical units of work
|
||||
using `git rebase -i` and `git push -f`.
|
||||
- A majority of submissions should have a single commit, so if in doubt,
|
||||
squash your commits down to one commit.
|
||||
- Check for unnecessary whitespace with `git diff --check` before committing.
|
||||
- Use descriptive commit messages and reference the #issue number.
|
||||
@@ -92,7 +92,7 @@ need to do
|
||||
- Your work should apply the [Dokku coding standards](https://github.com/progrium/bashstyle)
|
||||
- Pull requests must be cleanly rebased on top of master without multiple branches
|
||||
mixed into the PR.
|
||||
- **Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
|
||||
- **Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
|
||||
feature branch to update your pull request rather than `merge master`.
|
||||
|
||||
### Which branch to base the work
|
||||
|
||||
82
HISTORY.md
82
HISTORY.md
@@ -374,7 +374,7 @@ sudo DOKKU_TAG=v0.30.4 bash bootstrap.sh
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- #5786: @obrienmd Detect id_ed25519.pub in git:public-key command
|
||||
- #5786: @obrienmd Detect id_ed25519.pub in git:public-key command
|
||||
- #5758: @josegonzalez Support pack-based images that do not have a Procfile
|
||||
|
||||
### New Features
|
||||
@@ -999,7 +999,7 @@ See the [0.28.0 migration guide](/docs/appendices/0.28.0-migration-guide.md) for
|
||||
|
||||
### New Features
|
||||
|
||||
- #5300: @josegonzalez Add the ability to disable the init process
|
||||
- #5300: @josegonzalez Add the ability to disable the init process
|
||||
- #5295: @josegonzalez Add an official caddy proxy implementation
|
||||
- #5293: @josegonzalez Add an official traefik proxy implementation
|
||||
- #5202: @josegonzalez Add builder-lambda plugin
|
||||
@@ -1063,7 +1063,7 @@ sudo DOKKU_TAG=v0.27.9 bash bootstrap.sh
|
||||
|
||||
### Other
|
||||
|
||||
- #5184: @yasoob New website. Closes #5175
|
||||
- #5184: @yasoob New website. Closes #5175
|
||||
- #5270: @dependabot[bot] chore(deps): bump werkzeug from 2.2.0 to 2.2.1 in /tests/apps/python-flask
|
||||
- #5265: @dependabot[bot] chore(deps): bump werkzeug from 2.1.2 to 2.2.0 in /tests/apps/python-flask
|
||||
- #5264: @dependabot[bot] chore(deps): bump sinatra from 2.2.1 to 2.2.2 in /tests/apps/ruby
|
||||
@@ -2736,7 +2736,7 @@ See the [0.22.0 migration guide](/docs/appendices/0.22.0-migration-guide.md) for
|
||||
|
||||
- #4160: @nerg4l Rewrite logs plugin in Go
|
||||
- #4149: @josegonzalez Rewrite ps plugin in golang
|
||||
- #4080: @hugopeixoto Stop using VHOST when listing app domains and urls
|
||||
- #4080: @hugopeixoto Stop using VHOST when listing app domains and urls
|
||||
- #4117: @josegonzalez Rewrite app-json plugin in golang
|
||||
- #4113: @josegonzalez Drop herokuish release code
|
||||
|
||||
@@ -3379,7 +3379,7 @@ sudo DOKKU_TAG=v0.19.1 bash bootstrap.sh
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- #3713: @josegonzalez Require nginx 1.13+ in order to enable tls1.3
|
||||
- #3713: @josegonzalez Require nginx 1.13+ in order to enable tls1.3
|
||||
|
||||
## 0.19.0
|
||||
|
||||
@@ -4745,7 +4745,7 @@ sudo DOKKU_TAG=v0.13.1 bash bootstrap.sh
|
||||
- #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. `
|
||||
- #2670: @znz Remove duplicated `(i.e.`
|
||||
|
||||
### Documentation
|
||||
|
||||
@@ -5099,7 +5099,7 @@ Thanks to all the contributors who helped with this release, and a special thank
|
||||
|
||||
## 0.5.8
|
||||
|
||||
This release is the last release in the `0.5.x` series, and as such is mainly a bugfix release. Users are highly encouraged to upgrade to this release *before* moving to the upcoming `0.6.x` release, as we will be removing deprecated features at that point.
|
||||
This release is the last release in the `0.5.x` series, and as such is mainly a bugfix release. Users are highly encouraged to upgrade to this release _before_ moving to the upcoming `0.6.x` release, as we will be removing deprecated features at that point.
|
||||
|
||||
Thanks to all the contributors who helped with this release!
|
||||
|
||||
@@ -5291,7 +5291,7 @@ That was quick! This is a bugfix release to fix issues in the packaging and rele
|
||||
|
||||
This is our largest, most feature-packed release in the history of the dokku project. Lots of delicious things, including:
|
||||
|
||||
- Support for docker 1.10/1.11. You *must* have docker 1.9.1+ to install dokku.
|
||||
- Support for docker 1.10/1.11. You _must_ have docker 1.9.1+ to install dokku.
|
||||
- Revamped documentation website
|
||||
- [Deployment Tasks](https://dokku.com/docs/advanced-usage/deployment-tasks/)
|
||||
- Heroku-style management of [dockerfile processes](https://dokku.com/docs/deployment/builders/dockerfiles/#procfiles-and-multiple-processes)
|
||||
@@ -5390,7 +5390,7 @@ Thanks to all the contributors who helped with this release!
|
||||
|
||||
## 0.4.13
|
||||
|
||||
We lied. *This* is the final 0.4.x release. This specific release fixes support for bash `4.2`, which may be the only bash version available for certain testing environments.
|
||||
We lied. _This_ is the final 0.4.x release. This specific release fixes support for bash `4.2`, which may be the only bash version available for certain testing environments.
|
||||
|
||||
Thanks to all the contributors who helped with this release!
|
||||
|
||||
@@ -5444,7 +5444,7 @@ Thanks to all the contributors who helped with this release!
|
||||
This release is mostly a bugfix release, though we have a few important changes:
|
||||
|
||||
- `dokku plugin:update` can now be used to update a specific plugin. Previously, this could potentially result in an error a user would have to manually resolve.
|
||||
- We have started labeling all dokku-managed containers. In a future minor release, triggering a `dokku cleanup` will remove *only* exited containers that are managed by dokku. This change allows users to start containers outside of dokku and be assured that dokku would not inadvertently remove them.
|
||||
- We have started labeling all dokku-managed containers. In a future minor release, triggering a `dokku cleanup` will remove _only_ exited containers that are managed by dokku. This change allows users to start containers outside of dokku and be assured that dokku would not inadvertently remove them.
|
||||
|
||||
Thanks to all the contributors who helped with this release!
|
||||
|
||||
@@ -5790,11 +5790,11 @@ One new feature is colorized logging output, which should make it easier to debu
|
||||
This is our first minor release in almost a year. Many new features and removals have occurred, so here is a neat summary:
|
||||
|
||||
- Plugins are now triggered via `plugn`. Notably, you'll need add a `plugin.toml` to describe the plugin as well as use `plugn trigger` instead of `pluginhook` to trigger plugin callbacks. Please see the [plugin creation documentation](https://dokku.com/docs/development/plugin-creation/) for more details.
|
||||
- A few new official plugins have been added to the core, including [image tagging](https://dokku.com/docs/deployment/application-deployment/), [certificate management](https://dokku.com/docs/configuration/ssl/), a tar-based deploy solution, and much more. Check out the *New Features* section for more details.
|
||||
- A few new official plugins have been added to the core, including [image tagging](https://dokku.com/docs/deployment/application-deployment/), [certificate management](https://dokku.com/docs/configuration/ssl/), a tar-based deploy solution, and much more. Check out the _New Features_ section for more details.
|
||||
- We've removed a few deprecated plugin callbacks. Please see the [plugin triggers documentation](https://dokku.com/docs/development/plugin-triggers/) to see what is available.
|
||||
- [Official datastorage plugins](https://github.com/dokku) have been created for the most commonly used datastores. If you previously used/maintained a community contributed plugin, please check these out. We'll be adding more official plugins as time goes on.
|
||||
|
||||
Thanks to the *many* contributors for making this release our best release so far, and special thanks to both @michaelshobbs and @Flink for pushing along the `0.4.0` release!
|
||||
Thanks to the _many_ contributors for making this release our best release so far, and special thanks to both @michaelshobbs and @Flink for pushing along the `0.4.0` release!
|
||||
|
||||
### Deprecations and Removals
|
||||
|
||||
@@ -6116,10 +6116,10 @@ This release pegs Dokku to Docker 1.6.2. Docker 1.7.0 introduced changes in `doc
|
||||
- #1028: @Flink [docs] Add rails-logs to plugins
|
||||
- #1031: @michaelshobbs Upgrade docker in CI to 1.5.0
|
||||
- #1029: @assaf Added several enhancements for CHECKS file:
|
||||
- Specify how long to wait before running first check
|
||||
- Specify timeout for each check
|
||||
- Check specific hosts, e.g. http://signin.example.com
|
||||
- Check both HTTP and HTTPS resources
|
||||
- Specify how long to wait before running first check
|
||||
- Specify timeout for each check
|
||||
- Check specific hosts, e.g. [http://signin.example.com](http://signin.example.com)
|
||||
- Check both HTTP and HTTPS resources
|
||||
- #1032: @cameron-martin Updated dokku-installer to use relative path
|
||||
- #1035: @Flink [docs] Add dokku-http-auth to plugins
|
||||
- #1040: @ebeigarts [docs] Add dokku-slack plugin information
|
||||
@@ -6223,12 +6223,12 @@ This release pegs Dokku to Docker 1.6.2. Docker 1.7.0 introduced changes in `doc
|
||||
## 0.3.9
|
||||
|
||||
- #787: @josegonzalez/@michaelshobbs Official user-env-compile plugin
|
||||
- Uses ENV and APP/ENV files
|
||||
- Supports old `BUILD_ENV` files (which are likely in wide-use)
|
||||
- Allows user's to override globals with app-specific configuration
|
||||
- Migrate `$DOKKU_ROOT/BUILD_ENV` to `$DOKKU_ROOT/ENV` if the former exists and the latter does not
|
||||
- Drop `BUILD_ENV` support in favor of just `ENV` via a `mv` command
|
||||
- Add default ENV with `CURL_TIMEOUT` and `CURL_CONNECT_TIMEOUT`
|
||||
- Uses ENV and APP/ENV files
|
||||
- Supports old `BUILD_ENV` files (which are likely in wide-use)
|
||||
- Allows user's to override globals with app-specific configuration
|
||||
- Migrate `$DOKKU_ROOT/BUILD_ENV` to `$DOKKU_ROOT/ENV` if the former exists and the latter does not
|
||||
- Drop `BUILD_ENV` support in favor of just `ENV` via a `mv` command
|
||||
- Add default ENV with `CURL_TIMEOUT` and `CURL_CONNECT_TIMEOUT`
|
||||
- #811: @abossard Increased `server_names_hash_bucket_size` in nginx.conf to 512
|
||||
- #814: @josegonzalez Source files in $DOKKU_ROOT/.dokkurc directory and add `dokku trace` command
|
||||
- #816: @josegonzalez Add documentation for user-env feature
|
||||
@@ -6337,25 +6337,25 @@ This release pegs Dokku to Docker 1.6.2. Docker 1.7.0 introduced changes in `doc
|
||||
|
||||
## 0.2.0 (2013-11-24)
|
||||
|
||||
* Added DOKKU_TRACE variable for verbose trace information
|
||||
* Added an installer (for pre-built images)
|
||||
* Application config (environment variable management)
|
||||
* Backup/import plugin
|
||||
* Basic hooks/plugin system
|
||||
* Cache dir is preserved across builds
|
||||
* Command to delete an application
|
||||
* Exposed commands over SSH using sshcommand
|
||||
* Git handling is moved to a plugin
|
||||
* Integration test coverage
|
||||
* Pulled nginx vhosts out into plugin
|
||||
* Run command
|
||||
* Separated dokku and buildstep more cleanly
|
||||
* Uses latest version of Docker again
|
||||
- Added DOKKU_TRACE variable for verbose trace information
|
||||
- Added an installer (for pre-built images)
|
||||
- Application config (environment variable management)
|
||||
- Backup/import plugin
|
||||
- Basic hooks/plugin system
|
||||
- Cache dir is preserved across builds
|
||||
- Command to delete an application
|
||||
- Exposed commands over SSH using sshcommand
|
||||
- Git handling is moved to a plugin
|
||||
- Integration test coverage
|
||||
- Pulled nginx vhosts out into plugin
|
||||
- Run command
|
||||
- Separated dokku and buildstep more cleanly
|
||||
- Uses latest version of Docker again
|
||||
|
||||
## 0.1.0 (2013-06-15)
|
||||
|
||||
* First release
|
||||
* Bootstrap script for Ubuntu system
|
||||
* Basic push / deploy with git
|
||||
* Hostname support with Nginx
|
||||
* Support for Java, Ruby, Node.js buildpacks
|
||||
- First release
|
||||
- Bootstrap script for Ubuntu system
|
||||
- Basic push / deploy with git
|
||||
- Hostname support with Nginx
|
||||
- Support for Java, Ruby, Node.js buildpacks
|
||||
|
||||
@@ -39,10 +39,10 @@
|
||||
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
|
||||
- Link to the exact repository being deployed (if possible/applicable):
|
||||
- If a deploy is failing or behaving unexpectedly:
|
||||
- Application name
|
||||
- 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`.
|
||||
- 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 XXXXXX):
|
||||
|
||||
2
docs.mk
2
docs.mk
@@ -1,6 +1,6 @@
|
||||
.PHONY: docs-build-image
|
||||
docs-build-image:
|
||||
docker build -f docs/_build/Dockerfile --progress plain -t app/mkdocs .
|
||||
docker build -f docs/_build/Dockerfile --progress plain -t app/mkdocs .
|
||||
|
||||
.PHONY: docs-build
|
||||
docs-build:
|
||||
|
||||
@@ -59,7 +59,6 @@ When deploying a monorepo, it may be desirable to specify the specific path of t
|
||||
|
||||
For deploys via the `git:from-image` and `git:load-image` commands, the `app.json` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `app.json` extracted directly from the source code. Both cases will respect the configured `appjson-path` property value.
|
||||
|
||||
|
||||
```shell
|
||||
dokku app-json:set node-js-app appjson-path .dokku/app.json
|
||||
```
|
||||
|
||||
@@ -27,7 +27,7 @@ Dokku deploys your application in multiple "phases" and the `docker-options` plu
|
||||
|
||||
Manipulation of docker options will not restart running containers. This enables multiple options to be set/unset before final application. As such, changing an app's docker options must be followed by a `dokku ps:rebuild` in order to take effect.
|
||||
|
||||
More information on supported Docker options can be found here: https://docs.docker.com/engine/reference/commandline/run/.
|
||||
More information on supported Docker options can be found [here](https://docs.docker.com/engine/reference/commandline/run/).
|
||||
|
||||
Container options configured via the `docker-options` plugin are not used to modify the process a container runs. Container options are the `[OPTIONS]` portion of the following, where `[CONTAINER_COMMAND]` and `[ARG]` are the process and the arguments passed to it that are launched in the created container: `docker run [OPTIONS] [CONTAINER_COMMAND] [ARG...]`. Please see the documentation for [customizing the run command](/docs/deployment/builders/dockerfiles.md#customizing-the-run-command) or use a [Procfile](/docs/deployment/builders/dockerfiles.md#procfiles-and-multiple-processes) to modify the command used by a Dockerfile-based container.
|
||||
|
||||
|
||||
@@ -75,4 +75,4 @@ pre-release-buildpack
|
||||
pre-release-dockerfile
|
||||
receive-app
|
||||
update
|
||||
```
|
||||
```
|
||||
|
||||
@@ -36,7 +36,6 @@ dokku storage:list node-js-app
|
||||
|
||||
The output format can also be set to `json` for programmatic access:
|
||||
|
||||
|
||||
```shell
|
||||
dokku storage:list node-js-app --format json
|
||||
```
|
||||
@@ -70,11 +69,11 @@ dokku storage:ensure-directory node-js-app
|
||||
By default, permissions are set for usage with Herokuish buildpacks. These permissions can be changed via the `--chown` option according to the following table:
|
||||
|
||||
- `--chown herokuish` (default): Use `32767:32767` as the folder permissions.
|
||||
- This is used for apps deployed with Buildpacks via Herokuish.
|
||||
- This is used for apps deployed with Buildpacks via Herokuish.
|
||||
- `--chown heroku`: Use `1000:1000` as the folder permissions.
|
||||
- This is used for apps deployed with Cloud Native Buildpacks using the `heroku/buildpacks` builder.
|
||||
- This is used for apps deployed with Cloud Native Buildpacks using the `heroku/buildpacks` builder.
|
||||
- `--chown packeto`: Use `2000:2000` as the folder permissions.
|
||||
- This is used for apps deployed with Cloud Native Buildpacks using the `cloudfoundry/cnb` or `packeto` builders.
|
||||
- This is used for apps deployed with Cloud Native Buildpacks using the `cloudfoundry/cnb` or `packeto` builders.
|
||||
- `--chown false`: Skips the `chown` call.
|
||||
|
||||
Users deploying via Dockerfile will want to specify `--chown false` and manually `chown` the created directory if the user and/or group id of the runnning process in the deployed container do not correspond to any of the above options.
|
||||
|
||||
@@ -4,10 +4,10 @@
|
||||
|
||||
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/networking/proxies/nginx/#customizing-the-nginx-configuration) docs for more details.
|
||||
See the [nginx customization](/docs/networking/proxies/nginx.md#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/networking/proxies/nginx/#customizing-the-nginx-configuration) docs for more details.
|
||||
See the [nginx customization](/docs/networking/proxies/nginx.md#customizing-the-nginx-configuration) docs for more details.
|
||||
|
||||
@@ -8,7 +8,7 @@ The `tls` name is no longer a reserved app name, and can be used by applications
|
||||
|
||||
- `git#git_deploy_branch()` is deprecated in favor of `plugn trigger git-deploy-branch`.
|
||||
- The `config` command is deprecated in favor of `config:show`.
|
||||
- Usage of this command in conjunction with either the `--export` or `--shell` flag is deprecated in favor of `config:export --format` with the correct format value (`exports` or `shell`, respectively).
|
||||
- Usage of this command in conjunction with either the `--export` or `--shell` flag is deprecated in favor of `config:export --format` with the correct format value (`exports` or `shell`, respectively).
|
||||
- The `nginx:build-config` command is deprecated in favor of `proxy:build-config`.
|
||||
|
||||
## Removals
|
||||
|
||||
@@ -19,7 +19,7 @@ Before upgrading, uninstall the registry plugin via `dokku plugin:uninstall regi
|
||||
- The `dokku run` command now always removes the ephemeral container on exit. Users that need a persistent container should instead specify a `console` process type in their `Procfile` specifying an available shell (usually either `bash` or `sh`) and scale that container appropriately.
|
||||
- The `pre-deploy` plugin trigger is now called internally by Dokku. Scheduler plugins should avoid calling this trigger, as any image changes introduced by subsequent trigger calls will be ignored.
|
||||
- The default image used for Herokuish Buildpack builds is now `gliderlabs/herokuish:latest-20`, and is based on both the `heroku-20` stack as well as Ubuntu 20.04. Users that wish to stick with the old, `heroku-18`/Ubuntu 18.04 builder may specify `gliderlabs/herokuish:latest-18` as their builder image. Please see the [herokuish buildpack deployment documentation](/docs/deployment/builders/herokuish-buildpacks.md#customizing-the-buildpack-stack-builder) for more information on how to specify a custom buildpack stack builder.
|
||||
- This change does not impact any users of Cloud Native Buildpacks.
|
||||
- This change does not impact any users of Cloud Native Buildpacks.
|
||||
- We fixed an issue that required extracting Procfiles at the beginning of a deploy. Due to this change, a `Dockerfile` app contains a `Procfile` that does not specify a `web` process will fail to start. Usage of a `Procfile` with _only_ a `release` command should be replaced with a `scripts.dokku.postdeploy` deployment task in the `app.json` file. The alternative is to define the `web` process in the `Procfile`. See the [deployment task documentation](/docs/advanced-usage/deployment-tasks.md) for more information.
|
||||
|
||||
### Deprecations
|
||||
|
||||
@@ -9,4 +9,4 @@
|
||||
|
||||
- The `scheduler` plugin now controls the scheduler in use for deploys. Apps will have their `DOKKU_SCHEDULER` environment variables migrated to the scheduler plugin, after which that value will be removed from said app. Please see the [scheduler documentation](/docs/deployment/schedulers/scheduler-management.md) for more information.
|
||||
- The `deploy-source` metadata from `apps:report` is now no longer computed on the fly, but hydrated at deploy time via the `deploy-source-set` trigger. This value may be empty until your next deploy.
|
||||
- Additionally, the `deploy-source` trigger has now been removed.
|
||||
- Additionally, the `deploy-source` trigger has now been removed.
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
## Changes
|
||||
|
||||
- Renaming an application will now only rename domains that are associated with global domains. As an example:
|
||||
|
||||
```shell
|
||||
dokku domains:set-global dokku.me
|
||||
dokku apps:create node-js-app
|
||||
|
||||
@@ -3,23 +3,23 @@
|
||||
## `nginx-vhosts` plugin
|
||||
|
||||
- The nginx-vhosts template language is now [sigil](https://github.com/gliderlabs/sigil)
|
||||
- No need to escape literal `$` characters (or other "bash-isms")
|
||||
- Template variables are represented as {{ .VARIABLE_NAME }}
|
||||
- A detailed list of template variables can be found [here](/docs/networking/proxies/nginx.md#available-template-variables)
|
||||
- No need to escape literal `$` characters (or other "bash-isms")
|
||||
- Template variables are represented as {{ .VARIABLE_NAME }}
|
||||
- A detailed list of template variables can be found [here](/docs/networking/proxies/nginx.md#available-template-variables)
|
||||
- A custom nginx-vhosts template must be named `nginx.conf.sigil`
|
||||
- The default path for this custom template is the root of your repo (i.e. `/app` in the container or `WORKDIR` if defined in a dockerfile app)
|
||||
- Dokku no longer looks for this file in `/home/dokku/node-js-app` on the Dokku server
|
||||
- Check out an example template [here](/docs/networking/proxies/nginx.md)
|
||||
- The default path for this custom template is the root of your repo (i.e. `/app` in the container or `WORKDIR` if defined in a dockerfile app)
|
||||
- Dokku no longer looks for this file in `/home/dokku/node-js-app` on the Dokku server
|
||||
- Check out an example template [here](/docs/networking/proxies/nginx.md)
|
||||
- Support for server-wide SSL certs have been dropped in favor of using the `certs` plugin
|
||||
- `dokku certs:add node-js-app < certs.tar`
|
||||
- `dokku certs:add node-js-app < certs.tar`
|
||||
- All domains for an SSL-enabled app will be redirected to https by default
|
||||
- This can be overridden with a custom template
|
||||
- This can be overridden with a custom template
|
||||
- Replaced "magic" `NO_VHOST` variable with `domains:enable/disable`
|
||||
- Simplified zero downtime control
|
||||
- `checks:enable/disable`
|
||||
- `checks:enable/disable`
|
||||
|
||||
## Dockerfile apps with exposed ports
|
||||
|
||||
- Dockerfiles with `EXPOSE` clauses will get [all **tcp** ports proxied by default](/docs/deployment/builders/dockerfiles.md#exposed-ports)
|
||||
- Note that nginx will proxy the same port numbers to listen publicly
|
||||
- UDP ports can be exposed by disabling the [nginx proxy](/docs/networking/proxy-management.md) with `dokku proxy:disable node-js-app`
|
||||
- Note that nginx will proxy the same port numbers to listen publicly
|
||||
- UDP ports can be exposed by disabling the [nginx proxy](/docs/networking/proxy-management.md) with `dokku proxy:disable node-js-app`
|
||||
|
||||
@@ -3,30 +3,30 @@
|
||||
## Zero-downtime deployment
|
||||
|
||||
- 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
|
||||
- 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/networking/proxy-management.md) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
|
||||
- The UI is handled by the [proxy](/docs/networking/proxy-management.md) interface plugin by setting the `DOKKU_PROXY_PORT_MAP` config variable in the format of `scheme:host-port:container-port`. The default `nginx-vhosts` proxy plugin supports both the `http` and `https` schemes.
|
||||
- Default port mappings
|
||||
- buildpack apps will be set to `http:80:5000` and will also include `https:443:5000` if SSL is enabled.
|
||||
- dockerfile apps with explicitly exposed ports (i.e. using the `EXPOSE` directive) will be configured with a listener on each exposed port that proxies to the same port of the deployed application container.
|
||||
- You may override this behavior with the [`proxy:ports-*` commands](/docs/networking/proxy-management.md) or by directly setting `DOKKU_PROXY_PORT_MAP` with the `config:set` command
|
||||
- dockerfile apps without explicitly exposed ports will behave the same as a buildpack app
|
||||
- NOTE: These defaults **are not** automatically changed on subsequent pushes and must be manipulated with the aforementioned commands
|
||||
- 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/networking/proxy-management.md) or by directly setting `DOKKU_PROXY_PORT_MAP` with the `config:set` command
|
||||
- dockerfile apps without explicitly exposed ports will behave the same as a buildpack app
|
||||
- NOTE: These defaults **are not** automatically changed on subsequent pushes and must be manipulated with the aforementioned commands
|
||||
|
||||
## 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:
|
||||
- `dokku build`
|
||||
- `dokku receive`
|
||||
- `dokku release`
|
||||
- `dokku tar:build`
|
||||
- `dokku tar:build-locked`
|
||||
- `dokku git:build`
|
||||
- `dokku git:build-locked`
|
||||
- `dokku build`
|
||||
- `dokku receive`
|
||||
- `dokku release`
|
||||
- `dokku tar:build`
|
||||
- `dokku tar:build-locked`
|
||||
- `dokku git:build`
|
||||
- `dokku git:build-locked`
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## Domain Management
|
||||
|
||||
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.
|
||||
You can now set global and app domains via `domains:set` and `domains:set-global`. See the [domains documentation](/docs/configuration/domains.md) 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.
|
||||
See the [uninstall trigger documentation](/docs/development/plugin-triggers.md#uninstall) for implementation instructions.
|
||||
|
||||
## Deployment Tasks
|
||||
|
||||
|
||||
@@ -208,7 +208,7 @@ The following plugins have been removed as their functionality is now in Dokku C
|
||||
| [Volume (persistent storage)](https://github.com/ohardy/dokku-volume) | [ohardy][] | v0.5.0 (storage plugin) |
|
||||
|
||||
<sup>1</sup> Conflicts with [VHOSTS Custom Configuration](https://github.com/neam/dokku-nginx-vhosts-custom-configuration)
|
||||
<sup>2</sup> Similar to the heroku-labs feature (see https://devcenter.heroku.com/articles/labs-user-env-compile)
|
||||
<sup>2</sup> Similar to the [heroku-labs feature](https://devcenter.heroku.com/articles/labs-user-env-compile)
|
||||
|
||||
### Unmaintained Plugins
|
||||
|
||||
|
||||
@@ -14,6 +14,7 @@ config:keys (<app>|--global) [--merged]
|
||||
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
|
||||
config:unset [--no-restart] (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
|
||||
```
|
||||
|
||||
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available _only_ during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860). Consider using [build arguments](/docs/deployment/builders/dockerfiles.md#build-time-configuration-variables) to expose variables during build-time for Dockerfile apps.
|
||||
|
||||
Environment variables are available both at run time and during the application build/compilation step for buildpack-based deploys.
|
||||
@@ -28,7 +29,8 @@ You can set multiple environment variables at once:
|
||||
dokku config:set node-js-app ENV=prod COMPILE_ASSETS=1
|
||||
```
|
||||
|
||||
> Note: Whitespace and special characters get tricky. If you are using dokku locally you don't need to do any special escaping. If you are using dokku over ssh you will need to backslash-escape spaces:
|
||||
Whitespace and special characters get tricky. If you are using dokku locally you don't need to do any special escaping. If you are using dokku over ssh you will need to backslash-escape spaces:
|
||||
|
||||
```shell
|
||||
dokku config:set node-js-app KEY="VAL\ WITH\ SPACES"
|
||||
```
|
||||
@@ -58,8 +60,7 @@ dokku config:export node-js-app
|
||||
eval $(dokku config:export node-js-app)
|
||||
```
|
||||
|
||||
You can control the format of the exported variables with the `--format` flag.
|
||||
`--format=shell` will output the variables in a single-line for usage in command-line utilities:
|
||||
You can control the format of the exported variables with the `--format` flag. `--format=shell` will output the variables in a single-line for usage in command-line utilities:
|
||||
|
||||
```shell
|
||||
dokku config:export --format shell node-js-app
|
||||
|
||||
@@ -102,7 +102,7 @@ Once the deploy is complete, the application's web URL will be generated as abov
|
||||
Dokku supports deploying applications in a few ways:
|
||||
|
||||
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) to learn about the different ways to specify a buildpack.
|
||||
- This is the default method used by Dokku.
|
||||
- This is the default method used by Dokku.
|
||||
- [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/builders/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
|
||||
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) to learn about how to deploy a Docker Image.
|
||||
|
||||
@@ -148,7 +148,7 @@ dokku config:set ruby-getting-started DOKKU_SKIP_DEPLOY=true
|
||||
|
||||
### Redeploying or restarting
|
||||
|
||||
If you need to redeploy or restart your app:
|
||||
If you need to redeploy or restart your app:
|
||||
|
||||
```shell
|
||||
# on the Dokku host
|
||||
|
||||
@@ -131,14 +131,14 @@ dokku builder:report node-js-app --builder-selected
|
||||
To create a custom builder, the following triggers must be implemented:
|
||||
|
||||
- `builder-build`:
|
||||
- arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
|
||||
- description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
|
||||
- arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
|
||||
- description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
|
||||
- `builder-detect`:
|
||||
- arguments: `APP` `SOURCECODE_WORK_DIR`
|
||||
- description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
|
||||
- arguments: `APP` `SOURCECODE_WORK_DIR`
|
||||
- description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
|
||||
- `builder-release`:
|
||||
- arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
|
||||
- description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
|
||||
- arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
|
||||
- description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
|
||||
|
||||
Custom plugins names _must_ have the prefix `builder-` or builder overriding via `builder:set` may not function as expected.
|
||||
|
||||
|
||||
@@ -28,25 +28,27 @@ Builds will proceed with the `pack` cli for the app from then on.
|
||||
As this functionality is highly experimental, there are a number of caveats. Please note that not all issuesare listed below.
|
||||
|
||||
- Specifying specific buildpacks is not currently possible.
|
||||
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
|
||||
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
|
||||
- There is currently no way to specify extra arguments for `pack` cli invocations.
|
||||
- A future release will add support for injecting extra arguments during the build process.
|
||||
- A future release will add support for injecting extra arguments during the build process.
|
||||
- The default process type is `web`.
|
||||
- Build cache is stored in Docker volumes instead of on disk. As such, `repo:purge-cache` currently has no effect.
|
||||
- A future version will add integration with the `repo` plugin.
|
||||
- A future version will add integration with the `repo` plugin.
|
||||
- `pack` is not currently included with Dokku, nor is it added as a package dependency.
|
||||
- A future version will include it as a package dependency.
|
||||
- A future version will include it as a package dependency.
|
||||
|
||||
### Detection
|
||||
|
||||
This builder will be auto-detected in either the following cases:
|
||||
|
||||
- The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
|
||||
```shell
|
||||
dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
|
||||
```
|
||||
|
||||
```shell
|
||||
dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
|
||||
```
|
||||
|
||||
- A `project.toml` file exists in the root of the app repository.
|
||||
- This file is consumed by `pack-cli` and used to describe how the app is built.
|
||||
- This file is consumed by `pack-cli` and used to describe how the app is built.
|
||||
|
||||
The builder can also be specified via the `builder:set` command:
|
||||
|
||||
|
||||
@@ -22,9 +22,9 @@ builder-herokuish:set <app> <key> (<value>) # Set or clear a builder-herokuish p
|
||||
Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
|
||||
|
||||
- Set a `BUILDPACK_URL` environment variable
|
||||
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
|
||||
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
|
||||
- Create a `.buildpacks` file in the root of your repository.
|
||||
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
|
||||
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
|
||||
|
||||
This page will cover usage of the `buildpacks` plugin.
|
||||
|
||||
@@ -35,9 +35,9 @@ This page will cover usage of the `buildpacks` plugin.
|
||||
This builder will be auto-detected in either the following cases:
|
||||
|
||||
- The `BUILDPACK_URL` app environment variable is set.
|
||||
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
|
||||
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
|
||||
- A `.buildpacks` file exists in the root of the app repository.
|
||||
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
|
||||
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
|
||||
|
||||
The builder can also be specified via the `builder:set` command:
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ When an application is created via `git push`, Dokku will create the proper `pre
|
||||
dokku git:initialize node-js-app
|
||||
```
|
||||
|
||||
In order for the above command to succeed, the application _must_ already exist.
|
||||
In order for the above command to succeed, the application _must_ already exist.
|
||||
|
||||
> Warning: If the `pre-receive` hook was customized in any way, this will overwrite that hook with the current defaults for Dokku.
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ In addition, the following commands have special local side-effects:
|
||||
|
||||
#### Specifying a remote
|
||||
|
||||
While many users will only ever push to a single dokku remote from a given repository, it may be useful to point the same repository at multiple remotes, especially in the case of pre-production environments. This can be done via the `remote` commands. These commands are _only_ available within the official remote client, and are not server-side commands.
|
||||
While many users will only ever push to a single dokku remote from a given repository, it may be useful to point the same repository at multiple remotes, especially in the case of pre-production environments. This can be done via the `remote` commands. These commands are *only* available within the official remote client, and are not server-side commands.
|
||||
|
||||
To see your currently configured remote, run `dokku remote`. This will respect the `--remote` flag.
|
||||
|
||||
@@ -101,7 +101,7 @@ To add a remote, run `dokku remote:add $REMOTE_NAME dokku@dokku.me:$APP_NAME`, r
|
||||
|
||||
To remove a remote, run `dokku remote:remove $REMOTE_NAME`. This is equivalent to running `git remote remove $REMOTE_NAME`.
|
||||
|
||||
By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote _must_ be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
|
||||
By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote *must* be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
|
||||
|
||||
To clear the configured remote, run `dokku remote:unset`. The client will unset the configured remote, and will default back to `dokku`, or the value of `--remote` if specified.
|
||||
|
||||
|
||||
@@ -121,7 +121,6 @@ This plugin implements various functionality through `plugn` triggers to integra
|
||||
- `ps:stop`
|
||||
- `run`
|
||||
|
||||
|
||||
### Logging support
|
||||
|
||||
App logs for the `logs` command are fetched from running containers via the `docker` cli. To persist logs across deployments, consider using Dokku's [vector integration](/docs/deployment/logs.md#vector-logging-shipping) to ship logs to another service or a third-party platform.
|
||||
@@ -133,15 +132,15 @@ The `docker-local` scheduler supports a minimal list of resource _limits_ and _r
|
||||
#### Resource Limits
|
||||
|
||||
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
|
||||
- See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
|
||||
- See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
|
||||
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
|
||||
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
|
||||
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
|
||||
|
||||
#### Resource Reservations
|
||||
|
||||
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
|
||||
|
||||
@@ -91,23 +91,23 @@ Custom plugins names _must_ have the prefix `scheduler-` or scheduler overriding
|
||||
At this time, the following dokku commands are used to implement a complete scheduler.
|
||||
|
||||
- `apps:destroy`: stops the app processes on the scheduler
|
||||
- triggers: post-delete, scheduler-register-retired, scheduler-retire
|
||||
- triggers: post-delete, scheduler-register-retired, scheduler-retire
|
||||
- `apps:rename`: handles app renaming
|
||||
- triggers: post-app-rename-setup
|
||||
- triggers: post-app-rename-setup
|
||||
- `apps:clone`: handles app cloning
|
||||
- triggers: post-app-clone-setup
|
||||
- triggers: post-app-clone-setup
|
||||
- `deploy`: deploys app proceses and checks the status of a deploy
|
||||
- triggers: scheduler-app-status, scheduler-deploy, scheduler-is-deployed, scheduler-logs-failed
|
||||
- triggers: scheduler-app-status, scheduler-deploy, scheduler-is-deployed, scheduler-logs-failed
|
||||
- `enter`: enters a running container
|
||||
- triggers: scheduler-enter
|
||||
- triggers: scheduler-enter
|
||||
- `logs`: fetches app logs
|
||||
- triggers: scheduler-logs
|
||||
- triggers: scheduler-logs
|
||||
- `run`: starts one-off run containers (detached and non-detached) as well as listing run processes
|
||||
- triggers: scheduler-run, scheduler-run-list
|
||||
- triggers: scheduler-run, scheduler-run-list
|
||||
- `ps:stop`: stops app processes
|
||||
- triggers: scheduler-stop
|
||||
- triggers: scheduler-stop
|
||||
- `ps:inspect`: outputs inspect output for processes in an app
|
||||
- triggers: scheduler-inspect
|
||||
- triggers: scheduler-inspect
|
||||
|
||||
Schedulers may decide to omit some functionality here, or use plugin triggers to supplement config with information from other plugins. Additionally, a scheduler may implement other triggers in order handle any extra processes needed during a deploy.
|
||||
|
||||
|
||||
@@ -82,7 +82,6 @@ echo "$CONTENTS_OF_YOUR_PUBLIC_SSH_KEY_HERE" | dokku ssh-keys:add KEY_NAME
|
||||
SHA256:ABC123ABC123+abc123abc123Zabc123abcZ123abc
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
cat path/to/id_rsa.pub | dokku ssh-keys:add KEY_NAME
|
||||
```
|
||||
@@ -91,7 +90,6 @@ cat path/to/id_rsa.pub | dokku ssh-keys:add KEY_NAME
|
||||
SHA256:ABC123ABC123+abc123abc123Zabc123abcZ123abc
|
||||
```
|
||||
|
||||
|
||||
Admin users and root can add keys remotely by specifying the `dokku` bin on their `ssh` command:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -163,12 +163,12 @@ A healthcheck entry takes the following properties:
|
||||
- `attempts`: (default: `3` seconds) Number of retry attempts to perform on failure.
|
||||
- `command`: (default `''` - empty string) Command to execute within container.
|
||||
- `content`: (default: `''` - empty string) Content to search in http path check output.
|
||||
initialDelay default: 0, unit: seconds) Number of seconds to wait after a container has started before triggering the healthcheck.
|
||||
- `initialDelay`: (default: 0, unit: seconds) Number of seconds to wait after a container has started before triggering the healthcheck.
|
||||
- `name`: (default: autogenerated) The name of the healthcheck. If unspecified, it will be autogenerated from the rest of the healthcheck information.
|
||||
- `path`: (default: `/` - for http checks): An http path to check.
|
||||
- `timeout`: (default: `5` seconds): Number of seconds to wait before timing out a healthcheck.
|
||||
- `type`: (default: `""` - none): Type of the healthcheck. Options: liveness, readiness, startup.
|
||||
- `uptime`: (default: `""` - none): Amount of time the container must be alive before the container is considered healthy. Any restarts will cause this to check to fail, and this check does not respect retries.
|
||||
- `uptime`: (default: `""` - none): Amount of time the container must be alive before the container is considered healthy. Any restarts will cause this to check to fail, and this check does not respect retries.
|
||||
- `wait`: (default: `5` seconds): Number of seconds to wait between healthcheck attempts.
|
||||
|
||||
> Warning: Healthchecks are implemented by specific scheduler plugins, and not all plugins support all options. Please consult the scheduler documentation for further details on what is supported.
|
||||
|
||||
@@ -1161,7 +1161,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
- Description: Return the path to a `sigil` template that should be used to generate a given nginx configuration file.
|
||||
- Invoked by: `nginx-vhosts#build-config`
|
||||
- Arguments: `$APP $TEMPLATE_TYPE`
|
||||
- The `TEMPLATE_TYPE` argument can be one of: `[app-config, hsts-config, validate-config]`
|
||||
- The `TEMPLATE_TYPE` argument can be one of: `[app-config, hsts-config, validate-config]`
|
||||
- Example:
|
||||
|
||||
```shell
|
||||
@@ -1477,7 +1477,7 @@ APP="$1"
|
||||
|
||||
### `post-config-update`
|
||||
|
||||
- Description: Allows you to get notified when one or more configs is added or removed. Action can be `set` or `unset`.
|
||||
- Description: Allows you to get notified when one or more configs is added or removed. Action can be `set` or `unset`.
|
||||
- Invoked by: `dokku config:set`, `dokku config:unset`
|
||||
- Arguments: `$APP` `set|unset` `key1=VALUE1 key2=VALUE2`
|
||||
- Example:
|
||||
@@ -2052,6 +2052,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
|
||||
# TODO
|
||||
```
|
||||
|
||||
### `ps-current-scale`
|
||||
|
||||
- Description: Prints out the current scale contents (process-type=quantity) delimited by newlines.
|
||||
|
||||
@@ -29,4 +29,4 @@ Dokku Pro has the following functionality:
|
||||
- Authenticated HTTP(S) endpoints for git push functionality
|
||||
- Single Page App (SPA) Web UI exposing app, datastore, and ssh key management
|
||||
|
||||
While each release is fairly feature complete, individual features and documentation will expand over time. Feature development follows a monthly release cadence, with individual bug fixes released on an as needed basis.
|
||||
While each release is fairly feature complete, individual features and documentation will expand over time. Feature development follows a monthly release cadence, with individual bug fixes released on an as needed basis.
|
||||
|
||||
@@ -78,7 +78,7 @@ Follow the [user management documentation](/docs/deployment/user-management.md)
|
||||
|
||||
## VMs with less than 1 GB of memory
|
||||
|
||||
Having less than 1 GB of system memory available for Dokku and its containers may 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).
|
||||
Having less than 1 GB of system memory available for Dokku and its containers may 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.
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@
|
||||
Port 22
|
||||
```
|
||||
|
||||
> For users that have customized the IP address of their VM - either in a custom `Vagrantfile` or via the `DOKKU_IP` environment variable - and are not using `10.0.0.2` for the Vagrant IP, you'll need to instead use the output of `vagrant ssh-config dokku` for your `~/.ssh/config` entry.
|
||||
> For users that have customized the IP address of their VM - either in a custom `Vagrantfile` or via the `DOKKU_IP` environment variable - and are not using `10.0.0.2` for the Vagrant IP, you'll need to instead use the output of `vagrant ssh-config dokku` for your `~/.ssh/config` entry.
|
||||
|
||||
6. Connect to the server via `vagrant ssh` and add your ssh key to the install. Additionally, set the global domain name to `dokku.me`.
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Getting Started with Dokku
|
||||
|
||||
### What is Dokku?
|
||||
## What is Dokku?
|
||||
|
||||
Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice. Dokku supports building apps on the fly from a `git push` via either Dockerfile or by auto-detecting the language with Buildpacks, and then starts containers based on your built image. Using technologies such as nginx and cron, Web processes are automatically routed to, while background processes and automated cron tasks are also managed by Dokku.
|
||||
|
||||
### System Requirements
|
||||
## System Requirements
|
||||
|
||||
To start using Dokku, you'll need a system that meets the following minimum requirements:
|
||||
|
||||
@@ -12,7 +12,7 @@ To start using Dokku, you'll need a system that meets the following minimum requ
|
||||
- [Ubuntu 20.04/22.04](https://www.ubuntu.com/download)
|
||||
- [Debian 10+ x64](https://www.debian.org/distrib/)
|
||||
- A server with one of the following architectures
|
||||
- AMD64 (alternatively known as `x86_64`), commonly used for Intel cloud servers
|
||||
- AMD64 (alternatively known as `x86_64`), commonly used for Intel cloud servers
|
||||
- ARMV7 (alternatively known as `armhf`), commonly used for Raspberry PI
|
||||
- ARMV8 (alternatively known as `arm64`), commonly used for Raspberry PI and AWS Graviton
|
||||
|
||||
@@ -28,11 +28,11 @@ Finally, we recommend attaching at least one domain name to your server. This is
|
||||
|
||||
Please see the [dns documentation](/docs/networking/dns.md) and [domains documentation](/docs/configuration/domains.md) for more details.
|
||||
|
||||
### Installing the latest stable version
|
||||
## Installing the latest stable version
|
||||
|
||||
This is the simple method of installing Dokku. For alternative methods of installation, see the [advanced install guide](/docs/getting-started/advanced-installation.md#configuring).
|
||||
This is the simple method of installing Dokku. For alternative methods of installation, see the [advanced install guide](/docs/getting-started/advanced-installation.md#configuring).
|
||||
|
||||
#### 1. Install Dokku
|
||||
### 1. Install Dokku
|
||||
|
||||
To install the latest stable version of Dokku, you can run the following shell commands:
|
||||
|
||||
@@ -44,7 +44,7 @@ sudo DOKKU_TAG=v0.31.0 bash bootstrap.sh
|
||||
|
||||
The installation process takes about 5-10 minutes, depending upon internet connection speed.
|
||||
|
||||
#### 2. Setup SSH key and Virtualhost Settings
|
||||
### 2. Setup SSH key and Virtualhost Settings
|
||||
|
||||
Once the installation is complete, you should configure an ssh key and set your global domain.
|
||||
|
||||
@@ -67,6 +67,6 @@ dokku domains:set-global 10.0.0.2.sslip.io
|
||||
|
||||
See the [user management](/docs/deployment/user-management.md#adding-ssh-keys) and [domains documentation](/docs/configuration/domains.md#customizing-hostnames) for more information.
|
||||
|
||||
#### 3. Deploy your first application
|
||||
### 3. Deploy your first application
|
||||
|
||||
At this point, you should be able to [deploy to the Dokku installation](/docs/deployment/application-deployment.md).
|
||||
|
||||
@@ -33,7 +33,7 @@ dokku trace:off
|
||||
|
||||
## Common Problems
|
||||
|
||||
### I deployed my app but I am getting the default nginx page.
|
||||
### I deployed my app but I am getting the default nginx page
|
||||
|
||||
Most of the time it's caused by some defaults newer versions of nginx set. To make sure that's the issue you're having run the following:
|
||||
|
||||
@@ -91,7 +91,7 @@ The following error may be emitted from a deploy:
|
||||
|
||||
The `remote rejected` error does not give enough information. Anything could have failed. Enable trace mode and begin debugging. If this does not help you, create a [gist](https://gist.github.com) containing the full log, and create an issue.
|
||||
|
||||
One the reasons why you may get this error is because the command that is run in the container exited (without errors). For example, (in Procfile) when you define a new worker container to run Delayed Job and use the bin/delayed_job start command. This command deamonizes the process and exists. The container thinks it's done so it closes itself. The error you get is the one above. To fix the above problem for Delayed Job, you must define the worker to user rake jobs:work, which doesn't deamonize the process.
|
||||
One the reasons why you may get this error is because the command that is run in the container exited (without errors). For example, (in Procfile) when you define a new worker container to run Delayed Job and use the bin/delayed_job start command. This command deamonizes the process and exists. The container thinks it's done so it closes itself. The error you get is the one above. To fix the above problem for Delayed Job, you must define the worker to user rake jobs:work, which doesn't deamonize the process.
|
||||
|
||||
### I get the aforementioned error in the build phase (after turning on Dokku tracing)
|
||||
|
||||
@@ -121,7 +121,7 @@ Sometimes (especially on DigitalOcean) deploying again seems to get past these s
|
||||
resolvconf -u
|
||||
```
|
||||
|
||||
Please see https://github.com/dokku/dokku/issues/841 and https://github.com/dokku/dokku/issues/649.
|
||||
Please see [#841](https://github.com/dokku/dokku/issues/841) and [#649](https://github.com/dokku/dokku/issues/649).
|
||||
|
||||
### After adding an SSH key, I am told I cannot read from the remote repository on push
|
||||
|
||||
@@ -155,7 +155,7 @@ Host DOKKU_HOSTNAME
|
||||
|
||||
Also see [issue #116](https://github.com/dokku/dokku/issues/116).
|
||||
|
||||
### I successfully deployed my application with no deployment errors and receiving **Bad Gateway** when attempting to access the application.
|
||||
### I successfully deployed my application with no deployment errors and receiving **Bad Gateway** when attempting to access the application
|
||||
|
||||
In many cases the application will require the a `process.env.PORT` port opposed to a specified port.
|
||||
|
||||
@@ -171,7 +171,7 @@ Additionally, your application should listen/bind to all interfaces (`0.0.0.0`).
|
||||
|
||||
Please see [#5798](https://github.com/dokku/dokku/issues/5798).
|
||||
|
||||
### Deployment fails because of slow internet connection, messages shows `gzip: stdin: unexpected end of file`.
|
||||
### Deployment fails because of slow internet connection, messages shows `gzip: stdin: unexpected end of file`
|
||||
|
||||
If you see output similar this when deploying:
|
||||
|
||||
@@ -191,11 +191,11 @@ dokku config:set --global CURL_TIMEOUT=1200
|
||||
dokku config:set --global CURL_CONNECT_TIMEOUT=180
|
||||
```
|
||||
|
||||
Please see https://github.com/dokku/dokku/issues/509.
|
||||
Please see [#509](https://github.com/dokku/dokku/issues/509).
|
||||
|
||||
Another reason for this error (although it may respond immediately ruling out a timeout issue) may be because you've set the config setting `SSL_CERT_FILE`. Using a config setting with this key interferes with the buildpack's ability to download its dependencies, so you must rename the config setting to something else, e.g. `MY_APP_SSL_CERT_FILE`.
|
||||
|
||||
### Build fails with `Killed` message.
|
||||
### Build fails with `Killed` message
|
||||
|
||||
This generally occurs when the server runs out of memory. You can either add more RAM to your server or setup swap space. The follow script will create 2 GB of swap space.
|
||||
|
||||
@@ -209,7 +209,7 @@ sudo sysctl -w vm.swappiness=10
|
||||
echo vm.swappiness = 10 | sudo tee -a /etc/sysctl.conf
|
||||
```
|
||||
|
||||
### I successfully deployed my application with no deployment errors but I'm receiving Connection Timeout when attempting to access the application.
|
||||
### I successfully deployed my application with no deployment errors but I'm receiving Connection Timeout when attempting to access the application
|
||||
|
||||
This can occur if Dokku is running on a system with a firewall like UFW enabled (some OS versions like Ubuntu have this enabled by default). You can check if this is your case by running the following script:
|
||||
|
||||
@@ -223,7 +223,7 @@ If the previous script returned `Status: active` and a list of ports, UFW is ena
|
||||
sudo ufw disable
|
||||
```
|
||||
|
||||
### I can't connect to my application because the server is sending an invalid response, or can't provide a secure connection.
|
||||
### I can't connect to my application because the server is sending an invalid response, or can't provide a secure connection
|
||||
|
||||
This isn't usually an issue with Dokku, but rather an app config problem. This can happen when your application is configured to enforce secure connections/HSTS, but you don't have SSL set up for the app.
|
||||
|
||||
|
||||
@@ -28,8 +28,7 @@ The proxy port scheme is as follows:
|
||||
|
||||
- `SCHEME:HOST_PORT:CONTAINER_PORT`
|
||||
|
||||
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
|
||||
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
|
||||
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes. For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
|
||||
|
||||
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.
|
||||
|
||||
|
||||
@@ -107,7 +107,7 @@ Once the HSTS setting is disabled globally, it can be re-enabled on a per-app ba
|
||||
dokku nginx:set node-js-app hsts true
|
||||
```
|
||||
|
||||
### Running behind another proxy — configuring `X-Forwarded-*` headers:
|
||||
### Running behind another proxy — configuring `X-Forwarded-*` headers
|
||||
|
||||
Dokku's default Nginx configuration passes the de-facto standard HTTP headers [`X-Forwarded-For`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [`X-Forwarded-Proto`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto), and `X-Forwarded-Port` to your application.
|
||||
These headers indicate the IP address of the original client making the request, the protocol of the original request (HTTP or HTTPS), and the port number of the original request, respectively.
|
||||
@@ -331,7 +331,6 @@ When deploying a monorepo, it may be desirable to specify the specific path of t
|
||||
|
||||
For deploys via the `git:from-image` and `git:load-image` commands, the `nginx.conf.sigil` is extracted from the configured `WORKDIR` property of the image. For all other deploys - git push, `git:from-archive`, `git:sync` - will have the `nginx.conf.sigil` extracted directly from the source code. Both cases will respect the configured `nginx-conf-sigil-path` property value.
|
||||
|
||||
|
||||
```shell
|
||||
dokku nginx:set node-js-app nginx-conf-sigil-path .dokku/nginx.conf.sigil
|
||||
```
|
||||
|
||||
@@ -117,36 +117,36 @@ From Dokku versions `0.5.0` until `0.11.0`, enabling or disabling an application
|
||||
|
||||
Custom plugins names _must_ have the suffix `-vhosts` or scheduler overriding via `proxy:set` may not function as expected.
|
||||
|
||||
At this time, the following dokku commands are used to interact with a complete proxy implementation.
|
||||
At this time, the following dokku commands are used to interact with a complete proxy implementation.
|
||||
|
||||
- `domains:add`: Adds a given domain to an app.
|
||||
- triggers: `post-domains-update`
|
||||
- triggers: `post-domains-update`
|
||||
- `domains:clear`: Clears out an app's associated domains.
|
||||
- triggers: `post-domains-update`
|
||||
- triggers: `post-domains-update`
|
||||
- `domains:disable`: Disables domains for an app.
|
||||
- triggers: `pre-disable-vhost`
|
||||
- triggers: `pre-disable-vhost`
|
||||
- `domains:enable`: Enables domains for an app.
|
||||
- triggers: `pre-enable-vhost`
|
||||
- triggers: `pre-enable-vhost`
|
||||
- `domains:remove`: Removes a domain from an app.
|
||||
- triggers: `post-domains-update`
|
||||
- triggers: `post-domains-update`
|
||||
- `domains:set`: Sets all domains for a given app.
|
||||
- triggers: `post-domains-update`
|
||||
- triggers: `post-domains-update`
|
||||
- `proxy:build-config`: Builds - or rebuilds - external proxy configuration.
|
||||
- triggers: `proxy-build-config`
|
||||
- triggers: `proxy-build-config`
|
||||
- `proxy:clear-config`: Clears out external proxy configuration.
|
||||
- triggers: `proxy-clear-config`
|
||||
- triggers: `proxy-clear-config`
|
||||
- `proxy:disable`: Disables the proxy configuration for an app.
|
||||
- triggers: `proxy-disable`
|
||||
- triggers: `proxy-disable`
|
||||
- `proxy:enable`: Enables the proxy configuration for an app.
|
||||
- triggers: `proxy-enable`
|
||||
- triggers: `proxy-enable`
|
||||
- `ports:add`: Adds one or more port mappings to an app
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- `ports:clear`: Clears out all port mappings for an app.
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- `ports:remove`: Removes one or more port mappings from an app.
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- `ports:set`: Sets all port mappings for an app.
|
||||
- triggers: `post-proxy-ports-update`
|
||||
- triggers: `post-proxy-ports-update`
|
||||
|
||||
Proxy implementations may decide to omit some functionality here, or use plugin triggers to supplement config with information from other plugins.
|
||||
|
||||
|
||||
@@ -117,7 +117,7 @@ If the file exists, it should not be empty, as doing so may result in a failed d
|
||||
|
||||
The syntax for declaring a `Procfile` is as follows. Note that the format is one process type per line, with no duplicate process types.
|
||||
|
||||
```
|
||||
```Procfile
|
||||
<process type>: <command>
|
||||
```
|
||||
|
||||
@@ -141,7 +141,7 @@ For initial app deploys, Dokku will default to starting a single `web` process f
|
||||
There are also a few other exceptions for the `web` process.
|
||||
|
||||
- By default, the built-in nginx proxy implementation only proxies the `web` process (others may be handled via a custom `nginx.conf.sigil`).
|
||||
- See the [nginx request proxying documentation](/docs/networking/proxies/nginx.md#request-proxying) for more information on how nginx handles proxied requests.
|
||||
- See the [nginx request proxying documentation](/docs/networking/proxies/nginx.md#request-proxying) for more information on how nginx handles proxied requests.
|
||||
- Only the `web` process may be bound to an external port.
|
||||
|
||||
#### The `release` process
|
||||
@@ -206,7 +206,7 @@ dokku ps:scale --skip-deploy node-js-app web=1
|
||||
|
||||
Users can also configure scaling within the codebase itself to manage process scaling. The `formation` key should be specified as follows in the `app.json` file:
|
||||
|
||||
```Procfile
|
||||
```json
|
||||
{
|
||||
"formation": {
|
||||
"web": {
|
||||
@@ -383,7 +383,7 @@ When a server reboots or Docker is restarted/upgraded, Docker may or may not sta
|
||||
- Start all linked services.
|
||||
- Clear generated proxy configuration files.
|
||||
- Start the app if it has not been manually stopped.
|
||||
- If the app containers still exist, they will be started and the generated proxy configuration files will be rebuilt.
|
||||
- If any of the app containers are missing, the entire app will be rebuilt.
|
||||
- If the app containers still exist, they will be started and the generated proxy configuration files will be rebuilt.
|
||||
- If any of the app containers are missing, the entire app will be rebuilt.
|
||||
|
||||
During this time, requests may route to the incorrect app if the assigned IPs correspond to those for other apps. While dokku makes all efforts to avoid this, there may be a few minutes where urls may route to the wrong app. To avoid this, either use a custom proxy plugin or wait a few minutes until the restoration process is complete.
|
||||
|
||||
@@ -18,7 +18,7 @@ Dokku automates scheduled `dokku run` commands via it's `app.json` cron integrat
|
||||
|
||||
The `app.json` file for a given app can define a special `cron` key that contains a list of commands to run on given schedules. The following is a simple example `app.json` that effectively runs the command `dokku run $APP npm run send-email` once a day:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"cron": [
|
||||
{
|
||||
@@ -168,8 +168,7 @@ For tasks that will properly resume, you _should_ use the above method, as runni
|
||||
Regularly scheduled tasks can be a bit of a pain with Dokku. The following are general recommendations to follow to help ensure successful task runs.
|
||||
|
||||
- Use the `dokku` user in your cron entry.
|
||||
- If you do not, the `dokku` binary will attempt to execute with `sudo`, and your cron run with fail with `sudo: no tty present and no askpass program specified`.
|
||||
|
||||
- If you do not, the `dokku` binary will attempt to execute with `sudo`, and your cron run with fail with `sudo: no tty present and no askpass program specified`.
|
||||
- Add a `MAILTO` environment variable to ship cron emails to yourself.
|
||||
- Add a `PATH` environment variable or specify the full path to binaries on the host.
|
||||
- Add a `SHELL` environment variable to specify Bash when running commands.
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
This is a sample application to test heroku buildpack multi for integrating with herokuish: https://github.com/gliderlabs/herokuish
|
||||
This is a sample application to test heroku buildpack multi for integrating with [herokuish](https://github.com/gliderlabs/herokuish)
|
||||
|
||||
I am choosing to use the python, nodejs, and ruby buildpacks to create a very simple flask app that performs a bower install and a simple grunt task using compass.
|
||||
|
||||
@@ -9,10 +9,10 @@ This application support the [Getting Started with Scala on Heroku](https://devc
|
||||
Make sure you have Scala and sbt installed. Also, install the [Heroku Toolbelt](https://toolbelt.heroku.com/).
|
||||
|
||||
```sh
|
||||
$ git clone https://github.com/heroku/scala-getting-started.git
|
||||
$ cd scala-getting-started
|
||||
$ sbt compile stage
|
||||
$ foreman start web
|
||||
git clone https://github.com/heroku/scala-getting-started.git
|
||||
cd scala-getting-started
|
||||
sbt compile stage
|
||||
foreman start web
|
||||
```
|
||||
|
||||
Your app should now be running on [localhost:5000](http://localhost:5000/).
|
||||
@@ -20,9 +20,9 @@ Your app should now be running on [localhost:5000](http://localhost:5000/).
|
||||
## Deploying to Heroku
|
||||
|
||||
```sh
|
||||
$ heroku create
|
||||
$ git push heroku master
|
||||
$ heroku open
|
||||
heroku create
|
||||
git push heroku master
|
||||
heroku open
|
||||
```
|
||||
|
||||
## Documentation
|
||||
@@ -30,4 +30,3 @@ $ heroku open
|
||||
For more information about using Scala on Heroku, see these Dev Center articles:
|
||||
|
||||
- [Scala on Heroku](https://devcenter.heroku.com/categories/scala)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user