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