There are two publishing instances and one is recently down. An advice is to start a clean publishing instance and let the sync happen automatically.
The situation is, two publishing instances are not clustered now and there are quite a few bundles installed.
My question is, if I try to start a clean publishing instance as advised, do I need to do anything to make it exactly the same as the running one? like the followings:
republish the pages
manually install OSGi bundles
configure publishing agent (if url and port number remains the same)
Anything is appreciated.
You're not far off in my opinion.
Some minor additions:
You don't need to install the site-specific osgi bundles manually,
you can replicate them (after configuring the replication agent) from
the author instance.
Re-Publish the pages using tree-activiation.
Related
On Jelastic, I created a node for building an application (maven), there are several identical environments (NGINX + Spring Boot), the difference is in binding to its database and configured SSL.
The task is to ensure that after building the application (* .jar), deploy at the same time go to these several environments, how to implement it?
When editing a project, it is possible to specify only one environment, multi-selection is not provided.
it`s allowed to specify just one environment
We suggest creating a few environments using one Repository branch, and run updates by API https://docs.jelastic.com/api/#!/api/environment.Vcs-method-Update pushing whole code to VCS.
It's possible to use CloudScripting technology for attaching custom logic to onAfterBuildProject event and deploying the project to additional environments after build is complete. Please check this JPS as an example of the code syntax. Most likely you will need to use DeployProject API method.
Using HyperLedger Composer 0.19.1, I can't find a way to undeploy my business network. I don't necessarily want to upgrade to a newer version each time, but rather replacing the one deployed with a fix in the JS code for instance. Any replacement for the undeploy command that existed before?
There is no replacement for the old undeploy command, and in fact it it not really undeploy - merely hiding the old network.
Be aware that everytime you upgrade a network it creates a new Docker Image and Container so you may want to tidy these up periodically. (You could also try to delete the BNA from the Peer servers but these are very small in comparison to the docker images.)
It might not help your situation, but if you are rapidly developing and iterating you could try this in the online Playground or local Playground with the Web profile - this is fast and does not create any new images/containers.
I am looking for any best practices and/or recommendations around how best to manage releases for custom modules in a production environment running on the Spring-XD platform.
Specifically, if I have a custom module foo-1.0.0 deployed into a farm of xd containers and I wish to rev it to version foo-1.1.0. What are my alternatives? I gather the following might work (from looking at other questions and docs):
Assuming a shared filesystem/directory for each server/container the custom module jar can be replaced and the container will pick up the new version without a need to restart the server. Will this work? Does this mean the jar name needs to be the same or will it work with versioned named jars?
Maintain a duplicate/mirrored container envs so that one set of containers can be updated by properly removing the stream/job/modules and then bring up the environment up with the updated module version etc... (though this is expensive from a hardware perspective) basically doing a rolling upgrade of sorts
Any other ways?
An ancillary question might be about how easy is it to expose the version of the custom module being used by a given container?
Any thoughts would be appreciated.
Thanks,
Mark
In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...
But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.
So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?
It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.
I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.
Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:
asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear
There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv
Hope this helps.
I want to setup two Hudson Masters on the same Hardware. This will make administering Hudson easier, since both servers are used by two different (and independent) teams.
So far I tried to install one server as a service. I verified the installation and it is running ok. I than copied the installation into another path and changed the service information (different service Name and description) and the httpPort. I then create the service, once using sc.exe create and once using hudson.exe install. In both cases the server started. However, the configuration page acted goofy. So this approach is either not working at all or I missed another configuration file.
Does anyone has an idea how to accomplish this?
I tried the same approach as documented in the question but avoided the copying of the original installation. So I created two folders and put a copy of hudson.war in it. Then I performed the following steps for both folders.
Start Hudson with java -jar hudson.war
Installed Hudson as a service using the web UI
went into the Hudson Base Dir and ran hudson uninstall
modified the port and the Service information in hudson.xml
installed the service through command line hudson install
Now I have two services and the first quick test looks promising.
May I suggest:
run two instances of Tomcat
have each Tomcat running on its own HTTP port
deploy HUDSON.WAR in each Tomcat
set CATALINA_OPTS for each Tomcat to point to a different HUDSON_HOME