mirror of
https://github.com/funkypenguin/geek-cookbook/
synced 2026-10-29 04:03:23 +00:00
Fix more broken links, add lazy-loading to images
This commit is contained in:
78 files changed
+166
-155
No files matched your search
@@ -2,7 +2,7 @@
|
||||
|
||||
Miniflux is a lightweight RSS reader, developed by [Frédéric Guillot](https://github.com/fguillot). (_Who also happens to be the developer of the favorite Open Source Kanban app, [Kanboard](/recipes/kanboard/)_)
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
I've [reviewed Miniflux in detail on my blog](https://www.funkypenguin.co.nz/review/miniflux-lightweight-self-hosted-rss-reader/), but features (among many) that I appreciate:
|
||||
|
||||
|
||||
@@ -18,27 +18,27 @@ IMO, the easiest Kubernetes cloud provider to experiment with is [DigitalOcean](
|
||||
|
||||
Create a project, and then from your project page, click **Manage** -> **Kubernetes (LTD)** in the left-hand panel:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
Until DigitalOcean considers their Kubernetes offering to be "production ready", you'll need the additional step of clicking on **Enable Limited Access**:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
The _Enable Limited Access_ button changes to read _Create a Kubernetes Cluster_ . Cleeeek it:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
When prompted, choose some defaults for your first node pool (_your pool of "compute" resources for your cluster_), and give it a name. In more complex deployments, you can use this concept of "node pools" to run certain applications (_like an inconsequential nightly batch job_) on a particular class of compute instance (_such as cheap, preemptible instances_)
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
That's it! Have a sip of your 🍷, a bite of your :cheese:, and wait for your cluster to build. While you wait, follow the instructions to setup kubectl (if you don't already have it)
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
DigitalOcean will provide you with a "kubeconfig" file to use to access your cluster. It's at the bottom of the page (_illustrated below_), and easy to miss (_in my experience_).
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
## Release the kubectl!
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ We use a phone-home container, which calls a simple webhook on our haproxy VM, a
|
||||
|
||||
Here's a high-level diagram:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
[Helm](https://github.com/helm/helm) is a tool for managing Kubernetes "charts" (_think of it as an uber-polished collection of recipes_). Using one simple command, and by tweaking one simple config file (values.yaml), you can launch a complex stack. There are many publicly available helm charts for popular packages like [elasticsearch](https://github.com/helm/charts/tree/master/stable/elasticsearch), [ghost](https://github.com/helm/charts/tree/master/stable/ghost), [grafana](https://github.com/helm/charts/tree/master/stable/grafana), [mediawiki](https://github.com/helm/charts/tree/master/stable/mediawiki), etc.
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
## Ingredients
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ description: Unlike competing ingresses (*cough* nginx *cough*), the beautiful T
|
||||
|
||||
One of the advantages [Traefik](/kubernetes/ingress/traefik/) offers over [Nginx](/kubernetes/ingress/nginx/), is a native dashboard available in the open-source version (*Nginx+, the commercially-supported version, also includes a dashboard*).
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
!!! summary "Ingredients"
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Traefik natively includes some features which Nginx lacks:
|
||||
* [x] An elegant "middleware" implementation allowing certain requests to pass through additional layers of authentication
|
||||
* [x] A beautiful dashboard
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
!!! summary "Ingredients"
|
||||
|
||||
|
||||
@@ -22,23 +22,23 @@ Install the FRR package in pfsense, under **System -> Package Manager -> Availab
|
||||
|
||||
Under **Services -> FRR Global/Zebra**, enable FRR, set your router ID (*this will be your router's peer IP in MetalLB config*), and set a master password (*because apparently you have to, even though we don't use it*):
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
### Configure FRR BGP
|
||||
|
||||
Under **Services -> FRR BGP**, globally enable BGP, and set your local AS and router ID:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
### Configure FRR BGP Advanced
|
||||
|
||||
Use the tabs at the top of the FRR configuration to navigate to "**Advanced**"...
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
... and scroll down to **eBGP**. Check the checkbox titled "**Disable eBGP Require Policy**:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
!!! question "Isn't disabling a policy check a Bad Idea(tm)?"
|
||||
If you're an ISP, sure. If you're only using eBGP to share routes between MetalLB and pfsense, then applying policy is an unnecessary complication.[^1]
|
||||
@@ -58,13 +58,13 @@ It's useful to bundle our configurations within a "peer group" (*a collection of
|
||||
|
||||
Now add each node running MetalLB, as a BGP neighbor. Pick the peer-group you created above, and configure each neighbor's ASN:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
## Serving
|
||||
|
||||
Once you've added your neighbors, you should be able to use the FRR tab navigation (*it's weird, I know!*) to get to Status / BGP, and identify your neighbors, and all the routes learned from them. In the screenshot below, you'll note that **most** routes are learned from all the neighbors - that'll be service backed by a daemonset, running on all nodes. The `192.168.32.3/32` route, however, is only received from `192.168.33.22`, meaning only one node is running the pods backing this service, so only those pods are advertising the route to pfSense:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Miniflux is a lightweight RSS reader, developed by [Frédéric Guillot](https://github.com/fguillot). (_Who also happens to be the developer of the favorite Open Source Kanban app, [Kanboard](/recipes/kanboard/)_)
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
I've [reviewed Miniflux in detail on my blog](https://www.funkypenguin.co.nz/review/miniflux-lightweight-self-hosted-rss-reader/), but features (among many) that I appreciate:
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ They're still not very secret though, and you certainly wouldn't want to be stor
|
||||
|
||||
An elegant solution to this problem is Bitnami Labs' Sealed Secrets.
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
A "[SealedSecret](https://github.com/bitnami-labs/sealed-secrets)" can only be decrypted (*and turned back into a regular Secret*) by the controller in the target cluster. (*or by a controller in another cluster which has been primed with your own private/public pair)* This means the SealedSecret is safe to store and expose anywhere.
|
||||
|
||||
|
||||
@@ -113,7 +113,7 @@ storage: 1Gi
|
||||
|
||||
And here's what my snapshot list looks like after a few days:
|
||||
|
||||
|
||||
{ loading=lazy }
|
||||
|
||||
### Snapshot a non-Kubernetes volume (optional)
|
||||
|
||||
|
||||
Reference in new issue
Block a user