Docker Registries

When specifying an image to use for a role, you can either:

Choose to reference an existing image from a Docker registry.
Build an image from a local directory containing a Dockerfile and, optionally, some scripts to include in that image.

In general:

If you are building an EPIC app using a locally built image, that image will be embedded in the final app binary. If you are referencing an existing image, then you must provide a registry URL from which to pull the image when the app is deployed.
You must always provide the registry if you are building a KubeDirector app, because KubeDirector must pull the image from the registry during deployment. If you choose to build the image locally, it will be pushed to the registry that you specify.
Hewlett Packard Enterprise recommends using a Docker Hub account to pull the images. If you are using public repository and not Docker Hub account, you may face the Docker Hub Rate Limiting issue. To create Docker Hub accounts, see Docker Hub accounts.

Image Repo Tags

Repo-tags take the following form:

[REGISTRY_URL/]REPOSITORY/NAME:TAG

You must include the registry component in the repo-tag that you provide in the App Workbench Images screen when pushing or pulling an image to/from a registry, in the same manner as using the repo-tag in a docker pull or docker push command. Omitting from the repo-tag will default to the Docker Hub Registry (hub.docker.com). The repo-tag usually contains the repository within the registry when specifying an image. Omitting this as well as the registry assumes that the repository is an official Docker Hub Registry image. The following examples describe how repo-tags are interpreted:

nginx:1.19 - Refers to an official Docker Hub image.
bluedata/mysql:1.0 - Refers to an image within the bluedata repository on Docker Hub.
quay.io/bitnami/nginx:latest - Refers to an image on RedHat's quay.io registry under the bitnami repository.

Repositories can be public or private. It is not necessary to supply credentials to pull from a public repository; you must, however, supply credentials in order to pull from a private repository from an account with access to that repository. This is typically done via a docker login command. Acount access is always necessary to push to a repository. App Workbench therefore needs account access for that repository within the registry when building KubeDirector apps where an image is pushed to a repository,

There are two ways to provide a docker login context to App Workbench:

Option 1: Either before or after the App Workbench container has been launched, but before building and pushing images:
```
$ docker login <server>[:<port>]
```
After the image has been built, you can logout:
```
$ docker logout <server>[:<port>]
```
Repo-tags used for the role images will be of the form:
```
<server>[:<port>]/<myrepo>/<image>:<tag>
```

NOTE You may only use one registry per application.

Option 2: Supply credentials through environment variables. Be aware that this exposes them in plain text. Environment variables must be placed in a file called .env at the top level of the workspace directory. This must be done before launching the App Workbench container.
```
$ cat .env
        AWB_REGISTRY_USERNAME=<user>
        AWB_REGISTRY_PASSWORD=<password>
```