5 ms·
This is useful for us. We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed ou
by nstott 12y ago
This is useful for us.
We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers.
Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.
- josh2600 12y agoYou can take a look at the work we've done with containers if you want over at Terminal.com. You can run it on your own metal too if you'd like. We wrote a blog post about running docker containers on it too a while ago: https://blog.terminal.com/docker-without-containers-pulldocker/ https://blog.terminal.com/docker-without-containers-pulldock...
- nstott 12y agoThat looks like a useful tool We're running on (mostly) raw lxc, with networking via openvswitch, cgroups, yada yada. so I don't think it's applicable to us at this point A containerized world makes a lot of sense, but it still seems like a really young ecosystem. It's really the 'wild west'at this point. To be honest, I'd rather back an accepted standard, then a specific implementation. Don't get me wrong, Tools like this are super valuable, and generally make my day to day life easier