>> Hey, friends. In the first episode of this two-part series,
we learned about the conceptual framework behind building
a CI/CD Pipeline for your API Management instances.
In this episode, Miou is back to apply that knowledge
and then demonstrate a sample implementation using Azure DevOps.
I'm going to learn all about it today on Azure Friday.
[MUSIC].
>> Hey folks. It's Azure Friday here with Miou,
we're in part two of
understanding how to build a CI/CD pipeline
for Azure API Management.
If you found yourself here somehow and you didn't
watch part one be sure to watch it.
A lot of really good information about
the problems and the solutions.
I really liked the way you broke it down.
Like these are some of the issues that you're going to bump into.
Here is a conceptual solution,
and now we're going to actually see the actual solution.
>> Thank you Scott. Thanks for having me.
So in the last episode, we talked about a conceptual framework
of implementing a CI/CD Pipeline for API Management.
In this episode, I'm going to demonstrate
a simple CI/CD Pipeline that I
implemented by following that approach.
So let's say I'm an API Developer,
and for my organization, I just created a new API.
At this point, I have deployed the back-end to
Azure and I'm ready to publish my API through API Management.
So I've done my research,
I've decided that I want to use
Azure Resource Manager templates to deploy my API.
However, I'm new to this,
so it will take me some time to create my ARM templates.
So this is where our automation tools
or DevOps Resource Kit comes into play.
So in the first demo here,
I'm going to show you how to use the creative tool to create
an ARM template to deploy
my open API specification file for my API.
So let me switch to my VS Code.
So as you can see in my Explorer here,
I have a folder called
foodtrucks-API because my API is called Food Trucks.
Essentially, it returns a list of
food trucks that are available around our office.
So as you can see there are three files here.
The first file is the swagger file to open
API spec for my API. It's very simple.
The second file here is an XML file,
which essentially contains the policy that I want to apply to
this API once it's published
through API Management. So it's very simple.
Just a way to limit policy to add throttling capability.
Also we have a YAML file here,
which essentially is the configuration file for the creator tool.
Essentially, it tells the tool how to create the ARM templates.
As you can see here, I'm saying
that for this API please create an API version set,
and this is automated data for that version set.
Then here are more information about API such as name,
version ID, revision ID.
This is the link to open API spec,
this is the link to that policy XML file,
and then the suffix of this API protocols, products, and so forth.
So at this point,
we have all the input files ready for the creator,
so let's go and run it.
So let me copy this command
and paste here in my terminal, and run it.
So as you can see that the creator is
creating all different template for this API,
and now it has finished.
So if I go to the templates folder here and the foodtrucks API,
there are many templates created for this API.
So I'm going to walk you through these templates in a minute,
but before that I just want to do two more things.
>> All right.
>> The first thing is that, if you remember
in the conceptual framework.
So we have a master template at
a service level which links to all the templates.
So the first step I want to do here is to add
one more step in my master template to include these API.
So let me add that.
So just jumped in a new step to deploy the foodtrucks API.
Now, supposedly, I have all my files ready, I can check,
I can commit my changes to my developer repository which
was formed and cloned from the publisher repository.
So let me add all my files,
and say "Okay" added a new API
committed and "Push" to my developer repository.
The reason I want to do it now because as soon
as the changes are committed,
it will trigger a build and release pipeline in
my Azure DevOps and
it will take sometime I want to click this out fast.
>> Oh good point.
>> Yeah. So at this point while
my build and risk pipeline is running,
so let me walk you through the files
that were generated by the creator.
Let's go back to the Explorer.
So here under template, as you can see,
the first template here is for the version stack for this API.
Then we also have the initial API template,
which essentially creates this API
in API management with automated data such as version,
and revisions, and then so forth.
In the subsequent API template,
it essentially imports the swagger file into this API
and also it applies the policy to this API in the second step.
Then finally, it's associating
this API to the product called a starter,
which was all specified in my configuration file.
Finally, we have a master template for
this particular API which links
to all those templates for this API.
That's what I used in the master template for the service.
>> Okay.
>> So now let's head over to
my Azure DevOps and see how these pipeline is working.
So if I go to "Pipelines",
if I go to "Builds."
Here we can see the build pipeline
for my dev instance currently running.
So if I show its definition, it's very simple.
There are three steps here.
In the first step, it essentially copies all my templates from
my Azure repo into
storage account because ARM cannot
access my files from my private repository,
so I need to copy those files into storage account.
In the second step here,
I'm using the Azure deployment step to actually
validate the syntax of my templates.
Because if you look at the deployment mode here,
I'm using the validation only mode.
So this does not actually deploy those templates,
it just validates the syntax of my templates.
After that, it will publish build artifacts.
So as soon as the build artifacts is published,
it will trigger my release pipeline.
>> What is the artifact if you are only validating?
>> It's essentially just a template,
it will move the templates into artifacts.
>> Okay.
>> So as soon as this has finished,
it will kick off
a release pipeline which is currently running right now.
So if I show you the definition of the release pipeline,
it is super simple just a one-step.
Essentially, it uses the Azure deployment step
again to deploy all my templates.
So this time instead of using the validation only mode,
I'm actually using the incremental mode which will
actually deploy my templates.
>> Is it significant that you run the creator on
your local machine as a dev rather than checking in?
>> Exactly. That's the one thing I didn't do it here.
So you can actually build another automation process.
So as soon as I knew swagger file is checked in,
you can run the creator to generate the template.
>> So it depends on whether or not you want your API creators
to have that piece abstracted away from themselves?
>> Exactly.
>> So you could add that as a stage
in your pipeline depending on how you
want to adopt or change the search model?
>> Exactly.
>> Okay good.
>> Cool. So let's go check on our release.
So it's still running. So it will
take a couple of minutes to finish.
So let's assume that the release has finished and that we have
tested our API in the dev instance and everything looks good.
So at this point, as the API developer,
I want to publish my API
through the production API management instance.
But obviously as we mentioned earlier,
as the API developer I do not have
access to the production API management instance.
So to publish my API to the production instance,
I need to submit
a pull request to the publisher repository to merge my templates.
So let's head over to my Azure repos.
As you can see, it already knows that I have checked in something,
so I can just create a pull request based on that.
So these are all the files I checked in,
so let's just create a pull request.
So as soon as this pull request is submitted,
it will actually call a webhook that I
implemented which will validate the syntax of
my templates and also check the compliance of my templates.
So we just had it back from the validator.
So it says only HTTPS is allowed in protocols.
Apparently, I made a mistake
somewhere so let's go back to VS Code.
>> All right.
>> I'm sorry. To VS Code,
and if we look at my template here.
So in the protocols I said you only use HTTP.
So this is the mistake I made.
So let's make a change here to HTTPS.
So let me check in to change again.
I say, change the protocol and push it to my repository.
So the pull requests should
automatically pick up my change which it did.
So now the validation process is triggered again in a few seconds.
That says approved for merges.
>> That was very fast.
>> Yes. So at this point my job as the API developer has finished.
So let me change my head here, and say,
I'm the API publisher who
manages the production API Management instance.
As API publisher, I just saw okay,
a new pull request came,
so I came to this page and I saw that's
the validation process and I said it's okay to merge it.
I can also manually review all the files again.
So everything looks good, let me merge that.
So as soon as this pull request is merged,
it will trigger another build and
a release pipeline to deploy
the changes to my production instance.
The pipelines very similar to my dev instance.
So I'm not going to show you.
>> Of course.
>> So now you have seen the first demo which essentially I used
the creator to create ARM templates to deploy my API,
and also you've seen the sample CI/CD pipeline of how to
deploy my templates to
the dev instance and then promote that to the production instance.
So as I mentioned earlier,
we also have another tool called extractor,
which can extract your configurations into ARM templates.
So I'm going to show you that. So let's head
over to my API Management instance.
So this is my Dev API Management instance.
I'm going to refresh this page.
So as you can see, our food truck API has just been deployed here.
This is a food truck API.
So in addition to the food truck API,
we also have another API here called the Demo Conference API.
So let's pretend that I manually configured
this Demo Conference API
through the Azure portal and I have
tested it, everything looks good.
So now I want to migrate its configuration from
the dev instance into the production instance.
So I'm going to use the extractor to extract its configuration.
So let's go back to the VS Code,
and let me go to "My Script", copy this command.
Let me enlarge the terminal here.
So now, I'm actually running the extractor.
So as you can see this is
my development API Management instance name,
and I'm saying, okay please extract
this API and please place the files into this folder.
So now it's saying, "One API formed".
So these are all the operations under this API,
and it should take a few seconds to run.
>> To be clear, it's extracting it from a live running instance?
>> Correct.
>> Which API is it using to do the extraction?
>> It's ARM Management API.
>> The Management API.
>> So behind the scenes it's using ARM Management API to get
all the information about APIs and other entities.
>> Wow.
>> So now if we go back to the Explorer here.
So under the conference API,
you can see that a bunch of files have just been created.
So this is the API template, just close it,
this is API template which contains all the information about
these APIs such as operations, things like that.
You can also see the areas of policy folder here,
and there's a XML file
which is actually the policy for this particular APIs.
It's very easy for you to edit your policy here.
As you can see, I have rate limit policy for this API,
and in the counter key attribute,
it actually uses a named value here called the "RateLimitKey".
So if we go to the named value template here,
you can see that the rate limit,
the RateLimitKey is exactly here.
It's because the extractor is
smart enough to know that it needs to
extract all the entities that are used by this API.
So this is how you can use the extractor
to extract your configurations from
a live API Management instance and
migrate your changes to a different environment.
>> So then this becomes
your new source code that you go and move forward in there.
>> Correct.
>> All of this is available,
and it's all opensource.
It's all part of the API Management Resource Kit.
>> That is right.
>> So folks go to aka.ms/apimdevops.
>> Correct.
>> They get involved. They can improve it.
They can change it for themselves,
and offer any thoughts.
>> Yeah. Exactly.
>> This is fantastic. I'm learning
all kinds of great stuff about how to build
a CI/CD Pipeline for Azure API Management.
I hope you've enjoyed both part one and
this one part two today on Azure Friday.
[MUSIC]