The official standard image with all the tools is 4Gb compressed and it is really too big for my tiny VPS server. The image includes a lot of tools that I don’t use so I will remove those tools and see ho much disk space I can save.
The repository with all the experiments and images is vsts-minimal-build-agent
In the offical Microsoft docker hub the base image uses Ubuntu 16.04.
docker image ls microsoft/vsts-agent:ubuntu-16.04 REPOSITORY TAG IMAGE ID CREATED SIZE microsoft/vsts-agent ubuntu-16.04 929c015071d9 8 days ago 304MB
Let try to upgrade the base version to 18.04 (just because)
From the original configurations I moved a few components and configurations from the standard image to the base image. A bigger and more complete base image will reduce the time needed for building the other optimized images.
docker build -t gabrieleteotino/vsts-minimal-agent:ubuntu-18.04 ubuntu/18.04 docker build -t gabrieleteotino/vsts-minimal-agent:ubuntu-18.04-core-node ubuntu/18.04/core-node docker image ls gabrieleteotino/vsts-minimal-agent REPOSITORY TAG IMAGE ID CREATED SIZE gabrieleteotino/vsts-minimal-agent ubuntu-18.04-core-node cc9eeb17ee72 25 minutes ago 2.2GB gabrieleteotino/vsts-minimal-agent ubuntu-18.04 6264c2f8ddec 37 minutes ago 472MB
2.2GB uncompressed for an image capable of running node and .net core.
Test the basic agent
Create a script vsts_minimal_agent_core_node.sh with the following content
docker run \ -e VSTS_ACCOUNT=<your organization name> \ -e VSTS_TOKEN=<pat> \ -e VSTS_AGENT='donbosco-agent-01' \ -e VSTS_POOL=Donbosco \ -it gabrieleteotino/vsts-minimal-agent:ubuntu-18.04-core-node --name vsts_agent_01
Note that this test can be done using the Default agent pool.
From VSTS site go in Agent pools and create a new agent pool, in my case named Donbosco like the VSTS_POOL parameter.
Run the agent
On VSTS create a new build script and change the Agent pool for the pipeline to Donbosco insert some step then Save and queue.
The build script I used to do the test will download a git repo, do a dotnet restore then a dotnet ef migrations script
In the docker TTY will appear
2018-09-05 10:09:13Z: Running job: Job 2018-09-05 10:09:59Z: Job Job completed with result: Succeeded
If we queue the job again
2018-09-05 10:10:46Z: Running job: Job 2018-09-05 10:11:08Z: Job Job completed with result: Succeeded
46 seconds for the first run and 22 second for the second run. The 24 second difference are mostly from the package restore step.
The same build running time on Microsoft Hosted Agent takes 1m 32s.
The difference became really noticeable with bigger jobs.