Cgroups for the best

Reminder: Microservices

• Collection of Services
• Loosely Coupling
• Business Capabilities Oriented
• Deployable On-the-fly Independently

• Microservices Architecture

Microservices

• Business oriented: one service only does one thing
  (e.g. a settings manager module)
• Exposes an API: each service allow interaction through a standardized API
  (e.g. the settings manager exposes getter/setter for settings)
• Is independent: a service doesn’t require another one
  (e.g. the interface service get settings from the manager of fallback to defaults if unavailable)
• Rely on bus messages: a service publish changes to a common Bus
  (e.g. the settings manager push changes to the bus and the interface service register to those messages to update)
• Runs Stateless: data are stored on dedicated storage backends
  (e.g. the settings manager stores values to a shared DB)

Do You Need Microservices?

• You want to split a complex monolith architecture
• Your business is spread accross different units
• You need real scaling capabilities
• Your team can be split to multiple small projects
• Your team is pretty much DevOps skilled

When not using them?

• You’re not ready for observability
• Your team doesn’t have DevOps roles
• You don’t even know containers
• You’re running the Web version of Flappy Bird

The Multi-Languages Architecture

• Components vs Services
• Doesn’t need high DevOps skills
• Offers the Goods of Microservices
  (i.e. Scalability, Flexibility, Maintenance, etc.)
• Flappy Bird Compatible!

Isolation Benefits

• Preventing from data leaks
• Distributing resources
• Sandboxing environments
  (i.e. versions, libraries, etc.)
• Improving Observability

The POSIX Basics

• Processes: isolation of execution
• I/O Controls: isolation of access
• Message Passing: isolation of communication
• Permissions: isolation of resources

The Underlying Technology: Cgroups

• Used by every containers technology
  (Docker, containerd, LXC, etc.)
• Used at system level
  (systemd)
• Kernel-level isolation

Running On Your Own

• Pros:
  • Built-in the Kernel
  • Lot of documentation
  • Standardized
• Cons:
  • Need High Linux Skills
  • Not “just push an image”

Cloud Definition

• High-availabily
• Elastic Scalability
• Embedded Services
• Edge Infrastructure
• Native Isolation

Cgroups Based Isolation

• Isolation per User
• Cgroup per Process per User
• POSIX Permissions for Resources

# ls -l /sys/fs/cgroup/system.slice/container.service/users/intranet/proxy/apache.upstream

-r--r--r-- 1 root root 0 Apr 13 14:37 cgroup.controllers
-r--r--r-- 1 root root 0 Apr 13 14:37 cgroup.events
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.freeze
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.max.depth
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.procs
-r--r--r-- 1 root root 0 Apr 13 14:37 cgroup.stat
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.threads
-rw-r--r-- 1 root root 0 Apr 13 14:37 cgroup.type
...

# cat /sys/fs/cgroup/[...]/apache.upstream/cgroup.procs

986352
1297585
1297586
1297587
3598699

Setting the Limits

• Cgroups Native Capability
• Writing into files
• Capping Hardware Resources
• Using Kernel balances features

# cat /sys/fs/cgroup/[...]/apache.upstream/memory.max

4294967296

Orchestrating: Running the Containers

• Need a Central Interface
  (i.e. a-la-Kubernetes)
• Manage Cgroups CRUD
• Interact with Users’ Profiles

Interfacing: PAM and iptables

• Sanboxing any process
• SSH process: PAM script
• Network: iptables for private ips

Going Further: Namespaces

• Partition Kernel Resources
• Used in every containers technology
• Useful but not mandatory