WEBVTT 00:00.000 --> 00:12.800 All right everyone, we're ready for the next event, and in this session we're going to start 00:12.800 --> 00:21.560 out with a talk by Pierre Ozu Keber, who's going to talk about limo s h, the 9, basically 00:21.560 --> 00:27.960 the perspective on 9 years later, 11 and a last 9 years, right, and I think that's great 00:28.040 --> 00:33.560 because it's really difficult to have long lasting projects and to stick around and to stuff 00:33.560 --> 00:40.360 that's guys endurance, right? So, I'm really curious to hear more about this, and thank 00:40.360 --> 00:43.560 you very much, around the applause to speak of this. 00:43.560 --> 00:54.760 Thank you very much, I'm always amazed when screen sharing works on Linux. A quick 00:54.840 --> 01:00.520 thanks to Julian DuForn, that is here, and Ryan LaFa, that built this system which is called 01:00.520 --> 01:05.080 Securix, and it's a secure laptop that I'm currently using, they learned it to me for the 01:05.080 --> 01:13.640 presentation, but here, I will discuss about something else. So, we have a project called Libre.sh, 01:14.680 --> 01:22.280 and it's based on Linux containers, and we help organizations, we have free software for them, 01:23.160 --> 01:29.400 and we use a lot of nix. So, the idea is we want to build the package manager for internet 01:29.400 --> 01:37.160 applications, and we want your help. We are a French corporate chief, we are 5 employees, 01:38.040 --> 01:43.400 and the idea is to fight the technofasism, but here we are a bit humble, so one bit at a time, 01:44.040 --> 01:47.400 I will not explain why you are all, everybody here understand why. 01:48.360 --> 01:55.480 We have a new project, which is last week.co.op, we are 5 corporate chiefs in France again, 01:55.480 --> 02:01.320 so we get together, we are 14 employees, and the idea is to empower collaborative organizations 02:02.040 --> 02:09.480 towards digital sovereignty, and we host free software for them. So, we are a core philosophy, 02:09.480 --> 02:15.240 which we really believe in to our standards, well-defined standards by the community, 02:16.120 --> 02:19.880 and these standards help for the interoperability and federation, 02:21.160 --> 02:29.400 and we love to have beautiful implementations, hosted by foundation with nice governance. 02:29.400 --> 02:36.520 So, this is our dream goal about this ecosystem. Here, what we will cover, 02:36.840 --> 02:42.840 we will cover the problem that there are no standard way to describe an internet application 02:42.840 --> 02:53.080 on its dependencies. Our approach with Kubernetes, how we bring together Kubernetes and Nix, 02:55.000 --> 03:02.360 will go through a concrete example where we package an application from last week, 03:03.320 --> 03:10.120 this application is called Docs, and at the end we will discuss how we could build this together. 03:11.560 --> 03:19.080 So, have you ever tried to deploy some self-hosted application for you, for your family, for your company, 03:19.080 --> 03:28.200 or your organization? And yeah, you hit a ton of them, spending hours, okay, how this piece of software 03:28.200 --> 03:35.720 works, how do I connect my, does it need my RGB postgres, my SQL, which version, 03:36.520 --> 03:41.240 maybe it's postgres, maybe it's SQLized, how do I do this as a slow integration? What are the 03:41.240 --> 03:47.640 variables to plug it into my special SSO, and all these kinds of questions? And there are 03:47.640 --> 03:57.400 currently no standards to describe this as a metal level. Yeah, but yeah, just let's take just 03:57.400 --> 04:02.200 one step back for a quick moment. Yeah, what's what's in the internet application, basically? 04:02.200 --> 04:08.680 What's the job of a hosting provider like us? Yeah, beyond security, resiliency and scalability. 04:09.400 --> 04:13.880 So, our job, at the end of the day, it's quite, yeah, it's complicated, but yeah, it could be 04:13.880 --> 04:22.360 resumed to this. We have to manage data, like plug some disks, make it redundant, have backups, 04:22.360 --> 04:29.480 and be able to restore them. We need network so that we can connect some processes together, 04:29.480 --> 04:35.400 expose them to the internet, make sure the pipes are big enough that there are different 04:35.560 --> 04:41.080 redundant pipes to get there. And then at the end of the day, we have to manage the 04:41.080 --> 04:48.200 lifecycle of the process, which are like CPU and RAM, and yeah, what's the process? It's running 04:48.200 --> 04:54.440 binary, like some kind of artifact, that would process this data and serve them over the network. 04:54.680 --> 05:09.000 And yeah, we love Kubernetes because they take care of this, and they, the community around 05:09.000 --> 05:17.960 this project build beautiful standards for each of these areas. Not sure you're all familiar 05:18.040 --> 05:27.080 with Kubernetes, but so these are beautiful standards. There is a diversity of implementations 05:27.080 --> 05:35.000 of these standards. And this is hosted by the Linux Foundation, the CloudNative Computing 05:35.000 --> 05:43.880 Foundation. And what we also love is that it's declarative. So, at the core, Kubernetes, it's a 05:43.960 --> 05:50.920 beautiful API. And what's even more amazing is that you can easily extend it with something called 05:50.920 --> 06:01.960 custom resource definition. So, it's a way to declare a new object. And then you implement 06:01.960 --> 06:09.080 a controller operator to do the reconciled loop. So, basically, you say that in my dream, 06:09.720 --> 06:17.320 I want this object, and then the reconciled loop will make sure that your dream comes true. 06:21.160 --> 06:28.440 And in the end, we'd like to bring all this concept together to have a beautiful package manager. 06:29.480 --> 06:36.280 So, the responsibility of the package manager is to handle the lifecycle of the application 06:36.600 --> 06:44.680 to describe the dependencies. And there is some sort of registry where people could interact 06:44.680 --> 06:49.480 to pull the software from. So, I'm sure you're all familiar, and I'm sure I'm repeating, 06:49.480 --> 06:59.720 but it's always a bit risky. We are idealists, and yeah, maybe it's not realistic, 06:59.720 --> 07:04.920 but we'd like a standard way to describe an internet implication and their dependencies. 07:07.000 --> 07:14.680 We would love to have this. But, okay, let's start and get with our concrete example. 07:17.640 --> 07:23.320 So, here it's a collaborative software called Docs. It's developed by the French administration. 07:23.960 --> 07:32.280 It's free software. You can get it on GitHub. It's based on blogges and so on. And yeah, 07:32.280 --> 07:40.600 it's really nice and we love it. And we will see how we package this and how we run it in our infrastructure. 07:42.520 --> 07:52.600 So, at the high level, this is how it looks like the description of one instance of a 07:52.600 --> 07:59.800 Docs internet application. And this is like a Kubernetes representation of this object. 07:59.800 --> 08:06.920 So, this is a declarative thing. So, I post this on the Kubernetes API. And I say, 08:06.920 --> 08:16.600 yeah, please, I'd like to have Docs instance running on the domain name.example.org with this image. 08:16.600 --> 08:22.520 And yeah, it really helped with our infrastructure. We have this high level objects. 08:22.520 --> 08:29.960 And then there are implementations that distillates through the infrastructure to make it running. 08:31.080 --> 08:39.560 So, in the concrete, Docs depends on having like a Postgres, a Redis, an Object Store, 08:39.880 --> 08:46.920 an OpenI-D Connect client for a single sign-on. And once we have all these dependencies deployed, 08:47.960 --> 08:54.680 then we can deploy the backend, the front end of the Django. And then we can expose it to the 08:54.680 --> 09:05.880 internet. It's a traditional internet application. And how we do it is then for each dependencies, 09:06.840 --> 09:13.240 we have a clear interface, a clear abstraction. So, here it's like the Postgres abstraction. 09:23.480 --> 09:30.520 So, the Postgres abstraction, maybe it works, maybe not. 09:30.520 --> 09:40.920 Yeah. So, as you see, it's a simple object. Again, we can see that it's an object, 09:41.560 --> 09:51.400 and the name of the database is Docs. And so, again, this is declarative. And this is how Docs, 09:51.640 --> 10:03.160 this is how Docs implement this abstraction. So, it's basically in GoCode, this idea to have 10:03.160 --> 10:12.600 this Postgres database cluster that is also backup. And then this Postgres reconciler controller, 10:12.600 --> 10:18.760 then makes this cluster happen. And as we have this clear abstraction all the way. And so, 10:18.760 --> 10:25.400 Kubernetes, as you can see, helps us to describe our infrastructure and have clear 10:25.400 --> 10:31.080 abstractions so that we can reuse this Postgres abstraction over the different application we 10:31.080 --> 10:36.280 host. But then the question is how we describe the application that run on it. 10:37.880 --> 10:44.760 As you can see on the last line, there is a reference to a container image. So, in the Linux container, 10:44.760 --> 10:54.200 well, this is the address of the package. So, the current container image ecosystem has several 10:54.200 --> 11:00.920 problems. It's scattered. You have different ways and places where you can find. You have 11:00.920 --> 11:08.120 like the local official images. Bitnemy was used by big chunk of the community, but at the core, 11:08.120 --> 11:14.520 it was not open source. And it was owned by private company that got bought by VMware. And now, 11:14.600 --> 11:23.480 it's over. You can also find the images in upstream projects. But basically, you have different 11:23.480 --> 11:29.240 based images like Alpine, Deepian, Ubuntu, different tools inside, sometimes you have Dash, 11:29.240 --> 11:35.480 sometimes you have SH, sometimes none of that. And there is no easy patching when you did 11:35.480 --> 11:42.920 do it or remove something. There is no coherent versioning and no coherent vulnerability management. 11:43.800 --> 11:49.400 So, the requirement would be coherent base image, always the same tools. And maybe we can have 11:49.400 --> 11:53.480 a variation like for production and for debugging. And for debugging, we want all the tools 11:53.480 --> 11:59.960 and for production. We don't want any tools. We want the current versioning so that our 11:59.960 --> 12:05.720 operator can detect when there is a migration to run, for instance. We want to be able to patch 12:05.720 --> 12:11.800 the source because maybe sometimes there was a vulnerability, upstream, there was a patch, but they 12:12.120 --> 12:16.840 didn't release categories. So, we want to patch it and deploy it on our infrastructure 12:16.840 --> 12:22.280 quicker. And we want to make variations because we have different organizations and they want 12:22.280 --> 12:29.800 to different branding, for instance. So, there are already nice initiatives. So, some weeks ago, 12:29.800 --> 12:36.840 I think the German government, they started this container, got the, it's really new and I think 12:36.920 --> 12:41.960 it's really promising. So, I really hope that we can work together. There is also cloud 12:41.960 --> 12:51.000 pirates so that they are doing like the bitnamy takeover, do we get better, hopefully. But yeah, 12:51.000 --> 12:54.680 we'd like to push their approaches a bit further. And yeah, of course, we'd like to collaborate 12:54.680 --> 13:01.960 together. So, the dream container image registry, maybe it's a bit too dreamy again. We are a bit 13:01.960 --> 13:07.640 too idealistic, but we could imagine some kind of metadata on the next package that would say, 13:07.640 --> 13:12.040 okay, this package is available over the network because I think there are two kind of next 13:12.040 --> 13:16.680 packages or two kind of packages, some that are kind of deep dependencies and some that are 13:16.680 --> 13:22.920 exposed and you can use it over the network. We could imagine to have like a function, 13:22.920 --> 13:28.520 standard function, to say, okay, I want to take this next package and transform it to a container 13:28.520 --> 13:36.520 image. We could have some kind of function to easily patch and make variants. Then, like the 13:36.520 --> 13:42.680 next package, we could have a public container registry with all these images and we can have a 13:42.680 --> 13:50.840 sine bomb and scan vulnerabilities. So, this would be the dream. Our current implementation, 13:51.720 --> 14:00.760 which is far from perfect, basically, we'd like to track. So, what's the application? What's 14:00.760 --> 14:05.400 the components? Because, like Docs, it has two components, backend and fontan, for instance, 14:06.040 --> 14:11.320 what are the variants for theming proposed, plugins proposed? What's the application versioning? 14:12.680 --> 14:20.120 And what's the package versioning? Because, yeah, sometimes you have, sometimes you have 14:20.920 --> 14:25.880 to update dependencies like Postgres library, but it's not updating the application. So, in this 14:25.880 --> 14:29.240 case, you don't necessarily want to run the migration and shut down your application. 14:30.760 --> 14:38.120 So, at the end of the day, we'd like something like that. So, we can pull the 14:38.120 --> 14:43.480 the binaries from that and you can see, like here, it's like the application with Docs, 14:43.560 --> 14:50.840 the front and the backend are the components. The variant is material fronts or 14:50.840 --> 14:56.440 city of Lyon, for instance. So, they have different branding and simming. We have the version of the 14:56.440 --> 15:02.360 application and at the end of the line, we have the version of the package. This would be the 15:02.360 --> 15:10.440 hour API to build and push. So, that we have control on what we build and what we push. And, yeah, 15:10.520 --> 15:15.800 at the end of the day, we have one command to build all. And then, what's really nice with 15:15.800 --> 15:21.160 nix is that we can leverage the caching. And, yeah, that's one of the reason we use these nix. 15:21.800 --> 15:28.760 And, yeah, here it's, how it looks like we have a nix function. Mka up, where we describe 15:28.760 --> 15:34.200 the name of the application, the version, the package version, whites from GitHub. So, this helps 15:34.600 --> 15:42.280 us with the updates, we can get the new updates from GitHub, where all other source. Of course, 15:43.000 --> 15:49.960 here we describe the components and we have two variations, one with nix packages and one with 15:49.960 --> 15:55.880 container file. Here we describe variants, it's a function and, again, some metadata. So, 15:56.440 --> 16:03.800 then we can describe the license license. And here, how it looks like for containers, 16:04.280 --> 16:10.280 basically, from this Git repository, here's the Dockerfile or the container file and here are 16:10.280 --> 16:19.960 the build documents. If we build with nix packages, here, this is the nix package and here is the 16:19.960 --> 16:26.280 entry point. So, the first command to execute when we start to contain them. Then, once we build 16:26.280 --> 16:32.040 all of this, we have nice updates, we can update all our stack with one command and we love that. 16:32.280 --> 16:39.640 Here is the function for variants and, as you can see, we can patch different parts of the code. 16:41.640 --> 16:52.360 And then, thanks to the work of the nix community on SBOM, we can implement SBOM directly inside 16:52.360 --> 16:59.000 this container registry. So, for then, we have two approaches, if it is like a nix component, 16:59.160 --> 17:07.000 nix packages or a container. And so, we could use a bombo or 3v and so on for containers. 17:09.880 --> 17:16.600 So, we covered that there is currently no standard to describe an internet application. Our approach 17:16.600 --> 17:25.160 is to bring together Kubernetes operators and nix for reproducible and patchable images. 17:26.120 --> 17:32.920 And, I give you some sense of how it could work for real use case for this application 17:32.920 --> 17:40.200 last few talks. So, I'd like to thank, of course, the nix community for all these incredible 17:40.200 --> 17:45.320 work that you are doing since so many years, also with the help of NLNet, for instance. 17:46.120 --> 17:53.240 And also a colleague Hugo Rona that helped us to adopt and embrace the nix ecosystem. 17:53.960 --> 17:57.080 And if you want to try Docs, for instance, you could go there. 18:00.680 --> 18:06.360 And so, yeah, we are trying to build that dream and we'd like to build it together. And 18:07.800 --> 18:14.120 we are not nix experts, but yeah, I would love to love your feedback, how maybe we are two 18:14.120 --> 18:20.120 idealistics and maybe we are doing things that are not perfect, but yeah, I would like to have 18:20.200 --> 18:22.600 your feedback on that. Thank you. 18:35.080 --> 18:36.040 All right, thank you very much.