2020年7月7日火曜日

AWS CDKで立てたEC2インスタンスのTimeZoneとかいじりたかった話

EC2を立てることはできたけど、立てたインスタンスは UTCのままだし設定ファイルとかいちいちscpしてくるのはダルい。

当初UserDataでなんとかしようとしたものの、「書く量がヤバいしメンテしにくい」と悩んでいたところ見かけたのが AWS::CloudFormation::Init 
調べたら YAMLやJSONでの書き方ばかりだったけど、CDKも結局最後は CloudFormationになるはず!とツッコんでみた。

■ どんなことができるのか


使った機能だけだけど

package    : yum install できるものはここで宣言しておくのが楽っぽい。
files          : その名の通りファイルの配置。インスタンス作った直後にscpで送るのか…とか頭抱えてた課題の救世主。
command : その名の通りコマンド実行。ただし実行ユーザーはrootユーザーの模様。

サーバ作った後、最初にやりたいセットアップまでコード化できるのは色々嬉しい。(最悪 README.mdにインスタンス立てた後のコマンドつらつら書くことを覚悟してた。)

■ どんな風に書くのか

 instance.addOverride('Metadata', {
  'AWS::CloudFormation::Init': {
    'config': {
      'packages': {
        'yum': {
          'git': []
        }
      },
      'files': {
        '/home/ec2-user/.ssh/config': {
          'content': fs.readFileSync(path.resolve(__dirname, "../files/config")).toString(),
          'mode': '600',
          'owner': 'ec2-user',
          'group': 'ec2-user'
        },
      },
      'commands': {
        '01_set_timezone': {
          'command': 'timedatectl set-timezone Asia/Tokyo',
          'ignoreErrors': false
        }
      },
    }
  }
});

let userData = ec2.UserData.forLinux({ shebang: "#!/bin/bash" });
userData.addCommands(
  `/opt/aws/bin/cfn-init --region ${this.region} --stack ${this.stackName} --resource ${instance.logicalId}`
);
instance.userData = cdk.Fn.base64(userData.render());

前回 のものに追加した。
config の子要素としてそれぞれやりたいことを書いていく感じ。

filesは当然権限やファイルのowner:group なんかを設定できる。
コード化しているので配置したいファイルそのままを fs.readFileSync().toString() してしまえば、ファイルの中身をベタ書きせずに済むのも嬉しい。(【追記】 ただしこの場合、readFileSyncするfileの中身が空だと実行時にエラーになる…(´・ω・`))

commandsには「このコマンド実行の失敗を無視するか」を設定できる。
手作業でリカバーできる内容なら無視してしまってもよい?
また commandsは(今回は一つしか無いけど) key名(例だと 01_set_timezone)のソート昇順で実行するらしい。
ので今回の様にprefix的に番号でも付けておくと実行順の管理もしやすそう。

なおcommands自体の実行前に packages、filesの処理は終わってる模様。
なので「filesでshellファイルを配置し、commandsでそれを実行する」なんてこともできる。(この後さらにコマンドを追加しようと思ったら実行ユーザーの関係でどうしてもうまく行かなかったので、妥協して上記の形にしたのは内緒)

ただ最終的には UserDataから cfn-init を実行する。 オプションは無いと動いてくれないので忘れずに。

■ ついでに

これ作ってて一番アホだったミスが「コードは書き換えたが生成物に反映されていなかった」問題。「あれれ〜?変更されないぞ〜?」とかアホ面下げて調査してたらよく見たらFormationの更新がされていないというオチ。
なので必ず clean build( tcs --build --clean ) をdeploy前に実施するようにした。

…ホントこれのせいで一日潰したことに気づいた時の脱力感よ…(´・ω・`)

■ 不満点


ここまで「スゴイベンリ!」「ヤッター!」と来たものの、ここに至るまでに何度インスタンスを立てたか…
もっとこう、テストがしたいです…

ちなみに /var/log/cfn-init.log に実行ログが出るので、「なんかコマンド効いてなくない?」と思ったらここを確認すると幸せになれるかも




2020年7月1日水曜日

AWS CDKでサクッとEC2インスタンスを立てたかった話

前回 ひとまずcdk の initまで完了してプロジェクトの用意ができたので、次は実際に構成したい内容を書いていく。

■ 最初の要件


今回立てたいEC2インスタンスの要件はこんな感じ。
  • NodeJSのツール(インターネットアクセス有り)を実行できる。
  • TimeZoneは JST
  • sshで入る(=22ポートを開けたい)
ひとまずこんなところ。他は随時拡張したくなったら。

■ 作るもの


今回明示的に用意するものは以下
  • VPC(CIDERは適当に既存のものに被らないものを)
  • Security-Group(22ポートだけひとまずフルオープンしておく)
  • EC2インスタンス(t2.small)
一旦まずはTimeZoneなどは置いておいてインスタンスにsshできればいいや、程度から作る。

■ コード

さっくり
    const prefix = 'Sample';

    // VPC 
    const vpc = new ec2.Vpc(this, `${prefix}Vpc`, {
      cidr: 'x.x.x.x/y', // 空いているところを適当に使用
      natGateways: 0, 
      subnetConfiguration: [
        { name: `${prefix}PublicSubnet`, cidrMask: 20, subnetType: ec2.SubnetType.PUBLIC }
      ]
    });
    
    // SecurityGroup
    const instanceSecurityGroup = new ec2.SecurityGroup(
      this,
      `${prefix}SecurityGroup`,
      {
        securityGroupName: `${prefix}SecurityGroup`,
        vpc: vpc
      }
    );
    
    instanceSecurityGroup.node.applyAspect(
      new cdk.Tag("Name", prefix)
    );
    
    instanceSecurityGroup.addIngressRule(
      ec2.Peer.anyIpv4(),
      ec2.Port.tcp(22)
    );
    
    // EC2
    const instance = new ec2.CfnInstance(this, `${prefix}Instance`, {
      imageId: new ec2.AmazonLinuxImage(
        {generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2}
      ).getImage(this).imageId,
      instanceType: new ec2.InstanceType("t2.small").toString(),
      keyName: "sample-key", // 鍵は別途作ってあるものを使う
      networkInterfaces: [{
        associatePublicIpAddress: true,
        deviceIndex: "0",
        groupSet: [instanceSecurityGroup.securityGroupId],
        subnetId: vpc.publicSubnets[0].subnetId
      }],
      tags: [
        {"key": "Name", "value": `${prefix}-A01`},
      ]
    });
  
主に悩んだのは「Tagの宣言の仕方色々あるんやなぁ(´・ω・`)」というくらい。
あとはどちらかと言うと AWSの知識(どんな設定項目が必要なのか)の方が大事でコード的には難しいことはなにもない。
このあたりは実際にAWSコンソールから対象をまず手作業で作ってみて、「どんな設定、入力項目があるのか」を見てきた方が早いし納得しやすいかと。

■ この後やりたいこと


このままだとサーバのTimeZoneが UTC のままなのでJSTにしたい。
ついでに設定ファイルとかわざわざ scpしたりするのめんどい。

ので AWS::CloudFormation::Init を設定して楽したい。

というのは長くなったので次で。

2020年6月24日水曜日

AWS CDKを使いたくなった話

めちゃめちゃ久々に書いてみようとしたらなんか色々死んでた orz

お仕事が平気で徹夜カマしたり同じことばっかやって書くネタなくなったり気力続かなかったりグラブったりといろいろ理由付けてサボってたらいつの間にかインフラ構築とかもやるようになったので備忘録φ(._. )メモメモ

■ まず AWS CDKってなんやねん


AWS CDK とは 「AWS Cloud Development Kit」の略で、
ざっくり言えば 【CloudFormationビルドツール】的なもの。
これまで(と言ってもCDKが出たのは結構前だが)は一生懸命 YAMLやJsonでつらつら長々と書いていたCloudFormationを
さっくりコードから生成してしまおう、というもの。
使える言語もこの記事を書いている時点では 
「The AWS CDK supports TypeScript, JavaScript, Python, Java, and C#/.Net.」
と人気どころは押さえてあるんじゃないですかね知らんけど。

自分はずっとJavaScript(NodeJS)ばっか触ってたのでJavaScript…ではなくTypeScriptメインでいじってます。タイプセーフって安心する。
ので NodeJS-TypeScript環境でつらつら書いていく。


■ セットアップ


あらかじめNodeをインストールしておき、かつ
npm i -g aws-cdk
して cdk コマンドを使えるようにしておく。
あとは
mkdir sample 
cd sample
cdk init --language typescript
とプロジェクト用のディレクトリを切ってinit コマンドを実行すれば 必要な一式を自動生成してくれる。
なお「cdkをグローバルインストールしたくない」と予め
npm init -y 
npm i -S aws-cdk
npx cdk init --language typescript
とやろうとすると、
`cdk init` cannot be run in a non-empty directory!
と怒られるので諦めた(一敗)。

あとは個人的なカスタムとして、 package.jsonの scriptsに
    "deploy": "npm run build & npx cdk deploy"
を追加。一応READMEにコマンドが色々載ってるが、
  • buildとdeployでコマンドが違う
  • build忘れてdeployする(というかして一日ほど無駄にした)
  • cdkのバージョンはglobalではなくプロダクトのものに合わせておきたい
等の理由からdeployスクリプトを用意しておきたかった。

|・ω・).。o0( なんか長くなってきたから一旦ここで切る )

AWS CDKで立てたEC2インスタンスのTimeZoneとかいじりたかった話

EC2を立てることはできたけど、立てたインスタンスは UTCのままだし設定ファイルとかいちいちscpしてくるのはダルい。 当初UserDataでなんとかしようとしたものの、「書く量がヤバいしメンテしにくい」と悩んでいたところ見かけたのが  AWS::CloudFormation:...