So, I do have an installation of Apache Karaf 3.0.4 with a root instance and two child instances. First child is the productive one and the other one was cloned from that for a testing environment.
Both child instances are run as Windows services via the wrapper, the root is stopped.
The instances serve as runtime for some Apache Camel routes compiled as OSGi bundles as jar-files. The bundles are deployed by copying them to the deploy folder of the respective instance.
My Problem is, that if I'm deploying to either instance the bundle will also be installed to the other instance.
For example,
I'm running a 1.0.0 in prod and 1.0.1-SNAPSHOT in test
and
I'm undeploying the 1.0.0 and deploying a 1.0.1 to prod
the result is, that prod is prod is running 1.0.1 - as expected - and test will be running 1.0.1-SNAPSHOT and the release of 1.0.1.
Could somebody point me towards at what causes that behaviour? Is it something related to the test-instance being a clone? Is there any config I need to check?
Thanks in advance, h.
I tried to recreate your scenario.
instance:create prod
instance:clone prod test
instance:list
The test instance seems to have the same ssh port as prod. It also seems to use the same KARAF_BASE dir. So it also uses the same deploy folder.
I think you should not use clone to create the test instance.
Related
I have two SAM applications, both of which have a set of Python Lambdas in common. I have a different template file for each application.
When I run sam deploy for the first one it correctly deploys the Lambdas with their dependencies. For the second it only deploys the application code.
I can see all the dependencies correctly there in the .aws-sam/build directory.
Using --debug doesn't give me any useful information.
How do I go about debugging this?
Should the zip files that it deploys be available somewhere on my local system, and if so where?
I have created an application on Play framework 2.5.6. I am trying to find out what is the best way to deploy the application on production. I have tomcat installed on my Ubuntu machine. How to create war file and How to deploy on tomcat? I am using Scala Eclipse IDE for development.
Have a look at this other thread which is very similar to what you're asking here (albeit directed at GAE).
In a nutshell, the disadvantages of deploying your app to Tomcat are:-
you have extra work to do to package your application as a WAR
extra work to deploy it
your application may not be fully asynchronous running in Tomcat
As that outdated documentation suggests - the simplest way of deploying your app in production is just using the version of Netty which is packaged as part of a Play application. See the relevant version of the docs to create a distribution. You only need a relevant version of a JVM on your prod server in this case.
The flow is generally:-
Run $ dist to build the binary (this is a zip by default, but you can also build a tar if you prefer using $ universal:packageZipTarball instead of dist).
Move it into your Linux production environment
Unpack it
Set permissions if you build a zip $ chmod +x /path/to/bin/<project-name> (not required if you created the tar)
Run the app start script (created by the dist task) eg. $ target/universal/stage/bin/<project-name>
I have a Service Fabric application with a few services underneath it. They are all currently sitting at version 1.0.0.
I deploy an update out to the cluster for version 2.0.0. Everything is running fine and the deployment succeeds. I notice a very large but in the version. Is there a way to manually rollback to version 1.0.0? The only thing I have found is automatic rollback during an upgrade.
Matt's answer is correct, but I'll elaborate a bit on it here.
The key is in understanding the different steps during application deployment:
Copy
Register
Create
Upgrade
Visual Studio rolls these up into single "publish" and "upgrade" operations to make it easy and convenient. But these are actually individual commands in the Service Fabric management API (through PowerShell, C# or HTTP). Let's take a quick look at what these steps are:
Copy:
This just takes your compiled application package and copies it up to the cluster. No big deal.
Register:
This is the important step in your case. Register basically tells the cluster that it can now create instances of your application. Most importantly, you can register multiple versions of the same application. At this point, your applications aren't running yet.
Create:
This is where instances of your registered applications are created and start running.
Before we get to upgrade, let's look at what's on your cluster. The first time you go through this deployment process with version 1.0.0 of your application (call it FooType), you'll have just that one type registered:
FooType 1.0.0
Now you're ready to upgrade. You first copy your new application package with a new version (2.0.0) up to the cluster. Then, you register the new version of your application. Now you have two versions of that type registered:
FooType 1.0.0
FooType 2.0.0
Then when you run the upgrade command, Service Fabric takes your instance of 1.0.0 and upgrades it to 2.0.0. If you need to roll it back once the upgrade is complete, you simply use the same upgrade command to "upgrade" the application instance from 2.0.0 back to 1.0.0. You can do this because 1.0.0 is still registered in the cluster. Note that the version numbers are in fact not meaningful to Service Fabric other than that they are different strings. I can use "orange" and "banana" as my version strings if I want.
So the key here is that when you do a "publish" from Visual Studio to upgrade your application, it's doing all of these steps: it's copying, registering, and upgrading. In your case, you don't actually want to re-register 1.0.0 because it's already registered on the cluster. You just want to issue the upgrade command again.
For an even longer explanation, see: Blue/Green Deployments with Azure ServiceFabric
Just follow the same upgrade procedure, but targeting your 1.0.0 version instead. "Rollback" is just an "upgrade" to your older version.
Is it possible to set a remote path (may be a FTP location) as Hot Deployment directory in Karaf environment?
I am aware of the org.apache.felix.fileinstall-deploy.cfg file under Karaf_home/etc. But this seems to be useful for changing the deployment directory to local path only.
Actually I have different Karaf installations running on different machines and I need to deploy my bundle to all instances. To avoid this I was planning to keep the deployment in some FTP location which will be treated as deployment directory for all instances.
Any idea?
I strongly suggest against using the deployment directory for productive environments.
For your usecase I'd rather start using Karaf-Cellar and let it do the deployment across your distributed Karaf installations. This works especially good in conjunction with either a maven repository or a specialized Karaf Instance running also Karaf-Cave that will work as OBR server.
Is there a deployment folder where a war can be placed in the master node so that it gets deployed to all the slave nodes in a domain managed setup in JBoss AS7?
I know that we can use the JBoss CLI to deploy to a server group which places the artifact in the JBOSS_HOME/domain/data//content directory.
However I would like to find out if there is a way that it can be placed in a deployments folder under the domain of the master node (e.g. JBOSS_HOME/domain/deployments) that is similar to the one available in the standalone mode (i.e. JBOSS_HOME/standalone/deployments) so that the deployment scanner picks it up and makes it available to the slave nodes in the domain without the explicit deploy command via CLI.
To summarize the comments above: There is no deployment directory in domain mode.
You can use the CLI
the web console
the maven plugin
or create your own deployment manager.
I wrote a, now old, blog post on how to do this on a standalone server, but it could be slightly changed to use on a domain server. Have a look at how it's done with the jboss-as-maven-plugin for an example.