むらじゅん風呂具

ITエンジニアとたまに歌手と司会などで活動する村中淳のブログ

TerraformでサクッとEC2インスタンスを作成する

ツイッター界隈で評判がとても良い実践Terraformを入手していたので、
今日はそちらを参考にサクッとEC2インスタンスを立ててみる。

ちなみに私はTerraform完全初心者。

・リソースの作成 main.tf

適当なところにディレクトリとその中に main.tf を作成
中のコードは以下

resource "aws_instance" "example" {
  ami = "ami-0c3fd0f5d33134a76"
  instance_type = "t3.micro"
}


CloudFormationのYAMLと似たような書き方かと思っていたら、
割と違うんすね。

・terraform init の実行

上のファイルを置いた場所で、terraform init を実行

$ terraform init

ファイル一覧を見ると、.terraform が出来ている。実行に必要なバイナリファイルを持ってきているとのこと

$ ls -la
total 8
drwxr-xr-x  4 muranakajun  staff  128  1 22 21:39 .
drwxr-xr-x  3 muranakajun  staff   96  1 22 21:35 ..
drwxr-xr-x  3 muranakajun  staff   96  1 22 21:39 .terraform
-rw-r--r--  1 muranakajun  staff   98  1 22 21:38 main.tf
$

動き方としてはvagrantっぽい

・terraform plan と terraform apply

terraform plan コマンドは実行計画が出力されて、
どんなリソースが作成されるか、出力してくれる。実行はされない。

terraform apply コマンドは、予め実行した結果を表示してくれて、
このまま実行してよいのか、確認をしてくれる

plan コマンドは出力が長かったので省略

apply コマンドは以下のように出力

$ terraform apply
provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Enter a value: 

リージョンを入れてくれとのことで、ap-northeast-1 を入力

確認に yes を入力してリソースが作成された

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_instance.example: Creating...
aws_instance.example: Still creating... [10s elapsed]
aws_instance.example: Creation complete after 12s [id=i-xxxxxxxxxx]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$

f:id:pj124183:20200122221827p:plain


リソース管理はCloudFormationのほうがいいかな

単純に好みの問題ではあるけれど、自分にとってはCloudFormationのほうが触りやすい印象。

どちらも良し悪しあると思うけど、大きな違いとか運用面での良し悪しが聞いてみたくなったなあ。

ともあれ、今日はこんな感じ。

【AWS】CloudFormation にてスタックの更新とRef関数を試す

CloudFormation の復習にて、スタック更新時にリソースを減らす挙動を確認してみた。

ちゃちゃっと以下のYAMLファイルを用意

AWSTemplateFormatVersion: '2010-09-09'
Description: Test cfn Template

Resources:
  cfnVpc:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0/16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'
  cfnsubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      CidrBlock: '192.168.0.0/24'
      MapPublicIpOnLaunch: true 
      Tags:
        - Key: 'Name'
          Value: 'cfn-subnet'
      VpcId: 'vpc-0b2963bc4975e0386'

スタックを作成してリソースが出来たことを確認

f:id:pj124183:20200121214836p:plain

f:id:pj124183:20200121214853p:plain


・Subnetを削除する

YAMLファイルからSubnetを削除

AWSTemplateFormatVersion: '2010-09-09'
Description: Test cfn Template

Resources:
  cfnVpc:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0/16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'

CloudFormation 画面から 更新する

f:id:pj124183:20200121215253p:plain

既存のテンプレートを置き換える から、更新したファイルをアップロード

f:id:pj124183:20200121215402p:plain

その他の設定はせず、レビュー画面にて変更内容を確認して スタックの更新

f:id:pj124183:20200121215553p:plain

先ほどのSubnetが削除されていることを確認

f:id:pj124183:20200121215817p:plain


・Ref関数を使う

再度、Subnet作成するためのYAMLファイルを用意
VPC ID を指定する際にRef関数を使う
上のcfnVpcを指していることになり、わざわざVPC IDを書かなくても済むのが便利

AWSTemplateFormatVersion: '2010-09-09'
Description: Test cfn Template

Resources:
  cfnVpc:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: '192.168.0.0/16'
      Tags:
        - Key: 'Name'
          Value: 'cfn-vpc'
  cfnSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      CidrBlock: '192.168.1.0/24'
      MapPublicIpOnLaunch: true
      Tags:
        - Key: 'Name'
          Value: 'cfn-subnet'
      VpcId: !Ref cfnVpc

再度スタックを更新、Ref関数を使用してSubnet作成できたことを確認

f:id:pj124183:20200121220559p:plain


CloudFormation には他にもいろいろと関数が用意されている模様。
組み込み関数リファレンス

パッと試せそうなのはどんどん使ってみたい。
ごっつあんです。

【AWS】EC2からRDSへの疎通確認をcurlコマンドでやってみる

今回は下記を参考にさせていただき、
EC2からRDSへの疎通確認をcurlコマンドでやってみました。

cloudpack.media

書かれている新川さん。
面識はないですが、以下の記事が素敵だなと思い、
書かれているものを探っていたところ、今回のノウハウ記事に出会いました。

cloudpack.media


DBクライアントがいらないのが便利

元記事に詳細は記載されていますが、今回DBクライアントが不要なところ、
設定内容を確認する術として、curlコマンドを使用されているのがポイントでした。
ほとんどの場合、telnetが一般的かと思うので。

さっそく自分でやってみて挙動を確認。


・EC2インスタンス、RDS(MySQL)を用意

同じVPC内にEC2インスタンス、RDS(MySQL)を用意
まずは、セキュリティグループを設定しないで疎通が取れないパターンを確認

$ curl -v telnet://database-1. xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306


結果

"test" 0L, 0C                                                                                                                       0,0-1        全て
* Rebuilt URL to: telnet://database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306/
*   Trying 10.1.15.128...
* TCP_NODELAY set
* connect to 10.1.15.128 port 3306 failed: Connection timed out
* Failed to connect to database-1. xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com port 3306: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to database-1. xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com port 3306: Connection timed out
[ec2-user@ip-10-1-11-117 ~]$

接続が失敗している挙動を確認。


続いて、セキュリティグループを設定した状態で再度実施

[ec2-user@ip-10-1-11-117 ~]$ curl -v telnet://database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306
* Rebuilt URL to: telnet://database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306/
*   Trying 10.1.15.128...
* TCP_NODELAY set
* Connected to database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com (10.1.15.128) port 3306 (#0)
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 25)
* Closing connection 0
[ec2-user@ip-10-1-11-117 ~]$

接続自体はできているものの、Warningが出ている
バイナリ出力させるのはあかんで!ってところかな


なので、オプションでoutputしてみる

[ec2-user@ip-10-1-11-117 ~]$ curl -v --output test telnet://database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306
* Rebuilt URL to: telnet://database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 10.1.15.128...
* TCP_NODELAY set
* Connected to database-1.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com (10.1.15.128) port 3306 (#0)
* RCVD IAC 193
※ここでCtrl + c を押下  
[ec2-user@ip-10-1-11-117 ~]$

きれいに接続を確認
しかし、outputに指定したtestファイルには何も記載がされていない
このへんの挙動がちょっと謎だが、接続自体を確認する目的は果たしたのでよしとする

curl コマンドについては使えば便利なことが多く、
もう少し仲良くなっていきたいところ。
焦らずひとつひとつ試していきましょ。

【AWS】作成したTwitterデペロッパーアカウントでlambdaからツイートする

昨日作ったアカウントで、Lambdaからツイートできるか試してみる。

murajun.hatenablog.jp

今回、ほとんどの部分は@ketanchoさんの下記参照させていただきました。

www.ketancho.net

なので、僕の方は作成したzipファイルをあげるところからの手順を残しておく。


・Lambda画面にて関数を作成

関数の作成から設定画面へ

f:id:pj124183:20200119104531p:plain

関数の作成 画面にて、一から作成を選び、
基本的な情報は以下の通り、実行ロールはAWSリソースにアクセスしないため、
適当なものでよし

f:id:pj124183:20200119104804p:plain


次に、関数コードから コードエントリタイプ を .zip ファイルをアップロード を選択
アップロードから事前作成したzipファイルをあげる

f:id:pj124183:20200119105136p:plain

画面右上の保存をクリック

※この時、コードビュー画面で画面がクルクルした状態で読み込まれない事象が発生
「lambda_function.pyが見つからない」というメッセージが出たので、
pythonファイル名を修正して、無事に読み込みを確認


・テストしてツイートされるか確認

テストボタンをクリックして、無事にツイートされていることを確認

f:id:pj124183:20200119105823p:plain


ただ、見よう見まねでやっているので意味がよくわかってない・・・

うん、これだと遺憾ですね。
とりあえずPythonコードから何をしているか、雰囲気なんとなくわかる感じしかしない。
試すところはできたので意味の理解をしていかないといかんとだな。

Twitter デペロッパーアカウント登録をやってみる

AWS Lambda からツイートするのを試したいと思い、
準備として、Twitter デペロッパーアカウント登録をやってみる。

Bot アカウントの作成から

ちゃちゃっとメールアドレスから登録して作成

Twitter アプリ登録へ

作成したBotツイッターアカウントにログインしたままの状態で、
下記URLをクリック

https://apps.twitter.com/app/new

そうすると、こんな画面に出るので Create an app をクリック

f:id:pj124183:20200118172947p:plain

Apply をクリック

f:id:pj124183:20200118173053p:plain

Makking a bot をクリックして、Next

f:id:pj124183:20200118173210p:plain

個人確認のため、諸々の情報が出てくる

f:id:pj124183:20200118173500p:plain

必要なところだけ入力して、Next

f:id:pj124183:20200118173612p:plain

・さらに情報を入力

さて、続いて、
君、なんでAPI使いたいん?(意訳)と聞かれるので、
グーグル先生を使って英語でいろいろと伝える。

f:id:pj124183:20200118174151p:plain

次に機能の利用に関して聞かれるので、
使用するものにだけ回答をする

ツイート機能は使うので以下に回答

f:id:pj124183:20200118174655p:plain

全体見たところ、上だけ入力すれば良さそうなので、画面下のNextをクリック

その後、確認画面が出るので、画面下のLooks good!をクリック

そして承認の画面が表示
チェックを入れて、Submit Application をクリック

f:id:pj124183:20200118175130p:plain

どうやら完了した模様

f:id:pj124183:20200118175230p:plain

登録したメールアドレスにて、メールを確認
Confirm your email をクリック

f:id:pj124183:20200118175436p:plain

お、正常に作成されたような感じだ

f:id:pj124183:20200118175522p:plain


以前、やった記憶だともう少し時間がかかった記憶があるが、
変わったのかな。

さて、Lambdaにて試すのはまた別記事で。

※もっと詳細が知りたい方は以下を参考したほうがよいかと。

qiita.com

【AWS】少しでもxfsに触れたくてEBSの拡張をしてみた

できないことで悶々とするより、平日はサクッと試せることを試したいので、
Amazon Linux 2 のルートデバイスの拡張をしてみた。

テスト用のインスタンスを立ててボリュームを拡張する

EBS-Extension-Test というテストインスタンスを立てる

対象のインスタンスを選択して、アクション > ボリュームの変更

f:id:pj124183:20200117212039p:plain


ボリュームの変更でサイズを20GiBにする

変更をすると、画面にてサイズが20GiBになっていることを確認

f:id:pj124183:20200117212632p:plain


OSにてボリュームを認識させる

インスタンスにログイン後、確認してみると変更前の容量のまま

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  400K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  1.3G  6.8G   16% /
tmpfs             99M     0   99M    0% /run/user/1000
$


現在利用できるブロックデバイスを表示する lsblk コマンドで見ると20Gがある

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk
└─xvda1 202:1    0   8G  0 part /
$


df コマンドでファイルシステムを確認、xfs だ

$ df -hT
ファイルシス   タイプ   サイズ  使用  残り 使用% マウント位置
devtmpfs       devtmpfs   475M     0  475M    0% /dev
tmpfs          tmpfs      492M     0  492M    0% /dev/shm
tmpfs          tmpfs      492M  456K  492M    1% /run
tmpfs          tmpfs      492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1     xfs        8.0G  1.3G  6.8G   16% /
tmpfs          tmpfs       99M     0   99M    0% /run/user/1000
tmpfs          tmpfs       99M     0   99M    0% /run/user/0
$


次に、調べるとパーティションサイズを拡張する際に、
cloud-initのモジュールである、growpart が必要になるとのこと

Amazon Linux 2 には標準で入っている

$ rpm -qa | grep growpart
cloud-utils-growpart-0.31-2.amzn2.noarch
$


以下、コマンドを実行

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=41938911 end=41943007
$


これが何をしているかわからずhelpをみたところ、

Example:
    - growpart /dev/sda 1
      Resize partition 1 on /dev/sda

リサイズしてくれている様子

次に、拡張したパーティションファイルシステムに認識させる、
xfs_growfs というコマンドが必要

www.systutorials.com

実行してみる

$ xfs_growfs -d /
xfs_growfs: cannot open /dev/xvda1: Permission denied
[ec2-user@ip-10-1-11-244 ~]$ sudo xfs_growfs -d /
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 5242363
$


うまくいった様子
再び確認すると / の容量が増えていることを確認

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  456K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        20G  1.3G   19G    7% /
tmpfs             99M     0   99M    0% /run/user/1000
tmpfs             99M     0   99M    0% /run/user/0
$


どうやらOSの再起動で自動認識してくれるらしい

調べてみると、わざわざここまでの処理をしなくても、
OS再起動で認識してくれるらしい↓

dev.classmethod.jp

ともあれ、昨日ハマったxfsに触れたのでよしとする。

ごっつあんです。

【AWS】Amazon Linux2 で既存インスタンスのボリュームを別インスタンスにマウントしたいがハマった

うーん、ちょっとごにょごにょしてみたができないので備忘録。

キーペアをなくした際の対応をシチュエーション

昨日見つけた、キーペアを紛失した後、SSH へのアクセスを回復するにはどのようにしたらよいですか?という、日本語字幕付きナレッジセンターの動画をチェックしたところ、 Amazon Linux がOSの場合の対応だった。

今回、試したのがAmazon Linux 2 のパターン。
※気づかずAmazon Linux 2 にしてしまったのでそのまま試す。


紛失したキーペアのインスタンスボリュームを、別のインスタンスにマウントができない

これが今回のハマりどころ。

既存インスタンスからルートデバイスのボリュームをデタッチ。
デタッチしたボリュームを別のインスタンスにマウントして復旧させようとしてるが、アタッチができてもマウントができない。

マウント時に出てきたエラーメッセージ↓

mount: /mnt/tempvol: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error.

Amazon Linux だとボリュームのファイルシステムext4でこれだとすんなりマウントができる。
Amazon Linux 2 だとファイルシステムがxfsになっており、どうやらこいつがポイントのようだ。

ちょっとググったところ、上の手順にこだわることなく、
SSMからインスタンスにログインせずコマンド実行で復旧させる手立てもありそう・・。

むーん、もう少しxfsに関して調べないとわからなそうである・・・。