use go 1.13, replace glide with modules, add boilerplate docker_build

[jstewmon]

• removed bootstrap make target, since it was only needed to install
  glide and run glide install
• updated Dockerfile stages to optimize dependency caching
• update docker-compose to use the base stage of Dockerfile for
  consistency

fixes #57: Per the conversation there, maintainers can provide lyft credentials for docker.io registry if this is accepted.

duplicates #101

I realize this PR could be controversial, so I welcome all feedback...

I took the liberty of replacing glide with go modules because it simplified the setup. For example, docker-compose no longer depends on the user running glide install on their host machine; GOPATH is no longer required, etc.

The go.mod and go.sum files should be reproducible by running: go mod init github.com/lyft/ratelimit && go mod tidy

I tried to anticipate the desired direction implied by the boilerplate project.

[jstewmon]

@lyft/network-team this is ready for review 🤞

[jstewmon]

@junr03 @rodaine 👋 , sorry to nag, but it looks like the @lyft/network-team tag from the contributing guidelines is inactive, and I would love to get your feedback on this!

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[jstewmon]

Ping to ward off stale bot

[junr03]

I am in favor of moving the project to go modules, and publishing to dockerhub. I think both are very good for the project. Thanks for taking this on @jstewmon!

A couple questions for other folks:

1. @rodaine is there any issue with the project moving to go modules even though internally Lyft is still using glide?
2. @jonathanburns could you take a look at the boilerplate setup?
3. @mattklein123 @wgallagher if we ultimately want to move the project to the envoyproxy org, do you have a preference if we merge the dockerhub publishing part of this PR before or after the move? I assume that after the move we would push to envoyproxy's dockerhub.

[junr03]

why downgrade?

[jstewmon]

I switched the the latest v2 release, so that I could make the ratelimit service depend on the redis service being healthy.

docker-compose removed support for depends_on conditions in v3 because it does not work with swarm mode.

Their current recommendation is to use v3 and have the application container await the upstream service dependency, which is more troublesome to implement.

Since we do not need swarm mode, I thought using v2 was the easier way to get the desired behavior.

[jstewmon]

Here's a reference: docker/compose#4305 (comment)

[mattklein123]

I assume that after the move we would push to envoyproxy's dockerhub.

I would do it after the move, though it will take a bit of time to get that sorted out.

[jonathanburns]

Boilerplate looks good.

[rodaine]

is there any issue with the project moving to go modules even though internally Lyft is still using glide?

Not really, but you may need to finagle some stuff to get it to build properly.

[jstewmon]

Thanks everyone for the reviews!

If the desire is to move the project to the envoyproxy org before pushing to docker hub...

1. Is there anything I can do to help with that? e.g. Submit a PR that replace 'lyft/ratelimit' with 'envoyproxy/ratelimit'

If the move will take some time, I can split this PR into separate patches for the transition to Go Modules and the boilerplate for building and publishing the docker image. That would allow us to merge the former now, which would in turn make it easier for users to build the project while awaiting a published image.

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[jstewmon]

shoo stale bot

[junr03]

Hi @jstewmon, sorry for the delay Kubecon/Envoycon and thanksgiving got in the middle.

Do you mind splitting the PR into everything except pushing to dockerhub. And we can do the dockerhub change once we move the repo over? Thanks!

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[stale]

This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[jacobstr]

Started going down a similar path when I tried I approached the project to get a local build going. I no longer have a GOPATH configured in my go dev environment (thank you modules!).

Seems worthy to drive this guy across the finish line.

[jstewmon]

Hi 👋, sorry for the long delay - I got very busy at work for a while... I ran into some trouble splitting this up as it relates to the desire to move the project from lyft to envoyproxy because the boilerplate docker setup assumes lyft is the docker user.

@junr03 or @jonathanburns do you have any guidance on how you'd like to proceed? I can setup a bespoke docker build for this repo if there is not a clear path forward using boilerplate to publish for the envoyproxy project.