When developing with VSCode Remote Containers, if you write a Dockerfile and say "Reopen in Container", the Docker container will start, but at this time VSCode will execute docker run
.
Therefore, if you start it without worrying about anything and referring to Official procedure etc., you can not add the --privileged
option. You can't run systemctl
on the container because you can't pass / sbin / init
to ENTRYPOINT either.
In this article, as mentioned in the title, I will introduce the research process for passing --privileged
and / sbin / init
to docker run
in the container used by VSCode Remote Containers, and the method that was realized.
First of all, when I investigated whether it could be done in a straightforward manner, I found that devcontainer.json in the configuration file has a parameter called "runArgs", and here I can add a parameter for docker run
.
Reference: devcontainer.json reference
However, this method allowed me to add --privileged
but not overwrite --entrypoint
.
When you start the docker container with "Reopen in Container" in VSCode Remote Containers, the argument of docker run
is ** --entrypoint / bin / sh <your own Docker Image> -c echo Container started; trap "exit 0" "15; while sleep 1 & wait $ !; do :; done
** has been added, and it seems that the parameters written in devcontainer.json cannot overwrite this.
You can check what kind of command is flowing at startup from the log that can be seen by pressing the link in the pop-up below that is displayed during startup.
Also, as explained in the following link, the --entrypoint
specified in the argument takes precedence over the ENTRYPOINT and CMD written in the Dockerfile, so even if you write it in the Dockerfile, it cannot be overwritten.
This is the highest priority because VSCode always appends --entrypoint
to docker run
as an argument.
Reference: Build with Dockerfile
Therefore, I decided to follow the steps below.
This procedure builds the Docker image and launches the container. At this time, open the log from the link in the pop-up above, find the following command in the log, and copy it.
docker run -a STDOUT -a STDERR --mount type=bind,source=<The path of your environment>,target=<The path of your environment>,consistency=cached -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=<The path of your environment> --entrypoint /bin/sh <Your own Docker Image> -c echo Container started ; trap "exit 0" 15; while sleep 1 & wait $!; do :; done
The container started in (1) is not --privileged
, so use VSCode to disconnect it once.
Add --privileged
to the copied command and rewrite --entrypoint
.
docker run -a STDOUT -a STDERR --mount type=bind,source=<The path of your environment>,target=<The path of your environment>,consistency=cached -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=<The path of your environment> --privileged --entrypoint /sbin/init <Your own Docker Image>
When executed, the docker container will be started according to the option (3).
You can check the startup status with docker ps
.
Next, attach the container started in (4) to VSCode. First, select "Attach to Running Container" as shown in the image below.
Next, on the screen for selecting a running container, just select the container.
At this point, you can connect to the container from VSCode and open the development environment.
Open the container's terminal with VSCode and try typing systemctl
.
bash-4.2# systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
dev-vda1.device loaded activating tentative /dev/vda1
-.mount loaded active mounted /
dev-hugepages.mount loaded active mounted Huge Pages File System
dev-mqueue.mount loaded active mounted POSIX Message Queue File Syste
etc-hostname.mount loaded active mounted /etc/hostname
etc-hosts.mount loaded active mounted /etc/hosts
(Since it is long below, it is omitted)
In this way, the error is resolved and you can hit it.
By following the steps to connect to the launched container from VSCode in this way, you will be able to run systemctl
on VSCode Remote Containers as well.
This time, it's a bit annoying, but I decided that it would be faster to run up to docker build
with VSCode and find the docker run
command with various options from the VSCode log.
(There may be a better way, but if found, I'll add it)
As the name implies, --privileged
means privilege, so you should use it systematically.