Container Roundup

  |  Compiler Team   容器 专业发展

Compiler • • Container Roundup | Compiler

Container Roundup | Compiler

About the episode

As it turns out, breaking up your application into a bunch of tiny pieces can be way more efficient than running it as a monolith. Thanks to containers, organizations can fine-tune their IT resources to match demand. But setting up and managing a containerized infrastructure is no small task.

Cedric Clyburn, Red Hat Open Source Engineer and Developer Advocate, talks us through why containers now dominate cloud computing—and shares some advice on how to keep track of them all.

Compiler team Red Hat original show

订阅

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

脚本

A lot of the companies that I work with do have very strict guidelines around this also. So reach out to your security teams if you haven't already. By this time, I wouldn't have said that five years ago, but now definitely they already have. So, you know, utilize them. There's people already doing this work. Yes, everything is a potential glitter bomb. Open with caution. Glitter bombs. This is Compiler, an original podcast from Red Hat. I'm Emily Bock. And I'm Jennifer Scalf. On this show, we go beyond the buzzwords and jargon and simplify tech topics. This season, we're covering the fundamentals of IT infrastructure. On today's episode, we see what it takes to ship containers. Containers may not be the hot item on the block anymore, but they've proven to have staying power. If you're working on cloud software, chances are you're either working with containers or planning your move to containers. So Jennifer, what's your hot take on containers? I don't know if there are any hot takes anymore. I was just talking to a bunch of kids, like new developers, young, they're still in college. They just think it's ubiquitous. It's just what folks do now. It's not even something people apparently think twice about, which kind of surprised me because I was still, I'm still kinda, even though I work in the industry all day, every day, there are still places where people have not containerized their software, their applications. Mm-hmm. Yeah, so I guess that's my hot take is like, "Hey, folks, the next generation is coming up with this just being the default. So can we hurry up?" That's about it. Oh, it's every, every migration to a new tech takes just long enough for a new one to appear. Absolutely. I wouldn't wish it away too fast because then we'll have to learn something else. Yes, I agree. Oh, for sure. Only a matter of time always. But I think we'll see how your opinion stacks up against another expert. We spoke with Cedric Clyburn, an open source engineer and developer advocate here at Red Hat and he shared how convenient container development can be. So when you can kind of break it apart into little pieces, think about Legos and then build, you know, that Lego car or whatever you're trying to build, it's a much more agile way and I, you know, I'm saying Agile, don't yell at me please, but, it's a much faster way to innovate and let's say that we want to adopt some new framework like Spell or update our application from some version of Java to Java 24 or 25 then we're not limited by another team needing to work on their application because let's say we're exposing the same endpoints, then that team can just call those endpoints and you'll see as we talk about Kubernetes later on with services that it makes it really easy for these containerized microservices to talk to each other. But that's the main, that's the main solution there is being able to build faster and not having issues when something breaks that brings down the entire application. How big of a difference is it really to decouple all of these separate components and allow them to have independent update cycles? It is a bigger deal than folks realize sometimes when you're working on an existing application being containerized. So I joked, "Oh, the big hot take is that folks haven't moved." For some very large established applications, it is a bigger lift than maybe we'd foresee it. If they could just do it though, if they could get there, containerize parts of their application and then start chipping away at the rest, make them much more, and I'll use it too. Why not? Let's say agile. It's a great word. But because then they get to the point where it's great for scaling and then customizing, as you mentioned, the different requirements that your application has inside of a cluster. I can't even help myself. I'm gonna start using the terminology. Inside of a cluster, if you're especially working on a cluster that has many different containers for very, a lot of different applications and you are all moving at different speeds, that is so incredibly helpful. But another thing that this doesn't really talk about, but I have to throw out there is there are a lot of schools of thought now where people run the same application in containers across large clusters. In my world, in telco, that is something that they do. So they'll have something like 2,000 nodes. And they're all running technically the same application, but it's all been broken down into little tiny pieces so that they can quickly scale and quickly, spin up, spend down, move to different hardware. It's kind of wild how many different ways you can configure these clusters these days and applications inside of those clusters. Yeah. So like a million copies of the same thing all running at the same time rather than one giant one. Exactly, exactly. Yeah. It's amazing. That makes sense. And I could see how that would be a little bit easier. You just add a bunch more. That's exactly what they do Versus, you know, re-architect the whole thing to be bigger. Yeah. There's a well-known company that uses it for their email and that's exactly what it is. Huh. Billions of instances are all run, each in their individual containers. Wow. That is kind of mind boggling. Really is. But that really drove it home for me when I was learning this technology, 10 plus years ago. Oh, okay. So everything your email would need to be your email, just imagine that is a container. Mm-hmm. So anyway, trying to keep it straightforward. Yeah. Yeah. That to me is closer. Maybe it's confusing, but I literally picture them as like a little shipping container— Yeah. With all your like software goodness insight. Exactly. So fun. All right. Back on topic though. Like to top all of that benefit off, there's also, I think, resource usage advantages to containers as well. Cedric connected the benefits of container resource allocations with the demands of scaling in application. Because, you know, while developers are also very expensive resources to have on our team, so is the infrastructure. And this is more true for startups, early stage companies who are getting their foot off the ground who need to keep those costs in control to grow as a company, right? They need to be able to manage the resources of each of these components, the front and the back in the database as examples. And with those microservices and something like Kubernetes, I can specifically assign, say, for example, four gigabytes to one resource and if those four gigabytes are being utilized by that application, well, then I have another replica come in with another four gigabytes and that's the beauty of this approach is that I can automatically scale up without any engineering teams have to do this manually. So it reacts to the traffic, it reacts to those who are using the application and that's why I think containers and microservices are now the defacto standard for deploying software in the modern world. Okay. So I wanna clarify exactly what he means here by tying costs to infrastructure resources. Do you have any fun metaphors for us in this vein? We'll get to one, definitely. I mean, we've already gotten to the shipping containers and that was a great one, but we'll compare for just a second. So in the past, years and years ago when I first started, there were very large servers, physically large servers that we paid a lot of money for and we ran a few applications on and now we've gone to much smaller, commoditized, much cheaper hardware. Well, okay, we're not gonna talk about the last couple months, okay? But, but in general—and it still is true because a large server is gonna have a lot more RAM and it'll be a lot more expensive either way if they're senior or, or large. But anyway, so now we've gone to a lot smaller ones and so you can, , put a lot more very highly specified applications that are broken down into their individual container components onto that no matter like how large, right, if you need to roll in another rack full of, you know, individual much cheaper hardware. It's much easier to do. You can like just smush, keep switching that in there as an infrastructure. And then if you don't need it anymore, if somebody doesn't care about that particular app anymore, you can actually decouple that so much easier now than if you just have one humongous box. So I'm really simplifying this a lot, but I was there, I was there with the massive blue boxes that are now little teeny, tiny sliver, you know, and all kinds of different names for the little slices that are, are, are little servers now. But I've actually seen this. It's amazing. The other thing I do wanna mention that he brings up is the autoscaling. Mm-hmm. I did have a customer one time somehow assume that autoscaling meant they could autoscale forever. Yeah. And I did have to explain very gently, well, I mean, in their mind, they needed a better paradigm to understand it, right? They said, "Oh, well, what I just said, oh, we'll just keep rolling in more hardware." Sure, but you still need humans to recognize and know that you need to add more, right? Yeah. More of these little slices and these servers and, or, you know, if it's talking about hard drives or whatever it is that some, some of them are very CPU intensive, some of them are RAM intensive, whatever that infrastructure that you need to add, it doesn't autoscale into infinity like a TARDIS. Yeah. Bigger on the inside. Right. You still need people or something, if we want to, whatever it is that's identifying that, okay, we have now—even though everything is broken into containers and the infrastructure can scale and the containers can scale, you still need somebody to add more of whatever that is that they need. So CPU, RAM, et cetera, after a certain point. So at a certain point it is autoscaling, "Hey, we need more. Let's go out to our big farm and get more." Oh, we went to a farm, that's a good metaphor. Farm could be one. I have one I'm toying with. Okay, what's that? How about, okay, so non-containerized world is kind of like a laptop in that it is all one thing. If you wanna upgrade or change something about it, you have to avoid the warranty or kind of replace the whole thing versus containerized would be like building your own desktop computer. Yes. And if you want more RAM for it, you just pop out the RAM, stick something bigger in there, bam, you're all good. Beautiful. And you know, because, you know, we've had a desktop that there's only a certain amount of RAM, certain amount of CPUs, because you built it, you added it. Right. And so it doesn't autoscale forever, but the, but it could scale to use all of that. In fact, some of our web browsers love to do that, don't they? And yeah, and not only that, if you don't need a massive amount of RAM, you can put just as much as you need in there and not pay a bunch extra. Exactly. All right. Yeah, we made it there. Love it. I like it. Okay. So I think we've covered kind of the basics of why containers became such a big deal in the tech world and next we're gonna dive into how to handle some of their complexity. The thing that's great about containers is that you can break up an application into many different pieces that scale independently based on what's needed. The thing that's not so great is having to keep track of all those containers. Observability with containers, of course, you get the logs that are coming out of a container, right, of what's being written to a file system perhaps or who's accessing what part of a website you can see the post request and the git request. But the observability in a distributed fashion has led to projects like Open Telemetry and Grafana and Prometheus and Jaeger, all of these that have capabilities to show you what's going on in your containerized applications at a huge scale because it can be a lot to monitor this even if you're in a singular virtual machine to monitor one container in the system D logs and the, and the, the journal logs from your application. And so there's a lot that we can do in order to observe these from a, a high point of view and be able to understand what's happening and what's slowing down our application and why users might be waiting, you know, 50 seconds to add an item to their shopping cart when it should be 50 milliseconds. Ah, yes. What's going on in all those containers? So Jennifer, how easy is it to get lost in the logs? Well, first you have to find out where the logs are going because this is not your laptop anymore. I'm loving that analogy, so we'll keep going with that metaphor. It's not a simple, bringing up a terminal and doing a less ETC, you know, var log messages anymore, guys. Mm-hmm. So for those of you who did that back in the day, this is not where we are anymore. We haven't been there for a while, but we're definitely not there now. So he mentioned a few different ways that you can offload logs into something that can make them a little bit more sane. So definitely, definitely do that. These days, we're now talking and I can't remember if I used this metaphor before, but it is a very popular one where you have the pets versus cattle. Emily, you've heard of this, right? Yeah. Okay. Where We say pets Versus cattle. So in a container land, these are def— I don't know how people, I don't think they like this one as much anymore, But I can't get out of my head. So we'll figure out a better one for the whole world to use. But if it's cattle, right, you don't normally, if you have a herd of 5,000 cattle, you're not naming each one, you know, they got a number instead, which again, it does, it seems a little gross in 2026, but that's, I've been doing this for a long time, you know? I get the vibe. It's like there's one. Yeah. That you have to keep forever and take care of and I think about all the time. And then there's the ones that are, like, expendable. A little bit more so. I'm sure we can, I'm sure, I think we can come up with a less controversial metaphor, for sure. Yeah, I think we can. But, it's the same idea. Yeah. So you've got logs then that you're not, you, you have a name of your cluster, you have a name of the nodes, you have a name of your instances, you have a name, right? Mm-hmm. But all of that gets all tangled up very quickly, especially if you don't know where they're going or if you're not sending them somewhere. So you definitely need to make sure that wherever they're being sent, there is something running and they disappear so quickly. So— Yeah. It's very, yeah, this is not ephemeral. This is, it's just snapping in and out of existence. I mentioned the email example. So you could bring in, you open up your email, you look at it, you're using, that is a container in certain, , email servers as soon as you close that out, that is gone. So if you are a system administrator and you're trying to troubleshoot something that happened in one of your users containers, it can blip out of existence real fast. Yeah. And where does that go? So that's really something I don't think a lot of sysadmins keep in mind at first. I get that. I have a metaphor to pitch. Oh. It's a campground. Okay. Some things are your permanent structures, your lodge, your, you know, bathrooms, whatever, and the rest are tents. People come and go, they pop it up, they leave. Yes, exactly. And if they come to you two weeks later and they complain that something was wrong, there was a lot of rocks— Yeah. Underneath their tent, and you go, "Well, you moved your tent." Exactly. We don't know where your tent went. This is good. So campground versus campsite. No, we'll get there. Well, it's like the whole metaphor, I guess, is the campground and then some containers are your permanent structures and some are your visitors. Yep, and you're tents. Yep. Tents versus campground. I love it. It's an intense metaphor. Oh, oh no. All right. I've met my one dad joke person. Okay. So cool. Okay. So now we've got to make sure to have a system to keep track of everything, all our tents and visitors so we can figure out what went on with their stay. So let's move on to the containers themselves. One big benefit we talked about earlier is how containers can run with a smaller footprint like just the RAM that they need in our desktop computer metaphor. Cedric explained just how much you can control the size of that footprint. With containerization, you're able to sum that down, but you have to do additional optimizations, for example, slim base images, which, instead of including a bunch of those utilities that you might need for Python and maybe one includes Python and Java and Node.js, picking these really carefully vetted base images or even creating them yourself in order to keep infrastructure cost as minimal as possible by not including all this bloat that you don't need in a container that's only doing, you know, one or two processes, right? So let's say, for example, you have all these drivers that you don't need, being able to slim those down, set limits on how many containers are spawned at a certain time and how much resources those all get. That makes sense. You don't wanna give every camper your fully tricked out RV. Some of them just need, you know, a one person tent for a night or two. It's kind of the same thing with images, right? So have you tinkered with, like, that base image container kind of concept? Oh, yes, definitely because I've been around so many people that were in the before, you know, large server models. We had our operating systems or virtual machines. We haven't really talked too much about the difference between virtual machines and these container worlds. And so if folks are coming from a virtual machine world, they've got their entire campground, they got their tricked out RV, they've got everything. It's the technical term. Everything's in there. All those drivers, oh, Cedric is so right. All those drivers, oh my goodness. Well, you don't need those if you're containerizing an existing application or something new. You need exactly what version of Python your container might not even need to know at all anything about the hardware. So why would you need 75 drivers? So this is where, and I'm not knocking the operating system, I love the operating system, that's my heart. But if you're making a base image, you control what goes in there. It's a lot of power. Mm-hmm. So yeah, going in and saying, "I only need this version of Python. I only need these libraries. I only need X, Y, and "you know, fabulous. I only, I'm a light sleeper, but I still just need my one blow up mattress. Okay, we keep going to these metaphors— Game changer. It's true. You know, it does make a big difference. I don't want a sleeping bag. I wanna, I want a mattress. Mm-hmm. You don't need an entire bed. We don't need to pack the wood to build the bed when we get there. So I am trying to keep using our metaphors as I think they're great. It helps me keep track of what we're talking about. Yeah. So I have tinkered with this and I have seen both sides. I've seen when people have put too much and they get very large, because they're coming from that virtual machine world. They're coming from 20 years ago where they're like, "I have a machine, it has an operating system, and then I run, you know, all of my different applications on top of that.” This is not that world, and it takes a little while to wrap your head around it. Yeah, I think that kind of ephemerality, if that's a word— It is now. It is kind of part and parcel to that. If it's not gonna last forever, it doesn't have to be perfect so you can strip it down a lot more easily. Mm-hmm. That makes sense. And that's a rabbit hole you can really dive into if you want to. So I don't wanna spend too much time on it, but there is also the option of finding and using pre-made images from a public registry that fit your needs already. Typically, public registries think of places that you can just find online and pulling those images, just to, you know, I'd say be diligent, right? You know, it's always a concern to run code on your machine and with these images we can't always see from a glance or on a web search what is included in that image, right? To pull things down and inspect the different layers, what's been put together for this image, itself. And so just focusing on security, focusing on trusted sources. When I was younger, I didn't always focus on trusted sources and I downloaded Minecraft as a .exe on my computer and I got a virus and my parents were very upset. So I didn't have a very diligent security footprint back then. I try to say that I have a better footprint now, but it's always good to just keep in mind the sources that you're using and also to even set up your own internal image registry. Oh, that takes me back to the Limewire days. That is a mistake you only make once. Oh, was that before or after Napster? It was like the immediate successor. Okay. I think Napster, but it was very much that era. And yes, do not blindly trust things from the internet that goes for files and for information and everything in between. Yes. And back in those days when we were first using, I was first using Red Hat Linux because I'll be honest with you, guys, you're looking at a person who started using Linux because it was less likely to be affected by some of these things. Mm-hmm. And now, yes, I understand I need to stop saying that right now because we're in a different age, different world with that too. Oh my gosh, Emily, we're covering so many different topics without actually covering them, but we will. They're wide ranging. This season, we're definitely going all over the place and I love it. But yeah, no, don't trust your strange code from the internet is a very good mantra for all of us, always has been. I can never say it too much, for sure. You can never say it too much, please. So yes, we have container registries, companies, we, I mean, we, the Royal and also us. Go to those, don't go wild. A lot of the companies that I work with do have very strict guidelines around this also. So reach out to your security teams if you haven't already. By this time, I wouldn't have said that five years ago, but now definitely they already have. So, you know, utilize them. There's people already doing this work also. Yes. Everything is a potential glitter bomb. Open with caution. The glitter bombs. Yes. Moving right along, it is always an option to stand up your own private container image registry, just like Cedric said before. Having, like, a private way to do the tagging and to do the storage of your images is really important because there's even exploits out there that can upload unauthorized container images to your registries that's, it's important to understand how the attacks could happen and to kind of make sure that you don't fall for something like that, like a phishing attack to share your keys, because the thing is, you know we're sharing these containerized applications that still, while the footprint of a container is minimized because we can run it, you know, in different ways that might turn off the file system usage or remove the network, they still can be susceptible to vulnerabilities, albeit a much reduced factor. Okay, that makes sense. So what does a private registry look like? Okay. I gotta figure out a good metaphor for this too. Yeah, I'm kind of picturing, okay, you've got your public library, then you've got like your home library. Is that kind of the vibe? Right, but your home library doesn't, isn't as private as we're talking about here. Maybe you're safe. Okay. Maybe you're safe. We'll get there. We'll get there. Your diary. Your diary. Ooh, yes. I would definitely go much closer to diary. But this is like anything, same thing. There are, especially if you work for any large companies, there are people that are trying to social engineer you all the time. So just in all seriousness, they do know about containers. They know how Cgroups are used and et cetera to block all these things off. We're a lot safer now these days than we were when all this first came out 12 years ago or so. I sat in on some of those meetings where it wasn't as safe, it was easier to bleed through in the container world. So I'm not trying to get too serious. You know, I wanna be lighthearted and we'll talk about diaries. But it is safer now. It is safer now, but it is still an attack vector. So again, continue to keep up with your security teams. They will hopefully keep you up to date on anything that would be specifically attacking like your versions of all of this, going back to some of our earlier conversations about keeping your versions up to date, which is hard to do in large, , environments, but keeping a private registry, you should be working with your security team on doing that. If you are your security team, hello, good luck. No, no. Joking aside, yeah, this is— Thank you for your service. Thank you for your service. Seriously, I cannot thank you enough. , you are saving the internet, but definitely have your own private registry, make sure your users are just connecting to that and cannot connect out to the public ones because this is an attack vector, unfortunately. Yeah. The quarantined safe things. Yes. Go, go to those first and pay attention to your action needed, urgent, important emails. Oh my goodness. Yes. So here's, here's a quick one from Cedric as well where he warns us about some bad tagging habits. The most simple thing is, when we go to build a container image and we go to push that, sometimes we forget to add a tag and it just says “latest.” And the thing is, when you just use “latest,” even though it's a bad habit that I always do myself, it doesn't let us take advantage of one of the biggest benefits of containers, which is being able to have rollbacks and predictability over different versions of our application. Ah, yes. The, the latest, latest or latestest final, final, final. Things to avoid in taggings. So how should we be tagging containers? I laugh at this too. I feel like it's, remember, , we all do it where you just make a backup copy and call it dot BAK or dot—and then you go back later and you cannot figure out, "wait, which one? I didn't put a date. Oh, let me look at the timestamp on the file," but you could have edited that file. Yeah. This is very similar, right? So you wanna go in there and you pick your naming convention. If you wanna use the date, the cluster name, if you have particular applications where you know on this cluster people are going to be running, you know, ABC application and they need to have seven different versions, you're gonna go in there, you're gonna put the date, you're gonna put the cluster, you're gonna put the application name. You know, I'm just kind of, you know, spitballing here. There's all kinds of ways I've seen that people go in there and, and pick their nomenclature. Yeah. It's whatever you will need to be able to find and identify what you need. Yeah, because dot BAK doesn't work anymore, you know? You can, it didn't work back when we were doing it. And you know, you need to, you need to add more and this is something that folks really overlook. Cedric is completely right. They put the latest, they think, "Oh, that's good enough." No, one of the beauties of containers is that it's so easy to roll back. Mm-hmm. I've done it a few times in some of the, , I'm gonna say Atomic Linux, that's not what it's called anymore. And it's like blue, silver blue. There's a number of different actual entire operating systems that are kind of based around this concept now. They're not fully containerized. Yeah. It's so cool. So if you then go and update, as we always need to update, but then your application dies, you can actually roll your entire operating system back. But that, I should stop. That's an entire other episode. No, I think that's really interesting. Some things we've talked about, try to plan for the future, don't just call it latest, like try to have some kind of information, metadata in there, be kind to your future self, help you find what you need. Yes. So I think that's some good advice. And up next, we can kind of gaze into our crystal ball and evaluate what role containers are going to play in the near future. And as with the rest of the industry, we got into how AI and containers are coming together. I mean, this is probably the most important topic right now when it comes to infrastructure, is for AI, how do we run these models cheaply, efficiently, and securely? And that's what pretty much every team inside of every organization has been tasked with. Well, that's exactly where containers come back in, right? Because these are isolated environments where we have, you know, specific username spaces for each process that we're running and when it comes to models, we can still pass through the GPU acceleration for an NVIDIA GPU or an AMD GPU inside of that container. So we're still getting the full benefits of acceleration, but we're getting the capability to fine tune how that model can talk to our existing services and applications instead of just running it as a process directly on our hardware. So I think it's really important. It's gonna be one of the most talked about subjects in the next few years. So it sounds like AI and containers are a bit of a match made in heaven. So what are some of the ways that they work well together? The ability to scale up quickly. That autoscaling, again, not infinite autoscaling, but autoscaling up based on your user's use of whatever inference server, model, hardware acceleration you're doing, whatever it is, is absolutely fascinating. I've watched for at least a year now folks using, you know, OpenShift AI. So what that means is it's basically like the little pieces you'd need to run these models in OpenShift and I, and shameless plug for the thing that I support. I won't tell. I'm trying to keep it simple, but the ability to run, containerize all of this. And we already have a lot of the things already, all the services that you would need to containerize it. Like you don't even have to do it. Like we've already done it. So you go out there, you grab all that, but that ability to scale up and down because I don't know about everybody else, but the tokens. Mm-hmm. Y'all, the tokens, they're using all the tokens. It stresses me out to see the number keep going up. It keeps going up. So all of that, it's like this was already ready for that. And maybe it is because I don't know everyone and they were thinking about this ahead of time. I don't know. But it does really feel like it sounds really corny, but it really was made to go together. Mm-hmm. Yeah. Yeah. And so those, the different telcos that I work with and in the past, the financial services and all that, I see in my mind all of the different services that they offer to their customers and how they would spin up so quickly and use all the RAM. Now we're doing it with GPUs, right? So, one can easily use all of it, but now you can segment that out and say, "No, no, I'm sorry. I'm sorry. No, you can't." Like, "no, no, no. Here's your ration." Exactly, because it is. It literally is. Like that's all of our money going to the tokens right there. No, we gotta scale that back down. And, and you need to have that. I can't stress that enough how much you should have these conversations with your users if you are not the user yourself. Hey, users, if you're not having these conversations with your sysadmins and DevOps, you should. Yeah, absolutely. And better earlier than later. Yes, definitely. So cool. Well, this is the future though. I'm like, I just need to be just really excited for just another minute. This is so exciting. I can't help it. I'm such a nerd. I feel like it kind of goes the other way too. Like it helps run and kind of contain AI, but I imagine AI can also be helpful for spinning up containers. Yes. That's the other piece of it. It's the opposite too. Like knowing when and where and how. We don't have a person making all those decisions. You can work together with whatever your preferred, you know, I'm gonna say chatbot, but they're not anymore. These, these little agents and stuff doing a lot more than what a chatbot would do. So yes. Oh yeah. They're evolving quickly. And they can go through and analyze all those logs that we were talking about earlier. Mm-hmm. You know? Oh, it's so exciting. I know there's danger, but every bit of excitement comes with a little danger, right? I mean, I love a good self-replicating system and like this just like on paper at least, it looks perfect and that's really satisfying. And because I'm in day two, most of the time day-two support, the ways that folks can break this. Mm-hmm. I can't help it. I love, I love seeing all the ways that people break these things so they're gonna self-replicate until they've talked themselves into having environments that are just crazy. Yeah. So again, I'm speaking directly to my sysadmin friends out there. If you don't love how your users can break stuff, I don't know what you're doing in this business. Like let's do this. All new troubleshooting adventures. Yes. It's so fun. Never a dull moment, that's for sure. Never. Okay. So I think we covered a lot of ground here. I think we talked containers, they're great, but they need work. You have to keep track of them. You have to make sure that you're appropriately, you know, logging and observing what they're doing and you have to make sure they're coming from trusted places and not just from random corners of the internet. What else did we talk about? Tagging. Make sure you're tagging. Help your future self. Give your future self a present. Yes. Organize your stuff. It will make future you so much more happy. What do they say? Treat yourself. Treat yourself. Yeah, no, and I think, if you get it right, containers can play a really big part in your application success. I agree 100%. And I loved, again, going back to the beginning, I love talking to those. What I consider kids, they probably think they're all grown up, but they're much younger than me. It's just what they do. It's just, it's just a given. Oh yes, everything. We containerize everything. I'm like, "Oh, thank you. You're making my heart so happy." I think containers are here to stay. So the more comfortable you can get with them and the more you can build them into kind of your workflows in a really pristine kind of way, the better your life will be. I agree. So I think we've talked a lot about containers. So for all of our listeners out there, please hit us up on social media at Red Hat and use the hashtag #compilerpodcast and I think that'll do it for this episode of Compiler. This episode was written by Johan Philippine. Thank you to our guest, Cedric Clyburn. Compiler is produced by the team at Red Hat with technical support from Molly Brock. If you like today's episode, follow and review our show on your platform of choice. Until next time.

More about 容器

need a description here
博客文章

成本管理指标 Operator 镜像 2.0 有哪些新变化？

2023 年 5 月 30 日
容器
博客文章

RHEL 9 为开发和生产提供最新的容器技术

2022 年 8 月 8 日
容器

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.