pct.adoc

   1 ifdef::manvolnum[]
   2 PVE({manvolnum})
   3 ================
   4 include::attributes.txt[]
   5
   6 NAME
   7 ----
   8
   9 pct - Tool to manage Linux Containers (LXC) on Proxmox VE
  10
  11
  12 SYNOPSYS
  13 --------
  14
  15 include::pct.1-synopsis.adoc[]
  16
  17 DESCRIPTION
  18 -----------
  19 endif::manvolnum[]
  20
  21 ifndef::manvolnum[]
  22 Proxmox Container Toolkit
  23 =========================
  24 include::attributes.txt[]
  25 endif::manvolnum[]
  26
  27
  28 Containers are a lightweight alternative to fully virtualized
  29 VMs. Instead of emulating a complete Operating System (OS), containers
  30 simply use the OS of the host they run on. This implies that all
  31 containers use the same kernel, and that they can access resources
  32 from the host directly.
  33
  34 This is great because containers do not waste CPU power nor memory due
  35 to kernel emulation. Container run-time costs are close to zero and
  36 usually negligible. But there are also some drawbacks you need to
  37 consider:
  38
  39 * You can only run Linux based OS inside containers, i.e. it is not
  40   possible to run Free BSD or MS Windows inside.
  41
  42 * For security reasons, access to host resources need to be
  43   restricted. This is done with AppArmor, SecComp filters and other
  44   kernel feature. Be prepared that some syscalls are not allowed
  45   inside containers.
  46
  47 {pve} uses https://linuxcontainers.org/[LXC] as underlying container
  48 technology. We consider LXC as low-level library, which provides
  49 countless options. It would be to difficult to use those tools
  50 directly. Instead, we provide a small wrapper called `pct`, the
  51 "Proxmox Container Toolkit".
  52
  53 The toolkit it tightly coupled with {pve}. That means that it is aware
  54 of the cluster setup, and it can use the same network and storage
  55 resources as fully virtualized VMs. You can even use the {pve}
  56 firewall, or manage containers using the HA framework.
  57
  58 Our primary goal is to offer an environment as one would get from a
  59 VM, but without the additional overhead. We call this "System
  60 Containers".
  61
  62 NOTE: If you want to run micro-containers (with docker, rct, ...), it
  63 is best to run them inside a VM.
  64
  65
  66 Security Considerations
  67 -----------------------
  68
  69 Containers use the same kernel as the host, so there is a big attack
  70 surface for malicious users. You should consider this fact if you
  71 provide containers to totally untrusted people. In general, fully
  72 virtualized VM provides better isolation.
  73
  74 The good news is that LXC uses many kernel security features like
  75 AppArmor, CGroups and PID and user namespaces, which makes containers
  76 usage quite secure. We distinguish two types of containers:
  77
  78 Privileged containers
  79 ~~~~~~~~~~~~~~~~~~~~~
  80
  81 Security is done by dropping capabilities, using mandatory access
  82 control (AppArmor), SecComp filters and namespaces. The LXC team
  83 considers this kind of container as unsafe, and they will not consider
  84 new container escape exploits to be security issues worthy of a CVE
  85 and quick fix. So you should use this kind of containers only inside a
  86 trusted environment, or when no untrusted task is running as root in
  87 the container.
  88
  89 Unprivileged containers
  90 ~~~~~~~~~~~~~~~~~~~~~~~
  91
  92 This kind of containers use a new kernel feature, called user
  93 namespaces. The root uid 0 inside the container is mapped to an
  94 unprivileged user outside the container. This means that most security
  95 issues (container escape, resource abuse, ...) in those containers
  96 will affect a random unprivileged user, and so would be a generic
  97 kernel security bug rather than a LXC issue. LXC people think
  98 unprivileged containers are safe by design.
  99
 100
 101 Configuration
 102 -------------
 103
 104 The '/etc/pve/lxc/<CTID>.conf' files stores container configuration,
 105 where '<CTID>' is the numeric ID of the given container. Note that
 106 CTIDs < 100 are reserved for internal purposes. CTIDs need to be
 107 unique - cluster wide. Files are stored inside '/etc/pve/', so they get
 108 automatically replicated to all other cluster nodes.
 109
 110 Those configuration files are simple text files, and you can edit them
 111 using a normal text editor ('vi', 'nano', ...). But one can also use
 112 the 'pct' command to generate and modify those files, or do the whole
 113 thing using the GUI.
 114
 115
 116 File Format
 117 ~~~~~~~~~~~
 118
 119 Container configuration files use a simple colon separated key/value
 120 format. Each line has the following format:
 121
 122  # this is a comment
 123  OPTION: value
 124
 125 Blank lines in those files are ignored, and lines starting with a '#'
 126 character are treated as comments and are also ignored.
 127
 128 It is possible to add low-level, LXC style configuration directly, for
 129 example:
 130
 131  lxc.init_cmd: /sbin/my_own_init
 132
 133 or
 134
 135  lxc.init_cmd = /sbin/my_own_init
 136
 137 Those settings are directly passed to the LXC low-level tools.
 138
 139
 140 Container Storage
 141 -----------------
 142
 143 Traditional containers use a very simple storage model, only allowing
 144 a single mount point, the root file system. This was further
 145 restricted to specific file system types like 'ext4' and 'nfs'.
 146 Additional mounts are often done by user provided scripts. This turend
 147 out to be complex and error prone, so we trie to avoid that now.
 148
 149 Our new LXC based container model is more flexible regarding
 150 storage. First, you can have more than a single mount point. This
 151 allows you to choose a suitable storage for each application. For
 152 example, you can use a relatively slow (and thus cheap) storage for
 153 the container root file system. Then you can use a second mount point
 154 to mount a very fast, distributed storage for your database
 155 application.
 156
 157 The second big improvement is that you can use any storage type
 158 supported by the {pve} storage library. That means that you can store
 159 your containers on local 'lvmthin' or 'zfs', shared 'iSCSI' storage,
 160 or even on distributed storage systems like 'ceph'. And it enables us
 161 to use advanced storage features like snapshots and clones. 'vzdump'
 162 can also use the snapshots feature to provide consistent container
 163 backups.
 164
 165 Last but not least, you can also mount local devices directly, or
 166 mount local directories using bind mounts. That way you can access
 167 local storage inside containers with zero overhead. Such bind mounts
 168 also provides an easy way to share data between different containers.
 169
 170
 171 Managing Containers with 'pct'
 172 ------------------------------
 173
 174 'pct' is the tool to manage Linux Containers on {pve}. You can create
 175 and destroy containers, and control execution (start, stop, migrate,
 176 ...). You can use pct to set parameters in the associated config file,
 177 like network configuration or memory.
 178
 179 CLI Usage Examples
 180 ------------------
 181
 182 Create a container based on a Debian template (provided you downloaded
 183 the template via the webgui before)
 184
 185  pct create 100 /var/lib/vz/template/cache/debian-8.0-standard_8.0-1_amd64.tar.gz
 186
 187 Start container 100
 188
 189  pct start 100
 190
 191 Start a login session via getty
 192
 193  pct console 100
 194
 195 Enter the LXC namespace and run a shell as root user
 196
 197  pct enter 100
 198
 199 Display the configuration
 200
 201  pct config 100
 202
 203 Add a network interface called eth0, bridged to the host bridge vmbr0,
 204 set the address and gateway, while it's running
 205
 206  pct set 100 -net0 name=eth0,bridge=vmbr0,ip=192.168.15.147/24,gw=192.168.15.1
 207
 208 Reduce the memory of the container to 512MB
 209
 210  pct set -memory 512 100
 211
 212 Files
 213 ------
 214
 215 '/etc/pve/lxc/<CTID>.conf'::
 216
 217 Configuration file for the container '<CTID>'.
 218
 219
 220 Container Advantages
 221 --------------------
 222
 223 - Simple, and fully integrated into {pve}. Setup looks similar to a normal
 224   VM setup.
 225
 226   * Storage (ZFS, LVM, NFS, Ceph, ...)
 227
 228   * Network
 229
 230   * Authentification
 231
 232   * Cluster
 233
 234 - Fast: minimal overhead, as fast as bare metal
 235
 236 - High density (perfect for idle workloads)
 237
 238 - REST API
 239
 240 - Direct hardware access
 241
 242
 243 Technology Overview
 244 -------------------
 245
 246 - Integrated into {pve} graphical user interface (GUI)
 247
 248 - LXC (https://linuxcontainers.org/)
 249
 250 - cgmanager for cgroup management
 251
 252 - lxcfs to provive containerized /proc file system
 253
 254 - apparmor
 255
 256 - CRIU: for live migration (planned)
 257
 258 - We use latest available kernels (4.2.X)
 259
 260 - image based deployment (templates)
 261
 262 - Container setup from host (Network, DNS, Storage, ...)
 263
 264
 265 ifdef::manvolnum[]
 266 include::pve-copyright.adoc[]
 267 endif::manvolnum[]
 268
 269
 270
 271
 272
 273
 274