How to develop in a container with --privileged and / sbin / init passed in VSCode Remote Containers

Introduction

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.

• When executed, "Failed to get D-Bus connection: Operation not permitted" will be displayed and an error will occur.
• The mechanism around this has already been talked about in articles such as "Starting services using systemd in the Docker container of CentOS 7". Therefore, I will omit it in this article.

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.

0. Preface: Survey

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

1. Realization procedure

Therefore, I decided to follow the steps below.

(1) First, execute "Reopen in Container" according to the procedure.

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

(2) Disconnect from the container with VSCode

The container started in (1) is not --privileged, so use VSCode to disconnect it once.

(3) Partially change the copied command

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>

(4) Execute the above command in the local terminal

When executed, the docker container will be started according to the option (3). You can check the startup status with docker ps.

(5) Execute "Attach to Running Container" with VS Code

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.

2. Operation check

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.

Finally

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.

References

• VSCode Remote Containers * Official
• devcontainer.json reference * Official
• Development environment with Docker and Remote Containers is too great * The procedure to start with Dockerfile is posted.
• VSCode Remote Container is good
• I want to create the strongest local development environment using VSCode Remote Containers
• Start a service using systemd inside a Docker container on CentOS 7
• Build with Dockerfile