DevOps from Zero to Hero: Build and Deploy a Production API

DevOps, the word that makes half of

YouTube tutorials feel like you don't

really belong. Like you should stick to

HTML while the real engineers handle the

big stuff. But when you try learning it

yourself, you're slammed with Docker

commands that look like alien code, YAML

files that read like broken poetry, and

the jungle of tools that never seem to

connect. That's the trap. DevOps gets

sold as a scary gatekeeping monster. And

the problem is that no one shows you how

this puzzle fits together. You either

get a 10-minute look, it works demo or a

six-hour death by PowerPoint lecture

that has nothing to do with the apps you

actually want to ship. So, welcome to

the full DevOps course where you'll

finally see the whole picture step by

step as we go from fundamentals to a

productionready API that looks and feels

like something you'd actually run in the

real world. Here's what you'll get. A no

BS intro to what DevOps actually is and

why it matters. A hands-on Git crash

course so version control stops feeling

like black magic. CI/CD pipelines that

deploy your code automatically. A Docker

crash course to containerize your apps

for dev and production. Kubernetes

deployments like real companies use

them. Infrastructure as code to spin up

environments on demand and monitoring,

logging, and security baked in from the

start. And of course, we won't end

there. In the signature JavaScript

mastery style, you'll then use this

learn knowledge to build and deploy

acquisitions, a realworld API for buying

and selling SAS businesses with tons of

features like JWTbased authentication

and authorization. Role- based access

control for admins and users. User

management for accounts. Business

listings to create, update, delete, and

browse. Deal management to track deals

from pending to completed. Health

monitoring of all the endpoints, request

validation using ZOD, structured logging

with Winston, completely secured

endpoints using Arkjet, a painless

security system for developers that

protects your app from bots, spam, and

abuse in real time. For the database,

we're using Postgress with Neon DB. It's

serverless, lightning fast, and built

for modern cloud apps that even work

locally. Adding on to it, Drizzle RM for

type- safe database queries, Docker for

containerizing applications across dev

and production environments, Kubernetes

to orchestrate containers at scale,

justest and superest for automated

testing and validating application

behavior, CI/CD pipelines for linting,

testing, deployment and automation,

clean absolute imports, eslint and

prettier for clean maintainable code and

much more using warp, the fastest way to

build and ship applications with AI.

It's an all-in-one environment where you

run commands, write code, and prompt top

AI agents in parallel. This isn't just

another DevOps demo. By the end, you'll

have hands-on experience and

productionready backend you can actually

ship tomorrow. And if you want to dive

deeper into building scalable

productionready back-end systems from

the ground up in a beginner-friendly

way, check out the upcoming ultimate

back-end developer course. It's the

perfect combination of strong

foundations taking you all the way from

core networking concepts all the way to

building and deploying APIs with full

DevOps and AWS integration. You can

either join the wait list if it's not

out or if you're lucky, it's already out

and you can get started with it right

away. So, grab your cup of coffee and

let's ship code like six figure salary

engineers. By the way, I recently opened

up channel memberships. So, if you've

been enjoying these videos and want to

support the channel, that's one of the

best ways to do it. In return, you'll

also get access to extra resources like

the Figma design files from my

tutorials, detailed cheat sheets paired

with this video, and even complete

ebooks. Plus, as a member, you'll

actually get a say in what I record next

for YouTube. It's totally optional, but

if you've been finding value here and

you're not quite ready to become pro

yet, if you want to dive a bit deeper

while helping me make these full courses

free, I would be thankful if you joined

today. Before we start building, let's

get our environment set up. Because

here's the thing, DevOps isn't something

you watch, it's something you do. And to

actually follow along without getting

stuck, you'll need the same stack I'm

using. The good news, it's all free. And

these are real tools companies are using

every day. First, make sure you've got

Node.js installed. That's the core

runtime we'll be using to build our

backend API. Then our database. We'll be

using a cloud Postgress provider called

Neon DB. This will power up everything

in our API. So, you'll want an account

ready before we dive in. Click the link

down in the description, create an

account, and you're good to go. Next,

Arjette. You can build the cleanest API

in the world, but if it's wide open to

bots, spam or abuse, it's useless. Arjet

gives you a real-time protection while

you build. So security isn't something

you tackle on later. It's there from day

one. And finally, warp. This is where

all the action happens. Running

commands, shipping code, and even

prompting AI agents to speed up your

workflow. It's a modern AI powered

developer environment you'll never want

to leave. And right now, their pro plan

is literally one buck, which makes it

kind of a no-brainer. So once you've set

those up, you'll have the exact stack

I'm using. That way when I say run this

command, you can run it too with no

interruptions, no detours, just straight

into building. Very soon, you'll build

and deploy your very own production

ready API. But first, let's dive right

into the crash course.

You've heard this term a hundred times,

but let's be real. DevOps sounds scary

as hell, right? Is it a job? A tool? A

secret club for 10x engineers with six

monitors and a tolerance for drinking

five Red Bulls? You're not alone.

Everyone feels like this at first.

DevOps sounds massive, mysterious, and

way too complicated. But here's the

truth. DevOps is simpler than it sounds.

And in this crash course, I'll break it

down like we're just chatting over

coffee. Here's how software used to

work. You write some code, it runs on

your laptop, you deploy to a server,

done. And if you're a vibe coder, you

might even skip testing entirely, push

it straight to production, and call it a

day. That actually works. If your app is

tiny, and no one cares if it crashes.

But the second your app grows, traffic

spikes, and the real money is on the

line, that's when this vibe ship starts

sinking. Servers crash, hackers attack,

thousands of users log in at once, and

your app dies at 3:00 a.m. Tell me, who

handles all that chaos? Early on, it was

the same developers writing features.

But most devs aren't trained to babysit

servers or fight off security attacks.

Their job is to build, not panic at

midnight. So companies created operation

teams or ops. They managed servers,

scaled apps, monitored uptime and

performance, applied security patches,

and got woken up at 3:00 a.m. when

everything broke. Honestly, props to

them. Ops became the guardians of

stability, while devs focused on speed.

So now you've got two camps. Devs who

ship features fast and ops who keep

things stable. So what happened? Well, a

tug of war. Devs tossed code over the

wall. Ops slow them down, blocked

releases, or spent weeks cleaning up.

Result: frustration, silos, and slow

delivery. So finally, DevOps was the

solution. Not a tool or a role, a

culture shift. It's about breaking down

silos so devs and ops work together.

Backed by automation, they deliver

software faster and safer. DevOps is a

culture of collaboration, a set of

practices for building, testing, and

releasing reliably and an automation

toolbox for deployments, monitoring, and

infrastructure. Think of your app like a

restaurant. Devs are the chefs who are

cooking meals or code, and ops are

waiters and managers getting meals to

customers. They handle servers and

uptime. Without DevOps, chefs would toss

random dishes onto the counter and hope

for the best. Chaos. With DevOps, the

kitchen runs like a welloiled machine.

Orders flow smoothly, food is

consistent, and customers are happy. So,

why not just Vibe Code? I mean, you can

skip all of this if your project is just

for fun, but once you have real users,

especially paying users, vibe coding

quickly turns into vibe burning. So,

let's skip the burnout and learn DevOps

the right way.

You have a sense of DevOps, but not the

full picture yet. You might be thinking,

I get that DevOps is a culture, but how

do I learn it? And what does it look

like day-to-day? If you've ever Googled

or chat GPT, if that's even a word, the

term DevOps, you've definitely come

across the famous infinity loop diagram.

You know the one where arrows chase each

other endlessly labeled plan, code,

build, test, release, deploy, operate,

and monitor. That loop is not just a

conference graphic even though it looks

that way. It is the process of how an

idea becomes software in users hands and

then gets better with feedback. Dev and

ops are connected the entire time. So,

let me show you what each stage means in

practice. We start with a plan. Imagine

you're building a multi-million dollar

SAS application. Doesn't hurt to

imagine, right? Before a single line of

code, you decide what you want to build,

when to ship, who owns that, and how you

will measure success. Page speed, user

growth, revenue, and make it traceable,

not sticky notes that'll disappear. Use

tools that the team will actually keep

up to date. Be it Jira, Linear, GitHub

projects, or just notion, the tool is

less important than the discipline. A

plan without action is just a dream. So

make it explicit and visible. Once we're

done with planning, we move over to

code. Code quality matters as much as

code output. So write clean, modular,

and testable code that others can

extend. Use Git with reviews, branch

rules, or automated checks, ship

readable code, and not hacky solutions

that only you can understand. And now we

enter the build phase. Because when you

finish writing source code, it's still

just raw text files. Those files cannot

always be executed directly in

production. They often need to get

compiled or transpiled. Dependencies

need to get installed. It needs to get

bundled or packaged like in Docker. And

we need to check for linting or security

mistakes. The build step is all about

preparing code so it can actually run an

artifact, a ready to run package. Think

of it like baking dough into bread. You

can't eat raw dough, which is the source

code. So you can bake it build into

something edible, an artifact. In

DevOps, this process is automated for

consistency. You build Docker images,

run containers through make files, and

build them every time you make a commit.

You'll learn all of that in the next

lesson. And then we get to testing. Of

course, you wouldn't want untested code

to reach production. The test stage

exists to catch problems early when

they're still cheap and easy to fix.

Automated tests run as part of the CI

pipeline, covering everything from basic

unit tests to integration tests,

end-to-end workflows, and security

scans.

For instance, let's say you're building

a payments feature. Unit tests verify

the math for totals. Integration tests

ensure the checkout flow works with a

database. And end-to-end tests simulate

a customer actually completing a

purchase.

Security tests scan for vulnerable

dependencies or insecure patterns. And

by the time the code passes all of these

stages, the team can be confident that

it behaves as expected and won't break

the system when deployed. All of this

runs in automation pipelines. So when

all the tests pass, the build is finally

marked as ready for release. This

doesn't mean it's already running in

production. It means that the artifact

has been approved and cued for

deployment. Think of this as moving from

dev to ops. In practice, the release

stage involves versioning, tagging

artifacts, and pushing them into a

release repository like Docker Hub,

Nexus, or an internal store. This

ensures the exact same build that was

tested will be the one deployed later

on. No surprises or mismatches. And then

comes the big moment, deployment. In

traditional setups, someone might have

to log into a server at 2 a.m. to run

some manual scripts. But in DevOps,

deployments are automated and

repeatable. Pipelines handle the

process, and tools like Kubernetes

orchestrate deployments at scale. But

more on that soon. For now, understand

that you have to use these tools to

build pipelines for automated

deployments that scale up and down based

on defined needs. For example, when

deploying a new version of a web app,

Kubernetes might spin up new pods with

the updated code while gradually phasing

out the old ones, a strategy known as

rolling deployment. This ensures a

minimal downtime and a smooth user

experience. Some teams even practice

blue green deployments or canary

releases to test new versions with a

small subset of users before rolling out

widely. And once deployed, the

application is live. But the work isn't

over. You have to operate. See, the

operate stage is all about ensuring the

system continues to run reliably under

real world conditions.

This includes monitoring server health,

scaling resources when traffic spikes,

applying security patches, and managing

infrastructure configurations. Think

about an e-commerce platform on a Black

Friday. At 2 p.m. traffic might

skyrocket, requiring the system to scale

horizontally across multiple servers. At

2 a.m., when traffic is low, resources

can be scaled down to save costs. DevOps

teams ensure that the system is

resilient, stable, and performant at all

times. So, finally, we have the

monitoring. Here teams gather data about

the systems performance. Uptime, error

rates, and business metrics. Monitoring

tools like Prometheus, Graphana, Data

Dog, New Relic, or Century act like CCTV

cameras for your app. They let you see

not only technical metrics like CPU

usage, latency or error logs, but also

business outcomes like orders processed,

signups completed, and revenue

generated. For instance, if your new

checkout flow increases card

abandonment, monitoring will catch it.

That insight then loops back into the

plan stage where the team can adjust

priorities and improve the product and

then the cycle starts again. That's the

beauty of DevOps. It never really stops.

Each stage feeds the next, forming a

continuous loop of building, testing,

delivering, operating, and improving.

And it's not just a set of tools or a

job title. It's a culture of constant

learning and iteration. But wait, does

that mean that as a DevOps engineer,

you're expected to handle everything in

this cycle? Are you supposed to code

like a developer, test like a QA, deploy

like ops, and monitor like SRRES? That's

a great question. No, you're not

supposed to do everything. This is one

of the biggest misconceptions about

DevOps. If DevOps is a culture, a way of

working where dev, ops, QA, and security

work closely together, then a DevOps

engineer is not a superhum who replaces

all those roles. Instead, your role is

all about bridging the gap between

teams, automating the boring or manual

work so teams can move faster, and

setting up tools and practices that make

collaboration smoother. See, developers

still write features. QA still ensures

quality. Ops still keeps server running,

but as a DevOps engineer, you make sure

that all these moving parts are

connected and running without chaos. So,

what does a DevOps engineer actually do?

You're not here to replace developers,

QA, or ops. You're here to connect all

the dots and keep things running

smoothly. So let's run through the

entire life cycle once again, but from

your point of view. When it comes to the

planning phase, developers and product

managers decide what to build. You make

sure that planning tools like Jira,

Confluence, or notion are wired into

your pipeline. For example, when someone

closes a Jira ticket, it should link

straight to a commit or a deployment

log. In the coding phase, you're not

writing every feature, but you set the

rules of the road. Branching strategies,

code review requirements, autolinting,

and security scans all run

automatically. So code quality stays

high. Then in the build phase is where

raw code becomes something that can

actually run anywhere like a Docker

image. Your job is to set up pipelines.

So this happens on every commit

consistently with zero manual steps.

When it comes to testing, QA owns it,

but you make it effortless. You

integrate unit tests, integration tests,

and security scans into the pipeline so

bugs get caught early before they even

reach production. And then for the

release and deploy phases, this is where

you shine. Instead of someone sshing

into a server at midnight, you automate

deployments with Kubernetes. Terraform

or Helm. In the operation phase, the ops

teams keep everything alive, but you

help them codify the infrastructure with

Terraform or cloud for set scaling rules

and make systems highly available. An

example of this would be spinning up a

new AWS cluster with a single config

file instead of spending hours in the

console. And finally, in the monitor and

feedback phase, once the code is live,

you keep watch. Metrics, logs,

dashboards, and alerts feed straight to

Slack or Teams. If something breaks or

slows down, you know it before customers

do. So, no, you're not coding the app

and writing tests and running servers

all by yourself. You're the air traffic

controller. Developers fly the planes or

build the features. Ops is the ground

crew. QA is the safety check. And you're

in the tower keeping everything smooth

and safe.

Let's dive into the heartbeat of DevOps.

CIC CD. But what does that actually

mean? Well, picture a kitchen in a

restaurant. The chef chops the

vegetables. The assistant cooks them.

The manager inspects the dish. And the

waiter finally serves it to the table.

If every step was manual, the service

would be slow. In the same way, we

manually go through different stages

such as coding, building, testing, and

deployment. Pretty manual, right? Now,

imagine a conveyor belt moving the dish

automatically from one step to the

other. That's a pipeline. It's an

automated conveyor belt for software.

So, let's break it down. CI stands for

continuous integration. Every time a

developer pushes code, tests run

automatically. And if something breaks,

the pipeline stops and you fix it before

moving forward. CD stands for continuous

deployment where once tests pass, the

app is automatically deployed to staging

or production. No late night manual

deployments. Your job is to write these

pipelines using tools like GitHub

actions, GitLab CI, Jenkins, or

CircleCI. You'll define each step from

build, test, release to deploy. Back in

the day, running apps was messy. You'd

install them directly on servers, and if

one needed version 18 of Node.js and

another one needed version 20, you'd

have conflicts everywhere. Containers

solve this by packaging apps with

everything they need. The most popular

tool here is Docker. Now imagine not

just one container, but hundreds of them

for microservices, background jobs, and

databases. Someone needs to decide where

do these containers run? How many copies

do we need right now? What happens if

one crashes? And how do they securely

talk to each other? That's called

orchestration. And the go-to tool here

is Kubernetes, which acts like the

conductor of an orchestra, coordinating

containers, so everything runs smoothly

and scales automatically. Traditionally,

people clicked around in a cloud

dashboard to create servers and

networks. That's like building IKEA

furniture without instructions. Slow,

errorprone, and almost impossible to

recreate. With infrastructure as code or

ISC for short, you describe your entire

setup. Servers, networks, databases, all

in code. You store it in Git, review

changes, and recreate environments any

time. Tools like Terraform or AWS Cloud

Form make your infrastructure

predictable and repeatable. So if

something goes down, you just rerun your

code to rebuild it from scratch. And

almost no company runs their own

physical service anymore. Instead, they

rent them from cloud providers like AWS,

which are Amazon's web services, Azure

from Microsoft, or GCP, which is Google

Cloud Platform. You don't need to master

all three. Focus on one primary

provider. AWS is the most common. And

get comfortable deploying apps, setting

up networks, and managing storage. Once

you know one well, switching to another

is easier. Like learning to drive one

car and then trying out a different

brand. And once your app is live, you

need visibility. Monitoring and logging

tools show what's happening in real

time. Not just server performance, but

also user behavior and errors. You've

seen me use Sentry in some of my

projects to track errors and

performance. That's a great starting

point. Some DevOps teams use different

tools like Prometheus and Graphfana for

custom metrics and dashboards, Elk Stack

or Data Dog for centralized logs, or

Post Hawk for product analytics and

funnels. With the right setup, you know

about problems before your users do. And

finally, scripting ties everything

together. A DevOps engineer should be

comfortable with at least Bash or Shell

scripting and one programming language

like Python or JavaScript. Why? Because

automation is the heart of DevOps. And

if you're onboarding 10 new developers

and need to set up their accounts and

permissions, don't just click through

dashboards 50 times. Write a script once

and automate the whole process.

I know it's a lot, but if you take it

step by step from Git, pipeline,

containers, ISC, cloud monitoring, and

scripting, you'll go from confused to

confident pretty fast. And in this

video, we'll skim the surface of each

one of these topics in a

beginnerfriendly way. And if you'd like

some deep dives on advanced DevOps

concepts, drop a comment down below and

I'll make it happen. Imagine you're

working on a coding project and you make

a mistake that breaks everything. Your

boss would most likely fire you if you

were even able to get a job in the first

place. Without Git, you'd have no easy

way to go back and undo the changes.

You're toasted. Git is the industry

standard. Most companies, team, and

open- source projects use Git. So,

naturally, every job description

mentions it. Learning Git isn't just a

nice to have. It's your get good or get

out moment. It's a must for any serious

developer wanting to land a job. So,

what is Git and why is it so popular?

Git is a distributed version control

system. Sounds fancy, right? Well, let's

break it down. The version control part

helps you track and manage code changes

over time. While distributed means that

every developer's computer has a

complete copy of the codebase, including

its entire history of changes and

information about who changed what and

when, allowing you to get blame someone.

Hopefully, people won't blame you. But

do you really need it? Can you code

without using it? Well, of course you

can, but then your workflow would look

something like this. You start coding

your project in a folder named my

project. And as you make progress, you

worry about losing your work. So you

create copies, my project v1, v2, v3,

and so on. Then your colleague asks you

for the latest version. You zip up my

project v3 and email it over. They made

some changes and sent it back as my

project v3 johns changes.zip. zip.

Meanwhile, you've continued to work. So

now you have my project V4. You then

need to manually compare J's changes

with your V4 and create a V5

incorporating everyone's work. And then

a week later, you realize you

accidentally removed a crucial feature

in V2. You dig through your old folders

trying to figure out what changed

between versions. Now imagine doing this

with 10 developers, each working on

different features. It's a recipe for

chaos, lost work, and countless hours

wasted on a version management system

instead of actual coding. Git solves all

of these problems and more. It tracks

every change automatically, allows

multiple people to work on the same

project seamlessly, and lets you easily

navigate through your project's history.

No more final version v2 final, really

final zip files. Git does all of this

for you, but in a much more powerful and

organized way. To get started, you need

Git installed. Whether on Windows, Mac,

or Linux, it's just two clicks away.

Google download Git and get it for your

operating system. Once Git is installed,

open up your terminal. Nowadays, I

prefer using a terminal built into my

IDE. First things first, let's check

whether you've installed Git properly.

run git d- version and you'll get back

the version that is installed on your

device. Next, you need to configure git

to work with your name and email. This

is just to track who made the changes in

the project so your colleagues know who

to blame. Here's the command. git

config- global user.name and then in

single quotes put in your name. Once you

do that, you can repeat the same

command, but this time instead of

changing user.name, we'll change user.

And here you can enter your email. Press

enter. And that's it. You're all set up.

Now, let's talk about repositories. A

repo or a repository is where Git tracks

everything in your project. Think of it

like a folder that stores all the

versions of your code. Simply put, if a

folder is being tracked by Git, we call

it a repo. Now, let's create a new

repository. In your terminal, type git

in it and press enter. As you can see,

git has just initialized a new

repository. On top of the success

message, we can also see a warning. In

previous times, the default name of a

branch has been master. But nowadays,

you'll see main used much more

frequently as the name for the primary

branch. So, let's immediately fix it by

configuring the initial branch name. You

can copy this command right here. And at

the end, you can just say main.

Now, considering that we have just

changed the initial configuration

settings, we have to create a new

folder. create a new one called

something like mastering git. Open it

within your editor and then rerun git in

it. As you can see here and here, now

we're in the main branch. That means

that git has initialized an empty

repository. You won't see any changes

yet in your folder, but a hidden.git

folder has been created inside your

directory. You don't need to touch this

folder. Git handles everything inside

from commit history, branches you'll

make, remote repos, and more. Most of

the time, Git will already come

pre-initialized by the framework or

library that you use to set up your

project with. That's how integrated Git

is into every developer's life. So now

that we have this main right here, what

does that exactly mean? Well, main is

the default branch name of your repo

created by Git. Every time you

initialize git, this branch will be

automatically created for you. I'll

teach you more about Git branches soon,

but for now, know that a branch is

nothing but a parallel version of your

project. All right, let's add some files

and track changes. I'll create a new

file called hello.js.

And you can see how smart WebStorm is.

It automatically asks me whether I want

to add it to Git. But for now, I'll

cancel that because I want to explain

everything manually. Let's make it

simply run a console.log that prints

hello get. Alongside this file, let's

create another new file and I'll call it

readme.md.

In here, we can do something similar and

say hello get. And now run git status.

Git will tell you that you're currently

on the main branch, that there are no

commits yet, and that there are two

unttracked files, one of which is a

markdown document. So to track it, use

git add readme.md.

After adding a file, we need to commit

it. Committing in git is like taking a

snapshot of your project at a certain

point. Think of it as creating a whole

new copy of your folder and telling git

to remember when you did it at what

time. So in the future, if anything

happens, you'll time travel to this

folder with the commit name you specify

to git and see what you had in there.

It's essential to commit your changes

regularly. Regular commits help you keep

track of your progress and make it

easier to revert to previous versions if

you break something. You can commit by

running get commit-m

which stands for message and then in

single quoted strings you can add that

message. For example, add readme.md

file. There we go. Congrats. You just

created a checkpoint in your project's

history. Now let's try running git

status again to see what it shows. As

you can notice that other file hello.js

is still there. It's not tracked. We

asked git to track only the readme file.

To track this file or other files that

you may create, we'll have to run a

similar command. It'd be too much work

to commit each file individually.

Thankfully, we have a command that

commits all the files we've created or

modified that Git is not tracking yet.

To see this in action, let's create

another file test.js

and let's add a simple console log that

simply console logs a string of test.

Now to track both files and commit them

in a single commit action, we can do

that by running git add dot. The dot

after git add tells git to add all files

created, modified or deleted to the git

tracking. Next, as usual, we can specify

the commit name for this tracked version

by using git commit-m

add hello and test files.

There we go. So now you can see that all

of these files are tracked. And since

I'm using webstorm, it also has a hidden

ideid folder. So it added it to tracking

as well, which I'm okay with. Well done.

Now to see the history of all commits

we've created, we can use a new command

get log. And there we have it, our git

history. It contains a commit ID or a

hash automatically created by git, the

author we specified when using git

config, a timestamp, and the commit

message we provided. Great. But how do

we switch to an older commit and restore

it? Let's say the commit add hello and

test files introduces some buggy code

and we want to restore our project to a

previous version without these files.

our brain would immediately suggest

deleting those files entirely or

clearing up their code. And if you do

that, you'll most likely break your

production because other files depend on

those files. So instead of deleting them

manually to restore to the first version

where we had only committed the readme

file, we can use a new command. First,

you have to copy the commit hash. Yours

is going to be different from mine. So

make sure to copy yours. I'll get this

one first that says add readme file. and

I'll press copy. Then you have to exit

this git log by pressing the Q letter on

the keyboard. And then you can use a

command get checkout and then you can

provide a hash of a specific commit or a

branch you want to check out too. Now

press enter. Okay, something happened.

First of all, our two files are gone.

Detached head experimental changes.

What's happening? Well, in git there is

a concept of a head which refers to the

pointer pointing to the latest commit

you've created. When we created our

second commit, our head shifted from

readme commit to the latest add hello

and test files commit. But when we ran

get checkout command, we moved the head

to the previous older commit. That's why

we got this detached head warning. It's

a state where the head pointer no longer

points to the latest branch commit. And

the rest of this message tells you that

you can create a new branch off of this

commit. But don't worry, your files are

still somewhere. When you use a git

checkout command, you're simply viewing

the repository state as it was at the

time of a specific commit. Like right

now, we're viewing a snapshot of your

codebase at a previous moment in time

when we only had a readme.md file. The

beauty of this is that all the logs and

files, whether created or modified,

remain untouched. The get checkout

command won't delete any logs or

history, so you can safely explore past

states without worry. But what if you

actually want to discard changes made

after that commit? Maybe you want to

quickly roll back to a stable state

after an issue hits production, tidy up

messy commits to look more professional

or undo a bad push you regret making.

Perhaps you've been experimenting with a

refactor that didn't pan out, or you

need to recover from a messy merge

conflict. Thankfully, Git provides a few

commands that'll help you in these

scenarios and I'll teach you how all of

that works very soon. So, just keep

watching and we'll dive into these more

advanced commands that are really going

to help you well fix a broken

production. Now, to go back to a current

state, which is often called the head

state, you simply have to run get

checkout main. And there we go. Previous

head position was at the hash of this

checkout. And now you switch the branch

to main. You can see the same thing

happen right here on the bottom right or

the top left depending where your

branching is. And if you made any

changes while in the detached head state

and you want to discard them, you can do

the same thing. Get checkout dash if

that means force and then get back to

main. In this case, we're good. We're

already on main. And that's it. You

already know more about git than most

developers do. Of course, we'll dive

deeper into advanced use cases and tips

and tricks soon, but now let's talk

about GitHub and how it differs from

Git. Git is a tool you use to track

changes. Whereas GitHub is a cloud

platform that allows you to store your

Git repositories online and collaborate

with others. To push your local project

to GitHub, you'll need to link your

repository to a remote. But what's a

remote? Well, there are two types of

repositories. Local repository is a

version of a project that exists on your

own machine, laptop, or whatever else

you use where you do your developer

work. When you initialize a repo using

git init, you create a local repo in

your folder. Changes you make there are

private until you push them to a remote

repository.

So a remote repo is a version of a

project stored on a server like GitHub,

GitLab or Bitbucket. It's used to share

code between collaborators and keep

project versions in sync across

different users computers. When

collaborating with a team, you'll have

two kinds of repos. Everyone in the team

will have a local repository on their

machine and there will also be this one

common remote repo from which everyone

will sync their local repository

versions. Now head over to github.com

and create an account if you don't

already have one. Once you're in, press

the little plus icon on the top right

and select new repository. Enter a

repository name such as mastering git.

Choose whether you want to make it

public or private. Leave the add readme

file checkbox unticked and click create

repository.

This is a remote repository. Here you

can see your repository's origin. Copy

it. When you clone a repository from

GitHub, Git automatically names the

remote repository as origin by default.

It's basically an alias for the remote

repositories URL. Now, our goal is to

link our local repository to the remote

origin. If you haven't yet switched the

default master branch name to main, you

can do that by running git branch- m

main and this will change the branch

name to main which is a standard

practice nowadays. And now we are ready

to link our local repo to a remote

origin. You have to run a command get

remote add origin and then you have to

paste the link to the origin that you

just copied and press enter. And a good

thing to know is that you can have

multiple remote repositories. You just

have to rerun the command and change the

origin name to something else. Of

course, that's the name of your choice.

And then you can also update the new

URL. But in most cases, you'll be fine

with just one remote repo. Finally, to

push your local commits to GitHub, use

get push-

origin main. And remember, we used

origin here to refer to the remote

repository instead of typing the full

URL.

So, press enter. And there we go. This

worked. If anything with git goes wrong,

typically it goes wrong at this point

when you're trying to push to a remote

repo. So, if you don't see what I'm

seeing right here, and instead you got

some error, typically all of these

errors are very easily resolvable. I

would just recommend copying the error

message, pasting it in Google, and then

fixing it right there and then. But in

this case, we're good. And now, if you

go back to your GitHub repository and

reload, boom, your code is now online

for the world or your team to see. And

okay, okay, you might have already known

this. For some of you, that's about as

far as you've gone with Git. create a

repo, push your changes, and call it a

day. But Git has so much more to offer,

especially when you're working within a

team. So now, let's take things up a

notch and dive into branching and

merging. This is where Git truly shines.

Branches in Git allow you to create

different versions of your project, like

making a copy of a project at a specific

moment in time.

Whatever changes you make in this copied

version won't affect the original. The

main project or branch stays untouched

while you experiment, modify, or add new

features in the copied branch. If

everything works out, you can later

merge your changes back into the

original project. If not, no worries.

The original remains safe and unchanged.

When working in a team, using separate

branches for different features or bug

fixes is essential. It allows you and

your team to work independently on

different parts of the code without

causing conflicts or errors, ensuring

everyone can focus on their own tasks.

At the start, you'll have one default

branch called main. To create a new

branch, run get branch and then type a

branch name.

This will create a new branch. And if

you want to switch to this newly created

branch, then run get checkout and then

enter the branch name you want to check

out too. And there we go. Switch to

branch branch name. Now, if you want to

go back to main, just run get checkout

main. There we go. And here's a little

pro tip. There is a shortcut to create a

new branch and immediately move to it.

To do that, run git checkout with a

-ashb flag and then enter a branch name

such as feature branch. Of course, this

branch name and feature branch are just

dummy names. Make sure your branch name

is short and explains which changes will

you be making on that branch. For more

tips on how to properly name your

branches, you can download the git

reference guide. So, let's create and

move to this feature branch in one

command. There we go. And what I'm about

to say next is very important. So keep

it in mind. When you create a new

branch, it'll be based on the branch

you're currently on. So if you're on the

main branch and run the command, the new

branch will contain the code from the

main branch at that point in time.

However, if you're on a different branch

with different code, the new branch will

inherit that code instead. So to ensure

you're creating the new branch from the

correct starting point, you should

either first switch to the branch you

want to base the new one on or run this

command get branch. Then you can enter a

new branch name

and then the next thing can be the

source branch. So if you do it this way

and replace the new branch name and the

source branch with the names of actual

branches, then it'll create a new branch

from another specific branch. So if you

run this command, you can directly

create and switch to a branch based on

any other branch without needing to

check out to it first. For now, I'll

remove that. And let's say that we want

to go into our code and implement this

feature we're working on. Let's say that

in our case the only feature we want to

do is to modify the readme. So below

hello git I'll say I'm adding this from

feature dash branch. There we go.

Feature implemented. If only it was this

easy. And you can see that our IDE

immediately highlighted this readme file

in blue indicating that it has some

changes. Now we need to add it commit it

and push it. This time instead of saying

get add readme md let's just use the get

add dot which is a command that you'll

use much more often. Next we need to

commit the changes with git commit-m

and then we have to add a commit

message. So this is the perfect time to

learn how to write a proper commit

message. A quality commit message is

written in the imperative mood. a

grammatical mood that sounds like you're

giving a command

like improve mobile responsiveness or

add AB testing. When writing your commit

message, make it answer this question.

If applied to the codebase, this commit

will and then fill in the blank like

this commit will upgrade the packages or

this commit will fix thread allocation.

And why do we do this? Well, because it

answers the question, what will happen

when I merge the branch containing this

commit? It will add AB testing. For

example, be direct and eliminate filler

words. For example, let's use modify

readme. In this case, it's short, sweet,

and in an imperative mood. And press

enter. There we go. We've just made get

aware of our commit. Now that you know

how to write better commits, let's take

a moment and check out our remote

repository. What do you think? Will it

have the latest commit we made? Let's

reload it. And it's the same. It doesn't

contain our newly created feature

branch. Do you know why? It's because

the changes we made are in the local

repository, which has not yet been

synced with the remote repo. To see

those changes, first you'll have to

publish your local branch. And you can

do that using the git push d- set dash

upstream origin and then the name of the

branch. In this case, feature dash

branch and press enter.

There we go. An upstream branch is a

remote branch that your local branch

tracks. When you set an upstream branch

using set upstream, you're essentially

linking your local branch to a branch on

a remote repo. Through this command, you

push a local feature branch to the

origin remote repository and then you

set the upstream branch for your local

feature branch to track origin feature

branch. Alternatively, you can also use

get push- u origin feature- branch or

the name of your branch. Of course, both

set upstream and -ash u establish a

tracking relationship between your local

branch and the remote branch. This way,

in the future, if you want to push

something from your local branch to your

remote branch, you simply have to run

get push. That's it. At this moment for

us, everything is up to date. But as you

make future changes, you don't have to

rerun set upstream or -ashu. You only

have to add it, commit it, and push it.

That's it. And if somebody else made

changes to your remote branch, either

directly or by merging some other

changes into it, you have to make your

local branch up to date with the remote

branch. And you do that by using the get

pull command. There we go. It's already

up to date in this case. This command

fetches changes from the remote repo and

merges them into your local repo for

that branch. There are all and the story

doesn't stop there. Git has plenty of

advanced features like merge conflicts,

reset, revert, stash, cherrypick, and

more. And if you want to truly master

Git, I've got a complete crash course

waiting for you on YouTube, totally

free. You'll find the link down in the

description. But for now, what you've

learned so far is enough to kick off

your DevOps journey. Though, it's

definitely just the beginning. Make sure

to keep digging deeper into Git as you

grow. You'll soon use this knowledge to

build pipelines that automatically

build, test, and deploy code to staging

or production servers. And guess what?

That entire process begins with a simple

Git push. Git also plays a huge role in

managing infrastructure with tools like

Terraform or Pulumi. Your cloud setup

whether it's virtual machines, databases

or networks, lives inside a TF or ayaml

files in git repository. Change a line,

commit and push, and your entire

infrastructure updates automatically.

All in all, in DevOps, you might not

always write the application logic

yourself, but you'll constantly review

PRs, check configurations, and maintain

secure workflows. GitHub or GitLab pull

requests will become your daily

workbench. And now you know exactly how

they work. And once you've mastered Git,

you're ready for the next big leap of

building pipelines that take your

commits and turn them into live runnable

applications. So, let's dive into that

next.

CI/CD pipelines. What are those? Well, a

pipeline is just a set of automated

steps that takes your code from the

moment you push it all the way to

production. Instead of manually running

mpm install, mpm test, docker build, and

cubectl apply. Every single time, your

pipeline does it for you. Over the

years, the industry has developed a

bunch of tools for managing pipelines.

Some of the most popular ones are

Jenkins, which is the OG, highly

customizable but self-hosted and heavy.

GitLab CI/CD, which is built right into

GitLab, great if you have your repos

there. CircleCI, TravisCCI, and Azure

DevOps if you're on the Microsoft

ecosystem. They all automate, build,

test, and deploy. But most devs today

prefer GitHub actions because it's

deeply integrated with where your code

already lives. I prefer it because it's

built right into GitHub which means no

extra setup or third party login. It's

event driven which means that it

triggers on push PRs or cron jobs. So in

simple words when you push your pipeline

runs. It has a massive library of

pre-built actions which means that you

can just grab community workflows for

testing docker deployments and more. and

it has version controlled YAML configs.

This is where the automation lives right

within your repo. So, it's easy to audit

and reuse. In other words, it's super

simple to use and that's why I

personally use it and recommend you do

too. At its core, a GitHub actions

pipeline is called a workflow. Workflows

live in your repo inside the

folder.github/workflows.

And each workflow is just a YAML file

defining triggers, what events start the

workflow like pushing code or opening a

PR, jobs which are a set of tasks each

running on its own virtual machine, and

the steps which are actual commands or

actions executed in a job. So what is

YAML? Well, YAML stands for YAML aim

markup language. Funny name, right? It

basically means that YAML is not about

complicated tags like HTML or XML.

Instead, YAML is designed to be human

friendly and machine readable. Compare

that to JSON or XML. YAML is cleaner,

which is why Kubernetes, Docker Compose,

and GitHub actions use it for configs.

So, to truly master creating pipelines

with GitHub actions, you need to

understand YAML syntax rules. Unlike

other file formats, YAML is whitespace

sensitive, which means that indentation

is everything. You have things like key

value pairs like language is Python. For

indentation, there's no debate here. It

only accepts spaces, no tabs. You can

also have lists, nested structures where

you can combine mappings and lists,

scalers for strings, numbers, and

booleans, and even things like

multi-line blocks, and anchors and

aliases where you can reuse different

configs. You don't need every detail

right now. Just focus on writing clean

YAML. And similar to any other language,

YAML also has specific keywords and

syntax. So, let me walk you through them

real quick. Some of the core actions

include the keyword name which is used

to define the workflow or the job title

on which defines triggers such as push,

PR or schedule. Jobs to define jobs,

their OS and steps. Steps which are

sequential commands or actions run which

includes shell commands to execute. uses

if you want to use pre-built actions

with where you can pass params to

actions env to set environment variables

and needs to make one job depend on the

other list can go on and on but these

are some special keywords that matter

most in GitHub actions YAML files and

the list could go on and on and that's

why I prepared a complete YAML and

GitHub actions CI/CD cheat sheet it's

packed with so many useful commands And

hey, if you'd like to buy me a coffee

and support me in making more

highquality YouTube videos like this

one, plus get a detailed cheat sheet on

YAML and CI/CD pipelines, you can join

our new channel membership. No pressure

at all. The link should be just

somewhere below this video. All right,

let's keep going.

For now, let's move forward and put what

we've learned into action by creating

our first GitHub actions pipeline using

YAML. I'll start with creating a new

GitHub repo. Let's call it something

like DevOps pipelines. Create a new repo

and then go ahead and clone it locally

by copying this URL and then just clone

it. In this case, I'll be using WebStorm

to clone it automatically. Once you're

in, you'll have an empty repo. So, what

you can do is initialize a project by

running mpm init-y.

And this will give you a new package

json with a new node project. Alongside

it, go ahead and create a new file

called index.js

which will act as the starting point of

our application.

And in there, add a new console log

saying hello DevOps. We can also add

maybe an additional console log saying

something along the lines of I'm

learning CI/CD using GitHub actions.

Perfect.

And what we can do is also create

another file called test.js.

Within it, I'll add a console log when

we start the tests. So I'll say starting

tests. And I'll also add a timeout right

here that'll wait for 3 seconds. So say

console.log

waiting 3 seconds. And of course it'll

take 3,000 milliseconds which is 3

seconds. And then I'll add another

console log saying something like tests

complete. Now we can add both of these

files as scripts within package JSON. So

right here instead of test I'll simply

add a run script which will run node

index.js and I'll also add a test script

which will also run the test.js

file. Now we want to create a special

folder right here in the root of our

application. Create a new folder that's

called.github.

And within GitHub create a new folder

called workflows.

Within workflows, you can see how my IDE

automatically recognizes that I might

want to do a GitHub workflow, which

would create a workflow. file, but in

this case, we can create it manually by

creating a new pipeline.

And we can start creating it. First, it

needs a normal human readable name. So,

I'll say name is CI pipeline, which will

make it easier to identify this pipeline

in GitHub actions tab as you create more

pipelines.

Then it needs an on property which will

define the trigger event. What action in

GitHub should start this pipeline.

In this case, we can say that it'll be a

push action. So whenever somebody pushes

code to the repo and then we only want

to restrict it when changes are pushed

to the main branch. So I'll say branches

is going to be set to an array of main.

So if you push to a feature branch,

nothing happens. Only when you merge

into main, which is our production ready

branch, the pipeline will run. This will

prevent the unnecessary builds for every

branch and ensure that main always stays

tested. After that, we can define the

jobs. A job is a group of steps that run

together. You can think of it like a

container in which multiple actions are

executed in sequence. In this case, we

will name this job build and we have to

define what it will run on. So in this

case, we'll tell it to use runs on the

latest fresh YUbuntu latest machine. Why

Ubuntu? Because it's fast, lightweight,

and widely supported. Then inside a job,

you have to define different steps.

These are the actual instructions to be

executed one after another.

Each step has a name. In this case,

we'll call it checkout code. And then

you can say what it uses.

So in this case, you can say uses

actions/checkout

atv5.

This means that we're using a pre-built

GitHub action such as this one right

here, GitHub actions checkout. And this

is the action we're using that checks

out our repository under the GitHub

workspace so our workflow can access it.

Now we can add some more steps such as

another one with a name of set up

Node.js JS which will also use so uses

another predefined action of actions

forward slash setup- node at v3

with and here you can define the node

version that you want to set it up with

in this case let's do 16 after that we

want to run some dependencies so I will

create another package that'll have a

name of install dependencies and the

only thing that it'll is it'll run mpm

install and after that we'll have

another one which will run the tests. So

it'll be a step of name run tests

and it'll run mpm test. This is

typically done using just or some other

testing framework. But for now we'll

just run our manual test file. Now as

you can see we have some yellow squiggly

lines right here saying that we have

some issues with our setup. And that's

because I used tabs for indentation

instead of using spaces. So after fixing

the indentation, it should look

something like this. You should have two

spaces for each indentation point. We

have jobs, then the build, then we have

runs on, and then steps is directly

below runs on. Two spaces indented after

build. Perfect. Now let's go ahead and

add and commit those changes to GitHub

by running git add dot getit commit-m

feature add ci pipeline and then get

push.

Now if you head back over to your GitHub

repo, you'll be able to see your latest

changes. And now if you head over to the

actions tab, you'll be able to see your

newly created pipeline right here.

expand it and you'll see all the job

details if you enter the build such as

setting up the job, setting up Node.js,

installing dependencies, and then even

running tests. And you can see the

results of those tests right here.

Starting, completed, waiting 3 seconds,

and the job finally is done. Now, this

pipeline will run on every single main

push. I can prove that to you by heading

over to the code and adding a readme

which will automatically push a new

readme.md file to main. So I'll say

testing

the CI pipeline

and commit and push. Since a push has

been made, if you head over to actions,

you'll see that a new action run

automatically based off of my commit

which pushed over to main. It'll rerun

the tests for the entire application and

make sure that everything is good. From

here on, you can add additional test

coverage checks, deploy to staging your

production, or find actions from the

GitHub marketplace where there are so

many different actions that you can

immediately use within your application.

So, in the build and deploy stage, this

allows you to see your CI/CD pipelines,

which enforce code quality, passing

tests, and shipping inside Docker

container. This was just one simple

example. Based off of this, you can

create more workflows or reuse existing

workflows from the community. Later on

in the build and deploy stage of this

project, you'll actually set up real

CI/CD pipelines for our acquisitions

application, ensuring that your

formatting is consistent, your tests

pass successfully, and everything runs

smoothly within a Docker container.

Speaking of which, let's dive into

Docker next.

It works on my machine. Have you ever

heard or said this? Or it works on

Windows but not Mac OS. Or have you ever

struggled with juggling different NodeJS

versions for different projects? This is

why Docker was created in 2013. And it's

not just a tool to solve compatibility

issues. It's a critical skill required

for the highest paying jobs as the

surveys find Docker to be the most

popular tool used by 57% of professional

developers. If you don't learn it now,

you significantly lower your chances of

landing a job. You can think of Docker

as a lunchbox for our application. In

the lunchbox, we pack not just the main

dish, which is our code, but also all

the specific ingredients or dependencies

it needs to taste just right. Now, this

special lunchbox is also magical. It

doesn't matter where we want to eat, at

our desk, a colleagueu's desk, or have a

little picnic. No matter the environment

or different computers, wherever we open

the lunchbox, everything is set up just

like it is in our kitchen. It ensures

consistency, portability, and prevents

us from overlooking any key ingredients,

making sure our code runs smoothly in

any environment without surprises.

Technically, that's what Docker is. It's

a platform that enables the development,

packaging, and execution of applications

in a unified environment. By clearly

specifying our applications requirements

such as NOJJS versions and necessary

packages, Docker generates a

self-contained box that includes its own

operating system and all the components

essential for running our application.

This box acts like a separate computer

virtually providing the operating system

runtimes and everything required for our

application to run smoothly. But why

should we bother using Docker at all?

Big shots like eBay, Spotify, Washington

Post, Yelp, and Uber noticed that using

Docker made their apps better and faster

in terms of both development and

deployment. Uber, for example, said in

their study that Docker helped them

onboard new developers in minutes

instead of weeks. So, what are some of

the most common things that Docker helps

with? First of all, consistency across

environments. Docker ensures that our

app runs the same on my computer, your

computer, and your boss's computer. No

more it works on my machine drama. It

also means everyone uses the same

commands to run the app, no matter what

computer they're using. Since

downloading services like Node.js isn't

the same on Linux, Windows, or Mac OS,

developers usually have to deal with

different operating systems. Docker

takes care of all of that for us. This

keeps everyone on the same page, reduces

confusion, and boosts collaboration,

making our app development and

deployment faster. The second thing is

isolation. Docker maintains a clear

boundary between our app and its

dependencies. So we'll have no more

clashes between applications much like

neatly partitioned lunchbox compartments

for veggies, fruits, and bread. This

improves security, simplifies debugging,

and makes development process smoother.

Next thing is portability. Docker lets

us easily move our applications between

different stages like from development

to testing or testing to production.

It's like packaging your app in a

lunchbox that can be moved around

without any hassle. Docker containers

are also lightweight and share the host

system resources making them more

efficient than any traditional virtual

machines. This efficiency translates to

faster application start times and

reduced resource usage. It also helps

with version control as just like we

track versions of our code using Git,

Docker helps us track versions of our

application. It's like having a rewind

button for our app so we can return to a

previous version if something goes

wrong. Talking about scalability, Docker

makes it easy to handle more users by

creating copies of our application when

needed. It's like having multiple copies

of a restaurant menu. When there are

more customers, each menu serves one

table. And finally, DevOps integration.

Docker bridges the gap between

development and operations, streamlining

the workflow from coding to deployment.

This integration ensures that the

software is developed, tested, and

deployed efficiently with continuous

feedback and collaboration. How does

Docker work? There are two most

important concepts in Docker. images and

containers and the entire workflow

revolves around them. Let's start with

images. A Docker image is a lightweight

standalone executable package that

includes everything needed to run a

piece of software, including the code,

runtimes like Noode.js, libraries,

system tools, and even the operating

system. Think of a Docker image as a

recipe for our application. It not only

lists the ingredients being code and

libraries, but also provides the

instructions such as runtime and system

tools to create a specific meal, meaning

to run our application.

And we would want to run this image

somewhere, right? And that's where

containers come in. A Docker container

is a runnable instance of a Docker

image. It represents the execution

environment for a specific application,

including its code, runtime, system

tools, and libraries included in the

Docker image.

A container takes everything specified

in the image, and follows its

instructions by executing necessary

commands, downloading packages, and

setting things up to run our

application. Once again, imagine having

a recipe for a delicious cake. The

recipe being the Docker image. Now when

we actually bake the ingredients, we can

serve it as a cake, right? The baked

cake is like a docker container. It's

the real thing created from the recipe.

Just like we can have multiple servings

of the same meal from a single recipe or

multiple documents created from a single

database schema. We can run multiple

containers from a single image. That's

what makes Docker the best. We create

one image and get as many instances as

we want from it in form of containers.

Now, if you dive deeper into Docker,

you'll also hear people talk about

volumes. A Docker volume is a persistent

data storage mechanism that allows data

to be shared between a Docker container

and the host machine, which is usually a

computer or a server or even among

multiple containers. It ensures data

durability and persistence even if the

container is stopped or removed. Think

of it as a shared folder or a storage

compartment that exists outside the

container. The next concept is Docker

network. It's a communication channel

that enables different Docker containers

to talk to each other or with the

external world. It creates connectivity,

allowing containers to share information

and services while maintaining

isolation. Think of a Docker network as

a big restaurant kitchen. In a large

kitchen being the host, you have

different cooking stations or

containers, each focused on a specific

meal. Meal being our application. Each

cooking station or a container is like a

chef working independently on a meal.

Now imagine a system of order tickets or

a Docker network connecting all of these

cooking stations together. Chefs can

communicate, ask for ingredients or

share recipes seamlessly.

Even though each station or a container

has its own space and focus, the

communication system or the Docker

network enables them to collaborate

efficiently. They share information

without interfering with each other's

cooking process. I hope it makes sense

but don't worry if it doesn't. We'll

explore it together in the demo. So

moving on, the Docker workflow is

distributed into three parts. Docker

client, Docker host aka Docker Damon,

and Docker registry aka Docker Hub. The

Docker client is the user interface for

interacting with Docker. It's the tool

we use to give Docker commands. We issue

commands to the Docker client via the

command line or a graphical user

interface instructing it to build, run,

or manage images or containers. Think of

the Docker client as the chef giving

instructions to the kitchen staff. The

Docker host or Docker Damon is the

background process responsible for

managing containers on the host system.

It listens for Docker client commands,

creates and manages containers, builds

images, and handles other Docker related

tasks. Imagine the Docker host as the

master chef overseeing the kitchen

carrying out instructions given by the

chef or the Docker client. Finally, the

Docker registry aka Docker Hub is a

centralized repository of Docker images.

It hosts both public and private

registries or packages. Docker is to

Docker Hub what git is to GitHub. In a

nutshell, Docker images are stored in

these registries. And when you run a

container, Docker may pull the required

image from the registry if it's

unavailable locally. To return to our

cooking analogy, think of Docker

registry as a cookbook or recipe

library. It's like a popular cookbook

store where you can find and share

different recipes. In this case, Docker

images.

In essence, the Docker client is the

command center where we issue

instructions. The Docker host then

executes these instructions and manages

containers. And the Docker registry

serves as a centralized storage for

sharing and distributing images.

Using Docker is super simple. All you

have to do is click the link in the

description, download Docker Desktop for

your own operating system, and that will

help you containerize your application

in the easiest way possible.

It'll definitely take some time to

download, but once you're there, you can

accept the recommended settings and sign

up. Once you're in, on the left side,

you can see the links to containers,

which display the containers we've made,

images, which shows the images we've

built, and volumes, which shows the

shared volumes we have created for our

containers, and other beta features like

builds, dev environments, and docker

code. Now, return to the browser and

Google Docker Hub. The first result will

surely be hub.docker.com.

Then open it up. Go to explore and you

can see all of the public images created

so far by developers worldwide. from

official images by verified publishers

to sponsored open-source ones covering

everything from operating system images

like Ubuntu languages like Python and

Golang, databases like Reddis,

Postgress, for MongoDB, MySQL,

runtimes like Noode.js to even Hello

World Docker image and also the old

peeps like WordPress and PHP. Almost

everything that you need is right here.

But how do we create our own Docker

images? Easy peasy. Creating a Docker

image starts from a special file called

Docker file. It's a set of instructions

telling Docker how to build an image for

your application. There are some

specific instructions and keywords we

use to tell Docker what we want through

the Docker file. Think of it as Docker

syntax or language to specify exactly

what we want. Here are some of the

commands from specifies the base image

to use for the new image. It's like

picking a starting kitchen that already

has some basic tools and ingredients.

Work deer sets the working directory for

the following instructions. It's like

deciding where in the kitchen you want

to do all your cooking. Copy copies the

files or directories from the build

context to the image. It's like bringing

in your recipe, ingredients, and any

special tools into your chosen cooking

spot. Run executes commands in the shell

during image build. It's like doing

specific steps of your recipe, such as

mixing ingredients.

Expose informs Docker that the container

will listen on specified network ports

at runtime. It's like saying, "I'm going

to use this specific part of the kitchen

to serve the food."

Env sets environment variables during

the build process. You can think of that

as setting the kitchen environment such

as deciding whether it's a busy

restaurant or a quiet home kitchen. Arg

defines built time variables. It's like

having a note that you can change before

you start cooking, like deciding if you

want to use fresh or frozen ingredients.

Volume creates a mount point for

externally mounted volumes. Essentially

specifying a location inside your

container where you can connect external

storage. It's like leaving a designated

space in your kitchen for someone to

bring in extra supplies if needed. CMD

provides default command to execute when

the container starts. It's like

specifying what dish you want to make

when someone orders from your menu.

Entry point specifies the default

executable to be run when the container

starts. It's like having a default dish

on your menu that people will get unless

they specifically ask for something

else. And you might wonder, isn't entry

point the same as cmd? Well, not really.

In simple terms, both cmd and entry

point are instructions in Docker for

defining the default command to run when

a container starts.

The key difference is that cmd is more

flexible and can be overridden when

running the container while entry point

defines the main command that cannot be

easily overridden. Think of cmd as

providing a default which can be changed

and entry point as setting a fixed

starting point for your container. If

both are used, cmd arguments will be

passed to entry point. And this are the

most used keywords when creating a

docker file. I have also prepared a list

of other options you can use in docker

files. You can think of it as a complete

guide and a cheat sheet you can refer to

when using docker. The link is in the

description. But now, let's actually use

some of these commands in practice.

Let's try to run one of the images

listed in the Docker Hub to see how that

works. Let's choose one of the operating

system images as an example. Let's go

for Ubuntu. On the right side of the

details of the image, you'll see a

command. Copy it and try executing it in

your terminal. But before we paste it,

first create a new empty folder on our

desktop called docker_course

and then drag and drop it to our empty

Visual Studio Code window. Open up your

empty terminal and paste the command

docker pool Ubuntu. It's going to do it

using the default tag latest and it's

going to take some time to pull it. As

you can see, it's working. Docker

initially checks if there are any images

with that name on our machine. If not,

it searches for the Docker hub, finds

the image, and automatically installs it

on our machine. Now, if we go back to

Docker Desktop, we'll immediately see an

Ubuntu image right here under images. To

confirm that we actually installed a

whole different operating system, we can

run a command that executes the image.

Do you know how that process is called?

creating a container. So let's run

docker run dashit

for interactive and then Ubuntu and

press enter. After you run this command,

head over to docker desktop and if you

go to containers, you'll see a new

container based off of the Ubuntu image.

Coming back to our terminal, you'll see

something different. If you've ever

tried Ubuntu before, you'll notice that

this terminal looks exactly like the

Ubuntu command line. Let's test out some

of the commands. ls for list. We have cd

home to move to our home directory. MK

dear, which is going to create a new

directory called hello. We can once

again ls

cd into hello to navigate to it. We can

create a new hello-ubuntu.txt.

txt.

We can ls to check it out if it's there.

And it is. We have just used different

Ubuntu commands right here within our

terminal. Amazing, isn't it? We are

running an entirely different operating

system simply by executing a Docker

image within a Docker container. For

now, let's kill this terminal by

pressing this trash icon and navigate

back to our Docker desktop. Now a bigger

question awaits. How do we create our

own Docker images? We can start from a

super simple Docker app that says hello

world. Let's create a new folder called

hello-ashd

docker. Within it, we can create a

simple hello.js

file. And we can type something like

console.log log hello

docker.

Then comes the interesting part. Next,

we'll create a docker file. Yep, it's

just Docker file like this. No dots, no

extensions. VS Code might prompt you to

install a Docker extension. And if it

does, just go ahead and install it. Now,

let's figure out what goes into the

Docker file. Do you remember the special

Docker syntax we talked about earlier?

Well, let's put it to use. First, we

have to select the base image to run the

app. We want to run a JavaScript file so

we can use the node runtime from the

Docker Hub. We'll use this one with an

Alpine version. It's a lightweight

version of Linux. So, we can type

something like from node 20-p.

Next, we want to set the working

directory to forward slapp. This is the

directory where commands will be run.

And then forward/ app is a standard

convention. So we can type work there

and then type forward slash app.

Next we can write copy dot dot like

this. This will copy everything from our

current directory to the docker image.

The first dot is the current directory

on our machine and the second dot is the

path to the current directory within the

container. Next, we have to specify the

command to run the app. In this case,

cmd node hello.js

will do the trick.

And now that we have created our Docker

file, let's move into the folder where

the Docker file is located by opening up

the terminal and then running cdello-d.

Inside of here, let's type docker build-

t and t stands for the tag, which is

optional. And if no tag is provided, it

defaults to the latest tag. And finally,

the path to the docker file. And in this

case, that's hello-ashdocer

dot because we're right there. And press

enter.

It's building it. And I think it

succeeded. Great. To verify that the

image has been created or not, we can

run a command docker images. And you can

see that we have two images, Ubuntu as

well as hello docker created 16 seconds

ago. Now, if you're a more visual

person, you can also visit Docker

desktop. Here, if you head to images,

you can see all of the images we have

created so far.

Now that we have our image, let's run or

containerize it to see what happens. So,

if we go back, we can run docker run

hello-doer.

There we have it, an excellent console

log.

If we go back to Docker desktop and then

open up that container

and navigate inside of the files,

you'll see a lot of different files and

folders, but there is one special file

here. Want to make a guess? Yes, it's

app which we created in Docker file.

Moving inside it, we can see that it

contains two of the same files we have

in our application. Docker file and

Hello.js exact replica. Also, if we want

to open up our application in shell

mode, similar to what we did with

Ubuntu, we have to run docker run it

hello-d.

This puts us directly within the

operating system and then you can simply

run node hello.js

to see the same output.

We can also publish the images we have

created on docker. But before that,

let's build something a bit more complex

than the simple hello world and then

let's publish it to the Docker Hub.

Which means that now we're diving into

the real deal, dockerizing ReactJS

applications. Let's dockerize our first

React application. I'm going to do that

by quickly spinning up a simple React

project by running the command mpm

create vit latest and then react- docker

as the folder name. If you press enter,

it's going to ask you which flavor of

JavaScript you want. In this case, let's

go with React. Sure, we can use

TypeScript. And we can now cd into

React-doccker.

And we won't run any mpm install or mpm

rundev because the dependencies will be

installed within our dockerized

container. So with that said now if we

clear it we are within react docker and

you can see our new react application

right here. So as the last time you

already know the drill we need to create

a new file called docker file. As you

can see, it automatically gets this

icon. And it's going to be quite similar

to the original Docker file that we had,

but this time I want to go into more

depth about each of these commands so

you know exactly what they do. And

because of that, below this course, you

can find a complete Docker file for our

React Docker application. Copy it and

paste it here. Once you do that, you

should be able to see something that

looks like this. It seems like there's a

lot of stuff, but there really isn't.

It's just a couple of commands, but I

wanted to take my time to deeply explain

all of the commands we're using right

here. So, let's go over all of that

together. First, we need to set the base

image to create the image for React app.

And we are setting it up from Node 20

Alpine. It's just a version 20 of Node.

You can use any other version you want.

And in these courses, I want to teach

you how to think for yourself, not

necessarily just replicate what I'm

doing here. So, if you hover over the

command, you can see exactly what it

does. Set the base image to use for

subsequent instructions. From must be

the first instruction in a Docker file.

And you can see a couple of examples.

You can use a from base image or you can

even add a tag or a digest. In this

case, we're adding a tag of a specific

version, but it's not necessary. And if

you click online documentation, you can

find even more instructions on exactly

how you can use this command. Next, we

have to play with permissions a bit.

Now, I know that these couple of

commands could be a bit confusing, but

we're doing it to protect our new

container from bad actors and users

wanting to do something bad with it. So

because of that we create a new user

with permissions only to run the app.

The s is used to create a system user

and g is used to add that user to a

group. This is done to avoid running the

app as a root user that has access to

everything. That way any vulnerability

in the app can be exploited to gain

access to the host system. This is

definitely not mandatory, but it's

definitely a good practice to run the

app as a non-root user, which is exactly

what we're doing here. We're creating a

system user, adding it to the user

group, and then we set the user to run

the app user app, and you can see more

information about right here. Set the

username to use when running the image.

Next, we set the working directory to

forward slash app. And then we copy the

package JSON and package log JSON to the

working directory. This is done before

copying the rest of the files to take

advantage of Docker's cache. If the

package JSON and package log JSON files

haven't changed, Docker will use the

cache dependencies. So copy files or

folders from source to destination in

the images file system. So first you

specify what you want to copy from the

source and then you provide a path where

you want to paste it to.

Next, sometimes the ownership of the

files in the working system is changed

to root and thus the app can't access

the files and throws an error eax

permission denied. To avoid this, change

the ownership of the files to the root

user. So we're just changing it back

from what we did above. Then we change

the ownership of the app directory to

the app user by running a new command in

this case chown where we specify which

user and group and directory we're

changing the access to and then we

change the user back to the app user and

once again if these commands are not

100% clear no worries. This is just

about playing with user permissions to

not let bad actors play with our

container. Finally, we install

dependencies. copy the rest of the files

to the working directory. Expose the

port 5173 to tell Docker that the

container listens on that specified

network and then we run the app. If you

want to learn about any of these

commands, hover over it. You can already

get a lot of info and then go to online

documentation if you need even more.

With that said, that is our Docker file.

Another great practice that we can do is

just go right here and create another

file similar to.git ignore. This time

it's called docker ignore. And here you

can add node_modules

just to simply exclude it from docker

because we don't really need it in our

node modules on our github. We don't

need it anywhere, not even in docker.

Docker is playing with our package json

and package lock json and then rebuilds

it when it needs to. Now finally once we

have our docker file we are ready to

build it. We can do that by opening up a

new terminal, navigating to React

Docker, and we can build it by running

the command docker build- t for tag,

which we can leave as default. React-

Docker, which is the name of the image,

and then dot to indicate that it's in

the current directory. And finally,

press enter. This is going to build out

the image, but we already know that an

image is not too much on its own. To use

the image, we have to actually run it.

So, let's run it by running the command

docker run react-doccker

and press enter. As you can see, it

built out all of the packages needed to

run our app and it seems to be running

on localhost 5173.

But if we open it up, it looks like the

site isn't showing even though we

specified thatexpose endpoint right here

saying that we're listening on 5173.

So why is it not working? Well, first we

need to understand that expose does only

one job and it's to inform docker that

the container should listen to that

specific exposed port in runtime. That

does make sense. But then why didn't

work? Well, it's because we know on

which port the docker container will

listen to. Docker knows it and so does

the container. But someone is missing

that information. Any guesses? Well,

it's the host is the main computer we're

using to run it. As we know, containers

run in isolated environments and by

default, they don't expose their ports

to the host machine or anyone else. This

means that even if a process inside the

container is listening on a specific

port, the port is not accessible from

outside the container. And to make our

host machine aware of that, we have to

utilize a concept known as port mapping.

It's a concept in Docker that allows us

to map ports between the Docker

container and the host machine. It's

exactly what we want to do. So to do

that, let's kill our entire terminal by

pressing this trash icon. Reopen it. Reg

to React-docker

and let's run the same command docker

run. And then we're going to add a P

flag right here and say map 5173 in our

container to 5173 on our host machine.

And then specify which image do we want

to run and press enter. Now as you can

see it seems to be good. But if I run

it, same things happens again. It's not

Docker's fold, but it's something that

we missed. It's a Vit. If you read the

logs right here, it's gonna say use-host

to expose. So, we have to expose that

port for vit 2. So, let's modify our

package json by going right here and

adding the d-host

to expose our dev environment. And now

again we'll have to stop everything,

kill our terminal, reopen it, ren to

React Docker, and then run the image

again. Which makes you wonder, wouldn't

it be great if Docker does it on its own

whenever we make some file changes? And

the answer is yes, definitely. And

Docker heard us. Later in the course,

I'll teach you how to use the latest

Docker features that allow us to

automatically build images and save us

from all of this hassle. But I first

want to teach you how to do it manually

to understand how cool Docker Compose

is, which I'm going to teach you later

on. So, let's just rerun the same

command.

And now we get an error. This means that

something is already connected to that

port. And this indeed is true. If you

check out our containers or images, we

have accumulated a large number of

images. So let's do a quick practice on

how to clear out all of our images or

containers.

Back in our terminal, we can run a

command docker ps, which is going to

give us a list of all of the current

containers alongside their ids, images,

created status, and more, as well as on

which ports are they listening on. This

is for all the active running

containers. And if you want to get

absolutely all containers, we can run

docker ps- a. And here you can see

absolutely all containers that we have.

That's a lot. Now the question is how do

we stop a specific container? Well, we

can stop it by running docker stop and

then use the name or the ID of a

specific container. You can use the

first three digits of the container ID

or you can use the entire name. So let's

use C3D

C3D. And if you get back the same

command, it means that it successfully

stopped it. If we go back to containers,

you can see that the C3D is no longer

running. But now let's say we have

accumulated a large number of

containers,

which we indeed have both the images and

containers. So, how can we get rid of

all of the inactive containers we have

created so far? Well, we can do that by

running docker container prune. If you

run that, it's going to say this will

remove all stopped containers. So, let's

press y. And that's fine. We only had

one that was stopped that we manually

stopped and it pruned it. But you can

also use the command docker rm to remove

a specific container by name or its ID.

So let's try with this one. A A7 docker

rm aa7 and press enter. Here we get a

response saying that we cannot stop a

running container. Of course you could

always use the d-force and that's going

to kill it. We can verify right here.

These commands are great and it's always

great to know your way around the CLI.

But nowadays we also have Docker Desktop

which allows us to play with it within a

graphical user interface which makes

things so much simpler. You can simply

use the stop action to stop the

container or you can use the delete

action to delete a container. It is that

easy. Similarly, you can do that for

images by selecting it and deleting all

images. And you can follow my process of

deleting everything. Right now, I just

want to ensure that we have a clean

working environment before we build out

our React example one more time. And

while we're here, if you have any

volumes, feel free to delete those as

well. There we go.

So, moving back, we want to first build

out our image. And now, let's repeat how

to do that. You simply have to run

docker build-asht the name of the image

and then dot. This is going to build out

the image. After you do that, we have to

run it with port mapping included. So

that's going to be docker run-b

map the ports and then the name of the

container you want to run and press

enter. It's going to run it. And you can

see a bit of a difference. Right now

here it's exposed to the network. And if

you try to run localhost 5173,

you can see that this time it actually

works.

That's great. But now if we go back to

our code, go to source app and change

this vit and react to something like

docker is awesome and save it.

Back on our local host, you can see that

it didn't make any changes.

That's very unfortunate. We hope that

this container could somehow stay up to

date with what we are developing.

Otherwise, it would be such a pain to

constantly rebuild containers with new

changes. This happens because when we

build the Docker image and run the

container, the code is then copied into

that container. You can see all the

files right here and they're not going

to change. So, even if you go right here

to app and then source and then app tsx,

rightclick it and click edit file,

you'll be able to see that here it still

says vit plus react.

So, what can we do? Well, we'll have to

further adjust our command. So, let's

simply stop our active container so we

can then rerun a new one on the same

port. Let's go back to our Visual Studio

Code. Clear it. Make sure that you're in

the React-docker folder and we need to

run the same command. Then we have to

also add a string sign dollar sign pwd

close it and then say col/app

and close it like so.

It seems a bit complicated, doesn't it?

What this means is that we tell docker

to mount the current working directory

where we run the docker run command into

the app directory inside the container.

This effectively means that our local

code is linked to the container and any

changes we make locally will be

immediately reflected inside the running

container. This tiny pwd represents the

current working directory over here. It

executes in the runtime to provide the

current working directory path. And V, V

stands for volume. That's because we're

creating a volume that's going to keep

track of all of those changes. Remember

that we talked about volumes before.

They try to ensure that we always have

our data stored somewhere. But before

you go ahead and press enter, there is

one more additional flag that we have to

add to this command. And that is yet

another dashv but this time forward

slapp slode

modules. Why are we doing this? Well, we

have to create a new volume for the node

modules directory within the container.

We do this to ensure that the volume

mount is available in its container. So

now when we run the container, it will

use the existing node modules from the

named volume and any changes to the

dependencies won't require a reinstall

when starting the container. This is

particularly useful in development

scenarios where you frequently start and

stop containers during code changes. So

let's run it. It's running on localhost

5173.

Docker is indeed awesome. But now the

question is if we change it, what's

going to happen? So we go here and say

something like Docker is awesome, but

also add a couple of whales at the end.

Press save. And then you can see PM V

update source app tsx. And now if we run

it, we have a couple of whales right

here. There we go. So whenever you

change something, you'll see the result

instantly in the UI. That's amazing.

And even if we go back to our Docker

desktop, you can see that now we have a

volume that keeps track of these

changes. And if you go under containers,

go to our active container, go to files,

and then let's go to app source app tsx

and edit. You can see that the changes

are also reflected right here. So that's

it. You have successfully learned how to

dockerize a front-end application. Not

many developers can do that. But you,

you are just getting started.

Now that we have created our Docker

image, let me teach you how to publish

it. We can do that using the command

line. So let's go right here, kill our

current terminal, reopen it, and cd into

React Docker.

Next, we can run docker login. And if

you already logged in with docker

desktop, it should automatically

authenticate you. Next, we can publish

our image using this command. Docker tag

react-doccker.

Then you need to add your username and

the name of the image.

You can find your username by going to

docker desktop, clicking on the icon on

top right, and then copying it from

there. In my case, it's JavaScript

mastery. And then I'm going to do

forward slreact-docker.

It's okay if we don't provide any tag

right here as the default tag is going

to be colon latest. Also, don't forget

that below this course, I provided a

complete list of all of the commands

including different tag commands to help

you get started with Docker anytime,

anywhere.

So, check them out and try running some

of them. Finally, let's publish our

image. And now we have to run docker

push javascript mastery or in this case

your username/react-doccker.

And this is going to actually push it to

our docker hub. There we go. Now if you

go back to docker desktop, you can see

that we have a JavaScript master react

docker image that is now actually pushed

on the hub. And you can also check it

out right here by going to localhub

images. And then you can see JavaScript

mastery has one latest image. And

another cool thing you can do is go to

hub.docker.com

where you can find your image published

under repositories and then check out

your account right here and you'll be

able to see your React Docker image

right here live on DockerHub. And now

other people can run this image as well

and containerize their applications by

using it. How cool is that? And that's

all it is to it. You have successfully

published your first Docker image. But

now that you know the basis, let's find

a more efficient way of dockerizing our

applications. Oh yeah, developers are

lazy. So writing and running all of

these commands for building images and

containers and then mapping them to host

is just too much to do. But it's not the

only way. We can improve or automate

this process with Docker Compose and run

everything our application needs to run

through Docker using one small single

command. Yes, we can use a single

straightforward command to run the

entire application.

So, say hi to Docker Compose. It's a

tool that allows us to define and manage

multicontainer Docker applications. It

uses a YAML file to configure the

services, networks, and volumes for your

application, enabling us to run and

scale the entire application with a

single command. We don't have to run 10

commands separately to run 10 containers

for one application. Thanks to Docker

Compose, we can list all the information

needed to run these 10 containers or

more in a single file and then run only

one command that automatically triggers

running the rest of the containers. In

simple words, Docker Compose is like a

chef's recipe for preparing multiple

meals in a single dinner. It allows us

to define and manage the entire cooking

process for recipes in one go,

specifying ingredients, cooking

instructions, and how different parts of

the meal should interact. With Docker

Compose, we can serve up our entire

culinary experience with just one

command.

And while we can manually create these

files on our own and set things up,

Docker also provides us with a CLI that

generates these files for us. It's

called Docker Init. Using Docker Init,

we initialize our application with all

the files needed to dockerize it by

specifying our tech choices.

So let's go ahead and create another VIT

project which we can use to test out the

features of docker compose and docker

init. We can open up a terminal and then

run mpm create vit add latest. In this

case we can call it vit- project and

press enter.

It's going to ask us a couple of

questions. It can be a react typescript

application. We can cd into it. And

please make sure that you are in the

Docker course, meaning in the root of

our folder. So it needs to create it

right next to React. If you were in

React before when you run this command,

it's going to create it inside of it. If

that's the case, delete it and just

navigate to Docker course and then run

the command. Now we can cd into V

project and we can learn how to use

Docker in it. It's so simple. You simply

run Docker in it. That's all there is to

it. And it's going to ask you many

questions based off which it's going to

generate a perfect YAML file for you. So

what application platform are we

planning on using? In this case, it's

going to be node. So you can simply

press enter. What version? You can just

press enter one more time to verify what

they're saying in parenthesis. 20 is

fine with us. MPM is good. Do we want to

use mpm run build? No, actually uh in

this case we're going to say no and

we're going to say mpm rundev. That's

what we want to use. And the server is

going to be 5173.

And that's it.

We can see that this has generated three

new files for us. The docker file which

we already know a lot about. This one

has some specific details in it. But you

can see that again it's based off of the

same thing.

It starts from a specific version, sets

up the environment variables, sets up

the working directory and run some

commands. We also have a docker ignore

where we can ignore some additional

files. And then there's this new file

compose.yaml.

While all of these files are important

with using docker compose, yaml is the

most important one. And you can read all

of these comments, but for now I just

want to delete them to show you what it

is comprised of.

We simply define which services we want

our apps or containers to use. We have a

server app where we build the context,

specify environment variables, and

specify the ports. Of course, these can

get much more complicated in case you

have multiple services you want to run,

which is exactly what I want to teach

you right now. Here, they were even kind

enough to provide an example of how you

would do that with running a complete

Postgress database. So you can specify

the database, database image, and

additional commands you can run. But

more on that later. We're going to

approach it from scratch. For now, we

can leave this empty compos yaml. And

first, let's focus on just the regular

Docker file. In this case, we can

replace this Docker file with the one we

have in our React Docker application.

So, copy this one right here and paste

it into this new one. This one we

already know what it is doing.

Now moving inside of the YAML file here,

we can rename the server into web as

that's a common practice for running web

applications and not servers.

We can also remove environment variables

as we're not using any

and we can leave the port. Finally, we

need to add the volumes for our web

service. So we can save volumes.

Make sure to provide a space here and

then a dash. And that's going to be

colon slapp

and another dash/app/node

modules.

Does this ring a bell? It's similar what

we have done before manually by using

the docker build command, but now we're

doing it all with this compose yaml

file. And now all we have to do is run a

new command. docker compose up and press

enter. And as you can see, we get a

permission denied. You never want to see

this. If you're in Windows, maybe you're

used to seeing this every day. In which

case, you simply have to close Visual

Studio Code, rightclick it, and then

press run as administrator. That should

give you all the necessary permissions.

On Mac OS or Linux, you can simply add

sudo before the command.

Then it's going to ask you for your

password and it's going to rerun it with

admin privileges. So let's press enter.

And the process started. It's building

it out. Now let's debug this further. We

get the same response we've gotten

before. Hm. What could this be? Port is

already allocated. Oh yeah, we forgot to

delete or close our container that we

used for previous React application. So

now we know the easy way to do it. We

simply go here, we select it and we can

stop it or delete it. Once it is

stopped, we can go back and then simply

rerun the command. I want to lead you

through all of the commands together,

even if the failed ones, just so you can

get the feel of how you would debug or

reapproach specific aspects once you

encounter errors. That's what being a

real developer is. getting stuck,

resolving the obstacle, and getting

things done. And finally, let's run the

command. It's running it. And if we go

to localhost 5173, ah, the same thing as

before. Any guesses? The answer is that

we once again forgot to add the d-host

to our vit dev script right here. So if

we add it stop our application from

running by pressing Ctrl C, this is

going to gracefully stop it. The cool

thing about Docker Compose is that it's

also stopping the container that it spun

up. And now that we have canceled our

action, we can try to rerun it with

pseudo Docker Compose up, but this time

with host included. And press enter.

It's going to rebuild it. And if we open

it up now, it works. By now, you should