WEBVTT 00:00.860 --> 00:07.940 Okay, So the first environment variable we're going to handle is providing a MongoDB URI and we're 00:07.940 --> 00:15.290 going to take advantage of MongoDB Atlas as a managed service to run MongoDB for us and then we can 00:15.290 --> 00:20.240 connect to it in both our local and Gcloud Kubernetes cluster. 00:20.270 --> 00:26.270 The reason for this is because it's totally free to start out and we don't need to set up any complicated 00:26.270 --> 00:31.910 infrastructure, and Atlas makes it super easy to just get started with what we need out of the box. 00:31.910 --> 00:39.740 And they also provide auto scaling so that our MongoDB infrastructure will grow and scale as more load 00:39.770 --> 00:42.910 hits our system, which is a great feature to have. 00:42.920 --> 00:49.430 So make sure you head to Mongodb.com slash cloud, slash atlas slash register. 00:49.460 --> 00:51.830 Go ahead and sign up for Atlas. 00:51.860 --> 00:56.240 It's completely free to get up and running and we will get a MongoDB set up. 00:56.240 --> 01:01.080 So after you've created your account, you should see that you get a message to verify your email. 01:01.110 --> 01:02.940 Go ahead and verify your email. 01:02.940 --> 01:04.530 After email is verified. 01:04.530 --> 01:07.910 We'll go ahead and click continue to move on with the process. 01:07.920 --> 01:14.610 You can go ahead and complete out this quick form to tell them what kind of app we are building. 01:14.610 --> 01:19.560 You can just fill this out with whatever you'd like and we can set our preferred language to JavaScript 01:19.560 --> 01:20.100 here. 01:20.630 --> 01:25.790 Go ahead and click finish now we can go ahead and select the kind of database we want to deploy. 01:25.820 --> 01:31.790 You can see the three types here, a dedicated cluster, a serverless cluster that will auto scale based 01:31.790 --> 01:36.380 on our needs and a free cluster that uses a shared environment. 01:36.410 --> 01:40.100 We are going to choose the free environment so we can continue to build. 01:40.130 --> 01:44.180 You can always upgrade later on if you think you need more compute power. 01:44.210 --> 01:46.250 You can then choose any provider. 01:46.280 --> 01:50.600 I'll go ahead and use Google Cloud since we're already using it for the region. 01:50.600 --> 01:57.110 I'll go ahead and select the American region US Central to be close to where our Kubernetes cluster 01:57.110 --> 01:58.080 will be running. 01:58.100 --> 02:03.290 Feel free to change this however you like, to any region you want, and we can just continue calling 02:03.290 --> 02:05.450 this cluster sleeper here. 02:05.480 --> 02:06.890 Go ahead and click create. 02:06.920 --> 02:11.900 Next, you can see we're brought to a security Quickstart where we can determine our authentication 02:11.900 --> 02:12.550 method. 02:12.560 --> 02:16.430 We'll use a username and password and I'll use the default username. 02:16.430 --> 02:24.120 It's supplying of sleep or nest app and I will auto generate a secure password and click the Create 02:24.120 --> 02:24.990 user button. 02:24.990 --> 02:30.330 Make sure you take note of this username and password before you create the user and then you can see 02:30.330 --> 02:33.150 we are brought to where we would like to connect from. 02:33.150 --> 02:38.370 We are going to go ahead and click my local environment and then for the IP access list, we're going 02:38.370 --> 02:39.810 to go ahead and edit this. 02:39.810 --> 02:45.390 0.0.0.0 and click on description. 02:45.390 --> 02:51.870 We will enter all IPS because by default we're going to allow traffic on all IP addresses just to make 02:51.870 --> 02:54.120 our building this database easier. 02:54.120 --> 02:59.970 We are still locking down access with a username and password, so go ahead and click update entry and 02:59.970 --> 03:02.250 then we can click finish and close. 03:02.520 --> 03:08.330 I'll click on Go to Databases and you should see that our database is now up and running. 03:08.340 --> 03:12.450 Now out of the box, we're going to have a three node replica set here, which means we're going to 03:12.450 --> 03:16.140 have fault tolerance in this database set up all out of the box. 03:16.140 --> 03:18.300 And this was all super easy to set up. 03:18.690 --> 03:23.970 Okay, so now that we have our MongoDB connection string, we need a way to provide it to our underlying 03:23.970 --> 03:25.820 pods in a secure way. 03:25.830 --> 03:32.400 We don't want to paste our connection string directly in to a file that we can commit because that means 03:32.400 --> 03:38.580 we're going to be committing plain text secrets, meaning our MongoDB username and password, which 03:38.580 --> 03:40.020 is a bad practice. 03:40.020 --> 03:44.760 So Kubernetes offers a way around this using a concept known as a secret. 03:44.760 --> 03:50.040 So we're going to go ahead and create a secret which is just going to be inside of this cluster and 03:50.040 --> 03:52.770 it will be base 64 encoded. 03:52.770 --> 03:56.730 So let's go ahead and create the secret using our new connection string. 03:56.730 --> 04:03.930 We'll run kubectl, create secret generic, which will be the type of secret and we'll call it MongoDB. 04:04.140 --> 04:11.160 And then we're going to use dash dash from literal and set it equal to the key name we'll call connection 04:11.160 --> 04:15.870 String here and set that equal to our full connection string. 04:15.870 --> 04:22.320 So go ahead and paste our connection string in here you can see the username and password has been entered 04:22.320 --> 04:30.690 in and if you don't remember the password for your user, you can go back into Atlas Cloud, into database 04:30.690 --> 04:36.330 access, click on our user here and edit the password to generate a new one. 04:36.330 --> 04:38.490 So I'll go ahead and create this secret. 04:38.490 --> 04:47.070 And now if we run Kubectl get secrets, we can see we have this MongoDB secret and if we try to get 04:47.070 --> 04:56.120 it and run output yaml you can see that our connection string here has been base 64 encoded. 04:56.130 --> 04:56.520 Okay. 04:56.520 --> 05:02.130 So now that we have the mongodb secret defined with our connection string, let's go ahead and actually 05:02.130 --> 05:05.490 inject it as an environment variable into our deployments. 05:05.490 --> 05:11.040 So we'll start off with the reservations deployment here under the container section, I'm going to 05:11.040 --> 05:18.660 add a new ENV property here, and underneath that we'll add a name to provide the environment variable 05:18.660 --> 05:19.290 we want. 05:19.320 --> 05:23.490 Of course we know the environment variable we need is MongoDB URI. 05:23.520 --> 05:27.450 This is the environment variable name from our app module here. 05:27.450 --> 05:35.280 Next, we'll go ahead and specify value from here and then we'll provide a secret key ref. 05:35.280 --> 05:38.940 And now we can provide the name of the secret we want to inject. 05:38.940 --> 05:44.970 We know this is MongoDB, the one we just created, and then we provide the key inside of the secret. 05:44.970 --> 05:48.600 In this case, it's going to be connection string. 05:48.600 --> 05:55.980 Now we can run helm upgrade Sleeper to upgrade our helm deployment run get pods. 05:55.980 --> 06:02.820 And if we now look at the logs for reservation, we can see it's no longer complaining about the MongoDB 06:03.060 --> 06:12.180 URI and we can even describe the pod here to see that we are providing the MongoDB URI and you can see 06:12.210 --> 06:15.480 it's hidden here to the secret we've defined. 06:15.480 --> 06:19.740 Let's go ahead and copy this environment variable and provide it in. 06:19.790 --> 06:22.700 To the rest of our services that actually need it. 06:22.700 --> 06:27.950 So next, let's add the same environment variable to the auth deployment, which is the other service 06:27.950 --> 06:29.480 that needs MongoDB. 06:29.960 --> 06:31.700 I'll go ahead and paste this in. 06:31.700 --> 06:40.670 And now we can run helm upgrade one more time and if we run Kubectl get pods, we can see the auth pod 06:40.700 --> 06:43.580 is actually completely up and running now. 06:43.790 --> 06:49.400 And now if we run kubectl logs on the auth pod again we see the same thing. 06:49.400 --> 06:52.220 MongoDB is no longer being required. 06:52.220 --> 06:57.060 So we've set up MongoDB Atlas and provided it to the deployments that need it. 06:57.080 --> 07:01.070 Let's go ahead and finish setting up the rest of our environment variables.