Linuxコンテナー：技術的ブレークスルーとしての分離

さらに、作業環境が特定の構成を持つラップトップでアプリケーションを開発していると想像してください。 アプリケーションはこの構成に依存し、コンピューター上の特定のファイルに依存します。 他の開発者は、構成がわずかに異なる場合があります。 さらに、組織には独自の構成とファイルセットを備えたテスト環境と産業環境があります。 これらの環境を可能な限り正確にエミュレートする必要がありますが、マシン上で複雑で重いサーバーを絶対に使用したくない場合があります。 すべての環境でアプリケーションを動作させ、品質管理に合格して、絶え間ないコードの改善を必要とする道路上の多くの問題に遭遇することなく本番に入る方法は？







回答：コンテナを使用してください。 コンテナにはアプリケーションと一緒に、必要なすべての構成（およびファイル）が含まれているため、副作用を心配することなく、開発環境からテスト環境に、さらに産業環境に簡単に転送できます。 危機は解消され、すべてが利益を得ることです。



もちろんこれは単純化された例ですが、Linuxコンテナを使用すると、アプリケーションの移植性、カスタマイズ、分離に関連する多くの問題に実際に対処できます。 ローカルITインフラストラクチャ、クラウド、またはそれらに基づくハイブリッドソリューションのいずれであっても、コンテナは効率的に仕事を行うことができます。 もちろん、コンテナ自体に加えて、適切なコンテナプラットフォームの選択が重要です。

Linuxコンテナーとは

Linuxコンテナは、オペレーティングシステムの他の部分から分離されたプロセスのセットであり、その操作に必要なすべてのファイルを含む別のイメージから起動されます。 イメージにはすべてのアプリケーションの依存関係が含まれているため、開発環境からテスト環境へ、そして産業環境へ簡単に転送できます。

それは単なる仮想化ではありませんか？

はい、いいえ。 このアプローチは以下を理解するのに役立ちます。

• 仮想化により、1台のコンピューターで複数のオペレーティングシステムを同時に操作できます
• コンテナは同じオペレーティングシステムカーネルを使用し、アプリケーションプロセスをシステムの他の部分から分離します。

これはどういう意味ですか？ まず、1つのハイパーバイザー（仮想化を実装するプログラム）で複数のオペレーティングシステムを同時に操作するには、コンテナーに基づく同様の構成よりも多くのシステムリソースが必要です。 原則として、リソースは無制限ではありません。したがって、アプリケーションの「重量」が少ないほど、サーバーに配置できる密度が高くなります。 コンピューター上で実行されるすべてのLinuxコンテナーは同じオペレーティングシステムを使用するため、アプリケーションとサービスは軽量のままであり、互いに干渉することなく並行して実行されます。

コンテナの簡単な歴史

コンテナの先祖は、2000年に登場したFreeBSD Jailテクノロジーと考えることができます。 同じFreeBSDオペレーティングシステム内で、独自のカーネル、いわゆる「jailセル」で実行する複数の独立したシステムを作成できます。 カメラは、管理者が内部ユーザーまたは外部クライアントに安全に提供できる独立した環境として考えられていました。 カメラはchroot呼び出しに基づいて構築され、ファイル、ネットワーク、およびユーザーを含む仮想環境であるため、プロセスはカメラを超えてメインOSを損傷することはできません。 ただし、設計上の制限により、Jailメカニズムはまだプロセスを完全に分離しておらず、時間が経つにつれて、カメラから「エスケープ」する方法が登場しました。



しかし、そのアイデア自体は有望であり、2001年には、 VServerプロジェクトがLinuxプラットフォームに登場し、 創業者のジャックジェリナスによれば 、「高度な独立性を備えた1台のマシンで複数の標準Linuxサーバーを実行する」とセキュリティ。」 このように、Linuxは並列ユーザー環境の実装の基盤となり、現在コンテナと呼ばれるものが徐々に出現し始めました。

実用化への道

分離に向けた主要かつ迅速なステップは、既存のテクノロジーの統合でした。 特に、Linuxカーネルレベルで動作し、プロセスまたはプロセスのグループによるシステムリソースの使用を制限するcgroupsメカニズムと、ユーザースペースの作成とプロセスの起動を担当するsystemd初期化システム。 これらのメカニズムの組み合わせは、もともとLinuxの全体的な管理性を向上させるために作成されたもので、孤立したプロセスをより適切に制御し、環境を適切に分離するための基盤を築きました。



コンテナの歴史における次のマイルストーンは、 ユーザー名前空間の開発に関連しています 。これにより、名前空間の内部と外部のプロセスに割り当てられたユーザーとグループの識別子を分離できます。 コンテナのコンテキストでは、これは、ユーザーとグループがコンテナ内で特定の操作を実行する権限を持つことができることを意味しますが、コンテナの外部ではできません。 これは、Jailの概念に似ていますが、追加のプロセス分離により安全です。



その後、 Linux Containersプロジェクト （LXC）仮想化システムが登場しました。この仮想化システムは、非常に人気の高いツール、テンプレート、ライブラリ、言語サポートツールを多数提供し、実際のコンテナーの使用を大幅に簡素化しました。

Dockerの外観

2008年には、Docker（当時dotCloudと呼ばれていました）が同じ名前のテクノロジーで登場し、LXCの成果と開発者向けの高度なツールを組み合わせ、コンテナーの使用をさらに促進しました。 今日、Dockerオープンソーステクノロジは、Linuxコンテナの展開と管理のための最も有名で人気のあるツールです。



他の多くの企業と同様に、Red HatとDockerは、コンテナ技術管理標準の統一を目的とするOpen Container Initiative（OCI）プロジェクトの参加者です。

標準化とオープンコンテナーイニシアティブ

Open Container Initiativeプロジェクトは、 Linux Foundationが後援しています。 2015年に「コンテナ形式とランタイムのオープンな業界標準を作成するために」設立されました。 現在、彼の主な仕事は、コンテナイメージとランタイムの仕様を開発することです。



ランタイム仕様は、ファイルシステムバンドルの構成と構造、およびランタイムがこのバンドルを展開する方法を記述するオープンスタンダードのセットを定義します。 基本的に、コンテナが意図したとおりに機能し、必要なリソースがすべて利用可能で適切な場所に配置されるように、この仕様が必要です。



コンテナイメージの仕様は、「イメージマニフェスト、ファイルシステムのシリアル化、およびイメージ構成」の標準を定義しています。

これら2つの仕様を組み合わせて、コンテナイメージ内の内容、およびコンテナの正常な実行に必要な依存関係、環境、引数、その他のパラメータを定義します。

抽象化としてのコンテナ

Linuxコンテナーは、アプリケーションの開発、展開、および保守方法の開発における別の進化的なステップです。 移植性とバージョン管理を提供するコンテナイメージにより、アプリケーションが開発者のコ​​ンピューターで実行される場合、産業環境で動作することが保証されます。



Linuxコンテナは、仮想マシンと比較して要求されるシステムリソースが少なく、分離機能がほぼ劣っており、複合マルチレベルアプリケーションのメンテナンスを大幅に促進します。



Linuxコンテナの意味は、開発をスピードアップし、発生するビジネス要件に迅速に対応できるようにすることであり、新たな問題を解決するための特定のソフトウェアを提供することではありません。 さらに、アプリケーション全体をコンテナにパッケージ化できるだけでなく、アプリケーションとサービスの個々の部分をパッケージ化してから、 Kubernetesなどのテクノロジーを使用して、そのようなコンテナ化されたアプリケーションを自動化および編成できます。 つまり、すべてのアプリケーションロジック、ランタイムコンポーネント、および依存関係が1つのコンテナにあるモノリシックソリューションを作成したり、マイクロサービスとして機能する多くのコンテナから分散アプリケーションを構築したりできます。

工業用コンテナ

コンテナは、産業環境でコンテナを使用する顧客へのソフトウェアとアプリケーションの配信を促進する優れた方法です。 しかし、これは当然責任とリスクを増大させます。 コンテナを安全に保つ方法は、Red HatセキュリティストラテジストのJosh Bresser氏は述べています。



「私は非常に長い間セキュリティの問題に取り組んできましたが、技術やアイデアが主流になるまで、ほとんどの場合、それらは十分な重要性を与えられていません」とBresserは文句を言います。 -誰もがこれが問題であることに同意しますが、それが世界の仕組みです。 今日、コンテナが世界を席巻しており、全体的なセキュリティ状況における位置が明らかになり始めています。 コンテナは特別なものではなく、単なる別のツールです。 しかし、今日、彼らは注目を浴びているので、彼らの安全性について話す時が来ました。



少なくとも1週間に1回は、コンテナでワークロードを実行することが安全であることを保証しているので、中身について心配する必要はありません。 実際、すべてが完全に間違っており、そのような態度は非常に危険です。 コンテナ内のセキュリティは、ITインフラストラクチャの他の場所のセキュリティと同様に重要です。 コンテナはすでにここにあり、驚くほどの速度で積極的に使用され配布されています。 ただし、それらにはセキュリティの魔法はありません。 コンテナは、その中身と同じくらい安全です。 したがって、コンテナに脆弱性の束が含まれている場合、結果は同じ脆弱性の束を持つ「ベアアイロン」の場合とまったく同じになります。

コンテナセキュリティの何が問題になっていますか

コンテナ技術は、コンピューティング環境に対する見方を変えています。 新しいアプローチの本質は、必要なものだけが含まれており、必要なときにのみ起動するイメージがあることです。 無関係なソフトウェアはインストールされていませんが、その理由は明らかではなく、大きなトラブルを引き起こす可能性があります。 セキュリティの観点から、これは「攻撃面」と呼ばれます。 コンテナ内で実行されているあらゆる種類のものが少ないほど、このサーフェスは小さくなり、セキュリティは高くなります。 ただし、コンテナ内で実行されているプログラムがほとんどない場合でも、コンテナの内容が古くなく、脆弱性が充満していないことを確認する必要があります。 深刻なセキュリティの脆弱性があるものが内部にインストールされている場合、攻撃対象領域のサイズは重要ではありません。 コンテナは全能ではなく、セキュリティの更新も必要です。



Banyanは、「 Docker Hubの公式画像の30％以上に重大度の高いセキュリティ脆弱性があります」というタイトルのレポートを公開しました。 30％が多い。 Docker Hubはパブリックレジストリであるため、さまざまな人々によって作成された大量のコンテナーが含まれています。 そして、だれでもそのようなレジストリにコンテナを配置できるため、新しく公開されたコンテナに古い「穴あき」ソフトウェアが含まれていないことを誰も保証できません。 Docker Hubは祝福と呪いの両方です。 一方では、コンテナを操作する際に多くの時間と労力を節約しますが、他方では、ロードされたコンテナに既知のセキュリティ脆弱性が含まれていないという保証はありません。



これらの脆弱な画像のほとんどは悪意のあるものではなく、悪意を持って「穴のあいた」ソフトウェアを組み込んだものはありません。 誰かが一度にソフトウェアをコンテナに詰めて、Docker Hubに投稿しました。 時間が経つにつれて、ソフトウェアに脆弱性が発見されました。 そして、誰かがこれに従わずに更新を行う限り、Docker Hubは引き続き脆弱なイメージの温床になります。



コンテナを展開するとき、基本的なイメージは通常レジストリから「プル」されます。 これが公開レジストリである場合、対処する内容を常に理解できるとは限らず、場合によっては非常に深刻な脆弱性を含むイメージを取得することもできません。 コンテナの内容は本当に重要です。 そのため、多くの組織が、コンテナーイメージの内部を調べて、見つかった脆弱性について報告するスキャナーを作成し始めています。 しかし、スキャナーはソリューションの半分にすぎません。 結局のところ、脆弱性が見つかった後は、セキュリティ更新プログラムを見つけてインストールする必要があります。



もちろん、サードパーティのコンテナを完全に放棄して、独自に開発し、独自に管理することもできますが、これは非常に難しい決定であり、主要なタスクと目標から真剣にそらされる可能性があります。 したがって、コンテナの安全性を理解し、対応する問題を解決できるパートナーを見つけて、本当に必要なものに集中できるようにすることをお勧めします。

Red Hat Container Solutions

Red Hatは、Linuxコンテナを実装するための完全に統合されたプラットフォームを提供します。これは、小さなパイロットプロジェクトや、コンテナが動作するホストのオペレーティングシステムから、独自のアプリケーションを構築するための検証済みコンテナイメージまで、オーケストレーションされたマルチコンテナアプリケーションに基づく複雑なシステムに適しています産業用コンテナ環境向けの同じオーケストレーションプラットフォームとコントロール。

インフラ

• ホスト
  
  Red Hat Enterprise Linux （RHEL）は、信頼と認定の点で世界的に高い評価を得ているLinuxディストリビューションです。 コンテナ化されたアプリケーションのサポートのみが必要な場合は、専用のRed Hat Enterprise Linux Atomic Hostディストリビューションを使用できます。 コンテナーソリューションと分散システム/クラスターの作成を提供しますが、RHELにある汎用オペレーティングシステムの機能は含まれません。
• コンテナ内
  
  コンテナ内でRed Hat Enterprise Linuxを使用すると、RHELプラットフォームにデプロイされた通常のコンテナ化されていないアプリケーションがコンテナ内でも同じように機能します。 組織自体がアプリケーションを開発する場合、コンテナ内のRHELを使用すると、コンテナ化されたアプリケーションの使い慣れたレベルの技術サポートと更新を維持できます。 さらに、移植性が提供されます。つまり、アプリケーションは、開発者のマシンからクラウドまで、RHELが存在する場所であれば問題なく動作します。
• データウェアハウス
  
  コンテナには大量のストレージスペースが必要になる場合があります。 さらに、設計上の欠陥が1つあります。コンテナがクラッシュすると、コンテナ内のステートフルアプリケーションはすべてのデータを失います。 Red Hat OpenShiftプラットフォームと統合されたRed Hat Gluster Storageソフトウェアは、コンテナ化されたアプリケーションに柔軟な管理ストレージを提供し、独立したストレージクラスターを展開したり、従来のモノリシックストレージシステムのコストのかかる拡張にお金を費やす必要がありません。
• Infrastructure-as-a-Service（IaaS）
  
  Red Hat OpenStack Platformは、物理サーバー、仮想マシン、およびコンテナーを1つの統合プラットフォームに結合します。 その結果、コンテナテクノロジとコンテナ化されたアプリケーションはITインフラストラクチャに完全に統合され、テクノロジスタック全体で完全な自動化、セルフサービス、およびリソースクォートを行うことができます。

プラットフォーム

• コンテナアプリケーションプラットフォーム
  
  Red Hat OpenShiftプラットフォームは、 DockerやKubernetesなどの主要なコンテナーテクノロジーをエンタープライズクラスのRed Hat Enterprise Linuxオペレーティングシステムと統合します。 このソリューションは、プライベートクラウドまたはパブリッククラウド環境（Red Hatの部隊をサポートする機能を含む）に展開できます。 さらに、ステートフルアプリケーションとステートレスアプリケーションの両方をサポートし、既存のアプリケーションのアーキテクチャ処理を行わずにコンテナ化された翻訳を提供します。
• オールインワンソリューション
  
  一度にすべてを取得したほうが良い場合もあります。 コンテナアプリケーション開発プラットフォーム、プライベートクラウドを構築するためのインフラストラクチャコンポーネント、パブリッククラウド環境との統合ツール、およびすべてのコンポーネントの共通管理システムを含むRed Hat Cloud Suiteパッケージが意図されているのは、このような場合です。 Red Hat Cloud Suiteを使用すると、企業のITインフラストラクチャをアップグレードできるため、開発者は従業員や顧客にサービスを迅速に作成して提供でき、ITプロフェッショナルはITシステムのすべてのコンポーネントを集中管理できます。

運営管理

• ハイブリッドクラウド管理
  
  成功は柔軟性と選択にかかっています。 ユニバーサルソリューションは存在しないため、企業のITインフラストラクチャの場合、常に複数のオプションを用意する価値があります。 パブリッククラウドプラットフォーム、プライベートクラウド、および従来のデータセンターを補完するコンテナにより、選択肢が広がります。 Red Hat CloudFormsを使用すると、KubernetesやRed Hat OpenShiftなどのコンテナー管理システムをRed Hat VirtualizationおよびVMware仮想環境と統合することにより、簡単にスケーラブルで理解しやすい方法でハイブリッドクラウドおよびコンテナーを管理できます。
• コンテナ自動化
  
  多くの場合、コンテナの作成と管理は単調で時間のかかる作業です。 Red HatのAnsible Towerを使用すると、Ansible Towerを自動化でき、シェルスクリプトを記述して操作を手動で実行する必要がなくなります。 Ansibleスクリプトを使用すると、アセンブリ、展開、管理など、コンテナのライフサイクル全体を自動化できます。 あなたはもはやルーチンを行う必要はなく、より重要なことのための時間があります。

コンテナとそれらをデプロイおよび管理するためのほとんどのテクノロジーは、オープンソースソフトウェアとしてRed Hatによってリリースされています。



Linuxコンテナーは、アプリケーションの開発、デプロイ、管理の方法におけるもう1つの進化的なステップです。 これらは、移植性とバージョン管理を提供し、ラップトップで作業する開発者が本番環境で作業できるようにします。



仕事でコンテナを使用していますか？また、その見込みをどのように評価していますか？ あなたの痛み、希望、成功を共​​有してください。