++knotdns readme
This commit is contained in:
parent
3792700e1c
commit
bf2ffca5fe
1 changed files with 70 additions and 6 deletions
|
@ -1,27 +1,91 @@
|
|||
## Authoritative DNS for ungleich
|
||||
|
||||
* Zone are stored in git
|
||||
* DNS zones are stored in git repository
|
||||
* All zones are Bind/Knot compatible below zones/
|
||||
* Filenames starting with a dot should be ignored
|
||||
* They are symlinked by some zones, as zones are the same
|
||||
|
||||
## Reload mechansim
|
||||
|
||||
### Constraints
|
||||
## Reload mechansim constraints
|
||||
|
||||
* If possible stay with the regular/upstream container
|
||||
* Rebuilding causes a delay and extra work
|
||||
* We want to base the work on czniz/knot image
|
||||
* Need to generate config file from zones
|
||||
* Very easy to generate
|
||||
* However needs to include synthrecord directives
|
||||
* This step *might* also use kustomize edit?
|
||||
* "Double commits" are somewhat ugly
|
||||
* App 1 commits a zone file change
|
||||
* App 2 / CI/CD modifies the configuration file - commits again
|
||||
* The pipeline needs to analyse *what* changed to prevent a circle
|
||||
of commits
|
||||
* git might be smart enough already and failing to commit again,
|
||||
as there is no change
|
||||
* Then we need to
|
||||
* Time to deploy should be low
|
||||
* Seconds, not minutes
|
||||
* Rebuilding containers seems to be excessive
|
||||
* Flux might need to get triggered instead of relying only on
|
||||
periodic updates
|
||||
* Might be possible with flux using
|
||||
https://fluxcd.io/docs/components/notification/
|
||||
* Might require https://github.com/fluxcd/notification-controller/issues/230
|
||||
|
||||
## Reload using CI/CD pipeline
|
||||
|
||||
Theorethical flow:
|
||||
|
||||
* Git repository is pushed to CI/CD
|
||||
* We need to select a CI/CD system first
|
||||
* Ongoing work in https://redmine.ungleich.ch/issues/9565
|
||||
* Might be bit overkill "just for DNS"
|
||||
* Might be usable for other workflows, too
|
||||
* CI/CD "builds" on trigger "something"
|
||||
* A helm chart
|
||||
* A container
|
||||
* Jenkins would be suited for this
|
||||
* A configmap
|
||||
* This overlaps 80% of flux/kustomize
|
||||
|
||||
|
||||
## Reload using helm / configmap
|
||||
|
||||
## Git cloning inside the pod
|
||||
Theorethical flow:
|
||||
|
||||
* git push triggers creating a new helm chart
|
||||
* Might need a CI pipeline in between
|
||||
* Might be Jenkins/Buildbot/etc.
|
||||
* helm chart is uploaded to a (local) chartmuseum
|
||||
* flux updates itself to the latest chart using semversion constraints
|
||||
* Might be easy to include a webhook
|
||||
|
||||
## Reload using git cloning inside the pod
|
||||
|
||||
* It's easy to write a shell script that does git pull && checkzone &&
|
||||
reload
|
||||
* Needs ssh keys or token inside the pods
|
||||
* Could be injected via env
|
||||
* Could use a *git-hook* to reload knot, if the zone files are working
|
||||
* Needs git inside the container
|
||||
* additional files could be injected via configmap
|
||||
* No direct webhook for trigger support
|
||||
* Might have a webhook pod that triggers reload in one or the other way
|
||||
|
||||
Sample git
|
||||
```
|
||||
git clone https://nico:<TOKEN>@gitea.default.svc.c2.k8s.ooo/nico/ungleich-k8s.git
|
||||
```
|
||||
|
||||
### Flux/git repository
|
||||
Sketch shell script:
|
||||
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
|
||||
|
||||
### Relooad using Flux/git repository
|
||||
|
||||
**TL;DR**
|
||||
|
||||
|
|
Loading…
Reference in a new issue