Adding option parsing and flags to app binaries

[jwoertink]

This is something that if you needed, you could hand roll in to your app as needed, but maybe the idea would be beneficial enough to add in as a first class citizen?

The idea here is a way to add in some flags or option parsing for your production built app binary. Imagine a scenario where you build your production binary locally, then you want to deploy by zipping up that binary with whatever else you needed (AWS ElasticBeanstalk, etc..), then once uploaded, you want to run migrations. The current migrations task needs to be compiled in order to run (see other discussion). What would be cool here is if you did this:

lucky build.release
# do deploy
./my_app --exec "db.migrate"

In this case, all tasks are compiled. We don't need to worry about the task not being up-to-date since we know we're in production at this point. We could grab that task name, and pass it through.

One thing though would be to specify which tasks would be added. You probably don't need the "gen" tasks, or "db.drop" to exist in production, but I could see someone needing ./my_app --exec "db.console" and maybe a few others. So I guess this would be a list that you'd specify, and lucky build.release would know to include those targets.

Now, aside from just the --exec, having an option parser allows you to do any options. If you're building a white labeled app, maybe the clients you distribute to need to know the app's version ./my_app -v?

Thinking through this, my initial thought would be adding a line in to generated apps to the start_server.cr that looks like:

if Lucky::Env.development?
  Avram::Migrator::Runner.new.ensure_migrated!
  Avram::SchemaEnforcer.ensure_correct_column_mappings!
end

# This block gets added
if Lucky::Env.production?
  # a local option parser file
  require "./option_parser"
end

app_server = AppServer.new

# src/option_parser.cr
require "option_parser"

OptionParser.parse do |parser|
  parser.banner = "Usage:  [arguments]"
  parser.on("-h", "--help", "Show this help") do
    puts parser
    exit
  end
  parser.on("-v", "--version", "Show app version") { puts MyApp::VERSION }
  parser.on("-e TASK", "--exec=TASK", "Execute lucky task") { |task| Lucky::ExecTask.new(task).call }
end

We would want to keep this as close to the crystal stuff as possible to give as much flexibility as we can, plus less to build on to.

With all that said, anyone see any plot holes, or get bad vibes from this? Or maybe you see more use cases that you would want with this?

[matthewmcgarvey]

This is just a "what-if" but what if lucky-cli was the only entrypoint into an app? Instead of building the binary that starts the app when it runs, it would be started through a task ./my-app start. Does that make sense?

[BrucePerens]

It's not really a great idea to compile tasks into production apps, because it increases the attack surface. And production apps belong in a constrained environment, for security purposes. Generally tasks can't run under the same constraints. It would, however, be a good idea to produce a task executable that could be distributed along with the production application, with all tasks built, and with no need to have source on the machine running the task. Right now, it seems that almost every task requires a compile.

[robacarp]

Recently, building a lucky app for production in a dockerfile, I ran into an issue because I didn't have a way to run migrations. Installing Lucky into the docker image was a bit much to ask -- I prefer to have my deployments minimal, even to the point of deleting the source code from my images after compilation.

I eventually landed on this:

targets:
  server:
    main: src/start_server.cr
  worker:
    main: src/app_worker.cr
+  tasks:
+    main: tasks.cr

That emitted a tasks binary to bin/ and I can execute migrations with a docker run -it <image> tasks db.migrate