#Dagger in Gitlab

1 messages · Page 1 of 1 (latest)

dire veldt
#

Btw, if you have any trouble, we can take a look today. Feel free to ping if you have any question 😇 That could be a nice docs improvement

#

@neat flax I believe you can copy most of the docker stuff, then, on the .dagger part, you just install Go and run the script. Dagger shall autoprovision itself

#

So, copy:

.docker:
  image: docker:${DOCKER_VERSION}-git
  services:
    - docker:${DOCKER_VERSION}-dind
  variables:
    # See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#docker-in-docker-with-tls-enabled-in-the-docker-executor
    DOCKER_HOST: tcp://docker:2376

    DOCKER_TLS_VERIFY: "1"
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_CERT_PATH: "/certs/client"

    # Faster than the default, apparently
    DOCKER_DRIVER: overlay2

    DOCKER_VERSION: "20.10"

.dagger:
  extends: [.docker]




  // TODO:
  // add Go
  // checkout multiarch example. Shall autoprovision itself
neat flax
#

ahh, perfect, thanks!

dire veldt
neat flax
#

So, Ihave the multiarch running locally, and can do go run path/to/main.go https:://repo so I think

  1. install Go in Docker
  2. run app go run path/to/main.go repo
  3. profit
dire veldt
neat flax
#

I've not used DIND for a long time.

#

Just rusty 😉

#

reviewing the dagger-cue/install.sh

dire veldt
elfin blade
#

@neat flax feel free to ping me for this too - I just got a gitlab-ci setup with Dagger running last Friday 😄

neat flax
#

@elfin blade thanks, will do

#

progress so far is:

  • Successfully installed Go in DIND docker
  • Now running with a before_script
  • And whilst I wait, creating a container from the DIND image which has Go installed to reduce the duration of the pipeline
# 
  image: docker:${DOCKER_VERSION}-git
  services:
    - docker:${DOCKER_VERSION}-dind
  variables:
    # See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#docker-in-docker-with-tls-enabled-in-the-docker-executor
    DOCKER_HOST: tcp://docker:2376

    DOCKER_TLS_VERIFY: "1"
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_CERT_PATH: "/certs/client"

    # Faster than the default, apparently
    DOCKER_DRIVER: overlay2

    DOCKER_VERSION: "20.10"

.dagger-go:
  extends: [.docker]
  variables:
    DAGGER_VERSION: 0.2.232
    DAGGER_LOG_FORMAT: plain
    DAGGER_CACHE_PATH: .dagger-cache

    ARGS: ""
  cache:
    key: dagger-${CI_JOB_NAME}
    paths:
      - ${DAGGER_CACHE_PATH}
  before_script:
    - |
      # install Go
      echo "installing go version 1.19.4..." 
      apk add --no-cache --virtual .build-deps bash gcc musl-dev openssl go 
      wget -O go.tgz https://dl.google.com/go/go1.19.4.src.tar.gz 
      tar -C /usr/local -xzf go.tgz 
      cd /usr/local/go/src/ 
      ./make.bash 
      export PATH="/usr/local/go/bin:$PATH"
      export GOPATH=/opt/go/ 
      export PATH=$PATH:$GOPATH/bin 
      apk del .build-deps 

      go version
  script:
    - |
      echo "Runing CMD: ${CMD}"
      go run ${CMD}

run-go-pipeline:
  extends: [.dagger-go]
  variables:
    CMD: experiments/01-go-multiarch/main.go https://github.com/jbendotnet/helloworld
#

Path failed, but making progress - lunch now.

plain talon
dire veldt
elfin blade
# dire veldt Is your example on a public repo ? 😇

Not atm no, I was planning to clean up and publish before the community call I'm joining but that's not until Jan - happy to share any details you want, but the Gitlab CI side is mostly just copy-paste from your docs 🙂

neat flax
#

Ok, fighting a bit (we have on-prem Gitlab so can't assume things are 100% the same).

I'm attempting to get the CUE todoapp running.

ERROR: error during connect: Get "http://docker:2376/v1.24/info": dial tcp: lookup docker on 10.43.0.10:53: no such host

I get this error, what can I configure in the dagger.cue to change the addr used?

#

tangentially, the experience of writing Go to write the pipelines was seamless, the experience of deploying the pipelines in CI less so - sure it will improve

west zenith
# 
.docker:
  image: golang:1.19-alpine
  services:
    - docker:${DOCKER_VERSION}-dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_VERIFY: '1'
    DOCKER_TLS_CERTDIR: '/certs'
    DOCKER_CERT_PATH: '/certs/client'
    DOCKER_DRIVER: overlay2
    DOCKER_VERSION: '20.10.16'
.dagger:
  extends: [.docker]
  before_script:
    - apk add docker-cli
build:
  extends: [.dagger]
  script:
    - go run main.go
neat flax
#

thanks! I will try that now.

# 
$ go run main.go
2022/12/08 14:44:06 Hello, world!
#

@west zenith thank you

west zenith
neat flax
#

thanks 🙂

#

it's more my lack of DIND in Gitlab that's causing pain, we build with Kaniko in Kube now, so the process is a bit different.

# 
$ docker info
unable to resolve docker endpoint: open /certs/client/ca.pem: no such file or directory

Is it possible to run Dagger without privilege escalation ?

dire veldt
neat flax
#

yeah, I think it's a bit of a non-starter with our deployed runners, so I'm going to run a local runner, which should work 🙂

#

thanks for all the help

elfin blade
#

@neat flax we run k8s runners, for dind they need to run as privileged containers but the rest is fairly smooth sailing

violet wave
neat flax
#

@violet wave @elfin blade hi - sorry for the delay - I've spoken to our SRE team and the feedback was to say "we're using kube deployed Gitlab ci runners" - if you have any tips or require additional info, please let me know 🙂

elfin blade
#

@dire veldt @neat flax Dagger won't work without privileged containers, because dind doesn't work without privileged containers. That said, there is rootless buildkit https://github.com/moby/buildkit/blob/master/docs/rootless.md.

@dire veldt I'm not too familiar with the low-level interaction with buildkit, but would it be feasible to run buildkit directly rather than DIND?

dire veldt
harsh vault
#

We have an issue for supporting rootless mode here: https://github.com/dagger/dagger/issues/1287

Rootless containers in general are full of nuances and tradeoffs (described some previously here: https://github.com/dagger/dagger/pull/2978#issuecomment-1234794009) so it's unfortunately not possible to just enable it by default and have it work for everyone.

As of right now, the only path to running rootlessly would require customization of our base engine image, which right now is in the category of "not officially supported but we can't stop you from doing it", though we are figuring out our next steps on that front here: https://github.com/dagger/dagger/issues/4105

harsh vault
# elfin blade <@274903880343748619> <@679038495523602469> Dagger won't work without privileged...

I'm not too familiar with the low-level interaction with buildkit, but would it be feasible to run buildkit directly rather than DIND?
It's certainly technically possible but will currently again full under the category of "not officially supported but we can't stop you from doing it". One hard part is that we package our engine as an image because it's more than just buildkit; it also includes other dependent binaries like runc, a dagger shim, qemu emulators, etc. So it's not just a matter of running a single binary outside a container. The other thing to keep in mind is that this mode would still require either privilege (buildkitd needs it) or running rootlessly (with the same caveats)

neat flax
#

interesting, thanks 🙂

neat flax
#

I'm going to run a CI runner locally for my live-demo later 😉 😓

elfin blade
#

On that I'll maybe add that it's all about risk management - we run a dedicated cluster for CI, so the risks of privileged containers are fairly low; anything happening is contained to our CI runners. Personally I don't think running as privileged is a big deal for this but ymmv (or your sec team's mileage)

neat flax
elfin blade
#

Do you run or intend to run on AWS Fargate? (Not sure you're even on AWS). We discussed that, and Fargate doesn't support privileged containers, which is why we started looking at Kaniko initially

#

One thing to note is that you can also run a dagger host remotely, and set the DAGGER_HOST env (though this is being deprecated in favour of better alternatives last I heard). So one option could be to have your runners as now, and use a remote dagger host. That avoids DIND entirely

neat flax
elfin blade
#

In this case what I was talking about was to run a separate node that just runs dagger, then have your gitlab CI run just the dagger client

neat flax
#

Yes, that node being a node running in Kube, rather than DIND running Docker which is used to run Dagger.

elfin blade
#

It couldn’t run in Kube. The Dagger server needs access to buildkit, and running buildkit is, to my understanding, what requires privileged

#

It might be possible to run within k8s, but I haven’t given it much thought – I think e.g @vale wedge would know better on the limitations of that

#

but the TLDR is that the dagger agent needs access to a DOCKER_HOST, which needs to run somewhere. You also have the option of running just docker on a remote host, and changing the docker host

neat flax
#

Ok, so we could run one or more fat Dagger hosts provisioned with Terraform or similar, provided one can load balance them, that should work.

elfin blade
#

that might work

#

This is getting into territory I have no idea about so I’ll defer to the people actually working on Dagger for it 😄 but yeah that was my understanding about remote hosts

neat flax
#

hehe 🙂

#

it's even newer to me mate 😉

elfin blade
#

I’ve only been here a week 😂

#

Or two? I lost track of time

#

maybe 2 weeks but yeah, you run into a lot of interesting edge cases when running CI runners in kubernetes and making it work with Dagger 😄

neat flax
#

@elfin blade hi - coming back to this after the w/e, occurs to me that perhaps I could have run Dagger as a CI service 🤔