Opened 4 years ago

Last modified 20 months ago

#2956 accepted enhancement

Provide latent Docker build slave

Reported by: sa2ajj Owned by: sa2ajj
Priority: patches-accepted Milestone: 0.9.+
Version: master Keywords: docker, slave, latent
Cc:

Description

There's a number of options already implemented:

(There's one more that I can't find atm)

Change History (17)

comment:1 Changed 4 years ago by Ben

I'm slowly wrapping my head around that concept, was wondering what advantage it would bring, or how could we integrate Docker as a slave or such ... What would help me most would be a blog post to lay down some basis I guess, then, once I got a clear idea of the possible links between Docker and Buildbot, I could try to think about binding them as a Latent slave ...

In that direction, the drone project (drone.io) is based around Docker slave, they provide some base image, and you just tell in your config which one you wanna use ... Something like that ?

Last edited 4 years ago by sa2ajj (previous) (diff)

comment:2 Changed 4 years ago by sa2ajj

Latent build slaves have a special feature: reproducible environment, which is a parameter:

The "normal" build slaves would have to create such an environment (e.g. Buildbot's builder configuration).

I agree though that either a blog post or an addition to the documentation would be helpful for more people to start using this kind of build slaves.

comment:3 Changed 4 years ago by Ben

So you mean something like taking that class into core buildbot: https://github.com/elbaschid/dockbot/blob/make_single_command_executable/dockbot/slaves/dockerslave.py, or do you mean something more there ? (i.e. being able to install the minimal slave stuff into any base image ?)

comment:4 Changed 4 years ago by sa2ajj

Yes, I am talking about taking that particular class (with amendments since it seems to do a bit too much with respect to parameters) and adding a test case.

comment:5 Changed 4 years ago by Ben

Looking forward to it !

I'm struggeling with nine for the moment, but as I have it working, I could have a look at that !

comment:6 follow-up: Changed 4 years ago by Ben

I started looking onto it, unfortunately, I hit a few blockers with master (#2970).

A question I had is about the completness of the docker image. Should we try to create-slave + start at each substiantiation ? Or should the image have a pre-created slave and it should only be started during substantiation ?.

In other words: Should the docker image be buildbot-aware, or should any (well, with limitations) docker image be made buildbot-aware ?

comment:7 in reply to: ↑ 6 Changed 4 years ago by sa2ajj

Replying to Ben:

I started looking onto it, unfortunately, I hit a few blockers with master (#2970).

Let's see how it's resolved.

A question I had is about the completness of the docker image. Should we try to create-slave + start at each substiantiation ? Or should the image have a pre-created slave and it should only be started during substantiation ?.

I think the best is make all latent build slaves behave in a similar way; this means that it's a responsibility of the user to create an image with build slave in it as well as to provide a way for the build slave to authenticate against master:

  • some latent build slaves have this information "hardcoded", that's it: one image can only provide one build slave
  • majority of images I saw use environment variables or a bootstrap script to configure the authentication

In other words: Should the docker image be buildbot-aware, or should any (well, with limitations) docker image be made buildbot-aware ?

I think, the former: that's in line with, for example, AWS images.

comment:8 Changed 4 years ago by Ben

Been working on that over the weekend. With nice results !

1 trouble: We need to hardcode the master hostname, the slave name and password in the Dockerfile. For the master name, it would be good to use the --add-hosts cli parameter, unfortunately I found no way to give it through the docker API :( probably worth a bug by docker. Or the doc I found is not up-to-date.

I also would love to add the possibility to build a container if the requested one is not found. Probably through giving a Dockerfile as parameter to the slave. This would allow us to require no preliminary setup on the docker side.

I still need to write the doc, add some tests, and we're ready to go !

comment:9 Changed 4 years ago by Ben

  • Owner set to Ben
  • Status changed from new to assigned

comment:10 Changed 4 years ago by sa2ajj

I do not think we need to hardcode anything.

A common Docker approach is to pass parameters via environment variables. In case of latent Docker slave, we'd have to pass 4 parameters (names are examples):

  • BUILDBOT_MASTER_HOST
  • BUILDBOT_MASTER_PORT
  • BUILDBOT_SLAVE_NAME
  • BUILDBOT_SLAVE_PASSWORD

and modify buildbot.tac to use these parameters when they are present.

comment:11 Changed 4 years ago by sa2ajj

And, by the way, this modification can go to master: buildslave create-slave can put the provided values so that they are used as defaults, while the abovementioned environment variables would override these defaults.

comment:12 Changed 4 years ago by Ben

See GH:1344.

Last edited 4 years ago by sa2ajj (previous) (diff)

comment:13 Changed 4 years ago by sa2ajj

As agreed, environment variables is going to be in a separate PR.

comment:14 Changed 4 years ago by Ben

Can this now be closed ?

comment:15 Changed 4 years ago by sa2ajj

  • Owner changed from Ben to sa2ajj
  • Status changed from assigned to accepted

See above my comment about environment variables. I have a branch, I just need to polish it and submit, then this can be closed when the change is merged.

comment:16 Changed 4 years ago by sa2ajj

But first I want to take care of #2851.

Note: See TracTickets for help on using tickets.