From 5aad416ffeacccb41b5ee259f4819bdec94091e5 Mon Sep 17 00:00:00 2001 From: Michael DeHaan Date: Sun, 5 May 2013 14:04:03 -0400 Subject: [PATCH] remove playbook examples from main repo. Fear not, these are now in the ansible/ansible-examples repo :) --- examples/playbooks/ansible_pull.yml | 56 --- examples/playbooks/batch_size_control.yml | 19 - examples/playbooks/cloudformation.yaml | 45 -- examples/playbooks/complex_args.yml | 50 --- examples/playbooks/conditionals_part1.yml | 50 --- examples/playbooks/conditionals_part2.yml | 40 -- examples/playbooks/custom_filters.yml | 6 - examples/playbooks/delegation.yml | 39 -- examples/playbooks/environment.yml | 33 -- examples/playbooks/eucalyptus-ec2.yml | 53 --- examples/playbooks/file_secontext.yml | 18 - .../files/cloudformation-example.json | 399 ------------------ .../filter_plugins/custom_plugins.py | 29 -- examples/playbooks/get_url.yml | 16 - examples/playbooks/group_by.yml | 35 -- examples/playbooks/group_commands.yml | 18 - examples/playbooks/handlers/handlers.yml | 10 - examples/playbooks/intermediate_example.yml | 91 ---- examples/playbooks/intro_example.yml | 76 ---- examples/playbooks/loop_nested.yml | 10 - examples/playbooks/loop_plugins.yml | 20 - examples/playbooks/loop_with_items.yml | 30 -- examples/playbooks/mysql.yml | 18 - examples/playbooks/nested_playbooks.yml | 26 -- examples/playbooks/netscaler.yml | 25 -- examples/playbooks/postgresql.yml | 41 -- examples/playbooks/prompts.yml | 60 --- examples/playbooks/rabbitmq.yml | 39 -- examples/playbooks/register_logic.yml | 33 -- examples/playbooks/roles/foo/files/foo.txt | 2 - .../playbooks/roles/foo/handlers/main.yml | 10 - examples/playbooks/roles/foo/tasks/main.yml | 14 - examples/playbooks/roles/foo/templates/foo.j2 | 1 - examples/playbooks/roles/foo/vars/main.yml | 3 - examples/playbooks/roletest.yml | 71 ---- examples/playbooks/roletest2.yml | 57 --- examples/playbooks/selective_file_sources.yml | 28 -- examples/playbooks/tags.yml | 44 -- examples/playbooks/tasks/base.yml | 21 - .../playbooks/templates/custom-filters.j2 | 1 - .../templates/etc_cron.d_ansible-pull.j2 | 2 - .../templates/etc_logrotate.d_ansible-pull.j2 | 7 - examples/playbooks/templates/foo.j2 | 10 - examples/playbooks/templates/hostvars.j2 | 7 - examples/playbooks/upgraded_vars.yml | 30 -- examples/playbooks/user_commands.yml | 38 -- examples/playbooks/vars/CentOS.yml | 3 - examples/playbooks/vars/defaults.yml | 3 - examples/playbooks/vars/external_vars.yml | 3 - examples/playbooks/zfs.yml | 33 -- 50 files changed, 1773 deletions(-) delete mode 100644 examples/playbooks/ansible_pull.yml delete mode 100644 examples/playbooks/batch_size_control.yml delete mode 100644 examples/playbooks/cloudformation.yaml delete mode 100644 examples/playbooks/complex_args.yml delete mode 100644 examples/playbooks/conditionals_part1.yml delete mode 100644 examples/playbooks/conditionals_part2.yml delete mode 100644 examples/playbooks/custom_filters.yml delete mode 100644 examples/playbooks/delegation.yml delete mode 100644 examples/playbooks/environment.yml delete mode 100644 examples/playbooks/eucalyptus-ec2.yml delete mode 100644 examples/playbooks/file_secontext.yml delete mode 100644 examples/playbooks/files/cloudformation-example.json delete mode 100644 examples/playbooks/filter_plugins/custom_plugins.py delete mode 100644 examples/playbooks/get_url.yml delete mode 100644 examples/playbooks/group_by.yml delete mode 100644 examples/playbooks/group_commands.yml delete mode 100644 examples/playbooks/handlers/handlers.yml delete mode 100644 examples/playbooks/intermediate_example.yml delete mode 100644 examples/playbooks/intro_example.yml delete mode 100644 examples/playbooks/loop_nested.yml delete mode 100644 examples/playbooks/loop_plugins.yml delete mode 100644 examples/playbooks/loop_with_items.yml delete mode 100644 examples/playbooks/mysql.yml delete mode 100644 examples/playbooks/nested_playbooks.yml delete mode 100644 examples/playbooks/netscaler.yml delete mode 100644 examples/playbooks/postgresql.yml delete mode 100644 examples/playbooks/prompts.yml delete mode 100644 examples/playbooks/rabbitmq.yml delete mode 100644 examples/playbooks/register_logic.yml delete mode 100644 examples/playbooks/roles/foo/files/foo.txt delete mode 100644 examples/playbooks/roles/foo/handlers/main.yml delete mode 100644 examples/playbooks/roles/foo/tasks/main.yml delete mode 100644 examples/playbooks/roles/foo/templates/foo.j2 delete mode 100644 examples/playbooks/roles/foo/vars/main.yml delete mode 100644 examples/playbooks/roletest.yml delete mode 100644 examples/playbooks/roletest2.yml delete mode 100644 examples/playbooks/selective_file_sources.yml delete mode 100644 examples/playbooks/tags.yml delete mode 100644 examples/playbooks/tasks/base.yml delete mode 100644 examples/playbooks/templates/custom-filters.j2 delete mode 100644 examples/playbooks/templates/etc_cron.d_ansible-pull.j2 delete mode 100644 examples/playbooks/templates/etc_logrotate.d_ansible-pull.j2 delete mode 100644 examples/playbooks/templates/foo.j2 delete mode 100644 examples/playbooks/templates/hostvars.j2 delete mode 100644 examples/playbooks/upgraded_vars.yml delete mode 100644 examples/playbooks/user_commands.yml delete mode 100644 examples/playbooks/vars/CentOS.yml delete mode 100644 examples/playbooks/vars/defaults.yml delete mode 100644 examples/playbooks/vars/external_vars.yml delete mode 100644 examples/playbooks/zfs.yml diff --git a/examples/playbooks/ansible_pull.yml b/examples/playbooks/ansible_pull.yml deleted file mode 100644 index dd25b963e4c..00000000000 --- a/examples/playbooks/ansible_pull.yml +++ /dev/null @@ -1,56 +0,0 @@ -# ansible-pull setup -# -# on remote hosts, set up ansible to run periodically using the latest code -# from a particular checkout, in pull based fashion, inverting Ansible's -# usual push-based operating mode. -# -# This particular pull based mode is ideal for: -# -# (A) massive scale out -# (B) continual system remediation -# -# DO NOT RUN THIS AGAINST YOUR HOSTS WITHOUT CHANGING THE repo_url -# TO SOMETHING YOU HAVE PERSONALLY VERIFIED -# -# ---- - -- hosts: pull_mode_hosts - user: root - - vars: - - # schedule is fed directly to cron - schedule: '*/15 * * * *' - - # User to run ansible-pull as from cron - cron_user: root - - # File that ansible will use for logs - logfile: /var/log/ansible-pull.log - - # Directory to where repository will be cloned - workdir: /var/lib/ansible/local - - # Repository to check out -- YOU MUST CHANGE THIS - # repo must contain a local.yml file at top level - #repo_url: git://github.com/sfromm/ansible-playbooks.git - repo_url: SUPPLY_YOUR_OWN_GIT_URL_HERE - - tasks: - - - name: Install ansible - action: yum pkg=ansible state=installed - - - name: Create local directory to work from - action: file path={{workdir}} state=directory owner=root group=root mode=0751 - - - name: Copy ansible inventory file to client - action: copy src=/etc/ansible/hosts dest=/etc/ansible/hosts - owner=root group=root mode=0644 - - - name: Create crontab entry to clone/pull git repository - action: template src=templates/etc_cron.d_ansible-pull.j2 dest=/etc/cron.d/ansible-pull owner=root group=root mode=0644 - - - name: Create logrotate entry for ansible-pull.log - action: template src=templates/etc_logrotate.d_ansible-pull.j2 dest=/etc/logrotate.d/ansible-pull owner=root group=root mode=0644 diff --git a/examples/playbooks/batch_size_control.yml b/examples/playbooks/batch_size_control.yml deleted file mode 100644 index 970bc2a2a19..00000000000 --- a/examples/playbooks/batch_size_control.yml +++ /dev/null @@ -1,19 +0,0 @@ -# ordinarily, without the 'serial' keyword set, ansible will control all of your machines in a play at once, in parallel. -# if you want to perform a rolling update, so that each play completes all the way through on a certain number of hosts -# before moving on to the remaining hosts, use the 'serial' keyword like so: - ---- -- hosts: all - serial: 3 - -# now each of the tasks below will complete on 3 hosts before moving on to the next 3, regardless of how many -# hosts are selected by the "hosts:" line - - tasks: - - - name: ping - action: ping - - name: ping2 - action: ping - - diff --git a/examples/playbooks/cloudformation.yaml b/examples/playbooks/cloudformation.yaml deleted file mode 100644 index 76ab56a9591..00000000000 --- a/examples/playbooks/cloudformation.yaml +++ /dev/null @@ -1,45 +0,0 @@ ---- -# This playbook demonstrates how to use the ansible cloudformation module to launch an AWS CloudFormation stack. -# -# This module requires that the boto python library is installed, and that you have your AWS credentials -# in $HOME/.boto - -#The thought here is to bring up a bare infrastructure with CloudFormation, but use ansible to configure it. -#I generally do this in 2 different playbook runs as to allow the ec2.py inventory to be updated. - -#This module also uses "complex arguments" which were introduced in ansible 1.1 allowing you to specify the -#Cloudformation template parameters - -#This example launches a 3 node AutoScale group, with a security group, and an InstanceProfile with root permissions. - -#If a stack does not exist, it will be created. If it does exist and the template file has changed, the stack will be updated. -#If the parameters are different, the stack will also be updated. - -#CloudFormation stacks can take awhile to provision, if you are curious about its status, use the AWS -#web console or one of the CloudFormation CLI's. - -#Example update -- try first launching the stack with 3 as the ClusterSize. After it is launched, change it to 4 -#and run the playbook again. - -- name: provision stack - hosts: localhost - connection: local - gather_facts: false - - # Launch the cloudformation-example.json template. Register the output. - - tasks: - - name: launch ansible cloudformation example - cloudformation: > - stack_name="ansible-cloudformation" state=present - region=us-east-1 disable_rollback=true - template=files/cloudformation-example.json - args: - template_parameters: - KeyName: jmartin - DiskType: ephemeral - InstanceType: m1.small - ClusterSize: 3 - register: stack - - name: show stack outputs - debug: msg="My stack outputs are {{stack.stack_outputs}}" diff --git a/examples/playbooks/complex_args.yml b/examples/playbooks/complex_args.yml deleted file mode 100644 index 03742d0b13c..00000000000 --- a/examples/playbooks/complex_args.yml +++ /dev/null @@ -1,50 +0,0 @@ ---- - -# this is a bit of an advanced topic. -# -# generally Ansible likes to pass simple key=value arguments to modules. It occasionally comes up though -# that you might want to write a module that takes COMPLEX arguments, like lists and dictionaries. -# -# happen, at least right now, it should be a Python module, so it can leverage some common code in Ansible that -# makes this easy. If you write a non-Python module, you can still pass data across, but only hashes that -# do not contain lists or other hashes. If you write the Python module, you can do anything. -# -# note that if you were to use BOTH the key=value form and the 'args' form for passing data in, the key=value -# parameters take a higher priority, so you can use them for defaults, which can be useful. - -- hosts: all - user: root - gather_facts: no - - vars: - defaults: - state: stopped - complex: - ghostbusters: [ 'egon', 'ray', 'peter', 'winston' ] - mice: [ 'pinky', 'brain', 'larry' ] - - tasks: - - - name: this is the basic way data passing works for any module - action: ping data='Hi Mom' - - - name: of course this can also be written like so, which is shorter - ping: data='Hi Mom' - - - name: but what if you have a complex module that needs complicated data? - action: ping - args: - data: - moo: cow - asdf: [1,2,3,4] - - - name: can we make that cleaner? sure! - action: ping - args: { data: $complex } - - - name: here is an example of how it works with defaults, notice the key=value format wins - action: service name=httpd state=running - args: $defaults - - - diff --git a/examples/playbooks/conditionals_part1.yml b/examples/playbooks/conditionals_part1.yml deleted file mode 100644 index f3f9fcb9a06..00000000000 --- a/examples/playbooks/conditionals_part1.yml +++ /dev/null @@ -1,50 +0,0 @@ ---- -# this is a demo of conditional imports. This is a powerful concept -# and can be used to use the same recipe for different types of hosts, -# based on variables that bubble up from the hosts from tools such -# as ohai or facter. -# -# Here's an example use case: -# -# what to do if the service for apache is named 'httpd' on CentOS -# but is named 'apache' on Debian? - - -# there is only one play in this playbook, it runs on all hosts -# as root - -- hosts: all - user: root - -# we have a common list of variables stored in /vars/external_vars.yml -# that we will always import - -# next, we want to import files that are different per operating system -# and if no per operating system file is found, load a defaults file. -# for instance, if the OS was "CentOS", we'd try to load vars/CentOS.yml. -# if that was found, we would immediately stop. However if that wasn't -# present, we'd try to load vars/defaults.yml. If that in turn was not -# found, we would fail immediately, because we had gotten to the end of -# the list without importing anything. - - vars_files: - - - "vars/external_vars.yml" - - - [ "vars/{{ facter_operatingsystem }}.yml", "vars/defaults.yml" ] - -# and this is just a regular task line from a playbook, as we're used to. -# but with variables in it that come from above. Note that the variables -# from above are *also* available in templates - - tasks: - - - name: ensure apache is latest - action: "{{ packager }} pkg={{ apache }} state=latest" - - - name: ensure apache is running - action: service name={{ apache }} state=running - - - - diff --git a/examples/playbooks/conditionals_part2.yml b/examples/playbooks/conditionals_part2.yml deleted file mode 100644 index e40a1654a28..00000000000 --- a/examples/playbooks/conditionals_part2.yml +++ /dev/null @@ -1,40 +0,0 @@ ---- -# this is a demo of conditional executions using 'when' statements, which can skip -# certain tasks on machines/platforms/etc where they do not apply. - -- hosts: all - user: root - - vars: - favcolor: "red" - dog: "fido" - cat: "whiskers" - ssn: 8675309 - - tasks: - - - name: "do this if my favcolor is blue, and my dog is named fido" - action: shell /bin/false - when: favcolor == 'blue' and dog == 'fido' - - - name: "do this if my favcolor is not blue, and my dog is named fido" - action: shell /bin/true - when: favcolor != 'blue' and dog == 'fido' - - - name: "do this if my SSN is over 9000" - action: shell /bin/true - when: ssn > 9000 - - - name: "do this if I have one of these SSNs" - action: shell /bin/true - when: ssn in [ 8675309, 8675310, 8675311 ] - - - name: "do this if a variable named hippo is NOT defined" - action: shell /bin/true - when: hippo is not defined - - - name: "do this if a variable named hippo is defined" - action: shell /bin/true - when: hippo is defined - - diff --git a/examples/playbooks/custom_filters.yml b/examples/playbooks/custom_filters.yml deleted file mode 100644 index 2bc8feffa0c..00000000000 --- a/examples/playbooks/custom_filters.yml +++ /dev/null @@ -1,6 +0,0 @@ ---- - -- name: Demonstrate custom jinja2 filters - hosts: all - tasks: - - action: template src=templates/custom-filters.j2 dest=/tmp/custom-filters.txt diff --git a/examples/playbooks/delegation.yml b/examples/playbooks/delegation.yml deleted file mode 100644 index 28946af34cd..00000000000 --- a/examples/playbooks/delegation.yml +++ /dev/null @@ -1,39 +0,0 @@ ---- - -# this is an example of how we can perform actions on a given host on behalf of all the hosts -# in a play. -# -# The two main uses of this would be signalling an outage window for hosts that -# we are going to start upgrading, or to take a machine out of rotation by talking to a load -# balancer. -# -# This example cheats by replacing the load balancer script with the 'echo' command, -# leaving actual communication with the load balancer as an exercise to the reader. In reality, -# you could call anything you want, the main thing is that it should do something with -# {{inventory_hostname}} - -# NOTE: see batch_size_control.yml for an example of the 'serial' keyword, which you almost certainly -# want to use in this kind of example. Here we have a mocked up example that does something to -# 5 hosts at a time - -- hosts: all - serial: 5 - - tasks: - - - name: take the machine out of rotation - action: command echo taking out of rotation {{inventory_hostname}} - delegate_to: 127.0.0.1 - -# here's an alternate notation if you are delegating to 127.0.0.1, you can use 'local_action' -# instead of 'action' and leave off the 'delegate_to' part. -# -# - local_action: command echo taking out of rotation {{inventory_hostname}} - - - name: do several things on the actual host - action: command echo hi mom {{inventory_hostname}} - - - name: put machine back into rotation - action: command echo inserting into rotation {{inventory_hostname}} - delegate_to: 127.0.0.1 - diff --git a/examples/playbooks/environment.yml b/examples/playbooks/environment.yml deleted file mode 100644 index 10d5ddb9a76..00000000000 --- a/examples/playbooks/environment.yml +++ /dev/null @@ -1,33 +0,0 @@ ---- - -# it is often useful to be able to set the environment for one command and have that environment be totally -# different for another. An example is you might use a HTTP proxy for some packages but not for others. -# -# in Ansible 1.1 and later, you can pass the environment to any module using either a dictionary variable -# or a dictionary itself. - - -- hosts: all - user: root - - # here we make a variable named "env" that is a dictionary - vars: - env: - HI: test2 - http_proxy: http://proxy.example.com:8080 - - tasks: - - # here we just define the dictionary directly and use it - # (here $HI is the shell variable as nothing in Ansible will replace it) - - - shell: echo $HI - environment: - HI: test1 - - # here we are using the $env variable above - - - shell: echo $HI - environment: env - - diff --git a/examples/playbooks/eucalyptus-ec2.yml b/examples/playbooks/eucalyptus-ec2.yml deleted file mode 100644 index c8fe3386212..00000000000 --- a/examples/playbooks/eucalyptus-ec2.yml +++ /dev/null @@ -1,53 +0,0 @@ ---- -# This playbook is an example for deploying multiple instances into EC2/Euca and "doing something" with them. -# - uses the ec2 and ec2_vol module. -# -# Run this with ansible-playbook and supply the private key for your EC2/Euca user (to access the instance in the second play), e.g: -# ansible-playbook eucalyptus-ec2-deploy.yml -v --private-key=/path/to/ec2/pri/key - -- name: Stage instance(s) - hosts: local - connection: local - user: root - gather_facts: false - - vars: - keypair: mykeypair - instance_type: m1.small - security_group: default - image: emi-048B3A37 - - # Launch 5 instances with the following parameters. Register the output. - - tasks: - - name: Launch instance - local_action: ec2 keypair={{keypair}} group={{security_group}} instance_type={{instance_type}} image={{image}} wait=true count=5 - register: ec2 - - # Use with_items to add each instances public IP to a new hostgroup for use in the next play. - - - name: Add new instances to host group - local_action: add_host hostname={{item.public_ip}} groupname=deploy - with_items: ${ec2.instances} - - # Use the ec2_vol module to create volumes for attachment to each instance. Use with_items to attach to each instance (by returned id) launched previously. - - - name: Create a volume and attach - local_action: ec2_vol volume_size=20 instance={{item.id}} - with_items: ${ec2.instances} - -# This play targets the new host group - -- name: Configure instance - hosts: deploy - user: root - gather_facts: True - - # Do some stuff on each instance .... - - tasks: - - name: Ensure NTP is up and running - action: service name=ntpd state=started - - - name: Install Apache Web Server - action: yum pkg=httpd state=latest diff --git a/examples/playbooks/file_secontext.yml b/examples/playbooks/file_secontext.yml deleted file mode 100644 index 117a930dc0a..00000000000 --- a/examples/playbooks/file_secontext.yml +++ /dev/null @@ -1,18 +0,0 @@ ---- -# This is a demo of how to manage the selinux context using the file module -- hosts: test - user: root - tasks: - - name: Change setype of /etc/exports to non-default value - action: file path=/etc/exports setype=etc_t - - name: Change seuser of /etc/exports to non-default value - action: file path=/etc/exports seuser=unconfined_u - - name: Set selinux context back to default value - action: file path=/etc/exports context=default - - name: Create empty file - action: command /bin/touch /tmp/foo - - name: Change setype of /tmp/foo - action: file path=/tmp/foo setype=default_t - - name: Try to set secontext to default, but this will fail - because of the lack of a default in the policy - action: file path=/tmp/foo context=default diff --git a/examples/playbooks/files/cloudformation-example.json b/examples/playbooks/files/cloudformation-example.json deleted file mode 100644 index 945e4e4d7ca..00000000000 --- a/examples/playbooks/files/cloudformation-example.json +++ /dev/null @@ -1,399 +0,0 @@ -{ - "Outputs" : { - "ClusterSecGroup" : { - "Description" : "Name of RegionalManagerSecGroup", - "Value" : { - "Ref" : "InstanceSecurityGroup" - } - } - }, - "AWSTemplateFormatVersion" : "2010-09-09", - "Description" : "Launches an example cluster", - "Mappings" : { - "ebs" : { - "ap-northeast-1" : { - "AMI" : "ami-4e6cd34f" - }, - "ap-southeast-1" : { - "AMI" : "ami-a6a7e7f4" - }, - "eu-west-1" : { - "AMI" : "ami-c37474b7" - }, - "sa-east-1" : { - "AMI" : "ami-1e08d103" - }, - "us-east-1" : { - "AMI" : "ami-1624987f" - }, - "us-west-1" : { - "AMI" : "ami-1bf9de5e" - }, - "us-west-2" : { - "AMI" : "ami-2a31bf1a" - } - }, - "ephemeral" : { - "ap-northeast-1" : { - "AMI" : "ami-5a6cd35b" - }, - "ap-southeast-1" : { - "AMI" : "ami-a8a7e7fa" - }, - "eu-west-1" : { - "AMI" : "ami-b57474c1" - }, - "sa-east-1" : { - "AMI" : "ami-1608d10b" - }, - "us-east-1" : { - "AMI" : "ami-e8249881" - }, - "us-west-1" : { - "AMI" : "ami-21f9de64" - }, - "us-west-2" : { - "AMI" : "ami-2e31bf1e" - } - } - }, - "Parameters" : { - "ClusterSize" : { - "Description" : "Number of nodes in the cluster", - "Type" : "String" - }, - "DiskType" : { - "AllowedValues" : [ - "ephemeral", - "ebs" - ], - "Default" : "ephemeral", - "Description" : "Type of Disk to use ( ephemeral/ebs )", - "Type" : "String" - }, - "InstanceType" : { - "AllowedValues" : [ - "t1.micro", - "m1.small", - "m1.medium", - "m1.large", - "m1.xlarge", - "m2.xlarge", - "m2.2xlarge", - "m2.4xlarge", - "c1.medium", - "c1.xlarge", - "cc1.4xlarge" - ], - "ConstraintDescription" : "must be valid instance type. ", - "Default" : "m1.large", - "Description" : "Type of EC2 instance for cluster", - "Type" : "String" - }, - "KeyName" : { - "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the cluster", - "Type" : "String" - } - }, - "Resources" : { - "ApplicationWaitCondition" : { - "DependsOn" : "ClusterServerGroup", - "Properties" : { - "Handle" : { - "Ref" : "ApplicationWaitHandle" - }, - "Timeout" : "4500" - }, - "Type" : "AWS::CloudFormation::WaitCondition" - }, - "ApplicationWaitHandle" : { - "Type" : "AWS::CloudFormation::WaitConditionHandle" - }, - "CFNInitUser" : { - "Properties" : { - "Path" : "/", - "Policies" : [ - { - "PolicyDocument" : { - "Statement" : [ - { - "Action" : [ - "cloudformation:DescribeStackResource", - "s3:GetObject" - ], - "Effect" : "Allow", - "Resource" : "*" - } - ] - }, - "PolicyName" : "AccessForCFNInit" - } - ] - }, - "Type" : "AWS::IAM::User" - }, - "CFNKeys" : { - "Properties" : { - "UserName" : { - "Ref" : "CFNInitUser" - } - }, - "Type" : "AWS::IAM::AccessKey" - }, - "ClusterCommunication1" : { - "Properties" : { - "FromPort" : "-1", - "GroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "IpProtocol" : "icmp", - "SourceSecurityGroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "ToPort" : "-1" - }, - "Type" : "AWS::EC2::SecurityGroupIngress" - }, - "ClusterCommunication2" : { - "Properties" : { - "FromPort" : "1", - "GroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "IpProtocol" : "tcp", - "SourceSecurityGroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "ToPort" : "65356" - }, - "Type" : "AWS::EC2::SecurityGroupIngress" - }, - "ClusterCommunication3" : { - "Properties" : { - "FromPort" : "1", - "GroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "IpProtocol" : "udp", - "SourceSecurityGroupName" : { - "Ref" : "InstanceSecurityGroup" - }, - "ToPort" : "65356" - }, - "Type" : "AWS::EC2::SecurityGroupIngress" - }, - "InstanceSecurityGroup" : { - "Properties" : { - "GroupDescription" : "Enable SSH access via port 22", - "SecurityGroupIngress" : [ - { - "CidrIp" : "0.0.0.0/0", - "FromPort" : "22", - "IpProtocol" : "tcp", - "ToPort" : "22" - } - ] - }, - "Type" : "AWS::EC2::SecurityGroup" - }, - "LaunchConfig" : { - "Properties" : { - "IamInstanceProfile" : { - "Ref" : "RootInstanceProfile" - }, - "ImageId" : { - "Fn::FindInMap" : [ - { - "Ref" : "DiskType" - }, - { - "Ref" : "AWS::Region" - }, - "AMI" - ] - }, - "InstanceType" : { - "Ref" : "InstanceType" - }, - "KeyName" : { - "Ref" : "KeyName" - }, - "SecurityGroups" : [ - { - "Ref" : "InstanceSecurityGroup" - } - ], - "UserData" : { - "Fn::Base64" : { - "Fn::Join" : [ - "\n", - [ - "#!/bin/bash -v", - "exec > >(tee /var/log/cfn-data.log|logger -t user-data -s 2>/dev/console) 2>&1", - "", - "sleep 10", - "", - "function retry {", - " nTrys=0", - " maxTrys=5", - " status=256", - " until [ $status == 0 ] ; do", - " $1", - " status=$?", - " nTrys=$(($nTrys + 1))", - " if [ $nTrys -gt $maxTrys ] ; then", - " echo \"Number of re-trys exceeded. Exit code: $status\"", - " exit $status", - " fi", - " if [ $status != 0 ] ; then", - " echo \"Failed (exit code $status)... retry $nTrys\"", - " sleep 10", - " fi", - " done", - "}", - "", - "yum update -y aws-cfn-bootstrap", - "", - "#for all the stuff that complains about sudo and tty", - "sed -i 's,Defaults requiretty,#Defaults requiretty,g' /etc/sudoers", - "", - "function error_exit", - "{", - { - "Fn::Join" : [ - "", - [ - " /opt/aws/bin/cfn-signal -e 1 -r \"$1\" '", - { - "Ref" : "ApplicationWaitHandle" - }, - "'" - ] - ] - }, - "}", - "yum update -y aws-cfn-bootstrap", - "#this runs the first stage of cfinit", - { - "Fn::Join" : [ - "", - [ - "#/opt/aws/bin/cfn-init -c ascending -v --region ", - { - "Ref" : "AWS::Region" - }, - " -s ", - { - "Ref" : "AWS::StackName" - }, - " -r ", - "LaunchConfig", - " --access-key ", - { - "Ref" : "CFNKeys" - }, - " --secret-key ", - { - "Fn::GetAtt" : [ - "CFNKeys", - "SecretAccessKey" - ] - }, - " || error_exit 'Failed to initialize client using cfn-init'" - ] - ] - }, - "", - "", - "", - "result_code=$?", - { - "Fn::Join" : [ - "", - [ - "/opt/aws/bin/cfn-signal -e $result_code '", - { - "Ref" : "ApplicationWaitHandle" - }, - "'" - ] - ] - } - ] - ] - } - } - }, - "Type" : "AWS::AutoScaling::LaunchConfiguration" - }, - "ClusterServerGroup" : { - "Properties" : { - "AvailabilityZones" : { - "Fn::GetAZs" : "" - }, - "LaunchConfigurationName" : { - "Ref" : "LaunchConfig" - }, - "MaxSize" : { - "Ref" : "ClusterSize" - }, - "MinSize" : { - "Ref" : "ClusterSize" - } - }, - "Type" : "AWS::AutoScaling::AutoScalingGroup" - }, - "RolePolicies" : { - "Properties" : { - "PolicyDocument" : { - "Statement" : [ - { - "Action" : "*", - "Effect" : "Allow", - "Resource" : "*" - } - ] - }, - "PolicyName" : "root", - "Roles" : [ - { - "Ref" : "RootRole" - } - ] - }, - "Type" : "AWS::IAM::Policy" - }, - "RootInstanceProfile" : { - "Properties" : { - "Path" : "/", - "Roles" : [ - { - "Ref" : "RootRole" - } - ] - }, - "Type" : "AWS::IAM::InstanceProfile" - }, - "RootRole" : { - "Properties" : { - "AssumeRolePolicyDocument" : { - "Statement" : [ - { - "Action" : [ - "sts:AssumeRole" - ], - "Effect" : "Allow", - "Principal" : { - "Service" : [ - "ec2.amazonaws.com" - ] - } - } - ] - }, - "Path" : "/" - }, - "Type" : "AWS::IAM::Role" - } - } -} \ No newline at end of file diff --git a/examples/playbooks/filter_plugins/custom_plugins.py b/examples/playbooks/filter_plugins/custom_plugins.py deleted file mode 100644 index d00e6c3fccf..00000000000 --- a/examples/playbooks/filter_plugins/custom_plugins.py +++ /dev/null @@ -1,29 +0,0 @@ -# (c) 2012, Jeroen Hoekx -# -# This file is part of Ansible -# -# Ansible is free software: you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation, either version 3 of the License, or -# (at your option) any later version. -# -# Ansible is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with Ansible. If not, see . - -class FilterModule(object): - ''' Custom filters are loaded by FilterModule objects ''' - - def filters(self): - ''' FilterModule objects return a dict mapping filter names to - filter functions. ''' - return { - 'generate_answer': self.generate_answer, - } - - def generate_answer(self, value): - return '42' diff --git a/examples/playbooks/get_url.yml b/examples/playbooks/get_url.yml deleted file mode 100644 index b1a7dfe6907..00000000000 --- a/examples/playbooks/get_url.yml +++ /dev/null @@ -1,16 +0,0 @@ ---- -- hosts: webservers - vars: - - jquery_directory: /var/www/html/javascript - - person: 'Susie%20Smith' - tasks: - - name: Create directory for jQuery - action: file dest={{jquery_directory}} state=directory mode=0755 - - name: Grab a bunch of jQuery stuff - action: get_url url=http://code.jquery.com/{{item}} dest={{jquery_directory}} mode=0444 - with_items: - - jquery.min.js - - mobile/latest/jquery.mobile.min.js - - ui/jquery-ui-git.css - #- name: Pass urlencoded name to CGI - # action: get_url url=http://example.com/name.cgi?name='{{person}}' dest=/tmp/test diff --git a/examples/playbooks/group_by.yml b/examples/playbooks/group_by.yml deleted file mode 100644 index f682f7c4e22..00000000000 --- a/examples/playbooks/group_by.yml +++ /dev/null @@ -1,35 +0,0 @@ ---- -# Example playbook to demonstrate the group_by action plugin. -# -# as we know, the setup module will automatically run in each play, and sets up various -# facts. We can then create temporary (in memory only) groups based on those facts, which -# are useful ways of selecting similar sets of hosts. -# -# Additionally, we can use the 'register' keyword in Ansible to set similar variables -# and use those for grouping. This is not shown in this example. - -- hosts: all - - tasks: - - - name: Create a group of all hosts by operating system - action: group_by key={{ansible_distribution}}-{{ansible_distribution_version}} - -# the following host group does not exist in inventory and was created by the group_by -# module. - -- hosts: CentOS-6.2 - - tasks: - - - name: ping all CentOS 6.2 hosts - action: ping - -- hosts: CentOS-6.3 - - tasks: - - - name: ping all CentOS 6.3 hosts - action: ping - - diff --git a/examples/playbooks/group_commands.yml b/examples/playbooks/group_commands.yml deleted file mode 100644 index afb7be91e68..00000000000 --- a/examples/playbooks/group_commands.yml +++ /dev/null @@ -1,18 +0,0 @@ ---- -# This is a demo of how the group command works. - -- hosts: all - user: root - sudo: yes - - tasks: - - # Walk through group creation, modification, and deletion - - name: create a group - action: group name=tset - - # You can only modify the group's gid - - action: group name=tset gid=7777 - - # And finally remove the group - - action: group name=tset state=absent diff --git a/examples/playbooks/handlers/handlers.yml b/examples/playbooks/handlers/handlers.yml deleted file mode 100644 index b9a25d9edea..00000000000 --- a/examples/playbooks/handlers/handlers.yml +++ /dev/null @@ -1,10 +0,0 @@ ---- - -# this is an example to show that handlers can be included from yaml files, -# to promote reuse between different plays or even playbooks. They work -# just like normal handlers. - -- name: restart apache - action: service name=httpd state=restarted -- name: restart memcached - action: service name=memcached state=restarted diff --git a/examples/playbooks/intermediate_example.yml b/examples/playbooks/intermediate_example.yml deleted file mode 100644 index e0cd209ef06..00000000000 --- a/examples/playbooks/intermediate_example.yml +++ /dev/null @@ -1,91 +0,0 @@ ---- -# see intro_example.yml first! -# This file explains some more advanced features of playbooks. -# because of the comments it's less concise than it normally is. But feel -# free to comment your playbooks if you like. - -- hosts: all - - # we can define variables the normal way... - - vars: - release: 2.0 - - # but they can also come from other files. This can be a relative - # or absolute path. This is a good way to store 'secret' variable - # files but still keep the playbook in public source control - - vars_files: - - vars/external_vars.yml - - # as with before, every play has a list of tasks in it - - tasks: - - # tasks can be written the normal way... - - - name: arbitrary command - action: command /bin/true - - # or we can promote reuse and simplicity by including tasks - # from other files, for instance, to reuse common tasks - - - include: tasks/base.yml - - # we could also have done something like: - # - include: wordpress.yml user=timmy - # and had access to the template variable $user in the - # included file, if we wanted to. Variables from vars - # and vars_files are also available inside include files - - handlers: - - # handlers can also be included from files, to promote reuse - # and simpler recipes, you may wish to only have one - # handler file for all your plays and playbooks. This example really - # doesn't notify any handlers, it is just showing you how they would - # be included (see intro_example for usage). - - - include: handlers/handlers.yml - - # you can mix things that are directly in the file with things - # that are included. Order is executed as written, but only - # handlers that have been notified get executed - - - name: restart foo - action: service name=foo state=restarted - -# =============================================================== - -# Here's a second play in the same playbook. This will be run -# after the first playbook completes on all hosts. You may want -# a different play for each class of systems, or may want a different -# play for each stage in a complex multi-node deployment push -# process. How you use them are up to you. - -# any play in a playbook can be executed by a user other than root -# if you want. sudo support is coming too. - -- hosts: webservers - user: mdehaan - - # vars must be specified again for the next play in the playbook - # but can be reused by including from vars_files if you want - # you can use vars, vars_files, or both. vars_files overrides - # those set in vars. - - vars: - release: 2.0 - vars_files: - - vars/external_vars.yml - - - # these all runs as the user 'mdehaan'. If there were any handlers - # they would as well. - - tasks: - - - name: some random command - action: command /bin/true - - diff --git a/examples/playbooks/intro_example.yml b/examples/playbooks/intro_example.yml deleted file mode 100644 index b81d250d445..00000000000 --- a/examples/playbooks/intro_example.yml +++ /dev/null @@ -1,76 +0,0 @@ ---- -# this is an annotated example of some features available in playbooks -# it shows how to make sure packages are updated, how to make sure -# services are running, and how to template files. It also demos -# change handlers that can restart things (or trigger other actions) -# when resources change. For more advanced examples, see example2.yml - -# on all hosts, run as the user root... - -- name: example play - hosts: all - user: root - -# could have also have done: -# user: mdehaan -# sudo: yes - - # make these variables available inside of templates - # for when we use the 'template' action/module later on... - - vars: - http_port: 80 - max_clients: 200 - - # define the tasks that are part of this play... - - tasks: - - # task #1 is to run an arbitrary command - # we'll simulate a long running task, wait for up to 45 seconds, poll every 5 - # obviously this does nothing useful but you get the idea - - - name: longrunner - action: command /bin/sleep 15 - async: 45 - poll: 5 - - # let's demo file operations. - # - # We can 'copy' files or 'template' them instead, using jinja2 - # as the templating engine. This is done using the variables - # from the vars section above mixed in with variables bubbled up - # automatically from tools like facter and ohai. 'copy' - # works just like 'template' but does not do variable subsitution. - # - # If and only if the file changes, restart apache at the very - # end of the playbook run - - - name: write some_random_foo configuration - action: template src=templates/foo.j2 dest=/etc/some_random_foo.conf - notify: - - restart apache - - # make sure httpd is installed at the latest version - - - name: install httpd - action: yum pkg=httpd state=latest - - # make sure httpd is running - - - name: httpd start - action: service name=httpd state=running - - # handlers are only run when things change, at the very end of each - # play. Let's define some. The names are significant and must - # match the 'notify' sections above - - handlers: - - # this particular handler is run when some_random_foo.conf - # is changed, and only then - - - name: restart apache - action: service name=httpd state=restarted - - diff --git a/examples/playbooks/loop_nested.yml b/examples/playbooks/loop_nested.yml deleted file mode 100644 index b546bd1e7c8..00000000000 --- a/examples/playbooks/loop_nested.yml +++ /dev/null @@ -1,10 +0,0 @@ ---- -# this is a trivial example of how to do a nested loop. - -- hosts: all - tasks: - - shell: echo "nested test a={{ item[0] }} b={{ item[1] }} c={{ item[2] }}" - with_nested: - - [ 'red', 'blue', 'green' ] - - [ 1, 2, 3 ] - - [ 'up', 'down', 'strange'] diff --git a/examples/playbooks/loop_plugins.yml b/examples/playbooks/loop_plugins.yml deleted file mode 100644 index 0ea6395172d..00000000000 --- a/examples/playbooks/loop_plugins.yml +++ /dev/null @@ -1,20 +0,0 @@ ---- - -# in addition to loop_with_items, the loop that works over a variable, ansible can do more sophisticated looping. - -# developer types: these are powered by 'lookup_plugins' should you ever decide to write your own -# see lib/ansible/runner/lookup_plugins/fileglob.py -- they can do basically anything! - -- hosts: all - gather_facts: no - - tasks: - - # this will copy a bunch of config files over -- dir must be created first - - - file: dest=/etc/fooapp state=directory - - - copy: src={{ item }} dest=/etc/fooapp/ owner=root mode=600 - with_fileglob: /playbooks/files/fooapp/* - - diff --git a/examples/playbooks/loop_with_items.yml b/examples/playbooks/loop_with_items.yml deleted file mode 100644 index 3b9efba4899..00000000000 --- a/examples/playbooks/loop_with_items.yml +++ /dev/null @@ -1,30 +0,0 @@ ---- -# this is an example of how to run repeated task elements over lists -# of items, for example, installing multiple packages or configuring -# multiple users - -- hosts: all - user: root - - tasks: - - - name: install packages - action: yum name={{ item }} state=installed - with_items: - - cobbler - - httpd - - - name: configure users - action: user name={{ item }} state=present groups=wheel - with_items: - - testuser1 - - testuser2 - - - name: remove users - action: user name={{ item }} state=absent - with_items: - - testuser1 - - testuser2 - - - diff --git a/examples/playbooks/mysql.yml b/examples/playbooks/mysql.yml deleted file mode 100644 index 27207a837ae..00000000000 --- a/examples/playbooks/mysql.yml +++ /dev/null @@ -1,18 +0,0 @@ -## -# Example Ansible playbook that uses the MySQL module. -# - ---- -- hosts: all - user: root - - tasks: - - - name: Create database user - action: mysql_user user=bob password=12345 priv=*.*:ALL state=present - - - name: Create database - action: mysql_db db=bobdata state=present - - - name: Ensure no user named 'sally' exists and delete if found. - action: mysql_user user=sally state=absent diff --git a/examples/playbooks/nested_playbooks.yml b/examples/playbooks/nested_playbooks.yml deleted file mode 100644 index 3d43608a02a..00000000000 --- a/examples/playbooks/nested_playbooks.yml +++ /dev/null @@ -1,26 +0,0 @@ ---- -# it is possible to have top level playbook files import other playbook -# files. For example, a playbook called could include three -# different playbooks, such as webservers, workers, dbservers, etc. -# -# Running the site playbook would run all playbooks, while individual -# playbooks could still be run directly. This is somewhat like -# the tag feature and can be used in conjunction for very fine grained -# control over what you want to target when running ansible. - -- name: this is a play at the top level of a file - hosts: all - user: root - tasks: - - name: say hi - tags: foo - action: shell echo "hi..." - -# and this is how we include another playbook, be careful and -# don't recurse infinitely or anything. Note you can't use -# any variables in the include path here. - -- include: intro_example.yml - -# and if we wanted, we can continue with more includes here, -# or more plays inline in this file diff --git a/examples/playbooks/netscaler.yml b/examples/playbooks/netscaler.yml deleted file mode 100644 index b1f17101316..00000000000 --- a/examples/playbooks/netscaler.yml +++ /dev/null @@ -1,25 +0,0 @@ ---- -# -# NetScaler module example -# - -- hosts: web-pool - serial: 3 - vars: - nsc_host: nsc.example.com - nsc_user: admin - nsc_pass: nimda - # type of the netscaler object you want to manipulate - type: service - # netscaler object name - name: "{{facter_fqdn}}:8080" - - tasks: - - name: disable service in the lb - action: netscaler nsc_host={{nsc_host}} user={{nsc_user}} password={{nsc_pass}} name={{name}} type={{type}} action=disable - - - name: deploy new code - action: shell yum upgrade -y - - - name: enable in the lb - action: netscaler nsc_host={{nsc_host}} user={{nsc_user}} password={{nsc_pass}} name={{name}} type={{type}} action=enable diff --git a/examples/playbooks/postgresql.yml b/examples/playbooks/postgresql.yml deleted file mode 100644 index cb763bff9ae..00000000000 --- a/examples/playbooks/postgresql.yml +++ /dev/null @@ -1,41 +0,0 @@ -## -# Example Ansible playbook that uses the PostgreSQL module. -# -# This installs PostgreSQL on an Ubuntu system, creates a database called -# "myapp" and a user called "django" with password "mysupersecretpassword" -# with access to the "myapp" database. -# ---- -- hosts: webservers - sudo: yes - gather_facts: no - - tasks: - - name: ensure apt cache is up to date - action: apt update_cache=yes - - name: ensure packages are installed - action: apt name={{item}} - with_items: - - postgresql - - libpq-dev - - python-psycopg2 - -- hosts: webservers - sudo: yes - sudo_user: postgres - gather_facts: no - - vars: - dbname: myapp - dbuser: django - dbpassword: mysupersecreetpassword - - tasks: - - name: ensure database is created - action: postgresql_db db={{dbname}} - - - name: ensure user has access to database - action: postgresql_user db={{dbname}} user={{dbuser}} password={{dbpassword}} priv=ALL - - - name: ensure user does not have unnecessary privilege - action: postgresql_user user={{dbuser}} role_attr_flags=NOSUPERUSER,NOCREATEDB diff --git a/examples/playbooks/prompts.yml b/examples/playbooks/prompts.yml deleted file mode 100644 index 6016eaad1da..00000000000 --- a/examples/playbooks/prompts.yml +++ /dev/null @@ -1,60 +0,0 @@ ---- - -# it is possible to ask for variables from the user at the start -# of a playbook run, for example, as part of a release script. - -- hosts: all - user: root - -# regular variables are a dictionary of keys and values - - vars: - this_is_a_regular_var: 'moo' - so_is_this: 'quack' - -# alternatively, they can ALSO be passed in from the outside: -# ansible-playbook foo.yml --extra-vars="foo=100 bar=101" -# or through external inventory scripts (see online API docs) - -# here's basic mode prompting. Specify a hash of variable names and a prompt for -# each. -# -# vars_prompt: -# release_version: "product release version" - -# prompts can also be specified like this, allowing for hiding the prompt as -# entered. In the future, this may also be used to support crypted variables - - vars_prompt: - - name: "some_password" - prompt: "Enter password" - private: yes - - - name: "release_version" - prompt: "Product release version" - default: "my_default_version" - private: no - - - name: "my_password2" - prompt: "Enter password2" - private: yes - encrypt: "md5_crypt" - confirm: yes - salt_size: 7 - salt: "foo" - -# this is just a simple example to show that vars_prompt works, but -# you might ask for a tag to use with the git module or perhaps -# a package version to use with the yum module. - - tasks: - - - name: imagine this did something interesting with {{release_version}} - action: shell echo foo >> /tmp/{{release_version}}-alpha - - - name: look we crypted a password - action: shell echo my password is {{my_password2}} - - - - diff --git a/examples/playbooks/rabbitmq.yml b/examples/playbooks/rabbitmq.yml deleted file mode 100644 index 5996f5422c0..00000000000 --- a/examples/playbooks/rabbitmq.yml +++ /dev/null @@ -1,39 +0,0 @@ ---- -- hosts: rabbitmq - sudo: true - vars: - rabbitmq_version: 3.0.2-1 - - tasks: - - name: ensure python-software-properties is installed - apt: pkg=python-software-properties state=installed - - - name: add rabbitmq official apt repository - apt_repository: repo='deb http://www.rabbitmq.com/debian/ testing main' state=present - - - name: install rabbitmq - apt: pkg=rabbitmq-server={{rabbitmq_version}} state=installed force=yes - - - name: enable rabbitmq plugins - rabbitmq_plugin: names=rabbitmq_management,rabbitmq_tracing,rabbitmq_federation state=enabled - notify: - - restart rabbitmq - - - name: add users - rabbitmq_user: user={{item}} password=changeme tags=administrator,{{item}} vhost=/ configure_priv=.* write_priv=.* read_priv=.* state=present - with_items: - - user1 - - user2 - - - name: remove default guest user - rabbitmq_user: user=guest state=absent - - - name: ensure vhost /test is present - rabbitmq_vhost: name=/test state=present - - - name: set federation local-username - rabbitmq_parameter: component=federation name=local-username value='"user1"' state=present - - handlers: - - name: restart rabbitmq - service: name=rabbitmq-server state=restarted diff --git a/examples/playbooks/register_logic.yml b/examples/playbooks/register_logic.yml deleted file mode 100644 index 8e143e472aa..00000000000 --- a/examples/playbooks/register_logic.yml +++ /dev/null @@ -1,33 +0,0 @@ -# here's a cool advanced topic about how to perform conditional logic in ansible without resorting -# to writing your own module that defines facts. You can do that too, and it's easy to do, but -# often you just want to run a command and then decide whether to run some steps or not. That's -# easy to do, and here we'll show you how. - -- name: test playbook - user: root - hosts: all - - tasks: - - # it is possible to save the result of any command in a named register. This variable will be made - # available to tasks and templates made further down in the execution flow. - - - action: shell grep hi /etc/motd - ignore_errors: yes - register: motd_result - - # and here we access the register. Note that variable is structured data because - # it is a return from the command module. The shell module makes available variables such as - # as 'stdout', 'stderr', and 'rc'. - - # here we run the next action only if the previous grep returned true - - - action: shell echo "motd contains the word hi" - when: motd_result.rc == 0 - - # alternatively: - - - action: shell echo "motd contains the word hi" - when: motd_result.stdout.find('hi') != -1 - - diff --git a/examples/playbooks/roles/foo/files/foo.txt b/examples/playbooks/roles/foo/files/foo.txt deleted file mode 100644 index 7b6f19a00c0..00000000000 --- a/examples/playbooks/roles/foo/files/foo.txt +++ /dev/null @@ -1,2 +0,0 @@ -This is a file - diff --git a/examples/playbooks/roles/foo/handlers/main.yml b/examples/playbooks/roles/foo/handlers/main.yml deleted file mode 100644 index 030b30f5e3a..00000000000 --- a/examples/playbooks/roles/foo/handlers/main.yml +++ /dev/null @@ -1,10 +0,0 @@ ---- - -- name: blippy - shell: echo notifier called, and the value of x is '{{ x }}' - -# within a role, it's possible to include other task files as well. By default, we -# can reference files in the same directory without doing anything special: - -# - include: other.yml - diff --git a/examples/playbooks/roles/foo/tasks/main.yml b/examples/playbooks/roles/foo/tasks/main.yml deleted file mode 100644 index 1642311f51f..00000000000 --- a/examples/playbooks/roles/foo/tasks/main.yml +++ /dev/null @@ -1,14 +0,0 @@ ---- - -- name: copy operation - copy: src=foo.txt dest=/tmp/roles_test1.txt - -- name: template operation - template: src=foo.j2 dest=/tmp/roles_test2.txt - notify: - - blippy - -- name: demo that parameterized roles work - shell: echo just FYI, param1={{ param1 }}, param2 ={{ param2 }} - - diff --git a/examples/playbooks/roles/foo/templates/foo.j2 b/examples/playbooks/roles/foo/templates/foo.j2 deleted file mode 100644 index 172015653fa..00000000000 --- a/examples/playbooks/roles/foo/templates/foo.j2 +++ /dev/null @@ -1 +0,0 @@ -I am a {{ ansible_os_family }} distribution. diff --git a/examples/playbooks/roles/foo/vars/main.yml b/examples/playbooks/roles/foo/vars/main.yml deleted file mode 100644 index 68576ba28f0..00000000000 --- a/examples/playbooks/roles/foo/vars/main.yml +++ /dev/null @@ -1,3 +0,0 @@ ---- -x: '{{ ansible_machine }}' - diff --git a/examples/playbooks/roletest.yml b/examples/playbooks/roletest.yml deleted file mode 100644 index df2b25cb80c..00000000000 --- a/examples/playbooks/roletest.yml +++ /dev/null @@ -1,71 +0,0 @@ -# in Ansible 1.2 and later, roles allow easy best-practices organization of content -# and maximize shareability of ansible building blocks. -# -# suppose a playbook applied to a group of hosts includes two roles, foo and bar. -# -# what do roles do in this case? -# -# listing the roles as foo and bar will auto include the following: -# -# tasks from ./roles/foo/tasks/main.yml, then ./roles/bar/tasks/main.yml -# handlers from ./roles/foo/handlers/main.yml, then ./roles/bar/handlers/main.yml -# vars from ./roles/foo/vars/main.yml, then ./roles/bar/vars/main.yml -# -# should any of these files not exist, that is ok, and they will simply not be loaded. -# -# should the task file in foo/tasks/main.yml want to include subtasks in other files, that -# is also permitted. -# -# templates and copy operations also get smarter about where to look for content when using -# roles. -# -# as an example, a task in foo/tasks/main.yml could copy or template a file by -# referencing a "src=foo.j2" rather than having to explicitly path src=roles/foo/templates/foo.j2. - ---- - - - hosts: all - - pre_tasks: - - # these tasks are executed prior to roles. - # this might be a good time to signal an outage window or take a host out of a load balanced pool - - - local_action: shell echo "hi this is a pre_task step about {{ inventory_hostname }}" - - roles: - - # a role can be listed flat like this: - # - # - common - # - webservers - - # but you can also pass variables to them, so they can be parameterized. You can call - # a role more than once with different parameters too. It might look like the section - # below. Note I can also declare tags at this time. - - - { role: foo, param1: 1000, param2: 2000, tags: [ 'foo', 'bar' ] } - - { role: foo, param1: 8000, param2: 9000, tags: [ 'baz' ] } - - # add as many roles as you like, roles takes a list of roles names - # these paths can be qualified, but if bare, it will look from them in - # roles/{{rolename}} relative to the playbook - - # explicit tasks and handlers can be used, but are not required. - # they will run after the roles if present. - - tasks: - - # you can still have loose tasks/handlers and they will execute after roles are applied - - - shell: echo 'this is a loose task' - - post_tasks: - - # just to provide a syntactic mirroring to 'pre_tasks', these run absolute last in the play. - # this might be a good time to put a host back in a load balanced pool or end an outage window - - - local_action: shell echo 'this is a post_task about {{ inventory_hostname }}' - - - diff --git a/examples/playbooks/roletest2.yml b/examples/playbooks/roletest2.yml deleted file mode 100644 index 29be1b55102..00000000000 --- a/examples/playbooks/roletest2.yml +++ /dev/null @@ -1,57 +0,0 @@ -# in Ansible 1.2 and later, roles allow easy best-practices organization of content -# and maximize shareability of ansible building blocks. -# -# suppose a playbook applied to a group of hosts includes two roles, foo and bar. -# -# what do roles do in this case? -# -# listing the roles as foo and bar will auto include the following: -# -# tasks from ./roles/foo/tasks/main.yml, then ./roles/bar/tasks/main.yml -# handlers from ./roles/foo/handlers/main.yml, then ./roles/bar/handlers/main.yml -# vars from ./roles/foo/vars/main.yml, then ./roles/bar/vars/main.yml -# -# should any of these files not exist, that is ok, and they will simply not be loaded. -# -# should the task file in foo/tasks/main.yml want to include subtasks in other files, that -# is also permitted. -# -# templates and copy operations also get smarter about where to look for content when using -# roles. -# -# as an example, a task in foo/tasks/main.yml could copy or template a file by -# referencing a "src=foo.j2" rather than having to explicitly path src=roles/foo/templates/foo.j2. - ---- - - - hosts: all - roles: - - # a role can be listed flat like this: - # - # - common - # - webservers - - # but you can also pass variables to them, so they can be parameterized. You can call - # a role more than once with different parameters too. It might look like this: - - - role: foo - param1: '{{ item }}' - param2: '{{ item + "/" + item }}' - with_items: ['a','b','c'] - when: ansible_os_family == 'RedHat' - - # add as many roles as you like, roles takes a list of roles names - # these paths can be qualified, but if bare, it will look from them in - # roles/{{rolename}} relative to the playbook - - # explicit tasks and handlers can be used, but are not required. - # they will run after the roles if present. - - tasks: - - # you can still have loose tasks/handlers and they will execute after roles - - - shell: echo 'this is a loose task' - - diff --git a/examples/playbooks/selective_file_sources.yml b/examples/playbooks/selective_file_sources.yml deleted file mode 100644 index f31be1019d6..00000000000 --- a/examples/playbooks/selective_file_sources.yml +++ /dev/null @@ -1,28 +0,0 @@ ---- -# this is an example of how to template a file over using some variables derived -# from the system. For instance, if you wanted to have different configuration -# templates by OS version, this is a neat way to do it. Any Ansible facts, facter facts, -# or ohai facts could be used to do this. - -- hosts: all - - tasks: - - - name: template a config file - action: template dest=/etc/imaginary_file.conf - first_available_file: - - # first see if we have a file for this specific host - - /srv/whatever/{{ansible_hostname}}.conf - - # next try to load something like CentOS6.2.conf - - /srv/whatever/{{ansible_distribution}}{{ansible_distribution_version}}.conf - - # next see if there's a CentOS.conf - - /srv/whatever/{{ansible_distribution}}.conf - - # finally give up and just use something generic - - /srv/whatever/default - - - diff --git a/examples/playbooks/tags.yml b/examples/playbooks/tags.yml deleted file mode 100644 index 797d5a532a4..00000000000 --- a/examples/playbooks/tags.yml +++ /dev/null @@ -1,44 +0,0 @@ ---- -# tags allow us to run all of a playbook or part of it. -# -# assume: ansible-playbook tags.yml --tags foo -# -# try this with: -# --tags foo -# --tags bar -# --tags extra -# -# the value of a 'tags:' element can be a string or list -# of tag names. Variables are not usable in tag names. - -- name: example play one - hosts: all - user: root - - # any tags applied to the play are shorthand to applying - # the tag to all tasks in it. Here, each task is given - # the tag extra - - tags: - - extra - - tasks: - - # this task will run if you don't specify any tags, - # if you specify 'foo' or if you specify 'extra' - - - name: hi - tags: foo - action: shell echo "first task ran" - -- name: example play two - hosts: all - user: root - tasks: - - name: hi - tags: - - bar - action: shell echo "second task ran" - - include: tasks/base.yml tags=base - - diff --git a/examples/playbooks/tasks/base.yml b/examples/playbooks/tasks/base.yml deleted file mode 100644 index 1232d9f87ec..00000000000 --- a/examples/playbooks/tasks/base.yml +++ /dev/null @@ -1,21 +0,0 @@ ---- - -# this is the example of an included tasks file. It contains a flat list of tasks -# they can notify other tasks, and have full access to variables from 'vars' -# or 'vars_files' directives. Further, if ohai or facter were installed on -# the remote machines, variables from those tools can be accessed on the 'action' -# line or in templates. Just prefix with 'facter_' or 'ohai_' before the particular -# variable. - -# possible uses for a included yaml file might be to represent a 'class' of a system -# like defining what makes up a webserver, or you might have a common 'base.yml' -# (like this) that might be applied to all your systems as well. - -- name: no selinux - action: command /usr/sbin/setenforce 0 - -- name: no iptables - action: service name=iptables state=stopped - -- name: made up task just to show variables work here - action: command /bin/echo release is $release diff --git a/examples/playbooks/templates/custom-filters.j2 b/examples/playbooks/templates/custom-filters.j2 deleted file mode 100644 index 08126f958a4..00000000000 --- a/examples/playbooks/templates/custom-filters.j2 +++ /dev/null @@ -1 +0,0 @@ -1 + 1 = {{ '1+1' | generate_answer }} diff --git a/examples/playbooks/templates/etc_cron.d_ansible-pull.j2 b/examples/playbooks/templates/etc_cron.d_ansible-pull.j2 deleted file mode 100644 index 99f7339120c..00000000000 --- a/examples/playbooks/templates/etc_cron.d_ansible-pull.j2 +++ /dev/null @@ -1,2 +0,0 @@ -# Cron job to git clone/pull a repo and then run locally -{{ schedule }} {{ cron_user }} ansible-pull -d {{ workdir }} -U {{ repo_url }} >>{{ logfile }} 2>&1 diff --git a/examples/playbooks/templates/etc_logrotate.d_ansible-pull.j2 b/examples/playbooks/templates/etc_logrotate.d_ansible-pull.j2 deleted file mode 100644 index e396f31a4e5..00000000000 --- a/examples/playbooks/templates/etc_logrotate.d_ansible-pull.j2 +++ /dev/null @@ -1,7 +0,0 @@ -{{ logfile }} { - rotate 7 - daily - compress - missingok - notifempty -} diff --git a/examples/playbooks/templates/foo.j2 b/examples/playbooks/templates/foo.j2 deleted file mode 100644 index 8ebc7736db9..00000000000 --- a/examples/playbooks/templates/foo.j2 +++ /dev/null @@ -1,10 +0,0 @@ -# This is a very simple Jinja2 template representing an imaginary configuration file -# for an imaginary app. - -# this is an example of loading a fact from the setup module -system={{ ansible_system }} - -# here is a variable that could be set in a playbook or inventory file -http_port={{ http_port }} - - diff --git a/examples/playbooks/templates/hostvars.j2 b/examples/playbooks/templates/hostvars.j2 deleted file mode 100644 index ca8f51482ad..00000000000 --- a/examples/playbooks/templates/hostvars.j2 +++ /dev/null @@ -1,7 +0,0 @@ -# example of how to get the ipaddress of every machine in the webservers group -# for use in a template - -{% for host in groups['webservers'] %} - HOST: {{ host }} IP: {{ hostvars[host]['ansible_all_ipv4_addresses'][0] }} -{% endfor %} - diff --git a/examples/playbooks/upgraded_vars.yml b/examples/playbooks/upgraded_vars.yml deleted file mode 100644 index fdbf5795320..00000000000 --- a/examples/playbooks/upgraded_vars.yml +++ /dev/null @@ -1,30 +0,0 @@ -# this just shows some tricks possible with variables in Ansible 1.2 and later. - ---- - - - hosts: all - - vars: - a_list: - - a - - b - - c - - tasks: - - shell: echo hello {{ ansible_hostname.upper() }} - - - shell: echo match - when: 2 == 2 - - - shell: echo no match - when: 2 == 2 + 1 - - - shell: echo {{ ansible_os_family }} - - - shell: echo {{ item }} - with_items: a_list - - - shell: echo 'RedHat' - when: ansible_os_family == 'RedHat' - - diff --git a/examples/playbooks/user_commands.yml b/examples/playbooks/user_commands.yml deleted file mode 100644 index 2d5a792eb3a..00000000000 --- a/examples/playbooks/user_commands.yml +++ /dev/null @@ -1,38 +0,0 @@ ---- -# this is a demo of how the user commands work and how to reference salted passwords -# in vars sections. You could also use vars_files if you like (see other examples) - -- hosts: all - user: root - vars: - # created with: - # python -c 'import crypt; print crypt.crypt("This is my Password", "$1$SomeSalt$")' - password: $1$SomeSalt$UqddPX3r4kH3UL5jq5/ZI. - - tasks: - - # Walk through account creation, modification, and deletion - - name: test basic user account creation - action: user name=tset comment=TsetUser group=users shell=/sbin/nologin createhome=no - - # the following is just a simple example of how you don't have to include - # the 'name' element for each task - - - action: user name=tset comment=NyetUser - - action: user name=tset password={{password}} - - # The following will add the user to supplementary groups. - - # Add the user to the groups dialout and uucp. - - action: user name=tset groups=dialout,uucp - - # Add the user to the groups dialout and wheel, - # This will remove tset from the group uucp. - - action: user name=tset groups=dialout,wheel - - # Add the user to the group uucp. Because append=yes, the user - # will not be removed from the groups dialout and wheel. - - action: user name=tset groups=uucp append=yes - - # Finally, remove the user. - - action: user name=tset state=absent diff --git a/examples/playbooks/vars/CentOS.yml b/examples/playbooks/vars/CentOS.yml deleted file mode 100644 index b75cf94e8a8..00000000000 --- a/examples/playbooks/vars/CentOS.yml +++ /dev/null @@ -1,3 +0,0 @@ ---- -apache: httpd -packager: yum diff --git a/examples/playbooks/vars/defaults.yml b/examples/playbooks/vars/defaults.yml deleted file mode 100644 index 3a04c435bd1..00000000000 --- a/examples/playbooks/vars/defaults.yml +++ /dev/null @@ -1,3 +0,0 @@ ---- -packager: apt -apache: apache diff --git a/examples/playbooks/vars/external_vars.yml b/examples/playbooks/vars/external_vars.yml deleted file mode 100644 index ebc76961bf5..00000000000 --- a/examples/playbooks/vars/external_vars.yml +++ /dev/null @@ -1,3 +0,0 @@ ---- -alpha: one -beta: two diff --git a/examples/playbooks/zfs.yml b/examples/playbooks/zfs.yml deleted file mode 100644 index 0e0282ee9b7..00000000000 --- a/examples/playbooks/zfs.yml +++ /dev/null @@ -1,33 +0,0 @@ ---- -## -# Example Ansible playbook that uses the Zfs module. -# - -- hosts: webservers - gather_facts: no - sudo: yes - - vars: - pool: rpool - - tasks: - - - name: Create a zfs file system - action: zfs name={{pool}}/var/log/httpd state=present - - - name: Create a zfs file system with quota of 10GiB and visible snapdir - action: zfs name={{pool}}/ansible quota='10G' snapdir=visible state=present - - - name: Crate zfs snapshot of the above file system - action: zfs name={{pool}}/ansible@mysnapshot state=present - - - name: Create zfs volume named smallvol with a size of 10MiB - action: zfs name={{pool}}/smallvol volsize=10M state=present - - - name: Removes snapshot of rpool/oldfs - action: zfs name={{pool}}/oldfs@oldsnapshot state=absent - - - name: Removes file system rpool/oldfs - action: zfs name={{pool}}/oldfs state=absent - -