上一篇我們有提到要用 Ansible 的腳本來做 container orchestration,python 本身已經被視為 glue language,而 python-based 的 ansible,更是 glue 中的 glue,可以協助運維人員管理大批管理用的 script,無論是用什麼語言寫的。
之前我們說過,要寫一個 3-tier 的 web app,寫我們耳熟能詳的 TODO。整個微服務的專案架構骨架長得像是這樣,未來我們會逐漸添枝加葉:
├── ansible
├── flask.mytodos
│ ├── src
│ ├── conf
│ └── Dockerfile
├── react.mytodos
│ ├── src
│ ├── conf
│ └── Dockerfile
└── README.md
基本上在團隊的主要 repo 上,每個微服務都有自己的目錄(directory),RD 必須 commit 至少這三件事件
在 code push 到版控(例如 Git)之後, CI(Continous Integration)系統抓取(git pull)相關的開發分支後,就會 cd(change directory)到各微服務底下的 dir,以 docker build
的指令,依照 Dockerfile 的描述,把相關的 code 「包」起來,不含配置。
而 ansible 這個目錄,底下就是 operation 相關的配置與 Yaml 檔,有的團隊習慣 operation 相關的 code (如果 Yaml 也可以稱作 code 的話),會用另一個 repo,但既然都說開發維運一條龍了,我還不合併起來這麼做其中一種思路是這樣的:當配置有所更改時,難道不希望相對應的環境重新部署嗎?我認為這是Configuration as Code的一種實踐。
我們將參考Ansible Best Practice來形塑 ansible 目錄的骨幹。
ansible
├── ansible.cfg
├── files
│ ├── cert.d
│ ├── conf.d
│ ├── html.d
│ ├── script.d
│ ├── setting.d
│ └── sql.d
└── inventory
└── roles
└── tasks
以下,我們示範一個簡單的 ansible 腳本來部署我們的 docker host VM
$ cat roles/tasks/setup_vm.yaml
- hosts: "{{ variable_host | default('beta') }}"
gather_facts: true
remote_user: centos
become: true
become_method: sudo
tasks:
- name: Yum | Install Useful Utilities
yum:
name: "{{ useful_packages }}"
vars:
useful_packages:
- epel-release
- git
- vim
- wget
- tree
- bind-utils
- net-tools
- telnet
- chrony
- name: Shell | Adjust Timezone
shell: "timedatectl set-timezone UTC"
- name: Shell | Chrony
shell: "systemctl start chronyd && systemctl enable chronyd"
- name: Script | Install Docker 18.06
script: "{{ dev_dir }}/ansible/files/script.d/install_docker1806.sh"
- name: Script | Install PostgreSQL 10 Client
script: "{{ dev_dir }}/ansible/files/script.d/install_pg10_client.sh"
- name: Yum | Install Python-Pip
yum:
name: python-pip