moby: Image tags not working with awslogs log driver
Description
Image tags cause containers to fail to start with awslogs log driver. This applies to the following tags:
{{.ImageName}}{{.ImageID}}{{.ImageFullID}}
Steps to reproduce the issue:
- Configure the docker daemon to awslogs and include
--log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"in order to create a stream that uses the image name - Use swarm mode (the only way I’ve tested this so far)
- Create a service
Describe the results you received:
The containers will fail to start. This can be verified with docker ps
Describe the results you expected:
The containers should start. Logs should show up in CloudWatch logs under the configured log group, using the format specified in the tag.
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
Version: 1.13.0
API version: 1.25
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:26 2017
OS/Arch: linux/amd64
Server:
Version: 1.13.0
API version: 1.25 (minimum version 1.12)
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:26 2017
OS/Arch: linux/amd64
Experimental: false
Output of docker info:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 2
Server Version: 1.13.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 10
Dirperm1 Supported: true
Logging Driver: awslogs
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: active
NodeID: z2mr9iejgxzf1n2s1e46px5vf
Is Manager: true
ClusterID: ps88z6izmqfpkgcex0y6o2aho
Managers: 1
Nodes: 26
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: 10.10.14.68
Manager Addresses:
10.10.14.68:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-59-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.952 GiB
Name: ip-10-10-14-68
ID: C3GF:EIBV:PXHF:6LAO:OMDW:3PCC:4CGA:3DUZ:24TA:C37U:XIB5:5SYU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional environment details (AWS, VirtualBox, physical, etc.): AWS
About this issue
- Original URL
- State: open
- Created 7 years ago
- Comments: 19 (7 by maintainers)
@thaJeztah maybe that bug should be considered just as a doco error and a feature request should be created instead for adding new tags?
Beside/as a replacement for those in https://docs.docker.com/engine/admin/logging/log_tags/, we might want to have:
{{.ImageName}}: the container image name without the version tag{{.FullImageName}}: the container image name with the version tag{{.VersionTag}}: the container image version tagThis way we could fix our issue with something like:
WDYT?
PR to the docs added, to specify the above formatting trick! 💃
This doesn’t sound like a bug to me, but rather a documented limitation of the CloudWatch Logs API.
I think that’s a bit non-obvious, but if it makes the usability of the
--log-opt tagoption easier we could mitigate the confusion through more documentation.Ah yeah thanks @FrenchBen, that’s a nice trick to get the first part of the ImageName. I didn’t know how to run multiple commands before your example in #33073 and this one.
So, with this, the final solution for my use case is:
As far as I am concerned this issue is closed for me (but I hijacked it 😉)