Amazon ECS is a fully managed container orchestration service that enables you to run Docker-based applications at scale. It supports multiple launch types, including AWS Fargate — which abstracts away the underlying EC2 infrastructure so you don't have to manage or provision servers yourself.

Core Components of ECS

Cluster

A cluster is the main logical environment managed by AWS that contains all your services, tasks, and capacity providers.

Capacity Providers

Capacity providers define the infrastructure where your containers run. ECS supports:

• EC2 — You manage the virtual machines.
• Fargate — Serverless container hosting managed entirely by AWS.

Task Definition

A task definition is like a blueprint for your application. It defines:

• Docker image
• CPU and memory requirements
• Networking
• Environment variables
• Ports and container configurations

Container Image

Your application is packaged into a Docker image and pushed to a container registry such as:

• Amazon Elastic Container Registry (ECR)
• Docker Hub

Task

A task is a running instance of a task definition. It represents one or more running containers.

Service

A service ensures that a specified number of task instances are always running. It also supports:

• Automatic recovery of failed tasks
• Load balancing
• Scaling across multiple instances

Typical ECS Workflow

does:

1. Build your application into a Docker image.
2. Push the image to ECR or Docker Hub.
3. Create a Task Definition using that image.
4. Run Tasks or create a Service in an ECS Cluster.
5. ECS manages deployment, scaling, and availability automatically.

Simple Real-World Analogy

to owning a food delivery business:

• Docker Container = a packed lunch box with everything needed for one meal.
• Task Definition = the recipe/instructions for making the lunch box.
• Task = one prepared lunch box being delivered.
• Cluster = the kitchen area.
• EC2/Fargate = the workers or kitchen machines doing the cooking.
• Service = the manager making sure enough lunch boxes are always available.

References

1. Introduction to Amazon Elastic Container Service (ECS)

2. ECS vs EKS Comparison

Introduction

AWS SAM (Serverless Application Model) is an open-source framework from AWS that helps developers build, test, and deploy serverless applications easily.

It simplifies working with AWS serverless services like:

• AWS Lambda
• API Gateway
• DynamoDB
• Step Functions
• EventBridge

It provides a way to define infrastructure as code (IaC) and manage deployments through the AWS SAM CLI.

AWS SAM mainly has two important parts:

1. SAM Transform Templates
2. AWS SAM CLI

---

1. SAM Transform Templates

AWS SAM templates are infrastructure-as-code templates used to define serverless applications.

SAM templates are built on top of AWS CloudFormation, which means SAM extends CloudFormation by adding serverless-specific resources and simplifying deployment.

Instead of manually creating:

• Lambda functions
• API Gateway endpoints
• Permissions
• Event triggers

we can define everything inside one SAM template.

---

Lambda and Events

A Lambda function cannot work by itself. It needs an event source to trigger it.

Common Lambda triggers:

• API Gateway requests
• S3 uploads
• SNS messages
• SQS messages
• EventBridge events

Inside a SAM template, we define:

• Lambda function
• Event source that triggers the Lambda function

This makes managing serverless applications easier.

---

AWS SAM Serverless Resource Types

AWS SAM provides 8 main serverless resource types:

AWS::Serverless::Function

Creates Lambda functions.

AWS::Serverless::API

Creates REST APIs using API Gateway.

AWS::Serverless::HttpApi

Creates HTTP APIs using API Gateway.

AWS::Serverless::SimpleTable

Creates DynamoDB tables.

AWS::Serverless::LayerVersion

Creates Lambda layers.

AWS::Serverless::Application

Allows reuse of serverless applications.

AWS::Serverless::StateMachine

Creates AWS Step Functions workflows.

AWS::Serverless::Connector

Creates permissions and connections between resources.

---

Lambda Event Sources Supported by SAM

Lambda functions can be triggered by:

• Amazon S3
• Amazon SNS
• Amazon Kinesis
• Amazon DynamoDB Streams
• Amazon SQS
• API Gateway
• HTTP API
• Scheduled Events
• Amazon Cognito
• Amazon EventBridge

SAM allows these integrations to be defined directly inside the template.

---

2. AWS SAM CLI

AWS SAM CLI is a command-line tool used to:

• Build
• Test
• Debug
• Deploy

serverless applications.

---

AWS SAM Local

SAM Local allows developers to test serverless applications locally before deploying.

It supports:

• Unit testing
• Functional testing
• Debugging

---

Run APIs Locally

Command:

sam local start-api

or

aws sam start-api

This runs API Gateway and Lambda locally.

---

Invoke Lambda Locally

Command:

sam local invoke

This invokes Lambda locally by simulating:

1. A service sending an event
2. Lambda receiving and processing the event

---

Generate Mock Events

Command:

sam local generate-event

Generates sample events from AWS services.

Examples:

• S3 event
• SQS event
• API Gateway event

---

AWS SAM Accelerate

SAM Accelerate improves the development workflow by reducing deployment time.

It includes:

---

SAM Build

Command:

sam build

Features:

• Parallel builds
• Incremental builds
• Temporary layers

SAM build only rebuilds changed resources instead of rebuilding everything.

---

SAM Sync

Command:

sam sync

SAM Sync updates changes quickly without a full deployment.

It is mainly used for development.

It watches changed files and updates AWS resources faster.

---

SAM Logs

Command:

sam logs

Allows developers to view CloudWatch logs from the terminal.

Features:

• Aggregated logs
• Log filtering
• Trace information

---

SAM Deploy Flow

The deployment process:

flowchart LR

    A[Template YAML File<br/>SAM Template] --> B[S3<br/>Upload Lambda Code<br/>and Artifacts]

    A --> C[ECR<br/>Amazon Elastic Container Registry<br/>Upload Container Images]

    B --> D[Create CloudFormation<br/>Change Set]

    C --> D

    D --> E[Deploy to CloudFormation Stack]

    E --> F[AWS Resources Created<br/>Lambda<br/>API Gateway<br/>DynamoDB<br/>Other Serverless Resources]

---

SAM Deploy

Command:

sam deploy

Deploys the serverless application to AWS.

Before deploying:

sam build

SAM packages application artifacts and uploads them to:

• Amazon S3
• Amazon ECR

depending on the application type.

---

AWS SAM Pipeline

AWS SAM provides tools to create CI/CD pipelines for serverless applications.

It automatically generates:

• AWS resources
• Permissions
• Pipeline configuration

---

Pipeline Bootstrap

Command:

sam pipeline bootstrap

Creates AWS environment resources and permissions required for the pipeline.

---

Pipeline Init

Command:

sam pipeline init

Generates pipeline configuration.

Flow:

sam pipeline bootstrap
          |
          ↓
sam pipeline init

---

Serverless Application Repository Patterns

AWS provides reusable serverless patterns.

There are more than 186 AWS SAM patterns available.

These patterns help developers quickly create common architectures.

---

SAM Config File

AWS SAM supports:

samconfig.toml

This file stores default values for SAM commands.

Example:

Instead of repeatedly passing deployment parameters, store them inside the config file.

---

Best Practice: Let SAM Name Your Resources

Avoid manually hardcoding resource names.

Example:

Avoid:

FunctionName: MyApplicationLambda

Allow SAM and CloudFormation to generate resource names.

Benefits:

• Avoid naming conflicts
• Easier deployments
• Better environment management
• Works better with multiple stages

---

APIs play a crucial role in enabling communication between different software systems. Two commonly used API architectures are REST APIs and gRPC APIs. While both facilitate data exchange between clients and servers, they differ in their design, communication patterns, and use cases.

What is a REST API?

REST API (Representational State Transfer API) enables communication between a client and a server over HTTP. It maps HTTP methods to CRUD operations and is one of the most commonly used API styles today.

REST APIs make data and digital resources available through web URLs and allow clients to manipulate those resources using HTTP methods such as GET and POST. Responses are typically returned in structured formats such as JSON, XML, or even images.

Features of REST APIs

• Stateless: REST APIs are stateless, meaning the server does not store client session data. Every request must contain all the information required for the server to process it.
• Client-Server Architecture: The client and server operate independently, promoting a clear separation of concerns.
• Cacheable: Responses can be made cacheable, which helps improve application performance and reduce server load.
• Uniform Interface: REST APIs provide standardized communication through consistent use of URLs and HTTP methods.
• Layered System: REST APIs can operate across multiple layers, allowing for scalable and flexible system architectures.

What is gRPC?

gRPC is a schema-driven, language-agnostic framework for service-to-service communication in distributed environments. It uses the Remote Procedure Call (RPC) protocol and supports streaming as well as strongly typed service contracts through HTTP/2 and Protocol Buffers (Protobuf).

Developers define service contracts and data structures in Protobuf files. These files are then processed by the Protocol Buffers compiler (protoc), which generates client and server code in various programming languages.

gRPC Service Methods

gRPC supports four primary service methods:

• Unary RPC: The client sends a single request and receives a single response.
• Server Streaming RPC: The client sends one request and receives a stream of responses.
• Client Streaming RPC: The client sends a stream of requests and receives a single response.
• Bidirectional Streaming RPC: Both the client and server can exchange streams of messages simultaneously, enabling real-time communication.

REST API vs gRPC API

Although both REST and gRPC use HTTP for data exchange, they follow different architectural approaches:

Feature	REST API	gRPC API
Uses standard HTTP methods	✓	Allows clients to call server functions directly
Typically uses JSON for data formatting	✓	Uses Protobuf for binary data serialization
User-friendly and widely adopted	✓	Optimized for high-performance communication
Commonly used for web applications	✓	Well-suited for microservices
Follows resource-based communication	✓	Supports multiple request and response patterns
Does not natively support bidirectional streaming	✗	Supports real-time, bidirectional communication

Conclusion

REST and gRPC are both powerful approaches to building APIs. REST remains the preferred choice for many web applications because of its simplicity and ease of use. gRPC, on the other hand, is designed for high-performance microservices and applications that require real-time, bidirectional communication. Understanding the strengths of each approach can help developers choose the right technology for their specific requirements.

References

• Postman Blog - What is gRPC?
• GeeksforGeeks - Node.js Rest API Introduction
• Postman Blog - Rest API Examples

Internet Gateway vs Private Gateway in AWS

When working with AWS networking, understanding how your VPC communicates with the outside world is essential.

---

Internet Gateway (IGW)

• Enables public internet traffic to reach resources in a VPC
• Acts as the connection between a VPC and the internet
• Required if resources (like web servers) need public access
• Without an Internet Gateway, resources inside the VPC cannot be accessed from the internet

---

Private Gateway (Virtual Private Gateway – VGW)

• Enables secure communication through a VPN tunnel
• Allows on-premises infrastructure to connect privately to your VPC
• Uses encryption to protect data traveling over the internet
• Commonly used for hybrid cloud architectures

---

Key Concepts

• VPC (Virtual Private Cloud):
  An isolated section of the AWS cloud where you launch resources

• VPN (Virtual Private Network):
  A secure, encrypted tunnel used to connect networks over the internet

---

In Simple Terms

• IGW → like a public playground, anyone can come and play.
• VGW → like a school playground, only authorized students are allowed

---

Understanding these components is fundamental when designing secure and scalable AWS architectures.

Don’t worry — these concepts are simple once you think of them in terms of “public vs private access.”

Introduction

AWS Lambda is a serverless compute service that frees you from managing servers, scaling, or infrastructure. However, this also means you lose direct access to traditional debugging tools like SSH or local log files. Effective logging becomes your primary window into your application's behavior.

Good logging helps you debug issues, monitor performance, detect security problems, optimize costs, and maintain compliance. Lambda automatically streams logs to Amazon CloudWatch, but without a solid strategy, logs can become noisy, expensive, or hard to use.

This guide covers how Lambda logging works and the critical best practices to make it efficient, searchable, and cost-effective.

How AWS Lambda Logging Works

Lambda automatically captures and sends these logs to CloudWatch Logs for every invocation:

• INIT_START, START, END, and REPORT lines — These include runtime details, request ID, duration, billed duration, memory usage, and initialization time.
• Custom logs — Anything you output via console.log(), print(), or standard output/error streams.

You can add your own logs to track application flow, variables, errors, or business events. Errors (exceptions, timeouts, memory issues) are also captured automatically.

Tip: Use JSON.stringify() (with care) to log objects structuredly, and consider redacting sensitive data (e.g., passwords, personal info) using a replacer function.

Best Practices for Lambda Logging

1. Provide Enough Context (But Not Too Much)

Every log should be actionable. Include:

• Relevant event details or inputs (summarized).
• Application state or key variables.
• Environment variables or configuration settings (e.g., stage, version).
• Timestamps (often added automatically) and outcomes.

Avoid logging entire large payloads (e.g., full HTTP requests or Kinesis records) in production, as this drives up costs quickly.

2. Use a Proper Logging Framework

Relying only on console.log() works for simple cases but lacks structure. Use established libraries:

• Node.js: Winston, Pino (fast and lightweight).
• Python: Built-in logging module.
• Java: Apache Log4j.

These frameworks support log levels, structured output, metadata, and asynchronous logging—ideal for serverless. Consider packaging them via Lambda Layers for reuse.

3. Apply Appropriate Log Levels

Categorize logs to control verbosity:

• DEBUG — Detailed tracing (development only).
• INFO — Normal operational events.
• WARN — Potential issues.
• ERROR — Failures that need attention.
• CRITICAL — Severe problems.

Set the log level via an environment variable (e.g., LOG_LEVEL=info in production). This lets you increase verbosity temporarily during incidents without redeploying.

4. Use Correlation IDs (Request IDs)

Assign a unique ID to each request. Lambda provides context.awsRequestId automatically.

• Log this ID with every message.
• It allows you to trace a single invocation across multiple log lines or even chained Lambda functions and services.

This is essential for distributed systems debugging.

5. Log in Structured JSON Format

JSON logs unlock powerful querying in CloudWatch Logs Insights. You can filter by fields, run aggregations, and create dashboards easily.

Example structure:

{
  "level": "info",
  "message": "User processed successfully",
  "requestId": "abc-123",
  "userId": "user456",
  "durationMs": 245
}

This beats plain text for searchability and analysis.

6. Don’t Log Too Much – Mind the Costs

CloudWatch pricing includes ingestion ($0.50/GB) and storage. Built-in Lambda logs (START/END/REPORT) add overhead for every invocation. Excessive logging of payloads can lead to surprisingly high bills.

Best practices:

• Use log levels to reduce production volume.
• Summarize or sample high-volume data.
• Avoid logging in hot paths unless necessary.

7. Configure Log Retention and Rotation

CloudWatch retains logs indefinitely by default. Set a realistic retention policy (e.g., 30 or 90 days) in your IaC (Terraform, Serverless Framework, etc.).

Benefits:

• Reduces storage costs ($0.03/GB/month, compressed).
• Limits exposure of old sensitive data.
• Keeps log groups performant.

Regularly review and archive older logs if needed for compliance.

8. Centralize, Monitor, and Alert

• Centralize: Use CloudWatch as the hub. Forward to tools like Elasticsearch, Datadog, or Lumigo for advanced analysis if your setup grows.
• Monitor & Alert: Create CloudWatch Metrics Filters and Alarms for patterns like high error rates, specific error messages, or latency spikes. Route notifications via SNS, email, or PagerDuty.

Common Pitfalls to Avoid

• Logging sensitive data.
• Using plain strings instead of structured logs.
• Noisy DEBUG logs left enabled in production.
• Ignoring costs until the bill arrives.
• Poor or missing request ID correlation.

Conclusion

Strong logging turns AWS Lambda from a black box into an observable, maintainable system. By providing context, using frameworks and levels, structuring logs as JSON, tracking requests with correlation IDs, and managing retention/costs, you’ll debug faster, reduce expenses, and build more reliable serverless applications.

Start small: Audit your current functions for log levels and JSON structure, then add retention policies. Over time, these practices will pay dividends in operational efficiency.

Further Reading:

• Lumigo: Lambda Logging Best Practices
• Better Dev: AWS Lambda Logging
• Medium article on practical examples with Pino and JSON handling.

What logging challenges have you faced with Lambda? Share in the comments!

Amazon Elastic Container Service (ECS) is one of AWS’s most powerful tools for running containerized applications. One of its biggest advantages is built-in auto-scaling, which automatically adjusts resources based on real demand. This helps maintain application performance during traffic spikes while keeping costs under control by scaling down when demand drops.

ECS handles auto-scaling at two distinct levels:

1. Task-level Scaling (Service Auto Scaling) — available for both EC2 and Fargate launch types.
2. Infrastructure-level Scaling (Cluster Auto Scaling) — available only for the EC2 launch type.

---

Understanding the ECS Hierarchy

Before diving into scaling, it’s important to understand how ECS is structured:

• An ECS Cluster contains one or more ECS Services.
• An ECS Service runs and maintains one or more ECS Tasks.
• Each Task contains one or more containers that make up your application.

Scaling at the service level changes the number of tasks running. Scaling at the cluster level changes the underlying compute capacity.

---

1. Task-Level Scaling (Service Auto Scaling)

This is the most commonly used form of auto-scaling in ECS and works with both EC2 and Fargate.

You define scaling policies for your ECS Service so it automatically adds or removes tasks based on metrics such as:

• CPU utilization
• Memory utilization
• Custom metrics (via CloudWatch)
• Request count (when used with a load balancer)

Example policy: “If average CPU utilization across all tasks exceeds 75% for 5 minutes, add 2 tasks. If it drops below 40%, remove 1 task.”

Benefits:

• Handles traffic spikes gracefully.
• Simple to configure through the AWS Console, CLI, or CDK/Terraform.
• Works seamlessly with Application Load Balancers for even traffic distribution.

Service Auto Scaling only manages the number of tasks. It does not automatically provision more servers (EC2 instances).

---

2. Infrastructure-Level Scaling (Cluster Auto Scaling)

If you’re using the EC2 launch type, you also need to scale the underlying virtual machines. This is where Cluster Auto Scaling (also called managed scaling with Capacity Providers) comes in.

Key Concept: EC2 Auto Scaling Groups + ECS Capacity Providers

When you enable managed scaling on a Capacity Provider linked to an Auto Scaling Group, ECS automatically:

• Monitors the resource needs of your tasks.
• Creates custom CloudWatch metrics and alarms.
• Manages a target tracking scaling policy.
• Adds or removes EC2 instances as needed.

Important behaviors:

• When scaling out from zero instances, ECS launches 2 instances by default.
• ECS uses the AWSServiceRoleForECS service-linked IAM role to manage scaling.
• You set a target capacity percentage (e.g., keep instances at 70% utilization).
• Never manually change the desired capacity if ECS is managing it — let ECS control the scaling policy.

Note: This does not apply to Fargate. With Fargate, AWS manages all the underlying infrastructure, so you only need Service Auto Scaling.

---

EC2 vs Fargate: Why It Matters for Scaling

Feature	EC2 Launch Type	Fargate Launch Type
Task Scaling	Yes	Yes
Infrastructure Scaling	Yes (Cluster Auto Scaling)	No (AWS-managed)
Management Overhead	Higher (manage instances)	Lower
Cost Model	Pay for EC2 instances	Pay per vCPU/memory per second
Best For	Full control, custom AMIs, cost optimization	Simplicity and reduced ops

---

How Service Auto Scaling and Cluster Auto Scaling Work Together

These two scaling mechanisms are independent:

• You can scale tasks without scaling instances (risky on EC2 — tasks may go pending).
• You can scale instances without scaling tasks.
• For optimal performance on EC2, you should use both.

Best Practice: Use Service Auto Scaling + Cluster Auto Scaling with Capacity Providers. This creates a complete auto-scaling loop where tasks and infrastructure scale in harmony.

---

Conclusion

ECS Auto Scaling is a game-changer for running production workloads efficiently. By combining Service Auto Scaling (task level) with Cluster Auto Scaling (infrastructure level on EC2), you can build highly responsive, cost-optimized container environments that handle unpredictable traffic with minimal manual intervention.

Whether you choose Fargate for simplicity or EC2 for maximum control, understanding these two scaling layers is essential for mastering AWS container orchestration.

Happy scaling!

---

References:

• AWS Documentation: Cluster Auto Scaling
• GeeksforGeeks: Introduction to Amazon ECS
• Judoscale Blog: ECS Autoscaling

When building projects, we often feel lazy about handling access control. Who can do what? How do we authorize users? AWS solved this headache with a service called Amazon Cognito.

Cognito is a fully managed service that helps you handle:

• User authentication (sign-up, sign-in, password reset)
• Multi-factor authentication (MFA)
• Synchronization of user data across devices
• Integration with social identity providers like Facebook, Google, and Amazon, so users can log in with existing accounts

---

Amazon Cognito Architecture

Amazon Cognito has several key components:

1. User Pools

   • Acts as your user directory
   • Manages authentication: email/password, phone number, or social logins
   • Handles account info, multi-factor authentication, and password resets

2. Identity Pools

   • Provides temporary AWS credentials to access AWS resources (like S3 or DynamoDB)
   • Can accept identities from:
     • User Pools
     • Social logins (Google, Facebook, Apple)
     • SAML or OpenID Connect
     • Anonymous guest access

3. Cognito Sync

   • Synchronizes user data across devices
   • Uses S3 as backend storage

4. Cognito Streams

   • Provides real-time updates on user data changes

More about Cognito on GeeksforGeeks

---

User Pools vs Identity Pools — What’s the Difference?

Here’s an easy way to remember:

Feature	User Pool	Identity Pool
Purpose	Authentication (who you are)	Authorization (what you can access)
Handles	Sign-up, sign-in, MFA, password reset	Temporary AWS credentials
Tokens	JWT tokens (ID, access, refresh)	AWS credentials
Use case	Manage users directly	Let users access AWS resources

When to use both:
If you want authenticated users (User Pool) to access AWS resources securely (Identity Pool), use both together.

Flow:

1. User signs in via User Pool → receives JWT tokens
2. Tokens are sent to Identity Pool → exchanged for temporary AWS credentials
3. User accesses AWS resources using those credentials

When you don’t need both:

• Only User Pool → if you just need user authentication, not AWS access
• Only Identity Pool → if you just need social or guest access to AWS resources

---

Step-by-Step: Connecting User Pools and Identity Pools

Think of it as “how to connect your login system to AWS resources.”

1. Set up a User Pool

• Go to AWS Management Console → Cognito → User Pools → Create a user pool
• After creating it, note down:
  • User Pool ID → unique pool identifier
  • App Client ID → key for your app to use the pool

2. Set up an Identity Pool

• Go to AWS Management Console → Cognito → Identity Pools → Create a new identity pool

3. Link User Pool to Identity Pool

• Open your Identity Pool → User access tab → Add identity provider
• Select Cognito User Pool and enter:
  • User Pool ID
  • App Client ID

4. Set up roles for users

• AWS roles define what users can do
• Options:
  • Default role → everyone gets the same permissions
  • Role with rules → assign roles based on attributes (group, email, etc.)
  • Preferred role → users can request a specific role if allowed

5. Map user attributes to principal tags (optional)

• Tags are extra info attached to AWS credentials
• Options:
  • Inactive → no tags
  • Default mappings → AWS uses sub (user ID) and aud (app ID)
  • Custom mappings → pick which user attributes become tags

6. Save changes

• Click Save after configuring everything

Summary:

• User Pool → handles login/authentication
• Identity Pool → handles access to AWS resources
• Linking → tells AWS which users can access which roles
• Roles & tags → control what users can do

Official AWS guide

---

While developing a new project using Next.js, I encountered an issue where React Hooks could not be used inside an asynchronous function. After researching this problem, I found that it is related to the Rules of Hooks defined by React.

---

React Rules of Hooks

According to the official React documentation, hooks must always be called in the same order during every render.

React depends on this consistent order to correctly associate state and effects with each hook call.

If the order changes between renders, React may lose track of which state belongs to which hook, leading to errors such as:

• "Rendered fewer hooks than expected"
• "Rendered more hooks than expected"
• State mismatches

---

Common Violations of the Rules of Hooks

Some common patterns that violate these rules include:

• Calling hooks inside conditions (if, else, ternary operators)
• Calling hooks inside loops (for, while)
• Calling hooks after early returns
• Calling hooks inside callbacks or event handlers
• Calling hooks inside async functions
• Calling hooks inside class methods
• Calling hooks at the module level

---

Hooks Inside Async Functions

One common mistake is attempting to use hooks inside an async function.

Hooks must run during the rendering of a React function component. React relies on the order of hooks during this render process to manage state and effects correctly.

If hooks are called inside an async function, they are executed outside the component’s render flow, which breaks React’s hook tracking mechanism.

Because of this, hooks can only be called inside:

• React function components
• Custom hooks

Not inside regular JavaScript functions such as async functions.

---

Solution: Using Async Logic Inside useEffect

A common solution is to keep the useEffect callback synchronous while calling an internal async function.

Example

import { useEffect, useState } from "react";

export default function Example() {
  const [data, setData] = useState(null);

  useEffect(() => {
    async function fetchData() {
      const res = await fetch("/api/data");
      const json = await res.json();
      setData(json);
    }

    fetchData();
  }, []);

  return <div>{data ? JSON.stringify(data) : "Loading..."}</div>;
}

This guide covers essential Docker commands and concepts, including:

• Building images
• Running containers
• Managing processes
• Cleaning up resources

It provides a clear understanding of the core Docker workflow with simple examples, enabling you to start building and running containerized applications confidently.

1. Build Docker Image

Create the image from your Dockerfile:

docker build -imagename(anyname) .

---

2. Run Docker Container

Start a container from the image:

docker run -p 3000:3000 imagename(anyname)

Port mapping:

• 3000:3000 = local machine → container

---

3. List Containers

docker ps -a

Shows all containers (running + stopped)

---

4. Stop a Running Container

docker stop <container_id>

---

5. Remove a Container.

docker rm <container_id>

---

6. Remove Docker Image.

By name:

bash docker rmi dirname

### By image ID:
 ```bash
docker rmi <image_id>

---

Quick Flow (Important to remember)

build → run → list → stop → remove container → remove image