Compare commits
10 commits
a600b1f5ee
...
3c41835e1a
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
3c41835e1a | ||
|
|
072e2998ae | ||
|
|
563e6333dc | ||
|
|
5e79d7efb2 | ||
|
|
460c84ac9b | ||
|
|
3d027bd7f7 | ||
|
|
09f36dff16 | ||
|
|
f3d077e3c4 | ||
|
|
09f01d409f | ||
|
|
af174eaa63 |
2
.gitignore
vendored
|
|
@ -5,3 +5,5 @@ dist
|
|||
.vite-inspect
|
||||
.remote-assets
|
||||
components.d.ts
|
||||
*.deleted
|
||||
vite.config.ts
|
||||
|
|
|
|||
BIN
og-image.png
|
Before Width: | Height: | Size: 737 KiB After Width: | Height: | Size: 483 KiB |
8763
package-lock.json
generated
|
|
@ -2,12 +2,21 @@
|
|||
level: 2
|
||||
---
|
||||
|
||||
# Configuration
|
||||
# `infctl`
|
||||
|
||||
Configuration is based on a list of simple JSON objects.
|
||||
Keep it simple, list of JSON objects.
|
||||
|
||||
````md magic-move {lines: true}
|
||||
```js {1,12|2-10}
|
||||
|
||||
```js {1-4}
|
||||
[
|
||||
{},
|
||||
{}
|
||||
]
|
||||
```
|
||||
|
||||
|
||||
```js {2-10}
|
||||
[
|
||||
{
|
||||
"name": "...",
|
||||
|
|
@ -62,3 +71,26 @@ Configuration is based on a list of simple JSON objects.
|
|||
```
|
||||
|
||||
````
|
||||
|
||||
<!--
|
||||
|
||||
`infctl` uses a simple JSON list of objects to represent a pipeline of tasks
|
||||
|
||||
each object
|
||||
|
||||
* has a name
|
||||
* calls a function
|
||||
* an retry failed steps
|
||||
* optionally exits on failure
|
||||
|
||||
a function may be internally implemented in `infctl`
|
||||
|
||||
there is currently only the one: `K8sNamespaceExists`
|
||||
|
||||
more may be added but this is for reference at this time and so as to illustrate how this may be implemented for other use cases
|
||||
|
||||
the majority of the time `infctl` uses `RunCommand` to execute scripts and executables
|
||||
|
||||
additionally, pipeline steps may be repeated so as to allow for some steps to be re-tried until complete or fail over time
|
||||
|
||||
-->
|
||||
34
pages/diagram-3node.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# MVK for pre-production
|
||||
|
||||
The **V** in MVK is for *viable*, so why is MVK viable for 3 or more nodes ?
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
<img src="/k8s-3.drawio.png">
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
why is MVK 'viable' ?
|
||||
|
||||
Out of the box K8s examples and some deployments are not useable without other externalities
|
||||
|
||||
* Persistent storage - often built in to managed kubernetes cloud platforms
|
||||
* Ingress - is also provided by cloud providers, K8s does not natively have this
|
||||
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
|
||||
|
||||
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
|
||||
|
||||
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
|
||||
|
||||
it also adds Longhorn for persistent storage
|
||||
|
||||
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
|
||||
|
||||
-->
|
||||
36
pages/diagram-single-node.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# MVK for development
|
||||
|
||||
The **V** in MVK is for *viable*, so why is MVK viable for single 'dev' nodes ?
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
|
||||
<img src="/k8s-2.drawio.png">
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
why is MVK 'viable' ?
|
||||
|
||||
Out of the box K8s examples and some deployments are not useable without other externalities
|
||||
|
||||
* Persistent storage - often built in to managed kubernetes cloud platforms
|
||||
* Ingress - is also provided by cloud providers, K8s does not natively have this
|
||||
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
|
||||
|
||||
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
|
||||
|
||||
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
|
||||
|
||||
it also adds Longhorn for persistent storage
|
||||
|
||||
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
|
||||
|
||||
-->
|
||||
87
pages/gcloud-single.md
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# GCE
|
||||
|
||||
Google Compute Engine
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
```bash
|
||||
# 1. PREREQS
|
||||
# 2. CONFIGURE
|
||||
# 3. RUN
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
# PREREQS
|
||||
# run pre flight checks ...
|
||||
#
|
||||
# we need to run this at least once to ensure we have tooling available ...
|
||||
```
|
||||
|
||||
```bash
|
||||
# PREREQS
|
||||
# run pre flight checks ...
|
||||
cd /home/user/projects/infctl-cli # where we checked out infct-cli to
|
||||
./gcloud/tf/scripts/pre-flight-checks.sh
|
||||
```
|
||||
|
||||
```bash
|
||||
# PREREQS
|
||||
# running pre flight checks ...
|
||||
./gcloud/tf/scripts/pre-flight-checks.sh
|
||||
# .....
|
||||
|
||||
✅ tofu is installed,...
|
||||
|
||||
✅ gcloud is installed,...
|
||||
|
||||
✅ kubectl is installed,...
|
||||
|
||||
✅ envsubst is installed,...
|
||||
|
||||
# .....
|
||||
|
||||
✅ Pre-flight checks passed. You are ready to proceed 🙂
|
||||
```
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
# CONFIGURE
|
||||
[ -f .env ] || cp -v .env.gcloud-example .env
|
||||
# edit to include
|
||||
export PROJECT_NAME="the name of your gcp project, often referred to as the project"
|
||||
export EMAIL="your email address to identify yourself with letsencrypt"
|
||||
export APP_DOMAIN_NAME="your domain name for the app, e.g., frgdr.some-domain.com"
|
||||
export INSTALL_FORGEJO="true"
|
||||
```
|
||||
|
||||
```bash
|
||||
# RUN
|
||||
LOG_FORMAT=none infctl -f ./gcloud/tf/scripts/build-gcloud-k3s-pipeline-wait-dns.json
|
||||
```
|
||||
|
||||
|
||||
|
||||
````
|
||||
<div v-click>
|
||||
|
||||
Lets see a Google Compute Engine install [Demo](https://ascii.headshed.dev/a/jgUbXEHHhv9kmm9A2vfr3m5OU)
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
TBC
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
31
pages/infctl-summary-end.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Pre release
|
||||
|
||||
<div grid="~ cols-2 gap-4">
|
||||
<div>
|
||||
|
||||
[MVK](https://mvk.headshed.dev) is new and evolving
|
||||
|
||||
`infctl` is an early release.
|
||||
|
||||
Its a snapshot of ideas I've been working on for over 10 years.
|
||||
|
||||
I'd like to share it as I code it and use it.
|
||||
|
||||
It is open to ideas, comments, contribution and collaboration.
|
||||
|
||||
License: [GNU General Public License](https://www.gnu.org/licenses/gpl-3.0.en.html)
|
||||
|
||||
|
||||
# [https://headshed.dev/n25](https://headshed.dev/n25)
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
<img class="mx-auto" alt="qr code for https://headshed.dev/n25/" src="/n25-qr.png">
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
TBC
|
||||
-->
|
||||
|
|
@ -1,39 +1,31 @@
|
|||
# Alpha release
|
||||
# Pre release
|
||||
|
||||
<div grid="~ cols-2 gap-4">
|
||||
<div>
|
||||
|
||||
[MVK](https://mvk.headshed.dev) is new and evolving
|
||||
|
||||
`infctl` is an early release.
|
||||
|
||||
treat is as 'Alpha'.
|
||||
|
||||
Its a sketch of ideas I've been working on for decades.
|
||||
Its a snapshot of ideas I've been working on for over 10 years.
|
||||
|
||||
I'd like to share it as I code it and use it.
|
||||
|
||||
Open to ideas, comments, contribution and collaboration.
|
||||
It is open to ideas, comments, contribution and collaboration.
|
||||
|
||||
License: [GNU General Public License](https://www.gnu.org/licenses/gpl-3.0.en.html)
|
||||
|
||||
|
||||
|
||||
|
||||
Check out [https://codeberg.org/headshed/infctl-cli](https://codeberg.org/headshed/infctl-cli) for more.
|
||||
# [https://headshed.dev/n25](https://headshed.dev/n25)
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
<img src="/infctl.png">
|
||||
<img src="/container_night2_c.jpg">
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!--
|
||||
Presenter note with **bold**, *italic*, and ~~striked~~ text.
|
||||
|
||||
Also, HTML elements are valid:
|
||||
<div class="flex w-full">
|
||||
<span style="flex-grow: 1;">Left content</span>
|
||||
<span>Right content</span>
|
||||
</div>
|
||||
TBC
|
||||
-->
|
||||
|
|
|
|||
53
pages/ingress-test.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# Ingress test
|
||||
|
||||
... with Vagrant
|
||||
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
```bash {1|2|3|4|5}
|
||||
vagrant ssh workstation
|
||||
cd /vagrant/certs/
|
||||
bash secret.sh
|
||||
bash copy_secret_to_default.sh
|
||||
cd $HOME
|
||||
```
|
||||
|
||||
|
||||
```bash {1|2|3|4}
|
||||
cd k8s/nginx-test
|
||||
kubectl apply -f deployment.yaml
|
||||
kubectl apply -f service.yaml
|
||||
kubectl apply -f ingress.yaml
|
||||
```
|
||||
|
||||
````
|
||||
<div v-click>
|
||||
|
||||
Lets see an install of metallb and traefic ingress in a [Demo](http://ascii.headshed.dev/a/NwWLIm29tu2eU5Ah7H4GyU6Vg)
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<div v-click>
|
||||
|
||||
The creation of a valid certificate is handled by [mkcert](https://github.com/FiloSottile/mkcert)
|
||||
|
||||
And our workstation already has [dnsmasq](https://thekelleys.org.uk/dnsmasq/doc.html) installed acting as a forwarding DNS and serving the address of our test domain `headshed.it` from earlier
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
TBC
|
||||
|
||||
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
38
pages/ingress.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# Ingress
|
||||
|
||||
... with Vagrant
|
||||
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
```bash {1|2|3}
|
||||
vagrant ssh workstation
|
||||
infctl -f pipelines/vagrant-metallb.json
|
||||
infctl -f pipelines/vagrant-ingress.json
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
````
|
||||
<div v-click>
|
||||
|
||||
Lets see an install of metallb and traefic ingress in a [Demo](https://ascii.headshed.dev/a/lLlJj9Mscia6rPXrp1wB9fBna)
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
TBC
|
||||
|
||||
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
# What is Minimal Viable Kubernetes?
|
||||
|
||||
MVK is kubernetes for the impatient and impeverished, and consists the following features
|
||||
|
||||
- ≥ **CLI** - Living in the terminal, uses [`infctl`](https://mvk.headshed.dev/guides/intro/) command line pipeline
|
||||
- 🧑💻 **Startup Friendly** - Getting a functional stack quickly and simply
|
||||
- 🤹 **Automated** - Focus on an infrastructure as code
|
||||
- 🎥 **Repeatable** - Repeatable, re-useable and predictable.
|
||||
- 📤 **Portable** - Kubernetes that can run anywhere
|
||||
- 🛠 **Hackable** - Simple to modify, extend and prototype
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
<div mt-20 v-click>
|
||||
|
||||
See a [Demo that goes terribly wrong](http://ascii.headshed.dev/a/f8S5WqD7OyCzkTcoPZhCSnefX?t=30)
|
||||
|
||||
Then see [one that goes right](http://ascii.headshed.dev/a/jSYcC7p4pbkMdf1B07rQOiIa0?t=01:30)
|
||||
|
||||
</div>
|
||||
|
||||
51
pages/intro01.md
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
What is MVK ?
|
||||
|
||||
### ≥ CLI friendly, CLI first
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
I work at the command line.
|
||||
|
||||
It is efficient and powerfull.
|
||||
|
||||
I find that I can get the most done with tooling that is cli first and can automate everything that is.
|
||||
|
||||
Infrastrructure used to be manually crafted.
|
||||
|
||||
Now it is encoded and version controlled, recoverable, repeatable, maintainable
|
||||
|
||||
can be reviewed and quality controlled
|
||||
|
||||
MVK as self hosted is more portable across environments
|
||||
|
||||
cloud to cloud ( ish ) but mostly
|
||||
|
||||
dev => test => pre-prod => prod, all can use similar pipelines and plugins
|
||||
|
||||
MVK started out as a means of sharing knowlege and providing a kick-start into k8s
|
||||
|
||||
microlearnings
|
||||
|
||||
templates
|
||||
|
||||
avoids using cloud based servies that cannot port to other providers
|
||||
|
||||
k8s has many of these
|
||||
|
||||
storage
|
||||
ingress
|
||||
load balancing
|
||||
...
|
||||
more and more
|
||||
|
||||
|
||||
|
||||
-->
|
||||
26
pages/intro02.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
What is MVK ?
|
||||
|
||||
### ≥ CLI friendly, CLI first
|
||||
|
||||
### 🤹 Promotes Infrastructure as code
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
|
||||
|
||||
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
|
||||
|
||||
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
|
||||
|
||||
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
|
||||
|
||||
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
|
||||
|
||||
-->
|
||||
26
pages/intro03.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
What is MVK ?
|
||||
|
||||
### ≥ CLI friendly, CLI first
|
||||
|
||||
### 🤹 Promotes Infrastructure as code
|
||||
|
||||
### 📤 **Portable** on-prem, cloud
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
|
||||
|
||||
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
|
||||
|
||||
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
|
||||
|
||||
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
|
||||
|
||||
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
|
||||
|
||||
-->
|
||||
27
pages/intro04.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
What is MVK ?
|
||||
|
||||
### ≥ CLI friendly, CLI first
|
||||
|
||||
### 🤹 Promotes Infrastructure as code
|
||||
|
||||
### 📤 **Portable** on-prem, cloud
|
||||
|
||||
### 🧐 Fosters curiosity
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
|
||||
|
||||
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
|
||||
|
||||
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
|
||||
|
||||
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
|
||||
|
||||
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
|
||||
|
||||
-->
|
||||
29
pages/intro05.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
What is MVK ?
|
||||
|
||||
### ≥ CLI friendly, CLI first
|
||||
|
||||
### 🤹 Promotes Infrastructure as code
|
||||
|
||||
### 📤 **Portable** on-prem, cloud
|
||||
|
||||
### 🧐 Fosters curiosity
|
||||
|
||||
### 🔒 Avoids lock-in
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
|
||||
|
||||
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
|
||||
|
||||
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
|
||||
|
||||
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
|
||||
|
||||
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
|
||||
|
||||
-->
|
||||
38
pages/make-it-work.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# MVK Viability
|
||||
|
||||
[mvk](https://mvk.headshed.dev)
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
<div class="flex justify-center">
|
||||
|
||||
<img src="/k8s-2.drawio.png">
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
why is MVK 'viable' ?
|
||||
|
||||
Out of the box K8s examples and some deployments are not useable without other externalities
|
||||
|
||||
* Persistent storage - often built in to managed kubernetes cloud platforms
|
||||
* Ingress - is also provided by cloud providers, K8s does not natively have this
|
||||
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
|
||||
|
||||
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
|
||||
|
||||
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
|
||||
|
||||
it also adds Longhorn for persistent storage
|
||||
|
||||
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
|
||||
|
||||
-->
|
||||
38
pages/out-the-box-node.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# K8s Viablility
|
||||
|
||||
Is K8s out of the box, self-hosted, viable ?
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
<div class="flex justify-center">
|
||||
|
||||
<img src="/k8s-1.drawio.png">
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
why is MVK 'viable' ?
|
||||
|
||||
Out of the box K8s examples and some deployments are not useable without other externalities
|
||||
|
||||
* Persistent storage - often built in to managed kubernetes cloud platforms
|
||||
* Ingress - is also provided by cloud providers, K8s does not natively have this
|
||||
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
|
||||
|
||||
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
|
||||
|
||||
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
|
||||
|
||||
it also adds Longhorn for persistent storage
|
||||
|
||||
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
|
||||
|
||||
-->
|
||||
|
|
@ -2,9 +2,9 @@
|
|||
level: 2
|
||||
---
|
||||
|
||||
# Plugins
|
||||
# RunCommand plugins
|
||||
|
||||
Plugins are any script or executable that print output and exit with a number.
|
||||
Plugins are any script or executable that print output and exit with a system code of 0 (OK) or greater (error).
|
||||
|
||||
````md magic-move {lines: true}
|
||||
```bash
|
||||
|
|
@ -28,3 +28,21 @@ exit 1
|
|||
|
||||
|
||||
````
|
||||
|
||||
<!--
|
||||
|
||||
RunCommand plugins are scripts or executables that do two things
|
||||
|
||||
1. print some output that can be seen and logged
|
||||
2. exit with a system code
|
||||
|
||||
The example is of a bash script but it could be any scripting language that can do the same.
|
||||
|
||||
It could be a compiled program, so long as it also outputs logging information to the terminal and exits with a system code of [0|1 or greater]
|
||||
|
||||
Long running scripts or commands are expected
|
||||
|
||||
exiting with 1 or greater will signify a failure of some kind
|
||||
|
||||
|
||||
-->
|
||||
98
pages/run-slide.md
Normal file
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# Getting Started
|
||||
|
||||
... with Vagrant
|
||||
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
```bash
|
||||
cd ~/projects
|
||||
git clone https://codeberg.org/headshed/infctl-cli.git
|
||||
```
|
||||
|
||||
```bash
|
||||
cd infctl-cli/vagrant/dev/ubuntu
|
||||
pwd
|
||||
/home/user/projects/infctl-cli/vagrant/dev/ubuntu
|
||||
```
|
||||
|
||||
```bash
|
||||
vagrant up
|
||||
Bringing machine 'vm1' up with 'virtualbox' provider...
|
||||
Bringing machine 'vm2' up with 'virtualbox' provider...
|
||||
Bringing machine 'vm3' up with 'virtualbox' provider...
|
||||
Bringing machine 'workstation' up with 'virtualbox' provider...
|
||||
==> vm1: Checking if box 'ubuntu/jammy64' version '20241002.0.0' is up to date...
|
||||
==> vm1: Clearing any previously set network interfaces...
|
||||
==> vm1: Available bridged network interfaces:
|
||||
1) wlp0s20f3
|
||||
2) docker0
|
||||
3) br-9ebcfa7b8ec0
|
||||
4) br-b036d14629a8
|
||||
5) veth9ae7cf3
|
||||
==> vm1: When choosing an interface, it is usually the one that is
|
||||
==> vm1: being used to connect to the internet.
|
||||
==> vm1:
|
||||
vm1: Which interface should the network bridge to?
|
||||
```
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
cd ../../..
|
||||
export LOG_FORMAT=none
|
||||
export VAGRANT_BRIDGE=wlp0s20f3
|
||||
|
||||
infctl -f pipelines/dev/vagrant-k3s.json
|
||||
🔄 Running step: Create Vagrant nodes
|
||||
🐞 Running command: ./scripts/install_vagrant_nodes.sh
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
````
|
||||
<div v-click>
|
||||
|
||||
Lets see what this looks like for real in a [Demo](http://ascii.headshed.dev/a/ISIOKVA1AmckG2muwOMUOG4z5)
|
||||
|
||||
</div>
|
||||
|
||||
<div v-click>
|
||||
|
||||
Lets [try again](http://ascii.headshed.dev/a/bUzNNojNjkxytfDT6cRqhSVwN)
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
Let's see how to get started with vagrant
|
||||
|
||||
We use Vagrant to stand up a cluster of 3 nodes and a workstation locally
|
||||
|
||||
Vagrant by default uses Virtualbox which works across Windows, Linux and Mac
|
||||
|
||||
Git cloning the `infctl-cli` repository gets us the starter files
|
||||
|
||||
changing to the vagrant folder we can use `vagrant up` to see what would happen **without** `infctl`
|
||||
|
||||
we see the first gotcha in any automation process - where the tooling does not know what to do and asks the user for input
|
||||
|
||||
This in IaC is an epic fail and we need to copy the name of the interface we want to use for the external network in our test case and export it as an environment variable
|
||||
|
||||
export VAGRANT_BRIDGE=wlp0s20f3
|
||||
|
||||
sets to a device on the example system
|
||||
|
||||
which allows us now to run `infctl` with a deployment file
|
||||
|
||||
lets see what this looks like for real
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
47
pages/storage.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# Storage
|
||||
|
||||
... with Vagrant
|
||||
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
|
||||
```bash
|
||||
cd infctl-cli/vagrant/dev/ubuntu
|
||||
pwd
|
||||
/home/user/projects/infctl-cli/vagrant/dev/ubuntu
|
||||
```
|
||||
|
||||
```bash
|
||||
vagrant ssh workstation
|
||||
```
|
||||
|
||||
```bash
|
||||
export LOG_FORMAT=none
|
||||
|
||||
infctl -f pipelines/vagrant-longhorn.json
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
||||
````
|
||||
<div v-click>
|
||||
|
||||
Lets see a longhorn install [Demo](https://ascii.headshed.dev/a/qslfF9KTMj69zcSwzD6xm1uZ7)
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
TBC
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
36
pages/three-node-happy.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# MVK for pre-production
|
||||
|
||||
### MVK, three node, production
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
<div class="flex justify-center">
|
||||
<img src="/k8s-3.drawio.png" alt="3-node Kubernetes diagram">
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
why is MVK 'viable' ?
|
||||
|
||||
Out of the box K8s examples and some deployments are not useable without other externalities
|
||||
|
||||
* Persistent storage - often built in to managed kubernetes cloud platforms
|
||||
* Ingress - is also provided by cloud providers, K8s does not natively have this
|
||||
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
|
||||
|
||||
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
|
||||
|
||||
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
|
||||
|
||||
it also adds Longhorn for persistent storage
|
||||
|
||||
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
|
||||
|
||||
-->
|
||||
72
pages/usage-slide.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
level: 2
|
||||
---
|
||||
|
||||
# Usage
|
||||
|
||||
`infctl` has a single, compulsory parameter `[-f|--deployment-file]` and an optional environment variable `LOG_FORMAT` which may be ["none"|"basic"|""]
|
||||
|
||||
there must be a valid `deployment-file`
|
||||
|
||||
`LOG_FORMAT` is used to switch structured log to be off, "none", 2 field with "basic" or JSON ( the default )
|
||||
|
||||
|
||||
|
||||
````md magic-move {lines: true}
|
||||
```bash
|
||||
export LOG_FORMAT=none
|
||||
infctl
|
||||
|
||||
no config specified with --deployment-file=<path_to_config_file>
|
||||
```
|
||||
|
||||
```bash
|
||||
export LOG_FORMAT=none
|
||||
infctl -f pipelines/dev/vagrant-k3s.json
|
||||
|
||||
🔄 Running step: Create Vagrant nodes
|
||||
🐞 Running command: ./scripts/install_vagrant_nodes.sh
|
||||
...
|
||||
```
|
||||
|
||||
```bash
|
||||
export LOG_FORMAT="basic"
|
||||
infctl -f pipelines/dev/vagrant-k3s.json
|
||||
|
||||
level=INFO msg="Project name already exists: hdshd\n"
|
||||
level=INFO msg="🔄 Running step: Create Vagrant nodes"
|
||||
...
|
||||
```
|
||||
|
||||
```bash
|
||||
export LOG_FORMAT=""
|
||||
infctl -f pipelines/dev/vagrant-k3s.json
|
||||
|
||||
{"time":"2025-08-16T18:28:00.412416282+01:00","level":"INFO","msg":"Project name already exists: hdshd\n"}
|
||||
{"time":"2025-08-16T18:28:00.412511255+01:00","level":"INFO","msg":"🔄 Running step: Create Vagrant nodes"}
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
````
|
||||
|
||||
[cast](https://ascii.headshed.dev/a/OB2jSE47d1HTz2d5vFhJhIKAl)
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
`infctl` has only one compulsory parameter
|
||||
|
||||
-f | --deployment-file
|
||||
|
||||
another, entirely optional environment variable `LOG_FORMAT` sets the degree to which output is structured
|
||||
|
||||
none - supresses all structured logging
|
||||
|
||||
basic - shows level and standard / error output
|
||||
|
||||
default - structures log output as JSON with date timestamp, level and message
|
||||
|
||||
the latter is purposed for ingesting logs into other systems that can use these fields for categorizing the data
|
||||
|
||||
-->
|
||||
28
pages/uses01.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 🏠 Local development
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
Development is where everything starts from
|
||||
|
||||
logically we use k8s within development to start
|
||||
|
||||
packaging containers
|
||||
testing
|
||||
security scanning
|
||||
|
||||
|
||||
|
||||
-->
|
||||
23
pages/uses02.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 🏠 Local development
|
||||
|
||||
### 🛠️ Integration and smoke testing
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
proving we have not broken things with changes between componetnts and apps outisde of our own
|
||||
|
||||
|
||||
|
||||
-->
|
||||
23
pages/uses03.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 🏠 Local development
|
||||
|
||||
### 🛠️ Integration and smoke testing
|
||||
|
||||
### 🎬 Pre-prod & production
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
In pipelines we can deploy production like environments allowing us to try out produciton configurations before going into live
|
||||
|
||||
test and pre-prod environmetns can be entirely or in part ephemeral, cutting cost and proving infrastructure as code
|
||||
|
||||
|
||||
-->
|
||||
26
pages/uses04.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Minimal Viable Kubernetes
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 🏠 Local development
|
||||
|
||||
### 🛠️ Integration and smoke testing
|
||||
|
||||
### 🎬 Pre-prod & production
|
||||
|
||||
### 💣 Disaster recovery rehearsal
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
prodduction can be never upgraded, rather, new productdion can replace old, provin infra as code and migrating to major updates
|
||||
|
||||
We are already backing up our data right ?
|
||||
|
||||
how can we prove our backups are valid without DR tests, rehearsals ?
|
||||
|
||||
we can if we have infra as code
|
||||
|
||||
-->
|
||||
31
pages/why.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Why ?
|
||||
|
||||
* 2025 building a minimal k8s for our own hosting
|
||||
* asked for an intro for techs getting into k8s
|
||||
* been working with Linux and Unix from SME to large enterprise since before Y2K
|
||||
* k8s since 2018
|
||||
|
||||
|
||||
<div v-click>
|
||||
|
||||
**I want to ...**
|
||||
|
||||
➤ bring down the cost of k8s
|
||||
|
||||
➤ pass on what I have learnt
|
||||
</div>
|
||||
|
||||
|
||||
<div v-click>
|
||||
➤ not pay vercel
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-->
|
||||
5912
pnpm-lock.yaml
generated
Normal file
BIN
public/boat-under-water.jpg
Normal file
|
After Width: | Height: | Size: 184 KiB |
BIN
public/cont13_c.jpg
Normal file
|
After Width: | Height: | Size: 150 KiB |
BIN
public/cont3_c.jpg
Normal file
|
After Width: | Height: | Size: 244 KiB |
BIN
public/cont8_c.jpg
Normal file
|
After Width: | Height: | Size: 267 KiB |
BIN
public/cont_ship3_c.jpg
Normal file
|
After Width: | Height: | Size: 205 KiB |
BIN
public/cont_ship4_c.jpg
Normal file
|
After Width: | Height: | Size: 295 KiB |
BIN
public/cont_ship5_c.jpg
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
public/container_night2_c.jpg
Normal file
|
After Width: | Height: | Size: 191 KiB |
BIN
public/container_pipeline.jpg
Normal file
|
After Width: | Height: | Size: 348 KiB |
BIN
public/containers.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
public/containers.webp
Normal file
|
After Width: | Height: | Size: 131 KiB |
BIN
public/containers2.jpg
Normal file
|
After Width: | Height: | Size: 270 KiB |
BIN
public/containers3.png
Normal file
|
After Width: | Height: | Size: 1.8 MiB |
BIN
public/containers3.webp
Normal file
|
After Width: | Height: | Size: 247 KiB |
BIN
public/error.png
Normal file
|
After Width: | Height: | Size: 831 KiB |
BIN
public/hi-and-dry.png
Normal file
|
After Width: | Height: | Size: 1.2 MiB |
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 129 KiB |
BIN
public/k8s-1.drawio.png
Normal file
|
After Width: | Height: | Size: 26 KiB |
BIN
public/k8s-2.drawio.png
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
public/k8s-3.drawio.png
Normal file
|
After Width: | Height: | Size: 57 KiB |
|
Before Width: | Height: | Size: 5.9 KiB After Width: | Height: | Size: 5.9 KiB |
BIN
public/og-image.png
Normal file
|
After Width: | Height: | Size: 737 KiB |
BIN
public/why.jpg
Normal file
|
After Width: | Height: | Size: 164 KiB |
46
scripts/instalL_asciinema.sh
Executable file
|
|
@ -0,0 +1,46 @@
|
|||
#!/usr/bin/env bash
|
||||
|
||||
|
||||
## available versions as of Tue 7 Oct 18:34:05 BST 2025
|
||||
|
||||
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-aarch64-apple-darwin
|
||||
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-aarch64-unknown-linux-gnu
|
||||
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-apple-darwin
|
||||
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-unknown-linux-gnu
|
||||
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-unknown-linux-musl
|
||||
|
||||
VERSION="3.0.0"
|
||||
LINK="https://github.com/asciinema/asciinema/releases/download/v${VERSION}/asciinema-"
|
||||
|
||||
unameOut="$(uname -s)"
|
||||
archOut="$(uname -m)"
|
||||
|
||||
case "${unameOut}" in
|
||||
Linux)
|
||||
if ldd --version 2>&1 | grep -q musl; then
|
||||
platform="x86_64-unknown-linux-musl"
|
||||
else
|
||||
platform="x86_64-unknown-linux-gnu"
|
||||
fi
|
||||
if [[ "${archOut}" == "aarch64" ]]; then
|
||||
platform="aarch64-unknown-linux-gnu"
|
||||
fi
|
||||
;;
|
||||
Darwin)
|
||||
if [[ "${archOut}" == "arm64" ]]; then
|
||||
platform="aarch64-apple-darwin"
|
||||
else
|
||||
platform="x86_64-apple-darwin"
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
echo "Unsupported platform: ${unameOut} ${archOut}"
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
echo "Detected platform: $platform"
|
||||
echo "installing asciinema version ${VERSION} for ${platform}"
|
||||
sudo curl -sL "${LINK}${platform}" -o /usr/local/bin/asciinema
|
||||
sudo chmod +x /usr/local/bin/asciinema
|
||||
asciinema --version
|
||||
151
slides.md
|
|
@ -3,7 +3,11 @@
|
|||
theme: seriph
|
||||
# random image from a curated Unsplash collection by Anthony
|
||||
# like them? see https://unsplash.com/collections/94734566/slidev
|
||||
background: https://cover.sli.dev
|
||||
# background: https://cover.sli.dev
|
||||
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/mYBMP8pW4uQ.webp
|
||||
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/zRkBOOpKRhs.webp
|
||||
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/3XXSKa4jKaM.webp
|
||||
background: container_pipeline.jpg
|
||||
# some information about your slides (markdown enabled)
|
||||
title: Minimal Viable Kubernetes
|
||||
info: |
|
||||
|
|
@ -30,7 +34,7 @@ seoMeta:
|
|||
|
||||
# Minimal Viable Kubernetes
|
||||
|
||||
Kubernetes for the impatient and impoverished
|
||||
Kubernetes for the impatient and pragmatic
|
||||
|
||||
Jon Brookes 2025
|
||||
|
||||
|
|
@ -49,15 +53,110 @@ Jon Brookes 2025
|
|||
</a>
|
||||
</div>
|
||||
|
||||
<!-- Hidden image reference to force bundling -->
|
||||
<img src="/containers.webp" alt="preload" style="display:none;" />
|
||||
|
||||
<!--
|
||||
This is an introduction to Minimal Viable Kubernetes (MVK). What it is, why it is and tooling around it.
|
||||
|
||||
why and why now ?
|
||||
|
||||
I created it because
|
||||
|
||||
* was building a minimal k8s for our own hosting
|
||||
* asked for an intro for techs getting into k8s
|
||||
|
||||
as I've been working with unix, linux and systems since before Y2K and k8s since 2018 I thought I could have something to say
|
||||
|
||||
so I wanted to
|
||||
|
||||
* use my own knowlege to deliver my own self managed k8s
|
||||
* bring down the cost of k8s
|
||||
* pass on what I have learnt
|
||||
* not pay vercel
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
layout: image-left
|
||||
image: why.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/intro-slide.md
|
||||
src: ./pages/why.md
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
layout: image-right
|
||||
image: cont3_c.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/intro01.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-right
|
||||
image: cont8_c.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/intro02.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-right
|
||||
image: containers3.png
|
||||
transition: fade-out
|
||||
src: ./pages/intro03.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-right
|
||||
image: containers2.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/intro04.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-right
|
||||
image: boat-under-water.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/intro05.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-left
|
||||
image: cont_ship3_c.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/uses01.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: image-left
|
||||
image: cont_ship4_c.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/uses02.md
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
layout: image-left
|
||||
image: cont_ship5_c.jpg
|
||||
transition: fade-out
|
||||
src: ./pages/uses03.md
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
layout: image-left
|
||||
image: hi-and-dry.png
|
||||
transition: fade-out
|
||||
src: ./pages/uses04.md
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
You can have `style` tag in markdown to override the style for the current page.
|
||||
Learn more: https://sli.dev/features/slide-scope-style
|
||||
|
|
@ -75,10 +174,6 @@ h1 {
|
|||
}
|
||||
</style>
|
||||
|
||||
<!--
|
||||
Here is another comment.
|
||||
-->
|
||||
|
||||
---
|
||||
src: ./pages/config-slide.md
|
||||
---
|
||||
|
|
@ -90,12 +185,48 @@ src: ./pages/plugins-slide.md
|
|||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/infctl-summary.md
|
||||
src: ./pages/usage-slide.md
|
||||
---
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/out-the-box-node.md
|
||||
---
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/make-it-work.md
|
||||
---
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/gcloud-single.md
|
||||
---
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/three-node-happy.md
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/infctl-summary.md
|
||||
---
|
||||
|
||||
---
|
||||
transition: fade-out
|
||||
src: ./pages/infctl-summary-end.md
|
||||
---
|
||||
|
||||
---
|
||||
layout: center
|
||||
class: text-center
|
||||
|
|
@ -108,5 +239,3 @@ class: text-center
|
|||
#### Jon Brookes
|
||||
|
||||
[https://headshed.dev/n25/](https://headshed.dev/n25/)
|
||||
|
||||
<PoweredBySlidev mt-10 />
|
||||
|
|
|
|||