Yeah. I find that the AWS ECS optimized AMI has a very peculiar configuration: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-ami-storage-config.html
Amazon ECS-optimized AMIs from version 2015.09.d and later launch with an 8-GiB volume for the operating system that is attached at /dev/xvda and mounted as the root of the file system. There is an additional 22-GiB volume that is attached at /dev/xvdcz that Docker uses for image and metadata storage. The volume is configured as a Logical Volume Management (LVM) device and it is accessed directly by Docker via the devicemapper backend. Because the volume is not mounted, you cannot use standard storage information commands (such as df -h) to determine the available storage.
We had all sort of issues because of this. Since devicemapper is not supported by dind, our Drone builds would not use the separate Docker volume, and soon we wouldn’t have any space left on the root volume.
So I suggest you try to:
A) use a different base AMI, which supports overlay or aufs (but it’s going to be harded to integrate it with ECS)
B) mount the host docker socket, so you do not need dind and can inherit the device mapper configuration:
This requires you to enable the “Trusted” option on the Drone UI.
We’ve been using this configuration to make a rather large number of daily builds without problems so far. There might be some security risks running it on a public server or for a open-source repo though, as I think different builds using the same socket could have access to each other docker registry credentials. But I haven’t seen any drawback when running like this on a private server so far.