Allow additional build flags when building a container

Question

Allow additional build flags when building a container

marchingphoenix opened this issue 4 years ago · 51 comments

When building a devcontainer from dockerfile it will be useful to expose out additional docker build args that can be used when the container is created.
This can be done either by direct linking of these commands to the build property in the .devcontainer.json or via a catch-all array like build.command_flags: ["--network=host", "--compress"] etc

Example, a dockerfile is installing packages from an internal repository but your machine is on a vpn. Would need to pass --network=host to the build command to ensure that traversal happens correctly on Linux hosts.

Answer 1 · 2021-04-14T16:12:07.000Z

Any word on when this might get added? We work in Amazon Workspaces Linux instances and in order to build/run Docker images/containers you need to pass --network host to allow the running container to access the network. There is already a runArgs that allows passing Docker run options there also needs to be a buildOpts to allow passing docker build options

I can work around this by building the container outside vscode and then open my devcontainer project in vscode. I then use the "runArgs": ["--network=host"]. This is less than optimal.

We are trying to make this a standard for projects we support but without this it is difficult.

Answer 2 · 2021-04-28T16:51:20.000Z

In my case I would like to use --cache-from repo/devcontainer:cache as my devcontainer takes around 30 minutes to build, so I can prebuild it in CI and let the VSCode leverage the build cache.

Answer 3 · 2021-04-30T21:58:05.000Z

For some cases (such as mine), the following workaround can be useful:

// pre build image to leverage --cache-from
"initializeCommand": [
  "docker",
  "build",
  "--target=devcontainer",
  "--cache-from=armdocker.rnd.ericsson.se/proj-river/cicd-devcontainer",
  "."
],

This will build the image the way I want, and later when VS Code tries to build it, it will be already cached and will be almost instantaneous.

Answer 4 · 2021-09-13T15:21:12.000Z

Hello,
any update on this ticket ? we really need this feature to be able to use --network=host.

Regards

Answer 5 · 2022-01-11T21:19:35.000Z

Another very important use-case I don't see mentioned above is that this feature is needed in order to use docker "build --ssh=default".

This is used to allow the host ssh-agent to sign for build commands (such as pulling from a private github repository using ssh).

Answer 6 · 2022-03-03T12:07:36.000Z

And since I have the docker buildx plugin I cannot run it since I have to pass --load argument for the image to be loaded into docker locally.

Answer 7 · 2022-03-03T12:41:04.000Z

--load is implicit, unless you are not using the native/default builder.

docker buildx use default

Answer 8 · 2022-03-03T12:47:16.000Z

--load is implicit, unless you are not using the native/default builder.
docker buildx use default

I am using this emulator (https://github.com/tonistiigi/binfmt), does that makes --load not implicit?

Answer 9 · 2022-03-03T13:14:22.000Z

does that makes --load not implicit?

Yes

Answer 10 · 2022-03-29T17:33:12.000Z

Another very important use-case I don't see mentioned above is that this feature is needed in order to use docker "build --ssh=default".

This is used to allow the host ssh-agent to sign for build commands (such as pulling from a private github repository using ssh).

Yes, this has been blocking me for years.

Answer 11 · 2022-03-31T09:35:30.000Z

I am in Japan and the apt command for Ubuntu Docker images is very slow.
This is due to the distance from Japan to archive.ubuntu.com, which is greatly improved by using a mirror server in Japan (jp.archive.ubuntu.com) with option --add-host=archive.ubuntu.com:160.26.2.187 set.

When building from Remote-Containers, this technique cannot be used and builds take a long time...

Answer 12 · 2022-03-31T12:47:32.000Z

I'm not sure if this was said here or not, but Remote Containers supports docker-compose. It means you can leverage whatever docker-compose let you do in the build. Even if it's for a single container.

Answer 13 · 2022-05-16T14:14:33.000Z

Was curious if theres been any progress on this? I'm basically unable to use the built-in .devcontainer system due to not being able to pass the --ssh default flag on build. Something like a

"buildOptions": ["--ssh default"]

would be incredibly helpful.

Answer 14 · 2022-06-06T19:03:12.000Z

For some cases (such as mine), the following workaround can be useful

Thanks!

	"initializeCommand": [
		"docker", "build", "--network=host", ".devcontainer"
	],

worked for me.

Answer 15 · 2022-06-20T10:27:51.000Z

Wondering if @Chuxel, @bamurtaugh or if @chrmarti would have an update on this? The feature is quite useful indeed. Anyone building images that require cloning from private repositories would be really well served with this option.

Also, does someone has a working workaround to use ssh agent based authentication when building a container image based on devcontainer.json ? I don't immediately understand what @Trass3r is doing.

Answer 16 · 2022-06-28T14:51:47.000Z

As of today, using the pre-release version of the plugin (don't know if available on the release version),
there is a new build attribute in devontainer.json with new sub-attributes like args, cacheFrom and target:

"build": {
	"args": {
		"BUILD_ARG1": "value1",
		"BUILD_ARG2": "value2"
	}
},

Answer 17 · 2022-06-30T08:24:45.000Z

@LudovicTOURMAN I've just retested using Remote - Containers v0.241.1 Pre-Release version.

My devcontainer.json looks like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.234.0/containers/docker-existing-dockerfile
{
	"name": "Quark Dev Environment",
    [...]
	"build": {
		"args": { "--ssh": "default" }
    }
}

The container creation fails, see log below:

[556 ms] Setting up container for folder or workspace: /root/quark
[559 ms] Start: Check Docker is running
[...]
[1472 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=\\wsl$\Ubuntu-vscode-quark\root\quark
[1573 ms] Start: Run: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f /root/quark/Dockerfile -t vsc-quark-91dd4a23334f30b21c17b16e0490c8cf --build-arg --ssh=default /root/quark
[6309 ms] Error: Command failed: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f /root/quark/Dockerfile -t vsc-quark-91dd4a23334f30b21c17b16e0490c8cf --build-arg --ssh=default /root/quark

The offending part is --build-arg --ssh=default

I was expecting something on the lines of:
docker build --ssh default .

Which actually works fine for me when the container creation is launched directly from the WSLs command line. Any hints ?

Answer 18 · 2022-08-12T11:00:59.000Z

It looks amazing that 53 upvotes of this issue in 2 years changed nothing. Even when there is a myriad of problems that it could potentially solve 😔. It looks there was a time when this feature worked.

👉 Any update on this?

Answer 19 · 2022-08-18T15:44:59.000Z

For the people who used initializeCommand as a workaround. It seems like SSH_AUTH_SOCK is not set while initializeCommand is run on a remote ssh instance. Which means that the

"initializeCommand": ["docker", "build", "--ssh=default", "-f", ".devcontainer/Dockerfile", "."]

workaround doesn't work for me. Note, I'm agent forwarding with AgentForward yes via ssh config. Does anyone know how to access the ssh agent in initializeCommand?

Answer 20 · 2022-10-06T00:26:47.000Z

I've been struggling with this today and as far as I can tell, build.args doesn't seem to parse environment variables.

VSCode has "terminal.integrated.inheritEnv": true, I have variables defined and exported in my .zshenv and .zshrc files (macOS), and I have them set in my devcontainer.json as such:

"build": {
	"args": {
		"VAR1": "${VAR1}",
		"VAR2": "${VAR2}"
	}
}

Reopen in Container fails every time with the build failing due to the environment variables not being passed through. Running a docker build from the integrated shell in VSCode works as expected. Am I missing something here or this broken?

Answer 21 · 2022-10-06T00:36:08.000Z

My suggestion for you is to use docker compose instead.

Answer 22 · 2022-10-06T09:32:33.000Z

@BryanAPEX You can use ${localEnv:VAR1} for using a local variable in the devcontainer.json.

Answer 23 · 2022-10-06T14:49:25.000Z

@BryanAPEX You can use ${localEnv:VAR1} for using a local variable in the devcontainer.json.

For some reason, I thought that syntax only applied to working on Windows with PowerShell, but had actually tried it earlier as a test with no success. Something else must have been misconfigured at that point as I just tried it again with fresh eyes and it worked. Embarrassing, but I'll leave this here in hopes it helps anyone else going through this with the same bad assumption. Thank you!

Answer 24 · 2023-03-13T11:40:51.000Z

For some cases (such as mine), the following workaround can be useful:
// pre build image to leverage --cache-from
"initializeCommand": [
  "docker",
  "build",
  "--target=devcontainer",
  "--cache-from=armdocker.rnd.ericsson.se/proj-river/cicd-devcontainer",
  "."
],
This will build the image the way I want, and later when VS Code tries to build it, it will be already cached and will be almost instantaneous.

Building on this suggestion, we can also use image:

 "initializeCommand": "docker build --network host --tag my-image .",
  "image": "my-image"

This works pretty nicely and requires not so much boilerplate.
Should you have a lot of arguments, you can save building command as a script and call that.

Answer 25 · 2023-03-23T08:35:29.000Z

Looking to leverage the --secret flag to mount some credentials at build, doesn't seem to be supported currently (?)

Answer 26 · 2023-04-25T17:05:14.000Z

I am trying to use a BLAH_TOKEN in my build environment, but can't seem to get it to work via anything I've googled or found so far.

Answer 27 · 2023-04-25T17:13:46.000Z

My suggestion for you is to use docker compose instead.

Quoting again my own suggestion. ;)

Answer 28 · 2023-04-27T16:14:30.000Z

OMG nearly 3 years open
Its a Problem....
I need to pass environment variables to the build for authentication.

Answer 29 · 2023-05-17T11:24:05.000Z

This is seriously limiting us. It is not possible to build a dev-container because we need to access a proxy that is running on the host. We can neither pass --network=host nor --add-host=host.docker.internal:host-gateway when building a container.

Edit: Finally I got the mentioned workaround with initializeCommand working. What they all forgot to mention is that the whole build part needs to be removed and instead, the custom build should tag the image and that tag should be used in image.
Example:

{
	"name": "Debian",
	"initializeCommand": [
		"docker",
		"build",
		"--network=host",
		"--tag=my-project-dev",
		".devcontainer"
	],
	"image": "my-project-dev",
	...
}

Answer 30 · 2023-07-28T13:50:55.000Z

#3545 (comment)

As of today, using the pre-release version of the plugin (don't know if available on the release version), there is a new build attribute in devontainer.json with new sub-attributes like args, cacheFrom and target:
"build": {
	"args": {
		"BUILD_ARG1": "value1",
		"BUILD_ARG2": "value2"
	}
},

{
    "build": {
		"dockerfile": "../Dockerfile", 
		"args": {
			"BUILD_ARG_KEY":"BUILD_ARG_VALUE"
		}
    }
}

Field "args" worked for me

Answer 31 · 2023-07-28T14:11:42.000Z

Field "args" worked for me

AFAIK that's for docker build --build-arg only, not for any arbitrary option.

Answer 32 · 2023-07-28T14:54:31.000Z

Field "args" worked for me

AFAIK that's for docker build --build-arg only, not for any arbitrary option.

Sorry, I didn't read the entire conversation, just replied to "Allow additional build flags when building a container" topic (the main request from marchingphoenix).

Answer 33 · 2023-09-04T09:56:11.000Z

As this is something that is missing in the dev-container specification itself, I started a feature discussion regarding this there: devcontainers/spec#301

Answer 34 · 2023-09-11T13:19:56.000Z

Sometimes it is necessary to pass secrets to the dev container build. While I learned that we can use something like ${localEnv:VAR1}, which is great, it is not sufficient from my point of view.

Is it possible to ask the user for a specific argument, such as:

Specify ${userArg:VAR1} in the devcontainer,json.
Before starting the build, ask the user to pass the value for e.g. VAR1*.
Start the Docker build

*) Ask the user if the value should be stored in a local login store (optional second version).

Use case:
I have a Docker file from a customer that contains vcpkg in a cmake script to pull some libraries from an Azure repository. While the git repo is pulled with a credential manager, vcpkg only works with a pat (personal access token).

While this is a specific use case, it can also apply to many other use cases where secrets should only be stored in a secure repository.

Answer 35 · 2023-10-17T14:17:11.000Z

For years I have been using docker compose instead. You can do that too, no?

Answer 36 · 2023-10-17T14:41:32.000Z

OMG nearly 3 years open Its a Problem.... I need to pass environment variables to the build for authentication.
How many more years until this has been implemented? Right now this is the last hurdle we have in my organisation to fully using vs code development containers.

For anyone having this trouble I would suggest to use a post-install script called after the build command that allows for user authentication inside docker. 👌 that's how we "workarounded" the issue and works like a charm.

Answer 37 · 2023-11-01T09:35:09.000Z

I added a proposal devcontainers/spec#328 and also the spec change devcontainers/spec#324
Feel free to upvote them to give more visibility.

Answer 38 · 2023-12-20T05:02:18.000Z

For years I have been using docker compose instead. You can do that too, no?

@felipecrs Thanks but it's the 3rd time you mention this. This feature should exist without needing to use Docker Compose.

Answer 39 · 2023-12-20T05:04:47.000Z

Yes, for sure. I'm not denying that. I was just trying to provide an alternate solution so that users don't need to wait on this to be implemented.

Answer 40 · 2024-01-15T14:26:38.000Z

The proposal devcontainers/spec#328 is merged. 👍

In progress: devcontainers/cli#85 and devcontainers/spec#324.

Answer 41 · 2024-01-17T09:31:59.000Z

Available in Dev Containers 0.333.0-pre-release.

Answer 42 · 2024-01-17T16:22:20.000Z

This is great being able to specify build arguments now!

Is there a way the user can specify those build arguments (or a script can be run on the host machine)?

I'm thinking something like this.

{
        "name": "Code Build Environment",
        "dockerFile": "/usr/share/dpkg-buildenv/Dockerfile",
        "build": {
                "args": {
                        "DISTRIBUTION" : "${inputs:distribution}"
                }
        },
	"inputs": [
		{
		  "id": "distribution",
		  "type":"promptString",
		  "description": "which base os to use",
		  "default": "debian:12"
		}
	],
}

Using "${inputs:XX}" works in VSCode launch.json however it looks like it isn't support for .devcontainers.json.

Answer 43 · 2024-01-18T08:34:07.000Z

@aidan-gallagher Correct, that is not supported at the moment. Seeing your feature request for this at #9397. Thanks.

Answer 44 · 2024-01-18T09:46:34.000Z

@aidan-gallagher +1, would love to see this implemented.

Answer 45 · 2024-01-18T10:50:16.000Z

Awesome, thanks! Is it possible @chrmarti to also include Docker's official buildx bake tool as well? that would allow passing in a larger build spec file (instead of lots of cli flags)
devcontainers/spec#311

Answer 46 · 2024-01-18T15:45:22.000Z

I just tried it with the pre-release of 0.333.0 with the following build:

"build": {
      "dockerfile": "Dockerfile",
      "options": [
        "--add-host=host.docker.internal:host-gateway"
      ]
    },

but I don't see this added to the docker build command in the log and also the hostname cannot be found in the docker container. Am I missing something?

Answer 47 · 2024-01-22T15:29:17.000Z

@Roemer That should indeed work. Could you open an issue with the log from rebuilding the container? Thanks!

@c-ameron That is not supported by the feature implemented here. devcontainers/spec#311 is a good place to track it. Thanks!

Answer 48 · 2024-01-26T06:34:38.000Z

build: {options: [...]} does NOT work in the latest prerelease version of extension 0.337 and devcontainer cli 0.55

Answer 49 · 2024-01-26T07:31:27.000Z

@pmunin Could you open an issue with the log included? (F1 > Dev Containers: Show Container Log)

Answer 50 · 2024-01-26T14:42:13.000Z

@chrmarti as i mentioned in that other comment - I discovered after reloading the window that my installed prerelease version was not 0.337, but 0.330 instead which is max available for standard vscode build:

So seems like I need VS Code Insider to try it, which I'm not ready to install yet, hope it's ok. But I cannot wait this feature to be released. This --ssh default is an absolute MUST HAVE for companies that have their private repos/packages installed during building an image that require authentication (in my case it's private homebrew packages)

Answer 51 · 2024-01-26T15:34:57.000Z

The current pre-release versions of the Dev Containers extension also adopt changes from the upcoming VS Code 1.86 which is why they require VS Code Insiders at the moment. VS Code 1.86 is expected to release some time next week at which point we will also release a new stable version of the Dev Containers extension.