本番環境の設定ファイルはバージョン管理されなければならない。
確かにそうなんですが、だからといってGit Treeをまるっとcloneしてきてというのも無駄が多いですし不要なデータを持つことでリスクが高まりますし、「そうは言っても…」というのが現実かと思います。
そんな現場に解決策を。Kubernetesだけではないのですよ、現実は…。
AWS SSMの多彩な機能を活用する
コンテナ化されていない、いわゆるVMを管理するにあたって強力なツールがAWS Systems Manageです。機能がたくさんあってよくわからないですが、AWS Systems Manager Run Commandが重要です。これ、非常に乱暴な言い方をすると、Systems Managerから対象のVMにコマンドを送りこんで実行する機能です。いちいちVMにログインせずとも、AWSのコンソールから操作できますし、操作対象のVMは複数選べますし、理解を深めておきたい機能の1つです。
SSMからAnsibleを実行する
SSMのRun Commandでコマンドを実行できるということは、当然、Ansibleも実行できます。というか、Ansible実行用のドキュメント(Run Commandのパラメータセット？)が提供されています。どんな中身かというと…。AWSにログインしていないと見れないようですが。
AnsibleのPlaybookをGitHubかS3からダウンロードしてきて、localhost(自ホスト)に対してapplyするという動きです。apply対象の選択はSSMの機能で行えばよいという判断なのでしょう。「これからAnsibleのPlaybookを書く」というのであれば、SSMの方針に素直に乗っかるのがよいのではないでしょうか。
Playbookだけでなく、Zipを用意するscriptも管理する
設定ファイルはもちろん、その設定ファイルをdeployするPlaybookもGitの管理下に置くのは当然です。それに加えて、Zipファイルを作るscriptもちゃんと管理しましょう。「S3のどこにアップロードする」まで決めて、そこまでscript化してしまうのもよさそうです。
GitHubを利用していれば、Zipファイルを作るscriptなんて不要なのですが…。AWS CodeCommitとか、BacklogのGit機能とか、GitBucketとか、いくつもサービスはあるので。
自動deployも視野に
SSMのRun Commandの画面でいろいろ設定する部分、これ、画面の一番下に、「AWS CLIだと…」ってコマンドが表示されます。ですので、Run Commandを実行する部分もscript化できます。
全部script化してGitの管理下に置けるので、自動deployの仕組みにも乗っかりそうですね。
Git Treeに取り込む際にレビューされたものをレビューされた手順でdeployする。
設定ファイルだけでなくdeploy手順まで管理できるので、SSM + Ansibleは強力なソリューションになりますね。
