I guess it is about the good enough principle.
As long as having one docker layer is fast enough there is no need to
improve on it.

My motivation to do the split was that I work from home and my internet
connection is quite bad regarding uploads.
So the size of a docker image to push makes a big difference. (10s vs 2
minutes). So whenever I need to build locally it makes a difference.

When you always do your builds in the cloud in the same region as the
docker registry and the kubernetes cluster it might be less relevant.
Then indeed making the build more efficient might slow you down (at least
initially).

Another case where it matter are large images. For Adobe Experience Manager
our images are still very large (several hundred MB). A more efficient
build can
save terrabytes of space on the registries and make the rollout of changes
quicker.

Christian

Am Mi., 7. Aug. 2019 um 10:20 Uhr schrieb Peter Kriens <
peter.kri...@aqute.biz>:

> Christian,
>
> Yes, for JPM, which feels very long ago, I had a base image and then added
> only an executable JAR as a new layer.
>
> However, since I've seen the stats for porn sites on the Internet the size
> of images got me a lot less worried :-) I've spent a lot of my working life
> trying to make things work in small spaces and trying to make them
> efficient. However, in the last decade I've been bypassed by several people
> that just could not care less about these issues and thereby gained speed.
> So I am trying to also become less obsessed with efficiency because it does
> remove a lot of complexity. Today, quite often keeping it simple and stupid
> is actually good enough.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 7 Aug 2019, at 09:49, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> Hi Peter,
>
> I also thought a bit about how to possibly make the deployments smaller.
>
> I see three possible solutions:
> 1. Put the main version of a system in a docker layer and upgrades in a
> layer on top.
>
> An example where this might make sense is Adobe Experience Manager. You
> put the bundles of AEM 6.5 in one docker layer. Each file name must
> uniquely map to a bundle symbolic name + version (or maven coordinates).
> Then for any updates you overwrite or add the changed bundles in a layer
> on top and overwrite the runbundles list.
>
> Even if you write out the full list of bundles again for any update docker
> will be able to create an effective diff that makes your new docker image
> pretty small.
>
> 2. Put your dependencies in one docker layer and your own bundles in
> another
>
> Typically you have more changes to your own code than changes to
> dependencies. Also typically your own code is much smaller than your
> dependencies.
>
> So this approach can also make your docker images (needed for an upgrade)
> a lot smaller.
>
> 3. Pull bundles from maven repository (maybe with local caching)
>
> In this case you only deploy the list of runbundles with maven coordinates
> and a starter in the docker image. The starter then downloads the bundles
> from a maven repo. To make this fast you would need a local cache of
> bundles that survives restart of a pod. (Not sure how to best achieve this
> for k8s but I am sure it can be done).
>
> What do you think? What concept do you have in mind?
>
> Christian
>
> Am Di., 6. Aug. 2019 um 16:58 Uhr schrieb Peter Kriens via osgi-dev <
> osgi-dev@mail.osgi.org>:
>
>> I don't see any reason why upgrading your existing workflow with a static
>> Docker container and then updating the bundles would not work.
>>
>> However ...
>>
>> Just look at the number of moving parts that you then need in runtime.
>> Creating a Docker image in the build is trivial and deploying it to
>> Kubernetes is, well less than trivial. You need to have a lot of things
>> going right on different systems and much more configuration to make the
>> dynamic update work. All these moving parts can fail.
>>
>> The only issue is size & time. If you need to deploy a full docker image
>> to hundreds of thousands of machines the update can be done more
>> efficiently using OSGi bundles. And actually that is a solution I'm working
>> on at the moment. However, if time/size is not a concern I find a full
>> docker image disturbingly hard to beat. About 5 years ago I ran the 'Java
>> Package Manager' web site on Kubernetes and it worked scarily easy and
>> reliable.
>>
>> When I am hired to help one of the first things I look for is reduce as
>> many of the moving parts as possible. Yes, you can get anything to work but
>> reducing the possible errors cases really increases reliability imho.
>>
>> Kind regards,
>>
>>         Peter Kriens
>>
>>
>> > On 6 Aug 2019, at 16:28, Cristiano via osgi-dev <osgi-dev@mail.osgi.org>
>> wrote:
>> >
>> > Hello all,
>> >
>> > I have a challenged POC to do in order to dockerize an existent OSGi
>> > based application and then deploy it to a Kubernetes based cloud.
>> >
>> > I'm not totally aware of k8 features yet, so I have some doubts that I
>> > would like discuss here.
>> >
>> > The main doubt is related to our existent upgrading process which
>> > currently we upload a R5 repository to a webserver and then a node
>> > management agent bundle access it and upgrades the necessary app
>> bundles.
>> >
>> > Many examples I saw in the web creates a docker image in their building
>> > process and delivery an image at each dev cycle. I don't like much of
>> > this idea, so initially I thought to mimic our existent process in a
>> > docker container just setting up a Volume in order to upload the newer
>> > repositories.
>> >
>> > So I have created two docker images for testing this locally. One image
>> > contains the OSGI container and framework bundle (that do not change
>> > much) and other image that extends the other for only the apps bundles.
>> > it have worked well running locally.
>> >
>> > Would this also work in K8 ?  What would happen if I need to scale and
>> > then create multiple PODS for this application?
>> >
>> > thanks for any help.
>> >
>> > best regards,
>> >
>> > Cristiano
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to