How to expose more than one port on a pod

[Mark Petrovic]

Vitals:

rkt Version: 1.27.0

appc Version: 0.8.10

Go Version: go1.7.4

Go OS/Arch: linux/amd64

Features: -TPM +SDJOURNAL

I am trying to expose more than one port on a pod, like so

# systemd-run --unit redis --slice redis rkt --insecure-options=image run --dns=host --port=6380-tcp:6380 --port=26380-tcp:26380  \

        docker://docker-registry.example.com/infeng/redis-sentinel-dev-2.8.24:latest --environment=MASTER_PORT=6380 --name redis-master  \

        docker://docker-registry.example.com/infeng/redis-sentinel-dev-2.8.24:latest --environment=MASTER_PORT=6380 --environment=SENTINEL_PORT=26380 --environment=MASTER=127.0.0.1 --name redis-sentinel

However, this results in errors when the pod starts:

# systemctl status redis
...
Jul 20 04:12:25 ip-10-2-23-187.qa.xoom.com systemd[1]: Started /bin/rkt --insecure-options=image run --dns=host docker://docker-registry.dev.xoom.com/infeng/redis-sentinel-dev-2.8.24:latest --environme...

Jul 20 04:12:25 ip-10-2-23-187.qa.xoom.com systemd[1]: Starting /bin/rkt --insecure-options=image run --dns=host docker://docker-registry.dev.xoom.com/infeng/redis-sentinel-dev-2.8.24:latest --environm...

Jul 20 04:12:25 ip-10-2-23-187.qa.xoom.com rkt[2919]: run: disabling overlay support: "unsupported filesystem: missing d_type support"

Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com rkt[2919]: run: error setting up stage0: port name "6380-tcp" defined multiple apps

Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com systemd[1]: redis.service: main process exited, code=exited, status=254/n/a

Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com systemd[1]: Unit redis.service entered failed state.

Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com systemd[1]: redis.service failed.
...

I've tried variations on the rkt run invocation, all resulting in the same error.

Is it possible to expose more than one port on a pod, and if so, how to achieve this?

Thank you.

[Luca BRUNO]

On Wednesday, July 19, 2017 9:20:45 PM UTC Mark Petrovic wrote:

> Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com rkt[2919]: run: error setting up
> stage0: port name "6380-tcp" defined multiple apps

I think the problem you are hitting is due to the fact that you are trying to
run two copies of the same app, which are thus defining two times the same
port name. This in turn boils down to docker images not having explicit port
names, thus getting a generated port name in the form of $port-$proto in rkt.

You may try using two different Docker images exposing different port numbers,
or doing the docker->appc conversion yourself and then renaming the exposed
port in ACI manifest. If you have a Docker-based workflow, the first option
may be simpler.

Ciao, Luca

--
"If you build a wall, think of what you leave outside it" - Italo Calvino

[Mark Petrovic]

On Thursday, July 20, 2017 at 1:25:44 AM UTC-7, Luca BRUNO wrote:

On Wednesday, July 19, 2017 9:20:45 PM UTC Mark Petrovic wrote:

> Jul 20 04:12:29 ip-10-2-23-187.qa.xoom.com rkt[2919]: run: error setting up
> stage0: port name "6380-tcp" defined multiple apps

I think the problem you are hitting is due to the fact that you are trying to
run two copies of the same app, which are thus defining two times the same
port name. This in turn boils down to docker images not having explicit port
names, thus getting a generated port name in the form of $port-$proto in rkt.

I see.  It sounds like at runtime an exposed port is associated effectively with an image (aka app?), not a pod.  Is that fair to say? Do you feel like what I want to achieve is reasonable?  If yes to both those questions, how entangled in the design of rkt is that association, and therefore how difficult, through code changes, would it be to allow what I am attempting?  

  

[Mark Petrovic]

I see.  It sounds like at runtime an exposed port is associated effectively with an image (aka app?), not a pod.  Is that fair to say? Do you feel like what I want to achieve is reasonable?  If yes to both those questions, how entangled in the design of rkt is that association, and therefore how difficult, through code changes, would it be to allow what I am attempting?  

It's also possible, maybe likely, that what I'm attempting is an anti-pattern.  I can separate the two containers into dedicated pods and still elegantly achieve my goals.  How I got here resulted from noting that I can run two containers in the same pod, and that drove the remainder of my config.  Because I can run two containers in a pod doesn't mean I should run two containers in a pod for my specific use case.  But, my original question about why that doesn't work in conjunction with the exposed ports might help someone reading this in the future. 

[Luca BRUNO]

On Thursday, July 20, 2017 8:49:19 AM UTC Mark Petrovic wrote:

> > I see. It *sounds *like at runtime an exposed port is associated
> > effectively with an image (aka *app?*), not a pod. Is that fair to say?

I don't completely agree. This is just about the pod runtime being able to
match at runtime port to a port exposed by some app in the pod. Ports are in
the pod scope but names (from app side) are arbitrary, and they are used to
link the two entities.
What you wanted to do is perfectly fine in the pod model, just not with docker
images as you have two apps claiming the same exposed-port identifier after
the auto-conversion.

> > Do you feel like what I want to achieve is reasonable? If yes to both
> > those questions, how entangled in the design of rkt is that association,
> > and therefore how difficult, through code changes, would it be to allow
> > what I am attempting?

I think this won't fix your problem anyway, as you can't have two exposed-
ports in different apps identified by the same name (per appc pod definition).

> It's also possible, maybe likely, that what I'm attempting is an
> anti-pattern. I can separate the two containers into dedicated pods and
> still elegantly achieve my goals. How I got here resulted from noting that

> I *can* run two containers in the same pod, and that drove the remainder of

> my config. Because I can run two containers in a pod doesn't mean I should
> run two containers in a pod for my specific use case. But, my original
> question about why that doesn't work in conjunction with the exposed ports
> might help someone reading this in the future.

It depends on your usecase. It should be ok to assemble the two in a pod if
their lifetime is strictly linked (i.e. they should start, stop, restart, and
fail together) and their are part of the same architectural service; otherwise
they can probably be split and handled as two entities.