💭

OSSなローコードツールBudibase

2022/06/06に公開約8,600字

概要

Budibaseは社内向けのWebアプリを作るためのローコードツールです
OSSでセルフホストも可能です
簡単な操作で社内システムを作れるのが特徴みたいです

公式サイトのテンプレートを見ると作成できるアプリの雰囲気が分かると思います

一通り機能を触ってみたので構築メモを残しておきます

例として以下のようなアプリを作ってみます
sshの公開鍵の署名依頼フォームです

flow

ssh公開鍵認証は便利なのですが、CA役の人に作業が集中するので軽減策を考えているという設定

slack

※ この程度ならGoogle Formsとか, Google AppSheetでも可能ですし、そもそもsshを使う機会が減っていますが例と言う事で・・・

インストール

今回はGKEを使用します
クラスタを作成(autopilotを使用したい場合はcreate-autoコマンドです)

gcloud beta container clusters create "cluster-budibase" --region "asia-northeast1" --machine-type "e2-small" --spot --num-nodes "1"  --workload-pool "project-id.svc.id.goog"

helmを使って必要なリソースを立ち上げ

helm show values budibase/budibase > config.yaml
vim config.yaml # ingressはfalseにしておきます (GCLB使うので)
helm install --create-namespace --namespace budibase budibase budibase/budibase -f config.yaml 
kubectl config set-context $(kubectl config current-context) --namespace=budibase 

ログインはgoogle認証を使います
callback URLにhttpsが必要なので、httpsのingressを作ります

curl -L https://bit.ly/3vW6s1a > ingress.yaml
kubectl apply -f ingress.yaml 

こんな感じの画面が出たらOK
adminアカウントを作成します

top

GCSも触れるようにしておきます
サービスアカウントと紐付け
(今回はdefaultにストレージ管理者を紐づけていますが、スコープを絞ったほうが良いかと思います)

gcloud iam service-accounts create gke-default

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:projectname.svc.id.goog[budibase/default]" \
  gke-default@projectname.iam.gserviceaccount.com

kubectl annotate serviceaccount default \
  iam.gke.io/gcp-service-account=gke-default@projectname.iam.gserviceaccount.com

gcloud projects add-iam-policy-binding projectname \
 --member serviceAccount:gke-default@projectname.iam.gserviceaccount.com \
 --role roles/storage.admin

認証

ログインにはgoogle認証を使います

以下の通りクライアントIDとシークレットを取得します

https://support.google.com/workspacemigrate/answer/9222992?hl=ja

ユーザーの種類は内部でOKかと思います

naibu

あとは、トップからAuthを選んで、ClientID, ClientSecretを入力すればOKです

google-auth

googleログインできるようになります

google-login

メール送信

メール送信はsendgridに転送して送ります
APIで送る方法もありますが、今回は単純にSMTPで転送 します

sendgrid

アプリの作成

アプリの作成は左メニューのAppを選んで適当な名前を付けて作成します

start

まずデータベースの種類を選びます
今回は内蔵のDB(Budibase DB)を使用しますが、MySQLやAirtable等いろいろ選べるので
慣れたDBでOKかと思います

db-select

signing_request テーブルという名前で作成します

create-table

画面は左からDBの設定を行う「Data」, 画面を作る「Design」, その他連携処理を書く「Automate」があります
今回はDB -> automation -> designの順で作っていきます

start-page

DBの作成

以下のようなテーブルを作成してみます

カラム名 Type 制約 備考
email String 必須 申請者のメールアドレス
ssh_pub_key Attachment 必須 ssh公開鍵
principals Options 必須 developer, admin, rootのどれか
validity_interval_month Number 必須 1〜12までの範囲 有効期間(単位は月)
status Options reject, acceptのどれか 承認されたか否か
reason Text rejectされた場合の理由

テーブル定義は画面からポチポチ作ります
このとき、データの制約条件を入れておくと、フォーム画面でvalidationもしてくれるので楽になります
今回はテーブルが一つなので作りませんでしたが、リレーションを作るときもTypeから選択します

db

automation

automation

automationはDBの更新だけではない外部サービスとの連携などを作ります
こんな感じのシステムに連携できます

renkei

直接bashスクリプトをたたくこともできますが、パッケージのインストールを行う必要があるので、違うpodに連携させる形にします

今回はNode-RED を使ってjsonを受け取り、bashスクリプトを実行してssh鍵の署名
結果をwebhookでbudibaseに伝えます

https://gist.github.com/yaasita/57bc7aa67a5bbac760af954056e1ec7c

Docker buildして、コンテナを Artifact Registry に入れておきます
同じクラスタでnode-redを動かします

kubectl create secret generic ssh-ca-key --from-file=ssh-privatekey=/path/to/.ssh/ca.key
vim conf.sh
kubectl apply -k .

あとは、jsonを受けて、bashスクリプトを走らせるように設定

node-red1

budibase -> Node-REDへのスクリプト

fetch("http://node-red.budibase.svc.cluster.local/sign", {
  method: "POST", 
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    id: trigger.fields.id,
  }),
});

こんな感じで、App Actionをトリガーにして、JS SCRIPTINGを実行するようにフローを作ります
下の画像はidを受け取って、javascriptを実行するトリガーです

sign-trigger

Node-RED -> budibaseへの処理
メールを送る処理です

mail

今回メールのテンプレートはデフォルトのままですが、変更した場合はトップ画面のEmail->Templatesから変更可能です

email-template

対象が公開鍵なので、アクセス制限なしでGCSに置いてますが、
気になる人はランダム文字列を付与したり、署名付きURLを使うと良いと思います

画面の作成

次は画面の作成を行います
申請者をBasic権限、承認者をadmin権限として作成します

操作は左メニューで権限とURL、上部のメニューから配置したいパーツ、パーツごとの細かい設定を右メニューから行います
ちなみにアプリはSPAとして作成されますので、見た目上URLは変化しますが遷移はしていません

design

basic画面

basic権限の画面を作成します

レイアウトは使わないのでまっさらな画面に申請フォームを作るだけです
画面に必要なパーツを配置します
デザインはEdit custom CSSボタンから直接調整もできますが、今回は画面から配置するだけにします

haiti

validation はテーブル作成の際に制約を入れたので、
フォームをDBと紐づけると勝手にやってくれますが、自分で定義したい場合はConfigure validationボタンから行います

送信ボタンを押したときの挙動を定義
完了画面も作っておきます

submit

PCサイズ画面、タブレット画面、スマホ画面での見え方を確認
右上の再生ボタンでテスト

saisei

フォームに入力してみます
DBにもデータが入っているのを確認

data1

admin画面

admin画面は承認画面と、自分自身も申請を行いたいので申請画面も用意します
タブのレイアウトを選択

layouts

申請画面はbasic権限の画面をコピーしてもってきます

copy

CRUDの雛型を自動的に作るウィザードがあるのでそれを利用してベースとします

crud

あとは同様にパーツを置いていくだけです
ボタン押したときの確認はモーダルで表示するようにします

create-admin

申請一覧の画面はフィルタを作って、まだ結末がついてない申請だけを表示します

filter

申請一覧ではaccept, rejectに応じて後続の処理を変えます
許可なら、公開鍵の署名を、拒否なら理由をつけて、申請者にメールします

Define actionsから、設定します

actions

テスト

一通り作成できたのでテストしてみます

まず、ユーザー権限でログインして、公開鍵と要求する権限を選択して申請

sinsei

admin権限の人が承認ボタンを押したり、拒否ボタンを押します

admin-sousa

するとメールが飛んできて署名済みの公開鍵が手に入ります

承認時はGCSのURLが

accept-mail

拒否の時は理由が入っています

reject-mail

大丈夫そうです

まとめ

今回デザインはデフォルトで作成しましたのでだいぶ簡素なものになりました
automation含め一通り使ったので作成イメージは大方つかめた気がします
budibaseはotusystem, bubble等に比べると機能は少ないですが、その分シンプルなので簡単に使えると思います

Discussion

ログインするとコメントできます