public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 09:46:23 +00:00
Code Issues Releases Wiki Activity

Minor markdown fixes

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2022-09-28 12:11:53 +13:00
parent 3b3122aa2c
commit 2ea2991ac1
3 changed files with 2 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/kubernetes/ssl-certificates/wildcard-certificate.md
View File

@@ -16,7 +16,7 @@ This behaviour can be prohibitive, because (a) we don't want to have to request/
To take advantage of the various workarounds available, I find it best to put the certificates into a dedicated namespace, which I name.. `letsencrypt-wildcard-cert`.
!!! question "Why not the cert-manager namespace?"
Because cert-manager is a _controller_, whose job it is to act on resources. I should be able to remove cert-manager entirely (even its namespace) from my cluster, and re-add it, without impacting the resources it acts upon. If the certificates lived in the `cert-manager` namespace, then I wouldn't be able to remove the namespace without also destroying the certificates.
Because cert-manager is a *controller*, whose job it is to act on resources. I should be able to remove cert-manager entirely (even its namespace) from my cluster, and re-add it, without impacting the resources it acts upon. If the certificates lived in the `cert-manager` namespace, then I wouldn't be able to remove the namespace without also destroying the certificates.
Furthermore, we can't deploy ClusterIssuers (a CRD) in the same kustomization which deploys the helmrelease which creates those CRDs in the first place. Flux won't be able to apply the ClusterIssuers until the CRD is created, and so will fail to reconcile.
@@ -44,7 +44,6 @@ Thanks to [Sealed Secrets](/kubernetes/sealed-secrets/), we have a safe way of c
Finally, we create our certificates! Here's an example certificate resource which uses the letsencrypt-staging issuer (*to avoid being rate-limited while learning!*). I save this in my flux repo as `/letsencrypt-wildcard-cert/certificate-wildcard-cert-letsencrypt-staging.yaml`
```yaml title="/letsencrypt-wildcard-cert/certificate-wildcard-cert-letsencrypt-staging.yaml"
apiVersion: cert-manager.io/v1
kind: Certificate

2
docs/premix/ansiblizing/index.md
View File

@@ -7,4 +7,4 @@
So you want to add a recipe to the the premix playbook which is not yet an Ansible role? Read on for details...
1. [Ansiblizing for Docker Swarm](/premix/ansiblizing/swarm/)
2. [Ansiblizing for Kubernetes (flux)](/premix/ansiblizing/kubernetes/)
2. [Ansiblizing for Kubernetes (flux)](/premix/ansiblizing/kubernetes/)

1
docs/premix/ansiblizing/swarm.md
View File

@@ -41,4 +41,3 @@ immich:
## Ensure the recipe files are valid
The playbook assumes that `/<recipe-name>/<recipe-name>.yml` and `/<recipe-name>/<recipe-name>.env-sample` exist. Without these (*and any other supporting files, ending in `-sample`*), unpleasant things will happen!