Forem: Theodora

Git, GitHub, and EC2: A Practical Walkthrough from Local Repo to Live Deployment

Theodora — Thu, 29 Jan 2026 22:22:24 +0000

Overview

Most Git and deployment issues don’t come from advanced problems, they come from skipped steps, assumptions, and rushed workflows. This post walks through a complete, end-to-end setup using Git, GitHub, and AWS EC2, focusing on how these tools are actually used in team environments.

Rather than abstract theory, this guide shows the exact commands, decisions, and checks involved in moving from a local repository to a live Nginx deployment, and finally to contributing changes through a pull request. Along the way, I’ll point out where things commonly break, why certain steps matter more than they appear, and how to structure work so it’s reviewable, reversible, and safe.

If you already use Git and Linux, this is meant as a practical reference and a reinforcement of good habits such as clean commits, verified state, isolated branches, and predictable deployments,because those are the details teams rely on long after the tools stop feeling new.

Initializing the Project and Git Repository
Configuring Git Identity (Local vs Global)
Verifying Repository State Before Working
Creating Project Files
Adding Starter Content
Tracking and Staging Files
Creating the First Commit
Making a Controlled Change
Deploying to EC2 with Nginx
Branching Workflow: Adding a Contact Page
Verifying Branch Isolation
Merging the Feature Branch
Inspecting Commit History
GitHub Collaboration: Forks and Remotes
Syncing with Upstream
Creating a Pull Request to Upstream
Final Notes

Initializing the Project and Git Repository

First, create your project directory and initialize Git.

To confirm Git is actually tracking this directory:

You should see a .git folder. Without it, Git isn’t tracking anything,no commits, no branches, no history. Every Git workflow depends on this being present.

Configuring Git Identity (Local vs Global)

Local (Repo-Specific) Identity

In professional environments, repositories often require specific commit identities. I configured a local Git identity for this project.

This ensures commits in this repo don’t accidentally use a different identity.

Global Identity

For personal or non-restricted repositories, a global identity is convenient.

Local config always overrides global config. That precedence matters more than people think.

Verifying Repository State Before Working

Before creating files, always confirm:

You’re in the right directory
Git is active
You’re on the expected branch

Most Git mistakes come from skipping this check.

Creating Project Files

I created two basic frontend files:

Verify they exist.

This might seem trivial, but confirming file creation avoids silent errors,especially when working across multiple terminals.

Adding Starter Content

I copied starter HTML and CSS from a remote repository and pasted it into my local files using VS Code. This mirrors real-world scenarios where teams provide templates or base layouts.

At this stage, nothing is tracked yet.

Tracking and Staging Files

Check the current status:

You should see both files listed as untracked.

Stage the files:

verify staging

Staging is how you control exactly what goes into a commit. Professionals don’t commit blindly.

Creating the First Commit

Create a clean initial commit:

Verify commit history

Clear commit messages make history readable and useful months later.

Making a Controlled Change

I modified the homepage content in index.html, then checked status:

Stage only the modified file:

Commit the change:

Multiple small commits are easier to review and easier to roll back.

Deploying to EC2 with Nginx

SSH into the Server

Note-chi.pem is the name of my key.pem
Install and Verify Nginx

Copy Files from Local Machine

Since the files weren’t zipped, I transferred them individually:

Move Files to Nginx Web Root

Set Permissions

Validate Configuration

Verify Locally on Server

Then access the site in a browser:

Branching Workflow: Adding a Contact Page

Let's talk about branching workflows!

Create and Switch to Feature Branch

Add New File contact.html, edit with VS code editor not nano and Commit

Update index.html Separately by adding the contact page link

Each logical change gets its own commit.

Verifying Branch Isolation

Switch back to main branch:

contact.html should not exist here. This confirms isolation before merging.

Merging the Feature Branch.

Verify files exist and render correctly in the browser.

Inspecting Commit History

If the history looks linear, that’s likely due to a fast-forward merge. This is expected unless --no-ff is used.It should be in a graph format.

GitHub Collaboration: Forks and Pull Requests

Add Remotes

Verify

Sync with Upstream

Push Feature Branch

Then open a pull request from your fork to the upstream repository.

Creating a Pull Request to Upstream

Once the feature branch is pushed to your fork, the final step is opening a Pull Request (PR) to the upstream repository. This is where your changes are reviewed and (if approved) merged.

Verify Your Branch Is Pushed

First, make sure your feature branch exists on GitHub:

The -u flag sets the upstream tracking branch so future pushes don’t require extra arguments.

Open the Pull Request on GitHub

1.Go to your fork on GitHub

Switch to your feature branch (feature/contact-page).
Click Compare & pull request

(If you don’t see it, go to Pull Requests → New Pull Request manually.)

Confirm PR Target Settings

This part matters more than people think. Double-check everything:

Base repository: pravinmishraaws/devops-micro-internship-interviews
Base branch: main
Head repository: your fork
Compare branch: feature/contact-page

A surprising number of PRs fail review simply because they target the wrong repo or branch.

Add a Clear PR Title and Description

PR Title-docs: add contact page
PR Description-This PR adds a contact page and links it from the homepage.
Changes were made on a feature branch and verified before merge.
The goal here isn’t verbosity ,it’s clarity. Reviewers should understand what changed and why in under 10 seconds.

Create the Pull Request

Click Create Pull Request.

At this point:

Your code is isolated
The change is traceable
Reviewers can comment line-by-line
The main branch stays protected

This is the core of how teams collaborate safely at scale.

Why This Step Matters in Practice

In theory, PRs are just a formality.

In practice, they’re where most quality control happens.

PRs are used to:

Catch unintended changes
Enforce standards
Share context
Prevent direct pushes to protected branches

Teams that skip or rush PRs usually pay for it later — in broken releases or messy rollbacks.

Final Thought

From local commits → feature branches → deployment → pull requests, this workflow isn’t about tools. It’s about reducing risk while moving fast.

Once you internalize this flow, you stop “using Git” and start working with teams.

Deploying a Real React App on an Ubuntu VM with AWS and Serving It with Nginx

Theodora — Tue, 20 Jan 2026 00:26:34 +0000

Overview
What You’ll Need
Step 0: Launch an Ubuntu Server on AWS EC2 and Connect via SSH
- Launch the EC2 Instance
- Retrieve the Public IP Address
- Connect to the Server via SSH
Update the System
Install Node.js and npm
Install and Start Nginx
Clone the React Application Repository
Modify the React Application
Install Dependencies and Build the Application
Serve the React App via Nginx
Configure Nginx for a React Single-Page Application
Test the Deployment
Conclusion

Overview

This guide walks through launching an Ubuntu server on AWS EC2, securely connecting to it via SSH, and deploying a real React application that is served using Nginx and accessible through the server’s public IP address.

What You’ll Need

Before starting, ensure you have:

An AWS account

Basic familiarity with the Linux command line

An SSH client (Git Bash, VS Code terminal, or WSL)

Internet access

Step 0: Launch an Ubuntu Server on AWS EC2 and Connect via SSH

0.1 Launch the EC2 Instance

Navigate to EC2 → Instances → Launch instance

Configure the instance:

Name: react-nginx-server (or any preferred name)

AMI: Ubuntu Server 22.04 LTS

Instance type: t3.micro (eligible for free tier)

Key pair: Create or select an existing .pem key

Network settings:

Allow SSH (port 22) from your IP

Allow HTTP (port 80) from anywhere

Launch the instance and wait until its state shows Running

Note- when you click on the above , it will show the instance in a running state.

0.2 Retrieve the Public IP Address

From the EC2 instance details page, copy the Public IPv4 address. This IP will be used both for SSH access and later to view the deployed React app.

0.3 Connect to the Server via SSH

You may use Git Bash, VS Code terminal, or WSL. The command is the same.

ssh -i your-key.pem ubuntu@

Step 1: Update the System

Step 2: Install Node.js and npm

These are application dependencies.

Verify the installation

Step 3: Install and Start Nginx

check status

At this point, Nginx should already be serving the default welcome page on port 80.

Step 4: Clone the React Application Repository

This pulls the application source code to the server.

Step 5: Modify the React Application

Navigate to the source directory

(You may use vi or vim if preferred.)]

Replace the placeholder values with your own details:

Example

Save and exit the editor.

Step 6: Install Dependencies and Build the Application

Return to the project root directory

Install dependencies

Build the production bundle

This generates a build/ directory containing optimized static files.

Step 7: Serve the React App via Nginx

Clear the default web directory

Copy the build output to Nginx’s document root

Set correct permissions

This ensures Nginx can read and serve the files securely.

Step 8: Configure Nginx for a React Single-Page Application

Replace the default Nginx site configuration

Note- This should be ran directly on your terminal

Restart Nginx

Optional validation:

Step 9: Test the Deployment

Retrieve your public IP address

Access the application in your browser

Congratulations

You have successfully:

Launched an Ubuntu server on AWS EC2

Connected securely via SSH

Built a React application for production

Served it efficiently using Nginx

Deploying a Dockerized Web Application to Azure Using Terraform (Manual Docker Build and Push)

Theodora — Sun, 26 Oct 2025 15:36:25 +0000

We will go through the process of deploying a Dockerized Node.js application to Azure Container Instances (ACI) using Terraform. Along the way, we’ll leverage a manual approach to build and push the Docker image to Azure Container Registry (ACR) deployed by Terraform, and then automate the deployment of that image to ACI using Terraform.

Prerequisites

Before diving into the deployment, make sure you have the following tools installed and configured:

Terraform installed: Install Guide
Docker installed and running: Install Guide
Azure CLI installed and authenticated: Install Guide
An Azure Subscription

Step 1: Set Up Azure Container Registry (ACR)
- Set Up variables.tf
- Create terraform.tfvars
- Apply Terraform to Deploy Azure Container Registry
Step 2: Manually Build and Push the Docker Image
Step 3: Deploy to Azure Container Instances (ACI) Using Terraform
Step 4: Apply Terraform and Deploy
Step 5: Access Your Application
Troubleshooting Tips
Conclusion

Step 1: Set Up Azure Container Registry (ACR)

To get started, we first need to create an Azure Container Registry (ACR), which will store our Docker images before deploying them to Azure Container Instances (ACI).

In your Terraform configuration, create the following resources:

main.tf (Terraform Configuration)

This creates:

rg-theodora-container: The resource group in Azure.
hostcr2025: The Azure Container Registry where we will push our Docker image.

set up variables.tf

Create terraform.tfvars

Apply Terraform to Deploy Azure Container Registry

Once your main.tf, variables.tf, and terraform.tfvars files are ready, use the following commands to deploy your Azure resources:

Initializes Terraform, downloads the required providers (like AzureRM), and prepares your workspace.

Checks that all Terraform files are syntactically correct and the configuration is valid.

Generates and shows an execution plan, detailing what Terraform will create, modify, or destroy.

Executes the deployment based on your plan.
When prompted, type yes to confirm and start creating the Azure resources.

Step 2: Manually Build and Push the Docker Image

Now that we have our ACR setup, we need to manually build the Docker image and push it to ACR.

Dockerfile

Here’s the Dockerfile for a basic Node.js application:

This Dockerfile:

Starts from a Node.js base image.
Installs dependencies.
Runs the app using serve on port 3000.

Manually Build and Push Docker Image

To build and push the Docker image to ACR manually, follow these steps:

Login to ACR:

Build the Docker image:

Push the Docker image to ACR:

This step ensures that your Docker image is available in ACR, and Terraform can reference it during the deployment to Azure Container Instances (ACI).

Step 3: Deploy Docker Image to Azure Container Instances (ACI) with Terraform

Now that the Docker image is in ACR, we’ll use Terraform to deploy the container to Azure Container Instances (ACI).

Create your ACI.tf with the following configuration to deploy the image:

Terraform Configuration for ACI Deployment

This configuration:

Uses the image we pushed to ACR (hostcr2025.azurecr.io/electrot:v1).
Exposes port 3000 (matching the app’s internal port).
Creates a public IP and a DNS label (theocontainer2025) for external access.

Step 4: Apply Terraform to Deploy the Container

Now that everything is set up, we’ll use Terraform to deploy the container.
Follow the terraform deployment process above

Step 5: Access Your Application

After deploying the container to Azure Container Instances (ACI), you should be able to access your application.

DNS Name: http://theocontainer2025.eastus.azurecontainer.io:3000
Public IP: You can also access the app using the public IP address of your ACI container.

For example, the public IP can be retrieved using this Azure CLI command:

Troubleshooting Tips

Inaccessible Image: If you encounter the InaccessibleImage error, it typically means there’s an issue with image permissions in ACR. Double-check that the image exists in ACR and that ACI has the correct credentials to pull the image.
Port Binding: Ensure that your application is listening to the right port.
Container Logs: You can check the logs of your container to make sure it's running correctly using:

Conclusion

In this tutorial, we:

Set up an Azure Container Registry (ACR) using Terraform.
Manually built and pushed the Docker image to ACR.
Used Terraform to deploy the image to Azure Container Instances (ACI).
Exposed the application via public IP and DNS for external access.

While the manual Docker build and push process can seem tedious, it gives you full control and debugging capabilities, especially when things don’t work perfectly with automation. Using Terraform for deployment makes managing and automating the infrastructure side seamless.

Creating and Deploying a Custom Docker Image with Azure Container Registry and Azure Container Instances

Theodora — Mon, 20 Oct 2025 21:49:43 +0000

Table of Contents

Prerequisites
Step 1: Create a Simple Dockerfile and Shell Script
Step 2: Build the Docker Image
Step 3: Set Up Azure Container Registry
Step 4: Push Docker Image to ACR
Step 5: Deploy to Azure Container Instances
Common Errors and Fixes
Final Checks

Prerequisites

Make sure you have the following installed:

✔️ An Azure account (you can create one for free)
✔️ Azure CLI
✔️ Docker Desktop
✔️ A terminal or PowerShell window

Step 1: Create a Simple Dockerfile and Shell Script

Create a new directory, then inside it:

This is a minimal Dockerfile using the nginx base image and a custom shell script.

`FROM nginx:latest`

This tells Docker to use the latest version of the official nginx image from Docker Hub as the base image.

The base image already includes Nginx installed and configured.
It's lightweight and typically used for serving web content.

`ARG VERSION`

This declares a build-time argument named VERSION.

ARG is only available during the image build process.
You can pass it using -build-arg like this:

docker build --build-arg VERSION=1.2.3
### ENV VERSION=$VERSION

This sets an environment variable inside the container using the value passed during build time.

ENV is available at runtime — your script or Nginx can access it.
You can verify it with: echo $VERSION

`COPY hostname.sh .`

This copies the hostname.sh script from your local directory into the image's working directory (which is / by default unless changed).

If you want it in a specific directory like /usr/local/bin, you should write: COPY hostname.sh /usr/local/bin/

`CMD ["/hostname.sh"]`

This sets the default command that runs when the container starts.

It overrides Nginx’s default command.
So instead of starting Nginx, the container will run the hostname.sh script.

Note If the script isn't executable or doesn't start with a shebang (#!/bin/bash or similar), the container will fail.

This Dockerfile creates a container that:

Uses the latest Nginx image.
Accepts a version number at build time.
Sets that version as an environment variable.
Copies a script called hostname.sh into the container.
Runs that script instead of Nginx when the container starts

Script Breakdown: hostname.sh

`#!/bin/sh`

This line tells the system to use the sh shell to run the script.

`HOSTNAME=\`hostname``

Runs the hostname command, capturing the machine/container name.
Stores it in the variable HOSTNAME.

`VERSION=${VERSION:-v1}`

Reads the VERSION environment variable if it’s set.
If not, it defaults to v1.

Creates a landing HTML page for the root of the Nginx server:

cat > /usr/share/nginx/html/index.html <<EOF
...
EOF

This file will be served when someone visits / in the browser.
It includes:
- Writes an HTML file directly to the default Nginx directory.
- The hostname (of the container or VM)
- The version number

`mkdir /usr/share/nginx/html/healthz /usr/share/nginx/html/hostname /usr/share/nginx/html/version`

Creates 3 subdirectories inside Nginx's web root:
- /healthz – for liveness/readiness checks
- /hostname – for showing the container’s hostname and version
- /version – for showing the version only

Writes mini HTML/text responses to each endpoint:
cat > /usr/share/nginx/html/hostname/index.html <<EOF
$HOSTNAME -- $VERSION
EOF

Shows: hostname -- version
Endpoint: /hostname

cat > /usr/share/nginx/html/version/index.html <<EOF
$VERSION
EOF

Endpoint: /version
Shows: version only

chmod 777 /usr/share/nginx/html/healthz
cat > /usr/share/nginx/html/healthz/index.html <<EOF
healthy
EOF

Grants all permissions to /healthz directory (not ideal for production, but okay for dev/demo).
Writes a file that says healthy to /healthz/index.html
This is useful for Kubernetes or Docker health checks.

`nginx -g "daemon off;"`

Starts Nginx in foreground mode (so the container doesn't exit).
This is required in Docker — if the main process exits, the container stops.

When this script runs inside a Docker container, it:

If you access the container in a browser (or curl):

/ → HTML page showing the hostname and version
/healthz → returns healthy
/hostname → returns hostname -- version
/version → returns the version string

Step 2: Build the Docker Image

Open PowerShell in the folder and run:

Output

Step 3: Set Up Azure Container Registry

In the Azure Portal:

Search for Container Registry
Click Create
Choose a name (mine was hostcr)
Set the resource group, region, SKU, etc.
Enable Admin User under Access Keys after creation

Step 4: Push Docker Image to ACR

1.Authenticate with Azure:

Tag Your Docker Image

Output

Push the Image to ACR

Output

boops-I lost my screenshot of the Azure intercae for this

Step 5: Deploy to Azure Container Instances

In the Azure portal, search for Container Instances
Click Create
Fill in:
- Name
- Resource Group
- Image source: Azure Container Registry
- Image: hostcr.azurecr.io/hostname:v1
Review and create

Common Errors and Fixes

❌ `docker push` returns "authentication required"

Fix: Make sure you're logged into ACR:

❌ `az login` fails due to tenant mismatch

Fix: Use the right tenant ID explicitly:

✅ Final Checks

Go to your deployed Container Instance
Copy the public IP
Visit in browser:

You should see HTML responses with hostname, version, and health check status.

Getting Started with Docker Compose: A Hands-On Guide to Multi-Container Applications

Theodora — Fri, 10 Oct 2025 22:39:23 +0000

If you’ve been working with Docker, you’ve probably been dealing with single-container applications. However, when your applications become more complex, you may need to run multiple services, such as databases, message queues, or caches. The question is: Do you install everything in a single container, or do you run multiple containers? And if you run multiple containers, how do you connect them together?

In this blog post, we’ll explore how Docker Compose makes managing multi-container applications easy. We’ll work with a simple to-do list app built with Node.js and MySQL to demonstrate how Docker Compose can manage your containers, network, and persistent data, all in a single YAML file.

Why Use Docker Compose?
Prerequisites
Lab 1: Setting Up the Application
Lab 2: Starting the Application
Lab 3: Accessing the Application
Tearing Down the Application
Conclusion

Why Use Docker Compose?

One of the key best practices for containers is that each container should do one thing and do it well. When your project grows, running everything inside a single container can quickly become a mess. Imagine running a database, an application server, and a message queue all in one container,it’s not scalable, maintainable, or efficient.

Docker Compose solves this problem by allowing you to define multiple containers and their configurations in a single file, called a docker-compose.yml. This file allows you to:

Define all services in one place.
Automate network setup for your containers.
Persist data across container restarts using volumes.
Manage environments with environment variables.
Rebuild containers when changes are made using a simple command.

Docker Compose is declarative. You define what you need, and when you run docker-compose up, Docker Compose ensures your environment is built correctly.

Prerequisites

Before you begin, make sure you have the following installed:

Docker Desktop: Install it from the official Docker website for your operating system.
Git: To clone the application repository.

Lab 1: Setting Up the Application

Let’s begin by setting up the sample application.

1. Clone the Sample Application

First, open your terminal and clone the application repository:

2. Explore the Compose File

Inside the todo-list-app directory, you’ll find a file named docker-compose.yml (also called the Compose file). This YAML file defines all the services that make up your application, their configurations, and how they connect.

3. Overview of the Docker Compose File

The docker-compose.yml file includes the following key sections:

services: Defines the individual containers (e.g., app, mysql).
networks: Specifies how services communicate.
volumes: Persists data, especially for databases, even when containers are stopped.
environment variables: Provides configuration data to containers.

Lab 2: Starting the Application

Now, let’s start the application with Docker Compose.

1. Run the Application Using Docker Compose

Run the following command to start the application in detached mode (-d) and build the services:

What happened?

Docker pulled the Node.js and MySQL images from Docker Hub.
A new network was created for the application to allow communication between the containers.
A volume was created to persist MySQL data.
Two containers, todo-list-app-app-1 (Node.js app) and todo-list-app-mysql-1 (MySQL), were started.

Lab 3: Accessing the Application

Once everything is up and running, you can access your to-do list app in your browser.

1. Access the Frontend

In your browser, visit:

or on docker desktop, click

2. View the Containers in Docker Desktop

You can also use Docker Desktop to monitor your containers and their configurations. Open Docker Desktop and navigate to the Containers tab to see the todo-list-app-app-1 and todo-list-app-mysql-1 containers.

Tearing Down the Application

When you're done with the application, it’s easy to tear everything down using Docker Compose.

1. Stop the Containers

To stop all running containers and remove them, run:

Expected Output:

2. Remove Volumes (Optional)

By default, volumes are not removed when tearing down the application to allow you to retain your data. If you want to remove the volumes as well, run:

Expected Output:

Conclusion

In this hands-on guide, you learned how to use Docker Compose to define, build, and run a multi-container application. We explored how to:

Set up and configure services using docker-compose.yml.
Start the app and view it in your browser.
Easily tear down the app when done.

Docker Compose makes it easy to work with multiple containers, saving time and effort when managing complex applications. This workflow is essential for modern development, and now you’re equipped to run your own multi-container Docker applications.

How to Build, Tag, and Push Docker Images to Docker Hub

Theodora — Fri, 10 Oct 2025 21:39:51 +0000

In this blog, we’ll walk through the process of building, tagging, and pushing a Docker image to Docker Hub. We will also troubleshoot some common errors encountered during this process.

Lab 1: Building the Docker Image
Lab 2: Tagging the Docker Image
Lab 3: Pushing the Image to Docker Hub
Troubleshooting Common Errors
Conclusion

Lab 1: Building the Docker Image

Build the Image

In this first step, we are building the Docker image from a Dockerfile in the Electro project folder. The -t flag is used to tag the image with a version name.

Run the following command in your PowerShell or terminal:

Output:

Lab 2: Tagging the Docker Image

Now that the image is built, it’s time to tag it properly to push it to Docker Hub.

The image we built locally is electro:v1. We now need to tag it for our Docker Hub repository under the username theodora22. Here’s the command to tag the image:

Output:

You should not see any output after running this command, which means the image has been tagged successfully. You can verify the tagging by running:

Example Output:

Note Remember to create a repository first on docker hub before tagging the docker image.

Lab 3: Pushing the Image to Docker Hub

Now, let’s push the tagged image to Docker Hub.

Run the following command to push the image to your Docker Hub repository:

Expected Output:

Troubleshooting Common Errors

Error: Tag does not exist

This error occurs if the image isn’t tagged correctly or hasn’t been built yet. Ensure the image exists locally by checking with:

Then tag the image correctly:

And retry pushing.

Conclusion

In this lab, we learned how to:

Build a Docker image using a Dockerfile.
Tag the image appropriately to push it to Docker Hub.
Push the image to Docker Hub, making it available to others or for use in production.

Docker simplifies the process of building and deploying applications across various environments.

Build and Run Your First Container

Theodora — Mon, 29 Sep 2025 04:54:47 +0000

Containerization has changed how software is developed, deployed, and managed. Docker allows developers to package applications with all dependencies into portable containers. This blog shows hands-on experience with Docker, from installation to running a frontend app.

Lab 1: Installing Docker
Lab 2: Running Your First Container
Step 1: Clone Sample Application
Step 2: Explore the Dockerfile
Step 3: Build the Docker Image
Step 4: Run the Container
Step 5: Access the application
Step 6: Stop the Container
Summary

Lab 1: Installing Docker

Download Docker Desktop

Docker Desktop includes the Docker Engine, CLI, and Docker Compose, providing everything you need to build and run containers locally.
Go to the https://www.docker.com/
and download Docker Desktop for your operating system.

Run the installer and follow the on-screen instructions for your platform. After installation, restart your computer if required.

This process sets up Docker’s core components and ensures that your system is ready to manage containers.

Verify Installation

Output

These commands confirm that Docker and Docker Compose are installed and ready to use.

Lab 2: Running Your First Container

This step verifies that Docker can pull images from Docker Hub and run them as containers on your system.

Run a simple test container:

Expected Output:
Docker will download a small test image and display a success message.

Step 1: Clone Sample Application

Cloning the repository gives you all the source code and the Dockerfile needed to build your containerized application.

Clone the sample application repository:

Step 2: Explore the Dockerfile

The Dockerfile acts as a blueprint that tells Docker how to set up your container consistently.
The Dockerfile defines the environment for your app:
Base image: node:22-alpine

Working directory: /app

Copy application files and install dependencies

Build the app and remove unnecessary files

Expose port 3000 and serve the app using serve -s build

Step 3: Build the Docker Image

Building an image packages your app and all its dependencies into a single, portable unit that can run anywhere Docker is installed.

Build the Docker image using:

Expected Output

Step 4: Run the Container

Running a container launches your application in an isolated environment. Port 3000 is mapped so you can access the app from your browser.

Run your image as a container:

Optionally

In Docker Desktop, go to the Images tab.

Next to your image, select Run.

Expand the Optional settings.

In Host port, specify 8089

Select Run.

Step 5: Access the Application

This confirms that your containerized application is running correctly and accessible locally.

Open a browser and go to:

Optionally

Select the link next to your container in Docker Desktop to access the application.

Step 6: Stop the Container

Stopping the container frees system resources. docker ps shows which containers are currently running.

List running containers and stop yours

Optionally

To stop the container in Docker Desktop, go to the Containers tab and select the Stop icon in the Actions column of your container.

Summary

In this lab, you learned how to install Docker, build a container, and run it locally. You now understand how Docker packages applications and their dependencies, making them portable and consistent across environments.

Using SSH Keys on Windows: Fixing “Unprotected Private Key File” Errors

Theodora — Sun, 31 Aug 2025 09:18:51 +0000

When you use SSH to connect to an EC2 instance, the client checks the permissions on your private key file (.pem).

On Linux/macOS, this is enforced with chmod 400 (file is only readable by the owner).

On Windows with OpenSSH, the same check is enforced via NTFS file permissions (ACLs).

If the file is accessible to other groups like Authenticated Users, Users, or Everyone, SSH will refuse to use it and you’ll see:

The core concept

A private key must be owned by you and only readable by you.

On Windows, this is controlled by ACLs (Access Control Lists), not chmod.

To fix the issue, you must take ownership of the file and restrict its ACLs so only your account (plus SYSTEM/Administrators) can read it.

Step 1: Take ownership

If you downloaded or copied the file from another system, ownership may not match your account.

takeown /F "D:\3-tier-web-arch\nfs-key.pem"

Step 2: Remove inheritance

Prevent the file from inheriting broad permissions from the folder.

icacls "D:\3-tier-web-arch\nfs-key.pem" /inheritance:r

Step 3: Remove broad groups

Remove default Windows groups that make the file accessible to others

icacls "D:\3-tier-web-arch\nfs-key.pem" /remove:g "Authenticated Users" "Users" "Everyone"

Step 4: Grant only necessary access

Give your account read permission, and (optionally) keep SYSTEM and Administrators with full control

icacls "D:\3-tier-web-arch\nfs-key.pem" /grant "DESKTOP-ABCD\Amanda:(R)"
icacls "D:\3-tier-web-arch\nfs-key.pem" /grant "NT AUTHORITY\SYSTEM:(F)" "BUILTIN\Administrators:(F)"

If you want to do this in one clean command

icacls "D:\3-tier-web-arch\nfs-key.pem" /inheritance:r /grant:r `
"DESKTOP-ABCD\Amanda:(R)" "NT AUTHORITY\SYSTEM:(F)" "BUILTIN\Administrators:(F)"

Step 5: Verify

icacls "D:\3-tier-web-arch\nfs-key.pem"

Expected output

DESKTOP-ABCD\Amanda:(R)
BUILTIN\Administrators:(F)
NT AUTHORITY\SYSTEM:(F)

Step 6:Connect to EC2

Now you can connect
ssh -i "D:\3-tier-web-arch\nfs-key.pem" ec2-user@

Best practice is to Store keys in ~.ssh

For convenience, place the key in your .ssh folder
mkdir "$env:USERPROFILE.ssh" -Force
copy "D:\3-tier-web-arch\nfs-key.pem" "$env:USERPROFILE.ssh\nfs-key.pem"

Then create a config file (~/.ssh/config) so you can connect with just

ssh my-ec2

SSH enforces strict private key security. On Windows, that means taking ownership of the PEM file and restricting its ACLs so only you (and optionally SYSTEM/Administrators) can read it. This is the Windows equivalent of chmod 400 on Linux.

Note- Run commands on Powershell as Administrator and then connect to EC2 Instance on VScode powershell Terminal or powershell on windows.

How to Host a Static Website on Azure Blob Storage

Theodora — Sat, 17 May 2025 13:25:02 +0000

Hosting a static website on Azure Blob Storage is a simple, cost-effective way to make your web content accessible globally. In this tutorial, I'll show you how to deploy a static website using Azure Blob Storage, starting with a sample website I downloaded and edited using VS Code.

Prerequisites
Prepare Your Static Website
Create an Azure Storage Account
Enable Static Website Hosting
Upload Website Files
Access Your Website
Troubleshooting Tips
Conclusion

Prerequisites

Before we get started, make sure you have:

An active Azure account.

Visual Studio Code installed.

A sample static website ready to deploy.

Firstly, you download the sample static website from Luther, unzip the file, and saved it to a preferred location on your local machine.

Prepare Your Static Website

Using VS Code, open the sample website files and make the necessary edits on index.html.

Edit the White parts like name and intro and then Save.

Run the website by selecting Run without debugging in VS Code to open the website in your browser and verify the content. Once you’re satisfied, we’ll proceed to deploy the site to Azure.

Make sure your website works locally before deploying it on Azure

Create an Azure Storage Account

Click Create a resource > Storage > Storage account.

Fill in the required fields: subscription, resource group, storage account name, region, etc.

Review and create the storage account.

Fill in the Basics tab

Enable Static Website Hosting

Once the storage account is created:

Navigate to your storage account by going to resource.

In the left sidebar, under Settings, select Static website or on the right side under capabilities.

Enable Static website hosting.

Specify your index document name (index.html) and error document path (error.html).

Save your changes.

Azure will automatically create a $web container to store your website files.

Type in index.html — This is the main page of your website.

Type in error.html — This page will be displayed if a user tries to access a URL that doesn’t exist on your site.**

Copy the Primary endpoint URL and open it in your browser. At this point, you won’t see any website content because the files haven’t been uploaded yet. Next, we’ll upload our web files to Azure to make the site live

Upload Website Files

Next, upload your local website files to the $web container:

In your storage account, go to Containers.

Open the $web container.

Click Upload and select all your website files and folders (e.g., index.html, error.html, CSS files, images).

Upload them to Azure.

Access Your Website

After uploading, go back to the Static website page in the Azure Portal.

Copy the Primary endpoint URL and paste it into your browser.

Your static website should now be live and accessible from anywhere in the world!

Example URL format:
https://portfoliowebsite123.z13.web.core.windows.net/index.html

Now everyone can see it, Bingo!!!!!

Troubleshooting Tips

No content showing? Ensure your files are correctly uploaded in the $web container.

Page not found errors? Check your index and error document names in the static website settings.

File paths broken? Make sure all relative links in your HTML files are correct.

Cache issues? Try clearing your browser cache or open the page in an incognito window.

Conclusion

Hosting static websites on Azure Blob Storage is fast, affordable, and scalable. By following these steps, you can quickly get your site online without managing a web server.

Creating and Connecting to a Linux Virtual Machine Scale Set (VMSS) on Azure

Theodora — Tue, 06 May 2025 23:48:41 +0000

Azure Virtual Machine Scale Sets (VMSS) are a great solution for managing and scaling a large number of identical virtual machines in Azure. With VMSS, you can automatically scale your infrastructure based on demand, ensuring high availability and load balancing for your applications. In this guide, we'll go through the steps to create a Linux VMSS, configure it, and connect to the individual instances using SSH.

What is a Virtual Machine Scale Set (VMSS)?
Create a Linux VMSS in Azure
Generate SSH Keys
Connect to an Instance in the VMSS Using SSH
Scaling and Load Balancing
Troubleshooting
Spot VMs: Cost-effective but Preemptible

What is a Virtual Machine Scale Set (VMSS)?

A Virtual Machine Scale Set is an Azure resource that allows you to deploy and manage a set of identical virtual machines. VMSS makes it easier to:

Automatically scale VM instances up or down based on load.

Ensure high availability across multiple availability zones.

Simplify management by handling updates and upgrades to multiple VMs at once.

With VMSS, you can quickly set up a fleet of identical VMs that are load-balanced and auto-scalable, which is perfect for web applications and services that need to scale dynamically.

Create a Linux VMSS in Azure

Let’s walk through the steps of creating a Linux Virtual Machine Scale Set in Azure.

Step 1: Log in to Azure Portal

First, log in to the Azure Portal with your Microsoft account.

Step 2: Create a Virtual Machine Scale Set

In the Azure Portal, click “Create a resource” from the sidebar.

Search for Virtual Machine Scale Set.

Click Create to start the setup process.

Step 3: Configure the Basic Settings

In the Basics tab:

Subscription: Select your subscription.

Resource Group: Create a new one or select an existing group.

Region: Choose the region where you want to deploy the scale set (e.g., East US).

VMSS Name: Name your VMSS (e.g., MyLinuxVMSS).

Availability zone: You can choose none or any zone you want

Orchestration mode: Uniform- This means Azure will automatically create and manage identical virtual machines for you, based on a single configuration. It's easier to use and perfect when you want all VMs to be the same.

Security type: Standard

Scaling options- Manual, also configure scaling options to enable predictive auto scaling. It doesn’t make any scaling changes—it just helps you visualize what auto scaling might look like in the future. Scale-In Policy-Choose how Azure decides which VM instances to delete first when scaling in (reducing the number of VMs).
You can prioritize based on the newest, oldest, or custom rules.

Image: Choose Ubuntu 20.04 LTS (or any other Linux distribution you prefer).

Instance Size: Choose an appropriate size (e.g., Standard B1ms for testing).

Instance count:2 or any size you want

Authentication Type: Choose SSH public key.

Username: Create a user (e.g., azureuser).

SSH Public Key: You’ll add this later after generating the key pair.

Step 4: Configure the Disk Settings

In the Disks tab:

OS Disk Type: Choose Standard SSD or Premium SSD, depending on your requirements.

Data Disks: You can also add data disks if your VMSS requires additional storage.

Leave everything at default

Step 5: Configure the VMSS Networking

In the Networking tab:

Virtual Network: Select Default or create a new network.

Subnet: Select Default or create a new subnet.

Network Interface Card (NIC): Make sure to set your NIC properly to connect the VM instances to the network.

Public IP: Choose Enabled to ensure each VM instance has a public IP for external access.

Allow selected ports: Make sure to allow SSH (port 22) for secure access and HTTP (port 80) for web traffic.

This ensures that SSH connections to manage your VMs and HTTP traffic for the web server are allowed.

Load Balancer:

Choose Azure Load Balancer to distribute traffic evenly across all VM instances for better performance and availability.

Click Create a new load balancer, give it a name (e.g., MyVMSSLoadBalancer).

Set the IP type to Public.

Choose TCP for Protocol to handle traffic.

Click Create to set up the load balancer.

This will ensure that incoming traffic is distributed evenly to your VM instances, improving your application’s scalability and reliability.

Step 6: Review + Create

Review the configuration and click Create to deploy the Virtual Machine Scale Set. Azure will start the deployment, and it will take a few minutes to set up the resources.

Go to Instances and view your two virtual machines

Connect to an Instance in the VMSS Using SSH

Now that the scale set is deployed, let’s connect to an instance using SSH.

Step 1: Find the Public IP Address of Your VMSS

Under Instances, you’ll see a list of your VM instances.

Find the Public IP address of one of the instances.

Step 2: SSH into the Instance

Use the following SSH command to connect to the instance.

ssh -i ~/.ssh/myVMSSKey azureuser@

To connect to all instances within the Virtual Machine Scale Set (VMSS), you can use the frontend IP address of the load balancer. This ensures that traffic is evenly distributed across all VM instances in the scale set.

Use the following SSH command to connect to all instances.
ssh -i C:\Users\hp\Downloads\MyLinuxVMSS_key.pem azureuser@20.169.225.135 -p 50000

Extra

Autoscaling
You can enable autoscaling to automatically adjust the number of VM instances based on CPU usage, memory usage, or other metrics.

Spot VMs: Cost-effective but Preemptible

Spot VMs are preemptible virtual machines that offer significant cost savings compared to regular VMs in Azure. However, they come with a risk: they can be terminated by Azure when there is high demand for capacity. Spot VMs are ideal for workloads that are flexible and can tolerate interruptions.

Key Features of Spot VMs:
Cost-effective: Up to 90% cheaper than regular VMs.

Interruptible: Azure can terminate these VMs with little notice when resources are in high demand.

Best for flexible workloads: Suitable for jobs like batch processing or testing, where occasional interruptions are acceptable.

By leveraging Spot VMs, you can save significantly on Azure compute costs, but it's important to plan workloads that can tolerate interruptions and be terminated without affecting your overall application.

Mastering Azure: Core Architectural Components Explained

Theodora — Sat, 19 Apr 2025 16:59:14 +0000

Microsoft Azure is one of the leading cloud platforms, providing businesses with a wide range of services to build, manage, and deploy applications on a global scale. Azure’s architecture is designed to offer flexibility, scalability, security, and high availability. Understanding the core components of Azure’s architecture is essential for designing and implementing efficient cloud-based solutions.

This guide explores the eight core architectural components of Azure, including compute, storage, networking, identity, and monitoring — giving you the foundation to build secure, high-performing applications on Azure.

Azure Regions and Availability Zones
Compute Services
- Azure Virtual Machines
- Azure App Service
- Azure Kubernetes Service
- Azure Functions
Storage Services
- Azure Blob Storage
- Azure Files
- Azure Disk Storage
- Azure Table Storage
Networking
- Azure Virtual Network
- Azure Load Balancer
- Azure ExpressRoute
Identity and Access Management
- Azure Active Directory
- Role-Based Access Control
Monitoring and Management
- Azure Monitor
- Azure Application Insights
Security and Compliance
- Azure Security Center
- Azure Key Vault
Databases
- Azure SQL Database
- Cosmos DB
Conclusion

Azure Regions and Availability Zones

Azure’s global infrastructure is organized into regions and availability zones to provide high availability, fault tolerance, and redundancy.

Azure Regions

A region is a geographical area containing a set of data centers.
Azure currently operates in over 60 regions across the globe, making it one of the most widely available cloud platforms.
Each region is strategically located to meet compliance and data residency requirements.

Availability Zones

Availability zones are physically separated data centers within a region.
Each zone has its own power, cooling, and networking to prevent failures from affecting all zones.
Deploying resources across multiple availability zones ensures redundancy and disaster recovery.

Compute Services

Azure provides a range of compute options to run applications and services at scale.

Azure Virtual Machines

On-demand, scalable compute resources that allow you to run Windows and Linux-based workloads.
Support for different machine sizes based on CPU, memory, and storage requirements.
VMs can be configured for high availability by deploying them across availability zones.

Azure App Service

A fully managed platform for building and hosting web apps, RESTful APIs, and mobile backends.
Supports multiple programming languages such as .NET, Java, Node.js, Python, and PHP.

Azure Kubernetes Service

Fully managed Kubernetes service that allows you to deploy and manage containerized applications.
Supports scaling, monitoring, and orchestration of containers.

Azure Functions

Serverless compute service that allows you to execute code in response to events without managing infrastructure.
Ideal for event-driven applications and background processing.

How to Create and Connect to a Linux VM Using a Public Key

Theodora — Sat, 19 Apr 2025 15:48:09 +0000

How to Create and Connect to a Linux VM Using a Public Key

Creating a Linux Virtual Machine (VM) and connecting to it via SSH using a public key is a secure and efficient method for managing cloud-based systems. This guide walks you through the entire process of creating a Linux VM in Azure and securely connecting to it using SSH keys.

Create a Linux VM in Azure
Generate SSH Private Key
Connect to the Linux VM Using SSH
Update the Server and Install a Web Server (Nginx)
Troubleshooting
Conclusion

Create a Linux VM in Azure

Before you can connect to a Linux VM using SSH, you need to create it. Follow the steps below to create the VM in Azure.

Step 1: Log in to Azure Portal

Open the Azure Portal and sign in with your Microsoft account.

Step 2: Create a Virtual Machine

In the Azure Portal, click on "Create a resource" in the left sidebar.
Click Create to start the VM creation process.

Fill Out the Basics Tab

Subscription: Select your subscription

Resource Group: Create a new one or use an existing one

VM Name: e.g., LinuxVM

Region: Choose the closest location

Availability options- No Infrastructure redundancy as i am not replicating the vm

Security - Standard

Image: Any Ubuntu distribution that you want

Size: e.g., Standard B1s (suitable for testing) or any size

Authentication Type: Select SSH public key

Username: e.g., azureuser

SSH Public Key: Generate new key pair

Inbound port rules- Allow selected ports and select SSH(22) and HTTP(80). Open port 80 to access the IP address on a browser as a simple web server will be installed.

Configure the Disks Tab

OS disk type: Choose Standard SSD or Premium SSD depending on your needs

Leave other options at default unless you have specific disk encryption or backup requirements

Configure the Networking Tab

Virtual Network: Use default or create a new one

Subnet: Leave as default

Public IP: Enabled

NIC network security group: Choose Basic

Select inbound ports:
SSH (port 22) – to connect to the VM
HTTP (port 80) – to access a web server via browser

Generate SSH private Key

Click Review + Create
Azure will validate the configuration

Click Download private key and the deployment will start

Connect to the Linux VM Using SSH

click on connect
we will connect to this VM using our public IP address and admin user name

Go to your terminal(Windows PowerShell) and run the SSH command to connect to the Linux VM.
ssh -i "/path/to/your_downloaded_key.pem" azureuser@your-vm-ip-address
Explanation:
ssh: The secure shell command used to connect to remote servers.

-i "/path/to/your_downloaded_key.pem": Specifies the path to your private key file (downloaded from Azure).

azureuser: This is the username you set when creating the VM.

your-vm-ip-address: Replace this with the public IP address of your VM (you can find it in the Azure Portal).

Update the Server and Install a Web Server (Nginx)

Now that you're connected to your VM, it's time to update the system and install a basic web server. We’ll use Nginx, a lightweight and fast web server ideal for serving static websites.

Step 1: Update Your Server

Run the following commands to update the package list and install any available upgrades:
sudo apt update
sudo apt upgrade -y

Step 2: Install Nginx

Once the system is updated, install the Nginx web server:
sudo apt install nginx -y

Step3 :Access Your Web Server in a Browser

Open your browser and visit:
http://
You should see the default Nginx welcome page.

Troubleshooting

If you encounter issues:

✅ NSG Inbound Rules: Ensure port 22 and port 80 are open

✅ Correct IP: Use the public IP from Azure

✅ File Permissions: Confirm private key permission if necessary

chmod 600 ~/.ssh/myLinuxKey

✅ SSH Key Format: Ensure the entire public key was pasted correctly

Conclusion

Congratulations! You’ve successfully:

Created a Linux VM in Azure

Configured it for SSH access using a public key

Enabled web traffic via port 80 for web server deployment

You're now ready to install your favorite web server and start developing or deploying apps securely.

Forem: Theodora

Git, GitHub, and EC2: A Practical Walkthrough from Local Repo to Live Deployment

Initializing the Project and Git Repository

Configuring Git Identity (Local vs Global)

Local (Repo-Specific) Identity

Global Identity

Verifying Repository State Before Working

Creating Project Files

Adding Starter Content

Tracking and Staging Files

Creating the First Commit

Making a Controlled Change

Deploying to EC2 with Nginx

SSH into the Server

Copy Files from Local Machine

Branching Workflow: Adding a Contact Page

Verifying Branch Isolation

Merging the Feature Branch.

Inspecting Commit History

GitHub Collaboration: Forks and Pull Requests

Creating a Pull Request to Upstream

Verify Your Branch Is Pushed

Open the Pull Request on GitHub

Confirm PR Target Settings

Add a Clear PR Title and Description

Create the Pull Request

Why This Step Matters in Practice

Final Thought

Deploying a Real React App on an Ubuntu VM with AWS and Serving It with Nginx

Overview

What You’ll Need

Step 0: Launch an Ubuntu Server on AWS EC2 and Connect via SSH

0.1 Launch the EC2 Instance

0.2 Retrieve the Public IP Address

0.3 Connect to the Server via SSH

Step 1: Update the System

Step 2: Install Node.js and npm

Step 3: Install and Start Nginx

Step 4: Clone the React Application Repository

Step 5: Modify the React Application

Step 6: Install Dependencies and Build the Application

Step 7: Serve the React App via Nginx

Step 8: Configure Nginx for a React Single-Page Application

Step 9: Test the Deployment

Deploying a Dockerized Web Application to Azure Using Terraform (Manual Docker Build and Push)

Prerequisites

Step 1: Set Up Azure Container Registry (ACR)

main.tf (Terraform Configuration)

set up variables.tf

Create terraform.tfvars

Apply Terraform to Deploy Azure Container Registry

Step 2: Manually Build and Push the Docker Image

Dockerfile

Step 3: Deploy Docker Image to Azure Container Instances (ACI) with Terraform

Terraform Configuration for ACI Deployment

Step 4: Apply Terraform to Deploy the Container

Step 5: Access Your Application

Troubleshooting Tips

Conclusion

Creating and Deploying a Custom Docker Image with Azure Container Registry and Azure Container Instances

Prerequisites

Step 1: Create a Simple Dockerfile and Shell Script

FROM nginx:latest

ARG VERSION

COPY hostname.sh .

CMD ["/hostname.sh"]

Script Breakdown: hostname.sh

#!/bin/sh

HOSTNAME=\hostname``

VERSION=${VERSION:-v1}

mkdir /usr/share/nginx/html/healthz /usr/share/nginx/html/hostname /usr/share/nginx/html/version

nginx -g "daemon off;"

Step 2: Build the Docker Image

Step 3: Set Up Azure Container Registry

Step 4: Push Docker Image to ACR

Step 5: Deploy to Azure Container Instances

Common Errors and Fixes

❌ docker push returns "authentication required"

❌ az login fails due to tenant mismatch

✅ Final Checks

`FROM nginx:latest`

`ARG VERSION`

`COPY hostname.sh .`

`CMD ["/hostname.sh"]`

`#!/bin/sh`

`HOSTNAME=\`hostname``

`VERSION=${VERSION:-v1}`

`mkdir /usr/share/nginx/html/healthz /usr/share/nginx/html/hostname /usr/share/nginx/html/version`

`nginx -g "daemon off;"`

❌ `docker push` returns "authentication required"

❌ `az login` fails due to tenant mismatch