データバックアップサーバ

データのバックアップサーバを作った。これまでは各マシンに外付け HDD をつけてそこにバックアップしてたけど、バックアップサーバに一元化することにした。バックアップサーバには新しく買った 6TB の外付け HDD を取り付けた。

バックアップの方法はこれまで通り rsync を使うんだけど、ネットワーク越しにバックアップサーバにバックアップすることになる。

具体的な手順は過去記事に譲ろう。

順次バックアップ設定を変えていって、バックアップサーバに集約する。

とすると、さて、外付け HDD が4つ余ることになるんだけど、どうしようか……。

修理に出していたPCが戻ってきた

先月末にダメになってしまった PC、修理に出していたのが戻ってきた。メモを見ると DELL のサポートに電話して修理依頼をしたのが4月9日なので、1週間かからずに戻ってきたわけだ。

故障個所は CPU ファンだった。どうやらファンを交換して修理完了したようだ。ハードディスクのデータは保証しない、といわれていたけど、起動してみたら元のまま CentOS7 が立ち上がった。データも大丈夫のようだ。

先日のエントリに書いた通り、この PC(ホスト名は nightschool)はインターネットに公開していたサーバで、web アプリを2つ動かしていた。両方とも新しいサーバ(unclemeat)に引き継いでいるので、余った形になる。

さて、何に使おうか。

DELL製PCにCentOS7をインストールしてもブートできない

昨日の話。サーバにしていた PC がダメになった。しばらく前から異音がしていて、これはもうヤバげだな、という感じではあったんだけど、昨日リブートしてみようと思い立ってそうしてみたら、ダメになった。余計なことはするもんじゃない。

もう少し正確に言うと、OS (CentOS7だ)は起動する。Nginx も起動する。けど、肝心の web アプリが起動しない、という状態。リブートしただけなので、何も変わっていないはずなんだけど、起動しないものは起動しない。そもそも上に書いたとおりハード的にもヤバそうだったので、早々に諦めて、新しいPCに移行することにした。実は、しばらく前から異音が発生していたので新しい PC を買ってあったのだ。

新しい PC は、DELL 製の OptiPlex 3060 Micro という機種。これに CentOS7 をインストールしようというわけだ。BIOS (というか最近のは UEFI というらしい)の設定を変更して外付け DVD ドライブからブートするようにしてインストール。インストール自体は特につまづくこともなく終了(過去記事を見てほしい)。

ところが、DVD を抜いてリブートしてもできない。ブータブルなメディアが見つからない、とかなんとかそんなことを言われる。そんなこと言われても、インストールできたんだからなんとかなるだろう、と思って UEFI の設定を変更しようと試みるも、UEFI というのは Windows 向けの設定になっているし(変更しようにもファイルシステムが見つからないと言われる)、レガシーな BIOS (インストール時にはこちらに設定した)には内部のハードディスクからブートするという選択肢がない。ように見える。

BIOS に内部ハートディスクからブートする機能がないとすると、UEFI を使うしか無いんだけど、どうもググった限りで分かったのは CentOS7 は UEFI に対応していないらしいということと、Ubuntu は対応しているらしい、ということ。

そこで、Ubuntu (18.04 の日本語REMIX版)をインストールしてみた。結果、今度はちゃんとブートするようになった。まだ OS をインストールしただけで、web アプリの構築とかしてないんだけど、今のところ大丈夫そうだ。

というところまでが、昨日の話。今日は web アプリを構築して早くサーバとして復帰させたい……んだけど、今日は時間がないんだよなぁ。

[追記]

何とか、最低限の復旧は果たした。

あと、ホスト名は unclemeat にした。

さくらのVPSのサイトをHTTPS化

さくらの VPS で運用しているサイト(Railsアプリ)を Let’s Encrypt で HTTPS 化した。言っとくけどこのブログじゃないよ。

HTTPのポートを開放

まず、HTTPS のポート 443 を開放する。/etc/sysconfig/iptables ファイルを編集。

[takatoh@tk2-254-36564 ~]$ cd /etc/sysconfig
[takatoh@tk2-254-36564 sysconfig]$ sudo vim iptables

つぎの行を追加。

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

iptables を再起動。

[takatoh@tk2-254-36564 sysconfig]$ sudo service iptables restart
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
iptables: Loading additional modules: ip_conntrack_ftp [ OK ]

certbot-auto のセットアップと証明書の自動生成

「certbot-auto」は Let’s Encrypt が提供しているクライントツールで、SSL証明書を取得したり延長したりできる。ここでは、最新版を取得する。

[takatoh@tk2-254-36564 bin]$ sudo wget https://dl.eff.org/certbot-auto
--2019-01-13 09:41:36-- https://dl.eff.org/certbot-auto
dl.eff.org をDNSに問いあわせています… 151.101.72.201, 2a04:4e42:36::201
dl.eff.org|151.101.72.201|:443 に接続しています… 接続しました。
HTTP による接続要求を送信しました、応答を待っています… 200 OK
長さ: 63562 (62K) [application/octet-stream]
`certbot-auto' に保存中

100%[======================================>] 63,562 --.-K/s 時間 0.002s

2019-01-13 09:41:39 (24.3 MB/s) - `certbot-auto' へ保存完了 [63562/63562]

[takatoh@tk2-254-36564 bin]$ sudo chmod 700 /usr/bin/certbot-auto

いまインストールした certbot-auto を使って、証明書を自動生成する。

[takatoh@tk2-254-36564 ~]$ sudo certbot-auto certonly --webroot -w /var/www/lathercraft/public -d www.lathercraft.net --email [email protected]

途中、いろんなパッケージをインストールしたりするのでy(yes)を入力する。しばらくすると利用規約が表示されるので、A(agree)を入力。最後に↓こんなメッセージが出ればOK。

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.lathercraft.net/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.lathercraft.net/privkey.pem
Your cert will expire on 2019-04-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew all of your certificates, run
"certbot-auto renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

- We were unable to subscribe you the EFF mailing list because your
e-mail address appears to be invalid. You can try again later by
visiting https://act.eff.org.

……じゃないな、e-mail が invalid だと言ってる。あとから試せるとも言ってるので、とりあえず先に進む。この時点で証明書類はこんな感じになっている。

[takatoh@tk2-254-36564 ~]$ sudo ls -l /etc/letsencrypt/live/www.lathercraft.net/
合計 4
-rw-r--r-- 1 root root 692 1月 13 09:53 2019 README
lrwxrwxrwx 1 root root 43 1月 13 09:53 2019 cert.pem -> ../../archive/www.lathercraft.net/cert1.pem
lrwxrwxrwx 1 root root 44 1月 13 09:53 2019 chain.pem -> ../../archive/www.lathercraft.net/chain1.pem
lrwxrwxrwx 1 root root 48 1月 13 09:53 2019 fullchain.pem -> ../../archive/www.lathercraft.net/fullchain1.pem
lrwxrwxrwx 1 root root 46 1月 13 09:53 2019 privkey.pem -> ../../archive/www.lathercraft.net/privkey1.pem

Nginxの設定

SSL 対応にする。こんなふうに書き換える。

    #listen      80;
    listen      443 ssl;

    ssl_certificate      /etc/letsencrypt/live/www.lathercraft.net/cert.pem;
    ssl_certificate_key  /etc/letsencrypt/live/www.lathercraft.net/privkey.pem;

Nginx を再起動。

[takatoh@tk2-254-36564 conf.d]$ sudo service nginx restart
Stopping nginx: [ OK ]
Starting nginx: [ OK ]

これでOKのはず。まだアプリが SSL 対応していないのでバナー画像に https でアクセスしてみたら、ちゃんと表示された。なのでここまではOKのようだ。

RailsアプリのSSL対応

これは簡単。config/envronments/production.rb ファイルのつぎの箇所を修正すればいい。

# config.force_ssl = true
config.force_ssl = true

コメントアウトしてあるのを外すだけだ。そして再起動。

[takatoh@tk2-254-36564 environments]$ sudo service unicorn_lathercraft restart
reloaded OK

OK。大丈夫そうだ。

httpをhttpsにリダイレクト

最後に、http でのアクセスを https にリダイレクトする設定をする。Nginx の設定に戻ってつぎの設定を追加する。

server {
    listen       80;
    server_name  www.lathercraft.net;
    return       301 https://www.lathercraft.net;
}

Nginx を再起動して完了。

証明書の自動更新設定

Let’s Encrypt の証明書は有効期限が3ヶ月と短いので、自動更新するように設定する。更新は certbot-auto renew コマンドでできるので、これを root ユーザの cron に登録する。

[takatoh@tk2-254-36564 ~]$ sudo -s
[root@tk2-254-36564 takatoh]# crontab -l
no crontab for root
[root@tk2-254-36564 takatoh]# crontab -e
0 4 * * 0 certbot-auto renew --post-hook "service unicorn_lathercraft restart" > /dev/null 2> /dev/null

これで毎週月曜日の午前4時に更新するようになる。

[追記]

上の、Nginx のリダイレクトの設定では、http でのアクセスはどんなパスでも全て https のルートにリダイレクトされてしまう。なので、つぎのように変更した。

server {
    listen       80;
    server_name  www.lathercraft.net;

    location ~ ^/(.*)$ {
        return 301 https://www.lathercraft.net/$1;
    }
}

これで各ページも https にリダイレクトされるようになった。

sshで接続できるようにする

bigswifty を WiMAX に接続したので、他のマシンとはネットワーク的に切り離されてしまった。まぁ、これは意図した通りなんだけど、ssh で接続できないのも不便なので、インターネット経由で接続できるように設定する。

ここからは bitswifty 上での作業。

sshdの設定

ポートを変更。

Port 12345

root でのログインを禁止。

PermitRootLogin no

設定を反映するために sshd を再起動。

[lcstorage@bigswifty ~]$ sudo systemctl restart sshd

ファイアウォールの設定

ポートを開ける。

[lcstorage@bigswifty ~]$ sudo firewall-cmd --add-port=12345/tcp --zone=public --permanent
success

設定をリロード。

[lcstorage@bigswifty ~]$ sudo firewall-cmd --reload
success

WiMAX端末のポートマッピング

192.168.100.1 にブラウザで接続して、設定ページから、ファイアウォール設定→ポートマッピングと進んで、WAN ポートの12345 を bitswifty の12345 番ポートに接続するようにする。と、ここで気が付いたんだけど bigswifty のポートは変更しなくても良かったんじゃないか?まぁいいか。

接続テスト

別のマシンからインターネット経由で ssh 接続してみると、無事接続できた。

公開鍵での認証

認証方法をパスワード認証から公開鍵認証に切り替える。公開鍵は GitHub からもってきた。

[lcstorage@bigswifty ~]$ mkdir .ssh
mkdir: ディレクトリ `.ssh' を作成できません: ファイルが存在します
[lcstorage@bigswifty ~]$ cd .ssh
[lcstorage@bigswifty .ssh]$ wget -O authorized_keys https://github.com/takatoh.keys
--2018-12-15 05:32:26--  https://github.com/takatoh.keys
github.com (github.com) をDNSに問いあわせています... 192.30.255.112, 192.30.255.113
github.com (github.com)|192.30.255.112|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 特定できません [text/plain]
`authorized_keys' に保存中

    [ <=>                                   ] 381         --.-K/s 時間 0s

      2018-12-15 05:32:27 (2.28 MB/s) - `authorized_keys' へ保存終了 [381]

[lcstorage@bigswifty .ssh]$ chmod 600 authorized_keys
[lcstorage@bigswifty .ssh]$ ls -al
合計 12
drwx------.  2 lcstorage lcstorage   48 12月 15 05:32 .
drwx------. 19 lcstorage lcstorage 4096 12月 15 04:34 ..
-rw-------   1 lcstorage lcstorage  381 12月 15 05:32 authorized_keys
-rw-r--r--.  1 lcstorage lcstorage  185 12月  4 03:56 known_hosts

接続テスト

再び、別のマシンから接続テスト。ちゃんと公開鍵認証で接続できた。

パスワード接続を禁止

最後に、もう一度 /etc/ssh/sshd_config ファイルを編集して、パスワード接続を禁止する。

PasswordAuthentication no

sshd を再起動。

[lcstorage@bigswifty .ssh]$ sudo systemctl restart sshd

これで完了。

参考ページ

CentOS: マシンを再起動するとサービスが動かない件

一昨日のエントリでは書かなかったけど、マシンを再起動したら uWSGI のサービスが起動しなかった。仕方がないので手動で起動してたんだけど、今日、問題が解決した。
原因は、ソケットファイルを作る /run/uwsgi ディレクトリがマシンを再起動すると消えてしまうこと。何故なら、/run は tmpfs というタイプのファイルシステムだかららしい。

[lcstorage@bigswifty ~]$ df -h
ファイルシス                      サイズ  使用  残り 使用% マウント位置
/dev/mapper/centos_bigswifty-root    50G  4.3G   46G    9% /
devtmpfs                            1.8G     0  1.8G    0% /dev
tmpfs                               1.8G  8.7M  1.8G    1% /dev/shm
tmpfs                               1.8G  9.8M  1.8G    1% /run
tmpfs                               1.8G     0  1.8G    0% /sys/fs/cgroup
/dev/sdb1                           917G  3.4G  867G    1% /mnt/wiwaxia
/dev/sdc1                           917G   77M  871G    1% /mnt/ottoia
/dev/sda1                          1014M  286M  729M   29% /boot
/dev/mapper/centos_bigswifty-home   179G  507M  178G    1% /home
tmpfs                               359M   32K  359M    1% /run/user/1001

詳しくは分からないけど、↓このページに解決策があった。

 cf.  /var/run の中身が再起動すると消えてしまうので・・・ – cles::blog

要するに、次のような内容で /etc/tmpfiles.d/uwsgi.conf  ファイルを作ってやればいいようだ。

d /run/uwsgi 0777 root root

これで無事、マシンを再起動しても大丈夫になった。

bottleアプリにNginx経由で接続できるようにする

1日空いてしまった。
uWSGI でデーモンとして動かすことに成功したので、今日は Nginx をリバースプロキシにして lcstorage というホスト名で接続できるようにする。

Nginx の前に、uWSGI の設定をちょっと変更。リクエストを待ち受けるのにポートじゃなくて UNIX ソケットを利用するようにする。

[uwsgi]
uid = lcstorage
gid = lcstorage
#http = :8080
socket = /run/uwsgi/lcstorage.sock
venv = /home/lcstorage/lcstorage/env
wsgi-file = /home/lcstorage/lcstorage/index.py
master = true
pidfile = /home/lcstorage/lcstorage/lcstorage.pid
daemonize = /home/lcstorage/lcstorage/lcstorage.log

http の設定をコメントアウトして socket を設定している。
でもって、sochekt のディレクトリをつくる。

[lcstorage@bigswifty ~]$ sudo mkdir /run/uwsgi
[lcstorage@bigswifty ~]$ sudo chmod 777 /run/uwsgi

つぎに、Nginx のバーチャルホストの設定。
/etc/nginx/conf.d/lcstorage.conf ファイルを作る。

upstream uwsgi-lcstorage {
    server unix:/run/uwsgi/lcstorage.sock;
}

server {
    # port
    listen      80;

    # server name
    server_name lcstorage;

    # document root
    #root        /home/lcstorage/lcstorage;

    # index
    #index       index.php index.html index.htm;

    client_max_body_size    4G;

    # log files
    access_log /var/log/nginx/lcstorage/access.log main;
    error_log  /var/log/nginx/lcstorage/error.log warn;

    keepalive_timeout     60;
    proxy_connect_timeout 60;
    proxy_read_timeout    60;
    proxy_send_timeout    60;

    location / {
        #root       /home/lcstorage/lcstorage;

        include uwsgi_params;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        uwsgi_pass unix:/run/uwsgi/lcstorage.sock;
    }
}

ログファイル用のディレクトリをつくる。

[lcstorage@bigswifty ~]$ sudo mkdir /var/log/nginx/lcstorage

そして、SELinux を無効化。コレ重要。

最後に、マシンをリブートして終了。
無事にバーチャルホストにアクセスできることを確認した。

CentOS 7上でbottleアプリをuWSGIで動かす(2)

一昨日の続き。今日は、アプリをデーモンとして動かす。
まず最初に、uWSGI の設定ファイルをちょっと書き換える。

<span class="token selector">[uwsgi]</span>
<span class="token constant">uid</span> <span class="token attr-value"><span class="token punctuation">=</span> lcstorage</span>
<span class="token constant">gid</span> <span class="token attr-value"><span class="token punctuation">=</span> lcstorage</span>
<span class="token constant">http</span> <span class="token attr-value"><span class="token punctuation">=</span> :8080</span>
<span class="token constant">venv</span> <span class="token attr-value"><span class="token punctuation">=</span> /home/lcstorage/lcstorage/env</span>
<span class="token constant">wsgi-file</span> <span class="token attr-value"><span class="token punctuation">=</span> /home/lcstorage/lcstorage/index.py</span>
<span class="token constant">master</span> <span class="token attr-value"><span class="token punctuation">=</span> true</span>
<span class="token constant">pidfile</span> <span class="token attr-value"><span class="token punctuation">=</span> /home/lcstorage/lcstorage/lcstorage.pid</span>
<span class="token constant">daemonize</span> <span class="token attr-value"><span class="token punctuation">=</span> /home/lcstorage/lcstorage/lcstorage.log</span>
Ini

最後の行を変更した。logger を daemonize に変えると何故かデーモンとしてバックグラウンドで動くようになるという、uWSGI のよくわからない仕様。

無事バックグラウンドで動くようになったら、systemd のサービスになるように設定ファイル /etc/systemd/system/lcstorage.service を書く。

[Unit]
Description=lcstorage service with uWSGI

[Service]
Type=forking
ExecStart=/usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -QUIT $MAINPID
PIDFile=/home/lcstorage/lcstorage/lcstorage.pid
WorkingDirectory=/home/lcstorage/lcstorage
User=lcstorage
Group=lcstorage

[Install]
WantedBy=multi-user.target
Ini

これでいいはず。試してみよう。

[lcstorage@bigswifty system]$ sudo systemctl start lcstorage
[sudo] lcstorage のパスワード:
[lcstorage@bigswifty system]$ ps ax | grep uwsgi
28937 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28946 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28947 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28949 pts/1    S+     0:00 grep --color=auto uwsgi

成功のようだ。他のマシンのブラウザからも確認できた。

最後に、マシンの起動にあわせて自動的に起動するようにする。

[lcstorage@bigswifty system]$ sudo systemctl enable lcstorage
Created symlink from /etc/systemd/system/multi-user.target.wants/lcstorage.service to /etc/systemd/system/lcstorage.service.

さあ、あしたは Nginx 経由でアクセスできるようにしよう。時間があったらだけど。

Railsアプリのログをローテーションした話

Web を見ていてログローテーションの記事を見かけたので、そういえばさくらの VPS で動かしている Rails アプリのログはどうなってるんだろう、と思った。で、調べてみるとつぎの通り。

[takatoh@tk2-254-36564 log]$ ls -lh
合計 1.2G
-rw-r--r-- 1 root root  25K  5月  5 09:53 2017 development.log
-rw-r--r-- 1 root root 1.2G 12月  5 03:56 2018 production.log

うわあああああ、production.log が 1.2GB もあるううう!!!!!

こりゃ、ぜひともログローテーションしなきゃ、と思って調べてみると、Rails にはログのローテーションをする機能があるらしい。アプリのディレクトリ以下の config/environments/production.rb ファイルで、つぎのようにすればいいようだ。

config.logger = Logger.new("log/production.log", 'daily')

ところが、実際に動いているアプリのファイル(の該当部分)を見てみるとつぎのようになっている。

# config.logger = ActiveSupport::TaggedLogging.new(SyslogLogger.new)

コメントアウトしてあるのはいいとしても、Rails のバージョンのせいなのか何なのか、全然違う。はっきりいってこういうのはウカツに弄りたくない。

というわけで、logrotate でやってみることにした。さくらの VPS では logrotate がデフォルトで動いている(らしい)ので、/etc/logrotate.d 以下に設定ファイルを書いて置いてやればいい。

/var/www/lathercraft/log/production.log {
daily
rotate 14
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/sbin/service unicorn_lathercraft rotate > /dev/null 2> /dev/null || true
endscript
}

参考にしたページ:
cf. さくらのVPSの設定 – logrotateの設定
テストしてみる。

[takatoh@tk2-254-36564 logrotate.d]$ logrotate -dv unicorn_lathercraft
reading config file lathercraft
reading config info for /var/www/lathercraft/log/production.log 

Handling 1 logs

rotating pattern: /var/www/lathercraft/log/production.log  after 1 days (14 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/lathercraft/log/production.log
  log does not need rotating
not running postrotate script, since no logs were rotated

エラーらしきものは出てないので、いいのかな。
とりあえずこれで様子を見てみよう。

CentOS 7上でbottleアプリをuWSGIで動かす

専用ユーザーの作成

[takatoh@bigswifty ~]$ sudo useradd lcstorage
[sudo] takatoh のパスワード:
[takatoh@bigswifty ~]$ sudo passwd lcstorage
ユーザー lcstorage のパスワードを変更。
新しいパスワード:
よくないパスワード: このパスワードには一部に何らかの形でユーザー名が含まれています。
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。

よくないパスワードとか言われてるけど無視。sudo する権利をつける。

[takatoh@bigswifty ~]$ sudo usermod -G wheel lcstorage

ここからは新しいユーザーでの作業になるので、ログインし直し。

bottleアプリの配置

bitbucket.org から clone。

[lcstorage@bigswifty ~]$ git clone https://[email protected]/takatoh/lathercraft-storage-py.git lcstorage
Cloning into 'lcstorage'...
Password for 'https://[email protected]': 
remote: Counting objects: 127, done.
remote: Total 127 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (127/127), 13.63 KiB | 0 bytes/s, done.
Resolving deltas: 100% (55/55), done.

中に入って virtualenv を作成。

[lcstorage@bigswifty ~]$ cd lcstorage
[lcstorage@bigswifty lcstorage]$ virtualenv env
New python executable in /home/lcstorage/lcstorage/env/bin/python2
Also creating executable in /home/lcstorage/lcstorage/env/bin/python
Installing setuptools, pip, wheel...
done.
[lcstorage@bigswifty lcstorage]$ source env/bin/activate
(env) [lcstorage@bigswifty lcstorage]$

依存ライブラリのインストール。

(env) [lcstorage@bigswifty lcstorage]$ pip install -r requirements.txt
Collecting PyYAML==3.12 (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/4a/85/db5a2df477072b2902b0eb892feb37d88ac635d36245a72a6a69b23b383a/PyYAML-3.12.tar.gz (253kB)
    100% |████████████████████████████████| 256kB 6.9MB/s 
Collecting bottle==0.12.10 (from -r requirements.txt (line 2))
  Downloading https://files.pythonhosted.org/packages/5c/a9/f157af11b37834db992b14e43ade37a1bdc141485657cfa36dc1d99420a6/bottle-0.12.10-py2-none-any.whl (88kB)
    100% |████████████████████████████████| 92kB 8.9MB/s 
Collecting requests==2.12.3 (from -r requirements.txt (line 3))
  Downloading https://files.pythonhosted.org/packages/84/68/f0acceafe80354aa9ff4ae49de0572d27929b6d262f0c55196424eb86b2f/requests-2.12.3-py2.py3-none-any.whl (575kB)
    100% |████████████████████████████████| 583kB 8.1MB/s 
Building wheels for collected packages: PyYAML
  Running setup.py bdist_wheel for PyYAML ... done
  Stored in directory: /home/lcstorage/.cache/pip/wheels/03/05/65/bdc14f2c6e09e82ae3e0f13d021e1b6b2481437ea2f207df3f
Successfully built PyYAML
Installing collected packages: PyYAML, bottle, requests
Successfully installed PyYAML-3.12 bottle-0.12.10 requests-2.12.3

アプリの設定ファイルを作って、起動確認。設定はとりあえずはデフォルトのままで。

(env) [lcstorage@bigswifty lcstorage]$ cp config.yaml.example config.yaml
(env) [lcstorage@bigswifty lcstorage]$ python index.py
Bottle v0.12.10 server starting up (using WSGIRefServer())...
Listening on http://0.0.0.0:8080/
Hit Ctrl-C to quit.

よし、大丈夫そうだ。じゃ、virtualenv をぬけて uWSGI に行くぞ。

uWSGIで起動

まずは uWSGI のインストール。

[lcstorage@bigswifty lcstorage]$ sudo pip install uwsgi
Collecting uwsgi
  Using cached https://files.pythonhosted.org/packages/a2/c9/a2d5737f63cd9df4317a4acc15d1ddf4952e28398601d8d7d706c16381e0/uwsgi-2.0.17.1.tar.gz
Installing collected packages: uwsgi
  Running setup.py install for uwsgi ... done
Successfully installed uwsgi-2.0.17.1
You are using pip version 8.1.2, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

上では省略しちゃったけど、最初のインストールの時にエラーが出て、sudo yum install gcc python2-devel しなきゃならなかった。
ともかくインストールできたので、コマンドラインから起動してみる。

[lcstorage@bigswifty lcstorage]$ uwsgi --http :8080 --wsgi-file index.py -H env

他のマシンからアクセスしたら、ちゃんと動いていたのでOK。

設定ファイルを書く。

[uwsgi]
uid = lcstorage
gid = lcstorage
http = :8080
venv = /home/lcstorage/lcstorage/env
wsgi-file = /home/lcstorage/lcstorage/index.py
master = true
pidfile = /home/lcstorage/lcstorage/lcstorage.pid
logger = file:/home/lcstorage/lcstorage/lcstorage.log

起動確認。

[lcstorage@bigswifty lcstorage]$ uwsgi lcstorage.ini
[uWSGI] getting INI configuration from lcstorage.ini

OK。大丈夫そうだ。

とりあえずここまで。