Discourse

[Ben Cooksley]

On Tue, Oct 30, 2018 at 10:59 PM Paul Adams <paul.adams at kde.org> wrote:
>
> On Tue, 30 Oct 2018 at 07:28, Ben Cooksley <bcooksley at 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