|
| 1 | +# Cloud Image Registry |
| 2 | + |
| 3 | +## Table of Contents |
| 4 | +- [What is it?](#what-is-it) |
| 5 | +- [Why do we need it?](#why-do-we-need-it) |
| 6 | +- [How to use it](#how-to-use-it) |
| 7 | + |
| 8 | +--- |
| 9 | + |
| 10 | +## What is it? |
| 11 | + |
| 12 | +**Cloud Image Registry** is an image storage solution designed to store and serve VM images within a Kubernetes cluster. It consists of: |
| 13 | +- A custom **Golang server** running as a Kubernetes **Deployment**. |
| 14 | +- A **Persistent Volume Claim (PVC)** that acts as the storage backend for the images. |
| 15 | + |
| 16 | +The server provides a set of HTTP endpoints to **upload, download, and manage images and their metadata**. |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +## Why do we need it? |
| 21 | + |
| 22 | +There is already a private container registry, **[Harbor](../docker-registry/README.md)**, present in our setup to store VM images. The goal of introducing it was to reduce external internet traffic and improve user experience when deploying VMs. |
| 23 | + |
| 24 | +However, it was discovered later that **storing VM images in a PVC inside the cluster significantly accelerates VM instantiation**. Therefore, we developed this **Cloud Image Registry** to: |
| 25 | +1. **Enhance VM startup times** by providing an internal, fast-access storage for VM images. |
| 26 | +2. **Retain image metadata**, allowing future extensions and features that depend on additional image details. |
| 27 | + |
| 28 | +--- |
| 29 | + |
| 30 | +## How to use it |
| 31 | + |
| 32 | +### **Deployment Setup** |
| 33 | +The registry currently runs inside the Kubernetes cluster and is **accessible only via an internal network**. The setup consists of: |
| 34 | +- A **Deployment** running the custom Golang server. |
| 35 | +- A **ClusterIP Service** for internal access. |
| 36 | +- A **Persistent Volume Claim (PVC)** to store image files. |
| 37 | + |
| 38 | +**Note:** Future updates may include exposing the service externally via an **Ingress** resource. |
| 39 | + |
| 40 | +### **Configuration Options** |
| 41 | +Some server options can be configured through **command-line flags** in the deployment [manifest](../../operators/deploy/cloudimg-registry/templates/deployment.yaml): |
| 42 | +- `--listener-addr` → Server listen address (default: `localhost:8080`) |
| 43 | +- `--data-root` → Root directory of the registry inside PVC |
| 44 | +- `--read-header-timeout-secs` → Timeout for reading headers in HTTP requests |
| 45 | + |
| 46 | +### **API Endpoints** |
| 47 | +All interactions happen via HTTP requests. Below is a table summarizing the available endpoints: |
| 48 | + |
| 49 | +| Method | Endpoint | Description | |
| 50 | +|--------|----------------------------------|-----------------------------| |
| 51 | +| **GET** | `/reg` | Lists all existing repositories. | |
| 52 | +| **GET** | `/reg/{repo}` | Lists all images inside a repository. | |
| 53 | +| **GET** | `/reg/{repo}/{image}` | Lists all available tags for an image. | |
| 54 | +| **GET** | `/reg/{repo}/{image}/{tag}` | Serves the image file for an image tag. | |
| 55 | +| **GET** | `/reg/{repo}/{image}/{tag}/meta` | Serves the metadata JSON file for an image tag. | |
| 56 | +| **POST** | `/reg/{repo}/{image}/{tag}` | Uploads an image with its metadata. **Request body:** `meta` (metadata JSON), `img` (image file). | |
| 57 | +| **DELETE** | `/reg/{repo}/{image}/{tag}` | Deletes an image and its metadata. If it's the last tag/image, the image/repo directory is removed. | |
| 58 | + |
| 59 | +**Note:** `reg` in the endpoints above is a default registry prefix which can also be configured using `--repo-prefix` command-line flag. |
| 60 | + |
| 61 | +**Example Base URL:** |
| 62 | +For a server running at `192.168.0.1:8080`, with the default registry prefix (`reg`), the following request would be valid: |
| 63 | + |
| 64 | +- **List all repositories:** |
| 65 | + ```sh |
| 66 | + curl -X GET http://192.168.0.1:8080/reg |
0 commit comments