Dockerの有償プランを契約して運用するまでの話

こんにちは。弥生の内山です。
みなさまご存知の通り、2022年1月31日以降、一定以上の規模の組織でDocker Desktopを利用するには有償プランの契約が必要となります。

www.docker.com

弥生では、検討の結果、Dockerを利用する開発者全員分のライセンスを購入し運用することにしました。
しかし、実際に有償プランを使おう!となったとき、具体的に何をしたらよいのかという情報がWeb上にほとんど見つからず、手探りで作業を進めることになりました。
現時点で、ようやく運用の形が見えてきたため、この記事では契約から運用までの具体的な考慮ポイントをご紹介したいと思います。
無償利用の猶予期間終了が迫っている中、有償プランの利用について困っている方の助けになれば幸いです。

(なお、この記事は2022/01/20時点で弥生内で検討・試行した内容に基づいて作成したものであり、Docker社の提供するサービスについて正確な情報を提供することを目的としたものではありません。契約を行われる際は十分な調査を行った上でご判断ください)

なぜ有償プランを契約するのか

Docker Desktopが使いたい

有償プランを契約する目的は、開発メンバーがDocker Desktopを使えるようにすること、ほぼそれだけです。
「Docker Desktopを利用せず、無償で利用できるツールの範囲でDockerを使い続ければよいのでは?」という考え方もあります。
実際、Web上にはDocker Desktopを使わずにDockerを使い続けるための手順が多数見つかります。
そのようにして有償プランを契約せずにDockerを利用し続けるという選択はありだと思います。
ですが、我々は有償プランを契約してDocker Desktopを利用した方がよいと考えました。
理由は以下です。

Dockerまわりのセットアップやトラブルシュートが簡単であるため

Docker Desktopは、それをインストールするだけで、Dockerの利用に必要なセットアップがほとんど完了します。
また、GUIのツール上から、稼働中のコンテナやpullしたイメージを管理できるため、DockerのCUI操作に不慣れなメンバーでもトラブルシュートが比較的容易です。
実際の開発チームでは、スキルや経験が様々なメンバーが参加しているため、簡単にセットアップやトラブルシュートが可能であるというメリットは大きいと考えます。

Windowsコンテナを利用したい場合、Docker Desktopがないと厳しそうであるため

弥生の新規プロダクトの開発では、Windowsコンテナを利用して機能を実装する可能性があります。
Windows 10/11にてWindowsコンテナを利用する場合、Microsoft公式の手順では、Docker Desktopをインストールする方法が案内されています
Web上を探せば、Docker Desktopを利用せずにWindowsコンテナを利用する手順も見つかりはするのですが、多少複雑な手順となりますし、またいつまでもその手順が有効とは限りません。
前述の理由と近いですが、開発メンバーがトラブル無く開発を続けられることを重視するならば、やはり公式の手順通り、Docker DesktopをインストールしてWindowsコンテナを利用した方がよいと考えました。

契約・運用のポイント

プラン選択は"Team"プランがよさそう

2022年1月現在、Dockerの有償プランには、"Pro"、"Team"、"Business"という3つのプランがあります。
どのプランでもDocker Desktopは利用できるため、一番安い"Pro"プランを選択したくなるのですが、企業で利用する場合、"Team"プランを選択するのが現実的だと考えています。

www.docker.com

企業でソフトウェアライセンスを管理・運用する場合、「必要な分を一括で購入し、必要なメンバーに付与し、不要なメンバーからは回収する」というようなオペレーションができないと、管理が面倒すぎて運用が難しいと思います。
"Pro"プランは、個人の商用開発をターゲットとしているためか、Docker ID(=ユーザーアカウント)のそれぞれにおいて支払情報(クレカ)を紐付けて支払いを行うような設計になっているようです。
5人以下程度の組織ならばどうにか運用できるかもしれませんが、それ以上となると管理は難しいでしょう。
"Team"プランであれば、"Seats"という形でライセンスがプールされ、個別のメンバーに着脱を行うことができるため、数十人規模での運用に耐えうると思います。

f:id:ucho_yayoi:20220120201731p:plain
"Team"プランでは利用しているSeatsが表示される。Seatsの増減も可能。

”Business"プランは、SSO機能などがあるようなので、より大規模な組織での運用に適しているのではないかと思います。
ただし、"Team"プランと比較して価格が跳ね上がることと、我々としてはそこまで高度な機能を必要としていないことから、候補としてあまり検討を行いませんでした。"Business"プランは日本の代理店での取り扱いを行っているので、興味のある方はお問い合わせをしてみるとよいかもしれません。

メンバーには業務用アカウントを取得してもらう

"Team"プランでは、Organizationというグループのようなものを作成し、そこにメンバーを招待して追加していきます(追加されるとSeatsが消費されます)。
招待を行う際、Docker IDまたはメールアドレスを指定して招待を送るのですが、我々はここで社用のメールアドレス宛てに招待を送り、その社用メールアドレスを使ってDocker IDを作成してもらう運用としました。
理由は以下です。

ライセンスの利用者を明確にするため

メールアドレスを指定して招待を行うと、そのメールアドレスを紐付けたDocker IDでなければ招待元のOrganizationに参加することができないようです。
このことを利用し、招待は社用メールアドレスに対してのみ行うようにすることによって、社内の開発メンバーだけが確実に会社のOrganizationに参加するようにしました。

f:id:ucho_yayoi:20220120200954p:plain
招待されたときのDocker ID作成画面には招待を受け取ったメールアドレスを入力する欄がある

個人利用と業務利用を分けるため

個人用のDocker IDを会社のOrganizationに追加してしまうと、個人でDockerを利用している際に、誤ってOrganization内のリポジトリへの出し入れを行ってしまい、セキュリティリスクにつながる恐れがあるのではないかと考えました。
個人用と業務用のDocker IDを別にすることによって、上記のようなリスクをあらかじめ軽減できるのではないかと思います。

台帳でアカウントを管理する

せっかく社用のメールアドレスを指定して招待を行ったものの、Organizationに追加されたDocker IDに紐付いているメールアドレスを見ることはできません。見ることができるのはID文字列とプロフィールのFull Nameだけです。
そのため、「誰のIDか識別できるようにするために、ID文字列やプロフィールに本名を入れるようにしよう!」などとしたくなるのですが、ID文字列とプロフィールは公開情報となるため、本名をインターネットに公開したくないメンバーに対してそのようなことを強要するべきではないと思います…。 そこで我々は、招待したメンバーから実際に作成したID文字列を教えてもらい、それを氏名やメールアドレスと合わせてスプレッドシートで台帳管理するという、アナログな解決策を採ることにしました。
ただ、結局は退社したメンバーをOrganizationから削除するなどの棚卸し作業が必要になるため、どのみち台帳管理のようなことは必要になると思います。
(もしかしたら"Business"プランでSSOを利用すれば、認証サーバー側でIDを無効化するだけでOK、となるのかもしれませんが、詳細はわかりません…)

おわりに

Dockerの有償プランを具体的にどのように運用していくかをご紹介しました。
このような有償ライセンスは、ライセンス費用そのものに加えて、運用のコストがかかるのがつらいところです。
みなさまも、運用上の工夫ポイントなどがありましたら、ぜひ共有いただけるとうれしいです。

お知らせ

弥生では一緒に働く仲間を募集しています! herp.careers