Merge branch 'upcoming' of github.com:dokku/dokku into upcoming

This commit is contained in:
Jose Diaz-Gonzalez
2019-10-07 18:55:29 -05:00
154 changed files with 1998 additions and 1494 deletions

View File

@@ -90,6 +90,7 @@ The following list config variables have special meaning and can be set in a var
| `DOKKU_EVENTS_LOGFILE` | `$DOKKU_LOGS_DIR/events.log` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where the events log file is written to. |
| `DOKKU_APP_NAME` | none | `--app APP` flag | Name of application to work on. Respected by core plugins. |
| `DOKKU_APPS_FORCE_DELETE` | none | `--force` flag | Whether to force delete an application. Also used by other plugins for destructive actions. |
| `DOKKU_CHECKS_URL` | `http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Whether to detach a container started via `dokku run`. |
| `DOKKU_QUIET_OUTPUT` | none | `--quiet` flag | Silences certain header output for `dokku` commands. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> `--rm-container` flag <br /> `--rm` flag | Whether to keep `dokku run` containers around or not. |

View File

@@ -9,7 +9,7 @@ Once you have configured Dokku with at least one user, you can deploy applicatio
```shell
# from your local machine
# SSH access to github must be enabled on this host
git clone git@github.com:heroku/ruby-getting-started.git
git clone https://github.com/heroku/ruby-getting-started
```
### Create the app

View File

@@ -76,3 +76,28 @@ This behavior can be disabled entirely on a per-app basis by setting the `rev-en
# override for a specific app
dokku git:set node-js-app rev-env-var ""
```
### Keeping the `.git` directory
By default, Dokku will remove the contents of the `.git` before triggering a build for a given app. This is generally a safe default as shipping the entire source code history of your app in the deployed image artifact is unnecessary as it increases bloat and potentially can leak information if there are any security issues with your app code.
To enable the `.git` directory, run the `git:set` command as follows:
```shell
# on the Dokku host
# keep the .git directory during builds
dokku git:set node-js-app keep-git-dir true
```
The default behavior is to delete this directory and it's contents. To revert to the default behavior, the `keep-git-dir` value can be set to either an empty string or `false`.
```shell
# on the Dokku host
# delete the .git directory during builds (default)
dokku git:set node-js-app keep-git-dir false
# delete the .git directory during builds (default)
dokku git:set node-js-app keep-git-dir ""
```

View File

@@ -92,7 +92,6 @@ dokku tags:deploy node-js-app v1
-----> Running post-deploy
-----> Configuring node-js-app.dokku.me...
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
Reloading nginx
-----> Shutting down old containers in 60 seconds
=====> 025eec3fa3b442fded90933d58d8ed8422901f0449f5ea0c23d00515af5d3137

View File

@@ -46,6 +46,12 @@ dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
Containers may have specific labels attached. In order to avoid issues with dokku internals, do not use any labels beginning with either `com.dokku` or `org.label-schema`.
```shell
dokku --label=com.example.test-label=value run node-js-app ls -lah
```
Finally, you may wish to run a container in "detached" mode via the `--detach` Dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
```shell

View File

@@ -123,7 +123,7 @@ To specify checks, add a `CHECKS` file to the root of your project directory. Th
- comments (lines starting with #)
- empty lines
> For Dockerfile-based deploys, the file *must* be in `/app/CHECKS` within the container. `/app` is used by default as the root container directory for buildpack-based deploys.
> For Dockerfile and Docker Image based deploys, the file *must* be in the `WORKDIR` directory of the built image. `/app` is used by default as the root container directory for buildpack-based deploys.
### Check instructions
@@ -327,7 +327,6 @@ curl: (7) Failed to connect to 172.17.0.155 port 5000: Connection refused
-----> Running post-deploy
-----> Configuring myapp.dokku.me...
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
Reloading nginx
-----> Shutting down old container in 60 seconds
=====> Application deployed:

View File

@@ -159,7 +159,7 @@ Certain systems may require a wrapper function around the `docker` binary for pr
```shell
# good
"$DOCKER_BIN" run -d $IMAGE /bin/bash -e -c "$COMMAND"
"$DOCKER_BIN" container run -d $IMAGE /bin/bash -e -c "$COMMAND"
# bad
docker run -d $IMAGE /bin/bash -e -c "$COMMAND"
@@ -175,16 +175,16 @@ Note that where possible, a label `com.dokku.app-name=$APP` - where `$APP` is th
```shell
# `docker build` example
"$DOCKER_BIN" build "--label=com.dokku.app-name=${APP}" $DOKKU_GLOBAL_BUILD_ARGS ...
"$DOCKER_BIN" image build "--label=com.dokku.app-name=${APP}" $DOKKU_GLOBAL_BUILD_ARGS ...
# `docker commit` example
# Note that the arguments must be set as a local array
# as arrays cannot be exported in shell
local DOKKU_COMMIT_ARGS=("--change" "LABEL org.label-schema.schema-version=1.0" "--change" "LABEL org.label-schema.vendor=dokku" "--change" "LABEL $DOKKU_CONTAINER_LABEL=")
"$DOCKER_BIN" commit --change "LABEL com.dokku.app-name=$APP" "${DOKKU_COMMIT_ARGS[@]}" ...
"$DOCKER_BIN" container commit --change "LABEL com.dokku.app-name=$APP" "${DOKKU_COMMIT_ARGS[@]}" ...
# `docker run` example
"$DOCKER_BIN" run "--label=com.dokku.app-name=${APP}" $DOKKU_GLOBAL_RUN_ARGS ...
"$DOCKER_BIN" container run "--label=com.dokku.app-name=${APP}" $DOKKU_GLOBAL_RUN_ARGS ...
```
## Copy files from the built image using `copy_from_image`

View File

@@ -65,7 +65,6 @@ dokku proxy:ports-add node-js-app http:8080:5000
DOKKU_PROXY_PORT_MAP: http:80:5000 http:8080:5000
-----> Configuring node-js-app.dokku.me...(using built-in template)
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
Reloading nginx
```
@@ -100,7 +99,6 @@ dokku proxy:ports-set node-js-app http:8080:5000
DOKKU_PROXY_PORT_MAP: http:80:5000 http:8080:5000
-----> Configuring node-js-app.dokku.me...(using built-in template)
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
Reloading nginx
```
@@ -126,7 +124,7 @@ For buildpack deployments, your application *must* respect the `PORT` environmen
> Changed as of 0.5.0
Dokku's default proxy implementation - nginx - only supports HTTP request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
Dokku's default proxy implementation - nginx - supports HTTP and GRPC request proxying. At this time, we do not support proxying plain TCP or UDP ports. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/docs/advanced-usage/proxy-management.md).
#### Applications using EXPOSE

View File

@@ -69,7 +69,8 @@ The proxy port scheme is as follows:
- `SCHEME:HOST_PORT:CONTAINER_PORT`
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports both the `http` and `https` schemes.
The scheme metadata can be used by proxy implementations in order to properly handle proxying of requests. For example, the built-in `nginx-vhosts` proxy implementation supports the `http`, `https`, `grpc` and `grpcs` schemes.
For the `grpc` and `grpcs` see [nginx blog post on grpc](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
Developers of proxy implementations are encouraged to use whatever schemes make the most sense, and ignore configurations which they do not support. For instance, a `udp` proxy implementation can safely ignore `http` and `https` port mappings.