 So for this session we are two. My name is Steven Lummer, I'm Product Manager on Developer Tools and Paul. I'm Paul Hoxinger, I'm a Software Engineer at RedHead, I work on the Portman Container Manager. So what we are going to cover today? So we will start with an introduction about Portman which is really your gateway to containerization. And we will speak more about containers and Kubernetes and how you can go from one to the other with Portman Desktop and we will exhaustively spend time doing a demo of Portman Desktop. And then we will speak a little bit about our future plans as well. But let's start with an introduction about Portman and I'm ending it over to Paul. So let's talk about RedHead's Container's philosophy. So we know no solution fits every use case. So we built a variety of tools that can handle different use cases for you. There is Scorpio, Builder and Portman which focus on different kind of needs. So we use open standards, the OCI, the Open Container Initiative has several standards how to interact with containers and container images. We use open development, we develop on GitHub in the open. It's open source and it's open to the community. You can contribute, you can report bugs, we have community meetings, you can ask for our help. All of this is interoperable and compatible. All these tools work with the open standards and work together not only our own tools but also in the wider container ecosystem. So who here has used Portman before? Okay, so let's talk a bit about what is Portman. Portman is a container manager. It manages images, containers, ports, volumes and networks. And Portman is short for the port manager. So Portman uses a Docker-compatible CLI. So if you use Docker before, you will be very familiar with it. And it's also offering a Docker-compatible API. So if you have tools written against the API, you can also use them. We also support Kubernetes YAML. We have rootless support so you can run containers as your normal user. There is no daemon and we focus on security. And this is a tool for developers and this admins. So it works primarily on Linux but we also work on macOS and Windows with the help of Portman machine which creates a Linux VM for you on these platforms. So let's talk a bit about the architecture. Why did we decide to make Portman like this? So at the top, you see the architecture of Docker. So you have in the middle, the central piece is the Docker daemon running as root and then creating containers with the help of container D and the runtime. And everything has to go into that daemon. And if you run Docker as rootless, you usually just you talk to the root daemon and you have root privileges. It's not very secure and hard to keep track of. And if you are running on multi-user systems, that's really a mess. So with Portman, we decided to follow a fork-exec architecture. So the command, if you type on the CLI, the container will be a child of the, there's directly fork-exec into conmon, which is our container monitor. It's a very small program. It just handles the logging and makes sure if a container exits, we clean up our state and update if you look at the container states. So Portman can also be used for deployments and in production workloads. So we have a relatively new tool called Quadlet. This is a system D generator. And that can, you can see a unit like this here. If you're familiar with system D unit syntax, you will understand that. And there's a special container section where we just say, okay, let's take an image, UBI 9 minimal. We want the volume in there. Just give the path and what do we want to execute in the container. And in the server section from system D, we can say, okay, let's restart if there's a failure. So very simple with that. It's useful for the production. And if you want to know more about the production capabilities, check out retta.com sysadmin. My colleagues wrote very many articles on how to use all these Portman capabilities, including Portman auto update, which can keep your container images up to date with no user interaction. So let's summarize. Portman, we have a focus on the security part. So we run with as a Linux second minimal capabilities. And there are very lots of options that you can use to further strengthen the security of containers. It's Docker compatible. Kubernetes YAML support. We have a good system D integration. And with that, we can bridge the gap between a developer and the production because you can use the same tool for both. And with that, I hand you over to Stefan, which will show you how to use these capabilities for Portman desktop in an easy way. Thank you, Paul. So yeah, actually about bridging the gaps between developer and production, we know that when we are working with our local developer environments, usually have become both impractical and the lack of consistency with production environments. That is a challenge. There are a lot of complicated setup that needs to go in in order to get a local developer environment up and running. And also your laptop is naturally having limited resources compared to your production environments. It's also lack of consistency because the way you run things on your local environment are unlikely to be the way they are going to run on a live environment, especially if you are targeting Kubernetes. There are a lot of more pieces at work in a production environment, which are kind of difficult to reproduce on a developer environment. So a lot of discrepancies in the way you are running your containers locally, but also in the way you are creating composite applications and the way they are going to get configured to talk to each other. So we have all fights with configuring the networking between multiple microservices. And in fact, in order to solve that, a lot of developers, they are ending up using solutions like Compose, which is a nice solution. But in fact, when you are targeting Kubernetes, this is bringing another set of challenges. And you need to translate basically your application from how you run it locally to the way you are going to run it on a production environment. So there is this additional complexity and additional overhead, and there is also a skill gap. So in recent studies, we figure out that 70% of the IT departments have a single expert on Kubernetes, because Kubernetes is hard and it's difficult to ramp up on it. And that usually brings some disconnect between the developers and between the ops as well, because a lot of people are claiming that it creates some conflicts. And that's because there's challenges, challenges to go from production to deployment on production. So on one side, the developer during the inner loop, they are basically going to pull images that are going from different sources. Maybe the images will have low to no security. You may use different container registries and using Compose. And on the other side, on the upside, when you are on Kubernetes, then you are targeting to use base images that most likely are going to be curated, that will be defined to be validated to go on to production. You will have to use specific registries. The images will have to be rootless to use a specific set of ports as well. So there's a lot of things at work. And in fact, getting predictability to go from local to production is tricky. And it's also difficult on the day two operation when there is a bug that is happening on production and you want to reproduce that bug onto your local environment. So there is definitely technologies, discrepancies that are bringing barriers in the adoption of the technology. And basically, we see ops getting burdened by taking the artifacts from the developers to make them available for production. So basically, what we are doing with Podman Desktop is simplifying the workflows and the experience when you are working with containers and targeting Kubernetes. We are bringing Kubernetes closer to the developer. And as Paul mentioned during the intro of Podman, Podman provides capability in order to work with Kubernetes, so run Kubernetes objects, but also help you to really onboard into those Kubernetes objects in this world. So we aim to minimize the discrepancies between the desktop and the target Kubernetes environment and enabling simplistic onboarding to go from application to containers and then to pods and other Kubernetes objects and later on onto Kubernetes. So with Podman Desktop, you can really assure an application through the entire pipeline. You can start with containers. They can be translated natively to run natively with Podman as pod and then you can translate them to run them into Kubernetes. And you can test that locally with a simulated Kubernetes environment using kind or mini-cube. And or you can connect to a remote instance or remote cluster and just deploy your service there. So I'm going to get into the demo and show you how that works. So this is Podman Desktop. So when you arrive, you have the list of your containers. So you can see all the things that are running with Podman. You can also see all your images, volumes, and the things that are running with Podman. So when I click on the ready stack image, I can see a summary of the image. I can also see the history of this image and I can get all the metadata about it. I can click on this play button to create a container from this image. I have all the basic settings to add volumes, to do the bot mapping as well to define another but I have advanced settings as well as networking and security. I can also directly from here build an image. So if I have a container file, I can do that from here. And I can also go into the container list. So when I have a container which is running, clicking on it allows me to quickly access to the logs. So I don't need to remember the command. I can see the summary. I can inspect, get all the metadata and I can directly SSH inside of my container. So if I go do ready CLI, set hello developers up, get hello. That's it. So I'm able to directly interact with my application. I can also debug things more easily this way. So that's already a pretty convenient. If my application is opening a port like this one, for example, I can also just click here to open my application and I can see that it's running. I probably need to zoom in a little bit. So we mentioned that with Spodman, you have the ability to run Kubernetes objects locally, natively with Spodman. So here I have a simple pod but I can completely give a Kubernetes email file. So here it's going to be an HTTP container running in a pod and I can just say, hey, I want to run this with Spodman. So it creates a pod. I can see it here. When I get here, I can see the summary of my pod and I can also inspect everything which is going on. That's already pretty convenient and I can get access to the logs as well. Now let's say I have my application. It's running with multiple containers and I want to start moving from containers to Kubernetes. So we have the ability to select multiple containers and to basically bring them together as a pod. It's a feature that we are calling Podify. So I can just select my two containers here. So let me show you this application before. It's basically a Python application with a Redis database that I am using as a cache. So if I click on it and open it, I can see the number of times I have opened this application. But really when I'm going to run that onto Kubernetes, I really want to run the two containers together because it's my cache. I'm going to select my Redis container, my Python service, and I have this little button that allows me to podify my container. So I will copy the container inside of a pod. So it's showing me what are the different containers. It's showing me which part I do want to expose outside of my pod. And here in this context, I'm going to remove the part for Redis because I just want to use it internally as a cache inside of my pod. So let's create the pod. So what it does is that it stops the containers and it recreates them in a pod. Here it is. My pod starts. And I can see the different outputs of each of the different containers. And if I go into my Python app-podified container, I can still open my application and I can see that it's properly running as a pod. So that's cool. So already with Podman, I have capabilities to interact with Kubernetes objects, but there's one more thing that you can spin up a local Kubernetes environment. So here we have integrated with Skyne, which basically spin up a Kubernetes cluster into a container. So I'm going to just spin it up. And you can see that it's preparing the environment, making sure that I have the nodes, the control plane. And when the environment will be ready, I will have a container with Kubernetes inside that I can use for development purposes. So it's going to take just a few few more seconds. And that's it. So I have Skyne, which is running as a container with Podman. I can access it from here. And already from here, I can do a kubectl. And I will be able to interact also with the environment as well. So let's take the pod. And from the pod here, I can say, hey, this pod is running locally. That's cool. Now I want to deploy it onto Kubernetes. So I have this little cube tab, which allows me to generate the Kubernetes manifest for my application. So that's very handy. I don't need to write it. I can just say, hey, this is a Kubernetes manifest that I want to use in order to deploy my application. So here it detects my Skyne cluster. I can select the different Kubernetes contacts from here. And I can say, hey, let's deploy this application as a pod inside of Skyne. So it's going to take a little bit of time to spin it up. But you can see that the pod is now visible from running into Podman, but it's also visible from running inside of Kubernetes Skyne. So I can do that from here. That's fairly convenient already. And I can also, if I want, I can also change my Kubernetes context. And here in this case, I'm just going to switch to a remote environment where I will take my pod and I will just deploy it to this OpenShift environment. It's basically using developer sandbox that my colleague is going to introduce in the next session. It's providing you free environment online. And I can see my pod here getting deployed onto OpenShift. I can access the application if I want. And I can see my application running on a remote environment. So as you can see from Podman desktop, I have been able to go from the containers to pods running natively onto Podman to pods running inside of Skyne. And I can also deploy to a remote environment. So you have things that help you into your workflows, into your developer journey in order to simplify your onboarding because we are providing you some capabilities to get the Kubernetes manifest to deploy your containers onto Kubernetes. So that's about it for the demo. I'm going to head back to the slides. So Podman desktop, it's available today. It's providing capability to install and run anywhere. So you can run it on Windows, Mac, Linux. It will install the container on Jyn. It will keep it up to date as well as the Kubernetes local distribution. It will help you to manage containers and pods. You can also use Podman desktop against multiple container on Jyn. And it provides capability with compatibility with Docker out of the box. You also have some enterprise readiness features that allows you to configure VPN proxies, image registries, and you will also find an air gap bundle if you need to install it in a more constrained environment. It's free. It's open and completely extensible. So the way it is getting built is that it uses a virtualization stack, which we are calling the Podman machine. At the moment on Windows, it is relying on WSL. And on Mac, it is using QMU. On Linux, it's running natively. It's an electron-based application using Node.js on the server side. And on the front end, we are using the Velt and Telwin. It's extensible. So we are providing extension points inside of the UI. So you can really make it your own. You can extend it with your own flows if you need. You can add actions on to the list of images, on to the list of containers. You can add tabs, menus, and things like that. You can also completely customize the list of default progestries that are available out of the box. Right now, we are providing the most popular one, Docker Hub, Quay, the GitHub one, and the Google one. But you can also add your own in-house registry. And there's also extensions that are extending the online providers or the Kubernetes providers. At the moment, we have Podman, Khan, Lima, Docker, and OpenShift local. But there is a mini-cube extension that the community is currently building. So about the future capabilities, we wanted to provide a little bit of an overview of what we are going to work on. And maybe starting with Podman. So for a Podman machine, we are working on native Apple hypervisor support. And for Windows, we are working on hypervisor support. So what that means, that brings better performance and better stability to all developers on Windows and macOS. We also work on faster container startup. We are always looking to make Podman faster, to make the overhead as little as possible and as fast as possible. We also continuously extend the Kubernetes YAML support. So while we support many options from Kubernetes YAML, we do not support everything and we are adding new fields every release. Then we are also looking into a better rootless networking story because if you run containers rootless, usually networking is a bit more complicated and we are looking to make the friction there a bit less to make it more like you are expecting it to be. And you are really the future. You can tell us what you need, what you want from us and we can make it happen together. Yeah, it's really open. So feel free to join the community and bring your use case and the things that you want to see in the tool. From the Podman desktop side, so we are focusing on containers workflows. So exactly what Paul mentioned as the support of the native IP Advisor is going to be quite critical. We are currently working on improving the onboarding experience. So everything that is related to your first-time experience and configuring your environment, we are working on that. And by the way, we have discussions that are happening upstream. So feel free to join. Feel free to tell us what you think about the screens that we are going to add. And this will also help into making the configuration of the Docker compatibility a little bit easier that has been quite requested by the community. On the Kubernetes capabilities, so we are continuously improving the podify and QBify flow that I just demoed. We also are planning to bring more Kubernetes objects directly inside of the UI. Really, the goal is to help the developers that are targeting to work with, that are working with containers, but targeting deployment on a Kubernetes-like environment. So that's why all the capabilities around the UI for interacting with the Kubernetes objects are going to be important. And we have some mock-ups that are available as well. Feel free to join the discussion and to contribute to tell us what you think and how you need those features so that we can shape them in a way that will bring the most value for you. And also, because we know that a lot of developers are using Compose but sometimes are stuck when they need to transition to Kubernetes, we are also looking at how we can help on that aspect and make the transition smoother as well. On the OpenShift support, so we are working on a better support for the developers sandbox where you will be able to spin up a free remote Kubernetes environment directly from Podman Desktop. We will also bring an image checker, which provides some capabilities for helping you with the best practices in the way you need to shape your image. And that is going to provide a tighter OpenShift integration only for the people who need it and only for the people who are interested by it. It's always done through the mechanism of extension, so it's something you can pull it down if you want, if you need. You're not forced to do that. If you are interested to learn more, there is a Podman.io website where you can find a lot of materials around Podman. There is a website for Podman Desktop as well. You have the links for the repository. If you are interested by the project, if you are supportive of the initiative, feel free to drop us a star. It's always helpful. We always like to see that people are interested by what we are building and we are available also on different chat channels, so they are all bridged together. You can use Discord or Matrix or even ISC if you want. And there is a nice book around running containers on production with Podman, which is available on developers.radat.com as well. I really invite you to download this book. And with this, thank you.