The Docker Container Ecosystem 101 @ Docker Bangalore Meetup

is a developer advocate
at jfrog she’s a mom she’s a doctor
cabin
a java champion and co-author author of
an upcoming book
devops tools for java developers
melissa’s the longtime
developer turned international speaker
who will be sharing
today on the docker and container
ecosystem 101
a presentation that she actually shared
at dockercon this year so without any
further ado we want to welcome melissa
hey everyone hey i’m super excited to be
here
um really happy to be you know it is i
think it’s
12 and a half hour difference or
something like that it’s actually
9 45 here right now i’m located in
denver colorado
um it’s been really hot here the last
few days um
but other than that nothing to complain
about uh
i am excited to talk to you about
containers today
the docker and container ecosystem to be
uh specific uh we’re gonna have a new
batch of developers new to containers
and to docker every year
and my personal introduction was sink or
swim i found myself
wading through a bunch of new
terminology i didn’t understand
and i discovered quite a few stumbling
blocks that slowed me down
and not to mention suffering some of the
consequences of trial and error
so my goal for you for this talk um the
first one of today
is to have a good foundation before you
jump into the deep end of containers
we’ve got a lot of container talks
tonight
and sometimes we forget that there may
be some folks in our audience that are
brand new to this
and need a little background i could
have really used a session like this to
quickly get me up to speed
on understanding the terminology the
different components of the big picture
and clear up any silly misunderstandings
of overloaded terms
like container or do we actually store
containers
in container registries that kind of
thing
this is our agenda today as ari said i
did
present this talk at dockercon and it
was one of the
the introductory talks so i hope that
you can get a lot out of this today
um right now i’ll just uh already
introduced me already so i’m gonna
briefly go through a slide there so you
have my twitter handle and all of that
business and then we’ll move on to a
discussion of one
of why one might want to get comfortable
with containers right now
the history lesson is the heaviest
portion of this talk so make sure you’re
in a comfortable spot
get comfortable in your chair where you
can absorb this info because it’s going
to come at you pretty fast
i’ll give a brief explanation of the
docker ecosystem some of this 101
terminology
around containers and then i’ll finish
off with a few resources
for you to go and learn more
ari already introduced to me thank you
very much for that beautiful
background i have been in the industry
for over 20 years
have been a developer at various levels
and a year and a half ago joined jfrog
as a developer advocate i am a java
champion and a docker captain
and you can find me at twitter on
twitter at melissa j mckay
all right so let’s get started my
introduction to docker was
by way of a project that was developed
by a third-party contractor
so in my case this wasn’t a decision
made by our team at the time
the first thing that i saw when i was
ramping myself up on the code base where
were those docker commands in the readme
file and a file named
dockerfile in the root of the project
i’m always up for learning something new
so i was intrigued what is this docker
thing
this particular project that introduced
me to docker was already designed
code was already written and functional
so in this case the best thing for me to
do was just to dive in and figure out
how to set it up
how to build it and deploy it as it was
this strategy
has always worked pretty well for me
when ramping up on any project
especially when it involves a new tech
stack or framework
follow those instructions the best you
can if you have them we were lucky in
this case
to get it up and running make note of
any difficulties or questions that come
up
adjust the instructions if necessary and
then go back through again to understand
how all of those pieces fit together
this is something that you would do
repeatedly at the beginning of a project
right away i had so many questions like
these questions here
but there was nothing uh initially
stopping me from moving forward
i learned best by doing so my first step
was to download docker desktop to try
this thing out
before we get into those darker details
specifically let’s ask the most
important question
why would we or should we use containers
i don’t know why docker was chosen for
the product
project that i was tackling at the time
i was not involved in those initial
discussions
but as i worked with it in setting up
our development environments and our ci
cd pipelines
i saw several advantages
if you’re doing the same and you’re
thinking of wrapping your applications
in containers and going cloud native
just take a moment to consider the
problem specific to your project that
you’d like to solve
put these down in writing somewhere i
see so much documentation out there that
goes into depth on how to do something
without explaining anywhere why so let’s
go through this list
um the first one here is kind of a joke
really you’re using java 11. well java
11 was released in september of 2019
java 16 just came out recently but i
know
so many projects that are still back on
java 8 for various reasons
i know it’s frustrating to deploy a nice
new java 11 application
to a prod machine that only has java 8
installed
that’s just one example of you know a
language specific problem obviously
contain you know applications that are
containerized are not all going to be in
java i’m just pulling from
from my experience and my background
here
the second item here i love my macbook
my workspace workstation is my macbook
um i was introduced to mac um i don’t
know maybe the
the third position i was in or the third
team i was on and i haven’t gone back
since i
i love it um but how many of you have
worked in code that has a bunch of if
statements in it
around what os you might have i had
co-workers that were running on windows
i’m sure there are some legitimate
reasons for this um
but i’m remembering scars from the
browser wars the web browser wars
but i actually had a situation once
where unit tests i ran
failed because i was on a mac instead of
windows
there were some other issues there
multiple problems there to address
one was how it was dealing with the file
system but it
is nice to be able to have the option to
run unit tests
in a container without having to worry
about every possible os
the third item here there’s a bug in
production
the first thing you do as a developer is
to reproduce the problem
but that’s difficult when you’re already
developing the latest and greatest and
you’ve made changes to your environment
that are not backward compatible
consistency and build reproducibility is
key when you’re chasing those bugs
number four it works on my machine
only on my machine that’s related to
number two
again consistency in software versions
and libraries will make your life
so much less complicated number five we
just hired three new developers
this has happened various times in my
career where a new team is is started up
or
new members of the team have joined that
consistency that you get from step four
will make onboarding those team members
so much faster number six
my service is super popular this is a
good problem to have
you’ve put your service out there in the
cloud and now it’s getting
hit with a ton of traffic one of the
biggest reasons for moving to modularity
and to containers
is utilizing the strategies of cloud
native deployments to quickly scale
that application as you need as load
increases
now you might be asking right now um
don’t don’t virtual machines solve this
problem for us
they have isolated environments it
should be you know just fine
but the problem with vms vms have their
advantages
but they are not as lightweight as
containers vms contain
an entire copy of the os so it’s not as
lightweight
as a container which actually shares the
os of its host with
other containers
even if you’re not using containers in
production today there
are other scenarios worth considering
the use of containers in your
development pipeline
those dev environments don’t suffer from
the disappointing
disappointment of spending that entire
day debugging a problem that you find
out happens only on your machine
the test environment having that ability
to easily launch
other external services like databases
that type of thing
being able to improve your test
automation that’s an advantage
and then of course production um you may
have a problem with
securing dedicated resources uh
i know that i was in a situation where
uh getting a new server set up in
production involved quite a few
it tickets and a lot of time you don’t
have to wait
for custom provisioning or worry as much
about inconsistency
when you’re being when you’re able to
deploy with containers
now i want to get into that history that
i referred to earlier
it’s really easy to skip this part when
you’re eager to get started
but i recommend going through this
exercise with any new framework or
technology that you want to start using
this will be quite a bit of info but
bear with me because it’s worth it
understanding how we got here and where
the tool you’re about to commit to for
your project
where it came from can help you avoid
some nasty pitfalls and help you use
that tool in the most effective way
you know that popular cognitive bias
if all you have is a hammer everything
looks like a nail
this is also applicable here containers
are useful
but aren’t intended to solve everything
yet anyway
all right in the 1960s and 70s computing
resources were a lot more limited
than today computers were commonly
dedicated for long periods of time to a
single task for a single user
of course these limitations resulted in
plenty of bottlenecks and just general
inefficiency
efforts were started to develop a method
of sharing resources without getting in
each other’s way or having one person
inadvertently cause the entire system to
crash for all of its users
both hardware and software that advanced
virtualization technology started to
trickle in
uh one development in software was
charut which is where we’ll begin
in 1979 during the development of this
seventh edition of unix
true was developed and then later added
to the berkeley software
distribution bsd in 1982.
this system command allowed for the
ability to change the apparent root
directory of a process
and its children which results in a
limited view of the file system in order
to provide
an environment for testing a different
distribution for example
to root was a move in the direction of
providing the isolation required from us
today and several years
later in 2000 freebsd expanded that
concept and introduced the more
sophisticated jail command
and utility in freebsd 4.0 release
its features later which were later
improved in 5.1 and the 7.2 releases
those features helped to further isolate
file systems
users and networks and also included the
ability to assign an ip address to each
jail
in 2004 solaris containers and zones
brought us ahead even further
by giving an application full user
process and file system space
and access to system hardware google
jumped in with their process containers
in 2006
those were later renamed to c groups
which centered around isolating and
limiting the resource usage of a process
in 2008 c groups were merged into the
linux kernel
which along with linux namespaces led to
ibm’s development of linux containers
lxc you may have heard of those
now things get even more interesting
docker was open source in 2013
and that same year google open sourced
their let me contain that for you
project
which provided applications the ability
to create and manage their own
sub containers and from here we saw the
use of containers
explode docker containers specifically
initially docker used galaxy as its
default execution environment but in
2014
docker chose to swap out their use of
the lxc toolset
for launching containers with lib
container which is a native solution
written
in go that was something new that i i
learned i didn’t realize that docker was
written and go
soon after the uh let me contain that
for you project ceased active
development
uh with the intention of joining forces
and migrating the core concepts of that
project into docker’s lib container
a lot more stuff happened but before we
leave
this i want to point out something
specific that concerns java applications
in july of 2011 javas 7
was released and java 8 was released in
march of 2014.
given the development going on in
containerization at the same time
it shouldn’t come as a huge surprise
that older versions of java are not
fully container aware
except it is a surprise if you don’t
know this and you wrap your java 8
application
only to suffer from out-of-memory killer
activity
the reason for this is that the
mechanisms the jvm
used in these older versions to retrieve
the resources available
come from the actual host machine and
not the c group limits that you would
expect
although possible with later java 8
updates i believe it’s 121
um is is the best you can get for
java 8. uh it’s recommended to get to
java 11
in order to get that version that is
fully container aware
all right there’s a lot more that
happened during this period of time i’m
intentionally going to skip over some of
those details in order to get to a
specific event in 2015.
this event is really important to know
about because it’ll give you some
insight into some of the activity and
motivations behind shifts
in the market especially concerning
docker on june 22
2015 the establishment of the open
container initiative
oci was announced this is an
organization under the linux foundation
with the goal of creating open standards
for container runtimes and image
specification
docker is a heavy contributor but in
their announcement of this new
organization it was said that over
20 organizations were involved in this
um
i’m would read that list to you
just so that you can fully comprehend
the big how big of a deal
that was these are a lot of companies a
lot of organizations involved
it containerization has evolved to such
an extent that this number of
organizations wanted to work towards
some common ground for the benefit of
all
the oci accomplished some big things
um they had in in june 2015
um you know when they were established
they had the oci runtime specification
the oci image specification the oci
distribution specification
and in july 2017 uh the runtime and the
image specs were released as
version 1.0 on may 4th 2021 the
distribution spec
was released again version 1.0
docker had a lot to do with these
specifications and i’ll talk to you more
about what those contributions were in a
minute
one month after the oci was established
the cloud native computing foundation or
cncf was established
the cncf does a lot there’s a ton of
projects there that are either
incubating or graduated under its
umbrella
there are a few activities there that
you need to know about for
our purposes along with
the developments in the container
ecosystem orchestration was also in
rapid development
orchestration frameworks like kubernetes
took on the responsibilities of the
coordination configuration and
management of containers
in deployment environments kubernetes
version 1.0 was released at the same
time the cncf was announced
kubernetes was contributed by google and
was the first project
that was brought into the cncf right on
the heels of that first release
version 1.5 came out which included the
container runtime
interface the cri and that there’s that
word again
run time so what exactly is the
container runtime interface
that cri is a level of
abstraction that allowed the kubernetes
um kublets to support alternative
low-level container runtimes
um the docker the company also a member
of the cncf
and well on their way to breaking up
that huge tech stack
we know as docker contributed their cra
compatible runtime called container d
container d was developed in order to
integrate run c
into docker version 1.11.
all right congratulations you made it
through that history lesson i know that
was a lot of information and you might
have even more questions now
but you have some description of a lot
of those keywords a lot of the main
projects that you hear about in the
ecosystem
um hopefully you won’t be so bogged down
with all of that
new project information um when you
begin on your
darker journey
[Music]
so docker does all of these things in
this list
and it does it well well enough that its
popularity is unmatched here
note that when you hear of talk of
container run times or
image formats what’s being discussed is
a small piece of that whole package that
entire
tech stack which is described here the
ability to define a container
building an image of a container
managing those images
distributing and sharing those images
creating a container environment and
the concern of launching and actually
running a container on your machine
and then of course managing the life
cycle of those container instances
let’s talk a little bit more about
container run times
this can be really confusing for someone
new to the world of containers
the docker tech stack obviously contains
a lot more than just
the runtime docker did quite a bit of
reorganizing their code base
over the last several years developing
abstractions and pulling out discrete
functionality
one of the results of this effort was a
project called run c
which i mentioned before which was
contributed to the oci
this was the first and for some time the
only
implementation of a low-level container
runtime that implemented the
oci runtime specification there are
other runtimes out there
and as of this writing this is a very
active space so be sure to reference the
current list that is maintained by the
oci
for the most up-to-date information and
i can provide you those links i actually
have some links at the end of this slide
deck that will help you get there
other notable low-level runtime projects
include
crun an implementation in c
that was led by red hat and railcar
an implementation in rust which was led
by oracle
that project is now archived but it’s
interesting
developing a specif a specification
is really challenging and collaboration
on the oci runtime specification
wasn’t any less challenging figuring out
where those boundaries are
what should and what should not be
included in the spec
took some time before the release of
version 1.0
it is very clear however just
implementing that
specification isn’t enough to drive
adoption of an implementation
additional features are needed to make a
low-level runtime usable for developers
since we’re concerned with much more
than just the creation and running of a
container
this leads us to higher level runtimes
like container d
and cryo
these runtimes include solutions for
many of the other concerns around
container orchestration
including image management and
distribution
both of these runtimes implement the cri
which eases that path to a kubernetes
deployment
both of them delegate low-level
container activities
to the oci compliant low-level run times
like run c
that brings me to a point a question
that i get a lot
this here is a link to a really good
blog
in short uh kubernetes is deprecating
the docker runtime
and that caused a lot of panic really
because um
i think most people don’t understand
what that actually means
in short that deprecation of docker
runtime support
does not in any way shape or form mean
that docker is going anywhere
or losing support in other ways you can
still use docker to develop and produce
docker images
and containers as you do now
basically what happened is
docker was originally the docker runtime
was originally
the original implementation of cri
compliance but it was through a specific
uh component called the docker shim
that uh basically kubernetes wanted to
get rid of that
it was it was a customization that
wasn’t necessary for any of the other
runtimes
plus when docker hit version 1.11
they started using container d which is
cri compliant so it really doesn’t make
any sense
for kubernetes to support the entire
docker tech stack
anymore in order to support that docker
runtime
all right we’re getting to the end here
now we get into just some simple
terminology of containers
um what is a container exactly it’s a
it’s a running instance on your machine
what is a container image that’s an
immutable executable binary used to
create a container
this is usually a made up of
made by a docker file which is
a text file that is a set of
instructions that is used to
build that image
an image tag indicates the version of
the image
excuse me a container registry
is a library of container repositories
and images
and the most popular example is docker
hub that is the
um the default
um central storage for docker images
and an image repository that stores all
of the versions and tags of an image
so generally it’s that’s the image name
all right what now you have all of this
information you’ve got some terminology
behind you
now it’s time to just download docker
desktop
um back when i first downloaded
this application excuse me
i’ve got a frog in my throat i work for
jfrog and that’s what happens
anyway um back when i first downloaded
docker desktop
it it was simple it was easy to work
with
but when i look at it today so many
improvements have been made around the
ui
you don’t even have to use command line
commands to
look at your images or look at the info
behind them
any of that you can do that all through
the ui now it’s pretty cool
the documentation at docker.com is
abs it’s very very good um
they have a whole getting started
section which is definitely worth
working through
the um cncf website
is here um you can find a lot of
information about how to get
involved in those organizations it’s
really important
that um companies and organizations get
involved in these
so that we move in the right direction
for future components
on future development around cloud
native technologies
and then of course opencontainers.org
this is where you can find all of the
links
to all of the specifications that i
talked about earlier um
the runtime specification includes a
um a reference to like all of the
current implementations
that are available right now and if you
go there
you can find not only the current
low-level container runtimes
but you can also find as work that’s
being done
in vms as well
all right i am ready for some questions
if you have any i think we have a couple
minutes before we start with our next
speaker
so i don’t know if anything came up i’m
going to take another drink
i was just going to single throat
yeah there’s there’s uh you know we have
frogs but i mean
we never have but you know this is uh
this is taking it to the extreme i love
it
let me ask america would you would you
prefer to um answer some questions to go
on to the youtube channel and take some
questions there in the chat
uh you can drink as much water as you
want
and uh i’m putting in a cough drop right
now
i would like to answer these this
question that’s up here for sure
sure absolutely okay what does it mean
by being applica
by an application being container aware
as is a container is subset os which can
run application in isolation
okay so mainly what i mean is um
for java applications specifically uh
the way the jvm
handled resources for example when you
launch a container
you can tell that container only use
this much of memory on the host
only use this much of processing power
on the host
but for a java application for older
versions
it ignored that it was it wasn’t using
it was getting the wrong number
basically so you could launch a bunch of
containers on an
os and then they could all stomp on each
other because they’re all taking
resources from each other
so that’s what i meant by container
aware
there wasn’t good enough isolation there
thank you that’s awesome also there was
a git repo
you were talking about somebody who
actually wanted to know if you could
share the get repo
uh information a get repo
yeah i think it was near the beginning
of the talk um
maybe you made a reference to one uh
made reference to one
i may have let me go find it um it might
be the open containers
[Music]
you