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.
Related
It's clear that you can set which roles can deploy to a certain on-premise server thanks to the security settings in Deployment Groups and Agent pools. But, any way of restrict access at webapp level?
The only ways I found are:
Creating a specific account, giving it deploying permissions in target server's IIS in required webapps only and provide this credentials to developers on charge of creating the pipelines for deploying those webapps (they will put them as custom environment vars or similar in pipelines)
Same than 1 but using the created account as a service account for an agent. Access to this agent will be restricted to developers on charge of creating the pipelines for deploying those webapps.
Both cases require to create new accounts and to give permissions on server's IIS. No way of doing this from Azure DevOps on the same way that access to whole servers can be restricted?
Regards.
It's clear that you can set which roles can deploy to a certain
on-premise server thanks to the security settings in Deployment Groups
and Agent pools. But, any way of restrict access at webapp level?
Sorry but as I know Azure Devops Service doesn't support such out-of-box feature.
We can manage the access in Organization level(Organization settings), Project Level(Project settings), Feature Level(Security of Pipelines/Deployment Groups feature...) and even the 'instance Level' (Set security for one specific pipeline/deployment group/one specific git repo).
But the 'instance level' is the lowest level, we can only manage the access in specific pipeline or specific deployment group but not one webapp which will be deployed by pipeline/deploymentGroup.
The webapp is not an option hosted by Azure Devops Service, it's just something to be deployed by pipelines(hosted by Azure Devops Service). So Azure Devops Service avtually have no knowledge about the webapp(it also won't have UI that represents one webapp), that's why we can manage the access in pipeline but not webapp in that pipeline...
Update 1
Once you have only one deployment group for the specific target server, you can determine who can access the deployment group here:
The person who is assigned with reader permission can't use the deployment group to do the deploy.
Ok, following the suggestion from #Lance and after some research, this is what I´m planning to do:
Creating a custom service connection where following fields can be set: IIS Server where the WebApp is, Webapp name, User (with permissions to deployment) and Password.
Together with the Custom Service connection I will provide a custom task where developer team can select the service connection against they want to do the deployment (obviously, server admins will only configure service connections to webapps which this team is allowed to deploy).
Agent will run with a low-privileged account (no way of affecting any app) and the custom task will use internally the creds provided on service connection to perform the deploying.
I think that approach is the best workaround to the initial problem and can be extensible to fix the granularity problem in other kinds of resources (like DB´s, Shared Folders, ...) just simply adding another specific custom service connection (to specify the resource and the deployment credentials) and a linked Custom task which allows deployments only against that resource.
The only drawback is the fact that, if you want to set a deployment approval, you have to do it at resource level (for every webapp, for every DB, ...) and that means that approvers will have to approve resource by resource when deploying also (instead of a single approval for the whole application deployment as, in my understanding, should be)
What do you think guys? Any remark before start coding this?
Regards.
I am working on a powershell script the deploys azure templates that create all manner of resources on azure (resource groups, VMs, network configurations, peerings, runbooks etc) Since I started, I've been mainly running them from my desktop, logging in using my msdn username and password, and from there on the script would have the access it needs.
I've explored Service Principals but I believe those are mainly for deploying Azure Web Apps.
The goal is move my scripts to the Atlassian Bamboo Deployment server, where they can be run by anyone with access to the system. It also greatly helps with continuous integration.
I've been googling but alas, I do not know the terms / correct questions to ask.
My understanding so far on PaaS deployment using WebRoles or Worker Roles-
Spinning Web roles or Worker roles will create Cloud service to manage it.
However, in ARM resource group, their is no concept of Cloud service, then how are web & worker roles managed in ARM resource group?
Also I tried adding the webroles via JSON Outline in VS 2015, but no option to add webroles. So not sure if you can deploy webroles via JSON template?
Any information will be of great help.
Cloud Services have been around since the beginning of Azure.
To the deploy or manage them, you have to use the old APIs (Azure Service Management).
As far as I know, they won't be migrated to the new APIs (Azure Resource Manager), but you could use Virtual Machine Scale Sets instead.
Azure Resource Manager Web apps rely on the concept of App Service Plans, rather than cloud services. Basically this is the underlying VM(s) that the service runs on. You can specify the size and number of servers that make up the App Service plan, and then deploy on to those as a single unit.
You create an App service plan, then run web / worker roles inside that (as well as Logic, API, Functions)
As far as Web / Worker roles are concerned, App Service Plans do not draw a distinction between the two. You simply deploy code to it and it will run it however it is packaged. See here
The concept of cloud services simply don't exist within the Azure Resource Management model.
You can find a template for deploying a Web App here
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.
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.