canonical / lxd-demo-server

The LXD demo server
https://linuxcontainers.org/lxd/try-it
Apache License 2.0
74 stars 26 forks source link

Exposing container port #22

Closed JonasVautherin closed 4 years ago

JonasVautherin commented 4 years ago

If I understand correctly, the way this works is that there is a go server that has access to the LXD daemon and can therefore spawn containers. It exposes the console output of a container through /1.0/console, and if server_console_only is false, it exposes an ssh server.

Also, it seems like there is an id (which is really a random string) required to access a container. So if I know the id of all the containers, I can basically access them remotely. Which is considered good enough for this use-case.

Assuming that this is not completely wrong, there is a thing I don't get: how does the SSH thing work (server_console_only=false)? How does the remote client connect to it? Wouldn't there be a need for a reverse proxy somewhere, translating :22 to :?

I'm interested in that because I would like to try exposing a port for my demo. So that users could have a remote terminal into my container, and at the same time they could connect a separate RPC client to that same container.

It seems that with lxd, I should be able to expose a port with something like:

lxc config device add c1 proxy0 listen=tcp:127.0.0.1:80 connect=tcp:127.0.0.1:8080

So I'm trying to figure out the reverse proxy issue (mentioned above) and also how rest.go would need to be modified in order to run the proxy config line above when creating a container.

stgraber commented 4 years ago

Nope, we just assume that the containers are publicly routable. This is usually only possible over IPv6 unless you have a rather sizable IPv4 allocation.

In theory the proxy device could be used for this, but you'd indeed have to deal with a pool of host ports and possibly also deal with multiple host addresses.

In our production environment, the host itself isn't accessible anyway so proxying wasn't really useful to us, instead we just routed a public IPv6 subnet so the containers may be directly accessed by those who have IPv6 connectivity.

JonasVautherin commented 4 years ago

I am not super familiar with IPv6. So you mean that returning the IPv6 address is enough because the host machine allows "direct routing"? But then the container still needs to expose port 22, doesn't it? I don't see where that is done :confused:.

stgraber commented 4 years ago

LXD doesn't use port 22, all connections are done over the REST API.