Docker is one of the core elements of developing Python applications in consistent ways, as well as running them across different hardware universally.
On this episode, you'll meet Peter McKee from Docker.
He's here to catch us up on what's happening in the Docker universe for Python developers.
This is Talk Python to Me, episode 308, recorded March 9th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy, and keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Datadog and us over at Talk Python Training.
Please check out what we're offering during our segments.
It really helps support the show.
A little bit of news.
We just released not one, but two new courses, and more are just around the corner.
You might remember my interview with Sebastian Vipovsky over on episode 279,
where we discussed the modern Python developers toolkit.
Since then, he and I have teamed up to bring you this whole idea of modern tools
applied to well-structured Python projects as a course.
And we just released it.
It's called Modern Python Projects.
You can find it over at talkpython.fm/modern dash python dash projects,
or you'll find the link in the show notes.
If you like the idea of a total tool chain makeover for how you're building your Python projects and applications,
be sure to drop by the course page and watch the overview video to see if it's right for you.
I'm sure everyone will learn something interesting in this course.
There's so many cool things in here, no matter your experience level.
Another new course we just launched is full web apps with FastAPI.
FastAPI is definitely the framework with the most energy lately.
But if you build your APIs with FastAPI, well, you need another framework for your HTML user interaction side.
In other words, could you replace Flask or Django with FastAPI?
The answer is yes.
And this course is your guide to doing so.
Check it out at talkpython.fm/fastapi dash web.
Link in the show notes.
I'm really excited about these two courses, and I hope you all love them.
We'll be giving away five tickets to attend PyCon US 2021.
This conference is one of the primary sources of funding for the PSF,
and it's going to be held May 14th to 15th online.
And because it's online this year, it's open to anyone around the world.
So we decided to run a contest to help people, especially those who have never been part of PyCon before,
attend it this year.
Just visit talkpython.fm/PyCon 2021 and enter your email address,
and you'll be in the running for an individual PyCon ticket.
Compliments of Talk Python.
These normally sell for about $100 each.
And if you're certain you want to go, I encourage you to visit the PyCon website,
get a ticket, and that money will go to support the PSF and the Python community.
Congratulations to Tammy Doe.
Tammy won the second of five tickets we're giving away, and there's still more chances to win.
If you want to be in this drawing, just visit talkpython.fm/PyCon 2021.
Enter your email address.
You'll be in the running to win a ticket.
Now, let's get on to that interview.
Peter, welcome to Talk Python to me.
Yeah, thanks for having me.
Great to be here.
Hey, it's really great to have you here as well.
It's been far too long since we've talked containers and Docker and all the things.
I was looking back at something like Show 9 or something like that.
It was, I believe, 2015.
Has anything changed with Docker since 2015?
I suspect something has.
Yeah, containers are interesting.
They're moving very fast, right?
Very fast.
On just about all fronts, I think the whole developer, DevOps, DevSecOps, you know, just have embraced it the past five years.
Yeah, I was thinking what you might respond to from that question.
And to me, it seems like not so much how containers work and run, but just how people have embraced them and how many places they show up and how many people are saying, hey, hey, we have a cluster.
You just run your thing over here.
Just give us your container and we'll help you run it as part of our platform as a service or whatever it is they're cloud hosting.
Yeah.
Yeah, it's very interesting.
And then there's all these little micro, maybe micro is not the correct term, but all these, a lot of SaaS and startups and trying to help.
And containers are at the core of a lot of that.
If you get in a container, we can run it.
And yeah, some really interesting SaaS as they're starting up, little niche platforms as a service type things.
Yeah, 100%.
Yeah, absolutely.
It's super interesting.
Before we dive too deep into that, though, let's get started with your story.
How did you get into programming?
As a kid, my dad's an accountant, but a nerd at heart, you know, a techie, let's say.
And he started out, this is interesting, at least to me, he started out with calculators before PCs were a big thing.
He had calculators and he programmed these calculators and stuff.
And anyways, long story short, he ended up getting, I think it was Apple II was the first kind of computer we had.
And I was fascinated about it, started programming on it, just learning, messing around.
Fast forward after high school, I was in the Coast Guard and had gotten out and was going back to school.
And, you know, I started back as an accountant.
My dad said, hey, accounting is a good foundation, like math and science and those type of things.
And I hated it, hated it, debits and credits.
And I was just like micro Mac record.
Yeah, exactly.
Now it's very, yeah, now it's a lot more interesting.
Back then I couldn't stand it.
But then I lucked out.
My father was running two steel companies and he had a consulting team that was writing software for him, you know, like very exciting stuff.
Like inventory management, work in process tracking.
It's not exciting, but it's the kind of stuff that if you looked at what people were doing before, it was dreadful, right?
It was like transformative, even though it seems so boring and basic.
Yeah.
And he said, why don't you come work for me?
And this consulting firm, the main, the owner had some life issues or whatever and had to move on.
And I said, well, I don't, you know, I don't know what I'm doing.
He said, oh, you'll figure it out.
There's a big Barnes and Noble at the top of the hill there.
You can.
They got a whole section on it.
Just go read it.
Yeah.
Literally.
Yeah.
And, and I did, and I did.
And, you know, it was, I had a passion.
I had a burning desire, right?
To learn.
It was fascinating to me.
Yeah.
And so I switched over a computer science degree, MIS.
And, but by the time I got farther along than that, I was getting paid to program and I was learning a ton more on the job.
So that kind of started my career.
Do you remember your first experience of getting paid to write code?
Was it just like, I can't believe they're actually paying me to do this?
Absolutely.
It was.
Yeah.
I mean, it's literally how they say, you know, find something you love and are passionate in and the money will come.
And yeah, it did.
It certainly did.
I was, I really enjoyed it.
And yeah, I was getting paid to learn and write applications.
So yeah, it was, it was awesome.
It was awesome.
Yeah.
It's fantastic.
I remember my first experience like that as well.
I'm like, I had better figure this out before they realized I can't actually do this stuff.
Yeah.
I could do the things they want if I'm like, oh, any moment they're just going to say, no, if you actually don't get to do this anymore.
But it was, it was great.
Yeah.
Yeah, exactly.
By that time I said, you know, I have to get on a bigger team and learn.
I know I got to the point where, okay, I can write programs, but I don't know how to be an engineer.
And I'm not sure I could put it in those type of words.
But, but luckily after that, I got on a team and had some great mentors.
So yeah, that's, that's how I kind of got started.
Yeah.
Fantastic.
I think that's good advice.
You know, it's, it's really cool to be on small teams because you really get to put your hand in so many areas.
You're not pigeonholed into, well, I'm the one who optimizes a stored procedure.
So I do that.
Right.
You know, you get like a really broad experience, but at some point when it's like, I'm, there's no one I can talk to or learn from to go farther in this.
Then it gets to be a little bit limiting, I think.
Yeah, exactly.
Like, well, that's how it got for me.
I was like, I don't know where to go next.
And I don't know who, you know, I didn't have anybody there with me.
Yeah.
I think having a mentor either, you know, well-structured or kind of loosely structured or whether you look back on it five years and go, oh, that person was kind of mentor for me.
It's very powerful.
Right.
It's very powerful.
Yeah.
Yeah, absolutely.
It totally is.
I remember making that transition to a really great group of people who were, every one of them I felt like was way smarter than me.
It was intimidating, but absolutely was a good outcome.
Yeah.
That's the place to be.
Right.
Unless, you know, of course, I think a lot of us too in tech deal with the ego issue sometimes.
I know I did.
Right.
Like, hey, I'm pretty smart.
I know what I'm doing.
Then you, when you're young and ambitious, right.
And you run into other really smart people that like are smart and you go, okay, I'm not that smart.
Yeah.
It's a little humbling, but it can be humbling.
Yeah.
Those are probably good life lessons, but they're hard to take when you're young.
I remember.
Yeah, absolutely.
Yeah.
Fantastic.
So how about now?
What are you doing day to day?
Yeah.
So I head up the developer relations team at Docker and I get to do what I love.
You know, I still get to play around with tech and learn new things and build stuff.
But then I also get to transfer that knowledge to others or at least try.
So teaching and mentoring is what I do mostly day to day, right?
Content and workshops and those types of things.
I help folks learn to use containers and Docker to help build applications.
Right.
So, yeah, it's fantastic.
I love my job.
Truly do.
I can imagine.
You know, I really have thought for a long time that this developer evangelist sort of
role just seems so neat because you get to work with a bunch of people.
You're not really there just closing boring JIRA tickets every day, right?
You get to just work at like the fun level of software and really interact with a lot of
different people.
You get to go to conferences, maybe be on a podcast, all those kinds of things.
I just, it's a really cool space to be after you've learned enough in the industry to play
that role.
Yeah.
A hundred percent.
I remember seeing, I had thought about the role before, but I think I was at Google's,
what is it?
Google Next.
I think it's their conference.
And that was when I kind of, I had known about Dev Advocates and DevRel, but when I saw
a couple speak, I was like, oh wait, Dev Advocates.
Oh, they get paid to do this.
This isn't just, you know, Peter, who's a software engineer, then speaks, right?
This is their job.
And I was like, oh, that's, that's pretty interesting.
Yeah.
It's, I think you got to have the right personality for it, but I think it's really fantastic.
I did actually a whole episode, episode 189 on this role.
And I had four or five people who were at different companies doing this.
So yeah, I was, it's really, really neat.
So, you know, I do want to catch up on what is new and Docker and containers in that whole space,
but there are a lot of people with lots of different backgrounds.
Let's, you know, listen to the show who I'm sure everyone's heard of Docker and
containers, right?
It's like hearing of Linux or something, but that doesn't mean you're super familiar
with it or you really understand the advantages or maybe the history.
So let's actually maybe start with just like the history of containers a little bit.
I know when I first saw the talk by the original, I think it was the original CEO of Docker,
he had a really interesting sort of tie back to shipping containers.
Yeah.
So what's this whole idea of containers?
Where's it come from?
What's the deal?
Yeah.
Solomon Hikes.
Yeah, that was him.
When I first saw his, I think it was at a Pi conference.
Now that I think about it, actually in Europe.
Yeah.
He gave a quick brief, kind of like what do you call lightning talk, right?
And it kind of went over at the end and people like went kind of crazy.
And I remember kind of seeing it and I was like, and if you ever go watch it, I recommend people
go watch it and kind of look for the aha moment.
At least it took me a bit, right?
And, you know, he did ran these commands and then, oh yeah.
And then there's this process running inside of a container and super easy.
And I forget what he demoed, but it took me a while, right?
To be honest, right?
I stepped back and said, well, okay, we have VMs.
What is this container thing?
And it took me a little bit to figure out like, oh wow, this is super powerful.
But, you know, containers that the constructs to build containers have been around for a while
since the seventies, right?
And been in Unix, different Unix flavors with change root and those type of things.
And then I think around 2000, I believe was when vServe came out and then about eight years.
So you had Linux vServe and FreeBSD had some, you know, container-like functionalities to isolate
processes into those type of things.
So vServe was kind of like a virtual, you know, sitting on top of the core kernel and having
some virtualization there.
I'll put virtualization.
Yeah, when I first heard about Docker, I thought, oh, this is this amazing new thing.
And then as I researched it more, I'm like, actually this, the pieces had always, not always,
but they had been there for a while.
Like these pieces you're talking about, they just hadn't really been put into a nice little
package the way Docker has, right?
Yeah.
And I think that's the beauty of what Docker did and Solomon and his team, right?
There was, I think there was three founders, but yeah, two is, was it 2013?
There it is on the screen.
Yeah.
So 2013 Docker kind of took off, right?
It kind of exploded and it was just that.
And I, you know, they simplified containers.
These constructs were all there, but they made it easy.
The ability to deep, you know, drop back down in, into the details or stay very high level
and use, you know, Docker run, Docker push, you know, those Docker build, right?
Those three main commands were super powerful.
And I think that was the beauty of Docker.
They just made it easier for the average developer or, you know, for, if you had to be a Linux kernel
developer to kind of really understand containers before that.
Yeah.
And they simplified it.
Yeah.
Linux admin or something like that, right?
Yeah.
A hundred percent.
And it's kind of like, I think Microsoft did a great job at this.
I think Apple has done a great job at this, you know, Microsoft with, you know, VB, right?
And I'm going to get beat up on the internets for this visual, visual basic, but visual basic
six, I mean, kind of weird, but it was a game changer, right?
You had C++ MFC, you know, writing these C++ to write desktop apps and business apps.
Right.
And VB6 came along and said, oh no, no, it's, you know, if you need a text box and
some labels and a button, just drag it on there.
Right.
Look, I won't beat you up for that.
VB was transformative.
It was magical.
Yeah.
The problem with VB was you could go so far and then you're like, well, VB doesn't do that.
So now you, now you get a grownup.
Now it's time to put your big boy pants on and get a grownup language and suffer the,
you know, C++ huge gap.
But for what you, a lot of people built with that, it was incredibly easy.
To be honest, there's nothing like that today that I can think of.
That is so powerful for building a little distributable application I can give to you.
Yeah.
Electron feels super complicated and hard.
Python, you can build stuff, but it's always kind of like, but this is a challenge or that,
you know, even though the windows stuff with WPF is, it's way more complicated than like,
it was magic, right?
It's just, it's too bad that there's not sort of a semi-modern version of something that
simple for people.
Yeah.
And if, who knows if, if Visual Basic had curly braces, we might have a different story.
I mean, like, like truly, right?
I mean, I remember having debates with, yeah, what's not a real language?
It's, you know, it's basic.
It's the basic programming language, right?
But yeah.
Yeah.
And John Sheen out there in the live stream says, rad concepts seem to be coming back as
these low code, no code platforms.
That's a really interesting tie in there.
I do agree with that.
I think that they've gone even lower than, or simpler than what Visual Basic was to like
really, really simple.
So yeah, I'm not sure it's exactly equivalent, but it's definitely, you're right.
Those things are definitely coming back.
Yeah.
I think we were real complicated.
Now we're going real too simplifying, right?
The pendulum swings hard.
Yeah.
I think we'll find it.
I do believe though, with technology, right?
Abstractions get higher and higher.
And well, this will kind of roll in a little bit into where the container history went
next.
And, you know, 2017, 18-ish, Kubernetes kind of dominated the orchestration, right?
And still does.
But it is, I was going to say horribly complex.
And maybe it is, maybe I'll get beat up for that too.
But it is extremely complex, right?
Extremely complex.
And you're mostly talking about like running a Kubernetes cluster is complex.
Not necessarily like somebody's already set up for you and you give them a-
of a definition and say, run that.
Like that part might not be so hard, but like if you're going to do the whole stack, right?
Yeah.
The whole stack from the ground up, right?
Yeah.
So it's a bunch of moving parts, getting installed, getting everything working together.
Security, networking.
Yeah.
It's not simple, right?
It's not simple at all.
This portion of Talk Python to Me is brought to you by Datadog.
Are you having trouble visualizing latency and CPU or memory bottlenecks in your app?
Not sure where the issue is coming from or how to solve it?
Datadog seamlessly correlates logs and traces at the level of individual requests, allowing
you to quickly troubleshoot your Python application.
Plus, their continuous profiler allows you to find the most resource-consuming parts of
your production code all the time at any scale with minimal overhead.
Be the hero that got that app back on track at your company.
Get started today with a free trial at talkpython.fm/Datadog, or just click the link in your
podcast player's show notes.
Get the insight you've been missing with Datadog.
I think it'll get easier and easier and easier and orchestrated run times.
You know, I see a lot in tech, like the app engine from Google with Python, right?
Well, basically serverless now.
But when it first came out, you're like, what, you're going to run my whole app?
No, no, no, no, no.
I need to control all that.
Yeah.
So we did away with it.
But now we're coming back.
You know, serverless, we're kind of coming back to it.
Same with Kubernetes, right?
Oh, you're ECS and ACI on, you know, hey, give me a container.
I'll just run it and manage it.
You know, we said, no, no, no, no.
I need to control all that.
And then you get this massive Kubernetes.
And now I think we're going back, right?
Yeah.
I just want to give you my containers and run them for me, right?
I don't have time to deal with all this.
And Google's and Google announced autopilot and those type of things, right?
So I think that's the way we're going to go.
And I think Docker as a company, about a year ago, when we sold off the enterprise, a little
over a year ago, sold the enterprise business off, got a kind of package software, enterprise
software, moved more to SaaS, back to developers.
Yeah.
Well, let's dig into that for a minute, because I remember seeing Docker coming along and it
was like, oh, this is a really cool, really cool dev tool.
But how are they going to make any money out of this?
And I feel like the first big step was, well, what we're going to do is we're going to have
special offerings for enterprises and help them tame their zillions of different types
of software they need to run.
It sounds like that that's not the case anymore.
What's that transition?
What's happened with Docker around that?
I think first the business model was we shifted to an enterprise business model.
Prior to that, Docker was just exploding, right?
And building tools and every Docker con, there was a new release and a new tool.
And a lot of them would fizzle out and stuff like that.
And the people with the purse strings, the money said, hey, hold on, this is great.
You're doing some wonderful things.
But we want our money back eventually.
So can you go sell something?
And they probably-
Open source and Cumbia, we all love it.
But we're investors.
Where's our 10X?
Yeah.
So we shifted a little bit to enterprise.
And it was just an old business model, I think.
On-prem, long licenses, three-year licenses, at least a year, if not three years.
And then consulting on top of that.
So paying a couple of hundred thousand dollars for the software and then twice that for consulting
services.
It was just a model that's a little bit outdated.
And it's still there, of course.
But Salesforce was really the first that kind of was starting to drive the nail into the coffin,
so to speak, right?
Well, it seems to me where a lot of those stories are moving are, are you moving to Azure?
Are you moving to AWS?
Are you moving to Linode?
Instead of trying to solidify and really modernize the data center inside companies, a lot of them
are going, how can we just get out of the data center business?
In which case, that's a totally different story, right?
In terms of how they work with you guys.
We did have an advantage, you know, cross cloud, one single plane of glass for all your containers
across clouds, internal, external.
But it was just, it was a day late and a dollar short with funding when we kind of tried to
do that.
And yeah, so they sold off the enterprise business and focused back on what Docker does
really well is build development tools, development experiences, making container development first
really easy, right?
And that's kind of what we're focused on.
We call it shift left, right?
Focusing back on the developer.
We're still very interested in ops and DevOps and DevSec ops, but more from a developer's perspective
and not that day two long-term running your production environments and stuff.
Yeah.
And so we got small again, got focused again.
You know, we have something like 10 million developers or 10 minute desktop installs, you
know, billions of images being pulled out of Hub and kind of looked at it and said, hey, there's
a business here, right?
Just official images on Hub is a huge, huge asset for us, right?
You know, with Python and packages and all the languages and runtimes, right?
To get really good, high quality scanned packages is hard, right?
And Hub does that.
So you know where you're getting your Mongo database from, who's produced it.
Docker kind of puts their stamp on it.
Okay.
So you guys have like officially verified, certified, either direct images or Docker files that build
the images out there?
Yeah.
So we have official images, which we kind of say, hey, this is following best practices.
This is, you know, been scanned for security vulnerabilities.
That doesn't mean there's not security vulnerabilities in there.
If anybody works in the security space, right?
That's like impossible.
Yeah.
Lowers your attack surface.
This is the, we're recording this the week that we're basically hearing, you know, 60,000
direct companies have been compromised by the Microsoft Exchange vulnerability.
And then they're probably providing products to others, right?
Like it's, it's tough.
Yeah.
Yeah, it is.
But at the same time, there's also a lot of news around supply chain vulnerability.
And the SolarWinds thing was a supply chain vulnerability.
I don't believe the, you don't know, but I don't believe the exchange one was.
But, you know, Docker is certainly part of that supply chain, either strengthening or weakness
there, right?
Like we hear about how PyPI and NPM and RubyGems and all of those have people have been, you know,
putting renewed interest in trying to get bad things into there.
I always have the same thought about Docker if I just grab an arbitrary Docker file off
the internet because, oh, look, this configures the thing that I need.
And I Docker build Docker run.
Well, it might be configuring it with extra goodies for someone else right in there.
Right.
And so that sounds like a really good thing to, you know, at least have verified to the degree
that you guys can.
Yeah.
You used to be with security, right?
It's, I remember sitting at a large computer manufacturing company here in central Austin,
central Texas.
I won't mention their name, but, you know, we're getting, oh, nice.
Thank you.
Yeah.
So we're, you know, launching a big release and we're all sitting in the go, no go meeting
and it's, you know, a couple of days before release.
And of course, then that's when the security team walks in.
Right.
And they're like, oh, you know, like literally like dropping down.
Hey, you didn't fill out your, your TPS reports.
And exactly.
Well, that's such the wrong time to do it because, you know, a lot of those ideas have to be built
in early and you've got to, yeah, it's really tricky to layer that on at the very, very end.
A hundred percent.
And now with containers, developers a lot more are closer to the operating system and worrying
about it.
You know, before you had your VM and you had, you know, you had ops folks taking care of that
was patching them and keeping it.
Here's my code.
It's going to need Nginx and micro whiskey.
You figure that out.
Go.
Right.
Yeah.
Now we're throwing it in containers and devs are doing a lot of that.
So shifting that security even farther left to, Hey, scan your images, make, you should
know what's going in your images.
You know, what base images you're using, those types of things are super important.
Yeah.
Okay.
And controlling that whole light, like you said, that, that whole life cycle, right.
Of, of when you're building your images and how through CICD, right.
Doing the consistency consistently, making sure you're doing scans.
Right.
So you can protect that whole pipeline.
A hundred percent.
Yeah.
We definitely need to be thinking about that as an industry.
It's serious.
Yeah.
There's so many smart people out there and they move fast.
They move really fast and keeping up with the hackers is hard.
That's for sure.
So one of the things I thought it might be fun to touch on is just some of the areas
that containers are useful, maybe some of their, their benefits, things like that.
Right.
I think there's a lot of different use cases that are not, well, it makes DevOps more consistent
with development, even though that may be one of the benefits.
Yeah.
You know, the, the biggest problem that Docker solves is that packaging.
It runs on my machine.
Right.
And that's been part of our marketing since the beginning.
It works for me.
Right.
There's a fantastic thing that people should Google.
Maybe if I can find it, I've put it on the show before, but there's a thing called, it
works.
It works on my machine certification.
You can get the official certification.
This is done by Jeff Atwood and some folks.
Oh, that's fantastic.
And another guy over there.
And so you get this big banner.
It says, it works on my machine.
And the way you get it is you compile your code and getting the latest from any version
control, getting the recent from that is totally optional and up to you.
You launch the application that has been compiled.
You cause at least one code path to be the, to, that needs to be checked, to be executed.
The preferred way to do this is ad hoc manual testing.
You may omit this step.
If the code change was less than five lines or in the developer's professional opinion,
it couldn't possibly result there.
And then you check it into source control.
Right.
And so, yeah, I mean, that's, that's a joke.
And the reason I bring it up is it's just, you know, so common in the industry that you
run into this, this problem, right?
That, well, we tested over here and under this environment, it works fine, but in a different
environment, it doesn't.
And, you know, we try to backfill that with things like CICD and whatnot, but it's, you
know, it's still, it's not a perfect fit.
So with, with Docker, you can get much closer to running on exactly the same system.
Yeah.
The idea is not only package your app, but package the operating system, all of its
dependencies, your app, its configuration, all the application dependencies all in one package,
right?
Into an image.
And then pass, share that around, right?
Makes it so much easier.
Yeah.
At that large computer manufacturer, right?
We had two huge data centers.
And I talk about this in my getting started video, you know, 50 in each center just for
the browse layer and dub, dub, dub.
And if you go through and patching those machines, those 50, and you miss one.
And of course we had scripts and all that, but you know, we still had them manually.
You list of what servers are in and out of the, out of the data center, who's in DNS,
who's not right.
You miss one.
And then you get this, these, these random errors where I hit three good servers, the
fourth one breaks, and then you hit F5 and you go back to server two and you're fine.
Right.
Yeah.
That's really tricky when it's, it's going, you know, could be round Robin type of
load balancing.
And you're like, well, sometimes it's wrong, but I don't know when.
Right.
Yeah.
So we used to just go and, you know, restart all the servers one by one.
Some of the, some of the troubleshooting.
Yeah.
Some of the troubleshooting you get into is like, we have no idea.
Yeah.
So I think Docker really, really attacks that really well.
But then when you looking at developers, what I'm really excited is, you know, moving into
microservices and kind of more modern cloud first kind of development.
Right.
Again, getting everything running on your machine, you know, 10, 15, a hundred microservices that
you're not going to use.
You're not going to touch.
You don't work on, but they need to be there.
So, you know, you have this mesh of microservices or even just three or four of them, right.
That work together.
You have to have your sign on, you know, your single sign on, blah, blah, blah, all these
things and getting databases and queuing and everything running locally is hard.
Right.
If I got to install Mongo and SQL server locally, and then maybe projects are using two different
versions.
Right.
So now if everything's in containers and then if you're using compose, which I'll use orchestration
loosely here, but it orchestrates your containers locally.
Right.
Because Docker is all well and simple and easy.
When the goal is I need to fire up this Docker container and I put the thing I want to run
at the end, you know, I say Docker run, you know, container something.
But if I want to run multiple things and they've got to discover each other on the network, they've
got to have DNS names.
And this one has to start before that one.
Right.
All of a sudden it's a whole, a whole nother level of like manual challenges to do that
by hand.
So Docker compose is basically a way to write a file that takes a bunch of Docker containers
and starts them the right way with the right ports and everything.
Yeah.
Exactly.
Wire gives you kind of built in discoverability.
So DNS, you can easily plug in volumes and share volumes across your containers.
Yeah.
Super powerful.
And it's also a way to, like you said, writing out all these Docker run commands and then your,
you know, your run command is huge.
You can put that all into a compose file and then you use version control.
Things like that.
Yeah.
And then once I, yeah, exactly, Michael, I could set up and then, you know, setting up a
new dev.
Hey, you know, pull latest from GitHub and Docker compose up and, you know, brings your
application up.
I've got a couple of ideas here that I thought might be fun to bounce off you.
And the very first one on the list is onboarding new developers.
Yeah.
I mean, it's one thing to say, well, we're going to create a new project.
I want to work on it, but almost no one starts jobs with brand new projects.
They start jobs with, here's what we've been working on for four years.
It's kind of clunky, but it works.
Go.
Right.
A hundred percent.
And I wrote, I wrote a blog post about this, but, and then my mentees, right.
A lot of them come out of bootcamps and, you know, they're used to right click new
project.
Right.
And I'm like, that's not where you're going to go.
Right.
You're going to jump into a code base that is not the latest and greatest react, you know,
functional components, right.
You're going to have old stuff and you got to be productive.
It's a huge, I mean, I'm sure the audience will know.
It'd be great to hear, you know, the last time you joined a dev team, how long it took
you to just get your computer set up and get your environment set up and get familiar.
Right.
It's a week, at least a week, if not two weeks.
Or, you know, your machine dies and you're like, well, now I got to get it all set up
again.
I haven't done that for a year and a half.
So I forgot how to do that.
Right.
Yeah.
I'm trying to get everything into containers as much as possible, run everything in containers.
When you get into the GUI apps, it gets a little fun, but yeah, if you're running everything
in containers, it makes it super simple to be able to move those onboard new devs.
Yeah.
A hundred percent.
So another one of those that I think we kind of already touched on more or less is reliable
development.
Like everybody's working literally on the same system and you don't have the, you know, works
on my machine certification thing.
Yeah.
A hundred percent.
Another one though is, you know, I'm here on my Mac, but maybe I want to do things that
are as close as possible to where I deploy my various stuff things, which is Ubuntu, right?
And Mac is kind of like Ubuntu.
I mean, it's got sort of a Unix flavor to it, but it's not Ubuntu itself.
It's not exactly that.
Right.
And so having this ability to be closer to the environment that you're going to run at,
or you're going to deploy to, even though you happen to be developing in on something
that's not that.
Yeah.
Being able to get correct versions, right?
Of everything across your stack is, is very hard, right?
It seems simple, but it's not.
I mean, I could get Nginx.
I could brew install Nginx onto my machine, which I probably have done already, but maybe
I've got like the latest, greatest, whereas by default over on Ubuntu, if I just say, you
know, app install Nginx, I think it's held back a little ways for some reason, unless you
really like configure it for the latest sources.
And so, you know, maybe the configuration file has something new that I could do on my machine
that's supported.
But if I try to put it out there, it's just going to, you know, service failed to start.
Yeah.
Go find a log file somewhere and figure this out.
Right.
And that's, especially when you're new, it's like, I don't even know where the log files are.
Why is this happening to me?
It's so frustrating.
Right.
Yeah.
You're pulling down a project and the, the remia getting started is compile, right?
Make run, make, right?
Yeah.
And if unless you're a C, a Linux C developer and you start getting errors, you know, off the
stack overflow, you go and start randomly trying things.
Right.
And that as a senior developer, you know, I'm like, I'm so scared.
I'm a foobar my machine.
Right.
Cause I'm just changing settings and stuff.
And yeah.
Yeah.
But if you were doing that all inside of your container and really a Docker file is, is the
steps you would do to install an application.
Right.
And so they're all there repeatable, have the correct versions of, you know, libraries
all in the image.
Right.
I think it's a simple preconception to have is like Docker saves me from knowing Linux in
terms of the command.
So I don't need to know Linux if I'm going to run on Docker and maybe off to Kubernetes or
whatever.
And so I can just do Docker and then everything will be fine.
But in practice, like those steps you just described, those are apt install this, you know,
and the various configuration commands of Linux itself.
So there, you do need to know a little bit.
There's a very small subset that you need to do, but you know, you don't really have to be
an admin of Linux.
So I do think it takes down the bar, but I still think it's interesting that it's, you still
kind of have to know a little bit about how to set up the system.
Yeah.
And it's nice because you can start high level, like, Hey, I just run my, my, my
Mongo image and it works and I'm not exactly sure.
Right.
I just, here's the connection string.
We're good.
Yeah.
Here's the connection string.
And then if you start, okay, I want to build my own and I want to get slimmest images as
possible, right.
You're going to, you're going to start diving more in it.
And really the skillset to build your images is you have to understand Docker, but then
you also have to understand Linux commands, right?
How to install things on Linux, configure them for sure.
But you don't, to your point, right.
You don't have to start there.
Like don't become a super, you know, admin, you know,
get the Linux command line Bible or whatever book it is.
Like start tearing through it.
Right.
I think that's a book.
Yeah.
I think it is too.
You can go very far with, without knowing that just basic Linux commands.
Yeah.
I got a few examples of like, these are the three things you really got to do.
Yeah.
And the nice thing too, about official images that you can, they're stored in GitHub too.
So if you go in the hub and see it, you can jump into the GitHub repo and actually read
the Docker file.
So it's great way to kind of, kind of learn, right.
Of best practices and those types of things.
Yeah.
Yeah, absolutely.
You talked about building like thin images and whatnot.
One of the interesting things is taking these Docker files and layering them, right?
Like instead of just saying, I'm going to, I'm going to need Nginx and I'm going to need
Python and I'm going to need all this.
So let's just build one that has all that.
And then any minor change you make to the Docker file means you completely rebuild all of that
stuff.
And maybe part of that's compiled from source that takes two minutes.
And it's like, why is this so slow?
Right.
You could make that four or five Docker files that one depends on the other that depends
on the other in very subtle, small ways.
So like only the very last bit that changes maybe really requires much work.
Right.
You want to speak to that a little?
Yeah.
So you can do two things in there.
I think you want to make sure one of the best practices you want to do is only one
run one process inside of a container.
And I'm going to, I'm going to, I use container and image sometimes interchangeably.
So, and then I get, I get yelled at for the people's on the internet.
I'm probably making it wrong.
So I'm an image, I believe.
Yeah.
No.
And you're totally fine.
Right.
Cause you can use them interchangeably, but so container is just a running image, right?
And if you're a computer scientist or object-oriented programmer, it's your class and your
objects, your class is your image.
And then your object is your container.
So containers are instance of running.
And I use them interchangeably all the time.
And I get yelled at in a lot of my talks, but, but generally speaking one process running
inside of your container, you know, it's the, it's the old Linux idea, separation concerns,
do one thing, do really well, microservices, those types of things.
But then to be able to create your images as small as possible, right?
You can do multi-stage builds is what we call it.
So you can have a stage in your Docker file.
That has all your compilers, your libraries, everything you need to build your application.
Make that one part of your Docker file.
And then below that you can reference that.
And so like a lot of Golang stuff, and we do this internally is we'll use Docker to build
all our apps, multi-architectural to architect.
And then below that, just pull out the compiled binary and put that in my image.
So now your image is extremely small.
It only has your executable in it and everything else that you compiler tools, GCC, all that
type of stuff is left out.
Oh, that's interesting.
Yeah.
So those are kind of like throwaway containers.
It'll do everything in container, get your nice dev build environment, build it, and then
pull only what you need out.
So even like in a node world where you're not, it's not a compiled, compiled language or Python's
compiled, not a compiled language, right?
You could do everything you need in an earlier stage and then pull that out.
Just what you need into the final stage to be able to serve those up in your runtime.
That's it.
And that's the best way to kind of get the smallest, lightest images you want.
And the smaller and lightest that you can get them, then they're easier to pass around.
They're easier to start.
They're faster to start up.
And the attack surface from a security perspective is very small.
Yeah.
Less is better there.
Less is better.
Yeah.
Absolutely.
All right.
Some other areas that I think two more that are certainly related, but not exactly the same.
I feel like the data science side has a lot to gain from the whole container stuff because
so often the environments are multi-technology.
You know, you might have, oh, we're going to use this library and it depends on Fortran.
We'll use this library and it depends on Rust.
And then we're going to control that from a Jupyter notebook.
And it's, you know, it's different environments make that harder, easier to set up.
And so I feel like data science has a lot to benefit from here as well.
I think so too.
And that's not my world day to day for sure.
And so I gave a talk at the Toronto machine learning group a while back.
The talk should be online.
So if you're interested, you'll be able to check that out.
And when I was step back and really thought about what I wanted to talk about and how is
Docker really helpful in these scenarios.
And it's kind of all the things we've been talking about.
It's how do I share my data set with other data scientists, right?
And you can put those in images and you can put those in volumes and share those, right?
And then how do I get a consistent environment to, you know, reproducibility is the biggest
thing in science, right?
Right.
That's the other half of that that I was hinting at.
That's right.
Yeah.
And so having that reproducibility that I can share with other scientists and you have everything
packaged together that I was running, right?
And you might swap out the data with your own data, but the processes is all the same.
So I think reproducibility is huge and talking with those folks, the machine learning folks,
that's what they were looking for, right?
Is how do I pass this around?
How do I share this?
How do I get my environment up quickly without having to become a full-blown computer scientist,
right?
A software engineer.
Or an admin or something.
An admin, yeah.
Well, one of the challenges in science in general, I believe lately is there's been,
what do you call it?
A crisis of reproducibility, but like a real focus on reproducibility.
And because of that, I think some folks have realized certain studies are very hard to
reproduce.
And it used to be what they would publish is, here's a graph I generated with my software
and here's the analysis of the graph.
And you're like, well, that could mean anything.
I can make a graph out of anything.
That doesn't mean very much, right?
And so then the move to like Jupyter Notebooks and IPython and so on to say, well, here's the
code and here's the graph and here's the explanation.
And that's a fantastic.
But what version of the library that maybe had a small interior change that no one sees
that might propagate some change down there.
And you can solidify all that stuff into a Docker container and then say, this is exactly
what we ran.
At least maybe it was wrong.
Maybe it was right.
But this is what we did.
Yeah.
Just even a minor tick in a version of an algorithm that's processing the data, right?
And I'm one tick behind you.
And well, that's not the same, right?
It's not the same.
Yeah.
It might be okay.
But we need to know that that's how the difference is.
Yeah.
You know, one thing that's interesting.
Have you seen this project Gigantum?
No, I haven't.
Okay.
So this one, I had these guys on the show back on episode 238 and it's really all about
Docker.
It's super interesting.
Oh, cool.
So it's like a collaborative way for building like local environments in Docker, but then
sharing those and then people can work on them and then you can like publish them to the
cloud.
And there's like all these cool activity streams.
And it's just all about orchestrating data science with facilitating that by doing Docker.
They have interesting things.
Like if you go in and open up like a terminal and you type some commands, I believe they try to
like capture those and make those part of what has to be done to the Docker container, even
though you didn't change the files.
They're trying to do a lot of stuff to make it like really the same.
So I don't know.
It's an interesting idea.
Oh, that's interesting.
I'm going to go check it out.
Yeah.
Jumping back to our earlier conversation, building that Docker file, right?
Is, is, and you, especially when you're learning commands, right?
That build debug cycle, test cycles can be painful a little bit.
Yeah.
So we're trying to think about that at Docker, right?
Like it's one thing to have an image and just run it and use it.
And then it's another to build, build an image, right?
A very complex image and kind of, so what you end up doing is kind of what you say.
You create a base image and then you're inside of that running commands and then go, crap.
Okay.
What did I run there?
Exactly.
You go write that down.
Yeah.
We kind of love to reverse sometimes.
That thing I just did to make this work, make that part of the Docker file, you know?
Right.
Extract what I did.
Those five things I typed on the command, the terminal command prompt.
When I logged in with Docker run, you know, Z shell or bash.
Yeah.
I need that too.
Yeah.
A hundred percent.
Yeah.
Advice.
Do you got advice on that?
I mean, it's basically a saving at each point right now.
It's very low fidelity, right?
You're, you're running the command and then, and trying to remember.
Right.
And it's painful.
Yeah.
It's very painful.
Some up arrow action.
Like, okay, I did that.
Then down arrow, down arrow.
Okay.
Those are the things.
Something like that.
Yeah.
We've been playing around with some interactive, lightweight kind of, I say editors, but tools,
right?
To, to build your images.
So the concept of building an image from scratch, it's where you kind of, you can do a top or a Docker file, say from, you know, Ubuntu or from Alpine.
Well, you can do from scratch and that's literally nothing.
Right.
And you're moving everything in yourself and that's tough, but it's, if you, the most secure and leanest image, that's the way to do it.
And yeah, so we've been thinking about tools around that and it's exactly that capturing what you're doing and what works.
Right.
So you can play a little bit and take, try and figure things out.
And then once you figure it out, you're like, oh crap, what, what was that sequence that just worked?
Right.
Cause I did five things, but those three things were what actually worked and that could be tough for sure.
I find that what I do is I'll fire.
I'll try to create the Docker file.
It'll invariably fail in some way that I didn't predict.
So then I'll get it as far as I can run it in an interactive mode and try to, you know, get it to go to where I want it and then go, okay, well, these are the steps.
And maybe it errored out during the build, but you couldn't figure out why.
So you want to go explore something to see what the log generated for that failure.
Right.
There's a little bit of back and forth.
Yes.
A hundred percent.
Yeah.
What do you think about things like attaching, basically using Docker within some of these tools like PyCharm and VS Code both have these ways to say, just run this, but in Docker when I pressed debug.
Yeah.
My old school developer, you know, no fancy editors, right?
Text editor, you know, it dies a little bit inside, but I've had to get over that.
Right.
I'm like, no, do these, right?
Like I tell my mentees too.
I'm like, okay, when we start, like you're in a text editor, remove all, remove all the tools.
Cause you've got to feel the pain to understand what helps.
Yeah.
Sure.
But with that said, right.
Yeah.
I mean, the tools are fantastic, right?
The context switching, right?
If you can stay right in your ID, your main tool and do everything within there and do it really well is super powerful.
The VS Code plugin is super powerful, right?
Of managing your containers, running containers, dev containers, connecting into ACI and Azure and launching your containers right there.
It's extremely powerful.
Yeah.
I feel like it's going to get to the point where you might be running stuff in Docker, but you don't even know it.
Yeah.
You might conceptually know, but there's nothing about what you do or what you see that makes you feel like, oh, it's running in Docker.
You just, I pressed run.
It did these things.
I saw it in my browser or I saw the output.
Yeah.
I don't know where that happened.
Right.
But it happened in Docker.
Exactly.
Yeah.
It just works.
Right.
Yeah.
That's where we're trying to go is like with our tools is like you, the more, you know, you're, they get out of the way, right?
They're not in your way is maybe the best way to say it.
Yeah.
Really good tools.
You kind of, you kind of go, does that really doing a lot for me?
And then when you figure it, you're like, oh yeah, it's doing a ton.
I just didn't, don't know it.
It does it so well.
Right.
Exactly.
I think we have time for a few more topics that we can touch on.
So we talked about the multi-container stuff and we talked about, you know, run this on my cloud.
And I feel like a lot of times what that means these days is Kubernetes, right?
Everybody seems to have a hosted Kubernetes offering.
Sometimes that means just give us your container.
Others that means, well, we'll really just run the cluster sort of configure it for you, but you kind of got to still own those VMs that run it.
There's some sort of spectrum there.
What are your thoughts on people working with Kubernetes versus just directly with Docker itself or maybe even a pass, like almost a serverless type thing?
If you spend a lot of time on the internet, right?
We're all on the bleeding edge, right?
Yeah, we absolutely are.
Yeah.
You read a lot of blog posts about Kubernetes and service meshes and serverless.
And those are all fantastic and wonderful, right?
But a lot of us out there are not, we're not the Googles or the Netflix or, you know, Disney Plus, right?
You can see I watch a lot of movies.
But anyways, you know, so you have small teams, small three, five person teams that really are writing the majority of the software out there, right?
And there's nothing wrong with standing a VM up, putting a Docker engine in it and running your containers like that, right?
That's the way we started.
It's extremely powerful.
You know, before I came to Docker, I had a consulting business, a custom dev.
And that's how we ran all of our containers, right?
We had a Docker engine installed on a VM, sometimes two VMs, right?
That we managed as the orchestrator.
And it ran fantastic.
And we could scale, we had load, right?
And to update it and to maintain it, all the things we've kind of been talking about today were super simple because the only prerequisite for the VM was to have the engine installed.
Yeah.
And to be honest, that's how my stuff is running now.
I have a CI, CD stuff set up.
So I do get pushed to a certain branch.
My VMs automatically work with the load balancer.
They automatically update themselves.
They restart and like it's hands off, right?
And, you know, the small, small set of us, like it works.
Yeah.
A hundred percent.
And serverless.
And then also kind of the container passes that are out there.
So ECS, ACI.
So ECS is Elastic Container Service from Amazon.
ACI is Azure Container Instances.
And I don't know if Google has one.
They probably do too.
Yeah.
Love you, Google.
But yeah.
Anyways, you know, it's being able to take your container and just run it in the cloud and worry about the container running and what it needs to do and how it needs to run, right?
And ECS will take care of the rest underneath the covers.
That's a fantastic option.
I mean, it's kind of, you know, it's like those progressions, right?
If you're doing a single VM with the Docker engine or two of them, a couple of them, and that becomes painful when you need to scale, really look at ECS or ACI, right?
Because that will help you scale a lot easier.
And you don't need to be a Kubernetes expert.
And then if you do, then go to Kubernetes.
But I always tell people, and Swarm is a great option too.
Swarm is an incredible orchestrator.
It works.
How does that compare to Kubernetes?
You know, I hear Docker Compose.
I hear Swarm.
I hear Kubernetes.
I'm not sure when I should be thinking about which.
So Compose is fantastic for local development.
I would use it primarily there.
You can use Compose to deploy and production.
Would I use Compose if I had only a single container I wanted to run?
But maybe it had a complicated layering, potentially?
Yeah.
So Compose works great there too.
Even if you're running one container and all the command line switches and flags and environment variables and secrets, all those type of things, like put them all in your Compose file.
So one, you don't have to remember all of them.
And two, you don't write bash scripts to just run the Docker command, right?
Yeah, you plug them all in just like that.
You can see you're passing ports, volumes, all those type of things, right?
You know, and I tell people start, think about Swarm, right?
If you're doing one instance, don't jump to, like have really good reasons to jump into Kubernetes.
It's super powerful.
It's a great tool.
It really is, but it comes with a ton of complexity, right?
So if you don't need to go.
Well, there's, like I said before, there's a difference between I want to run this on Kubernetes and I want to have my own Kubernetes cluster for which I'm the admin.
Right.
Yeah.
And don't get stuck in.
Also another advice.
And some engineers, you're like, don't get focused on developing for your resume, right?
A lot of times, oh, we got to get in Kubernetes.
I want to have Kubernetes.
I've done all this, right?
And yeah, you know, you want to learn new technology and stay cutting edge.
But that's a tough one.
That's a tough one to go to.
Yeah.
You can get very far with single engines, with Compose, and then with Swarm.
And Swarm is a great orchestrator.
It's built into the engine.
It moved to the enterprise with Mirantis when they bought the Docker Enterprise business.
So they maintain it.
We got out of Docker proper.
It's gotten out of the orchestration business.
But it's a fantastic orchestrator.
It just works.
A prior life at Docker, I ran all the customer success technology.
So our knowledge base, our search engine, our training tools and everything.
And we ran on Compose.
Compose and Swarm.
All on Swarm.
Five, nine uptime.
Never touched it.
Didn't have a DevOps team, right?
It just, it really works.
When you need things like sidecars and more complex networking and the more complex data storage,
volumes, those type of things, that's where Kubernetes really shines.
But other than that, Swarm is fantastic and single engines will get you very far.
And then, like you said, I would go to EKS or something like that first, right?
Have a Kubernetes cluster and manage at the level that you need to manage at and nothing lower,
right?
Until you have to.
Makes sense.
Chris McDonough, creator of the creators of Pyramid.
Framework out there is in the live stream.
It says, Compose kind of fills the same space as Buildout did in Python land for managing one
or multiple containers locally.
Yeah, awesome.
Hello, Chris.
Thanks for being here.
Hey, Chris.
Yeah, very cool.
So the last thing that I want to touch on, the last topic I think we have time to talk
about is the future.
Where are things going with Docker, right?
Like we've seen this move to focusing more on, you said, shift the left, more on the developer
tools and whatnot.
I'm glad you brought it to roadmap.
Thank you.
My bosses will be happy.
My masters.
Anyways, love you, Matt.
So GitHub out there for forward slash Docker forward slash roadmap.
That is our public roadmap.
That is our roadmap, right?
We work on that roadmap.
We're actually coming out with a blog post with a feature.
And that was spawned, came out of the roadmap, right?
It was an idea from the community.
It's integrating in with different terminals with Docker desktop.
And that came out of the community.
And people said, hey, I run iTerm on my Mac.
And so does 99% of the other developers on Mac.
We want that integrated, our integrated desktop.
And so the upticks were really great.
Anyways, we implemented it.
So you'll see Ben, if you're looking at the screen on the right, Ben is the best PM I've
ever worked with.
Seriously, he's fantastic.
But he is in there constantly.
Yeah.
So we look at this roadmap.
We follow this roadmap.
We build off of this roadmap.
We don't have a secret shadow internal roadmap, right?
And we say, hey, yeah.
You've got different channels for like Windows and Microsoft and the engine and all that stuff,
right?
Yep.
And so go read through there.
Put in an issue if you have one.
If you don't find it, it's where you can interact, add comments, those type of things.
We do use that constantly.
You know, I don't.
So we have DockerCon coming up.
So I don't want to give any secrets away.
But yeah, we have, I would say, look for us in this year, the past year, we really kind
of solidified the business, right?
Really did a lot of things that Docker didn't do early in its early days, right?
As a business wise, you know, we're shifting around a lot, but focus back on Hub and say,
hey, you know, let's tighten up Hub.
This is a place where a massive amount of developers come for value.
So we tightened it up, put in good features like audit logging and more team features and
fixed our plans and seats and how the pricing and how that works.
And then started moving towards developer tools.
So integrating it with ECS, ACI into the public clouds.
You'll see a lot more of that coming.
See a lot more tools around local development, container first development, a lot of sharing.
So it'd be interesting to say, I'm working on a feature.
I have a branch and I want to share that with you, Michael.
Hey, you know, take a look at this real quick.
And now you're in that same scenario, right?
I have to check out your branch.
If I'm doing everything on my machine, do I have all the versions correct?
Do I have everything right?
Well, what if you could just wrap that all up a container and I just share it with you?
And you fire that container up and you're in a dev environment and it not just running
the container, but able to see my code and everything and the app running inside the container and
interact with it, right?
Yeah, that's cool.
That's powerful.
That sounds a little bit like the VS Code feature where they have that's like launch this in
code off of GitHub.
Yep.
And it just like sets up that remote environment.
Exactly.
Yep.
Launch, launch this for me.
And also too, I can notify you, right?
So you get in a little desktop notify.
Hey, you got something shared with you and you launch this in VS Code and it brings it all
in for you.
Yeah, cool.
And to your earlier point, you go, oh, if you didn't know you're running containers, you
might not know it.
Right.
It's like, oh, I just got this PR shared with me and I want to check it out.
Right.
And it's just the run button and it's good.
I push the run button.
Yeah.
Awesome.
A lot of stuff coming around that.
A lot of more features in for teams and sharing features coming in Hub.
We have scanning and the security scanning in there now.
Yeah.
A lot of interesting.
One thing that GitHub added was notifications of security CVEs and whatnot.
Like periodically I'll log in and I did this class that interacted in a very minor way
with an Electron JS app.
And it's always like your repository has this critical vulnerability because some random
version in a package lock dot JSON is, you know, like, so for me, I'm like, I don't really
need that, but I'll go ahead and just accept it because I just need it to be quiet to me.
But in general, those features are super useful when those come up for your actual code.
Anything like that you guys are thinking about?
So we partnered with Snyk, which is a dev security scanning company, security company.
I shouldn't say just scanning because they do a bunch of stuff.
But now you have Docker space scan.
So you can scan your images locally, get reports, see high, low severity.
Yeah.
And then that'll run in Hub.
So when you push into Hub, your images will be scanned if you have it turned on.
And so you have a central place where you can see all those.
And then you can use Snyk to remediate them and those types of stuff.
And Snyk has really good tools.
Right.
Because maybe you could have scanned locally, push your stuff to production.
Right.
And then you haven't touched it for three weeks.
Right.
But in the meantime, something's come out you need to take action on.
Right.
And so having it on the Hub, giving you notifications is constantly running.
Right.
Exactly.
Yeah.
Being able to get notified of your base images.
Right.
So if you run in the node or the Python base image.
Right.
When that changes underneath you.
Right.
And there's security vulnerabilities introduced.
Do you want to know?
Right.
Should I go to the next version or not?
And then I think, too, to your earlier point of, you know, it's like I'm not a security professional.
Right.
So I see these reports and I do a scan and I go, oh, heck, you know, 300, you know, high
severity vulnerabilities.
Right.
What do I do?
And I think what we're trying to do is say, hey, here's how you remediate that.
Right.
You're on version 3.2.
If you bump up to 3.3, it fixes these.
So you should do that.
Right.
A little minor version upgrade or major upgrade takes you to instead of 300.
Now you have 20 vulnerabilities.
Right.
And they're all medium.
So.
Yeah.
You know, I think we need that as engineers to be able to get our job done quicker writing
code.
You know, it's a primary function.
Right.
So I got a bunch of these vulnerabilities.
And to your point, you kind of like just, yes, just clearly these red X is off of here.
Right.
We might not know exactly what's going on.
So really trying to help you remediate those vulnerabilities, but also understand why and
what you're doing.
Right.
Yeah.
That sounds really valuable.
We got it for our code.
We should have it for basically our infrastructure.
Comment from the live stream.
Could Docker potentially be able to share really big files across the globe, allowing others to recode
easily?
How would this work?
Honestly, I don't know.
I mean, it certainly will allow you to share files as images and it will definitely allow
you to have environments set up like data science environments that could analyze those.
But what are your thoughts?
I think we could do some of that now.
So I'm through hub being able to just Docker push and Docker pull is very powerful.
Right.
You can get a whole disk image, let's say.
Right.
Because instead of getting just the Docker file, you got to build, you get the result, which
could have had files copied in locally and all set up in the file system internally.
Right.
Yeah.
So two ways to share with just the Docker file and say, hey, build this yourself or I've
built it.
Here you go.
Right.
Yeah.
I would love to hear, you know, reach out to me on Twitter or something.
Right.
And let me know.
I'd love to hear more of what you're trying to do.
And because that sounds interesting.
Right.
Yeah.
Bandwidth is interesting too around the world.
Right.
So, you know, I sit here in Austin where, you know, high speed internet.
Well, really the rest of the world doesn't have that.
Right.
So low bandwidth.
And, you know, of course I got a screaming desktop laptop.
Right.
That I use in fast and not, you know, the whole world doesn't have those advantages.
So, you know, and if I'm pulling down a Mongo, some image, right.
And I'm picking on Mongo all the time, but you know, if it's, if it's over a gig, that's,
that's big, right.
That it'll take a while on some network.
So yeah.
Yeah.
All the video and video courses and audio processing and file exchange.
I've had to buy unlimited data from Comcast because I was going over my 1.2 terabyte per
month data caps every month.
That was ridiculous.
Yeah.
So a lot, a lot of data these days.
All right.
Well, you know, fantastic stuff you guys have coming up there.
I guess maybe we should probably wrap it up just for the sake of time, but yeah, I guess
we'll, we'll hit the, the two final questions I always ask.
First of all, notable PyPI package.
This is like something interesting that you ran across.
Maybe you want to just share people that find useful, some Python library.
I love testing.
So test containers.python.
That's a little inside joke that no one on here really knows, but I have, I have developer
friends.
So I will, one of my favorite things to argue against is testing just as a thought experiment,
but it's, it's really fun.
Right.
But anyways, but don't listen to me.
Testing is super important.
Right.
And being able to test in containers and pick off these prebuilt containers and use right
in your, in your app, right in your code is super powerful, extremely powerful.
So definitely interested in test containers.
Yeah.
It's super cool.
It lets you basically create a with block that says with my SQL container as my SQL or with
my MongoDB and DB container as that.
And it just fires up a Docker container.
You do your tests within that thing and maybe use a high test fixture to preload the test
data, then run your code against it.
So instead of mocking out the database and mocking out Redis, you just run a test Redis
and then throw it away, which I think that's fantastic.
It's like hybrid between integration tests and unit tests, isolation type stuff.
It goes back to our earlier conversations around reproducibility, right?
Yeah.
Having same environments are very important, right?
Yeah, absolutely.
And then final question, if you're going to write some code, what editor do you use these
days?
If you would have asked me that about two years ago, it would have been Sublime.
Been in a plain text editor, you know, back and forth, alt tabbing and back and forth
between my terminal.
But now I've fallen in love with VS Code.
Yeah.
It's extremely powerful.
So I feel like Sublime, like so many of the people who love Sublime have just naturally
moved to VS Code.
I mean, Sublime was really cool.
It just had all these like weird community stuff.
Like there was Sublime and then Sublime 3 and there was like permanently in beta and like,
are these getting updated?
Which one is like the real thing?
It's just, it was always kind of a little unclear where it was going.
And then, you know, VS Code came along with a similar model and just said, well, why don't
we put a hundred people just like constantly adding features to this?
Yeah, exactly.
I don't know what the number is, but it's high.
Yeah.
And it's interesting you say that because I was a long time Sublime.
I bought it, right?
And purchased it forever.
And yeah, it was like two or three and I have a theme over here, but it doesn't work in three.
And how do you get it?
It was just weird.
And then VS Code just kind of snuck in and I said, yeah, I'm going to use it.
I'm going to use it.
And now I keep just using, I use it as a text editor back then, right?
And now I just keep using more and more features, plugins.
I mean, the ecosystem around that is so powerful.
There's neat stuff.
And especially there's a lot of neat Docker things going on in it.
Yeah.
I'm going to run my VS Code in a Docker and then run, you know, dev containers.
And it'll be like Inception.
It'll be Docker.
Yeah, a little Inception.
Docker VS Code all the way down.
All right.
You got a moment for a couple more audience questions before we wrap it up?
Absolutely.
You know me.
I'll chat away for days, but I know your audience might get bored.
All right.
So Brian Sands out there.
Hey, Brian says, do you know of any good examples using Docker Compose with Postgres for persistent
local storage?
I have a hard time finding up-to-date working info to do this properly.
Yeah.
Check out Awesome Compose.
So it's a GitHub repo.
Docker owns it.
So Awesome-Compose.
I can't remember if it was under the Docker organization or not, but there's a ton of different
kind of configurations with different stacks.
That's super interesting.
I had no idea about this.
Good question, Brian.
Yeah.
Thank you, Brian.
I paid him.
I'll send you that.
I'll Venmo you here in a minute.
No, but yeah, check that out.
If you can't get your specific stack, you're going to get something very close, right?
So there's Flask in there.
There's Nginx like Flask and Postgres, different kind of three-tiered stacks.
And then within that, you'll have Docker files.
And then you'll have a Compose file to kind of bring it all together.
And you should get some really great examples in there.
If not, please do hit me up on Twitter and I'll get you pointed in the right direction
for sure.
Yeah, very cool.
Awesome.
And then Tino asks, what is the current state of Windows-based Docker containers?
I know there's Nanostrip.
I got to tread lightly on this one.
You know, I was super excited when Microsoft, when we started supporting it for Windows containers.
You know, the focus has been not as much.
The amount of people actually using Windows containers is very, very small compared to Unix-based
containers.
So, you know, just because of that, the focus has not been on that.
There's still a thing.
They're still being developed on.
They're just not as prominent in the industry for whatever reason, especially with .NET.
Well, you know where I would say they probably, as is standard with Microsoft these days,
their focus seems to be if it runs on Azure, we love it, right?
This is where we will sacrifice many, many of the things so that it will run on Azure.
And a lot of that, I believe, is check this thing in Windows and like say Visual Studio
Code so I can push deploy to run on Docker on Azure.
Yep.
I think that's probably where a lot of it is.
Yeah.
And WSL2 is huge, right?
So talking to the Microsoft folks, right?
They want to be the place where you come.
The Windows platform is the place you come for developing, right?
So whether you're a Windows developer or Linux developer, right?
You're using VS Code.
You're running on Windows.
You're using WSL2 for Unix development or you're using Windows for Windows development.
That's their thought, right?
So the underlying platforms kind of change and with containers, they can do some of that.
So they're focusing a lot on WSL2, which is super powerful.
Right.
Which really just means make WSL2 good so that it runs on Ubuntu or something like that,
right?
I mean, we just leverage that Ubuntu Docker support, I suspect.
Yeah.
While we're talking platforms, I've been doing basically nothing but M1 stuff these
days.
Since mid-December, I thought I would, you know, I got my Mac mini M1 and I thought I'd be juggling
this would work here, that would work there.
And I just literally have just turned off my laptop and just do this.
And I love it.
What's the story of Docker and M1?
Yeah.
So we love Apple.
It was nice to see our little, I don't know if you saw an Apple's keynote, you know,
where you saw the Docker desktop on there, which was super cool.
We're getting very, very close to shipping, you know, a release.
Okay.
A GA.
Yeah.
I mean, really close.
I don't want to give a date or anything, but really close.
But you know, tomorrow?
Yeah.
Tomorrow will be okay.
We'll do that.
I'll take it.
Very, very close.
They're working on it.
It's one of our primary feature sets to finish, to get done, right?
And again, it came from the community.
It was our number one issue, right?
When the M1s dropped, you know, I think everybody jumped into our GitHub issue and said, we need
support.
I think this whole M1 stuff has come out way stronger than I expected.
I thought, oh, that'll be kind of a neat, who knows what they're doing.
But like, as it came out, it's like, wow, this is really transformative in some ways.
Yeah.
You can get the tech preview.
It's pretty stable right now.
You know, it's just going to be on probably, you know, one-off little issues on your environment,
how you run containers and what exactly, what container, you know, because they got to be
compiled for the different lines.
It's got to basically be an ARM image.
Yeah.
And sometimes you run ARM, but then, you know, Mongo doesn't have an ARM version yet.
So you're running an emulation and, you know, so there's those type of things.
We're very, very close to releasing GA.
Stay tuned.
Next couple of weeks, I would say.
Yeah.
Fantastic.
And shout out to the MongoDB people.
Where's your M1 version?
Come on.
All right.
Final question.
We're going to wrap it up.
Ricardo says, networking on Docker feels like it's easier with LXC, one of the other container
styles.
Am I doing something wrong?
I'm interested in giving a container-in-zone IP address.
Peter, this is you.
I have no idea.
Yeah.
Ricardo, I thought I was going to get out of here without any networking questions.
But Ricardo, you are not alone.
Networking in containers is difficult, right?
You got to deal with different networking technologies, even locally.
So yeah, it's not easy.
Is this easier in something like Swarm or Kubernetes or something else that maybe controls them more?
No, it gets even more complicated.
Okay.
Yeah.
Once you step outside of, if you have cloud-native apps, right?
And I'm not a huge fan of that term because what the heck does that mean?
But if you don't-
I want to permanently pay to run my app forever.
Thank you.
Yeah, exactly.
But yeah.
So if you're in microservices, you're using configuration outside of your app to control
your app, right?
Is the best.
But I see a lot of legacy apps.
I'll do legacy in double quotes also, right?
Because just meaning not more microservice type apps, right?
And so you're trying to run those apps inside of containers and they have unique networking
needs, unique volume needs, right?
They're still writing to disk and reading from disk and you can't control that without changing
code or they have IP addresses or subnets kind of hardwired in, right?
And you can't do a lot of that.
So you got to configure your networking around your app with inside a container and that's where
the complexity comes in.
So in this scenario, giving your container its own IP address, it's a little bit against
best practices, right?
So containers should be ephemeral.
They should go away, right?
You should think of them.
And I got to get a better analogy.
My apologies to anybody if this offends you, but we used to think of our VMs as pets, right?
And we take care of them, keep them up and love them and hope they live forever, right?
Configure them.
And then now you have containers, which are more like, let's say, I used to say cattle, but
I'm more that offends people.
So let's say consumable foods, right?
You know, like you get-
Fungible elements.
Yeah.
So you get more like a cake, right?
If I get cake in my house, I'm eating that, right?
And it's gone.
And then if I want new cake, I got to put new cake, right?
So same with containers.
It goes bad.
You don't try to rehabilitate it.
You just get new cake.
Right, right.
Yeah.
But you don't eat half the cake and then bake, you know, put another bake the half.
This analogy is going poor, but-
Speak for yourself.
We refill our cake.
We don't ever want to go down to zero cake.
Right.
But that's the idea.
So if you're assigning an IP to a container, that container goes away, right?
And the idea is if I'm orchestrating that I have multiple containers all running, they
shouldn't have the same IP, right?
If one goes away, one comes back up, you don't want to, you know, so those are the type of
things you're getting into.
And Ricardo, you're probably shaking your head going, yes, but, but, but, but, but, and I
totally-
But I need it.
Yeah.
I totally understand.
And you can do it, but it's just a little more complex.
Yeah.
A little hard to answer on, you know, with a couple of minutes here, but-
Yeah.
I hit you up on Twitter.
All right.
So thank you so much for being here, Peter.
It's super interesting.
Final call to action.
People want to get started maybe making Docker more of their life.
What do they do?
Definitely go hit me up on Twitter.
Say hello.
Love to talk to folks.
Join our community.
Jump into community Slack.
If you're, questions like that, Ricardo, the community's there.
They'll be very, very helpful.
A lot of our engineers, our developers are in there.
All of our PMs are in there.
Ton of captains are in there.
Docker captains are in there.
And they're very, very helpful.
So this is a great way to get plugged into the community.
And then the last thing is DockerCon is coming up here in the May.
Sign up for DockerCon.
It's going to be an online live event.
Last year, we had 80,000 registrants, a really, really big show.
So you're not going to want to miss a great content coming.
You get to see more of my smiley face.
And then CFP is still open.
We're getting ready to close it on the 15th.
So if you ever thought about giving a talk, right?
Please submit.
If you're a first-time speaker, don't let that deter you, right?
DockerCon is traditionally a pretty big conference and well-attended, right?
And it might, you know, first-time speakers might not submit.
Please do.
We do read all of them.
And we do take an account, you know, what you've done in the past.
But we also do look for new speakers, right?
A hundred percent.
Don't let that deter you, for sure.
All right.
Fantastic.
Well, thanks for taking the time, Peter.
It's been great to chat with you about this.
Yeah.
Hey, thanks for having me on.
Really enjoyed it.
You bet.
See you later.
All right, bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Peter McKee, and it's been brought to you by Datadog and
us over at Talk Python Training.
Datadog gives you visibility into the whole system running your code.
Visit talkpython.fm/datadog and see what you've been missing.
Don't throw in a free t-shirt with your free trial.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like this.
Like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the
direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to
subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Bye.
you
Thank you.