Forem: Saravanan Gnanaguru

How to Avoid Vulnerabilities in AI-Generated JavaScript and Node.js Projects

Saravanan Gnanaguru — Wed, 08 Apr 2026 07:48:15 +0000

Why Your AI Coding Workflow Needs Strict Node.js Rules to Avoid Vulnerabilities

Introduction
The real issue: AI defaults to the average of the internet
Why this matters more in Node.js than many teams realize
Why strict rules are necessary
What strict rules should cover in a Node.js project
- Runtime version
- Module system
- TypeScript expectations
- Built-in APIs first
- Testing rules
- Dependency policy
- Security expectations
The meeting app example: where this matters in the real world
What to do in practice
A sample “rules-first” prompt for modern Node.js development
Example custom instructions for ChatGPT or Claude
Example .cursorrules file
The bigger lesson
Closing thought

Introduction

AI code generation tools can speed up development significantly.

But there is a practical problem many teams quietly run into:

AI often generates JavaScript and Node.js code based on older patterns, outdated packages, and legacy ecosystem assumptions.

That becomes risky very quickly.

You ask for a backend service, and the generated code may:

use older CommonJS patterns even when your project is ESM-first
suggest outdated libraries that are no longer actively maintained
pull in packages with weak security posture or unnecessary transitive dependencies
generate examples that work “in general” but do not fit your runtime, version policy, or production standards

For teams building modern applications, especially with AI-assisted development, this is no longer a small inconvenience. It is a security, maintainability, and architecture discipline problem.

This is exactly why teams need strict rules for their Node.js and JavaScript stack.

The real issue: AI defaults to the average of the internet

Large language models are trained on enormous amounts of public code, documentation, tutorials, blog posts, forums, and repositories.

That means they do not naturally prefer:

the newest stable Node.js patterns
the safest library choices
your organization’s runtime constraints
your internal engineering standards

They often prefer what is most statistically common across historical code.

And the JavaScript ecosystem has a lot of history.

That history includes:

deprecated libraries
abandoned packages
insecure examples copied across blogs and repos
older syntax patterns
outdated testing stacks
over-dependence on third-party packages for things now supported natively in Node.js

So unless you explicitly guide the model, AI will often produce code that is technically plausible but operationally dated.

That is where risk begins.

Why this matters more in Node.js than many teams realize

Node.js moves fast, and the npm ecosystem moves even faster.

That creates a unique problem:

a package that looked fine two years ago may now be unmaintained
an older library may still “work” but carry security debt
one dependency can bring dozens or hundreds of transitive packages
many vulnerabilities enter not through your direct code, but through your dependency tree

When AI suggests a package casually, it is not just suggesting one library.

It may be suggesting:

a package with outdated maintainers
weak release hygiene
known advisories
legacy subdependencies
unnecessary attack surface

In other words, bad defaults in JavaScript are expensive.

This is why modern Node.js development needs a rules-first mindset, especially when AI is part of the workflow.

The vulnerability problem is not only “bad packages”

When people think about security, they usually focus only on npm audit.

That matters, but the problem is broader.

Weak AI-generated Node.js code can create risk in at least five ways.

1. Outdated or deprecated dependencies

AI may recommend older packages simply because they were widely used historically.

Examples of ecosystem patterns teams should be careful about:

old HTTP clients when native fetch is available
date libraries that are heavy or in maintenance mode
legacy request or callback-style packages
test libraries or middleware stacks that are no longer the cleanest option

2. Excessive dependency usage

A surprising amount of generated code imports third-party packages for things modern Node.js can already do well:

HTTP requests
file handling
UUID generation
testing
path operations
streams
crypto utilities

Every unnecessary package increases supply-chain exposure.

3. Legacy syntax and module patterns

Older patterns are not just stylistic debt. They often signal broader ecosystem mismatch.

Examples:

require() in projects that should be ESM-first
inconsistent module boundaries
weak TypeScript typing
callback-heavy flows instead of promise-based APIs

These increase the chance of brittle code, patchy upgrades, and inconsistent runtime behavior.

4. Version ambiguity

If your prompts do not define the runtime, the AI fills in the blanks.

That means code may assume:

an older Node version
incompatible package behavior
missing runtime features
polyfills you do not actually need

This creates hidden instability from the start.

5. Weak testing and validation assumptions

AI-generated code often looks complete before it is actually trustworthy.

Without strict validation rules, teams may accept:

untested business logic
poor error handling
weak input validation
naive file operations
poor auth/session assumptions
unsafe meeting or scheduling logic in real applications

So the problem is not just “AI suggested an old package.”

The real issue is:

Without rules, AI introduces inconsistency into architecture, runtime compatibility, dependency hygiene, and security posture.

Why strict rules are necessary

Strict rules are not about making AI less useful.

They are about making AI output safe enough to be useful in a real codebase.

A rules-driven setup gives the model boundaries such as:

which Node.js version to target
whether the project is ESM-only
whether external libraries should be minimized
what testing framework is allowed
what dependency policy should be followed
which coding standards are mandatory
which types of packages are forbidden

This changes AI from “internet autocomplete” into a more controlled engineering assistant.

That is the shift teams need.

What strict rules should cover in a Node.js project

For AI-assisted Node.js development, your rules should define at least these areas.

Runtime version

Tell the AI exactly what version family you support.

Example:

Node.js 24.x
only modern runtime APIs
no assumptions for Node 16 or earlier

This reduces outdated examples and avoids compatibility drift.

Module system

Be explicit:

use ES Modules
use import/export
no CommonJS unless required for a legacy boundary

This helps keep the generated code aligned with a modern project structure.

TypeScript expectations

Require:

TypeScript v5+
strict typing
no any unless justified
explicit return types for core services where helpful

This improves maintainability and catches errors earlier.

Built-in APIs first

Set a policy that native Node.js APIs should be preferred whenever practical.

Examples:

native fetch
node:fs/promises
node:test
node:path
node:crypto

This directly reduces dependency sprawl.

Testing rules

Tell the model what test stack is allowed.

For lean modern services, this could be:

node:test
node:assert
no Jest or Vitest unless the project explicitly uses them

That gives you smaller dependency trees and more predictable tooling.

Dependency policy

Define what the AI should avoid:

deprecated packages
maintenance-mode libraries
libraries with no recent activity unless intentionally chosen
packages that duplicate built-in runtime features

This is one of the most important controls.

Security expectations

Require generated code to include:

input validation
safe file handling
explicit error handling
least-privilege assumptions
no hardcoded secrets
environment-based configuration
audit-friendly structure

This is especially important for apps used by institutions, academies, internal teams, or customer-facing workflows.

The meeting app example: where this matters in the real world

Take a modern meeting and class scheduling application for academies.

At first glance, this sounds like a straightforward SaaS-style app:

schedule classes
assign teachers
track attendance
manage recurring sessions
maintain basic reporting

But once you move from idea to implementation, the risk surface grows fast.

Such an app may involve:

student records
teacher data
class timings
attendance history
meeting links
notifications
scheduling workflows
recurrence logic
role-based access
audit trails

If AI generates this application using weak defaults, you may end up with:

outdated scheduling libraries
poorly validated date logic
overuse of third-party packages
fragile recurrence calculations
excessive dependencies for simple backend operations
weak testing around attendance and scheduling logic
inconsistent module structure across the project

That is how “small” technical shortcuts become long-term security and reliability debt.

For educational systems, that is not acceptable.

This is why strict Node.js rules are not only a style preference. They are part of building dependable software with AI assistance.

What to do in practice

Here are the most effective ways to keep AI-generated Node.js code aligned with modern and safer standards.

1. Put version constraints in the project itself

Your repository should clearly declare the runtime.

In package.json:

{
  "engines": {
    "node": ">=24.0.0"
  }
}

In .nvmrc:

24.0.0

These files are not only for developers. AI tools often read them too.

2. Use permanent instructions for your AI tools

Do not repeat runtime and standards manually in every prompt if you can avoid it.

Use:

ChatGPT custom instructions
Claude project instructions
Cursor rules
Copilot instructions in the repo

A good instruction set should clearly state:

target runtime
module format
dependency policy
testing rules
language version
security expectations

3. Start prompts with the environment, not the feature

A weak prompt:

Build an API for scheduling academy classes.

A stronger prompt:

Target Node.js 24 with TypeScript v5+, strict mode, ESM, top-level await, and the built-in Node test runner. Build an academy class scheduling API with recurring sessions, attendance tracking, and teacher assignment.

This changes the quality of generated output immediately.

4. Explicitly ban legacy patterns

It helps to say what should not be used.

Examples:

do not use require()
do not use deprecated or maintenance-mode packages
do not use Jest unless already part of the project
prefer native APIs over third-party libraries
avoid unnecessary dependencies

AI follows negative constraints surprisingly well when they are concrete.

5. Audit generated dependencies immediately

Even with good prompting, never assume the generated dependency choices are safe.

Review:

package freshness
maintenance status
transitive dependency count
known advisories
whether the package is even needed

Then run:

npm audit
dependency review tools
renovate or dependency update automation
internal package approval checks if you have them

AI output should be treated as a draft, not as trusted supply-chain input.

6. Keep architecture and dependency decisions separate

A common mistake is asking AI to generate both architecture and package choices in one go.

A better approach:

define the runtime and rules
ask the AI to propose options
review package choices
select one deliberately
then generate implementation code

This reduces accidental adoption of weak libraries.

A sample “rules-first” prompt for modern Node.js development

Here is a more disciplined prompt pattern for code generation:

Target environment:
- Node.js v24+
- TypeScript v5+ with strict mode
- ESNext / ESM only
- Use top-level await where suitable
- Use native Node.js APIs first
- Use the Node.js built-in test runner (node:test)
- Avoid deprecated, maintenance-mode, or unnecessary packages
- Do not use CommonJS require()

Build a backend module for an academy class scheduling application.

Requirements:
- Manage classes, teachers, students, and recurring schedules
- Track attendance per session
- Validate inputs carefully
- Use native fetch and node:fs/promises where needed
- Keep dependencies minimal
- Include unit tests using node:test
- Structure code for maintainability and auditability

This kind of prompt gives the model enough guardrails to produce far better output.

Example custom instructions for ChatGPT or Claude

Node.js Development Standards

- Target modern Node.js runtime only.
- Use TypeScript v5+ with strict typing.
- Always use ES Modules (import/export), never CommonJS unless explicitly requested.
- Prefer built-in Node.js APIs over third-party libraries.
- Avoid deprecated, abandoned, or maintenance-mode packages.
- Minimize dependencies and avoid adding packages for functionality available natively in Node.js.
- Use explicit error handling and input validation.
- Never hardcode secrets or credentials.
- Use node:test and node:assert for tests unless the project already uses a different approved testing framework.
- Generate code that is production-aware, maintainable, and compatible with modern Node.js standards.

Example `.cursorrules` file

# Node.js / TypeScript Project Rules

- Runtime: Modern Node.js only
- Language: TypeScript v5+ with strict mode
- Modules: ESM only (`import` / `export`)
- Style: Prefer modern ESNext features
- Use top-level await only in appropriate entry points
- Prefer built-in Node.js APIs over external packages
- Avoid deprecated or weakly maintained libraries
- Keep dependency count low
- Tests must use `node:test` and `node:assert` unless told otherwise
- No CommonJS unless explicitly required for legacy integration
- All generated code must include reasonable validation and error handling
- Prioritize security, maintainability, and low attack surface

The bigger lesson

AI-assisted development does not reduce the need for engineering discipline.

It increases it.

Because once AI becomes part of the coding workflow, bad defaults can spread much faster:

across files
across services
across teams
across repositories
across dependency decisions

That is why teams should treat AI tooling the same way they treat CI/CD pipelines, security gates, and infrastructure guardrails.

Not as magic.

As a system that needs constraints.

For Node.js and JavaScript in particular, those constraints matter because the ecosystem is powerful, fast-moving, and historically noisy.

Without strict rules, AI can easily drag a modern codebase toward legacy patterns and unnecessary security exposure.

With strict rules, it becomes much more useful:

cleaner output
fewer outdated libraries
better alignment to runtime
smaller dependency trees
lower supply-chain risk
more maintainable architecture

That is the real goal.

Not just generating code faster.

But generating code that is safer to keep.

Closing thought

If you are using AI to generate Node.js or JavaScript code, do not only ask:

“Does this code work?”

Also ask:

“Does this code match our runtime, dependency policy, security expectations, and long-term maintainability standards?”

Because in modern software delivery, especially with AI in the loop, speed without guardrails becomes technical debt very quickly.

And in the JavaScript ecosystem, that debt often arrives through dependencies first.

If you are building AI-assisted apps and want to make them more secure and maintainable, feel free to connect with me on LinkedIn or explore my work here: https://gsaravanan.dev

Run Your Own GenAI LLMs Offline with LM Studio

Saravanan Gnanaguru — Wed, 13 Aug 2025 03:57:13 +0000

LM Studio — The Best Tool for Privacy-First GenAI Enthusiasts

In the world of Generative AI, access to powerful large language models (LLMs) has never been more important — but it’s also become increasingly dependent on internet connectivity and third-party platforms. For developers, researchers, and privacy-first organizations, this dependency can be a major limitation — not to mention a potential security or compliance risk.

That’s where LM Studio comes in. If you're a GenAI enthusiast, then LM Studio is your go-to tool for running open-source LLMs and SLMs locally, with full control over your data, models, and workflows.

This post explores why running LLMs locally is becoming the new standard, what makes LM Studio stand out, and how it compares to other tools like Ollama and vLLM.

We’ll also highlight why offline use is a game-changer for privacy-first organizations — and how you can take full advantage of it with LM Studio.

Whether you're a prompt engineer, a researcher, or part of an organization that values data autonomy, this guide will help you understand the power of running your own LLMs without internet, and how LM Studio makes it easier than ever.

Why This is Important ?

If you're running a privacy-first organization, offline LLM use is not just an option — it's a necessity.
If you're a GenAI nerd, LM Studio gives you the freedom to experiment, customize, and run models without relying on external services.
If you're a developer or researcher, knowing how to run LLMs locally can save you time, money, and data privacy concerns. This is the future of GenAI — local, fast, and secure. And with tools like LM Studio, it's more accessible than ever.

🚀 If You're Passionate About Running Open Source GenAI LLM Models in Your Workstation — This Post Is For You

If you're a GenAI nerd, then this is going to be your new go-to tool for offline LLM usage — and it’s not just about running models. It's about freedom, control, and the ability to run your favorite open-source models without ever relying on an internet connection.

This post will dive deep into how to use LM Studio — the best GUI-based tool for running open-source large language models (LLMs) and small-language models (SLMs) locally on your own hardware. We’ll also touch on other tools and models you can run offline, so you have a full control of what's possible with your local run models.

Why Run LLMs Locally?

There are a few key reasons why running large language models locally is becoming the new standard for many GenAI enthusiasts and developers:

✅ Privacy & Control: Your data stays local — no third-party tracking.
✅ Offline Use: Work without an internet connection. Ideal for coding, research, and brainstorming.
✅ Customization: Fine-tune models, tweak prompts, and experiment with model behavior.
✅ Cost Efficiency: No need for expensive cloud credits or API calls.

And if you're a GenAI nerd or development team, then the ability to run models like Qwen, LLaMA, Phi-3, Mistral, and even newer ones like LLaMA-3 — all offline — is a dream come true.

LM Studio: The Best GUI for Offline LLM Use

LM Studio, developed by @yugil burowski, is the most user-friendly tool for running open-source LLMs and SLMs locally. It's designed with GenAI enthusiasts in mind — it’s fast, lightweight, and packed with features that make local model running simple and powerful.

✅ Features of LM Studio

🖥️ GUI-based interface: No need to type commands or write scripts.
💻 Runs on your local machine: Perfect for offline use, even with internet turned off.
🧠 Supports multiple model formats: GGUF, GPTQ, and more.
📌 Customizable prompts and templates: Tailor the model’s behavior to your needs.
📦 Easy model loading and management: Just download the model, click "Load," and start using it.

LM Studio Best For,

GenAI enthusiasts who want to experiment with model behavior.
Prompt engineers looking for full customization.
Researchers and developers who need offline access to models.

Privacy First Organizations: Why Offline GenAI Use Matters

For organizations that prioritize data privacy, offline use is a game-changer. With LM Studio, you can run your LLMs without ever sending data over the internet, making it ideal for:

Financial institutions
Healthcare providers
Government agencies
Any organization that needs strict data control

You can run your models on-premise, ensuring compliance with regulations like GDPR or HIPAA.

LM Studio vs Ollama, vLLM & Other Tools

Below is a list of the top tools available today that let you run open-source LLMs and SLMs on your own hardware — including LM Studio, Ollama, vLLM, and more.

Feature	LM Studio	Ollama	vLLM	LLaMA-CPP
Type	GUI-based	CLI-only	Python library	CLI/Python
Local Use?	✅	✅	✅	✅
Offline Support?	✅	✅	✅	✅
Model Formats	GGUF, GPTQ	GGUF, Q4	GGUF, GPTQ	GGUF, MMap
Best For	GenAI enthusiasts, prompt engineers	Developers, API users	Researchers, production environments	Developers, low-latency use
Ease of Use	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
Can be accessed via API?	✅ (LM Studio API)	✅	❌	❌

Note: LM Studio can also be accessed via the LM Studio API, making it a flexible choice for both local and integrated workflows.

Final Thoughts

If you're a GenAI nerd, then LM Studio is your best bet — it’s the most user-friendly and ideal for experimentation. It gives you full control over your models, allows offline use, and lets you customize the way they behave — all without needing to write a single line of code.

But if you're more into development or research, then tools like Ollama or vLLM might be more suitable for your needs.

What’s Next?

I’d love to hear from you — have you tried LM Studio yet?

✅ Is it your go-to tool for offline LLM use?
🤔 Are you running any other models locally besides LLaMA or Phi-3?
🧠 What features would you like to see in a local LLM runner?

Let me know in the comments — I'm always happy to help and explore more together.

Want a step-by-step guide on how to set up LM Studio or run your first model offline? Let me know!

🔗 LM Studio Documentation — Check out the API and model loading details!

Follow me on,

Git Guide to Delete Old Commits and Clear Sensitive Info from Git History

Saravanan Gnanaguru — Sat, 26 Jul 2025 20:32:08 +0000

How To: Delete Old Git Commits and Clear Sensitive Files from History

Introduction

Everyone works with GenAI apps (like ChatGPT, Gemini and Claude) and often forgets to delete the secret while pushing the code to Git/GitHub/BitBucket etc.

Accidentally committing sensitive information (like passwords, API keys, or certificates) to a Git repository is a common mistake.

Removing these sensitive files from your repository's history is critical to protect your project and users.

This guide provides step-by-step instructions for three common approaches to erase old commits and clear unwanted files, with a recommendation for the most robust solution.

GitHub has added the feature by NOT allowing the files to get pushed - but the user also has an option to force push with secret - which poses the security threat.

So take care while working with API keys in your code. Best practice is to use ENV variables and storing key as HASH string is always recommended.

Why Is This Important?

Even if you delete a sensitive file and commit the changes, the sensitive data remains in the repository's history and can be recovered. To fully remove this information, you must rewrite your Git history.

Approach 1: Start Fresh — Remove All History

This method removes all commit history, leaving only your current files as a new initial commit.

Steps:

Backup your repository!

Delete the Git history:

rm -rf .git
git init
git add .
git commit -m "Initial commit"

(Optional) Rename your branch:
```
git branch -M main
```

Add your remote and force-push:

git remote add origin <remote-url>
git push -f origin main

Pros:

Simple and effective.

Cons:

Loses all commit history.
Disruptive for collaborators.

Approach 2: Remove Specific Files — With git-filter-repo

If you need to delete specific files (like .env, secrets.txt) from every commit, use git-filter-repo.

Steps:

Install git-filter-repo (if not already):
```
pip install git-filter-repo
```

Remove sensitive files from history:

git filter-repo --path <path-to-sensitive-file> --invert-paths

Example for multiple files:

git filter-repo --path secret.env --path private.pem --invert-paths

Force-push changes:
```
git push -f origin main
```

Pros:

Precise: removes only targeted files.
Preserves useful history for all other files.

Cons:

Still rewrites history (force-push required).
All collaborators must re-clone or reset local branches.

Approach 3: Squash All Commits Into One

This approach creates a single new commit with only your current files, erasing all previous history (including sensitive data) but preserving your current project state.

Steps:

Create a new orphan branch (no history):
```
git checkout --orphan latest_branch
```

Stage and commit all files:

git add -A
git commit -m "Initial commit with all current files"

Delete the old branch and rename the new one:
```
git branch -D main
git branch -m main
```
Force-push to your remote:
```
git push -f origin main
```

Pros:

Completely erases old history, including all sensitive files or data.
Leaves you with a clean slate and current state.

Cons:

All previous commit history is lost.
Requires force-push; all collaborators must re-clone.

Recommendation: Use Approach 3 (Squash All Commits Into One)

While all three approaches can remove sensitive data, squashing all commits is often the best choice for these reasons:

It guarantees that all traces of sensitive information are erased.
Leaves your repository clean and easy to maintain.
Is simple to execute, with minimal risk of missing hidden copies of sensitive files.

Important:

After rewriting history, you must force-push (git push -f). All collaborators must re-clone or reset their local repositories to avoid conflicts.

I personally tried approach 3 to clear the git history.

Final Steps

Invalidate Old Credentials: If you committed passwords or keys, assume they are compromised. Change them immediately.
Add Sensitive Files to .gitignore: Prevent accidental future commits.
Notify Collaborators: Let everyone know to re-clone the repository.
Check Remotes: Ensure you are pushing to the correct repository and branch.

Useful Resources

Remember: Always review your changes and ensure sensitive files are excluded from future commits!

My new blog on Docker and Kubernetes deployment in UpCloud

Saravanan Gnanaguru — Tue, 22 Apr 2025 03:03:49 +0000

Saravanan Gnanaguru for UpCloud

Apr 21 '25

How Kubernetes Automates and Manages Your Docker Containers

Comments

5 min read

How Kubernetes Automates and Manages Your Docker Containers

Saravanan Gnanaguru — Mon, 21 Apr 2025 13:06:10 +0000

Blog Description: Learn how we can use Kubernetes to automate the deployment, scaling, and management of Docker containers. Discover how it simplifies container orchestration and enhances application reliability.

Introduction

In today’s microservices-driven world, Docker revolutionized how we build and package applications. But managing containers at scale? That’s where Kubernetes steps in. Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications — especially those created with Docker.

As part creating the Demo I've used UpCloud - A Leading European Cloud Provider.

Why UpCloud Good for Containers and Kubernetes?

UpCloud is a high-performance cloud provider known for:

⚡ Ultra-fast MaxIOPS storage
🌍 Global data centers
🧩 Easy Kubernetes-ready infrastructure (via manual setup or Terraform)
💰 Cost-effective pricing for scalable clusters

Whether you're starting locally with Minikube or going full-scale with K8s on cloud VMs, UpCloud gives you the flexibility and performance edge.

What is Docker?

Docker is a tool that packages your code, libraries, and dependencies into a container—an isolated, lightweight executable. Containers solve the “it works on my machine” problem, ensuring consistent environments across dev, test, and production.
But what happens when you have hundreds or thousands of these containers?

What Is Kubernetes?

Kubernetes (aka K8s) is an open-source container orchestration engine developed by Google. It manages clusters of Docker containers, offering automation, monitoring, and self-healing capabilities out of the box.

How Kubernetes helps to Orchestrate Docker Containers

Let’s break down the Orchestration functionality of Kubernetes brings:

1. Automated Deployment and Rollbacks

Define your desired container state in YAML files.
Kubernetes ensures the cluster matches this state.
Supports rolling updates and easy rollbacks if something goes wrong.

2. Self-Healing Mechanisms

Failed containers? Kubernetes replaces them automatically.
Restarts containers if they crash.
Removes non-responsive containers from the network.

3. Load Balancing and Service Discovery

Automatically distributes network traffic across containers.
Built-in DNS service allows containers to find each other by name.

4. Horizontal Scaling

Scale container instances up/down based on CPU/memory usage.
Manual or automatic scaling using the Horizontal Pod Autoscaler.

5. Resource Optimization

Efficient bin-packing ensures optimal use of compute resources.
Limits and requests help avoid resource hogging.

Core Components of Kubernetes

Category	Component	Definition
Control Plane	kube-apiserver	Handles all REST requests and serves as the front-end of the Kubernetes control plane.
	etcd	Stores all Kubernetes cluster data in a distributed, consistent key-value store.
	kube-scheduler	Assigns pods to nodes based on defined scheduling rules and resource availability.
	kube-controller-manager	Runs controllers to monitor and maintain the desired cluster state.
	cloud-controller-manager	Manages cloud-specific control loops like load balancers, volumes, and node management.
Node Components	kubelet	Ensures that containers in pods are running as defined in their PodSpecs.
	kube-proxy	Maintains network rules for pod-to-pod and pod-to-service communication.
	Container Runtime	Executes and manages containers on the node (e.g., containerd, CRI-O).
Workload Object	Pod	The smallest deployable unit that can run a container or set of containers in Kubernetes.
Networking Object	Service	Exposes a stable network endpoint for accessing a group of pods.
Cluster Resource	Cluster	A set of nodes and control plane components that together run containerized workloads.

Real-World Example of Kubernetes Implementation

Imagine you have a web app built with Node.js in a Docker container:

You define a Deployment that runs 3 replicas.
Kubernetes ensures 3 instances are always running.
If one crashes, it spins up a new one instantly.
A Service ensures traffic is routed to available instances.
Want to scale to 10 instances? Just change the replica count.

Demo of Deploying a Docker image in Kubernetes

We will see the step by step approach to deploy an application Docker image in kubernetes using minikube

Create a Server in UpCloud

System Requirement for Minikube is 2 Core CPU, so we have created an UpCloud server with 2 Core CPU and 4 GB RAM in Singapore Region.

👉 Start with UpCloud and deploy your next app with confidence.

You can also get started with UpCloud by following the documentation here

Logged into UpCloud server and proceeded the further steps

Steps to Deploy Application in Kubernetes

Step 1: Install Minikube and Dependencies

1.1 Install Docker (Required for Minikube)

Please Follow Docker Installation Steps in official documentation to install Docker.

Docker Official Documentation

1.2 Install Kubectl (Kubernetes CLI)

Please Follow Installation Steps to install Kubectl here - Official Installation Docs

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/
kubectl version --client

1.3 Install Minikube

Please Follow Installation Steps to install Minikube here - Installation Docs

List of commands to install Minikube

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
chmod +x minikube
sudo mv minikube /usr/local/bin/
minikube version

Step 2: Start Minikube Cluster

minikube start --driver=docker 
# or
minikube start --driver=docker --force

Step 3: Deploy a Simple Application

3.1 Create a Deployment

kubectl create deployment my-app --image=nginx

3.2 Expose the Deployment

kubectl expose deployment my-app --type=NodePort --port=80

3.3 Get Service Details

kubectl get svc my-app

3.4 Access the Application

minikube service my-app --url

Step 4: Scale the Application

kubectl scale deployment my-app --replicas=3
kubectl get pods -o wide

Step 5: Clean Up Resources

kubectl delete svc my-app
kubectl delete deployment my-app
minikube stop
minikube delete

(Alternative Method) Using `deployment.yaml` File

Create a deployment.yaml file, which deploys a nginx server and creates a service for access it.

Here’s a simple Kubernetes deployment.yaml file that deploys an nginx container and exposes it using a NodePort service.

We are deploying the yaml in minikube cluster, to access the service via your browser using minikube.

📄 `nginx-deployment.yaml`

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

🧪 Steps to Deploy and Access NGINX

Apply the YAML file:

kubectl apply -f nginx-deployment.yaml

Check pod and service status:

kubectl get pods
kubectl get svc nginx-service

Access NGINX in browser (if using Minikube):

minikube service nginx-service --url

This will return a URL like: http://192.168.49.2:30080 — open this in your browser.

Conclusion

As part of this blog, you have learnt the following aspects,

What is Docker and Kubernetes
Basics understanding of various components of Kubernetes and it's advantages
how to deploy Docker image using Kubernetes using kubectl in-line command and Kubernetes yaml deployment.

In the next blog - we will see how to scale the application and we will get into internals of application scaling in Kubernetes.

Call to Action

Ready to scale your Docker containers with ease? Dive deeper into Kubernetes, or start building your own K8s-powered apps today!

Shout out to UpCloud for their developer-friendly cloud platform.

If you're trying out Kubernetes or deploying applications for testing or learning — check out UpCloud Developer Plans.

Use the personalized promo code cloudenginelabs to get $50 in free credits with an extended 30-day trial period.

👉 Start with UpCloud and deploy your next app with confidence.

You can also get started with UpCloud by following the documentation here

GitHub Actions Self-Hosted Runner Setup Guide for Ubuntu

Saravanan Gnanaguru — Wed, 23 Oct 2024 15:21:41 +0000

Introduction to GitHub Actions Workflow Basics and Runners

GitHub Actions Workflow Basics

GitHub Actions is a powerful automation platform that allows you to create custom workflows for your software development lifecycle. Workflows are defined using YAML files and can be triggered by various events such as pushes, pull requests, or scheduled times.

A basic GitHub Actions workflow consists of:

Events: Triggers that start the workflow (e.g., push, pull_request).
Jobs: A series of steps that execute on the same runner.
Steps: Individual tasks within a job, which can run commands or use pre-built actions.

Example workflow file (.github/workflows/ci.yml):

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run build
        run: make build

Runners

Runners are the machines that execute the jobs in your workflows. GitHub provides hosted runners with different operating systems, but you can also use self-hosted runners.

GitHub-Hosted Runners: Managed by GitHub, these runners come pre-configured with a wide range of tools and software.
Self-Hosted Runners: Custom machines that you manage yourself. These can be on-premise servers, physical machines, virtual machines, or cloud instances.

Need for Self-Hosted Runners

While GitHub-hosted runners are convenient, there are scenarios where self-hosted runners are beneficial:

Custom Environments: You need specific software, configurations, or hardware that GitHub-hosted runners do not provide.
Performance: You require more powerful hardware or specific hardware configurations.
Cost: You want to reduce costs by using your own infrastructure.
Security: You need to run workflows in a more controlled and secure environment.

Self-hosted runners give you more control over the environment in which your workflows run, allowing you to tailor the setup to your specific needs.

In this How-to Guide we will explore, how to set up a GitHub Actions self-hosted runner on an Ubuntu instance.

Prerequisites

A GitHub repository where you want to add the self-hosted runner.
A GitHub Personal Access Token (PAT) with repo scope.
An Ubuntu system (can be an EC2 instance on AWS or any other Ubuntu machine) - e.g., Ubuntu Server 22.04 LTS or 24.04 LTS
Administrative privileges on the Ubuntu system.

Steps to Create a Personal Access Token (PAT) from Developer Settings

To create a Personal Access Token (PAT) for GitHub, follow these steps:

Step 1: Navigate to Developer Settings

Log in to your GitHub account.
In the upper-right corner of any page, click your profile photo, then click Settings.
In the left sidebar, click Developer settings.

Step 2: Generate a New Token

In the left sidebar, click Personal access tokens > Token Classic .
Click Generate new token .

Step 3: Configure the Token

Note: If you are prompted to confirm your password, enter your GitHub password.
Note: Give your token a descriptive name in the Note field.
Expiration: Set an expiration date for the token. You can choose from 7 days, 30 days, 60 days, 90 days, or no expiration.
Select Scopes: Select the scopes or permissions you'd like to grant this token. For setting up a self-hosted runner, you typically need the repo scope.

Step 4: Generate and Save the Token

Click Generate token.
Important: Copy the token to a secure location. This is the only time you will be able to see it. If you lose it, you will need to generate a new token.

Example of Required Scopes

For setting up a self-hosted runner, you generally need the following scope:

repo: Full control of private repositories

You now have a Personal Access Token (PAT) that you can use to authenticate with GitHub when setting up your self-hosted runner. Make sure to keep this token secure and do not share it publicly.

Step-by-Step Guide Create Self Hosted Runner

Step 1: Launch an Ubuntu EC2 Instance (if using AWS)

You can spin-up the instance either manually from AWS console or use Terraform IaC Automation

AWS Console Method

Log in to your AWS Management Console.
Navigate to the EC2 Dashboard.
Click on "Launch Instance".
Choose an Amazon Machine Image (AMI) with Ubuntu (e.g., Ubuntu Server 22.04 LTS or 24.04 LTS
Select an instance type (e.g., t2.micro for testing).
Configure instance details, add storage, and configure security groups as needed.
Launch the instance and connect to it via SSH.

Terraform IaC Method

You can use Terraform IaC code to spin-up an EC2 instance. Refer the Terraform EC2 Module Guide for the reference.

Step 2: Set Up the Runner on Ubuntu

SSH into your Ubuntu instance.

Create a shell script file named SETUP-RUNNER-LINUX.SH and add the following code:

#!/bin/bash
# Check if both arguments are provided
if [ "$#" -ne 2 ]; then
    echo "Missing arguments. Usage: $0 <repo_to_add_runner> <github_token>"
    exit 1
fi

repo_to_add_runner=$1
github_token=$2

# Create a folder
mkdir actions-runner && cd actions-runner
# Download the latest runner package
curl -o actions-runner-linux-x64-2.313.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.313.0/actions-runner-linux-x64-2.313.0.tar.gz

# Optional: Validate the hash
# echo "5697e222e71c4  actions-runner-linux-x64-2.313.0.tar.gz" | shasum -a 256 -c

# Create directory to extract the tar
mkdir runner-files && cd runner-files
# Extract the installer
tar xzf ../actions-runner-linux-x64-2.313.0.tar.gz

# Create GitHub runner registration token to be used in config.sh input
curl -L -X POST -H "Accept: application/vnd.github+json" -H "Authorization: Bearer $github_token" -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/chefgs/$repo_to_add_runner/actions/runners/registration-token | jq .token --raw-output > token.txt
repo_token=$(cat token.txt)

# Create the runner and start the configuration experience
./config.sh --unattended --url https://github.com/chefgs/$repo_to_add_runner --token $repo_token

# Config.sh installs the service files. 
# So as a last step, setup runner service & run it!
./svc.sh install && ./svc.sh start

# Otherwise, If you want to run the runner interactively, you can run ./run.sh

# Clean up
if [ ! -z token.txt ]; then
    rm token.txt
fi

Make the script executable:
```
chmod +x SETUP-RUNNER-LINUX.SH
```
Run the script with your repository name and GitHub token as arguments:
```
./SETUP-RUNNER-LINUX.SH <repo_to_add_runner> <github_token>
```

Step 3: Update Your Workflow File

Add the following line to your workflow file to use the self-hosted runner:

runs-on: self-hosted

Example workflow file (.github/workflows/ci.yml):

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: self-hosted
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Run build
        run: make build

Explanation

How a Specific Repository Uses the Self-Hosted Runner

When you set up a self-hosted runner, you are adding a custom machine to your GitHub repository that can execute GitHub Actions workflows. Here's how it works:

Runner Setup: You download and configure the runner software on your machine.
Registration Token: You generate a registration token from GitHub, which is used to link the runner to your specific repository.
Configuration: You configure the runner with the repository URL and the registration token.
Service Installation: The runner is installed as a service on your machine, allowing it to start automatically and run in the background.
Workflow Execution: When a workflow is triggered in your repository, GitHub Actions will use the self-hosted runner to execute the jobs defined in the workflow.

Linking the Runner to a Repository

Registration Token: The registration token generated from GitHub is specific to the repository you want to link the runner to. This token ensures that the runner is securely associated with the correct repository. We will be using GitHub PAT token passed as an argument to fetch the repo registration token.- Repository URL: During the configuration step, you provide the URL of the repository. This URL, combined with the registration token, links the runner to the repository.
GitHub Actions Workflow: In your workflow file, you specify runs-on: self-hosted to indicate that the job should run on the self-hosted runner.

By specifying runs-on: self-hosted, GitHub Actions will use the self-hosted runner you set up to execute the job.

Conclusion

You have now set up a GitHub Actions self-hosted runner on an Ubuntu system. Update your workflow files to use this runner by specifying runs-on: self-hosted. This allows you to run your CI/CD jobs on your own hardware, providing more control over the environment and potentially reducing costs.

Reference

GitHub Self-hosted Runner Docs

The Art of Creating Container Images and Best Practices

Saravanan Gnanaguru — Mon, 29 Jul 2024 19:12:06 +0000

The Art of Creating Container Images

Introduction

We are in the era of the evolving landscape of software product development, So the need for efficient, consistent, and scalable deployment methods has been more critical.

One of the most significant advancements in this area is the use of containers. Containers have revolutionized the way we build, package, and deploy applications, offering a level of flexibility and reliability that traditional methods often lack.

It is one of key automation pillar in DevOps Process Automation (CI/CD), that helps the developed frozen code has been released. It is making sure nothing gets changed in code once it is packaged into container images.

In this blog, we'll explore the concept of containers, delve into the traditional approach of application packaging, and highlight the best practices for creating container images. Additionally, we'll provide examples of packaging React and Java-based applications using containers.

What are Containers?

Containers are lightweight, portable units of software that package an application and its dependencies together, ensuring that it runs consistently across different computing environments. Unlike virtual machines, containers share the host system's kernel, which makes them more efficient in terms of resource usage. Containers can be run on any system that supports the container runtime, making them an ideal choice for modern, cloud-native application development and deployment.

Packaging the Application: A Traditional Approach

Before the advent of containers, applications were typically packaged and deployed using traditional methods. This often involved creating installation packages that bundled the application binaries along with necessary libraries and configuration files. These packages were then installed on target systems, where the application would run. While this approach worked for many years, it had several inherent limitations.

Disadvantages of the Old Approach

Inconsistent Environments: Traditional packaging methods often led to inconsistencies between development, testing, and production environments. This could cause applications to behave differently depending on where they were running. There is a chance that developers over-writes the finalised packages that are about to be deployed in release environments, causing the delay in product or feature releases.
Dependency Conflicts: Managing dependencies was a significant challenge. Different applications might require different versions of the same library, leading to conflicts and "dependency hell."
Resource Overhead: Traditional methods typically required separate instances of operating systems for each application, leading to high resource consumption and inefficiencies.
Complex Deployment: The deployment process was often complex and error-prone, requiring manual intervention and detailed configuration.

How Containers Help in Overcoming the Shortfall of Traditional Approach

Containers address many of the shortcomings of traditional application packaging methods:

Consistency: By packaging the application and its dependencies together, containers ensure that the application runs the same way, regardless of where it is deployed.
Isolation: Containers provide process and filesystem isolation, reducing the risk of dependency conflicts and enhancing security.
Efficiency: Containers share the host system's kernel and resources, making them more efficient than virtual machines. This allows for higher density and better resource utilization.
Simplified Deployment: Containers can be easily deployed, scaled, and managed using container orchestration platforms like Kubernetes. This simplifies the deployment process and reduces the risk of errors.

Container Image Creation Best Practices

Creating efficient and secure container images is crucial for leveraging the full benefits of containerization. Here are some best practices to follow:

Low Image Size

Use Minimal Base Images: Start with a minimal base image, such as alpine or distroless, to reduce the overall image size.
Multi-stage Builds: Use multi-stage builds to separate the build environment from the runtime environment. This helps in keeping the final image lightweight by excluding unnecessary build tools and dependencies.
Remove Unnecessary Files: Clean up temporary files, cache, and other unnecessary files during the image build process.

Less/No Vulnerable Images

Regular Updates: Regularly update the base images and dependencies to include the latest security patches and updates.
Security Scanning: Use tools like Trivy or Clair to scan images for known vulnerabilities before deploying them.
Minimal Permissions: Ensure that the application runs with the least privileges necessary to reduce potential attack surfaces.

Be Cautious in Opening Ports

Limit Exposed Ports: Only expose the ports that are necessary for the application to function. Avoid exposing unnecessary ports to reduce the attack surface.
Use Non-standard Ports: When possible, use non-standard ports to make it harder for attackers to find and exploit open services.

Follow Security Best Practices

Use Non-root Users: Run applications as non-root users within the container to minimize the impact of a potential security breach.
Environment Variables: Avoid hardcoding sensitive information in the image. Use environment variables to pass sensitive data at runtime.
Network Policies: Implement network policies to control the traffic between containers, enhancing security within the containerized environment.

Example of Packaging React and Java-based Application

Let's look at examples of packaging a React application and a Java-based application using Docker.

Installing Docker

Before you can create and push images, you need to have Docker installed on your machine. You can follow the official Docker installation guide for your operating system here.

Packaging a React Application

Let us consider a React based web application we have. Here is what the container creation Dockerfile will look like,

Dockerfile:

This is a multi-stage Dockerfile. Where we have Two stages, and Stage 2 is dependent on Stage 1 Build.

Dockerfile has to be added into the Project Home path.

```dockerfile
# Stage 1: Build the React app
FROM node:14-alpine as build

WORKDIR /app

COPY package.json ./
COPY package-lock.json ./

RUN npm install

COPY . ./

RUN npm run build

# Stage 2: Serve the React app using Nginx
FROM nginx:alpine

COPY --from=build /app/build /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]
```

Build and Run:

Once the Docker file is created, we can run the commands below to create the Image in user Workstation.

```sh
docker build -t my-react-app .
docker run -d -p 80:80 my-react-app
```

Packaging a Java-based Application

Let us consider another application, which is a Java based web application. So here is what the container creation Dockerfile will look like,

Dockerfile:

This is also a multi-stage Dockerfile. Where we have Two stages, Stage 1 build code and Stage 2 is dependent on Stage 1 Build.

Dockerfile has to be added into the Project Home path.

    # Stage 1: Build the Java app
    FROM maven:3.8.1-jdk-11 as build

    WORKDIR /app

    COPY pom.xml ./
    COPY src ./src

    RUN mvn clean package -DskipTests

    # Stage 2: Run the Java app
    FROM openjdk:11-jre-slim

    COPY --from=build /app/target/my-java-app.jar /app/my-java-app.jar

    EXPOSE 8080

    CMD ["java", "-jar", "/app/my-java-app.jar"]

Build and Run:

Once the Docker file is created, we can run the commands below to create the Image in user Workstation.

```sh
docker build -t my-java-app .
docker run -d -p 8080:8080 my-java-app
```

Pushing Images to Docker Hub or Cloud Registry

Once your container images are built and tested locally, you often need to push them to a container registry for storage and deployment to other environment. Here’s how to push images to different registries.

Pushing Images to Docker Hub

Create a Docker Hub Account: If you don't already have one, go to Docker Hub and create an account.
Login to Docker Hub:

   docker login

You will be prompted to enter your Docker Hub username and password.

Tag Your Image:

   docker tag my-image:latest your-dockerhub-username/my-image:latest

Push the Image:

   docker push your-dockerhub-username/my-image:latest

Pushing Images to Google Container Registry (GCR)

Set Up GCloud: Install the Google Cloud SDK and authenticate.

   gcloud auth login
   gcloud auth configure-docker

Tag Your Image:

   docker tag my-image:latest gcr.io/your-project-id/my-image:latest

Push the Image:

   docker push gcr.io/your-project-id/my-image:latest

Pushing Images to Amazon Elastic Container Registry (ECR)

Create an ECR Repository: Use the AWS Management Console or CLI to create a repository.

   aws ecr create-repository --repository-name my-repo

Authenticate Docker to Your ECR:

   aws ecr get-login-password --region your-region | docker login --username AWS --password-stdin your-account-id.dkr.ecr.your-region.amazonaws.com

Tag Your Image:

   docker tag my-image:latest your-account-id.dkr.ecr.your-region.amazonaws.com/my-repo:latest

Push the Image:

   docker push your-account-id.dkr.ecr.your-region.amazonaws.com/my-repo:latest

Pushing Images to Azure Container Registry (ACR)

Create an ACR: Use the Azure CLI to create a registry.

   az acr create --resource-group myResourceGroup --name myACR --sku Basic

Login to ACR:

   az acr login --name myACR

Tag Your Image:

   docker tag my-image:latest myACR.azurecr.io/my-repo:latest

Push the Image:

   docker push myACR.azurecr.io/my-repo:latest

Summary of Steps

Create an Account/Repository: Create an account on the desired registry platform and create a repository if necessary.
Login to the Registry: Use CLI commands to authenticate your Docker client with the registry.
Tag Your Image: Properly tag your Docker image to match the registry's naming conventions.
Push the Image: Use the docker push command to upload your image to the registry.

Conclusion

Containers have transformed the way we package and deploy applications, offering significant advantages over traditional methods.

By following best practices for container image creation, we can build efficient, secure, and reliable containerized applications. Whether you're working with modern JavaScript frameworks like React or more traditional Java applications, containerization can streamline your development and deployment processes, ensuring consistency and scalability across different environments.

Start leveraging containers today to take your application development to the next level.

Suggested Next Steps

Explore container orchestration platforms like Kubernetes.
Integrate continuous integration and continuous deployment (CI/CD) pipelines with containerization.
Learn about service mesh technologies for managing microservices within a containerized environment.

By embracing these technologies and practices, you can further enhance the efficiency and scalability of your applications.

Reach out to me

GitHub

Create Architecture Diagram as Code for a 2-Tier Bookstore Application

Saravanan Gnanaguru — Tue, 09 Jul 2024 15:20:30 +0000

How to Create Architecture Diagram as Code for a 2-Tier Bookstore Application

Creating architecture diagrams as code is a modern approach that offers numerous benefits over traditional diagramming methods, including architecture diagram automation, and consistency. This approach allows for version-controlled, easily reproducible, and modifiable diagrams that can evolve alongside your application.

This article will guide you through the process of creating an architecture diagram for a 2-tier bookstore application in AWS Cloud using Python and its [diagrams] library.

Why Diagrams as Code?

Diagrams as code offer several advantages over traditional diagramming tools:

Version Control: Changes to diagrams can be tracked over time.
Automation: Diagrams can be automatically updated as part of your CI/CD pipeline.
Consistency: Ensures uniformity in the presentation of your architecture.

Diagram as code makes it easy to Architects and Developers to update their architecture diagram, and use version control to maintain various versions of the Architecture.

Tools & Technology Used

We'll use the [diagrams] Python library, which allows for creating cloud system architecture diagrams using code. It supports various providers, including AWS, GCP, Azure, and many more.

Prerequisites

Python 3.x installed on your system
Basic understanding of Python programming
Familiarity with virtual environments in Python

Sample Application: Bookstore 2-Tier Architecture

Our sample application is a simple bookstore with a 2-tier architecture consisting of a frontend and a backend, along with a database. It also includes a CI/CD pipeline and monitoring services.

To run the Python code that generates an architecture diagram for a bookstore application, follow these detailed steps. These steps include setting up a virtual environment, installing dependencies, and running the script.

Step 1: Setting Up a Python Virtual Environment

First, you need to create a virtual environment. A virtual environment is a self-contained directory that contains a Python installation for a particular version of Python, plus a number of additional packages.

Open your terminal.
Navigate to the directory where you want to store your project.
Run the following command to create a virtual environment named venv:



python3 -m venv venv

Activate the Virtual Environment

Activate the virtual environment to use it for your project.

On macOS and Linux:



source venv/bin/activate

On Windows:



.\venv\Scripts\activate

Install the Required Libraries

With the environment activated, install the diagrams library, which enables you to generate architecture diagrams using Python code.



pip install diagrams graphviz

Step 2: Writing the Diagram Code

Create a new Python file named [architecture.py] and open it in your favorite text editor.
Copy the following code into the file. This code defines the architecture of a simple bookstore application with a 2-tier architecture, including a frontend, a backend, a database, a CI/CD pipeline, and monitoring services.



from diagrams import Diagram, Cluster, Edge
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB, Route53
from diagrams.aws.general import Client
from diagrams.onprem.network import Internet
from diagrams.onprem.monitoring import Prometheus, Grafana
from diagrams.programming.framework import React
from diagrams.custom import Custom

graph_attr = {'ranksep': '1.0'} #, 'rankdir': 'TB'}

with Diagram("Two Tier Application Architecture", show=False, graph_attr=graph_attr):
    with Cluster("User Network"):
        client = Client("User")
        internet = Internet("Internet")

    with Cluster("CI/CD Pipeline"):
        with Cluster("Source Code"):
            react = React("React")
            terraform = Custom("Terraform", "./tf.png")
        github_actions = Custom("GitHub Actions", "./ghactions.png")

    with Cluster("AWS Cloud"):
        with Cluster("VPC"):
            with Cluster("Public Subnet"):
                dns = Route53("DNS")
                lb = ELB("Load Balancer")
                # public_subnet = Subnet("Public Subnet")
                dns >> lb

            with Cluster("Private Subnet for Backend"):
                # private_subnet_backend = Subnet("Private Subnet")
                backend = EC2("Backend (Node.js)")
                db = RDS("Database (MongoDB)")
                backend >> db

            with Cluster("Private Subnet for Frontend"):
                # private_subnet_frontend = Subnet("Private Subnet")
                frontend = EC2("Frontend (React)")
                # private_subnet_frontend >> frontend

        with Cluster("Monitoring"):
            prometheus = Prometheus("Prometheus")
            grafana = Grafana("Grafana")

    client >> internet >> dns
    react >> github_actions
    terraform >> github_actions
    lb >> Edge(label="HTTP/HTTPS") >> frontend
    lb >> Edge(label="HTTP/HTTPS") >> backend
    backend >> Edge(label="Database Connection") >> db
    backend >> prometheus
    frontend >> prometheus
    db >> prometheus
    prometheus >> grafana

    # Connecting CI/CD Pipeline to AWS Cloud
    github_actions >> Edge(color="blue", style="dashed", label="Deploy to AWS Cloud") >> dns

# Creating Custom Node 
# Custom Node: We can create a custom node to represent the subnet. 
# The diagrams library allows you to create custom nodes with your own images, 
# which can be useful for representing components that are not available as predefined classes.
# from diagrams import Node
# class Subnet(Node):
#    _icon_dir = "path/to/custom/icons"
#    _icon = "subnet.png"

Full source code has been available in GitHub. Please check it out here.

Python Code Break down of the Architecture Diagram

Let's break down the Python code used to generate the architecture diagram step-by-step:



from diagrams import Diagram, Cluster, Edge
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB, Route53
from diagrams.aws.devtools import Codepipeline, Codebuild
from diagrams.aws.general import Client
from diagrams.onprem.network import Internet
from diagrams.onprem.container import Docker
from diagrams.onprem.monitoring import Prometheus, Grafana
from diagrams.programming.language import Python

Imports

Diagram, Cluster, Edge: Core components from the diagrams library to create diagrams, group components, and define connections.
AWS Components: Various AWS components (EC2, RDS, ELB, Route53, Codepipeline, Codebuild, Client) to represent different parts of the architecture.
On-Prem Components: Components for non-cloud (on-prem) services (Internet, Docker, Prometheus, Grafana).
Programming Language: Represents GitHub Actions with a generic programming language icon (Python).

Creating the Diagram



with Diagram("Two Tier Application Architecture", show=False, graph_attr=graph_attr):
    with Cluster("User Network"):
        client = Client("User")
        internet = Internet("Internet")

Diagram: The main context for the diagram, with the title "Bookstore Application Architecture". show=False prevents the diagram from being immediately displayed.
Client: Represents the user accessing the application.
DNS: Uses Route53 to represent the DNS service.

CI/CD Pipeline



    with Cluster("CI/CD Pipeline"):
        with Cluster("Source Code"):
            react = React("React")
            terraform = Custom("Terraform", "./tf.png")
        github_actions = Custom("GitHub Actions", "./ghactions.png")

Cluster: Groups components logically. Here, it groups the CI/CD pipeline components.
GitHub Actions: Represented using a generic programming language user uploaded icon (ghactions.png).
React and Custom: MERN code and Terraform code representation (with user uploaded Terraform icon). They are integrated with the GitHub action workflow for CICD deployment.

AWS Cloud & Monitoring Components



    with Cluster("AWS Cloud"):
        with Cluster("VPC"):
            with Cluster("Public Subnet"):
                dns = Route53("DNS")
                lb = ELB("Load Balancer")
                # public_subnet = Subnet("Public Subnet")
                dns >> lb

            with Cluster("Private Subnet for Backend"):
                # private_subnet_backend = Subnet("Private Subnet")
                backend = EC2("Backend (Node.js)")
                db = RDS("Database (MongoDB)")
                backend >> db

            with Cluster("Private Subnet for Frontend"):
                # private_subnet_frontend = Subnet("Private Subnet")
                frontend = EC2("Frontend (React)")
                # private_subnet_frontend >> frontend

        with Cluster("Monitoring"):
            prometheus = Prometheus("Prometheus")
            grafana = Grafana("Grafana")

AWS Cloud Cluster: Groups all AWS cloud components.
Load Balancer (ELB) and DNS: Distributes traffic between frontend and backend services. DNS used to be exposed to the public internet.
VPC Cluster: VPC cluster has been created to indicate private and public subnet networks for UI layer and backend layer.
Backend Service Cluster: Contains the backend server (Node.js on EC2) and the database (MongoDB on RDS).
Frontend Service Cluster: Contains the frontend server (React on EC2).
Monitoring Cluster: Contains Prometheus for metrics collection and Grafana for visualization.

Defining Connections



    client >> internet >> dns
    react >> github_actions
    terraform >> github_actions
    lb >> Edge(label="HTTP/HTTPS") >> frontend
    lb >> Edge(label="HTTP/HTTPS") >> backend
    backend >> Edge(label="Database Connection") >> db
    backend >> prometheus
    frontend >> prometheus
    db >> prometheus
    prometheus >> grafana

Connections: Represented using >> operator, defining the flow and connections between components.
client >> internet >> dns: The user accesses the DNS service, via public internet.
react >> github_actions: Represents the CI/CD pipeline flow from MERN Code into integration GitHub Actions.
terraform >> github_actions: Represents the CI/CD pipeline flow from Terraform infra deployment code into integration GitHub Actions.
lb >> Edge(label="HTTP/HTTPS") >> frontend: The load balancer directs traffic to the frontend services.
lb >> Edge(label="HTTP/HTTPS") >> backend: The load balancer directs traffic to the backend services.
backend >> Edge(label="Database Connection") >> db: The backend service connects to the MongoDB database.
backend >> prometheus and frontend >> prometheus: Both frontend and backend services send metrics to Prometheus.
prometheus >> grafana: Prometheus metrics are visualized using Grafana.
github_actions >> Edge(color="blue", style="dashed", label="Deploy to AWS Cloud") >> dns: Depicts to connection from GitHub Action to AWS Cloud infra deployment and code deployment into servers

Summary of Diagram Breakdown

The Python script leverages the diagrams library to create a structured, version-controlled architecture diagram. It groups related components into clusters, defines the interactions between them using directed edges, and ensures the entire infrastructure is visually represented in a clear, consistent manner. This approach makes it easy to update and maintain the architecture diagram as the application evolves.

Adding custom node for user-defined components

Let us see how to create a custom node in Python using the diagrams library. This library allows developers to visually represent their infrastructure and systems.

The purpose of creating a custom node is to represent a user-defined architecture component and ICON/logo.

Method 1: Defining the from diagrams.custom import Custom Diagrams Custom module, and using this section along with the valid logo/ICON PNG image of the architecture component.
For example, we have added Terraform Icon using this method.

We need to store the license free PNG image for this purpose.



from diagrams.custom import Custom

terraform = Custom("Terraform", "./tf.png")

Method 2:
As depicted on the commented out example, a custom node definition for subnet has been added.

A subnet is part of VPC architecture &, and is a logical subdivision of an IP network. The ability to create custom nodes is particularly useful when the predefined classes provided by the diagrams library do not cover all the components you need to represent in your architecture diagrams.

The code snippet begins by importing the Node class from the diagrams library.
This Node class is the base class for all diagram nodes, and custom nodes can be created by subclassing it.
The subclass shown in the example is named Subnet, indicating its intended use to represent subnetworks.

Within the Subnet class, two class attributes are defined:

_icon_dir: This attribute specifies the directory path where custom icons are stored. In this example, it's set to "path/to/custom/icons", which should be replaced with the actual path to the directory containing the icon files.
_icon: This attribute specifies the filename of the icon image that will be used to visually represent the node in the diagram. Here, it is set to "subnet.png", indicating that an image file named subnet.png in the specified directory will be used as the icon for the subnet node.

By defining these attributes, the Subnet class tells the diagrams library where to find the custom icon and which icon to use when rendering the subnet node in a diagram. This allows for a more customized and visually accurate representation of the system's architecture.

Step 3: Generating the Diagram

Ensure the Python script ([architecture.py] is saved in your project directory.

Run the script to generate the architecture diagram. Ensure your virtual environment is activated, then execute:



python architecture.py

This command executes the script, which generates a PNG image named Bookstore Application Architecture.png in the same directory, illustrating the architecture of the bookstore application.

Understanding the Diagram `Bookstore Application Architecture.png`

User Network: Represents the entry point for users, connecting through the internet to our application.
CI/CD Pipeline: Showcases the automation for deploying our React frontend and Terraform configurations.
AWS Cloud: Hosts our application, including the load balancer, DNS service, backend service (Node.js), frontend service (React), and database (MongoDB).
Monitoring: Utilizes Prometheus for monitoring and Grafana for visualization.

Step 4: Deactivating the Virtual Environment

Once you're done working in the virtual environment, you can deactivate it by running:



deactivate

This command returns you to the system’s default Python interpreter with all its installed libraries.

By following these steps, you've successfully set up a virtual environment, installed necessary dependencies, and run a Python script to generate an architecture diagram for a bookstore application.

Benefits & Use-cases of Diagram as code

Diagrams as code offer numerous benefits in real-time project scenarios, providing a powerful and efficient way to manage and visualize complex system architectures. Here are some typical use-cases:

Documentation and Communication
Architecture Documentation: Automatically generate up-to-date diagrams that accurately reflect the current state of the system architecture. This ensures that documentation is always current and avoids the pitfalls of manually maintained diagrams.
Team Communication: Facilitate better communication among team members by providing a clear and consistent visualization of the architecture, which can be easily shared and discussed.
Infrastructure as Code (IaC) Integration
IaC Synchronization: Use diagrams as code to keep architecture diagrams in sync with the actual infrastructure managed by tools like Terraform, CloudFormation, or Ansible. This provides a visual representation of the infrastructure that matches the code.
Automated Updates: Automatically update architecture diagrams as part of the CI/CD pipeline whenever changes are made to the IaC scripts. This ensures that diagrams reflect the latest infrastructure changes.
CI/CD Pipeline Integration
Pipeline Visualization: Visualize the CI/CD pipeline stages and the flow of code from development to production. This helps in understanding the deployment process and identifying potential bottlenecks.
Deployment Architecture: Generate diagrams that show the architecture of the deployed application, including microservices, databases, and other components. This can be especially useful for troubleshooting and optimizing deployment strategies.
Microservices and Distributed Systems
Service Dependencies: Visualize the dependencies and interactions between microservices in a distributed system. This helps in understanding the overall system behavior and identifying potential points of failure.
Dynamic Environments: Automatically generate diagrams for dynamic environments where services and dependencies may frequently change. This ensures that the architecture diagram remains accurate and up-to-date.
Architecture diagram AI automation:
If you want to create AI to generate architecture diagram for given prompt, then we can use this method of generating diagrams

Conclusion

You've now successfully created an architecture diagram as code for a 2-tier bookstore application. This method allows for easy updates, version control, and integration into CI/CD pipelines, making it an efficient tool for modern software development practices.

Docs Reference

Python Diagrams

Installation

Examples

Follow me on,

Share your views about creating Architecture Diagrams as code.

Practicing Kubernetes Control Plane environment in Killercoda Interactive Terminal

Saravanan Gnanaguru — Tue, 23 May 2023 16:18:54 +0000

Killercoda Interactive Terminal

Killercoda offers free environments (based on Ubuntu) with various tools for beginners to try hands-on. It also has the Kubernetes playground which provides control plane server access for 1 hour. In which we can try to practice hands-on with control plane components.
Because sometimes we are dependent on training platforms to try the control plane (or kubeadm) practice, and killercoda comes handy as a free platform to satisfy the needs.

killercoda environment is similar to the killershell Kubernetes certification exam environment, but without the test scenarios.

So to get started with killercoda, users need to sign up for an account using their preferred method listed on the screen.

What is available in Killercoda Playground

There are variety of options available in Killercoda, plain Ubuntu OS, Kubernetes control plane with various versions and other options related to Kubernetes environment

Choose a Kubernetes environment

Let us choose Kubernetes v1.26 environment and inspect the internal components of Kubernetes control plane

Kubectl get nodes and get namespace

This control plane has 2 nodes and 5 namespaces

Kubectl get pods -A -o wide

controlplane $ k get pods -A -o wide
NAMESPACE            NAME                                       READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
kube-system          calico-kube-controllers-5f94594857-kjbzt   1/1     Running   4          2d20h   192.168.0.3   controlplane   <none>           <none>
kube-system          canal-5zh75                                2/2     Running   0          32m     172.30.1.2    controlplane   <none>           <none>
kube-system          canal-9wbgc                                2/2     Running   0          32m     172.30.2.2    node01         <none>           <none>
kube-system          coredns-68dc769db8-4nd5b                   1/1     Running   0          2d19h   192.168.0.7   controlplane   <none>           <none>
kube-system          coredns-68dc769db8-fmx25                   1/1     Running   0          2d19h   192.168.1.2   node01         <none>           <none>
kube-system          etcd-controlplane                          1/1     Running   0          2d20h   172.30.1.2    controlplane   <none>           <none>
kube-system          kube-apiserver-controlplane                1/1     Running   2          2d20h   172.30.1.2    controlplane   <none>           <none>
kube-system          kube-controller-manager-controlplane       1/1     Running   2          2d20h   172.30.1.2    controlplane   <none>           <none>
kube-system          kube-proxy-7zc4f                           1/1     Running   0          2d20h   172.30.1.2    controlplane   <none>           <none>
kube-system          kube-proxy-glxxb                           1/1     Running   0          2d19h   172.30.2.2    node01         <none>           <none>
kube-system          kube-scheduler-controlplane                1/1     Running   2          2d20h   172.30.1.2    controlplane   <none>           <none>
local-path-storage   local-path-provisioner-8bc8875b-lspfz      1/1     Running   0          2d20h   192.168.0.6   controlplane   <none>           <none>

We can see the list contains the control plane components

Contents of the directory `/etc/kubernetes`

We can find all the important files of Kubernetes control plane components, configurations, secrets and key files inside /etc/kubernetes directory.

controlplane $ pwd   
/etc/kubernetes

controlplane $ tree --dirsfirst
.
|-- manifests
|   |-- etcd.yaml
|   |-- kube-apiserver.yaml
|   |-- kube-controller-manager.yaml
|   `-- kube-scheduler.yaml
|-- pki
|   |-- etcd
|   |   |-- ca.crt
|   |   |-- ca.key
|   |   |-- healthcheck-client.crt
|   |   |-- healthcheck-client.key
|   |   |-- peer.crt
|   |   |-- peer.key
|   |   |-- server.crt
|   |   `-- server.key
|   |-- apiserver-etcd-client.crt
|   |-- apiserver-etcd-client.key
|   |-- apiserver-kubelet-client.crt
|   |-- apiserver-kubelet-client.key
|   |-- apiserver.crt
|   |-- apiserver.key
|   |-- ca.crt
|   |-- ca.key
|   |-- front-proxy-ca.crt
|   |-- front-proxy-ca.key
|   |-- front-proxy-client.crt
|   |-- front-proxy-client.key
|   |-- sa.key
|   `-- sa.pub
|-- admin.conf
|-- controller-manager.conf
|-- kubelet.conf
`-- scheduler.conf

3 directories, 30 files

Control Plane Component Manifest files

Let us see the contents of manifests/kube-apiserver.yaml
We can notice the manifest has config values of etcd, tls and other components

controlplane $ cat manifests/kube-apiserver.yaml 
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 172.30.1.2:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=172.30.1.2
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    image: registry.k8s.io/kube-apiserver:v1.26.1
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 172.30.1.2
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 172.30.1.2
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 50m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 172.30.1.2
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/ca-certificates
      name: etc-ca-certificates
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
    - mountPath: /usr/local/share/ca-certificates
      name: usr-local-share-ca-certificates
      readOnly: true
    - mountPath: /usr/share/ca-certificates
      name: usr-share-ca-certificates
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/ca-certificates
      type: DirectoryOrCreate
    name: etc-ca-certificates
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /usr/local/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-local-share-ca-certificates
  - hostPath:
      path: /usr/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-share-ca-certificates
status: {}

Similarly, let us inspect the contents of manifests/etcd.yaml
We notice the manifest has an etcd key, cert files and other config values.

controlplane $ cat manifests/etcd.yaml 
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.30.1.2:2379
  creationTimestamp: null
  labels:
    component: etcd
    tier: control-plane
  name: etcd
  namespace: kube-system
spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://172.30.1.2:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/var/lib/etcd
    - --experimental-initial-corrupt-check=true
    - --experimental-watch-progress-notify-interval=5s
    - --initial-advertise-peer-urls=https://172.30.1.2:2380
    - --initial-cluster=controlplane=https://172.30.1.2:2380
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://172.30.1.2:2379
    - --listen-metrics-urls=http://127.0.0.1:2381
    - --listen-peer-urls=https://172.30.1.2:2380
    - --name=controlplane
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-client-cert-auth=true
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --snapshot-count=10000
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    image: registry.k8s.io/etcd:3.5.6-0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /health?exclude=NOSPACE&serializable=true
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: etcd
    resources:
      requests:
        cpu: 25m
        memory: 100Mi
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /health?serializable=false
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
    - mountPath: /etc/kubernetes/pki/etcd
      name: etcd-certs
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data
status: {}

Taking ETCD Backup snapshot in control plane

Now, let us try a ETCD backup using the command from documentation

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> \
--cert=<cert-file> \
--key=<key-file> \
snapshot save <backup-file-location>

We can grep for pki values in manifests/etcd.yaml

controlplane $ grep pki manifests/etcd.yaml 
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

Replace values of cert-file, key-file and trusted-ca-file in the etcdctl snapshot save command

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /tmp/snapshot-pre-boot.db

Finally, we will run the snapshot save command:

controlplane $ ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
> --cacert=/etc/kubernetes/pki/etcd/ca.crt \
> --cert=/etc/kubernetes/pki/etcd/server.crt \
> --key=/etc/kubernetes/pki/etcd/server.key \
> snapshot save /tmp/snapshot-pre-boot.db

{"level":"info","ts":1684855944.7321026,"caller":"snapshot/v3_snapshot.go:68","msg":"created temporary db file","path":"/tmp/snapshot-pre-boot.db.part"}
{"level":"info","ts":1684855944.7623043,"logger":"client","caller":"v3/maintenance.go:211","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1684855944.7625878,"caller":"snapshot/v3_snapshot.go:76","msg":"fetching snapshot","endpoint":"https://127.0.0.1:2379"}
{"level":"info","ts":1684855946.5906115,"logger":"client","caller":"v3/maintenance.go:219","msg":"completed snapshot read; closing"}
{"level":"info","ts":1684855948.752495,"caller":"snapshot/v3_snapshot.go:91","msg":"fetched snapshot","endpoint":"https://127.0.0.1:2379","size":"6.1 MB","took":"4 seconds ago"}
{"level":"info","ts":1684855948.7526174,"caller":"snapshot/v3_snapshot.go:100","msg":"saved","path":"/tmp/snapshot-pre-boot.db"}

Snapshot saved at /tmp/snapshot-pre-boot.db

Conclusion

Idea of this blog is to introduce the killercoda environment to newbies of Kubernetes. So they can explore the Control plane components as part of their learning.
I believe seeing things and getting your hands dirty at the same time allows anyone to catch hold of things faster.
In terms of kubernetes learning the more practice we do, the more confidence we do get.

Follow me on,

Automate Kubernetes Deployment using Terraform and GitHub Actions

Saravanan Gnanaguru — Mon, 22 May 2023 19:03:40 +0000

Automate Kubernetes Deployment using Terraform and GitHub Actions

What I built

I've created Terraform code that will create a namespace and deploys the Nginx server in the minikube cluster and TF code verification and deployment has been automated using GitHub actions

How I built

Created a GitHub Actions workflow using the Marketplace Github actions plugins,
- actions/checkout@v2.5.0 -> to Checkout the code
- medyagh/setup-minikube@v0.0.13 -> to setup minikube
- Azure/setup-kubectl@v3 -> to setup kubectl
- hashicorp/setup-terraform@v2.0.2 -> to setup terraform
This workflow can be used in development environments, in which an Infra developer can create the Terraform code to deploy kubernetes workload. Once after creating the tf code, the developer can trigger the Terraform workflow, that will do the CI for Terraform code, and deploy the infra in minikube.
The kube config context has been created as a variable in Terraform, so it can be overridden with other Kubernetes Cluster config and contexts from Cloud providers like Amazon EKS or Azure AKS or GCP GKE Clusters.

Category Submission

DIY Deployments

App Link

Source code for the Repo is available here

Github Action Workflow Yaml

Screenshots

Description

Triggering the Workflow

This workflow can be triggered from the actions tab, by providing the Terraform code directory as an input (Refer the screenshot above).
So it will run the below steps in the directory provided as input,

Workflow installs, minikube, kubectl and terraform CLI executables needed to be used by the rest of workflow
It runs terraform init command to download the kubernetes provider
Then runs terraform validate command to check the tf code is valid or not
After that it runs, terraform plan and terraform apply commands and performs the Kubernetes namespace creation and deploys the nginx server.
Workflow also has terraform destroy command, that deletes the kubernetes infra created in the workflow

Workflow Dispatch

This workflow uses, workflow_displatch Github feature - It is the sub block inside the on event triggering block, in which we can specify what are the inputs needed to trigger the workflow.
In the on event block workflow_dispatch section, we will be adding the inputs directory path, on which we are going to run our Terraform code validation
It is defaulted to the 'kubernetes' directory present in the repo for the ease of demo purpose.

Link to Source Code

Source code for the Repo is available here

Github Action Workflow Log

Github Action Workflow Yaml

Permissive License

MIT License

Background

As mentioned earlier,
This workflow (or pipeline) can be configured for testing the terraform code pushed by DevOps engineers/SREs/Developers, and can be triggered whenever there is new tf code is pushed into a specific branch for Kubernetes workload management

Additional Resources/Info

Platform Engineering and Internal Developer Platform

Saravanan Gnanaguru — Thu, 11 May 2023 07:25:02 +0000

Platform engineering and IDP

The concept of platform engineering is the step up evolution of setting up deployment automation using CICD tools and utilizing the Cloud provider integration for hosting the apps.
IDP is its further evolution to reduce the dependency of DevOps engineers' interaction with Developers. Because these concepts help to set up a self service platform for developers to onboard their app when they are ready to deploy.

These concepts are mainly driven by the pipeline automation done using Pipeline as a code and creating templates for reusable deployments.

Approaching the platform engineering concept is a step by step process, so let me explain my view of this concept (this might be different from person to person).

Deployment automation using CICD

Step 1: Usual cycle of application onboarding,

It starts with usual deployment automation using CICD,

when the dev teams complete developing a feature, there is a need for development teams to reach out to DevOps engineers to onboard their application for promoting the code for the release
So before the feature development starts, devops engineers or leads works in parallel with development team to understand the build and app deployment process from dev teams
DevOps engineer/lead will come up with a deployment strategy (including the integration with infra automation, test automation tools and monitoring tools) for the specific feature development, that was based on the nature of programming language used typically. In some cases, architecture decisions need to be considered, if the application is fit for container based deployment or non container based deployment.
Then using the tools automation knowledge of DevOps engineers pipeline will be created with various integration needed for CI and CD tools
Once the pipeline is ready, it is recommended to test the build and deployment strategy with some sample application provided by the dev team, to confirm the strategy works good and it can be used to on-board when the actual application development is complete
In case of multiple feature development teams, this process will be repeated for each teams
So finally when the feature development is completed, the dev team approaches the DevOps engineer to on-board the application in the pipeline

The process so far explained can be the typical example of how a feature development team utilizes the DevOps engineer team for application onboarding.

Platform Engineering

Step 2: Evolution from Individual deployment automation to Platform Engineering

Now we can notice there is a repeatable pattern of efforts involved here for feature teams and there is dependency for developers with devops engineers. Here is when the usual deployment automation gets evolved into platform engineering. As I mentioned earlier every deployment orchestration tool available now be it OSS or enterprise tools, supports creating the pipeline as code.
So to simplify the application onboarding for development teams, DevOps engineers will be creating a pipeline as code and will make it as a template for each specific development team. The template can be re-used onboarding apps of the same programming language.
Also another advantage of pipeline as code is, it can be source controlled in git so the pipeline will be versioned for various releases too.
So the process of strategising the deployment automation and templating the deployment will be a major responsibility here. The team responsible for implementing it is as platform engineering team and engineers are called platform engineers.
This entire deployment automation and onboarding of apps will be documented and handover will be given to developers on how to use this template for further app onboarding. So this reduces the dependency of DevOps engineers for dev teams.

Internal Developer Portal

Then let's quickly discuss what is IDP as well.

Internal Developer Portal (or Platform) - IDP in short is an extension of the platform engineering team. We have discussed how the deployment automation process was simplified using pipeline as code template, and version controlling it.
So the IDP platform will be having an UI to wrap all the various existing pipeline templates of specific tech stacks in the portal. Thus it further simplifies the job for developers.
Typical IDP platform should have customisation options to choose the tech stack and what is required in the pipeline. When the developers chooses the feature development repo, the internal pipeline template will be picked up for the specific tech stack and generate an automated pipeline to onboard the app.
Also it will contain various dashboards which will show various release metrics for stakeholders to understand how the feature development is going. For typical IDP contain the pipeline health metric which will show how the deployments are performing and how is the health of specific services deployed in infrastructure.

Conclusion

In this blog, I've explained the abstract understanding of platform engineering and IDP in this post. We have not deep dived into each topic. So If you want to know more about the specific topic please reach out to me.

Follow me to share your thoughts,

Setup HarperDB on Equinix Bare Metal Server

Saravanan Gnanaguru — Wed, 19 Apr 2023 15:03:43 +0000

Introduction to HarperDB
Ways to Host HarperDB
Introduction to Equinix Bare Metal
Equinix Account Setup and Completing Prerequisites
Create an On Demand Server in Equinix
Login into the Server using SSH
Install and Run HarperDB on Equinix Server
- Prerequisites
- HarperDB installation using npm
Run HarperDB in Equinix
- Alternate method to run HarperDB
Access the HarperDB using Equinix IP
Start using HarperDB hosted in Equinix
- Create Schema
- Create Table
- Insert a Record
Conclusion
Document References

Introduction to HarperDB

HarperDB is a globally-distributed edge data platform that is designed to handle massive amounts of data with ultra low latency. Other edge database solutions are not write optimized and global replication is slow. Whereas HarperDB is read and write optimized, handling upwards of 20K writes per second per node, with 110 ms global replication.

HarperDB’s clustering methodology relies on eventual consistency to be much more efficient than more traditional options, and you can’t lock out the database globally. Read more about HarperDB and the use case it is trying to solve in this blog.

HarperDB has the solutions listed below and if you’re an organization looking for database solutions in this area can utilize the HarperDB for your need,

Distributed Database
Edge Computing / Edge Caching
Infrastructure Savings

Ways to Host HarperDB

There are multiple ways available to getting started with HarperDB, but the quickest way to get up and running with HarperDB is with HarperDB Cloud.

It is also possible to Install HarperDB on Cloud Instances across public cloud providers like AWS, Azure, GCP and On premise Cloud providers like Equinix and Linode.

In this blog, we will see how to set-up the HarperDB database in Equinix Cloud Bare Metal Server and create steps to create a DB schema, Table, and insert a record.

Introduction to Equinix Bare Metal

Equinix is one of the leaders in providing on-demand bare metal as a service product offering. You can sign-up here to get started with Equinix.

Equinix Account Setup and Completing Prerequisites

In this section we will see the steps to get started with Equinix.

Step 1: Sign-up for an account,
Step 2: During the sign-up we need to add payment method for billing (apply “deploynow” code to get the trial credit of $250)
Step 3: Create an organization and a project under the org

Step 5: Click on the name of the Project to go to the project page
Step 6: Click on Project Settings > SSH Keys

Step 7: Create an ssh key in your workstation from which we will be using to logging into “Equinix Instance” using the SSH method. Follow the guide here if you’re new to creating the SSH key for your workstation
Step 8: Copy the public key (generally file name will be id_rsa.pub) from the file ending with *.pub
Step 9: Paste Public key value in SSH key page by adding new “Add new key”.

Create an On Demand Server in Equinix

In this section we will see the steps to deploy our on-demand server to install HarperDB.
Step 1: Go to project > Bare metal servers > On demand

Step 2: Go to the “Classic” tab, choose the metro region in which you want to host the HarperDB server.

Step 3: Choose operating system - for this HarperDB demo I’ve selected the OS “Ubuntu 20.04”

Step 4: Expand “Optional settings” and go to “SSH keys” to select SSH key we have added earlier

Step 5: Verify the summary and click on “Deploy Now”
Step 6: We can observe the server instance is getting deployed

Step 7: After some time the instance deployment will be complete, and we can see the instance is up and running

Step 8: Click the instance “hostname” to open the instance details

Login into the Server using SSH

Using the public IPV4 address, we can get into the server using SSH method
Use the private key pair of the public key we have added in the SSH key while creating the instance. It will be located in the path ~/.ssh



$ ssh -i ~/.ssh/equinix_key root@145.40.77.227
The authenticity of host '145.40.77.227 (145.40.77.227)' can't be established.
ED25519 key fingerprint is SHA256:A8G3NWfuX9wEvSbiTtReGwSqouiUirqvXbfBjB/StmM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '145.40.77.227' (ED25519) to the list of known hosts.
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-137-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Thu Apr  6 05:42:41 UTC 2023

  System load:  0.25               Processes:            261
  Usage of /:   0.5% of 438.04GB   Users logged in:      0
  Memory usage: 1%                 IP address for bond0: 145.40.77.227
  Swap usage:   0%

0 updates can be applied immediately.

Your Hardware Enablement Stack (HWE) is supported until April 2023.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

root@c3-small-x86-01:~#

Now we logged into the server and let us see the steps to install HarperDB in the Equinix Server.

Install and Run HarperDB on Equinix Server

Prerequisites

I’ve followed the installation steps available here and followed the Linux installation steps for installing nvm, since we deployed Ubuntu OS in Equinix.

Since it is just a demo installation, I’ve skipped the LVM configuration and Configure Data volume sections.
Now, HarperDB needs npm and NodeJS. So we need to install them using,

nvm - Node version manager, which is the recommended way for installing NodeJS and npm

I’ve used below commands to install nvm



curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

After running the above commands, either you can exit and re-login to the Equinix server so the changes will go into effect.



exit

Then install nvm version 17, which worked fine for me.



nvm install 17

HarperDB installation using npm

I’ve used the offline installation method for installing HarperDB in Equinix.

Step 1: Download installation package



wget https://products-harperdb-io.s3.us-east-2.amazonaws.com/harperdb-4.0.5.tgz

Step 2: install using npm



sudo npm install -g harperdb-4.0.5.tgz harperdb install

There are some optional steps available in the documentation which can help HarperDB to start when the OS boots.

Run HarperDB in Equinix

After the successful installation execute the command harperdb run to start the database

Follow the prompts to start the database



$ harperdb run

This version of HarperDB is tested against Node.js version 18.13.0, the currently installed Node.js version is: 17.9.1. Some issues may occur with untested versions of Node.js.

Starting HarperDB...

HarperDB not found, starting install process.

Starting HarperDB install...

Terms & Conditions can be found at https://harperdb.io/legal/end-user-license-agreement

and can be viewed by typing or copying and pasting the URL into your web browser.

I Agree to the HarperDB Terms and Conditions. (yes/no) yes

Please enter a destination for HarperDB: /root/hdb

Please enter a server listening port for HarperDB: 9925

Please enter a username for the HDB_ADMIN: HDB_ADMIN

Please enter a password for the HDB_ADMIN: [hidden]

HarperDB installation was successful.

           ▒▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒                                
       ▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒                     
   ▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒                    



▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▒


   ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▒


    ▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▒▒


    ▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒


   ▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒


  ▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒

 ▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒ 

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒


  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒


     ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒


         ▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒


            ▒▒▒▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒


               ▒▒▒▒▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒


                   ▒▒▒▓▓▒▒▒▒▒▒▒▒▒▒▒


                      ▒▒▒▒▒▒▒                                  

                HarperDB, Inc. Denver, CO.



|------------- HarperDB 4.0.5 successfully started ------------|

Alternate method to run HarperDB

There is also a single line command available to run HarperDB, which has all the database invocation arguments passed as CLI options



harperdb install --TC_AGREEMENT "yes" --ROOTPATH "/home/ubuntu/hdb" --OPERATIONSAPI_NETWORK_PORT "9925" --HDB_ADMIN_USERNAME "HDB_ADMIN" --HDB_ADMIN_PASSWORD "abc123!"

Access the HarperDB using Equinix IP

HarperDB runs in the server, so it can be accessed via localhost:port http://localhost:9925

Also we can access the server from outside using the “equinix-public-ip:port” as http://145.40.77.227:9925

Start using HarperDB hosted in Equinix

We will now see how to create a DB schema, create tables and insert records in it.

Refer the “Quick Start Examples” in API docs to explore the various programming methods for creating HarperDB elements like schema, tables, etc.

I’ll be using the curl method to play around with HarperDB

Create Schema



root@c3-small-x86-01:~ curl --location --request POST -u HDB_ADMIN:admin123 'http://localhost:9925' --header 'Content-Type: application/json' --data-raw '{

    "operation": "create_schema",

    "schema": "dev"

}'

{"message":"schema 'dev' successfully created"}

Create Table



root@c3-small-x86-01:~ curl --location --request POST -u HDB_ADMIN:admin123 'http://localhost:9925' --header 'Content-Type: application/json' --data-raw '{

    "operation": "create_table",

    "schema": "dev",

    "table": "dog",

    "hash_attribute": "id"

}'

{"message":"table 'dev.dog' successfully created."}

Insert a Record



root@c3-small-x86-01:~ curl --location --request POST -u HDB_ADMIN:admin123 'http://localhost:9925' --header 'Content-Type: application/json' --data-raw '{

    "operation": "insert",

    "schema": "dev",

    "table": "dog",

    "records": [

        {

            "id": 1,

            "dog_name": "Penny",

            "owner_name": "Kyle",

            "breed_id": 154,

            "age": 7,

            "weight_lbs": 38

        }

    ]

}'

{"message":"inserted 1 of 1 records","inserted_hashes":[1],"skipped_hashes":[]}

Conclusion

In this article, we discussed the introduction to HarperDB data platform, and how it was easy to get started with the HarperDB setup in the Equinix Bare metal on-demand server.
Also we have gone through how to access the database and tried out creating a DB schema, Table and Record.
Hope this article should be useful for database professionals, developers and data architects looking for a tutorial of HarperDB installation on Equinix bare metal servers.

Document References

HarperDB Getting Started
HarperDB API documentation
Equinix Getting Started

Forem: Saravanan Gnanaguru

How to Avoid Vulnerabilities in AI-Generated JavaScript and Node.js Projects

Why Your AI Coding Workflow Needs Strict Node.js Rules to Avoid Vulnerabilities

Table of Contents

Introduction

The real issue: AI defaults to the average of the internet

Why this matters more in Node.js than many teams realize

The vulnerability problem is not only “bad packages”

1. Outdated or deprecated dependencies

2. Excessive dependency usage

3. Legacy syntax and module patterns

4. Version ambiguity

5. Weak testing and validation assumptions

Why strict rules are necessary

What strict rules should cover in a Node.js project

Runtime version

Module system

TypeScript expectations

Built-in APIs first

Testing rules

Dependency policy

Security expectations

The meeting app example: where this matters in the real world

What to do in practice

1. Put version constraints in the project itself

2. Use permanent instructions for your AI tools

3. Start prompts with the environment, not the feature

4. Explicitly ban legacy patterns

5. Audit generated dependencies immediately

6. Keep architecture and dependency decisions separate

A sample “rules-first” prompt for modern Node.js development

Example custom instructions for ChatGPT or Claude

Example .cursorrules file

The bigger lesson

Closing thought

Run Your Own GenAI LLMs Offline with LM Studio

LM Studio — The Best Tool for Privacy-First GenAI Enthusiasts

Why This is Important ?

Why Run LLMs Locally?

LM Studio: The Best GUI for Offline LLM Use

✅ Features of LM Studio

LM Studio Best For,

Privacy First Organizations: Why Offline GenAI Use Matters

LM Studio vs Ollama, vLLM & Other Tools

Final Thoughts

What’s Next?

Follow me on,

Git Guide to Delete Old Commits and Clear Sensitive Info from Git History

Introduction

Why Is This Important?

Approach 1: Start Fresh — Remove All History

Approach 2: Remove Specific Files — With git-filter-repo

Approach 3: Squash All Commits Into One

Recommendation: Use Approach 3 (Squash All Commits Into One)

Final Steps

Useful Resources

My new blog on Docker and Kubernetes deployment in UpCloud

How Kubernetes Automates and Manages Your Docker Containers

How Kubernetes Automates and Manages Your Docker Containers

Introduction

Why UpCloud Good for Containers and Kubernetes?

What is Docker?

What Is Kubernetes?

How Kubernetes helps to Orchestrate Docker Containers

1. Automated Deployment and Rollbacks

2. Self-Healing Mechanisms

3. Load Balancing and Service Discovery

4. Horizontal Scaling

5. Resource Optimization

Core Components of Kubernetes

Real-World Example of Kubernetes Implementation

Demo of Deploying a Docker image in Kubernetes

Create a Server in UpCloud

Steps to Deploy Application in Kubernetes

Step 1: Install Minikube and Dependencies

1.1 Install Docker (Required for Minikube)

1.2 Install Kubectl (Kubernetes CLI)

1.3 Install Minikube

Step 2: Start Minikube Cluster

Step 3: Deploy a Simple Application

Example `.cursorrules` file

(Alternative Method) Using `deployment.yaml` File

📄 `nginx-deployment.yaml`