Today I'm going to show you how dev containers can
save you so much time configuring your development environment.
As developers, most of us want to spend our time
actually coding, but often you're spending time trying to figure
out what dependency you need to install in order for
your code to work.
Or you're on a call with your teammate who has
a Mac, and you're trying to figure out why the
code doesn't work on their machine, but it works on
your Windows.
Or you're onboarding onto a new project and you're reading
pages and pages and pages of documentation, trying to figure
out what you need to install in order for the
code to run.
These are all common scenarios that dev containers can really
help with.
Dev containers are full-featured development environments.
A dev container houses its own app and dependencies such
as the required tools, libraries and runtimes needed to run
the code.
In VS Code,
you can use dev containers with the Dev Containers extension.
This container has your technology stack and dependencies already set
up for you.
When you open your project in the dev container, your
code will just work without downloading anything on your local
machine.
And the best part is, when connected to a dev
container, your developer experience is exactly the same as if
you opened the project locally in VS Code.
So let's dive into a demo now.
Dev containers work by using a docker container, so you
will need to have Docker installed.
You can either install docker locally, on a remote environment,
or use other Docker compliant CLIs. For simpler configurations like
what I'm about to show,
you really don't need to do anything with docker other
than have it up and running.
I'm going to use this vscode-remote-try-python
repo. To try it out yourself,
you can either clone this repo, or in VS Code,
you can run the Try a Dev Container Sample command
where you will see a list of sample repos for
different languages. To follow along, you'll select the Python repo.
Let's just try to run this code not in a
dev container.
This would be what traditional local development looks like, where
you pull down someone else's code and just hope it
works on your machine.
So when I go to run it, I immediately get
an error that the debug type Python is not supported.
This particular error is prompting me to install the Python
extension, and if we look at my extensions, I only
have the dev containers and GitHub Copilot extensions installed.
But other common errors you might see are that you
might have the wrong version of Python installed, or you
might not even have it installed at all.
And I don't want everyone who pulls down this code
to have to make sure that they have the right
extension or versions or dependencies installed.
So that's where dev containers come into play.
Now, this project already has a dev container setup, which
you can tell from the .devcontainer folder which contains
a devcontainer.json file.
If I were working with a brand new project, to
add this dev container folder, it's as easy as installing
the dev containers extension, then running the command Add Dev
Container Configuration Files.
From there, you'll pick a template for your tech stack and
its version.
You can then customize your devcontainer.json further if
needed.
Before we go over the devcontainer.json for this
repo, let's talk a bit more about what this file
is for.
The devcontainer.json contains the metadata used to configure
your dev container.
You can install things like languages and toolsets that
your code needs to run and further customize the container
for your development experience, such as configuring different extensions and
settings.
By having this file be a part of the source
code, anyone who works on the project will be able
to quickly spin up this customized dev container.
Now let's take a look at what properties this project's
devcontainer.json configures.
The dev container will have the name Python 3, and
here we specify which docker image we'll be using to
create the dev container.
Next, we have a customization section that will allow you
to customize tool specific properties.
So we are specifying that we want the Code Spell
Checker extension to come installed in our dev container.
You might be wondering why we have VS Code specific
configurations, and that's because dev containers can be used with
tools other than VS Code using the dev container specification.
We'll link to that documentation in the description, but for
the purposes of this video we're just going to focus
on VS Code now.
We also have a ports attribute setting for port forwarding
properties.
And finally, we have a post create command.
This means that after the dev container gets created, we
will automatically run this pip install command for our requirements.txt,
which is really handy.
So let's now reopen this project in a dev container.
To do that we'll run the Reopen in Container command.
Now this will take just a few moments to spin
up.
As it does, you'll get a log of the dev
container creation process as well as see that post create
command run.
Now when we look at our VS code it looks
almost exactly the same, with a couple of key differences.
In the bottom left we have this button known as
the remote indicator, which now is updated to show the
name of my container from the devcontainer.json.
When you click on the remote indicator you will have
a convenient entry point into popular remote commands.
So for dev containers, we see a subset of five
popular commands, and you can always use the command palette
to access your full set of commands.
Next, if we head to our extensions, we now see
two sections, one for local installed, and that's my Dev
containers and Copilot extensions that I had installed in my
local VS code setup, and the 2nd is a dev
container section.
These are the extensions that were installed only in my
dev container.
So we can see that the code spell checker extension
that we saw in the devcontainer.json customization setting,
as well as a few Python and linter extensions.
Now when we were going over the devcontainer.json,
we saw where the spell checker extension was explicitly
configured, but there is no mention of the Python extensions.
So how did the dev container know to include them?
The answer is in the docker image that was specified
in our project's devcontainer.json.
This is actually a prebuilt image, and this prebuilt image
has its own devcontainer.json.
This image's configuration then specifies dev container features, which are
used to add dependencies in a standalone unit.
For example, the Python feature comes with the Python and
pylance extensions installed, so that's how we are getting those
installed in our dev container.
By having this chain of references, your project's devcontainer.json
can stay much simpler and cleaner, while still ensuring
that behind the scenes, everything your code needs to run
is being configured.
This is a really powerful concept, so in the future
we'll post another video fully breaking down features and prebuilt
images.
Alright, now it's time for the moment of truth.
Does the code run?
And voila, this Python app is up and running with
no steps needed for me other than opening the code
in a dev container.
From here you can make edits, debug, commit your code,
everything that you're used to in your VS Code development
environment, but now running in a container that has everything
configured for you.
And as your dependencies change, all you need to do
is update your dev container configuration for a seamless experience.
In the demo, we showed you how to get started
with dev containers in just a few minutes.
We also went over some really cool concepts like prebuilt
images, features, and templates.
If you want to learn more, then you're in luck
because over the next few months we're going to be
posting a series of videos going over these more advanced
concepts.
So make sure you're subscribed to our channel so that
you don't miss out.
Happy coding!