In this demo, we're going to deploy our application on the Google Cabernets engine on Google Cloud
platform.
So as a prerequisite, you must have access to the Google.
A Google cloud account.
Google provides a twelve month free trial with the credit of $ 300.
And that should be sufficient to follow this demo.
So if you don't have access to a Google cloud already, now use this link and sign up.
Now, of course, some basic understanding of working with the Google cloud environment and the shell
are required so that you can set up all the prerequisites.
So we won't be going into that.
Once logged in to the DCP console, we have a project that we've created by the name example voting
app.
So to start with GCE, click on the navigation menu on the top left corner and under the computer section,
click on Coronets Engine.
Once you're in this page, click on Create Cluster.
So this should load the components cluster creation interface.
So the first thing that you have to do is change the name here.
So we'll we will name it.
Example Wooding app.
We will leave the default values and therefore location type and the zone.
We will live it as as it is.
The master version is the community's version, which we could either set to a static version or select
release channel to automatically upgrade the components versions when new versions are made available
on G.K.
Otherwise, if you set it to static, then you upgrade manually.
We talk about the cluster upgrades in detail in the Saeki, of course.
For now, let's leave it at the default and you may choose another version by clicking on this dropdown
link.
Now you can make additional changes to the worker nodes that have to be configured so you can make change
to the type of virtual machine to be used, the size, etc. But we are just going to stick with the
defaults for now.
So we will proceed with creating the cluster.
So click on CREATE to begin the creation process.
Remember, this can take anywhere between five to 10 minutes.
So let's just wait and give it some time to complete.
You may click on the refresh button to refresh the status.
All right, so now the cluster has been set up.
Now you can see that by the green checkmark next to the cluster name.
And the easiest way to connect to the cluster is by making use of this connect button right here.
So this will give us the command to connect to the cluster using the cloud shell.
So let's click on that.
And on the lower half of the screen, the Google cloud Shell should open up.
And just going to increase it all the way to the top to make some space.
So this is the command that.
Will enable cattle to be able to talk to the DCA cluster.
So in Cloud Shell, you already have the coop cattle utility installed.
So all you need to do is run this command and to set up connectivity to the G.K cluster.
So it will set up the cube config and any other required configuration.
Once that is done, we are ready.
So we now clear the screen.
And if you run the cube, cuddle, get nodes command.
We can see that we have three worker nodes which are in ready state is running wishin one, not one,
one two, one four.
And it was set up about one to two minutes ago.
So our next task is to get the ammo files for deployments and services that we created earlier.
So to do that, we'll open up our GitHub repository where all these files have been committed.
So here we have the repository.
And within the its specifications directory, we have all the deployment and service definition files.
So let's first clone the repository onto the Google Cloud Shell.
So I'm going to run get clone now.
Pays the are.
That was a copy to the clipboard.
And let's run get clone command and paste the world to download the repository.
Now I'm going to see these into the example Wooding App Directory.
And in here I'm going to the specification directory.
And if I run, unless we see all the ammo definition files.
So.
Let's check the changes that we have made to the voting app and the result app services.
So we made a small change to the services because we are deploying these on the cloud environments.
Earlier, we discussed about a service type of load balancer where the native load balancer on the cloud
is deployed.
How?
When we create a service.
So in here we have changed the type of service to load balancer instead of node port.
And we have done the same for result app service as well.
So now let's start creating these objects.
So we will start with the call, create that command and we'll start with the voting deployment itself.
And then we will deploy the service for voting app.
Next, let's deploy the readies deployment, followed by the ready service.
Next, we will do the postgrads deployment, followed by the Postal Service.
And now we can do the worker app deployment.
And finally, let's create the deployment for the result app as well as the result service.
Now, you can also create all of these at once, too, by just specifying a wild card instead of each
file name.
You could just do a Kuka to create Dash F and then a dot to just create all of them at once.
So now we have created all the objects that are needed for this application to run.
So let's verify that by running the cube could all get deployment's Common Services Command again.
See that most of the objects have been created with the exception of the worker app, which is still
being deployed.
I can see that they are ready and we can also see that our load balancers do not have an external IP
yet.
So they are still in a pending state.
So at this stage, the Cabinet is service is in fact working with the native load balancer.
So it's sent a call to the native load balancer to provision a load balancer on on the Google cloud
platform.
So once the load balancer is provisioned and we get the load balancer externally, Warrell and IP,
it will be populated here.
So let's give it a couple of minutes and then check this command again.
Now we can see that all the five deployments are ready and have one out of one part which are in the
running states.
And we also have to load balancers with these two external eyepiece available.
So everything has been set up as needed.
And before we test the application, let's check the load balancer configuration.
So if we click on services and the ingress tab on the left, we can see that we have two services which
are of type cluster IP, which are the internal services of DBI for progress.
And the other one for red is.
And we have two front end services which are making use of the external load balancer.
And here are the external endpoints.
The and the you are all that we can use to access the application.
If you'd like to see more details, you can click on any of these.
And this should give you more details about the service in general, the load balancer, the internal
cluster i.p, the load balancer IP and the load balancer.
You are all.
And you can see that for all of them, the status is OK.
So now we can test the application.
So let's get the link here.
So we're going to open up a new tab in the browser and it will redirect us to the external load balance
right here.
And this is our voting application.
Similarly, let's open up the results app in a new tab as well.
And we will now cast a vote and we see that the result pages updated with the percentage of votes.
Let's try another vote.
And then we see that.
And this has been updated as well.
So that's a quick and short demo for deploying comandantes clusters on GCP.
And I will see you in the next one.