>> If you have a .Net Framework web application,
did you know that you can containerize it and its dependencies,
publish it to a container registry,
and then deploy it to Azure App Service?
Take advantage of what the Cloud has to
offer by moving your application to Azure.
Andrew Westgarth is here to show us how,
today on Azure Friday.
[MUSIC]
>> Hey everyone. Donovan Brown here with
another episode of Azure Friday. I'm here with Andrew.
He's going to show us how to take our .NET Framework applications,
all their dependencies, and run them inside of
a Windows Containers inside of Azure.
This is exciting stuff because so much talk is
about just port it to .NET core and
that is not always an option for a lot of us.
We want to take our .Net Framework Apps,
and we just want to lift and shift them into pairs,
and this sounds like it's going to be a great way to do that.
>> Yeah, exactly. We looked at our customer base and there is
a large customer base of .NET Framework
Apps who are not on Azure yet.
So how do we enable them,
how do we enable customers that are in
Cloud Service or on their own datacenters?
They got contracts when they know.
They've got applications they don't maintain anymore.
The contract, they don't even know them anymore.
How do we get them into
Azure and spin stably into Azure App Service.
>> All right.
>> The other thing is that we look at is
customers have dependencies in some of these applications.
So they have database clients that they need to use.
They have libraries that need to be installed in the GAC.
Well, we don't allow you to do that in
App Service because we don't want you to
have access to the underlying infrastructure.
It's all about your code.
With a Windows Container,
you can put those dependencies directly inside
your container and then run them on top of our platform.
>> Great.
>> So then that opens up new doors
for App modernization for a lot of customers.
>> Yeah, because you just answered the question,
because a lot of us are thinking, "Well,
I can already run my.NET Framework Apps and App Service.
Why do I have to containerize them?"
That was the reason why you have to containerize them.
>> Yeah, its dependencies,
and now a sandbox blocks access to
certain libraries say GDI, PDF generation.
We've made changes over the years to support a lot of frameworks,
but it doesn't support everything.
Whereas now customers are not blocked by that because
the sandbox becomes their Container
not what we have in App Service.
>> They can do whatever they need to in their Docker file to
make sure that all the dependencies are on that machine.
>> The only principal requirement is
that they're running a HTTP workload.
>> Okay.
>> So it communicates over 82443.
It's a web workload.
If it's a Windows service that thing,
Azure has got other services that we can help you out with,
but App Service is principally about running
high-scale web Apps and that's what we want to make easy.
>> So are you going to show us how to use it today?
>> Yeah. So I've got Visual Studio 2019 up and running,
and this simulation here is that I've already got a.Net App.
This is a web forms App,
and I wanted to move it to the Cloud.
So it has a dependency in place and I'm stuck.
I've got one thing I can go to IaaS,
I can go to Cloud services,
but it's not easy to move
around line you want to focus on the application.
So we're going to make a quick change here.
Just to show it's real.
Save that, and then all we're going to do is add Docker support.
Okay. I just have this one menu option,
and what happens is Visual Studio then gives us this Docker file.
If I minimize the solution explorer,
we have here the information of what our base images.
For.NET framework applications, we need to build
our containers off a base image of Windows Server Core.
For.NET core, we can use Windows Server Nano,
and they are very different in terms of capabilities.
One of the things that we have now in App Service is
support for Server 2019 hosts.
Which means that we can use Server Core 2019 images,
and that's what we're going to do here.
We just have to literally just now publish that to
a container registry and then we can make it
available to our App
once we go into the App Service we can pull it up.
>> Sure. So we can either use Docker Hub or ACR.
Any registry we really want to.
>> Exactly. So today I'm going to use Docker Hub just to
show that we can use any customer registry
or whichever your feel comfortable with.
So I'll just login to Docker Hub.
You can build a DevOps pipeline for all of
this and you can go into much more detail demos,
but today we just want to show very simple.
How do I get quickly up and run in and take
advantage of everything that we have built into the platform.
>> This is the process most of us are
going to take the first time we do it anyway.
>> Exactly, and then we'll go and we've explored.
Now how do I get this with one of
my real Apps and my production Apps and that's sort of things?
To go back to that comment that I made about the container sizes,
moving from 2016 Host support to 2019 is a massive difference.
So we go from here.
This is a 2016 image.
Nearly 14 Gig in size.
>> Yeah. It's always an invasion of
our existence it's just they're too big.
>> Then below, thanks to the awesome work
the Windows Server team has been doing on
making sure that those container images only
got the bare minimum you actually need in,
we're down to 5.32 gig.
>> Isn't that fantastic?
>> Then on Nano I think they've got that down to about 314 meg.
So if you're doing.NET Code then your way.
>> Absolutely. Very cool and we're really glad to see
the improvement in the size because that's something
that always comes up when you want to move to Windows Containers.
>> So we're just waiting for VS to publish that, but there we go.
We've got the publishing going on now,
and that's been published to Docker Hub.
It's compiling all of the layers getting everything put up.
The key thing with Windows Containers is
to make sure that you don't have unnecessary layers.
So a Container's built of various layers.
Your base image plus your application and
any changes as you'll see there in the published window,
and the key thing is to A,
use a base image that a service caches.
So we cache the 2019,
47 to image or the Nano Server 1809 image, make that call.
That way when we pull the customers image,
we don't have to pull that.
We've got it already,
and then we're just pulling
the differences and then spinning it up.
>> Great. So even though it's a five gigabyte image,
you're not going to pay the price of it being
a five-year gigabyte image because it's
cached in App Service for you anyway.
>> Yeah. We wouldn't have enough pull your applications as
effectively or your dependencies and even
there's ways you can build your Docker file
so that you actually put those dependencies in,
but then remove the transient layers so that you can just
push it down and be a lot more
efficient on how you build your Containers.
>> Fantastic.
>> So we have the Container here built,
and that's up and running in my Docker Hub.
So now I'm going to go into the Azure portal,
and I'm going to create a Web App.
This is something anybody who's used App Service before
not very familiar and very comfortable something that they can do.
We'll just give it a name,
and we have a choice in App Service,
Windows Linux code, or Docker image.
Now we have parity there,
and I'm going to create a new App Service Plan.
So an App Service Plan is effectively
the infrastructure underneath that we
have running for all App Service apps,
and for Windows containers,
we offer some of the most powerful equipment
that we have available in App Service
because they need different types of hardware underneath to run.
So we have everything from an eight gig at the low end
in terms of RAM up to 32 gig machine on the PC4 end,
and I'm going to choose one of those PC4 right now.
>> It's always fun.
>> Yeah. Let's give that a name,
and we have some locations support.
We're in six regions right now,
while we're in public preview where
we're looking at seeing what customers are doing.
We've expanded those over the year to give us more regions and
today I'm going to choose a West US
because that's closest to us where we recording,
and then I'd go in and configure my container.
>> All you're doing here is putting in
the actual image tag this way.
>> Yeah. So here's my image tag that I got.
That's the application Azure Friday's web
App and then latest which is my tag,
and then we just apply.
We do validation as well to make
sure that you're not deploying a Linux Container into
a Windows machine and so on and the actual Container is valid.
Because we want you to fail here
not after you've managed to spin an App when we try and do
a Docker pull and everything files when you're trying to have
a fantastic experience for the end user and the customer.
>> Great.
>> In the meantime we're building that,
and we'll wait for the application to come up and then
we'll do an initial request which is
then when we kick off the poll.
>> Okay.
>> That's when the worker says, "Okay.
I need to go and do some work.
Can we did a poll?" We're looking at ways in
which we can optimize that experience as we go forward.
We optimized for Server Core because the images are so big.
Anybody deploying a Nano image just gets the benefits because we
optimized for the harder problem then off we go so.
There's my App, there's my App Service Plan,
and there's my website.
Very familiar.
Certain features are grayed out because they're
not there yet or they don't apply,
but as we get closer towards a GI product,
more and more of those features that people know and
love about App Service will come up.
So we're just waiting for that Container to spin up.
In the background, we're doing a Docker pull.
>> Yes.
>> Getting it all unpacked
extracting all the layers and having it run.
While we're doing that, we'll look at some of the demos or some of
the scenarios that we can solve with this problem.
>> Sure.
>> So here's the support for custom fonts.
Again, they need to be installed into the machine,
but now you install them into the Container.
We can make use of those.
This one is PDF generation.
So if you do this with certain libraries,
you'll get yellow screen of deaths.
This thing in App Service.
So we don't want that now.
That fully functions and works,
and here's another one Custom Culture.
So this is something that needs to be installed into the GAC.
Again, that's something we don't allow
in App Service, but now you can do that.
It's the same for MSIs.
So I've got a demo where you actually use
an Access database which is stored in Azure File Share,
connected to App Service,
but then I can read it using Jet from my.NET Framework to App,
and that's a common thing in enterprise.
I spent enough time in that world
that I know that these things happened.
>> Access is like Vb.
It's like it's everywhere. You never [inaudible].
>> If it isn't broke don't think [inaudible].
>> Exactly. So it's still doing getting the job done.
So yeah.
Again this is a really going to be exciting for people who have
large legacy full framework applications and we all do.
We all have those applications.
>> There's the demo opening.
>> Very cool.
>> So that's taken the Container,
pulled it down, unpacked.
I used the base image that we catch.
So all it needed was my layers.
So if we go into there,
we can even show that piece off by looking at
the container logs and we can see what we've actually done.
So you see that already exists.
>> Already exists.
>> Already exists, and then we realized we have this layer.
>> Exactly.
>> We took in a few K4 layer.
>> Yeah. It's interesting.
So instead of just using App Service itself,
we were forced to use Containers
because it gives us
that sandbox that allows us to do our own dependencies.
But forcing our hand there has given us
this portability that comes with being in a Docker container.
The image in there has more platform support Windows images.
You're just going to be able to pull that down and run it in
so many other places which is I think the true power and benefit
of Docker is that you build
your MS1 as you deploy as many times
and in many places as you'd like.
>> Certainly and within App Service we give you auto-scale.
>> Yeah.
>> We give you to scale out.
We can do that automatically for you.
>> Deployment slots are in there.
>> Deployment slots. We've had
those ever since the preview started.
We've got things like WinRM.
You can WinRM in your container,
but you don't have to customize your container to enable it.
>> Oh! Nice.
>> We do that for you.
So when your container is up and running,
we're able to inject the module and then be able to open up WinRM.
We can do the same thing with SSH.
This services and that's where we're
looking at the value out of App Service.
How can we enable these scenarios,
but still give you that portability of the container.
>> Fantastic.
>> If you lose that potability of the container,
then we haven't implemented correctly.
>> Correctly. Yeah. Exactly.
>> You're driving forward risk, and that's
what our feature gates is all the time.
>> Well, this is always exciting to see
the Windows world embracing
the Container world so much so
that we're not going to have to rewrite.
Because the answer cannot always be just rewrite it in.NET Core.
That's not an answer. This is an answer.
Just do what you did before.
Right-click, add Docker support,
publish your app, and enjoy all the benefits.
>> Yeah.
>> Awesome. We're learning all about taking
your full framework applications and
containerizing them inside of
a Windows Container and running them in
Azure here on Azure Friday.
[MUSIC]