 And off we go. Thanks for joining us. Welcome to today's CNCF live webinar. Let's talk about innovation and open source container developing developer tooling. I'm Libby Schultz and I'll be moderating today's webinar. I'm gonna read our code of conduct and then hand over to Phil Estes, principal at Amazon Web Services. A few ha... Before we get started, during the webinar, you're not able to talk as an attendee, but you can pop all your questions and comments into the chat box when we'll get to them as soon as we can. This is an official webinar of the CNCF and as such is subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. They're also available via your registration link you use to join us today and will be on our online programs YouTube playlist. With that, I will hand things over to Phil. All right, thanks so much, Libby. Sorry for the delay in getting started. As usual, there's always technology fund. And so my colleague here at AWS, Chris Short, is driving the slides because my system refused to play well with the Bevy tool. So, and I kind of hope to show some demos of Finch. I don't know if we'll figure that out when we get there, but for now we'll dive in and thanks again for hanging on while we got things started. So yeah, today I first, I think we'll start with some background so it makes sense why we're still talking and innovating around container developer tooling, command line clients, how you actually build and run and talk to registries when you're working with containers. So why don't you hop to that next slide, Chris? So it's been exactly 10 years since the Docker command line was famously demoed by Solomon Hikes at, I believe it was PyCon in April of 2013, and it's forever immortalized on the internet with his misspelled hello world, which had the crowd laughing along with him. But, you know, we've come a long way in 10 years. Next slide. And, you know, for the most part, I assume if you're building containers, yes, there has been some amazing work by Microsoft to have Windows containers. But, you know, when we started this journey, you know, people were building for a Linux platform. And so the concepts that make up containers, again, if we ignore Windows for a minute, are all about Linux technologies like namespaces and C-groups. And these were pieces of the Linux kernel. And I just saw Chris disappear, which means our slides have disappeared. So hopefully he'll come back in a minute. Uh-oh, here he is. Apologies. No problem at all. So I assume we get those slides back in a second. Yeah, so if we go to the next slide, you know, we've been building containers for Linux, and it's not just that these kernel features are critical to, you know, even the concept of what a container is, this process that's isolated in very specific ways. But there's other technologies we've added to that around security like SE Linux or App Armor, Setcom profiles, how images are even constructed, this idea of layers and these file system constructs of copy or unwrite file systems and the Linux capability system. These are all very integrated into our concept of what containers are. And so we're used to building and operating containers in the context of Linux. Next slide. But, you know, the interesting question is, what's that system that you sit in front of every day? Is it Linux or is it a Windows machine? It's many times dependent on your employer and, you know, the machine that they have is a common build that developers get in your company or a preference that you have for, you know, having a MacBook like many people do these days. Next slide. If you try and look for data, it's pretty tricky. So I, you know, distilled a lot of my rabbit trailing down to some averages. Mac OS and Windows, you know, again, you can quibble about specific percentages, but potentially up to 80% of developers aren't using Linux at work. And so when we marry these two things we've discussed, you know, what's that system that I'm, that my keyboard is attached to that I work with every day and where am I trying to run containers that I'm building and testing in my local environment, mostly targeting Linux? There's a mismatch there. Next slide. So, you know, now we're struck with this problem. I want to work with Linux containers, but I'm not on Linux. And a very easy solution that many people, including myself, used for years was, well, I can, you know, just have Linux in a VM somewhere. I can use it in the cloud. I can run, you know, software like parallels on my MacBook or on my Windows system, or I can use VMware. And yes, I mean, this is definitely a possibility. Now I'm running, you know, whatever that container software is, the Docker engine or container D or Creo on a Linux system. And I interact with it by having this VM. And, you know, maybe there's some complexity around now. I have to SSH in or I have to share file systems across this boundary and it becomes a little less easy to do my work. Next slide. And of course, you know, once we've added this solution, so to speak, we've brought new problems to ourselves because we now don't only have our laptop or our workstation and all the management that's either required by my employer or the fact that I'm just trying to keep it up to date. But now I have another OS image that has its own CVEs and flow of updates. And I have to, you know, if I get my system replaced, you know, I either have to preserve my VM image or configure it back the way I wanted it. And then I've already mentioned there's the whole issue around VM boundaries. You know, I have an IDE on my Windows or Mac system but I wanna share those files I'm editing into the VM so I can build it, you know, in my Docker file into a container and then networking and all kinds of other complexities of having essentially two systems. So all this boils down to I potentially inhibit, you know, just having a streamlined workflow because of the difference of what's on my host versus what's inside this VM with, you know, commands or scripts or tools that I like to use and it just creates complexity there. Next slide. So, you know, Docker recognized this early on and initially created a project called Docker Machine that was pretty popular that tried to hide some of the complexities of running this VM on your behalf. That then was developed into a more complete project called Docker Desktop that has continued on to today into an actual licensed product from Docker that they continue to develop and add extensions to. And again, for anyone in the sort of Docker ecosystem, this is a welcome addition to how to operate with containers no matter what operating system I use day to day. Next slide. And again, there's tons of benefits there because now, again, I'm back to this perception that it's just seamless. I just run commands and I don't worry about where there's a VM and who's managing what's inside the VM and how the pass-through magic happens. And also it gives them a chance to bundle relevant related tooling. So, Kube CTL and a local Kubernetes cluster and Docker Compose and all the other pieces that may be valuable to your workflow are there within this collection of projects that manage this on your behalf. Next slide. So that's great. You know, again, if the Docker ecosystem is where you work and operate, meanwhile, across the last seven, eight, nine years additional ideas around how we assemble container runtimes, what they look like, what they contain. I'm a maintainer of the CNCF Container D project. So obviously I spend a lot of my time focused on the Container D ecosystem. There's Podman and Creo coming out of Red Hat and a suite of tools that go along with that. And then, you know, I threw in even sort of the HPC community and work they've done to develop container runtimes, which again, are have a lot of the similar capabilities of building a container, you know, running a container, pushing it to a registry. But these are, you know, all potentially incompatible with specifically the Docker desktop product or ecosystem around it. Next slide. So, you know, again, as I said, as a maintainer of Container D, that's where I spend most of my time. It's now a graduated project with a mature user base. And there's a lot of sub projects around it. It's not just the one runtime. There's custom file system support. There's an image encryption project. There are people who now, you know, want to integrate Container D with pieces and software platforms built around Rust. And so there's Rust crates to tie into Container D either as a runtime or via the GRPC API. There's C group projects. And then one that I really want to highlight that's going to play into our discussion today is Nerd CTL was created just a couple of years ago to provide something that Container D didn't have when we created it. And that is a compatible set of command line flags and sub commands that match the Docker command line interface. Now, additionally, it's important at this point to mention BuildKit because Container D also wasn't created with the idea of encapsulating the whole concept of assembling a container, again, the traditional way of being using a Docker file, running it through Docker build, and getting a container that you can push to a registry. And so BuildKit is that project that came out of Docker. As its own open source project has expanded its capabilities, it can build or run C, it can build on Container D. And so together, having BuildKit plus Nerd CTL provides two missing pieces in the Container D ecosystem around having that compatibility with, for example, the Docker command line. Next slide. So we're kind of back to where we started in that. Well, that's great. Container D is a Linux project. BuildKit is a Linux project. But what's the solution when I'm back on my Mac or potentially on Windows? And I still want to use these projects to build and run containers in my local development environment. So I've already mentioned Nerd CTL provides that Docker-compatible command line. It also has compose support. So all the commands around Docker compose that you would expect are there. And then Lima is this missing piece that was created by one of our Container D maintainers, Akihiro Sudak created Lima, which is now also contributed into the CNCF as a sandbox project. He uses QMU for virtualization. And he wrote it specifically. Again, his own use case was I have Container D. I want to put it inside of VM. And on my Mac, just get this simple pass through, both for file sharing and handling the commands of the flags, all passing through to Nerd CTL and Container D and BuildKit inside the VM. Now, you can use Lima for a lot of other use cases. But again, his personal use case was around this idea of similar to Docker machine or Docker desktop providing the same pass through experience. So it feels natural to run Nerd CTL or Container D commands on your host and have all the management of the VM and the pass through handled on your behalf. The cool thing is that because Container D, as I mentioned, has other sub projects, Lima plus Nerd CTL plus Container D has allowed that specific set of components to expose other experimental features that are part of Container D, the engine, the runtime. So Lazy Loading Snapshotters is a big area of investment and innovation as well as some of the other projects like image encryption that I mentioned. You also get out of the box, if you use Lima plus Nerd CTL and Container D, you get rootless unprivileged mode. And if anyone has worked with rootless unprivileged Container Runtimes, it can get a bit complex to set that up yourself. You have to have some other scripts that handle the rootless networking and other pieces. And so Lima packages this for you by default and gives it to you out of the box. And so there's two other popular projects that have built on the same stack. One is CoLima, you can easily find it on GitHub. And then Rancher Desktop, initially created by Rancher who are now under the SUSE platform, SUSE acquired Rancher a few years ago. Both CoLima and Rancher Desktop have built development platforms on Lima using Container D and Nerd CTL, as I mentioned. Next slide. So that brings me to another open source project that was just founded and launched last November. And so we have a team here at AWS who contribute to Container D because we use Container D heavily in our cloud services at AWS. And looking for solutions for the same, same problem we started talking about right from the beginning. Thousands of developers using MacBooks, they want to develop and test in that sort of tight local development loop. And so looking at our contributions to Container D and the work that was happening around Nerd CTL and Lima. And as I mentioned, having build kit there as well, we decided that that same stack would be a great kind of building block on which we could build our own tooling for this compatible command line for developers to be able to build, run, test, push and pull images to registries on their own systems. And so we also wanted it to be easy to get. So having releases through Homebrew and also Apple signed installer releases means it's something that we can distribute very easily. You can install it with almost a single click and supporting both the Mac Silicon, so ARM64 based and Intel based Macs. And then, you know, again, we started small. We wanted to get it out there to get feedback, but we would love and are looking at this year adding an extension framework similar to ones you find in Docker desktop or Podman desktop, allowing, you know, for example, partners to have image scanning extensions or extensions that maybe work with cloud services or cloud authentication frameworks. And then the other important piece is that, you know, we started focused on sort of fixing our own problem, which was Mac OS centric, but we are planning and would love community help to also look at adding Windows and Linux support. So that's kind of the core of what we launched late last year. We continued to develop it in the open. It's an open source project with a team here at AWS working on it full time. And we're even looking and hoping for external contributors who even want to become maintainers of the project. Next slide. So yeah, at this point, I was gonna show off some commands now. If you've used Docker at all, maybe you'd say, well, it's not all that exciting because you're just typing the same commands but putting Finch where you would put Docker. So, you know, Finch images to see the list of images, run a container with a command, pull a new image from a registry like pulling the MySQL latest container image from Docker Hub. So, you know, the magic is not that you get the Docker commands. It's again, the lack of any management you have to do of the VM and the lack of any work you have to do to handle passing through your home directory or extra directories you want mounted inside the VM and the networking and sharing the ports back to your host system. Yeah, Chris, so I'm trying to think, I had a little compose file that I was gonna show, but again, you know, maybe we'll just continue. And then if people have questions and want to see anything specific, you can hop into your terminal and we can try some things out. But for now, we can go on to the next slide. So, as I mentioned, Finch is not a replacement for any of these projects. We created it because we were already working upstream in container D as we started to think about assembling a tool like this. We made some contributions to Lima. We've been actively working in Nerd CTL. And again, you know, build kit is not part of the container D project, but it's a very key project that is important to the build subsystem of not just Finch, but many other projects, including the Docker engine now uses build kit. And we also work in the OCI specs on features that are important to future capabilities like attaching signatures and S-bombs to your container images. And so when we think about collaborating with others on Finch, it's not just our Finch repo that we care about. It's all these other projects that we want to collaborate with because they're the building blocks of not just Finch, but many other technologies and software projects that are out there. I mentioned this, but I want to reiterate that Finch is not an AWS project. It's not an AWS product. It's a community open source project that we started, but we want to work on it in public with a public roadmap, with external contributors. And it's been exciting to have some early contributions, but we would love to have more. I've already mentioned that adding OS support for Windows and Linux is high on our priority list. And then having this extension framework because obviously a lot of, just like with Docker desktop or Podman desktop, one of the values is being able to add other capabilities without having to change the underlying project itself. So for example, allowing Aqua security or any or Datadog to have an extension to plug in some of their capabilities, they don't want to add that directly into Container D or the Finch project. They want to be able to have an extension that works for Finch or for Podman or for Docker. And so that's another key feature that we think will unlock a lot of extensibility for Finch. The GitHub project is here, should be simple to find. We also have a Finch channel on CNCF Slack where we've had some good community discussion with others, but it's still very early days and would love others to drop in there and give us feedback. I think we have, is the next slide just sort of a wrap up with some links? Yeah, okay. So there's a few more links here that Chris put together on, again, getting to the Finch organization. We have a blog post that explains more that Chris and I participated in writing about why we created it. That's easy to find. And then again, a lot of this is based around our existing work in Container D, not just myself, but we have a container runtime team here at AWS that works upstream in Container D and some of the sub-projects. And I'm easy to find online as well if there are future questions or you're interested to reach out on any of these topics. So I will stop there. Chris is available if we wanna look at anything from a demo perspective, but also happy to answer any questions that anyone would have. Okay, now's the time to pop a question into the chat and let us know. Otherwise, I'll know that I've perfectly explained everything. Yeah, so break question, Gerardo, hopefully I got your name correctly. So there are, well, I think one of the ways to start this answer is to recognize that people have favorite IDEs or there's the classic VI versus Emacs, which maybe is less of an exciting war as it used to be when we have fancy VS code and cloud-based IDEs these days. So we don't see Finch as necessarily, you should pick Finch because item bullet points one, two, or three. There are people for whom the Docker ecosystem is perfectly fitted for what they want to accomplish. For us specifically, AWS has, I'm sure many know, a fairly massive customer base who pay to run their workloads on AWS and many of those workloads today now running containers. And if they're running it on Fargate or EKS, it's probably running in container D as the container runtime. And so Finch gives us that ability for those companies who also have a significant developer base who all have laptops and are building their applications and containers, Finch gives them a way to use the same technology that AWS is using when they run their workloads in production. And it also potentially for some of those customers, they would like to make sure that if they have a problem talking to ECR public, AWS's public container registry or their ECR private registries, they know that if AWS are experts in Finch because we collaborate with others in the project, then we can help them, we can debug their issue. If they're using Docker or Podman, they have to go seek out help from those communities. And so that's kind of our natural bet to have a tool that's built using a lot of the same components, but it's one that we have expertise in and it uses the same container runtime that we use in production and have expertise in. And so debugging complex problems and giving developers a similar stack so that hopefully if there's some quarter case issue, they can even see it locally as well as seeing it maybe in one of our production services. So that's a bit low-witted answer, but I think people choose the tools that make sense for their environment. When people ask about Podman, for example, I know most of that team because many of them worked in the upstream Docker and other container communities for the same eight or nine years that I have, they've created a set of tools that make a lot of sense because they're very well integrated with RHEL and Fedora and OpenShift. And so that also can work for people who aren't in those communities, but maybe there's a more natural affinity in those communities because again, there's a similarity. OpenShift is using Creo, which is the same core libraries that Podman uses as well. So that's kind of this, I think my answer around affinity for the communities you're in. You also mentioned, so no Docker loops or binaries will be used. Yes, that's correct in the sense that when you install Finch, you're getting a Lima VM with container D installed inside on top of a lightweight Fedora Linux OS image with BuildKit. The only reason I'm being very precise is that Docker, if you install Docker, you also get BuildKit and container D and RunC. So we're sharing common components, but there's no actual Docker engine binaries or any components from Docker involved in that sense. So I hope that covered. I'm happy to follow up covered kind of your multi-part questions. Okay. Anyone else? There's one more shot for a question. All right. Well, Phil and Chris, have you popped into the chat maybe any of your handles or Slack channels so that if anyone has any questions, they can follow up with you. Oh, there we go. Richard. Yeah. So as I mentioned, I think earlier in the presentation, Finch supports both Apple Silicon and Intel. The cool thing about QMU and some of the features in the Linux kernel is that you can target, so again, you're building Linux containers on your MacBook that is either Apple Silicon or Intel, but you can actually target either platform on Linux. So you can target Linux slash RM 64 or Linux slash AMD 64 by using the dash dash platform flag in Finch, which is the same flag again that you would use with Docker or any of the other tools I mentioned. So it supports both architectures and a cool added benefit of the QMU static support in the kernel is that you can essentially cross build to either architecture. So if you have an RM 64 Mac, but your company targets Intel-based CPUs in your production cloud scenarios, then you can build Intel-based 64-bit images and test them out. You can run them locally, but obviously then they would run naturally in a Linux Intel environment in the cloud. Yeah, thanks, Chris. Chris put some links there. We also have the Finch channel in CNTF Slack. So that's a great place to catch up with us 20 minutes from now or two days from now, you're like, oh, I would love to get an answer about this. We'll be happy to connect with you there as well. There you go. All right, unless anyone has any other questions, we will wrap things up. All right, thanks so much, Libby. And thanks to those that joined. And again, happy to take other questions in the future. This was great. Thank you so much, Phil and Chris for joining us. Thank you everyone for joining our webinar. It will be online shortly this afternoon and join us again for more online programs and we'll see you next time. Thanks everybody. Thanks.