As I've repeated several times now we're going to create a cluster IP service to allow access to our
post pod and one for event buzz as well.
So let's get to it.
Back and said my editor we can either create a new file to house these two services or I should say
one file for each service.
Or alternatively we can just write out the configuration for each cluster IP service directly into the
appropriate deployment file.
Personally I kind of like to co locate my deployment configuration and the IP service that maps up to
it.
And the reason for that is that we usually end up with a one to one mapping between cluster IP services
and the deployments that they are allowing access to.
So it kind of makes sense in my mind to collect all this stuff but you will find that other people like
to create a separate file for every single service or I should say every single object inside their
communities cluster.
So it's really up to you but at least in this course we're going to co-located all this configuration.
That means that inside of my event bus deployment file I'm gonna go down to the very bottom of the file
and we're going to write out the configuration to create this new cluster I.P. service right here to
create multiple objects inside of a single e-mail file.
We add on dash dash dash and then just go down to the next line.
So we will write out our configuration for the cluster IP service starting right here the configuration
we're going to write out is going to look just about identical to what we wrote out already inside the
post SRB file so let's get to it to create this cluster I.P. service will say API version 1 kind is
going to be service metadata is going to have a name of event plus SRB
I'll then create a spec inside of here we're going to once again setup a selector that's going to tell
the service what pods it is going to allow access to.
So in this case we want to use or we want to make sure that we tell the service to direct any incoming
traffic to the pod with a label of event app event dash bus that's going to be the label that we're
going to look for right there so we will provide that label to the selector field the app event Dash
Plus next step we can optionally specify a type of cluster IP.
The reason I say optionally is that if we do not specify a type for the service companies will default
to creating a cluster IP service for us so we can delete that altogether if we want to and we will just
go ahead and get a cluster IP service it is 100 percent up to you whether or not you want to write out
the full type or just rely upon the default behavior for me personally I think I'll go at the default
so I'm not going to include it.
And then finally we'll set up our ports as a quick reminder the event bus application itself.
If we open up its implementation specifically the index dot J as file this thing is listening to incoming
traffic on port four thousand five.
So we just need to make sure that we specify a port of four thousand five in the port configuration.
It's all but a dash in say name event.
Bus protocol of DCP then a port of four thousand and five and a target port of four thousand and five.
Like so an attribute I'm going to say this file and then going to go back over to my terminal and I'll
try to apply it right away I'm still inside of my k aides directory and I'll do a cube Seitel apply
event bus depot dot yellow once I run that command you'll see that Cuban net now understands that there
are two objects that we are defining inside that config file the event plus deployment has been unchanged
so although we tried to apply some changes we haven't actually or apply that same file again we haven't
actually made any changes to the deployment but Cuban eddies did realize that the event by service was
brand new and so it listed it as being created which Nashville to do a cube Seitel get services and
see our event bus service right there and it should have a type of cluster IP awesome now looks pretty
good now we're going to repeat that same process where our posts as well before we do so however you'll
recall that we've already created a note port right here and it's already using this name of post SRB.
So we just need to be aware that once we create a second service that's going to direct to this post
pod right here.
Once we create this second cluster IP in addition to the node ports that already points to it we just
need to make sure that we use some slightly different names.
Otherwise Cuban that is is going to think that we want to try to change the existing node port service
into a cluster IP.
I mean to say is we just need to use a different name than the one that we already used inside this
post SRB file going to open up the post deployment file and once again we're gonna write out the cluster
IP service that's going to allow access to the pod created for this deployment down here at the very
bottom it's all put in dash dash dash and then rather than writing all this stuff out again let's just
do some copy paste I'm going to go back over to the event event plus deployment file and copy everything
down here go down to a post dash deployment and paste it all in
and then finally I'll change the name of this cluster I.P. service to those luster IP dash SRB again
that's just going to distinguish between the existing post service we've already created then make sure
that I update the selector right here to post and I'll update the name of the port to post as well finally
recall that we have some different ports where our post application if we open up the posts indexed
not just file this thing lists traffic on Port 4000 we just have to make sure that we update that port
and that should be at I'll save this file and once again we'll go over to our terminal and we'll do
a cube CTO apply those double dot e-mail Oh don't forget the F on their dash F so we've now created
that cluster IP service that points over it suppose and if I do a cube CDL get services e up there it
is right there all right.
Once again I want to repeat that I know a lot of this stuff seems tedious right now and as soon as you
get through this one time of doing all this stuff by hand.
A lot of it is going to get way way easier.
And again I want to also repeat that I'm sure a lot of this Cuban neti stuff seems kind of pointless
right now.
You might be saying there's no way all this trouble is worth it but trust me once we get a really good
Cuban that flow going adding in new stuff or new components to our micros services application is going
to be an absolute breeze.
So I can't repeat enough.
It's really just some onetime pain to learn this stuff and we're almost done.
Anyhow OK so this is looking pretty good.
We have now gone through building image we push the image we create a deployment we create the cluster
IP services now we just have to do one last little step to wire the stuff up and then our two event
bus and posts or these two pods will yield to communicate with each other very easily.
So a quick pause and I'll see you in just a minute.