【TOP100summit】仕事をうまくやり遂げたいなら、まずはツールを磨くこと --- JFrog の Kubernetes 実践

[51CTO.com からのオリジナル記事] Kubernetes は、コンテナ化されたアプリケーションを大規模にデプロイするための標準的な方法となり、複雑なコンテナ デプロイ環境の管理に役立ちます。ただし、Kubernetes 環境にアプリケーションとマイクロサービスをデプロイするのはそれほど簡単でも単純でもありません。 Kubernetes 環境でアプリケーションを正常にデプロイするにはどうすればよいですか?最近、51CTO の記者が第 7 回 Global Software Case Study Summit (略称 ***00summit) で JFrog のアーキテクト Gao Xin 氏にインタビューし、この問題を解決しました。

[[252161]]

JFrog のアーキテクトである Gao Xin は、DevOps ソリューションとエンタープライズ DevOps 変革に重点を置いています。彼は IBM で約 10 年間勤務し、Dev Ops 製品とパブリック クラウド サービスの研究開発、運用、保守、サービス、プロモーションに重点を置くチームを率いてきました。ソフトウェア製品やクラウドサービスの開発・運用、継続的インテグレーションとデリバリー、DevOpsなどの分野で豊富な技術的蓄積と実践経験を持っています。

アプリケーションの展開

Gao Xin 氏はまず、Kubernetes 環境でアプリケーションを正常にデプロイするには、アプリケーションのデプロイを急ぐのではなく、小さなことから始めて Kubernetes の特性を十分に理解する必要があると述べました。同時に、アプリケーション自体も十分に調査して変換し、Kubernetes 環境でのデプロイメントに適したものにする必要があります。

JFrog を例にとると、JFrog は非常に小さなアプリケーションからの Kubernetes デプロイメントを開始しました。たとえば、Nginx の場合、最初にアプリケーションを Kubernetes にデプロイするための小さな目標を定義して、コンテナ化されたプロセス全体が技術的に制御可能であることを確認します。

高可用性は JFrog 製品のデフォルト機能であるため、高可用性テストに対する需要が高まります。大規模な同時リクエストをサポートし、ローリング アップグレード (ダウンタイムなしのアップグレード) テスト、計画的および計画外のノード ダウンタイム テストを含む破壊テスト、およびクラスター削減テストをサポートするために、容量を迅速に拡張できる必要があります。

次に、展開方法と構成を完全に設計する必要があります。 Gao Xin 氏は、Helm プロジェクトはバージョン管理をサポートし、Kubernetes アプリケーションの配布と展開の複雑さを大幅に簡素化できる統一されたソフトウェア パッケージング方法を提供すると述べました。 Helm はコミュニティの成長にもつながり、ますます多くのソフトウェア プロバイダーが高品質のチャートを提供するようになりました。したがって、Helm を使用すると、デプロイメントのオーケストレーションと実行が容易になります。

そして、デプロイが完了した後は、Kubernetesの特性を踏まえてアプリケーションの実行状況を監視する必要があります。これには、アプリケーションと開発に加えて、動作状態を監視するための優れたメカニズムとシステムを提供できるいくつかの追加ツールの使用が必要です。
***、いくつかの自動化された方法とアセンブリ ライン メソッドを使用して展開プロセス全体を自動的に実行し、迅速に再利用して迅速な応答を得ることができる全体的なプロセスが必要です。 Gao Xin氏は、開発者がコミュニティの力をうまく活用し、他者の経験から学ぶことで、半分の労力で2倍の成果を達成できることを期待していると強調した。

実戦経験

JFrog では現在、さまざまな製品ラインとバージョンの組み合わせに対して 100 を超えるテスト環境を毎週自動的にデプロイでき、各環境で 50 を超えるマイクロサービスをデプロイする必要があります。この規模の展開を達成する過程で、JFrog は多くの困難な問題に遭遇し、多くの経験と教訓を蓄積しました。

まず、JFrog は Kubernetes アプリケーションを社内で実装する目標を明確に定義しました。それは、開発、テスト、テクニカル サポート、製品チーム、ソリューション チームなど、すべてのチームが使用できるフル機能のテスト環境を迅速に構築できるようにすることです。同時に、各ブランチに CI/CD パイプラインのサポートが提供され、R&D が自己テスト用の独立したサンドボックス環境を持つことが可能になりました。これも Kubernetes がもたらす最大の価値の 1 つです。

同時に、JFrog はクラウド サービスを Kubernetes 環境に段階的に移行し、Kubernetes 環境での展開を容易にするために、すべての JFrog 製品用の Helm Charts を顧客に直接提供しています。

「このプロセスのすべてのステップは困難だ」とガオ・シン氏は語った。まったく新しい環境であり、まったく新しいアプローチであるため、未知の要素が数多くあります。 Gao Xin 氏は、開発者がコミュニティをより頻繁に訪問し、コミュニティの専門家とコミュニケーションを取ることを提案しています。彼らは遭遇する困難を解決するための多くの経験と方法を得るでしょう。

Jfrog のクライアントは業界によって制限されません。テンセント、ZTE、ファーウェイなどのインターネット企業のほか、金融や証券などの伝統的な産業も含まれます。 DevOps 変革の必要性がある限り、JFrog が支援を提供します。 JFrog は、DevOps の概念をより多くのユーザーに広め、普及させたいと考えています。

記者の視点

Kubernetes では、アプリケーション管理が最も要求が厳しく、困難な領域です。 Kubernetes コミュニティ オーケストレーション ソリューションの中では、Charts パッケージに基づく Helm の実装が主流です。現在、Helm は Kubernetes におけるアプリケーション オーケストレーションの唯一のサブプロジェクトとなっています。 JFrog は実践で豊富な経験を積み、オープンソースを積極的に採用しており、より多くの企業顧客が DevOps を実装するのに役立つことは間違いありません。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]