From 17eb51594d220658686ac25b183b661db0936e6c Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 21:33:11 -0700 Subject: Fix some grammar --- doc/container_registry/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/container_registry/README.md b/doc/container_registry/README.md index 4df24ef13cc..a7dac54a1ad 100644 --- a/doc/container_registry/README.md +++ b/doc/container_registry/README.md @@ -82,7 +82,7 @@ Make sure that your GitLab Runner is configured to allow building docker images. You have to check the [Using Docker Build documentation](../../ci/docker/using_docker_build.md). You can use [docker:dind](https://hub.docker.com/_/docker/) to build your images, -and this is how `.gitlab-ci.yml` should look like: +and this is how your `.gitlab-ci.yml` should look: ``` build_image: @@ -98,7 +98,7 @@ and this is how `.gitlab-ci.yml` should look like: You have to use the credentials of the special `gitlab-ci-token` user with its password stored in `$CI_BUILD_TOKEN` in order to push to the Registry connected -to your project. This allows you to automated building and deployment of your +to your project. This allows you to automate building and deployment of your Docker images. ## Limitations -- cgit v1.2.1 From 4209212bb80c8d92955bcc71fa8e6973b44cf59a Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 21:33:54 -0700 Subject: Add docker bind-mount as an option --- doc/ci/docker/using_docker_build.md | 78 ++++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 10 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index ca52a483a59..f98b2860e21 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -4,14 +4,14 @@ GitLab CI allows you to use Docker Engine to build and test docker-based project **This also allows to you to use `docker-compose` and other docker-enabled tools.** -This is one of new trends in Continuous Integration/Deployment to: +This is one of the new trends in Continuous Integration/Deployment to: -1. create application image, -1. run test against created image, -1. push image to remote registry, -1. deploy server from pushed image +1. create an application image, +1. run tests against the created image, +1. push image to a remote registry, +1. deploy server from the pushed image -It's also useful in case when your application already has the `Dockerfile` that can be used to create and test image: +It's also useful when your application already has the `Dockerfile` that can be used to create and test an image: ```bash $ docker build -t my-image dockerfiles/ $ docker run my-docker-image /script/to/run/tests @@ -19,10 +19,7 @@ $ docker tag my-image my-registry:5000/my-image $ docker push my-registry:5000/my-image ``` -However, this requires special configuration of GitLab Runner to enable `docker` support during build. -**This requires running GitLab Runner in privileged mode which can be harmful when untrusted code is run.** - -There are two methods to enable the use of `docker build` and `docker run` during build. +However, this requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds. ## 1. Use shell executor @@ -150,5 +147,66 @@ In order to do that follow the steps: An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker. +## 3. Bind Docker socket + +The third approach is to bind-mount `/var/run/docker.sock` into the container so that docker is available in the context of that image. + +In order to do that follow the steps: + +1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation). + +1. Register GitLab Runner from the command line to use `docker` and `privileged` + mode: + + ```bash + sudo gitlab-runner register -n \ + --url https://gitlab.com/ci \ + --token RUNNER_TOKEN \ + --executor docker \ + --description "My Docker Runner" \ + --docker-image "docker:latest" \ + --docker-volumes /var/run/docker.sock:/var/run/docker.sock + ``` + + The above command will register a new Runner to use the special + `docker:latest` image which is provided by Docker. **Notice that it's using + the Docker daemon of the runner itself, and any containers spawned by docker commands will be siblings of the runner rather than children of the runner.** This may have complications and limitations that are unsuitable for your workflow. + + The above command will create a `config.toml` entry similar to this: + + ``` + [[runners]] + url = "https://gitlab.com/ci" + token = TOKEN + executor = "docker" + [runners.docker] + tls_verify = false + image = "docker:latest" + privileged = false + disable_cache = false + volumes = ["/usr/local/bin/docker:/usr/bin/docker", "/cache"] + [runners.cache] + Insecure = false + ``` + +1. You can now use `docker` from build script (note that you don't need to include the `docker:dind` service as in the option above): + + ```yaml + image: docker:latest + + before_script: + - docker info + + build: + stage: build + script: + - docker build -t my-docker-image . + - docker run my-docker-image /script/to/run/tests + ``` + +1. However, by sharing the docker daemon, you are effectively disabling all + the security mechanisms of containers and exposing your host to privilege + escalation which can lead to container breakout. + [docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/ [docker-cap]: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities -- cgit v1.2.1 From d7664c7223cbd9e91e21beaf6ceb9ea7c2f294d8 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 21:34:30 -0700 Subject: Add example using GitLab Container Registry --- doc/ci/docker/using_docker_build.md | 72 +++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index f98b2860e21..fe2c5207cd1 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -208,5 +208,77 @@ In order to do that follow the steps: the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. +## Using the GitLab Container Registry + +Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md). + +``` + build: + stage: build + script: + - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com + - docker build -t registry.example.com/group/project:latest . + - docker push registry.example.com/group/project:latest +``` + +Here's a more elaborate example that splits up the tasks into 4 stages, +including two tests that run in parallel. The build is stored in the container +registry and used by subsequent stages, downloading the image +when needed. Changes to `master` also get tagged as `latest` and deployed using +an application-specific deploy script: + +```yaml +image: docker:git +services: +- docker:dind + +stages: +- build +- test +- release +- deploy + +variables: + CONTAINER_TEST_IMAGE: registry.example.com/my-group/my-project:$CI_BUILD_REF_NAME + CONTAINER_RELEASE_IMAGE: registry.example.com/my-group/my-project:latest + +before_script: + - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com + +build: + stage: build + script: + - docker build --pull -t $CONTAINER_TEST_IMAGE . + - docker push $CONTAINER_TEST_IMAGE + +test1: + stage: test + script: + - docker pull $CONTAINER_TEST_IMAGE + - docker run $CONTAINER_TEST_IMAGE /script/to/run/tests + +test2: + stage: test + script: + - docker pull $CONTAINER_TEST_IMAGE + - docker run $CONTAINER_TEST_IMAGE /script/to/run/another/test + +release-image: + stage: release + script: + - docker pull $CONTAINER_TEST_IMAGE + - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE + - docker push $CONTAINER_RELEASE_IMAGE + only: + - master + +deploy: + stage: deploy + script: + - ./deploy.sh + only: + - master +``` + [docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/ [docker-cap]: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities -- cgit v1.2.1 From 6841e76b45b44da9f749538dbae2bb1fc63d8ee4 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 22:09:15 -0700 Subject: Add notes --- doc/ci/docker/using_docker_build.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index fe2c5207cd1..a5f37366265 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -280,5 +280,11 @@ deploy: - master ``` +Notes: +1. You must log in to the container registry before running commands. Putting this in `before_script` will run it before each build job. +1. Using `docker build --pull` makes sure that Docker fetches any changes to base images before building just in case your cache is stale. It takes slightly longer, but means you don’t get stuck without security patches to base images. +1. Doing an explicit `docker pull` before each `docker run` makes sure to fetch the latest image that was just built. This is especially important if you are using multiple runners that cache images locally. Using the git SHA in your image tag makes this less necessary since each build will be unique and you shouldn't ever have a stale image, but it's still possible if you re-build a given commit after a dependency has changed. +1. You don't want to build directly to `latest` in case there are multiple builds happening simultaneously. + [docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/ [docker-cap]: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities -- cgit v1.2.1 From d9cbe019866843132225d440754a20da0e937d00 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 22:25:33 -0700 Subject: Moar commas --- doc/ci/docker/using_docker_build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index a5f37366265..4620eeac2b6 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -76,7 +76,7 @@ The second approach is to use the special Docker image with all tools installed (`docker` and `docker-compose`) and run the build script in context of that image in privileged mode. -In order to do that follow the steps: +In order to do that, follow the steps: 1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation). @@ -151,7 +151,7 @@ An example project using this approach can be found here: https://gitlab.com/git The third approach is to bind-mount `/var/run/docker.sock` into the container so that docker is available in the context of that image. -In order to do that follow the steps: +In order to do that, follow the steps: 1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation). -- cgit v1.2.1 From 84128441081869ff2bd260a92a7c0b43d68ca415 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 22:26:59 -0700 Subject: Fix instructions --- doc/ci/docker/using_docker_build.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 4620eeac2b6..62e48a6d8d6 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -155,8 +155,7 @@ In order to do that, follow the steps: 1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation). -1. Register GitLab Runner from the command line to use `docker` and `privileged` - mode: +1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`: ```bash sudo gitlab-runner register -n \ -- cgit v1.2.1 From 9b30f26b988f69995d1f548f79020c23dfe1a9ea Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 23:39:38 -0700 Subject: Fix runner CLI instructions --- doc/ci/docker/using_docker_build.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 62e48a6d8d6..3af4afbbefe 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -84,9 +84,9 @@ In order to do that, follow the steps: mode: ```bash - sudo gitlab-runner register -n \ + sudo gitlab-ci-multi-runner register -n \ --url https://gitlab.com/ci \ - --token RUNNER_TOKEN \ + --registration-token REGISTRATION_TOKEN \ --executor docker \ --description "My Docker Runner" \ --docker-image "docker:latest" \ @@ -158,9 +158,9 @@ In order to do that, follow the steps: 1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`: ```bash - sudo gitlab-runner register -n \ + sudo gitlab-ci-multi-runner register -n \ --url https://gitlab.com/ci \ - --token RUNNER_TOKEN \ + --registration-token REGISTRATION_TOKEN \ --executor docker \ --description "My Docker Runner" \ --docker-image "docker:latest" \ -- cgit v1.2.1 From 6ca1370c92dcf074af73562fb0fd613c8af45ce1 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Tue, 7 Jun 2016 23:50:26 -0700 Subject: Fix more instructions --- doc/ci/docker/using_docker_build.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 3af4afbbefe..aae37010508 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -24,16 +24,16 @@ However, this requires special configuration of GitLab Runner to enable `docker` ## 1. Use shell executor The simplest approach is to install GitLab Runner in `shell` execution mode. -GitLab Runner then executes build scripts as `gitlab-runner` user. +GitLab Runner then executes build scripts as the `gitlab-runner` user. 1. Install [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/#installation). 1. During GitLab Runner installation select `shell` as method of executing build scripts or use command: ```bash - $ sudo gitlab-runner register -n \ + $ sudo gitlab-ci-multi-runner register -n \ --url https://gitlab.com/ci \ - --token RUNNER_TOKEN \ + --registration-token REGISTRATION_TOKEN \ --executor shell --description "My Runner" ``` -- cgit v1.2.1 From db656a3987131816d47897b2424821b19ca147b0 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 00:28:23 -0700 Subject: Fix more references to old gitlab-runner --- doc/ci/docker/using_docker_images.md | 2 +- doc/ci/examples/php.md | 4 ++-- doc/ci/runners/README.md | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 56ac2195c49..a849905ac6b 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -23,7 +23,7 @@ To use GitLab Runner with docker you need to register a new runner to use the `docker` executor: ```bash -gitlab-runner register \ +gitlab-ci-multi-runner register \ --url "https://gitlab.com/" \ --registration-token "PROJECT_REGISTRATION_TOKEN" \ --description "docker-ruby-2.1" \ diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md index 26953014502..17e1c64bb8a 100644 --- a/doc/ci/examples/php.md +++ b/doc/ci/examples/php.md @@ -263,10 +263,10 @@ terminal execute: ```bash # Check using docker executor -gitlab-runner exec docker test:app +gitlab-ci-multi-runner exec docker test:app # Check using shell executor -gitlab-runner exec shell test:app +gitlab-ci-multi-runner exec shell test:app ``` ## Example project diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index b42d7a62ebc..400784da617 100644 --- a/doc/ci/runners/README.md +++ b/doc/ci/runners/README.md @@ -63,10 +63,10 @@ instance. Now simply register the runner as any runner: ``` -sudo gitlab-runner register +sudo gitlab-ci-multi-runner register ``` -Shared runners are enabled by default as of GitLab 8.2, but can be disabled with the +Shared runners are enabled by default as of GitLab 8.2, but can be disabled with the `DISABLE SHARED RUNNERS` button. Previous versions of GitLab defaulted shared runners to disabled. @@ -93,7 +93,7 @@ setup a specific runner for this project. To register the runner, run the command below and follow instructions: ``` -sudo gitlab-runner register +sudo gitlab-ci-multi-runner register ``` ### Making an existing Shared Runner Specific -- cgit v1.2.1 From e97af053eb24391df926cb7f7ca20d67a4ff03d0 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 11:10:06 -0700 Subject: Fix docker volume --- doc/ci/docker/using_docker_build.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index aae37010508..5df1fdd84c7 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -183,7 +183,7 @@ In order to do that, follow the steps: image = "docker:latest" privileged = false disable_cache = false - volumes = ["/usr/local/bin/docker:/usr/bin/docker", "/cache"] + volumes = ["/var/run/docker.sock", "/cache"] [runners.cache] Insecure = false ``` -- cgit v1.2.1 From 46114eddf0a2fc07f932fe45948a48896abbeb78 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 11:39:31 -0700 Subject: Add more pros and cons for each docker approach --- doc/ci/docker/using_docker_build.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 5df1fdd84c7..17ba953ca73 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -19,7 +19,7 @@ $ docker tag my-image my-registry:5000/my-image $ docker push my-registry:5000/my-image ``` -However, this requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds. +However, this requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs. ## 1. Use shell executor @@ -67,7 +67,7 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. -6. However, by adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. +However, by adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). ## 2. Use docker-in-docker executor @@ -138,12 +138,16 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -1. However, by enabling `--docker-privileged` you are effectively disabling all - the security mechanisms of containers and exposing your host to privilege - escalation which can lead to container breakout. +However, by enabling `--docker-privileged` you are effectively disabling all +the security mechanisms of containers and exposing your host to privilege +escalation which can lead to container breakout. For more information, check out the official Docker documentation on +[Runtime privilege and Linux capabilities][docker-cap]. - For more information, check out the official Docker documentation on - [Runtime privilege and Linux capabilities][docker-cap]. +Using docker-in-docker, each build is in a clean environment without the past +history. Concurrent builds work fine because every build get it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers. + +By default `docker:dind` uses ``--storage-driver vfs` which is the slowest form +offered. An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker. @@ -203,9 +207,14 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -1. However, by sharing the docker daemon, you are effectively disabling all - the security mechanisms of containers and exposing your host to privilege - escalation which can lead to container breakout. +However, by sharing the docker daemon, you are effectively disabling all +the security mechanisms of containers and exposing your host to privilege +escalation which can lead to container breakout. For example, if a project +ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner +containers. + +Also, concurrent builds may not work; if your tests +create containers with specific names, they may conflict with each other. ## Using the GitLab Container Registry -- cgit v1.2.1 From 1c02ef9c144f3a8d40e31a21d82b5628e72d48e6 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 12:00:17 -0700 Subject: Drop some 'however's --- doc/ci/docker/using_docker_build.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 17ba953ca73..cc820d81144 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -19,7 +19,7 @@ $ docker tag my-image my-registry:5000/my-image $ docker push my-registry:5000/my-image ``` -However, this requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs. +This requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs. ## 1. Use shell executor @@ -67,7 +67,7 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. -However, by adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. +By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). ## 2. Use docker-in-docker executor @@ -138,7 +138,7 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -However, by enabling `--docker-privileged` you are effectively disabling all +By enabling `--docker-privileged` you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on [Runtime privilege and Linux capabilities][docker-cap]. @@ -207,7 +207,7 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -However, by sharing the docker daemon, you are effectively disabling all +By sharing the docker daemon, you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For example, if a project ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner -- cgit v1.2.1 From b393478f63ad2f4381996dc08111fc3393bf762e Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 12:11:44 -0700 Subject: Refactor notes --- doc/ci/docker/using_docker_build.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index cc820d81144..5af6d36e83e 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -67,7 +67,8 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. -By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. +Notes: +* By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). ## 2. Use docker-in-docker executor @@ -138,15 +139,16 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -By enabling `--docker-privileged` you are effectively disabling all +Notes: +* By enabling `--docker-privileged` you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on [Runtime privilege and Linux capabilities][docker-cap]. -Using docker-in-docker, each build is in a clean environment without the past +* Using docker-in-docker, each build is in a clean environment without the past history. Concurrent builds work fine because every build get it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers. -By default `docker:dind` uses ``--storage-driver vfs` which is the slowest form +* By default, `docker:dind` uses ``--storage-driver vfs` which is the slowest form offered. An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker. @@ -207,15 +209,21 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -By sharing the docker daemon, you are effectively disabling all +Notes: +* By sharing the docker daemon, you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For example, if a project ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner containers. -Also, concurrent builds may not work; if your tests +* Concurrent builds may not work; if your tests create containers with specific names, they may conflict with each other. +* Sharing files and directories from the source repo into containers may not +work as expected since volume mounting is done in the context of the host +machine, not the build container. +e.g. `docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests` + ## Using the GitLab Container Registry Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md). -- cgit v1.2.1 From b0cbeb18d1864ab36fb17c69d963321d745924fa Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 14:11:15 -0700 Subject: Remove unnecessary message --- doc/ci/docker/using_docker_build.md | 4 ---- 1 file changed, 4 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 5af6d36e83e..c44b1d7a0cc 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -117,10 +117,6 @@ In order to do that, follow the steps: Insecure = false ``` - If you want to use the Shared Runners available on your GitLab CE/EE - installation in order to build Docker images, then make sure that your - Shared Runners configuration has the `privileged` mode set to `true`. - 1. You can now use `docker` from build script: ```yaml -- cgit v1.2.1 From 6f834ecaa94a1da230c933c981b33634d937d8dd Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 14:17:03 -0700 Subject: Reformat notes --- doc/ci/docker/using_docker_build.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index c44b1d7a0cc..697b9f10163 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -67,7 +67,7 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. -Notes: +### Notes * By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). @@ -135,7 +135,7 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -Notes: +### Notes * By enabling `--docker-privileged` you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on @@ -205,7 +205,7 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -Notes: +### Notes * By sharing the docker daemon, you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For example, if a project @@ -292,7 +292,7 @@ deploy: - master ``` -Notes: +### Notes 1. You must log in to the container registry before running commands. Putting this in `before_script` will run it before each build job. 1. Using `docker build --pull` makes sure that Docker fetches any changes to base images before building just in case your cache is stale. It takes slightly longer, but means you don’t get stuck without security patches to base images. 1. Doing an explicit `docker pull` before each `docker run` makes sure to fetch the latest image that was just built. This is especially important if you are using multiple runners that cache images locally. Using the git SHA in your image tag makes this less necessary since each build will be unique and you shouldn't ever have a stale image, but it's still possible if you re-build a given commit after a dependency has changed. -- cgit v1.2.1 From 35ce04ef2e02e5b176c57567f2ddf82871af7639 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 14:40:56 -0700 Subject: Move registry CI example to CI docs --- doc/ci/docker/using_docker_build.md | 22 ++++++++++++++++++---- doc/container_registry/README.md | 23 ++--------------------- 2 files changed, 20 insertions(+), 25 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 697b9f10163..33b1624d00b 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -73,7 +73,8 @@ For more information please checkout [On Docker security: `docker` group conside ## 2. Use docker-in-docker executor -The second approach is to use the special Docker image with all tools installed +The second approach is to use the special docker-in-docker (dind) +[Docker image](https://hub.docker.com/_/docker/) with all tools installed (`docker` and `docker-compose`) and run the build script in context of that image in privileged mode. @@ -222,10 +223,18 @@ e.g. `docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_ap ## Using the GitLab Container Registry -Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md). +> **Note:** +This feature requires GitLab 8.8 and GitLab Runner 1.2. -``` +Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md). For example, if you're using +docker-in-docker on your runners, this is how your `.gitlab-ci.yml` could look: + + +```yaml build: + image: docker:git + services: + - docker:dind stage: build script: - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com @@ -233,7 +242,12 @@ Once you've built a Docker image, you can push it up to the built-in [GitLab Con - docker push registry.example.com/group/project:latest ``` -Here's a more elaborate example that splits up the tasks into 4 stages, +You have to use the credentials of the special `gitlab-ci-token` user with its +password stored in `$CI_BUILD_TOKEN` in order to push to the Registry connected +to your project. This allows you to automate building and deployment of your +Docker images. + +Here's a more elaborate example that splits up the tasks into 4 pipeline stages, including two tests that run in parallel. The build is stored in the container registry and used by subsequent stages, downloading the image when needed. Changes to `master` also get tagged as `latest` and deployed using diff --git a/doc/container_registry/README.md b/doc/container_registry/README.md index a7dac54a1ad..1b465434498 100644 --- a/doc/container_registry/README.md +++ b/doc/container_registry/README.md @@ -79,27 +79,8 @@ delete them. This feature requires GitLab 8.8 and GitLab Runner 1.2. Make sure that your GitLab Runner is configured to allow building docker images. -You have to check the [Using Docker Build documentation](../../ci/docker/using_docker_build.md). - -You can use [docker:dind](https://hub.docker.com/_/docker/) to build your images, -and this is how your `.gitlab-ci.yml` should look: - -``` - build_image: - image: docker:git - services: - - docker:dind - stage: build - script: - - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com - - docker build -t registry.example.com/group/project:latest . - - docker push registry.example.com/group/project:latest -``` - -You have to use the credentials of the special `gitlab-ci-token` user with its -password stored in `$CI_BUILD_TOKEN` in order to push to the Registry connected -to your project. This allows you to automate building and deployment of your -Docker images. +You have to check the [Using Docker Build documentation](../ci/docker/using_docker_build.md). +Then see the CI documentation on [Using the GitLab Container Registry](../ci/docker/using_docker_build.md#using-the-gitlab-container-registry). ## Limitations -- cgit v1.2.1 From a7caea9e3e6b624ada8d3dbabf13c2f9ad79b463 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 8 Jun 2016 15:41:27 -0700 Subject: Use docker:latest --- doc/ci/docker/using_docker_build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 33b1624d00b..d5bc1d7406e 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -232,7 +232,7 @@ docker-in-docker on your runners, this is how your `.gitlab-ci.yml` could look: ```yaml build: - image: docker:git + image: docker:latest services: - docker:dind stage: build @@ -254,7 +254,7 @@ when needed. Changes to `master` also get tagged as `latest` and deployed using an application-specific deploy script: ```yaml -image: docker:git +image: docker:latest services: - docker:dind -- cgit v1.2.1 From f95791d4118e7a1ad85ab0f287784c5639182560 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Mon, 13 Jun 2016 22:32:01 -0700 Subject: Make Achilleas' suggested changes --- doc/ci/docker/using_docker_build.md | 56 ++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 28 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index d5bc1d7406e..77291597659 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -4,12 +4,12 @@ GitLab CI allows you to use Docker Engine to build and test docker-based project **This also allows to you to use `docker-compose` and other docker-enabled tools.** -This is one of the new trends in Continuous Integration/Deployment to: +One of the new trends in Continuous Integration/Deployment is to: 1. create an application image, 1. run tests against the created image, -1. push image to a remote registry, -1. deploy server from the pushed image +1. push image to a remote registry, and +1. deploy to a server from the pushed image. It's also useful when your application already has the `Dockerfile` that can be used to create and test an image: ```bash @@ -19,9 +19,13 @@ $ docker tag my-image my-registry:5000/my-image $ docker push my-registry:5000/my-image ``` -This requires special configuration of GitLab Runner to enable `docker` support during builds. There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs. +This requires special configuration of GitLab Runner to enable `docker` support during builds. -## 1. Use shell executor +## Runner Configuration + +There are three methods to enable the use of `docker build` and `docker run` during builds; each with their own tradeoffs. + +### Use shell executor The simplest approach is to install GitLab Runner in `shell` execution mode. GitLab Runner then executes build scripts as the `gitlab-runner` user. @@ -67,11 +71,11 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. -### Notes +> **Note:** * By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. -For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). +For more information please check out [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). -## 2. Use docker-in-docker executor +### Use docker-in-docker executor The second approach is to use the special docker-in-docker (dind) [Docker image](https://hub.docker.com/_/docker/) with all tools installed @@ -118,7 +122,7 @@ In order to do that, follow the steps: Insecure = false ``` -1. You can now use `docker` from build script: +1. You can now use `docker` in the build script: ```yaml image: docker:latest @@ -136,21 +140,19 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -### Notes -* By enabling `--docker-privileged` you are effectively disabling all +> **Notes:** +> * By enabling `--docker-privileged`, you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on [Runtime privilege and Linux capabilities][docker-cap]. - -* Using docker-in-docker, each build is in a clean environment without the past -history. Concurrent builds work fine because every build get it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers. - -* By default, `docker:dind` uses ``--storage-driver vfs` which is the slowest form +> * Using docker-in-docker, each build is in a clean environment without the past +history. Concurrent builds work fine because every build gets it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers. +> * By default, `docker:dind` uses `--storage-driver vfs` which is the slowest form offered. An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker. -## 3. Bind Docker socket +### Use Docker socket binding The third approach is to bind-mount `/var/run/docker.sock` into the container so that docker is available in the context of that image. @@ -172,14 +174,14 @@ In order to do that, follow the steps: The above command will register a new Runner to use the special `docker:latest` image which is provided by Docker. **Notice that it's using - the Docker daemon of the runner itself, and any containers spawned by docker commands will be siblings of the runner rather than children of the runner.** This may have complications and limitations that are unsuitable for your workflow. + the Docker daemon of the Runner itself, and any containers spawned by docker commands will be siblings of the Runner rather than children of the runner.** This may have complications and limitations that are unsuitable for your workflow. The above command will create a `config.toml` entry similar to this: ``` [[runners]] url = "https://gitlab.com/ci" - token = TOKEN + token = REGISTRATION_TOKEN executor = "docker" [runners.docker] tls_verify = false @@ -191,7 +193,7 @@ In order to do that, follow the steps: Insecure = false ``` -1. You can now use `docker` from build script (note that you don't need to include the `docker:dind` service as in the option above): +1. You can now use `docker` in the build script (note that you don't need to include the `docker:dind` service as when using the Docker in Docker executor): ```yaml image: docker:latest @@ -206,16 +208,14 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -### Notes +While the above method avoids using Docker in privileged mode, you should be aware of the following implications: * By sharing the docker daemon, you are effectively disabling all the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For example, if a project ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner containers. - * Concurrent builds may not work; if your tests create containers with specific names, they may conflict with each other. - * Sharing files and directories from the source repo into containers may not work as expected since volume mounting is done in the context of the host machine, not the build container. @@ -306,11 +306,11 @@ deploy: - master ``` -### Notes -1. You must log in to the container registry before running commands. Putting this in `before_script` will run it before each build job. -1. Using `docker build --pull` makes sure that Docker fetches any changes to base images before building just in case your cache is stale. It takes slightly longer, but means you don’t get stuck without security patches to base images. -1. Doing an explicit `docker pull` before each `docker run` makes sure to fetch the latest image that was just built. This is especially important if you are using multiple runners that cache images locally. Using the git SHA in your image tag makes this less necessary since each build will be unique and you shouldn't ever have a stale image, but it's still possible if you re-build a given commit after a dependency has changed. -1. You don't want to build directly to `latest` in case there are multiple builds happening simultaneously. +Some things you should be aware of when using the Container Registry: +* You must log in to the container registry before running commands. Putting this in `before_script` will run it before each build job. +* Using `docker build --pull` makes sure that Docker fetches any changes to base images before building just in case your cache is stale. It takes slightly longer, but means you don’t get stuck without security patches to base images. +* Doing an explicit `docker pull` before each `docker run` makes sure to fetch the latest image that was just built. This is especially important if you are using multiple runners that cache images locally. Using the git SHA in your image tag makes this less necessary since each build will be unique and you shouldn't ever have a stale image, but it's still possible if you re-build a given commit after a dependency has changed. +* You don't want to build directly to `latest` in case there are multiple builds happening simultaneously. [docker-in-docker]: https://blog.docker.com/2013/09/docker-can-now-run-within-docker/ [docker-cap]: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities -- cgit v1.2.1 From 4c571041de6989d71f09fc326f8d6bee731f0b19 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Mon, 13 Jun 2016 22:36:28 -0700 Subject: Make minor grammar change --- doc/ci/docker/using_docker_build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 77291597659..09a2d8b5966 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -72,8 +72,8 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user. 5. You can now use `docker` command and install `docker-compose` if needed. > **Note:** -* By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions. -For more information please check out [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). +* By adding `gitlab-runner` to the `docker` group you are effectively granting `gitlab-runner` full root permissions. +For more information please read [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful). ### Use docker-in-docker executor -- cgit v1.2.1 From aefb08cb6a8bd15415b641c385e790f941b72ced Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Mon, 13 Jun 2016 22:42:46 -0700 Subject: Clarify dind example --- doc/ci/docker/using_docker_build.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 09a2d8b5966..36ff4dcf05a 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -122,7 +122,7 @@ In order to do that, follow the steps: Insecure = false ``` -1. You can now use `docker` in the build script: +1. You can now use `docker` in the build script (note the inclusion of the `docker:dind` service): ```yaml image: docker:latest @@ -141,7 +141,7 @@ In order to do that, follow the steps: ``` > **Notes:** -> * By enabling `--docker-privileged`, you are effectively disabling all +> * By enabling `--docker-privileged`, you are effectively disabling all of the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on [Runtime privilege and Linux capabilities][docker-cap]. -- cgit v1.2.1 From 8df7d90d5a92b7d8aa26ac07b7391b4e86d63499 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Mon, 13 Jun 2016 22:45:43 -0700 Subject: De-note-ify --- doc/ci/docker/using_docker_build.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 36ff4dcf05a..39eea740d18 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -140,14 +140,14 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -> **Notes:** -> * By enabling `--docker-privileged`, you are effectively disabling all of +Docker-in-Docker works well, and is our recommended configuration, but it is not without its own challenges: +* By enabling `--docker-privileged`, you are effectively disabling all of the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on [Runtime privilege and Linux capabilities][docker-cap]. -> * Using docker-in-docker, each build is in a clean environment without the past +* Using docker-in-docker, each build is in a clean environment without the past history. Concurrent builds work fine because every build gets it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers. -> * By default, `docker:dind` uses `--storage-driver vfs` which is the slowest form +* By default, `docker:dind` uses `--storage-driver vfs` which is the slowest form offered. An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker. -- cgit v1.2.1 From 6ed7fcad29d0b96b4513c2961c342d0309eda07e Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Mon, 13 Jun 2016 22:47:54 -0700 Subject: Remove our --- doc/ci/docker/using_docker_build.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 39eea740d18..7f83f846454 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -140,7 +140,7 @@ In order to do that, follow the steps: - docker run my-docker-image /script/to/run/tests ``` -Docker-in-Docker works well, and is our recommended configuration, but it is not without its own challenges: +Docker-in-Docker works well, and is the recommended configuration, but it is not without its own challenges: * By enabling `--docker-privileged`, you are effectively disabling all of the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout. For more information, check out the official Docker documentation on -- cgit v1.2.1 From 120fbbd4875f340b5c863b7e0e3eabcb2796e15d Mon Sep 17 00:00:00 2001 From: Paco Guzman Date: Mon, 13 Jun 2016 18:41:37 +0200 Subject: Measure CPU time for instrumented methods --- doc/development/instrumentation.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md index 9168c70945a..50d2866ca46 100644 --- a/doc/development/instrumentation.md +++ b/doc/development/instrumentation.md @@ -97,15 +97,16 @@ def #{name}(#{args_signature}) trans = Gitlab::Metrics::Instrumentation.transaction if trans - start = Time.now - retval = super - duration = (Time.now - start) * 1000.0 + start = Time.now + cpu_start = Gitlab::Metrics::System.cpu_time + retval = super + duration = (Time.now - start) * 1000.0 if duration >= Gitlab::Metrics.method_call_threshold - trans.increment(:method_duration, duration) + cpu_duration = Gitlab::Metrics::System.cpu_time - cpu_start trans.add_metric(Gitlab::Metrics::Instrumentation::SERIES, - { duration: duration }, + { duration: duration, cpu_duration: cpu_duration }, method: #{label.inspect}) end -- cgit v1.2.1