From afc10bbc32c8852158c2213a9bf24e0808bd3302 Mon Sep 17 00:00:00 2001
From: Sheogorath <sheogorath@shivering-isles.com>
Date: Wed, 17 Jan 2024 00:58:41 +0100
Subject: [PATCH] docs: Rework video integration into documentation

---
 docs/book.toml              |  1 +
 docs/custom.css             |  4 ++++
 docs/src/concepts/gitops.md |  4 ++--
 docs/src/concepts/sre.md    | 21 +++++++++++++--------
 4 files changed, 20 insertions(+), 10 deletions(-)
 create mode 100644 docs/custom.css

diff --git a/docs/book.toml b/docs/book.toml
index 1a9bf5a7e..7f17e3b94 100644
--- a/docs/book.toml
+++ b/docs/book.toml
@@ -10,3 +10,4 @@ git-repository-icon = "fa-gitlab"
 git-repository-url = "https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/tree/main/docs"
 edit-url-template = "https://git.shivering-isles.com/-/ide/project/shivering-isles/infrastructure-gitops/edit/main/-/docs/{path}"
 additional-js = ["external-links.js"]
+additional-css = ["custom.css"]
diff --git a/docs/custom.css b/docs/custom.css
new file mode 100644
index 000000000..1f40e361e
--- /dev/null
+++ b/docs/custom.css
@@ -0,0 +1,4 @@
+iframe[src^="https://www.youtube-nocookie.com/"] {
+    aspect-ratio: 16 / 9;
+    width: 100%;
+}
\ No newline at end of file
diff --git a/docs/src/concepts/gitops.md b/docs/src/concepts/gitops.md
index ef0f6eb2b..3aa04bacf 100644
--- a/docs/src/concepts/gitops.md
+++ b/docs/src/concepts/gitops.md
@@ -4,10 +4,10 @@ The Shivering-Isles Infrastructure uses GitOps as central concept to maintain th
 
 The current tool of choice to implement GitOps in the Shivering-Isles Infrastructure is [FluxCD](https://fluxcd.io/) in combination with a monorepo.
 
-<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/lI03nh0EmaQ" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<iframe src="https://www.youtube-nocookie.com/embed/lI03nh0EmaQ" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
 ## GitOps Security
 
 To secure GitOps based deployments and reduce the risks of compromise, the GitOps deployment in the Shivering-Isles Infrastructure only accepts signed commits. This prevents a deployment of workload if an attackers mananges to push a commit onto the GitOps repository. The git forge itself is in charge of preventing rollbacks in the commit history. Rollbacks could be prevented by using git tags instead of git branches as reference, but are less practical.
 
-Further all secrets stored in the GitOps repository are encrypted using [SOPS](https://getsops.io/) along with unsensitive, but irrelevant information, such as dns names.
+Further all secrets stored in the GitOps repository are encrypted using [SOPS](https://getsops.io/) along with insensitive, but irrelevant information, such as dns names.
diff --git a/docs/src/concepts/sre.md b/docs/src/concepts/sre.md
index e84fefa85..fb413b843 100644
--- a/docs/src/concepts/sre.md
+++ b/docs/src/concepts/sre.md
@@ -8,21 +8,26 @@ In the Shivering-Isles Infrastructure various apps have an own set of SLOs to va
 
 Besides maintaining reasonable SLOs, other SRE practices are implemented, such as post mortems and especially the practice of reducing toil. All components of the infrastructure have a maintenance budget, if it's depleted, it's time to fix the apps or get rid of it.
 
+Service Level Objectives
+---
+
+All public facing apps  and infrastructure components should have an Service Level Objective (SLO). The most basic SLOs for web apps are the availability and latency measured through the ingress controller. [An examples for an SLO definitions is the Shivering-Isles blog.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/blog/slo.yaml)
+
+Apps that provide more insight via metrics, can have app-specific SLOs to optimise for user impacting situations, that aren't covered by basic web metrics. [An example is the sidekiq SLO for Mastodon.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/mastodon/slo.yaml#L9-21)
+
+The actual objectives in the Shivering-Isles infrastructure are often relatively low around 95 percent.
+
 Learning about SRE
 ---
 
 A good start is this small video Series by Google:
 
-<iframe width="100%" height="480" src="https://www.youtube-nocookie.com/embed/?listType=playlist&list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-
+<iframe src="https://www.youtube-nocookie.com/embed/?listType=playlist&list=PLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
 Further there is the [Google SRE book](https://sre.google/sre-book/introduction/) as recommended read.
 
-Service Level Objectives
----
-
-All public facing apps should have an Service Level Objective (SLO). The most basic SLOs for web apps are the availability and latency measured throught the ingress controller. [An examples for an SLO definitions is the Shivering-Isles blog.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/blog/slo.yaml)
+Further there are some good talks from SREcon:
 
-Apps that provide more insight via metrics, can have app-specific SLOs to optimise for user impacting situations, that aren't covered by basic web metrics. [An example is the sidekiq SLO for Mastodon.](https://git.shivering-isles.com/shivering-isles/infrastructure-gitops/-/blob/797843c960f82a1974e2c3b632f0d45e5de9d6fe/apps/k8s01/mastodon/slo.yaml#L9-21)
+<iframe src="https://www.youtube-nocookie.com/embed/cKBRxLF22Mk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
-The actual objectives in the Shivering-Isles infrastructure are often relatively low around 95 percent.
\ No newline at end of file
+<iframe src="https://www.youtube-nocookie.com/embed/jNP4nzIMK8E" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-- 
GitLab