This meeting is being recorded. Stan says, just as I stick that pizza in my mouth. Okay, this is the monthly St.
Louis log meeting St. Louis Linux user group. And this is. When Thursday the 20 first of September 2023 our speaker tonight will be with us in a moment, but first a few announcements.
This is a monthly meeting. There's also some other meetings on our schedule. I'll bring that.
See if I can do that. I understand have you got that handy that you can flip it up?
Pop up the calendar.
So, yeah. No.
No, okay. Give me a second. So I said it's embarrassing when you get a call with the pizza in your mouth.
First off, I'm gonna say I apologize for last week. I got waylaid by a little emergency.
And so I did not. Get in here to start the meeting on time. I was out here to em see it and so I left Stan holding the bag and he did a wonderful job.
Of somehow making it all work. So thank you so much, Stan, for for somehow getting it done.
There you go.
All right, and there's our calendar. So the ones in around are meetings that we actually, run.
So, like the St. Louis area Computer Club, it's kind of more of a hardware oriented meeting.
Of the steering committee that's where we make sausage. The Unix user group is Basically just open source.
I mean, Unix is an open source operating system, but we get into. To anything that's open standards or open source.
Tonight's meeting the St. Louis log kind of self-explanatory. And the new Linux user group.
Is the one-to-month meeting and that's You know, anybody can come. But we always try and, hey, anybody who wants to claim that they are the most novice user.
They get to ask the questions first and everybody else at the meeting tries to answer them. And, so it's a good place to go if you've got some.
Questions that you're just not getting answers to. So, so those are the meetings we run, the other things on the calendar, used to be all stuff.
Was here in St. Louis. With the age of COVID and the fact that us and so many other organizations went on to assume or did see or Any other, Microsoft Teams.
All those things were Now we can see meetings all over the world. And so anytime we see something that we think, you know, might have something to do with Linux, open technology, open standards.
We try and put it on the calendar here. And so the calendar has gotten pretty crowded. And, hopefully we got a volunteer who's gonna help kind of pair it down.
Curated a little bit. But so that's, that's what's going on there.
See, in a second we'll do. Just general Q&A.
And let's see.
Let's see, anything announcement wise we need to bring up lead, you know.
Not that I can think of. Stan, you have any particular announcements?
Next Tuesday will be the new Linux user group meeting.
Good, good. Good.
It's on the calendar. It's, it'll be sent out on our discussed mailing list and on the announce the instructions.
Okay.
It'll be a gitzy meeting. I prefer J. And All newcomers are welcome and and people that already know Linux, it's be nice that they join.
They could answer some of the questions. I certainly don't know everything. Phil, who usually comes along and corrects me on a lot of things.
May, or may not be there depending on his, move schedule. I'd have a Tennessee to say Megabytes when I mean gigabytes and gigabytes when I mean tetra bites.
And Phil's always there to. Correctly and sometimes said, And he corrects me. Yeah.
It's, always interesting.
2 other items here on the calendar. First off. See, Lee, if you got your finger on the calendar button still.
Tuesday.
So, just yesterday, I guess. No. Tuesday was the Red Hat Summit, here.
On the nineteenth.
You're in St. Louis and Do those right? I'm trying to, there it is.
Summit. And, so that was a A great meeting. I want to say there are probably about 60 people there.
Was over on Del Mar at Moonrise Hotel. Lot of good technical talks. A big thank you to Red Hat.
For putting it on. And it went very well. At least I thought it did. Maybe our speakers tonight may give us some inside.
But for those of you who may not have made it that night, I'm going to point out October the 20 seventh so we got a roll up the next month I guess upper left hand.
Okay. So on October the 20 seventh, we use it Friday. There is a red hat user group meeting here in town.
It's a physical only meeting. It's a lunchtime meeting and it's, held down at the Microsoft Technology Center down by St.
Louis, U. So, there's a city showing, there's a link.
And it's gonna be about answers. And terraform. And I believe that providing lunch I think but so sign up and register and Should be another good meeting.
Let's see. Yeah, 11 to one.
Okay, unless somebody's got any other announcements, Q&A. Anybody got any questions?
It doesn't have to be about tonight's topic. It can just be. Anything you want, probably only has a good chance of getting an answer if it has something to do with.
Technologies, computers, networking, something like that. So questions?
I don't think we wouldn't sleep yet, do you? Is this microphone on?
No, it's not. I can't hear you.
Oh, excuse me.
Yeah. Oh god. Hey, let's see, well.
There, there, when, when we finish up, We're done with the questions at the end of Chris's talk.
It'd be another opportunity for anyone to to pose any general topic questions. Albert. We get, done with the topics that, are immediately germane to.
To the talk tonight. But, With that, what? Usually don't.
Wind up with a group this quiet this early in the night. I'm missing anything that should be brought up.
I don't think so. I have to think we might want to mention Bach. Yeah, we're getting ready to do a.
Debian 10 to 11 transition and we have some concern about mailman. If anybody would like to help out, please jump on the system and list or.
When are you doing that? Do you have a date locked down yet?
No, not yet.
When do you wanna do it? Yeah.
When do you want to do it? Yeah. Hey, we.
You acting like I know anything about mailman at all, okay? I don't.
Oh, okay.
Well. No. Often any additional help is appreciated.
And it's, Certainly the old timers in the group can give you some some suggested boundaries of things that you probably don't wanna do or we know cause problems or things like, you know, we just know we don't want to go that direction, but pretty much if you volunteer to work on a project like this, you know, it's like, yeah, you Yeah, he who's volunteering is usually the one
who gets to Just decide how things are gonna dig it on. And set the schedule. Is that the schedule?
So.
Don't be scared to volunteer that you want to at least look into maybe doing something. It's a good way to learn.
A lot of times it's a, you know, a system that you're usually not used to.
Somebody else put together originally and such a good good way to learn things. In a lot of cases, the fact that you got new set eyes looking at it, you can ask questions.
That other people might just make assumptions about.
Yeah. It's, you know, it's the old thing. It doesn't mean it's necessarily being done right right now.
So sometimes when you ask a question, you know, the answer isn't, you know, oh well, we do it this way because but it's like.
Oh, the last guy put this together. We just didn't know you could do it this way.
So yeah.
So let's see.
I'm willing to, I'm willing to help with that once the date is set, but I'm not, I don't think I can drive the whole thing, but I can tag along and help.
Okay, okay, that'd be good.
Okay. Do you have a log in?
Yeah.
I had one. Do I remember what it is? No, that's another story.
I tell you what, shoot me an email directly and, it's a password updated or key, replace whatever you need.
Okay, great. Appreciate that.
Okay.
Let's see.
I guess.
Oh, I'm gonna mention something just for the odd curiosity part. I totally blew it.
This month, earlier this month. Was the 130 fifth anniversary. Of boroughs computer, which is now.
Unicorns. Computers. Burroughs was founded right here in downtown St. Louis.
135 years ago. They have an office downtown now. A period which building that is T.
Rex building. I guess. I don't know.
And to tell you the truth, I used to know some folks down there, but after the pandemic. I've kind of lost contact but I would have thought What have said something would have done something.
Maybe they're not even aware that that's their history, but yeah, not, not probably 10, a dozen blocks north of the current office is where the company was originally founded.
It kind of it's on our calendar but the quick version of the story is the original boroughs.
He was working in a bank. And he absolutely hated the job. I was just sitting around all day and working through sheets and numbers and and adding this, adding that, subtract this.
And he was kind of mechanically inclined and so he quit his job in the bank. He went to a an iron working place, basically a blacksmith shop kind of type thing.
Okay.
He told the guy, I want to try and build something, we're gonna call it an adding machine.
And so we basically built the first adding machine and the idea was it has to make you working at a bank easier and that eventually became the computer company.
So. Yeah, kinda neat that's a St. Louis thing and nobody's seen pay attention to it.
I'm guessing as one of the punch in your number, pull the lever and it would Got some kind of mechanical registers.
Hmm.
Yep, yep. And I don't know who, I mean, he got a patent on it and I'm sure there were some competitors back then but apparently banks really liked his because you know with his banking experience, he kind of knew exactly what they needed.
So the company took off. I forget when it moved out of St. Louis. And, but yeah, moved out of town.
There was a little thing. I think it's in the calendar section story. It, it basically said that all the employees were put on a train one morning.
They were told if you want your job, you know, we're going to move. I guess there's Minneapolis or someplace and so it's a whole train of employees that left one morning.
So.
Wow.
Anyway, so that's just a little trivial story. And I was throwing that in just because I figured, okay, usually we don't start with the main speaker till about quarter till later.
So. Wanted to make sure if anybody was joining us late they had time to get in. But, So, With that, for our talk tonight.
We're gonna hear about Podman from, from. Red Hat. And So Popman is a an open source, open standard technology.
And so yeah, it looks like it should be something real interesting. And Chris Boland who was here at the summit the other day.
Did a good president Good talks. There just informally with some of us. But I'm gonna turn it over to Chris.
And we're gonna hear all about it. So Chris. Yeah.
Before we do, there was a question in the chat room. Somebody asked what was the software behind the calendar.
That is, I frame. Pulling up a Google calendar. Okay. So.
Go ahead. I'm sorry. Go ahead, Chris. Yeah.
Yeah, I appreciate it. And thank you, Lee too. So as Lee mentioned, my name is Chris Bowen.
I do work for Red Hat. And I appreciate you guys actually both talking a little bit about Red Hat Summit.
Which we had just a couple days ago. It was a ton of fun for me. I saw some familiar faces there.
I know Steve Gomez and met some new folks as well. So that was good. And I also appreciate you guys mentioning the Red Hat user group a little bit later on in October down with Microsoft.
It's kind of interesting if you're aware of the Red Hat and Microsoft backstory.
How how much that's changed we are actually really good partners with Microsoft and do a lot with them actually The number one workload I think in Azure is Red Hat Enterprise Linux.
Which is kind of crazy. All of that being said, this is not a Red Hat presentation. So just to be clear with that, yes, I do work for Red Hat.
This is not a Red Hat presentation. This is just Chris. Talking about, actually it's gonna be more pod me on desktop at the end than Podman and we'll talk why that is and why I think I have fun with Podman Desktop.
A little bit about me. I've been with Red Hat for 5 years. Prior to that, I've been in the IT industry for a quarter of a century now, it seems like, which is pretty crazy to me.
Heavy application development. Done some help desk work and a lot of enterprise architecture recently. What I really get excited about is using open source to help companies get a competitive advantage and that's why I'm working for Red Hat.
So I think that's the best place to do that. Tonight, as I mentioned, we're going to start with Podman and Podman desktop towards the end.
I was looking on your website. And going through the history of talks that were given. And I noticed a couple different talks, back, you know, you months ago, maybe even last year on podman.
And so before getting into this, I wanted to ask you guys and you seem like a very quiet crowd this morning or this evening, which doesn't really bode well for my talk.
So I'm hoping Maybe somebody will come off mute beside Stan and me. And jump in like, did you attend those other talks on podman which which I didn't actually watch the talks.
I just went and looked at the presentations. Did you attend those? What's your familiarity with podman containers that type of stuff?
Anybody want to come off mute and just clue me in as to who I'm talking to besides the void.
Yeah, this is Steve's statement. I'm just wondering what is pot man? I've never heard of
Okay, yeah, so good question. We'll deal with that. What else? Who else is out in the audience that wants to be brave and say something.
Hi, this is Josh. Basically I have the same question. I don't really have any, but not seen any previous presentation or anything.
About it. So just general interest.
Okay. Awesome.
Hey, this is Sean. And, I, have, used Podman at work and at home for a while, but there was some incompatibilities with, the way that it works with Dr.
Compose. I have to switch back to Docker unfortunately, which means my company had to pay for Docker desktop.
I'm not a huge fan of, but, yeah, I'm, I'm always, trialing pod man to see, like, is it fully ready for me yet?
Can I use it right now? But.
Yup, that's awesome. Thank you, Sean. So.
And just to pass it to, I think Andrew, I don't know if he's here right now, but he actually gave the last pod.
I think so. Real expert in the house there.
Oh, outstanding. Well, I will take any expertise you guys are willing to lend. And so if I am, if I say anything dumb or make mistakes, please jump in and correct me because like I said, this is not an official Red Hat thing.
This is just Chris talking about podman and Podman desktop and I agree with you, Sean, you know, if you've got heavy Docker compatibility concerns, it can be tough to transition for sure.
It's easier to to start fresh with any technology. I appreciate you guys. Cool me in kind of and that helps me.
My the way I'm gonna go through the slides and I guess I should start sharing screens and things you can Stop actually looking at me and we'll see something slightly more interesting, I hope.
Alright, we'll do this guy and share.
Where did.
Zoom over here. Alright, are you guys able to see the presentation currently?
Yes.
Okay, awesome. And the way I've got this set up, I've moved zoom over to my left so I won't see any chats they won't pop up and be obvious so so I won't see any chats. They won't pop up and be obvious.
So, if somebody is shy and puts it in the chat, if a braver soul will interrupt me, or if you're feeling brave yourself just to shout out like you know We're friends, we're just chatting here about technology.
This isn't a sales presentation at all. Alright, so, the abstract, I don't know if you guys got a copy of the abstract.
But really what I'm trying to get to with this talk and presentation and demo towards the end. Is to first look at Why we move to containers for our software, what the promise was and and why it actually didn't work out the way we were hoping.
And then talk a little bit about that and move towards, well, maybe we can use newer tools like Podman Desktop to try and squeeze the distance between what we're doing.
Our personal development machines, whether their desktops or laptops, squeeze that distance if we're doing containerized development.
And deploying to something like Kubernetes. Because what we what we see is that how you develop software locally and how you end up deploying it can be different and it can create some friction and bumps and bruises as you move from those environments.
And I think Podman desktop can be a pretty handy tool. When dealing with those things and I said, I don't think we're going to eliminate the distance between the laptop and Kubernetes but maybe maybe shrink it.
And certainly make it easier. For folks that are developers and don't necessarily want to be cube admins or write lots and lots of YAML.
Things like that. If you're not familiar with Kubernetes as a container orchestration platform, basically the lingua franca of Kubernetes is YAML files.
And I'm not a big fan of LAML. Yes, there's there's linting and other ways, but It can be tough to find errors in white space.
So let's go ahead and get into really what's podman and thank you guys.
Who said you know I'm not sure what podman is and and why I'm here other than this is on my calendar.
So Podman is an open source. Container engine, it's not a runtime.
There are various runtimes you can actually plug into Podman that vaulted something called Run C.
But it's a container engine to run and manage containers without having to use that background demon. And I think Sean brought up Docker and Docker compatibility.
Docker runs as a background demon and a typically runs needing root privileges regardless of what machine it's running on whether it's a Linux machine or Windows machine or whatever.
And Potman was architected specifically to not need that. So it isn't. Doesn't run as a demon for example and it does not run with root privileges by default.
Now you can if you need to, if you have applications or containers that need to have elevated privileges, you can do that.
But it's not, it's not by default going to run with rootless containers. And I bring that up in the context of.
What I do, you know, on my own time when, when I'm at work.
I am very serious and buttoned up about the sources of my software. I'm very concerned about software supply chain when doing work types stuff.
So where are my images coming from? How am I building those images? Are there, you know, security scans going on that type of stuff?
When I'm working at home, not so much. And so for me, I feel a little bit better running a a container engine that isn't running as root because if I screw up, if I choose the wrong image out of the cesspool known as Docker Hub.
And, you know, I should do better job checking, but I don't always. And, and, and it hasn't happened to me.
But in theory, I could pull down an image that has, you know, malware, some other, other vulnerabilities.
I feel much better being a little bit lazy at home if I've got pod man kind of backing me up.
I'm not saying this is a best practice. I'm not recommending this is a best practice.
I'm not recommending you guys do that at all. I'm confessing personal shortcomings.
And again. This is, this is not a red hat presentation, so would not say that to Red Hat.
The other thing that I like about Podman is compared to Docker desktop or Docker in general.
Is that it's much more Unix like and that makes a lot of sense because the guy who wrote book podman his name is Dan Walsh He is a distinguished engineer from Red Hat.
And he, his nickname is is It's Dr. Linux or something like that.
I mean, Dan is, he basically wrote Selinux. If you're familiar with security enhanced Linux, that's Dan's work for the NSA.
And what I like about live in is instead of the Docker way of doing things, which is having that single monolith that does everything.
Podman is actually split into smaller pieces of software that you can compose. So there's pod man, the runtime engine.
And then there are other pieces such as Scopio and Bilda. In the Docker world, all that's one thing.
It's all in the Docker binary. In Linux in Unix, we don't like to do that.
We like to have small utilities that you can bring together and create interesting things. So like I said, podman, the container engine, and in the command line tool.
Scopio is all about image, copying and deleting, pushing to registries. If you're signing your images, you'd use scope.
And then Bilda, as you might guess from the name, creates container images. Just a little bit of history on Bilda.
This is something that Dan Walsh wrote. And Dan's from Boston. The reason they named it Bilda, if you know anything about the Boston accent, you can imagine somebody from Boston saying build it and it ended up always build a buildup buildup.
You know, Pocky Ka and Hava Yad. That type of stuff. So that's why builder has that funny spelling and funny pronunciation.
They got the the guys who named it were making fun of Dan and his accent.
Yeah.
Hey Chris, quick question. Oci compatible any chance steps? Helps with the architecture issues between Windows and Linux.
You mean an example of the architecture issues. Okay.
Well, for example, a container. Built for Linux won't run on Windows.
Okay.
So no, it won't do that. So what OCI compatible is trying to do.
Is If we go back in history. Docker. Okay, so if we really go back in history, Docker did not invent containers, right?
I, I saw some of you guys in person and I'm guessing based on on looking at the website.
That you might argue with me that docker invented containers and you would be right. You know, we could talk about containers from the mainframe and doing isolation.
Then we could talk about Solarithones and how containers are just another implementation of that type of isolation.
All of that's correct. 100%. But from from a speeding through things from from a shortcut.
Docker kind of popularized, let's say popularized and didn't invent. Docker popularized containers.
What happened with that? And if you've used Docker, you know, you have, you have Docker, you have Docker composed, you have Docker Swarm, everything is sort of Dr. Dr. Docker.
You have a Docker file. For example, when, because Docker had such awesome success with this technology, really, really a breakout technology, what, 15 years ago or 10 years ago.
They basically owned the whole space. They were the sole developer implementer of this And some of the problems with doing that is that when you have people building onto an ecosystem and you're not really as a company ready to take on the responsibility.
Of being a foundational linchpin type of software for an ecosystem, you might end up making breaking changes with having all the all the best intentions in the world, but making breaking changes to the software.
And so the Open Container Initiative folks kind of looked at the state of Docker.
Docker being the de facto standard. It was it was Docker Docker Docker.
That was really it. Was it a great idea though to take what had become such a critical piece of our modern infrastructure and leave it with one company, a proprietary company.
Who, you know, it was a small startup didn't necessarily have the the experience or the wherewithal to to sort of serve as a foundational component.
And so when they when they took over the standards, essentially the OCI stuff started as. We're gonna take Docker as the standard because that's what it was.
It was a de facto standard, but we can't keep naming things Docker. And so they created different standards for things, different names.
So the new name for a Docker file is the container file. They're exactly the same thing, but the OCI name and and you can use either one interchangeably with Pop Ben.
The, but the OCI folks wanted to create that type of standardization. So that's really where what OCI.
Is about now you asked about architecture from Windows and Linux and let's say max which I'm going to be using today that.
That chip market so There's there's a couple of ways to do that at their core.
Caners are. Linux. Their Linux. Now I know there are some you know things about Windows containers and such we will you know, we're, we're St.
Louis, Unix users group and Linux users group. So we're gonna, we're gonna leave that oddity off to the side.
Maybe that'll actually get real traction going forward. But for the most part, containers are Linux and what I mean by that.
Is that they depend on features in the Linux kernel to make them work. We, we, when we draw pictures of containers, we draw them like, like boxes, like they, you know, and the metaphor is a container.
It holds things. That metaphor is a little bit misleading. I think. Because what a container really is, it's actually and it's pretty straightforward and simple, and but the metaphor makes it, you know, doesn't, doesn't attach too well to this.
It is an isolated process. On running on your Linux server. That's all a container is. It's an isolated process.
And where is it isolated? It's isolated in the it with Selinux. It's isolated with your C groups and your namespaces.
So the first thing when you create a container it's going to create a, a separate namespace for basically all the things.
So separate user namespace, separate networking. Storage, etc. And all of those are they use The namespaces, the C groups.
Selinux to make sure that all of those, they look like their own. Linux container when you're in there and we'll see this in a minute, but they're really just a process running on a host.
So when you think about that, this is a process running on a host. My container is a Linux process.
That's why you can't go from running your container as a Linux process on a Linux machine.
To running it on a Windows machine because you're running a process. So you can't really switch the process.
From, like if you're using virtualization though, and that's what Docker does actually, or that's actually what podman does as well for both Windows and Macs.
Because it's actually running a Linux VM under the covers. And then that is where those container processes are being run.
In that VM. But that's sort of an implementation detail for those other operating systems for a Linux system such as Fedora, which is I use at home or Real, which, you know.
Bit popular in the enterprise world. They run natively as processes on those O. Also from an architecture perspective, we've had some recent changes with mac architecture.
So, you know, 2 years ago, this was all x. 86 architectures on max. Yes, it was, you know, it's more free BSD than Linux or Unix.
But you know, it's Unix-ish. It's post 6 compliant, all that stuff.
And it was an x 86 architecture so that when you built a container on a Mac with an x 86 architecture you could actually run that container on a Linux system.
Pretty much unless you did, you know, really specific customized things. When Max moved to, this is not at all what I wanted to talk about today, by the way.
So, hope we have time. But this is it's important to me because it affects me when Max moved to the ARM architecture if I build a container on my Mac natively, it'll run fine on my Mac because it's it's the ARM architecture.
But if I try and take that same container image and run it somewhere else because it was built on ARM.
If I try and run it on a Linux system, it won't run. So for me, this has caused a little bit of consternation and concern.
It's a little annoying. You have to pass in an extra flag and I forget what it is.
You know, dash dash. Something something AMD, 64. And then it'll actually build the art, when you when you build your container image, it will build it for your target architecture, not for the system that you're running it on.
Is that not allowed to OCI?
So it kind of becomes. It kind of becomes a cross compiler when you use that flag. Okay.
Yeah, yeah. That's a great analogy, Steve. Thank you for saying that. I appreciate that.
You're exactly right. Great way to think about it. All right, so, so that's, so we, we talked about Podman and OCI and Docker and stuff like that.
But why are we doing? Containers in the first place. One of the reasons that I like containers a bunch both as a personal developer.
Doing stuff at home as well as somebody who before working for Red Hat actually worked for Panera Bread for just about 13 years.
Working in enterprise software development. Was and I'll use Panera as an example. So like.
My first, my first bits into PENer, let's say I was writing some sort of web application that needed to talk to a Postgres database.
I would have to go to the infrastructure team and request a VM and have Postgres installed and then they'd have to you know create DNS and do networking and all of those kinds of things.
That took a bunch of time. It was, it could be days or weeks depending upon, you know, how busy those teams work, creating tickets and all of that type of stuff.
And it just made, you know, your writing code, you have this dependency on Postgres.
You'd like to, you know, start doing it and get out of mocking things, which I hate.
So what, you could do then once, backer, blustered hard. Came up with this container idea is that you could actually as a developer Run that Postgres instance in a container locally on your machine.
So instead of having to go hat in hand to all these other teams, even if you were, you know, doing it virtually through a ticketing system.
But basically, you know, hat in hand go, you know, please serve me. I have a Postgres.
You could really do it for yourself. And then really accelerated your ability to start working on the stuff.
You cared about. That didn't care about Postgres. When we got into, you know, Dev and QA and pre pod and staging and production, yes, there were going to be real postgresses.
They weren't running in containers. But it made it much faster for me. To start working with the code that I was writing because I was removed from that that dependency blockage.
So that was, that was huge for me from a developer perspective, from a, from an infrastructure perspective, there's a lot of interest in containers.
Because it's really a continuation of the journey we've been on. With virtualization. So virtualization was all about better utilization of our physical hardware machines.
We had these giant servers. And it didn't make any sense to run just a few applications on them but we didn't want to run too many applications on them because our dependency management was terrible and then we couldn't make there were different patching cycles and and all of that mess but I'm sure you guys are fully familiar with and perhaps even still living.
And so containers came along. The infrastructure guys are happy about that. They can continue to virtualize even further down.
So if a VM is virtualizing the hardware, you can think of a container as virtualizing the operating system.
So they're much smaller, much higher weight. They start much quicker. So a lot of a lot of good reasons to do that, but also easy to share.
You can put the things in version control, you can put your final artifacts in a container repository and your other developers can start working on things and you can collaborate.
So there's really a lot of good reasons to do containers and that's that's why you know Docker just became so popular.
So again, back to podman. Podman is that container engine. If you're getting it from, Red Hat type stuff, it'll be in your container tools package, whether you're, running that in REL or Fedora.
And I put on this. On this slide here, a list of the commands. And this is a very small subset of the list of pod man commands that you might be interested in.
So podman build, podman run, podman PS. If you've done DACA before, that's really gonna look very, very similar.
Shawn's gonna say, yeah, but it's not similar enough. I feel your pain, Sean.
You're exactly right. But it is, you know, pretty much unless you got some some specific customizations that don't work, particularly around compose.
Which is, you know, certainly more nuanced. You could in theory alias Docker to Podman.
Or pod bandedocker and then just run it and No one would know the difference. The commands are the same. The syntax is the same.
And that's intentional because Docker really did create the standard for how we interact with these things and so Podman is using that same standard.
From from like an API layer. You know but not not but the implementation. Different. The podman commands are great that helps system is really really awesome.
But like everything we do, it seems like with the command line in Linux and Unix systems, there is a whole alphabet soup.
Switches and flags that we can pass into these things to make them do what we want and they're necessary.
Maybe if you're a an application developer and you're developing 4 containers. Maybe you don't want to have to learn the whole alphabet soup of this, you know, weird container thing.
Can't you just, you know, stick with what you know and and find a different way to easier way to deal with the container part and that's one of the big reasons for bringing along originally Docker desktop.
But then Podman desktop as well to, not force developers and to use if they're not, you know, command line heroes.
To not force them to become so because that can really slow folks down. And and doesn't make it you know terrifically helpful.
For me personally, I'd much rather stick with the command line for my for my general work. I am when I was hiring people, I, my final interview question was, was always a silly one and it was, you know, which editor you prefer?
Is it, is it Emacs or VI and there's only one right answer in my opinion and it's DI.
So that's more about me, but bringing a tool like, Docker desktop or Podman desktop to these developers that may be weren't you know so comfortable using the command line.
I've been doing Unix, I, you know, started out as as a, and then moved into Linux pretty quickly.
But what about our Windows friends or folks that, you know, are just growing up and writing software, whether they're doing PHP or whatever, and they don't, you know, they're not command line here with.
We don't need to make them so. It's kind of the point to all of that.
So. That's kind of the idea with Podman desktop to create a graphical user interface that can help you do all of these things.
But do it with a GUI. I will totally accept as valid all criticism that this slows you down, that you can do it faster on the command line that you can automate the command line.
All of that, 100% agree. That's typically how I do things. As well. However, I said that doesn't work for everybody.
So when you think about this, if that's not your workflow, if you are a command line hero.
If you're using the One True Editor VI, that's awesome. Keep doing that.
But not everybody is there. And so, so podman desktop again, I saying we're trying to shrink that distance between developing on our on our laptops and shipping code that other people can actually use our businesses can get value from.
That's the idea, shrink that distance, give people tools that help them, don't make them use, you know, the hammers and saws.
That we've all grown up with. And but it does all the things. So you can, you know, build and run and inspect and push and start and stop.
I mean, actually does some things that are not obvious. From a from a Docker perspective or a Podman perspective, meaning you can actually create a pod.
With Podman, not just a running container, you can actually generate the YAML you need to deploy into a Kubernetes platform.
I'll write out a podman. It'll say, oh, there's a container.
Let me generate some YAML for you. Save you the typing, save you the going to have to look up the YAML spec and, you know, figuring out what that is or copying and pasting from Stack Overflow and doing something strange.
So, it is actually really cool in, in a really nice interface. The the folks that are working on it seem to be putting out new versions all the time. They put out a new version.
I think it was yesterday or the day before. So it's certainly a project that is under active development.
Yeah, yeah, go for it.
Yeah, real quick, Chris. Yeah, I kind of went through the same journey of using Podman.
As I started I started with odd man more so than Docker but a lot of the examples for building containers were, you know, Docker, Bill, Docker, Ron, this, you know.
And then was able to say, okay, just change Docker to pod. And it worked up until.
You want to make 2 containers that talk to each other, which I think that's when you're at, you know, like a baby orchestration.
Yeah.
Yeah, so so compose can do that for sure and and and like Shawn pointed out compose It does get nuanced depending upon what you're doing.
There are some other things that you can do in terms of making containers talk to each other if they're running locally and not like you're not targeting a Kubernetes like system which is typically where my work My work stuff, my work, my day job ends up running in Kubernetes.
One of the things, Steve, I don't know if you've messed with this. Is actually creating.
A dedicated network with podman. And then putting the containers into that network that, might go a long way in terms of getting them to talk to each other.
I don't know if you've experienced that, but that might be worth looking into.
Yeah, I got to that point, but I. You may be touching on this little later, but I was.
I kind of got the impression, and you know, from past conversations with you and other. Other of your colleagues and different reading that,
The red hat flavor of Kubernetes includes the the CREO for the container runtime.
Yep.
Hi, And I got the impression that, the way podman does this orchestration is kind of aimed in that direction whereas container D or I guess that's the Docker.
Demon is.
Okay, so there's different run times. You know, you're absolutely right. So you've got run C, Container D, cryo, those are all implementations of a spec, done for particular reasons and and that's not really my area of expertise.
So I assume people have good reasons for doing what they're doing. Whatever that is. I don't think that that would necessarily keep containers from talking to each other when they're running locally.
But you know we can certainly you know take it off line Steve and and I can try and help you out as best I can With that, you know, you're more than welcome to send me an email and I can try and, you know, better understand the difficulties you're running into with the caveat again.
Yeah.
This is this is not Chris the red hat guy this this is this is Chris you're your neighborhood spider-man just trying to be helpful.
Right, but I but I think you said that. And you're, I'm probably talking ahead of you here, but.
You mentioned that, Docker desktop can. Help set up. Some of the YAML that you would need to take, you know, like 3 or 4 containers that you wanted to.
Right.
You're having a pod. It's called pod manager, hence podman. I think you're about ready to get to that anyway.
So I was just cut off.
Okay.
Yeah, so I'm gonna do a composed example for you Steve a little what a little baby one so Sean, you don't get too excited.
Yeah. Yeah, okay.
It's the little, composed, right? We're doing a youth group here. We're not, having a workshop.
Okay, and I'll show up and see what you got.
Okay.
You shutting up Steve is not possible. I don't think that's what I'd love about you, baby.
Alright.
Thanks a lot. While we're talking about the runtime, can I ask a question about the rootless thing?
Yeah, yeah.
So, so I know Docker runs like a demon, right? And then that's where, and then like the containers, which you said are like processes.
Do they they don't run in the dam and they're like spawned by the Damon, right?
They're spawned by a the demon process which is which itself is running as root and that's the problem
Okay, and so And so the thought being that if somebody escapes the container. They're escaping.
In the root.
Yep. Yep. That's a hundred percent.
Into the demon because they respond from the demon there also is route is that thing Okay, and I know that Docker has been like, you know, they obviously don't want Podman to have this like security story over them.
So I've heard some. Things that they've done to basically do the same . Yeah But I don't really know much about that, but.
But they're working on it for sure. Yeah, absolutely. Yeah, no. Nope, so and that's the great thing about open source like and that's why I love working at Red Hat.
It's why I love working at Red Hat. It's not like like You know, we came together and created this thing and we're going to compete with Docker.
We're not going to show you the the secret sauce. All of this is open source. I, if I am traveling and in a bar as we do.
And someone asked you at a cocktail party, what do you do? My standard answer is I sell free software.
Right? That is Red Hit. Everything is open source. Everything is available to see.
And so You're right that Docker is getting, is improving what they do because of podman.
That's a good thing. I would love to see them have parity with Podman. I'd love them to see that become better than Podman because then you know we get into this.
Virtuous cycle of better software for everybody. And that's why I love this job. That's why I like open source.
That's my whole gig. That's why I like working for Red Hat. You know, we, we compete, you know, as, and, okay, so I'm putting my red hat on now for a second.
We compete in terms of selling enterprise software, but at the end of the day, everything Red Hat does goes into the upstream to help everybody make everything better.
And that includes that includes Docker as well. So I am glad they're doing that. You know, the better secure our systems are, the better it is for everybody.
Strongly.
Yeah.
Hey, yeah, Chris, quick question. We can back up a quarter step. It seems to me like there are a lot of system functions that require elevated privilege like networking configuration and stuff like that.
How does Podman do it if it's not running as root?
That's, that's a great question. So that comes into, that those. Namespaces that it creates.
So in that process, it ends up creating a separate process namespace, a separate networking namespace, a separate.
Storage. What are the other? They're like 5 main namespaces, right?
I forget what they are. Again, not exactly my day job. Easy to look up if you guys are doing a Google on this.
So what happens is it creates that ice that those, those separate namespaces. So let's take process namespace for an example and then I'll come back to the networking bit.
When you When you run a container. And it is, it is spawning a process. If you log into that container, if you SSH into that container, which which in its heart of hearts. And we'll see this in a minute.
In its heart of hearts, that container believes it's a Linux system. There's no way you're going to convince it otherwise.
It fully believes it's a complete Linux system. If you do a you run a PS command inside that container.
You're going to see a process ID of one for that container. The root process. If you, now remember this whole container that like I said believes in its heart of hearts that it is a full Linux operating system.
It's a full server. If you run that same. PS command. On the host.
On the server that's actually running the container as a container. If you do a PS command there, it will not be one.
You'll it'll be a process spawned by the user that ran it will not be one. You'll it'll be a process spawned by the user that ran it.
So in my case, it So you don't have a process ID of something other than root. And so that's where you see it's not the container fully believes it's root.
It's just wrong. It is not. So getting back to the networking bit. You'll have all the same constraints that you have.
With with networking and Linux things so with ports lower than 1024 for example right they they require privileges to open those up like 80 if you're gonna do Apache 22 if you're gonna do SSH all of those types of things.
All of that still true. One of the things that containers let you do, and this is back from the Docker days as well, is do a port mapping so that you can actually take local host, you know, 80, 80 and map that to 80 inside the container.
You can run 80 inside the container because it believes it's running as root, it's wrong, but it believes it is.
But you can't get to 80 from outside. And so you have this port mapping concept. If you're running it on the command line dash p and you'll give it, you know, 80, 80, 80, colon 80, just like we do with SSH.
To map those ports. But if you do need to run with Livated privileges, it is certainly possible to do so.
The best practice at this point is to refactor your software if you can to not need the elevated privileges, whether you're running it strictly as containers or you're deploying that in some sort of larger container orchestration system.
Like Kubernetes.
Is that so you're saying namespaces, but I've heard C groups be used in the same context for the same thing.
Yeah, see, yeah. So since I've got my slides up, I will let you guys do the googling and then you can, you can fill it in for me, Sean.
So it so containers based on we need we need namespaces control groups. Selinux and then there's one more that I forget.
Off the top of my head. Mostly I'm thinking about podcast. But yes, so control groups.
If you've got the you know the google up right now you can tell us exactly what control groups do because I forget.
But it's a way of isolating these processes. Oh, and then the other one is, Shoot, there's a way of constraining the amount of resources your container can use.
And that's another, you know, Linux specific thing. That's helpful when creating your isolated processes.
Okay, so I did Google it and yeah, see groups are limiting the resources and namespaces Provide a process with its own isolated view of the system.
Such as its own file system, network, hostname, and more.
Yep.
Hey, I was pretty close. So if you dig into those. If you look at, there's like 5 or 6 Linux namespaces.
So you've got, you know, process and network and storage and, you know, what whatever the other ones are.
All of these get created as part of the container and that's why it thinks it's running its own system because it has its own process tree.
It's not It doesn't see the actual process tree of the server it's running on.
That's a really interesting way of keeping these things isolated.
So we can park on the slide for a while. Really the the point of this slide, not to belabor it too much is it can be hard from developers to go from laptops to something like Kubernetes.
They don't have the skills. It's a lot to learn. And can we, can we help that out?
Can we make it easier for people to do? Why is that? So we talked about base images. I confess that I use Docker Hub.
Sometimes I'm gonna do it today. Shouldn't do that, I don't think, with your production images.
You want to bring those if you're using even from Docker Hub, you want to bring them internally and then stand them and do that type of stuff.
We're not gonna do that. We're on we're on the left side over here in local Devon.
Low node security. Really true. We're gonna use Docker Hub.
As I said, we'll do, I think I've got a compose example that we're gonna do.
That type of stuff. And then when, when you take all of this, so you're, going fast and developing.
And then you. One run inside, you know, something big or a big, you know, Kubernetes orchestration thing, whether it's EKS or AKS or Open Shift or whatever you're doing.
You're gonna have a different process. Your, your security teams as an enterprise are not gonna be real happy if you're just pulling stuff randomly from Docker Hub.
So you're gonna think about different base images. You're gonna want to use your own internal image registry.
I'm Red Hat what has one called Quay, but there's lots of them. You can use artifactory.
You could use harbor, right? There's lots of good internal registries. That you can use running things rootless as we've talked about quite a bit.
Needing to understand and leverage YAML to get those deployments. To happen, they're, different are, you know, back in Way back in this in this early part of the talk, I was, you know, we said.
One of the reasons that we wanted containers is because it's sort of made our development environments look like our production environments.
And it turned out that sounded really good. It didn't actually get as close as we thought. It was going to do.
And so we're going to try and do with Podband desktop like I said is shrink that down a little bit, make it a little bit easier, bring Dev and what we're doing in production.
A little bit closer together.
And so, you know, lots of different ways to do things. We've got a CLI, Podman desktop, which is a really good tool, I think, for the folks who like doing, GUI based stuff, APIs, Kubernetes.
Red Hat's got some really interesting things where you can run containers as a system D process.
Which is really neat so you can treat them as if if I know some people hate system D that's fine.
Not doing a commercial persistency. If you happen to like that type of stuff, it's kind of cool.
Makes it part of, you know, behaves like all the other system D stuff.
And then if you're using modern versions of either Fedora or or ROW and you like the web-based console pod.
I'll actually, incorporate into that as well. So you can use podm, you know, really across.
All of these different places however you like to do your development.
And that's what's kind of neat about it. So Podman desktop is going to span this whole thing from just the container based CLI stuff.
You know, we're doing, we're doing Linux processes. All the way over to we've created a bunch of YAML and we're running, you're running at scale in Kubernetes, Podman desktop can help get that done.
So it's interesting to look at how the things built, I think. I like understanding where my tools come from.
So when you look at under the covers as I mentioned earlier if you're not running a Linux type thing, you need some sort of virtualization, whether it's Windows or Mac and they're different virtualizations obviously.
Where you can then run a Linux VM as an implementation detail. We don't have to care about that too much.
But that that's what's happening on my Mac. There's a there it's called Podman machine actually.
Docker does the same thing. You're running a Linux VM under the covers so that you can do your thing if you're running it in Linux though you don't need that you're just gonna run natively with because you don't need a virtual machine you've got a Linux operating system that you can spawn those container processes directly from.
So that's under the covers. On top of that, these guys have used electrons. So if you've ever used VS code, I think BS code uses Electron, but it's a really popular set of libraries for.
Building desktop applications that let you do things across platforms so that you can essentially have the same code for your Windows and Macs and Linux system.
It's pretty handy that way. And then it's styled. With CSS and some some reactive stuff.
So it's pretty responsive, I think.
And extensibility. So lots of different things that you can bring into this. You can you can use various different flavors of Kubernetes.
You can use different image repositories. You can use Docker extensions. Which is pretty interesting.
I mean, they get you some of the way there, you know, like Shawn's used cases probably not all the way for him yet.
So that's lots of extensibility that you can do customizations that you can bring to it.
And yeah, that's kinda where we are. So we're gonna have some better tooling, hopefully, bring some Kubernetes capabilities, closer to the developer so that they can they've got less friction when trying to get into production.
And if you're choosing the best Kubernetes, open shift back to commercial. Certainly tightly integrated with the red hat stuff, but you know, that's, just more commercially than or commercial than, than anything else.
It's, tightly integrated with an AKS or an EKS or whatever. So.
Easy to do. Is it better than Docker? I think Docker is coming a long way.
It does really because of the success that Podman's been having. So we've got, you know, a really at this time, I think a better security posture.
One thing that is I think better it is open source and community driven so Well, what I mean by that, like everything Red Hat does, it's open source.
However, you cannot buy Podman from Red Hat. We don't sell it. It is a community project.
There more developers than just Red Hat working on this thing, which I think is great. You know, I like a heterogeneous development environment.
I don't I don't like projects where there's only you know one company and they say they're open source but they really don't accept contributions all that much.
Bye. I like the way Red Hat doesn't. If you do, if you are running Podman or Podman desktop on REL systems that Red Hat that you do have Red Hat entitlement for Red Hat will do a best effort support for you on that, which you are more than welcome to run Podman, Podman desktop on on anything you got and it is community supported
community developed community supported. Says it, yeah, comes comes with, and then we are working to be compatible with all the Kubernetes, not just Open Shift.
Make it easier for developers to get there. And then bunch of links. Alright. So that's it from a slide perspective.
Any questions before we actually try and do some things?
Hey.
Yes, this is Stan. I don't have the best Google. Who the ability there are always.
Rely on. Phil to help me with that. But I couldn't find, I found very little on Google doing a Google search on pod man.
I mean everything I saw there was from Red Hat. And I always like to go to Wikipedia and find what might be there first before it gives me an idea of a general layout of things.
Before I dive further in. And I didn't see any specific thing on Podman on Wikipedia.
Which usually tells you where the websites are, where the source code is, where the license is.
So what is the open source license for Podman specifically? Do you know?
We can go to their website and find out.
Go, okay, I couldn't find the website.
It's podman.
Bye.
No wonder I couldn't find it. All these new Thanks. All these new things, I, you know, I/O and dot meet dot pickle duty and everything thing else.
Indeed, I agree with you. So this is the website. This wasn't going to be part of my demonstration.
But yeah, so I've got the website up here. This is the podman website. So I'm sure that the licensing questions are answered in here somewhere.
I just, you know.
Yeah, yeah. Oh, it would have been nice on Wikipedia if they'd pointed to this website.
I mean, I couldn't find it. You know, without going nuts.
Shaun, can you help me out there? Can you find Podman on Wikipedia?
Certainly.
I'm delegating. Like, alright, moving on. No, that's a great question.
Though like, how do you find resources for things that are relatively new because you're absolutely right. Docker own this space for more than a decade.
Podman is the new kid on the block. It's having a lot of success.
I like using it, you know. And Sean will attest to your mileage may vary.
It's definitely an interesting thing. I wish I could move this toolbar, Hide. Oh, hi.
Can I hide? Video panel high floating control oh there we go love it all right No more floating controls.
Okay, so we did that. Let's actually start doing some things. So first off, let's take a look at, okay, backing up.
I haven't used Zoom in a while. Are these sponts like ridiculously tiny for you guys?
Yes, yes.
Alright, okay. So let's see if we can do. A little bit.
Gary happens to be our token blind man. When Ed is not here.
Yeah.
Alright, so how's the command line? Is that? Relatively visible.
It is.
No.
It went away.
Hey, No. There you go. That's a little better. That's a
Yeah, it works.
Okay.
Okay, okay. And so this is podman. This is the Podman desktop GUI that I was talking about.
I'm gonna try to make this bigger. That it works. It looks great on my on my screen.
So we'll figure out, we'll see if I can actually make some. Some font size changes.
So let's make this spont bigger. We'll make it 25. I actually haven't done this before because I don't you know I like a smaller font, but had always.
I'm on, I'm on Windows and I was able to do control shift plus and it was got it zoomed it all in.
Hmm. Is zoomed it all in? Right, let me try that. That's outstanding.
So maybe try that. Might be different on Mac though, I don't know.
Let's try that. Yeah, yeah, so, oh yeah, we're getting bigger. Look at that.
Alright, how about you?
Oh yeah.
Cool.
Yeah, baby.
Alright, so we'll be doing all kinds of scrolling. Thank you. For that pro tip, I love it.
Okay, so when you launch. Podm and desktop. You're going to end up with the whether they call this thing a dashboard, I guess.
So you've got some various links here. You've got the link to the website and the installation guide.
Docker compatibility guide for Sean. Can join the community and do stuff. You can see I'm running a developer sandbox.
That's a Kubernetes instance, a bunch of extensions that I've installed.
What I wanna do now is just sort of go through like the desktop itself and then we'll start doing things with it.
So that's my dashboard. Up here. The next thing down here is a section for containers.
We don't have any running containers yet. We're going to fix that. But this is where you would find containers.
The next section down, this is pods. We don't have any running pods. I tried to clean everything up before starting this meeting, but we'll have some pods later on to look at.
This is images, so container images that will be stored locally or things that perhaps we've pulled from.
Docker Hub or other repositories. And then if we've mounted any volumes, if we're if we're either reading data or persisting data, we could create volumes or when we, Used containers that create volumes for us, they will show up here.
You might have noticed as I jumped way down here, we've got a settings button on the bottom left.
Where you can do new resources this podman machine here at the top. That's the VM I was talking about.
So you can you can size that thing, you can give it more CPU and memory and disk and that type of stuff as you would expect.
Kind we're gonna use kind to create a locally running instance of Kubernetes. It'll actually run in Podman as a container, which is really
Well, that and, machine is that. Amd, 64 or?
So that is the, oh, that's a great question. What is the architecture of that VM?
I don't know.
It's on Windows it installs like a fedora. I think it like takes the user land of like the fedora one of the like one of the fedora containers installed as a VM.
That would make sense.
What, but I don't know how does that get updated like how does the cause cause of what I assume will happen is if you have that admin machine installed long enough.
Eventually the version of Podman client on the host will get updated to where it's no longer compatible with.
The pod man running on the machine. And so I wonder.
Yep. Yeah. So what you would do typically is you would you can power off your Podman machine, shut down the VM.
And then either. Upgrade your pod, man. So I'm using a Mac, so I'm doing Homebrew for this.
So it just brew, you know, install Podman or Brew upgrade podman. It does that.
Same thing with both with Podman desktop as well as podman composed. So I can do all of that from a Mac perspective on Homeb.
You would use whatever package management would be appropriate. For your particular system. I, I don't run Windows, so I, I don't have a whole lot of advice on that, but conceptually the same thing.
So you would do that you would shut the machine down, you would install your new version of Podman, you would install your new version of Podman, and then you would start the machine down, you would install your new version of Podman and then you would start the machine backup.
Yeah, but I mean like inside the machine, right? Like, cause let's say inside the machines running like Podman, you know, some old version.
Right.
Cause you, you, you created the machine like 2 years ago, right? But you've been continually upgrading Podman client on your Mac.
And now, like at some point, there's gonna be a breaking change to where your Mac. Client can't talk to the ancient version running inside that machine, right?
Yes.
So you would do this delete function, you would delete your podman machine and then recreate it.
Yeah, that's what I've been doing too because I never there's no data in there, right?
Yep.
That's like, well, there could be, right? If you did mounts and stuff or.
Yeah.
Anything you care about, you should put inversion control. If it's source code or an image repository if it's a container image.
So you should be able to recreate everything you need.
Yeah, you're gonna learn real quick if you should have created a volume mountain, then whatever you go to do that.
Exactly. Yeah, data is gone. Whatever. So yeah, so this is this is like, you know, this is developer, Right, so in my mind, I always look at developer tooling is sort of being ephemeral.
In and of itself because you are you're always churning you're always installing new things you're tearing it down you're installing something that doesn't work all of that type of stuff so you leverage your other tools your get repose your image repositories.
To save that stuff off. Make sure you've still got it. So we've got our settings here.
We've got our resources. A proxy if you need to do that extra registries.
If you need to do that, I've logged into Clay. We'll use Docker Hub anonymously, but you could, use those.
You can add extra registries if you were going to use, I forget what Amazon calls theirs, but whatever, you could add registries.
You can install authentication providers like if you were, you know, large company in rolling this out, which, we see a bunch of.
Various extensions. I think I've installed pretty much everything just to kick the tires on it.
Docker specific extensions. I have not done this. So I don't use, docker.
Per se. And then, you know, all the preferences here. So editors and fonts and terminals and things like that.
We'll see how badly I messed this up trying to make the font bigger. Also, before I forget, down here in the bottom right, you've got some other things.
This tells me versions and whatnot. What I really care about is the question mark which is the help section.
Cause I always need help. So you click on that guy and then you've got lots of good helps.
In terms of doing things tutorials and and Discord channels and all that stuff. And this, Steve, this might be a great place for you.
If you wanted to. You know, get on the various chat channels and see if somebody there can't ask answer your question.
I would expect that you'd find better experts than I. With that.
And speaking of the chat channels, Andrew, put a comment in there. ECR is AWS.
Thank you very much. Elastic Container Registry, I'm guessing.
Every time they use elastic, I think it bean stalks. I don't know why.
I guess that's me.
Yeah.
That's correct.
Awesome. Alright, so let's actually do some stuff. This should be fun. So we've got our container.
We're gonna and what I'm gonna do is we're gonna keep it pretty simple but I do want to kind of build so we'll go like really simple and then work our way towards more complicated stuff.
So the first thing we're going to do, we're going to grab this. We don't have any containers, so let's run one and we're gonna use our CLI to do that.
I'll just paste this guy in here. And if you were a docker person, this would just be Docker, run.
Pull out the image. So that was awesome. So what you can see here if you haven't done containers before we Quay is a is a container registry meaning this container has been built it's a container image sitting in this registry and we said podman please run this one at this address.
Equated I/O podman hello. Pulls down that container image and then it runs it and it does what ever that container image wants to do.
In this particular case, my wife is laughing at me. I'm doing, I'm hand waving and talking in an animated fashion, which just totally cracks her up at.
70'clock at night or whatever time this is. So what this container does is it it really just prints a little bit of ASCII art.
So it runs out, it prints the ASCII art, it puts the project website and and whatnot down in the logs and then it exits.
That's the whole thing. That's all it does, right? Just to just a hello pop man.
I'm with the little seals or otters or whatever those things are. The little creatures.
So we do this, why? Because we wanted to first and let's exercise the GUI a little bit and see what we've got.
So we're in our container section of the GUI and we see we have one container, we can see that it is not running, it is exited.
As it says, it gave it a default name. You can give your containers names, you should give your containers names because I have no idea what a cranky Jennings is and I have to look at the image to remember what the heck I did but you can give them names.
Are you, we could rerun this thing with our play. We could throw it away. We've got some other actions that we could take, look at logs, generate cube files, which could be some, things like that.
If we click into the image here, so this is the log. That's exactly what we saw in that terminal.
It this is what it would output. If we, and so when you're a developer, logs are super important.
So it's nice to be able to have a container even if it's exited to still be able to get back and look at the logs and be like, why didn't you run?
Like, why did you crash? Oh, let's pop into the logs and see. As an aside, everything that we're gonna do here in Podman desktop, you can do on the command line.
And as I said, you can, if you're good, if you're a good command line hero, you can do it faster in the command line.
This is for folks that don't know, oh, I could run podman logs and give it my container name or container ID.
And see the exact same thing. Absolutely could do that. Probably would do that. But let's all pretend that we're, we're not command line heroes and we're.
We need a GUI tool to help us out with these things. To tell us even, hey, there's a logs out with these things to tell us even, hey, there's a logs option.
Like, how do you even know that's a possibility? Like, how do you even know that's a possibility?
So we've got our summary. This ID, that's the ID of the container itself. We'll go back here for just a sec.
Do a pod man, PS dash a. It's this ID right here. So it's this is the ID unique identifier of that container.
Same one here. So we're getting the same information just doing it differently. We're using a GUI at this point.
We can inspect our, image. Here, so we've got again the ID when it was created the path of that executable all of the arguments.
Various states on it so we can see it's executed. It is not running. It's not paused, etc, etc.
I'm the image that we use. So this is a hash of that image, not just the name of the image, but the literal hash of that.
So it is immutable and unspoofable. As a shot 50 and unique as sharp 56.
Hashes tend to be. We haven't ever restarted it. So like lots and lots of information that we could get, inspecting our container.
This might be helpful for having problems. You know, why didn't something happen or, you know, whatever? You jump right in there.
Very easy to do. If we were going to generate the YAML to run this in Kubernetes.
This is all you need to do. You run your container. You click on the little, the little cube menu and boom, there we go.
We can just grab this YAML and do a QCTL apply dash F if you've saved it as a file or do a file redirect, and you will have this pod running in Kubernetes.
Now in this particular case, because the container is not running, we can't open a terminal to it.
You can't. SSH, you can't connect to a process that's not running.
So let's do another container. But this time I think we're gonna leave this one running.
So let's do that. We're gonna create this one then from the file system. Why?
Because we can.
Alright, so here is my Docker file on my file system. And we are just, let's give it a better.
Give it a better image name. Let's call it.
From file. Okay. Alright, so we're gonna build this image. We have a doctor file.
It's gonna tell us what we what it should look like. We're going to build it.
So you can see we're pulling from, if you read really quickly, we're pulling from DACA I/O to get the Alpine Linux, it's back again.
And installed all the dependencies that we need, engine X and a bunch of other packages that this particular application needs and we built that image.
So we can say we're done here. We have a container image that's been built for us.
But now what we'd like to do is actually run this container image. You notice it dropped us into our images.
Here we have Alpine is our base image. That podman hello that's the ASCII art that we generated and this is the image that we just created a few seconds ago.
Go ahead and run this guy.
Now, when we're going to run the image. Remember when I talked about, we're all been doing Unix and Linux for a long time and we're used to the alphabet soup of all the different command line options that you could pass in to get exactly the right behavior that you want.
For people that don't like that. Here's how you do it. There's a nice form and it kind of walks you through.
Let's create names. So let's call this guy. What did I call it? From File, from file container.
We, we could change the entry point of the command. We can do that port mapping that we talked about.
So the inside the container port is 80. We're actually going to be accessing it on port 9,000.
We could change that here. You can do advanced stuff. Around restart policies and things you could change the networking, add some TNS, do some hostname stuff, do some security things like if you were going to turn off.
On the security and run it as a privileged container. I'm not going to do that. What we could we could do all of these things without having to know the alphabet soup of all the possible flags.
Right, we got it. We have a nice. A nice GUI that will allow us to do this.
I like that flag that said make root file system read only.
Yeah.
Will, will the gluey create the? In the logs, the those options so that you can recreate them in the command line.
Oh man, that is a fantastic question. I don't know. That's a good question.
Let's do this. So let's see if we can answer that question before we go peek in it.
So you can see it's running by the way. We cover our file from file container. It's running on port 9,000.
We're taking a detour to answer that question because it's a fantastic question. Let's do.
Good. Good.
Stan doesn't remember it.
Yeah.
How are you? All the flags.
Yeah, he was asking if, this tool will. Build the command line. Yeah, yeah, have all the right flags in it.
Good.
From the logs. Yeah.
So yes, sort of. Okay, so let's look at this. I'm gonna expand this window a little bit and maybe it'll be able to see it a little bit better.
Okay, so here's my terminal. What I ran here was Podman PS and let's do this.
Okay. Alright, or do Podman PS. So this is like Docker PS.
It's saying show me all the processes that are running. I didn't if I do PS dash a it's saying show me all the processes that are running.
I didn't if I do PS dash a it'll show me the containers that have accident.
PS just shows you the regular containers. Again, alphabet suit. Alright, so what we've got here, we've got our container ID.
That's awesome. We've got the image that we used to create this running container. And really when you think about a container, here's the here's the I think the most accurate way of saying what a container is.
It is a running instance of a container image. The container image is actually the real hero that's doing all of the work.
The container itself, that's just a running instance of that container image. Which is called what I called it from the from file image and then the latest version of it.
So here we go. When you asked about the various flags, we can, it's not creating the command line per se, but we can see that it is doing a port mapping.
So this would have had a dash P, 9,000 colon 80. On that and then with the the last bit that my lines actually wrapped where it says from file container, that's actually the name of the container itself.
So I don't know. And this is
Is, can you show the log what's in log?
Hmm, yeah, let's do that. Now we can do it from the other side too, but just for fun, 5 analogs will be command line heroes for a day.
Yeah.
And what would be interesting too is if you did a pop and diff with the base image and then the currently running a image.
Yeah, so there's nothing there's nothing running in these logs currently. That's a really good question.
I'm gonna I will try and run that down.
Isn't it from, file image? Isn't the pod isn't it? Cause you have 2 different names actually.
Oh.
From file, from file image there, but then you put from file container and the
Well, that's my running container. This is the container that's running.
Okay.
Hey, they're not good names. Sorry.
This is my man support tab completion error like Dr. Does.
There is a way to do that. Yes, I don't I don't know if I have if I did that let's say Pod, man.
Yeah, look at that. M.
Well, not like.
And hit tab
No, I'm saying do pod man log space F tab. And as long as your, string is unique.
No. Yeah, well, you know, backup this hit F.
. If
Oh, just like that and it'll see what it takes. Yeah, I need, I need to specify one of them.
So you could.
No, what I'm saying is, you do is say log space F.
Yeah, and hit that. Yeah.
Or Yeah. Yeah. Or have, yeah, enter.
Alright, so that's when it comes up. Okay.
Okay, so let's try that. Oh yeah, look at that. Nice. And that's our default, right?
Cause that's the one that was last running. So yeah, handy tip, handy pro tip.
Thank you. I love working as a community.
No, that's Yeah, us, Greybeards, no tab completion first.
Okay.
Yeah, no, that's good stuff. I love it. Alright. So we got, we took a nice D to where we found out a little bit, but we didn't answer the question.
So the question was, and if anybody is super interested, I'm going to try and remember this to look at, look it up on my own.
I think it's a great one. I'm going to try and remember this to look at look it up on my own because I think it's a great one.
If you do some custom Can you then sort of. Reverse engineer what all the alphabet soup would have been.
That's I mean that would be that's kinda what they do with the YAML stuff so it
Does podman desktop have its own logs
Oh, good question. I don't know. It's probably logging somewhere, but I don't know.
Yeah, I'd like. As an example, GR sync is a graphical input. Implementation of our sync.
And by following through the graphical, it, it. It shows you what some of the different options are because it then outputs the command line stuff.
As it as it's created when you run it. And that's the kind of thing I was thinking of.
Yeah, no, and I think it's a great question. So Podman desktop. Is really only going to do Podman things.
Right.
It's just making it, you know, it's just providing a GUI interface to that set of API.
So at the end of the day, It is running. you know what we could do here?
Let's do this. Let's just look at our process tree.
Whoa.
That's just me on a Mac, let's see.
Okay, let's do, see if we can find this thing. Okay, Oh, you got the answer?
Oh, I found it. Yeah, go to images in Podman desktop. Oh, sorry.
I'm never, I don't want to, from what you're doing right now.
Well, I'm just curious as to what I've got here. Okay, so let's see if it actually.
There was anything super exciting, then we'll get the official answer. From the community. This looks more like pod man machine type stuff.
Alright. Oh, you know why? Because this is actually running in Podman machine and it's not running on my Mac so I'd have to get into the machine to run the PS command that I'm trying to do.
If I was on a Linux system, this would have given me the answer. Okay, yes, what is the answer?
We're going to go to
Yep.
Go to the desktop, go to images on the left. And then click on the one you want to see the changes to and you can go to history.
Oh yeah, the history.
And doesn't this everything that was you asked for how to like make a Docker, a Docker file from.
Well, I think this will give us the Docker file, which is awesome. And I think the The sort of the question was maybe maybe I have it wrong.
What's the command line version that did the same thing?
Yeah, so but this is perfect too. So this is actually another thing which is super helpful. That you can look at how this image was built.
I was.
And you start, it's interesting if you've ever looked at a. Docker file, they usually do from and then they've got, you know, the stuff.
The way the history worked because in we didn't go into all this stuff about containers. Containers are built in layers.
Each one of these lines is a layer in your. And you read this. Typically from the bottom up compared to the Docker file or the container file which you're gonna read from the top down.
So good stuff there. Yes, thank you for pointing that out. All right, so we
Yep. Yeah, I may have kind of started this path when I asked about the, I made a comment about there was a an option to make the volumes or the root volumes read only.
And somewhere you showed like some, maybe on that the cube tab there.
Yep, it's the cube, Tab.
Yeah, I was wondering if that. If there's a flag, they wind up in there to where it would run on a Kubernetes instance with.
The root volume being read only, is that a flag if you can scroll down?
Is that all there is to it? Okay.
This is the end of the. Okay's really small. Thankfully. Yaml gets ugly in a hurry.
That's a good question. The way Kubernetes does their volumes is different. So when you're running in Kubernetes, you're going to create a persistent volume.
And then that will present the storage and then the application will use a persistent volume claim. None of this is super relevant to Podman.
Ness. So it's a good question. I don't know the answer to it.
But certainly a super good question. So let's see, what was I going to do with this guy?
I have a little, I have notes over here on my left. Alright, so we ran the image.
Okay, so what does this thing actually do? So we went back to our, can we go back?
We've got our 2 images, one that exited, one that's still running, because we've had some awesome discussion.
About this and I'm learning a lot from you guys, which is fantastic. All right, so we popped in here.
It's not doing any logging. We looked at the summary. We looked, we inspected it, looked at cube.
We'll come back to terminal here in a second. On the upper right though, we now have, some new options.
So we, we can, do a stop. We can delete it. We've got our little rocket ship guy, which will deploy it to Kubernetes for us.
We have this little guy, which is open in a browser window. And this is really, remember.
The reason I like this is from a developer. Perspective. So let's say I wrote some code.
I created a container image. To exercise this code and that it's a web app. Let's see if it's actually working.
So I just want to open this thing in a browser and see what the heck's going on.
So I clicked on that little. Square with a arrow inside. I'm gonna open the local host port 9,000.
We opened it up. Hey, it works. Isn't that super exciting? It is super exciting if that's what you were expecting and it is.
So we know that that we were able to grab that container image. Build. A container and run that.
Container and then actually exercise the code in the container. Kind of cool there. The other bit is we can now look at the terminal.
Because we are because our container is still running. This file is still still running. So when I clicked on terminal, essentially what that did was pop me into this running process, which fully.
It is a Linux system. So if I do. Hey, you name. Dash A, for example.
Yeah, it thinks it's a Linux system. It gives me the kernel version and times and the name if I do a PS dash a
So you can see it thinks it's running a root process as or the process ID one as rude.
If we were in the pod man machine. And we did a PS and found this process, this container running as a process on that host, it would not be running as root.
So, just a little bit of a interesting there about running as ruthless. It fully believes it's root.
It is not. Alright, so there's that rascal. Let's do another one.
We're gonna pull an image. From our podium.
Here we go. I'm gonna pull an image. So we're gonna use something from Quay this time.
Alright, so first thing we do is we need to pull this image down from the Quay repository.
Okay.
This would have been the time to ask questions. And I miss type it. Quay. I/ORH developers.
Quarkus hyphen demo one Let's find out, let's see, looks right.
Add this again. Wait.
Okay. Demo.
You may not have success pulling this image, which is okay. We have other things we can do.
And it could be a typo I'm not seeing. I don't know. I know what it's upset with.
Yeah.
If you pulled it on the command line with Docker or Bodman desktop know about.
It does. Yep. It actually looks for exactly the same stuff. That is a great idea.
Let's try that.
Yeah, mine too.
Alright, on my machine, I got an internal server error, 500, so. Hey.
My. Might be a quick thing. I can tell you it did. Oh, hey, look at that.
I found something here with pod. Alright. So, oh.
I think RH developer doesn't really exist.
Did I have singular? That put singular?
No, well, our developer, I tried single and plural.
Yeah, so okay, so we pulled it here so we can do.
Okay, they work for me too, so it must have been a. It must have been something with Quay for a second there.
Yeah, okay, yeah.
Could have been. Alright, so we did Podman images. We have our corkus image there.
Corcus is a Kubernetes native Java. HIPAA framework, all right, so where's our corkus?
Here's our corkus guy. So what we want to do now is run our image. So we can do that.
We'll just start this rascal right up. There's our corkus. I did not give it a.
An image name. I forgot to do that and the way Podman generates its image names.
They are sort of a randomized combination of an adjective and a famous scientist. So this is determined bore, which I think described Neil pretty well, actually.
Alright, so we've got determined B. We can we can click into our image. So this is the this is the log from a Java app.
The frameworks called corkus. So very similar to how spring booth if you guys have ever done spring booth it prints quite a bit.
On there as well We can open our website, make sure it's actually. Working locally.
Yep. So that's the tagline for or corkus supersonic subatomic Java.
It is Kubernetes native. Good if you're if you're a Java developer definitely worth looking into.
Super, super neat stuff. All right. So now what we want to do, we actually want to run this thing in Kubernetes.
So we've got our app, we have our container, it's running, we've got our, we've got our logs.
What I'm gonna do is take my little rocket ship guy here, which is my deploy to Kubernetes.
And we're gonna fire this off. So what this is going to do, it created some YAML, as you can see up here at the top.
For a pod, it's going to use that same. Image repository out in Quay, hopefully it will behave itself this time.
It's going to map port 80 80 on the host to 80 80 in internally. And then hopefully start this guy up.
So I'm gonna hit deploy and this is gonna deploy. Fingers crossed. Alright, so.
Yeah, I like there's another button there that restricted security content. Where you can check that box.
Huh.
That would update the Kubernetes manifest. To match your container security.
Yes, and that's that's a big deal when you're looking at deploying the open shift as your Kubernetes platform.
This is already deployed and running, by the way. That's that's as long as that took.
Right.
So let me let me get back to that part and sort of do my what I was gonna say here.
Remember, we're developers. What we're trying to do is get the software that we've written on our laptops into Kubernetes.
Without learning anything about Kubernetes. Like, I don't care in this scenario that it's running in Kubernetes.
My boss told me, write your software, you're happy with it, create an image, that little rocket ship guy, hit that and then go look and see if it's running.
Like that's all I had to know. I had to basically know nothing, right? I had to use a button in the GUI to make this happen.
And it's happened and it's happy. And if we look at the logs, which we should do since we did that earlier.
Exactly the same logs. So super cool. We deployed it there. All right.
So security context constraints. This is a big deal for Red Hat.
Yeah, somewhere you had to configure. You're Podman. Desktop to know. The credentials for this open shift instance.
I did. Yeah, I did that earlier. Yep.
Yep.
Yeah. Okay, so is this, okay, this is not the sandbox. This is Open Chef dedicated or.
Nope, this is this is an open. So. Open shift the developer. Sandbox from from Red Hat.
So putting my red hat hat back on again. It is a multi-tenant open chip cluster that you can use to explore Kubernetes.
And and other stuff and it's free. Every 30 days your cluster is destroyed, but then you can just spin it back up again.
It doesn't have a ton of resources, so you're not gonna be able to do any Bitcoin mining or anything super exciting with that.
But it makes for a great case for I just want to be able to do any Bitcoin mining or anything super exciting with that.
But it makes for a great case for I just wanna, you know, can I get my app running in Kubernetes?
Cause this, this is Kubernetes. This is Open Chip. It's exactly the same Open.
GIF that you would find anywhere else. You know, whether you're running at on hat back off.
Anyway. What we did from the developer perspective, we're like, hey, my code's awesome.
Let me hit the rocket ship and get it into Kubernetes and I don't care about Kubernetes.
I don't have to care. And so it's running, we saw those logs that looked exactly the same on the command line.
So I'm feeling pretty good about it. I can hit this little bow and arrow guy here. I'm not gonna go into the ins and outs of open shift, but this is gonna open the URL for the app.
And I can click on it. There we go. Same thing. So we've got our determined, Niels Bohr pod up and running in Kubernetes.
So remember the point of this talk was, can I use Podman desktop? To accelerate.
Work I'm doing with containers locally. And get them into some sort of Kubernetes thing without having to know much about Kubernetes at all.
And I think this was a pretty good example of that. We move pretty quick with that. Even with me talking all the time.
Alright, so there was that. Let's run something a little bit more. A little bit more exciting.
So. Let's see. Oops, I lost my image. Here we go.
What happens when you're
Editing your notes and you forget to do something. Alright, so we're gonna deploy a A new image.
And we're going to do it. Hold an image. Here we go. Alright, so this is gonna be Redis.
Redis is a really popular key value store database. I'm folks use it a ton for like in memory caching.
There's a ton of great use cases for Redis. If you're not familiar with Redis, look into Redis, it's awesome.
Not a Red Hat product by the way, so this is not a commercial for redhead stuff. Redis is awesome.
I'm Lebrettis so this is, this is an in caching sort of exercise.
So we, deployed our, we pulled down our image. I've lost it where my red is.
Here we go. Let's go ahead and run this container. So we've been doing this a bit.
We're just gonna. Fire this guy right up. Now we have our. Red this container.
With objective Bardeen, I'm not sure who Bardeen was, but type of science he did.
But Apparently he was very objective. Alright, so now what I want to do, so we did the terminal and we.
What do we do with our terminal? We did PS. We validated that the thing thinks it's a Unix system.
Here what I want to do is do something a little bit more interesting and actually use the software that we deployed.
We're gonna so we're gonna we're gonna poke Redis a little bit. So So what we want to do here, so I hit the terminal tab.
This is log me into that running container.
So I'm gonna run Red a CLI. Red a CLI is, as you might expect, the command line interface into Redis.
So this is how you interact with your Redis stuff. As you can see, it's running on local host and it gives me the port that Redis is listening on.
So pretty you know this looks if you if you do this kind of CLI type stuff lots of systems have these things, databases, Postgres, Mysql, whatever.
All those guys. Alright, so, so we've connected to our CLI. Let's actually do some Redis.
So what I'm gonna do, so remember it is a key value store database. So what I'm going to do is I'm going to set a value to a key and then we're gonna we're gonna pull it back out and really what we're doing is we're just showing that we've deployed a Redis container.
We started Redis, and we're actually able to use Redis. So. We're gonna set a key and and their CLI as you can maybe see in the faint gray.
It's a really nice CLIX. It tells you exactly what you need. So, SET I have an ahead key, so I typed in a key.
And then now I can type in a value. So let's say we are.
We are slugs. And it took it. So that looks good. That's promising.
Next thing you want to do with your key value database, you've set a value. Let's go ahead and see if we can get it.
So we're going to say, and it tells us get. Hello, that's our key.
So in theory, if Redis is running fine in my container, I should be able to do a get hello and in fact it's correct.
We pulled out the string version. We are slugs. So super cool, I think. Nice to be able to validate that that is working.
Let's run another one.
Thank you.
Oh, another image. This will be HTTPD. Back to docker.
Okay.
The way that font is getting pretty small.
Yeah.
Yes.
On which on this part here. Let's see. Oh, no, that went the wrong way.
That's better.
How's that? Better? Okay, thank you for that. Yeah.
There we go. Way gooder.
I can't tell, so awesome. Thank you guys for that. Alright, so docker.
Or my notes. Oh, here we go.
Okay, so we're gonna pull down the latest version of HTTPD out of DACA.
Take just a second, we're quickly done. That was speedy.
Can't throw this person. Little bit.
What's that?
Alright, we're gonna run this container.
Do there's our oh exciting Heisenberg. They're probably breaking bad pants Awesome.
Okay.
Most exciting Heisenberg I had ever seen. All right, so we did that and let's go ahead and Again, we're just gonna open the website on this guy.
It worked, we already, well. Hey, I'm out of order.
Doesn't matter. That worked again. How about that? We're doing science.
We have repeatable results. Okay, let's do something a little bit more complex. So let's go over to our command line.
This is gonna be our Docker compose and this is where I start crossing fingers. With this thing.
All right, so we're going to do pod man.
Compose. And then we gotta point it at our compose file. We've got this guy and we want to do up and we're going to do a detach.
I think this will work. That's bound. Did I know? Okay, hold on.
. One
. S. Not found
Would, would, would, would, would, probably, man, space.
No, it's a hyphen thing. Let's see, brew.
Maybe I forgot to put it back on.
Oh, look at that. Always download the software ahead of time.
We're getting lots of pro chips tonight. Okay, let's see if this will work better for us.
Hey, there we go. There's stuff.
Okay, so now we've got a Docker composed running.
And now what we want to do, let's do a podcast.
We've got our various. Applications running. This is a Postgres database down here that we did with the Compose.
From our lovely friends at Chengguard. They are awesome. Let's go look at Podmandu.
Yeah.
And that font is big. All right. I need I need to sit back from this. Alright, so we're gonna view in containers.
Right, where is our podman composed? Okay, so notice this is a little bit different now.
With with Compose and and Sean probably a much better expert in this than I am. But one of the things composed lets you do is run is orchestrate containers locally so that you can have a number of containers inside the same compose file and then bring them all up.
At the same time because they're related and then they should run at the same time and they should die at the same time.
So when you look at our first set of images here all the way up to our friend Heisenberg, there's There's only, you know, there's nothing over here down here.
With this guy. We're getting this a little expanding thing. What is going on there? What this is showing us is that there's actually and notice the composed word after the engine X.
Notice this is now 2 containers running as a Docker compose instance. So they're both running right here.
I like how confusingly says one container right there.
Well, yeah, it's one here and then and then this one. Yes, it is kind of confusing.
The other thing just as an aside that bugs me to no end is
Where is it? I forget where it is. They use the word container instead of container image. Container image containers are running instance of the container image, but that's nit picking.
All right, so we ran some compost. So that was cool. Let's do, let's actually create multiple containers individually.
And smoosh them together. And then deploy them into Open. In a single pod, right? Because again, this is this is kind of the point where developers we're going to write a bunch of different things we don't want to know about Kubernetes. We don't want to know about Kubernetes.
So we just want to be able to get this done and move on.
The open shift is normally where you where you have the containers. Associated with each other.
Yes, so that's it. That is an awesome question. Open shift is I shouldn't have said open shift.
I should have said Kubernetes in this context. Confusing my day job. So open shift is red hats version of Kubernetes.
So back in the day when we just had Docker and then we had Docker Swarm.
To, you know, do more than compose could give us and orchestrate these containers and that was awesome.
And back in the day, there were other choices. So you had Misasphere, you had Docker Swarm, you had rancher, you had pivotal cloud foundry.
There were a bunch of different totally legitimate choices for running and orchestrating your containers. At scale for, you know, large enterprises, not just, you know, doing stuff small, but big enterprises.
They had a lot of choices and how to do this and they all they were all individual technologies. About a decade ago, this thing called Kubernetes came out of Google.
Kubernetes has really won the orchestration wars. If you guys will allow me that analogy with the Linux wars and the OS wars you know we Linux won the OS worse.
Real is probably one the enterprise. Linux wars. For the most part, at least in the States, Sousa is a little bit more popular perhaps in in Europe.
From a container orchestration perspective, Kubernetes now is the big dog. So Amazon uses Kubernetes.
Azure uses Kubernetes, Red Hat certainly does. And then even even other companies that had a competing orchestration tool such as Meisos or Rancher or I think Docker too.
They are now they are now all offering their container orchestration as a Kubernetes thing their version of Kubernetes.
So yeah, when you're gonna run your containers at scale, you're going to want to orchestrate them.
Using something. Kubernetes is the marketplace winner at this particular moment in time.
That makes sense.
Okay.
Alright, probably more than you wanted to know.
No, no, no, that's a good piece of info.
Alright, so let's see, what were we gonna do? We're gonna, okay, so we're gonna, we're gonna deploy a couple of images and then we're gonna smash them and then ship them.
Cause that's what we're here to do. We're here to get software into. In the production as quickly as possible.
Now you probably wouldn't use Docker, I'm sorry, you wouldn't probably, you wouldn't use Podman desktop to go to production unless you're really, really brave.
But this is more again, developer workflow. So you're, working locally, you're like, okay, now I need to go to my Dev instance of Kubernetes and see what's happened in there.
It's good. Okay.
See if I've got any problems before you go, you know, any further down the way. So let's pull an image.
Yeah.
First November.
What's that?
Oh.
I'm sorry I couldn't tell who was talking there.
That was from John Steinmeier. I'm not sure if he meant to ask question or not.
Okay.
I do that all the time. Usually I get caught with a snarky comment.
Yeah.
Okay, so embarrassing. Alright, so we pulled a Redis 5 image from Centos and I am trying to sort of spread the love around here.
Like I said, this isn't a Red Hat presentation. We've done Alpine Linux.
We've done Docker Hub. We're doing Centos now. Hasn't been all, Java stuff.
We're gonna do a little bit of Python here. We're using is really what I'm trying to illustrate is the tool, that it's a good tool for, you know, whatever instances you're doing, we're not pinned into a particular ecosystem, whether it's languages or Kubernetes or, you know, whatever.
Okay.
Alright, so we'll pull our. Or app down.
I'm done. Alright, here we go. So now we're going to run both of these rascals.
So the first one was my.
Santos 7 and actually let's stop a couple of these other guys while we're over here.
With my containers. And it can serve some resources.
Alright, you stopped all those guys. Notice we did. Create that pod when we pushed it into oh, and we pushed it into Kubernetes.
You know we created our determined bore we ran it and then we shipped it and it created that cube, for us and then and then push that in so we've got we now have a pod this this area was blank previously.
And this area was blank previously. Can make another pod here in a second. All right, we got our images.
We're going to start our. Redis 5 and we will Run that rascal. Just go.
And back to images and we will also start our. Python app and run that guy. Go.
We'll go back to our running containers. Here we go. Alright, so we've got our 2 containers running.
We've got, unruffled and gifted.
So now what we want to do, so we've got 2 containers who got 2 different applications listening on different ports.
And we want to sort of podify them if that makes sense. We want to turn them into a pod and then ship them into Kubernetes.
So we're gonna check both of those rascals.
We are going to then this is our Potify icon, this sort of stack of 3 blocks.
So we're gonna create a block with both of these guys. We're gonna. So. Pretty nice thing.
My, yeah, my pod's fine. We'll call it My pod. It's showing us the ports.
We could probably not expose 63 79 that's the The reddest port, but I'm just gonna leave it leave it the way it is and we will create this pod.
So we're creating our pod.
We have our pod here. Now we can take this pod which has 2 different independent containers. And zoom this off to Kubernetes.
Just like we've done.
And so there it's doing. Exposing our endpoints and whatnot.
Back to here so we can see this is our pod the dark blue in The Open Ship console here means this application is done.
This one. You can see it is what's this rascal up to? Yeah, we just deployed.
So it was pulling those images and, and then starting those processes. So when we look at this, we can see our resources.
We have our pod there. Containers are creating we could take the look at our logs This logs a little bit of a mess because it's both logs for for each container or the log for each container in the same output.
We've got this one. And we've got that one. We can see our 2 containers there.
That's super handy. We cared about metrics in the ammo. We don't care.
So let's let's go back here and see if this actually worked. So remember we we had a we created a Redis key value data store and then we deployed a Python app that's going to use that Redis key value data store.
So let's let's hit our, we'll open up the route to this guy. I can click on it and we have viewed it one time.
So what this app does is it takes a request. It stores that into the Redis store. And then if we are We are to reload this page.
You've seen it many more times. Such an exciting website. But kinda cool from a developer perspective, so think about that, you know, you maybe we were really just writing that Python app, this web app that we've seen, but we've got this dependency on Redis.
Well, we could locally run Redis as a container and we were doing our local development and that was cool and we're like happy.
Yeah, we've got snazzy colors and our counters working and all of that kind of stuff.
Now we're ready. You know, rewinding 5 min in time. Now we're ready to see how this looks in Kubernetes.
Well, we run them, we potify them, and we ship them. Boom. Now I'm, you know, I could be happy or sad.
I don't know what the answer is, but getting to that answer quickly is the key to rapid development.
And in this particular case, I think I'm pretty happy.
Any questions about that? That should be kind of a cool thing, I think. To go from running containers into containers running in Kubernetes, not knowing anything about Kubernetes and yet they're all wired up.
I'm doing exactly what they're supposed to be doing.
And if you don't have questions, that's fine. Let's see, one more thing.
Good question.
Do we have time for one more? Yeah.
Good comment. Sean put in the chat. Podman has something like watchtower built in.
And he put in the URL part.
Oh, I don't know what watch power is. But that sounds awesome.
And we could.
Yeah, basically watchtowers like it updates your container images. So we've been looking at this from like a developer point of view during this presentation, but Podman is also interesting, I think, from a home lab perspective because One, you can run your pods with system the units so you run them a lot more similar to how you would run through traditional Linux applications and 2.
They can actually auto update the containers right because the fear is i'm gonna set up the service the stocker container and leave it running for months and then how is the base image and the container ever going to get updated you know but podman has an auto update command.
Or it'll actually. And a system D timer to go along with it. So it'll actually auto update the base image whenever you tell it to.
It's pretty, they're like on a timer whenever you tell it to. So. Pretty cool.
That's gonna be huge from a security perspective. I'm thinking so I always think about.
Okay, how does it supply it to the enterprise? And that sounds like a really great use case for the edge.
Where you're running containers at the edge, you're not going to run a full blow on Kubernetes, but you run them as system D units and then you know your security guys will be happy that they'll actually get updated on occasion about on the factor or whatever you might I'd be doing that.
Yeah. Yeah, or from a home lab perspective too, right? A lot of people don't wanna run Kubernetes at home.
Oh, for sure.
So having something like this where it's just system D and it auto updates itself seems pretty useful.
Yeah, that would be a whole other talk. And maybe, you know, somebody would, wanna do that using podman to generate those system D files and then also looking at and it was one in one of the slides quadrants which is a new extension and then there's a and even oh never mind I'm not gonna remember the name there's even a newer thing than Quad Lots.
Podman Shell, Podman SH. Something like that. There's so much energy and new development and cool things happening in the space.
I love open source. All right, one more thing. One more thing. Good morning.
Could you, the, where the containers are. For the
Okay. Go back to here.
Yeah, yeah, so you know how you have the dropdown for alpine because it was a composed file does it okay it does show the dropdown for the one you created manually okay That's what I want to see. Thanks.
Yep. Yeah, so what it did is it created that pod and, and then the pod definition, the YAML and then shook it off.
Oh yeah. And again, as a developer. I didn't have to care. Yeah, we're gonna do one more thing and then we'll get out of here.
Except I lost my one more thing. Where'd I go? Okay.
Resources so kind I mentioned that that We could use lots of different Kubernetes. For me, Open Shift is the easiest Kubernetes to use.
Most one if you want to play with this is a little bit of commercial if you want to play with kubernetes for free in the wild and not have to like set it up and do system administrator stuff Developer.
Dot com. Free account and you can have your own cluster every that renews every 30 days so make sure you save your code but a great place to play.
Kind we're going to you can you can read it on the screen. Kubernetes utility for running local customers using single node containers.
So we're gonna create a single node Kubernetes locally. Mostly and again really just to show you this isn't tend to red hat tooling we're really tooling agnostic certainly we want to work well within our own ecosystem, but whatever whatever makes sense for developers.
Since this is a community. Driven led supported. Project. That's what that's what's gonna happen.
So we're gonna create a kind cluster. So we'll do this. It's gonna be a pod man type. I don't even know what our options are.
We can do a Docker version. That would be exciting. We're gonna stick with Podman.
It's going to set up an ingress controller, meaning we'd be able to get traffic into our into our cluster if we needed to.
So we're gonna do this. And we will just hit create. Just make it as simple as possible.
So what this is doing is creating a single node open shift cluster, called kind. That's the name of the project.
Assuming it's doing something. Yeah, it's creating. Here we go. And then it's going to run it as a container by pod.
And so podman is gonna run my kind cluster for me as a container. I don't look at logs.
Let's see if it's doing something.
Yeah.
And kind was actually an acronym for something. The K was Kubernetes. I forget what the other 3 letters were, but it's.
Oh, there we go.
It's a Kubernetes in Docker. That's why the I is capital.
Yeah.
Yeah, okay.
Perfect. Or in this case, it's Kubernetes and Podman, but close enough.
Same stuff. So we've created our kind resource. And then if I go to my containers.
Okay.
Nice should have a kind cluster control plane. So here is my kind cluster. Very exciting. You can see I've got the logging in that.
If I wanted to log in to here and then I could do, you know, regular Kubernetes stuff, See Okay.
Oh, good Lord. All right. QCT. I'm just gonna hit Enter because we're kinda out of time, but I could run QCTL, right?
So here's all my CTL stuffs and I've got Kubernetes running locally in Podman and I could start, you know, deploying more Cube stuff or developing for cube, but doing it locally within Podman securely safely and like really super easy.
That was those. Easy, easy to set up. And that I think brings me to the end of what I wanted to share with you guys.
I really appreciate all the conversation that we've had. I've learned a lot from this.
I hope you guys had a good time. It was fun for me. Anything before we wrap up. Word from our sponsor.
Yeah, I think there's some promise for some of the work I've been doing. Because you know I've been working with containers for a while but.
At the part where I need to push into some kind of. Cloud instance. When I was using the The open shift sandbox I was getting some permission errors.
Which is what cut my attention on one of those screens. Well, there's a check box where you could.
Change the YAML such that it would or look like you could change the, to do that.
So I'm going to,
Yes, so that's one of the things I was gonna mention that so open shift when we have a much stricter.
Security policy when running, you know, open shift proper, which the developer sandbox is. And so if you're running containers that need privileged access, they are going to fail by default.
There's a command you can run to open that up. We have in Open sheF 4, 12 or 4 13.
There's some additional security context constraints that we're adding. It's all about trying to keep your your clusters in your in your companies safe.
So it can be a little bit of a Perfect.
But it's all for good reasons.
Looking Right, you mentioned that there's a command that I could run in the sandbox to open up some of the security stuff.
Yeah, you just, so. Put a quick google on. Open chef SCC security context constraint or privilege containers that type of stuff.
Okay.
There's all kinds of examples for it. Now again, the the best advice for me, so putting my hat back on.
If you can, refactor your app to not need those kinds of elevated privileges.
But sometimes you can't.
Yes, that's kind of the direction. Right, I was hoping to like get it working, maybe cheating with some of the security things and then going back and.
Yeah, cause they can be kinda subtle what actually broke the message is that the sandbox gives you like
Was this huge context of, you know, like this paragraph of all these things were wrong? I have no idea then.
Right.
Realize okay I broke some security rules and so they Kind of threw the book at me. But I was hoping some of those flags that I saw in the.
Within the GUI there. Good can you give me some, how to work around that?
Yep. I take those questions to the community. I think that they would be really interested in helping that.
I mean, that's that's why we that's why the community exists. You know, it's what we're doing here tonight, helping each other get better.
I have a question if you still have that hat on. So. So we deployed a Kubernetes, but locally we just used.
Yeah, I noticed it sitting back there.
Yeah.
Okay, so we deployed Kubernetes, but we locally we just use Docker compose and it's been, locally, we just use Docker compose and it's been, I mean, fine.
Yep.
So I was wondering, what do you think? Is the reason why. Even if it is simple, why would I make my developers deal with Kubernetes on that local machine if Docker composed has been working fine.
I don't see the benefit.
I wouldn't change anything that's working fine for you.
That would be Well, I mean. There is that, but if you're not, there's.
Yeah. But could it work finer? Gonna work better somehow. I don't know.
There's so much work to be done. That you know sharpening your saw to down to the nubs just isn't worth it if the process is working for you, then don't change your process.
There's nothing wrong with that. If, it's not, you know, if you're running into some impediments for whatever reason.
That then you then you would look at other tooling that would be my, you know, best advice on that.
H or not.
Okay.
So you're saying that my VMRC shouldn't be a thousand lines long? Like, that we're talking about with the saw sharpening.
I'm just optimistic that you've got that committed inversion control somewhere.
Okay.
Of course.
Where else?
I mean, the only, argument I'd make for, using, Docker like stuff everywhere both local and remote right at once and not have to try and translate it because there are tools to translate from the docker compose but I've always found that I get burnt by the edge cases sometimes.
Yeah, a hundred percent like I. This isn't a commercial for broadband desktop. This is more, hey, this is a cool tool that might be useful, potentially.
If you have, you know, processes, procedures, policies, tools that work with, that are doing what you need them to do.
Don't change. That'd just be silly in my opinion. I mean, you know, maybe experiment and dabble, but don't don't change your your day job.
Just to bring on tools to bring on tools that that never makes it at least my experience, that doesn't make any sense.
And if you got a vendor telling you differently. You know, not a good vendor in my opinion.
Yeah, I think that's a good point, Andrew. Like riding the Docker compose files initially and riding the helm deployment, right?
I had to write 2 separate things there. Whereas if I just somehow use the helm deployment locally also then it could save me from writing.
That Docker compose file. So I see that point.
Yeah, I mean, at least personally, I have, make getting it all right the first time, let alone getting it right.
Twice.
Yeah, feel that.
Yeah, Kubernetes is a beast.
No doubt. Like that should be. Definitely not having my head on at this point. That should be like your tool of last report.
Like that's for, you know, when you have to operate really at enterprise scale. You know, that isn't for, that this isn't for, you know, necessarily Steve and running.
You know, 5 or 10 containers that you can do pretty easily with. Docker or Podman or system D.
Right, lots of good choices to keep things simple, but if you're running you know, 100 node clusters, multiple 100 node clusters across lots of different cloud providers.
Then, and that's when Bigger beasts like Kubernetes come into play.
I think.
Yeah, I see it, solving the same, thing. There was always a statement about.
Big data don't do big data unless you absolutely can't do it any other way and you meet all of the these.
Yeah. Or what's the? The the quip about about Reg X. You know, if you have a problem and you solve it with reg x, now you have 2 problems.
Yeah.
Yeah, exactly.
And that was said, I thought that was said.
Also, yeah, same thing.
Yeah, but I feel that pain though, cause we literally, we have a Kubernetes cluster, but we only run 5 containers.
But then our platform team. Put 7 containers in there to monitor our 5 containers like with security scanning tools and all that kind of stuff.
And so it's like we're literally doubling our overhead to run these scanning things.
We like, yeah, it's funny.
Yep, that's. Kubernetes is too big of a solution for that. It's certainly got
Yeah, I've got a similar scenario to that.
Yeah. And like so the customers that I that I talked to, and, you know, perfectly happy to share with you guys.
But it's it's folks like enterprise rent a car, state farm, caterpillar.
Developments health care, and team, like, I mean, these are giant companies. They're not running.
5 containers on a Kubernetes cluster. They're they're running. 5 Kubernetes clusters with hundreds or thousands of containers across hundreds of nodes.
It so it's a problem of scale and if you don't have that problem. There was a lot of resonated driven development.
You guys familiar with that term? Where you go out and you do the new shiny thing so that you can get the next bump and pay and go to the next job.
Okay.
I think a lot of our infrastructure friends the last 5 years did quite a bit of resonate building.
Infrastructure. Because you want to I mean Kubernetes you know the jobs are out there then yes thank you for confessing for sure.
Yeah.
The jobs are out there for folks that do Kubernetes. I mean, it is an in-demand skill right now.
So maybe folks. Brought it into organizations when you didn't necessarily. Necessarily need it running running 5 containers and Kate's is a bit of an overkill.
I think
Yeah, and I mean, I work for a big company. We have, you know, I think there is a need for Kubernetes but they make each application have its own Kubernetes cluster, right?
Or it's on its own EKS, right? And so that's when it gets a little bit ridiculous, I think.
I think if they had one or 2. Or a handful for like the entire enterprise that might make a bit more sense than each application has its own Kubernetes cluster type of thing.
Yeah.
Yeah, that's an interesting point, Sean. So, Back with the hat and looking at lots lots of different companies do there there is a real tension there and and this has been across all of our jobs as long as we've been at IT.
Do we, you know, how far do we isolate? And waste resources and how much do we consolidate and then bring in problems like coordination and noisy neighbors and things like that.
So you'll see companies that do exactly what you said. They've got one or 2 very big clusters.
Those clusters can be hard to manage and maintain because getting all those individual app teams to agree to agree on patching cycles and upgrades and things like that.
Really, really hard to do. But on the other hand, if you're running Kate's just for a couple of different things.
Maybe it's, maybe it's overkill. Maybe in that case you would have been better off not knowing anything about your business shot.
But maybe just using ECS and just using Elastic Container Service or maybe even if you could using serverless apps, right?
That's that's a big deal. Putting the sales hat back on. I think Red Hat does a really good job in terms of solving container sprawl.
One of the things we're doing, in Amazon coming out now is something called hosted control planes and this is definitely commercial time at this point.
Where we will have, you'll be able to have. The control plane. I single control plane for many different Open shift clusters, actually other Kubernetes clusters too.
So you're not continually duplicating the 3 nodes to run the control plane. Well, that because people have been complaining about that, you know, I want to have 5 clusters each each of them have 5 apps and now I've got 5 control planes and that's just a waste of money.
Can I have one control plane that manages 5 different distinct clusters securely and whatnot. So life is evolving in that space.
And there's definitely a, you know, that tension of. Of isolation versus consolidation. Is ongoing.
Going back to resume, having driven development, it's really hard to blame some of those platform people though because it just feels like Amazon is just pushing you like here.
Oh, here, try this service and that service. And then, you know, you want all these different acronyms on your resume. And then, you know, you want all these different acronyms on your resume, right?
Oh yeah, I've experience with ECS, EKS, RDS, you know, it's like all these acronyms you need on your resume and they and they keep pushing their sales.
You know, like, oh, we have a service for every problem. Come, look at our. Let us help you with that, you know, and it's just.
I feel like yes, it's resume driven development, but also I feel like the sales pressure from these gigantic cloud companies is, you know, really intense like pushing people towards that also.
100%. Yeah, 100%. Everybody has their own individual motivations.
I don't I don't generally judge people what they're motivated by because I'm probably motivated by the same thing.
You know, we all wanna do interesting things and get paid, you know, for doing it. And how you get there.
That's interesting. Darn vendors, the worst.
Yeah.
All right.
I mean, personally, I go for the, AWS in, let's see, I think it was called.
It was basically somebody made up a AWS service and tried tried to get enough buy-in that recruiters would start trying to recruit people for it.
Yeah.
That you had to have infinite dash experience.
Yeah, yeah.
Okay. Service? Yeah, and how would you ever know? There's like a hundred of the things.
Yeah, and the problem was actually people started putting it on their resume and it actually got some traction.
I think academia suffered from that a little bit too where people would auto generate, you know, research stuff, particularly around the literary criticism, which is just so stinking dense.
If you've ever, it's terrible stuff to read. And you don't understand and things would get published and talked about and accepted and it was all just, you know, made up We are certainly vulnerable to that as a species, I think.
And
Right.
I like the, the mean going around where somebody's like listing all these programming languages they know and then like one of them's like not even a programming language, it's just the name of the It's like, which one of these is the?
Yeah. I've been try that.
Yeah, and it probably sounds like a programming like, which I've got a friend who I worked with at Panera, I've got a friend who I worked with at Pinara, he's still there.
But he used to sort of do the same thing. And now, so his joke actually became a reality, but like 10 years ago, Scott would be like, hey, we should start using Rocket Chip JS.
And there is a rocket ship getting us now, but there wasn't there. They could stop up.
Yeah.
That sounds legit, right? Rocket chip JS.
Good times.
I'm gonna point out that the the best. Comment and chat all night. Was when I had said something about, wait a second, there's a background sound.
Somebody's open mic or something. John responded back and chat, but sorry, I walked out of the room, came back in and found the cat was walking across the keyboard and unmuted my system.
That's awesome. My, my assistant frequently joins me on video calls and you'll see a tail kind of.
Yeah.
We'll write it across or she'll get up on the back of the chair and she'll be like, you know, chewing on my ear.
I'm not talking, so you're fine.
Okay.
Wow.
There you guys have a lively jet conversation. This is great. I'm gonna have to chase down some of these links.
Thank you for putting.
Go ahead.
I have a question for, the group in general. So like app images and black packs, they're kind of like an isolation thing and And I always wondered like if there was a role your own way to do those with.
Like containers or dot or, you know, something.
If anybody has any ideas on that.
Yeah, certainly. You can certainly do that with containers. So you would start with a base image, right?
And then, you know, like in a bunch to base image or whatever, and then you can install whatever you want in there.
I'll bite your tongue. Start with a rail base image.
Hmm.
Right, and you'd use a UVI, of course.
Yes, you there is a really so UBI is unrestricted like you guys if you want to use the universal base images from Red Hat there is no licensing restriction on that.
Okay, hat back off. Alright, yes, a bunch is great by the way. I love Ubuntu.
So are the app images or flat packs or they full distributions or they?
Yes, it's.
Just the control needed for what you're running like, like my zoom is an app image.
And I'm right now, so is it? Not a full distribution, is it?
Oh, okay. Well, if you're trying to run GUI apps, I don't think that would work in from a container.
Now that you mentioned that, at least I've never. And from a container. Now, that you mentioned that, at least I've never seen.
GUI apps running from a Docker container. But if it's command line stuff, that's definitely.
Easy to do.
Alright, I'm a boy, you guys mind. And then maybe we call it a night. So GUI apps in a container.
I agree with you a hundred percent. That is not generally what people are doing. However, There is this crazy project called Kubert.
Yeah, is that the crazy one where you run VMs and Kubernetes?
Somebody heard of Kubert? Hey, That is the crazy one. You are running a VM in a container in Kubernetes since the cube, hence the bird.
So it is AVM running in Kubernetes in a pod just like we ran our stuff in a pod and it is doing whatever the VM does and it could be you could be running a Citrix client doing citrus key things or you could be whatever you're running right it's a VM it literally makes It's not like you had to refactor the app and make it like small and
snazzy like most of our container. Based applications are. It's literally the virtual machine, but running in a pod in Kubernetes.
So in that respect, you could do it, but that's not exactly what the question was.
Although some things certainly to look at a lot of folks are starting to look at cube vert or way off topic here.
Because of the Broadcom acquisition with Vmware, that's creating a lot of anxiety in organizations in terms of What's gonna happen with support and what's gonna happen with my Vmware contract?
So there's a lot of, and I know folks are looking at Kubernetes and, you know, hyper-converged infrastructures and all kinds of different things and and all kinds of different things and some folks are just putting their head in the sand and me, and some folks are just putting their head in the sand and be like, we're just putting their head in the sand and be like, we'll never move off at the end where it doesn't
matter But it's getting a lot of interest.
Awesome.
First there's another comment and in chat, I'm sorry, I'm.
Yeah, in theory, you might be able to get away with doing something like XRDP or, one of those other remote desktop, E sort of things to.
Get away with it. It's really one of those you could, but really should you.
That's an awful lot of weight just to, get.
You can put a White House and black parts together, but not pulling in the same directions you says.
Yeah.
Yeah, do the. Based images typically have that kind of. Plumbing in them.
Well, I mean, depending.
What depends on the base.
Yeah, I think it's possible. I, sorry. Yeah, I've seen a couple where you can say like Kind of make it like, like a desktop and, but again, it's your.
Kinda. Are you're defeating the purpose of the container, right? It's resource intensive.
The purpose of the container, I think, is to provide an isolated environment for the application that you're trying to deploy.
So. You wanna, I think in general start with the smallest base image that's gonna meet your needs.
And that, you know, so when they mentioned the UVI images, it's universal based image that Red Hat has.
There's 3 versions of that. There's kind of a big one which feels like a full version of REL.
There's a standard one and then there's a minimal which has like almost nothing. And then what you do when you're building containers is you say from this base image, whatever it is, and let's say it's a Sentos image.
For example, or Alpine. I did a couple of Alpines. As well. Then you start, you know, then you interact with the package manager and you say, you know, app get install or, you know, DNF.
Dash why I like installing tree because I like pretty colors. But whatever it is, right?
You use your package manager, you install your other packages, you you might do, you know, user configurations, all the things.
So. Containers in theory should be smaller than of VM because you're you're essentially virtualizing the OS.
You're not duplicating that entire OS. The VM is virtualizing the hardware. A container is virtualizing that I with a shared kernel underneath.
So all it's gonna have Are the it's gonna be your app at the end of the day, but then those applications specific dependencies, you know, the various libraries that your app needs.
If you're a Java developer, a little bit like you're not going to do import.
Java that you tilt that star when you only need hash map. For example, now I know the compiler will fix that for us these days, but sort of a similar thing.
You want to start with a small thing so that you can start faster, scale it, you know, one of the premises.
Of containers when you're running them at scale in Kubernetes is to be able to horizontally scale based on load.
If it takes a long time to start, you're not going to have a great experience scaling horizontally.
And if you've got really big fat images, that's going to take up a lot of resources.
Okay.
And if you let's say you're running in Amazon, they would love it. You know, that's that's just it's money that you have to pay you can get your the smaller you can get your resources down the better experience you'll have from a start perspective and from a cost perspective.
Okay, there's Kubert. Thank you for dropping that in the chat. And the universal base image, other good things.
It's coming up on 90'clock folks.
I had a good time talking to you guys.
Hi.
And, anybody can want to think of a final question or whatever. Real quick, but I'll take this opportunity to thank Chris.
I mean, this is really been. Oh, wonderful presentation, a real tour to force of what's going on.
And.
It's like my brain hurts. I think I learned too much here.
The question is from Steve Gomez and Sean. To a house of really been inspiring. And informational.
Is there any use for this for like daily drivers or desktop? Like. Ours just dissolve, this all development, you know, high level enterprise ID stuff.
You.
Like Podm and Desktop, seen as more, more down to, you know, down to the desktop level.
So.
Yes.
Yeah, let me give you a use case, right? So you know how like in a packages are old depending on.
On how recently the latest release came out. But let's say you wanted to install like the latest version, you wanted to run like the latest version of like, I don't know, Terraform or something, right?
Well, there's probably a Docker image that Terraform produces. Where you could use the container to make sure you run in the latest one.
Cause installing the latest one on a bunch to might not be as easy as just like. App to get installed, right?
Cause that version might be significantly behind. And so using the container. Might give you easier access to more up to date.
Like command line apps like that.
Yeah, it's an interesting application. I thought they'd be forward.
So I've also used it for, like image or video transcoding. So that you don't end up getting yourself in a dependency hell where, X application needs.
I version of another application. As a dependency. And that way when you're done doing your transcoding stuff, you don't have bunch of craft sitting around on your base host machine.
That by a way reminds me of video editing. I know a couple of you may have joined us in progress and if you missed the earlier part of this with Chris's permission, we'll take the recording that we made.
And put it in our archive, so that people can, pull up the recording off our our home web page.
Just to the archives there. And you can listen to the whole talk from the beginning or listen to the whole thing over again.
And I can use it for resume driven development too.
So. And as I said. There we go.
Yeah. Yes, yes.
That's another important thing I learned at today's.
Well, thank you very, very much Chris. Once again, really enjoyed this and really appreciate the effort.
And thank all of you for coming tonight. I'm gonna first say that we'll turn it over to any open general Q&A that's not necessarily apropos to tonight's talk and certainly we understand.
Hey, without me.
If Chris wife is saying Chris it's time for dinner get off that thing. We But,
Yeah.
So, I mean, you're more than welcome to stay with us for any general Q&A, but if you got to go, we certainly, general Q&A, but if you got to go, we certainly understand it.
And
I'm starving. I'm gonna let you guys go. Thank you so much. So this was a ton of fun.
I'm really enjoyed talking with you guys. Hopefully we can do it again. In the future and and please do come out you know to the red head of guns.
Yes. That is.
Would love to see you. For sure.
We need you to come every, meeting so you could be our Red Hat expert for Red Hat questions.
Yeah.
Well, that that would probably be stretching it a little bit and the other thing in all candidness I really in this context, I don't want to be a Red Hat representative too much.
I really do want to be more of a community person. I mean the business comes out, right? I work for who I work for, which I love.
And I'm happy to take any red hat questions you have, but yeah, from my perspective, I just, I just want to be one of the gang really, but thank you for that because I've had a ton of fun tonight.
I recommend that the recording be ended. And that, Gary, go ahead and do the book ends.
I'm gonna, yes, we keep the recording on for just a few minutes just to see if anybody has a.
First has any question it would be apropos to record, then we can turn it off afterwards.
But the book end this was Thursday the 20 first of September 2023. Our speaker tonight was.
Chris, from, Red Hat and the topic was. Podman and it was really a good interesting presentation.
So we really enjoyed it. And thank you all. And we'll leave the recording up for a couple of minutes here just in case there's something.
Like I say, first, if anyone has anything you don't mind.
Being recorded, ask that question first.
Kishna? I guess not. Anybody in that case, after crystal, Chris Bowen being done here and Yeah, I think he's left, but thank you again.
And we're gonna turn on