This section is about storing configuration. As software developers, we know it’s a good practice not to hard-code configuration variables in code. We keep them separate so that any changes in configuration do not require code changes. Examples of these variables can include non-sensitive information like environments (for example, dev, test, and prod) or sensitive information such as API keys and account IDs. Let’s look at our example from the previous section. We have two variables in the code that have been given default values. They are the hard-coded values “8080” and “Hello world!” They will be overwritten by the environment variables “process.env.PORT” and “process.env.MESSAGE”, if the environment variables are present. Let’s pass in the MESSSAGE value from a ConfigMap and overwrite the overwrite the “Hello world!” string. This string appears on the index page, as you can see in the screenshot. There are multiple ways to do this. Before we dive into how to create and tell our deployments about ConfigMaps, let’s look at what they are and what value they provide. ConfigMaps give us a way to provide configuration data to pods and deployments so we don't have to hard-code that data in the application code. You can also reuse these ConfigMaps and Secrets for multiple deployments, thereby decoupling the environment from the deployments themselves! Secrets work similarly to ConfigMaps but are meant for sensitive information. ConfigMaps can be created in a couple of different ways: •Using string literals •Using an existing properties or ”key”=“value” file •Providing a ConfigMap YAML descriptor file; both the first and second methods can help us create such a YAML file We'll go into each of these methods in detail in the next section. The deployment or pods can then consume a ConfigMap by using environment variables with the "configMapKeyRef" attribute or mounting a file using the volumes plugin. The ConfigMap and the Secret are applied to the pod or the deployment just before they are run. We can potentially supply the environment variable directly in the YAML file, as shown here. The MESSAGE variable can now be used in the JavaScript file as "process.env.MESSAGE". In fact, if you applied this deployment descriptor to our deployment and viewed the application, you would see the new message as shown here. That's great, but now the string “Hello from the config file” is hard-coded to our deployment in the descriptor file. Let’s change this situation by using a ConfigMap. The simplest way to provide a ConfigMap is to provide a key-value pair in the "create configmap" command. Next, you need to tell your deployment about this new variable and where to pick it up. You do that by adding an "env" section in the deployment descriptor, as shown here, and using the “valueFrom” attribute to point to the ConfigMap created in the first step. In this case, the deployment will look for a key called "MESSAGE" in the ConfigMap named “my-config”. You can list all the ConfigMaps in your cluster using the ”kubectl get configmaps” command, and describing the ConfigMap will give us the descriptor for the ConfigMap. You can see the "env" section from deployment descriptor on the right of the slide. Another way to add the "MESSAGE" variable in the ConfigMap is to use a file. This file will contain all our environment variables in the “key=value” format. This file is useful for adding a large number of variables at the same time instead of listing them on the command line. An example of this kind of file is shown here. It has the one "MESSAGE" key with the string “MESSAGE=hello from the my.properties file” as the value. We can now create the ConfigMap by using the “--from-file” flag. Notice that the deployment descriptor section also looks a little different. The key is now “my.properties” and everything inside the file will appear as subkeys in the environment variable. To use it in the server.js file, you would refer to it as “process.env.MESSAGE.MESSAGE”. If you give a directory to the “--from-file” flag, all files in the directory will be loaded into the Secret ConfigMap. You can also load the file under a specific key by using the “--from-file=key=filename” format. As with the first method, you can describe the deployment descriptor to get the YAML output as shown here. Again, we have listed the "env" section from the deployment descriptor on the right of the screen. Finally, if you already have a YAML file with the ConfigMap descriptor, you can simply apply that file. In our case, we have saved the output from ”kubectl get configmap” as a YAML file called “my-config.yaml”. As you can see from the first command, there is currently no ConfigMap. We can now apply the YAML file to our cluster. This will create our ConfigMap, as shown here. The application should work as before. Working with Secrets is similar to working with ConfigMaps. First, we create a Secret using a string literal. Next, we use the "get" command to see that the Secret was created. Finally, to prove that our Secret is actually a secret, we can use the "describe" command to see that the Secret is not printed out in plain text in the CLI. In fact, if we print out the Secret in YAML format using kubectl, you can see that the encoded value is printed out to the console. To use our Secret, let’s add another "env" to the deployment descriptor, as shown here. We can now use the key as usual in our application by referring to it as “process.env.API_CREDS”. I've changed the code to print out all environment variables in the Node.js file. You can see the printed Secret here. Another way to use the Secret key in our application is to use volume mounts. We first create the same Secret we had previously. Next in the descriptor YAML file, we need to have a volume for the Secret with a corresponding volume mount. Each container in the descriptor file will have its own volume mount but can share the volume itself. In this case, our "api-creds" Secret will be mounted as a file at "/etc/api/api-creds". The program that needs this Secret will have to read and process the file to extract the Secret. Congratulations! You now know how to provide configuration variables and sensitive secret information to your deployments. We can keep our code clean because we don't need to hard-code variables such as environment configuration, API keys, usernames, and passwords. The final video in this module will focus on using external services in your application and will make use of ConfigMaps and Secrets!