まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

UNIX/Linux 系 OS 用の仮想端末マネージャーである screen コマンド。以前に紹介した tmux に似てるけど、screen は多くのケースで標準導入されているので、ビルドとかなしにそのまま使えることが多いです。

というわけで、概要と使い方のメモ:

【screen コマンドとは?】
- 1つのターミナル上で、仮想的に複数の端末を同時にオープンして作業するツール。
- 仮想端末が開かれた状態を保ったままターミナルをログアウトできる。後から再度ターミナルでログインして、screen を呼び出すことで仮想端末の状態に復帰できる。
- 1つのターミナルの画面を上下に分割して、複数の端末を同時にアクティブにして(切り替えながら)操作できる。


【screen コマンドの使い方】
screen 起動
# screen
screen 内で新しい仮想端末を開く
[ctrl]+a c
screen 内で動いている仮想端末の一覧表示
[ctrl]+a w
screen 内で動いている別の仮想端末に移動する
[ctrl]+a n または [ctrl]+a [space] 昇順移動 [ctrl]+a p または [ctrl]+a [del] 降順移動 [ctrl]+a 数字 (数字)で示される仮想端末に移動 [ctrl]+a [ctrl]+a 直前に使っていた仮想端末へ戻る
現在開いている仮想端末を閉じる(キル)
[ctrl]+a k
現在開いている仮想端末をサスペンド状態にして閉じる(デタッチ)
[ctrl]+a d
screen 内でデタッチ状態で動いている仮想端末の一覧表示
# screen -ls (ここで PID が確認できる)
screen 内でデタッチ状態で動いている仮想端末に戻る(アタッチ)
# screen -r PID
デタッチせずに screen を終了する
[ctrl]+a \
起動中の screen をバックスクロールモードにする
[ctrl]+a [
バックスクロールモードでテキストコピー
カーソルを始点に移動させて [space] または [enter] カーソルを終点に移動させて [space] または [enter]
コピーしたテキストのペースト
[ctrl]+a ]
画面を上下2分割
[ctrl]+a S
画面分割後にフォーカス画面を変更
[ctrl]+a [tab]
画面分割をやめる
[ctrl]+a Q

【実際の使い方】
一度実行すると、処理完了まで1日程度かかるコマンド(# php test.php)があるとします。
これをサーバー上で実行して、一度デタッチして(バックグラウンドで処理を続けて)からサーバーとの接続を切断し、翌日サーバーに再度ログインして結果を確認する。
(ssh や telnet でサーバーにログイン)

# screen screen 実行(この時点で仮想端末0が実行される)

[ctrl]+a c 新しい仮想端末1を作成して移動

# php test.php 処理実行開始・・・・

[ctrl]+a d 処理実行中の仮想端末をデタッチ(この時に screen からも抜ける)

# screen -ls デタッチした処理の PID を確認( XXXX だったとする)

# exit (サーバーからログアウト)

  :
  :
  :

(翌日、再度 ssh や telnet でサーバーにログイン)

# screen -r XXXX 前日デタッチした仮想端末をアタッチ

(処理が完了していたらそのまま続きの作業を行う。まだ完了してなかったら再びデタッチして完了を待つ)







高速な HTTP サーバーである Nginx を使って cakePHP を利用する場合の設定をまとめました。注意点としてはリライトの扱いとファイルパーミッションです:


前提として cakePHP は(Apache HTTPd で使う前提の内容でいいので)設定ができているものとします。cakePHP の導入先は /var/www/html/cakephp/ であると仮定します。Apache HTTPd は導入しないか、サービスを止めておきます。cakePHP の導入手順についてはこちらを参照ください:
cakePHP を CentOS にインストールする


また PHP-FPM や Nginx の導入自体はできているものとします。これらの手順はこちらを参照ください:
CentOS に Nginx をインストールして PHP を使う


では Nginx を cakePHP の環境に合わせて設定していきます。まずは /etc/nginx/conf.d/default.conf を以下の内容に変更します(特に赤字部分は各自の環境に合わせて編集するよう、注意してください):
server {
    listen       80;
    server_name  localhost;
 
    root   /var/www/html/cakephp/app/webroot;
    index  index.php index.html;
 
    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;
 
    location / {
        try_files $uri $uri?$args $uri/ /index.php?$uri&$args /index.php?$args;
    }
 
    #error_page  404              /404.html;
 
    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
 
    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}
 
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        try_files       $uri =404;
        fastcgi_pass    127.0.0.1:9000;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include         fastcgi_params;
    }
 
    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

※追記1
index 節に index.html を追加。webroot/sub/index.html に /sub/ でアクセスできるようにするため

※追記2
try_files 節に /index.php?$args を追加。/controller/view?key=value を正しくハンドルできるようにするため



次に cakePHP 内の app/tmp フォルダに(Apache HTTPd ではなく) nginx が書き込めるような権限を与えます:
# chown -R nginx.nginx /var/www/html/cakephp/app/tmp
# chmod -R 700 /var/www/html/cakephp/app/tmp

また、/etc/php.ini に以下の内容を加えて、セッションデータを保存するディレクトリを設定しておきます:
session.save_path = "/var/lib/php/session"

これで Nginx を起動して、ブラウザで http://(サーバー名)/ にアクセスすると Nginx 環境下で動いている cakePHP のホーム画面が表示されるはずです:
# /etc/init.d/nginx start (Nginx サービス起動)
# chkconfig nginx on (自動起動設定)

2014051701




心なしか速くなった・・・のかな?



Stackato を使ってプライベート環境に構築した Cloud Foundry 環境に、App Store というアプリケーション一覧からアプリケーションをデプロイしてみます。Stackato 環境構築の手順はこちらを参照してください:
Stackato を導入してプライベートな Cloud Foundry 環境を(KVM に)構築する
 ↑これの続きです


Stackato 管理コンソールにログインして、最初のページを下にスクロールすると "Deploy from the App Store" と書かれたリンクがあります。ここをクリックします:
2014051501


"App Store" という、Stackato 対応アプリケーション(正確にはサーバー&アプリケーション)の一覧が表示されます。CMS の Joomla やアプリケーション開発フレームワークの cakePHP など、メジャーどころが結構対応しています。これらは全て以下に紹介する簡単な手順で Stackato にデプロイできるようになっています:
2014051502


試しに、ブログや CMS では定番の1つになっている WordPress をデプロイしてみます。一覧の最後の方までスクロールして、"WordPress" を見つけたら、"Deploy App" ボタンをクリックします:
2014051503


WordPress アプリケーションサーバーのデプロイ情報を入力します。といってもここで気をつけるべきは一番上の "App Name" 欄だけです。デフォルトで設定されている名称をそのまま使ってもいいし、変更してもいいのですが、これがアプリケーションサーバー名の一部(****.stackato-mm7d.local の **** 部)になります。とりあえずこの例では "wordpress-y7unx" という名称にしています。最後に "Deploy Application" ボタンをクリックすると Stackato 環境にデプロイが開始されます:
2014051504


デプロイ中の画面はこんな感じでログが表示されます。しばらく待ちます・・・:
2014051505


ログに "Created app 'wordpress-y7unx(App Nameの値)'" と表示されて、ログの動きが止まったらデプロイが完了しています:
2014051506


この状況で画面左の "Instance" をクリックすると、Stackato 環境内で動いているサーバーインスタンスの一覧が表示されます。先程作成した WordPress サーバーがちゃんと Stackato 内で動いていることが確認できます。またこの画面から再起動などの管理オペレーションが可能になっています:
2014051507
 ↑仮想環境の KVM の中で動いている Stackato の中で動いている WordPress サーバー、です


では実際のアプリケーションにアクセスしてみます。

・・・が、その前に、このアプリケーションは Stackato 内で動いていて、IP アドレス自体は Stackato と同じものです。(恐らく VirtualHost 設定などで)アクセスサーバー名で切り替えられるようなので、この WordPress にアクセスするには改めて /etc/hosts を編集するなどして、サーバー名(wordpress-y7unx.stackato-mm7d.local)でアクセスできるようにしておく必要があります。

前回も紹介したように、ブラウザを利用するマシンの hosts ファイルを更に変更して、サーバー名と IP アドレスの対応を追加しておきます:
192.168.0.101 stackato-mm7d.local api.stackato-mm7d.local wordpress-y7unx.stackato-mm7d.local
(↑内容は各自の環境に合わせるようにして赤字部分を追加します


そしてブラウザで http://wordpress-y7unx.stackato-mm7d.local/ を開くと、、、WordPress の初期設定画面が表示されています。あっけなく動いてますね:
2014051508


初期設定を済ませれば、そのまま WordPress を使いはじめることができます:
2014051509


この WordPress の例に限らず、Stackato の App Store には初めから使えるアプリケーションが数多く用意されているので、これらを使ってアプリケーションをすぐに構築したり、ミドルウェア環境を手早く用意する、といったことができそうです。この WordPress アプリケーションの場合は 128MB メモリ環境で動作するようなので、これ1つ作った時点であればまだまだ余裕があるので他のアプリケーションを同時に作って動かす、ということもできると思っています(他のリソースはともかくメモリ的には)。

今回使った Stackato の mini Cloud Foundry 環境の場合はメモリ上限が 4GB と比較的小規模運用が前提になっていますが、この範囲で収まる使い方であれば、社内やチーム内利用には充分すぎる環境だと思います。仮に収まりきらなくなった場合でも、(有料の)上位エディションに移行したり、各社から提供されている Cloud Foundry ベースの環境に移行ことで運用先に困ることはないと思っています。 

こういう移行選択肢がある、ということがオープン環境の素晴らしいところです。


このページのトップヘ