Thank you all for being with us. It sits 30 p.m. Actually sits 31 p.m. I'll make sure this
taught us really small and quick so that we all can live and have our favorite refreshments
and enjoy some delicious, built-in food. Again, thank you. So, what does top sprangler
well, I'll come to that slide. Awesome. I hope you can hear me now. I'm not going to repeat what
I said. Well, all right, the agendas slide is here who are we, I will just go through what
who are we, what is that swanler, why are we doing this and give you a very brief overview of
the system? Ethan will give a demo then it's all up to you to ask the questions and we can
head up soon. So, I'm Carvee. This is Ethan. We come from Griker. It is for those who don't
are Griker. It is one of the biggest insurance companies in U.S. It's highly regulated and we come
from an operating systems, containers and runtime team and our mission is to deliver compliant
and secure operating systems, containers and language one times. So, what is top sprangler?
Well, I would like to call it the brothel that I'll download the image building and management
where we get to build based images, container images and effective secure way where we can
reduce the number of redundant processes and operations which are integrated fully with the
CI pipelines and what did we build it? Well, there are several open source tools. One of the best
is that they have, there are many of them where we can build a single golden image in a secure
efficient way. What we wanted was like for our use cases, we have like multiple versions of
Ubuntu, say like two versions of Ubuntu, four versions of Pareto and like three versions of
Tomcat. Last thing we want to do is build them 24 times. So, one config file where we get to have
all the versions specified and then build them without redundancies, manual interventions and
the best part is we also have like a lot file through which we get to maintain the
versions of the dependencies in a accurate way. It's actually what we want. Our design
considerations where scalability, flexibility, making sure it is fully integrated with the CI
pipelines and efficiency. That said, I'll give them my two items.
All right, can everyone hear me all right? Awesome. So, over here we have a graphic showing the
overall design and what we were looking for in an image building system. So, the most important
part is that it's automated. We previously came from teams where automation wasn't a priority
and that creates a lot of ops burden on the team itself. And so, this really influenced our
design and we started with a nightly runner that updates our configuration. And so, we wanted to
write our definitions of code as configuration. And so, by the design we decided we have a
lock file that is machine generated. We have a configuration file that is human generated. And
those two work together to create a history of all changes of versioning that happens. And that's
great for auditing purposes. It also allows us to have closer to reproducible builds. We do do
a little bit of updating so that it's not 100% reproducible right now. We are working towards
that in the future. We also want to integrate automated testing and then have automated publishing
all using GitHub actions with the touch-rangler tool itself. And so, one of the greatest parts
of touch-rangler is automated dependency updates. And we start with Docker images. So, we need to
find our base image. In most cases, it's a boon too. We also can support red hat. But any Docker
image can be used as a base image in touch-rangler. We then specify the tags that we want to
track in using mutable tagging like Jamie for a boon too. We can automatically pull the latest version.
So, in this graph up here, we start with our configuration. In this case, a boon to Jamie.
We then pull the image from Docker and fetch the actual versioning like 22.04 Jamie. We also
track the registry and the digest of that exact image. And that's written to the lock file. So,
this means every night when we update our lock file, we're seeing the exact digest that all of our
images are being built with. We also do a similar process for a GitHub. For instance, Amazon
Coreto, which we've decided to use as our Java runtime, is hosted on GitHub. And here we fetch
the GitHub repo. And then we look through all of the branches. And we pattern match those with
our target version. In this case, it was Amazon Coreto 21. So, after we fetch the versions, we
match the target. And then we write up those exact versions to our lock file. So, I'm going to
do two different demos. They're pre-recorded. The first one will show how we build Java runtime
using Amazon Coreto with Touch Wrangler. And then in the second ones, a little more abstract
example on the powerful capabilities of Touch Wrangler. And so, again, building simple runtime
languages. And this case is going to be Amazon Coreto. So, we start by defining our base. Here,
we're defining a boon to. We're telling it, which versions we care about. In this case, it's
Jamie and Focal. We define the package manager. And then we have a couple extra fields that are
used for the internals. And then the most important part is where we fetch the version. This
tells us that we use Docker. It tells us how to find the image. And then there's a command that
we run to fetch the actual version. This allows it to be extremely expandable for any different
operating system or any different base that we would want. We can define our own command and fetch
that version. So, next, we define a feature. In this case, Amazon Coreto. And we can specify the
versions we want to look for. And that's used for the pattern matching on the branches or tags.
In this case, we're tracking the major LTS versions. So, Amazon Coreto. 21, 17 and 11. And then
we specify that. We fetch the version by using GitHub. And we just provide the organ the project.
We do have a lot of support for templating in most fields, as you can see in version tag in project.
And then we get to define the installation. And so, here we're setting the Java home. We use app
to use Amazon's repositories to install the desired version of Java. As you can see here,
we're using a lot of templating for the versioning. This allows us to write the versioning once.
And no matter what version we want, we can get it. Once we go to the lock file, which we'll see
in a minute, we'll see some more rigorous versioning. So, we can also define the installation for
separate package managers. The previous example was using app. In this same configuration,
we've also defined the installation for young. And so, this means that no matter what package
manager we're using, if our base has apped or young, we can install Amazon Coreto on it. No
matter what version of Amazon Coreto we want, or no matter what type of after young repositories
we're using for installation. Once you do that, we generate our lock file. So, here we have the
booty base from before with the exact versioning we're using as well as the digest. So, every
image that's built with this lock file, we'll use this exact digest every single time.
We also have a definition of Coreto here. In this case, it's version 11. The 11 in our target
version was normalized to 11 0 2641. And as you can see on our installation, we're no longer
insulating by template. We actually have the specific version in the install steps.
So, here's a brief recording. I'll start by showing that we have our Wrangler.com.
Well, that's the human written configuration file in the entry point. And this is just showing
that it has the examples that we had before. Here we have Amazon Coreto 811 1721. And we have
bases Ubuntu and REL. And so, we're starting by fetching the versioning from Docker. So, we're
pulling the Ubuntu jammy image. We're going to run our versioning command on that. And then once
that's done, it'll be written to the lock file. And we're also doing the same for Red Hat. Right
now, things are working synchronously. We're working to make things happen more synchronously
to speed up this process. But since it's normally done in CI, we don't typically care about
how long that takes. And then we fetch all the versions from GitHub. And finally, we fetch our
digest. And then we have our lock file. So, you can see the lock file Wrangler.lock. As well as Wrangler.
Text which lists out all of the images that we're creating. So, with that single configuration
file, we've defined all eight of these images. And I'll briefly show the lock file where you can
see that we no longer have that loose versioning from before. Here we every version is specified
completely. Instead of Credo version 8, it's 844206. We'll see another version of Java 21. And then
another version of 17. All of our installation is extremely explicit. And this lock file defines
exactly how we're building our images. So, the previous example showed how we can use
correct or build a variety of Amazon Credo-based images with a single configuration file. But what if
we had different types of runtime layers that we wanted? Suppose we wanted to create Java
images, but we also wanted to create Python images as well. This next example is going to show how
we can use Touch Wrangler to create all possible combinations of a version set. So, here we're
defining a dependency A1. There's going to be two A dependency. So, there'll be A1 and A2. Here
we're saying that we're just going to copy this file from my local system. A version with the
version dot text. And we're going to copy that into the Docker container. And we specified versions
1, 2, and 3. Then we have A2. And so, in this example, A1 and A2 are going to be conflicting
features. So, we're going to say we want either 1 version of A1 or 1 version of A2. We never want
both A1 and A2. Here we have versions alpha beta and gamma. And we're again copying those
files to our computer. From our local system to the container. Then we're going to have two
features called B or two feature B. And then in this case we have B1 versions 1, 2, and 3. And
there we just echo the version into a file on the container. And B2 is similar. We have B2 with
the version alpha beta gamma. And then we're just writing that version to a file on the container.
And then the same thing for B2. And then this is the cool part. This is where we're defining
our build. So, before we have base images, we're starting with Ubuntu and REL. And then we
define our feature sets. So, here we have A1 and A2. And they're in the same level of the array,
which means that those are conflicting features. We can also specify the versioning there
if we needed to. And then we have B1 and B2 also as a set of features. And so, this is telling
touch granular to build all possible combinations of either A1 or A2 with either B1 or B2
on all versions of Ubuntu or REL. So, with just this small bit of configuration, we've defined
a lot of images. So, here we'll show a brief example. Again, so here's our tree. We have A1 with
the version files, A2 with that's version files. And then we have Wrangler.com, just going over
the configuration we already showed in the other slide. I was just copying and pasted from this
configuration file. Then we call touch granular update again. We fetch the version for Ubuntu
Jami. Then we'll fetch it for REL. And then since we didn't have any other GitHub-based projects,
we don't have to fetch the versions for those. So, once we fetch those two images, then we'll
fetch the digest. And then we'll have a lock file. And so, after we have our lock file, we'll
start. So, once we have our lock file, we can look at Wrangler.text again. And this lists out
all of the images we're creating. So, from just those little bits of line of configuration,
we've defined all of these images. Now, this is an extreme example. Hopefully,
whatever team you're providing images, too, doesn't need this highly of a configuration.
But, because of the way we design touch granular, this is possible. And not only possible, it's easy.
Next, we're going to show that we're currently using Docker behind the scenes. We're
looking at other options like Stacker, possibly something else. And this is just showing the
Docker file that's generated from the lock file. So, for every different possible combination,
we are defining the installation steps using our configuration file.
And so, like we said last, we're creating a huge set of images with just a minimal amount of
configuration. They're highly configured. Based on whatever the teams needs are, we can
configure different runtime layers. We can configure the feature layers. We can use systems from
with our local tree. And so, COVID is going to talk a little bit about our future direction,
and then we'll open it up for some questions. And see, then. So, there's a reason. This demo
was recorded. We are at the tail and self-opensourcing yet. We should have the project
open source in the next two weeks or less. And the Apache 2.0. We do have, there's always
work with CI integrations as we all know. So, there will be more CI CD works. It then brought up
Sacker, the path partner and these are all things which we need to look into. Maybe integration
to create.io. We want to build a community which has similar needs and work with us. So, get the
dots out so that it is easier for foods to understand and consume. That's randler. And
more other things which we would love to know and contributions through GitHub discussions
once we have the project. And yes, testing, of course, we need to have more testing.
That's us. Thank you. Questions?
Hi. Thanks. Maybe I missed it. But one question is what language is Trucks Wrangler written in?
Sure. And the second is, since you're building a bunch of images at lunch and you're saying
you're doing some pipelines. What do you do? What do you do? Just one image fails but the
rest succeed. How do you handle stuff like that? Awesome. Yeah. So, our Trucks Wrangler is built
in Rust. We love Rust. It's got a great open source community and we thought it would be a great
language to write this project in. And you had a great question about image building in consecutive
or concurrent builds. We're currently looking at different ways to do concurrent builds within
Tuxeringler. Currently, we are building out a Docker file and then building images from the
Docker file. In the future, we imagine Tuxeringler will be responsible for building those images.
And in that case, we'll have concurrent builds. And then the fail behavior will probably be
configurable.
So, if you have, if I understand correctly, you're creating a lot of Docker files right now.
Currently, yes. Do you use buildings for this kind of stuff?
Yes. So, currently, we build with BuildX. So, we can reuse our layers. We can specify the
specific target layers that we need. This is our goal long-term. Long-term, we want to have
everything being built inside Tuxeringler and abstract that from the user experience unless they
want that. And because BuildX also provides you with the templates and something like that,
I was wondering if you're trying to generate that for BuildX to be able to concurrently
images and so on. Yeah. So, currently, we use a library called
Ballard from Fuzzy Beaver that doesn't quite enable all of the features of BuildX
we'd like. We're, while we're evaluating different building options like stacker, et cetera,
build speeds is definitely a concern for us and as well as consistent builds.
Were there any other questions?
No. Okay. Seems like we're done for today.
Oh, was there one up here? No. Okay. Yeah. If anyone has any questions,
I have our emails I can go back to those on the first couple of slides. You can also
feel free to reach out to either of us on LinkedIn. But thanks for everyone for coming.
Yeah. And thanks for coming to the Container's Deaf Room and see you next year, hopefully.