Complete Docker and Containers Course: From Basics to Deployment

hey team welcome to this complete course on Docker and containers my goal with this course is for it to be the most

efficient way for you to ramp up on your Docker and container skills starting from the basics and progressing through

to intermediate and advanced concepts by the end of the course you'll have the Knowledge and Skills to be productive

within a team using containers for both development and deployment of their applications you'll understand why you

would want to use containers as well as how to integrate them seamlessly into your own workflow this course is split

between the and practice for each section I'll cover the concepts that you need to know using helpful visuals and

diagrams before diving into our code editor and solidifying that knowledge with real world

examples I've provided a companion GitHub repo Linked In the description containing all of the code and

configuration that will be shown throughout the course feel free to clone or Fork the repo to follow along as we

go before diving in I do want to highlight a couple of prerequisites that will help you get the most out of this

course as the image shows it can be tempting to jump straight into learning about

containers and skipping some of the foundational Concepts that they build upon I'll do my best to explain

everything in such a way that even an absolute beginner would understand but if you have some familiarity with web

application development and how all the different components fit together that will be helpful and make it easier to

understand what aspects are container specific and what aspects are just General application architecture

concerns also having some understanding of basics L shell commands will be useful as we'll use such commands

throughout the course if you don't have these I think you can still get value from the course

but some things that I do or say might not make sense so it could be worthwhile to go and brush up on those topics

first I've broken down the course into the following learning modules each building progressively upon the last I

provided timestamps in the description to make it easy to jump between sections if you're already familiar with the

topic or if you plan to revisit this video and watch it across multiple sessions in the first portion of the

course sections 1 through 4 we'll explore why containers exist in the first place the problems that they solve

and the underlying Linux kernel features that make Docker and containers possible we'll also install and configure the

docker desktop application and get our first hands-on experience running some containers for the remainder of the

course we'll be focused on building out and containerizing our own web application from development all the way

through to deploying it to the cloud this is where the rubber meets the road and you'll learn exactly how software

companies use Docker throughout the application development life cycle so what is this demo application we're

working with I'll go into it in much more detail during section five and throughout the rest of the course but in

summary it's a minimal three- tier web application meaning it has a front end in this case built out using react an

API layer we actually have two implementation of this one in nodejs and one in goang to highlight how different

languages are handled with containers and finally a postgres database each service is designed to be as simple as

possible while still showcasing how they all fit together within a real world application when we get to the

deployment section of the course we'll learn how to deploy our containerized application to the cloud within the

course I'll be using Docker swarm which is a container orchestrator built into Docker and I've also filmed two bonus

videos to highlight additional methods of deploying containers one using Railway and another using kubernetes

these are separate from the course and information about where you can find them can be found in the description

this should give you a taste of the variety of options that we have for deploying containerized

applications before we jump into the course content I want to pause for a moment to thank the sponsor of this

video Shipyard because of their generous support I can provide this course to you completely free of charge I'm excited

about them as a sponsor because Shipyard is highly relevant to everyone working in the container World their platform

offers the easiest way to generate on demand ephemeral environments and other words automatically generating fully

functional isolated environments for every pull request you connect your G Hub repo add a couple of lines of code

to your configuration files and you can have test environments running in just a few minutes later in the course I'll

demonstrate how to use the shipyard platform with the course sample application as a bonus for all the

students of this course the team at Shipyard has created an exclusive coupon code for you the first 300 people to

create a shipyard account and use the promo code devops directive will get 30 extra free days on either the startup or

business tier plans links and instructions are in the description below you should go check out the

shipyard platform and consider how it can help your teams deliver better software faster without further Ado

let's get into the course now in this first section of the course I really want to uh ground our

understanding of why containers exist and why a product like Docker has been so successful uh we're going to start

with kind of the motivation and then we'll walk through the history of different virtualization Technologies

from bare metal to Virtual machines to containers uh and try to understand how that Evolution has occurred and why

containers have become the dominant uh kind of development and deployment mechanism for software applications

today and this meme on the right is one that I've seen shared a number of times uh it's this idea that I'm building a

software application I get it running locally but then something goes wrong in the process of Translating that local

system to the production one and so one thing that Docker does really well is help to make it such that our local

environment is as close as possible to the production environment that we're going to deploy to and so that's what

this is this is hinting at is we're taking that local environment and just shipping it directly to

production now there's two main aspects uh of the software development life cycle that Docker and containers are

trying to address uh the first one is on the development side so up front as we're building this application maybe

historically there was this long process proc you you join a company and they tell you here's your new laptop uh go

ahead and and install all these things run these scripts and get everything configured and now you can run the

application locally and do your development uh it was very complex lots of opportunity for human error uh and so

then Docker came along and Now setting up your development environment is as easy as running a single command Docker

compose up we're going to go more into what that is doing later in the course but it took this whole complex sequence

of of events that you needed to uh run and turned that into a singular system and command that

everyone can run and be up and running uh in the first hour of their their day and so making all of the different

combinations of Windows and Mac and Linux development environments all compatible uh is one thing that Docker

does really well and containers in general do really well so that's kind of the the de vment side of things on the

deployment side of things uh similarly let's say you would build your application and then you need to to put

it onto some server somewhere to run it and there was this uh idea that there's a number of steps that need to happen

let's say okay we need to create a server running auntu then we're going to run some configuration software like

anible to get all the dependencies configured and then finally we're going to copy our application code onto the

server and run it with these configuration options again lots of steps lots of complexity uh and much

harder to ensure that it's going to be right every single time what containers do is they bring a

single standardized package such that as long as my server has a container runtime and there's a number of those

available Docker provides one but there's a number out there all you need to do is take this standard container

image and run it with these specific options and that's it so now instead of worrying about the underl operating

system and the underlying dependencies as long as we have our system and a container runtime and our container

image we can run it and get repeatably reliable results uh over and over and so these two aspects are really why

containers exist and you can see how much simpler it gets when we use containers going from this historical

system with lots of steps and and potential for error into a much more simplified uh unified approach using a

system like container and like docker and so that hints at what a container is I've talked about kind of the

standardized package uh but from the docker website a Docker container image is a lightweight Standalone executable

package of software that includes everything needed to run an application so you can think of it as this box that

contains the underlying sort of os dependencies let's say runtime dependency so if I was writing an app in

Python it would have the python runtime with the version that is needed uh it would have any of the Python libraries

that I'm using so maybe I'm using SQL Alchemy to talk to a database or fast API to build out an API and then it's

also going to have my application code so the specific application code that I'm writing all of that gets bundled

into this container image and then the beauty is that we have this standard interface and can run multiple copies of

it so let's say I need two copies of this application I can take that image with a container runtime and run a

container run two copies run three copies Etc and so I've used the term container and container image it's

important to know the difference there a container image is this artifact that has all of the all of these dependencies

within it a container is what you run from that image so you take an image and if you think of object oriented

programming a container image is like the class and then the container itself that you're actually running is like an

instance of that class an instantiation of that class and so a container allows us to

have this standardized Packaging that we can then create one or more copies of uh and those copies are going to be the

same every single time so far I've been using the term Docker container uh but I want at this point to call out what is

known as the oci or the open container initiative and effectively there were a few early players including Docker

building out the early implementations of containers and as they became more popular companies realized that rather

than having a whole bunch of slightly different but similar things that we're calling containers it would make much

more sense to come together and create one standard that can be used across different

implementations that's exactly what the cont the open container initiative is a number of companies including Docker

Google VMware Microsoft Dell IBM Oracle the list goes on came together uh and created open industry standards around

what a container is and how it should be run and so there's three primary specifications that the oci defines the

runtime specification the image specification and the distribution specification so the image specification

defines what should be included in the image in terms of metadata and the format that it should contain so a

serializable file system the runtime specification defines how you would take an image that adheres to that image

specification and run it in a container and then the distribution specification talks about how those images should be

distributed so think about Registries and pushing and pulling images and so these three things together make up the

open container initiative and Docker has a specific implementation of this standard so when I talk about Docker

images or Docker container images what I'm referring to specifically is the docker implementation of this oci

specification if Docker is the only container tool that you're using it's not all that important to know this I

wanted to provide this context in case you start using other tools and know that there is this standard format that

can be shared across different Tooling in the ecosystem now now let's walk back in time a little while and understand

how we got to this idea of containers hopefully from my description of the motivation uh you understand why

containers are useful but it's I think it's also important to understand the history and the context of how we got to

where we are today and so before there were containers before there were even virtual machines uh we just had

computers uh we now call this bare metal Computing so if you're running your applications directly on the Hardware

system itself uh another term for that is bare metal but back long enough ago this was just called Computing right so

in this case you have your your physical host your server um the physical Hardware layer at the bottom you've

installed whatever operating system you want on top of it then you've installed whatever binaries and libraries are

necessary to run your application and then you would have your application one or more applications installed directly

uh onto this host machine now what are some challenges with this setup uh first of all you can

see that shared layer of binaries and libraries uh it's shared across both of those applications and so if your

applications for example need different versions of the same dependency or have some dependencies that are somehow

incompatible with each other now we've got we've gotten ourselves into what is known as dependency hell so uh we

somehow need to either modify our application such that those dependencies are not compatible or figure out a way

to to carve up the system such that we can have both versions of the the libraries available doing things like

setting uh your your path environment variables differently for the different processes Etc so that can be quite a

challenge um you also because of this dependency management challenge you're more likely to have le fewer

applications on each host machine uh and so it makes it harder and harder to achieve High utilization so let's say

application one takes one CPU core application 2 also takes one CPU core but we have this server-based uh system

that has 64 cores um it could be very hard to sort of utilize that compute capacity effectively because of the

challenges uh associated with managing dependencies for for applications you also now if you are

installing multiple applications onto the system if you ever have an issue with one of those applications or do

something that will mess up uh some underlying dependency now you have this large blast radius meaning uh changes or

or issues with one application can directly impact uh the performance of another application running on that same

host machine so uh it just makes it much more dangerous to to modify things also the startup and shutdown

speed of a physical system is on the order of minutes so uh to spin down that server and reboot it for for some reason

uh that can take a number of minutes and so so it's just relatively slow if you want to try to achieve high uptime and

and eliminate downtime for your applications in addition to that creating new physical machines uh sort

of provisioning a new system is very very slow so depending on my setup if I have my own Data Center and I need to

actually order the hardware and get it installed and hookup networking that could be on the order of days or weeks

if I'm working with a co- location facility or a provider that offers bare metal systems that provisioning might be

on the order of hours um but still quite slow relative to what we'll see as we evolve and and sort of add in this

concept of virtualization and so that's bare metal I think most people are familiar with

working with bare metal um even if they don't realize it because when you run things on your laptop or your desktop

you're installing them directly on the host and so that is this concept of of bare metal however that's not the only

way to do things and so these challenges really prompted Engineers to come up with this concept of virtualization and

adding virtual machines such that we can eliminate some of those challenges and so in the case of a virtual machine now

this outer boundary is still the host the physical system the server uh we've got our Hardware um we may or may not

have an operating system running on that Hardware I'll talk about that more in a second but then we have what's known as

a hypervisor and so a hypervisor is some combination of software and Hardware that allows us to carve up the physical

resources so think CPU cores memory access to storage or gpus other devices it allows us to carve up that pool of

resources into isolated smaller pools that we can then install our our systems onto and so this hypervisor kind of

gives us this virtual Hardware layer upon which we can then install an operating system install binaries and

libraries and install our applications and so now rather than having both applications on the single physical host

we now have application one and application 2 each with their own virtual isolated virtual machine uh

running on top of that hypervisor and so there's two types of hypervisor type one means there's no underlying OS these are

running directly on the physical Hardware um this is beneficial because you don't sacrifice any performance in

that sort of os to software virtualization layer uh there there's a small performance hit but much less than

if you have an operating system on the hardware and then a hypervisor on top of that uh so things like AWS Nitro so

that's the hypervisor that Amazon web services is using to create virtual machines on their servers uh VMware is a

very popular virtualization uh company and they have vsphere which is a type 1 hypervisor if you want to just create a

virtual machine let's say on your laptop you're probably going to use a type two uh hypervisor uh one such example is

virtual box so you can install this program virtual box and then within that you can create virtual machines for

various uh operating systems Etc and so how does this compare to those challenges that we saw with the

bare metal systems uh one we've eliminated this dependency hell so now each virtual machine has an isolated set

of dependencies binaries and libraries such that our application can specify whatever dependencies it needs and not

have to worry about the needs of other applications uh because of this we're going to have better utilization so we

can carve up a big server CPU into many different smaller uh chunks and each of those chunks can have its own virtual

machine and then we can install our applications accordingly so this is what enables a cloud provider you can go on

and see oh I can I can choose between all these different machine types they don't actually have all those different

machine types installed in their data center they have much larger machine types and you're getting some sliver of

that installed as a virtual machine you also we've also reduced the blast radius significantly such that now

if if something goes wrong with application one on virtual machine 1 that should be isolated from application

2 and Virtual Machine 2 uh and it should not cause any issues and so because of that we've we've increased the safety of

of making changes we've also sped up the speed at which we can start and stop these things so now it's still on the

order of minutes probably um but faster than shutting down and starting a physical server and then finally uh uh

one area where virtual machines have a big uh bonus over bare metal is that we can provision and decommission them much

much faster and so we're all used to living In This Cloud world where we can go onto our favorite cloud provider

click the button or issue a command and have a new virtual server ready uh within minutes or if we're done with it

we can decommission it in a can also be done and and we can stop paying for it within minutes as

well and so that's the sort of the second tier or the second rung along this path of virtualization the next one

being containers and so containers obviously are the focus of this course um they change things a bit further

still so now in this outer box we've got our host or our which could be a physical system uh it also could be a

virtual machine so we can take either of those two uh Concepts from before and we can run containers within that

context uh you can see at the bottom we've got either our virtual or physical Hardware with an operating system and

then the key piece here that's kind of analogous to that hypervisor uh is the container runtime so this is a piece of

software that knows how to take a container image and run it within the host system uh the key difference

between virtual machines and uh containers is that virtual machines are running their own copy of the Linux

kernel uh and I'm talking only about Linux containers within this course there are windows containers but that is

a different topic for a different day and so with Linux containers uh they are actually running they're sharing the

kernel with the host operating system uh versus in a virtual machine you have your own oper you have your own kernel

and you have a copy of your own operating system that's running and So within a container you're sharing that

with the host however we're using certain features that'll go into later of the Linux kernel to help provide uh

isolation between the different container processes and so you don't get quite the same level of isolation that

you would with a virtual machine you do get quite good isolation if you configure things

properly as we can see now we have our two containers both running uh on the same host however they are still

isolated and have their own copies of binaries and libraries even though they're sharing that underlying kernel

now there's a couple of different sort of types of software related to containers the first category of which

I'll call the desktop container platforms so these are sort of container Management Systems things like Docker

fall into this category things like podman these are things that you would install on your development system to

manage containers manage container images uh run containers uh set up the the necessary networking Etc um so these

are kind of the holistic lifecycle systems and then there's much more targeted or specific pieces of software

called container run times which include things like container D or cryo and these are very specifically designed to

take a container image that aderes to the spec and run it uh with the necessary configuration options to

provide that type of isolated environment that that is shown in the image now how does this compare to

Virtual machines and bare metal in terms of those challenges we saw before again we don't have the issue of dependency

conflicts because they each have their own underlying binaries and libraries uh We've improved our utilization

efficiency even further because we now for each virtual machine we had to have an entire copy of that operating system

so each of those virtual machine images is going to be on the order of gigabytes whereas container images can be much

much smaller because they're able to leverage that underlying OS and so they're generally going to be on the

order of megabytes uh I have seen very large multi-gigabyte container images but that's not ideal

uh but because of this we're able to utilize the resources of the system much more effectively again we have a small

blast radius where we have some level of isolation even if it's not quite as strong of an isolation as a virtual

machine we're able to start and stop containers even more quickly than virtual machines so on the order of

seconds uh we're able to in this case starting and stopping a container uh is kind of equivalent to provisioning and

decommissioning so also on the order of seconds we can bring up a new container from scratch and clear it out as well

and then the final sort of key piece I think with containers is that they're small and light enough that we now start

to use them within our development environment sure you could use something like virtual box you could create a

virtual machine that tries to replicate your uh your production environment but it's kind of slow and clunky and not

that many people do some people do but but many people don't containers are light enough uh that now more and more

will start to actually run containers and we're going to do this later in the course run containers within our

development environment such that we can have high confidence that our our production environment is as similar as

possible to that development environment and that just decreases the likelihood that we're going to hit some small

nuanced bug uh between the differences there uh and so we're able to develop more efficiently uh using a technology

like this and so I I pointed out here that this host can be a virtual or a physical machine and so now we can get a

little bit uh Inception with it where we have a host machine with virtual machines running on it and then

containers running within uh those virtual machines and so this is a very common configuration that you'll see uh

most people who are working with containers in the cloud are going to have something like this where you have

multiple virtual machines each running multiple containers uh and so this is just combining all these Concepts

together and the real challenge now becomes how do I how do I manage all of these containers

across those virtual machine hosts and that's where this concept of orchestrators comes in and so things

like kubernetes Nomad from hashicorp or Docker swarm are these systems that are designed specifically to take containers

and run and manage and schedule them across multiple nodes and so in this case the node is each of those virtual

machines and so when we get to the deployment section of this course we'll talk a little bit more about this but

it's just important to know kind of the concepts of hey I'm starting with this bare metal server it my my code has to

run somewhere on some physical CPU I'm carving it up into these smaller virtual machines that I'm able to manage a

little bit more effectively but then I also want to gain the benefits and the speed uh and the efficiency that a

container provides and so combining these different types of virtualization in this way that we see more and more

companies using in this day and age this just summarizes most of those challenges and tradeoffs uh that I

talked about before uh in terms of dependency management uh virtual machines and containers really shine uh

in terms of utilization containers definitely win out uh just because it's much easier to get uh to to pack

applications more efficiently uh when running them in containers uh from an isolation perspective uh you can't get

any more isolated than than multiple physical hosts if you're running application a on on one server and

application B on one other physical server that's the strongest isolation you can get virtual machines still

provide very strong isolation and those hypervisors are these very optimized systems with a small attack surface area

that have really been battle tested and so I I think isolation provided by virtual machines is almost as good as as

those from bare metal obviously there could still be some unknown bug that that causes uh a security issue there

but I think most people have quite high confidence in the isolation that hypervisors provides and then containers

um this is one area where they are less good than these other options is they do provide some level of isolation we'll

talk about the the ways in which they do that but they don't give the same they're not as strong and if you make a

configuration mistake the the level of isolation can be dropped significantly so that's why I gave containers a yellow

on isolation um startup speed containers win out the ability to run containers within a development

environment because they're lightweight enough means that we're much more likely to do so and therefore have stronger

parity or have have our development environments and our production environments more similar to one another

this control row is one that I haven't talked about as much this is just the fact that you can have full

configuration control over the system um in a bare metal context that you might not get in a virtual machine so only you

only have control over the features or the specific configuration options that the hypervisor passes through or the the

container runtime passes through and so maybe there's some specific type of GPU or Hardware accelerator that is not yet

supported by your particular container runtime or your hypervisor in those cases the bare metal system is going to

win out because if you need that specific Hardware config that might be the only way in which you can achieve it

and that leads into kind of this this next row of performance obviously ly a summary of red yellow green um here

can't fully capture the nuances you don't take that much of a performance hit when you move to a virtual machine

or container however I think one place that performance can win out on bare metal is because of that control you're

able to do things like if you're if you're running multiple servers for example ensure that they are directly

next to each other on the same server rack such the networking latency is as small as possible or ensuring that the

storage devices that you're using are directly connected to that physical Machine versus accessing

them over the network and so there is Performance Tuning that bare metal provides the opportunity to do um but

overall the performance is fairly comparable for most use cases across these different

Technologies and then the final column there just sort of how challenging it is to work with and so so if I'm if I'm

buying and racking my own servers in a facility that's intensely difficult to do and and manage there are now

providers that can give me access to Bare Metal systems and handle some of this operational overhead but I think

it's still more challenging than virtual machines and more challenging still than containers where I can spin something up

and and down very easily and there's all of these services that have container run times such that as long as I provide

a compatible container image I'm able to run it within that system and we'll see that optionality uh in in a later

portion of the course when we get into deploying our own containerized applications and so now that we have a

better understanding of the motivation and history of containers and virtualization Technologies I think it's

useful to do a bit of a technology Deep dive and start to understand the the foundational Linux kernel features that

software like Docker is using to make the magic of containers happen and provide those isolated environments that

we described uh then towards the end of this section we'll actually take a look at the docker system architecture itself

there's three technologies that make up the core of uh a container and that is namespaces control groups

and Union file system and now namespaces are a a mechanism to wrap a global system resource such that from within

that namespace any processes running within the namespace it appears as though they have their own isolated

instance of that resource uh and they cannot see things happening outside of their own instance uh so for example on

the right here we have a listing of the various types of name spaces at one very good example example is the PID

namespace so the process ID namespace within a container it is isolated with with a p namespace such that the process

I'm running appears to be process ID number one even though there may be tons of other processes running on the host

from inside the container we don't know anything about those host processes and we essentially think that we are the

only thing running uh in this system another good one to call out is the username space uh so by using a username

space containers are able to map a one user within the container to a different user on the host system so we

could be running as a root user with elevated privileges inside the container but by run as long as that container is

run within a user name space that's configured correctly that root user inside the container may actually map to

a non-root user outside the container uh and that's very important from a security perspective in case there was

an issue with with one of our containers and an attacker was able to gain access to it and break out of that container if

we had properly set up username spaces then on the host they would not have the same level of privileges that they had

inside the container cgroups are a Linux kernel feature that allow you to organize your

processes into groups which you can then limit and monitor access to certain resources and so on the bottom left you

can see within the file system under proc cgroups we can see all the different cgroups that are available

these correspond to different system resources whether they're CPU memory storage devices Etc and using cgroups we

can specify a configuration for a particular process or group of processes on how they should be able to

access those system resources and so for example we might have one application that is enabled to use up to 30% of the

CPU Cycles we would use the cpu. shares cgroup maybe it can use up to 50 megabytes of memory we would specify

that with the memory. liit in bytes cgroup and then we could also limit the amount of disk read that it has access

to uh using the block IO throttle read bits per second device C group uh now the reason that this is important is

that it allows us to avoid what's called a Noisy Neighbor problem where one application uh is very resource hungry

and sort of starves the other applications of resources by using cgroups we can isolate from a

performance perspective each of our different processes and each of our different

applications now the third key underlying technology is what's called a union Mount file system a specific

example of which that Docker uses is called overlay FS it essentially allows you to take separate file systems and

combine them into a unified view that you can then operate on and so in the image you can see we have a lower file

system and an upper file system with various files we got file one 2 a and four in the lower layer in the upper

layer we have a different file 2B a new file three and then we've actually deleted file 4 when we combine these

layers into the overlay we end up with a a combination of those two things where the upper layer takes precedence over

the lower and so we have file one file 2B and file three and so while Nam spaces and cgroups are sort of what make

containers possible it's this concept of a union Mount file system that makes containers practical because of this

layered approach we're able to share lower layers and cache those layers such that the amount of data that needs to be

transferred and stored for container images is much much smaller because many images can share a common lower layer

and then only some subset of the upper layers can be modified which enables us to move less data when we need to get a

container image onto a system and allocate less space if we're running multiple copies of the same container

and so with those Technologies while you can interact with them directly it's software like Docker that takes it and

packages it into a really nice user experience so rather than needing to know all the different commands to

create control groups and move processes into them or create Nam spaces and and block off the different portions of our

system in such a way Docker has bundled that uh into an easy to use desktop application that we can install in our

system and get all of that uh with a series of simple commands that we're going to learn throughout this course

and so this is a diagram of the docker desktop application uh there's there's a number of pieces here here so let's call

them out in turn on the left hand side is the client application and so this is the thing that we will be interacting

with there's a a number of elements there's the command line interface so when I go to my command line and type

Docker run or Docker pull I'm interfacing with that Docker CLI there's also a a graphical user interface which

gets installed uh this is nice for browsing which images you might have on your system uh you can do things like

configure how much CPU and and memory and disc space the docker application has access to so there's a number of

nice user experience features that the that the guy provides there's also a credential Helper and so this is when we

learn more about Registries later on in the course essentially a registry is a place where we can store we can push

images to and pull images from and so in order to have a private registry you need some way to log in and so the

docker credential helper is a mechanism to help store the necessary credentials to do the authentication for that

and then finally uh extensions are a relatively new feature of Docker that are thirdparty pieces of software that

plug into the client and provide additional functionality in some way and so that's the client application when

you install Docker desktop on your system it also creates a Linux virtual machine uh so if I'm on Mac OS there's

no such thing as a Mac OS uh container uh instead Docker uses a hypervisor installs a Linux virtual machine and

then within that virtual machine it setss up uh two things it sets up the server host application and so that's

known as the docker demon or Docker D that exposes an application programming interface the docker API and so when I

execute a command from the the command line uh let's say I do Docker run that command gets passed to the docker demon

which is listening via that Docker API and then it executes whatever command that is specifying uh within that server

host application so let's say I did Docker run and then specified I wanted to run my container image one I might

create it would then go off and create that container 1A let's say I then issued that same command Docker run with

my container image number one again I get another container container 1B and so this Docker demon is managing those

container objects as well as things like uh networking and and volumes all within this server host

application finally there's an optional kubernetes cluster that gets configured and installed uh within that virtual

machine this can be a nice to have if you are developing four kubernetes you can leverage that cluster directly

without having to uh install and configure a separate cluster I mentioned for Mac OS it's a Linux virtual machine

on Windows there's actually two options you can either configure it to use uh WSL Windows system subsystem for Linux

as the back end or you can use hyperv as that virtualization layer uh to create a virtual machine I think either of those

are viable when we go through the installation and setup in the next portion uh we can talk through that in a

a little more detail and then the final portion to call out on the right I hinted at this but a registry is just a

place to store your container images and share those container images uh with your team or with the world or with

wherever you're deploying uh your containers to and so while it is not a part of Docker desktop it's useful to

call out here uh because that Docker demon when it needs to get an image that it's not building locally it's going to

go off to some registry dockerhub is a great example of one such registry and pull that image into the the host

environment so that it can then run the container from it there's also a little bit of confusion around Docker Docker

desktop and Docker engine I've highlighted a few of the subcomponents here that make up what's known as Docker

engine and so that is the command line interface so that Docker CLI uh as well as the docker demon and the docker API

those make up what is known as Docker engine and that is the open-source core of Docker because the the Docker demon

only runs on Linux you can only install Docker engine on Linux you don't get sort of this niceness of the Linux

virtual machine and sort of the developer experience that the GUI provides but if all you need to do is

build run and interact with containers then Docker engine might be sufficient for your

needs in this course though because we're using Docker for development and likely many of you are on Windows and

Mac OS systems we're going to install Docker desktop so that we can leverage all of the developer experience niceness

that Docker desktop provides at this point I think we are ready to go ahead and install Docker on our systems and

start using it one thing that is important to call out is that for personal use Docker is completely free

you can use Docker desktop without paying anything uh however if you're using it for commercial purposes and

your team has either more than 250 employees or more than $10 million in annual revenue uh it does require one of

the paid tier subscriptions so depending on how using it within your company uh it may or may not be free so that's just

something to call out before we uh before we install it but for personal and learning purposes it is completely

free now to install it we can just go to the docker docs under docs. do.com Docker and so in preparation for this

video I actually uninstalled Docker so I'm going to go ahead and pull open Chrome and go to that uh site and so

here I am at docs. do.com getd doer it gives us options for Windows Mac and Linux uh so

choose whichever operating system you're on and then it will have some additional system requirements uh and information

that you're going to need I'll just click Docker desktop for Mac with Intel and it'll start downloading uh it is

quite a large file so we'll see hopefully my uh home internet is fast enough down below it has information

about system requirements uh for depending on the type of system that that you're running so you just want to

go through uh and read these the installation process is pretty much just like any other desktop application here

it's downloading that dot DMG file I'll then open it drag it into my applications folder on Windows similarly

a pretty straightforward installation process the one thing to call out is the two different options for the back end

so uh I described in the architecture diagram how you have your client running directly on your system but then you're

going to have this virtualized environment where the docker demon is running and so this is choosing whether

you want that Docker Dage to be running within WSL or using uh hyperv as the the backend

system if you are on Windows I would probably just go with this WSL backend as that's kind of the default option

here so it looks like my installation file has finished I'll drag it into

applications it expands from the 600 megab download into a 2 GB install and now I should be able to just

go to my applications and click on Docker it's

verifying it asks whether I want to trust it or not click open and so now here is that graphical user interface uh

one thing that I will call out is you may want to go under settings and then resources and here you can

specify how many of your system resources that Docker as a whole should have access to so here it's defaulted to

four CPUs 10 gigs of memory I'm going to give it access to a little more memory uh the defaults are likely fine for just

getting started but if you find yourself running up against resource constraints modifying these uh resource

configurations can be very helpful in in alleviating those constraints in order to have those

changes take effect you have to click apply and restart and so I'll do that now now at this point we can run Docker

commands and installing that application gave us both the CLI as well as the the docker demon and so let's run our first

container um one fun example that we can use is uh the whalsay container and so I can do Docker

run Docker SL whales say uh and then the command is going to be C say and I'll just

say hey team and so if I run that it's going to go off and find that public whale site image download it from

dockerhub so we can see it downloading now and each of those lines corresponds to one of the layers in that overlay

file system and so it's downloading each of those images onto the host system such that we can then run a container

from that image and we see it took the phrase that I put in here uh and gave us this nice asky

art output uh with that phrase built in and so with that we have uh pulled an image from dockerhub run a container

from it and provided a custom command so that's kind of the the most basic thing that we can do uh with a Docker image

and so that's a fun example but let's do something a little more useful let's say we needed a copy of postgres 15.1

running uh for our application uh we can just issue a Docker run command and then I'm I'm doing two options here one I'm

setting the postgress password environment variable uh that's just something that's needed the container

won't start if you don't set a password and then I'm also publishing Port 5432 and so because these Docker containers

are running on an isolated Network the only way that I'm going to be able to connect to it from my host is to publish

that port and so that publish command is saying take Port 5432 on my my my Local Host my system and connect that to Port

5432 inside the container uh I'm then specifying the postgres image and specifically uh version 15.1 uh running

on the Alpine operating system again it didn't have that image locally so it's going to pull that from

dockerhub once it finishes pulling it then starts up the image and now we have the

database system running inside that container ready to accept connections uh just to show that it is actually running

and and accept connections we can open up PG admin uh and we can see I've added this

Docker database uh and it was able to successfully connect to it uh and we can for

example run a query I could do select star from information schema

tables uh and run that and we get all the tables from that information schema within the database

running inside the container hopefully this gets you excited about the possibilities of what running inside of

these isolated container environments can provide in terms of your development life cycle now that we've run a couple

of simple containers on our system I want to really dive deep on using thirdparty container images and how we

can leverage these within our development process to solve a number of different use cases now dockerhub is a

container registry hosted by the company Docker there's over 100,000 publicly available images ranging from things

like Alpine and auntu which are different flavors of Linux to specific tools such as engine X which is a a web

server and reverse proxy or busy box which is a utility image that has tons of different uh useful commands that you

can leverage on your system from within Docker if you go to hub. do.com you can then search the images or browse based

on the different filters there on the left and so if there is some utility that you want to use likely someone has

created an image for that now before we go off and create a bunch of containers on our system I do

want to pause and call out the fact that by default any data that we create or modify within a container at runtime is

going to be ephemeral meaning if that container is stopped and removed from our host all those data will be gone now

there are two mechanisms by which we can help to solve this uh for dependencies that we want to be in the container when

it's started up we'll want to build those into the image itself and we'll look at how to do that um as you can see

in the diagram on the right if we remember that overlay that Union file system approach we have all of our

different build layers there and those at runtime are treated as readon so we've we're starting with an auntu image

we're installing uh some dependencies we're copying in our source code we're running npm install to pull in

those node uh those node dependencies all of those layers when we create a container from that image or treat it as

readon and then there's just this thin read WR layer on top that's where any data that's modified at runtime will go

if there's some additional dependency or configuration change that is needed rather than starting the container and

then making that change where that change would live in the the the read WR layer at the top we'll want to pull that

into our build process such that every time we create a container from that image it will have

the necessary change now the other case with data that we may want to persist are data

generated by the application at runtime so this could be things like data that we're storing in a database uh when a

user creates or or modifies some uh some aspect of their profile let's say on a website those data we can't incorporate

into the image because they're not known at build time but instead we need to store them in such a way that they'll be

that they will persist beyond the life cycle of the container itself now there's two mechanisms to do that the

first of which is called a volume and so we can create what's known as a Docker volume that will designate a particular

uh location within uh the docker host system so it will be within that virtual machine that Docker is running uh

located at/ barli doer volumes uh we can then when we run a container tell Docker to use that volume and mount it at a

specific path within our container file system such that any data we store there gets stored in the volume and that can

be managed separately from the life cycle of the container itself now the second option is a bind Mount it's a

where the volume Mount the data is still stored within that virtual machine on the Linux file system with a bind Mount

we're actually we're actually connecting our host file system into the Container at runtime so I'm going to have some

path on my system uh and then I'm going to mount that into the Container at runtime and now if I modify any files

within that path they'll show up on the host file system both of these are viable options Docker suggest using

volume mounts by default one reason for this is that because that bind Mount is crossing the boundary between our

virtual machine and our host system performance can be much lower if we are doing things that have a lot of reads

and wrs and so by default use a volume Mount if you need to have easy observability into the data that's being

modified or you want to be able to see the files that are being created more easily then a bind Mount can be a good

option also later in the course we'll use a bind Mount to actually Mount our source code into the Container such that

when we make changes and are developing on the Fly those changes can be represented within the container file

system right away I just covered a lot within this one slide but I created a walkth through in the GitHub repo that

we'll do now that I think will really solidify these Concepts so the read me for the fourth

module of the course uh so the running third party containers module has all of this within it and so now I'm going to

walk through the process here that is outlined in this read me and I think it will make what I was just describing uh

much more clear about data persistence so remember our container file system looks like this we have a number of

readon layers that that exist in the image and then we have a read right layer at the very top let's do some

experimentation with uh running a container installing something in it and seeing how that behaves when we create

additional containers from that same image so let's start by doing a Docker run command and we'll pass it the uh--

interactive flag in the D- TTY flag those two flags together mean that when we issue this command we'll get a

running shell within that container the-- RM flag tells Docker that once this container process exits so once we

exit the container uh it should not store that stopped container it should actually remove that from our system so

if we run this it's going to go off and pull that Ubuntu 224 image then it starts the container and now we're

running a shell inside that container let's try to Ping google.com from within the

container as you can see the pin command is not found it's not installed by default within that UB 2 image to

install it we can use the APT package manager we can do apt update that'll go off and fetch all the metadata

associated with uh the APT package manager and then we can do AP install IP utils

ping I'll say yes and so now with ping installed we should be able to call Ping

google.com uh one time that's the- C1 it's successfully pinged Google uh and that's great now I'm going to exit this

container and if we want to take a look at the container ID here d61 we'll get a different container ID the next time we

create create one so now I'm going to rerun that same command we're going to create a new container from that same

image and you see we have a different container ID this container doesn't know anything about that previous one and so

because we installed that pin command within the readr container image of the other container it was blown away

completely when we exited and Docker removed that container so now that we're in this container again if we try to do

ping ping is not found however let's change this experim ment just a little bit so I'll exit this

container and now I'm going to run the same command but I'm going to add I'm going to remove this dsrm flag so Docker

is not going to throw away the container after it stops and then I'm going to add a name option and so I'll name it my

Ubuntu container and now we have a shell inside that container again we're going to do

apt update and apt install and that will get our ping utility installed within the

container okay so now with ping installed we should be able to use it great and so now when I exit because I

didn't have that D- remove flag the container still exists on my system if I do a Docker PS that will list containers

but because it's stopped it doesn't show by default so I'll do a dash a and we can see my Ubuntu container was running

it was created 41 seconds ago it exited 13 seconds ago but it should this container even though it's in its stop

State still has that read write layer associated with it uh so I can uh now restart my container with the docker

start command so I'll do Docker start and pass it my container

name and then I can use the docker attach command to attach to the Shell running inside that container so now I'm

back inside the container and I can ping Google and it works successfully so that just shows we created a

container we installed the dependency in that container layer we stopped the container but did not delete it and then

we were able to jump back in that same container and that dependency existed again now normally we would never want

to jump into a container and modify things like this on the Fly the better approach and the approach that we'll

want to use for a dependency like this is we want this to always be there when we start a container from that

particular image so instead of starting the container and resisting it uh in the container itself instead we want to

build our own image containing that dependency and so we're going to do a much deeper dive on building containers

and optimizing those builds in module 6 but we can write a very simple Docker file here and pass it at the command

line so this is just saying start from that Ubuntu container image run the APT update apt install and that passes it to

the docker build command and then we're going to tag it with this tag my Ubuntu image so if I run this command

Docker is going to build a a brand new image based on the original but now this new image is going to have IP utils

installed out of the box if I want to run a container based on the new image I'll use the tag

specified in the build command and now I don't have to install ping because it's already installed so

now I can run ping Google and it succeeds so hopefully that gives you a better idea of how this container file

system works and the fact that if we want some data likely in the form of a dependency or configuration to be

available at runtime every time we want to build that into the image we don't want to start an image and then make

modifications to get it to the state we want and so that's the that's the case of data that we know about at build time

and can build into the image directly the Second Use case that I described was Data produced by the application at

runtime uh and so like I mentioned this could be data that's going into a database let's do some experimentation

to build up some intuition about this type of data again I'm going to create a container from that auntu image now this

time I've shortened the-- interactive D- TTY uh you get the same thing in a shorthand version with just - it and so

here we have a shell running in that container to simulate uh data created at runtime I'm going to make a directory

called my data and then I'm going to Echo hello from the container into a file within that directory and so

now if I C my data hello text we can see hello from the container stored in a file on the container file

system if I exit the container run a new container from the same image what do we expect if I try to

do cat my data hello text of course that file doesn't exist just like when we installed something into the

file system it's in that top readr layer that gets Blown Away away with the container but now we can no longer build

this into the image because we don't know what this file should say ahead of time so instead we're going to use a

volume I can run Docker volume create my volume and that creates a volume and now I can modify my run command such that I

mount the volume into the file system of that container so I've added this-- Mount

flag it's using the source of my volume which I just created and it's using a

destination of my data root SL myy dat now I'm going to do exactly what I did before I'll do make my

data oh it already exists because I mounted that volume that directory was already created so I'll Echo just like

before hello from container into a file within that directory I'll C it

our data exists within that file system but if I exit and then recreate a new container

also mounting that same volume we can go into my data and see that hello Tex has persisted across that

container destruction uh so the data was stored in the volume even though we stopped the container and Docker removed

it from the system the volume is treated separately and so we were able to persist the data across that container

boundary now you might be wondering where where does this file actually live um it has to live somewhere on disk and

in this case because I'm on Mac OS it lives within that virtual machine that Docker is managing um so it's if I was

on Linux it would just be directly at VAR lib Docker volumes because I'm in Mac OS I don't have VAR Li Docker

volumes that lives within the virtual machine one way that we can take a look at that is to run this privileged

container so this is a Nifty trick that I saw online where I can run this command and it will essentially give me

a shell into that virtual machine that Docker is running and now I can navigate to VAR

lib Docker volumes I see a whole bunch of volumes the one I care about is the one that I

named my volume now if I go into the data directory if I go into the data

directory and I see my hello. text and so this is showing in that virtual machine file system where that

volume actually lives now this was just a trivial example where I was creating that file

and wanted it to persist let's say we were running a database like we were running postgres before we would want to

use the same approach with a volume and mount it into the file system of the container where postgres was going to

store its data and so by default postgres stores atar lib postgres data and so we would want to modify our

Command to use that mounting syntax uh there's an alternative syntax with the- v that does the same thing and this

would allow us to store the databased data in a volume and manage that separately from the

container now I mentioned that volume mounts were one option and bind mounts were the other let's explore what a bind

mount looks like for the same use case now I'm going to take my command that I used before where I had a

volume Mount and change the type to bind so now the type is bind my source is my present working directory and in

particular the my data directory within my present working directory and so let's just list out to show I have a my

data directory here within there there's already hello. text let's remove

that so now there's nothing in my data and if I run this command I'm going to mount that directory from my host

file system at the present work directory SL myy data and the destination is going to

be rooty data on the container so let's Echo something in here blah

blah that's going to go into hello. text so inside the container we have blah blah within hello. text if I exit

that container I'm now on my host system and if I cat my data hello. text we can see that file was created and stored at

the path that I specified I can also modify the host data and that will be reflected inside of a container mounted

in the same fashion so I can do I'll add another blah okay so it's three BLS outside the

container I'll now recreate my container it'll actually be a new container but still mounted at that same path and if I

do cat my data hello. text we see the updated version reflected inside that container and so as you can see bind

mounts just like volumes are a mechanism to persist data beyond the container life cycle uh the volume Mount is kind

of tucked away inside the the file system that Docker is managing the bind Mount is located on my local

system by default Docker suggest using volumes they're slightly easier to manage however if you want easier

visibility into the data itself it can be convenient to use a bind Mount just be aware that you can suffer some

performance impacts if you're doing heavy read wres into the bind Mount location so my hope is that this has

helped to build your intuition around how data is handled within containers uh both sort of the default case then the

case where we want dependencies available in the container when it's started and then the third case where

data is generated at runtime and sort of how we should manage each of those either by building those data into the

image or by mounting a volume or a bind Mount uh to capture those data beyond the life cycle of the

container the other thing that I've called out within this read me that I think you'll find useful are specific

use cases for leveraging thirdparty containers directly and what by that I mean not needing to build our own

container image the first one is databases so databases are always a pain to deal with sometimes you need one

version sometimes you need another sometimes you'll have multiple databases that you'll want to interact with for

different projects Docker provides a super useful mechanism for spinning up a new container with a different database

that you can use and have that completely separate from one application to another from one version to another

uh very very easily I think the key considerations are to always use a volume to persist the data um if you

have additional configuration that you need so let's say there's a config file that you need to have in the container

when it's starting up to to in order to set some specific configuration you can use a bind mount to mount that from your

host file system into the container and then finally you'll want to set the necessary environment variables so a

number of the the official database images use environment variables to configure things like the root password

within the container so earlier when we started that postgres container we had to set the the postgis password

environment variable uh there's a number of things like that with these database container

images I've laid out a number of a number of different databases and I've tried to capture the specific volume

mount and environment variables that you might need to use so we've seen postres before um here I've added that volume

amount for the location where the data gets stored uh if you had a custom postr SQL comp file and didn't want to use the

default you would modify this command to use this bind Mount so you would have this on your local file system and then

you would pass the- C flag uh to The Container when you when you run it and pass it a path to that flag flag so this

is as you can see where we mounted inside the container this is that same path and that tells the container upon

startup to look there for the configuration file so mongodb the official image it looks quite similar as

you can see it's expecting to save the data to SL dat DB so we're we're putting that into a volume uh we're setting the

initial root username and password with environment variables and we're publishing the default Port of

277 again if we have a specific configuration file we need to pass in we're going to bind Mount that into the

container and then we're going to pass a configuration flag to tell where to look for

that I'll let you look at the rest of these on your own time but I've I've laid out the commands for redus MySQL

elastic search and neo4j now the Second Use case that I think using third party containers is

super useful for is when you need an interactive test environment for something other than what you're running

uh on your daily on your laptop so I'm running Mac OS but sometimes I need to test out commands in auntu or Debian or

or Alpine and so being able to run this Quick Command and have a interactive shell within that specific Linux flavor

is really Priceless like I can test out commands and iterate on them so much more quickly if I'm writing a script

that's eventually going to be run in that environment I'll just create a container using one of these commands

and then I have an interactive environment where I can test things figure out the exact syntax use the help

commands Etc inter inter active test environments for operating systems or for programming runtimes uh we can do

something very similar but instead of having a shell in the OS we'll have a a repple in our command line with a

particular version of that programming runtime and so if we're if we're testing something that needs python 3111 versus

3110 uh or some minor tweak it's so easy using Docker to get an environment that has the exact versions that we care

about for doing that type of test now the final sort of use case that I find super helpful for using thirdparty

containers are command line utilities sometimes you just won't have it installed or you don't have the right

version and so people have bundled up these utilities and because so many Unix tools are designed to pass data as text

from one to another so we can pipe data from one command to the next um we could pass data into these containers and get

the output as a stream uh we can use these without actually having them installed on our system so

JQ is a utility for working with Json data and so for example uh if I run this command so if I jump back

here and we look at the sample data I have here so let's say I have this test. Json it has key1 value one key2 value

to if I run this command it's going to take that test Json data file pass it into this JQ image and

perform this command so it's going to find the value located at key1 and combine it with the value located at

key2 and so in this case I get value one value two as a string and that's the output and so without having JQ

installed on my system I'm still able to use that utility directly with Docker yq is similar to JQ but is for yaml there's

also command line interfaces from cloud providers such as the AWS command line or the Google Cloud platform command

line uh and you can run those in container images uh you will need to mount in your credentials so by

default we know that the container is not going to have access to the host file system and so if your credentials

are stored at let's say the AWS directory within your home directory or the config directory within your home

directory you'll need to craft the the correct volume the correct bind Mount commands to get those credentials uh

into the CLI but once you do that it allows you to use different versions of the C very easily and so if there was a

breaking change from one version to the next you can leverage that previous version without having to reinstall and

modify things if you've already upgraded now this sounds cool but you might be thinking I don't want to have to type

out Docker run blah blah blah with all these bind mounts Etc and so so one way that we can improve the ergonomics of

this quite a bit is to use two concepts one is a shell function so we can write a function like this that will take this

command and essentially invoke it when we run this function we also can use an alias to do the same thing to to close

out this section I wanted to pull up a talk that was given by Jesse frel um I think this was in 2015 so this is quite

a few years ago uh Docker was much younger in its maturity however she was an early adopter and employee at Docker

and used to run all sorts of things uh within Docker and so I think this is a talk that is worth watching for sure and

just sort of shows that you can pretty much run anything in containers giving it a watch is really interesting and

inspiring and helps to understand sort of this mindset of I don't necessarily need to install everything on my host

system she goes a little further than most with this concept uh but I think it it's still eye opening to see the number

and types of things that she's able to run in containers so with that we've reached the end of the first portion of

the course in which we learned the history and motivation of Docker about the underlying Technologies we installed

and configured Docker such that we're now able to run containers and interact with them and then we saw some use cases

for leveraging thirdparty container images for different things throughout our development life cycle at this point

we're going to shift gears and start building building our own containerized applications I think it's important to

realize that learning Docker in a vacuum doesn't actually provide much value and so instead we want to have some

realistic web application with which we can apply this technology in this module I'm going to walk through a sample

application that I've built for exactly that purpose it's a minimal three- tier web application and by three tiers we

have the front the front end or the client that's built in react we have an an API layer application programming

interface layer we have one API built in node.js so that's an interpreted language one built

in goang a compiled language we have both of those they're almost identical but I wanted to show two different

languages with two different developer tool chains so that we can showcase how Docker handles those slightly

differently and then we're going to have a postgres database I've tried to keep each of these components as simple as

possible while still being representative of the type of application that you might see in a

modern web technology company today the implementation of each of them will be quite minimal but how we configure

things like networking and passing credentials will be realistic to an application at a web technology compy at

this point I'll jump over to my code editor and walk through this code at a very high level I'll point out though

because this course is focused on Docker and containers and not on web application programming I'll keep this

relatively high level just to give you an idea of the things that the code is actually doing and highlighting the

configuration surface area where Docker is going to interface with them at this point if if you haven't already you'll

want to go to the companion repo for this course I'll have a link for it down in the description uh and you can find

all the source code that we'll be going through and building out uh and what you'll want to do is here under code uh

you can either click here and clone it to your system but even better is if you Fork it because that way you can make

modifications commit those modifications and if you have any improvements you'd like to make uh and propose back to the

course for others to use you could create a poll request back to my copy of this repo on get Hub and that would be

awesome while you're here if you don't mind giving it a star that would be super helpful to help the project grow

and while I'm asking for your support you may as well hit the thumbs up button on the video as well and so with that

let's jump over to the text editor and see this demo application so I've got the code editor up here uh and we're in

module 5 the example web application I'm going to start by running the database just like we did in module 4 I'm going

to run the database with a Docker run command I'm going to pass it a postgress password environment variable I'm going

to use a volume Mount like we talked about to persist the data outside of the container in this volume so it can live

beyond the life cycle of this particular container and then I'm going to publish Port 5432 which is the default Port that

postgres runs on and I'm using postgres 15.1 uh and in particular the Alpine variant so this is a make file each of

these is called a make Target we can do make run post Gres and now we have that database

running in a container container I can do the docker PS command to list out the containers running and

we can see here's the container this is the image it was based on uh because I didn't specify a name it generates a

random one and we're publishing that Port so that I can connect from my local host at this point let's move and take a

look at the node API and get that running as well so it's located within this API

node uh subdirectory uh if we look in the package.json file we can see there are just a couple

of dependencies we have Express which is a package for building rest based apis we

have Morgan which helps us configure logging uh for that API a little more easily and then we have the PG package

or the postgres package uh which is going to allow us to create a client and connect to the

database so what I'm going to do here is make sure I'm running the right version of node so I have NVM installed

so I can do NVM LS it'll list out the different options that I have installed on my system I want 19.4 so I'll use nbm

use node 194 and then I'll do npm install it's going to grab those dependencies from

the package.json and install them in my system in this node modules folder if I wanted to run the

application I would do npn run Dev but I also need to pass it one environment variable and that environment variable

is the database URL so this is going to give the application the information it needs to connect to that post Chris

database running in the container and so again I have the same I have this command laid out here and so I'm just

going to do make run API node and now it's started up and listenting on Port 3000 let's just go

see how that application behaves if I load it up we see uh at the root path so I haven't specified any

path it Returns the current time stamp and I'll show it I'll show you how this is working behind the scenes but it's

just querying the database asking for the current time and then returning that and then I have the API node key and

value just to show this is the node based API we'll have an an almost identical response from the goang API

except this will say goang instead of node for each time we refresh the page uh

we're seeing there's a a 200 response that's a successful HTTP response uh for the request and then we have this 404

for the favicon so because I'm loading it from uh from a browser it's also trying to load that little icon that you

would see in the top left corner but it doesn't have one so that's the the 404 not found error that we're seeing

there now let me just look very briefly at the source code for this application to show you what it's doing we've got

two primary files index.js is the main one we're importing some dependencies here at the top we're setting the port

number that we're listening on defaulting to Port 3000 uh we're setting up some logging and then here's where we

Define that API endpoint where we call our get date time function which I'll show you here in a minute uh and then we

populate the uh node we populate the API key within that Json object as well uh in our database do our db. JS file uh is

where we have that function uh it's where we're going to load in our connection our credentials so that we

can connect to the database instantiate a new uh pool which will be that database client uh and then make the

necessary call to the database to get the time that then we we can return on that

endpoint and so that's pretty much all there is to this node application like I said I want to keep this as simple as

possible while still highlighting the types of networking and configurations that they would we would need in a real

world application uh at this point with the node application running we can jump uh

we can move on to the the goang application and so for this one it's located at the subdirectory API

goang uh here I am within that directory uh to install the dependencies I would do go Mod download uh first I'm going to

set the go path just to tell it where to download those modules to to set a workspace um I've got this go workspace

subdirectory uh I can export go path and that will point to that subdirectory now if I do go Mod

download it's going to look for the dependencies that are in my go mod file and so the two dependencies that I've

added here are Jin which is a an API framework work uh and PGX which is a postgress client and so that go Mod

download looked in go mod brought those into my workpace okay so now we should have all of our necessary uh

dependencies uh and just for reference I'm using uh go19 and so to execute this program I

would do go run and then point it to the the main.go file uh that's going to both build the application and run that built

binary um again just like the uh node application I either need to pass it an environment variable with the database

URL or pass it a file containing those credentials um I have a command in my make file that does just that uh so I

can do make run API goang we see it passes that database URL in as an environment VAR variable

and then executes our go L and then does gun main.go uh that's running on port 8080 so I can go here and reload this

and very similar response to the no l to the node.js one uh we have API goang and then it's grabbing that time stamp from

the database each time I refresh it gets an updated time and so just very briefly uh I can

take a look and show you the implementation here I'll pull open the the main file uh as you can see we

import our dependencies here at the top uh we then have our init function uh within there we're loading in the

credentials that we need to to connect to the database once we do that uh we pass those credentials uh to this init

DB function which is defined in the database module that I'll pull up here in a minute and then within our main

function we have our endpoint defined where we uh call our database. getet time function and take the results of

that and we've returned that Json object using Jin I'll just pop open the database module here just to show you

the two functions there um we've got our init DB function where we're taking our connection string uh with those

credentials uh and initiating a client uh and then I have this get time function which just like in the node

implementation is calling select now is now getting those data back and and returning that uh to the

caller and so that's really all there is to this application like I said almost identical to node we just want to have

both of these different languages so we can show how to manage the different tool chains how we're going to build the

docker container images and how we're going to create containers from those images now with the goang API running

the final piece of the puzzle is going to be the react client uh so that implementation is here in the client

react subdirectory uh once again we can look at the package.json uh we have a handful of dependen we have react and

react Dom those are installed by vit when I created this project I used V to do so and then I added axios as well as

this react query package which just enabled me to very easily call my apis get those data and feed that data into

my react uh components uh so I'll want to once again just make sure I'm using the right

version of node I want 19.4 great I'll do an npm uh make sure I'm in the right directory

then I'll do npm install this goes off and downloads uh all those dependencies brings them into

my my local um node modules folder and then to run it uh I'll just do npm run

Dev and by default uh V is going to run that development server on Port 5173 so if I load the page here

uh we see the result it's a react app it calls both of those apis gets the data and returns them each time I refresh you

can see that the the time stamps are updating and so that's doing exactly what we wanted to do once again I can

give you a quick look at the source code just so I can show you what it's doing all the logic pretty much is in

this app.jsx file we're pulling in our dependencies at the top I have this function based component called current

time that uses the use qu method and axios to make a get call to the uh API that's specified and so this enables me

to use the same component for both those apis by passing the API in as a prop I then get the data back and can use that

within my component then down here this is the actual content that's going to be

displayed I just have which API it's coming from from data. API and then the time stamp that was returned in data.

now while it's still fetching it will just it will have this placeholder up dating text here at the bottom is the

content of our app itself uh we wrap it in this query client provider uh that just enables us to use uh the

functionality within uh that react query package we've got our static header and then two instances of the current time

component uh one where we're passing it the goang path one where we're passing it the node path it is important to call

out here that within my V.C config I have these proxies set up such that API goang is sent to Local Host 880 where

the goang application is running and then API node is passed to uh Local Host 3000 where the node API is running

that's pretty much it for this configuration hopefully that didn't seem too overwhelming uh it's quite complex

trying to run all of these Services independently and get them all talking to each other that's kind of the whole

point of this course right I want to avoid having to set up each of these Services separately and avoid the

complexity of needing to match the right version on your system versus my system and Mac versus Linux versus Windows

docker's going to help us simplify this dramatically and so as we progress through the rest of the course we're

going to take these components containerize them and then learn how to run those containers how to configure

them properly and how to set up a development environment such that we can very easily go from zero to rapidly

developing and iterating on our applications all within a containerized setup and what I really tried to do with

this application is have each component be the absolute minimum complexity while still giving us that application the

networking the configuration be representative of what you would see in a modern-day web technology company and

so ideally don't get bogged down with any of the particular applications themselves but just try to understand

here is the core of what it's doing we have our client on the front end it's calling those two apis so we need the

networking to be set up properly there those two apis instantiating clients and connecting to that database and making a

database call so we need to handle those credentials properly as well as the networking between them and just

generally we need to have our environment set up for each of these applications to run as

desired now that we have our example application we can go through the process of containerizing it now what

that means is that we're going to create a specification and then we're going to build from that specification our

container image the specification is what is known as a Docker file so it's a text document