【AWS】CodeStarでCI/CD自動作成してみた



本記事は Advent Calendar 2020 の2020/12/03分です。
※Advent Calendar 2020 へはHTCのチームメンバー5人で毎日日替わりで投稿させていただいていますので、暇なときに覗いてください。
※HTCの紹介は本イベント1日目の投稿をご参照ください。


初めまして。文系学部卒SIer新人のかいとです。

今回は、AWS初心者の私がWebアプリのCI/CDをAWS CodeStarを使用して自動作成しましたので、
個人的な備忘録&初心者でもこんなこと出来るのかという気付きを自分と同じような初心者に提供できればと思います!
※本記事は所属する会社の大先輩よりご教示いただいたものになります。
(今回は概念的なお話から、CodeStarの概要に触れさせていただきます。IAMの権限周りや、s3のバケットポリシー、Code3兄弟などの詳しいお話は今後投稿していきます。)

はじめに

そもそも、CI/CDとは?AWSとは?CodeStarとは?
という疑問が絶えない方々も多くいらっしゃるかと思いますので、この場で簡単にご説明します!(せっかくなので、参考記事はQiita)

CI/CD
  • 簡単に言うとCI/CDとはビルド、テスト、デプロイを自動化するシステムになります。
  • 要は、コーディングしたものを実行できるファイルなどに整形し、不具合がないかテストし、サーバーなどに乗っけてアクセスできるようにするという一連の流れを自動化することです。
AWS
  • AWSとはAmazon Web Servicesの略で、Amazonが提供している100以上のクラウドコンピューティングサービスの総称です。
AWS CodeStar
  • アプリケーションを迅速に開発および構築して AWS にデプロイするために必要なツールを備えたクラウドベースの開発サービスです。
  • 要はAWSのサービスで、CI/CDを自動作成&サーバーやその他めんどくさい設定を勝手に自動作成してくれるというモノです。

それでは、早速備忘録スタートです!

前提

  • 対象読者
    • AWSの基本概念・知識は取得しているが、Code周りを使用したことが無い方
    • 文系学部卒程度のITスキル以上を保時している方(いやそれほぼ全員)
  • AWS環境
    • rootもしくは本記事の権限付与をされているIAMユーザ

利用するAWSサービス

  • AWS CodeStarにより以下をscaffold
    • EC2インスタンス・SecurityGroup
    • CodeCommit
    • CodePipeline・CodeBuild・CodeDeploy
  • 加えて使用するサービス
    • BitBuckt(CodeCommitの代用)
    • Cloud9
  • 準備しておくもの
    • AWSサービス
      • VPC(Public/Private)
      • EC2用のキーペア
    • 追加で使用するサービスに必要なもの
      • Bitbucketの開発用リポジトリ

実践

  • CodeStarマネジメントコンソール→プロジェクトの作成
  • プロジェクトのテンプレートの選択→RoRでアプリを作りたかったので、「Ruby」でフィルタ。

    • ※アプリをどの言語でコーディングするかで決めましょう。
    • Ruby on Rails × EC2のテンプレートを選択して、Next
  • プロジェクト設定を入力

    • 任意のプロジェクト名を入力→「xxxx-rails-app」など
    • リポジトリプロバイダーは「CodeCommit」を選択
    • EC2設定
      • インスタンスタイプは「t2.micro」
      • VPCは予め作成したVPC ID
      • サブネットはパブリックサブネットのID
      • キーペアは予め作成しローカルコンピュータに秘密鍵をダウンロードしたもの

→確認してプロジェクト作成

~10分くらいかかります~

  • 環境作成確認
    • AWSマネジメントコンソール→CloudFormationの以下スタックのステータス「CREATE_COMPLETE」となること
      • 「awscodestar-プロジェクト名」のスタック
        • →CI/CDパイプライン(CodeCommit、CodePipline、CodeBuild、CodeDeploy)を構築するスタック。基本的に更新不可
      • 「awscodestar-プロジェクト名-infrastructure」のネストされたスタック
        • →CI/CDパイプラインの中で更新が適用されるスタック(EC2、SecurityGroupを構築)。CodeCommit内のYAMLに設定が記載されているので更新可能
    • AWSマネジメントコンソール→CodeStar→プロジェクト→パイプラインのステータスが「成功しました」となっていること
    • AWSマネジメントコンソール→EC2で「プロジェクト名-WebApp」というインスタンスが作成されたことを確認する
    • パブリックIPv4 DNSを確認し、「オープンアドレス」をクリック
    • 「Congratulations!」のテストRailsアプリが表示されたことを確認する。各アプリで変動。
    • 完成です。

開発環境の準備

  • AWSマネジメントコンソール→CodeStar→プロジェクトより、「AWS Cloud9の設定」
  • 環境の詳細を入力して、「環境の作成」
    • インスタンスタイプは「t2.micro」
    • VPCは予め作成したVPC ID
    • サブネットはパブリックサブネットのID
    • 環境名は任意の名前→「xxxx-rails-ide」など
    • コスト節約の設定→「30分後」
  • 環境が作成されたら、「Open IDE」で環境を開く
    • CodeStarに連携されたCodeCommitのリポジトリが自動でcloneされてIDEが起動する
  • ローカルでRailsアプリを実行してみる
bundle install
rails s
  • Cloud9のメニューバー→Preview→Preview Running Application
    • Cloud9内でブラウザを開くと画面が真っ白になるが、「Pop Out Into New Window」で別タブで開くと、Cloud9ローカルで実行されているRailsアプリが表示される

CI/CD(CodePipeline)

上記流れで作成したCodeStarプロジェクトによって、自動作成されたCodePipeLineの概要かこちら。
(出典:https://dev.classmethod.jp/articles/codepipeline-approval/)

詳しくは今後の記事にて書かせていただきますが、sourceステージのリポジトリをトリガーにCodePipelineが走り、CodeBuildにてビルド、CodeDeployにてデプロイを行なえる環境が自動作成されます。

追加で実践した内容
  • CodePipelineのSourceステージをCodeCommit→Bitbucketに変更。
    • CodeCommitはここには向かない。。Git管理するなら尚更。
  • EC2にfromIP制限を付与。
    • 直接SGを変更してもいいが、自動作成されたtemplate.ymlにて設定をしてもよい。CI/CDを回すと反映される。
    • 下記参考↓

HTTPアクセス制限の例

template.yml
    #省略
       - IpProtocol: tcp
         FromPort: '80'
         ToPort: '80'
         CidrIp: 0.0.0.0/0
    #省略

↓ IP:123.456.789.0/32 に限定

template.yml
    #省略
       - IpProtocol: tcp
         FromPort: '80'
         ToPort: '80'
         CidrIp: 123.456.789.0/32
    #省略

詰まった部分

CodeDeployでデプロイするにあたり、該当EC2にはcodedeploy-agentをインストールする必要があります。
しかし、なぜかCodeStarで自動作成したプロジェクト内のEC2にはインストールされておらず、初期のCI/CDが失敗する事象が発生しました。
インストールをすれば解決ましたが、設定もしてあるし、自動的にインストールされるはずなのですが。。ここは謎でした。。
- 対応方法:https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/codedeploy-agent-operations-install-linux.html

まとめ

・CodeStarはサクッと一般的なアプリケーション実行環境+CI/CDパイプラインをお手軽に構築でき、
驚き&楽しさ&嬉しさがありました。この手軽さで構築できるのは非常に魅力的です!!
ただ、ELB・RDSの構築やCI/CDの細かいカスタマイズはできないので、一つの完成形(AWS環境としてのMVP)を実物として素早く展開して、その接続構成や設定を理解することで後続の自分たちのサービス開発に活かすために使用するのがベストかなと思いました。

・共同開発にCloud9便利(実行環境はチームで共有可能)ですが、開発環境(IDE)はIAMユーザーごとにアクセス権が分離されるので開発に参加する全員が準備を行う必要があるので、大規模の開発には向かなさそう。。

・総じて初心者でも、AWSはGUIポチポチ(CLIももちろんあるが)なので、振れやすいサービスかと思います!ぜひ皆さん私と一緒に学びましょう!!