How to expose ports for go_image?

[chaitanya9186]

#305

[mattmoor]

You can compose go_image with container_image, e.g.

go_image(
    name = "foo",
    ...
)

container_image(
    name = "bar",
    base = ":foo",
    ports = [...],
)

[chaitanya9186]

But bazel run :bar target not running the container.

[mattmoor]

This was harder to make the default for container_image (really: docker_build) which has been around for years. You can enable that for that rule with: legacy_run_behavior = False.

You can also invert the layer ordering to get this, e.g.:

load("@io_bazel_rules_docker//go:image.bzl", GO_DEFAULT_BASE="DEFAULT_BASE")

container_image(
    name = "bar",
    base = GO_DEFAULT_BASE,
    ports = [...],
)

go_image(
    name = "foo",
    base = ":bar",
    ...
)

[chaitanya9186]

I have tried the invertion approach too. If I run docker run -d -p 8888:8888 <image> I able to query with localhost:8888, but if I run bazel run :foo I am unable to query localhost:8888.

I referred the generated config file, it has the ExposedPorts: {"8888:8888/tcp": {}} filed.

And I also checked docker ps -a list, with manual docker run I see 40ef854fdb77 <image> "/app/server/serve..." 20 seconds ago Up 19 seconds 0.0.0.0:8888->8888/tcp.

with bazel run :foo I see 8fcc1ca061f0 <image> "/app/server/serve..." 6 seconds ago Up 5 seconds 8888/tcp

I am not sure, what's happening, but I get a feeling that I miss some other setting.

[mattmoor]

We don't expose network on the Docker daemon by default when a lang_image is run (except war_image).

I feel like this is a mistake, particularly since you can't override it. We should be doing what we do for war_image for all lang_image. I'll just fix this.

Another thing to beware of is that ctrl+C of the container run by bazel won't kill it. This is a longstanding Bazel bug, that I'll dig up and ping.

[mattmoor]

here's the thread: bazelbuild/bazel#3519

[wkiser]

I was running into similar problems as @chaitanya9186 when trying to run a flask app in a container locally. Now that #312 is merged, can the lang_image binaries be updated to accept a docker_run_flags argument (and pass it to the app_layer)? Based off of my brief local testing that would make the docker pick up the run flags when running `bazel run :lang_image' locally.

[alsutton]

I've put a PR up to add the ports option to the go_image; #462

[nlopezgi]

lang_images have the same arguments as their corresponding lang_binary rules. The recommended way to get these additional properties is still to compose the lang_image with a container_image as indicated in the comment above.

[alsutton]

Given _binary and _image tackle two different types of problem (the need for a locally executable binary -v- the need to compose a container image) it seems a little odd to try and keep their parameters in absolute sync, but hey, your repo, your rules :)

[nlopezgi]

is this still an issue? please reopen if so.

[jschaf]

Can you explain the rationale for wanting to keep go_image synced with go_binary? I echo @alsutton's sentiment that they do different things. It'd be nice if ports were exposed on the lang_image rules.

lang_images have the same arguments as their corresponding lang_binary rules

This isn't true. go_image has base, binary and layers attributes, none of which are present in go_binary.

[nlopezgi]

Some key reasons:

• We have not found any limitations with the current approach of adding a base container_image to your xx_image or extending the xx_image rule with container_image to add these properties
• There's no current need to clutter each xx_image rule with attributes already present in container_image
• The maintenance burden for xx_image rules would be significantly increased if we had to maintain each separately with extensions added by community to add attributes that they find lacking which are already offered in container_image
• Maintaining xx_image rules in sync with xx_binary rules, given the quick churn of Bazel core and Starlark rules, is hard enough as it is today. Adding more attributes to these rules increases the complexity of the code, making it harder for us to maintain them.
• An architectural principle of the xx_image rules is that it should be trivial to swap out xx_binary for xx_image (and vice versa) with minimum overhead. We have made a very small number of exceptions (namely, adding layers) for some specific xx_image rules in specific cases in which there is a clear gain that can be obtained via providing a language-specific layering strategy. I've pushed back in each case, but eventually agreed when the arguments are strong enough to make the exception. ports is definitely not in this category
• Adding things to an API, just because it would be 'nice' to have them tends to lead, imo, to API surfaces that too large and can lead to user confusion, and are generally harder to maintain.

[mancini0]

Bazel run //yourimage pushes the image to your local repository and runs it. You can suppress the run by "bazel run //yourimage -- --norun" (so this would simply publish it to your local docker) then 'docker run' it using docker. Then you can run it like you would any other image, setting ports, network, etc.