[レポート] Amazon Lightsail で開発/テスト環境を作成してみるワークショップに参加しました #reinvent #CMP224-R1

こんにちは！SHIOです。
Amazon Lightsailにて開発/テスト環境を作成し、本番ワークロードに移行する方法を学ぶワークショップに参加しました。そちらの様子をレポートしたいと思います！

概要

Creating development sandboxes and testing environments outside of your production environment lets you test without the concern of breaking something or spending large amounts of money. Amazon Lightsail provides lightweight virtual servers and other cloud resources at a low, predictable price, which allows you to test solutions in a low-risk way. In this workshop, learn how you can easily migrate your development resources in Lightsail to run production environments on Amazon EC2 and other AWS services. Learn about how to run your dev/test environments on Lightsail and migrate them to production workloads. You must bring your laptop to participate.

以下日本語verです。

本番環境の外に開発用のサンドボックスやテスト環境を作ることで、何かを壊したり、多額の費用をかけたりする心配なくテストすることができます。Amazon Lightsailは、軽量な仮想サーバーやその他のクラウドリソースを低価格で提供し、低リスクでソリューションをテストすることができます。このワークショップでは、Lightsailで開発したリソースを簡単に移行して、Amazon EC2やその他のAWSサービス上で本番環境を実行する方法を学びます。Lightsail上で開発/テスト環境を動作させ、本番ワークロードに移行する方法について学びます。参加にはノートPCの持参が必要です。

レポート

Agenda

Lightsailの概要、ステージング/開発/本番各環境の役割についての説明、最後にワークショップのシナリオについての説明がありました。以下内容をまとめていきます。

Amazon Lightsail

Amazon Lightsailは、使いやすい仮想プライベートサーバー (VPS) インスタンス、コンテナ、ストレージ、データベースなどを費用効果の高い月額料金で提供します。

What's in the bundle?

全てのLightsailのインスタンスには下記が含まれています。

• コンピューティング(vCPU)
• SSDベースのストレージ(ディスク)
• 無料データ転送枠
• 予測可能な低価格の料金

Additionally:

• DNS管理
• 静的IPアドレス
• CDN
• オブジェクトストレージ
• 他AWSサービスとの統合

Lightsail is great for...

どのような使用用途の場合にLightsailが適しているかのお話がありました。

• Simple web applications
  LAMP, Nginx, MEAN, Django, Node.jsなどの開発スタックが用意されています。

• Websites
  WordPress, Magento, Drupal, Ghost, Plesk, Joomlaなどクリックするだけで設定済みのアプリケーションをインストールできます。

• Business software
  ファイル共有ストレージ、バックアップ、財務・会計ソフトウェアなど独自のアプリケーションを立ち上げることができます。

Application development lifecycle

Production, Staging, Developmentの3つの環境についてです。

開発環境: コード/修正
ステージング環境: 本番環境のデータでテスト
本番環境: (本番環境では修正作業はしない)

● Development(DEV)
・すべてのコードの更新を行う環境
・開発環境は本番環境には何も接続されないので、コードのバグ、Dev環境の問題が顧客に影響を与えることはない
・次のステージへ行く前に開発環境で多くのテストを行い、すべてがうまくいっていることを確認する必要がある

● Staging(STAGE)
・可能な限り本番環境に類似している
・この段階ではまだ本番環境のシステムには一切触れない
・本番環境で使用されているできるだけ多くのサービスもステージ環境でミラーリングする必要がある
・ステージング環境では本番環境にコードをリリースする前にすべての最終テストが行われる
・本番稼働前のすべての適合・仕上げ作業が行われる

● Production(PROD)
・それぞれの環境は重要だけど、本番環境はユーザが利用する環境であるため最も重要
・本番環境はコードの最終的な環境となる
・この環境でのすべての変更は顧客に影響する

Scenario description

ワークショップのシナリオです。

1. CI/CDパイプラインの設定とデプロイ
2. DEV と STAGE インスタンス用の環境作成
3. ウェブサイトテンプレートのダウンロードと編集
4. Git Repoに変更をコミット
5. 変更をステージングインスタンスにデプロイする

ワークショップ

それではいよいよワークショップの開始です。

0 - Introduction

Welcome! の文字とともに本ワークショップに関する説明がありました。
上記で書いたシナリオと同じような内容なので省略します。

1 - Initial Setup

CI/CDパイプラインをセットアップ後、CodeDeployはS3を使用してデプロイパッケージを保存するためCodeDeployエージェントがS3バケットを使用できるようにアクセス許可を作成・設定します。
また、CodeCommitへすべてのコードをコミットし、バージョン管理をします。

1. S3バケットの作成

2. ロール、ポリシー、ユーザの作成

3. CodeCommitとCodeDeployの設定
   CodeCommitでrepositoryの作成、CodeDeployでapplicationを作成します。

できました！

2 - Amazon Lightsail Instances

事前設定は終わりましたので、次にインスタンスを作成・設定していきます。

1. ステージングインスタンスのデプロイ
2. 開発インスタンスのデプロイ
3. AWS CLIを開発インスタンスに設定する
4. CodeDeployエージェントをステージングインスタンスに設定する
5. ステージングインスタンスに静的IPアドレスを付与する
6. CodeDeployにステージングインスタンスを登録する

手順を実施するためにLightsailコンソールを開きます。

Lightsailってページがかわいいですよね！

手順に従い、ステージングインスタンスをLinux、開発インスタンスをWindowsで作成します。

ステージングインスタンスで以下を実施します。
- CodeDeployエージェントのインストールと設定
- Nginxのインストール

ステージングインスタンスを作成している間に開発インスタンスを作成しておきます。作成をする際に、起動スクリプトの追加をします。

こちらを追加しておくことで、Google chrome, Git, Github Desktop, Visual Studio CodeのダウンロードとCodeDeoployがファイルを適切に管理するために必要なHTMLテンプレートとその他いくつかのファイルのダウンロードが自動で行われます。

両方のインスタンスが起動しました！

開発インスタンスにログインしてスクリプトの進捗を確認します。Completedになっているので問題なく実行されたようです。

次にaws configureの設定をします。

ここで苦労するのがコピー＆ペーストという...(笑) AWSエンジニアの方がコピペが普通にできないからクリップボード使ってね〜！！と言っていましたが、クリップボードでもなかなかうまくできずにひとりでワタワタしておりました...不慣れ感です...。

一通り開発インスタンスで作業をしたら、今度はCodeDeployエージェントをステージングインスタンスに設定します。

ステージングインスタンスに静的IPアドレスを付与します。
CodeDeployにステージングインスタンスを登録して、本ステップはこれで完了です。

3 - CodeCommit, CodePipeline, and CodeDeploy

1. CodeCommitの認証情報
2. 開発インスタンスにGitの設定をする
3. 初Git Commit
4. Stagingブランチの作成と使用
5. CodePipelineの設定

先ほどCodecommitのGitリポジトリを作成しました。
このリポジトリにHTTPS接続するには、CodeCommitで認証する必要があるためAWS CodeCommit の HTTPS Git 認証情報を作成します。(IAMユーザの箇所で作成します。)

git cloneコマンドを実行したところ、gitコマンドを認識してないというエラーが発生してしまいました。git pathがうまくいっていないようです...。

エラー解消しようと調べてみるもすぐに原因が分からなそうだったので、AWSエンジニアの方に見て頂きました。そしたらなんとたまーーーに発生するという不具合に遭遇していました(笑)本日2人目だそうです。なんというタイミング。

Windowsインスタンス起動時に追加したスクリプトの一部パスが問題とのことでその箇所を修正し、再度手動でスクリプトを実行したところgitコマンドが正常に使用できるようになりました！先へ進めそうで良かったです。

しかし開発インスタンスにあるwebコンテンツをgit pushしたところまたもやエラー発生。コンテンツの置き場所を間違えるという初歩的ミスをしておりました。テンプレートの修正を最初からやり直して、無事pushできました。

最後に、CodePipelineの設定をしてこのステップは完了です。

4 - Time to Develop

パイプラインを実行します。 CodeCommitまでは成功したのですが、その後は失敗してしまいました。スクリーンショットも中途半端なところでとってしまいエラーの部分が無い状態で見にくくて申し訳ないです...。

エラーを調べたり自分が実施した内容を確認したりしていたのですが、ワークショップ終了時刻となってしまいました。とりあえず最後までやりたくて、部屋から出たあとにトラブルシューティングをしたものの原因不明で、そうこうしているうちにワークショップドキュメントにアクセスできなくなってしまい最後までできませんでした。。。

まとめ

時間内に最後までできず、中途半端なところで終わってしまったのが残念ですが複数のAWS Code ServicesやAmazon Lightsail、CI/CDパイプラインを使用してのシナリオをワークショップを通して経験することができて勉強になりました。エラーのまま終わってしまったので何が原因だったのか気になります。。。ワークショップ中、結構ゆったりめに進めてしまったので時間配分も気をつけなければいけないなと思いました。

また機会があればリベンジしたいです！