Docker engine context switch (and contribution)

Waypoint
#1

Hi, really glad to have waypoint in our lives, but there is something that we’ve somewhat met as a roadblock in adopting waypoint.

We initial believe the use of waypoint context for example with docker, allowed us to register waypoint servers with different docker engines hosted on remote servers, so that when we switch context and deployment is made, then that deployment is both either:

  1. Built locally then copied for deployment to the remote docker
  2. The data are sent to the remote engine, built, and deployed.

But when tested, the UI on the remote server did display the build process which was executed through the waypoint CLI, but with a surprise we find ourselves seeing the container deployed locally to our local docker engine.

Which was in its self a surprise, so I guess the questions are:

  1. Did we misunderstand contexts?
  2. Is the docker plugin coming with waypoint not able to deploy to the remote docker engine?
  3. Is there a way to achieve this? (Do we need to thinker around with docker environments variables?)

While researching, I found the following github PR ticket Docker Remote Engine by nicholasjackson · Pull Request #631 · hashicorp/waypoint · GitHub, but we don’t want to hardcode remote docker credentials into the waypoint file, it just makes it one off and brittle.

Would appreciate any insight possible.

Aside:

On the contribution end, I find myself stuck trying to setup the nix packages as the golang 1.15 (roughly believe) fails to pass the test process after building, making it impossible for me to get running, and trying just normal go mod tidy leaves with a few import errors on the project, are there any clear ways to bypass the golang build failure due to failing tests?

Could I suggest the execution of the golang building without execution of tests if possible.

I would very much like to contribute and any help to get running with the project dev side would be appreciated.

#2

Would truly appreciate any insight you may have! @mitchellh

#3

Possibly. Waypoint contexts are a way for the Waypoint CLI to target different Waypoint servers. They have no impact on the behavior of deployments whatsoever, which are only defined by the waypoint.hcl file.

I believe it does, but it has some limitations… I’m not sure what those are at the moment.

Yes, if you find anything out please report an issue that’d be very helpful.

If you aren’t familiar with nix you don’t need to use it (only a couple devs on the team do). But otherwise everything should be fairly standard Go. We recently updated the contribution/development guide so maybe that can help?

#4

Thank you so much for taking the time.

I see, so the context simply indicates which waypoint server to handle the process of building alone and not deployment?

I see, would it be safe to write a possible PR that allows retrieval of the remote docker host from the deployed waypoint server and use that for deployment instead of depending on environment variables?

Thank you, I will.

Once again, appreciate the reply.

#5

This is an interesting idea!

I think the idea of default configuration for different plugins stored on the server is interesting. I’m not sure how we’d like to see the implementation of this but this is a pretty good idea. i’ll discuss with the team.

1 Like
#6

Thank you. I think this was how we envision context would affect deployment or atleast allow to select the target deployment, so that in general we can have multiple deployed servers (for example to different docker engines on different servers).

This then allows seamless deployment to this different hosts just based on the selected context.