Azure Storage Account – Blob Storage Kavramı ve Oluşturma işlemleri

Özdemir Mustafa 29/11/2021

2 13 dakika okuma süresi

Storage Account yani Depolama hesabı olarak geçmektedir. Storage Account, Verileriniz için benzersiz bir azure ad alanı olarak tanımlayabiliriz. Bu sakladığınız her nesnenin Azure Depolamada yani Stroage’da bir web adresi mevcuttur. Bu web adresi Benzersiz Storage Account adınızı içermektedir. Depolama hesabınıza verdiğiniz ad, Ana web adresi olmaktadır.

Storage Account ve Unique Azure Namespaces birbiryle bütünleşik bir kavram olduğunun bilgisini vermek isterim.

Depolama Hesabı = Benzersiz Azure Ad Alanı açıklayabiliriz.

Daha iyi anlayabilmek adına ;

Yapımızda oluşturacağımız yada oluşturacağımız Stogare Account’umuz örnek olarak Özdemir olsaydı , Depolama ad Alanı veya adresi aşağıda gösterildiği gibi o formatta olurdu. Bu Aynı zamanda Depolama Hesabınızın adı anlamına gelmektedir. Azure ortamında benzersiz olması gerekmektedir. Aksine bu durum problem yaratabilir.

ozdemir.<storage type>.core.windows.net

Storage Account yani Depolama Hesabı, Tüm Azure Depolama türlerinin temeli olarak tanımlanabilmektedir. Azure Storage servisini organizasyonunuzda kullanabilmeniz için önce veri objelerinizi depolama işlemi gerçekleştirebilmeniz için Azure Storage Account oluşturmanız gerekmektedir. Azure Portal , Azure Powershell veya Azure CLI arayüzlerinden Azure Storage Account oluşturma işlemlerinizi gerçekleştirebilirsiniz.

Şimdi bunlar ilk olarak bilgi olarak aklımızda kalsın. Bunun yanında Azure Storage Account oluşturma işlemi sağladıktan sonra Blob Storage oluşturma işlemi sağlayacağız. Onun için detaylı olarak Blob Storage mimarisinden , Nerelerde kullanılmaktadır daha detaylı olarak aşağıda bahsediyor olacağız. O halde hemen başlayalım :

Blob kavramının açılımı Binary Large Object olarak diyebiliriz. Peki Blob Ne anlama gelmektedir. Bunu açıklayalım. Blob , Günümüzde kullanılan en yaygın terimlerden biridir. ” İkili Büyük Nesne “ olarak geçmektedir. Diğer bir açıklama yapmak gerekirse ; Blob kavramını , Bit ve Byte’lardan oluşan hemen hemen herşey olarak tanımlayabiliriz. Yani bir anlama Blob , Veri Bloğu olarak da anılabilmektedir. Bu Veri Blokları Storage Account yani Depolama hesabının içindeki Container’larda muhafaza edilmektedir. Buradan Blob Storage mimarisinin üç katman olduğunu çıkarabiliriz. Storage Account , Container ve Blob üçlüsü .

Azure Yapınızdaki Azure Storage Account’unuzda birden çok Blob Container olabilmektedir. Bunların içeriğinde verilerinizi depolayabilirsiniz. Örnek vermek gerekise ; Bir kutu , Container bir Blob Container olsun , Kutunun içeriğinde her ne olursa olsun, Dışarıdan istediğim verileri bu Blob öğesinin içine koyabiliyorum. Hangi türde bir veri oldukları yada Hangi boyutta bir veri olduklarının bir önemi yok. Bu Blobların veya öğelerin her birinin benzersiz bir adresi olacağını yukarıda söylemiştim. Örnek olarak kutumuzun içeriğindeki herhangi bir veriyi almak istiyorum :Kutunun içeriğindeki verilerimizi doğrudan ve hızlı bir şekilde sorunsuz bir şekilde alabiliriz. Yani burada dikkat etmemiz gereken nokta bu verilerimizin Tam olarak nerede olduklarını görebilir, bulabilir ve bilebiliriz. Yani Şöyle Blob Container düşünün , Karışık bir Sepet olarak hepsi Logic halde yani Mantıklı bir şekilde baştan aşağı tag’lenmiş halde yani etiketlenmiş diyebiliriz.

Blob Storage , çok yönlü kullanıcılacak şekilde tasarlanmıştır.

Peki Nerelerde Kullanabiliriz ?

Her çeşit dosyayı muhafaza edebilir ve Distributed yani Dağıtılmış erişim sağlayabilirsiniz.
Video ve Ses Akışı
Ortamınızdaki Log istediğiniz ortamları için Günlük Dosyalara Yazma işlemleri
Yedekleme ve Geri yükleme gibi işlemler ve Felaketten kurtarma , verilerin arşivlenmesi.
İmage’lar genellikle çeşitli farklı boyut ve biçimdedirler ve Blob Storage, Bunları doğrudan bir Browser’a depolamayı sağlamaktadır.

Azure Storage , üç çeşit Blobu desteklemektedir :

Block Blob
Append Blob
Page Blob

Bunları açıklamak gerekirse ;

Block , Blokları ve ikili verileri yaklaşık 4,7 TB’a kadar depolamayı desteklemektedir. Block Blob’ları , Veri bloklarından oluşmaktadır. Bireysel olarak yönetilebilmektedir.
Append ( Ekleme ) Blob’ları , Block blobları gibi bloklardan oluşur. Ancak ekleme işlemleri için optimize edilmiştir. Append Blob , sanal makinelerden veri kaydetme gibi senaryolar için gerçekten çok iyi çalıştığını söyleyebilirim.

Page ( Sayfa ) Blob’ları , 8 TB’a kadar Rastgele erişim dosyalarını depolamayı desteklemektedir. Dosyanın herhangi bir bölümünün herhangi bir zamanda erişilebilir durumda olduğunu vurgulamak isterim. Bu Page Blob’ları sanal bir sabit sürücüye depolanabilmektedir. Örnek verirsek; bir VHD dosyasına. Azure ortamındaki Sanal Makine için disk olarak hizmet verebilme imkanına sahipsiniz.

Blob Storage için 3 Adet Maliyetlendirme söz konusu bunları sıralayarak , açıklamak gerekirse ;

Ortamınızda Sık Sık eriştiğiniz Dosyalar mevcutsa Hot Tier tam size göre. Bu Katman Daha düşük erişim sürelerine ve daha yüksek erişim maliyetlerine sahiptir.

Ortamınızda Daha düşük depolama maliyeti istiyorsanız Cool Tier tam size göre .Bu katman Hot Tier’e göre kıyaslandığında High Availability yani Yüksek Erişilebilirlik sunmaktadır. Bu katman genellikle 30 Gün boyunca kalıcı verileriniz için tasarlanmıştır.

En düşük maliyete ve en yüksek erişim sürelerine sahip Archive Tier. Kalıcı ve arşivlemeniz gereken dosyaları bu katmana alabilirsiniz.

Şimdi bu anlattıklarımızı Azure Portal üzerinden adım adım uygulayalım. Yapacağımız işlemleri ilk öncelik sıralamak istiyorum :

Yukarıda belirtildiği gibi Azure Blob Hizmetini kullanabilmek için Bir Azure Storage Account oluşturacağız.
Storage Account’umuzun Blob Servisi içinde images block container’ı oluşturacağız. Ardından bu İmage’leri adlandırıyor olacağız.
Blob yükleme işlemi gerçekleştireceğiz.

O halde Başlayalım:

İlk olarak Azure Portalına gireriz . Sonrasında Storage Account ile alakalı konfigürasyonları sağlarız. İlk olarak arama çubuğumuza ” Storage Accounts ” kaynağını yazarız. Hizmetler kısmından ilgili seçeneği seçeriz.

Storage Account oluşturma işlemi için ” Create “ seçeneğini yada aşağıdaki ” Create storage account “ seçeneğini seçeriz.

” Basics “ adımında Azure ortamımızda bulunan ” Subscription’umuzu “ seçeriz. Ardından oluşturacağımız Storage Account’umuzun hangi ” Region “ olacağını seçeriz. Ortamınızda Resource Group mevcut değilse Checkbox altındaki ” Create New “ seçeneğini seçeriz.

” Storage Account Name “ kutucuğuna Storage Account oluşturma işlemlerinde problem çıkmaması adına benzersiz bir isimlendirme sağlamanız gerekmektedir. Bu isimlendirme 3 ile 24 karakter uzunluğunda ve sadece Küçük harf ve rakamlarla oluşturulmalıdır. Yapınıza göre veya isteğinize göre isimlendirme sağlayabilirsiniz. Ben ” ozdemir “ ismini vereceğim.

” Region “ bölümünde ise Storage Account’umuzun hangi bölgede olmasını istersek onu seçeriz. Yapınıza ve isteğinize göre Region konfigürasyonu sağlayabilirsiniz. Region’lardaki seçiminiz ” Redundancy “ seçeneklerinin daha da çeşitlenmesine sebep olabilmektedir. ” LRS (Locally Redundant Storage ) , GRS (Geo-redundant Storage ) dışında , ZRS ( Zone Redundant Storage ) , GZRS ( Geo-zone-redundant Storage ) “ gibi yapılarda seçilebilir hale gelmektedir.

” Performance “ bölümünde ise ” Standart “ seçeneğinin yanındaki kutucuğu işaretleriz. Yani Standart Genel Amaçlı v2 Storage Account şeklinde seçerek ilerleriz. Bu seçenekleri seçerek , Storage Account Block Blob’ları , Dosya Paylaşımları veya Page Blob’ları için üstün performansa sahip olmak isteyip istemediğimizi belirleriz.

” Redundancy “ bölümünde ise ” Locally -redundant storage ( LRS ) “ seçeneğini seçeriz. Yani Yerel olarak Yedekli Depolama anlamına gelmektedir.

” Next : Advanced > “ seçeneğini seçerek ” Advanced “ aşamasına geçeriz.

” Storage Account Name “ kutucuğuna Storage Account oluşturma işlemlerinde problem çıkmaması adına benzersiz bir isimlendirme sağlamanız gerekmektedir. Bu isimlendirme 3 ile 24 karakter uzunluğunda ve Sadece Küçük harf ve rakamlarla oluşturulmalıdır. Yapınıza göre veya isteğinize göre isimlendirme sağlayabilirsiniz. Ben ” ozdemir “ ismini vereceğim.

” Redundancy “ bölümünde ise ” Locally -redundant storage ( LRS ) “ seçeneğini seçeriz. Yani Yerel olarak Yedekli Depolama anlamına gelmektedir.

” Next : Advanced > “ seçeneğini seçerek ” Advanced “ aşamasına geçeriz.

” Advanced “ adımında ise ilk olarak ” Security “ bölümündeki konfigürasyonları kısaca açıklıyor olacağız.

” Require secure transfer for REST API operations ” seçeneği Güvenlik Aktarım seçeneği olarak geçmektedir. Bu seçeneği aktifleştirme işlemi sağladığınızda HTTP’leri kullanan Storage Account sadece REST API işlemlerine izin vererek Storage Account’uzun güvenliğini arttırabilirsiniz. Bu konfigürasyonu etkinleştirdiğinizde , HTTP isteklerinin hepsi reddedilecektir. Şunu hatırlatmak isterim : Azure Storage , Size Özel Domain isimleri için HTTP’leri desteklemediğinden , özel bir Domain İsimleri kullanırken bu seçenek işaretli olsa dahi uygulanmaz. Son olarak TCP Protokolü üzerinden yapınızdaki Blob’larınız için NFSv3 ( Network File System Version 3 ) aracılığıyla yapılan bağlantılar problemsiz gerçekleşir. Fakat yapınız için Pek Güvenli olmadığının bilgisini vermek isterim.

” Enable infrastructure encryption “ seçeneği ise Altyapı Şifrelemesi olarak geçmektedir. Yapınızdaki Storage Account’unuzun verilerine alternatif bir Şifreleme katmanı dahil etmektedir. Fakat Microsoft Azure , Default olarak Storage Account verilerini şifreleme işlemlerini sağlamaktadır.

” Enable blob public access “ seçeneğinde ise oluşturacağınız yada oluşturduğunuz Blob’u Public Erişime açmaktadır. İlgili özelliği yapınızda etkinleştirme işlemi sağladığınızda , yapınızdaki Storage Account içindeki blob’lara Everyone erişime izin vermek için Container’ların Access Control List’lerin yapılandırılmasına izin verilmektedir. Devredışı bırakıldığında , Temel Access Control List yapılandırmalarından bağımsız olarak , Storage Account içindeki Blob’larınıza everyone erişim izini geçersiz olmaktadır.

” Enable Storage account key access “ seçeneğinde ise oluşturacağınız veya oluşturduğunuz Storage Account için Key erişimi Devredışı bırakıldığında , Shared Access Signatures ( SAS ) yani Paylaşılan Erişim imzaları dahil olmak üzere, Shared Key ile Yetkilendirilen Account’lara gelen tüm istekler reddedilmektedir. Etkinleştirme gerçekleştirdiğinizde , Shared Key kullanarak Storage Account’a erişim sağlayan Client’ınız Uygulamaları çalışamaz hale geldiğini hatırlatmak isterim. Bu seçeneği Default halde bırakarak ilerleriz.

” Default to Azure Active Directory authorization in the Azure Portal ” seçeneğinde ise etkinleştirme sağladığınızda Azure Portalınızda Default olarak Azure Active Directory ile Blob’lara , Kuyruklara ve Tablolara yönelik isteklerin yetkilendirilmesi sağlanmaktadır.

” Minumum TLS version “ seçeneğinde ise Storage Account’unuza ait verileri kullanan Uygulamalarınız için gereken Minumum TLS sürümünü konfigüre edebilirsiniz. Seçeneklerde , ” Version 1.0 , Version 1.1 ve Version 1.2 “ bulunmaktadır. Ortamınızdaki güvenliği ve Uygulamanızın uyumluluğu açısından TLS 1.2 şeklinde konfigürasyon sağlamak yararınıza olacaktır.

” Advanced “ adımındaki konfigürasyonlara devam ediyoruz.

” Data Lake Storage Gen2 “ Hiyerarşik Ad Alanı olarak anılmaktadır. Büyük Veri Analizi yöntemiyle kullanılan iş yüklerinize büyük ölçüde ivme kazandırmakta ve Dosya Seviyesinde tanımlamış olduğunuz ACL’leri etkinleştirmektedir.

” Secure File Transfer Protocol ) “ Güvenli Dosya Transferi Protokolü olarak anılmaktadır. Organizasyonunuzdaki kullanıcılarınızın bu SFTP aracılığıyla Blob’lara erişmesine imkan sağlamış olursunuz , oluşturduğunuz yada oluşturacağınız Storage Account’unuz için SFTP Protokolünü devreye almaktadır. Ortamınızda STFP erişimleri için yapınızda Local User’ları oluşturulması gerekmektedir. ” Enable SFTP “ seçeneğinin konfigüre edilemediğini görürüz. Bunun nedeni Hiyerarşik ad alanı Account’larımız için Subscription seviyesinde etkinleştirme sağlamadığımız için konfigüre edilememektedir.

” Blob Storage “ bölümünde ise ” Enable network file system v3 “ seçeneğininde konfigüre edilemediğini görürürüz. Bunun nedeni ilk önce ortamınızda Hiyerarşik Ad Alanı etkinleştirilmemesinden kaynaklıdır. Etkinleştirme sonrası , konfigürasyon ve etkinleştirme işlemlerini gerçekleştirebilirsiniz.

” Allow cross-tenant replication “ seçeneğinde ise Nesne Replikasyonunu farklı Azure Active Directory Tenant’ındaki oluşturduğunuz yada oluşturacağınız User Acount’a replike edilmesini sağlayabilirsiniz. Tenant’ler arası Replikasyonu devredışı bırakmak ise , Yapınızdaki aynı Azure AD Tenant içerisinde bulunan nesnelerin replikasyonuna sınır koymaktadır.

” Access Tier “ Hesap Erişim Katmanı olarak anılmaktadır. Bu seçenektekiler ise yukarıda açıkladığım gibi ” Hot “ ve ” Cool “ gibi senaryolar mevcuttur. Bunlardan tekrardan bahsetmek gerekirse ;

Sık Sık eriştiğiniz Dosyalar için Hot Tier , Bu Katman , Daha düşük erişim sürelerine ve daha yüksek erişim maliyetlerine sahiptir.

Daha düşük depolama Maliyetine sahiplik için Cool Tier, Bu Katman Hot Tier’e göre kıyaslandığında Yüksek Erişilebilirlik sunmaktadır. Bu katman genellikle 30 Gün boyunca Kalıcı Verileriniz için tasarlanmıştır.

Bunları kıyaslarsak , Hot Katmanı , Sık erişilen veriler için idealdir . Cool Katmanı ise , Seyrek erişilen veriler için idealdir.

Bunlardan üçüncü olarak Archive Katmanıda mevcut . Fakat bu erişim katmanı , Account seviyesinde değil , Sadece Blob seviyesinde Konfigüre edilebilmektedir.

” Hot “ olarak konfigüre ederek , işlemlerimize devam ederiz. ( Yapınıza göre ve ihtiyacınıza göre konfigürasyon sağlamak yararınıza olacaktır. )

” Azure Files “ bölümünde ise Maksimum 100TiB’a kadar dosya paylaşımını desteklenmektedir. Konu açılmışken şunu da belirtmek istiyorum : Büyük Dosya Paylaşımlı Storage Account’lar Coğrafi olarak yedekli Depolama yapılarına dönüştürülememektedir. ” Table and queues “ bölümünde ise etkinleştirme işlemi sağladığınızda Yapınızdaki SQL Veritabanınızdaki Dosyaları yani Tabloları ve Kuyrukları güvenlik amacıyla şifreleme işlemi sağlamaktadır.

Etkinleştirme işlemi sağlandıktan sonra Storage Account oluşturma işlemi tamamlandıktan sonra konfigürasyon değiştirilemediğinin bilgisini vermek isterim. Konfigüre işlemi sağlamanız esnasında değiştirilememe durumunu göz önünde bulundurmalısınız.

Bir sonraki ” Networking “ adımına geçmek için ” Next : Networking > “ seçeneğini seçerek devam ederiz.

” Network connectivity “ bölümünde ” Connectivity Method “ konfigürasyonlarında ;

Storage Account’unuza genel olarak , Public IP adresleri veya Service Endpoint aracılığıyla veya Private Endpoint kullanarak özel olarak bağlanabilirsiniz. Şunu belirtmek istiyorum ki : ” Public endpoint ( all networks ) “ seçeneğini seçersek , Tüm Ağlar bu Storage Account’a erişebilecek. Fakat tavsiye edilen, Bu kaynağa ağınızdan Özel olarak erişmek isterseniz , ” Private endpoint “ seçeneğini seçebilirsiniz.

” Public Endpoint ( all networks ) “ seçeneğini seçerek devam ederiz. ( Yapınıza veya ihtiyacınıza göre uygun olanı belirlemeniz yararınıza olacaktır. )

” Network routing “ bölümünde kaynaktan Azure Endpoint noktasına giderken trafiğinizi belirleyebilirsiniz. Çoğu Organizasyonlar için önerilmektedir. ” Routing prefence “ konfigürasyonlarında ise ” Microsoft Network Routing ” seçeneğini seçtiğinizde trafiğinizi kaynağından kabul edilebilir sürede Microsoft Bulutuna yönlendiriyor olacaktır. ” İnternet Routing “ seçeneğini seçtiğinizde trafiğinizi Azure Enpoint’e daha yakın Microsoft Bulutuna yönlendiriyor olacaktır.

” Microsoft Network Routing “ seçeneğini seçerek devam ederiz. ( Yapınıza veya ihtiyacınıza göre uygun olanı belirlemeniz yararınıza olacaktır. )

Bir sonraki ” Data protection “ adımına geçmek için ” Next : Data Protection > “ seçeneğini seçerek devam ederiz.

” Data Protection “ bölümünde ” Recovery “ alanında ortamınızdaki verilerinizin sehven silinmesini veya değiştirilmesine karşı korumanızı sağlamak için konfigürasyonlar yer almaktadır.

” Enable point-in-time restore for containers “ seçeneğininin yanındaki kutucuğu işaretlediğinizde bir veya daha fazla Container’e daha önceki durumuna geri dönmek için Checkpoint ( Bazen Snapshot olarak da anılmaktadır. ) denen kavramı burada belirlemiş olduğumuz konfigürasyona göre geri dönebiliriz. Ayrıca bu seçeneği etkinleştirdiğinizde , Versiyon oluşturma ve Blob Soft Delete işlemlerini gerçekleştirebilirsiniz.

” Enable soft delete for blobs “ seçeneği ise Geçici silme olarak anılmaktadır. Üzerine yazılan Blob’larda dahil olmak üzere , yapınızda daha önceki silinecekler olarak belirlenmiş Blobları kurtarmanıza imkan tanımaktadır. Bu bölümde etkinleştirme işlemi gerçekleştirdiğinizde ” Days to retain deleted blobs “ seçeneğinde kutucukta belirlemiş olduğunuz değer , Silinmek üzere işaretlenen yapınızdaki Blobun kalıcı olarak silinene kadar devam edeceği gün sayısını konfigüre etmiş oluruz. Default değer olarak ” 7 gün ” olarak belirleriz.

” Enable soft delete for containers “ seçeneği ise Geçici silme olarak anılmaktadır. Üzerine yazılan Blob’larda dahil olmak üzere , yapınızda daha önceki silinecekler olarak belirlenmiş Container’ları kurtarmanıza imkan tanımaktadır. Bu bölümde etkinleştirme işlemi gerçekleştirdiğinizde ” Days to retain deleted containers “ seçeneğinde kutucukta belirlemiş olduğunuz değer , Silinmek üzere işaretlenen yapınızdaki Container’ın kalıcı olarak silinene kadar devam edeceği gün sayısını konfigüre etmiş oluruz. Default değer olarak ” 7 gün ” olarak belirleriz.

” Enable soft delete for file shares ” seçeneği ise Geçici silme olarak anılmaktadır. Üzerine yazılan Blob’larda dahil olmak üzere , yapınızda daha önceki silinecekler olarak belirlenmiş Dosya Paylaşımlarınızı kurtarmanıza imkan tanımaktadır. Bu bölümde etkinleştirme işlemi gerçekleştirdiğinizde ” Days to retain deleted file shares “ seçeneğinde kutucukta belirlemiş olduğunuz değer , Silinmek üzere işaretlenen yapınızdaki Dosya Paylaşımının kalıcı olarak silinene kadar devam edeceği gün sayısını konfigüre etmiş oluruz. Default değer olarak ” 7 gün ” olarak belirleriz.

” Data Protection “ bölümünde ” Tracking “ alanında versiyonları yönetmenize ve Blob verilerinizde yapılan değişiklikleri takip etmemizi sağlamaktadır.

” Enable versioning for blobs “ seçeneğini etkinleştirerek , Recovery yani Kurtarma ve Restore işlemleriniz için yapınızdaki Blob’larınızın önceki versiyonlarını otomatik olarak koruma sağlamaktadır.

” Enable blob change feed “ seçeneğini etkinleştirerek , hesabınızda blob’larda oluşturma , değiştirme ve silme değişikliklerinizi takip edebilirsiniz. Etkinleştirme sonrası 2 seçenek karşımıza çıkmaktadır. ” Keep all logs ” ve ” Delete change feed logs after ( in days ) “

” Keep all logs ” seçeneğini seçerek , tüm loglar ortamda kalmalı.

” Delete change feed logs after ( in days ) ” seçeneğini seçerek , etkinleştirme sonrası ne kadar Gün kalmasını belirleyebiliriz.

” Access Control “ alanında ” Enable version-level immutability support “ seçeneğini seçerek , Blob versiyonları için zamana dayalı Bekletme politikaları konfigüre etmenize imkan tanınmaktadır. Account veya Container seviyesinde Default yani varsayılan politikalar konfigüre edilebilmekte veya Belirlemiş olduğunuz Bloblar veya versiyonlar için yapımıza göre politikalar belirleyebilirsiniz. Bu özelliğin Etkinleştirilmesi için versiyon oluşturma işlemini etkileştirmeniz gerekmektedir. ” Tracking “ alanında ” Enable versioning for blobs “ seçeneği aktif olmalıdır. Bir sonraki ” Tags “ adımına geçmek için ” Next : Tags > “ seçeneğini seçerek devam ederiz.

” Data Protection “ bölümünde ” Tracking “ alanında Versiyonları yönetmenize ve Blob verilerinizde yapılan değişiklikleri takip etmemizi sağlamaktadır.

” Enable blob change feed “ seçeneğini etkinleştirerek , Hesabınızda blob’larda oluşturma , Değiştirme ve silme değişikliklerinizi takip edebilirsiniz. Etkinleştirme sonrası 2 seçenek karşımıza çıkmaktadır. ” Keep all logs ” ve ” Delete change feed logs after ( in days ) “

” Keep all logs ” seçeneğini seçerek , Tüm Loglar ortamda kalmalı.

” Delete change feed logs after ( in days ) ” seçeneğini seçerek , etkinleştirme sonrası ne kadar Gün kalmasını belirleyebiliriz.

Bu bölümde oluşturacağınız kaynaklarımıza daha kolay bulunabilmesi için etiketleme standartı belirleyerek , oluşturma işlemlerini gerçekleştirebilirsiniz.

Ardından kaynak oluşturma işlemlerinin başlaması için gerekli kontroller sağlanarak , kaynağımızın oluşması için herhangi bir engel mevcut mu ? Kontroller aşamasına geçmek için ” Next : Review + create > ” seçeneğini seçerek devam ederiz.

” Review + Create ” bölümüde Azure ortamında oluşturduğunuz veya oluşturacağımız Storage Account ile alakalı konfigürasyonlarının özet bilgilerini inceleyerek uygun ise oluşturma işlemlerini sağlayabilirsiniz. ” Validation Passed “ uyarısı aldığımıza göre konfigürasyonlarımızda herhangi bir problem olmadığını görmüş oluruz. Oluşturma işlemlerine başlamak için ” Create “ seçeneğini seçeriz.

Deployment işlemi başladı.

Kaynak oluşturma işlemleri devam etmektedir.

Storage Account oluşturma işlemimiz tamamlanmıştır. Kaynağımızın konfigürasyonu ve arayüzüne gitmek için ” Go to Resource “ seçeneğini seçeriz.

Storage Account kaynağımızın başarılı problemsiz şekilde oluştuğu görmüş oluruz ve adımlarımıza devam ediyoruz. Bir sonraki adımımız konfigürasyonlar bölümünde ” Data Storage “ alanının altındaki Blob hizmetini kullanmak için ” Containers “ seçeneğini seçeriz. Ardından yapımızda yeni bir Container oluşturacaksak yada Storage Account’umuzda oluşturduğumuz veya var olan Container’larımızı görmüş oluruz. Fakat biz User Defined yani Kullanıcı Tanımlı bir kapsayıcı oluşturacağız. Bunun için ” Container “ seçeneğini seçeriz.

” Container “ oluşturma işlemlerinde ” Name “ kısmına depolayacağımız dosyalar ile alakalı isimlendirme sağlayabilmekte özgür olduğunuzun bilgisini vermek isterim. ” Public access level “ alanında ise ” Private ( no anonymous access ) “ seçeneğini seçeriz. ” Public access level “ Container içeriğindeki verilere genel olarak erişilip erişilemeyeceğini belirtmektedir. Varsayılan seçeneği seçmiş olduk. Yani Container verileri hesap sahibine özeldir. Blob’lar için Public Okuma erişimine izin vermek için ” Blob ( anonymoys read access for blobs only ) “ seçeneğini seçebilirsiniz. Tüm Container’a Genel Okuma ve Listeleme erişimine izin vermek için ” Container ( anonymous read access for containers and blobs ) “ seçeneğini seçebilirsiniz.

Ardından oluşturma işlemleri için ” Create “ seçeneğini seçeriz.

Ardından Storage Container kaynağımızın oluştuğunu görmüş oluruz.

Oluşturmuş olduğumuz ” images “ üzerine çift tıklayarak container içeriğine gireriz. Şimdi Blob yükleyerek test ediyor olacağız. Ardından ” Upload “ seçeneğini seçeriz.

Blob olarak eklemek istediğimiz veriyi seçeriz. Bunun için ” Browse “ anlamına gelen klasör simgesine tıklarız. Bilgisayarımızdan ilgili veriyi seçeriz.

Seçtiğimiz dosyanın “Files “ alanına geldiğini görürüz. Ardından Blob’un yüklenmesi için ” Upload “ seçeneğini seçerek devam ederiz.

Yüklediğimiz Blob düşmediyse ” Refresh “ seçeneğini seçerek devam edebilirsiniz.

Yüklediğimiz Blob’un üzerine tıklayarak , içeriğine gireriz ve Blob’umuzun özel olduğunu görmüş oluruz. ” Change access level “ ile Blob’larımızın dışarıdan veya özelden erişilebilirliğini değiştirme imkanına sahip olduğunuzun bilgisini vermek istiyorum.

Blob URL bölümündeki linki kopyalayarak , Browser arama çubuğuna yapıştırırız.

İlgili URL’I Browser adres çubuğuna kopyalayarak eriştiğimizde özel olduğu için Blobu göremeyeceğimiz bilgisini vermektedir. Benimde istediğim özel ve gizli olmasıydı.