Lab: Running Containers

Developed with
Red Hat

Contents

keyboard_tab
Introduction & Overview
Managing Containers as Services
Review & Lab Session
Start course
Overview
Difficulty
Intermediate
Duration
1h 46m
Students
70
Ratings
3/5
starstarstarstar-borderstar-border
Description

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.

 

Transcript

Time to walk you through that skills test, of course this is the end of chapter lab and we are focusing on Running Containers. From a terminal for the workstation virtual machine, run the command lab containers-review start, make sure that you have your successes before proceeding and what we are now going to be doing is running a container on serverb. So, make an ssh connection to serverb as the student user and then from there what we are going to be doing is installing the yum module for container tools. So, the command that I have used over here is sudo yum module install -y container-tools and you guys are not really interested in seeing all of the output, right! You only want to make sure that that the transaction is successful. So, I am piping it out to tail -4 and all that we are looking for over here is Complete. Now the next thing that we are told to do is to determine the image with the lowest tag, the lowest tag version for the mariadb image. So, what we are now going to be doing is making an ssh connection as the podsvc user to serverb. Then what are we going to do in order for us to access that image we are going to use the podman login command and we are going to log into the registry registry.lab.example.com as the admin user which has a password of redhat321. So, in order for us to inspect the image and to learn more about it we are going to use the skopeo command. So, we say skopeo inspect and then docker://registry.lab.example.com/rhel8/mariadb-103 and guys you are not interested in seeing all of that output right. So, what I have done over here is that I have done a grep I am looking for the four lines after the regular expression RepoTag is found. So, what we need to do is figure out which one is the latest,  which one is the the lowest numbered version. So, of course what we can see over there is that we have three tags, these tags facilitate versioning.

We have "1-86" "1-102" and then we have "latest". So, the one that we are going to be transacting against is the image with the tag "1-86". So, the next thing that we are told to do is that we need to go and create a directory for our persistent storage and on serverb as the podsvc user what we are doing is making the directory db_data and of course that is inside of our home directory. 

Then we just need to make sure that we have permissions that facilitate access to that directory. So, I have used the chmod 777 command against the db_data directory.

So, what we are now going to be doing is running our containers. So, use the command podman run -d. We are going to give our container a name. The name is going to be inventorydb.

We are going to be doing port forwarding so, we are going to forward from the container host 13306 to inside of the container 3306. We are also going to be doing a volume mount. The volume mount is from /home/podsvc/db_data and we are going to mount it inside of the container to /var/lib/mysql/data and to take care of the SELinux requirements we are using colon and then an uppercase Z. Now what we also need to do is run the container with certain environment variables. So, every environment variable is going to be prefixed with the -e. So, guys we have environment variables like MYSQL_USER which is operator1. MYSQL_PASSWORD is being set to redhat, the Database that we are creating is called inventory, the MYSQL_ROOT_PASSWORD is redhat and this is all going to be based on the image registry.lab.example.com/rhel8 and then mariadb-103 and we have to specify the tag. The instruction says that we have to use the image with the lowest versioned tag. So, then in our case is 1-86.

So, all we need to do right now is basically test the database. So, guys we have a script for you, it's in the containers-review directory on serverb as the podsvc user account and the script is called testdb.sh. So, what you should see is a success. Now what you could also do is that you could execute this manually. So, if you want to have a poke about in our shell script have a look at or run the command cat containers-review/testdb.sh and ultimately what we are looking for over here is that you can make a connection as operator1 using the password of redhat to port 13306 on localhost and what we can do is use the show databases command and we can see the output includes the inventory database.

So, next we do want to start up the container as a systemd unit, of course this is going to be handled as a user systemd unit. So, what we now need to do is make sure that we have a directory in which to store our unit file. So, what we are going to do is create a .config/ systemd/user/ directory. So, now we change to that directory using the cd command and now we can generate the systemd unit files in that directory using podman generate systemd. The name of our container is called inventorydb, we are going to write it to the current directory and we are going to use the - - new option and that will ensure that the container is started and when it's stopped it is also removed.

So, the next thing that we are going to do is stop inventorydb, we are also going to remove it using podman rm and because this is all going to be under the control of systemd.

So, now we need to tell systemd, we need to give it a poke, we need to say hey systemd!

There have been a couple of changes right now to the units that are managed by a normal user. So, we use the command systemctl - - user daemon-reload and what we are going to be doing is using the systemctl command to enable as well as to start the container right now and that's going to be for the unit called container-inventorydb.service.

Now what we of course want to do is that we want to make sure that the container is started as a systemd unit whenever the server boots up. So, what we now do is that we use the loginctl enable- linger command. So, just as a bit of a cursory test, what I could do is use podman ps what I could also do is reboot and I could test to make sure that the container is started as a service. However what we could do is we could test our work using the grading script that we have. So, guys once you're satisfied what we can now do is from the workstation machine very importantly these lab scripts execute from the workstation machine. What we now do is that we run the command lab containers-review grade. As you can see I have got my passes I hope that you do too and if you don't, don't be afraid what we could do is go back refactor and we could regrade. However just to wrap up all that we now need to do is run the command lab containers-review finish and with that it does bring this chapter to an end, I will see you in the next video for the comprehensive review.

About the Author
Students
95992
Labs
54
Courses
110
Learning Paths
85

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, and Kubernetes (CKA, CKAD, CKS).