1 00:00:01,150 --> 00:00:04,400 In the last video we built out our client image on our local machine. 2 00:00:04,420 --> 00:00:07,720 Now that this has been built I'm going to push it out to Docker Hub. 3 00:00:07,780 --> 00:00:09,570 I'm gonna do a docker push. 4 00:00:09,580 --> 00:00:11,650 Steven Greider slash client. 5 00:00:11,830 --> 00:00:17,640 Remember if you are using Cuban 80s on Google Cloud you do not have to run this command. 6 00:00:17,710 --> 00:00:20,670 So I gotta run that and let it do its thing while that's running. 7 00:00:20,680 --> 00:00:24,870 I go back over to my terminal where we're going to start to write out a pretty good amount of configuration. 8 00:00:25,110 --> 00:00:28,590 So we want to get our client running inside of our communities cluster. 9 00:00:28,590 --> 00:00:31,530 There are a couple of things we have to do to get that happening. 10 00:00:31,530 --> 00:00:36,210 First off we need to make sure that we create a new deployment config file inside of our case its directory. 11 00:00:36,210 --> 00:00:40,170 This deployment config file is going to be just about identical in nature to the one we already wrote 12 00:00:40,170 --> 00:00:45,760 out for our authentication deployment we're then going to make sure that we add a config entry to our 13 00:00:45,760 --> 00:00:49,680 scaffold e-mail file particularly inside this artifact section. 14 00:00:49,720 --> 00:00:54,280 Remember the artifact section is going to setup some code sinking to make sure that in time we make 15 00:00:54,280 --> 00:00:57,340 a change to some JavaScript files inside of our client directory. 16 00:00:57,340 --> 00:01:03,550 Those changes get sink into the pod that is running our client image and then finally we want to kill 17 00:01:03,550 --> 00:01:06,710 to access this next J application from inside our browser. 18 00:01:06,720 --> 00:01:11,160 So in other words we need to somehow make requests from outside of our cluster and get them correctly 19 00:01:11,160 --> 00:01:12,960 routed inside of it. 20 00:01:12,960 --> 00:01:15,550 You'll recall that we were using ingress engine X for that. 21 00:01:15,900 --> 00:01:19,440 So we've got the ingress SRB file inside of arcades directory. 22 00:01:19,440 --> 00:01:24,690 This is where we are listing out all of our config to specify routing rules inside the cluster for incoming 23 00:01:24,690 --> 00:01:26,690 requests from the outside world. 24 00:01:26,730 --> 00:01:28,460 So in total three things for us to do. 25 00:01:28,470 --> 00:01:29,880 Let's get started right away. 26 00:01:30,600 --> 00:01:34,980 I'll first begin by going to my k its directory inside there are going to make a new file called client 27 00:01:35,010 --> 00:01:37,680 dash double yellow again. 28 00:01:37,830 --> 00:01:42,420 The client config file or the client deployment file is gonna look just about identical in nature to 29 00:01:42,420 --> 00:01:43,750 the authentication one. 30 00:01:43,860 --> 00:01:48,120 Just everywhere we have the word off pretty much just gets changed over to client. 31 00:01:48,120 --> 00:01:49,850 So let's write this out very quickly. 32 00:01:49,980 --> 00:01:59,110 I'm gonna put in an API version of apps V1 a kind of deployment we'll put in a metadata section with 33 00:01:59,110 --> 00:02:05,710 the name of client dash devil I'll then put in a spec to describe exactly how this deployment is supposed 34 00:02:05,710 --> 00:02:12,310 to behave I'm gonna put in replicas of one because I only want to be running at one single pod or my 35 00:02:12,310 --> 00:02:15,130 next s application when we're in this kind of development environment. 36 00:02:16,390 --> 00:02:25,070 I'll then put in a selector with the match labels app client then on the same level of indentation as 37 00:02:25,070 --> 00:02:27,280 selector we'll put in the template. 38 00:02:27,280 --> 00:02:31,640 And remember this template section describes exactly how every pod that is created and managed by this 39 00:02:31,640 --> 00:02:36,200 deployment should behave it's going to put in a metadata here as well. 40 00:02:37,850 --> 00:02:45,230 With labels of app client remember this metadata section right here and the selector section right here 41 00:02:45,560 --> 00:02:51,310 is how the deployment is going to find the set of pods that is supposed to manage then on the same level 42 00:02:51,310 --> 00:02:52,990 of indentation as metadata. 43 00:02:53,020 --> 00:03:00,290 We'll put in a spec describe how every pod should behave we're gonna say that every pod is gonna have 44 00:03:00,290 --> 00:03:01,880 a container section. 45 00:03:02,030 --> 00:03:08,270 We only want to have one container and we're going to give it a name as simply client animals it the 46 00:03:08,270 --> 00:03:14,600 image that we wanted to run so in this case my dock ready slash client quick reminder if you are making 47 00:03:14,600 --> 00:03:19,370 use of Google Cloud for your communities cluster you are not going to put in this format of image right 48 00:03:19,370 --> 00:03:19,920 here. 49 00:03:19,940 --> 00:03:24,320 Instead you're gonna put in that kind of GC R dot Io or something like that. 50 00:03:24,470 --> 00:03:28,610 You can see the format of that or get a reminder of what the format looks like by going back over to 51 00:03:28,610 --> 00:03:31,880 your will see me on the dash depo file. 52 00:03:32,090 --> 00:03:35,040 So go back over there and you'll see the format that you are supposed to use. 53 00:03:35,170 --> 00:03:40,130 It's supposed to be something like GC short Io dot something slash and then your project I.D. and then 54 00:03:40,130 --> 00:03:45,040 the name of the actual part or image they trying to run OK. 55 00:03:45,060 --> 00:03:46,230 That is it for the deployment. 56 00:03:46,260 --> 00:03:52,260 But remember after the deployment we also need a service to allow requests inside the cluster to get 57 00:03:52,290 --> 00:03:53,670 access to this pod. 58 00:03:53,730 --> 00:03:58,910 You're gonna write out that service at the bottom of the file I'll put in a dash dash dash at the very 59 00:03:58,910 --> 00:04:02,290 bottom and we're gonna create our cluster I.P. service. 60 00:04:02,360 --> 00:04:11,140 We'll put in an API version of V1 a kind of service metadata with the name of client SRB 61 00:04:14,350 --> 00:04:16,350 and then our specs section. 62 00:04:16,590 --> 00:04:20,540 We're going to add in a selector of app client. 63 00:04:20,560 --> 00:04:24,540 And remember the selector right here is how the service is going to find the pods that it is supposed 64 00:04:24,540 --> 00:04:25,170 to govern. 65 00:04:25,170 --> 00:04:32,770 Requests to after selector will then specify the list of ports that we want to allow access to. 66 00:04:32,850 --> 00:04:33,730 We're gonna have one port. 67 00:04:33,870 --> 00:04:36,230 I'll give it a name of client remember the name here. 68 00:04:36,240 --> 00:04:38,640 Not super important on the actual port. 69 00:04:38,760 --> 00:04:46,620 It's really just for logging and reporting purposes our protocol will be DCP but the port of three thousand 70 00:04:46,680 --> 00:04:49,950 and a target port of three thousand. 71 00:04:49,950 --> 00:04:51,210 Why are we using three thousand here. 72 00:04:51,390 --> 00:04:56,160 Well as you just saw at your terminal a moment ago as we started up our next application in the development 73 00:04:56,160 --> 00:05:01,170 of armament directly on a machine you saw that next day us by default listens on port three thousand. 74 00:05:01,170 --> 00:05:02,550 So that's all you're putting out here. 75 00:05:03,740 --> 00:05:04,030 All right. 76 00:05:04,060 --> 00:05:09,190 Let's save this file now as soon as we save this file scaffold is going to detect that we've added a 77 00:05:09,190 --> 00:05:11,020 new config file to our kids directory. 78 00:05:11,620 --> 00:05:16,660 So if we go back over to the terminal window running scaffold we should see something it says aha found 79 00:05:16,660 --> 00:05:20,130 this thing and created some deployment and some service. 80 00:05:20,230 --> 00:05:27,070 Now just you know after you apply or after scaffold applies this file you might see an error a big red 81 00:05:27,070 --> 00:05:33,160 error something it says cannot find image your Docker I.D. blah blah blah if you see something like 82 00:05:33,160 --> 00:05:33,610 that. 83 00:05:33,670 --> 00:05:36,880 Chances are you have not finished pushing your image. 84 00:05:36,880 --> 00:05:40,270 The initial build that we just put together to Docker Hub. 85 00:05:40,270 --> 00:05:45,550 So if you get that really big error message all you have to do is stop scaffold with the controller 86 00:05:45,550 --> 00:05:52,810 see and then start it back up with scaffold depth and you'll want to do that after you have pushed the 87 00:05:52,810 --> 00:05:59,330 image successfully to Docker Hub and then after that we should see our off come back up and very shortly 88 00:05:59,330 --> 00:06:02,270 we should see some logs coming from the client as well 89 00:06:05,340 --> 00:06:08,160 so that gets at least the pod created. 90 00:06:08,160 --> 00:06:10,550 But there are still two other things we have to go through. 91 00:06:10,650 --> 00:06:14,940 Remember inside of our scaffold at the end of file we have to setup files sinking by listing out our 92 00:06:14,940 --> 00:06:22,400 client project as a build artifact so I'm going to just go ahead and copy the existing block here and 93 00:06:22,400 --> 00:06:30,520 paste it down and then going to fix our indentation I'll find the dash image and make sure it's on the 94 00:06:30,520 --> 00:06:37,880 same level of indentation as image above it all then go through this copy paste right here and update 95 00:06:37,970 --> 00:06:45,130 off to client I'll update the context to client and then the only other thing we have to change is the 96 00:06:45,130 --> 00:06:47,900 directory where the files set to attempt to sync. 97 00:06:48,200 --> 00:06:52,790 So remember on the scaffold project we're going to be trying to sync JavaScript files and in addition 98 00:06:52,790 --> 00:06:57,290 inside this client directory we do not have a s RC folder to watch. 99 00:06:57,500 --> 00:07:06,510 So we're gonna change SLC right here to star star flash star dot J.S. and we'll save that file 100 00:07:10,270 --> 00:07:11,500 very last step. 101 00:07:11,500 --> 00:07:16,840 Remember we need to update our ingress configuration so inside my KDE directory I'll find the ingress 102 00:07:16,840 --> 00:07:18,560 service config file. 103 00:07:18,730 --> 00:07:24,220 So we need to add in a new path that users can visit and have all requests that go to some particular 104 00:07:24,220 --> 00:07:32,910 path read it off to our client service I'm going to add in a new entry at the bottom here of path slash 105 00:07:33,300 --> 00:07:42,590 and then question mark parentheses dot star well then put in a back end but the service name of client 106 00:07:42,680 --> 00:07:51,190 SRB and a service port of three thousand as well now something really important to understand here we 107 00:07:51,200 --> 00:07:51,820 are listing out. 108 00:07:51,850 --> 00:07:54,590 And so this part's an array of different paths. 109 00:07:54,650 --> 00:08:00,100 Whenever a request comes into ingress engine X it's going to attempt to match the path of that incoming 110 00:08:00,100 --> 00:08:02,600 request to the parts we've lost out inside of here. 111 00:08:02,630 --> 00:08:09,130 In order that means that first the incoming request is going to attempt to be matched against that path 112 00:08:09,140 --> 00:08:09,940 right there. 113 00:08:09,940 --> 00:08:14,400 If it does not match that path it will then be attempted to be matched against this one. 114 00:08:14,650 --> 00:08:20,020 The one that we just had in in right here is essentially a catch all in just about any path request 115 00:08:20,020 --> 00:08:20,730 comes in. 116 00:08:20,920 --> 00:08:23,830 This little red X right here is always going to capture it. 117 00:08:23,830 --> 00:08:29,050 So we want to make sure that we always first list out our very particular API for our different services 118 00:08:29,440 --> 00:08:34,330 and then only if we do not capture a request against any different services do we wanted to eventually 119 00:08:34,330 --> 00:08:36,210 be forwarded on to the client service. 120 00:08:36,220 --> 00:08:40,390 There are always gonna make sure that we list out the client service at the very very bottom because 121 00:08:40,390 --> 00:08:45,550 if we listed at the top then any incoming request and always be matched against this one which is definitely 122 00:08:45,550 --> 00:08:47,250 not what we want. 123 00:08:47,480 --> 00:08:49,310 So going to save this file as well. 124 00:08:49,350 --> 00:08:55,400 And now finally after all that we should be able to go over to our terminal and in the window running 125 00:08:55,400 --> 00:08:56,170 scaffold. 126 00:08:56,360 --> 00:09:00,520 Hopefully you will now see some output from the client pod. 127 00:09:00,680 --> 00:09:02,410 Looks like I've got it right here. 128 00:09:02,480 --> 00:09:05,540 If you are seeing a error message of any sort. 129 00:09:05,540 --> 00:09:12,470 By far first thing you want to do is stop scaffold and start a backup after it looks like everything 130 00:09:12,470 --> 00:09:12,970 is running. 131 00:09:13,010 --> 00:09:15,270 Or even if you see a warning or something like that. 132 00:09:15,350 --> 00:09:21,140 Let's test this out very quickly to do so we should be able to go back over to our browser and remember 133 00:09:21,170 --> 00:09:25,040 how we access our development server or our carbonated cluster. 134 00:09:25,040 --> 00:09:33,090 We're going to go to ticketing not dev so if I go to ticketing dot dev I will see the next J.S. page 135 00:09:33,120 --> 00:09:35,040 up on the screen of landing page. 136 00:09:35,040 --> 00:09:35,920 Awesome. 137 00:09:35,970 --> 00:09:41,340 Remember if you get a security warning we just want to bypass that because it's chrome jumping in when 138 00:09:41,340 --> 00:09:42,630 we really don't want it to do. 139 00:09:42,660 --> 00:09:47,760 So you can either click on advance at the bottom and try to bypass the security warning chits or however 140 00:09:47,790 --> 00:09:49,740 there will not be a bypass link inside there. 141 00:09:49,740 --> 00:09:54,250 So to really bypass that screen you can type directly onto your keyboard. 142 00:09:54,300 --> 00:10:01,520 This is unsafe and it should bypass the HDD yes air so we can see our landing page and if we tried to 143 00:10:01,520 --> 00:10:08,040 go to slash the nana we should see the banana page as well. 144 00:10:08,120 --> 00:10:08,480 All right. 145 00:10:08,480 --> 00:10:09,890 So now we've got this all wired up. 146 00:10:10,010 --> 00:10:12,050 Quick pause right here and continue in just a minute.