1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00

Nit fix spelling of separate

This commit is contained in:
Jim Kleckner 2013-04-21 12:33:51 -07:00
parent 97f9b6df1c
commit 5e5235a433
3 changed files with 6 additions and 6 deletions

View file

@ -16,7 +16,7 @@ Core Features:
* --limit can now be given a filename (--limit @filename) to constrain a run to a host list on disk
* failed playbook runs will create a retry file in /var/tmp/ansible usable with --limit
* roles allow easy arrangement of reusable tasks/handlers/files/templates
* pre_tasks and post_tasks allow for seperating tasks into blocks where handlers will fire around them automatically
* pre_tasks and post_tasks allow for separating tasks into blocks where handlers will fire around them automatically
* "meta: flush_handler" task capability added for when you really need to force handlers to run
* new --start-at-task option to ansible playbook allows starting at a specific task name in a long playbook
@ -172,7 +172,7 @@ Module Changes/Fixes:
* more OS X facts
* added a 'fail_on_missing' (default no) option to fetch
* added timeout to the uri module (default 30 seconds, adjustable)
* ec2 now has a 'wait' parameter to wait for the instance to be active, eliminates need for seperate wait_for call.
* ec2 now has a 'wait' parameter to wait for the instance to be active, eliminates need for separate wait_for call.
* allow regex backreferences in lineinfile
* id attribute on ec2 module can be used to set idempotent-do-not-recreate launches
* icinga support for nagios module

View file

@ -133,7 +133,7 @@ We can define specific hardware variance in systems in a host_vars file, but avo
foo_agent_port: 86
bar_agent_port: 99
Top Level Playbooks Are Seperated By Role
Top Level Playbooks Are Separated By Role
`````````````````````````````````````````
In site.yml, we include a playbook that defines our entire infrastructure. Note this is SUPER short, because it's just including
@ -230,12 +230,12 @@ to be some additional playbooks that hop between tiers to roll out an applicatio
may be augmented by playbooks like 'deploy_exampledotcom.yml' but the general concepts can still apply.
Ansible allows you to deploy and configure using the same tool, so you would likely reuse groups and just
keep the OS configuration in seperate playbooks from the app deployment.
keep the OS configuration in separate playbooks from the app deployment.
Stage vs Production
+++++++++++++++++++
As also mentioned above, a good way to keep your stage (or testing) and production environments seperate is to use a seperate inventory file for stage and production. This way you pick with -i what you are targetting. Keeping them all in one file can lead to surprises!
As also mentioned above, a good way to keep your stage (or testing) and production environments separate is to use a separate inventory file for stage and production. This way you pick with -i what you are targetting. Keeping them all in one file can lead to surprises!
Testing things in a stage environment before trying in production is always a great idea. Your environments need not be the same
size and you can use group variables to control the differences between those environments.

View file

@ -16,7 +16,7 @@ options:
groups:
aliases: [ 'groupname' ]
description:
- The groups to add the hostname to, comma seperated.
- The groups to add the hostname to, comma separated.
required: false
author: Seth Vidal
examples: