Thanks Eric for the detailed explanation, clear. Will check more for related links, thanks!
2014-08-19 7:09 GMT+08:00 Eric Windisch <ewindi...@docker.com>: > >>> On Mon, Aug 18, 2014 at 8:49 AM, Jyoti Ranjan <jran...@gmail.com> wrote: >>> >>>> I believe that everything can not go as a dock container. For e.g. >>>> >>>> 1. compute nodes >>>> 2. baremetal provisioning >>>> 3. L3 router etc >>>> >>> >>> Containers are a good solution for all of the above, for some value of >>> container. There is some terminology overloading here, however. >>> >> >> Hi Eric, one more question, not quite understand what you mean for >> "Containers are a good solution for all of the above", you mean docker >> container can manage all of three above? How? Can you please show more >> details? Thanks! >> > > I'm not sure this is the right forum for a nuanced explanation of every > use-case and every available option, but I can give some examples. Keep in > mind, again, that even in absence of security constraints offered by > Docker, that Docker provides imaging facilities and server management > solutions that are highly useful. For instance, there are use-cases of > Docker that might leverage it simply for attestation or runtime artifact > management. > > First, one could in the case of an L3 router or baremetal provisioning > where host networking is required, one might specify 'docker run -net > host' to allow the process(es) running inside of the container to operate > as if running on the host, but only as it pertains to networking. > Essentially, it would "uncontain" the networking aspect of the process(es). > > As of Docker 1.2, to be released this week, one may also specify "docker > run --cap-add" to provide granular control of the addition of Linux > capabilities that might be needed by processes (see > http://linux.die.net/man/7/capabilities). This allows granular loosing of > restrictions which might allow container-breakout, without fully opening > the gates. From a security perspective, I'd rather provide some > restrictions than none at all. > > On compute nodes, it should be possible to run qemu/kvm inside of a > container. The nova-compute program does many things on a host and it may > be difficult to provide a simplified set of restrictions for it without > running a privileged container (or one with many --cap-add statements, > --net host, etc). Again, while containment might be minimized, the > deployment facilities of Docker are still very useful. That said, all of > the really "interesting" things done by Nova that require privileges are > done by rootwrap... a rootwrap which leveraged Docker would make > containerization of Nova more meaningful and would be a boon for Nova > security overall. > > -- > Regards, > Eric Windisch > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
