Docker Dos & Do Nots @ Jfokus 2022

time of today’s jay focus here at a1
give a warm welcoming upload to melissa mckay from jfrog
[Applause]
thank you everybody so glad to see all of you here um for many of you it’s it’s your first day the end of your first day
at j focus and um it has been a pleasure for me to be here so far um how many of
you is this your first time here at jfocus wow
wow that’s like half of you in the audience that’s pretty awesome um
can i just get a round of applause for the organizers of this conference and how well it has been put together so far
this is going to be a pretty light hearted talk it’s a good one for the end of your day and get you set up for celebrations later and i promise that i
won’t actually be talking about skinning any cats during this session i’m not that type of a person but what we’ll
talk about instead is how you can tangle yourself up into some bad practices sometimes when you’re writing your
doctor files and before i go any further i was instructed not to wear this hat
and since because of the lighting and i just am so excited that i even
have lighting to worry about at a talk right now because i’ve been so used to virtual
talks and being on zoom all the time so this is great so i got a little rebellious and i’m wearing the hat but
since this talk is all about doing things a little bit differently i will
wear my hat a little differently so you can see my face
all right this is my first time in stockholm actually my first time physically here
my name is melis mckay i work for jfrog i’ve been with jfrog now for two years
and i became a java champion at jfocus my first virtual attendance of jfocus that
was pretty exciting and i also became a doctor captain during that time period so i get to
spend a lot of time with the other docker captains and find out about what’s what’s coming you know down
the pipe what’s coming up next for docker and containers in general um this is my contact information
twitter is probably the best way to reach out to me if you have any questions or or anything like that you
could also follow me on linkedin prior to being a developer advocate i
always find this important to say because it makes a difference i was a developer i was a developer for
20 years all the way from a lowly intern to a principal engineer at a pretty huge
company and during that time i just found a real
passion for speaking i had an opportunity to go to an unconference
which is a very different type of conference if you’ve ever heard of them or ever get the opportunity to go to an
unconference take that chance it was probably one of the best decisions i made in my life
i did do it on my own dime because at the time you know i was not paid to travel to these kinds of things
so it was very very small it’s not the type of conference where you have someone standing up front
talking to you the whole time instead you have you know discussions with everyone in a
group so everyone gets to participate and talk about whatever subject is near and dear to
their heart i met a lot of passionate people that way got involved with other developer advocates and that’s how i
became a speaker today so if any of you are interested in doing that in your
career it can happen it works
all right how many of you got new pets in the last two years
anyone yeah there’s a few of you the rest of you just aren’t being honest you’ve done something
in the past two years i’m actually a cat owner these are my two friends i rescued as
actually my children rescued them as feral kittens last summer when we were all stuck at home and were getting a
little lonely i call them our pandemic pets our coved kitties
and again this is not a presentation about skinning cats obviously as you can see these two are
alive and well instead i will include a bunch of cute
cat pictures for you to enjoy because who doesn’t like that and anyone already familiar with my image and container
talks that i’ve given already i refuse to use any graphic of shipping
containers in my slides it’s never going to happen that’s my commitment and uh if
you’re the first to report to me any marketing or anything around a session of mine that has a shipping container
picture in it please reach out to me on twitter let me know i will give you some kind of prize for that
in addition to cute cat pictures i’ll be going over some of my early experiences with docker and specifically the docker
file and how that development went for me we’ll see if any of you can feel the
same pain that i went through or you’ll learn something today so that you do not feel that pain
how many of you are using containers right now
every just about everyone how many of you are using them in production right
now okay little less but about the same it’s pretty amazing now even just a
couple years ago i could ask that question and there just weren’t that many positive responses it’s very clear
how much containers and the use of containers has grown there’s a lot of different reasons
for that some of it is just the tool sets around it has exploded and just made it a lot
easier for developers to get involved and start jumping in and wrapping their
applications in containers now we all know it’s not a solution for everything but it
definitely is something that makes our lives a little bit easier when we don’t have to worry about what environment
we’re actually running in we can just you know wrap it up throw it out into the cloud and it runs
it’s pretty nice so let’s start with the docker file
that’s where i started um you pretty much have all the building blocks that you need to get your
application out the door and into production there’s all of these commands available to you this is a pretty fairly
exhaustive list but with these you can pretty much do anything your heart desires you can do
all the right things and you can do all the wrong things and everything in between
they’re pretty much building blocks you can put things together and it’s pretty amazing what i’ve seen
come out of some of the projects that i’ve worked on um if you want to know you know
obviously a lot of you are using containers already and maybe not just docker containers specifically but you know containers in general
there is some references that you can go out and learn about that when i started
it was not as common several several years ago i started using it docker containers and
uh it was it was pretty tough for me to start um i was on a brand new team
and did not even know where to start so that was
quite the experience so today we’re going to go through uh 10 things i just gathered 10 concepts that i wanted to
share um and we’ll talk about the do nots involved with that and of course the
related dues these are things i learned through trial and error when i first
started with docker some you may be aware of these pitfalls already but my hope is you’ll find you
know one or two or more of these helpful and think about making some edits to your existing docker files you might
have in the wild right now so several years ago i was brought onto
a project that was initially developed by a third-party contractor and it was time the company decided to bring that
project in-house and to build a team around it so that now my team would be responsible for maintaining that project
and making sure that we got new features developed and stuff
it was a very small team to begin with and the first thing i realized was yes
it was wrapped in a container and there was a docker file in the source
that was the first thing that i looked at and um pulling up this dockerfile uh i
just read you know the readmes that were available on how to get the project up and running and get started and i that’s
how we started and chaos went from there several things i learned uh through this
journey the first was ignoring the docker ignore file i did that immediately didn’t even
know it existed didn’t know that that was there or what it what the use would be so of course i didn’t use
it and one of the things that annoyed me the most was how long it took to build my images and this uh you know project
was a pretty big it turned into a pretty big space so every time we would build and anytime
anything would change it just took forever to build on my machine and that was just because i
didn’t fully understand how the docker context worked
why would you use dr ignore this is kind of a contrived example here but it includes the exact problematic
line that we had in our docker file to begin with and you can see it right there that third line down
copy with two dots and if you don’t realize this
this is copying and delivering everything in your current working directory
to the daemon and then into the image things that you might not want to put in
there one reason to use the docker ignore is to prevent such a scenario
you don’t want to send everything to the docker daemon you first of all immediately invalidate your cash for a
lot of things so you don’t get to save that time and you may be sending test files or other resources that are not
needed in the production image you may be sending user-specific files
maybe you have your own environment set a certain way and so you’ve edited some files the or secrets even you may be sending
secrets across the docker ignore file works very much the same way as git ignore
and it just prevents you from putting in extra stuff into your image that you don’t need
so let’s be real very clear about what this is doing when you run a docker build command
to build an image using this particular docker file that i showed you everything that current directory is sent to the
docker context everything is then copied into the image other
you know avoiding adding any tests or specific files or secrets that you’ve stored locally is important
and at first i thought that i when i started learning this i thought i could just improve my build time by explicitly
copying only what i wanted but under the covers still everything gets sent and shipped
to the docker daemon even if you don’t end up using it in your image in this case this particular dockerfile
you wouldn’t there’s just two files there being copied so my project continued to take forever
because i was still shipping all of that stuff and this just you know showed what it
looked like i was happy with my two files that i ended up in my quite a bit smaller image which was nice
but that wasn’t going to work for me so here’s our first do and do not
don’t ignore the docker ignore file here’s an example of some of the items that you might want to put in there of
course your readmes your your passwords if you have any of those and one thing interesting is that git
directory i had been sending my git directory this entire time and putting it into my image
with that explicit coffee copy so that that was something that i fixed
once i learned about docker ignore all right number two
using untrusted base images and i’m going to confess when i first
started ramping up in docker the first thing i did i just followed those readme instructions i got everything up and
running and i was happy with it i didn’t want to touch it it was working it was fine i wanted to bury myself in the code
that i was familiar with which was java and there was some javascript in there
and surprisingly there was a python component too that was kind of a fun project but i didn’t realize then how images
actually worked until later when our build broke with an error message that said sorry your base
image doesn’t exist i didn’t know what that meant so i went digging around it turns around
turns out that the base image that was in our docker file was actually getting pulled from a private repo of the
original third-party contractor which had been out of the picture for over a year
so good luck trying to get that base image it was gone we didn’t we had to make our own so we
had to learn very fast how base images work and how to put one together
ourselves for our project a problematic base image probably isn’t
going to be as obvious as this one named evil image but my point here is to
pay attention where your base images are coming from this is becoming more and more important every day especially with
our supply chain issues that we hear about more commonly now
in the media and everything pay attention where they are coming from they are dependencies like anything else
they really should be pulled into a dependency management system of some kind
like artifactory or managed along with the other binaries wherever you have them stored everything
that you rely on for your build there are official images that come from
docker hub these images docker has a dedicated team that is responsible for
reviewing and publishing those images and that content that team works in collaboration with
upward software maintainers upstream software maintainers and security experts and the greater docker community
as well so you’re a little bit safer if you’re pulling from official images from docker hub
but just realize that you’re still relying on a third party so i would suggest to bring anything that you rely
on into a private registry of some kind so that you can track it make sure it’s
not changing out from under you make sure it doesn’t disappear like what happened to my team
you can also you know it’ll help you avoid malicious packages you can get the latest updates
that kind of stuff so here’s an example the second do and do not make sure that you’re pulling
from a registry that you recognize and preferably one that you have control
over also understand by default everything comes from docker
hub unless you explicitly say or tag an image that it it should come
from your registry so understand that and also understand that
just because it’s listed as as the from there’s an inheritance there that base image could be based on
another image which could be based on another image it is worthwhile to do your research and figure out exactly
where those are coming from and what is inside makes sense
we should know this about our applications so i got a little scared because i
didn’t even know really where to look for a base image that was going to work for us i had to do a lot of homework
tear some things apart figure out what was relying on what so how do we make this decision what do
we use especially as java programmers you know what on earth do we just go out to docker hub and search for java is
that how we’re coming up with our images do we just go google and get the first example that says uh you know from open
jdk is that the right thing to do there’s also this whole other
nomenclature if you’re if you’re not real familiar with linux these are actually you know linux
distributions and when you see names like buster and
bullseye those are different linux distributions for java specifically you would
recognize jre and the jdk so you might decide well if i want a smaller image if i want you know less
in my production image i would choose a jre over a jdk
you could certainly you know just limit you know based on your java version um
but once you start learning these other names as well you’ll see them in other projects not just java projects
there’s no mystery here when you realize what those names indicate and i just listed them here for you
if you need to install additional packages on top of any of
these images you might need to pay attention to the linux version at this point and just to note the alpine
version is interesting alpine is very popular it’s considered to be small this you know one of the smallest
it produces small enough images that are really especially for container
use however just realize it does use a slimmer c library that’s different than
what debian uses which we’re more used to glib c or the the new c library uh the
alpine uses actually a lot it’s called muscle and it requires an open jdk port and in
fact if you were to look at the documentation for the official open jdk
image it says that the port for alpine is not even in a supported release by
openjdk and according to their documentation alpine images are only
released for early access open jdk versions and they are not updated after
ga so i would consider maybe looking for something different
than the official open jdk alpine image and it makes sense if you’re already
paying for support for specific distribution from from azul perhaps or from ibm it makes sense to stick with
their official images and i do know they have alpine versions that that are maintained and supported
all right moving on to number three not defining versions this particular outcome is gorgeous in a
cat not so gorgeous in a project when you have incompatible versions
flowing in and you don’t have control over all of those variations and variables
and this one kicked us as you would expect our build just started randomly breaking one day and there was a lot of
troubleshooting involved trying to figure out what changed
one way to solve that is make sure that your artifact management
has a way to identify for you every single component of your project to make sure that it is
actually the same um that is one way to manage this a little bit better than we did
we unfortunately had everything in in the same repo
it made it really difficult for us to track things specifically but one of the things that i didn’t realize
was not just versions of you know our application but the os
packages too and in fact this was what happened to us we ended up building a
new image uh no caching was involved so everything new came in
and there was an incompatibility there took a while to figure out exactly what
package that was once we did we learned we needed to make sure to specify the version that we
were interested in using you should always always have a bill of
materials for your build this is more important now than ever know what versions of everything is installed
artifactory has a metadata called build info which is super helpful with this
you can eliminate you know multiple moving parts and control your version updates a little better this way
so the do’s and do knots here again a contrived example but the do not section notice the tag
latest we started using that we thought that was great we’re getting the latest and
greatest what i didn’t realize at that point was just how tags actually work for docker images
they are not always going to be stable and latest
might not actually be pointing to latest today or tomorrow
it changes out from under you so really important to understand what you’re getting latest may not even be a stable
version depending on where you’re pulling these from also caching it was really interesting
when we started adding new members to our team and they would build these fresh images
and they didn’t have the benefit of all of the image cache on their machine and things just did not work the same which
makes sense right just like in java if you were to you know remove your entire maven
local maven repository you might have some issues that happens pretty frequently
frequently when a new programmer comes on board and they’ve got to build everything fresh
and all of a sudden you realize oh no we have this dependency that we relied on that none of us realized was just coming
from our local cache same goes for images that can happen to you too
all right number four never updating this is a mess
and i know a lot of us are guilty of this we’ve been on teams where keeping our software updated is not as much of a
priority as getting the next release out or getting the next new feature out that
has always been a push and pull with different parts of companies
some are organized differently than others and it’s just a more difficult
process to really iron out it’s really easy to fall into that idea
of if it’s not broken don’t fix it and that really means that there are bigger problems going on
but there does really need to be a balance there updates need to be scheduled they need to be regularly addressed
just waiting for your build to break before doing those updates is never a good idea not a good strategy and why
there are three reasons i put here security updates are important
and again security updates are important on number three security updates are
really really important blockout time every development cycle to
spend on this kind of maintenance some believe that defining versions is a is
or not defining the versions for example using latest is a good way to get the latest security
updates but i’d argue that depending on the size of your project that increases the number of changing variables during
your build and you might end up with some difficult troubleshooting there i like to control your variables
i’m kind of a controlling person that way i guess but i think it’s important to do and
i think it’s it’s just quicker to decide today we are going to upgrade this version
rather than you know randomly do it out from under you
um this particular file notice you know not only the base image needed to be updated
it’s old but there’s also packages that were being added on top of the base image so
every time this image was built fresh it would be building with a package that had known vulnerabilities in it
something to consider and make sure you have a process to deal with that
so how to fix it obviously decide the version that you want get it upgraded
make sure you’re going through all of your testing cycles i would do these kinds of upgrades by
themselves during during a maintenance session rather than have everything else come in
at the same time new features and bug fixes and all of that uh reserve some time for this specifically
all right we’re almost halfway through five including your build tools
i see this all the time i see this everywhere in examples online
when you’re out looking for just how to build a dockerfile it’s really easy to come across examples that look like this
and they come from some base image that includes all of the tools that you need to actually build your project and this
isn’t again not restricted to java this is for any anything out there they’re all
supported base images that just make it easy for you to get your project up and running it works
but you end up with an image that’s much larger larger than it needs to be you don’t need all of that extra stuff
in a production image why would you be putting maven libraries in a production image
also it’s just best to minimize your attack surface from a security perspective the less that you have
wandering around in your image it just goes to reason that’s that the less you have to worry about potential security
vulnerabilities you might ask why not just copy over the artifact from a previous step in the
process rather than include the whole building of the project within the image
build and one argument that i’ve heard for that is that
some teams like to be able to include the specifics of how the project is built in the docker
file they kind of keep it as a record of how it’s built and that makes it more buildable by anyone regardless of
availability of tool sets in a local environment so that might be another reason you would want to include maven
in there so that someone doesn’t have to install you know the correct version or whatever on their machines
the solution to this i suppose is really just going to depend on how your team is organized for example there was a period
of time when i was on a team that we just weren’t involved in containerization of our
project we just focused on the libraries and building the libraries we passed those off and it was more of an
operations chore to put that together and then actually deploy into containers
so just depends on you know what works for your team how you’re organized but one
thing to consider is multi-stage builds that way you can get the best of both worlds you can get a smaller image
without those build tools in the end and here’s an example of what that might
look like so in the do section there’s two from statements that whole
first part is the build of the project and then when you hit the second one that is actually all that is going to be
included in your image this is something you should really focus on doing only include the pieces and parts you
absolutely need for your application to run in production
all right number six using external resources
this is another one i see all the time and it’s pretty
blatant out there i see a lot of cruel statements and docker files i see a lot of you know
wget things where you need to connect to some external resource to get your
artifact that you need or dependency that you need one example that we had in our project
was there was a proprietary piece of software that we needed to install
on in the container and part of that process was just to
curl out and get it but we were just getting a script we were just pulling in a script and
that script was running we just you know ran it um you wouldn’t do that on your own
machine would you would you that’s something that i would be very careful about i mean the first thing i
would do if i was presented with a script like that is go get it and look at it see what it’s doing right before
just running it on my machine i mean that’s the classic going to stack overflow and
getting instructions to delete your hard drive and just doing it so
at the very least make sure you know what you’re getting
and consider pulling it into your own binary management system like artifactory this way you can also not
only pay attention to what it’s doing but you can also control when it gets updated
you will notice when it gets updated and then you can update it at your own
pace and not at the whim of the script owner or the maintainer in our
case this was noticed especially when the maintainer of the script just
basically moved it so we were curling out to something and not getting anything back and
we had to contact the maintainer of the project and get all of that fixed and that’s when it occurred to me this
probably wasn’t the best relationship to have
so the do and do nots here this is just an example of you know pulling that script in owning it making
sure you are in charge of those updates you are in charge of what is actually happening with that script when it is
running that kind of stuff
trust but verify again and again and again we take for
granted this stuff that we pull in there are so many binaries out there now
a bunch of open source projects we are all in this position where none of us really
want to reinvent the wheel we want to use what’s already there so that we can build bigger and better things and i get
that totally understand that but a lot of times we’re being a little bit careless about what we’re pulling into
our projects and it might not even be a problem with
you know a vulnerability so to speak it could be just a licensing issue that
could come up and bite your company later so if you aren’t aware of what your
developers are pulling in what they’re using in the project restricting that in some way or maybe
not restricting is the right word but monitoring it you can definitely count on that coming
to bite you at some point
all right seven this one’s pretty obvious hard coding secrets
not so obvious hard coding config this is something that we struggled with because we really didn’t have a good
pipeline at the time that was something we were building from scratch for this particular project and learning how to
do that with a container and you know where to put that in our build pipeline
and stuff [Music] this is an example of something i saw in
a docker file and see if you can figure out what is happening here
and maybe what the intent was here if we just go through it step by step
you see that there’s a base image okay then we’re doing some updates we’re
doing some upgrades of os packages all right and from what we’ve learned already we’re we might be concerned
about updates that we don’t want right now so that would be you know something to take a look at but look at that third
line what is going on there and this isn’t exactly the docker file but it is
certainly modeled on one that we came across on our team
what happened here is someone responsible for building the base image
oops added some secrets they shouldn’t have but instead of rebuilding the base image
and providing a new version they thought it was sufficient enough that during the build cycle
to just remove that file just remove the parts that they didn’t want to be there
when you start learning more about how layering works with docker images you
know this is not a good solution maybe the what you’re looking at at the end if you
were to exec into the container for example built from an image like this you wouldn’t see that file but it’s
still there it’s still there on the system in an underlying layer
so always best to rebuild this image now i’m sure there was some good reason why
this base image wasn’t rebuilt but i think just understanding that this particular fix wasn’t really a fix was
more important to us at the time as far as config and hard coding config
the port that’s exposed here that was something that mattered to us when we started adding other environments and we
had some restrictions on port requirements things like that going through our testing phases and our our
integration tests and going through qa and finally getting into a production environment sometimes that
port needed to change it’s much better to put that in
i’ll go ahead and move to the the do section it’s much better to expose that as an environment variable that you can
pass in rather than hard code that it’s very future thinking kind of future proofing your image development
in this case too uh we absolutely required that the base image be rebuilt
so that we weren’t going through with that silly line of trying to remove secrets that would just exist in an
underlying layer
all right number eight just doing too much there’s a point when you start you might
start especially in the beginning thinking that your doctor file is just a glorified shell script
and it is not it is meant to be a
description of the blueprint that you’re going to launch containers from it’s not supposed to be littered with
a bunch of actions and processes that are really meant to be like a pipeline a build pipeline or a test pipeline
this is an example of what i’m talking about and again this comes from not quite
understanding what it means when docker you know creates layers
and then caches from those layers in this particular file you can see
once again this this was an interesting thing we had a base image and they were trying to
remove an old package for the purposes of installing a new package that’s
another candidate for just rebuilding the base image that’s really what needed to happen there but down at the bottom
can you figure out what the problem with that is it looks like there is a script that does some cleanup of a database
and then unit tests are run
this isn’t what happens when a test fails
and then you try to rebuild this image and think again how caching works
nothing has changed if if all you do is uh you know let’s say the test fails you
just fix the the test it’s one of those cases and you try to rebuild this image
well you’ve already gone all the way past that line cleanup database
and now you’re going to try to run unit tests again you’re going to have some problems
and side effects are all around whether or not you know you’re caching something that’s unexpected
we had some crazy effects when we did stuff like this in our docker files
and of course this file is contrived for complicity simplicity but it was it was
again modeled off another file that i worked on most importantly docker file should contain item potent
operations only in order to provide repeatable builds
so the do’s and don’ts of this basically don’t treat your doctor file like a shell script it is not
rather than running integration tests during the build of a docker file consider launching a
container and running tests against the container in another environment meant for
integration testing that would be a much better approach and keep your docker file as simple as
possible
okay we talked enough about caching and i added this one unnecessarily busting
cash so there are times when you do not want cash because you want to verify that the build from beginning to end is
legit that it’s going to work in any scenario in any environment but there are times when you do want to
benefit from the cash and the one that i can think of the most is a developer
if you’re involved and repeatedly building images on your machine it would be nice to be able to
benefit from that cache just like being a java developer you can benefit from
if you’re working with maven for example be able to benefit from your local maven repository
it’s nice to not have to repeat all of the downloading of stuff that you already have
so an example of this and we also had many instances of this
i see a lot of this when i see you know projects working within pm
and uh um trying to you know figure out how to utilize cash without you know
downloading everything every time you run the build for an image
performance really takes a hit you want to minimize that time for images to be pulled or pushed across the
wire as layers are created if any of those layers changes that
means that that layer has to be regenerated everything below it also needs to be regenerated
so take a look at this file very simple named it named things so
that it makes sense what’s going on here we have our base image we’re just copying from our
from our work environment we’re copying a dynamic file in meaning a file that changes a
lot next we’re copying a static file file that never changes it’s just some
requirement for our application and then last we’re we’re sending in a script that we use to start
our application so they do and do not hear
reorder those make sure that your dynamic files happen later in your
docker file not earlier that can take you know sometimes you
might find yourself in a catch-22 that might indicate you need to do some reorganization of your folder structure
or something in your project but in this case it’s pretty simple moving stuff that changes a lot lower
now as java developers you’ll probably see this a lot uh if you were to use
um the like the maven docker plug-in you can see that class files and
third-party libraries and stuff are actually separated from each other and if you if you could see a docker
file it would appear that the highest layers would include third-party libraries things that aren’t
likely to change as often as your local your class files that you put together
and that are in active development so that’s one way to improve performance
when you are building java in containers making sure that
those dynamic files come in as late as possible
okay i’m leaving the best for last i had the pleasure of meeting uh thomas
andolff from trusec before his interview at the devops speakeasy
this morning and i don’t know have you all found where that is it’s right where the massage is given so surely you’ve all found
where the massages are being given out the devops speakeasy is right next door to that and we chatted a little bit this
morning about what he was speaking about his talk is tomorrow at 3 35 in room c3
it’s called quickie the top list of securing your developer workstation
and as we chatted he asked me if i could please help to lead the charge
to get docker to get rid of running as a route processes inside running a running
container they’re just like any other process on the system albeit a few constraints but they should not be
running as root in a container unless absolutely necessary
doing that opens up the possibility of escaping the intended confines of those processes and
you know something someone unintended gaining access to host resources
reduce that attack surface area by following the principle of least privilege and treat those processes like
you would any other in your application monitor their use make sure you have the
appropriate user and group running those processes you can
create a user inside the docker file you can also determine a user when you
launch a container however i like it being inside the docker file so that you don’t forget or you don’t have to
constantly look to see if it’s there that’s the case for base images because when you’re pulling in base images pay
attention to whether they are bringing along with them the root user
here’s an example i mean most of the examples i’ve shown you so far
where you know there was no nothing in there about creating a user a group and and controlling any of those
processes and here we are again my start script is just going to run as root
so i um feel bad bringing that up um sometimes
um just because i feel like this is something that we talk about over and over and over again and i feel like
everyone should know about it but on the next slide you’ll see a statistic that’s pretty scary but
here’s an example of how to do what i’m saying this actually is just modeled
after some examples i’ve seen with spring boot they often you know you’ll see them
create a new group and a new user and use that group and user for the rest of the the build
same with uh like postgres i’ve seen the postgres container does that a lot of the a lot of the other containers will
do this for you always good to check though find the find the source of those and make sure that that’s what’s going
on so there is a report that came out recently uh this is the 2022 cloud native
security and usage report by systig systig is a pretty popular monitoring
company this came out of three million containers that they were observing and
76 of those were containers that were run as root
so even if everyone’s heard about it and understands maybe we’re not taking this
risk seriously enough hopefully this number will will go down
but for now this is something that i think maybe maybe folks that are building containers
just don’t completely understand i have a resource at the end that i’ll
share with you as well it it it’s dated now actually it’s 2017 i
think but it’s just a blog describing an example of how this can happen how you can get yourself in trouble by not
assigning a user in group i love articles and blogs like that because i’d rather not just be told i want to be
told why so like today when matthias told me don’t wear your hat he also told me the
reason why is because no one will be able to see her face because of the lighting so only then
was i ready to take my hat off and do the right thing so mind your do’s and don’ts uh that’s
all i have for you today uh remember that this these ten things are not an exotic exhaustive list but i think they
are the most important um i hope all of those items will encourage you to be thoughtful when you write your own
doctor files and also i would not be a responsible frogger if i didn’t invite you to visit
the jfrog booth we’re giving away a star wars lego set so you can
either go to the booth to get this qr code or you can take a picture of it now and sign up for that raffle
and then also visit the devops speakeasy we had some incredible interviews all day today and we’re going to be doing
the same all day tomorrow that space is open over there you can sit and listen to the interviews they will show up on
twitter and eventually they will show up on the youtube channel for the devops
speakeasy these are resources that i just put
together obviously the dockerfile documentation at docker is the best it has improved
quite a bit over the last few years definitely point someone that direction if they’re new to containers i know not
everyone is using docker as their tool but it is a very good starting place
learning about official images the place where you can find docker hubs official images
let me give you a hint it took me a while to figure out you know if i really wanted to break
into a base image and figure out how it was made i wasn’t sure how to do that
there is a cool tool called dive that you can use that will give you some indication
of what’s inside those images other than launching a container and exacting in and poking
around which could take a while but if you google
docker official images and you look for a github link that’s where you start
you would navigate into that find the project that you’re interested in and then
be able to go hunt for it there’s a they’re all built the same way which is good they follow some good practices so
it’s good to use them as a standard for how you might want to build yours as well
but there’s always a maintenance link and it’s another github project that you can go to and that is where you
will find the docker file itself for those base images that you’re curious
about um multi-stage build included a link there there’s the article um
about running this route that actually showed an example as well i was pretty impressed with the systig report if you
want to just if you’re curious there’s a lot of good information in there about other statistics around images and
containers running in production today and then i wrote an article on d-zone about storing your images
what you might consider when you’re looking for an image registry some place to put them
there’s some good information there too all right thank you very much
this is great
are there any questions i can’t see you very well but i can hear you if you shout them out
pardon podman yes so yes there are other
solutions um if you’re not do you run what’s your development environment are
you on linux yes so that’s the advantage there
windows and mac i don’t think it’s still very easy to run pod mount or anything else
to make that work but windows though with the wsl2 you could
use podman in there right you should be able to do that that is another option
anyone use the like maven plugins for docker or anything like that
no one anyone use build packs so something i discovered when i was
playing around with using uh the maven plugins because the idea there was to you know obfuscate the whole thing why
do we all need to worry about writing docker files and learning all this stuff when we already you know write java and
we we know our application that was one of the advantages of creating these plugins but what i
discovered was first of all the way the image is split up into layers might not always be the
way you want it it’s something that you need to again you know trust but verify
sometimes it’s good turns out okay sometimes it doesn’t and also
one thing i noticed the particular plug-in i was using actually ended up using paquetto build packs underneath
that’s all fine and good except that when i went to look at my image cache there’s other images that get pulled in
that are not part of my application and they’re needed in order to run the build packs against your you know to build
your image but what you might want to consider there is not relying on the defaults and make sure that you’re
setting up the plug-in to use your version of the build pack that you have collected and put in your own
image management so that you can control it
all right anyone learn anything new
awesome that’s the best part for me as long as you go away with something valuable that
you can take back to your team that makes me happy all right everybody have a great night i
don’t know what you all have planned next but i’m sure there’s going to be some celebrations going on
and i’ll see you all tomorrow [Applause]
[Music]