gh #498: Use docker alpine image

[mzdaniel]

Preliminary work to use lightweight docker alpine image.
Created https://github.com/mzdaniel/alpinewheels as pypi doesn't have yet support for musl libc, nor a tag that we can use.
This is a proof of concept to discuss the implementation details and improve it.
Development is working with postgres support and production properly launches all containers (though boto seems to insist in aws credentials raising exception. gunicorn seems to be active)

[mjsisley]

I seem to have the same functionality. I hadn't tested aws.
Your approach using wheels is much better than mine. I just installed the dependencies in the Dockerfiles.

What are the sizes of your resulting images?

Also, I swapped redis and nginx to their official alpine images. Postgres doesn't have an official alpine image yet, but there may be soon docker-library/postgres#119.

[audreyfeldroy]

@mzdaniel Awesome work with this so far!

Question for @jayfk and core devs: There's an edge case affected by this PR, where someone is using Docker in production but not for local development, and they end up with an alpine wheel as part of their local requirements. Is that worth considering, or should we not worry about it?

This is the part I'm thinking about: https://github.com/pydanny/cookiecutter-django/pull/594/files#diff-5b667bb77c1db39af213e1d97dfbde23R20

[mzdaniel]

Thank you for your comments, @mjsisley and @audreyr
Django image weights so far:
4.8: Linux OS
58: python3 (55.5) + bash + curl
7.5: pip 8.1
117: python packages
Total 188 MB (we'll shave a further 25MB in the next iteration)

If people are for it, I'll work in further optimizing space for our dependencies too.

[jayfk]

Looks rock solid. Great work.

One thing we should discuss: I'm not comfortable with making this the default unless there's official support for the wheels being used.

Why?

• People won't expect to install privately hosted wheels from an unknown source by default unless there's a very good reason for it.
• Image size/build time is not a good reason.

I'm in favor of adding this as an optional thing for now. This way we can document the advantages and (current) disadvantages of using an alpine based build and there won't be any surprises.

Once all disadvantages are sorted out, we make it the default.

What do you think?

[mzdaniel]

Sounds good!
I'll adjust the PR accordly. In the meantime, Do people prefer the current way of templating binary
wheels, or have them preloaded with python in an alpine docker container (~75MB)?

[jayfk]

+1 binary wheels!

[audreyfeldroy]

@mzdaniel Were you able to figure out how to automatically upload the wheels to GitHub, or is it a manual process? If manual, I prefer a preloaded Docker image, but if automated, I think I like separate binary wheels. But I'm flexible.

Thoughts on dealing with package version number updates? We recently set up requires.io to send automatic PRs to cookiecutter-django updating requirements files whenever a new version of a package comes out. Perhaps doing the same with alpinewheels and having a core Cookiecutter Django dev (me and/or @jayfk) keep both in sync could be a possible solution, though I'm open to ideas.

[mzdaniel]

@audreyr and @jayfk . Yes I am aware of these processes. AFAIK the only publicly available alpine builder for our wheels is dockerhub. Currently a github commit automatically launches a docker build. I just don't see there is an interface to publish artifacts back to github though. As @jayfk mention, it seems best for now not to make alpine the default docker image so we can tackle automation and other issues in following iterations as needed.
I do like the idea of requires.io! Why don't deal with it when we concentrate in the automation part?
What is the concensus for offering options (default python3)? alpine + templated wheels, custom python3 with builtin binary wheels.
Regarding hosting, do we have an org for cookiecutter-django on dockerhub/github?

[jayfk]

Regarding hosting, do we have an org for cookiecutter-django on dockerhub/github?

There's a organization on dockerhub, but afaik not on github.

@audreyr, @pydanny could you open a cookiecutter org on github and create a django-alpinewheels repo and add @mzdaniel, @mjsisley, @audreyr and me as contributors? This is where we could set up the alpine wheels and possibly find a way to semi automate that.

[audreyfeldroy]

@jayfk Sure, will do as soon as we get a free moment.

[ssteinerx]

As usual, I vote for moving e.g. Docker support out into its own "plugin/mixin" rather than having it mind-melded into the main project.

The case for separation of concerns is compelling.

[ssteinerx]

Also, this should, in my opinion, be getting done on a sub-branch, based on 1.9-dev, not targeted directly for merge with master. Running everything off master is a very Subversion concept (since branch merging was such a nightmare). With git, branching and merging branches is so easy, there's no reason not to make branches for any non-trivial propositions.

[amcorreia]

I know it's a bit old issue, but don't make more sense just use python alpine image instead of create a new image?

[pydanny]

This PR is so old is there any reason to keep it open?

[mjsisley]

I would close it. If anything, probably makes sense to use python alpine as suggested by @amcorreia. On Thu, Sep 21, 2017 at 4:07 PM Daniel Roy Greenfeld < mailto:Daniel Roy Greenfeld <[email protected]> > wrote: a, pre, code, a:link, body { word-wrap: break-word !important; } This PR is so old is there any reason to keep it open? — You are receiving this because you were mentioned. Reply to this email directly, #594 (comment) , or https://github.com/notifications/unsubscribe-auth/AL4BA9VqhQWdOiOIuomA_xZvd1K5ChQNks5skuxMgaJpZM4IuuU5 .

[pydanny]

Closing this for now. If @mzdaniel or one of the core maintainers wants to reopen it, they can.

[mzdaniel]

The underlying issue is there is no alpine psycopg2 wheel available so we can use the python alpine image. This is why we've been talking into hosting such a wheel on a cookiecutter org on github.
As mention, I will take care of the details (I've been blocked by infrastructure needs) if core maintainers support the move to a significantly more lean image.