Dockerは私のユースケースに適していますか？ [閉鎖]

コンテナは素晴らしいです。アプリケーションとその依存関係を一緒にパッケージ化し、デフォルトで自動化する必要があります。これにより、機械で1つ（またはそれ以上）を自動化するのが比較的簡単です。

これはアップグレードに役立ちます。後でこのポイントに戻ります。

実際のユーザーに効率的かつ強力なアップデートをプッシュする方法が必要でした。

Dockerとrktの両方に独自のコンテナリポジトリがあります。 rkt は、少なくとも完全な暗号整合性チェックも提供します。 Dockerコンテナはレイヤーで構築され、ある程度の効率を提供します（変更されたレイヤーのみをインポートできます）。rkt現在、毎回全体の画像を抽出します。または、少なくとも私がインストールしたバージョンでは抽出します。

画像は2つの間で変換できます。たとえば、最近のプロジェクトでは、開発にDockerを使用し（レイヤーが大いに役立つ可能性があるため）、デプロイのためにイメージをrktに変換しました（rktがシステム管理者にとってより有用であるため）。少なくとも私にはセキュリティ問題があります）。

どちらの技術も現在急速に発展しています。たとえば、コンテナの形式が変更されています。したがって、Dockerまたはrktを使用することにした場合は、頻繁にアップグレードする必要があります。

注：すべての依存関係はコンテナにパッケージ化されているため、コンテナ外で実行されるOSのバージョンはそれほど重要ではありません。しかし、通常、新しいコンテナを出荷します。すべて直す。これはかなり多くの帯域幅を消費します。

また、オペレーティングシステムをアップグレードするとき（ご存知のようにUbuntuのアップグレードが長く遅れる）、パッケージが「正常に動作する」と比較的安全であると感じるように何かが必要です。

ここで必要なのはテストラボです。アップグレードが機能するという確信は、主にすでにアップグレードが完了しているという事実に由来します。テスト済みです。、サポートするすべてのバリエーションで繰り返されます。

コンテナが役に立ちます。これを使用して自動的にテストを実行できます（たとえば、GitLabの自動化されたテスト設定を参照）。コンテナはホストリソースの観点から非常に軽く、仮想マシンよりはるかに軽量です。したがって、コミットするたびに頻繁にテストできます。そして、出荷中のコンテナを構築するのと同じ自動化されたスクリプトを使用してテストを実行する必要があり、コンテナイメージが正しく機能することを確認できます。

ただし、実際の基本オペレーティングシステムのアップグレードのためには、実際のハードウェアでテストする必要があります。仮想マシンを使用してOSのアップグレードをテストすることもできます（画像を非常に簡単にロールバックして自動化できるため、非常に良いです）、実際のハードウェアもテストする必要があります。特に現場にあるため、アップグレードに失敗した場合は費用がかかります。

簡単に言うと：コンテナはこのような多くの作業に役立ちますが、今後5年間で安定性を安全に信頼できるほどソフトウェアがまだ成熟していないと思います。ただ、1～2年後には変わると予想しているので今でも考えてみると良いようです。

PS：考慮すべき非技術的事項：Ubuntuアーカイブからパッケージをダウンロードする場合、Ubuntuは同じ場所でソースを使用できるようにしてGPL準拠を処理できます。コンテナイメージを出荷する場合は、それについて心配する必要があります。 （もちろん、機器を運ぶときもこれを行う必要があります。）