Open CpuID opened 8 years ago
You may find some guidance by looking at https://github.com/docker/libcompose -- which is Docker Inc's first step at rewriting Docker Compose in golang. (Presently it's a Python app that is distributed as a monolithic binary.)
Between the Python and the golang implementation, you can infer a "spec" that will allow your Ruby implementation to interop with the other to. I believe containers that represent running services are identified by a naming pattern (i.e. myproject_myservice_1
); there may be labels on the containers too.
I'm the author of the docker-compose
gem and I took the brutish but effective approach of just wrapping the docker-compose CLI. Your approach is more elegant, but of course it's more work. What you're really building is libcompose-ruby
if you want to think of it that way. Unlike docker-api
, you do not target Docker Compose's API (it has none; just a CLI). Rather, you are providing an independent reimplementation in Ruby...
I don't remember, from the top of my mind, any reason why a container started with this gem can't be deleted/removed by Docker client itself.
Anyway, I'll check it out and give you guys a feedback...
Thanks for the issue report!
+1 to Docker going down the road of rewriting docker-compose in Golang, thanks for the reference @xeger :) Considering so many of their other tools are already Golang, makes sense from a code reuse standpoint.
I am very close to considering the docker-compose
gem at the moment but I believe there was some piece of missing functionality when I looked a week ago, I'll check into what it was and report back also.
@xeger found the two things I am missing, created issues for each on the other gem repo:
https://github.com/xeger/docker-compose/issues/19 https://github.com/xeger/docker-compose/issues/20
+1
Is there a REST api for Compose?
On docker project has an open issue about it, take a look! https://github.com/docker/compose/issues/230
+1
Currently if you spin up your infrastructure using
docker-compose-api
, and try tostop
orrm
it withdocker-compose
after, nothing occurs and the containers remain running.Should the two be able to co-exist and act on the same set/s of containers? or can they only operate independently? Being that both do not run persistently or maintain any state files, I would assume there's an inconsistency between the two projects of some sort preventing it at the moment?
docker-compose version: 1.6.2