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.
- 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
This course is ideal for anyone who wants to learn how to run containers with Red Hat.
To get the most out of this course, you should have a basic understanding of Red Hat and of how containers work.
The learning continues, right now we are going to have a look at Performing Advanced Container Management and you know what the best way to learn is by doing. So, let's go to my terminal and see what's going on there. So, first up I am running the command podman images because I want you to see that I don't have any images on my computer right now. So, let's go and get an image.
So, I am using the podman pull command we are pulling an image from registry.lab.example.com which is the registry in our classroom environment from the rhel8 account and it's called mariadb.
Now after a while it downloads the blobs and we have the image available, we can use this image right now. So, let's go and start a container. Containers are started from their running images.
So, now we are going to use the command podman run, we are going to run an image, I am not specifying a name. Now if you don't specify name one is going to be randomly generated for you and this could be hard for you to keep track of your containers. So, if you want to keep track of your containers more efficiently give it a name, however for my goal right now I don't need a name. I am using -d because I want the container not to run in the foreground but as a detached process and containers are started from images so, the final argument over there is the name of the image.
So, moving on I have run the command podman ps and you can see well, yeah! I don't have any containers running. So, what happened to the container that was started with the podman run command. So, guys there was obviously some sort of problem right! So, now we have to go do some troubleshooting. So, the command that I am going to run right now is podman ps -a so, the -a is all about the archive containers.
So, it's giving me information about those containers that are running right now and those that have been archived and you could see that once upon a time did have a container. It had the CONTAINER ID beginning with bravo bravo 4. It was started from the image and here we have the image and inside of that image the command that we attempted to run was run-mysqld and it was created 7 seconds ago and it wasn't around for very long but it did exit with the return code of 1 and as you could see the name of the container that was used is loving_ lumiere.
So, of course if you want to get more information about what went wrong we can have a look at the logs. So, podman logs and now you specify either the container id or the container's name. So, here we have a bit of output and it said right! you have to specify the following environment variables.
So, it says that in order for us to use this image we need values for the environment variables.
MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE or we can simply use MYSQL_ROOT_PASSWORD or we can use them all and then we have a bunch of other environment variables. Variables allow us to parameterize our containers that means that our container images don't have to be created in a static way. We don't have to sort of hard code the name of the database, the name of the user and then and the password for that user inside of the container image. So, it's been parameterized and this means that this image is very portable. I could give you this image and you could use it to start up your own containers. So, let's go and try and use it right now with the environment variables.
So, to pass the environment variables off to podman we use the command podman run -d and now you could see that we're using -e. So, every environment variable is prefixed with a -e.
So, here we have MYSQL_USER is dipsy, the MYSQL_PASSWORD is bongle and the MYSQL_DATABASE is tubbies. Finally guys, you can see that the MYSQL_ROOT_PASSWORD is niftyhat365 and we are going to be starting a container using the image and you could see the path to the image.
So, now if you have a look at the output of podman ps we now have output, we now have a container that is currently running. So, what this does right now is that it says we have a container, it begins with the id of echo 5 charlie, you can see the image that is being used, you can see the command and this container is running, it's running right now and it has the name of musing_blackburn.
So, how do we connect to it, well we know that mariadb typically runs on port 3306.
Conveniently, it's not a privileged port so, I don't have to be root in order to bind anything to this port but how do I connect to it right now, ah that's a bit of a problem isn't it? So, guys one of the cool things that we can do using podman and we don't have to be root to do this unless we are doing it for privileged ports and that is set up port forwarding. So, what I am going to do next is that because I want my users and my customers to be able to connect to that container, to the mariadb instance that's running inside of that container, I am going to set up port forwarding. So, what I have done over here in the meantime is that I have stopped the container because you know what, what's the use of having a database if no one can connect to it.
So, podman stop, I have specified the CONTAINER's ID then I wanted to delete it to conserve space. We don't need that anymore and now I am going to start up a brand new container with some additional options so, let's have a look at that. Guys I know that it's spanning two lines but it's one line.
So, podman run -d detach -p, now we are setting up port forwarding. So, port 3306 on my computer, on my servera computer is going to get forwarded to a container port 3306.
So, it's the same port number, so what I am doing over here guys is that this reference over here is a reference to the ports on the container host then we have a colon and then we have a reference to the port inside of the container and you could see the remainder of the options that we are using along with the image. So it's MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE and MYSQL_ROOT_PASSWORD. Those are the environment variables that are being passed to the mariadb image. Now if you have a look at the output of podman ps it looks kind of different doesn't it. So, if you have a look right now we have this I know that it's spanning multiple lines and it's wrapping.
So, we have ports over there and you could see that on my container host, on all interfaces we are taking port 3306 and we are forwarding it into the container at port 3306 as well. You can see that their name has been generated beautiful_merkle.
Now of course if I wanted to allow customers external to servera, to connect to this to connect to this instance, what do we need to do set up firewall rules right. Now that part is going to require privilege because if you are making use of host-based firewalling you're going to have to use the firewall cmd command as the root user to allow for traffic to come to port 3306.
So, in another tab what I am doing and coming from servera I am not going through the firewall but from servera what I am now going to do is use the mysql command. So, mysql -h we're connecting to 127.0.0.1, don't use localhost because that implies a socket-based connection, we are connecting as the user dipsy with the password bongle and we are connecting to, I know that I didn't have to specify it but I just want you guys to be aware that should you run mysql or mariadb on a different port you can use the -p capital P to specify the ports.
So, what you can see right now is that I have got a connection and this is a connection into the container itself. So, I have used the command SHOW DATABASES. So, it's not case sensitive, mysql commands are not case sensitive however they are terminated with a semicolon.
So, running the command SHOW DATABASES reveals the databases that we have and it includes the database that we had specified which is tubbies. So, I no longer have the need for this container.
What I could easily do right now is that I could stop it so, let's go and now work with it right now podman ps reveals that I do have the container running let's go and copy the container id and I am going to say podman stop, now this is something that is worthwhile knowing that if the container doesn't respond what we could also do is use the podman kill command. So, it does respond to kill signals so, what you could do is that if you wanted to specify an alternate signal you could say podman kill and you could use the - s option and you could specify the signal that you would like to send.
Once the container is stopped what I could also do is that I could restart it using the podman restart command; so what the command does is that it creates a new container with the same container id as the stop container and it will also reuse its state including the environment variables and port forwarding along with the file system as well.
If you want to get rid of that what you could do is of course use the command podman rm let's just go and free up some space and there we go.
So, now if you have a look at the output of podman ps -a, you'll see that I have got that one container that's still sticking around, that's the one that was errant so, let's get and get rid of that. So, it's already stopped. I don't have to stop it. So, let's go and use the command podman rm and we simply go and reference either the container's id or the container name.
So, guys it's no fair that I get to have all the fun right so, what I want you to do right now is move on to the next video and I will catch you there for the guided exercise.
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).