Amazon AWSサービスのDevOps

クラウドサービスの使用により提供される効率は、今日の多くのIT企業の変革の主な傾向の1つです。 GITコードから開発および/または本番 環境への展開に至るまでのすべてのプロセスの自動化、およびその後の監視、インシデント対応など。 （自動化することもできますし、自動化する必要があります）-これらすべては、そうでない場合、一般に認識されている多くのITILプラクティスを大幅に変更します。 Amazon AWSの観点からのDevOpsプロセスの概観 ：IaaC（ コードとしてのインフラストラクチャ ）コンセプトのフレームワーク内でのサービスへの実装方法-これらはすべて、Amazon AWS コードサービスに関する一連の記事で提供されます： CodeCommit 、 CodeBuild 、 CodeDeploy 、 CodePipeline 、 CodeStar 。



この記事は最初の概要です。



この記事の目的は、DevOpsに関する教育プログラムではなく、 元のソースから既に入手可能な資料の些細な複製でもありません。 目標は、DevOpsの実装を一般的な形式でAmazon AWSサービスに提示することであり、誰でも自由に適切なオプションを選択できます。 対象読者は少なくともAmazon AWSの存在に精通しており、仕事でその機能を使用してプロセスを部分的または完全に転送する予定です。 提供されたAmazon AWSサービスは高速で増加し、その数は既に100のラウンドマークを超えています。したがって、AWSの優れた経験があっても、新機能を見つけることが役立つ場合があります。彼らの仕事に成功する。

キューブではない（のみ）

誰か、特にAmazon AWSの十分な経験がない人のためのいくつかの一般的だが重要な言葉。 ロゴに描かれたキューブは、論理的に正しく主なアイデアを伝えます。AmazonAWSは、サービスのセットを提供し、誰でも必要なものを組み立てることができるコンストラクタです。 ただし、目的のキューブ（サービス）がニーズを満たさない場合、この「キュービック中心」の瞬間だけが反発する可能性があります。 この場合、異なるタスクを使用して同じタスクを解決でき、多くのサービスがさまざまな方法で相互に複製できるため、リクエストに一致しないAmazon AWSサービスはその使用をキャンセルせず、単に検索する理由を与えることを覚えておく必要があります適切です。 結局のところ、Amazon AWSサービスは、主に彼ら自身のニーズのために運用の結果として登場しました。 Amazon AWSは数千の小さなチーム（ 2つのピザチームと呼ばれます）を採用しており、それぞれが独自の作業方法（言語、OS、構造、プロトコルなど）を自由に選択できるため、最初はAmazon AWSで利用可能なサービスそのような動物園の多様性をサポートする必要があり、それらはすでにAmazon AWS内で動作しています。



これは、使用する必要があるものを伝えるだけでなく、一方で、通常の既存のプロセスおよびデバッグされたプロセスと統合する機能を提供するために設計されたAmazon AWS Codeサービスにとって特に重要です一方、独自の実装を提供するツールは、通常、Amazon AWS機能を活用するときに最も効果的です。

DevOps Amazon AWS Designer

各キューブを個別に十分に理解していても、それらからどの家を建てることができるかは常に明確ではありません。 したがって、これらのサービスを1つの図にまとめて、そのようなコンストラクターから何をアセンブルできるかについての一般的なアイデアを得るようにします。 Code- servicesを選択し、それらを通常のプロセスと関連付けると、次のような設計になります。







各Code-サービスについて簡単に説明します（詳細については、後で各サービスについて個別に説明します）。

AWS CodeCommit

最も明白で理解しやすいサービスは、GITのAmazon実装であり、これは完全に繰り返されます。 作業と対話（チーム）の点でGITと違いはありません。実際には、 IAMサービスを介したアクセスの整理など、AWSサービス構造への直接統合に必要です。 コード自体はS3に保存されます。

AWS CodeBuild

アセンブリサーバー-Javaなど、展開前にアセンブリを必要とするプロジェクト用。 デフォルトでは、Ubuntuに基づいてコンテナを起動しますが、独自のコンテナを指定できます。





プラグインを介したJenkinsとの統合をサポートします 。



組み立てに加えて、テストも同様に実行できます。 そして、これは彼の主な目的ではありませんが、彼はそのように選ぶことができます。





したがって、AWS CodeBuildは 「テスト」段階にも存在します。

AWS CodeDeploy

事前にインストールされたエージェントと柔軟な設定を使用して、あらゆる環境で機能するコードを展開するためのサービス。 特別な違いは、エージェントがAmazon AWS仮想マシンだけでなく、「外部」でも動作することです。これにより、次のような最も多様なソフトウェアを一元的にデプロイできます。 そしてローカル。

AWS CodePipeline

メイン図からわかるように、前の3つのサービスとやり取りし、目的の順序でサービスを開始し、実際、DevOpsプロセスの自動化を提供します。



次のステップを開始する前に、プロセスブランチの整理、サードパーティサービスの開始（たとえば、テスト用）、並列ブランチの作成、確認の要求（ 承認アクション ）を行うことができます。 全体として、これはAmazon AWSでDevOpsを整理するための中心的なツールです。

AWS CodeStar

本質的にCodePipelineを複製しますが、起動と設定を簡単にするために研ぎ澄まされており、幅広い既製のテンプレート（ 多数のアプリケーション言語用）とモニタリングサービス（ CloudWatch ）と統合するプラグインと統合のためのプラグインを備えた本当に便利なダッシュボードを使用して解決されますジラと。

Amazon AWS IaaCサービス

Infrastructure as Codeの概念を実装するAmazon AWSサービスは次のとおりです。

• 弾性豆茎
• Opsworks
• 雲形成

多くの場合、どちらを選択するのか、3つのサービスがデプロイ段階のメインダイアグラムにある同じもの（インフラストラクチャとアプリケーションのデプロイ）向けに設計されている理由について疑問が生じます。 要するに、それらの使用は次のように表すことができます。







つまり、何かを迅速に行うために（そして、これが悪いことを意味するわけではありません）、これは標準機能（単純なサイトなど）です-Elastic Beanstalkを使用すると便利です。 これが多くのネストされた要素とネットワーク設定の深刻な要件を伴う複雑なプロジェクトである場合、 CloudFormationを使用せずに行うことはできません。 中間の何かとして-ChefベースのOpsWorksの使用のようです 。



ただし、実際には（そして通常は複雑なプロジェクトで使用されます）3つすべての組み合わせ： CloudFormationはメインインフラストラクチャ（ VPC 、サブネット、リポジトリ、アクセスに必要なIAMのロールを作成するなど）を上げ、 OpsWorksスタックを起動します。実行中のvirtualoksの内部コンポーネントを既に柔軟に構成できます。 また、開発プロセスの利便性のために、 CloudFormationはElastic Beanstalkコンポーネントのスタックを上げることができるため、 .ebextensions自体を使用する開発者は、単純な構成ファイルを変更するだけで、実行中のアプリケーションのパラメーター（使用する仮想マシンの数と種類、 ロードバランサーの使用など）を変更できますコミット後に自動的に変更が適用されたとき（アプリケーションインフラストラクチャを含む）のコードを含むフォルダー。

AWSラムダ

それとは別に、 ServerLessアーキテクチャの概念を実装するLambdaサービスについて言及する価値があります 。これは、一方ではElastic Beanstalkに似ており、AWS Codeサービスを使用してDevOpsプロセスに入力できます。 一方、AWS Lambdaは、Amazon AWSのあらゆるもののための優れた（必読の）オートメーションツールです。 相互作用を伴うすべてのプロセスは、 Lambdaを使用して接続できます。 たとえば、サービス（ 仮想マシン 、クラスター）を再起動し、メールで管理者にエラーメッセージを送信することにより、 CloudWatchのモニタリング結果を処理して応答できます。 また、DevOpsプロセスの接続にも使用されます。たとえば、ビルドメソッドとテストを実行した後、一般的な方法でDeployに転送します。 一般に、AWS Lambdaを使用すると、最も複雑なロジックを実装できますが、これは現在のAmazon AWSサービスのセットではまだ利用できません。



これらのサービスに加えて、他のサービスがDevOpsプロセスに関与している場合があります。 したがって、使用するサービスの一般的なスキームを提示しようとすると、状況が非常にわかりにくくなる可能性があります（以下は単なる条件付きの例です）。







すべてが視覚的に送信できるわけではありません、なぜなら AWS IAMアクセスコントロールサービスなどのグローバルエンティティが浸透し、ほぼすべてのコンポーネントに存在します。 EC2サービスの計算能力に基づいて、他のすべてのサービスが機能します。 S3ストレージサービスは、他の多くのサービス間でデータを転送するために使用されます。 また、AWS Service Catalogなどの高レベルのサービスは、さまざまなAmazon AWSアカウント間の相互作用などを提供できます。



さらに、個々のサービスのより詳細な考慮事項として、分かりやすく理解しにくいツールのセットに混乱して理解できないスキームが出現し、誰でも必要なものを選択できます。



DevOpsプロセスに関与できるAmazon AWSサービスの一般的なスキームに基づく合計。 最も人気のあるバンドルは、 CodePipeline / CodeCommit + ElasticBenstalk / OpsWorks as Deployのようなものです。 そして、「すぐに見える」ために-CodeStarは良いです。 確かに 、 AWS CodeStarは支払われますが、ここでは、選択の一般的な考え方を示すためにコストファクターが意図的に考慮されませんでした。Jenkinsの仲間のような人気のあるCI / CDプロジェクトの必要なプラグインを使用するなど、各コンポーネントを自由に使用できるためです



参照：

• AWSでDevOpsパイプラインを高速化： ビデオ 、 プレゼンテーション