A brief introduction to Linux containers configuration files

1.Cgroup section (all cgroup subsystem configuration parameters can be dynamically obtained or adjusted via Lxc-cgroup command)

LXC uses Cgroup for resource management of containers, so each subsystem of cgroup can be used. The Mount None-t cgroup/cgroup Mount Cgroup must be performed before the LXC is actually used, or the echo "None/cgroup cgroup defaults 0 0" >>/etc/fstab is used to allow the system to be restarted each time Dynamic automatic Mount Cgroup. Since then, all subsystems of cgroup have been automatically mounted to a HIERARCHY,LXC to create a sub group under/Group when creating a container in order to control the resources of the container, we can set the parameters of the corresponding subsystems according to the need to achieve the goal.

The Cgroup section is configured with Lxc.cgroup. [The form of subsystem name].key=value. For example: lxc.cgroup.cpu.shares=512 lxc.cgroup.cpuset.cpus=1.2

The following is an introduction to the use of the Cgroup subsystem (for more information on Cgroup, please go to the Redhat official documentation online)

CPU subsystem Schedules The CPU access to Cgroup. You can schedule access to CPU resources based on the following parameters, with each parameter stored independently
is in the pseudo file of the Cgroup virtual file system:

Cpu.shares
Contains an integer value that specifies the relative shared CPU time available for a task in Cgroup. For example: in two Cgroup
The task that sets the cpu.shares to 1 will have the same CPU time, but set the Cpu.shares to 2 in Cgroup
of the task.

Special note: According to the experimental results and source code analysis, the shares value of the root directory defaults to 1024, the same level task and task group equal to accept scheduling. It is also said that there are task a sub group C under Root group, and if B's shares value is 512,c shares value is 1024, then the process of task A and group B and the process CPU share in Group C should be roughly 2:1:2. (Of course, if a task or group B does not share that much, it is automatically ceded to other tasks or group)

The Cpuset subsystem allocates independent CPUs and memory nodes for Cgroup. Each cpuset can be specified based on the following parameters, each parameter
Have separate pseudo files in the control group virtual file system:

Cpuset.cpus (mandatory)
Specifies the CPU that allows the tasks in this cgroup to be accessed. This is a comma-separated list, formatted as ASCII, using a small horizontal
The line ("-") represents a range, for example: cpuset.cpus=1,2-4

Special Note: single-threaded program even if the allocation of multiple cores will only use one, for the fork call procedures, the system will do SMP equalization, but all processes are still running on the limited CPU.

Cpuset.mems (mandatory)
Specifies the memory node that allows the task in this cgroup to be accessible. This is a comma-separated list, formatted as ASCII, so
Use a dash ("-") to represent a range, for example: cpuset.mems=1,3-5

Special NOTE: This option does not need to be set in the SMP architecture machine, the machine has only one memory node. Mainly for NUMA machine use

The memory subsystem automatically generates the memory resource reports used by tasks in Cgroup and sets the memory limits that are used by those tasks:

Memory.limit_in_bytes
Sets the maximum amount of user memory (including file caching). If no unit is specified, the value is interpreted as a byte.

Special Note: This option is set separately on a machine with swap space, malloc exceeds the limit value, the program can still run, because the program will exchange the memory data to swap space, will not exceed the limit. You can use/sbin/swapoff to turn off swap space (not recommended)

Memory.memsw.limit_in_bytes
Sets the sum of the maximum memory and swap amount. If no units are specified, the value is interpreted as bytes.

Special note: Before setting this option, you must set the Memory.limit_in_bytes and the memory.limit_in_bytes must be less than or equal to the value of this option. On a machine with swap space, set this option, you can strictly control the application of memory, as long as malloc over this value, will be killed by the system

Blkio Subsystem

The Block I/O (Blkio) subsystem controls and monitors the I/O access to the block device for tasks in Cgroup. Writing values in some of these pseudo files can restrict access or bandwidth, and reading values from these pseudo files provides I/O operation information

Blkio.weight
Specifies the relative proportion (weighted) of the Cgroup default available access block I/O, ranging from 100 to 1000. This value can be overridden by the Blkio.weight_device parameter of the specific device. This value is similar to Cpu.share and works in the form of a proportional access time. The default root group value is 1000. If you create two group below the root, set weight to 500 and 1000 respectively, then the IO time ratio is 1:2. More instructions can refer to the kernel documentation.

Blkio.weight_device
Specifies the relative proportion (weighted) of the specific device I/O access available in Cgroup, ranging from 100 to 1000. The format of this value is Major:minor weight, where major and
Minor is the device type and number of nodes specified in the Linux assigned device, which we also call the Linux device list, and you
can refer to Http://www.kernel.org/doc/Documentation/devices.txt

Blkio.throttle.read_bps_device

Upper limit of read bps for a particular major:minor device (bps is the byte per second, that is, the byte of a second)

Blkio.throttle.write_bps_device

Maximum write bps limit for a specific Major:minor device

Blkio.throttle.read_iops_device

Upper limit for read iOS for a particular Major:minor device (iOS refers to Io per second, i.e. IO times/sec)

Blkio.throttle.write_iops_device

Upper limit for writing iOS for specific major:minor devices

These four parameters can be used before the Blkio.weight Blkio.weight_device, and the system will meet some limitations at the same time.

2.network part
The configuration of the network section begins with Lxc.network.

LXC.NETWORK.TYPE Specifies the type of network used for the container:

Empty: The new network space is built for the container, but there is no network interface

Veth: The new network space is set up for the container, and the container will be linked to the Lxc.network.link defined bridge to communicate with the outside. The bridge must be built in advance.

Macvlan: The new network space is built for the container, and a Macvlan interface is linked to the Lxc.network.link.

Phys: The new network space is created, and then the specified physical interface is assigned to the container Lxc.network.link

Lxc.network.flags used to specify the state of the network

Up: The network is in the available state

Lxc.network.link is used to specify a real interface for communication with the container interface, such as a bridge br0

Lxc.network.name is used to specify the name of the network interface of the container and is not in a namespace with the host interface. If not specified, LXC is automatically assigned a

Lxc.network.hwaddr the MAC address of the network interface used to specify the container

Lxc.network.ipv4 is used to specify the IPv4 address of the network interface of the container, if not set or set to 0.0.0.0, the container will obtain the IP address by way of DHCP

Lxc.network.ipv6 The IPv6 address of the network interface used to specify the container

3.rootfs part
Lxc.rootfs is used to specify the virtual root directory of the container, after which all processes within the container will have the directory root directory, inaccessible to the path outside the directory, equivalent to the chroot effect

PS: With these parts can be equipped with a more complete application container, provide CPU memory IO resource control, provide a separate network, root directory space, combined with the loop file or LVM to do the hard drive limit is better.