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

ある時、私は Docker コンテナと deb パッケージの形式での配信について記事を書こうと決めましたが、書き始めたとき、どういうわけか、最初のパーソナルコンピュータや電卓の遠い時代まで夢中になってしまいました。一般的に、docker と deb の無味乾燥な比較の代わりに、進化というトピックに関するこれらの考えを皆さんの判断のために提示します。

製品が何であれ、何らかの方法で製品サーバーに到達し、構成され、起動される必要があります。これがこの記事の主題です。

私は歴史的な文脈で、「私が見ているものは私が歌うものです」、私が最初にコードを書き始めたときに見たものと今観察しているもの、私たち自身が現在何を使用しているか、そしてその理由について振り返ります。この記事は本格的な研究であると主張しているわけではなく、いくつかの点が抜けていますが、これは過去と現在の状況に関する私の個人的な見解です。

それで、古き良き時代に戻って…私が覚えている最も古い配信方法は、テープレコーダーからのテープでした。私はBK-0010.01というコンピューターを持っていました…

電卓の時代

いや、もっと前の瞬間もあった。計算機もあった MK-61 и MK-52.

だから、私が MK-61当時、プログラムを転送する方法は、箱の中に普通の紙が入っており、その紙にプログラムが書かれており、必要に応じて手動で計算機に書き込まれていました。遊びたい場合 (そう、この大昔の電卓にもゲームがありました)、座って電卓にプログラムを入力します。当然のことながら、電卓をオフにすると、プログラムは忘れ去られました。計算機のコードは手書きで紙に書かれたほか、雑誌「ラジオ」や「若者のためのテクノロジー」にもプログラムが掲載され、当時の書籍にも印刷されました。

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

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

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

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

MK-52についてのちょっとした余談 （Wikipediaより）

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これにより、ソフトウェアの展開と構成のすべてのタスクが非常にうまく解決されました。

インターネット時代

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

概念は完全に変わり、インターネットが登場し、クラウドサービスの時代が始まりました。今のところ、ウェブサイトという形ではまだ初期段階にあります。誰もサービスを本当に夢見ていません。しかし、これはアプリケーションの開発と実際の配信の両方において業界にとっての転換点となりました。

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

当時私が働いていた会社 (名前は言いません) では、ant 経由でビルドするのではなく (当時は maven は普及していなかったか、まったく存在していませんでした)、IDE で jar をビルドして、それを SVN に静かにコミットしていた時代を覚えています。したがって、展開は、SVN からファイルを取得し、SSH 経由で目的のマシンにコピーすることで構成されます。それはとても単純かつ粗雑なことだ。

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

RPM および DEB パッケージ

一方、インターネットの発展に伴い、UNIX系のシステムがますます人気を集めるようになり、特に私がRed Hatを知ったのはその頃だった。 Linux 6、2000年頃。当然ながら、そこにもソフトウェアを配信するための手段がいくつか存在した。Wikipediaによると、主要なパッケージマネージャーとしてのRPMは、1995年にRed Hat版で登場した。 Linux 2.0。それ以降、このシステムはRPMパッケージとして提供され、引き続き発展を続けている。

家族の分布 Debian 彼らは同様の道を辿り、debパッケージの形式で配信を実装した。この形式は今日まで変わっていない。

パッケージ マネージャーを使用すると、ソフトウェア製品自体を配信したり、インストール時に構成したり、さまざまなパッケージ間の依存関係を管理したり、製品を削除したり、アンインストール時に不要な項目をクリーンアップしたりできます。それらの。ほとんどの場合、必要なのはそれだけであり、それが何十年も実質的に変わることなく存続してきた理由です。

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

現時点では、deb から snap パッケージへ移行する試みがいくつかあることは注目に値しますが、これについては後ほど詳しく説明します。

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

私の観察では、Docker が提案されるのは、合理的な選択としてではなく、単にコミュニティ内で話題になっており、それを提案する人だけがそれを知っているからというだけの理由である場合が非常に多いです。一方、古き良きパッケージング システムはほとんど知られていません。つまり、存在し、静かに、気づかれずにその役割を果たしているのです。このような状況では、他に選択肢はありません。選択肢は明らかです。Docker です。

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

自作のスクリプト

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

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

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

もちろん、洗練されたスクリプトを書くこともできますが、上で書いたように、開発には時間がかかり、しかも、ご存知のとおり、時間が足りないのです。

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

デッカー

ある時点で、アイデアが湧き上がり、Docker を絶賛する、できたてのミドルたちが私たちのところにやって来るようになりました。さて、行きましょう！やりましょう！試みは2回ありました。両者とも失敗に終わりました。大きな野心があったものの、実務経験が不足していたためだと言えます。無理やり、どんな手段を使ってでも終わらせる必要があったのでしょうか？可能性は低いです。適切なツールを使用するには、チームが必要なレベルまで進化する必要があります。また、既製の Docker イメージを使用すると、ネットワークが正常に動作しなかったり (Docker 自体の未熟さも原因だったと思われます)、他の人のコンテナの拡張が困難であったりするケースも頻繁に発生しました。

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

• ブリッジモードでのネットワークの問題
• コンテナ内のログを表示するのは不便です（ログがホストマシンのファイルシステムに個別に移動されていない場合）
• コンテナ内のElasticSearchが定期的に奇妙にフリーズするが、理由は明らかにされていない。コンテナは公式である。
• コンテナ内のシェルを使用するのは不便です。すべてが非常に限られており、通常のツールはありません。
• 収集された容器のサイズが大きいため、保管に費用がかかる
• コンテナのサイズが大きいため、複数のバージョンをサポートするのは困難です。
• 他の方法（スクリプトや deb パッケージ）よりもビルド時間が長くなります

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

実践が示しているように、現実にはこれは必要ありません。 90% のケースでは deb パッケージで十分です。

古き良き deb が失敗するのはいつですか? また、docker が本当に必要なのはいつですか?

私たちの場合は、Python でサービスを展開していました。機械学習に必要な多くのライブラリが標準のオペレーティング システムの配信には含まれておらず (含まれていたとしても適切なバージョンではなかった)、設定に関するハックがあり、同じホスト システム上で稼働するさまざまなサービスに異なるバージョンが必要であることから、この核となる混合物を配信する唯一の合理的な方法は Docker であるという事実に至りました。 Docker コンテナを組み立てる労働集約度は、依存関係を持つ個別の deb パッケージにこれらすべてをパックするというアイデアよりも低いことが判明し、実際、正気でこれを採用する人は誰もいなかったでしょう。

docker が使用される予定の 2 番目のポイントは、ブルーグリーン デプロイ スキームを使用してサービスをデプロイすることです。しかし、ここでは複雑さを徐々に増やしていきたいと考えています。まず、deb パッケージがビルドされ、次にそれらから docker コンテナがビルドされます。

スナップパッケージ

スナップパッケージの話に戻りましょう。スナップパッケージは最初に公式に登場したのは Ubuntu 4月16日。従来のDEBパッケージやRPMパッケージとは異なり、Snapパッケージにはすべての依存関係が含まれています。これによりライブラリの競合は回避されますが、結果としてパッケージのサイズが大きくなります。さらに、これはシステムセキュリティにも影響を与える可能性があります。Snapパッケージをデプロイする場合、パッケージを作成する開発者は、含まれるライブラリへのすべての変更を管理する必要があります。全体として、それほど単純なものではなく、Snapパッケージを使用することが常に双方にとってメリットがあるとは限りません。しかし、たとえばDockerを仮想化ではなく、パッケージングツールとしてのみ使用する場合には、Snapパッケージは十分に合理的な選択肢となります。

その結果、現在では deb パッケージと docker コンテナの両方を適切な組み合わせで使用しており、場合によっては snap パッケージに置き換えることもあります。

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

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

• 自作のスクリプト

• FTPに手動でコピーする

• debパッケージ

• rpm パッケージ

• スナップパッケージ

• Dockerイメージ

• 仮想マシンイメージ

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

• 人形

• アンシブル

• その他

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

出所： habr.com