Skip to content

GRR v1.3.0: People say I am rootless
Compare
Choose a tag to compare
@garden-gnome garden-gnome released this 14 Mar 09:19
· 2880 commits to develop since this release
v1.3.0
a0f431b

Lots of nice little changes and two big ones: CPU maximums support and alpha/experimental support for running containers without root.

Experimental! Support for running containers without root

This is very much a v1 which we would not suggest running in production (yet!). It is now possible to run garden without needing root (other than for one-time setup). This increases the security posture of garden and the number of places where it can potentially be used. Manual instructions and known gaps in the attached doc: https://github.com/cloudfoundry/garden-runc-release/blob/develop/docs/rootless-containers.md.

You can also opt-in using the experimental_rootless_mode bosh property which will do all the work for you!

NOTE: Not ready - or secure - for production use yet, but feedback very welcome!

CPU Maximums

It is now possible to request a maximum CPU limit proportional to the existing fair-share CPU limit. The previous cpu limit just ensured that if two containers competed for cpu they would receive it in proportion to their requested cpu share (in the Cloud Foundry use case, this meant in proportion to their memory limit). This meant, for example, if only one container was active on a host it could potentially consume all of the host's resources -- far more than were paid for.

The new cpu_quota_per_share_in_us property, which - if set - applies to all containers created on a host, enforces an additional maximum amount of cpu usage in each quota period (which unless changed on the system is 100ms) in proportion to the existing shares limit.

Example: Using Cloud Foundry as an example, since CF sets a container's cpu limit (ContainerSpec.Limits.Cpu.LimitInShares) based on the memory limit, if cpu_quota_per_share_in_us is set to 100 on a single-core system then a 64MB container will be able to use a maximum of 6.4ms (64 * 100us = 6400us = 6.4ms) of cpu every 100ms.

A Few More Things..

  • Container MTU now defaults to the MTU of the external network interface on the host rather than 1500. This is pretty much always what you want and avoids issues on environments with lower MTUs than the default.
  • We now strip all entries starting 127.* from resolv.conf on the host when setting up networking for the container. Since 127.* on the host can never be accessed in the container it's never the right thing for it to survive into the container's resolv.conf (and causes slow DNS lookups when it does).
  • Our CI now tracks container creation performance using bucket bench
  • Golang bumped to 1.8.0
  • Squished some misleading log messages. Feel good knowing you will no longer be misled (as much).

Enjoy!

Assets 4
Loading