💻
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
Powered by GitBook
On this page
  • 1. Neden Playbook’ları Doğrulamak Gerekir?
  • 2. Check Mode (Dry Run)
  • 3. Diff Mode (Öncesi ve Sonrası Karşılaştırma)
  • 4. Syntax Check Mode (YAML Yazım Kontrolü)
  • 5. Kullanım Senaryoları ve Önemli Notlar
  • 6. Özet
  • Örnek,

Was this helpful?

  1. Ansible

Verifying Playbooks

1. Neden Playbook’ları Doğrulamak Gerekir?

  • Ufak bir yazım hatası veya yanlış bir task, yüzlerce sunucuda kritik hizmetlerin durmasına sebep olabilir.

  • “Ön izleme” yaparak riskleri düşürür, üretim ortamında sorun çıkmasını engellersiniz.

  • Hataları erken yakalamak, sonradan düzeltmekten çok daha hızlı ve az maliyetlidir.

Kısacası, “check”/“diff”/“syntax check” modlarını kullanarak ne olacağını önceden görür, hataları giderebilir ve playbook’un prod ortamlarda tam olarak beklediğiniz gibi çalışacağından emin olursunuz.

2. Check Mode (Dry Run)

2.1 Ne Yapar?

  • Ansible’ın “dry-run” özelliğidir: Playbook içindeki görevler gerçekten uygulanmaz; sadece hangi değişikliklerin yapılacağını gösterir.

  • Sunucularda hiçbir değişiklik olmaz. Yalnızca “Şu paket kurulu değilmiş, kuracaktım” gibi bir ön izleme verir.

2.2 Nasıl Kullanılır?

ansible-playbook <playbook_ismi>.yml --check

Örnek: install_nginx.yml playbook’unuz varsa:

ansible-playbook install_nginx.yml --check
  • Çıktıda “changed” gibi ibareler görürseniz, bunlar gerçek bir değişiklik değil, “değişiklik olsa ne olurdu?” bilgisidir.

  • Önemli: Bazı modüller check mode’u desteklemeyebilir, bu durumda “SKIPPED” olarak geçer.

3. Diff Mode (Öncesi ve Sonrası Karşılaştırma)

3.1 Ne İşe Yarar?

  • Sistemdeki dosya, ayar vb. yapılarda öncesi/sonrası farklarını gösterir.

  • Özellikle yapılandırma dosyası değiştiren (ör. lineinfile, template) görevlerde, “Hangi satır eklenecek veya silinecek?” gibi ayrıntılı bilgi verir.

3.2 Nasıl Kullanılır?

ansible-playbook <playbook_ismi>.yml --diff
  • Tipik olarak --check ile birlikte kullanılır:

    ansible-playbook configure_nginx.yml --check --diff
  • Çıktıda --- before ve +++ after gibi satırlar görürsünüz. + olan satırlar eklenecek bölümü, - olanlar çıkarılacak bölümü ifade eder.

Örnek: configure_nginx.yml ile /etc/nginx/nginx.conf dosyasına client_max_body_size 100M; ekleniyorsa, diff çıktısında:

--- before: /etc/nginx/nginx.conf
+++ after: /etc/nginx/nginx.conf
@@ -20,3 +20,4 @@
 # some existing lines
 #
+client_max_body_size 100M;

gibi bir ek satır görürsünüz.

4. Syntax Check Mode (YAML Yazım Kontrolü)

4.1 Ne İşe Yarar?

  • Playbook’unuzun YAML sözdizimini denetler.

  • Basit hataları (“: unutulmuş”, “girinti bozuk” vb.) hızlıca yakalar.

  • Görevleri çalıştırmaz, sadece “YAML dosyasında mantıksal hata var mı?” diye bakar.

4.2 Nasıl Kullanılır?

ansible-playbook <playbook_ismi>.yml --syntax-check
  • Hata yoksa “Syntax check complete. No errors found” benzeri bir mesaj alırsınız.

  • Hata varsa, size “satır 5, kolon 9’da beklenen anahtar bulunamadı” gibi ipuçları verir.

5. Kullanım Senaryoları ve Önemli Notlar

  1. Check Mode:

    • Prod ortamlara göndermeden önce “acaba gerçekten ne yapardı?” diye bakmak için ideal.

    • Bazı modüller (ör. command, shell) tam desteklemeyebilir, görevi “SKIPPED” olarak atlar.

  2. Diff Mode:

    • Konfigürasyon dosyalarında satır satır ne değişecek görmek için mükemmel.

    • Özellikle hassas dosyaları güncellerken faydalı.

  3. Syntax Check:

    • Basit ama çok faydalı. Özellikle “uygunsuz girinti” veya “:` unutulması” gibi YAML hatalarını hızla yakalar.

    • Kod gözden geçirirken zaman kazandırır.

Tavsiye:

  • Prod ortamına playbook uygulamadan önce sırasıyla “Syntax check → Check mode (ve diff mode)” yaparsanız riskleri büyük ölçüde azaltırsınız.

  • Daha gelişmiş test yaklaşımları için Molecule gibi framework’ler veya --limit parametresiyle önce test sunucularda deneme yapma da kullanılabilir.

6. Özet

  • Check Mode (--check): Dry-run yapar, değişiklikleri uygulamadan raporlar.

  • Diff Mode (--diff): Dosya/konfig değişikliklerinde öncesi/sonrası farklılıkları satır satır gösterir.

  • Syntax Check (--syntax-check): YAML formatında yazdığınız playbook dosyasının yazım (sözdizimi) hatalarını kontrol eder.


Örnek,

$ ansible-playbook install_nginx.yml --check
PLAY [webservers] ****************************************************************
TASK [Gathering Facts] ***********************************************************
ok: [webserver1]


TASK [Ensure nginx is installed] **************************************************
changed: [webserver1]


PLAY RECAP ***********************************************************************
webserver1 : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  • ok=2

    • Bu, Ansible’ın toplam 2 task yürüttüğünü ve bunların her birinde “mantıksal olarak başarıyla sonuçlandığını” anlatır.

    • Task 1: Gathering Facts (her zaman ilk aşamada sistem bilgileri toplanır veya check mode’da simüle edilir)

    • Task 2: Ensure nginx is installed (asıl “package install” aşaması)

  • changed=1

    • Ansible “check mode”da bile olsa, “bu görev normalde bir değişiklik yapacaktı” anlamını verir.

    • Örneğin “Ensure nginx is installed” adlı task, nginx paketinin kurulu olmadığını algılar ve “kurulacaktı” diye raporlar.

    • Gerçekte (dry-run olduğu için) paket kurulmadı, ama eğer check mode olmasaydı “changed=1” demek o görev gerçek bir değişiklik yapacaktı.

  • unreachable=0

    • “0” demek, hiçbir host’a “bağlanılamadı” hatası alınmadı. Tüm hostlar (burada webserver1) başarıyla erişilebilir durumda.

  • failed=0

    • “0” demek, hiçbir görev hata verip kesilmedi. Tüm görevler “success” şekilde (veya check mode’da “başarıyla test edildi”) tamamlandı.

  • skipped=0

    • Bazı modüller check mode’u desteklemez veya when: koşulu nedeniyle atlanırsa “skipped” artar. Burada “0” demek, “hiç atlanmış görev yok”.

  • rescued=0

    • Ansible’ın blocks yapısında bir hata olduğunda rescue: bölümü çalışabilir. Bu sayılar “rescue” mekanizmasının kaç kere tetiklendiğini gösterir. “0” demek, hiç devreye girmedi.

  • ignored=0

    • ignore_errors: yes gibi ayarlar varsa ve bir görev hata alırsa “ignored” sayısı artar. Burada “0” demek, öyle bir durum da yaşanmamış.

Özetle

  • “ok=2, changed=1” → İki görevin gayet sorunsuz çalıştığını ve bir tanesinin “değişiklik gerektireceğini” (dry-run’da “olabilirdi” şeklinde) gösterir.

  • unreachable=0, failed=0 → Bağlantı ve hata yok.

  • skipped=0, rescued=0, ignored=0 → Hiçbir görev atlanmamış, hata kurtarma veya hata göz ardı etme yaşanmamış.

Check mode’da “changed=1”, size “normalde bu host’ta nginx yok, kuracaktım” mesajıdır. Gerçek kurulumu uygulamak isterseniz --check olmadan aynı komutu çalıştırırsınız.

PreviousAnsible PlaybooksNextAnsible lint

Last updated 23 days ago

Was this helpful?