moby: docker service ls --filter on name is not an exact match

The command docker service ls --filter name=foo will return both the services foo and foobar, and there seems to be no built-in option to change this mode. It makes sense when filtering on an id to make it match on whichever part of the id you use, but it would be handy if filters would be able to maybe use regex, like so: docker service ls --filter name=^foo$

If this might be considered a feature request, let’s consider it for all other filterable output too.


docker version

Docker version 17.04.0-ce, build 4845c56

docker info

Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 17
Server Version: 17.04.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 151
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: gvd49po3fnmib337ya4exlxg6
 Is Manager: true
 ClusterID: w6lq1qvmj0e9v6i1laz3uhfgh
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 192.168.100.100
 Manager Addresses:
  192.168.100.100:2377
Runtimes: runc
Default Runtime: runc
Init Binary: 
containerd version: 422e31ce907fd9c3833a38d7b8fdd023e5a76e73
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 3.13.0-107-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.955GiB
Name: vagrant-ubuntu-trusty-64
ID: 2IBB:D2LL:IOK5:UGC6:WHZG:XQ73:SLMQ:4IUZ:5IJJ:5E5R:U2UE:4ABS
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 15
  • Comments: 16 (3 by maintainers)

Most upvoted comments

@shouze Actually, there is a specific use case: I want to be able to filter on the specific service “foo”, and not get the service “foobar” in my results.

Do we have any update on this ? This is a nice and useful feature, all filters should have this regexp option

Please, add the regex option. Docker syntax is sometimes inconsitent and as I use a script I programmed for easier deployment, this detail was irritating. Because:

with the service-command it’s not working

# docker service ls --filter name='^example$'
ID                  NAME                MODE                REPLICAS            IMAGE               PORTS
# docker service ls --filter name='example'
ID                  NAME                MODE                REPLICAS            IMAGE               PORTS
9ejv73a7umq9        example             replicated          1/1                 nginx:latest        
v65pfg516cbj        example1            replicated          3/3                 nginx:latest        *:12345->80/tcp
2pmfad6ctlj3        example2            replicated          3/3                 nginx:latest        *:12346->80/tcp

with the network-command it’s working!

# docker network ls --filter name='^example$'
NETWORK ID          NAME                DRIVER              SCOPE
3800c6664e9a        example             bridge              local

+1 same issue, need external processing to exact match de name of my service.

+1 😞

Also - this type of filtering behavior is inconsistent with docker network ls --filter. If I have networks foo, bar, and foobar, then docker network ls --filter name=foo it’ll just return foo

This is working as intended currently (see https://docs.docker.com/engine/reference/commandline/service_ls/#name)

screen shot 2017-11-16 at 17 05 49

Also see https://github.com/moby/moby/issues/22522

There’s a feature request for “negative” filters in https://github.com/moby/moby/issues/13533, but adding more options may need some discussion