PHP in AWS Lambda Function ausführen

Bei der Transformation in der Cloud möchte man manchmal schnell kleine Scripts in die
Cloud bringen ohne erst Server oder Container in der Cloud zu installieren.
In vielen Fällen reichen Funktionen wie AWS-Lambda-Functions, Azure Functions oder
Google Cloud Functions.

AWS Lambda bietet dafür in Lambda folgende (Script)-Sprachen an:

  • C#
  • Java
  • python
  • nodejs

Gerade in älteren Umgebungen werden oft Perl und PHP für kleinere Webscripte,
die Applikationen zum Austausch von Informationen benutzen eingesetzt.
Klar, diese Scripte sollte man teilweise überdenken und erneuern. Das kostet zum
einen Geld, jemand muss es machen und manche sollen auch nur noch bei dem Sprung
in die Cloud helfen und dann eh das zeitliche segnen.

Daher wäre es nicht schlecht diese Tools schnell mit in die Cloud zu nehmen um
andere Software so in die Cloud zu bekommen und die Tools nicht als Spassbremse
zu haben.

nodejs und statisch kompliliertes php

Da Lambda nodejs anbietet kann man es auch dazu nötigen PHP auszuführen.
Ja, würde ich es jetzt auch lesen oder es von jemanden hören, ich würde mich
jetzt genau so schütteln.
Aber es soll ja nur den Sprung in die Cloud ermöglichen und zeigen wie man solche
Probleme umgehen kann.

PHP Binary erstellen

Um das PHP statisch als ein Binary vorliegen zu haben bietet sich Docker an.

build_php_7.sh

#!/bin/sh
PHP_VERSION_GIT_BRANCH=PHP-7.1.1
echo "Build PHP Binary from current branch '$PHP_VERSION_GIT_BRANCH' on https://github.com/php/php-src"
docker build --build-arg PHP_VERSION=$PHP_VERSION_GIT_BRANCH -t php-build -f Dockerfile.BuildPHP .
container=$(docker create php-build)
docker -D cp $container:/root/php7/usr/bin/php ./php
docker rm $container

Das stellt einen Container der PHP 7.7.1 zusammensetzt und anschliessend das
fertige Binary aus den Docker Container kopiert.

Wer eine andere Version benötigt kann die Version mit PHP_VERSION_GIT_BRANCH setzen.

PHP Script

<?php
echo "Hello world!";
var_dump($argv);
?>

index.js spawn für php

Damit der PHP Interpreter und ein Script aufgerufen werden benötigt man nur noch
etwas JavaScript:

'use strict';
var child_process = require('child_process');
exports.handler = function(event, context) {
  var strToReturn = '';
  var proc = child_process.spawn('./php', [ "index.php", JSON.stringify(event), { stdio: 'inherit' } ]);
  proc.stdout.on('data', function (data) {
    var dataStr = data.toString()
    console.log('stdout: ' + dataStr);
    strToReturn += dataStr
  });

  proc.on('close', function(code) {
    if(code !== 0) {
      return context.done(new Error("Process exited with non-zero status code"));
    }
    context.succeed(strToReturn);
  });
}

Alles einpacken und verschiffen

Jetzt nur noch ein Zip-File aws-lambda-php-example.zip erstellen mit den Dateien:

  • index.js
  • index.php
  • php

    zip aws-lambda-php-example.zip index.js index.php php

In AWS eine neue Lambda Function erstellen mit folgenden Parametern:

  • Type: nodeJS
  • RAM: 128mb
  • Timeout: 3 seconds

Den JavaScript Code nicht in den Online Editor kopieren, sondern Upload auswählen
und das komplette ZIP-File hochladen und an der Lambda Function anhängen.
Alternativ im S3 ablegen und aus dem Bucket heraus laden lassen

Benötigt man die Schnittstelle per HTTP von extern und/oder anderen Instanzen kann
man auch noch das API-Gateway von Amazon hinzuziehen.

Spassbremse umgangen

Das Script stört nicht mehr die weitere Transformation und alle anderen Softwarebrocken
können ihren Weg in die Cloud beschreiten. Die Teams, die solche Softwarestückchen
einmal in schön abliefern müssen, können dies dann noch später nachholen.
Haben aber auch erst einmal Zeit für die grösseren Cloud-Projekte.

Wer aus “Gründen” nicht sofort eine komplette Software in die Cloud bringen kann
sollte sich das API-Gateway einmal genauer angucken. Path und Method lassen sich
damit sehr gut trennen. Einzelne Aufrufe lassen sich so auf die alte Software
oder die neue Software leiten. Natürlich nur, so lange so etwas mit einer Software
möglich ist und intern keine Abhängigkeiten bestehen. Ist es möglich steht einer
Migration einzelner Funktionen nichts im Wege. Rollback inklusive.

AWS Lambda serverless Framework und serverless-offline

nodejs, npm, serverless und serverless-offline installieren

Installation nodejs

$ sudo apt-get install curl python-software-properties
$ curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
$ sudo apt-get install nodejs
$ node -v 

v8.2.1

$ npm -v 

5.3.0

Installation serverless

npm install -g serverless

serverless service erstellen

Project erstellen

# Ein neues Serverless Service/Project erstellen 
serverless create --template aws-nodejs --path my-service
# In das neue Verzeichnis wechseln
cd my-service

AWS Access-Key und Secret

export AWS_ACCESS_KEY_ID=<your-key-here>
export AWS_SECRET_ACCESS_KEY=<your-secret-key-here>
serverless deploy

oder

serverless config credentials --provider aws --key AKIAIOSFODNN7EXAMPLE --secret wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Deploy Service

serverless deploy -v

Die Logs der Function abrufen:

serverless invoke -f hello -l

Service in AWS entfernen

serverless remove

mysql RSD DB mit NodeJS in Lambda benutzen

Als erstes im Projectverzeichnis (my-project) das mysql plugin installieren

npm install mysql 

Im Code mysql hinzufügen und den restlichen mysql java-script Code:

var mysql = require('mysql');
module.exports.view = (event, context, callback) => {
  const ip = event.requestContext.identity.sourceIp;
  var connection = mysql.createConnection({
    host: 'YourRdsDB.xxxxxxx.eu-central-1.rds.amazonaws.com',
    user: 'DBUser',
    password: 'DBPass',
    database: 'DBname'
  });
  connection.connect();
  // ....
}

Serverless offline ohne AWS benutzen

Serverless-offline installieren

npm install serverless-offline --save-dev

Hinter einem Cooperate-Proxy ggf. auch noch mit Auth?

Einfach npm mit config set die Parameter für https-proxy und proxy setzen.

npm config set proxy http://"username:gehe\!m"@proxy.example.com:3128
npm config set https-proxy http://"username:gehe\!m"@proxy.example.com:3128

Sonderzeichen wie das ‘!’ hier im Beispiel müssen escaped werden. Und Benutzer und Password müssen komplett in ” gesetzt werden.

Das Verzeichnis “node_modules” sollte jetzt ungefähr so aussehen und unter anderem serverless-offline auflisten:

ls node_modules/
accept            babel-helpers   balanced-match   content               esutils            home-or-tmp  json5             mimos          os-homedir           serverless-offline  supports-color
ammo              babel-messages  boom             convert-source-map    globals            invariant    jsonpath-plus     minimatch      os-tmpdir            shot                to-fast-properties
ansi-regex        babel-register  brace-expansion  core-js               h2o2               iron         js-string-escape  minimist       path-is-absolute     slash               topo
ansi-styles       babel-runtime   call             cryptiles             hapi               isemail      js-tokens         mkdirp         peekaboo             source-map          trim-right
b64               babel-template  catbox           crypto                hapi-cors-headers  is-finite    kilt              moment         pez                  source-map-support  velocityjs
babel-code-frame  babel-traverse  catbox-memory    debug                 has-ansi           items        lodash            ms             private              statehood           vise
babel-core        babel-types     chalk            detect-indent         heavy              joi          loose-envify      nigel          regenerator-runtime  strip-ansi          wreck
babel-generator   babylon         concat-map       escape-string-regexp  hoek               jsesc        mime-db           number-is-nan  repeating            subtext

PlugIn in der serverless.yml hinzufügen

plugins:
  - serverless-offline

Überprüfen ob das PlugIn verfügbar ist

serverless

Die Ausgabe sollte unter commands jetzt zusätzlich “offline” und “offline-start” auflisten

...
logs .......................... Output the logs of a deployed function
metrics ....................... Show metrics for a specific function
offline ....................... Simulates API Gateway to call your lambda functions offline.
offline start ................. Simulates API Gateway to call your lambda functions offline using backward compatible initialization.
package ....................... Packages a Serverless service
remove ........................ Remove Serverless service and all resources
...

In der letzten Zeile werden alle verfügbaren PlugIns aufgelistet und “Offline” sollte dort auch aufgelistet werden.

Plugins
AwsCommon, AwsCompileAlexaSkillEvents, AwsCompileApigEvents, AwsCompileCloudWatchEventEvents, AwsCompileCloudWatchLogEvents, AwsCompileCognitoUserPoolEvents, AwsCompileFunctions, AwsCompileIoTEvents, AwsCompileS3Events, AwsCompileSNSEvents, AwsCompileScheduledEvents, AwsCompileStreamEvents, AwsConfigCredentials, AwsDeploy, AwsDeployFunction, AwsDeployList, AwsInfo, AwsInvoke, AwsInvokeLocal, AwsLogs, AwsMetrics, AwsPackage, AwsProvider, AwsRemove, AwsRollback, AwsRollbackFunction, Config, Create, Deploy, Emit, Info, Install, Invoke, Login, Logout, Logs, Metrics, Offline, Package, Platform, Remove, Rollback, Run, SlStats

Projekt offline starten

serverless offline start or sls offline start.

serverless offline start
Serverless: Starting Offline: dev/us-east-1.

Serverless: Routes for hello:
Serverless: (none)

Serverless: Offline listening on http://localhost:3000

Service testen

Dabei an den Proxy denken und den Parameter --noproxy setzen:

curl --noproxy "127.0.0.1, localhost" http://localhost:3000

Parameter von serverless-offline

serverless offline --help 
--prefix                -p  Adds a prefix to every path, to send your requests to http://localhost:3000/[prefix]/[your_path] instead. E.g. -p dev
--location              -l  The root location of the handlers' files. Defaults to the current directory
--host                  -o  Host name to listen on. Default: localhost
--port                  -P  Port to listen on. Default: 3000
--stage                 -s  The stage used to populate your templates. Default: the first stage found in your project.
--region                -r  The region used to populate your templates. Default: the first region for the first stage found.
--noTimeout             -t  Disables the timeout feature.
--noEnvironment             Turns off loading of your environment variables from serverless.yml. Allows the usage of tools such as PM2 or docker-compose.
--resourceRoutes            Turns on loading of your HTTP proxy settings from serverless.yml.
--dontPrintOutput           Turns off logging of your lambda outputs in the terminal.
--httpsProtocol         -H  To enable HTTPS, specify directory (relative to your cwd, typically your project dir) for both cert.pem and key.pem files.
--skipCacheInvalidation -c  Tells the plugin to skip require cache invalidation. A script reloading tool like Nodemon might then be needed.
--corsAllowOrigin           Used as default Access-Control-Allow-Origin header value for responses. Delimit multiple values with commas. Default: '*'
--corsAllowHeaders          Used as default Access-Control-Allow-Headers header value for responses. Delimit multiple values with commas. Default: 'accept,content-type,x-api-key'
--corsDisallowCredentials   When provided, the default Access-Control-Allow-Credentials header value will be passed as 'false'. Default: true
--exec "<script>"           When provided, a shell script is executed when the server starts up, and the server will shut domn after handling this command.

Parameter in der serverless.yml setzen

Beispiel:

custom:
  serverless-offline:
    httpsProtocol: "dev-certs"
    port: 4000
    prefix: "dev"
    stage: "dev"

libstdc++.so.6: version `GLIBCXX_3.4.20′ not found

Da will man einmal kurz was neues installieren und dann das:

[email protected]:~# node -v
[email protected]:~# node: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)
[email protected]:~# node: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.16' not found (required by node)

Na dann fixt man es halt eben schnell:

[email protected]:~# sudo apt-get update
[email protected]:~# sudo apt-get install gcc-4.8 g++-4.8
[email protected]:~# sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 20
[email protected]:~# sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50
[email protected]:~# sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.6 20
[email protected]:~# sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 50

Da zum testen ein alter RaspberryPI B im Einsatz ist:

[email protected]:~# apt-get purge node
[email protected]:~# wget https://nodejs.org/download/release/v0.10.0/node-v0.10.0-linux-arm-pi.tar.gz
[email protected]:~# cd /usr/local
[email protected]:/usr/local# tar xzvf ~/node-v0.10.0-linux-arm-pi.tar.gz --strip=1

Fertig und weiter machen mit dem was man eigentlich vor hatte. 😉

[email protected]:/usr/local# node -v
v0.10.0
[email protected]:/usr/local# npm -v
1.2.14

Betrieben von WordPress | Theme: Baskerville 2 von Anders Noren.

Nach oben ↑