Skip to content

Commit

Permalink
Merge pull request #103 from vshn/NextcloudDecision
Browse files Browse the repository at this point in the history
adding Nextcloud decision
  • Loading branch information
wejdross authored Jun 17, 2024
2 parents cdea77f + 234abff commit 6c071c5
Show file tree
Hide file tree
Showing 2 changed files with 65 additions and 0 deletions.
64 changes: 64 additions & 0 deletions docs/modules/ROOT/pages/explanations/decisions/nextcloud.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
= VSHN Managed Nextcloud on Kubernetes

== Problem

We need to provide Nextcloud on Kubernetes with the following features:

* Possibility to Single Sign-On with Keycloak
* Nextcloud Office with Collabora on backend
* PostgreSQL as database
* Extensions management
* full lifecycle of an application: deploy, update, backup, restore, monitoring, scaling, etc.


== Solutions

- helm chart available for Nextcloud: https://github.com/nextcloud/helm
- Writing our own provider-nextcloud

=== Analysis - Helm Chart

The Nextcloud Helm Chart is a good starting point for our offering. It is actively maintained and has a lot of features. It is also the official Helm Chart for Nextcloud.

Nextcloud provides also: https://github.com/nextcloud/all-in-one docker image, which contains a lot of features including Office package.

For backup and restore there is necessity to use a separate solution like k8up.
For extension management we need to provide a custom solution.
There is another helm chart for Office extension: https://open.greenhost.net/stackspin/nextcloud (not official)

Advantages::

* Official Helm Chart
* Actively maintained
* Supports various databases, metrics, persistance, ingress, some basic rbac

Disadvantages::

* We still need to cover a lot of topics manually:
** Maintenance
** Backup and restore
** Extension management
** Office package deployment and integration

=== Analysis - Custom Provider

Writing our own provider would give us the most flexibility. We could implement all the features we need and integrate them into our existing solutions. We could probably handle more features than the Helm Chart.

Advantages::

* Full Flexibility over deployment, backup, restore, monitoring, scaling, etc.
* VSHN would be the first to offer a Nextcloud provider for Kubernetes - unique marketing opportunity

Disadvantages::

* High development effort
* Time consuming
* High risk of introducing bugs

== Decision

We use the Nextcloud Helm Chart.

== Rationale

As I really like concept of writing our own provider, I think that the Nextcloud Helm Chart is a good starting point for our offering. It is actively maintained and has a lot of features already present. It is also the official Helm Chart for Nextcloud. Thanks to composition-functions we can still add features on top of it, like backup and restore, extension management, etc.
1 change: 1 addition & 0 deletions docs/modules/ROOT/partials/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,7 @@
*** xref:app-catalog:ROOT:explanations/decisions/local-objectstorage-provider.adoc[Provider Evaluation]
*** xref:app-catalog:ROOT:explanations/decisions/local-objectstorage-sli.adoc[SLI]
** xref:app-catalog:ROOT:explanations/decisions/mariadb.adoc[MariaDB by VSHN]
** xref:app-catalog:ROOT:explanations/decisions/nextcloud.adoc[Nextcloud by VSHN]
** xref:app-catalog:ROOT:explanations/decisions/secret-pki-mgmt.adoc[Secret and PKI Management by VSHN]
** xref:app-catalog:ROOT:explanations/decisions/capacity-alerting.adoc[Converged Service Capacity Alerting]
** xref:app-catalog:ROOT:explanations/decisions/logging.adoc[Converged Service Logging]
Expand Down

0 comments on commit 6c071c5

Please sign in to comment.