rebar3
http://lists.basho.com/pipermail/rebar_lists.basho.com/2016-March/002342.html
- in github.com/erlang !
rebar3 shell
: code paths, boots up applications.
- rebar agent as r3 with a name:
r3:do(compile)
r3:do(dialyse)
- r3 name can be used for IDE tooling
- plugins for rebar3 agent: rebar3_auto recompiles modified files
- rebar3 shell detect release configurations, so boot the system the way release would
rebar3 tree
to see the deps tree (first wins deps resolution strategy)
overrides
feature. allow replace or add configuration for an app at a lower level (deps)
profiles
feature to manage env and options
- test profile - use neck, eunit_opts, etc
- release profile - to add erts
dependency tracking
feature
- each time it runs
compile
it’ll verify deps
- hex packages are cached
rm -rf deps
is not needed anymore
- tradeoff between repeatability and efficiency for developer
- deps are never rebuilt even if sources are changed by hands
checkout dependencies
feature with _checkout
directory that is used at first place
- if sources for deps are changed in
_checkout
, they’re recompiled and used
Paper “Borg, Omega, Kubernetes”
http://queue.acm.org/detail.cfm?id=2898444
- Borg - run long lived processes + batch jobs
- Omega - offspring of Borg. Stored the state of the cluster in a centralised Paxos-based transaction-oriented store, that was accessed by different parts of the cluster control plane (schedulers). Optimistic concurrency control. Instead of Borgmaster - several peers
- Kubernetes - open sourced. Also shared persistent store, with components watching for changes to relevant objects. Store is access through REST API. Focus on the experience of developers writing complex distributed systems, also benefits from improved utiziation.
- Containers. FreeBSD jails -> Linux cgroups. Resource isolation + image.
- Application-oriented Infrastructure. Containerization transforms the data center from being machine oriented to being application oriented:
- Container abstracted away many details of machine and OS from developer.
- container + container image -> for one application => managing containers means managing apps, not machines.
- the same deployment environment in both development and production
- improves deployment reliability
- speeds up development by reducing inconsistencies and friction.
- isolation is not complete: /proc is not fully supported. All hopes are for the OpenContainer initiative
- Borg showed problems with updating base OS image (tar, libc, etc), though, all applications are statically linked
- Docker and ACI images are more hermetic,
- Containers as the unit of management.
- application developers don’t worry about OS or machine details
- easy hardware update and OS update
- ties telemetry to the application rather than machine, improves monitoring and introspection
- provide convenient points to register geenric APIs (health for container, etc)
- logs are collected by applications, not machines
- Orchestration is the beginning, not the end
- Consistency is achieved with: higher level services all share the same common basic building blocks. Autoscaling + replica controller.
- Consistency is also achieved though common design patterns for different k8s components. Reconciliation controller loop: compare a desired state against the observed state => takes actions. Fail -> repeat.
- Choreography - achieving the desired behaviour by combining the effects of separate, autonomous entities that collaborate. Contrast - Orchestration - centralized one, more simple at first, but more difficult to support.
- Things to avoid
- Don’t Make the Container System Manage Port Numbers
- Don’t Just Number Containers: Give Them Labels
- Be Careful with Ownership
Borg: job -> task. Kubernetes: replication controller uses label selector. Remove label -> start new container, while the old is available for debug.
- Don’t Expose Raw State
- Some Open, Hard Problems
- Configuration. set of values supplied to applications, rather than hard-coded into them.
- Dependency Management