[DOCKER] Comment développer dans un conteneur avec --privileged et / sbin / init passés dans VSCode Remote Containers
introduction
Lors du développement avec VSCode Remote Containers, si vous écrivez un Dockerfile et dites "Rouvrir dans le conteneur", le conteneur Docker démarrera, mais à ce moment, VSCode exécutera docker run.
Par conséquent, si vous le démarrez sans vous soucier de quoi que ce soit et en vous référant à la Procédure officielle etc., vous ne pouvez pas ajouter l'option --privileged. , Systemctl ne peut pas être exécuté sur le conteneur car / sbin / init ne peut pas être passé à ENTRYPOINT.
- Lors de l'exécution, "Impossible d'obtenir la connexion D-Bus: opération non autorisée" s'affiche et une erreur se produit.
- Le mécanisme autour de cela a déjà été évoqué dans des articles tels que "Démarrage des services en utilisant systemd dans le conteneur Docker de CentOS 7". Par conséquent, je vais l'omettre dans cet article.
Comme mentionné dans le titre, cet article présentera le processus de recherche pour passer --privileged et / sbin / init à docker run dans le conteneur utilisé par VSCode Remote Containers, et la méthode pour le réaliser.
0. Préface: Enquête
Tout d'abord, lorsque j'ai vérifié si cela pouvait être fait de manière simple, j'ai trouvé que devcontainer.json dans le fichier de configuration avait un paramètre appelé "runArgs", et ici je peux ajouter un paramètre pour docker run.
Référence: référence devcontainer.json
Cependant, cette méthode m'a permis d'ajouter --privileged mais pas de remplacer --entrypoint.
Lorsque vous démarrez le conteneur Docker avec "Reopen in Container" avec VSCode Remote Containers, l'argument de docker run est ** --entrypoint / bin / sh <your own Docker Image> -c echo Container started; trap "exit 0" "15; while sleep 1 & wait $!; Do:; done ** a été ajouté, et il semble que les paramètres écrits dans devcontainer.json ne peuvent pas écraser cela.
Vous pouvez voir quel type de commande circule au démarrage à partir du journal qui peut être vu en appuyant sur le lien dans la fenêtre contextuelle ci-dessous qui s'affiche au démarrage.
De plus, comme expliqué dans le lien suivant, le --entrypoint spécifié dans l'argument a la priorité sur le ENTRYPOINT et le CMD écrits dans le Dockerfile, donc même si vous l'écrivez dans le Dockerfile, il ne peut pas être écrasé.
Il s'agit de la priorité la plus élevée car VSCode ajoute toujours «--entrypoint» à «docker run» comme argument.
Référence: Build with Dockerfile
1. Procédure de réalisation
Par conséquent, j'ai décidé de suivre les étapes ci-dessous.
(1) Tout d'abord, exécutez "Reopen in Container" selon la procédure.
Cette procédure crée l'image Docker et lance le conteneur. À ce stade, ouvrez le journal à partir du lien dans la fenêtre contextuelle ci-dessus, recherchez la commande suivante dans le journal et copiez-le.
docker run -a STDOUT -a STDERR --mount type=bind,source=<Chemin de votre environnement>,target=<Chemin de votre environnement>,consistency=cached -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=<Chemin de votre environnement> --entrypoint /bin/sh <Votre propre image Docker> -c echo Container started ; trap "exit 0" 15; while sleep 1 & wait $!; do :; done
(2) Déconnectez-vous du conteneur avec VSCode
Le conteneur démarré dans (1) n'est pas --privileged, utilisez donc VSCode pour le déconnecter une fois.
(3) Modifier partiellement la commande copiée
Ajoutez --privileged à la commande copiée et réécrivez --entrypoint.
docker run -a STDOUT -a STDERR --mount type=bind,source=<Chemin de votre environnement>,target=<Chemin de votre environnement>,consistency=cached -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=<Chemin de votre environnement> --privileged --entrypoint /sbin/init <Votre propre image Docker>
(4) Exécutez la commande ci-dessus dans le terminal local
Une fois exécuté, le conteneur docker sera démarré selon l'option (3).
Vous pouvez vérifier l'état de démarrage avec docker ps.
(5) Exécutez "Attach to Running Container" avec VS Code
Ensuite, attachez le conteneur démarré dans (4) à VSCode. Tout d'abord, sélectionnez «Joindre au conteneur en cours d'exécution» comme indiqué dans l'image ci-dessous.
Ensuite, sur l'écran de sélection d'un conteneur en cours d'exécution, sélectionnez simplement le conteneur.
À ce stade, vous pouvez vous connecter au conteneur à partir de VSCode et ouvrir l'environnement de développement.
2. Contrôle de fonctionnement
Ouvrez le terminal du conteneur avec VSCode et tapez 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
(Puisqu'il est long en dessous, il est omis)
De cette façon, l'erreur est résolue et vous pouvez la frapper.
finalement
En suivant les étapes pour vous connecter au conteneur démarré à partir de VSCode de cette manière, vous pouvez également exécuter systemctl sur VSCode Remote Containers.
Cette fois, c'est un peu ennuyeux, mais j'ai décidé qu'il serait plus rapide d'exécuter docker build avec VSCode et de trouver la commande docker run avec diverses options du journal VSCode.
(Il y a peut-être un meilleur moyen, mais s'il est trouvé, je l'ajouterai)
Comme son nom l'indique, «--privileged» signifie privilège, vous devez donc l'utiliser systématiquement.
Références
- Conteneurs distants VSCode * Officiel
- devcontainer.json reference * Officiel
- L'environnement de développement avec Docker et Remote Containers est trop grand * La procédure pour démarrer avec Dockerfile est publiée.
- VSCode Remote Container is good
- Je souhaite créer l'environnement de développement local le plus puissant à l'aide de conteneurs distants VSCode
- Démarrez le service en utilisant systemd dans le conteneur Docker de CentOS 7
- Construire avec Dockerfile