ゲストブログ:DockerデスクトップとDIYソリューションのどちらを選択するか

ゲスト著者の Ben Hall は、 gov.uk (英国の公的機関の情報 Web サイト) で C# .NET の主任技術開発者であり、.NET Foundation のメンバーでもあります。 彼は学校の教師として9年間働き、プログラミングとコンピューターサイエンスをカバーしました。 Ben は、忙しい開発者が複雑なトピックをアクセスしやすく実用的なものにすることを楽しんでいます。

DockerデスクトップとDIYソリューションのどちらを選択するか

Docker エクスペリエンスの中心にあるのは Docker Engine です。 コンテナ化されたアプリケーションを構築するためのDocker Desktopのすぐに使用できるソリューションには、Docker Engineと、すぐに開発を開始するために必要な他のすべてのツールとセットアップが含まれています。

開発者は、Docker Engine に関する "DIY" Docker 実装を手動で作成できます。 一部の組織では、自分で行う柔軟性と制御を好む場合があります。 しかし、DIY Dockerエンジンソリューションを選択するには、はるかに多くのエンジニアリング、開発、およびセットアップが必要です。 DockerとそのWindowsコンパニオンであるWSLは比較的複雑であるため、DIYアプローチはすべての人に適しているわけではありません。

この記事では、あなたとあなたの組織に適したアプローチを決定するのに役立ちます。 説明のために、Docker Desktopが提供するものとWindowsでのDIY Dockerセットアップを比較します。

ウィンドウズでのドッカーのセットアップ

failingfast.io に関するこの記事では 、WSL 2 ディストリビューションの作成、Docker リポジトリのセットアップ、WSL 2 ディストリビューションへの Docker エンジンの追加セットアップのインストールなど、Windows での手動インストールの主な手順について説明します。このプロセスは少し壊れやすいので、起動して実行する前にトラブルシューティングの準備をしてください。 そして、それは 始めるためのガイドにすぎません。 ほとんどのユースケースでは、次のような追加の設定が必要です。

• 起動時に起動するように Docker を構成する
• 伐採
• リモートホストからの Docker デーモンへの接続の受け入れ
• リモート アクセスの構成
• IP 転送の問題の解決

Dockerデスクトップのセットアップは、非常に異なるエクスペリエンスです。 最新のDockerデスクトップインストーラー をダウンロードして 実行するだけで、すべての作業が自動的に完了します。 数分で稼働し、コンテナをデプロイする準備が整いました。

最先端で安定

Docker Desktop とリンクした DIY 実装は、開発者が Windows 環境を直接 Windows 上で実行できるようにする Windows Subsystem for Linux (WSL) 2 上の共通の基盤を共有しています。

WSL 2 では、メモリ使用量、コード実行、互換性が大幅に向上しました。 これは、エミュレーションなしでネイティブに実行されるLinuxコンテナをサポートする完全なLinuxカーネルへのアーキテクチャの移行によって実現されました。

MicrosoftおよびWindows Insiderと緊密に連携して、Dockerはこの有益な新しいテクノロジーをDocker Desktopの主要なバックエンドとしてすぐに採用しました。 その後、Docker は、WSL 2 が Windows で一般公開されるずっと前にテクニカル プレビューをリリースしました。 また、Hyper-V を使用していた以前のバージョンと同等の機能を維持するために、あらゆる努力が払われました。

Docker Desktopを開発者ツールに追加して、慣れ親しんだエクスペリエンスの重大な変更を回避しながら、最新のテクノロジーを引き続きサポートすることを確信できます。

ソフトウェアの更新

Dockerデスクトップは、セットアップから将来のカーネルパッチまで、すべてを管理します。 また、これは完全な バンドルであるため、自動ソフトウェアアップデートにより、Dockerエンジン自体を含め、インストールされているすべてのツールが最新かつ安全に保たれます。これにより、社内で管理するマシンイメージが1つ少なくなります。

DIY Dockerのセットアップでは、すべてのセキュリティパッチやその他の更新に追いつくのはあなた次第です。 DIYソリューションは、解決する必要のある進行中の問題もたくさん提供します。 そのため、Docker Desktop の ROI を計算するときは、大規模な組織全体でこれらの開発者の時間を掛けるようにしてください。

ネットワーキング

Docker デスクトップは、コンテナーをプルするときに使用する構成済みの HTTP/HTTPS プロキシ設定を Docker に自動的に伝達します。

また、VPNに接続しても正しく機能します。 これは、コンテナーからのトラフィックをインターセプトし、Docker アプリケーション自体から発生したかのように Windows に挿入することで実現されます。

一時停止と再開

この機能は、Docker デスクトップの パブリック ロードマップ のユーザーから要求されました。 これはこれまでで最大の機能ではありませんが、Dockerデスクトップが活発に開発されていることを思い出させるもう1つの優れた機能です。 ユーザーからのフィードバックに応えて継続的に改善され、毎月のリリースで実装されています。

ユーザーは Docker デスクトップ セッションを一時停止して、CPU 使用率を減らし、バッテリー寿命を節約できるようになりました。 一時停止すると、すべてのコンテナーの現在の状態がメモリに保存され、すべてのプロセスがフリーズされます。

Volume Management

ボリュームは、コンテナー間で共有されるファイルなど、Docker コンテナーが処理するデータを永続化するための標準的なアプローチです。 ホストマシンファイルを直接操作する バインドマウントとは異なり、ボリュームはDockerによって管理されるため、いくつかの 利点があります。

Docker CLI で Docker ボリュームを手動で操作する場合、次の 2 つの大きな課題に直面します。

• 各ボリュームがどのコンテナーに属しているかを識別するのは難しい場合があるため、古いボリュームのクリアは時間がかかる可能性があります。
• ボリュームの内外へのコンテンツの転送は、実際よりも複雑です。

Docker Desktop は、ボリュームを探索するためのビューをダッシュボードに提供することで、このためのソリューションを提供します。 このビューでは、次のことができます。

• 使用されているボリュームを簡単に特定 
• ボリュームを使用しているコンテナーを確認する
• ボリュームの作成と削除
• ボリューム内のファイルとフォルダー (ファイル サイズを含む) の探索
• ボリュームからのファイルのダウンロード
• 名前、日付、サイズで検索および並べ替え

Kubernetes Integration

1つの記事で調べるには機能が多すぎますが、DockerデスクトップでのKubernetesの統合を確認する必要があります。

Kubernetesはコンテナオーケストレーションの標準になり、 2020年のCNCF調査 の回答者の83%が本番環境で使用していると報告しています。

確かに、ホストシステムからの分離など、ローカル開発でDockerのメリットを享受するためにKubernetesは必要ありません。 さらに、Docker Compose 2.0を使用して、いくつかの気の利いたネットワーク機能を備えた複数のコンテナを実行することもできます。 ただし、運用環境の Kubernetes にデプロイするプロジェクトに取り組んでいる場合は、同様の環境をローカルで使用するのが賢明な選択です。

以前は、ローカルの Kubernetes インスタンスは別の設定であり、開発者の時間のコストは一部のユーザーに十分なメリットを提供していませんでした。 これは、DIY Dockerソリューションにも当てはまる可能性があります。

対照的に、Docker Desktop には、ローカルテスト用のスタンドアロンの Kubernetes サーバーとクライアントが付属しています。 これは、単純で構成不要の単一ノード クラスターです。 下の画像に示すように、UIを介して、またはkubectl構成の使用コンテキストを使用して通常の方法で切り替えることができます。

ネイティブアップルシリコンサポート

2021年、最新のM1チップを完全に 活用できるバージョンのDockerデスクトップ用Macが一般公開されました。Docker Hub には既に 145,000 を超える ARM ベースのイメージがあります。この Apple シリコン バージョンはマルチプラットフォーム イメージをサポートしているため、複雑なクロスコンパイル環境なしで x86 および ARM アーキテクチャ用のイメージをビルドして実行できます。

多くの一般的なアプリケーションに許容できる機能を提供するRosetta 2が提供するエミュレーションは、コンテナを実行するのに十分ではないため、これは非常に好評でした。

コストとスケーラビリティ

DIYの代替手段では、コンテナ環境の更新、パッチ適用、トラブルシューティングのための継続的なメンテナンスコミットメントとともに、構築と構成に多大なエンジニアリング時間が必要です。 組織内の各開発者は、新しい環境で作業するたびに、この作業のほとんどを個別に実行します。 

このアプローチはうまく拡張できません! これは、開発者が新機能など、ビジネスに直接利益をもたらす活動に時間を費やすことがないことを意味します。 開発環境の問題や設定作業のために機能を提供しなかったことを説明しなければならないスプリントレビューを楽しんでいる人は誰もいません。

コンテナ化は、製品の配送を容易にするのに役立つはずです。 Docker Desktopが達成しようとしていることは新しいものではありません。 私たちは常に、生産性を向上させるために、単一のユーザーフレンドリーなパッケージに機能をバンドルするIDEやその他のツールのプログラミングに投資してきました。

コストの観点から Docker Desktop が組織に適しているかどうかを判断するのに役立つように、Jeremy Castile は ROI の評価に役立つガイダンスをいくつか用意しています。

複数の環境での作業

開発者は、ビルドアーティファクトは不変でなければならないことを広く受け入れています — ビルドされた同じアプリケーションは、QAを介して本番環境に移行する必要があります。 次のレベルは、必要に応じて、アプリケーション とその 依存関係を一緒にパッケージ化することです。 これにより、開発環境、テスト環境、および運用環境間の一貫性をさらに維持できます。

プロセスが複雑すぎると、この利点を実現できないリスクがあります。 組織は多くの優れたツールとプロセスをチームに導入しましたが、必要なスキルのエントリーバーが高すぎるため、これらのツールがほこりを集めるだけです。

この状況は、QAチームでより顕著です。 多くのテスターは技術的ですが、より一般的には 、テスト向けの特定のスキルセットを持っています。QAは、一貫性のあるテスト環境から大きな恩恵を受ける1つのグループセットであるため、使用する可能性が最も高いものを検討してください。

開発環境の紹介

これらのシナリオのエクスペリエンスをさらに向上させるために、Docker Desktop には、現在プレビュー段階にある開発環境と呼ばれる新しい共同開発機能が追加されました。

git ブランチまたは環境を切り替えるには、通常、コードを実行する前に、構成、依存関係、およびその他の環境のセットアップを手動で変更する必要があります。

この新機能を使用すると、コードを使用して環境の詳細自体をソース管理に簡単に保持できます。 ボタンをクリックするだけで、開発者はDocker Hubを介して進行中の作業 とその 依存関係を共有できます。 つまり、開発者は互いの作業の完全に機能するインスタンスに簡単に切り替えて、たとえば、ローカルブランチから変更することなくプルリクエストを完了し、それらの環境をすべて変更することができます。

開発環境の使用を開始するには、プレビュー ドキュメントを参照してください。

結論

Dockerについて執筆している著者のBret Fisher氏は、Docker Desktopの必要性を 要約 しています:「これは、macOS/Windows上のローカルLinuxコンテナに匹敵するツールがなく、コンテナランタイムから通常必要なものの80%をローカルで解決するツールがないことをDocker Desktopの証です」と述べています。

Dockerデスクトップが提供するものとその過程で調査しました。 また、コストとROI、セットアップとメンテナンス、スケーラビリティ、オンボーディングについても触れました。 DIY Dockerの柔軟性と制御を好む人もいますが、Docker Desktopはセットアップの労力とメンテナンスが少なくて済み、開発からQAまでのすべての人に穏やかな学習曲線を提供します。

おそらく、DIYソリューションの最大の課題は、ビジネス価値の観点からです。 開発者は、これらのことを行う方法を発見するのが大好きです。 したがって、開発者は必ずしもDIYソリューションの維持に1週間以上費やした時間を追跡するとは限らず、ビジネスは生産性の低下を可視化できません。
Windows または macOS 上の Docker を使用したローカル開発に DIY ソリューションをまだ使用している場合は、 Docker Desktop の詳細を確認し 、ダウンロードして開始してください。