formatting improvements and standardisation changes

Author: vjdhama

content/blog/.markdownlint.json

@@ -0,0 +1,10 @@
+{
+    "MD033": {
+        "allowed_elements": [
+            "nobr",
+            "sup",
+            "p"
+        ]
+    },
+    "MD013": false
+}

content/blog/rpi-netboot-automation.md

@@ -190,7 +190,7 @@ configure_pxe_services() {
 
 The `addresslist.txt` file serves as a record of processed MAC addresses. Before executing the setup for a new MAC address, the script checks this list to ensure it hasn't already been configured. This prevents unnecessary duplication of efforts. Create `addresslist.txt` in the `/opt` directory. Here's an example of how the `addresslist.txt` file might look:
 
-```
+```text
 00-11-22-33-44-55
 aa-bb-cc-dd-ee-ff
 ```

content/blog/rpi-netboot-deep-dive.md

@@ -11,14 +11,14 @@ weight: 1
 
 ### What is PXE Boot?
 
-The Preboot Execution Environment (PXE) specification describes a standardized client–server environment that boots a software assembly retrieved from a network on PXE-enabled clients.
+The Preboot Execution Environment (PXE) specification describes a standardized client-server environment that boots a software assembly retrieved from a network on PXE-enabled clients.
 
 ### Why PXE Boot?
 
 - Simplify Pi provisioning and maintenance as much as possible.
 - Automate updates/upgrades as much as possible.
 
-Netbooting is a good path to achieve this. For example, when you netboot a Pi, it does not require an SD card to boot. The OS and file system live on a central server. Because most of the provisioning happens on a central server, we can eventually automate it via scripts.
+Netbooting is a good path to achieve this. For example, when you netboot a Pi, it does not require an SD card to boot. The OS and file system live on a central server. Because most provisioning happens on a central server, we can eventually automate it via scripts.
 
 ### PXE Boot Sequence
 
@@ -66,7 +66,7 @@ Netbooting is a good path to achieve this. For example, when you netboot a Pi, i
 To implement netbooting for Raspberry Pi devices, you'll need the following components:
 
 - Raspberry Pi units acting as PXE clients connected via Ethernet to the router or switch.
-- Raspberry Pi acting as a PXE server containing boot files and user files connected via Ethernet to the router or switch.
+- Raspberry Pi as a PXE server containing boot files and user files connected via Ethernet to the router or switch.
 
 ## Configuration
 
@@ -132,6 +132,7 @@ $ sudo mkdir -p /tftpboot/<MAC_ADDRESS>
 $ sudo chmod 777 /tftpboot
 $ sudo cp -r ~/bootfiles/* /tftpboot/<MAC_ADDRESS>
 ```
+
 **Important Note:** Replace `192.168.XX.XX` with the IP address of PXE server and `<MAC_ADDRESS>` with the MAC address of PXE client.
 
 #### Configure `dnsmasq.conf`
@@ -156,4 +157,4 @@ EOF
 
 ### Conclusion
 
-In conclusion, implementing PXE boot for Raspberry Pi devices streamlines deployment and maintenance by centralizing the boot process and file systems. Automation of these processes further enhances efficiency and reduces manual intervention. To learn more about automating Raspberry Pi deployment using PXE boot, click [here](https://www.infraspec.dev/blog/rpi-netboot-automation).
+In conclusion, implementing PXE boot for Raspberry Pi devices streamlines deployment and maintenance by centralizing the boot process and file systems. Automation of these processes further enhances efficiency and reduces manual intervention. To learn more about automating Raspberry Pi deployment using PXE boot, click [here](https://www.infraspec.dev/blog/rpi-netboot-automation).

content/blog/setting-up-ingress-on-eks.md

@@ -11,31 +11,31 @@ weight: 1
 
 * * * * *
 
-**What is an Ingress?**
------------------------
+## What is an Ingress?
 
 An Ingress in Kubernetes provides external access to your Kubernetes services. You configure access by creating a collection of routing rules that define which requests reach which services.
 
 This lets you consolidate your routing rules into a single resource. For example, you might want to send requests to [mydomain.com/](http://example.com/api/v1)api1 to the api1 service, and requests to [mydomain.com/](http://example.com/api/v2)api2 to the api2 service. With an Ingress, you can easily set this up without creating a bunch of LoadBalancers or exposing each service on the Node.
 
 *An Ingress provides the following:*
 
--   Externally reachable URLs for applications deployed in Kubernetes clusters
--   Name-based virtual host and URI-based routing support
--   Load Balancing rules and traffic, as well as SSL termination
+- Externally reachable URLs for applications deployed in Kubernetes clusters
+- Name-based virtual host and URI-based routing support
+- Load Balancing rules and traffic, as well as SSL termination
 
-**Kubernetes Service types -- an overview**
-------------------------------------------
+## Kubernetes Service types -- an overview
 
 ### ClusterIP
 
 A ClusterIP service is the default service. It gives you a service inside your cluster that other apps inside your cluster can access. There is no external access.
 
-![ClusterIP](/images/blog/setting-up-ingress-on-eks/cluster-ip.png)
+<p align="center">
+  <img width="500px" src="/images/blog/setting-up-ingress-on-eks/cluster-ip.png" alt="ClusterIP">
+</p>
 
 *The YAML for ClusterIP service looks like this:*
 
-```shell
+```yaml
 apiVersion: v1
 kind: Service
 metadata:
@@ -55,15 +55,15 @@ spec:
 
 Create the service:
 
-```shell
+```bash
 $ kubectl apply -f nginx-svc.yaml
 service/nginx-service created
 
 ```
 
 Check it:
 
-```shell
+```bash
 $ kubectl get svc nginx-serice
 NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
 nginx-service   ClusterIP   172.20.54.138   <none>        80/TCP    38s
@@ -76,7 +76,9 @@ A NodePort service is the most primitive way to get external traffic directly to
 
 When we create a Service of type NodePort, Kubernetes gives us a nodePort value. Then the Service is accessible by using the IP address of any node along with the nodePort value. In other words, when a user sets the Service type field to NodePort, the Kubernetes master allocates a static port from a range, and each Node will proxy that port (the same port number on every Node) into our Service.
 
-![NodePort](/images/blog/setting-up-ingress-on-eks/node-port.png)
+<p align="center">
+  <img width="500px" src="/images/blog/setting-up-ingress-on-eks/node-port.png" alt="NodePort">
+</p>
 
 *The YAML for NodePort service looks like this:*
 
@@ -128,11 +130,13 @@ In case of AWS -- will create an AWS Load Balancer, by default Classic type, whi
 
 `LoadBalancer` type provides a Public IP address or DNS name to which the external users can connect. The traffic flows from the LoadBalancer to a mapped service on a designated port, which eventually forwards it to the healthy pods. Note that LoadBalancers doesn't have a direct mapping to the pods.
 
-![LoadBalancer](/images/blog/setting-up-ingress-on-eks/load-balancer.png)
+<p align="center">
+  <img width="400px" src="/images/blog/setting-up-ingress-on-eks/load-balancer.png" alt="LoadBalancer">
+</p>
 
 *The YAML for LoadBalancer service looks this:*
 
-```shell
+```yaml
 apiVersion: v1
 kind: Service
 metadata:
@@ -145,20 +149,19 @@ spec:
   ports:
     - name: http
       port: 80
-
 ```
 
 Apply it:
 
-```shell
+```yaml
 $ kubectl apply -f nginx-svc.yaml
 service/nginx-service created
 
 ```
 
 Check:
 
-```shell
+```yaml
 $ kubectl get svc nginx-service
 NAME            TYPE           CLUSTER-IP      EXTERNAL-IP                                                              PORT(S)        AGE
 nginx-service   LoadBalancer   172.20.54.138   ac8415de24f6c4db9b5019f789792e45-443260761.ap-south-1.elb.amazonaws.com   80:30968/TCP   1h
@@ -167,25 +170,28 @@ nginx-service   LoadBalancer   172.20.54.138   ac8415de24f6c4db9b5019f789792e45-
 
 So, the *LoadBalancer* service type:
 
--   will provide external access to pods
--   will provide a basic load-balancing to pods on different EC2
--   will give an ability to terminate SSL/TLS sessions
--   doesn't support level-7 routing
+- will provide external access to pods
+- will provide a basic load-balancing to pods on different EC2
+- will give an ability to terminate SSL/TLS sessions
+- doesn't support level-7 routing
 
 *The big downside is that each service you expose with a LoadBalancer will get its own IP address, and you have to pay for a LoadBalancer per exposed service, which can get expensive!*
 
-Ingress
--------
+## Ingress
 
 Unlike all the above examples, Ingress is actually NOT a dedicated Service. Instead, it sits in front of multiple services and act as a "smart router" or entrypoint into your cluster.
 
 It just describes a set of rules for the Kubernetes Ingress Controller to create a Load Balancer, its Listeners, and routing rules for them.
 
 An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type [Service.Type=NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) or [Service.Type=LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
 
-![Ingress](/images/blog/setting-up-ingress-on-eks/ingress.png)
+<p align="center">
+  <img width="500px" src="/images/blog/setting-up-ingress-on-eks/ingress.png" alt="Ingress">
+</p>
 
-![Ingress managed LB](/images/blog/setting-up-ingress-on-eks/ingress-managed-lb.png)
+<p align="center">
+  <img width="700px" src="/images/blog/setting-up-ingress-on-eks/ingress-managed-lb.png" alt="Ingress managed LB">
+</p>
 
 _image source: https://kubernetes.io/docs/concepts/services-networking/ingress/_
 
@@ -197,14 +203,14 @@ An [Ingress controller](https://kubernetes.io/docs/concepts/services-networking
 
 Install:
 
-```shell
+```bash
 $ kubectl apply -f <https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.1/deploy/static/provider/cloud/deploy.yaml>
 
 ```
 
 Output:
 
-```shell
+```bash
 namespace/ingress-nginx created
 serviceaccount/ingress-nginx created
 clusterrole.rbac.authorization.k8s.io/ingress-nginx created
@@ -228,17 +234,17 @@ job.batch/ingress-nginx-admission-patch created
 
 A few pods should start in the `ingress-nginx` namespace:
 
-```shell
+```bash
 $ kubectl get pods --namespace=ingress-nginx
 
 ```
 
 After a while, they should all be running. The following command will wait for the ingress controller pod to be up, running, and ready:
 
-```shell
-$ kubectl wait --namespace ingress-nginx \\
-  --for=condition=ready pod \\
-  --selector=app.kubernetes.io/component=controller \\
+```bash
+$ kubectl wait --namespace ingress-nginx \
+  --for=condition=ready pod \
+  --selector=app.kubernetes.io/component=controller \
   --timeout=120s
 
 ```
@@ -249,7 +255,7 @@ This has set up the Nginx Ingress Controller. Now, we can create Ingress resourc
 
 First, let's create two services to demonstrate how the Ingress routes our request. We'll run two web applications that output a slightly different response.
 
-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -278,7 +284,7 @@ spec:
 
 ```
 
-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -309,15 +315,15 @@ spec:
 
 Create the resources
 
-```shell
+```bash
 $ kubectl apply -f apple.yaml
 $ kubectl apply -f banana.yaml
 
 ```
 
 Now, declare an Ingress to route requests to `/apple` to the first service, and requests to `/banana`  to second service.
 
-```shell
+```yaml
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
@@ -349,7 +355,7 @@ Here we set two rules: if URI == */apple* or */banana*  -- then send the traffi
 
 Deploy it:
 
-```shell
+```bash
 $ kubectl apply -f ingress.yaml
 
 ```
@@ -358,7 +364,7 @@ Another example is the hostname-based routing.
 
 *Update the manifest:*
 
-```shell
+```yaml
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
@@ -393,13 +399,15 @@ The Ingress controller provisions an implementation-specific load balancer that
 
 Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
 
-![Name based virtual hosting](/images/blog/setting-up-ingress-on-eks/name-based-virtual-hosting.png)
+<p align="center">
+  <img width="500px" src="/images/blog/setting-up-ingress-on-eks/name-based-virtual-hosting.png" alt="Name based virtual hosting">
+</p>
 
 image source: https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting
 
 The following Ingress tells the backing load balancer to route requests based on the Host header.
 
-```shell
+```yaml
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
@@ -431,8 +439,7 @@ spec:
 
 Here we left Services without changes, but in the Rules, we set that a request to the *[apple.service.com](http://apple.service.com)* must be sent to the *apple-service* and *[banana.service.com](http://banana.service.com)* to the banana-service.
 
-Summary
--------
+## Summary
 
 A Kubernetes Ingress is a robust way to expose your services outside the cluster. It lets you consolidate your routing rules to a single resource, and gives you powerful options for configuring these rules.