Our digital ocean clutter is up and running.
We can connect to it.
And now it's time to start to deploy our application to it.
Let me show you a diagram very quickly that's going to outline how we are going to use a GitHub action
at workflow to automatically deploy all of our different services to this running cluster.
OK.
So the first time we look at this diagram is give me a little bit confusing.
So let me walk you through it.
Each of these vertical series right here.
So we've got one vertical series right there.
Another one right there.
And so on.
Represents a different workflow file that we're going to put together, essentially a separate GitHub
action.
So in total, we're going to have about seven different workflow files.
In each of these different workflow files, we are going to have a little bit of configuration that's
going to run any time that we merge a pull request into the master branch.
Whenever we emerge a player request into the master branch, we're going to inspect each of our different
services.
So the auth service, client expiration and so on.
And if anything changed inside of that service or specifically inside of our off folder, client folder,
expiration folder and so on.
Then we're going to go through the series of steps that you see on the right hand side.
It's a long story short, just to repeat that one more time, because this is a confusing diagram every
time that we merge a policy question to the master branch.
We're going to see if anything changed inside of that auth directory.
And if it did, we're going to go through this series of steps.
So that series of steps, we're going to first take everything inside that auto directory and build
a new image out of it.
So that's a normal docker image similar to how we've done it many, many times in the past.
We're then going to take that image and push it off to Docker Hub.
After that, we're going to reach out to our running cluster.
So our cluster on digital ocean and we're going to update our deployment or the off service and we're
going to tell that deployment to use the newest version of the off image that is available.
The one that we had just pushed off to Docker Hub.
So that is it for each of our individual six services.
The actual workflow files that they get, hub action files, are going to be almost identical in nature.
The reason we are creating all these workflow files separately is just so we can make sure that we do
not rebuild and deploy images if nothing has changed inside of a given service.
In addition, this is also going to make it really easy for us to change the building process for a
particular service.
If we need to at some point time, for example, we might decide to rewrite the payment service using
a different programming language at some point.
And so we would want to make sure that we can very easily customize how that payment service gets built.
At some point, and maybe we need to push it off to a different provider.
Who knows?
We can do that very easily.
By creating a separate workflow for each of our different services.
Maybe beyond each of our individual services, remember?
We also have that set of Cuban Eddys config files, which is where we create all of our different actual
services, where we define our ingress service.
That's where we also define all the different deployments themselves.
So as an additional workflow, in addition to all these other six that we're going to put together,
we're gonna have one other workflow that is always going to be executed at all times.
We're going to make sure that we reach in to that in Fred directory.
And we're going to apply all the Yamal files inside there to our cluster.
Remember that the infra directory.
Right here is where all of our communities can pick Byles live.
So if we make any change, these can take files.
We're just going to reapply them to our cluster.
That's it.
That's the general plan.
So in total, we're going have to create.
Well, seven different config files.
Now, we also thought you were really only good to great, too, at the end of the day, really just
going to create the auth one and then pretty much copy paste it or client expiration and so on.
And the only other one that we really have to write from scratch is infra.
So although we do have to create several different files, we really only have to create two from scratch.
And then from there on, it will really just be a job of copy paste.
It's now that we understand the plan, because here we can start to implement this in just a moment.