Containerless Django: Deploying without Docker
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44053 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 201833 / 50
2
5
7
8
13
18
20
21
22
35
41
44
45
47
00:00
System administratorInformation securityParity (mathematics)CodeRead-only memoryLogical constantComputer programmingMathematical optimizationSemiconductor memoryCodeSoftware developerWordServer (computing)Revision controlPhysical systemEntire functionNumberInformation securityMathematical optimizationStack (abstract data type)Operator (mathematics)BitQuicksortLibrary (computing)Product (business)Operating systemVirtual machineLoop (music)BuildingRight angleMetropolitan area networkMedical imagingSoftware frameworkInheritance (object-oriented programming)LeakHacker (term)Process (computing)PlanningCuboidInstance (computer science)Different (Kate Ryan album)Software bugPoint (geometry)State of matterCartesian coordinate systemComputing platformAnalytic continuationForcing (mathematics)Integrated development environmentContinuous integrationComputer programEvent horizonSystem administratorParity (mathematics)Regular graphUML
04:45
SoftwareShift operatorAsynchronous Transfer ModeBinary fileConfiguration spaceComputer fileCompilerCloningSineMereologyPauli exclusion principleMechanism designMenu (computing)SoftwareProjective planeSoftware developerBuildingWeb 2.0Server (computing)Binary codeComputer fileType theoryProduct (business)Virtual machinePhysical systemChainWeightMultiplication signConfiguration spaceState of matterSingle-precision floating-point format1 (number)MathematicsLibrary (computing)FreewareMereologyCodeFile systemProxy serverOperating systemIntegrated development environmentRevision controlStress (mechanics)Entire functionNumberQuicksortIdeal (ethics)Uniform resource locatorOperator (mathematics)File archiverAnalogyLine (geometry)AbstractionDeterminismNatural languageTwitterProcess (computing)Goodness of fitMedical imagingExtension (kinesiology)CausalitySinc functionScripting languagePicture archiving and communication systemCartesian coordinate systemReverse engineeringMobile appUML
13:03
Point (geometry)Computer fileTemplate (C++)Core dumpIntegrated development environmentConfiguration managementComputer configurationVariable (mathematics)Computer fileDeterminismDirectory serviceSet (mathematics)Installation artComputer configurationCodeServer (computing)Parameter (computer programming)Configuration spaceStatistical hypothesis testingMultiplicationIntegrated development environmentProjective planePoint (geometry)Functional (mathematics)WebsiteMobile appVideo game consoleScripting languageMultiplication signSystem administratorGastropod shellMereologyFunction (mathematics)Weißes RauschenState of matterLine (geometry)Fluid staticsCartesian coordinate systemLevel (video gaming)Template (C++)Type theoryProduct (business)DatabasePasswordRootKey (cryptography)Arithmetic meanBuildingExtension (kinesiology)Software repositoryDivisorRevision controlWeb 2.01 (number)Proper mapRow (database)Disk read-and-write headVariable (mathematics)Hacker (term)Digital rights managementSoftware developerLibrary (computing)Right angleCuboidQuicksortStandard deviationPiPauli exclusion principleException handlingUniform resource locatorModal logicMaizeDifferent (Kate Ryan album)GenderUML
21:26
Statistical hypothesis testingSystem programmingConfiguration spaceMobile appStatistical hypothesis testingLatent heatServer (computing)LastteilungUniform resource locatorComputer fileQuicksortFlagRevision controlFluid staticsMereologyInformation securityPhysical systemEntire functionRead-only memoryVariable (mathematics)Crash (computing)Projective planeConfiguration managementDirectory serviceIntegrated development environmentCartesian coordinate systemFile systemDynamical systemContinuous integrationBitProcess (computing)Negative numberSystem administratorCompilation albumGroup actionSet (mathematics)RootDatabaseMultiplication signPoint (geometry)Key (cryptography)Profil (magazine)Operator (mathematics)Game controllerData structureVideo gameSoftware developerMoment (mathematics)Message passingFile formatVector spaceVirtual machineSimilarity (geometry)Differential operatorSoftwareSlide rule1 (number)UsabilityINTEGRALCore dumpChemical equationGreen's functionSpherical capUML
29:48
Server (computing)Parity (mathematics)Integrated development environmentWindows RegistryCodeRun time (program lifecycle phase)Latent heatExtension (kinesiology)Service (economics)Software developerFunctional (mathematics)Virtual machineProduct (business)Case moddingPhysical systemRight angleServer (computing)Cartesian coordinate systemExtension (kinesiology)BitProjective planeCASE <Informatik>Digital rights managementContinuous integrationMultiplicationDifferent (Kate Ryan album)Point (geometry)Line (geometry)Figurate numberControl flowMobile appComputer fileWebsiteDirectory serviceSingle-precision floating-point formatScripting languageMultiplication signCache (computing)2 (number)Bootstrap aggregatingMoment (mathematics)Medical imagingNumberFormal languageComputer configurationComputing platformCodeWindows RegistryPerspective (visual)Latent heatHand fanGoogolScaling (geometry)Library (computing)Parity (mathematics)Installation artRevision controlFile archiverActive contour modelLambda calculusSlide rulePiProcess (computing)Beat (acoustics)Endliche ModelltheorieSound effectMetropolitan area networkShooting methodSystem callConfiguration spaceAnalytic continuationUniform resource locatorOrder (biology)Area
38:11
ComputerInternet service providerData typeXMLComputer animation
Transcript: English(auto-generated)
00:17
Thank you. So this is containerless Django deploying without Docker. I tried
00:24
to use some buzzwords here but really this is just like regular deployment but we're gonna try to do a little better. So real quick about me, I'm the founder at Lincoln Loop, we're a Django development agency, we've been
00:42
we do kind of full stack Django solution so everything from design to DevOps and that's primarily my role at the company these days. I've been doing it for a long time before that I was a sysadmin and I'm co-author of a book High Performance Django which is also has quite a bit about deploying Django
01:04
so I've done quite a bit of this. How many of you have seen Stranger Things or maybe not seen Stranger Things? Okay well I'm gonna make some references to Stranger Things in this talk. Halloween's coming up. I don't think I'll
01:23
make any major spoilers but I'll reference a few characters in it. So Docker is cool. I like Docker. Docker is kind of like this Steve Harrington guy, right? He's got like you know great hair, he's like the cool guy at school, drives a nice car. I feel like you know the kind of popular
01:41
opinion of Docker these days is the same, like it's great, it solves all your problems. And like I said, Docker is cool. One of the things I really like about it is this pipeline that it gives you. It kind of forces you into you write code on your machine, you check it in and your continuous integration system picks it up. It builds your image which you can then
02:04
test and push that image out to any number of servers in any different environment and you can be guaranteed that the thing you tested is the thing that you're running in that environment. It gives you some security right out of the box. So in the unfortunate event that you know hacker attacks your
02:23
system and gains access to your application in ways you don't want them to, it's very difficult for them to kind of leak outside of the container and do things to other services or systems. It also gives you isolation and beyond
02:41
that security isolation it gives you isolation from kind of having some sort of global state that you have to deal with. So when you're deploying lots of different services on a single instance you don't have to worry about conflicting versions of software, libraries, all that stuff. And it gives you this developer parity from development machine through to
03:03
production. So I know that the thing I run in development is the same thing that I run in development or in production. That's great. I like all these things about Docker. So Steve's over here like hey man just bundle the entire OS like all your problems are gonna go away right? Well not exactly.
03:21
You know this is a great solution if your platform as a service, if you're running hundreds or thousands of services absolutely like this is probably the right solution for you. But my guess is most of the people here are not in that scenario. You're deploying maybe one or a handful of services and maybe you know going to the point of bundling the entire
03:42
operating system is overboard for you. So that kind of leads into some of my philosophy when I'm building systems and I'll use a couple of quotes here to show I'm not like the only person that thinks this way. Mike Perham, he's a Ruby developer. He wrote Sidekick which is sort of
04:02
Ruby's version of Celery. He says no code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code and no code is easier to understand than no code. So the less code you run generally the better off you are. And this one is Henrik Jörteg, he's a
04:24
JavaScript developer and he says for an optimal programming experience constantly ask yourself do I really need all this crap? And I think it's important these days like we are bombarded with frameworks and new technologies and all this stuff and it's good to rather than just sort of adopt it willy-nilly take a step back and say like you know is this
04:43
what I really need? So Docker has its drawbacks as well. It's slow like you're you know downloading entire operating systems and uploading them and all this stuff you've got really big build artifacts and it takes time to ship those around you know build them and all that. When people say
05:06
Docker is lightweight it's not a lightweight solution like it's lightweight compared to running an entire server or compared to like a virtual machine like we used to run them but maybe not as lightweight as running something you know directly on a Linux system like we've done for
05:20
years. It creates all these extra abstractions so you know when you're running in Docker you've got now an extra network you have to handle and doing things like working with the file system can become more challenging so you don't get it for free and it's kind of the same philosophy I talked about
05:42
before more software more problems. Docker is about a million lines of Go code there's 3,000 open issues for it like you should not expect that it just runs flawlessly for you all the time and it's a it's an extra layer on top of what everybody has you know been running for years. So the cool guy
06:01
Steve like maybe he's not so cool maybe he goes in the parking lot and drops your friend's camera on the floor. How did we get here like you know like one of the things like we should kind of take a step back like if we're gonna look at things like why is Docker so popular and I would say one of the primary reasons is deployments kind of sucked like we didn't do them very
06:23
well. We had this issue for a long time where you know we use PIP and requirements files and we'd install stuff and then some sub-dependency of dependencies would change versions and everything would break. A lot of times
06:41
we're building software on a server that we also want to you know run it from so we had all these build tools and development packages that had to be installed there was like tons of opportunity for things to kind of go wrong or to kind of have deal with this global state and lack of isolation and conflicting versions of software. And today if you're building Django apps
07:05
there's a good chance you're probably touching node too. You might be using something like webpack to build your JavaScript files so now we've just like compounded the problem like not only do we have to deal with all the Python versions and all that but we also have to deal with node versions. If you
07:21
were doing ops work and you were trying to build stuff like this these things probably made you mad and frustrated at your developers that were throwing all these new tools at you. So if if we were kind of you know had these sucky deployments what is the ideal deployment? In my opinion it's this
07:40
you download a binary you create a configuration file that says how you want that binary to run in the given environment and you run it. And this type of software exists like traffic and telegraph those are services built with Go, nginx which I'm sure many familiar with web server reverse proxy
08:03
written in C. You can download a binary of these you can give them a configuration file and they run. And I think if all software worked like this or more software work like this that Docker would be you know would have a lot less popularity like I don't see a lot of benefit that it brings if we
08:22
had software like this. But Python is not C or Go. C and Go have really good stories for doing stuff like this. Python requires a virtual machine the Python virtual machine to run it you can't just run Python files without it.
08:40
It uses dynamic linking so your Python files may reference some library and it's expecting to find those libraries kind of in your global system. And packaging isn't straightforward there's no obvious solution to I want a single file that is my Django project or my Python project and I want to run it.
09:03
So in our stranger things analogy I would say Python's kind of like Jonathan Byers here he's you know this emo guy he's got a bowl cut he's you know confused about where he fits in like not nearly as sleek as Steve is.
09:21
And the question I've been kind of asking myself is you know can we do better than this like is there some sort of holy grail that that solves this solution for Python. I've wanted this for years I think ever since I saw somebody run you know Jenkins in a single download and you can like run Jenkins like how can we do that with Python. Will this be a terrible talk
09:46
if we couldn't do better we can do better and we already are like there's a lot of things that we're using every day that have improved the situation. So pipenv and poetry a lot of you probably maybe worked with pipenv or at least heard of it it's creating a lock file that is making
10:06
sure all our dependencies we remove that problem dependencies shifting underneath us with these tools we can guarantee a kind of deterministic build when I install a project on one machine I'm gonna get the same packages on another machine. Pre-compiled wheels exist for lots of popular libraries so
10:25
you know one of the problems was all these build and development tools that we needed just to install our project. Pillow the image manipulation library and psychopg2 binary are two really common ones that's the one you use to connect to Postgres so I can install these packages they have compiled C
10:44
extensions in them but I don't have to worry about it I don't have to build them I don't need the build toolchain on my machine to use them but there's still a lot of holes we still have this whole like assembling a virtualenv thing that we have to do we have to deal with the static files from our
11:03
Django application somehow and we need to have a production web server like we want to just download a single thing and run it it has to be a web server there's lots of projects out here or out there that that have kind of worked on
11:22
on this problem lots of people have the problem and want to solve it so I'm not gonna go through each one of these individually but these are all projects out there that are designed in some way to kind of create a pipeline with Python where you can build your software on one machine and then deploy it
11:40
elsewhere without needing to kind of build and assemble it pecs is an interesting one it's been around for a long time it's from Twitter and it uses this concept from Python called zip applications and I always tried away from pecs I had heard like it's slow it's cumbersome it's you know hard
12:03
to use whatever so it's it's not something I ever kind of saw as a viable solution but zip apps are interesting so zip applications there they've been part of Python since version 2.6 they're not dead they just got improved support in Python 3.5 and what they are is a way to create a
12:25
zip archive of Python files and then you can actually run the zip archive with Python it's it's kind of weird and crazy but it works so the big problem with zip applications is there's no way of handling dependencies so if I
12:42
want to run you know I can run my Python files without a problem but if I want to run Django there's no kind of way for me to pip install it well there's a new project out there called shiv and it is kind of a reimagination of pecs and it comes from it comes from LinkedIn and it's a way to
13:07
build these zip apps and include all the dependencies in them so you can then generate a single artifact which you can run through the pipeline build test deploy the common extension for zip apps is PYZ so I can create a zip
13:24
app and then execute it kind of like a binary you know I still need Python but other than that everything's included so can we teach Django to run as a zip app yes yes you can the first thing you need to do is make
13:47
sure your Django project is a proper Python package I would recommend doing this anyways it's in my opinion it's kind of best practice so it's very simple to do you just create a setup.py file you drop it in the root of
14:00
your repo and really there's only three things necessary here name version which you can set arbitrary it doesn't matter and packages setup tools includes this nice function called find packages and that will go out and find all your Python files and include them when it wants to distribute your
14:21
application the last one here is optional but I bring it up because we're gonna talk about it later your console scripts entry points console scripts this is how when you install Django the Django admin shell command works and it's basically a way of saying telling setup tools that when I
14:43
when you when somebody installs this create a script they can run that executes this Python function so with this I could instead distribute instead of creating a manage.py file I can basically do it with this line here in setup tools and it will create it for me when the project installs so the
15:02
next thing we need to deal with is templates or templates and static files that find packages command will get all of your Python files but it will gladly ignore all other types of files so we need to get our static files and templates the kind of simplest way to do this is to create
15:20
this manifest.in file it also goes in the root of your project and graft means take this directory and anything in it any sub directories all that so we would include our collected static files and our templates in that now we need a production web server you know if you're running a Django
15:44
application in a docker container you'd expect when you start your docker container that it serves web requests right so the common ones are our G unicorn and uwhiskey typically we use modwhiskey is also out there I'm
16:01
gonna say that Graham sitting in the front row but we want these to run from our entry point typically what we're doing when we deploy these is we start our web server and then we tell it to import our application and we want to kind of flip that on its head we want to start our application and tell
16:20
it to run the web server so you can do that you could also shiv provides a way that you can kind of dynamically swap the entry point when you start it up but feels like kind of a hack let's kind of pretend like it is this you know static binary so one option is G unicorn and white noise so white
16:42
noise you use to serve your static files in an efficient way and it's not too difficult to write your own management command which then starts G unicorn there's another option which we've released recently called Django pyuwhiskey so we've been working with the developer of uwhiskey when you
17:03
pip install uwhiskey you get a binary executable it's not a Python thing that you can work with so pyuwhiskey is a way you can build uwhiskey is a library and then import it in your Python code and run it so this includes that management command I was talking about so you can run manage.py
17:24
pyuwhiskey and you get a kind of production web server right out of the box pyuwhiskey is also distributed on pypi as a wheel so you don't have to worry about compiling it or anything like that it just you download it and
17:40
works and so with all those pieces in place now we can build our zip app what I'm gonna do is gonna look just like you would probably build any sort of Django site for the most part if you were using it in Docker or you know building it on your server or whatever I'm gonna use pipenv to install my
18:02
dependencies that way I get the benefit of that lock file and that deterministic build then I'm gonna do whatever I need to do to build my static files this is this is the part where you call webpack or Grunt or Parcel or whatever you're doing and make all that happen then I'm gonna run collect static get all those static files and collect them into a directory
18:23
and then I do the part with shiv so shiv you can just pip install it install shiv it's just Python and I'll explain these options here so dash o is output so I can tell it I want to create this file called your project
18:41
that pyz dash e is that entry point I talked about so it says when I run my project or your project that pyz this is the function I want you to call when this one's the one that managed.py uses site packages lets me include a pre-existing site packages directory so I can point to the one
19:04
that pipenv used when it installed my project I can also use this shiv except accepts most of the arguments that pip does so you can also pip install projects and they will or pip install apps and they'll end up in
19:21
your final zip app next is Python so I can I can say like if this gets executed just by itself pick up this Python it ends up as a shebang line like the first line you often see in a script you can also call it with Python as the first argument if I want to choose a specific Python and then the
19:43
last two the last line there is those are just standard pip arguments no depths says install my project but don't install it with any dependencies that I might have specified and then the dot is like the current working directory so that would be where my setup.py file is so that runs it
20:04
builds this zip app and I'm left with something like this so I can run my project pyz your project up pyz pyuwizgi and then I can pass it whatever arguments uwizgi accepts the only requirement here is that I have
20:21
Python installed everything else is in this zip app so the next part we need to figure out is configuration a lot of times you'll see people installing Django apps and then like mucking around with settings files or creating them dynamically and kind of injecting them into the project that won't work
20:42
with this with this solution you kind of have a frozen state of your your Python app so we want to run the same zip app but we want to run it in different environments we want to run it for our tests we want to run it in staging we want to run it in production so one option is multiple
21:03
settings files you have a bunch of settings files for all your different environments and you toggle them with the Django settings module environment variable I don't recommend this approach you still have to deal with secrets like database passwords and API keys and you don't want to put those into your project so this isn't a great option another option is
21:23
environment variables so this is kind of the 12 factor method of building apps you you created your application application and then you use environment variables to configure them that's a viable solution there's another one this is another project I've been working on with Chris Bevan as
21:42
well it's called good comp so what good comp does is it lets you define a set of variables that you might want to change and this isn't Django specific it's would work with any Python application and you so you create your your kind of configuration and it might be your database URL or your API
22:03
keys and that kind of thing and then you can define that in a JSON or yaml file some sort of structured format that's easy for a build tool or a configuration management system to pump out and then your Django app will pick up those files and read them one of the one of the things I really like about
22:23
this is it lets you document all those variables that you're using to configure your app which with environment variables that they kind of tend to get added willy-nilly and people don't ever you know know which ones are available and the other thing is this will fall back on environment
22:41
variables too so I can take my same project and run it you know the way I want to with with configuration file but I could also run it on Heroku or in Docker where environment variables are kind of preferred and I don't know if I mentioned this I think I skipped it but the other concern with environment
23:03
variables is it's really easy to leak them on accident you can have a you know a program crash and it dumps out your environment somewhere or child process runs and it now has access to your environment so by putting them in a file instead I would argue you get a little better security so now kind of
23:28
going back to this pipeline the Docker pipeline how do we replicate that with a zip app so you'd use a continuous integration system there's a
23:42
bitbucket get lab whatever you build your project that's that slide I showed you with pip em and collect static and all that just like you would with Docker and you're gonna run shiv which is going to generate your zip
24:00
app you'll run your tests against that so you'll have your tests built in as part of that so you can ensure again the thing you test is the exact same thing you deploy and then once your test pass you push it to some central location that could be Amazon s3 or you know wherever you can pull it down to deploy and now deployment just is download the thing and run it which is
24:27
awesome like your ops teams are gonna love you for you know simplifying their life and it's great for development teams too because they can kind of take full control over everything in the CI pipeline they you
24:41
know if you want to switch you were using grunt before and now you want to use webpack like you don't have to your developers can kind of manage that and they know the the only thing they have to churn out and end is this zip app to be deployed so zip apps like aren't looking so bad like
25:00
pythons looking a little better he's no longer the kind of awkward dude with the bowl cut right but that's not all Docker brings what about security so how do how do we get you know a similar sense of security here well system D's got your back on this one system D's awesome like if you are not
25:24
familiar with it definitely check it out it gets bad rap in the Linux community sometimes but it is on every modern Linux distro you know learn it use it love it so well I'll mention quick if you're not super familiar with
25:42
system D it's how all the services on your Linux machines start up and run and stop and restart and all that it manages that and the way you define a service is via service file and you tell it what command you want it to run and you can give it all sorts of other flags that tell it how you want it to
26:03
run so I'm gonna give you some that are gonna deal with security you drop these in your service file protect system strict that will make your entire file system read-only so you know right off the bat that's super
26:20
easy like now if some in the scenario we're protecting against here is some nefarious user has hacked your application and is now trying to run commands you know on your host system so we've now made the entire file system read-only they can't create any files or edit any files there's a protect home
26:43
equals true that just basically removes any home direct removes any access to any home directories so even if somebody has like bad permissions on their home directory like they can't access it dynamic user equals true so best practice is that you run each service as its own user that way one
27:02
service doesn't potentially gain access to things another service is doing usually you would you know create these users as you set up the services dynamic user equals true just tell system do you like hey do that for me like just create some user I don't care who it is and you know when the service is done you can remove it just capability bounding set so this is
27:25
probably familiar if some of you have used docker quite a bit this lets you determine the capabilities the kind of Linux capabilities that the process has access to the tilde means like negate it so this says my service
27:41
cannot do anything in the capsis admin group so that basically is removing like kind of root like abilities or anything the service is and there's a whole bunch of others too so I could create a app primer profile that gives you really really fine-grain permission control and there's these
28:02
which the system D docs recommend adding I'm not going to go through each one private temp is an interesting one that's like a attack vector you see sometimes where two services are both writing to a temp directory one service gets hacked and it starts reading what the other service is doing in the temp
28:20
directory and gains some sort of interesting thing it shouldn't through that so this will find out a private temp directory for every service another thing interesting I don't have time to talk about it but one of the kind of things that people really like about things like kubernetes is the
28:41
ability to do rolling deployments blue-green deployments where you have one version of your software running and you want to run a new version this typically been kind of a pain point for the Python community and that kind of reloading and getting the new service running as your project gets bigger it takes longer for you to start up your service and it's sort of difficult to
29:03
do that dance where you take one service down and bring the new one up without any downtime and sort of the common practice these days is managing that via your load balancer or something where you bring both both ends up you've got your your blue version your green version they're both running side by side for a moment once your new version kind of passes health
29:24
checks and is happy you drop your old one out and then you just point all your traffic to your new one if you're interested in it you can do this with systemd on a single machine without having to orchestrate and coordinate with load balancers or use something like kubernetes I don't have time to go into it but I'd be happy to kind of show somebody after the
29:47
isolation that was the other thing we mentioned was cool about Docker so how do we handle that I'll be frank it's not as good you still need to install Python globally if you were using Python packages that are referencing you
30:04
know libraries on the server there's a chance you may need to install those you don't need the development packages but you may need the library itself if you don't have these wheels built for for all your packages but that being said it's really easy to install multiple Python versions on a server if
30:23
you're using Ubuntu there's a personal package archive called dead snakes you can easily install three six three seven two seven whatever they'll all happily live side by side so yeah Dockers got better isolation but you know at the end of the day do you really need it especially if we're you
30:42
know kind of bundling our apps in this way and then how about parity what that was kind of the last thing on my original slide is you get this parity from your development sheet machine all the way to production in this scenario you're still gonna get it from your continuous integration system
31:01
all the way to production that's probably the important bit as far as locally you can use Docker it's a great use case for Docker to run image that's the same as your deployed machine or not like you know we have lots of developers that work on Macs and deploy to Linux and that's
31:23
generally you know something you can do these days without being terrified that you know the world's gonna break so pros and cons to this approach like hopefully I've showed you at this point like you can deploy a single file
31:42
Python project pros to this it's simpler you don't have to put Docker on your server you don't have to manage a Docker registry or pay somebody to manage one for you and you are now depending on about a million less lines of go code my guess is for most people when something breaks with
32:02
Docker it's like a oh crap moment like I have no way to debug this or deal with this on my own hopefully somebody else has dealt with this and I can google it you get smaller artifacts so we're not bundling the entire OS if you if you are building Docker images kind of naively it's not
32:25
uncommon to have a gig or two gig Docker images with this you're probably looking more at like 100 megs or something like that depends on your project because your artifacts are smaller your deployments are faster it's a big difference to playing you know 100 mega artifact versus a 2gig artifact and then
32:46
finally it's just Python like there's not a whole lot of magic going on here there's not a million lines of go code that you're depending on so when things do break you can look under the hood and figure it out shiv is a very simple project and I just realized I didn't really explain
33:05
how shiv works so I'll give you that really quick so what what shiv does is it takes all your dependencies or your site packages directory it puts it into the zip app hit the zip file along with like a small bootstrap script
33:23
and when you execute the zip app it will unpack the your site packages and then basically inject the path where it unpacked them into your Python path so it's the first thing that gets picked up you can read the code and understand
33:40
it and it's not terribly difficult to understand the second time you run it it knows where that kind of temporary cache it created is and so it doesn't to unpack them the second time cons so it's not as isolated as true
34:01
containers that's true it requires Python being installed on your server it's Python specific so docker you can use with any number of languages and it'll work the same not so with this and it's not cross-platform compatible I mean technically docker isn't really either but you can't build
34:24
stuff you can't build a zip app with C extensions on your Mac and ship it to Linux but you could build it in a docker container that is Linux on your Mac and send it that way so what's the sweet spot here you know
34:42
docker my if you takes away anything from this talk docker is not for everybody and this solution certainly isn't for everybody I would say if you're deploying primarily Python services you've outgrown platform as a service I'm a huge fan of platform as a service things like koroku python
35:04
anywhere all these options out there it should be where you're starting when you're looking to deploy stuff unless for some reason you are like super interested in learning these things these kind of tools you don't have to worry about it they deal with it for you but people tend to outgrow them like
35:24
they either find like at some point it makes more sense from a financial perspective to bring these things in-house or they need more flexibility than they get with with one of these options and this is an arbitrary number but I'm gonna say if you have fewer than 50 services to
35:41
maintain so if you have a hundred services a thousand services something like kubernetes is probably where you want to be it's kind of it's designed for doing exactly that but most people aren't Google scale most people are not deploying hundreds and thousands of service services most
36:01
people are deploying one to ten and at that scale the payoff might not be there so next time you're faced with a scary deployment scenario I hope you remember there are multiple options docker is a great option and but
36:24
Python is not so bad on its own and you can certainly have you know these secure single file deployments with Python so thank you happy thanks very
36:43
much for the talk have you used Shiv and the zip apps at all with lambda I it's not entirely or AWS lambda or Azure functions or whatever I haven't yet but I noticed that in the configuration setup.py you exposed
37:05
manage.py I was wondering for use with mod whiskey if there might be any way to expose it you have to expose whiskey.py in some way in the zip is that a possibility right so the the way I've been running the WYSI applications
37:21
with this is by wrapping it in a management command so I call I can still call the management command and then that executes the whiskey application another option would be to change the entry point via so you would install you know I'm not super up-to-date on how mod whiskey works but I bet Graham
37:47
has lots of ideas on this yeah so you you could execute that you could include other servers in your zip app assuming their Python and adjust the
38:03
entry point to run those if you wanted to thank you