Update a runtime image

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Update a runtime image

Thomas Brand
Hello, I have a question related to jlink.

In a scenario where a runnable image created with jlink is installed, and
it should be updated, what are good strategies for doing this?

I think if an update will introduce new dependencies this will be
different to updates that are known to be satisfied with what is already
in the image.

The idea is to 'ship' just a small sort of diff / replacement part that
can be applied to the 'old' image to become 'new'.

Thanks for any insights, and happy silvester / new year!
Thomas


Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Alan Bateman
On 31/12/2017 15:42, Thomas Brand wrote:

> Hello, I have a question related to jlink.
>
> In a scenario where a runnable image created with jlink is installed, and
> it should be updated, what are good strategies for doing this?
>
> I think if an update will introduce new dependencies this will be
> different to updates that are known to be satisfied with what is already
> in the image.
>
> The idea is to 'ship' just a small sort of diff / replacement part that
> can be applied to the 'old' image to become 'new'.
>
The jlink tool always generates a new run-time image, there is no
support at this time to install additional modules into a run-time image.

-Alan.
Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

forax
jlink is not a distribution tool,
you need to use a tool on top of jlink, in the past, i've used the rpm format for that.

We have stopped to distribute deltas when we have moved to docker that as far as i know as no concept of incremental update.

Rémi

----- Mail original -----
> De: "Alan Bateman" <[hidden email]>
> À: "Thomas Brand" <[hidden email]>, "jigsaw-dev" <[hidden email]>
> Envoyé: Dimanche 31 Décembre 2017 16:55:37
> Objet: Re: Update a runtime image

> On 31/12/2017 15:42, Thomas Brand wrote:
>> Hello, I have a question related to jlink.
>>
>> In a scenario where a runnable image created with jlink is installed, and
>> it should be updated, what are good strategies for doing this?
>>
>> I think if an update will introduce new dependencies this will be
>> different to updates that are known to be satisfied with what is already
>> in the image.
>>
>> The idea is to 'ship' just a small sort of diff / replacement part that
>> can be applied to the 'old' image to become 'new'.
>>
> The jlink tool always generates a new run-time image, there is no
> support at this time to install additional modules into a run-time image.
>
> -Alan.
Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Thomas Brand
On Sun, December 31, 2017 17:13, Remi Forax wrote:

> jlink is not a distribution tool, you need to use a tool on top of jlink,
> in the past, i've used the rpm format for that.
>
> We have stopped to distribute deltas when we have moved to docker that as
> far as i know as no concept of incremental update.
>
> Rémi
>
>
> ----- Mail original -----
>
>> De: "Alan Bateman" <[hidden email]>
>> À: "Thomas Brand" <[hidden email]>, "jigsaw-dev"
>> <[hidden email]>
>> Envoyé: Dimanche 31 Décembre 2017 16:55:37
>> Objet: Re: Update a runtime image
>>
>
>> On 31/12/2017 15:42, Thomas Brand wrote:
>>
>>> Hello, I have a question related to jlink.
>>>
>>>
>>> In a scenario where a runnable image created with jlink is installed,
>>> and it should be updated, what are good strategies for doing this?
>>>
>>> I think if an update will introduce new dependencies this will be
>>> different to updates that are known to be satisfied with what is
>>> already in the image.
>>>
>>> The idea is to 'ship' just a small sort of diff / replacement part
>>> that can be applied to the 'old' image to become 'new'.
>>>
>> The jlink tool always generates a new run-time image, there is no
>> support at this time to install additional modules into a run-time
>> image.
>>
>> -Alan.
>>

Thanks for the facts & suggestions!
Greetings




Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Gunnar Morling
Hi Thomas,

What I've found helpful is the ability to amend or override the set of
modules contained in a modular runtime image via --module-path and
--upgrade-module-path.

If you use (Docker) containers to deploy your app, this can be employed
nicely to separate images with your app's dependencies (as a modular
runtime image) and a very thin image with your app itself. Unless your
dependencies change, only the latter one needs to be re-built and
distributed. The "exclude-resources" plug-in comes in handy for omitting
your app from the modular runtime image. I've written about it here:
https://github.com/moditect/moditect/wiki/Creating-dependency-images.

--Gunnar


2018-01-07 18:23 GMT+01:00 Thomas Brand <[hidden email]>:

> On Sun, December 31, 2017 17:13, Remi Forax wrote:
> > jlink is not a distribution tool, you need to use a tool on top of jlink,
> > in the past, i've used the rpm format for that.
> >
> > We have stopped to distribute deltas when we have moved to docker that as
> > far as i know as no concept of incremental update.
> >
> > Rémi
> >
> >
> > ----- Mail original -----
> >
> >> De: "Alan Bateman" <[hidden email]>
> >> À: "Thomas Brand" <[hidden email]>, "jigsaw-dev"
> >> <[hidden email]>
> >> Envoyé: Dimanche 31 Décembre 2017 16:55:37
> >> Objet: Re: Update a runtime image
> >>
> >
> >> On 31/12/2017 15:42, Thomas Brand wrote:
> >>
> >>> Hello, I have a question related to jlink.
> >>>
> >>>
> >>> In a scenario where a runnable image created with jlink is installed,
> >>> and it should be updated, what are good strategies for doing this?
> >>>
> >>> I think if an update will introduce new dependencies this will be
> >>> different to updates that are known to be satisfied with what is
> >>> already in the image.
> >>>
> >>> The idea is to 'ship' just a small sort of diff / replacement part
> >>> that can be applied to the 'old' image to become 'new'.
> >>>
> >> The jlink tool always generates a new run-time image, there is no
> >> support at this time to install additional modules into a run-time
> >> image.
> >>
> >> -Alan.
> >>
>
> Thanks for the facts & suggestions!
> Greetings
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Alan Bateman
On 10/01/2018 10:32, Gunnar Morling wrote:

> Hi Thomas,
>
> What I've found helpful is the ability to amend or override the set of
> modules contained in a modular runtime image via --module-path and
> --upgrade-module-path.
>
> If you use (Docker) containers to deploy your app, this can be employed
> nicely to separate images with your app's dependencies (as a modular
> runtime image) and a very thin image with your app itself. Unless your
> dependencies change, only the latter one needs to be re-built and
> distributed. The "exclude-resources" plug-in comes in handy for omitting
> your app from the modular runtime image. I've written about it here:
> https://github.com/moditect/moditect/wiki/Creating-dependency-images.
>
If I understand this correctly then the app module is linked into the
run-time image to force its dependences to be linked in. It might be
saner to just get its list of `requires` and specify that list to jlink.
That way the app module can be specified on the module path (you are
otherwise forced to use the upgrade module path to avoid the broken app
module in the run-time image).

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Gunnar Morling
2018-01-10 16:28 GMT+01:00 Alan Bateman <[hidden email]>:

> On 10/01/2018 10:32, Gunnar Morling wrote:
>
>> Hi Thomas,
>>
>> What I've found helpful is the ability to amend or override the set of
>> modules contained in a modular runtime image via --module-path and
>> --upgrade-module-path.
>>
>> If you use (Docker) containers to deploy your app, this can be employed
>> nicely to separate images with your app's dependencies (as a modular
>> runtime image) and a very thin image with your app itself. Unless your
>> dependencies change, only the latter one needs to be re-built and
>> distributed. The "exclude-resources" plug-in comes in handy for omitting
>> your app from the modular runtime image. I've written about it here:
>> https://github.com/moditect/moditect/wiki/Creating-dependency-images.
>>
>> If I understand this correctly then the app module is linked into the
> run-time image to force its dependences to be linked in. It might be saner
> to just get its list of `requires` and specify that list to jlink. That way
> the app module can be specified on the module path (you are otherwise
> forced to use the upgrade module path to avoid the broken app module in the
> run-time image).


What exactly do you mean by "broken app module"? It was my understanding
that by applying that exclusion pattern, no trace whatsoever of the app
module would end up in the resulting runtime image. If I run
<IMAGE>/bin/java --list-modules it's not shown in the image's module list,
and things works for me when I add it via --module-path.

But either what you suggest might be cleaner indeed.


>
>
> -Alan
>
Reply | Threaded
Open this post in threaded view
|

Re: Update a runtime image

Alan Bateman
On 10/01/2018 17:39, Gunnar Morling wrote:
> :
>
> What exactly do you mean by "broken app module"? It was my
> understanding that by applying that exclusion pattern, no trace
> whatsoever of the app module would end up in the resulting runtime
> image. If I run <IMAGE>/bin/java --list-modules it's not shown in the
> image's module list, and things works for me when I add it via
> --module-path.
I think there may be a bug here. The exclude-resources plugin was
created for selectively removing resources, it was never mean to be able
to remove a module completely.

-Alan.