Unfortunately, this method seems like it would only work for libraries, or things that can easily be packaged as libraries. It wouldn't work that well for a web application, for example, especially since the typical Django application usually involves multiple services, different settings per machine, etc.
How We Deploy Python Code
41–50 of 129 posts
Re: How We Deploy Python Code
#42Seems this method wouldn't work as well if you have external clients you deploy for. I'd use Docker instead of doing this, just to be in a better position for an internal or external client deployment.
Re: How We Deploy Python Code
#43Yes, someone should build the one way to ship your app. No reason for everybody to be inventing this stuff over and over again. Deploys are harder if you have a large codebase to ship. rSync works really well in those cases. It requires a bit of extra infrastructure, but is super fast.
+1 rsync is pretty darn good at any scale -- I'm not sure why the simplest solution possible doesn't beat out docker as a suggestion in this thread.
I've been bundling libs and software into a single virtual environment like package that I distribute with rsync for a long time - it solves loads of problems, is easy to bootstrap a new system with, and incremental updates are super fast. Combine that with rsync distribution of your source and a good tool for automating all of it (ansible, salt, chef, puppet, et al) and you have a pretty fool-proof deployment system.
And a rollback is just a git revert and another push away -- no need to keep build artifacts lying around if you believe your build is deterministic.
Re: How We Deploy Python Code
#44Unfortunately, this method seems like it would only work for libraries, or things that can easily be packaged as libraries. It wouldn't work that well for a web application, for example, especially since the typical Django application usually involves multiple services, different settings per machine, etc.
> different settings per machine
/etc/default/mycoolapp.conf
Debian packages have the concept of 'config' files. Files will be automatically overwritten when installing a new version of package FOO, unless they're marked as config files in the .deb manifest. This allows you to have a set of sane defaults, but not to lose customisations when upgrading.
Re: How We Deploy Python Code
#45Here is the process I use for smallish services -
1. Create a python package using setup.py 2. Upload the resulting .tar.gz file to a central location 3. Download to prod nodes and run pip3 install .tar.gz
Rolling back is pretty simple - pip3 uninstall the current version and re-install the old version.
Any gotchas with this process?
Re: How We Deploy Python Code
#46> Building with dh-virtualenv simply creates a debian package that includes a virtualenv, along with any dependencies listed in the requirements.txt file.
So how is this solving the first issue? If PyPI or the Git server is down, this is exactly like the git & pip option.
Re: How We Deploy Python Code
#47> Building with dh-virtualenv simply creates a debian package that includes a virtualenv, along with any dependencies listed in the requirements.txt file. So how is this solving the first issue? If PyPI or the Git server is down, this is exactly like the git & pip option.
You need those things up to build the package not to install it
Re: How We Deploy Python Code
#48Re: How We Deploy Python Code
#49Seems this method wouldn't work as well if you have external clients you deploy for. I'd use Docker instead of doing this, just to be in a better position for an internal or external client deployment.
Why? Saying it runs on Debian X is much more easy to facilitate by your end users than "requires docker"
Re: How We Deploy Python Code
#50Here is the process I use for smallish services - 1. Create a python package using setup.py 2. Upload the resulting .tar.gz file to a central location 3. Download to prod nodes and run pip3 install .tar.gz Rolling back is pretty simple - pip3 uninstall the current version and re-install the old version. Any gotchas with this process?
You have to do this every time there's a change in the codebase which is not easy. How do you stick this into a CI without the git & pip issue talked about in the post?