Official Kallithea docker image

Tue Mar 28 16:48:17 UTC 2017

On Mon, Mar 27, 2017 at 5:01 PM, Dominik Ruf <dominikruf at gmail.com> wrote:
> Søren Løvborg <sorenl at unity3d.com> schrieb am Mo., 27. März 2017 um 19:57
> Uhr:
>>
>> > I see the official docker one would the the "recommended" one
>> > it is also about recommending deployment best practices.
>>
>> But one size doesn't fit all.
>
> It never does. :-P
> But I think that is not really the point of a 'official' docker (or how ever
> you want to call it).
> For me the would be to provide a good (enough) solution for 80% of users.

Exactly, good enough 80% of the cases.

It's like recommending a stable version (might be older) by default to
someone only if he has special needs (need a bug fix not released yet)
then he can live on the bleeding edge and run from source.

As Soren already pointed out, there are way too many deployment
combinations for Kallithea.  A normal user that just want to use it,
that is not a Python web developper, will be completely lost or likely
to choose the wrong combination then have the wrong impression about
Kallithea.

>>
>> Just take the choice of database
>> backend: At home, I run SQLite, because I know the install will never
>> grow to a size where I'll need a "real" database. At work, we use
>> PostgreSQL. I'd recommend one of those two depending on needs, but
>> others might prefer MySQL. And "what database backend should I use?"
>> is the _easy_ question, with only three supported options.
>
> I don't see your point here. A docker image could still allow the end user
> to choose his preferred database. My docker images have a separate volume
> for the .ini file where I configure my database, smtp server etc.

And in fact, the database process should be running outside of the
Kallithea container.  Docker is an application container, one
container should run one single process.  There are official images
for Postgres/MariaDB.

We should just focus on getting Kalilthea up inside the Kallithea
image, installing the minimum required, no front proxy, no celery
either.  Again there are image for celery, httpd, ngnix ...

When each process is in its own container, it makes upgrade a lot
easier, ex: if need to upgrade httpd version, just pull and start a
new httpd container, no need to rebuild/restart any other containers.

It also makes re-using user's existing stack easier, ex: the user
already have other web services on the same Docker host and is already
using a front proxy (a Docker container) to provide httpS to the
multiple web services in the backend (a bunch of other Docker
containers), the user can simply add Kallithea to the mix, re-using
the same front proxy for httpS.  Had the front proxy been part of the
Kallithea image, it'll be running for nothing because the user won't
use that.

Then the actual "deployment recommendation" for the 80% use-case is in
a docker-compose.yml that assemble/link/configure the all the pieces
(front proxy, DB, celery) together.

But we still need a bare "official" Kallithea image to be used in the
sample/recommended docker-compose.yml.

Ex: the wordpress official image https://hub.docker.com/_/wordpress/
that shows how to launch it with a mariadb image using both flavors
"docker run" or docker-compose.yml.  Users that just want to try, just
copy/paste the sample docker-compose.yml or the docker run line and up
they are running, without any fear of changing their local system
because everything is containerized.

Anyone with special needs will read additional docs.  Otherwise, that
setup is "good enough".

>>
>>
>> For choice of webserver, well, the choice is not "Apache, nginx, or
>> uWSGI?". The choice is more like:
>>
>> * Apache + mod_wsgi (what we're currently running at work)
>> * Apache + reverse proxy + Waitress
>> * Apache + reverse proxy + Gunicorn
>> * Apache + reverse proxy + Paster (what I run at home)
>> * nginx + ngx_http_wsgi
>> * nginx + reverse proxy + Waitress
>> * nginx + reverse proxy + Gunicorn
>> * nginx + ngx_http_uwsgi + uWSGI (some people swear by this, though I
>> don't see the point)
>> * uWSGI
>>
>> As for "uWSGI"... well, "uWSGI" is not a web server. It's really more
>> like a set of tools you can combine to build your own web server. I
>> mean, you can go with "plain and simple": uWSGI with a http router, a
>> master process, and offloading enabled for static files. But you can
>> also use uWSGI in "emperor" mode, "legion" mode, "zerg" mode, or even
>> "broodlord" mode. To make an informed decision, you'll need a sound
>> understanding of networking and Unix process management, and to
>> carefully read the uWSGI docs... and mailing list... and source code,
>> possibly.
>>
>> Depending on the user's needs, resources and experience, any of the
>> above choices might be the recommended one. :-)
>>
> For this point I actually think we should provide a good (enough) solution
> that fits for the 80%.
> Even though it is not really a job for a docker image (dockerfile), but more
> for a docker-compose.yml.
> I believe a lot of users don't know or don't care that much about the
> multitude of possible server configurations. And I believe these people
> don't want to run instances for hundredth of people. So we could provide an
> example docker-compose.yml to get them started.
>>
>> Now, I'm not at all opposed to creating a docker image... but I am
>> quite hesitant about the words "recommended" and "official". For
>> anyone trying to answer the above questions ("what database backend
>> and webserver should I use?"), a Docket image will often only be a
>> starting point. Actual documentation about pros and cons is much more
>> valuable.
>>
>> FWIW, at work we're currently experimenting with uWSGI in zerg mode
>> tightly coupled with systemd service management. We're still way off
>> getting this setup into production, but if it turns out to be the
>> right solution for us, I'll try to write up some notes on it. Not sure
>> it's recommended for *most* users, though. :-)
>>
>> Best,
>> Søren
>>
> I think I'll create PR for this as a starting point. We can then discuss
> concrete concerns and issues there.
>
> Cheers,
> Dominik
>>
>>
>> On Mon, Mar 27, 2017 at 6:25 PM, Long Vu <long.vu at intelerad.com> wrote:
>> > On Sun, Mar 26, 2017 at 5:42 PM, Mads Kiilerich <mads at kiilerich.com>
>> > wrote:
>> >> On 03/23/2017 11:53 PM, Dominik Ruf wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> I've been using docker for a while now for my kallithea server and
>> >>> others
>> >>> have also mentioned that they are using docker.
>> >>> So what are the thoughts about creating an official docker image for
>> >>> kallithea?
>> >>
>> >>
>> >> I think most setups have "special" requirements. I thus don't think
>> >> there
>> >> can be one official docker image. But it would be great to have a
>> >> collection
>> >> of images that work for different cases - some simple, some with lots
>> >> of
>> >> configuration knobs.
>> >
>> > I see the official docker one would the the "recommended" one with all
>> > the best practices for performance and diagnosis and a set up that
>> > open the door for the most integration with other tools in the stack
>> > of the user.  And we can have other docker for other special case
>> > setup.
>> >
>> > Example I've been seeing posts in this list about how to troubleshoot
>> > Kallithea performance and someone mentioned using uwsgi because it has
>> > better performance stats but no mention about how it compares
>> > performance wise to other deployment deployment.
>> >
>> > Personally, I am using apache as a front proxy to paster process, no
>> > celery, just because I am familiar with using apache as a front proxy
>> > and it's just for evaluation for now, so performance is not my
>> > priority.  I would very be interested in knowing what is the
>> > recommended setup to maximize performance if I actually golive in
>> > production with Kallithea.
>> >
>> > So for me, having an "official" or "recommended" docker image is more
>> > than just to provide an easy and reproducible way to deploy Kallithea,
>> > it is also about recommending deployment best practices.
>> >
>> > If Kallithea have deployment that is easy, performant, and easy to
>> > reproduce to reproduce bugs, it will clearly help adoption.
>> >
>> >>
>> >> There might also be valid reasons to use something else than docker -
>> >> for
>> >> example openshift of script installation on physical/virtual hardware
>> >> with
>> >> salt or ansible ... and for running natively on macOS or Windows
>> >> instead of
>> >> Linux ... or different Linux brands and different databases and web
>> >> servers
>> >> and authentication and ...
>> >
>> > Yes clearly not forgetting other configuration management tools and
>> > other platforms.  Ansible can actually drive the Docker deployment.
>> > At work we are not using Docker alone, but with Ansible.
>> >
>> > On Linux, if Docker is available as a possibility, it is really great
>> > for its reproducible nature that pretty much guaranty it'll just work.
>> >
>> > The more "turn key" solutions we have, the better.  Let's start with
>> > something and we'll grow the different solutions with time.
>> >
>> >>
>> >> So ... perhaps create a top folder called something like "images" (even
>> >> though that would be a bit ambiguous ...) and create subfolders there
>> >> for
>> >> each contribution.
>> >>
>> >> (I looked at existing docker images when upgrading celery and
>> >> paster/gearbox
>> >> ... and decided to create my own docker config that worked for that
>> >> purpose.
>> >> I could clean that up and contribute that too.)
>> >>
>> >> /Mads
>> >>
>> >> _______________________________________________
>> >> kallithea-general mailing list
>> >> kallithea-general at sfconservancy.org
>> >> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>> >
>> >
>> >
>> > --
>> > Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
>> >
>> > --
>> >
>> > This email or any attachments may contain confidential or legally
>> > privileged information intended for the sole use of the addressees. Any
>> > use, redistribution, disclosure, or reproduction of this information,
>> > except as intended, is prohibited. If you received this email in error,
>> > please notify the sender and remove all copies of the message, including
>> > any attachments.
>> >
>> > _______________________________________________
>> > kallithea-general mailing list
>> > kallithea-general at sfconservancy.org
>> > https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>> _______________________________________________
>> kallithea-general mailing list
>> kallithea-general at sfconservancy.org
>> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>

-- 
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.