Make devcontainer work in WSL and proxy environments #52

olivembo · 2025-11-05T14:39:31Z

Summary

This PR adds robust support for running the devcontainer in environments with or without a corporate proxy, including WSL2 scenarios. The setup is now fully automated and self-healing, ensuring Docker and BuildKit always use the correct proxy settings.

Key changes

Automated proxy detection and configuration
- Adds .devcontainer/setup-proxy.sh which configures Docker daemon, BuildKit, and Docker client for proxy or non-proxy environments.
- Automatically detects and applies current proxy environment variables.
- Cleans up and recreates BuildKit builder with correct proxy settings if the proxy changes.
Post-create automation
- Runs the setup script automatically via postCreateCommand in devcontainer.json.
Build-time and runtime proxy support
- Passes proxy variables as build args and runtime envs.
- Ensures Dockerfile and all devcontainer features can access the internet through the proxy.
WSL2 and host networking compatibility
- Adds host.docker.internal and other runArgs for seamless networking in WSL2.
Documentation and testing
- Adds .devcontainer/test-proxy.sh for easy verification.
- Adds README-PROXY.md with usage and troubleshooting instructions.

How it works

On container creation, the setup script:
Detects proxy settings.
Configures Docker daemon and BuildKit accordingly.
Verifies Docker and registry access.
Works out-of-the-box for both proxy and non-proxy environments.
Handles proxy changes and container rebuilds gracefully.

Why

Ensures reliable devcontainer builds in corporate, WSL, and direct-internet environments.
Reduces manual setup and troubleshooting for developers.
Makes onboarding and CI/CD more robust.

AlexanderLanin · 2025-11-06T09:01:06Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--volume=/home/${USER}/.cache/uv:/home/user/.cache/uv"
+    ],
+    "workspaceFolder": "/workspace",
+    "postCreateCommand": "bash .devcontainer/setup-proxy.sh",


@opajonk can you please document/explain how the split between devcontainer and features is designed?

Moved to #28

AlexanderLanin · 2025-11-06T09:03:19Z

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

+        fi
+    }
+
+    # Restart Docker with proxy settings


Will this kill any (unrelated) running dockers on the system?

I think this comment is outdated.

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

lurtz

Adds README-PROXY.md with usage and troubleshooting instructions.

I guess this forgotten to be added.

We should talk about this pull request via Slack.

lurtz · 2025-11-07T13:05:41Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--volume=/home/${USER}/.cache/uv:/home/user/.cache/uv"
+    ],
+    "workspaceFolder": "/workspace",
+    "postCreateCommand": "bash .devcontainer/setup-proxy.sh",


I am a bit confused where this script is intended to be run. Per the location it should be run inside the S-CORE devcontainer. But the content assumes that docker is present, which is not installed in the S-CORE devcontainer but on the host instead.

If you intend to run it on the host, you have to use initializeCommand: https://containers.dev/implementors/json_reference/#lifecycle-scripts. However in this case you have to deal with lots of different environments.

Host environments I am aware of so far:

Ubuntu 20.04, 22.04, 24.04

do not expect to have root permissions on these

MacOS

WSL2

lurtz · 2025-11-07T13:12:46Z

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

is this script reconfiguring my host Docker daemon from inside the S-CORE devcontainer?

lurtz · 2025-11-07T13:19:08Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--volume=/var/run/docker.sock:/var/run/docker.sock",
+        "--volume=..:/workspace:cached",
+        "--volume=/tmp/.X11-unix:/tmp/.X11-unix",
+        "--volume=/home/${USER}/.cache/uv:/home/user/.cache/uv"


what is in .cache/uv? It does not exist on my host

lurtz · 2025-11-07T13:23:58Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--env=WORKSPACE_FOLDER=/workspace",
+        "--volume=/var/run/docker.sock:/var/run/docker.sock",
+        "--volume=..:/workspace:cached",
+        "--volume=/tmp/.X11-unix:/tmp/.X11-unix",


would this close the door to wayland users?

lurtz · 2025-11-07T13:33:56Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--env=no_proxy",
+        "--env=DISPLAY",
+        "--env=WORKSPACE_FOLDER=/workspace",
+        "--volume=/var/run/docker.sock:/var/run/docker.sock",


I have to check how well this works with podman. At the time being I would like to be able to run the container on both docker and podman. The reason is that for being able to run bazels linux-sandbox the container needs to be run with --privileged which gives the container with docker basically root access to my notebook. With podman this can be minimized to my user.

I have so far seen containers as an easy to setup development environment and as a security / safety measure for the host system of my computer. Having to use --privileged is already a big boon to that and seeing the host docker being reconfigured from within the container seems to further tear down this wall.

lurtz · 2025-11-07T13:35:52Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

+        "--env=https_proxy",
+        "--env=NO_PROXY",
+        "--env=no_proxy",
+        "--env=DISPLAY",


will this read the content of the current variable and assign it to DISPLAY inside the container?

lurtz · 2025-11-07T13:40:14Z

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

+        echo "🔄 Restarting Docker daemon with proxy settings..."
+
+        # Kill existing dockerd if running
+        if pgrep dockerd > /dev/null; then


docker is not installed inside the container. How can you access it?

lurtz · 2025-11-07T13:49:00Z

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

+    sudo tee /etc/docker/daemon.json > /dev/null << EOF
+{
+  "registry-mirrors": [],
+  "insecure-registries": [],
+  "debug": false,
+  "experimental": false,
+  "dns": ["8.8.8.8", "1.1.1.1"],
+  "dns-search": [],
+  "dns-opts": []
+}


I have setup a daemon.json so that docker works in the corporate environment of my company. Would this be overriden, if I were using one of the proxy variables?

lurtz · 2025-11-07T13:52:05Z

src/s-core-devcontainer/.devcontainer/setup-proxy.sh

+    # Prepare buildx command with proxy options
+    BUILDX_CMD="docker buildx create --name multiarch --driver docker-container --driver-opt network=host"


now I get very confused. I assume this requires the existence of a Dockerfile. Is this script used to build the S-CORE devcontainer with the other devcontainer of this repository?

opajonk · 2025-11-10T07:48:43Z

Adds README-PROXY.md with usage and troubleshooting instructions.

I guess this forgotten to be added.

We should talk about this pull request via Slack.

I agree we should have a chat. There seems to be a legitimate use-case (as I also heard during the architecture workshop last week). However, re-configuring the docker host (!) significantly - and probably unexpectedly to most other users - is a problem. Maybe we can find a less "intrusive" and still helpful solution?

lurtz

Works on my machine.

Now proxy related environment variables are defined in the container with empty content. I hope no software trips over that.

Have you considered using

    "runArgs": [
        "--env-file", "proxy_settings.env",
    ],

In the devcontainer.json? In proxy_settings.env you define the environment variables to be made available inside the container. Maybe even .env as filename is sufficient and no extra arguments needed (was not working for me with an already built container)

olivembo · 2025-11-11T16:03:47Z

Works on my machine.

Now proxy related environment variables are defined in the container with empty content. I hope no software trips over that.

Have you considered using
    "runArgs": [
        "--env-file", "proxy_settings.env",
    ],
In the devcontainer.json? In proxy_settings.env you define the environment variables to be made available inside the container. Maybe even .env as filename is sufficient and no extra arguments needed (was not working for me with an already built container)

In general, I like the .env file approach, but in that case it would mean that users behind proxies would have to create the .env file manually before they can start. The current approach does not need any user interaction, neither from user behind a proxy nor from users with direct internet connection.

Regarding the empty environment variables in case of direct internet access:
I agree it is maybe confusing, but didn't had side effects so far when I tested on my machine with direct internet access.

However, I could add a line like

"postStartCommand": "for var in HTTP_PROXY HTTPS_PROXY http_proxy https_proxy NO_PROXY no_proxy; do [ -z \"${!var}\" ] && unset $var || true; done",

to the devcontainer.json. Does that make sense from your side?

lurtz · 2025-11-11T21:25:36Z

I would appreciate if these are deleted if empty. Then we are sure not to get unintended side effects. I also only checked if some tools work. Would be a waste of time to discover that there is a tool which malfunctions when these variables are set but empty.

olivembo · 2025-11-12T07:19:14Z

I would appreciate if these are deleted if empty. Then we are sure not to get unintended side effects. I also only checked if some tools work. Would be a waste of time to discover that there is a tool which malfunctions when these variables are set but empty.

Is addressed with c81e8ed

lurtz · 2025-11-12T11:59:16Z

I get an error, when starting the container:

Running the postStartCommand from devcontainer.json...

[3301 ms] Start: Run in container: /bin/sh -c for var in HTTP_PROXY HTTPS_PROXY http_proxy https_proxy NO_PROXY no_proxy; do [ -z "${!var}" ] && unset $var || true; done
/bin/sh: 1: Bad substitution
[3349 ms] postStartCommand from devcontainer.json failed with exit code 2. Skipping any further user-provided commands.

I suspect the problem is that /bin/sh is used instead of bash.

lurtz · 2025-11-12T16:05:22Z

src/s-core-devcontainer/.devcontainer/devcontainer.json

        "./s-core-local"
    ],
    "remoteUser": "vscode",
+    "postStartCommand": "bash -c 'for var in HTTP_PROXY HTTPS_PROXY http_proxy https_proxy NO_PROXY no_proxy; do [ -z \"${!var}\" ] && unset $var || true; done'",


this still does not work. Execution is now successful, but variables are still present in a new shell:

vscode ➜ /workspaces/inc_mw_com (example_trait_impl) $ cat .devcontainer/devcontainer.json { "name": "eclipse-s-core", // "image": "ghcr.io/eclipse-score/devcontainer:rustup-completion-amd64" "image": "ghcr.io/eclipse-score/devcontainer:proxy-settings-amd64" // "image": "ghcr.io/eclipse-score/devcontainer:fix-setting-bazel-version-amd64" } vscode ➜ /workspaces/inc_mw_com (example_trait_impl) $ env | grep -i proxy no_proxy= https_proxy= NO_PROXY= HTTPS_PROXY= HTTP_PROXY= http_proxy=

You are right. The postStartCommand runs in its own shell und unsets the environment variables only there.

The only solution I would have at the moment, would be to append unset commands to .bashrc in the postStartCommand. The .bashrc is then sourced by every new bash shell and every time unsets the environment variables. But it's not a nice solution imho. Would appreciate better proposals.

I guess we can use /etc/profile.d/ for this. Here is an example where I removed using it: https://github.com/eclipse-score/devcontainer/pull/51/files#diff-e418ce180663a5c3fc806f1c352a9d737097e60cecaa9cd1724c8236a955a335R64

Addressed with #102e649a40d7af70dba77453bbb984b659e5ff74

lurtz · 2025-11-12T16:09:42Z

src/s-core-devcontainer/.devcontainer/s-core-local/install.sh

+# gdb (GNU Debugger)
+apt-get install -y gdb="${gdb_version}*"


@opajonk Do we really have to specify the tool version, if it just installed via apt-get? E.g. Python tooling is not installed with a specific version either: https://github.com/etas-contrib/score_devcontainer/blob/8aae83706ce51796b85894cdd2c6c0bc29901e84/src/s-core-devcontainer/.devcontainer/s-core-local/install.sh#L41

We already have a Ubuntu release set, which defines the versions of these tools. And thus defining the versions for each tool feels redundant.

lurtz · 2025-11-12T16:11:43Z

src/s-core-devcontainer/.devcontainer/s-core-local/install.sh


+# OpenJDK JRE and CA certificates, via APT
+# Required for Bazel to work with corporate proxy/CA certificates
+apt-get install -y --no-install-recommends ca-certificates-java openjdk-${openjdk_version}-jre-headless


Specifying the Java version here is IMHO ok, because there are different versions as apt packages available for the same Ubuntu release.

… direct internet connection

Signed-off-by: Oliver Emrich <oliver.emrich2@bosch.com>

…te proxy/CA certificates

lurtz · 2026-01-21T11:21:09Z

#52 (comment) is still relevant

src/s-core-devcontainer/.devcontainer/Dockerfile

opajonk · 2026-01-21T17:11:20Z

src/s-core-devcontainer/.devcontainer/Dockerfile

+
+# Proxy arguments for build-time network access
+ARG HTTP_PROXY
+ARG HTTPS_PROXY
+ARG http_proxy
+ARG https_proxy
+ARG NO_PROXY
+ARG no_proxy
+
 FROM buildpack-deps:${VARIANT}-curl


However, there is even more here: there are pre-defined build args in Docker (I did not know before reviewing this PR). Guess what, they are exactly those we are looking for here! Can you test if that works? Maybe the ARG declarations are not needed at all.

I lean towards having them explicitly. Otherwise someone will also stumble across it and wonder how did this ever work?

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Oliver Emrich <195922963+olivembo@users.noreply.github.com>

opajonk

nice job!

AlexanderLanin reviewed Nov 6, 2025

View reviewed changes

src/s-core-devcontainer/.devcontainer/setup-proxy.sh Outdated Show resolved Hide resolved

lurtz reviewed Nov 7, 2025

View reviewed changes

lurtz reviewed Nov 11, 2025

View reviewed changes

lurtz reviewed Nov 12, 2025

View reviewed changes

olivembo added 7 commits January 15, 2026 15:46

Introduced usage of proxy environment variables

c4c123e

feat: Added proxy related functions to the create_builder.sh script

ba91ed4

chore: Reverted previous changes

14d8782

feat: Remove empty, proxy-related environment variables if there is a…

b80c0ba

… direct internet connection

fix: Use bash for postStartCommand instead of sh (default)

0976073

Signed-off-by: Oliver Emrich <oliver.emrich2@bosch.com>

chore: Add OpenJDK in order to be able to configure Bazel for corpora…

a811a36

…te proxy/CA certificates

feat: Install gdb

8490b2b

olivembo force-pushed the make-devcontainer-also-work-in-environments-with-proxy branch from 8aae837 to 8490b2b Compare January 15, 2026 14:52

Removed duplicate entry

f348fe8

Unset proxy environment variables if they are empty

102e649

olivembo added this to Infrastructure Jan 21, 2026

github-project-automation bot moved this to Draft in Infrastructure Jan 21, 2026

olivembo added the enhancement New feature or request label Jan 21, 2026

opajonk suggested changes Jan 21, 2026

View reviewed changes

Update src/s-core-devcontainer/.devcontainer/Dockerfile

4cbf53a

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Oliver Emrich <195922963+olivembo@users.noreply.github.com>

lurtz approved these changes Jan 22, 2026

View reviewed changes

opajonk approved these changes Jan 22, 2026

View reviewed changes

opajonk mentioned this pull request Jan 22, 2026

Docs? #28

Open

AlexanderLanin approved these changes Jan 22, 2026

View reviewed changes

AlexanderLanin merged commit c341030 into eclipse-score:main Jan 22, 2026
4 checks passed

AlexanderLanin deleted the make-devcontainer-also-work-in-environments-with-proxy branch January 22, 2026 10:44

github-project-automation bot moved this from Draft to Done in Infrastructure Jan 22, 2026

		# Prepare buildx command with proxy options
		BUILDX_CMD="docker buildx create --name multiarch --driver docker-container --driver-opt network=host"

		# gdb (GNU Debugger)
		apt-get install -y gdb="${gdb_version}*"

Make devcontainer work in WSL and proxy environments #52

Make devcontainer work in WSL and proxy environments #52

Uh oh!

Conversation

olivembo commented Nov 5, 2025

Summary

Key changes

How it works

Why

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lurtz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

opajonk commented Nov 10, 2025

Uh oh!

lurtz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

olivembo commented Nov 11, 2025

Uh oh!

lurtz commented Nov 11, 2025

Uh oh!

olivembo commented Nov 12, 2025

Uh oh!

lurtz commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

olivembo Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lurtz Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lurtz commented Jan 21, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

opajonk left a comment

Choose a reason for hiding this comment

Uh oh!

lurtz left a comment •

edited

Loading

olivembo Nov 12, 2025 •

edited

Loading

lurtz Nov 13, 2025 •

edited

Loading