Docker と Kubernetes は私のチームに適していますか?

Sitecoreのサイトコアコミュニティでは、コンテナ化されたインストールの公式サポートが発表されて以来、Dockerとコンテナを中心に多くの話題が飛び交っています。ザコミュニティ Docker リポジトリは、開発者が非常に迅速にセットアップできるように、画像とスクリプトを準備するために多くの支援を提供してきました。デベロッパーは、生産性の向上とインストール管理の容易化に期待を寄せており、今度は、組織がソフトウェア配信の戦略としてコンテナ化を採用するかどうかを決定する必要があります。

残念ながら、答えは「場合による」です。 

経験則として、仮想マシンを使用している組織の場合は、おそらくコンテナを使用する方が良いでしょう。個々の開発者は、プロダクションへの完全なDevOpsフローのために企業全体でDockerを採用しないことを決定した場合でも、Dockerを使用することでメリットが得られることに注意してください。

一般に、次の課題は、組織がコンテナ戦略から利益を得る可能性があることを示しています。

• 現在の DevOps フローでは、インフラストラクチャの高コスト仮想マシンに必要なリソースの過剰使用が原因です。
• 次の理由により、組織が Sitecore インフラストラクチャを管理するのは困難ですさまざまな依存関係Sitecore の異なるバージョン間。
• 組織は多くの時間を無駄にするSitecore 環境の設定。
• さまざまな環境があります複数のクラウドにデプロイホスティング環境。
• チームは次のことができる必要があります特定の環境を迅速にレプリケート(報告されたプロダクションの問題に対するサポートなど)。
• チームは取り組む必要がありますさまざまなサイト/ソリューション/プロジェクトまた、Sitecore の異なるバージョンを使用し、異なる依存関係 (SQL Server バージョン、オペレーティング システム、Solr バージョンなど) が必要な場合もあります。
• デベロッパーは、ある Sitecore プロジェクトから別のプロジェクトに移動する必要があります。すぐに使い始める、そしてすぐに分解します。
• チームは、その方法を見つけるのに苦労しています分離してテストするデプロイ前。

これが私のものです特典のトップ4これは、コンテナ化戦略を採用する理由を説明するのに役立ちます。

コンテナ化戦略を採用する理由を説明するのに役立つメリットのトップ4をご紹介します。

1. 市場投入までの時間の短縮。 多くのマーケティングチームは、開発者のセットアップ時間の短縮、環境間のデプロイフローの円滑化、技術的なデリバリーの遅延の原因となる「自分のマシンで動作する」シナリオの減少により、恩恵を受けることができます。これにより、チームはより迅速にイテレーションを行い、開発からプロダクションまでのフローにおけるリスクを軽減できます
   
   課題: チームは新しい働き方に適応する必要があるため、これらのメリットを享受するには時間がかかります。また、コードがプロダクションに達するのを妨げている他の理由(長いテスト/受け入れステージなど)が組織にある場合は、最初にこれらのより大きなフローの問題に焦点を当てる必要があるかもしれません
    
2. 運用コストの削減。ITチーム チームは、同じホスト上の複数の仮想マシンと比較して、ホスト上で複数のコンテナーを運用する場合、インフラストラクチャ コストの削減を実感できます。オペレーティングシステムのカーネルが共有され、毎回複製されることがなくなるため、ホスト上でコンテナを実行するために必要なリソースが少なくなります。
   
   挑戦：コンテナのデプロイの容易さは、「コンテナの無秩序な増加」という副作用をもたらす可能性があり、実際には運用コストに逆効果をもたらします。運用コストを抑えるために、コンテナの適切なオーケストレーションと管理を行うことが非常に重要です。Kubernetes(K8s)はここであなたの友達です!
    
3. クラウドの柔軟性。 コンテナがオペレーティングシステムを抽象化する方法の性質上、コンテナは異なるクラウドベンダー間で移動できます。これにより、組織はクラウドインフラストラクチャの誰と取引するかを柔軟に選択できます
   
   課題:コンテナは柔軟なですが、「サービスとしてのKubernetes」(別名マネージドKubernetesサービス)の使用を計画している場合、オーケストレーションはクラウドベンダー間で異なる場合があります。これは、クラウドベンダーを切り替えたり、一度に複数のベンダーで実行したりする場合に計画する必要があります
    
4. 平均解決時間(MTTR)の短縮。コンテナ戦略がプロダクションを含むすべての環境に流れる場合は、サポートチームがプロダクション環境をローカルに迅速に複製できるため、ローカル環境とプロダクション環境間の不均衡の可能性を抑えながら、より迅速に問題の修正に取り組むことができます
   
   挑戦： このシナリオの利点を確認する前に、フローチェーン全体でこれを採用する必要があり、数人の開発者にDockerをインストールさせるだけでは十分ではありません。これは、利点を認識するために総合的に対処する必要があります。

コンテナ戦略を採用する際に、組織がおそらく課題に直面することを示す兆候があります。

• レイトアダプター。組織は、新しいテクノロジーが登場するたびに採用するのが困難です。彼らは「それを理解する」ことを望んでおらず、自分たちが知っている方法で物事を行い、他の人が最初に新しい、十分に文書化された実践を確立することを望んでいます。これらの組織は通常、「バージョンマイナス1」ポリシー、古いオペレーティングシステムやブラウザバージョンでの実行、クラウドベースのインフラストラクチャへの移行への躊躇など、「導入が遅れる」行動を示します。一部のシナリオでは、これらの古いインフラストラクチャでは、Docker の仮想化要件を満たすことさえできない場合があります。
  
  KubernetesとDockerはまったく新しいものではありませんが、Sitecoreサイトコアコミュニティではまだ新しい技術ソリューションであるため、ドキュメント、実証済みのプラクティス、および広範な採用にギャップがあります。
  
  課題に直面する:現在 Sitecore を使用している組織で、自社の組織と同様のプロファイルを持つ組織のケース スタディを特定します。これにより、ステークホルダーに対して「これは以前にも行われたことがある」という安心感を得ることができます。次に、インフラストラクチャテクノロジーの現状を分析して、コンテナの準備を確実にする必要があります。
  
  
• 高度に規制された環境。政府の法律であろうと企業レベルのポリシーであろうと、これらの組織には、ソフトウェアを開発からプロダクションに移行する方法について多くのルールがあります。DevSecOpsチームは、現在のポリシーや規制をコンテナの世界にどのように変換するかを知らないかもしれません。すべてのチームは、コンテナがポリシーを満たしていることを確認する方法についてどのように教育を受けますか?これらのポリシーの一部は、おそらく何年も前に開発され、新しいテクノロジーに対して再検討されていません。 
  
  課題に直面する:これはすべて教育に関するものです。できないわけではありませんが、人々は必ずしも方法を知っているわけではありません。これは、概念実証を行い、さまざまなチームに「見せる」ことができるチャンピオンを特定するして、既存のテクノロジーと提案されたの違いを理解できるようにするのに役立ちます。
  
  
• インフラのコストは「制御下にある」ようです。インフラストラクチャのオーバーヘッドが非常に小さいか、技術的な提供/運用が外部グループにアウトソーシングされており、サービスのコストは技術的責任の軽減に比べて妥当です。 
  
  手記：アウトソーシングされた作業を行っているチームは、利益率を高めるためにコンテナ戦略を検討したいかもしれません。
  
  課題に直面する: 現在のインフラストラクチャ コストがビジネスを妨げておらず、コンテナが組織のあるべき道であると本当に感じている場合は、インフラストラクチャ コストだけに焦点を当てるのではなく、プロダクションの欠陥に対する解決までの時間 (MTTR) や市場投入までの時間のメリットを検討する価値があるかもしれません。あなたの組織は、これらの分野でより多くの価値を見出しますか?
  
  
• 成熟した安定したアプリケーションベース。Sitecore がホストする環境で日常的に発生する変更はほとんどありません。おそらく、Sitecore、1つのサイト、1つのソフトウェアバージョンで作業している小さなチームがあるでしょう。さまざまな環境を維持することに複雑さはなく、変更はほとんど発生しません。
  
  課題に直面する:この状態は、実はイノベーションの警告サインなのです。継続的な改善モデルであるべきであり、変更がないことは実際には良いことではありません。このような理由でチームが新しいテクノロジーの採用を控えている場合は、この状況につながっている問題についてより深く分析する必要があるかもしれません。コンテナ以外のより大きな戦略があるかもしれません。
  
  
• インフラストラクチャの自動化が遅れている。現在、すべてのインフラストラクチャを担当するチームがインフラストラクチャの自動化に追いつくのに苦労している場合、インフラストラクチャの自動化を必要とする新しいテクノロジーの導入は困難になる可能性があります。これらのチームがインフラストラクチャの管理方法に革新をしていないと、特に組織がここに挙げた最初の 2 つの課題のいずれかに該当する場合、これらの新しいテクノロジーを取り入れたがらないことがあります。
  
  課題に直面する:コンテナ戦略に取り組む前に、この課題は、組織がインフラストラクチャをどのように自動化するか(または場合によっては自動化しないか)に優先事項が焦点を当てていることを示している可能性があります。チームが自動化を優先する方法に全体的に投資することは、最初のステップかもしれません。コンテナ戦略がそれを実現する方法かもしれませんが、この文化的な採用が機能するところまでチームを導くためには、まずここでいくつかの小さなステップを踏む必要があるかもしれません。

• すべてのCIOがKubernetesを検討すべき5つのビジネス上の理由、Kalyan Ramanathan、Sumo Logic
• コンテナとは何ですか、なぜ必要なのですか?、ポール・ルーベンス、cio.com
• Docker リファレンス アーキテクチャ: Docker Enterprise のセキュリティ保護とセキュリティのベスト プラクティス港湾労働者
• Kubernetes as a Service: GKE 対 AKS 対 EKS、Evan Klein 氏、logz.io

ジェイソン・セント・シール、フィッシュタンク・コンサルティング、エンゲージメント担当バイスプレジデント
https://jasonstcyr.com