In this section we're going to get through our last set of boring config for the post deployment and
its associated cluster IPs service.
So I'm sure you don't need any clever or witty comments from me at this point I'm sure you just want
to get this stuff done so let's get to it.
I'm going to flip on over to my code editor inside of my case directory.
We'll do our post gresse deployment YAML file.
Now again this is going to be a file that's very much identical to the read is stuff that we just put
together and even the other different objects we had put together before that.
I still do not recommend that you ever do a copy paste of these config files just because it's so incredibly
easy to forget to update some specific property.
Far safer to just rewrite it.
But that's just my personal opinion.
All right.
So we'll do our API version of apps the one for our deployment this is going to be an object with a
type of deployment we'll set up our meta data if I can spell it correctly.
With the name of postscripts deployment and we'll set up our spec that's going to configure the deployment
itself.
So I again want to only have one replica running of my posts gresse container inside of it's given pod.
Just very much like our read this deployment that we just put together.
We technically can create postscripts in a sort of cluster of different instances that are going to
all work together to increase the availability and bandwidth of our database.
However again that's something it's kind of outside the realm of Kooper Nennius that we're talking about
right now.
So we're just going to focus on running a single replica as it stands.
After that we'll put down our selector.
We're going to say look for a label that is matching component postscripts then set up our pod template.
So we'll give it a meta data property with labels of component postscripts.
And then again I'm going to make sure they unindexed back to be on the same indentation level as metadata
will define our spec for all the different pods that get created by this deployment.
I'll say here is our list of containers.
I want to have a name of postscripts I want to use the image photographs.
And then finally we're going to set up the ports here as well.
So the default port with progress which we are using We're not going to reconfigure or anything like
that.
We'll set up a container port of 5 4 3 2.
Again default port for postscripts All right well it's good.
Now I remember very similarly to all the like read this and express API stuff that we had done previously
to get our Express and our worker Pod's up and working correctly or more specifically the containers
inside there.
They need to have that set of environment variables that are going to make sure that they can successfully
connect to this copy of postscripts.
So we do have to set up a little bit of environment variables not only inside of this file but inside
of the worker and server deployments as well.
We're going to take care of that in just a second.
But for right now I want to first put together the cluster IP service and then we'll come back and talk
about all these environment variables.
And this PVC thing and all that stuff.
Essentially I just wanted to get the boring parts out of the way here at the very start of these repetitive
config files and then go over to the more interesting stuff like the environment variables and the postscripts
persistent volume claim.
All right.
So that's our deployment.
We're going to also make inside of our directory the postscripts luster IP service that Yandle file.
And inside if you're completely identical to the postgresql one we just are skipping the red one we
just put together or do an API version of the one we are making a service I will have a Medhat data
name of post gresse cluster IP service and we'll give it a spec with that type of cluster IP.
And then finally to make sure that we're not finding we have two other properties to here.
But one of the two is going to be the selector where we'll tell this thing.
What set of Pod's it's going to look for.
And as usual look at component along with the name or the label that we had applied to it which was
postscripts as we can verify back inside of our template section over here inside the deployment.
All right so now the real last step for real this time around we're going to set up our ports.
We're going to say the default 4 5 4 3 2 to connect read us and we're not going to do any type of remapping
this time around as well.
Target port.
There we go.
All right.
So that looks like it's just about it.
Now let's take these two new configuration files that are going to apply them to cube Seitel as well.
And then we'll check out our different sets of in make sure that everything is running successfully
before we start to come back and take care of the postgresql persistent volume claim thing and some
environment variables as well.
So my Turnell still inside of my complex directory.
We'll do our cube Seitel apply Cate's.
Now we should see that we have the postscripts IP service and the postscripts deployment as well.
So just as before we'll do our get POD's.
And now one of these names is really long so it wants to kind of wrap the levels with the SO I CAN SEE
MY post gresse deployment right here.
The container is being created all do get pods again and I can now see that it is in fact up and running
or the post deployment.
And I'll make sure I do my get services as well.
And somewhere inside of your postscripts cluster IP service.
Very good.
And I got port 5 4 3 2.
All right.
So I think that we are pretty much all set.
So that's just about it on our very basic very simplistic config files for all the different deployments
and associated services.
So let's take a pause right here.
When we come back the next section we're going to talk about some additional work that we need to do
to make sure that the server can connect to Rattus and postscripts and to make sure that the worker
can't connect to read us as well.
And also let's not forget this little PVC thing down here.
OK.
So quick pause and I'll see you in just a minute.