We currently have an Azure account set up through a third party who happens to be a CSP. As expected, this took several hours to set up and configure.
We're looking to move from that CSP partner to an account that we manage ourselves. The feedback we're getting is that that's not something easily done.
Has anyone experienced difficulties moving from a CSP to a pay as you go subscription, or is this company we're dealing with holding something back? I obviously want to avoid the several hours of re-setting up all of our resources.
Migrating resources across accounts are not something I have seen done. But you may get the Azure resource manager template for each resource. See attached link.
At the same time I would encourage you to implement infrastructure as code as part of your best practice for development in your organization. Infrastructure as Code is a process of managing and provisioning computing infrastructure in Azure with some declarative approach while setting their configuration using definition files instead of traditional interactive configuration tools.
The key benefits of IaC are:
Consistently achieve standardised provisioning or deployment
Accelerating provisioning or deployment rapidly
Reusable JSON code for repeatable or similar provisioning or deployment
Extensible JSON code for incorporating with additional items
Export template: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-export-template
Infrastructure as code: https://blogs.msdn.microsoft.com/azuredev/2017/02/11/iac-on-azure-an-introduction-of-infrastructure-as-code-iac-with-azure-resource-manager-arm-template/
Related
I need to walk the resources in an Azure Subscription and determine the dependencies of those resources, i.e. this LogicApp connects to or is triggered by that Service Bus topic, or, that API connects to this SQL Server etc.
I realise I could use the dependsOn attribute in the ARM template, but that may not be a true representation of all the resources in the subscription being parsed.
Does anyone know of a tool that can build a dependency graph?, or, Does anyone know if Azure Powershell provides enough information that can help me build a dependency graph of my own?
There is nothing built into Azure itself, but there are a few options that may help depending on your requirements.
There is an open source ARM visualizer at http://armviz.io/designer. You can import an ARM template and then it will create the diagram of your resources. There is a walkthrough available at https://blogs.msdn.microsoft.com/azureedu/2016/03/09/how-can-i-map-my-existing-azure-arm-resources-visually/.
There is another more fully featured resource visualizer that covers multiple cloud platforms at https://www.cloudockit.com/, but it is not free to use.
There are some other similar visualization tools that you might be interested in for helping visualize and manage your applications and infrastructure rather than just your Azure resources.
Application Map in Application Insights - https://learn.microsoft.com/en-us/azure/application-insights/app-insights-app-map. It provides a more application centric architecture view rather than an infrastructure view and provides additional runtime insights such as performance and errors.
Service Map in Operations Management Suite - https://learn.microsoft.com/en-us/azure/operations-management-suite/operations-management-suite-walkthrough-servicemap. This provides a more machine oriented infrastructure view showing the different connections and dependencies that a VM has.
You can also use Azure Resource Graph for this, but there isn't a list or built-in way to automatically detect all of the dependencies so you would have to build out this logic yourself. There is a starter sample at https://learn.microsoft.com/en-us/azure/governance/resource-graph/samples/advanced?tabs=azure-cli#list-virtual-machines-with-their-network-interface-and-public-ip.
We would like have a DR and staging subscriptions at my Azure. Also we do not want to pay for not used resources. We have Continuous deployment server. We would like to have the same deployment process in different environments.
Process
1.We read the current live subscription configuration from Azure resource manager
2.Modify some parts
3.Create DR and Staging
4.Deactivate them when not used using API calls triggered from the Continuous deployment server
5.Activate them when not used using API calls triggered from the Continuous deployment server
From time to time we are updating the resources.
Questions
What are the best practices ?
What are the API calls we can use?
I would argue that this is not possible (I might be wrong, never tried disabling subscription with active resources and see what happens) and not viable (for sure).
First of all, most PaaS offering cannot be switched off in Azure. That means you cannot achieve what you want (well, unless you can disable the entire sub and enable it after with all the resources starting to work like nothing happened). To try and figure the REST call to disable the sub I would go and capture the rest request with fiddler and try to reproduce it. Because I'm quite sure this call is not documented
The route I would go in this case - I would create ARM templates to make deployments repeatable and use those to deploy needed resources into prod\dev\stage\whatever with a flip of a switch. This would allow you to have the same deployment process you crave for.
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
We are a small company and are still unsure how to start all this azure stuff.
Ok, we are clear on the technicalities like table storage and queues and all the that stuff, what we don't know about at all is how to set up the organization around developing for our developers. Which/how many azure accounts, shared or individual ones.
So far we've done classic windows development, so everyone has his environment, unit tests run either locally or on the build server (after pushing to mercurial or git), deployment from the build server.
The thing is that we want to use Azure not just as a hoster, but the full set, like blob/document/table storage, event hubs, storage queues, ReliableActors and everything. Things we can't do locally.
What's the appropriate way for azure then? There are about 20 to 30 developers and most have the enterprise msdn subscription.
What is a "company or organisation" account for? Should developers have their own accounts? Does DevOps need their passwords for all the bamboo or jenkins build stuff?
I went through this recently and I can share a few tips here since I'm also not aware of a DevOps specific platform to share this on StackExhange.
As far as organizing your subscriptions go look at Azure Pay-As-You-Go Dev/Test Subscriptions link
or Enterprise Dev/Test link if you are an Enterprise Agreement customer. These are aimed at development teams, you get discounted rates since you don't pay for software licenses that are already included in your MSDN subscription.
It is best to use individual developer subscriptions for exploration, POC etc while running your main dev workload in the Dev-Test subscription. It looks tempting to try and save a buck by spreading the work across multiple MSDN subscriptions to use the credits but I wouldn't recommend it. It becomes a pain to manage 20~30 subscriptions and they can run out of credits and things stop working. If you remove the spending limit on all the subscriptions you run the risk of racking up a huge bill accidently if multiple devs leave VMs on or add premium storage to VMs etc.
As far as DevOps go, use RBAC and Azure Active Directory to manage access and certificates for your DevOps tooling, build servers, release management etc don't use individual developer credentials for this.
And I agree with the other comments, get in touch with MS as well, this is just the tip of the iceberg but it will get you started.
We started using Azure platform. Especially we are having issues in Web Sites platform. How we give different kinds of access to our development team.
Right now the development team could access the production deployment slots.
We need to be able specify the access to the system according to their roles in the organization.
Have your development team use their own subscription for development. That way, they never have access to your production environment. This is something I personally practice and recommend to customers.
This gives you the added benefit of also separating development and QA costs with your production deployment costs. In development, you may choose to use smaller and fewer instances (to control costs). Yet, in production, you may prefer larger and more instances (to meet demand). Having a separate subscription for each enables these options for you.
This is also an approach demonstrated in the Patterns and Practices Guide. It's a little dated and is in the context of Cloud Services (not Websites). But, the overarching principles still apply.
Microsoft has Role-Based Access Control in the roadmap for the new Azure portal but have not committed to any target dates.
If you're using Azure AD to manage Azure access there are some different roles available there.
Edit: Basic RBAC functionality was added to the new Azure Portal back in September.