Nit fix spelling of separate
This commit is contained in:
parent
97f9b6df1c
commit
5e5235a433
3 changed files with 6 additions and 6 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
|
Loading…
Reference in a new issue