目次
はじめに
普段、Vagrantで仮想マシンを作成する場合にCentOSを使用しています。
データベースなどのミドルウェアや、開発言語の最新バージョンをインストールする際に、ソフトウェアごとに別々のリポジトリを参照する必要があり、何でこんなに煩雑なのかと悩んでいました。そんな時、見つけたのがソフトウェアコレクションです。
結論から言ってしまうと、これも煩雑でした。ただし、一つのリポジトリから全てをインストールするので、複数のリポジトリ時にあった、両方に同じソフトウェアのパッケージがあって更新頻度が違うけど、どっち使えば良いの?と悩まなくて済みます。
また、ソフトウェアコレクション内のパッケージで連携が取れているので、インストール後の手順が少なくて済みます。ただし固有の知識が必要な部分もあります。
色々試して資料が溜まったので、ソフトウェアコレクションの成り立ちから利用法までを、まとめていきます。
一次情報のほとんどが英語なので誤認しているかもしれません。ん、違うかな?と思ったら参照したサイトへのリンクから詳細を確認してください。
ソフトウェアコレクションとは
Software collections(SCL)のルールに従って作られたRPMパッケージにより提供されるソフトウェアです。
SCLは、サポート期間が長くなったRed Hat Enterprise Linux(RHEL)とは別のライフサイクルで、安定した最新バージョンのソフトウェアをインストールする方法として提供された、Red Hat Software Collections 1.0が始まりです。
Red Hat Software Collections 1.0は、RHELサブスクリプションを介して提供され、他ディストリビューションで利用するものではありませんでした。約半年でRHEL用のRed Hat Software Collections 1.0は廃止され、RHEL、CentOS、Fedora向けのSCLを作成、ホスティング、提供するプロジェクトSoftwareCollections.orgがRed Hatから発表されました。
参照:Announcing SoftwareCollections.org
ディストリビューションごとの対応状況
- Red Hat Enterprise Linux
Red Hat Software CollectionsはRed Hatにより維持、管理されています。 - CentOS
CentOSのコミュニティ(Software Collections SIG)により維持、管理されています。Red Hat Software Collections由来のパッケージと、CentOS独自のパッケージが提供されています。 - Fedora
Fedoraでは2015年6月頃からSoftware Collectionsは非推奨となっています。理由はFHSに違反する階層にファイルを格納するためです。SCLは/opt
以下にインストールされ、設定ファイルやログファイルの位置も固有の場所に格納されます。Fedora公式サイトのwikiにメッセージがあります。
利用方法
CentOSでSoftware Collections(SCL)を利用する手順は以下の通りです。
(Red Hat Enterprise Linuxはサブスクリプションの契約が必要なので、CentOSのみの説明になります)
参照:softwarecollections.org – Quick Start – Using Software Collections
- リポジトリの登録
- インストール
- 有効化
リポジトリの登録
CentOSが公開しているSCLリポジトリは2つありますが、centos-sclo-rhだけで十分です。
centos-sclo-rh
Red Hat Software Collections 由来(Upstream)のSCLパッケージのみを提供します。
リポジトリ:http://mirror.centos.org/centos/7/sclo/x86_64/rh/centos-sclo-sclo
CentOS Software Collections SIGのSCLパッケージを提供します。
リポジトリ:http://mirror.centos.org/centos/7/sclo/x86_64/sclo/
リポジトリの登録を行うパッケージcentos-release-scl-rh
が、extrasリポジトリから提供されているので、yum
コマンドでインストールすれば登録できます。
$ sudo yum install centos-release-scl-rh
$ yum repolist -q
repo id repo name status
base/7/x86_64 CentOS-7 - Base 9,591
centos-sclo-rh/x86_64 CentOS-7 - SCLo rh 6,640
extras/7/x86_64 CentOS-7 - Extras 388
updates/7/x86_64 CentOS-7 - Updates 1,929
インストール
例としてGit2.9をインストールします。パッケージ名はrh-git29
です。
$ sudo yum install rh-git29
有効化
参照:softwarecollections.org – Packaging Guide – 1.6. Enabling a Software Collection
インストールだけではパスなどの環境変数が設定されないため有効化する必要があります。
有効化には2つの方法があり、scl
コマンドかscl_source
スクリプトを使用します。
scl
コマンド
複数のバージョンを切り替えて利用する際に、一時的に有効化する方法です。scl_source
スクリプト
バージョンの切り替えをせず最新バージョンを利用したい場合に、手入力でのコマンド実行以外に、rcファイルに記述して有効化します。
sclコマンド
$ scl enable rh-git29 "git --version"
git version 2.9.3
書式
scl <アクション> <[ソフトウェアコレクション]...> <コマンド>
アクション
enable
指定されたソフトウェアコレクションを有効化します。このenableだけが全てのSCLが共通で持つアクションで、他はSCLごとに異なります。ソフトウェアコレクション
有効化したいソフトウェアコレクションを1つ以上指定します。$ scl enable rh-git29 rh-php71 "git --version && php -v"
コマンド
指定されたソフトウェアコレクションが有効化された環境で実行するコマンドを指定します。引数を伴う場合は、"で括ります。
コマンドにbash
を指定するとソフトウェアコレクションが有効化された環境のサブシェルが起動します。
scl_sourceスクリプト
$ source scl_source enable rh-git29
$ git --version
git version 2.9.3
書式
source scl_source enable <[ソフトウェアコレクション]...>
- ソフトウェアコレクション
有効化したいソフトウェアコレクションを1つ以上指定します。
このスクリプトは現在のシェルで有効化します。ただし、無効化する手段はありません。また、同じソフトウェアコレクションを指定して複数回実行しても、有効化済みのものは無視されるので問題ありません。
サービスの操作
Apache httpdやmysqldのようなサービスを提供するSCLの場合は、ユニット名が異なりますがsystemctl
コマンドによりサービスの操作ができます。
例としてApache httpd 2.4の起動と終了、自動起動の設定を行います。
まず、Apache httpd 2.4をインストールします。パッケージ名はhttpd24
です。
$ sudo yum install -y httpd24
起動
ユニット名はhttpd24-httpd
です。( 拡張子の.sevice
は省略できます)
$ sudo systemctl start httpd24-httpd
終了
$ sudo systemctl stop httpd24-httpd
自動起動の設定
SCLはサービスが自動起動しないのデフォルトの設定なので後から自動起動を有効にします。
$ sudo systemctl enable httpd24-httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd24-httpd.service to /usr/lib/systemd/system/httpd24-httpd.service.
考察
SCLの有効化について
sclコマンド
softwarecollections.org – Packaging Guide – 1.6. Enabling a Software Collectionの説明では、scl
コマンドはソフトウェアコレクション(SCL)を有効化した子プロセス(サブシェル)を生成し、そのサブシェルで指定されたコマンドを実行すると書かれています。
確認のために以下のコマンドを実行すると、scl
コマンドが、bash
を子プロセスとして実行し、孫プロセスとして指定されたコマンドが実行されていることが分かります。
$ scl enable rh-git29 "ps x --forest"
PID TTY STAT TIME COMMAND
2757 ? S 0:00 sshd: vagrant@pts/0
2758 pts/0 Ss 0:00 \_ -bash
4940 pts/0 S+ 0:00 \_ scl enable rh-git29 ps x --forest
4941 pts/0 S+ 0:00 \_ /bin/bash /var/tmp/sclwWoApD
4944 pts/0 R+ 0:00 \_ ps x --forest
コマンドが終了するとサブシェルが終了し、最初のシェルに戻ります。
コマンドにbash
を指定すると、SCLを有効化したシェルを実行できます。この時のプロセスの状態は以下のようになります。
$ ps x --forest
PID TTY STAT TIME COMMAND
2757 ? S 0:00 sshd: vagrant@pts/0
2758 pts/0 Ss 0:00 \_ -bash
4999 pts/0 S 0:00 \_ scl enable rh-git29 bash
5000 pts/0 S 0:00 \_ /bin/bash /var/tmp/sclNIanBO
5003 pts/0 S 0:00 \_ bash
5020 pts/0 R+ 0:00 \_ ps x --forest
現在のシェルで有効なSCLは環境変数X_SCLS
で確認します。
$ echo $X_SCLS
rh-git29
scl_sourceスクリプト
現在のシェルでSCLを有効化するscl_source
スクリプトを、scl
コマンドの状態と比べてみます。
$ source scl_source enable rh-git29
$ echo $X_SCLS
rh-php71
$ ps x --forest
PID TTY STAT TIME COMMAND
2757 ? S 0:00 sshd: vagrant@pts/0
2758 pts/0 Ss 0:00 \_ -bash
5114 pts/0 R+ 0:00 \_ ps x --forest
余計な子プロセスが起動していない事が分かります。ただし、現在のシェルだけで有効なのでOSが起動するプロセスでは無効なままです。
サービスの起動はどう行われているのか?
ソフトウェアコレクションとしてインストールした、Apache httpdなどのサービスもsystemdのルールに従って設定が行われています。ユニット名が異なるだけでsystemctl
コマンドで制御できます。
実行ファイルへのパスなどscl
コマンドで行なっていた有効化を、どうやって解決しているのかが気になります。
通常のパッケージが提供するユニットの設定ファイルは/usr/lib/systemd/system/
以下に配置されます。ソフトウェアコレクションでも、ユニット名が異なり衝突することがないので、SCL固有の特殊な階層にはなっていません。
ユニットの設定ファイル
httpd24の設定ファイルはhttpd24-httpd.service
で、内容は以下の通りです。
$ cat /usr/lib/systemd/system/httpd24-httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/opt/rh/httpd24/root/etc/sysconfig/httpd
ExecStart=/opt/rh/httpd24/root/usr/sbin/httpd-scl-wrapper $OPTIONS -DFOREGROUND
ExecReload=/opt/rh/httpd24/root/usr/sbin/httpd-scl-wrapper $OPTIONS -k graceful
ExecStop=/opt/rh/httpd24/root/usr/sbin/httpd-scl-wrapper $OPTIONS -k graceful-stop
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
ラッパースクリプト
ユニットの設定ファイルから、サービスの操作(ExecStart
,ExecReload
,ExecStop
)を行うためのラッパースクリプトが絶対パスで指定されているのが分かります。/opt/rh/httpd24/root/usr/sbin/httpd-scl-wrapper
の内容は以下の通りです。
$ cat /opt/rh/httpd24/root/usr/sbin/httpd-scl-wrapper
#!/bin/sh
# We have to re-enable SCL environment, because /sbin/service
# clears almost all environment variables.
# Since X_SCLS is cleared as well, we lose information about other
# collections enabled.
. /opt/rh/httpd24/service-environment
for sclname in $HTTPD24_HTTPD_SCLS_ENABLED ; do
. /opt/rh/$sclname/enable
export X_SCLS="$X_SCLS $sclname"
done
exec /opt/rh/httpd24/root/usr/sbin/httpd "$@"
SCLの有効化で利用されるスクリプト(/opt/rh/$sclname/enable
)が実行されています。
ソフトウェアコレクションでインストールしたサービスは、サービスの操作内でラッパースクリプトによりSCLの有効化が行われているのが分かりました。
まとめ
ソフトウェアコレクション(SCL)についてイメージが掴めてきました。
取り敢えず、Red Hat Enterprise LinuxでSCLの利用が廃止されたり、Fedoraみたいに非推奨にならない間は、CentOSでSCLを利用できそうです。
ここから実際に使える環境を構築してSCLを利用した場合の手法を調べていきます。