Hi Norbert - it’s all in the gitlab repo (the idea was to fork it and configure your own pipeline e vars)
However the key stuff was in the scripts dir, and this file - /scripts/build.sh Which also loads some .st files for image fix ups . Tim Sent from my iPhone Sent from my iPhone > On 18 Oct 2019, at 16:07, Jan van de Sandt <jvdsa...@gijjes.nl> wrote: > > Hi Norbert, > > Last year I did some experiments with Pharo Lambda functions, see: > > https://github.com/jvdsandt/pharo-aws-toolbox/blob/master/doc/pharo-lambda-runtime.md > > > I didn't spend a lot of time on minimizing the image. There is still a lot of > room for improvement. > > Jan. > > > > >> On Fri, Oct 18, 2019 at 12:30 PM Norbert Hartl <norb...@hartl.name> wrote: >> Tim, >> >> is there a document anywhere explaining how to do a lambda image? >> >> Norbert >> >> > Am 18.10.2019 um 11:00 schrieb Tim Mackinnon <tim@testit.works>: >> > >> > I haven’t tried in a while, but in 2017 with PharoLambda I had a combined >> > Pharo image and VM size if 21 mb using the early Pharo minimal (I recall >> > it was an early 7.0 image ). I was loading a simple hello Alexa app, so >> > not a ton of code (but it had Neo Json and other AWS libs as a dependency >> > I recall). >> > >> > I’m interested in trying these Docker experiments, so I’ll have to look at >> > some point and see if I can get similar sizes. >> > >> > As I scripted my build, I have the steps laid out. I recall there were >> > many vm plugins not needed for a server install (sound etc) and I also ran >> > a cleanup step in the image as there was lots of metacello stuff cached >> > ... so I’m sure tinier is possible even without candle. >> > >> > Tim >> > >> > Sent from my iPhone >> > >> >>> On 18 Oct 2019, at 07:48, Norbert Hartl <norb...@hartl.name> wrote: >> >>> >> >>> >> >>> >> >>>> Am 17.10.2019 um 02:00 schrieb Julián Maestri <serp...@gmail.com>: >> >>> >> >>> As a side note, the final image size is not what really matters, if you >> >>> have 20 different images all starting from the same base image (eg >> >>> ubuntu:18.04) the base layer is shared among all images so the network / >> >>> disk usage is less than the total size of the image. >> >> >> >> The overlayfs does only help here with the disk storage that is not >> >> multiplied. As the image is a memory dump of an individual image nothing >> >> can be shared there. So if you have 20 images you have 20 times the heap. >> >> So a small image is actually important. The vm is different. It is the >> >> same static file which will be paged into shared memory and the vm binary >> >> should be shared for all 20 runtimes. But the interpreter memory will not >> >> be shared so a small vm pays out as well. >> >> >> >> Norbert >> >> >> > >> > > > > -- > Jan van de Sandt > gsm: +31 (0)6 3039 5998
