#Ping all hosts in inventory
ansible all -i inventory.ini -m ping
# Run module for specific group
ansible web -i inventory.ini -m shell -a "uptime"# Run a Playbook
ansible-playbook -i inventory.ini playbook.yml
Common Modules:
| Modül | İşlev |
|---|---|
| ping | Ping test |
| file | File/directory create, delete, permission |
| copy | Copy file from local to remote |
| template | Jinja2 template path to destination |
| yum/apt | Package install/delete (RHEL/Debian) |
| service | Service start/stop/enable |
| user | User create/delete |
| lineinfile | Add line in file |
| git | Repo Clone/Pull |
| command / shell | Command run (but be careful for privelege) |
20 Tasks For Daily Use
| Görev | Modül + Kısa Açıklama |
|---|---|
| 1. Ping test | ansible all -m ping |
| 2. Create /tmp/testfile | file: path=/tmp/testfile state=touch |
| 3. htop install | apt: name=htop state=present update_cache=yes |
| 4. Servis start | service: name=nginx state=started |
| 5. Add user | user: name=deniz shell=/bin/bash |
| 6. Copy File | copy: src=./dosya.txt dest=/tmp/ |
| 7. Add line in file | lineinfile: path=/etc/sysctl.conf line=”vm.swappiness = 10″ |
| 8. Git repo Clone | git: repo=https://… dest=/opt/code/ |
| 9. Set File Permissions | file: path=/tmp/testfile mode=0644 |
| 10. Run command | shell: echo hello > /tmp/hello.txt |
| 11. Remove a package | yum: name=httpd state=absent |
| 12. Delete a file | file: path=/tmp/oldfile state=absent |
| 13. Add cron job | cron: name=”log temizle” minute=0 hour=1 job=”rm -f /tmp/*.log” |
| 14. Deploy .env file | template: src=env.j2 dest=/app/.env |
| 15. Propogate SSH keys | authorized_key module |
| 16. Mount | mount: path=/mnt state=mounted src=… |
| 17. Firewall Rules | ufw: rule=allow port=22 |
| 18. Restart the System | reboot: |
| 19. Disk Space Control | command: df -h |
| 20. Default Gateway Route | `command: ip route |
Playbook and Inventory Examples
[web]
web1 ansible_host=192.168.10.10 ansible_user=deniz ansible_ssh_pass=parola
[db]
db1 ansible_host=192.168.10.11 ansible_user=deniz ansible_ssh_pass=parolaPlaybook Örneği (playbook.yml):
---
- name: Nginx Installation
hosts: web
become: true
tasks:
- name: Nginx package installation
apt:
name: nginx
state: present
update_cache: yes
- name: Start the nginx service
service:
name: nginx
state: started
Bonus: Test Fast
ansible web -i inventory.ini -m shell -a "hostname && uptime"
Simple Web Server Deploy (Ubuntu )
Amaç:
One or more servers:
- Nginx
- index.html
- Service
- Web page content control
Project Structure:
web-setup/
├── inventory.ini
├── playbook.yml
├── files/
│ └── index.htmlinventory.ini
[web]
web1 ansible_host=192.168.10.10 ansible_user=ubuntu ansible_ssh_pass=Par0la!
Sample
<!DOCTYPE html>
<html>
<head><title>Welcome</title></head>
<body>
<h1>Welcome to Ansible Web Server!</h1>
</body>
</html>playbook.yml
---
- name: Setup Nginx web server and deploy static site
hosts: web
become: true
tasks:
- name: Update apt cache
apt:
update_cache: yes
- name: Install nginx
apt:
name: nginx
state: present
- name: Copy custom index.html
copy:
src: files/index.html
dest: /var/www/html/index.html
owner: www-data
group: www-data
mode: '0644'
- name: Ensure nginx is started and enabled
service:
name: nginx
state: started
enabled: yes
- name: Check if index page is served
uri:
url: http://localhost
return_content: yes
register: webpage
- name: Debug response
debug:
msg: "{{ webpage.content | truncate(80) }}"
Run
cd web-setup/
ansible-playbook -i inventory.ini playbook.yml
Ansible Galaxy: The Open-Source Role Repository for Automation
It contains thousands of ready-to-use Ansible ROLES written by system administrators, DevOps engineers, and community contributors.
With these roles, you can easily automate tasks such as:
- Web Server
- Docker
- PostgreSQL MongoDB
For example, let’s say we want to install Nginx on an Ubuntu-based server. Instead of configuring everything manually, we can use a community-tested Ansible role that saves time and ensures reliability.
Role Download:
geerlingguy.nginx
ansible-galaxy install geerlingguy.nginx
This Command ,installs related role to $HOME/.ansible/roles/ directory
Create project structure
mkdir -p galaxy-demo && cd galaxy-demo
touch inventory.ini playbook.yml
inventory.ini
[web]
web1 ansible_host=192.168.10.10 ansible_user=ubuntu ansible_ssh_pass=Par0la!If you use ssh pricate key file , update as ansible_ssh_private_key_file
Playbook: Call Galaxy Role
# playbook.yml
---
- name: Install NGINX using Ansible Galaxy role
hosts: web
become: true
roles:
- geerlingguy.nginx
Run playbook:
ansible-playbook -i inventory.ini playbook.yml
Why you should Use Ansible Galaxy?
| Avantaj | Açıklama |
|---|---|
| 🔁 Reusable | You do not need to declare everytime |
| ⏱Time advantage | One line for 20 something task |
| ✅ Tested Structure | Tested by authors and groups |
| 🧩 High modularity | in cloud infrastructure makes scaling and maintenance more efficient. |
Ansible AWX: The Open-Source Version of Ansible Tower:
Ansible AWX is the open-source edition of Red Hat Ansible Tower.
It provides a modern web interface, a powerful REST API, role-based access control (RBAC), scheduled tasks, and much more.
In short, AWX is the management panel that brings Ansible to the enterprise level.
Requirements for Ansible AWX
AWX is now fully container-based and can be installed using Kubernetes or Docker Compose.
Minimum Requirements::
Git, Python3, make, ansible commands
2 vCPU / 4 GB RAM (sufficient for demo environments)
Docker (or Podman)
Docker Compose
Installation Steps on Kubernetes
A running Kubernetes cluster is required
Cloud options: Amazon EKS, Azure AKS, Google GKE
Installing the AWX Operator
git clone https://github.com/ansible/awx-operator.git
cd awx-operator
export NAMESPACE=awx
make deploy
AWX Custom Resource (CR)
In Kubernetes, the AWX Custom Resource (CR) defines the configuration for deploying and managing an AWX instance.
It allows you to specify important settings such as:
Name and namespace
Ingress and service type
Admin credentials
Persistent storage
Resource limits (CPU / RAM)
With the AWX CR, you can fully customize how your AWX deployment behaves inside the Kubernetes cluster, ensuring flexibility and scalability for production environments.
# awx.yml
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx
spec:
service_type: LoadBalancer # NodePort Or ClusterIP
ingress_type: none
hostname: awx.example.com # , For Ingress
admin_user: admin
admin_password_secret: awx-admin-password
postgres_storage_class: nfs-clientCreate neccessary Secret :
kubectl create secret generic awx-admin-password \
--from-literal=password='StrongPa$$w0rd!' -n awx
WX CR’yi Apply
kubectl apply -f awx.yml -n awx
Accessing AWX After Installation
kubectl get svc -n awx
If the service type is LoadBalancer, you can access AWX directly through its IP address.
Otherwise, you need to create an Ingress definition for external access.
Post-Installation Steps
After deploying AWX, it’s recommended to complete the following configurations:
Monitoring setup (optional Prometheus + Grafana integration)
DNS setup for access via FQDN (Fully Qualified Domain Name)
SSL certificate integration (Ingress + cert-manager)
Vault/Secrets integration for secure credential management
Git repository connections (SCM credentials)
High Availability Deployment
AWX Operator 2.x+ with HA Supported:
spec:
replicas: 3
task_replicas: 3
web_replicas: 2
With this configuration, both the web pods and the task pods will start in High Availability (HA) mode.
This ensures that AWX remains scalable, reliable, and resilient, even under heavy workloads or node failures.
