new colors

blog posts

Co-authored-by: Andreas Nordahl <[email protected]>
Co-authored-by: Johnny Horvi <[email protected]>

Author: 3 people

package-lock.json

@@ -22,6 +22,7 @@
 		"eslint-plugin-svelte": "^2.36.0",
 		"globals": "^15.0.0",
 		"mdsvex": "^0.12.3",
+		"mdsvex-relative-images": "^1.0.3",
 		"prettier": "^3.3.2",
 		"prettier-plugin-svelte": "^3.2.6",
 		"svelte": "^5.0.0",

package.json

@@ -40,7 +40,7 @@
 		z-index: -1;
 	}
 	.section::after {
-		background: linear-gradient(to right, #3380a512, #6ee5c212);
+		background: linear-gradient(to right, #3381a53e, #6ee5c125);
 	}
 	.users {
 		font-size: 3rem;

src/lib/Brukere.svelte

@@ -67,6 +67,6 @@
 		z-index: -1;
 	}
 	.glances::after {
-		background: linear-gradient(to right, #ff910012, #f7689012);
+		background: linear-gradient(to right, #ff91002a, #f7689124);
 	}
 </style>

src/lib/Glances.svelte

@@ -33,7 +33,8 @@
 	</button>
 	<nav class="main-menu" class:isOpen>
 		<ul class="main-menu-list">
-			<li><a class:isActive={isActive("blogg")} href="/blog">Blogg</a></li>
+			<!-- <li><a class:isActive={isActive("blogg")} href="/blog">Blogg</a></li> -->
+			<li><a class="main-menu-item" href="https://nais.io/blog">Blogg</a></li>
 			<li><a class="main-menu-item" href="https://docs.nais.io">Dokumentasjon</a></li>
 			<!-- <li><a class="main-menu-item" href="/annonseringer" class:isActive={isActive('annonseringer')}>Annonseringer</a></li> -->
 			<!-- <li>
@@ -87,11 +88,11 @@
 	}
 	.header::before {
 		transform: translate(-75%, -60%);
-		background: linear-gradient(to right, #ff910012, #f7689028, #6200ff15);
+		background: linear-gradient(to right, #ff910067, #f7689155, #6200ff51);
 	}
 	.header::after {
 		transform: translate(0, -60%);
-		background: linear-gradient(to right, #3380a518, #6ee5c218);
+		background: linear-gradient(to right, #3381a542, #6ee5c131);
 	}
 
 	.home {

src/lib/Header.svelte

@@ -1,6 +1,5 @@
 interface Post {
 	route: string;
-	content: string;
 	metadata: {
 		title: string;
 		date: string;

src/routes/blog/+page.server.ts

@@ -0,0 +1 @@
+<slot />

src/routes/blog/posts/+layout.svelte

@@ -7,7 +7,6 @@ author: Frode Sundby
 tags: [istio, linkerd, LoadBalancing]
 ---
 
-
 ## Why change?
 With an ambition of making our environments as secure as possible, we jumped on the service-mesh bandwagon in 2018 with Istio 0.7 and have stuck with it since.
 
@@ -23,7 +22,7 @@ We looked to the grand ol' Internet for alternatives and fixed our gaze on the r
 Having honed in on our preferred candidate, we decided to take it for a quick spin in a cluster and found our suspicions to be accurate.
 
 Rarely has a meme depicted a feeling more strongly
-<!--![service-mesh-experiance](/blog/images/service-mesh-experience.jpg)-->
+![service-mesh-experiance](./images/service-mesh-experience.jpg)
 
 Even though we'd invested a lot of time and built in quite a bit of Istio into our platform, we knew we had to make the change.
 
@@ -36,7 +35,7 @@ The traffic was then forwarded to the Istio Ingressgateway, who in turn sent it
 Before the Ingressgateway could reach the application, both NetworkPolicies and AuthorizationPolicies were required to allow the traffic.
 We used an [operator](https://github.com/nais/naiserator) to configure these policies when an application was deployed.
 
-<!-- ![changing-service-mesh](/blog/images/changing-service-mesh-1.png) -->
+![changing-service-mesh-1](./images/changing-service-mesh-1.png)
 
 ### New LoadBalancers and ingress controllers
 Since our LoadBalancers were configured by (and sent traffic to) Istio, we had to change the way we configured them.
@@ -86,7 +85,7 @@ spec:
 ```
 
 Alrighty. We'd now gotten ourselves a brand new set of independantly configured LoadBalancers and a shiny new Ingress Controller.
-<!-- ![changing-service-mesh](/blog/images/changing-service-mesh-2.png) -->
+![changing-service-mesh-2](./images/changing-service-mesh-2.png)
 
 However - if we'd started shipping traffic to the new components at this stage, things would start breaking as there were no ingresses in the cluster - only VirtualServices.
 To avoid downtime, we created an interim ingress that forwarded all traffic to the Istio IngressGateway:
@@ -104,7 +103,7 @@ spec:
         path: /
   ...
 ```
-<!-- ![changing-service-mesh](/blog/images/changing-service-mesh-3.png) -->
+![changing-service-mesh-3](./images/changing-service-mesh-3.png)
 With this ingress in place, we could reach all the existing VirtualServices exposed by the Istio Ingressgateway via the new Loadbalancers and Nginx.
 And we could point our DNS records to the new rig without anyone noticing a thing.
 
@@ -127,7 +126,7 @@ One thing we didn't take into concideration (but should have), was that some app
 When an ingress was created for a shared hostname, Nginx would stop forwarding requests for these hosts to Istio Ingressgateway, resulting in non-migrated applications not getting any traffic.
 Realizing this, we started migrating applications on the same hostname simultaneously too.
 
-<!-- ![changing-service-mesh](/blog/images/changing-service-mesh-4.png) -->
+![changing-service-mesh-4](./images/changing-service-mesh-4.png)
 And within a couple of hours, all workloads were migrated and we had ourselves a brand spanking new service-mesh in production.
 And then they all lived happily ever after...
 
@@ -137,7 +136,7 @@ Except that we had to clean up Istio's mess.
 What was left after the party was a fully operational Istio control plane, a whole bunch of Istio CRD's and a completely unused set of LoadBalancers. In addition we had to clean up everything related to Istio in a whole lot of pipelines and components
 
 
-<!-- ![changing-service-mesh](/blog/images/changing-service-mesh-5.png)
-![changing-service-mesh](/blog/images/changing-service-mesh-6.png) -->
+![changing-service-mesh-5](./images/changing-service-mesh-5.png)
+![changing-service-mesh-6](./images/changing-service-mesh-6.png)
 
 It has to be said - there is a certain satisfaction in cleaning up after a party that has been going on for too long.

src/routes/blog/posts/changing-service-mesh/+page.md

@@ -8,7 +8,7 @@
 
 body {
 	font-family: 'Poppins', sans-serif;
-	background-color: #f7fafe;
+	background-color: #faf3f8;
 	color: #222;
 }
 a {

src/routes/blog/posts/changing-service-mesh/images/changing-service-mesh-1.png

@@ -1,13 +1,20 @@
 import adapter from "@sveltejs/adapter-static";
 import path from "path";
 import { mdsvex } from "mdsvex";
+import remarkRelativeImages from "mdsvex-relative-images";
+
 
 /** @type {import('@sveltejs/kit').Config} */
 const config = {
 	// Consult https://github.com/sveltejs/svelte-preprocess
 	// for more information about preprocessors
 	extensions: ['.svelte', '.svx', '.md'],
-	preprocess: mdsvex({extensions: ['.svx', '.md']}),
+	preprocess: [
+		mdsvex({
+			extensions: ['.svx', '.md', '.mdx'],
+			remarkPlugins: [remarkRelativeImages],
+		})
+	],
 
 	kit: {
 		adapter: adapter({