I have an application that was pushed to the Liberty runtime via the packaged server deployment method and I understand that some of the default features provided by Liberty will change in one of the upcoming buildpack updates. Will this change in default features provided adversely affect my packaged server deployment?
If you're deploying/restaging your application in a manner other than a packaged server or a server directory, then the change in the default feature set might affect your application. This is due to the changes in spec levels in the new default feature sets. However, if you used the "packaged server" or the server directory method for deploying your app then you will not be affected. This is because the features you put in your server.xml will still get picked up due to the fact that the buildpack will provide Java 6 & 7 features.
If you need more information about the new default features added to the buildpack, how to make your app resilient to the changes, and even how to "preview" the new buildpack for testing purposes, see the link below:
https://developer.ibm.com/bluemix/2015/09/08/upcoming-liberty-for-java-buildpack-changes/
Related
I am developing a number of microservices which will run on Open Liberty. I have set up a test server in my eclipse environment which is configured to use all the features required by all the services which I am currently working on.
Whilst this works, it seems a heavy-handed approach and it would be good to test each service in an environment which closely resembles the target server. The services can differ in the set of features they require as well as the JVM settings necessary.
Each service will run in its own docker container and the docker configuration is defined in each project.
Is there a way to better test these services without explicitly setting up a new server for each individual service?
I am not aware of any way to segment the Liberty runtime (its features) nor the jvm (for different jvm settings) for different applications running in a single Liberty instance.
You can set app specific variables and retrieve them using MP Config, but that's not the same as jvm settings and certainly not the same as trying to segment specific features of the runtime to a specific application.
However, in general when testing, I would highly recommend trying to mimic your production environment as much as possible. Since you're planning on deploying into docker, I would do the same locally when testing, and given Liberty's lightweight, composable nature, it's unlikely that you'll hit resource issues locally when doing this (you should only enable the features on each Liberty instance that your app is using to minimize the size of that instance). This approach is one of the big benefits/value provided by containers and Liberty.
In other words, even if you could have one Liberty instance segmented per application, I would not recommend it for your testing because, as you said, "it would be good to test each service in an environment which closely resembles the target server"
Google Compute Platform
I've got an Angular (2) app and a Node.js middleware (Loopback) running as Services in an App Engine in a project.
For the database, we have a Compute Engine running PostgreSQL in that same project.
What we want
The testing has gone well, and we now want to have a test version (for ongoing upgrade testing/demo/etc) and a release deployment that is more stable for our initial internal clients.
We are going to use a different database in psql for the release version, but could use the same server for our test and deployed apps.
Should we....?
create another GCP project and another gcloud setup on my local box to deploy to that new project for our release deployment,
or is it better to deploy multiple versions of the services to the single project with different prefixes - and how do I do that?
Cost is a big concern for our little nonprofit. :)
My recommendation is the following:
Create two projects, one for each database instance. You can mess around all you want in the test project, and don't have to worry about messing up your prod deployment. You would need to store your database credentials securely somewhere. A possible solution is to use Google Cloud Project Metadata, so your code can stay the same between projects.
When you are ready to deploy to production, I would recommend deploying a new version of your App Engine app in the production project, but not promoting it to the default.
gcloud app deploy --no-promote
This means customers will still go to the old version, but the new version will be deployed so you can make sure everything is working. After that, you can slowly (or quickly) move traffic over to the new version.
At about 8:45 into this video, traffic splitting is demoed:
https://vimeo.com/180426390
Also, I would recommend aggressively shutting down unused App Engine Flexible deployments to save costs. You can read more here.
I have an application that was pushed to the Liberty runtime via the packaged server deployment method. In the future, if I make changes to my code without having to change my server.xml, do I still have to build a package and deploy the same way? Or can I just Commit and Push my changes from Eclipse or DevOps straight into Bluemix?
you still have to push your application using the packaged server deployment method, because even if the push action uploads only what needs to be updated, it makes a full restaging once the upload is completed.
By this way, if you push only your application files without using the packaged server deployment method, it will use its server.xml template overwriting all your previous customizations.
If you are using IBM Eclipse Tools for Bluemix you can take advantage of incremental publishing support by putting your packaged server in development mode. Right click on your packaged server and select Enable Development Mode. Once enabled, you can make changes to applications that are deployed on the packaged server and then once you are finished with the changes, right click on the Bluemix server and select Publish. No re-push is required and only changed files will be copied over to the Bluemix server saving a lot of time. See the following for more details: http://www-01.ibm.com/support/knowledgecenter/SS8PJ7_9.5.0/com.ibm.etools.iwd.doc/topics/tincrementalpublish.html. As you mentioned, if you change the server configuration (server.xml) then you will need to re-push the packaged server. Incremental publishing is supported for applications deployed directly to Liberty on Bluemix as well.
I have developed a feature using sharepont 2010, feature Scope is "Web", feature Deployment Target is "WebApplication"(Deployement Target has been set throw Package->Advanced->Add->Add Assembly from Project Output->Deployment Target as "WebApplication).
In this feature using "SPWebConfigModification" class updating web.config file.
My concern is below:
1)After deploying it should go to particular "web" since its a "WebApplication" deployemnt but this feature is availabe in all the web apllication in the server, even though if we go to Central Admin->System Setting->Manage Farm solution, we can see this .wsp file has been deployed to particular web application not Globally Deployed. I think this looks strange. My requirement is, the feature should be available in one web application not in all web application. Can somebody point me out pls whats wrong in this or how can we do this?
This has to do with the property ActivateOnDefault in the feature manifest file, this property ONLY applies to features scoped at Farm and Web Application levels. Any feature (Farm or WebApplication) with that setting set to True will automatically activate on all web applications when you deploy the WSP solution. This property is set to true by default.
Read more about it here:
http://www.sharepoint.bg/radi/post/Activate-on-Default-confusion-and-features-scoped-at-Web-Application-level.aspx
I am trying to use maven profiles and filtering in order to produce two different versions of a given web archive (war):
A first one for local deployment to my local machine on localhost
A second one for remote deployment to cloudfoundry
There are a number of properties that differ according to whether the app is deployed to my local machine or to cloudfoundry.
Of course the difficult bit is that I am trying to do all this from STS/Eclipse and deploy from Eclipse to my local tomcat and to cloudfoundry...
Can anyone please provide advice, tips or suggestions?
If you are using Spring versioning 3.1+ the "profile" attribute for <beans> in the spring bean configuration xml would be the best choice. Take a look at the doc here: http://docs.cloudfoundry.com/frameworks/java/spring/spring.html#using-spring-profiles-to-conditionalize-cloud-foundry-configuration
Basically you need to specify at least 2 elements. One for your local properties (profile="default") and one for the properties when deployed to CF. The latter one should be defined as <beans profile="cloud">. When running locally the properties within "cloud" would be ignored and properties in "default" will take effect. When pushed to CF, CF will detect the profile named "cloud" and, which is better, inject corresponding datasource connection info of the services provisioned by CF itself. You can find the detailed CF-specified properties in that doc as well.
For more information about the profile attribute, see the doc here: http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
Consider having a single project per artifact generated. Hence one project generating your local deployment and one project generating your cloudfoundry deployment.
Overlays (http://maven.apache.org/plugins/maven-war-plugin/overlays.html) is the officially sanctioned way to bake in extra files in an existing WAR file, giving a new WAR artifact. Very useful but may be too slow for comfort while developing.