在 2021年6月4日,21:51,Eneko Lacunza
<elacunza(a)binovo.es> 写道:
Hi,
We operate a few Ceph hyperconverged clusters with Proxmox, that provides a custom ceph
package repository. They do a great work; and deployment is a brezee.
So, even as currently we would rely on Proxmox packages/distribution and not upstream, we
have a number of other projects deployed with containers and we even distribute some of
our own development in deb and container packages, so I will comment on our view:
El 2/6/21 a las 23:26, Oliver Freyermuth escribió:
[...]
If I operate services in containers built by developers, of course this ensures the setup
works, and dependencies are well tested, and even upgrades work well — but it also means
that,
at the end of the day, if I run 50 services in 50 different containers from 50 different
upstreams, I'll have up to 50 different versions of OpenSSL floating around my
production servers.
If a security issue is found in any of the packages used in all the container images, I
now need to trust the security teams of all the 50 developer groups building these
containers
(and most FOSS projects won't have the ressources, understandably...),
instead of the one security team of the disto I use. And then, I also have to re-pull all
these containers, after finding out that a security fix has become available.
Or I need to build all these containers myself, and effectively take over the complete
job, and have my own security team.
This may scale somewhat well, if you have a team of 50 people, and every person takes
care of one service. Containers are often your friend in this case[1],
since it allows to isolate the different responsibilities along with the service.
But this is rarely the case outside of industry, and especially not in academics.
So the approach we chose for us is to have one common OS everywhere, and automate all of
our deployment and configuration management with Puppet.
Of course, that puts is in one of the many corners out there, but it scales extremely
well to all services we operate,
and I can still trust the distro maintainers to keep the base OS safe on all our servers,
automate reboots etc.
For Ceph, we've actually seen questions about security issues already on the list[0]
(never answered AFAICT).
These are the two main issues I find with containers really:
- Keeping hosts uptodate is more complex (apt-get update+apt-get dist-upgrade and also
some kind of docker pull+docker restart/docker-compose up ...). Much of the time the
second part is not standard (just deployed a Harbor service, upgrade is quite simple but I
have to know how to do it as it's speciffic, maintenance would be much easier if it
was packaged in Debian). I won't say it's more difficult, but it will be more
diverse and complex.
- Container image quality and security support quality, that will vary from upstream to
upstream. You have to research each of them to know were they stand. A distro (specially a
good one like Debian, Ubuntu, RHEL or SUSE) has known, quality security support for the
repositories. They will even fix issues not fixed by upstream (o backport them to
distro's version...). This is more an upstream vs distro issue, really.
About debugging issues reported with Ceph containers, I think those are things waiting
for a fix: why are logs writen in container image (or an ephemeral volume, I don't
know really how is that done right now) instead of an external name volume o a local
mapped dir in /var/log/ceph ?
All that said, I think that it makes sense for an
upstream project like Ceph, to distribute container images, as it is the most generic way
to distribute (you can deploy on any system/distro supporting container images) and eases
development. But only distributing container images could make more users depend on third
party distribution (global or specific distros), which would delay feeback/bugreport to
upstream.
Cheers and thanks for the great work!
Eneko Lacunza
Zuzendari teknikoa | Director técnico
Binovo IT Human Project
Tel. +34 943 569 206 |
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bino…
Astigarragako Bidea, 2 - 2º izda. Oficina 10-11, 20180 Oiartzun
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.yout…
https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.link…
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io