Docker images Filter Options

Docker images Filter Options

Get Social!

The below is an excerpt from docker.com listing the –filter options available for docker images.

danglingboolean – true or false – will show dangling images.
label
label=<key> or label=<key>=<value>
before
<image-name>[:<tag>]<image id> or <image@digest> – filter images created before given id or references
since
<image-name>[:<tag>]<image id> or <image@digest> – filter images created since given id or references
reference
(pattern of an image reference) – filter images whose reference matches the specified pattern

Docker ps Filter Options

Get Social!

The below is an excerpt from docker.com listing the –filter options available with docker ps.

idContainer’s ID
nameContainer’s name
labelAn arbitrary string representing either a key or a key-value pair. Expressed as <key> or <key>=<value>
exitedAn integer representing the container’s exit code. Only useful with --all.
statusOne of createdrestartingrunningremovingpausedexited, or dead
ancestorFilters containers which share a given image as an ancestor. Expressed as <image-name>[:<tag>],<image id>, or <image@digest>
before or sinceFilters containers created before or after a given container ID or name
volumeFilters running containers which have mounted a given volume or bind mount.
networkFilters running containers connected to a given network.
publish or exposeFilters containers which publish or expose a given port. Expressed as <port>[/<proto>] or <startport-endport>/[<proto>]
healthFilters containers based on their healthcheck status. One of startinghealthyunhealthy or none.
isolationWindows daemon only. One of defaultprocess, or hyperv.
is-taskFilters containers that are a “task” for a service. Boolean option (true or false)

Remove Docker Container Based On Regex

Get Social!

This simple one-liner will take a regular expression (regex) and remove any Docker containers matching the pattern based on the name field. You can change the name match to be any other field accepted by the –filter switch.

Run the following docker ps command and substitute NAMEHERE* with the pattern you’d like to match. Careful, this command will delete any containers it finds.

docker ps --filter name=NAMEHERE* -aq | xargs docker stop | xargs docker rm

You can also filter on various other keys, such as status and volume using exactly the same method. Just replace the –filter element with the key from the below table, and the expression you want to match. 

idContainer’s ID
nameContainer’s name
labelAn arbitrary string representing either a key or a key-value pair. Expressed as <key> or <key>=<value>
exitedAn integer representing the container’s exit code. Only useful with --all.
statusOne of createdrestartingrunningremovingpausedexited, or dead
ancestorFilters containers which share a given image as an ancestor. Expressed as <image-name>[:<tag>],<image id>, or <image@digest>
before or sinceFilters containers created before or after a given container ID or name
volumeFilters running containers which have mounted a given volume or bind mount.
networkFilters running containers connected to a given network.
publish or exposeFilters containers which publish or expose a given port. Expressed as <port>[/<proto>] or <startport-endport>/[<proto>]
healthFilters containers based on their healthcheck status. One of startinghealthyunhealthy or none.
isolationWindows daemon only. One of defaultprocess, or hyperv.
is-taskFilters containers that are a “task” for a service. Boolean option (true or false)

See Docker PS Filter Options.

You can also filter for multiple conditions by passing the –filter switch multiple times. For example, name=webserver and status=running would look like this:

docker ps --filter name=webserver --filter status=running -aq | xargs docker stop | xargs docker rm

Setting Memory Resource Limits With LXC

Category : How-to

Get Social!

linux_containers_logo

 

Linux Container (LXC) management is now often dealt with by LXD, the Canonical lead project built on top of LXC.

LXD offers a suite of options for controlling Linux Container resources and setting limits where appropriate. This post will talk about setting constraints on CPU, however other options are available for limiting almost any sort of resource, such as network, disk I/O, memory and so on.

Available Limits

CPU management is done in 1 of 4 ways, depending on your expected workload and host CPU management regime.

  1. Number of CPUs – set the number of CPU cores that LXC can use with this container and automatically distribute CPU time amongst guests when there is competition for CPU time. The value used is an integer, for example 2.
  2. Specific cores – specify specific physical core(s) for the container to use and distribute available CPU time between containers when multiple containers use the same cores.The value used is an integer or range and can be comma separated, for example 2, 0-1 or 0-1,3,5-9.
  3. Capped share – allow a specified percentage of CPU time for the container, or more if it’s available. When the host is not under load then a container can use any available CPU however when there is contention for CPU then the container will be limited to the specified amount. The container will see all host CPU cores (in TOP, for example).
  4. Limited time share – will limit the container CPU time to be whatever is specified out of each 200ms. Even if more CPU is available, only what is specified per 200ms slice is allowed. The container will see all host CPU cores (in TOP, for example).

Setting Limits

Setting limits is done with the lxc command. There are then two options; limits.cpu for the above points 1 and 2, or limit.cpu.allowance for points 3 and 4.

lxc config set [CONTAINER] limits.cpu [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 1 or 2 above.

OR

lxc config set [CONTAINER] limits.cpu.allowance [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 3 or 4 above.

CPU Limit Examples

Set the container nginx-proxy to use any 2 CPUs on the host.

lxc config set nginx-proxy limits.cpu 2

Set the container nginx-proxy to use physical CPU 0, 3, 7, 8 and 9 on the host.

lxc config set nginx-proxy limits.cpu 0,3,7-9

Set the container nginx-proxy to use 20% of the available CPU on the host or more if it’s available.

lxc config set nginx-proxy limits.cpu.allowance 20%

Set the container nginx-proxy to use no more than 50% of the available CPU on the host, or 100ms for every 200ms of CPU time available.

lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

You can view /proc/cpuinfo to see the available cores on your container, however it will not include any additional scheduling limits or priorities.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

CPU Priority

The last option around CPU limiting is the priority of CPU time. This option only kicks in when the host is overcommitted on CPU resource and containers are fighting for CPU time. This can either be on a single core (if using above points 1 or 2) or system wide (if no CPU limiting is in place or using above points 3 or 4).

Available values are 0 – 10 inclusive and lower numbers mean a lower priority – a higher number will mean the machine gets CPU time before lower numbers.

The below command sets the container nginx-proxy to have a CPU priority of 5.

lxc config set nginx-proxy limits.cpu.priority 5

The below command sets the container php-backend to have a CPU priority of 2 and therefore would get less CPU time than container nginx-proxy when CPU is under contention.

lxc config set php-backend limits.cpu.priority 5

Setting CPU Resource Limits With LXC

Category : How-to

Get Social!

linux_containers_logoLinux Container (LXC) management is now often dealt with by LXD, the Canonical lead project built on top of LXC.

LXD offers a suite of options for controlling Linux Container resources and setting limits where appropriate. This post will talk about setting constraints on CPU, however other options are available for limiting almost any sort of resource, such as network, disk I/O, memory and so on.

Available Limits

CPU management is done in 1 of 4 ways, depending on your expected workload and host CPU management regime.

  1. Number of CPUs – set the number of CPU cores that LXC can use with this container and automatically distribute CPU time amongst guests when there is competition for CPU time. The value used is an integer, for example 2.
  2. Specific cores – specify specific physical core(s) for the container to use and distribute available CPU time between containers when multiple containers use the same cores.The value used is an integer or range and can be comma separated, for example 2, 0-1 or 0-1,3,5-9.
  3. Capped share – allow a specified percentage of CPU time for the container, or more if it’s available. When the host is not under load then a container can use any available CPU however when there is contention for CPU then the container will be limited to the specified amount. The container will see all host CPU cores (in TOP, for example).
  4. Limited time share – will limit the container CPU time to be whatever is specified out of each 200ms. Even if more CPU is available, only what is specified per 200ms slice is allowed. The container will see all host CPU cores (in TOP, for example).

Setting Limits

Setting limits is done with the lxc command. There are then two options; limits.cpu for the above points 1 and 2, or limit.cpu.allowance for points 3 and 4.

lxc config set [CONTAINER] limits.cpu [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 1 or 2 above.

OR

lxc config set [CONTAINER] limits.cpu.allowance [VALUE]
  • [CONTAINER] is the name of the container – can be obtained from lxc list if you’re unsure.
  • [VALUE] is a valid value from point 3 or 4 above.

CPU Limit Examples

Set the container nginx-proxy to use any 2 CPUs on the host.

lxc config set nginx-proxy limits.cpu 2

Set the container nginx-proxy to use physical CPU 0, 3, 7, 8 and 9 on the host.

lxc config set nginx-proxy limits.cpu 0,3,7-9

Set the container nginx-proxy to use 20% of the available CPU on the host or more if it’s available.

lxc config set nginx-proxy limits.cpu.allowance 20%

Set the container nginx-proxy to use no more than 50% of the available CPU on the host, or 100ms for every 200ms of CPU time available.

lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

You can view /proc/cpuinfo to see the available cores on your container, however it will not include any additional scheduling limits or priorities.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

CPU Priority

The last option around CPU limiting is the priority of CPU time. This option only kicks in when the host is overcommitted on CPU resource and containers are fighting for CPU time. This can either be on a single core (if using above points 1 or 2) or system wide (if no CPU limiting is in place or using above points 3 or 4).

Available values are 0 – 10 inclusive and lower numbers mean a lower priority – a higher number will mean the machine gets CPU time before lower numbers.

The below command sets the container nginx-proxy to have a CPU priority of 5.

lxc config set nginx-proxy limits.cpu.priority 5

The below command sets the container php-backend to have a CPU priority of 2 and therefore would get less CPU time than container nginx-proxy when CPU is under contention.

lxc config set php-backend limits.cpu.priority 5

Bash Command to Check Container Disk Space in Proxmox/ OpenVZ

Get Social!

proxmox logo gradKeeping an eye on all of your containers disk space can be time consuming if done one by one. Luckily, the vzlist command gives us access to many of the data and counters associated with each container.

Running vzlist on it’s own will give a list of the currently running containers and a few extra columns of information such as IP address and hostname.

vzlist
CTID NPROC STATUS  IP_ADDR     HOSTNAME
100  27    running 10.10.10.10 test.jamescoyle.net

You might be thinking that the above command doesn’t show anything about containers which are currently turned off, or about disk space. You’d be right!

Adding the –all switch will include all containers, regardless of their running state.

To add the disk space information we add the –output switch followed by the column names we want to display. For disk space, the column name is helpfully named diskspace so the command will look like this:

vzlist --all --output diskspace
DSPACE
1184648

We now see the disk space of all of our containers, but with a problem. We have no idea (although in this example we do because we only have one container) which container the disk space output is for. We need to add a few more columns to the –output switch such as ctid and hostname.  (see below for a complete list of output columns)

vzlist --all --output ctid,hostname,diskspace
CTID HOSTNAME             DSPACE
100  test.jamescoyle.net  1184660

The last trick here is to add a sort using the –sort switch and the column name

vzlist --all --output ctid,hostname,diskspace --sort diskspace
CTID HOSTNAME             DSPACE
100  test.jamescoyle.net  1184660

Let’s put all that together, plus a spot of awk magic to get a nice disk full percentage that we can work with:

vzlist --all --output ctid,hostname,diskspace,diskspace.s,diskspace.h --sort diskspace | awk '{if (NR>1) {printf("%-4s %-30s %-10s %-10s %-10s %d\n", $1, $2, $3, $4, $5, $3/$4*100)} else printf("%-4s %-30s %-10s %-10s %-10s %s\n", $1, $2, $3, $4, $5, "PERC_USED")}'

Output:

CTID HOSTNAME            DSPACE  DSPACE.S DSPACE.H PERC_USED
100  test.jamescoyle.net 1184684 5242880  5767168  22

Complete list of vzlist column headings

You can get a complete list of vzlist column headings with the following command:

vzlist -L
ctid            CTID
veid            CTID
vpsid           CTID
private         PRIVATE
root            ROOT
mount_opts      MOUNT_OPTS
origin_sample   ORIGIN_SAMPLE
hostname        HOSTNAME
name            NAME
smart_name      SMARTNAME
description     DESCRIPTION
ostemplate      OSTEMPLATE
ip              IP_ADDR
nameserver      NAMESERVER
searchdomain    SEARCHDOMAIN
status          STATUS
kmemsize        KMEMSIZE
kmemsize.m      KMEMSIZE.M
kmemsize.b      KMEMSIZE.B
kmemsize.l      KMEMSIZE.L
kmemsize.f      KMEMSIZE.F
lockedpages     LOCKEDP
lockedpages.m   LOCKEDP.M
lockedpages.b   LOCKEDP.B
lockedpages.l   LOCKEDP.L
lockedpages.f   LOCKEDP.F
privvmpages     PRIVVMP
privvmpages.m   PRIVVMP.M
privvmpages.b   PRIVVMP.B
privvmpages.l   PRIVVMP.L
privvmpages.f   PRIVVMP.F
shmpages        SHMP
shmpages.m      SHMP.M
shmpages.b      SHMP.B
shmpages.l      SHMP.L
shmpages.f      SHMP.F
numproc         NPROC
numproc.m       NPROC.M
numproc.b       NPROC.B
numproc.l       NPROC.L
numproc.f       NPROC.F
physpages       PHYSP
physpages.m     PHYSP.M
physpages.b     PHYSP.B
physpages.l     PHYSP.L
physpages.f     PHYSP.F
vmguarpages     VMGUARP
vmguarpages.m   VMGUARP.M
vmguarpages.b   VMGUARP.B
vmguarpages.l   VMGUARP.L
vmguarpages.f   VMGUARP.F
oomguarpages    OOMGUARP
oomguarpages.m  OOMGUARP.M
oomguarpages.b  OOMGUARP.B
oomguarpages.l  OOMGUARP.L
oomguarpages.f  OOMGUARP.F
numtcpsock      NTCPSOCK
numtcpsock.m    NTCPSOCK.M
numtcpsock.b    NTCPSOCK.B
numtcpsock.l    NTCPSOCK.L
numtcpsock.f    NTCPSOCK.F
numflock        NFLOCK
numflock.m      NFLOCK.M
numflock.b      NFLOCK.B
numflock.l      NFLOCK.L
numflock.f      NFLOCK.F
numpty          NPTY
numpty.m        NPTY.M
numpty.b        NPTY.B
numpty.l        NPTY.L
numpty.f        NPTY.F
numsiginfo      NSIGINFO
numsiginfo.m    NSIGINFO.M
numsiginfo.b    NSIGINFO.B
numsiginfo.l    NSIGINFO.L
numsiginfo.f    NSIGINFO.F
tcpsndbuf       TCPSNDB
tcpsndbuf.m     TCPSNDB.M
tcpsndbuf.b     TCPSNDB.B
tcpsndbuf.l     TCPSNDB.L
tcpsndbuf.f     TCPSNDB.F
tcprcvbuf       TCPRCVB
tcprcvbuf.m     TCPRCVB.M
tcprcvbuf.b     TCPRCVB.B
tcprcvbuf.l     TCPRCVB.L
tcprcvbuf.f     TCPRCVB.F
othersockbuf    OTHSOCKB
othersockbuf.m  OTHSOCKB.M
othersockbuf.b  OTHSOCKB.B
othersockbuf.l  OTHSOCKB.L
othersockbuf.f  OTHSOCKB.F
dgramrcvbuf     DGRAMRB
dgramrcvbuf.m   DGRAMRB.M
dgramrcvbuf.b   DGRAMRB.B
dgramrcvbuf.l   DGRAMRB.L
dgramrcvbuf.f   DGRAMRB.F
numothersock    NOTHSOCK
numothersock.m  NOTHSOCK.M
numothersock.b  NOTHSOCK.B
numothersock.l  NOTHSOCK.L
numothersock.f  NOTHSOCK.F
dcachesize      DCACHESZ
dcachesize.m    DCACHESZ.M
dcachesize.b    DCACHESZ.B
dcachesize.l    DCACHESZ.L
dcachesize.f    DCACHESZ.F
numfile         NFILE
numfile.m       NFILE.M
numfile.b       NFILE.B
numfile.l       NFILE.L
numfile.f       NFILE.F
numiptent       NIPTENT
numiptent.m     NIPTENT.M
numiptent.b     NIPTENT.B
numiptent.l     NIPTENT.L
numiptent.f     NIPTENT.F
swappages       SWAPP
swappages.m     SWAPP.M
swappages.b     SWAPP.B
swappages.l     SWAPP.L
swappages.f     SWAPP.F
diskspace       DSPACE
diskspace.s     DSPACE.S
diskspace.h     DSPACE.H
diskinodes      DINODES
diskinodes.s    DINODES.S
diskinodes.h    DINODES.H
laverage        LAVERAGE
uptime          UPTIME
cpulimit        CPULIM
cpuunits        CPUUNI
cpus            CPUS
ioprio          IOP
onboot          ONBOOT
bootorder       BOOTORDER
layout          LAYOUT
features        FEATURES
vswap           VSWAP
disabled        DISABL

 


Visit our advertisers

Quick Poll

Do you use ZFS on Linux?

Visit our advertisers