%201.svg){kind=logo}
「Docker」という言葉は、10年以上前からテクノロジー業界ではいたるところで聞かれるようになりました。Dockerは、Linuxシステム上で動作するアプリケーションをパッケージ化し、カーネルレベルの機能を使って（通常のプロセスと比較して）特別な分離を提供する新しくユニークな方法を世界に紹介した会社です。そしてそれ以来、ティッシュを "クリネックス "と呼んだり、検索エンジンを使うことを "ググる "と呼ぶように、コンテナに関連するものはすべて "Docker "と呼ばれるようになりました。
Docker（会社）は、このコア・テクノロジーにとどまらず、エンタープライズ向けの機能、オーケストレーション、そして世界で最も広く使われているコンテナ・レジストリであるDocker Hubにまで拡大しました。Dockerはまた、Dockerが最も得意とする開発者向けツールに焦点を当てた製品の販売も開始しました。
他の初期のイノベーターと同様に、Dockerは市場に最初に登場したかもしれませんが、彼らの製品はコンテナ化された本番環境を実際に構築し、維持するためにはもはや必要ありません。この記事では、Dockerに代わる主要なコンテナ技術、特にオープンソースを探ります。また、代替案を採用できるようにするために、プロセスを変更する必要があるとすれば、それは何なのかについても説明します。
コンテナ構築ツール
ほとんどの人は、コンテナイメージをビルドするデフォルトの方法として docker build を使用しています。これは "Dockerfile "という名前のファイルに依存しており、コンテナにパッケージ化するアプリケーションのルートディレクトリに存在します。Dockerfileには、FROMコマンドで指定された、ビルドを開始するための他のコンテナイメージが含まれています。そのベースイメージから、RUNとCMDを使用して一連のコマンドを実行し、コンテナ内にアプリケーションのレイヤを構築します。
https://youtu.be/wr4gpKBO3ug
＊Youtube設定で字幕を自動翻訳にし、日本語を選んでいただきますと日本語字幕でご覧いただけます
GoogleのKanikoを含め、Kubernetesクラスタ内でコンテナイメージをビルドできるDockerの代替ツールがいくつかあります。最も簡単な直接の代替はbuildahで、Docker CLIに存在するビルドコマンドをすべてミラーしています。さらに、buildahはコマンドラインからレイヤーごとにイメージをビルドできるため、単一のDockerfileを管理する必要がありません。ステップバイステップのビルド手順はこのチュートリアルにあります。
Dockerに慣れている人なら、アプリケーションをホストするディレクトリと、世界で最もシンプルなコンテナ（localhostにpingを送るだけ）を作成する以下のコマンドがわかるでしょう：
[example@rhel8 ~]$ mkdir container
[example@rhel8 ~]$ cd container/
[example@rhel8 container]$ cat >> Dockerfile << EOF
> FROM alpine:latest
> CMD ping localhost
> EOF
[example@rhel8 container]$ buildah bud .
STEP 1: FROM alpine:latest
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob 59bf1c3509f3 done
Copying config c059bfaa84 done
Writing manifest to image destination
Storing signatures
STEP 2: CMD ping localhost
STEP 3: COMMIT
Getting image source signatures
Copying blob 8d3ac3489996 skipped: already exists
Copying blob 5f70bf18a086 done
Copying config 944addf7c4 done
Writing manifest to image destination
Storing signatures
--> 944addf7c4f
944addf7c4f494d11645e5e4e2d0a8ae3c70789aa283f9c4bc03c88cb453ec09
これでコンテナが構築されましたが、名前もタグもありません。2番目に表示されているコンテナ画像は、ベースとして使用するために自動的にダウンロードされた画像です。
[example@rhel8 container]$ buildah images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 944addf7c4f4 5 seconds ago 5.87 MB
docker.io/library/alpine latest c059bfaa849c 4 days ago 5.87 MB
注意: すべてのビルドツールはコンテナビルドのメインソースファイルとしてDockerfileを探しますが、業界のあるグループは代わりに "Containerfile "を標準にすることを推進し始めています。とはいえ、Dockerfileは当面すべてのツールで動作し続けるでしょう。
ランタイム
コンテナの起動に使用される最も一般的なランタイムはrunCとcontainerdの2つで、どちらもオープンソースであり、1つの企業によって管理されているわけではありません。これらはマシン上でデーモンとして実行され、必要に応じてコンテナの起動とシャットダウンを制御します。Docker自体は実際にはrunCをバックエンドとして使用しており、すべてオープンソースでOpen Container Initiative（OCI）によって管理されているため、Dockerの代替ソフトは必要ありません。
ランタイムに関しては、podmanやCRI-Oのような他のものについての言及を耳にすることがあるかもしれませんが、これらはバックグラウンドでOCI準拠のランタイムを呼び出すインターフェースを提供します。CRI-Oは非常に軽量で、Kubernetesクラスタ内で使用されるように構築されています。PodmanはDockerのコマンドラインツールの代替として構築されており、buildahと連携してその機能を提供します。
開発/デスクトップツール
開発マシン上のコンテナ管理や、マルチノードのオーケストレーション機能を必要としないワークロードにとって、PodmanがDockerの代替となるのです。
PodmanはDockerが持つ全てのコマンドライン機能を持ち、Linux、Mac、Windowsで利用可能です。デフォルトのランタイム（crun）はrootとして実行する別のデーモンを必要としないため、より優れたセキュリティプロファイルを持っています。Windows版とMac版はリモートクライアントで、DockerのようなローカルVMを使うことも、リモートホストに接続することもできます。
Podmanは基本的に、コマンドライン上でドロップインで置き換えられます。例えば、これは以前にビルドしたコンテナを実行しているところです：
[example@rhel8 container]$ podman run 944addf7c4f4
PING localhost (::1): 56 data bytes
64 bytes from ::1: seq=0 ttl=64 time=0.027 ms
64 bytes from ::1: seq=1 ttl=64 time=0.131 ms
64 bytes from ::1: seq=2 ttl=64 time=0.087 ms
64 bytes from ::1: seq=3 ttl=64 time=0.066 ms
64 bytes from ::1: seq=4 ttl=64 time=0.063 ms
64 bytes from ::1: seq=5 ttl=64 time=0.064 ms
^C
--- localhost ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.027/0.073/0.131 ms
バックグラウンドでコンテナを起動し、何が実行されているかを確認する方法も、Docker CLIで行うこととよく似ています。
[example@rhel8 container]$ podman run --detach 944addf7c4f4
5b4b3c7a25fad10c9238daa7c1dfa2afdf79fd065abbcd72a14ff44300b9f8ec
[example@rhel8 container]$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
5b4b3c7a25fa 944addf7c4f4 /bin/sh -c ping l... 2 seconds ago Up 3 seconds ago
より複雑なシナリオで運用する場合や、KinD（Kubernetes in Docker）を使わずにKubernetesを使って本番環境をシミュレートしたい場合は、microk8sやminikubeのようなKubernetesのマイクロディストリビューション、Rancher Desktop、CodeReady Containers（CRC）が非常に効果的です。どれもMac、Windows、Linuxをサポートしています。特にオペレーターのようなものをテストする場合は、デスクトップをできるだけ本番環境に近いものにしたほうがよいでしょう。
レジストリとリポジトリ
コンテナ業界では、この2つの用語をよく耳にします。簡単に言うと、リポジトリは実際にイメージを保存する場所であり、レジストリは複数のリポジトリにまたがるインデックスとして機能します。ほとんどの場合（Docker Hubと同様）、この2つは同じものです（つまり、レジストリは自分のリポジトリにしかアクセスしません）。
Docker Hubを使用することから離れたい場合（クォータを避けるためであれ、セキュリティ上の理由からオンプレミスで実行できるものが必要なためであれ）、複数の選択肢があります。
ホスティングされたサービスが必要であれば、Google Cloud上のContainer Registryのように、主要なパブリック・クラウドがすべて提供しています。クラウドにこだわらないのであれば、ソースコード管理プラットフォームにレジストリを組み込むのが理想的でしょう。GitHubには、packages機能で利用できるコンテナ・レジストリがあります（GitHub.comにあります）。
オンプレミスのソリューションでは、長年の業界リーダーであるSonaType Nexusがオープンソース版とプロフェッショナル版の両方を提供しています。JFrogのArtifactoryもこの分野での強力な候補です。Artifactoryは、セルフホスト型とクラウドデバイス型の両方があります。
OCIに準拠した代替コンテナ・リポジトリの登録は、1つのコマンドを実行するだけで簡単に行えます：
$ podman login acme-dockerv2-virtual.jfrog.io
Username: myusername
Password:
Login Succeeded!
コンテナ・レジストリに匿名アクセスがある場合は、ログインせずに直接引き出すことができます：
$ podman pull acme-dockerv2-virtual.jfrog.io/hello-world
コンテナのオーケストレーション
DockerでさえSwarmを売却し、Kubernetesを採用しているため、Dockerの技術に代わるものを見つけるにはここが一番簡単です。他のオーケストレーション・エンジンも存在しますが、業界の大半はKubernetesを選択しており、この分野では本当の競争相手はいません。2022年に向けて、実際に認定されたKubernetesディストリビューションは55、認定されたホスティングサービスは48あります。
Azure AKSのような基本的なサービスから、CIVOのような使いやすく開発者向けのサービス、SUSE RancherやRed Hat OpenShiftのような本格的なエンタープライズ向けディストリビューションまで、あらゆるニーズに対応するホステッドサービスやディストリビューションがあります。
コンテナの財団とオープンスタンダード
コンテナが登場するとほぼ同時に、複数の企業がDockerに準拠した技術の構築を開始しました。これは、Dockerが作成した仕様がLinuxカーネル内の既存の機能を活用していたためです。Dockerは時間の経過とともにこれらのグループに加わりました。
例えば、Dockerはコンテナ仕様とコアランタイムエンジン（runC）をOCIに寄付しました。また、DockerはCloud Native Computing Foundation（CNCF）にも参加しました。CNCFは、最も広く使われているコンテナ技術の多くに構造とガバナンスを提供しており、最も有名なのはKubernetesです。この領域がどれほど広がっているか知りたい場合は、CNCF Landscapeで何百ものものを見つけることができます。
Dockerはこれらのオープンな標準や基盤の中心的な貢献者であるため、Dockerのツールで構築されたコンテナは、他の組織のプロジェクトや製品と混在させることができます。
要約
OCI準拠のコンテナをサポートし、理想的にはKubernetesを使用して本番環境で実行できるツールであれば問題ありません。そうすれば、組織の要件を満たすのに問題はありません。セキュリティ・スキャンであれ、サーバーレス・アプリケーションであれ、エンタープライズ・フレンドリーなモニタリングであれ、このエコシステムで製品やサービスを見つけることができるでしょう。