技術

AWSでのTerraformによるダウンタイムゼロのJenkins継続的デプロイ

文字通りすべてが24時間年中無休で稼働する必要がある今日のインターネットの世界では、信頼性が鍵となります。これは、最新リリースのロールアウト中に、Webサイトのダウンタイムがほぼゼロになり、恐ろしい「見つかりません：404」エラーページやその他のサービスの中断を回避することを意味します。

クライアントまたはおそらく自分自身のために新しいアプリケーションを構築し、そのアプリケーションを気に入った優れたユーザーベースを獲得できたとします。ユーザーからフィードバックを収集し、開発者のところに行き、新しい機能を構築してアプリケーションをデプロイできるようにするように依頼します。これで、アプリケーション全体を停止して新しいバージョンをデプロイするか、ダウンタイムゼロのCI / CDデプロイパイプラインを構築して、手動で介入することなく新しいリリースをユーザーにプッシュするという面倒な作業をすべて行うことができます。

この記事では、後者について正確に説明します。Terraformをインフラストラクチャオーケストレーターとして使用して、AWSクラウド上のNode.jsに構築された3層Webアプリケーションの継続的デプロイパイプラインを作成する方法について説明します。使用しますジェンキンス継続的デプロイ部分とBitbucketがコードベースをホストします。

コードリポジトリ

コードを見つけることができるデモの3層Webアプリケーションを使用しますここに。

リポジトリには、WebレイヤーとAPIレイヤーの両方のコードが含まれています。これは、ウェブモジュールがAPIレイヤーのエンドポイントの1つを呼び出し、データベースから現在の時刻に関する情報を内部的にフェッチしてウェブレイヤーに戻るシンプルなアプリケーションです。

レポの構造は次のとおりです。

火： APIレイヤーのコード
ウェブ： Webレイヤーのコード
Terraform： Terraformを使用したインフラストラクチャオーケストレーションのコード
ジェンキンス： CI / CDパイプラインに使用されるJenkinsサーバーのインフラストラクチャオーケストレーターのコード。

デプロイする必要があるものがわかったので、このアプリケーションをAWSにデプロイするために必要なことについて説明し、次にCI / CDパイプラインのその部分を作成する方法について説明します。

画像を焼く

インフラストラクチャオーケストレーターにTerraformを使用しているため、デプロイする層またはアプリケーションごとにプリベークされたイメージを用意するのが最も理にかなっています。そのためには、Hashicorpの別の製品であるPackerを使用します。

Packerは、AWSでのデプロイに使用されるAmazonマシンイメージまたはAMIの構築に役立つオープンソースツールです。 EC2、VirtualBox、VMwareなどのさまざまなプラットフォーム用のイメージを構築するために使用できます。

これは、Packer構成ファイル（terraform/packer-ami-api.json）を使用してAPIレイヤーのAMIを作成する方法のスニペットです。

{ 'builders': [{ 'type': 'amazon-ebs', 'region': 'eu-west-1', 'source_ami': 'ami-844e0bf7', 'instance_type': 't2.micro', 'ssh_username': 'ubuntu', 'ami_name': 'api-instance {{timestamp}}' }], 'provisioners': [ { 'type': 'shell', 'inline': ['mkdir api', 'sudo apt-get update', 'sudo apt-get -y install npm nodejs-legacy'], 'pause_before': '10s' }, { 'type': 'file', 'source' : '../api/', 'destination' : 'api' }, { 'type': 'shell', 'inline': ['cd api', 'npm install'], 'pause_before': '10s' } ] }

また、AMIを作成するには、次のコマンドを実行する必要があります。

packer build -machine-readable packer-ami-api.json

このコマンドは、この記事の後半でJenkinsビルドから実行します。同様に、WebレイヤーにもPacker構成ファイル（terraform/packer-ami-web.json）を使用します。

上記のPacker構成ファイルを調べて、何をしようとしているのかを理解しましょう。

前述のように、Packerを使用してイメージを構築できます多くのプラットフォーム、そしてアプリケーションをAWSにデプロイしているので、ビルダー「amazon-ebs」を使用します。これは、開始するのが最も簡単なビルダーです。
構成の2番目の部分は、イメージの構成に使用できるスクリプトまたはコードブロックに似たプロビジョナーのリストを取得します。
- ステップ1 シェルプロビジョナーを実行してAPIフォルダーを作成し、inlineを使用してイメージにNode.jsをインストールしますプロパティ。実行するコマンドのセットです。
- ステップ2 ファイルプロビジョナーを実行して、ソースコードをAPIフォルダーからインスタンスにコピーします。
- ステップ3 再びシェルプロビジョナーを実行しますが、今回はscriptプロパティを使用して、実行する必要のあるコマンドでファイル（terraform / scripts / install_api_software.sh）を指定します。
- ステップ4 次のステップでインストールされるCloudwatchに必要なインスタンスに設定ファイルをコピーします。
- ステップ5 シェルプロビジョナーを実行してAWSCloudwatchエージェントをインストールします。このコマンドへの入力は、前の手順でコピーされた構成ファイルになります。 Cloudwatchについては、この記事の後半で詳しく説明します。

したがって、本質的に、Packer構成には、必要なビルダーに関する情報と、イメージの構成方法に応じて任意の順序で定義できるプロビジョナーのセットが含まれています。

Jenkins継続的デプロイのセットアップ

次に、CI / CDパイプラインに使用されるJenkinsサーバーのセットアップについて検討します。これもセットアップにTerraformとAWSを使用します。

Jenkinsを設定するためのTerraformコードは、フォルダーjenkins/setup内にあります。この設定の興味深い点をいくつか見ていきましょう。

AWS認証情報： AWSアクセスキーIDとシークレットアクセスキーをTerraformAWSプロバイダー（instance.tf）に提供するか、認証情報ファイルの場所をプロパティshared_credentials_fileに提供することができます。 AWSプロバイダーで。
IAMの役割： JenkinsサーバーからPackerとTerraformを実行するため、AWSのS3、EC2、RDS、IAM、負荷分散、自動スケーリングサービスにアクセスします。したがって、これらのサービスにアクセスするためにJenkins for Packer＆Terraformに資格情報を提供するか、IAMプロファイル（iam.tf）を作成して、それを使用してJenkinsインスタンスを作成します。
テラフォーム状態： Terraformは、ファイル内のどこかにインフラストラクチャの状態を維持する必要があります。S3（backend.tf）を使用すると、インフラストラクチャの状態をそこに維持できるため、他の同僚と共同作業を行うことができ、状態が離れた場所で管理されます。
公開鍵と秘密鍵のペア： Jenkinsインスタンスが起動したら、SSHで接続できるように、キーペアの公開鍵をインスタンスと一緒にアップロードする必要があります。私たちは定義しました aws_key_pair Terraform変数を使用して公開鍵の場所を指定するリソース（key.tf）。

Jenkinsを設定する手順：

ステップ1： Terraformのリモート状態を維持するには、Terraformで使用できるバケットをS3で手動で作成する必要があります。これは、Terraformの外部で実行される唯一のステップです。必ずAWS configureを実行してください以下のコマンドを実行してAWS認証情報を指定する前に。

aws s3api create-bucket --bucket node-aws-jenkins-terraform --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1

ステップ2： terraform initを実行します。これにより、状態が初期化され、S3に保存されるように設定され、AWSプロバイダープラグインがダウンロードされます。

プレゼンテーションのデザイン方法

ステップ3： terraform applyを実行します。これにより、すべてのTerraformコードがチェックされ、プランが作成され、このステップの完了後に作成されるリソースの数が示されます。

ステップ4： yesと入力すると、前の手順ですべてのリソースの作成が開始されます。コマンドが終了すると、JenkinsサーバーのパブリックIPアドレスを取得します。

ステップ5： 秘密鍵を使用して、JenkinsサーバーにSSH接続します。 ubuntu AWSEBSでサポートされているインスタンスのデフォルトのユーザー名です。 terraform applyによって返されたIPアドレスを使用しますコマンド。

ssh -i mykey [email protected]

ステップ6： http://34.245.4.73:8080に移動して、Jenkins WebUIを開始します。パスワードは/var/lib/jenkins/secrets/initialAdminPasswordにあります。

ステップ7： 「推奨プラグインのインストール」を選択し、Jenkinsの管理者ユーザーを作成します。

JenkinsとBitbucket間のCIパイプラインの設定

このために、JenkinsにBitbucketプラグインをインストールする必要があります。に移動 Jenkinsの管理→プラグインの管理 とから 利用可能なプラグイン インストールします Bitbucket プラグイン。
Bitbucketリポジトリ側で、 設定→Webhook 、新しいWebhookを追加します。このフックは、リポジトリ内のすべての変更をJenkinsに送信し、パイプラインをトリガーします。

画像をベイク/ビルドするためのJenkinsパイプライン

次のステップは、Jenkinsでパイプラインを作成することです。
最初のパイプラインは、Packerを使用してアプリケーションのAMIを構築するために使用されるFreestyleプロジェクトになります。
Bitbucketリポジトリの認証情報とURLを指定する必要があります。
ビルドトリガーを指定します。
2つのビルドステップを追加します。1つはアプリモジュール用のAMIをビルドするためのもので、もう1つはWebモジュール用のAMIをビルドするためのものです。
これが完了すると、Jenkinsプロジェクトを保存できます。これで、Bitbucketリポジトリに何かをプッシュすると、Jenkinsで新しいビルドがトリガーされ、AMIが作成され、そのイメージのAMI番号を含むTerraformファイルがビルドステップの最後の2行からわかるS3バケット。

echo 'variable 'WEB_INSTANCE_AMI' { default = ''${AMI_ID_WEB}'' }' > amivar_web.tf aws s3 cp amivar_web.tf s3://node-aws-jenkins-terraform/amivar_web.tf

TerraformスクリプトをトリガーするJenkinsパイプライン

APIとWebモジュールのAMIができたので、ビルドをトリガーして、アプリケーション全体をセットアップするためのTerraformコードを実行し、後でこのパイプラインにサービスのダウンタイムなしで変更をデプロイさせるTerraformコードのコンポーネントを調べます。

別のフリースタイルのJenkinsプロジェクトnodejs-terraformを作成します。このプロジェクトは、Terraformコードを実行してアプリケーションをデプロイします。
まず、グローバル資格情報ドメインに「シークレットテキスト」タイプの資格情報を作成します。これは、Terraformスクリプトへの入力として使用されます。 TerraformとGit内でRDSサービスのパスワードをハードコーディングしたくないため、Jenkins認証情報を使用してそのプロパティを渡します。
他のプロジェクトと同様に、資格情報とURLを定義する必要があります。
ビルドトリガーセクションでは、前のプロジェクトが終了したときにこのプロジェクトが開始されるように、このプロジェクトを他のプロジェクトとリンクします。
次に、バインディングを使用してプロジェクトに以前に追加した資格情報を構成できるため、ビルドステップで使用できます。
これで、ビルドステップを追加する準備が整いました。ビルドステップでは、前のプロジェクトによってS3にアップロードされたTerraformスクリプトファイル（amivar_api.tfおよびamivar_web.tf）をダウンロードし、Terraformコードを実行してアプリケーション全体をビルドします。 AWS。

すべてが適切に構成されている場合、コードをBitbucketリポジトリにプッシュすると、最初のJenkinsプロジェクトがトリガーされ、次に2番目のプロジェクトがトリガーされ、アプリケーションがAWSにデプロイされます。

httpライブストリーミング.tsファイルをダウンロードしてマージします

AWSのTerraformゼロダウンタイム構成

次に、このパイプラインがダウンタイムなしでコードをデプロイするのは、Terraformコードの内容について説明します。

まず、Terraformがこれらを提供することですライフサイクル構成ブロックためにリソースその中であなたはオプションを持っています create_before_destroy 文字通り、Terraformが現在のリソースを破棄する前に同じタイプの新しいリソースを作成する必要があることを意味するフラグとして。

ここで、この機能をaws_autoscaling_groupで活用します。およびaws_launch_configurationリソース。だからaws_launch_configurationプロビジョニングするEC2インスタンスのタイプと、そのインスタンスにソフトウェアをインストールする方法、およびaws_autoscaling_groupを設定しますリソースはAWS自動スケーリンググループを提供します。

ここで興味深いのは、Terraformのすべてのリソースに一意の名前とタイプの組み合わせが必要なことです。したがって、新しいaws_autoscaling_groupに別の名前がない限りおよびaws_launch_configuration、現在のものを破棄することはできません。

Terraformは、name_prefixを提供することでこの制約を処理しますaws_launch_configurationへのプロパティ資源。このプロパティが定義されると、Terraformはすべてのaws_launch_configurationに一意のサフィックスを追加しますリソースを選択すると、その一意の名前を使用してaws_autoscaling_groupを作成できます。資源。

上記のすべてのコードはterraform/autoscaling-api.tfで確認できます。

resource 'aws_launch_configuration' 'api-launchconfig' { name_prefix = 'api-launchconfig-' image_id = '${var.API_INSTANCE_AMI}' instance_type = 't2.micro' security_groups = ['${aws_security_group.api-instance.id}'] user_data = '${data.template_file.api-shell-script.rendered}' iam_instance_profile = '${aws_iam_instance_profile.CloudWatchAgentServerRole-instanceprofile.name}' connection { user = '${var.INSTANCE_USERNAME}' private_key = '${file('${var.PATH_TO_PRIVATE_KEY}')}' } lifecycle { create_before_destroy = true } } resource 'aws_autoscaling_group' 'api-autoscaling' { name = '${aws_launch_configuration.api-launchconfig.name}-asg' vpc_zone_identifier = ['${aws_subnet.main-public-1.id}'] launch_configuration = '${aws_launch_configuration.api-launchconfig.name}' min_size = 2 max_size = 2 health_check_grace_period = 300 health_check_type = 'ELB' load_balancers = ['${aws_elb.api-elb.name}'] force_delete = true lifecycle { create_before_destroy = true } tag { key = 'Name' value = 'api ec2 instance' propagate_at_launch = true } }

また、ダウンタイムがゼロのデプロイメントでの2番目の課題は、新しいデプロイメントが要求の受信を開始する準備ができていることを確認することです。状況によっては、新しいEC2インスタンスをデプロイして開始するだけでは不十分です。

その問題を解決するには、aws_launch_configurationプロパティがありますuser_dataネイティブAWS自動スケーリングをサポートしますuser_data自動スケーリンググループの一部として、新しいインスタンスの起動時に実行するスクリプトを渡すことができるプロパティ。この例では、アプリサーバーのログを追跡し、起動メッセージが表示されるのを待ちます。 HTTPサーバーをチェックして、いつ起動するかを確認することもできます。

until tail /var/log/syslog | grep 'node ./bin/www' > /dev/null; do sleep 5; done

それに加えて、aws_autoscaling_groupでELBチェックを有効にすることもできます。リソースレベル。Terraformが古いインスタンスを破棄する前に、ELBチェックに合格するために新しいインスタンスが追加されたことを確認します。これは、APIレイヤーのELBチェックがどのように見えるかです。 /api/statusをチェックします成功を返すエンドポイント。

resource 'aws_elb' 'api-elb' { name = 'api-elb' subnets = ['${aws_subnet.main-public-1.id}'] security_groups = ['${aws_security_group.elb-securitygroup.id}'] listener { instance_port = '${var.API_PORT}' instance_protocol = 'http' lb_port = 80 lb_protocol = 'http' } health_check { healthy_threshold = 2 unhealthy_threshold = 2 timeout = 3 target = 'HTTP:${var.API_PORT}/api/status' interval = 30 } cross_zone_load_balancing = true connection_draining = true connection_draining_timeout = 400 tags { Name = 'my-elb' } }

まとめと次のステップ

これで、この記事の終わりになります。うまくいけば、これまでに、JenkinsデプロイメントとTerraformのベストプラクティスを使用してダウンタイムゼロのCI / CDパイプラインでアプリケーションをデプロイして実行しているか、この領域を探索してデプロイメントに手動の介入をほとんど必要としないようにすることに少し慣れています。可能。

この記事では、使用されている展開戦略をBlue-Green展開と呼びます。現在のインストール（Blue）は、新しいバージョン（Green）の展開とテスト中にライブトラフィックを受信し、新しいバージョンがすべての準備ができました。この戦略とは別に、アプリケーションをデプロイする方法は他にもあります。これについては、この記事で詳しく説明しています。展開戦略の概要。別の戦略の適応は、Jenkinsパイプラインを構成するのと同じくらい簡単になりました。

また、この記事では、API、ウェブ、データレイヤーのすべての新しい変更に互換性があることを前提としているため、新しいバージョンが古いバージョンと通信することを心配する必要はありません。しかし、実際には、常にそうであるとは限りません。この問題を解決するには、新しいリリース/機能を設計する際に、常に下位互換性レイヤーについて考えてください。そうしないと、その状況を処理するためにデプロイメントを微調整する必要があります。

統合テストは、このデプロイメントパイプラインにも欠けているものです。テストせずにエンドユーザーに何もリリースしたくないので、これらの戦略を自分のプロジェクトに適用するときは、間違いなく覚えておく必要があります。

Terraformの仕組みと、テクノロジーを使用してAWSにデプロイする方法について詳しく知りたい場合は、お勧めします Terraform AWSクラウド：健全なインフラストラクチャ管理 ここでは、仲間のApeeScapeerRadosławSzalskiがTerraformについて説明し、チーム用にマルチ環境で本番環境に対応したTerraformセットアップを構成するために必要な手順を示します。

基本を理解する

Terraformとは何ですか？

Terraformは、バージョン管理されたインフラストラクチャコードを簡単に作成できるツールです。これを使用して、AWS、Alicoud、GCP、Azure、OpenStackなどの100を超えるさまざまなサービスプロバイダーのインフラストラクチャを調整できます。

CI / CDとは何ですか？その利点は何ですか？

継続的インテグレーションと継続的デプロイは、コードが変更されるたびにソフトウェアを統合してテストする方法です。その後、そのコードは本番環境にデプロイされます。主な利点は、展開中の手作業と人的エラーの可能性を減らすことです。

さまざまな展開戦略とは何ですか？

製品と技術的な実装方法に応じて、ローリング戦略、再作成戦略、青緑色、A / Bテスト、カナリア展開、またはシャドウ戦略を選択できます。

パッカーとは何ですか？

Packerは、AWS EC2、Virtual Box、VMWareなどのさまざまなプラットフォーム用のマシンイメージを簡単に構築できるようにするツールです。

Jenkinsで何ができますか？

Jenkinsは、ソフトウェアチームがプロジェクトの統合パイプラインを構築できるようにする継続的インテグレーションツールです。 Jenkinsを利用したパイプラインをカスタマイズして、ビルド、テスト、ステージングなどのさまざまなソフトウェア開発プロセスを含めたり、コードの静的分析を実行したりできます。