Amemiya.workができるまで（前編）

この記事は、ぐすくまさん主催のMastodon Advent Calendar 2018のための記事です。

マストドンに関するアドベントカレンダーとしては、他に、SHさん主催のものなど、色々ありますので、興味ある人は見てみるといいと思います（ぐすくまさん主催のもののページに便利なリンクがあります）。

昨日の担当者はkhws4v1さんでした。自宅サーバーでマストドンインスタンスはロマンですね。いつか私も挑戦したいです。

ちなみに、S.H.さん主催のものの方では、昨日は「マストどす」管理人の7_nanaさんでした。

で、この記事ですが、タイトル通り、Amemiya.workができるまでの様子を、当時の勉強用ノートの中身そのまま垂れ流す形でお見せするものです。……が、書いていくにつれ、なんと3万字ほどの長文になってしまいました。こんなの、スクロールバー見ただけで読む気が失せるやつじゃないですかやだー。

ということで、前編後編とわけて投稿します*1。

前編の今日は、サーバーの設定を行い、マストドンを入れるための準備をし、マストドンをセットアップする所まで。明日投稿する後編では、マストドンの設定からアップデート、公開するまでを、それぞれお送りいたします。

「もし技術無い文系が鯖缶工場のご指導を受けつつインスタンスを立てたら」といったドキュメンタリーに近い記事として読んで戴けますと幸いです。

前日談

Amemiya.workを作ろうと考えるより以前、私は、ムトーの無料ホスティングサービスを利用して、中仙ドンという地域インスタンスを作っていました。

ところが、ユーザー数少なかったにも関わらず、私の使い方はサーバーへの負荷が酷かったようで、TLがカクついたり、更には利用規約の変更もあってムトーから「フォローされすぎ」という警告が来るようになってしまいました。

他のホスティングサービスを利用することも考えたのですが、それではあまり勉強にならないこと、丁度Discordに「鯖缶工場」というインスタンス立ち上げ支援のチャンネルが開設されたことから、自身でインスタンスを立てようと決意しました。

早速、鯖缶工場で支援を依頼。早速ぐずすまさんが支援者を募ってくださり、ikuradonさん、mimikunさん、きょりさんが協力を申し出てくださりました。

その間、お名前.comでドメインとVPSとを確保。au WALLETで決済しようとした所、決済できなかったので、近所のコンビニに車飛ばして*2支払ってきました。

ちなみに、私のこの手のスキルは、本当に大したことありません。Ubuntuは、デスクトップとして使ったことはありますが、専らGUIで、CUIはお遊びでフォーチュンクッキー入れたりSLコマンド入れたりする程度。

コマンドの意味とかも、検索かけながらやっとうっすらぼんやり理解したりしてなかったりという情弱っぷり。支援を申し出てくださったお三方から手取り足取り教えて戴きながらの立ち上げとなります。

1日目：Ubuntuのセットアップ

VPSの初期セットアップ

お名前.comのVPSは、初期セットアップはSentOSになっていて、SentOSをセットアップしてからでないと、他のOSが入らないという仕様になっていました。

まずは、SentOSをセットアップ。お名前.comの手順通りにやっていけば普通にセットアップ完了します。

Ubuntu16.04セットアップ

続いてUbuntu18.04をセットアップしようとしたのですが、ここで問題が発生。進めていく中で、どうしても途中で止まってしまいます。具体的には、「ソフトウェアの選択とインストール」という部分で12％までは進むものの、アップデート方法指定の画面が一瞬出てまた0％に戻されてしまうというのが無限ループ。謎。

仕方が無いので、16.04を入れて、そこから18.04へバージョンアップを試みます。

VPSのWebコンソールからOSの再インストールを実行。OSはUbuntu 16.04。VirtioはON。ディスク構成は基本構成のまま（だったハズ）ですが、これは、パーティションを切らない（「ディスク構成」を「カスタム」にして、スライダーを右端まで動かして/dev/vda一本にする）方が良かったなぁと後々後悔します。

以下、Ubuntu 14.04LTSの導入手順を参考に作業を進めていきます。なぜそんな古いバージョンのものを参考にするかというと、公式のものがこれしかないからです。……こういうトコで、「お名前.comは玄人向け」って言われるんでしょうね。

ホスト名は、任意で大丈夫です。ドメインである必要はありません。ユーザー名も任意。ただし、パスワードはできるだけ強くとのこと。パスワード管理アプリで作りましょう。忘れてしまったら大変なので、紙媒体手書きでメモします。このメモは鍵付きでしまっておきましょうね。

「ディスクのパーティショニング」、なぜか、dev/vdbがマウントされているという警告が出ました。アンマウントします。

改めて、「パーティショニングの方法」は「ディスク全体を使う」を選択。続いて「パーティショニングするメディアの選択」は仮想ディスク1（vba）を選択。「プロキシ使うんならプロキシ入れて」って言われましたが、スルーで。

18.04ではこの後上手くいきませんでしたが、16.04では無事にいけました。

「アップデートの設定」を「自動でアップデートしない」にします。もしこれがオンになっていると、勝手にアップデートが行われ、環境が滅茶苦茶になる恐れがあるためです。

「ソフトウェアの選択」はデフォルトのまま。

「ハードディスクへのGRUBブートローダのインストール」、「ブートローダをインストールするデバイス」はdev/vbaを選択。

時折、ちょっと固まったり、ひやっとする場面はありましたが、無事、16.04のインストールを完了。

Ubuntu18.04へのアップデート

間髪入れずにアップデートしていきます。VNCのままです。日本語フォントが入っていないので、日本語が全て豆腐になってます。

インストーラーが相当古かったらしく、大量の更新が処理されていきます。重たい。

「日本語フォントが全部読めない状態で、エラーで止まったらどうしよう……」とか思っていたら、どうもそれがフラグだったようで、見事に止まる。そしてなんかわかりませんが、編集画面に入ってしまったよう。とりあえずxで脱出。

何がなんだかわからないということで、一時的に言語を英語にすることに。

export LANG=en_US.utf8

で、改めて。

sudo apt update -y

sudo apt upgrade -y

sudo apt-get dist-upgrade -y

sudo apt install ubuntu-release-upgrader-core

exportは、現在の環境変数一覧に書き込むコマンドだそうで、今回だと、LANGという環境変数にen_US.utf8を設定してねという意味とのこと。

aptはパッケージ管理コマンドで、この後につけるサブコマンドで処理が変わるそう。

installは、権限や所有者などを一括指定してファイルコピーするときに使うコマンド。

sudoは、SuperUserがDoするコマンド。つまり、一般ユーザーが管理者権限を借りてコマンドを実行するという、とても重要なコマンドなようです。……この後、私はこれを使って大変なことをやらかします。

そんなこんなで、「configuring grub-pc」という画面までたどり着きました。

「What do you want to do about modified configuration file grub?」と尋ねられたので、ひとまず、「show difference」を選択します。何が変わったのかがわかります。行の最初に-があるものは削除された行、+は追加されたものです。

とくに問題無さそうなので、戻って「install the package maintainer's version」を選択。すると、ちょっと画面が面白いことになります。興味ある人は、ぜひ、インスタンスを立ててみましょう。

で、しばらくすると、「34 packages are going to be removed」と出ます。とりあえずdで何が消えるか確認します。古いカーネルが消されるのと、入れ替えによって不要になったパッケージが消されるだけのようだから大丈夫そうとのこと。qで脱出しyで削除実行。

yでシステムリスタート。

なんか上手くいったっぽいですが、念のため確認。

cat etc/os-release 

catとは、指定したファイルの中身を画面に表示させるコマンドで、元々はconcatnateの略だそう。ネコでもポストアポカリプス世界の通貨でもないんですね。

今回は、etcというフォルダの中のos-releaseというファイルの中身を確認しています。無事、18.04になってるようです。

Ubuntu18.04のセットアップが完了したので、この日は終了。

2日目：SSHとDocker

TeraTerm導入

まず、SSHクライアントをインストールします。今回は、TeraTermを選択しました。

公式サイトからインストールします。コンポーネントや追加タスクは標準のままです。

続いて、サーバー側の設定。

sudo apt install openssh-server

これで、SSHサーバーがインストールされたようです。

続いて、TeraTermのSSH鍵生成機能を使って鍵を作成し、公開鍵をサーバーへ転送します。お名前.comのマニュアルを使ってやろうとしましたが、できませんでした*3ので、別の方法をとります。

お名前.comにファイアーウォールなんてない

……そして、このタイミングで驚愕の事実が発覚します。

help.onamae.com

Q：【VPS（KVM）】ファイアーウォールは設置されていますか？
A：アプライアンスなどのファイアーウォールは設置しておりません。
ポート制限などのセキュリティ設定につきましては、VPS内で設定してください。

ということで、きちんとポート制限しないといけませんねと。

そのためにも、さっさとSSHで接続できるようにしてしまいます。

 SSHで接続できるようにする

TeraTermの設定→SSH鍵生成で、SSH鍵を生成します。設定はデフォルトのまま。

続いて、鍵のパスフレーズ→パスフレーズの確認で、パスフレーズを入力して、公開鍵（id_rea.pub）と秘密鍵（id_rsa）とをそれぞれ保存。

続いて、公開鍵（id_rea.pub）をtransfer.shというアップローダーにアップして、出てきたリンクをサーバー上へDLします。

ここでまたしても問題発生。URLを入れたところ、VNCが落ちました。結局、この後も何やってもダメでずーっと固まったままになってしまいました。サーバー再起動（ちなみに、コマンドは sudo reboot です）したら戻りましたけど。

仕方がないので、TeraTerm使って、IPアドレスから繋いでしまうことに。

TeraTermのファイル→新しい接続をクリック。認証画面で、OSインストール時に作成したユーザー名やパスワードを入力。すると、無事にTeraTermからログインできました。

早速、SSHをDLします。

mkdir -p ~/.ssh
chmod 700 ~/.ssh
curl -sSL (transfer.shにアップロードして出てきたURL) >> ~/.ssh/authorized_keys

cat  ~/.ssh/authorized_keys

最後のコマンドで、ssh-rsaから始まる文字列がだーって出たら成功です。

ちなみに、ここで、chmod 600 ~/.sshとすると、後のコマンドを打ち込んだ時に「権限ねーぞ」って怒られます。

とにかく、これで、SSHの公開鍵がサーバー側に送られたはずなので、SSHでの接続へ切り替えます。

「新しい接続」で、今度は、「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、秘密鍵を選択。「パスフレーズ」の所に、鍵のパスを入れます。

これで無事にSSHで接続できました。続いて、ログインを自動化します。

id_rsaと同じフォルダ内に任意ファイル名のTTLファイルを作ります。で、以下中身（ikuradonさん謹製）。

getdir dir
host = "ホスト名"
user = "ユーザー名"
pass = "パスワード"
file = "ファイル名"

msg = host
strconcat msg ':22 /ssh /user='
strconcat msg user
strconcat msg ' /auth=publickey /passwd='
strconcat msg pass
strconcat msg ' /keyfile='
strconcat msg dir
strconcat msg '\'
strconcat msg file
connect msg

パスワードでのログインを無効化

これで、SSLで接続できるようになったので、パスワードでのログインを無効化します。

sudo vim  /etc/ssh/sshd_config

SSHの設定が出ますから、PermitRootLogin、PasswordAuthenticationの前に付いている「#」を取り、また、続く文字列を「no」にします。PermitEmptyPasswordsの前の「#」も取ります。保存は、「Ctrl+C」→「:wq」でエンター。ちなみに、Ctrl+Cがコマンド入力モードへ戻る、wが保存、qが閉じるという意味だそう。

完了したらSSHを再起動します。

sudo systemctl restart ssh

これで、パスワードでのログインができなくなったはずです。

 ポートの設定

続いて、ポートをふさいでいきます。

sudo ufw default deny
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

上から順に、許可してないポートは全部拒否、SSH接続（22）は許可、http接続（80）は許可、https接続（443）は許可、UFWをこの設定で動かす……という意味だそう。

これで、ポートが塞がりました。

 Dockerを入れる

それでは、この日最後の作業。Dockerを入れていきます。まず、もともとDockerが入っているかどうかを確認します。

sudo docker version

コマンドが見つかりませんと出るので、Dockerは入っていないようです。

ちなみに、Dockerを作ってる会社には、CanonicalとDocker inc.とがあるので、前者であった場合には後者に切り替える必要があるとのこと。Dockerの公式マニュアルを見ながら入れていきます。

\は、￥を半角にしたやつです。あと、#や$、%が頭に付いている行が入力する行、それ以外は「こういう風に動くから確認してね」って行のようです。

安定リポジトリの設定は、今回は x86_64 / amd64 です。

Hello from Docker! と表示されたら完了です。

そしたら、実質2コマンドのdocker-composeもいれておきます。

sudo curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-%60uname -s-uname -m` -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

最後に、バージョンを確認します。

sudo docker-compose --version

無事、1.22.0と出ました。

tmuxについて

接続まわりでトラブルが起きた時のために、tmuxの使い方を教えて戴きました。以下、ikuradonさんのご説明。

あ、そうだ
なにか接続周りでトラブルが起きたとき、SSHは再接続の概念がないので
tmuxの話をさせてください

tmuxはターミナルマルチプレクサといい、仮想のコンソールを複数用意することが出来ます。また普通だとできない複数の接続元からの同一コンソールの操作、回線トラブルによる切断による復帰不可の回避などなど…いろいろできます。
それなり時間かかるコマンド中に切断された場合、SSHは切断を検知した瞬間そのログイン環境で動かしていたコマンドを全て停止させようとします。
なのでもう少しでビルドが終わるーなどのときに悲しい思いをしないためにSSHで接続したらtmuxセッションを開く/セッションに戻るを習慣づけると心の平穏を得られます。
で、具体的な話ですが、初めての場合はtmux、切断されちゃったときに戻りたいときはtmux attach、途中でセッションからはなれたい場合はCtrl+B👉dと入力するだけです。
やっぱり他にもめっちゃ便利な画面分割などありますが、今回は生存戦略要員として使います。

ということで、tmuxを使っていきます。

エントロピー補充

cat /proc/sys/kernel/random/entropy_avail

このコマンドを入れると、なにやら数字が出てきます。この数字がエントロピーの量で、これが枯渇してしまうと、暗号化の作業が止まってしまい、サーバースペックあるのになんか遅い重いって状態になってしまうそうです。

一般的には1500以上あった方がよいとのこと。

で、再び、ikuradonさんによる解説。

これの補充方法なんですが、本来は物理キーボードやマウスの入力などの/dev/input系からの入力を元に生成されているらしいのですが、VPSにそんなものは存在しないので必然的に枯渇しちゃうのです。
これの解決方法として、hwrngとhavegedが存在します。
hwrngはHardware RandomGeneratorの略で、物理乱数生成装置を利用したエントロピー補充をする方法です。物理乱数生成装置は真の乱数を生成するので実装さえ間違えなければそこからの攻撃は不可と言われています。
これの欠点として、ハードウェアが対応していないと使えないというところがあります。
で、じゃあない場合はどうするの？というとhavegedの出番です。

これは擬似乱数生成装置(/dev/urandom)をいじくり回した結果のデータをエントロピーに追加する方法です。なので擬似乱数生成の方法が割れ、タイミングが偶然合致すると暗号化の種もばれちゃうっていう可能性はあります。ただ、このばれちゃう確率は実は天文学的数字だとか…　

一応havegedのマニュアルによると、hwrngがあるのであればそっちをつかってね！のスタンスだったりします。
で、VPSの運営会社とシステムによるのですが
hwrngがある場合とない場合があるのでこれを確認した方が良いです

ということで、hwrngがあるのか無いのかを確認します。

sudo apt install rng-tools

cat /proc/sys/kernel/random/entropy_avail

全然増えてないどころか減ってるので、hwrng非対応のようです。rng-toolsを設定ファイルごと消してhavegedを入れます。

sudo apt purge rng-tools

sudo apt install haveged
cat /proc/sys/kernel/random/entropy_avail

無事増えたので、起動時に実行されるようにします。

sudo systemctl enable haveged

これで、SSHログインすら遅いって事態は避けられそうです。

3日目：メールサーバーと画像サーバーの準備

Gitにアカウントを作る 

まず先にMastodonを立てて、ローカルで動きを確認した後で、公開することになりました。

まず、GitHubにアカウントを作ります。

github.com

 そして、GitHubにログインした状態でMastodonのページを開き、Forkボタンをクリック。マストドンをフォークします。

ユーザーページのリポジトリの所に、Mastodonが入るはずです。

「Clone or Download」という緑色のボタンをクリックし、https:// から始まってmastodon.gitで終わるアドレスを控えます。

続いて、TeraTermでの作業。 cd ~ で、ホームディレクトリに移動します。

まずgitがきちんと入っているか、とりあえずgitとだけ入力してみます。なんか色々表示されたので、無事入ってるっぽいです。では、サーバー上からマストドンをDLしていきます。cloneを使います。

git clone [さっきのURL] live

これで、liveというフォルダの中にマストドンが入るハズ……なのですが、末尾の「live」を打つ前にDLが始まってしまいました。

lsコマンド*4を使って確認すると、新たにmastodonというフォルダができています。このフォルダの名前をliveへリネームします。

mv mastodon live

以降、マストドンに関する操作は、全部、liveフォルダの中で行います。フォルダを移りたい時にはcdコマンドを使います。

cd live

このコマンド、慣れない内はよく忘れます。メモ用紙か何かに書いてデスクにでも貼っとくといいと思います。

マストドンの最新版を取得

で、続いて、マストドンの最新の安定版を取得します。

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

これで最新の安定板が入ったはずなので、細かい設定をしていきます。

sudo vim docker-compose.yml

この中の、

### Uncomment to enable DB persistance
### Uncomment to enable REDIS persistance

という2つの項目のすぐ下にある行2行の冒頭にある「#」をそれぞれ取ります。

Ctrl+Cして:wqで保存。

mkdir postgres redis

このコマンドを打った後、lsをしました。mkdirは新しいディレクトリを作るコマンドなので、postgresとradisのディレクトリがきちんと作られたかの確認だと思います。

cp .env.production.sample .env.production

cpはカップリング……ではなくて、ファイルやディレクトリのコピーを行うコマンドです。

ls -la で.env.productionがあるか確認します。-laというのはオプションで、-lという横長の表みたいな形で表示されるオプションと、-aという隠しファイルも含めて全部表示させるというオプションとを合わせたもの。

 ビルド

それでは、ビルドします。

sudo docker-compose build

がーっと色々なものが流れて行きます。少し時間が掛かるので、ここで再びikuradonさんによる解説。

今やっているのは、Dockerのイメージ作成となります。
Dockerの仕組みとして、大元のイメージを利用し、そのイメージをカスタマイズしたイメージをレイヤーとして重ね合わせていったものを最終的なアプリサーバとして利用することが出来ます。
で、このイメージは今回のように手元でbuildする場合と、Docker Hubを利用して自動的にビルドする…といったことが出来ます。
このイメージに対して何かしら作業をする度にバージョン管理がされるので、気に入らない動作に関しては戻したり別のバージョンを作成したり…とgitと同じような作業をすることが出来ます。
要は仮想PCのgitみたいなモンですね

ただこのDocker、標準状態では仮想マシンをシャットダウンしてしまうと中のデータは消失してしまうので、先ほどコメントを外したdocker-compose.ymlファイルのようにVolumeを利用したり、AWS S3などの外部ストレージを利用することによって永続化というものを行います。

で、ここでお名前.comのVPS、あっという間にビルドを終了させます。もしかしてお名前.com、運用面はともかくハード面は優秀説……？

ビルドが完了したら、所有者権限を書き換えます。

sudo chown -R 991:991 public

 マストドンのセットアップ

そして、マストドンのセットアップを始めます。

sudo docker-compose run --rm web bundle exec rake mastodon:setup

これでセットアップが始まります。色々訊かれるので、それに合わせて回答を入力していきます。こういうのをウィザードというようです。

まず、ドメイン名どうするのか訊かれます。私は、この時のために取得したamemiya.workに。……これ、後々変更はできないそうです。

で、お一人様にするのかオープンにするのか。今回はひとまずオープンに。

ドッカー使ってるかどうか訊かれました。yで。

SQNホストもポートもデフォルトのままです。

SQNユーザーのパスワードを訊かれました。postgresってしたら入れました。

すると、「Database configuration works!?」と出ます。最後文字化けしてるのは、絵文字が使われているからだそう。

Redisとパスワードは空エンター。

そうしていくと、アップロードファイルをクラウドで格納するかどうか訊ねられます。今回は、手元にMinioを立てて、空き容量無くなったらWasabi辺りに逃がすという方針にしました。

クラウドはy、プロバイダーはminio。「Minio endpoint URL」は、とりあえず、「http://localhost:9000」としておきます。「ACCESS_KEY」「SECRET_KEY」も、後で設定する時にわかりやすいように「PLACE_HOLDER」で。

bucket nameはフォルダ名。S3などでは他人と被らないものを選ぶ必要があるそうですが、今回は1人しか使わないので任意の名前でよいそう。

アップロードしたファイルをあなたのドメインから見れるようにしますか？　的なこと訊かれました。yで。アップロードファイルのドメインは、media.amemiya.workにしました。

 メールサーバーの設定

続いて、多分、マストドンを構築する上で結構ネックになってそうなやつ。メールサーバーの構築です。

ただ、私の場合、今回ので自分のメールアドレスを持つ必要は別段無いかなぁと思ってるので、既存のサービスを活用します。

標準だと、Mailgunを使うことが想定されているようです。とりあえず、この日はMailgunでも無料ユーザーならクレカ無しでイケるのではという感じで設定をしました。

で、えっと、正直な話をすると、この辺りから色々混乱してます。設定間違えて手戻りが起きたり、予期せぬ問題が起きたり、あとなによりも、私の能力不足が大きいのですが。

色々と手戻りとかあるのですが、とりあえずやったことをそのままの順番で書きます。

とりあえず、最初、Mailgunを使うことにしました。

www.ritolab.com

Mailgunのユーザー登録を、「Add payment info now」にチェックを入れた状態で行います。「To send to anyone without restriction, add payment info now – it’s still FREE to sign up.」と出ますが、これは公告です。「Company Name」に「INDIVIDUAL」と入れます。「work E-mail」は、普段使ってるもの。

今回はSMTPサーバとしてしか使わないので、テスト送信は不要。ドメイン設定をやります。

お名前.com側の設定が微妙にわかりにくくて、詰まってしまいました。

設定画面こんな感じで、これ、TXTとかどこに入力するねんと思ったんです。TYPEをTXTにすりゃいいだけでした。

VALUEに「v=spf1 include:mailgun.org ~all」、ホスト名に「mx._domainkey.mail」、TYPEはTXTで、VALUEに「k=rsa;~~~~~~」をそれぞれ入力していきます。

Mailgunに戻って「Validate」をクリック。出てきた情報のうち、SMTP LoginとDefault Passwordをマストドンのウィザードに入れていきます。

この時、まだDNS確認が終わっていないので、MailgunのValidate画面にはUnverifiedと表示されています。

SMTPサーバー名はsmtp.mailgun.orgでそのまま。SMTPポートもそのまま。ユーザーネームやパスワードはMailgun上のDefault SMTP Loginの情報を使います。ここでパスワードの入力をミスった場合、テストメールを送る時に失敗してスタートに戻れます。SMTP authenticationはプレーンのまま。OpenSSL verify modeはnone。アドレスのfromの所に入る設定は、「Mastodon <no-reply@amemiya.work>」としました。

テストメール送りますかって出ますので、Yにします。設定が間違っていなければ、これでちゃんと送られるはず。

マストドンの方の設定の一覧みたいなのが出てて、「自分らで別途保存しといてや」って出てるはずです。メモ帳にコピペするなどして保存しましょう。自分で控えを作ったら、Yで設定保存。

で、続いてDBの設定に入るわけですが、ここでエラー。設定ファイルを保存した後で読み込み処理ができてない模様。

vim .env.productionで、さっきメモった設定で書き直していきます。

Compile the assets now? は、設定ファイルの読み込み失敗するのでnで。管理者作成もDBが存在しないのでnで。「全部完了しました」的なメッセージが出ますが、全然完了してません。

「ユーザーストレージを作りますか？」って出ますが、DBは後から作るのでnです。

「#」が付いている行は読んでくれないので、きちんと外します。

 minioの準備

で、そろそろminioの準備をします。今回はDockerに組み込みます。

sudo vim docker-compose.yml

上から4行目辺りに「db:」というのがあるので、その上に、

  minio:
    image: minio/minio
    restart: always
    command: server /data
    networks:
      - external_network
      - internal_network
    ports:
      - "127.0.0.1:9000:9000"
    volumes:
      - ./minio/data:/data

と入れます。minio:の前は半角空白2文字、image:とかは4文字、- internal_networkなどは6文字分です。ここがずれるとエラーになります。「networks:」の「- external_network」を飛ばしてしまうと、後で、mcにminioを覚えさせる際、ポート開放ができなくてエラーが出ます。

できたら、minioを入れるパーティションの準備をします。こちらの記事を参考にしますが、今回はvdbです。間違ってvdaとか打っちゃうと、せっかくセットアップしたUbuntuが吹き飛びます。

一応、合ってるかどうか、ls /dev/vd*と、sudo fdisk -l /dev/vdbで確認します。

vdbにパーティションを作り、ext4でフォーマット、それを/mntあたりにマウントします。ちなみに、sd*は物理マシンでのHDD、vd*は仮想マシンでのHDDを指します。今回はVPSを使ってますのでvd*です。

sudo apt install gdisk

sudo gdisk /dev/vdb

コマンドが求められるので「o」でエンター。「全部消すけどええんか？」って警告が出るのでy。またコマンドが求められるのでNewの「n」。Partition Number、First Sector、Last Sectorは全てソフト任せにするので全部空エンターで。HexCodeも空エンター。

コマンド画面に戻ったので、Printのpで現在書き込む予定のパーティションを確認。

これで書き込む準備が完了しましたので、WriteのwでHDDに書き込みます。警告が出ますがYで。完了したら、ls /dev/vd*を実行して、/dev/vdb1が存在することを確認します。

確認ができたら、パーティションをフォーマットし、マウント先（/mnt/storage）を作成します。

sudo mkfs.ext4 /dev/vdb1

sudo mkdir -p /mnt/storage

起動時に自動的にマウントさせます。

sudo vim /etc/fstab

一番下に、

/dev/vdb1 /mnt/storage ext4 defaults 0 0

を追記。これは、「/dev/vdb1を/mnt/storageにEXT4というフォーマットでdefaults（標準オプション）でマウントしてください」という意味だそう。

:wqで保存。できたらマウントします。

sudo mount /mnt/storage

エラーが発生しなかったらOK。確認のために以下の2つのコマンドを入れます。

mount
df -h 

mount実行結果の中に/dev/vdb1が居て、df -hの実行結果にも同じように存在しつつ、その横に空き容量などが出ていればOK。

大丈夫そうなら、マウントしたフォルダ内にminioフォルダを作って、Symlinkを作成します。

sudo mkdir /mnt/storage/minio

sudo ln -s /mnt/storage/minio ./minio

minioを起動します。

sudo docker-compose up minio

AccessKeyとSecretKeyの文字列をメモします。で、.env.productionへ戻ります（vim .env.production）。戻ったら、

S3_HOSTNAME=minio:9000
S3_ENDPOINT=http://minio:9000/

このように書き換えます。また、AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYも、さっきメモったものに書き換えます。

それぞれ2ヶ所ありますが、片方だけ有効化されてたらOKです。

これでminioの下準備ができたので、最後にS3_BUCKETのバケツ（オブジェクトストレージにおけるドライブ）を作ります。

まず、minioを操作するためにmcを用意します。

sudo curl -L https://dl.minio.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc
sudo chmod +x /usr/local/bin/mc

一時的にminioを起動させ、mcにminioを覚えさせます。

sudo docker-compose start minio

mc config host add media http://localhost:9000 [AWS_ACCESS_KEY_IDの文字列] [AWS_SECRET_ACCESS_KEYの文字列]

mc config ~~~と表示されたら、上手くいった証。

この辺りで、外が明るくなってきました（その節は、長時間に渡ってお付き合い戴き、ありがとうございました＞ikuradonさん）。

バケットの設定をします。

mc mb media/[さっき作ったBUCKET名]
mc policy download media/[さっき作ったBUCKET名]

BUCKET名を忘れてしまった場合は、.env.productionのS3_BUCKETを参照します。

エラーが無ければ終了。これで画像サーバーの準備もできました。

こんなに嬉々としてる内に夜が明けてしまったの、いつ振りでしょう。明るくなってますが、寝ます。

次回予告（

わくわくしながら各種設定を進める宮原。焦る気持ちからかとんでもない過ちを犯す。

壊れる権限。来ないメール。果たしてAmemiya.workは無事オープンできるのか？

次回、「Amemiya.workができるまで（後編）」、12月9日0時投稿予定。

なお、本日、S.H.さんの方のアドベントカレンダーでは、S.H.さんがTootGetterの紹介をされるそうです。マストドンのトゥートを集めて公開できるサービスだそうで。正直、今回初めて知ったので、勉強させて戴こうと思ってます。

明日、ぐすくまさんの方のアドベントカレンダーでは、localyouserさんが、ご自身のインスタンスを支える技術について記事をアップされるそうです。こちらも、興味がある方はぜひ。

*1:アドベントカレンダーでこんなことやっていいのかわかりませんが、分けてすらも1記事あたり1.5万字と、あまりに長すぎるので、苦肉の策としてご容赦ください……。

*2:コンビニへ車で行くという時点で、いかにド田舎に住んでるかがわかりますね。

*3:そういうトコやぞ

*4:SLコマンドの元ネタですね