Linux」カテゴリーアーカイブ

個人サイトのいろいろを移行してみた

こんばんわ。ねんどです。お久しぶりです。

最近会社の同僚と話しているときにwebarenaというPaaSを使っているという話を聞いて、7年間使っていたさくらのVPSというサービスよりだいぶ値段が安いということがわかり、かつ今作成しているサービスのデプロイやcentosのバージョンもとっくにEoLが過ぎていたという状態だったので、思い切って移行してみました。

めちゃ適当に書いたイメージはこんな感じ。考えていた要件はもりもりですが、こんな感じ。

  • httpdが前段として受けて、静的コンテンツや各種サービスへプロキシする
  • サービスのコンテナ化(httpd, wordpress, mariadb, …)
  • ansibleで構成管理をきちんとする
  • sslに対応する

どれも仕事で触ってはいるのでハードルは高くないと思ってましたが、一人作業ではなかなか時間がかかってしまいました。

値段の話とか

さくらのVPSはサービスに満足はしていたんですが、今の基準だと結構高くてメモリ512GBで月額590円。たいしてwebarenaは1GBで449円、2GBで814円といったところ。ちょうど料金改定で値上げする後の値段で、今まではもっと安かったようです。

またドメインの管理料も最近値上がっていて、さくらのドメインは.netの維持に年額2700円。対してgoogleドメインだと12ドルということで、円安の影響もありますが半値くらいになるようです。このくらい違うと移行しないとなぁとなりますね。

webarenaはさくらのVPSとそこまでサービスの質は変わらないと思います。若干UIがさくらより良く便利な感じはあるくらいですかね。初期状態でコンソールが取れなかったりと変な部分もあるので大きな差があるようには感じませんでした。

ansibleで構成管理

正直個人サーバにansibleはやりすぎかなと思ったんですが、結論としてはやってよかったと思っています。たしかに時間は結構かかりまして(1ヶ月位?)、ただ半分は学習コストでした。他に比べて忘れやすい作業であるし、今後のデプロイが確実に楽になると思います。普段触らないからこそ自動化の意味も大きいと感じます。

レシピの規模感はこんな感じ。

かなり数は多くなりましたが、やってることはコピペも多いのでそれほどの量ではありません。今回dockerのランタイムからansibleで入れていて、VMを破壊してもすぐに構築できるような状態までもってこれています。

OSバージョン

なんとcentos6.7からcentos stream9に移行してます。時がめちゃとんでいる…!

正直いろいろ苦しいかなと思ったのですが、想像以上に何事もなく動いております。centos6から7はsystemdやfirewalldなど大きめの変更がありましたが、そこに比べるとこれといった変更を感じませんでした。まぁ、会社の本番環境でやる作業ではないのでエイヤな感じです。多分調べたら色々違いはあると思います…。

mariadb container

今回mariadbはホスト上に普通に建てようと思っていたのですが、dockerネットワークの都合もありコンテナ上で動かしてみております。永続化とコンテナの相性は悪いと思っていたのですが、細かいことを除けばそこまで避ける必要はないのかもしれません。雑にディレクトリを/var/lib/mysqlにマウントして動かしてみてます。overlayfsのオーバヘッドなどをシビアに見る場合や、メモリなどの管理上の問題があるかもしれません。

各コンテナ間の通信はdocker上のbridgeで行えるので、とてもいい感じです。ただ今回ローカルネットワーク上にポートをもはや公開していないので、DBの中身を見るときはmariadb containerにdocker execしてからクライアントを叩く必要があってそれが微妙に不便だったりはします。

wordpress

phpのバージョンが古く、かつEoLのcentosで八方塞がりとなっていたwordpressのバージョンを上げたかったのが今回のリプレースの一因でもありました。ランタイムバージョンの影響を大きく受けるコンポーネントなのでこちらは特にコンテナ化したかったです。

データの移行もかなり問題視していて悩んだのですが、結論としてはmysqldumpを吐かせて飲ませた後、wp-contentだけ移してあげれば動きました。一応DB上の値も少し書き換えております。

MariaDB [wordpress]> select * from wp_options limit 2;
+-----------+-------------+----------------------------+----------+
| option_id | option_name | option_value               | autoload |
+-----------+-------------+----------------------------+----------+
|         1 | siteurl     | http://xxx.xxx.xxx.xxx/blog | yes      |
|         2 | home        | http://xxx.xxx.xxx.xxx/blog | yes      |
+-----------+-------------+----------------------------+----------+
2 rows in set (0.001 sec)

上記の値は公開URLと揃っている必要がありそうです。DBの書き換えが正しい手順かはわかりませんが、一応これで動きました。最新バージョンになって警告もなくなりすっきりしております!

ただ一つだけ、コンテナのバージョンに対してwordpressのバージョンを管理画面から上げると一致性が保たれないという問題があります・・。あまり気にしないで、phpのバージョンを上げたいときだけコンテナバージョンを上げれば良いのかなぁと思っているところです。

あと、そもそも今どきwordpressを自前構築するよりもうどこかのブログサービスに乗ればいいのでは・・と思いましたがなんとなく自前構築を続けております!笑

意外と移行は簡単!

やることを整理して淡々とこなしていけば、なんとかできるものだと思いました!今ドメインの移管手続き中なので、それが完了したらSSLの設定も入れてみようかなと思ってます。httpdの設定やそれぞれレシピの書き方など苦労した部分もありましたが、その辺はなんとか調べつつやればなんとかなりそうです。今だとChatGPTに聞くのもありですね。

サイト構築がかなり楽になったので、これから作り物の資材を更に上げていったりできればなと夢が広がりますね!それではまた。

CentOS 7 を VirtualBox で使ってみるメモ

Windows での Docker 体験があまりにも酷すぎたので、開発を完全に Linux でやろうと決意。今のところ決意だけ。

余談

そもそも何故 Windows を使っていたのでしょうか。私が思うメリットを挙げてみます。

  • GUI がよい。慣れの問題もひじょーに関わってくるけれど、CentOS よりはサクサクで使いやすいと思っている
  • Visual Studio が使える
  • 開発とは関係ないけど、ゲームをするなら Windows 一択だと思う

このうち2番目は現状 Visual Studio を使う開発物がないので問題なく、3番目はホスト Windows のゲスト Linux 構成なら支障がないです。実際、CLI に関しては既に Cygwin から ssh して Linux 上でゴニョゴニョしている。この辺までは普通だと思います。

問題となるのは1番目で、特に IDE をどちらで動かすかというのは判断に迷うポイントだと思います。今だと私はホスト Windows に WebStorm を入れていて、付随する Node.js や Git なんかのツールも Windows に入れています。この辺はインストーラをポチポチすれば入りますし。でも Docker はあかんかった…。

書いていても思いますが、やはり開発関連のツールは IDE 含め Linux 側で揃っているべきです。折角なので CentOS 7 の勉強も兼ねて1から導入を試してみます。

インストール

VirtualBox での CentOS 7 の入れ方は他ページを参考にしつつ進めます。パッケージはミニマルではなく開発関連の必要そうなものを一通り入れるようにしました。CentOS 6 に比べると必要な容量がちょっと多い気がします(素で7GB程度)。起動したら Guest Additions もすぐに入れます。それからクリップボードを双方向に設定します。

VM の設定

今回はメイン開発機にする予定なため潤沢にメモリ 8GB を割り当てます。ネットワークアダプタに NAT とホストオンリーアダプタを設定します。それに加えて、ビデオメモリを最大まで割り当て+3Dアクセラレーションを有効化します。モッサリだと思っていた CentOS の GUI がすごくサクサクになりました…!

ネットワークの設定

どうやら CentOS 7 では「nmcli」「nmtui」コマンドを用いて設定を行うことが推奨されているようです。私は下記サイトを参考にさせていただきました。最終的に ifcfg-* ファイルが設定として使われることは変わらない様子。

日本語の設定

下記のサイトを参考にしながら進めました。アプリケーション > システムツール > 設定 > 地域と言語 から 入力ソースのプラスボタン > 日本語 > 日本語(かな漢字)を追加。その後は Windows キー+スペースキーで日本語入力が出来るようになります。

Google Chrome の導入

デフォルトは Firefox のみなので Chrome を導入。公式サイトで配布されている rpm のインストールに失敗したので、私は下記サイトを参考にしつつ導入しました。

フォントの設定

CentOS 6 に比べると、なんだか妙にフォントが汚い気します。調べると、フォントの設定はデフォルトでは設定ファイルを生で書き換えないといけない様子です。下記サイトに従うと、「fonts-tweak-tool」を入れることで GUI から設定できるようです。

[plain]
# yum install fonts-tweak-tool
[/plain]

インストール後は アプリケーション > ユーティリティ > Tweak Tool からフォントを設定できました。

ついでに Chrome のフォントを設定も実施(chrome://settings/fonts)。

WebStorm の導入

公式サイトから落としたパッケージを解凍して bin/webstorm.sh を叩けば起動します。素の状態では Windows より少しモッサリ感を感じますが、設定の問題な気もします。

あとは開発ツールを必要に応じて入れていけばよさそうです。その辺は yum が使える CentOS は一番楽だと思います。

感想

Windows から脱却できそうな、そこそこの手応えを感じました。WebStorm の動作が少々モッサリに感じますが、慣れや設定の問題かもしれないです。加えてスクリーンロック時の表示が無駄に今風でカッコよさげ。

なにより Windows での環境構築の面倒から開放されるのは嬉しいです。今後もぼちぼちと移行を進めていく次第です。

Foswiki: WYSIWYG の出来るフリー Wiki を求めて

動機

個人用のドキュメンテーションツールとしては今まで PukiWiki を利用していて、基本的な機能に不満はないけれど要所でイケてないと感じていました。

  • マークアップを思い出すのが辛い
    • プレビューすら自動反映されずストレスが溜まる
    • 画像の取扱いも厳しい
  • 本体の更新が止まっている
    • 周辺プラグインの開発が進んでいない
    • それどころか保守されず消えているものも多い
  • 権限の設定が設定ファイル依存で辛い
    • GUI から設定情報の確認、設定の投入もろもろ出来て欲しい

問題点を考えてみるとこのくらいです。仕事で利用している Confluence は上記に関してだけみれば大きく上回っていると感じますし、理想を考えるとあのくらいの機能が欲しいところです。

似たような選択肢としては以下の様なものが見つかりました。

  • DokuWiki
    • プラグインで WYSIWYG 出来るようにしたり、マークアップを Markdown にしたり
    • (普及率を除けば)基本的に PukiWiki の上位互換といった風体で、なかなかよさそう
  • Sphinx
    • そもそもローカルで管理して、見せるものだけ適当な HTTP サーバにおけばいい派
      • 今回はブラウザからいじりたいので、要件としては少し足りていません
    • ReST を Markdown に変える方法も提供されています
    • Git で管理できるのでバージョンの取り方としては一番汎用的で馴染みがあります

DokuWiki は特に良いと思いましたが、わざわざ手間を掛けて PukiWiki と同じようなアプリケーションを入れるのも少々辛いところです。せっかくならばデフォルトで WYSIWYG が可能で少々高級なツールを入れたいと思い、見つけたのが Foswiki です。

調べてみると、日本語のドキュメントがあまりないようです。一応、トップページのサマリを見てみると

  • Edit pages collaboratively
  • If needed, protect pages with flexible access controls
  • Versioned documents and attachments with revision history
  • Best in class WYSIWYG text editor

上記の記載があります。ライセンスは GPL で、再配布をしないのならば基本的にフリーで使えそうです。


導入

依存パッケージの情報などは以下を参照してください。

CentOS 6.8 のデフォルトで入っている Perl は 5.10.1 の様子なので、試しに使う程度ならこのままで大丈夫そうです。早速以下のガイドに従って導入をはじめてみます。

まずはパッケージの解凍を行います。

[plain]
$ wget http://sourceforge.net/projects/foswiki/files/foswiki/2.1.2/Foswiki-2.1.2.tgz
$ tar xf Foswiki-2.1.2.tgz
$ ls -d Foswiki-2.1.2
Foswiki-2.1.2
[/plain]

次に、Foswiki 用の Apache の config を吐き出してくれるツールを用意してくれているので、その設定を入れます。

私は以下の点のみ変更して設定を生成しました。

  • Apache version: 2.2
  • File system paths: /opt/app/foswiki
  • URL Path: /wiki

その後、設定をコピペして httpd を再起動します。中身は本気で使おうと思ったらよく読む必要があると思いますが、とりあえずはこのままで進めたいと思います。

[plain]
# vi /etc/httpd/conf.d/foswiki.conf
// 生成した設定をコピペする
# service httpd restart
[/plain]

あわせて、本体の配置とパーミッションの設定を行います。

[plain]
# mv Foswiki-2.1.2 /opt/app/foswiki
# chown -R apache:apache /opt/app/foswiki
[/plain]

この状態で /wiki にアクセスすると、依存ライブラリが足りていないと表示されました。どうやら標準の Perl ではコアモジュールが足りていないらしいです(Perl 5.8.8 or higher って書いてたのになぜ…)。また Perl の最新版は rpm が配布されてないらしく、導入も手間が必要そうです。Foswiki の依存関係を調べるツールによると、以下のモジュールが足りていない模様。

[plain]

# ./tools/dependencies
The following critical dependencies are missing from your installation:
… CGI::Session: Can’t locate CGI/Session.pm in @INC
… Crypt::PasswdMD5: Can’t locate Crypt/PasswdMD5.pm in @INC
… File::Copy::Recursive: Can’t locate File/Copy/Recursive.pm in @INC
… JSON: Can’t locate JSON.pm in @INC
[/plain]

これらを cpan で順に入れていきます。

[plain]
# yum install cpan
# perl -MCPAN -e shell
[cpan] install CGI::Session
[cpan] install Crypt::PasswdMD5
[cpan] install YAML
[cpan] install File::Copy::Recursive
[cpan] install JSON
[/plain]

ここまで実施した上で、もういちど /wiki を開くと Can’t locate Time/HiRes.pm というエラーが表示されました。調べたところ、処理時間を計測するモジュールらしいです。このモジュールは yum で追加できます。

[plain]
# yum install perl-Time-HiRes
[/plain]

この時点で /wiki を開くと、遂に Frontpage が表示されました。

初期設定

ここからは、基本的に GUI が提供されるためポチポチやればいいと思います。本番適用時には設定を見直す必要があると思います。私は、初期設定を以下の手順で済ませました。

  1. /wiki/System/UserRegistration から新規アカウントを登録
  2. /wiki/Main/AdminGroup を開いて、作成したアカウントを Add Member する
  3. /wiki/bin/configure から、サーバの初期設定を作成する
    1. Security and Authentication タブから Access Control Implementation のセレクトを選択し、「TopicACLReadOnlyAccess」を選択
      1. この設定で外部アカウントは「閲覧のみ、新規アカウント作成も不可」となり、これらの権限設定は AdminGroup に登録されているアカウントのみ可能となる
    2. 設定を保存する

前提として、設定を保存していない一番初めの状態ではアクセスした人すべてに Administrator 権限が付与されます。従って速やかに管理者の追加を行い、初期設定の保存を行う必要があります。

ここまで行ったら、あとはまったりと管理者で操作を試してみます。


所感

まず肝心かなめの WYSIWYG 操作。エディタ画面はこんな感じです。

可もなく不可もなくと言った感じです。ただ、少なくとも PukiWiki で書くよりは楽に感じます。使ってみた限り、キーボードショートカットがない、あるいは直感的なアサインになってないため、その辺りは気になります。(箇条書きが Tab で段落ちできなかったりするので…。)

画像のアップロードは予想よりもかなり良い感じです。

編集画面から直接アップロードして、画像を選択すれば WYSIWYG で表示されます。PukiWiki ではアップロードした画像ファイルを識別するための名前を毎回打たないといけなかったので、随分と楽です。

権限周りは予想を上回る多機能さで、正直複雑すぎてわかりにくいです。

基本的に記事単位で Read と Write を設定でき、それぞれデフォルト(これは本体の設定に権限が依存する)・登録済みアカウント・自分自身・特定のアカウント/グループへの権限指定が可能である様子です。アカウントの作成と閲覧・編集権限の付与という基本操作は GUI から行えます。

他にも、検索機能や特定ページの購読・RSS などの機能がある様子です。この辺は使い込んでみないと使用感は分からない感じです。また、導入に関しては、実装言語として Perl を使っていることがやはり大変です。

機能は有り余るほどあると感じるので、PukiWiki に力不足を感じたら導入を考えてみるのもよいかもしれません。