Time to create our second workflow.
So this one is going to be all about taking all those different config files inside of right in front,
hey, it's directory and applying them to our cluster.
This config files gonna look really similar to the one we just put together.
In fact, it's even gonna be a little bit more straightforward.
Well, let's get right to it.
I'm going to first go and take a look at the deploy audio file that we just put together a moment ago.
I'm going to copy all the stuff we had put inside there just to save myself a little bit of time.
Like I said, it is going be very similar to this.
I'll then go back to my workflows directory inside of here, I'm going to create a new file and I want
to call it deploy dash manifests.
All those config files are technically called manifest, by the way.
So that's why we're calling it deploy manifests.
And then going to a paste in everything that we just copied.
Now we're going to make a couple of small changes inside of you.
So first off, I cannot change the name to deploy manifests.
I'm going to change paths to infra flash.
Star, star.
I'm then going to remove everything around building the image, logging into docker, pushing off to
Docker.
So those three steps right there.
I delete them.
So I should now only have a uses for dactyl.
The doctor will step right here where we get that context.
And then finally, where we are doing the rollout on the deployment.
So in this case, we do not want to do any rollouts of deployment or anything like that.
Instead, we want to apply all those config files we had placed into that Cades directory.
Up inside of your QVC, T.L., apply Dasch F in front, slash K eights like so.
And believe it or not, that should pretty much be it.
So we're going to apply all those config files to our cluster.
I'll then go down, commit to file.
And that should be at.
Now, as usual.
No, that's not really it.
It turns out there's one other thing that we need to be aware of.
I want to give you a very quick reminder back inside of our editor.
I cannot find my infra k its directory.
Inside there is the Ingress service file.
So we have put together this ingress configuration file.
And we said that whenever a user goes to a host of ticketing dot dev, we want to apply this set of
redirect rules and whatnot or routing rules to their request.
The key thing here is that we have a host of ticketing dot def.
Now we are about to deploy our application to the open Internet.
And when we do so, we're going to eventually purchase a domain name and pointed at our application.
When we do so, that domain name is probably going to be something different than ticketing dot dev.
As a matter of fact, I can guarantee you it's going to be different because I'm going to end up with
a different domain name than you are.
So this little property right here at this very singular property really needs to be different, depending
upon whether we are running our ingress service in our development cluster or on our production cluster.
Right now, if we just take all these config files and apply them to our cluster, we will create a
copy of Ingress and Genex.
But unfortunately, it's always going to be looking for a user to come to ticketing dot dev.
And if I go to ticketing dot dev on my local machine, it's always going to point to my local cluster,
never, ever to the diploid cluster.
So there are a couple of different ways we can solve this problem.
We can take a quick pause right here and then figure out how to solve it in just a moment.