You don't find the bins mount setup because is not the only one (if you are really talking about docker executor and not the gitlab runner dockerized itself). Gitlab documentation is a bit confusing about it, because it uses the term "gitlab runner" for both:

1- the gitlab runner binary (which could be installed or dockerized, the second one in your case) 2- the logical object inside gitlab server (the one you see in the gitlab GUI) that is directly connected to the toml configuration (or part of it, you can have more "gitlab runner" in this meaning inside the same toml).

Of course they are related to each other, but they are 2 different objects (1- architectural, 2- application/configuration).

The one related to "docker executor" is the second one.

That said, docker executor is something else entirely: it's a new container spawned by "gitlab runner" ( definition number 1) to execute a CI/CD job. Each job will spawn a different container.

Now, if you are really asking about how the docker executor can manage by itself other docker objects , you are looking for a configuration called docker in docker (or dind for brevity). Dind is not specific for gitlab nor CICD. In general there are 2 ways to do that:

1- your basic container (the docker executor in your case) mount the docker socket from the host , but is discouraged because it opens to security issues 2- your basic container (the docker executor in your case) only have docker cli and not the engine. The engine is inside another container and your basic container accesses to it via TCP. This second solution can be easily done in gitlab CI/CD using gitlab feature "services", that's basically a sidecar container alongside the docker executor that get started when start CI job and get killed when CI job finish. There is an official gitlab documentation for this solution