Deploying Docker images
As an alternative to using buildpacks, you can push applications based on Docker.
The only way to push Docker applications right now is through a public Docker registry. We will enable a private registry in the future.
To push a Docker image, use the
-o flag when pushing your app, for example:
cf push lattice-app -o cloudfoundry/lattice-app
If you want to build your own Docker image, or if you want to read more, check out the Docker documentation in the Cloud Foundry project.
Once you push a Docker image as your application, cloud.gov cannot update the baseline for your application, so you are responsible for keeping it up to date. You are responsible for maintaining the operating system, libraries, application code, and all of the associated configuration (losing some of the benefits of a PaaS environment). See this chart of responsibilities.
Here are some considerations to keep in mind when deciding to use Docker images instead of supported buildpacks in your application’s deployment:
|Supported buildpack||Docker container|
|Pros||It “just works”.
Automatic and constant security updates.
All you need to do is write code.
|Can build container images and run containers on local workstation.
Fine-grained control over compilation and root filesystem.
|Cons||Difficult to recreate the execution environment locally.
Testing compilation and the result of staging is harder.
|Added responsibility for all security updates and bug fixes.
More compliance responsibility means more work.
Docker as tasks
There is a Cloud Foundry API for tasks creation. This allows single, one-off tasks to be triggered through the API.