It is usually necessary to watch for any changes in file systems, both in development and in production modes. For example, in the development mode Webpack can watch files and recompile whenever they change; in the production mode Consul Template can watch runtime configs and invoke specific applications whenever they change.

These are well-known scenarios in traditional pre-container world. How about the container world? Do they behave the same in the new container world?

前天我在 2019 台灣雲端大會帶了兩個場次，一個是現場實作場次，一個是經驗分享演講：

• Lab / 給 RD 的 Kubernetes 初體驗 (90 minutes)

• Speech / 當 .NET 遇到 Kubernetes (30 minutes)

兩個場次，一言以蔽之，都圍繞在 Kubernetes 的入門認知與導入策略上。

四月 9–11 日去舊金山參加 Google Cloud 的 Next ’19 大會，收穫頗大。

這場大會，同一時段就有近 30 場專題演講同時進行，議程滿滿，勢必得做取捨。基於工作需要及個人興趣，我主要選擇與容器相關的場次：service mesh、Windows containers、混合雲、資安實務。

我發現，光是這些場次，就得花很大力氣去消化、實驗與應用。

我們這些所謂的「台港團」會在 GCPUG Taipei 舉辦一場分享會。因為自己不克參加，便以這篇文章，針對我鎖定的核心議題：Istio，做一番重點摘要，以饗讀者。

既然要開始在 Windows 上沿用 Mac 及 Unix 的命令列工具習慣¹，免不了要處理 Ansible 及 Vagrant。

雖然這兩個軟體都有對應的 Windows 版本，但據我以前的經驗，卡卡的，有許多小地雷；畢竟這些發跡自泛 Unix 家族的軟體，不是那麼容易無縫移植到對命令列不友善的 Windows 家族。

如今 Windows 已經有 WSL (Windows Subsystem for Linux) 機制，是否可以更無痛享用 Ansible 及 Vagrant 呢？

可以的。

在 Windows 10 上面使用 WSL 已經一個月了¹。小狀況也就罷了，但 Cmder 不夠穩定的顯示邏輯卻最讓我頭痛，在視窗尺寸變化時，無法正確處理字元位置。更令人費解的是，即使是其他狀似更華麗（也更耗資源）的替代方案，也仍然有這些問題²。

既然酷炫的終端機競品問題多多，乾脆回歸極簡的 WSLtty³，並混搭 tmux⁴ 來彌補。可惜，畢竟是組合技，無法完全複製 Mac 的 iTerm2 使用經驗。

此事古難全。