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

Move all deployment methods into their own section

Browse Source 
This makes our support for each method explicit, and also allows us to add more deployment methods in the future.

[ci skip]
This commit is contained in:
Jose Diaz-Gonzalez
2016-07-05 01:16:14 -04:00
parent 29847b7ab6
commit 35947100b8
7 changed files with 14 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
docs/deployment/methods/buildpacks.md Normal file
View File

@@ -0,0 +1,103 @@
# Buildpack Deployment
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:
- Use `dokku config:set` to set the `BUILDPACK_URL` environment variable.
- Add `BUILDPACK_URL` to a committed `.env` file in the root of your repository.
- See the [environment variable documentation](/dokku/configuration/environment-variables/) for more details.
- Create a `.buildpacks` file in the root of your repository.
## 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.
To use a specific buildpack, you can run the following dokku command:
```shell
# replace APP with the name of your application
# replace REPOSITORY_URL with your buildpack's url
dokku config:set APP BUILDPACK_URL=REPOSITORY_URL
# example: using a specific ruby buildpack version
dokku config:set APP BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-ruby.git#v142
```
Please check the documentation for your particular buildpack as you may need to include configuration files (such as a Procfile) in your project root.
## Using multiple buildpacks
You can only set a single buildpack using the `BUILDPACK_URL`, though there may be times when you wish to use multiple buildpacks. To do so, simply create a `.buildpacks` file in the base of your repository. This file should list all the buildpacks, one-per-line. For instance, if you wish to use both the `nodejs` and `ruby` buildpacks, your `.buildpacks` file should contain the following:
```shell
https://github.com/heroku/heroku-buildpack-nodejs.git#v87
https://github.com/heroku/heroku-buildpack-ruby.git#v142
```
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
You may also choose to set just a single buildpack in this file, though that is up to you.
Please check the documentation for your particular buildpack(s) as you may need to include configuration files (such as a Procfile) in your project root.
## Using a specific buildpack version
As Dokku pins all buildpacks via herokuish releases, there may be occasions where a local buildpack version is out of date. If you wish to use a more recent version of the buildpack, you may use any of the above methods to specify a buildpack **without** the git sha attached like so:
```shell
# using the latest nodejs buildpack
# replace APP with the name of your application
dokku config:set APP BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs
```
You may also wish to use a **specific** version of a buildpack, which is also simple
```shell
# using v87 of the nodejs buildpack
# replace APP with the name of your application
dokku config:set APP BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs#v87
```
## Specifying commands via Procfile
While many buildpacks have a default command that is run when a detected repository is pushed, it is possible to override this command via a Procfile. A Procfile can also be used to specify multiple commands, each of which is subject to process scaling. See the [process scaling documentation](/dokku/deployment/process-management/) for more details around scaling individual processes.
A Procfile is a file named `Procfile`. It should be named `Procfile` exactly, and not anything else. For example, `Procfile.txt` is not valid. The file should be a simple text file.
The file must be placed in the root directory of your application. It will not function if placed in a subdirectory.
If the file exists, it should not be empty, as doing so may result in a failed deploy.
The syntax for declaring a `Procfile` is as follows. Note that the format is one process type per line, with no duplicate process types.
```
<process type>: <command>
```
If, for example, you have multiple queue workers and wish to scale them separately, the following would be a valid way to work around the requirement of not duplicating process types:
```Procfile
worker: env QUEUE=* bundle exec rake resque:work
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](/dokku/deployment/process-management/) for more details around scaling individual processes.
## Clearing buildpack cache
Building containers with buildpacks currently results in a persistent `cache` directory between deploys. If you need to clear this cache directory for any reason, you may do so by running the following shell command:
```shell
# replace APP with the name of your application
sudo rm -rf /home/dokku/APP/cache/*
```
## 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.
If you see output similar this when deploying , you may need to override the curl timeouts to increase the length of time allotted to those tasks. You can do so via the `config` plugin:
```shell
dokku config:set --global CURL_TIMEOUT=600
dokku config:set --global CURL_CONNECT_TIMEOUT=30
```

74
docs/deployment/methods/dockerfiles.md Normal file
View File

@@ -0,0 +1,74 @@
# Dockerfile Deployment
> New as of 0.3.15
While Dokku normally defaults to using [heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, you can also use docker's native `Dockerfile` system to define a container.
> Dockerfile support is considered a **Power User** feature. By using Dockerfile-based deployment, you agree that you will not have the same comfort as that enjoyed by Buildpack users, and Dokku features may work differently. Differences between the two systems will be documented here.
To use a dockerfiles for deployment, commit a valid `Dockerfile` to the root of your repository and push the repository to your Dokku installation. If this file is detected, Dokku will default to using it to construct containers **except** in the following two cases:
- The application has a `BUILDPACK_URL` environment variable set via the `dokku config:set` command or in a committed `.env` file. In this case, Dokku will use your specified buildpack.
- The application has a `.buildpacks` file in the root of the repository. In this case, Dokku will use your specified buildpack(s).
## Exposed ports
> Changed as of 0.5.0
Dokku will extract all tcp ports exposed using the `EXPOSE` directive (one port per line) and setup nginx to proxy the same port numbers to listen publicly. If you would like to change the exposed port, you should do so within your `Dockerfile` and app.
> 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.
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'd like to investigate alternative proxy methods, please refer to our [proxy management documentation](/dokku/advanced-usage/proxy-management/).
## Customizing the run command
By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base nodejs image, with the following `ENTRYPOINT`:
```Dockerfile
ENTRYPOINT ["node"]
```
You can do:
```shell
dokku config:set APP DOKKU_DOCKERFILE_START_CMD="--harmony server.js"
```
To tell docker what to run.
Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disable docker's image layer cache. Lastly, for more granular build control, you may also pass any `docker build` option to `docker`, by setting `$DOKKU_DOCKER_BUILD_OPTS`.
### Procfiles and Multiple Processes
> New as of 0.5.0
You can also customize the run command using a `Procfile`, much like you would on Heroku or
with a buildpack deployed app. The `Procfile` should contain one or more lines defining [process
types and associated commands](https://devcenter.heroku.com/articles/procfile#declaring-process-types).
When you deploy your app a Docker image will be built, the `Procfile` will be extracted from the image
(it must be in the folder defined in your `Dockerfile` as `WORKDIR` or `/app`) and the commands
in it will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
```Procfile
web: bin/run-prod.sh
worker: bin/run-worker.sh
```
And `Dockerfile`:
```Dockerfile
FROM debian:jessie
WORKDIR /app
COPY . ./
CMD ["bin/run-dev.sh"]
```
When you deploy this app the `web` process will automatically be scaled to 1 and your Docker container
will be started basically using the command `docker run bin/run-prod.sh`. If you want to also run
a worker container for this app, you can run `dokku ps:scale worker=1` and a new container will be
started by running `docker run bin/run-worker.sh` (the actual `docker run` commands are a bit more
complex, but this is the basic idea). If you use an `ENTRYPOINT` in your `Dockerfile`, the lines
in your `Procfile` will be passed as arguments to the `ENTRYPOINT` script instead of being executed.

147
docs/deployment/methods/images.md Normal file
View File

@@ -0,0 +1,147 @@
# Image Tag Deployment
> New as of 0.4.0
The dokku tags plugin allows you to add docker image tags to the currently deployed app image for versioning and subsequent deployment.
```
tags <app> # List all app image tags
tags:create <app> <tag> # Add tag to latest running app image
tags:deploy <app> <tag> # Deploy tagged app image
tags:destroy <app> <tag> # Remove app image tag
```
For exampple, you can list all tags for a given application:
```shell
dokku tags node-js-app
```
```
=====> Image tags for dokku/node-js-app
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
dokku/node-js-app latest 936a42f25901 About a minute ago 1.025 GB
```
You can also create new tags for that app using the `tags:create` function. Tags should conform to the docker tagging specification for your docker version. As of 1.10, that specification is available [here](https://github.com/docker/docker/blob/master/image/spec/v1.1.md), while users of older versions can check the documentation [here](https://github.com/docker/docker/blob/master/image/spec/v1.md).
```shell
dokku tags:create node-js-app v1
```
```
=====> Added v1 tag to dokku/node-js-app
```
Once the tag is created, you can see the output by running the `tags` command again.
```shell
dokku tags node-js-app
```
```
=====> Image tags for dokku/node-js-app
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
dokku/node-js-app latest 936a42f25901 About a minute ago 1.025 GB
dokku/node-js-app v1 936a42f25901 About a minute ago 1.025 GB
```
Finally, you can also deploy a local image using the `tags:deploy` command.
```shell
dokku tags:deploy node-js-app v1
```
```
-----> Releasing node-js-app (dokku/node-js-app:v1)...
-----> Deploying node-js-app (dokku/node-js-app:v1)...
-----> Running pre-flight checks
For more efficient zero downtime deployments, create a file CHECKS.
See http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/ for examples
CHECKS file not found in container: Running simple container check...
-----> Waiting for 10 seconds ...
-----> Default container check successful!
=====> node-js-app container output:
Detected 512 MB available memory, 512 MB limit per process (WEB_MEMORY)
Recommending WEB_CONCURRENCY=1
> node-js-app@0.1.0 start /app
> node index.js
Node app is running at localhost:5000
=====> end node-js-app container output
-----> 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
=====> Application deployed:
http://node-js-app.dokku.me
```
## Deploying from a Docker Registry
You can alternatively add image pulled from a docker Registry and deploy app from it by using tagging feature. In this example, we are deploying from Docker Hub.
1. Create dokku app as usual
```shell
dokku apps:create test-app
```
2. Pull image from Docker Hub
```shell
docker pull demo-repo/some-image:v12
```
3. Retag the image to match the created app
```shell
docker tag demo-repo/some-image:v12 dokku/test-app:v12
```
4. Deploy tag
```shell
dokku tags:deploy test-app v12
```
> Note: When deploying an image, we will use `docker inspect` to extract the `ExposedPorts` configuration and if defined, use that to populate `DOKKU_DOCKERFILE_PORTS`. If this behavior is not desired, you can override that configuration variable with the `config:set` command.
> Example: `dokku config:set test-app DOKKU_DOCKERFILE_PORTS="5984/tcp 80/tcp"`
## Deploying an image from CI
To ensure your builds are always reproducible, it's considered bad practice to store build
artifacts in your repository. For some projects however, building artifacts during deployment
to dokku may affect the performance of running applications.
One solution is to build a finished Docker image on a CI service (or even locally) and deploy
it directly to the host running dokku.
1. Build image on CI (or locally)
```shell
docker build -t dokku/test-app:v12
# Note: The image must be tagged `dokku/<app-name>:<version>`
```
2. Deploy image to dokku host
```shell
docker save dokku/test-app:v12 | ssh my.dokku.host "docker load | dokku tags:deploy test-app v12"
```
> Note: You can also use a Docker Registry to push and pull
> the image rather than uploading it directly.
Here's a more complete example using the above method:
```shell
# build the image
docker build -t dokku/test-app:v12
# copy the image to the dokku host
docker save dokku/test-app:v12 | bzip2 | ssh my.dokku.host "bunzip2 | docker load"
# tag and deploy the image
ssh my.dokku.host "dokku tags:create test-app previous; dokku tags:deploy test-app v12 && dokku tags:create test-app latest"
```