200 - 301

ICCNA Eğitimi
by Yavuz BULUT
Kıdemli Ağ Danışmanı ve Eğitmeni
 BÖLÜM
200 - 301
- 14

45 Controller Tabanlı Ağ’lar

Bölüm - 14
AĞ
46 Cisco Software Defined Access-SDA

OTOMASYON 47 REST ve JSON'u Anlamak

48 Ansible, Puppet ve Chef'i Anlamak

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14

45
Controller Tabanlı
I SDN and Controller Tabanlı Ağ’lar

I Controllers and Software-Defined Architecture

Ağ’lar I Ağ Programlanabilirliği ve SDN Örnekleri

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

SDN and Controller Tabanlı Ağlar Data Plane

Software Defined Networking (SDN) (Yazılım Tanımlı Ağ Oluşturma) Data Plane terimi, bir ağ cihazının bir mesajı iletmek için yaptığı görevleri ifade eder.

Bu bölüm de SDN ve Ağ programlanabilirliğinin en temel kavramlarını Başka bir deyişle, veriyi almakla, işlemekle ve aynı veriyi iletmekle ilgili her yaptığı şey

işleyeceğiz. Geleneksel ağ cihazlarında bulunan bazı işlevlerin bölünmesinden Data Plane’nin bir parçasıdır.

başlayacağız, daha sonra Controller adı verilen merkezi yönetim yazılımılarını

Örnek olarak aşağıdaki şekilde gösterildiği gibi router’ların IP paketlerini nasıl
kullanarak bir ağı nasıl kolay yönetebileceğimizden bahsedeceğim.
ilettiğini düşünün. Layer 3 mantığını düşündüğünüzde ;

Data, Control, and Management Planes Adım 1: Host paketi default router’ı olan R1'e gönderir.
Adım 2: R1, alınan paket üzerinde bazı işlemler yapar, bir yönlendirme kararı verir ve
İlk olarak ağ cihazlarında ki bazı işlevlerden bahsedelim. Örneğin, Router’lar ve
paketi iletir.
switch’ler, ağ oluşturmak için birbirlerine fiziksel olarak kablolarla ve kablosuz
Adım 3 ve 4 : Router’lar R2 ve R3 ayrıca paketi alır, işler ve iletir.
olarak bağlanır. Switch’ler Ethernet frame’lerini iletir, router’lar IP paketleri iletir.
Network katmanı route’ları öğrenmek için routing protokolleri gibi birçok farklı
Bu verdiğimiz örnek router’da Data Plane aşamasında gerçekleşir.
protokol kullanırlar.

Ağ cihazları bu yaptığı her işlevi belirli bir Plane ile kategorize edilebilir. Bu
Kategoriler ise Data Plane, Control Plane ve Management Plane olarak üçe
ayrılır.

Şekil 45-1 Basit olarak bir Router’da Data Plane İşlemleri

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Ağ cihazlarında Data Plane aşamasında yaygın olarak yapılan bazı işlevlerin Geleneksel ağlar hem dağıtılmış bir Data Plane hem de dağıtılmış bir Control

detaylarına aşağıdaki listeden bakalım. Plane kullanır. Diğer bir deyişle, her cihazın bir Data Plane ve bir Control Plane’i
vardır. Aşağıdaki örnekte router’larda Data Plane ve Control Plane aşamalarını
■ Bir ethernet frame paketin kapsülden çıkarılması ve yeniden kapsüllenmesi
göstermektedir.
(Router ve Layer 3 Switch’ler)
■ 802.1Q Trunk Header ekleme veya kaldırma (Router ve Switch’ler)
■ Bir Ethernet Framin’deki hedef MAC adresini, MAC adres tablosu ile
eşleştirmek (Layer 2 Switch’ler)
■ Bir IP paketinin hedef IP adresini IP yönlendirme tablosuyla eşleştirme (Router
ve Layer 3 Switch’ler)
■ Verileri şifreleme ve yeni bir IP Header ekleme ( VPN] işlemleri için ) Şekil 45-2 Router’da Control ve Data Plane Aşamalarının Çalışma Mantığı
■ Source veya Destination IP adresini değiştirme ( NAT işlemi için)
Yukarıdaki şekilde, Control Plane protokolü olan OSPF tüm Router’larda çalışır. Her
■ Bir filtre nedeniyle bir mesajın silinmesi (ACL’ler ve Port Security işlemleri)
Router’daki OSPF IP Routing tablosuna route’ları ekler, kaldırır ve değiştirir. Geçerli
Listedeki tüm işlemler Data Plane aşamasını oluşturur, çünkü Data Plane mesaj
route’lar belirlendikten sonra, Data Plane gelen paketleri iletebilir. Aşağıdaki liste ,
başına yapılan tüm eylemleri içerir.
yaygın olarak Control Plane protokollerinin çoğunu içerir:

Control Plane ■ Routing protokolleri OSPF, EIGRP, RIP, BGP

Control Plane terimi, Data Plane’i kontrol eden herhangi bir eylemi ifade eder. ■ IPv4 ARP

Zaten birçok Control Plane protokolünü biliyorsunuz, örnek olarak tüm IP ■ IPv6 Komşu Bulma Protokolü (NDP)

routing protokolleri Control Plane aşamasında çalışırlar. ■ Switchlerin MAC Adres öğrenmesi.
■ STP

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Management Plane

Control Plane, Data Plane’ninin davranışını doğrudan etkiler. Ancak Management

Plane, Data Plane’i doğrudan etkilemez. Bunun yerine Management Plane ağ
cihazlarını yönetmemize izin veren protokolleri içerir. Telnet ve SSH Management
Plane protokollerindendir.

Aşağıdaki şekilde bazı Managemet Plane Protokollerini göstermektedir.

Şekil 45-3 Router’da Control ve Data Plane Aşamalarının Çalışma Mantığı

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Controllers and Software-Defined Architecture

2010'larda yeni ağ oluşturma yaklaşımları ortaya çıktı, bu yaklaşımların çoğu, Control Bir Controller yazılım tabanlı (SDN) ağ cihazlarının kontrolünü merkezileştirir.

Plane işlevlerini, Controller adı verilen ve merkezi bir uygulama olarak çalışan bir Kontrolün derecesi ve kontrolün türü büyük ölçüde değişir. Örneğin, Controller

yazılıma taşımak. cihazların dağıtılmış Control Plane’i değiştirerek tüm Control Plane işlevlerini
gerçekleştirebilir. Alternatif olarak Controller cihazların çalışma şeklini
Controllers ile Merkezi Yönetim
değiştirmeden dağıtılmış Data, Control ve Management Plane’lerinin devam eden
Çoğu geleneksel Control plane işlemi dağıtılmış bir mimari kullanır. Örneğin, her çalışmasını yönetebilir . Ve liste birçok varyasyonla devam ediyor.
Router kendi OSPF Routing protokol sürecini çalıştırır. İşlemleri yapmak için, bu
Bir Controller fikrini daha iyi anlamak için, bir SDN Controller’ının tüm önemli
dağıtılmış Control Plane süreçleri Router’lar arasındaki iletişimi kurmak için OSPF
Control Plane işlevlerini merkezileştirdiği Şekil 45-4'te gösterildiği gibi özel bir
protokol mesajları gibi mesajları kullanır. Sonuç olarak, geleneksel ağların dağıtılmış
durumu düşünün. İlk olarak Controller ağdaki cihazlara erişebilmesi için ağa
bir Control Plane kullandığı söylenir.
bağlanır. Ağ cihazlarının her biri hala bir Data Plane sahiptir; ancak, cihazların
Bir ağdaki herhangi bir işlevi yerine getirmek için dağıtılmış veya merkezileştirilmiş Control Plane işlevleri artık Controller tarafından gerçekleştirilir. Controller Data
mimarileri kullanmanın artıları ve eksileri vardır. Birçok Control Plane işlevi, Plane girişlerini doğrudan programlar. Ağ cihazları, routing tablolarını geleneksel
dağıtılmış bir mimariyle iyi çalışma konusunda uzun bir geçmişe sahiptir. Bununla dağıtılmış Control Plane işlemleriyle doldurmaz.
birlikte, merkezi bir uygulamanın yazılması, dağıtılmış bir uygulamaya göre daha
kolay olabilir çünkü merkezi uygulama, tüm verileri tek bir yerde toplar. Bu yeni
ortaya çıkan yazılım tanımlı mimariler dünyası (SDA), temelleri Controller adı verilen
merkezi bir Control Plane sahip bir merkezi mimariyi kullanır.

I CCNA Eğitimi 200-301

by Yavuz BULUT Şekil 45-4 Centralized Control Plane and a Distributed Data Plane
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Southbound Interface

Controller tabanlı bir ağ mimarisinde, Controller’ın ağ cihazlarıyla iletişim kurması

gerekir. Çoğu ağ çiziminde ve mimari çizimlerde, bu ağ cihazları tipik olarak, Şekil
45-4’te gösterildiği gibi Controller’ın altında yer alırlar. Controller ile bu cihazlar
arasında bir Interface vardır ve çizimlerde ağ cihazlarının alt kısmındaki konumu göz
önüne alındığında, bu Interface’ler güneye giden arayüz (Southbound Interface)
veya SBI olarak bilinmeye başlamıştır.

Bir SBI, Controller ve cihazların iletişim kurabilmesi için genellikle bir protokol içerir,
ancak genellikle bir uygulama programlama arayüzü (API - Application
Şekil 45-4 Centralized Control Plane and a Distributed Data Plane
Programming Interface) içerir. Bir API, bir uygulamanın (programın) başka bir
uygulama ile veri alışverişi yapması için bir yöntemdir. Programlar verileri işler,
böylece bir API iki programın veri alışverişi yapmasına izin verir. Bir protokol,
genellikle bir standartlar gövdesinden bir belge olarak varolsa da, bir API, bir ağdaki
programlar arasında yapılandırılmış verileri iletmek ve kopyalamak için bir program
tarafından kullanılabilen, genellikle kullanılabilir kodlar (işlevler, değişkenler ve veri
yapıları) olarak bulunur.

SBI Controller ve ağ cihazları arasındaki bir arayüzdür ve iki programın iletişim

kurmasına izin verir, tek amaç Controller’ın ağ cihazlarının Data Plane yönlendirme
tablolarını programlamasına izin vermektir.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Northbound Interface

Bir merkezi bir kontrol modelinde Controller , Control Plane için gereken işin NBI'nin nerede olduğunu görmek için önce Controller cihazının kendisini
çoğunu yapar ve Ağ hakkında her türlü yararlı bilgiyi toplar. Controller ağ hakkındaki düşünün. Controller bir VM veya fiziksel sunucularda çalışan bir yazılımdır. Bir
tüm bu yararlı bilgiler için merkezi bir havuzunu oluşturabilir. Aşağıdaki liste uygulama, Controller ile aynı sunucu üzerinde çalışabilir ve iki programın iletişim
Controller’ın ağda topladığı bilgileri listeler; kurabilmesi için bir API olan bir NBI kullanabilir.

■ Ağdaki tüm cihazların listesi Aşağıdaki şekil tam da böyle bir örneği göstermektedir. Şekildeki büyük kutu,

■ Her bir cihazın yetenekleri Controller yazılımının bulunduğu sistemi temsil etmektedir. Bu Controller Java

■ Her cihazdaki interface’ler / portlar tabanlı bir yazılımdır ve Java tabanlı bir yerel API'ye sahiptir. Controller üreticisi

■ Her Port’un mevcut durumu başka bir şirket veya herhangi birisi, Controller’ın Java API kullanan aynı işletim

■ Topoloji - hangi cihazların hangi interface bağlandığı sisteminde çalışan bir uygulama yazabilir. Controller ile veri alışverişi yapmak için

■ Cihaz yapılandırması - IP adresleri, VLAN'lar vb. bu API’yı kullanarak uygulama ağ hakkındaki bilgileri öğrenebilir.

Bir Controller; Northbound Interface (NBI) açar, böylece verileri ve işlevleri diğer
programlar tarafından kullanılabilir ve çok daha hızlı ağ programlanabilirliğini
sağlar. Programlar Controller’ın API'larını kullanarak bilgi alabilir. NBI'ler ayrıca
programların, Controller cihazının SBI'larını kullanarak cihazlara giren akışları
programlamak için Controller’ın yeteneklerini kullanmasını sağlar.

I CCNA Eğitimi 200-301 Şekil 45-5 Java API: Java Applications Communicates with Controller
by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Ağ Programlanabilirliği ve SDN Örnekleri

Bu bölüm de Cisco'nun sunduğu üç farklı SDN ve ağ programlanabilirlik Open SDN modeli, Controller tarafından yapılan ağ denetimi ve Controller’ın

çözümünden bahsedeceğiz. NBI'larını kullanan tüm uygulamalarla çoğu Control Plane işlevini merkezileştirir.
Aslında Control Plane işlevleri olmayan ağ cihazlarını gösteren aşağıdaki şekil
■ OpenDaylight Controller
SDN'nin bu merkezileştirilmiş OpenFlow modelini temsil etmektedir.
■ Cisco Application Centric Infrastructure (ACI)
■ Cisco APIC Enterprise Module (APIC-EM) OpenFlow modelinde uygulamalar cihazlara ne tür yönlendirme tablosu
girişlerinin ekleneceğini dikte etmek için Controller’ında desteklediği herhangi bir
OpenDaylight and OpenFlow
API'yı (NBI'ler) kullanabilir, ancak ağ cihazlarının OpenFlow'u destekleyen cihazlar

Yaygın bir SDN biçimi olan Open Networking Foundation'dan (ONF) gelir ve Open olması gerekir.

SDN olarak adlandırılır. ONF (www.opennetworking.org), pazarda SDN

kurulmasına yardımcı olmak için kullanıcılar (operatörler) ve satıcılardan oluşan bir
konsorsiyum olarak hareket eder. Bu çalışmanın amacı insanların SBI ve NBI’ları
kullanarak SDN vizyonlarını uygulamalarına yardımcı olmaya çalışmaktır.

SDN'nin ONF modeli OpenFlow özelliğine sahiptir. OpenFlow, Controller ve ağ

cihazları arasında IP tabanlı bir SBI ile birlikte bir Controller konseptini tanımlar.
OpenFlow, günümüzde switch’lerde yaygın olarak kullanılan ASIC'lere ve
TCAM'lara dayalı olarak bir switch’in yeteneklerinin ne olduğuna dair standart bir
fikir tanımlar.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

OpenDaylight Controller Cisco Open SDN Controller (OSC)

OpenDaylight açık kaynaklı SDN Controller olarak 2010'larda konsolidasyon
sürecinden ortaya çıkan en başarılı SDN Controller platformlarından biridir. Tüm
üreticiler açık kaynaklı Controller’ı kendi ürünlerinin temeli olarak kullanabilir ve
her üretici temel özelliklerden ziyade ürünü farklılaştırma kısmına odaklanabilirler.
Cisco 2010’larda OpenDaylight Controller modeli olan Cisco Open SDN Controller
(OSC) adı verilen ticari bir sürümünü çıkardı. Bu Controller ODL projesi için
geliştirilen modelden esinlenerek yapıldı.
Cisco artık Cisco OSC'yi üretmiyor ve satmıyor, geçmiş ürünlerden de bilginiz

S o n u ç o l a r a k , 2 0 1 0 ' l a r ı n o r t a l a r ı n d a O p e n D ay l i g h t S D N Co n t ro l l e r olması açısından kısaca bahsetmek istedim.

(www.opendaylight.org) doğdu. OpenDaylight (ODL) ayrı bir proje olarak başladı,

ancak şu anda Linux Foundation tarafından yönetilen bir proje olarak devam
etmektedir. Şekil 45-6, ODL mimarisinin genelleştirilmiş bir versiyonunu
göstermektedir.

Şekil 45-6 Architecture of NBI, Controller Internals, and SBI to Network Devices

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Cisco Application Centric Infrastructure (ACI)

Cisco veri merkezi için ağ oluşturmayı yeniden tasarlarken, SCI tasarımcıları bir veri
merkezinde çalışan uygulamalara ve ihtiyaç duydukları şeylere odaklandılar. Sonuç
olarak, uygulama mimarileri etrafında ağ oluşturma konseptleri oluşturdular.
Cisco, ağ altyapısını uygulama merkezli bir hale getirdi, dolayısıyla Cisco’nun SDN
veri merkezi çözümünün adı: Application Centric Infrastructure (ACI) ( Uygulama
Merkezli Altyapı )

ACI Physical Design: Spine and Leaf

Cisco ACI, Spine ve Leaf adı verilen özel bir fiziksel switch topolojisi kullanır. ACI ile
fiziksel ağda, sağ taraftaki şekil de gösterildiği gibi bir dizi Spine Switch ve bir dizi
Leaf switch’ler bulunur. Şekil 45-7 Spine-Leaf Network Design

■ Her bir Leaf Switch, her Spine Switch’e bağlanmalıdır.

■ Her bir Spine Switch, her Leaf Switch’e bağlanmalıdır.

■ Leaf Switch’ler birbirine bağlanamaz.

■ Spine Switch’ler birbirine bağlanamaz.

■ Uç noktalar yalnızca Leaf switch’e bağlanır.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 45 I Controller Tabanlı Ağ’lar

Cisco APIC Enterprise Module

Cisco şirketlerde yeni ağ tasarımlarını uygulamaya başladığında, büyük bir engel

ile karşılaştılar. Müşterilerinin ağlarınındaki mevcut cihazların çoğunda herhangi
bir kurumsal SDN çözümü yoktu, mevcut cihazların bazılarının SBI’ları desteklediği
için merkezi bir şekilde SDN çözümleri uygulanamayacağı görüldü, bunun için
APIC-EM ürünü geliştirildi.

APIC-EM Basics

Cisco, ilk SDN (ağ programlanabilirliği) çözümünü sunduğunda, müşterilerin tüm

donanımlarını değiştirmelerini ve SDN çözümleri ile uyumlu ürünler almaları fikrini
Şekil 45-8 APIC-EM Controller Model
reddetti. Bunun yerine mevcut cihazları değiştirmeden merkezi bir Controller ile
SDN’in avantajlarını ağlara eklemenin yollarını aradı. Cisco APIC-EM ürünü ile ■ Topoloji Haritası: Uygulama, ağın topolojisini keşfeder ve görüntüler.

mevcut ağlardaki cihazları değiştirmeden kurumsal SDN çözümleri sundu.
Ağdaki cihazların yeni SDN özellikleri yoksa, Controller tabanlı bir mimari ne gibi
avantajlar sağlayabilir? Şekil 45-8’deki avantajları sağlayabilir.
■ Yol İzleme: Kullanıcı bir kaynak ve hedef cihaz sağlar ve uygulama, her adımda
yönlendirme ayrıntılarla birlikte ağdaki yolu gösterir.
■ Tak ve Çalıştır: Bu uygulama, yeni bir cihazı kutusundan çıkarabilmeniz ve
Controller’daki otomasyon yoluyla onu IP'ye erişilebilir hale getirebilmeniz için tak

Cisco, 2019'da mevcut APIC-EM ürünü için satışın sona erdiğini duyurdu. APIC-EM çalıştır desteği sağlar.

ürününün işlevlerinin birçoğunu, Cisco DNA Center (DNAC) ürününün temel ■ Kolay QoS: Controller’da birkaç basit adımla, her cihazda karmaşık QoS

özellikleri haline gelmiştir. özelliklerini yapılandırabilirsiniz.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14

46
Cisco Software- I SDA Fabric, Underlay, and Overlay

Defined Access
I DNA Center and SDA Operation

I Ağ Yönetim Platformu olarak DNA Center

(SDA)

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

SDA Fabric, Underlay, and Overlay

Cisco Software Defined Access (SDA) (Yazılım Tanımlı Erişim), geleneksel ağ Underlay : Overlay VXLAN tünelleri oluşturma sürecinin bir parçası olarak tüm SDA

oluşturma yöntemlerine kıyasla Campus LAN'ları oluşturmak için tamamen yeni destekli cihazları dinamik olarak bulmak ve bu cihazların IP bağlantısını sağlamak

bir yöntemdir. Cisco 2010'ların ortalarında SDA ile Campus LAN’ları yeniden için kablolu ve kablosuz bağlantıları kullanır.

tasarlamaya başladı. Fabric (Yapı) : Ağ üzerinden veriyi iletmek için tüm özellikleri bir arada sunan
overlay ve underlay kombinasyonu kullanır..
SDA, bir Controller ve çeşitli API'lar ile Yazılım Tabanlı Mimari modeli kullanır. Bu
mimaride de halen Switch’ler, Router’lar, kablolar ve çeşitli uç noktaları içeren
fiziksel bir ağ kullanılıyor. Yandaki Şekil’de de gösterildiği gibi Dijital Ağ Mimarisi
(DNA) yazılımı merkezi Controller oluyor, bir grafik user interface (GUI) ve API’ları
kullanarak otomasyon sağlanıyor. Kısaca DNA Center, SDA ağlarının Controller’ı
oluyor..

Mimari olarak Controller SBI tarafı şunları içerir; Fabric, Underlay ve Overlay.

Overlay : SDA Switch’ler arasında VXLAN tünel mekanizmaları oluşturulur, daha

sonra trafiği bir cihazdan diğerine taşımak için SDA yapısını kullanılır.

Şekil 46-1 DNA Merkezli SDA Mimari Modeli

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

SDA Underlay SDA Overlay

SDA Underlay, Overlay ağındaki VXLAN tünellerini desteklemek amacıyla SDA İlk olarak, bir uç nokta, SDA ağı üzerinden teslim edilecek bir frame gönderir.
ortamındaki Switch’ler arasında bağlantı sağlamak işlevini yapar. Underlay bunu Frame’i alan ilk SDA Switch, frame’i VXLAN adı verilen bir tünelleme özelliği
yapmak için fiziksel ağı oluşturan kablolu ve kablosuz bağlantıları kullanır. kullanarak kapsüller ve frame’i iletir. Diğer SDA Switch’leri frame’leri VXLAN tüneli
ayrıntılarına göre iletir. Son SDA Switcth, VXLAN ayrıntılarını kaldırarak orijinal
SDA Underlay için Mevcut Cihazları Kullanma
frame’leri hedef uç noktaya doğru iletir.
Bir SDA underlay ağı oluşturmak için şirketlerin iki temel seçeneği vardır. Mevcut
kampüs ağlarını kullanabilir veya alternatif olarak yeni Switch’ler satın alabilir ve
mevcut trafiğe zarar verme endişesi olmadan SDA ağını kurabilir ve zaman içinde
uç noktaları yeni SDA ağına taşıyabilirler.

SDA Underlay için Yeni Cihazları Kullanma

SDA yapısı için yeni cihazlar almak mevcut cihazları kullanırken karşılaşılabilecek Şekil 46-3 SDA'da VXLAN Kapsüllemesinin Temelleri

birçok zorluğu ortadan kaldırır. Uyumlu donanım ve yazılımları kolayca sipariş Bunun işe yaraması için, önce Underlay 172.16.0.0/16 IPv4 adres alanı kullanılarak,
edebilir ve DNA Center ile, tüm underlay özelliklerini otomatik olarak tüm switch’leri bu IP adetleri ile yapılandıracaktır. Aşağıdaki şekilde her biri

yapılandırabilirsiniz. gösterilen underlay IP adresine sahip dört switch’li küçük bir SDA tasarımını
gösterir (172.16.0.0/16 adres alanından).

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

DNA Center and SDA Operation

Cisco DNA Center (www.cisco.com/go/dnacenter) ağlarımızda iki önemli role
sahiptir:

■ Cisco SDA kullanan bir ağda Controller olarak çalışmak.

■ Geleneksel (SDA olmayan) ağ cihazları için bir ağ yönetimi platformu olarak
çalışmak

Cisco DNA Center

Cisco DNA Center yönettiği cihazlarla iletişim kurabilmesi için birkaç Southbound
API'yi destekler. Bunları iki kategori olarak düşünebilirsiniz:

■ Geleneksel ağ aygıtlarını / yazılım sürümlerini destekleyen protokoller: Telnet,

SSH, SNMP
■ Daha yeni ağ aygıtlarını / yazılım sürümlerini destekleyen protokoller: NETCONF, Şekil 46-4 Cisco DNA Center with Northbound and Southbound Interfaces

RESTCONF

Cisco DNA Center, çok sayıda eski Cisco cihazları ve işletim sistemi sürümlerini
destekleyebilmek için eski protokollere ihtiyaç duyar. Zamanla Cisco, daha güncel
donanım ve yazılımlarına NETCONF ve RESTCONF için destek ekliyor.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

Ağ Yönetim Platformu olarak DNA Center

Geleneksel kurumsal ağları yönetmek için Cisco Prime Infrastructure (PI) PI'nın kendisi, bir web tarayıcısı aracılığıyla GUI erişimi olan bir sunucu

(www.cisco.com/go/primeinfrastructure) ürünü kullanılmaktadır. Cisco Prime platformunda bir uygulama olarak çalışır. PI sunucusu, sunucularınız üzerinde
Infrastructure, uzun yıllar boyunca şirketlerde ağ yönetimi için kullanılmıştır. kurulup çalıştırılacak bir yazılım paketi olarak veya fiziksel bir cihaz olarak
Aşağıdaki özellikleri içerir: Cisco'dan satın alınabilir.

■ Tüm PI işlevlerini ve özelliklerini tek bir GUI üzerinden kullanılabilir.

■ Ağ cihazlarını keşfeder, bir envanter oluşturur ve bunları bir topoloji haritasını
DNA Center’ın Geleneksel Yönetime Benzerlikleri
çıkarır.
DNA Center’ın tüm özellikleri geleneksel yönetim yazılımlarına benzemektedir.
■ Geleneksel kurumsal LAN, WAN ve veri merkezi yönetimi işlevleri için destek
Örneğin, her ikisi de ağ cihazlarını keşfedebilir ve bir ağ topoloji haritası
sağlar.
oluşturabilir.
■ Ağdaki aygıtlar hakkında bilgileri görüntülemek ve öğrenmek için SNMP, SSH ve
Telnet'in yanı sıra CDP ve LLDP'yi kullanır. Örnek olarak bir sonraki sayfada Şekil 46-5’de DNA Center’daki bir ağ topolojisi
■ Her cihaza QoS yapılandırmasını basitleştirir haritasını göstermektedir. Hem PI hem de DNA Center, ağdaki tüm cihazları
■ Aynı yönetim platformundan hem kablolu hem de kablosuz ağları yönetmenizi
bulmak için bir keşif işlemi gerçekleştirebilir ve ardından cihazları göstermek için
sağlar.
topoloji haritaları oluşturabilir. (İlginç bir şekilde, DNA Center, keşif çalışmasını
■ Ağ cihazlarındaki yazılımları yönetir ve güncellemeleri otomatikleştirir.
tekrar gerçekleştirmek yerine PI tarafından keşfedilen verileri kullanarak PI ile
■ Yeni cihazı fiziksel olarak kurup bir ağ kablosu bağlayıp ve cihazı çalıştırdıktan
çalışabilir.)
sonra yeni ağ cihazları için ilk kurulumları gerçekleştirir.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

Şekil 46-5 DNA Center Topology Map Şekil 46-6 DNA Center'dan Bir Cisco 9300 Switch Hakkında Ayrıntılara Gelin ve Tıklayın

GUI mekanizmaları, daha fazla veya daha az ayrıntıya tıklama yeteneği ile nispeten Cisco DNA Center ile ilgili bazı videoları kullanmak ve izlemek için biraz zaman
sezgiseldir. Şekil 45-6, Şekil 45-5'daki topolojideki switch’lerin birinin üzerine gelip ayırmanızı tavsiye ederim. https://developer.cisco.com adresinden Cisco DNA
tıkladıktan sonra, biraz daha ayrıntılı gösterir. Center ile pratik yapmak için Cisco DNA Center sanal laboratuvarlarını
bulabilirsiniz.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 46 I Cisco Software-Defined Access (SDA)

Geleneksel Yönetim ile DNA Center Farklılıkları

Geniş anlamda, Cisco DNA Center ile Cisco PI gibi geleneksel ağ yönetimi ■ Şifreli trafik analizi: Cisco DNA Center şifrelenmiş trafikte bile güvenlik tehditlerini

platformları arasında birkaç temel fark vardır. En büyük fark: Cisco DNA Center, tanımak için değişik algoritmalar kullanılmasını sağlar.

SDA'yı desteklerken diğer yönetim uygulamaları desteklemez. Cisco PI hala Cisco ■ Cihazların sağlık durumları hakkında kapsamlı bilgiler verir.

DNA Center'da bulunmayan bazı geleneksel yönetim özelliklerine sahiptir. Bu ■ Ağda zaman yolculuğu: Mevcut davranışları karşılaştırma yapmak için geçmiş

nedenle, Cisco DNA Center'ın SDA desteği gibi gelecekteki özelliklere odaklanırken istemci performansını bir zaman çizelgesinde gösterir

bu özelliklerin çoğuna sahip olduğu PI'yi geleneksel cihaz yönetimi için kapsamlı
olarak düşünün.

Cisco DNA Center özelliklerini geliştirerek işletmeler tarafından yapılan işi

basitleştirmek ve daha düşük maliyetler ile değişikliklerin çok daha hızlı
yapılabilmesini amaçlamaktadır. Cisco DNA Center ilk kurulumları kolaylaştırmaya
ve zorlu konfigürasyona sahip özellikleri uygulamak için işi basitleştirmeye ve
sorunları daha hızlı fark etmenize yardımcı olur. Cisco DNA Center'a özgü
özelliklerden bazıları şunlardır:

■ EasyQoS: Manuel olarak yapılandırması karmaşık olan QoS'i Cisco DNA Center'dan
yalnızca birkaç basit seçenekle yapabilirsiniz.

Not : Cisco, DNA Center geleneksel ağ yönetimi özelliklerini, Cisco PI ile kıyaslandığında, DNA
I CCNA Eğitimi 200-301 Center'ın PI'ın yerini alabileceği noktaya kadar güncellemeye devam etmeyi umuyor.
by Yavuz BULUT
 BÖLÜM - 14

47
REST ve JSON'u
I REST Tabanlı API’ler

I REST APIs and HTTP

Anlamak I Data Modelleme ve JSON

I JSON'u Yorumlama

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

REST Tabanlı API’ler REST Tabanlı (RESTful) API’ler

Uygulamalar, iletişim kurmak için uygulama programlama arayüzlerini ( API- REST API'ler, bir REST API'yi neyin oluşturup neyin oluşturmadığına ilişkin bir
Application Programming Interfaces) kullanır. Bunu yapmak için, bir program dizi temel kuralı izler. REST API'lerin yaratıcısı Roy Fielding tarafından
başka bir program tarafından kullanılan değişkenleri ve veri yapılarını öğrenebilir, tanımlanan altı özelliği içerir. (Https://restfulapi.net adresinde iyi bir özet
bu değerlere göre mantıksal seçimler yapabilir, bu değişkenlerin değerlerini bulabilirsiniz). Bu altı özellik
değiştirebilir, yeni değişkenler oluşturabilir ve değişkenleri silebilir. API'ler, farklı
bilgisayarlarda çalışan programların işbirliği içinde çalışmasına ve bir hedefe ■ Client/server architecture
ulaşmak için veri alışverişinde bulunmasına izin verir. ■ Stateless Operation
■ Clear statement of cacheable/uncacheable
API yazılım dünyasında, bazı uygulamalar API'yi kullanan diğer birçok uygulama ile
■ Uniform Interface
birlikte bir API oluşturur. Yazılım geliştiricileri, diğer uygulama yazılımlarının ilk
■ Layered
uygulamanın özelliklerinden yararlanabilmesi için yazılımlarına API'ler ekler.
■ Code-on-Demand

Bir yazılımcı uygulama yazarken bir miktar kod yazar, ancak yazılımcı verileri ve
Bu özelliklerin ilk üçü, bir REST API'nin nasıl çalıştığının temelini oluşturur. Bu ilk
işlevleri sağlayabilen bazı API'leri kullanarak yazılması gereken yeni kod miktarını
üç özelliği ağ oluşturma REST API'leri ile çalışırken daha kolay görebilirsiniz,
azaltarak daha az kod yazarak daha fazla iş yapabilir.
şimdi bu ilk üç özelliğe bakalım.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14
Client/Server Architecture
Birçok uygulama gibi, REST uygulamaları da bir istemci / sunucu mimari modeli
kullanır. İlk olarak, bir uygulama geliştiricisi bir REST API oluşturur ve bu uygulama
yürütülürken bir REST sunucusu görevi görür. Diğer herhangi bir uygulama,
istemciden sunucuya bir isteğin akmasına neden olan bazı kodları çalıştırarak bir
REST API çağrısı (REST istemcisi) yapabilir. Örneğin, Şekil 47-1’de
1- Soldaki REST client, REST server’a REST API mesaj çağrısı gönderir.
2- Sağdaki REST sunucusu, isteği dikkate alan ve nasıl yanıt verileceğine karar veren
API koduna sahiptir.
3- REST sunucusu, cevap mesajındaki uygun veri değişkenleri ile cevap mesajını
geri gönderir.
Şekil 47-1 REST ile Client / Server İşlemi
I CCNA Eğitimi 200-301
by Yavuz BULUT
47 I REST ve JSON'u Anlamak
Stateless Operation
REST API'lerinin durumsuz özelliği, REST'in sonraki API değişimlerinin nasıl
işleneceği hakkındaki bilgileri kaydetmediği ve kullanmadığı anlamına gelir.
Karşılaştırma için, TCP protokolü durum bilgisi olan bir yaklaşım kullanırken, UDP
durum bilgisi olmayan işlem kullanır. Bir TCP bağlantısı, uç noktaların her bir uçtaki
değişkenleri başlatmasını, bu değişkenlerin zaman içinde güncellenmesini ve bu
değişkenlerin sonraki TCP mesajları için kullanılmasını gerektirir. Örneğin, TCP, bir
TCP bağlantısındaki veri akışını yönetmek için sıra numaralarını ve onay
numaralarını kullanır.
Cacheable (or Not)
Önbelleğe alınabilir kelimesinin ne anlama geldiğini anlamak için, bir web sitesine
göz attığınızda ne olacağını düşünün. Tarayıcınız yeni bir web sayfası yüklediğinde,
sayfanın içinde çeşitli nesneler (metin, resimler, videolar, ses) içerir. Bazı nesneler
nadiren değişir, bu nedenle nesneyi bir kez indirip bir daha indirmemeniz daha iyi
olur; bu durumda, sunucu bu nesneyi önbelleğe alınabilir olarak işaretler. Örneğin,
bir web sitesinin birçok sayfasında gösterilen bir logo veya başka bir resim
neredeyse hiç değişmez ve muhtemelen önbelleğe alınabilir. Ancak, en son web
sitesi aramanızda döndürülen ürün listesi önbelleğe alınamaz çünkü sunucu,
sayfayı her talep ettiğinizde güncellemek ve yeni bir liste sağlamak isteyecektir.
 BÖLÜM - 14
REST APIs and HTTP
İki programın veri alışverişine izin vermek için API'ler kullanılır. Bazı API'ler, aynı
bilgisayarda çalışan programlar arasında bir arayüz olarak tasarlanabilir, böylece
programlar arasındaki iletişim tek bir işletim sistemi içinde gerçekleşir. Diğer
bilgisayarlarda çalışan programlar için birçok API'nin kullanılabilir olması gerekir, bu
nedenle API, API tarafından desteklenen ağ protokollerinin türünü tanımlamalıdır
ve birçok REST tabanlı API, HTTP protokolünü kullanır.
REST tabanlı API’leri geliştirenler genellikle HTTP'yi seçerler çünkü HTTP'nin
mantığı, REST API'leri için daha genel olarak tanımlayan bazı kavramlarla eşleşir.
HTTP, REST ile aynı ilkeleri kullanır, istemci / sunucu modeli ile çalışır; stateless
operation modelini kullanır ve nesneleri önbelleğe alınabilir veya önbelleğe
alınamaz olarak işaretleyen başlıklar içerir.
Software CRUD Actions and HTTP Verbs
Yazılım endüstrisi bir uygulama tarafından gerçekleştirilen dört ana eylem için
akılda kalıcı bir kısaltma olan CRUD kullanır. Bu eylemler
Create: İstemcinin sunucuda bazı yeni değişkenler ve veri yapıları oluşturmasına ve
sunucuda tutulan değerleri başlatmasına izin verir
I CCNA Eğitimi 200-301
by Yavuz BULUT
47 I REST ve JSON'u Anlamak
Read: İstemcideki değişken yapıların ve değerlerin bir kopyasını depolayarak,
sunucuda bulunan değişkenlerin geçerli değerini almasını (okumasını) sağlar.
Update: İstemcinin sunucuda bulunan değişkenlerin değerini değiştirmesine
(güncellemesine) izin verir
Delete: İstemcinin sunucudan farklı veri değişkenleri örneklerini silmesine izin verir
Örneğin, bir DNA Controller’ın Nourthbound REST API'sini kullanıyorsanız, yeni bir
güvenlik politikası gibi yeni bir şey oluşturmak isteyebilirsiniz. Programlama
perspektifinden bakıldığında, güvenlik politikası, değişkenler tarafından dahili
olarak temsil edilen DNA Controller’da bir dizi yapılandırma ayarı olarak mevcuttur.
Bunu yapmak için, bir REST istemci uygulaması, DNA Center REST API'si aracılığıyla
DNA Controller üzerinde değişkenler oluşturan DNA Center RESTful API'yi
kullanarak bir oluşturma eylemi kullanır. Controller’da yeni konfigürasyon
oluşturma işlemini CRUD eylemlerini kullanılarak API aracılığıyla gerçekleştirilir.
HTTP, kısmen REST ile iyi çalışır çünkü HTTP, CRUD paradigmasındaki genel
program eylemleriyle eşleşen Verb’lere sahiptir. Tablo 47-1 HTTP Verb ve CRUD
terimlerini listeler.
Tablo 47-1 Comparing CRUD Actions to REST Verbs
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

Data Modelleme ve JSON XML

Data modelleme dilleri bir metni bir ağ üzerinden gönderebilmek veya bu metni Genişletilebilir Biçimlendirme Dili (XML), daha eski biçimlendirme dilleri için bazı

bir dosyada depolamak amacıyla değişkenleri tanımlamak için metni kullanma iyileştirmeler yapmak için daha sonra geliştirildi. Bir web sayfasında kullanılacak

yöntemleri sağlar. Data modelleme dilleri bize değişkenleri herhangi bir belirli değişkenleri tanımlayabilecek bir biçimlendirme diline ihtiyacı vardı. XML,

programlama dili tarafından kullanılan dahili gösterimler yerine metinle temsil değişkenleri, değerleri ve veri yapılarını tanımlamak için birçok özelliğe sahip bir

etmenin bir yolunu sunar. biçimlendirme dilini tanımlar.

Her Data modelleme dili API sunucularının verileri döndürmesini sağlar, böylece
API istemcisi API sunucusunda bulunan veri yapılarının yanı sıra aynı değişken
adlarını çoğaltabilir. Veri yapılarını açıklamak için veri modelleme dilleri liste
değişkenleri, sözlük değişkenleri ve diğer daha karmaşık veri yapıları hakkındaki
fikirleri ileten özel karakterler ve kurallar içerir.
XML ile JSON karşılaştırıldığında, her ikisi de insanlar tarafından okunabilir olmaya
çalışır, ancak XML’i okumak biraz daha zordur. Örneğin, HTML gibi, XML de
aşağıdaki şekilde görüldüğü gibi her değişken için başlangıç ve bitiş etiketleri
kullanır. Örnekteki vurgulanan satırda, <macAddress> ve </macAddress> etiketlerin
arasında bulunan değerle bir değişken adını belirtir.

Data Modelleme Dilleri

JSON
JavaScript Object Notation, insan ve makine okunabilirliği arasında bir denge
kurmaya çalışır. Aynı zamanda JSON verileri, programların JSON metnini
değişkenlere dönüştürmesini kolaylaştırarak API'leri kullanan uygulamalar arasında
veri alışverişi için çok yararlı hale getirir.

JSON'un ayrıntılarını IETF RFC 8259'da ve www.json.org dahil olmak üzere İnternet
aramalarında bulunan bir dizi sitede bulabilirsiniz.

I CCNA Eğitimi 200-301

by Yavuz BULUT
Örnek 47-1 JSON Output from a REST API Call
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

YAML (Ain’t Markup Language)

XML işaretleme ayrıntılarını tanımlamaya çalışır ama YAML, işaretleme ayrıntılarını
tanımlamaya çalışmaz. Bunun yerine YAML, veri modeli (yapı) ayrıntılarına
odaklanır. YAML ayrıca temiz ve basit olmaya çalışır. YAML Data modelleme dilleri
içinde okuması en kolay olanıdır.

Tablo 47-2 Data Modelleme Dillerini Karşılaştırma

Örnek 47-2 YML File Used by Ansible

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

JSON'u Yorumlama
JSON komut satırı hakkında hiçbir şey bilmeden bile Cisco Router ve Switch’ler
hakkındaki önceki bilgilerinizden muhtemelen anlayabilirsiniz. Aşağıdaki örnek de
JSON komut satırında iki cihazdaki Interface’lerin bir listesini gösterdiğini
muhtemelen anlayabilirsiniz.
■ Value: İki nokta üst üste işaretinden sonra, key değerini temsil eden öğe.
■ Metin(Text): Çift tırnak içinde listelenmiştir.
■ Sayısal(Numeric): Tırnak işaretleri olmadan listelenir.
■ Dizi(Array): Özel bir değer [ ]
■ Nesne(Object): Özel bir değer { }
■ Multiple Pairs: Multiple Key Value çiftini listelerken, çiftleri virgülle ayırın
her çiftin sonu (son çift hariç).

Bu kurallardan bazılarıyla çalışmak için Örnek 47-4’nin JSON verilerini göz önünde
Örnek 47-3 Router Interface’lerini Listeleyen Basit JSON
bulundurun ve üç Key: Value Pairs odaklanın. Örnekten sonraki metin, örneği analiz
edecektir.
JSON Key Yorumlama: Value Pairs
Bağımsız değişken adları ve değerleri olarak düşünebileceğiniz JSON'daki Key:
Value Pairs: ilgili şu kuralları gözden geçirelim.

■ Key: Value Pairs: İki nokta üst üste işaretinden önce ve iki noktadan sonraki
Örnek 47-4 One JSON Object (Dictionary) with Three Key:Value Pairs
değerle bir Key: Value Pairs’i tanımlar.
■ Key: İki nokta üst üste işaretinden önce, çift tırnak içinde, bir değere gönderme
Diğer özel karakterlere gelince, virgüllere ve süslü parantezlere dikkat edin. İlk iki
yapan ad olarak kullanılan metin.
Key: Value Pairs: virgülle biter, yani onu başka bir Key: Value Pairs: izlemelidir. JSON
verilerini başlatan ve sonlandıran süslü parantezleri, tek bir JSON Object’i belirtir.

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

JSON Objects ve Arrays Yorumlama

Veri yapılarını basit bir değerle Key: Value Pairs: ötesinde iletmek için JSON Object
ve JSON Array’leri kullanır. Object biraz esnek olabilir, ancak çoğu kullanımda bir
sözlük gibi davranırlar. Diziler (Arrray) bir dizi değeri listeler. JSON Object ve Array
Örnek 47-5 A JSON Snippet Showing a Single JSON Array (List)
için komut satırının nasıl yorumlanacağına bakalım.

■ { } - Object (Nesne): Bir süslü parantez çifti içine alınmış bir Array ve Key: Value Şimdi, Şekil 47-4'deki JSON verilerinin tüm yapısını düşünün. Metni başlatmak ve
Pairs’den oluşur. bitirmek için eşleşen bir çift süslü parantez vardır ve bir nesneyi (Object) içine alır.
■ [ ] - Array (Dizi): Köşeli parantez çifti içine alınmış bir dizi değer (Key: Value Pairs) Bu nesne iki tane iki nokta üst üste içerir, bu nedenle nesnenin içinde iki Key: Value
değil.. Pairs: vardır.
■ Key (Anahtar): Bir nesnenin (Object) içindeki tüm Key: Value Pairs’ler önceki Key:
Value Pairs’in kurallara uyar.
■ Value Inside Arrays (Dizilerin içindeki değerler): Örneğin, metnin etrafında çift
tırnak, sayıların etrafında tırnak işareti yoktur).

Örnek 47-5, JSON formatında tek bir diziyi (Array) göstermektedir. JSON verilerinin
köşeli parantez [ ile başladığına ve ardından üç metin değerini listelediğine dikkat
edin. Daha sonra bir köşeli parantez ] ile biter.

Şekil 47-4 Accurate/Complete JSON Data with One Object, Two Keys, Two JSON List Values
I CCNA Eğitimi 200-301
by Yavuz BULUT
 BÖLÜM - 14 47 I REST ve JSON'u Anlamak

Kısaltılmış ve Düzgün JSON

JSON, ihtiyaçlarınıza bağlı olarak boşluklara izin verir veya vermez. İnsanlar için,
boşlukla organize edilmiş ve hizalanmış metinlerle JSON okumak çok daha kolay
olabilir. Örneğin, eşleşen açılma ve kapanma parantezlerinin aynı satırda
bulunması, hangi parantezlerin hangisiyle bittiğini bulmayı çok daha kolay hale
getirir.

{"1stbest": "Messi", "2ndbest": "Ronaldo", "3rdbest": "Pele"}

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14

48
Ansible, Puppet ve I Ansible, Puppet ve Chef Temelleri

Chef'i Anlamak
I Yapılandırma Yönetim Araçlarının Özeti

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14 48 I Ansible, Puppet ve Chef'i Anlamak

Ansible, Puppet ve Chef Temelleri

Ansible, Puppet ve Chef yapılandırma ve yönetim yazılım paketleridir. Bu yazılım ■ Templates (Şablonlar): Jinja2 dilini kullanan şablonlar, değişkenlerle birlikte bir

araçlarının ücretli ve ücretsiz versiyonları vardır, ancak bazı araçlar Windows işletim cihazın yapılandırmasını temsil eder.

sisteminde çalışmadığı için Linux üzerinde çalıştırmanız gerekebilir.
Bu üç yazılım aracıda donanım tabanlı sunuculardan sanallaştırılmış sunuculara
geçişin bir parçası olarak ortaya çıktı. Sanal Sunucuların sayısı artmaya başlayınca
VM'leri oluşturmak, yapılandırmak ve kaldırmak için çeşitli otomasyon yazılımlarına
ihtiyaç doğdu.
Ansible
Ansible'ı (www.ansible.com) yazılımını kurmanız için Mac, Linux veya bir Windows
‘da bir Linux VM üzerine kurabilirsiniz. Ücretsiz açık kaynak sürümünü kullanabilir
veya ücretli Ansible Tower sunucu sürümünü kullanabilirsiniz. Kurulduktan sonra
aşağıdakiler gibi birkaç dosya oluşturulur:
■ Variables (Değişkenler): YAML kullanılarak, bir dosya Ansible'ın şablonlara ikame
edeceği değişkenleri listeleyebilir.
Ansible, ağ cihazlarını yönetmek için aracısız bir mimari kullanır. Ansible'ın ağ
cihazında çalışan herhangi bir koda (aracıya) güvenmediği anlamına gelir. Bunun
yerine Ansible, ağ cihazlarında değişiklikler yapmak ve bilgi almak için SSH veya
NETCONF özelliklerini kullanır. SSH kullanılırken, Ansible’da kullanıcılarının yaptığı
gibi cihazda değişiklikler yapar, ancak işi bir insan yerine Ansible koduyla yapar.
Ansible, pull (çekme-veri alma) modeli yerine Şekil 48-1’de gösterildiği gibi Push
(itmek- veri göndermek) modelini kullanır (Puppet ve Chef pull modelini kullanır).
Ansible'ı kurduktan sonra Playbooks ve diğer Ansible dosyalarını oluşturmanız ve
düzenlemeniz gerekir.

■ Playbooks (Başucu Kitapları): Bu dosyalar Ansible'ın ne yapması gerektiğiyle ilgili

eylemler ve mantığı sağlar.
■ Inventory (Envanter): Bu dosyalar, Ansible'ın envanterin alt kümeleri için işlevleri
yerine getirebilmesi için her bir cihazla ilgili bilgilerle birlikte cihaz adlarını sağlar.

I CCNA Eğitimi 200-301 Şekil 48-1 Ansible Push Model

by Yavuz BULUT
 BÖLÜM - 14 48 I Ansible, Puppet ve Chef'i Anlamak

Puppet
Puppet (www.puppet.com) kullanmak için bir Linux işletim sistemine kurarak
başlayabilirsiniz. Test için kendi Linux sunucunuza kurabilirsiniz ama normal
kullanım için onu Puppet master adlı bir Linux sunucusuna kurmanız gerekir.
Ansible'da olduğu gibi, ücretli veya ücretsiz sürümleri kullanabilirsiniz. Öğrenmek
ve test etmek için ayrı bir sunucu olmadan Puppet'i öğrenmeye başlayabilirsiniz.
Puppet yüklendikten sonra, aşağıdakiler gibi farklı bileşenlere sahip birkaç önemli
metin dosyası da kullanır:
Puppet, ağ cihazları desteği için tipik olarak aracı tabanlı bir mimari kullanır. Bazı ağ
cihazları cihaz üzerinde bulunan bir araç aracılığıyla Puppet desteğini etkinleştirir.
Ancak her Cisco işletim sistemi Puppet aracılarını desteklemez, bu nedenle Puppet
bu sorunu bazı harici bilgisayarlarda çalışan bir proxy aracı kullanarak çözer
(Agentless işlem olarak adlandırılır). Harici aracı daha sonra, Şekil 48-2’da
gösterildiği gibi, ağ cihazı ile iletişim kurmak için SSH kullanır.

■ Manifest: Bir cihazın yapılandırma durumunu Puppet master'da insan tarafından

okunabilmesini sağlayan bir metin dosyasıdır.
■ Resource, Class, Module: Bu terimler manifestin bileşenlerini ifade eder.
■ Templates: Puppet’a özgü bir dil kullanan bu dosyalar, Puppet'in şablonlarda
değişkenleri değiştirerek bildirimler (ve modüller, sınıflar ve kaynaklar)
oluşturmasına izin verir.

Şekil 48-2 Agent Tabanlı ve Agent’sız Puppet Operasyon

I CCNA Eğitimi 200-301

by Yavuz BULUT
 BÖLÜM - 14
Puppet aracı (Agent) cihazda daha önceden etkinleştirilmelidir, aşağıdaki şekilde
gösterildiği gibi bu yapılandırmanın aygıtta görünmesini sağlamak için Pull
modeli kullanır. Yüklendikten sonra bu adımlar gerçekleşir
Adım 1: Puppet sunucusundaki tüm dosyaları oluşturur ve düzenlersiniz.
Adım 2: Her cihaz üzerindeki aracıyı veya bir proxy aracısını yapılandırmanız ve
etkinleştirmeniz gerekir.
Adım 3: Agent, sunucudan bildiri ayrıntılarını çeker ve bu da Agent’a
yapılandırmasının ne olması gerektiğini söyler.
Adım 4: Agent cihaz yapılandırmasının güncellenmesi gerekiyorsa, Puppet aracı,
cihaz yapılandırmasını güncelleyen aracı ile gerekli tüm ayrıntıları almak için ek
çekimler gerçekleştirir.
Şekil 48-3 Pull Model with Puppet
I CCNA Eğitimi 200-301
by Yavuz BULUT
48 I Ansible, Puppet ve Chef'i Anlamak
Chef
Chef (www.chef.io), Ansible ve Puppet'te olduğu gibi, kurduğunuz ve çalıştırdığınız
bir yazılım paketidir. Chef şirketin birçok ürünü vardır, Chef Automate yazılımı ise
çoğu insanın basitçe Chef olarak adlandırdığı üründür. Puppet'te olduğu gibi
Chef’de yazılımını da bir sunucuya yükleyerek çalıştırırsınız.
Chef yazılımını yüklendikten sonra aşağıdakiler gibi farklı bileşenlerle birkaç metin
dosyası oluşturursunuz:
■ Resource: Chef tarafından yönetilen yapılandırmarı yönetilen nesnelerdir.
■ Recipe: Kaynaklara ne zaman ve nasıl hareket edip etmeyeceğini belirlemek için
uygulanan Chef mantığı.
■ Cookbooks: Daha kolay yönetim ve paylaşım için gruplandırılmış aynı tür işler için
bir dizi kolaylıklar sağlar.
■ Runlist: Belirli bir cihazda çalıştırılması gereken Recipe’ların sıralı bir listesi.
Chef Puppet'e benzer bir mimari kullanır. Ağ cihazları için bir agent çalıştırır. Cisco
cihazının bir Chef istemcisini desteklemediğini için Ansible ve Puppet'in daha fazla
kullanılmaktadır.
 BÖLÜM - 14 48 I Ansible, Puppet ve Chef'i Anlamak

Yapılandırma Yönetim Araçlarının Özeti

Burada listelenen yapılandırma yönetim araçlarının üçü de iyi bir kullanıcı
tabanına ve farklı güçlü yönlere sahiptir. Ağ cihazlarının yapılandırmasını
yönetmek için en yaygın olarak Ansible kullanılandır, ardından Puppet ve Chef
gelir. Ansible’ın Agent’sız mimarisi ve SSH kullanımı ile bir çok Cisco cihazını
destekler Puppet’ın Agent’sız modeli de Cisco cihazları için geniş destek sağlar.

Tablo 48-1 Ansible, Puppet ve Chef Karşılaştırması

I CCNA Eğitimi 200-301

by Yavuz BULUT
Teşekkürler.
Eğitim konuları ile ilgili sorularınız
için bana Udemy soru cevap
bölümünden ulaşabilirsiniz.

www.udemy.com

Diğer kurumsal hizmetler için web

sitem üzerinden ulaşabilirsiniz.

www.yavuzbulut.com