docker としての asdf ― あるいは、なぜ私は anyenv から乗り換えたか

ソフトウェアエンジニアの三上（@mickamy）です。普段の業務では、取引管理という部署で、主に取引とその周辺（入出金など）に関わる処理の開発を担当しています。

最近、asdf という anyenv の代替となるツールを知り、気になってはいたのですが、なかなか anyenv から乗り換えるモチベーションを見出せずにいました。あることをきっかけにそのモチベーションを言語化できたので、その使い方とメリットについてお伝えできればと思います（タイトルの前半についてはだいぶ盛っています）。

asdf とは何か

asdf は、様々なソフトウェアの複数バージョンを管理するための CLI ツールです。

プログラミング言語のバージョン管理は、特に開発者に馴染みの深いユースケースかと思います。あるプロジェクトでは ruby の 2.7 系を利用しているが、別のプロジェクトでは 3.2 系を利用したいという場合に、複数バージョンをインストールし、都度 PATH を通すことでの管理も可能ではありますが、極めて煩雑な作業となりえます。

asdf を使えば、任意のディレクトリに紐づく言語のバージョンを指定でき、そのディレクトリに移動したタイミングで、当該のバージョンへの PATH を自動で通すことができます。

同じ課題を解決できるツールに anyenv がありますが、それとの違いとしては、 anyenv がプログラミング言語に限定されているのに対し、 asdf の管理スコープは言語に止まらず、さまざまなソフトウェアを対象としていることが挙げられます。これは、anyenv の実体が rbenv や nodenv などの **env 系の CLI ツールのラッパであるのに対し、asdf では plugin という機構により任意のソフトウェアのバージョン管理を行えるようになっていることから来ています。

asdf の organization 配下には、ruby, nodejs, erlang などのプログラミング言語のプラグインがオフィシャルとして提供されていますが、plugin 自体は誰でも開発することができます。例えば Java の plugin は、一般の開発者によってメンテナンスされています（そのことに一抹の不安を覚える方をいらっしゃるかもしれませんが、筆者が利用した限りでは、とてもリーズナブルな作りになっており、信頼できると考えています）。

様々な種類のソフトウェアに対応した plugin を利用することで、それら全てを asdf で一括で管理することができます。plugin を管理するリポジトリを見ると、 yarn や awscli, mysql など、一般的な WEB 開発に使われるソフトウェアは軒並み対応しています。

asdf の使い方

asdf 自体のインストール方法は公式のドキュメントに譲るとして、plugin の追加や各種ツールのインストールなどの詳しい使い方を見ていきましょう。なお、ここで記載している方法はあくまで記事執筆時点での情報です。細かなコマンドなどは変わり得るので、一次ソース（公式ドキュメント）も合わせてご確認されることをお勧めします。

# (1) plugin のインストール
$ asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git
# (2) plugin を介したソフトウェアのインストール
$ asdf install nodejs latest
# (3) ローカルのバージョンの指定 
$ asdf local nodejs latest
# (4) `.tool-versions` に記載されているソフトウェアのインストール
$ asdf install

(1) で、asdf の plugin をインストールします。各種ソフトウェアのインストールも、この plugin を介して行います（2）。ローカルのバージョンを指定することで、.tool-versions というファイルに、利用するソフトウェアとそのバージョンが記載されます（3）。この .tool-versions を git repository に含めることで、他の開発者も同じバージョンのソフトウェアをインストールして利用することができます（4）。

例えば、ruby, nodejs, Java を利用した .tool-versions は以下のようになります。

$ cat .tool-versions
ruby 3.1.3
nodejs 16.17.1
java corretto-11.0.17.8.1

チームで利用する asdf

ここまでで、asdf の使い方や、anyenv との比較を簡単に見てきました。以下の章では、長らく anyenv を愛用してきた筆者が asdf に乗り換えようと考えたきっかけについて書いていきます。

最近の WEB 開発では（といっても、もう随分と前からですが） docker を利用することで、本番環境と開発環境（ローカル PC, CI/CD）の差分をできるだけなくした状態での開発が主流になっています。本番環境で docker を利用してデプロイされているアプリケーションについては、ローカルにおいても docker 上で開発を行うことで、特に上記のメリットを享受することができます。

一方で、WEB フロントエンドやモバイルアプリなど、本番環境で docker を利用しないシチュエーションというのも存在します。そのような場面でも、各開発者間の環境差分をなくすという観点から、開発環境として docker を利用するメリットがあります。一方で、ディスク I/O が遅いといったパフォーマンスなどのデメリットが存在するのもまた事実です。特に iOS アプリ開発に関しては、macOS の docker image が公式に存在しないことから、開発を docker 上で行うことは困難を極めると言っていいでしょう。

そのデメリットがメリットを上回ったと判断される時、ローカル開発環境としては docker を利用せず、各開発者の PC 上で環境を用意する運用となります。その場合、リポジトリの README などに言語やツールのバージョンを記載し、各開発者がそのバージョンをインストールするよう求められることになりますが、asdf を利用すれば、asdf install などのコマンドで全てのツールを一度にインストールすることができます。

asdf を使った CI/CD 上での環境構築

anyenv を利用しても、ローカル環境構築においてはほとんど同じ恩恵を享受することができますが、CI/CD 上での環境構築についてはどうでしょう。

利用するプログラミング言語がひとつに限られている場合、多くの言語ではオフィシャルの docker image が配布されているので、それを利用して CI/CD 上で他のツールをインストールすることができます。あるいは、複数のプログラミング言語を利用する場合（モバイルアプリ開発において、fastlane を利用するために ruby が必要など）、そのプロジェクトのための docker image を用意することも選択肢となるでしょう。

しかし、これは筆者の経験ですが、CI/CD 環境で利用するためだけの docker image の作成と管理は時に煩雑になりえます。 Dockerfile の開発、作成された image の registry への登録、さらに CI/CD サービスから当該の registry 経由で image を pull するための設定など、やりたいことは単純なのに考慮すべき点がいくつか存在します（本記事では private な docker registry を利用すると仮定します）。

これがひとつのプロジェクトなら許容できますが、複数プロジェクトに対して専用の image を管理するとなると、そのコストは無視できません。特に、今回の例では CI/CD 環境でのみ当該の image を利用する想定のため、あまり本質的でない作業に時間を取られることになります。

asdf を利用することで、docker image なしに、それに近い環境を CI/CD 上で構築することができます。

プログラミング言語のバージョンはもちろん、anyenv では管理することができなかった各種ビルドツールのインストールまで、ワンストップで行えます。

恐らく読者の方は、パフォーマンス上の懸念（言語やツールのインストールに時間がかかる）をお持ちかもしれませんが、昨今の CI/CD サービスで提供されているキャッシュの機構を利用することで、インストールにかかる時間は許容できる範囲に収まるはずです。

asdf によってインストールされたソフトウェアは、$HOME/.asdf 以下に配置されるため、そのディレクトリをキャッシュします。初回のインストールにかかる時間については懸念の通りですが、各種ツールのアップデートはそう頻繁に発生するものではないため、これもまた許容できるはずです。

また、キャッシュのサイズが大きくなるにつれ、キャッシュファイルをほどく時間がかかるのでは、という懸念もあったのですが、筆者の環境ではそのようなことはありませんでした。 github actions を利用し、Java, nodejs, ruby と yarn のインストールとキャッシュを行ったところ、筆者の環境では、リストアに要した時間はたったの3秒です。

github actions でのキャッシュのリストアと asdf install

まとめ

以上、筆者の考える asdf の利点と、anyenv からの乗り換えを決意した理由について書いてきました。

開発環境のセットアップは、組織上とても大切なことだと筆者は考えています。特に開発初期のタイミングなど、複数の開発者を一度に受け入れる際に、必要なソフトウェアのインストールを各自で行ってもらうのは、受け入れる側も受け入れられる側もストレスになりえます。インストールにかかる手間を少なくし、チーム・プロジェクトにジョインしてから最初の PR がマージされるまでのリードタイムを短くすることで、双方の体験を向上することができます。

docker は、特に開発環境の構築においてそのための解になりえましたが、必ずしも全てのチーム・プロジェクトに最適なものではありません。そのような場合において、asdf が課題の一端を解決するのに役立つことがあると筆者は考えています。読者の方の課題を解決しえるソリューションのひとつを提示できたとしたら、これに勝る喜びはありません。

ウェルスナビでは、一緒に働く仲間を募集しています。金融系となると、忌避される方も一定数いらっしゃるかとは思いますが、在籍しているメンバは皆、一皮剥けばただのアツいエンジニアです。特に取引管理では、顧客の資産の取引という、極めてコアな処理を扱うため、なかなか他では得難い経験ができると自負しています（筆者が取引管理に在籍しているためのポジショントークという意味合いももちろんあります）。

hrmos.co