Docker とは: 歴史と基本的な抽象化についての簡単な説明

10月XNUMX日からスラームでスタート Docker ビデオコースここでは、基本的な抽象概念からネットワーク パラメータに至るまで、それを完全に分析します。

この記事では、Docker の歴史とその主な抽象化である Image、Cli、Dockerfile について説明します。 この講義は初心者を対象としているため、経験豊富なユーザーには興味を持たれない可能性があります。 血液、虫垂、または深い水没はありません。 まさに基本。

ドッカーとは

Wikipedia から Docker の定義を見てみましょう。

Docker は、コンテナ化された環境でのアプリケーションのデプロイと管理を自動化するソフトウェアです。

この定義からは何も明らかではありません。 特に「コンテナ化をサポートする環境で」が何を意味するのかが不明瞭です。 それを知るために、時間を遡ってみましょう。 私が従来「モノリシック時代」と呼んでいた時代から始めましょう。

モノリシック時代

モノリシック時代とは 2000 年代初頭で、当時はすべてのアプリケーションがモノリシックであり、多くの依存関係がありました。 開発には長い時間がかかりました。 同時に、サーバーの数はそれほど多くはありませんでしたが、私たちはすべてのサーバーの名前を知っており、それらを監視していました。 こんな面白い比較があります。

ペットは家畜です。 モノリシック時代、私たちはサーバーをペットのように扱い、毛づくろいをして大切にし、塵を吹き飛ばしました。 また、リソース管理を改善するために、仮想化を使用しました。サーバーを複数の仮想マシンに分割し、それによって環境の分離を確保しました。

ハイパーバイザーベースの仮想化システム

VMware、VirtualBox、Hyper-V、Qemu KVM などの仮想化システムについては、誰もが聞いたことがあるでしょう。これらはアプリケーションの分離とリソース管理を提供しますが、欠点もあります。 仮想化を行うには、ハイパーバイザーが必要です。 そして、ハイパーバイザーはリソースのオーバーヘッドです。 そして、仮想マシン自体は通常、オペレーティング システム、Nginx、Apache、そして場合によっては MySQL を含む巨大なイメージです。 画像が大きく仮想マシンの操作が不便です。 その結果、仮想マシンの操作が遅くなる可能性があります。 この問題を解決するために、仮想化システムがカーネル レベルで作成されました。

カーネルレベルの仮想化システム

カーネル レベルの仮想化は、OpenVZ、Systemd-nspawn、LXC システムでサポートされています。 このような仮想化の顕著な例は、LXC (Linux Containers) です。

LXC は、単一ノード上で Linux オペレーティング システムの複数の分離されたインスタンスを実行するためのオペレーティング システム レベルの仮想化システムです。 LXC は仮想マシンを使用しませんが、独自のプロセス スペースとネットワーク スタックを備えた仮想環境を作成します。

基本的に LXC はコンテナを作成します。 仮想マシンとコンテナの違いは何ですか?

コンテナーはプロセスの分離には適していません。カーネル レベルで仮想化システムに脆弱性が見つかり、コンテナーからホストに逃れることができます。 したがって、何かを分離する必要がある場合は、仮想マシンを使用することをお勧めします。

仮想化とコンテナ化の違いは、図で確認できます。
ハードウェア ハイパーバイザー、OS 上のハイパーバイザー、およびコンテナーがあります。

本当に何かを分離したい場合には、ハードウェア ハイパーバイザーが最適です。 メモリページとプロセッサのレベルで分離できるためです。

プログラムとしてはハイパーバイザーがあり、コンテナーがあり、それらについてはさらに詳しく説明します。 コンテナ化システムにはハイパーバイザーはありませんが、コンテナを作成および管理するコンテナ エンジンがあります。 これはより軽量であるため、コアを使用するため、オーバーヘッドが少ないか、まったくありません。

カーネルレベルでのコンテナ化に使用されるもの

他のプロセスから分離されたコンテナーを作成できる主なテクノロジーは、名前空間とコントロール グループです。

名前空間: PID、ネットワーキング、マウント、およびユーザー。 他にもありますが、理解を容易にするためにこれらに焦点を当てます。

PID 名前空間はプロセスを制限します。 たとえば、PID 名前空間を作成し、そこにプロセスを配置すると、PID 1 になります。通常、システムでは PID 1 は systemd または init になります。 したがって、プロセスを新しい名前空間に配置すると、プロセスも PID 1 を受け取ります。

Networking Namespace を使用すると、ネットワークを制限/分離し、内部に独自のインターフェイスを配置できます。 マウントはファイル システムの制限です。 ユーザー - ユーザーの制限。

コントロールグループ: メモリ、CPU、IOPS、ネットワーク - 合計約 12 の設定。 それ以外の場合は、Cgroup (「C グループ」) とも呼ばれます。

コントロール グループは、コンテナーのリソースを管理します。 コントロール グループを通じて、コンテナーは一定量を超えるリソースを消費すべきではないと言うことができます。

コンテナ化を完全に機能させるには、機能、コピーオンライトなどの追加テクノロジーが使用されます。

ケイパビリティとは、プロセスに何ができるか、何ができないかを伝えるものです。 カーネル レベルでは、これらは多くのパラメーターを含む単なるビットマップです。 たとえば、root ユーザーは完全な権限を持ち、すべての操作を行うことができます。 タイム サーバーはシステム時刻を変更できます。Time Capsule にはタイム サーバーの機能があります。それだけです。 特権を使用すると、プロセスの制限を柔軟に構成できるため、自分自身を保護できます。

コピーオンライト システムを使用すると、Docker イメージを操作し、より効率的に使用できるようになります。

現在、Docker には Cgroups v2 との互換性の問題があるため、この記事では特に Cgroups v1 に焦点を当てます。

しかし、歴史に戻りましょう。

仮想化システムがカーネル レベルで登場すると、積極的に使用され始めました。 ハイパーバイザーのオーバーヘッドはなくなりましたが、いくつかの問題が残りました。

• 大きなイメージ: オペレーティング システム、ライブラリ、さまざまなソフトウェアの束を同じ OpenVZ にプッシュしますが、最終的にはイメージが依然として非常に大きいことが判明します。
• 梱包と配送には通常の標準がないため、依存関係の問題が残ります。 XNUMX つのコードが同じライブラリを使用しているが、バージョンが異なる場合があります。 それらの間に衝突が起こる可能性があります。

これらすべての問題を解決する次の時代が到来しました。

コンテナ時代

コンテナの時代が到来すると、コンテナを扱う哲学が変わりました。

• XNUMX つのプロセス - XNUMX つのコンテナー。
• プロセスに必要なすべての依存関係をコンテナーに配信します。 これには、モノリスをマイクロサービスに分割する必要があります。
• イメージが小さいほど、潜在的な脆弱性が少なくなり、ロールアウトが速くなります。
• インスタンスは一時的になります。

ペットと牛について私が言ったことを覚えていますか? 以前はインスタンスは家畜のようなものでしたが、今では牛のようなものになりました。 以前は、モノリス、つまり 100 つのアプリケーションがありました。 今では 100 個のマイクロサービス、2 個のコンテナーになります。 一部のコンテナーには 3 ～ XNUMX つのレプリカが含まれる場合があります。 すべてのコンテナを制御することはそれほど重要ではなくなります。 私たちにとってより重要なことは、サービス自体の可用性、つまりこのコンテナーのセットが何を行うかです。 これにより、モニタリングのアプローチが変わります。

2014 年から 2015 年にかけて、Docker が隆盛しました。これについては、これから説明します。

Docker は哲学を変更し、アプリケーションのパッケージ化を標準化しました。 Docker を使用すると、アプリケーションをパッケージ化し、リポジトリに送信し、そこからダウンロードしてデプロイできます。

必要なものはすべて Docker コンテナに入れたため、依存関係の問題は解決されました。 Docker は再現性を保証します。 多くの人が再現不能に遭遇したことがあると思います。すべてがうまく機能し、本番環境にプッシュすると、そこで動作が停止します。 Docker を使用すると、この問題は解決します。 Docker コンテナが起動して必要なことを実行すると、高い確率で実稼働環境でも起動し、そこで同じことを実行します。

オーバーヘッドについての余談

諸経費については常に論争が起きます。 Docker は Linux カーネルとコンテナ化に必要なすべてのプロセスを使用するため、追加の負荷はかからないと考える人もいます。 「Docker がオーバーヘッドだというなら、Linux カーネルもオーバーヘッドだ」というようなものです。

一方で、さらに詳しく見てみると、Docker には、オーバーヘッドと言えるものが実際にいくつかあります。

1 つ目は PID 名前空間です。 プロセスを名前空間に配置すると、そのプロセスには PID 1 が割り当てられます。同時に、このプロセスには、コンテナの外のホスト名前空間にある別の PID が割り当てられます。 たとえば、コンテナで Nginx を起動すると、PID 12623 (マスター プロセス) になりました。 そして、ホスト上では PID XNUMX になります。そして、それがどの程度のオーバーヘッドであるかを言うのは困難です。

XNUMX つ目は Cgroup です。 Cgroup をメモリ、つまりコンテナのメモリを制限する機能別に見てみましょう。 これを有効にすると、カウンタとメモリ アカウンティングがアクティブになります。カーネルは、このコンテナに割り当てられたページ数と、まだ空きページ数を把握する必要があります。 これはオーバーヘッドである可能性がありますが、それがパフォーマンスにどのような影響を与えるかについての正確な研究は見たことがありません。 そして、私自身も、Docker で実行されているアプリケーションのパフォーマンスが突然急激に低下したことに気づきませんでした。

そして、パフォーマンスについてもう XNUMX つ注意してください。 一部のカーネル パラメーターはホストからコンテナーに渡されます。 特に、いくつかのネットワークパラメータ。 したがって、Docker で高性能なもの、たとえばネットワークを積極的に使用するものを実行したい場合は、少なくともこれらのパラメーターを調整する必要があります。 たとえば、nf_conntrack などです。

Docker の概念について

Docker はいくつかのコンポーネントで構成されています。

1. Docker デーモンは同じコンテナ エンジンです。 コンテナを起動します。
2. Docker CII は、Docker 管理ユーティリティです。
3. Dockerfile - イメージを構築する方法についての説明。
4. イメージ — コンテナーのロールアウト元のイメージ。
5. 容器。
6. Docker レジストリはイメージ リポジトリです。

概略的には次のようになります。

Docker デーモンは Docker_host 上で実行され、コンテナーを起動します。 コマンドを送信するクライアントがあります: イメージのビルド、イメージのダウンロード、コンテナーの起動。 Docker デーモンはレジストリにアクセスしてそれらを実行します。 Docker クライアントは、ローカルに (Unix ソケットに) アクセスすることも、リモート ホストから TCP 経由でアクセスすることもできます。

各コンポーネントを見てみましょう。

ドッカーデーモン - これはサーバー部分であり、ホスト マシン上で動作します。イメージをダウンロードしてそこからコンテナを起動し、コンテナ間にネットワークを作成し、ログを収集します。 私たちが「イメージを作る」と言うとき、悪魔もそれを行っています。

Docker CLI — Docker クライアント部分、デーモンを操作するためのコンソール ユーティリティ。 繰り返しますが、ローカルだけでなくネットワーク経由でも機能します。

基本的なコマンド:

docker ps - Docker ホスト上で現在実行されているコンテナーを表示します。
docker イメージ - ローカルにダウンロードされたイメージを表示します。
docker search <> - レジストリ内のイメージを検索します。
docker pull <> - レジストリからイメージをマシンにダウンロードします。
ドッカービルド < > - 画像を収集します。
docker run <> - コンテナを起動します。
docker rm <> - コンテナを削除します。
docker ログ <> - コンテナー ログ
docker start/stop/restart <> - コンテナーの操作

これらのコマンドをマスターし、自信を持って使用できる場合は、ユーザー レベルで Docker の 70% に習熟していると考えてください。

ドッカーファイル - イメージを作成するための手順。 ほぼすべての命令コマンドは新しいレイヤーです。 例を見てみましょう。

Dockerfile は次のようになります。左側にコマンド、右側に引数があります。 ここにある (そして通常は Dockerfile に記述される) 各コマンドは、Image に新しいレイヤーを作成します。

左側を見ても大体何が起こっているかが分かります。 「フォルダーを作成してください」と言いますが、これは XNUMX つのレイヤーです。 「フォルダーを機能させる」は別のレイヤーであり、以下同様です。 レイヤーケーキは生活を楽にしてくれます。 別の Dockerfile を作成し、最後の行で何かを変更した場合 (「python」「main.py」以外のものを実行したり、別のファイルから依存関係をインストールしたりした場合)、以前のレイヤーがキャッシュとして再利用されます。

画像 - これはコンテナ パッケージングです。コンテナはイメージから起動されます。 パッケージ マネージャーの観点から Docker を見た場合 (deb または rpm パッケージを操作しているかのように)、image は本質的に rpm パッケージです。 yum install を使用すると、アプリケーションのインストール、削除、リポジトリ内での検索、ダウンロードを行うことができます。 ここでもほぼ同じです。コンテナはイメージから起動され、Docker レジストリ (リポジトリ内の yum と同様) に保存され、各イメージには SHA-256 ハッシュ、名前、タグが付けられます。

イメージは Dockerfile の指示に従って構築されます。 Dockerfile からの各命令により、新しいレイヤーが作成されます。 レイヤーは再利用できます。

Docker レジストリ Docker イメージ リポジトリです。 OS と同様に、Docker にはパブリック標準レジストリ dockerhub があります。 ただし、独自のリポジトリ、独自の Docker レジストリを構築することはできます。

コンテナ - 画像から発射されるもの。 Dockerfile の指示に従ってイメージを構築し、このイメージから起動します。 このコンテナは他のコンテナから分離されており、アプリケーションが機能するために必要なものがすべて含まれている必要があります。 この場合、XNUMX つのコンテナーに XNUMX つのプロセスが含まれます。 たまたま XNUMX つのプロセスを実行する必要がありますが、これは Docker のイデオロギーに多少反しています。

「1 つのコンテナー、XNUMX つのプロセス」要件は、PID 名前空間に関連しています。 PID XNUMX のプロセスが名前空間で開始されたときに、そのプロセスが突然停止すると、コンテナ全体も停止します。 そこで XNUMX つのプロセスが実行されており、XNUMX つは生きており、もう XNUMX つは死んでいる場合でも、コンテナーは引き続き生き続けます。 ただし、これはベスト プラクティスの問題であり、他の資料で説明します。

コースの特徴と完全なプログラムをさらに詳しく調べるには、次のリンクをクリックしてください。Docker ビデオコース'。

著者: Marcel Ibraev、認定 Kubernetes 管理者、Southbridge の現役エンジニア、Slurm コースの講演者および開発者。

出所： habr.com