[Autogenerated] alright, I've saved the best for last updating.
I debated when I would cover this because we have all these
installed scenarios that we went through in this course.
And the fact is,
the the update strategy that you take is dependent on which of
those approaches you take to installing software.
So the install dictates the updates.
So we kind of had to wait to the end because this is largely a
course about installing and configuring and getting your Docker
engine up and running in a Linux environment.
And so, naturally,
the path that you take to install and configure will dictate the path you
take to update that installation and configuration.
For example, if you start out with Santos and the young package manager,
that's what you'll be using for your update process.
If, however you install on a bunch you're Debian or something similar,
you'll be using the app package manager Most likely.
Now that might seem a little bit hyperbolic,
but more specifically there are choices within some of
these environments that are different.
For example, you could use the Docker snap versus the app package.
These are two different roads to go and they probably
would entail different update processes,
and not that At some point in time, you couldn't change which you're using.
In fact, that's probably one of the strong suits of container.
Ization is the ability to lift and shift.
You can literally pick your containers up,
move them to another environment,
and they should operate exactly as they were operating before.
It's the underlying infrastructure that might be different.
And, of course, that might, until some concerns about storage of data.
I'm also hoping that by the time you get to the end that
whatever release you started with that,
there's a least a point update out so you can try out the process of updating,
even if there's nothing breaking or major about it,
just in the spending.
Making this course I know 2010 came out with 20100.1 and got to say,
I'm hoping the same for you.
Don't take a moment and look at the binary installation route
because this highlights a symmetric property.
Voters at a moment ago, I said, How you update depends on how you install Well,
how you install might also depend on how you want to update.
Take the static builds of Docker.
They are wonderful when you don't have a supported package
manager or supported distribution of Linux.
And you just want to get Docker up and running
really good for a test environment, for example,
maybe even great in a supportive environment just to
simplify the installation for testing purposes.
But then the reality creeps in.
As you add, more components is have done in this course configuration files,
maybe system the unit files or some other service managers.
Perhaps you have some client configuration files,
all those bits and pieces that don't come with the binary distribution.
Let's look at that real quick.
So this is the binaries distribution again.
It just has the compressed tar archive that we downloaded
and then extract into this Docker folder,
and then I literally copied these into the path.
So in my case, because of how I approach this,
I probably should have kept track of what I copied into the path.
Maybe I should have linked it,
and instead or use some sort of tool that could keep track of
the state of the system before and after changes so that when
the next release comes out,
I might be aware that one of these pieces is no longer here.
Or maybe it's been blown apart into separate pieces,
and the old version can't be lingering.
So the static binaries approach this is a more manual approached updating
where you really have to know what you're doing because,
for example, you don't wanna lose any configuration follows you set up.
But where you keep track of those that perhaps you're using
Ansel like we did in that example earlier in the course for
configuration management.
Perhaps not.
Perhaps you're copying files out by hand.
So in this case, the static builds approach,
while tantalizing perhaps, for testing for quick,
rapid,
throwaway environments really doesn't seem so
exciting for a production environment.
And so that's why I think the update process can have a
significant impact on how you want to install Docker.
But don't forget we're talking about the underlying infrastructure here.
If your application what runs on top of this is a container,
that's a standard that should operate just fine,
no matter what the underlying infrastructure is.
And at the end of the day, you can lift and shift those things pretty easily,
and what I mean by that with rows to updates,
is that Let's say you went the binaries approach,
but you don't like the update stories, so you go to a package approach.
So create that new environment,
move your containers over and throw away the old one in a clustered environment.
Quite often, that is the update story.
You drain a note of all of its resource is containers,
volumes, etcetera, perform maintenance, for example,
updating and then you throw it away.
If that doesn't work,
or you bring it back online and your orchestrator will move containers and resource is back to that machine.