In Kubernetes, Deployment/Pods run container images that are pulled from image stores designed as Registries. In CloudManager, a user can defines multiple Registries from where to pull the images used by containers in managed Deployments. Additionally, a Registriy needs to be selected when an image is build from a GIT Repository using CI/CD tasks. The Registry configuration includes the required credentials details to pull/push images to/from.
The images pulled from Registries follow the Docker format, and thus are often designed as Docker images even if the Docker runtime is not involved. The term image repository is also used to designed a set of related images stored in the same Registry that have the same base name and differ only in a tag, and normally used to designate and store images fir different versions of the same application. Each image has a unique identifier of the form
[domain/]repository[:tag], where the
domain identifies the Registry (ie. the DNS
host.domain with the API endpoints),
repository is the name of the repository, and
tag specifies which the image “version”. The tag is optional, and if so this implies the “special/default” tag
latest. The Registry
domain is also optional, and when not specified fall backs to the original registry DockerHub.
Notice that the default tag “latest” simply means “the last build/tag that ran without a specific tag/version specified”, and not necessarily the last (most-recent) image pushed to a repository. As this may lead to some confusion, some developer advocates recommend against or suggest avoiding using the “latest”/default tag, and recommend always specify an explicit tag.
Image and image repositories manged by Registry have ownership and security details associated with it, and are setup as public or private:
Pushing images to a Registry usually require that credentials are provided, both for public and private images.
Registries are a top level abstraction in CloudManager, and each user can configure access to several Registries. These Registries can then be selected from when configuring the images of managed Deployments, and as targets for CI/CD builds. The button Registries in the top-right toolbar, navigate to the list of Registries configured by a user. One immutable global registry representing the default DockerHub is automatically available.
CloudManager is not in it self a Registry implementation, but a Registry can optionally be installed in a cluster that is managed by CloudManager.
Image below shows an example of list Registries available to a user:
A user can define any number of Registries. The button Add New in the Registry list page, opens a form page to create a new registry. Several options are available to configure the credentials to access a Registry to accommodate different authentication methods supported by different Registries implementations.
The following fields should be specified when defining a Registry:
Name— descriptive name
Server— URL of the Registry API
Credential Type— Type of authentication credentials to user (None | Username/Password | OAuth2 Token | JSON token)
Username— username or ID specified at signup in the Registry
Images below show examples of Registry definition with private access:
GitHub Packages (right-side).
Any Registry whose API URL and valid credentials are known can be configured. As a convenience, the CloudManager UI provides several “One-Click/Quick-Setup” buttons for commonly used public SasS Registries. Table below provides a summary of these Registries as well as the credential types to use/supported. Notice this list may change with different versions of CloudManager.
|Icon||Registry Name||Server URL||Credential Type(s)|