July Tech Festa 2021 winter で Infrastructure as Codeについて話をしてきました
AWS Organizationsシリーズは今回一旦休憩です。
1/24(日)に行われた、インフラエンジニア向けのカンファレンスJuly Tech Festa 2021 winterでお話しました。せっかくなのでブログにも内容をまとめます。
発表資料
なぜこのテーマでしゃべろうと思ったのか
Infrastructure as Code(以下IaC)は、構築や環境の複製を楽にするもの。
だけではない!
インフラ環境の品質UPにもつながるはずだ!と私は信じております。
私はオンプレミスのインフラ構築も多く行ってきており、手動のインフラ構築・運用も行ってきました。IaCでは多くの手動管理の課題が解決できるなと感じているのですが、まだまだIaCが浸透せずに手動管理となっている現場を多く見かけます。
この発表をきっかけにIaC始めてみよう、難しくないんだ!と思ってもらえると良いなと思い発表に至りました。(CFP通って良かった)
発表内容
資料を貼りながら補足部分を書いていきます。
対象は先ほど書いたとおりIaC初心者としております。ここでいう初心者とはインフラ・クラウド構築の初心者ではなく、AWSなどクラウド環境の構築経験はありつつも、手動管理を行っているIaC初心者ということになります。
IaCを使わない手動インフラ管理
まずはIaCを使わない場合(=手動でインフラ構築、管理)どういった流れになるのかをお話しました。
最初はまずインフラってなんだっけというところです。
そしてインフラ構築の流れ。V字モデルですね。
手動管理では通常、パラメータ設計で設定するパラメータを決定しそれに従い構築、構築ができたら設計したパラメータ通りになっているかテストする。という流れで構築を行っていきます。
具体的なパラメータ内容は構築してみないとわからない部分もあり、設計と構築を行ったり来たりすることも多いですね。
手動管理の課題
1つ目の課題です。
この課題が1番わかりやすいかなと思います。すべて手作業になるため、環境数分の作業時間(手間)がかかります。
また、環境をコピーしている訳ではないため、すべての環境で想定通りのパラメータになっているかテストする必要があります。
実際の開発現場では、アプリ開発チームに、「開発環境もう一つ必要だから作って」と言われることもあります。予定してないから無理と断るか、同じ手間をかけて作るかの2択です。
2つ目の課題。
これも手動構築の現場ではよく見てきました。開発でうまくいっていた設定が、本番では入っていない!?というやつです。
こういった事象を無くすために、各環境できちんとテストをしていくのですが、テストするのも人間であるため、100%ミスを無くすのは難しいです。
3つめの課題。
設計どおり構築をしてもうまくいかない、本番運用中に障害があった場合、その場で急遽設定変更をします。その場でうまく動いたことがとても嬉しいので、たいていの場合設計書への反映が忘れられます。
「たいていの場合」は言い過ぎかもしれませんが、私もこういった経験はあり、「この設計書本当にあってるの?実環境見てくるわ」ということもありました。今でもオンプレ環境だとあったりしますね。
4つめの課題。
「設定の履歴が残らない」です。
これが無いとどういった場合に困るのか、というところですが、たとえば、ファイアウォール(SGでもOK)で見知らぬIPアドレスからアクセス許可の設定が入っていたとします。 IPアドレスの値が入っているのみで、どこのIPアドレスなのかわかりません。
そうなると、誰が、いつ設定したんだ?となりますが、改定履歴がないとそれを聞く相手もわかりません。
そして、その設定は消していいのか、変更していいのかわからないため、怖くていじれなくなります・・
ということでいつ、誰が、何のために設定したのか履歴情報を残すことはとても重要です。
が、資料管理をきちんとやるのはとても難しです。人により履歴の書き方も変わってきます。
ということで課題4つ紹介しました。
IaCが解決する課題
いくつかIaCのツールはありますが、今回はAWSのCloudFormaitonを前提としてお話しました。
1つ目の課題解決。
1番わかりやすいIaCのメリットかと思います。テンプレートベースになるので環境の複製が容易にできますね。
2つ目の課題解決。
1つ目と似ていますが、ここは品質観点です。同じテンプレートベースになるため、環境間で差があるといったミスが発生しにくくなります。
ポイントとして書いているリソースを同一にというのは、たとえばサブネットの数が本番と開発で異なると、テンプレートも環境ごとに書き換えたり工夫をする必要があります。サブネット数など料金に影響を与えない部分は基本的に全環境同じにしたほうがテンプレートとして書きやすいのでおススメです。
また、人のミスを減らすという目的においては、CloudFormaitonのデプロイ作業もパイプラインからコマンド経由で行ったほうが良いです。
3つ目の課題解決。
これは、リポジトリで管理しているテンプレートから正しくリリースしている前提になりますが、実環境を見に行かなくても、テンプレートを見れば設定内容がわかるという点です。
特に運用する方にとって嬉しいポイントかと思います。
4つ目の課題解決。
IaCをGitリポジトリ管理にすることで、強制的に履歴を残せます。
コミットメッセージについては組織でルールを決めて正しく運用でカバーする必要がありますが、少なくとも「誰が、いつ」という情報は残るようになります。その人に聞きにいくことができますね。
課題の解決まとめです。
元々あった課題が完全に無くなるわけではないですが、かなり減らせる部分はあると思います。
CloudFormationの使い方
実際の書き方に入っていきます。
まずパラメータシート。手動管理の場合Excelを使用して以下のような資料を作りますね。VPCを例としています。
これをCloudFormaiton(YAML)で書くとこうなります。(右側)
太字で書いている部分が一番のポイントです。パラメータシートの場合も、CloudFormaitonの場合も書いている内容はほぼ同じです。
おそらくここで難しいと感じる場合は、CloudFormaitonが難しいのではなく、AWSの設定がわからなくて難しいと感じているのだと思います。
CloudFormaitonはYAMLの場合コメントも残せるため、設計で大事となる根拠や補足なども書き込むことができます。
CloudFormtaionのポイント
書き方を覚えたら活用のポイントです。
まずParameters。ほぼ必須で使用する機能です。
環境ごとに変わる値(名前で使用する環境名Env、VPCのCidr)をParametersとして別出ししています。
コードも貼っておきます。
Parameters: Env: Description: "Environment" Type: String Default: "dev" VpcCidr: Description: "VPC CIDR" Type: String Default: "10.0.0.0/16" Resources: vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: !Ref VpcCidr InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${Env}-sys-vpc"
次にテンプレートの分割です。実際の運用では1システムすべてを1テンプレートで書くことはあまりなく、いくつかのテンプレートに分割します。
たとえばネットワークのまとまりであるVPCやサブネットを1テンプレートにしたりします。
一方で、VPCの情報は他のリソースでもIDをインプット情報として与える必要があるため、テンプレート間で参照できる必要があります。
そこで紹介したのがOutPutとImportValueの機能です。
コードは以下のとおりです。
- VPC(参照される側)
Outputs: vpc: Value: !Ref vpc Export: Name: vpc
- Security Group(参照側)
Resources: SecuritygroupEC2: Type: "AWS::EC2::SecurityGroup" Properties: GroupName: !Sub "${Env}-ec2-sg" GroupDescription: "for EC2" VpcId: !ImportValue vpc
その他には、SSM Parameter StoreやSecrets Managerを使用するやり方もあります。
次からは運用面。
テンプレートのデプロイやテストも人の手から離れて自動化したいため、以下のようなパイプラインを作ります。
パイプラインの要素ごとに見ていきます。まずはChange Sets。
aws cloudformation deploy
コマンドを実行すると、すぐさま変更が反映されるのですが、CloudFormaitonでは重要なリソースを管理している場合も多く、変更対象を間違えると意図しない変更や削除が発生する可能性もあります。
そのために本番環境へ反映される前に、事前に反映予定の内容を確認できる機能がChange Setsです。本番環境のパイプラインでは入れることをおススメします。
つづいてCloudFormaitonのテストツール。
cfn-nagやcfn-python-lintはコード解析のツールであるため、テンプレート開発中もローカルで実行することができます。各テストツールのリンクを貼っておきます。
TaskCatは、実環境にデプロイできるかという観点でテストができます。CloudFormaitonはテンプレート内容としてOKでも、実際の環境によってNGになることもあるため、デプロイを事前確認することで品質UPにつながります。
パラメータチェックのツールです。
たとえばCLIでVPCの情報を見たい場合はaws ec2 describe-vpcs
というコマンドで確認できます。
awspecはテスト用のツールです。
以下のように書いてVPCのあるべき状態を書いてテストが可能です。
require 'spec_helper' describe vpc('my-vpc') do it { should exist } it { should be_available } its(:cidr_block) { should eq '10.0.0.0/16' } it { should have_tag('Name').value('my-vpc') } end
テスト手法について書きましたが、2つ目に書いたパラメータチェックは必要なのかというところについての考察です。
どちらが正解という結論はここでは出していませんが、私としては、IaCではテンプレートの内容がとても重要になるため、できればまず複数名でレビューを行って、テンプレートの品質UPを目指すのが良いと思っています。
テストツールを使ってパラメータチェックをするのも良いと思いますが、全パラメータをやみくもにチェックするのではなく、ポイントを絞って方針を決めることをおススメします。
たとえばセキュリティに関わるところとか、環境ごとに差が出そうなところです。
テストケース数や実施状況を報告しなきゃいけないという状況となり、関係者の品質共通認識としてテストツールを使うことが良い場合もあるかと思います。
まとめ
少しでもIaCで解決できそうな課題がありましたら是非ご使用を!
手動管理をやってきたインフラな方は、CloudFormaitonが取っ付きやすいと思います。
いただいた質問
「Go Formationのように、プログラム言語でCloudFormationを書く機能もあるがそれについてどう思うか。」
という質問をいただきました。ありがとうございます。
CloudFormation、全設定を見るという面では非常に優れていると思うのですが、これがツライ部分もあります。 たとえばマネジメントコンソールでは自動設定くれる場所も書かないといけないので、記述量が多くなりがちです。
また、ループのような処理もCloudFormation単体では難しいです。
そういった記述の柔軟さで言うと、Terraformのほうが優れているかなと思います。
AWS CDKも使ってみたいです。
ただ、組織全体で考えると、まだIaCに慣れていないメンバーがいる場合は、CloudFormationが入りやすいと思い選ぶことが多いです。
自分1人であれば、次はCDKで頑張ってみたいなという気持ちもあります。
登壇してみて
私にとってはとても大きなイベントでの登壇でした。
他の方の発表はとても専門性が高くて素晴らしく、私のはあまり見られないなと予測しておりましたが、それなりに見ていただけて良かったです。
運営されていた方、発表された方、視聴してくれた方、機会をいただき本当にありがとうございましたm(__)m
アーカイブされたらほかの方の発表もじっくり見たいと思います。