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', ...). This is sometimes
 112 useful to do small corrections, but keep in mind that you need to
 113 restart the container to apply such changes.
 114
 115 For that reason, it is usually better to use the 'pct' command to
 116 generate and modify those files, or do the whole thing using the GUI.
 117 Our toolkit is smart enough to instantaneously apply most changes to
 118 running containers (hot plug).
 119
 120
 121 File Format
 122 ~~~~~~~~~~~
 123
 124 Container configuration files use a simple colon separated key/value
 125 format. Each line has the following format:
 126
 127  # this is a comment
 128  OPTION: value
 129
 130 Blank lines in those files are ignored, and lines starting with a '#'
 131 character are treated as comments and are also ignored.
 132
 133 It is possible to add low-level, LXC style configuration directly, for
 134 example:
 135
 136  lxc.init_cmd: /sbin/my_own_init
 137
 138 or
 139
 140  lxc.init_cmd = /sbin/my_own_init
 141
 142 Those settings are directly passed to the LXC low-level tools.
 143
 144
 145 Guest Operating System Configuration
 146 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 147
 148 We normally try to detect the operating system type inside the
 149 container, and then modify some files inside the container to make
 150 them work as expected. Here is a short list of things we do at
 151 container startup:
 152
 153 set /etc/hostname:: to set the container name
 154
 155 modify /etc/hosts:: allow to lookup the local hostname
 156
 157 network setup:: pass the complete network setup to the container
 158
 159 configure DNS:: pass information about DNS servers
 160
 161 adopt the init system:: for example, fix the number os spawned getty processes
 162
 163 set the root password:: when creating a new container
 164
 165 rewrite ssh_host_keys:: so that each container has unique keys
 166
 167 randomize crontab:: so that cron does not start at same time on all containers
 168
 169 Above task depends on the OS type, so the implementation is different
 170 for each OS type. You can also disable any modifications by manually
 171 setting the 'ostype' to 'unmanaged'.
 172
 173 OS type detection is done by testing for certain files inside the
 174 container:
 175
 176 Ubuntu:: inspect /etc/lsb-release ('DISTRIB_ID=Ubuntu')
 177
 178 Debian:: test /etc/debian_version
 179
 180 Fedora:: test /etc/fedora-release
 181
 182 RedHat or CentOS:: test /etc/redhat-release
 183
 184 ArchLinux:: test /etc/arch-release
 185
 186 Alpine:: test /etc/alpine-release
 187
 188 NOTE: Container start fails is configured 'ostype' differs from auto
 189 detected type.
 190
 191 Container Storage
 192 -----------------
 193
 194 Traditional containers use a very simple storage model, only allowing
 195 a single mount point, the root file system. This was further
 196 restricted to specific file system types like 'ext4' and 'nfs'.
 197 Additional mounts are often done by user provided scripts. This turend
 198 out to be complex and error prone, so we trie to avoid that now.
 199
 200 Our new LXC based container model is more flexible regarding
 201 storage. First, you can have more than a single mount point. This
 202 allows you to choose a suitable storage for each application. For
 203 example, you can use a relatively slow (and thus cheap) storage for
 204 the container root file system. Then you can use a second mount point
 205 to mount a very fast, distributed storage for your database
 206 application.
 207
 208 The second big improvement is that you can use any storage type
 209 supported by the {pve} storage library. That means that you can store
 210 your containers on local 'lvmthin' or 'zfs', shared 'iSCSI' storage,
 211 or even on distributed storage systems like 'ceph'. And it enables us
 212 to use advanced storage features like snapshots and clones. 'vzdump'
 213 can also use the snapshots feature to provide consistent container
 214 backups.
 215
 216 Last but not least, you can also mount local devices directly, or
 217 mount local directories using bind mounts. That way you can access
 218 local storage inside containers with zero overhead. Such bind mounts
 219 also provides an easy way to share data between different containers.
 220
 221
 222 Managing Containers with 'pct'
 223 ------------------------------
 224
 225 'pct' is the tool to manage Linux Containers on {pve}. You can create
 226 and destroy containers, and control execution (start, stop, migrate,
 227 ...). You can use pct to set parameters in the associated config file,
 228 like network configuration or memory.
 229
 230 CLI Usage Examples
 231 ------------------
 232
 233 Create a container based on a Debian template (provided you downloaded
 234 the template via the webgui before)
 235
 236  pct create 100 /var/lib/vz/template/cache/debian-8.0-standard_8.0-1_amd64.tar.gz
 237
 238 Start container 100
 239
 240  pct start 100
 241
 242 Start a login session via getty
 243
 244  pct console 100
 245
 246 Enter the LXC namespace and run a shell as root user
 247
 248  pct enter 100
 249
 250 Display the configuration
 251
 252  pct config 100
 253
 254 Add a network interface called eth0, bridged to the host bridge vmbr0,
 255 set the address and gateway, while it's running
 256
 257  pct set 100 -net0 name=eth0,bridge=vmbr0,ip=192.168.15.147/24,gw=192.168.15.1
 258
 259 Reduce the memory of the container to 512MB
 260
 261  pct set -memory 512 100
 262
 263 Files
 264 ------
 265
 266 '/etc/pve/lxc/<CTID>.conf'::
 267
 268 Configuration file for the container '<CTID>'.
 269
 270
 271 Container Advantages
 272 --------------------
 273
 274 - Simple, and fully integrated into {pve}. Setup looks similar to a normal
 275   VM setup.
 276
 277   * Storage (ZFS, LVM, NFS, Ceph, ...)
 278
 279   * Network
 280
 281   * Authentification
 282
 283   * Cluster
 284
 285 - Fast: minimal overhead, as fast as bare metal
 286
 287 - High density (perfect for idle workloads)
 288
 289 - REST API
 290
 291 - Direct hardware access
 292
 293
 294 Technology Overview
 295 -------------------
 296
 297 - Integrated into {pve} graphical user interface (GUI)
 298
 299 - LXC (https://linuxcontainers.org/)
 300
 301 - cgmanager for cgroup management
 302
 303 - lxcfs to provive containerized /proc file system
 304
 305 - apparmor
 306
 307 - CRIU: for live migration (planned)
 308
 309 - We use latest available kernels (4.2.X)
 310
 311 - image based deployment (templates)
 312
 313 - Container setup from host (Network, DNS, Storage, ...)
 314
 315
 316 ifdef::manvolnum[]
 317 include::pve-copyright.adoc[]
 318 endif::manvolnum[]
 319
 320
 321
 322
 323
 324
 325