這幾天 debug 的心得之一。

這例子是這樣的：在打包 Docker 容器中安裝 PostgreSQL，並在安裝後就立即啟動服務，做了一些初始化的設定，但是忘了要在設定完成後關掉它，於是就會造成某些資料庫相關的檔案沒有正常關檔。

在之後要用到 PG 時，伺服器雖然表面上正常啟動了，但是背景仍在執行因為之前沒有正常關閉服務而需要跑的復原工作，於是就出現 “psql: FATAL: the database system is starting up” 這個第一眼讀來有點丈二金剛摸不著頭腦的錯誤訊息，同時 PG 也不能正常對外服務，便會造成相關的操作失效。

執行 docker build 的時候，要記得每個步驟都是 run 完就由 docker 寫入差異部份至檔案系統，然後就結束了，這個步驟執行時跑起來的 process，在下一個步驟執行時，是不會留在記憶體待命的，這跟使用其他的 configuration management 軟體來做這類「無人值守」工作時，有很大的不同，務必要記住這點。

• 搬回宜蘭，揮別在台北租房子的日子，開始長途通勤。
• 結婚，告別單身。
• 離開信義區，回到南港區工作。
• 頭一次出國，頭一次去日本，久久不能忘懷當地那種相較於台灣「不過正不足以矯枉」的龜毛做事方式。
• 在 Modern Web 聽到很多場值回票價的演說。
• 看到 Readmoo、想起カーリル，很感慨，對於閱讀社群的經營，別人能，為什麼我不能。
• 因為之前在 development 方面長期拙於實戰，武功退化不少，到了丟辭呈的那段準備交接時間，拿起之前借同事看的 Erlang 書，反而因為腦袋空空，而很能吸收，不較之前認為「Erlang 是個天書語言、函數式語言不曉得在幹嘛」，可謂失之東隅，收之桑榆。
• 對容器化技術、微服務架構，有了一定的認知。配合 Erlang 這樣的語言與平台設計，我覺得簡直是天造地設的組合。
• 被前端技術的治絲益棼嚇著，根本搞不懂這些三不五時冒出來（然後隨即又死掉的）新工具是在幹嘛，於是決定專注在後端的發展。

從八月寫了〈NHK World Premium 從台灣大寬頻類比頻道中消失〉說要去裝衛星碟之後，到本週一晚間才真的實踐，但是這中間其實做了很多功課，才讓整個安裝過程沒有遇到什麼麻煩。在本文就稍加整理心得。

安裝衛星碟的條件

BS 衛星 BSAT 3 大約在方位角 210 度、仰角 60 度左右的位置（這只是大略位置，之後會說明如何取得更精確的），如果估算想要安裝、可以安裝的位置望出去，有障礙物遮蔽，那麼就沒辦法安裝衛星碟了，因為衛星訊號只要稍微偏掉，就收不到，遑論還有遮蔽物在干擾。

針對這個問題，我找到最好的輔助工具，是 Satellite Director 這套 Android app，也是到目前為止我在 Play Store 上看到同類工具中做的最好的。利用它尋找 110.0E BSAT 3A，很容易藉由手機 GPS 與電子羅盤、相機鏡頭三者結合，去觀測衛星位置與目前所在地點中間是否有障礙物。

當然，運用這套 app 的前提，也就是手機的 GPS 與電子羅盤要夠精準。因為我考慮房間位置、衛星方位等因素，打算把衛星碟架在家裡後方，其實是個很尷尬、卻又不得不選擇這裡的地點，因為與對面人家中間僅有很小的視野可以看到天空，所以 GPS 常常要看天候、時間狀況才能取到 Satellite Director 判斷容許的 5m GPS 距離誤差。

至於電子羅盤，這是更難保證精準的感測器，我用過好幾隻 smart phone 和平板電腦，沒遇過一打開就「至少不要偏得太誇張」的，常常偏個 180 度、南方變北方是家常便飯，使用「繞 8 字形校正法」又很難保證確實校正了。這時，去準備一隻實體的指南（北）針做對照組還是必要的，不然像我這樣的安裝環境，很容易誤判可安裝或不可安裝衛星碟。

最後再到 Satellite Finder 網站，在地圖上輸入、找到自家位置，並指向 110E BSAT-3A | BSAT-3C | N-SAT-110 (SUPERBIRD-D)，計算更精準的仰角 (Elevation)、方位角（Azimuth，有分別以磁北與真北為基準的兩個數值），記在紙上備用。

設備、材料、工具準備

確定地理環境可以安裝衛星碟後，我就開始張羅各種設備、材料、工具了。因為我打算 DIY，所以上網看過很多文章後，才把東西備齊。如果是找廠商來安裝，就不用這麼麻煩了，相對地就是要多準備一點預算在廠商師傅的工資上。

先列出我這次施工用到的全部東西，所列價格是台幣：

• 前面提過的指南針，文具店購買，30 幾元。
• 前面提過的 Satellite Director 軟體。
• IO-DATA REC-ON（HVTR-BCTX3）接收機，請網拍從日本帶回，12, 000 元。我不需要藍光光碟錄放機能，一來燒錄片難找，二來我已經有 PS3 可以當 BD player，所以買了這款可用 USB HDD 或 NAS 錄影、還可以用 App 遠端收視的機種。
• TOSHIBA BCA-453K / BCA-453AK 衛星碟，隨接收機加購，2,800 元。若要個別採購請一定要注意自己買的是含支架的 BCA-453AK 還是不含支架的 BCA-453K，我因為要架在鋁窗上，所以買的是前者。這組衛星碟已含 LNB（把衛星碟訊號「聚焦」起來接收的元件），所以不用再買 LNB 了。
• 請廠商製作的兩條各 20m, 10m BS 衛星專用纜線，加上一條「過窗線」，580 元。雖然 BCA-453AK 就有附纜線，但是我要利用過窗線把纜線拉進房間，所以另外去請專業廠商製作纜線。請注意，這種纜線雖然長得跟有線電視用的很像，但是頻寬規格差很多，不能混用。
• 配線槽，90 元。為了讓進房間的纜線好鋪設、不影響觀瞻。
• 螺絲起子。
• 延長線，為了就近接電視與接收機，確認衛星碟有無正確收到訊號。
• 電視，慶幸這個時代是液晶電視當道，不用再扛傳統笨重的 CRT 電視了。

施工

尋星（尋找衛星的簡稱）是整個施工過程中，最讓陌生新手感到畏懼的一項。但是若有基本的、國中生程度的幾何概念，其實很簡單。

首先是支架安裝，這裡一定要確認支架有 90 度垂直，利用簡單的鉛垂法就可以測定，如果支架這個基準點沒有垂直安裝好，那麼之後的衛星碟相對角度都會有誤差，反之，如果支架確實安裝好，那麼尋星會非常簡單。

再來是把碟盤與 LNB 裝好、纜線接上 LNB 預備，然後把碟盤裝上支架。螺絲要暫時鎖在「讓碟盤固定不會亂晃，卻還能維持左右轉動」的「假固定」緊度。碟盤暫時大概指向指南針的南方 （180 度）就好，因為從 180 漸漸調整右轉至 210 度左右其實沒什麼傷腦筋，但是若一開始就想調方位角卻不得法，反調得過頭，就會迷失在「不曉得該往左調還是往右調」的難題中。

所以應該先調整仰角，注意碟盤後的角度刻度，調整到盡可能與之前在 Satellite Finder 得到的數值一致。我的經驗是，若傻傻地沿用網上文章講的 60 度，則什麼訊號都收不到。因為一開始支架是確定垂直的，所以調整的仰角刻度也應該是可信的。

然後把纜線另一端接上接收機，接收機插入 B-CAS 卡、接上電視，再設定接收機要對天線（其實是 LNB）供電，進到接收機的天線設定畫面，觀察訊號強度。

此時以每隔 5~10 秒的步調，慢慢往右轉調整碟盤的方位角，直到找到衛星訊號、並定位到最大訊號強度為止。最後再鎖緊螺絲固定。

後續的拉線進房間，沒有什麼技術難度，就略去不多寫了。

BS 節目絕大部分都是高畫質的，除了一些電影頻道與 Animax 有時會播畫質較差的老片，高畫質節目看起來非常賞心悅目。不過試看期之後這些付費頻道也看不到了，變成黑畫面要你訂閱才能收看，除此之外幾個免費頻道，我下班、休假時偶爾看看也很滿足了。重點是我又能看到 NHK 了，雖然不是濃縮精華的 World Premium，但是很多節目 BS Premium 上也都有。

Cookbooks 的規劃

對應 OpsWorks 的任務分支，分為以下幾個 cookbooks：

• common
• setup
• configure
• deploy
• shutdown
• service-pack

不要有類似 OpsWorks 的 nginx 或 rails 這類獨樹一格的「專用」、「特用」cookbook，依以上基於動詞的 cookbook 來做事。

比如如果遇到要設定 nginx 某個獨特的項目，就是 setup::nginx_do_something 或 configure::nginx_do_something，而不要自己搞一個 nginx::do_something。

這樣做的好處就是管理起來簡單，一眼望過去知道這個 recipe「要做什麼事、對象是誰」，寫 recipe 時有明確分類可以遵循。

其中有幾點要注意：

• common cookbook 是用在「支援、配合任一其他類 cookbook」的地方，而不是「萬用類」。開發初期如果不曉得某任務應該歸在哪類，可「暫時」放在這裡，一旦確定放在某特定類比較適當後，則應立即 refactoring 改放到該特定類。
• service-pack cookbook 適合用在「單次任務」如元件安全更新、強制不使用 cache 重建 Docker images 的地方。
• 因為 Docker 的特性，基本上不需要 undeploy 類的任務，退版其實就是切回到某個舊版本的 Docker image 開 container 出來而已。所以不規劃 undeploy cookbook。

Docker 的部署設計

理想上，應該是把 docker image 從 registry pull 回來後立即 docker run 就能動起來。

實務上，我們有些地方還是需要仰賴 stack, layers, nodes 的設定資訊，所以還是免不了要使用 Chef 的 template 命令幫我們生成設定檔與 Dockerfile，最後再疊加上一層，生成新的 image 後予以部署。

部署時特別要注意，像是 Rails 應用會產生 logs、Unicorn 也會產生 logs，這些 logs 是營運績效、問題診斷的重要資訊 ，我會盡可能在 container 內把這些 logs 放在同一個目錄下，再用 volume 對應到 host 某一目錄底下保存。這樣可以直接從 host 取得 logs，不用進到 container 內，方便很多，也利於 logrotate, fluentd 之類的工具操作這些 logs。

目前想到的是這些，以後若有想到再寫…。

今天凌晨，位在 CH95 的 NHK World Premium 突然斷訊，有幾秒的時間被調到 CH94，旋又消失，接著 CH95 換載 MTV 綜合台。

求證有裝數位有線電視機上盒的岳家，NHK World Premium 還在數位頻道裡。

親眼見證這段歷程，很有感觸，我在當下還抱著希望，以為像之前一樣只是被賣藥台排擠而換了頻道。重新掃描頻道掃了兩、三次，再按著遙控器一台接一台尋找，覺得這很像是國中時新買的自行車失竊，我茫然地在附近兜圈那樣。

我知道類比頻道頻率範圍有限、數位頻道（理論上）無限的道理，但是今天台灣大寬頻可以這樣獨斷決定一個類比頻道的去留，我相信同樣的事情，很有可能也會在數位頻道裡發生。

於是我（終於）決定去裝衛星碟。

今天談到一個話題：「不熟 OP 的 developer 如果缺少 OP 相關知識，那怎麼做好 DevOps？」

我覺得這是個假議題。

今天就是因為 developer 都認為 OP 會負責 deploy 到好、負責出來坦，所以開發時毫不考慮 OP 負荷，logs 也不看不管，這才是真正導致 DevOps 做不起來的原因，也就是我一直批評的「假 DevOps 之名，行傳統 OP 之實」。

而 developer 真的需要很強的 OP/sysadmin 知識嗎？不用，真的不用，developer 缺的是很強的 DRY 意識。

如果能時時設想「我做的這個東西，能不能在 10 分鐘內整套自動 setup run 起來？」那 developer 自然會去想「程式能不能通過測試？」、「設定、部署能不能簡單輕鬆？」這才是以 developer 這一側要實行 DevOps 該有的思維。