6 ms·

Using Docker as a Python Development Environment

61 points by amouat 12y ago

netcraft 12y ago
I'm confused how they created the docker image with python, postgresql and apache in the first place? Is it the FROM python_webapp that defines that? python_webapp being the name of a docker image already defined? How hard is it to set up the docker image initially? Edit: NVM, it is documented here (I missed it the first read through) http://continuousdelivery.uglyduckling.nl/continuous-delivery/rapid-prototyping-a-python-web-application-with-vagrant-and-docker-part-1-development/ http://continuousdelivery.uglyduckling.nl/continuous-deliver...
- mbreese 12y ago
  I'm more curious as to how to get a lightweight Docker container running Python. The one they use pulls in an Ubuntu Quantal image, which isn't something that I'd normally use (I'm more in the RHEL/CentOS camp). So, how would one go about building something like this that isn't tied to a container that pulls in a whole OS? Or is that just not the way these things work? Or am I just too used to virtualenv?
  - chanux 12y ago
    You can use CentOS if you prefer that. Also the OS is pulled just once.
monatron 12y ago
to be honest i still usually implement virtualenv when constructing a container. This way I'm sure that I'm not interfering with the os-level python dependencies, and any activation of the environment is handled by a "python-webapp" baseimage that I use for all of my projects.
dschiptsov 12y ago
Why, why should I do this?) What's wrong with python3 and Postgresql which are packaged in last Ubuntu? How about the principle of not adding unnecessary entities/complications?
- klibertp 12y ago
  It's probably not needed when working on a single project - although even then Docker has some advantages, like being able to have another distro in the image than you have natively - but it makes your life infinitely simpler when you need to work with two or more projects with differing dependencies.
- lvh 12y ago
  That seems orthogonal to using virtual environments or not. Are you talking about putting them on your dev machine? In that case: reproducible development environments.
  - dschiptsov 12y ago
    "reproducible development environments" - what does this mean?)
quasarj 12y ago
I'm not sure about this guy's list of issues with virtualenv. Point 1 (he forgets to activate it) is not an issue at all. You could forget to "activate" your docker too. Point 3 (he doesn't want to run it in production) but running docker in production is okay? That said, he made a good point about non-python dependencies.
- amouat 12y ago
  Regarding point 1, the way in which I start the server has fundamentally changed but is still only one command - I know I have to do "docker run" to start it, rather than "python run.py" or similar. In virtualenv I have to remember two commands; "workon bla" and "python run.py". Regarding point 3, yes I think docker in production is ok, or soon will be :)
  - zigara 12y ago
    How about you use a simple virtualenv wrapper such as https://pypi.python.org/pypi/vex https://pypi.python.org/pypi/vex ? Then you can easily type 'vex myenv python myapp.py', no need to spin up a linux container for simple development.
    - klibertp 12y ago
      > no need to spin up a linux container for simple development But why not do this, anyway? These containers are very cheap and come with very little overhead, they are truly isolated and they are easily shareable. I'd say there is no need not to spin up a container for everything, it's not like you're going to run out of RAM...
      - zigara 12y ago
        While they do make sense in certain situations, they also add more complications. On linux, it's much easier, but If I want to run this on windows, or osx, they tell you to run Docker inside of a full VBox VM (and maintain it), this is not ideal as VBox destroys my battery and other annoyances. You also have to maintain those containers/images (not to mention lug around a 600+mb base OS image and update it). I am not sure how Docker handles keeping images updated, I assume overlayfs makes it easy to keep your base docker OS images updated, but not sure how it'd handle certain package configurations.
stuaxo 12y ago
This could be really useful for non-python webapps. Gtk and other libraries for stuff like Sound haven't caught up to the virtualenv age + getting them to work can involve ugly hacks.
chanux 12y ago
I see a lot of 'but why' questions in the thread. When I started to work with Docker for the very first time, I soon realized that it is going to be fantastic for setting up dev environments (I was not that in to VMs anyway). I have put pretty complex setup at work on docker and it made things really simple for people who wants to set it up on their work laptop. Especially the new hires (oh and interns). Of course Docker is more stuff to learn but when it's just a bunch of instructions to follow on a readme file they would just run those and have the system running (mostly without much trouble) and later figure out what this Docker thing really is, if they are in to it.

61 points by amouat 12y ago

I'm confused how they created the docker image with python, postgresql and apache in the first place? Is it the FROM python_webapp that defines that? python_webapp being the name of a docker image already defined? How hard is it to set up the docker image initially? Edit: NVM, it is documented here (I missed it the first read through) http://continuousdelivery.uglyduckling.nl/continuous-delivery/rapid-prototyping-a-python-web-application-with-vagrant-and-docker-part-1-development/ http://continuousdelivery.uglyduckling.nl/continuous-deliver...

mbreese 12y ago
I'm more curious as to how to get a lightweight Docker container running Python. The one they use pulls in an Ubuntu Quantal image, which isn't something that I'd normally use (I'm more in the RHEL/CentOS camp). So, how would one go about building something like this that isn't tied to a container that pulls in a whole OS? Or is that just not the way these things work? Or am I just too used to virtualenv?
- chanux 12y ago
  You can use CentOS if you prefer that. Also the OS is pulled just once.

monatron 12y ago

to be honest i still usually implement virtualenv when constructing a container. This way I'm sure that I'm not interfering with the os-level python dependencies, and any activation of the environment is handled by a "python-webapp" baseimage that I use for all of my projects.

dschiptsov 12y ago

Why, why should I do this?) What's wrong with python3 and Postgresql which are packaged in last Ubuntu? How about the principle of not adding unnecessary entities/complications?

klibertp 12y ago
It's probably not needed when working on a single project - although even then Docker has some advantages, like being able to have another distro in the image than you have natively - but it makes your life infinitely simpler when you need to work with two or more projects with differing dependencies.
lvh 12y ago
That seems orthogonal to using virtual environments or not. Are you talking about putting them on your dev machine? In that case: reproducible development environments.
- dschiptsov 12y ago
  "reproducible development environments" - what does this mean?)

quasarj 12y ago

I'm not sure about this guy's list of issues with virtualenv. Point 1 (he forgets to activate it) is not an issue at all. You could forget to "activate" your docker too. Point 3 (he doesn't want to run it in production) but running docker in production is okay? That said, he made a good point about non-python dependencies.

amouat 12y ago
Regarding point 1, the way in which I start the server has fundamentally changed but is still only one command - I know I have to do "docker run" to start it, rather than "python run.py" or similar. In virtualenv I have to remember two commands; "workon bla" and "python run.py". Regarding point 3, yes I think docker in production is ok, or soon will be :)
- zigara 12y ago
  How about you use a simple virtualenv wrapper such as https://pypi.python.org/pypi/vex https://pypi.python.org/pypi/vex ? Then you can easily type 'vex myenv python myapp.py', no need to spin up a linux container for simple development.
  - klibertp 12y ago
    > no need to spin up a linux container for simple development But why not do this, anyway? These containers are very cheap and come with very little overhead, they are truly isolated and they are easily shareable. I'd say there is no need not to spin up a container for everything, it's not like you're going to run out of RAM...
    - zigara 12y ago
      While they do make sense in certain situations, they also add more complications. On linux, it's much easier, but If I want to run this on windows, or osx, they tell you to run Docker inside of a full VBox VM (and maintain it), this is not ideal as VBox destroys my battery and other annoyances. You also have to maintain those containers/images (not to mention lug around a 600+mb base OS image and update it). I am not sure how Docker handles keeping images updated, I assume overlayfs makes it easy to keep your base docker OS images updated, but not sure how it'd handle certain package configurations.

stuaxo 12y ago

This could be really useful for non-python webapps. Gtk and other libraries for stuff like Sound haven't caught up to the virtualenv age + getting them to work can involve ugly hacks.

chanux 12y ago

I see a lot of 'but why' questions in the thread. When I started to work with Docker for the very first time, I soon realized that it is going to be fantastic for setting up dev environments (I was not that in to VMs anyway). I have put pretty complex setup at work on docker and it made things really simple for people who wants to set it up on their work laptop. Especially the new hires (oh and interns). Of course Docker is more stuff to learn but when it's just a bunch of instructions to follow on a readme file they would just run those and have the system running (mostly without much trouble) and later figure out what this Docker thing really is, if they are in to it.