Optionally use different host internal and host ip for networking in dev environments.

[dkennetzoracle]

Allows users to optionally build dev environment with non-default HOST_INTERNAL and HOST_IP. This can resolve issues when there are connectivity errors from archgw to the host machine.

[dkennetzoracle]

Can revert this, but cargo build --target wasm32-wasip1 --release this failed on my machine, but building these packages individually worked. I can revert this, I just wanted to draw attention to it.

[adilhafeez]

That is because llm_gateway and prompt_gateway binaries are loaded in envoy which only supports wasm32-wasip1 runtime. But for brightstaff there is no such limitation as runs as individual server.

[dkennetzoracle]

No pressure to merge any / all of this btw, just easier to communicate intent here with code.

[Copilot]

Pull Request Overview

This PR enables configurable host networking settings for development environments to resolve connectivity issues between archgw and the host machine. It allows users to specify custom HOST_INTERNAL and HOST_IP environment variables instead of using hardcoded default values.

• Replaces hardcoded host.docker.internal and host-gateway with configurable environment variables
• Updates Docker build commands, container runtime configurations, and Envoy templates to use the new variables
• Modifies docker-compose configuration to support the new networking options

Reviewed Changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
arch/tools/cli/main.py	Updates Docker build and runtime commands to use configurable HOST_INTERNAL and HOST_IP environment variables
arch/tools/cli/docker_cli.py	Modifies container startup to use configurable host networking settings
arch/envoy.template.yaml	Changes hardcoded host address to use HOST_INTERNAL environment variable
arch/docker-compose.dev.yaml	Updates compose file to support configurable host networking and fixes volume mappings
arch/README.md	Updates documentation with corrected build commands and file references

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[adilhafeez]

@dkennetzoracle thanks a lot for putting this PR together. I think we can also do following too as it will be a bit simpler. What do you think?

    extra_hosts:
      - "host.docker.internal:host-gateway"
      - "host.rancher-docker.internal:host-gateway"

[dkennetzoracle]

@dkennetzoracle thanks a lot for putting this PR together. I think we can also do following too as it will be a bit simpler. What do you think?

    extra_hosts:
      - "host.docker.internal:host-gateway"
      - "host.rancher-docker.internal:host-gateway"

No problem! Happy to help where I can. I ended up finding out that host.docker.internal worked for me, the docker bridge just pointed to the wrong IP - or an IP that failed to connect out.

Summary: either host worked if I set the correct HOST_IP (which was that 192 value). I'm okay either way.

My CLI looks like:

ARCH_CONFIG_FILE=/Users/dkennetz/code/arch_demos/oci_apis/arch_config.yaml OPENAI_API_KEY=test MISTRAL_API_KEY=test HOST_INTERNAL=host.docker.internal HOST_IP=192.X.X.X docker-compose -f docker-compose.dev.yaml up archgw

[adilhafeez]

Looking at rancher docs it seems like adding mapping for host-gateway is not supported and is likely contributing to the issue. I think fix may be to not add mapping when rancher desktop is used.

Another fix is to remove that mapping completely as newer version of docker desktop doesn't need that support.

[adilhafeez]

So I just tried following without add-host command and it worked.

root@55d2a7d24190:/app# curl host.docker.internal 
curl: (7) Failed to connect to host.docker.internal port 80 after 4 ms: Couldn't connect to server
root@55d2a7d24190:/app# 

But I do think that better/safer approach is to use mapping for all environments except for rancher. So we'll need to add a runtime check in bash script to add/remove mapping based docker provider (maybe look at docker info to see if rancher is the host)

[dkennetzoracle]

I agree, I think it would be a better approach to keep the mapping for everything else (especially if it is backwards compatible in newer docker desktop versions) @adilhafeez