Image Sources
Image sources are used to group imports of an image together. Image sources can be configured for a myriad of different origins, and can be imported directly from another registry or built off of a Dockerfile via source code or tarball using the factory core service.
The image source stores the configurations and credentials necessary for creating or importing new image builds from its origin.
Docker Hub Image Source
The Docker Hub source can be used to pull images directly off of Docker Hub with minimal configuration.
Target
The Docker Hub source requires a target, composed of a image string identical to what's used with docker pull commands.
organization/image:tag
Authorization
For private images, an access token will be necessary for Cycle to be able to pull images from the registry.
See: how to create a Docker access token .
Create a Docker Hub Image Source
Docker Registry Image Source
The Docker Registry source is for importing images from a self-hosted or private Docker registry.
Target
Similar to the Docker Hub source requires a target, composed of a image string identical to what's used with docker pull commands. The Docker Registry source also requires the URL of the registry.
The Docker Registry target generally looks like:
url/organization/image:tag
Authorization
Authorization for a Docker Registry source typically consists of a username/password combination, or an access token such as that used on the Docker Hub source.
Create a Docker Registry Image Source
OCI Registry Image Source
The OCI Registry source is for integrating with OCI compatible image sources. The best examples are ECR, GCR, ACR, and the GitHub container registry.
Target
The OCI Registry target is identical to the Docker Registry image source:
url/organization/image:tag
Authorization
Given the various types and implementations of OCI image registries, Cycle supports various different methods for authentication.
- User - A simple username & password or token.
- Webhook - Webhook-based authentication to the provided URL. This webhook expects to receive a base-64 string GET response that when decoded is in the format username:password.
- Provider - Cycle provides certain abstractions over provider-specific authentication. Currently, only AWS ECR is supported.
Create an OCI Registry Image Source
Dockerfile Image Source
The Dockerfile Image Source is for building images directly off of a Dockerfile, with support for Git Repositories and tar.gz packages. Building these images is handled by the factory core service operated by Cycle.
Target
There are two targets available for Dockerfile sources.
- Git Repository - Requires a hosted git repository containing a Dockerfile, and any files necessary to do the build.
- tar.gz - Requires a web-accessible tar.gz package, containing the Dockerfile and any necessary files to do the build.
Authorization
Git Repository
When working with a git repository, both HTTPS and SSH protocols are supported.
Using HTTPS for repository authentication will require the entry of a username and password that has, at a minimum, read access. SSH will require you to enter a private, pem-encoded key as well as a username, the passphrase is optional and only needed if your key requires a passphrase to use.
Generating an SSH Key
ssh-keygen -t ecdsa -b 256 -m PEM -f your-filename.pemThis command will produce two files, the public and private key. Depending on your repository service you'll need to add the public key at the account or repository level and then add the private key to your Cycle image source.
For example: Github has both account level keys and "Deploy Keys" - each scoped to account and repositories respectively.
Authorizing Against Sub-Registries
Multiple sets of credentials can be provided for authorizing against registries the Dockerfile depends on to be built.
Context Directories and Build Files
Regardless of the Dockerfile location (repo or hosted tar.gz), a context directory and build file will need to be provided.
The build file is the full path to and including the name of the Dockerfile to be used for the build. Leaving this field empty when using the portal will submit the default value of /Dockerfile. In the picture below app-one's build file would be /app-one/Dockerfile.
A context directory is the full path from the root of a resource to the directory to use as the context when fulfilling commands like COPY.
The following image shows two projects. The project in the top window has two applications sharing a single root context and separated into two directories with each one holding an individual Dockerfile responsible for creating that services image. The bottom window shows a single application with the Dockerfile in the root context.
Branches, Tags And Hashes
For git repositories, users are also asked to supply the branch to be used when pulling files. This branch information can be enriched by the optional values supplied to tag or hash.
Tag - A git tag, to be used to target a specific tag created by the user to denote a version or moment in their commit history pertaining to some relevant state.
Hash - A commit hash, specifically, that points to the desired commit to be used when referencing the repository files.
Hashes and Branches
The hash must be correctly aligned with the branch. If you enter a hash for your development branch, but the branch you supply is not specifically development Cycle will use the most recent commit for the branch provided.