|
1 | | -# Installation |
| 1 | +# Installation & Setup |
2 | 2 |
|
3 | 3 | ```likec4-view |
4 | 4 | ro-crate_service |
5 | 5 | ``` |
6 | 6 |
|
7 | 7 | ## Service Snapshot |
| 8 | +The RO-Crate Validation Service works in two ways: a metadata-only mode, in which the contents of an `ro-crate-metadata.json` file are assessed, and storage-backed validation, where complete RO-Crates (zip or directory) are evaluated. |
8 | 9 |
|
9 | | -Cratey Validator is a web service that checks whether RO-Crates follow the |
10 | | -expected structure and metadata rules. It can validate a complete RO-Crate |
11 | | -stored in MinIO-compatible object storage, or it can validate the contents |
12 | | -of an `ro-crate-metadata.json` file directly. |
| 10 | +## Quick start |
13 | 11 |
|
14 | | -At a high level, a client sends a validation request, the service runs the |
15 | | -RO-Crate validation checks, and the result is either returned directly or |
16 | | -saved so it can be retrieved later. |
| 12 | +You will need Docker with Docker Compose. |
17 | 13 |
|
18 | | -## What You Can Validate |
| 14 | +To start, clone the repository, copy the example environment file, and start the stack: |
19 | 15 |
|
20 | | -### Stored RO-Crates |
| 16 | +```bash |
| 17 | +git clone https://github.com/eScienceLab/RO-Crate-Validation-Service.git |
| 18 | +cd RO-Crate-Validation-Service |
| 19 | +cp example.env .env |
| 20 | +docker compose up --build |
| 21 | +``` |
| 22 | + |
| 23 | +!!! warning |
| 24 | + Remember to update the default `.env` values when running the object store in production. |
21 | 25 |
|
22 | | -Use this option when the RO-Crate already exists in MinIO-compatible object |
23 | | -storage. The service reads the crate from the configured bucket, runs the |
24 | | -validation checks, and saves the validation result back to object storage. |
| 26 | +The API is served at `http://localhost:5001`. Redis and a Celery worker are also started, but these are only used once storage is enabled. |
25 | 27 |
|
26 | | -This is useful for validating complete crates as part of an upload, review, |
27 | | -or publication workflow. |
| 28 | +To check the service is up, run: |
| 29 | + |
| 30 | +```bash |
| 31 | +curl http://localhost:5001/healthz |
| 32 | +``` |
28 | 33 |
|
| 34 | +This returns `{"status": "ok"}`. |
29 | 35 |
|
30 | | -### Metadata Files |
| 36 | +To validate the contents of an `ro-crate-metadata.json` file, post to the metadata endpoint. The [running example](https://www.researchobject.org/ro-crate/specification/1.2/introduction.html#running-example) from the RO-Crate specification is a good test document. |
31 | 37 |
|
32 | | -Use this option when you only need to check the contents of |
33 | | -`ro-crate-metadata.json`. Instead of asking the service to download a full |
34 | | -crate, you submit the metadata JSON directly and receive the validation result |
35 | | -in the response. |
| 38 | +The file needs to be sent as an escaped JSON string, which `jq` can do: |
36 | 39 |
|
37 | | -This is useful for quick checks while editing metadata or before a complete |
38 | | -crate has been assembled. |
| 40 | +```bash |
| 41 | +jq -Rs '{crate_json: .}' ro-crate-metadata.json | curl -X POST http://localhost:5001/v1/ro_crates/validate_metadata -H 'Content-Type: application/json' -d @- |
| 42 | +``` |
39 | 43 |
|
| 44 | +The response contains a `status` of `valid`, `invalid` or `error`, along with the detailed validation. For more information, the [API reference](api.md) describes the endpoints and result format in full. |
40 | 45 |
|
41 | | -### Saved Validation Results |
| 46 | +## Enabling object storage |
42 | 47 |
|
43 | | -After a stored RO-Crate has been validated, the saved validation result can be |
44 | | -retrieved later. This lets another application or user interface show the most |
45 | | -recent validation status without rerunning the checks. |
| 48 | +To validate a complete RO-Crate (zip or directory) held in an object store, set `STORAGE_ENABLED=true` in `.env`. |
46 | 49 |
|
| 50 | +The storage-backed validation mode requires six settings, [described below](#configuration-reference): `S3_ENDPOINT`, `S3_ACCESS_KEY`, `S3_SECRET_KEY`, `S3_BUCKET`, `CELERY_BROKER_URL` and `CELERY_RESULT_BACKEND`. |
47 | 51 |
|
48 | | -## Before You Start |
| 52 | +The service will fail at startup if any are missing. The Compose stack already sets the Celery variables to the bundled Redis, so in practice only the S3 settings in `.env` matter here. |
49 | 53 |
|
50 | | -For stored RO-Crate validation, you need: |
| 54 | +Then start the stack with the bundled development object store (RustFS), run: |
51 | 55 |
|
52 | | -- A MinIO-compatible object store. |
53 | | -- A bucket containing the RO-Crate. |
54 | | -- Access credentials for that bucket. |
55 | | -- The crate identifier used by the object store. |
| 56 | +```bash |
| 57 | +docker compose --profile objectstore up --build |
| 58 | +``` |
56 | 59 |
|
57 | | -For metadata-only validation, you only need the contents of |
58 | | -`ro-crate-metadata.json`. |
| 60 | +RustFS serves the S3 API on port 9000 and a web console at `http://localhost:9001`. Development credentials are set in `example.env`. |
59 | 61 |
|
| 62 | +!!! warning |
| 63 | + The service does not create the bucket itself. Create the bucket in the console or with an S3 client. The bucket name needs to match `S3_BUCKET` (`ro-crates` by default). |
60 | 64 |
|
61 | | -## Running The Service |
| 65 | +Upload an RO-Crate under the prefix: `crates/<id>.zip` for a zipped RO-Crate, or `crates/<id>/` for a directory. Note that for a zipped RO-Crate, `ro-crate-metadata.json` must be at the root of the archive. |
62 | 66 |
|
63 | | -The service can be started with Docker Compose: |
| 67 | +The readiness endpoint checks the object store and broker connections: |
64 | 68 |
|
65 | 69 | ```bash |
66 | | -docker compose up --build |
| 70 | +curl http://localhost:5001/readyz |
67 | 71 | ``` |
68 | 72 |
|
69 | | -For local container development, use: |
| 73 | +## Using your own object store |
70 | 74 |
|
71 | | -```bash |
72 | | -docker compose --file docker-compose-develop.yml up --build |
73 | | -``` |
| 75 | +Any S3-compatible store can be used in place of RustFS, including AWS S3, MinIO and Ceph: set `S3_ENDPOINT`, the credentials and `S3_BUCKET` for your store. In this case, do not run the `objectstore` profile. |
74 | 76 |
|
75 | | -Expected local services: |
| 77 | +If you already use a 1.\* release against MinIO, the [upgrade guide](upgrading.md) maps the old settings to the new ones. |
76 | 78 |
|
77 | | -- Flask API: `http://localhost:5001` |
78 | | -- MinIO API: `http://localhost:9000` |
79 | | -- MinIO console: `http://localhost:9001` |
80 | | -- Redis: `localhost:6379` |
| 79 | +## Configuration reference |
81 | 80 |
|
82 | | -MinIO needs a bucket for RO-Crates, normally `ro-crates`. Bucket versioning |
83 | | -should be enabled so uploaded crate objects can be tracked reliably. |
| 81 | +| Variable | Default | Description | |
| 82 | +|----------|---------|-------------| |
| 83 | +| `STORAGE_ENABLED` | `false` | Enable the stored-crate endpoints and storage checks | |
| 84 | +| `S3_ENDPOINT` | — | Object store endpoint, e.g. `objectstore:9000` (required in storage mode) | |
| 85 | +| `S3_ACCESS_KEY` | — | Object store access key (required in storage mode) | |
| 86 | +| `S3_SECRET_KEY` | — | Object store secret key (required in storage mode) | |
| 87 | +| `S3_BUCKET` | — | Bucket holding crates and results (required in storage mode) | |
| 88 | +| `S3_USE_SSL` | `false` | Use HTTPS to the object store | |
| 89 | +| `S3_REGION` | — | Region; needed for AWS S3 | |
| 90 | +| `S3_CRATE_PREFIX` | `crates` | Key prefix crates are read from | |
| 91 | +| `S3_RESULTS_PREFIX` | `validation-results` | Key prefix results are written to | |
| 92 | +| `CELERY_BROKER_URL` | — | Redis broker URL (required in storage mode; preset in the Compose stack) | |
| 93 | +| `CELERY_RESULT_BACKEND` | — | Celery result backend URL (required in storage mode; preset in the Compose stack) | |
| 94 | +| `PROFILES_PATH` | — | Profiles directory that replaces the bundled profiles | |
| 95 | +| `EXTRA_PROFILES_PATH` | — | Profiles directory added to the bundled profiles | |
| 96 | +| `CACHE_PATH` | `/app/.rocrate-cache` in the published image | Validator HTTP cache location | |
| 97 | +| `VALIDATION_OFFLINE` | `false` | Validate using only the cache, with no network access | |
| 98 | +| `FLASK_ENV` | `development` | Set to `production` to disable debug behaviour | |
84 | 99 |
|
| 100 | +## Custom profiles |
85 | 101 |
|
86 | | -## Configuration |
| 102 | +The validator comes with several RO-Crate profiles, and for the Five Safes RO-Crate, the prebuilt `ghcr.io/esciencelab/ro-crate-validation-service-fivesafes-profile` image has the `five-safes-crate` profile already included; see [Five Safes validation](five-safes.md). |
87 | 103 |
|
88 | | -The main environment variables are: |
| 104 | +To add other profiles, mount a directory into both the `flask` and `celery_worker` containers, and set `EXTRA_PROFILES_PATH` to the mounted path. Note that both containers need the mount as metadata-only validation runs in the API process and stored-crate validation runs in the worker. There is a working example in `docker-compose-develop.yml`. |
89 | 105 |
|
90 | | -- `FLASK_APP`: Flask entrypoint, normally `cratey.py`. |
91 | | -- `FLASK_ENV`: selects development or production config. |
92 | | -- `CELERY_BROKER_URL`: Redis broker URL. |
93 | | -- `CELERY_RESULT_BACKEND`: Redis result backend URL. |
94 | | -- `PROFILES_PATH`: optional path to custom RO-Crate validator profile |
95 | | -definitions. |
96 | | -- `MINIO_ENDPOINT`: default MinIO endpoint used by Docker examples. |
97 | | -- `MINIO_ROOT_USER`: MinIO root username for local development. |
98 | | -- `MINIO_ROOT_PASSWORD`: MinIO root password. |
99 | | -- `MINIO_BUCKET_NAME`: default bucket name used by local setup. |
| 106 | +!!! note |
| 107 | + `EXTRA_PROFILES_PATH` adds the directory to the bundled profiles, whereas `PROFILES_PATH` replaces them entirely. |
100 | 108 |
|
101 | | -API calls also pass MinIO access details in `minio_config`, so the service can validate crates in a specified object store and bucket. |
| 109 | +## Offline validation |
102 | 110 |
|
103 | | -## More Information |
| 111 | +The validator fetches profile and context resources over HTTP and caches them. The published images pre-populate this cache at build time, so setting `VALIDATION_OFFLINE=true` runs validation entirely from the cache, with no network access at runtime. This is useful inside TREs and other restricted networks. |
104 | 112 |
|
105 | | -- For endpoint paths, request bodies, response codes, validation profiles, and |
106 | | -result storage paths, see the [REST API documentation](./rest_api). |
107 | | -- For implementation details, service components, runtime flow, and test |
108 | | -coverage, see the [Architecture documentation](./architecture). |
109 | | -- For deployment context and the architecture diagram, see |
110 | | -[Deployment](./deployment). |
| 113 | +Online validation (the default) also uses and refreshes the same cache. Offline validation requires `rocrate-validator` at 0.10.0 or later, which the published images include. |
0 commit comments