i am leaning towards installing lxc. at this point i have found quite a number of packages that appear to be for lxc.
i am running Ubuntu Xenial 16.04.5 LTS last upgraded about a week ago. i would much prefer installing packages via the standard Ubuntu/Debian tools like apt-get using the Ubuntu repositories rather than pip (which i have had bad experiences with) or snap (which i have never used). what i am looking for is a list of package names to install; the essential ones and the optional ones with reasons or use cases for these.
Xenial comes with 2.0.x, which is LTS version of LXD 2. It is actually pre-installed in a standard server installation. You can upgrade to 3.0.1 which is the LTS version for LXD 3, using xenial-backports.
If you want to try this, you will first need to remove lxd/lxc/liblxc1 that came with the stock install and get 3.0.1 from backports, as per below:
i actually want lxc instead of lxd. and i am doing this on a desktop edition of Ubuntu Xenial 16.04.5, not a server edition. i have acquired a list of packages, but it might be too few or too many. it would be nice to have a list of packages (dpkg -l) from a fresh server edition to see exactly what it comes with. i do have access to AWS but i don’t know that the AWS EC2 AMI for Ubuntu Xenial would have the same packages or even have lxc at all. i’ve already built my own generic (not for any particular project) customized (lots of my commands, scripts, and tools) AMIs based on the existing Ubuntu AMI (to minimize snapshot space usage).
here is the list of package names i gathered. they were found in Ubuntu 16.04 repositories. it is not known what packages are essential, optional, benign, undesirable, or dangerous. it is not known if other packages should also be in the list. i installed them all in a chroot and the installations all succeeded. the only action i have tried in that chroot is “man lxc” which works.
I am not sure how you can get a supported setup of xenial with lxc 1.x and I am not sure why you would explicitly go for a package that has been superseded twice. This looks like a puzzle for someone who can really go out of their way to get a very specific setup.
my goal is to learn in the same sequence as i would have learned it had i not been led astray when this all began. when things first started there was no management system. at that time people learning about it could learn only the deep technical details. today, it seems most people are learning about containers as managed, and without learning those deep technical details. as i understand it, lxd has all the functions of lxc, but it executes everything through a daemon. this means i cannot see what is being done by using facilities like strace to look at the kernel syscalls or diagnose problems by looking at the errors from syscalls. in other things i have learned i end up making my own, often crude, management tools, doing things the way i usually do it. that’s why i want to start out with lxc and let it mold my view of containers as lxd. maybe i won’t need lxd. maybe i don’t even need lxc commands and can get by with just C and/or Python API bindings. i may, or may not, have time to develop bindings for Pike.
That is an admirable approach. The principle it great, and it kind of reminds me of Kelsey Hightower’s “Kubernettes the hard way”, only he does not advocate starting will obsolete, deprecated or superseded versions of it. Just building it all from scratch and understanding what each part does. You could do that, I guess, by compiling lxd from source for example. I hope you find what you are looking for.
I respectfully disagree in wanting to “mold you view of containers” by forcing yourself to forego years of development. Just because you came later to the container world, does not mean you have to take it from the start and not take advantage of all the cool work and advancement the technology has seen from inception to your first contact with it. It’s like saying that people new to Linux, should start with compiling their own kernel and modules, instead of choosing a distro, in order to mold their view on Linux without any management tools or regard for any progress or work from the community.
You can clear up any lxc package from your distro and then setup a development environment for LXC. Compile LXC, install and start using it. You will end up with the latest of LXC and you will have only the necessary tools.
i worry that the great new development will obscure my understanding of what’s underneath. running through a daemon could very well do that. and i worry a lot about something that is a management layer won’t let me automate things as easily because it is also doing automation which can end up conflicting with each other. i believe that sometimes it could be best to use lxd and sometimes lxc and sometimes even lower.
i am reading more about cgroups and namespaces. and it looks like i may not need all namespaces to be isolated even for system type containers. but i need to read on to be sure. and there is the hint that i might not even need lxc. maybe a document that explains what all lxc does (then one like it for lxd) would be good reading. but, i don’t want a sales brochure; i don’t want someone trying to tell me how great it is. it should be telling me what it is and let me figure out how great it is.
i have found a bunch of packages for lxd, as well. can you tell me what i need to actually install … what is essential and what is optional … and what i should avoid. but i will still want such a list of lxc packages, as well, before proceeding.
since i have been told this works fine in AWS EC2 instances, i will be trying things there, before here. and i can launch 2 instances.