VPS を式年遷宮する その5 超A&G+の録画環境構築
概要
文化放送のインターネットラジオである 超A&G+ (以下AGQR) にてリアルタイム配信されている番組を自動録画する環境を構築した。
先人が公開しているソースコードを Fork し、自身の環境や使い勝手に合わせて改変した。
その際の作業内容を記述する。
構築する目的
AGQR にはタイムシフトなどの機能は存在せず基本的にリアルタイム視聴のみなので、 後日好きなタイミングで再生が出来るようサーバ上で録画出来る環境が欲しかった。
環境
サーバ
ローカル
- macOS 10.15.6 Catalina
- iTerm2
AGQR 録画の OSS 紹介
AGQR の録音ツールは先人が OSS として公開している物が存在しているので、その中で気になった物を下記に示します。
ybenjo/agqr.rb
https://gist.github.com/ybenjo/9904543
Ruby 製の OSS で、同じディレクトリに設置した schedule.yaml
から録画リストを読み込んで実行する。
今回は このリポジトリを Fork させていただきました。
ushironoko/a-Go
github.com
Golang で実装された OSS。
バイナリが配布されているので、RTMPDump
導入済みの環境で直ぐに利用出来る。
自動録画にはタスクスケジューラや crontab
等が必要。
Fork したコードについて
Fork 先リポジトリは下記リンクを参照。
Fork 元との差分は下記の通り。
- 各パッケージのパスを自環境に合わせて変更
- 音声ファイルの保存先を実行ファイルと同じディレクトリに変更
/flv
/m4a
ディレクトリが作成できるよう修正- 配信 URL を現行の物に修正
- 音声ファイルの出力フォーマットを
mp3
からm4a
へ変更
配信 URL は不定期に変更されるため結構曲者です。
AGQR の録音環境を構築する際には URL が接続可能か確認しましょう。
作業手順
必要パッケージ導入
スクリプト実行に必要なパッケージを導入します。
私の環境では前回の Radiko 録音環境構築時に導入済みでした。
$ sudo apt install rtmpdump $ sudo apt install ffmpeg
Ruby 導入
サーバに Ruby を導入していなかったので、下記記事を参考に rbenv
をインストールして環境構築しました。
スクリプト設置と実行
スクリプトを設置するディレクトリ /agqr
を作成し、スクリプトをGist から Clone します。
$ mkdir agqr $ cd agqr $ git clone https://gist.github.com/y4shiro/8f3093c7db7b34e0e83b525979fbe0ec .
crontab
に下記のタスクを追加しました。
毎時 29/59 分に agqr.rb
を実行し、schedule.yaml
に放送直前の番組が存在する場合は録画を開始します。
初回実行時にはデータ保存用のディレクトリ data/flv
/ data/m4a
が作成されます。
29,59 * * * * sleep 55; /home/<username>/.rbenv/shims/ruby /home/<username>/agqr/agqr.rb
私が実際に運用している schedule.yaml
の一部を例に示します。
ファイル名 / 曜日 / 時刻 / 番組の長さ(分) を記述してください。
- title: hidakakuma wday: 火 time: '23:00' length: 30 - title: toshitai wday: 火 time: '23:30' length: 30
感想など
AGQR の配信 URL は不定期に変更されるので、URL の変更検知を行う仕組みが必要だと感じた。
今回の作業で録音周りは一通り移行し終えたので、次はドメインや証明書関連に着手する予定です。
VPS を式年遷宮する その4 Radiko の録音環境構築
概要
Radiko にてリアルタイム配信されている番組を自動録音する環境を構築した。
先人が公開しているソースコードを Fork し、自身の環境や使い勝手に合わせて改変した。
その際の作業内容を記述する。
構築する目的
Radiko にはタイムフリーという名の過去番組聴取機能が存在するが、
- 聴取可能期間は放送終了から1週間
- タイムフリー再生開始から3時間が経過すると聴取権限が無くなる
といった制限があり使い勝手がよろしくないため、後日好きなタイミングで再生が出来るようサーバ上で録音出来る環境が欲しかった。
環境
Radiko は都道府県を IP アドレスで判定しているため、VPSのリージョンによって聴取出来る放送局が違います。
私は東京の放送局を主に聴取しているので東京リージョンを選択しましたが、
他地域の放送局を聴取したい場合は別リージョンを用意してください。
サーバ
ローカル
- macOS 10.15.6 Catalina
- iTerm2
Radiko 録音の OSS 紹介
Radiko の録音ツールに関しては、先人が OSS として公開している物が存在しているので、その中で気になった物を下記に示します。
matchy2/rec_radiko.sh
matchy2 さんが Gist にて公開されており、旧サーバからお世話になっている OSS です。
今回はこのリポジトリを Fork して自分用にカスタマイズしました。
sankaku/docker_rec_radiko
github.com
上記 OSS を参考に Docker 化した方もいらっしゃしました。
Docker が実行できる環境ならこちらのほうがお手軽かも。
yyoshiki41/radigo
github.com
qiita.com
Golang で書かれており、CLI で現在聴取可能番組一覧の表示や、タイムフリー/リアルタイム録音が可能。
プレミアム会員の方は mail / password を環境変数に設定してエリアフリーの録音機能も可能。
今後、自前で録音ツールを開発する際に参考にする予定です。
Fork したコードについて
Fork 先リポジトリは下記リンクを参照。
Fork 元との差分は下記1点のみ。
- ファイルの保存形式を
mp3
からm4a
へ変更
私の環境では m4a
形式(中身は AAC)でも再生に支障が無いので、mp3
へエンコード時にかかる時間の省略/ファイルサイズの縮小を図った事が理由となります。
作業手順
必要パッケージ導入
スクリプト実行に必要なパッケージを導入します。
$ sudo apt install rtmpdump $ sudo apt install swftools $ sudo apt install libxml2-utils $ sudo apt install ffmpeg $ sudo apt install libavcodec-extra
スクリプト実行
スクリプトを設置するディレクトリ radiko/bin
と番組保存ディレクトリ radiko/data
を作成し、Gist から Clone します。
$ mkdir -p radiko/bin radiko/data $ cd radiko/bin $ git clone https://gist.github.com/246a08f5df885d8566bb546a15c7c11e.git .
実行に必要な権限を与え、スクリプトを実行して動作確認します。
引数で指定したディレクトリに test.m4a
が保存されていれば OK です。
$ chomod 775 rec_radiko.sh $ rec_radiko_m4a.sh QRR 3 /home/<username>/radiko/data test // 実行時に引数が必要で、それぞれ 放送局 id 録音時間(分) 保存ディレクトリ ファイル保存名 を指す。
放送局 id に関しては、Radiko 公式ページでは一覧表などが用意されていないため、 有志の方が公開されているリストを参照してください。
私の環境では、スクリプト実行時に Perl の warning が出ました。
録音に支障はないのですが、以下の記事を参考にパッケージを導入して解決。
$ sudo apt install locales-all
タイマー設定
定期的に番組を録音する場合は crontab
で指定します。
私が実際に運用している例を下記に示します。
$ crontab -l # m h dom mon dow command 00 19 * * 6 /home/<username>/radiko/bin/rec_radiko.sh QRR 121 /home/<username>/radiko/data キミまち 00 21 * * 6 /home/<username>/radiko/bin/rec_radiko.sh QRR 121 /home/<username>/radiko/data エジソン
今後の展望
今回構築した環境では、crontab
にて録音したい番組の日時を直接指定する必要があり少々手間がかかる。
Web ページ上で番組表の表示 / 番組表からの予約といった Web アプリを実装してもよい気がした。
VPS を式年遷宮する その3 サーバの監視周り - Mackerel 導入
概要
サーバ監視を目的として Mackerel を導入、SSH ログイン時 Slack へ通知するスクリプトを組み込んだ。
その際の作業内容を記述する。
環境
サーバ
- Ubuntu 18.04
ローカル
- macOS 10.15.6 Catalina
- iTerm2
1. Mackerelの導入
Mackerel とは
株式会社はてな が開発・運用しているサーバ監視サービス。
mackerel.io
数年程利用していますが、グラフやアラート時系列といった UI が見やすく、
各種設定も分かりやすいのでお勧めです。
Free プランと Standard プランが存在するが、個人用途なら Free プランで十分です。
サーバへのインストール
mackerel-agent
のインストールは非常に簡単です。
Mackerel のダッシュボードにて、新規ホストを追加する際に提示されるワンライナーコマンドを実行するだけで完了します。
$ sudo wget -q -O - https://mackerel.io/file/script/setup-all-apt-v2.sh | MACKEREL_APIKEY='<API Key>' sh
私の環境ではパッケージが足りず失敗したので、必要パッケージを導入しました。
$ sudo apt install gnupg
監視ルールの設定
サーバに異常が出た際、通知するための監視ルールを設定します。
Free プランでは監視ルール数の上限が結構少ないので、
厳密な設定が必要な場合は有償プランを検討してください。
Slack 通知の設定
監視ルールに抵触した場合は通知を送信できます。
送信先には様々なサービスが選択でき、複数サービスへ同時送信も可能です。
Slack へ通知を行う際には下記の2つが必要です。
- 通知するチャンネル名
- Slack の Webhook URL
実際に Slack へ通知が送られた例は以下の通り。
2. SSH ログイン時通知スクリプト導入
SSH ログイン時に実行するスクリプトを /var/local/script/
に設置する。
$ sudo vim /var/local/script/sshlogin.sh --- #!/bin/sh #WebHookUrl WEBHOOKURL="<WebHookUrl>" #Slack送信チャンネル CHANNEL=${CHANNEL:-"#server"} #Slack送信名 BOTNAME=${BOTNAME:-"SSH_Login"} #Slackアイコン FACEICON=${FACEICON:-":ghost:"} #Slackメッセージ MESSAGE=${MESSAGE:-"$1が$2から$3にログインしました"} curl -s -S -X POST --data-urlencode "payload={\"channel\": \"${CHANNEL}\", \"username\": \"${BOT NAME}\", \"icon_emoji\": \"${FACEICON}\", \"text\": \"${MESSAGE}${WEBMESSAGE}\" }" ${WEBHOOKURL} >/dev/null
/etc/ssh/sshrc
に下記を記述する。
$ sudo vim /etc/ssh/sshrc --- if [ $PS1 ]; then /var/local/script/sshlogin.sh "$USER" "$SSH_CLIENT" "$HOST_NAME" fi
SSH でログインを行うと Slack へ下図のような通知が届きます。
参考文献
VPS を式年遷宮する その2 VPS セットアップ
概要
VPS 契約後に行ったサーバセットアップの作業内容を記録する。
環境
サーバ
ローカル
- macOS 10.15.6 Catalina
- iTerm2
1. OS アップデートと作業ユーザ追加
VPS の契約と OS インストール完了後、
さくら VPS のコントロールパネルから Web コンソールでサーバに接続し、
OS のアップデートを行う。
$ sudo su - # apt update # apt upgrade -y
作業ユーザを追加する。
# adduser y4shiro # gpasswd -a <Password> sudo
以降、 SSH で接続し作業を行う。
2. SSH の設定
先程設定した User / Password を用いてサーバへ接続。
$ ssh -l y4shiro <IPAdress> // 上記コマンド実行後にパスワードを求められる
SSH 接続に成功後、sshd_config
の設定を変更する。
$ sudo su - # vim /etc/ssh/sshd_config --- // デフォルトのポートではセキュリティリスクが高いので変更 - Port 22 + Port <任意のポート番号> --- // root でのログインを不許可 - PermitRootLogin prohibit-password + PermitRootLogin no --- // 公開鍵認証を許可 - PubkeyAuthentication no + PubkeyAuthentication yes --- // パスワード認証を不許可 - PasswordAuthentication yes + PasswordAuthentication no --- // PAM を使用しないので無効化 - UsePAM yes + UsePAM no ---
編集後、sshd
を再起動する。
# service ssh restart
3. FireWall 設定
今回は Ubuntu の uwf
を使用する。
# ufw default deny # ufw allow <SSH Port> # ufw allow 80 # ufw allow 443 # ufw enable
4. 公開鍵接続の設定
公開鍵を登録して SSH 接続できるようにする。
今回はローカル側から鍵をコピーした。
// サーバ側で /.ssh ディレクトリを作成し、パーミッションを変更 $ mkdir ~/.ssh $ chmod 700 ~/.ssh
// ローカル側から公開鍵を送信 $ scp -P 12555 ~/.ssh/id_rsa.pub y4shiro@<IPAdress>:~/.ssh/authorized_keys
// 公開鍵のパーミッションを修正 $ chmod 600 .ssh/authorized_keys
実際に公開鍵で接続できる事を確認する
$ ssh -p 12555 -l y4shiro <IPAdress>
参考資料
さくらVPS1GプランにUbuntu16.04でサーバーを構築した備忘録 - spangled shalalala blog
超簡単Ubuntu 18.04(ConoHa VPS)必要最低限(セキュリティ)初期設定(ユーザー・SSH・ファイアーウォール)|10mohi6|note
VPS を式年遷宮する その1 移行先検討
目的
VPS の移行先検討
希望条件
- ストレージは SSD かつ 100GB 以上
- メモリは 1GB
- 東京リージョン
現行サーバのスペック
- 以降の料金表示は税抜きです
さくらのVPS | |
---|---|
プラン | 1GB (v4) |
CPU | 仮想 2コア |
メモリ | 1GB |
ストレージ | HDD 100GB |
リージョン | 東京 |
料金 | 900円 / 月 |
候補
さくらのVPS | ConoHa VPS | |
---|---|---|
プラン | 1GB (v5) | 1GB |
CPU | 仮想 2コア | 仮想 2コア |
メモリ | 1GB | 1GB |
ストレージ | SSD 50GB (初期費用 1,000円で 100GB) |
SSD 100GB |
リージョン | 東京 | 東京 |
料金 | 900円 / 月 年間契約では9,900円(825円 / 月) |
880円 / 月 |
備考 | 石狩サーバは 880円 / 月 年間契約では8,800円(733円 / 月) |
イメージ保存や LB 利用可 |
結果
元々さくらの VPS を利用しているので ConoHa を試してみたかったのですが、
コスト的にさくらの方が若干安く、かつ数年運用して問題が起きなかったため、
引き続きさくらの VPS を利用する事にしました。
VuePress で静的ページを作成し、GitHub Pages に公開する
VuePress を試したかったので、ついでに CircleCI でビルド/デプロイを行うようにしました。
目的
- VuePress 環境構築
- GitHub Pages の公開
- CircleCI でビルド/デプロイ
までを行う
環境
GitHub リポジトリと成果物
実際にデプロイした GitHub Pages のリンクです。
作業手順の詳細も下記を参照してください。
GitHub - y4shiro/vue-press
所感と今後の予定
VuePress の環境構築、GitHub Pages の公開、CircleCI 環境構築を1日かからずに終えたので、サクッと試せてお手軽でした。
むしろ、README.md を書くほうが圧倒的に面倒だったので、定期的に文章を書いて慣れていく必要性を痛感しました。
CircleCI から GitHub Pages へのデプロイはコミット履歴を汚してしまうデメリットがあるため、別ホスティングへのデプロイに適用したほうが無難です。
ポートフォリオページ作成が頓挫しているので、リニューアルついでに CircleCI を組み込む予定です。