This course covers a range of techniques to help you run your own containerized applications using Red Hat. Throughout this course, you will follow along with guided presentations from the Red Hat platform to get a first-hand understanding of how to run containers and manage your workflows using Red Hat.
Learning Objectives
- Learn the basics of setting up web servers and containers
- Understand how to find and manage containers
- Understand how to perform advanced container management
- Learn how to attach persistent storage to a container
- Learn how to manage containers as services
Intended Audience
This course is ideal for anyone who wants to learn how to run containers with Red Hat.
Prerequisites
To get the most out of this course, you should have a basic understanding of Red Hat and of how containers work.
Time to get our hands dirty, we are going to have a crack at the guided exercise which focuses on Performing Advanced Container Management. As always we need to get things kick-started by running the appropriate start script this activity is no different. So, from a terminal on your workstation virtual machine run the command lab containers-advanced start.
Make sure that you have your successes before continuing. So, let's have a look at the first unit of work. So, step 1 has us ssh as the user student to our container host of course that is servera and then from there guys what we are going to do is that we are going to authenticate to the registry located at registry.lab.example.com.
So, over here we simply say podman login -u specify the username and if you don't want to specify the password on the command line like I have, know this you will be prompted for the password in the event that you don't specify one which of course is the preferred approach.
Now what we are going to do next is that we are going to run a container. So, you could see over here that the command that we are using is podman run -d detached, we are going to give the container a name it is mydb and you could see that we have specified some environment variables. So, they are user1 is going to be the mysql user, the password for user1 is redhat, the database that we are creating is items and the MYSQL_ROOT_PASSWORD is redhat. What we are also doing is that we are taking port 3306 on the container host and we are forwarding that into the container on the same port and then you could see over here that we are referencing the image that we would like to use which is registry.lab.example.com/rhel8/mariadb and you could see the version string along with the tag.
So, guys looking at the output of podman ps right now what you can see is that we do indeed have a container that is running, you could see the container's id, the registry, you could see the command that is being run. You can see how long it's been up for and then very importantly below the ports column. You could see that we are forwarding port 3306 across all interfaces to port 3306 inside of the container and we did statically grant this a name and the name is mydb.
So, of course to test this out right now from the container host and again we are not going through the firewall. What we are doing over here is using the mysql command. So, we are connecting as user1, we are being prompted for the password which is redhat and we are connecting on port 3306 and the host that we are connecting to is 127.0.0.1. So, as you can see we have a prompt right now, we are connected to MariaDB and in this case over here guys we can use the command show databases. Don't forget that your commands terminate with a semicolon and if you forget to use the semicolon just enter a semicolon in on another line and it will terminate the command.
So, once we're satisfied what we can now do is that we could disconnect from that mysql shell and we could stop the container. So, use the command podman stop and now we specify the name of the container and all is well right now so, let's go and move on to step 5.
Now at step 5 what we are going to do is that we are going run another container. So, let's have a look at this right now, slightly differently what we are going to do is run the container we are going to give it the name myweb. We are going to ask for an interactive terminal inside of the container that is created. So, the image that we are using is from registry.lab.example.com/rhel8/httpd and you could see that we are starting that bash process. So, now we are connected to the container. So, what we are told to do right now is to run the command cat /etc/redhat-release. So, you could see that the output of that command tells us that this is based on Red Hat Enterprise Linux release 8.2. So, let's go and disconnect from that and what we are now going to be doing guys is that we are going to use the command podman -ps. Now do you notice something interesting?
Let's have a look at the output right now. So, podman ps -a tells us that we have some archived containers. So, these containers that we are running and that they've been subsequently stopped. So, let's have a look at why they stopped, was there some sort of error? So, let's have a look at the first one over here. The most recent one at the top is myweb. So, myweb was running, the command that we had run was /bin/bash it was created 28 seconds ago and the status is that it Exited with a return code of 0. 0 is good , 0 is good this is fantastic so, why did it exit?
Well what we didn't do is that we did not tell the container myweb to run detached. So, it was running in the foreground and we had started the /bin/bash process for that particular container.
So what happens is that the container is running in the foreground and when we detach, when we disconnect from that session like we did when I ran the exit command over here, what then happens is that it terminates the container, the container was running and now it's terminated because you left it, you didn't actually run it in detached mode.
So, for the next one over here, you could see that we also have the mydb database.
So, again you could see that below the STATUS column it exited with 0. So, let's go back over here what I did is that I ran the command podman stop so, the command stop or podman stop was executed against that database and it gracefully terminated. So, this explains why we have these archived containers right now and why they have a return code of 0.
So, the next thing that we're going to be doing right now is in another tab and on the same machine I am running the command podman run and we are going to create another container. It's going to be called mysecondweb rather. It is going to run detached and you could see the final argument of course is the image that we are using so, it creates the container.
Now, if we want to connect to that container we can make use of the podman exec command. So what we are doing is that we are saying, let's go ahead let's make a connection to mysecondweb and we are going to run the command uname -sr. So, guys of course this is returning the kernel, the kernel version this is going to be the kernel version of the container host. Your container doesn't actually have a kernel so, it's using the kernel of the host. So, you could see that the kernel version that we are using is Linux 4.18 and you can see the remainder of the string. Now something that is really cool is that over here I am using podman exec and the -l is a reference to the last container name and what this means is that you didn't have to copy and paste or type out the container name once again. So, just the case of podman exec conduct the transaction against the last container that was referenced and we are using the uptime command and once again you're looking at that thinking crikey! it's been up and running for all that time. No, it hasn't. This is a new container but the uptime is actually derived from the container host itself. So, what we are going to do next over here is that in another tab I am using podman run - - name, we are statically giving this container a name, it is myquickweb and note the - - rm. So, the - - rm says that we are going to delete this container as soon as it stops running, whether it errored out to whether it was running successfully as soon as this container stops running delete it. So, there's no archived container and then you could see that we are using the command or using the image httpd and we are passing the command cat/etc/redhat-release. So, what's going to happen over here is that it's going to start the container, it's going to run the command cat/etc/redhat-release. Here we have the output and immediately afterwards if you have a look at the output of podman ps -a and we do a grep for myquickweb it has no reference to that container because of course it has been deleted as a result of that - - rm option.
So, let's move on to steps 8 and 9. What we are now going to do is run the command podman ps -a and now you could see we have all these archived containers.
Well in fact you could see over here that we have 3 containers and you could see that the one is Up. It's been Up since 2 minutes ago that is mysecondweb and then you could see that we have two archived containers over there and that is the ones for myweb and mydb and they've Exited. So, what we are going to do right now is that we are going to run the command podman stop -a. So, the -a is a reference to all containers.
Then what we are going to do is run the command podman rm -a so, we are going to do this for all the containers again including the archived ones and then podman ps -a you could see that we don't have any containers right now including those archived containers.
So, once you're satisfied guys what you could do is use the log out or exit command disconnect from servera. All that we need to do right now is clean up our work and to do that we run the command lab containers-advanced finish and it does bring this guided exercise to an end.
I will see you in the next video where we will be talking about Managing Container Storage.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).