service discovery initial code

[nadilas]

in a second step, I'll make an interface out of the current registry implementation.

[arbarlow]

Continuing the discussion here from the issue!

I don't think we need a new registry repo, we can add the interface to this main repo and then much like how the google package works in pubsub there can be a subpackage that implements that interface that can be brought in an used?

It would be awesome then to generate the apps with a users preferences and it mostly be code stuff.

What do you think?

[nadilas]

I understand what you mean. I hid consul behind the interface, I still need to wrap some consul specific structs (api.AgentServiceCheck, QueryOptions, ServiceEntry, QueryMeta) to fully abstract it away, but it looks good.

Take a look.

[arbarlow]

Hey @nadilas, nice.

Can we move the models stuff just into the lile package, we've had trouble with types only packages before and I like having them as top level citizens.

Can you run gofmt too? 😄

All in all, good stuff. I think I'll pull this in to a new version branch and do some things I've been wanted to do for a while that will allow more customisation generally.

[nadilas]

@arbarlow no problem.

I also like models to be first level, so they live now in the project root. :)

I did! 😆 Although I'm not sure how Goland handles that. I ran it on the whole project 👍 Obviously it's not even close being finished, I'll have more time in a couple weeks, but feel free to dive in.

[arbarlow]

Hi @nadilas, I haven't heard anything for a while but I'm going to close this PR as we have lile v2 and that has Registry now, which is just await some implementations.

If you're keen for Consul I'd be happy to take a PR 😄

[nadilas]

Hi @arbarlow, sorry about that. I was trying to reach you on the linkerd.io Slack. 😆 Didn't work...

I had quite a sprint using lile for a project I had in April and May. I had to figure out how to go about service discovery and went with a slightly different setup, but still using lile. I ended up using Nomad for scheduling and Consul (from within Nomad) for service discovery. Also I needed to a SPA as the UI for the user facing part of the application where I had to integrate grpc-web into lile. I will be reviewing lile v2 and my changes to see, how they go together.

On top of that I'm now implementing linkerd.io, where I found your issue http://github.com/linkerd/linkerd/issues/1301 and would appreciate your input on that.

It's live now, but once I have linkerd implemented, I will have to reiterate, but the final stack will probably end up like: lile-services, grpc-web, mist, consul, nomad, linkerd.

Sorry for going MIA 😄

[arbarlow]

Hi @nadilas, no worries!

I'm glad you're using lile.

We have a similar setup with an SPA, grpc-web and others. But we just use Kubernetes DNS for service discovery.

I've added linkerd support in the latest release of lile actually, https://github.com/lileio/lile/blob/master/lile.go#L145

You can now point your apps as accounts:80 and set SERVICE_HOST_OVERRIDE to your linkerd instance and then you can set your dtab as needed. Also, by passing the header around, you can do deep service re-routing!

[arbarlow]

We publish our typescript repos to a private NPM which allows us to just import those in our front end repos, we have something like this in our makefile

proto:
    @go get github.com/golang/protobuf/protoc-gen-go
    @npm install -g ts-protoc-gen
    @mkdir -p clients/js
    @protoc -I . accounts.proto --lile-server_out=. \
      --js_out=import_style=commonjs,binary:clients/js \
      --go_out=plugins=grpc:$$GOPATH/src \
      --ts_out=service=true:clients/js