本連載では、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ファンクションを作成します。
著者紹介
川畑 光平(KAWABATA Kohei) - NTTデータ
金融機関システム業務アプリケーション開発・システム基盤担当、ソフトウェア開発自動化関連の研究開発を経て、デジタル技術関連の研究開発・推進に従事。
Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。AWS Top Engineers & Ambassadors選出。
本連載の内容に対するご意見・ご質問は Facebook まで。