As a developer I am used to keep my Python tools updated. Especially packages needed for installing and bundling. Using the most recent releases of pip, virtualenv and setuptools is in my personal experience the most reliable choice.
I have been told recently that from an operations perspective, I should not touch the preinstalled releases of pip on the production machine. So to speak: The typical pip install -U pip in the virtualenv was a security risk.
There are valid concerns I think, but I do wonder whether this really is the best practice for running services developped with Python. Pip as it is in Debian 7 for example is quite old.
So my questions
- What are the best practices here for running Python services securely?
- Are there ways to move the split worlds (OS Package Tree and Python Package Tree) closer together?
1
Linux packages shipped with a given distribution are usually heavily tested to ensure they work well with the specific distribution. Your company may do an additional step of testing those packages for the scenarios which happen specifically in the company.
If you’re installing newer versions, you’re on your own. It may work well, and it usually does, because it was tested by the developers of the package itself. But it may also cause problems in a given distribution.
Whether you should install the newer versions depend on:
-
How stable the servers should be. If you want to avoid any issue in production, don’t blindly upgrade to newer versions expecting that everything will work as expected.
-
How critical is to have the new version. Some versions contain new features you absolutely need for your application, and it becomes acceptable to take a risk to update the package. Some versions solve bugs which are again critical enough to be kept on your platform.
In general, the update process of production servers, would it be on Linux or Windows, is not as simple as apt-get install ... or clicking on a button in Windows Update. Instead:
-
Updates should be tested in staging to ensure that there are no apparent regressions.
-
Production servers s houldn’t be updated all at once, but rather one by one, to be able to failover and to step back if something bad happens.
-
You should make sure you can revert to earlier state if a regression is discovered later.
Using virtual environments, you can specify which version of each package you want installing (why this is a good thing). This allows you to pin version specific to whatever you code base needs.
The main draw backs are that updating can be slower and deploying to a new machine takes longer. The former might not be too bad since you want to test that all newer version of dependencies still work with your code, right? The later has been solved by a plethora of tools — for example Puppet-Python.