開発者は K8s の専門家である必要はありません。！！

以前に「ナンセンスな DevOps、私たち開発者は運用や保守をまったくやりたくない!」という記事があり、多くの開発者の共感を呼びました。すべての開発者は運用や保守の作業を放棄して、開発するコードにもっと集中したいと考えています。素晴らしいアプリ。しかし、状況は期待通りではなく、クラウドネイティブの時代になっても、開発者の運用保守作業は軽減されるどころか、K8s上でのアプリケーションの導入と管理になっているようです。

運用および保守担当者は、基盤となる K8 を保守するだけで済み、柔軟性と利便性が大幅に向上します。しかし、K8s は私たち開発者にとってまだ複雑すぎるため、イメージと K8s 関連の知識をパッケージ化する方法を学ぶ必要があります。アプリケーションのデプロイメントには多くの時間が無駄に費やされていますが、K8s の専門家になる必要は本当にあるのでしょうか? 非常に複雑なアプリケーションをデプロイしたいだけですか? K8s の専門家でなくても、K8s の知識がなくても、アプリケーションをデプロイして簡単に管理できるプラットフォームや方法があるのではないかと考えたことはありますか?

実際の問題

私たち開発者にとって、企業レベルの問題またはビジネスレベルの問題である可能性がある次のようなさまざまなシナリオに常に遭遇することになります。おそらく、現在は従来のデプロイメント方法を使用するのは非常に簡単ですが、ビジネスが成長するにつれて、移行する必要があります。こうした問題に直面して、私たちは声を上げなければなりません。

小規模な会社では、専任の運用保守担当者はいません。プログラマは、Dockerfile + YAML + KusTOMize を作成して、それを k8s にデプロイする必要があります。ワークロードに加えて、K8s 自体の複雑さにも直面しており、複数のビジネスの場合、Dockerfie、Yaml、CI、CD スクリプトがワークロードのほとんどを占めています。これらは書かなくても大丈夫でしょうか？
社内のマイクロサービスはますます複雑になっています。コードを書くことに基づいて、各サービス間の通信、依存関係、デプロイメントの問題を考慮する必要があります。結局のところ、開発者は別として、運用および保守担当者は必要ありません。マイクロサービス間の複雑な依存関係よりも、マイクロサービスに精通しています。Helm はすでに試されているかもしれませんが、完全なチャートパッケージを作成するのは依然として非常に複雑で、形式の問題や不完全な構成の分離に直面する可能性もあり、別の環境にデプロイすることはできません。すべての Yaml を作成します。追加の Helm Chart を作成せずに、アプリケーションを直接コピーしても問題ありませんか?
大企業では、従来のアプリケーションをクラウド環境に移行する岐路に立っています。さまざまなクラスターのニーズに直面して、既存のアプリケーションをどのようにスムーズに移行するか、さらには一部の公開モジュールをどのように再利用するかが解決すべき問題になります。毎回再開発する必要はなく、既存のアプリケーションやモジュールを蓄積できますか?

これらのシナリオでは、追加の Dockerfile、Yaml、Helm Chart の作成に多くの時間を費やします。K8s は非常に優れていますが、開発者の問題を解決するものではなく、開発者にとって K8s を使用することがさらに複雑になります。これらの追加ファイルやスクリプトを作成する必要があることは言うまでもなく、K8 の知識を習得するだけでも多くの時間と労力を必要とします。これらの問題は本当に避けられないのでしょうか? 私はそうは思わない。K8 の知識を必要としないクラウドネイティブなアプリケーション管理プラットフォームである Rainbond について学びましょう。K8s のエキスパートになって初めてアプリケーションを適切に管理できるなんて誰が言ったのでしょう?

なぜレインボンドなのか？

Rainbondは、K8 の知識を必要としないアプリケーション管理プラットフォームです。サーバー上で面倒な操作を実行する必要はなく、K8 についての深い知識も必要ありません。Rainbond は、「アプリ中心」の設計哲学に従っています。ビジネスモジュールとアプリケーションのみがここにあります。すべてのビジネスモジュールはコードウェアハウスから直接デプロイして実行でき、K8s の専門家でなくてもアプリケーションのライフサイクル全体を管理できます。同時に、Rainbond のモジュラーアセンブリ機能を使用すると、ビジネスを独立したアプリケーションモジュールに柔軟に分割でき、これらのモジュールを自由に組み合わせて無限に組み立てることができ、最終的にはさまざまなアプリケーションシステムを構築できます。

1. K8 を理解していませんが、K8 を導入できますか?

わかりました！多くの初心者や開発者にとって、会社がすでに使用可能な K8s プラットフォームを構築している場合、このステップは心配する必要はありません。しかし、一部の独立系開発者にとって、そのような環境を持つことは困難であり、Rainbond がそのようなソリューションを提供します。Linux サーバーでは、最初に Docker コンテナを実行し、Rainbond コンソールにアクセスして、サーバーの IP アドレスを入力するだけです。完全な K8s クラスターを迅速に展開できます。

クラスターの追加

これでもまだ複雑すぎる場合は、Rainbond のクイックインストールを使用してみてください。K8s クラスターを備えたプラットフォームを開始するには、コンテナーと 5 分しかかかりません。プラットフォームにデプロイしたサービスもこのクラスターにデプロイされます。 .真ん中。

2. Dockerfile、Yaml、その他のファイルを書きたくない、または書き込めない場合でも、アプリケーションをデプロイできますか?

できる！Rainbond は、Java、Python、Golang、NodeJS、Dockerfile、Php など、使用する開発言語に関係なく、さまざまな開発言語の自動識別をサポートしており、それらを識別してコンテナイメージに自動的にパッケージ化し、ビジネスを迅速にデプロイできます。効率的な管理のための K8s クラスター。コードに依存しないファイルを作成する必要はなくなりました。コードウェアハウスのアドレスを入力するだけです。

ソースコードビルド

3. さまざまな業務システムをどのように組み立てるのか？

Rainbond では、簡単な接続を通じてさまざまなビジネスプログラムを迅速にプログラムできます。フロントエンドプロジェクトをバックエンドに依存させる必要がある場合は、オーケストレーションモードをオンにして接続するだけで、依存関係をすばやく確立し、モジュール式アセンブリを実現できます。これにより、アプリケーションアーキテクチャに大きな柔軟性がもたらされ、複雑な構成や操作を行わずに、複雑なアプリケーションシステムを迅速に構築できます。

同時に、完全なビジネスプログラムを実装している場合、そのプログラムには複数のマイクロサービスモジュールが含まれている可能性があり、それをローカルコンポーネントライブラリに公開してモジュールの蓄積を実現することもできます。これをクリックして次の展開で直接使用することができ、展開後に他のアプリケーションと組み合わせることができます。無制限のアセンブリの組み合わせを実現する機能。

コンポーネント_アセンブリ

4. K8s を知らなくても、デプロイされたアプリケーションを管理できますか?

問題ない！Rainbond は、アプリケーション指向の完全なライフサイクル管理とメンテナンスを提供します。Kubectl コマンドを学習したり、K8 の複雑な概念を知る必要はありません。バッチの起動、シャットダウン、構築、更新、ロールバックなどの主要な操作を管理できます。アプリケーションに障害が発生した場合の自動回復と、アプリケーションの自動スケーリングをサポートします。また、http および tcp ポリシーを適用する構成と、対応する証明書管理もサポートします。

アプリ管理

使い方？

Linux ターミナルで次のコマンドを実行し、5 分後にブラウザを開いて http://<your IP>:7070 と入力し、Rainbond ページにアクセスします。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

次に、クイックスタートに従って、最初のアプリケーションをすばやくデプロイします。