Зачем?
Ой, не спрашивайте. Хотя почему бы и не поддаться современным веяниям, и не реализовать 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 выглядит последнее время заброшенным, не знаю насколько у Оракла в планах поддерживать его.
