[戲劇] 韓劇 - 紳士的品格

前陣子一直用它當作測資，當程式寫完後，就順便把他看完了 XD 好久沒有跳脫生活好好欣賞一部戲了！好笑的是...我都熬夜看，大概七天看完吧，甚至面試新人時，新人還說：請問...你們很常加班嗎？你看起來好像很累 囧

我記得碩班時代還滿自豪的跟同學說：ㄟ，我用兩倍數看完某某戲劇、動漫。這部戲應該算是最近第一次沒用加速看完 XD 有興趣可以在 LiTV.tv - 紳士的品格 上觀看正版戲劇！

簡短的分享，還滿享受劇中四位熟男的感情，可以在任何時候拋下手邊的事物、甚至犧牲睡眠來聚在一起，只為了朋友有難！想想，周邊若真的要說的話，大概就像參加大學同學的婚宴時，提早到的反而被抓去當伴男闖關 XD 大概有類似的 fu 吧。

這部戲大家對它褒貶皆有，有人會覺得女主角做作，我反而覺得女主角咬嘴唇演戲還滿自然 XD 且因為演員都頗有年紀的，可能不見得會被時下年輕人接受。這齣是 2012 年的韓劇，除了享受四男的友情外，則是劇中的配樂，都讓我想買原聲帶了！有興趣可以翻翻 PTT 鄉民整理的清單：[LIVE] 《紳士的品格》Ep20 最終回。阿，還有，其實我一開始認錯女主角，以為是河智苑 :P 覺得他們長得真像啊！其實他倆都是挺厲害的演員，有興趣可以翻翻 wiki 簡介：

• 金荷娜
• 河智苑

在台灣...在 35~40 歲之間的演員，不知代表人物會是誰？我大概只會想到舒淇吧。不知下次再好好看戲劇會是何時了。這齣也會讓我想起...日劇，不能結婚的男人。

[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;
}

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-galaxy install changyy.find-package
• https://github.com/changyy/ansible-role-find-package
• 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

Ansible 筆記 - 讓 Server 主動更新的方式

這陣子使用 Ansible 進行大部分的機器發佈，也進入了另一個瓶頸：如何讓 Server 自動啟動後也能更新至最新版。我把它當作 Server 主動更新的流程。

目前搭配 Jenkins + git，可以定期追蹤是否要出新版，一旦決定出新版後，就是一道道 Ansible 指令執行完成發佈。在架設 AWS Auto Scaling 時，將碰到服務量變大時，將會自動開啟機器，此時這個機器狀態是有機會是過時的，這時需要讓這些機器開啟啟動時進行軟體更新，來確保得到的資料是最新的。

透過 Dynamic Inventory 架構，仿造 AWS EC2 External Inventory Script 來執行，動態塞 host 資訊給 Ansible 即可，例如：

$ cat bin/echo.sh
#!/bin/bash
echo "{\"$HOST\":$DATA}"

$ HOST=target DATA=[\"server_ip1\",\"server_ip2\"] bash bin/echo.sh                                                
{"target":["server_ip1","server_ip2"]}

$ ANSIBLE_HOST_KEY_CHECKING=false HOST=webserver DATA=[\"localhost\",\"127.0.0.1\"] ansible webserver -i bin/echo.sh -m raw -a date -k
SSH password:
127.0.0.1 | success | rc=0 >>
Thu Nov 25 11:23:26 UTC 2015


localhost | success | rc=0 >>
Thu Nov 25 11:23:26 UTC 2015

因此，整個設計架構就是讓 servers 帶足資訊到發動 Deploy(ansible commands) server 請他更新自己即可！

[PHP] 尚未設定 phpMyAdmin 資料庫，某些進階功能將無法使用 @ Ubuntu 14.04

很久沒用 PHPMyAdmin 了，因為是都改用 Sequel Pro 啦！但開放給同事還是要用 PHPMyAdmin 就是了。簡言之，架設 PHPMyAdmin 後，在 /etc/phpmyadmin/config.inc.php 有個 controluser 跟 controlpass 要設定，之前都是偷懶用 root 權限，這次仔細研究一下，其實只要讓 controluser 可以管理 phpmyadmin database 即可，要限縮權限可以限縮到只能看到 phpmyadmin 資料庫！

至於 phpMyAdmin 資料庫未建立的，可以用以下招數進行處理：

$ ls /usr/share/doc/phpmyadmin/examples/create_tables.sql.gz
$ cp /usr/share/doc/phpmyadmin/examples/create_tables.sql.gz . && gunzip create_tables.sql.gz
$ mysql -h hostname -u controluser -p < create_tables.sql

如此一來，就會建立 phpmyadmin 資料庫，以及一堆 phpmyadmin.pma__* 開頭的資料表。

此外，如果在 AWS RDB 開很多 DB server 時，可以偷懶在 /etc/phpmyadmin/config.inc.php 添加位置，並且做完上述動作後，大家就可以透過 PHPMyAdmin 連線使用了！

$cfg['Servers'][$i] = $cfg['Servers'][$i-1];
$cfg['Servers'][$i]['host'] = 'new-aws-db-server-hostname';
$cfg['Servers'][$i]['controluser'] = 'phpmyadmin-pma-controller';
$cfg['Servers'][$i]['controlpass'] = 'password';
$i++;