On Wed, Jan 18, 2017 at 12:15 PM, Guido Jäkel <g.jae...@dnb.de> wrote: >> Here is my opinion on it: >> >> 1) We do need documentation, especially tutorials. Lots and lots of >> tutorials and how-tos . LXD and Docker compete in different niches, but >> LXD can easily do what Docker does (and sometimes better in certain >> situations) and part of the reason that Docker is used so much is >> because of the volume of articles/tutorials for setting it up in >> production scenarios. >> >> 2) I agree with the poster who mentioned that the archive is not >> searchable (but should be IMO). Is there some way to make it a >> searchable archive? I understand that there are software-tools that >> allow the conversion of mail-archives into a forum-like appearance, so >> that might help > > Dear all, > > I ask about such some years before. But in my opinion, a typical forum is not > much better than list mail -- I would suggest to present all the community > information as a Wiki space or something in that way! > > Because to my (mostly bad) experiences, in a forum the information is spread > around in different threads. And you have to read through pages of statements > to extract the "core" and/or "head" of information. In a typical Wiki, you'll > get the most up-to-date information on the main page, you may use an history > to extract changes and there might be a comment feature enabled for > discussions. And a typical wiki engine would allow to search in a > full-text-index, of corse. > > I think, one important topic for HowTo's is around networking. This is > because LXC/LXD (and others) become more and more easy to use. This is a > great success, but in the other hand it attract more and more users with a > lower level of basic skills.
Yes! Part of it is that LXD's network configuration steps are a bit different from some of its predecessors in the container/virt space, like OpenVZ and VMware, so people trying to "migrate" to LXD instead get a migraine trying to learn new networking concepts so they can wrap their head around the network configuration for LXD. I currently run LXD in production with about 8 containers on a non-mission-critical server (if it crashes, it's not the end of the world), and things are going very well -- it's stable, secure enough for my needs, great guest/host isolation, guests can do all the things I expect them to be able to do, etc. -- but the one area that still eludes me to this day is how exactly macvlan works. To me, macvlan is just a magic black box. I followed a tutorial by rote on one of stgraber's blogs and got it working perfectly, but if it ever breaks, I won't be able to dig very deep in my troubleshooting efforts due to the perceived opacity of the technology and the weird way it works compared to traditional networking (physical interfaces and bridges are about as far as I go, normally; but I don't even know where macvlan sits in the OSI model!). I think we need some (better) pictures/diagrams, analogies, concrete examples, etc. for some of the more common networking topologies involving LXD, even if the "details" of those networking setups are not a feature of LXD itself (if we are borrowing features from the Linux kernel and expecting our users to use them to accomplish tasks, it would be helpful to explain how those features work in a user-friendly way.) And I'd like to see "LXD hardening" guides for doing system-level configuration unrelated to LXD to increase the security of LXD. For example, if you are exposing a public /27 IP subnet to a bunch of LXD containers through macvlan, out of the box there is nothing preventing one of those containers' root users from acquiring and using any IP address within that /27. This is a very bad thing for hosting companies with multi-tenant boxes, so we just have to hope that nobody is going to try and start a hosting company based on LXD and then launch their service without locking that down. Ideally, the host-side configuration would specify which exact IP(s) each container can use, and the container's root user can do nothing to circumvent those restrictions. In the end, what I envision LXD as capable of becoming, is something equivalent from a user's perspective to VMware, where all the sysadmin's assumptions about isolation and security in VMware (except sharing the same kernel) also hold in LXD, except that since you're not doing virtualization, your performance overhead is extremely low. And in practice, the "sharing the same kernel" bit *shouldn't* be a security problem, because if the Linux kernel security team does their job, the vulnerabilities will get found and closed in short order so your customers can't break out of the container. Then you just have to enable rebootless kernel updates on the host and you're good to go. But LXD out of the box is a long way from that. It can probably be made to work that way if you know enough about which isolation weaknesses exist and how to close them using system tools, but I personally don't know how to do that. So unless there are plans to make the LXD code automatically fix those weaknesses (e.g., as mentioned, restricting the IPs that each container can use), we need documentation and maybe helper scripts to take care of it so people can start using LXD in production. It *would* be great to see some of those commercial hosting providers who are still on the OpenVZ stable 2.6.32 kernel, upgrading to the much faster and more featureful modern 4.x kernel with LXD instead of OpenVZ. But not as long as container root users can trample on another user's IP address with a single `ifconfig` command :) TL;DR: +1 for "production use case" LXD docs, please. Sean > > To promote LXC, a section with success stories would be great, too. > > > Grüße > > Guido > > _______________________________________________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
