ブログ

applicationサービスと CD パイプライン

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2016 年 2 月 25 日公開

データ センターの会話で主流となるすべてのテクノロジと同様に、DevOps も現在、定義疲れに悩まされています。 実際、この時点では疲労だと思いますが、その境界線は判断が難しいです。 DevOps は、クラウドや SDN と同様に、広く受け入れられている定義からは程遠いと言えば十分でしょう。

しかし、DevOps は、その複合概念がしばしば混乱したり、混同されたりする点でも独特です。 たとえば、CD は「継続的デリバリー」または「継続的デプロイメント」を意味します。 これら 2 つは同じものではなく、混同したり混同したりすべきではありません。 Puppet Labs はブログ投稿でその違いをわかりやすく説明しました。

 

 

継続的デリバリー継続的デプロイメント

決定的な違いは、本番環境へのデプロイメントが「手動」（継続的デリバリー）であるか「自動」（継続的デプロイメント）であるかであることがわかります。  

問題は、「本番環境にデプロイ」というラベルの付いた小さなオレンジ色のボックスに、自動化する必要がある大量の作業があるということです。 これは、アプリとその依存関係 (データベース、その他のサービス、インフラストラクチャなど) をデプロイするだけではありません。 また、applicationを最終消費者に提供するために必要なすべてのネットワークおよびapplicationサービスを展開することも重要です。  ここでapplicationサービスが機能し、application配信 (開発の観点ではなく、運用の観点) が継続的デプロイメント パイプラインに組み込まれます。

継続的デプロイメント パイプライン内の「本番環境へのデプロイ」ステップを自動化するには、多くの可動部分をプロビジョニング、構成、テストする必要があります。 つまり、基本的なネットワークからセキュリティ (ファイアウォールなど)、可用性 (負荷分散)、パフォーマンス (高速化、キャッシュなど) のサービスまで、あらゆるサービスが含まれます。 平均して、組織は高速で安全かつ可用性の高いapplicationsのニーズを満たすために、 11 種類の異なるapplication配信サービスを使用しています。 それぞれを展開 (プロビジョニングおよび構成) する必要があり、一部は他の展開に依存します。

これらの各サービス (一緒に遊んでいる方のために説明すると、これはセント アイブスの謎のようなものです) には、構成する必要のあるさまざまな特性、true または false に設定するオプション、選択するアルゴリズム、確立するルートなどがあります。

言い換えれば、「手動」から「自動」への切り替えは、思ったほど簡単ではありません。

ネットワークを妨げているものは何ですか?

これらのプロセスを自動化する際の大きな障害は、共有コンポーネントとアプリごとのコンポーネントの違いにあります。 アプリケーション インフラストラクチャ領域で Infrastructure as Code が可能なのは、インフラストラクチャ (Web サーバーやロード バランサーなど) をapplication専用にできるためです。 つまり、その構成ファイルは一種のマイクロサービスのようなもので、ローカライズされており、 1 つのapplicationにサービスを提供することに重点が置かれています。

 

 

CD制作中

ネットワークやアプリ サービスの世界に移ると、必ずしもそうとは限りません。 たとえば、ルーターやスイッチは、複数のapplicationsに接続および転送サービスを提供する目的で設計されています。 つまり、構成ファイルは必然的に複数のapplicationsを網羅することになります。 ここではバージョン管理が役立つかもしれませんが、構成はアプリではなくデバイスに大きく結びついているというのが現実です。アプリのサービスとセキュリティについても同じことが言えます。

したがって、API が CLI となる世界に向かって私たち全員が移行しているのは良いことですが、構成をアプリケーションごとに管理できるアプリごと (またはアプリ中心) のパラダイムをサポートする必要性にも対処する必要があります。

つまり、サービスがアプリごとに展開および構成されるマイクロサービス スタイルのネットワーク アーキテクチャに移行することを意味します。 これは、専用の「デバイス」（仮想またはハードウェア、フォーム ファクターはこの説明では無関係）またはテンプレートなどのアプリ固有の構成のいずれかの形をとることができます。

もう着きましたか？

API を使用してアプリケーションごとにテンプレート (コードとしてのインフラストラクチャ) を展開するプロビジョニングと管理の宣言型モデルにより、目標に近づいていますが、まだそこには至っていません。 継続的なデプロイメントを完全に成功させるために必要な自動化をどのように調整するかを考える領域では、まだやるべき作業が数多く残っています。

継続的デリバリーから継続的デプロイメントへの移行を完了する上で重要な「本番環境へのデプロイ」ステップを「手動」から「自動」に移行する場合は、ネットワーク、インフラストラクチャ、アプリ サービス、およびセキュリティ サイロを含める必要があります。 つまり、自動化レイヤーでの作業が増えるだけでなく、最終的に本番環境への継続的な展開を推進するプロセスを完全に自動化するために必要な包括的なオーケストレーションも必要になります。