All right everyone, we're ready for the next event, and in this session we're going to start
out with a talk by Pierre Ozu Keber, who's going to talk about limo s h, the 9, basically
the perspective on 9 years later, 11 and a last 9 years, right, and I think that's great
because it's really difficult to have long lasting projects and to stick around and to stuff
that's guys endurance, right? So, I'm really curious to hear more about this, and thank
you very much, around the applause to speak of this.
Thank you very much, I'm always amazed when screen sharing works on Linux. A quick
thanks to Julian DuForn, that is here, and Ryan LaFa, that built this system which is called
Securix, and it's a secure laptop that I'm currently using, they learned it to me for the
presentation, but here, I will discuss about something else. So, we have a project called Libre.sh,
and it's based on Linux containers, and we help organizations, we have free software for them,
and we use a lot of nix. So, the idea is we want to build the package manager for internet
applications, and we want your help. We are a French corporate chief, we are 5 employees,
and the idea is to fight the technofasism, but here we are a bit humble, so one bit at a time,
I will not explain why you are all, everybody here understand why.
We have a new project, which is last week.co.op, we are 5 corporate chiefs in France again,
so we get together, we are 14 employees, and the idea is to empower collaborative organizations
towards digital sovereignty, and we host free software for them. So, we are a core philosophy,
which we really believe in to our standards, well-defined standards by the community,
and these standards help for the interoperability and federation,
and we love to have beautiful implementations, hosted by foundation with nice governance.
So, this is our dream goal about this ecosystem. Here, what we will cover,
we will cover the problem that there are no standard way to describe an internet application
on its dependencies. Our approach with Kubernetes, how we bring together Kubernetes and Nix,
will go through a concrete example where we package an application from last week,
this application is called Docs, and at the end we will discuss how we could build this together.
So, have you ever tried to deploy some self-hosted application for you, for your family, for your company,
or your organization? And yeah, you hit a ton of them, spending hours, okay, how this piece of software
works, how do I connect my, does it need my RGB postgres, my SQL, which version,
maybe it's postgres, maybe it's SQLized, how do I do this as a slow integration? What are the
variables to plug it into my special SSO, and all these kinds of questions? And there are
currently no standards to describe this as a metal level. Yeah, but yeah, just let's take just
one step back for a quick moment. Yeah, what's what's in the internet application, basically?
What's the job of a hosting provider like us? Yeah, beyond security, resiliency and scalability.
So, our job, at the end of the day, it's quite, yeah, it's complicated, but yeah, it could be
resumed to this. We have to manage data, like plug some disks, make it redundant, have backups,
and be able to restore them. We need network so that we can connect some processes together,
expose them to the internet, make sure the pipes are big enough that there are different
redundant pipes to get there. And then at the end of the day, we have to manage the
lifecycle of the process, which are like CPU and RAM, and yeah, what's the process? It's running
binary, like some kind of artifact, that would process this data and serve them over the network.
And yeah, we love Kubernetes because they take care of this, and they, the community around
this project build beautiful standards for each of these areas. Not sure you're all familiar
with Kubernetes, but so these are beautiful standards. There is a diversity of implementations
of these standards. And this is hosted by the Linux Foundation, the CloudNative Computing
Foundation. And what we also love is that it's declarative. So, at the core, Kubernetes, it's a
beautiful API. And what's even more amazing is that you can easily extend it with something called
custom resource definition. So, it's a way to declare a new object. And then you implement
a controller operator to do the reconciled loop. So, basically, you say that in my dream,
I want this object, and then the reconciled loop will make sure that your dream comes true.
And in the end, we'd like to bring all this concept together to have a beautiful package manager.
So, the responsibility of the package manager is to handle the lifecycle of the application
to describe the dependencies. And there is some sort of registry where people could interact
to pull the software from. So, I'm sure you're all familiar, and I'm sure I'm repeating,
but it's always a bit risky. We are idealists, and yeah, maybe it's not realistic,
but we'd like a standard way to describe an internet implication and their dependencies.
We would love to have this. But, okay, let's start and get with our concrete example.
So, here it's a collaborative software called Docs. It's developed by the French administration.
It's free software. You can get it on GitHub. It's based on blogges and so on. And yeah,
it's really nice and we love it. And we will see how we package this and how we run it in our infrastructure.
So, at the high level, this is how it looks like the description of one instance of a
Docs internet application. And this is like a Kubernetes representation of this object.
So, this is a declarative thing. So, I post this on the Kubernetes API. And I say,
yeah, please, I'd like to have Docs instance running on the domain name.example.org with this image.
And yeah, it really helped with our infrastructure. We have this high level objects.
And then there are implementations that distillates through the infrastructure to make it running.
So, in the concrete, Docs depends on having like a Postgres, a Redis, an Object Store,
an OpenI-D Connect client for a single sign-on. And once we have all these dependencies deployed,
then we can deploy the backend, the front end of the Django. And then we can expose it to the
internet. It's a traditional internet application. And how we do it is then for each dependencies,
we have a clear interface, a clear abstraction. So, here it's like the Postgres abstraction.
So, the Postgres abstraction, maybe it works, maybe not.
Yeah. So, as you see, it's a simple object. Again, we can see that it's an object,
and the name of the database is Docs. And so, again, this is declarative. And this is how Docs,
this is how Docs implement this abstraction. So, it's basically in GoCode, this idea to have
this Postgres database cluster that is also backup. And then this Postgres reconciler controller,
then makes this cluster happen. And as we have this clear abstraction all the way. And so,
Kubernetes, as you can see, helps us to describe our infrastructure and have clear
abstractions so that we can reuse this Postgres abstraction over the different application we
host. But then the question is how we describe the application that run on it.
As you can see on the last line, there is a reference to a container image. So, in the Linux container,
well, this is the address of the package. So, the current container image ecosystem has several
problems. It's scattered. You have different ways and places where you can find. You have
like the local official images. Bitnemy was used by big chunk of the community, but at the core,
it was not open source. And it was owned by private company that got bought by VMware. And now,
it's over. You can also find the images in upstream projects. But basically, you have different
based images like Alpine, Deepian, Ubuntu, different tools inside, sometimes you have Dash,
sometimes you have SH, sometimes none of that. And there is no easy patching when you did
do it or remove something. There is no coherent versioning and no coherent vulnerability management.
So, the requirement would be coherent base image, always the same tools. And maybe we can have
a variation like for production and for debugging. And for debugging, we want all the tools
and for production. We don't want any tools. We want the current versioning so that our
operator can detect when there is a migration to run, for instance. We want to be able to patch
the source because maybe sometimes there was a vulnerability, upstream, there was a patch, but they
didn't release categories. So, we want to patch it and deploy it on our infrastructure
quicker. And we want to make variations because we have different organizations and they want
to different branding, for instance. So, there are already nice initiatives. So, some weeks ago,
I think the German government, they started this container, got the, it's really new and I think
it's really promising. So, I really hope that we can work together. There is also cloud
pirates so that they are doing like the bitnamy takeover, do we get better, hopefully. But yeah,
we'd like to push their approaches a bit further. And yeah, of course, we'd like to collaborate
together. So, the dream container image registry, maybe it's a bit too dreamy again. We are a bit
too idealistic, but we could imagine some kind of metadata on the next package that would say,
okay, this package is available over the network because I think there are two kind of next
packages or two kind of packages, some that are kind of deep dependencies and some that are
exposed and you can use it over the network. We could imagine to have like a function,
standard function, to say, okay, I want to take this next package and transform it to a container
image. We could have some kind of function to easily patch and make variants. Then, like the
next package, we could have a public container registry with all these images and we can have a
sine bomb and scan vulnerabilities. So, this would be the dream. Our current implementation,
which is far from perfect, basically, we'd like to track. So, what's the application? What's
the components? Because, like Docs, it has two components, backend and fontan, for instance,
what are the variants for theming proposed, plugins proposed? What's the application versioning?
And what's the package versioning? Because, yeah, sometimes you have, sometimes you have
to update dependencies like Postgres library, but it's not updating the application. So, in this
case, you don't necessarily want to run the migration and shut down your application.
So, at the end of the day, we'd like something like that. So, we can pull the
the binaries from that and you can see, like here, it's like the application with Docs,
the front and the backend are the components. The variant is material fronts or
city of Lyon, for instance. So, they have different branding and simming. We have the version of the
application and at the end of the line, we have the version of the package. This would be the
hour API to build and push. So, that we have control on what we build and what we push. And, yeah,
at the end of the day, we have one command to build all. And then, what's really nice with
nix is that we can leverage the caching. And, yeah, that's one of the reason we use these nix.
And, yeah, here it's, how it looks like we have a nix function. Mka up, where we describe
the name of the application, the version, the package version, whites from GitHub. So, this helps
us with the updates, we can get the new updates from GitHub, where all other source. Of course,
here we describe the components and we have two variations, one with nix packages and one with
container file. Here we describe variants, it's a function and, again, some metadata. So,
then we can describe the license license. And here, how it looks like for containers,
basically, from this Git repository, here's the Dockerfile or the container file and here are
the build documents. If we build with nix packages, here, this is the nix package and here is the
entry point. So, the first command to execute when we start to contain them. Then, once we build
all of this, we have nice updates, we can update all our stack with one command and we love that.
Here is the function for variants and, as you can see, we can patch different parts of the code.
And then, thanks to the work of the nix community on SBOM, we can implement SBOM directly inside
this container registry. So, for then, we have two approaches, if it is like a nix component,
nix packages or a container. And so, we could use a bombo or 3v and so on for containers.
So, we covered that there is currently no standard to describe an internet application. Our approach
is to bring together Kubernetes operators and nix for reproducible and patchable images.
And, I give you some sense of how it could work for real use case for this application
last few talks. So, I'd like to thank, of course, the nix community for all these incredible
work that you are doing since so many years, also with the help of NLNet, for instance.
And also a colleague Hugo Rona that helped us to adopt and embrace the nix ecosystem.
And if you want to try Docs, for instance, you could go there.
And so, yeah, we are trying to build that dream and we'd like to build it together. And
we are not nix experts, but yeah, I would love to love your feedback, how maybe we are two
idealistics and maybe we are doing things that are not perfect, but yeah, I would like to have
your feedback on that. Thank you.
All right, thank you very much.