tech.guitarrapc.cóm

Technical updates

git pull をサブディレクトリでまとめて実行するスクリプト

リポジトリが10個~ (あるいは100個でも) あるときに、そのすべてのローカルGit を更新したいことがまれにあります。 Windows、macOS、Linux 各種OSでサブディレクトリにあるローカルGit で git pull を一気に行う必要があったのでスクリプトをおいておきます。

tl;dr;

  • バッチファイル、PowerShellスクリプト、シェルスクリプトで同様にパラメーターを受け取り、動作するスクリプトが用意できる
  • OS に応じて手元にあると便利。めったに使わないけど

gist においておきます。

https://gist.github.com/guitarrapc/2623623a0e1bc7fe86b5cf56e0c70d88

やりたいこと

現在のフォルダ以下に次のように複数の Gitリポジトリがクローンされた状態で、まとめてすべて git pull したいことがあります。

# たくさんフォルダがあるとして....
$ tree -L 1
.
├── Bar
├── Foo
├── Piyo
├── Hoge
├── ...
└── NanikaSugoiRepo

コミットしていない変更の存在するリポジトリもあり得るため、手でやるのは時間がいくらあっても足りません。 とりあえずリポジトリを今の ref に対して最新に更新したい。これを目指します。

# ↓を並べるのはやりたくない
cd ./Bar && git pull && cd - # stash や git reset --hard をしたいかもしれない
cd ./Foo && git pull && cd -
...

スクリプト

ワンライナーで書くのもいいですが各種OS でサクッとやりたいので、Windowsバッチファイル、PowerShellスクリプト、シェルスクリプトそれぞれで同じような引数を受け取って、同じように動作するようスクリプトを書きます。

やりたくなることを見越して、パラメーターで git stashgit reset --hard もやるか選べるようにしましょう。git stash はデフォルト有効でパラメーターで無効を指定 (--no-stash)、git reset --hard はデフォルト無効でパラメーターで有効を指定できる (--force)、とします。

こんな感じの手触りをイメージして書きます。

# Windows バッチファイル
git-pull.bat --force --no-stash

# PowerShell スクリプト
./git-pull.ps1 -Force --NoStash

# シェルスクリプト
bash ./git-pull.sh --force --no-stash

さっそく見てみましょう。

Windowsバッチファイル

git-pull.bat

:: Script to run `git pull` inside all subdirectories which are git repositories.
:: usage 1: keep local changes, then up to date.
::   > git-pull.bat
:: usage 2: abort local changes, reset if possible, then up to date.
::   > git-pull.bat --force --no-stash
:: usage 3: try keep local changes, reset if possible, then up to date.
::   > git-pull.bat --force

@echo off

setlocal
:parse
    IF "%~1"=="" GOTO endparse
    IF "%~1"=="--force" set _FORCE=true
    IF "%~1"=="--no-stash" set _NO_STASH=true
    SHIFT
    GOTO parse
:endparse

for /f "tokens=* delims=" %%i in ('dir /ad /b "."') do (
    echo --- Working on %cd%\%%i
    pushd "%cd%\%%i"
        if NOT EXIST ".git\" (
            echo   x: \"%cd%\%%i\" is not a git repository, continue next directory.
        ) else (
            if not "%_NO_STASH%"=="true" ( git stash --quiet )
            if "%_FORCE%"=="true" ( git reset --hard )
            git pull
            if not "%_NO_STASH%"=="true" ( git stash apply --quiet )
        )
    popd
)

endlocal

PowerShellスクリプト

git-pull.ps1

# Script to run `git pull` inside all subdirectories which are git repositories.
# usage 1: keep local changes, then up to date.
#   PS> ./git-pull.ps1
# usage 2: abort local changes, reset if possible, then up to date.
#   PS> ./git-pull.ps1 -Force -NoStash
# usage 3: try keep local changes, reset if possible, then up to date.
#   PS> ./git-pull.ps1 -Force

param(
    [Switch]$Force,
    [Switch]$NoStash
)

foreach ($dir in Get-ChildItem -Directory) {
    try {
        pushd $dir.FullName
            echo "--- Working on ""$($dir.FullName)"""

            if ((Get-ChildItem -Force -Directory).Name -notcontains ".git") {
                echo "  x: ""$($dir.FullName)"" is not a git repository, continue next directory."
                continue
            }

            if (!$NoStash) { git stash --quiet }
            if ($Force) { git reset --hard }
            git pull
            if (!$NoStash) { git stash apply --quiet }
    } finally {
        popd
    }
}

シェルスクリプト

git-pull.sh

#!/bin/bash
set -o pipefail

# Script to run `git pull` inside all subdirectories which are git repositories.
# usage 1: keep local changes, then up to date.
#   $ bash ./git-pull.sh
# usage 2: abort local changes, reset if possible, then up to date.
#   $ bash ./git-pull.sh --force --no-stash
# usage 3: try keep local changes, reset if possible, then up to date.
#   $ bash ./git-pull.sh --force

while [ $# -gt 0 ]; do
    case $1 in
        --force) _FORCE=true; shift 1; ;;
        --no-stash) _NO_STASH=true; shift 1; ;;
        *) shift ;;
    esac
done

## find is not a good way to control. Additionally, this include CURRENT directory and it is unexpected.
# find . -maxdepth 1 -type d -exec bash -c 'echo "Working on $(realpath $1)"; git reset --force; git pull' shell {} \;

for dir in ./*/; do
    echo "--- Working on \"$(realpath "${dir}")\""
    pushd "$(realpath "${dir}")" > /dev/null
        if [[ ! -d ".git" ]]; then
            echo "  x: \"$(realpath "${dir}")\" is not a git repository, continue next directory."
            popd > /dev/null
            continue
        fi
        if [[ "${_NO_STASH:=false}" != "true" ]]; then git stash --quiet; fi
        if [[ "${_FORCE:=false}" == "true" ]]; then git reset --hard; fi
        git pull
        if [[ "${_NO_STASH:=false}" != "true" ]]; then git stash apply --quiet; fi
    popd > /dev/null
done

書くときのメモ

どのスクリプトも、フォルダが git フォルダじゃない場合は次に行きます。 また、エラーが出ても止まらないようにしています。もし止めたい場合は、set -e (シェルスクリプト) や $ErrorActionPreference = "Stop" (PowerShell)、あるいは%errorlevel% チェック (Windowsバッチファイル) でできますが、数が多いとエラー無視して進めたくなるんですよね。

Windowsバッチファイル

パラメーター引数を受け取るのは Window バッチファイルでパラメーター入力を受け付ける で紹介したやり方です。 サブディレクトリで何かコマンドを実行する方法として for を採用しました。ただ、このやり方だと 実行中に Ctrl+C でキャンセルしようとしても Ctl+C連打で止まらず、キャンセルプロンプトで Y を選ばないといません。これは結構不便です。1

PowerShellスクリプト

try/finally を使うことで、実行中に Ctl+C でキャンセルしてもフォルダ移動しっぱなしが防げます、便利。 パラメーター受け取りから制御処理まで、全体的に小細工がなく、素直に書けばそのまま動くのは PowerShell えらい。 あとは、PowerShell 7がOSのデフォルトに入ればいいのですが、なかなか先は見えません。

シェルスクリプト

パラメーター入力はいくつかやりかた2 がありますが、私はもっぱら while + case + shift がパラメーターごとに一行で収まり、また任意のパラメーター名にできるのが好みです。 フォルダ一覧を取得するなら定番は find ですが、-exec でコマンド並べるのは厳しいので雑に glob としています。 シェルスクリプト定番なことだけ使って書いていますが、もう少しいい書き方ないですかね?

参考


  1. echo でクォートが使えないのは地味に不便です。
  2. よく見かけるのは while + case + shiftgetoptsfor arg in $@ があります。

Window バッチファイルでパラメーター入力を受け付ける

Windows バッチファイル (.bat や .cmd) を実行するときに、パラメーターを指定して引数を渡したいと思ったのでおいておきます。 これまで面倒で考えてなかったのですが、便利。

tl;dr;

  • シェルスクリプトと同じように引数を組めるので、Windowsバッチだからパラメーター入力できないとあきらめる必要はありません。(過去の自分へ)
  • 複数のパラメーターをユーザーが選択して指定できるようにしたい、こういったときにパラメーター入力は便利です
  • 引数解析も単純なので定番として利用できます

gist においておきます。

https://gist.github.com/guitarrapc/a6c3fc433e7f98ef74f6cb45f4f2a952

どういうことをしたいのか

イメージしやすいように シェルスクリプト (Bash) や PowerShell で考えてみましょう。

シェルスクリプトを利用するときに、パラメーター名 値 で引数を渡すことがよくあります。

# X: 引数の順序に依存する
./foo.sh true true 1

# O: パラメーター名で指定する
./foo.sh --foo --bar --param 1

PowerShell でスクリプトを書いた時も、Param() を使って標準的に行われるパターンです。

# O: パラメーター名で指定する
./foo.ps1 -Foo -Bar -Param 1

Windows バッチでもシェルスクリプトのように、パラメーターで引数を指定したいですね。

foo.bat --foo --bar --param 1

パラメーターで引数を渡すメリットは、引数が順序に縛られずパラメーター名さえわかっていれば任意の順序で指定できることです。スクリプトを利用するときに圧倒的に楽です。

Windows バッチファイルでパラメーターを指定して引数を渡す

次のようなシェルスクリプトがあったとして..。

#!/bin/bash
set -euo pipefail

while [ $# -gt 0 ]; do
    case $1 in
        --foo) _FOO=true; shift 1; ;;
        --bar) _BAR=true; shift 1; ;;
        --param) _PARAM=$2; shift 2; ;;
        --param2) _PARAM2=$2; shift 2; ;;
        *) shift ;;
    esac
done

if [[ "${_FOO:=""}" == "true" ]]; then echo "--foo detected"; fi
if [[ "${_BAR=""}" == "true" ]]; then echo "--bar detected"; fi
if [[ "${_PARAM:=""}" != "" ]]; then echo "--param ${_PARAM}"; fi
if [[ "${_PARAM2:=""}" != "" ]]; then echo "--param2 ${_PARAM2}"; fi

これに相当するWindows バッチファイルでの書き方の例を示します。

@echo off

setlocal
:parse
    if "%~1"=="" GOTO endparse
    if "%~1"=="--foo" (set _FOO=true)
    if "%~1"=="--bar" (set _BAR=true)
    if "%~1"=="--param" (set _PARAM=%~2)
    if "%~1"=="--param2" (set _PARAM2=%~2)
    shift
    GOTO parse
:endparse

if "%_FOO%"=="true" (echo --foo detected)
if "%_BAR%"=="true" (echo --bar detected)
if not "%_PARAM%"=="" (echo --param %_PARAM%)
if not "%_PARAM2%"=="" (echo --param2 %_PARAM2%)

endlocal

想定通り、任意のパラメーターを指定できるのがわかります。

> parse.bat

> parse.bat --foo --bar
--foo detected
--bar detected

> parse.bat --foo --bar --param 1
--foo detected
--bar detected
--param 1

> parse.bat --foo --bar --param2 5
--foo detected
--bar detected
--param2 5

> parse.bat --foo --bar --param2 5 --param 100
--foo detected
--bar detected
--param 100
--param2 5

> parse.bat --foo --bar --param 1 --param2 5
--foo detected
--bar detected
--param 1
--param2 5

簡単な説明

:parse から :endparse が引数の指定です。

Windows バッチに while 構文がないので、 goto で代用しています。引数解析は、shift で引数をずらしながら、空になるまでgoto でループするだけです。 setlocalendlocal でスクリプト内の変数を外部出さないようにすると、実行シェルに影響与えないのでお行儀がいいです。

まとめ

Windows バッチファイルも便利。

Windows 11 Professional マシンを構成する

Windows マシンを更新したので、構成メモです。記事を寝かして1か月経っていますが安定しています。

tl;dr;

2年前に組んだ Ryzen 5900X もいいマシンだったのですが、次のデスクトップCPU が期待できそうなのは2年後になりそうです。今を逃すと長いので新しいPCに切り替えました。どこかでグラボを替えたいものの、今後いいタイミングは来ない気もします。4000シリーズはない。

今回感じた課題は次の通り。

  • (完了) Windows のツールセットアップは local-provisionerSccopPlaybook にお任せ
  • (課題) インストーラーを使う、Visual Studio、Docker Desktop、Logicool Options+、Realforce Driver が自動化できていない。 -> winget 一択?
  • (課題) Windows のユーザー名を指定したいので、Microsoft Account での初期ユーザー作成を避けたいが Wi-Fi だとちょっと悩ましい。 -> あきらめ
  • (課題) Windows の初期設定も macOS の defaults のように構成していきたいが、定義はYAMLに書いたり冪等性を担保したい。が、Ansible は使いたくない。 -> ツール書くしかなさそう

Windows マシンの構成

前準備

  • UEFI: Hyper-V を使うため、 CPU > Advanced で Intel VTAMD SVM を有効にします
  • OS: Windows 11 Professional をクリーンインストールします

Windows 10 からのアップグレードでは発生しないドライバー認識問題がおこるので、Windows 11 でクリーンインストールは大事。

流れ

私の環境の場合、次のように行っています。

  1. Wi-Fi に接続
  2. (Windows) Windows 初期サインアップは Microsoft Account で行う。(LAN/Wi-Fi を切るのは面倒なのであきらめている)
  3. (Windows) ローカルアカウント (Administrators Group) を作成する
  4. (Windows) Microsoft アカウントとの Windows ユーザーをサインアウト、ローカルアカウントでWindows サインイン
  5. (Windows) English の言語パックを追加、IME を日本語に設定1 する
  6. (Windows) Windows 初期サインアップで作った Microsoft アカウントの Windows ユーザーを削除
  7. (Windows) Windows の ローカルアカウント を Microsoft アカウントと紐づけ
  8. (Windows) Windows を Developer mode (開発者モード)で設定2 する
  9. (Windows) Windows Update を1回あてる
  10. (ツール) Scoop をインストール
  11. (ツール) git を scoop でインストール 3 する
  12. (ツール) Windowsアプリを guitarrapc/local-provisioner で構成
  13. (Windows) ネットワークプロファイルを Private に設定4 する
  14. (Windows) Windows に Yubikey Bio を設定
  15. (ツール) Chome にサインアップ。デフォルトブラウザを Edge から Chrome に変更
  16. (ツール) Chrome 拡張の uBlacklist のサブスクリプションを構成
  17. (Windows) Night lightを有効化。 Stlength 50%、時間は 21:00 til 7:00
  18. (Windows) Display scale を 100% に設定、縦モニターは portlait (flipped) に設定
  19. (ツール) VSCode Sync の有効化
  20. (ツール) Visual Studio をインストール、構成5する
  21. (ツール) WSL & WSL2 をインストール 、構成6する
  22. (Windows) LongPath の有効化7 する
  23. (ツール) Docker desktop のインストールと設定8 する
  24. (Windows) Bluetooth機器のペアリング、 Dynamic Lock の有効化9 をする
  25. (Windows) Startup apps の無効化10 を TaskManagerで行う
  26. (Windows) そのほかドライバーの構成11 を行う

パーツのメモ

メモリのクロック制約

メモリを 128GB (DDR-4800) で組んでいます。しかし、Ryzen 7000シリーズはメモリ4チャンネル (4枚差し)をするとクロックが DDR5-3200 まで落ちるのでそれは許容しています。 64GB だと足りないので仕方ない。

セミファンレス電源

Fractal Design ION+2 Platinum を採用しました。セミファンレスにできるのですが、実際電源周りは静かかつ、普段はファン起動していないのでいいかんじでですね。 今のところ違和感なく、モジュラー + ケーブルがやわらかいので大変良いです。

Samsung 990 PRO

採用を見送りました。Ryzen 7000 シリーズだと ランダムの Write がおかしいので避けました。

【やじうまミニレビュー】Samsungの新SSD「990 PRO」自腹購入。Ryzenだとさらに速い!涼しい! - PC Watch

インテルなら問題ないようなのでいいのではないでしょうか。

「Samsung SSD 990 PRO 1TB」をレビュー。性能も電力効率もトップクラス! : 自作とゲームと趣味の日々

代わりに WD_BLACK SN850X を用いています。個人的には、ここ2年で WD_BLACK がバランスよく早いのでいい感じです。

「WD_BLACK SN850X NVMe SSD 1TB / 2TB」をレビュー。SN850よりも高速なのに低消費電力! : 自作とゲームと趣味の日々

CM01 はWindows 11 クリーンインストールでは Windows Hello顔認証で動作しない

マウスの CM01 は、Windows 10 で Windows Hello 顔認証カメラとして利用できました。また、Windows 10 からアップグレードした Windows 11 でも Windows Hello 顔認証カメラとして機能します。しかし、Windows 11 をクリーンインストールした環境では同ドライバーが機能しません。CM01 は Windows 11 で機能しないと公式に表明されているので、そんなものと割り切りましょう。代わりに後継の CM02 を利用しています。

ところでマウスさん、商品の販売終了でページを閉じるのは悲しいです。ドライバーのリンクにしておきますね。


  1. 日本語キーボードを使う場合、IME は日本語にしておくと Windows の表示言語にかかわらずキーボードで困らない。
  2. 開発者モードは、mklink で管理者権限が不要になり、PowerShell のRemote Signed も有効にできる便利設定。
  3. scoop install git
  4. local-provisioner の envs/windows/etc にスクリプトがある。
  5. 2023/Apr 時点では Visual Studio 2022。
  6. local-provisioner の envs/windows/etc にスクリプトがある。
  7. local-provisioner の envs/windows/etc にスクリプトがある。
  8. Hyper-V バックエンド、localhost:2375 の有効化、Kubernetes の有効化。
  9. ヘッドホン、ゲームパッド、iPhone
  10. Microsoft Teams, OneDrive, Radeon Software Startup Task
  11. CM02, Realforce R3, Logcool Options+

EKS Fargate に DaemonSet を配置しない Node Affinity

Kubernetes 小ネタです。

EKS Fargate は便利なのですが、Fargate = Pod なので DaemonSet は配置できません。ということで、「DaemonSet を Fargate には配置しない」を Node Affinity で実現しましょう。

Node affinity を用いた Fargate にスケジュールしない指定

単純な NodeGroup ベースの配置なら nodeSelector でいいのですが、Fargate かどうかとなるとNode affinityのほうが柔軟に管理しやすいのでこれを用ています。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: foo-daemonset
spec:
  selector:
    matchLabels:
      k8s-app: foo-daemonset
  template:
    metadata:
      labels:
        k8s-app: foo-daemonset
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: eks.amazonaws.com/compute-type
                    operator: NotIn
                    values:
                      - fargate
      containers:
        - name: foo
          image: foo

設定に関しては Assigning Pods to Nodes を参照するのが王道です。大体ここに書いてあります。

Node affinity には2つの指定方法があります。 IgnoredDuringExecution は Nodeのラベルがスケジュール後に代わっても Pod をそこで動作させ続ける意味です。

  • requiredDuringSchedulingIgnoredDuringExecution: 指定した条件のNodeに配置できないならスケジュールはしない。nodeSelector と同じような使い方です
  • preferredDuringSchedulingIgnoredDuringExecution: 指定した条件のNode配置できるなら配置したいけどだめなら他のNodeにスケジュールして良し

幸い EKS Fargate は Selector に eks.amazonaws.com/compute-type: fargate を持っているのでこれで指定できますね。

どんな時に使う?

DaemonSet なので、管理用に入れているエージェント系Podが多いことでしょう。私の場合、Datadog Agent や NodeLocal DNSCache、FluentBit で利用すること多いです。

Helm で nodeAffinity を想定されていることが多くなったので、ここ一年ぐらいで楽になってきましたね。

2022年を振り返って

毎年やっている昨年の振り返りをしてみます。2021年はこれでした。

tech.guitarrapc.com

総合

2022年は、2021年にやったことの一部が成果として世の中に出た年でした。会社としては開示条件を得てなかったので公開事例にはできないのですが、喜ぶ人が観測できたのはよかったです。2022年も新しいことへのチャレンジに取り組んでいます。今もクライアントにフルコミットが必要で、自社の時間を設けるのが難しいのは変わらず、そろそろ自社に引きこもりも検討してほしいといわれそうで戦々恐々しています。

サービス全般を一手で見るのはやはり難しい、主に私が病気や事故で倒れた時に詰むというのを真剣に正面から考えた年でした。あくまでもクライアントへの協力なので、プロジェクトが真摯に取り組むことでもありますが、協力会社しては真剣に悩みます。幸いにして、IaC 100% 、かつ CI/CD を整備し続けてきたこともあり、運用や設計をほかの人に伝えることも進めることができたという側面があり、IaC は本当にプロジェクトの地力を高めるなぁと痛感した年でした。やっておいてよかったIaC、IaCは嗜み。

2022年もわからん殺しが多かったですが、今年も周りに助けてもらいながら1つずつ潰せしました。去年の自分から受け取ったもののうち、課題ではなくしたものと、さらに来年に投げたものがあるので来年早々に片づけます。目途をつけて寝かしつつ、優先順位つけて、完了させて次につなげるの繰り返し。

経営

実は自社でリリース目前でリーガルチェックも通して、あとは私の決断次第というステージまで来たサービスがありました。が、リリースしないという選択をしました。メンバーとも相談したものの、決断は私なので本当に申し訳ないと思います。リリースしなかった理由は、リリース後に取り消せないということにあります。

弊社ではサービスを作るときにホワイトペーパーを用意してサービス開発するか決定しているのですが、そこでもしかしてとチームでも一瞬触れつつ、まぁリリースしてみて考えるかと棚上げしたのです。リリースしたら取り消せないことの重要性に気付かずここまで来てしまった。ペルソナも用意したものの、今考えると都合のよいペルソナばかり用意した結果、サービス開発上はぶれなくいけたものの、リスクをおざなりにしてしまいました。リリースしたときに悪意を持った利用ができる余地があるサービスだったので、リリースがリスクとなります。悪意を持った利用を防ぐには、ホワイトペーパーと利用ペルソナから乖離することになり、サービスの性質が変わる。となったときに寝かせることにしたのでした。

ということで、別のサービスにピボットしてまた考えます。

プログラミング

今年はかなり C# メイン気味だった気がする。Go、Python、TypeScript も書いてたけど、C# メインだったなぁ。

C#

C# 11 が出て、required modifier のおかげで IaC (Pulumi) との相性がかなり良くなりました。呼び出し側に強制しつつ、利用側でもnullable を不要にするにはコンストラクタしかなかったのが解消されてよかったです。

learn.microsoft.com

フレームワーク基盤としては Source Generator がかなりよくいい感じだと思います。普通に便利だし、今後も使っていくし、いくつか用意したいものがあるので書いていきたい。C# サーバーの 負荷試験にDFrame を利用しているのですが、v2 はかなり良くなっているのでいいんじゃないでしょうか、v1 でしんどかった部分がほぼ解消したと思いますし、実践向きな構成になりました。Pulumi は良い感じですが、AWS-Native はまだ微妙に怪しいので AWS Classic を使っておくのがいいでしょう。

そういえば、C# の CI は GitHub Actions が完全に決定版という感じまで来たので、あらゆる C# リポジトリの CI は GitHub Actions を用意していけるといいなぁと思います。その割に setup-dotnet は微妙に環境変数回りとかは手薄で悩ましい。dotnet build 周りのプラクティスもちょっとたまってきたので、記事にしたいところです。

IaC

Terraform と Pulumi と cdk を使っていました。CDK いいけど、やっぱりセンスが微妙すぎる。

2022年に痛感したのは、IaC は地力ということでした。チームとして組むときに最低限のコードがドキュメントというのにいくには IaC が必要であり、ドキュメントや CI/CDやテストが一般的なソフトウェア開発のレベルまで高めるのでインフラをソフトウェア開発にするためにも IaC は最低限必要だと思います。

AWS Console や GCP Console、Azure portal でぽちぽちのほうが早い、わかりやすいはそうです。労力がどこまでそこにつぎ込まれているか考えれば当然です。しかし、再現性となるとコードに落とすしかなく、CLI ではだめなのです。ソフトウェア開発のプラクティスをインフラに持ってくるという側面には、再現性が重要なファクターであり、無視しようとするとどこかで誰かが割を食います。チームでインフラ基盤を鍛え上げるにはIaC は必須であり、価値を見失ってはいけないのではないかなぁ。

この側面からみるとBicep は IaC ではないといっていいでしょう。何しろ、インフラを継続的にアップデートできないんだからどうしようもない、IaC ではないワンショットとしてはいいんですけどね。IaC というなら顔洗って出直してくるといいと思います。

terraform は moved 構文によって、ほかの IaC から頭1つ飛びぬけました。コードのリファクタリングをインフラに依存せず安全に行える、そんな仕組みを言語レベルで用意したのは初めてと認識しています。これによって、HCL は現状 IaC を学びサクッと運用に持っていくには最適と言っていいと思います。Pulumi は state json を直接いじればできるけど、言語レベルの moved 構文が来ないと辛すぎるので頑張ってほしい。だが、HCL は制御構文がゴミなので、プログラミングのノウハウからすると、厳しいぞ、Terraform。

コンテナ

ContainerApps への AKS からの移行や ECS Fargate から App Runner への切り替えを行ってみた年になりました。2022年いいぞ、ついに Fargate を意識せず、AKS/ACI を意識せずにアプリを起動できるところまできた。Cloud Run に徐々に追いついたともいえる。実際この世界いいんですよね、Kubernetes や ECS を組むまでもなく、Fargate という仕組みを知る必要もない。コンテナの Build & Share さえすればアプリへアクセスできるというのは、ミニマムに必要なことへアプローチができます。開発環境や社内向けにはぴったりといえます。本番環境で使うには、となると FaaS を置き換えるぐらいならいいと思いますが、Zero to scale がイベントドリブンの前提になります。そういう意味では、App Runner はスタートラインに立てておらず、まだまだだめですね。

Kubernetes は クラウド環境で、1.24 がデファクトになりました。ずいぶん歩みがゆっくりになった気もするけど認識がバグってるでしょう、十分早い。1.25 が欲しい機能を3つほどピックアップしているので、年明けが待ちどおしいです。

Kustomize と Helm 問題は難しいですね、2022年、時々探したのですがいい方法は見つからず答えを探してさまよう日々が続きそう、だれか YAML をいい感じで管理できる仕組み教えて...。

ネイティブ

ネイティブビルド、対応プラットフォーム増えると地獄だし、それを複数のOS でビルドサポートするとなるとさらに煉獄って感じで、なにそれ辛すぎます。頑張ったしある程度できたけど、修行足りないので出直してきます。

記事

22本、去年よりは増えた。なんか書きたいことをかけてないんですが、ドキュメントほかで書きまくっててブログに書けないんですよね。適当にもっとライトに書こうと思うので、はてなブログの更新方法も GitHub ベースにしていじっていこうと思います。

ライフスタイル

コロナだいぶんはやりましたね。ついに身の回りでもたくさん感染者が出ました。看病をしてみて思ったのですが、家でもマスクが必要になると導線含めて中々生活は難しいですね。とはいえ、9月以降は慎重にしつつも外に意識的に出かけています。随分と飲食店や映画館も緩くなったという感じがあります。私は意識して口に入れるとき以外マスクしたりしていますが、今のところ感染を避けられるなら安いものだと思います。ようやく食事を楽しめそうになってきてうれしいと思います。好きな店はいくつも閉店してしまったのですが、それも時代でしょう。

2023年は?

2022年は、クライアントに自分が SPOF にならないように働きかけつつ、リリースまでこぎつけたりと休みがほぼなく忙しかったです。そして、何気にリモートワークが終わった。(おわった)

2023年も協力している会社が頑張れるように微力ながら力を尽くしますし、自社の開発面白い感じになりそうなので、時間作るぞ、と。リモートワークになることはなさそうだな!? (信じられない顔をしている)

個人的には、Kubernetes と CaaS がどうなるかが2023年の大きな要になると思います。