github/dokku
0
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Use correct casing for Dokku name

Browse Source 
lowercase should only be used to refer to the binary, not the project
This commit is contained in:
Jose Diaz-Gonzalez
2016-09-03 04:39:12 -04:00
parent 7cfeb090ed
commit f26b3f1966
34 changed files with 123 additions and 119 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/deployment/application-deployment.md
View File

@@ -14,7 +14,7 @@ git clone git@github.com:heroku/ruby-rails-sample.git
Create the application on the Dokku host. You will need to ssh onto the host to run this command.
```shell
# on your dokku host
# on your Dokku host
dokku apps:create ruby-rails-sample
```
@@ -23,7 +23,7 @@ dokku apps:create ruby-rails-sample
When you create a new app, Dokku by default *does not* provide any datastores such as MySQL or PostgreSQL. You will need to install plugins to handle that, but fortunately [Dokku has official plugins](/dokku/community/plugins/#official-plugins-beta) for common datastores. Our sample app requires a PostgreSQL service:
```shell
# on your dokku host
# on your Dokku host
# install the postgres plugin
# plugin installation requires root, hence the user change
sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git
@@ -39,7 +39,7 @@ dokku postgres:create rails-database
Once the service creation is complete, set the `POSTGRES_URL` environment variable by linking the service.
```shell
# on your dokku host
# on your Dokku host
# each official datastore offers a `link` method to link a service to any application
dokku postgres:link rails-database ruby-rails-sample
```
@@ -97,7 +97,7 @@ You can also support pushing multiple branches using the [receive-branch](/dokku
If you only want to rebuild and tag a container, you can skip the deployment phase by setting `$DOKKU_SKIP_DEPLOY` to `true` by running:
``` shell
# on your dokku host
# on your Dokku host
dokku config:set ruby-rails-sample DOKKU_SKIP_DEPLOY=true
```
@@ -106,7 +106,7 @@ dokku config:set ruby-rails-sample DOKKU_SKIP_DEPLOY=true
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 `/home/dokku/.ssh/` and potentially add github.com (or your VCS host key) into `/home/dokku/.ssh/known_hosts`. The following test should help confirm you've done it correctly.
```shell
# on your dokku host
# on your Dokku host
su - dokku
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh -T git@github.com

2
docs/deployment/application-management.md
View File

@@ -21,7 +21,7 @@ node-js-app
python-app
```
Note that you can easily hide extra output from dokku commands by using the `--quiet` flag, which makes it easier to parse on the command-line.
Note that you can easily hide extra output from Dokku commands by using the `--quiet` flag, which makes it easier to parse on the command-line.
```shell
dokku --quiet apps

4
docs/deployment/methods/buildpacks.md
View File

@@ -9,9 +9,9 @@ Dokku normally defaults to using [heroku buildpacks](https://devcenter.heroku.co
## Specifying a custom buildpack
In certain cases you may want to specify a custom buildpack. While dokku uses herokuish to support all the [official heroku buildpacks](https://github.com/gliderlabs/herokuish#buildpacks), it is possible that the buildpack detection does not work well for your application. As well, you may wish to use a custom buildpack to handle specific application logic.
In certain cases you may want to specify a custom buildpack. While Dokku uses herokuish to support all the [official heroku buildpacks](https://github.com/gliderlabs/herokuish#buildpacks), it is possible that the buildpack detection does not work well for your application. As well, you may wish to use a custom buildpack to handle specific application logic.
To use a specific buildpack, you can run the following dokku command:
To use a specific buildpack, you can run the following Dokku command:
```shell
# replace APP with the name of your application

2
docs/deployment/methods/dockerfiles.md
View File

@@ -19,7 +19,7 @@ Dokku will extract all tcp ports exposed using the `EXPOSE` directive (one port
> Note: Nginx does not support proxying UDP. UDP ports can be exposed by disabling the nginx proxy with `dokku proxy:disable myapp`
If you do not explicitly `EXPOSE` a port in your `Dockerfile`, dokku will configure the nginx proxy to listen on port 80 (and 443 for TLS) and forward traffic to your app listening on port 5000 inside the container. Just like buildpack apps, you can also use the `$PORT` environment variable in your app to maintain portability.
If you do not explicitly `EXPOSE` a port in your `Dockerfile`, Dokku will configure the nginx proxy to listen on port 80 (and 443 for TLS) and forward traffic to your app listening on port 5000 inside the container. Just like buildpack apps, you can also use the `$PORT` environment variable in your app to maintain portability.
When ports are exposed through the default nginx proxy, they are proxied externally as HTTP ports. At this time, in no case do we proxy plain TCP or UDP ports. If you would like to investigate alternative proxy methods, please refer to our [proxy management documentation](/dokku/advanced-usage/proxy-management/).

8
docs/deployment/methods/tar.md
View File

@@ -7,9 +7,11 @@ tar:from <app> <url> # Loads an app tarball from url
tar:in <app> # Reads an tarball containing the app from stdin
```
## Deploying from a tarball
## Usage
In some cases, it may be useful to deploy an application from a tarball. For instance, if you implemented a non-git based deployment plugin, tarring the generated artifact may be an easier route to interface with the existing dokku infrastructure.
### Deploying from a tarball
In some cases, it may be useful to deploy an application from a tarball. For instance, if you implemented a non-git based deployment plugin, tarring the generated artifact may be an easier route to interface with the existing Dokku infrastructure.
You can place the tarball on an external webserver and deploy via the `tar:from` command.
@@ -17,6 +19,8 @@ You can place the tarball on an external webserver and deploy via the `tar:from`
dokku tar:from node-js-app https://dokku.me/releases/node-js-app/v1
```
### Deploying via stdin
As an alternative, a deploy can be trigged from a tarball read from stdin using the `tar:in` command:
```shell

8
docs/deployment/one-off-processes.md
View File

@@ -36,14 +36,14 @@ dokku config:set --global DOKKU_RM_CONTAINER=1
dokku config:unset --global DOKKU_RM_CONTAINER
```
You may also use the `--rm-container` or `--rm` dokku flags to remove the containers automatically:
You may also use the `--rm-container` or `--rm` Dokku flags to remove the containers automatically:
```shell
dokku --rm-container run node-js-app ls -lah
dokku --rm run node-js-app ls -lah
```
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.
Finally, you may wish to run a container in "detached" mode via the `--detach` Dokku flag. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
```shell
dokku --detach run node-js-app ls -lah
@@ -119,8 +119,8 @@ For tasks that will properly resume, you **should** use the above method, as run
Regularly scheduled tasks can be a bit of a pain with dokku. The following are general recommendations to follow to help ensure successful task runs.
- Use the dokku user's crontab
- If you do not, dokku will attempt to execute with sudo dokku, and your cron run with fail with `sudo: no tty present and no askpass program specified`
- Use the `dokku` user's crontab
- If you do not, the `dokku` binary will attempt to execute with `sudo` dokku, 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.

4
docs/deployment/remote-commands.md
View File

@@ -12,7 +12,7 @@ Host dokku.me
## Behavioral modifiers
Dokku also supports certain command-line arguments that augment it's behavior. If using these over ssh, you must use the form `ssh -t dokku@dokku.me -- <command>`
in order to avoid ssh interpretting dokku arguments for itself.
in order to avoid ssh interpretting Dokku arguments for itself.
```
--quiet suppress output headers
@@ -23,6 +23,6 @@ in order to avoid ssh interpretting dokku arguments for itself.
## Clients
You may optionally use a client to connect to your dokku server. Most clients use the configured `git remote` to locate the dokku server, though some allow for overriding this via an environment variable or flag.
You may optionally use a client to connect to your Dokku server. Most clients use the configured `git remote` to locate the Dokku server, though some allow for overriding this via an environment variable or flag.
Please refer to the [clients](/dokku/community/clients/) list for more details.

8
docs/deployment/zero-downtime-deploys.md
View File

@@ -10,7 +10,7 @@ checks:run <app> [process-type(s)] Runs zero-downtime checks for all proce
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
```
Following a deploy, dokku will wait `10` seconds before routing traffic to the new container to give your application time to boot up. If the application is not running after this time, then the deploy is failed and your old container will continue serving traffic. You can modify this value globally or on a per-application basis:
Following a deploy, Dokku will wait `10` seconds before routing traffic to the new container to give your application time to boot up. If the application is not running after this time, then the deploy is failed and your old container will continue serving traffic. You can modify this value globally or on a per-application basis:
```shell
dokku config:set --global DOKKU_DEFAULT_CHECKS_WAIT=30
@@ -147,7 +147,7 @@ Invalid container id specified (APP.web.3)
If your application needs a longer period to boot up - perhaps to load data into memory, or because of slow boot time - you may also use dokku's `checks` functionality to more precisely check whether an application can serve traffic or not.
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, dokku will fallback to the aforementioned process uptime check.
Checks are run against the detected `web` process from your application's `Procfile`. For non-web processes, Dokku will fallback to the aforementioned process uptime check.
To specify checks, add a `CHECKS` file to the root of your project directory. The `CHECKS` file should be plain text and may contain:
@@ -203,7 +203,7 @@ ATTEMPTS=10 # Attempt checks 10 times
/ My Amazing App
```
You can also override the default `WAIT`, `TIMEOUT`, and `ATTEMPTS` variables for the global dokku installation:
You can also override the default `WAIT`, `TIMEOUT`, and `ATTEMPTS` variables for the global Dokku installation:
```shell
dokku config:set --global DOKKU_CHECKS_WAIT=30
@@ -219,7 +219,7 @@ dokku config:set <app> DOKKU_DEFAULT_CHECKS_WAIT=0
### Configuring docker stop timeout
[By default](https://docs.docker.com/engine/reference/commandline/stop/), docker will wait 10 seconds from the time the `stop` command is passed to a container before it attempts to kill said container. This timeout can be configured on a per-app basis in dokku by setting the `DOKKU_DOCKER_STOP_TIMEOUT` configuration variable. This timeout applies to normal zero-downtime deployments as well as the `ps:stop` and `apps:destroy` commands.
[By default](https://docs.docker.com/engine/reference/commandline/stop/), docker will wait 10 seconds from the time the `stop` command is passed to a container before it attempts to kill said container. This timeout can be configured on a per-app basis in Dokku by setting the `DOKKU_DOCKER_STOP_TIMEOUT` configuration variable. This timeout applies to normal zero-downtime deployments as well as the `ps:stop` and `apps:destroy` commands.
```shell
dokku config:set $APP DOKKU_DOCKER_STOP_TIMEOUT=20