microsoft
AzNamingTool - suggestion for override logic
Hi,
If I wanted to implement the tool as part of a build system, I would like to receive the newest version of resourcetypes.json & resourcelocations.json (i.e. from mcr.microsoft.com). At the same time, I would like to be able to override a subset of resourcetypes.json and resourcelocations.json with values from my own settings.
Would it be possible to enhance the application to allow this kind of behaviour? Maybe with files like resourcetypes_ovveride.json resourcelocations_override.json where my changes are saved?
Thanks
Hi @andreabisiach, Thank you for your feedback! The JSON files within the tool are heavily customized to combine lots of different aspects for resource types (name, short name, regex, invalid characters, etc.). Currently, this process is done manually, as all the information required is in several different locations. We have been working with various Microsoft teams to centralize this, whoever, the process will continue to be manual for the foreseeable future.
That being said, you are able to modify the resourcetypes.json, if you want. This is the process that happens with the naming tool and all of the JSON files:
- After installation, the site will look at the /repository folder.
- For each file it finds, it will look to see if a file of the same name exists in the /settings folder
- If the file is not in /settings folder, it will copy the file from the /repository folder to the /settings folder
- If it already exists in the /settings folder, it will be skipped
This process allows you to have a "customizable" version of every JSON file in your /settings folder. This will only ever be updated if you choose to do so (using the "Reset" option on the Configuration page for the component). When you use the Configuration page, you are actually modifying your respective JSON in your /settings folder, so everything is retained. Because of this, you don't have to do any sort of "override", as the site is already suing your custom copy.
It is possible for you to populate your /settings files with your own versions of the JSON, however, the Azure Naming Tool requires very specific JSON schema to operate properly. If you choose to integrate the updating of the resourcetypes.json or resourcelocations.json files, you would have to be sure it contained all the appropriate elements. I HIGHLY recommend against this, as the resourcetypes.json is such a curated file that the Azure Naming Tool is doing for you.
I hope that explanation addressed your questions. I know it's verbose, however, it such an important part of the tool I wanted to be as clear as I could. Please let me know if you have any questions!
- Bryan
Hi @BryanSoltis ,
thank you a lot for the detailed explanation. I probably did not explain my suggestion correctly, I will try with a practical step-by-step example of what I meant as solution/suggestion
- I install and start the AzNamingTool first time
- All files in the repository folder except resourcestypes.json and resourcelocations.json are copied in the settings folder (if not present already)
- I decide to modify the short name for Web/sites/slots from "slot" to "slt"
- Using the configuration interface, I edit the resource type Web/sites/slots and assign it the slt short name.
- The single configuration change is now saved into settings/resourcetypes.json
- The API and Web interface load resources from repository/resourcestypes.json and apply customizations from settings/resourcestypes.json
- Microsoft updates the file repository/resourcestypes.json with newer entries.
- The API and Web interface now present the new entries and apply the customizations only where necessary.
Basically a mechanism to receive updates from Microsoft (new resources, new locations) but still retaining local customizations.
/Andrea
Hi Andrea,
OK, I believe I understand your feedback now. You are suggesting always loading the resourcetypes.json/resourcelocations.json from a public location, and then allowing an override capability for the desired types/locations you want to modify. This is an interesting concept, however, it does conflict with the overall goal of having a tool that could be completely self-contained (not even requiring internet access), if desired. The tool does currently allow the types and locations to be modified (to an extent). Additionally, the tool does allow the ability to update the resource types from the official GitHub repo, if needed. This process does add any new types to your local installation, ensuring you are up to date. We will soon be deploying an update that include a notification within the tool for Admins if their installation is out of date.
I will be sure to add your suggestions to our next team meeting and we will discuss. Thank you again for your feedback!
- Bryan
Hi @BryanSoltis , yes, that was the idea and also in conjunction with being able to pull a docker image of AzNamingTool from mcr.microsoft.com during an (Infrastructure as code) build, thus receiving the most up-to-date list of resources and locating, overriding some values with locally maintained changes and using the container to calculate azure resources names to be built automatically using ansible/terraform/bicep.
Please add my suggestion and thanks a lot for your time. Reach out to me if you need more details on this.
/Andrea
Great ides. We are working on getting the image included in mcr.microsoft.com, however, it's a bit of a process that will take some time. We know many people will want to deploy the tool as a container, so we are constantly looking for ways to imporve the deployment experience for any time of scenario.
We are also in the process of several updates to the tool and documentation. We will be publishing these changes in the next few weeks, however, I wanted to share with you a very easy way to get the tool running as an App Service (non-container), with continuous deployment from GitHub. This process is by far the easiest to way to deploy the tool and have it running in Azure: (this will be in the GitHub documentation with images when we publish the latest code)
Run as an Azure App Service (.NET application, non-container)
This process will allow you to deploy the Azure Naming Tool as a .NET application in an Azure App Service. This is the fastest deployment option and allows you to deploy and utilize your installation in minutes. This process includes creating a fork of the repository, then creatin an Azure App Service with direct integration to your repo. This will create a GitHub Action to deploy your repository code on every commit.
- Click on the CloudAdoptionFramework link to open the root of this repository.
- Click the Fork option in the top right menu.
- Select your desired Owner and Repository name and click Create fork.
- In the Azure Portal, create a new resource.
- Search for Web App and select Create.
- On the Create tab, select the following options:
- RuntimeStack: .NET 6 (LTS)
- Operating Systems: Linux (For lowest cost)
- Select desired options for all other settings and click Next.
- On the Deployment tab, select the following options:
- Continuous deployment: Enable
- Authenticate to your GitHub account
- Organization: Your desired organization
- Repository: Your desired repository
- Branch: Your desired branch
- Click Review + create.
- After the site is deployed, it is recommended that you enable Authentication on the app service. Choose your desired identity provider to ensure only authorized users can access your site.
- In your GitHub repo, select the Actions tab.
- Review the new GitHub Action workflow definition file.
- On your Settings tab, review the new *Secret value for your deployment.
- Access the site using your Azure App Service URL
- Bryan
Thanks a lot @BryanSoltis
That is a great suggestion while waiting for the container version. I will look into it.
Have a great day Andrea
Hi @BryanSoltis,
I was wondering if you are still planning to publish the AzNamingTool image in mcr.microsoft.com? Also any thoughts on the override logic I had explained earlier? Any plans in that direction?
Cheers Andrea
Hi Andrea,
We are still working on getting the Azure Naming Tool added to mcr.microsoft.com. I'm actually working with that team now and hopefully will have an update soon.
As far as your other suggestion, we are still valuating. Changing how the tool loads resource type details would be a significant change, so we are evaluating if this is something we want to implement. We will be sure to publish any changes in future releases, if we do move forward with it.
- Bryan
This issue has been added to our backlog and will be considered for a future update.