Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gitlab-runner
gitlab-runner
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,998
    • Issues 1,998
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 204
    • Merge Requests 204
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • gitlab-runnergitlab-runner
  • Merge Requests
  • !1569

Merged
Opened Sep 06, 2019 by Steve Exley@steve.exleyContributor3 of 3 tasks completed3/3 tasks

Create network per build in docker executor

  • Overview 293
  • Commits 79
  • Pipelines 36
  • Changes 18

What does this MR do?

Re-Opens !1041 (closed). Rebased onto v12

Add support for per-job Docker network creation, based on !609 (closed), and built on top of !895 (closed) (rebased on master). By nature of its implementation it also provides a workaround fix for corporate DNS resolution as outlined in https://github.com/docker/libnetwork/issues/2187, and may mitigate issues such as #1541 (closed).

Why was this MR needed?

There is a huge need of proper service discovery b/w the job container and the service container(s). Use cases include:

  • Running a selenium grid peer to the build container which can see the build container (i.e. karma tests).
  • Replicating service based environments which depend on multiple services being able to communicate using Docker networks
  • Set up complex interdependent application stacks.

Docker has indicated that the current links functionality used by Gitlab Runners is a legacy feature that may eventually be removed and advises using Docker Networks instead

Previous MR !1041 (closed) was the most popular MR for the Gitlab Runner project by a significant margin and received community contributions indicating the need for this feature.

Are there points in the code the reviewer needs to double check?

The feature works and has been used extensively by some of the followers on !1041 (closed). However it would benefit from a review by somebody more familiar with the code.

At the time of opening the MR, there are some issues around static QA which I've not yet addressed.

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Added tests for this feature/bug
  • In case of conflicts with master - branch was rebased

Network per build vs Container mode networking

We had extensive discussions on whether which option is better, we had 2 to choose from Network per build (what this merge request is achieving) and Container Mode what !1674 (closed) is achieving. Below are some links that are noteworthy on how we come to a decision:

  • !1674 (comment 266948542)
  • Decision taken in !1674 (comment 269674747)

What are the relevant issue numbers?

Closes #1042 (closed) #4430 (closed) #2699 (closed)

Based off of !609 (closed) and !895 (closed).

Partial fix for #1541 (closed).

Edited Feb 21, 2020 by Steve Azzopardi
Assignee
Assign to
Reviewer
Request review from
12.9
Milestone
12.9 (Past due)
Assign milestone
Time tracking
Reference: gitlab-org/gitlab-runner!1569
Source branch: gitlab-runner-add-network-per-build

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.