Jets Init

To generate jets config files need to ultimately deploy the Events project to Serverless AWS Lambda, run:

jets init

You’ll see something like this:

❯ jets init
This will initialize the project for Jets.

It make changes to your project source code.

Please make sure you have backed up and committed your changes first.

Are you sure? (y/N) y
      create  config/jets/env/.env
      create  config/jets/bootstrap.rb
      create  config/jets/deploy.rb
      create  config/jets/project.rb

Init Files

Here’s a review of the files jets init generates.

File	Description
config/jets/project.rb	Project settings like project name. The project name is a part of the stack name to deploy. IE: `project=demo` => `stack=demo-dev` gets to deploy to AWS.
config/jets/bootstrap.rb	Bootstrap settings are used for the `jets deploy` initial bootstrap deployment. This phase creates the s3 bucket and codebuild remote runner which will be used to deploy your project. The remote runner provides a consistent build environment, CPU architecture, raw horsepower, and internet speed. See: Remote Runner.
config/jets/deploy.rb	This is where the main deploy settings live. It tells the jets remote runner how it should deploy. These are the settings you’ll probably update the most.

Review Config

Let’s take a look some of the config files. We’ll review them in an introductory manner. For more details, see: Jets Config: project, bootstrap, deploy

project

The project.rb is always loaded earliest. It has simple configurations are loaded super early in the Jets boot process.

config/jets/project.rb

Jets.project.configure do
  config.name = "rails"
end

The project.rb has the project name. The jets init command infers the name from the parent folder. Change it to rails if it’s not already.

The project name will be part of the stack name to deploy. IE: project=rails => stack=rails-dev gets to deploy to AWS.

bootstrap

The bootstrap.rb has configurations that loaded next for the Jets bootstrap process. The bootstrap phase is the first phase of the Jets deploy process.

config/jets/bootstrap.rb

Jets.bootstrap.configure do
  config.codebuild.project.env.vars = {
    BUNDLE_GITHUB__COM: "SSM:/#{ssm_env}/BUNDLE_GITHUB__COM",
    DOCKER_PASS: "SSM:/#{ssm_env}/DOCKER_PASS",
    DOCKER_USER: "SSM:/#{ssm_env}/DOCKER_USER",
    # Use your own docker host
    # DOCKER_HOST: "SSM:/#{ssm_env}/DOCKER_HOST",
    # JETS_SSH_KEY: "SSM:/#{ssm_env}/JETS_SSH_KEY",
    # JETS_SSH_KNOWN: "SSM:/#{ssm_env}/JETS_SSH_KNOWN"
  }
end

The ssm_env helper returns dev for JETS_ENV=dev and prod for JETS_ENV=prod. You should create these SSM values:

/dev/BUNDLE_GITHUB__COM
/dev/DOCKER_PASS
/dev/DOCKER_USER

Environment variable BUNDLE_GITHUB__COM allow the jets remote process to git clone and install private gems in your Gemfile. See: Remote Runner Private Repos

The DOCKER_PASS and DOCKER_USER env vars can be use to log into docker. You should set them to log into DockerHub, so it allows DockerHub docker pull without running into the rate limit. For more info see: CodeBuild Remote Docker.

It is recommended to use your own remote Docker Host with the env var DOCKER_HOST to speed up builds. See: Remote Docker Host

After jets init, you’ll adjust boostrap.rb. It’s not updated much afterward.

Related: SSM CLI Cheatsheet

deploy

The deploy.rb contains the most options and will be the config you’ll likely adjust most. It controls how the remote runner builds and deploys your project to Serverless AWS Lambda. The jets init provides a starter deploy.rb with helpful comments.

config/jets/deploy.rb

Jets.deploy.configure do
  # CloudFront Lambda URL https://docs.rubyonjets.com/docs/routing/lambda/cloudfront/distribution/
  # config.lambda.url.cloudfront.enable = true
  # config.lambda.url.cloudfront.cert.arn = acm_cert_arn(domain: "domain.com", region: "us-east-1")
  # config.lambda.url.cloudfront.route53.enable = true

  # CloudFront Assets
  # config.assets.cloudfront.enable = true
  # config.assets.cloudfront.cert.arn = acm_cert_arn(domain: "domain.com", region: "us-east-1")
  # config.assets.cloudfront.route53.enable = true

  # Release phase https://docs.rubyonjets.com/docs/hooks/remote/release/
  # config.release.phase.command = "bundle exec rails db:migrate"

  # Scaling https://docs.rubyonjets.com/docs/config/concurrency/
  # config.lambda.controller.provisioned_concurrency = 1  # costs money, always running lambda
  # config.lambda.controller.reserved_concurrency = 25    # free and limits scaling

  # IAM https://docs.rubyonjets.com/docs/iam/app/iam-policies/
  # config.lambda.iam.policy = ["sns"]
  # config.lambda.iam.managed_policy = ["AmazonS3FullAccess"]

  # Docker https://docs.rubyonjets.com/docs/docker/dockerfile/managed/
  # config.dockerfile.packages.apt.build_stage = ["default-libmysqlclient-dev"]
  # config.dockerfile.packages.apt.deployment_stage = ["default-mysql-client"]

  # https://docs.rubyonjets.com/docs/config/package-type/
  config.package_type = "zip"
  config.lambda.controller.enable = false
end

Since this is a lightweight events app, we’ll use the zip package type. For more info see: Package Types

Next, we’ll make sure the AWS config is set up and working properly. Then you’ll be ready to deploy to AWS Lambda.

Getting Started