├── .gitignore ├── Day-01 ├── 01-introduction.md └── 02-shell-vs-ansible.md ├── Day-02 ├── 01-passwordless-authentication.md └── 02-inventory.md ├── Day-03 ├── 01-yaml-basics.md ├── 02-ansible-playbook-components.md └── 03-first-playbook │ ├── first-playbook.yaml │ └── index.html ├── Day-04 └── 01-roles.md ├── Day-05 └── 01-push-role-to-galaxy.md ├── Day-06 ├── 01-prereq.md └── 02-playbook.yaml ├── Day-07 ├── README.md ├── ec2_create.yaml └── ec2_shutdown.yaml ├── Day-08 ├── 01-error-handling.yaml └── inventory.ini ├── Day-10 ├── 01-install-and-setup.md ├── 02-playbook.yaml └── README.md ├── LICENSE └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | # If you prefer the allow list template instead of the deny list, see community template: 2 | # https://github.com/github/gitignore/blob/main/community/Golang/Go.AllowList.gitignore 3 | # 4 | # Binaries for programs and plugins 5 | *.exe 6 | *.exe~ 7 | *.dll 8 | *.so 9 | *.dylib 10 | 11 | # Test binary, built with `go test -c` 12 | *.test 13 | 14 | # Output of the go coverage tool, specifically when used with LiteIDE 15 | *.out 16 | 17 | # Dependency directories (remove the comment below to include it) 18 | # vendor/ 19 | 20 | # Go workspace file 21 | go.work 22 | -------------------------------------------------------------------------------- /Day-01/01-introduction.md: -------------------------------------------------------------------------------- 1 | # Introduction to Ansible 2 | 3 | ## What is Ansible ? 4 | 5 | Ansible is an open source IT automation engine that automates 6 | - provisioning 7 | - configuration management 8 | - application deployment 9 | - orchestration 10 | 11 | and many other IT processes. It is free to use, and the project benefits from the experience and intelligence of its thousands of contributors. 12 | 13 | ## How Ansible works ? 14 | 15 | Ansible is agentless in nature, which means you don't need install any software on the manage nodes. 16 | 17 | For automating Linux and Windows, Ansible connects to managed nodes and pushes out small programs—called Ansible modules—to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished. These modules are designed to be idempotent when possible, so that they only make changes to a system when necessary. 18 | 19 | For automating network devices and other IT appliances where modules cannot be executed, Ansible runs on the control node. Since Ansible is agentless, it can still communicate with devices without requiring an application or service to be installed on the managed node. 20 | 21 | 22 | 23 | -------------------------------------------------------------------------------- /Day-01/02-shell-vs-ansible.md: -------------------------------------------------------------------------------- 1 | # Comparison with Shell Scripting 2 | 3 | - Shell Scripting works only for Linux. 4 | 5 | - Becomes complex and less readable(for non-experts) as the script size goes high. 6 | 7 | - Idempotence and predictability 8 | 9 | When the system is in the state your playbook describes Ansible does not change anything, even if the playbook runs multiple times. 10 | 11 | for example, run the below shell script twice and you will notice the script will fail. Which means shell scripting is not idempotent in nature. 12 | 13 | ``` 14 | #/bin/bash 15 | 16 | set -e 17 | 18 | mkdir test-demo 19 | echo "hi" 20 | ``` 21 | 22 | - Scalability and flexibility 23 | 24 | Easily and quickly scale the systems you automate through a modular design that supports a large range of operating systems, cloud platforms, and network devices. 25 | 26 | -------------------------------------------------------------------------------- /Day-02/01-passwordless-authentication.md: -------------------------------------------------------------------------------- 1 | # How to setup Passwordless Authentication 2 | 3 | ## EC2 Instances 4 | 5 | ### Using Public Key 6 | 7 | ``` 8 | ssh-copy-id -f "-o IdentityFile " ubuntu@ 9 | ``` 10 | 11 | - ssh-copy-id: This is the command used to copy your public key to a remote machine. 12 | - -f: This flag forces the copying of keys, which can be useful if you have keys already set up and want to overwrite them. 13 | - "-o IdentityFile ": This option specifies the identity file (private key) to use for the connection. The -o flag passes this option to the underlying ssh command. 14 | - ubuntu@: This is the username (ubuntu) and the IP address of the remote server you want to access. 15 | 16 | ### Using Password 17 | 18 | - Go to the file `/etc/ssh/sshd_config.d/60-cloudimg-settings.conf` 19 | - Update `PasswordAuthentication yes` 20 | - Restart SSH -> `sudo systemctl restart ssh` 21 | 22 | -------------------------------------------------------------------------------- /Day-02/02-inventory.md: -------------------------------------------------------------------------------- 1 | # Inventory 2 | 3 | Ansible inventory file is a fundamental component of Ansible that defines the hosts (remote systems) that you want to manage and the groups those hosts belong to. The inventory file can be static (a simple text file) or dynamic (generated by a script). It provides Ansible with the information about the remote nodes to communicate with during its operations. 4 | 5 | ## Static Inventory 6 | 7 | A static inventory file is typically a plain text file (usually named hosts or inventory) and is structured in INI or YAML format. Here are examples of both formats: 8 | 9 | ### INI Format 10 | 11 | ``` 12 | # inventory file: hosts 13 | 14 | [webservers] 15 | web1.example.com 16 | web2.example.com 17 | 18 | [dbservers] 19 | db1.example.com 20 | db2.example.com 21 | 22 | [all:vars] 23 | ansible_user=admin 24 | ansible_ssh_private_key_file=/path/to/key 25 | ``` 26 | 27 | ### YAML 28 | 29 | ``` 30 | # inventory file: hosts.yaml 31 | 32 | all: 33 | vars: 34 | ansible_user: admin 35 | ansible_ssh_private_key_file: /path/to/key 36 | children: 37 | webservers: 38 | hosts: 39 | web1.example.com: 40 | web2.example.com: 41 | dbservers: 42 | hosts: 43 | db1.example.com: 44 | db2.example.com: 45 | ``` 46 | 47 | ## Dynamic Inventory 48 | 49 | A dynamic inventory is generated by a script or plugin and can be used for environments where hosts are constantly changing (e.g., cloud environments). The script or plugin fetches the list of hosts from a source like AWS, GCP, or any other dynamic source. 50 | 51 | Here is an example of a dynamic inventory script for AWS EC2: 52 | 53 | ``` 54 | #!/usr/bin/env python 55 | 56 | import json 57 | import boto3 58 | 59 | def get_aws_ec2_inventory(): 60 | ec2 = boto3.client('ec2') 61 | instances = ec2.describe_instances() 62 | inventory = { 63 | 'all': { 64 | 'hosts': [], 65 | 'vars': { 66 | 'ansible_user': 'ec2-user', 67 | 'ansible_ssh_private_key_file': '/path/to/key' 68 | } 69 | }, 70 | '_meta': { 71 | 'hostvars': {} 72 | } 73 | } 74 | 75 | for reservation in instances['Reservations']: 76 | for instance in reservation['Instances']: 77 | if instance['State']['Name'] == 'running': 78 | public_ip = instance['PublicIpAddress'] 79 | inventory['all']['hosts'].append(public_ip) 80 | inventory['_meta']['hostvars'][public_ip] = { 81 | 'ansible_host': public_ip 82 | } 83 | 84 | print(json.dumps(inventory, indent=2)) 85 | 86 | if __name__ == '__main__': 87 | get_aws_ec2_inventory() 88 | ``` 89 | 90 | ## Usage 91 | 92 | ``` 93 | ansible-playbook -i inventory 94 | ``` -------------------------------------------------------------------------------- /Day-03/01-yaml-basics.md: -------------------------------------------------------------------------------- 1 | # Understanding YAML 2 | 3 | YAML (YAML Ain't Markup Language) is a human-readable data serialization format that is commonly used for configuration files and data exchange between languages with different data structures. 4 | 5 | ## YAML Syntax 6 | 7 | ### Strings, Numbers and Booleans: 8 | 9 | ``` 10 | string: Hello, World! 11 | number: 42 12 | boolean: true 13 | ``` 14 | 15 | ### List 16 | 17 | ``` 18 | fruits: 19 | - Apple 20 | - Orange 21 | - Banana 22 | ``` 23 | 24 | ### Dictionary 25 | 26 | ``` 27 | person: 28 | name: John Doe 29 | age: 30 30 | city: New York 31 | ``` 32 | 33 | ### List of dictionaries 34 | 35 | YAML allows nesting of lists and dictionaries to represent more complex data. 36 | 37 | ``` 38 | family: 39 | parents: 40 | - name: Jane 41 | age: 50 42 | - name: John 43 | age: 52 44 | children: 45 | - name: Jimmy 46 | age: 22 47 | - name: Jenny 48 | age: 20 49 | ``` 50 | -------------------------------------------------------------------------------- /Day-03/02-ansible-playbook-components.md: -------------------------------------------------------------------------------- 1 | # Ansible Concepts: Playbook, Play, Modules, Tasks, and Collections 2 | 3 | ## Playbook 4 | A **Playbook** is a YAML file that defines a series of actions to be executed on managed nodes. It contains one or more "plays" that map groups of hosts to roles. 5 | 6 | ### Example 7 | ``` 8 | --- 9 | - name: Update web servers 10 | hosts: webservers 11 | remote_user: root 12 | 13 | tasks: 14 | - name: Ensure apache is at the latest version 15 | ansible.builtin.yum: 16 | name: httpd 17 | state: latest 18 | 19 | - name: Write the apache config file 20 | ansible.builtin.template: 21 | src: /srv/httpd.j2 22 | dest: /etc/httpd.conf 23 | 24 | - name: Update db servers 25 | hosts: databases 26 | remote_user: root 27 | 28 | tasks: 29 | - name: Ensure postgresql is at the latest version 30 | ansible.builtin.yum: 31 | name: postgresql 32 | state: latest 33 | 34 | - name: Ensure that postgresql is started 35 | ansible.builtin.service: 36 | name: postgresql 37 | state: started 38 | ``` 39 | 40 | ## Play 41 | 42 | A Play is a single, complete execution unit within a playbook. It specifies which hosts to target and what tasks to execute on those hosts. Plays are used to group related tasks and execute them in a specific order. 43 | 44 | ``` 45 | - name: Install and configure Nginx 46 | hosts: webservers 47 | tasks: 48 | - name: Install Nginx 49 | apt: 50 | name: nginx 51 | state: present 52 | ``` 53 | 54 | ## Modules 55 | 56 | Modules are the building blocks of Ansible tasks. They are small programs that perform a specific action on a managed node, such as installing a package, copying a file, or managing services. 57 | Example 58 | 59 | The apt module used in a task to install a package: 60 | 61 | ``` 62 | - name: Install Nginx 63 | apt: 64 | name: nginx 65 | state: present 66 | ``` 67 | 68 | ## Tasks 69 | 70 | Tasks are individual actions within a play that use modules to perform operations on managed nodes. Each task is executed in order and can include conditionals, loops, and handlers. 71 | 72 | ``` 73 | - name: Install Nginx 74 | apt: 75 | name: nginx 76 | state: present 77 | 78 | - name: Start Nginx service 79 | service: 80 | name: nginx 81 | state: started 82 | ``` 83 | 84 | ## Collections 85 | 86 | Collections are a distribution format for Ansible content. They bundle together multiple roles, modules, plugins, and other Ansible artifacts. Collections make it easier to share and reuse Ansible content. 87 | Example 88 | 89 | A collection structure might look like this: 90 | 91 | ``` 92 | my_collection/ 93 | ├── roles/ 94 | │ └── my_role/ 95 | │ └── tasks/ 96 | │ └── main.yml 97 | ├── plugins/ 98 | │ └── modules/ 99 | │ └── my_module.py 100 | └── README.md 101 | ``` 102 | 103 | ### Using a Collection 104 | 105 | ``` 106 | - name: Use a custom module from a collection 107 | community.general.my_module: 108 | option: value 109 | ``` -------------------------------------------------------------------------------- /Day-03/03-first-playbook/first-playbook.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - hosts: all 3 | become: true 4 | tasks: 5 | - name: Install apache httpd 6 | ansible.builtin.apt: 7 | name: apache2 8 | state: present 9 | update_cache: yes 10 | - name: Copy file with owner and permissions 11 | ansible.builtin.copy: 12 | src: index.html 13 | dest: /var/www/html 14 | owner: root 15 | group: root 16 | mode: '0644' -------------------------------------------------------------------------------- /Day-03/03-first-playbook/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Sample Index Page 7 | 34 | 35 | 36 |
37 |

I am learning Ansible with Abhishek Veeramalla

38 |
39 |
40 |

Ansible Zero to Hero Series

41 |

This is my First Ansible Playbook, Where I learnt how to deploy a static app on ec2 instance using Ansible.

42 |

For more information, visit www.youtube.com/abhishekveeramalla

43 |
44 |
45 |

© 2024 Abhishek.Veeramalla

46 |
47 | 48 | -------------------------------------------------------------------------------- /Day-04/01-roles.md: -------------------------------------------------------------------------------- 1 | # Ansible Roles 2 | 3 | An Ansible role is a reusable, self-contained unit of automation that is used to 4 | organize and manage tasks, variables, files, templates, and handlers in a structured way. 5 | 6 | Roles help to encapsulate and modularize the logic and configuration needed to manage 7 | a particular system or application component. 8 | 9 | This modular approach promotes reusability, maintainability, and consistency across different 10 | playbooks and environments. 11 | 12 | ## Key Components of an Ansible Role 13 | 14 | ### Tasks 15 | The main list of actions that the role performs. 16 | 17 | ### Handlers 18 | Tasks that are triggered by changes in other tasks, typically used for actions like restarting services. 19 | 20 | ### Files 21 | Static files that need to be transferred to managed hosts. 22 | 23 | ### Templates 24 | Jinja2 templates that can be rendered and transferred to managed hosts. 25 | 26 | ### Vars 27 | Variables that are used within the role. 28 | 29 | ### Defaults 30 | Default variables for the role, which can be overridden. 31 | 32 | ### Meta 33 | Metadata about the role, including dependencies on other roles. 34 | 35 | ### Library 36 | Custom modules or plugins used within the role. 37 | 38 | ### Module_defaults 39 | Default module parameters for the role. 40 | 41 | ### Lookup_plugins 42 | Custom lookup plugins for the role. 43 | 44 | ## Directory Structure of an Ansible Role 45 | 46 | An Ansible role follows a specific directory structure: 47 | 48 | ``` 49 | / 50 | ├── defaults/ 51 | │ └── main.yml 52 | ├── files/ 53 | ├── handlers/ 54 | │ └── main.yml 55 | ├── meta/ 56 | │ └── main.yml 57 | ├── tasks/ 58 | │ └── main.yml 59 | ├── templates/ 60 | ├── vars/ 61 | └── main.yml 62 | ``` 63 | 64 | ## Why Use Ansible Roles? 65 | 66 | ### Modularity 67 | Roles allow you to break down complex playbooks into smaller, reusable components. 68 | Each role handles a specific part of the configuration or setup. 69 | 70 | ### Reusability 71 | Once created, roles can be reused across different playbooks and projects. This saves time 72 | and effort in writing redundant code. 73 | 74 | ### Maintainability 75 | By organizing related tasks into roles, it becomes easier to manage and maintain the code. 76 | Changes can be made in one place and applied consistently wherever the role is used. 77 | 78 | ### Readability 79 | Roles make playbooks cleaner and easier to read by abstracting away the details into logically 80 | named roles. 81 | 82 | ### Collaboration 83 | Roles facilitate collaboration among team members by allowing them to work on different parts 84 | of the infrastructure independently. 85 | 86 | ### Consistency 87 | Using roles ensures that the same setup and configuration procedures are applied uniformly across 88 | multiple environments, reducing the risk of configuration drift. -------------------------------------------------------------------------------- /Day-05/01-push-role-to-galaxy.md: -------------------------------------------------------------------------------- 1 | # Push your Ansible roles to Ansible Galaxy 2 | 3 | 1. Make sure your role is structured correctly. The basic structure should look like this: 4 | 5 | ``` 6 | my_role/ 7 | ├── defaults/ 8 | │ └── main.yml 9 | ├── files/ 10 | ├── handlers/ 11 | │ └── main.yml 12 | ├── meta/ 13 | │ └── main.yml 14 | ├── tasks/ 15 | │ └── main.yml 16 | ├── templates/ 17 | ├── tests/ 18 | │ ├── inventory 19 | │ └── test.yml 20 | └── vars/ 21 | └── main.yml 22 | ``` 23 | 24 | 2. Make sure ansible-galaxy CLI exists 25 | 26 | ``` 27 | ansible-galaxy --version 28 | ``` 29 | 30 | 3. Push Your Role to GitHub 31 | 32 | ``` 33 | cd 34 | git init 35 | git remote add origin 36 | git add . 37 | git commit -m "Initial commit" 38 | git push -u origin main 39 | ``` 40 | 41 | 4. Import the Role to Ansible Galaxy 42 | 43 | ``` 44 | ansible-galaxy role import 45 | ``` 46 | -------------------------------------------------------------------------------- /Day-06/01-prereq.md: -------------------------------------------------------------------------------- 1 | # Setup EC2 Collection and Authentication 2 | 3 | ## Install boto3 4 | 5 | ``` 6 | pip install boto3 7 | ``` 8 | 9 | ## Install AWS Collection 10 | 11 | ``` 12 | ansible-galaxy collection install amazon.aws 13 | ``` 14 | 15 | ## Setup Vault 16 | 17 | 1. Create a password for vault 18 | 19 | ``` 20 | openssl rand -base64 2048 > vault.pass 21 | ``` 22 | 23 | 2. Add your AWS credentials using the below vault command 24 | 25 | ``` 26 | ansible-vault create group_vars/all/pass.yml --vault-password-file vault.pass 27 | ``` 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /Day-06/02-playbook.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - hosts: localhost 3 | connection: local 4 | tasks: 5 | - name: start an instance with a public IP address 6 | amazon.aws.ec2_instance: 7 | name: "ansible-instance" 8 | # key_name: "prod-ssh-key" 9 | # vpc_subnet_id: subnet-013744e41e8088axx 10 | instance_type: t2.micro 11 | security_group: default 12 | region: us-east-1 13 | aws_access_key: "{{ec2_access_key}}" # From vault as defined 14 | aws_secret_key: "{{ec2_secret_key}}" # From vault as defined 15 | network: 16 | assign_public_ip: true 17 | image_id: ami-04b70fa74e45c3917 18 | tags: 19 | Environment: Testing -------------------------------------------------------------------------------- /Day-07/README.md: -------------------------------------------------------------------------------- 1 | # Ansible Realtime project 2 | 3 | ## Task 1 4 | 5 | Create three(3) EC2 instances on AWS using Ansible loops 6 | - 2 Instances with Ubuntu Distribution 7 | - 1 Instance with Centos Distribution 8 | 9 | Hint: Use `connection: local` on Ansible Control node. 10 | 11 | ## Task 2 12 | 13 | Set up passwordless authentication between Ansible control node and newly created 14 | instances. 15 | 16 | ## Task 3 17 | 18 | Automate the shutdown of Ubuntu Instances only using Ansible Conditionals 19 | 20 | Hint: Use `when` condition on ansible `gather_facts` 21 | 22 | 23 | 24 | 25 | 26 | 27 | -------------------------------------------------------------------------------- /Day-07/ec2_create.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - hosts: localhost 3 | connection: local 4 | 5 | tasks: 6 | - name: Create EC2 instances 7 | amazon.aws.ec2_instance: 8 | name: "{{ item.name }}" 9 | key_name: "abhi-aws-keypair" 10 | instance_type: t2.micro 11 | security_group: default 12 | region: ap-south-1 13 | aws_access_key: "{{ec2_access_key}}" # From vault as defined 14 | aws_secret_key: "{{ec2_secret_key}}" # From vault as defined 15 | network: 16 | assign_public_ip: true 17 | image_id: "{{ item.image }}" 18 | tags: 19 | environment: "{{ item.name }}" 20 | loop: 21 | - { image: "ami-0e1d06225679bc1c5", name: "manage-node-1" } # Update AMI ID according 22 | - { image: "ami-0f58b397bc5c1f2e8", name: "manage-node-2" } # to your account 23 | - { image: "ami-0f58b397bc5c1f2e8", name: "manage-node-3" } 24 | -------------------------------------------------------------------------------- /Day-07/ec2_shutdown.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - hosts: all 3 | become: true 4 | 5 | tasks: 6 | - name: Shutdown ubuntu instances only 7 | ansible.builtin.command: /sbin/shutdown -t now 8 | when: 9 | ansible_facts['os_family'] == "Debian" -------------------------------------------------------------------------------- /Day-08/01-error-handling.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - hosts: all 3 | become: true 4 | 5 | tasks: 6 | - name: Install security updates 7 | ansible.builtin.apt: 8 | name: "{{ item }}" 9 | state: latest 10 | loop: 11 | - openssl 12 | - openssh 13 | ignore_errors: yes 14 | - name: Check if docker is installed 15 | ansible.builtin.command: docker --version 16 | register: output 17 | ignore_errors: yes 18 | - ansible.builtin.debug: 19 | var: output 20 | - name: Install docker 21 | ansible.builtin.apt: 22 | name: docker.io 23 | state: present 24 | when: output.failed 25 | -------------------------------------------------------------------------------- /Day-08/inventory.ini: -------------------------------------------------------------------------------- 1 | # Add your hosts(managed nodes) to this file -------------------------------------------------------------------------------- /Day-10/01-install-and-setup.md: -------------------------------------------------------------------------------- 1 | # Install and Setup Ansible for Implementing Policy as Code on AWS 2 | 3 | ## Install boto3 4 | 5 | ``` 6 | pip install boto3 7 | ``` 8 | 9 | ## Install AWS Collection 10 | 11 | ``` 12 | ansible-galaxy collection install amazon.aws 13 | ``` 14 | 15 | ## Setup Vault 16 | 17 | 1. Create a password for vault 18 | 19 | ``` 20 | openssl rand -base64 2048 > vault.pass 21 | ``` 22 | 23 | 2. Add your AWS credentials using the below vault command 24 | 25 | ``` 26 | ansible-vault create group_vars/all/pass.yml --vault-password-file vault.pass 27 | ``` -------------------------------------------------------------------------------- /Day-10/02-playbook.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | - name: Enforce s3 bucket versioning on AWS account 3 | hosts: localhost 4 | gather_facts: false 5 | 6 | tasks: 7 | - name: List S3 buckets in AWS account 8 | amazon.aws.s3_bucket_info: 9 | register: result 10 | 11 | - debug: 12 | var: result 13 | 14 | - name: Enable versioning on S3 bucket 15 | amazon.aws.s3_bucket: 16 | name: "{{ item.name }}" 17 | versioning: yes 18 | loop: "{{ result.buckets }}" 19 | -------------------------------------------------------------------------------- /Day-10/README.md: -------------------------------------------------------------------------------- 1 | # Policy as Code 2 | 3 | Policy as Code (PaC) in DevSecOps refers to the practice of defining and managing security policies through code. This approach enables automated, consistent, and scalable enforcement of security controls and compliance requirements across the software development lifecycle. 4 | 5 | ## Key Concepts of Policy as Code 6 | 7 | ### Codification of Policies 8 | Security policies, compliance requirements, and governance rules are written in code, similar to how infrastructure is defined in Infrastructure as Code (IaC). 9 | Policies are typically defined using declarative languages or scripts. 10 | 11 | ### Automation 12 | Policies are automatically enforced through CI/CD pipelines. 13 | Tools continuously monitor and ensure compliance with the defined policies. 14 | 15 | ### Version Control 16 | Policies as code are stored in version control systems (e.g., Git), allowing for versioning, auditing, and change tracking. 17 | This ensures that any changes to policies are transparent and traceable. 18 | 19 | ### Integration with DevOps Tools 20 | PaC integrates with DevOps tools and platforms, enabling seamless policy enforcement across development, testing, and production environments. 21 | Common integrations include CI/CD tools, configuration management tools, and cloud management platforms. 22 | 23 | ## Benefits of Policy as Code 24 | 25 | ### Consistency and Accuracy 26 | Policies are applied consistently across environments, reducing the risk of human error. 27 | Automated checks and enforcement ensure that policies are adhered to accurately. 28 | 29 | ### Scalability 30 | PaC enables scalable policy enforcement across multiple environments and numerous resources. 31 | It supports the rapid deployment and scaling of applications while maintaining compliance. 32 | 33 | ### Auditability and Transparency 34 | Policies as code provide an auditable trail of policy definitions and changes. 35 | This transparency is crucial for compliance and regulatory requirements. 36 | 37 | ### Shift-Left Security 38 | By integrating security policies early in the development process, PaC promotes the shift-left security approach. 39 | It helps identify and remediate security issues early, reducing the cost and impact of security vulnerabilities. 40 | 41 | ## Example Use Cases 42 | 43 | ### Infrastructure Security: 44 | Ensure that cloud resources (e.g., AWS S3 buckets, IAM roles) comply with security best practices. 45 | Automatically remediate non-compliant resources. 46 | 47 | ### Application Security: 48 | Enforce secure coding practices and compliance checks during the build and deployment stages. 49 | Prevent deployment of applications with known vulnerabilities. 50 | 51 | ### Compliance and Governance: 52 | Implement regulatory compliance requirements (e.g., GDPR, HIPAA) as code. 53 | Continuously monitor and enforce compliance across the organization. -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Ansible Zero to Hero 2 | 3 | Day 1: Introduction to Ansible and Getting Started 4 | 5 | - Overview of Ansible: What is Ansible, its advantages, and why use it? 6 | - Comparison with Shell and Python scripting for automation. 7 | - Installing Ansible on different platforms. 8 | - IDE(VS Code) and Plugin configuration. 9 | 10 | Day 2: Ansible Adhoc Commands 11 | 12 | - Passwordless Authentication 13 | - Ansible Inventory 14 | - Understanding Adhoc commands and their usage. 15 | - Examples of common Adhoc commands for system management tasks. 16 | - Exploring the power of Adhoc commands for quick tasks. 17 | 18 | Day 3: Writing Your First Ansible Playbook 19 | 20 | - Understanding YAML basics and Ansible playbook structure. 21 | - Introduction to Ansible structure: Playbook, Play, Modules, Tasks and Collections. 22 | - Hands-on: Writing a playbook to install apache2 and deploy a static app on aws. 23 | 24 | Day 4: Understanding Ansible Roles 25 | 26 | - What are Ansible roles and why use them? 27 | - Exploring the folder structure of Ansible roles. 28 | - Comparing roles with playbooks and understanding their advantages. 29 | - Hands-on: Creating a simple role and using it in a playbook. 30 | 31 | Day 5: Deep Dive into Ansible Roles with Demo 32 | 33 | - Ansible Galaxy - Exploring pre-built Ansible roles. 34 | - Ansible Galaxy - Importing and Installing roles. 35 | - DEMO: Advanced usage of Ansible roles with a practical example project. 36 | - Best practices for organizing roles and playbook structure. 37 | 38 | Day 6: Ansible Variables and Precedence 39 | 40 | - Create AWS Resources using Ansible (Collections) 41 | - Understanding Ansible variables and their scope with an example 42 | - Jinja2 Templating - Utilizing advanced templating features 43 | - Variable precedence: How Ansible resolves conflicts between different variable sources. 44 | - Hands-on: Using variables in playbooks and roles. 45 | 46 | Day 7: Ansible Conditionals and Loops 47 | 48 | - Using conditionals in Ansible to control task execution. 49 | - Implementing loops for repetitive tasks. 50 | - Practical examples of conditionals and loops in playbooks. 51 | 52 | Day 8: Error Handling in Ansible 53 | 54 | - Dealing with errors and failures in Ansible playbooks. 55 | - Error handling techniques and best practices. 56 | - Demonstrating error handling in practical scenarios. 57 | 58 | Day 9: Ansible Vault for Security 59 | 60 | - Understanding Ansible Vault and its role in securing sensitive data. 61 | - Encrypting and decrypting files using Ansible Vault. 62 | - Best practices for managing secrets and sensitive data in Ansible. 63 | 64 | Day 10: Policy as Code 65 | 66 | Day 11: Network Automation using Ansible 67 | 68 | Day 12: Ansible Tower Deep Dive 69 | 70 | - Understanding Ansible Tower 71 | - Comparision with Ansible command line and adhoc commands 72 | - RBAC and Security with Ansible Tower 73 | 74 | Day 13: Advanced Ansible Project 75 | 76 | - Terraform + Ansible Project 77 | 78 | Day 14: Ansible Interview Questions 79 | --------------------------------------------------------------------------------