Ⅰ 如何配置一個 Docker 化持續集成的 php 開發環境
首先，我們得知道什麼才是好的開發環境， 對於我而言，一個好的開發環境需要具備以下幾個特點：
可隨意使用。我必須可以隨意刪除和創建新的環境。
快速啟動。我想要用它工作時候，它立馬就能用。
易於更新。在我們行業中，事物發展變化非常快，必須能讓我很容易將我的開發環境更新到新的軟體版本。
而Docker都支持以上這些特點，甚至更多。你幾乎可以即時銷毀和重建容器，而更新環境只需要重建你當前使用的鏡像即可。
什麼是PHP開發環境
目前Web應用錯綜復雜，PHP開發環境需要很多的東西，為了保證環境的簡單性，需要做各種各樣的限制。
我們這次使用Nginx、PHP5-FPM、MySQL來運行Synmfony項目。由於在容器中運行命令行會更復雜，所以這方面的內容我會放到下一篇博客中再說。
Pet 與 Cattle
另一個我們要討論的重點是：我們要把開發環境部署在多容器還是單容器中。 兩種方式各有優點：
單容器易於分發、維護。因為它們是獨立的，所有的東西都運行在同一個容器中，這點就像是一個虛擬機。但這也意味著，當你要升級其中的某樣東西（比如PHP新版本）的時候， 需要重新構建整個容器。
多容器可以在添加組件時提供更好的模塊化。因為每個容器包含了堆棧的一部分：Web、PHP、MySQL等，這樣可以單獨擴展每個服務或者添加服務，並且不需要重建所有的東西。
因為我比較懶，加上我需要在我的筆記本上放點別的內容，所以，這里我們只介紹單個容器的方法。
初始化工程
首先要做的是初始化一個新的Symfony工程. 推薦的方法是用composer的create-project命令。本來可以在工作站上安裝composer，但是那樣太簡單了。這次我們通過Docker來使用它。
我之前發過一篇關於Docker命令的文章：make docker commands（好吧，我說謊了，我本來把它寫在這篇文章中了，然後覺得把它獨立出來會比較好）。
不管怎麼樣，你可以讀一下。接下來如果還沒有composer命令的話，你可以創建一個屬於自己的composer 別名。
$ alias composer="docker run -i -t -v \$PWD:/srv ubermuda/composer"
現在你可以初始化Symfony工程了：
$ composer create-project symfony/framwork-standard-edition SomeProject
帥呆了！下面來點實在的工作。(省略了博主自娛自樂的一堆balabla....原文:Awesome. Give yourself a high-five， get a cup of coffee or whatever is your liquid drug of choice， and get ready for the real work.)
容器
構建一個運行標准Symfony項目且自給自足的容器相當容易，只需要安裝好常用的Nginx、PHP5-FPM和MySQL-Server即可，然後把預先准備好的Nginx的虛擬主機配置文件扔進去，再復制一些配置文件進去就完事了。
本容器的源代碼在GitHub上的 ubermuda/docker-symfony倉庫中可以找到。 Dockerfile 是Docker構建鏡像要用到的配置文件，我們來看一下:
FROM debian:wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update -y
RUN apt-get install -y nginx php5-fpm php5-mysqlnd php5-cli mysql-server supervisor
RUN sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf
RUN sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf
RUN sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
ADD vhost.conf /etc/nginx/sites-available/default
ADD supervisor.conf /etc/supervisor/conf.d/supervisor.conf
ADD init.sh /init.sh
EXPOSE 80 3306
VOLUME ["/srv"]
WORKDIR /srv
CMD ["/usr/bin/supervisord"]
我們通過擴展 debian:wheezy 這個基礎鏡像開始，然後通過一系列的sed命令來配置Nginx和PHP5-FPM。
RUN sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf
RUN sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf
RUN sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
這里我們要做兩件事。 首先配置PHP5-FPM和Nginx讓他們在前台運行以便supervisord可以追蹤到他們。
然後，配置PHP5-FPM以指定的用戶運行Web-Server，並處理好文件許可權。
接下來需要安裝一組配置文件，首先是Nginx的虛擬主機配置文件vhost.conf:
server {
listen 80;
server_name _;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
root /srv/web;
index app_dev.php;
location / {
try_files $uri $uri/ /app_dev.php?$query_string;
}
location ~ [^/]\.php(/|$) {
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}
}
因為我們不需要域名，所以把server_name設成了_（有點像perl的$_佔位符變數）， 並配置根目錄（document root）為/svr/web， 我們會把應用程序部署在/srv下，剩下的就是標準的Mginx + PHP5-FPM配置.
因為一個容器每次只能運行一個程序， 我們需要supervisord（或者任何別的進程管理器，不過我比較中意supervisord）。幸運的是， 這個進程管理器會產生我們需要的所有進程！下面是一小段supervisord的配置：
[supervisord]
nodaemon=true
[program:nginx]
command=/usr/sbin/nginx
[program:php5-fpm]
command=/usr/sbin/php5-fpm
[program:mysql]
command=/usr/bin/mysqld_safe
[program:init]
command=/init.sh
autorestart=false
redirect_stderr=true
redirect_stdout=/srv/app/logs/init.log
這里我們需要做的是定義所有的服務， 加上一個特殊的program:init進程，它不是一個實際的服務，而是一個獨創的運行啟動腳本的方式。
這個啟動腳本的問題在於，它通常需要先啟動某些服務。比如，你可能要初始化一些資料庫表，但前提是你得先把MySQL跑起來，一個可能的解決辦法是，在啟動腳本中啟動MySQL，然後初始化表，然後為了防止影響到supervisord的進程管理，需要停掉MySQL，最後再啟動supervisord。
這樣的腳本看起來類似下面這樣：
/etc/init.d/mysql start
app/console doctrine:schema:update --force
/etc/init.d/mysql stop
exec /usr/bin/supervisord
看起來丑爆了有木有，咱換種方式，讓supervisor來運行它並且永不重啟。
實際的init.sh腳本如下：
#!/bin/bash
RET=1
while [[ RET -ne 0 ]]; do
sleep 1;
mysql -e 'exit' > /dev/null 2>&1; RET=$?
done
DB_NAME=${DB_NAME:-symfony}
mysqladmin -u root create $DB_NAME
if [ -n "$INIT" ]; then
/srv/$INIT
fi
腳本先等待MySQL啟動，然後根據環境變數DB_NAME創建DB，默認為symfony， 然後在INIT環境變數中查找要運行的腳本，並嘗試運行它。本文的結尾有說明如何使用這些環境變數。
構建並運行鏡像
萬事俱備只欠東風。我們還要構建Symfony Docker鏡像， 使用docker build命令:
$ cd docker-symfony
$ docker build -t symfony .
現在，可以使用它來運行你的Symfony工程了:
$ cd SomeProject
$ docker run -i -t -P -v $PWD:/srv symfony
我們來看看這一連串的選項分別是幹嘛的:
-i 啟動交互（interactive）模式， 也就是說，STDIO（標准輸入輸出）連接到了你當前的終端上。當你要接收日誌或者給進程發送信號時，它很有用。
-t 為容器創建一個虛擬TTY， 它跟-i是好基友，通常一起使用。
-P 告訴Docker守護進程發布所有指定的埠， 本例中為80埠。
-v $PWD:/srv 把當前目錄掛載到容器的/srv目錄。掛載一個目錄使得目錄內容對目標掛載點可用。
現在你還記得之前提到的DB_NAME和INIT環境變數了吧，幹嘛用的呢：用於自定義你的環境。 基本上你可以通過 docker run的-e選項在容器中設置環境變數，啟動腳本會拿到環境變數，因此，如果你的DB名為some_project_dev， 你就可以這么運行容器：
$ docker run -i -t -P -v $PWD:/srv -e DB_NAME=some_project_dev symfony
INIT 環境變數就更強大了，它允許你啟動時運行指定的腳本。比如， 你有一個bin/setup腳本運行composer install命令並且設置資料庫schema:
#!/bin/bash
composer install
app/console doctrine:schema:update --force
用-e來運行它：
$ docker run -i -t -P \
-v $PWD:/srv \
-e DB_NAME=some_project_dev \
-e INIT=bin/setup
注意，-e選項可以在docer run中多次使用，看起來相當酷。另外，你的啟動腳本需要可執行許可權（chmod +x）。
現在我們通過curl發送請求到容器，來檢查一下是否所有的東西都像預期一樣工作。首先，我們需要取到Docker映射到容器的80埠的公共埠，用docker port命令:
$ docker port $(docker ps -aql 1) 80
0.0.0.0:49153
docker ps -aql 1 是個好用的命令，可以方便的檢索到最後一個容器的id， 在我們的例子中，Docker 把容器的80埠映射到了49153埠。我們 curl 一下看看。
$ curl http://localhost:49153
You are not allowed to access this file. Check app_dev.php for more information.
當我們不從localhost（譯者註：容器的localhost）訪問dev controller時，得到了Symfony的默認錯誤消息，這再正常不過了， 因為我們不是從容器內部發送 curl 請求的， 所以，可以安全的從前端控制器web/app_dev.php中移除這些行。
// This check prevents access to debug front controllers that are deployed by accident to proction servers.
// Feel free to remove this， extend it， or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(@$_SERVER['REMOTE_ADDR']， array('127.0.0.1'， 'fe80::1'， '::1')) || php_sapi_name() === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}
這些行阻止了任何從localhost以外的地方訪問dev controller。
現在再curl的時候就可以正常工作了，或者用瀏覽器訪問 http://localhost:49153/：
很容易吧！ 現在我們可以快速的啟動、更新環境了，但還是有很多地方需要改進。
Ⅱ 什麼是psr-0，psr-1，psr-2標准
轉自：http://www.nginx.cn/2677.html
FIG組織在制定跟PHP相關規范，簡稱PSR，PSR旨在通過討論我們代碼項目的共同點以找出一個協作編程的方法。
什麼是psr0強調自動載入的方式
下文描述了若要使用一個通用的自動載入器(autoloader)，你所需要遵守的規范：
規范
一個完全標準的命名空間(namespace)和類(class)的結構是這樣的：\*
每個命名空間(namespace)都必須有一個頂級的空間名(namespace)("組織名(Vendor Name)")。
每個命名空間(namespace)中可以根據需要使用任意數量的子命名空間(sub-namespace)。
從文件系統中載入源文件時，空間名(namespace)中的分隔符將被轉換為 DIRECTORY_SEPARATOR。
類名(class name)中的每個下劃線_都將被轉換為一個DIRECTORY_SEPARATOR。下劃線_在空間名(namespace)中沒有什麼特殊的意義。
完全標準的命名空間(namespace)和類(class)從文件系統載入源文件時將會加上.php後綴。
組織名(vendor name)，空間名(namespace)，類名(class name)都由大小寫字母組合而成。
示例
\Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php
\Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
\Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php
空間名(namespace)和類名(class name)中的下劃線
\namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/Class/Name.php
\namespace\package_name\Class_Name => /path/to/project/lib/vendor/namespace/package_name/Class/Name.php
以上是我們為實現通用的自動載入而制定的租野最低標准。你可以利用能夠自動載入PHP 5.3類的SplClassLoader來測答型族試你的代碼是否符合這些標准。
實例
下面是一個怎樣利用上述標准來實現自動載入的示例函數。
<?php
function autoload($className)
{
$className = ltrim($className, '\\');
$fileName = '';
$namespace = '';
if ($lastNsPos = strrpos($className, '\\')) {
$namespace = substr($className, 0, $lastNsPos);
$className = substr($className, $lastNsPos + 1);
$fileName = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR;
}
$fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';
require $fileName;
}
SplClassLoader實現清弊
下面的gist是一個按照上面建議的標准來自動載入類的SplClassLoader實例。這是依據這些標准來載入PHP 5.3類的推薦方案。
什麼是psr1，定義基本代碼規范
本節我們將會討論一些基本的代碼規范問題，以此作為將來討論更高級別的代碼分享和技術互用的基礎。
RFC 2119中的必須(MUST)，不可(MUST NOT)，建議(SHOULD)，不建議(SHOULD NOT)，可以/可能(MAY)等關鍵詞將在本節用來做一些解釋性的描述。
1. 概述
源文件必須只使用 和 這兩種標簽。
源文件中php代碼的編碼格式必須只使用不帶位元組順序標記(BOM)的UTF-8。
一個源文件建議只用來做聲明（類(class)，函數(function)，常量(constant)等）或者只用來做一些引起副作用的操作（例如：輸出信息，修改.ini配置等）,但不建議同時做這兩件事。
命名空間(namespace)和類(class) 必須遵守PSR-0標准。
類名(class name) 必須使用駱駝式(StudlyCaps)寫法 (譯者註：駝峰式(cameCase)的一種變種，後文將直接用StudlyCaps表示)。
類(class)中的常量必須只由大寫字母和下劃線(_)組成。
方法名(method name) 必須使用駝峰式(cameCase)寫法(譯者註：後文將直接用camelCase表示)。
2. 文件
2.1. PHP標簽
PHP代碼必須只使用長標簽()或者短輸出式標簽(<?= ?>)；而不可使用其他標簽。
2.2. 字元編碼
PHP代碼的編碼格式必須只使用不帶位元組順序標記(BOM)的UTF-8。
2.3. 副作用
一個源文件建議只用來做聲明（類(class)，函數(function)，常量(constant)等）或者只用來做一些引起副作用的操作（例如：輸出信息，修改.ini配置等）,但不建議同時做這兩件事。
短語副作用(side effects)的意思是 在包含文件時 所執行的邏輯與所聲明的類(class)，函數(function)，常量(constant)等沒有直接的關系。
副作用(side effects)包含但不局限於：產生輸出，顯式地使用require或include，連接外部服務，修改ini配置，觸發錯誤或異常，修改全局或者靜態變數，讀取或修改文件等等
下面是一個既包含聲明又有副作用的示例文件；即應避免的例子：
<?php
// 副作用：修改了ini配置
ini_set('error_reporting', E_ALL);
// 副作用：載入了文件
include "file.php";
// 副作用：產生了輸出
echo "<html>\n";
// 聲明
function foo()
{
// 函數體
}
下面是一個僅包含聲明的示例文件；即應提倡的例子：
<?php
// 聲明
function foo()
{
// 函數體
}
// 條件式聲明不算做是副作用
if (! function_exists('bar')) {
function bar()
{
// 函數體
}
}
3. 空間名(namespace)和類名(class name)
命名空間(namespace)和類(class)必須遵守 PSR-0.
這意味著一個源文件中只能有一個類(class)，並且每個類(class)至少要有一級空間名（namespace）：即一個頂級的組織名(vendor name)。
類名(class name) 必須使用StudlyCaps寫法。
PHP5.3之後的代碼必須使用正式的命名空間(namespace) 例子：
<?php
// PHP 5.3 及之後:
namespace Vendor\Model;
class Foo
{
}
PHP5.2.x之前的代碼建議用偽命名空間Vendor_作為類名(class name)的前綴
<?php
// PHP 5.2.x 及之前:
class Vendor_Model_Foo
{
}
4. 類的常量、屬性和方法
術語類(class)指所有的類(class)，介面(interface)和特性(trait)
4.1. 常量
類常量必須只由大寫字母和下劃線(_)組成。 例子：
<?php
namespace Vendor\Model;
class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
}
4.2. 屬性
本指南中故意不對$StulyCaps，$camelCase或者$unser_score中的某一種風格作特別推薦，完全由讀者依據個人喜好決定屬性名的命名風格。
但是不管你如何定義屬性名，建議在一個合理的范圍內保持一致。這個范圍可能是組織(vendor)級別的，包(package)級別的，類(class)級別的，或者方法(method)級別的。
4.3. 方法
方法名則必須使用camelCase()風格來聲明。
什麼是PSR2定義代碼風格
代碼風格指南
本手冊是基礎代碼規范(PSR-1)的繼承和擴展。
為了盡可能的提升閱讀其他人代碼時的效率，下面例舉了一系列的通用規則，特別是有關於PHP代碼風格的。
各個成員項目間的共性組成了這組代碼規范。當開發者們在多個項目中合作時，本指南將會成為所有這些項目中共用的一組代碼規范。 因此，本指南的益處不在於這些規則本身，而在於在所有項目中共用這些規則。
RFC 2119中的必須(MUST)，不可(MUST NOT)，建議(SHOULD)，不建議(SHOULD NOT)，可以/可能(MAY)等關鍵詞將在本節用來做一些解釋性的描述。