ISIMA / LIMOS Image Registry✯
The ISIMA/LIMOS provides its community with a container image registry (Docker / OCI) accessible at:
This registry is powered by Harbor, an open source registry from the CNCF. It allows you to store, share, analyze, and distribute your container images within the establishment.
Why an internal registry?
- Store your own images (built for your labs, projects, research deployments…)
- Share your images, publicly or privately, with individuals or groups
- Proxy public registries (Docker Hub, ghcr.io…) for faster downloads from ISIMA and without bandwidth/quota limits imposed by these registries
- Analyze the security of your images using the Trivy vulnerability scanner
- Integrate your GitLab CI/CD pipelines
Essential Concepts✯
An image stored in the registry is always named according to the following scheme:
registry.isima.fr/<project>/<repository>:<tag>
└──────┬────────┘ └───┬──┘ └──┬─┘ └─┬─┘
the registry the project the repository the version
- A project is the organizational and permission unit of the registry. You create your own projects, decide if they are public or private, and invite members or groups to them.
- A repository corresponds to an image (e.g.
my-app) and can contain multiple tags (versions).
Getting Started✯
| Step | Documentation |
|---|---|
| Connect to the registry (Web and command line) | Authentication |
| Organize and share your images | Projects, members and groups |
Push and pull images with docker |
Using with Docker |
| Automate access (CI/CD, scripts) | Robot accounts |
| Analyze the security of your images | Trivy vulnerability scanner |
| Check allocated disk space | Quotas |
Speed up pull from public registries |
Proxy Cache |
| Integrate the registry with GitLab | GitLab CI/CD integration |
Best Practices✯
Never store secrets in an image
An image pushed to the registry can be read by others (and remains in the layer history). Ensure no secrets (passwords, API keys, tokens, private certificates…) are included. See the nightmare of secret leaks in Docker images.
Monitor your image sizes
An image larger than 1 GB is undesirable for both storage and use. Prefer lightweight base images (alpine, -slim…) and multi-stage builds.
Having issues with Docker in a teaching context?
Check the Docker section of Known Issues with Teaching Resources.