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