Last Updated: November 22, 2024 A container registry is a collection of repositories designed to efficiently store and distribute container images. SCE integrates with the most popular container registries, allowing you to use your existing build pipelines to create and manage your container images. When a Container Group is created, SaladCloud will automatically pull the image from your registry into a private container registry that is managed by Salad, allowing us to generate 1-time access tokens that are only distributed to specific machines that are designated to run your application. SaladCloud supports both Public and Private Registries, many providers offer both options depending on your specific requirements. A private registry allows users to store and distribute container images without making them publicly accessible. This allows for better control over the distribution of images, as well as the ability to keep proprietary or sensitive information secure.

​
Specifying the Container Image Source

When configuring a Container Group for deployment, you’ll need to specify the source of the container image. If your image is hosted on the Docker Hub Registry, you don’t need to include the registry name. If your image is hosted on another registry, such as GitHub Container Registry, you’ll need to include the registry path. This path is similar to a URL, but doesn’t contain a protocol specifier (e.g. https://). You may optionally append a tag, as well. Note that if no tag is supplied, the :latest tag will be used by default. 
docker manifest inspect $REMOTEIMAGESOURCE
If you’re building using Docker, you can specify the output manifest spec using buildx: 
docker buildx build \
-t $LOCALIMAGESOURCE \
--provenance=false \
--output type=docker \
.

​
Examples

  • Image hosted on Docker Hub, with the tag v1 -
    • Full URL: docker.io/my-name/imagename:v1
    • Shortened URL: my-name/imagename:v1
  • Image hosted on GHCR, latest version - ghcr.io/my-org/imagename

​
Supported Registries

Details of using a Private Container Registry with SaladCloud will vary depending on the private registry used. Guides for supported registries are linked here:
👀 Missing a Registry? We’re working to expand the supported registries on SaladCloud. If you’re using a registry not listed here, please get in touch!

​
Requirements

To use a registry, an image must first be pushed to the registry. This can be done using the docker push command, specifying the registry URL and the image name. Once the image is in the registry, it can be pulled and used to create a new Container Group through the Portal or the Public API.
  • SaladCloud requires authentication details to pull images, but authentication details are only stored long enough to pull the image and place it into encrypted storage for distribution to the SaladCloud Network.
  • When we distribute a workload to a node, we generate a 1 time access token, allowing only specific node(s) to download and run the container image
  • There currently a max image size of 35 GB (note: subject to change)
  • We pull and store images at moment of container group creation, so if the image is modified you will have to create a new container group

​
View Status When Creating a Container Group

  • While the image is being pulled and stored, the container group status will be “pending”
  • Once the image is ready, the container group status will change to stopped, and the container group can be started.

​
Failures

A few unique failures can occur when pulling an image from a registry
  • Failure to authenticate: This will occur if we are unable to authenticate to the private registry with the credentials provided. Double check the credentials are correct and try again.
  • Failure to store: This will occur if we are unable to store the container image. This should be a temporary condition so try again.
  • Image too large: This will occur if the container image is too large. You will need to use a smaller container image.
If issues persist, please contact support here.

​
Caching of Container Images

Encrypting and caching image layers on compatible nodes allows us to start your container images much faster in the event the workload fails over to a new node or you make small updates to your container image. By caching image layers across our network, startup and failover times are significantly decreased for workloads using those image layers. Without image layer caching, any time a new node needs to start your container image, the new node would need to download the entire image. All image layers from public repositories are automatically cached across the network for up to 30 days. Image layers from private repositories are optionally cached for up to 30 days. Image layers from private repositories may be cached for up to 5 minutes to allow for restarts after brief interruptions. Note that all container images across the SaladCloud network are encrypted (AES-256) from when they are pulled up until the image is ready to be started on the node.