ISPsystem さん、許してさようなら! サーバー コントロール パネルを作成した理由と方法

こんにちは！ 私たちは「ホスティングテクノロジーズ」であり、5年前に設立されました VDSina — 開発者向けに特別に作成された最初の vds ホスティング。 私たちは、DigitalOcean と同様に、ロシアのサポート、支払い方法、ロシアのサーバーを使用して、利便性を高めるよう努めています。 しかし、DigitalOcean は信頼性と価格だけでなく、サービスでもあります。

ISPsystem のソフトウェアは、クールなサービスを実現するために私たちの手を縛るロープであることが判明しました。 XNUMX 年前、私たちは Billmanager 請求と VMmanager サーバー コントロール パネルを使用しましたが、独自のコントロール パネルなしでは優れたサービスを提供することはほぼ不可能であることにすぐに気づきました。

ISP システムがいかに利便性を殺したのか

バグ

私たち自身でバグを修正することはできませんでした。そのたびに、他の人のサポートに連絡して待たなければなりませんでした。 問題を解決するには、サードパーティ企業の対応が必要でした。

ISP システムのサポートは正常に応答しましたが、修正は数回のリリース後にのみ提供され、その後は常に、すべてではありませんでした。 場合によっては、重大なバグが数週間修正されることもありました。 私たちは顧客を安心させ、謝罪し、ISP システムがバグを修正するのを待つ必要がありました。

ダウンタイムの脅威

アップデートにより予期せぬダウンタイムが発生し、新たなエラーが発生する可能性があります。

各アップデートは宝くじでした。私は請求を隠蔽し、アップデートの神に犠牲を払わなければなりませんでした。何度かアップデートにより 10 ～ 15 分のダウンタイムが発生しました。 この時点では、管理者は静観していました。ダウンタイムがどれくらい続くかはわかりませんし、ISPsystem がいつ新しいアップデートをリリースするかを予測することもできませんでした。

第 XNUMX 世代では、Billmanager は改善されましたが、必要な機能にアクセスするには、ベータ版をインストールする必要がありました。ベータ版はすでに毎週更新されていました。 何かが壊れた場合は、他の開発者が何かを修正できるようにアクセスを許可する必要がありました。

パネルインターフェースが不便

すべてが異なるパネルに分割され、異なる場所から制御されました。 たとえば、クライアントは Billmanager を通じて支払いを行うため、VMManager で VDS を再起動または再インストールする必要がありました。 また、当社のスタッフは、クライアントをサポートしたり、サーバーの負荷を確認したり、使用している OS を確認したりするために、ウィンドウを切り替えなければなりませんでした。

このようなインターフェイスには、私たちにとってもクライアントにとっても時間がかかります。 このような状況では、DigitalOcean のような利便性が存在することに疑問の余地はありません。

頻繁な API アップデートによる短いライフサイクル

私たちは独自のプラグインを作成しました。たとえば、VMManager にはない追加の支払い方法を備えたプラグインです。

近年、VMManager のライフサイクルは比較的短く、新しいバージョンでは API 内の変数または関数の名前が任意に変更される可能性があり、これによりプラグインが機能しなくなってしまいました。 古いバージョンのサポートはすぐに段階的に廃止され、更新する必要がありました。

変更できません

より正確に言えば、それは可能ですが、非常に非効率的です。 ライセンス制限により、ソース コードを変更することはできず、プラグインのみを作成できます。 最大プラグイン - 一部のメニュー項目、ステップバイステップのウィザード。 ISP システムは多用途性を考慮して設計されていますが、特殊なソリューションが必要でした。

そこで、自分でパネルを書くという決断が熟しました。 私たちは次の目標を設定しました。

• エラーやバグに迅速に対応し、クライアントを待たせることなく自分で修正できるようにします。
• ワークフローやクライアントのニーズに合わせてインターフェイスを自由に変更できます。
• すっきりとしたわかりやすいデザインで使いやすさを向上させます。

そして開発を開始しました。

新しいパネルアーキテクチャ

私たちは自給自足の開発チームを持っているので、パネルも自分たちで書きました。
主な作業は XNUMX 人のエンジニアによって行われました。テクニカル ディレクターの Sergey がアーキテクチャを考え出してサーバー エージェントを作成し、Alexey が請求を行い、フロントエンドはフロントエンダー Artysh によって組み立てられました。

ステップ 1: サーバーエージェント

サーバー エージェントは、ライブラリを管理する Python Web サーバーです。 libvirt、それが今度は統治する Qemu-kvm ハイパーバイザー.

エージェントは、libvirt ライブラリを介してサーバー上のすべてのサービス (vds の作成、停止、削除、オペレーティング システムのインストール、パラメーターの変更など) を管理します。 記事の公開時点では、これらは XNUMX 以上の異なる機能であり、タスクやクライアントのニーズに応じて補完されます。

理論上、libvirt は課金から直接制御できますが、これには追加コードが多すぎるため、これらの機能をエージェントと課金の間で分離することにしました。課金は単に JSON API 経由でエージェントにリクエストを行うだけです。

エージェントはインターフェイスを必要とせず、サーバー コンソールから直接テストできるため、最初に実行しました。

サーバーエージェントから得られたもの: すべての人の生活を簡素化するレイヤーが登場しました。請求では大量のコマンドを送信する必要はなく、リクエストを行うだけで済みます。 そして、エージェントは必要なことをすべて実行します。たとえば、ディスク領域や RAM を割り当てます。

ステップ 2. 請求

開発者の Alex にとって、これは初めてのコントロール パネルではありませんでした。Alex は長い間ホスティングに携わっていたため、クライアントが何を必要とし、ホスティング者が何を必要としているのかを大体理解していました。

私たちは、請求書のことを「コントロール パネル」と呼んでいます。これには、お金やサービスだけでなく、その管理、顧客サポートなどが含まれています。

ISPSystem ソフトウェアから切り替えるには、顧客向けに以前の機能を完全に保持し、ユーザーのすべての財務行為と、ユーザー間のすべてのサービスと接続を古い請求から新しい請求に移行する必要がありました。 私たちは現在の製品の内容を調査し、次に競合他社 (主に DO と Vultr) のソリューションを調査しました。 私たちは欠点と利点を検討し、ISPsystem の古い製品を使用した人々からのフィードバックを収集しました。

新しい請求では、従来の PHP、MySQL (将来的には PostgreSQL に切り替える予定)、バックエンドのフレームワークとして Yii2、フロントの VueJS という XNUMX つのスタックが使用されました。 スタックは互いに独立して動作し、さまざまな人々によって開発され、JSON API を使用して通信します。 当時も現在も開発に使用しています PHPストーム и ウェブストーム JetBrains の出身であり、彼らを心から愛しています (皆さん!)

このパネルは、支払いシステム モジュール、ドメイン レジストラ モジュール、または SSL 証明書モジュールなどのモジュール ベースで設計されています。 新しい機能を簡単に追加したり、古い機能を削除したりできます。 拡張の基礎は、逆の方向、つまり「ハードウェアに向けて」も含めて、アーキテクチャ的に構築されます。

私たちが得たものは何ですか: 私たちが完全に制御できるコントロール パネル。 現在では、バグは数週間ではなく数時間で修正され、新機能は ISPSystem の要求ではなく顧客の要求に応じて実装されます。

ステップ 3 インターフェース

インターフェースは私たちのチームの発案です。

まず、インターフェースを根本的に変更せずに、ISPsystem API 上でアドオンを作成した場合に何が起こるかを検討しました。 結果はまあまあだったので、すべてを最初から行うことにしました。

私たちは、クリーンでミニマルなデザインでインターフェイスを論理的にすることが重要であり、そうすれば美しいパネルが得られると信じていました。 要素の配置については Megaplan で議論され、現在ユーザーがコントロール パネルで見るインターフェイスが徐々に誕生します。

すでに ISPsystem 用の支払いプラグインを作成しているため、請求ページのデザインが最初に登場しました。

フロントエンド

彼らは、パネルを SPA アプリケーションにすることを決定しました。これは、リソースをあまり要求せず、データを高速に読み込むことができます。 私たちのフロントエンダー Artysh は、Vue でそれを書くことに決めました。当時、Vue はちょうど登場したばかりでした。 私たちは、このフレームワークは React のように動的に発展し、しばらくすると Vue コミュニティが成長し、ライブラリの海が現れるだろうと想定していました。 私たちは Vue に賭けましたが、後悔しませんでした。バックエンドですでにプログラムされている新しい機能をフロントに追加するのに、ほとんど時間はかかりません。 フロントエンドパネルについては別の記事で詳しく説明します。

フロントエンドをバックエンドに接続する

フロントエンドはプッシュ通知を介してバックエンドに接続されました。 苦労して独自のハンドラーを作成する必要がありましたが、今ではページ上の情報はほぼ瞬時に更新されます。

どうしたの： パネルインターフェースがよりシンプルになりました。 私たちはそれを適応型にし、高速読み込みにより、パネルを操作するための別のアプリケーションをインストールすることなく、離陸前の最後の数分間に携帯電話からでも使用できるようにしました。

ステップ 4. テストと移行スキーム

すべてが起動し、最初のテストに合格したとき、移行の問題が生じました。 まず、課金をインストールし、サーバーエージェントでの動作テストを開始しました。

次に、データベースを古い請求書から新しい請求書に転送する簡単なスクリプトを作成しました。

Billmanager、VMmanager、マネージャーの IPmanager という XNUMX つの古いデータベースからデータが XNUMX つの新しいデータベースに統合されたため、文字通りすべてをテストして再チェックする必要がありました。 おそらく、テストの移行は、新しいパネルの開発過程で遭遇した最も難しいことです。

再確認後、古い請求を閉鎖しました。 最後のデータ移行は非常に厄介な瞬間でしたが、ありがたいことに目立った問題もなく数分で完了しました。 小さなバグがあったので、その週の間に修正しました。 ほとんどの時間は何が起こったかをテストするのに費やされました。

その後、新しいパネルの住所と請求書を記載した手紙をクライアントに送信し、リダイレクトを作成しました。

結果として： 生きてる！

ハッピーエンド

ソフトウェアを使用した最初の数時間から、私たちは移行のすべての喜びを感じました。 コードは完全に私たちのもので、便利なアーキテクチャを備えており、インターフェイスはクリーンで論理的でした。

新パネル発売後の初レビュー

お客様の移行を容易にするために、負荷が最も少ない 2017 年の大晦日の XNUMX 月に移行プロセスを開始しました。休日の前夜にはほとんど誰も仕事をしません。

当社のシステムに切り替えて得た主な点は (一般的な信頼性と利便性は別として)、主要な顧客向けに機能を迅速に追加できることです。つまり、顧客の尻ではなく顔になることができるということです。

次は何ですか？

私たちは成長しており、データ、顧客、顧客データの量は増加しています。 Memcached サーバーと、異なるタスクを持つ XNUMX つのキュー マネージャーをバックエンドに追加する必要がありました。 フロントエンドにはキャッシュと独自のキューがあります。

もちろん、製品が開発され、より複雑になるにつれて、たとえば HighLoad を追加したときなど、私たちにはまだ冒険がありました。

次回の記事では、Hi-CPU 料金体系がどのようにして開始されたのか、ハードウェア、ソフトウェア、どのようなタスクを解決し、何を行ったかについて説明します。

出所： habr.com