DB Streaming ツール materialize を試してみた。

こんにちは k-jun です。今回は Rust 製の DB Streaming ツール materialize を試してみようとおもいます。

https://github.com/MaterializeInc/materialize

某デザインツールと名前が似ているは気にしなかったのでしょうか...? どうやら PostgreSQL を利用するようです。 どうやら firestore のように Client と非同期に通信するのではなく、Database 自体が非同期にデータを取り込んでいるっぽい...?

Run

Docker が用意されているのでこれで起動してみます。

$ docker run -p 6875:6875 materialize/materialized:v0.9.6 --workers 1

PostgereSQL 互換のようなので、psql で接続していきます。

$ psql -U materialize -h localhost -p 6875 materialize
psql (13.4, server 9.5.0)
Type "help" for help.

materialize=>

何やら怪しげな SQL を叩いていきます。

materialize=> CREATE SOURCE market_orders_raw
FROM PUBNUB
SUBSCRIBE KEY 'sub-c-4377ab04-f100-11e3-bffd-02ee2ddab7fe'
CHANNEL 'pubnub-market-orders';
CREATE SOURCE

materialize=> SHOW COLUMNS FROM market_orders_raw;
 name | nullable | type
------+----------+------
 text | f        | text
(1 row)

どうも、ここ からデータを取り込んで Stream で流すみたいですね。それがなぜ Database の層で完結するのかは謎ですが。

materialize=> CREATE VIEW market_orders AS
SELECT
    ((text::jsonb)->>'bid_price')::float AS bid_price,
    (text::jsonb)->>'order_quantity' AS order_quantity,
    (text::jsonb)->>'symbol' AS symbol,
    (text::jsonb)->>'trade_type' AS trade_type,
    to_timestamp(((text::jsonb)->'timestamp')::bigint) AS ts
FROM market_orders_raw;
CREATE VIEW

うーん。知らん syntax だし色々と謎。

CREATE MATERIALIZED VIEW avg_bid AS
SELECT symbol,
       AVG(bid_price) AS avg
FROM market_orders
GROUP BY symbol;

materialize=> SELECT * FROM avg_bid;
   symbol    |        avg
-------------+--------------------
 Apple       | 200.12943851142316
 Google      | 303.64465372226175
 Elerium     |  153.0859976127034
 Bespin Gas  | 221.24196606620828
 Linen Cloth | 245.64254669609824
(5 rows)

なんか取れたけど。なるほど、実際に流れているデータをカテゴライズした結果が返ってきているのか。

https://materialize.com/use-cases/

usecases を見てみると、リアルタイムな分析やエラー検知とどうもサービスで使用するというよりはその周りで使用することが想定されているみたい...? 今の所使いみちは自分も思いついていませんが、時間ができたらもう少し触ってみようと思います。

それでは今回はこのへんで。

次世代の データベース CockroachDB を試してみた。

こんにちは、 k-jun です。今回は Spanner の OSS 実装であり次の世代のデータベースとなりうる CockroachDB を試していこうと思います。 同系統の TiDB が MySQL 互換なのに対してこちらは Postgres 互換のようですね。Aurora 互換のこういう DB 出ないかしら...?

https://github.com/cockroachdb/cockroach

https://www.cockroachlabs.com/

公式のドキュメントを参照してみると以下の項目が羅列されており、Cockroach の由来はここら辺なんじゃないのかなぁとなんとなく思っています。

  • SCALE FAST
    • Build fast & build to last Familiar SQL
    • Elastic Scale Grow locally and/or globally
  • SURVIVE ANYTHING
    • Bulletproof Resilience Survive any failure
    • Consistent Transactions Guarantee data correctness
  • THRIVE EVERYWHERE
    • Geo-partitioned data Performance & Regulatory Compliance
    • Hybrid and multi-cloud Deploy on and across any cloud

ゴキブリのような生命力を DB に求めるかと言われればそれは YES なんですけれども...。システムの最も重要な箇所がゴキブリに荒らされているような感覚に陥りますね...。 Docker でサクッと試せそうなのでそちらで起動してみます。あとは適当に sysbench で SQL が使えるかどうかと性能を見てみます。ゴキブリのような生命力を有しているのかの確認もしてみたいですが 笑、今回はパスです。

Run

ここら辺 を参考にやってみる。

# docker network
$ docker network create -d bridge roachnet

# cockroach cluster
$ docker run -d \
--name=roach1 \
--hostname=roach1 \
--net=roachnet \
-p 26257:26257 -p 8080:8080  \
-v "${PWD}/cockroach-data/roach1:/cockroach/cockroach-data"  \
cockroachdb/cockroach:v21.1.9 start \
--insecure \
--join=roach1,roach2,roach3

# cockroach node
$ docker run -d \
--name=roach2 \
--hostname=roach2 \
--net=roachnet \
-v "${PWD}/cockroach-data/roach2:/cockroach/cockroach-data" \
cockroachdb/cockroach:v21.1.9 start \
--insecure \
--join=roach1,roach2,roach3
c0b9420b32548db935009c779b1e23d7277d3e6599ac4c07642c3e2b30ac22f
$ docker run -d \
--name=roach3 \
--hostname=roach3 \
--net=roachnet \
-v "${PWD}/cockroach-data/roach3:/cockroach/cockroach-data" \
cockroachdb/cockroach:v21.1.9 start \
--insecure \
--join=roach1,roach2,roach3

謎のコマンド。initialization みたい。

$ docker exec -it roach1 ./cockroach init --insecure
Cluster successfully initialized
$ docker exec -it roach1 grep 'node starting' cockroach-data/logs/cockroach.log -A 11
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +CockroachDB node starting at 2021-09-23 20:21:01.726278 +0000 UTC (took 109.8s)
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +build:               CCL v21.1.9 @ 2021/09/20 21:47:27 (go1.15.14)
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +webui:               ‹http://roach1:8080›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +sql:                 ‹postgresql://root@roach1:26257?sslmode=disable›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +RPC client flags:    ‹/cockroach/cockroach <client cmd> --host=roach1:26257 --insecure›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +logs:                ‹/cockroach/cockroach-data/logs›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +temp dir:            ‹/cockroach/cockroach-data/cockroach-temp470954380›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +external I/O path:   ‹/cockroach/cockroach-data/extern›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +store[0]:            ‹path=/cockroach/cockroach-data›
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +storage engine:      pebble
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +status:              initialized new cluster
I210923 20:21:01.726415 85 1@cli/start.go:704 ⋮ [-] 182 +clusterID:           ‹6ee045f0-07a0-455a-bf12-bfe6c95e138d›

以下のコマンドを実行することで SQL の Interface を利用することが出来る。

$ docker exec -it roach1 ./cockroach sql --insecure
#
# Welcome to the CockroachDB SQL shell.
# All statements must be terminated by a semicolon.
# To exit, type: \q.
#
CREATE DATABASE bank;
CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
INSERT INTO bank.accounts VALUES (1, 1000.50);
SELECT * FROM bank.accounts;

うーん... 実行しても出力が何も返らない... ダメそう ...。なにか間違えたのだろうか...? console が localhost:8080 に立っているようなのでこれを見てみる。

f:id:K-jun1221:20210924053018p:plain

database が defaultdb / postgres / system 以外に作成されていないのでダメそう。 しかし local の docker で構築しても console が付与されているのは非常に体験として良いな。

postgres の client app で直接中身を覗いてみる。

$ psql -h 127.0.0.1 -p 26257 -U root -d defaultdb
psql (13.4, server 13.0.0)
Type "help" for help.

defaultdb=# CREATE DATABASE bank;

もろもろ確認してみるとどうやら node が2つとも落ちていたようです。詳細にログを追ってはいないので詳細は不明ですが。 再起動してみると動くようになったので先程の SQL をポチポチしてみます。

defaultdb=# CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
defaultdb=# INSERT INTO bank.accounts VALUES (1, 1000.50);
defaultdb=# SELECT * FROM bank.accounts;
 id | balance
----+---------
  1 | 1000.50
(1 row)

おおお...! 実行できていそうです。いい感じに postgres 互換ですね。sysbench を実行してみますか。

$ brew install sysbench --with-postgresql
...
Error: invalid option: --with-postgresql

https://github.com/akopytov/sysbench/issues/302

brew install ができないじゃねえか...。辛い...。うーん。。。まあ、CockroachDB が起動することは確認できましたし今回はこれでよしとしましょう。 後で ubuntu 環境に TiDB と CockroachDB を起動して sysbench で性能を比べてみるとかやって見ます 笑。

それでは今回はこのへんで。

AWS の 新サービス AppRunner を今頃試してみる。

こんにちは k-jun です。AWS から提供されている新サービスの AppRunner を試してみようと思います。

2021/05 に AWS から提供が開始されたサービスです。GCP の Cloud Run を意識したような 名前をしています。

実態としては Container Image を指定するだけでアプリケーションのスケール・分散まで行ってくれる、まさに Container を指定すればあとはこっちで勝手にやっとくわ。なサービスです。 c5.large 料金的に比較してみます。

ap-northeast-1 vCPU RAM(GB) vCPU per hour RAM(GB) per hour doller per hour doller per month
c5.large 2 4 - - 0.107 77.04
apprunner 2 4 0.081 0.009 0.198 142.56

ざっと ec2 と比較して 2倍位ですね。スケーリングすることを加味すると良さげにも見えますが、ec2 も結局オートスケール出来るので Deploy の手間賃が加算されているんでしょうね。

今回は簡単なアプリケーションを Rust で作成し、Github Actions で Build したものを ECR に Push。App Runner で設定しその後の Deploy を自動化するところまでやってみます。

まずはアプリケーションの作成から。面白そうな API があったのでこれを in-memory に保存するアプリにします。プロトコルは HTTPS/HTTP が対応しているようですね。

https://github.com/k-jun/advices-api

Actions も設定して、master に push したら ECR に image を push するようにしておきました。

ではでは AppRunner の設定に入ります。vCPU と Memory は 1 core と 2 GB に。in-memroy なのでスケーリングすると整合性が取れなくなりますが、そこらへんはご愛嬌です。 Auto Scaling もデフォルトのものを使用。Port は 3000 に。

f:id:K-jun1221:20210921031417p:plain

あとは設定していて気づきましたが、これは Health Check は TCP ベースなんですね...。リソースがフルに使われでもしない限り TCP ヘルスチェックは引っかからないと思うので、それなりにスケーリングは遅そうです。後で HTTP ペースのものが追加されるんですかね。

$ curl https://d68fmvi2ky.ap-northeast-1.awsapprunner.com/
0.1.0
$ curl -XPOST https://d68fmvi2ky.ap-northeast-1.awsapprunner.com/advices
{"id":168,"advice":"Do a bit more for your friends."}
$ curl -XPOST https://d68fmvi2ky.ap-northeast-1.awsapprunner.com/advices
{"id":198,"advice":"Sing in the shower."}
$ curl -XPOST https://d68fmvi2ky.ap-northeast-1.awsapprunner.com/advices
{"id":57,"advice":"If you get stuck, try doing the opposite of what the solution requires."}

いい感じですね。Dockerfile の内容ですが、Rust の Multi Container Build を試してみたところ、AppRunner の log が "Service status is set to OPERATION_IN_PROGRESS." からさきに進まず 約一時間程度立った後に終了するという自体が発生したので Single Container Build にしました。本格的に使用する際にはもう少し確認してみます。

CI からの Deploy が出来ることもわかりましたし、いい感じですね。それでは今回はこのへんで。

TUI ベースの RDS クライアントツール gobang を試してみる。

こんにちは k-jun です。今日は約一週間ほど前に登場し、またたく間に 1000 star を獲得した TUI ベースの RDS クライアントツール gobang を試してみようと思います。

https://github.com/TaKO8Ki/gobang

Rust で記述されており、Sequal Ace 等の各種 GUI ベースのクライアントツールがサポートしている挙動をほとんど行えるようで、そりゃ star も集まるよなという印象です。

Install

インストールも扱いやすく、brew で提供されています。

$ brew install tako8ki/tap/gobang

Run

ひとまず適当に、MySQL を起動して試してみます。

$ docker run -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root -e MYSQL_USER=test -e MYSQL_PASSWORD=test -e MYSQL_DATABASE=test -d mysql:5.7

config ファイルを生成して gobang の引数に渡します。

$ cat /tmp/config.toml
[[conn]]
type = "mysql"
user = "test"
password = "test"
host = "localhost"
port = 3306
$ gobang -c /tmp/config.toml

f:id:K-jun1221:20210920021753p:plain

いい感じですね。database test には何も table を生成していないので、ここを作ってみます。 readme 勝手に SQL が直で打てるものかと思っていましたがどうも違うようです。WHERE の条件を簡単に検索出来るぐらいみたいですね。

適当に table と row を生成したので、改めて中身を見てみます。

f:id:K-jun1221:20210920023400p:plain

簡易的な検索も聞くようです。検索というよりは Filter に近いですね。

f:id:K-jun1221:20210920023420p:plain

結構いい感じに使えそうです。何より TUI でここまで出来るというのがすごい !!! 自分も見習って何かしら便利なものを作りたいです !! それでは今回はこのへんで。

認証情報の漏洩をシステム的に検知する gitleaks を試してみる。

こんにちは k-jun です。今回は git 管理下にある現在のコード、過去のコミット履歴などから包括的に認証情報が漏洩していないかを確認できるツール gitleaks を試してみようと思います。

https://github.com/zricethezav/gitleaks

基本的には gitactions で CI/CD としてセットすることが想定されているみたいですね。 一度 github にあげてしまうと手遅れ感はあるので、それよりは未然に防ぐために手元で git push のエイリアスに設定されていると良いかもしれませんね。

Install

$ brew install gitleak

brew で簡単にインストールできます。

Run

$ gitleaks
INFO[0000] opening .
INFO[0000] scan time: 35 milliseconds 632 microseconds
INFO[0000] No leaks found

適当に実行してみると何やらチェックらしきものが走っています。ではでは検証として適当にパスワードっぽいものを生成して .env なんかに貼り付けてみます。

$ echo "kJutbFnW52aB8C4Al1ph0LuMOvYIYzSP4GZfXXXXX" > .env

~/ghq/github.com/k-jun/playground-pulumi master*
$ gitleaks
INFO[0000] opening .
INFO[0000] scan time: 14 milliseconds 168 microseconds
INFO[0000] No leaks found

あれ...? なにも反応しない...??

$ echo AWS_ACCESS_KEY='XXXXXXbFnW52aB8C4Al1ph0LuMOvYIYzSP4GZfvksdnv/dsa' > .env

~/ghq/github.com/k-jun/playground-pulumi master*
$ gitleaks
INFO[0000] opening .
INFO[0000] scan time: 13 milliseconds 264 microseconds
INFO[0000] No leaks found

うーんこれでも反応しない...。リポジトリの url を直接指定できるようなのでそれで試してみる。

$ gitleaks --repo-url https://github.com/zricethezav/gronit -v
INFO[0000] cloning... https://github.com/zricethezav/gronit
Enumerating objects: 228, done.
Counting objects: 100% (78/78), done.
Compressing objects: 100% (51/51), done.
Total 228 (delta 34), reused 17 (delta 9), pack-reused 150
{
        "line": "const AWSKEY string = \"AKIAIO5FODNN7EXAMPLE\"",
        "lineNumber": 12,
        "offender": "AKIAIO5FODNN7EXAMPLE",
        "offenderEntropy": -1,
        "commit": "034344be2227771ae9f020358ad68230debfbb9d",
        "repo": "gronit",
        "repoURL": "https://github.com/zricethezav/gronit",
        "leakURL": "https://github.com/zricethezav/gronit/blob/034344be2227771ae9f020358ad68230debfbb9d/main.go#L12",
        "rule": "AWS Access Key",
        "commitMessage": "secret\n",
        "author": "Zach Rice",
        "email": "zricer@protonmail.com",
        "file": "main.go",
        "date": "2021-04-20T09:04:44-04:00",
        "tags": "key, AWS"
}

おおお!!! こんな感じに出るのね。リポジトリレベルで指定できるのはかなり有り難いですね。CI がどこで動くかを考えるまもなく、同じコマンドを実行しておけば良いので。 .git/hooks/pre-commit に書き込むとこのように、commit 前にチェックしてくれます。認証情報を万が一 commit した際に備えて設定しておくと良いかもしれませんね。

$ git commit -m 'feat(docs): update readme'
INFO[0000] opening ./
INFO[0000] scan time: 69 milliseconds 727 microseconds
INFO[0000] commits scanned: 62
WARN[0000] leaks found: 7

これでローカルの環境が少しだけ安全になりました。それでは今日はこのへんで...!

Wireshark の CLI 版 TShark を試してみる。

こんにちは k-jun です。今回は、Wireshark より簡易的に使用できて高速な TShark を試してみようと思います。

https://github.com/wireshark/wireshark

The Wireshark distribution also comes with TShark

記載の通り、Wireshark にくっついて来るみたいですね。今回は tpcdump でキャプチャしたパケットを閲覧してみたいと思います。

Install

$ brew install wireshark
$ which tshark
/usr/local/bin/tshark

Run

まずは tcpdump でパケットをキャプチャします。-w でファイル名を指定することで対象ファイルへのパケットがキャプチャされます。 今回は適当に EC2 インスタンスを AWS 環境に立ち上げ、Nginx を起動させておきます。EC2インスタンス に対してローカルから cURL を発行し、インスタンス上で tcpdump を打っておきパケットを確認してみます。

$ sudo apt update -y
$ sudo apt install -y nginx
$ sudo tcpdump -w /tmp/tcpdump -i any port 80

rsync で手元に持ってきてから tshark で中身を見てみます。port は 80 に限定します。

$ rsync -azv ubuntu@XX.XXX.XX.XXX:/tmp/tcpdump /tmp/tcpdump
$ tshark -r /tmp/tcpdump 'tcp.dstport==80'
    1   0.000000 106.165.44.175 → 10.1.101.115 TCP 80 55327 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=597833747 TSecr=0 SACK_PERM=1
    2   0.000023 10.1.101.115 → 106.165.44.175 TCP 76 80 → 55327 [SYN, ACK] Seq=0 Ack=1 Win=62643 Len=0 MSS=8961 SACK_PERM=1 TSval=2055342097 TSecr=597833747 WS=128
    3   0.015210 106.165.44.175 → 10.1.101.115 TCP 68 55327 → 80 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=597833762 TSecr=2055342097
    4   0.015233 106.165.44.175 → 10.1.101.115 HTTP 144 GET / HTTP/1.1
    5   0.015237 10.1.101.115 → 106.165.44.175 TCP 68 80 → 55327 [ACK] Seq=1 Ack=77 Win=62592 Len=0 TSval=2055342112 TSecr=597833762
    6   0.015388 10.1.101.115 → 106.165.44.175 HTTP 927 HTTP/1.1 200 OK  (text/html)
    7   0.029359 106.165.44.175 → 10.1.101.115 TCP 68 55327 → 80 [ACK] Seq=77 Ack=860 Win=130880 Len=0 TSval=597833777 TSecr=2055342113
    8   0.029629 106.165.44.175 → 10.1.101.115 TCP 68 55327 → 80 [FIN, ACK] Seq=77 Ack=860 Win=131072 Len=0 TSval=597833777 TSecr=2055342113
    9   0.029649 10.1.101.115 → 106.165.44.175 TCP 68 80 → 55327 [FIN, ACK] Seq=860 Ack=78 Win=62592 Len=0 TSval=2055342127 TSecr=597833777
   10   0.043834 106.165.44.175 → 10.1.101.115 TCP 68 55327 → 80 [ACK] Seq=78 Ack=861 Win=131072 Len=0 TSval=597833791 TSecr=2055342127

tshark で中身は見れましたが、これ EC2 インスタンスの Private の IP Address ですね..。106.165.44.175 は自分の IP っぽいですが...。 どうも不思議ですね..。手元でも tcpdump を取ってみます。

$ tshark -r /tmp/tcpdump_send 'tcp.port==80'
    1   0.000000 192.168.0.24 → 35.75.22.116 TCP 78 56004 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=598576611 TSecr=0 SACK_PERM=1
    2   0.016389 35.75.22.116 → 192.168.0.24 TCP 74 80 → 56004 [SYN, ACK] Seq=0 Ack=1 Win=62643 Len=0 MSS=1460 SACK_PERM=1 TSval=2056091860 TSecr=598576611 WS=128
    3   0.016430 192.168.0.24 → 35.75.22.116 TCP 66 56004 → 80 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=598576627 TSecr=2056091860
    4   0.016518 192.168.0.24 → 35.75.22.116 HTTP 142 GET / HTTP/1.1
    5   0.032305 35.75.22.116 → 192.168.0.24 TCP 66 80 → 56004 [ACK] Seq=1 Ack=77 Win=62592 Len=0 TSval=2056091876 TSecr=598576627
    6   0.032305 35.75.22.116 → 192.168.0.24 TCP 66 [TCP Dup ACK 5#1] 80 → 56004 [ACK] Seq=1 Ack=77 Win=62592 Len=0 TSval=2056091876 TSecr=598576627
    7   0.032466 35.75.22.116 → 192.168.0.24 HTTP 925 HTTP/1.1 200 OK  (text/html)
    8   0.032501 192.168.0.24 → 35.75.22.116 TCP 66 56004 → 80 [ACK] Seq=77 Ack=860 Win=130880 Len=0 TSval=598576642 TSecr=2056091876
    9   0.032723 192.168.0.24 → 35.75.22.116 TCP 66 56004 → 80 [FIN, ACK] Seq=77 Ack=860 Win=131072 Len=0 TSval=598576642 TSecr=2056091876
   10   0.048712 35.75.22.116 → 192.168.0.24 TCP 66 80 → 56004 [FIN, ACK] Seq=860 Ack=78 Win=62592 Len=0 TSval=2056091892 TSecr=598576642
   11   0.048769 192.168.0.24 → 35.75.22.116 TCP 66 56004 → 80 [ACK] Seq=78 Ack=861 Win=131072 Len=0 TSval=598576658 TSecr=2056091892

手元からは 35.75.22.116 に http request を送信しているように見えています。こちらの Source IP も Private IP になっていますしそういうものということですかね。

内容的には しっかり SYN -> SYN,ACK -> ACK の 3way ハンドシェイクや切断時の FIN,ACK -> FIN,ACK -> ACK も確認できます。

また TShark は実は直接 パケットキャプチャを行うことができます。tcpdump で取得だけを行ったのは TShark をインストールできないリモートサーバーを想定していたためでした。 できることを試さないのも怠慢なのでやってみます。

$ sudo apt install -y tshark
$ sudo tshark -Y 'tcp.port==80'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens5'
    1 0.000000000 106.165.44.175 → 10.1.101.115 TCP 78 56799 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=599940646 TSecr=0 SACK_PERM=1
    2 0.000021621 10.1.101.115 → 106.165.44.175 TCP 74 80 → 56799 [SYN, ACK] Seq=0 Ack=1 Win=62643 Len=0 MSS=8961 SACK_PERM=1 TSval=2057468236 TSecr=599940646 WS=128
    3 0.014247052 106.165.44.175 → 10.1.101.115 HTTP 142 GET / HTTP/1.1
    4 0.014262153 10.1.101.115 → 106.165.44.175 TCP 66 80 → 56799 [ACK] Seq=1 Ack=77 Win=62592 Len=0 TSval=2057468251 TSecr=599940660
    5 0.014275806 106.165.44.175 → 10.1.101.115 TCP 66 56799 → 80 [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=599940660 TSecr=2057468236
    6 0.014278135 10.1.101.115 → 106.165.44.175 TCP 66 [TCP Dup ACK 4#1] 80 → 56799 [ACK] Seq=1 Ack=77 Win=62592 Len=0 TSval=2057468251 TSecr=599940660
    7 0.014423231 10.1.101.115 → 106.165.44.175 HTTP 925 HTTP/1.1 200 OK  (text/html)
    8 0.028525676 106.165.44.175 → 10.1.101.115 TCP 66 56799 → 80 [ACK] Seq=77 Ack=860 Win=130880 Len=0 TSval=599940673 TSecr=2057468251
    9 0.028532464 106.165.44.175 → 10.1.101.115 TCP 66 56799 → 80 [FIN, ACK] Seq=77 Ack=860 Win=131072 Len=0 TSval=599940673 TSecr=2057468251
   10 0.028558085 10.1.101.115 → 106.165.44.175 TCP 66 80 → 56799 [FIN, ACK] Seq=860 Ack=78 Win=62592 Len=0 TSval=2057468265 TSecr=599940673
   11 0.042741897 106.165.44.175 → 10.1.101.115 TCP 66 56799 → 80 [ACK] Seq=78 Ack=861 Win=131072 Len=0 TSval=599940687 TSecr=2057468265

いい感じですね。tcpdump と同じような内容が観測できました。CLI であるがゆえに簡単に環境に入れられ見たいものも見れたので満足です。 今後必要に応じて使っていこうと思います。それでは今回はこのへんで。

Postman の代替ツール Ain を触ってみる。

こんにちは k-jun です。今回は Postman のように API サーバーにリクエストを投げる Ain を試してみます。

https://github.com/jonaslu/ain

Postman との差別点は Cli で完結している点ですね。意外と便利で 設定ファイルに格納できれば、確認 URL として GitHub に収めることも可能になります。 他 Postman に似たツールとして paw、insomnia. も存在するようですね。知りませんでした...。

Install

$ go install github.com/jonaslu/ain/cmd/ain@latest

Run

ではでは、早速試してみます。

$ ain -b basic_template.ain

テンプレートを生成。中身を見てみます。

$ cat basic_template.ain
[Host]
http://localhost:${PORT}

[Headers]
Content-Type: application/json

# [Method]
# POST

# [Body]
# {
#    "some": "json"
# }

[Config]
Timeout=3

[Backend]
curl
# wget

[BackendOptions]
-sS # Makes curl suppress its progress bar in a pipe
# -q # Makes wget suppress its progress output

# Short help:
# Comments start with hash-sign (#) and are ignored.
# ${VARIABLES} are replaced with the .env-file or environment variable value
# $(executables.sh) are replaced with the output of that executable

うーむ... なんか横に長いですね...。toml 形式の設定方法は単発では見やすいと思いますが、複数 API を定義するのには冗長になりそうだなと言う印象を受けました。 これ複数定義して GitHub 管理してもどれを使うかわからなくなりそうですね...。

利用用途は Load Balancer ですが drill のほうが簡易的で好きでした...。Header の Content-Type とかも Postman であればよしなに判断して付与してくれますし...。

認証系統は以下のようにコマンドを利用できるのである程度やりやすそうですが、設定のわかりやすさとしては、自分の中では Drill の勝ちですね。

[Headers]
Authorization: Bearer $(bash -c "./get-login.sh | jq -r '.token'")

というか、これぐらいであれば Makefile に curl を列挙して実行したほうがマシな気がします。無駄なファイルが増えませんし。

それでは今回はこのへんで。