Container Management With Podman Crash Course

1. Course Introduction: Hello and welcome to the container management with Pac-Man course. My name is Andre balance and I'm here to help you learn the benefits of containerization and also how to create and manage containers using the Pokemon container management tool, I would like to specify the board man is extremely similar to Docker. The knowledge gain here can be used when working with Docker also. Now let's start the course by telling you a bit about myself. I'm a Red Hat certified engineer and also a specialist in working with both containers and Kubernetes is my second area of expertise is InfoSec. I'm also CompTIA Security Plus 35 mile to CISOs certified. So now that you know a bit about me, see what we shall be covering within this course. Let's do a short overview of what we should be covering during this course. We shall learn about containers, their architecture, in their benefits afterwards, which we'll go into more practical areas. And we will discuss container registries. They are and how to configure them within pod man. Next, we will dive into managing Containers, where we shall see how to create containerized services. Now we can manage containers well, if we can also manage images. So that is what we shall do in the next module. Containers have by default ephemeral storage. So if we want our changes to persist beyond the death of a container, we have to understand how to allocate persistence storage to containers. And we will cover that in the fifth module. In the sixth seven module, we shall focus on Container Networking, where we will learn about port binding and network creation. As today, we will finish this course by learning how to create our own container images through the use of Docker files and working directories. Now that we have a pretty good overview of what we shall cover, Let's get started. 2. Containers Explained: Now with now our first module, we shall talk a bit about containers, what they are, and the benefits of containerization. We'll finish this module by setting up a lab environment where we can run all our practical exercises for the next modules. So without further ado, let's get started. Now let's look a bit at how containers function. Now software applications depend on system libraries, configuration files, or services the runtime environment provides. Additionally, the runtime environment for a software application is installed in an operating system that runs on either a physical host or a virtual machine, administrators install application dependencies on top of that operating system. The major drawback to traditional deployed software applications is that these dependencies are entangled with the Runtime Environment. An application might require older or newer versions of a supporting software and the software that is provided by the OS. That is where containers come in. Container is a set of one or more processes that are isolated from the rest of the system. Think of it like a physical shipping container. Shipping container is a standard way to package and ship. It is labeled loaded, unloaded, and transported from one location to another within a single box. Containers contents are isolated from the contents of other containers, so they do not affect each other. So they are in isolation and they function independently. So what are the characteristics of a container? Well, they run directly on the host operating system and share those resources with all containers on that system. They shared the host kernel. The kernel isolates the application processes from the rest of the system. They require a lot less resources than virtual machines, so they are quicker to start and deploy. And they include all dependencies such as system and programming dependencies and configuration settings. No matter where you will deploy them, they will behave the same. Now that we understand a bit about container architecture, let's look at some useful terms. Container is a process or a set of processes running an image with restrictions. Image is a bundle which contains all requirements to execute those processes or that process. A registry is a place where images can be stored and retrieved. Old man is the container management tool, which we use managed both images, containers, and the way they interact. Another popular alternative is Docker. And the pod is one or multiple containers, which represents a single application. So let's look a bit at the benefits of containerization. First, we have portability. An application container creates an executable software package abstracted away from the host OS. Hence, it is not dependent or tied to the OS in any way, making it portable and allowing it to run consistently and uniformly across any platform or cloud, then we have speed because there is no OS to boot. That also means that start time is very low. The nerves are also very efficient is the software running in a containerized environment shares the host machines OS kernel. Developers can share the app layers across containers. Additionally, containers have an inherently smaller capacity than virtual machines require minimal startup times, allowing developers to run more containers on the same compute capacity is one virtual machine. Consequently, this drives higher server efficiencies and reduce its associated server and licensing costs. And lastly, as stated previously, because there is no OS to both containers also have less overhead. We understand container architecture and the benefits of containerization. Set up the lab environment. First, we shall go over the prerequisites for setting the lab. Afterwards, we shall look at the commands we should run. Lastly, we will do a short demo to have our lab environment up and running. Now in terms of prerequisites, we need a host running Red Hat Enterprise Linux version eight or higher. Host has to be connected to the internet. So it needs an active Internet connection, which we will use to download both Birdman and also container images attached to our host. We need a self-support or developers description. So that means we need to create a developer account with Red Hat. Additionally, it is recommended we also have an account on a container repository where we shall get our images from, such as Docker or clay. But that is not mandatory. So now let's look at the commands which we will need to set up our lab environment. So it's not actually that complicated. There are only three commands that we have to run. First day Subscription Manager register, which will register our system using our Red Hat account and password. Afterwards we have Subscription Manager attached minus minus auto, which will attach the subscription to our host. And lastly, we will run the yum install container tools command to install the poor man container management tool from red heads repositories after we have successfully registered our host. So now let's put all of these commands into use and setup our lab environment within our short demo. First that we'll be using the Subscription Manager registered command to register my system with Red Hat. I will be putting in my Red Hat ID and also my password. Then I just have to wait a bit. As you can see, the output message is that the system has been registered and the system name is localhost dot local domain. I will be using the Subscription Manager attach command minus minus auto to attach my subscription to my host. This might take a bit of time, but after this is done, then I have access to read heads repositories can also see a pop-up message has appeared saying that the registration is successful and my status is subscribed asleep. I will be using the yum install container tools command to install the container management tool called Pac-Man from red heads repositories. You can see that it is successfully downloading and it is completed. Now. Congratulations. Now have a functioning, been running lab environment. 3. Container Registries: Previously we set up our lab environment. So now we can talk about container registries. We shall first do a theoretical overview of what container registries are. And then we shall be moving on to demo, where we will make our own custom container registry. So without further ado, let's get started. So what our container registries? Well, to put it simply, there are a repository of images. A container registry is a bank for storing and obtaining container images. A developer uploads container images to a container registry. You can then download those images from a registry to a local system to run and create containerized services based on those images. There are two types of registries, private or public. You might use a public registry or a private one which your organization controls the source of your container images matter, especially from the security side. In order to download images from most registries, you first need to have an account with those registries and you can login to that register using the old man container management tool, more specifically the pot man login command. Now, the default configuration file for container registries is taught in the slash ETC slash container slash registry.com file. Now, both man has the ability to run ruthless containers. That mean we can create a registry.com file in the home of the user dot config slash containers directory. This will take precedence over the general one present in slash, ETC slash container slash registries.com. Now within the container registry file, we have these registries search section. Within the registry search section, there is a list of searchable registry is configured. We also have the registries in secure section. These registries are not protected with TLS encryption. So now that we have a good theoretical overview of registries, Let's look at some practical and useful Pokemon commands for working with registries. First, we have the old man login command using the boat man login command, as we can see in the example, I will login to my registered.com using a username and password. Then we have the pod man info command will give us information about PODD man's configuration, including searchable registries. And lastly, we have the port man's search command, The point man search command. I can go through my registries and search for a specific keyword like HTTPD. As an example, PacMan search, HTTPD will search registries for any container image containing the HTTPD keyword. So without further ado, let's go now into the demo and put our learned knowledge into practice. First, I will use VIM to show you the slash, ETC slash container slash registered.com file. Here we have the unqualified search registries. These are the registries through which pod man searches. When I'm looking for an image, we have here the registry.CentOS.org, quiet.docker.io, etcetera. Now I will be quitting this particular document. I will create a new path using the MK D or Command. And my new path will be dot config slash containers. Now I will copy the slash ETC slash containers slash registered.com file into the dot config slash containers path. I will keep the same name, registry.com. Now, I will edit this particular file because I only want my pod man container management tool to search through registry.access.redhead.com. So I will delete all the registries which I would not like to use, such as Registry dots, CentOS.org, quiet.io and docker.io. Then I will save and exit this document. Now I will do a PubMed search command with the term HTTPD to test if my registries are okay. And we can clearly see that we have results here. Now, I will clear the screen and use the port man info command to get information about our Pac-Man configuration. And we can clearly see here that the searchable registries are only registry.access.com. So the only one I left within the dot config slash containers slash registries.com file. So our demo worked perfectly. Thank you very much and see you in the next module. 4. Managing Containers: Previously, we learned about container registries. Now within this module we will learn how to manage container using the pod man container management tool. This will be a highly practical module and we will end this module with the demo, putting all our learned knowledge into practice. So without further ado, let's get started. Now in terms of useful commands, we first have the port man pool command, specifying a registry and then image within that repository. This will download that image to the local host. Afterwards we have the Pokemon inspect command specifying a locally saved image. This will give us detailed information about that container image. Using the pod man images command, we can get a list of locally saved image and using the poor man RMI command specifying an image name, we can remove a locally saved image. Now before we go into running containers, let's do a short overview of the states in which a container can be found. Great, it means that our container is created but not started running means that a container is running with all of its processes. Stop means a container is stopped and it's waiting for a signal to start. Its processes are waiting for the same thing. Post means a container and its processes are paused while that means that all of its processes have been exited. Now let's look at some useful commands for running containers using the poor man container management tool with the podium and run command. We can run a command within a container. We can specify the name with the minus-minus name option. And at the end of the command, we specified the image on which that container is based by using the minus d option, which stands for detached, means that the container will be running in detached mode. That means that the container will run in the background until stopped. Using the pot man ps command, we can list all running containers using the pod man ps command with this minus a option, we can list all containers running or not. Using the pod man logs command. We can obtain loads from a name container, which might help us in troubleshooting possible issues associated with that container. I would like to specify that if we use the minus e option, we will declare environmental variables which are passed to that container. We deport man stop command specifying a container name. We can stop a running container with the Pac-Man start command. Again, specifying the container name. We can start a stopped container using the pod man RM command. We can remove a container specifying its name. With the Pac-Man cp command. We can copy files from the host to a container using the old man exec command specifying a container name, we can execute a command within a name container and using the pot man exec command with the minus IT options specifying slash bin slash bash, we can obtain a terminal within a name container. The minus i option will forward all input from the host to the container. And the minus d option will give us up pseudo terminal within that container. So now that we have a good overview of all important commands needed to run containers using the pod container management tool. Let's move into the demo. Now first, I will look for an HTTP D image using the pod man's search command. I will just scroll up a bit and within the description, I can see an Apache HTTP 2.4 server. I will copy the name of that image and I will clear the screen and use the Postman pull command to download it locally. As you can see, it is trying to pull the image from the registry, is getting the source signatures and it's copying the blobs as we speak. So let's just wait a bit. So the polling has been successful. Now to validate this, I'll be using the pod man images command and we can see that our image is present here. Next, I will use the port mapping spec command to get detailed information on this particular image. We can see a lot of information here. First, we can see the user under which this image runs, which is used at 1001. We can also see details on the exposed ports of the image, which are 8088443. A summary and a description of what this image is meant to do, the working directory of this image, and also details regarding the vendor of the image which is redhead Incorporated, and the version of the image which is 2.4. I will just clear the screen. Now. Now I will be using the port VLAN run command specifying the name of my Container through the minus-minus name option. And it will be called web app and the image on which to base it. And we can clearly see that the container started. It does give us some logs and errors, but it has functioned properly. I will just exit the screen. I will now use the boatman ps minus a command to list all containers. And we can clearly see our web app container, which was created 39 seconds ago. I will remove it using the poor man RM command specifying its name. Now, I will run the container again, but now in detached mode specified through the minus d option. I will maintain the same name web app, and it will be based on the same image. I will validate my work through the use of the pause band ps command, which will show us all running containers. And we can see that our container called Web App, which was created two seconds ago, is up and running. I will get detailed information on this container through the use of Pac-Man logs. And we can see some logs associated with our web app container. Now, let me just clear the screen. And now let's use the Pokemon stop command to stop with a web app container. We can validate our work through the use of the old man ps minus a command where we can check the status of the container and it switched from up to exited. I will start the container again by using the boatman start command. And as you can see, the status has changed again from exited to up. So now I would like to demonstrate the Pac-Man cp command. But before that, I will create a document called index.html with the content of helloworld using the echo command and output redirection, then I will use the port man cp command, specifying the index.html file which I have previously created. And I will be transferring it to the container called wet-bulb within the past slash var slash v, V, v slash HTML slash index.html. Now, I will enter the container using the boatman exec command with the minus IT options slash bin slash bash. As you can see, the batch has changed and by running a P S minus ox command, I can clearly see I'm no longer on my local host. I am within the container. I will change directory to the slash var slash VB slash HTML path. And here I can do a listing. Within that listing, we can clearly see the index.html file. And I will just read the contents of that file, which are exactly as specified. Hello World. We have successfully copied our file from within the local host to the container at these specified path. If I wanted to check the contents of that file without entering the container, I can do that by using the pod man exec command to run the cat command at these specified path. So now it's time to clean up after ourselves. First, I will list all containers with the pod man ps minus a command, and we can clearly see our web app container there. Then I will stop the container with the Pokemon stop web app command. Afterwards, I will remove the container with the port man RM command. Next, I will list all images present on my local host using the Pokemon images command, I will remove my existing image with the pot man RMI command. And I will again list all images with the Pokemon images command. And we can clearly see that we have no images. And by using the pod man ps minus a command, we can also clearly see that there are no more running containers at this point. So congratulations. You now have a basic understanding of how to manage containerized services using the port man container management tool. See you in the next module where we shall talk about managing container images. 5. Managing Images: In the previous module, we talked about container management. Now, let's look also at ways in which we can manage images within our environment. So without further ado, let's get started. Now, let's look at some essential commands for managing images within postmen. We previously saw poured man pool. Now using the port man poor command, we can save a container image locally from a repository. We can list all container images using the pot man images. And if we would like to remove a locally saved image, we can use the pod man RMI command specifying the image name. Now let's assume we would like to rename an image. We can do that by using the Pac-Man tag command, specifying the original image name and the new image name. We would like to give it. If we would like to upload a locally safe container image to a register, we can do that by using the Pac-Man push command. If we would like to get detailed information on a locally stored container image, as previously discussed, we can do that by using the pot man inspect command. Now let's assume we work within a container like an HTTP web server. And we modified our index.html file and we would like to create a new image based on that altered container. We can do that by using the pod men commit command in order to create an image from a running container. So now that we have an overview of all important commands for image management, let's go into the demo. First, I will use port man's search to find an adequate HTTPD image. I will scroll up within the results. And again, I will copy the first result, which is HTTP D24 RHEL seven. I would clear the screen and now I will use Pac-Man pool in order to download that image from the repository and save it locally. Now, let's just wait a bit for the pulling to be finalized. So now that the download is complete, I can use Pac-Man images in order to validate that the image has been successfully. And we can see it here. Now, I will use port man inspector to inspect the image. As you can see, Pokemon expect gives us detailed information on this particular image. We can see the user under which the image is running. We can see the exposed ports. You can see a summary of what the image is intended to do, a detailed description on that. Now, I would like to retract the image using the boatman tag command, specifying the original image name and the new tag which I will give it will be called my new tag version 2. I can build it by work by using the Pokemon images Command N. We can clearly see here localhost slash minute tag version 2. Now I will be using the port man run command container running in detached mode. The container will be called web app and it will be based on the image called minute tag version 2. As you can see, the container was successfully created. And now I will run the Pac-Man ps minus a command in order to validate that it is up and running. And what do you know it is functioning adequately? Next, I will open a terminal within the container using the pot man exact minus IT slash bin slash bash command. There I will do an echo test and redirect the output to the slash var slash slash HTML slash index.html file. Within that container, I will exit the container. I will run Pac-Man ps minus a. Again, we can see that it is up and running. And I will use the command called Pac-Man commit in order to create an image based on this altered container, pod men commit web app, my new image, version 1, we can see that the image was successfully created. I will stop the existing container called web map, and I will remove it using the poor man RM command. I will clear the screen. And now I will create a new container running in detached mode with the same name, but now based on the committed image which we created previously, the container has been successfully created and now I will be using the pot man exec command to run a cat command within the container to see if the file is present. Cat slash bars such v, V, v slash HTML slash index.html. And we can clearly see that the output is as expected South tests, so it worked perfectly. Now, I will be using the Pokemon stop command to stop my web app container. I will remove it using the pod man RM command. I will now be running the Pac-Man images command to list all images saved on my local file system. And I will remove each of them with the Pokemon RMI command. So proud man, RMI, minute image version 1, pot man, RMI, my new tag 2 and poor man RMI registry dot access, both Red Hat.com, we can validate that our systems, it is cleaned by running the pot man images command and department ps minus a command and there's nothing there left. Congratulations, you now have a basic understanding of how to manage container images using the Pac-Man container management tool. See you in the next module where we shall be talking about ephemeral and persistent storage. 6. Persistent Storage: Hello and welcome back. In this module, we shall talk about containers storage and learn how to mount persistent storage within containers. Because by default, containers have ephemeral storage. So that means that anything we've done within a container at the moment of destruction, it's gone. So let's get to it. So the storage the container uses is ephemeral. The ephemeral nature of containers storage means that its contents are lost after you remove the container by mounting a directory from the host inside the container, you are giving the container persistent storage. All changes and contents of the mounted directory will be written on the host file system. Thus, they will persist after the container has been destroyed or removed. Keep in mind that you must take into account file system permissions into consideration when mounting a persistent volume for the container to use. Now the Pokemon container management tool supports rootless containers if you are running the container as the user root of the host than the UID and GID will match those within the container. In a rootless container, they user has root access within the container because pod man creates the container within the users namespace, the root user of the container maps to the UID of the user within the host machine. Each user after within the container maps to a user within the 100 thousand range. So now let's look at some useful commands for mounting persistent storage within containers. With the Padma unshare cat slash proc slash slash UID map. We can see that UID mapping of users within the container. We deport man, unshare cat slash proc slash slash JD map. We can see that GID mapping. Now, if we would like to mount persistent storage within a container, we shall be using the pod man run command with the minus v option. The first command creates an HTTP web server where the content is obtained from the mounted directory slash web content on the host is mounted on the slash var slash www dot slash HTML path within the container. Adding an uppercase Z at the end of the path will also ensure that you are setting the correct SE Linux context. Now, let's get to the demo and make things a bit more practical. So let's start off this demo by first looking at the GID and UID mappings using the pod man unshare command. Pod man, unshare cat slash, proc slash, slash your ID map. And we can see the mappings here. And Birdman unshare cat slash proc slash cell size JID. And we can see the GID mappings here. So now that we have this, Let's create actually a new path. I'll create a directory called web content within the home of my user. Within this folder, I will echo IN mounted message and I will redirect the output to a file called index.html. I will now clear the screen and let's look at what images we have available using the Pac-Man images command. We have none. So I will use the pod man pull command in order to download an image of an HTTP server locally. And let's just wait a bit for the image to finish downloading. The image has finished downloading successfully. And we can use the pod man run command in order to create a container called Web App. It will be running in detached mode and I will be mounting the web content directory which I have previously created from my host to the slash var slash www slash HTML folder within the container, maintaining the SELinux correct contexts. By adding the uppercase Z at the end, I will bind the port through the minus p option. So port 8082 of the host will be bound to port 8080 of the container. And I will be using the image which I have previously downloaded. As we can see by using the pod man ps minus a command, the container is up and running and the port is bounded correctly. If I do a curl command on the local host through port 8082, we can see the message, I am Mountain. Now I will use the boatman exec command to get an N-terminal within the container and I will echo a new message. This message means I am modified and I will output the standard output, the file which we mounted within the container. So index.html. I will exit the container using the exit command, and now I will read the file from the mount points, so from web content. And we can see both values are mounted and I modified. If I use the curl command, we can see the same output. Now, I will stop the container and I will remove the container using the pod man RM command. And I will recreate it just to see the nature of persistent storage. So let's test this by running a curl command on the local host on port 8082. As you can see, the message has remained unchanged. That is because the storage of this particular container for that particular path is held on the local host. So even though the container was destroyed, what was written within the web content directory has remained persistent. Thank you very much and I'll see you in the next module where we shall be talking about port binding. 7. Port Binding: Hello and welcome back. In the previous module, we talked about the ephemeral storage and persistent storage, and we learned how to give containers persistent storage, so we don't lose anything when they are destroyed. Within this module, we shall be talking about port binding and how to bind the ports from the local host to the container spots to make them accessible from the outside as well. So let's get to it. What is container port binding? Well, connecting to a container means that clients must connect two ports of the host that will send traffic to the container sports or the containers exposed ports. We can map ports of the host to those accessible from inside the container, to make containers accessible from the outside as well, not just from the local host. Keep in mind that if you want to make them accessible from the outside as well, we also have to check firewall rules to make sure any traffic on those ports is permitted. So with this in mind, let's look at some essential commands in order to do container port binding. Now in order to bind a port from the local host to the container, we shall be using the pod man run command with the minus p option. Our first example creates a containerized HTTPD web server called web app, where all traffic from port 8082 of the host is passed onto port 8080 of the container. Keep in mind, the container must accept traffic on that port. That means it has to be exposed. And we can see that by using the pot man in spec command on the container image, by using the portmanteau port minus a command, we can see all port mappings. And by using the pod man port command specifying container name, we can see the port mapping for a name container. Don't forget to create a persistent firewall rule using the firewall CMD command in order to permit traffic on that port. So now that you have a good theoretical overview of what port mapping is and its function within Container Management. Let's go into the demo. First, I will be using the Pokemon images command to show that I have a locally saved HTTPD container image present. Then I will be using the port man run command in order to create a container called web app running and detached mode, which will forward all traffic from port 8082 from the host side to port 8080 on the container side. As we can see through the pod man ps minus a command, the container is up and running. Now I will use a proud man exec command with the minus i t option in order to get an active terminal within the container. Here, I will echo the message hello world, and I will redirect the output to the slash var slash www slash HTML slash index.html file. Then I will exit the container with the exit command. Now we will use the port man port minus a command to see all port mappings. And we can clearly see the traffic from the local host on port 8082 is redirected to port 8080 of the container. We can also see that by using the port man port command specifying the name web app. Now let's test this by using a curl command, and we shall call the local host on port 8082. And we can clearly see the helloworld message. So it worked perfectly. Now in order to make traffic accessible from outside the local host, I will also add a firewall rule in order to permit traffic on port 8082. It is asking me for administrative privileges. I will give them and it has been successful. So now our containerized Apache web server is accessible from both the local host and also outside the local host on port 8082. We can also see the port binding, even if we run a Pokemon ps minus a command, we can clearly see it here that traffic from the local host is redirected to port 8080 slash TCP on the container side. Now how do I know that I should do directly to port 8080 on the container side, this is where Pokemon inspect comes into play. We can inspect the locally safe container image and we shall be looking at the exposed ports. The exposed ports are actually what is accessible to the container. Where does it permit traffic from? So that's how I knew that port 8080 was where I should redirect the traffic from port 8082. Now all that's left is to clean up after ourselves, our stop the container web app with the man stop command. Then I will remove it with the Pokemon RM command. And lastly, I will remove the image with the Pokemon RMI command. Thank you very much and see you in the next module where we shall be talking about Container Networking. 8. Container Networking: Hello and welcome back. In the previous module, we talked a bit about port mapping and binding a host port to a containers exposed port. Now we shall go more in depth with Container Networking. We will see poor man's capacity to create networks and resolve names within those networks. So without further ado, let's get started. Now let's look at some essential commence for Container Networking. The important command here is both men network with the postman network create command. We can make a network specifying its gateway name and subnet. The poor man network inspect specifying a network name, we can obtain details on an existing network. We deport man network creates specifying a container name. We can connect the container to an existing network. We deport man network removed. We can remove an existing network and we deport man run command. We can add the minus minus network option and connect the container to a network upon creation. So now that we have a good overview of important commands related to Container Networking, let's go into the demo. Now to start this demo, I will use the port man images command to show you my locally saved HTTPD container image. Now I'll use the poor man's search command to search for a Red Hat Enterprise Linux eighth image. I have copied it and now I'll be using the post man Paul commands to download it locally. So let's just wait a bit for the download to be finished. Now I will be using the poor man network create command to create a network for my containers. The subnet will be specified through the minus minus subnet option, and it will be 192168 dot one dot 0 slash 24. And the gateway will be specified through the minus-minus gateway option, and it will be 192168 dot one, dot one. The name of my network will be my network. Now that the network has been successfully created, we can move on to creating my containerized services. First, I will use the Pac-Man run command to create a container called client running in detached mode, connected to my network through the minus-minus network option with persistent storage. And the base image behind this container will be the Red Hat Enterprise Linux eight base image. As you can see, the container has been successfully created and I will list or running containers with the Pokemon ps minus a option, and it is up and running. Then I'll create my second containerized service using the Pokemon run command. This will be an Apache web server called web server, running in detached mode, connected also to my network. It will use the register.access.com http D24 L7 image, which I have locally stored. This second container was also successfully created. We can see them both up and running. Now, I will use the pod man network ls command to see all our available networks. And we can clearly see my network here. And to get more detailed information on my network, I will use the postman network inspect command specifying the name of my network. And we can see here both the subnet and the gateway. So now that we have a good overview of both our network and our containers, let's see if everything works. I will use the port man exec command with the minus IT option to open a terminal within the web server container. Here I will use the echo command and redirect its output to the slash var slash www slash HTML slash index.html file. In order to create a personalized message. More specifically, hello, I will exit this container, and now I will enter the other container, the client container, again with the pot man exempt minus IT option to get a terminal within the client container which is running Red Hat Enterprise Linux eight. Here I will use the curl command to curl the web server on port 8080, which was the one exposed. And we can clearly see that the message is as expected. So congratulations, we created two containers. One running in a containerized Apache web server running Red Hat Enterprise Linux eight, we created a network between the two and we can see that they communicate and they also have named server resolution. Thank you very much and see you in the next and final module. 9. Creating Images: Welcome to the final module of our course. Here we shall learn how to build container images from files to help us create our own custom images and personalize them to our own needs. So without further ado, let's get started. First, we shall talk about the steps for building a container image. So Birdman can build images automatically by reading the steps from a Docker file, you might ask what is a Docker file? A Docker file is a text document that contains all the commands a user could call on to assemble an image. Now, Docker files also make it easy to both create new container images based on an existing one, like extending a rated Enterprise Linux container image width and HTTPD functionality. So let's move on and see how do we actually create a container image. Firstly, create a working directory which contains all the required files for building the container image. Then we create a Docker file. A Docker file is just a text document that contains all the commands a user could call on to assemble an image. And lastly, we use depots man build command. We use the Poll Man build command to create the image based on the docker file and other resources within the working directory. So now let's look at a sample Dockerfile and see our possibilities. Now here we have a simple Dockerfile. The from field indicates which Bates image is to be extended. The label field indicates what label will this container image have. The Rosenfield runs commands within the base image, the exposed field exposes ports from the container side. The EM field sets environmental variables within the container. The copy field copies from the working directory to the container. The user field sets the user under which the container is run as the add field is similar to the copy field. The entry point field says the command which the container starts with. And we can create the container by parsing this Docker file with the pod men build command. So let's put all this knowledge into practice by moving on to the demo. Now I will start this demo by listing the contents of my working directory. I have an index.html file which contains the message hello world, and a pre-made Docker file which I assembled previously. Let's look at it. So it extends the Red Hat Enterprise Linux seven image, the user under which the container is running as root. It runs a yum install minus y HTTPD. To install the HTTPD service, it exposes port 80 and it copies the index.html file from the working directory all over to the container slash var slash slash HTML slash index.html path. Now, I will use the port man build command to create my image. I am specifying the minus d option for tag, which will give mother my image, the name of my HTTPD image. Now, I will use the Pac-Man images command to see if the image was created. And we can see it here, localhost slash my HTTPD image. Now let's give it a test. I will use the pot man run command specifying that the container will run in detached mode. The name of my Container will be Web App. I will be forwarding port 8082 to port 80 of the container, and I will be using my own created image. The container seems to be up and running. The port forwarding seems to work. So let's do a curl on the local host on port 8082, and we can clearly see the hello world message. So the file was copied successfully. Let's enter the container with the Pac-Man exec minus i t options to open a terminal within the container. As you can see, the terminal was opened as root. So the user which I specify it in the Docker file is used and the file which we copied from the local host to the container is present. So the Docker file did as promised. We have a containerized Red Hat Enterprise Linux seven operating system running on HTTPD service. By finishing this demo, we have also finished our crash course into container management. I would like to thank you for your attendance and maybe we see each other in other future courses. Thank you very much.