顯示具有 ci 標籤的文章。 顯示所有文章
顯示具有 ci 標籤的文章。 顯示所有文章

2018年1月27日 星期六

[PHP] 使用 PHP built-in web server 及 PHP CodeIgniter framework

回想起來,我大概斷斷續續用了 CodeIgniter 七年了,最近才準備在本地開發 XD 開發上就在想 node.js 都有 webpack 等工具了,為啥 PHP 開發上還要先架設個 Web server 而感到納悶。

然而,其實 PHP 早已有 built-in web server 了,雖然只是 single-thread 但在開發上已經非常夠用,就來摸一下怎樣整再一起

$ cd project_web_document_root
$ php -S localhost:8000


接著就在 http://localhost:8000 就可以運行了!
然而,許多 web framework 都靠 routing 把 requests 統一集中到一支程式判斷,似乎已經是個非常基本的設計概念,那在 php built-in web server 也是可以的,他可以設定 routing 機制

$ cd project/web
$ cat ../tools/routing.php
$BASE_DIR = __DIR__ . '/../web' ;
if (file_exists($BASE_DIR . $_SERVER['REQUEST_URI']))
return false;
$_SERVER['SCRIPT_NAME'] = '/index.php';
include_once ($BASE_DIR . '/index.php');
$ php -S localhost:8000 ../tools/routing.php
PHP 7.0.27 Development Server started at Tue Jan 23 12:31:32 2018
Listening on http://localhost:8000
Document root is C:\Users\user\Desktop\ci-project\web
Press Ctrl-C to quit.


更多筆記:changyy/codeiginiter-and-php-built-in-web-server

2016年7月20日 星期三

NGNIX 與數個 PHP CodeIgniter 專案部署問題:使用虛擬目錄切該各個專案

最近處理某個老專案,裡頭有多個 PHP CI Project,配置在同一台 Web Server,原本採用 Apache Web Server 設定相安無事,直到搬到 Nginx 才發現頭很痛 XD 若使用 Nginx 部署一個 CI Project 是很容易的,但使用虛擬目錄則會面臨一些問題。

這個原因是建構在部署專案時,採用 Apache Alais 跟 Requests Rewrite 方式,非常便利 Requests URI 導向至指定的 PHP CI Project:

# Apache Web Server
Alias /prefix/project /path/ci/project
<Directory /path/ci/project>
Options FollowSymLinks
DirectoryIndex index.php
AllowOverride None
Require all granted
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /prefix/project
RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
        </IfModule>
</Directory>


其中 /prefix 是個虛擬的目錄,然而,在 Nginx 環境中,若要採用類似的架構時,就會需要處理一些問題,包含要做 requests uri 或 php script filename 的更新等,若 PHP CI Project 有提供 Web UI 時,就還得處理 css/js/image 的 requests 導向。

最終的解法:

# static files
location ^~ /prefix/project/assets/ {
alias "/path/ci/project/assets/";
}

# php requests
location ^~ /prefix/project {
root "path/ci/project";
try_files $uri $uri/ /prefix/project/index.php?$query_string;

location ~ \.php$ {
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_read_timeout 180;
fastcgi_buffer_size 64k;
fastcgi_buffers 512 32k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
fastcgi_index  index.php;
include fastcgi_params;

set $target_fastcgi_script_name $fastcgi_script_name;
if ($target_fastcgi_script_name ~ ^/prefix/project/(.*)$) {
set $target_fastcgi_script_name /$1;
}
fastcgi_param SCRIPT_FILENAME $document_root$target_fastcgi_script_name;
}
}


此外,若想多了解 nginx location 的優先順序,可以參考這則: Nginx location priority - Stack Overflow

2015年12月25日 星期五

[Linux] 解決 PHP CodeIgniter 在 Nginx 環境中 $_REQUEST 永遠為空

這塊只是 Nginx 的 try_files 的地方未補好引起的,我有點忘了當初是在哪邊找到的 XD 剛看一下 Nginx 的官網的確也是這樣寫:

https://www.nginx.com/resources/wiki/start/topics/recipes/codeigniter/
location / {
# Check if a file or directory index file exists, else route it to index.php.
try_files $uri $uri/ /index.php;
}


這樣的環境下,在 PHP CodeIgniter 裡頭,每次想要從 $_REQUEST 取資料都會為空

<?php
print_r($_REQUEST);


解法就是將 $query_string 資訊帶入即可:

location / {
# Check if a file or directory index file exists, else route it to index.php.
try_files $uri $uri/ /index.php?$query_string;
}

2015年11月27日 星期五

DevOps 筆記 - 使用 Jenkins、Git、RPM、Ansible、Slack 建置持續整合架構(Continuous integration)

今天終於端出一盤比較好吃的菜了,用料有點雜筆記一下吧!之前已經用 Jenkins + Git + Slack 可以做到持續發布跟通知開發者了,但面對 AWS Auto Scaling 議題還是頗抖的,因為建立 AMI (Amazon Machine Image) 後,機器的狀態被保留在某一刻,這時服務量一大自動開啟機器時,就會出現服務更新的需求。原先同事採用 Puppet 方案,但仍不適合處理 Auto Scaling 的問題,因為 Puppet 需要比較強的關係式(Server/Client認證),雖然硬做也是 ok 的,但要一直維護 Server/Client 架構還是頗累,所幸有了 Ansible 的出現!這提供比較分散式的管理架構,Server 跟 Client 都是透過 keypair + ssh remote command 溝通的。

粗略配置作法:
  • Git
    • 主要特色還是 branch 的規劃,跟公司文化有關
      • master:正式網站的狀態
      • alpha:內部最新網站狀態
      • develop:最新程式碼
    • 開發者都是從 develop branch 開發服務,當有版本要釋出時,merge 進 alpha branch 後,發佈到 alpha site 測試,妥當後再把 alpha branch merge 進 master branch
      • 概念上有點從 develop -> alpha -> master 角度
      • 若有 hotfix 時,從 master 產生 branch 修正後,在 merge 回 alpha 跟 develop
      • 在 alpha site 測試出問題時,不斷地在 alpha branch 處理,到最後才 merge 回 develop branch,以及發佈到 master branch
    • 透過 Jenkins 每一次發版時,會下 git tag 標記狀態
      • develop-version-number
      • alpha-version-number
      • production-version-number
    • 相關資料:A successful Git branching model
  • Jenkins 
    • 新增 Slack Notification Plugin/Version Number Plug-In
    • 權限設定,為了不要暴露太多專案給開發者,做了簡易的權限管控
      • 設定全域安全性
        • 安全性領域:採用 Jenkins 內建使用者資料庫 且不允許註冊
        • 授權:採用專案型矩陣授權策略
          • 每一個 task 都可以自訂可以觀看的使用者
    • 管理方面,新增工作分成 build 跟 deploy 兩種
      • build 就是把 source code 包成 RPM ,方便作業系統管理和除錯追蹤,另外,對於開發者測試機的準備也有幫助
        • 取得最新程式碼後,透過 RPMBuild 包裝起來,擺至指定位置
        • 每一次 build 都會下 git tag 標記版本狀態,方便之後除錯
        • 若封裝過程可以接觸到 git 資訊,則把 source code 最後 3 筆 commit log 拉出來製作版本資訊
          • git log -3 --pretty=format:"{\"commit\":\"%H\",\"update\":\"%ad\",\"author\":\"%an\"}"
      • deploy 就是透過 ansible 進行發佈,因此也可以把 ansible 操作用 git 管理
        • 發布過程中,第一步先到指定位置找出最新的 RPM files
        • 第二部透過 AWS EC2 API 得知待更新機器列表
        • 透過 ssh remote command 進行機器更新
        • 盡量把所有動作濃縮至 Ansible command,而透過 Jenkins Web UI 撰寫幾個指令就好 
      • 工作通知
        • 每一次 build 或 deploy 都可以透過 slack plugin 將更新訊息發佈至指定頻道通知相關開發者
      • 採用輪詢 SCM 方式,由 Jenkins 主動確認程式碼狀態,以此決定是否出 build ,不採用 git hook 等被動方式進行工作任務
        • 無法規範開發者 git push 行為,擔心 push 太多造成大量 build event
      • build 完畢後,可以設立相關專案,自動進行 deploy 任務
  • AWS
    • 透過 AIM 建立一個只有 AmazonEC2ReadOnlyAccess 權限的帳號
    • 對於需被管理的機器,都透過 Tag 標記管理
      • 使用 AWS EC2 API 來動態查詢指定的機器,以此取得機器列表,例如指定 ELB 裡所有的機器
    • 關於 Auto Scaling
      • 由於機器 IP 非固定,在不同 data center 溝通容易踩到 Security Group 限制,建議還是把服務以 data center 切開
        • 例如有美西跟日本時,若 db server 開在美西,那需要存取此 db server 的機器就擺在美西就好,這樣 Security Group 比較好做(類似限制 LAN 即可)
  • Ansible
    • 將 RPM 複製到機器上安裝,在 Ubuntu server 可偷懶用 alien :P
    • 依照腳本,進行機器的環境配置,如 limits、web server 等
    • 埋入一個 boot script ,當開機時透過 ssh remote command 向 deploy server 要求更新自己
以上使用的相關資源:
  • RPM 打包目錄專用
    • https://github.com/changyy/rpm-builder
    • 若打包目錄有 .git 時,會抓出最後幾筆 commit log 塞進 version.json 檔案內,可協助往後的偵錯
    • 由於 RPMBuild 很吃環境變數,面對 Jenkins 同時出 build 會衝到共用資源的部分,在此已經透過修改 $HOME 目錄來避開共用資源的問題,因此不用再擔心 Jenkins 一次只能出一個 build
  • AWS EC2 機器查詢
    • http://docs.ansible.com/ansible/intro_dynamic_inventory.html#example-aws-ec2-external-inventory-script
    • Jenkins 建置範例(script),只要修改 yml 檔案名稱即可:
      • develop site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-develop.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
      • alpha site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-alpha.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
      • production site
        • export ANSIBLE_HOST_KEY_CHECKING=False
          export EC2_INI_PATH=$WORKSPACE/dynamic-inventory-ec2.ini
          export AWS_ACCESS_KEY_ID=XXX
          export AWS_SECRET_ACCESS_KEY=OOO
          export DEPLOY_TARGET=site-production.yml

          ansible-playbook $WORKSPACE/$DEPLOY_TARGET -i $WORKSPACE/bin/ec2.py --private-key=$HOME/.ssh/ansible-deploy.pem
  • Ansible 找尋最新 package files
  • Ansible 設置自動要求更新
    • $ ansible-galaxy install changyy.self-update 
    • https://github.com/changyy/ansible-role-self-update
    • 比較雜亂一點,原理:
      • 機器部署時,建立一個 auto update script (負責通報 deploy server 更新指定 host),將此 script 埋入開機執行區( /etc/rc.local )
        • 當機器啟動時執行該 script ,把部署此機器該有的資訊以 ssh remote command 丟給 deploy server 
      • 該 ssh remote command 包含的動作
        • 登入 deploy server 並切換至 ansible workspace
        • 透過 dynamic inventory 建立動態 host 資訊
        • 執行 ansble-playbook 批次指令
      • Deploy server workspace 範例:
        • $ cat bin/echo.sh
          #!/bin/bash
          echo "{\"$HOST\":$DATA}"

          $ HOST=MySite DATA=[\"SERVER_IP\"] bash bin/echo.sh
          {"MySite":["SERVER_IP"]}

          $ cd ansible-deploy-dir && \
          ANSIBLE_HOST_KEY_CHECKING=false \
          HOST=MySite \
          DATA=[\"SERVER_IP\"] \
          ansible-playbook MySite.yml \
          -i bin/echo.sh \
          --private-key=mysite-login-key.pem

2015年10月20日 星期二

透過 Bitbucket、Jenkins、Slack 打造持續發佈打屁等自動化架構

透過 Bitbucket 作為 git 版本控制的服務托管處,而 slack 則是工程師打屁好去處,而 Jenkins 則是打造一鍵發佈的便利介面。雖說連續動作也可以化簡成一隻 script,但能夠端出 Web UI 介面,還是大勝!

首先提一下 git 版本控制,透過 Bitbucket 服務,人多的話還是花一點小錢了!在 Bitbucket 可以建立群組概念,大概可粗略分成 Administrators、Developer、Deploy 三個個群組(若要細分則可以變成 iOS Developer、Android Developer、Web developer 或是甚至以專案為單位等),這邊設計讓所以有成員都進 Developer 並且 Developer group 預設對所有專案擁有 read only 權限。而埋了一個機器人在 deploy group 中,預設沒有任何權限(機器人不需進入 developer group)。當有專案要搭建自動發佈流程時,請專案擁有者或管理者,讓專案可供 Deploy Group 有 write 權限,這是為了 Jenkins 發佈新版時,能夠打個 tag 記錄狀態。而 Deploy group 裡的機器人,就只需添加個 ssh key 即可。

在 Jenkins Web UI:
  1. 建立作業 => 填寫作業名稱 => 建置 Free-Style 軟體專案 
  2. 設定 Slack Notifications => 進階設定 Team Domain、Integration Token 和 Project Channel => Test Connection
  3. 原始碼管理 => git => git@bitbucket.org:group/project.git => Credentials 搭配 Bitbucket SSH key => Branches to build 要指定 => Additional Behaviours => Advanced sub-modules behaviours => Recursively update submodules
  4. 建置環境 => Create a formatted version number => 設定 Environment Variable Name (VERSION) => Version Number Format String (1.0.0) 
  5. 建置 => 例如拉完程式碼後想要做的事,如 /path/project-build.sh project-name  $VERSION $BUILD_NUMBER $JOB_NAME 
  6. 建置後動作 => Git Publisher => Push Only If Build Succeeds => Tag to push (develop-$VERSION-$BUILD_NUMBER) => Target remote name (origin)
如此一來,開發者可以用 bitbucket 持續開發,並且用不同 branch 管理,如 develop branch、alpha branch、release branch 等,而 Jenkins 就建立三個任務,分別從上述 branch 取資料出來使用,而在 "建置" 跟 "建置後動作" 都可以對各個 branch 操作做細部的調整。

例如"建置"中的 /path/project-build.sh 的程式,就可以包含建立 RPM 、更新 repos 等行為,同時有環境變數 $VERSION $BUILD_NUMBER $JOB_NAME 拿來輔助。

以上就是將程式碼編譯打包的流程,若要再添加上 deploy 流程時,可以再額外建置一個 Jenkins 工作,裡頭只需填寫 slack 通知和建置項目,而建置項目就可以一隻 script 處理發佈的動作即可,而在相對應工作中,把剛剛的 deploy task 建立相依性即可。

如此一來,當 Jenkins 每一次建置時,各個階段的都丟訊息至 slack 指定的頻道,等同通知相關人員。若需要做類似 git hook 來達成自動建置時,可以使用 Jenkins "建置觸發程式" 裡的輪詢  SCM 項目,例如每 10 分鐘確認一次 bitbucket 專案狀況等,達成類似 git hook 行為。

2015年10月6日 星期二

[PHP] 處理 PHP CodeIgniter 與 apache web server、nginx 的 Rewrite Rules

之前比較常用 Apache Web server ,在使用 PHP CodeIngiter 時,常常設定 Rewrite Rules 時,需要做一些手腳,例如:http://hostname/ci 想要瀏覽到 PHP CodeIgniter Project,而 ci 這個並非實體目錄,且 PHP CI Project 並非擺在 DocumentRoot 裡,這時就有很多環境變數需處理。

由於要符合 PHP CodeIgniter 的 routing rules,必須把 /ci 這個 path 給去掉,在 Apache Web server 透過 RewriteBase 處理,而 Nginx 又更麻煩一點,需處理 fastcgi_param REQUEST_URI 跟 fastcgi_param SCRIPT_FILENAME 資訊。

Apache 的設定:

Alias /ci /data/ci-project
<Directory /data/ci-project>
       Options FollowSymLinks
       DirectoryIndex index.php
       AllowOverride None

       Require all granted
       <IfModule mod_rewrite.c>
               RewriteEngine On
               RewriteBase /ci

               RewriteCond %{REQUEST_URI} ^system.*
               RewriteRule ^(.*)$ /index.php?/$1 [L]
 
               RewriteCond %{REQUEST_URI} ^application.*
               RewriteRule ^(.*)$ /index.php?/$1 [L]

               RewriteCond %{REQUEST_FILENAME} !-f
               RewriteCond %{REQUEST_FILENAME} !-d
               RewriteRule ^(.*)$ index.php?/$1 [L]
       </IfModule>
</Directory>


Nginx 設定:

        set $request_prefix '/ci/';
        set $ci_sys_dir '/opt/actions-channel-api/';

        location /ci/ {
                alias $ci_sys_dir;
                index  index.php index.html index.htm;

                try_files $uri $uri/ /ci/index.php?$query_string;
        }
        location ~* \.php$ {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_split_path_info ^(.+\.php)(.*)$;
                include fastcgi_params;

                set $target_request_uri $request_uri;
                if ($target_request_uri ~ ^/ci/(.*)$ ) {
                        set $target_request_uri /$1;
                }
                fastcgi_param REQUEST_URI $target_request_uri;

                set $target_fastcgi_script_name $fastcgi_script_name;
                if ($target_fastcgi_script_name ~ ^/ci/(.*)$ ) {
                        set $target_fastcgi_script_name $1;
                }
                fastcgi_param SCRIPT_FILENAME $ci_sys_dir$target_fastcgi_script_name;
        }


其他 Nginx 筆記:

  • alias 的數值記得要補上最後的 "/" ;alias 跟 root 的最大差別是 alias 的位置不需要在 document root  裡頭
  • 在 try_files 流程中,一旦符合條件後,就不會再執行該 nginx location 底部項目,因此還是把 php handler 拉到最外層,而不要全部都寫在 location /ci/ 此區塊裡頭
  • nginx 可定義很多環境變數,若想要看它就寫到 log 即可:
    • http {
          log_format proxy ' "$request"  "$status"  "$http_referer"  "$http_user_agent"  $request_time  $upstream_response_time "$ci_sys_dir" "$target_fastcgi_script_name"  "$target_request_uri"  '
      }

2015年4月8日 星期三

PHP CodeIgniter - 透過 Apache RewriteRule 限制 CGI 功能

基於一些開發需求,想要侷限網站的功能。剛好這個網站服務是用 PHP CodeIgniter 開發的,整套都是走 RewriteRule 來進行,例如一個 URL 位置,都一律導向到 PHP CodeIgniter Project 的 index.php?/path 來分析。

假設原本網站有 3 個主要網址,分別是 /api, /shopping, / 等,假設想要讓此網站只開啟 /api 時,這時就可以透過 Apache RewriteRule 來限制:

<VirtualHost *:80>
DocumentRoot /ci-project/
DirectoryIndex index.html index.php index.htm

# empty page
Alias /empty     /var/www/html/

<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

<Directory /var/www/html/>
Options FollowSymLinks
AllowOverride None
DirectoryIndex index.html index.php index.htm
Require all granted
Satisfy Any
</Directory>

<Directory /ci-project>
Options FollowSymLinks
DirectoryIndex index.php
AllowOverride None
#AllowOverride All
Require all granted
Satisfy Any

<IfModule mod_rewrite.c>
RewriteEngine On
#LogLevel alert rewrite:trace6
RewriteBase /

# disable index.php with empty QUERY_STRING
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^index\.php$ /empty/ [L]

RewriteCond $1 !^(index\.php|images|css|js|favicon\.ico)
# enable /api only
RewriteCond $1 ^api.*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ ./index.php?/$1 [L,QSA]
</IfModule>
</Directory>
</VirtualHost>


如此一來,只要使用者逛 / 位置,則會顯示 /var/www/html 的資料,而逛 /api 系列時,則是可以正常引導到 PHP CodeIgniter 相關程式碼來處理。

2014年3月18日 星期二

[PHP] CodeIgniter 處理多層子目錄 Routing 問題

[PHP] CodeIgniter 處理多層子目錄 Routing 問題

過去使用 CodeIgniter 一直以為在 application/controller 裡的目錄結構可以無限延伸使用,如:

application/conotrollers/service/dashboard/product.php
application/conotrollers/service/api/product.php
application/conotrollers/service/welcome.php
application/conotrollers/welcome.php


當瀏覽 hostname/ 可以由 conotrollers/welcome.php 處理,瀏覽 hostname/service/welcome 則由 conotrollers/service/welcome.php 處理,一切正常。

但瀏覽 hostname/service/api/product 和 hostname/service/dashboard/product 時,卻噴 404 Page Not Found 訊息。

一開始以為 nginx rules 設定錯誤,追一下 CodeIgniter 的 source code 後,發現 CodeIgniter 的程式碼沒有用遞迴或等價方式去搜尋子目錄,再透過相關關鍵字才發現,關於多層子目錄的需求,則只能透過指定 routing 的設定方式進行,但對應到還是一層目錄結構:

例如 hostname/service/dashboard/product 用法:

$ vim application/config/routes.php

$route['service/(:any)/(:any)'] = 'service_$1/$2';


而目錄結構更新為:

application/conotrollers/service_dashboard/product.php
application/conotrollers/service_api/product.php
application/conotrollers/welcome.php


簡言之,就是以 application/controllers 為基準,頂多再加一層 subdir 而已,而想要 uri 有多層的含義,只能自定 route 來達到。

2014年1月8日 星期三

[Linux] 簡易的測試機 - Nginx + Codeigniter + PHP + MySQL + PhpMyAdmin @ Linode Ubuntu 12.04 TLS

有點久沒在 Linode 打滾了,記得...我的信用卡還因為 Linode 的事件花錢換了一張新的 Orz 這次著重在測試機,所以先偷懶不裝防火牆

更新系統:

$ apt-get update && apt-get upgrade && apt-get dist-upgrade

簡易管理員:

$ adduser userid
$ vim /etc/group
sudo:userid


更新 hostname (建議不要有 "-",過去的經驗是 Hadoop 會找不到機器):

$ vim /etc/hostname
$ hostname -F /etc/hostname
$ vim /etc/hosts
127.0.1.1 YourName


簡易資安管理:

$ apt-get install denyhosts
$ vim /etc/hosts.allow
# whilelist
sshd: MyIP : allow


設定開發環境:

$ apt-get install nginx php5-cli php5-fpm mysql-server phpmyadmin

$ nginx -v
nginx version: nginx/1.1.19
$ php -v
PHP 5.3.10-1ubuntu3.9 with Suhosin-Patch (cli) (built: Dec 12 2013 04:27:25)
$ php5-fpm -v
PHP 5.3.10-1ubuntu3.9 (fpm-fcgi) (built: Dec 12 2013 04:31:25)


設定 nginx + PHP + Codeigniter:

$ vim /etc/nginx/sites-available/default
server {
# …
index index.html index.htm index.php;
# …
        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
 
                # With php5-cgi alone:
                fastcgi_pass 127.0.0.1:9000;
                # With php5-fpm:
                #fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
        # http://wiki.nginx.org/Codeigniter
        location /ci_proj/ {
               index index.html index.htm index.php;
               try_files $uri $uri/ /ci_proj/index.php;
        }
# …
}
$ service nginx restart


設定 nginx + PHPMyAdmin:

$ ln -s /usr/share/phpmyadmin/ /usr/share/nginx/www/phpmyadmin
$ sudo service php5-fpm restart


其中 /etc/phpmyadmin/config-db.php 有標記預設登入的帳蜜,當然,也可以用當初設定 mysql 的 root 登入,建議新增帳號後,把 root 登入關掉, 共有兩處:

$ vim /etc/phpmyadmin/config.inc.php
/* Authentication type */
$cfg['Servers'][$i]['AllowRoot'] = FALSE;


其他資料庫匯入:

$ mysql -u db_account -p -D db_name < db_backup.sql