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