On: Evolution of code deployment tools at Mixpanel

[gravypod]

Have you considered using Bazel to build an artifact that describes your deployment configuration? This is something that I've been thinking about trying to implement for some time. Essentially I want to have a way to support defining service configurations like this:

    service_binary(
      name = "foobar",
      srcs = ["foobar.jsonnet"],
      deps = ["//jsonnet/service.jsonnet"],
      images = ["//a:image"],
    )

Then make it possible to create a class of `*_test` rules that would start up a bunch of docker containers in the same network topology they would exist in prod, run your test in the same netns, then clean everything up. It could look something like this:

    cc_integration_test(
      name = "...",
      services = ["//a", "//b"],
      srcs = ["main.cc"]
    )

There's some BazelCon talks about people doing similar stuff but not actually open sourcing their code.

P.S. if you use rules_docker please feel free to open a PR to add your company to our README: https://github.com/bazelbuild/rules_docker/#adopters

> service_binary

[Vendan → gravypod]

We've looked at it, but we have services that aren't using rules_docker to build their images, so for now at least, we'd rather have everything use as similar of a deployment process as possible.

(and we are using rules_docker, and love it! Added a pr, gotta look into the CLA stuff (would like to do it from employer side, but that will have to wait until monday at least))

[sa46 → gravypod]

With something like service_binary, how do you wire up services? For example, If main.cc depended on Redis, how would you get the host and port of the Redis dependency from main.cc?

[gravypod → sa46]

You can do some amazing things based on convention. In kube it's pretty common to use Services for service discovery. Essentially all a Service is is a smart DNS name that points to a collection of pods (netns). If you want to mirror that setup you can create a virtual bridge network setup the same docker-compose does which would let you have a container with a hostname of `database` and then `ping database` would resolve to the correct container. To match kube's conventions you could do this: https://kubernetes.io/docs/concepts/services-networking/serv...

Another thing you could do is generate environment variables similar to what kube does: https://kubernetes.io/docs/concepts/services-networking/serv...