On Tue, Oct 30, 2018 at 10:59 PM Paul Adams <paul.ad...@kde.org> wrote: > > On Tue, 30 Oct 2018 at 07:28, Ben Cooksley <bcooks...@kde.org> wrote: > > Sorry, Docker might be a wonderful way to test applications, but it's > > totally unsuitable for production workloads. > > That's a bold claim. At Zalando we have 10,000s of microservices in > production and each one of them is running inside a Docker container. > this has been our deployment vector for years > > We are far from alone in this.
If you're running 10,000+ microservice instances, then you can have the teams of people needed to maintain the necessary overhead, which you go into below... We're completely different in scale - there wouldn't even be 10,000 processes (or even 5,000 to be honest) across all of the KDE servers combined. At our level of scale, having to run all the instrumentation layers you go into below actually creates more work than the benefit to be gained from it. > > > First, the contents of that Docker image can be confirmed how exactly? > > You build the image yourself, sign it and upload to your own private registry. > > > Second, it's impossible for Sysadmin to delegate management of a > > Docker container to anyone. > > There are third party tools to support this and Docker itself supports > delegation of signing and deployment. > Each team at Zalando has full autonomy to start/stop/update/deploy and > reassign their running services (and therefore the container). > > This is handled by an open source tech we have released called STUPS: > https://stups.io/ > > Sadly, this is AWS-centric, but I am sure there are other solutions > that solve the same problem. Openstack? So to make all of this work (securely), I count: 1) A private Docker registry 2) An orchestration system to manage your Docker cluster, complete with access control around who can do what 3) A system to build and sign the images you work with, and corresponding setup on your workers to validate those keys on your images. That's quite a bit of overhead. Openstack itself is quite a heavy bit of software too. > > > This means if anything goes wrong with it a Sysadmin would have to be > > the one to take a look > > Genuine comment: > Unless you are doing devops, when *anything* goes wrong I would expect > the sysadmin to be the first to react. > If you /are/ doing devops, then of course it is the deploying team who reacts. We delegate management of sites to people who look after them (where it makes sense) as it helps people get things done. They are essentially the "admin" of that specific site/service, but won't have root on the actual server that runs it. Regards, Ben > > -- > Paul J. Adams > PhD MIEEE MBCS CITP > > GPG: 07DD 0812 Paul James Adams
