[RFC] Dockerize

[Lukasa]

For ease of deployment it might be helpful to have a Docker container that runs httpbin. This is a simple first step down that road.

Before merging, it might be worth trying to optimise this image somewhat. For example, it might be better to use Debian as the base rather than Ubuntu. It might also be worth trying to remove the artifacts of the build step, make the number of gunicorn workers parameterizable, or something else interesting. I'm happy to make those changes and test them.

[kevin1024]

I think this is pretty cool. The number of workers should be configurable via an env variable.

Would we also add this to the docker hub registry? What account should it be under?

I've seen some projects manage the dockerfile in a separate repository (docker-httpbin) instead of keeping the dockerfile in the main repository. I don't think there is a convention for this yet.

On Feb 21, 2015, at 10:45 PM, Cory Benfield notifications@github.com wrote:

For ease of deployment it might be helpful to have a Docker container that runs httpbin. This is a simple first step down that road.

Before merging, it might be worth trying to optimise this image somewhat. For example, it might be better to use Debian as the base rather than Ubuntu. It might also be worth trying to remove the artifacts of the build step, make the number of gunicorn workers parameterizable, or something else interesting. I'm happy to make those changes and test them.

You can view, comment on, or merge this pull request online at:

#216

Commit Summary

Add basic Dockerfile.
File Changes

A Dockerfile (9)
Patch Links:

https://github.com/Runscope/httpbin/pull/216.patch
https://github.com/Runscope/httpbin/pull/216.diff
—
Reply to this email directly or view it on GitHub.

[Lukasa]

I think this is pretty cool. The number of workers should be configurable via an env variable.

Cool, I'll make that change and push it up.

Would we also add this to the docker hub registry? What account should it be under?

I think it would be worth doing. As for what account, I have no particular opinion on that front. =)

[Lukasa]

Ok, number of workers can now be configured by setting GUNICORN_WORKERS to the appropriate value: the default is currently 4.

[msabramo]

OK, this reminded me of a tool that I've been experimenting with lately for work and I've open-sourced it but not yet put it on PyPI because it's still in flux.

https://github.com/msabramo/pydockerize

The idea is to make it as easy as possible to take a Python app and make a Docker image for it and run it. It tries to glean as much information as it can from requirements.txt, Procfile (which httpbin conveniently already has), .env, etc. so that it can do something reasonable for a twelve-factorish app.

Comments are appreciated. Pull requests are appreciated ecstatically!

[sigmavirus24]

So I'm kind of torn personally @kevin1024 about where to keep the Dockerfile. For some projects it seems to make more sense to put them in a separate repository (e.g., if someone sent one for Flake8, I'd much prefer to have that in a separate repository). I feel like having it here, makes sense but it's a super subjective opinion. I think my distinction is purely that it's better to work with a server-like application in the environment it's (most) likely to be deployed in (fedora, ubuntu, debian, etc.). With tools like Flake8 it'll be used in so many contexts that it doesn't seem sensible to restrict development to one environment since it'll have to work on my laptop's distro, every other linux distro, OSX, Windows, etc.

I guess I'm +0.5 on having it here, but if the consensus ever does become that it should be in a separate repo, I'm okay with that too.

Thanks for this @Lukasa !

[msabramo]

I think it makes sense to keep the Dockerfile in this repo, along the lines of what @sigmavirus24 said, which in my mind is that this is an application more than a general tool or library. And I think it's better to err on the side of having less moving parts rather than more.

I'd say create an organization on Docker hub for httpbin so the image can be httpbin/httpbin, which makes it look more official.

[Lukasa]

@msabramo Agreed, though it would be equally good to have runscope/httpbin as an alternative. Particularly if Runscope plan to dockerize more of their community apps.

[sigmavirus24]

I think it's better to err on the side of having less moving parts rather than more.

This is what I was getting at without verbalizing it. :D

I would think @Runscope/owners might want this under a Runscope organization given the fact that they sponsor it's hosting, etc.

[sigmavirus24]

Damnit @Lukasa you always comment 10s before me with exactly what I was thinking.

[msabramo]

Yeah, runscope/httpbin would be fine too, especially since that's the name on GitHub now.

[Lukasa]

FYI, this Dockerfile is currently running behind H2O on http2bin.org.

[msabramo]

What is H2O? (Other than water)

[Lukasa]

It's a HTTP/1.1 and HTTP/2 reverse proxy. See here.

[Lukasa]

The relevant Dockerfile for that one is here.

[kevin1024]

I think it makes sense to keep the Dockerfile in this repo, along the lines of what @sigmavirus24 said, which in my mind is that this is an application more than a general tool or library.

OK, makes sense. +1 from me for keeping it in the repo.

Regarding the base image: I've been using the official Docker python language stack and it works pretty well. It makes some assumptions about the layout of the project will automatically run pip install -r requirements.txt. I believe it's based on Debian.

[msabramo]

I also used the official python image and it was cool. IIRC only the "onbuild" tagged versions have the ONBUILD that does pip install -r requirements.txt

[msabramo]

Oh and +1 for Dockerfile in repo and runscope/httpbin docker hub image.

[kennethreitz]

can we do this on alpine?

[kennethreitz]

also, gunicorn will automatically honor WEB_CONCURRENCY (instead of GUNICORN_WORKERS).

[kennethreitz]

can always improve it later