My Jenkins Story: Why I prefer to use non-containerised agents than using Docker containers as agents

It is possible to use throw-away Docker containers as a Jenkins ‘agent’ and this method is increasingly becoming more and more popular. All it does is spin up a Docker container that where your build will happen. Jenkins core support this now and it is flexible with one of the plus is that you don’t need to go through a somewhat tedious process of setting up a physical (non-container) agent and manage it afterwards.

However, as a personal taste, I prefer to have a more traditional Jenkins setup where you have a master and a number of slaves as agents ready to build configured jobs. The agent slaves would be registered under the nodes section within Jenkins.

One of the benefits is the trade-off of having to manage the lifecycle of these non-container agents against the power + freedom of controlling what tooling this particular agent or agents have at their disposal. And I, like to have this power & freedom.

As an example, to make things really simple (as I like simple solutions), I personally prefer to have a ‘god’ like agent that has a massive toolkit (java, git, maven, gradle, ant, terraform, packer, node, npm, aws-cli, ansible, chef, puppet, etc… and the list of tools goes on).