Managing Containers as Services Demo
Introduction & Overview
Running a Basic Container
Finding and Managing Container Images
Performing Advanced Container Management
Attaching Persistent Storage to a Container
Managing Containers as Services
Review & Lab Session
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.
Right now we are going to get our hands dirty, of course we are focusing on the guided exercise which is all about Managing Containers as Services and allow me to add this that this is one of the most relevant activities in this class. So, to get things kick-started, we're going to run the command lab containers-services start. Of course we need to make sure that we have our successes before proceeding. So, first up guys what we are going to do is make an ssh connection as student to servera, then we are going to elevate our privileges to that of the root user so, we use the sudo -i command. It's going to prompt us for the student user's password, of course that password is student. From there we are going to add a user and this is going to be the contsvc user. So, this is going to be the user account with which we are going to be running our containers as systemd units. Then we are going to give that user a password and I know this is bad form, I know that you can see the password on the command line but remember that is my intention, I want you to see that I am setting the password for that contsvc user to redhat. So, guys feel free to disconnect from that particular session because next we are going to make an ssh connection as the contsvc user to servera.
So, what we are now going to do is use the mkdir command and we are going to create a directory called .config/containers/ in our home directory and the reason for that is that the lab start script it created the registries.conf file which is below /tmp/containers-services so, this has got a reference to the registry that we are using in our classroom and that registry has got an image that we are going to be using to start a container from. So, all that we now need to do is in order for us to use that registry, we need to copy the file registries.conf from /tmp/containers- services to our home directory .config/containers. So, the next thing that we are going to do is create a directory that we are going to be using for persistent storage for our container. So, inside of your user's home directory create /webcontent/html/ and then we are going to create a simple index.html file with the text "Hello World" or in my case I just spotted my typo right now "Hello Word". So, yes I have redirected "Hello World" to webcontent/html/index.html. So, all that we now need to do is validate that we have the permissions that would facilitate access to that index.html file. So, use the ls -ld command against the webcontent/html directory, we want to make sure that other has read and execute. What we also want to do is make sure that for index.html other has the read permission. So, guys the next thing that we are going to do right now is use the podman login command and again I have got the username and password on screen that's part of my bash history. Typically I wouldn't do this in the real world however I want you to see that I am authenticating as the user admin with the password of redhat321 to registry.lab.example.com and of course it's from this registry that we are going to be downloading an image with which we are going to be using to start our container. So, let's go and fire up a container. So, over here podman run is being used with the d option. We are starting a detached container, the container is being named it's getting the name of myweb and we are doing port forwarding as well. So, we are taking port 8080 on the container host and we are forwarding it to the container port 8080. We are also doing a volume mount. So, over here we are saying -v and we're going to take the directory that we had just created that webcontent directory which is on the container host and we are mounting that inside of the container to /var/www and you could see that there's a colon and then an uppercase Z afterwards which sets the SELinux context of container-file-t on that directory.
The last argument of course is the image that we are going to be using for that particular container.
So, next what we are going to be doing is using the curl command against the localhost port 8080 and of course localhost port 8080 is being forwarded to my container 8080 and in my case I see "Hello Word" however you should see "Hello World" if you followed the instructions as the student guide recommends.
So, what we are next going to be doing is creating a directory to host our systemd unit files. So, mkdir -p inside of the home directory, we are creating .config/systemd/user so, that's going to be the directory that's going to hold our systemd unit files. So, let's change to that directory using the cd command and then from there we are going to use the podman generate command. So, we say podman generate systemd and now we have to reference an existing container, an already running container and that is why we named our container. So, in that case we say - - name myweb and now we say - - files otherwise what's going to happen is that it's going to generate the systemd content but it's going to write it to standard out. So, with the - - files it generates the files inside of the current directory and also we have - - new which tells the systemd service to create the container whenever the server starts and delete it whenever the server stops. So, now what we could do is in order to test this, we are going to use the podman stop command and we are going to stop the container called myweb. We are also going to be removing it and this is all going to be handled right now by systemd and again that is the use of the - - new. So, what I just want to do I know that the instruction is not inside of your student guides. However I didn't want to show you the contents of that container-myweb.service.
So, if you go into your directory that .config/systemd/user directory there there's a file called container - whatever the name of your container is .service and this is the generated systemd unit that we have. So, you could see here we have the unit definition you could see the Description, the Documentation that is applicable to this, the once the dependencies in other words the once and the after and then you have this the Service block over here.
So, a couple of cool things about this right now is that we have like an ExecPre section or an ExecPre command over here. So, this is what's going to happen before we actually start up the container. The ExecStart specifies the command that we are using to start up the container and then we have ExecStop. So, this is how we go about stopping the unit file and then after we stop the unit, after we stop the container, we want to remove the container itself using podman rm and then what you can also see is that there's an Install section. So this particular unit is going to be initialized by multi-user.target as well as default.target. So, let's move on to step 7 right now. I know that this particular instruction is not inside of your student guide but I want to to run the podman ps command to show you that I don't have a container right now.
So, the next thing that we are going to do is use the systemctl command and we have to prefix it, we have to make use of the - - user option because if we don't use the - - user it's going to require root privileges. We are going to be re-initializing those systemd unit files below etc/systemd/system. So, instead what we are doing right now is that we are making systemd aware of the unit files below .config/systemd/user. So, let's go and do a daemon reload, now that systemd knows about our user defined units. We can now go and use the systemctl command and we say - - user and we are going to enable and we are also going to start the unit right now and the unit is called container-myweb and then what you can also see is that it's created a link from
/home/contsvc/.config/systemd/user/multi-user.target.wants/container-myweb.service So it has created that link which points to the unit file that we had created in a previous step.
So, now guys when we run the podman ps command what we can see is that we have a container and this container was not started directly by us using the podman run command.
So, let's go and put this to the test right now so what we do now is that we simply go and run curl against localhost port 8080 and we have "Hello World" in my case but you could see that I get the content that comes from my container.
So, let's go and stop it right now so, we are going to use the systemctl command and don't forget we need to make use of the - - user option.
Otherwise it's going to manage an actual system service.
So, systemctl - - user we are going to stop container-myweb and then when we run the podman ps -a command, we can't see a container not even an archived container. So, podman ps -a will show you the status of all containers even those that have been archived. So, what this proves right now is that when we stop the container using the systemctl subsystem, what it's going to do is that it's also going to use the podman rm command as a result of that exact stop post instruction.
So, let's go and start it up one more time. So, here we are using systemctl - - user start container-myweb and no surprises over here the container's back.
So, let's move on to step 8 right now so, we have to remember about the loginctl command in about enable-linger. So, in this case what we are going to do is that we are going to make sure that our container started whenever the system boots otherwise what's going to happen is that the container is only going to be started whenever the user logs in. So, for the contsvc user we are going to use the loginctl enable-linger command and then if you want to look at the stages of that we can also just verify by running loginctl show-user contsvc and what we are looking for is that linger is enabled. So, you can see that there's a directive that says Linger equals yes. So, the next thing that we are going to do right now of course is test this.
We are going to elevate our privileges to that of the root user so, we use sudo or rather su - it's going to prompt us for the root user's password, we can't make use of sudo because the contsvc is not enabled inside of the pseud users file. So, we elevate our privileges to that of the root user using the su command and then we simply use systemctl reboot.
So, this reboots the system and what we should find is that when the system comes back out that we do have the container running and that we can access our content so, let's go and do that.
Make an ssh connection as contsvc to servera, from there use the podman ps command and you should find that your container is there, your container is running.
Next what we are going to do is use the curl command and we can access our content and again in my case I have "Hello Word". So, guys it is that simple. Once you are satisfied what we could do is wrap up by running the command lab containers-services finish and while it brings this guided exercise to an end. What's coming up next is the end of chapter lab where we are going to be testing your skills. So, I will see you there in the next video for that lab.
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, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).