<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Thomas De Schampheleire <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> schrieb am Mi., 15. Nov. 2017 um 08:50 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2017-11-14 22:55 GMT+01:00 Dominik Ruf <<a href="mailto:dominikruf@gmail.com" target="_blank">dominikruf@gmail.com</a>>:<br>
><br>
><br>
> Thomas De Schampheleire <<a href="mailto:patrickdepinguin@gmail.com" target="_blank">patrickdepinguin@gmail.com</a>> schrieb am Di., 14.<br>
> Nov. 2017 um 21:32 Uhr:<br>
>><br>
>> Hi Dominik,<br>
>><br>
>> 2017-09-20 20:52 GMT+02:00 Dominik Ruf <<a href="mailto:dominikruf@gmail.com" target="_blank">dominikruf@gmail.com</a>>:<br>
>> > Hi all,<br>
>> ><br>
>> > like I mentioned before, I'd like to add a Dockerfile and<br>
>> > docker-compose.yml<br>
>> > to make it really easy to get started with kallithea.<br>
>> > I did some more work on my docker setup and it now also includes ssh<br>
>> > support.<br>
>> > And like before it generates the css file from less.<br>
>> > So since these 2 things are not merged yet, I'd like to wait before<br>
>> > creating<br>
>> > a PR.<br>
>> ><br>
>> > But I wanted to ask if some people would volunteer to already test it.<br>
>> > I'd like to hear from others if it helps them setting up a Full Stack<br>
>> > installation.<br>
>> > And if there are unclear things about how to use it.<br>
>> ><br>
>> > I upload my images to <a href="https://hub.docker.com/r/domruf/kallithea-domruf/" rel="noreferrer" target="_blank">https://hub.docker.com/r/domruf/kallithea-domruf/</a><br>
>> > and you can find the docker-compose.yml at<br>
>> ><br>
>> > <a href="https://kallithea.dominikruf.com/kallithea/kallithea-domruf/raw/26ccf792b435/docker/docker-compose.yml" rel="noreferrer" target="_blank">https://kallithea.dominikruf.com/kallithea/kallithea-domruf/raw/26ccf792b435/docker/docker-compose.yml</a><br>
>> ><br>
>><br>
>> Sorry, I kind of forgot about this mail.<br>
>><br>
>> I have recently deployed a kallithea instance with docker based on<br>
>> your repo, but I was unaware that the version on Bitbucket is not up<br>
>> to date with your latest developments.<br>
>> As a result, I was still working on top of the latest commit there:<br>
>><br>
>> <a href="https://bitbucket.org/domruf/kallithea-docker/commits/36265eeea7a94a3538dbdb2e9cf22f0f56252965" rel="noreferrer" target="_blank">https://bitbucket.org/domruf/kallithea-docker/commits/36265eeea7a94a3538dbdb2e9cf22f0f56252965</a><br>
>> I would need to reevaluate your changes on <a href="http://dominikruf.com" rel="noreferrer" target="_blank">dominikruf.com</a>. For the<br>
>> text below, I have not yet done that. It is possible that you already<br>
>> solved some problems.<br>
><br>
> I did some experiments and some back and forth, so the history of my repo is<br>
> a bit ugly. Sorry.<br>
>><br>
>><br>
>> The instance we run is using uwsgi and postgresql.<br>
>><br>
>> Some feedback:<br>
>> - Since we have some custom changes to Kallithea, I build the image<br>
>> myself. In order to solve the reproducibility and traceability<br>
>> problem, I have added a label to the image, which is visible with<br>
>> 'docker inspect <image>'. There apparently is a schema project that<br>
>> provides a standard proposed set of labels, I took some of them from<br>
>> there:<br>
>><br>
>> ARG BUILD_DATE=unknown<br>
>><br>
>> LABEL org.label-schema.build-date=$BUILD_DATE \<br>
>>       <a href="http://org.label-schema.name" rel="noreferrer" target="_blank">org.label-schema.name</a>="Kallithea image" \<br>
>>       org.label-schema.description="Kallithea<br>
>> (<a href="https://kallithea-scm.org/" rel="noreferrer" target="_blank">https://kallithea-scm.org/</a>)" \<br>
>>       org.label-schema.vcs-ref=$REV \<br>
>>       org.label-schema.vcs-url=$URL \<br>
>>       org.label-schema.schema-version="1.0"<br>
><br>
> Okay, I didn't know about that. I'll look into it, thanks.<br>
>><br>
>><br>
>> - In order to easily provide the build date and other args, I added a<br>
>> makefile with a build target:<br>
>><br>
>> NAME = foobar/kallithea<br>
>> REV = 8142c5f0fd894a91dfd3f7e8e4484a028c5bfa96<br>
>> URL = <a href="http://foobar:8000" rel="noreferrer" target="_blank">http://foobar:8000</a><br>
>><br>
>> build:<br>
>>        docker build \<br>
>>                --build-arg REV=$(REV) \<br>
>>                --build-arg URL=$(URL) \<br>
>>                --build-arg BUILD_DATE=`date -u +"%Y-%m-%dT%H:%M:%SZ"` \<br>
>>                --tag $(NAME) \<br>
>>                .<br>
>><br>
>> - As we want uwsgi, I updated the dockerfile to install uwsgi and<br>
>> uwsgitop with pip. I changed the CMD to:<br>
>> CMD ["uwsgi", "--ini-paste-logged", "../conf/kallithea.ini"]<br>
>> And in the kallithea-entry-point.sh script, I changed:<br>
>> -if [ "$2" == "serve" ]; then<br>
>> +if [ "$1" == "uwsgi" ]; then<br>
><br>
> I did something similar.<br>
>><br>
>><br>
>><br>
>> - I had to change ownership of the kallithea-entry-point.sh script to<br>
>> the kallithea user, adapting the chmod line to also contain:<br>
>>     chown -R kallithea $KALLITHEA_PATH/src/kallithea-entry-point.sh<br>
><br>
> Why was this necessary? I mean it is probarbly a good idea but I don't see<br>
> why it' be required.<br>
<br>
I don't remember by heart. I need to try it again without that change,<br>
I'll come back later.<br>
<br>
>><br>
>><br>
>> - Also to improve reproducibility, I added the dockerfile in the image:<br>
>><br>
>> ADD Dockerfile $KALLITHEA_PATH<br>
><br>
> So the idea is that somebody who downloaded the image could  extract the<br>
> Dockerfile and<br>
> make some modifications?<br>
<br>
Yes. We need to have a situation where a given docker image can be<br>
reproduced exactly by someone else.<br>
So we need to know how exactly an image is built.<br>
Based on your kallithea-docker repo, we had two repos involved: the<br>
kallithea source repo, and the separate docker repo. In order to<br>
reproduce the docker image, you need to know which kallithea source<br>
revision was used (can be solved with the label) and which dockerfile<br>
and arguments were used. To know that, I am using image tags of the<br>
form vX-YYYYYYYYY-k0.3.3-ZZZZZZZZZZ   where X is a sequential number,<br>
YYYY is the hash of kallithea-docker, and ZZZZ is the hash of<br>
kallithea sources.<br>
But ideally, as you did  in your own repo now, the dockerfile is part<br>
of the kallithea source repository. Then, all you need to know is the<br>
kallithea source revision, which we can add in the image label. The<br>
only reason one could still add the Dockerfile inside the image, is to<br>
catch any non-committed changes to it. But if we create a clear<br>
process on how to create official docker images, then that risk can be<br>
mitigated and the explicit ADD of the dockerfile is not actually<br>
necessary.<br></blockquote><div>Bare in mind that we (currently) do not pin the versions of the pypi or deb packages,</div><div>so a newly generated images may not be exactly the same.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
>><br>
>><br>
>><br>
>> Below things refer to docker-compose.yml:<br>
>><br>
>> - removed references/names to 'domruf' as we use our own images.<br>
>> - removed explicit references to 172.17.0.1<br>
>> - added log rotation to all services (kallithea, celery, postgres,<br>
>> etc.), for example:<br>
>>     logging:<br>
>>       driver: "json-file"<br>
>>       options:<br>
>>         max-size: "10M"<br>
>>         max-file: "10"<br>
>><br>
>> - removed explicit container_name statements. It was unclear to me why<br>
>> you did that.<br>
>><br>
>> - removed the explicit references to kallithea_net network. As far as<br>
>> I see it is not necessary for a basic setup like this. All services<br>
>> are connected to the same network anyway.<br>
>><br>
>> - removed celerybeat. Can you clarify why it is needed? Is it used by<br>
>> Kallithea mainline?<br>
><br>
> No, it is used for an experimental feature (cron like tasks i.e. pull tasks)<br>
>><br>
>><br>
>> - I changed named volumes for kallithea_conf, kallithea_repos and db<br>
>> data to bind mounts, because it seemed easier for backup to me. But<br>
>> that is probably not 'standard' in docker world.<br>
>><br>
>> - how do you solve the problem of user permissions between the host<br>
>> system and the docker world? Files created by docker, like the db data<br>
>> directory, are owned by a non-existing user on the host system. To<br>
>> change them, I need to be root, or do changes from inside docker.<br>
><br>
> I usually use sudo<br>
>><br>
>><br>
>><br>
>> With respect to mainlining docker-related files, and some random thoughts:<br>
>> - we can avoid some duplication by splitting docker-compose.yml, for<br>
>> example the reference to the right image for kallithea, celery, and<br>
>> celerybeat could be done in docker-compose-base.yml similar to what is<br>
>> done here: <a href="https://github.com/cabotapp/docker-cabot/" rel="noreferrer" target="_blank">https://github.com/cabotapp/docker-cabot/</a><br>
><br>
> Yes, maybe. I'll look into it.<br>
>><br>
>><br>
>><br>
>> - we need to find a good way to cover different use cases. mysql<br>
>> versus postgres is currently handled by uncommenting some lines, but<br>
>> perhaps we could provide several files instead. Perhaps each of the<br>
>> choices could be in separate files, and a master docker-compose can<br>
>> include the relevant bits based on the user choice. Then the user<br>
>> should only need to change the include statements in the master<br>
>> docker-compose file.<br>
>> Also the choice of web server (gearbox, uwsgi, external reverse proxy)<br>
>> would need to be covered nicely. I'm no expert, but I guess we can<br>
>> learn from other projects.<br>
>><br>
>> - in the cabot app example I linked above (which is based on Django)<br>
>> they use alpine images for postgres and rabbitmq, which are generally<br>
>> more lightweight. I'm not sure if there are downsides to doing this.<br>
>> It could be something to consider.<br>
>><br>
>><br>
>> Best regards,<br>
>> Thomas<br>
</blockquote></div></div>