So we just saw how the voting application works on Tucker.
Let's now see how to deploy it on corporate notice.
So it's important to have a clear idea of what we are trying to achieve and plan accordingly.
Before we get started.
So we already know how the application works.
And it's a good idea to write down what we plan to do.
So our goal is to deploy these containers.
These applications as containers on our coronets cluster and then enable connectivity between the containers
so that the applications can access each other and the databases and then enable external access for
the external facing applications, which are the voting and the result app so that the users can access
the Web browser.
Right.
So how do we go about this?
Now we know that we cannot deploy containers directly on coronets.
We learned that the smallest object that we can create on a Cabernets cluster is a pod.
So we must first deploy these applications as a pod on our cabernets cluster.
Or we could deploy them as replica sets or deployments, as we have seen through throughout this course.
But first, for the sake of simplicity, we will stick to pods in this lecture.
Right.
And later we will see how to easily convert that to a deployment.
So once the parts are deployed, the next step is to enable connectivity between the surfaces.
So it's important to know what the connectivity requirements are.
So we must be very clear about what application requires access to what services.
We know that the red this database is accessed by the voting app and the worker app.
The wadding app saves the world to the red.
Its database and the worker app reads the world from the red database.
We know that the PostgreSQL Whewell database is accessed by the worker app to update it with the total
count of roads.
And it's also accessed by the result app to read the total count of votes to be displayed in the resulting
Web page in the browser.
So we know that the voting app is accessed by the external users, the voters, and the result app is
also accessed by the external users to view the results.
So most of the components are being accessed by another component except for the worker app.
Note that the worker app is not being accessed by anyone.
You can see arrows going into all of these components, but there are no arrows going into worker,
which means none of the other components or external users are accessing the worker app.
The worker app simply reads the count of votes from the Reds database and then updates the total count
of votes on the Progress CUAL database.
So none of the other components nor the external users ever access the worker app.
Now, while the voting app has a Python Web server that listens on Port A-T and the result app also
has a no jass based server that listens on Port 80 and they read this database has a service that listens
on Port six three seven nine.
And the PostgreSQL database has a service that listens on Port five, four, three, two.
The worker app has no service because it's just a worker and it's not accessed by any other service
or external users.
So keep that in mind.
So how do you make one component accessible by another?
Say, for example, how do you make the greatest database accessible by the voting app?
Should the voting app use the IP address of the reddest part, perhaps?
No, because that can change.
The IP of the port can change if the port restarts.
And you may also run into issues when you try to scale your applications in the future.
The right way to do it is to use a service.
Now we learned that a service can be used to expose an application to other applications or users for
external access.
So we will create a service for the reddest pod so that it can be accessed by the voting app and the
worker app.
And we will call it a red this service, and it will be accessible anywhere within the cluster.
By the name of the service Radice.
So why is that name important?
The source code within the voting app and the worker app are hard coded to point to a Redis database
running on a host by the name Radice.
So it's important to name your service.
This so that these applications can connect to the red database.
And this is not a best practice to hardcore stuff like this within the source code of an application.
Instead, you should be using environment variables or something.
But for the sake of simplicity, we will just follow this application as it is developed.
Right now, these services are not to be accessed outside the cluster.
So they should just be of type cluster IP.
So we will follow the same approach of creating a service for the PostgreSQL pod so that the PostgreSQL
DBE can be accessed by the worker.
And the result app.
So what should we name the PostgreSQL service?
If you look at the source code of the result app and the work app, you will see that they are looking
for a database at the address DBI.
So the service that we create for PostgreSQL should be named DBI.
Also note that while connecting to the database, the worker and the result apps passing a username
and password to connect to the database, both of which are set to progress.
So when we deploy the postgrads d.b pod, we must make sure that we set the these credentials for it
as the initial set of credentials to while creating the database.
Now the next task is to enable external access.
So for this, we saw that we could use a service with a type set to node port.
So we create services for voting app.
And the result app.
And set there Type two node port.
Now we could decide on what port we are going to make them available on.
And it would be a high port with a port no greater than 30000.
So we'll do that when we create the service.
So we are done and we have the high level steps ready.
So to summarize, we will be deploying five port in total.
And we have four services.
One for red is another for postgrads, both of which are internal services.
So they are of type cluster IP.
And we then have external facing services for Wooding app.
And the result app.
However, we have no service for the worker pod.
And this is because it is not running any service.
That must be accessed by another application or external users.
So it is just a worker process that reads from one database and updates, Senator.
So it's not going to require a service.
Now I say that again, as that's a common question that I get when we talk about services.
Why does this work or not require a service?
Right.
So a service is only required if the application has some kind of process or database service or Web
service that needs to be exposed.
That needs to be accessed by others.
In this case, that's that's not true for the worker app.
Now, before we we get started with the deployment note that we will be using the following Docker images
for these applications.
So these images are built from a four of the original developed at the Docker samples repository.
The image names are called cloud slash example.
Wooding app underscore vote with a tag of me one.
And then again, worker B one result won.
And for the databases we will use the official redis and post crepuscule releases that are available.
Right.
So that's it for now.
And we will see this in action in the upcoming demo.