Hacker News new | ask | show | jobs
by pedoh 4646 days ago
Part two is up: http://codeascraft.com/2013/09/23/lxc-automating-containers-...

It looks like they're not leveraging LXC via Docker. I wonder if that's because they've been doing it this way pre-Docker, or if there are some technical reasons why it made sense to skip it.

1 comments

They've probably been doing it long before Docker, as most people who use LXC have been. Also, it makes sense to skip it because Docker adds relatively little for their use case.
Precisely, you've nailed it.

Docker is great when it fits your use-case, but there are lots of practical ways in which LXC stands great all on it's own.

I've commented on HN before about why I often choose plain LXC over Docker: https://news.ycombinator.com/item?id=6378823

You have any good resources on vanilla LXC?
The ubuntu docs are pretty good: https://help.ubuntu.com/lts/serverguide/lxc.html

And also the lxc-user mailing list is a great resource: https://lists.sourceforge.net/lists/listinfo/lxc-users

Yeah, in general if you have a production system in place there's not much incentive to rip it out and replace it with something else - especially if your system is relatively new and shiny.

It becomes more interesting when a) your system has been running long enough that you've learned operational and design lessons that justify an upgrade, or b) you're starting fresh on a new architecture.

Most of the Docker community is made of these groups A and B. If you're starting from scratch, or if making significant changes anyway, it makes a lot of sense to federate the development effort and reap the benefits of code reuse, common tools etc.

That is absolutely correct. We started this before Docker existed. Also LXC is simple enough to do on your own that we haven't had a compelling reason to replace our tools with any others. Docker definitely has some cool features though!