The following post (on stackoverflow.com):
Design of Application in Azure Service Fabric
suggested that it is possible to have side by side installation of same application type with a different version. I tried to install a new version of application (fabric:/ServiceFabApp1 with a new version of 2.0.0 and of ServiceFabApp1Type) on my local cluster (that already has same application name with same application type with version 1.0.3 i.e. fabric:/ServiceFabApp1 with a existing version of 1.0.3 and of ServiceFabApp1Type) and got following error:
An application with name 'fabric:/ServiceFabApp1' already exists, its Type is 'ServiceFabApp1Type' and Version is
'1.0.3'.
You must first remove the existing application before a new application can be deployed or provide
a new name for the application.
Is this by design that application type (for multiple versions) can be same but the application name must be different for each version? Or it simply does not work on the local cluster but works in the azure cloud? Or is my interpretation of the information in the above link is incorrect?
Application types (eg. ServiceFabricApp1Type) can have one or more versions but an application instance (eg. fabric:/ServiceFabricApp1) can only be running one version at a time.
Thus, if you want to have two different versions of your application type running in your local cluster, you will need two different application instances, such that you can have, say, fabric://ServiceFabricApp1 running version 1.0.0 and fabric:/ServiceFabricApp2 running version 2.0.0. The easiest way to do this with the VS tools is to create two application parameters files, each of which defines a distinct app instance name. You can then choose which of the current instances to target with the current version that you're building. To move back and forth between versions of the type in VS, you'll probably want to just create a branch for each.
When you deploy a SF application, there are several steps:
1. Copying application package to the service SF image store
2. Provision application
3. Deploy/upgrade application
Step #1 is just copying the package to the SF cluster image store.
Step #2 provisions a new version of the application so that SF can either deploy that application, or upgrade an existing application if it has already been deployed.
Step #3 depends on what you've done before. If you have already deployed version X of your app, you can't deploy version X+1. You can only upgrade/downgrade.
If you need to run multiple instances of applications with the same version, you'll need to create different packages where name of the app is a unique name (a multi-tenant scenario).
Related
I have a service fabric application type deployed to a cluster. This is working ok. I have recently refactored the code and and changed the deployed application-name from A.. to B.. i.e. changed the application name in the type. After deploying to the cluster the following error is shown:
The update of 'ServiceTypeName' is not allowed. Current value 'A..' , Target value 'B..'. (Code: UpdateNotAllowed).
Any idea how to fix it I have tried deleting the old application type from the cluster before the update but that hasn't help.
Deploy a new instance (instead of upgrading) and use backup & restore to copy the data.
In Service Fabric cluster, If application has multiple versions(say 1.0.0,1.0.1,1.0.2), then how can we shift the application to one version to another version(say active is 1.0.0, then I wanted to shift to 1.0.1) with out redeploying the application. Is there a PowerShell command to do this?
You should be able to use the PowerShell command
Start-ServiceFabricApplicationUpgrade
This being said I did hit an issue with my local cluster, telling me I couldn't upgrade / roll back the application if the service description had changed, which it hadn't. Using an Azure hosted cluster this worked as expected, perhaps an inconsistency with how the package is copied into the image store.
Depending on what you are attempting to achieve you could also look at named instance where you are able to deploy multiple versions of an application at once, for A - B testing.
Here are some similar posts:
Post 1
Post 2
EDIT:
Thanks to Aleksey L for the comment below. With a bit of messing around due to types not being the same and as long as you haven't changed any parameters between versions this will work,if you have you will need to manually build up the hash table.
I understand this might be an easy solution, but I am very new to this so any help would be appreciated.
I have been running through the hello world application for node.js with managed vms on google compute engine, and I have just done this stage
gcloud preview app deploy app.yaml --promote
Which has allowed me to put up the app, and it works.
BUT HOW do I now update that code? If I run that command again it starts up new instances and essentially treats it like a new upload.
You can deploy the updated version of your app by running the same command you used to deploy the app the first time, as indicate in this article:
If you update your app, you can deploy the updated version by entering the same command you used to deploy the app the first time. The new deployment creates a new version of your app and promotes it to the default version. The older versions of your app remain, as do their associated VM instances. Be aware that all of these app versions and VM instances are billable resources. For information about deleting or stopping your VM instances, see Cleaning up.
Just in case anyone found this question looking for the same information, I finally seemingly worked out how to do it.
You need to attach the --version flag when you are deploying, instead of using --promote.
You can find the default version in google cloud console, by going menu (burger icon) -> app engine -> versions and you will see in that list one item with (default) by it.
so then when deploying put that version string after --version and it will deploy without needlessly creating new things
So I cannot wrap my head around clustering in Websphere. The first issue I'm having is starting the deployment manager. To start it I need a profile. To create the profile I found this command within IBM documentation:
manageprofiles.sh -create -templatePath profileTemplates/dmgr/ -isDefault
-profileName dmgr
But profileTemplates/dmgr/ does not exist, does it exist in a different place, or have i missed something while installing Websphere?
If you see only "default" and "management" directories under WAS_HOME/profileTemplates then most likely this is BASE edition. You can run versionInfo command from WAS_HOME/bin and for Network Deployment it should show some thing like
Name IBM WebSphere Application Server Network Deployment
Version 8.5.5.1
ID ND
The ID is showing ND. If your ID shows BASE /Express then there would be no option to create Deployment Manager profile. You would need to install ND code.
To download Trial version of WebSphere Application Server Network Deployment
http://www.ibm.com/developerworks/downloads/ws/wasnetwork/
To download Licensed version from Passport Advantage
http://www-01.ibm.com/support/docview.wss?uid=swg27038624
VS, opinions are my own and not those of my employer
I have a question regarding to Setup Projects in .Net (c# language, Framework 4.0):
I made a setup project for a Windows Service, on the installation wizard, the user must input the name of the Windows Service as it would be installed. The setup program also creates a shortcut to the Uninstall program in case the user wants to remove that Windows Service.
The question is: how to let the user run the same setup program several times specifing different service name?
This behaviour could be required because the windows service is a socket consumer that connects to a server and retrieves data; to take advantage of the server capabilities the user could install the same windows service multiple times pointing to a different port on the server, to perform the data retrieving task much faster. The service is the same, the user just modify the port on the configuration file of the service, so that's why it's not logical to create a new version of the installer each time.
Any clue or suggestion would be appreciated, thanks in advance.
This can be done by using an multiple instances installation. The general approach is:
create a transform for each instance you want available to the user
use a custom EXE bootstrapper which applies a new transform to your MSI package each time a new instance is installed
The transform should change at least the PackageCode, ProductCode and UpgradeCode.
This is not supported by Visual Studio setup projects. So either you do it manually or use a commercial setup authoring tool which supports multiple instances.