Builtin Settings in 0.145-beta-1+
Flyctl 0.0.145-beta-1 has landed with a new feature. Settings for Builtins. This makes Builtins more configurable than ever. There’s also a new Python builtin and many fixes.
About
When we introduced the Fly Builtin, we wanted to make it as easy as possible to go from zero to a Fly deployment up and running. Our secret - we baked in carefully crafted Dockerfiles into the Fly CLI app so you could just tell flyctl what kind of app you were building and we’d automatically use the builtin Dockerfiles.
Since builtins landed in Fly, we have added a couple more to the available builtins, like a hugo-static builder. Run that in a directory with a configured Hugo site and your files will be published in no time at all.
But we also had requests for particular changes, often small but important changes, like skipping or adding steps, changing the base image for Docker, and setting particular flags. This got us thinking about how we could make Builtins more configurable.
Settings
The answer was to bring settings to builtins. Settings have sensible defaults, but you can override them in the fly.toml file to change how a builtin is run. Let’s show you an example. Deno’s runtime is very secure by default and expects you to set multiple flags to allow particular actions. By default, we turn on --allow-net. But what if you also wanted to allow reading of the disk (yes, Deno is strict about this stuff). Well, now in fly.toml you can write:
[build]
builtin = "deno"
[build.settings]
perms = [ "--allow-net", "--allow-read" ]
The perms setting takes an array of command line flags and adds them to the builtin’s RUN command for Deno.
So, how do you discover if your builtin has settings? Use the fly builtins show <builtinname> command. Let’s have a look at the static builtin with that
❯ fly builtins show static
Name: static
Description: Web server builtin
Details:
All files are copied to the image and served, except files with executable
permission set.
Settings:
httpsonly=false (bool)
Enable http to https promotion
log=false (bool)
Enable basic logging
Dockerfile (with defaults):
FROM pierrezemb/gostatic
COPY . /srv/http/
CMD ["-port","8080"]
The Settings section shows what settings are available, what the default is and what type of value is expected. Strings, integers and booleans as well as arrays of those types are supported. Check the description to see how these types should be used.
To assist debugging, there is also fly builtins show-app which will use the current fly.toml to preview what the builtin will do:
Name: deno
Description: Deno builtin
Details:
Uses Debian image from https://github.com/hayd/deno-docker.
runs main.ts with --allow-net set and requires deps.ts for dependencies.
Uses and exposes port 8080 internally.
Settings:
perms=["--allow-net","--allow-read"] (array)
Array of command line settings to grant permissions, e.g. ["--allow-net","--allow-read"] defaults to [--allow-net]
Dockerfile (with fly.toml settings):
FROM hayd/debian-deno:1.4.0
ENV PORT=8080
EXPOSE 8080
WORKDIR /app
USER deno
COPY main.ts deps.* ./
RUN /bin/bash -c "deno cache deps.ts || true"
ADD . .
RUN deno cache main.ts
CMD ["run", "--allow-net","--allow-read", "main.ts"]
This shows what the settings are and their effect on the builtin Dockerfile.
Please give them a try. Right now, there are settings for deno (for permissions), static and hugo-static (for HTTPS promotion and logs), and the Python builtin (for versions).
Python!
Oh yes, completely forgot, there’s a Python builtin now. It’s experimental, but thats the point of these betas. Basically set up a requirements.txt and a Procfile to set up what you run and the builtin will get all the requirements and set up to run the Procfile. It’s powered by hivemind.
Wanted:
Are you interested in creating builtin style builders for your projects? Drop us a line, as we have something we’d like to try out (spoiler, it’s a way to design your own builtins and use them on demand)…
Also Wanted:
We want to hear from you about your build experiences. Are you using the builtin builders? Or are you rolling your own Dockerfiles? Are you using buildpacks? Let us know about that and what you are happy and not happy with. We have massive plans for the entire fly experience and we want to make sure it’ll make a difference to you.
Looking forward to your bug reports and feedback!