Hello and welcome to this lecture in this lecture.
We will try and understand micro services architecture using a simple Web application.
We will then try and deploy this Web application on multiple different Coburn as platforms such as Google
Cloud Platform.
I'm going to use a simple application developed by Docker to demonstrate the various features available
in running an application stack on Docker.
So let's first get familiarized with the application, because we will be working with the same application
in different sections to the rest of this course.
This is a sample voting application which provides an interface for a user to vote and another interface
to show the results.
The application consists of various components, such as the voting app, which is a Web application
developed in Python to provide the user with an interface to choose between two options a cat and a
dog.
When you make a selection, the vote is stored in red is for those of you who are new to red is red.
In this case, serves as a database in memory.
This vote is then processed by the worker, which is an application written in dot net.
The worker application takes the new vote and updates the persistent database, which is at Postgrads
Escuela in our case.
The Post Chris Escudo simply has a table with the number of votes for each category.
Cats and dogs.
In this case, it increments the number of votes for cats as our vote was for cats.
Finally, the result of the vote is displayed in a web interface, which is another Web application
developed in No G.S..
This resulting application reads the count of votes from the Post's Chris Siecle database and displays
it to the user.
So that is the architecture and dataflow of this simple voting application stack.
As you can see, this sample application is filled with a combination of different services, different
development tools and multiple different development platforms such as Python.
No G.S., dot net, et cetera.
This sample application will be used to showcase how easy it is to set up an entire application stack
consisting of diverse competence in Dakar.
Let us see how we can put together this application stack on a single docker engine using docker run
commands.
Let us assume that all images of applications are already built and are available on Docker repository.
Let us start with the data layer.
First, we are on the Docker Run command to start an instance of red is by running the docker run.
Red is command.
We will add the dash D parameter to run this container in the background and we will also named the
container red this.
Now, naming the containers is important.
Why is that important?
Hold that thought.
We will come to that in a bit.
Next, we will deploy the Postgrads sequel database by running the Docker Run Postscripts Command.
This time, too, we will add the Dashty option to run this in the background and name this container
DBE for database.
Next, we will start with the application services, we will deploy a front, an app for voting interface
by running an instance of wanting app image.
Run the Docker Run command and name the instance vote since this is a Web server.
It has a Web UI instance running on Port 80.
We will publish that port to five thousand on the host system so we can access it from a browser.
Next, we will deploy the results web application that shows the results the user.
For this, we deploy a container using the results dash app image and published Port 80 to Port five
thousand one on the host.
This way we can access the Web UI of the resulting app on a browser.
Finally, we deploy the worker by running an instance of the worker image.
OK.
Now, this is all good and we can see that all the instances are running on the host.
But there is some problem.
It just does not seem to work.
The problem is that we have successfully run all the different containers, but we haven't actually
linked them together.
As in, we haven't told the voting web application to use this particular red, this instance.
There could be multiple red is instances running.
We haven't told the worker and the resulting app to use this particular PostgreSQL database that we
ran.
So how do we do that?
That is where we use links.
Link is a command line option, which can be used to link two containers together.
For example, the voting app Web Service is dependent on the ready service.
When the Web server starts, as you can see in this piece of code on the Web server, it looks for a
ready service running on host.
But the voting app container cannot resolve a host by the name.
Read this.
To make the voting app aware of the ready service, we add a link option while running the voting app
container to link it to the red.
This container.
Adding a dash dash link option to the DOCA run command and specifying the name of the red is container,
which is which in this case it's red, is followed by a colon and the name of the host that the voting
app is looking for.
Which is also read this in this case.
Remember that this is why we named the container when we ran it the first time.
So we could use its name while creating a link.
What this is, in fact, doing is it creates an entry into the ATC host file on the voting app container,
adding an entry with the host named where the internal IP of the red, this container.
Similarly, we add a link for the result app to communicate with the database by adding a link option
to refer the database by the name D.B..
As you can see in this source code of the application, it makes an attempt to connect to a postscripts
database on host DBI.
Finally, the worker application requires access to both the Radice as well as the Postgres database.
So we add two links to the worker application.
One link to link theoretics and the other link to link Postgres database.
Note that using links this way is deprecated and the support may be removed in our future in Dacher.
This is because, as we will see in some time, advanced and newer concepts in Docker Swarm and networking
supports better ways of achieving what we just did here with links.
But I wanted to mention that anyway.
So you learned the concept from the very basics.