第二式：用 Ansible 設定雲端主機組態 (14:33)

上一課，我們先以本機端的虛擬機為例，示範如何用 Ansible 來設定它的組態。了解 Ansible 的 control machine 及 managed node 的運作邏輯之後，這一課，我們會將經驗套用到雲端主機身上。

我們會探討兩種雲端主機的情境：

「Ansible → 雲端主機」操作動線

如果 Ansible control machine 可以直接觸碰到 managed node，那麼，整個操作動線就很單純：

首先，直接將這台 managed node 機器的登入資訊（位址、ssh port、登入帳號等）寫進一個 inventory 檔案。

有了 inventory 檔案，就可以叫 Ansible 將劇本套用在雲端主機身上：

ansible-playbook    \
    --inventory-file=inventory    \
    --private-key=$HOME/.ssh/private_key_file  \
    playbook.yml

影片中我是以 Google Compute Platform 及 Amazon EC2 為例，但同樣的邏輯，可以套用在各種雲端主機身上：Azure、DigitalOcean⋯⋯。

雲端主機，尤其是 production 環境的雲端主機，為了資安考量，常常會擺在 private subnet 中，只有 internal IP 位址；還套上存取控制機制，無法直接被外界觸碰。譬如說，典型的 AWS 用戶，會透過 VPC、security group 等機制，層層保護住雲端主機。

在這種保護措施之下，你可能會想讓事情簡單一點，將 Ansible control machine 擺在同一個 private subnet 中，讓它可以直接觸碰那些 managed node。

不過，你也可能希望更嚴謹一點，不要給 Ansible control machine 特殊待遇，不要直接擺在同一個 private subnet 裡，不要讓它直接觸碰那些 managed node。

如果 Ansible control machine 無法直接觸碰到 managed node，那麼，整個操作動線就要略作修改：透過既有的 bastion host（跳板機），間接觸碰 managed node：

在 Ansible 中，有很多種手法可以實現這種跳板機的動線。影片中我示範其中一種手法：在 inventory 檔案中，透過 ansible_ssh_common_args 變數指定 bastion host：

ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q bastion_hostname"'

如果還想知道其他類似的 bastion 手法，請參考以下文章：

Discussion