[MUSIC] >> Hi, I'm Brendan Burns from Microsoft Azure, and we're going to talk about Kubernetes and configuration management.
When you think about configuration management, it's helpful to think about the problem that we're trying to solve.
When people first defined their pod and their container image, I think they often think well you know what, configuration can just be a part of the container image that I deploy.
But I think it's useful to think of the pod in the container image just like you would think of a function in a programming language.
Just like a function has parameters, you should think about a configuration for your application providing the parameters for your container image.
The reason for this is because of you want to create images that are general purpose.
They're useful in a variety of scenarios.
You may have different configurations in Canary environment where you're testing a particular configuration.
As you deploy to a worldwide configuration, you may want to parameterize your image with different languages, different images, all sorts of different small variations that you want while still using the same build, the same continuous delivery to define the image itself.
Fortunately in Kubernetes, there's a resource to represent this, and it's known as a ConfigMap.
A ConfigMap resource is a collection of key value pairs.
Those key value pairs can be something like a language, of EN_US.
So really just string string pairs, or they might also be something like a properties file in a traditional Java application, and the configuration value is actually the value of the file itself.
Now when you think about consuming this ConfigMap after it's been created inside of the Kubernetes API server, you can mount that ConfigMap as a volume into the pod itself.
Then once you create the volume associated with the pod you can then mount it into your container at a particular directory.
Depending on whether your ConfigMap is representing a single file or a collection of files, you either map it into a directory where each file becomes a sub file within that directory or it maps to a specific file in the context of the container.
Now, that's useful for configuration that is a file.
But what about configuration that is just a simple key-value pair.
Well, in that context you can also use environment variables.
Such that, and point those environment variables at your configuration map such that in your code you can say something like get elve and gain access to the configuration that you stored it into the ConfigMap.
Now the question that you should have is well what about something like a password? It might seem like a password is a configuration value as well.
But in fact, because passwords and other kinds of secrets are well, conceptually configuration, something that you want to be very careful about the management of and possibly use different access control in different sorts of settings.
Kubernetes actually treats config and secrets as separate objects even though they look and operate largely the same.
So when you're thinking about configuring your secrets you should use a Kubernetes secret instead of a Config Map for storing certificates, database, passwords, and all that stuff.
Now, the next interesting question is, how should you think about rolling out configuration in Kubernetes? It's often been said that configuration is code and it really should be treated as such.
You can easily have an application, that it's totally healthy, provide it with a new configuration, and cause that application to crash.
So in that context you want to be able to perform a roll out of your configuration just like you would perform a roll out of your application.
Fortunately, you can do this.
So you might have your application V1 with ConfigMap, and you have this defined in a deployment.
Well, if you keep the container image the same but you change the configuration map that's mapped as a volume into your container.
So let's say we change this instead to be Config two.
Well, it turns out that actually the deployment engine is going to notice that change and actually perform the same kind of rolling update that it does if you change the container image.
So in particular, if in the template spec for your deployment, you change the configuration to point to a new configuration object and these are configuration map resources, Cfg1 and Cfg2.
You've already created, so you have two different ConfigMap resources.
If you change the ConfigMap in the specification of your application, Kubernetes will actually start doing the same kind of rolling upgrade.
Eventually, you'll get to a world assuming everything happens correctly, where you've rolled out that new configuration with proper health testing, with all of the things that you would associate with an image roll out.
So the deployment API actually makes it very easy for you to manage the deployment of new configurations just like you manage the deployment of new images.
You should absolutely run them through the same kind of continuous validation and testing that you do with an image prior to even getting to the roll-out stage in the context of Kubernetes.
The final piece that you should be thinking about is templating.
So when you think about configuration, it's great to create these ConfigMaps, but in many cases you want the configuration to be largely the same but a little bit different depending on your environment.
So you might have a high level template and two configurations East and West that extend from that template and add some extra value.
When you're thinking about templating and configuration management in that context, a tool-like helm can provide a lot of templating capabilities and you can find out more information that helm.sh.
Hope that gives you an early intro into why you might be motivated to separate your application and configuration and how you can use ConfigMaps to represent configuration information, bring them into your containers and then ultimately roll them out to your applications.
[MUSIC]