github.com/ssube/gitlab-ci-multi-runner@v1.2.1-0.20160607142738-b8d1285632e6/docs/executors/README.md (about)

     1  # Executors
     2  
     3  GitLab Runner implements a number of executors that can be used to run your
     4  builds in different scenarios:
     5  
     6  - [Shell](shell.md)
     7  - [Docker](docker.md)
     8  - [Docker Machine and Docker Machine SSH (auto-scaling)](../install/autoscaling.md)
     9  - [Parallels](parallels.md)
    10  - [VirtualBox](virtualbox.md)
    11  - [SSH](ssh.md)
    12  
    13  ## Select the executor
    14  
    15  The executors support different platforms and methodologies for building a
    16  project. The table below shows the key facts for each executor which will help
    17  you decide.
    18  
    19  | Executor                                          | Shell   | Docker | Docker-SSH | VirtualBox | Parallels | SSH  |
    20  |---------------------------------------------------|---------|--------|------------|------------|-----------|------|
    21  | Clean build environment for every build           | no      | ✓      | ✓          | ✓          | ✓         | no   |
    22  | Migrate runner machine                            | no      | ✓      | ✓          | partial    | partial   | no   |
    23  | Zero-configuration support for concurrent builds  | no (1)  | ✓      | ✓          | ✓          | ✓         | no   |
    24  | Complicated build environments                    | no (2)  | ✓      | ✓          | ✓ (3)      | ✓ (3)     | no   |
    25  | Debugging build problems                          | easy    | medium | medium     | hard       | hard      | easy |
    26  
    27  1. it's possible, but in most cases it is problematic if the build uses services
    28     installed on the build machine
    29  2. it requires to install all dependencies by hand
    30  3. for example using Vagrant
    31  
    32  ### I'm not sure
    33  
    34  **Shell** is the simplest executor to configure. All required dependencies for
    35  your builds need to be installed manually on the machine that the Runner is
    36  installed.
    37  
    38  A better way is to use **Docker** as it allows to have a clean build environment,
    39  with easy dependency management (all dependencies for building the project could
    40  be put in the Docker image). The Docker executor allows you to easily create
    41  a build environment with dependent [services], like MySQL.
    42  
    43  We usually don't advise to use **Docker-SSH** which is a special version of
    44  the **Docker** executor. This executor allows you to connect to a Docker
    45  container that runs the **SSH** daemon inside it. It can be useful if your
    46  Docker image tries to replicate a full working system: it uses some process
    47  management system (`init`), exposes the SSH daemon, and contains already
    48  installed services. These kind of images are fat images, and are not generally
    49  advised to be used by the Docker community.
    50  
    51  We also offer two full system virtualization options: **VirtualBox** and
    52  **Parallels**. This type of executor allows you to use an already created
    53  virtual machine, which will be cloned and used to run your build. It can prove
    54  useful if you want to run your builds on different Operating Systems since it
    55  allows to create virtual machines with Windows, Linux, OSX or FreeBSD and make
    56  GitLab Runner to connect to the virtual machine and run the build on it. Its
    57  usage can also be useful to reduce the cost of infrastructure.
    58  
    59  The **SSH** executor is added for completeness. It's the least supported
    60  executor from all of the already mentioned ones. It makes GitLab Runner to
    61  connect to some external server and run the builds there. We have some success
    62  stories from organizations using that executor, but generally we advise to use
    63  any of the above.
    64  
    65  [services]: http://doc.gitlab.com/ce/ci/services/README.html