I have service fabric up and running in Azure. Also I have Visual Studio solution with two projects: Service Fabric and Web Service.
I would like to deploy the service to the service fabric in azure.
When I right-click my service fabric project and click "Publish", the service smoothly deploys to the cloud fabric. I would like to do the same with PowerShell.
It seems I need to run this script:
# Connect to the cluster using a client certificate.
Connect-ServiceFabricCluster -ConnectionEndpoint $endpoint `
-KeepAliveIntervalInSec 10 `
-X509Credential -ServerCertThumbprint $thumbprint `
-FindType FindByThumbprint -FindValue $thumbprint `
-StoreLocation CurrentUser -StoreName My
# Copy the application package to the cluster image store.
Copy-ServiceFabricApplicationPackage $packagepath -ImageStoreConnectionString fabric:ImageStore -ApplicationPackagePathInImageStore $packagename
# Register the application type.
Register-ServiceFabricApplicationType -ApplicationPathInImageStore $packagename
# Create the service instance.
$appName = <name that I see in fabric explorer under 'typeName' in azure>
New-ServiceFabricService -ApplicationName fabric:/$appName -ServiceName fabric:/$appName/MyApp -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount -1
Prior to running the script I right click my fabric app and select "Package".
The very last command of my script fails with "application not found"
What can be missing?
Once you have the package build and ready, you can try the below commands in order to deploy the pkg using PowerShell Script.
If you haven't tried the below option, try this and see if it works.
There are few prerequisites that's needed in order to run the script :
You have your cluster up and running.
Cluster has all necessary certificates deployed (such as for SSL
endpoints, if any)
You have ARM template and parameters files ready.
You have the necessary permissions for deployment of new resources,
namely the Contributor role (on the level of subscription or resource
group)
You have the destination resource group created
Once you check the above, execute the following commands:
Copy-ServiceFabricApplicationPackage
Register-ServiceFabricApplicationType
New-ServiceFabricApplication
If that doesn't work for you, go through the below sites to see if it helps .
Deploy applications using PowerShell
Deploy resources with Resource Manager templates and Azure PowerShell
The problem was that I used wrong ApplicationName and ServiceName in the command New-ServiceFabricService.
In order to find out what correct values are, I ran Get-ServiceFabricApplication and Get-ServiceFabricService.
These pages were very helpful for building troubleshooting the scripts:
Deploy and remove applications using PowerShell
Service Fabric application upgrade using PowerShell
Related
I have an installation of Azure DevOps Server 2020.1.1 which is running on a EC2 windows virtual machine (Server 2019). I have been able to install an instance of the agent that is running as a build agent but when I try to install a copy of the agent as an Environment agent it is giving me VS30063: You are not authorized to access . I have a valid PAT that has been given full permissions. When I installed the build agent I had to give the url as https://[FQDN]/Sandbox where Sandbox is the name of my collection, however when installing an Environment agent it doesn't like this format of the url and insists on it being https://[FQDN]. I have configured IIS to only have the https binding and have allowed both Anonymous Authentication and Windows Authentication. The FQDN exists in DNS but is overwritten in the hosts file because of a network load balancer that the FQDN points to which sits in front of the server, this is because the NLB did not like traffic coming from the server and going back to itself.
Can someone please help me with what I need to do to allow access using the PAT token.
BTW the PAT was generated for a user that is an administrator as configured in the Azure DevOps console.
The command that I run in powershell is:
.\config.cmd --environment `
--agent ${Env:computername} `
--url "$(${Env:AZP_URL})" `
--auth PAT `
--token "$(Get-Content ${Env:AZP_TOKEN_FILE})" `
--work '_work' `
--sslskipcertvalidation `
--runasservice `
--environmentname ${Env:AZP_ENVIRONMENT_NAME} `
--collectionname ${Env:AZP_COLLECTION_NAME} `
--projectname ${Env:AZP_PROJECT_NAME} `
--addvirtualmachineresourcetags `
--virtualmachineresourcetags ${Env:AZP_ENVIRONMENT_TAGS}
I am trying to do this in a docker container but have also tried running the agent install directly on the server and get the same error there as well.
The problem is that by default the PAT organization level is set to current Collection level scope (in your scenario, it should be https://[FQDN]/Sandbox). But in the script to setup Environment agent, the URL is specified to the server level (https://[FQDN]).
So, in this case, you need to edit the PAT and change the organization level to “All accessible organizations”.
I am setting up an integration tests build where I am just trying to start up a windows service.
I have used the InvokeProcess command to run the powershell scripts which just does the following
Start-Service ServiceName
The script fails when I run the build process but when I executed the same script outside TFS it works. I get the following error in TFS logs
Start-Service : Service 'ServiceName (ServiceName)' cannot be started due to the following error: Cannot open ServiceName
service on computer '.'.
Then I tried changing the way I am starting the service and used SC.exe with parameters "Start ServiceName" in the InvokeProcess and I get Access Denied error in TFS as follows:-
SC start ServiceName.
[SC] StartService: OpenService FAILED 5:
Access is denied.
I am using Network Service account to run the build.
After searching a while, I have come to the conclusion that I have to run the InvokeProcess with elevated privileges but I don't know how would I do that with in TFS.
Any help is much appreciated.
We run our build agent as a custom service account and give that domain account admin access on the servers we deploy to.
I have resolved the issue by adding Network Service account to the administrator group. I might not go with this solution as it seems wrong to assign administrative rights to Network Service account but I don't know how to assign Service Start/Stop permissions to Network Service without adding this account to Administrator group.
In short, I agree with the answer that a custom service account must be used to run the build with appropriate privileges.
I have a build agent set up on a VM in Azure, that is linked to our Visual Studio Online.
I then have an Azure Powershell build step that runs a script that tries to execute New-AzureResourceGroup.
This results in the following:
New-AzureResourceGroup : Unauthorized
113 ##[error]At C:\BuildAgents\agent\_work\[...]\Deploy-AzureResourceGroup.ps1:47 char:1
114 ##[error]+ New-AzureResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation ...
115 ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
116 ##[error]+ CategoryInfo : CloseError: (:) [New-AzureResourceGroup], CloudException
117 ##[error]+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.NewAzureResourceGroupCommand
I can run these scripts locally with no problem.
I have tried importing a publish settings file in the script, but it seems New-AzureResourceGroup is not allowed authentication this way.
I run the build agent as a service under a local user account (not network service).
Does anyone know how to allow the build agent execute New-AzureResourceGroup?
I hope to be able to do a full continuous deployment including setting up and managing everything needed in Azure, including the resource groups.
UPDATE
According to the article below:
"If you connect using this method [publish settings file], you can only use the Azure Service Management (or the ASM mode) commands."
https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-connect/
I'm assuming this applies to Azure powershell as well.
So, is there really no way of managing resources in azure without using account based authentication?
UPDATE
Thanks to #bmoore-msft for providing the missing piece. I'll just add another screen shot of the link I needed to find to set up the build to run under an actual account.
In Azure Resource Manager you do have to use Azure Active Directory authentication, no certs. So that applies to cli, PowerShell, REST APIs, etc.
In VSO there is a build task for Azure PowerShell. When you use that task you specify a "connection" or subscription to execute the task as... so you save the creds in VSO. You could use a regular PowerShell task, but then you would have to secure the creds yourself.
Finally, when you set up the account connection in VSO, it must be an orgID, MSAs are not supported (PowerShell limitation). Service Principal support is coming.
I also had a lot of trouble using the Azure Resource Manager with VSO.
I finally found a working solution to my problem by creating a Service Principal account with enough rights on the Azure subscription to deploy from Visual Studio Online.
I used this blog post from David Ebbo to create the Service Principal Account: http://blog.davidebbo.com/2014/12/azure-service-principal.html
In VSO I removed the "Azure PowerShell" step and replaced it with a "PowerShell" step. In the PowerShell script I start with logging in the Service Principal account and then deploy my applications using Azure Resource Manager.
More details of my findings can be found on the MSDN forum: https://social.msdn.microsoft.com/Forums/azure/en-US/d5a940e0-ed83-46ff-9efc-045fb9522c5b/ad-auth-from-azure-powershell-in-vso-fails-with-accessingwsmetadataexchangefailed?forum=azurescripting
How can I use Powershell to shutdown a Virtual Machine created using the Azure Preview Portal when there is no Cloud Service Name? i.e. what do I put for the ServiceName parameter...
Thanks!
If it's a vm created using the resource manager api (and I guess it is if it doesn't have a cloud service), you need to switch to the resource manager mode in Powershell and access your vms from there:
Switch-AzureMode -Name AzureResourceManager
$vms = Get-AzureVM
The service I wish to upgrade is in a resource group and my user account is configured as an owner of that resource group. The user account is limited to only access the one resource group.
I can successfully update the cloud service using the new management portal by uploading a cspkg and a cscfg file.
I'm trying to automate this process using Azure Powershell.
This is what I've tried so far:
Set-AzureDeployment -Upgrade -ServiceName test-service -Configuration C:\temp\test-service.cscfg -Package "https://test-service.blob.core.windows.net/azurepowershelldeploy/test-package.cspkg" -Slot Production -Mode Auto -Label test-2015-07-28T00:33:04
ForbiddenError: The server failed to authenticate the request.
Verify that the certificate is valid and is associated with this subscription.
Having a look in fiddler, it's making a request to this endpoint, and getting back a 403 forbidden.
POST /xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx/services/hostedservices/test-service/deploymentslots/Production/?comp=upgrade HTTP/1.1
I believe the ASM API's don't work properly with resource groups. Is there a method to update a cloud service using the new ARM API's?
You can deploy, update or delete all of the resources for your application in a single, coordinated operation using ARM.
You would redeploy your ARM template to an existing RG using:New-AzureResourceGroupDeployment
The New-AzureResourceGroupDeployment cmdlet adds a deployment to an existing resource group, including the resources that the deployment needs. This cmdlet is similar to the New-AzureResourceGroup cmdlet, but it works on existing resource groups, instead of new ones. To add a single resource to a resource group, use the New-AzureResource cmdlet.
A good walk through for your scenario (with a few changes) is at: Provision and deploy microservices predictably in Azure
This tutorial shows how to provision and deploy an application composed of microservices in Azure App Service as a single unit and in a predictable manner using JSON resource group templates and PowerShell scripting.
Instead of using an app service resource in the RG template, use the types of resources you'd need. Then call the above New-AzureResourceGroupDeployment cmdlet instead of New-AzureResourceGroup cmdlet.