|
| 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 | +Presently, the VM images are stored in container disks in the **[Harbor registry](../docker-registry/README.md)**. Storing and using VM images directly would make the process of VM instantiation more efficient. This is accomplished by introducing the **Cloud Image Registry**. |
| 23 | + |
| 24 | +The new component also stores metadata about every image, which is necessary for future CrownLabs features that require additional image-related information. |
| 25 | + |
| 26 | +--- |
| 27 | + |
| 28 | +## How to use it |
| 29 | + |
| 30 | +### **Deployment Setup** |
| 31 | +The registry currently runs inside the Kubernetes cluster and is **accessible only via an internal network**. The setup consists of: |
| 32 | +- A **Deployment** running the custom Golang server. |
| 33 | +- A **ClusterIP Service** for internal access. |
| 34 | +- A **Persistent Volume Claim (PVC)** to store image files. |
| 35 | + |
| 36 | +**Note:** Future updates may include exposing the service externally via an **Ingress** resource. |
| 37 | + |
| 38 | +### **Configuration Options** |
| 39 | +Some server options can be configured through **command-line flags** in the deployment [manifest](../../operators/deploy/cloudimg-registry/templates/deployment.yaml): |
| 40 | +- `--listener-addr` → Server listen address (default: `localhost:8080`) |
| 41 | +- `--data-root` → Root directory of the registry inside PVC |
| 42 | +- `--read-header-timeout-secs` → Timeout for reading headers in HTTP requests |
| 43 | + |
| 44 | +### **API Endpoints** |
| 45 | +All interactions happen via HTTP requests. Below is a table summarizing the available endpoints: |
| 46 | + |
| 47 | +| Method | Endpoint | Description | |
| 48 | +|--------|----------------------------------|-----------------------------| |
| 49 | +| **GET** | `/reg` | Lists all existing repositories. | |
| 50 | +| **GET** | `/reg/{repo}` | Lists all images inside a repository. | |
| 51 | +| **GET** | `/reg/{repo}/{image}` | Lists all available tags for an image. | |
| 52 | +| **GET** | `/reg/{repo}/{image}/{tag}` | Serves the image file for an image tag. | |
| 53 | +| **GET** | `/reg/{repo}/{image}/{tag}/meta` | Serves the metadata JSON file for an image tag. | |
| 54 | +| **POST** | `/reg/{repo}/{image}/{tag}` | Uploads an image with its metadata. **Request body:** `meta` (metadata JSON), `img` (image file). | |
| 55 | +| **DELETE** | `/reg/{repo}/{image}/{tag}` | Deletes an image and its metadata. If it's the last tag/image, the image/repo directory is removed. | |
| 56 | + |
| 57 | +**Note:** `reg` in the endpoints above is a default registry prefix which can also be configured using `--repo-prefix` command-line flag. |
| 58 | + |
| 59 | +**Example Base URL:** |
| 60 | +For a server running at `192.168.0.1:8080`, with the default registry prefix (`reg`), the following request would be valid: |
| 61 | + |
| 62 | +- **List all repositories:** |
| 63 | + ```sh |
| 64 | + curl -X GET http://192.168.0.1:8080/reg |
0 commit comments