<div dir="ltr">Hi,<br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 7:13 PM Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote:<br>
> Changing the topic to follow the subject.<br>
> <br>
> [tl;dr] it's time to rearchitect container images to stop incluiding <br>
> config-time only (puppet et al) bits, which are not needed runtime<br>
> and <br>
> pose security issues, like CVEs, to maintain daily.<br>
<br>
I think your assertion that we need to rearchitect the config images to<br>
container the puppet bits is incorrect here.<br>
<br>
After reviewing the patches you linked to below it appears that you are<br>
proposing we use --volumes-from to bind mount application binaries from<br>
one container into another. I don't believe this is a good pattern for<br>
containers. On baremetal if we followed the same pattern it would be<br>
like using an /nfs share to obtain access to binaries across the<br>
network to optimize local storage. Now... some people do this (like<br>
maybe high performance computing would launch an MPI job like this) but<br>
I don't think we should consider it best practice for our containers in<br>
TripleO.<br>
<br>
Each container should container its own binaries and libraries as much<br>
as possible. And while I do think we should be using --volumes-from<br>
more often in TripleO it would be for sharing *data* between<br>
containers, not binaries.<br>
<br>
<br>
> <br>
> Background:<br>
> 1) For the Distributed Compute Node edge case, there is potentially<br>
> tens <br>
> of thousands of a single-compute-node remote edge sites connected<br>
> over <br>
> WAN to a single control plane, which is having high latency, like a <br>
> 100ms or so, and limited bandwith. Reducing the base layer size<br>
> becomes <br>
> a decent goal there. See the security background below.<br>
<br>
The reason we put Puppet into the base layer was in fact to prevent it<br>
from being downloaded multiple times. If we were to re-architect the<br>
image layers such that the child layers all contained their own copies<br>
of Puppet for example there would actually be a net increase in<br>
bandwidth and disk usage. So I would argue we are already addressing<br>
the goal of optimizing network and disk space.<br>
<br>
Moving it out of the base layer so that you can patch it more often<br>
without disrupting other services is a valid concern. But addressing<br>
this concern while also preserving our definiation of a container (see<br>
above, a container should contain all of its binaries) is going to cost<br>
you something, namely disk and network space because Puppet would need<br>
to be duplicated in each child container.<br>
<br>
As Puppet is used to configure a majority of the services in TripleO<br>
having it in the base container makes most sense. And yes, if there are<br>
security patches for Puppet/Ruby those might result in a bunch of<br>
containers getting pushed. But let Docker layers take care of this I<br>
think... Don't try to solve things by constructing your own custom<br>
mounts and volumes to work around the issue.<br>
<br>
<br>
> 2) For a generic security (Day 2, maintenance) case, when <br>
> puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to<br>
> be <br>
> updated and all layers on top - to be rebuild, and all of those<br>
> layers, <br>
> to be re-fetched for cloud hosts and all containers to be<br>
> restarted... <br>
> And all of that because of some fixes that have nothing to OpenStack.<br>
> By <br>
> the remote edge sites as well, remember of "tens of thousands", high <br>
> latency and limited bandwith?..<br>
> 3) TripleO CI updates (including puppet*) packages in containers, not<br>
> in <br>
> a common base layer of those. So each a CI job has to update puppet*<br>
> and <br>
> its dependencies - ruby/systemd as well. Reducing numbers of packages<br>
> to <br>
> update for each container makes sense for CI as well.<br>
> <br>
> Implementation related:<br>
> <br>
> WIP patches [0],[1] for early review, uses a config "pod" approach,<br>
> does <br>
> not require to maintain a two sets of config vs runtime images.<br>
> Future <br>
> work: a) cronie requires systemd, we'd want to fix that also off the <br>
> base layer. b) rework to podman pods for docker-puppet.py instead of <br>
> --volumes-from a side car container (can't be backported for Queens <br>
> then, which is still nice to have a support for the Edge DCN case,<br>
> at <br>
> least downstream only perhaps).<br>
> <br>
> Some questions raised on IRC:<br>
> <br>
> Q: is having a service be able to configure itself really need to <br>
> involve a separate pod?<br>
> A: Highly likely yes, removing not-runtime things is a good idea and <br>
> pods is an established PaaS paradigm already. That will require some <br>
> changes in the architecture though (see the topic with WIP patches).<br>
<br>
I'm a little confused on this one. Are you suggesting that we have 2<br>
containers for each service? One with Puppet and one without?<br>
<br>
That is certainly possible, but to pull it off would likely require you<br>
to have things built like this:<br>
<br>
 |base container| --> |service container| --> |service container w/<br>
Puppet installed|<br>
<br>
The end result would be Puppet being duplicated in a layer for each<br>
services "config image". Very inefficient.<br>
<br>
Again, I'm ansering this assumping we aren't violating our container<br>
constraints and best practices where each container has the binaries<br>
its needs to do its own configuration.<br>
<br>
> <br>
>  Q: that's (fetching a config container) actually more data that<br>
> about to <br>
>   download otherwise<br>
> A: It's not, if thinking of Day 2, when have to re-fetch the base<br>
> layer <br>
> and top layers, when some unrelated to openstack CVEs got fixed<br>
> there <br>
> for ruby/puppet/systemd. Avoid the need to restart service<br>
> containers <br>
> because of those minor updates puched is also a nice thing.<br>
<br>
Puppet is used only for configuration in TripleO. While security issues<br>
do need to be addressed at any layer I'm not sure there would be an<br>
urgency to re-deploy your cluster simply for a Puppet security fix<br>
alone. Smart change management would help eliminate blindly deploying<br>
new containers in the case where they provide very little security<br>
benefit.<br>
<br>
I think the focus on Puppet, and Ruby here is perhaps a bad example as<br>
they are config time only. Rather than just think about them we should<br>
also consider the rest of the things in our base container images as<br>
well. This is always going to be a "balancing act". There are pros and<br>
cons of having things in the base layer vs. the child/leaf layers.<br></blockquote><div><br></div><div>It's interesting as puppet is required for config time only, but it is kept in every image whole its life. There is a pattern of side cars in Kubernetes where side container configures what's needed for main container and dies.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> <br>
> Q: the best solution here would be using packages on the host, <br>
> generating the config files on the host. And then having an all-in-<br>
> one <br>
> container for all the services which lets them run in an isolated<br>
> mannner.<br>
> A: I think for Edge cases, that's a no go as we might want to<br>
> consider <br>
> tiny low footprint OS distros like former known Container Linux or <br>
> Atomic. Also, an all-in-one container looks like an anti-pattern<br>
> from <br>
> the world of VMs.<br>
<br>
This was suggested on IRC because it likely gives you the smallest<br>
network/storage footprint for each edge node. The container would get<br>
used for everything: running all the services, and configuring all the<br>
services. Sort of a golden image approach. It may be an anti-pattern<br>
but initially I thought you were looking to optimize these things.<br></blockquote><div><br></div><div>It is antipattern indeed. The smaller container is the better. Less chance of security issues, less data to transfer over network, less storage. In programming there are a lot of patterns to reuse code (OOP is a sample). So the same pattern should be applied to containers rather than blindly copy data to every container.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think a better solution might be to have container registries, or<br>
container mirrors (reverse proxies or whatever) that allow you to cache<br>
things as you deploy to the edge and thus optimize the network traffic.<br></blockquote><div><br></div><div>This solution is good addition but containers should be tiny and not fat.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> <br>
> [0] <a href="https://review.openstack.org/#/q/topic:base-container-reduction" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:base-container-reduction</a><br>
> [1] <br>
> <a href="https://review.rdoproject.org/r/#/q/topic:base-container-reduction" rel="noreferrer" target="_blank">https://review.rdoproject.org/r/#/q/topic:base-container-reduction</a><br>
> <br>
> > Here is a related bug [1] and implementation [1] for that. PTAL<br>
> > folks!<br>
> > <br>
> > [0] <a href="https://bugs.launchpad.net/tripleo/+bug/1804822" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1804822</a><br>
> > [1] <a href="https://review.openstack.org/#/q/topic:base-container-reduction" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:base-container-reduction</a><br>
> > <br>
> > > Let's also think of removing puppet-tripleo from the base<br>
> > > container.<br>
> > > It really brings the world-in (and yum updates in CI!) each job<br>
> > > and each <br>
> > > container!<br>
> > > So if we did so, we should then either install puppet-tripleo and<br>
> > > co on <br>
> > > the host and bind-mount it for the docker-puppet deployment task<br>
> > > steps <br>
> > > (bad idea IMO), OR use the magical --volumes-from <a-side-car-<br>
> > > container> <br>
> > > option to mount volumes from some "puppet-config" sidecar<br>
> > > container <br>
> > > inside each of the containers being launched by docker-puppet<br>
> > > tooling.<br>
> > <br>
> > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås <hjensas at<br>
> > <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a>> <br>
> > wrote:<br>
> > > We add this to all images:<br>
> > > <br>
> > > <a href="https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35</a><br>
> > > <br>
> > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2<br>
> > > python<br>
> > > socat sudo which openstack-tripleo-common-container-base rsync<br>
> > > cronie<br>
> > > crudini openstack-selinux ansible python-shade puppet-tripleo<br>
> > > python2-<br>
> > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB <br>
> > > <br>
> > > Is the additional 276 MB reasonable here?<br>
> > > openstack-selinux <- This package run relabling, does that kind<br>
> > > of<br>
> > > touching the filesystem impact the size due to docker layers?<br>
> > > <br>
> > > Also: python2-kubernetes is a fairly large package (18007990) do<br>
> > > we use<br>
> > > that in every image? I don't see any tripleo related repos<br>
> > > importing<br>
> > > from that when searching on Hound? The original commit message[1]<br>
> > > adding it states it is for future convenience.<br>
> > > <br>
> > > On my undercloud we have 101 images, if we are downloading every<br>
> > > 18 MB<br>
> > > per image thats almost 1.8 GB for a package we don't use? (I hope<br>
> > > it's<br>
> > > not like this? With docker layers, we only download that 276 MB<br>
> > > transaction once? Or?)<br>
> > > <br>
> > > <br>
> > > [1] <a href="https://review.openstack.org/527927" rel="noreferrer" target="_blank">https://review.openstack.org/527927</a><br>
> > <br>
> > <br>
> > -- <br>
> > Best regards,<br>
> > Bogdan Dobrelya,<br>
> > Irc #bogdando<br>
> <br>
> <br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Best Regards,<br>Sergii Golovatiuk</div></div>