目次
注意
経緯
本記事はLinuxについて「cdでディレクトリ移動できるらしい」くらいしか知らなかった初心者が恐れ多くも知る人ぞ知るおっさん幼女先輩とクソ映画大好きおじさん監視のもと、shimaidonとかいう簡易イキボタンのあるmastodon(何度見ても訳わからん)の運営に参加する為に、最低限のことを出来るようになるためしごかれた教えていただいた際、出された課題を解決するまでの経過をまとめたものである。
非常に勉強になったので同じようなことをしている人がもしいたらと思い公開することにしたが、前述の通りかなりの初心者なので間違いが多い可能性があることはご容赦願いたい。また、間違いがあった場合は指摘をいただけるとありがたい。
課題の内容
今回は以下の課題を出されたのでそれを解決する事を目的としていた。
- mastodonサーバをVM上に構築する
- CentOS7のminimal上に構築する
- パッケージマネージャの使用について制限を設ける
- 原則、更新系のものにおいては以下のもの以外使用を禁止する
yum groupinstall "Base"
yum groupinstall "Development Tools"
- 参照系のパッケージマネージャについては使用しても良い
- Dockerのインストールに際してとそれ以降については例外的に更新系のパッケージマネージャの使用を許可する
- webサーバはnginxを使用する
- サーバ監視を入れる
チェックポイント
上記課題に対して、以下のようなチェックポイントが課されていた
- サーバに外部から接続できること
- nginxが正常に動作していること
- dockerが正常に導入できていること
- docker-composeが正常に導入できていること
- mastodonのトップページがみれてトゥートできること
※外部ってのはインターネット介してでなくていい(サーバ上じゃないローカルネットワーク)
概要
というわけなので本記事はざっくりいうと
windows
上でVM
を立てて
- そこに
CentOS7 minimal
を立て
- インストールマネージャに制限のある中で
nginx
やdocker
をつかって
- 外部からアクセスできるような
mastodon
サーバを立てる
為に頑張ったといった内容になる。
環境
ホストOS
OS:Windows 7 Ultimate Service Pack 1
プロセッサ:Intel Core i7-4790 CPU @ 3.60GHz
実装メモリ: 16.0GB
システムの種類: 64ビット オペレーティングシステム
ゲストOS
今回はホストOS上にVMを立ててそこにサーバを構築する。VMを立てるのにはVirtualBox
を使用する。今回はVirtualBox グラフィカルユーザーインターフェース バージョン 5.2.6 r120293 (Qt5.6.2)
を使用した。
ゲストOSとしてはCentOS-7-x86_64-Minimal-1708.iso
をイメージとして使用してOSはCentOS7 Linux release 7.4.1708 (Core)
を用いた。
ターミナルソフト
sshのターミナルソフトとしてはRLogin Version 2.23.1(2018/01/30)
を使用した。
VM上にOSを立てる
VirtualBox公式のダウンロードページからWindows platform package
をダウンロードする
VirtualBox-5.2.6-120293-Win.exe
と言った感じの名前のファイルを実行して、インストーラに従ってインストールする。
インストールが終了したら起動する。
OSの入手
CentOS
のダウンロードページからMinimal ISO
を選択してダウンロードする。
名前とOS
上部メニューから「新規(N)」を選択し、好きな名前をつけ、「タイプ(T)」をLinux
に、「バージョン(V)」をRed Hat(64bit)
にして次へを押す。名前をCentOS
等にすると自動でタイプとバージョンは設定されるので基本それでいいはず。ここでは名前をCentOS7
にする。
同名で作成できない
同名の仮想マシンを作成しようとすると「仮想マシンのフォルダー{仮想マシン名}を親フォルダ{仮想マシンの置かれるフォルダ名。C:/Users/***/VirtualBox VMs
とか}に作成できません。 このフォルダーは既に存在し、ほかマシンに属している可能性があります」と出る。もし元の仮想マシンが既に必要ないなら、そこでVirtualBox上で「右クリック->除去」から「すべてのファイルを削除」すると新しく同名の仮想マシンを作成できるようになる。
ここでは余裕を持って8192MB
メモリとする。
ハードディスク
「仮想ハードディスクを作成する」を選択して「作成」を押す。
ハードディスクのファイルタイプ
書いてある通り、他の仮想ソフトウェアで使用する必要がなければ設定はVDI(VirtualBox Disk Image)
のままにして「次へ」を押す。
物理ハードディスクにあるストレージ
「可変サイズ」を選択して「次へ」を押す。
ファイルの場所とサイズ
名前はそのままでVM名とおなじになっていると思うのでそのままでいい。仮想ハードディスクは「20.00GB」にして「作成」を押すと、VMが作成される。
起動する
作成したVMをダブルクリックもしくは上部メニューの起動から起動する。「開始したい新しい仮想マシンを含むディスクのある、仮想高額ディスクか、ディスクが挿入されている物理光学ドライブを選択してください。 このディスクはコンピューターを起動することができ、仮想マシンにインストールしたいオペレーティングシステムを含んでいなければなりません。このディスクは仮想マシンをオフにした次の回に自動的に取り出されますが、必要であればデバイスメニューから取り出すこともできます」と出ていたらここでCentOS7のシステムイメージを設定する。CentOS-7-x86_64-Minimal-1708.iso
と言った感じのもの。そうしたら「起動」を押してOSのインストールに進む
Test this media & Install CentOS7
を選択すると色々走った後にGUIが起動する。
言語は「日本語」を選択して次へ進む。
「システム」の「インストール先」を設定しないとインストールを開始できないが、クリックして設定画面に入ったら何もせず「完了」を押して元の画面に戻れば自動パーティションに自動で設定されるので「インストールの開始」を押して次に進む。
インストールしてるうちにrootパスワードとユーザを作成しておく。そうしたら「設定終了」を押す。
再起動しろと言われるのでそれに從う。
これでインストールは終了。
ネットにつなげる
ネットに繋がらない
$ nmcli device
でネットワークインターフェースを確認する(参考)と、
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet disconnected --
と表示されたら接続されていない。
# nmcli c mod enp0s3 connection.autoconnect yes
再起動
インターネットへの自動接続設定をしたなら、設定を反映させるためにネットワークデーモンを再起動する
$ service network restart
つながったか確認
$ nmcli device
を実行して
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet connected enp0s3
となっていたらOK。
wikipediaによると
Security-Enhanced Linux (SELinux) は、アメリカ国家安全保障局 (NSA) がGPL下で提供しているLinuxのカーネルに強制アクセス制御 (MAC) 機能を付加するモジュールの名称。
こいつが有効になっているとその強力なアクセス制限のせいで作業中に躓く事があるので切っておく。
有効無効を確認する
参考:SELinuxを無効化する
SELinuxが有効かを確認する
$ getenforce
を実行する。表示される内容によって現在の状態がわかる。
表示される内容 |
意味 |
enforcing |
SELinux機能、アクセス制御が有効 |
permissive |
SElinuxは警告を出力するが、アクセス制限は無効 |
disabled |
SElinux機能、アクセス制御が無効 |
永続的に無効にする
今回は永続的に無効にすることを考える。SELinuxの設定ファイルは/etc/selinux/config
なので、
# vi /etc/selinux/config
でこれを開き、
SELINUX=enforcing
とある行を
SELINUX=disabled
と書き換える。設定を反映させるためにreboot
コマンド等で再起動する。
sudoを使えるようにする
sudoとは?
sudo
コマンドは他のユーザや他のグループの権限でコマンドを実行できるコマンド。特に指定せず実行した場合、スーパーユーザとして実行したことになる。
スーパーユーザとしてコマンドを実行したい場合、ユーザを変更出来るsu
コマンドで一旦スーパーユーザになってから実行するという方法があるが、コマンド実行後また元のユーザに戻らなければならないのは煩雑だし、かといってスーパーユーザで作業をするのは危険だし…という問題があるが、こういう場合はsudo
を使うと良い。
sudoがデフォルトで許可されているユーザグループに属す
CentOS
ではデフォルトでsudo
できるグループとしてwheel
グループが用意されているため、追加した一般ユーザーをwheel
グループに追加し、sudo
できるようにする。余談だが、Debian
の場合は、sudo
グループがデフォルトでsudo
出来るグループとして用意されている(出典)。
# usermod -aG wheel {ユーザー名}
でサブグループを追加する。
アカウントが既にサブグループに入っているかわからなければid
コマンドで
$ id {ユーザ名}
とすれば確認できる。
クライアントからのssh接続での操作ができる環境を作る
参考:
- Linux(CentOS7)でSSHを利用する。
- CentOS7.3でSSH接続(パスワード認証)する方法
前提
VM上からだと何かと使い勝手が悪いのでsshクライアント(ここではRLogin)を使ってゲストOSであるCentOSにアクセスするようにする。
SSHサーバーはプリインストールされているのでその先をやる。
/etc/ssh/sshd_config
を開いて
変更箇所 |
変更後 |
#PermitRootLogin yes |
PermitRootLogin no |
#PasswordAuthentication yes |
PasswordAuthentication yes |
#PermitEmptyPasswords no |
PermitEmptyPasswords no |
と書き換え保存して終了する。
サービスの起動
以下のコマンドを実行してSSHのサービスを起動する
# systemctl start sshd.service
実行したら以下のコマンドでサービスが起動できているか確認する
# systemctl status sshd.service
緑の字でactive (runnning)
と表示されていたらSSHのサービスが起動している。
SSH用のポート(22
番ポート)はMinimal ISO
でも元から開放されているので、設定は不要。
もし開放されていなかったとしても、CentOS7ではsshd
と同様firewalld
もsystemd
で管理されているので
# systemctl stop firewalld.service
とすれば停止して取り敢えず接続確認は出来る。
一般ユーザの作成
先ほどrootユーザーによるリモートログインを禁止したので、リモートログインするための一般ユーザを準備する。とはいえ、既にリモートログインしたいユーザがあるのであればわざわざ追加する必要はない。
以下、一般ユーザが準備できていない場合について書く。
一般ユーザーを追加する
# useradd {ユーザー名}
追加した一般ユーザーにパスワードを設定する。
# passwd {ユーザー名}
New password:
Retype new password:
でパスワードを2回入力したら、パスワードの設定は完了。
$ ip a show enp0s3
IPアドレスをメモしておく
クライアント側の設定
ターミナルソフトはRLoginを使う
ホストOS(Windows)で、Windows
+R
を押して出てきたウィンドウにcmd
と入力してEnter
を押してコマンドプロンプトを起動したら、ipconfig
コマンドを実行する。
「イーサネット アダプター ローカル エリア接続
」みたいに書いてあるところの「IPv4 アドレス
」をメモする。
参考:ローカルPCとVirtual Boxの仮想マシンとのネットワーク接続、どうなってる?
NATやポートフォーワードの設定をしないとゲストOSにはアクセスできないのでそれをやる。
環境設定
- ウィンドウ上部タブの「
ファイル->環境設定
」をクリックし、でてきたウィンドウの左カラムから「ネットワーク
」をクリックする。
- 右カラムに、上に「
NATネットワーク
」と書かれた空のボックスがあるのでその右にある「+
」のついたマーク(マウスオーバーすると、「新しいNATネットワークを追加します。
」と出るところ)をクリックする。
- 空だったボックス内に新たに「
NatNetwork
」という名前のネットワークが作成されるので、それをダブルクリック、もしくは選択した状態で右の歯車の付いたマークをクリックして、編集(NATネットワーク詳細)ウィンドウを開く。
- 「
ネットワーク名(N):
」を好みのものに変え(今回は変更しない)、下にある「ポートフォワーディング(P)
」と書かれたボタンをクリックする。
- また空のボックスの表示されたウィンドウが開く。上部タブの「
IPv4
」が選択されている事を確認し、右の「+
」のついたマークをクリックする。
そうすると空のボックス内に「Rule 1
」という新しいルールが追加されるので、
項目名 |
値 |
名前 |
わかり易い名前に任意に決める。ここでは「sshRule 」 |
プロトコル |
TCP のままにしておく |
ホストIP |
ホストOS(Windows)のコマンドプロンプトでipconfig コマンドを使って確認したアドレスを指定。今回は「192.168.2.100 」 |
ホストポート |
ウェルノウンポート(0~1023)を避けて指定する今回は「2022 」にした |
ゲストIP |
ゲストOS(CentOS)でip a show コマンドを実行して確認したアドレスを指定。今回は「10.0.2.15 」にした |
ゲストポート |
「22 」を指定 |
としたらOKを押して「環境設定」は終了。
- 接続したい仮想マシンを選択し、上にある「
設定(S)
」をクリックするか、右クリックメニューから「設定(S)
」を選択するとウィンドウが開くので、左カラムから「ネットワーク
」をクリックする。
- 右カラムのタブが「
アダプター1
」になっているのを確認したら、「割り当て(A):
」を「NATネットワーク
」にする。そうすると下に「名前(N):
」という項目が操作可能になるので、ここでさっき作成した「NatNetwork
」を指定する。
OKを押したらこれでVM側の設定は終了なので、ターミナルソフト側の設定に移る。
ターミナルソフト(RLogin)の設定
左上の電源プラグの様なマークの「サーバー接続
」をクリックすると「Server Select
」ウィンドウが開くので、右のボタンから「新規(N)
」をクリックする。そうするとサーバーエントリーを設定するウィンドウが開くので
|項目名|値|
|:--|:--|
|エントリー(上段)|任意の名前。今回はVM_CentOS7
とした。|
|プロトコル|ssh
を選択|
|Server Address|ホストIPを入力。今回は「192.162.2.100
」を入力|
|Socket Port|VMでホストポートとして指定したポートを入力。今回は「2022
」|
|User Name|ユーザ名を入力。今回はinaenomaki
|
|Password/Phrase|ユーザのパスワードを入力|
|Term|xterm
を指定|
|デフォルト文字セット|UTF-8
を指定|
残りは空欄もしくはチェックは外しておく。
これで設定は完了。
英語に直す
ここを参考に
# localectl set-locale LANG=en_US.UTF-8
として再起動する。
[inaenomaki@localhost ~]$ localectl status
System Locale: LANG=en_US.UTF-8
VC Keymap: jp
X11 Layout: jp
と英語になっている。
前準備
許可されているパッケージマネージャ
# yum groupinstall "Base"
# yum groupinstall "Development Tools"
を実行する
以下は
/home/inaenomaki
下で行った
Webサーバーを立てる
nginxに必要なものを予め用意しておく
nginxとは
「nginx(えんじんえっくす)とは、ロシア人のIgor Sysoe氏によって作られたメモリ使用量の少ない高速なオープンソースのWebサーバー」だ(出典)。今回はこれを使う。
PCREの用意
ダウンロード
$ wget http://sourceforge.net/projects/pcre/files/pcre/8.36/pcre-8.36.tar.gz
展開
$ tar xvzf pcre-8.36.tar.gz
zlibの用意
ダウンロード
$ wget http://zlib.net/zlib-1.2.11.tar.gz
展開
$ tar xvzf zlib-1.2.11.tar.gz
nginxの用意
ダウンロード
$ wget http://nginx.org/download/nginx-1.7.7.tar.gz
展開
$ tar xvzf nginx-1.7.7.tar.gz
nginxのインストール
構成としては
- ~(/home/inaenomaki)
- nginx-1.7.7(nginxのソースディレクトリ)
- pcre-8.36(pcreのソースディレクトリ)
- zlib-1.2.11(zlibのソースディレクトリ)
となっているので、
$ cd ~/nginx-1.7.7/
してひとつ下のディレクトリに入った後
$ ./configure --prefix=/usr/local/lib/nginx-1.7.7 --with-pcre=../pcre-8.36 --with-zlib=../zlib-1.2.11
としてソースディレクトリを指定する。
make
$ make
make install
$ sudo make install
実行ファイルのパスを通す
/usr/local/bin/
がスーパユーザ・一般ユーザ共にパスが通っているので
$ sudo ln -s /usr/local/lib/nginx-1.7.7/sbin/nginx /usr/local/bin/
としてnginxの実行ファイルへのシンボリックリンクを貼る
sudo時にもパスが通るようにする
visudo
でsudoers
を開き、
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/lib/nginx-1.7.7/sbin/
こうしてsudoers
を保存してless
でちゃんと変更されていることを確認する。
sudo
で実行してみると
[inaenomaki@localhost ~]$ sudo nginx -v
[sudo] password for inaenomaki:
nginx version: nginx/1.7.7
ちゃんとsudo
でも実行できるようになった。
nginxをサービス化する
定義ファイルを作成する
公式サイトの提供している定義ファイルを少し変えて使う(参考)。
/etc/systemd/system
に定義ファイルを置く。
$ sudo vi /etc/systemd/system/nginx.service
として
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/usr/local/lib/nginx-1.7.7/logs/nginx.pid
ExecStartPre=/usr/local/lib/nginx-1.7.7/sbin/nginx -t
ExecStart=/usr/local/lib/nginx-1.7.7/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target
とする。
Unitがサービスとして認識されたか確認する
$ sudo systemctl list-unit-files --type=service | grep nginx
nginx.service
が表示されていれば認識されている。
サービスを有効化する
$ sudo systemctl enable nginx
実行すると
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /etc/systemd/system/nginx.service.
と出てシンボリックが作成される。
サービスを有効化出来たか確認する
$ sudo systemctl list-unit-files --type=service | grep nginx
nginxを起動する
$ sudo systemctl start nginx
起動できたか確認する
$ sudo systemctl status nginx
Active: active (running)
となっていれば大丈夫。
ポートフォワーディングを設定する
VM上ではnginxは起動したように見えるので、きちんとそこに接続できるか試す。本来ならnginxの起動しているPCのアドレスにアクセスすればそれで済むのだが、今回はゲストOS上でnginxを動かしていて、ホストOSのブラウザからnginxにアクセスして接続できるか・正常に動いているかを確認したいので、ssh接続の時と同じくポートフォーワーディングを設定する。
前回と同じく、ファイル->環境設定
から開いたウィンドウの左カラムでネットワーク
を選択し、右カラムでssh接続する時に作ったNatNetwork
をダブルクリックもしくは選択してOKを押す。またウィンドウが開いたらポートフォーワード
をクリックして更にウィンドウを開き、IPv4
タブになっているのを確認したら、右のプラスマークの新規ポートフォワーディングルールを追加します。
からルールを追加し、
項目名 |
値 |
名前 |
ルールの名前。ここではhttpRule とした |
プロトコル |
TCP |
ホストIP |
ホストOSのIPアドレス。ここでは192.168.2.100 |
ホストポート |
ポートフォワーディングするホストOSのポート。ここでは8888 とした |
ゲストIP |
ゲストOSのIPアドレス。ここでは10.0.2.15 |
ゲストポート |
ゲストOSの転送先のポート。http接続をするつもりなので80 を指定 |
としたらOKを押して閉じる。(参考:外部からVirtualBox内のサーバにアクセス)
ポート開放する
デフォルトだとfirewalldがアクセスさせてくれないのでTCPの80番ポートを開ける。
$ sudo firewall-cmd --zone=public --add-service=http --permanent
として恒久的に開く設定にし、
$ sudo firewall-cmd --reload
で設定を反映する
$ sudo firewall-cmd --list-all
でservices
にhttp
が追加されていれば大丈夫。
接続できるか確認する
ブラウザ上からhttp://192.168.2.100:8888/
と指定してアクセスする
Welcome to nginx!
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.
Thank you for using nginx.
と出れば上手くいっている。
PC内からアクセス確認したいのであれば
$ curl localhost:80
とすればいい。
Dockerの導入
Dockerとは?
Wikipediaによると
Docker(ドッカー)はコンテナ型の仮想化環境を提供するオープンソースソフトウェアである。
雑に読んだ感じ、物理的に1つのサーバ上に、無駄を少なく複数のアプリケーションを走らせたいという要請から考えられた概念がコンテナ型の仮想化であり、これを提供するソフトウェアがDocker
という感じ。
今回はMastdonをコンテナとして扱う事を目指すのでこれを使う
古いバージョンの確認
古いバージョンのdockerが入っているとうまくいかないことがあるらしいので入っていない事を確認する。
$ yum list installed | grep docker
として何も表示されなければ問題ない。
厳密にやりたいのであれば
$ yum list installed | egrep 'docker(|-(client(|-latest)|common|latest(|-logrotate)|logrotate|selinux|engine(|-selinux)))'
とする。(-E
オプションは拡張正規表現の使用参考)
必要なパッケージのインストール
$ sudo yum install -y yum-utils device-mapper-persistent-data lvm2
をして必要なパッケージをインストールする
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
を実行してリポジトリを追加する。
無事/etc/yum.repos.d/docker-ce.repo
にリポジトリが保存されれば成功。
$ sudo yum makecache fast
ここではyum
リポジトリが最新である事を確認して更新している。
Docker CEのインストール
リポジトリ(/etc/yum.repos.d/docker-ce.repo
)の設定も終わったので、インストールをする。
$ sudo yum install docker-ce
Dockerを起動する
$ sudo systemctl start docker.service
としてDockerを起動する。
Active: active (running)
となっていれば
正しくインストールされているか確認する
docker
が正しくインストールされているのを確認するため、hello-world
イメージを実行する。
$ sudo docker run hello-world
上手く行けば良い感じのメッセージが表示される。
Docker Composeの導入
参考:
- 複数のDockerコンテナを自動で立ち上げる構成管理ツール「Docker Compose」(Dockerの最新機能を使ってみよう:第7回)
- docker-composeを使うと複数コンテナの管理が便利に
- Docker Compose
- Docker Compose のインストール
公式でも必要としているのでDocker Compose
を入れる。
Docker Composeって?
複数のコンテナを使うDocker
アプリケーションを定義・実行するためのツール(参考)で、コマンドを1つ実行するだけで、設定した全てのサービスを作成・起動する事ができる(参考)
設定された依存関係に応じて適切な順番でコンテナが起動されるようになっており、コマンド1つで簡単に必要なサービスを開始できたり、逆にコンテナを停止させる際も、自動的に適切な順番でコンテナを停止させるようになっている。
Docker Composeのダウンロード
GitHub上にあるComposeリポジトリのリリース・ページに移動し、指示に従いcurl
コマンドを実行する。
$ sudo curl -L https://github.com/docker/compose/releases/download/1.20.0-rc2/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
としたらうまくいった。
権限の追加
参考:パーミッションなどを設定する!chmodコマンドの詳細まとめ【Linuxコマンド集】
$sudo chmod +x /usr/local/bin/docker-compose
sudo時にもパスが通るようにする
docker-compose
は/usr/local/bin
にあるので一般ユーザにはパスは通っているが、sudo
時のパスは通っていないので通す。visudo
でsudoers
を開き、
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/lib/nginx-1.7.7/sbin/:/usr/local/bin/
とする。
動いていることを確認
$ docker-compose --version
と
$ sudo docker-compose --version
として、バージョンが表示されれば大丈夫
Mastdonを導入する
前提
これからダウンロードするMastdonプロジェクトには、Dockerfile
とdocker-compose.yml
が含まれていて、これはDocker Compose
の少なくともバージョン1.10.0
で必要とされる。これらの関係については、Dockerで雑にMastodonを起動する方法にわかりやすい図があるので良さげ。以下その図
入れるバージョン
最新版Mastodonはローカルに立てるのは非常に面倒くさい。よってここではMastodonのv2.0.0
を入れる。
参考
v2.0.0の最新コミットは2017/10/19
だったので、最新版ではなく2017/10/27
にコミットされた際の過去のDocker-Guideを参考に
v2.0.0をclone
cloneする。
$ git clone -b v2.0.0 https://github.com/tootsuite/mastodon mastodon_v2
移動
$ cd mastodon_v2/
以下特に断りが無ければここで作業
checkout
cloneの際にメッセージが出ていたのでcheckout(参考)
$ git checkout refs/tags/v2.0.0
設定ファイルのコピー
$ cp .env.production.sample .env.production
設定ファイルを変更する
.env.production
のLOCAL_HTTPS
をfalse
にする。ついでにLOCAL_DOMAIN
をsaigoudon.net
にする
# Federation
# Note: Changing LOCAL_DOMAIN or LOCAL_HTTPS at a later time will cause unwanted side effects.
# LOCAL_DOMAIN should *NOT* contain the protocol part of the domain e.g https://example.com.
LOCAL_DOMAIN=saigoudon.net
LOCAL_HTTPS=false
こうなったら大丈夫。
docker-compose.ymlの変更
docker-compose.yml
の
image: gargron/mastodon
となっている所を
image: gargron/mastodon:v2.0.0
としておいた。ここについてはcloneしてくるバージョンを指定するだけでいいのかこれも必須なのか要確認。
今更だがlog保存用ディレクトリを作って、以降ここにlogを残しておく。
$ mkdir mylogs
| tee mylogs/docker-compose_build.log
を後ろにつけてlog保存用ディレクトリにも結果を残す。tee
コマンドは、標準入力で受け取ったものを、標準出力と指定された出力先にそれぞれ出力するコマンド。
イメージのビルド
$ sudo docker-compose build | tee mylogs/docker-compose_build.log
secretsの生成と設定
以下を三回実行してそれぞれ生成されたsecret
を何処かにメモしておく
$ sudo docker-compose run --rm web rake secret
その後
$ sudo vi .env.production
して.env.production
を開き、
# Application secrets
# Generate each with the `RAILS_ENV=production bundle exec rake secret` task (`docker-compose run --rm web rake secret` if you use docker compose)
PAPERCLIP_SECRET=f3fa3a(略)a220c7f
SECRET_KEY_BASE=96304(略)e848323
OTP_SECRET=1933c7(略)79b21e5
と
PAPERCLIP_SECRET
SECRET_KEY_BASE
OTP_SECRET
のそれぞれ=
の右に入力した。
VAPID_keysの生成と設定
今度は
$ docker-compose run --rm web rake mastodon:webpush:generate_vapid_key
を実行してVAPID_PRIVATE_KEY=
の右側とVAPID_PUBLIC_KEY=
の右側をメモしておき、.env.production
の
VAPID_PRIVATE_KEY
VAPID_PUBLIC_KEY
にそれぞれ書き込む
# VAPID keys (used for push notifications
# You can generate the keys using the following command (first is the private key, second is the public one)
# You should only generate this once per instance. If you later decide to change it, all push subscription will
# be invalidated, requiring the users to access the website again to resubscribe.
#
# Generate with `RAILS_ENV=production bundle exec rake mastodon:webpush:generate_vapid_key` task (`docker-compose run --rm web rake mastodon:webpush:generate_vapid_key` if you use docker compose)
#
# For more information visit https://rossta.net/blog/using-the-web-push-api-with-vapid.html
VAPID_PRIVATE_KEY=VBOB(略)qX_l1NgSLA=
VAPID_PUBLIC_KEY=BHLWTwr9MW_QE74n8_b(略)C8g=
データベースの作成
$ sudo docker-compose run --rm web rake db:migrate
うまくいかない時は
バージョンは違うが、v2.3.0のリリースノートもしくはその日本語訳を見ると、
Troubleshooting
If you are using Docker with docker-compose and are getting a PG::ConnectionBad: could not translate host name "db" to address: Name does not resolve, you might have to do docker-compose down (make sure you were using volumes so you won't lose data!) before you can run any further docker-compose commands.
「トラブルシューティング
Dockerでdocker-composerを使用し、PG::ConnectionBad: could not translate host name "db" to address: Name does not resolve
が出る場合、docker-compose
コマンドを走らせる前に、docker-compose down
(Volumesを使用し、データを失わないようにしてください!)を実行する必要があるかもしれません」
とある。
$ sudo docker-compose run --rm web rake assets:precompile | tee mylogs/asetts_precompile.log
起動
$ sudo docker-compose up -d
errorが出てうまくいかない時は
別にmastodonを構築しようとしていたなら、それが邪魔をしている可能性があるのでそれらをdocker-compose down
する。
状態の確認
$ sudo /usr/local/bin/docker-compose ps
動いていれば全てのState
がUp
になっているはず。
接続テスト
ポートフォワードのmastodonRule
はホストポート3333
、ゲストポート3000
にした。
Chromeからhttp://192.168.1.3:3333/
に接続する。
内部から接続すると
[inaenomaki@localhost mastodon_v2]$ curl localhost:3000
<html><body>You are being <a href="http://localhost:3000/about">redirected</a>.</body></html>
起動までに時間がかかることもあるので注意。
起動したかを確認するのには、docker-compose logsの
$ sudo docker-compose logs -f
として起動したことを確認すると良い。
こうして、無事立てることに成功した。
Mackerelでmastodonサーバを監視する
参考:Mackerelをはじめる
Mackerelとは?
Mackerelは複数のサーバーのリソース状況やサービスのパフォーマンスを可視化、監視するためのサービスのこと。
Mackerelでは、mackerel-agent
と呼ばれるプログラムをサーバーにインストールすることでホストを登録する。協調してはたらくホストをまとめる『サービス』、サービス内のホストの役割である『ロール』によってホストを管理し、エージェントが収集したホストの状況をウェブ上で視覚的に確認できる
またMackerelでは、ユーザはオーガニゼーション(団体、組織)に所属し、複数人で共同で管理を行うことができる。
オーガニゼーションの作成
ページ左上あたりからオーガニゼーションの作成をする。
ここではmylocal-mastodon
という名前でオーガニゼーションを作成した。
プランはTrial
にしたが、Free
でもよさそう。(要確認)
オーガニゼーションのトップページのinstruction
によると、
1. 最初のオーガニゼーションを作成
{自分の登録メールアドレス}さんが所属するひとつめのオーガニゼーションをつくります。
2. 新規ホストを登録する
Mackerelにホストを登録するには、登録したいホストにmackerel-agentをインストールする必要があります。
3. サービスをつくってみましょう
Mackerelでは、協調してはたらくホスト群をまとめる『サービス』と、
サービス内の役割である『ロール』を使ってホストを管理します。
サービスをつくることで、複数台のホストの状態を一画面で素早く確認できるようになります。
4. ロールをつくる
エージェントをインストールしたホストを実際にサービスの一員として認識させるためには、
ホストのサービスにおける役割である『ロール』が必要です。
サービスのページから新しいロールを作成できます。
5. ホストにロールを紐付ける
作成したロールにホストをひもづけてみましょう。
ホストの一覧から、ロールを設定してください。あるいは、各ホストの設定画面から紐付けることもできます。
おめでとうございます!
ここまでの操作で基本的なMackerelにおけるリソース監視ができるようになりました。
ここからは、もう一歩進んだ使い方を紹介します。
ホストやサービスなどの監視をする
監視対象がどのような条件を満たした時に異常な状態であるかを決める監視ルールを設定できます。
監視ルールの条件をもとに発生したアラートはアラート一覧画面から確認できます。
アラートの通知先を振り分ける
発生したアラートの通知先を特定のサービスや監視ルールごとに自由に分類・設定できます。
プロジェクトチームや職種別チームなど、組織の開発スタイルに合わせた通知先の運用に便利です。
共同管理者を招待する
Mackerelでは、オーガニゼーションごとに共同の管理者を指定・招待できます。
オーガニゼーションの詳細ページから招待メールを送信してください。
という手順で進んでいくのでこれに從う。
新規ホストの登録
「新規ホストの登録」を押すと、使用OSを聞かれるのでCentOS/RedHat
を選択してプルダウンメニューに書いてある
$ curl -fsSL https://mackerel.io/file/script/setup-all-yum-v2.sh | MACKEREL_APIKEY='(略)' sh
を実行する。
動作の確認がしたければ
$ sudo journalctl -u mackerel-agent.service
とする。
サービスを作る
「新しいサービスを作成」からサービスを作る。ここではサービス名はmastodon
にした。
ロールを作る
「新規ロールを作成する」からロールを作る。ここではロール名はweb
にした。
ホストにロールを紐つける
左カラムの「Hosts」を選択するとホスト一覧が表示されるが、さっき追加したホストの「サービス/ロール」の所に「ロールを設定」ボタンがあるのでこれを押す。そうしたらさっき作ったロール(mastodon: web
)が表示されるので選択して「更新」を押す。
dockerのメトリクスをとれるようにする
参考:Dockerをモニタリングする
エージェントが基本的なメトリクスについてはとるようにするので、dockerのメトリクスを設定して取れるようにする。
Dockerコンテナの消費リソースを把握するには、Dockerが利用しているリソースの統計情報を参照する。Dockerのリソースの統計情報はAPIを利用して取得する。技術的な詳細は公式ドキュメントを参照のこと。
Mackerelではmackerel-plugin-docker
を利用することで、各コンテナのリソース消費の統計情報を取得しカスタムメトリックグラフとして可視化することができる。 mackerel-plugin-docker
は公式プラグイン集に含まれてるので、まずは公式プラグイン集をインストールする。
参考ミドルウェアのメトリック可視化に公式プラグイン集を使う
$ sudo yum install mackerel-agent-plugins
でインストールする。
[inaenomaki@localhost ~]$ sudo yum install mackerel-agent-plugins
[sudo] password for inaenomaki:
Loaded plugins: fastestmirror, langpacks
(略)
Installed:
mackerel-agent-plugins.x86_64 0:0.46.0-1.el7.centos
Complete!
となったら成功。
各プラグインは/usr/bin
にインストールされているので、mackerel-agent
の設定ファイルに、利用するプラグインに合わせて以下のような設定を追加する。設定の反映には、mackerel-agent
の再起動が必要となる。
設定の追加
プラグイン集がインストール出来たら、以下の設定を/etc/mackerel-agent/mackerel-agent.conf
に追記する。
[plugin.metrics.docker]
command = "mackerel-plugin-docker -name-format name"
これにより、そのホスト上で動作するDockerコンテナのCPU使用率、メモリ消費量、IO使用量(IOPS、転送バイト数とキュー長)が可視化される。
設定の反映には、mackerel-agent
の再起動が必要なので再起動する。
$ systemctl restart mackerel-agent.service
これでHostsのカスタムメトリックにDockerのメトリックが表示されるようになる。
ログ監視を行う
参考:ログ監視をおこなう
目標
/var/log/messages
にerror
という文字列が出力されたかどうかを監視したい。
公式チェックプラグイン集のインストール
参考:チェック監視に公式チェックプラグイン集を使う
$ sudo yum install mackerel-check-plugins
を実行する。
[inaenomaki@localhost etc]$ sudo yum install mackerel-check-plugins
[sudo] password for inaenomaki:
Loaded plugins: fastestmirror, langpacks
(略)
Installed:
mackerel-check-plugins.x86_64 0:0.18.0-1.el7.centos
Complete!
とでたら成功
check-logを使う
check-log
を使ってログ監視を行う。特定ファイルの特定文字列の出現について検出したい場合、/etc/mackerel-agent/mackerel-agent.conf
を開き、
[plugin.checks.access_log]
command = "check-log --file {監視したいファイル名} --pattern {検出したい文字列}"
と追記する。つまり、--file
オプションに監視対象のファイルを、--pattern
オプションに、エラー文言を検出したいパターンを正規表現で指定する。
今回は/var/log/messages
にerror
という文字列が出力されたかどうかを監視したいので、/etc/mackerel-agent/mackerel-agent.conf
を開き
[plugin.checks.access_log]
command = "check-log --file /var/log/messages --pattern error"
と追記する。
設定の反映には、mackerel-agent
の再起動が必要なので再起動する。
$ systemctl restart mackerel-agent.service
ログ監視が無事追加されていれば「Hosts」で「Host」を選んだ時の右の「Monitors」に
access_log
LOG OK: 0 warnings, 0 criticals for pattern /error/.
と表示される。
Monitorsの方から見ても見えないのが何故かわかっていないので要確認。
アラートが自動クローズされないようにする
追加したログ監視について、アラートがでた時に自動でクローズしないようにしたい。
そのためには/etc/mackerel-agent/mackerel-agent.conf
のログ監視の項目にprevent_alert_auto_close
のオプションを追加するといい(参考1,参考2)。
よって、
[plugin.checks.access_log]
command = "check-log --file /var/log/messages --pattern error"
prevent_alert_auto_close = true
とさっき編集したところをprevent_alert_auto_close = true
を追加する形で書き換える。
設定を反映させるためにmackerel-agent
を再起動する。
[inaenomaki@localhost log]$ systemctl restart mackerel-agent.service
これでアラートが自動クローズされなくなった。