Docker image

[gabrielcossette]

When someone has some time, a Docker image would be awesome :)

[rudyryk]

In the meantime, I've found this: https://github.com/buildsociety/nebula

[johnmaguire]

Hi there! I see there's a lot of votes on this issue. I'd appreciate if those interested could give some examples of their intended use cases. For example, I can see at least a few ways you might want this to behave:

1. A Docker base image that includes Nebula, but which can be extended to add additional programs on top of it.
2. A Docker image that runs Nebula only after being provided with a config of some sort (perhaps environment variables, or perhaps a raw config file.) This would require adding capabilities like NET_ADMIN to the container so that it can create the interface and routes.
3. A Docker image that runs Nebula only after being provided with a config of some sort, but that exposes the Nebula network for other containers, as opposed to (2) which exposes the Nebula network to the host.

Thanks in advance!

[stavros-k]

Let me start by saying this: I haven't deployed nebula yet, just started looking into it. So I might have gotten the "how it works" wrong. But bear with me.

I'd be interesting in a container for lighthouse at least initially. So I can deploy that on an existing VM running other services. I don't want to put those services behind nebula, Nebula will be just another public service running there.

With nebula deployed there, I can point all nebula "agents" (or how they are called) to the public lighthouse. Nebula network will be used to connect from one "agent" to another. I guess in this scenario it doesn't matter if lighthouse have access to host network or not.

As for configuration, I've seen a fair share of Go Projects that use viper. Which you can mix and match values from flags, variables and values from config file(s). Usually the weight goes like this: Flags, Env Vars, Config File. With Flags having the most "power" and config file the least.

Later you can investigate introducing a container for "agent". This will usually run along other containers (either docker, docker-swarm or kubernetes). And will need access to the container network(s) In kubernetes you can also run the agent as a "sidecar" to some other container(s) in the same pod.

Giving you the flexibility to have an "agent" per pod.

Hope that gives some info that you can use!

[wynemo]

sudo docker run -d --restart always --name nebula --net host --cap-add=NET_ADMIN --cap-add=SYS_ADMIN --device=/dev/net/tun -v $PWD:/app -w /app debian:buster-slim ./nebula -config ./nebula.config.yml, just run in buster-slim

[tmjpugh]

Hi there! I see there's a lot of votes on this issue. I'd appreciate if those interested could give some examples of their intended use cases. For example, I can see at least a few ways you might want this to behave:

1. A Docker base image that includes Nebula, but which can be extended to add additional programs on top of it.
2. A Docker image that runs Nebula only after being provided with a config of some sort (perhaps environment variables, or perhaps a raw config file.) This would require adding capabilities like NET_ADMIN to the container so that it can create the interface and routes.
3. A Docker image that runs Nebula only after being provided with a config of some sort, but that exposes the Nebula network for other containers, as opposed to (2) which exposes the Nebula network to the host.

Thanks in advance!

Definitely #3 I am looking to move away from reverse proxy and exposed ports for services and want ability to use nebula to allow connection to containers