AWS Lambda no longer can use pre-installed ImageMagick on runtime node 10.x

[ysugimoto]

I did not realise that AWS Lambda on nodejs 10.x runtime no longer bundle ImageMagick and unfortunately AWS Lambda will stop support runtime of 8.x in early 2020.

Source: https://forums.aws.amazon.com/thread.jspa?messageID=906619&tstart=0

So we gonna have to do that with:

• Use Lambda Layer which installed ImageMagick
• Fix it without using ImageMagick (we can do it as gm().subClass({ ImageMagick : false}) ?)
• Other ways...

Do you have any idea about that?

[OmeBlues]

Hi y'all, got mine working on 10.x with the following layers:

[ysugimoto]

Hi @OmeBlues, thank you for your information.

If we decided to adopt Lambda Layer, then we'd like to deploy function with layers at once like npm run deploy. Do you have any idea to do it? (sorry, I'm not familiar with Lambda Layers)

[OmeBlues]

I think claudia.js has a --layers option

[ysugimoto]

From claudia.js documentation, we can use --layers option on create/update Lambda function (thanks @OmeBlues ) FYI: https://github.com/claudiajs/claudia/blob/master/docs/create.md

But before deploying function, we need to add the ImageMagick layer to the Lambda, so we'll bundle the pre-built zip for the ImageMagick layer and add it on deploy function.

[OmeBlues]

Hi @ysugimoto, I also had to add the graphicsmagick layer to the function as well. I think both layers are already available in AWS (provided by other people) and you can simply point to the arn you need.

[OmeBlues]

Come to think of it you should probably be able to get away with only using GraphicsMagick...

[ysugimoto]

@OmeBlues Oh, sounds great! but are these AWS official one?

If not so, for securing future works, putting the individual layer (maybe the same as others) for this application specifically and maintain them should be fine, I think.

[ysugimoto]

Ah, we can use https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:145266761615:applications~image-magick-lambda-layer, so the user should be installed before deploy function

[ysugimoto]

Unfortunately, This issue is not only ImageMagick but also some reducers.

I tried to get command error details then I could see:

/var/task/bin/linux/cjpeg: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

It means AWS Lambda runtime also doesn't have shared libraries... 😢

[mhuebner]

I'm using the ImageMagick layer based on https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:145266761615:applications~image-magick-lambda-layer

But keep getting the error

{
    "errorType": "Error",
    "errorMessage": "write EPIPE",
    "code": "EPIPE",
    "errno": "EPIPE",
    "syscall": "write",
    "stack": [
        "Error: write EPIPE",
        "    at WriteWrap.afterWrite [as oncomplete] (net.js:789:14)"
    ]
}

[ysugimoto]

@mhuebner Now I got the same error but it seems to be caused by some reducer binary (e.g MozJpeg). The reason why is Lambda runtime doesn't have shared library which relates image (e.g libpng, libjpeg, ...)

[OmeBlues]

I had to use both ImageMagick and GraphicsMagick layers to get it to work (this solved the EPIPE problem).

[ysugimoto]

Hmm, OK, I'll try with GraphicsMagick Layer. At the moment I only use ImageMagick Layer

[OmeBlues]

https://github.com/rpidanny/gm-lambda-layer

[ysugimoto]

Wow, after I enabled GraphicsMagick Layer, It works fine! Thanks @OmeBlues !

I'll summarize these and release it as new version

[OmeBlues]

Glad to help and good luck!

[lloydwatkin]

I'm seeing:

{
    "errorType": "Error",
    "errorMessage": "Error processing uploads/photo/file/6JHZ0Eq9fky9tFu6TiHzuw/image.jpg: Error: Stream yields empty buffer",
    "stack": [
        "Error: Error processing uploads/photo/file/6JHZ0Eq9fky9tFu6TiHzuw/image.jpg: Error: Stream yields empty buffer",
        "    at _homogeneousError (/var/runtime/CallbackContext.js:13:12)",
        "    at postError (/var/runtime/CallbackContext.js:30:51)",
        "    at callback (/var/runtime/CallbackContext.js:42:7)",
        "    at /var/runtime/CallbackContext.js:105:16",
        "    at processor.run.then.catch (/var/task/index.js:55:13)",
        "    at process._tickCallback (internal/process/next_tick.js:68:7)"
    ]
}

After adding https://github.com/rpidanny/gm-lambda-layer, do I need the https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:145266761615:applications~image-magick-lambda-layer layer too?

[lloydwatkin]

Ah-ha, both together work. Thanks for the help!

[pkyeck]

@ysugimoto any news on the release? an "official" layer for image-magick would be nice (like the GM one) where we could just use the ARN ...

EDIT: ah, had this open for awhile before posting - see now, that you did a couple of updates - will check

[ysugimoto]

Hi @pkyeck,

I've just created the PR at https://github.com/ysugimoto/aws-lambda-image/pull/192 and wait for the review. If you can't wait for the release, please use PR's branch (for testing, It helps me, thanks)

an "official" layer for image-magick would be nice

I think so, too. However, https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:145266761615:applications~image-magick-lambda-layer seems already being official on serverless so at the moment we'd use this one.

Of course, I know providing arn should be better, let me think...

[ysugimoto]

Fixed at https://github.com/ysugimoto/aws-lambda-image/pull/192