We recently started using APIM in Azure to host a few APIs available via a gateway. However, this is just 1 environment.
How does everyone handle APIM changes across multiple dev and production environments? SCM configuration that API provides acts as a repo but only for 1 Service.
Can different APIs be templatized across different APIM instances and environments?
How is everyone keeping copies of redundant policy files?
My approach is to define everything with bicep and manage the deployments to multiple environments via pipelines.
You can have one set of bicep scripts that define all common areas, like APIM Service, products/subscriptions, common named values, global policy, backends, etc. This would allow you to provision a new environment when need be and would allow you to have all the benefits of the source control.
And then you should have a different set of bicep scripts that are responsible for publishing individual api, ie swagger file, operational policies, which products the api belongs to, etc. You could create a common publishing api yaml template that would be referenced by APIs own pipelines
No APIM changes should be done directly via azure portal, but rather via CI/CD pipelines.
Related
We have set up small dev platform on azure which includes servers(sql server, web server) and azure ML. These are protected by azure VPN gateway. Below are the list of azure components we created and configured . Currently we don't need the dev platform to be available but we will need it after 6 months . so is there any way we could take this complete setup as snap shot and store as image or images so that when we need we can just restore it with out doing much configuration
dev platform components to archive and restore
Virtual networks , sub nets, dns, firewalls
VPN gateway , configuration
VM with os and server setup
sql server with data
subscription with custom roles, assignments, cost alerts , dashboards etc
if this is not possible then what are the alternatives
regards,
Suman
Have a look at the different Infrastructure as Code options that are available. Easiest way to 'export' the current situation is to generate an ARM template of the needed resources by going to the resource group and clicking Export template under Automation.
To implement infrastructure as code for your Azure solutions, use Azure Resource Manager templates (ARM templates). The template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. The template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it. In the template, you specify the resources to deploy and the properties for those resources.
To increase the functionality options you have, have a look at Azure Bicep.
We've introduced a new language named Bicep that's used to develop ARM template JSON. Bicep files and JSON templates offer the same capabilities. You can convert templates between the two languages. Bicep provides a syntax that's easier to use for creating templates.
and also
Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. We believe Bicep offers the best authoring experience for your infrastructure-as-code solutions in Azure.
Be advised: this is meant for the resources and their configuration of your environment. For the data side of things, save and/or export the data somewhere you can restore it from easily like Azure Storage.
At the company that i work, they deploy applications to azure using Azure App Services.
This involves creating the App service manually, and setting up the pipelines manually.
My question is if there is another way to host and run applications in Azure without using App Services?
The reason for this is that i don't like the manually work when setting up a app service and all it's configuration.
Any suggestions?
What you actually need is setting up CI/CD pipelines for your application to create resource(AppService in this case) and deploy on them.
If you are new to Azure Devops, i would highly recommend to explore Devops starter service to deploy your application with few clicks and see how it creates resources and pipelines automatically
On the 2nd question, there are many compute options available on Azure such as Virtual Machines , AKS (Containers Orchestration) , Container instances etc.
You can explore those compute options using the decision tree here
I am planning to provision the logic app using terraform script. But the workflow of logic app, I am deploying through the arm templates.
Is this recommended approach?
Can anyone suggest me how to deploy the logic app with business flow?
Logic apps are kind of counter-intuitive when it comes to Terraform. It is an Azure service that is designed to abstract away custom coding with an easy-to-use user interface. Designing something in a user interface often does not work well when using multiple environments (e.g. test, staging, production). This conflicts heavily with one of the main purposes of Terraform: matching infrastructure across multiple environments.
Of course, you can turn to the magic of ARM templates, but mankind did not invent JSON to be readable. And Azure never had a plan to support YAML for ARM templates. So how to proceed from here? I set out our requirements, solution and a terraform example below.
Requirements
Infrastructure is deployed by Terraform.
Infrastructure is deployed in 4 matching environments (i.e. dev, tst, acc, prd).
Configuring parameters for logic apps should be an easy task.
Building logic apps is done in the GUI.
Solution
Create an "empty" logic app resource with azurerm_logic_app_workflow. This resource will be deployed across all environments. It is empty, so you will find the Logic App in the Azure Portal without any content. This means that in your dev environment, you can use the GUI to design the Logic App.
Create a resource which azurerm_resource_group_template_deployment which will only be deployed based on a condition. This condition is true when you supply an arm template path, which will not be the case in the dev environment.
Make sure that azurerm_resource_group_template_deployment depends on azurerm_logic_app_workflow and set deployment_mode = "Incremental". Furthermore you can supply parameters to the logic app by setting parameters_content = jsonencode(var.parameters_map).
Example
A working terraform example can be found on Github.
Note: another high-level Azure service is Data Factory, which faces the same problems when it comes to automatic deployments using Terraform.
We are working on following within Azure portal
Azure Functions
Data Factory
Logic Apps
Storage account (not files)
Now as we are done with development, we need to deploy these azure resources in client's UAT environment
I looked around (might be missing something) and found that deployment of Azure resources is not straightforward.
In Azure, it is like another subscription, correct?
So found this blog, which works with different PowerShell scripts to copies from one subscription to another
This is the right approach? & it cover everything required for resources to execute flawless (I still need to go thru scripts) for e.g. permissions, Data Factory datasets, etc?
Any other way to deploy (kind of export & import)?
Basically what you need is to create a reusable arm template, your question lacks some details yet ARM templates are the way of automated deployment in Azure, on a high-level
start by authoring your arm template to deploy the vanilla required resources look here
https://learn.microsoft.com/en-us/azure/templates/microsoft.web/sites/functions
https://learn.microsoft.com/en-us/azure/templates/microsoft.datafactory/factories
https://learn.microsoft.com/en-us/azure/templates/microsoft.logic/integrationaccounts
https://learn.microsoft.com/en-us/azure/templates/microsoft.datalakeanalytics/accounts/storageaccounts
you can combine all of them in one big template using ARM template dependency and other functions
look here
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions
after you finish ARM templates can be used in many ways including PowerShell, direct API calls or even you can create a deployment in Azure and save it to be reused with a click
look here, also if there will be a high volume of users consider adding it to market place.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/
after finishing your implementation of vanilla resources you can then move into adding any customization you might have.
this is the right and best way to do "afaik"
also look here to see all of your existing resources in an arm template view
https://resources.azure.com/
my understanding of Azure is that almost everything with some few exceptions has an ARM template representation
hope this would help.
I have an existing App Service created in Azure, which has a connection string linking to the database, 'Easy Tables' configured, and a whole bunch of custom API methods and table definitions done via the 'App Service Editor'.
I'm at a stage in development where I need to use deployment slots, in order to have separate environments for development, test, and eventually live.
On creating a deployment slot, I have the option of 'Configuration Source' - where I can clone an existing application.
I select my existing app when I choose this option, however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Considering that I already do have everything set up in the App Service, how can I transfer the Easy Tables and API methods over to the new deployment slot without recreating each file one by one.
The end goal that I am trying to achieve is an exact duplication of my current web app - pointing to a separate database, having it's own collection of API calls and easy tables - all using the existing app as a starting point, with a URL different to the existing app.
however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Answer in short yes. According the Set up staging environments in Azure App Service, we could know the if we choose WebApp as Configuration Source, it copies the configuration info such connectionstring setting, appsetting etc. not the content of the WebApp.
There is no content after deployment slot creation. You can deploy to the slot from a different repository branch, or an altogether different repository. You can also change the slot's configuration. Use the publish profile or deployment credentials associated with the deployment slot for content updates. For example, you can publish to this slot with git.