Mirrors/dokku
1
0
Fork 0
mirror of https://github.com/dokku/dokku.git synced 2025-12-29 00:25:08 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: more cleanup

Browse Source
This commit is contained in:
Jose Diaz-Gonzalez
2021-07-09 22:37:28 -04:00
parent 4469b7428a
commit c50f39b4fa
14 changed files with 72 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -211,10 +211,12 @@ git remote add dokku dokku@dokku.me:dokku.me
git push dokku main:master
```
... deployment ...
```
... deployment ...
remote: -----> Application deployed:
remote: http://dokku.me
remote: -----> Application deployed:
remote: http://dokku.me
```
## Dokku/Docker container management compatibility

4
docs/deployment/builders/herokuish-buildpacks.md
View File

@@ -55,7 +55,6 @@ dokku buildpacks:list node-js-app
-----> test buildpack urls
```
```shell
# running for an app with two buildpacks specified
dokku buildpacks:list node-js-app
@@ -226,7 +225,7 @@ dokku config:unset --no-restart node-js-app DOKKU_PROXY_PORT_MAP
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
By default, Dokku uses the [gliderlabs/herokuish](https://github.com/gliderlabs/herokuish/) project, which pins all of it's vendored buildpacks. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified *without* a Git commit SHA like so:
By default, Dokku uses the [gliderlabs/herokuish](https://github.com/gliderlabs/herokuish/) project, which pins all of it's vendored buildpacks. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified _without_ a Git commit SHA like so:
```shell
# using the latest nodejs buildpack
@@ -265,7 +264,6 @@ importantworker: env QUEUE=important bundle exec rake resque:work
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
### `curl` build timeouts
Certain buildpacks may time out in retrieving dependencies via `curl`. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a `curl` command.

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

@@ -36,7 +36,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.

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

@@ -293,7 +293,7 @@ Invalid container id specified (APP.web.3)
In this example, a Rails application is successfully deployed to Dokku. The initial round of checks fails while the server is starting, but once it starts they succeed and the deployment is successful. `WAIT` is set to `10` because our application takes a while to boot up. `ATTEMPTS` is set to `6`, but the third attempt succeeds.
### `CHECKS` file
### Successful `CHECKS` file
```
WAIT=10
@@ -307,7 +307,7 @@ For this check to work, we've added a line to `config/routes.rb` that simply ret
get '/check.txt', to: proc {[200, {}, ['simple_check']]}
```
### Deploy output
### Successful deploy output
> Note: The output has been trimmed for brevity.
@@ -370,7 +370,7 @@ In this example, a Rails application fails to deploy. The reason for the failure
Once the attempts have been exceeded, the deployment fails and we see the container output, which shows the PostgreSQL connection errors.
### `CHECKS` file
### Failing `CHECKS` file
```
WAIT=10
@@ -380,7 +380,7 @@ ATTEMPTS=6
> The check to the root url `/` would normally access the database.
### Deploy output
### Failing deploy output
> Note: The output has been trimmed for brevity.