Skip to content
All posts
2 min readtebakopackagingtutorial

Basic payloads: Package a Rails or Sinatra application (4 of 5)

The basic payloads series, hands-on: package a rails or sinatra application.

The Tebako team

github.com/tamatebako
Note

Post 4 of 5 in the series Basic payloads.

○ ○ ○ ● ○

  1. Basic payloads: Run your first package

  2. Basic payloads: Data payloads: make one, read one

  3. Basic payloads: Package a Ruby application

  4. Basic payloads: Package a Rails or Sinatra application (this post)

  5. Basic payloads: Publish to your users
Note

Reference guide: Package a Ruby app.

A web application is an application whose entrypoint starts a server. The task is therefore to press the app so that running the executable serves HTTP. The subject of this post is packaging Rails and Sinatra applications, along with the few decisions that are specific to them.

Package a web application the packaged web application a browser http://localhost:3000 your packaged app the server entrypoint: puma or rackup app code · gems · assets — inside the image binds its port like any server tmp/ and logs/ via declared grants sqlite in the image, or a declared host need tebako press -r ./myapp -e "bin/rails server"

Figure 1 — The packaged app boots the server from inside the image: code, gems, and assets travel with it; ports bind like any server; writable paths are declared grants.

Sinatra: one file, one command

A Sinatra app is the smallest web payload — a config.ru and a gem list:

$ tebako press -r ./webapp -e "rackup -p 3000 config.ru" -o webapp
$ ./webapp
Puma starting in single mode…
* Listening on http://0.0.0.0:3000

The app code, Sinatra, Puma, and every gem travel inside the payload slice, and a request to localhost:3000 is served from the package.

Rails: the same, with the pieces named

Rails is larger, not different. The image carries the application code, the bundled gems, and the precompiled assets — assets are files like any other, and mounting them is more reliable than expecting the host to provide them. The following stay outside:

  • The port — the server binds it at run time, like any server.

  • The database — an SQLite file can travel inside the image or live on the host; PostgreSQL and similar services are host services, reached over the network exactly as in development.

  • Temporary and log paths — a running Rails app writes to tmp/ and log/. Writable host paths are granted by declaration, which the advanced series covers; for a self-contained package, point both at a path inside the mounted image or at $TMPDIR.

$ tebako press -r ./blog -e "bin/rails server -p 3000" -o blog
$ ./blog
=> Booting Puma…
* Listening on http://0.0.0.0:3000

The executable is pressed for every platform its users run; the choices are the ones from the previous post.

What you can do now

This post has packaged a web application — Sinatra in one command, Rails with assets inside and services outside — and served it from a single file. The last post in this series publishes what has been built.

Note

Continue with part 5 of 5: Publish to your users.