It's time to jump into the brave new world of containers and Docker with Patrick Shanizen.
This is Talk Python to Me, episode number nine, recorded Monday, May 4th, 2015.
Hello.
And 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 talkpythontome.com.
This episode, we'll be talking with Patrick Shanizen about Docker.
Before we get to Patrick, I'm really excited to tell you that this episode is brought to
you by Codeship.
Codeship is a platform for continuous integration and continuous delivery as a service.
Please take a moment to check them out at codeship.com or follow them on Twitter, where they're
at Codeship.
Now, let me introduce Patrick.
Patrick Shanizen is a member of the technical staff at Docker Inc.
He helps build Docker, an open platform for distributed applications for developers and sysadmins.
Patrick is a software developer and storyteller.
He has spent 10 years building platforms at Netscape and Sun, 10 more evangelizing platforms
at Google, VMware, and Microsoft.
His main professional interest is in building and kickstarting the network effects for these
wondrous two-sided markets called platforms.
He worked on platforms for portals, ads, commerce, social, web, distributed apps, and of course,
the cloud.
Patrick, welcome to the show.
Hey, Michael.
Thanks for having me.
Hey, I'm really glad that you're here, and I'm super excited to have Docker on the show.
Ever since I learned about Docker, there's a few times I've learned about some technology,
and it has completely taken over me, and somehow I'm obsessed to learn it.
And when I figured, when I came across Docker, when you guys announced it, I don't know, was
it a year ago?
Two years, about two years ago, right?
Yeah, I came across it, and I'm just, oh my gosh, I need to learn this.
I need to understand this, because this is going to be huge.
And I really think Docker and these container technologies are going to change the way we
build and deliver software.
So let's start with telling the world, what is Docker, for those who don't know?
Sure.
So Docker is an open source project that was announced by Solomon Haidt, the founder of
.cloud and Docker, two years ago at PyCon.
So it's relevant for Python developers, because it all started at PyCon.
And so Solomon and his team were building this platform as a service called .cloud, and they
were struggling with that option.
It's a time when, at that time I was at Google, I was doing a Google App Engine.
There was Heroku, who's been bought by Salesforce.
And so .cloud had trouble attracting developers to their platform as a service, which allowed
you to deploy applications in PHP, Python, and multiple languages.
Well, at the time, a platform like Google App Engine, for example, was limited to Python
and Java as runtimes, and Go as well.
And so they were struggling with adoption, but they had this gem inside of .cloud that they
were using to build their platform as a service that was called Docker.
And that was an easy way to package and distribute, build, ship, and run Linux containers.
And so they open-sourced the project at PyCon two years ago.
And then it took the world by storm.
Like all developers starting adopting it.
And the whole industry restructured around that notion of Linux container.
So Docker essentially is a set of tools that allow you to build, ship, and run distributed applications based on Linux containers.
So there's the Docker command line, which is at the same time, it's a unique binary that has a client and a daemon.
And the daemon lets you get images for containers on your local machine or on a server and run them in a Linux container, like isolated from other workloads on that machine.
So you can have your own file system, your own users, your own network namespace.
And so Docker is based on Linux namespaces and C groups.
And then you have Docker machine that lets you provision machines running the Docker engine on any cloud provider, like Google, Amazon, Microsoft, but also locally on your machine on VMware, VirtualBox, or Hyper-V.
So Docker itself, Docker machine to provision the machines.
Then there's another project called Docker Compose that allows you to assemble all these containers that you're using to build your microservices into a single unit that you can run on your laptop for development or ship to the cloud as a single unit.
So typically you would have, for your typical Python app, maybe you're using Django or Flask.
You would have one container that has Django, your Django application with its code in it.
And you would link that to another container that has Redis on MySQL.
And then you can start all this with a single command, Docker Compose.
So you can, with Docker Compose, you can just start.
Yes, exactly.
So in Docker Compose, you say, I have my image for my Django app.
Let's call it like, let's call it like, my Django app.
I want to launch that with port 80 on the machine, on the server on which it's running, mapped to port 8080, maybe internally, where I'm running it.
And then I want to tie that to a Redis instance that's using the Docker image Redis that's on Docker Hub.
And then inside of my code, I'm just going to refer to Redis and automatically it will just tie that to the other container that's running.
CodeChip is a hosted continuous delivery service focused on speed, security, and customizability.
You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed.
CodeChip supports your GitHub and Bitbucket projects.
You can get started with CodeChip's free plan today.
Should you decide to go with a premium plan, Talk Python listeners can save 20% off any plan for the next three months by using the code TALKPython.
All caps, no spaces.
Check them out at CodeChip.com and tell them thanks for sponsoring the show on Twitter where they're at CodeChip.
So before we get into the details of how we run all that, you know, it's interesting that Docker kind of grew out of what was supposed to be kind of a larger project, right?
Yeah.
A platform as a service company, if you will.
It was just, it was just, that was how you guys were trying to internally achieve greater density for your hosting.
Yeah, that's exactly right.
And the notion of running Linux containers has been around for a really long time.
Or actually containers themselves have been around for a long time with three BSD gels.
In the, like, 2005, there was already the notion of Solaris containers in Solaris.
So that notion of containers existing for a long time.
And that's the way Google is running its workloads inside of Google data centers, using Linux containers for isolation in order to be able to run workloads with a very high density,
because it's using Linux or operating system virtualization.
So that's a super important difference or distinction to make between these containers and virtual machines.
So if I create a virtual machine, maybe it's a couple of gigs for the file system and the operating system and all my data and everything I've done to it.
Maybe it uses two gigs of RAM when I start and stop it.
It's got to boot up like a regular machine.
You know, it's a big blocky thing.
How big are these Docker containers?
Yeah, they can.
So Docker containers compared to virtual machines can be much smaller.
They can be big as well, but usually they're much smaller.
And another advantage they have over VMs is that the image format for Docker images, they are layered.
So you build a layer, you can say, oh, I'm going to inherit from the Ubuntu layer, and then I'm going to install Python on that.
And then I'm going to use pip to install my requirements on that.
Each of these instructions generates a different layer, and when you're using the Docker pool to pull the image or Docker run to run that image,
what it's doing is that it's looking in its local cache to see, oh, hey, I have Ubuntu already in there.
So I'm just going to download the image that adds Python to it and then the one with the requirements for my app.
So there's an additional density in terms of storage as well that goes with it.
While when you're packaging your app for a VM, you're just building that monolithic VM image with everything from the version of Linux or Windows that you're running in there,
the full operating system, plus your application code and packaging, and every VM you start has all these data.
While if you're running like 10 different Python applications package as a container on one host,
you would have one time the data for the Ubuntu VM, that's your base, and then maybe one layer for Python,
and then small layers 10 times for the requirements and the code base for your Python application.
So the images are lighter.
And what that means is that they download much faster.
Another aspect is that at runtime, it's much faster.
So starting a container, once your image is cached locally, just take like a few milliseconds.
While, as you know, to start a VM, it takes a good 20 to 30 seconds in good cases.
Yeah, that's really amazing.
And I like the layering concept.
So every layer you add brings you closer and closer to the specific type of operating system and environment you need for your app.
So at first, it's just Linux, and that could be anything.
Yeah.
And then it's Linux plus your version of Python.
And so it's a little closer.
And then maybe it's that plus Nginx.
And then it's a little closer.
And then it's that version of Linux plus Python plus Nginx plus all the packages your web app depends upon.
And then finally, maybe it's your code.
And so you can use every one of those layers as a building block to create new ones and things like that, right?
Yeah, it's very composable.
So once you have created your base layer, anybody in your team or if you make it public on Docker Hub can inherit from that and add their own stuff.
Or you can go up in the chain of inheritance of layers and say, oh, I don't like the official Python layer.
I'm going to see what operating system they're using to run it, and maybe I'm going to create my own.
So you can branch off at any time.
It's a very flexible system that gives you total flexibility.
And at the same time, to me, the big differentiation is that the speed aspect to it, the fact that downloading images is much faster because images are layered.
And starting a container is like 10 times or maybe 100 times faster, depending on the cases.
When you make things faster, usually it changes the experience.
And that's what developers found or realized when they start.
When a developer starts to use Docker, usually they have this aha moment.
Oh, then I can build all the time and create my own images and start breaking my application that was monolithic into smaller microservices that are easier to compose with something like Docker Compose.
So it goes hand in hand with two big shifts in software engineering that happened in the past five years.
One of them is microservices.
One of them is microservices, the fact of breaking up your application into smaller services that can be scaled and developed independently.
And the other one is DevOps, where dev teams and ops teams are working together with continuous integration and continuous delivery using the same tools to achieve continuous delivery of their application.
And so the container is a really nice unit of collaboration between devs and ops.
I think you're right that the size makes that really even possible to some degree.
So let me give you my mental model for the DevOps story.
And maybe you can tell me how I have that slightly wrong or improve on it or whatever.
So in my mind, I'm thinking there's some developers building their app and probably they have some kind of continuous integration set up where they check in, some automated build happens, some test run, stuff like that.
So I could build instead of just running my code directly, checking in and running my test directly on the, say, the build server.
I could create a container.
And when I do a check in, the build server could actually create one of these containers, push my code into it, run that code in that actual container environment.
And if I'm happy, maybe I could automatically push that out to some cloud provider.
And the thing that's actually running is the thing I tested and built locally.
Yeah.
So there's no sort of environmental differences or anything like that.
It's just that is the thing.
I can actually ship almost the infrastructure.
Yeah.
I think you got it right.
One of the things I would add is that this kind of factoring out of applications into microservices works really well for people who follow the 12-factor app manifesto that Heroku published a few years ago
where you try to build your apps as stateless as possible.
You run data services in a centralized way.
And then you configure the connectivity between different microservices with environment variables.
And so typically what would happen is that you would run locally as a developer on a single box with a test MySQL container
that has a volume attached with test data in there.
And then when you just got pushed to a build server, the build server deploys that into a cloud QA environment where automated tests are deployed.
And then there the container would be tied to a test MySQL database that maybe is maintained by operations.
So this is where the split between dev and operations happens where the devs specify all the requirements that they have for their app in the container.
And then the ops are providing the right plugs to the right services in different environments.
And then eventually you would push that to production where typically there would be someone, a sysadmin, that would decide, hey, this build is ready to go to production.
I'm just going to trigger the fact that in production the image is going to be pulled.
It's the same image that I had on my dev box.
But there it's configured to go to my production MySQL cluster.
That's really amazing.
So how do I deal with persistent data?
You know, I've got this.
Let's say I create one of these Docker containers that contains like MongoDB.
MongoDB has to have a data store somewhere on the file system.
How do I kind of deal with inversion that?
Is that actually in the container?
Is that somewhere else?
How do I, you know, if the database schema changes as the new container comes up, what do I do?
That seems a little tricky.
Yeah, yeah, yeah.
Definitely.
So Docker has this notion of values where in your container you can mount a directory that is on your host machine.
And this is where you would keep the data.
And typically there's also another notion that is called a data container where you just launch a container that just has a volume attached to it.
And then you mount the volumes from that container into your runtime container.
And then changing database like from development to production would just be a matter of changing the volume of the container you're mounting your volume from.
So that's the notion of volume that lets you have persistent containers.
There's one issue with it in Docker today that lots of people are running into when they try to deploy in clusters, which is volumes can be attached only for local file systems, on the engine on which you are triggered, on the host on which you are triggered.
And there's a company called cluster HQ, which is building an add-on to Docker called Fluckr.
We're working with them to make it a plugin, like a real plugin in Docker.
So there's work underway to make that happen right now.
And what Fluckr is doing is that they're addressing this issue of moving persistent container from one host to another.
If you're deploying in a large orchestrated Docker setup, where when the orchestrator tells the engine, hey, I want to move that Docker engine that is tied to your,
Docker container that has a persistent volume from host A to host B, what they're doing is that they're using ZFS under the hood,
and they're doing a ZFS snapshot, which are pretty fast.
Then they're moving the snapshot to the other machine that can take a few hours.
And once the snapshot is moved, they can start your server, take a diff of the snapshot and push it on the other side, which is faster.
And then they restart your container on the other side.
That sounds really helpful because it seems like there's a lot of complexity, more and more containers that get involved,
a more horizontal scale that gets in there.
Yeah.
Container persistence is really an interesting issue where there's lots of research right now and lots of companies looking into that and how to enable this.
Excellent.
So you've spoken a little bit about Docker Hub.
Can you tell the listeners what that is?
Yeah, definitely.
So Docker itself is a client and a demon that's running either on your local machine or on your server.
But what you're building with the Docker client is an image of the system on which you're running.
Once your image is ready, typically you would push it to Docker Hub, which is a hosted service by Docker.
So it's software as a service.
It's a hosted service that Docker, that lets you share your images either with the world.
You can make your image public.
And there are lots of open source and community images in there.
Or you can host them privately.
So Docker Hub is free for public images.
But if you want a private image, you can buy a subscription that allows you to have several private images for your own projects.
And then your colleague can just download the images from the hub as well.
And it's integrated with Docker client.
We also have a version that's called Docker Hub Enterprise.
That enterprises who want to adopt Docker for their internal workflow can install behind the firewall.
So they have complete control over the policies for the images that they're creating.
Right.
That makes sense.
You might not want to just go grab a bunch of public images and download them.
Is this actual source code or actual binary executables that I'm grabbing?
Or is there another way to get an image from Docker Hub?
So what you grab from Docker Hub, these images are actually tables that are gzip for each of the layers with a bunch of metadata explaining the Docker Engine how to reconstitute the image of your operating system.
Okay, excellent.
So it might tell me how to install Nginx or how to install Python 3 or something like that.
Yeah, exactly.
So we host official Docker images for many open source projects.
So for example, for Python, there's an excellent...
I used to take images from the community initially.
And then I switched to the official image, which is called Python.
And so in order to run Python in Docker, you just say Docker run Python.
Eventually, you could qualify that to say if you want Python 2 or Python 3.
Or there are labels on these images that let you specify a more fine-grained version of Python.
And once you run the image, it comes with a...
I don't remember which flavor of Linux.
And then Python all installed with the tools for developing there or for running Python workloads.
That sounds like a really easy way to get started for the Python developers.
That's cool.
Yeah, and that's one of the things that I love.
So I joined Docker just two months ago.
Before that, I was at Microsoft where my role as part of the developer experience team
was to bring all the Docker partner ecosystem on Azure.
And so as part of doing that, I built a bunch of tools to deploy clusters on Azure.
And the tool I built for that was in Python.
And I interacted with lots of startups using Python.
And when I started talking about my tools to other Microsoft people and I started giving trainings about that,
these guys were on Windows.
They didn't have Python installed.
They said, how do I run that script?
And in order to make that easier, I just bundled all my script in a Docker image.
And I just told them, hey, you just run that image and you'll have Python 2 installed,
all the requirements for the tool that I built, like the Azure Python SDK, all pre-installed.
And you don't need to install anything.
It's just a Docker run away from running.
That's really cool.
It sounds like an interesting world to live in, working with a lot of the Windows stuff.
And actually, one of the things I'd kind of like to talk about in a minute is the Docker view from different operating systems.
I mean, if I'm on Linux, it makes perfect sense.
It's kind of like a Linux thing.
I can run Docker right on Ubuntu, things like that.
Yeah.
But if I'm on, say, let's say, on my Mac, what do I do there?
Yeah, so on a Mac, you can download an installer from docker.com.
So we always release all our versions on Linux, Mac, and Windows.
And so you download that installer and what it's doing because the engine relies on primitives in the Linux kernel.
It needs to run on Linux.
And so we have this tool that's downloaded as part of the installer that's called Boot2Docker
that starts behind the scene a VirtualBox VM running Linux where the engine is installed.
And then you run the client on your Mac, and your client is targeting that VirtualBox instance.
And then by changing the environment variables, you can just target, instead of targeting your local machine,
your local VirtualBox instance on your Mac, you can target a box in Azure or Google Compute Engine or Amazon.
So that's pretty easy.
Yeah, in terms of operating system, one of the things that I'm super happy about that happened,
that was launched a few weeks ago and that was announced at the build,
conference last week from Microsoft, that Microsoft really bet heavily on Docker.
And what they've done is that they have contributed a lot of code to Docker so that now the Docker client runs on Windows.
So you can run the Docker client and then target Linux machines.
You can use Boot2Docker on Windows as well.
So you can run your Linux workloads on Windows with that and develop.
That's cool.
So that kind of puts it on par with OS X maybe.
Yeah, exactly.
Puts it on par with OS X.
But they're going to run the Docker client.
So that's cool.
So that's really a big news.
So Microsoft likes the Docker workflow for devs and ops so much that they wanted to give that to Windows developers and Windows sysadmins.
So they modified Windows server to have the same isolation primitive that exists in Linux.
And then they implemented the Docker daemon in terms of that.
So that's not out yet.
They just gave a demo last week.
But it's going to shift with the next version of Windows server.
And there will be a preview this summer.
So that means that you'll be able to develop .NET applications running on Windows server inside of Docker containers.
Which means that for developers and sysadmins in enterprise who are typically working half and half with Java and .NET,
they'll be able to just deploy or to build their microservices in the technology that fits the best.
Yeah, that's really cool.
I'm glad you brought that up.
I was watching the Build conference last week as well.
And just for the listeners, because of time shifting, we're recording on Monday, May 4th.
And Build, I think this was announced last Wednesday, so four or five days ago.
And one of the very first things they announced at the entire conference was your CEO, Ben Golub, coming out and saying, you know, from Docker, saying,
look, we're working with Microsoft doing amazing things.
And we started out maybe trying to bring it on par with OS X.
But the Microsoft guys wanted to go even farther and actually add features to Windows, the OS,
that would allow it to have containers for its operating system and its processes.
Because until this moment, there was no possibility of something like Docker on Windows for Windows apps.
Yeah, yeah, it's pretty incredible.
So, I mean, to me, that means like now we have the two major operating systems that run software and the servers in the data centers,
both supporting containers, both working with Docker.
And that's a huge boost for you guys, right?
Yeah, yeah, it is.
It is definitely.
And I think it's very good for the Windows ecosystem as well, because it will bring them the same kind of tools that Linux developers and admins have been enjoying for a long time.
And it really allows for more dense workloads on your servers and in the data center.
Yeah, that's really cool.
So the DevOps story just gets way better over there, I think.
Yeah, exactly.
So I'd like to talk a little bit about Python with you.
But before we do, what do you think the future holds for Docker and containers?
Where are things going in this whole world?
Yeah, so we have DockerCon, which is our big conference that's happening in June.
And one of the things we've been working on, as I explained to you before, Docker takes care of a lot of aspects, but it still needs to mature in lots of areas.
And especially when people start putting it in production, there are lots of needs that are still unfulfilled by the tool.
So one of the big aspects that we've been working on recently is to make it pluggable.
So we're working on a plugin model with people like Weave, who are building virtual networking, or ClusterHQ, who are building portable volumes,
so that they can run as plugin in Docker Engine, and so that you would be able to define networks for your containers that span your own data center,
and maybe Azure and Google, or like two public clouds.
So that's on the Weave side, and on the ClusterHQ side, it's like moving volumes from one to the other.
We're also working on making sure Docker Machine lets you provision Docker daemons everywhere.
There's been lots of improvement to Docker Compose.
And also, one of the big topics that's happening right now is once you start building all your apps as microservices running in containers,
the next step is how do you orchestrate them?
And I have a whole deck on that that I'd send you where there's at least six or seven containers in that space.
Again, as I used to say, the whole industry reorganized around this.
Before, people were building platforms as a service, and that whole industry refocused towards orchestrating Docker containers.
So the unit now is the microservice package as a container.
And in the orchestrators, you have Docker Swarm, which is one from Docker itself.
So it's a native orchestration solution that works multi-cloud.
There's Kubernetes from Google that's inspired by what's running internally at Google, and that's open source.
There's Apache Mesos, done by Mesosphere.
And they're running in production in lots of different places.
They're coming from Twitter originally.
I think Netflix runs it as well.
And there are smaller players like DS or Tutum, which is running on Azure as well.
So there's lots of activity in that space of our Docker container orchestration.
Yeah, that seems like where the real challenges lie.
And if that gets easier and easier, then, you know, the sky's the limit.
So that's amazing.
Yeah, on the Docker side, we're trying to make the whole experience easier, like with machines,
like one command to provision new machines in different clouds.
And then it's integrated with Swarm.
So you can say, oh, I want all these machines to be in a single cluster.
And then with Docker Compose, you can say, oh, I want to, or there's the start of an integration
where you can say, my app that's composed of multiple services, please deploy that to that Swarm instance.
And then it will just provision it in the right place in the cluster where there's some room.
So we're really trying to make the experience much easier for developers and sysadmins.
Cool.
Yeah.
The more you guys encourage and make it easy to break our apps into small little services,
then the challenge becomes linking them together, right?
So it sounds like you're doing some great work there.
Fantastic.
Yeah.
And one advantage I will have to add that there is to this microservice approach and that Docker enables
is once you start breaking your app in microservices, you can start innovating in terms of what language
and platform you're using for each of the microservice.
So as opposed to being stuck, for example, with a Django app running in Python 2.7 and you made that choice
and there's some legacy code that cannot be ported to Python 3, you could say, oh, I just break my app in 10 different microservices
and for this microservice, I don't have any legacy.
I'm going to write it in Python 3.
And for the developers, it's just a matter of saying, oh, I'm inheriting from Python 3 as opposed to Python 2 when you're creating your image.
Oh, that's really neat.
So maybe it's a gateway for a little more flexibility in the technology to...
Yeah.
And I think especially for the Python community where that big gap between Python 2 and Python 3 developers happen,
I think this breaking up of large monolithic applications into smaller microservices where you have more freedom to test new stuff
may be a good way of introducing Python 3 to your environment.
For sure.
Do you see anything like that happening in the data side of things?
So, you know, if I'm using MySQL and relational databases in some big monolithic way,
like, could my different microservices be using, like, NoSQL, say, MongoDB or Redis here and there,
and then maybe one other part still using a relational database?
Oh, yeah.
I've seen a lot of that where people are starting...
Once your microservices...
Your microservice has a smaller footprint and, like, a single functional goal,
then it's easier to say, oh, I'm going to back that up with Redis or MongoDB
as opposed to storing everything in MySQL
because maybe I'm building an e-commerce application and I need the relational aspect for parts of it,
but maybe for, like, tracking referrals or the social media aspect of how people are tweeting about products on my website,
maybe these small services can use different types of databases or data backends.
Yeah, that seems like a perfect way to choose the right database, the right job there.
Cool.
So you guys, do you use Python internally?
You know, obviously you can run Python in Docker containers really well,
but do you guys use it as a language for yourself?
Actually, we do.
Not everybody.
So Docker itself is written in Go as well as Docker Machine and Swarm.
But Docker Compose is actually written in Python, so it's a Python project.
Nice.
And how's that?
People are pretty happy with Python internally?
Yeah, and I think they even tried to call it to Go at some point,
but then they said, hey, we have high velocity with Python,
we have a code base that people understand well, so let's stick with that.
So I think Compose for now will stay in Python,
and the developers who are working on it are pretty happy with it.
Yeah, that's really cool.
So if, you know, I'm a listener and I'm out there hearing this,
and I'm like, this is awesome, I have to get started.
What do I do?
How do I get started?
Yeah, to get started, you go to docker.com.
We have lots of tutorials.
If you're on a Mac, you just download Docker for Mac, for Linux.
Depending on the distro, either there are packages
or you can download the binaries directly.
And for Windows, there's an installer as well.
There's also another project you may want to take a look at,
that's called Ketmatic.
That one runs only on macOS, and it's a Docker client GUI.
So it shows you all the containers that you can find on Docker Hub,
and you can say, oh, just start this one,
launch a terminal where I can script it or connect to it,
and it shows you the logs, the volume that you have attached,
so you can go edit the files and all that.
So that's a very easy way to get started, Ketmatic, I would say.
And else?
Yeah, I have Ketmatic installed, and I enjoy it.
It's nice.
It's clean and works well.
Yeah, there's lots of stuff to add in there,
but it's really a good start, and it's very easy to get started.
Excellent.
So I think it's probably a place to call it a show, Patrick.
What else would you like to add while we've got a chance to talk to everyone?
I mean, thanks very much for the opportunity.
I really encourage Python developers to go take a look at that.
To me, one of the angles that's most interesting for Python developers
is giving you the portability for your customers to run your code anywhere
without having a complicated environment to set up.
As long as they have Docker, they can just start your app packaged as a container.
And the other angle that's, I think, pretty important
is starting to introduce Python 3 microservices into your app.
If all your apps are packaged as containers, it just doesn't matter.
You don't need to set up complicated environments.
It's just a change of the label in the from directive in your Docker file
to start using Python 3.
I am very excited about Docker and this whole container world.
And I appreciate you taking the time to share it with everyone.
Thanks, Michael.
You're welcome, Patrick.
Bye.
This has been another episode of Talk Python to Me.
Today's guest was Patrick Shanazin, and this episode has been sponsored by Codeship.
Please check them out at Codeship.com and thank them on Twitter via at Codeship.
Don't forget the discount code for listeners.
It's easy.
Talk Python, all caps, no spaces.
Remember, you can find the links from this show at talkpythontome.com
slash episodes slash show slash nine.
And if you're feeling generous, please check out our Patreon campaign
at patreon.com slash mkennedy to contribute and support the show.
And be sure to subscribe to the show.
Visit the website and choose subscribe in iTunes
or grab the episode RSS feed and drop it into your favorite podcatcher.
You'll find both at the footer of every page.
This is your host, Michael Kennedy.
Thanks for listening.
Bye.
first, develop first, develop first, develop first, develop first.
Developers, developers, developers, developers.
you
Thank you.