>> Hi, my name is Jessica Deen and
I'm a cloud developer advocate with Microsoft.
Today, we're going to talk about building
a Docker image and pushing
it to Azure container registry.
All using Visual Studio Team Services.
So, let's get started.
I'm already logged into my VSTS account.
So, I'm going to automatically
go and create a new project.
Now, the first thing you
have to do is give it a project name.
So I'm going to go ahead and call it dotnet-containers.
Because I actually want to build a Docker image
with a dotnet core application.
Now, once the project creates,
the first thing it's going to ask
is Where do you have your code?
I can push from an existing repository
on the command line,
I can import a repository.
I can even build code from an external repository.
For today's demo, I'm actually going to import
repository because I already have my code,
living out and GitHub.
I'm going enter in the Git URL,
and I'm going to import.
Now, as soon as my code is imported,
I'm actually going to be taken over to where I can see
the code in my visual studio team services repo.
And the reason I've come, I chose to import my code,
is VSTS actually gives me free unlimited private repos.
So, for the purpose of the project today,
I'm already going to have my code already local in VSTS.
So, I'm going to click here to navigate and view my code.
And I can see that it looks like
it was successfully imported.
So, I can click down into source,
I can see that I have my test folder,
and I have my dotnet source code.
Perfect. So, if I go back to the Git repo bruit,
right up above in the top right hand corner,
under Fork and Clone,
I see that VSTS is already
walking me through the next part of my process,
which is going to be to set up my build.
So, I'm going to simply click
that button and then a new tab,
it's going to open up
my continuous integration or my CI setup.
Now, since I am going to
build the Docker image and container,
but I'm using a dotnet core application,
I'm actually going to choose to start with
a dotnet core template that VSTS provides.
If I didn't want to use a template,
I can even start with an empty process.
But we're going to do a template
today because it's easier.
So, I'm going to hit apply, and it's going to add in
tasks that makes sense for a dotnet core application.
Now, the first thing we see under process,
underneath the name is
actually something that says agent queue.
So if you're new to VSTS-.
Let me talk a bit about agents real quick.
Agents or computers that
VSTS gives you completely for free,
to run your builds and your releases on.
So, you can do anything from hosted visual studio 2017,
to hosted Windows, hosted linux preview,
and even hosted MacOS.
So, it's really neat.
We give you computers for any language, any platform.
Now there are certain instances,
where you might want to use your own computer
for build or release.
To do that, it's really simple
you would simply click on the gear up hear,
in the very top.
So, we can take a look at that.
And then when you hover over it,
you actually see agent queues right underneath.
Now, when you click it,
and they already have open in another tab for you.
When you click that, you
immediately are taken to your page
where you can set up additional private agents.
You can see that, you can download an agent and set it up
on Windows, OSX or Linux.
Now, the reason why you might
want your own private agent,
we're going to talk about a
little bit later on in this video.
For now, let's go back to our build.
Now, I'm going to leave Hosted VS2017,
as the agent I'm going to use
for this dotnet core application.
Now, I'm going to go through and take a look at what's
happening on the phases or the task runner,
which is over here on the left hand side.
So, I see that it already added
in tasks for dotnet restore,
dotnet build, task and publish.
But this publish artifact task would
publish files that I would need for my release.
Since I'm building an image and I'm
pushing into Azure container registry,
I actually don't need this task.
So, I'm going to go ahead and remove it.
However, I do need
additional tasks that are going
to make sense for this project.
So,I'm going to go ahead and add those now.
I simply search in the field and hit add.
There's a few more that I need,
so I'm going to go ahead and add those in.
And then I also need a Docker task.
I actually need to Docker tasks, right?
Because I need a task for build,
and then I need a task for push.
So, go ahead and add that in twice.
Great. So, I can see the new tasks
that I added over on the left hand side.
And since this is a task runner,
all I have to do is move these
around in the order that makes sense.
Great. So now, I'm going to go through and fill
out the values that I need for each one of those tasks.
So, for npm install,
I'm actually going to change this to version zero,
because I want to use arguments,
and I'm going to tell it that I want it to install bower.
So, we're going to do bower,
and then I'm also going to say allow root,
because I want it to have root access.
Now, the next thing I have to do,
is from command line-.
Again, these are tasks that are being run on
those computers that VSTS is giving for you.
The next thing I have to do is I have to tell
it that I want it to run that tool,
I just had to install.
So, I'm going to go ahead and click over here in tool,
and I'm going to enter bower.
Now again, I also still want to make
sure that I don't have any issues with permissions,
so I'm going to allow root.
The next thing I have to do is point
the working folder for that task,
where I want it to run bower,
and I'm going to point it to where how my bower json.
And I see that I do have my bower
json right in this folder,
so just say okay.
So now I see that that is the proper folder.
Now, the neat thing is because we chose a template,
I actually don't need to make any changes to my restore,
my build, my test,
or even my published tasks.
Everything is already pre-entered and
pre-configured for what makes sense for this project.
The next thing I have to do,
is just set up my build and push tests for
my Docker container image
that I'm to push out into Azure.
So, the first thing I'm going to do.
I can give it a build name I'm gonna leave it as is.
I see under container registry,
that it already has
Azure container registry selected for me.
Now, if I wanted to use a third party registry,
I could drop down and simply choose container registry.
I am going to leave it as ACR for today.
Now, I'm going to choose an Azure subscription.
Where does my ACR or my Azure container registry live?
In this case, it lives in
my Microsoft internal subscription.
As soon as I select it,
another box pops up which prompts me to authorize.
Once I hit that, VSTS is actually going to go
out and set up
the authentication to my Azure subscription,
so it can add automatically,
give me access into that container registry.
I don't have to set up any username,
password, credentials.
It simplifies the process.
Great. So now that that finished authorizing,
I can click the drop down arrow
under Azure container registry,
and I see my registry is already
available. So I'll click that.
Still, VSTS is still walking me through it.
What's the next thing I want to do?
I want to build an image. Great. I'm going
to leave that action as is.
Now, do I want to specify
a direct link to my Docker file. I do.
So, if I hit the ellipsis on the right hand side.again,
I can choose the location of
my Docker file from might Git repo.
So, I hit "Source",
drop down into my dotnet,
scroll down a little bit,
and there's my Docker file.
So, I'll select that, hit "okay".
And my Docker files now selected.
I don't have any build arguments and I
am going to use the default build context.
I'm going to live the image name,
as build repository name, with build id.
These are built in parameters,
by VSTS, again for you to use.
And it will automatically
populate the information accordingly.
Now the last thing I like to do,
is also check this box for including the latest tag.
This way, when VSTS builds my image,
it's not only going to target with the build id,
but it's also going to update the latest tag,
to use that image as well.
Now the second task,
I'm just going to go through and repeat
all the things that I did for the first task.
The only thing I don't have to repeat is
setting up the Azure subscription
because it's already authorized
as a service connection for this project.
So, I can just go through and quickly
select my registry again, a.
This time, I'm going to change the action to push,
because we're pushing the image that
we just built in the previous step.
Now, I'm going to scroll down a little bit more.
And the last thing I want to check is again latest tag.
Because again, not only did it build and target.
I now want to push both the build id and the tag.
So now, there's nothing else for me to check.
All I have to do is hit "Save and queue".
There's going to be one final Window,
where I can enter and save
comments or commit information.
I don't need to enter in anything else for this project,
and I'll just hit "Save and queue".
VSTS is now going to automatically queue off a build,
and we can go take a look and see what's happening.
Great. So, I can say that the build has started.
It's initializing the hosted agent,
that again has provided for us.
And it has now started the job.
So, we can actually watch
as this job goes through and completes.
It's going to run through a list of
tasks that it has set up.
And one thing I wanted to mention.
We'll circle back to something that I
mentioned earlier in the video.
I mentioned how it might make more sense
in certain situations to have a private agent.
The reason why, is because
the hosted agent is just a computer you used one time.
So, when you're building Docker images
specifically and container images,
your Docker file is going to pull what we call layers.
Now, when you use
a private agent or you do a build on your own system,
it's going to end up caching those layers.
So that the next time you build,
it doesn't have to re-pull.
Therefore, it speeds up future builds.
However, when this process is running on a hosted agent,
each time you kick it off, it's going to
re-pull down the layers.
So that's going to mean that the build is going to take
potentially five to six minutes the first time.
Each time, you would repeat
that build with a hosted agent.
It would take the same amount of time.
If you did have your own private agent,
it could take 30 seconds to a minute,
because it's not going to have to take all that time,
caching layers, rebuilding, re-polling et cetera.
So, we're going to go ahead and let this job run.
Like I said, it will take about five to six minutes,
and I'll come check in with you when this is finished.
Great. So now, my job finished,
and you can see it did take
almost seven minutes for it to complete.
If I were using a private agent,
the next time around I run it,
the time would be a lot shorter. But that's it.
In less than seven minutes,
and then maybe five minutes to set up
your build task in under 15 minutes,
you can get started with building and pushing
a Docker image into Azure container registry using VSTS.
Now, if you want to know what to do with
the image after you've built it and pushed it,
you're going to want to check out some of
my other videos while I walk you through,
how to set up from scratch,
a project using again still VSTS
but taking that Docker image and ultimately
pushing it out into a kurbenetes cluster.
Thanks for watching and have a great day.