NOTE: Most of the contents of this repository have been migrated to the new devcontainers GitHub org (https://github.com/devcontainers). See https://github.com/devcontainers/template-starter and https://github.com/devcontainers/feature-starter for information on creating your own!
Перейти к файлу
Chuck Lantz d498ea78d8 Add optional node to Java 2020-08-03 20:18:55 +00:00
.github Fix CI script typo 2020-08-03 07:30:51 -07:00
.vscode Ubuntu 18.04 => Ubuntu mutli-variant definition with 20.04 (#345) 2020-05-21 09:09:01 -07:00
build Fix for context processing with "build.context" 2020-08-03 11:25:10 -07:00
container-templates Update templates to use library-scripts 2020-08-03 09:09:54 -07:00
containers Add optional node to Java 2020-08-03 20:18:55 +00:00
repository-containers Reduce comments, clarify whether RUN statement should be modified 2020-07-14 18:32:39 -07:00
script-library Use library-scripts for pre-built images 2020-08-03 09:54:12 -07:00
.editorconfig Fix LF 2019-06-13 20:59:45 +00:00
.gitattributes Fix typo 2019-09-05 12:15:41 -04:00
.gitignore Move "latest" F# to 2.2 2019-10-04 20:31:42 +00:00
CONTRIBUTING.md Typo, clarification 2020-07-23 09:00:37 -07:00
LICENSE Initial commit 2018-11-05 04:52:41 -08:00
README.md Typo 2020-07-23 08:50:29 -07:00
azure-pipelines.yml Enable CG ingestion 2020-01-16 14:51:10 -08:00
cgmanifest.json Automated update for CG 2020-08-03 15:22:29 +00:00
package.json Update package version to 0.130.0 2020-07-30 16:51:08 -07:00
yarn.lock Update lock files to deal with minimist vulnerability 2020-03-19 07:24:27 -07:00

README.md

VS Code Remote Development / Codespaces Container Definitions

Visual Studio Code logo Visual Studio Code Remote Development
Open any folder in a container, on a remote machine, or in WSL and take advantage of VS Code's full feature set. Learn more!
Download now!

A development container is a running Docker container with a well-defined tool/runtime stack and its prerequisites. The VS Code Remote - Containers extension allows you to clone a repository or open any folder mounted into (or already inside) a dev container and take advantage of VS Code's full development feature set. Visual Studio Codespaces and Codespaces in GitHub both use this same concept to quickly create customized, cloud-based development environments accessible from VS Code or the web.

This repository contains a set of dev container definitions to help get you up and running with a containerized environment. The definitions describe the appropriate container image, runtime arguments for starting the container, and VS Code extensions that should be installed. Each provides a container configuration file (devcontainer.json) and other needed files that you can drop into any existing folder as a starting point for containerizing your project.

Note: While many of these definitions are also expected to work in Visual Studio Codespaces / Codespaces in GitHub, a few are not yet working. See here for a list of known issues.

The vscode-remote-try-* repositories may also be of interest if you are looking for complete sample projects.

Adding a definition to a local project

To add a dev container definition in your project, you can either:

  • Add it using VS Code Remote - Containers:

    1. If this is your first time creating a dev container, follow the getting started steps to configure your machine.
    2. Start VS Code and open your project folder.
    3. Press F1 and select either the Remote-Containers: Add Development Container Configuration Files... or Remote-Containers: Reopen Folder in Container commands.
    4. Follow the directions and pick one of the existing development container definitions in this repository from the list. You may need to choose the From a predefined container configuration definition... option if your project has an existing Dockerfile or Docker Compose file.
  • Or manually copy the contents of one of the .devcontainer folders in the containers directory into your project. See the definition's README for details.

Adding a definition to a repository

You can share a customized dev container definition for your project by adding the files under .devcontainer to source control.

Anyone who then opens a local copy of your repo in VS Code will be prompted to reopen the folder in a container, provided they have the Remote - Containers extension installed.

Additionally, if you reference your Git repository when creating a Codespace in Visual Studio Codespaces or Codespaces in GitHub, the container definition will be used.

Your team now has a consistent environment and tool-chain and new contributors or team members can be productive quickly. First-time contributors will require less guidance and there will be fewer issues related to environment setup.

Sample projects

If you want to try a sample project which already has a dev container, check out one of the following repositories:

Contents

  • containers - Contains reusable dev container definitions.
  • container-templates - Contains templates for creating your own container definitions or to contribute back.
  • repository-containers - Dev container definitions for working public source code repositories.

Common Questions

Can I just reuse an existing container image or Docker / Docker Compose configuration?

Yes, if you want to use an existing Dockerfile as a starting point, use the Remote - Containers extension, open a folder, and then run Remote-Containers: Add Development Container Configuration Files... from the Command Palette (F1). You'll be prompted to select a Dockerfile or Docker Compose file and customize from there. If you then commit these files to a Git repository, you can use it with VS Codespaces or Codespaces in GitHub as well. If you prefer, you can also start up the container manually and attach to it.

What is the goal of devcontainer.json?

A devcontainer.json file is similar to launch.json for debugging, but designed to launch (or attach to) a development container instead. At its simplest, all you need is a .devcontainer/devcontainer.json file in your project that references an image, Dockerfile, or docker-compose.yml, and a few properties. You can adapt it for use in a wide variety of situations.

Why do Dockerfiles in this repo use RUN statements with commands separated by &&?

Each RUN statement creates a Docker image "layer". If one RUN statement adds temporary contents, these contents remain in this layer in the image even if they are deleted in a subsequent RUN. This means the image takes more storage locally and results in slower image download times if you publish the image to a registry. You can resolve this problem by using a RUN statement that includes any clean up steps (separated by &&) after a given operation. See CONTRIBUTING.md for more tips.

Contributing and feedback

Have a question or feedback?

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

License

Copyright (c) Microsoft Corporation. All rights reserved.
Licensed under the MIT License. See LICENSE.