I have a simple Spring/Gradle/Liberty REST service that I would like to deploy on several different servers, with each deployment having different resources (e.g., connection parameters). Is there some way to keep the resource folder(s) separately from the .war, so that I can build and deploy the same .war to all deployments and only supply somehow the per-deployment resource folders?
Related
We recently started using APIM in Azure to host a few APIs available via a gateway. However, this is just 1 environment.
How does everyone handle APIM changes across multiple dev and production environments? SCM configuration that API provides acts as a repo but only for 1 Service.
Can different APIs be templatized across different APIM instances and environments?
How is everyone keeping copies of redundant policy files?
My approach is to define everything with bicep and manage the deployments to multiple environments via pipelines.
You can have one set of bicep scripts that define all common areas, like APIM Service, products/subscriptions, common named values, global policy, backends, etc. This would allow you to provision a new environment when need be and would allow you to have all the benefits of the source control.
And then you should have a different set of bicep scripts that are responsible for publishing individual api, ie swagger file, operational policies, which products the api belongs to, etc. You could create a common publishing api yaml template that would be referenced by APIs own pipelines
No APIM changes should be done directly via azure portal, but rather via CI/CD pipelines.
So I've got a scenario where numerous different teams are deploying with octopus to local team boxes. Octopus is used to make the deployment. However I'm facing a problem where octopus is deploying to a separate drive to our IIS pool for our web apps.
Is it possible to set IIS to be configured for the alternative path without disrupting the other applications in the pool. It's not an option to change the deployment location as it would disrupt other groups. Because at the moment we're forced to copy it to the correct location after it deploys to the wrong location.
If you are packaging for msdeploy zip file, you should use common msdeploy options. You should add your octopus project iisapplicationname parameter and give it the specificied pool name with environment names. it will be deployed to the correct folders.
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"
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.
we want to deploy a webrole on the Azure cloud service (PaaS)
we have multiple Virtual Applications that have exactly the same codebase (dlls) but different web.configs
this leads to multiple time the same dll's in the package to upload; resulting in a very large package file
is there any way to share the bin folder for these 'same' Virtual Applications to minimize the size of the package?
greetings,
Tim
Create a cloud application with one web role containing the codebase and additional web roles containing only the Web.config for the multiple virtual applications.
On ServiceDefinition.csdef, define the virtual applications for the roles as required.
Set a startup task to copy the contents from the complete web role to each of the additional virtual applications. This will be executed at role initialization time, with administrator privileges.
This way your deployment package won't need to include multiple copies of the same artifacts, and the virtual applications will be set up when the role instance is initialized.
Is it possible for you to load your configuration settings based on the host header or incoming request?
In the past we had configuration settings stored in Azure Blob Storage that were loaded (and then cached) based upon the host header. This allows you to load what is identically the same site except for the specific settings for that client.
In essence this is a multi-tenant application.