-: In this video, there's a couple odds and ends
I want to mention around Skaffold.
So you'll notice that down here
at the very bottom of the config file,
we added in this manifest section
and we provided a path
to just that client deployment yaml file.
So by adding in this yaml file right here,
anytime we start up Skaffold
with Skaffold Dev at our terminal,
Skaffold will automatically
try to apply that yaml config file
to our Kubernetes cluster.
Now here's the important part.
Anytime we close down Skaffold,
Skaffold will immediately try to delete the deployment
that we created with that file as well.
So take a look at this.
If I flip back over to my browser or see my terminal,
and I hit control+C,
we're going to automatically
see deployment apps client deployment deleted right here.
If I now attempt to get my pods,
I'll see that all of my client pods
have been deleted automatically.
So this is another feature of Skaffold
that's really nice.
Right now, anytime you do some local Kubernetes development,
if you decide to pause working on one project
and start working on another,
you might have a ton of different containers or pods
in the same name space
and it's kind of hard to tell which is which.
So by using Skaffold,
you can automatically set
startup one set of different pods
and then automatically close them all down
as soon as you stop Skaffold as well.
At present,
we are not having our server deployment being managed
or our worker deployment being managed by Skaffold.
So if you wanted to make sure
that those pods also started up
and got shut down automatically,
we could add them to that manifest section.
Let's do that right now.
So back over here, I can add in K8s
and we're going to go for our server deployment
and we can also do our K8s worker deployment as well.
You're not limited just
to having deployments being managed by Skaffold.
We can also add in services as well.
So if we wanted to make sure that we also, say,
shut down the server cluster IP service,
we can just add that as an additional entry.
So I can do server cluster IP service .yaml, like so.
And the same thing for,
let's just go ahead and be complete here,
I'll add in also my client cluster IP service
and our worker doesn't have one
so we'll just do just server and client.
All right, so I can now save this file,
flip back over to my terminal.
I can start everything up with a Skaffold Dev.
So we'll see that Skaffold
has automatically applied all those different config files.
Our React application's gonna start up,
and then at any point in time,
we can hit control+C
and we'll see that Skaffold's gonna shut down
all of our client pods,
all the server pods, and the worker pod as well.
So I'll do that right now.
I'll hit control+C,
that's going to delete all those pods.
And now if I get my pods, yep,
I will see that the server deployment,
while it's still listed,
it is being terminated along with the worker as well.
So if I run that again right now, yeah, there we go.
Now the server and the workers are completely gone.
Now there is, kind of,
one downside to this entire approach of adding in
all these different services or manifests
into this Skaffold file right here.
'Cause remember we're now saying
that as soon as we close down Skaffold,
we're going to essentially delete
all the things we have listed here.
So the downside to that
is that if you have anything persistent,
like maybe a database or a volume
that you want to keep around for development purposes
because maybe you've got a lot of test data loaded on there
or something like that,
do not add those things into your Skaffold file
because if you have any persistent data
in the form of volumes or pods or whatever else,
Skaffold is gonna delete that stuff
as soon as you close it down.
So I would recommend
not adding those things to your Skaffold file.
And you can actually see in my environment right here,
I actually have a Postgres deployment
that's been running for 110 days.
So that's for a very different project
that I've been working on for quite a while.
I don't want that deployment for Postgres
to be managed by Skaffold
'cause I have some persistent test data in there
and I don't want to have to be recreating that database
and reseeding that database with all that test data
every single time I decide to go back
and start using Skaffold on it again.
So in the case of all your different pods
for running React applications or APIs
or, kind of, these stateless services,
no problem adding them to the Skaffold file.
But if for anything related to data,
you might not want to add it in
because, like I said,
Skaffold is just going to very quickly delete it.
All right,
so now that we understand a lot more about Skaffold,
I wanna add in all of our different services or deployments
to this thing so that we can get some live updates
on our server, and our worker,
and all that good stuff as well.
So let's take a quick pause.
When we come back,
we'll just add in some more configuration
for artifacts for both the worker and the server.
So I'll see you in just a minute.