I tend also to use the scenario B even without docker. For me the reason is the ability to restart the container. If I do online updates while a container is running over some time then the chances are high that the container will not come up when it has to be restarted at some point.

A long time ago we had such an issue with a unix server. We udated it for one or two years without ever restarting. Then we moved the server to a new room and it did not come up again. After wondering for some time we found that it booted through an external hard drive that was not attached anymore for more than a year. So from that I learned that it makes sense to kind of practice the full restart from time to time. So a full update is a good chance to do so.

It is also a question of testing the same thing you deploy. If you test on a system that typically is created fresh for each test but then deploy by just replacing some bundles then chances are high that your tests do not reflect the production system.

Christian

Am 26.05.2015 um 17:11 schrieb Frank Langel:
Hi,

I was wondering if someone has used OSGI with Docker & ACE. We are figuring out the best way to use it:

I. Build and Deploy Path

 1. Developer builds and tests bundles locally using BndTools
 2. Commits source code to Git
 3. Git hock triggers CI build on Jenkins build server using Gradle,
    executing integration tests and binary artifacts
 4. Artifacts are uploaded to ORB repository
 5. ACE Feature/distribution is updated with latest versions

Furthermore

 1. Docker (Kubernetes) will be used for scaling out containers. No doubt

This, so far, makes sense to us. My questions would be the following. How do I update an OSGI bundle on small or large scale. I see the following scenarios

Scenario A:
=========

  * ACE agent is installed on each OSGI runtime
  * A docker instance runs a OSGI runtime instance
  * Many different docker instances are deployed
  * Changes to the code (new bundle version) are automatically picked up
  * OSGI handles the temporary downtime of the service when rebinding
    to the new (latest) version of the service provided by the newly
    deployed bundle


Scenario B:
=========

  * For each change(set), a new docker image is created that creates
    the new bundles and may be missing the replaced bundles
  * A changeset consists of >=1 bundles and optionally configuration data
  * Architecture needs to be able to register/deregister/pause
    endpoints dynamically
  * From a deployment perspective, docker instances are never
    upgraded. Rather then modifying an instance, a new docker instance
    is being deployed

We feel that Sceanrio B is a better way forward
Any feedback, comments ?
Thanks a lot in advance
Frank







_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to