introduction

Présentation de vos propres paramètres pour les conteneurs distants, une extension de Dieu VS Code Exemple officiel est ouvert au public, mais comme il est difficile à utiliser tel quel, je présenterai les paramètres modifiés pour vous faciliter l'utilisation. De plus, tous les fichiers de paramètres introduits dans cet article sont publiés dans le référentiel suivant (y compris ceux des environnements non introduits) https://github.com/sabure500/remote-container-sample

Aussi, j'ai pensé qu'il serait bon d'utiliser des conteneurs distants, donc je joue avec les paramètres pour le rendre plus facile à utiliser, mais puisque cet article "veut créer" l'environnement local le plus fort, il y a une idée que c'est mieux. Je vous serais reconnaissant si vous pouviez me dire

Qu'est-ce que les conteneurs distants VSCode?

C'est une extension de VSCode qui vous permet d'ouvrir et de travailler en VSCode à l'intérieur d'un conteneur. Étant donné que vous pouvez ouvrir VS Code directement dans le conteneur et travailler, vous pouvez bac à sable l'environnement de développement et le développer dans un endroit qui n'affecte pas du tout la machine locale. Il existe d'autres séries d'extensions similaires, "Remote SSH" et "Remote WSL", qui vous permettront d'ouvrir VS Code et de travailler respectivement dans la destination SSH ou WSL. Veuillez vous référer au Site officiel pour plus de détails sur chacun.

Installation

Les deux installations suivantes sont requises pour créer un environnement de développement avec VSCode Remote Containers Inversement, si vous avez les deux suivants, vous pouvez créer un environnement tel que Node, python, Go, Java etc. sans rien mettre d'autre sur la machine locale.

Visual Studia Code
Docker Desktop for Windows or Mac

Docker Desktop for Windows or Mac Téléchargez le programme d'installation à partir de la page officielle ci-dessous https://www.docker.com/products/docker-desktop

Visual Studio Code

Installation de VSCode lui-même

Téléchargez depuis la page officielle ci-dessous https://code.visualstudio.com/docs

Introduction de conteneurs distants

Étant donné que Remote Containers est une extension normale, vous pouvez l'installer à partir de la liste en le démarrant après avoir installé VS Code, en sélectionnant l'extension dans l'onglet de gauche et en recherchant "Remote Container". Vous pouvez également l'installer à partir de la page de marché ci-dessous. https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

Lancer des conteneurs distants

Après avoir démarré l'emplacement où se trouve le fichier de paramètres de conteneurs distants introduit ultérieurement en tant qu'espace de travail, cliquez sur la marque verte "> <" en bas à gauche de VS Code et sélectionnez "Remote-Containers: Reopen in Container".

Introduction des paramètres de construction de l'environnement

La construction de l'environnement dans les conteneurs distants est effectuée en plaçant devcontainer.json, un fichier de paramètres pour les conteneurs distants et un fichier Docker (ou docker-compose.yaml, etc.) dans le répertoire .devcontainer. Je présenterai les paramètres de chaque environnement

GoogleCloudSDK J'utilise également des conteneurs distants lorsque j'utilise les commandes du SDK Google Cloud dans mon environnement local. Le fichier de paramètres est publié ci-dessous et tout le monde peut utiliser immédiatement le même environnement du SDK Google Cloud en l'utilisant tel quel. Décrire les paramètres de création de l'environnement La structure générale des répertoires est la suivante

.
├ .devcontainer
    ├ devcontainer.json
    ├ Dockerfile
    ├ .config/fish/config.fish
    └ .local/share/fish/fish_history

Dockerfile Fichier de création d'un conteneur réellement utilisé comme environnement de développement Donnez d'abord une vue d'ensemble, puis expliquez chaque ligne

`Dockerfile`


FROM google/cloud-sdk:297.0.1-alpine

# ===== common area =====
RUN apk add --no-cache fish git openssh curl
COPY .config/fish/config.fish /root/.config/fish/config.fish
# =======================

# ===== kubernetes resource install =====
ENV KUBECTL_VERSION 1.18.4
ENV KUSTOMIZE_VERSION 3.1.0
ENV ARGOCD_VERSION 1.5.2
RUN curl -sfL -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VERSION}/bin/linux/amd64/kubectl \
    && curl -sfL -o /usr/local/bin/kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v${KUSTOMIZE_VERSION}/kustomize_${KUSTOMIZE_VERSION}_linux_amd64 \
    && curl -sfL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v${ARGOCD_VERSION}/argocd-linux-amd64 \
    && chmod +x /usr/local/bin/kubectl /usr/local/bin/kustomize /usr/local/bin/argocd
# =======================

Image de base
```
FROM google/cloud-sdk:297.0.1-alpine
```

L'image de base utilise google / cloud-sdk: 297.0.1-alpine

Installation de packages à usage général utilisés dans l'environnement
```
RUN apk add --no-cache fish git openssh curl
```

Comme l'image de base est alpine, utilisez apk pour installer le package que vous souhaitez utiliser dans l'environnement de développement. Ici, fish, git, ssh, curl sont inclus, mais si vous souhaitez utiliser bash, vous pouvez le personnaliser en introduisant bash au lieu de fish.

Paramètres pour la coquille de poisson

COPY .config/fish/config.fish /root/.config/fish/config.fish

set normal (set_color normal)
set magenta (set_color magenta)
set yellow (set_color yellow)
set green (set_color green)
set red (set_color red)
set gray (set_color -o black)

# Fish git prompt
set __fish_git_prompt_showdirtystate 'yes'
set __fish_git_prompt_showstashstate 'yes'
set __fish_git_prompt_showuntrackedfiles 'yes'
set __fish_git_prompt_showupstream 'yes'
set __fish_git_prompt_color_branch yellow
set __fish_git_prompt_color_upstream_ahead green
set __fish_git_prompt_color_upstream_behind red

# Status Chars
set __fish_git_prompt_char_dirtystate '⚡'
set __fish_git_prompt_char_stagedstate '→'
set __fish_git_prompt_char_untrackedfiles '☡'
set __fish_git_prompt_char_stashstate '↩'
set __fish_git_prompt_char_upstream_ahead '+'
set __fish_git_prompt_char_upstream_behind '-'

function fish_prompt
  set last_status $status

  set_color $fish_color_cwd
  printf '%s' (prompt_pwd)
  set_color normal

  printf '%s ' (__fish_git_prompt)

  set_color normal
end

Utilisez une coquille de poisson comme coquille de travail Comme il est difficile à utiliser avec les paramètres par défaut, copiez le fichier de paramètres pour modifier l'invite, comme afficher la branche de Git et le placer sur le conteneur Je me réfère au billet de blog suivant pour le fichier de réglage du poisson. https://www.martinklepsch.org/posts/git-prompt-for-fish-shell.html

Installation des commandes utilisées avec Google Cloud SDk

# ===== kubernetes resource install =====
ENV KUBECTL_VERSION 1.18.4
ENV KUSTOMIZE_VERSION 3.1.0
ENV ARGOCD_VERSION 1.5.2
RUN curl -sfL -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VERSION}/bin/linux/amd64/kubectl \
    && curl -sfL -o /usr/local/bin/kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v${KUSTOMIZE_VERSION}/kustomize_${KUSTOMIZE_VERSION}_linux_amd64 \
    && curl -sfL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v${ARGOCD_VERSION}/argocd-linux-amd64 \
    && chmod +x /usr/local/bin/kubectl /usr/local/bin/kustomize /usr/local/bin/argocd
# =======================

Étant donné que GKE est souvent utilisé exclusivement en tant que ressource GCP, les ressources associées à Kubernetes sont installées dans le conteneur.

devcontainer.json Fichier de configuration lors de l'ouverture d'un conteneur à partir de VS Code Décrivez le Dockerfile à utiliser, la fonction d'extension lors de l'utilisation de VSCode sur le conteneur, le volume de l'environnement local, etc. Consultez la référence officielle (https://code.visualstudio.com/docs/remote/containers#_devcontainerjson-reference) pour plus de détails sur ce que vous pouvez faire d'autre. Donnez d'abord une vue d'ensemble, puis expliquez chaque ligne

`devcontainer.json`


{
    "name": "Google Cloud SDK Remote-Container",
    "build" : {
        "dockerfile": "Dockerfile"
    },
    "settings": {
        "terminal.integrated.shell.linux": "/usr/bin/fish",
    },
    "extensions": [
        "alefragnani.bookmarks",
        "mhutchie.git-graph",
        "redhat.vscode-yaml",
        "zainchen.json"
    ],
    "mounts": [
        "source=${localEnv:HOME}/.ssh/,target=/root/.ssh/,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.gitconfig,target=/root/.gitconfig,type=bind,consistency=cached",
        "source=${localWorkspaceFolder}/.devcontainer/.local/share/fish/fish_history,target=/root/.local/share/fish/fish_history,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.config/gcloud/,target=/root/.config/gcloud/,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.kube/,target=/root/.kube/,type=bind,consistency=cached",
    ],
}

Image de conteneur à utiliser

    "build" : {
        "dockerfile": "Dockerfile"
    },

Spécifiez l'emplacement du Dockerfile Comme indiqué dans la structure de répertoires au début, puisqu'il se trouve dans le même répertoire, il est écrit comme "Dockerfile" tel quel

Paramètres de code VS spécifiques au conteneur

    "settings": {
        "terminal.integrated.shell.linux": "/usr/bin/fish",
    },

Décrivez les paramètres VS Code que vous souhaitez définir indépendamment sur le conteneur Par exemple, les paramètres d'extensions qui ne sont pas installées localement mais qui sont installées sur le conteneur, etc. Concernant la description des paramètres, ce qui est écrit localement est hérité sur le conteneur sans le réécrire sur devcontainer.json Ici, sur le conteneur, la coque du terminal décrit uniquement l'utilisation du poisson.

Réglage de la fonction d'extension utilisée par VS Code sur l'environnement du conteneur

    "extensions": [
        "alefragnani.bookmarks",
        "mhutchie.git-graph",
        "redhat.vscode-yaml",
        "zainchen.json"
    ],

Décrivez l'extension que vous souhaitez utiliser dans l'environnement du conteneur Concernant la fonction d'extension, contrairement au paramétrage des paramètres, même s'il est installé localement, celui qui n'est pas écrit sur devcontainer.json ne sera pas installé sur le conteneur.

Monter à partir de l'environnement local

    "mounts": [ 
        "source=${localEnv:HOME}/.ssh/,target=/root/.ssh/,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.gitconfig,target=/root/.gitconfig,type=bind,consistency=cached",
        "source=${localWorkspaceFolder}/.devcontainer/.local/share/fish/fish_history,target=/root/.local/share/fish/fish_history,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.config/gcloud/,target=/root/.config/gcloud/,type=bind,consistency=cached",
        "source=${localEnv:HOME}/.kube/,target=/root/.kube/,type=bind,consistency=cached",
    ],

Montez un fichier que vous souhaitez utiliser dans votre environnement local ou que vous ne souhaitez pas effacer lorsque vous redémarrez le conteneur "source =" spécifie le chemin local, "target =" spécifie le chemin sur le conteneur De plus, en écrivant $ {localEnv: XXXX}, vous pouvez utiliser la variable d'environnement "XXXX" sur l'environnement local. Ici, nous avons 5 répertoires de fichiers montés

paramètres ssh Étant donné que les paramètres ssh sont utilisés à partir de plusieurs environnements, montez et utilisez à partir de l'environnement local.
paramètres git Étant donné que les paramètres git sont également utilisés à partir de plusieurs environnements, montez et utilisez à partir de l'environnement local
Historique des opérations de pêche C'est un point, et si vous travaillez sur un conteneur, si vous arrêtez le conteneur, tout l'historique des opérations sera supprimé. Ce n'était pas pratique pour moi d'utiliser l'historique des commandes de l'historique passé en utilisant le curseur ↑ etc. lorsque je travaillais, donc ce n'était pas pratique de l'effacer, alors montez-le sur les espaces de travail pour qu'il ne disparaisse pas
paramètres gcp Comme il est gênant si les informations de connexion GCP, etc. disparaissent à chaque fois, montez-les à partir de
Paramètres kubectl De même, si l'enregistrement du cluster de GKE, etc. disparaît à chaque fois, cela pose problème, alors montez-le localement

Java J'utilise un environnement avec OpenJDK + Wildfly + maven + Gradle comme environnement pour Java. Cet environnement Java sera également introduit en se concentrant sur les différences par rapport à l'environnement SDK Google Cloud présenté ci-dessus. La structure générale des répertoires est la suivante

.
├ .devcontainer
    ├ devcontainer.json
    ├ docker-compose.yaml
    ├ Dockerfile
    ├ .m2/
    ├ .gradle/
    ├ .config/fish/config.fish
    └ .local/share/fish/fish_history

docker-compose L'environnement Java utilise docker-compose au lieu de Dockerfile pour utiliser le réseau de Docker pour se connecter à l'environnement DB qui est configuré dans un conteneur séparé. Donnez d'abord une vue d'ensemble, puis expliquez chaque ligne

`docker-compose.yaml`


version: "3"
services:
  jdk-wildfly-maven:
    build: .
    ports:
      - "8080:8080"
      - "9990:9990"
    command: /bin/sh -c "while sleep 1000; do :; done"
    volumes: 
      - $HOME/.ssh:/root/.ssh
      - $HOME/.gitconfig:/root/.gitconfig
      - .local/share/fish/fish_history:/root/.local/share/fish/fish_history
      - ..:/workspace
      - ./jboss_home/configuration/standalone.xml:/opt/wildfly/standalone/configuration/standalone.xml
      - .m2:/root/.m2
      - .gradle:/root/.gradle
    networks:
      - remote-container_common-network
networks: 
  remote-container_common-network:
    external: true

Transférer de l'environnement local à l'environnement du conteneur
```
ports:
  - "8080:8080"
  - "9990:9990"
```

Les ports par défaut 8080 et 9990 de Wildfly seront accessibles sur le conteneur lorsque le port cible est accédé dans l'environnement local.

Écraser la commande par défaut du conteneur

command: /bin/sh -c "while sleep 1000; do :; done"

Remplacez la commande par défaut afin que le conteneur ne s'arrête pas si la commande par défaut au démarrage du conteneur échoue ou s'arrête La commande décrite ici est le paramètre par défaut des conteneurs distants lorsque docker-compose n'est pas utilisé. Lors de l'utilisation de docker-compose, il est nécessaire de l'écrire explicitement

Monter à partir de l'environnement local

volumes: 
  - $HOME/.ssh:/root/.ssh
  - $HOME/.gitconfig:/root/.gitconfig
  - .local/share/fish/fish_history:/root/.local/share/fish/fish_history
  - ..:/workspace
  - ./jboss_home/configuration/standalone.xml:/opt/wildfly/standalone/configuration/standalone.xml
  - .m2:/root/.m2
  - .gradle:/root/.gradle

Les montages de l'environnement local doivent être écrits dans docker-compose.yaml au lieu de devcontainer.json La différence avec le cas de Dockerfile est que l'espace de travail lui-même est explicitement spécifié et monté comme écrit «..: / workspace». Les paramètres et référentiels Gradle et Maven sont montés avec ".m2: /root/.m2" et ".gradle: /root/.gradle" comme paramètres uniques à l'environnement java. Comme il n'est utilisé que dans cet environnement, il est monté directement sur le WorkSpace au lieu de la page d'accueil de l'utilisateur ($ HOME). De plus, en ce qui concerne le fichier de configuration Wildfly standalone.xml, les paramètres de la source de données, etc. peuvent toujours être modifiés pendant le développement, et c'est un problème s'il est supprimé chaque fois que le conteneur est redémarré, donc "./jboss_home/configuration/" Il est monté sous la forme standalone.xml: /opt/wildfly/standalone/configuration/standalone.xml "

Utilisation du réseau docker

    networks:
      - remote-container_common-network
networks: 
  remote-container_common-network:
    external: true

Java est utilisé comme environnement d'exécution d'application, je souhaite donc me connecter à DB Quant à DB, il démarre en tant que conteneur dans l'environnement local, alors créez un réseau Docker et utilisez-le pour vous connecter à d'autres conteneurs. Par conséquent, pour utiliser cet environnement, il est nécessaire de créer un réseau à l'avance avec la commande suivante.

```bash
docker network create --driver bridge remote-container_common-network
```

Dockerfile Dockerfile qui crée l'environnement OpenJDK + Wildfly + maven + Gradle spécifié dans docker-compose.yaml En tant qu'image de base, l'image officielle de JBoss "jboss / wildfly" est grande et difficile à utiliser, et je voulais utiliser une image alpine, je l'ai donc créée sur Adoptopenjdk.

`Dockerfile`


FROM adoptopenjdk/openjdk11:alpine-slim

# ===== common area =====
ENV WORKSPACE_DIR "/workspace"
RUN apk add --no-cache fish git openssh curl wget tar unzip\
    && mkdir -p $WORKSPACE_DIR
COPY .config/fish/config.fish /root/.config/fish/config.fish
# =======================

# ==== wildfly install =====
ENV JBOSS_HOME "/opt/wildfly"
ENV WILDFLY_VERSION "20.0.0.Final"

RUN wget -P /opt http://download.jboss.org/wildfly/${WILDFLY_VERSION}/wildfly-${WILDFLY_VERSION}.tar.gz \
    && tar -zxvf /opt/wildfly-${WILDFLY_VERSION}.tar.gz -C /opt \
    && rm /opt/wildfly-${WILDFLY_VERSION}.tar.gz \
    && mv /opt/wildfly-${WILDFLY_VERSION} ${JBOSS_HOME} \
    && $JBOSS_HOME/bin/add-user.sh admin admin --silent
# =======================

# ==== maven install =====
ENV MAVEN_HOME "/opt/maven"
ENV MAVEN_VERSION 3.6.3
ENV PATH "$PATH:$MAVEN_HOME/bin"
ENV MAVEN_CONFIG "$HOME/.m2"
RUN curl -fsSL -o /opt/apache-maven-${MAVEN_VERSION}-bin.tar.gz http://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz \
    && tar -zxvf /opt/apache-maven-${MAVEN_VERSION}-bin.tar.gz -C /opt \
    && rm /opt/apache-maven-${MAVEN_VERSION}-bin.tar.gz \
    && mv /opt/apache-maven-${MAVEN_VERSION} /opt/maven
# =======================

# ==== gradle install ====
ENV GRADLE_HOME "/opt/gradle"
ENV GRADLE_VERSION 6.5
ENV PATH "$PATH:$GRADLE_HOME/bin"
RUN curl -fsSL -o /opt/gradle-${GRADLE_VERSION}-bin.zip https://downloads.gradle-dn.com/distributions/gradle-${GRADLE_VERSION}-bin.zip \
    && unzip -d /opt /opt/gradle-${GRADLE_VERSION}-bin.zip \
    && rm /opt/gradle-${GRADLE_VERSION}-bin.zip \
    && mv /opt/gradle-${GRADLE_VERSION} /opt/gradle
# =======================

devcontainer.json Les paramètres par défaut et les paramètres disponibles de devcontainer.json sont différents selon que vous utilisez Dockerfile ou docker-compose (par exemple, le montage n'est pas efficace même si vous l'écrivez dans devcontainer.json, docker-compose Devra être décrit dans) Voir Référence officielle pour plus de détails.

`devcontainer.json`


{
    "name": "JDK&Wildfly&Maven&Gradle Remote-Container",
    "dockerComposeFile": "docker-compose.yaml",
    "service" : "jdk-wildfly-maven",
    "workspaceFolder": "/workspace",
    "settings": {
        "terminal.integrated.shell.linux": "/usr/bin/fish",
        "java.home": "/opt/java/openjdk",
        "maven.executable.preferMavenWrapper": false,
        "maven.executable.path": "/opt/maven/bin",
        "maven.terminal.useJavaHome": true,
        "java.jdt.ls.vmargs": "-noverify -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication -javaagent:\"/root/.vscode/extensions/gabrielbb.vscode-lombok-1.0.1/server/lombok.jar\"",
    },
    "extensions": [
        "alefragnani.bookmarks",
        "mhutchie.git-graph",
        "vscjava.vscode-java-pack",
        "shengchen.vscode-checkstyle",
        "gabrielbb.vscode-lombok",
        "naco-siren.gradle-langua"
    ],
    "shutdownAction": "stopCompose"
}

Images et services à utiliser

    "dockerComposeFile": "docker-compose.yaml",
    "service" : "jdk-wildfly-maven",

Lorsque vous utilisez docker-compose, utilisez "dockerComposeFile" et spécifiez l'emplacement de docker-compose.yaml. De plus, dans le cas de docker-compose, il est possible que plusieurs conteneurs soient en cours d'exécution, spécifiez donc quel conteneur ouvrir VS Code avec le service.

Spécifiez le dossier de l'espace de travail
```
    "workspaceFolder": "/workspace",
```

Contrairement au cas de Dockerfile, dans le cas de docker-compose, il est nécessaire de spécifier explicitement l'emplacement de l'espace de travail à monter. Dans ce cas, vous ne pouvez pas spécifier un répertoire qui n'existe pas, alors créez d'abord un répertoire tel que / workspace sur le Dockerfile.

paramètres spécifiques à java

    "settings": {
        "terminal.integrated.shell.linux": "/usr/bin/fish",
        "java.home": "/opt/java/openjdk",
        "maven.executable.preferMavenWrapper": false,
        "maven.executable.path": "/opt/maven/bin",
        "maven.terminal.useJavaHome": true,
        "java.jdt.ls.vmargs": "-noverify -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication -javaagent:\"/root/.vscode/extensions/gabrielbb.vscode-lombok-1.0.1/server/lombok.jar\"",
    },
    "extensions": [
        "alefragnani.bookmarks",
        "mhutchie.git-graph",
        "vscjava.vscode-java-pack",
        "shengchen.vscode-checkstyle",
        "gabrielbb.vscode-lombok",
        "naco-siren.gradle-langua"
    ],

Bien qu'elle ne soit pas incluse dans VS Code de l'environnement local, l'extension que vous souhaitez utiliser est spécifiée dans l'environnement Java. Il décrit également le contenu des paramètres que vous souhaitez appliquer uniquement sur le conteneur qui prend en charge l'extension.

MySQL Créer un DB à utiliser à partir de Java créé au chapitre précédent dans un conteneur Cela n'a pas beaucoup de sens de créer cet environnement avec des conteneurs distants, mais dans un souci d'unification, il est créé avec des conteneurs distants. Il n'y a aucun problème même si vous le démarrez simplement avec docker-compose. Avant de créer cet environnement pour vous connecter à d'autres conteneurs (environnement Java), créez un réseau Docker avec la commande suivante (Si vous l'avez déjà, il n'y a pas de problème)

docker network create --driver bridge remote-container_common-network

La structure complète des répertoires et le fichier de paramètres sont les suivants

.
├ .devcontainer
│  ├ devcontainer.json
│  ├ docker-compose.yaml
│  └ my.cnf
└ db

`docker-compose.yaml`


version: "3"
services:
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: pass
      TZ: "Asia/Tokyo"
    ports:
      - "3306:3306"
    volumes: 
      - ../db/data:/var/lib/mysql
      - ./my.cnf:/etc/mysql/conf.d/my.cnf
    networks:
      - remote-container_common-network
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      PMA_ARBITRARY: 1
    ports:
      - 3307:80
    depends_on:
      - mysql
    networks:
      - remote-container_common-network
networks: 
  remote-container_common-network:
    external: true

`devcontainer.json`


{
    "name": "MySQL Remote-Container",
    "dockerComposeFile": "docker-compose.yaml",
    "service" : "mysql",
    "workspaceFolder": "/root",
    "settings": {
        "terminal.integrated.shell.linux": "/bin/bash",
    },
    "extensions": [],
    "shutdownAction": "stopCompose"
}

Supplément

Cette fois, je construis mon propre environnement local, donc je fais les paramètres de conteneurs distants en supposant que plusieurs applications seront gérées dans un environnement. En d'autres termes, ce qui suit

.
├ .devcontainer
├ application1
│  ├ .git
│  └ source code
├ application2
│  ├ .git
│  └ source code

Il est préférable de créer un paramètre de conteneurs distants pour une application au lieu de la configuration ci-dessus, car cela présente l'avantage que l'environnement de développement de cette application peut être géré sur git et que tous les développeurs peuvent utiliser le même environnement. Je pense que le En d'autres termes, ce qui suit

.
├ application1
│  ├ .devcontainer
│  ├ .git
│  └ source code
├ application2
│  ├ .devcontainer
│  ├ .git
│  └ source code

Cependant, dans le cas d'une telle méthode de gestion, il est préférable de bien consulter l'équipe et de décider quoi faire car une guerre peut survenir si vous insérez le cadre d'origine du poisson tel qu'introduit cette fois.

Avantages et inconvénients des conteneurs distants VSCode

Mettez fin aux avantages et inconvénients que vous pensiez utiliser à la fin

mérite

Votre environnement local ne se salira pas C'est génial que vous n'ayez rien à mettre de plus si vous avez VS Code et Docker.
Les paramètres de l'environnement de développement peuvent également être partagés entre les développeurs d'applications Puisqu'ils partagent le même environnement de développement, il est possible d'éliminer l'occurrence d'événements tels que le mouvement et l'immobilité en fonction de la personne. De plus, étant donné que le Dockerfile est essentiel en premier lieu, si l'environnement de production est également créé avec le Dockerfile, la différence entre le développement et la production peut être réduite autant que possible. Cependant, il est préférable de créer séparément le Dockerfile pour l'environnement de développement et le Dockerfile pour l'environnement de production. (Bien que cela ne soit pas présenté dans cet article, il est également possible d'utiliser la fonction d'extension de Remote Containers pour écraser uniquement la partie d'introduction du package nécessaire au développement basé sur le Dockerfile de l'environnement de production et l'utiliser dans l'environnement de développement)
Les images créées dans l'environnement de développement peuvent être réutilisées dans CI / CD Lors de la vérification à l'aide d'outils dans l'environnement de développement, la même vérification est souvent effectuée pour CI / CD. À ce stade, l'outil CICD actuel prend souvent en charge l'exécution de JOB sur le conteneur, de sorte que le conteneur créé lors de la création de l'environnement de développement peut être utilisé tel quel ou seulement partiellement amélioré.

Démérite

Ne peut être utilisé qu'avec VS Code Puisqu'il s'agit d'une extension de VSCode, il ne peut pas être utilisé avec d'autres IDE. C'est une fonctionnalité très utile, alors peut-être que vous pouvez faire la même chose avec d'autres IDE simplement en ne le sachant pas ...
Toutes les extensions ne sont pas disponibles sur le conteneur Certaines extensions ne sont pas disponibles dans VS Code sur les conteneurs lancés avec des conteneurs distants
Vous ne pouvez pas créer un environnement à moins de comprendre les outils à utiliser dans une certaine mesure. Il est essentiel de créer un Dockerfile, et vous devez comprendre et savoir où le fichier de configuration de cet outil sera développé et ce qui devrait être monté et ce qui ne devrait pas l'être. Cependant, si vous souhaitez utiliser le fichier de paramètres créé par une autre personne tel quel au lieu de créer vos propres paramètres, vous pouvez l'utiliser sans rien savoir de plus qu'avant.
Il est difficile de savoir quelle quantité peut être emballée dans un environnement de conteneur Celui introduit cette fois-ci est divisé en Java et Google Cloud SDK, mais si vous souhaitez le faire, vous pouvez le subdiviser davantage ou, au contraire, le combiner en un seul. Il est facile de comprendre si vous définissez le paramètre de conteneur distant pour chaque application, mais si vous le définissez comme votre propre environnement local comme le SDK Google Cloud, la limite est difficile et je n'ai pas encore de réponse standard

référence

Exemple officiel de conteneurs distants VSCode: https://github.com/Microsoft/vscode-dev-containers
Document officiel des conteneurs distants VSCode: https://code.visualstudio.com/docs/remote/remote-overview
Blog de référence pour les paramètres d'invite de poisson: https://www.martinklepsch.org/posts/git-prompt-for-fish-shell.html

[JAVA] Je souhaite créer l'environnement de développement local le plus solide à l'aide de conteneurs distants VSCode

introduction

Qu'est-ce que les conteneurs distants VSCode?

Installation

Installation de VSCode lui-même

Introduction de conteneurs distants

Lancer des conteneurs distants

Introduction des paramètres de construction de l'environnement

Dockerfile

devcontainer.json

docker-compose.yaml

Dockerfile

devcontainer.json

docker-compose.yaml

devcontainer.json

Supplément

Avantages et inconvénients des conteneurs distants VSCode

mérite

Démérite

référence

`Dockerfile`

`devcontainer.json`

`docker-compose.yaml`

`Dockerfile`

`devcontainer.json`

`docker-compose.yaml`

`devcontainer.json`