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