Deploying Zercurity to Kubernetes with Kubectl

Whats with all the Kubernetes posts? Well, for sometime Zercurity has supported Kubernetes on-premise. However, we’re now bringing it to GitHub alongside our docker-compose setup and soon our helm build.

Why Kubernetes?

Whilst docker-compose is great for smaller and PoC deployments. If you’re looking to support thousands and thousands of clients in a production environment Kubernetes is the way to go for a clustered and highly available deployment.

Installing Zercurity on Kubernetes

This guide is designed to get you up and running with Zercurity on Kubernetes via the provided base configuration. This is designed to be a configuration from which you can pick and customise how you want Zercurity deployed. For a more uniform deployment. We’ll be providing a helm deployment in the coming weeks.

Prerequisite

You will obviously need a Kubernetes cluster. No special permissions are required at present.

The only real requirement is an NFS server. To share compiled and signed binaries between the backend and the NGINX proxy for client downloads.

If your Kubernetes cluster supports shared disks you can also provision a shared PVC instead. Removing the need for a separate NFS share.

Downloading Zercurity

Everything you need can be pulled down directly from our GitHub repository.

git clone git@github.com:zercurity/zercurity.git
cd zercurity/installers/kubectl

Creating a namespace

The default namespace used in this configuration is zercurity this can be overridden with your own namespace using the -n flag within your kubectl command. All the commands shown will use this flag to specify the namespace. As you’ll provably want to define your own.

kubectl create ns zercurity

Applying ConfigMaps and Secrets

There are two configuration files. The non-sensitive configuration parameters are in cm-config.yaml, and the secrets are stored within secret-config.yaml.

There are three things I would change for the initial configuration. These are the application domain name ZERCURITY_DOMAIN (which can be changed at anytime). I’d also change the application secret (SECRET) and database password (DATABASE_PASSWORD). Both can be found in secret-config.yaml .

kubectl apply -n zercurity -f cm-config.yaml
kubectl apply -n zercurity -f secret-config.yaml

Applying PersistentVolumeClaims

We’ve currently designed the deployment to work around an NFS server. The NFS server is used to store and serve the installation binaries via the NGINX pod. Which is configured to be readOnly and backend pods will generate and store the installer binaries to the NFS server.

If your Kubernetes cluster supports shared PVCs you can just use a shared PVC instead.

You will need to edit the pv-nfs.yaml with your server NFS information.

kubectl apply -n zercurity -f pv-nfs.yaml
kubectl -n zercurity get pv

Once the PersistentVolume has been created. Make sure the status is Bound. We can now create our PersistentVolumeClaims.

This command will also create the PVC for our database (PostrgreSQL) server too. Feel free to resize as needed. Though we’d recommend using something like pgo for database management.

kubectl apply -n zercurity -f pvc-*.yaml
kubectl -n zercurity get pvc

Applying the Deployments

Now for the fun part. Once the volumes are showing they’ve been successfully Bound. You can now deploy Zercurity.

kubectl apply -n zercurity -f deploy-*.yaml
kubectl -n zercurity get deploy
kubectl -n zercurity get pods

It will take a few minutes to download the images and start the containers.

Applying the services and LoadBalancer

Whilst this is happening you can deploy the services and load balancer.

kubectl apply -n zercurity -f svc-*.yaml
kubectl -n zercurity get svc

Initialising the database and running the migration scripts

When the PostgreSQL container successfully comes up. It maybe the case that other containers are in a CrashBackOff state. This is because database hasn’t been configured.

We can fix this by running this migrations job. This needs to be run post any update.

kubectl apply -n zercurity -f job-*.yaml

This will now initialise the database. Post the migrations job running. It may take the job a few more minutes to come up. However, once they’re all in the running state you’ll be able to visit the app via the LoadBalancer’s IP address or hostname (ZERCURITY_DOMAIN) if you’ve already configured your DNS.

Accessing the web application

If you’ve left the defaults as they are. Zercurity will be bound to the following hostname https://app.zercurity.local.

You can also check the API server is happy and healthy like so:

curl -k -vvv https://<Load balancer IP>/v1/healthcheck | json_pp{
“status”: “HEALTHY”
}
The Zercurity web application

Creating your initial user

You can create your first account using the Register button from within the app. However, if you’re having issues with SMTP or the mailer and want to create an account to just get going. You can exec the following to create a registration link to create an account.

This link is short-lived and unique to the email address provided.

kubectl -n zercurity exec backend-77c9cbf84d-lhg2g — ./zercurity — register — name “Tom” — email “tom@jerry.comhttps://app.zercurity.local/register/3bUJQ7z..aJLGC7W9S

Its all over!

We hope you found this helpful, Getting Zercurity deployed via kubectl. Please feel free to get in touch if you have any questions.

Real-time security and compliance delivered.