Excited about etcd
There’s been a lot of buzz about Docker over the past few weeks[1], so I was intrigued when I read about CoreOS, which amongst other things is designed to be a minimal substrate for Docker. When Alex Polvi left a comment that they might be giving away t-shirts to people signing up for the Alpha that was enough to get me interested. Alex reached out shortly after I signed up, and we had a chat last week.
NJYAJEOS
Not Just Yet Another Just Enough Operating System.
The OS bit of CoreOS is pretty much what I expected – yet another Just Enough Operating System (JEOS). To a certain extent it’s even more minimal than JEOSes that have come before, which is facilitated by the fact that Docker containers drag along their dependencies with them which means that the JEOS doesn’t have to be tailor made to the application (or applications) running on it – it really can be a bare minimum, and it can also be a static target (or at least a pretty slow moving one).
Welcome to the world of matryoshka virtualisation.
Enter etcd
If CoreOS was just yet another JEOS distribution then it would be pretty uninteresting, but there’s more…
A part of the CoreOS project (probably the most important part) is etcd.
A highly-available key value store for shared configuration and service discovery.
At the most basic level etcd is a place to put configuration metadata, which is a pretty mundane thing. What makes it interesting is that it’s a distributed implementation, which allows for scale and resilience. What makes it very interesting is that it supports atomic test and set. Doing atomic actions in a distributed system is hard, and etcd employs the raft consensus algorithm to do the heavy lifting.
How will it get used?
There are lots of places where LDAP (or its proprietary sibling Active Directory) could be used (or should be used) for managing configuration metadata but isn’t because it’s too much work to get things set up[2]. The low bar to entry for using etcd should make it more accessible. I can even imagine a world where somebody might build a multi master LDAP implementation over the top of etcd.
Most clouds have some kind of instance metadata service (many mimic the AWS implementation). These are generally fine for getting configuration into an individual instance, but fall short when it comes to managing a topology of connected instances. The exception here is Google Compute Engine (GCE), which offers a key/value store that works beautifully across all instances in a given project. Anybody who’s taken advantage of the GCE approach and who then wants to do the same thing in another cloud will be reaching for etcd.
The cool kids will of course use etcd as a way of wiring their Docker containers together.
How would I use it?
For the last few years CohesiveFT has had a product called Context3 (now rebranded ‘Server3 automation’), which is a distributed topology manager. It works along the lines of init, but across an array of machines rather than an individual machine. If we ever get the chance to do a rewrite then etcd would be an ideal thing to build on.
Security and the chicken and egg problem
etcd supports SSL Client certificates for authentication, which presents something of a chicken and egg problem when it comes to the question of how did the client get its certificate in the first place (in a world where all configuration metadata is served up by etcd)? etcd is potentially very helpful with key management, whilst at the same time etcd needs some help with key management. I imagine people will end up using schemes along the lines of Chef, where an account key is used to retrieve unique instance/node keys.
There’s no sign yet of an authorization scheme, but I’m sure that will have to come (hopefully by integration to a well understood standards based service mechanism and not just some clumsy system of ACLs).
Conclusion
etcd is going to be very helpful for managing configuration metadata in distributed environments (e.g. clouds), and the need for such management will only increase as applications use additional layers of virtualization (e.g. Linux containers). The system already offers useful functionality, but its applicable scope is presently constrained by a lack of sophisticated security controls (e.g. a limited administrative domain has to be used because there’s no authorization). I’m sure that will be fixed in time, and I’ll certainly be watching the project with interest.
PS It’s implemented in Go, which is both cool and the new hotness, but definitely not luke warm.
Notes
[1] I should probably write up my impressions on Docker some other time.
[2] This discussion gets me perilously close to my rant about ‘the next Enterprise Java Bean that I see will be my first one’. Calling them Enterprise Java Beans (EJBs) implied a level of service discovery and availability that has never achieved in practice because the place that EJBs were registered was always stranded on an individual application server (or cluster) rather than being a true enterprise service; and don’t get me started about the lack of COM+ registration in AD either.
Filed under: architecture, cloud, CohesiveFT, security, software | Leave a Comment
Tags: AD, configuration, CoreOS, distributed, Docker, etcd, GCE, Go, golang, JEOS, key-value, ldap, LXC, metadata, virtualisation, vitualization
Subscribe
Search
Top Posts
- Howto - Factory Reset iLO 4 on HP Microserver Gen8
- Using Amazon EC2 as a web proxy
- ZeroSSL API - The missing examples
- Raspberry Pi GPIO Joystick
- Making an image file from an SD card on Windows
- Multi architecture automated builds for Dart binaries
- Nudging original Wileyfox Swift into OTA updates
- Getting more from a British Gas UP2 Timer
- Kindle 3G - it's a trap
- Howto: secure your DNS with a Raspberry Pi, Unbound and Cloudflare 1.1.1.1
-
Recent Posts
Recent Comments
Tim Coote on Ross Anderson RIP iain on Skiing in Espace Killy (Val… Chris Swan on Getting more from a British Ga… Murray Cowell on Getting more from a British Ga… JL on AI MacGuffin Pinboard.in bookmarks
- Here's why RISC-V is important
- The marshmallow paradox – VAT or no VAT?
- Doctrine, Droids, & Dragons: An Impassioned Plea for Unconventional Professional Development
- SARS-CoV-2 BA.1 and BA.2 breakthrough infections boost antibody responses to early Omicron subvariants but not BQ.1.1 or XBB.1.5 - ScienceDirect
- How Many Calories Do You Really Burn on Cardio Machines?
- America’s animal shelters are overwhelmed. Pets – and staff – are at breaking point
- Netflix Secret Codes 2024: Every Movie & Series Category on Netflix
- Pharmaceutical giant Bayer is getting rid of bosses and asking nearly 100,000 workers to ‘self-organize’
- View of The TESCREAL bundle: Eugenics and the promise of utopia through artificial general intelligence
- Inside the Super Nintendo cartridges
Blogroll
- 451 CAOS Theory
- Adam Bosworth’s Weblog
- Andrew McAfee
- Behavioural Investing
- CapitalSCF
- Carpe Visum
- causticTech
- Charles Stross
- confused of calcutta
- Cory Doctorow
- Craig Murray
- Dan Creswell’s Weblog
- Dark Reading
- Dilbert Blog
- DJW
- Doc Searls
- Don Box’s Spoutlet
- Dopplr
- Eben Moglen
- Enhyper
- Financial Cryptography
- Fred Destin
- Freedom to Tinker
- Graham Glass, etc.
- Greg Matter
- Hugh Grant
- Internet Alchemy
- Invisible Things
- James Strachan’s Weblog
- John Merrells
- Jon Udel
- Justice League
- Kim Cameron
- Lambda the Ultimate – Programming Languages Weblog
- Light Blue Touchpaper
- Loosely Coupled weblog
- Luke Hutteman’s Weblog
- Marc Andreeson
- Nick Selby
- ongoing
- Otaku, Cedric’s weblog
- Park Paradigm
- Paul Graham
- Phil Becker
- Pi4Tech
- PJKtech
- Radovan Janecek: Nothing Impersonal
- rants
- Richard Monson-Haefel
- SAAS
- Schneier on Security
- Service Oriented Enterprise
- Simon Phipps’s Blog
- techno.blog(“Dion”)
- The BileBlog
- THE GRID BLOG
- Tim Oren’s Due Diligence
- timbl’s blog
- virtualization.info
- WebMink
- WebServices.org
- XKCD
Categories
No Responses Yet to “Excited about etcd”