クラウドにおける完璧な組み合わせ: コンテナと DevOps

企業が継続的デリバリー アプローチの実装や、ソフトウェア開発プラクティスへのクラウド コンピューティング サービスの導入を検討している場合は、理論を気にせず実践に重点を置いてください。

IBM では、IBM Cloud Container Service は 1 日に平均 40 回更新されます。これらのアップデートの数は驚異的と思われるかもしれませんが、それには十分な理由があります。マイクロサービス上に構築され、IBM Cloud 上にグローバルに展開されている IBM は、新たなサイバー脅威に対する新しい機能と性能、高いパフォーマンス、最新のセキュリティ ソリューションを継続的にユーザーに提供したいと考えています。

[[227460]]

コンテナ サービスを 1 日に 40 回更新するには何が必要ですか?これは、追加機能の反復と展開、新しい場所でのサービスの展開、最新の OS パッチに基づくセキュリティの向上、サービスの提供の中核となる Kubernetes とコンテナ エンジンの改善、パフォーマンスや可用性の問題の修正を意味します。これは、市場と技術のニーズを満たすために、メンテナンス機能を継続的に追加し、サービスを拡大することも意味します。

毎日の更新の数は気が遠くなるような量になるかもしれませんが、クラウド ネイティブ、コンテナー、またはマイクロサービス戦略を補完する実証済みの方法である DevOps によって実現されます。

私たちの文化と開発手法に DevOps を取り入れることで、今日の最大のハードルであるセキュリティを克服することができました。クラウドネイティブ アプリケーションへの移行により、アプリケーションは非常に速いペースで構築および更新される可能性があるため、アプリケーションの機能やコンポーネントがどれだけ変更されても、セキュリティ更新が同じペースで行われ、継続的に更新されることが重要です。

アプリケーションの継続的なセキュリティとパフォーマンスを確保することは、特に更新や機能を継続的に展開する場合、すべての開発者が考慮する必要があることです。 DevOps を考慮するまでは、これは不可能なことのように思えるかもしれません。クラウド ツールのパワーと、アプリケーションの中核にセキュリティと安定性を組み込む新しい機能と組み合わせることで、DevOps はチームの構築を迅速化するのに役立ち、標準になりつつあります。

DevOps とクラウド コンピューティングによるコンテナ セキュリティの強化

継続的な配信と開発の実践に伴う絶え間ない変化と、さまざまなコンテナやマイクロサービスの管理の複雑さが組み合わさって、さまざまなセキュリティ リスクが生じる可能性があると主張する人もいるかもしれません。可動部品が増えると、多くの場合、リスクも増えますが、正しく実装されていれば、その逆になります。

DevOps を使用してコンテナベースのソフトウェアを継続的に更新すると、セキュリティが強化されます。これは、ホストされたコンテナ プラットフォームなどのクラウド環境が常に最新の状態に保たれ、最新のパッチ レベルに移行され、クラウド コンピューティングを介して世界中にプッシュされるためです。これにより、マルウェアの脅威に対応し、すぐに解決できるようになります。アプリケーション内のセキュリティ上の問題の主な原因は古いソフトウェアであるため、これにより環境全体がより安全になります。

DevOps を実践しながら実現する

コンテナの台頭は、ユーザーがコンテナ アーキテクチャを安全かつ効果的に継続的に提供する必要があることから、DevOps にとって大きな推進力となっています。継続的デリバリーを機能させるには、繰り返し可能なソフトウェアのデプロイメントが必要であり、変更 (ローリング アップデートやロールバックを含む) を許容する環境にデプロイする必要があります。

クラウド コンテナ サービスでは、世界中の何万ものクラスターが稼働し続けることが必要ですが、これを信頼性の高い方法で自動化できる成熟した DevOps ツールがなければ、これは事実上不可能です。

現在、多くのチームは数万のクラスターを実行していません。いくつかのクラスターを実行しています。ただし、特に異なるリージョンにまたがって、多数のコンテナ クラスターを管理してセキュリティを維持する複雑で大規模なアプリケーションを実行する場合は、この規模に対応するために異なる DevOps アプローチが必要になります。

この場合、モデルは反転され、環境自体が環境に変化を押し込むのではなく、環境が変化するようになります。各クラスターは、適用する必要がある新しい更新があるかどうかを継続的にチェックします。その後、A/B テスト ツール LaunchDarkly を使用して、個々のクラスターの更新を制御できます。

これにより、LaunchDarkly の設定を変更するだけで、誰が何を実行し、どの更新が世界中に流れるかをきめ細かく制御できるようになります。システムは、更新をプッシュする場所を決定するための複雑な調整ロジックを必要とせずにこれに応答します。

アドバイスをする

組織が継続的デリバリー方法論の実装を検討している場合、あるいはコンテナ、マイクロサービス、開発者ワークロードなどのクラウド コンピューティング サービスをソフトウェア開発プラクティスに組み込むことを検討している場合、それは困難な作業のように思えるかもしれません。改善と利益はすぐに目に見えて現れますが、組織がこれらのテクノロジーとプロセスの価値を真に実現するのに役立つ成熟したプロセスを構築するには時間がかかります。

あなたのビジネスがこの旅を始めようとしている場合、アドバイスはシンプルです。理論について心配するのをやめて、実践に集中してください。コンテナを使用した DevOps は成熟したパスなので、分離しないでください。ほとんどのチームは、コンテナと DevOps の実装に対して別々の戦略を持つことを望んでいます。それらはパッケージ取引であるべきです。

そこで、企業はプロジェクトを選択し、協力して取り組みます。多くの技術者がこれをうまく行っており、このアプローチにより、企業は早く失敗し、より速く革新することができます。