Fix the nested-spire example in macOS #141
Open
+50
−25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Various small changes to make the nested-spire example work on a macOS host running Docker for Mac. --- On my system, the first run of scripts/set-env.sh yields: ``` 2025-03-13T02:46:39Z] bootstrapping root-agent. Error: connection error: desc = "transport: error while dialing: dial unix /tmp/spire-server/private/api.sock: connect: no such file or directory" ``` The naive thing to do is to merely re-run the script. If you re-run set-env.sh after the above failure, new certs are generated but the server appears to continue running and using the old ca. So lets just make it work the first time by waiting for the server. The other issues relate to Docker for Mac and it's hackish socket handling. The /var/run/docker.sock is apparently special cased somehow so we specify that single file in the volume mounts rather than the entire /var/run folder. --- The other error I saw had to do with sharing that `sharedSocket` folder: ``` "Agent crashed" error="unable to change UDS permissions: chmod /opt/spire/sockets/workload_api.sock: invalid argument" ``` This originates here https://github.com/spiffe/spire/blob/v1.5.1/pkg/agent/endpoints/endpoints_posix.go#L32 Again, docker for mac "breaks" sockets created in this shared volume when it's on the host filesystem because in practice it's some rube-goldberg contraption with a lightweight VM under the hood. So we just create a container-scoped volume instead, and bypass the macOS host filesystem entirely. This might make it a bit funky to interact with spire binaries running on our host - perhaps, but we could always just add some bastion container to the docker-compose.yml file if we want some tooling container for experimentation. Signed-off-by: Jacob Straszynski <[email protected]>
Signed-off-by: Jacob Straszynski <[email protected]>
Signed-off-by: Jacob Straszynski <[email protected]>
|
👍 for the PR. I've struggled quite a bit to run the sample from
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Various small changes to make the nested-spire example work on a macOS host running Docker for Mac.
On my system, the first run of scripts/set-env.sh yields:
The naive thing to do is to merely re-run the script.
If you re-run set-env.sh after the above failure, new certs are generated but
the server appears to continue running and using the old ca. So lets
just make it work the first time by waiting for the server.
The other issues relate to Docker for Mac and it's hackish socket
handling. The /var/run/docker.sock is apparently special cased somehow
so we specify that single file in the volume mounts rather than the entire
/var/run folder.
The other error I saw had to do with sharing that
sharedSocketfolder:This originates here https://github.com/spiffe/spire/blob/v1.5.1/pkg/agent/endpoints/endpoints_posix.go#L32
Again, docker for mac "breaks" sockets created in this shared
volume when it's on the host filesystem because in practice it's some
rube-goldberg contraption with a lightweight VM under the hood.
So we just create a container-scoped volume instead, and bypass the
macOS host filesystem entirely. This might make it a bit funky to
interact with spire binaries running on our host - perhaps, but we could
always just add some bastion container to the docker-compose.yml file if
we want some tooling container for experimentation.