Level Up Your Java Container Images @ Bangalore Java User Group Meetup – March 2022

cordova well hello everyone
and welcome to the april 2021 edition
of the st louis java users group
st louis java users group is an informal
group attendance is free we really don’t
have a formal membership
list or anything like that our normal
meeting date is the second thursday of
every month except december
and we have no meeting there’s just too
much going on during the holidays
for us to be able to schedule a meeting
then
due to the pandemic we are meeting
online until
further notice but when we do meet in
person
we have people come and join us for food
and social at 6 pm
and the presentation itself we try to
start somewhere around 6
30. when we do meet in person
our meeting location is in the object
competing incorporated training
room at 12 140 woodcrest executive drive
suite 310 in st louis missouri
i’d like to introduce everyone to the
rest of the members of our steering
committee
so from left to right here we have ted
doyle
todd zimmerman bruce allspaw that’s me
in the middle
wait she go and kathy slang
if you’d like to reach the steering
committee the best way to do it is to
just
send an email to that address there at
the bottom of the slide
that’s javasigsc
ociweb.com because they’re a
original sponsor of us and it will go to
all of us on the steering committee if
you just send to that little
group address right there
the st louis java users group would not
be possible without the support of our
sponsors
so our founding sponsor was
and continues to be object computing
incorporated
and they’re based in st louis said they
donate
the training room and fill in
like if we might be pizza or maybe a
speaker
last minute or something like that and
have been doing that
i believe going back all the way to
approximately 1997.
so we’re approaching a 25th anniversary
here before t1
jfrog has been very kind because not
only are they sponsoring
this zoom account which we are using
to deliver the presentation to you here
tonight
but they also sponsor the meetup group
fees
it’s free for you if you want to attend
one of our meetings some
meetup and you’ll find us at meetup.com
gateway chart but it does cost the group
to be able to have the page on meetup
and make it available
and they’ve been trying to cover that
cost
when we meet in person we have two
companies that alternate that cover the
food
and that signature consultants and
adaptive solutions group
so they’re headhunters if you are
looking for a java position you can just
look them up on the web
and tell them that you found out about
them through the st
louis java users group and they can help
you find a position or if you have a
position that you need to fill
they would be a good place to start
at the end of this presentation we will
be raffling two
jetbrains licenses yes you must be
present to win
sorry if you’re watching the recording
you’re too late
but stick around after the presentation
and we’ll do a
we’ll do a raffle here online
when we meet in person elastic
is sponsoring some gift cards we haven’t
figured out a way to send those
electronically they are physically
plastic cards but when
when we get out of this pandemic we’ll
we’ll bring that back for the raffle
as well as the intertech monkeys
intertek is a training company
and they sponsor the famous screaming
flying
monkeys coffee cups and
uh mouse pads so forth for the
for the raffle those screaming flying
monkeys if you don’t know
if you’re just watching the recording
because you’re from
i don’t know halfway across the world is
basically they’re just little dolls and
you pull the string
when you throw the monkey up against the
wall it screams
and they’re a lot of fun we will also be
raffling at the end of this meeting
two manning ebooks of
your choice so that will be at the
raffle at the end of the show
and also when we have them uh pearson
sponsors physical books uh on occasion
so we really appreciate the support of
our our sponsors
now as far as upcoming presentations
on may 13th we have reactive
microservices
with spring boot and jay hipster by matt
rayable
of octa so
we just haven’t had a spring boot
presentation for a while
and hey micro services
that’s kind of hot and
what’s this j hipster so
yeah when i saw that title i said i
think i’m going to
go for it this was one that was
on the fuji dot io tuber
that i nabbed from last time because
somebody didn’t grab it and so he
accepted here within a few minutes and
i’m just really happy
uh to have so
you can watch meetup.com gateway
for updates to the presentation schedule
and location
so we’re still online uh
until further notice but just watch the
meetup group
it’ll be clearly marked when we go back
to in person
i don’t have any special knowledge or
anything about when that’s going to be
but if you are interested in giving a
presentation
or sponsoring the job
just give us an email at javasigsc
ociweb.com we’re always looking for
speakers and
we’ll see what we can do to
get you worked in here so i believe i
what i’d like to
do is to hand things over here for just
a moment
before i hand it over here to our
speaker tonight melissa
ari i think of j frog has some
uh some things he’d like to tell us and
some some raffle items so i’m going to
click over here to make you a host
and with great power comes great
responsibility
i’ll trust you to take it over and then
hand it over to melissa so take it away
i will definitely do that you know bruce
i just think i figured you out yes
all the time i’ve known you i i realize
you are a you mentioned when you said
the word headhunter earlier about the
companies
you are you are a headhunter of speakers
because i said
the passion behind how you obtain the
speaker and how you share that
is something i can tell you you’re a
natural uh
at that and uh could probably apply that
to the technical recruiting space uh
i used to think about space i would have
hired you so
well well well thank you ari uh
i think i have maybe a different
perspective on myself and that is i’m a
total scratch
when it comes to speakers i just go to
the
conferences yeah and i just i’m just
right up front about it i am totally
honest i’m here to steal your speaker
you’re a networker that’s yeah
and and i don’t want to give too much
away
all right thank god okay there’s no this
is not only on video it’s okay
this is only on video and it’s only
going to be broadcast all over the world
exactly i think i got a connection for
our 25th anniversary
there you go no promises
when you’re ready for
when you’re ready for a hello world uh
in java you can just call me because
that’s that’s
that’s about the talk i could give but
uh hey thank you thank you again bruce
really appreciate it again hi everybody
um i’m ari waller and i am the meetup
event manager for jfrog and we are
really excited to be a sponsor for the
st
louis uh jug for yet another year i’ll
just share a little bit about who we are
uh jfrog
is the devops software company founded
in 2008
many people in the devops community know
us best for our flagship product
artifactory which is written in java and
which is considered by many to be the
gold standard for managing your
artifacts and dependencies
but here’s something that you may not
know jfrog has
a new free cloud version of our software
available for you to use
for your projects especially for the
java meetup community
and if you’re working with docker as i
know many of you are
jfrog’s free tier on the cloud is
capable of functioning as a pull through
cache
for docker hub and here’s the best part
since jfrog has partnered with docker
you’ll be exempt from any rate limits on
polls
from free or anonymous accounts so that
of course can be pretty valuable
um i’m going to share a slide with you
let’s see if the let’s see if the
transfer of hosts worked and it looks
like it did
um and i want to tell you about a couple
other free things that we have going on
um and that is our annual devops global
conference swamp up 2021 is coming
may 25th through 27th in the americas
and june 1st and through the 3rd
in emea and jfrog wants you to get in
for free
uh here on the slide or ju uh uh on the
left there just
um we have a qr code that you can scan
and i’m gonna drop the link in the chat
as well
that automatically fills in a code for a
free conference day
now the the second day of the conference
is free but we have a
third conference day that does cost
money but for the st
louis jug um when you um click on the
link i’m going to drop or use that
scan it’s actually going to fill in a
code which will
allow you to add the third day which is
a deep dive tutorial day
into um which has really in-depth
technical
two-hour uh demos on lots of different
products not just jfrog products but a
ton of different partner products and so
forth
which should be really really cool so um
we’d love to have you at that conference
and last but certainly not in the least
another bonus for tonight is our raffle
just for attendees tonight
jfrog is going to give you a chance to
enter and win an amazon echo show 5
or possibly one of the five limited
edition t-shirts
that we have if you’ve seen a jfrog
t-shirt before you already know you want
one and if you have one you don’t want
another
so you can enter with the qr code and
the bitly link that you see
and a winner i wish i could do live
drawings but
i’ve got compliance items that i have to
be concerned about through corporate
etc etc so what i’m gonna do is we do a
random drawing within two
days of the meetup and then i contact
the winner by email
after i’ve had my correspondence with
them i will announce the winner to your
um your meetup community and
congratulate you on social
and with that i am going to now turn it
over to
um melissa but bruce and team thank you
so much uh
really i it you know with all that aside
what we can really tell is that a lot of
time and attention
to the details of your meetup and your
community are really really important to
you and that and that
and that’s really really critical
especially when you want to put
something good together
um and uh i can’t tell you that i know
the community appreciates it
but from one who sits in um quite a few
meetups uh
every single day in fact i would say
that you guys
really really have a knack for this so
kudos to to all of you and thank you
very much
so i’m going to stop sharing here and
i’m going to turn this
over to i’m going to turn the hosting
over to melissa so she can in fact share
her stuff
and i keep pushing the wrong button you
think if i said in enough of these i
would be able to do this correctly so
let me just do this correct here
all right sorry for the delay
melissa you are now the host
thank you excellent i’m feeling
super important right now i’ve got
control
all right should be able to see my
screen
i can see it awesome all right well
um i’m melissa mckay i’m a developer
advocate with jfrog
and i’m super excited to be here to talk
to you all tonight about containers
this is a talk i’ve given a few times
now and i really enjoy it
i hope you do too and just to set some
expectations up front
there is a lot of information about
docker in this talk
but this is not a tutorial or a deep
dive on docker commands or anything like
that
there’s already a ton of documentation
out there already on that
so when i put this talk together i
wanted to do something a little bit
different
i wanted to do some background research
and focus more on how we got here
and get to some answers to some of those
big why questions
why we’re even doing any of this my hope
is that
after this talk you’ll come away with a
better understanding of the history
behind containers
how they actually work on your system
and some of what is really going on
under the covers
um for those of you that are really
experienced with containers already
a lot of this might be review but i
promise there’s going to be something in
here
that you’ll be able to get from from
this talk there’s a lot of little
details
all right
[Music]
okay i’m not going to linger on this too
long because ari’s spoken about this
already but
don’t forget to go to this link and to
fill out
feedback and enter to win your amazon
show
and this is also where i will post
slides
um for you to refer to later if you like
um i’ll show this again at the end in
case you want to grab the link again
we’re all over that okay
uh a little bit about where i come from
my back where
background in software engineering and
development um
i i’ve i’ve been a
java developer for many many years
i’ve been a developer in some way shape
or form now for over 20 years
so most of my professional experience
has been in server side development in
java but i’ve had the privilege of
working on many different
teams over the years in a variety of
different technologies languages
and different tool sites i started
speaking a few years ago
i decided that was something i wanted to
do more of so i made the jump to
developer relations with jfrog last
february
i just celebrated my year anniversary
that has been a whole new experience
especially since
normally with this position you travel a
lot and
we have learned very quickly how to
enjoy ourselves online with these new
online conference frameworks
and it’s it’s actually been a good
experience for me i’ve met a completely
different audience a lot of people who
for one reason or another family
obligations or work obligations
i wouldn’t normally see them at a
conference
so i’ve really enjoyed this experience
and i hope that
as we move forward here that that we’re
going to have a variety of both
in-person
and online stuff that people can attend
my most recent experience in software
development
pushed me into some new territory and
this was while i
started working on teams that were
beginning to practice devops
and this is when i got the privilege to
learn more about how the apps i was
working on
were actually being deployed and um
i got a lot of exposure to a variety of
tools in the devops ecosystem
which makes you know the move to jfrog
just perfect
but anyway it was during this experience
that i was exposed to
docker and that’s how i this talk came
about
i started collecting information from my
own experience and
you know learning how to containerize my
apps and some of it trial and error
which we’ll get to talk to you a little
bit later
all right um let’s get started we’ll
begin with a brief history here
to uh give some background context this
hopefully won’t be too
boring but there are some really
important milestones in the past
that are good to know to get a better
understanding of how we got here
then we’ll take a look at the container
market and what’s been going on
there for the last few years and then
we’ll move into getting a real
understanding of what
docker is docker is not synonymous with
containers it’s also a very overused
term
much like kleenex is after that we’ll be
in an excellent
place to talk about what a container
actually is and then we’ll review a few
common container gotchas
and last but not least i’ll talk to you
a little bit about an option
for managing your container images
[Music]
all right a few reasons why i just want
to show you this list
um i know if you haven’t considered this
before and i know that a lot of folks
aren’t really using containers yet in
production
but there are lots of reasons to use
them outside of production
the top two are listed here to provide
consistent development environments for
your local environments for your
developers
or also to use in testing or qa
environments where you can still gauge
the quality of your application
with significantly less resources than a
production environment
so just keep in mind this isn’t all
about production deploy
you can definitely take advantage of
this methodology and other
other environments
[Music]
all right let’s jump in and start
learning about containers
so i’m pretty sure this isn’t the
graphic that you are expecting
usually you see a classic shipping
container photo
of some shape or form so uh first and
foremost
um one reason that i’m i’m just
tired of seeing shipping containers on
every presentation about docker
or containerization in general so i’ve
started a rebellion and i’m going with
the banana theme
and i hope you’ll enjoy that theme
throughout this talk on second reason i
chose this
is this is really a story about how our
industry has adapted to dealing with
limited resources over time
when i was putting these slides together
i was reminded of a story that my
grandfather would repeatedly tell me
when i was growing up
surely just to remind me to be grateful
for what we have today
when he was a kid he would get a single
banana once a year
on christmas and this must have been
during the 20s and early 30s
bananas were a rare treat during that
time for my grandfather’s family
and none of that banana would go to
waste in fact he and his siblings would
scrape the banana peel to get every last
bit
off because they wouldn’t get another
one until the next year
that’s not the most solid analogy but i
went with it and i liken that story to
how computing resources were in the
1960s and 70s
very limited very expensive and on top
of that it took forever
to get anything done often a computer
would be dedicated for a long period of
time to a single task
for a single user
[Music]
obviously these limits and on time and
resources
created some bottlenecks and
inefficiency and just being able to
share
was not enough there needed to be a
method to share without getting in each
other’s way
or having one person inadvertently
causing an entire system to crash for
everyone
at this need for better strategies and
sharing compute resources
actually started a path of innovation
that we see
massive benefits from today then there’s
some key points
here that i want to share with you that
brought us to this state that we’re in
today with containers
and i’m going to begin this history
lesson with charut
charute was born in 1979 during the
development of the seventh edition
of unix and was added to bsd the
berkeley software distribution
in 1982 being able to change the
apparent root directory
for a process and its children which
teru allows you to do
results in a bit of isolation in order
to provide an environment
for testing a different distribution for
example
[Music]
tarot was a great idea solved some
specific problems but
more was needed the jail command was
introduced by freebsd
in 2000 jail is more sophisticated than
true in that its additional features
help to further isolate file systems
users and networks
with the ability and also to assign an
ip address
to each jail in 2004
solaris zones brought us ahead even
further by giving an
application full user process and file
system space
and access to system hardware solaire
zones also introduced the idea of being
able to snapshot
a system in 2006
google jumped in there with their
process containers
later renamed c groups those center
around
isolating and limiting the resource
usage of a process
and moving right along in 2008 c groups
were merged into the linux kernel
which along with linux namespaces led to
ibm’s development of linux containers
[Music]
2013 was a big year this is when docker
came on the scene
bringing their ability to package these
containers and move them from one
environment to another
that same year google open sourced their
letme container that for you project
which provided applications the ability
to create and manage their own sub
containers
and from here on out we saw the use of
containers
and specifically docker explode
um i love this part because
containers have been around for a long
time the idea of containers
this is not new stuff it’s just packaged
differently and docker took advantage of
that and
succeeded in 2014
doctor chose out chose to swap out their
use of the lxe
toolset for launching containers with
lib container
in order to utilize a native golang
solution
that was something new that i didn’t
realize is that
their lib container was made was written
in goling
[Music]
all right i’m almost done i promise this
is a very busy slide
i’m skipping over some details here
around different projects
organizations and other specs that came
out because i want to get what to what
happened in june of 2015.
this event is important to know about
because it will give you some insight
into some of the activity and
motivations
behind the shifts in the market the open
container initiative was established
which is an organization under the linux
foundation that includes
members from many major stakeholders
including docker
with the goal of creating open standards
for container runtimes and
image specification
[Music]
while all of this is happening in the
container world
there’s a couple of other dates that are
going to be important to us java devs
to know specifically the first is that
java 7 was released in july of 2011
and work was started on java 8
which was released in march of 2014.
keep this in mind because when you start
containerizing your java applications
this little bit of history will be
important to know and i’ll be bringing
this up again later
all right that’s it for history let’s
move on
to the container market and what’s going
on there
i did a little hunting and found that
for the last
three years well several years actually
sysdig
a company that provides a really
powerful monitoring and troubleshooting
tool for linux
some of you may already be using this
tool
they put out a container report based on
the analysis of their users
and part of the report includes data on
container runtimes that are in use
in 2017 they analyzed data from 45 000
containers
in the huge scope of things that isn’t
very many but we’ve got to start
somewhere
there’s no graph here available because
99 of those containers were docker
so they didn’t even split up the results
in 2018 however they analyzed data from
90 000 containers double their sample
size
we’re getting somewhere 83 percent were
docker
and then we see you know other
percentages for coreos rocket
mesos and lxe so it looks like other
container run times are starting to
encroach
a little bit on the docker space
[Music]
moving on to 2019 now we’ve got some
numbers we can work with
the cystic container report included
stats from over 2 million containers
and docker is still holding relatively
strong at 79
18 container d but uh it’s worth noting
that container d is actually a runtime
that docker builds on top of
that last percent uh four four percent
is cryo
and uh this data is interesting
especially because of what’s been
happening over the last few years
um something um to note here is that
disappearance of
core os rocket that’s kind of a sad
story
core os was required by red hat at the
beginning of 2018
and prior to that rocket was accepted to
the cncf
that’s the cloud native computing
foundation as an incubating project
and it really looked like a promising
competitor competitor to docker’s
container d
um their approach to security for
example was
a little bit different and and favored
however
since that acquisition the development
of the project went dormant and in mid
of
mid 2019 rocket was archived by the cncf
and in february of 2020 the project was
[Music]
ended
all right uh the last report just came
out in january
this is their 2021 container security
and usage report
and it’s hard to know if we’re comparing
apples to apples here
considering that little qualifier of a
subset of customer containers
but this report includes a ton of
detailed information about their
demographics
and data sources as well as other
interesting information around
what services customers are running like
kubernetes
as well as you know what they’re using
for orchestration
um i put the link here to this report so
uh when you get a moment and you’re
curious it’s definitely worth taking a
look at there’s a lot of information in
there
but in a nutshell what i pulled from it
was this i noticed that
increase in usage of container d from
18 in the previous report to 33
it’ll be really interesting to see if
that trend continues
especially since kubernetes announced
they will be deprecating support for
docker as a runtime later this year
some of you might have questions about
that but that’s nothing to panic
over all that means is that
you can’t use docker as a runtime in
kubernetes they won’t be supporting that
anymore
but the images that you create with
docker those are still compatible
you can still use them you just have to
switch out the runtime
all right now that i’ve introduced a few
of these other
container runtimes that exist out there
besides docker
it’s time to start talking about what a
container actually is
and what docker actually provides in
order to appreciate
those differences could you momentarily
speak to
the commonalities between these
containers as well
because of the open specification and
how there is a unified
idea of what each of these containers
are now providing
and therefore the kleenex will survive
as a container and therefore the
differences between
all three of these that you have
mentioned becomes
moot if anything the specification that
docker will no longer
as a as a trial example
not have to run as root becomes a large
hurdle to give its popularity back
right that’s exactly correct all right
so let’s get into talking about
what docker is exactly and this is a key
point
what docker had over other players in
the container game was a focus on
commoditizing a complete
solution that made it easy for
developers to package and
deploy their applications and once
containers became
easy to use we all witnessed that
explosion of tools and resources around
containers
and the docker image format rose to
become a de facto standard in the market
and the stats that i just showed from
sysdig are specific to container
runtimes that terminology is important
to understand here
and i’ll explain those pieces and parts
involved in working with containers
and you’ll immediately understand why
docker was able to suck up this market
so quickly
and as you mentioned why i don’t think
they’re going away anytime soon
[Music]
all right as users let’s think about
what we actually need
to get our apps out there and running
often we can
find ourselves getting so far down into
nitty gritty details that we lose sight
of the actual problem we are trying to
solve
that reminds me of my first job as an
intern i had an amazing boss
and whenever i started to overthink
something
or stumble around to make a decision he
would always come out with this advice
always go back to the original problem
you are trying to solve
ask yourself if the move you want to
make is getting you further or closer to
solving that problem
and i use that advice to this day
so here’s a list of needs that are
broken up into discrete features
first and foremost we need that
container itself
and some of you might be asking about
virtual machines
vms at this point um i just had someone
the other day
um you know they they said well vms are
the same thing as containers
and and we had a long conversation i was
pretty raw
after that but um
discussing vms we’re not going to do
that too much during this session
but the one thing that i’ll say about it
is they’re not the same thing as a
container
the biggest difference being that a vm
is usually understood to include an
entire os all to itself and containers
actually
share the systems os the point of the
container is to be lightweight
and have that ability to move from one
environment to another seamlessly and
quickly
that said i know there’s there are some
developments happening in the vm space
but that’s a topic for another time so
the rest of this list
uh we need an image format to define a
container
we need a method of building an image of
a container
and we need a way to manage images
we need a way to distribute and share
those images
and we need a way to create launch and
run a container environment
we also need a way to manage the life
cycle of the running containers
and i didn’t even get into orchestration
or anything like that
this right here is plenty to prove my
point about docker
so in the context of those developer
needs that we just went through
docker was ready for an answer for
everything
you want to start using containers well
we have docker engine for you
you need an image format well here’s the
docker image format
you need a way to build an image sure
we’ve got uh
you can use a docker file um just call
the command docker build
you want to manage those images call
docker images
or docker rm for remove
you want to share your images or use an
image from someone else
call docker push docker pull oh and
there’s docker hub
where you can store and share your
images
if you need a way to launch run and
manage your containers in their life
cycle you’ve got
docker run docker stop docker ps
docker quickly succeeded in meeting the
immediate needs of our container hungry
market and on top of that
the tool sets that docker provided made
it all
easy a huge plus for developers and that
was a huge
tremendous part of the market share that
they were able to walk away with
[Music]
all right now we’re going to get into
these pieces and parts and
nomenclature here is very important
differences between images
runtime engines all of that stuff
matters
remember in our history lesson when i
spoke about the open container
initiative
out of all of those features that we
just discussed that docker offers
there were two that were taken up for
the cause by the oci
the image format and the container run
time
they actually also offered up
distribution but i’m going to stick with
these two for now
docker did quite a bit of reorganizing
their code base
developing abstractions and pulling out
discrete functionality
they are a heavy contributor to the oci
they actually gave the docker version 2
image spec
as a basis for the oci image spec
they also gave run c which was a
contributed as a reference
implementation of the oci container
runtime
spec there’s quite a few other container
runtimes you might see out there
including container d remember this is
one that
docker uses cryo and kata
are other options all with various
levels of features for specific use
cases
again about docker building on top of
container d
container d was actually contributed by
docker
to the cloud native computing foundation
and it
itself internally uses run c
container d was integrated into docker
and has been in use since
version 1.11 which came out in 2016
so that’s old news it’s been a while now
the next few years i think are going to
be really interesting to observe what
happens with these specs and how the oci
moves forward there’s a quite a range of
differing opinions about what should and
should not be
in the standard for a container runtime
and we’re in a situation where having a
runtime that just meets the requirements
of the oci spec
doesn’t seem to be enough to drive
adoption
i’ve added a couple of links here that
are excellent starting places to learn
more about
computer run times or container runtimes
if you’re curious uh that second one in
particular
is the beginning of a blog series by ann
lewis he’s a google dev advocate
the first subtitle in that blog was
called why are container runtimes so
confusing
which immediately attracted me when i
was looking into this
ian does a really good job of explaining
some of this and he goes into details
about
low level and high level run times and
where they might overlap
which causes some of our confusion
all right what if you don’t wanna use
docker
that’s fine you might wanna sit yourself
down and ask why not
maybe it’s that long long-running damon
the dr damon
there could be reasons you don’t want
that maybe you just want to stop
thinking that docker is all there is and
we really need to stop calling all
containers docker containers because
it’s not really true
maybe you want to build your own images
using a bash script
you just want to do it all yourself
because you certainly can
it’s it’s not magic you can definitely
do that
there are these other projects out there
um podman
usually you use that to run containers
um
build a use that to build images
um scopio can be used to transfer
container images from remote
repositories
there’s a couple of other projects i
don’t list on this slide
bazel is a google tool uh kenneco
is another google tool those two i have
not used
so i will not comment on them but i
think it’s it’s interesting that
with the open specs and stuff we’re
going to see more
tool sets come out there
some of the cons here right away is
these aren’t really convenient to run on
a mac
mac os or windows os so if that’s what
your development environment is
then you might just stick with docker
um also like pod man machine that’s
that’s an option to maybe
you know get that running on your mac
for example but it still requires a
linux vm
um also oh something i didn’t put on
this slide as well as jib
i’m curious how many of you have used
jib and what your experiences with that
i’ll bring that up again a little bit
later when we we talk about some of the
some of the gotchas that you can get
into when you’re building a docker file
and if if i forget to bring this up
again definitely ask me afterwards
but i’m going to
just post the jib link to our chat
since i don’t have it on the slide but
it’s a good one to go
go check out mainly the the biggest
point with them is they optimize your
images
um you don’t need the docker daemon and
um
the way they optimize the images is um
you know normally you might see your
whole java app be in a single layer
and they actually break it up into
multiple layers
it’s a little bit more efficient
all right moving on now that we
understand
all that docker entails that it’s an
entire tech stack
not just one thing um and also some of
what’s going on in the market
let’s focus on just what the container
itself is and what that looks like on
your system
i’ll show you how it’s stored and what’s
actually happening under the covers
there
and you’ll discover like i said before
that it’s it’s not magic
[Music]
so my first experience with containers
it’s been several years now but
um i was a developer on a
new team new project there was a tight
deadline of course that can
that can be a good description of most
teams
and most projects um the best course of
action for me in general is just to jump
in
and start getting something up and
running on my local machine i learned
best by doing
so the docker documentation that i came
across
is actually it was good then it’s really
good now
so if you find yourself in a similar
position i recommend going through their
get started docs i’ve linked those here
on the slide
and going through this guide will get
you comfortable with all of the docker
commands you’re going to need
the ones i had on a previous slide those
are just the bare minimum
there’s a lot that you can do
the first thing to note is that
a docker image is really just a tarball
of a complete file system and when an
image is unpacked
it’s just thrown into its own directory
which becomes
its root file system the second
is that the processes that are involved
in running the containers
are just regular linux processes and on
top of that there’s just a few
linux features that are used together in
a way to achieve that
isolation that we want from containers
namespaces are an important ingredient
because this is what is used to provide
that virtual separation between
containers
this is how the processes inside a
container don’t interfere with the host
or processes inside another container on
the same host
here you can see the namespaces that
were set up for a postgres container
that i have on my box
stop here for a moment and speak to the
fact this is the area where run c
has failed and those security issues
that have been noted because of docker
have been alleviated most part and this
is why podman was developed
to actually speak to the fact that when
you run docker
in its native form it’s running as root
and this is one of the security flaws of
why alternatives came out and why the
open container initiative was created to
actually speak to these
issues to allow a better isolation by
not running as root also there are
alternatives
using jib that should be considered
because there are successors out there
currently right now called j cube i will
put a link into the chat
awesome thank you it’s definitely worth
checking out
all right the c groups functionality
that those are essential to constraining
how much a container can use things like
cpu
memory network bandwidth etc and
you can see that i’ve set these
constraints by including options on the
docker run command
you can do that when launching an image
here
you can see that i’ve constrained the
memory usage limit on one of my
containers
all right i’m going to quickly gloss
over some file system details
where containers and images are actually
stored on your file system
i went digging around one day just just
to satisfy my own curiosity
on you know how my file system on my
local machine is actually changing
when i’m building these images running
these containers all of that stuff
part of it was because something was
broken and i just needed to figure out
how to clean it up
so um this was this was quite the deep
dive
anyway um first off after you’ve
installed
docker assuming that’s what you’re using
and not something else
running the docker info will spit out a
bunch of information about your
installation including the docker root
directory
this is where most everything you’re
going to care about regarding your
docker images and containers will be
stored
and note that if you’re on a mac your
containers are actually running in a
tiny vm
so you’re going to need some tool like
screen or something to get in there
and get to the docker root directory to
look around
if you’re not familiar with that tool
with the screen command for example
definitely google that in advance get
familiar with it first
it will mess up your text display pretty
good on the mac if you don’t enter and
exit it
appropriately
[Music]
this slide shows how you can get
information about the images that you
have stored on your system
first i listed my available images using
the docker images command
i actually have several installed but
i’m just showing you the first couple in
the list
using the docker inspect command i can
expect
any image i like using its image id
this will spit out a ton of interesting
information but what i want to highlight
here is the graph driver section
which contains the paths to the
directories where all of those layers
that belong to this image live
docker images are composed of layers
which represent
instructions in the docker file that was
used to build the image originally
these layers actually translate into
directories
these and they can be shared across
other images
in order to save space pretty clever
the lower mergeder and upper dir
sections i want to highlight here
the lower dir directory contains all of
the directories
or layers like we just learned that were
used to build the original image
and these are read only the upper dir
directory contains all of the content
that has been modified while the
container is running
if modifications are needed for that
read only layer
in lower dir then that layer is copied
into the upper dir where it can be
written to and you may have heard the
term
copy on right operation that’s what that
is
it’s important to remember that that
data that’s in upper dir
is ephemeral data it only lives as long
as the container lives
in fact if you have any data that you
intend to keep
you should utilize the volume features
of docker
and mount a location that will stick
around after that container dies
and this is how most containers handle
running a database by the way
lastly the mergeder is kind of like a
virtual directory that combines
everything from lower dura and upper dir
and the way the union file system works
is that any edited layers that were
copied into upper dir
will overlay the layers in the lower and
that’s what you see
when you get into your container
all right i actually have a few
containers currently running on my
system
two of them are my local jfrog container
registry installation
which includes a container for
artifactory and a container for a
postgres database
the other is a simple test container i
was playing around with
and note that the container ids of the
running containers match up with the
container subdirectory names
something to remember here is if you
stop the container
that corresponding directory doesn’t
automatically go away until the
container is actually removed
with the docker rm command or some other
method
so if you have stopped containers that
are lying around and they never get
cleaned up
you might see your available space start
to dwindle
there is a docker
system prune command you can run that
every now and then to help clean things
up
or you can launch a container with a
flag to indicate that it should be
removed when it’s finished running
a lot of orchestration systems like
kubernetes can handle this part for you
i’m just important to know about it
especially when you’re developing on
your local box
[Music]
okay now we’re moving on into gotchas
these tool sets around building and
running images
and containers have made things so easy
it’s also easy to shoot yourself in the
foot
in a few places and i’m going to go over
some of the most common gotchas here
including some jvm specific ones that i
run into immediately
when i first started working with
containers
[Music]
the first is running a containerized
application as the root user
and i’ll be totally honest here um when
i was initially getting containers
up and running i was just so excited
about how well it was working
that it was a while before i took it
seriously now that
i know that processes inside a running
container are just like any other
processes on the system
albeit a few constraints it’s pretty
scary now to run his route inside a
container
and doing that opens up the possibility
of a process escaping the intended
confines
of the container and gaining access to
host resources
the idea here is to reduce the tax
surface of your container
by following the principle of least
privilege although containers are
designed not to affect
other running containers if someone were
to gain access to your container and
immediately has root privileges
they can wreak havoc on your host so how
do we mitigate this problem
the best thing to do is to create a user
and use the user command inside the
docker file when the container is built
in order to run processes as that user
there is a way that you can specify a
user when the doc
when you use the docker run command but
that leaves you can like pass it in as a
flag
but that leaves open the possibility of
forgetting to do that
it happens and it’s just nice if the
image itself is set up by
by default not to run as root
so pay attention to all of those
official images that you pull down
from docker hub uh whether or not they
run as route or if they leave that up to
you to figure out
um some of them are you know really
handy but what i
of what i see generally as a pattern is
um especially within companies that have
you know better control over that they
will pull down you know official images
from docker hub
but then they will modify you know make
modifications
using a user that everyone is aware of
and they will create that image and then
that image is what’s used as the base or
the parent image
of anything else in the company
[Music]
all right even though docker provides
you with the ability
to set some resource limits on your on
your container
it does not automatically do that for
you in fact the default settings are
pretty much a free-for-all
with no limits anywhere so make sure
that you understand the resource needs
of your application
too little your container will die from
starvation
and too much and the container could
smother others on the system
so using containers although very
convenient it is not a license to be
lazy
and not understand the resource
your usage of your application that’s
something also that you’re going to want
to monitor over time and adjust as
needed
just like your java applications before
it’s a very good way to determine if
something is going wrong
or if load on your system has changed
for some reason
you can also use that information to
determine if your application needs to
be split up
further with certain actions scaled
differently
[Music]
never updating this is a huge security
issue
and it’s very easy to get complacent and
not pay attention to what is actually
being pulled in when you build images
not only do you need to be aware of
outdated versions that you specify in
your own docker file
but you also need to pay attention to
what’s in the base image that it’s
coming from
not updating those packages and
libraries
inside your container those can lead to
some pretty embarrassing results
especially when there are tools
available now to alert you when security
issues have been discovered
with specific artifacts even ensuring
that you’re
running containers with a non-privileged
user
even that has risk when there are known
vulnerabilities that exist
within your container or even on the
kernel of the host
from time to time exploits are found
that enable
attackers to potentially escape a
container
we know it happens it’s not something
that you can always prevent
so definitely have a process in place to
respond
to those events and regularly update
your package packages keep up with those
security updates
i’ve definitely a strategy should you
come up with a strategy of coming up
with a list of base approved images to
start with so that
at least your brownish banana doesn’t
look that bad
exactly that’s a that’s an excellent
idea and i’ve seen that
before where like you might you might
get a
you know an an image from docker hub
that everyone uses right but then
internally
you update it and you um use that image
as a base image
internally it’s a very good very good
strategy to have
and you can organize your base images
pretty well that way
um i yeah not updating
that’s common too i’ve also seen that um
if it hasn’t been a priority it’s
usually because of the fear of breaking
a product or service that
that’s already working um but in reality
that’s a symptom of a different problem
and it’s just not worth it it’s um much
worse to leak private data
or potentially be the start of a domino
effect that can bring an entire system
down
rather than you know take the time and
come up with that strategy
and update your stuff
[Music]
all right this one’s fun i don’t know
how you feel about that graphic but it’s
really just about something unexpected
this is java specific very specific to
containerizing java applications
and very much related to being aware of
what your application requires to run
successfully regarding memory
that jvm is pretty clever at
automatically determining
settings for your swap and heap and your
garbage collection
and all that lovely stuff based on
things
like the memory and the number of cores
available on the host
and remember earlier during our history
lesson when i mentioned the dates for
java 7
and java 8. java 7 was released in july
of 2011
work was started on java 8 in march of
2014
so considering that timeline of docker
developments and java releases java 7
and earlier versions of 8 and certainly
earlier versions
are not fully container aware this means
that your java application
won’t necessarily obey those memory and
cpu constraints that you put on your
container
you may end up with some surprise out of
memory killer activity
if you aren’t paying attention to that
the reason for that
is that the mechanisms the jvm used in
these older versions to retrieve the
resources available
those came from the actual host machine
and not the
c group limits that you would expect
there were some improvements around
container awareness that were introduced
in java 8
on update 131 specifically
and further improvements in later
versions and some back porting going on
but to really get all of the benefits of
container awareness you really should
get to java 11
the latest lts release that is container
aware
[Music]
all right container gotchas and image
bloat
um something i see a lot
pulling in large parent or base images
that include a bunch of stuff you don’t
need
that increases your attack surface area
from a security perspective
and shipping these large images around
and storing them
can become clumsy slow and expensive now
since we’re paying for
all of our storage in the cloud these
days
um start with making use of the dot
docker ignore file it’s very similar to
the git ignore file
use that to keep those unnecessary items
out of your
images i’ve also seen
in build you know docker files that are
being built sometimes i see
like a one line copy of an entire source
tree
into the image and there’s actually
multiple
problems there you are you know
including tests
maybe a test directory or something that
you you really don’t need
um also that if you do that in one line
that’s an
entire layer with all of your stuff and
if
anything ever changes which it will with
every check in
that layer has to be regenerated every
build
so organize your code so that stuff
changes
the stuff that changes the most often is
in its own layer
think implementations versus
abstractions
and that’s that’s where jib comes in
that
you know kind of handles that for you a
little bit
another um thing that i’ve seen is
is mistakenly including the get
directory
even obviously that’s not a good idea
to include in your image you could
possibly be including secrets
and even if you take the step to delete
specific things
after that copy it still lives in that
previous layer
stored on the machine you may not see it
but it’s still there
that said if you’re pulling your java
source
into the docker file you’re likely
including your build tool
as well like maven or gradle
learn to use utilize the docker
multi-stage docker build
so you don’t end up with all of that
craft all of those extras
in your production image and this
problem is certainly not limited to
java projects i’ve seen it with other
code bases as well
all right managing your images this is
important
more than you know we’ve talked a little
bit about it about pulling images from
docker hub and stuff
um consider where your base and parent
images are coming from
and if you’re not specifying a container
registry
in your docker file by default it is
coming from docker hub
that’s the default behavior so
if you want to only use the images that
are provided
by like an internal registry you need to
specify that internal registry
um proprietary images you know maybe you
want to protect those and not just make
those available to the general public
make sure that you are putting those in
a private registry
that you have credentials for
public registries like docker hub they
certainly have their purpose they’re an
awesome place to share official images
and get some of your
services up and running quickly without
starting from scratch
but i definitely highly recommend using
a private internal container registry
this will help keep you reliable access
to
those required images for your builds
you can avoid
random failures in your pipelines
because of network issues or
a missing image due to a you know lost
connection to the public
registry you also have better control
better access to proprietary images
there are a ton of free tools out there
and of course i’m going to
point you to the jfrog platform
and there’s a link here that you can use
and try out
you can store images there
it will proxy images from docker hub
i already mentioned it a little bit at
the beginning as well
pretty good stuff also if you’re new to
container registries
at the bottom of this slide is a link to
a d zone rough card
that’ll help you learn a little bit more
about the things that you should
consider
when you start setting up a container
registry or choosing one to begin with
what else here oh the fuji link
uh that’s the last resource i’ll talk
about when you build your images with a
particular jdk
because you should you want to be if you
want more specifics on which version
or update to use fuji io is a great
resource to help you compare
those java versions and get detailed
info on updates
all right that’s all i’ve got for you
today
um i will open for questions for sure
and um i need to know who to
share or make host
once we’re done with questions
so that you should be right below
i’m sorry who that would be ted oh
ted okay he’s the one who normally
handles the raffle there
but does anyone have any questions here
for melissa
wow everybody’s real quiet okay i
don’t have any questions i just thought
it was a really good talk very
informative
thank you yeah i agree i really like the
background the
historical background as well
yeah i tried to work with
some source code i got source code for a
project and i tried
to deploy it on my local machine and i
didn’t have any information about
um what did that what how to go about
setting up the database
what the passwords were what the default
tables were
all that sort of stuff i sort of said oh
that’s what containers are all about
so that you have the entire ecosystem of
your
uh your your your your your system
in there you don’t have to worry about
keeping track of
passwords and all that because you got
the the things that handle secrets and
connect with the database and
and you know was it designed for which
type of
operating system was designed for do you
have the right packages installed
and it just was like oh that’s our
container is all about
so i’m like i’ve been hearing it but i
did sort of understand it so thank you
very much
you’re very welcome yeah they’re pretty
powerful
and um something that i like to use
especially for like testing in qa
environments and stuff
test containers very very awesome
project if you aren’t using that
definitely take a look at that because
you don’t you don’t always want to set
up you know
a production grade database for example
but you also don’t want to use an
in-memory database which
may be a little different in syntax or
by you know the queries might be a
little different
than your actual database that you use
in production so um
definitely check out test containers
that can make that process a lot easier
on you
you know talking about the the security
of containers
that’s something that’s uh really on my
mind a lot lately
and one of the the mantras i hear a lot
in security is make it easy to do the
right thing
and so what i’ve been thinking about or
working towards is
providing that base docker template
that based docker file that includes
the creating the user that doesn’t have
the elevated access
and and providing that information for
the other developers that
you know they’re just trying to get
through the docker file to get their
thing deployed they don’t really
know it or understand it or maybe
necessarily even care about it
but you know just make it easy for them
to do the right thing
and see that that last step copies
everything over
puts it in the lower level access and
sets it up
that’s excellent excellent advice you
can definitely
yeah narrow you know reduce your risk
by bringing that all up top and have you
know a team that are
handles that stuff because all it takes
is one developer
to push one change to a docker file that
can
open you up for problems so yeah and
that’s
i like that sentence you know make it
easy
if you want it to be done correctly make
it easy
developers need things to be easy
we’re lazy we just want to get this
stuff done
one of the names that came up on one of
the slides that i saw at the very
beginning
his name is matt rabel he is a great
speaker
about creating secure by design
and actually speaking about having
managed containers in a
kubernetes environment yeah and one of
the things is like
the developer is the person that you
should start with first
and there is something called the four
c’s that you can look up on kubernetes
website to actually look at the fact
that how they
on kubernetes t talk about security
and therefore you have to come up with
some way to use things like
open id oauth jwt
in concert with each other to actually
have
an oauth provider as an example key
cloth
that you would actually stick in your
kubernetes environment and therefore you
would then
control who has authority to talk to
microservice a to microservice b
to microservice c and therefore the key
cloth
is your oauth provider that provides all
of these things the
open id the oauth as well as the jwt
and therefore then controls that type of
orchestration of the microservices
when you then put this also
with istio which is your service mesh
with
envoy on top of this you have a totally
locked down environment from a network
perspective
along with authority inside of your
kubernetes environment
and if you really want to go to the nth
degree and lock down your
uh cube control put
shippa on it and therefore then you
would have
roles as well as users involved in your
kubernetes environment
these are the things that i think are
the most important things that a
developer
a developer not an administrator should
actually
learn as the tools that they should be
implementing to stick
into their environment to get a fully
functional productionized version of
what they should deliver
yes all right three things i’m just
smiling as you’re speaking
um matt rabel and i are good friends
he’s actually here in denver i’m in
denver as well
and we run devoxx for kids together and
um
yes and you have your next next meetup
group with matt so you can start
peppering him with questions for sure
oh i’m an awesome guy i love his
talks i am a big big
fan i love his vw
read about his and read about his slides
read about
seeing what he puts on youtube he has
the most
important view of how to handle
cloud native and i do mean cloud native
deployment of where you could go in this
in these types of environments
and therefore if you containerize and
stick it in kubernetes and get it into a
managed environment
the way i described i think that you can
then find the lowest price that you want
to go from aws to google to azure
or even ibm yeah definitely
um second i have a service mesh talk
that i do
so yes i enjoy talking about service
mesh and all of the
um abilities that gives you including
the security
you know no longer do you have to worry
about anyone talking to your container
or your service without going through
that gatekeeper
and third
we have some swamp up talks around that
very subject so um definitely consider
taking a look at some of our swamp up
sessions around that did you talk about
um i do i’m doing one with shipa
actually
i want debugging and visualization
for what i have described more like kali
and other things that are available to
involve
envoy because the fact like envoy is not
really representative enough to actually
show the ingress and egress points of
view
that you need to have visibility so that
when things go wrong in the middle of
the night you get a call i’m sorry
you have to it’s too hard to dig through
and with all the commands and everything
to find where the bug is right exactly
um one suggestion have you looked at
datadogs
offerings at all they actually have a
pretty
amazing visualization tool that uh lets
you track
you know the communication between all
of you use the bad word
free oh no
unfortunately now
right now no money is available for me
to actually
gotcha totally got it understood
oh here’s something that’s that um is
free
okay um and something that might you any
you know some of you might find this
useful
um the jfrog platform
has a free service um you can sign up
for that
there’s a link on this slide here for
that um
part of that is a version of x-ray
which monitors you know all of your
packages that you have that have been
pulled in
to artifactory there it includes
artifactory as well
and it will you know scan those packages
and let you know about any known
vulnerabilities
and on top of that as a developer you
can actually include a plug-in on
all of the main ides i use intellij love
it
and i just add the jfrog plugin i set it
up to communicate with my x-ray
and i can tell right there in my palm
file
when i’m ready to add a dependency i can
put that dependency in there
and it’ll let me know if there’s any
already known problems with it that i
need to
consider before even checking it in
would that alleviate the issues that is
my next issue
is having a bill of materials to be
published as part of the build of your
container because right now because of
the solar winds our orion
debugger problem that got in because i’m
sorry microsoft
supply chain attack because of that
fact has just turned my head upside down
in the fact now i can’t trust bills now
we have to have
a completely virgin build that now has
to be validated against a developer so
you have to build it in two places
once again secure once against the
developer and they must match by
checksum
exactly yup
yup um we definitely have that bill of
materials
you can use that for troubleshooting you
know one build to the next
also if there’s a vulnerability that’s
found inside a docker image there’s
actually a visualization that will
go deep into the layers it’ll tell you
exactly what layer
has the problem and what package within
that layer has the problem
so maybe like you don’t even have real
access or
have paid attention to your base image
for example this would allow you to see
a problem in your base image that you
weren’t aware of
well too much of what’s going on still
i’m sorry even though it’s become very
convenient in the fact that we’re
checking in containers
it’s still turning into an idea of
throwing it over the wall
and now there is now a real
real lack of trust of what’s being
thrown over the wall oh yeah
as there should be um it’s
this is the problems we’re seeing now
they’ve the capability to do that
especially for those supply chain
attacks
especially if you’re using you know npm
for example
any open registry or repository where
anyone can put stuff in there you’re
running this risk
and so many people we just don’t think
about it because we don’t have the
criminal minds we’re just sitting there
doing our job getting our stuff out
there
and this this problem has been around
for a while
with artifactory this is good to mention
something to help prevent a supply chain
attack especially with
internal packages that you use
internally that
have no business being in a public
repository
and the way to prevent accidentally
pulling something in from a public
repository when you intended to get your
local stuff
you can set up artifactory in such a way
that it will
ignore anything that’s public and only
take your internal stuff
well that’s the idea of the white list
ideas of even images or base images that
this is the white list
artifactory idea that you’re actually
putting here and i think that’s
always been there since i think
artifactory came out at least for most
companies i’ve dealt with
yep um just not
not enough people are using that feature
to uh
protect themselves
this is an awesome conversation i love
getting into these um especially java
user groups i feel like
you know we actually get to learn
something and i always come away
learning something
it’s really good
all right bruce are we ready to do
something i think so raffles
all right no more questions here from
melissa
then what i’m gonna do is i’m gonna turn
off this little
record button so please ask the host to
give you permission to record
okay so i just think i turned it off
okay and i’m making ted the host that’s
correct
all right normally at this time we’d
have a big round of applause
thank you
okay ted i see you yeah i’ve got
um i’ve been taking notes here so
i’ve i’ve only got two entries so far
for the raffle so
you just oh and there’s another one in
as two more that just came in we’ve got
people that are very
right so if you would like to be in the
raffle
what you should do is uh put your name
and email address in the chat
box and message it to
ted so he can see it
and is that avatar i think i just saw
pop up there sorry about that you should
have your ebook from last month
i was just a little delayed in getting
it out
yep i think i received it yeah
that was my fault i sent the messages
out right away
i just didn’t see them come back right
away so they were just a little slow
in getting them to manny but yeah i
think
i think he did get his work as a sorry
whom should i send my
email oh that would be to to
he’s the guy here who’s yeah to me
it’s right next to me uh
in the i can
that’s the guy to send to i just put it
in the chat window and just private
message it to ted
must be present to win and by the way
the speaker
is eligible to win a prize
if it matters
let’s see i’m just i i’m trying to do
this systematically so that i
i
i make sure i get every person exactly
once
i think is you’re the host you have to
be the one to turn off that recording
oh i’m getting me shut it off all right
you should have a record button
probably down at the bottom