Lint

Makefile

@@ -2,8 +2,11 @@ build: shard.yml $(wildcard src/**/*) $(runtimes/**/*)
 	shards build -d --error-trace
 	cat .rucksack >> bin/faaso
 	cat .rucksack >> bin/faaso-daemon
-proxy: build
+proxy:
 	docker build . -t faaso-proxy
+
+all: build proxy
+
 start-proxy:
 	docker run --name faaso-proxy-one \
 	--rm --network=faaso-net \
@@ -13,5 +16,10 @@ start-proxy:
 	-v ${PWD}/config:/home/app/config \
 	-p 8888:8888 faaso-proxy
 
+test:
+	crystal spec
 
-.PHONY: build proxy-image start-proxy
+clean:
+	rm bin/*
+
+.PHONY: all build proxy-image start-proxy test clean

README.md

@@ -50,22 +50,25 @@ This will give you:
 You need a server, with docker. In that server, build it as explained above.
 You can run the `faaso-proxy` with something like this:
 
-```
-docker run --network=faaso-net -v /var/run/docker.sock:/var/run/docker.sock -p 8888:8888 faaso-proxy
+```shell
+docker run --network=faaso-net \
+-v /var/run/docker.sock:/var/run/docker.sock \
+-p 8888:8888 faaso-proxy
 ```
 
-That will give `faaso-proxy` access to your docker, and expose the functionality in
-port 8888.
+That will give `faaso-proxy` access to your docker, and expose the functionality
+in port 8888.
 
 ## What it Does
 
 ### Funkos
 
-In FaaSO you (the user) can create Funkos. Funkos are the moral equivalent of AWS 
+In FaaSO you (the user) can create Funkos. Funkos are the moral equivalent of AWS
 lambdas and whatever they are called in other systems. In short, they are simple
 programs that handle web requests.
 
-For example, here is a `hello world` level funko written using Crystal, a file called `funko.cr`:
+For example, here is a `hello world` level funko written using Crystal,
+a file called `funko.cr`:
 
 ```crystal
 get "/" do
@@ -82,24 +85,26 @@ runtime: crystal
 ```
 
 If you have those two files in a folder, that folder is a funko, which is called
-`hello` and FaaSO knows it's written in Crystal. In fact, it knows (because the crystal runtime explains that, don't worry about it yet) that it's part of an
+`hello` and FaaSO knows it's written in Crystal. In fact, it knows (because the
+crystal runtime explains that, don't worry about it yet) that it's part of an
 application written in the [Kemal framework](https://kemalcr.com/) and it knows
 how to create a whole container which runs the app, and how to check its health,
 and so on.
 
 But the funko has *the interesting bits* of the app.
 
-The full details of how to write funkos are still in flux, so not documenting 
-it for now. Eventually, you will be able to just write the parts you 
+The full details of how to write funkos are still in flux, so not documenting
+it for now. Eventually, you will be able to just write the parts you
 need to write to create funkos in different languages. It's easy!
 
-### So what can a funko do?
+### So what can a funko do
 
 Once you have a funko, you can *build* it, which will give you a docker image.
 
 ```faaso build --local myfunko/```
 
-Or you can export it and get rid of all the mistery of how your funko **really** works:
+Or you can export it and get rid of all the mistery of how your funko
+**really** works:
 
 ```faaso export myfunko/ myfuko-exported```
 
@@ -116,9 +121,9 @@ than one, although currently only one is used by the proxy.
 The proxy has a few goals:
 
 1) You can connect to it using `faaso` and have it build/run/etc your funkos.
-
    * This builds the funko in your machine: `faaso build -l myfunko/`
-   * This builds the funko in the server pointed at by FAASO_SERVER: `faaso build myfunko/`
+   * This builds the funko in the server pointed at by FAASO_SERVER:
+     `faaso build myfunko/`
 
    Yes, they are exactly the same thing. In fact, if you don't use the `-l` flag,
    faaso just tells the proxy "hey proxy, run *your* copy of faaso over there and
@@ -127,10 +132,10 @@ The proxy has a few goals:
 2) It automatically reverse-proxies to all funkos.
 
    If you deployed a funko called `hello` and your faaso proxy is at
-   `http://myserver:8888` then the `/` path in your funko is at 
+   `http://myserver:8888` then the `/` path in your funko is at
    `http://myserver:8888/funko/hello/`
 
-   This proxying is automatic, you don't need to do anything. As long as you 
+   This proxying is automatic, you don't need to do anything. As long as you
    build the image for your funko in the server and then start the funko in the
    server? It should work.
 
@@ -145,4 +150,4 @@ beyond bugfixes, since I am redesigning things all the time.
 
 ## Contributors
 
-- [Roberto Alsina](https://github.com/ralsina) - creator and maintainer
+* [Roberto Alsina](https://github.com/ralsina) - creator and maintainer

TODO.md

@@ -1,4 +1,6 @@
-# Things that need doing before first release
+# TODO LIST
+
+## Things that need doing before first release
 
 * User flow for initial proxy setup
   * ✅ Setting up password
@@ -34,6 +36,6 @@
 * ✅ Cleanup `tmp/whatever` after use
 * `faaso scale` remote is broken
 
-# Things to do but not before release
+## Things to do but not before release
 
-* Propagate errors from `run_faaso` to the remote client 
+* Propagate errors from `run_faaso` to the remote client

config/Caddyfile

@@ -18,5 +18,5 @@ http://*:8888 {
 	handle_path /admin/* {
 		reverse_proxy /* http://127.0.0.1:3000
 	}
-      import funkos 
+      import funkos
 }

docs/DESIGN.md

@@ -38,7 +38,7 @@ up/downscaling, no multiple versions routed by header.
 Specifically: no downscaling to zero. It makes everything MUCH
 more complicated.
 
-# Function structure
+## Function structure
 
 Example using crystal, but it could be anything. Any function has
 an associated runtime, for example "crystal" or "python".
@@ -69,7 +69,9 @@ Probably some `metadata.yml` that is *not* in the template.
 * Files that should be copied along the function
 * Whatever
 
-# Implementation Ideas
+## Implementation Ideas
 
 * caddy for proxy? It's simple, fast, API-configurable.
-* Local docker registry for images? See https://www.docker.com/blog/how-to-use-your-own-registry-2/ (maybe later)
+* Local docker registry for images? See
+  [use own registry](https://www.docker.com/blog/how-to-use-your-own-registry-2/)
+  (maybe later)

docs/deployments.md

@@ -15,34 +15,31 @@ Solution: start the funko on the server. Done. It's implemented.
 
 ## Variant 3: Deploy to the server and it's already running
 
-1. If it's already running and it's running the latest image, then nothing to be done.
-2. It it's running and is not the latest, we can stop it and start with the latest image.
+1. If it's already running and it's running the latest image, then nothing
+   to be done.
+2. It it's running and is not the latest, we can stop it and start with the
+   latest image.
 
 * Action 2 causes downtime. Usually it will not be significant, but it's there.
 * In the future it may be important to have zero downtime.
 * We need to figure out what is implied by doing "zero downtime" to see if
   not doing it now would make it impossible.
 
-For zero downtime, we want to have two instances running, switch the proxy to the new
-one, then stop the old one.
+For zero downtime, we want to have two instances running, switch the proxy
+to the new one, then stop the old one.
 
 Currently it's impossible to run two instances because the container name is
 faaso-funkoname, and we can't have 2 of those.
 
-So: we could instead have faaso-funkoname-1, faaso-funkoname-2, etc. with some sort of suffix
+So: we could instead have faaso-funkoname-1, faaso-funkoname-2, etc.
+with some sort of suffix
 
 Changes implied in the faaso code:
 
-* If we have two containers for one funko, we need to consider the "state" of 
+* If we have two containers for one funko, we need to consider the "state" of
   the funko differently.
 * What does it mean to start/pause/stop a funko with two instances
 * Do we want to enable two-instance funkos? With round-robin proxy?
 * What happens if we have two instances with different images?
 
 Answers coming up.
-
-
-
-
-
-

docs/funkos.md

@@ -49,10 +49,12 @@ faaso-net.
 The proxy is the only container exposed to the host network, everything
 else needs to be accessed through it.
 
-The faaso-proxy container will automatically proxy all requests so if you access the URL `http://faaso-proxy:8888/funko/hello/foo` that will be
+The faaso-proxy container will automatically proxy all requests so if
+you access the URL `http://faaso-proxy:8888/funko/hello/foo` that will be
 proxied to `/foo` in the `hello` funko.
 
-This is all done via naming conventions. You can create your own `faaso-whatever` container, add it to the `faaso-net` and faaso will
+This is all done via naming conventions. You can create your own
+`faaso-whatever` container, add it to the `faaso-net` and faaso will
 happily consider it a funko.
 
 In the same way all funkos are simply docker containers running in that
@@ -78,4 +80,3 @@ faaso-proxy -- GET /bar --> faaso-funko1
 The dynamic proxying is achieved by reading the current state of
 Docker and just adapt to it using the naming conventions mentioned
 above.
-

docs/secrets.md

@@ -31,7 +31,7 @@ So, the proxy can periodically examine its secret store and populate a folder
 If on starting a funko we always do a bind mount of `/secrets/foo` to `/secrets`
 then it will always have its secrets in place.
 
-## Problem 2: how can the proxy know the secrets without keeping them in the image?
+## Problem 2: how can the proxy know the secrets without keeping them in the image
 
 They can't be shipped via the image, so they need to be injected via the admin API.
 

examples/hello_crystal/README.md

@@ -8,4 +8,4 @@ Write here what it is
 
 ## How to use Hello_crystal
 
-And so on.
+And so on.

public/index.html

@@ -88,4 +88,4 @@
         }
       </script>
   </main>
-</body>
+</body>

runtimes/crystal/README.md

@@ -1,4 +1,4 @@
 # README
 
 This is the readme for people wanting to change this runtime,
-not for people trying to use it
+not for people trying to use it

runtimes/crystal/template/shard.yml.j2

@@ -12,4 +12,3 @@ dependencies:
 # development_dependencies:
 #   webmock:
 #     github: manastech/webmock.cr
-

runtimes/express/Dockerfile.j2

@@ -17,4 +17,4 @@ USER app
 COPY --from=build /home/app/  .
 
 CMD ["node", "funko.js"]
-HEALTHCHECK {{ healthcheck_options }}  CMD {{ healthcheck_command }}
+HEALTHCHECK {{ healthcheck_options }}  CMD {{ healthcheck_command }}

runtimes/express/template/funko.js

@@ -12,4 +12,4 @@ app.get('/ping', (req, res) => {
 
 app.listen(port, () => {
     console.log(`Example funko listening on port ${port}`)
-})
+})

runtimes/flask/Dockerfile.j2

@@ -19,4 +19,4 @@ USER app
 COPY --from=build /home/app/  .
 
 CMD ["venv/bin/uwsgi", "--http", "0.0.0.0:3000", "--master", "-p", "1", "-w", "funko:app"]
-HEALTHCHECK {{ healthcheck_options }}  CMD {{ healthcheck_command }}
+HEALTHCHECK {{ healthcheck_options }}  CMD {{ healthcheck_command }}

runtimes/flask/template/requirements.txt

@@ -1 +1 @@
-flask
+flask

shard.lock

@@ -63,4 +63,3 @@ shards:
   rucksack:
     git: https://github.com/busyloop/rucksack.git
     version: 2.0.0
-

src/views/funkos.ecr

@@ -31,7 +31,7 @@
       </tbody>
       </p>
   </td>
-      
+
     </table>
   <td>
   <%- if f["name"] == "proxy" -%>