>> Hi, everyone. I'm really glad to be with you tonight.
I'm presenting myself. I'm Yohan and I'm
a Senior Cloud Developer Advocate working here at Microsoft.
If like me, you like working in a clean environment,
then I think the talk is for you.
I'll just start by telling you the story of
a developer that lands on a new project.
What happens when you're getting started in your new project?
First thing first, welcome to the team.
Then usually you're given up
the docs to setup your environment, provided there's one.
After that, you take some time to install
all the required tools to prepare
your environments and start working on new projects.
But what usually happens next is few days later,
you still don't have a working environment.
I've been that developer a few times already.
What happens?
First thing usually is that maybe
the documentation is not up-to-date.
But frankly, I can't be blaming the developers because I've been
there and since it's not
every day that you welcome a new developer in your projects,
so probably that's taking time
to update the docs every week or so,
might not be worth it.
Also, surely you'll probably have installed
on your own local environments the tools that were in the docs,
but maybe not the exact same version
that you needed to be able to work on your new project.
Or maybe that the tools that you
already have installed conflicts with
other projects or other environments you have
set up for working on different things.
The thing is, we already know how to
solve these problems because we had
the same issues for
the runtime environments when were
shipping applications to productions.
We solve these issues by packaging
our runtime environments into containers.
Why not use containers for development environments?
Again, I will be focusing on container this time,
but I will be also speaking about
the Remote Development extensions for
VS Code that Bridget just presented earlier.
Now, I'll start by showing you how
it works concretely on a project.
Let me switch to my desktop here.
Now you can see my VS Code open here on the project I just cloned.
This is a new project.
It's a C-Sharp Web API that I need to start working on.
Obviously, I have VS Code installed with
this Remote Development extension installed,
but I don't have any tools, we need to work on it.
If I try, for example, to use the dotnet CLI,
you can see that it stopped working
because I did not have installed anything.
Of course, I could like open
a C-Sharp file, make some modification,
but I wouldn't be able to like
build the projects or run it to
test if everything's working correctly.
What can I do? If you take
a look at the status bar in the bottom left here,
you can see this little green icon.
If I click on it, I have this option,
I can choose reopen the project in a container.
What it will do, it will reload VS Code, but this time,
instead of being able to work in
my local environment setup on my machine,
you can see already that I have a different shell here.
Previously I was using Z shell,
that's the shell I have installed on my local machine,
but now it's a Bash.
For example, if I try that command again,
you can see that this time it's working.
There's sometimes that that has been done.
This thing is that I'm now connected.
You can see that in the status bar in the bottom,
you can see that I'm connected to
my development container. How does is it work?
You can see here at the top that I have
this .devcontainer folder and this folder contains two files.
The first one is the regular Dockerfile.
You may be already familiar with it.
This Dockerfile, basically, it tells what kind of [inaudible] ,
I need to work on this projects.
Here I'm using a pro-built image provided by Microsoft.
But if I need any tools that are not provided in this,
I can just customize this file and
add any tool I might need to be able to work on my project.
The second one is also interesting.
It's called devcontainer.json.
If I open it, you can see there that
I have a few options to set up
how I want to work in
this specific development container environment.
You can see that I can change the name,
the name is what will be shown in the bottom
so we can be sure that you're connected to the right environment.
I can specify here which Dockerfile I need to use.
You can set up some settings
you want for building your Dockerfile,
for example, if you need to change
a few settings for your particular setup.
Then you have also another interesting options.
You saw earlier that the Bash used when
I'm connected to this development container
is not the same one I'm using locally.
This is because here in the settings part,
I can choose to set
different settings for when
I'm working in the specific container environments,
then the settings I have locally on my machine.
That means that you can set
specific VS Code settings that will be used for
every developer on your projects that will start
working using this specific container environment.
This is right for sharing specific VS Code settings
from other developers in your projects.
There's also another cool thing here,
is that you have the option to specify extensions
that will be installed when I'm working again,
in this specific container environment.
Here you can see that I have the C-Sharp extension,
and if I open here on the left,
the extension tab, you can see that I have been
with my local extension as usual,
but I have also a new one.
Here the C-Sharp extension is installed
inside the development container and not on my local machine.
Meaning when I close this project and I work on another one,
I once have this extension available.
That means you can clearly have complete separate environs,
you can also have your own extension installed and
shared within developers of
your projects for this particular development container,
that means you won't have conflicts of different extensions.
For example, if I'm working on a Java project,
I surely don't want to have this extension enabled.
That's really neat for keeping all things clean.
One last thing, is that I also
have the option to forward specific ports.
Because as you know,
containers are completely isolated environments.
But in this case, I'm working on a Web API,
so if I want to be able to
test this API and see if things are working,
I need to be able to connect to my API from the outside world,
meaning my local machine.
This time if I try to render projects,
let's run this project to see how it's working.
You can see that it's building the projects,
it will take some time.
Then what it will do,
it will run the server as usual,
but within the container.
You can see that it's running on
my local environments on power 5,000
but it's within the development container.
If I didn't specify anything,
I wouldn't be able to connect to this container.
But because I've set up here to forward this two specific ports,
if I switch back to my local browser and try to hit this URL,
you can see some JSON here,
meaning that I can still access
my sever running inside my development environments as usual.
Here, there's rates. I've shown you how to
be able to work in your environment.
Let me just conclude that
by reopening the same project but locally,
just because as I said in the title of my talk,
I like to keep things clean.
This time I've disconnected from this container,
it was closed and again,
on my local environment.
You can see that I still don't have
any tools related to
C-Sharp and dotnet installed on my local machine.
It's all within the container.
Everything is clean inside this developing container.
Now, what if I want to get started on a new project?
How do I set up projects to be able to work like that?
I move on to a completely blank VS Code projects.
Just to give you a bit of context,
I'm a JavaScript Developer, mainly myself.
I have an old Node.js environment installed locally on my machine.
I can show you that locally I have
the v12 version of Node.js installed here.
But for this new projects,
I would like to be able to use the latest
Node.js version. How do I do that?
Again, I click on the bottom left to open the extensions tools.
I will select this time "Add
Development Container Configuration Files".
What will appear is a list of
possible container configuration already prepared for you.
You can see that I have already a lot of options here,
for example, working with C plus plus,
Dart, C-Sharp, F-Sharp, Java,
or Node.js, that's what I will choose here.
I'll choose the latest js version, version 14.
What it will do, it will create these two files,
the Dockerfile and the devcontainer, that's JSON file.
Next thing, if I want to get
started and to work on these projects,
I do the same thing as last time.
I open again, the extension and select "Reopen in Container".
It will switch back to the container.
The first time, it might take a while
because it will be building the docker image,
but the later one will be faster.
It will open here my new environment.
It may be a bit tough for my computer.
Now if I try to run the Node.js version,
you can see that I now have version 14 available.
Meaning, I'm still connected to the container environments.
We have no issue working on different projects,
having different version of the tools I need.
That's really a new thing here.
Moving back to my slides,
let me switch back here to the slide.
I have one last thing I would like to show you that it
was already presented in
the introduction and also in a RIDGID storage,
but it's got spaces because everything I
demonstrated to you from using a locally container environment,
you can do it exactly on GitHub.
What's the advantages? The thing is maybe you're
working on a machine that's not a developer machines,
so it doesn't have enough RAM,
enough CPU to be able to be
working comfortably with your projects.
Or maybe you don't even want to install
VS Code or Docker or the remotes extension on your machine,
you basically have nothing.
Here, if I switch back again to my browser,
you can see that this GitHub contains
the exact same C-Sharp projects I've shown you earlier.
In this "Code" button, I have these Codespace extensions.
For that, of course,
since it's in early access,
you have to be enrolled into that.
I will put my glasses to give you a glimpse
of your future of what you may be able soon to do.
It's like once you click on these opening "Codespaces" button,
you get this exact same friendly VS Code environments
that I've just shown you earlier.
But if you notice the difference
is that now I'm running completely in my browser,
meaning that I don't need to
have anything installed on my local machine,
and I can still have the exact same tool that
were available locally when I was connected to my local container.
But this time, I'm working completely on the web in
GitHub codespace. That's really great.
For example, if you're a contractor and if you want
to work a few days on a project but don't want
to set up everything on your machine,
this is a great way to be able to just maybe prepare to request,
or help fix a quick bit in any projects in your company.
That's it for my talk. Thank you.
I hope you enjoyed it.
Every resources, every repo I've
shown on the slides also for
this talk will be available at this URL.
You can scan this quicker to get right into it.
Thank you-all for listening.
If you have any question,
you can use the chats or if there any concerns right now,
you can always message me on Twitter later. Thanks.
>> Excellent. Thank you so much, Yohan.
One, I have to ask, those glasses,
could you put those back on? Can you hear me, Yohan?
>> Yes.
>> Those glasses. Do you usually code with those glasses on?
>> That would be a bit difficult.
It's just special glasses to take a look into the future better.
>> I got you.
>> That's very practical for coding.
>> Very good. One quick question for you. This is great.
It's a fantastic scene,
setting up using containers.
In some situations, you might have
a more complex development environment.
What if you need more than one container?
How would you approach doing that?
>> Exactly. What I've shown you in this demo is show
you the basic workflow
if you need to connect to one single container.
But once you start working with container,
usually, you start solving a lot of containers.
For example, if you are working on a web project,
you might need to store database in separate container.
Of course, you can do that.
It will require a bit more setup.
But let me tell you that you can have
as many containers as you need for your projects,
and instead of a single Docker file,
you can specify to use a Docker
Compose.YAML file that you can use to set up complex environments.
Meaning if you need to have multiple container,
you can have as many as you need.
Got you. Then, there's some questions coming from the chat,
but I think it might be best to answer over Twitter,
but just to give you a heads up,
folks are asking about how you would add
Z shells to the container.
When you run a docker image or container,
is this always running on your local machine?
Maybe you can answer that one actually,
is it always running on your local machine?
>> For now, I've set up Z shell on my local machine and honestly,
I didn't try to set up one in a container.
That might be interesting to try.
>> Awesome. Thank you so much, Yohan.
>> Thank you, Brian.