Terraform Provisioner for DDClient Dynamic DNS update client in a Kubernetes cluster running on ARM architecture / Raspberry Pi. Makes use of Terraform Kubernetes Provider. Includes Terraform resource definitions for Kubernetes Secrets (for Dynamic DNS update credentials), and Kubernetes Persistent Volume (for DDClient cache file persistent storage). Functionality mostly similar to deploying using a Helm chart, but currently no version of Tiller available to run on ARM architecture. This method allows for single-command deployment, with a single variables config file.
Container based off of Docker image located at https://hub.docker.com/r/clayshek/ddclient-debian-arm/. Runs on top of ARM32v7/Debian:stretch-slim, approx size 84 MB. Containers based off this image configurable via terraform.tfvars and should work for most use-cases, but for deeper configuration needs, custom Docker images can be built and used by modifying image_name parameter in terraform.tfvars.
Some code based off of steasdal/ddclient-alpine & rycus86/docker-ddclient
- Working Kubernetes cluster (developed on v1.9) on Raspberry Pi. Info
- Terraform (tested with v0.11.7)
- Terraform must have connectivity to Kubernetes. Either run on K8s master (easiest), or other workstation with properly configured Kube config file and Terraform provider setup.
- Pre-configured NFS share (default) or other Kubernetes supported Persistent Volume for DDclient cache storage. If using other than NFS, customization of main.tf likely required in addition to tfvars file. See Terraform kubernetes_persistent_volume resource documentation for further details. An alternative, if not using persistent storage, would be to comment out all volume related code in main.tf, but risk (relatively small) chance of being flagged for abuse by DDNS provider due to repeated update attempts after container restarts.
- Clone the repository
- Customize the parameters in the terraform.tfvars file as applicable for provisioning. Includes DDClient config as well as Persistent Volume config. See note in terraform.tfvars regarding base64 Secrets encoding differences from native Kubernetes secrets; also blurb on Terraform Sensitive Data in State.
- Run
terraform init(required for first run to pull Kubernetes provider). - Apply the configuration:
terraform apply
- Remove the configuration from Kubernetes:
terraform destroy
- Metrics & Monitoring.
- Change Replication Controller resource to Deployment when supported by the Provider. See Git Issue
- Use envFrom for mapping Config Map to environment variables, when supported by Provider. See Git Issue)
- Evaluate Vault for Secrets
- Evaluate other Storage options. Possibly Rook? Ceph?
- Ultimately evaluate workload for Function as a Service, potentially OpenFaaS
This is open-sourced software licensed under the MIT license.