Solidity: Docker container for testing has too many intermediate layers

[chriseth]

Starting container ethereum/solidity-buildpack-deps:ubuntu1904
  image cache not found on this host, downloading ethereum/solidity-buildpack-deps:ubuntu1904
ubuntu1904: Pulling from ethereum/solidity-buildpack-deps
7eab35e32a16: Pulling fs layer
9c0b49bd5b97: Pulling fs layer
76ea149966fa: Pulling fs layer
d56480354398: Pulling fs layer
7f11ddc8843f: Pulling fs layer
ce9859ec7533: Pulling fs layer
3b6d291e8c52: Pulling fs layer
b0b7459cac75: Pulling fs layer
156c508a0d86: Pulling fs layer
d56480354398: Waiting
76e31f3f715a: Pulling fs layer
f4be69c02bda: Pulling fs layer
92461c7a53c8: Pulling fs layer
7f11ddc8843f: Waiting
08b7bd9b0484: Pulling fs layer
6c701fada0f9: Pulling fs layer
ce9859ec7533: Waiting
aa48621a5d2f: Pulling fs layer
b0b7459cac75: Waiting
7099ab2c30a1: Pulling fs layer
156c508a0d86: Waiting
76e31f3f715a: Waiting
92461c7a53c8: Waiting
f4be69c02bda: Waiting
aa48621a5d2f: Waiting
08b7bd9b0484: Waiting
6c701fada0f9: Waiting
7099ab2c30a1: Waiting
76ea149966fa: Verifying Checksum
76ea149966fa: Download complete
9c0b49bd5b97: Verifying Checksum
9c0b49bd5b97: Download complete
d56480354398: Verifying Checksum
d56480354398: Download complete
7f11ddc8843f: Verifying Checksum
7f11ddc8843f: Download complete
ce9859ec7533: Download complete
7eab35e32a16: Verifying Checksum
7eab35e32a16: Download complete
3b6d291e8c52: Verifying Checksum
3b6d291e8c52: Download complete
76e31f3f715a: Verifying Checksum
76e31f3f715a: Download complete
f4be69c02bda: Verifying Checksum
f4be69c02bda: Download complete
7eab35e32a16: Pull complete
92461c7a53c8: Verifying Checksum
92461c7a53c8: Download complete
b0b7459cac75: Verifying Checksum
b0b7459cac75: Download complete
08b7bd9b0484: Verifying Checksum
08b7bd9b0484: Download complete
6c701fada0f9: Verifying Checksum
6c701fada0f9: Download complete
aa48621a5d2f: Verifying Checksum
aa48621a5d2f: Download complete
9c0b49bd5b97: Pull complete
7099ab2c30a1: Verifying Checksum
7099ab2c30a1: Download complete
76ea149966fa: Pull complete
d56480354398: Pull complete
156c508a0d86: Verifying Checksum
156c508a0d86: Download complete
7f11ddc8843f: Pull complete
ce9859ec7533: Pull complete
3b6d291e8c52: Pull complete
b0b7459cac75: Pull complete

[Marenz]

I checked the relevant image and it has 16 layers and a size of 1.86 GB.
I think I can reduce it to 9 layers and 1.82 GB..

[chriseth]

It still takes 34 seconds to spin up the circleci environment. Maybe this could be improved?
The dockerfile is at .circleci/docker/Dockerfile

[kcy1019]

@chriseth Can you assign this to me? I'm willing to work on this :)

[chriseth]

Thanks, please go ahead!

[axic]

This issue seems to be not relevant anymore as the files in scripts/docker do not seem to have many layers (a few RUN and COPY instructions). Is this relevant @chriseth @aarlt @ekpyron @cameel, given you have touched docker stuff.

[cameel]

I don't think there's much we can improve here regarding the spin up time. I just took a look at the container download step in a random PR and the time it takes varies a lot even when the same exact image is being pulled:

• b_ubu_static: 13 seconds
  pull stats: download 299MiB in 3.65s (81.9MiB/s), extract 298.8MiB in 9.56s (31.25MiB/s) time to create container: 93ms using image solbuildpackpusher/solidity-buildpack-deps@sha256:aeedbe7390a7383815f0cf0f8a1b8bf84dc5e334a3b0043ebcdf8b1bdbe80a81 Time to upload agent and config: 746.624244ms Time to start containers: 2.080314423s
• b_ubu_release: 45 seconds
  pull stats: download 241.7MiB in 2.563s (94.28MiB/s), extract 298.8MiB in 32.207s (9.277MiB/s) time to create container: 10.467s using image solbuildpackpusher/solidity-buildpack-deps@sha256:aeedbe7390a7383815f0cf0f8a1b8bf84dc5e334a3b0043ebcdf8b1bdbe80a81 Time to upload agent and config: 849.954549ms Time to start containers: 1.174418413s

Both are running on identical machines (Docker X-Large instance) and the log shows that the exact same layers were downloaded vs already available locally. Despite this they downloaded different amounts of data (240 MB vs 300 MB), at different speeds (31 MiB/s vs 9 MiB/s) and the time to start the container differs by two orders of magnitude (0.1 s vs 10 s).

I think that the image is already optimized enough and other factors we don't have control over have much bigger influence now.

[axic]

Starting container solbuildpackpusher/solidity-buildpack-deps@sha256:aeedbe7390a7383815f0cf0f8a1b8bf84dc5e334a3b0043ebcdf8b1bdbe80a81
Warning: No authentication provided, using CircleCI credentials for pulls from Docker Hub.
  image cache not found on this host, downloading solbuildpackpusher/solidity-buildpack-deps@sha256:aeedbe7390a7383815f0cf0f8a1b8bf84dc5e334a3b0043ebcdf8b1bdbe80a81
sha256:aeedbe7390a7383815f0cf0f8a1b8bf84dc5e334a3b0043ebcdf8b1bdbe80a81: Pulling from solbuildpackpusher/solidity-buildpack-deps

1f796a1e: Already exists 
ea53ad12: Already exists 
71e02073: Already exists 
17bbf772: Already exists 
e23e86fe: Pulling fs layer 
cd42dec2: Pulling fs layer 
e5b03a2d: Pulling fs layer 
01b4ae49: Pulling fs layer 
3ae2d2db: Pulling fs layer 
ac0d36f7: Pulling fs layer 

I think that is a reasonable number of layers, comparing to the issue opener. I take the liberty to close this, but @chriseth please reopen if you think otherwise.