Expanded Docker support

[LeoCBS]

Hi, first of all, congrats for the project..

I saw that project have one docker folder.. support to docker is finish? if don't, I could finalize the Dockerfile

If support to docker is finish.. i could add some documentation in readme..

what you think?

[]'s

[timothycrosley]

@BrandonHoffman, I know you created the docker folder originally, do you have any thoughts on this?

@LeoCBS, thanks for the willingness to help! Definitely in any case adding more documentation is always appreciated.

Thanks!

~Timothy

[autoferrit]

I just mentioned this in gitter too. I have a dockerfile using gunicorn to launch python apps (currently uses python3 based on alpine). That could be used and all you would need to update (and include in your repo) is an updated supervisor.conf which is pretty simple.

Dockerhub: https://hub.docker.com/r/skiftcreative/gunicorn/ Source: https://github.com/SkiftCreative/docker-gunicorn

I actually planned on making a small example project to show how to use the gunicorn image, which I could show with falcon/hug and post that up.

[autoferrit]

I will need to tag the gunicorn image though to specify what version of python is desired as well. I will have to do the same with the parent supervisor image as well. which won't be too hard. I could do that tonight or this weekend.

[BrandonHoffman]

There currently is a docker image that can be used but its very basic (installs a few modules and copys over an application directory and runs it on start). The current one is also based of pythone/Alpine. Any improvements on it would be great.

[autoferrit]

Yea mine is similar, just uses python, installs supervisor and gunicorn (3 images total) and the app images will install the pip requirements

[autoferrit]

For reference if it helps, I made a small repo showing usage of mine. https://github.com/SkiftCreative/docker-gunicorn-examples with both flask and falcon/hug usage. I'm not sure if thats everything that would be needed here. or if you have a better idea. I still need to do python version tagging which I will take care of this weekend for the two images. I am not very experienced in falcon/hug yet so I could be going against the grain there. I noticed in the existing docker image you are starting the container in a different way. So im not sure if thats just for development or production use.

[BrandonHoffman]

Another potentially useful change would be switching the image to serve using uwsgi since that would be the preferred way of running hug for production purposes. Right now it is running it via the hug command instead. Might even justify having a 2nd docker image one for development purposes and one for production purposes.

[autoferrit]

how does uwsgi compare to using gunicorn? I have always just used gunicorn. I would make a docker images for that to sit along side gunicorn so people could essentially just chose which one they want to use. I'm just not familiar with using it/setting it up.

When running locally during dev, i generally dont actually use docker. I just run it through an env. I dont test it in docker until im going to push the code up to my server and I test it to make sure its working and possibly run tests.

[timothycrosley]

@SkiftCreative I think gunicorn is also a perfectly acceptable production server, I think @BrandonHoffman was just referring to the fact the currently included dockerfile specifies to use the hug development server which isn't suitable for production. In general I find gunicorn to be a bit simpler and uwsgi to be a bit more flexible - but their both pretty close, and both great servers for Production use.

[BrandonHoffman]

@SkiftCreative, @timothycrosley hit the nail on the head. Both seem uwsgi and gunicorn are good potential changes. Main concern is being able to deploy a docker image that does not use the development server.

[autoferrit]

well with the images im using now, ive pushed up without using the hug command. with the code in the example repo I posted. So I guess from here, im not sure whats going on really. My stuff is up under MIT so your free to steal them if you need to (although now that I think of it I may need to put LICENSE files in the repos stating that...

[timothycrosley]

Renaming and continuing this issue as expanded docker support, as I feel that with @SkiftCreatives and @BrandonHoffman's contributions we have enough of a base line of docker support for the 2.0.0 release, and can work on expanding that into 3.0.0

[vortec]

My suggestion is to generate 2 images for each release and publish them on Docker Hub. Imagine images like this:

• hug:2.0.2-gunicorn
• hug:2.0.2-uwsgi

If you omit the tag in Docker, latest is being used. I suggest pointing this tag to the gunicorn image.

Whenever a new hug release is pushed, the Docker image will be built and published too. Preferably this happens automatically, therefore I wonder if the hug release process is automated and offers something where we could hook into for this.

All this assumes that we want to offer Docker images additionally to the PyPi images. If the goal is to just provide a Dockerfile we are already there and must just decide on a default webserver.

[dgonzo]

I would love to help on this. I've been doing extensive development with docker-compose running hug, nginx, and rethinkdb so it might be helpful to others to have a few "reference stacks" in docker compose files all relying on images from docker hub. I'll put together a pull request with instructions.

[vortec]

@timothycrosley Can we hook into the release process somehow?

[timothycrosley]

@vortec, the most simple answer to this is via release tags https://github.com/timothycrosley/hug/releases which are gaurenteed to be incremented per a new release. I'm more then willing to provide any other form of notification / hooks that would be useful

[housni]

Can I just ask what the goal of this Docker image is going to be? Is it just a development container that people can throw away once they're done? In that case, an all-in-one image is perfect.

If you want to give people a Docker environment where they can run a database, webserver, dev environment and possibly caching and other things later on, using Docker Compose and spreading each service across a container is a better option because it allows people to easily scale up their containers and easily use it in production with some tweaks.

@vortec and I discuss this in PR #343 where he brought up a very valid point about how Docker is potentially useless to some users and therefore may not belong in the repo.

I'm open to whatever works best for the use case. Let me know if I can help!

[autoferrit]

Looking back at this, and reading #343, I think we need a slightly different approach. I sort of agree with @timothycrosley that we need a public docker hub image.

My proposal to have a separate repository for these container images. This will allow us to easier manage docker tags, have automated builds when a new hug version is released and have plenty of examples without polluting the main hug repo.

In regards to tagging, the :latest tag should always point to a current production ready version of hug using either gunicorn or uwsgi.

Further versioning can get tricky since there are essentially multiple things we need to track:

• Hug version
• Gunicorn, wsgi, or dev
• Python versions (currently only 3.5+)
• Possibly base image.

I've done this before, my proposal for tagging would be something like

:{os}-{server}-{hug-ver}

Meaning :latest currently would also be:

:alpine-gunicorn-2.2

Other options could be

:coreos-wsgi-2.2

Or

:ubuntu-dev-2

Omitting g hug version defaults to latest stable. Omitting server and hug version defaults to gunicorn, and latest hug version

We can build these images based on when a new version of hug is released.