Merge pull request #431 from kolaynurdan/add-tr

2022/tr/Days/day33.md

@@ -0,0 +1,180 @@
+## Microsoft Azure Ag(Network) Modelleri + Azure Yonetimi
+
+Bugün Microsoft Azure'nun kuruluşunun ve 12. yıl dönümünün kutlandığı bir gün! (1 Şubat 2022) Neyse ki, Microsoft Azure'daki ağ modellerini ve Azure için bazı yönetim seçeneklerini ele alacağız. Şu ana kadar yalnızca Azure portalını kullandık, ancak platformdaki kaynaklarımızı yönetmek ve oluşturmak için başka alanlar olduğunu da belirttik.
+
+## Azure Network(Ag) Modelleri
+
+### Sanal Aglar(Virtual Networks)
+
+- Sanal Network, Azure'da oluşturulan bir yapıdır.
+- Bir sanal ağın bir veya daha fazla IP aralığı vardır.
+- Sanal ağlar bir bölge içinde bir abonelikte bulunur.
+- Sanal ağlarda, ağ aralığını bölmek için sanal alt ağlar oluşturulur.
+- Sanal makineler sanal alt ağlara yerleştirilir.
+- Bir sanal ağın içindeki tüm sanal makineler birbirleriyle iletişim kurabilir.
+- Her bir Sanal Ağda 65.536 özel IP adresi kullanılabilir.
+- Bir bölgeden çıkan trafiğin bedeli ödenir. (Bölgeden çıkan veri trafiği)
+- IPv4 ve IPv6 desteklenir.
+   - IPv6, halka açık ve sanal ağlar içinde kullanılabilir.
+
+Azure Virtual Networks, AWS VPC'lerine benzetilebilir. Ancak, dikkate alınması gereken bazı farklılıklar vardır:
+
+- AWS'de varsayılan bir VNet (Virtual Network) otomatik olarak oluşturulurken, Azure'da ilk sanal ağınızı gereksinimlerinize göre oluşturmanız gerekmektedir.
+- Azure'da, varsayılan olarak tüm sanal makinelerin internete NAT (Network Address Translation) erişimi vardır. Azure, AWS'deki NAT Gateway'leri gibi NAT ağ geçitleri kullanmaz.
+- Azure'da, AWS'deki gibi özel veya genel alt ağ kavramı bulunmaz.
+- Genel IP adresleri, Azure'da vNIC'ler veya Yük Dengeleyicilere atanabilen bir kaynaktır.
+- Sanal Ağlar ve alt ağlar, kendi ACL'lerine (Erişim Kontrol Listelerine) sahiptir. Bu, alt ağ düzeyinde yetkilendirme yapmanızı sağlar.
+- Azure'da alt ağlar, AWS'deki gibi her bir Kullanılabilirlik Bölgesi için değil, Kullanılabilirlik Bölgeleri arasında yayılabilir.
+
+Ayrıca, Azure'da Sanal Ağ Eşlemesi (Virtual Network Peering) özelliği bulunur. Bu özellik, kiracılar ve bölgeler arasında sanal ağları Azure altyapısı kullanarak birbirine bağlama imkanı sağlar. Bu özellik varsayılan olarak geçişken değildir, ancak hub sanal ağında Azure Güvenlik Duvarı kullanarak etkinleştirilebilir. Sanal ağların bağlantılı ağa bağlanabilmesini sağlamak için geçiş noktası transit kullanılır ve bunun bir örneği olarak ExpressRoute ile Kurumsal Ağa bağlantı kurulabilir.
+
+### Access Control(Erişim Kontrolü)
+
+- Azure, Ağ Güvenlik Gruplarını (Network Security Groups - NSG) kullanır ve bunlar durumları korur.
+- Kuralların oluşturulmasına ve daha sonra bir ağ güvenlik grubuna atanmasına izin verir.
+- Ağ güvenlik grupları, alt ağlara veya sanal makineler (VM) üzerine uygulanır.
+- Bir alt ağa uygulandığında, bunun bir "Kenar" cihazı olmadığı Virtual Machine NIC'inde hala uygulanan bir kuraldır.
+
+![](Images/Day33_Cloud1.png)
+
+- Kurallar, bir Ağ Güvenlik Grubunda birleştirilir.
+- Önceliğe göre esnek yapılandırmalar mümkündür.
+- Daha düşük öncelik numarası yüksek önceliği ifade eder.
+- Çoğu mantık IP adresleri üzerinde kurulmuştur, ancak bazı etiketler ve etiketler de kullanılabilir.
+
+| Description      | Priority | Source Address     | Source Port | Destination Address | Destination Port | Action |
+| ---------------- | -------- | ------------------ | ----------- | ------------------- | ---------------- | ------ |
+| Inbound 443      | 1005     | \*                 | \*          | \*                  | 443              | Allow  |
+| ILB              | 1010     | Azure LoadBalancer | \*          | \*                  | 10000            | Allow  |
+| Deny All Inbound | 4000     | \*                 | \*          | \*                  | \*               | DENY   |
+
+Ayrıca, Uygulama Güvenlik Grupları (Application Security Groups - ASG) mevcuttur.
+
+- NSG'ler büyüyen ortamlar için sürdürmesi zor olabilecek IP adresi aralıklarına odaklanırken,
+- ASG'ler, farklı uygulama rolleri için gerçek isimlerin (Monikers) tanımlanmasına olanak sağlar (Web Sunucuları, Veritabanı sunucuları, WebApp1 vb.).
+- Sanal Makine NIC'i bir veya daha fazla ASG üyesi yapılır.
+
+ASG'ler daha sonra Ağ Güvenlik Gruplarındaki kurallarda kullanılabilir ve iletişim akışını kontrol etmek için NSG hizmet etiketleri gibi NSG özelliklerini kullanabilir.
+
+| Action | Name               | Source     | Destination | Port         |
+| ------ | ------------------ | ---------- | ----------- | ------------ |
+| Allow  | AllowInternettoWeb | Internet   | WebServers  | 443(HTTPS)   |
+| Allow  | AllowWebToApp      | WebServers | AppServers  | 443(HTTPS)   |
+| Allow  | AllowAppToDB       | AppServers | DbServers   | 1443 (MSSQL) |
+| Deny   | DenyAllinbound     | Any        | Any         | Any          |
+
+### Load Balancing(Yük Dengeleme)
+
+Microsoft Azure, iki ayrı yük dengeleme çözümüne sahiptir (birinci taraf, Azure Marketplace'de üçüncü taraf seçenekler de mevcuttur). Her ikisi de dışarıya yönelik veya içerideki uç noktalarla çalışabilir.
+
+- Yük Dengeleyici (Katman 4), karma-tabanlı dağıtım ve port yönlendirmeyi destekler.
+- App Gateway (Katman 7), SSL dışa aktarımı, çerez tabanlı oturum tutma ve URL tabanlı içerik yönlendirmesi gibi özellikleri destekler.
+
+Ayrıca, App Gateway ile isteğe bağlı olarak Web Uygulama Güvenlik Duvarı bileşenini kullanabilirsiniz.
+
+## Azure Management Tools(Azure Yonetim Aracları)
+
+Teorik zamanımızın çoğunu Azure Portal üzerinde dolaşarak geçirdik. Bir DevOps kültürünü ve sürecini takip etmek söz konusu olduğunda, özellikle dağıtım ile ilgili birçok görev API veya komut satırı aracılığıyla gerçekleştirilecektir. Azure ortamlarımızı otomatikleştirdiğimizde kullanılabilecek diğer yönetim araçlarından bazılarına da değinmek istedim.
+
+### Azure Portal
+
+Microsoft Azure Portal, komut satırı araçlarına alternatif olarak sunulan web tabanlı bir konsoldur. Azure Portal içinde aboneliklerinizi yönetebilirsiniz. Basit bir web uygulamasından karmaşık bulut dağıtımlarına kadar her şeyi oluşturabilir, yönetebilir ve izleyebilirsiniz. Portalda bulabileceğiniz diğer bir özellik de bu kırıntı izleri (breadcrumbs)dir. Daha önce belirtildiği gibi, JSON, tüm Azure Kaynaklarının temelini oluşturur. Özellikleri, hizmetleri ve işlevselliği anlamak için Portal'da başlayabilir, ardından otomatik iş akışlarınıza dahil etmek için altında yatan JSON'ı daha sonra anlayabilirsiniz.
+
+![](Images/Day33_Cloud2.png)
+
+Ayrıca Azure Önizleme portalı da bulunmaktadır. Bu portal, yeni ve yakında sunulacak hizmetleri ve geliştirmeleri görüntülemek ve test etmek için kullanılabilir.
+
+![](Images/Day33_Cloud3.png)
+
+### PowerShell
+
+Azure PowerShell hakkında konuşmadan önce önce PowerShell'i tanıtmakta fayda var. PowerShell, görev otomasyonu ve yapılandırma yönetimi çerçevesi, bir komut satırı kabuğu ve bir betikleme dilidir. Bu, Linux bölümünde ele aldığımız kabuk betiklemeye benzetebiliriz. PowerShell ilk olarak Windows işletim sisteminde bulunuyordu, ancak şimdi çapraz platform destekli hale gelmiştir.
+
+Azure PowerShell, Azure kaynaklarını doğrudan PowerShell komut satırından yönetmek için bir cmdlet kümesidir.
+
+Aşağıdaki gibi görebiliriz ki, PowerShell komutu `Connect-AzAccount` kullanarak aboneliğinize bağlanabilirsiniz. 
+
+![](Images/Day33_Cloud4.png)
+
+Ardından, Azure sanal makinelerle ilişkili belirli komutları bulmak isteseydik, aşağıdaki komutu çalıştırabilirdik. Bu PowerShell programlama dilini daha fazla öğrenmek ve anlamak için saatler harcayabilirsiniz.
+
+![](Images/Day33_Cloud5.png)
+
+Microsoft tarafından PowerShell ile başlamanız ve hizmetleri yapılandırmanız için harika başlangıç kılavuzları bulunmaktadır [burada](https://docs.microsoft.com/en-us/powershell/azure/get-started-azureps?view=azps-7.1.0)
+
+### Visual Studio Code
+
+Birçok kişi gibi, ve hepinizin gördüğü gibi benim tercih ettiğim IDE Visual Studio Code'dur.
+
+Visual Studio Code, Windows, Linux ve macOS için Microsoft tarafından geliştirilen ücretsiz bir kaynak kodu düzenleyicisidir.
+
+Aşağıda, Microsoft Azure ve içindeki hizmetlerle etkileşimde bulunmak için kullanabileceğiniz birçok entegrasyon ve aracın Visual Studio Code'a entegre edildiğini göreceksiniz.
+
+![](Images/Day33_Cloud6.png)
+
+### Cloud Shell
+
+Azure Cloud Shell, Azure kaynaklarını yönetmek için etkileşimli, kimlik doğrulaması yapılmış, tarayıcı üzerinden erişilebilen bir kabuktur. Çalışma şeklinize en uygun kabuk deneyimini seçme esnekliği sağlar.
+
+![](Images/Day33_Cloud7.png)
+
+Aşağıdaki resimden, portal içinde Cloud Shell'i ilk başlattığımızda Bash ve PowerShell arasında seçim yapabileceğimizi görebilirsiniz.
+
+![](Images/Day33_Cloud8.png)
+
+Cloud Shell'i kullanmak için aboneliğinizde biraz depolama alanı sağlamanız gerekecektir.
+
+Cloud Shell'i seçtiğinizde, geçici olarak bir makine oluşturulur. Bu makineler geçici olmasına rağmen dosyalarınız iki şekilde saklanır: bir disk görüntüsü ve bağlanmış bir dosya paylaşımı aracılığıyla.
+
+![](Images/Day33_Cloud9.png)
+
+- Cloud Shell runs on a temporary host provided on a per-session, per-user basis
+- Cloud Shell times out after 20 minutes without interactive activity
+- Cloud Shell requires an Azure file share to be mounted
+- Cloud Shell uses the same Azure file share for both Bash and PowerShell
+- Cloud Shell is assigned one machine per user account
+- Cloud Shell persists $HOME using a 5-GB image held in your file share
+- Permissions are set as a regular Linux user in Bash
+
+The above was copied from [Cloud Shell Overview](https://docs.microsoft.com/en-us/azure/cloud-shell/overview)
+
+### Azure CLI
+
+Son olarak, Azure CLI hakkında konuşmak istiyorum. Azure CLI, Windows, Linux ve macOS üzerine kurulabilir. Kurulum yapıldıktan sonra `az` komutunu kullanarak diğer komutlarla Azure kaynaklarını oluşturabilir, güncelleyebilir, silebilir ve görüntüleyebilirsiniz.
+
+Azure öğrenmeye başladığımda Azure PowerShell ve Azure CLI arasındaki farkı anlamakta biraz karışıklık yaşamıştım.
+
+Bu konuda topluluktan bazı geri bildirimler almak isterim. Ancak benim gördüğüm şekilde Azure PowerShell, Windows PowerShell veya PowerShell Core'a (Diğer bazı işletim sistemlerinde de mevcut, ancak tümü değil) eklenen bir modüldür. Öte yandan, Azure CLI, Azure'a bağlanan ve bu komutları yürüten çapraz platform destekli bir komut satırı programıdır.
+
+Her iki seçenek de farklı bir sözdizimine sahiptir, ancak gördüğüm ve yaptığım kadarıyla çok benzer görevleri yerine getirebilirler.
+
+Örneğin, PowerShell'den bir sanal makine oluştururken `New-AzVM` cmdlet'ini kullanırken, Azure CLI'da `az VM create` komutunu kullanırsınız.
+
+Daha önce sistemime Azure PowerShell modülünü yüklediğimi, ancak aynı zamanda PowerShell üzerinden çağrılabilen Azure CLI'nin de yüklendiğini görmüştünüz.
+
+![](Images/Day33_Cloud10.png)
+
+Buradaki önemli nokta, doğru aracı seçmektir. Azure otomasyon üzerine kuruludur. Portal içinde yaptığınız her eylem, kaynakları okumak, oluşturmak, değiştirmek veya silmek için bir yerlerde yürütülen kodlara dönüşür.
+
+Azure CLI
+
+- Çapraz platformda çalışan komut satırı arabirimidir ve Windows, macOS, Linux'e yüklenebilir.
+- Windows PowerShell, Cmd, Bash ve diğer Unix kabuklarında çalışır.
+
+Azure PowerShell
+
+- Cross Platform'da çalışan bir PowerShell modülüdür ve Windows, macOS, Linux'ta çalışır.
+- Windows PowerShell veya PowerShell gerektirir.
+
+Eğer ortamınızda PowerShell kullanamıyorsanız ancak bash veya başka bir kabuk kullanabiliyorsanız, Azure CLI tercih edeceğiniz seçenek olacaktır.
+
+Şimdiye kadar geçtiğimiz teorileri alıp bazı senaryolar oluşturacak ve Azure'da uygulamalar gerçekleştireceğiz.
+
+## Kaynaklar
+
+- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
+- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
+- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
+- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
+
+Gorusmek Uzere [Gun 34](day34.md)

2022/tr/Days/day34.md

@@ -0,0 +1,187 @@
+## Microsoft Azure Senaryoları ve Uygulamaları 
+
+Son 6 gün, Microsoft Azure ve genel olarak halka açık buluta odaklandı. Azure'nin temel yapı taşlarını anlamak için bu temelin biraz teorik bilgi içermesi gerekiyordu, ancak bu bilgi, diğer büyük bulut sağlayıcılarında da geçerli olacaktır.
+
+Başlangıçta halka açık bulutun temel bilgisini edinmek ve en azından başlangıçta bir sağlayıcı seçmekten bahsettim. Farklı bulutlar arasında gidip gelirseniz, kolayca kaybolabileceğinizi düşünüyorum. Ancak bir tane seçtiğinizde temelleri anlarsınız ve bu temelleri anladığınızda diğer bulutlara geçmek ve öğrenmeyi hızlandırmak oldukça kolay olur.
+
+Bu final oturumunda, Microsoft tarafından oluşturulan ve[AZ-104 Microsoft Azure Administrator](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/) sınavına hazırlık için kullanılan bir referans olan bu sayfadan kendi uygulamalı senaryolarımı seçeceğim.
+
+Şu anda ayrıntılı olarak ele almadığımız, Konteynerler ve Kubernetes gibi bazı konular burada bulunmaktadır, bu yüzden henüz oraya atlamak istemiyorum.
+
+Daha önceki yazılarda, Modül 1, 2 ve 3'ün çoğunu oluşturduk.
+
+### Sanal Ag(Virtual Networking)
+
+Takip edilerek [Modül 04](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_04-Implement_Virtual_Networking.html):
+
+Yukarıdakileri geçtim ve bazı adları #90DaysOfDevOps için değiştirdim. Ayrıca, Cloud Shell'i kullanmak yerine Windows makinedeki Azure CLI ile önceki günlerde oluşturduğum yeni kullanıcımla giriş yaptım.
+
+Bunu, tarayıcıyı açacak ve hesabınıza kimlik doğrulama yapmanıza izin verecek `az login` komutunu kullanarak yapabilirsiniz.
+
+Daha sonra PowerShell betiği oluşturdum ve bazı referanslarını bu klasöre yerleştirerek aşağıdaki görevleri oluşturmak için modülden yararlandım.(Cloud\01VirtualNetworking)
+
+Lütfen scriptte dosya konumunu kendi ortamınıza uyacak şekilde değiştirin.
+
+Bu ilk aşamada, ortamımızda sanal ağ veya sanal makine oluşturulmadı. Yalnızca kaynak grubumdaki bir Cloud Shell depolama konumu yapılandırdım.
+
+Öncelikle [PowerShell script](Cloud/01VirtualNetworking/Module4_90DaysOfDevOps.ps1) çalıştırıyorum.
+
+![](Images/Day34_Cloud1.png)
+
+- Task 1: Sanal ağ oluşturma ve yapılandırma
+
+![](Images/Day34_Cloud2.png)
+
+- Task 2: Sanal ağa sanal makinelerin dağıtılması
+
+![](Images/Day34_Cloud3.png)
+
+- Task 3: Azure VM'lerin özel ve genel IP adreslerini yapılandırma
+
+![](Images/Day34_Cloud4.png)
+
+- Task 4: Ağ güvenlik gruplarını yapılandırma
+
+![](Images/Day34_Cloud5.png)
+![](Images/Day34_Cloud6.png)
+
+- Task 5: İç isim çözümü için Azure DNS'yi yapılandırma
+
+![](Images/Day34_Cloud7.png)
+![](Images/Day34_Cloud8.png)
+
+### Network Trafik Yönetimi
+
+Takip edilerek [Modül 06](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_06-Implement_Network_Traffic_Management.html):
+
+Sonraki adımda, bir öncekinden başlayarak kaynak grubumuza gittik ve kaynaklarımızı sildik. Kullanıcı hesabınızı yalnızca o kaynak grubuna erişime sahip olacak şekilde ayarlamamışsanız, modülü takip ederek adı `90Days*` olarak değiştirerek tüm kaynakları ve kaynak grubunu silebilirsiniz. Bu, aşağıdaki lablarda her bir işlemim için sürecim olacak.
+
+Bu lab için, ayrıca aşağıdaki görevleri oluşturmak için PowerShell betiği ve modülden bazı referansları kullanarak ilgili dosyaları bu klasörde buldum.
+(Cloud\02TrafficManagement)
+
+- Task 1: Laboratuvar ortamının sağlanması
+
+Oncelikle [PowerShell script](Cloud/02TrafficManagement/Mod06_90DaysOfDevOps.ps1) calıstırıyorum.
+
+![](Images/Day34_Cloud9.png)
+
+- Task 2:  Hub ve spoke ağ topolojisinin yapılandırılması
+
+![](Images/Day34_Cloud10.png)
+
+- Task 3: Sanal ağ peering'inin geçirgenliğini test etme
+
+90DaysOfDevOps grubumun Network Watcher'a erişimi olmadığı için bunun nedeni, Network Watcher'ların kaynak grubuna bağlı olmayan kaynaklardan biri olmasıdır. Bu nedenle, bu kullanıcı için RBAC'nin kapsandığı kaynak grubu değildir. 90DaysOfDevOps grubuna East US Network Watcher katkıda bulunan rolünü ekledim.
+
+![](Images/Day34_Cloud11.png)
+![](Images/Day34_Cloud12.png)
+![](Images/Day34_Cloud13.png)
+
+^  Bu, iki spoke sanal ağı birbirine bağlamadığımız için (sanal ağ peering geçişken değil) beklenen bir durumdur.
+
+- Task 4: Hub ve spoke topolojisinde yönlendirme yapılandırması
+
+Burada, hesabımın 90DaysOfDevOps grubu içindeki kullanıcı olarak komut çalıştıramamasıyla ilgili başka bir sorun yaşadım. Bunun nedenini anlamak için emin değilim, bu yüzden ana yönetici hesabıma geri döndüm. 90DaysOfDevOps grubu, 90DaysOfDevOps Kaynak Grubu'ndaki her şeyin sahibidir, bu yüzden VM içinde bir komut çalıştıramıyor olmamı anlamak isterim.
+
+![](Images/Day34_Cloud14.png)
+![](Images/Day34_Cloud15.png)
+
+Daha sonra michael.cade@90DaysOfDevOps.com hesabıma geri döndüm ve bu bölümü tamamladım. Burada, aynı testi tekrar çalıştırıyoruz ancak bu kez sonuç ulaşılabilir olacak şekilde.
+
+![](Images/Day34_Cloud16.png)
+
+- Task 5: Azure Load Balancer Uygulama 
+
+![](Images/Day34_Cloud17.png)
+![](Images/Day34_Cloud18.png)
+
+- Task 6: Azure Uygulama Gateway Uygulama
+
+![](Images/Day34_Cloud19.png)
+![](Images/Day34_Cloud20.png)
+
+### Azure Storage(Depolama)
+
+Takip edilerek [Modül 07](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_07-Manage_Azure_Storage.html):
+
+Bu lab için, ayrıca aşağıdaki görevleri oluşturmak için PowerShell betiği ve modülden bazı referansları kullanarak ilgili dosyaları bu klasörde buldum.
+
+(Cloud\03Storage)
+
+- Task 1: Laboratuvar ortamının sağlanması
+
+Öncelikle [PowerShell script](Cloud/03Storage/Mod07_90DaysOfDeveOps.ps1)  scriptini çalıştırıyorum. 
+
+![](Images/Day34_Cloud21.png)
+
+- Task 2: Azure Depolama hesaplarının oluşturulması ve yapılandırılması
+
+![](Images/Day34_Cloud22.png)
+
+- Task 3: Blob depolamasını yönetme
+
+![](Images/Day34_Cloud23.png)
+
+- Task 4: Azure Depolama için kimlik doğrulama ve yetkilendirme yönetimi
+
+![](Images/Day34_Cloud24.png)
+![](Images/Day34_Cloud25.png)
+
+Buna izin verilmesini beklerken biraz sabırsızdım, ancak sonunda çalıştı.
+
+![](Images/Day34_Cloud26.png)
+
+- Task 5: Azure Dosyalar paylaşımlarının oluşturulması ve yapılandırılması
+
+Komut çalıştırma işleminde, michael.cade@90DaysOfDevOps.com ile çalışmıyordu, bu yüzden yönetici hesabımı kullandım.
+
+![](Images/Day34_Cloud27.png)
+![](Images/Day34_Cloud28.png)
+![](Images/Day34_Cloud29.png)
+
+- Task 6: Azure Depolama için network erişimini yönetme
+
+![](Images/Day34_Cloud30.png)
+
+### Serverless (Web Uygulamaları Uygulama)
+
+Takip ederek [Modül 09a](https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09a-Implement_Web_Apps.html):
+
+- Task 1: Bir Azure web uygulaması oluşturma
+
+![](Images/Day34_Cloud31.png)
+
+- Task 2: Bir aşama deployment slots oluşturma
+
+![](Images/Day34_Cloud34.png)
+
+- Task 3: Web uygulaması deployment ayarlarını yapılandırma
+
+![](Images/Day34_Cloud33.png)
+
+- Task 4: Kodu aşama deployment slots dağıtma
+
+![](Images/Day34_Cloud32.png)
+
+- Task 5: Aşama slots değiştirme
+
+![](Images/Day34_Cloud35.png)
+
+- Task 6: Azure web uygulamasının otomatik ölçeklendirmesini yapılandırma ve test etme
+
+Bu senaryoda kullandığım scripti (Cloud/04Serverless) dizininde bulunabilir.
+
+![](Images/Day34_Cloud36.png)
+
+Bu, Microsoft Azure ve genel olarak halka açık bulut hakkındaki bölümü sonlandırıyor. Bu senaryolara saldırmak ve üzerlerinde çalışmak gerçekten eğlenceliydi, diyebilirim.
+
+## Kaynaklar
+
+- [Hybrid Cloud and MultiCloud](https://www.youtube.com/watch?v=qkj5W98Xdvw)
+- [Microsoft Azure Fundamentals](https://www.youtube.com/watch?v=NKEFWyqJ5XA&list=WL&index=130&t=12s)
+- [Google Cloud Digital Leader Certification Course](https://www.youtube.com/watch?v=UGRDM86MBIQ&list=WL&index=131&t=10s)
+- [AWS Basics for Beginners - Full Course](https://www.youtube.com/watch?v=ulprqHHWlng&t=5352s)
+
+Sonraki olarak, sürüm kontrol sistemlerine, özellikle de git'e ve kod deposu genel bakışlarına odaklanacağız ve tercih ettiğim seçenek olarak GitHub'ı seçeceğiz.
+
+Gorusmek Uzere [Gun 35](day35.md)

2022/tr/Days/day35.md

@@ -0,0 +1,130 @@
+## Git - Versiyon Kontrolü
+
+Git'e girmeden önce, sürüm kontrolünün ne olduğunu ve neden önemli olduğunu anlamamız gerekiyor. Bu Git girişinde, sürüm kontrolünün ne olduğuna ve git'in temellerine bir göz atacağız.
+
+### Versiyon Kontrolü Nedir?
+
+Git, sürüm kontrol sistemlerinden sadece bir tanesidir. Bu nedenle, burada sürüm kontrolü etrafında hangi seçeneklerin ve metodolojilerin bulunduğunu kapsamak istiyoruz.
+
+Sürüm kontrolünün en belirgin ve büyük faydası, bir projenin geçmişini takip etme yeteneğidir. `git log` komutunu kullanarak bu depoya geri dönüp projenin şu ana kadar neler olduğunu görebiliriz. Endişelenmeyin, komutları daha sonra detaylı bir şekilde ele alacağız. Şimdi düşünün, bu gerçek bir yazılım projesi olsaydı ve içinde kaynak kodu bulunan birden fazla kişi farklı zamanlarda, farklı yazarlar tarafından yazılımımıza katkıda bulunuyor olsaydı ve ardından inceleyenler bunların hepsi burada kaydediliyor, böylece neyin ne zaman, kim tarafından ve kimin tarafından gözden geçirildiğini biliriz.
+
+![](Images/Day35_Git1.png)
+
+Version Control, "cool" olmadan önce, değişiklik yapmadan önce bir versiyonumuzun manuel olarak bir kopyasını oluşturmanız gibi bir şey olabilirdi. Ayrıca gereksiz eski kodu "belki lazım olur" mantığıyla yorum satırına alabilirsiniz.
+
+![](Images/Day35_Git2.png)
+
+Ben, sadece kaynak kodu değil, neredeyse her şeyi içeren sürüm kontrolünü kullanmaya başladım. Projeler gibi (90DaysOfDevOps) böyle konuşuyor. Neden rollback özelliklerini ve her şeyin kaydedildiği bir günlüğü kabul etmeyelim ki.
+
+Ancak, büyük bir uyarı **Sürüm Kontrolü bir Yedekleme Değildir!**
+
+Versiyon Kontrolünün bir başka faydası, bir projenin birden fazla versiyonunu yönetebilme yeteneğidir. Bir örnek oluşturalım: Her işletim sisteminde mevcut olan ücretsiz bir uygulamamız var ve aynı şekilde her işletim sisteminde mevcut olan ücretli bir uygulamamız var. Kodun büyük bir kısmı her iki uygulama arasında paylaşılıyor. Her bir uygulama için her bir taahhütte kodumuzu kopyalayıp yapıştırabiliriz, ancak bu özellikle geliştirmeyi bir kişiden daha fazlasına ölçeklendirdiğinizde çok karışık bir hale gelecektir ve hatalar yapılacaktır.
+
+Premium uygulama, ek özelliklere sahip olacağımız yerdir, onları "premium taahhütler" olarak adlandıralım, ücretsiz sürüm ise yalnızca normal taahhütleri içerecektir.
+
+Bu, Versiyon Kontrolü'nde dal oluşturarak başarılmaktadır.
+
+![](Images/Day35_Git3.png)
+
+Dallanma(Branching), yukarıda belirtildiği gibi aynı uygulama için iki kod akışına izin verir. Ancak kaynak kodu ücretsiz olan sürümde yer alan yeni özelliklerin premium sürümde de olmasını isteyeceğiz ve bunu gerçekleştirmek için birleştirme adı verilen bir şeye ihtiyacımız var.
+
+![](Images/Day35_Git4.png)
+
+Şimdi, bu kolay gibi görünse de birleştirme karmaşık olabilir çünkü ücretsiz sürüm üzerinde çalışan bir ekip olabilir ve premium ücretli sürüm üzerinde çalışan başka bir ekip olabilir ve her ikisi de genel kodun bazı yönlerini etkileyen kod değişiklikleri yapabilir. Belki bir değişken güncellenir ve bir şeyleri bozar. Sonra, bir özelliği bozan bir çakışma oluşur. Sürüm Kontrolü, sizin tarafınızdan çözümlenmesi gereken çakışmaları düzeltemez. Ancak sürüm kontrolü, bunun kolayca yönetilmesine olanak sağlar.
+
+Bugüne kadar genel olarak sürüm kontrolünün en önemli nedeni, işbirliği yapabilme yeteneğidir. Geliştiriciler arasında kod paylaşma yeteneği ve daha önce de belirttiğim gibi, artık kaynak kontrolü için diğer nedenlerin çok daha fazla kullanım senaryosunu görmeye başlıyoruz, belki bir meslektaşınızla birlikte çalıştığınız ortak bir sunum veya 90DaysOfDevOps gibi bir zorluk, burada topluluk projenin her aşamasında düzeltmelerini ve güncellemelerini sunuyor.
+
+Sürüm kontrolü olmadan, yazılım geliştiricilerinin ekipler halinde nasıl başa çıktığını düşünmek zor. Ben bile kendi projelerim üzerinde çalışırken takip etmekte zorlandığımı düşünüyorum. O dönemde, kodu her bir işlevsel modüle bölebilirlerdi. Belki de parçaları bir araya getirmek için biraz daha zorluklar ve sorunlar yaşanırdı, ancak herhangi bir şey yayınlanmadan önce.
+
+Sürüm kontrolü sayesinde, tek bir gerçek kaynağımız olur. Hala farklı modüller üzerinde çalışabiliriz, ancak işbirliği yapmamızı daha iyi bir hale getirir.
+
+![](Images/Day35_Git5.png)
+
+Burada belirtmek istediğim bir başka şey, Sürüm Kontrolünün sadece geliştiricilerin değil, takımın tüm üyelerinin faydalanabileceği, görünürlüğe sahip olabileceği ve aynı zamanda araçların farkındalık veya kullanım sağlayabileceği bir şey olduğudur. Proje Yönetimi araçları buraya bağlanabilir, çalışmayı takip edebilir. Örneğin, Jenkins gibi bir derleme makinesi olabilir, başka bir modülde bundan bahsedeceğiz. Sistemi derleyen ve paketleyen, dağıtım testlerini ve metrikleri otomatikleştiren bir araç.
+
+### Git Nedir?
+
+Git, kaynak kodunun veya herhangi bir dosyanın değişikliklerini izleyen bir araçtır veya Git, açık kaynaklı bir dağıtık sürüm kontrol sistemi olarak da adlandırılabilir.
+
+Git'i sistemlerimizde birçok farklı şekilde kullanabiliriz. En yaygın kullanım şekli komut satırında, ancak görsel kullanıcı arayüzleri ve Visual Studio Code gibi araçlar da git bilincine sahip işlemleri kullanmamıza olanak sağlar.
+
+Şimdi, Git'i local makinemize yüklemeden önce genel bir genel bakış yapacağız.
+
+Daha önce oluşturduğumuz klasörü ele alalım.
+
+![](Images/Day35_Git2.png)
+
+Bu klasörü sürüm kontrolü ile kullanmak için, `git init` komutunu kullanarak bu dizini başlatmamız gerekiyor. Şimdilik, bu komutun dizinimizi bilgisayarımızdaki bir veritabanına bir depo olarak yerleştirdiğini düşünelim.
+
+![](Images/Day35_Git6.png)
+
+Şimdi bazı dosyalar ve klasörler oluşturabilir ve kaynak kodumuz başlayabilir veya belki zaten başlamıştır ve burada zaten bir şeyler bulunmaktadır. `git add .` komutunu kullanarak tüm dosyaları ve klasörleri anlık bir görüntüye ekliyoruz, ancak henüz bu veritabanına hiçbir şey taşımadık. Sadece tüm dosyaların `.` ile eklenmeye hazır olduğunu söylüyoruz.
+
+![](Images/Day35_Git7.png)
+
+Ardından dosyalarımızı taahhüt etmek istiyoruz, bunu `git commit -m "My First Commit"` komutuyla yapıyoruz. Her taahhüt için bir açıklama verebiliriz ve bu önerilir, böylece her taahhütte ne olduğunu bilebiliriz.
+
+![](Images/Day35_Git8.png)
+
+Şimdi projenin geçmişinde neler olduğunu görebiliriz. `git log` komutunu kullanarak.
+
+![](Images/Day35_Git9.png)
+
+`samplecode.ps1` adında başka bir dosya oluşturursak, durum farklı hale gelir. Ayrıca, depomuzun durumunu `git status` kullanarak kontrol edebiliriz. Bu, taahhüt edecek bir şeyimizin olmadığını ve samplecode.ps1 adlı yeni bir dosya ekleyebileceğimizi gösterir. Ardından aynı git status komutunu çalıştırırsanız, taahhüt edilecek bir dosyanız olduğunu göreceksiniz.
+
+![](Images/Day35_Git10.png)
+
+`git add samplecode.ps1` komutunu kullanarak yeni dosyamızı ekleyin ve ardından `git status`komutunu yeniden çalıştırın ve dosyanızın taahhüt edilmeye hazır olduğunu görün.
+
+![](Images/Day35_Git11.png)
+
+Ardından `git commit -m "My Second Commit"` komutunu kullanın.
+
+![](Images/Day35_Git12.png)
+
+Başka bir `git status` artık her şeyin temiz olduğunu gösterir.
+
+![](Images/Day35_Git13.png)
+
+Sonra `git log` komutunu kullanarak en son değişiklikleri ve ilk taahhüdü görebiliriz.
+
+![](Images/Day35_Git14.png)
+
+Taahhütlerimiz arasındaki değişiklikleri yani hangi dosyaların eklendiğini veya değiştirildiğini görmek istiyorsak `git diff b8f8 709a` komutunu kullanabiliriz.
+
+![](Images/Day35_Git15.png)
+
+Bu, değişikliklerimizde nelerin değiştiğini gösterir, bizim durumumuzda yeni bir dosya ekledik.
+
+![](Images/Day35_Git16.png)
+
+Bu konuya daha derinlemesine gireceğiz, taahhütlerimiz arasında geçiş yapabiliriz, yani zamanda yolculuk yapabiliriz! Taahhüt numaramızı kullanarak `git checkout 709a` komutunu kullanarak yeni dosyamızı kaybetmeden geçmişe geri dönebiliriz.
+
+![](Images/Day35_Git17.png)
+
+Ancak aynı şekilde ileri gitmek isteyeceğiz ve bunu yine taahhüt numarasıyla yapabiliriz veya burada işlemimizi geri almak için `git switch -` komutunu kullanıyoruz.
+
+![](Images/Day35_Git18.png)
+
+Özetlemek gerekirse:
+
+- Bir projenin geçmişini izleme
+- Bir projenin birden fazla sürümünü yönetme
+- Geliştiriciler arasında ve daha geniş bir ekip ve araç yelpazesinde kod paylaşma
+- Ekip çalışmasını koordine etme
+- Ayrıca biraz zaman yolculuğu da var!
+
+Belki bu biraz karışık gibi göründü, ancak umarım komutları bilmeden bile Sürüm Kontrolü'nün gücünü ve genel resmi görebilirsiniz.
+
+Şimdi sıradaki adım, git'i yerel makinenize kurmak ve yapılandırmaktır. Daha sonra git'te gerçekleştirebileceğimiz diğer kullanım durumlarına ve komutlara biraz daha derinlemesine dalacağız.
+
+## Kaynaklar
+
+- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
+- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
+- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
+- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
+- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
+- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
+
+Gorusmek Uzere [Gun 36](day36.md)

2022/tr/Days/day36.md

@@ -0,0 +1,144 @@
+## Git'i Kurma ve Yapılandırma
+
+Git, açık kaynaklı ve platformlar arası bir sürüm kontrol aracıdır. Ubuntu gibi Linux ortamlarını kullanan biriyseniz, zaten git'in yüklü olduğunu görebilirsiniz, ancak yine de kurulum ve yapılandırmayı gözden geçireceğiz.
+
+Eğer sistemde zaten git yüklü ise güncel olduğumuzdan emin olmak da iyi bir fikirdir.
+
+### Git'in Kurulumu
+
+Daha önce de belirtildiği gibi, Git platformlar arası bir araçtır. Windows ve Linux için kurulumu anlatacağız, ancak macOS için de [burada](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) bulabilirsiniz.
+
+[Windows](https://git-scm.com/download/win) için resmi siteden kurucuyu indirebiliriz.
+
+Ayrıca Windows makinenizde `winget` komutunu da kullanabilirsiniz. Bu, Windows Uygulama Paket Yöneticiniz gibi düşünebilirsiniz.
+
+Herhangi bir şeyi kurmadan önce, Windows Makinemizde hangi sürümü olduğunu görelim. Bir PowerShell penceresi açın ve `git --version` komutunu çalıştırın.
+
+![](Images/Day36_Git1.png)
+
+Ayrıca WSL Ubuntu sürümümüzün Git versiyonunuda kontrol edebiliriz.
+
+![](Images/Day36_Git2.png)
+
+Yazının yazıldığı sırada en son Windows sürümü `2.35.1` olduğu için güncelleme yapmamız gerekiyor, bunu da göstereceğim. Linux için de benzer bir durum bekliyorum.
+
+En son kurulum programını indirdim ve sihirbazı çalıştırdım, bunu burada belgeleyeceğim. Önemli olan nokta, git'in en son sürümünü kurmadan önce önceki sürümleri kaldırmasıdır.
+
+Yani aşağıda gösterilen süreç, git olmayan bir sisteme kurulum yapacakmışsınız gibi çoğunlukla aynı süreçtir.
+
+Kurulum çok basittir. İndirilen dosyaya çift tıklayarak başlayın. GNU lisans anlaşmasını okuyun. Ancak unutmayın, bu ücretsiz ve açık kaynaklı bir yazılımdır.
+
+![](Images/Day36_Git3.png)
+
+Şimdi, git ile ilişkilendirmek istediğimiz ek bileşenleri seçebiliriz. Windows'ta, Git Bash'i her zaman yüklüyorum, çünkü bu bize Windows üzerinde bash komut dosyalarını çalıştırma imkanı sağlar.
+
+![](Images/Day36_Git4.png)
+
+Daha sonra kullanmak istediğimiz SSH Yürütülebilirini seçebiliriz. Ben bunu, Linux bölümünde görmüş olabileceğiniz dahili OpenSSH olarak bırakıyorum.
+
+![](Images/Day36_Git5.png)
+
+Daha sonra etkinleştirmek isteyebileceğimiz deneysel özelliklerimiz var, ben bunlara ihtiyacım olmadığı için etkinleştirmiyorum, isterseniz kurulum üzerinden geri dönüp daha sonra bunları etkinleştirebilirsiniz.
+
+![](Images/Day36_Git6.png)
+
+Kurulum tamamlandı, şimdi Git Bash'i açmayı veya en son sürüm notlarına bakmayı seçebiliriz.
+
+![](Images/Day36_Git7.png)
+
+Son kontrol, PowerShell penceresinde şu anda hangi git sürümüne sahip olduğumuza bakmaktır.
+
+![](Images/Day36_Git8.png)
+
+Son derece basit bir işlem ve şimdi en son sürümdeyiz. Linux makinede biraz geride olduğumuz görünüyor, bu yüzden güncelleme sürecini de geçebiliriz.
+
+Basitçe `sudo apt-get install git` komutunu çalıştırıyorum.
+
+![](Images/Day36_Git9.png)
+
+Ayrıca aşağıdakini çalıştırabilirsiniz, bu git deposunu yazılım yüklemeleri için ekleyecektir.
+
+```
+sudo add-apt-repository ppa:git-core/ppa -y
+sudo apt-get update
+sudo apt-get install git -y
+git --version
+```
+
+### Git Yapılandırması
+
+Git'i ilk kullandığımızda bazı ayarları tanımlamamız gerekiyor:
+
+- Name(İsim)
+- Email(mail)
+- Default Editor(Varsayılan editor)
+- Line Ending(Satır Sonlandırma)
+
+Bu üç seviyede yapılabilir:
+
+- System = Tum Kullanıcılar
+- Global = Kullanıcının Tum Repoları
+- Local = Repolar
+
+Ornek:
+`git config --global user.name "Michael Cade"`
+`git config --global user.email Michael.Cade@90DaysOfDevOPs.com"`
+İşletim sisteminize bağlı olarak varsayılan metin düzenleyici belirlenecektir. Ubuntu makinede, aşağıdaki komut kullanılarak bunu visual studio code olarak değiştirebiliriz.
+
+`git config --global core.editor "code --wait"`
+
+Şimdi tüm git yapılandırmalarını görmek istiyorsak aşağıdaki komutu kullanabiliriz.
+
+`git config --global -e`
+
+![](Images/Day36_Git10.png)
+
+Bu dosya herhangi bir makinede `.gitconfig` olarak adlandırılacaktır. Windows makinede bu, kullanıcı hesabınızın dizininde bulunur.
+
+![](Images/Day36_Git11.png)
+
+### Git Teorisi
+
+Dünkü gönderide farklı versiyon kontrol türleri olduğunu belirtmiştim ve bunları iki farklı tipe ayırabiliriz. Birincisi İstemci-Sunucu ve diğeri Dağıtık versiyon kontrolüdür.
+
+### Client-Server Versiyon Kontrolü
+
+Git ortaya çıkmadan önce, İstemci-Sunucu versiyon kontrolü, varsayılan yöntemdi. Buna örnek olarak, 2000 yılında kurulan açık kaynaklı bir versiyon kontrol sistemi olan [Apache Subversion](https://subversion.apache.org/) gösterilebilir.
+
+Bu Client-Server versiyon kontrol modelinde, geliştirici ilk adımda kaynak kodunu ve gerçek dosyaları sunucudan indirir. Bu, çatışmaları ortadan kaldırmaz, ancak çatışmaların karmaşıklığını ve nasıl çözüleceğini azaltır.
+
+![](Images/Day36_Git12.png)
+
+Örneğin, aynı dosyalar üzerinde çalışan iki geliştirici olduğunu düşünelim ve birincisi yarışı kazanır ve yeni değişiklikleriyle dosyayı ilk olarak sunucuya taşır veya yükler. İkinci geliştirici güncelleme yapmaya çalıştığında bir çatışma yaşar.
+
+![](Images/Day36_Git13.png)
+
+Şimdi, geliştirici birinci geliştiricinin kod değişikliğini kendi değişikliğiyle birleştirir ve çatışmalar çözüldükten sonra taahhüt eder.
+
+![](Images/Day36_Git15.png)
+
+### Dağıtık Versiyon Kontrolü
+
+Git, tek başına dağıtık versiyon kontrol sistemi değildir. Ancak genellikle kullanılan bir sistemdir.
+
+Git'in bazı temel avantajları şunlardır:
+
+- Hızlı
+- Akıllı
+- Esnek
+- Güvenli ve Korunaklı
+
+Client-Server versiyon kontrol modelinin aksine, her geliştirici kaynak deposunu indirir, yani her şeyi indirir. Taahhüt geçmişi, tüm dallar vb.
+
+![](Images/Day36_Git16.png)
+
+## Kaynaklar
+
+- [What is Version Control?](https://www.youtube.com/watch?v=Yc8sCSeMhi4)
+- [Types of Version Control System](https://www.youtube.com/watch?v=kr62e_n6QuQ)
+- [Git Tutorial for Beginners](https://www.youtube.com/watch?v=8JJ101D3knE&t=52s)
+- [Git for Professionals Tutorial](https://www.youtube.com/watch?v=Uszj_k0DGsg)
+- [Git and GitHub for Beginners - Crash Course](https://www.youtube.com/watch?v=RGOj5yH7evk&t=8s)
+- [Complete Git and GitHub Tutorial](https://www.youtube.com/watch?v=apGV9Kg7ics)
+
+Gorusmek Uzere [Gun 37](day37.md)