- 15 hours ago
Category
📚
LearningTranscript
00:01and next we are going to touch upon some of the basic concepts of docker network or docker networking
00:06docker network already we can check our networks using this command which is docker network ls
00:14by default docker creates three different types of networks for us and all of these use a different
00:20type of driver so three ways we have network drivers one is bridge one is host one is null
00:26any drivers go now we will try to understand these drivers basically our host machine
00:31if this is the host machine in our host machine when there are containers built
00:35so this is our container this is the host by default all of the containers have networking enabled
00:43networking enabled means that this can form the outgoing connections
00:46if we want our container to interact with our host machine and other containers can interact
00:51or then with internet also interact so this means networking exists when we talk about
00:57docker containers
00:58now our container is based on the way we can define our container which is external entities
01:06which can connect with our container which is the driver which is the bridge type or host type
01:12or null type which is defined by the container which can interact with other containers or
01:17which can interact with our container which can connect with our container which can connect with our
01:22container which can form different connections
01:24for that we have three major options when we talk about the drivers
01:29and the most important two options are the first type of network driver is a bridge driver
01:35after that we will apply our host driver and we will also look at the null type
01:40so first let's talk about our bridge driver
01:44generally by default as many new networks create for a container
01:49for a container
01:49in order for the default driver bridge
01:51so docker inside the bridge we can imagine
01:54this is the host machine
01:56and by default docker has our bridge driver
01:59which will automatically create a new container
02:01which will automatically create a new container
02:02so it will be associated with this bridge
02:04and because of this bridge driver
02:05because of this bridge driver
02:06the other containers are attached
02:08they can interact with each other
02:11so basically when we create a network
02:13in which the driver is of bridge type
02:15we give our containers the ability to interact with each other
02:18then we have built our MongoDB application
02:21our default network
02:22so in that custom network
02:24by default the driver is attached
02:25that is a bridge driver
02:27so basically in our MongoDB application
02:29we have built our custom network
02:31which was Mongo network
02:33and this Mongo network
02:34and this Mongo network
02:35we have built two containers
02:36one was our Mongo container
02:38second was our Mongo express containers
02:41and because the default driver
02:44was the bridge driver
02:46so these two containers
02:47were attached with this
02:48and then they could interact with each other
02:50so when we need this type of set up
02:52for a container
02:53where a container is able to interact
02:55with other containers
02:56on the same host machine
02:57then we give bridge type
02:58preference to the bridge type
02:59now we can also learn about network drivers
03:02on Docker
03:04by visiting this page
03:05so here the first type
03:07that is the bridge type
03:09which is the default network driver
03:11so if we don't specify the driver
03:13then by default
03:14we have a bridge driver
03:16that is used for us
03:17and it is commonly used
03:18when your application
03:19runs in a container
03:20that needs to connect
03:21with other containers
03:22on the same host
03:23so using the bridge type
03:25we have two different types of networks
03:26one is our default networks
03:28which is created by default
03:30which is created by default
03:31which is created by default
03:32and second
03:32we have custom networks
03:33so in this way
03:34the Mongo network
03:35created by default
03:37it was not a custom network
03:38but its type
03:39which was the same
03:40which was bridge
03:40so the default bridge network
03:42and custom bridge networks
03:43there is a common difference
03:45which is this
03:45that in custom bridge networks
03:47if containers
03:48interact with one another
03:49then as such
03:51any port number
03:52or container ID
03:53or other things
03:53they can interact directly with one another
03:56so the first important type
03:58we have bridge
03:58second important type
04:00we have host
04:01we have host driver
04:02host driver
04:03in the case
04:03whatever container
04:05we create
04:05this container
04:07uses the same network
04:08which our host machine
04:10uses
04:10and whenever we are using
04:12the host type
04:13for a container
04:13in that case
04:14our container
04:14has no IP address
04:18so we can read about
04:20the host driver
04:20here
04:21remove network isolation
04:23between the container
04:24and the docker host
04:25basically
04:26our host
04:26inside the container
04:27under the network
04:28isolation
04:29if we don't need that
04:30isolation
04:31if we want to use both
04:32same network
04:33then we use host driver
04:35and with this
04:36there is also
04:37a third type
04:38which we have by default
04:39create
04:40which is NUN
04:41NUN means
04:42whatever
04:43host machine
04:44inside
04:45if we have
04:46any container
04:47created
04:47then
04:49this container
04:50can connect with
04:51host machine
04:52or
04:53any other
04:54container
04:54so
04:56if we have multiple
04:57containers
04:58we want to run this
05:00isolated manner
05:01so
05:03either
05:03it can interact with
05:03other containers
05:04or
05:05host machine
05:06in that case
05:06we use the null
05:07driver
05:08so this was all about
05:09docker networks
05:10we can also read about
05:11more drivers here
05:12but in sub
05:13most important
05:14for us
05:15to bridge and host
05:16sometimes
05:17sometimes
05:18we can use none
05:19or other types
05:20but we need to have
05:21good understanding
05:22so
05:23this was a complete overview
05:25of what docker is all about
05:27we have a complete understanding
05:30in fact
05:30end to end
05:31understanding
05:32how docker
05:33docker
05:33docker
05:39docker
05:42docker
05:56docker
05:57and
05:57there are also many different things
05:59that we have explored
06:01about docker
06:01docker compose
06:02is definitely one of the most important things
06:04that we have covered with
06:05and instead of managing multiple containers
06:07from the command line
06:08we can also use docker compose
06:10in our day-to-day development work
06:11so
06:11I hope
06:12that docker
06:13will become a strong fundamental
06:14understanding
06:15and we will take into this same understanding
06:17we will take into our development process
06:19so
06:20that's all
06:20today
06:20we'll see on the next topic
06:21till then keep learning and keep exploring
06:29hi everyone
06:29and in the next series of lectures
06:31we are going to cover the core concepts
06:33of CICD
06:34which is continuous integration
06:35continuous delivery
06:36and we are also going to set up
06:38our own CICD pipeline
06:39now
06:40first of all we know
06:40what exactly
06:42does CICD mean
06:44CICD's full form
06:44is continuous integration
06:46and continuous delivery
06:47for the sake of simplicity
06:48we call it continuous deployment
06:50also
06:50the difference between both
06:52is slowly and slowly
06:53we are going to understand
06:53in the entire section
06:55now
06:55before understanding these two terms
06:57we have a basic concept
06:59let's suppose
07:00let's suppose
07:00we have an application
07:01a website
07:02it's an e-commerce website
07:03for that
07:04assume that
07:05we have built a modern website
07:06which has a front-end
07:08and a back-end
07:09and we have a website
07:10we have already deployed
07:11many users
07:13who are using that website
07:14now
07:14it is not that
07:15once
07:16we have built our whole website
07:17in the future
07:18definitely
07:19we will add some new features
07:20in the future
07:21or
07:22if there is a bug
07:23that we have to fix
07:25we have to fix
07:25so this means
07:26that if any application
07:28exists
07:28then in the future
07:29there are many changes
07:31that will come
07:32now
07:33when we change
07:34a existing website
07:36within an existing application
07:37then
07:38first of all
07:39we have to test
07:42those changes
07:44which means
07:44that if any new feature
07:46we have added
07:46after adding
07:47that
07:48our website
07:50functions
07:51and work
07:52we have to ensure
07:54this thing
07:54now
07:55generally
07:55we do
07:57unit testing
07:58and integration testing
07:59in our application
08:00what is the unit and integration testing
08:01exactly
08:02what is the unit and integration testing
08:03we have already covered
08:03in our project-based learning
08:04different projects
08:06but we will also recover that part
08:08in this section
08:09basically
08:09in any application
08:10unit testing
08:11means
08:12that we are testing
08:14the individual components
08:15for example
08:17if we have added back-end
08:18node.js
08:19then we will have
08:20javascript files
08:20we will write different functions
08:23in the javascript files
08:24so we can write
08:25the unit tests
08:27for these functions
08:28automatically
08:29test
08:29for example
08:31if we have made
08:32some name function
08:32which is work
08:33to calculate some numbers
08:35for this
08:35for this
08:36for this
08:38when we send 2
08:39plus 2
08:40then we have
08:41output 4
08:42or something else
08:43when we send
08:441 plus 2
08:45then we have output 3
08:47or something else
08:48if we have output
08:49right
08:49it means
08:50that we are working
08:50in our individual components
08:53this is the
08:54core logic
08:54of what unit testing is
08:56we are also going to cover
08:56some more parts
08:57related to unit testing
08:58in the later section
08:59a first type of testing
09:00will be unit testing
09:01which generally
09:02the developers
09:03and the second type of testing
09:05is called integration testing
09:07integration testing
09:08means
09:08when we have new changes
09:10in the application
09:10then we can work
09:11different applications
09:12modules
09:12and components
09:13together
09:15from the end user point of view
09:16basically
09:17if we have made
09:18a social media application
09:19built
09:19then we can log in
09:21after the new changes
09:22after the new changes
09:23is the user able
09:24to create a new post
09:25are they able
09:26to post their photos
09:27videos
09:27different users
09:28are able to comment
09:29them
09:30like them
09:31they can share
09:31so in this way
09:33different features
09:34and functionalities
09:35in our application
09:36we test
09:37in the integration
09:37testing
09:38and this is something
09:39which is generally handled
09:40by the QA team
09:41in a company
09:42whatever new changes
09:42in our application
09:44they will only be accepted
09:45if they pass
09:46all of the tests
09:47which are defined
09:48for that application
09:49now if this test
09:50fails
09:51then the developer team
09:52tells us
09:53that this is something
09:53that failed
09:54and they need to fix it
09:55in the second stage
09:56that once
09:57the tests passed
09:58after that
09:59finally
09:59we have to deliver
10:01or deploy
10:02now deploy
10:03it means
10:03finally
10:04we are available
10:04to the production
10:05server
10:06and our end users
10:07can see it
10:08now the deployment
10:09can also be
10:10as well
10:11for the sake of simplicity
10:13we are going to use AWS
10:14in our lecture
10:15so these are two
10:16which are done
10:17when we wish to push a new change
10:18into our application
10:19and push a new change
10:21now generally
10:22in the olden times
10:23these two processes
10:24used to happen manually
10:25i mean manually
10:26there was a team
10:27that did all the work
10:28for us
10:29but in the recent times
10:30what do we do
10:31we do these processes
10:32in an automated way
10:36by writing a script
10:37in an automated way
10:37so for these two things
10:38we use CICD pipelines
10:41basically
10:41whenever we have
10:42a new change
10:44in our application
10:44after that
10:45we create the build
10:46and test it
10:47that process
10:48is called
10:49continuous integration
10:50and this is an automated
10:52process
10:52like new changes
10:54from different developers
10:55like that
10:56we are automatically
10:56testing the website
10:57and the second step
10:58is continuous delivery
10:59which we can also
11:00call continuous deployment
11:02in which
11:02as we test all these applications
11:03we are automatically
11:05deploy
11:06now the whole process
11:08is in an organization
11:09generally
11:10our devops team
11:11handles
11:12and it is
11:12manual intervention
11:14generally
11:14in the initial phase
11:15is a lot of
11:16but in the future
11:17the new changes
11:18are pushed
11:19in the future
11:19they will work
11:20in an automated manner
11:21so to summarize
11:21CICD stands for
11:23continuous integration
11:24continuous delivery
11:25which can understand
11:25very easy
11:26so we are testing
11:28new changes
11:29in our website
11:30and deploy
11:32generally
11:33CICD
11:33this infinity sign
11:34is something that we see on the internet
11:36so this means
11:37that this process
11:38is going to infinity
11:39automatically
11:40Why is automation better than the manual process
11:42we used to have?
11:43First of all reason is reliability
11:45because we are doing the whole process
11:47automation
11:48so the scope of manual errors
11:50decrease
11:50and the second reason
11:52is the speed of execution
11:53that we have
11:54generally
11:55manually
11:56we have a lot of effort
11:58in this work
11:58we have done a lot of projects
11:59in our many projects
11:59in AWS
12:01and different platforms
12:03so that is generally
12:04a time taking process
12:05if we do new changes
12:06in our projects
12:07then we have to repeat
12:08every time
12:09but when we have automation
12:11the process
12:12will execute very little
12:13and that saves the entire team
12:16a lot of time
12:17so in today's session
12:17we are going to cover all CICD
12:18core concepts
12:20but our major focus
12:22will be on continuous deployment
12:24because this is something
12:25that will be more useful
12:26to us as developers
Comments