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?
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 https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-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 https://12factor.net/
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 https://www.openshift.org/minishift/
Since the conferences this has turned up too… https://www.telepresence.io/ (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