WordPressがマルウェアに感染したり、ファイル等の改ざん被害を受けた際の対策をまとめました。

WordPressは狙われやすい

WordPressは、世界で最も多く利用されているオープンソースのCMSです。

しかし利用者が多いということは、ITリテラシーやセキュリティ意識の低いユーザーが多い可能性も高くなります。

りゅう

つまり悪意あるユーザーにとっては格好の標的となります。

ということで今に始まったわけではありませんが、WordPressは悪意あるユーザーに「常に狙われている」状態にあるとまず考えましょう。

名の売れたサイトが狙われやすいのは当然ですが、「自分のところはアクセス数が少ないから対策しなくても大丈夫だろう」と高をくくるのは危険です。

悪意あるユーザーが求めているのは、まさにそのようなセキュリティ意識の低いサイトです。

被害に遭ってから対策するのはかなり骨の折れる作業になりますので、事前にできる限りの予防をしておきましょう。

乗っ取り被害のチェック

WordPressの管理画面にログインし、左メニューの「ユーザー」を確認します。

もし自分以外のユーザーが不正に登録されていたら、即座に削除しましょう。

さらに自分自身のパスワードも、長く難解なものに変更します。WordPress側で自動生成することもできます。

adminユーザーに注意

WordPressでは、デフォルトの管理ユーザーがadminになっています。

これをこのまま放置するのはセキュリティ上好ましくありませんので、管理権限を持つ別ユーザーを作成して、adminは削除することをおすすめします。

ログインユーザー名が表示されるのを防ぐ

http://******.***/?author=1のように、自サイトのURLに/?author=1を追記してブラウザで表示してみてください。

管理者権限を持つユーザー名が表示される場合、これは危険な状態です。

WordPressの認証は基本的にユーザー名とパスワードの2要素で行いますので、そのうち1つがバレるというのはリスクが高いと考えてください。

手動でなんとかする方法

テーマディレクトリ内のauthor.php（無ければ作成）の内容を、以下の通りにします。

<?php
    wp_redirect(home_url());
    exit();

これで、authorのユーザー名を表示することなくトップページに強制転送します。若干無理やり感がありますが。

プラグインを使用する方法

Edit Author Slugというプラグインで対策できます。

ユーザーアーカイブのスラッグを変更することができますので、/?author=1のようにアクセスしても設定したスラッグのURLに転送され、ユーザー名が露呈することはありません。

りゅう

テーマによっては、ユーザー名の表示を無効化する機能を持っている場合もあります。

ログイン保護と不正アクセス対策

不正アクセスを防ぐためには様々な方法がありますが、まとめて行ってくれるプラグインがあります。

SiteGuard WP Plugin

りゅう

既に改ざんや乗っ取り被害の跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

SiteGuardは国産のセキュリティプラグインで、ログインページの保護と不正アクセス対策に特化しています。

上の画像のように、ログイン履歴を見ることもできます。

注目すべきは右端の「タイプ」で、ログインページではなくXMLRPCからのログイン試行（失敗）が並んでいる点です。私がそのような操作を行ったことはありませんので、これは不正アクセスの試行を受けていることを意味しています。

りゅう

XMLRPCとは外部からWordPressを操作する仕組みと考えてください。外部連携には便利な機能ですが、悪用されやすいというデメリットがあります。

SiteGuardでは、このXMLRPCを無効にする設定も可能です。

いくつかの機能がありますが、私は以下のように設定しました。

日本語で項目ごとに説明が記述されているので迷うことは少ないでしょう。

「ログインページ変更」では、/wp-admin/と決まっている管理画面のURLを変更することができます。想像できる通り、ログインページからの不正ログイン試行の多くを防ぐことができます。

「画像認証」は、ひらがなによる画像認証を追加することができます。コメントにも仕掛けられますが、筆者はログインページだけにしておきました。

「XMLRPC防御」では、XMLRPCそのものを無効にしました。具体的には.htaccessにxmlrpc.phpへのアクセスを禁止する記述が追加されます。

これでひとまず、不正ログインに関してはかなりセキュリティを強化することができます。

改ざんと不正ファイルのチェック

これらの被害に遭っているかどうかを手動で調査するのは、大変骨の折れる作業となります。

ここでは、セキュリティリスクをスキャンできるプラグインを使用して、被害に遭っているかどうかを確認します。

Wordfence Security – Firewall & Malware Scan

Wordfenceは、WordPress本体のファイル改ざんや、不正なファイルが作成されていないかをスキャンすることができます。

また、古すぎたり更新が停止しているプラグインはスキャン結果で警告されますので、代替となるプラグインを探すことをおすすめします。

Wordfenceは英語のプラグインですが、使用するのは一部機能のみで設定も特に要らないため問題になることはないでしょう。

何はともあれ、まずは上記プラグインをインストール、有効化します。

りゅう

既に改ざんや乗っ取り被害の形跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

管理画面の左メニューに"Wordfence"が追加されますので、そこから"Scan"を選択します。

"START NEW SCAN"ボタンをクリックすれば、WordPressインストールディレクトリ以下の全ファイルを調査してくれます。

この画像では左下部の"Results Found"が空になっていますが、これは改ざんや不正なファイルが見つからなかったことを示しています。

りゅう

日本語版WordPressではwp-config-sample.phpとreadme.htmlが「内容がオリジナルと異なる」と表示されますが、多くの場合正常です。
前者はPHPスクリプトなので、一応おかしなコードが埋め込まれていないか確認（後述）し、問題がなければどちらもIgnore（無効）にしてしまってOKです。

もし"Results Found"に改ざんされたファイルや不正に作成されたファイルが表示された場合、対策が必要です。

具体的には、以下のように対応します。

• 改ざんされたファイル：対象ファイルをエディタで開き、後述のようなコードが埋め込まれていれば該当部分を削除する。
• 不正に作成されたファイル：対象ファイルを削除する。

このスキャン作業は、たまに行って確認するようにしましょう。日々の作業が増えますが、被害に遭ってから対応するよりよほど楽です。

Live Trafficが便利

Wordfenceには、他にも様々な機能がありますが、主に使用するのは上記のスキャンと、"Live Traffic"です。

アクセスログをほぼリアルタイムに閲覧できる機能ですが、国名を見られたり、怪しいか問題のあったアクセスを色分けして表示してくれたりするので大変便利です。

この機能だけを持つプラグインもありますが、このように1本にまとめられているのは嬉しい限りです。

また、上の画像がまさにそうなのですが、不正なアクセスを行ったIPアドレスをブロックリストに入れることもできます。

りゅう

ただし攻撃者は自らのPCではなく様々な国にある複数の踏み台を操って不正アクセスを試みますので、多くの場合IPアドレスは一定ではありません。
したがって単一のIPアドレスをブロックすることには（無意味とは言いませんが）あまりメリットはありません。

改ざんされたファイルの修正

Wordfenceのスキャンで改ざんされたファイルが見つかったら、エディタで開いてみます。

おそらくファイルの先頭に以下のようなコードが不正に埋め込まれています。

<?php $xxxx = Array(/* 無意味に見える大量の英数字 */);
eval(xxxx_function($base64_data, $xxxx)); ?>

「無意味に見える大量の英数字」の部分をbase64でデコードすると、PHPのコードであることがわかります。

私は何度もいたちごっこを繰り返しましたが、改ざんされるファイルは毎回index.php, wp-config.php, wp-settings.phpあたりでした。

これらのファイルはWordPressが毎回必ず読み込むファイルであるため、悪意あるコードを埋め込むにはうってつけというわけです。

上記のようなコードを発見したら、エディタで不正コード部分の<?phpから?>までを削除してください。

りゅう

完全な原因究明と抜本的な対策が行われない限り、繰り返し改ざんが行われる場合があります。私もそうでした。

不正に作成されたファイルの削除

Wordfenceの"Live Traffic"の部分で紹介した画像のように、いかにもランダムで付けたファイル名である場合が多いですが、たまに意味ありげなファイル名になっていることもあります。拡張子は.phpです。

作成されるディレクトリはまちまちで、wp-admin/やwp-includes/の中であったり、wp-content/uploads/の中であったり、プラグインやテーマのディレクトリ内であったりします。深い階層内に作成されることもあります。

該当ファイルをエディタで開くと、コードは概ね以下のように難読化されています。

最後の方でeval関数によって文字列がPHPコードとして評価されます。

りゅう

実行されるコードは様々でしょうが、筆者の場合はSPAMを送信するコードになっていました。

攻撃者はこの不正に作成したPHPファイルにPOSTメソッドでアクセスし、実行してきます。これはアクセスログやWordfenceの"Live Traffic"で確認することができます。

この不正ファイルを放置するのは大変危険ですので、見つけ次第 問答無用で削除してください。

海外のIPアドレスを拒否する

いささか乱暴ではありますが、攻撃はほぼすべて海外のIPアドレスから行われますので、サイトの公開対象が国内のみであれば、海外からのアクセスをすべて遮断してしまう方法があります。

これは大変効果的で、攻撃者とのいたちごっこを繰り返していた私が最終的に問題を解決するに至った手法です。

遮断する方法はいくつかありますが、ここでは最も修正が手軽な.htaccessによるアクセス制限を紹介します。

以下は、私が採用している.htaccessです。内容は、以下のような流れになっています。

1. すべてのアクセスを拒否
2. Googleやfacebook, Twitterなどbotからのアクセスを例外として許可
3. 日本国内で使用されるIPアドレスを例外として許可（4千行以上）

Apacheのバージョンによってアクセス制限の書式が異なる点に注意してください。

▼Apache 2.2系を使用している場合

https://gist.github.com/ryu-blacknd/3625090cd46b2b60d7ce3700ae7d6b78

▼Apache 2.4系を使用している場合

https://gist.github.com/ryu-blacknd/59dc7f1dbf5c82a3be507a9acb0146d9

多くの場合、既に何かが書かれた.htaccessファイルが存在すると思いますので、その部分は残して上記コードを追記してください。

貼り付ける場所に悩んだら、# BEGIN WordPressの直前にしておけばOKです。

SPAM送信の踏み台にされた場合の対処

私が実際に被害に遭ったサーバの環境は、OSがCentOS 7で、MTA（メールサーバ）はPostfixです。

ここではPostfixであった場合、かつrootによる作業が可能な場合の対処方法を紹介します。

まずは現在溜まっているキューを確認します。

$ postqueue -p

送信した覚えのないメールがズラッと表示された場合、既にSPAM送信が実行されています。

この場合は以下のコマンドでまずキューを削除します。

$ postsuper -d ALL

上記対応によって問題が解決している場合は、このままPostfixの運用を続けて構いません。

まだ対策が完了していない場合はさらにキューが増加しますので、不本意ながらPostfixを停止しておきます。

$ systemctl stop postfix

当然ですが、Postfixを停止している間はメールの送受信が機能しません。なるべく早期に対策を終え、再度Postfixを起動します。

$ systemctl start postfix

一度SPAMの踏み台になってしまった以上、以後しばらくはキューの確認を行うことをおすすめします。

まとめ

既に書きましたが、最も効果的な対策は海外のIPアドレスを排除することです。

すべての対策を行っても解決しない場合、最終手段は再セットアップということになります。WordPressのファイル群をすべて削除し、素のWordPressから再度環境を構築をすることで、クリーンな状態に戻せます。

ただし事前にバックアップを取ることはもちろんですが、バックアップしたファイルをそのまま書き戻さないこともまた重要です。
プラグインやテーマは改めて新規インストールし、手動で以前の設定を復元するべきです。

この作業は困難かつ時間がかかりますので、できることならここで紹介した方法で解決したいものです。

最後になりましたが、WordPress本体やプラグイン、テーマのアップデートは無視せず実行してください。

りゅう

公開されたばかりのバージョンであっても脆弱性が発見されることがしばしばありますので、常に目を光らせておいてください。

動画編集は目的によって最適な方法が異なり、正解というものはありません。本記事では目的別に定番を紹介します。

動画編集ソフトウェアの定番

Windowsで利用できる動画編集ソフトウェアは多数あります。かつては多くの選択肢がありましたが、近年では定番と呼べるものががだいぶ絞れてきたように思います。

ここではそんな定番たちを用途別に紹介しつつ、後半は個人的に特におすすめしたい、CUIによる動画編集とエンコードツールを紹介していきます。

本格的な映像制作

やはり筆頭はAdobe After EffectsとAdobe Premiere Proでしょう。VegasやEDIUSなど他社製品と比較されることもありますが、やはりAdobe製品のマーケットシェアは圧倒的です。

映像制作会社でAdobe系のソフトウェアがないと、外部とのファイル受け渡しに困ってしまいます。

Adobe Creative Cloud

Adobe CC（Creative Cloud）のライセンスを購入すると、期間内は好きなだけAdobe製品の最新版をダウンロードして使用できます。

りゅう

太っ腹なことに2台分のライセンスになっています！

Adobe Creative Cloud コンプリート|12か月版|Windows/Mac対応|オンラインコード版

¥65,102 （2022/06/08 13:51時点 | Amazon調べ）

Amazon

楽天市場

Yahoo!ショッピング

ポチップ

Premiere Proは主にカット編集、トランジションなどのエフェクト適用を目的としたソフトウェアで、編集からエンコードまでのほぼ全行程をこれ一本で行えます。特にカット編集はさすがに秀逸です。

After Effectsはその前工程となる映像制作、つまりPremiere Proに渡すソース動画を制作する用途というイメージです。
動画版Photoshopと呼ばれることもあります。

Adobe製品は大量に存在する高度なプラグインやエフェクトが魅力です。

りゅう

映像制作において、Adobe CCでできないことというのはちょっと思い浮かびません。

Adobe製品のパフォーマンスを向上するには

CPUの内蔵GPUでは、十分なパフォーマンスを発揮できません。

おすすめはNVIDIAのCUDAによるハードウェアアクセラレーションが可能なGPUです。

MSI GeForce RTX 3060 VENTUS 2X 12G OC グラフィックスボード VD7553

MSI

¥57,916 （2022/06/08 13:51時点 | Amazon調べ）

Amazon

楽天市場

Yahoo!ショッピング

ポチップ

エンコード時に流行りのコーデックが使えない！

具体的にはx264やNVEncが使えません。AviUtlなどからの乗り換え組にとっては衝撃の事実ですが、H.264に関してはメーカー製品が組み込まれていますので、ライセンス問題とか色々あるのでしょう。

この問題、実は対応可能です。別記事にまとめましたので参照してください。

https://blacknd.com/video-editing/adobe-cc-encode-codec-h264-avc-h265-hevc-x264-nvenc-geforce/

GUI操作が簡単な動画編集

Adobe製品の低価格版のような製品が多く存在します。
具体的にはPowerDirectorとかVideoStudioとか、そういった製品です。

用途はエンコードやリサイズ、動画形式の変換が多いでしょう。併せてカット編集、リサイズ、インターレース解除、字幕入れなどの一般的な動画編集もよく行われます。

私の周囲では、企業で「会社の方針でフリーソフトは使えないが、Adobe CCは高額すぎる」という制限のあるところが、よく上記のような製品を導入していました。

りゅう

でも正直、そういうところは最近見なくなりましたね。

TMPGEnc Video Mastering Works

TMPGEnc Video Mastering Works 7|ダウンロード版

ペガシス

¥12,069 （2022/06/08 13:51時点 | Amazon調べ）

Amazon

楽天市場

Yahoo!ショッピング

ポチップ

バージョン6よりNVEnc（HEVC）のハードウェアエンコードに対応し、インターレース解除に新機能も登場し、順調にパワーアップを続けています。

カット編集機能は賛否両論ですが、サムネイル部分をマウスのボタンでザーッと流すあたりの操作性は気に入っています。個人的にCMカット最強と考えているTMPGEnc MPEG Smart Renderと同じように使えます。

TMPGEnc MPEG Smart Renderer 6 |ダウンロード版

ペガシス

¥7,313 （2022/06/06 01:00時点 | Amazon調べ）

Amazon

楽天市場

Yahoo!ショッピング

ポチップ

りゅう

後にAviSynth+の記事で登場しますが、TMPGEnc MPEG Smart Renderは少し特殊な役割を持っています。

TMPGEncシリーズは、難しいこと抜きで今すぐGUIで使いこなしたい！という方や、AviUtlを学ぶ気になれない！面倒！という方に適しているでしょう。

AviUtl

http://spring-fragrance.mints.ne.jp/aviutl/

無料で使用できるフリーソフトウェアでは、やはりAviUtlの人気が頭一つ抜けています。

単なるエンコードや動画形式変換なら他にもお手軽ツールがありますが、AviUtlは勉強と努力次第で高度な動画編集を可能にしたり、市販ソフトウェアで読み込めない動画ファイルを読み込んだりできる柔軟性があります。

国内の利用者が非常に多く、ネットの情報も豊富です。x264でエンコードする出力プラグインの登場が、普及に拍車をかけたように思います。

拡張編集プラグインによりタイムライン編集もサポートし、Adobe Premiere Proっぽいことまでできてしまいます。

りゅう

無料でありながらこれ一本で大抵のことはできてしまう、優秀なフリーソフトウェアです。

ただしうまく活用するには、それなりの知識や経験が必要です。プラグインは古いものを含めると把握しきれないほど多く、入門者は似た機能を持つプラグインの取捨選択に戸惑うことでしょう。

急成長は止まった感がありますので、今から勉強する人はある意味入りやすいかもしれません。

りゅう

数年ぶりに新バージョンが登場しましたが、残念ながら期待された64bit化は（将来的にも）されないとのことです。プラグインの互換性が失われるため厳しいのでしょう。

AviUtlについてはこのサイト内にもまとめ記事がありますので参照してください。

AviUtlは「手に馴染むツール」として上級者にも人気があります。他のツールと併用している人も多いですね。

高速化・自動化できる映像編集

動画編集やエンコードは、突き詰めればフィルタやプラグインの機能理解、知識と経験、そして独特のセンスが重要になってきます。

自動化や効率化を追求するようになると、だんだんGUIが邪魔になってきます。

りゅう

どうしても似たような作業の繰り返しが多くなりますので、いちいちGUIで操作するよりスクリプト化して使いまわす方が理に適っています。

以下は独自のGUIを持たず、コマンドラインやスクリプトファイルによって動画編集を行うツールです。

FFmpeg

FFmpegは、メディアファイルの入力～編集～出力までを1行のコマンド（ワンライナー）で実行可能なツールです。
用途次第ではこれだけでほとんど何でもできてしまいます。

https://ffmpeg.org/

以下は、FFmpegによる簡単なパターンでのエンコード例です。

ffmpeg input.mp4 -s 1280x720 -sws_flags spline -vcodec nvenc_hevc -b:v 2M -vf bwdif=0:-1:1 output.mp4

input.mp4を読み込み、Splineで1280x720pxにリサイズし、コーデックをNVEnc（HEVC）とし、平均ビットレートを2Mbpsとし、インターレースを解除して、output.mp4にエンコード出力する、という内容です。

ご覧の通り「無敵か！」と思えるほどの簡便性ですが、後述するAviSynth（AviSynth+）に比べると周辺ツールやフィルタ選択の自由度、設定の多彩さで劣ります。

りゅう

しかしエンコードまでワンライナーで行える点では勝っています。用途次第ですね。

万能かつコマンド1つという手軽さから、内部的にFFmpegを利用するソフトウェアも多く、例えば携帯動画変換君などはFFmpegのラッパーとなっています。
有名なフリーのDVDオーサリングツールであるDVDStylerも、内部でFFmpegを使用しています。

今はどうか知りませんが、Youtubeも内部のエンコードをFFmpegで行っていたと記憶しています。
動画サービスを扱うサーバで利用されていることは非常に多く、OSの垣根を超えて活躍しています。

AviSynth

「定形処理 → 即エンコード」を前提とした動画編集で、高画質化と高効率化を両立・追求するならAviSynth（またはAviSynth+）でしょう。

http://avisynth.nl/index.php/Main_Page

りゅう

PT3のTV録画ファイルを扱う際等、たくさんのファイルに同じ編集処理を行いたい場合はコレで決まり！

AviSynthはVirtualDubなどと共に古くから人気があり、実はAviUtl用プラグインはAviSynth用フィルタの移植、ということも少なくありません（たまに逆もあります）。過去の記事で書いたNNEDI3もそうです。

AviSynthをおすすめする理由は、こういった優れたフィルタの存在だけでなく、その組み合わせやパラメータ指定、順序の組み立てにより、納得いくまで高画質化と高速化、高効率化を追求できるためです。

以下は本家サイトの説明をGoogle先生に翻訳してもらったものです。

AviSynthは、ビデオポストプロダクション用の強力なツールです。動画の編集や処理方法を提供します。
AviSynthはフレームサーバーとして機能し、一時ファイルを必要とせずに即座に編集できます。
AviSynth自体はグラフィカルユーザーインターフェイス（GUI）を提供しませんが、高度な非線形編集を可能にするスクリプトシステムに依存しています。これは、最初は面倒で直感的ではないように見えるかもしれませんが、それは非常に強力で、正確で一貫した再現性のある方法でプロジェクトを管理する非常に良い方法です。テキストベースのスクリプトは人間が読めるので、プロジェクトは本質的に自己文書化しています。
スクリプト言語はシンプルですがパワフルであり、基本操作から複雑なフィルタを作成して、有益なユニークなエフェクトの洗練されたパレットを作成することができます。

無意味に難解ですが、強力で、高速で、GUIがない代わりに効率的な処理ができるよ！ということですね。

AviSynthはCUIツールのため独自のGUIは持ちませんが、有志によるAvsPmodという有名なGUI（というかプレビュー付きのエディタ）が存在します。これは後の記事で紹介します。

具体的には、こういう使い方になります。

• ファイル名.avsというテキストファイルに適用したい処理を順に記述
• 上記avsファイルをコマンドライン版のx264やx265、QSVEncCやNVEncC、あるいはAviUtlなどに渡してエンコード

他のコマンドやツールに渡す理由は、AviSynthは基本的に動画にフィルタをかけるだけのツールであり、単体でエンコードする機能を持たないためです。

りゅう

AviUtlも標準のAVI出力以外は外部ツールに頼っています。GUIでパラメータを指定して処理を投げているわけですが、これと同じことをコマンドラインやバッチファイルで行うわけです。

渡されたコマンド側からは、avsファイルは「フィルタ適用済みの動画ファイル」のように見えます。

以下は非常に単純なAviSynthスクリプトの例です。

avsource = "D:¥My Videos¥Video_001.mpg"

LWLibavVideoSource(avsource)
AudioDub(last, LWLibavAudioSource(avsource, av_sync=true))

AssumeTFF()
TDeint(edeint=nnedi3)
Spline36Resize(1280, 720)

return last

上記スクリプトでやっていることは以下の通りです。

1：読み込む動画ファイルを指定
3：映像を読み込む
4：映像と同期しつつ音声を読み込む
6：フィールドオーダーをトップフィールドファーストに指定
7：インターレースを解除
8：1280x720pxにリサイズ

AviSynthの魅力的なところは、フィルタリングにかかる時間を惜しまなければ極限まで高画質化できるという点です。上の例ではインターレース解除やリサイズの処理が様々に工夫できます。

他にも放送局のロゴ除去、CMカット、逆テレシネ化（映画やアニメ録画番組の30→24fps化）、フレーム補完によるぬるぬる60fps化、色調補正、カット編集、黒ベタ、回転、再生速度変更、ぼかし、シャープ、字幕入れなど、AviUtlで可能なことは大体何でもできます。

スクリプトは単なるテキストファイルであり、上の例ではソースさえ書き換えれば同じ設定で何度でも再利用できます。ソース部分を動的に取得または生成するバッチファイルを書けば、処理を自動化できます。

先人による優れたスクリプトを単純なコピペで拝借することができる点も素敵です。

Avisynthの詳細については、別の記事で説明していますので参照してください。複数動画のエンコードを自動化するためのバッチファイルも公開しています。

次回以降はAviSynthから派生し高速化を図ったAviSynth+を紹介していきます。

CentOS 7にLAMP環境を構築。GitBucketとJenkinsを動かし、自動ビルドや自動デプロイまでやってみます。

なぜGitBucketか

GitBucketはGitHubクローンで、似たものに有名なGitLabがあります。 GitLabも最近はrpmコマンド一発でインストールできるほど簡単になっていますが、今回はより簡単 (.warファイルを置くだけ) で、見た目や使い勝手もGtiHubに近いGitBucketを選びました。

概要

• ソースからのビルドは行わず、yumパッケージや.warファイルを使用
• Apacheのmod_proxy_ajpを使い、Tomcatへはポート8080ではなく80でアクセス
• GitBucketでリポジトリにpushがあったらJenkinsで自動ビルド
• Jenkinsのビルドでは、rsyscでApacheの公開ディレクトリに自動デプロイ
• 自動デプロイ時のユーザーはtomcatではなくapacheで行う

動作環境

CentOS 7のミラーサイト一覧で、日本のミラーから最新版をダウンロードしてください。 Vagrantで起ち上げた仮想マシンやDockerのコンテナでも構いませんが、一部読み替えたり、ポートマッピング等の追加設定が必要になります。

リポジトリの準備

デフォルトではパッケージが少なかったり古かったりするので、EPELとremiのリポジトリを追加します。

EPELリポジトリの追加

yum install -y epel-release

remiリポジトリの追加

rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

パッケージのインストールと起動設定

とりあえずは最新の状態にしておきます。

yum -y update

必須パッケージに加え、普段よく使うパッケージも入れておきます。

yum --enablerepo=epel,remi install -y sudo vim-enhanced syslog httpd httpd-devel php php-devel php-pear php-mysql php-gd php-mbstring php-pecl-imagick mariadb-server phpmyadmin wget git java-1.7.0-openjdk-devel tomcat

各種サービスを起動し、さらに再起動時にもサービスが有効になるように設定します。

CentOS 6まではservice(または/etc/rc.d/init.d/のスクリプト)とchkconfigコマンドを使用しましたが、CentOS 7ではsystemctlに変更されています。

systemctl enable --now httpd
systemctl enable --now tomcat
systemctl enable --now mariadb

サービスの状況は以下のコマンドで確認できます。

systemctl list-unit-files

GitBucketをインストール

先述の通り、.warファイルを置くだけの簡単インストールです。

https://github.com/gitbucket/gitbucket

releaseから最新版のgitbucket.warをダウンロードして、実行用のディレクトリにコピーします。

cp gitbucket.war /var/lib/tomcat/webapps/

Jenkinsをインストール

こちらも.warファイルを置くだけです。

りゅう

簡単でいいですね！

https://jenkins.io/

最新版のJava Web Archive (.war)をダウンロードして、以下のディレクトリにコピーします。

cp jenkins.war /var/lib/tomcat/webapps/

ここでTomcatを再起動しておきます。

systemctl restart tomcat

ファイアウォールの設定

CentOS 6まではiptablesを使用しましたが、CentOS 7ではfirewalldに変更されています。

firewall-cmd --add-port=80/tcp --permanent

Apacheのプロキシ設定

AJPというプロトコルによって、ApacheとTomcatの相互通信を行い、外部への配信はApacheが担当するようにします。

TomcatのAJP通信は、ポート8080ではなく8009を用います。

以下のファイルを作成します。

/etc/httpd/conf.d/gitbucket.conf

<Location /gitbucket>
    ProxyPass ajp://localhost:8009/gitbucket
</Location>

/etc/httpd/conf.d/jenkins.conf

<Location /jenkins>
    ProxyPass ajp://localhost:8009/jenkins
</Location>

ファイルを作成したら、Apacheを再起動しておきます。

systemctl restart httpd

アクセスしてみる

まずはGitBucketにアクセスしてみます。

http://[hostname]/gitbucket

• ユーザー名：root
• パスワード：root

ログイン後はrootのパスワードを変更し、新規ユーザーを作成しておきます。

次にJenkinsにアクセスしてみます。

http://[hostname]/jenkins

正常に起動し、アクセスできました。

Jenkinsにプラグインをインストールする

「Jenkinsの管理」→「プラグインの管理」→「利用可能」へと進みます。

フィルタに「git」と入力して、以下のプラグインを選択して「再起動後にインストール」します。

• Git Plugin
• GitBucket Plugin

必要なプラグインがインストールされますので、「インストール完了後、ジョブがなければJenkinsを再起動する」にチェックを入れて待ちましょう。

長時間インストールが終わらない場合、実は既に終っているのに表示に変化がないだけということもあります。

GitBucketとJenkinsの連携設定

GitBucketのリポジトリを作成し、pushがあった際にJenkinsで自動デプロイを行うよう設定します。

GitBucket の設定

画面右上のレンチ型アイコンから設定画面へ進み、「System Settings」を選択します。

GitBucketでリポジトリを作成する

「new repository」からリポジトリ名を入力、「Initialize this repository with a README」にチェックを入れて新規リポジトリを作成します。

これで、リポジトリのトップページに表示されるREADME.mdのみがInitial commitされた状態になります。

次にリポジトリの「Settings」→「Service Hooks」と進み、「WebHook URLs」を入力します。

http://[hostname]/jenkins/gitbucket-webhook/

GitBucket側での設定は、このWebHookのみです。

apacheユーザーでデプロイするための設定

普通にデプロイの設定をすると、ファイル群はtomcatユーザーのままデプロイされます。
これだとApache的に都合が悪い場合もあるため、デプロイをapacheユーザーで行うようにします。

そのためには、Jenkinsを動かしているtomcatユーザーが、sudo -u apacheできるようにしなければなりません。

visudo

▼ 変更前

Defaults    requiretty

▼ 変更後（コメントアウトする）

$ Defaults    requiretty

さらにtomcatユーザーがパスワード無しでsudoできるよう設定します。

以下の行を追加

tomcat  ALL=(ALL)       NOPASSWD: ALL

そして、デフォルトでは/var/www/htmlの所有者がrootになっており、このために自動デプロイが失敗するので、権限を変更しておきます。

chown -R apache. /var/www/html

Jenkinsの自動デプロイ用ジョブを作成

新規ジョブ作成から、ジョブ名を入力 (例：project01)、「フリースタイル・プロジェクトのビルド」を選択してOKをクリックします。

りゅう

GitBucketのリポジトリページからコピペできる項目が多いです。

最後に「ビルド手順の追加」から「シェルの実行」を選択し、下記シェルスクリプトを記入します。割とここが目玉です。

sudo -u apache rsync -vr --delete --exclude ".git/" /usr/share/tomcat/.jenkins/jobs/project01/workspace/ /var/www/html/project01/

動作確認

gitコマンド、またはお使いのGitクライアントから、ファイルに適当な修正を加えてコミット → プッシュしてみてください。

※尋ねられるアカウントは、GitBucketのユーザーアカウントです。

GitBucketでは、GitHub同様にコミット履歴が加わっていれば成功です。こちらはまず大丈夫でしょう。

Jenkinsでは、リポジトリに対応するジョブが実行されて、/var/www/html以下に自動デプロイが行われたことを確認できればOKです。

CentOS 6で構築する場合

CentOS 6でも同様に、まずyumのリポジトリとしてEPELとremiをインストールします。

Tomcat 7もインストールできるため、一部CentOS 7独特の部分 (systemctlやファイアウォール等) 以外はそのまま進められます。

しかしJenkinsのGit Pluginがエラーを吐きます。

りゅう

これはCentOS 6にyumでインストールしたGitのバージョンが、1.7.1等の古いバージョンだからです。

解決するためには、最新のソースからGitをインストールすることです。

古いGitを削除

yum remove -y git

必要になるパッケージをあらかじめインストール

yum install -y curl-devel expat-devel gettext-devel openssl-devel zlib-devel

新しいGitのソースファイルをダウンロード

wget https://git-core.googlecode.com/files/git-1.9.0.tar.gz

解凍してインストール

tar zxf git-1.9.0.tar.gz
cd git-1.9.0
./configure --prefix=/usr/local/
make
make install

もし/usr/local/binにPATHが通っていなければ、下記のように.bash_profileに追加しておいてください。

.bash_profile

PATH=$PATH:/usr/local/bin

export PATH

そして上記変更を適用します。

source ~/.bash_profile

一応Gitのバージョンを確認しておきましょう。

git --version

これでJenkinsもエラーを吐くこと無く動作するはずです。

CentOS 7で採用されたApache 2.4の設定は従来とかなり変わっており、そのせいで戸惑うこともあるかと思いますので、馴染めない方は、少々面倒ですが上記の方法でCentOS 6上で構築してみるのも良いかと思います。