Re:After Docker: Unikernels and Immutable Infrastructure
by grosskur on Friday November 14, 2014 @02:24PM
(#8608972)
You could also try virtualenvs inside Debian packages:
https://github.com/spotify/dh-virtualenv
One reason to keep virtualenvs is that the system Python (VM or container) includes extra Python packages that your app may or may not need. If you use a virtualenv, you exclude these system-installed packages and guarantee a clean starting point.
Re:After Docker: Unikernels and Immutable Infrastructure
by calpaterson on Friday November 14, 2014 @03:40PM
(#8609361)
I find the problem with this approach comes when you want to ship a package (ie: requests) that is newer than whatever is packaged for your OS. Then you either have to repackage OS packages, taking on the corresponding duty to keep them patched. I am using wheel files in production for this very reason
Re:After Docker: Unikernels and Immutable Infrastructure
by icebraining on Friday November 14, 2014 @03:34PM
(#8609333)
Same here. As a bonus, it makes it easy to create a bare-metal OS installation image that includes your app.
I'm running a script right now that generates an ISO that turns a brand new machine into a server running our app with a template DB in completely unattended fashion.
For VMs/containers that already run a single application, except for some weird edge cases, there's really no point in having a virtual environment in a virtual environment.
I have initial success with a few simpler projects, now looking into transitioning more complex ones. Not sure whenever it'll go without any hassle, but seems worth trying. At worst, I'd just waste my time and return to virtualenvs.