継続的インテグレーション環境の構築(1)

本連載では、AWSリソース基盤構築の自動化を実践しています。今回からは数回に渡り、第2回から複数回に渡って解説してきたCI（Continuous integration：継続的インテグレーション）環境をCloudFormationを使って自動構築していきます。

ただし、自動構築においては、手動で構築する際とはいくつか違う点があります。以下に示すのは、自動構築するCI環境のイメージです。

第2回で解説した静的解析を行うSonarQubeServerの構築では、データベースを構築した後、ユーザー作成などの初期化処理をわざわざRDSに接続して手動で行っていました。自動構築では、これをCloudFormationのCustom Resource(AWS Lambda-backedカスタムリソース)を使って、AWS Lambdaから実行します。また、RDSのパスワードなどはCloudFormationのテンプレートコードにハードコーティングするのは望ましくないので、SystemsManager Parameter Store経由で取得するようにします。

なお、以降で取り上げるソースコードのフルバージョンはGitHub上にコミットしています。記事内では本質的でない記述を一部省略しているので、実行コードを作成する場合は、必要に応じて適宜GitHub上のソースコードも参照してください。

SonarQubeServerのベース環境構築テンプレート

まず、SonarQubeServerが実行されるベースとなるVPCやセキュリティグループ、ALB、ECSクラスタといったリソースを構築します。作成したCloudFormationテンプレートはGitHubにコミットしてあります。内容は、本連載の第36回で解説したものとほぼ同等です。必要に応じて参照してください。

差分がある箇所として、ECSクラスタの接続がSystems Manager Session Managerを使ってできるように、割り当てるロールにAmazonSSMManagedInstanceCoreポリシーを付与しているほか、ECSのクラスタの起動スクリプトでSSMエージェントをインストールしています。

AWSTemplateFormatVersion: '2010-09-09'

# omit

Resources:
  ECSRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRole
            Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

# omit

PublicECSLaunchConfiguration:
  Type: AWS::AutoScaling::LaunchConfiguration
  Properties:
    ImageId: !Ref ECSAMI
    InstanceType: !FindInMap [PublicClusterDefinitionMap, Instance, InstanceType]
    IamInstanceProfile: !Ref IamInstanceProfile
    SecurityGroups:
      - Fn::ImportValue: !Sub ${VPCName}-SecurityGroupPublicEcsCluster
    AssociatePublicIpAddress: true
    UserData:
      Fn::Base64: !Sub |
        #!/bin/bash -xe
        echo ECS_CLUSTER=${PublicECSCluster} >> /etc/ecs/ecs.config
        yum install -y aws-cfn-bootstrap jq
        # Get the current region from the instance metadata
        region=$(curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | jq -r .region)
        # Install the SSM agent RPM
        yum install -y https://amazon-ssm-${AWS::Region}.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm
        /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource PublicECSAutoScalingGroup --region ${AWS::Region}

 # omit

Systems Manager Session ManagerはEC2インスタンスやオンプレミスにあるサーバと安全に接続するためのSystems Managerの機能です。通常、EC2やサーバにはSSHなどを使用して接続するのが一般的ですが、Session Managerは以下の図のように、接続対象となるサーバにエージェントとなるソフトウエア(SSM Agent)をインストールし、Session Managerへ常にコンソールプロセス情報のポーリングを行うことで、インバウンド接続設定を行わずとも、対象のサーバにアクセスすることができようになります。セキュリティグループのデフォルトの設定通りアウトバウンド接続が常に可能な状態になっていれば、プライベートサブネットに配置されたEC2インスタンスでも踏み台なしに、Session Manager経由で直接接続することが可能です。

なお、オンプレミスのサーバでもSSM Agentをインストールすれば、Session Managerからアクセスが可能です。Session Managerには、さらにアクセスログをCloudWatchやS3へ保存する機能やSNSなどの通知サービスと連携させて禁止された操作を検出／通知することもできます。

AWSでは、アクセスキーやシークレットキーの漏洩リスクがある通常のSSH接続ではなく、Session Managerによるアクセスを推奨しています。Session ManagerはAWSマネジメントコンソール上経由でブラウザを使ってシェルコンソールを開くか、AWS CLI(コマンドライン)のプラグインを使って、通常のSSHアクセスと同じようにローカルのターミナルコンソール上から実行することが可能です。

SonarQubeServer向けRDS環境構築と事前準備

続いて、SonarQubeServer向けRDS環境構築や、（次回解説する）Lambdaファンクション実装の事前準備として以下を行っておく必要があります。

• CloudFormationを使ってLambdaをデプロイするために、事前にS3バケットを作成するテンプレートを実装／実行
• Lambdaファンクション内でCloudFormationカスタムリソースにおけるResponseURLへリクエスト送信するためにNAT Gatewayを作成するテンプレートを実装／実行
• Systems Manager Parameter StoreにRDSマスターユーザーおよびSonarユーザーのパスワードを作成(AWSコンソールから手動で実施)
• SonarQuberServer用のRDS(PostgreSQL)テンプレートを実装／実行し、エンドポイント、データベース名、マスターユーザ名をスタックでエクスポート出力

実際に作成したCloudFormationテンプレートはGitHubにコミットしてあります。S3バケットを作成するテンプレートの解説は本連載の第29回を適宜参照してください。

今回はSonarQubeServerのベースとなる環境のCloudFormationテンプレートの実装とRDS環境を構築しました。次回は、CloudFormationカスタムリソース(AWS Lambda-backed カスタムリソース)を使ってRDSの初期化処理を行うLambdaファンクションを作成します。