與 Jenkins 整合
在 Jenkins 中使用 Ansible 進行自動佈署：
pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Test') {
steps {
sh 'ansible-playbook --syntax-check playbook.yml'
sh 'ansible-lint playbook.yml'
}
}
stage('Deploy to Staging') {
when {
branch 'develop'
}
steps {
withCredentials([string(credentialsId: 'ansible-vault-password', variable: 'VAULT_PASSWORD')]) {
sh 'echo $VAULT_PASSWORD > .vault_password'
sh 'ansible-playbook -i inventories/staging playbook.yml --vault-password-file .vault_password'
sh 'rm .vault_password'
}
}
}
stage('Deploy to Production') {
when {
branch 'master'
}
steps {
input message: 'Deploy to production?', ok: 'Deploy'
withCredentials([string(credentialsId: 'ansible-vault-password', variable: 'VAULT_PASSWORD')]) {
sh 'echo $VAULT_PASSWORD > .vault_password'
sh 'ansible-playbook -i inventories/production playbook.yml --vault-password-file .vault_password'
sh 'rm .vault_password'
}
}
}
}
post {
always {
cleanWs()
}
success {
slackSend channel: '#deployments', color: 'good', message: "Deployment successful: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
}
failure {
slackSend channel: '#deployments', color: 'danger', message: "Deployment failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
}
}
}
這個 Jenkins 管道實作了以下功能：
- 簽出程式碼
- 檢查 Playbook 語法和風格
- 根據分支自動佈署到不同環境
- 生產佈署前需要手動確認
- 佈署結果通知到 Slack
與 GitLab CI/CD 整合
在 GitLab CI/CD 中使用 Ansible：
# .gitlab-ci.yml
stages:
- test
- deploy_staging
- deploy_production
variables:
ANSIBLE_CONFIG: ./ansible.cfg
test:
stage: test
image: python:3.9
before_script:
- pip install ansible ansible-lint
script:
- ansible-playbook --syntax-check playbook.yml
- ansible-lint playbook.yml
only:
- merge_requests
deploy_staging:
stage: deploy_staging
image: python:3.9
before_script:
- pip install ansible
- 'which ssh-agent || apt-get update -y && apt-get install openssh-client -y'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$VAULT_PASSWORD" > .vault_password
script:
- ansible-playbook -i inventories/staging playbook.yml --vault-password-file .vault_password
after_script:
- rm .vault_password
only:
- develop
deploy_production:
stage: deploy_production
image: python:3.9
before_script:
- pip install ansible
- 'which ssh-agent || apt-get update -y && apt-get install openssh-client -y'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$VAULT_PASSWORD" > .vault_password
script:
- ansible-playbook -i inventories/production playbook.yml --vault-password-file .vault_password
after_script:
- rm .vault_password
only:
- master
when: manual
這個 GitLab CI/CD 設定實作了類別似的功能，但使用 GitLab 的特性來管理佈署流程。
Ansible 效能最佳化與故障排除
提高 Ansible 執行效率
- 增加平行度：調整
ansible.cfg中的forks引數可以增加平行執行的任務數：
[defaults]
forks = 50
- 使用 Pipelining：啟用 SSH 管道可以減少 SSH 連線數量：
[ssh_connection]
pipelining = True
- 使用 Fact 快取：對於不經常變化的系統資訊，可以啟用 Fact 快取：
[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_fact_cache
fact_caching_timeout = 86400
減少不必要的任務：使用條件陳述式和標籤來避免執行不必要的任務。
最佳化模組選擇：選擇效率更高的模組，例如使用
copy而不是template來複製不需要範本處理的檔案。
常見問題與解決方案
- SSH 連線問題：
# 檢查 SSH 連線
ansible -m ping all -vvv
# 使用不同的 SSH 選項
ansible -m ping all -e "ansible_ssh_common_args='-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'"
- 許可權問題：
# 使用 sudo
ansible -m ping all -b
# 指定 sudo 密碼
ansible -m ping all -b -K
- 模組錯誤：
# 檢查模組檔案
ansible-doc module_name
# 使用 -vvv 檢視詳細錯誤
ansible -m problematic_module host -vvv
- Playbook 語法錯誤：
# 檢查 Playbook 語法
ansible-playbook --syntax-check playbook.yml
# 使用 YAML 驗證工具
yamllint playbook.yml
- 變數問題：
# 檢查主機變數
ansible host -m debug -a "var=hostvars[inventory_hostname]"
# 檢查特定變數
ansible host -m debug -a "var=variable_name"
除錯技巧
- 使用
debug模組：
- name: 顯示變數值
debug:
var: my_variable
verbosity: 2 # 只在 -vv 或更高詳細度時顯示
- name: 顯示自定義訊息
debug:
msg: "當前處理的檔案是: {{ file_path }}"
- 使用
-vvv選項：
ansible-playbook playbook.yml -vvv
- 使用
--step選項：
ansible-playbook playbook.yml --step
這會在每個任務執行前詢問是否繼續。
- 使用
--start-at-task選項：
ansible-playbook playbook.yml --start-at-task="任務名稱"
這可以從特定任務開始執行 Playbook。
- 使用
register和debug組合：
- name: 執行指令
command: ls -la /var/log
register: command_result
- name: 顯示指令結果
debug:
var: command_result
在我的經驗中，良好的日誌記錄和監控對於排查 Ansible 問題至關重要。我通常會設定 Ansible 將日誌寫入檔案，並使用 ELK 堆積積疊或類別似工具來分析這些日誌。
Ansible 與容器技術的結合
使用 Ansible 管理 Docker 容器
Ansible 提供了多個模組來管理 Docker 容器和映像：
---
- name: 管理 Docker 容器
hosts: docker_hosts
become: true
tasks:
- name: 安裝 Docker 依賴
apt:
name:
- apt-transport-https
- ca-certificates
- curl
- gnupg-agent
- software-properties-common
state: present
when: ansible_distribution == 'Ubuntu' or ansible_distribution == 'Debian'
- name: 增加 Docker GPG 金鑰
apt_key:
url: https://download.docker.com/linux/ubuntu/gpg
state: present
when: ansible_distribution == 'Ubuntu'
- name: 增加 Docker 儲存函式庫
apt_repository:
repo: deb [arch=amd64] https://download.docker.com/linux/ubuntu {{ ansible_distribution_release }} stable
state: present
when: ansible_distribution == 'Ubuntu'
- name: 安裝 Docker
apt:
name:
- docker-ce
- docker-ce-cli
- containerd.io
- python3-docker
state: present
update_cache: yes
when: ansible_distribution == 'Ubuntu' or ansible_distribution == 'Debian'
- name: 啟動 Docker 服務
service:
name: docker
state: started
enabled: yes
- name: 建立 Docker 網路
docker_network:
name: app_network
driver: bridge
- name: 執行 Nginx 容器
docker_container:
name: nginx
image: nginx:latest
state: started
restart_policy: always
ports:
- "80:80"
networks:
- name: app_network
volumes:
- /data/nginx/html:/usr/share/nginx/html
- /data/nginx/conf:/etc/nginx/conf.d
- name: 執行 MySQL 容器
docker_container:
name: mysql
image: mysql:5.7
state: started
restart_policy: always
env:
MYSQL_ROOT_PASSWORD: "{{ mysql_root_password }}"
MYSQL_DATABASE: "{{ mysql_database }}"
MYSQL_USER: "{{ mysql_user }}"
MYSQL_PASSWORD: "{{ mysql_password }}"
networks:
- name: app_network
volumes:
- /data/mysql:/var/lib/mysql
這個 Playbook 完成了以下任務：
- 安裝 Docker 及其依賴
- 建立 Docker 網路
- 執行 Nginx 和 MySQL 容器
使用 Ansible 管理 Kubernetes 資源
Ansible 也可以用來管理 Kubernetes 資源：
---
- name: 管理 Kubernetes 資源
hosts: localhost
connection: local
tasks:
- name: 建立 Namespace
k8s:
state: present
definition:
apiVersion: v1
kind: Namespace
metadata:
name: myapp
- name: 佈署 ConfigMap
k8s:
state: present
definition:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: myapp
data:
app.properties: |
app.name=MyApp
app.environment=production
app.log.level=info
- name: 佈署 Secret
k8s:
state: present
definition:
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
namespace: myapp
type: Opaque
data:
db_password: "{{ db_password | b64encode }}"
api_key: "{{ api_key | b64encode }}"
- name: 佈署 Deployment
k8s:
state: present
definition:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:latest
ports:
- containerPort: 8080
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: app-secrets
key: db_password
volumeMounts:
- name: config-volume
mountPath: /app/config
volumes:
- name: config-volume
configMap:
name: app-config
- name: 佈署 Service
k8s:
state: present
definition:
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: myapp
spec:
selector:
app: myapp
ports:
- port: 80
targetPort: 8080
type: LoadBalancer
這個 Playbook 在 Kubernetes 中建立了一個完整的應用程式佈署，包括 Namespace、ConfigMap、Secret、Deployment 和 Service。
使用 Ansible 構建 CI/CD 管道
Ansible 可以與容器技術結合，構建完整的 CI/CD 管道：
---
- name: 構建和佈署應用程式
hosts: localhost
connection: local
vars:
app_name: myapp
app_version: "{{ lookup('env', 'CI_COMMIT_SHORT_SHA') | default('latest', true) }}"
docker_registry: registry.example.com
k8s_namespace: "{{ lookup('env', 'CI_ENVIRONMENT_NAME') | default('development', true) }}"
tasks:
- name: 簽出程式碼
git:
repo: https://github.com/example/myapp.git
dest: ./myapp
version: master
when: lookup('env', 'CI_SERVER') == ''
- name: 構建 Docker 映像
docker_image:
name: "{{ docker_registry }}/{{ app_name }}"
tag: "{{ app_version }}"
build:
path: ./myapp
pull: yes
source: build
push: yes
- name: 更新 Kubernetes Deployment
k8s:
state: present
namespace: "{{ k8s_namespace }}"
definition:
apiVersion: apps/v1
kind: Deployment
metadata:
name: "{{ app_name }}"
namespace: "{{ k8s_namespace }}"
spec:
replicas: 3
selector:
matchLabels:
app: "{{ app_name }}"
template:
metadata:
labels:
app: "{{ app_name }}"
spec:
containers:
- name: "{{ app_name }}"
image: "{{ docker_registry }}/{{ app_name }}:{{ app_version }}"
ports:
- containerPort: 8080
env:
- name: ENVIRONMENT
value: "{{ k8s_namespace }}"
- name: 等待佈署完成
k8s_info:
api_version: apps/v1
kind: Deployment
name: "{{ app_name }}"
namespace: "{{ k8s_namespace }}"
register: deployment
until: deployment.resources[0].status.availableReplicas | default(0) == deployment.resources[0].status.replicas
retries: 30
delay: 10
- name: 執行冒煙測試
uri:
url: "http://{{ app_name }}.{{ k8s_namespace }}.svc.cluster.local/health"
return_content: yes
register: health_check
failed_when: "'OK' not in health_check.content"
這個 Playbook 實作了一個完整的 CI/CD 管道：
- 簽出程式碼（如果不在 CI 環境中）
- 構建 Docker 映像並推播到登入檔
- 更新 Kubernetes Deployment
- 等待佈署完成
- 執行冒煙測試
在我的實際工作中，這種結合 Ansible 和容器技術的方法極大地提高了佈署的一致性和可靠性。
Ansible 的未來發展與趨勢
隨著技術的不斷發展，Ansible 也在不斷演進。以下是一些值得關注的趨勢和發展方向。
Ansible 與雲原生技術的融合
隨著雲原生技術的普及，Ansible 正在加強與 Kubernetes、Istio、Prometheus 等工具的整合。未來，我們可能會看到更多專門針對雲原生環境的 Ansible 模組和角色。
Ansible 與 AI/ML 的結合
人工智慧和機器學習技術可能會為 Ansible 帶來新的可能性，例如：
- 人工智慧故障診斷和修復
- 根據歷史資料的自動最佳化
- 預測性維護和擴充套件
事件驅動的自動化
Ansible 正在向事件驅動的自動化方向發展，例如 Ansible Event-Driven Automation (EDA)，它允許根據外部事件觸發自動化任務，實作更加靈活和回應式的自動化。
安全性和合規性增強
隨著安全威脅的增加，Ansible 在安全性和合規性方面的功能也在不斷增強，例如：
- 更強大的密碼管理
- 合規性檢查和報告
- 安全基線自動化
社群和生態系統的擴充套件
Ansible 擁有一個活躍的社群和豐富的生態系統，未來這一趨勢將繼續，我們可能會看到：
- 更多高品質的社群角色和集合
- 更好的檔案和學習資源
- 更多與其他工具的整合
Playbook：自動化工作流程的藝術
Playbook 基本結構與語法
Playbook 是 Ansible 自動化的核心元素，它使用 YAML 格式定義一系列任務，讓我們能夠以結構化的方式描述系統設定與佈署流程。
以下是一個基本的 Playbook 結構：
---
- name: 安裝並設定 Web 伺服器
hosts: webservers
become: true
vars:
http_port: 80
max_clients: 200
tasks:
- name: 安裝 Nginx
apt:
name: nginx
state: present
update_cache: yes
- name: 佈署 Nginx 設定
template:
src: templates/nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: 重啟 Nginx
- name: 確保 Nginx 服務啟動
service:
name: nginx
state: started
enabled: yes
handlers:
- name: 重啟 Nginx
service:
name: nginx
state: restarted
這個 Playbook 的結構包含：
name：描述 Playbook 的用途hosts：指定要執行的目標主機群組become：啟用許可權提升（相當於 sudo）vars：定義變數tasks：定義要執行的任務列表handlers：定義處理程式，僅在被通知時執行
每個任務都有自己的名稱和使用的模組（如 apt），以及該模組需要的引數。
變數與條件式執行
Playbook 支援變數，讓設定更加靈活。變數可以在 Playbook 中直接定義，也可以來自 Inventory 檔案或外部變數檔案。
---
- name: 設定 Web 伺服器
hosts: webservers
vars:
web_package: apache2
firewall_enabled: true
tasks:
- name: 安裝 Web 伺服器
apt:
name: "{{ web_package }}"
state: present
- name: 設定防火牆
ufw:
rule: allow
port: 80
proto: tcp
when: firewall_enabled
在這個例子中，我使用了 {{ web_package }} 語法參照變數，並使用 when 條件判斷是否執行防火牆設定任務。
在實際專案中，我經常將變數分離到獨立的檔案中，以提高 Playbook 的可維護性：
# vars/web_config.yml
---
web_package: apache2
web_service: apache2
web_config_path: /etc/apache2/apache2.conf
然後在 Playbook 中參照：
---
- name: 設定 Web 伺服器
hosts: webservers
vars_files:
- vars/web_config.yml
tasks:
- name: 安裝 Web 伺服器
apt:
name: "{{ web_package }}"
state: present
處理迴圈與迴圈
當需要重複執行類別似任務時，可以使用 loop 或 with_items 指令：
---
- name: 安裝多個套件
hosts: all
become: true
tasks:
- name: 安裝必要套件
apt:
name: "{{ item }}"
state: present
loop:
- git
- vim
- curl
- htop
這個 Playbook 會迴圈安裝四個套件，比分別寫四個任務更加簡潔。
在處理大型專案時，我發現使用迴圈搭配條件判斷特別有用：
---
- name: 設定服務
hosts: all
become: true
vars:
services:
- name: nginx
port: 80
enabled: true
- name: mysql
port: 3306
enabled: false
tasks:
- name: 設定服務埠
template:
src: "templates/{{ item.name }}.conf.j2"
dest: "/etc/{{ item.name }}/conf.d/ports.conf"
loop: "{{ services }}"
when: item.enabled
這種方式讓我們能夠以結構化的方式管理複雜的服務設定。
Handlers：優雅處理設定變更
Handlers 是一種特殊的任務，只有在被通知時才會執行。這對於處理設定變更特別有用，例如只在設定變更時重啟服務：
tasks:
- name: 佈署 Apache 設定
template:
src: templates/httpd.conf.j2
dest: /etc/httpd/conf/httpd.conf
notify: 重啟 Apache
- name: 佈署虛擬主機設定
template:
src: templates/vhost.conf.j2
dest: /etc/httpd/conf.d/vhost.conf
notify: 重啟 Apache
handlers:
- name: 重啟 Apache
service:
name: httpd
state: restarted
即使多個任務都通知同一個 handler，該 handler 也只會在 play 結束時執行一次。這避免了不必要的服務重啟，提高了效率和可靠性。
Ansible Vault：保護敏感資料的利器
Ansible Vault 概念與功能
Ansible Vault 是 Ansible 提供的資料保護機制，用於加密與解密敏感資料。它使用 AES-256 加密演算法，這是一種高度安全的對稱加密方式。
Ansible Vault 可加密各種檔案型別，包括變數檔案、設定檔案，甚至整個 Playbook。最常見的用法是加密包含敏感資料的變數檔案，然後在 Playbook 中參照。
Ansible Vault 基本操作
假設有一個包含資料函式庫帳號密碼的變數檔案 secrets.yml：
---
db_user: "admin"
db_password: "SuperSecretPassword"
使用 ansible-vault encrypt 加密檔案：
ansible-vault encrypt secrets.yml
系統會要求輸入密碼，加密後檔案內容變為：
$ANSIBLE_VAULT;1.1;AES256
663566636632333861396462663762316531353431316466373764393430643332616439336530
30
3466666135376235613035303764636631383235613365380a6532633738623136663132353236
32
...
使用 ansible-vault view 檢視加密檔案內容：
ansible-vault view secrets.yml
在我的工作流程中，我通常將所有敏感資訊集中在幾個加密檔案中，並在 Git 中追蹤這些加密檔案。這樣既保護了敏感資料，又能讓團隊成員分享設定。
在 Playbook 中使用加密檔案
在 Playbook 中參照加密檔案：
---
- name: 佈署應用程式
hosts: webservers
become: true
vars_files:
- secrets.yml
tasks:
- name: 設定應用程式
template:
src: ./app_config.j2
dest: /etc/myapp/config.yml
執行時需指定密碼：
ansible-playbook deploy_app.yml -i hosts --ask-vault-pass
或使用密碼檔案：
ansible-playbook deploy_app.yml -i hosts --vault-password-file ~/.vault_pass.txt
在團隊環境中，我建議使用密碼檔案並確保它不被納入版本控制：
# 在 .gitignore 中增加
.vault_pass.txt
這樣可以在自動化流程中使用 Vault，同時保持密碼的安全性。
管理密碼檔案與多金鑰加密
在複雜環境中，可能需要多個金鑰管理不同加密檔案。Ansible Vault 支援多金鑰功能：
ansible-vault encrypt secrets.yml --vault-id dev@~/.vault_pass_dev.txt --vault-id prod@~/.vault_pass_prod.txt
這將 secrets.yml 同時用兩組金鑰加密，分別對應 dev 和 prod 環境。
使用特定金鑰檢視檔案：
ansible-vault view secrets.yml --vault-id dev@~/.vault_pass_dev.txt
在管理多環境佈署時，我發現這個功能特別有用。例如，我可以為開發、測試和生產環境分別設定不同的金鑰，並根據需要選擇適當的金鑰：
# 開發環境佈署
ansible-playbook deploy.yml -i dev_hosts --vault-id dev@~/.vault_pass_dev.txt
# 生產環境佈署
ansible-playbook deploy.yml -i prod_hosts --vault-id prod@~/.vault_pass_prod.txt
這種設定適合開發環境與生產環境的分離管理。
Ansible Vault 加密與解密操作
Ansible Vault 提供多種指令處理加密檔案，包括加密、解密、編輯和重設密碼。
檔案加密：ansible-vault encrypt
ansible-vault encrypt secrets.yml
系統會要求設定密碼，加密後檔案內容變為加密字串。
檔案解密：ansible-vault decrypt
ansible-vault decrypt secrets.yml
或指定輸出檔案保留原始加密檔案：
ansible-vault decrypt secrets.yml --output=secrets_decrypted.yml
編輯加密檔案：ansible-vault edit
ansible-vault edit secrets.yml
這會使用系統預設編輯器（通常是 vi 或 nano）開啟解密後的檔案，編輯完成後自動重新加密。
變更密碼：ansible-vault rekey
ansible-vault rekey secrets.yml
系統會要求輸入舊密碼和新密碼，然後重新加密檔案。
進階技巧與最佳實踐
使用 Tags 標記任務
使用 tags 可以選擇性地執行特定任務：
---
- name: 設定 Web 應用程式
hosts: webservers
tasks:
- name: 安裝套件
apt:
name:
- nginx
- nodejs
state: present
tags: install
- name: 佈署應用程式碼
git:
repo: https://github.com/myorg/myapp.git
dest: /var/www/myapp
tags: deploy
執行特定標記的任務：
ansible-playbook site.yml --tags deploy
這在大型 Playbook 中特別有用，可以只執行需要的部分，節省時間。
使用 Roles 組織複雜的 Playbook
對於複雜的自動化任務，使用 Roles 可以提高可維護性和重用性：
roles/
nginx/
defaults/
main.yml
files/
handlers/
main.yml
meta/
main.yml
tasks/
main.yml
templates/
nginx.conf.j2
vars/
main.yml
在 Playbook 中使用角色：
---
- name: 設定 Web 伺服器
hosts: webservers
roles:
- nginx
- { role: nodejs, nodejs_version: "14.x" }
這種結構讓複雜的自動化任務變得更加模組化和可維護。
使用 Ansible Galaxy 分享和重用角色
Ansible Galaxy 是一個分享和下載角色的平台：
# 安裝角色
ansible-galaxy install geerlingguy.nginx
# 在 Playbook 中使用
---
- name: 設定 Web 伺服器
hosts: webservers
roles:
- geerlingguy.nginx
這讓我們能夠利用社群中的優質角色，避免重複造輪子。
Ansible 是一個強大而靈活的自動化工具，能夠顯著提升 IT 維運效率。從基本的 Playbook 到進階的 Vault 加密，Ansible 提供了全面的解決方案來應對現代 IT 環境的挑戰。
在我的職業生涯中，Ansible 幫助我將繁瑣的手動操作轉變為可靠的自動化流程，不僅提高了效率，還減少了人為錯誤。無論是管理幾台伺服器還是上百台機器的大型基礎設施，Ansible 都能夠勝任。
自動化不僅是一種技術，更是一種思維方式。當你開始用 Ansible 思考問題時，你會發現許多重複性工作都可以被自動化，從而釋放更多時間專注於創新和解決真正的挑戰。隨著雲端運算、容器化和微服務架構的普及，掌握 Ansible 這樣的自動化工具將成為適應技術變革的必要技能。
使用 Ansible 自動化管理 Cron 排程任務
Cron 與 Ansible 的強大組合
在 Linux 系統管理的世界中，排程任務是維持系統健康與自動化的關鍵元素。當玄貓處理多台伺服器時，手動設定 Cron 任務不僅耗時，還容易出錯。Ansible 的 ansible.builtin.cron 模組提供了一種優雅的解決方案，讓我們能夠以程式碼方式管理所有伺服器的排程任務。
基本 Cron 任務設定
Ansible 讓 Cron 任務管理變得簡單直觀。以下是設定基本排程任務的方式：
- name: 設定每日備份任務
ansible.builtin.cron:
name: "每日資料函式庫備份"
user: "backup_user"
hour: "2"
minute: "0"
job: "/usr/local/bin/backup_database.sh"
這個 Ansible 任務會在目標系統上建立一個 Cron 排程，為使用者 backup_user 設定每天凌晨 2:00 執行 /usr/local/bin/backup_database.sh 指令碼。name 引數為此 Cron 任務提供一個識別標籤，這在後續管理或修改時非常有用。Ansible 會自動處理 crontab 檔案的編輯，確保任務正確設定而不會產生重複專案。
使用預定義的時間表示式
Ansible 支援多種便捷的時間表示式，讓 Cron 排程更加靈活：
- name: 設定每週日系統更新
ansible.builtin.cron:
name: "週末系統更新"
user: "root"
special_time: weekly
job: "apt update && apt upgrade -y"
這個任務使用 special_time 引數設定一個每週執行一次的 Cron 任務。Ansible 支援多種特殊時間表示式，包括 yearly、monthly、weekly、daily、hourly 和 reboot（系統重啟時執行）。這比手動設定完整的 Cron 表示式更加簡潔易讀。在這個例子中，系統會在每週日的凌晨執行更新命令。
管理複雜的 Cron 表示式
對於需要更精確控制的情境，可以使用完整的 Cron 表示式：
- name: 設定複雜排程任務
ansible.builtin.cron:
name: "工作日每小時日誌清理"
user: "sysadmin"
minute: "15"
hour: "9-17"
weekday: "1-5"
job: "/usr/local/bin/clean_logs.sh"
這個任務設定了一個在工作日（週一至週五）上班時間（早上9點到下午5點）每小時執行一次的任務。具體來說，它會在每小時的第15分鐘執行日誌清理指令碼。Ansible 允許我們使用標準的 Cron 表示式格式，包括範圍（如 9-17）和列表（如 1,3,5）。
移除 Cron 任務
系統維護中，移除不再需要的排程任務同樣重要：
- name: 移除舊的備份任務
ansible.builtin.cron:
name: "舊的每日備份"
user: "backup_user"
state: absent
這個任務會尋找並移除名為「舊的每日備份」的 Cron 任務。state: absent 引數告訴 Ansible 刪除比對的任務，而不是建立或修改它。Ansible 會根據 name 引數識別要移除的特定任務，這就是為什麼在建立任務時提供有意義的名稱很重要。
使用環境變數
有時 Cron 任務需要特定的環境設定才能正常運作：
- name: 設定帶環境變數的備份任務
ansible.builtin.cron:
name: "資料函式庫備份與通知"
user: "dbadmin"
hour: "1"
minute: "30"
job: "/usr/local/bin/backup_with_notification.sh"
env:
PATH: "/usr/local/bin:/usr/bin:/bin"
MAILTO: "admin@example.com"
BACKUP_TYPE: "full"
這個任務不僅設定了 Cron 排程，還設定了任務執行時的環境變數。PATH 變數確保指令碼能找到所需的執行檔，MAILTO 設定任務執行結果的郵件通知接收者，而自定義的 BACKUP_TYPE 變數則傳遞給備份指令碼使用。這種方式讓 Cron 任務更加靈活，無需修改指令碼即可調整行為。
使用 Cron 檔案
除了直接修改使用者的 crontab，Ansible 還可以管理 /etc/cron.d/ 目錄中的檔案：
- name: 建立系統維護 Cron 檔案
ansible.builtin.cron:
name: "系統維護任務"
user: "root"
cron_file: "system_maintenance"
hour: "3"
minute: "0"
job: "/usr/local/bin/system_maintenance.sh"
這個任務會在 /etc/cron.d/ 目錄中建立或修改名為 system_maintenance 的檔案，設定一個每天凌晨 3:00 執行的系統維護任務。使用 cron_file 引數的好處是可以將相關的排程任務組織在同一個檔案中，便於管理和追蹤。這種方法特別適合需要在系統層級管理的任務。
批次管理多台伺服器的 Cron 任務
Ansible 的真正威力在於能夠同時管理多台伺服器的排程任務：
- name: 根據伺服器角色設定備份排程
hosts: all_servers
become: true
vars:
backup_schedules:
database:
hour: "1"
minute: "30"
script: "/usr/local/bin/backup_database.sh"
web:
hour: "2"
minute: "15"
script: "/usr/local/bin/backup_web_content.sh"
mail:
hour: "3"
minute: "0"
script: "/usr/local/bin/backup_mail.sh"
tasks:
- name: 設定伺服器備份任務
ansible.builtin.cron:
name: "{{ server_role }} 備份任務"
user: "backup"
hour: "{{ backup_schedules[server_role].hour }}"
minute: "{{ backup_schedules[server_role].minute }}"
job: "{{ backup_schedules[server_role].script }}"
when: server_role in backup_schedules
vars:
server_role: "{{ server_primary_role | default('general') }}"
這個進階範例展示瞭如何使用 Ansible 變數系統動態設定 Cron 任務。我們首先定義了一個 backup_schedules 字典，包含不同伺服器角色的備份時間和指令碼。然後在任務中，根據每台伺服器的 server_primary_role 變數選擇適當的排程設定。這種方法的優點是集中管理所有排程設定，當需要調整時只需修改變數定義，而不是任務本身。同時，使用 when 條件確保只為已定義排程的角色設定任務。
監控與驗證 Cron 任務
設定完 Cron 任務後，確認它們正確運作也很重要：
- name: 檢查 Cron 任務是否存在
ansible.builtin.command: crontab -l -u {{ item }}
register: crontab_content
changed_when: false
failed_when: false
loop:
- backup_user
- www-data
- root
- name: 顯示各使用者的 Cron 任務
ansible.builtin.debug:
msg: "{{ item.item }} 的 Cron 任務:\n{{ item.stdout }}"
loop: "{{ crontab_content.results }}"
when: item.rc == 0 and item.stdout != ""
這組任務用於檢查和顯示指定使用者的 Cron 任務。第一個任務使用 command 模組執行 crontab -l 命令，並將結果儲存在 crontab_content 變數中。changed_when: false 確保這個檢查任務不會被報告為「已變更」，而 failed_when: false 則防止在使用者沒有 Cron 任務時報錯。
第二個任務使用 debug 模組顯示每個使用者的 Cron 任務內容。它使用 when 條件只顯示成功執行與有輸出的結果。這種檢查方法可以幫助我們驗證 Cron 任務是否正確設定，特別是在大規模佈署後。
實用的 Cron 任務範例
以下是一些常見系統管理任務的 Cron 設定：
- name: 設定常見系統維護任務
hosts: all_servers
become: true
tasks:
- name: 設定日誌輪轉
ansible.builtin.cron:
name: "日誌輪轉"
user: "root"
hour: "0"
minute: "0"
job: "logrotate -f /etc/logrotate.conf"
- name: 設定磁碟空間檢查
ansible.builtin.cron:
name: "磁碟空間檢查"
user: "root"
hour: "*/4"
minute: "0"
job: "/usr/local/bin/check_disk_space.sh | mail -s '磁碟空間警告' admin@example.com"
- name: 設定系統更新檢查
ansible.builtin.cron:
name: "檢查系統更新"
user: "root"
special_time: daily
job: "apt update > /dev/null && apt list --upgradable | mail -s '可用系統更新' admin@example.com"
這個 Playbook 設定了三個常見的系統維護任務：
- 日誌輪轉：每天午夜執行
logrotate命令，確保日誌檔案不會無限增長。 - 磁碟空間檢查：每4小時執行一次磁碟空間檢查指令碼，並將結果透過郵件傳送給管理員。
*/4表示「每4小時」。 - 系統更新檢查：每天檢查可用的系統更新，並將結果透過郵件傳送。使用
special_time: daily簡化了時間設定。
這些任務展示瞭如何使用 Cron 和 Ansible 自動化常見的系統維護工作，提高系統可靠性並減輕管理負擔。
使用 Ansible 處理複雜的 Cron 需求
有時我們需要處理更複雜的 Cron 需求，例如根據伺服器負載動態調整排程：
- name: 根據伺服器型別設定不同的備份時間
hosts: all_servers
become: true
tasks:
- name: 取得伺服器型別
ansible.builtin.setup:
filter: ansible_memtotal_mb
register: server_info
- name: 設定高記憶體伺服器的備份時間
ansible.builtin.cron:
name: "資料函式庫完整備份"
user: "backup"
hour: "1"
minute: "0"
job: "/usr/local/bin/full_backup.sh"
when: server_info.ansible_facts.ansible_memtotal_mb|int > 8192
- name: 設定低記憶體伺服器的備份時間
ansible.builtin.cron:
name: "資料函式庫分段備份"
user: "backup"
hour: "1,13"
minute: "30"
job: "/usr/local/bin/incremental_backup.sh"
when: server_info.ansible_facts.ansible_memtotal_mb|int <= 8192
這個範例展示瞭如何根據伺服器的硬體規格動態設定不同的備份策略。首先使用 setup 模組收集伺服器的記憶體資訊，然後根據記憶體大小決定備份策略：
- 對於記憶體超過 8GB 的高效能伺服器，設定在凌晨 1:00 執行完整備份
- 對於記憶體小於等於 8GB 的伺服器，設定在凌晨 1:30 和下午 1:30 執行分段備份
這種方法考慮了伺服器資源限制，避免在低規格伺服器上執行資源密集型的完整備份，同時確保所有系統都得到適當的備份保護。
Ansible 與 Cron 的最佳實踐
在大規模環境中使用 Ansible 管理 Cron 任務時，以下是一些最佳實踐：
使用有意義的名稱：為每個 Cron 任務提供清晰的名稱，便於後續管理和識別。
集中管理變數：將排程時間、使用者和指令碼路徑等設定集中在變數檔案中，便於維護和調整。
使用版本控制：將 Ansible Playbook 和相關指令碼納入版本控制系統，追蹤變更並支援回復。
測試排程任務：在佈署前，先在測試環境中驗證 Cron 任務的行為和效果。
監控任務執行：設定適當的日誌記錄和監控，確保 Cron 任務正常執行並及時發現問題。
考慮時區因素：在跨時區的環境中，注意 Cron 任務的執行時間會受到伺服器時區設定的影響。
避免重複任務：使用 Ansible 的
state引數確保不會建立重複的 Cron 任務。定期審查：定期審查和清理不再需要的 Cron 任務，避免系統負擔和潛在衝突。
透過 Ansible 管理 Cron 任務不僅提高了效率，還確保了一致性和可靠性。從簡單的備份排程到複雜的系統維護任務，Ansible 的 cron 模組都能優雅地處理，讓系統管理員能夠專注於更重要的工作。
在現代 IT 環境中，自動化不再是選項，而是必需。結合 Ansible 和 Cron 的強大功能，我們可以建立一個高效、可靠與易於維護的自動化基礎設施，為組織提供持續的價值。
