>> My name is Peter Mckee I'm on
the Developer Relations team at Docker.
Today I'm going to be talking about how to
supercharge your development using VS Code
and the Docker extension.
One of the first things you need to do to get started
is head over to our Hub,
hub.docker.com and create a free Docker ID.
I'm going to talk a little bit about that, why you should do that.
Next thing you should do is then head over to Products,
Docker-desktop, and download the "Desktop."
Come in here, you can choose whether for Mac or Windows.
Then we'll install Docker locally on
your machine and you can interact with the VS Code.
Okay, so let's jump right into it.
I don't have any slides today,
we're going to spend all of our time inside of code here.
The first thing you want to
do is you're going to come over here to the extensions.
You can also use the "Shortcut key" or you can click
on the little icon over here and just search for Docker.
You should have the first result,
it should come up, and should be the extension that we want.
I already have it installed.
I was worried about internet connections and those type of things,
but you'll have a little "Install" button over here.
Just click on that, that will install the extension.
Once it's installed, you'll have
this little "Whale" icon or a little Mobi icon.
If you click on that, we have
a bunch of little panels to your left.
Your panels might not be in the same order that mine are,
but I like to organize mine
this way because I usually build images
first and then I run those images in
containers and then they use volumes and networks.
Right now you can see I have a couple of images.
I have a Mongo image in an Engine X.
I don't have any containers running,
no volumes right now.
I do have networks and
these are the networks that Docker sets up for you.
Again, I'm not going to dive too deep into those,
but you can check out our docs if you
want to learn a little more about networking.
Then you have contexts.
Again, I won't dive too deep into this,
but a context basically allows you
to set up a context for a Public Cloud.
Either AWS or Azure,
you can set up a context that points there.
Then you can run your same Docker CLI commands that you know
and love and they'll be run up in the Cloud for you.
If you want to learn more about that,
check out our YouTube channel.
Got a bunch of stuff out on there, really cool stuff.
Next one is the Registry.
I'm going to connect to a Registry
and I'm going to connect in the Hub.
I clicked on "Connect Registry" and
this opens up the drop-down here.
I'm going to choose Hub, I'm going to put in my Docker ID.
I got to hit the right keys here.
Hardest part about doing demos is typing in front of
people and then put in your password.
Okay, now we're connected in the Hub.
You can see Docker Hub here,
you can expand Hub.
You can see our repositories that you remember of.
You can expand the repositories.
See images that you have.
Then if you expand your images,
you can see all the tags.
I'm going to grab the latest here.
If you right-click, easy way to pull that image just right-click.
Choose "Pull". That'll pull down your image from Hub.
You could see right here what command is being
run by the extension, a Docker pull.
That will pull down images from Hub.
Once it's done, it'll show up here at the top.
That's a whirlwind tour of the plugin right now.
Let's take a look at a sample application.
I have a really simple NodeJS application.
I'm using a little framework that I wrote
that I just used for demos.
It simplifies the code a little bit,
but we basically have to rest endpoints here.
We're going to be using this one mostly.
Don't worry too much about the code it's just sample code.
We have an application,
we have our code, we have our extension installed.
It could be great. I can just run
the application right now and start debugging,
but I want to run everything in containers,
and I don't want to use my containers to
debug and develop it and then share those out to the world.
I need a Docker file, to build an image we need a Docker file.
A couple of ways you can do that.
But with the extension,
if I open up the command palette and I type in "Docker file",
add "Docker file" to your workspace. We're going to click on that.
Now it's asking me what's my application platform?
I'm running NodeJS, so I'll click on that.
Now it's looking for the package.jason.
The extension uses the package.json to fill
out different parameters into infer how to run different commands.
I'm going to show a little bit that in a second.
Let me choose a package.json,
it's not underneath my node modules.
Then our application actually runs on 8080,
so let me add that in there.
We're not going to add a compose file at this time.
Go ahead and do that and voila,
I've got a fantastic Docker file here.
Let me add a little bit of wide space. There we go.
Now we've got our Docker file.
Let me save that, I'm not going to
run through the Docker file for the sake of time,
but a key things I want to show is it sets up
your Node environment variables includes
and installs your packages.
Then right here on line 10,
I want to point this out. We're cooperating.
What the dots mean is I'm going to copy everything in the context,
my Docker context that I've sent to the build command.
I'm going to copy everything there and I'm
going to put it inside the image and
it's going to put inside the working directory
because I said a working directory.
What if we have files that are in
our context in our project
that we don't want to include it in our image.
Usually what we do is we create a .dockerignore.
Of course, the extension has set this up for me,
put this into my project,
has some awesome defaults.
You'll see here we're not including
Node-Modules, those type of things.
Little quick tip.
If you're images that you're
producing when you're building are large,
make sure you have a dockerignore file.
I say that a lot. Sometimes it's
new projects and those type of things.
You forget to create a dockerignore file.
You're putting your whole documentation folder
into your image and it just expands your image,
so check that first. The extension sets that up.
Awesome. Okay, we install
the extension and now we have a Docker file produced for us.
Let's go ahead and build an image.
A couple of ways you can do that.
I like to just right-click right on
my "Docker file", choose Build Image.
That's going to run a build.
Sometimes it doesn't like to run when I do it,
demoing, there we ago.
Okay, so it's built my image,
I'm going to scroll up here,
sorry for the fast growing.
But you can see the extension runs
the exact same commands that you would be running in the terminal.
Others have made the point that
context switching really kills your productivity.
Normally I would be "Alt Tabbing" or I'd
be coming down here somewhere,
I'd be clicking on the terminal,
I would be running a Docker command there.
Then coming back into VS Code,
coding a little bit, going back to
my terminal, those type of things.
But if you're staying in VS Code and using the extension,
it reduces the amount of contexts which you need to do.
Also here to note is
all these flags are getting passed in to the build.
Where do all of those come from?
So another really cool thing that the extension does for us is
that it includes this task.json file.
What it did is it created three tasks;
one for our build and then two for running our images,
one for release and one for debug.
Right here you can configure
the way things are built and the way things are run.
Let's take a look of our images real quick.
Let me make this, see if I can get some more room here.
There we go. There's our zap name,
the image that was just built.
We have the latest. Where does zappname come from?
Well, Docker knows that you have a node application because
we set that up when we created our docker file.
What that does is it looks in the package.json,
it looks for your name in there.
If you don't have a name in your package.json,
it'll bump up into the directory and use the directory name,
but I don't like that.
This is some name that I just have from a previous demo.
What I want to do is change that.
I'm going to come into my Tasks
and I'm going to add another configuration in here.
I'm going to call it "Tag" and give a colon
and I call it vscodedocker. I'm going to save that.
I'm going to come back. I'm going to build
my image from now over on the Explorer side.
Again, just right-click, choose "Build Image."
That builds my image.
Let's go ahead and take a look now at our images,
let's close some of these down so we can have a better look.
Now I have VS Code Docker,
that image, and I have my zappname.
We don't need this one anymore.
Again, I don't switch over to my terminal.
I can stay right here, just right-click and say "Remove",
remove that image and now it's gone.
We've built our image,
we changed what tag we want.
Now let's go ahead and run our project inside of a container.
Now all we have to do is come over to the debug.
Real quick let me show you.
We have this launch.json,
the extension also set this up for us.
You can see right here this pre-launch task is going to run
as "Docker" "Dash" run "colon" debug "task."
That is going to look right here in the debug.
What's pretty cool it has this depends on?
It's going to depend on this docker build,
which is our build to beginning,
and then it's going to run our project.
Let's go ahead and do that now. I'm going to click on the "Run".
It started up. I know that scrolled by really fast there.
We'll come up to the top and we can see that we built.
Then if I scroll to the bottom,
again sorry for the fast scrolling,
you can see that I've run my image.
Now we're up and running,
we have our image running, we're good to go.
You can see that the extension has pulled in
these environment variables out of our task, down here.
You see we set environment variables, those were pulled in.
Also really cool thing is we're exposing port 9229,
which is the default debug port.
Then it runs node using the dash-hash inspect.
That's setting up our debugger.
Now let's come over to the extension.
Expand my containers, give it a refresh.
Now we can see that our container is running. Pretty simple.
We can right-click on that,
we can view logs and make this bigger for folks.
You can see all the logs that are running under your container.
They are being produced from your container.
You can even attach into
a shell inside of your container, excuse me.
We can run regular commands,
we can cut out files.
We can take a look at what's going on.
Let's go ahead and stop that.
One last thing I want to do so let me go ahead and stop them.
Move this down here. This is all great, running, awesome.
Let's open up our Source File and let's see if
we got a debug point set.
Let's see if we can run our images inside of our container,
connect with Visual Studio Code
into the container and see our break-point.
Awesome. Let's go up here and I'm going to start with debugging.
You can also push your "F5",
you can come over into
the "Debug" tab and you can start it from here.
We're up and running, the debugger's attached.
I have my break-point set.
Come back over to my browser.
Let's hit that "Code Endpoint."
There we go. It hit our break-point.
From the container, we're debugging into
the container back in the Visual Studio Code,
we have our break-point and we're able to
inspect just like you normally would.
You can see all kinds of interesting things running.
You can debug your code.
Yes, nice seamlessly, connect right into your container.
Now you can see it running. You can also expand your file systems.
A lot of times when you're building your images
and your containers are running,
you'll get file not found those type of things.
Easy way to see what's been added into
your container is by looking right here in the Containers panel.
Awesome. Let's go ahead and stop this.
Give that a second to stop.
One last thing I want to show is another [inaudible] ,
is typing all those commands out and getting
things on the command line is very time-consuming.
You can't remember all those things.
Compose files are really awesome to configure
your containers and run them locally and
orchestrate them locally so you can have your
like we have right here, our rest API.
Let's say we wanted to connect that into the database,
we can add that in a compose file.
Let's build a compose real quick.
Just do a docker and add a composed file to your workspace.
No JS, some of the same questions, package.json.
We're running on port 8080
and it's going to run a bit. Let's come over here.
Now we can see it's created two files for us.
We have our Docker compose.
This is everything that we'd be typing out on the command line.
Same thing the extension is running is all
nicely packaged up into composed file.
You can add in any services you need,
network volumes, those type of things.
Also we have one for debugging.
We can see here that it's going to run the command.
It's going to overwrite the command that I have in
my Docker file and it's going to run this dash-dash inspect.
We can put it into debug mode and we can debug.
Awesome, thank you so much.
There is a ton more you can do with the extension.
I wish I had more time.
Maybe I'll do a video on on all the other features, but yes,
thanks for joining me and listen to me talk.
>> Awesome. Thank you, Peter (phonetic).
Some questions for you. We've got a few minutes
to do some Q and A.
For folks that are new to Docker and Containers and images,
some of these terms might not be familiar.
If you could describe what's
the difference between an image and a container?
>> Yes. This is a question I get asked a lot.
It can be confusing. There's some confusion
out there around VMs and Containers.
The way I like to explain it is,
a virtual machine virtualizes your hardware.
You have a hardware, you have a bunch
of CPUs and a bunch of memory.
You put in a VM layer
and that allows operating systems to be installed;
multiple different operating systems be
installed and it virtualizes the hardware.
Containers virtualized the OS.
You have one OS installed in your multiple containers running.
It's just a simple normal operating system process that's been
wrapped and isolated from the rest of the processes.
That process runs and thinks it has
access to everything it can see.
That's the main differences between the two,
and that's why you can't run
a Windows EXE on a Linux operating system,
as a container and vice versa.
It shares the underlying operating system.
Then real quick, the difference between an image and a container.
I'd put it into object-oriented terms.
In object orient, we have classes and objects.
Class is the template that produce multiple objects,
same thing with an image in a container.
Image is your template,
the cookie cutter that stamps out containers.
An image is run inside of
a container and you can run that image in
multiple containers. Hopefully that helps.
>> Yeah, absolutely. I like the way you put
that with the classes and all that.
>> You got to talk about Cookies.
>> Yes, of course. I mean, you had me at Cookies.
Well, thank you so much Peter. That was super helpful
and insightful. Thanks again.
>> Yes, thank you. Appreciate it.