Skip to content

Commit f3e7717

Browse files
committed
doc: Add documentation for backup feature
The DevWorkspaceOperatorConfig was extended to enable the workspace backup process. This commits describes the feature and how to configure it. Signed-off-by: Ales Raszka <[email protected]>
1 parent bcbaf1a commit f3e7717

File tree

1 file changed

+95
-0
lines changed

1 file changed

+95
-0
lines changed

docs/dwo-configuration.md

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -107,6 +107,101 @@ Cleanup CronJob configuration fields:
107107
- **`retainTime`**: The duration time in seconds since a DevWorkspace was last started before it is considered stale and eligible for cleanup. Default: 2592000 seconds (30 days).
108108
- **`dryRun`**: Set to `true` to run the cleanup job in dry-run mode. In this mode, the job logs which DevWorkspaces would be removed but does not actually delete them. Set to `false` to perform the actual deletion. Default: `false`.
109109

110+
## Configuring Backup CronJob
111+
112+
The DevWorkspace backup job allows for periodic backups of DevWorkspace data to a specified backup location.
113+
Once enabled and configured, the backup job will run at defined intervals to create backups of DevWorkspace data.
114+
The backup controller depends on an OCI-compatible registry e.g., [quay.io](https://quay.io/) used as an image artifact storage for backup archives.
115+
116+
The backup makes a snapshot of Workspace PVCs and stores them as tar.gz archives in the specified OCI registry.
117+
**Note:** By default, the DevWorkspace backup job is disabled.
118+
119+
120+
Backup CronJob configuration fields:
121+
122+
- **`enable`**: Set to `true` to enable the backup job, `false` to disable it. Default: `false`.
123+
- **`schedule`**: A Cron expression defining how often the backup job runs. Default: `"0 1 * * *"`.
124+
- **`registry.path`**: A base registry location where the backup archives will be pushed.
125+
The value provided for registry.path is only the first segment of the final location. The full registry path is assembled dynamically, incorporating the name of the workspace and the :latest tag, following this pattern:
126+
`<registry.path>/<devworkspace-name>:latest`
127+
128+
- **`registry.authSecret`**: (Optional) The name of the Kubernetes Secret containing credentials to access the OCI registry. If not provided, it is assumed that the registry is public or uses integrated OpenShift registry.
129+
- **`oras.extraArgs`**: (Optional) Additional arguments to pass to the `oras` CLI tool during push and pull operations.
130+
131+
132+
There are several configuration options to customize the logic:
133+
134+
### Integrated OpenShift container registry
135+
This option is available only on OpenShift clusters with integrated container registry enabled and requires no additional configuration.
136+
137+
To enable the backup use following configuration in the global DWOC:
138+
139+
```yaml
140+
apiVersion: controller.devfile.io/v1alpha1
141+
kind: DevWorkspaceOperatorConfig
142+
config:
143+
routing:
144+
defaultRoutingClass: basic
145+
workspace:
146+
backupCronJob:
147+
enable: true
148+
registry:
149+
path: default-route-openshift-image-registry.apps.{cluster ID}.openshiftapps.com
150+
schedule: '0 */4 * * *' # cron expression with backup frequency
151+
imagePullPolicy: Always
152+
```
153+
154+
**Note:** The `path` field must contain the URL to your OpenShift integrated registry given by the cluster.
155+
156+
Once the backup job is finished the backup archives will be available in the DevWorkspace namespace under a repository
157+
with matching Devworkspace name.
158+
159+
### Regular OCI compatible registry
160+
To use a regular OCI compatible registry for backups, you need to provide registry credentials. Depending on your
161+
RBAC policy the token can be provided via a secret in the operator namespace or in each DevWorkspace namespace.
162+
Having the secret in the DevWorkspace namespace allows for using different registry accounts per namespace with more
163+
granular access control.
164+
165+
166+
```yaml
167+
kind: DevWorkspaceOperatorConfig
168+
apiVersion: controller.devfile.io/v1alpha1
169+
config:
170+
routing:
171+
defaultRoutingClass: basic
172+
workspace:
173+
backupCronJob:
174+
enable: true
175+
registry:
176+
authSecret: my-secret
177+
path: quay.io/my-company-org
178+
schedule: '0 */4 * * *'
179+
imagePullPolicy: Always
180+
```
181+
The `authSecret` must point to real Kubernetes Secret of type `kubernetes.io/dockerconfigjson` containing credentials to access the registry.
182+
183+
To create one you can use following command:
184+
185+
```bash
186+
kubectl create secret docker-registry my-secret --from-file=config.json -n devworkspace-controller
187+
```
188+
The secret must contain a label `controller.devfile.io/watch-secret=true` to be recognized by the DevWorkspace Operator.
189+
```bash
190+
kubectl label secret my-secret controller.devfile.io/watch-secret=true -n devworkspace-controller
191+
```
192+
193+
### Restore from backup
194+
We are aiming to provide automated restore functionality in future releases. But for now you can still
195+
manually restore the data from the backup archives created by the backup job.
196+
197+
Since the backup archive is available in OCI registry you can use any OCI compatible tool to pull
198+
the archive locally. For example using [oras](https://github.com/oras-project/oras) cli tool:
199+
200+
```bash
201+
oras pull <registry-path>/<devworkspace-name>:latest
202+
```
203+
The archive will be downloaded as a `devworkspace-backup.tar.gz` file which you can extract and restore the data.
204+
110205
## Configuring PVC storage access mode
111206

112207
By default, PVCs managed by the DevWorkspace Operator are created with the `ReadWriteOnce` access mode.

0 commit comments

Comments
 (0)