WEBVTT 00:06.850 --> 00:12.180 In this lecture we discuss how to work with configuration data in Kubernetes. 00:12.220 --> 00:17.050 In the previous lecture we saw how to define environment variables in it pod definition file. 00:17.770 --> 00:23.350 When you have a lot of pod definition files it will become difficult to manage the environment data 00:23.350 --> 00:26.110 stored within the query files. 00:26.110 --> 00:32.500 We can take this information out of the pod definition file and manage it centrally using Configuration 00:32.500 --> 00:39.920 Maps. ConfigMaps are used to pass configuration data in the form of key value pairs in Kubernetes. 00:40.150 --> 00:44.020 When it pod is created inject the config map into the pod. 00:44.110 --> 00:50.380 So the key value pairs that are available as environment variables for the application hosted inside 00:50.380 --> 00:52.330 the container in the pod. 00:52.690 --> 00:56.220 There are two phases involved in configuring ConfigMaps. 00:56.260 --> 01:05.070 First create the ConfigMaps and second Inject them into the POD. Just like any other Kubernetes object. 01:05.070 --> 01:08.330 There are two ways of creating a configmap. 01:08.580 --> 01:16.140 The imperative way - without using a ConfigMap definition file and the Declarative way by using a Config 01:16.140 --> 01:17.960 map definition file. 01:18.180 --> 01:24.240 If you do not wish to create a configmap definition, you could simply use the kubectl create 01:24.300 --> 01:29.040 configmap command and specify the required arguments. 01:29.040 --> 01:32.420 Let's take a look at that first with this method. 01:32.520 --> 01:39.120 you can directly specify the key value pairs in the command line. To create a configMap of the given 01:39.120 --> 01:43.720 values, run the kubectl create configmap command. 01:43.920 --> 01:51.360 The command is followed by the config name and the option –from-literal. The from literal option is 01:51.360 --> 01:55.560 used to specify the key value pairs in the command itself. 01:55.560 --> 02:03.090 In this example, we are creating a configmap by the name app-config, with a key value pair APP_COLOR 02:03.180 --> 02:04.800 equals blue. 02:04.980 --> 02:12.310 If you wish to add additional key value pairs simply specify the from literal options multiple times. 02:12.360 --> 02:17.760 However this will get complicated when you have too many configuration items. 02:17.760 --> 02:22.280 Another way to input configuration data is through a file. 02:22.290 --> 02:28.880 Use the from file option to specify a path to the file that contains the required data. 02:29.130 --> 02:36.650 The data from this file is read and stored under the name of the file let us now look at the declarative 02:36.650 --> 02:37.520 approach. 02:37.700 --> 02:42.470 For this we create a definition file just like how we did for the pod. 02:42.560 --> 02:50.330 The file has apiVersion, kind, metadata and instead of spec, here we have “data”. 02:50.330 --> 02:57.050 The apiVersion is v1, kind is ConfigMap. Under metadata specify the name of the config 02:57.050 --> 02:57.870 map. 02:58.070 --> 03:05.930 We will call it app-config. Under data add the configuration data in a key-value format. Run the kubectl 03:05.930 --> 03:13.010 create command and specify the configuration file name. So that creates the app-config config 03:13.040 --> 03:15.630 map with the values we specified. 03:15.980 --> 03:22.690 You can create as many configmaps as you need in the same way for various different purposes. 03:22.700 --> 03:28.920 Here I have one for my application, other for mysql and another one for redis. 03:29.120 --> 03:36.260 So it is important to name the config maps appropriately as you will be using these names later while 03:36.260 --> 03:44.120 associating it with PODs. To view the configmaps, run the kubectl get configmaps command. This lists 03:44.210 --> 03:49.930 the newly created configmap named app-config. The describe configmaps command 03:49.940 --> 03:58.440 List the configuration data as well under the data section now that we have the config map created let 03:58.440 --> 04:07.030 us proceed with step 2 configuring it with a pod here I have a simple pod definition file that runs 04:07.060 --> 04:14.710 my simple web application to inject an environment variable add a new property to the container called 04:14.860 --> 04:23.620 envFrom. The envFrom property is a list, so we can pass as many environment variables as required. Each 04:23.680 --> 04:30.490 item in the list corresponds to a configMap item. Specify the name of the configmap we created earlier. 04:31.150 --> 04:38.470 This is how we inject a specific configmap from the ones we created before. Creating the pod definition 04:38.470 --> 04:48.290 file now creates a web application with a blue background. What we just saw was using configMaps to inject 04:48.310 --> 04:50.160 environment variables. 04:50.160 --> 04:56.970 There are other ways to inject configuration data into pods you can inject it as a single environment 04:56.970 --> 05:02.820 variable or you can inject the whole the data as files in a volume. 05:03.000 --> 05:08.880 We will look at some of these options in the coding exercises that accompany this lecture. 05:08.910 --> 05:15.900 So head over to the coding exercises section and practice viewing configuring and troubleshooting environment 05:15.900 --> 05:18.930 variables on a live Kubernetes environment.