Kubernetes でちょっとした作業のために Pod を立てる

概要

Kubernetes で運用しているシステムで、ちょっとした作業を行う Pod が欲しくなった。例えば、通信経路が確立できているか確認するため curl を実行するとか。

そういうときは Deployment を用意せず、kubectl run を駆使して一時的に Pod を立てて確認する。

kubectl run Pod名 --restart=Never --image=イメージ --namespace=名前空間  --rm -it -- /bin/sh

これで ssh して作業を行い、離脱したら Pod が消えてくれる。

参考

Goのfuzzing testを調べる

概要

Go1.18からfuzzing testができるようになった。
fuzzing testの概要と導入して嬉しいかの情報をまとめる。

What’s fuzzing test?

ファジングは、プログラムへの入力を継続的に操作して、コードが影響を受けやすいパニック、バグ、データ競合などの問題を見つける自動テストの一種です。これらのセミランダムデータミューテーションは、既存の単体テストが見逃す可能性のある新しいコードカバレッジを発見し、そうでなければ見過ごされてしまうエッジケースのバグを発見することができます。このタイプのテストは、インテリジェントに少数のミューテーションではなく、より多くのミューテーションを迅速に実行できる場合に最適に機能します。
FYI https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md

テストケースはあくまでも人間が書くので、書いた人が想定できてないケースはカバーできない。それをカバーする手段の一つがfuzzing testらしい。

例えば下記のチュートリアルではfuzzing testを実施することで下記のバグに気づくことができる。

https://go.dev/doc/tutorial/fuzz

  • マルチバイト文字の対応ができていない
  • 無効なUTF-8が渡されるケースを想定できていない

ランダムで値を渡すのでこういったケースを洗い出すことができる。

導入

Go1.18ではパッケージのインストール等は不要で利用できる。

  1. テストケースの頭にFuzzをつける
  2. 実行時に go test -fuzz=メソッド名 として実行する
    実行時に -fuzztime 秒 を付けないと失敗するまで無限に実行する
FuzzFooというメソッドがある場合
go test -fuzz=FuzzFoo

etc.) 10秒動かして問題なければ止める
go test -fuzz=FuzzFoo -fuzztime 10s

所感

  • ランダムに値を渡していくため、テストコードにおける 期待値 は渡せない
  • 向いていそうなところはどこか

参考資料

手動作成したDatadogのアラートをTerraformで構成管理する

概要

Infrastructureは構成管理することで、コードのプラクティスを取り込む方法が進んでいる(IaC)。モニタリングツールも同様の考えがあるらしい。

FYI Monitoring as Code: What It Is and Why You Need It – The New Stack

個人としてはプルリクエストで「なぜこの変更を行うのか」が明確になるやり方を好んでいるため、Monitoring as Codeを意識し、アラートを構成管理してみる。

インポートして取り込み

Datadog Providerに例が記載してあるので、それから取り込むもよし。
今回はUI上で作成したものを取り込んでみる。

空の設定を用意

取り込むためには取り込み先が必要で、空の設定を用意する。

resource "datadog_monitor" "hoge" {
}

インポート

記載した環境変数をセット。 セットしたら対象URLの値をコピーし、ターミナルでコマンドを実行する。

terraform import datadog_monitor.hoge URL末尾の数字

ステートからインポートした情報を確認する

下記コマンドを実行することで、インポート内容を確認することができる。

terraform state show 対象
etc.) terraform state show datadog_monitor.hoge

空の設定の中身を書く

インポートすることによって状態管理の中には、UIで作成したアラート内容が取り込まれる。 しかし、これだと実態のファイルは空のままで、apply を実行すると画面の設定が飛んでしまう。

そこで状態管理を元に、コードの取り込みを行う。 取得したファイルはJSON形式で書かれているので、その中身をHCLに書き写していった。

キニナル

下記に2つはどちらかしてか設定できないというエラーが出る。手動で作成すると設定できている気がするので気になる。

new_group_delay
new_host_delay

実行

取り込みが終わったらapplyを実行する。 これで完全に取り込みが終わった。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

概要

https://images-na.ssl-images-amazon.com/images/I/51Bi27X9J3L._SX351_BO1,204,203,200_.jpg

目的

ヘビーリスナーとして聞いているYokohama North AMにて、アジャイル心理的安全性が分かりやすいと紹介されていたため。

目標

アジャイル心理的安全性を掴む。

総評

少ないページ数だが内容は濃厚。各章において、いくつかの企業の実例を交えることで、内容が理解しやすくなっているし「なるほどねー。」と思えた。
SpotifyAmazonは勿論、コカコーラといったIT以外の分野の実例も登場している。

アジャイルには思考と行動の両方が伴うというのは、とても自分に刺さる内容だった。ページ数が少ないが要点は抑えているので、チーム内で読み合わせしても面白そう。

ピックアップ

1章 「アジャイル」とはなにか?なぜ重要なのか?

アジャイルについて導入の章。

「ムーブメントとしてのアジャイル」という表現が興味深い。 ちょうど最近「スクラムにはマインドセットが必要ではないか?」と議論になった。しかし、この章では「マインドと手法は容赦なく繋がっていて切り離せない」と書いてあり、手厳しい内容となっている。

「うまくいかないのはマインド or 手法のせいだ」という話ではないということは、忘れないでおきたい。

2章 自分たちの北極星を探す

アジャイルラクティスに沿うだけでは不十分という話。

例えば、「今よりもっと早く価値を届ける」ためにアジャイルを導入する場合、「なぜ今遅いか」から目を背けることはできない。 そこから目を背け、アジャイルラクティスを取り入れても、名前を変えて今までのことをやっているだけ。

と書いてあり、非常に耳が痛い。

本書で紹介されているように、下記の質問に答えて、自分たちの北極星を探していくことが大事なんだろう。

  • チームや組織が将来なりたい状態は?
  • チームや組織の現在の状態は?
  • 将来なりたい状態になれないと思う理由はなにか?

3章 顧客から始めるのがアジャイル

1番重要で1番難しいのは、顧客を中心に考えることという話。

「組織があることで問題を難しくしているよ」という話が丁寧に紹介されていて良い(組織重力の第1法則というらしい)。 また速度もアイディアも顧客視点で見るべきという話は非常に納得できる。

弊チームも多分に漏れず、スプリントレビューなどでプロセスの話題が多く出ているため、 本章で紹介されているような「顧客中心」の質問を増やしていきたいと思った。

4章 早期から頻繁にコラボレーションするのがアジャイル

題名の通り、チームのコラボレーションについてがメインで、心理的安全性に通じる話もある。

距離が近いメンバーと働くことに意識が向きがち(組織重力の第2法則というらしい)な考えがあり、 アジャイルはそれを逆に利用する設計になっているという点は面白かった。

Spotifyの例を出しながら、報告と批評の文化から協調の文化へ行くことを説明している。

この章はチーム文化について色々と書いてあり、自分たちの現状に近しいものが数多くあった。

1つ取り上げるなら非同期コミュニケーションが多いところで、常々個人的にも課題と感じていた。 現状コロナ禍で物理的に同じ部屋にいることは難しいが、チャットツールなどを用いて擬似的に再現していきたいと感じた。

コカコーラのコラボレーションの例は、アジャイルがITかどうかに関係なく適用できる例として参考になった。

P.S.

評価がサイロの中や個人レベルで行われるなら、個人はその評価を求めるようになります。
私達はチームワークを評価しなければいけないし、チームワークを受け入れなければいけないのです。

Spotifyの例に出てきた上記は、確かにそうだなと思った。 評価が個人の功績に対してのみ行われる場合、チームワークを意識するのは難しい。

5章 不確実性を計画するのがアジャイル

「不確実性を計画する」というやや矛盾を含んだようなタイトル。 しかし、読み進めていくとこの言葉の意味するところがわかってくる。

「何が成功するか」の確証はないので、仮設を立てて実験をし、ふりかえることで確かめていくしかないという話。

ふりかえりで効果的なプラクティスも載っており参考になる。

余談

「スプリントを固定することによって逆に柔軟性が高くなる」というのは、言われるとそうだと思った。

自分たちは1週間スプリントとしているが、毎スプリント後にプロダクトゴールを考え、次のアプローチを検討している。
そうすることで、より大胆な打ち手を実施できているので、これは改めて効果を実感した。

6章 3つの原則に従い、速くて柔軟で顧客第一なのがアジャイル

今までの話をまとめる章。 顧客第一・コラボレーション・不確実性の許容を組み合わせることで、より効果を得られるということが書いてある。

この章で興味深いと思ったのは、ボトムアップアジャイルを取り入れる方法が書いてあること。 トップダウンで進めるより難しいのだが、どういった手引で自分の上長にアジャイルを進めるかが書いてあり、参考になった。

メンバーはリーダーの発言ではなく行動を真似る

ここは結構気をつけないと行けないと思った。所謂「背中を見せる」というか「背中を見ている」というところだろう。 自分がリーダーかどうかはさておき、発言ではなく背中を見られていることは意識したい。

AWS Lambda + PHPを技術調査した

概要

qiita.com

数年前に軽く記事にしていたが、改めて技術調査をしたのでまとめてみる。

TL;DR

  • いろいろなユースケースで使えるくらい充実してきた
  • 思ったよりもすんなり動く
  • ワーカーとか動かすと嬉しそう

実行環境

AWS公式でPHPの実行環境は提供されておらず、動かす場合は下記2つの選択肢があると思われる。

  • PHPのコンテナを動かす
  • brefを利用する

コンテナで動かすのはちょっと難儀したため、今回もbrefを利用していく。

bref

AWS LambdaでPHPを動かすライブラリで、Serverless Frameworkを利用して構成管理できる。

ここ数年でメジャーバージョンになったり、AWSの記事で紹介されるようになった。

aws.amazon.com

公式サイトではAmazon API Gatewayユースケースは勿論、Amazon SQSやAmazon S3のケースも紹介されている。

Typed PHP Lambda handlers

alu.jp

フルスタックフレームワークの例も記載されており、LaravelやSymfonyを動かすことも容易にみえる。

フルスタックフレームワークの例も記載されており、LaravelやSymfonyを動かすことも容易にみえる。

Serverless Laravel applications - Bref

MemcachedImageMagickといったライブラリを動かすカスタムLayerも別リポジトリで用意されている。下記を見る限り、一通りのライブラリが用意されており、本体と合わさって、かなり実用的なライブラリと思った。

https://github.com/brefphp/extra-php-extensions

環境構築

brefを動かすためには、下記の2つが必要

  • PHP
    • Composerを利用するため
  • Node.js
    • Serverless Frameworkを利用するため

自分はよくDockerで環境構築するため、下記のように用意した。

FROM php:8.0-fpm

RUN pecl install xdebug && \
    docker-php-ext-enable xdebug && \
    apt-get update && apt-get install -y zlib1g-dev git zip && \
    docker-php-ext-install pdo_mysql opcache && \
    php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && \
    php composer-setup.php && \
    php -r "unlink('composer-setup.php');" && \
    mv composer.phar /usr/local/bin/composer

# serverless
RUN apt-get install -y nodejs npm && \
    npm install npm@latest -g && \
    npm install -g serverless

あとは公式サイト通りに初期設定を行っていけばOK

serverless config credentials --provider aws --key <key> --secret <secret>
composer require bref/bref
vendor/bin/bref init
serverless deploy

フルスタックフレームワークを乗せる例は、PHPerKaigi2021でちゃちいさんが紹介しているので割愛。

ロギング

Amazon API Gateway + AWS LambdaでAPIを作った際、ログをまとめて調査したい欲求があった。

下記はECSの例だが、ちょっと変更すればAmazon API Gateway + AWS Lambdaの構成でも対応可能だった。

qiita.com

こちらに記載があるように、 LAMBDA_INVOCATION_CONTEXT を参照すれば良いので、フォーマッターを下記のようにすることでグルーピングできた。

/**
 * {@inheritdoc}
 */
public function format(array $record)
{
    $output = [];
    $context = json_decode($_SERVER['LAMBDA_INVOCATION_CONTEXT'], associative: true);
    $output['RequestId'] = $context['awsRequestId'];
    $output['message'] = $record['message'];
    foreach ($record['context'] as $var => $val) {
        $output[$var] = $val;
    }

    return json_encode($output, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) . PHP_EOL;
}

所感

意外とすんなり動く

下記構成のアプリケーションを作ってみたが、どれも想定より簡単に動作させることができた。

慣れない言語で四苦八苦した経験があったので、PHPでやってみるのはありなんじゃないかと思えた。

環境構築でPHPとNode.jsの環境が必要な都合上、デプロイパイプラインがServerless Framework単品で使うより手間だが、Workflowを組むことで解決可能だった。

※CircleCIをよく使うので、CircleCIでWorkflowを組んだ。

Serverless Frameworkの資産を使える

brefの公式サイトでも紹介されているが、Serverless Frameworkを使っているので、リソースの管理等もできる。

関係するリソースを一括で管理できるので、ライフサイクル単位で管理できるのは魅力。

最後に

AWS Lambdaのハードリミットがミスマッチで、プロダクション環境で使うことはなかった。だが結構色々調べられたので、知見としてここに残しておく。
あと「いつか使ってやるぞ」という野心も残しておく

参考資料

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意

概要

https://images-na.ssl-images-amazon.com/images/I/51vxSE6gGHL._SX351_BO1,204,203,200_.jpg

目的

スクラムマスターと開発者を兼任していたが、スクラムマスターっぽいことができなかった。スクラムマスターとしてどう振る舞うかきになったので読んでみる。

目標

スクラムマスターとしての振る舞いで使えるものを得る。

総評

今の自分が理解するのは難しい内容だった。何度か読み返すことによって、自分の身に染み込ませていく本なのかなと思う。

ピックアップ

1章 スクラムマスターの役割と責任

スクラムマスターは既存の枠組み(プロジェクトマネジャーや開発者)と違うため、必要性がピンと来ないかもという話からスタート。

スクラムにおいてチームがフォーカスする範囲は

「スプリントバックログとプロダクトバックログをDONEの定義を満たして完了にするのは、チームとして(1つの生き物として)どうしたらよいか?」

になるというところは学びになった。

また兼任のメリット・デメリットが記載されており、基本的には兼任すべきではないと書かれている。 自分自身、開発者として兼任したことで、スクラムマスターとして振る舞えなかったと感じており、納得に内容だった。

2章 心理状態モデル

スクラムマスターのアプローチが記載されている。 順を追っていくことで、メンバーの気持ちを育むことが記載されている。

この章を読んで、「スクラムマスターを辞めた今の方がスクラムマスターっぽい」と言われる片鱗がわかった。

スクラムマスター中はスクラムイベントのファシリテーションをやっており、会議の中心にいた。 辞任したことで会議の中心から離れ、ファシリテーションコーチングが結果としてできるようになった、

全く余談だが、「スクラムマスターやるならせっかちな性格を直せ」と暗に言われている気がするw

3章 #スクラムマスター道

スクラムマスターとはどうあるべきか」が書かれている。

スクラムマスターのチームを作る」は考えたことがあったが実践しなかった。 自社には他にもスクラムマスターがいるし、スクラムマスター同士で連携して組織課題に向かっていくべきだったなと感じた。

4章 メタスキルとコンピタンス

スクラムマスターが持つべきメタスキルの話。

すごく難しくて一回だと理解できない…。 ただ、アジャイルへの理解度が高く、自己組織化された組織での経験が不可欠というところは同意。

組織デザインでも言えることだけど、理想の組織で働いたことがあることは大事なんだよな。

5章 チームを構築する

チームを構築するために「現状を把握すること」・「スクラムマスターはどう振る舞うか」といったことが書かれている。

タックマンの集団発達モデルで、自分たちがどの段階にいるのかという話が記載されている。

  1. フォーミング
  2. ストーミング
  3. ノーミング
  4. パフォーミング

自分たちは去年からメンバーが入れ替わったのでフォーミングかな。 全体的に抽象的な内容が多く、理解するのに時間がかかる…。

6章 変化を実装する

前の章と同様に難しい…。 変化をしていくためにはどうするか、ということが書かれている。

7章 スクラムマスターの道具箱

「守離破」や「コーチング」、「なぜなぜ5回」といった実践的なプラクティスと取り入れ方が書かれている。

「なぜなぜ5回」は実際にやってみたことがあるが、相手の話を聞いて適切にブレイク・ダウンする必要があり難しかった。 カンバンの話に触れていて気づいたが、ダッシュボードを作っているのに、そこに触れた会話ができていないな。

8章 私は信じています

「誰もが偉大なスクラムマスターになることを信じています」というエモいスタート。 様々な悩みにアジャイルコーチが助けになってくれるという話。

Laravel Sanctumを試してみる

概要

ISRを利用したサイト開発を行うにあたり、認証周りの調査を行っていた。
その中でLaravel Sanctumの存在を知ったので遊んでみる。

所感

古き良きCookieを使ったセッションの仕組みを、トークンで再現した感。

試してみる

Laravel Sanctumとは

Laravel Sanctum(サンクタム、聖所)は、SPA(シングルページアプリケーション)、モバイルアプリケーション、およびシンプルなトークンベースのAPIに軽い認証システムを提供します。Sanctumを使用すればアプリケーションの各ユーザーは、自分のアカウントに対して複数のAPIトークンを生成できます。これらのトークンには、そのトークンが実行できるアクションを指定するアビリティ/スコープが付与されることもあります。 https://readouble.com/laravel/8.x/ja/sanctum.html

SPA向けの認証システムらしい。
導入に関しては引用の記事を見ればできるので、ここでは割愛。

独自の設定に取り込む

記事では標準のUserModelに対する組み込みを記載されているが、標準以外も動くか気になった。 その場合も、HasApiTokensのTraitで差し込むことで実装できる。

<?php
declare(strict_types=1);
 
namespace App\Models;
 
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;
 
class Hoge extends Model
{
    use HasApiTokens, HasFactory, Notifiable;

独自のログイン情報でも下記のようにトークンが返ってくる。

$ curl -X POST http://localhost:8088/api/v1/tokens/create  -H  "accept: application/json" -H  "Content-Type: application/json" -d "{\"id\":\"id\", \"pass\":\"パス\"}"
{"token":"1|LaMzf5HxLkrKDS0sLfCdWZwhf8QNNem77qa03l29"}

発行のコードはこんな感じで、テーブルにデータを作る仕組みになっている。

https://github.com/laravel/sanctum/blob/dd84a9141012c5509922df0c72866110f45026cb/src/HasApiTokens.php#L44

public function createToken(string $name, array $abilities = ['*'])
{
    $token = $this->tokens()->create([
        'name' => $name,
        'token' => hash('sha256', $plainTextToken = Str::random(40)),
        'abilities' => $abilities,
    ]);
 
    return new NewAccessToken($token, $token->getKey().'|'.$plainTextToken);
}

古き良きCookieを使ったセッションの仕組みを、トークンで再現した感がある。 同じパラメータで渡すと、新しいトークンが返ってくるところも似ている。