The decision to go to Kubernetes (managed deployment on Digital Ocean) was so that I could also free my home-server and eventually shut it down. There I hosted the Windows-based Ivideon server, on a Windows VM running on Proxmox. The internet in Romania being broadband helped a lot. I’m actively using Ivideon to record activity around the properties we hold.
Though in need of one for a quick deployment, I couldn’t find a HELM chart or something already done. On the other hand, the server itself is pretty stateless and just needs a configuration file and a PV to hold the archive, so not too big of a challenge to write a deployment file for it.
--- kind: Deployment metadata: name: ivideon-server namespace: ivideon spec: selector: matchLabels: app: ivideon-server replicas: 1 strategy: type: Recreate template: metadata: labels: app: ivideon-server spec: initContainers: - name: copy-config image: debian:stable command: ['bash', '-c', 'cp -v /configmap/* /config/'] volumeMounts: - mountPath: "/configmap" name: ivideon-config - mountPath: "/config" name: ivideon-pv-config containers: - name: ivideon image: sisaenkov/ivideon-server env: - name: SERVER_NAME value: "SameNameAsInConfiguration" - name: EMAIL value: "firstname.lastname@example.org" ports: - containerPort: 8080 volumeMounts: - mountPath: "/config" name: ivideon-pv-config - mountPath: "/archive" name: ivideon-pv-archive restartPolicy: Always volumes: - name: ivideon-config configMap: name: videoserverd-config - name: ivideon-pv-config persistentVolumeClaim: claimName: ivideon-pvc-config - name: ivideon-pv-archive persistentVolumeClaim: claimName: ivideon-pvc-archive
What happens above is pretty simple and straightforward. We take the sisaenkov/ivideon-server image (a great resource by the way) and feed it a ConfigMap which holds the videoserverd.config exported from a desktop version of Ivideon (with paths and camera ONVIF addresses adjusted).
We then have an init container copy that ConfigMap over to the final place (which was not so possible to attach directly as maps are read-only and the image wants to write logs in the /config folder). With that done, an extra PV for the /archive and that’s about it. One command away and we’re off to the races:
kubectl -n ivideon apply -f ivideon-deployment.yaml
After checking the pod logs for no errors, you’re free to see the cameras in action back on ivideon.com with the streams now gathered by and served from Linux variant of the Ivideon server running off a pod in Kubernetes.
Of course, I didn’t went full HA in my deployment, but you could if you wanted use the simple leader election sidecar pattern from the Kubernetes documentation and go wild with it … This is left as an exercise for the reader (and if you do, please ping back as I’m interested).