Installation and setupįirst, you need to get Podman installed on your machine. So, let's get started on a quick developer's introduction to using Podman Desktop. I don't need to have a cluster up and running anywhere, and, in certain scenarios, I don't need internet connectivity either. Being able to (natively) build and run containers on my MacBook is a huge advantage for me when it comes to building demos for Kubernetes and Red Hat OpenShift. These definitions of Podman and Podman Desktop do not do either of the projects justice. The website describes Podman Desktop as "an open source graphical tool enabling you to work with containers and Kubernetes from your local environment seamlessly." Figure 1: The Podman Desktop user interface. And that's where Podman Desktop comes in (Figure 1). I sit in both camps I like to drop to the CLI when doing operations that need it, but I also like a nice, opinionated, rich UX.
It is a command-line utility some people prefer to use those rather than UX-based systems. Podman gives me all the functionality I need to build, pull, push, and test containers. In fact, it's actually a pre-configured Fedora VM that is executed on the Mac, with appropriate privileges to connect to the host file system. Containers can either be run as root or in rootless mode."Īs I mentioned, I use a Mac for development, and fortunately, there's a spin of Podman for the Mac. The Podman project actually defines Podman as "a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Podman is, put simply, Docker with some security enhancements-it solves the old problem of having to run your containers as root, which was always a worry for me when using Docker. Any problem I had, I would have to drop back to my Mac desktop, fix the code, git add, git commit, rinse and repeat. I would prepare all my source, create a Git repo, fire up the VM, ssh into it, clone the repo, build, test. To get around that problem, I actually hosted a Fedora virtual machine (VM), amusingly named 'builder', on which I did all my Docker builds. I also used Docker a lot in the early days, but had a problem when I switched to developing on my Mac instead. But this isn't an option for a lot of developers. I'm used to being able to just log onto an OpenShift cluster and do my builds, normally through Source-2-Image or just by pointing the system at a Git repo with a Containerfile. Developing locally in the container eraīut for the last four or so years, I've found developing containers locally a bit of a challenge. I've seen the agile revolution and the rise of containers, and I was there when Kubernetes crawled out of the sea and into our hearts. Well, I like to think that I am I spent twenty-odd years as a software engineer before joining Red Hat ten years ago, and since then, I've been evangelizing the company's tools and products from a developer perspective.
0 kommentar(er)
