Vagrant 到 Ansible 的替代理由
Vagrant存在的問題
- 構築手順不明確
構築手順是通過VagrantFile來寫的，最終是通過shell的腳本實現。
導致出現 ①不同的人寫不同的腳本邏輯，可理解性減弱 ② 稍微的構成變更時，需要交由實裝者解決。
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "centos/7"
config.vm.hostname = "demo"
config.vm.network :private_network, ip: "192.168.33.10"
config.vm.synced_folder ".", "/home/vagrant/sync", disabled: true
config.vm.provision "shell", inline: $script
end
$script = <<SCRIPT
yum -y install epel-release
yum -y install nginx
echo "hello, vagrant" > /usr/share/nginx/html/index.html
systemctl start nginx
SCRIPT
- 設定項目不能追加
用VagrantFile寫的構築手順，實現的是從一開始的構築過程，如果只想在已構築完成的環境中實現設定項目的追加時，當然可以使用- vagrant provision - 的命令實現，但是基本是依靠腳本的分支處理來實裝，最終沒有形成統一的規範。 - 構築手順的環境流用性差
用VagrantFile寫的構築手順，基本實現的是本地環境的構築，不同的環境的依存設定值不同，需要根據環境配置不同的VagrantFile。
Ansible解決的問題
宣言性
本身是一種宣言性的記述語言，只需要在playbook中宣言自己想要的設定對象的狀態即可。不需要記載怎麼實現。
例如
service：
name：nginx
state：started
不依存於腳本，容易理解。
抽象性
構成對象的各種不同環境的差異沒必要自己實現，ansible自動對應。
例如
不管配置在RedHat上還是Ubuntu上，不需要記載是用yum還是apt-get，只要記載結果即可，內部實現由ansbie封裝實現。
實現最大化的共通化，提高可移植性。
收束性
不管對象目前是什麼狀態，保證變更爲期待的狀態。
例如
腳本實現的場合，開發者需要考慮命令背後的前提條件，例如文件是否存在等，ansible中，不需要考慮這些。
只通過記述，開發者就可以很容易把握對象狀態。
冪等性
不管playbook執行幾遍，都是同樣的結果。
例如
大大降低了實裝，測試的難度， 腳本的話，需要考慮每次執行後的變更條件。
省力化
- 便攜性
不像攜帶光盤鏡像文件等方式，只需要文本文件就可以實現各環境的共享。 - review
通過check文本文件的查分，容易review。 - 版本管理
通過版本管理的軟件來管理文本文件。 - 源碼公開
各種公開的源碼。