Forem: Thu Kha Kyawe

7.Deploy Grafana on Kubernetes Cluster

Thu Kha Kyawe — Tue, 14 Apr 2026 14:03:22 +0000

Lab Information

The Nautilus DevOps teams is planning to set up a Grafana tool to collect and analyze analytics from some applications. They are planning to deploy it on Kubernetes cluster. Below you can find more details.

1.) Create a deployment named grafana-deployment-devops using any grafana image for Grafana app. Set other parameters as per your choice.

2.) Create NodePort type service with nodePort 32000 to expose the app.

You need not to make any configuration changes inside the Grafana app once deployed, just make sure you are able to access the Grafana login page.

Note: The kubectl on jump_host has been configured to work with kubernetes cluster.

Lab Solutions

Step 1: Create the Grafana Deployment YAML file

First, create a deployment configuration file:

cat > grafana-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana-deployment-devops
  labels:
    app: grafana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest
        ports:
        - containerPort: 3000
        env:
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: "admin123"
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

Step 2: Create the NodePort Service YAML file

Now create the service configuration:

cat > grafana-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana-service
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 32000
  selector:
    app: grafana
EOF

Step 3: Deploy the Grafana Deployment

Apply the deployment to your Kubernetes cluster:

kubectl apply -f grafana-deployment.yaml

Step 4: Deploy the NodePort Service

Apply the service configuration:

kubectl apply -f grafana-service.yaml

Step 5: Verify the Deployment

Check if the deployment was created successfully:

kubectl get deployments

Step 6: Verify the Service

Check if the service is running:

kubectl get services

Step 7: Check the Pod Status

Verify that the Grafana pod is running:

kubectl get pods -l app=grafana

Step 8: Access Grafana

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

6.Deploy Jenkins on Kubernetes

Thu Kha Kyawe — Mon, 13 Apr 2026 05:35:54 +0000

Lab Information

The Nautilus DevOps team is planning to set up a Jenkins CI server to create/manage some deployment pipelines for some of the projects. They want to set up the Jenkins server on Kubernetes cluster. Below you can find more details about the task:

1) Create a namespace jenkins

2) Create a Service for jenkins deployment. Service name should be jenkins-service under jenkins namespace, type should be NodePort, nodePort should be 30008

3) Create a Jenkins Deployment under jenkins namespace, It should be name as jenkins-deployment , labels app should be jenkins , container name should be jenkins-container , use jenkins/jenkins image , containerPort should be 8080 and replicas count should be 1.

Make sure to wait for the pods to be in running state and make sure you are able to access the Jenkins login screen in the browser before hitting the Check button.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Jenkins Namespace

kubectl create namespace jenkins

Step 2: Create the Jenkins Service

Create a YAML file for the NodePort service:

cat > jenkins-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: jenkins-service
  namespace: jenkins
spec:
  type: NodePort
  selector:
    app: jenkins
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
      nodePort: 30008
EOF

Apply the service:

kubectl apply -f jenkins-service.yaml

Step 3: Create the Jenkins Deployment

Create a YAML file for the deployment:

cat > jenkins-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins-deployment
  namespace: jenkins
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      containers:
      - name: jenkins-container
        image: jenkins/jenkins
        ports:
        - containerPort: 8080
EOF

Apply the deployment:

kubectl apply -f jenkins-deployment.yaml

Step 4: Monitor the Deployment Progress

Check the status of the pod:

kubectl get pods -n jenkins

Wait until the pod status shows Running. This might take a few minutes as the Jenkins image needs to be pulled and the container needs to start up.

You can also check the deployment status:

kubectl get deployment -n jenkins

Step 5: Verify Service Configuration

Check that the service is properly configured:

kubectl get svc -n jenkins

Step 7: Access Jenkins

Once the pod is in Running state, you can access Jenkins:

Step 8: Final Verification Commands

Run these commands to verify everything is set up correctly:

Check all resources in jenkins namespace

kubectl get all -n jenkins

Verify pod details

kubectl describe pod -l app=jenkins -n jenkins

Verify service details

kubectl describe svc jenkins-service -n jenkins

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

5.Rolling Updates And Rolling Back Deployments in Kubernetes

Thu Kha Kyawe — Mon, 13 Apr 2026 05:20:58 +0000

Lab Information

There is a production deployment planned for next week. The Nautilus DevOps team wants to test the deployment update and rollback on Dev environment first so that they can identify the risks in advance. Below you can find more details about the plan they want to execute.

Create a namespace devops. Create a deployment called httpd-deploy under this new namespace, It should have one container called httpd, use httpd:2.4.25 image and 3 replicas. The deployment should use RollingUpdate strategy with maxSurge=1, and maxUnavailable=2. Also create a NodePort type service named httpd-service and expose the deployment on nodePort: 30008.

Now upgrade the deployment to version httpd:2.4.43 using a rolling update.

Finally, once all pods are updated undo the recent update and roll back to the previous/original version.

Note:

a. The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

b. Please make sure you only use the specified image(s) for this deployment and as per the sequence mentioned in the task description. If you mistakenly use a wrong image and fix it later, that will also distort the revision history which can eventually fail this task.

Lab Solutions

Step 1: Create the Namespace

First, create the devops namespace:

kubectl create namespace devops

Step 2: Create the Deployment

Create a YAML file for the deployment with the specified configuration:

cat > httpd-deploy.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deploy
  namespace: devops
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 2
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.25
        ports:
        - containerPort: 80
EOF

Apply the deployment:

kubectl apply -f httpd-deploy.yaml

Step 3: Create the Service

Create a YAML file for the NodePort service:

cat > httpd-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: httpd-service
  namespace: devops
spec:
  type: NodePort
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008
EOF

Apply the service:

kubectl apply -f httpd-service.yaml

Step 4: Verify Initial Deployment

Check that everything is running correctly:

kubectl get all -n devops

Step 5: Upgrade the Deployment

Upgrade to the new image version using rolling update:

kubectl set image deployment/httpd-deploy httpd=httpd:2.4.43 -n devops

Monitor the rolling update progress:

kubectl rollout status deployment/httpd-deploy -n devops

Verify the upgrade:

kubectl get pods -n devops -o wide
kubectl describe deployment httpd-deploy -n devops

Step 6: Rollback to Previous Version

Undo the recent update and roll back to the original version:

kubectl rollout undo deployment/httpd-deploy -n devops

Monitor the rollback progress:

kubectl rollout status deployment/httpd-deploy -n devops

Step 7: Final Verification

Verify that the rollback was successful:

kubectl get pods -n devops -o wide
kubectl describe deployment httpd-deploy -n devops

Check the rollout history:

kubectl rollout history deployment/httpd-deploy -n devops

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

4.Print Environment Variables

Thu Kha Kyawe — Mon, 13 Apr 2026 05:14:55 +0000

Lab Information

The Nautilus DevOps team is working on to setup some pre-requisites for an application that will send the greetings to different users. There is a sample deployment, that needs to be tested. Below is a scenario which needs to be configured on Kubernetes cluster. Please find below more details about it.

Create a pod named print-envars-greeting.

Configure spec as, the container name should be print-env-container and use bash image.

Create three environment variables:

a. GREETING and its value should be Welcome to

b. COMPANY and its value should be DevOps

c. GROUP and its value should be Datacenter

Use command ["/bin/sh", "-c", 'echo "$(GREETING) $(COMPANY) $(GROUP)"'] (please use this exact command), also set its restartPolicy policy to Never to avoid crash loop back.

You can check the output using kubectl logs -f print-envars-greeting command.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Pod YAML configuration

Create a file named print-envars-greeting.yaml:

cat > print-envars-greeting.yaml << 'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: print-envars-greeting
spec:
  containers:
  - name: print-env-container
    image: bash
    command: ["/bin/sh", "-c", 'echo "$GREETING $COMPANY $GROUP"']
    env:
    - name: GREETING
      value: "Welcome to"
    - name: COMPANY
      value: "DevOps"
    - name: GROUP
      value: "Datacenter"
  restartPolicy: Never
EOF

Step 2: Create the Pod

Apply the configuration to create the pod:

kubectl apply -f print-envars-greeting.yaml

Step 3: Check the Pod Status

Monitor the pod status to see when it completes:

kubectl get pod print-envars-greeting

You'll see the status change from Pending → Running → Completed (or Succeeded).

Step 4: View the Output

Check the logs to see the output of the command:

kubectl logs print-envars-greeting

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

3.Deploy Nginx Web Server on Kubernetes Cluster

Thu Kha Kyawe — Sun, 12 Apr 2026 15:10:17 +0000

Lab Information

Some of the Nautilus team developers are developing a static website and they want to deploy it on Kubernetes cluster. They want it to be highly available and scalable. Therefore, based on the requirements, the DevOps team has decided to create a deployment for it with multiple replicas. Below you can find more details about it:

Create a deployment using nginx image with latest tag only and remember to mention the tag i.e nginx:latest. Name it as nginx-deployment. The container should be named as nginx-container, also make sure replica counts are 3.

Create a NodePort type service named nginx-service. The nodePort should be 30011.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Deployment YAML configuration

Create a file named nginx-deployment.yaml:

cat > nginx-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest
        ports:
        - containerPort: 80
EOF

Step 2: Create the Deployment

Apply the deployment configuration:

kubectl apply -f nginx-deployment.yaml

Step 3: Verify the Deployment

Check if the deployment is created and all replicas are running:

kubectl get deployment nginx-deployment

Step 4: Verify the Pods

Check the pods created by the deployment:

kubectl get pods -l app=nginx

Step 5: Create the Service YAML configuration

Create a file named nginx-service.yaml:

cat > nginx-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30011
EOF

Step 6: Create the Service

Apply the service configuration:

kubectl apply -f nginx-service.yaml

Step 7: Verify the Service

Check if the service is created correctly:

kubectl get service nginx-service

Step 8: Detailed Service Verification

Get more details about the service:

kubectl describe service nginx-service

Step 9: Test the Setup

Test if the service is working by accessing it. Since this is a Kubernetes cluster, you can test using:

Using curl from inside the cluster

Get the Cluster IP of the service

CLUSTER_IP=$(kubectl get service nginx-service -o jsonpath='{.spec.clusterIP}')

Test access using Cluster IP

kubectl run test-pod --image=nginx:latest --rm -it --restart=Never -- bash -c "curl http://$CLUSTER_IP"

Step 10: Verify Endpoints

Check that the service is correctly targeting all 3 pods:

kubectl get endpoints nginx-service

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

2.Kubernetes Sidecar Containers

Thu Kha Kyawe — Sun, 12 Apr 2026 15:03:43 +0000

Task Information

We have a web server container running the nginx image. The access and error logs generated by the web server are not critical enough to be placed on a persistent volume. However, Nautilus developers need access to the last 24 hours of logs so that they can trace issues and bugs. Therefore, we need to ship the access and error logs for the web server to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from nginx. Nginx does one thing, and it does it well—serving web pages. The second container also specializes in its task—shipping logs. Since containers are running on the same Pod, we can use a shared emptyDir volume to read and write logs.

Create a pod named webserver.

Create an emptyDir volume shared-logs.

Create two containers from nginx and ubuntu images with latest tag only and remember to mention tag i.e nginx:latest, nginx container name should be nginx-container and ubuntu container name should be sidecar-container on webserver pod.

Add command on sidecar-container "sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"

Mount the volume shared-logs on both containers at location /var/log/nginx, all containers should be up and running.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Task Solutions

Step 1: Create the Pod YAML configuration

Create a file named webserver-pod.yaml:

cat > webserver-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  - name: sidecar-container
    image: ubuntu:latest
    command: ["sh", "-c", "while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  volumes:
  - name: shared-logs
    emptyDir: {}
EOF

Step 2: Create the pod

Apply the configuration to create the pod:

kubectl apply -f webserver-pod.yaml

Step 3: Verify the pod is running

Check if the pod is created and both containers are running:

kubectl get pod webserver

Step 4: Check the detailed status of the pod

Verify both containers are properly configured:

kubectl describe pod webserver

Step 5: Test the sidecar container logs

Check the logs of the sidecar container to see if it's reading the nginx logs:

kubectl logs webserver -c sidecar-container

Step 6: Generate some web traffic to create logs

Let's generate some access to the nginx server to create log entries:

First, find the nginx container's IP

kubectl get pod webserver -o wide

Then access the nginx server (you can use the pod IP or port-forward):

Using port-forward

In one terminal, set up port forwarding

kubectl port-forward webserver 8080:80

Step 7: Verify the sidecar is shipping logs

After generating some traffic, check the sidecar container logs again:

kubectl logs webserver -c sidecar-container

Step 8: Verify volume mounting

Check that both containers have the volume mounted correctly:

Check nginx container

kubectl exec -it webserver -c nginx-container -- ls -la /var/log/nginx/

Check sidecar container

kubectl exec -it webserver -c sidecar-container -- ls -la /var/log/nginx/

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

1.Kubernetes Shared Volumes

Thu Kha Kyawe — Mon, 06 Apr 2026 14:32:03 +0000

Lab Information

We are working on an application that will be deployed on multiple containers within a pod on Kubernetes cluster. There is a requirement to share a volume among the containers to save some temporary data. The Nautilus DevOps team is developing a similar template to replicate the scenario. Below you can find more details about it.

Create a pod named volume-share-devops.

For the first container, use image fedora with latest tag only and remember to mention the tag i.e fedora:latest, container should be named as volume-container-devops-1, and run a sleep command for it so that it remains in running state. Volume volume-share should be mounted at path /tmp/beta.

For the second container, use image fedora with the latest tag only and remember to mention the tag i.e fedora:latest, container should be named as volume-container-devops-2, and again run a sleep command for it so that it remains in running state. Volume volume-share should be mounted at path /tmp/cluster.

Volume name should be volume-share of type emptyDir.

After creating the pod, exec into the first container i.e volume-container-devops-1, and just for testing create a file beta.txt with any content under the mounted path of first container i.e /tmp/beta.

The file beta.txt should be present under the mounted path /tmp/cluster on the second container volume-container-devops-2 as well, since they are using a shared volume.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Pod YAML configuration

Create a file named volume-share-pod.yaml:

cat > volume-share-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-share-devops
spec:
  containers:
  - name: volume-container-devops-1
    image: fedora:latest
    command: ["/bin/sleep"]
    args: ["3650d"]
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/beta

  - name: volume-container-devops-2
    image: fedora:latest
    command: ["/bin/sleep"]
    args: ["3650d"]
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/cluster

  volumes:
  - name: volume-share
    emptyDir: {}
EOF

Step 2: Create the pod

Apply the configuration to create the pod:

kubectl apply -f volume-share-pod.yaml

Step 3: Verify the pod is running

Check if the pod is created and running:

kubectl get pods volume-share-devops

Step 4: Create test file in first container

Execute into the first container and create the test file:

kubectl exec -it volume-share-devops -c volume-container-devops-1 -- /bin/bash

Once inside the container, create the file:

echo "This is a test file for shared volume" > /tmp/beta/beta.txt

Exit the container:
exit

Step 5: Verify file exists in second container

Check if the file is accessible from the second container:

kubectl exec -it volume-share-devops -c volume-container-devops-2 -- cat /tmp/cluster/beta.txt

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

A Useful Resource If You’re Preparing for AWS, CompTIA, Microsoft Certifications

Thu Kha Kyawe — Sat, 04 Apr 2026 13:28:40 +0000

Udemy is now offering AWS, CompTIA and Microsoft exam vouchers with optional retake packages:

🔗 https://www.udemy.com/all-certification-vouchers/

I checked a couple of exams, and the pricing structure is actually more interesting than it first looks.

Example 1 — AWS Certified Solutions Architect (Associate)

Exam Voucher → $148.99
Exam Voucher + Retake → $181.99

👉 That’s roughly $33 more for a second attempt

Example 2 — AWS Certified DevOps Engineer (Professional)

Exam Voucher → $296.99
Exam Voucher + Retake → $329.99

👉 Again, about $33 more for a retake

My takeaway

This is where it gets interesting.

At first glance, Udemy shows a very large discount on the “voucher + retake” option (because it compares against a much higher original price).

But in reality, the decision is much simpler:

👉 You’re paying about $30–$35 extra for a second attempt

That’s actually not a bad deal if:

you’re not 100% confident yet
you want to reduce the risk of paying full price again
or you just want less pressure on exam day

Important details

From the voucher page:

Exam Voucher (one attempt)
→ valid for at least 9 months after purchase
Voucher + Retake (two attempts)
→ first attempt must be completed by Dec 31, 2026
→ retake must be completed by Jan 31, 2027
Works for:
- Associate exams
- Professional & Specialty exams
- Online or in-person testing

What to watch out for

This does not combine with other AWS benefits (e.g. 50% off vouchers)
It’s not the same as “free retake” promotions
Pricing may vary depending on your region / tax / currency

Final thought

This is one of those cases where the real value is hidden behind the marketing.

Ignore the big discount labels and just ask:

👉 “Is a second attempt worth ~$30 for me?”

If yes, the retake option actually makes a lot of sense.

AWS #AWSCertification #CloudComputing #DevOps #SolutionsArchitect #Certification #CareerGrowth #Upskilling #TechCareers

24.Application Security

Thu Kha Kyawe — Sun, 22 Mar 2026 19:30:00 +0000

Lab Information

We have a backup management application UI hosted on Nautilus's backup server in Stratos DC. That backup management application code is deployed under Apache on the backup server itself, and Nginx is running as a reverse proxy on the same server. Apache and Nginx ports are 8082 and 8092, respectively. We have to install the iptables firewall on the server. Make the appropriate changes to fulfill the requirements mentioned below:

We want to open all incoming connections to Nginx's port and block all incoming connections to Apache's port. Also make sure rules are permanent.

Lab Solutions

🧭 Part 1: Lab Step-by-Step Guidelines

1️⃣ Login to Backup Server

ssh clint@stbkp01
# Password: H@wk3y3
sudo -i

2️⃣ Install iptables

yum install -y iptables
yum install -y iptables-services

3️⃣ Check and Fix iptables

systemctl start iptables
systemctl enable iptables

4️⃣ Flush existing rules (clean start)

iptables -F

5️⃣ Allow Nginx port (8092)

iptables -A INPUT -p tcp --dport 8092 -j ACCEPT

6️⃣ Block Apache port (8082)

iptables -A INPUT -p tcp --dport 8082 -j DROP

7️⃣ Allow essential traffic (IMPORTANT)

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

8️⃣ Save rules (make permanent)

iptables-save > /etc/sysconfig/iptables
systemctl restart iptables

9️⃣ Verify rules

iptables -L -n

Output

[root@stbkp01 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8092
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8082
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)
What this lab is about

You are controlling:

Who can access which service
Current setup
Service Port Purpose
Apache 8082 backend
Nginx 8092 public access
What you need to do
Allow users → Nginx (8092)
Block users → Apache (8082)
Why block Apache?
Nginx acts as reverse proxy
Users should NOT access Apache directly
What iptables does
iptables = firewall tool
Controls network traffic
Rule explanation
1️⃣ Allow Nginx
iptables -A INPUT -p tcp --dport 8092 -j ACCEPT

👉 Means:

Allow incoming traffic on port 8092
2️⃣ Block Apache
iptables -A INPUT -p tcp --dport 8082 -j DROP

👉 Means:

Reject connections to Apache
3️⃣ Allow existing connections
ESTABLISHED,RELATED

👉 Prevents breaking active sessions

4️⃣ Allow loopback
lo (localhost)

👉 Required for internal communication

Final flow
User → Nginx (allowed) → Apache (internal only)
User → Apache (blocked ❌)
⚡ Key Concept
Firewall = control entry points to your system
🎯 Key Takeaway
Expose only what is needed, block everything else

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

23.Linux LogRotate

Thu Kha Kyawe — Sun, 22 Mar 2026 18:30:00 +0000

Lab Information

The Nautilus DevOps team is ready to launch a new application, which they will deploy on app servers in Stratos Datacenter. They are expecting significant traffic/usage of tomcat on app servers after that. This will generate massive logs, creating huge log files. To utilise the storage efficiently, they need to compress the log files and need to rotate old logs. Check the requirements shared below:

a. In all app servers install tomcat package.

b. Using logrotate configure tomcat logs rotation to monthly and keep only 3 rotated logs.

(If by default log rotation is set, then please update configuration as needed)

Lab Solutions

🧭 Part 1: Lab Step-by-Step Guidelines

1️⃣ Login to each app server

ssh tony@stapp01
# Password: Ir0nM@n

ssh steve@stapp02
# Password: Am3ric@

ssh banner@stapp03
# Password: BigGr33n

Then:

sudo -i

2️⃣ Install Tomcat and logrotate on ALL app servers

yum install -y tomcat
yum install -y logrotate

3️⃣ Verify Tomcat logs location

ls /var/log/tomcat

👉 Typical logs:

catalina.out
localhost.log

4️⃣ Configure logrotate for Tomcat

Create config file:

vi /etc/logrotate.d/tomcat

5️⃣ Add this configuration

/var/log/tomcat/*.log {
    monthly
    rotate 3
    compress
    missingok
    notifempty
    copytruncate
}

6️⃣ Save file

ESC
:wq

7️⃣ Test logrotate config (important)

logrotate -d /etc/logrotate.d/tomcat

👉 Output

WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

reading config file /etc/logrotate.d/tomcat
Reading state from file: /var/lib/logrotate/logrotate.status
error: error opening state file /var/lib/logrotate/logrotate.status: No such file or directory
Allocating hash table for state file, size 64 entries

Handling 1 logs

rotating pattern: /var/log/tomcat/*.log  monthly (3 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/tomcat/*.log
  log /var/log/tomcat/*.log does not exist -- skipping
Creating new state

8️⃣ Repeat on all app servers

Do same steps on:

stapp01
stapp02
stapp03

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)

What this lab is about

You are managing:

Large log files → need to control size and storage

Problem

Tomcat generates logs continuously:

More traffic → bigger log files → storage issues
Solution: logrotate
logrotate = tool to manage log files automatically

What your config does

1️⃣ monthly

Rotate logs once every month

2️⃣ rotate 3

Keep only 3 old log files

Example:

catalina.log
catalina.log.1
catalina.log.2
catalina.log.3
(old ones deleted)

3️⃣ compress

Old logs are compressed → save space

4️⃣ copytruncate

Copy log → clear original → service keeps writing

👉 Important because:

Tomcat is still running

5️⃣ missingok

Ignore if log file is missing

6️⃣ notifempty

Skip rotation if log is empty

Final flow

Logs grow → monthly rotation → old logs compressed → only 3 kept

⚡ Key Concept

Log rotation = prevent disk full issues

🎯 Key Takeaway

Production systems ALWAYS rotate logs to save storage

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

22.Linux GPG Encryption

Thu Kha Kyawe — Sun, 22 Mar 2026 16:00:00 +0000

Lab Information

We have confidential data that needs to be transferred to a remote location, so we need to encrypt that data.We also need to decrypt data we received from a remote location in order to understand its content.

On storage server in Stratos Datacenter we have private and public keys stored at /home/*_key.asc. Use these keys to perform the following actions.

Encrypt /home/encrypt_me.txt to /home/encrypted_me.asc.
Decrypt /home/decrypt_me.asc to /home/decrypted_me.txt. (Passphrase for decryption and encryption is kodekloud).
The user ID you can use is kodekloud@kodekloud.com.

Lab Solutions

🧭 Part 1: Lab Step-by-Step Guidelines

1️⃣ Login to Storage Server

ssh natasha@ststor01
# Password: Bl@kW
sudo -i

2️⃣ Import GPG keys

gpg --import /home/*_key.asc
# Password: kodekloud

3️⃣ Verify keys (optional but good practice)

gpg --list-keys
sudo chmod 777 /home

👉 You should see:

kodekloud@kodekloud.com

4️⃣ Encrypt the file

gpg --output /home/encrypted_me.asc \
    --encrypt \
    --recipient kodekloud@kodekloud.com \
    /home/encrypt_me.txt

👉 Enter passphrase when asked:

kodekloud

5️⃣ Decrypt the file

gpg --output /home/decrypted_me.txt \
    --decrypt /home/decrypt_me.asc

👉 Enter passphrase:

kodekloud

6️⃣ Verify output

cat /home/decrypted_me.txt

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)

What this lab is about

You are working with:

Encryption → hide data
Decryption → read data

Step 1: Import keys

gpg --import

👉 This loads:

Public key → used to encrypt
Private key → used to decrypt

Step 2: Encryption

gpg --encrypt

👉 What happens:

Plain file → converted into unreadable encrypted file

Only the person with the private key can open it.

Step 3: Decryption

gpg --decrypt

👉 What happens:

Encrypted file → converted back to readable content
Why passphrase is needed
Passphrase = protects the private key

Even if someone has the key file, they still need:

kodekloud
How keys work (simple idea)
Public key → lock 🔒
Private key → unlock 🔑

Final flow
encrypt_me.txt → encrypted_me.asc → (secure transfer)
decrypt_me.asc → decrypted_me.txt → readable

⚡ Key Takeaway
Encryption protects data during transfer
Decryption allows authorized access

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

21.Apache Troubleshooting

Thu Kha Kyawe — Sun, 22 Mar 2026 15:30:00 +0000

Lab Information

xFusionCorp Industries uses some monitoring tools to check the status of every service, application, etc running on the systems. Recently, the monitoring system identified that Apache service is not running on some of the Nautilus Application Servers in Stratos Datacenter.

Identify the faulty Nautilus Application Server and fix the issue. Also, make sure Apache service is up and running on all Nautilus Application Servers. Do not try to stop any kind of firewall that is already running.
Apache is running on 5004 port on all Nautilus Application Servers and its document root must be /var/www/html on all app servers.
Finally you can test from jump host using curl command to access Apache on all app servers and it should be reachable and you should get some static page. E.g. curl http://stapp01:5004/.

Lab Solutions

🧭 Part 1: Lab Step-by-Step Guidelines

1️⃣ Login to jump host

ssh thor@jump_host
# Password: mjolnir123

2️⃣ Identify faulty app server

Test all servers:

curl http://stapp01:5004/
curl http://stapp02:5004/
curl http://stapp03:5004/

3️⃣ Login to faulty server

Example:

ssh tony@stapp01
# Password : Ir0nM@n
sudo -i

(Use correct user for each server)

4️⃣ Check Apache status

systemctl status httpd

5️⃣ Fix Apache issues

✅ Set correct port (5004)

vi /etc/httpd/conf/httpd.conf

Check:

Listen 5004

✅ Start and enable Apache

systemctl restart httpd
systemctl enable httpd
systemctl status httpd

6️⃣ Verify locally on that server

curl http://stapp01:5004/

7️⃣ Repeat check on all app servers

ssh steve@stapp02
# Password : Am3ric@
sudo -i
sudo systemctl status httpd
sudo systemctl restart httpd
journalctl -xeu httpd.service
# Change ServerRoot "/etc/httpd"
vi /etc/httpd/conf/httpd.conf
systemctl restart httpd
systemctl enable httpd
systemctl status httpd
curl http://stapp02:5004/

ssh banner@stapp03
# Password: BigGr33n
sudo -i
sudo systemctl status httpd
sudo systemctl restart httpd
journalctl -xeu httpd.service
# Uncomment Listen 5004 and  Add " " at DocumentRoot "/var/www/html"
vi /etc/httpd/conf/httpd.conf
systemctl restart httpd
systemctl enable httpd
systemctl status httpd
curl http://stapp03:5004/

👉 All must be running

👉 All should return a webpage

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)

What this lab is about

You are fixing a real production issue:

Some servers are working, some are broken → find and fix them

Step 1: Find which server is broken
curl http://stapp01:5004/
curl http://stapp02:5004/
curl http://stapp03:5004/

👉 This is like checking:

“Which machine is not responding?”
If it shows a page → ✅ working
If it fails → ❌ faulty server

Step 2: Check Apache service

systemctl status httpd

👉 This tells you:

Is Apache running or stopped?

Step 3: Fix configuration issues

You checked logs:

journalctl -xeu httpd.service

👉 Logs tell you:

Why Apache failed
Common problems you fixed

🔴 Problem 1: Wrong ServerRoot

ServerRoot /var/www/html ❌

👉 This is wrong because:

ServerRoot = where Apache system files are stored

Correct:

ServerRoot "/etc/httpd" ✅

🔴 Problem 2: Port not configured

Listen 5004

👉 Apache must listen on the correct port, otherwise:

curl http://server:5004 → will fail

🔴 Problem 3: DocumentRoot formatting

DocumentRoot /var/www/html ❌

Correct:

DocumentRoot "/var/www/html" ✅

👉 Quotes are important in Apache config.

Step 4: Restart Apache

systemctl restart httpd

👉 Applies your fixes.

Step 5: Verify again

curl http://stapp02:5004/

👉 Now it should work.

Step 6: Repeat for all servers

Each server can have different issues:

Server Issue
stapp01 may be OK
stapp02 ServerRoot broken
stapp03 Listen/DocumentRoot issue

👉 So you fix each one individually

🔁 Final Flow (Very Important)

Test → Find broken server → Check service → Check logs → Fix config → Restart → Test again

⚡ Key Concepts You Learned

1️⃣ Services depend on config

Wrong config → service won’t start

2️⃣ Logs are your best friend

journalctl -xeu httpd.service

👉 Always tells the real problem

3️⃣ Apache has strict syntax

Small mistake → full service failure

4️⃣ Ports must match requirement

Apache must listen on 5004

✅ Final Result
All app servers:
✔ Apache running
✔ Port 5004 working
✔ curl returns webpage