Right now we are going to have a look at Managing Containers as Services. However before we do that let's think about how you would go about Managing Traditional Services that have not been containerized? So, let's pick on Apache httpd. So, to get things kick-started what we would normally do is use the yum install command to install the software. Now that the software is installed we now need to start it up and enable the service as a unit. So, what we would then do is use the system ctl enable - - now command and then of course we would reference the unit file that represents our software. So what would happen then is that whenever the system boots up that unit is going to be started up. Now let's go and think about how we would do this for containers. So, we could initialize a container as a systemd unit. Now this is really cool this is really awesome and I want to let you know on something on a little bit of a secret. I use containers in this way, I don't use OpenShift in my personal capacity, I don't have the kind of money or the infrastructure for that, however I still make use of containers. So, for things like my website which is powered by wordpress, for things like my database services, very often when I engage with customers I share code snippets with them and they share code snippets with me. So, I have my own private pastebin instance that I am using that customers can use to share snippets with me. All of these things run as containers however the caveat right now is that what if my server reboots, what if my server reboots and I am not there to start up the container automatically. So what we can now do is that we can initialize containers as systemd units and the cool thing about this guys is that we don't need root privileges. So, let's go and have a look at some of the techniques that we would adopt.

So, traditionally anything that is user-defined related to systemd would go below /etc/systemd/ system. However adding files to that directory, changing files and removing files from that directory will require root privileges. So, one of the cool things that we can do with systemd is that we could create a directory in our home directory, we can reate .config/ systemd/user/ and the cool thing about this right now is that I can take my user defined unit files and I can store them below that directory. So, let's go and talk about managing it right now. Let's go and talk about initializing and managing your own user-defined files. Now, ordinarily guys what you would do is that you would use the systemctl command to enable, to disable, start and stop your system services. However when it comes to things like user-defined services we have another option that you can make use of. So, when you make use of the systemctl command there's a - - user option and as you can see as per the man page over here and this is the man page for the systemctl command. The user option talks to the service manager of the calling user rather than the service manager of the system. Now to get these unit files, to get these user-defined unit files what we could do is that we can make use of the podman-generate command and you can see over here that we could say podman generate, well this is the man page for podman-generate as one command but what we could do is run podman generate space and then we could say systemd.

So, what that will do is that it will generate the systemd unit files for us to use a container as a service. Now there's one caveat that you have to be mindful of and that is when you use systemd unit files in this way, when the system boots up what's not going to happen is that your unit file is going to be initialized and that is because when it comes to systemd user defined services what would happen is that they would only initialize when the user logs in. So, what if you are not logged in. What if your server reboots like it does for mine, what if the server reboots and you are not there to interactively log in and therefore have your container started as units? So, guys this is where we have the login ctl enable linger option. Now the cool thing about this is that when you enable it for your particular account what's going to happen is that even though you are not there, your services are automatically going to be started.

So, to do this would make use of the login ctl enable linger command, so that would enable the linger service and then what I would do from there is that I would go and enable my container as a systemd unit file. Now guys doing this using podman is okay! for smaller solutions. I am using this when it comes to my wordpress website using a couple of MySQL Databases and a couple of other containerized services. However when it comes to managing this at scale the solution again is horribly insufficient and this is where we have OpenShift and I must add that OpenShift is is complex, it's impressive and I spend most of my year engaging with customers using Ansible Automation as well as OpenShift. OpenShift is complex and I would love for you to learn about OpenShift, I would love for you to learn about using Kubernetes and Managing Containers at scale and this is exactly what we cover in a couple of other classes. So, we have an OpenShift series of classes and if you are interested have a look at the DO080 class and then from there you could pivot to the DO180 class which is all about OpenShift Administration that is the starting point for OpenShift Administration 1. So, guys right now it is time to get our hands dirty, we are going to be experiencing these things, Managing Containers as Systemd Units so, hop on over to the next video where I will meet you there for the guided exercise.