A NextCloud Kubernetes deployment with Apache, MariaDB, Cron, and Redis. Based on the code found in this article on Medium, and subsequently modified.
- A functional k8s cluster.
- A dedicated namespace for this project (default is
nextcloud
). - An Ingress provider (I use
ingress-nginx
, not to be confused withnginx-ingress
) - A TLS secret suitable for an Ingress route. You need to either create a TLS
secret before hand, or modify
patches/nextcloud/ingress/settings.yaml
to do the Let's Encrypt part for you automatically. - Secrets defined in
.env.secret
:MYSQL_DATABASE=nextcloud
- The MariaDB database name
MYSQL_USER=nextcloud
- The MariaDB username
MYSQL_PASSWORD=<plaintext_value_here>
- The MariaDB password for the above username
MYSQL_ROOT_PASSWORD=<plaintext_value_here>
- The MariaDB root password
NEXTCLOUD_ADMIN_PASSWORD=<plaintext_value_here>
- The default Nextcloud Admin password
SMTP_HOST=smtp.example.com
- [OPTIONAL] for email support
SMTP_NAME=user@example.com
- [OPTIONAL] for email support
SMTP_PASSWORD=<plaintext_value_here>
- [OPTIONAL] for email support
MAIL_FROM_ADDRESS=nextcloud
- [OPTIONAL] for email support
MAIL_DOMAIN=example.com
- [OPTIONAL] for email support
Change these values accordingly. The MYSQL_DATABASE
and MYSQL_USER
values
should probably remain as nextcloud
, but the _PASSWORD
values can be set to
whatever you like. The mail/SMTP values should be set if you plan on using email
functionality. This requires additional settings to be uncommented in
patches/nextcloud/deployment/settings.yaml
.
MYSQL_DATABASE=nextcloud
MYSQL_USER=nextcloud
MYSQL_PASSWORD=<plaintext_value_here>
MYSQL_ROOT_PASSWORD=<plaintext_value_here>
NEXTCLOUD_ADMIN_PASSWORD=<plaintext_value_here>
SMTP_HOST=smtp.example.com
SMTP_NAME=user@example.com
SMTP_PASSWORD=<plaintext_value_here>
MAIL_FROM_ADDRESS=nextcloud
MAIL_DOMAIN=example.com
Update this file with the values required.
namespace: nextcloud
commonLabels:
app: nextcloud
Change namespace
if you prefer. The default is nextcloud
.
Any commonLabels
you apply must never change. This is an unbreakable rule.
Update each newTag
vaue with the latest, or desired version for each image.
images:
- name: nextcloud
newTag: 30.0.0-apache
- name: redis
newTag: 7.4.0-alpine3.20
- name: mariadb
newTag: lts-noble
Update the amount of space you want to allocate to the MariaDB PVC, and specify
a storageClassName
as needed.
# MariaDB patches
- patch: |-
## Storage
- op: replace
path: /spec/volumeClaimTemplates/0/spec/resources/requests/storage
value: 10Gi
## Uncomment and add a value if you need to define a storageClassName
# - op: add
# path: /spec/volumeClaimTemplates/0/spec/storageClassName
# value: ""
## StatefulSet
## Uncomment this to make it pull the latest lts-noble image Always
# - op: replace
# path: /spec/template/spec/containers/0/imagePullPolicy
# value: Always
target:
kind: StatefulSet
name: db
10Gi
is the default value. Be advised, whatever you set is NOT upgradable
since MariaDB is now a StatefulSet. Choose wisely for your initial size. If you
have a large number of files and users, it may be prudent to set this larger.
Also, the image behind the lts-noble
tag for the MariaDB image may change, but
you won't automatically receive that update because the default imagePullPolicy
for tags that are not latest
is IfNotPresent
. If you want to always pull
the latest lts-noble
tag, then uncomment the imagePullPolicy
patch section.
This can also be done ad-hoc when you know there's been a change. Just uncomment
it for "this" update, and then recomment again.
Storage settings
These patches will need to be edited and configured with your storage settings before they can be used.
## App storage
- patch:
path: patches/nextcloud/pv/settings.yaml
- patch:
path: patches/nextcloud/pvc/settings.yaml
## External storage
## Only uncomment if base/external is also uncommented in the resources block.
# - patch:
# path: patches/external/pv/settings.yaml
# - patch:
# path: patches/external/pvc/settings.yaml
Uncomment base/external
if you want to add the External storage lines.
resources:
- base
- base/external
Deployment settings
Carefully read the comments in this file as they explain settings that need to be updated, or uncommented and used in conjunction with other settings and patches.
-
patches/nextcloud/deployment/settings.yaml
:MYSQL_HOST
replaceNAMESPACE
with your own. If you usenextcloud
as your namespace, it will readdb.nextcloud.svc.cluster.local
REDIS_HOST
replaceNAMESPACE
with your own. If you usenextcloud
as your namespace, it will readredis.nextcloud.svc.cluster.local
OVERWRITECLIURL
should be whatever you use forNEXTCLOUD.EXAMPLE.COM
inpatches/nextcloud/ingress/settings.yaml
.NEXTCLOUD_TRUSTED_DOMAINS
can be multiple space separated values. At the very least, you should havelocalhost
and whatever you used forNEXTCLOUD.EXAMPLE.COM
. Possible additional values include:app.NAMESPACE.svc.cluster.local
, whereNAMESPACE
is the actual name of your namespace inkustomization.yaml
. The provided value isnextcloud
.ingress-nginx-controller.NGINX-INGRESS-NAMESPACE.svc.cluster.local
, whereNGINX-INGRESS-NAMESPACE
is the namespace where your Nginx ingress controller was installed. If you followed their normal, helm installation procedures, this is ostensiblyingress-nginx
, and the kubernetes metadata name isingress-nginx-controller
.
SMTP_
settings. To use these, uncomment and ensure you have added the necessary passwords and settings to.env.secret
.
-
patches/nextcloud/ingress/settings.yaml
:- Replace
NEXTCLOUD.EXAMPLE.COM
with your domain name. - Replace
<MY_TLS_SECRET>
with your own TLS secret.
- Replace
-
pv/settings.yaml
&pvc/settings.yaml
inpatches/nextcloud
:- Edit to fit your needs. This project uses an nfs mount. You may need to fork and edit if this is not how your environment is configured.
-
OPTIONAL:
pv/settings.yaml
andpvc/settings.yaml
inpatches/external/
:- Edit to fit your needs. This project uses an nfs mount. You may need to fork
and edit if this is not how your environment is configured. This also requires
uncommenting
- base/external
inresources:
near the top of thekustomization.yaml
file, as well as other related configuration items.
- Edit to fit your needs. This project uses an nfs mount. You may need to fork
and edit if this is not how your environment is configured. This also requires
uncommenting
-
(Optional) To preview generated configuration before deploying:
kubectl kustomize .
-
Run the following command to build and deploy:
kubectl apply -k .
-
Copy
kustomization.yaml
, and the variouspatches/*
files tooverlays/NAME
, or whatever directory structure you prefer. -
Each
overlays/NAME
should have its ownkustomization.yaml
andpatches
subdirectory. -
Be sure to update the
resources
section ofkustomization.yaml
to be able to reach thebase
directory:resources: - ../../base
Apply the same configuration steps as above for each overlay/NAME
path you
create.
-
(Optional) To preview generated configuration before deploying:
kubectl kustomize overlays/NAME
-
Run the following command to build and deploy:
kubectl apply -k overlays/NAME