Apache OpenWhisk Web Action HTTP Proxy

[James Thomas <jt...@gmail.com>]

Hello Whiskers.

I wanted to share an experiment I built recently to run existing web apps
on openwhisk (with minimal changes) using custom Docker images support.

https://github.com/jthomas/openwhisk-web-action-http-proxy

It uses a HTTP proxy binary inside the runtime container to proxy incoming
Web Action requests to the web apps run on a different port inside the same
container. HTTP responses are returned to the platform as Web Action
responses.

For simple & stateless web apps - it worked better than I thought. Here's
an example of how to use this with an exsting Node.js+Express Web App:

https://github.com/jthomas/openwhisk-web-action-http-proxy#nodejs--express-example

$ git clone https://github.com/jthomas/express_example
$ cd express_example & npm install
$ zip -r action.zip *
$ wsk action create --docker jamesthomas/generic_node_proxy --web true
--main "npm start" -p "__ow_proxy_port" 3000 web_app action.zip
$ wsk action get web_app --url

Two different options are available for getting web application source
files into the runtime environment - runtime injection using zip files or
putting source files directly into the runtime image.

There's lots more details about the project in the project README and I've
now written a blog post in more details about the project here:

http://jamesthom.as/blog/2019/04/29/apache-openwhisk-web-action-http-proxy/

-- 
Regards,
James Thomas

Re: Apache OpenWhisk Web Action HTTP Proxy

[Nick Mitchell <mo...@gmail.com>]

this is great james, thanks for the awesome writeup. last year, i tried a
somewhat similar experiment with using openwhisk as a proxy to kubectl and
helm. it worked! but ended up not being viable due to cold starts. i either
needed to use a docker action to host the go binaries, or download them on
the fly. the latter, surprisingly, turned out to be faster... and the
results are borderline usable (1.2s cold start times, which was pretty nice
considering this included downloading a binary!).

but, compared to the 350ms typical response times from the base CLI, and
the 400ms or so response times to be had from a pod-hosted kubectl proxy...
i had to ditch the experiment before long.

thoughts here? i'd love to have used the serverless openwhisk-kubectl
proxy. did i miss something that would have made this a viable approach?

@starpit

On Tue, Apr 30, 2019 at 6:14 AM James Thomas <jt...@gmail.com> wrote:

> Hello Whiskers.
>
> I wanted to share an experiment I built recently to run existing web apps
> on openwhisk (with minimal changes) using custom Docker images support.
>
> https://github.com/jthomas/openwhisk-web-action-http-proxy
>
> It uses a HTTP proxy binary inside the runtime container to proxy incoming
> Web Action requests to the web apps run on a different port inside the same
> container. HTTP responses are returned to the platform as Web Action
> responses.
>
> For simple & stateless web apps - it worked better than I thought. Here's
> an example of how to use this with an exsting Node.js+Express Web App:
>
>
> https://github.com/jthomas/openwhisk-web-action-http-proxy#nodejs--express-example
>
> $ git clone https://github.com/jthomas/express_example
> $ cd express_example & npm install
> $ zip -r action.zip *
> $ wsk action create --docker jamesthomas/generic_node_proxy --web true
> --main "npm start" -p "__ow_proxy_port" 3000 web_app action.zip
> $ wsk action get web_app --url
>
> Two different options are available for getting web application source
> files into the runtime environment - runtime injection using zip files or
> putting source files directly into the runtime image.
>
> There's lots more details about the project in the project README and I've
> now written a blog post in more details about the project here:
>
> http://jamesthom.as/blog/2019/04/29/apache-openwhisk-web-action-http-proxy/
>
> --
> Regards,
> James Thomas
>