Skip to content

Latest commit

 

History

History
178 lines (101 loc) · 9.64 KB

components.md

File metadata and controls

178 lines (101 loc) · 9.64 KB

Components

Currently only available in Japanese.

NeoShowcaseの開発・運用に使われている要素技術の紹介

Standalone Components

Dockerイメージをビルドするツール

Dockerの代わりにDockerイメージをビルドできて、コンテナの中で動かすことができる。 buildkitdと言うデーモンを起動することでgRPC APIを用いてリモートから操作できるので、NeoShowcaseではこれをアプリビルド用のサーバーとして使う。

Buildkit内部ではLLB(Low Level Build definition format)という中間表現を用いてイメージのビルドを行っており、これを直接操作することも可能。 ただしドキュメントに乏しく、Dockerfile frontendのほうが安定しているため、ほとんどはDockerfile経由でビルドしている。 静的サイトを生成物をイメージから取り出すときなどにLLBを使っている。

Dockerfile無しでアプリケーションのコードからDockerイメージをビルドするツール

アプリケーションが含むファイルやコードから、各"buildpack"が最適なビルド設定を検出し、Dockerイメージを作成する。 自身で"buildpack"を作成することもできる。

NeoShowcaseでは主に、buildpackの実装の一つであるpaketo-buildpacksを使用。

Google謹製のHTTP/2を利用したRPCフレームワーク

NeoShowcaseでは、管理サーバー・ビルドサーバーなど目的別サーバー間の通信手段としてgRPCを用いる。

Protocol Buffer 3形式(.proto)で通信で使う関数の仕様を定義すると、各種言語に対応したサーバー・クライアントのコードを自動生成してくれて、開発者は関数の中身だけ実装すれば良くなる。

例: Controllerコンポーネントのprotoファイル でns-controllerとns-gatewayの通信を定義して、コード自動生成するとこんなコードを自動生成してくれて、自分たちは関数の中身の実装をすればいいだけになる。

A better gRPC.

HTTP/1.1, HTTP/2のPOSTメソッドだけを用いて通信を行うプロトコル。 Connectによって生成されたサーバーまたはクライアントのコードはデフォルトでgRPC, gRPC-Web, Connectの3つのプロトコルに対応する。

Connect protocolのWebクライアントはデフォルトでapplication/jsonで通信を行うため、人間が理解しやすく、既存のRESTful APIのエコシステムにも上手くハマる。 NeoShowcaseではこの利点を生かしてtraefik forward auth middlewareに認証を委譲している。

モダンなリバースプロキシ

各コンポーネントの接続と、ユーザーのアプリへのルーティングに使用している。 K8s backendでは、Ingress Controllerとして使用。

.protoファイルから.goファイルなどを生成するときに使うコンパイラ

make init で入るようにしてある。 macならbrew install protobufでも入るはず。

protoc-gen-go (protocのgoコンパイルプラグイン) が必要。 インストール: go install google.golang.org/protobuf/cmd/protoc-gen-go

https://grpc.io/docs/languages/go/quickstart/ も参照

gRPC用クライアント

gRPCは当然Postmanとかcurlとかでアクセス出来ないので、デバッグするときとかには専用クライアントが必要。 これは対話的に呼び出せたりして補完とかも効くので便利。

The easiest idempotent MySQL/PostgreSQL/SQLite3/SQL Server schema management by SQL.

.sqlファイルにテーブルやindex, foreign keyの定義を書いて、sqldef schema.sql すると、.sqlファイルの内容に沿うようにスキーマを変更してくれる。

マイグレーションバージョンの管理が必要なく、冪等で扱いやすい。 新・旧どちらのバージョンにも互換性のあるスキーマを定義し、sqldefでスキーマを更新してから新しいバージョンのデプロイを行うのが普通。 ただし少し凝ったスキーマの変更を行うときは、データの手動マイグレーションが必要になったり、データがうっかり落ちないように注意する必要がある。

sql-migrate (現在不使用 -> sqldef)

DBスキーママイグレーションツール

新たなテーブルを追加したり、既存のテーブルのカラムを追加したりして、開発中にDBのテーブル構造を変えるときに、その変更手順や巻き戻し手順を書いて、DBの構造のバージョン管理をするようにするためのツール。 多分一番シンプル。マイグレーションバージョンの管理、正しいマイグレーションスクリプトの管理を自分で行う必要がある。

NeoShowcaseでは昔sql-migrateを使っていたが、冪等なツールが便利そうだったのでsqldefに移行した。

RDBドキュメント自動生成ツール

実際のDBからER図やドキュメントを自動生成したり、DBのLintなどもできる。

例: こういうのを自動生成する。

Goコード用のLinter

Linter: コードのフォーマットを指摘してくれたり、危ないコードや不要なコードを検出してくれるツール

swagger / OpenAPI 3.0 (現在不使用 -> Connect)

HTTPのAPI仕様を記述するための仕様

traPの内製サービスはほぼ全てこれでAPIの仕様を決定している。 https://apis.trap.jp/

NeoShowcaseでは、昔、Webダッシュボード(管理画面)とサーバー間のAPI仕様を書くのに使っていた。 現在はprotocファイルにかかれていることが全て。

spectral (現在不使用)

swagger.yaml用のLinter

Go Libraries

Go用のSQLDBのORマッパージェネレーター

他のSysAdプロジェクトでGoからMariaDBにアクセスするときには主にGormというORMライブラリを使ってますが、NeoShowcaseではデータベースのスキーマからORMライブラリを生成するsqlboilerを使います。 NeoShowcase専用のORMライブラリが出来る。

DBスキーマに従ってDBを作成した後、そのDBの構造に従った構造体をこんな感じで自動生成してくれる。

参考: Goの新定番?ORMのSQLBoilerを使ってみる | Qiita SQLBoiler の使い方を簡単にまとめた | note

SysAd内のデファクトスタンダードなWebサーバーライブラリ

built-inのstatic-site generator内で使用

コンソールログをいい感じに出力するようにするやつ

Goの標準logライブラリと互換性があるのでimport文変えるだけで使える。 NeoShowcase自身のログの出力にはこれを使う。

cobraはGoのコマンドラインツール作成支援ライブラリ viperは設定ファイル取り扱いライブラリ

同じ作者のライブラリで連携している。 NeoShowcaseでは、cmd以下で、実際の実行バイナリのコマンドを作るのに使う。

DI(Dependency Injection)のためのコードを自動生成してくれるライブラリ

参考: https://github.com/google/wire/tree/main/_tutorial

GoからDockerを操作するための公式ライブラリ

backend/dockerimpl中で使ってる。

Hub (現在不使用)

PubSub型の内部イベントバスライブラリ。

コード内でイベントのPublish / Subscribeができる。 イベントバス使うとコード依存が疎結合になってメンテしやすくなる。

任意のコントロールフローのスパゲッティ化を容易にしてしまうため、使いすぎには注意。 必要ない場合は使わない方が吉かも。