tech.guitarrapc.cóm

Technical updates

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年の大きな要になると思います。

2022年に買ってよかったもの、使ってよかったもの

2022年に買ってよかったもの、使ってよかったものです。使ってよかったサービスに今まで入れてたのを分離という感じで。

tech.guitarrapc.com

軟骨伝導イヤホン

ATH-CC500BT

https://www.audio-technica.co.jp/product/ATH-CC500BT

ShokzのOpenCommを使っていたのですが、軟骨伝導はどう変わるかと思って買ったら衝撃的によかったです。骨伝導とは全く違う、そこで鳴っている感触が味わえるのでチャンスがあれば試してほしいです。そして、人気が爆発して後継機が出てほしい。

骨伝導は頭の上というか奥でなってる感じがあるんですが、軟骨伝導は耳元でなっている感じがあります。結果どうなるかというと、普段の音楽が聴ける音質までぐっと引き上げられます。欠点は、マイク性能がそれほど良くないようでリモートワークでこもって聞こえるようなのと、1時間ほどつけていると耳の上が痛くなります。後継機が出たら付け心地の改善を期待できるので、ぜひ人気が出て他社含めて骨伝導を入れ替えていってほしいところです。骨伝導が次の世代に進んだという感じなので、本当に買ってよかったです。

あ、あとUSB-Cなので充電に困らないのが地味にいいです。OpenCommの充電は最低。

イヤーオーバーヘッドホン

Soundcore Life Q35

https://www.ankerjapan.com/collections/headphone/products/a3027

以前使っていたソニーのWH-CH710Nがついにぼろぼろになったので、手ごろな値段でいい感じのがないかと選びましたが大正解でした。

WH-CH710Nからみて、ノイズキャンセルがついて音もいいので上位互換に感じます。音も聞きやすいので、お手頃でいいやつないやつがないかと聞かれたらこれをお勧めしちゃいます。Ankerのヘッドホン、良いと聞いていたのですが、実際によかったので買って試してよかったです。

もちろんUSB-Cです、最高。

ヘッドホンハンガー

PUCK マグネットフック ホワイト NZXT エヌゼットエックスティー BA-PUCKR-W1

https://www.ask-corp.jp/products/nzxt/accessory/puck.html

ヘッドホンをデスクトップPCの側面に張り付けたり、リングフィットをデスクの足に引っ掛けています。

ほかのクリップとかと違って側面につけられるのが良くて、磁力もそこそこ強いのでずれることもないのにつけ外しもできて使い勝手最高です。ヘッドホンフックに悩んで探し回っていたのですが、結構私にはベストフィットですごくうれしいです。半分にして2個として使えるので、1つ買えば2つつけられるという謎のお得感もあります。

ロジクール Signature M650

Logicool Signature M650

https://www.logicool.co.jp/ja-jp/products/mice/m650-signature-wireless-mouse.html

静音マウスいいなぁと意識が変わったマウスです。一度使うと病みつきだし、買ってよかったです。

マウスパッドと光学トラックが相性悪くて今はMX Anywhere 3に戻していますが、MX Anywhereが静音化してほしい。Signature M650は先日新モデル出ましたがトラッキング変わってなかったので望み薄っぽい。価格帯の差別化のためどうしようもない気がするので、MX Anywhereがんばってくれ。

ゲームパッド

SteelSeries Stratus Duo

https://jp.steelseries.com/gaming-controllers/stratus-duo

SteamでHoriのゲームパッドを使ってたのですが、ジョイスティックが下手ってエイム厳しくなったので変更しました。

SteamでGeneric Gamepadとして認識されるXbox系配置です。Steamの多くのゲームは、この配置のコントローラーが大体のゲームでサポートされているのでPS系から移行って感じになりました。 ゲームによってジョイスティックが繊細だとやりにくいけど、たいていのゲームではいいのではないですかね。メニューボタンが押しにくいので、ちょっと厳しい面もあり、XBoxカスタムにしようと考えています。

https://xboxdesignlab.xbox.com/ja-jp/

SteelSeries Stratus DuoはマイクロUSBなのでダメっていう説もあります。

デスクパッド

Desk Pad

https://shop.minimaldesksetups.com/en-jp/products/desk-pad

ずっとマウスパッド使ってたのですが、デスクパッドを試したことなかったので試してよかったです。

デスクパッドにすると、キーボード、マウスがセットになるので結構いいですね。まとめてどかしたりもできるし、ふとした時に便利です。このデスクパッドはお手頃価格なのでお試しにいいし、開梱してすぐ使っても丸まらないので安心してください。欠点は、ファブリックなので光学マウスと相性が最悪です、具体的にはSignature M650がまともに使えなくなってMX Anywhere 3に戻しました。あとちくちくするので、ちょっと肌に合わない人とかいそう。

私もいつかいやになりそうな気がするけど、1年たった今は悪く感じてないのでもうしばらく使って体験を貯めます。

タイルカーペット

STYLE KIT

https://www.sangetsu.co.jp/pickup/stylekit/

タイルカーペット、これまで10年ぐらい使っていろいろ試してきましたが、サンゲツと東リが圧倒的に品質よくておすすめです。

ここ2年はニトリのタイルカーペットをいろいろ試していましたが、だめだなぁってなったので以前使ってたサンゲツに戻しました。ちょうど気になってたSTYLE KITを思い出したのでこれにしたのですが、あたりでした。ずれないし厚みもいいし、色合い、枚数とも調整できていうことないです。

STYLE KITはほかのカーペットよりカジュアルっぽい風体ですが、実態はめちゃめちゃ使いやすいのでデスク回りに敷くの最高です。

フライパン

ティファール T-fal G26277 [IHルージュ アンリミテッドマルチパン 26cm]

https://www.t-fal-onlineshop.jp/tfal/shop/goods/index.html?ggcd=2100116638

使っているティファールの深型フライパンが4年ぐらいになって、こびりつきが起こるようになってきたので新しいのに変更しました。

このモデルにしたのは深型+注ぎ口がついているのが理由、期待通りソースなどがたれなくなったので最高です。もともとフライパンは深型がほとんどのケースにマッチしていて浅型フライパンより好きなのです。1これも4年ぐらい持つよう丁寧に使います。

前のモデルからの変更で気になったのが、フライパン上部が少し開くようになったので使っていた別メーカーのフライパン鍋がぎりぎりに落ちるかどうかという感じになりました。ただ、ティファール純正のフライパンの蓋はガラス製です。ガラスの蓋は昔割ったことがあるので既製品で合うのを探す旅に出るか悩んでいます。

電子体温計

タニタ TANITA BT-471-GY

https://www.tanita.co.jp/product/medicalthermometer/3932/

ずっとテルモのを使ってたのですが、無頓着に古くなってしまったので新しくしました。

このモデルが本当にいいかはよくわからないです。が、医療機関での利用があるのと、予測式の検証結果が悪くなかったので選びました。2 以前は予測式じゃなかったので時間がかかってましたが、これだと20秒ぐらいで完了するのでサクッとみるには便利。実測式が10分程度と前のと同じぐらいなので、そこはおとなしく待ってますが実測のブザーが聞こえにくいと感じます。ふと熱あるかな? というときにサクッと調べられるのは便利だし、こういう小さなストレスは解消していきたいところです。

引き続き感染症には気を付けて生きていきます。

iPhone ケース

OtterBox Figura Series Case with MagSafe for iPhone 14 Pro

https://www.apple.com/jp/shop/iphone/accessories/cases-protection?fh=458b%2B2d0d&f=tpu

OtterBox Figura Series Case with MagSafeですが、素材がTPUなの重要だったんだなぁと思わされた年でした。

Apple純正のシリコンを試したんですが、2週間程度で隅がぼろぼろ剥げてきてこれはカバンに入れたりするのとは致命的に合わない感じでした。そこでiPhone 12で使っていたTPUに変えたところ、素材がはげることなく使えているのでいい感じです。シリコンは滑らない = 手で持って安心感があり、一方でTPUはすべすべなのが気になっていますが素材は好きです。今後もTPUがいいということに気づいたので買ってよかったです。


  1. 深型フライパンより浅型フライパンがやりやすいのはステーキとかの熱通す系で、深いと熱が入りすぎるので悩ましいときはあるけど。年に何回もやらないので割り切っています。
  2. 体温が35度台なので、予測0.6度程度ずれても37度に行かないので問題ないし、実際のところ予測でも0.2度程度しかずれてないので良い感じ。

2022年に使ったサービス

2021年、2020年は書き忘れてたみたいです。

tech.guitarrapc.com

継続しているもの

基本方針は、すぐに辞められる月間契約を選択、やめない/月間がないものは年間契約。

月間契約

サービス名 価格 期間 継続? 用途
Apple Music 1,480円 2019年~ 継続 ストリーミング
AWS $4.64 2013年~ 継続 Route53 / Lambda / S3 / KMS
GitHub Pro $5.00 2013年~ 継続
GitHub Sponsors $1.00 2022年~ 新規 @mayuki
Google Workspace Business Starter 680円/user 2013年~ 継続
IIJ 990円/user 2021年~ 継続 4GB 音声 SIM
Money Forward ME 480円 2018年~ 継続 家計簿、手放しで管理できるのがいいです。
Nintendo Switch Online 306円 2022年~ 新規 Mother2 がやりたくて
Plala 4843円 2004年~ 継続 ISP、光電話つき。
Udemy コース次第 2017年~ 継続 技術系の動画スクール。微妙
Unity Plus 4840円 2018年~ 継続 開発環境。
Youtube Premium 1180円 2020年~ 継続 広告のあるYoutube に戻りたくないです。
ジャンププラス 980円 2016年~ 継続 呪術廻戦、ワンピースが面白くて継続。
マガジンポケット 840円 2018年~ 継続 ブルーロック、シャングリラフロンティアが面白くて継続。

年間契約

サービス名 価格 期間 継続? 用途
Amazon Prime 4900円 2014年~ 継続 ネットショッピング。ヨドバシメインですが、時々使ってます。
Bitwarden Families Organization $40 2019年~ 無料->有料 無料でやっていましたが有料に切り替え。TOTP管理できるので最高。
GitKraken $59.4 2016年~ 継続 Git GUI クライアント。macOS/Windows両方で利用。$49から値上がりした。
はてなブログ 8434円 2013年~ 継続 今使ってるマネージドなブログサービス

無料

サービス名 価格 期間 継続? 用途
Azure 0円 2015年~ 継続 ContainerApps / AzureFunctions / AppService / AKS メイン
Circle CI 0円 2015年~ 継続 Orb の開発、リリース
diagrams.net 0円 2013年~ 継続 Mermaid メインだしそろそろやめたいけど、構成図が厳しい。
Docker Hub 0円 2017年~ 継続 個人のイメージぽんぽんおいています。課金する気にはなれなく悩ましい。
Eight 0円 2017年~ 継続 名刺交換の機会ほとんどないですね!?
Fastly 0円 2015年~ 継続 検証に Developer Account。
Fork 0円 2019年~ 継続 GitKraken が承認されないときに
Fulcul 0円 2020年~ 継続 タクシーの状況見るときに
GCP 0円 2016年~ 継続 開発環境
Go 0円 2019年~ 継続 タクシーの状況見るときに
Google Adsense 0円 2017年~ 継続 ブログ
Google Analytics 0円 2013年~ 継続 ブログとか
IFTTT 0円 2016年~ 継続 連動系はこっち
Integromat 0円 2019年~ 継続 インスタントは処理はこっち
Kibela 0円 2017年~ 継続 微妙なのでやめようかな
Microsoft To Do 0円 2019年~ 継続 TODO はこれで安定しています。
netprint 0円 2019年~ 継続 コンビニ印刷便利。
PayPay 0円 2019年~ 継続 2022年になって使う機会がすごく増えました。
S.Ride 0円 2022年~ 新規 タクシーの状況見るときに
Slack 0円 2017年~ 継続 個人のあれこれ。3か月で消えるようになって草。
Zapier 0円 2016年~ 継続 連動系はこっち
一休 0円 2017年~ 継続 ホテル、レストラン予約

やめたもの

サービス名 価格 期間 用途
Appveyor 0円 2015年~ さすがにおわった。
Azure DevOps 0円 2015年~ さすがに使わない。
duet 0円 2016年~ macOS がデフォルト対応してしまったのでオワコン
NearLock 0円 2017年~ そろそろ使わなくなりました。
Netflix スタンダードプラン 1,480円 2020年~ 見たいものがある時だけ入ってやめてを繰り返しています。
OpenCollective $5 2018年~ GitHub Sponsors に切り替え

感想

代り映えしない感じがあってよくないですね。2020年~のコロナになって、新しいサービスを試している頻度は変わっていないようにも思うのですが、あまり決定的なという感じがありません。Midjourney や ChatGPT も面白いけど、なんかここに乗せるサービスじゃないんですよね。

月間契約を優先する理由は、やめたいときにやめたいからです。やめようと思ったときにタイミングによって左右されるのは、賃貸だけで十分というのを忘れてはいけない。あの不自由さによるストレスからは自由でありたい。

  • サブスクの価格、あがったようで上がってなかったり。でも下がることはない、それがサブスク
  • ドル建ては円安の影響をもろに受けるので、細かいことを考え出すとストレスですね
  • 2019年に使っていた Goland はやめて VS Code に変更しました。VS Code で十分すぎる
  • Open Collective をやめてGitHub Sponsors に変えています。スポンサーの口はまとめたいんですよねぇ、という GitHub の思惑に乗った気がします
  • ジャンププラスは、有料じゃない読み切りやチェンソーマン第二部、ダンダダンが最高でどうしたものか。単行本買うのでもいいんですが、採用された読み切りなどの何となくのトレンドがわからなくなるので本誌は読みたい気持ちがあります。著者へのボーナスができたりするなど試みを重ねてるのがいいなぁと思います
  • マガジンポケットは、単行本購入ではなく話購入なので、Kindle などを含める単行本の購入と完全に敵対してるけど、無料分で読むにはよくて絶妙ですね。良くもあるけど、一気読みはできない代わりに長く見る方向に働きますね

GitKraken を改めて考えてみる

以前 Fork について書いたのですが、GitKraken についても書いておこうと思います。

tech.guitarrapc.com

tl;dr;

Unity リポジトリではgit操作が重く悩ましいのですが、それを除くと GitKraken は最高の Git GUIクライアントだと思います。速度の Fork か、使いやすさの GitKraken か、両取りのGitKrakenターミナル統合か、と用途に応じて使い分けるのも手でしょう。

  • GitKraken を商用で利用するなら有料版が必須。OSS開発だけなら無料版が利用できる
  • 視点移動が少ないUI設計が使いやすい
  • ターミナルタブはコマンド派でも操作しやすくGitKrakenのツリーも使えて便利
  • Unityリポジトリなどサイズの大きいリポジトリでgit操作が重くなりやすい
  • GitKranen の push 時にかかる git-hook が失敗するようになることがある

GitKraken の設計目標

GitKraken は、GitKraken で一連の git 操作 (clone, fork、pr) が完結することが目指されており、実際実現できています。目指すゴールとコンセプトがはっきりしているのは良いことです。ではこの設計目標は実際どのように達成されているのか見てみましょう。

価格

GitKrakenには無料版、有料版として Pro $4.95 per user/month、Teams $8.95per user/month あとは Enterprise があります。無料版はOSS利用のみ、GitHub.com のみ接続可能、プライベートリポジトリが開けない、プロファイル切り替えができない などの制約があります。Pro は複数のVCSに対して接続1でき、コマーシャル利用が可能になります。Teams は 10人を超えるユーザー管理、複数チーム管理ができます。

企業利用としても、ユーザーに対するライセンス割り当てをフローティング管理できるので、有料版は企業にも優しいなぁと感じます。

GitKraken Client Pricing

プロファイル

有料版で利用できる、複数のプロファイル設定は非常に優秀です。それぞれのプロファイルにメアド、VCS認証情報やデフォルトCloneフォルダが持てるので、個人で GitHub.com を使うとき、会社で GitHub.com を使うとき、会社で GHE を使うとき、会社で AzureDevOps を使うとき、とすべてプロファイルを分けたりできます。

プロファイル切り替え = .gitconfig の [user] セクションの name, email の書き換えになります。dotfiles で .gitconfig を管理している場合、プロファイルを切り替えで意図しない書き換えがpush されないか気を付ける必要があります。プロファイルが [credential] を見てくれればいいのですがそうはならないのが残念です。 [include] で指定した別.gitconfig の [credentials] に定義した.... を期待してはいけない。

GitHub.com とのOAuth認証

GitKrakenをGitHub.com で使うには Orgに対して OAuth App の許可を行う必要があります。これは結構厄介で、サクッと使おうと思っても GitKraken だと利用できないというケースがよくあります。一方で、GHE (Selfhost) や Azure DevOps は PAT 認証なのですんなり使えます。

プロファイルの[credential] の件も併せて、できれば CLIの認証と同じ仕組みで GitKraken が利用できるといいのですが。

GitHubの Authorized OAuth Apps に GitKraken を含める必要がある

SSH鍵

GitHub.com はSSHで認証するのですが、そのSSH鍵の生成、GitHubへの登録など一通りの操作はGitkrakenで完結します。これは結構重要で、こだわりがないならいちいちSSH鍵生成のために別ツールを利用する必要はありません。とはいえ、GHE や GitLab、Azure DevOps は PAT認証なので関係なかったりします。

GitKraken でのSSHキー生成

UI

GitKraken のUI最大の特徴はツリー画面だと思います。ツリーは真ん中に位置し、左にブランチ、右にコミットが表示されます。

GitKraken のUI

ツリーが見やすいと感じるのが、ブランチやタグがどのコミットを指しているかパッとわかること、複数ブランチから自分のブランチだけをツリー表示する Solo でのフィルタリングです。

Solo 機能で stagingブランチだけを表示した状態

左のブランチカラムは、ほかにもPR、Issue、Tag、Submodules、GitHub Actions が表示されいます。普段の開発だとLocalのブランチ操作がメインになると思いますが、すでに上がっているPRをここからひらくこともできます。Tag 操作もここで行えるなど、git の大半の操作が集約されています。

PULL REQUESTS から PR を開ける

右のコミットカラムは、選んでいるコミットの表示やファイル変更を示し、その変更一覧とコミット操作も右カラムの画面切り替えで表示されます。ファイルの差分表示は、ツリー表示に代わって左+真ん中カラムが切り替わって表示されます。

ファイルの変更は右カラムに表示される

ファイル変更のステージング操作とコミット操作は右ペインが切り替わって表示

ファイル差分は左+真ん中カラムが切り替わって表示

この UI表示で何よりも素晴らしいのが、目線の移動がいかに少なくなるか設計されていることです。特にそれを感じるのが、ファイル差分を左+真ん中カラムを切り替えて表示することです。差分表示は幅も高さも広いほど作業効率が高い一方で、ファイル差分チェック中はブランチ状態やツリー状態は不要です。左+真ん中カラムのスペースを切り替えつつ、コミットにかかわるファイル選択は右カラムのままなので、視線移動が少ないのに必要な視野が確保されています。すごいです。

私が知ってる Git GUI クライアントでこういった視線移動に対する設計がきっちり行われていると感じるものは他になく素晴らしいと思います。

コンフリクト解消

GitKraken は Merge時にコンフリクトが起こってもコンフリクト解消が容易です。コンフリクト時はファイルDiffの表示が「コンフリクト状態と解消選択表示」に切り替わります。行ごとにどちらのブランチから変更を引っ張ってくるか選択ができるのでミスせず操作ができます。VS Code や Vim での解消二度としたくない。

https://www.gitkraken.com/learn/git/tutorials/how-to-resolve-merge-conflict-in-git より引用

ターミナル統合

GitKraken は CUIのみで操作するときでも便利で、push/pull のみ CLI で行ってブランチ操作やツリーはGitKrakenを使うことができます。ターミナル統合のもう1つのメリットは、認証が Git CLI に準じることで「OAuth認証されていないリポジトリだけどGitKraken を使いたい」ができます。そして隠れたもう一つのメリットが git push/pull がターミナル操作なので GitKraken で push/pull するより高速なため大きなリポジトリでも操作が快適です。操作が早くてツリーが便利、を実現するのがターミナル統合の真の価値!

ちなみにGitKraken は Fork や SourceTree のようなカスタムコマンド連携はないのですが、ターミナル統合ならカスタムコマンドも利用可能なので、いつもの感覚で利用できるでしょう。

ターミナル統合でGitKrakenツリーを使う

ターミナル統合で git cli の補完がされる

LFS

Unity を使っていると出てくるのが git lfs です。2 GitKraken は、リポジトリルートの.gitattributesに lfs設定を記載していれば、pull操作で git lfs pull が自動的に実行されるのでLFSを意識しなくなり実体化忘れもなくなります。Fork などは git lfs 統合がなく、都度 git lfs pull が必要なので GitKraken の便利さはすごいです。逆にこの LFS統合によって、1回一回の pull操作が待たされるという感じもあるので、LFS 統合がいいか悪いかは微妙なラインもあるかもしれません。Preference では有効無効を設定できないので仕方ないかなぁ。

git-lfs なリポジトリと検知するとLFSという表示がされる

シングルスレッド

GitKraken にはいくつか課題がありますが、大きなストレスの1つが 「一つ操作をしているとUIがロックされて連続操作ができない」ことです。例えば、A リポジトリタブで pull 中に、別のBリポジトリタブに切り替えることもできません。また、バックグラウンドで git fetch が走っていて、UI上は何の表示もないのに無言で操作できないことがまれによくあります。ストレスに拍車をかけるのがリポジトリが大きい場合の挙動の遅さです。.git が大きなリポジトリ (体感で10GB超~) で git操作 3 に時間がかかるようになります。

シングルスレッドは GitKraken 最大の弱点であり、これが理由で Fork に魅力を感じるのはよくわかります。

ファイルロック

GitKraken のもう1つの課題がファイルロックでしょう。GitKraken で開いているリポジトリの .git は GitKraken につかまれているため、Windows でリポジトリのフォルダが消せなくなります。そんな時は GitKraken を終了させてからフォルダを消してみるといいでしょう。

git-hook

GitKraken の最後の課題が、push 時に勝手に仕込まれている git-hook 操作です。公式ドキュメントにデフォルト hook の記載がないのですが、push 時に git-hook が失敗してpush自体が行えないことがあります。git-hook が一度できないと リポジトリをgit clone しなおしてもずっと解消しなくて詰むことがまれにあるので終わったとなることがあります。

まとめ

GitKraken は、細かい課題や速度に大きな課題があると感じます。しかし UI設計やプロファイルなど使いやすい機能が多く、Git GUI クライアントとしては最も好みです。

私も Unity で LFS なリポジトリだけは Fork を使ったりしています。くやしい。


  1. 有料版の対応VCSは、GitHub、GitHub Enterprise、GitLab、GitLab Self-Managed、Bitbucket、Bitbucket Server、Azure DevOps、Jira Cloud、Jira Server、Trello。
  2. Platic SCM どうですか、Perfoceどうですか。
  3. diff/stage/commit は影響なし、push/pull/checkout が影響を受けやすい。