むらじゅん風呂具

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

【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に関して調べないとわからなそうである・・・。

【AWS】日本語字幕付きナレッジセンターをチェックしてみた

AWSを利用していて、おそらく初めて見たコンテンツ。

aws.amazon.com

文章そのまま引用しちゃいますが、
YouTube 動画を使用してお客様からのよくある質問に回答しています。
とのこと。


さすがにサービスの数が多いので動画の数も比例しているが、
EC2周りのトラブルは直面しそうだなあと思い、試してみたいものをチェック。

気になったのが、
キーペアを紛失した後、SSH へのアクセスを回復するにはどのようにしたらよいですか?
という質問。

たしかにどうすんだろう??
と思い、リンクされている動画をチェックして、きちんと手順紹介されておりました。

今日は時間がなさなので、別日に自分でテストして確認してみよう。

【AWS】Hands-on for Beginners 〜Serverless 編〜でサーバ レスアーキテクチャについて学べた!

AWSさんが公式に出されているハンズオン資料の中にあります、
Hands-on for Beginners 〜Serverless 編〜をやりました。

aws.amazon.com

何度か繰り返し動画視聴と手順を覚えて実施できるようになった上で、
感じた触感を書いていきます。


結論:初めて学ぶサーレスアーキテクチャとしてめっちゃ良い

いきなり結論を言いますが、めっちゃ良いコンテンツでした。

自分のようなインフラがっつりだけど、プログラミング雑魚なエンジニアでも、
手順を踏んでしっかり学べるところ、実際の成果物として動くサービスを作れたことは「大きなスタート」となり、「学べる楽しさ」を深く感じさせてくれました。

サーバーレスすごい。


翻訳 Web API を作成して使用するAWSサービス

今回、作成するのは翻訳 Web API
Lambda、API Gateway、DynamoDBの3つを使用してます。

サーバーレスに馴染みがない方に合わせて、
アーキテクチャの概要、上の3つのサービスに関しても、
ハンズオンに入る前に解説していただいているので初めて聞いた方でも、
敷居の低さを感じさせてくれます。

僕も正直、上3つのサービスをがっつり使って構築したことがなく、
なんとなくサービスを知ったような気になってたレベルです。

また、LambdaではPythonを使用してますが、
書けなくてもソースコードを公開していただいてますのでコピペでも大丈夫になってます。


ひとつひとつのサービスに触れて、連携させていく

AWSはググればいろんなアーキテクチャ構成、サービス事例が出てきますが、
「具体的に何がどうつながってこうなっている??」という、
触感を掴むのが正直むずかしいなと思うところがありました。

インフラならまだしもサーバーレスになると何が何やら・・・。

今回のハンズオンでは、まずLambdaを単体で利用して、
他のAWSサービスを呼び出す手順を見せてくれます。

個人的にはAPIリファレンスドキュメントの見方も含めて解説していただいているのがポイント高いです。
もっとPythonにも触れたいなあと思いました。
PyQやる時間を削ってAWS触っているのが惜しい・・・


サーバーレスもっと触れていきたい

ブログへのアウトプットを継続実施するようになってから、
よりAWSを触るのが楽しくなってきたことを実感してます。

ハンズオンとして、別に紹介していただいている、
スケーラブルウェブサイト構築編 も、とにかく手順をきれいに覚えて、動画を見ずに実行できるようにする。

そこから、ネットに転がるナレッジを試す、小さいことからひとつずつ試していく。

何か問題が出てきた時に、自分の頭の中で解決できたり、 「これを形にするにはどうしたらよいか?」と考えるのがやたら面白くなってきました。

いま、自分が触れている部分としてはインフラ側に寄ったものが多いですが、 今回のサーバーレスコンテンツをきっかけに領域を伸ばしていきたく思います!

続編も作成される予定とのことで大きく期待するとともに、
出るころくらいにはもう少しできることの幅が広がっているように邁進していきたいと思います。

興味が出た方、ぜひやってみましょう!!

aws.amazon.com

【AWS】Chatbot(beta版)を使ったSlack通知設定をしてみた

やってみたいと思っていたSlackへの通知設定。
Lambdaを利用した例が一般的でそれで試そうかと思っていたが、
今はchatbotを使ってサクサクっとできてしまう。

www.seeds-std.co.jp

さっそく自分でも手順を確認してみる。

以前作ったCloudWatchのアラートを利用する

先日設定したCloudWatchのアラートがあるので、
こちらを利用して、Slackへの通知設定も追加する。

murajun.hatenablog.jp


・Chatbotの設定

マネージメントコンソールから Chatbot を選択
Chat client にSlack を選択して、Configure client を選択

f:id:pj124183:20200113161536p:plain


Slack画面が表示されて、リクエストの確認画面が出るので 許可する


f:id:pj124183:20200113161952p:plain


Configure Slack channel 画面にて引き続き設定

Channel type:Public
Public channel : general を指定

f:id:pj124183:20200113162248p:plain


Permissions にて、IAMロールは自動生成
名前をChabot_Testに指定
ポリシーテンプレートは、デフォルトで入っているもののまま

f:id:pj124183:20200113162614p:plain


Notifications にて、東京リージョンを選択して、
Topics に作成したmail-alert-test01 を選択して、Configure をクリック

f:id:pj124183:20200113162821p:plain


画面が戻り作成を確認

f:id:pj124183:20200113163036p:plain


・Slackにアラートが流れるかテストする

以前と同様にEC2インスタンスのCPU使用率を80%以上に上げて、
Slackに流れるかテストしてみる

以下コマンドをEC2で実行

$ yes >> /dev/null &

しばらく待つ・・・。すると、指定したチャンネルにてアラートを確認

f:id:pj124183:20200113165457p:plain

グレイトですよ!こいつぁ!!


とりあえずchatbotを使えば簡単にできるとわかった上で、 Lambdaで設定するパターンも把握したい。

ごっつあんです。

【AWS】AWS SDK for Python(Boto3) でリソース作成をやってみた

AWS ハンズオン資料にある、
AWS Hands-on for Beginners 〜Serverless 編〜の復習を実施。

aws.amazon.com

この中で説明していただいているアーキテクチャは作れるようになったものの、 プログラミングをがっつりやっていない自分にとって、
プログラミングはまだまだ敷居が高く感じる。

そのため、AWS SDK for Python(Boto3)でやりやすいところから慣れていくことにした。


VPCとインターネットゲートウェイの作成とアタッチを実施

今回は下記を参考。

dev.classmethod.jp


VPC作成

所持しているMACにBoto3インストールを実施
AWS認証情報は設定済みで事前準備はOK

ファイル create_vpc.py を用意

import boto3                                  
 
client = boto3.client('ec2')           
response = client.create_vpc(
    CidrBlock='10.2.0.0/16',
)
 
print(response)

はじめに使用するboto3をインポート
クライアントに、VPCを作成するclass EC2.Client メソッドを指定
レスポンスに必要なパラメータを設定

Boto 3 Docs 1.11.0 documentation を確認、必要なパラメータ CidrBlock を指定

ファイル作成後、pythonを実行

$ python create_vpc.py

その後、VPC作成を確認

f:id:pj124183:20200112133200p:plain

・インターネットゲートウェイ作成

ファイル create_internet_gateway.py を用意

import boto3

client = boto3.client('ec2')
response = client.create_internet_gateway(
)

print(response)

インターネットゲートウェイ作成にもclass EC2.Client メソッドが必要なので指定 レスポンスに必要なパラメータはなかったため、書き方をドキュメントからそのまま貼り付け

実行して作成を確認

f:id:pj124183:20200112135010p:plain

VPCにインターネットゲートウェイをアタッチ

ファイル attach_internet_gateway.py を用意

import boto3
 
client = boto3.client('ec2')
response = client.attach_internet_gateway(
    InternetGatewayId='igw-0a5440d06838c44c0',
    VpcId='vpc-00eb973cbec06ab1a'
)
 
print(response)

class EC2.Client メソッドを入れる
アタッチする際には、VpcIdとInternetGatewayId が必須なので入れる

実行してアタッチされていることを確認

f:id:pj124183:20200112135830p:plain

・サブネットを作成

ここからは自分でドキュメントを確認して、
サブネットを以下ファイルで作成してみた。


import boto3

client = boto3.client('ec2')
response = client.create_subnet(
    CidrBlock='10.2.0.0/24',
    VpcId='vpc-0f3695e73591f7935'
)
 
print(response)

ファイル実行後、作成を確認

f:id:pj124183:20200112180713p:plain


プログラミング苦手意識を克服したい

簡単に試してなんとなく理解をする。
あとは数をこなして理屈を覚えて身体にしっかり入れる。

もっとAWSが楽しくなりますように。

【AWS】EC2インスタンスにCPU使用率アラートを設定した

標題の件ですが、さくっと直感的にやれてしまうほど簡単で助かりやす。

アラームを作成する

CloudWatch ダッシュボード > アラーム > アラームの作成

f:id:pj124183:20200111113922p:plain

新しいアラームの作成 画面になるので、以下項目を設定

・メトリクスの選択

すべてのメトリクス > EC2 > インスタンス別メトリクス > 対象のEC2インスタンスとメトリクス名 [CPUUtilization] を選択

メトリクスは、インスタンスの利用可能な CloudWatch メトリクスのリスト表示を参照

次に、グラフ化したメトリクス > 期間を1分に変更 > メトリクスの選択 をクリック

・アラームの詳細

名前と説明は適当に。
次の時:CPUUtilization が >= 80 と設定

f:id:pj124183:20200111115054p:plain

・追加設定

欠落データの処理方法:適性(しきい値を超えていない)
これをしておかないと、データ不足で表示されてしまう。

以下設定画面の補足

このオプションは、アラーム評価のためのメトリクスデータがない場合に適用されます。

・アクション

メールを飛ばしたいので、状態:アラーム、通知送信先にリストを設定

f:id:pj124183:20200111115349p:plain

最後にアラームの作成

・新しいメールアドレスの確認

画面に新しいメールアドレスの確認が表示

f:id:pj124183:20200111120559p:plain

通知先に指定したメールにAWSからメールが届くのでリンクをクリック 下記画面の表示が出ればOK

f:id:pj124183:20200111120907p:plain

アラートの作成を確認

f:id:pj124183:20200111115549p:plain


・アラートテスト

メール送信されるのか確認のため、EC2インスタンスでCPU使用率を上げるコマンドを行う

$ yes >> /dev/null &

CPU使用率が上がっているのを確認

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 662184   2088 252176    0    0     2     4   25   48  0  0 99  0  0
 1  0      0 662184   2088 252176    0    0     0     1  264   48 100  0  0  0  0
 1  0      0 662184   2088 252176    0    0     0     0  258   36 98  2  0  0  0
 1  0      0 662184   2088 252176    0    0     0     0  253   15 98  2  0  0  0
 1  0      0 662184   2088 252176    0    0     0     0  256   24 98  2  0  0  0
 1  0      0 662184   2088 252176    0    0     0     0  257   32 100  0  0  0  0
^C
$

しばらく待つ。


・アラートメールを確認

ALARM: "cpu-alert-test" in Asia Pacific (Tokyo) というメールを受信

ダッシュボード上でアラートになっていることを確認

f:id:pj124183:20200111122909p:plain


とりあえず一旦設定完了。
そろそろ小さいサーバを運用していき、日々のアラートを対処しながらAWS力を付けていきたい。