Powerstrip: prototype Docker extensions today(clusterhq.com)
clusterhq.com
Powerstrip: prototype Docker extensions today
https://clusterhq.com/blog/powerstrip-prototype-docker-extensions-today
15 comments
Do you know if Powerstrip could be used to extend the entire family of Docker tools: machine, compose (fig), swarm?
I think it would be interesting, for example, to explore development of an extension that "guided" those tools regarding where (virtually speaking) they should re/deploy machines and containers, based on metrics collected by a 3rd party service with which that extension communicated.
I apologize if my question is a bit naïve; at present, I've been spending a lot of time with the porcelain and haven't gotten into the internals enough to understand how all the Docker pieces truly fit together.
I think it would be interesting, for example, to explore development of an extension that "guided" those tools regarding where (virtually speaking) they should re/deploy machines and containers, based on metrics collected by a 3rd party service with which that extension communicated.
I apologize if my question is a bit naïve; at present, I've been spending a lot of time with the porcelain and haven't gotten into the internals enough to understand how all the Docker pieces truly fit together.
Hey Michael!
Powerstrip can be used to prototype extending anything which speaks the Docker API. So in theory it could be used in front of swarm, as well as behind it.
I'm also interested in finding a way to prototype extensions to the Docker CLI experience... this is the next logical step, and something we should talk about. :)
Just to be clear, as well, powerstrip is all about finding ways to prototype things. I believe that the way that it gets used can go a long way to figuring out what the best extensions points in Docker itself are.
IMO, the powerstrip project will be a success precisely if we can throw it away in a few months because we've used the results from the powerstrip experiment to build the right extensions mechanism into Docker itself that we can use instead ;)
Cheers, Luke
Powerstrip can be used to prototype extending anything which speaks the Docker API. So in theory it could be used in front of swarm, as well as behind it.
I'm also interested in finding a way to prototype extensions to the Docker CLI experience... this is the next logical step, and something we should talk about. :)
Just to be clear, as well, powerstrip is all about finding ways to prototype things. I believe that the way that it gets used can go a long way to figuring out what the best extensions points in Docker itself are.
IMO, the powerstrip project will be a success precisely if we can throw it away in a few months because we've used the results from the powerstrip experiment to build the right extensions mechanism into Docker itself that we can use instead ;)
Cheers, Luke
Hi,
because powerstrip presents a standard docker HTTP api - it can certainly be used to interact with any other tool that talks standard docker HTTP.
For example - I put together a small run-through in powerstrip-weave where fig can be used to allocate weave IP addresses:
https://github.com/binocarlos/powerstrip-weave/tree/master/e...
Fig speaks to the powerstrip HTTP api which in turn speaks to the weave adapter.
It would definitely be interesting to have some kind of cadvisor adapter (or equivalent) that was automatically feeding back metrics to some kind of scheduler.
The main point is to allow the vanilla docker client to interact with powerstrip and therefore by extension - all of the existing orchestration tools.
because powerstrip presents a standard docker HTTP api - it can certainly be used to interact with any other tool that talks standard docker HTTP.
For example - I put together a small run-through in powerstrip-weave where fig can be used to allocate weave IP addresses:
https://github.com/binocarlos/powerstrip-weave/tree/master/e...
Fig speaks to the powerstrip HTTP api which in turn speaks to the weave adapter.
It would definitely be interesting to have some kind of cadvisor adapter (or equivalent) that was automatically feeding back metrics to some kind of scheduler.
The main point is to allow the vanilla docker client to interact with powerstrip and therefore by extension - all of the existing orchestration tools.
I've been hacking on a powerstrip adapter for the past few weeks (https://github.com/binocarlos/powerstrip-weave) and have found it a pleasure to work with.
Capturing JSON messages on their way to the docker server is a far more civilised way to extend docker than trying to "wrap" the docker cli.
In my use case - using the cli - I was struggling to separate the docker arguments from the image name and container args. It's better for docker itself to do that and more generally - its better to use the vanilla docker client (because orchestration tools).
As soon as I was working with the JSON messages generated by the docker client - everything became much easier!
Capturing JSON messages on their way to the docker server is a far more civilised way to extend docker than trying to "wrap" the docker cli.
In my use case - using the cli - I was struggling to separate the docker arguments from the image name and container args. It's better for docker itself to do that and more generally - its better to use the vanilla docker client (because orchestration tools).
As soon as I was working with the JSON messages generated by the docker client - everything became much easier!
If you are looking to build an extension, make sure to checkout the post by @binocarlos [1], it's just the right level of detail for you know and a full-blow implementation indeed!
[1]: http://weaveblog.com/2015/01/29/powerstrip-weave-a-docker-ne...
[1]: http://weaveblog.com/2015/01/29/powerstrip-weave-a-docker-ne...
The Wordpress on this site is dead, why don't more people use static html generators these days? It doesn't get more web scale than static html via pelican or Jekyll or something :)
I'm quite happy to see this happening however and see that the batteries included, but removable mantra really is actually happening.
I'm quite happy to see this happening however and see that the batteries included, but removable mantra really is actually happening.
we just moved our very own https://crate.io site from wordpress to cactus (python-based, https://github.com/koenbok/cactus).
just opened our github repo: https://github.com/crate/crate-web
it also includes a script to pull in existing wordpress blog posts.
We're working on moving to a static site generator :)
That said one emergency mod_rewrite rule later and we fixed the issue - which was that the HN link went to the link without the trailing slash which was hitting the database! :'(
That said one emergency mod_rewrite rule later and we fixed the issue - which was that the HN link went to the link without the trailing slash which was hitting the database! :'(
Yes, we are also glad to be involved in making "batteries included but removeable" really happen :)
we at crate switched to https://github.com/koenbok/cactus and are really happy with it. we had a really bad experience with wordpress and are so glad we switched.
[deleted]
An interesting project would be to implement a policy extension, one that would check where container image has the right versions of certain packages and would refuse to start a container with outdate JRE, OpenSSL or anything more recent...
Definitely! We have https://github.com/ClusterHQ/powerstrip#additional-adapter-i... and https://github.com/ClusterHQ/powerstrip/issues/8 for ideas... please add more!
[deleted]
We're also planning to combine the Docker event stream plugin system I prototyped previously into Powerstrip: https://github.com/progrium/docker-plugins
And ultimately, eventually, we'll have native extension support in Docker that allows much more extensibility, but all this is a good first step IMO.