<div dir="ltr">And here is the best practice for using Dockerfile.<div><a href="https://docs.docker.com/articles/dockerfile_best-practices/">https://docs.docker.com/articles/dockerfile_best-practices/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 11:51 AM, Angus Lees <span dir="ltr"><<a href="mailto:gus@inodes.org" target="_blank">gus@inodes.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been reading a bunch of the existing Dockerfiles, and I have two humble<br>
requests:<br>
<br>
<br>
1. It would be good if the "interesting" code came from python sdist/bdists<br>
rather than rpms.<br>
<br>
This will make it possible to rebuild the containers using code from a private<br>
branch or even unsubmitted code, without having to go through a redhat/rpm<br>
release process first.<br>
<br>
I care much less about where the python dependencies come from. Pulling them<br>
from rpms rather than pip/pypi seems like a very good idea, given the relative<br>
difficulty of caching pypi content and we also pull in the required C, etc<br>
libraries for free.<br>
<br>
<br>
With this in place, I think I could drop my own containers and switch to<br>
reusing kolla's for building virtual testing environments.  This would make me<br>
happy.<br>
<br>
<br>
2. I think we should separate out "run the server" from "do once-off setup".<br>
<br>
Currently the containers run a start.sh that typically sets up the database,<br>
runs the servers, creates keystone users and sets up the keystone catalog.  In<br>
something like k8s, the container will almost certainly be run multiple times<br>
in parallel and restarted numerous times, so all those other steps go against<br>
the service-oriented k8s ideal and are at-best wasted.<br>
<br>
I suggest making the container contain the deployed code and offer a few thin<br>
scripts/commands for entrypoints.  The main replicationController/pod _just_<br>
starts the server, and then we have separate pods (or perhaps even non-k8s<br>
container invocations) that do initial database setup/migrate, and post-<br>
install keystone setup.<br>
<br>
I'm open to whether we want to make these as lightweight/independent as<br>
possible (every daemon in an individual container), or limit it to one per<br>
project (eg: run nova-api, nova-conductor, nova-scheduler, etc all in one<br>
container).   I think the differences are run-time scalability and resource-<br>
attribution vs upfront coding effort and are not hugely significant either way.<br>
<br>
Post-install catalog setup we can combine into one cross-service setup like<br>
tripleO does[1].  Although k8s doesn't have explicit support for batch tasks<br>
currently, I'm doing the pre-install setup in restartPolicy: onFailure pods<br>
currently and it seems to work quite well[2].<br>
<br>
(I'm saying "post install catalog setup", but really keystone catalog can<br>
happen at any point pre/post aiui.)<br>
<br>
[1] <a href="https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-endpoints" target="_blank">https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-endpoints</a><br>
[2] <a href="https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-db-sync-pod.yaml" target="_blank">https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-db-sync-pod.yaml</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
 - Gus<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#999999">Best wishes!<br>Baohua<br></font>
</div>