DEV Community: Rahimah Sulayman

YAML Learning Lab

Rahimah Sulayman — Tue, 04 Aug 2026 15:45:17 +0000

Introduction

YAML is one of the most widely used configuration and data serialization formats across modern cloud engineering, DevOps, automation, and CI/CD environments.

From GitHub Actions workflows to Kubernetes manifests and infrastructure configuration, YAML provides a human-readable way to represent structured data while remaining easy for machines to process.

The YAML Learning Lab is a practical technical repository focused on YAML syntax, structured data representation, configuration patterns, validation, and its application within modern DevOps workflows.

🔗 GitHub Repository: YAML Learning Lab

A Brief History of YAML

YAML was created in 2001 by Clark Evans, Ingy döt Net, and Oren Ben-Kiki as a human-friendly data serialization language.

The name YAML originally stood for "Yet Another Markup Language." It was later reinterpreted as "YAML Ain't Markup Language", emphasizing that YAML is a data serialization language, rather than a markup language.

This distinction is important.

Markup languages such as HTML are primarily concerned with describing the structure and presentation of documents, while YAML focuses on representing structured information and configuration in a format that is readable by both humans and machines.

Today, YAML is widely used in:

Cloud configuration
CI/CD pipelines
Kubernetes
Infrastructure as Code
Application configuration
Automation
DevOps tooling

Project Overview

The repository brings together practical YAML examples covering:

Key-value pairs
Mappings
Nested structures
Sequences
Lists of objects
Data types
Comments
Quoted strings
Multiline strings
Anchors and aliases
Merge keys
Multi-document YAML
GitHub Actions workflows
YAML validation with Python and PyYAML

The project demonstrates how YAML syntax translates into structured configuration used by modern engineering tools.

Project Setup

The project was organized as a Git repository with individual YAML files representing different concepts.

The repository structure keeps each concept isolated while also providing a final configuration challenge that combines multiple YAML features.

YAML Fundamentals

The first examples introduce YAML's basic key-value structure.

name: Raphael
role: Cloud Engineer
country: Nigeria

A YAML mapping associates each key with a value:

Key	Value
`name`	`Raphael`
`role`	`Cloud Engineer`
`country`	`Nigeria`

This simple structure is the foundation for more complex YAML configurations.

Mappings and Nested Structures

YAML uses indentation to represent relationships between data elements.

For example:

person:
  name: Raphael
  role: Cloud Engineer

Here, name and role are properties nested under person.

Nested structures allow configuration to represent relationships between related pieces of information without requiring complex syntax.

Nested mappings extend this idea by allowing multiple levels of configuration:

person:
  name: Raphael
  age: 30
  country: Nigeria

One important YAML rule becomes obvious here:

Indentation defines structure.

YAML configuration should use spaces for indentation rather than tabs.

Sequences

YAML sequences represent ordered collections.

They are identified using a hyphen (-):

skills:
  - Azure
  - Docker
  - Kubernetes
  - Git

This creates a list of four values under the skills key.

Sequences are common in configuration files for representing:

Packages
Ports
Hosts
Skills
Resources
Configuration options

Lists of Objects

YAML sequences can contain mappings, making it possible to represent collections of structured objects.

employees:
  - name: Raphael
    role: Cloud Engineer

  - name: Sarah
    role: DevOps Engineer

  - name: David
    role: Solution Architect

Each list item contains multiple properties.

This pattern is particularly useful when configuration describes multiple resources that share a common structure.

YAML Data Types

YAML supports several common data types.

person:
  name: Raphael
  age: 30
  salary: 4500.50
  active: true
  verified: false
  phone: null

These values represent different data types:

Value	Type
`Raphael`	String
`30`	Integer
`4500.50`	Floating-point number
`true`	Boolean
`false`	Boolean
`null`	Null

Understanding how YAML interprets values is important when configuration is consumed by automation tools or programming languages.

Comments and Quoted Strings

Comments begin with # and are ignored by YAML parsers.

# Employee Information Configuration
city: Lagos

Comments are useful for documenting configuration and explaining why a particular value or section exists.

YAML also supports quoted strings:

message: "Welcome: Cloud Engineers!"

Quoting can make the intended value explicit, particularly when a value contains characters that could otherwise be interpreted specially.

Multiline Strings

YAML provides block scalar syntax for storing multiline text.

There are two important styles:

| — literal block
> — folded block

Literal Block

The | character preserves line breaks.

bio_literal: |
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

Folded Block

The > character folds consecutive lines into a paragraph-like value.

bio_folded: >
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

The difference matters when YAML is being used to store scripts, documentation, certificates, configuration blocks, or other multiline content.

Anchors, Aliases, and Merge Keys

YAML provides anchors and aliases for reusing configuration without repeatedly defining the same values.

An anchor is created using &:

defaults: &default
  country: Nigeria
  role: Student

The configuration can then be reused using an alias:

student1:
  <<: *default
  name: Raphael

The << merge key incorporates the values from the anchored mapping.

Another object can reuse the same configuration:

student2:
  <<: *default
  name: Sarah

This approach reduces duplication and makes shared configuration easier to maintain.

Multi-Document YAML

A YAML file can contain multiple independent documents.

The document separator is:

---

For example:

student1:
  name: Raphael

---
name: Third Document Stream

The separator marks the beginning of another YAML document.

This becomes important during validation because a file containing multiple documents must be parsed accordingly.

The repository demonstrates this concept in anchors.yaml.

YAML in GitHub Actions

YAML is heavily used in CI/CD systems.

The repository includes a GitHub Actions workflow:

name: Build Project

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Building project..."

The workflow demonstrates several important GitHub Actions concepts.

Workflow Name

name: Build Project

Defines the workflow's name.

Trigger

on:
  push:

Specifies that the workflow runs when changes are pushed to the repository.

Job

jobs:
  build:

Defines a job named build.

Runner

runs-on: ubuntu-latest

Specifies the GitHub-hosted runner that executes the job.

Steps

steps:
  - uses: actions/checkout@v4
  - run: echo "Building project..."

The first step checks out the repository contents.

The second executes a shell command.

Final Configuration Challenge

The student-profile.yaml configuration combines several YAML concepts into one structured document.

It includes:

Mappings
Nested mappings
Sequences
Strings
Integers
Floating-point numbers
Booleans
Multiline strings
Folded strings
Anchors
Aliases
Merge keys

The shared configuration begins with an anchor:

default_profile: &default
  role: Student
  country: Nigeria
  active: true
  score: 95.5

The configuration is then reused:

user1:
  <<: *default
  name: Sarah

user2:
  <<: *default
  name: David

The file also contains sequences:

skills:
  - Azure
  - Docker
  - Kubernetes

hobbies:
  - Coding
  - Reading

Nested mappings:

address:
  street: 12 Cloud Way
  city: Abuja
  country: Nigeria

And both multiline string styles:

bio_literal: |
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

bio_folded: >
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

This configuration demonstrates how multiple YAML structures can be combined to represent realistic configuration data.

YAML Validation

Configuration should be validated before being used by automation systems.

This repository uses Python, PyYAML, and Linux command-line tools to validate the YAML files.

Validate All YAML Documents

python3 -c 'import yaml, glob; [list(yaml.safe_load_all(open(f))) for f in glob.glob("*.yaml")]; print("All YAML files valid!")'

This command:

Starts Python 3 using python3.
Uses -c to execute Python code directly from the command line.
Imports the PyYAML library with import yaml.
Imports Python's glob module with import glob.
Uses glob.glob("*.yaml") to find every .yaml file in the current directory.
Uses open(f) to open each YAML file.
Uses yaml.safe_load_all() to parse all YAML documents within each file.
Uses list() to force all documents to be parsed.
Uses a list comprehension to apply the validation to every YAML file.
Uses print() to display a success message after all files are parsed successfully.

The use of safe_load_all() is important because anchors.yaml contains multiple YAML documents separated by ---.

Check for Illegal Tab Characters

YAML indentation should use spaces rather than tabs.

The repository also checks for tab characters:

grep -n $'\t' *.yaml || echo 'No illegal tab characters found!'

Breaking down the command:

Part	Meaning
`grep`	Searches files for a specified pattern.
`-n`	Displays the line number where a match is found.
`$'\t'`	Represents a tab character in Bash.
`*.yaml`	Targets all `.yaml` files in the current directory.
`
{% raw %}`echo`	Prints text to the terminal.

If no tabs are detected, the command prints:

No illegal tab characters found!

These checks provide basic validation for both YAML syntax and indentation consistency.

Git and Repository Management

The project was maintained using Git and published to GitHub.

Git was used to track changes, create commits, maintain the main branch, and synchronize the repository with GitHub.

The final repository includes:

yaml-learning-lab/
├── docs/
│   └── lessons.md
├── screenshots/
├── README.md
├── anchors.yaml
├── lesson1.yaml
├── lesson2.yaml
├── lesson3.yaml
├── lesson4.yaml
├── lesson5.yaml
├── lesson6.yaml
├── lesson7.yaml
├── multiline.yaml
├── student-profile.yaml
└── workflow.yaml

The complete implementation, documentation, YAML files, and supporting evidence are available in the repository:

View the SKILL.SCH YAML Learning Lab on GitHub

Why YAML Matters in Cloud and DevOps

YAML is more than a configuration format. It is an important component of modern engineering workflows.

The concepts demonstrated in this repository appear in technologies such as:

GitHub Actions
Kubernetes
Docker Compose
Ansible
Azure DevOps
Infrastructure as Code tools
Application configuration systems
Cloud automation platforms

The same fundamental ideas—mappings, sequences, nesting, data types, multiline values, and reusable configuration—appear repeatedly across these technologies.

Understanding YAML therefore makes it easier to read, write, troubleshoot, and maintain configuration-driven systems.

Key Takeaways

The YAML Learning Lab demonstrates how YAML progresses from simple key-value pairs to structured configuration used in real-world DevOps environments.

The repository covers:

YAML syntax and structure
Mappings and nested mappings
Sequences and lists of objects
Data types
Comments and quoted strings
Literal and folded multiline strings
Anchors, aliases, and merge keys
Multi-document YAML streams
GitHub Actions workflow configuration
YAML validation using Python and PyYAML
Git-based project management

The project also demonstrates an important engineering principle:

Configuration should be readable, structured, reusable, and validated before it becomes part of an automation workflow.

Summary

The YAML Learning Lab provides a practical technical reference for YAML and its role in cloud engineering and DevOps.

From basic mappings and sequences to anchors, multiline strings, GitHub Actions, and automated validation, the repository brings together core YAML patterns required for working with configuration-driven tooling.

More importantly, the project demonstrates YAML in context—not simply as a file format, but as a foundational component of modern cloud, DevOps, automation, and CI/CD workflows.

For the complete implementation, configuration files, technical documentation, and supporting evidence:

🔗 YAML Learning Lab — GitHub Repository

Author

Rahimah Sulayman

Cloud & DevOps Engineer | Data Analyst

Dockerfiles: Building and Running a Node.js Application in a Container

Rahimah Sulayman — Wed, 29 Jul 2026 12:02:53 +0000

Introduction

Containers provide a consistent way to package applications together with the dependencies and configuration required to run them.

A Dockerfile defines how that container image is built.

In this project, a Node.js application was containerized using a custom Dockerfile, with the image built, tested, inspected, modified, and rebuilt throughout the implementation.

The project demonstrates how Dockerfile instructions influence the resulting image and, ultimately, the behavior of the running container.

What Is a Dockerfile?

A Dockerfile is a text file containing a sequence of instructions Docker uses to build an image.

A simplified workflow looks like this:

Application Source Code
        │
        ▼
    Dockerfile
        │
        │ docker build
        ▼
   Docker Image
        │
        │ docker run
        ▼
 Docker Container
        │
        ▼
 Running Application

The Dockerfile describes the environment and instructions required to turn application source code into a runnable container image.

Dockerfile vs Docker Image vs Container

These three concepts are closely related but serve different purposes.

Dockerfile

The Dockerfile is the build blueprint.

It defines instructions such as:

FROM
WORKDIR
COPY
RUN
EXPOSE
CMD

Docker Image

The image is the built artifact produced from the Dockerfile.

It contains the application, dependencies, filesystem layers, and configuration required to create a container.

Docker Container

The container is a running instance of an image.

In simple terms:

Dockerfile
    │
    │ docker build
    ▼
Docker Image
    │
    │ docker run
    ▼
Docker Container

Project Overview

The application used for this project is a simple Node.js web application.

The containerized application consists of:

A Node.js application
A server.js entry point
A package.json file
Installed Node.js dependencies
A Dockerfile defining the image build process

The Dockerfile is responsible for packaging these components into a reproducible container image.

Project Structure

Dockerfiles-lab/
├── screenshots/
├── .gitignore
├── Dockerfile
├── package.json
├── package-lock.json
├── README.md
└── server.js

The repository also contains implementation screenshots documenting the different stages of the Dockerfile and container lifecycle.

The complete implementation is available in the GitHub repository linked at the end of this article.

The Node.js Application

Before building the container, there needs to be an application for Docker to package.

The application entry point is:

server.js

A simplified Node.js server can look like:

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello from Docker!");
});

server.listen(3000, () => {
  console.log("Server running on port 3000");
});

The application listens on port 3000.

This gives Docker something concrete to package and run inside the container.

Why `package.json` Matters

The project also contains:

package.json

For Node.js applications, package.json provides project metadata and dependency information.

It can also define scripts used to start or manage the application.

For example:

{
  "scripts": {
    "start": "node server.js"
  }
}

The associated lock file:

package-lock.json

records the resolved dependency versions.

Together, these files make the Node.js application's dependencies and runtime configuration reproducible.

Building the First Docker Image

The first stage of the implementation involved building a Docker image from the Dockerfile.

The basic command is:

docker build -t docker-node-app:1.0 .

The components of the command are:

docker build
     │
     ├── -t docker-node-app:1.0
     │       └── image name and tag
     │
     └── .
         └── current directory as build context

The . tells Docker to use the current directory as the build context.

This makes files in the project directory available to Docker during the build, subject to .dockerignore rules where applicable.

Understanding the Dockerfile

A Dockerfile is processed from top to bottom.

A typical Node.js Dockerfile can contain instructions such as:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Each instruction has a specific purpose.

`FROM`: Choosing the Base Image

FROM node:20-alpine

FROM specifies the base image from which the new image is built.

For a Node.js application, using a Node.js base image provides the Node.js runtime and supporting environment required to execute the application.

The alpine variant is based on Alpine Linux and is commonly used when a smaller image footprint is desirable.

The base image is therefore the starting point for the container environment.

`WORKDIR`: Setting the Working Directory

WORKDIR /app

WORKDIR establishes the working directory for subsequent Dockerfile instructions.

Instead of placing application files throughout the container filesystem, the application can be organized under:

/app

It also determines the default working directory when the container starts unless another directory is explicitly configured.

`COPY`: Adding Application Files

The application files need to be transferred from the build context into the image.

For example:

COPY package*.json ./

This copies the Node.js package definition files into the working directory.

Later:

COPY . .

copies the remaining application files into the image.

This separation is useful because dependency installation and application source code can be handled as separate build layers.

`RUN`: Installing Dependencies

RUN npm install

RUN executes a command while the image is being built.

Here, npm installs the dependencies defined by the Node.js project.

The resulting files become part of the image layer produced by this instruction.

This is different from CMD.

RUN happens during image build time.

`EXPOSE`: Documenting the Application Port

EXPOSE 3000

The Node.js application listens on port 3000, so the Dockerfile declares:

EXPOSE 3000

It is important to understand that EXPOSE does not publish the port to the host by itself.

It documents the port the application expects to use inside the container.

Host-to-container port publishing is configured when the container is started.

For example:

docker run -d -p 3000:3000 --name docker-node-container docker-node-app:1.0

The mapping is:

Host                  Container
 3000       ───────►    3000

`CMD`: Defining the Default Container Command

One of the most important Dockerfile instructions in this project was:

CMD ["node", "server.js"]

CMD defines the default command executed when a container is started from the image.

In this case, Docker starts:

node server.js

inside the container.

This is what launches the Node.js application.

Why `CMD` Matters

During the implementation, the application command was changed between:

CMD ["node", "server.js"]

and:

CMD ["node", "app.js"]

This demonstrated an important container behavior.

If the file referenced by CMD does not exist in the image, the container cannot successfully start the application.

This can result in a container that starts and immediately exits.

For example, if the Dockerfile contains:

CMD ["node", "app.js"]

but the image does not contain:

/app/app.js

Node.js cannot execute the requested entry point.

This is why examining container logs is an important troubleshooting step.

Building After a Dockerfile Change

A Docker image is a built artifact.

Changing the Dockerfile does not automatically modify an existing image.

After making changes, the image must be rebuilt:

docker build -t docker-node-app:2.0 .

This creates a new image version containing the updated Dockerfile instructions.

The general workflow is:

Modify Dockerfile
       │
       ▼
docker build
       │
       ▼
New Image
       │
       ▼
docker run
       │
       ▼
Test Application

This build-test cycle was repeated during the project to validate changes to the container configuration.

Inspecting Docker Images

After building an image, available images can be inspected with:

docker images

This provides information such as:

Repository
Tag
Image ID
Creation time
Image size

For example:

REPOSITORY       TAG       IMAGE ID       CREATED        SIZE
docker-node-app  1.0       abc123...      ...            ...

Tags such as:

1.0
2.0
final

can be used to distinguish different image versions during development and testing.

Running the Container

Once the image has been built, it can be started with:

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

The important options are:

Option	Purpose
`-d`	Runs the container in detached mode
`-p 3000:3000`	Maps host port 3000 to container port 3000
`--name`	Assigns a name to the container
`docker-node-app:final`	Specifies the image to run

The application can then be accessed from the host through:

http://localhost:3000

Verifying a Running Container

After starting the container, its status can be checked with:

docker ps

This displays currently running containers.

Typical information includes:

Container ID
Image
Command
Creation time
Status
Port mappings
Container name

The port mapping should show that host port 3000 is forwarded to port 3000 inside the container.

Testing the Application

Once the container is running, the application can be accessed through a browser:

http://localhost:3000

At this point, the request flow is:

Browser
   │
   │ localhost:3000
   ▼
Host Port 3000
   │
   │ Docker port mapping
   ▼
Container Port 3000
   │
   ▼
Node.js
   │
   ▼
server.js
   │
   ▼
HTTP Response

This demonstrates the relationship between the host, container networking, and the application process.

Troubleshooting a Failed Container

Not every container starts successfully on the first attempt.

During the implementation, an invalid application entry point was used to demonstrate container troubleshooting.

A failed run can be identified using:

docker ps -a

Unlike docker ps, the -a option also displays stopped containers.

This is particularly useful when a container starts and then exits immediately.

Using Docker Logs for Troubleshooting

When a container fails, logs are often the fastest way to determine why.

The logs can be viewed with:

docker logs docker-node-container

For example, if the Dockerfile attempts to execute a file that does not exist:

CMD ["node", "app.js"]

Node.js may report that it cannot find the specified module.

The important troubleshooting pattern is:

Container exits
      │
      ▼
docker ps -a
      │
      ▼
Identify exited container
      │
      ▼
docker logs <container>
      │
      ▼
Identify application/configuration error
      │
      ▼
Fix Dockerfile or application
      │
      ▼
Rebuild image
      │
      ▼
Run container again

This workflow is useful well beyond simple Docker labs.

Stopping and Removing a Container

Once a container is no longer needed, it can be stopped and removed with:

docker stop docker-node-container && docker rm docker-node-container

The first command:

docker stop docker-node-container

stops the running container.

The second:

docker rm docker-node-container

removes the stopped container.

The && operator ensures the second command runs only if the first command succeeds.

Rebuilding and Retesting

After correcting the Dockerfile, the image was rebuilt and the container started again.

A typical sequence is:

docker build -t docker-node-app:final .

followed by:

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

Then:

docker ps

and finally:

http://localhost:3000

can be used to verify the result.

This build → run → inspect → troubleshoot → rebuild cycle is fundamental to working effectively with Dockerfiles.

Changing Application Output

The application response was also modified during testing.

For example:

res.end("Welcome to my Docker Node.js application!");

After changing application source code, the image must be rebuilt if the source code is copied into the image during the build:

docker build -t docker-node-app:final .

The updated image then needs to be used when starting a new container.

This demonstrates an important principle:

A running container does not automatically become a new image when the source code or Dockerfile changes.

The image must be rebuilt when the application contents packaged into it need to change.

Docker Build Cache

Docker builds are made up of layers.

For example:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Each instruction can contribute to the image's layer structure.

Docker can reuse unchanged layers during subsequent builds, which can significantly improve build performance.

This is one reason Dockerfiles are commonly structured to copy dependency definition files before copying the rest of the application source:

COPY package*.json ./
RUN npm install

COPY . .

If only application source code changes, Docker may be able to reuse the dependency installation layer.

Dockerfile Best Practices

A production-oriented Dockerfile should be designed with efficiency, security, and reproducibility in mind.

1. Use an appropriate base image

Choose a maintained base image that provides only what the application needs.

For example:

FROM node:20-alpine

A smaller base image can reduce the image footprint and attack surface, although compatibility should always be considered.

2. Keep the image focused

Only copy files required by the application.

A .dockerignore file can prevent unnecessary files from being included in the build context.

Example:

node_modules
.git
.env
npm-debug.log

3. Take advantage of layer caching

Copy dependency files before application source code:

COPY package*.json ./
RUN npm install

COPY . .

This can prevent unnecessary dependency reinstallation when only source files change.

4. Avoid embedding secrets

Do not place passwords, API keys, tokens, or other sensitive values directly into a Dockerfile.

Use appropriate runtime configuration and secrets-management mechanisms instead.

5. Run as a non-root user

Where appropriate, configure the container to run the application as a non-root user.

This reduces the impact of a potential application compromise.

6. Use explicit image tags

Rather than relying blindly on:

FROM node:latest

consider using an explicit version:

FROM node:20-alpine

This makes builds more predictable and reproducible.

Dockerfile Instructions at a Glance

Instruction	Purpose
`FROM`	Defines the base image
`WORKDIR`	Sets the working directory
`COPY`	Copies files into the image
`RUN`	Executes commands during image build
`EXPOSE`	Documents a container port
`CMD`	Defines the default runtime command

A useful distinction is:

RUN
└── Build time

CMD
└── Container runtime

Understanding this difference is essential when diagnosing why a container behaves differently from the image build process.

Dockerfile Workflow

The complete workflow demonstrated in this project can be summarized as:

Application Source
       │
       ▼
   Dockerfile
       │
       │ docker build
       ▼
   Docker Image
       │
       │ docker images
       ▼
   Image Inspection
       │
       │ docker run
       ▼
 Docker Container
       │
       ├── docker ps
       │
       ├── Browser Test
       │
       └── docker logs
               │
               ▼
          Troubleshooting
               │
               ▼
        Modify Application
               │
               ▼
          Rebuild Image
               │
               ▼
        Run & Test Again

This workflow provides a repeatable approach to packaging and validating containerized applications.

Dockerfile vs Docker Compose

Dockerfiles and Docker Compose solve different problems, but they complement each other.

Dockerfile	Docker Compose
Defines how an image is built	Defines how multiple services run together
Creates a custom image	Orchestrates application services
Focuses on image construction	Focuses on service configuration
Uses Dockerfile instructions	Uses YAML configuration
`docker build`	`docker compose up`
`docker run` starts the resulting image	Compose manages the defined application stack

A Dockerfile might create the image for an application:

Dockerfile
     │
     ▼
Application Image

Docker Compose can then use that image as part of a larger application:

                Docker Compose
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
    Application             Database
     Container              Container

Understanding both technologies provides a stronger foundation for building and operating containerized applications.

Key Docker Commands

The primary commands used throughout the project include:

Build an image

docker build -t docker-node-app:final .

List images

docker images

Run a container

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

List running containers

docker ps

List all containers

docker ps -a

View container logs

docker logs docker-node-container

Stop and remove a container

docker stop docker-node-container && docker rm docker-node-container

Skills Demonstrated

This implementation demonstrates practical experience with:

Dockerfile authoring
Docker image creation
Docker image tagging
Docker build context
Docker build layers and caching
Node.js containerization
Base image selection
Working directory configuration
Application file management with COPY
Dependency installation with RUN
Container port configuration
Runtime commands with CMD
Docker container lifecycle management
Port mapping
Container inspection
Container log analysis
Troubleshooting failed containers
Image rebuild and validation workflows
Linux command-line operations
Git and GitHub
Technical documentation

Conclusion

A Dockerfile provides the foundation for turning application source code into a portable, reproducible container image.

By defining the base runtime, working directory, application files, dependencies, exposed port, and startup command, the Dockerfile establishes how the application is packaged and executed.

The implementation also demonstrates that containerization is more than simply building an image. A reliable workflow includes:

Build
  ↓
Run
  ↓
Inspect
  ↓
Test
  ↓
Troubleshoot
  ↓
Rebuild
  ↓
Validate

These concepts form a practical foundation for container-based application development and provide the building blocks for more advanced workflows involving Docker Compose, CI/CD pipelines, container registries, orchestration platforms, and cloud-native deployments.

Project Repository

The complete implementation, Dockerfile iterations, application files, and supporting screenshots are available on GitHub:

https://github.com/rahimahisah17/dockerfiles-lab

The repository provides the complete implementation and evidence of the build, run, troubleshooting, and validation process documented in this article.

Related Work

This Dockerfile implementation pairs naturally with a multi-container deployment workflow using Docker Compose.

Docker Compose can be used to take individually containerized applications and combine them with supporting services such as databases, caches, and other dependencies into a complete application stack.

Docker Compose: Running WordPress and MySQL as a Multi-Container Application

Rahimah Sulayman — Wed, 29 Jul 2026 11:30:19 +0000

Introduction

Managing containers individually with docker run works well for simple applications, but once an application depends on multiple services, managing each container separately quickly becomes inefficient.

A typical WordPress deployment, for example, requires more than the WordPress application itself. It also needs a database service, networking between the services, configuration, and persistent storage.

This is where Docker Compose becomes useful.

In this project, I configured a multi-container WordPress environment using Docker Compose, with WordPress and MySQL defined as separate services and managed through a single compose.yml file.

What is Docker Compose?

Docker Compose is a tool for defining and managing multi-container applications using a YAML configuration file.

Instead of manually creating and configuring each container with multiple docker run commands, the required services and their configuration can be declared in one file.

For this project, the architecture is:

                    Docker Compose
                          │
              ┌───────────┴───────────┐
              │                       │
              ▼                       ▼
        WordPress Service       MySQL Service
        wordpress:latest          mysql:8.0
              │                       │
              └─────── Network ───────┘
                         │
                  Persistent Volumes
                   ┌─────┴─────┐
                   ▼           ▼
                wp_data     db_data

The two services work together:

WordPress provides the web application.
MySQL provides the database.
Docker Compose networking allows WordPress to communicate with MySQL.
Named volumes provide persistent storage.

Project Architecture

The environment consists of two services:

Service	Image	Purpose
`wordpress`	`wordpress:latest`	Web application
`db`	`mysql:8.0`	Database

The WordPress container exposes port 80 internally, which is mapped to port 8080 on the host.

The MySQL service is not exposed directly to the host because WordPress communicates with it through the internal Docker network.

Project Structure

my-wordpress-site/
├── screenshots/
├── compose.yml
└── README.md

The core configuration is contained in:

compose.yml

Creating the Project Workspace

The project begins with a dedicated directory:

mkdir my-wordpress-site
cd my-wordpress-site

This keeps the Compose configuration and project documentation organized in a single workspace.

Defining the Docker Compose Configuration

The environment is defined in compose.yml.

The file contains two services:

services:
  db:
    image: mysql:8.0

  wordpress:
    image: wordpress:latest

The services section is the foundation of the Compose configuration. Each service represents a containerized component of the application.

The complete configuration defines:

Container images
Environment variables
Service dependencies
Port mapping
Persistent volumes
Service-to-service communication

Inspecting `compose.yml`

Before starting the application, the Compose configuration can be inspected directly from the terminal:

cat compose.yml

Configuring the MySQL Service

The database service is defined as:

db:
  image: mysql:8.0
  restart: always
  environment:
    MYSQL_ROOT_PASSWORD: supersecretpassword
    MYSQL_DATABASE: wordpress
    MYSQL_USER: wordpressuser
    MYSQL_PASSWORD: wordpresspassword
  volumes:
    - db_data:/var/lib/mysql

Image

image: mysql:8.0

Docker Compose uses the official MySQL 8.0 image rather than building a custom database image.

Restart Policy

restart: always

This instructs Docker to automatically restart the container when appropriate.

Environment Variables

The database configuration is supplied through environment variables:

MYSQL_ROOT_PASSWORD: supersecretpassword
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpressuser
MYSQL_PASSWORD: wordpresspassword

These variables configure the initial MySQL database, user, and credentials.

Production note: Credentials should not be committed directly into a public repository. In production environments, use environment files, Docker secrets, or an appropriate secrets-management solution.

Persistent Database Storage

volumes:
  - db_data:/var/lib/mysql

The named volume db_data is mounted to MySQL's data directory.

This allows database data to persist independently of the container lifecycle.

Configuring the WordPress Service

The WordPress service is defined as:

wordpress:
  depends_on:
    - db
  image: wordpress:latest
  ports:
    - "8080:80"
  restart: always
  environment:
    WORDPRESS_DB_HOST: db:3306
    WORDPRESS_DB_USER: wordpressuser
    WORDPRESS_DB_PASSWORD: wordpresspassword
    WORDPRESS_DB_NAME: wordpress
  volumes:
    - wp_data:/var/www/html

Image

image: wordpress:latest

The official WordPress image is used as the application container.

Port Mapping

ports:
  - "8080:80"

This maps:

Host port 8080 → Container port 80

This allows the WordPress application to be accessed through port 8080 on the host.

Database Connection

The WordPress container is configured to connect to MySQL using:

WORDPRESS_DB_HOST: db:3306

This is an important Docker Compose concept.

db is not a hostname from the host machine. It is the service name defined in the Compose file.

Docker Compose creates a network for the application, allowing services to communicate with each other using their service names.

The connection therefore looks like:

WordPress
    │
    │ db:3306
    ▼
MySQL

Service Dependency

depends_on:
  - db

This establishes a dependency relationship between WordPress and the database service.

WordPress Persistent Storage

volumes:
  - wp_data:/var/www/html

The wp_data named volume stores WordPress application data outside the container's writable layer.

Starting the Multi-Container Application

Once the Compose configuration is ready, the complete environment can be started with:

docker compose up -d

The up command creates and starts the services defined in compose.yml.

The -d option starts them in detached mode, allowing the terminal to remain available while the containers run in the background.

docker compose
       │
       └── up
            │
            └── -d
                 │
                 ├── MySQL container
                 └── WordPress container

Verifying the Services

After starting the environment, the service status can be checked with:

docker compose ps

This provides a quick overview of the containers managed by the Compose project.

It can be used to verify:

Service names
Container status
Ports
Running state

Inspecting Container Logs

Logs are essential when troubleshooting containerized applications.

Docker Compose provides a convenient way to inspect logs from all services:

docker compose logs --tail 20

The --tail 20 option limits the output to the most recent 20 log lines.

This is useful for identifying:

Startup issues
Configuration problems
Database connection errors
Application errors
Service initialization messages

Managing Persistent Volumes

The Compose configuration defines two named volumes:

volumes:
  db_data:
  wp_data:

These are mounted into the respective services:

db_data
   │
   └── /var/lib/mysql

wp_data
   │
   └── /var/www/html

Named volumes are useful because container storage is otherwise tied to the container's lifecycle.

For a database-backed application, separating persistent data from the container itself is particularly important.

Cleaning Up the Environment

Once the deployment has been verified, the entire Compose environment can be removed with:

docker compose down -v

The down command stops and removes the containers and the Compose network.

The -v option additionally removes the named volumes created by the project.

In this lab, that means:

WordPress container   → removed
MySQL container       → removed
Compose network       → removed
wp_data volume        → removed
db_data volume        → removed

Warning: docker compose down -v removes the project's named volumes and therefore deletes the persistent data stored in them. Use this carefully when working with real application data.

Verifying the Cleanup

The cleanup can be verified using:

docker compose ps
docker ps -a
docker volume ls

The verification confirms that the project's containers and named volumes have been removed.

Docker Compose vs. Individual `docker run` Commands

Without Compose, running this type of environment manually would require separate commands for the database and WordPress containers, along with their networking, environment variables, volumes, and port configuration.

Docker Compose consolidates those requirements into a single declarative configuration.

Manual Docker	Docker Compose
Multiple `docker run` commands	One `compose.yml`
Configuration spread across commands	Configuration centralized in YAML
Manual container relationships	Services defined together
Manual volume configuration	Named volumes declared in Compose
Multiple commands to start services	`docker compose up -d`
Individual cleanup commands	`docker compose down`

This becomes increasingly valuable as application architectures grow.

Key Docker Compose Commands

The main commands used in this project were:

Start services

docker compose up -d

Check service status

docker compose ps

Inspect logs

docker compose logs --tail 20

Stop and remove services

docker compose down -v

Skills Demonstrated

This project demonstrates practical experience with:

Docker Compose
Multi-container application architecture
YAML configuration
WordPress containerization
MySQL containerization
Docker networking and service discovery
Docker named volumes
Persistent application storage
Environment-based service configuration
Container lifecycle management
Container log inspection
Docker CLI
Linux command-line operations
Technical documentation
Git and GitHub project management

Conclusion

Docker Compose provides a practical way to define, configure, and manage applications composed of multiple containers.

By defining WordPress and MySQL as services in a single compose.yml, the application environment becomes easier to deploy, inspect, manage, and remove.

The key concepts demonstrated in this implementation include:

Declarative multi-container configuration
Service-to-service communication
Docker Compose networking
Persistent volumes
Environment variables
Container lifecycle management
Log-based troubleshooting

The same principles can be extended to more complex architectures involving application servers, databases, caches, message brokers, reverse proxies, and other supporting services.

Project Repository

The complete project, including the compose.yml configuration and implementation screenshots, is available on GitHub:

https://github.com/rahimahisah17/my-wordpress-site

Building a Production-Style Azure Infrastructure with Azure CLI: Lessons from a Real Deployment

Rahimah Sulayman — Tue, 21 Jul 2026 11:11:27 +0000

How I deployed Linux and Windows virtual machines, configured networking, secured public access, and troubleshot real Azure deployment issues using only Azure CLI.

Introduction

One of the best ways to learn cloud engineering is to build infrastructure the same way it is deployed in real environments.

Instead of clicking through the Azure Portal, I challenged myself to provision an entire production-style environment using Azure CLI. The objective wasn't simply to deploy virtual machines: it was to understand the deployment process, solve real-world problems, validate every resource, and document the entire journey.

The final environment included:

Ubuntu Server running Nginx
Windows Server running IIS
Windows 11 client VM
Shared Virtual Network
Network Security Groups
Public connectivity validation
Complete cleanup after deployment

More importantly, the project involved several real Azure deployment challenges that required investigation and troubleshooting before the infrastructure was fully operational.

Project Objectives

The goals of this lab were to:

Provision Azure infrastructure entirely with Azure CLI
Deploy Linux and Windows virtual machines
Configure virtual networking
Deploy a Windows 11 client VM
Install and configure Nginx
Install and configure IIS
Configure Network Security Groups
Validate public connectivity
Practice troubleshooting real Azure deployment issues
Document the entire implementation

Architecture

The deployed environment consisted of:

Azure Resource Group
Virtual Network
Shared Subnet
Ubuntu Server VM
Windows Server VM
Windows 11 Client VM
Network Security Groups
Nginx Web Server
IIS Web Server

Although this is a learning project, the overall deployment closely resembles the structure used in many production Azure environments.

Infrastructure Deployed

Resource	Name
Resource Group	rg-globalretail-prod-001
Region	West Europe
Ubuntu VM	vm-linux-web-01
Windows Server VM	vm-win-admin01
Windows 11 VM	vm-win11-ha
Virtual Network	vm-linux-web-01VNET
Subnet	vm-linux-web-01Subnet

Deployment Process

Step 1 — Creating the Resource Group

Everything began by creating a dedicated Resource Group to logically organize every Azure resource used throughout the project.

This became the container for all virtual machines, networking resources, storage, and security components.

Resource Group Created

Step 2 — Deploying the Ubuntu Server

The first virtual machine deployed was an Ubuntu Server running Ubuntu 22.04 LTS.

This server would later host the Nginx web server.

Deployment was completed using Azure CLI without touching the Azure Portal.

Linux VM Created

Step 3 — Deploying Windows Server

Next came the Windows Server virtual machine.

This VM would later host Internet Information Services (IIS).

The deployment wasn't completely smooth, however...

Real-World Troubleshooting

One thing I appreciated about this project was that it wasn't a perfect "follow-the-lab" experience.

Several real deployment issues occurred along the way.

Windows Computer Name Limitation

The initial deployment failed because the Windows computer name exceeded Microsoft's 15-character limit.

After shortening the VM name, deployment continued successfully.

Azure CLI Returned `ResourceNotFound`

Immediately after deployment, Azure CLI displayed a ResourceNotFound error for the Windows VM.

Instead of assuming the deployment had failed, I verified the environment using:

az vm list --resource-group rg-globalretail-prod-001 --output table

The VM had actually been created successfully.

This reinforced an important lesson:

Always verify the actual Azure resource state instead of relying solely on CLI output.

Windows 11 Deployment Failed

The Windows 11 deployment initially failed because Azure attempted to create a subnet that conflicted with the existing virtual network.

The solution was to query the existing subnet and explicitly specify it during deployment.

SSH Authentication Failed

Connecting to Ubuntu initially produced:

Permission denied (publickey)

After investigating, I discovered the local machine did not contain an SSH key pair.

Generating a new RSA key pair resolved the issue immediately.

Configuring the Servers

With the infrastructure successfully deployed, the next phase involved configuring the workloads.

Ubuntu

After connecting through SSH:

Updated package repositories
Installed Nginx
Verified the service was running

sudo apt update
sudo apt install nginx -y
sudo systemctl status nginx

Windows Server

After connecting through Remote Desktop:

Opened PowerShell
Installed IIS

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Network Security

Neither web server was initially reachable.

The reason?

HTTP traffic wasn't allowed through the Network Security Groups.

After creating inbound TCP port 80 rules for both virtual machines, browser access worked immediately.

This served as a good reminder that:

Infrastructure deployment is only one part of cloud engineering.

Networking and security configuration are equally important.

Validation

The environment was validated by confirming that:

SSH access worked correctly
Remote Desktop access worked correctly
Nginx was running
IIS was installed successfully
HTTP traffic was permitted
Both web servers were accessible from a web browser

Browser showing Nginx or IIS page

What I Learned

This project reinforced several important Azure concepts:

Azure regions don't always have capacity for every VM size.
Windows virtual machines have naming constraints.
Existing VNets and subnets should be reused explicitly.
SSH authentication requires both server-side and client-side configuration.
Azure CLI responses should always be validated.
Network Security Groups are critical for application accessibility.
Cleaning up cloud resources prevents unnecessary costs.

Most importantly...

Cloud engineering isn't simply deploying resources.

It's understanding how infrastructure, networking, security, authentication, and troubleshooting all work together.

Source Code

The complete project — including Azure CLI commands, deployment documentation, troubleshooting notes, and screenshots is available on GitHub:

👉 https://github.com/rahimahisah17/globalretail-prod-lab

Final Thoughts

This project pushed me beyond simply following documentation.

It required investigating deployment failures, validating Azure resources, solving networking issues, configuring Linux and Windows servers, and documenting every stage of the deployment process.

Every challenge became an opportunity to better understand how Azure behaves in real-world scenarios.

I'm looking forward to building even more production - style cloud infrastructure projects as I continue developing my Azure and cloud engineering skills.

Thanks for reading! If you have suggestions, questions, or similar experiences deploying infrastructure with Azure CLI, I'd love to hear about them.

azure #azurecli #cloud #cloudcomputing #devops #linux #windowsserver #nginx #iis #networking #cloudengineering

From Feature Branch to Container Registry: Building a Complete CI/CD Pipeline with Docker and GitHub Actions

Rahimah Sulayman — Fri, 17 Jul 2026 21:17:41 +0000

Building a Complete CI/CD Pipeline with Docker and GitHub Actions

Modern software delivery is about much more than writing code. Successful engineering teams rely on automation, collaboration, repeatable workflows, and reliable delivery pipelines to move software from development to deployment.

To strengthen my DevOps skills, I built a production-inspired CI/CD project that simulates the workflow used by modern engineering teams.

Rather than focusing on building a complex application, I focused on building a professional software delivery pipeline—from planning and development to automated container image publishing.

This project demonstrates:

Git workflow
Feature branch development
Pull Requests
Docker containerization
GitHub Actions automation
Continuous Integration (CI)
Continuous Delivery (CD)
GitHub Container Registry (GHCR)

Note: This article has been updated to include Continuous Delivery with GitHub Container Registry (GHCR), along with improvements made after the initial publication.

The complete project is available on GitHub:

👉 GitHub Repository

https://github.com/rahimahisah17/cloud-devops-ci-cd-lab

Project Objectives

The objective was to simulate a realistic DevOps workflow that mirrors how software is developed, reviewed, automated, and delivered in production environments.

The completed project includes:

GitHub Issues for task tracking
Feature branch development
Pull Request-based collaboration
Docker containerization
GitHub Actions automation
Continuous Integration
Continuous Delivery
GitHub Container Registry (GHCR)
Comprehensive project documentation

Technology Stack

Git
GitHub
GitHub Actions
Docker
GitHub Container Registry (GHCR)
Nginx
Linux (WSL)
Visual Studio Code

Development Workflow

Every feature followed a structured Git workflow before reaching the main branch.

GitHub Issue
      │
      ▼
Feature Branch
      │
      ▼
Development
      │
      ▼
Commit
      │
      ▼
Push
      │
      ▼
Pull Request
      │
      ▼
GitHub Actions
      │
      ▼
Build Docker Image
      │
      ▼
Publish to GHCR
      │
      ▼
Continuous Delivery

CI/CD Architecture

👩‍💻 Developer
│
▼
📁 GitHub Repository
│
▼
🌿 Feature Branch
│
▼
🔀 Pull Request
│
▼
⚙️ GitHub Actions
│
├── Repository Validation
├── Docker Build
└── Push to GHCR
│
▼
📦 GitHub Container Registry
│
▼
🚀 Deployable Container Image

Continuous Delivery with GitHub Container Registry

The project initially implemented Continuous Integration by automatically validating the repository and building the Docker image.

To extend the workflow into Continuous Delivery, I enhanced the GitHub Actions pipeline to:

Authenticate with GitHub Container Registry (GHCR)
Tag Docker images using the GitHub Container Registry naming convention
Automatically publish Docker images after successful workflow execution

Every successful pipeline execution now produces a deployable Docker image stored in GitHub Container Registry, making the workflow suitable for downstream deployment environments.

Containerizing the Application

The application is packaged inside a lightweight Docker container using Nginx.

FROM nginx:alpine

COPY index.html /usr/share/nginx/html/index.html

EXPOSE 80

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

Containerization ensures the application behaves consistently regardless of where it runs.

Automating CI/CD with GitHub Actions

Every push and pull request automatically triggers GitHub Actions.

The workflow performs the following tasks:

Validates the repository
Builds the Docker image
Authenticates with GitHub Container Registry
Publishes the Docker image to GHCR

This eliminates manual build steps while ensuring every change follows the same automated delivery process.

Debugging the Pipeline

One of the most valuable aspects of this project wasn't creating the workflow—it was troubleshooting it.

After migrating the application from Python to an Nginx-based static website, the CI pipeline failed because it was still validating a Python file that no longer existed.

Instead of simply rerunning the workflow, I:

Investigated the workflow logs
Identified the obsolete validation step
Updated the workflow
Verified the fix by rerunning the pipeline

Watching the workflow transition from ❌ failed to ✅ successful reinforced an important DevOps lesson:

CI/CD pipelines evolve alongside the applications they support.

Lessons Learned

This project strengthened my practical understanding of:

Git workflows
Feature branch development
Pull Requests
Docker containerization
GitHub Actions
Continuous Integration
Continuous Delivery
GitHub Container Registry (GHCR)
Pipeline troubleshooting
Technical documentation

More importantly, it demonstrated that successful DevOps projects are built through continuous improvement, testing, and iteration.

Explore the Complete Project

The repository has continued to evolve beyond the initial publication of this article.

It now includes:

📘 Professional README
📝 Detailed implementation log
📸 Step-by-step screenshots
🐳 Dockerized Nginx application
⚙️ GitHub Actions CI/CD workflow
🚀 Continuous Delivery to GitHub Container Registry
🏷️ Official v1.0.0 release
📄 MIT License

Final Thoughts

What began as a simple Docker containerization exercise gradually evolved into a complete CI/CD implementation using GitHub Actions and GitHub Container Registry.

Beyond the technical outcome, this project strengthened my understanding of Git workflows, automation, pipeline troubleshooting, Docker, and technical documentation.

More importantly, it reinforced that DevOps is not just about writing automation scripts—it's about designing reliable, repeatable engineering processes that enable teams to deliver software with confidence.

I hope this walkthrough helps anyone learning DevOps by showing what an end-to-end project looks like in practice.

Thank you for reading!

Happy learning! 🚀

If you found this project helpful, feel free to ⭐ the repository, share your thoughts, or connect with me here on Dev.to. Feedback and suggestions are always welcome!

Strengthening Identity Security with Conditional Access Policies in Microsoft Entra ID

Rahimah Sulayman — Thu, 09 Jul 2026 14:49:43 +0000

Introduction

As organizations embrace cloud-first environments, protecting user identities requires more than just strong passwords. Conditional Access in Microsoft Entra ID enables administrators to make intelligent access decisions based on user identity, device compliance, location, application, and risk, ensuring that only trusted users can access organizational resources under the right conditions.

In this hands-on guide, I'll walk through creating and configuring a Conditional Access policy, targeting specific users and cloud applications, enforcing access controls, and using the What If tool to validate policy behavior before deployment. These practical exercises demonstrate how Conditional Access helps organizations implement Zero Trust principles while minimizing the risk of misconfigured security policies.

Exercise - Perform basic Conditional Access policy tasks

In this exercise you will learn to create and configure a Conditional Access policy and test its results with the What If analysis tool.

This exercise should take approximately 10 minutes to complete.

Task 1 - Review a Conditional Access policy

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Conditional access submenu.

4.Review the information provided on the Conditional Access Overview page.

Note - You can see how many policies you have enabled, and how many users who have logged in recently that are not covered by a policy, along with other details(if you created any).
5.Select the + Create new policy from the top menu.

6.In the Name box enter Block Bhogeswar from using Sway.

7.In the Assignments section select 0 users and agents selected text.

In the Include section mark the Select users and groups item.
Put a mark in the Users and groups box.

When the list of users and groups opens, select Bhogeswar Kalita from the list.
Use the Select button to add the user.

Select the word Exclude to switch tabs.
Put a mark in the Users and groups box.
When the list of users and groups opens, select the admin user you are using from the list.
Use the Select button to exclude this user.

Lab tip - We have added a user for this policy and we have added an exclude for our admin, to make sure they are not accidentally locked out by a policy change.

8.Find the section Target resources section.

9.Select the No target resources selected text from this section.

Make sure Resources (formerly cloud apps) is chosen in the dropdown.
Put a mark in the Select resources item.
In the section titled Select choose the word None.
When the resource selection dialog opens, enter Sway into the search bar.
Put a check in the box next to Sway then use the Select button to approve the choice.

Lab tip - We have chosen the app Sway to be the resource this policy works on. You could choose multiple apps, or you could even choose to exclude apps.

Notice the name and target resource.

10.Open and review the Network section, but we are not going to use that for this lab.

11.Open and review the Conditions section, but we are not using it for this lab.

Lab tip - Network and Conditions are powerful options in the Conditional Access policy, but they are not required for this simple policy to block access to an app. You would use them if you wanted to do things like restrict access for user working from a specific location, or block access if a user has shown risky behavior. There are many granular options that you can choose from, or even combine together.

12.Find the section titled Access controls.
13.Under the word Grant select the text 0 controls selected.
14.When the Grant dialog opens, select the Block access item.

15.Use the Select button to accept the change.

Lab tip - You have not set the values needed to create a simple block access policy to the Sway app for Bhogeswar. In the Access controls section, we could have allowed access with specific conditions like MFA or a domain joined device.
16.At the bottom of the Conditional Access interface, find the Enable policy item.
17.Set the value to On.

18.Select the Create button.

Lab tip - You have three options to pick from, and you can change value at any time, without having to change the policy.

On = enables the policy to run
Off = turn the policy off in case you need to modify it.
Report-only = use this option to review the outcome of the policy before you fully turn it on.

Task 2 - Perform a What If analysis for a conditional access policy

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Conditional access submenu.
4.From the Conditional access screen select the What if option from the top menu.

5.In the section User or Workload identity select the text No user or service principal selected.
6.Make sure the box next to User is marked.
7.Select the text No user selected or Edit user.
8.From the Users list, put a mark next to Bhogeswar Kalita, then use the Select button.

9.In the Cloud apps, actions, or authentication context, select the text Any cloud app.
10.When the Select target type dialog opens, confirm that Cloud apps is chosen in the dropdown.
11.Click on the + Select cloud app.
12.Use the search to find the Sway app, then use the Select botton to finalize.

13.Scroll down to the bottom of the What If tool.

14.Select the button What If.

Note - the results appear off the bottom of the screen, so you will need to scroll down again.
15.You should see the Block Bhogeswar from using Sway policy listed, and it is blocking access.

16.You have to make selections for Device platform and Client app under sign-in conditions.

Subtask 1 - Try a different app in the What If analysis

1.Scroll back to the top of the What If tool.
2.In the Cloud apps, actions, or authentication context, select delete next to Sway and remove it..

3.Then select select cloud app to pick a new app.
4.Search for Office 365 Reports and choose it from the list, then use the Select button.

5.Scroll down to the bottom again.
6.Select the What If button.
7.You should see that the Block Bhoseswar from using Sway policy did not apply.

Summary

In this article, I demonstrated how to create and configure Conditional Access policies in Microsoft Entra ID, assign policies to specific users and cloud applications, define access controls, and validate policy behavior using the What If analysis tool. By testing policies before enforcement, administrators can confidently implement secure access controls, reduce the risk of unintended user lockouts, and strengthen their organization's identity security posture through a Zero Trust approach.

Securing User Identities with Multi-Factor Authentication (MFA) in Microsoft Entra ID

Rahimah Sulayman — Wed, 08 Jul 2026 21:54:23 +0000

Introduction

Passwords alone are no longer enough to protect user accounts from today's evolving cyber threats. Multi-Factor Authentication (MFA) adds an essential layer of security by requiring users to verify their identity using multiple authentication factors, significantly reducing the risk of unauthorized access caused by compromised credentials.

In this hands-on guide, I'll walk through configuring Multi-Factor Authentication in Microsoft Entra ID, including enabling and disabling per-user MFA, reviewing MFA service settings, and configuring account lockout policies. These practical exercises demonstrate how to strengthen identity security while balancing usability and administrative control in a modern cloud environment.

Exercise - Perform basic Multifactor Authentication tasks

In this exercise you will explore the MFA setup process and configure a basic MFA deployment.

This exercise should take approximately 10 minutes to complete.

Task 1 - Enable / Disable Per-user MFA settings

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Identity submenu
4.Select Users and then select All users.
5.Look at the menu on the top of the new screen and find Per-user MFA.
6.Select Per-user MFA.

7.Put a mark in the box next to Bhogeswar Kalita.

8.Select Enable MFA from the top of the list.

9.Read the message box that pops up.

Note - This is a manual URL that you can email to the user, if you want to let them know to set up MFA.

10.Select Enable button.

11.Then select the Enforce button.

12.Note that after a few seconds enforced shows up next to Bhogeswar’s name.

Task 2 - Review the Service settings for MFA

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Identity submenu.
4.Select Users and then select All users.
5.Select Per-user MFA item.

6.Select Service settings.

7.Review the settings you can configure:

Setting	What is it for
App passwords	There are some legacy apps that won’t work with MFA, use this setting to allow a user to keep using them.
Trusted IPs	If your company has a specifc set of IP-address ranges that are always known safe, you can allow users to by-pass MFA the logging in.
Verification options	Select the methods you are willing to allow users to use for their second factor of authentication.
Remember multifactor authentication on trusted device	If your users are using a device that you trust, like a company managed laptop, you can allow them to retain thier MFA approved status for a specified number of days.

8.Select the Discard button if you made any changes. Save if you want to deliberately make changes.
This is one method of configuring MFA for your users.

Task 3 - View MFA account lockout settings

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Protection submenu.
4.Scroll to the bottom of the list and select Show more.
5.Select Multifactor authentication from the menu.
6.Select Account lockout from the menu.
7.Set the following lockout values:

Field	Value
Number of MFA denials to trigger account lockout	3
Minutes until account lockout counter is reset	180
Minutes until account is automatically unblocked	15

8.Select the Save option at the top of your screen.

Review some of the other configuration options you have on MFA like:

Fraud alert
Block / unblock users
Notifications

Summary

In this article, I explored the core aspects of configuring Multi-Factor Authentication (MFA) in Microsoft Entra ID. I demonstrated how to enable and manage per-user MFA, review and customize MFA service settings, and configure account lockout policies to protect against repeated unauthorized sign-in attempts. By implementing these security measures, organizations can significantly improve identity protection, reduce the risk of account compromise, and build a more resilient authentication framework for their cloud environments.

Mastering Self-Service Password Reset (SSPR) in Microsoft Entra ID

Rahimah Sulayman — Wed, 08 Jul 2026 18:59:21 +0000

Introduction

Forgotten passwords are one of the most common reasons users contact IT support, often resulting in lost productivity and increased administrative overhead. Self-Service Password Reset (SSPR) in Microsoft Entra ID empowers users to securely reset or unlock their accounts without requiring help desk assistance, improving both user experience and organizational security.

In this hands-on guide, I'll demonstrate how to configure Self-Service Password Reset in Microsoft Entra ID by enabling SSPR for specific users or groups, configuring authentication methods, managing registration settings, and customizing notification options. These configurations help organizations streamline identity management while maintaining strong security practices.

Exercise - Perform basic Self-Service Password Rest (SSPR) tasks

In this exercise you will learn where the self-service password reset feature is located in Microsoft Entra and explore the process to configure it.

This exercise should take approximately 15 minutes to complete.

Task 1 - View the SSPR properties for a specific group

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open Password reset submenu.

4.Find the Self service password enabled bar.

Value	What it means
None	No users can use the SSPR feature
Selected	Only members of the selected group(s) can use SSPR
All	All users can use the SSPR feature

5.Set the value to Selected.
6.Select the text No groups selected.
7.Mark the Project233 group we created previously.
8.Use the Select button to complete your choice.

9.Save your configuration.

Subtask 1 - View SSPR authentication methods

1.Select Authentication methods from the menu within Password reset.

2.Select 1 as the value for Number of methods required to reset.

Note - this value represents how many different ways the user is required to sign-in to the password reset tool, before they are allowed to reset their password. Note that using a password is not an option.

3.Select Email, Mobile phone, and Mobile app code for Methods available to user.

Note - if you use Security Questions you have to specify the number of questions the user is required to create and answer.
4.Use the button at the top to Save your choices.

5.You have added an Authentication method to your self-service password reset.

Subtask 2 - View SSPR registration

1.Select Registration from the menu within Password reset.
2.Make sure the Require users to register when signing in? value is set to Yes.
3.Set the Number of days before users are asked to re-confirm… to 90 days.
4.Select Save to save your changes.

Subtask 3 - View SSPR reset notifications

1.Select Notifications from the menu within Password reset.
2.Leave the Notify users on password reset? at the default of Yes.
3.Change the Notify all admins when other admins reset their password? value to Yes.
4.Use the Save option to save your changes.

Summary

In this article, I explored the configuration of Self-Service Password Reset (SSPR) in Microsoft Entra ID, including enabling the feature for selected groups, configuring authentication methods, enforcing user registration, and managing password reset notifications. By implementing these settings, organizations can reduce help desk workload, improve operational efficiency, and provide users with a secure and convenient way to regain access to their accounts while strengthening overall identity security.

Strengthening Identity Security with Microsoft Entra ID Password Protection

Rahimah Sulayman — Wed, 08 Jul 2026 17:24:21 +0000

Introduction

Passwords remain one of the most common attack vectors in today's threat landscape, making strong password policies a critical component of identity security. Microsoft Entra ID provides built-in password protection capabilities that help organizations defend against brute-force attacks, password spraying, and the use of weak or commonly compromised passwords.

In this hands-on guide, I'll walk through configuring essential password protection settings in Microsoft Entra ID, including custom smart lockout policies, banned password lists, and enforcement options. These configurations help strengthen authentication security while improving the overall resilience of your organization's identity infrastructure.

Exercise - Perform basic Password Protection tasks

In this exercise you will explore the capabilities Microsoft Entra ID offers in protecting your password. You will see how you can automate and enforce a strong password, and use login restrictions to prevent password attacks.

This exercise should take approximately 5 minutes to complete.

Task 1 - View lock settings, and review duration and threshold values

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Authentication methods submenu.

Note - You could also search on Password protection in the search bar at the top.

4.Select Password protection from the list.
5.Set the Custom smart lockout with the following values.

Field	Value	Description
Lockout threshold	5	How many times can you fail to login with a password before your account locks.
Lockout duration	30	How many seconds the account should lock when the threshold is reached.

Note - You can also configure a custom banned password list here.

6.Set Enforce custom list to Yes.
7.Enter the following values:

-Contoso
-London
-Widget

Lab Tip - Your lab is being performed for a company called Contoso, located in London, and it makes Widgets. By enter these three words you block them from being part or a whole of a password.

8.Set the value for Mode to Enforced.
9.Select the Save item at the top of the screen.

Summary

In this article, I demonstrated how to configure password protection in Microsoft Entra ID by reviewing smart lockout settings, defining lockout thresholds and durations, creating a custom banned password list, and enforcing password protection policies. These security measures help reduce the risk of unauthorized access by preventing weak passwords and limiting password-based attacks, making them an essential part of any modern identity security strategy.

Mastering Microsoft Entra ID: Managing Users, Groups, Dynamic Membership, and Licensing

Rahimah Sulayman — Wed, 08 Jul 2026 15:54:40 +0000

Introduction

In today's cloud-first world, identity has become the new security perimeter. Managing users is no longer just about creating accounts, it's about organizing identities efficiently, automating access, and simplifying administration at scale.

In this hands-on guide, I'll walk through essential Microsoft Entra ID group management tasks, including creating Microsoft 365 and Security groups, configuring dynamic membership rules, adding users and licenses to groups, and exploring how group-based licensing simplifies administration. Whether you're preparing for the AZ-104 exam or building real-world Azure administration skills, these are practical tasks every cloud administrator should know.

Exercise - Perform basic Group Management tasks

In this exercise you will explore the beginner level tasks associated with creating and using groups. You make a new group and assign members and set some basic access levels.

This exercise should take approximately 15 minutes to complete.
Task 1 - Create a Microsoft 365 group

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Groups and then All groups.
4.Select New group option.

5.Enter the requested information:

Field	Value
Group type	Microsoft 365
Group name	Project233
Group description	This group consists of members of the new AI Simulation software with codename Project233
Membership type	Assigned

6.Under the Members heading, select No member selected.

7.Add Bhogeswar Kalita, by marking the box and choosing the Select button.
8.Select the Create button.

Task 2 - Create a Security group

5.Enter the requested information:

Field	Value
Group type	Security
Group name	Guest Users
Group description	This group has all the Guest users currently in the tenant.
Membership type	Dynamic User

6.Under the Dynamic user members heading, select Add dynamic query.

7.Create a dynamic query with the following values:

Field	Value
Property	userType
Operator	Equals
Value	Guest

8.Select the Save item from the top of the page.

9.Select the Create button.

Note - It will take up to 2 minutes for the group to be populate.
10.From the Groups select the Refresh item.
11.Select the Guest Users group we just created.
12.Select Members.

Task 3 - Add an existing user to a new group

6.Select + Add members from the menu near the top.

7.Mark the box next to External User and use the Select button.

Subtask 1 - Alternative method to add an existing user to a new group

1.Open the Users menu, then select All users.
2.Find and select External User from the list.
3.Select the Groups item from the menu.
4.Select the option to + Add memberships.

5.Mark an existing group and use the Select button to add them.

Task 4 - Add licenses and owners to a group

5.Choose the Owners option from the menu.

Note - Your tenant administrator will automatically be added as the owner of a group, if no owner is specified.
6.Select the + Add owners menu item.
7.Mark the box next to Bhogeswar and use the Select button.
8.Notice the new owner has been added to the group.

Subtask 1 - Adding a license to a group

1.Open a new tab in your browser.
2.Connect to Microsoft 365 admin cetner at https://admin.microsoft.com.
3.From the menu on the left, open the Billing section and select Licenses.
4.Select the Microsoft Power Automate Free license.

5.Select the + Assign licenses item.

7.Use the dropdown on the right side of the screen to select the Project 233 group created earlier.
Note: I I unassigned license to a group and created a security group called Project 233, which I assigned the license to. You cannot assign a Microsoft Power Automate Free license (or other Microsoft 365/Entra group-based licenses) to a Microsoft 365 group.
8.Use the Assign licenses button at the bottom of the screen.

9.Close the Your licenses are… notification.

10.Use the Refresh button to see the added group licenses.

Summary

In this article, I explored the fundamentals of group management in Microsoft Entra ID through a series of practical, hands-on exercises. I demonstrated how to create both Microsoft 365 and Security groups, configure dynamic user membership using rules, add users to existing groups, and assign Microsoft licenses through group-based licensing. Along the way, I also highlighted the differences between Microsoft 365 groups and Security groups, including why only Security groups support group-based licensing. These are essential identity and access management skills for Azure administrators and anyone preparing for real-world cloud administration or the AZ-104 certification.

Identity as the Perimeter: Scaling User Provisioning, RBAC, and Bulk Automation in Microsoft Entra ID

Rahimah Sulayman — Wed, 08 Jul 2026 11:41:39 +0000

Introduction

In modern cloud architecture, identity is the new security perimeter. As an infrastructure expands, managing access manually isn't just inefficient, it’s a massive security risk. Engineers must be able to scale user provisioning while maintaining strict governance and the principle of least privilege.

In this article, I break down a hands-on walkthrough of cloud identity engineering using Microsoft Entra ID. We will look past basic configurations to explore the real-world operational workflows every team needs: handling secure B2B guest invitations, mapping enterprise licensing, implementing granular administrative roles, and utilizing bulk automation pipelines to provision users at scale.

Here is the blueprint for building efficient, production-ready identity infrastructure in the cloud.

Exercise - Perform basic User Management tasks

In this exercise you will explore the beginner tasks of an Identity and Access administrator by creating and managing a user in Microsoft Entra ID. There are five common activities you will perform in your lab from creating a new user to assigning them roles and licenses.

This exercise should take approximately 10 minutes to complete.

Task 1 - Create a new user

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select User and then All users.
4.Select + New user and then pick the Create new user option.

5.Enter the requested information:

Field	Value
User principal name	BhogeswarK
Display name	Bhogeswar Kalita

6.Leave the Mail nickname as is.
7.Make a copy of the Password (auto-generated) and store it in Notepad. You will need it later.
8.Leave Accounted enabled checked.
9.Select the Properties tab.

10.Set the values for first and last name:

Field	Value
First name	Bhogeswar
Last name	Kalita

11.Note that you can set the User type to Member. If you pick Guest, it will restrict the users capabilities.

12.Scroll down to the bottom of the page.
13.Set the Usage location to United States or to whatever region you are in.
14.Select the Review + create button.

15.Select Create.

Subtask 1 - Log in to confirm user

1.Open an InPrivate browsing window.
2.Connect to the Microsoft Entra admin center at the link https://entra.microsoft.com.
3.Enter the username and password you just created.

Field	Value
Username	BhogeswarK@`your tenant name`.onmicrosoft.com
Password	`Auto generated password you saved`

4.If prompted follow the on-screen instructions to complete MFA setup.

5.Feel free to explore the Microsoft Entra admin center for a minute.

6.Close the InPrivate browsing window.

Task 2 - Add a license to the user

1.Open a new tab in your browser.
2.Connect to the Microsoft 365 admin center at https//:admin.microsoft.com.

3.If prompted, log in using the credentials for your tenant.
4.Find the menu on the left side of the screen.
5.Open the Billing item in the menu.
6.Select Licenses from the list.
7.When the list of licenses appears, select Microsoft Power Automate Free.

8.Select the + Assign licenses item.

9.Choose Brogeswar from the list (user created in previous task).
10.Select the Assign licenses button at the bottom of the page.

11.Notice the message that you have successfully assigned a license.

12.Close the tab with Microsoft 365 admin center.

Task 3 - Invite an external user to your tenant

1.If not already open - Open a browser and connect to the Microsoft Entra admin center at https://entra.microsoft.com.
2.If prompted, log in using the credentials for your tenant.
3.From the menu on the left, open the Identity menu.
4.Select Users then select All users.
5.At the top of the page select + New User.
6.Choose the option to Invite external user from the dropdown.

7.Enter the information for your new external user:

Field	Value
Email	ExtUser@testemail.com
Display name	External User
Message	Thank you for joining the company for this short work project. We look forward to building this project together.

8.Select the Review + Invite button.
9.Select Invite.

Task 4 - Assign a role to a user

1.If not already open - Open a browser and connect to the Microsoft Entra admin center at https://entra.microsoft.com..
2.If prompted, log in using the credentials for your tenant.
3.In the left menu find the Identity section. Open it if not already opened.
4.Select Users then select All users.
5.Choose the user Bhogeswar Kalita create in the earlier task.

6.From the newly opened menu select Assigned roles.
7.At the top of the screen select + Add assignments.

8.From the Select role dropdown menu chose the role Attribute Definition Reader.

9.Select the Next button when it becomes available.
10.Choose the option Eligible for Assignment type.
Select Assign.

Subtask 1 - Alternate method to assign a role to a user

1.Look at the Identity menu section on the left side of the screen.
2.Select the Show more option to see the full Identity menu.
3.From the list of items in the Identity menu, expand the Roles & admins section.
4.Select Roles & admins.
5.Select Attribute Log Reader from the list of roles.

6.From the top of the screen select + Add assignment.
7.From the Select member(s) select the No member selected text.
8.From the list of user choose Bhogeswar Kalita.
9.Choose the Select button at the bottom.
10.Select the Next button.

11.On the Add assignments page choose Active for the Assignment type.
12.Note that you have to enter a justification for this role / user assignment.
13.Enter the justification User will be working as an Attribute log reader as their primary job. into the box.
14.Select Assign.

Notice the Remove|Update option.

Task 5 - Bulk import users

1.If not already open - Open a browser and connect to the Microsoft Entra admin center at https://entra.microsoft.com.
2.If prompted, log in using the credentials for your tenant.
3.From the Identity menu, select Users and then select All users.
4.From the top of the page, select the Bulk operations drop-down arrow and then select Bulk create.

Note - Selecting Bulk create will open a new tile. This tile provides a Download link to a template file that you will edit to populate with your user information and upload to add the bulk creation of users.

5.Select Download to see a sample bulk user CSV file.

Note - The .csv template provides you with the fields included with the user profile. This includes the required username, display name, and initial password. You can also complete optional fields, such as Department and Usage location, at this time. You do not need to fill out all the fields.

Lab Tip - A sample CSV has been provided in the Allfiles/Lab1 folder – APL0501-BulkUser.csv.
6.Open Notepad.
7.Open the SC300BulkUser.csv file.
8.Search and replace the existing value «>> with Your actual domain name.
9.Save the file.
10.On the Bulk create users dialog, select the file folder icon on step 3.
11.Path to the Allfiles/Lab1 folder and select APL0501-BulkUser.csv file.
12.Select Open.

13.Wait for the notification that the file uploaded successfully. Select the Submit button to add the users.

Note - After the users have been created, you will be prompted that the creation has succeeded.

14.Close the Bulk create users dialog.
15.Check the list of users to see your bulk created users.

In summary, Identity is the foundation of secure cloud architecture. Managing access manually isn't just inefficient - it’s an operational risk.

This article breaks down a hands-on walkthrough of cloud identity engineering using Microsoft Entra ID. From enforcing the principle of least privilege with granular administrative roles and secure B2B guest access to scaling user provisioning through bulk automation pipelines, here is the blueprint for building secure, production-ready identity infrastructure.

From Fork to Pull Request: A Practical GitHub Collaboration Workflow

Rahimah Sulayman — Sat, 04 Jul 2026 14:11:19 +0000

Modern software development is built on collaboration, and GitHub is at the center of that workflow.
Every contribution to an open-source project starts with a single Pull Request. This article walks through a practical GitHub collaboration workflow, from forking a repository to submitting production-style Pull Requests for review using the same process followed by development teams.

This project reinforced practical version control skills that are essential in Cloud and DevOps environments, including working with feature branches, synchronizing forks, writing meaningful commits, and contributing through Pull Requests.

Step 1: Fork the Repository

The workflow began by creating a personal fork of the original repository. This provided an independent copy where changes could be made safely without affecting the upstream project.

The fork serves as the working repository for development before changes are proposed back to the original project.

Step 2: Clone the Repository

After forking the project, I cloned my fork to my local development environment using Git. This enabled me to work on the project locally while maintaining a connection to my GitHub repository.

The local repository became the workspace for implementing changes, reviewing modifications, and managing version history before publishing updates.

Step 3: Configure the Upstream Repository

To keep my fork synchronized with the original project, I configured the upstream repository as an additional remote.

This made it possible to fetch the latest changes from the original project before starting new work, ensuring my local repository stayed aligned with the latest codebase.

Step 4: Create a Feature Branch

A dedicated feature branch was created to isolate the changes from the main branch, following a standard collaborative Git workflow.

Step 5: Contribute to the Project

I updated the project documentation by adding my contributor profile and committed the changes using a descriptive commit message.

Step 6: Push the Feature Branch

The completed work was pushed to my GitHub fork, making it ready for review through a Pull Request.
The arrow points to the Pull Request link.

The link opened a Pull Request through which the feature branch was submitted for review, thereby allowing the repository owner to review and merge the contribution.
The Pull Request was approved and merged.

Step 7: Submit a Documentation Improvement

After the initial contribution, I created a second feature branch to improve the project's README by clarifying the browser prerequisites and submitted another Pull Request.

Summary

This repository reflects hands-on experience with collaborative software development using Git and GitHub. It showcases practical skills in branching strategies, repository synchronization, documentation contributions, and Pull Request-based collaboration—core practices used across modern engineering and DevOps teams.

I look forward to applying these skills in professional environments while continuing to expand my expertise in Cloud and DevOps technologies.

DEV Community: Rahimah Sulayman

YAML Learning Lab

Introduction

A Brief History of YAML

Project Overview

Project Setup

YAML Fundamentals

Mappings and Nested Structures

Sequences

Lists of Objects

YAML Data Types

Comments and Quoted Strings

Multiline Strings

Literal Block

Folded Block

Anchors, Aliases, and Merge Keys

Multi-Document YAML

YAML in GitHub Actions

Workflow Name

Trigger

Job

Runner

Steps

Final Configuration Challenge

YAML Validation

Validate All YAML Documents

Check for Illegal Tab Characters

Git and Repository Management

Why YAML Matters in Cloud and DevOps

Key Takeaways

Summary

Author

Dockerfiles: Building and Running a Node.js Application in a Container

Introduction

What Is a Dockerfile?

Dockerfile vs Docker Image vs Container

Dockerfile

Docker Image

Docker Container

Project Overview

Project Structure

The Node.js Application

Why package.json Matters

Building the First Docker Image

Understanding the Dockerfile

FROM: Choosing the Base Image

WORKDIR: Setting the Working Directory

COPY: Adding Application Files

RUN: Installing Dependencies

EXPOSE: Documenting the Application Port

CMD: Defining the Default Container Command

Why CMD Matters

Building After a Dockerfile Change

Inspecting Docker Images

Running the Container

Verifying a Running Container

Testing the Application

Troubleshooting a Failed Container

Using Docker Logs for Troubleshooting

Stopping and Removing a Container

Rebuilding and Retesting

Changing Application Output

Docker Build Cache

Dockerfile Best Practices

1. Use an appropriate base image

2. Keep the image focused

3. Take advantage of layer caching

4. Avoid embedding secrets

5. Run as a non-root user

6. Use explicit image tags

Dockerfile Instructions at a Glance

Dockerfile Workflow

Dockerfile vs Docker Compose

Key Docker Commands

Build an image

List images

Run a container

List running containers

List all containers

View container logs

Why `package.json` Matters

`FROM`: Choosing the Base Image

`WORKDIR`: Setting the Working Directory

`COPY`: Adding Application Files

`RUN`: Installing Dependencies

`EXPOSE`: Documenting the Application Port

`CMD`: Defining the Default Container Command

Why `CMD` Matters

Inspecting `compose.yml`

Docker Compose vs. Individual `docker run` Commands

Azure CLI Returned `ResourceNotFound`