Provisioning a Containerized Database Service
Containers - why all the hype? If you're looking for answers then this course is for you!
"Deploying Containerized Applications Technical Overview" provides an in-depth review of containers and why they've become so popular. Complementing the technical discussions, several hands-on demonstrations are provided, enabling you to learn about the concepts of containerization by seeing them in action.
You'll also learn about containerizing applications and services, testing them using Docker, and deploying them into a Kubernetes cluster using Red Hat OpenShift.
In this section we'll take our first look at actually running a Container. I'm going to step you through a few of the podman commands we need to pull down our images and then actually run our Container. We're going to do this using a mysql image. So how do we fetch Containers? So in order to actually run our Containers we want to have them pulled down and available locally. And the way we can do that is using the podman search command and then the podman pull. So podman search is going to index one of those image registries and look for an image based on our search term.
So in this example down here we are searching for any Container that contains rhel. So what you're going to do is you're going to configure podman and point it to the registries that you want to have podman search in. So for example we mentioned the Red Hat Container catalog, we mentioned Docker hub Quay.io these are all registries that you can configure podman to be using, so we would do a podman search we search for rhel and we see we can we have found an image here that's available at registry to access the redhat.com/rhel.
Okay so if we want to have that available to us all we would need to do is run sudo podman pull rhel and rhel would be downloaded and available for us to create Containers from that image. So this is the structure for how images are named. It's just useful to keep in mind. Essentially it is a combination of the name of the registry, the user name that the image belongs to and then a specific name for that image. And then finally a tag which denotes the version of the image. So for example and down here we have registry.access.redhat.com/rhel, so that's an image name, that's the repository that the image is coming from as well as the name of the image itself. And the tag is latest, so latest is the default name. If you don't provide a tag for your image it's automatically going to be given the tag latest which usually implies that it's the newest. That's not always the case, it's always smart to tag your images and make sure to give them a version number.
I'll just help to keep things organized but example you would see like if you had a you know rhel 7.6 image you may see rhel and then the tag number would be 7.6. Okay, containers are run by using the podman run command and then by passing in the name of that image so for example we would run podman run rhel 7:7.5 and 7.5 specifies the tag number in this instance and then we could run a command at the end of that run.
So for example this one says hello world, so what that's going to do is it's going to start a container and it is going to basically be running a very lightweight version of rhel seven and it's going to just run a simple echo hello world. So I mentioned earlier one of the ways I described a container was by saying that it is an isolated process. So one thing to know about a container image is that at the end of a container you're always specifying what is called the entry point and the entry point is the process that is running within the container. So if you were to look at say a mysql image at the end of that image the last thing you're doing at the entry point is that you are starting the mysql service.
Similarly in a web application if you're using an Apache server the last thing that you're going to see is that you're starting the Apache process. So one of the interesting things about containers is that you are able to override that process if you would like to on the command line when you were running the container. So in this instance we're using like I said the rhel 7 image if that one doesn't have a running process it'll just default to a typical bin bash - c. So we can pass anything we want in at our entry point and in this case we're just running that echo Hello world. One other option that's important to know is the -d option.
I typically use this a lot because when you're running a container it's just a long-running process you probably want it to be running in the background. So the -d option is going to put that in the background so you can have your terminal back. If you don't do this your terminals going to be locked up with a process and if you press ctrl c not only is that container going to stop but it's going to go away.
So the process will end and then your container will have to be manually restarted. Here are some other important options to know about when using podman. You want to always give your container a name. This name has to be unique ,if you don't provide one, one is automatically generated for you and they're occasionally a little bit embarrassing to be honest.So it's a good idea not only because it's more organized but to save yourself some embarrassment with some awkward names of your containers.
We also have the -i and the -t option. So -t stands for Pseudo Terminal and -i for Interactive. These are almost always used in conjunction with each other or we often use them in conjunction with each other. These are great for when you need to interact with your container, if you need to have the ability to do like input/output, if you want to run commands within your container then you're going to want to use -i and -t. So here's an example of a container run, running podman run -it rhel7:7.5, 7.5 is the tag and then we're running bin bash. So what this is doing is it is creating a container that is based on rhel 7. We're running it interactively and then we are using a the bin/bash to override the entry point and to start a bash shell within the container. So those subsequent commands I'm running ls, whoami and exit, those are all being run actually within the rhel 7 container. So how do we get some information inside of our container.
We'd like to think of images and containers as immutable but we need to be able to transfer our own information. How do we configure our mysql server for example. So one way to do that is by using environment variables. So this looks like very similar to the example we just looked at. We're running podman run. We're taking the name and we're passing in the name of the container that we want to use. In this case mysql-custom and we are specifying the image name here mysql we're using the tag 5.5 and we're specifying with -e environment variables.
So these are the environment variables that are required for us to start the mysql service correctly. We need to pass in at least the mysql user and the mysql password. We're able to do this directly from the command-line when we start our container. If we didn't pass these in our container would probably fail to start, the process would not run properly. Okay so let's jump right into the demonstration and we'll take a look at creating a mysql container.
Okay so in this demonstration I'm going to be running this command here that is going to kick off a new mysql container based on this mysql 57 rhel 7 image. We're going to go inside of the container we're going to you know test it out make sure that we're able to create a table and you know insert some rows and just demonstrate that we were able to get a fully-fledged mysql service up and running. So in this podman run command again this is similar the example that I just showed you we're naming the container mysql-basic or passing in our environment variables. So these are just specifying who our mysql user is, the password the name of the database and the root password these are all required parameters for us to provide to start the mysql service.
We're running it in the background using the -d option and then this is the name of the image that we're using so let's give it a shot. Okay so the way we can check to see if our container is running is we can do a podman ps. Okay so this output is going to give us the container ID, it's going to give us the name of the image, it's going to give us the name of the container and it'll talk about when it was created how recently the container was created.
Okay so now that our container is running we can run podman exec -it this isn't the one you've seen before but I mentioned it earlier podman exec is going to allow us to go inside of our running container the -it if you remember this is our interactive terminal or passing in the name of our container and then we're going to pass in /bin/bash.
So this is going to allow us to open up an interactive shell within the container. Okay so from here we're going to use the mysql command. We're going to log in as root, okay so now we are in our mysql process and when you show databases okay I remember that we specified the name of our database was items so we can see here our database items is there. So let's switch over to using that one and I've got mysql create table ready for copy and pasting.
Don't worry if you're not really that familiar with sql commands. This is just to demonstrate that we're able to make changes to our database within our container. So I'm going to create the table projects, okay everything looked good there and let's take let's do a show tables to see that we can see it. All right we can see projects and now I'm going to insert a row into that table, insert into Project (id, name, code and we're going to pass in the values(1, 'Devops,' and then this course code 'DO080'), okay I think that's right it's not okay I got it I have a comma instead of a parenthesis ah projects. There we go alright third time's a charm.
Okay so then let's run select all from Projects and we can see that our row has been successfully inserted. So let's get out of this mysql process and let's exit out of the container.
And that concludes this demonstration. So join us in the next video and we'll start talking about how to create our own custom images.
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.