Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Define containers as RunOptions? #1337

Open
drodriguezhdez opened this issue Jan 21, 2020 · 3 comments
Open

[Proposal] Define containers as RunOptions? #1337

drodriguezhdez opened this issue Jan 21, 2020 · 3 comments

Comments

@drodriguezhdez
Copy link

drodriguezhdez commented Jan 21, 2020

Hi,

Working on a PoC of a custom Buildkit frontend to execute tests of a certain git repo, we'd like to validate with you guys the idea of using containers as support of a certain llb.State in the Buildkit DAG.

The use case would be, in this case, to run integration tests which need certain containers which run in the same network namespace and, which lifecycle, is bounded to a certain llb.State. (e.g. a database)

A theoretically example could be this:

var runTestsOpts []llb.RunOption
runTestsOpts = append(runTestsOpts, llb.Shlex("<execute integration test command>"))
runTestsOpts = append(runTestsOpts, llb.WithService("mysql:latest"))

build := llb.Image(<some base image>).
      Run(runTestsOpts...).
      Root()

In this example, we're using the hypothetical new llb.RunOption named llb.WithService("..."), which Buildkit needs to handle before/after the ExecState of run tests was executed.

Ideally, Buildkit is using executors to start/stop containers now, so the idea would be iterate this logic to include somehow this new capability.

So, our questions would be:

  • What would you think conceptually about this idea inside of Buildkit?
  • Would it be in the scope of Buildkit for you?
  • Would there be another approach to do the same based on your knowledge of the tool?

Thank you very much!

@drodriguezhdez
Copy link
Author

/cc @fermayo @tonyredondo

@tonistiigi
Copy link
Member

Yes, I think this is in BuildKit scope. I call this a network dependency. For caching/dag this is a dependency like any other but it runs in a separate container and exposes name/ip (or tcp port/unix socket if we want to keep this simpler) to another process for discovery. The executor can also do simple socket activation for lazy loading and containers do not need to run in the same machine.

I don't think there is a need for magical WithService. Every container should be defined by LLB. We do need some syntax to mark how the ip or port is exposed. And in executor level we need to define requirements for basic network capabilities that executor needs to support.

like this?

c := llb.Image("alpine").Run(llb.Shlex("cmd"))
c.Expose(llb.Image("redis").Run(llb.Shlex("init-db-pre-start")), llb.PortMapping(6379, 6379))

@drodriguezhdez
Copy link
Author

drodriguezhdez commented Jan 23, 2020

Thanks for your quick feedback!

Nice to hear that. We're going to start working in a POC in a Buildkit fork based on your API proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants