ch 13 Using ConfigMaps as Volumes

แชร์
ฝัง
  • เผยแพร่เมื่อ 10 ก.ค. 2024
  • Hi, in this video, we demonstrate how to use a ConfigMap to inject custom configuration data inside a container.
    The custom configuration data is basically an index.html file.
    We want to customize a web server.
    So let's see...
    ...what does the custom file look like?
    So the custom file is a much simplified index.html.
    It will basically display "Welcome to GREEN App!" on a green background.
    So I want this file to become the new index.html of our nginx web server that will run inside a cluster through the help of a pod managed by a deployment operator.
    So let's begin by creating the ConfigMap resource.
    So the configmap resource can be created from file, and we will provide the path to the custom index.html file as an option.
    And the configmap will be named green-web-cm, green web ConfigMap.
    So it has been created.
    Let's validate that the ConfigMap is there with the 'kubectl get cm'.
    The abbreviated form for ConfigMaps.
    And then we can describe the green-web-cm, the green web ConfigMap, and it will display under its data section the content of the HTML file that we have just used as the source of the ConfigMap.
    So once this is created, let's take a quick look at the deployment definition that will use this ConfigMap.
    So deployment is called web green.
    It is a much simpler deployment than the one we have seen earlier with the volume mount and the two containers, the "debian" and the "nginx" containers.
    This is green-web.
    So we have label and the name as green-web for the deployment.
    The selectors are again on green-web.
    And the template, the pod template only defines...
    ...one...
    ...one simple volume, and the volume uses the configMap plugin.
    So from the green-web-cm, we are actually creating a volume and then this volume will be mounted inside the single container that is specified under the pod spec.
    It is an "nginx" container, exposes port 80, and its volume mount will mount the web-config that comes from the ConfigMap under the /usr/share/nginx/html, which is the home directory of nginx's index.html file.
    So basically overriding the default file with the custom one injected through the ConfigMap.
    So let's create this deployment.
    So exit from here, quit, and now we are going to run the 'kubectl apply' command.
    Very simple to create the deployment, deployment has been created.
    By now, we know that we need to expose this deployment as well.
    Since the web server is already exposing port 80, all we need to do is specify the NodePort type service so we can visualize this in our browser.
    Then with the help of the 'minikube service list' command, we are going to list the services of the cluster but we are mostly interested in the URL of our NodePort type service.
    So from the command line, I could simply just run curl...
    ...maybe in a silent node because we don't want too much output.
    Let's paste this and then maybe pipe it through head and only display maybe the first four lines of the output.
    Okay, so every time I would curl, I would get the "Welcome to GREEN App!" displayed.
    Then obviously this is not very appealing.
    So what if we right-click on this URL, open link and then here we are in the browser, we have the "Welcome to GREEN App!" on a green background displayed.
    Now in a similar fashion, I would invite you to create a blue-app starting with an HTML index file...
    ...that would give you the specifics for the green-app...
    ...for the blue-app, I'm sorry.
    So this would be... you can use this as a sample.
    So all you have to do is just replace "green" with "blue" and it's that simple, really.
    You don't really need to be an expert in HTML.
    But save that under a new directory, maybe under blue directory as index.html.
    So once you have this file created, then out of this file you will create a ConfigMap.
    And then with the ConfigMap created then you will create a deployment.
    And a deployment... for the deployment you can use the model of our deployment.
    Let's take another quick look at that YAML definition file.
    So there's a very simple deployment.
    It has a label and a name under its metadata.
    Its spec is asking for a single replica and it specifies the selector.
    The green-web, well for blue it should be blue, and then the name should be blue, the label should be blue.
    And the strategy can remain blank.
    We don't have to define anything under template.
    The metadata needs to be updated.
    The label has to reflect the blue-web instead of green.
    And then the spec of the template needs to define the nginx, well the "nginx" container, and the web-config volume.
    But now the configMap will have a different name because we're creating it from a blue index.
    Now it will have the name blue-web-cm.
    The container nginx, port 80.
    And the volume mount of the container the same under /nginx/html.
    And the name can be left the same, web-config.
    So all we have to update is basically wherever we see green, we need to update that word with blue, it's that simple.
    Not a very complex task.

ความคิดเห็น •