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

Use different IP addresses for the out-of-the-box "virtualbox" variants #86

Merged
merged 1 commit into from
Jun 22, 2022

Conversation

amotl
Copy link
Contributor

@amotl amotl commented Jun 10, 2022

Dear Stefan,

coming from pyveci/racker#4, we are aiming to run the "out-of-the-box" boxes 2016-box, 2019-box and 2022-box in parallel without getting any conflicts between them.

Problem

Currently, when first using the 2016-box and then switching to the 2019-box, which has been provisioned beforehand already, it croaks because the association with respect to the appropriate Docker context vs. generated TLS certificates goes south.

We have been able to produce different flavors of the same broken situation, here are two examples how this turns out in practice:

$ docker --context=2019-box ps
error during connect: Get "https://192.168.59.90:2376/v1.24/containers/json": x509: certificate is valid for 169.254.232.221, 172.30.112.1, 10.0.2.15, 127.0.0.1, not 192.168.59.90

$ docker --context=2019-box ps
error during connect: Get "https://192.168.59.90:2376/v1.24/containers/json": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Docker TLS Root")

Workaround

A workaround-like solution is to manually remove the Docker context (docker context remove 2019-box) and run the box provisioning again (vagrant provision 2019-box). With both invocations, the TLS certificates will get re-generated and the corresponding Docker context will get re-established correctly.

Solution

The workaround outlined above quickly becomes tedious when aiming to switch back and forth between boxes or even impossible when aiming to run them in parallel.

So, with this patch, each of the "virtualbox"-type VM definitions gets a different IP address which makes the problem go away completely.

$ docker context list
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT
2016-box            moby                2016-box windows-docker-machine           tcp://192.168.59.50:2376
2019-box            moby                2019-box windows-docker-machine           tcp://192.168.59.51:2376
2022-box            moby                2022-box windows-docker-machine           tcp://192.168.59.52:2376

If you think the patch should be adjusted in any way, we are happy to receive any kind of guidance. Specifically, we didn't check how the patch would behave on other Vagrant provider backends than VirtualBox.

With kind regards,
Andreas.

It will make it possible to run all the corresponding boxes in parallel
without getting any conflicts.

- 2016-box: 192.168.59.50
- 2019-box: 192.168.59.51
- 2022-box: 192.168.59.52
@@ -96,7 +105,6 @@ Vagrant.configure("2") do |config|
v.customize ["modifyvm", :id, "--nested-hw-virt", "on"]
# Use the recommended paravirtualization interface for windows (hyperv) - requires VirtualBox 6
v.customize ["modifyvm", :id, "--paravirtprovider", "hyperv"]
override.vm.network :private_network, ip: "192.168.59.90", gateway: "192.168.56.1"
Copy link
Contributor Author

@amotl amotl Jun 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We removed this line over here, because we didn't take the time to validate override order yet, i.e. how the code would behave when it would have been left in place. Do you think our amendments re. "per-box-IP" would still take precedence?

However, it might introduce a regression because all the NON-"out-of-the-box" boxes will now be invoked without this configuration setting.

Please let us know if this detail should be addressed in one way or another beforehand. We see three options:

  • Check/verify override order. If the individual assignments take precedence, then this line can be left in place.
  • Explicitly assign IP addresses to all of the other machines as well.
  • Investigate if there is another, more advanced way of configuring the IP address assignment automatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is GH-89 possibly related?

/cc @gabyx

Copy link
Owner

@StefanScherer StefanScherer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good for now. Let's merge it. The different IP addresses make sense.

@StefanScherer StefanScherer merged commit da55180 into StefanScherer:main Jun 22, 2022
@amotl
Copy link
Contributor Author

amotl commented Jun 29, 2022

Thank you very much!

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

Successfully merging this pull request may close these issues.

2 participants