Runners and agents: hosted, self-hosted, cost, licenses, connection

Nordlicht Reisen GmbH, a fictional travel agency, has so far built the booking portal on the machines that GitHub and Microsoft provide. Now three requirements come together: a test run needs far more memory than those machines have, the deployment must reach a database in the company network that is not visible from outside, and at nine in the morning many runs start at the same time. You are to design the infrastructure on which the runs take place. That is the skill of this lesson: designing an infrastructure for GitHub runners or Azure DevOps agents, with a view to cost, tools, licenses, connection and maintainability.

Prior knowledge: K3, lesson 3.7.1, names GitHub's runners and self-hosted runners; K3, lesson 3.7.2, the section "Your own agents" with agent pools and the Managed DevOps Pools; and K3, lesson 3.7.7, why foreign code from pull requests should not run on your own machine. Here you learn the choice between all the kinds, and the names and options the exam expects.

Not run against Azure or GitHub; from the reference of Microsoft and GitHub: All commands and YAML files of this lesson come from the documentation; they were not run in this course. The pages change: check image names, sizes and billing rules on the current page before every decision.

The map: who runs the job?

An agent (Azure Pipelines) or runner (GitHub Actions) is the machine with the software that picks up a job and runs it, one job at a time each. The only question is who owns the machine and who maintains it.

Note the names: in Azure DevOps, the larger machines operated by GitHub are called "GitHub-hosted agents", at GitHub itself "larger runners". The Microsoft document says that the GitHub-hosted agents run on the same infrastructure as the larger runners of GitHub Actions.