Serverless хостинг в Oracle Cloud для рубиста

Зачем?

Ой, не спрашивайте. Хотя почему бы и не поддаться современным веяниям, и не реализовать REST api на лямбдах.

Проверить так ли уж необходимы Rails и попробовать минимизировать количество зависимостей.

Попробовать декомпозировать веб приложение в терминах облачных сервисов.

Oracle free tier,  хм, насколько это бесплатно в реальности?

Стек

В отличие от Amazon, у Oracle не так много сервисов. С одной стороны это плохо, а с другой — будет проще прикинуть архитектуру.

Итак, если лямбда в Oracle, значит это https://fnproject.io/. Free tier предоставляет 2000000 вызовов лямбд в месяц бесплатно. А еще это значит что наши лямбды будут поставляться как doker образы.

Если лямбда для веба, значит роутить запросы в облаке будет Api Gateway, это бесплатный миллион запросов в месяц (~ 1 запрос в 2.5 секунды). Этот же сервис умеет проксировать запрос к статическому контенту, предоставит https соединение. Он же может авторизовывать запросы и обрабатывать path параметры. Считайте что это аналогия роутера в Rails.

В качестве ORM не хочется брать тяжеловесный ActiveRecord, благо есть Sequel. Он более модульный и имеет адаптеры для большинства БД. Берем.

Для поднятия инфраструктуры в облаке будем использовать Terraform. Вы только гляньте на oracle провайдер от облака, он умеет все, класс.

В качестве бд я возьму Postgresql. Делаю это потому что привык и потому что на бесплатных вариантах Оракл может удалить вашу бдшечку при отсутствии запросов к ней, что неприятно. Но вообще в облаке есть варианты и с документными бд и с оракл бд (куда уж без нее). Использование этих вариантов считаю предпочтительней, поскольку вы можете управлять их схемой через тот же терраформ и хранить ее в стейте.

Итак, поехали.

Начинать стоит с авторизации SDK запросов к облачному Oracle апи. Подробно не будем останавливаться (вот и вот ссылочки в помощь), надо лишь сделать ключ и сохранить конфиг.

Структура проекта

/app — здесь лежит gem с логикой, которая шарится между всеми лямбдами. Согласитесь, хочется пошарить модели/сериалайзеры и прочее.

/client — код SPA фронтенда

/functions — здесь лежат наши лямбды

.tf файлы брошены в корень, терраформ любит знать про все зависимости сразу, пусть так, потом разберемся. В качестве бекенда можно использовать оракловые же бакеты, все как и в амазоне:

//infrastructure.tf  terraform {   required_version = ">= 1.0.0"   required_providers {     oci = {       version = ">= 4.76.0"       source = "oracle/oci"     }   } }  provider "oci" {   config_file_profile = "DEFAULT" }  terraform {   backend "s3" {     bucket   = "terraform-states"     key      = "terraform.tfstate"     region   = "{region-name}"     profile  = "terraform"     endpoint = "https://{namespace}.compat.objectstorage.{region-name}.oraclecloud.com".cm"     shared_credentials_file     = "~/.oci/terraform.secret"     skip_region_validation      = true     skip_credentials_validation = true     skip_metadata_api_check     = true     force_path_style            = true   } }

Деплой приложения происходит в десколько шагов — сначала билдим app гем, потом билдим и заливаем в облако образы функций, применяем изменения в инфраструктуре. С инфраструктурой справляется terraform, апи гейтвей выглядит как то так:

resource "oci_apigateway_gateway" "api_gateway" {   compartment_id = oci_identity_compartment.compartment.id   endpoint_type = "PUBLIC"   subnet_id = data.oci_core_subnet.net.id    display_name = "API Gateway"   freeform_tags = local.default_tags }  resource "oci_apigateway_deployment" "app" {   #Required   compartment_id = oci_identity_compartment.compartment.id   gateway_id     = oci_apigateway_gateway.api_gateway.id   path_prefix    = "/"    specification { routes {       path = "/users.create"       methods = ["POST", "OPTIONS"]        backend {         type        = "ORACLE_FUNCTIONS_BACKEND"         function_id = local.users_function_id       } } }

Типичная лямбда выглядит так

Yaml-файл описания фунции в fnproject. Под капотом собирается докер образ из указанных image, указаны параметры рантайма.

//func.yaml  schema_version: 20180708 name: users version: 0.0.27 runtime: ruby build_image: oci-app:latest // образ для билда run_image: oci-app-run:latest // релиз-образ entrypoint: ruby func.rb memory: 256 timeout: 120

Гемфайл зависимостей лямбды. По-хорошему наш гем стоит указать здесь, я же хотел чтобы гем ставился из локальной папки в проекте, с этим возникли сложности, поэтому гем предустанавливается в базовые докер образы oci-app, oci-app-run

# Gemfile  source "https://www.rubygems.org" do   gem "fdk", ">= 0.0.31"   gem "oci", ">= 2.17.0" end

Сам код функции, все классы Application::* берутся из нашего гема.

require "fdk"  require "oci/common" require "oci/object_storage/object_storage" require "oci/auth/auth" require "oci/secrets/secrets"  require "application"  class UsersController < Application::Controller   def show(input:)     authenticate do       user = input.key?("id") ? Application::User.with_pk!(id: input["id"]) : current_user        Application::UserSerializer.new(user).serializable_hash     end   end    def create(input:)     user = Application::User.new(input["data"]["attributes"].slice("name"))      if user.save       Application::UserSerializer.new(user, include: [:jwt_token]).serializable_hash     else       context.http_context.status_code = 400     end   end end  def route(context:, input:)   UsersController.new(context).route(input: input) end  FDK.handle(target: :route)

Переходим к самому гему.

Докер файлы для базовых образов функций:

// Dockerfile  FROM fnproject/ruby:2.7-dev as build-stage WORKDIR /app_lib RUN microdnf install libpq-devel COPY pkg/* /app_lib RUN gem install /app_lib/* 

// Dockerfile.run  FROM fnproject/ruby:2.7 RUN microdnf install tzdata libpq && microdnf clean all

Билд гема и его включение в базовые образы:

rake build docker build -f Dockerfile -t oci-app:latest . docker build -f Dockerfile.run -t oci-app-run:latest .

Управление лямбдами решил осуществлять средствами команд fnproject: fn start|build|deploy . Удалось организовать локальную среду, то есть те же самые функции работают в локальном fn сервере и отвечают на такие же запросы как и ApiGateway в облаке.

Итог:

• Имеем костяк приложения с базовым роутингом

• Имеем локальную девелопмент среду

• Имеем возможность локально запускать аналог rails консоли из папки гема с коннектом к локальной бд

• Минимум зависимостей от сторонних библиотек, нет rails, нет activesupport

• Практически готовый деплой и возможность деплоить по частям

• Фронтенд и его сборка полностью отдельно и никак не зависит от бекенда, все живет в папке client и деплоится в бакет терраформом. При желании все билд команды можно прописать в терраформе и тогда деплой будет выглядеть просто как `terraform apply`.

• Масштабирование из коробки. Забудьте про скейл группы и мониторинг метрик нагрузки.

• Приложение практически готово к развертыванию в собственном kubernetes кластере

• Благодаря щедротам Oracle, это все бесплатно в известных пределах)

Минусы тоже есть:

• Время холодного старта функций может доходить до 20-30 секунд

• У Оракла существенно меньше облачных сервисов, закрыт буквально минимальный набор

• FnProject выглядит последнее время заброшенным, не знаю насколько у Оракла в планах поддерживать его.