I have several Karaf-Containers in different environments, each with 50+ services deployed, and I´m looking for an easy way to compare the versions in each environment.
Is it possible to retrieve a list of all deployed services including the specific version via the jmx-Interface?
You can use the BundlesMBean with objectName org.apache.karaf:type=bundle,name=root.
The attribute Bundles returns Tabular data that contains among other details Symbolic Name and Version.
Simply try with jconsole. It is easy to connect to a local karaf installation.
Related
According to Jelastic documentation it is possible to export the Environment configuration and download it so it can be restored in another provider
However I have tried with 2 Jelastic providers and they both have disabled the option for exporting private data.
So exporting/download/upload/import of environment is not possible.
i.e. I was expecting to have a process similar to CPanel backup/restore tool
In fact, another view for the deployment process gives a possibility to get rid of the model of handling the data or configuration on the platform. Try to think a bit differently and using CI/CD approach. The Jelastic provides a platform where something you created, locate on somewhere you're elaborating(VCS or GIT as an example) and based on or depends on the specific stack, already pre-configured like a layer and can be installed(copied) over Jelastic. Don't need to handle the data somewhere in the cloud because you have it locally(means within any VCS) and doing the changes there. Then just do a 'pull' procedure(manually or automatically) on that deployment(test, production, staging) environment you're expecting.
Moreover, you can expect any environments type like a code and perform it creating before deploying the data.
Please, find the articles being described each case:
Deployment Guide
Jelastic Packaging Standard for CI/CD Automation
In case you would like to handle the databases' backups, check this article:
Scheduling Database Backups
Additional FTP add-on can make the copies more easily for each instance:
FTP/FTPS Support in Jelastic
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.
I was wondering if there is anyway that different versions of zabbix agent can runned on a windows server.
The documentation mentions something about multiple "intances" but doesnt look like this is creating any more services.
I've tried running version 3.2 alongside 2.4 on a test server but only one service can run at a time, if I try and start service 2, I'll get:
As you can see from the screen shoot the service have different names and calling diferent version of the executable.
Both services run, just not at the same time.
You can't run multiple agents on the same ListenPort. Use different ports per agent instance.
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.