DevopsDays Edinburgh 2017 – A Big Pile of Micro Services Advice :

Blue sky

Inside the Container. 

What OS should go into a microservices container?

Alpine is a tiny footprint Unix like OS. Running it in a read-only docker image with no SSH is the basis of a syatem with a very limited attack surface. This is very much the tiny no-attack surface approach – rather than the RedHat with its “another layer to administer approach”. Great for Node.JS! but Java is just plain massive and risky ridden, so loses a lot of the advantages. As a dev

Many people declared they used Java as the langauge for microservices – but there were significant NodeJS and Ruby contingents plus a couple of C / bare metal enthusiasts.

So RedHat based for Java and alpine for NodeJS. A bit like whether you have lots of stained glass windows and lots of gold in a church or not, this was an indication of a bit of a schism. Are the extra bells and whistles essential for security or do they just complicate things?

Securing Containers

Some steps to securing a container…

  • No root login – this is a security risk on Docker.
  • limit ssh – if possible none.
  • namespaces – chroot etc.
  • logging – a separate service
  • resource restriction – so a runaway container doesn’t consume everything (you need to leave headroom for the loggin service if nothing else).
  • Don’t run anything as root. (aside – people have been known to build rpms as root – so the whole install goes in as owned by root).

Kubernetes to Configure Containers

Kubernetes configmaps & secrets

OpenShift does the same thing as k8s but provides multitenancy support. For people who still like one big mess of servers.

Use Kubernetes for configuring persistent storage – many options due to the flexibility of Unix filesystems.

RedHat – very Enterprise

The RedHat guy was very much in favour of seLinux. As a general rule the RedHat presentation still had a siloed approach, with a high cognitive load “add another layer and use an enterprise stack”. Having said that OpenStack has a place in multi-tenancy. But, to go all metaphorical, if you’ve ever lived with a family in a tenemental stair you don’t wonder why people favour detatched houses. The simplicity of responsibility and

Running micro-services – much agreement on services, and less agreement on tools. 12 Factor App

Playing with Micro-Services

Kubernetes for the Faint Hearted

“Kubernetes nice but don’t I need a cluster before I can develop on it…?” Minikube is the answer. It has a cousin for OpenShift

Since the conferences this has turned up too… (if you have SSH access to the proxy server it sets up a VPN – see notes on not having SSH access on live micro-services) – this definitely works with Minikube but what about MiniShift?

When Micro-Services Go bad!

Sprawling… Coupling… Too many services not enough people… Multilayered rather than flat… Poor API documentation…

A MicroServices Top-tip:
Log the caller stack. Who called who in response to what web request.

Failure cases and dependencies