Applying 12 Factor Principles to Containerized Applications! @ Docker Atlanta Meetup

give you this is your first Docker Meetup Docker Atlanta Meetup okay awesome we only had one since the

pandemic in person and that was back in February so we’re going to work on my name is Ari Waller and

um I happen to be the local doctor organizer for the Meetup um and we’re going to work on getting

one every other month um and we’re really excited about that we have a lot of other events at jfrog

so sometimes I think some of you have come to some of the other events that we have here as well we have some devops oriented meetups too so we have

obviously we have a really great facility for this and uh my job happens to be a portion of it has to be meetups

so um we definitely want to take advantage of that and obviously share with the community as much as possible so welcome

um we started a Docker Atlanta Meetup Channel I mean YouTube channel so if you

have not subscribed yet it’s a small list right now but go ahead feel free to take your QR code and sign up uh we are

going to typically um unless there’s a reason why not uh post uh the videos

um I’ve been asked by a few people are we going to make these hybrid and the answer is no um I believe that hybrid is the cannibal

of the in-person Meetup and um you know I just I I was definitely torn both ways if

there was a way maybe wanting a technologist and I can go into business you ready for this do you know how local football games you know they um they

make the game unavailable to the locals unless it’s sold out well uh if we can

create a program presumed to do that it’s probably something with IP addresses and stuff like that I’d be

happy to let people from other states uh join but not the state of Georgia so if there’s a way to figure that out let’s

talk offline we’ll make a lot of money but other than that we’re going to continue to do it this way so

um but we will eventually and I say eventually I hope to get it up fairly shortly after uh meetups on the channel

we have two of our last videos up there right now for your enjoyment um typically so far what we’ve tried to

do I’m going to try and do this at least for the rest of the year is there’s some amazing people out there that have

earned the um title of Docker captain and I want there to only be one person that um logs

in for these meetings and that is the docker captain and I want to do that consistently through the year so um this

month we are lucky to have Melissa McKay who actually happens to be a J frog employee which is awesome and does hold

the title of Docker captain yeah Docker Captain last time and um next month and next in June I am talking

to the docker Captain um Ajit arena in um in India who runs

the Bangalore uh Meetup very active in the community very active in the docker community in

fact I think he helped some of the standards in place for the captain’s at one point um and uh he’s going to be sharing with

us a brilliant speaker and uh looking looking forward that as well for June so that’s that’s the plan

um also uh we want to hear from you this is uh you know where we want to have both a Docker captain and one of our

local speakers so tonight we have Ray that’s going to be sharing with us um and we would like one of those speakers to be somebody in the community

as well um go to our call for speakers you can always send me a note on LinkedIn too it doesn’t have to be formal but uh do

submit a topic um and uh we’ll take another okay and then we’ll get back to you we’ll definitely get back to you

um but uh we want to hear from you and you don’t have to be an expert to speak have to be the grand Pub of a particular

subject and doctor to do this there’s value to what you do every day obviously

Docker has enough uh components to it that you are probably an expert in something you don’t even know you’re an

expert in just based on what you do so share with your share with your colleagues and it would be really really valuable

uh follow us on Twitter another small following but we you know kicked it all off at once uh Shameless plug for my

amazing son who’s a graphic designer he created the doctor Atlanta logo and uh

yes I did get permission to use it uh by uh by by the community team there because I didn’t want to infringe on any

uh copyright so very proud of my son if you ever need some graphic design work ick designs

um uh also uh so I don’t like to do a ton about jfrog

um so for those of you who don’t know this is where I balance I am the community programs manager for jfrock so

my job at jfrog is I handle Global meetups for jfront the docker is set aside from that I

don’t feel I deal with Meetup organized all across the globe and it’s not fair that I work with them

and for a living but I don’t understand what it’s like to be a meet-up organizer so during the pandemic I was a Meetup

organizer from multiple meetups including go uh San Francisco and go to New York throughout the pandemic but now

that we’re back in person I really wanted to see the docker meet up in Atlanta uh be revived again so it’s

really important so this is um in essence but I do get to where the jfrog hat too because a J frog is a host and I

get the help with the facility so just a couple of words from our sponsor very quickly tonight we are doing a raffle uh

for a Google Nest you may have already signed up for this if you have it’s great we will select the winner at the

end of the evening you must be present to win okay um now we did I have another contest

with jfrog this month now this one’s a little bit different this is a monthly contest and this is a survey so we have

one of the most important things jfrog was founded based on uh the community feedback loop frankly we were an open

source product and we started in 2006 even before we were a company in 2008 and because that connection to the

community is so important for us we do have a survey and um we would love if you are willing of course totally opt in

this is optional of course is to fill out the survey and you will be entered into our monthly contest

um and the first week of May we’re going to be doing the drawing for a Nintendo switch when it will be contacted by

email that week terms and conditions apply they’re there you’ll see them want to um but uh one of the things that also

helps us do just frankly this is a very PBS but uh it allows J rob to continue

funding Community programs like this so it’s helpful when they get that feedback

so contribute if you’d like to and if not just enjoy yourselves it’s no pressure for that tonight

yes there’s the Google Nest one if you want to get that one well oh J5 employees can’t win any of

the reviews so if you’re from James Brockton Kansas um so I have uh I have to work on

getting the jetbrains Ides for this for this Meetup the problem I’ve had and I think you’re all I need your help this

evening before we go into our first talk is I’ve been I’ve been getting jetbrains Ides throughout the pandemic and I have

several from the last three months that I have not given out because I don’t do the go meet up anymore if these I don’t I’m gonna make the

appropriate connections but I don’t want these to go to waste so if I’m going to probably hand something out shortly that

you pass around I know some of you already typed it in but basically I need

um if you want to be entered into a contest for a IDE this evening I have enough to give away how many how many

people would actually get the IDE and activate it tonight if they got it raise

your hands okay I would say that we probably have something for most of you then

um so that’s good and if you don’t have an IDE I definitely have a couple of codes for some doctor swag so way too

much to give away tonight again I don’t want to spend too much time on the giveaways let’s get to the talks but um I’ll probably just um at the end uh

figure out ways to distribute those uh appropriately okay um that being said without any further

reviewing you there Melissa I am here can you hear me okay yeah we can let me

go ahead and unplug from this all right well everyone our first talk is going to be from Melissa McKay I’m

not gonna do her justice with her introduction but I will say one of them uh and I mean

this sincerely I do work with amazing people at jfrog but I have an immense amount of respect and love love love

working with Melissa um and she’s got some really amazing insights and experience that I know uh

she’s gonna share with us tonight so everyone uh J frog developer Advocate and Docker Captain Melissa McKay let’s

welcome her from Denver [Applause]

thank you hey everyone um I can’t hear anyone anymore so I hope

hopefully you can still hear me can you give me a thumbs up all right awesome I’m gonna go ahead and share my screen and get started here

all right um you should be able to see my slides now um we are here for applying at 12 Factor

principles to containerized Applications this is actually draft one of a talk that I’m continuing to build out I’ve

got some ideas for it so I’d love to get your feedback after what more you would like to see

um and especially if you have any questions that you want me to dive into deeper I usually like to do more thought

leadership talks um this one in particular is not so much into implementation details yet it’s more of

the thought around it the reasons why we do the things we do

um but as I get more uh time to speak and use this talk I’d love to expand it into workshops and get into the deep

implementation details because I’m sure that as we go through some of these factors some of these principles you’re

going to be wondering well okay that sounds great but how do I actually do that

so just a little bit of intro and I was there in Atlanta not too long ago I really miss being there with you so I’m

glad to be able to be with you virtually at least this time hopefully we’ll run across run paths you know again in the

future next time I’m in Atlanta but um just a little bit about my background I have been a developer

Advocate now for three years with jfrog um prior to that I was a developer by

all means all the way from intern to principal developer at my previous employer

um during that time I became a speaker I got involved in helping to organize some

unconference events uh these are conferences that are less formal they’re more like

um groups of folks that are in a circle uh very much a smaller audience it’s not

so much one speaker up front talking and you know teaching everyone it’s more of a group effort

um the topics are chosen uh each day depending on who arrives and who has the

expertise very very cool stuff so during that time while I was doing that I

quickly realized that being a speaker and being a full-time developer was pretty difficult we all have obligations

outside of our normal jobs so I decided it was time for me to find a position

where I could do this more full-time so here I am with jfrog um during the

last three years I did become a Java Champion uh Java is my um primary uh career language

um but I’ve never met a Java developer that isn’t into something else these days we all have learned you know a lot

of other uh tips and tricks along the way and a lot of other languages something I’m interested right now in is

rust that’ll be forthcoming um I did become a Docker Champion as a

Docker Captain as well um containers have always intrigued me

mainly because of the reasons why they came about how they came about how we use them now

um so it’s something that I continue to delve into not even not just Docker but all containers in general

um here’s my uh LinkedIn and my Twitter handle if you want to reach out to me you can do that at any time especially

if you want to ask questions or just provide me some feedback

all right so um I’ve been working with containers for a while

um and in my previous uh position as well it was something that was brought

to our team where we you know needed to containerize an existing application

um this was my first time in dealing with containers actually so when I first

took a look at it at the docker file that was exciting for me to you know walk through that and figure out exactly

what’s happening and how this is working um but something I always like to do is

always go back to the original principles for now you can do so much

with just a Docker file and all the commands that are available to you you can do all kinds of things that are not

good for you you can do things that are good for you so uh it’s always a good idea to go back to the beginning figure

out what best practices are without learning too much from trial and error

like I have in the past sometimes that can be fairly painful

I do have some stories I can share about that as we go here

um so I I went out and I went looking for the 12 Factor app this is something that’s been out a long time if you’re

not familiar with the 12 factors um definitely go check it out it is all

available at 12factor.net so take this link down and

go there much of this talk is heavily based on that there is a lot of you know

blogs and stuff out online about this as well but I like to go to the source read

it figure out how it’s applicable to me and then go forward from there but basically the 12 Factor app was

written by Adam Wiggins around 2011. uh he put it out online as an ebook

um he was one of the founders of Heroku and he was interested in how to release

software reliably how to scale it quickly and how to maintain it in a

consistent and predictable manner all of this sounds like heaven to a developer like me so obviously the 12 factors are

something I’m interested in uh this is just a snapshot of his

website this is what he has adamwiggins.com clearly a passionate person I’m interested in making all of

our Lives easier um someone um will do to follow and check out if

you’re not familiar with Adam Wiggins

this slide just comes directly from the 12 Factor app website

um it talks a lot about the methodology um it’s primarily focused on software as

a service app um it talks about using declarative formats for setup automation

um I know for one as a developer I I cannot count how many times as a new

developer on a new project I was always assigned fix the documentation for

setting it up um just and it never worked never worked the first time it was always a struggle

so you’d always Reserve you know maybe two or three days to ramp up on a project make sure you have all of the

dependencies that you need and and make sure you know the documentation is up to date so this whole idea of focusing on

automation around that is huge um definitely works to minimize time and

cost for new Developers it also talks about having a clean contract with underlying operating

systems and it talks about you know portability between systems I remember

one time I was set up on a new project I started to get everything building and

all and I started running through the tests just to make sure that I was a good point in the application

development cycle that I could start working on something new right this is a common thing we do this all day every

day so I started running the tests I get to one group of tests and it fails

immediately and the reason it fails is because of the last person that ran those tests was running on a Windows

machine and they had written a test that was specific to a Windows machine things like file

system stuff and uh I just thought that was really silly so this is something

that pleases me to see that we work more toward and focus on making sure that our

stuff is compatible doesn’t matter what OS you’re running on obviously this is

my love coming from a Java background so look forward to

um we talk about suitability for deployment on Modern Cloud platforms

I love spending more of my time on the development side of things rather than on CIS admin work so something that I

like immediately minimizing the diversions between the different environments

like development and production and enabling continuous deployment

technical oversight committee for um the CDF The Continuous delivery

Foundation um this is something that’s been really interesting to me so we talk a lot about

continuous delivery we have a lot of special interest groups that that come from this Foundation one of them is

interoperability I’m a chair of that group as well these are all you know

groups of people that are interested in making this easier for everyone for Developers for those on the operation

side of things any devops teams this is all a goal of ours to make continuous

delivery the default way of doing things

um scaling up without significant changes to tooling architecture or development practices

you know it’s it’s lovely when you get your service all up and and it works great it passes all the tests and you

deploy it and then the load just killed it uh this is something that obviously if you’re you know for-profit

organization is something that you want to address immediately so being able to scale up being able to offer your

services without interruption to all of your customers something that you know

we always want to improve so all of this sounds good and I’m just

talking about 12 factors I wasn’t talking about containers but this sounds very much like the goals of container

containerization right A lot of these goals are the same it also goes hand in hand with uh you

know microservice methodology a lot of these items here apply to microservices

as well well

um you know Docker introduced The World To The World um as open source that happened in 2013.

so you know a couple years after this 12 Factor app made its first appearance its

first draft out there we did start talking about containers a whole lot more

um now both Docker and containers in general are you know household words but

it has taken us some time to get here and a lot of that really was about

getting more of the tools um ironed out there was a lot of done a

lot of work done in the industry around tooling to make that whole containerization process of SAS apps

more efficient and easier for developers to pick up and do right off the bat

and a huge part of that is due to the development of Frameworks like kubernetes openshift Docker swarm and

and some others out there um but now we’re at a point where most

people I know you know if they haven’t worked with containers they certainly have heard of them and um certainly in

this group here you probably are all working with containers right now so the real question here is why do I

have a picture of bananas on the screen and uh this is just a silly thing for me

I have yet to find a more fun theme for containers than bananas I absolutely

refuse to use the shipping container metaphor um so hopefully you’ll enjoy this make

this a little bit more entertaining for you all right so we’re going to walk through

these 12 um factors with these 12 principles and

just see you know how we feel about them why they’re there what the idea is behind it and maybe how it applies to

containers um I’m by no means a banana expert but

just a little bit of research um came up with this bit of trivia might be useful to you someday who knows but

the commercial version of the banana that we see today is the Cavendish variety and these plants

um they actually are genetically identical clones they do not grow from

seeds and because of the years of cross breeding and stuff any seeds that you might see when you bite into one of

these bananas they’re just vestigial if you actually go out and try to plant them they’re not going to grow into a

banana plant unfortunately and this picture here is of a rhizome or

a bulb that can be taken from one plant and then transplanted and it will also

eventually produce more bulbs and then that process is repeated and now whether that’s a good way to maintain our

commercial supply of bananas uh that’s Up For Debate but um why do what does

this have to do with this first principle and uh I ask that you stretch your brain a little bit to really get

the metaphor here but the idea is that no matter how many deploys that you have your app should come from a single

source the code base should be the same across all of the deploys all through

the different versions that maybe deploy and um you may have different maybe some

commits that aren’t yet into um staging or into production but they

all come from the same code base so you can you know identify them as different deploys of your same app

and that is directly from the 12 Factor information

foreign T being the case I always feel bad for

picking on this particular project because I use it a lot for especially in workshops or um just to show as an

example it’s actually a really good example but there are some things in here that are intended specifically for

demo purposes not for production purposes so although I pick on this I’m

counting on the fact that we all know this is not an application that’s meant

for production um it’s here for us to play with and work with and learn how to do things

this is from a GitHub repo It’s called Spring Clinic Cloud it came originally

from a microservices version of this pet clinic application it’s it’s basically

like just an application that you could use if you were a veterinarian for example uh checks in you know people’s

pets and Records who the owner is and things like that anyway

um there’s lots of different differences in here but they’re all

uh actually different services that probably should be in their own repos

these are all in their own uh in directory but all within uh the same

repo and in the 12 factors uh uh it explains that if if

this is actually would be a distributed system and each of these components

should is an app and each can individually follow the 12 Factor

methodologies um so this right here is actually a

violation of 12 Factor uh which if there’s any code that’s shared that should also be uh put into a library

which can be included using a dependency manager of some sort um so yeah having it all here in the

same repo isn’t exactly how things should be done in this particular app if you wanted to go check it out each one

of these Services when you build it results in its own individual container here

all right number two and uh I’m gonna focus on this one pretty heavily because dependencies are

my thing um but uh and I certainly won’t spend as much time on the rest of the factor so

don’t be afraid I know we spent a lot of time on just the first and second one here um but we don’t talk about dependencies

enough so I’m going to spend a little bit more time here um directly from the 12 Factor app a 12

Factor app never relies on implicit existence of system-wide packages

this means you can’t ever take for granted that if you run curl that it’s

going to be there unless you explicitly put it there so this is something that applies to a

12 Factor app but certainly applies to Containers right you can actually make their life a little bit easier because

it gives us an environment that forces us to make sure that everything we need is in there

it has gotten um difficult um because now we not only have the

application that we’re worried about as a developer but now we have the packaging of the application and

everything that’s around the application um so we’re we’re talking about the OS

tools where you know OS packages things that are that come in that are separate

from the actual uh Java application or or JavaScript application or you know

whichever um so

the 12 Factor app really encourages um developers to use package manager for

their apps and then we also need to just pay attention to where everything is coming from and if we walk through the

development process by itself we start out with our developer this developer

chooses a language and framework let’s say he’s very wise and old and he

chooses Java and he’s going to need a package manager so this developer might

choose Maven and lists all of these dependencies in a pom file then when

they build the project locally this package manager assists by reaching out

to a global Central repository in this case it’s going to be Maven Central and

pulls in everything that you need the problem here is transitive

dependencies these are dependencies of dependencies so even though I may have

done the work of explicitly declaring the dependencies that I want in my

application that I’m using directly those dependencies may have dependencies of their own so we

need to pay attention to that make sure that we have a good accounting of everything

that our project relies on obviously developers do not want to

reinvent the wheel um this is an overused graphic really but this concept is real

um software is potentially made up of a ton of components that a developer doesn’t may not have firsthand knowledge

of these applications and services that we have today are more complex than ever

and developers generally you know we don’t want to repeat we don’t want to rewrite stuff that’s already out there

so we continuously bring stuff in unfortunately this becomes even more

difficult when we bring in build servers and they’re meant to be tools to

automate this process make everything easier for us but they behave the same way unless you configure it differently

you’re going to have a build process that reaches out to Maven Central

and then pulls all of your dependencies in um this is the time when you need to

consider some kind of artifact management system Shameless plug for

artifactory really excellent at this um but whatever you use it’s got to be a

better use um then constantly reaching out to Central

repos now you may have multiple setups in your

build process and one of these steps could be actually the job of packaging your application into a container and

once again by default you’re going to be reaching out to Docker Hub the central

repo for a lot of containers bringing stuff in to your build processes and

using it so you at this point you would really need to consider making sure that you have you know some

kind of caching mechanism or some kind of artifact and image

management system where you can pull these in and store them without constantly reaching out to these

external services for this even more complicated all of these steps

and and jobs will be running any containers themselves and these could be

managed by you know some kind of build a platform out there where they’ve decided for you what container you’re going to

be building and all of these things you need to pay attention to when you’re um

you know considering how your project is built uh really making sure that you’re taking a you know having a good

accounting of everything that’s involved in your process and making sure that you mitigate a lot of maybe

third-party pain especially when maybe one of these third-party services become

unavailable for a limited amount of time or maybe forever if something is deleted

or moved that you need for your build

I like looking at real examples um this is a very very derived Docker

file here but the interesting parts that I want to focus on are highlighted uh we talked you know about application

dependencies and stuff now that we’re packaging them in containers we’ve got some other dependencies that we need to

be concerned with uh you can see that you know there’s some packages here that are being installed

um on this image that need to be available for our application for whatever reason

and the one on the left does not explicitly Define the versions of these

applications um that isn’t horrible in and of itself it’s just that now you have a build

that’s pretty uh unreproducible um it’s going to take some homework you

know to get in there and figure out what versions is actually being used you can cause yourself some troubleshooting

problem especially the next time you need to rebuild this image and all of a sudden it doesn’t work and

it brought in a later version of a package than you had before it’s not even your app it’s something else in the

system so do yourself a favor and explicitly Define the versions that you want to

bring in of everything that you need

um the one on the right you know obviously put in some versions um but there’s a couple of other questions you

should be asking right away that Top Line we are starting with a base image sure we’re declaring the version but

where is the space image coming from do we have it stored do you know how it that one is built when it comes time to

update it are you going to be able to these are things you need to know about your own project and how it’s built

and then this line obviously like I said this is derived um this isn’t a real application it doesn’t even have like a

language you can’t even tell but [Music] you would want to know if you’re just

copying an app what version of the app is this where is it coming from you know is it is it just the latest

version that was built is it the latest that has passed tests is it the latest that’s past integration tests so that

it’s you know able to go into production without a worry these are things you

need to consider when you’re writing your Docker file

all right moving on like I said we’ll go through the rest of these much faster so number three involves config

um lots of times um config could be stored you know as

constants um basically don’t do use environment

variables that’s what the 12 Factor um

what that says is to use environment variables there’s lots of different ways to do this but one one thing that the

principle says and this is directly from the text a litmus test for whether an

app has all config correctly factored out of the code is whether the code base could be made open source at any moment

without compromising any credentials so now we have it now we have the why we

need to worry about this we don’t want our credentials being stored in places they shouldn’t this is something I

struggled a lot with a lot of java applications because we did have you know this idea that we want to be able

to run our application in different environments without having to uh

rebuild the whole thing and no it first started out with believe in profiles we were able to build you

know like a profile that was intended for development or a profile that was intended for production but the problem

with doing it that way is that in order to release you had to rebuild to release

well whenever you’re involved in rebuilding your application you kind of

defeat the purpose of going through all the testing of the original artifact so that was never really a good way to

do things so I really appreciated when um spring came onto the scene and they had

spring profiles these were profiles where you could actually just through an environment

variable affect how the app would run like which configuration it would use uh

things like so the things you want to include in your config are you know any

backing services like database credentials things like that

um also you need to be careful about how you inject variables like that into the

docker container because passing those values directly via the command line is

is not very secure um you could you could accidentally

um put stuff like that into Source control um and also when those containers run when

you pass it in that way if you do an inspect on the container if you have access to be able to do that you can

actually see the values so potentially you could have you know maybe you want

to limit your developers from knowing you know production passwords that’s not really a trust thing so much as a don’t

do something stupid by accident thing I’ve had some painful uh experiences in

that world I do not want to have access to things that um I’m really I really

shouldn’t have that includes production resources like that um so in those cases you really should

be using something like a Secrets manager this is you know something like hashicorp vaults AWS has a Secrets

manager there’s a Google Cloud Key Management Service there’s all kinds of stuff that you can do so you don’t know

what you don’t know um meaning that sometimes you feel the pain before you realize this is an issue

prevention and go ahead and um make sure that you’re dealing with your

config appropriately

okay look at this this is a good

um this a backing service is really uh any

service that the app needs as part of its normal operation that includes databases that includes any messaging

systems like Robin and queue um that includes you know maybe services

for mail SMTP Services maybe caching systems uh things like that

these um really and uh and from the 12 Factor app

the code should make no distinction between local and third-party services

so any of these resources should be considered just attached resources they can be accessed via a URL or credentials

that are located in the configuration you should be able the goal is here is

to be able to swap any of those things out without having to rebuild the app and in this case that makes sense for a

container we don’t want to have to rebuild um an image and launch a container just to

be able to swap out something like this

all right number five build release run strictly separate build and run stages

now just for fun I put a YouTube link here that’s to a video of how bananas

are actually sent through a processing plant I learned more about how bonanas are processed than I ever needed to know

but I thought it would be fun to include um this picture is also of banana processing plant I mean if you can

imagine they need to be grown they need to be harvested they need to be washed and then they need to be shipped

everywhere so yeah it’s all very interesting um our software needs to have different

stages like this too from you know development in the beginning all the way to actual deployment and the most

important stages are the three that are defined in the 12 Factor app that’s the build stage the release stage and the

Run stage every release should have a unique ID

in Java this was for our jars it was you know we always had like a time stamp attached to the end

um or you can have you know some increasing version number these are you know the tags for images are often set

up this way releases cannot be changed after they’ve

been created so once you’ve developed and you’ve

built that build should be immutable um other than you know environment

specific things that are run by you know config that we talked about you should never be rebuilding your artifact when

you move between different environments or when you go to release and then of

course when you go to run your application so that’s the rule here for your images

same thing you should never be rebuilding your images it should be built in the beginning this

you know may be triggered by a commit to a repo developer makes some changes makes a Commit This goes through the

build process the build uh goes through and assigns a version

number to that particular artifact now that artifact is ready to be promoted through the rest of the life cycle until

it potentially actually gets released to production

number six processes 12 Factor processes are stateless and

share nothing any data that needs to persist must be stored in a stateful backing service typically a database

that’s a quote from the 12 Factor app uh one thing that they do here is they

call out sticky sessions specifically and I have to laugh because I do remember an application I worked on a

long time ago where we it wasn’t a computerized application initially but we were working toward that end and we

didn’t deal with this problem until much later um but we already had it up in

containers and we absolutely did use sticky sessions for a while so uh this

is definitely something that needs to be fixed your apps should not have state

within them um for the simple reason is because they’re ephemeral containers are

ephemeral they can leave at any time they can be shut down at any time

um so if you really need to rely or use session State data or anything like that

you need to bring in something like memcache or redis something that is more

appropriate to handle that type of data I certainly don’t be handling it with your container

number seven Port binding it’s pretty simple to me I mean it was one of the first things I learned when um building

my first containers and being able to assign a port and then just being able to access it directly on my local

machine was pretty awesome um I know an app that I containerized

you know previously involves um injecting a web server into the

execution environment and in this case now that we have containers

um we actually you know use a dependency to add the web server

library to the app itself so we we have it available to us it’s not something

that happens later really

nice for me because I do remember being in a situation where I was working on an application that was

uh delivered to a client who then set it up and used it so just to clarify I was

working on a Java app and I delivered to them the Java app the Java web app and

then they would do all of this stuff you know to get it up and running and and get the web server set up and stuff like

that we at that time did not have very good communication about what web server they were using what version they were

using all kinds of stuff so in our own internal testing we discovered some pretty severe issues with that uh

consider concerning certain versions of Tomcat and uh some things just did not work quite right so that was something

that we had to go through painfully so this is a much nicer to have a

dependency like that to be included with the application

number eight concurrency in the 12 Factor app processes are a

first class citizen this is nice for containers especially I

mean this allows us to scale out horizontally much easier and a good

example of doing this too and being able to handle work like this is using The

Good Old Pub sub architecture so you have you know you consume uh requests

you might put those requests on a queue maybe that’s handled you know by a

broker of some kind you can then collect maybe you have workers that get spun up

and they collect work from that queue and you’re able to scale better that way

so this fits right into how we deal with containers and how we you know logically

divide this is to make sure that we can scale really

number nine disposability the 12 Factor apps processes are

disposable meaning they can be started or stopped at a moment’s notice this goes right along with you know a good

reason why you don’t handle state in your containers um you need to be able to do this you

need to be able to scale but not only just scale up but scale down this means you know you’re able to take advantage

of some cost savings and resource savings when your load isn’t as high so now we have you know automatic scaling

capabilities that Frameworks like kubernetes offer us and we need to be

able to shut down these Services gracefully meaning they really need to

respond to a Sig term signal so this is something that you need to make sure works with your container before

releasing um and then you know in order to be able to scale up

you need to be able to minimize your startup time as well um also

make sure that you implement you know liveliness and Readiness probes so that

you can you know your internal systems can be more aware whether or not a container is actually ready to start

receiving requests uh things like that and most of us are not going to be

perfect with this right out of the gate I know my team several years ago wasn’t

um we had containers uh that were continuously restarting and

unfortunately we did not have the best communication with our operations team at the time so their solution was just

oh well if it crashes just get just restart it well the result of that since I already confessed to you that we were

handling some State the result of that was that we would often lose you know parts of jobs

um things like that would go on so if make sure that you have that

communication monitor when your services are going down and make sure that you understand why is it a scaling action or

is there actually a bug in your system that you need to consider getting fixed quickly

so make sure uh you know any Behavior like that is noted and communicated to

your devs in the right way

all right number 10 Dev prod parody keep development staging and production as

similar as possible um I had already told you my story about

how you know we were developing an app and delivering it and they were using completely different tools to deploy

than what we were internally um in fact it’s just you know sets you up

for some problems that you could avoid it would be wonderful to be able to uh tell you know your client you know if

you use this particular version Be watchful for such and such and be prepared for such and such

um you know being able to keep all of these environments as similar as possible is a very good idea and

containers fit right in here too they allow us to be able to run you know

pretty much the same application in development as in staging as in production the tempting thing here is to

use different backing services so that’s something to be aware of as

well um not a good idea to use a different database

or a different broker you know there’s all kinds of things that you don’t anticipate when you start switching

those kinds of things around and always good to catch problems earlier rather

than in production when everything is different so good idea to keep all these the same

obviously this fits right into containers it keeps all of our you know everything around the container

and the app the same pretty nice

logs it has been years since I’ve had to configure logs so when I took a look at

this one there I have a lot of unanswered questions here um so there’s a lot of experimentation I

want to do I remember being in a situation where

we had some containers running we had logs but we were doing stupid things like

um you know our application inside the container was logging to the file well that file lives inside the container it

wasn’t you know mounted anywhere it wasn’t like an external file or anything so you know you can predict what happens

there anytime that container dies those logs are gone

so a 12 Factor app um not even just a container but any 12

Factor app you need to make sure that you’re handling logs appropriately

um it should the app itself should not be concerned with writing or managing log

files it’s one of the stipulations of the principle each should write to the event stream to

standard out and uh if you want to handle those logs

in some way if you want to ship those logs somewhere that’s up to you to do that you might want to use something

external to do that you can use you know log routers like

fluent D huge good idea for that you can also you know take all of these

logs send them out to something like Splunk so that you can start doing some analysis things like that but just you

know be aware by default Docker you know it will log to standard out and standard

error but if you’ve got applications inside the container doing their own thing make sure that you are aware of

that oh another thing that happened to us and obviously we figured this out before it went to production but you

know um a lot of those logs were there was a lot of logs and when you have a

little container and you might deploy several containers on a single VM you’re going to quickly run out of space so we

learned uh quickly that we need to make sure that our logs don’t live within the container

and the last one here admin processes run admin management tasks as one-off

processes the examples of these are running database migrations or running a

console um to kind of you know maybe inspect the

app with real data for example um and or any other one-time scripts

that you might need to run occasionally all of these things need to be included

with the app so those one-time scripts need to be committed into the repo just like everything else when you run any of

these processes they should be with the same environment the same dependencies everything else around it should be the

same as the app itself so with containers this is nice because

you can actually just maybe spin up another container and then be able to do these one-off processes uh that way you

know you have the same release you’ve got scripts that are compatible

um this is you know a good idea with containers um

kubernetes has operators um this is another way that you might be

able to do stuff like repair tasks or maybe a database schema setup uh things

like that um you might be able to use you know other Frameworks too to help with this

so that’s it um you know this overview of 12 factors you know are is this good should are

they applicable container two containers I think absolutely uh it seems like it fits very well with containerization a

lot of the same goals and outcomes um so yeah

thanks very much um if you have any Docker files lying around I guess your task now is to go

and walk through them and see if your images and your containers are actually following these guidelines and what I

would love to hear from you is if you find any reasons or exceptions to the

rule why you would not follow a principle the way it stated in your

application how you have it built and packaged

thank you very much

well due to time I’m going to allow for one pressing question for Melissa Melissa can you hear us okay

yes okay great one question anybody have one question that you can’t go to sleep tonight unless you get the answer

okay well I know Melissa’s exceptionally he’s up you got one question okay okay all right let’s not go to

exchange go ahead one question um yeah so uh uh regarding the um the

factor about a singular code base uh there is a concept of model repos um now that you’re confused with

monoliths right and they’re pros and cons the trade-offs to having a mono repo versus having my multiple repos

um I think of cicd and having like pipelines that are um reusable across multiple applications

or Services um I’m curious what your thoughts are there in terms of like violating that rule for like a month repo

I get into this argument frequently about Mono repos

um I I don’t like them but I mean it’s mainly for personal reasons but there’s there’s some reasons I don’t like them

is um for one when you have a code base set up like that it kind of implies one of the

big advantages is if it’s all written in the same language um yeah that’s great uh that way you can

bring it all in you can bring it all into your IDE if you make a change somewhere you can address you know any

complications or considerations you know anywhere else in that huge code base but

I feel like if you’re already there doing that maybe they’re not logically separated enough anyway I mean if you

have enough code that’s being shared between those Services maybe there’s some other issues in the structure that

need to be dealt with if they can’t be cleanly separated out into another repo

there might be some other things to worry about um ideally I would like to be able to

see like different teams be able to handle different components and have

their own release cycle their own pipelines that they’re concerned with maybe they can reuse templates of

pipelines but maybe their release cycle is different than other components in the system

um also you know every time you check that code base out I don’t know you know you just gotta

hack away at it to figure out how to only pull in what you need and not build the entire thing every time right and

then also tracking your releases making sure that you know if every commit actually triggers a build does that mean

that everything needs to be re-released or just the code that was changed in the

component that was changed so yeah lots of issues to think about

thank you so much Melissa really appreciate it