Docker Compose Wrapper

by shouze • 10 years ago

38 24 10 years ago

skrebbel• 10 years ago

So this is a wrapper around a wrapper around a wrapper around linux containers? Is there any level at which this ever becomes user friendly?

redmar• 10 years ago

we need to go deeper

alexandrerond• 10 years ago

Maybe you can wrap it again to make it user friendly?

mpweiher• 10 years ago

Needs a middleware abstraction layer.

pkaye• 10 years ago

Docker... it's wrappers all the way down...

storrgie• 10 years ago

systemd-nspawn seems like it makes sense...

dacompton• 10 years ago

Is this a joke?

cakes• 10 years ago

I smiled to myself for a moment and that was immediately followed by that question.

Myrmornis• 10 years ago

I sympathize with this question but I think this thread is actually mocking someone's well-intentioned and serious project. Personally I have at minimum a "dc" alias and I can totally see how one might start evolving that into a shell wrapper to make your common tasks less verbose. But perhaps the author envisioned it saving more typing and being more generally useful than it is, and also under-estimated the importance of the increased surface for errors and bugs that the project brings.

alixaxel• 10 years ago

I'm just smiling now. :)

manojlds• 10 years ago

This might be more helpful -https://github.com/grammarly/rocker-compose

arez• 10 years ago

would you recommend it over docker-compose? Because I'm really searching for an alternative and it's in go, that's even better for me

rmurri• 10 years ago

I use https://github.com/michaelsauter/crane.

It has held up really well for me.

heitortsergent• 10 years ago

There's also this one: https://github.com/azukiapp/azk

ersoft• 10 years ago

I'm using azk[0] for my development workflow with 30+ services defined in one Azkfile.js. It automatically setups http load balancers and dns services for you, no need for container linking.

[0] https://github.com/azukiapp/azk

yahyaheee• 10 years ago

What docker compose needs is a scheduler

dominotw• 10 years ago

you can use it (with caveats) docker swarm.

zimbatm2• 10 years ago

Does any of these solutions give me back live-reload when developing web apps on OSX ?

As far as I know the code is uploaded into the container and only gets replaced when the image is re-created. At which point there are issues with private git dependencies because it can't access the SSH_AUTH_SOCK.

athyuttamre2• 10 years ago

You could host a volume into your container containing the code base. Then use any standard live reloading library to make it work.

sillypog• 10 years ago

If the live reloading library relies on inotifywait, it won't detect changes made on the OSX side across the volume due to issues with Virtual Box. I made a utility that I run in my container while I'm developing to trigger these events: https://github.com/sillypog/inotify-proxy

zimbatm2• 10 years ago

Does it mean that I need two docker compose, one for development and one for deployment ?

markbnj• 10 years ago

We run containers locally for components that our code needs, i.e. if the code needs redis, or elasticsearch or whatever it's easier to spin up a local container, keeps the dev system free of clutter, and what you're running can often be the same or very close to what is in prod. For our own code, why should it care whether it is running in a container or not? We develop locally on the host and package into a container at deployment.

frnhr• 10 years ago

Wrappers all the way down!

Docker Compose Wrapper

Related Stories