[Music]
hello good morning everyone and welcome
back to the kia auto theater uh at linux
conference australia 2022 um
i hope you had a great morning tea and i
hope you had a great rest and i hope you
have a great rest of your day
uh our first talk today is steve ellis
uh who is an open source technology
evangelist in the apac office of
technology team at red hat and a regular
face around lca and the rest of the
community as well
uh this session is going to look at a
couple of different approaches for
creating our standard images with image
builder for our traditional linux and
images and builder for our container
images it's all yours steve take it away
hey thanks caitlin and thanks everyone
for joining me
and i'm really pleased to be giving this
session after this morning's keynote
because the term ephemeral was
referenced and i actually put up on the
first slide
uh one of the definitions because some
people say what you actually mean by
this and
well i think ephemeral really is a great
way of referring to
the way we should be treating a lot of
our environments and a lot of our
platforms today
so look well we'll dig into this as we
go through the session please use the
questions
tab and i'll try and come back to them
at the end or i'll jump into the q a
area after the
uh the talk
so here's like a a rough agenda
i'm going to kick off with a bit of the
why
and a little bit of history
uh we're going to dig into the what what
is the technologies that we're digging
we're looking at today image builder and
builder
and then a bit of the how we're actually
going to do some live demo because
you know this is a conference i love
doing live demos and then a little bit
of a look back did we get to where we
wanted to be did we actually answer some
of the why
um and i actually think so my why isn't
so good after listening to the keynote
this morning liz did a much better job
of summarizing some of the reasons why
these tools are are important
and why these approaches are very very
important to the way wedges should be
dealing with environments today
so
ephemeral uh terry pratchett's one of my
favorite riders of all time and i i this
is a terrific quote that appeared in the
guardian a few years ago
death appears to have some sneaking
regard and compassion for a race of
creatures which to him are as ephemeral
as
mayflies that really nicely uh positions
it there may be a few more pateri uh
references as we go forward
so why why are we having this
conversation
let's be honest security is hard it's
incredibly hard we're living in a
landscape where every day every week we
seem to have new security compromises
and issues but to counter that change is
hard it's really hard to convince
customers or
organizations to
to change
it's incredible the number of times
where i've seen a security fix delayed
for an inordinate amount of time because
of change management the change is
critical
but the change has to still go through
the process
for many of us cloud has changed the way
we do everything
almost everything because not everything
runs in the cloud we have to deal with
more than just cloud environments and
consistency and repeatability
are difficult can be difficult shouldn't
be difficult
because we're dealing with a mix of
environments many of us are dealing with
physical and virtual workloads we're now
dealing with cloud instances and we may
be dealing with containerized workloads
and i'm not even getting into things
like serverless
and then we've got all those legacy
things that we have to deal with
you know number of organizations are
dealing with
edge appliances legacy appliances and
now everyone's going on about the future
of iot and how do we make sure that we
have that consistency
and resiliency and the security we need
for managing all those environments
so
let's step back a little bit and look at
a bit of history let's look at an
environment
that's very long-lived
there isn't a lot of change over time
in fact you thought it was difficult
changing the time on the clock radio in
your car imagine adjusting this for
daylight savings
it's relatively repeatable but it's an
amazing engineering effort to put up
this isn't something that you're going
to easily repeat because of the cost of
producing it
let's step forward a little bit into the
realms of mechanical computing and
honestly if you ever have the chance to
visit the science museum in london go
and look at this because it is stunning
i think this is a piece of art
but it's a very very mechanical device
it is repeatable but it requires a high
degree of engineering customizing it's
hard
changing it in some way programming
isn't overly easy
and then we step forward a little bit to
turing machines and i really want to
visit bletchley park next time i'm in
the uk and go and have a look at this
as one example of an early turing
machine
again mechanical devices
that
you put one wire wrong
you make one
uh that you've now impacted your
programming
that um the the nature of the devices is
there's a high rate of things going
wrong when we step into digital
computing we now have a higher degree of
control it's easier to load the
operating system it's easier to load the
software
these big hawking devices that weren't
really subject to the high rates of
change that we need to deal with today
and that anything but ephemeral devices
i actually got introduced to the need
for ephemeral computing fairly early on
thanks to this man and this device
clive sinclair zx81 and the infamous ram
packs that we had
you know there's a few things i learned
that were really important in my early
years of programming with the zx81 and
later aztec spectrum
first of all the importance of backups
backups are critical
backup and recovery was a something you
really needed when with one wrong move
your ram pack would
wobble and you would lose all your data
everything you did was ephemeral
i also learned the vital importance of a
well-placed piece of blue tack
so stepping forward how do we install
software
and store the operating system in the
case of my zx81 it was from a cassette
tape the humble cassette tape stepping
back in time
we had
things like paper tape or punch cards
these aren't exactly reliable it's very
easy to damage them
and in fact if you have a look at the
links below uh command line heroes
season 4 from red hat really digs into
some of the history of computing and
some of the early methods for loading
software
coming forward a little we move through
floppy disks
through cd dvd
media and now
into usb keys
they're all ways we used to bootstrap
systems traditionally
so when i was thinking about this talk i
kind of stepped back and said well
really where we're going to get to now
is what we should be talking about is
infrastructure as code
and i realized way back in 2008 at
linuxconf i actually gave a talk about
infrastructure as code
um we i this is part of the sysadmin
mini confidence quite amusing actually
going back and
uh re-looking at this
talk so i've actually provided the links
here to some of the presentation
materials and the original video
um but while we're in that
session we talked to
the need for reliable repeatable
reproducible infrastructure effectively
infrastructure as code we talked about
some of the technologies available back
then around whether you should use
system imaging versus technology like
kickstart or precede in order to build
up your base operating system
we want to make sure the way we were
doing this
was abstracted away from whether the
system was physical or virtual
um there was the options around patching
versus rebuilding systems
when we were dealing with operating
system updates
uh security and hardening was still just
as important if not more important back
then
so we looked at capabilities like how
operating firewalls and
se linux etc
and then back then the post build
automation tools we were looking at were
things like cf engine and puppets you
know ansible hadn't come along at that
stage
and i couldn't underestimate the under
the importance of having things like
single sign-on you know making sure out
of the box that we've got the
environments integrated with our
identity management is incredibly
important
so that was all the way back in 2008
my roles changed many times since then
and i spend a lot of time talking to
customers and operations teams about how
they build and run systems
and surprisingly or unsurprisingly
these are still two of the most popular
ways for systems to be bootstrapped in a
lot of enterprises today
the number of times where it's still
sticking this a usb
or even sometimes a dvd in a system in
order to bootstrap it is just incredible
and there's still an enormous amount of
systems out there today which are click
click click
through the installer
rather than automating the delivery and
having your corporate customized
approach to delivering those services
when we talk about
cloud computing containers and modern
workloads we often use the terms
pets and cattle i'm going to use some
different terminology here today
i want to talk about snowflakes and
dwarf axes
because a snowflake
is extremely fragile a snowflake system
is very very hard to change you may
change one thing and the whole snowflake
collapses
snowflake systems are usually created in
life to live for a long time with very
little change or modification
dwarf axes are incredibly robust
again another terry pratchett reference
see a dwarf axe may have been in your
family for decades maybe in your family
for generations it's had eight new heads
and seven new arms but it's still the
same dwarf axe
now if we apply the dwarf axe thinking
to systems a good system a good service
should be like a dwarf axe it should be
resilient it should stay up it should be
hard-working
but we should be able to change its
underlying infrastructure we should be
able to change its head and change its
arm without the actually this service
changing
and to be honest i have a personal
dwarfax and again this is a reference
back to linuxconf in 2008 because i
talked about the development of a myth
tv based pvr appliance
now my own unit
is actually kind of the dwarf x i had
all the way back in 2008 i've changed
the operating system many times i've
actually swapped it from 32-bit to
64-bit versions of linux
it's had many
motherboard iterations and cpu
iterations i've changed the hard drives
i've changed the tuners and yet
it's still the same
to all facts it still has recordings
from all the way back in 2006
it's still providing the same service
but i've abstracted away the
configuration and data from the
underlying infrastructure
that's a really important change that
started to come through in a great part
by cloud cloud computing the arrival of
cloud computing
and another big change that came through
with cloud computing
was the conversation change between dev
and ops because traditionally in many
organizations there was a great big wall
there was a divide
you know there was that running joke
that dev would throw something over the
wall for operations to manage
and once they started to conversate once
they started to collaborate those walls
started to come down
and today most organizations also
introduced
security into the conversation
now we have the term devsecops
and boy is that something we really need
today
i mean i apologize for any ptsd
flashbacks here but how many of these
can you name
you know because there was a period
where
every week there was a new super
vulnerability
every week there was a vulnerability
where the logo the branding the website
for the vulnerability was better than
that for the
uh our originating project
for those of you who can't remember them
we've got heartbleed open ssl shell
shock which was a bash vulnerability
poodle which was a again a ssl
vulnerability stage fright which was a
big android vulnerability drown which
was another ssl vulnerability and then
bad luck which was a samba smb
vulnerability and bad luck was a big
deal
i mean they spent so much time warning
everyone that that existed
in the
ite ecosystem long before it was kind of
made public so that we could put some
mitigations in place
so
having dev ops and security talk to each
other
really started to change everything so i
like to say dev met obs and started to
talk about security
we're now seeing the need
for
greater consistency in environments
because greater consistency drives
repeatability we want consistency across
our stack we want the same stack
that for our developers to run as we're
running in production
we don't want the same surprises we used
to have in the past where the developer
environment had a completely different
library a completely different operating
system release
and the move towards containerization
has really helped that because
you know developers can work on the same
environment the same
same base environment as we're really
running in production
but speed of deliveries changed
long gone are the days where we're
waiting months for new infrastructure to
arrive in the data center
waiting weeks sometimes for an operating
system to be deployed onto it
uh maybe days for
allowed to get access to a system
in fact i i know a few organizations
where
they're even when they try to automate
the process for standing up their
infrastructure
on virtual hardware it was still taking
weeks because several steps
involve people as a service
once they reduce that down and found
ways to automate around some of the
firewall rule changes dns allocations
and those other steps
they now got it down to hours
and pretty soon they had it down to
minutes
and then suddenly the business is
expecting seconds
and if you're working in a containerized
ecosystem you start to get used to that
incredible speed of delivery we need it
right now
because ultimately businesses
expect faster delivery than they did in
the past cloud has changed this
so there's a little bit of background of
where some of my thinking's gone some of
the conversations i've had over the last
you know 12 13 14 years since linux conf
2008
what are we here to talk about today
we're going to talk about two
projects two capabilities that kind of
focus on solving two parts of the
problem
image builder with the upstream project
os build
is focused on creating operating system
images
builder
is focused on the container side of the
story and builder is there to create oci
compatible
container images
so we're going to dig into each of these
and turn and then we're going to do a
little bit of a demo
so image builder or os build image
builder effectively represents some of
the us ui components for os build
so
it has a web ui
that is plugged into cockpit so
uh it's called cockpit composer and you
can access it through the cockpit web
interface it also has a command line
interface composer cli and something
that red hat's been developing for its
customers is actually a a sas type
service
which means that our customers can come
in and actually just go and request
image builder to be run on their behalf
to create their custom images on our
backend platform
builds what kind of does all the heavy
lifting has a restful api
um and then the workers that do all the
actual composition now historically some
of this is based on
lorax composer and components at the
welder project and the api is still
based on the welder api
so the restful api comes out a welder
um
os build compose is kind of like a
re reworking
of the original work that went into
lorax composer
so it's been
you know um
[Music]
now we've got the word anyway we'll move
on
um here's a high-level view of the
architecture so we've got on one side
the the user interfaces the cli
or the web ui they then communicate with
os build composer
that they run locally on your machine or
the machine that's got the web ui and
then they will kick off the jobs and
then you can have a pool of workers and
this is one of the strengths of this is
that you can actually have
different workers targeting different
um operating system flavors or targeting
different architectures so this is the
current supported list of architectures
from you know typical x86 through arm
power and system z
this is quite nice pluggable
architecture so it should be relatively
simple to extend it to other
platforms as they increase in popularity
one other nice part of this is the image
upload capability
so you can just have it generate an
image and then you can pull it down
either through the command line or the
web interface but you can actually
provide credentials and have it
automatically push an image into amazon
or azure if you're using that for your
cloud hosted
workloads
so
each platform so each target platform
has a set of standard packages and
requirements so at the moment we can
target
ami for amazon and vhd for
azure we have vmware vmdk
generic cucao2 openstack and we have an
iot based image that's based on os tree
commits
um
the
one the reasoning behind this is the os
tree gives us a nice way to do kind of a
b testing or roll out so we can actually
have
the old iteration and the new iteration
of our image on a system
and we can push out a new image and then
have the system flick to it
architecture-wise as i said earlier at
the moment we currently support four
architectures
so that's just some of the capabilities
in
image builder
looking at builder
is part of our attempt to kind of break
down
the capabilities available in today in
docker so where docker kind of attempts
to be an all-in-one
tool for running containers
building containers
providing an api
the container standard originally pubman
is our way to provide an oci compatible
runtime
scopio's there for
container image management and builders
there just as a build tool now by
separating these services out it reduces
the attack surface these are each just
focus on a particular capability it
means that you can actually and and we
do have an example in the get repository
i'll share with you during the tour of a
simple
os image that can only run containers it
can't build them
which is a great thing because you don't
want someone building custom containers
on your production container host
also around containerization is some
standardization around runtime
interfaces so we've now got a cryo
standard so as long as your runtime
supports cryo and cryo's very much been
engineered uh with a focus around
kubernetes then any containers built to
work against cryo will work against your
runtime which means you can have a
choice of different containerized
runtimes
if you really want to dig into a lot
more around
how containerization works and some of
the underlying capabilities i recommend
you have a look at fraser tweeddale's
talk from yesterday
now builders there to as i said provide
those oci compatible container images
and it can do multi-stage builds with
and without docker files and this is
really cool because you've got several
ways of actually engineering the way the
build comes together
and i think also from a security
perspective very importantly you can
build
container images as a non-root user
i think that's incredibly important and
something i talked about last year was
uh
like running
containers as a non-root user it's
equally important to be able to build
containers as an on-route user
so let's get into a bit of the how
so there's a git repository here i'll
share it in the chat later
what we're going to use is
it's got all of the demo code all the
scripts i've used to help stand this up
and it's actually going to walk through
of how to run some of this demo yourself
we're going to use image builder and
builder and we're going to actually run
all this on a fedora host
to keep it all free and open
and in the
vein of keeping it ephemeral
i'm actually going to spin up a fedora
cloud ready image
that's running on my local laptop so
it's running on kvm qemu using libert
and then i use a small
ansible playbook to customize it to
install the required components so again
all this is in the git repository so
you've got access to all of this you can
go and try it all out yourself
so the ephemeral host means i can create
it run it for the purposes of this talk
and then tear it all down again and then
use it again on a later date
so first we're going to bootstrap
our cucao2 image
so we're going to use a standard
off-the-shelf fedora 35 cloud image i've
also tested this with rel85 and r9 if
you want to play around with enterprise
flavors of linux and then we're going to
do the
installation of
builder
image builder and also cockpits that's a
key requirement
now this is the fun bit because it's a
demo there may be a few shortcuts
um most of these cloud-ready images
don't allow ssh's root and it's just an
easy way for the purposes of this to do
things quickly so i customized the image
i stripped that cloud in it and i set
the root password to password ah
they're awesome
um i you know if you're gonna run this
on a cloud image hosted in azure or aws
and try it out there i recommend you
don't use password as your default
password
also
if you want to try this out
there's a
hosted version that we make available
completely for free at red hat
of both image builder and builder these
are hosted labs that you can actually
just go and walk through and try some of
this out today for free without ever
installing anything on your local laptop
or spinning up a cloud image
so let's just spin over to a shell
because of time i've actually have to do
a couple of tasks early so you can see
my date and time now it's just you know
10 past one
but i set this up at 10 o'clock this
morning
so here's the script which is actually
in my
git repository so here's the get
repository this has all of the guidance
and then how to deploy and run all the
steps so we're going to deploy a local
cloud hosted image
and we're going to set a few values and
then we run this script
and this basically takes
um
the cloud ready image and just creates a
snapshot of it
we then customize that snapshot and set
the password to password very naughty
but what the heck and then we run the
install to create a vm
off it
that we can access on my local laptop
um
so that's what we've done here and then
we can see we've examined the guess this
is actually the customization step
and we've uninstalled a package and
we've tweaked ssh config and set the
passwords
now the second part of this
there's a guide there also for doing
this on relay
five if you want
is the ansible setup so in this case you
simply need to run a ansible playbook
and it does the rest of the setup for
the demo
so here's that part where we log into
the host
we make sure
it's not running relative don't need to
subscribe it we enable cockpit image
builder
uh builder set up firewall d correctly
firewall rules install git and we clone
our repo so we've actually got a copy of
this repo with a few extra files
available as part of this demo and
walkthrough
we've now got a
environment ready
we're now going to show off
some examples of using image builder so
let's jump back to my web browser and
here we go and we'll log in to our
um
[Music]
ephemeral environment so i'm going to
log in as root
there we go
so here within the cockpit ui i have an
image builder option
and i have no blueprints blueprints are
the baseline for this each blueprint
defines one of our images
blueprint can be customized for an os
version and there's a whole series of
different customizations you can walk
through so i'm going to create a
web server
blueprint
and what this is now going to do is it's
going to go off and see what packages
are available they can go include into
the blueprint
now let's just take a few minutes to
sync
um
one other option
i jump back to my instructions of
this step
which is
here
um this tells us what we're going to go
and add package-wise into that image
loading they're still doing a sync
but there's some extra commands here so
i can do things like if i look on the
command line i can see
here's my fedora image if i do
that i can see that this version of
image builder's capable of producing the
following
types of images
likewise i can start and stop jobs and
do a bunch of other things through this
this is still sinking
joy i should have gone through the
stepper slightly earlier right so now i
can go and do things like add
http search for http
and
b
and i can add
there we go
and when i add that it's automatically
going off and look doing a dependency
lookup and making sure i need to pull in
187 dependencies
now for the moment i'm not going to go
through all the extra steps i'm actually
just going to commit this image because
i want to show
you some of the other parts of the web
ui that are available
now i'm not going to create the image at
this point i'm going to go back i
haven't set a hostname i'm going to give
it a hope hostname
and then i can go and create a
an initial user which i'm going to call
webmaster
i'm going to make it administrator and
i'm going to give it a really hard to
remember
password which of course is password for
the sake of the demo
so i can now see what packages i've got
i've got no images created but i can now
go and say create an image and i can go
and say what type of image i wanted to
create
great
now there's a few things here to be
aware of
it will do dependency checks i can also
do
a dependency check on the command line
so i can go compose
less now blueprints
list
i can also have a look
um
on the right
uh sorry i need to oops
name the
show
joe
show
web server
and there's my
definition so i've actually got a
web server definition httpd
name
and the password inserted now one thing
i've done here is i've actually got a
customized version i can push to replace
this one nice thing is that the version
the the blueprints are version so if i
look at the version i've actually got
saved locally this does a little bit
more
so it actually does the firewall setup
so i've customized the firewall settings
it's also made sure that the services
start
now one thing at the moment through the
web ui you can't
specify which services you want to start
and stop you need to do that through the
command line i've also inserted an ssh
key and i've also put a few extra
packages in so if i do
[Music]
this
and then have another look
i've now got the updated image and if i
jump back into my
web ui here
we'll force refresh
one problem i found is that the ui
doesn't always refresh
so quickly but this will now come up and
it's got all of the packages i need
now what i'm going to do now is generate
an image i can deploy
and i'll do that here on the command
line so what i'm going to do is i'm
going to create cucao2 image
and that will come back shortly with the
uuid for the image that's being created
and i can actually just take a look at
so if i use my instructions and go
and then
so these are all the instructions that
are in the git repository so that job
started that's going to take about four
or five minutes to run so let's actually
dig into some of the detail while that's
running in the background
so that's actually now
how we can define and create
an image definition
um
looking at the
uh the blueprint we've got
i'm not specifying any versions here so
i've made this blueprint very os
independent i can actually reuse this
blueprint to create a
fedora image or a rel image or a theory
or centos image or other platforms
but because i haven't been um
explicit around what versions of
packages and components i want or which
os i'm building for or what architecture
but there's things you can override here
if you want to tune that
for the purpose of the demo it's quite
nice to be able to show the same thing
running on multiple platforms
the other thing you can do said earlier
was be able to upgrade upload your
generated images automatically to aws
and azure
so
for this is just how you would configure
a
identity file that's got your
access keys for those platforms and then
you simply include that when you're
starting the compose and it will
automatically create the image and push
it up for you into the cloud platform
that you're using
so this is going to take a few more
minutes
let me have a look at
that's still running
so while that's running let's have
another have a look into
a few of the issues so one of the things
here you can do is compose a cli
blueprint depth solve
depth sol's really useful it
allows you to check
that the
you've you've validated all the
dependencies associated with a
particular image
um
depending on the platform you're
targeting there may be specific
additional dependencies it doesn't quite
catch everything i found for example um
one of the other examples i've got in my
git repository is creating a simple
podman based container host
it needed an extra dependency that the
dependency checker didn't pick up
because the qcow target enforces sc
linux and it it then added another
dependency that didn't come through the
dependency model so that's a bit of a
bug something we need to kind of dig
into and look at
so i've already tagged that there and of
course the web ui sometimes needs a bit
of a refresh
um forced refresh if you're doing things
through the command line and there's a
few gaps around features uh really the
the web ui is a great way to get things
started or to do some simple
um
blueprint definitions initially if
you're really going to be a power user
you really need to get into customizing
those tamil files yourself
i think this is still
running and if i jump back to the
webview i and go to images
and of course refresh
now it's not showing up there yet but
we'll leave that running and we'll dig
into the next part of the talk now
builder we're going to use the same host
vm
and we're going to step through a few
um
examples of building containers using
builder
so if i jump back up here and come down
and go to try out builder
there's again the guide on how to get
started with this so we're going to jump
into this location
and i've got a few blue
docker files uh sorry
a few docker build files here and a few
other examples of how we can build
containers using builder so if i jump
into
ubi minimal
look at the docker file this is a real
simple strip back example of a web
server now i'm actually using here our
ubi 8 minimal instance
now the the red hat ubi instances are
freely redistributable there are
universal base images
we patch them and maintain them and
they've got access to a reduced
uh set of packages that you can again
also use for free and build into your
container images so you can actually
build off this on a fedora house without
any red hat subscription without paying
any money to rent out and use this as
part of your projects
so i can actually just build
now in this example i'm basically
creating a very very simple
web server i'm injecting a index
and i'm simply running http in the
foreground i'm not putting any
additional customizations in so i'm
going to build using dockerfile
and that's going to kick off and pull
again this is a completely clean
environment so this is doing a fresh
pull
so hopefully my internet connection is
good enough of the ubi minimal image
and then it's going to use micro dnf
because this is a micro image we
actually don't have full fat yarm and
dnf in there uses a thing called micro
dnf
this is one of the smaller image types
that we make available
so there we go that's fairly standard
kind of
bill for anyone who plays around with
containers and now you can see that
we've got the baseline image from red
hat on our ubi minimal
i can double check this is working using
podman
so i'm going to start that service on
port
8000 map that port internally to port
8080 i can see
that's running
awesome and now i can run a simple curl
command and get back
that response
awesome
i can also do all the usual things
around looking at
the
logs
which is pretty much nothing so i
haven't set anything specific into the
container that i'm running today
so what i'm going to do now is simply
pull that one down
and show another example so if we step
back here
we've got another way of deploying
pretty much the same thing
slightly different approach so if i look
at
yes this is building
off the same baseline
image
but we're building
without using a
docker file this is kind of
producing the same output
so if i run this now
we don't need to pull the image because
it's already down we're going through
much the same steps
and if i do
[Music]
images
you can see now i've got two different
web server images they're roughly the
same size but being created using
different methodologies
and again i can
start that one
i can run curl
and then i can
also just
pull it all back down again
one of the nice thing that we've done
is in the container world there's a lot
of contention about image sizes and
small images
so we actually have an even smaller
example now i'm running short on time so
i'm not going to dig into this right now
so um but hopefully
i've got my
oh where are we
finding the right window
i've now got that qcaw 2 image and i can
now go and download that
and run that
locally
and i will get my web server instance up
and running now we're running low on
time so there's a few things uh
alternatives image builder you can look
at things like packer
that's very popular ec2 image builders
there's cloud specific ones uh you can
of course still use things like
kickstart i still use that a lot builder
alternatives of course got docker
uh build kit and can co
are out there today um
uh build kits come out of moby as um
kind of an equivalent i think to builder
we've got things like s2i which kind of
act like uh supersets and you've got a
lot of extra features
uh image builder versus builder the
really apples and oranges because you're
two in different things one is all about
the container the other one is about the
operating system lightweight heavyweight
you know and when we and people go on
about image sizes there's a really good
article done by scott mccarthy about
comparing different types of image sizes
don't get hung up on it
if it's a really big deal you can use
things like the ubi minimal example
a ubi micro example again that's in my
code repository go and have a play with
it
at the end of the day by the time you've
actually built
the container with your services often
there isn't a big difference between
the the the different baseline os
instances
so image build is really about full os
images
infrastructure agnostic version
blueprints
whereas builders very much focused on
that
single app service and needs an oci
runtime in order to make it work but
they're all open source and they all
focus on the important thing about
infrastructure is code it gives us
consistency and reliability be here on
the road map
one big thing in the image builder space
is looking towards oci support so that
the os tree layers
map onto the kind of oci model rather
than the existing os tree model
and better dev tool integration builder
again a chunk of work going on upstream
on that
few gaps and issues pain points
trying to drop builders sometimes into
sea ice existing cic d tools that expect
docker is not much fun
but it's getting better it's getting
much better
um so why are we doing this well
security is hard but i strongly believe
infrastructure as code helps change
everything
cloud has almost changed everything but
we're but not everything's there let's
be honest i don't run everything in the
cloud another do most of my customers uh
some people are all in some people
aren't but we need to have that
consistency in repeatability and this is
where these tools are great because
the blueprints the text therefore it's
infrastructure as code it can live in a
source code repository we can version it
we can manage it and hopefully
when the next big security vulnerability
comes along we can be ready to deal with
it
because there's always one more
vulnerability there's almost one more
thing to patch
and those vulnerabilities well they're
still lingering somewhere in the
background if you've got any questions
i'll answer them because we're running
short on time
there's a load of references here and
background material as usual my slides
will be posted up on my people page at
red hat and again all the contents
available on github
so thank you all for your time
thank you very much for your time
we've got about a minute for questions
we've got three questions in the queue
and the leftovers will go into the text
chat of course uh that was a really good
walkthrough of some like really
practical ways to use those tools so
thank you so much for that
um
i think
the most interesting question in this
list i think is can the image builder
roll fedora silver blue-ish images with
its os tree support
yeah that's kind of what the iot model
does
um if you play with it on rel85 and i
actually have a uh rel85 instance here
with if i do compose
i if i check the image capabilities here
it's got a bunch of extra ones compared
with fedora at the moment because this
work we're doing around additional
composability models so yeah there's
some work happening in that space
that's really cool um i think we'll take
the rest of the questions into the text
chat thank you so much for your talk uh
steve have a great rest of your
conference
thank you everyone for joining the
session
thank you the next talk that we've got