Our developers need to publish a worker role to Azure and be able to get the diagnostics information if there's problem. The network admin suggests this requires the developers to log into Azure portal and upload packages and he doesn't want to do it because developers would need full admin rights.
Is this correct? This doesn't sound right. All we need to do is publish a newly created worker role to Azure -- preferrably directly from Visual Studio.
We also need to see any errors our new worker role may generate.
How should we go about it? Do we have to keep generating packages and giving them to the network admin and wait to hear from him?
Ideally you shouldn't ever be publishing into a prod environment directly from Visual Studio - it's certainly possible though. The better bet is deploy via a build server which is configured to deploy into a Worker Role. This way you remove the need for a co-admin level of access for your developers.
If you want to capture errors from a Web or Worker Role (aka a Cloud Service) then you can use Azure Diagnostics to write the logs to an Azure Blob Storage account.
Related
We have a situation where we are in development and experiencing a lot of delay and resistance from the Azure admin which is creating costly delays and impacting deadlines.
I would like to create our own Azure subscription to allow us to fully admin our environment and pipelines as we see fit, without needing to go through the aforementioned resource. The admin can link our Dev subscription to their corporate AD later.
We already have some projects in VSTS, build scripts, began some CD development.
Obviously on a new subscription we would just recreate the pipelines and resources. However, since it would be a new AD, how would this impact our ability to still view content and resources in VSTS?
Link the new AD to the projects?
You can easily associate a VSTS instance with a different Azure subscription, no need to recreate anything. This can be done via the Azure Portal. It can still be connected to the same Azure AD.
I need to assign publish permission to one of my developers so that he should be able to publish to only one cloud service & do not affect others.
Azure websites have these concepts called download publishing profile.
I could not find anything similar for cloud service. Can it be
achieved?
As you know Azure Management Portal does not have any role defined where we could map a user account login to manage a set of resources (say cloud service 1 & 2)
It is not possible as of today. It seems that it should be possible with Resource Groups and Role Based Access Control (RBAC) however currently cloud services can't be added in resource groups and assigned RBAC.
One way you could achieve this is have a custom application consuming Service Management API and implement your own RBAC in that application. However it is still a "hack" and not proper solution.
Why don't you try using "publish from source control"? When the developer checks in it will auto publish the code.
I believe the new portal will allow the creation of roles for publishing profiles; it already allows adding additional users to your organization; but to get what you want for now; publishing from source code should do the trick.
We have developed and tested our webroles in our Free trial Azure cloud.
We now have to deploy the webroles to Company A Azure cloud. Company A is open to creating IIS VMs for our deployment but will not share username/pwds with us to publish our Webroles to their cloud.
This should be a pretty common scenario, would like to hear from folks who have solved it in their deployments.
How do we publish web roles to a pre-existing VM?
This isn't how Web Roles work. A Web Role (along with any other defined roles) is essentially a bundle of code, startup scripts, binaries, etc. that are needed on the VM. The VM itself is stateless: It's started up as a fresh (up to date) copy of Windows Server, and your code is executed. Anything needing install is done via your startup scripts.
You cannot push a Web Role independently to an existing Virtual Machine. You'd need to take your actual code project (e.g. asp.net) and publish that to a pre-existing VM, without any of the Web Role scaffolding. How you do that would be up to you (and the folks who are managing these VMs).
I guess there is a confusion with different concepts.
From what I understand you have already deployed your cloud service and associated web roles to a trial azure subscription. You were able to do that because you are the admin of the subscription. If you need to deploy the same set of roles and the cloud service to one of your customers azure subscription they will need to setup your account as a co-admin so you can follow the same deployment procedure you did with your trial subscription. They don't need to give you a user/pass pair. They just need to give your LiveID or appropriate credentials a temporary co-admin permission to do the deployment on their behalf. They can do this in the azure management portal.
I created an empty Azure cloud service and I want to allow other developers to deploy to it. So far the only route I can see is adding the developers as Azure subscription administrators. I would rather give them more specific access to the cloud services only.
No such functionality exist today which will allow you to grant/revoke permissions at the cloud service level. Once a developer is provided access to the subscription, they would have access to all the resources under that subscription.
There's a REST API behind cloud service deployments and all the tools (including Windows Azure Portal and Visual Studio) consume this API for creating deployments. One possible solution would be to build your own solution consuming this API. In this solution you will implement access control based on your requirements so that when your user use this service, they will only see the cloud service they're assigned to and can only manage that cloud service. There's a managed library for consuming this API. You can find more information here: http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries.
It seems that if the original developer downloads the publish profile from Azure (it's an xml file that with a .PublishSettings extension), you can copy the userPWD from that file, give it to another developer and they can paste it into the password field in the Connection section of the Publish dialog.
The userPWD is a string that looks something like this:
EFFCLfDqDKHlXcA2YDZPvX4BZXWFaobxaLN0aPJd4HCfa8WxlqEkt2yywBsx
I want to outsource the development of a WordPress website that will be hosted in Azure. Is there a way to create a Cloud Service that I can give someone access to, but at the same time not giving them my Azure subscription credentials?
From an Azure subscription perspective, you can only grant co-admin privilege; a co-admin gets full access to a subscription. This leaves you with a few options (I'm sure you can think of others):
Set up a separate subscription solely for the outsourced WordPress work. At completion of project, you can choose to remove the co-admin rights of the subscription
Grant admin access to the WordPress site, along with specific Azure resource keys (e.g. storage account namespace+key; service bus, MySQL credentials, etc.) for your developer to do the work. You can always change access keys once the project is completed
Have your developer set up WordPress in their own subscription, and then transfer the contents to your subscription when the project is complete.
EDIT - I slightly misunderstood the question, and was thinking the outsourced dev needed certain subscription-level resources. As Mike pointed out, source control is a good solution for Web Sites. You'd still need to set up resources such as Storage accounts if you don't want to set them up as co-admin.
If you are using Cloud Services then you could set up continuous integration between TFS and your cloud service. This would allow you to give the other person their own accounts to your TFS source code. Thus they check in and trigger the build, and it deploys. They don't have access.
If you don't have to have Cloud Service then you also have the same option with Windows Azure Web Sites (it's under development so this should be fine to run in even under the free, and bump up if you want to load test, etc.). With that you can give ftp access only, or also set up TFS or GIT source control integration.