<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 Di., 14. Nov. 2017 um 21:32 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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 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>
> <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>
<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></blockquote><div>I did some experiments and some back and forth, so the history of my repo is a bit ugly. Sorry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 (<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></blockquote><div>Okay, I didn't know about that. I'll look into it, thanks. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>I did something similar. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>Why was this necessary? I mean it is probarbly a good idea but I don't see why it' be required. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Also to improve reproducibility, I added the dockerfile in the image:<br>
<br>
ADD Dockerfile $KALLITHEA_PATH<br></blockquote><div>So the idea is that somebody who downloaded the image could extract the Dockerfile and</div><div>make some modifications?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>No, it is used for an experimental feature (cron like tasks i.e. pull tasks) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>I usually use sudo </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>Yes, maybe. I'll look into it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>