Re: Port forwarding for Guix containers

[Jason Conroy]

Hi Edouard, I completely agree that this sort of composition is convenient
for a group of services that share a single dependency graph. For example,
when deploying a web application in a container, one could also provide an
nginx server there for its exclusive use, and maybe even a database server
(if the db doesn't have other clients).

But when it comes to deploying separate, unrelated applications (or
isolated instances of an app, like Production and Testing), I believe that
development, testing, and maintenance are all simplified by keeping the
containers separate. For example, after a `guix pull` with a major package
update, I might want to rebuild a single application container and test the
new package there. The alternative is to bring down all applications,
upgrade them all, test them all, and roll back everything if there's at
least one issue. When there are many applications, this doesn't scale well.

I guess I see `guix system container` as analogous to `guix environment` in
this regard: a single environment may contain many binaries that work
together, but users are encouraged to set up different environments for
Project A and Project B.

I'm not sure whether Zihao's situation is similar, but that's my
perspective. :)

Jason


On Sun, Nov 22, 2020 at 10:10 AM <edk@beaver-labs.com> wrote:

>
> The trick is that guix being written in scheme, operating system
> declarations can be written in a composable way, where the port N can be
> a parameter.
>
> The way I see it, it is when you compose all your services together on
> one host that you decide which service gets which port, and declare all
> that in a single operating system declaration (which is made up of
> modular, task specific, smaller OS declarations).
>
> I don't know if I'm being clear. I can't provide code because I did not
> have the time to do it yet, but this was my understanding of how guix
> works.
>
> Jason Conroy writes:
>
> > I agree with Zihao that containers have certain use cases where it's
> > important to use separate network namespaces for each instance, with
> > traffic forwarded selectively between host and guest. Security (and hence
> > firewalling) is part of the issue, but it's also about the container's
> > maintainability and reproducibility.
> >
> > Supposing that we've developed some system container that starts a
> service
> > on port N. If we want to run another instance of the same container, we
> > first need to override the port number for the service in our
> > operating-system, otherwise the service in the second container will fail
> > to bind to port N in the shared network namespace. With a couple of
> > one-service containers this may not be so hard, but system containers in
> > general could have lots of services, and the authors of individual
> > containers may not want to worry about choosing port numbers that are
> > mutually disjoint from those in all other containers (and those used by
> the
> > container host itself).
> >
> > Aside from the risk that one container's port bindings will prevent
> another
> > container from working, there's also the risk of unintended dependencies:
> > we might start a container thinking that it's self-contained, when really
> > it depends on a service belonging to the container's host or to another
> > container. This is why I consider the shared namespace a reproducibility
> > problem.
> >
> > Lately I've been experimenting with a modified version of this script
> > <
> https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99#file-ns-inet-sh
> >
> > to set up a network namespace with its own interface and routes, and then
> > run a guix system container inside. Because the container is built with
> the
> > -N flag, its services will bind to the virtual interface inside the
> network
> > namespace. Processes inside the container can access the internet, while
> > processes on the host (but outside the container) can access the
> container
> > services via the IP address bound to the container's interface.
> >
> > Next, to make the container's services accessible to other hosts, there
> are
> > a couple of options. One is to enable port forwarding from the host's
> > external interface to the container's IP address using iptables
> > <https://www.systutorials.com/port-forwarding-using-iptables/>. If the
> > container is hosting a web service, another choice (as Edouard mentions)
> is
> > for the host to run some sort of reverse proxy that forwards incoming
> > requests to the container's port. For example, nginx and Apache can both
> do
> > this.
> >
> > It would be really nice if guix system containers had this namespacing
> > ability built in, but it sounds complex.
> >
> > On Sat, Nov 21, 2020 at 10:03 AM zimoun <zimon.toutoune@gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> On Fri, 20 Nov 2020 at 19:26, Christopher Baines <mail@cbaines.net>
> wrote:
> >> > Zhu Zihao <all_but_last@163.com> writes:
> >> >
> >> >> I found guix container "created by `guix environment --container` or
> >> >> `guix system container`" is very useful to isolate some service. But
> >> >> it only supports fully isolated network namespace or just share with
> >> >> host, it's not so safe IMO.
> >> >
> >> > I'll assume that a fully isolated network namespace is safer in
> whatever
> >> > way you're referring to than a shared network namespace. However, for
> a
> >> > shared network namespace, what threats is that not safe in respect to?
> >> >
> >> > In the shared network namespace scenario, you are free to use a
> >> > firewall, which could help protect against threats coming from other
> >> > machines, for example by creating a list of IP addresses which are
> >> > allowed to connect, and dropping any other traffic.
> >>
> >> I do not know about the initial motivation and I do not know either if
> >> it makes sense in the context of “guix environment”.  One point is that
> >> Docker [1] provides a way to specify the firewall rules.  Well, somehow,
> >> something similar as ’--share’ but for network.
> >>
> >>
> >> 1: <https://docs.docker.com/config/containers/container-networking/>
> >>
> >> All the best,
> >> simon
> >>
> >>
>
>
>