配信ツールの進化、または Docker、deb、jar などについての考え

どういうわけか、ある時点で、Docker コンテナーと deb パッケージの形式での配信に関する記事を書こうと決心しましたが、書き始めると、どういうわけか、最初のパーソナル コンピューター、さらには電卓が登場した遠い時代に引き戻されてしまいました。 一般に、docker と deb の無味乾燥な比較の代わりに、進化のトピックについて次のような考えを得ました。それを皆さんの考察のために紹介します。

どのような製品であっても、何らかの方法で製品サーバーにアクセスし、設定して起動する必要があります。 それがこの記事の内容です。

私は歴史的な文脈で、「私が見ているものは私が歌うものである」、最初にコードを書き始めたときに見たもの、そして今観察しているもの、私たち自身が現在何を使用しているのか、そしてなぜ使用しているのかを考えます。 この記事は本格的な研究を装ったものではなく、いくつかの点が抜けていますが、これは当時と現在についての私の個人的な見解です。

それで、古き良き時代に...私が見つけた最も初期の配信方法は、テープレコーダーのカセットテープでした。 私はBK-0010.01というコンピューターを持っていました...

電卓の時代

いや、もっと前の瞬間もあった、電卓もあった MK-61 и MK-52.

それで、私が持っていたとき MK-61、その後、プログラムを転送する方法は、プログラムが書かれた箱に入った普通の紙で、必要に応じて手動で実行するために電卓に書き込まれました。 プレイしたい場合は (はい、この古代の電卓にもゲームがありました)、座って電卓にプログラムを入力します。 当然のことながら、電卓の電源を切ると、プログラムは忘却の彼方に消えてしまいました。 プログラムは、彼自身の手で紙に書かれた電卓コードに加えて、雑誌「ラジオ」や「テクノロジー・フォー・ユース」に掲載され、当時の書籍にも掲載されました。

次の変更は電卓でした MK-52、すでに不揮発性データストレージのようなものを備えています。 これで、ゲームやプログラムを手動で入力する必要はなくなりましたが、ボタンを使用していくつかの魔法のパスを実行すると、自動的にロードされました。

電卓の最大プログラムのサイズは 105 ステップ、MK-52 の永続メモリのサイズは 512 ステップでした。

ところで、この記事を読んでいるこれらの電卓のファンがいるなら、記事を書いている過程で、Android 用の電卓エミュレータとそのプログラムの両方を見つけました。 過去へ進め！

• Android用エミュレータMK-61
• MK-61用プログラムカタログ

MK-52についてのちょっとした余談 (ウィキペディアより)

MK-52はソユーズTM-7宇宙船で宇宙に飛び立ちました。 搭載コンピューターが故障した場合に備えて、着陸軌道を計算するために使用されるはずだった。

52 年以来、Elektronika-Astro メモリ拡張ユニットを備えた MK-1988 は、ナビゲーション コンピューティング キットの一部として海軍の船舶に供給されてきました。

最初のパーソナルコンピュータ

時代に戻ろう BK-0010。 そこにはより多くのメモリがあり、紙からコードを入力するという選択肢はもはやありませんでした (ただし、最初は単に他の媒体がなかったため、最初はそうしていましたが)。 テープレコーダー用のオーディオカセットは、ソフトウェアを保存および配信する主な手段になりつつあります。

カセット上のストレージは通常、2 つまたは 3 つのバイナリ ファイルの形式であり、それ以外はすべてその中に含まれていました。 信頼性は非常に低く、プログラムのコピーを XNUMX ～ XNUMX 枚保管しなければなりませんでした。 ロード時間も残念なもので、愛好家はこれらの欠点を克服するためにさまざまな周波数エンコードを実験しました。 当時、私自身はまだ専門的なソフトウェア開発に携わっていなかったので（BASIC の簡単なプログラムは除いて）、内部がどのように構成されているかについては、残念ながら詳しくは説明しません。 コンピューターの大部分に RAM しか搭載されていないという事実自体が、データ ストレージ方式の単純さを決定しました。

信頼性の高い大容量記憶メディアの登場

その後、フロッピー ディスクが登場し、コピー プロセスが簡素化され、信頼性が向上しました。
しかし、十分に大きなローカル ストレージが HDD の形で登場した場合にのみ、状況は劇的に変わります。

配信の種類は根本的に変化しています。プログラムはメモリに読み込まれるだけでなく、すでにローカル ストレージにコピーされているため、システムの構成プロセスと削除後のクリーンアップを管理するインストーラー プログラムが表示されます。必要に応じて不要なものを削除できます。

同時に、提供されるソフトウェアの複雑さも増しています。
配信されるファイルの数は数個から数百、数千個に増加し、ライブラリのバージョン間で競合が発生したり、別のプログラムが同じデータを使用すると他の楽しみが始まります。

当時、Linux の存在は私にとってまだオープンではなく、MS DOS、その後 Windows の世界で生き、Borland Pascal と Delphi で書き、時には C++ に目を向けていました。 当時、多くの人が InstallShield を使用して製品を配信していました。 ru.wikipedia.org/wiki/InstallShieldこれにより、ソフトウェアの展開と構成という割り当てられたすべてのタスクが非常にうまく解決されました。

インターネット時代

ソフトウェア システムの複雑さは徐々にさらに複雑になり、モノリス アプリケーションやデスクトップ アプリケーションから分散システム、シン クライアント、マイクロサービスへの移行が進んでいます。 ここで、XNUMX つのプログラムだけでなく、一連のプログラムを構成して、すべてが連携して動作するようにする必要があります。

概念が一変し、インターネットが到来し、クラウドサービスの時代が到来しました。 これまでのところ、ウェブサイトの形での初期段階では、誰も特にサービスを夢見ていませんでした。 しかし、それはアプリケーションの開発と提供の両方において転換点となりました。

私自身としては、その瞬間に開発者の世代交代があり（あるいは私の環境だけで）、古き良き配信方法がすべて一瞬にして忘れ去られ、すべてが最初から始まったような感覚があったことに気づきました。始まり: すべての配信はニースクリプトで行われるようになり、それを誇らしげに「継続的配信」と呼びました。 実際、古いものは忘れ去られ、使用されず、新しいものはまったく存在しない、混乱の時代が始まりました。

当時私が働いていた会社（名前は言いませんが）では、ant 経由でビルドする代わりに（Maven はまだ普及していないか、まったく存在していませんでした）、人々は単純に IDE で jar を集めて、静かにコミットしていた時代を思い出します。 SVNで。 したがって、展開は、SVN からファイルを取得し、SSH 経由で目的のマシンにコピーすることで構成されていました。 とてもシンプルで不器用です。

同時に、PHP での単純なサイトの配信は、修正されたファイルを FTP 経由でターゲット マシンにコピーするだけという非常に原始的な方法で行われていました。 そうでない場合もありました。コードは製品サーバー上でライブ編集されており、どこかにバックアップがあれば特にシックでした。

RPM および DEB パッケージ

一方、インターネットの発展に伴い、UNIX 系システムがますます普及し始め、特に私が RedHat Linux 6 に出会ったのは 2000 年頃のことでした。 当然のことながら、ソフトウェアを配信するための特定の手段もありました。Wikipedia によると、主要なパッケージ マネージャーとしての RPM は 1995 年の RedHat Linux 2.0 バージョンですでに登場していました。 それ以来、そして今日に至るまで、システムは RPM パッケージの形式で提供され、非常に順調に存在し、開発されています。

Debian ファミリーのディストリビューションも同様の道をたどり、deb パッケージの形式で配信を実装しました。これは今日まで変更されていません。

パッケージ マネージャーを使用すると、ソフトウェア製品自体の配布、インストール プロセス中のソフトウェア製品の構成、異なるパッケージ間の依存関係の管理、製品の削除、アンインストール プロセス中の不要なアイテムのクリーンアップが可能になります。 それらの。 ほとんどの場合、必要なのはそれだけであり、それが、数十年にわたってほとんど変化せずに存続した理由です。

クラウド コンピューティングにより、物理メディアだけでなくクラウド リポジトリからのパッケージ マネージャーへのインストールも追加されましたが、基本的にはほとんど変わっていません。

現在、deb から離れて snap パッケージに切り替える動きがあることは注目に値しますが、それについては後ほど説明します。

そのため、DEB も RPM も知らなかったこの新世代のクラウド開発者もゆっくりと成長し、経験を積み、製品はより複雑になり、FTP、bash スクリプト、および同様の学生の工作よりも合理的な配信方法が必要になりました。
ここで Docker が登場します。これは、仮想化、リソースの制限、配信方法を組み合わせたものです。 今はファッショナブルで若々しいですが、それはすべてに必要ですか？ これは万能薬ですか？

私の観察によると、Docker が提案されるのは、合理的な選択肢としてではなく、単にコミュニティで話題になっていて、提案する人だけがそれを知っているという理由だけで提案されることが非常に多いです。 その一方で、彼らはほとんどの場合、古き良き包装システムについては沈黙しています。それらは存在し、目立たずに静かにその仕事を行っています。 このような状況では、実際には Docker を選択する以外に選択肢はありません。

Docker をどのように実装したか、その結果何が起こったかについての私の経験を共有したいと思います。

自作のスクリプト

当初は、jar アーカイブを必要なマシンにデプロイする bash スクリプトがありました。 このプロセスは Jenkins によって管理されました。 jar アーカイブ自体はすでにクラス、リソース、さらには構成を含むアセンブリであるため、これは正常に機能しました。 すべてを最大限に詰め込んだ場合、それをスクリプトに拡張することは、必要な最も難しいことではありません。

ただし、スクリプトにはいくつかの欠点があります。

• スクリプトは通常、急いで作成されるため、非常に原始的であるため、最良のシナリオが XNUMX つしか含まれていません。 これは、開発者が迅速な配信に関心があり、通常のスクリプトにはかなりの量のリソースの投資が必要であるという事実によって促進されます。
• 前の点の結果として、スクリプトにはアンインストール手順が含まれていません。
• 確立されたアップグレード手順がない
• 新しい製品が登場すると、新しいスクリプトを書く必要がある
• 依存関係のサポートなし

もちろん、洗練されたスクリプトを作成することもできますが、上で書いたように、これは開発時間であり、ご存知のとおり、常に十分な時間はありません。

これらすべてにより、この展開方法の適用範囲が最も単純なシステムのみに限定されることは明らかです。 これを変える時が来ました。

デッカー

ある時点から、鋳造されたばかりのミドルが私たちのところにやって来始め、アイデアに沸き立ち、港湾労働者について熱狂していました。 さあ、旗を手に、やってみよう！ 試みは XNUMX つありました。 どちらも失敗に終わりました。大きな野心はあったものの、実際の経験が不足していたと言えます。 それを無理してでも終わらせる必要があったのだろうか？ それはありそうにありません。適切なツールを使用するには、チームが必要なレベルまで進化する必要があります。 また、既製の Docker イメージを使用すると、ネットワークが正しく動作しなかったり (Docker 自体の湿気が原因である可能性があります)、他人のコンテナを拡張するのが難しいという事実に頻繁に遭遇しました。

どのような不都合がありましたか?

• ブリッジモードでのネットワークの問題
• コンテナ内のログを表示するのは不便です (ログがホスト マシンのファイル システムに個別に保存されていない場合)
• ElasticSearchがコンテナ内で時々異常にフリーズする、原因は特定されていない、コンテナは公式
• コンテナ内でシェルを使用する必要があります。すべてが非常に削ぎ落とされており、使い慣れたツールはありません
• 収集されたコンテナのサイズが大きい - 保管に費用がかかる
• コンテナのサイズが大きいため、複数のバージョンをサポートすることが困難
• 他の方法 (スクリプトまたは deb パッケージ) とは異なり、ビルド時間が長くなります。

一方で、同じ deb を介して jar アーカイブの形式で Spring サービスをデプロイする方が悪いのはなぜでしょうか? リソースの分離は本当に必要ですか? 大幅に削減されたコンテナにサービスを詰め込んで、便利なオペレーティング システム ツールを失うことに価値があるでしょうか?

実践が示しているように、実際にはこれは必要なく、90% の場合 deb パッケージで十分です。

古き良き deb が失敗するのはどんなときで、実際に docker が必要になるのはどんなときでしょうか?

私たちにとって、これは Python でサービスをデプロイすることでした。 機械学習に必要なライブラリが多数あり、オペレーティング システムの標準ディストリビューションには含まれていませんでした (間違ったバージョンが含まれていました)、設定のハッキング、同じホスト システム上に存在するさまざまなサービスに異なるバージョンが必要なことが原因で、つまり、この核混合物を運ぶ唯一の合理的な方法は港湾労働者だったということです。 Docker コンテナを組み立てる労働集約度は、それを依存関係のある個別の deb パッケージにすべて詰め込むという考えよりも低いことが判明し、実際、正気の人間なら誰もこれに取り組むことはありません。

Docker の使用を計画している XNUMX 番目のポイントは、Blue-Green デプロイ スキームを使用してサービスをデプロイすることです。 ただし、ここでは複雑さを段階的に増加させたいと考えています。最初に deb パッケージが構築され、次にそれらから Docker コンテナが構築されます。

スナップパッケージ

スナップパッケージに戻りましょう。 これらは Ubuntu 16.04 で初めて正式に登場しました。 通常の deb パッケージや rpm パッケージとは異なり、snap はすべての依存関係を保持します。 これにより、ライブラリの競合を回避できる一方で、結果として得られるパッケージのサイズが大きくなります。 さらに、これはシステムのセキュリティにも影響を与える可能性があります。スナップ配信の場合、パッケージを作成する開発者は、含まれるライブラリに対するすべての変更を監視する必要があります。 一般に、すべてがそれほど単純であるわけではなく、それらを使用することで普遍的な幸福が得られるわけではありません。 ただし、同じ Docker が仮想化ではなくパッケージ化ツールとしてのみ使用される場合、これは完全に合理的な代替手段です。

その結果、現在では deb パッケージと docker コンテナの両方を合理的な組み合わせで使用していますが、場合によってはこれを snap パッケージに置き換えることになるでしょう。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

配達には何を使いますか？

• 自作のスクリプト

• FTPに手動でコピー

• debパッケージ

• rpmパッケージ

• スナップパッケージ

• Docker イメージ

• 仮想マシンのイメージ

• HDD全体のクローンを作成する

• 人形

• アンシブル

• その他

109 人のユーザーが投票しました。 32名のユーザーが棄権した。

出所： habr.com