Docker Apps¶

Permission to Push Docker Apps¶

Because certain Docker images can potentially expose a root user and other escalated privileges, Helion Stackato administrators should generally restrict the ability to push Docker images to:

• a trusted group of users in an organization with sudo permissions enabled
• a trusted list of Docker images, namespaces, or registry servers
• a trusted group deploying from a trusted list

Depending on which restrictions your Helion Stackato administrator has set, an error message describing the restriction may be displayed when you attempt to push an application as an unauthorized user:

Error staging: Need 'allow_sudo' quota to stage and run a Docker app (400)

An error may also be displayed when you attempt to push an unauthorized image:

Error staging: Docker image example/simple-server is not from an allowed registry (400)

Pushing Docker Apps¶

You can specify official Docker Hub library images by name, with or without a tag. For example:

$ stackato push --docker-image tomee:8-jre-7.0.0-M1-webprofile

You can also specify images from a particular user or organization by namespace, for example:

$ stackato push --docker-image cloudfoundry/lattice-app

Images from a particular registry server require a fully-qualified URL (without the protocol portion):

$ stackato push --docker-image registry.example.com/user/docker-app:latest

For registries that requires authentication, use the <user>:<pass>@<host> format to specify credentials:

$ stackato push --docker-image myname:mypass@reg.example.com/myname/myapp

Administrators can save default credentials for specific servers in the Allowed Registries list. Stackato uses these credentials for a specific registry server, if it is present. However, any credentials specified in the command override the default credentials.

Docker Apps and Data Services¶

Docker apps can be bound to data services like staged apps. $VCAP_SERVICES, $STACKATO_SERVICES, and URL-based environment variables are injected into the container and can be read by the application. For instructions on creating data service instances and binding them to applications, see the Data Services documentation.

Docker apps do not have staging hooks:, so there is no opportunity to extract and reformat credentials into the format the Docker app expects. To circumvent this issue you can do one of the following:

1. Refactor the Docker app to consume the default service variables.
2. Bind the new service to a temporary app (for example, go-env or node-env) to find the service instance credentials, and then set the environment variables the Docker app expects using the web console, the --env option of the CLI client, or in the manifest.yml file.

Web Process and Exposed Ports¶

The $PORT environment variable exposed in staged apps is also available for Docker apps to use for web processes. For example, a Dockerfile may end with the following line:

ENTRYPOINT /usr/bin/python manage.py runserver 0.0.0.0:$PORT

This parameter serves the web process on a port automatically allocated by Helion Stackato.

If the app's Dockerfile exposes a single port (for example, EXPOSE 8080), Helion Stackato will forward that port instead.