doridoridoriand’s diary

主に技術的なことを書いていく予定(たぶん)

corretto8をAnsible経由でインストールしてAmazonLinuxで使う

前回書いたブログの日にちが1月2日だって。もう引くレベル。

個人用途ではOracleJavaのライセンス問題はそこまで気にする必要ないけれども、会社でJavaを使ってサービス作って運営する業務をしている身としては、頭の片隅にいつもいる感じで、ちょっと気持ち悪かったのも事実。

そんなときに登場した Corretto

AWSありがてえ。。

以外の何者でもない感じであった。(まあOpenJDKでいこうってプロジェクトもあるので完全ではないけど)

Jenkinsを立てる必要が出てきて、どうせなら使ってみようと思って、Ansible経由でインストールしてみたので、その過程を忘備録的に残しておく。
※Jenkinsのことを脳死で嫌う人いるけれども、別にそれをCircleCIやCodeShip変えたからモダンだみたいなのも個人的にはよく分からない。まあ確かにCircleCIチョー便利なのは納得しますが。

使用環境はAmazonLinux2。いきなりAnsibleのtask貼っちゃう。

はい。これだけ。AmazonLinuxならこれだけでインストール完了します。

ついでにJnekinsをインストールするtaskも貼っておく。

これらのインストールが完了して、初期設定とか済ませて、本当にcorrettoが使われているのかをJenkinsの管理画面から確認する。

jenkins runs with corretto8
jenkins runs with corretto8

問題なさそう。

ターミナルをカラフルに表示してみる

12月があっという間で本当に光陰矢の如しとはこのとこだなと思いましたまる

一ヶ月強ぶりの更新となった。一ヶ月ぶりの更新なのにまさかの小ネタなのはお許し下さい

ログ出力時のターミナルの表示をもっとリッチにしたいと思い、どの色が使用可能なのかを確認したかったので作った突貫スクリプト
こちらのブログを参考にした

以下gistにまとめた

実行するとこんな感じで表示される f:id:doridoridoriand:20180102214957p:plain

次回はもっとまともな記事を書こう

JMeterのクラスタをゆるく立ててみる

仕事でJMeterクラスタを使う必要が出てきたので、割と簡単に立てられる方法無いかなと思い、実際にやった方法を忘備録的に残しておく。(まあ会社のwikiにちゃんとあるんだけれど)

GatlingやSaasなどが既に沢山ある状況で、なんで昔ながらのJMeterかというと、既にあるシナリオを使いたいというのが最大の理由。 とはいえJMeterが悪いわけでは全く無いので新しい何かにするモチベーションもなかったのも事実。

構築は全部AWS上。スレッド数がそこそこ多いので、Master-Slave構成とした。 東京リージョンを使用して建てたが、負荷が1つのAZに依るのはテスト的にも基盤的にも良くないだろうと考え、2つのAZに均等にまたがって建てるようにした。
Slave側をstop/startする度にパブリックDNSが変わるのも不便かと思い、本当はEIPをアタッチすべきであるが、aws shellを使ってPublicDNS名引けるよなと思ったこと、将来的にはクラスタサイズを自由に変えたいという思いがあったことなどから敢えてEIPは使用していない。

tag:Nameを適切に設定していれば、aws cliとjqを使用して以下のように取得することが可能である。
以下はtag:Nameを load-test-jmeter-slave-1c に設定していた場合の例。

$ aws ec2 describe-instances --filters="Name=tag:Name, Values=load-test-jmeter-slave-1c" | jq -r ".Reservations[].Instances[].PublicDnsName"
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

これが分かればMasterからSlaveに接続する際に困らないはず。

JMeterとJava8のインストールはAnsibleを使用。 JMeterインストールの主要部分を切り出したロールはこんな感じ。

---

- name: download Apache JMeter
  shell: >
    wget -O {{ jmeter.src_path }} {{ jmeter.pkg_url }}

- name: Unarchive Apache JMeter
  unarchive:
    src: "{{ jmeter.src_path }}"
    dest: "{{ jmeter.dst_path }}"
    remote_src: yes

vars配下には以下の内容を記したmain.ymlを配置してある。

## vars for Apache Jmeter
---
jmeter:
  src_path: /usr/local/src/source/apache-jmeter-3.3.tgz
  dst_path: /usr/local/src/script
  pkg_url: http://ftp.yz.yamagata-u.ac.jp/pub/network/apache//jmeter/binaries/apache-jmeter-3.3.tgz

読むと分かるのだがこれはJMeterのインストールにしか使えない。メモリのアロケーションとかその他confをいじった状態で再度Ansibleを流してしまうと綺麗サッパリなくなってしまうので注意。
(本当はちゃんと主要ファイルをテンプレート化して撒く処理を追加するなりすれば良いのだけれど、ゆるくクラスタを立ててみるの趣旨からはそれてしまうので、今回はなしの方向で)

ここまで出来ればとりあえずJMeterをMaster-Slave構成で起動できるようになる。

Masterから実際に繋いでみる。コマンドは以下のようになるはず。

$ ./jmeter -n -t test.jmx -e -l log.jtl \
  -R ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com,ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com,ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

一応オプションを説明すると、

-n cliモードで起動(本テストでは基本的にGUIを起動しないように)
-t シナリオファイルの指定
-e 実行後のレポート出力
-l 実行後のログファイルの出力
-R 使用するSlaveのエンドポイント

もっとちゃんと設定すると、 このページのような GatlingライクなHTMLでグラフィカルなレポートも出力できたりするが、今回はとりあえず動かしたかったので。 今回はここまで。

CloudFormation忘備録2


前回はただ単体のセキュリティグループを作っただけなので、今回は複数のセキュリティグループを連携させてみる。

例えば図のような経路に対するセキュリティグループを作りたくなったとする。

img-1.png

このときに、それぞれのコンポーネントに対してセキュリティグループを充てる必要が出てくる。 今回の場合ではリクエストを一番最初に受け付けるロードバランサと、そのロードバランサから来たリクエストを処理するAPサーバーの2つとなる。 ロードバランサはSSL終端をしているためHTTPS(443)のみ。APサーバー達はロードバランサからのリクエストしか受け付けないようにする。 (SSH出来ないよとかはとりあえず無視で。それは別のセキュリティグループを作って充てましょう)

前回書いたセキュリティグループのYAMLファイルを流用する。
以下のようにディレクティブを加えた。

---
AWSTemplateFormatVersion: "2010-09-09"
Description: >
  Here is the area of description of this CloudFormation template.
Resources:
  WebAPServersSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: SecurityGroup of webservers
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '3000'
          ToPort: '3000'
          SourceSecurityGroupId: !Ref ApplicationLoadbalancerSecurityGroup
      Tags:
        - Key: Name
          Value: dev-web-ap-sg
      VpcId: vpc-XXXXXXXX
  ApplicationLoadbalancerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: SecurityGroup of Application Load Balancer
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '443'
          ToPort: '443'
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: dev-alb-sg
      VpcId: vpc-XXXXXXXX

別段変わったところは無く、ALB用のセキュリティグループが増えた形となる。ただしAPサーバー達に充てるセキュリティグループ dev-web-ap-sg には変更が入っている。

SecurityGroupIngressのアクセス元を表す表記が CidrIp から SourceSecurityGroupId へ変更となっている。 このように設定することによって、 dev-alb-sg を充てたロードバランサからのみのリクエスト受け付けるように出来る。 ちなみに今回は参照先・参照元共に一緒に生成しているため !Ref を利用して未知のセキュリティグループIDに対応出来るようにしているが、 既存のセキュリティグループを参照したい場合は sg-xxxxxxxx を書いてあげればおk。

前回のCloudFormationのスタックを利用してupdate-stackを実行。

無事にできていた。

img-2.png

CloudFormation忘備録

前のエントリーから非常に時間が開いてしまった。。
前のエントリーの投稿日60日前とか死ぬしかない。

本当に意識的に書いていかないと全然続かないな。 忙しかったんだけど、まあ酒飲んでる時間とかちょっと削れば1エントリーくらい書けるわけで。 まあ良い訳ですね。


業務で積極的にCloudFormationを使うようにしており、セキュリティグループやらロードバランサもCloudFormationで作っている。 以外とこの辺をCloudFormationで作っている人が居ないようなので、忘備録がてらブログに記しておく。

AWSのドキュメント読めば正直解決するのであるが、デバッグしずらいところでもあるので、このエントリーが誰かの役に立てばと。

いきなりソースコードから。 (not ステーキ)

---
AWSTemplateFormatVersion: "2010-09-09"
Description: >
  There is the area of description of this CloudFormation template.
Resources:
  WebAPServersSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: SecurityGroup of webservers
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: dev-web-ap-sg
      VpcId: vpc-XXXXXXX

最小構成のセキュリティグループのCloudFormationテンプレートを書いた。

おおまかな構成としては

AWSテンプレートフォーマットのバージョン
このテンプレートの説明
テンプレートで定義しているリソース

となっている。意外と構成要素少ない。なので、リソース配下にどのようなリソースをおけばよいかを書けば基本的には完成する。

一つずつ説明。

WebAPServersSecurityGroup

ここは正直なんと書いても問題ない。これ自体が変数みたいなもの。 今回は例として、WebAPサーバーにアタッチするセキュリティグループとしたので、このように書いているだけ。

Type: AWS::EC2::SecurityGroup

これはどのようなリソースをこのディレクティブ内部で使用するかを定義するもの。これはAWSのドキュメントを調べないとわからないので各自で。

Properties:

この下にネストさせて、色々構成物を定義していく。

GroupDescription: SecurityGroup of webservers
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: '80'
    ToPort: '80'
    CidrIp: 0.0.0.0/0

GroupDescription

セキュリティグループの説明文。事業部では英語で書くことが決まりとなっているが、別に日本語でもエラーにはならないと思う。

SecurityGroupIngress

インバウンドのルールのこと。ちなみにアウトバウンド(EC2 => ネット)の方は SecurityGroupEgress。だた、EC2にアタッチするセキュリティグループでアウトバウンドを制限する要件はそれほど高くないと思われるので、今回は割愛。
複数定義したいときは次のように書くことも出来て、

 - IpProtocol: tcp
   FromPort: '80'
   ToPort: '80'
   CidrIp: 0.0.0.0/0
 - IpProtocol: tcp
   FromPort: '443'
   ToPort: '443'
   CidrIp: 0.0.0.0/0

ちなみに更に一気に範囲を指定してあげたいときは

- IpProtocol: tcp
  FromPort: '2000'
  ToPort: '4000'
  CidrIp: 0.0.0.0/0

とすることで 2000~4000番ポートを一気に開けることが出来る。 完成したCloudFormationテンプレートを実際に使用したい時は以下のコマンドを使用する。
(AWS CLIの基本的な使い方はマスターしている前提で話しています。そもそもAWS CLIってなんぞやって方はこちらを参照ください)

$ aws cloudformation create-stack --stack-name=dev-web-application-security-group --template-body=file://dev-web-ap-sg.yml

YAMLファイルを dev-web-ap-sg.yml として保存して、この構成名を dev-web-application-security-group として作成する感じ。

実行すると以下の結果が返ってくる。

/Users/dorian/sandbox aws cloudformation create-stack \
                      --stack-name=dev-web-application-security-group \
                      --template-body=file://dev-web-ap-sg.yml | jq -r
{
  "StackId": "arn:aws:cloudformation:ap-northeast-1:0123456789:stack/dev-web-application-security-group/8d7bf440-c6e9-11e7-931f-500c44f24c1e"
}

マネコンを開いてみると

ててーん。あっという間に完成。実際にセキュリティグループを見てみると

確かにできている。ちなみにCloudFormationの画面を確認してみるとこんな感じで出ていた。

最初に頑張って書いてしまえば、インフラ構成をgitでバージョン管理出来たりするので変更履歴置いやすいし、インフラエンジニアじゃなくてもどのような構成になっているのかを分かってもらえるので変なコミュニケーションが発生せず快適だったりする。

inode を枯渇させてみる

毎週書くとか言っておきながら、すごく日が開いてしまった。。よくない。。

とか言っておきながら、今回も小ネタ的なものですみません。 inode を枯渇させてみる。

業務中にルートボリュームがおかしくなったサーバーがあり、調査の過程でinodeも調べたので、興味本位がてらやってみた。 (結局そのサーバーは別の原因でルートボリュームがおかしくなっていたのだけれども)

そもそもinodeってなんぞや、全く聞いたことが無いで、という方は以下を読んでおけばなんとなくわかるかと思います。
inode番号とは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

数に上限があるので、細かいファイルをガンガン保存していたりすると普通に枯渇する。そんなに無いとは思うけれどJSONをファイルとして 大量に保存していたりすると大変そう。

枯渇させるのは簡単で、ファイルをひたすらtouchしてあげればおk。 計測がてら、以下のようなスクリプトを組んでみた。

。。。と実行してみたことろ、SSH越しでコマンドを実行していため、生成速度が遅い。
1時間程度回してみたが、0.3%くらいしか使用率が上がらなかったorz
inode枯渇のタイミングで挙動がスクリプトの挙動がおかしくなって、正確な測定にならないだろなとか考えてSSH越しで別サーバーを立てて叩くようにしたが、そもそも測定が終わらなさそうなので、考えを改めて、普通にローカルで回せるように変更。
本当は別のドライブアタッチしてあげれば、そんな心配もしなくて良いのだけれども、まあ面倒なので
最終的に以下スクリプトを利用。

これを回すと以下のログが出力されるようになっている。

I, [2017-09-10T12:41:28.910920 #20048]  INFO -- : Used: 86386  Remain: 3753614  Percentage: 97.750
I, [2017-09-10T12:41:28.946672 #20048]  INFO -- : Used: 86396  Remain: 3753604  Percentage: 97.750
I, [2017-09-10T12:41:28.981453 #20048]  INFO -- : Used: 86406  Remain: 3753594  Percentage: 97.749
I, [2017-09-10T12:41:29.016357 #20048]  INFO -- : Used: 86416  Remain: 3753584  Percentage: 97.749
I, [2017-09-10T12:41:29.050865 #20048]  INFO -- : Used: 86426  Remain: 3753574  Percentage: 97.749
I, [2017-09-10T12:41:29.085021 #20048]  INFO -- : Used: 86436  Remain: 3753564  Percentage: 97.749
I, [2017-09-10T12:41:29.119606 #20048]  INFO -- : Used: 86446  Remain: 3753554  Percentage: 97.748
I, [2017-09-10T12:41:29.155900 #20048]  INFO -- : Used: 86456  Remain: 3753544  Percentage: 97.748
I, [2017-09-10T12:41:29.190215 #20048]  INFO -- : Used: 86466  Remain: 3753534  Percentage: 97.748

出力されるものは現在のinodeの使用率、残り、残りの%表記となっている。
最終的に15時間ほど掛かって完全に枯渇した。
枯渇すると以下のログが吐き出される。

ubuntu@ip-172-31-3-220:~$ ruby run_local.rb
/usr/lib/ruby/2.3.0/fileutils.rb:1157:in `initialize': No space left on device @ rb_sysopen - ./inode/1/e28c7144-aff1-4ddf-97cd-f93abaee09f7 (Errno::ENOSPC)
        from /usr/lib/ruby/2.3.0/fileutils.rb:1157:in `open'
        from /usr/lib/ruby/2.3.0/fileutils.rb:1157:in `rescue in block in touch'
        from /usr/lib/ruby/2.3.0/fileutils.rb:1153:in `block in touch'
        from /usr/lib/ruby/2.3.0/fileutils.rb:1151:in `each'
        from /usr/lib/ruby/2.3.0/fileutils.rb:1151:in `touch'
        from run_local.rb:18:in `block (2 levels) in <main>'
        from run_local.rb:15:in `times'
        from run_local.rb:15:in `block in <main>'
        from run_local.rb:12:in `times'
        from run_local.rb:12:in `<main>'
ubuntu@ip-172-31-3-220:~$

容量的には余裕。

ubuntu@ip-172-31-3-220:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            488M     0  488M   0% /dev
tmpfs           100M  6.8M   93M   7% /run
/dev/xvda1       30G  1.5G   28G   5% /
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /run/user/1000

しかしinodeは確かに枯渇している。

ubuntu@ip-172-31-3-220:~$ df -i
Filesystem      Inodes   IUsed  IFree IUse% Mounted on
udev            124865     381 124484    1% /dev
tmpfs           126832     469 126363    1% /run
/dev/xvda1     3840000 3840000      0  100% /
tmpfs           126832       1 126831    1% /dev/shm
tmpfs           126832       3 126829    1% /run/lock
tmpfs           126832      16 126816    1% /sys/fs/cgroup
tmpfs           126832       4 126828    1% /run/user/1000

この状態ではボリュームに対する、書き込みが発生するいかなる処理も実行不可能となる。 もちろんファイルの新規作成は無理であるし、

ubuntu@ip-172-31-3-220:~$ touch test.txt
touch: cannot touch 'test.txt': No space left on device

入力補完といった、一見ファイル作成とは無関係のコマンドも、以下のように使用することが出来ない。

ubuntu@ip-172-31-3-220:~$ less -s re-bash: cannot create temp file for here-document: No space left on device
-bash: cannot create temp file for here-document: No space left on device

これらに対処する一番簡単は方法は、不要ファイルを削除すること。 以下のように、ちょっとでもinodeに余裕ができれば、

ubuntu@ip-172-31-3-220:~/inode$ df -i
Filesystem      Inodes   IUsed  IFree IUse% Mounted on
udev            124865     381 124484    1% /dev
tmpfs           126832     469 126363    1% /run
/dev/xvda1     3840000 3830454   9546  100% /
tmpfs           126832       1 126831    1% /dev/shm
tmpfs           126832       3 126829    1% /run/lock
tmpfs           126832      16 126816    1% /sys/fs/cgroup
tmpfs           126832       4 126828    1% /run/user/1000

ファイルの新規作成も可能。

ubuntu@ip-172-31-3-220:~$ touch test.txt
ubuntu@ip-172-31-3-220:~$ ls
test.txt

入力補完も問題なく効く。

CentOS7でXFSフォーマットされたルートボリュームを拡張する

会社で使用しているサーバーの1台でルートボリュームを拡張する必要が出てきたので、実施した。 CentOS7での拡張は経験がなかったので、忘備録としてブログに記載。

サーバーはAWS上に存在。今年の2月にEBSのサイズが自由に変更出来るようになった。 https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

検証に利用していたサーバーのルートボリュームは20GBだったのだが、ログのサイズが予想よりも大幅に大きかったため、99%まで逼迫していた。

今回は私物のAWSアカウントにサーバーを立てて会社で行った操作を記録。 何も考えずにウィザードに則ってインスタンス立てたりすると8GBのルートボリュームになっちゃったりする。 以下のようにすぐに逼迫してしまう。

[centos@dorian ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       8.0G  7.6G  499M   94% /
devtmpfs         477M     0  477M    0% /dev
tmpfs            496M     0  496M    0% /dev/shm
tmpfs            496M   13M  483M    3% /run
tmpfs            496M     0  496M    0% /sys/fs/cgroup
tmpfs            100M     0  100M    0% /run/user/0
tmpfs            100M     0  100M    0% /run/user/1000

これでは生きていけないので、EBSを変更する。 マネコンからは以下のように変更できる。

対象のインスタンスを選択し、ルートデバイスのところをクリック。

sc-1

するとブロックデバイスのポップアップが表示されるので、EBS IDの部分をクリックして、ボリュームのページに移動する。

sc-2

対象のボリュームが選択された状態になっているので、上部にあるアクションボタンからボリュームの変更を選択。

sc-3

sc-4

必要としているサイズに変更する。今回は100GBととしてみた。

sc-5

実行をするとボリュームの状態がin-use - modifyingとなり、サイズの変更が行われれていることがわかる。

sc-6

この作業には数分掛かるので、待つ。変更中でもボリュームはオンラインであるので、以下のように読み書きは可能(性能劣化はしていると思うけれども)

[centos@dorian ~]$ mkdir works
[centos@dorian ~]$ cd works/
[centos@dorian works]$ ll
合計 0
[centos@dorian works]$ touch file
[centos@dorian works]$ ll
合計 0
-rw-rw-r--. 1 centos centos 0  8月 19 08:40 file
[centos@dorian works]$

変更が完了すると、 in-use - completed(100%)と表示される。

sc-7

サーバーに戻ってパーティーション変更の作業を行う。 もちろん拡張したことは認識されていない。

[centos@dorian works]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       8.0G  7.6G  499M   94% /
devtmpfs         477M     0  477M    0% /dev
tmpfs            496M     0  496M    0% /dev/shm
tmpfs            496M   13M  483M    3% /run
tmpfs            496M     0  496M    0% /sys/fs/cgroup
tmpfs            100M     0  100M    0% /run/user/0
tmpfs            100M     0  100M    0% /run/user/1000

ただしディスク自体が100GBになっていることは再起動なしで反映されていた。

[centos@dorian works]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
└─xvda1 202:1    0    8G  0 part /

よってパーティーションの変更をすればおk まずはボリュームとパーティーションの現状確認をするため、 fdisk コマンドを利用して情報を引き出す。

[centos@dorian works]$ sudo fdisk -l /dev/xvda1

Disk /dev/xvda1: 8588 MB, 8588886016 bytes, 16775168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

[centos@dorian works]$ sudo fdisk -l /dev/xvda

Disk /dev/xvda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x000b2270

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/xvda1   *        2048    16777215     8387584   83  Linux

次にfdiks使用して、現在のパーティーションの削除と再作成を行う。 この作業の途中でインスタンス障害などでリブートが掛かると多分二度と起動しなくなるので要注意。

[centos@dorian works]$ sudo fdisk /dev/xvda
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


コマンド (m でヘルプ): p

Disk /dev/xvda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x000b2270

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/xvda1   *        2048    16777215     8387584   83  Linux

コマンド (m でヘルプ): d
Selected partition 1
Partition 1 is deleted

コマンド (m でヘルプ): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-209715199, 初期値 2048): 2048
Last sector, +sectors or +size{K,M,G} (2048-209715199, 初期値 209715199): 209715199
Partition 1 of type Linux and of size 100 GiB is set

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。

WARNING: Re-reading the partition table failed with error 16: デバイスもしくはリソースがビジー状態です.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
ディスクを同期しています。

緊張の一瞬。最後にWARNING出るのが普通にビビる。OSがまだ古い情報保持したままだよってことなのでことなので問題ないはず。

一旦再起動。

[centos@dorian works]$ sudo shutdown -r now
packet_write_wait: Connection to 52.38.77.75 port 22: Broken pipe
/Users/dorian/AWS_keys ssh centos@example.com
Last login: Sat Aug 19 08:36:55 2017 from nttkyo888131.tkyo.nt.ngn.ppp.infoweb.ne.jp
[centos@ip-172-31-26-162 ~]$

無事に再起動した。ボリュームを確認してみる。

[centos@ip-172-31-26-162 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       100G  7.6G   93G    8% /
devtmpfs         477M     0  477M    0% /dev
tmpfs            496M     0  496M    0% /dev/shm
tmpfs            496M   13M  483M    3% /run
tmpfs            496M     0  496M    0% /sys/fs/cgroup
tmpfs            100M     0  100M    0% /run/user/1000

無事に増えている。元の8GBを超えて追加出来るか試してみる。

[centos@ip-172-31-26-162 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       100G   12G   88G   12% /
devtmpfs         477M     0  477M    0% /dev
tmpfs            496M     0  496M    0% /dev/shm
tmpfs            496M   13M  483M    3% /run
tmpfs            496M     0  496M    0% /sys/fs/cgroup
tmpfs            100M     0  100M    0% /run/user/1000

無事に出来た模様。

今回はサーバーに搭載しているアプリケーションの関係でルートボリュームを拡張したが、ログのボリュームを別途用意し、LVMを組むなどの工夫をするほうが本来取るべき作業内容だとは思う。

つか緊張するのでもうやりたくないですね(^ν^)