EinfĂĽhrung
Ansible ist ein leistungsstarkes Konfigurationsmanagementsystem zum Konfigurieren und Verwalten von Infrastruktur und Anwendungen in einer Vielzahl von Umgebungen. Während Ansible eine einfach zu lesende Syntax, flexible Workflows und leistungsstarke Tools bietet, kann die Verwaltung einer großen Anzahl von Hosts eine Herausforderung sein, wenn sie sich je nach Bereitstellungsumgebung und Funktionalität unterscheiden.
In diesem Lernprogramm werden einige Strategien für die Verwendung von Ansible für die Arbeit mit mehrstufigen Bereitstellungsumgebungen erläutert. Typischerweise führen die Anforderungen für verschiedene Stufen zu unterschiedlichen Mengen und unterschiedlichen Konfigurationen von Komponenten. Beispielsweise können sich die Speicheranforderungen für einen Entwicklungsserver von denen für Staging- und Produktionsumgebungen unterscheiden, und es ist wichtig, explizit zu steuern, wie die Variablen, die diese Anforderungen darstellen, Vorrang haben. In diesem Artikel werden einige Möglichkeiten zur Abstraktion dieser Unterschiede sowie einige der von Ansible bereitgestellten Konstrukte zur Förderung der Wiederverwendung von Konfigurationen erläutert.
Unvollständige Strategien zur Verwaltung mehrstufiger Umgebungen mit Ansible
Während es in Ansible verschiedene Möglichkeiten gibt, Umgebungen zu verwalten, bietet Ansible selbst keine bessere Lösung. Vielmehr bietet es viele Konstrukte, die zum Bearbeiten von Umgebungen verwendet werden können, und ermöglicht dem Benutzer die Auswahl.
Der Ansatz, den wir in diesem Handbuch demonstrieren, basiert auf einer Gruppe von Variablen Ansible und mehreren Registern ( Inventories ). Es gibt jedoch mehrere andere Strategien, die in Betracht gezogen werden sollten. Wir werden uns im Folgenden einige dieser Ideen ansehen und herausfinden, warum sie bei der Implementierung in komplexen Umgebungen problematisch sein können.
Wenn Sie mit der empfohlenen Ansible-Strategie beginnen möchten, fahren Sie mit dem Abschnitt über die Verwendung von Ansible-Gruppen und mehreren Registrierungen fort.
Verlassen Sie sich ausschlieĂźlich auf Gruppenvariablen
, Ansible . , . Ansible . . . :
- (, dev, stage, prod . .)
- (-, . .)
- (NYC, SFO . .)
. , - () ( ) - ( ).
, Ansible . , , , , Ansible .
Ansible . Ansible , , , . , .
Ansible , [groupname: children]
. . , .
. , environment
, dev
, stage
, prod
. , environment
dev
. , functions
, web
, database
loadbalancer
.
, . , , environments
functions
. .
, . , , :
, :
. . . [function:children] web database loadbalancer region [region:children] nyc sfo environments [environments:children] dev stage prod
, , region
function
. , environments
, . , dev
, nyc
web
, , , dev
.
. , . Ansible , . .
Ansible-,
Ansible , , vars_files
include_vars
. Ansible plays , . vars_files
, include_vars
.
, group_vars
, .
, group_vars
:
group_vars/dev
--- env: dev
group_vars/stage
--- env: stage
group_vars/web
---
function: web
group_vars/database
---
function: database
vars
, . vars. group_vars
, include_vars
.yml.
, server_memory_size
vars
. , , , . , - :
vars/dev.yml
--- server_memory_size: 512mb
vars/prod.yml
--- server_memory_size: 4gb
vars/web.yml
--- server_memory_size: 1gb
vars/database.yml
--- server_memory_size: 2gb
playbook, vars
, group_vars
. , .
vars_files
:
example_play.yml
---
- name: variable precedence test
hosts: all
vars_files:
- "vars/{{ env }}.yml"
- "vars/{{ function }}.yml"
tasks:
- debug: var=server_memory_size
, server_memory_size
var/web.yml
var/database.yml
:
ansible-playbook -i inventory example_play.yml
Output. . . TASK [debug] ******************************************************************* ok: [host1] => { "server_memory_size": "1gb" # value from vars/web.yml } ok: [host2] => { "server_memory_size": "1gb" # value from vars/web.yml } ok: [host3] => { "server_memory_size": "2gb" # value from vars/database.yml } ok: [host4] => { "server_memory_size": "2gb" # value from vars/database.yml } . . .
, :
example_play.yml
---
- name: variable precedence test
hosts: all
vars_files:
- "vars/{{ function }}.yml"
- "vars/{{ env }}.yml"
tasks:
- debug: var=server_memory_size
playbook , :
ansible-playbook -i inventory example_play.yml
Copy
Output. . . TASK [debug] ******************************************************************* ok: [host1] => { "server_memory_size": "512mb" # value from vars/dev.yml } ok: [host2] => { "server_memory_size": "4gb" # value from vars/prod.yml } ok: [host3] => { "server_memory_size": "512mb" # value from vars/dev.yml } ok: [host4] => { "server_memory_size": "4gb" # value from vars/prod.yml } . . .
include_vars
, , :
--- - name: variable precedence test hosts: localhost tasks: - include_vars: file: "{{ item }}" with_items: - "vars/{{ function }}.yml" - "vars/{{ env }}.yml" - debug: var=server_memory_size
, Ansible , . , , .
, vars_files
include_vars
, , , . group_vars
, vars
. . , Ansible group_vars
.
, . playbook , . Playbook . , ansible
-, .
Ansible:
, . Ansible , .
— , . , , . group_vars
.
:
. ├── ansible.cfg ├── environments/ # Parent directory for our environment-specific directories │ │ │ ├── dev/ # Contains all files specific to the dev environment │ │ ├── group_vars/ # dev specific group_vars files │ │ │ ├── all │ │ │ ├── db │ │ │ └── web │ │ └── hosts # Contains only the hosts in the dev environment │ │ │ ├── prod/ # Contains all files specific to the prod environment │ │ ├── group_vars/ # prod specific group_vars files │ │ │ ├── all │ │ │ ├── db │ │ │ └── web │ │ └── hosts # Contains only the hosts in the prod environment │ │ │ └── stage/ # Contains all files specific to the stage environment │ ├── group_vars/ # stage specific group_vars files │ │ ├── all │ │ ├── db │ │ └── web │ └── hosts # Contains only the hosts in the stage environment │ ├── playbook.yml │ └── . . .
, . (hosts
) group_vars
.
. web
db
. . , , , . group_vars
.
. , , . -, . .
, , — . . — Ansible . all
group_vars
all
.
, , . , . .
- . (environments
). :
cd environments
touch 000_cross_env_vars
group_vars
, all
all
. :
cd dev/group_vars mv all env_specific mkdir all mv env_specific all/
, :
cd all/ ln -s ../../../000_cross_env_vars .
, :
. ├── ansible.cfg ├── environments/ │ │ │ ├── 000_cross_env_vars │ │ │ ├── dev/ │ │ ├── group_vars/ │ │ │ ├── all/ │ │ │ ├── 000_cross_env_vars -> ../../../000_cross_env_vars │ │ │ │ └── env_specific │ │ │ ├── db │ │ │ └── web │ │ └── hosts │ │ │ ├── prod/ │ │ ├── group_vars/ │ │ │ ├── all/ │ │ │ │ ├── 000_cross_env_vars -> ../../../000_cross_env_vars │ │ │ │ └── env_specific │ │ │ ├── db │ │ │ └── web │ │ └── hosts │ │ │ └── stage/ │ ├── group_vars/ │ │ ├── all/ │ │ │ ├── 000_cross_env_vars -> ../../../000_cross_env_vars │ │ │ └── env_specific │ │ ├── db │ │ └── web │ └── hosts │ ├── playbook.yml │ └── . . .
, 000_cross_env_vars
, .
ansible.cfg
. .
-, ansible
ansible-playbook
. :
ansible -i environments/dev -m ping
, :
ansible -m ping
-, . . , , -i
.
, ansible.cfg
. /etc/ansible/ansible.cfg
.
. ansible.cfg
. /etc/ansibile/ansible.cfg
, . /etc/ansible/ansible.cfg
/etc/ansible
, .
nano ansible.cfg
, . , hosts:
[defaults] inventory = ./environments/dev
-i
. - -i
, .
In diesem Artikel haben wir die Flexibilität untersucht, die Ansible für die Verwaltung Ihrer Hosts in mehreren Umgebungen bietet. Auf diese Weise können Benutzer viele verschiedene Strategien anwenden, um mit variabler Priorität umzugehen, wenn der Host Mitglied mehrerer Gruppen ist. Die Mehrdeutigkeit und das Fehlen offizieller Anleitungen können jedoch ein Problem für Sie sein. Wie bei jeder Technologie hängt die beste Anpassung an Ihr Unternehmen von Ihren Anwendungsfällen und der Komplexität Ihrer Anforderungen ab. Der beste Weg, um eine Strategie zu finden, die zu Ihnen passt, ist zu experimentieren. Teilen Sie Ihren Anwendungsfall und Ansatz in den Kommentaren unten.