さくらのクラウドでDiskFullになってしまったのでストレージ拡張をした

さくらのクラウドインスタンスを立ててLXDを使った検証をしていて、とりあえずディスクを20GBにして使っていたら気がついたらディスクの空きがなくなってしまい、検証をある程度進めていてインスタンス作り直して手動で構築しなおすのも面倒だったのでディスク拡張をやってみました。

OSはUbuntu16.04で、ファイルシステムext4です。

問題発覚

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
udev                            983M     0  983M   0% /dev
tmpfs                           201M  8.4M  192M   5% /run
/dev/vda3                        16G   16G     0 100% /
tmpfs                          1001M     0 1001M   0% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                          1001M     0 1001M   0% /sys/fs/cgroup

/dev/vda3 が空きがないのが見てわかります。LXD用のzfsイメージのサイズを大きく割当すぎたのが原因でした。 この時最悪だったのが、適当にコマンドを打つとそのコマンドが刺さって応答がなくなってしまうようになったことでした…。

ディスク拡張作業

インスタンスをシャットダウン

シャットダウンしないと操作できないので一旦シャットダウンします。

f:id:kuro_m88:20161207231836p:plain

f:id:kuro_m88:20161207232125p:plain

容量を大きくした新しいディスクを作成する

ディスク一覧より、新しいディスクを作成します。

f:id:kuro_m88:20161207232255p:plain

この時、空のディスクを作るのではなく、ディスクのソースに20GBの元のディスクを指定します。 こうすることで元のディスクの内容が新しいディスクにクローンされます。

f:id:kuro_m88:20161207232416p:plain

ステータスが完了になるまで(コピーが完了するまで)待ちましょう。

f:id:kuro_m88:20161207232503p:plain

元のディスクをインスタンスから取り外す

停止させたサーバから元のディスクを取り外します。

f:id:kuro_m88:20161207232604p:plain

新しいディスクをインスタンスに接続する

停止させたサーバに新しいディスクを接続します。

f:id:kuro_m88:20161207232639p:plain

f:id:kuro_m88:20161207232817p:plain

サーバ上で認識されるディスクサイズを拡張する

新しいディスクが接続できたら、サーバを起動します。 この状態ではまだファイルシステム上はディスクは拡張されていませんし、 df -h してもリサイズ後のサイズで認識されていません。

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
udev                            983M     0  983M   0% /dev
tmpfs                           201M   11M  190M   6% /run
/dev/vda3                        16G   16G     0 100% /
tmpfs                          1001M     0 1001M   0% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                          1001M     0 1001M   0% /sys/fs/cgroup

parted -l コマンドでパーティションを確認しますが、この時に拡張済のディスクのサイズとGPT上のディスクのサイズが違う事をpartedが検知してくれるので、ここで修正を行います。

$ sudo parted -l
Warning: Not all of the space available to /dev/vda appears to be used, you can
fix the GPT to use all of the space (an extra 41943040 blocks) or continue with
the current setting?
Fix/Ignore? Fix
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
1      1049kB  2097kB  1049kB                        bios_grub
2      2097kB  4297MB  4295MB  linux-swap(v1)
3      4297MB  21.5GB  17.2GB  ext4

修正ができたら、 /dev/vda (接続したディスクの名前) のパーティションサイズを変更します。

$ sudo parted /dev/vda
GNU Parted 3.2
Using /dev/vda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
1      1049kB  2097kB  1049kB                        bios_grub
2      2097kB  4297MB  4295MB  linux-swap(v1)
3      4297MB  21.5GB  17.2GB  ext4

(parted) resizepart 3
Warning: Partition /dev/vda3 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [21.5GB]? 42.9GB
(parted) p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
1      1049kB  2097kB  1049kB                        bios_grub
2      2097kB  4297MB  4295MB  linux-swap(v1)
3      4297MB  42.9GB  38.6GB  ext4

(parted)
Information: You may need to update /etc/fstab.

パーティションの拡張ができました。

次はファイルシステムの拡張です。 resize2fs コマンドがよしなにやってくれます。

$ sudo resize2fs /dev/vda3
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/vda3 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/vda3 is now 9424544 (4k) blocks long.

確認

最後に確認をします。

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
udev                            983M     0  983M   0% /dev
tmpfs                           201M   14M  187M   7% /run
/dev/vda3                        36G   16G   19G  47% /
tmpfs                          1001M     0 1001M   0% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                          1001M     0 1001M   0% /sys/fs/cgroup

拡張できたようです。めでたしめでたし。

追記 (2016/12/09)

前佛さんに自動ディスク容量拡張機能について教えて頂きました!

knowledge.sakura.ad.jp

さくらのクラウドに実装されている「ディスクの修正」機能に対応したパブリックアーカイブのOS から起動した場合にこの機能が使えるようです。
この機能があればサーバ上での作業が減って楽できますね!

DNSのレコードをGitHubで管理 & 自動反映する

最近調布技研という団体のDNSのネームサーバーをCloudflareに変えてみた。 Cloudflareは無料でAPIつきのネームサーバーとCDNが使えてとても便利そうだったので。

www.cloudflare.com

APIつきのネームサーバーが使えるようになったので、レコード管理 & 反映の自動化をやってみた。

DNSレコードをGitHubで管理する

管理するために作ったのがこちら。

github.com

TerraformにCloudflareのproviderがあったので、これを使ってレコード設定を記述するようにした。

Provider: Cloudflare - Terraform by HashiCorp

Cloudflareの設定 (cloudflare.tf)

variable "cloudflare_email" {
  description = "cloudflare email"
}

variable "cloudflare_apikey" {
  description = "cloudflare api key"
}

provider "cloudflare" {
  email = "${var.cloudflare_email}"
  token = "${var.cloudflare_apikey}"
}

上記がTerraformのCloudflare providerを使うために必要な設定で、CloudflareのAPIキーをここに書いても動くけど、publicなリポジトリなので実行時に環境変数で渡すことにした。

レコードの設定 (record.tf)

resource "cloudflare_record" "chofu_tech_A" {
    domain = "chofu.tech"
    name = "chofu.tech"
    value = "151.101.100.133"
    type = "A"
}

resource "cloudflare_record" "www_chofu_tech_A" {
    domain = "chofu.tech"
    name = "www.chofu.tech"
    value = "151.101.100.133"
    type = "A"
}

こんな感じでレコードを列挙していく。ただのテキストファイルなのでこれでプルリクベースで管理できるようになった。

DNSレコードの設定変更が自動反映されるようにする

プルリクのマージ後に自動で実行するためのツールとしてCircleCIを使った。

circleci.com

CircleCIは実行時に渡す環境変数が設定できて、その環境変数は外部から読めないようにできるのでAPIキーを隠しておきたい場合に便利。

TF_VAR_cloudflare_email = "hoge@example.com"
TF_VAR_cloudflare_apikey = "hogehoge"

環境変数はこの2つを設定しておいた。 TF_VAR_ で始まる環境変数はTerraform内のパラメータとして使える。
あとは、CircleCIの設定ファイルに master ブランチに変更があった場合は terraform plan のみ実行(反映はされない)、 production ブランチに変更があった場合は terraform apply を実行(実際に反映される) されるようにして反映が自動で行われるようにした。

chofutech-public-dns-record/circle.yml at master · chofutech/chofutech-public-dns-record · GitHub

これでしばらく運用してみて便利そうだったら自分のドメインもこんな感じで管理してみようかなと思う。

「サーバレス」に対する気持ち

「サーバレスアーキテクチャ」という言葉を目にするようになって、なんだかもやもやするなぁと思っていた。 最近だと、「サーバレス」という言葉の方がよく目にする気がする。

www.publickey1.jp

この記事を読んで、さらに違和感しかなくなった。

僕の気持ち

…サーバレスって、何がないんだっけ?

Twitter上での皆さんの気持ち

自分だけかなと思ってTwitterを検索してみると、同様に違和感を感じている方がいて安心(?)した。

サーバとは

サーバ - Wikipedia

サーバあるいはサーバー(英: server)は、コンピュータの分野では、本来はソフトウェアの用語であり、クライアントサーバモデルにおいてクライアントからの要求に対して何らかのサービスを提供する役割を果たす側のプログラムを指す言葉である。

serverの意味 - goo辞書 英和和英

〔コンピュータ〕 サーバー:ネットワーク上で他のコンピュータに情報やサービスを提供するコンピュータ

サーバとはサービスを提供(Serve)するからサーバ(Server)と呼ばれる。
その前提からすると、「サーバレス」はサービスの提供者が居ないような気がしてやはり変な感じがする。

サーバレスとはなんなのか

前述の意味を真に受けてしまうと何もしないに等しい状態になってしまうし、さすがにそんなことはない。

サーバがないというより、自前で管理しなくて良い、マネージドサービスのことを言っているんだと思う。

一番よく例に出されるのがAWS Lambda。ドキュメントに書いてある説明がわかりやすい。

AWS Lambda とは - AWS Lambda

AWS Lambda は、コードを AWS Lambda にアップロードすると、サービスが AWS インフラストラクチャを使用してコードの実行を代行するコンピューティングサービスです。

サーバを管理しなくてよくて、アプリをデプロイするだけで良いっていうのは要するにPaaSのことでは。

さくらインターネットの田中社長もこんなツイートをしていた。

ちなみに、「美味しい」は「多いし」のtypoだそうです。

「サーバレス」はマーケティング用語であって技術的にはその用語自体のことを気にする必要はなさそう。

なんと呼べばいいのか

PaaSに違いないということはわかった。

PaaSと言われるとHerokuが最初に思い浮かんだのだが、HerokuとAWS LambdaやGoogle Cloud Functionsは同じPaaSのくくりでも何か違う気がする。

SDKが必要/不要などもあるが、前者は入力としてウェブブラウザ等からのHTTPリクエストを受けるのを前提としていて、後者はもっと汎用的に「イベント」を受けるのを前提としている。ウェブアクセスだけでなく、「ストレージにオブジェクトが置かれた」などあらゆるイベントのトリガーを設定することができる。

これは、一番最初に挙げた記事中にも書かれているが、入力に対して出力を返す関数のようなもの、 Function as a Service と呼ぶ方がよさそう。

「サーバレス」はマーケティングのための用語で、「PaaS」に変わりないし、もっと詳しく分類するとすれば「FaaS」ということで自分の中では落ち着いた。

追記

同期の反応

f:id:kuro_m88:20160830195822p:plain

「平日に会社を休む」という概念が通じなかった話

少し前に髪の毛を切りに行った時の話。

店員 「土日休みのご職業なんですか?」

僕 「はい」

店員「土日は何されてるんですか?」

僕「飲み会とか誘われなければ家でグダグダしてることが多いですね、どこも混んでますし」

店員「何もされないんですか?」

僕「もし出かけたいところがあったら平日に休み取るかもしれないですね」

店員「平日お休みの職業なんですね!」

僕「いや、休みを取るんですよ」

店員「休めるんですね!」

僕「」

まぁ店員さんも忙しそうだし、閉店前で疲れてただろうから会話に頭が回ってなかっただけかもしれないし、シフト勤務の方は不定休が当たり前なのかもしれない。
もしくは、自分の話し方が悪かっただけか。

だから何だというのがあるわけじゃないけど、会話が咬み合ってないような感じがしてもやもやした気持ちになった。

オチはないです。