ぽれのーと

技術に関する雑な感想置き場

今更ながら 1password を使ってみたけどかなり便利だった

ぐだっとした感想です。

TL;DR

1Password で良かった点

※基本的なパスワードマネージャーとしての機能は当たり前に備えているので、それらについては省略します。

SSH Agent

1password では SSH 鍵を管理でき、外部に SSH する際に ssh-agent として利用することができます。 仕組みとしては ssh-add する際の認証を 1password への認証で済ませるようなことが可能です。

https://developer.1password.com/docs/ssh

Git の署名

最近知ったのですが、現在は Git の署名に SSH を用いる方法を使うことが可能です。 GitHub などの Platform に push したタイミング等に依存しますが、それでも従来の GPG 署名の鍵管理が無く圧倒的に簡単です。

この署名用の鍵の管理すらも 1password で行うことができます。コミットするときに 1password の認証を通すだけで署名ができるようになります。

その面倒さ故、普段から署名を行う人は少ないかもしれませんが、1password を挟むと「ほぼノーコストだからやっておくか」という気持ちにさせてくれるのは非常に良い体験です。

1password connect server / 1password SDK

1password はプログラムからシークレットにアクセスする手段を豊富に提供してくれています。 API 経由であれば connect server で、プログラミング言語から直接であれば SDK を使ったアクセスが可能です。 その他に CLI なども提供しています。

私の自宅インフラでの利用事例

私の自宅サーバーは以下のような手順で構築されており、まっさらな状態からなるべく自動的に定義した環境が立ち上がるようにしています。 Ansible と Kubernetes の 2 つのレイヤでシークレット管理が必要だったのですが、それぞれのレイヤで 1password を利用することで、シークレットの管理を統一的に行うことができました。

  • マシンに Proxmox のインストール (手動)
  • 1Password Connect Server をローカルに立てる
    • Ansible が参照する専用。 Ansible を実行する間だけ起動されていれば良い。
  • Ansible を実行する (以下 Ansible で行っていることの詳細)
    • 各種シークレットへの参照は 1Password の Ansible Integration を使用する
    • Proxmox を操作し各種 VM を立てる
    • 各種 VM (PVE) 内の構成管理
    • Kubernetes クラスタの構築 + argocd 設定 + その他
      • ArgoCD に任せることができるものはそっちに任せる
      • K8s 内からは以下を用いてシークレットへのアクセスを行う

余談: Enable specifying the vault by UUID

external-secrets には元々 1password connect server provider を提供していたのですが、最近 1password から 1password SDK が登場したことで、 external-secrets でも 1password SDK Provider の利用が勧められています。

ただ最近出てきたばかりだったらしく vault の指定を UUID で行えていませんでした。変更の可能性がある名前 (Title) での管理はしたくなかったので以下の PR を出したところ迅速にレビュー対応していただきマージしていただけました。 Thank you!

OnePasswordSDKProvider Enable specifying the vault by UUID by pollenjp · Pull Request #4906

パッケージ管理ツールとして hatch を使ってみた

きっかけ

Python のパッケージ管理を行うツールは多くありますが、自分はそのお手軽さから rye をよく使っています。

しかしながら、rye は最近のツール故にで EOL なバージョンの Python に対応していないことが多いです。

今回 EOL な Python を使う必要が生じた (※1) ため、Hatchを使ってパッケージ管理してみることにしました (※2)。

使ってみて気になった点の感想をぬるっと書いてみます。

※1 ... そもそも EOL なバージョンを使うべきではないというのはその通りですが、バージョンアップ対応が遅れていたため、一時的な手段として古いものを継続して使っていました。

※2 ... ツールが EOL なバージョンへのサポートを切っていくは普通のことで hatch も例外ではありません。しかし、hatch 自体のバージョンをまだ EOL ではない時の状態に下げれば昔のものも利用することができます。 rye の場合は最近のアップデートが激しいため古いバージョンにすると使用感が大きく崩れます。

Hatch とは

Hatch には主に２つの機能が存在します。１つは build-system としての機能、もう１つはパッケージ管理としての機能です。

Python でパッケージを作成する際は setuptools を使うことが一般的ですが、PEP 517 等に準拠した他の build-system も指定が可能です。 build-system としての hatch もその一つで、簡単にパッケージお設定を記述できるようになっています。 rye もデフォルトでは hatch を build-system として指定しています。

パッケージ管理の機能には様々なものがありますが代表的なものとして以下のようなものが上げられるかと思います。

  • パッケージのビルドとアップロード
    • PEP 518 の情報を元に wheel ファイルを作成し、 PyPI にアップロードする
      • Python バージョンの指定
      • 依存パッケージの指定
      • build-system の wrap
  • 環境の設定と構築 (オプショナル)
    • 本番用・開発用環境の構築や切り替え
    • test/lint/format の実行

Python は単体のファイルでも動作するので、パッケージ管理を行わなくても動作させることは可能ですが、パッケージ管理を行うことで環境の再現性を高めることができます。

気になった点

依存関係の記述

pyproject.toml の dependencies に依存関係を 直接 記述します。 rye add や poetry add のようなコマンドは存在しないため、手動で記述する必要があります。

詳しい依存関係の整合性をチェックしたり、別ファイルに残したりはしないのでそこだけ注意が必要です。

dependencies = [ "requests", "click" ] # 例

hatch build, hatch publish などのコマンドを実行することで wheel ファイルを作成し、 PyPI にアップロードすることはできます。

複数の仮想環境の設定

Hatch では pyproject.toml 内に複数の環境を定義することができます (poetry における group に近いです)。

パッケージ用環境と dev 環境以外に、必要最低限のパッケージだけを入れてテストしたい環境がある場合は便利そうです。

#
# 開発環境用 (default)
#
[tool.hatch.envs.default]
dependencies = [ "mypy", "ruff", "pyright" ]
[tool.hatch.envs.default.scripts]
typing = [
  "pyright {args:src/pkg_name}",
  "mypy --install-types --non-interactive {args:src/pkg_name}",
]
style = ["ruff check {args:.}"]
fmt = [
  "ruff check --fix {args:.}", # https://docs.astral.sh/ruff/linter/
  "ruff format {args:.}",      # https://docs.astral.sh/ruff/formatter/
  "style",
]
lint-all = ["style", "typing"]
[[tool.hatch.envs.default.matrix]]
python = ["3.12"]

#
# test 用
#
[tool.hatch.envs.all]
dependencies = [ "pytest", "pytest-mock" ]
[tool.hatch.envs.all.scripts]
test = "pytest {args:tests}"
test-cov = "coverage run -m pytest {args:tests}"
cov-report = ["- coverage combine", "coverage report"]
cov = ["test-cov", "cov-report"]
[[tool.hatch.envs.all.matrix]]
python = ["3.10", "3.11", "3.12"]
# default 環境の fmt コマンドを実行したい時
hatch run fmt

# all 環境の test コマンドを実行したい時
hatch run all:test

rye, hatch, poetry の比較

rye hatch poetry
Python のインストール o o x
build-system の提供 x o o (poetry-core)
パッケージ作成 o o o
開発環境の構築 o (2 環境のみ) o o
パッケージ依存性解決 o x o

終わりに

hatch をパッケージ管理ツールとして触ってみた感想を雑に書いてみました。

今まで build-system としての hatch は使ったことがありましたが、パッケージ管理ツールとしては初めて使いました。

既に使ったことのある rye や poetry との違いを感じることができましたが、シングルバイナリという導入のしやすさを考えると個人的には rye がイチオシです。

一方で poetry に近いような細かい設定もできつつ、Python バイナリのインストールも行える hatch は他のツールと比べても一長一短があると感じました。

※ ディレクトリに閉じた環境で Python バイナリを構築したい場合はこちらの記事をご参照ください。