💻
Cheet Sheets
  • 🦁Başlarken
  • 🟧DevOps Pre-Requisite
    • ❤️Why Linux? | Linux Basics #1
    • 💛Vi Editor | Linux Basics #2
    • 💙Basics Commands | Linux Basics #3
    • 🧡Package Managers | Linux Basics #4
    • 💚Services | Linux Basics #5
    • 💛Networking Basics
    • 🤎DNS Basics
    • 🩶Applications Basics
    • 🟨Java introduction
    • 🟩NodeJS Introduction
    • 🟦Python Introduction
    • 🟪GIT Introduction
    • 🟧Apache Web Server Introduction
    • ⬛Apache Tomcat
    • 🟫Python Flask
    • 🟥Node.js Express App
    • 🟨Databases
    • 🟩MySQL
    • 🟪MongoDB
    • 🟨SSL & TLS
    • 🟦YAML & JSON - JSON Path
    • ⬛Labs Resources
  • 🍎Kubernetes
    • 🍏Kubernetes: Nedir ?
    • 🍒Bileşenler
    • 🍵Kubectl ve Versiyon
    • ❤️Pod
    • 🏷️Label ve Selector
    • 🔎Annotation
    • 📲Namespaces
    • 📦Deployments
    • 🔁ReplicaSet
    • 🔙Rollout & Rollback
    • 🌐Networking - 1
    • 🌏Service
    • 🛠️Liveness Probe & Readiness Probe
    • 🥐Resource Limits
    • 💰Environment Variables
    • 📃Ephemeral Volumes
    • 🔑Secrets
    • 🌂ConfigMap
    • 🖥️Node Affinity
    • 🔌Pod Affinity
    • ✍️Taint and Toleration
    • 🔦DaemonSet
    • 🧀PV/PVC
    • 🌜Storage Class
    • 🗿StatefulSet
    • 🕹️Job & Cronjob
    • 🔐Authentication
    • 📏Role-based access control (RBAC)
    • 🈷️Service Account
    • 📈Ingress
    • 📂ImagePullPolicy & ImageSecret
    • 📖Static Pods
    • 🌐Network Policy
    • 🫐Helm Nedir?
    • 📽️Prometheus Stack - Monitoring
    • 💼EFK Stack - Monitoring
    • 🥳CRD & Operator
  • 🧑‍⚕️GIT & GITHUB
    • 👉Girizgah
    • 🌴Branch
    • 🤝Merge
    • 🤔Conflict - Rebase
    • 🇸🇴Alias
    • 🛑Gitignore
    • 🥢Diff
    • ◀️Checkout
    • 🔦Stash
    • 👉Other
  • ☁️AWS
    • 🪣S3
    • 🚙EC2
    • ⚖️ELB
    • 🤝Auto Scaling
    • 🗄️EFS
    • 🔐VPC
    • 🎆CloudFront
    • ❤️Route53
    • 🦈RDS
    • 🏢ElastiCache
    • 🔭CloudWatch
    • 👀CloudTrail
    • 📃CloudFormation
    • 🔕SNS
    • 📬SQS
    • 🎇SWF
    • 📧SES
    • 📦Kinesis
    • 📐AWSConfig
    • 👩‍🏭OpsWork
    • 🚀Lambda - Api Gateway
    • 📌ECS - EKS
    • 🔑KMS
    • 📂Directory Service
    • 🏐Snowball
    • 💾Storage Gateway
    • 💽Volume Gateway
    • 📼Tape Gateway
    • 🏠Organizations
    • 🔙Backup-Transfer-CloudShell
    • 🆔IAM
    • 📀DataSync
    • 🗃️FSx
    • 🎒Aurora Serverless
    • 🌐Global Accelerator
    • 💪HPC
    • 🎰Outposts
    • 🗼Others
  • 👨‍🔬Ansible
    • 👉Girizhah
    • 📔YAML
    • ⚙️Komponentler
    • 🎒Inventory
    • 🏑ad-hoc
    • ▶️Playbook
  • 👨‍⚕️PROMETHEUS
    • 📈Terminoloji
    • 🦯Ubuntu 20.04 Prometheus Kurulum
    • 🗒️prometheus.yml dosyasına ilk bakış:
    • 🧭promQL up query
    • 📇Exporters
    • 🔦promQL Data Types
    • 🦯Selectors & Matchers
    • 🔢Binary Operators
    • 💀ignoring and on
    • ✍️Aggregation Operators
    • 🧠Functions
    • 🖊️Alıştırma
    • 💻Client Libraries
    • 🐍Examining the data of our Python application
    • 🐐Examining the data of our GO application
    • ⏺️Recording Rules
    • 💡rate functions
    • ⏰Alerting
    • ⌚Alert Routing
    • ⏰Slack integration with Prometheus
    • 🤯PagerDuty integration with Prometheus
    • ◼️BlackBox exporter
    • 📍Push Gateway
    • 🪒Service Discovery
    • 🧊kube cadvisor with external prometheus
    • 👉aws with prometheus
    • ☁️CloudWatch Exporter
    • 👨‍🚒mysql exporter
    • 🛃Custom exporter with Python
    • ⚙️Prometheus with HTTP API
    • 🤖Prometheus Federation For Kubernetes
    • 📺Grafana
    • ⁉️Prometheus: Ne zaman kullanılmalı? Ne zaman kullanılmamalıdır?
  • 🍪Sheets
    • 🛳️Docker Sheets
    • 🐐Kube Sheets
  • 🔢12 Factor APP
    • 🏗️Introduction
    • 1️⃣Codebase
    • 2️⃣Dependencies
    • 3️⃣Concurrency
    • 4️⃣Processes
    • 5️⃣Backing Services
    • 6️⃣Config
    • 7️⃣Build, release, run
    • 8️⃣Port binding
    • 9️⃣Disposability
    • 🔟Dev/prod parity
    • 🕚Logs
    • 🕛Admin processes
  • ☁️Azure 104
    • 👨‍👨‍👧‍👧Azure Active Directory ( Entra ID )
    • 💰Subscriptions
    • 🌎Virtual Network (VNET)
    • 💻Virtual Machines
    • 🧑‍🌾Load Balancing
    • 🥍Network Advanced
    • 🪡Automating Deployment and Configuration
    • 💂Securing Storage
    • 📓Administering Azure Blobs and Azure Files
    • 🔧Managing Storage
    • 🎁App Service
    • 🛳️Azure Container
    • 🥇Backup And Recovery
    • 🪐Network Watcher
    • ⏰Resource Monitoring And Alerts
  • ⛅AZURE 305
    • 🆔identity and access management
    • 💼Desing Azure AD (Entra ID)
    • 👨‍💼Desing for Azure B2B
    • 🛃Desing for Azure B2C
    • 💳Design for MFA and Conditional Access
    • ⛑️Design for Identity Protection
    • 🚶Access Reviews
    • 🚦Managed identity Demostration
    • 🔐Key Vault Demostration
    • 👑Governance hierarchy
    • 💠Design for Management Groups
    • 🔑Desing for Subscriptions
    • 🍇Desing for resource groups
    • 📟Design for resource tags
    • 🚷Azure Policy & RBAC
    • 🫐Desing For Blueprints
    • 🪡Desing for Virtual Networks
    • 🛫Design for on-premises connectivity to Azure
    • 🔽Design for network connectivity
    • 📦Design for application delivery
    • 🥞Design for network security and application protection
    • 📕Choose a compute solution
    • 🌊Design for virtual machines
    • 🔋Azure Batch Demostration
    • 🛰️Design for Azure App Service
    • ⛲Design for Azure Container Instances
    • 🎢Design for Azure Kubernetes Service
    • 📠Azure Functions Demostration
    • 💪Azure Logic Apps Demostration
    • 🧑‍💼Design for data storage
    • 🎞️Design for Azure storage accounts
    • 🌟Choose the storage replication
    • 📹Azure blob storage - Lifecycle & immutable demo
    • 🥌Azure Files Demostration
    • 🕸️Design Azure disks
    • 🦼Design for storage security
    • 🔮Azure Table Storage And Cosmos DB Demostration
    • 🟧Azure SQL Solutions
    • 🎡Azure SQL Database - Purchasing models
    • 🕯️Database availability
    • 📜Data security strategy
    • 🧮Azure SQL Edge
    • 🚲Azure Data Factory
    • 🔅Azure Data Lake Storage
    • 🧘‍♂️Azure Databricks
    • 🎒Azure Synapse Analytics
    • 🅰️Azure Stream Analytics
    • 📼Data flow strategy
    • 🍥Cloud Adoption Framework
    • ☣️Azure Migration Framework
    • 🦿Assessing workloads
    • 🪡Migration tools
    • 🤖Azure Database migration
    • 👥Storage migration
    • 👜Azure Backup
    • ⏲️Azure Blob Backup and Recovery
    • 💈Azure files backup and recovery
    • 🎞️Azure VM backup and recovery
    • 🧺Azure SQL backup and recovery
    • ⏰Azure Site Recovery
    • 📩Differentiate event and message
    • ✈️Azure messaging solutions
    • 🚜Event Hub
    • 🥍Application optimization solution
    • 🎁Application lifecycle
    • 📺Azure Monitor
    • 🅱️Log Analytics
    • 👥Azure workbooks and Insights
    • 🚌Azure Data Explorer
  • Github Actions
    • Github Actions Nedir?
    • Workflow & Schedule Triggers
    • Single and Multiple Events
    • Manuel Events
    • Webhook Events
    • Conditional Keywords For Steps
    • Expressions - 1
    • Expressions - 2
    • Runners
    • Workflow Commands
    • Workflow Context
    • Dependent Jobs
    • Encrypted Secrets
    • Configuration Variables
    • Default & Custom Env Varb
    • Set Env Varb with Workflow Commands
    • Github Token Secret
    • Add Script to workflow
    • Push Package #1
    • Push Package #2 Docker
    • Service Containers
    • Routing workflow to runner
    • CodeQL Step
    • Caching Package and Dependency Files
    • Remove workflow Artifact
    • Workflow Status Badge
    • Env Protection
    • Job Matrix Configuration
    • Disable & Delete Workflows
    • Actions type for Action
    • Inputs and Outputs for actions
    • Action Versions
    • Files and Directories for Actions
    • Exit Codes
    • Reusable Workflow & Reuse Templates for Actions and Workflows
    • Configure Self Hosted Runners for Enterprise
  • Loki
    • What is Loki?
    • Architecture of Loki
    • Install Loki For Ubuntu
    • Install Promtail For Ubuntu
    • Querying Logs
    • Loki in Kubernetes
    • Deploying Loki in Kubernetes
    • Connecting to Grafana
    • Viewing Kubernetes logs
    • Promtail Customize & Pipeline
  • Ansible
    • Ansible Introduction
    • Introduction to Ansible Configuration Files
    • Ansible Inventory
    • Inventory Formats
    • Ansible Variables
    • Variable Types
    • Registering Variables and Variable Precedence
    • Variable Scoping
    • Magic Variables
    • Ansible Facts
    • Ansible Playbooks
    • Verifying Playbooks
    • Ansible lint
    • Ansible Conditionals
    • Ansible Conditionals based on facts, variables, re-use
    • Ansible Loops
    • Ansible Modules
    • Introduction to Ansible Plugins
    • Modules and Plugins Index
    • Introduction to Handlers
    • Ansible Roles
    • Ansible Collections
    • Introduction to Templating
    • Jinja2 Templates for Dynamic Configs
  • 🅰️Ansible Advanced
    • Playbook run options
    • Facts
    • Configuration files
    • Install required packages
    • SSH keys to managed nodes
    • Adhoc Commands
    • Commands with shell scripts
    • Privilege Escalation
    • Frequently Asked Questions
    • Additional Modules
    • Variable Precedence
    • Variable Scope
    • Use variables to retrieve the results of running commands
    • Magic Variables
    • Jinja2 Basics
    • Jinja2 in Ansible
    • Templating use cases
Powered by GitBook
On this page

Was this helpful?

  1. Ansible

Ansible Inventory

Inventory, Ansible’ın hangi sunucularla/cihazlarla çalışacağını tanımladığımız listedir. Bu listede genellikle:

  • Sunucu (veya cihaz) isimleri,

  • IP adresleri veya tam alan adı (FQDN) bilgileri,

  • Hangi port üzerinden bağlanılacağı (SSH için 22, WinRM için farklı port vb.),

  • Bağlanılırken kullanılacak kullanıcı adı (user) ve bazen parola (ssh_pass) gibi bilgiler yer alır.

Ansible, bu bilgiler sayesinde her bir hedef sunucuya “agent” yüklemeye gerek kalmadan (yani “agentless”) uzaktan bağlanır ve gereken işlemleri yapar.

Varsayılan Inventory Dosyası

  • Ansible kurulduğunda, varsayılan olarak /etc/ansible/hosts dosyası “default inventory” kabul edilir.

  • Eğer özel bir inventory oluşturmazsanız, Ansible komutları bu dosyadaki bilgileri okur.

Ancak ihtiyaca göre:

  • Proje klasörünüzde farklı bir hosts veya inventory dosyası oluşturabilir,

  • Ansible komutunu çalıştırırken -i /path/to/myinventory diyerek farklı bir inventory dosyası belirtebilirsiniz.

Basit Bir Inventory Örneği

INI-benzeri bir biçimde yazılır:

server1.company.com
server2.company.com

[mail]
server3.company.com
server4.company.com

[db]
server5.company.com
server6.company.com

[web]
server7.company.com
server8.company.com
  • Köşeli parantez [mail], [db], [web] gibi “grup adları”dır.

  • Gruplar, benzer roller üstlenen sunucuları bir arada toplar (ör. web sunucuları, veritabanı sunucuları).

  • Bir sunucu tek bir grupta olabileceği gibi birden çok grupta da bulunabilir.


Ansible Inventory Parametreleri

INI formatında, her satıra ek parametre ekleyerek sunucuya özel ayarları yapabilirsiniz. Örneğin:

# Alias vererek
web1 ansible_host=server1.company.com ansible_connection=ssh ansible_user=root
db1  ansible_host=server2.company.com ansible_connection=winrm ansible_user=administrator
  • ansible_host: Hedef sunucunun IP adresini veya FQDN’ini belirtir. (Örn: 192.168.1.10 veya server1.company.com)

  • ansible_connection: Bağlantı türü (ssh, winrm, localhost vb.)

    • ssh → Linux sunucular

    • winrm → Windows sunucular

    • localhost → Yerel makine (Ansible’ın çalıştığı makine)

  • ansible_user: Bağlanırken kullanılacak kullanıcı adı (Linux için genelde root, ya da Ubuntu sunucularda ubuntuvb.)

  • ansible_port: SSH için varsayılan 22’dir. Eğer farklı bir port kullanıyorsanız (ansible_port=2222 gibi) değiştirebilirsiniz.

  • ansible_ssh_pass: Parola yazabileceğiniz parametre. Tavsiye edilmez, çünkü metin olarak saklamak güvenlik zafiyeti yaratır. Daha iyisi SSH anahtarı (key-based authentication) kullanmak veya Ansible Vault ile parolayı şifrelemektir.

Bunlara “inventory parametreleri” diyoruz; her makineye özel ayarları ya satır sonuna ekleriz ya da group_vars/host_vars yapılarını kullanarak daha düzenli saklayabiliriz (ileri konular).

Neden Inventory Kullanıyoruz?

  1. Kolay Yönetim Yüzlerce sunucunuz varsa, hepsini tek tek IP yazmak yerine gruplara ayırır ve playbook’larda sadece [web], [db]gibi grup adları kullanarak işlemleri hedeflersiniz.

  2. Agentless Olma Ansible, hedef sunucularda ayrı bir program (agent) kurmaya ihtiyaç duymaz. Sadece SSH (Linux) veya WinRM (Windows) bağlantısı yeterlidir.

  3. Esneklik

    • Aynı inventory içindeki bazı makineler Linux, bazıları Windows olabilir.

    • İster IP ister domain name kullanabilirsiniz.

  4. Parametrik Tanımlama

    • Her sunucuya özel kullanıcı, port, parola gibi ayarları tek satırda belirtebilirsiniz.

    • Daha da ileride, group_vars ve host_vars adlı dizin yapılarıyla daha düzenli bir biçimde değişken tanımlayabilirsiniz.

Parola Konusu (ansible_ssh_pass)

  • Demo veya test amaçlı hızlı denemeler için ansible_ssh_pass kullanabilirsiniz.

  • Güvenliğe önem verilen ortamlarda, genellikle:

    • SSH key-based authentication tercih edilir (Linux tarafında).

    • Windows tarafında ise, Kerberos veya güvenli yöntemlerle etkileşim yapılır.

  • Ya da Ansible Vault gibi bir mekanizma kullanarak parolaları şifreli bir dosyada saklayabilir, playbook çalışırken açabilirsiniz.

Kısa Özet

  • Inventory, Ansible’ın hangi sunucularla çalışacağını tanımlar.

  • Varsayılan dosya /etc/ansible/hosts olsa da, kendi özel inventory dosyanızı oluşturabilirsiniz.

  • INI Formatı: Grup adlarını [groupname] şeklinde tanımlar, altına sunucu adreslerini yazarsınız.

  • Alias ve Parametreler (örn. ansible_host, ansible_connection, ansible_user, vb.) sayesinde her sunucuya özel ayar girebilirsiniz.

  • Basit şifre yerine anahtarsız (passwordless) SSH kullanmak veya Ansible Vault ile şifre saklamak güvenlik açısından önerilir.


Farklı Bir Inventory Dosyası Kullanmanın Yolları

  1. Komut Satırında -i Parametresi ile Belirtmek En sık kullanılan yöntem budur. Playbook’u çalıştırırken şu şekilde yazarsınız:

    ansible-playbook -i /path/to/my_inventory.ini my_playbook.yaml

    Böylece Ansible, varsayılan /etc/ansible/hosts yerine sizin belirttiğiniz my_inventory.ini dosyasını kullanır.

  2. ansible.cfg Dosyasında Belirtmek Projenizin kök dizininde (veya çalıştığınız herhangi bir dizinde) ansible.cfg dosyanız varsa, [defaults]bölümüne şu satırı ekleyebilirsiniz:

    [defaults]
    inventory = /path/to/my_inventory.ini

    Bu şekilde ansible-playbook my_playbook.yaml komutunu yazdığınızda, otomatik olarak bu inventory dosyası kullanılacaktır (başka bir -i parametresi verilmediği sürece).

  3. Ortam Değişkeni (Environment Variable) Kullanmak Bir diğer alternatif, geçici veya kalıcı olarak ANSIBLE_INVENTORY değişkenini ayarlamaktır. Örneğin:

    export ANSIBLE_INVENTORY=/path/to/my_inventory.ini
    ansible-playbook my_playbook.yaml

    Bu yöntemle de varsayılan envanter dosyası yerine sizin dosyanız kullanılır.

  • “export” yöntemiyle ayarlanan değişken, o terminal oturumunu kapatana veya değişkeni unset ANSIBLE_INVENTORYile silene kadar kalıcı hale gelir.

  • Dolayısıyla ikinci, üçüncü komutlarınız da aynı inventory dosyasını kullanır.

1. Aynı Satırda Kullanma (Tek Komut için)

ANSIBLE_INVENTORY=/path/to/my_inv.ini ansible-playbook my_playbook.yml
  • Bu yöntemde yalnızca o komut çalışırken ANSIBLE_INVENTORY geçerli olur.

  • Komut bittiğinde değişken sıfırlanır (shell’de kalıcı olmaz).


Kısa Özet

  • En Kolay Yol: ansible-playbook -i <inventory_dosyası> <playbook.yml>

  • Kalıcı Yol: ansible.cfg içinde [defaults] inventory = <inventory_dosyası>

  • Geçici Yol: ANSIBLE_INVENTORY ortam değişkeni ayarlamak

Bu üç yöntemden hangisini seçtiğiniz, projeyi nasıl organize ettiğinize ve hangi ortamda çalıştığınıza göre değişir. Tek komutla sınamak isterseniz, en pratik olan -i parametresidir.

PreviousIntroduction to Ansible Configuration FilesNextInventory Formats

Last updated 1 month ago

Was this helpful?