Changes

Jump to: navigation, search

LXD

595 bytes removed, 1 month ago
no edit summary
}}
=== Features =Another Nice LXD Administration Tutorial ==
Some of the biggest This section contains another nice LXD tutorial that can be used to learn more about profiles and other features of LXD are: * Secure by design (unprivileged containers, resource restrictions and much more)* Scalable (from containers on your laptop to thousand of compute nodes)* Intuitive (simple, clear API and crisp command line experience)* Image based (no more distribution templates, only good, trusted images)* Live migration ==== Unprivileged Containers ====.
LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level). The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container. The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them. From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user. LXD does offer a number of options related to unprivileged configuration: * Increasing the size of the default uid/gid map* Setting up per-container maps* Punching holes into the map to expose host users and groups === Relationship with LXC Terminology ===LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go bindingto create and manage the containers. It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network. === Licensing ===LXD is free software and is developed under the Apache 2 license. <hr><hr>Let's break this tutorial into smaller parts. Please click on the headings to go to the section's text. <hr><hr> == [[LXD/LXD Installation|PART II - LXD Installation]] == == [[LXD/LXD Setup|PART III - LXD Setup]] == == Containers, snapshots and images =='''Containers''' in LXD are made of:* A filesystem (rootfs)* A list of configuration options, including resource limits, environment, security options and more* A bunch of devices like disks, character/block unix devices and network interfaces* A set of profiles the container inherits configuration from (see below)* Some properties (container architecture, ephemeral or persistent and the name)* Some runtime state (when using CRIU for checkpoint/restore)
Container '''snapshots''' as the name states snapshots of the container in time and cannot be modified in any way. It is worth noting that because snapshots can store the container runtime state, which gives us ability of “stateful” snapshots. That is, the ability to rollback the container including its cpu and memory state at the time of the snapshot.
| Ubuntu Trusty (14.04 LTS) - EOL 2019-04 || upstart || Working
|}
 
== Features ==
 
Some of the biggest features of LXD are:
 
* Secure by design (unprivileged containers, resource restrictions and much more)
* Scalable (from containers on your laptop to thousand of compute nodes)
* Intuitive (simple, clear API and crisp command line experience)
* Image based (no more distribution templates, only good, trusted images)
* Live migration
 
==== Unprivileged Containers ====
 
LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level).
 
The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container.
 
The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them.
 
From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user.
 
LXD does offer a number of options related to unprivileged configuration:
 
* Increasing the size of the default uid/gid map
* Setting up per-container maps
* Punching holes into the map to expose host users and groups
 
=== Relationship with LXC ===
LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding
to create and manage the containers.
 
It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network.
[[Category:Virtualization]]
[[Category:Official Documentation]]
Bureaucrats, Administrators, wiki-admins, wiki-staff
5,834
edits

Navigation menu