>> You know there's a lot of debate around how to
best tag and version your Docker images,
with one side favoring stable tags and
the other claiming that unique tags are the way to go.
Steve is here to explain the advantages of both sides,
spoiler alert both are right.
It depends on what type of images that you're building,
but we'll try to clear it up today on Azure Friday.
[MUSIC]
>> Hey friends, I'm Scott Hanselman,
and and it's another episode of Azure Friday.
Here's Steve Lasker and we're talking about
Docker Containers and the right ways to do things,
because you know I will always do it wrong
and then I will call you and you will
explain it to me how to do it right.
>> We'll figure out what we missed to fix it the next time.
>> We'll fix it together.
>> Yes. So, this one's an interesting one.
What's the best practice on something still evolving?
So, in this case is really kind of based on working ourselves,
and also seeing a lot of customers call us in ECR or with
a bunch of complaints and help us have us track it down,
and it turns out a lot of them are they wound
up having inconsistent images deployed.
It really kind of came down to,
what is their tagging strategy?
Do you tag with
a stable tag using semantic versioning kind of thing?
Or unique tags, which you can also argue semantic versioning?
Or do I skip all that and use the digest,
so they're pinned to a very exact word?
So, we'll kind of pull that
apart and figure out where to use each.
>> Well, I'm just from anecdotes as evidence.
In nearly every issue that I've ever had with
Docker has been my use of tags in
some inappropriate way or my misunderstanding of how
a tag was used in an upstream thing.
So, for a while the.net team had tags a certain
way and I would go and say ASP.NET Core SDK bill,
but I never said the version so it wasn't explicit.
So, Monday my build works and Tuesday at
brakes and I shake my fist at them,
but it was me because I never really asked for
a bill that I wanted explicitly.
Then other issues whether it was when I was using latest locally,
got confused and didn't think about and then I ended up just
torching my entire Docker images cash and building again.
>> Yeah, and it gets even more confusing when you are local to
know whether using a local one or the reverse upstream one.
So, in this case what we wanted to do is
just kind of use an example of some unique and stable tags.
Actually, the best way for me to
show this is some slides and then I'll do a demo.
>> Okay.
>> So here, we have
three containers that I'm
building for this little app that Glenn and I,
did for the build event last year.
We're doing the Docker builds and we do Bach Docker pushes.
If we look closely,
you'll notice that web:1.
So, we have the image and the tag.
>> Okay.
>> But it actually points to a digest that's actually
the unique identifier for
that manifest that represents those images.
>> Okay.
>> Well, that's just important to keep in mind here,
so we'll hold onto that for a second.
>> Is this like labels and SHA-1 Hashes in a Gitway?
>> Yeah. Actually, it would be a good example of that,
because you can have multiple label
or same labeled pointing to different.
>> Can I move that image tag to a different Digest?
>> Hold that point.
>> All right.
>> So, I'm going to deploy based on the tag.
In this case, I want three copies of web and
quotes and four copies of the important thing that we'll deploy.
>> Okay.
>> The orchestrator and I actually made this more generic,
not trying to be Kubernetes or anything-
>> I appreciate the effort made an animations by the way, kudos.
>> I'm a visual person and that's the way I think.
>> [inaudible] absolutely helped me understand.
>> So, anyway so that thing's deployed and
Kubernetes or the orchestrator in this case said.
"I'm going to distribute these and
keep them running and life's good."
Its going to keep on running,
because it stores it in its little db there, that says.
"I need to keep these things running, that's its job."
So, now somebody else is working and
they're doing builds and they didn't bother changing the tech.
So, they did a build of some random change that they
made and it went into the registry with one.
>> Okay.
>> This could be intentional or accidental, doesn't really matter.
But notice now to your point,
those tags, the quotes one and important one,
are pointing at different digests now.
>> I see where this is going to go sour.
>> Yeah.
So, here now what we're going to do,
we're going to kind of get rid of one of those nodes,
and the orchestrator is going to go.
"My job is to keep so many copies of these things running.
I'm going to redeploy using
the tag that I was told and host digest running."
>> Now, as you've guest,
you now have this inconsistency here that you have the same web:1
and quotes an important one
running but there are different versions.
>> Which is exactly the thing that they promised
me orchestration and containers,
we're not going to cause.
The whole point was magic.
>> Well. So, this is what I love as with all of these,
you got to be careful, because a hammer can be really good
until you smash your thumb, and you blame the hammer.
So, the orchestrator was doing its job.
That's the thing here is the orchestrator,
and this is what I love around this
whole infrastructure of containers,
is orchestrators are finally taking
the fact that hardware will fail as a premise.
>> Right.
>> So, its job is to run it again.
So, how do we get out of all of this?
Here's will take this example.
So, I actually have the site running here,
and you can see that there are two containers running on.
>> You're hitting "Refresh" with your hotkey here,
and I see the hostname swapping between two. All right.
>> We come over.
>> That's really somewhere.
>> We look at our deployments.
We'll notice that we have for "Helloworld,"
we have two containers running.
>> Make sense.
>> Pods of course we'll see two and
we'll now quickly fix and break this.
>> All right.
>> So, we're going to come over here,
and we're going to say instead of grabbing
the color from the environment variable,
because that was really risky,
we're just going to hard-code it.
We're going to say. "We'll use purple again,"
because that was pretty obvious that stood out in that other one.
So, now, if I come over here
and we see az acr build.
>> What are you building in?
>> So, we going to build it, and we have our tag,
in fact this case we don't,
actually, I'm sorry I have to take that back.
What I want to do here is use the exact tag.
So, let me clean this up a little bit.
>> So, you're going to put a new purple build at
the tag that is already being used by [inaudible] ?
>> Exactly. So, let's come over here, and we'll look at our part.
>> Get only the best of intentions.
>> What could go wrong? So, we'll come over here and we've got.
>> AAHM.
>> Right. So, HM and dot.
So, new code reused tag.
So, I like stable tags.
Right. I'm not actually changing my deployment per se,
I'm doing this little minor bug fix.
I shouldn't have to rev the whole system.
Well, we'll see what happens here.
So, we'll build that,
and we you actually have to give this a second,
because what I want to do is go and kill off one of those nodes.
When you kill a node,
just like we did the animation,
what's it going to do?
It's got to go back and pull another image because
the cluster itself doesn't actually keep images, right?
The cluster says. "My job is to pull images,
and it goes and deploys them."
So, we're almost done there.
>> Okay. So, in this case the orchestrator is doing
what it should be doing and I'm starting to
realize what best practice must be,
because you've changed something that was
pointed to you by something like you de-reference the pointer.
>> Right. Exactly. So, that's why it's really important to
understand this is why I feel more comfortable in this one.
Since we've been doing this since we
posted the blog post on the whole thing,
we've actually had a lot of reduction in cost.
>> This isn't an Azure specific thing,
this is just a Containers as we as
a community start to understand better.
>> Exactly.
>> The role of the orchestrator,
the role of the Container Registry.
>> So, if we look,
we should have, here we go here's the pods.
So, we've got a couple of pods running here.
Actually, what I'll do, I'll go back to our deployments.
We're just going to scale, it will just scale will
actually do the nice thing. We're not going to kick [inaudible].
>> Rather than hurting one of them on purpose,
you're going to add another and that
new one will be pulling from a new location.
>> Because nobody should have a failure
anyway, so I wouldn't matter.
>> So, now we've got the third one coming in,
and if we refresh this.
>> Okay. It's not going to work because
our connection died. Hold on.
Let's free them. So, no problem,
we'll just re-establish the SSH connection, but.
>> I see, the tunnel that you were using,
your Local Host Kubernetes is
a tunnel off to the Kubernetes and the cloud.
>> Notice it says 127 up here.
>> There you go.
>> So, we'll come over here,
there's our two "helloworlds."
Actually, because it misbehaved I am going to
kill one and wish you didn't have.
But notice, it's doing its job and he's hurt.
>> It is told one while another one's coming in and so we've got
a failure and a scale out simultaneous?
>> I will didn't get the.
>> Actually look like they might have gotten
>> No, that's the third one trying and it's going to.
>> Three and a two.
>> I don't know we'll see.
>> Yeah we'll get something
>> Either way, as we come here, we will see this.
So, I'm just refreshing and here's.
>> This is just purple but it could be a tax thing or
a number thing or some fundamental business logic,
and this is why sometimes we
get DVDs at a discount so that we don't
because somebody rolled it out wrong in the product catalog.
>> So, that right there is really the crux of
the thing and if we come back here,
what we want to be able to do
is just recap on our tagging techniques.
>> Okay.
>> So, stable tags. Perfect, right?
If you look at my base image over here on the Docker file,
you'll notice that I've got base image node nine.
So, when I want to bind to nine versus 10,
11 or seven or whatever.
When the community ships
an update to node nine I want to get that.
>> Like a fix a non-breakin chain.
>> A non-breakin OS patch.
>> All right. Security.
>> One time patch, some kind of security
that should not change the behavior.
>> Revision rather than a version.
>> So, that's where stable tags are perfect.
Right. I want to have my from statements on
stable tags because I want to get those OS and framework patching.
>> Yeah.
>> When I'm deploying,
I always wanted to pull unique tags.
So, stable tags the way you can manage those is let's say
that some framework has shipping you know 1,0 and that's fine,
it points the latest and one will point to that.
You'll notice that I could also have additional tax.
So, what I'm saying here is
one actually points at 1.2 at this point.
>> Right.
>> Latest, in this case it's always rolling forward as well.
Here, I actually want to have a 2.0.
So, now I can have a stable one that actually points
to 1.2 and two is a new band.
So, two points to 2.0.
>> So, you're recommending both a major and minor tag
to be explicit and then allow the floating of those?
>> That's kind of the subtlety,
this is where I'm kind of leaving it because the people that are
doing this kind of tagging should be the framework providers.
Whether it's somebody at a company building a framework
or us building one's and shipping them.
So, you can kind of see that you really
can get both going on there.
>> Okay.
>> Serviceable tags are also that kind of model,
if we notice we're moving the tag forward including 1.1.
>> Right.
>> Here we're saying 1.1 has
an OS patch or a framework patch or something upstream.
So, we actually even moved 1.1 forward.
So, that's all what I'm trying to show here is,
you can still use these moving forward.
That's not the whole idea because each one of these are going to
trigger or should be triggering downstream teams that were then [inaudible]
>> How would I prevent the purple issue that we just
saw happen I went to prevent that by
by a not reusing a tag during a push?
>> So, that's this one, so
this one the top one is are the Framework teams.
Here, every tags something new.
Right. So, that's what we want to do deployments
and just as a summary there the base images for from statements,
you stable tags and deployed images I want to use
run and Coulomb update and so forth.
So, I'm hearing I need to be
conscious about my underlying frameworks,
what's going to be stable realized
that what I say explicitly as what's going to happen.
>> Exactly.
>> So, be conscious.
>> You don't want to use latest on anything other than a demo,
because that's always going to be floating and
that's not necessarily stable.
Stable tag is more of the 1.0,
2.0, those kind of things.
But if you also noticed in the service of all tags,
if I bound to the digest which is totally valid from a technology.
If I'm bound to 91 EF J6,
when that framework or OS ships and update I'm not getting it.
>> It's going to happen and I'll never know.
>> You'll never know when somebody's
going to figure it out and now
your exploited and the world ends as we know it.
Here's just a bunch of Info,
check out more things on and I hope people [inaudible]
>> Fantastic, I appreciate you
putting together this resource because I
feel like with a combination of hard work and animations,
as well as a very visceral demo that shows that this
can easily happen in production if you're just not thinking.
>> Exactly.
>> Reminds me that computers do exactly what you tell them to do.
>> Yeah. Exactly.
>> I am learning all about best practices and
Docker tagging and my images here on Azure Friday.
[MUSIC]