オープンソースこねこね

Webプログラミングなどについてあれこれ。

OmnibusでPHPアプリケーションをRPMにパッケージングする

要約: Omnibusを使うとApachePHPをバンドルしたオールインワンなPHPアプリケーションのRPMパッケージを作れます。

最近CLIツールやAPIサーバなどはGoで書くようになって、PHPをさわる頻度が減ってきているのですが、それでもPHPの実行環境が不必要になることはなく、その個人的な一つの理由にAdminerがあります。これは2012年に一度ブログにも書いたのですが、PHPのシングルファイルをDocumentRootにおくだけで動作する、データベース用のWebUIです。

Adminer - PHPの1ファイルを置くだけで簡単に使えるDB管理ツール - オープンソースこねこね

現在でもメンテは続いているようで、今ではElasticsearchやMongoDBなどにも対応しているそうな。個人的にもずっと使い続けています。

ただ、前述のようにGoの適用範囲が広がってきたので、新しく立ち上げたサーバとかだと、Adminerを使う以外にApachePHPが必要ない環境もあります。後々の運用管理のことも考えてサーバ構築にはプロビジョニングツールを使っていることもあり、これ一つのために、ApachePHPを入れてhttpd.confとphp.iniを書き換えるレシピ書いて。。。てなことがやや面倒くさいです。

Adminerの機能単体でぱっとインストール、アンインストールできればいいかもしれない、と考えたので、omnibusを使ってApachePHPをバンドルしたオールインワンなPHPアプリケーションのRPMを作成してみました。omnibusについては以前ブログに書いたのでそちらを参照してください(CentOS用にSupervisor3.3.0のRPMパッケージを作成した - オープンソースこねこね )。今回の成果物は以下

github.com

Githubのリリースページに生成したRPMをあげたので

$ sudo yum install https://github.com/kohkimakimoto/omnibus-adminer-server/releases/download/v0.3.0/adminer-server-0.3.0-1.el7.x86_64.rpm

でインストールできます。これだけで/opt/adminer-serverApachePHPランタイムを含めたアプリケーションがインストールされます。これらはもちろんシステムワイドにあるApachePHPとは干渉しません。あとは、

$ sudo systemctl start adminer-server

とすればApacheが14200ポートで起動しますのでブラウザでhttp://localhost:14200/adminer.phpにアクセスすると

f:id:kohkimakimoto:20170329115005p:plain

と画面がでます。

補足

  • サービス設定は現状systemdのみの対応なので、このRPMはCentOS7限定です。initスクリプトを書けばCentOS6などにも対応できますが、自分が使わないので書いてません。
  • 設定ファイルは/etc/adminer-server、adminer.phpなどのPHPファイルは/var/lib/adminer-server以下に配置してあります。
  • 今回はやってないがMySQLなどDBもバンドルすれば、いわゆるLAMPアプリケーションがパッケージ配布可能になるんじゃないかと。

あとがき

こんなことしなくても、今はDocker使えばいいかも、とも思いますが、Systemdにサービスを登録するところまでyum installlでできるのでミドルウェア的なものを扱うのなら、RPMも便利ですよと。。。

テストやビルドスクリプトをDockerコンテナで実行させるための便利ツールを作った

ある程度複雑なプログラムだと、ローカル環境やCIサーバ環境など、どこでも動くようにテストを書くのが難しくなったりします。また、昨今のWebアプリケーションだと、デプロイ前に何らかのビルドプロセスが必要になることがほとんどで、依存物をインストールしたり、Webpackを動かしたり、Goのビルドを走らせたりします。こういうタスクもnodeやらGoに依存していて、複数の環境で差異なく動かすことを考えると、いろいろツライものがあります。

そこで、こういったテストやビルド処理はシェルスクリプトを書いて、Dockerコンテナ内で動かすことによって環境に対しての依存を解消していました。 たとえばGo言語の場合以下のようなテスト実行スクリプトtest_run.shを書いておきます。

#!/usr/bin/env bash
set -eu

go test $GOTEST_FLAGS $(go list ./... | grep -v vendor)

そしてこれをDockerコンテナで実行するためのスクリプトとして以下のようなtest.shを書きます。

#!/usr/bin/env bash
set -eu

DOCKER_IMAGE=${DOCKER_IMAGE:-'kohkimakimoto/golang:centos7'}
GOTEST_FLAGS=${GOTEST_FLAGS:--cover -timeout=360s}

repo_dir=$(cd $(dirname $0); pwd)

docker run \
  --env GOTEST_FLAGS="${GOTEST_FLAGS}" \
  -v $repo_dir:/build/src/github.com/username/repo \
  -w /build/src/github.com/username/repo \
  --rm \
  ${DOCKER_IMAGE} \
  bash ./test_run.sh

goコマンドなど、テストに必要な環境は全てDockerイメージとして用意しておきます。あとはリポジトリのルートにいる状態で./test.shを実行すれば、テストが実行されます。TravisCIのようなCIサーバはDockerに対応しているので、同様に./test.shを実行するだけで、ローカル環境と同じようにテストが実行できます。テストコード側で環境の違いを意識する必要はなくなります。

ところで、しばらくこの方式でやっていたところ、以下のような課題が浮き彫りになってきました。

  • 新しいプロジェクトごとにシェルスクリプトをコピペ、修正して使いまわしている。
  • これらのスクリプトはだいたい似たようなコードになりがちだが、利用するDockerイメージやdocker runのオプションなどが微妙にちがう。
  • テストやビルドなど個々のタスクごとに「実際のタスクを実行するスクリプト」と「それをDockerコンテナで実行するスクリプト」の2つのファイルを作る必要があり、数が増えるとファイルがごちゃごちゃしてきた。

ベタに書いたシェルスクリプトによる実装なので、プロジェクトが増えると、共通化などができずコードが冗長になりがちでした。そこで、大雑把に処理を整理してみると

  • カレントディレクトリをDockerコンテナの特定の場所にマウントする
  • --rmオプションをつけて、コンテナ停止後自動でコンテナを削除するようにする
  • スクリプトを実行する。

などが共通な処理であったので、これらをまとめて、いい感じにDockerコンテナを起動してその中でスクリプトを実行するコマンドラインツールを作りました。

github.com

Goで実装したシングルバイナリなので、Githubのリリースページからバイナリをダウンロードして、パスの通ったディレクトリに配置すればすぐに使えます。

使い方

まずは単純に

$ buildsh

を実行してみます。これだけで、デフォルトでDockerイメージkohkimakimoto/buildsh:latest(2Gくらいあります)をダウンロードして、カレントディレクトリをコンテナ内の/buildにマウントした状態でコンテナを起動します。そのままbashでログインした状態になるので、たとえばPHPのテストだったら

$ php phpunit

などを実行すればテストができます。PHPPython,nodeなど主なLLのランタイムを入れてあるので、ホストマシンの環境に関係なくすぐにテストやビルドができます。作業が終わったら

$ exit

すれば、ホストマシンにもどってコンテナが破棄されます。特定の環境でちょっとしたことを動作確認したい場合などに便利に使えます。

そしてテストやビルドのシェルスクリプトを実行させたい場合は

$ buildsh test.sh

のようにスクリプトファイルを指定して実行すれば、そのスクリプトがDockerコンテナ内で実行されます。これで用意するスクリプトはテストを実行する部分のみでよくなり、「それをDockerコンテナで実行するスクリプト」を書く必要がなくなりました。

設定ファイル

使用するDockerイメージを変更したい場合などは、設定ファイルを利用することができます。.buildsh.ymlをカレントディレクトリに配置してください。以下のような設定ができます。

use_cache: true
docker_image: kohkimakimoto/buildsh:latest
additional_docker_options: --net=host -v=/var/run/docker.sock:/var/run/docker.sock
environment:
  FOO: bar
  FOO2: bar2
home_in_container: /build/src/github.com/kohkimakimoto/buildsh

詳細はREADME.mdを参照していただくとして、いくつかピックアップして概要を説明します。

use_cache

use_cacheはtrueにするとカレントディレクトリ配下に.buildsh/cacheディレクトリを作り、コンテナ内でパスを環境変数BUILDSH_CACHEDIRに設定します。これはスクリプト実行ごとに破棄されてしまうコンテナ内のデータを保存するときに使うことができます。たとえばyarn installを以下のようにすれば、キャッシュを保持できて、次回以降の処理の高速化が望めます。

$ yarn install --cache-folder=$BUILDSH_CACHEDIR/yarn

.gitignore.buildshを追加するのを忘れずに。。。

docker_image

docker_imageは利用するDockerイメージです。自分の用途に合わせて好きなイメージを使えます。

additional_docker_options

additional_docker_optionsは内部で実行しているdocker runに付け加えるオプションを指定できます。例のように-v=/var/run/docker.sock:/var/run/docker.sockを利用すればDockerコンテナ内から新しくDockerコンテナを立ち上げることもできたりします。

home_in_container

home_in_containerはコンテナ内でホストのカレントディレクトリがマウントされるパスを変更できます。デフォルトは/buildですが、例えばGoのテストやビルドをおこなうとき、GOPATHの関係上/build/src/github.com/kohkimakimoto/buildshのようにGOの流儀にそったパスに配置したいことがあります。この設定を使うことでそのようなケースに対応できます。

実装について

このツールはつまるところ、テストやビルド目的の使い捨てコンテナである場合docker runにセットするオプションや引数がおおむね共通化できるので、それをまとめたラッパーコマンドというわけです。

もともとはbashスクリプトで書いていたこともあって、実装は単純なdocker runのラッパーコマンドになっているので、メインのコードはbuildsh.goのみです。なのでをこれを見れば何をやっているのか大体わかりますので、細かいことはソースを見たほうが早いかもしれません。

mattn/memoのzsh補完

Golang実装のメモコマンド

Big Sky :: golang でメモ専用コマンド「memo」作った。

GitHub - mattn/memo: 📓 Memo Life For You

が便利だったので、雑にzsh補完を書きました。

_memo_options() {
    local -a __memo_options
    __memo_options=(
        '--help:show help'
        '-h:show help'
        '--version:print the version'
        '-v:print the version'
     )
    _describe -t option "option" __memo_options
}

_memo_sub_commands() {
    local -a __memo_sub_commands
    __memo_sub_commands=(
     'new:create memo'
     'n:create memo'
     'list:list memo'
     'l:list memo'
     'edit:edit memo'
     'e:edit memo'
     'delete:delete memo'
     'd:delete memo'
     'grep:grep memo'
     'g:grep memo'
     'config:configure'
     'c:configure'
     'serve:start http server'
     's:start http server'
     'help:Shows a list of commands or help for one command'
     'h:Shows a list of commands or help for one command'
     )
    _describe -t command "command" __memo_sub_commands
}

_memo_list() {
    local -a __memo_list
    PRE_IFS=$IFS
    IFS=$'\n'
    __memo_list=($(memo list))
    IFS=$PRE_IFS
    _describe -t memo "memo" __memo_list
}

_memo () {
    local state line

    _arguments \
        '1: :->objects' \
        '*: :->args' \
        && ret=0

    case $state in
        objects)
            case $line[1] in
                -*)
                    _memo_options
                    ;;
                *)
                    _memo_sub_commands
                    ;;
            esac
            ;;
        args)
            last_arg="${line[${#line[@]}-1]}"

            case $last_arg in
                edit|e|delete|d)
                    _memo_list
                    ;;
                *)
                    ;;
            esac
            ;;
        *)
            _files
            ;;
    esac
}
compdef _memo memo

~/.zshrcとかにコピペして使ってください。

※2017-02-10 追記: 本家リポジトリに取り込んでもらいました。https://github.com/mattn/memo/blob/master/misc/completion.zsh

systemd-nspawnで/sys/fs/selinuxがマウントできないので警告される件は無視することにした

ただのメモです。

CentOS7でsystemd-nspawnの動作を検証してるなか、SELinuxを無効にした状態でコンテナを起動させると/sys/fs/selinuxがマウントできないと警告がでてきました。

# systemd-nspawn -D /var/tmp/mycontainer 
Spawning container mycontainer on /var/tmp/mycontainer.
Press ^] three times within 1s to kill container.
Failed to create directory /var/tmp/mycontainer//sys/fs/selinux: No such file or directory
Failed to create directory /var/tmp/mycontainer//sys/fs/selinux: No such file or directory
-bash-4.2# 

/sys/fs/selinuxSELinuxを無効にすると存在しないディレクトリ。調べたらsystemd-nspawnはHAVE_SELINUXマクロでこのディレクトリのマウントを制御しています

systemd/nspawn.c at v219 · systemd/systemd · GitHub

そしてログを出力しているところはココ

systemd/nspawn.c at v219 · systemd/systemd · GitHub

ソースを見る限りその後の処理は続行しているし、問題なさそうかな〜と考えていたら、

systemd-nspawn: dont try to mount non existing selinux directories by tblume · Pull Request #4569 · systemd/systemd · GitHub

で、同様の問題の当たっていたヒトがこの警告を消すためにログレベルをLOG_DEBUGからLOG_WARNINGにさげるPRを送っていてmasterにマージされていました。なので、今後CentOS(systemd)のバージョンが上がれば、この警告は消えるので、現状無視することにした、というお話でした。

CentOS7でサーバを構築する際におこなっている基本設定

以前書いた

CentOS6でサーバを構築する際におこなっている基本設定 - オープンソースこねこね

のCentOS7バージョンです。調査中の内容もあるので、情報は随時更新する予定です。

※ここではサーバのロールにかかわらず行う基本的な作業をまとめています。通常この環境の上にWebサーバ(httpd, nginxなど)やDB(MySQLなど)をインストールすることになります。

※本文中のコマンドは基本的にrootユーザで行っているものとします。一般ユーザを使い必要に応じて都度root権限を使うようにしている方はsudoをつけるなど、コマンドを読み替えてください。

デフォルトターゲットの確認

systemctl get-defaultで取得。CentoOS6までのデフォルトランレベルに相当します。

# systemctl get-default
multi-user.target

multi-user.targetになっていることを確認します。

サービスの起動設定の確認

サービスの管理はsystemdによる管理に刷新されています。

systemctl list-unit-filesでサービスの一覧と状態を取得します。

# systemctl list-unit-files --type service --no-pager
UNIT FILE                                   STATE   
arp-ethers.service                          disabled
auditd.service                              enabled
auth-rpcgss-module.service                  static  
autovt@.service                             disabled
blk-availability.service                    disabled
brandbot.service                            static  
chrony-dnssrv@.service                      static  

STATEの意味は以下の通り。

  • enable: 自動起動有効
  • disabled: 自動起動無効
  • static: 他のユニットに依存。有効/無効が設定できないもの。

不要と思われるサービスはサーバリソースの無駄使いになるので、以下のコマンドで停止設定にしておきます。

# systemctl disable nginx.service
# systemctl stop nginx.service

OSの起動時に実行させたいサービスは

# systemctl enable nginx.service
# systemctl start nginx.service

としておきます。

ディクスサイズの確認

# df -h

サーバスペックにあったディクスサイズになっていることや、パーティションを確認します。

ロケールの設定

現在のロケールの設定を確認します。

# localectl status

利用可能なロケールlocalectl list-localesを調べ、

# localectl list-locales --no-pager

localectl set-localeで変更。

# localectl set-locale LANG=ja_JP.utf8

ロケールを日本語にしたとき、manページを日本語にするために

# yum install man-pages-ja

をインストールします。

タイムゾーンとNTPの設定

現在のタイムゾーンを確認します

# timedatectl status

利用可能なタイムゾーンtimedatectl list-timezonesで調べます

# timedatectl list-timezones --no-pager

timedatectl set-timezoneで変更。

# timedatectl set-timezone Asia/Tokyo

RTC in local TZ: yesの設定になっていると警告がでるので以下を設定する

# timedatectl set-local-rtc 0

CentOS7では時刻同期サービスが2つあって従来のntpdと新しいchronydがある。最小構成でOSインストールした場合は chronydだけがインストールされている状態になっているはず。それぞれ設定ファイルは

/etc/chrony.confまたは/etc/ntp.confです。設定ファイルのフォーマットはほとんど同じなので

server 0.centos.pool.ntp.org iburst

のような、時刻問い合わせ先サーバの設定を確認します。

# systemctl start ntpd.service
or
# systemctl start chronyd.service

でサービスを起動します。

最後にtimedatectlでntpによる時刻合わせを有効化します。

# timedatectl set-ntp yes

ネットワーク関連の設定

CentOS7ではネットワーク周りの管理がNetworkManagerを使った方式に変更されています。 NetworkManagerのコマンドラインインターフェースであるnmcliを使って設定するのが標準の方法ですが、 ひとまず従来CentOS6の方法でできることは、それを踏襲してます(非推奨の方法だと思うので、のちのち更新予定です)。

まず、従来のifconfigなどがデフォルトでは提供されていないのでnet-toolsパッケージをインストールします。

# yum install net-tools

ホスト名

従来/etc/sysconfig/networkに記載していたホスト名はCentOS7では/etc/hostnameに記述します。

ネットワーク・インターフェースの確認

CentOS6のときと同様に/etc/sysconfig/network-scripts配下のifcfg-xxxを確認します。 設定を変更したら、

systemctl restart network

で反映させます。

IPアドレスの確認

# ifconfig

IPアドレスの設定が、設定通りか確認します。

ネットワークの疎通確認

# ping yahoo.co.jp

pingが外に向けて通るかを確認します。0% packet lossとなればOK。

# traceroute yahoo.co.jp

外につなぎに行く際にどのようなIPを経由するかを確認。ネットワーク管理者ではないので、ざっと結果を眺めるだけです。

yumリポジトリ

CentOS6のときと同様。epelとremiは(個人的に)必須なのでインストールします。epelは直接yumからインストールできます。

# yum install epel-release
# yum install http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

その他、設定ファイルなどはCentOS6のときと同様。

bash-completion

CentOS6のときと同様。素のbashのままだとzshになれた補完脳にはツライので、bash-completionを入れます。

# yum install bash-completion

インストールするだけで、ある程度補完が効くようになります。カスタマイズは特にしていません。

ファイアウォール (firewalld)

ファイアウォールiptablesからfirewalldに変わりました。 firewalldはiptablesをバックエンドにしたファイアウォール管理のフロントエンド的なもので、実は内部的にはiptablesが依然使われています。とはいえ、設定に関してはやることがガラっと変わっています。

設定のための覚書

firewalldにはゾーンという概念があり、サービスやポートへの接続許可、拒否などの設定をまとめた単位。ゾーンはデフォルトで

  • block
  • dmz
  • drop
  • external
  • home
  • internal
  • public
  • trusted
  • work

があります。ファイアウォールはこのゾーンをNICに割り当てることで、有効化され、機能します。 デフォルトではpublicゾーンが、有効化、割り当てされています。

# firewall-cmd --list-all

で確認できます。ゾーンについては

# firewall-cmd --list-all-zone

で一覧がでます。

デフォルトで有効になっているpublicゾーンは、明示的に許可した通信しか受け入れないようになっているので、基本的にこのゾーンに接続許可するポートやサービスの設定をしておけば、普通のファイアウォールの用途としては要件を満たせそうです。設定はfirewall-cmdを実行することで行います。

設定

いくつか典型的な設定パターンをメモしておきます。

特定の接続先(この例では192.168.0.1/24)からのみサービスへの接続(この例ではSSH)を許可する場合:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.0.1/24" service name="ssh" accept' --permanent

サービスの定義は/usr/lib/firewalld/services/配下にあるxmlファイルを読む。ポート番号などがここに定義されています。

特定の接続先(この例では192.168.0.1/24)からのみポート8000の接続を許可する場合:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.0.1/24" port port="8000" protocol="tcp" accept' --permanent

ポート80の接続を許可する場合:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" port port="80" protocol="tcp" accept' --permanent

ちなみに上記のポートを単純に開放するだけなら

# firewall-cmd --zone=public --add-port=80/tcp --permanent

でも良さそう。個人的に設定の書き方を統一しておきたいので基本的に--add-rich-ruleを使っています。

設定を変更したら

# firewall-cmd --reload

で反映させます。その後確認のために

# firewall-cmd --list-all

でゾーンの設定を表示し、内容をチェックします。

sshd

CentOS6のときと同様。ポート番号を変えて、鍵認証オンリーにします。以下、編集および確認箇所のみを記載します。

/etc/ssh/sshd_config

# 22以外に変えます
Port 2222
# rootログインは禁止
PermitRootLogin no
# パスワード認証は禁止
PasswordAuthentication no

再起動して設定を反映します。

# systemctl restart sshd

ログの管理

syslogに代わる新しいログデーモンとしてjournaldが提供されています。systemdのサービスとして起動されたプログラムの標準出力、標準エラー出力は自動的にjournaldへと送られてログ管理の対象になります。ログはバイナリデータで保存され、専用のjournalctlコマンドを使って検索、表示させるという操作になります。

ログの保存場所はデフォルトで/var/run/log/journal。これは一時領域なので再起動したら消えてしまうため、/var/log/journalに変更する。

# mkdir /var/log/journal
# systemctl restart systemd-journald

上記のように/var/log/journalを作成して、journaldを再起動すればOK。

ログの容量の最大サイズはファイルシステムの10%まで。変更するには/etc/systemd/journald.confないで

SystemMaxUse=500M
RuntimeMaxUse=500M

のようにサイズ指定すればよいです。

参考:http://www.server-memo.net/centos-settings/journald/journald.html

logrotate

ログのローテート設定です。journaldにではなく、サービスが直接ファイルになどに出力したログファイルをローテートします。

CentOS6のときと同様です。ログが無尽蔵に大きくなってディクスサイズを圧迫しないように設定、確認します。 初期設定時の他にhttpdなどのデーモンやログを出力するアプリケーションを追加した時にも目を通します。

/etc/logrotate.d/以下にログの対象ごとに設定ファイルがあるのでそれを確認します。例えばnginxは以下のようになっていたりします。

/etc/logrotate.d/nginx

/var/log/nginx/*log {
    create 0644 nginx nginx
    daily
    rotate 10
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

実際の設定はログのサイズや保存期間の要件などによって異なるので、それを考慮し設定します。

sysctl

CentOS6と同様、カーネルパラメータの設定です。CentOS6のときは/etc/sysctl.confを編集してましたが/etc/sysctl.d/配下にxxx..confファイルを配置しても設定できるので、そうしてます。(実はCentOS6のときからできたっぽいですが。参考:http://qiita.com/ngyuki/items/002a4a153ac6d8075bdb)

/etc/sysctl.d/override.conf

net.nf_conntrack_max = 1000000
net.netfilter.nf_conntrack_max = 1000000
net.core.somaxconn = 1024
vm.overcommit_memory = 1

設定の内容はCentOS6でサーバを構築する際におこなっている基本設定 - オープンソースこねこねを参照。設定値の反映は以下のコマンドを実行します。

# sysctl --system

参考: http://tsunokawa.hatenablog.com/entry/2015/09/02/175619

以下のコマンドで確認。

# sysctl -a

Pythonの開発環境

MacPythonの開発環境を構築したかったので少しばかり調査、試行錯誤しました。調査メモと現時点で落とし所になった構成のまとめ。

調査

モダンなpython開発環境は

  • python: ランタイム本体
  • pip: パッケージの管理コマンド(rubyのgem的な役割)
  • virtualenv: パッケージをディレクトリ単位で管理する仮想環境(rubyのbundler的な役割)
  • pyenv: 複数バージョンのpythonを管理(rbenvとかphpenvとかと同様)
  • pyenv-virtualenv: pyenvでvirtualenvの仮想環境を作成、管理するプラグイン

などが使われる模様。情報ソースは以下のサイトなどなど。

以下のオペレーションを実際にやってみました。

  • pyenvを使ってpythonをインストール
  • virtualenvで仮想環境を構築
  • pyenv-virtualenvで仮想環境を構築

所感。

  • 複数バージョンのpythonは今のところ私には必要ない。pyenvはなくていい。
  • 現状、やりたいことは、開発するときにプロジェクトディレクトリ配下にリソースをまとめたい。グローバルを汚染したくない、ということ。
  • virtualenvディレクトリに入ってからsource bin/activateしないと有効にならない。また出るときはdeactivateが必要。地味にめんどい。
  • pyenv-virtualenvでpyenv管理の仮想環境を作ってpyenv localでローカルの設定をしておけば、ディレクトリ移動で仮想環境が有効になるが、仮想環境自体が~/.pyenv配下に保存されて、インストールパッケージがプロジェクトのディレクトリ配下に配置されない。

いまひとつ不満が解消されないまま、さらに調べていたらいつも使っているdirenvが組み込みの関数でpythonのvirtualenvを構築、ロードに対応していることを発見。

https://github.com/direnv/direnv/blob/c2cfad5ee664fed68224c44fd0549e73615f6b79/stdlib.sh#L352

試してみたらいい感じだったので、現状これとhomebrewでインストールできるpythonを使う構成に落ち着きました。以下、その環境の詳細となります。

環境構築

最終的な構成は以下になります。

  • python (version2.x)
  • pip
  • virtualenv
  • direnv

インストール手順。まずはpythonをインストールMac標準のよりバージョンが新しくpipもバンドルされてるのでhomebrewで提供されているものを使います。direnvもhomebrewでインストールする。

$ brew install python
$ brew install direnv

virtualenvはpipでシステムにインストール

$ pip install virtualenv

システムにインストールするものは以上です。

開発環境の使い方

プロジェクトディレクトリの作成

何か開発したいときはプロジェクトディレクトリを作成して、

$ mkdir python_project
$ cd python_project

layout_pythonを記述した.envrcファイルを用意する。

$ echo "layout_python" > .envrc && direnv allow

すると

direnv: loading .envrc                                                                                                            
Running virtualenv with interpreter /usr/local/bin/python
New python executable in /path/to/python_project/.direnv/python-2.7.12/bin/python2.7
Also creating executable in /path/to/python_project/.direnv/python-2.7.12/bin/python
Installing setuptools, pip, wheel...done.
direnv: export +VIRTUAL_ENV ~PATH

となってpython_project/.direnvにvirtualenvの仮想環境が構築された上に、VIRTUAL_ENV環境変数が設定され仮想環境が有効になります。 (source bin/activateしたのと同様の状態になる)

パッケージのインストール

試しにpipでこの仮想環境にインストール済みのパッケージを確認してみます。

$ pip list
pip (8.1.2)
setuptools (27.2.0)
wheel (0.30.0a0)

そこに新しくパッケージをインストールします。

$ pip install supervisor

もう一度pip listすると

$ pip list
meld3 (1.0.2)
pip (8.1.2)
setuptools (27.2.0)
supervisor (3.3.1)
wheel (0.30.0a0)

supervisorがインストールできていることが確認できます。そしてこのプロジェクトディレクトリから出て、グローバルでのパッケージを確認すると

$ cd ..
$ pip list
mercurial (3.9.1)
pip (8.1.2)
setuptools (23.1.0)
vboxapi (1.0)
virtualenv (15.0.3)
wheel (0.29.0)

プロジェクトでインストールしたものが入っていないことが確認にできます。再びプロジェクトディレクトリに入ると、仮想環境が有効になり、インストール済みパッケージももとに戻ります。

パッケージの書き出しと復元

pip freezeでプロジェクトにインストールしたパッケージを書き出しておき、

$ pip freeze > requirements.txt

.direnvを削除して、仮想環境を消去し、一度プロジェクトディレクトリを出ます。この状態でもう一度プロジェクトディレクトリに入ると

$ rm -rf .direnv 
$ cd ..
$ cd python_project
direnv: loading .envrc                                                                                                            
Running virtualenv with interpreter /usr/local/bin/python
New python executable in /path/to/python_project/.direnv/python-2.7.12/bin/python2.7
Also creating executable in /path/to/python_project/.direnv/python-2.7.12/bin/python
Installing setuptools, pip, wheel...done.
direnv: export +VIRTUAL_ENV ~PATH

仮想環境が再作成されます。最後にpip install -rで書き出したパッケージ情報から、パッケージを再インストールすれば、環境が復元できました。

$ pip install -r requirements.txt

おわりに

pythonに複数バージョンが必要になったらこの構成にpyenvを足すだけで良さそう。

direnv便利。

CentOSにLet's EncryptのSSL証明書を導入する

やってみたので、手順をまとめました。実施したのはCentOS6+Apache2.2という、やや古い環境ですがCentOS7とかでも基本的には同じはずです。

Let's Encryptの概要

Let's Encryptは無料のSSL証明書を発行する認証局。 特徴は料金無料であるのと、専用のクライアントコマンドを使って証明書の発行を行う点。またワイルドカードの証明書は発行できない。有効期限が3ヶ月で、更新もコマンドによって自動化するのが前提となっています。

証明書を発行する際の要件として、当然ドメイン所有者の認証(本当にそのドメインの所有者か確認を行うこと)が必要になります。通常の認証局はメールなどを使ってこれを行いますが、Let's EncryptはACMEプロトコルという通信プロトコルと専用のクライアントコマンドを使います。ACMEプロトコルについて以下の記事が参考になりました。

Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes

ざっくり理解したところでは、ACMEプロトコルの内容は難しいものではなく、HTTPをベースに使った証明書の自動発行手順といった感じのものです。

さて、実際にLet's Encryptの証明書を導入するには一般に以下の作業が必要です。

  • クライアントコマンドのインストール
  • HTTPサーバの用意
  • クライアントコマンドを実行して証明書を取得
  • 取得した証明書使うためのHTTPサーバの設定
  • 自動更新のための設定

以下、順に記述します。

手順

クライアントコマンドのインストール

ACMEプロトコルでLet's Encryptのサーバと通信して証明書発行を行うCLIツールです。ここでは公式が提供しているcertbot-autoというツールを使います。

https://certbot.eff.org/

シェルスクリプトPythonで構成されています。このツールの操作自体、基本的にroot特権が必要になるので、以下のインストール作業のコマンドも全てrootユーザで行いました。

# yum install -y epel-release
# curl https://dl.eff.org/certbot-auto -o /usr/bin/certbot-auto
# chmod a+x /usr/bin/certbot-auto
# certbot-auto --os-packages-only --non-interactive

最後のcertbot-auto --os-packages-only --non-interactiveで依存パッケージがインストールされます(pythonのランタイムとか)。

HTTPサーバの用意

証明書発行時にACMEプロトコルドメインの認証処理(acme challengeというらしい)において、証明書を発行するドメインに対してHTTPでリクエストを投げてきます。 よってHTTPサーバが稼働している必要があります。ここではapache使うことにします。

# yum install -y httpd

インストールしたらドメイン名でアクセスできるように設定しておきます。

クライアントコマンドを実行して証明書を取得

certbot-auto certonlyで証明書を取得します。証明書発行に必要な秘密鍵などもこのコマンドを叩くだけでまとめて生成されます。

# certbot-auto certonly --non-interactive --agree-tos --webroot -w /var/www/html -d example.com --email kohki.makimoto@gmail.com

以下のオプションは環境に合わせて読み替えてください。

  • -d: ドメイン名を指定します。

  • --email: 更新期限が近づいたときにメール通知されるメアドを指定します。

  • -w: HTTPサーバのドキュメントルートを指定します。

-wオプションについて補足します。前述したようにACMEプロトコルドメインの認証処理でHTTPサーバにアクセスしてくるのですが、その際/.well-known/acme-challenge/というパスに対してアクセスしてきます。クライアントコマンドはこのパスにLet's Encrypt が指定したテキストを配置する必要があるので、そこにアクセスできるようドキュメントルートを指定するわけです。

その他オプションについての詳細はcertbot-auto --help allで確認してください。

うまくいくと

/etc/letsencrypt/live/{ドメイン名}

というパスに証明書や秘密鍵が生成されます。

取得した証明書使うためのHTTPサーバの設定

最近はSNIを使ってバーチャルホストごとにSSL設定ができるので、SSL証明書の設定はバーチャルホストごとに設定しました。

<VirtualHost *:443>
    ServerName example.com
    # ...

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

</VirtualHost>

なお、サーバ全体のSSL設定は/etc/httpd/conf.d/ssl.confなどに以下のように記述しておきます。

LoadModule ssl_module modules/mod_ssl.so

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

SSLPassPhraseDialog  builtin
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
SSLStrictSNIVHostCheck off

Listen 443

また、必要に応じてhttpにアクセスがあったらhttpsにリダイレクトさせる設定もいれます。

<VirtualHost *:80>
    ServerName example.com
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</VirtualHost>

自動更新のための設定

certbot-auto renewコマンドで証明書の更新ができます。Let's Encryptの証明書は3ヶ月で有効期限が切れるので、cronに以下のコマンドを仕込みます。この例は出力を捨ててますが、ちゃんと運用する場合はきちんとログに残しましょう。

50 3 * * * root certbot-auto renew --post-hook "/usr/sbin/apachectl graceful" > /dev/null 2>&1

証明書取得時のようにドキュメントルートの指定はしていないので、/etc/letsencrypt/配下の設定ファイルなどを見て更新しているっぽいです。

–-force-renewをつけて実行すると有効期限が1ヶ月未満にならなくても、強制的に有効期限を更新します。手動で更新検証するのに使いました。

以上で一通り、作業は完了です。

その他

Basic認証をかけたサイトにLet's Encryptを使う

Basic認証をかけているサイトだとACMEプロトコルドメイン認証で、HTTPサーバにアクセスできず、証明書取得ができません。 以下の設定を入れて/.well-known/acme-challengeに穴をあけておくとうまくいきます。

<Location />
    Satisfy Any
    AuthType Basic
    AuthName "My Private Stuff"
    AuthUserFile /var/www/example/.htpasswd
    Require valid-user

    SetEnvIf Request_URI "/.well-known/acme-challenge" acme-challenge
    Order Deny,Allow
    Deny from all
    Allow from env=acme-challenge
</Location>

サードパーティツール

クライアントツールはサードパーティーのGo実装のシングルバイナリもあるのですが、現状見送り。公式のほうがやはり安心感ある。

CentOS6のpythonのバージョンが古い

CentOS6はpythonのバージョンが古いのでcertbot-auto実行時に以下のような警告がでました。が、正常に証明書取得までできたのでまあいいかな、と。。。

/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
  DeprecationWarning

いろいろ参考にさせていただいたサイトなど

ありがとうございました。