I have three projects in a single solution that I want to deploy using RM DSC:
a Windows service
webUI
and a DB project
For the deployment, I have three Azure servers:
a SQL box
and two App servers
Currently I am able to deploy all three projects successfully in all three servers, but for some new directions from the boss man, I have to deploy my projects as follows:
Windows service project into all three servers
the WebUI into one of the App servers and
The DB project into the SQL box.
My ultimate goal here is copying files that are needed on each of the destination servers only.
For example, I would like to only keep the DB files into the DB server and similarly the WebUI files only in the App server.
You may want to checkout: continuous-deployment-using-dsc-with-minimal-change
Basically, you can use configuration to choose a "server" role type and install different packages for each. However, I find it easier to have a DSC per role type (a.k.a web role versus DB role) to encapsulate functionality (even at the cost of some duplication).
There are a few examples on web for DB install/etc, here is an example of website install: DSC Web Install
I do agree with #Graham Smith, however, on separating deployment from provisioning (vm creation and configuration). I would focus your DSCs on
the configuration aspect of provision and use a second step in your overall
process to deploy with msdeploy and a tool like fluentmigrator for DB.
EDIT: Added file upload option that works well on Azure (this pattern could be followed for non azure vm's too)
One way I've found to upload files is to wrap the required files in a DSC Resource. For example,
Create a DSC resource that contains file/files you want to access. I've created an example that contains Erlang that I use for installation here
Import the module DSC resource in your DSC: Import-DscResource -ModuleName Erlang
Ensure DSC resource is in your module path
Use Publish-AzureVMDscConfiguration to create zip (that will contain imported DSC Resource).
Your DSC Resource will be in module path "$env:ProgramFiles\WindowsPowerShell\Modules\Erlang\otp_win32_17.5.exe"
Related
I am wondering if there is an easy way to incorporate an extra tool to one of the default Microsoft hosted agent pools (specifically VS2017).
Basically, I want to add some of the extra ARM powershell modules that are not installed by default as only the core set of modules are installed; i.e. I am looking to leverage some of the extra modules such as AAD as part of the deplyment pipeline, e.g. to create an AAD role definition.
I guess the same would be true for CLI extensions if I was using the CLI instead of PS.
Essentially, I am wondering if I have to use my own agent on a self hosted agent pool (my own VMs) or if I can just add the extra modules to the microsoft hosted agent pool VMs as part of the deployment pipeline, perhaps as a task?
For PowerShell modules, you can just use Install-Module in an inline script (or at the start of your existing scripts) to ensure they're installed. That, of course, assumes the modules are in the PowerShell Gallery.
Worst case, just put the modules you need in source control and publish them as an artifact along with everything else so you can load them up.
I want to run tests using real SQL databases. The SQL server and the databases would be on Azure. I'm trying to configure a build definition on VSTS where the tasks would set up an Azure resource group with the databases, set the connection strings on my solution and run the Entity Framework Core migrations to the databases. After the tests a task should delete the resource group.
I created an Azure resource group with the databases I need and downloaded the PowerShell deployment files, the script, template.json and so on.
The PowerShell script task can have an inline script or a path to the script. Should I add the Powershell scripts to the solution so that the VSTS could access them? The inline script option seems to be for small few line scripts and the Azure deployment is quite big with multiple files.
Setting up the connection strings shouldn't be too difficult. Several people suggest using the Replace Tokens task from the market place.
I'm not sure how to run the database migrations after that. Can I run the migrations on PowerShell script task? How can I ensure that the needed cmdlets work?
Since the script is quite big, you can’t use Inline script, you can add it to the project or other path of server (Add additional mapping for different path).
Regarding database migration, if you enabled EF migration in a web app, you can create a publish profile (web deploy package) with database migration enabled, then publish/deploy with /p:DeployOnBuild=true /p:PublishProfile=[profile name];DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\webEF.zip" MSBuild arguments, then deploy package to Azure Web APP through Azure Web Deploy task.
Sometimes in our website which is deployed on Azure web roles, issue comes related to small bugs in javascript and HTML. We go to all instances of webroles and fix these JS and HTML file on machines.
But I was looking into some automated way of doing this, downloading the files to patch from some central location and replace the files in all azure web roles. I am using ASP .net MVC for website.
It is possible to redeploy the website with the patch in the package but we don't want to wait for long deployment time. Please let me know if it is possible via some internal WEB API which replaces the content on all azure web roles.
There are 2 ways to deploy a new webrole:
redeploy
inplace update
The first one is the slowest, meaning new VM's are booted.
With inplace upgrade (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-update-azure-service/)
The new application package is mounted on a new drive (usually F: instead of E:) and the IIS website is swapped to the new drive.
You can try this by going to the old portal and upload a new application package. In just a few seconds/minutes the update is done.
After digging many things on stackoverflow, I crafted my own solution which is creating a topic and subscribing to the topic in code when website starts. When I want to patch the web app then I send a message to Topic to start patching then each machine in the web roles will get notification from topic and start patching themselves. Patching itself is very easy, which is going to a web storage and downloading files from there and replacing files in approot.
When azure maintenance happens this patching may go away, so for this situation I made patching work started at start up of website too.
Cloud service deployment packages tend to be slow since they are basically a recipe on how to build and configure your deployment. The deployment not only puts the recipe out in Azure (so it can be used again if it needs to move your machine), but also follows the recipe to build out a VM for your Cloud Service (WebRoles/WorkerRoles are platform as a service so you don't have to worry about the OS and infrastructure level like you would if you were using the Virtual Machine Azure product but they do still run in VMs on physical hardware).
What you are looking to do is something that will update the recipe (your cloud service package) and your deployment after it is out and running already ... there is no simple way to do that in Cloud Services.
However, yes you could create a startup script that could pull the site files from blob storage or some other centralized location - this would compare to how applications (fiddler for example) look for updates then know how to update and replace themselves. For that sort of feature you will likely need to run code as an elevated user - one nice thing about startup scripts are they can run as an elevated user - so they can do about anything you need done on a machine (but will require you to restart the instance for them to run). Basically you would need to write some code that will allow your site to update itself. This link may help: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-startup-tasks/
If you have the ability to migrate to WebApps and WebJobs, I would recommend looking into that since that compute product solves your problem really well.
Here is a useful answer of the differences between WebApps and Cloud Services: What is the difference between an Azure Web Site and an Azure Web Role
I got a cloud service (worker role) which I want to deploy to a beta and a production environment.
It seems a waste to have to create three projects (one with the actual implementation and two for deployment).
Is it possible to create two deployment profiles which links to different Azure destinations but uses the same worker role project?
This is very simple to do. Just build your Azure package without deploying, and keep your dev/beta/prod settings in the Service Configuration, not embedded anywhere like web.config/app.config. Then store both the deployment package and configuration in blob storage (speeding up deployment). You'll want multiple configuration files: one for each environment, each stored separately in blob storage.
Once this is done, you can just deploy the package to multiple cloud services, each with a different configuration file. This can be done either through the portal or through PowerShell / CLI.
If you've been deploying directly from Visual Studio, it might not seem quite as obvious. But from VS, you can build a package without actually deploying.
I have two Azure VM's running in a cloud service. They contains almost the same thing. Some TCP port's are also opened between them.
Is it possible to create a deploy package from this existing setup so that at a later time can deploy this setup in an easy way. I.e. I want to be able to do this:
1. Create deploy package from existing setup *
2. Delete whole existing cloud service including VM's
3. Deploy the package from step 1 and have everything created again.
*I can save one of the VM's to my Azure storage and use it as template for both of them if that is easier.
How to accomplish this if it is possible?
Yes, you can take what you have as a template and use it to stand up multiple silos. But in IaaS, there isn't a notion of a deployment package. There's a few things you'll need to do...
1) understand how to take an existing VM and turn it into an image
2) use Powershell or another DevOps style automation suite (Chef/Puppet/etc..) to define deploy your silo.
You seem specifically interested in how to create an image so I'd recommend using the tutorial we have published on this. http://www.windowsazure.com/en-us/documentation/articles/virtual-machines-capture-image-windows-server/ This does of course presume you're running Windows Server. But a Linux version it can be found at: http://www.windowsazure.com/en-us/documentation/articles/virtual-machines-linux-capture-image/
The automation of a deployment depends on a great many things, so I'd suggest at a starting point, familiarizing yourself with the management API: http://msdn.microsoft.com/en-us/library/windowsazure/ee460799.aspx
With the implementation of Resource Manager, you can now easily use JSON template to deploy and redeploy resources in Azure. There are also starter templates available - https://azure.microsoft.com/en-us/documentation/templates/