Merge branch 'MichaelCade:main' into main

2022/Days/day28.md

@@ -100,6 +100,6 @@ I am also going to build out a scenario as I have done in the other sections whe
 - [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)
+- [AWS Basics for Beginners - Full Course](https://youtu.be/k1RI5locZE4?si=0wPB2cdTY5hHgjl5)
 
 See you on [Day 29](day29.md)

2022/Days/day40.md

@@ -73,7 +73,7 @@ We can then drill down into the building block of GitHub, the repositories. Here
 
 As the repository is so important to GitHub let me choose a pretty busy one of late and run through some of the core functionality that we can use here on top of everything I am already using when it comes to editing our "code" in git on my local system.
 
-First of all, from the previous window, I have selected the 90DaysOfDevOps repository and we get to see this view. You can see from this view we have a lot of information, we have our main code structure in the middle showing our files and folders that are stored in our repository. We have our readme. mdbeing displayed down at the bottom. Over to the right of the page, we have an about section where the repository has a description and purpose. Then we have a lot of information underneath this showing how many people have starred in the project, forked, and watched.
+First of all, from the previous window, I have selected the 90DaysOfDevOps repository and we get to see this view. You can see from this view we have a lot of information, we have our main code structure in the middle showing our files and folders that are stored in our repository. We have our readme.md being displayed down at the bottom. Over to the right of the page, we have an about section where the repository has a description and purpose. Then we have a lot of information underneath this showing how many people have starred in the project, forked, and watched.
 
 ![](Images/Day40_Git8.png)
 
@@ -179,7 +179,7 @@ Let's now make some changes, I want to make a change to all those links and repl
 
 ![](Images/Day40_Git27.png)
 
-Now if we check back on GitHub and we find our readme.mdin that repository, you should be able to see a few changes that I made to the file.
+Now if we check back on GitHub and we find our readme.md in that repository, you should be able to see a few changes that I made to the file.
 
 ![](Images/Day40_Git28.png)
 

2022/Days/day41.md

@@ -16,7 +16,7 @@ When we went through the GitHub fundamentals we went through the process of fork
 
 ## Fork a Project
 
-The first thing we have to do is find a project we can contribute to. I have recently been presenting on the [Kanister Project](https://github.com/kanisterio/kanister) and I would like to share my presentations that are now on YouTube to the main readme.mdfile in the project.
+The first thing we have to do is find a project we can contribute to. I have recently been presenting on the [Kanister Project](https://github.com/kanisterio/kanister) and I would like to share my presentations that are now on YouTube to the main readme.md file in the project.
 
 First of all, we need to fork the project. Let's run through that process. I am going to navigate to the link shared above and fork the repository.
 
@@ -26,7 +26,7 @@ We now have our copy of the whole repository.
 
 ![](Images/Day41_Git2.png)
 
-For reference on the Readme.mdfile the original Presentations listed are just these two so we need to fix this with our process.
+For reference on the readme.md file the original Presentations listed are just these two so we need to fix this with our process.
 
 ![](Images/Day41_Git3.png)
 
@@ -42,7 +42,7 @@ We have our project local so we can open VSCode or an IDE or text editor of your
 
 ![](Images/Day41_Git5.png)
 
-The readme.mdfile is written in markdown language and because I am modifying someone else's project I am going to follow the existing project formatting to add our content.
+The readme.md file is written in markdown language and because I am modifying someone else's project I am going to follow the existing project formatting to add our content.
 
 ![](Images/Day41_Git6.png)
 
@@ -76,7 +76,7 @@ Next, we hit that contribute button highlighted above. We see the option to "Ope
 
 ## Open a pull request
 
-There is quite a bit going on in this next image, top left you can now see we are in the original or the master repository. then you can see what we are comparing and that is the original master and our forked repository. We then have a create pull request button which we will come back to shortly. We have our single commit but if this was more changes you might have multiple commits here. then we have the changes we have made in the readme.mdfile.
+There is quite a bit going on in this next image, top left you can now see we are in the original or the master repository. then you can see what we are comparing and that is the original master and our forked repository. We then have a create pull request button which we will come back to shortly. We have our single commit but if this was more changes you might have multiple commits here. then we have the changes we have made in the readme.md file.
 
 ![](Images/Day41_Git12.png)
 

2022/tr/Days/day39.md

@@ -0,0 +1,204 @@
+## Değişiklikleri Görüntüleme, Unstaging, İptal Etme ve Geri Yükleme
+
+Dün kaldığımız yerden git komutlarının bazılarına ve projelerinizde git'i nasıl kullanabileceğinize dair nasıl yapabileceğimize dair konuşmaya devam ediyoruz. Hatırlatmak isterim ki henüz GitHub veya diğer git tabanlı hizmetlere dokunmadık, şu anda projelerinizi yerel olarak kontrol etmenize yardımcı olmak için tüm bunlar, ancak bu araçlarla entegre olmaya başladığımızda hepsi kullanışlı hale gelecek.
+
+### Staged ve Unstaged Değişiklikleri Görüntüleme
+
+Commit etmeden önce staged ve unstaged kodu görüntülemek iyi bir uygulamadır. Bunun için `git diff --staged` komutunu çalıştırabiliriz.
+
+![](Images/Day39_Git1.png)
+
+Bu bize yaptığımız tüm değişiklikleri ve eklediğimiz veya sildiğimiz tüm yeni dosyaları gösterir.
+
+Değiştirilen dosyalardaki değişiklikler `---` veya `+++` ile gösterilir, aşağıda yeni satırlar olduklarını belirten +add some text below eklediğimizi görebilirsiniz.
+
+![](Images/Day39_Git2.png)
+
+Ayrıca `git diff` komutunu çalıştırarak taahhüt alanımızı çalışma dizinimizle karşılaştırabiliriz. Yeni eklenen code.txt dosyasını değiştiririz ve bazı metin satırları ekleriz.
+
+![](Images/Day39_Git3.png)
+
+Daha sonra `git diff` komutunu çalıştırırsak, aşağıdaki çıktıyı karşılaştırır ve görüntüleriz.
+
+![](Images/Day39_Git4.png)
+
+### Gorsel Fark(Diff) Aracları
+
+Benim için yukarıdaki yöntem biraz karışık olduğu için daha çok görsel bir araç kullanmayı tercih ederim.
+
+Birkaç görsel fark aracını şöyle sıralayabiliriz:
+
+- KDiff3
+- P4Merge
+- WinMerge (Windows Only)
+- VSCode
+
+Bu aracı git içinde ayarlamak için aşağıdaki komutu çalıştırırız: `git config --global diff.tool vscode`
+
+Yukarıdakini çalıştıracağız ve VScode'u başlattığımızda bazı parametreler belirleyeceğiz.
+
+![](Images/Day39_Git5.png)
+
+
+Ayrıca konfigürasyonumuzu `git config --global -e` komutu ile kontrol edebiliriz.
+
+![](Images/Day39_Git6.png)
+
+Ardından şimdi farklılık görsel aracımızı açmak için `git difftool` komutunu kullanabiliriz.
+
+![](Images/Day39_Git7.png)
+
+Bu, farklılık sayfasında VScode düzenleyicimizi açar ve ikisini karşılaştırır, sadece bir dosyayı hiçbir şeyden, şimdi sağ tarafta bir kod satırı ekleyerek değiştirdik.
+
+![](Images/Day39_Git8.png)
+
+Bu yöntemi değişiklikleri takip etmek için çok daha kolay buluyorum ve bu, GitHub gibi git tabanlı hizmetlere baktığımızda göreceğimiz bir şeye benziyor.
+
+Ayrıca stage edilmiş dosyaları aşama ile karşılaştırmak için `git difftool --staged` komutunu da kullanabiliriz.
+
+![](Images/Day39_Git9.png)
+
+Ardından stage etmeden önce değiştirilmiş dosyalarımızı döngü içinde gezebiliriz.
+
+![](Images/Day39_Git10.png)
+
+Ben IDE olarak VScode kullanıyorum ve çoğu IDE gibi, bu işlevsellik zaten entegre edilmiş durumda, bu komutları nadiren terminalden çalıştırmanız gerekecektir, ancak herhangi bir nedenle IDE yüklü değilse yardımcı olur.
+
+### History(Gecmiş) Görüntüleme
+
+Daha önce `git log` komutuna değinmiştik, bu komut bize deposundaki yaptığımız tüm commitleri kapsamlı bir şekilde görüntüler.
+
+![](Images/Day39_Git11.png)
+
+Her commitin kendine özgü onaltılık bir dizisi vardır ve bu dizide depoya özgüdür. Burada hangi şubede çalıştığımızı ve ayrıca yazarı, tarihi ve commit mesajını görebilirsiniz.
+
+Ayrıca `git log --oneline` komutunu kullanarak daha küçük bir onaltılık dizisinin daha küçük bir sürümünü alabiliriz ve bunu diğer `diff` komutlarında kullanabiliriz. Ayrıca yalnızca tek satırlık açıklamaya veya commit mesajına sahibiz.
+
+
+![](Images/Day39_Git12.png)
+
+Bu komutu tersine çevirerek ilk commitle başlamak için `git log --oneline --reverse` çalıştırabiliriz ve şimdi ilk commitiniz sayfanın en üstünde görüyoruz.
+
+![](Images/Day39_Git13.png)
+
+### Bir Commit'i Görüntüleme
+
+Bir taahhüt mesajına bakma yeteneği, en iyi uygulamaları takip etmeye özen gösterdiyseniz ve anlamlı bir taahhüt mesajı eklediyseniz harikadır, ancak ayrıca bir taahhüdü incelememize ve görüntülememize izin veren `git show` komutu da vardır.
+
+g`git log --oneline --reverse` komutunu kullanarak commitlerimizin bir listesini alabiliriz. ve sonra bu taahhütleri alıp `git show <commit ID>` komutunu çalıştırabiliriz.
+
+![](Images/Day39_Git14.png)
+
+Bu komutun çıktısı, commitin detayı, yazarı ve neyin değiştiği gibi aşağıdaki gibi görünecektir.
+
+![](Images/Day39_Git15.png)
+
+Ayrıca, `git show HEAD~1` kullanarak, 1, mevcut sürümden ne kadar geri gitmek istediğimizi belirtir.
+
+Bu dosyalarınız hakkında bazı detaylar istiyorsanız harikadır, ancak tüm anlık görüntü dizini için ağaçta bulunan tüm dosyaları listelemek istiyorsak. Bunun için `git ls-tree HEAD~1` komutunu kullanarak bunu başarabiliriz, burada en son committen bir anlık görüntü geriye gitmektedir. Aşağıda iki blok olduğunu görebilirsiniz, bunlar dosyaları gösterirken ağaç, bir dizini gösterecektir. Ayrıca bu bilgilerde taahhütleri ve etiketleri görebilirsiniz.
+
+![](Images/Day39_Git16.png)
+
+Yukarıdakini kullanarak, dosyanın içeriğini (bloklar) görmek için `git show` komutunu kullanabiliriz.
+
+![](Images/Day39_Git17.png)
+
+Ardından belirli bir dosyanın o sürümünün içeriği gösterilecektir.
+
+![](Images/Day39_Git18.png)
+
+### Unstaging Files
+
+Belki de `git add .` komutunu kullanmış olabilirsiniz, ancak henüz o anlık görüntüye commit etmek istemediğiniz dosyalarınız olabilir. Aşağıdaki örnekte yeni bir dosya olan newfile.txt'yi commit alanıma ekledim, ancak bu dosyayı taahhüt etmeye hazır değilim, bu nedenle `git add` adımını geri almak için `git restore --staged newfile.txt` komutunu kullanacağım.
+
+![](Images/Day39_Git19.png)
+
+Aynı şekilde main.js gibi değiştirilmiş dosyaları unstaging bırakabiliriz ve commiti geri alabiliriz, yukarıda değiştirilmiş için yeşil bir M işareti var ve aşağıda bu değişiklikleri committen çıkarıyoruz.
+
+![](Images/Day39_Git20.png)
+
+Ben bu komutu 90DaysOfDevOps sırasında oldukça faydalı buldum, bazen ileride çalışıyorum ve bir sonraki gün için notlar almak istediğim günlerde commit ve push işlemlerini genel GitHub deposuna gerçekleştirmek istemiyorum.
+
+### Local Değişiklikleri İptal Etme
+
+Bazen değişiklikler yapabiliriz, ancak bu değişikliklerden memnun değiliz ve onları atmak istiyoruz. Tekrar `git restore` komutunu kullanacağız ve anlık görüntülerden veya önceki sürümlerden dosyaları geri yükleyebileceğiz. `git restore .` komutunu dizinimize karşı çalıştırabilir ve anlık görüntüden her şeyi geri yükleyebiliriz, ancak takip edilmeyen dosyanın hala mevcut olduğuna dikkat edin. newfile.txt adında izlenen önceki bir dosya yok.
+
+![](Images/Day39_Git21.png)
+
+Şimdi newfile.txt veya takip edilmeyen herhangi bir dosyayı kaldırmak için `git clean` komutunu kullanabiliriz, yalnızca bir uyarı alacaksınız.
+
+![](Images/Day39_Git22.png)
+
+Veya sonuçlarını biliyorsak, tüm dizinleri zorla kaldırmak için `git clean -fd` komutunu çalıştırmak isteyebiliriz.
+
+![](Images/Day39_Git23.png)
+
+### Bir Dosyayı Daha Önceki Bir Sürüme Geri Yükleme
+
+Git'in size yardımcı olabileceği büyük bir bölümü, dosyalarınızın anlık görüntülerinizden kopyalarını geri yükleyebilme yeteneğidir (bu bir yedek değil, ancak çok hızlı bir geri yükleme noktasıdır). Benim tavsiyem, ayrıca kodunuzu diğer konumlarda yedek bir çözüm kullanarak kaydetmenizdir.
+
+Bir örnek olarak, dizinimizdeki en önemli dosyamızı silelim, bunu dizinden kaldırmak için Unix tabanlı komutları kullanıyoruz, git komutları değil.
+
+![](Images/Day39_Git24.png)
+
+Şimdi çalışma dizinimizde readme.md dosyamız yok. `git rm readme.md` komutunu kullanabilirdik ve bu, git veritabanımızda yansıtılacaktı. Ayrıca, tamamen kaldırıldığını simüle etmek için onu buradan da silelim.
+
+![](Images/Day39_Git25.png)
+
+Şimdi bir mesajla bunu commit edelim ve artık çalışma dizinimizde veya taahhüt alanımızda hiçbir şey olmadığını kanıtlayalım.
+
+![](Images/Day39_Git26.png)
+
+Hatalar yapıldı ve şimdi bu dosyaya ihtiyacımız var!
+
+Son taahhüdü geri alacak olan `git undo` komutunu kullanabilirdik, ancak bir süre önceyse ne yapmalıyız? Taahhütlerimizi bulmak için `git log` komutunu kullanabiliriz ve ardından dosyamızın son taahhütte olduğunu buluruz, ancak tüm bu taahhütlerin geri alınmasını istemiyoruz, bu nedenle belirli bir komut olan `git restore --source=HEAD~1 README.md` komutunu kullanarak dosyayı belirleyebiliriz ve anlık görüntümüzden geri yükleyebiliriz.
+
+Bu süreci kullanarak dosyanın artık çalışma dizinimizde olduğunu görebilirsiniz.
+
+![](Images/Day39_Git27.png)
+
+Artık yeni bir izlenmeyen dosyamız var ve dosyalarımızı ve değişikliklerimizi takip etmek, aşama almak ve commit etmek için önceki olarak bahsedilen komutlarımızı kullanabiliriz.
+
+### Rebase vs Merge
+
+Bu, Git ve ne zaman yeniden taban almak veya birleştirmeyi kullanmak gerektiğinde en büyük baş ağrısına neden olan şey gibi görünüyor.
+
+Bilinmesi gereken ilk şey, `git rebase` ve `git merge` komutlarının aynı sorunu çözdüğüdür. İkisi de bir dalı diğerine entegre etmek içindir. Ancak bunu farklı yollarla yaparlar.
+
+Yeni bir özellikle yeni bir özel dalda başlayalım. Ana dal, yeni taahhütlerle devam eder.
+
+![](Images/Day39_Git28.png)
+
+Kolay seçenek, `git merge feature main` kullanmaktır, bu, ana dalı özellik dalına birleştirir.
+
+![](Images/Day39_Git29.png)
+
+Birleştirme, yıkıcı olmadığı için kolaydır. Mevcut dallar hiçbir şekilde değiştirilmez. Bununla birlikte, bu, özellik dalının her seferinde yukarı akış değişikliklerini içermesi gerektiğinde ilgisiz birleştirme taahhüdüne sahip olacağı anlamına gelir. Ana dal çok yoğun veya aktifse, bu özellik dalının geçmişini kirletebilir.
+
+Alternatif bir seçenek olarak, özellik dalını ana dalın üstüne yeniden taban alabiliriz:
+
+```
+git checkout feature
+git rebase main
+```
+
+Bu, özellik dalını (tüm özellik dalını) ana dala etkin bir şekilde dahil eder. Ancak, birleştirme commiti kullanmak yerine yeniden taban almak, orijinal dalın her commiti için yepyeni taahhütler oluşturarak proje geçmişini yeniden yazarak yapar.
+
+![](Images/Day39_Git30.png)
+
+Yeniden taban almanın en büyük faydası, çok daha temiz bir proje geçmişidir. Ayrıca gereksiz birleştirme taahhütlerini ortadan kaldırır. Ve son iki resmi karşılaştırdığınızda, daha temiz ve lineer bir proje geçmişini takip edebilirsiniz.
+
+Yine de kesin bir sonuç olmasa da, daha temiz bir geçmişi seçmek bazı karşılıklılıkları da beraberinde getirir. Eğer [Yeniden Taban Almanın Altın Kuralı](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)nı takip etmezseniz, proje geçmişini yeniden yazmak işbirliği iş akışınız için potansiyel olarak felaket olabilir. Ve daha az önemli olarak, yeniden taban alma birleştirme taahhüdünün sağladığı bağlamı kaybeder - yukarı akış değişikliklerinin özelliğe ne zaman dahil edildiğini göremezsiniz.
+
+## 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)
+- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
+- [Exploring the Git command line – A getting started guide](https://veducate.co.uk/exploring-the-git-command-line/)
+
+Gorusmek Uzere [Gun40](day40.md)

2022/tr/Days/day40.md

@@ -0,0 +1,200 @@
+## Sosyal Network Kod için
+
+GitHub | GitLab | BitBucket'i Kesfetmek
+
+Bugün, muhtemelen hepimizin duyduğu ve muhtemelen günlük olarak kullandığımız bazı git tabanlı hizmetleri ele almak istiyorum.
+
+Daha sonra önceki oturum bilgilerimizden bazılarını kullanarak verilerimizin kopyalarını ana hizmetlere taşıyacağız.
+
+Bu bölümü "Sosyal Network Kod için" olarak adlandırdım, nedenini açıklayayım mı?
+
+### GitHub
+
+En yaygın olarak en azından benim için GitHub'tır. GitHub, git için web tabanlı bir barındırma hizmetidir. Genellikle yazılım geliştiricileri tarafından kodlarını saklamak için kullanılır. Git sürüm kontrol özellikleri ile Kaynak Kod Yönetimi ve birçok ek özellik sunar. Takımlara veya açık katkı sağlayanlara kolay iletişim imkanı sağlar ve kodlamaya sosyal bir yön kazandırır. (bu yüzden sosyal ağ başlığı) 2018 yılından bu yana GitHub, Microsoft'un bir parçasıdır.
+
+GitHub uzun bir süredir var ve 2007/2008 yılında kuruldu. Bugün platformda 40 milyondan fazla kullanıcı bulunmaktadır.
+
+GitHub Ana Özellikleri
+
+- Code Repository
+- Pull Requests
+- Project Management toolset - Issues
+- CI / CD Pipeline - GitHub Actions
+
+Fiyatlandırma açısından, GitHub kullanıcıları için farklı fiyatlandırma seviyeleri sunar. Daha fazlası için [fiyatlandırma](https://github.com/pricing)'ya bakılabilir.
+
+Bu kapsamda ücretsiz seviyeyi ele alacağız.
+
+Bu rehberde zaten oluşturulmuş olan GitHub hesabımı kullanacağım, eğer bir hesabınız yoksa, açılış GitHub sayfasında kaydolma seçeneği ve kurulumu yapmak için bazı kolay adımlar bulunmaktadır.
+
+### GitHub Açılış Sayfası
+
+GitHub hesabınıza ilk giriş yaptığınızda, genelde neleri görmek veya ne yapmak istediğinize dair birçok widget içeren bir sayfa görüntülenir. İlk olarak "Tüm Etkinlik"ler kısmı bulunmaktadır, bu, depolarınızla veya hesabınızla ilişkilendirilen genel etkinlikleri gösterir.
+
+![](Images/Day40_Git1.png)
+
+Sonra, Kod Depolarımızı görüntüleriz, kendi depolarımızı veya son zamanlarda etkileşimde bulunduğumuz depoları görüntüleyebiliriz. Ayrıca hızlıca yeni depolar oluşturabilir veya depo arayabiliriz.
+
+![](Images/Day40_Git2.png)
+
+Daha sonra son zamanlardaki etkinliklerimiz gelir, bunlar genellikle benim tarafımdan oluşturulan veya son zamanlarda katkıda bulunduğum sorunlar ve çekme istekleridir.
+
+![](Images/Day40_Git3.png)
+
+Sayfanın sağ tarafında, muhtemelen son etkinlikleriniz veya kendi projeleriniz temel alınarak ilginizi çekebilecek depo önerileri bulunur.
+
+![](Images/Day40_Git4.png)
+
+Dürüst olmak gerekirse, şimdi gördüğümüz ve anlattığımız ana sayfada çok nadiren bulunurum, ama artık beslemenin belirli projelerde toplulukla daha iyi etkileşimde bulunmama yardımcı olabileceğini görüyorum.
+
+Şimdi, GitHub Profilimize gitmek istiyorsak, sağ üst köşeye gidip resminizin üzerine tıklamanız gerekiyor, açılan menüde hesabınızı gezinmek için bir seçenek bulunacaktır. Buradan "Profiliniz"i seçerek profiline erişebilirsiniz.
+
+![](Images/Day40_Git5.png)
+
+Sonra, profil sayfanız görünecektir. Varsayılan olarak, yapılandırmanızı değiştirmezseniz, benimkinde olduğu gibi görmeyeceksiniz. Ben, son blog yayınlarımı [vZilla](https://vzilla.co.uk) üzerinde ve ayrıca en son [YouTube](https://m.youtube.com/c/MichaelCade1) kanalımdaki videolarımı gösteren bazı işlevselliği ekledim.
+
+Profilinizi çok fazla inceleme yaparak geçirmeyeceksiniz, ancak bu, ağınızla paylaşabileceğiniz iyi bir profil sayfasıdır, böylece üzerinde çalıştığınız harika projeleri görebilirler.
+
+![](Images/Day40_Git6.png)
+
+Sonra, GitHub'ın temel yapı taşı olan depolara doğru ilerleyebiliriz. Burada depolarınızı göreceksiniz ve özel depolarınız varsa bunlar da bu uzun listede gösterilecektir.
+
+![](Images/Day40_Git7.png)
+
+Depo GitHub için çok önemli olduğu için, son zamanlarda oldukça yoğun olan 90DaysOfDevOps deposunu seçtim ve burada kullanabileceğimiz temel işlevselliğin bazılarını anlatacağım. Zaten yerel sistemimde "kod"umuzu düzenlerken kullandığım her şeyin üstüne.
+
+Öncelikle, önceki pencereden 90DaysOfDevOps deposunu seçtim ve bu görünümü gördük. Bu görünümden, çok sayıda bilgiye sahip olduğumuzu görebilirsiniz. Orta kısımda ana kod yapımızı görüntülüyoruz, depomuzda saklanan dosyalarımızı ve klasörlerimizi gösteriyoruz. Alttan okuma. mdalt kısmına ekran alınmıştır. Sayfanın sağ tarafında, depo bir açıklama ve amaç içeren bir bölüm bulunur. Ardından, projeye kaç kişinin yıldız eklediğini, çatal oluşturduğunu ve izlediğini gösteren birçok bilgi bulunur.
+
+![](Images/Day40_Git8.png)
+
+Biraz daha aşağı kaydırırsak, Yayınlananlar bölümünü de göreceksiniz, bunlar meydan okumanın golang kısmından geliyor. Projemizde herhangi bir paket bulunmuyor, katkıda bulunanlarımız burada listeleniyor. (Yazım hataları ve gerçekleri kontrol etme konusunda topluluk yardımı için teşekkür ederim) Ardından yine meydan okumanın farklı bölümlerinden alınan kullanılan dilleri görüyoruz.
+
+![](Images/Day40_Git9.png)
+
+Sayfanın üst kısmında sekmelerin bir listesini göreceksiniz. Bunlar değişebilir ve yalnızca ihtiyaç duyduklarınızı göstermek üzere değiştirilebilir. Burada, bunların tümünü kullanmıyorum ve tüm depomun düzenli olduğundan emin olmak için bunları kaldırmalıyım.
+
+Öncelikle, sadece tartıştığımız kod sekmesi vardı, ancak bu sekmeler, bir depo içinde gezinirken her zaman mevcuttur, bu da bölümler arasında hızlı ve kolay geçiş yapmamıza olanak tanır. Sonraki olarak, sorunlar sekmesine sahibiz.
+
+Sorunlar sekmesi, GitHub'daki çalışmanızı takip etmenize olanak tanır. Gelişmenin gerçekleştiği yer. Bu belirli depoda diyagram eklemeye veya yazım hatalarını düzeltmeye odaklanan bazı sorunlarım olduğunu görebilirsiniz, ancak aynı zamanda depoya Çince bir sürümün gerektiğini belirten bir sorunumuz da var.
+
+Bu bir kod deposu olsaydı, bu, sahiplerle ilgili sorunları veya sorunları gündeme getirmek için harika bir yer olurdu, ancak raporladığınız şeyin ne olduğu konusunda dikkatli ve ayrıntılı olmayı unutmayın ve mümkün olduğunca çok ayrıntı verin.
+
+![](Images/Day40_Git10.png)
+
+Sonraki sekme pull requestlerdir. Pull requestleri, bir depodaki bir dalda ittiğiniz değişiklikleri başkalarına bildirmenizi sağlar. Bu, birinin depoyu çatallandığı, hataları düzelttiği veya özellikleri geliştirdiği veya bu depoda çoğu durumda sadece yazım hatalarını düzelttiği yerdir.
+
+Sonradan forklamayı ele alacağız.
+
+![](Images/Day40_Git11.png)
+
+Sanırım bir sonraki sekme oldukça yeni mi? Ama böyle bir projede, #90DaysOfDevOps gibi, içerik yolculuğunu yönlendirmeye yardımcı olabileceğini düşündüm, ancak aynı zamanda topluluğa öğrenme yolculukları sırasında yardımcı olabilir. Her meydan okuma bölümü için birkaç tartışma grubu oluşturdum, böylece insanlar katılarak tartışabilirler.
+
+![](Images/Day40_Git12.png)
+
+Eylemler sekmesi, kodu inşa etmenize, test etmenize, dağıtmanıza ve GitHub içinden çok daha fazlasını yapmanıza olanak tanır. GitHub Eylemleri, meydan okumanın CI/CD bölümünde ele alacağımız bir şeydir, ancak burada bize adımları otomatikleştirmek için yapılandırma ayarlayabileceğimiz yerdir.
+
+Ana GitHub Profilimde, ana ekranı güncel tutmak için en son blog yayınlarını ve YouTube videolarını almak için GitHub Eylemlerini kullanıyorum.
+
+![](Images/Day40_Git13.png)
+
+Yukarıda bahsettiğim gibi, GitHub sadece bir kaynak kod deposu değil, aynı zamanda bir proje yönetim aracıdır. Proje sekmesi, projeyi daha iyi işbirliği yapmak ve bu görevlerin görünürlüğünü sağlamak için sorunları ve PR'leri bağlayabileceğimiz kanban tipi panoları oluşturmamıza olanak tanır.
+
+![](Images/Day40_Git14.png)
+
+Sorunların bana iyi bir özellik talebi kaydetmek için uygun bir yer gibi görünmesine rağmen ve öyledir ancak wiki sayfası, mevcut durumu ile projenin kapsamlı bir yol haritasını oluşturmak için genelde sorunlarınıza daha iyi çözüm olabilecek belge veya sorun giderme tarzı içeriği oluşturmanıza olanak tanır.
+
+![](Images/Day40_Git15.png)
+
+Bu projeye pek uygulanamasa da, Güvenlik sekmesi, katkıda bulunanların belirli görevleri nasıl ele alması gerektiğini bildiğinden emin olmak için burada bir politika tanımlayabiliriz, ancak aynı zamanda kod tarama eklentileriyle kodunuzun örneğin gizli ortam değişkenleri içermediğinden emin olabiliriz.
+
+![](Images/Day40_Git16.png)
+
+Benim için Insights sekmesi harika, depo hakkında bu kadar çok bilgi sağlıyor, aktivite ne kadar sürdüğünden, taahhütler ve sorunlar hakkında raporlar da dahil olmak üzere, ayrıca depoya yönelik trafiği raporlar. Solda gördüğünüz bir liste, depo metrikleri hakkında detaylı bilgi almanıza olanak tanır.
+
+![](Images/Day40_Git17.png)
+
+Son olarak, Ayarlar sekmesi, depomuzu nasıl işleteceğimize dair ayrıntılara girebileceğimiz yerdir. Şu anda repo sadece benim tarafımdan yönetiliyor, ancak bu sorumluluğu burada paylaşabilirdik. Entegrasyonları ve diğer görevleri burada tanımlayabiliriz.
+
+![](Images/Day40_Git18.png)
+
+Bu, GitHub'ın hızlı bir genel bakışıydı. Daha ayrıntılı açıklamaya ihtiyaç duyabileceğimi düşündüğüm bazı diğer alanlar da var. Bahsedildiği gibi, GitHub milyonlarca depoyu barındırıyor, bunların çoğu kaynak kodunu içeriyor ve bunlar genel veya özel olarak erişilebilir.
+
+### Forking(Catallama)
+
+Yarınki oturumda daha fazla şekilde Açık Kaynaklı (Open-Source) konusuna gireceğim, ancak herhangi bir kod reposunun büyük bir parçası toplulukla işbirliği yapma yeteneğidir. Düşünün ki, bir repodan bir kopya istiyorum, çünkü üzerinde bazı değişiklikler yapmak istiyorum, belki bir hatayı düzeltmek istiyorum ya da belki de kodun orijinal bakımını yapan kişi için öngörülmeyen bir kullanım senaryosu için bir şeyi değiştirmek istiyorum. İşte bu duruma bir depoyu "forklamak" diyoruz. Bir fork, bir reposunun bir kopyasıdır. Bir deponun fork'lanması, orijinal projeyi etkilemeden değişikliklerle serbestçe denemenizi sağlar.
+
+Giriş yaptıktan sonra ana sayfaya geri döneyip önerilen repolardan birine bakalım.
+
+![](Images/Day40_Git19.png)
+
+Bu depoya tıklarsak, gerade 90DaysOfDevOps deposunda gezindiğimiz görünümü alacağız.
+
+![](Images/Day40_Git20.png)
+
+Aşağıya baktığımızda 3 seçeneğimiz var: izleme (watch), fork ve yıldız (star).
+
+- Watch - Depoya bir şeyler olduğunda güncellemeler alırsınız.
+- Fork - Bir deponun kopyası.
+- Star - "Projeni harika buluyorum"
+
+![](Images/Day40_Git21.png)
+
+Bu repoyu kopyalamak istediğimiz senaryomuz göz önünde bulundurulursa, fork seçeneğine tıklıyoruz. Birden fazla organizasyona üyeyseniz, fork'ün nerede gerçekleşeceğini seçmeniz gerekecektir. Ben profilimi seçmeyi tercih ediyorum.
+
+![](Images/Day40_Git22.png)
+
+Şimdi, bu repomuzun kopyasına sahibiz ve istediğimiz gibi özgürce üzerinde çalışabilir ve değişiklikler yapabiliriz. Bu, önce kısaca bahsettiğimiz "pull request" (çekme isteği) sürecinin başlangıcı olacak, ancak bunu yarın daha detaylı bir şekilde ele alacağız.
+
+![](Images/Day40_Git23.png)
+
+Peki, diyorsunuz, bu depoya ve koda nasıl değişiklik yapabilirim, çünkü bu bir web sitesinde; evet, web sitesi üzerinden düzenlemeler yapabilirsiniz, ancak bunu yerel sistemimizdeki favori IDE'nizle ve favori renk temasınızla yapmak gibi olmayacaktır. Bu depoyu yerel makinenize kopyalamak için deponun bir "clone"unu (kopyasını) oluşturacağız. Bu, yerelde çalışmamıza ve ardından deponun fork'lanmış kopyasına değişikliklerimizi geri itmemize olanak tanır.
+
+Kodun bu kopyasını elde etmek için birkaç seçeneğimiz var, aşağıda gördüğünüz gibi.
+
+GitHub Masaüstü uygulaması ile, yerel ve GitHub arasında değişiklikleri takip etmek ve çekmek (pull) ve göndermek (push) için görsel bir masaüstü uygulaması sunulur.
+
+Bu küçük demoda, üzerinde gördüğümüz HTTPS URL'sini kullanacağım.
+
+![](Images/Day40_Git24.png)
+
+Şimdi, yerel makinede, bu deponun indirilmesini kabul edeceğim bir dizine gidip `git clone url` komutunu çalıştıracağım.
+
+![](Images/Day40_Git25.png)
+
+Şimdi bunu VScode'a taşıyarak bazı değişiklikler yapalım.
+
+![](Images/Day40_Git26.png)
+
+Şimdi bazı değişiklikler yapalım, bu tüm bağlantıları değiştirip başka bir şey ile değiştirmek istiyorum.
+
+![](Images/Day40_Git27.png)
+
+Şimdi GitHub'a geri döner ve bu depodaki readme.md dosyasını buluruz, dosyada yaptığımız birkaç değişikliği görebilirsiniz.
+
+![](Images/Day40_Git28.png)
+
+Bu aşamada, bu tamamlanmış olabilir ve yeni değişikliğimizi sadece biz kullanacağımız için memnun olabiliriz, ancak belki de bir hata düzeltmesi idi ve eğer durum buysa, o zaman orijinal depo sahiplerine değişikliğimizi bildirmek ve onaylamalarını istemek için bir Pull Talebi (Pull Request) yoluyla katkıda bulunmak isteyeceğiz.
+
+Bunu aşağıda vurgulanan "contribute" düğmesini kullanarak yapabiliriz. Daha fazlasını yarın Açık Kaynaklı iş akışlarını incelediğimizde ele alacağım.
+
+![](Images/Day40_Git29.png)
+
+Uzun bir süre boyunca GitHub'ı inceledim ve bazılarınızın "peki diğer seçenekler ne?" dediğini duyuyorum!
+
+Evet, başka seçenekler de var ve bazı temel bilgileri kapsayan kaynaklar bulacağım. GitLab ve BitBucket gibi hizmetlerle karşılaşacaksınız ve bunlar git tabanlı hizmetlerdir, ancak farklılıkları vardır.
+
+Ayrıca barındırılan seçeneklerle de karşılaşacaksınız. En yaygın olarak GitLab'ı barındırılan bir versiyon olarak veya GitHub Enterprise'ı görmüşümdür (Ücretsiz bir barındırılan GitHub mı yoksa?).
+
+## Kaynaklar
+
+- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
+- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
+- [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)
+- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
+
+Gorusmek Uzere [Gun 41](day41.md)

2022/tr/Days/day41.md

@@ -0,0 +1,117 @@
+## Açık Kaynak İş Akışı
+
+Umarım, Git'in son 7 bölümünü inceledikten sonra git'in ne olduğunu ve ardından GitHub gibi bir git tabanlı hizmetin, kaynak kodu depolama alanını sağlamanın yanı sıra geniş topluluğun kod ve projeler üzerinde işbirliği yapabileceği bir yol olduğunu daha iyi anlamışsınızdır.
+
+GitHub temellerini incelediğimizde rastgele bir projeyi çatallama ve yerel depomuzda bir değişiklik yapma sürecini geçtik. Burada bir adım daha ileri gitmek ve açık kaynak bir projeye katkıda bulunmak istiyoruz. Unutmayın, katkıda bulunmak hata düzeltmeleri veya kodlama özellikleri olmak zorunda değildir, aynı zamanda belgeleme de olabilir. Her türlü katkı faydalı olur ve ayrıca üzerinde çalıştığımız bazı git işlevselliğiyle pratik yapmanıza olanak tanır.
+
+## Bir Projeyi Çatallama(Forklama)
+
+İlk yapmamız gereken katkıda bulunabileceğimiz bir proje bulmak. Yakın zamanda [Kanister Project](https://github.com/kanisterio/kanister) hakkında sunum yapmıştım ve şimdi YouTube'da bulunan sunumlarımı projenin ana readme.md dosyasında paylaşmak istiyorum.
+
+Öncelikle, projeyi çatalamamız gerekiyor. Bu süreci geçelim. Yukarıda paylaşılan bağlantıya gidip repoyu forklayacağım.
+
+![](Images/Day41_Git1.png)
+
+Artık tüm depomuzun bir kopyasına sahibiz.
+
+![](Images/Day41_Git2.png)
+
+Referans için, Readme.md dosyasındaki orijinal Sunumlar sadece şunlar, bu nedenle işlemimizi düzeltmemiz gerekiyor.
+
+![](Images/Day41_Git3.png)
+
+## Yerel Makineye Klonlama
+
+Şimdi çatalımızı yerelimize getirebilir ve ardından dosyalara düzenlemeler yapmaya başlayabiliriz. Repo üzerindeki kod düğmesini kullanarak URL'yi alabilir ve ardından `git clone url` komutunu, depoyu koymak istediğimiz bir dizinde kullanabiliriz.
+
+![](Images/Day41_Git4.png)
+
+## Değişikliklerimizi Yapmak
+
+Projemizi yerelde sahip olduğumuz için, VSCode veya tercih ettiğiniz bir IDE veya metin düzenleyiciyi açarak değişikliklerinizi ekleyebilirsiniz.
+
+![](Images/Day41_Git5.png)
+
+readme.md dosyası markdown dilinde yazıldığı için ve başka birinin projesini değiştirdiğimiz için, mevcut proje biçimini takip ederek içeriğimizi eklemek istiyorum.
+
+![](Images/Day41_Git6.png)
+
+## Değişikliklerinizi Test Etme
+
+En iyi uygulama olarak değişikliklerimizi test etmeliyiz; bu, bu bir uygulamanın kodunda bir değişiklik olduğunda, kod değişikliğinden sonra uygulamanın hala çalıştığından emin olmak isteyeceğiniz gibi, belgelerin de düzgün biçimlendirilip görünüp görünmediğinden emin olmak anlamına gelir.
+
+VSCode'da birçok eklenti ekleyebiliriz; bunlardan biri markdown sayfalarını önizleme yeteneğidir.
+
+![](Images/Day41_Git7.png)
+
+## Değişiklikleri Forklu Repomuzu Geri Yollayalım
+
+Forklu repomuza doğrudan değişiklikleri itmek için kimlik doğrulamamız yok, bu nedenle bu yolu takip etmeliyiz. Değişikliklerimizden memnun olduğumuzda, artık iyi bilinen bazı git komutlarını inceleyebiliriz.
+
+![](Images/Day41_Git8.png)
+
+Şimdi GitHub'a geri dönüp değişiklikleri bir kez daha kontrol edip ana projeye katkıda bulunabiliriz.
+
+Görünüşe bakılırsa iyi durumda.
+
+![](Images/Day41_Git9.png)
+
+Şimdi, Kanister için forklu repomuzun en üstüne dönebilir ve kanisterio:master dalına göre 1 taahhüt ileride olduğumuzu görebiliriz.
+
+![](Images/Day41_Git10.png)
+
+Sonraki adım olarak, yukarıda vurgulanan "Katıl" düğmesine tıklıyoruz. "Pull Talebi Aç" seçeneğini görüyoruz.
+
+![](Images/Day41_Git11.png)
+
+## Bir Pull Request Açın
+
+Bu sonraki görüntüde oldukça fazla detay bulunuyor. Sol üst köşede, şu an orijinal veya ana deposunda olduğumuzu görebilirsiniz. Ardından, karşılaştırdığımız şeyi görebilirsiniz ve bu orijinal ana deposu ile forklu repomuzdur. Daha sonra bir pull talebi oluştur düğmesini görebilirsiniz, bu konuya yakında geri döneceğiz. Tek bir commitiniz var, ancak bu daha fazla değişiklik olsaydı, burada birden fazla commitiniz olabilir. Ardından, readme.md dosyasında yaptığımız değişiklikleri görebilirsiniz.
+
+![](Images/Day41_Git12.png)
+
+Yukarıdaki değişiklikleri gözden geçirdik ve yeşil düğmeye basarak bir pull talebi oluşturmaya hazırız.
+
+Sonrasında, bir projenin bakımcısı, pull talebi işlevselliğini depolarındaki nasıl düzenlediğine bağlı olarak, size ne görmek istediğini gösteren bir şablonunuz olup olmadığını belirtebilir.
+
+Burada yine, ne yaptığınıza dair anlamlı bir açıklama yapmak istersiniz, net ve öz ama yeterli detay içermeli. Ben basit bir değişiklik özetini yapmışım ve dökümantasyon işaretlemesini seçtim.
+
+![](Images/Day41_Git13.png)
+
+## Bir Pull Request Olusturun
+
+Şimdi pull talebi oluşturmaya hazırız. Sayfanın üst kısmındaki "Pull Talebi Oluştur" düğmesine tıkladıktan sonra pull talebinizin bir özetini göreceksiniz.
+
+![](Images/Day41_Git14.png)
+
+Aşağı doğru kaydırdığınızda, otomasyonun gerçekleştiğini görebilirsiniz; bu durumda bir inceleme gereklidir ve bazı kontroller gerçekleştirilmektedir. Travis CI'nin devam ettiğini ve bir derleme işleminin başladığını görebiliriz. Bu işlem, eklemelerimizle bir şeylerin bozulmadığından emin olmak için yapılır.
+
+![](Images/Day41_Git15.png)
+
+Burada dikkat edilmesi gereken bir diğer nokta, yukarıdaki ekran görüntüsündeki kırmızının biraz korkutucu görünebileceğidir ve sanki hatalar yapmış gibi görünebilir! Endişelenmeyin, herhangi bir şeyi bozmadınız, en büyük ipucum burada, bu sürecin size ve projenin bakımından sorumlu olanlara yardımcı olmak için olduğudur. Hata yapmışsanız, en azından benim deneyimimden yola çıkarak, projenin bakımcısı size ulaşacak ve ne yapmanız gerektiği konusunda tavsiyede bulunacaktır.
+
+Bu pull talebi artık herkes tarafından görülebilir durumda [added Kanister presentation/resource #1237](https://github.com/kanisterio/kanister/pull/1237)
+
+Ben bunu yayımlamadan önce, birleştirme ve pull talepleri (PR) kabul edilmeden önce yayımlayacağım, bu nedenle hala takip eden ve başarılı bir PR'ı ekleyebilen herkese küçük bir ödül kazanmak için bir fırsat sağlayabiliriz.
+
+1. Forkla bu repoyu kendi GitHub hesabına
+2. Resminizi ve belki de metni ekleyin.
+3. Değişiklikleri forkladıgınız reposuna gönderin.
+4. Benim göreceğim ve onaylayacağım bir PR oluşturun.
+5. Bir tür ödül düşüneceğim.
+
+Bu, Git ve GitHub'a bakışımızı sonlandırıyor, bir sonraki adım olarak konteynerlere dalıyoruz, bu da büyük resmi bir bakış açısıyla başlıyor, neden konteynerler ve sanallaştırma konularına göz atıyoruz ve nasıl buraya geldiğimize bakıyoruz.
+
+## Kaynaklar
+
+- [Learn GitLab in 3 Hours | GitLab Complete Tutorial For Beginners](https://www.youtube.com/watch?v=8aV5AxJrHDg)
+- [BitBucket Tutorials Playlist](https://www.youtube.com/watch?v=OMLh-5O6Ub8&list=PLaD4FvsFdarSyyGl3ooAm-ZyAllgw_AM5)
+- [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)
+- [Git cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
+
+Gorusmek Uzere [Gun 42](day42.md)

2022/tr/Days/day42.md

@@ -0,0 +1,124 @@
+## Containers(Konteynerlar)
+
+Şimdi yeni bir bölüme başlıyoruz ve bu bölüm, özellikle Docker'a odaklanacak ve Konteynerler hakkında daha fazla anlayış kazanmak için bazı temel konulara odaklanacak.
+
+Ayrıca, bu bölümde ve ilerleyen zorlukların sonraki bölümlerinde kullanabileceğimiz bir konteyner oluşturmak için burada pratik yapmaya çalışacağım.
+
+Her zamanki gibi, bu ilk gönderi, nasıl buraya geldiğimiz ve bunun ne anlama geldiği hakkında büyük resme odaklanacaktır.
+
+#Platformların ve uygulama geliştirmenin tarihi
+#Sanallaştırma ve Konteynerleştirme hakkında konuşmak istiyor muyuz?
+
+### Neden başka bir uygulama çalıştırma yöntemi?
+
+Bakmamız gereken ilk şey, neden yazılım veya uygulamalarımızı çalıştırmak için başka bir yönteme ihtiyacımız var? İşte sadece seçeneğin harika olmasıyla ilgili, uygulamalarımızı birçok farklı şekilde çalıştırabiliriz. Fiziksel donanıma sahip bir işletim sistemi ve tek bir uygulamanın dağıtıldığı durumları görebiliriz veya uygulamamızı çalıştıran sanal makine veya bulut tabanlı IaaS örneklerini görebiliriz, bunlar daha sonra bir veritabanına entegre olabilir veya kamu bulutunda bir PaaS teklifi olarak sunulabilir. Veya uygulamalarımızı konteynerlerde çalıştırırken görebiliriz.
+
+Yukarıdaki seçeneklerin hiçbiri yanlış veya doğru değil, ancak her birinin var olma nedenleri vardır ve ayrıca bu seçeneklerden hiçbirinin ortadan kalkacağına inanmıyorum. Konteynerler vs. Sanal Makineler gibi konuları ele alan birçok içerik gördüm ve gerçekten bir tartışma olmamalı çünkü bu daha çok elma ile armut karşılaştırması gibi bir şey, her ikisi de meyve (uygulamalarımızı çalıştırmanın yolları) olsa da aynı değil.
+
+Ayrıca, eğer başlıyorsanız ve bir uygulama geliştiriyorsanız, konteynerlere doğru yönelmeniz gerektiğini söylerim, çünkü bu konulara daha sonra değineceğiz, ancak bu verimlilik, hız ve boyutla ilgilidir. Ancak bunun bir bedeli vardır, konteynerler hakkında hiçbir fikriniz yoksa, nedenini anlamak ve bu zihniyete girmek için bir öğrenme eğrisi olacaktır. Eğer uygulamalarınızı belirli bir şekilde geliştirdiyseniz veya yeşil saha bir ortamda değilseniz, konteynerleri düşünmeden önce ele almanız gereken daha fazla zorluk yaşayabilirsiniz.
+
+Belirli bir yazılım parçasını indirme konusunda birçok farklı seçeneğimiz var, kullanabileceğimiz bir dizi farklı işletim sistemi var. Ve uygulamalarımızı nasıl kurmamız gerektiği için belirli talimatlar mevcut.
+
+![](Images/Day42_Containers1.png)
+
+Son zamanlarda giderek daha fazla gözlemliyorum ki bir zamanlar tam bir sunucu işletim sistemine, bir sanal makineye, fiziksel bir sunucuya veya bulut örneğine ihtiyaç duyduğumuz uygulamalar, şimdi yazılımlarının konteyner tabanlı sürümlerini yayınlıyorlar. Bu durumu ilginç buluyorum çünkü bu, konteynerlerin ve ardından herkese değil sadece uygulama geliştiricilerine odaklanmayı açan Kubernetes dünyasını herkese açıyor gibi görünüyor.
+
+![](Images/Day42_Containers2.png)
+
+Muhtemelen daha önce söylediğim gibi, cevabın ne olduğunu söyleyeceğimi savunmayacağım, soru nedir! Ama uygulamalarımızı dağıttığımızda farkında olmamız gereken başka bir seçenek olduğunu tartışmak istiyorum.
+
+![](Images/Day42_Containers4.png)
+
+Uzun bir süredir konteyner teknolojimiz var, o zaman neden son 10 yılda, son 5 yılda daha da popüler hale geldiğini söyleyebilirim. Onlarca yıldır konteynerlerimiz var. Bunun nedeni, sadece konteyner teknolojisine sahip olsak bile, yazılım yönetimi ile yaşadığımız aynı sorunlara sahip olmamızdır.
+
+Docker'ı bir araç olarak düşünürsek, popüler hale gelmesinin nedeni, kullanımı kolay ve bulması kolay görüntüler ekosistemidir. Sistemlerinize almak ve çalıştırmak kolaydır. Bunun büyük bir kısmı, yazılım ile karşılaştığımız tüm bu farklı zorlukların tamamında tutarlılıktır. MongoDB veya nodeJS olsun, her ikisini de çalıştırmak için izlenen süreç aynı olacaktır. Her ikisini durdurma süreci de aynıdır. Tüm bu sorunlar hala var olacak, ancak iyi bir konteyner ve görüntü teknolojisini bir araya getirdiğimizde, artık tüm bu farklı sorunları ele almamıza yardımcı olacak tek bir araç setine sahibiz. Bu sorunların bazıları aşağıda listelenmiştir:
+
+- İlk olarak, internet üzerinde yazılım bulmamız gerekiyor.
+- Ardından bu yazılımı indirmemiz gerekiyor. 
+- Kaynağa güveniyor muyuz?
+- Sonra bir lisansa mı ihtiyacımız var? Hangi lisans? 
+- Farklı platformlarla uyumlu mu?
+- Paket nedir? İkili mi? Yürütülebilir mi? Paket yöneticisi mi? 
+- Yazılımı nasıl yapılandırırız?
+- Bağımlılıklar? Genel indirme işini örttü mü, yoksa bunları da mı gerektiriyor?
+- Bağımlılıkların bağımlılıkları?
+- Uygulamayı nasıl başlatırız? 
+- Uygulamayı nasıl durdururuz?
+- Otomatik yeniden başlar mı? 
+- Başlangıçta otomatik başlar mı?? 
+- Kaynak çatışmaları? 
+- Çakışan kütüphaneler? 
+- Port cakısmaları
+- Yazılım için güvenlik?
+- Yazılım güncellemeleri?
+- Yazılımı nasıl kaldırabilirim?? 
+
+Yukarıdakileri yazılımın karmaşıklığının üç alanına bölebiliriz ve konteynerler ve görüntüler bu konularda yardımcı olurlar
+
+| Distribution | Installation | Operation          |
+| ------------ | ------------ | -----------------  |
+| Find         | Install      | Start              |
+| Download     | Configuration| Security           |
+| License      | Uninstall    | Ports              |
+| Package      | Dependencies | Resource Conflicts |
+| Trust        | Platform     | Auto-Restart       |
+| Find         | Libraries    | Updates            |
+
+Konteynerler ve görüntüler, muhtemelen diğer yazılım ve uygulamalarda yaşadığımız bazı zorlukları aşmamıza yardımcı olacak. 
+
+Yüksek seviyede, kurulumu ve işletmeyi aynı liste taşıyabiliriz, Görüntüler bize bir dağıtım açısından yardımcı olurken, konteynerler kurulum ve işletme konularına yardımcı olur.
+
+Tahminen harika ve heyecan verici gelebilir, ancak hala bir konteynerin ne olduğunu anlamamız gerekiyor ve şimdi görüntülerden bahsettim, bu yüzden bir sonraki bölümde bu konuları ele alalım.
+
+Yazılım geliştirme için Konteynerler hakkında konuşurken sıkça gördüğünüz bir diğer şey, gemi konteynerleri ile birlikte kullanılan bir benzetme, denizlerin üzerinde büyük gemiler kullanılarak çeşitli malların taşınmasında gemi konteynerlerinin kullanıldığı bir gerçektir.
+
+![](Images/Day42_Containers5.png)
+
+Bu, konteynerler konusundaki konumuzla ne ilgisi var? Yazılım geliştiricilerinin yazdığı kodları düşünün, bu belirli kodu bir makineden başka bir makineye nasıl taşıyabiliriz?
+
+Önce yazılım dağıtımı, kurulum ve işletmeye dokunduğumuz şeyi düşünürsek ve şimdi bunu bir çevresel görsel olarak inşa etmeye başlarsak, donanım ve bir işletim sistemi ile birden fazla uygulama çalıştıracağınız bir ortamınız var. Örneğin, nodejs belirli bağımlılıklara ve belirli kütüphanelere ihtiyaç duyar. Daha sonra MySQL'i yüklemek istiyorsanız, gerekli kütüphaneler ve bağımlılıklara ihtiyaç duyar. Her yazılım uygulamasının kendi kütüphanesi ve bağımlılığı olacaktır. Özel kütüphaneler ve bağımlılıkların çakıştığı ve sorunlara yol açtığı özel bir durumumuz olmadıkça, herhangi bir uygulama arasında çakışma olasılığının daha fazla olduğu daha fazla uygulama olacaktır. Bununla birlikte, bu yalnızca her şeyin yazılım uygulamalarınızı düzelten bir dağıtım olduğu bir durum değildir, yazılım uygulamalarınız güncellenecek ve bu çakışmaları da tanıtabiliriz.
+
+![](Images/Day42_Containers6.png)
+
+Konteynerler bu sorunu çözmeye yardımcı olabilir. Konteynerler uygulamanızı **inşa etme**nize, uygulamayı **paketleme**nize, **dağıtma**nıza ve **ölçeklendirme**nize yardımcı olur. Mimarisine bir göz atalım, donanım ve işletim sisteminizin üzerinde daha sonra ele alacağımız bir konteyner motoruna sahip olacaksınız. Konteyner motoru yazılımları, uygulamanın ihtiyaç duyduğu kütüphaneleri ve bağımlılıkları paketleyen konteynerler oluşturmanıza yardımcı olur, bu nedenle bu konteyneri bir makineden diğerine sorunsuzca taşıyabilirsiniz ve uygulamanın çalışması için gereken kütüphaneler ve bağımlılıklar hakkında endişelenmeniz gerekmez, çünkü bunlar bir paketin parçası olarak gelir, ki bu da konteynerden başka bir şey değildir, bu nedenle farklı konteynerlere sahip olabilirsiniz ve bu konteyneri sistemler arasında taşıyabilirsinizken uygulamanın çalışması için gerekli olan altta yatan bağımlılıklardan endişelenmeden.
+
+![](Images/Day42_Containers7.png)
+
+### Bu Containerların Avantajları
+
+- Konteynerler, tüm bağımlılıkları içinde paketlemeye ve izole etmeye yardımcı olur.
+
+- Konteynerleri yönetmek kolaydır.
+
+- Bir sistemden diğerine taşımak kolaydır.
+
+- Konteynerler, yazılımı paketlemeye yardımcı olur ve herhangi bir tekrar çaba gerektirmeden kolayca taşıyabilirsiniz.
+
+- Konteynerler kolayca ölçeklenebilir.
+
+Konteynerleri kullanarak bağımsız konteynerleri ölçeklendirebilir ve bir yük dengeleyici veya hizmet kullanabilirsiniz, bu da trafiği bölmeye yardımcı olur ve uygulamaları yatay olarak ölçeklendirebilirsiniz. Konteynerler, uygulamalarınızı nasıl yönettiğinizde büyük bir esneklik ve kolaylık sunar.
+
+### Container Nedir? 
+
+Bilgisayarlarımızda uygulamaları çalıştırdığımızda, bu web tarayıcısı veya bu yazıyı okumak için kullandığınız VScode gibi bir şey olabilir. Bu uygulama, bir işlem olarak çalışır veya işlem olarak bilinen bir şeydir. Dizüstü bilgisayarlarımız veya sistemlerimizde genellikle birden fazla uygulama veya işlem çalıştırmaya çalışırız. Yeni bir uygulama açtığımızda veya uygulama simgesine tıkladığımızda, çalıştırmak istediğimiz bir uygulamadır; bazen bu uygulama sadece arka planda çalışmasını istediğimiz bir hizmet olabilir. İşletim sistemimiz, arka planda çalışan ve sistemle ilgili kullanıcı deneyimini sağlayan birçok hizmetle doludur.
+
+Bu uygulama simgesi, dosya sisteminizdeki bir yürütülebilir dosyaya bir bağlantıyı temsil eder; işletim sistemi daha sonra bu yürütülebilir dosyayı belleğe yükler. İlginç bir şekilde, bu yürütülebilir dosya bazen bir işlem hakkında konuştuğumuzda bir görüntü olarak adlandırılır.
+
+Konteynerler işlemlerdir. Bir konteyner, kodu ve tüm bağımlılıklarını paketleyen standart bir yazılım birimidir, böylece uygulama bir hesaplama ortamından başka birine hızlı ve güvenilir bir şekilde çalışır.
+
+Konteynerleştirilmiş yazılım her zaman altyapıdan bağımsız olarak aynı şekilde çalışacaktır. Konteynerler yazılımı ortamından izole eder ve geliştirme ve sahneleme gibi farklılıklar olsa bile aynı şekilde çalışmasını sağlar.
+
+Önceki bölümde, konteynerlerin neden ve nasıl popüler hale geldiği konusunda konteynerler ve görüntülerin nasıl birleştiğinden bahsettim.
+
+### Image Nedir? 
+
+Bir konteyner görüntüsü, bir uygulamayı çalıştırmak için gereken her şeyi içeren hafif, bağımsız, yürütülebilir bir yazılım paketidir: kod, çalıştırma zamanı (runtime), sistem araçları, sistem kütüphaneleri ve ayarlar. Konteyner görüntüleri, çalışma zamanında konteynerlere dönüşürler.
+
+## Kaynaklar 
+
+- [TechWorld with Nana - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=3c-iBn73dDE)
+- [Programming with Mosh - Docker Tutorial for Beginners](https://www.youtube.com/watch?v=pTFZFxd4hOI)
+- [Docker Tutorial for Beginners - What is Docker? Introduction to Containers](https://www.youtube.com/watch?v=17Bl31rlnRM&list=WL&index=128&t=61s)
+- [Introduction to Container By Red Hat](https://www.redhat.com/en/topics/containers)
+
+Gorusmek Uzere [Gun 43](day43.md) 

2023.md

@@ -4,6 +4,8 @@
  <img src="logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
 </p>
 
+English Version | [한국어](2023/ko/README.md)
+
 This repository is used to document my journey on getting a better foundational knowledge of "DevOps".
 
 [![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/N4N33YRCS)
@@ -156,7 +158,6 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
 
 ### Engineering for Day 2 Ops
 
-
 - [✔️] 👷🏻‍♀️ 84 > [Writing an API - What is an API?](2023/day84.md)
 - [✔️] 👷🏻‍♀️ 85 > [Queues, Queue workers and Tasks (Asynchronous architecture)](2023/day85.md)
 - [✔️] 👷🏻‍♀️ 86 > [Designing for Resilience, Redundancy and Reliability](2023/day86.md)

2023/ko/2023.md

@@ -0,0 +1,169 @@
+# 90DaysOfDevOps
+
+<p align="center">
+ <img src="logo.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
+</p>
+
+이 레포지토리는 "DevOps" 의 기본적인 지식을 학습해 나가기 위한 저의 여정을 문서화 하기 위해 사용됩니다.
+
+[![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/N4N33YRCS)
+
+If you have questions and want to get involved then join the discord and share your questions and stories with the community.
+질문이 있거나 디스코드에 참여하거나 당신의 경험 또는 질문을 커뮤니티에 공유하고 싶다면,
+
+[![](https://dcbadge.vercel.app/api/server/vqwPrNQsyK)](https://discord.gg/vqwPrNQsyK)
+
+혹은 트위터를 통해 연락 주세요. 제 트위터 핸들은 [@MichaelCade1](https://twitter.com/MichaelCade1) 입니다. 아래에 링크된 트위터를 통해 2023년의 글쓴이들에게 연락할 수도 있습니다.
+
+## List of Topics
+
+| Topic                                  | Author                              | Date                | Twitter Handle                                                                                  |
+| -------------------------------------- | ----------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------- |
+| DevSecOps                              | Michael Cade                        | 1st Jan - 6th Jan   | [@MichaelCade1](https://twitter.com/MichaelCade1)                                               |
+| Secure Coding                          | Prateek Jain                        | 7th Jan - 13th Jan  | [@PrateekJainDev](https://twitter.com/PrateekJainDev)                                           |
+| Continuous Build, Integration, Testing | Anton Sankov and Svetlomir Balevski | 14th Jan - 20th Jan | [@a_sankov](https://twitter.com/a_sankov)                                                       |
+| Continuous Delivery & Deployment       | Anton Sankov                        | 21st Jan - 27th Jan | [@a_sankov](https://twitter.com/a_sankov)                                                       |
+| Runtime Defence & Monitoring           | Ben Hirschberg                      | 28th Jan - 3rd Feb  | [@slashben81](https://twitter.com/slashben81)                                                   |
+| Secrets Management                     | Bryan Krausen                       | 4th Feb - 10th Feb  | [@btkrausen](https://twitter.com/btkrausen)                                                     |
+| Python                                 | Rishab Kumar                        | 11th Feb - 17th Feb | [@rishabk7](https://twitter.com/rishabk7)                                                       |
+| AWS                                    | Chris Williams                      | 18th Feb - 24th Feb | [@mistwire](https://twitter.com/mistwire)                                                       |
+| OpenShift                              | Dean Lewis                          | 25th Feb - 3rd Mar  | [@saintdle](https://twitter.com/saintdle)                                                       |
+| Databases                              | Taylor Riggan & Andrew Pruski       | 4th Mar - 10th Mar  | [@triggan](https://twitter.com/triggan) & [@dbafromthecold](https://twitter.com/dbafromthecold) |
+| Serverless                             | Kristi Perreault                    | 11th Mar - 17th Mar | [@kperreault95](https://twitter.com/kperreault95)                                               |
+| Service Mesh                           | Marino Wijay                        | 18th Mar - 24th Mar | [@virtualized6ix](https://twitter.com/virtualized6ix)                                           |
+| Engineering for Day 2 Ops              | Alistair Hey                        | 25th Mar - 31st Mar | [@alistair_hey](https://twitter.com/alistair_hey)                                               |
+
+## Progress
+
+- [✔️] ♾️ 1 > [2022 Reflection & Welcome 2023](2023/day01.md)
+
+### DevSecOps
+
+- [✔️] ♾️ 2 > [The Big Picture: DevSecOps](2023/day02.md)
+- [✔️] ♾️ 3 > [Think like an Attacker](2023/day03.md)
+- [✔️] ♾️ 4 > [Red Team vs. Blue Team](2023/day04.md)
+- [✔️] ♾️ 5 > [OpenSource Security](2023/day05.md)
+- [✔️] ♾️ 6 > [Hands-On: Building a weak app](2023/day06.md)
+
+### Secure Coding
+
+- [✔️] 🔐 7 > [Secure Coding Overview](2023/day07.md)
+- [✔️] 🔐 8 > [SAST Overview](2023/day08.md)
+- [✔️] 🔐 9 > [SAST Implementation with SonarCloud](2023/day09.md)
+- [✔️] 🔐 10 > [Software Composition Analysis Overview](2023/day10.md)
+- [✔️] 🔐 11 > [SCA Implementation with OWASP Dependency Check](2023/day11.md)
+- [✔️] 🔐 12 > [Secure Coding Practices](2023/day12.md)
+- [✔️] 🔐 13 > [Additional Secure Coding Practices](2023/day13.md)
+
+### Continuous Build, Integration, Testing
+
+- [✔️] ⚒️ > [Container Image Scanning](2023/day14.md)
+- [✔️] ⚒️ > [Container Image Scanning Advanced](2023/day15.md)
+- [✔️] ⚒️ > [Fuzzing](2023/day16.md)
+- [✔️] ⚒️ > [Fuzzing Advanced](2023/day17.md)
+- [✔️] ⚒️ > [DAST](2023/day18.md)
+- [✔️] ⚒️ > [IAST](2023/day19.md)
+- [✔️] ⚒️ > [Practical Lab on IAST and DAST](2023/day20.md)
+
+### Continuous Delivery & Deployment
+
+- [✔️] 🚚 21 > [Continuous Image Repository Scan](2023/day21.md)
+- [✔️] 🚚 22 > [Continuous Image Repository Scan - Container Registries](2023/day22.md)
+- [✔️] 🚚 23 > [Artifacts Scan](2023/day23.md)
+- [✔️] 🚚 24 > [Signing](2023/day24.md)
+- [✔️] 🚚 25 > [Systems Vulnerability Scanning](2023/day25.md)
+- [✔️] 🚚 26 > [Containers Vulnerability Scanning](2023/day26.md)
+- [✔️] 🚚 27 > [Network Vulnerability Scan](2023/day27.md)
+
+### Runtime Defence & Monitoring
+
+- [✔️] 🏃 28 > [System monitoring and auditing](2023/day28.md)
+- [✔️] 🏃 29 > [Application level monitoring](2023/day29.md)
+- [✔️] 🏃 30 > [Detecting suspicious application behavior](2023/day30.md)
+- [✔️] 🏃 31 > [Runtime network protections and policies](2023/day31.md)
+- [✔️] 🏃 32 > [Vulnerability and patch management](2023/day32.md)
+- [✔️] 🏃 33 > [Application runtime and network policies](2023/day33.md)
+- [✔️] 🏃 34 > [Runtime access control](2023/day34.md)
+
+### Secrets Management
+
+- [✔️] 🕵 35 > [Understanding the Importance of Secrets Management](2023/day35.md)
+- [✔️] 🕵 36 > [Securing Secrets with HashiCorp Vault](2023/day36.md)
+- [✔️] 🕵 37 > [Working with HashiCorp Vault's Secrets Engines](2023/day37.md)
+- [✔️] 🕵 38 > [Increase the Security Posture of Your Organization with Dynamic Credentials](2023/day38.md)
+- [✔️] 🕵 39 > [Getting Hands-On with HashiCorp Vault](2023/day39.md)
+- [] 🕵 40 > [](2023/day40.md)
+- [] 🕵 41 > [](2023/day41.md)
+
+### Python
+
+- [✔️] 🐍 42 > [Programming Language: Introduction to Python](2023/day42.md)
+- [✔️] 🐍 43 > [Python Loops, functions, modules and libraries](2023/day43.md)
+- [✔️] 🐍 44 > [Data Structures and OOP in Python](2023/day44.md)
+- [✔️] 🐍 45 > [Debugging, testing and Regular expression](2023/day45.md)
+- [✔️] 🐍 46 > [Web development in Python](2023/day46.md)
+- [✔️] 🐍 47 > [Automation with Python](2023/day47.md)
+- [✔️] 🐍 48 > [Let's build an App in Python](2023/day48.md)
+
+### AWS
+
+- [✔️] ☁️ 49 > [AWS Cloud Overview](2023/day49.md)
+- [✔️] ☁️ 50 > [Create Free Tier Account & Enable Billing Alarms](2023/day50.md)
+- [✔️] ☁️ 51 > [Infrastructure as Code (IaC) and CloudFormation](2023/day51.md)
+- [✔️] ☁️ 52 > [Identity and Access Management (IAM)](2023/day52.md)
+- [✔️] ☁️ 53 > [AWS Systems Manager](2023/day53.md)
+- [✔️] ☁️ 54 > [AWS CodeCommit](2023/day54.md)
+- [✔️] ☁️ 55 > [AWS CodePipeline](2023/day55.md)
+
+### Red Hat OpenShift
+
+- [✔️] ⛑️ 56 > [What does Red Hat OpenShift bring to the party? An Overview](2023/day56.md)
+- [✔️] ⛑️ 57 > [Understanding the OpenShift Architecture, Installation Methods and Process](2023/day57.md)
+- [✔️] ⛑️ 58 > [Deploying Red Hat OpenShift on VMware vSphere](2023/day58.md)
+- [✔️] ⛑️ 59 > [Deploying applications and getting a handle on Security Constraints Context (SCC)](2023/day59.md)
+- [✔️] ⛑️ 60 > [Looking at OpenShift Projects - Creation, Configuration and Governance](2023/day60.md)
+- [✔️] ⛑️ 61 > [Understanding Authentication, Role-Based Access Control (RBAC) and Auditing in Red Hat OpenShift: Control and Secure Your Cluster](2023/day61.md)
+- [✔️] ⛑️ 62 > [Compliance and Vulnerability Scanning provided by Red Hat OpenShift Operators](2023/day62.md)
+
+### Databases
+
+- [✔️] 🛢 63 > [An introduction to databases](2023/day63.md)
+- [✔️] 🛢 64 > [Querying data in databases](2023/day64.md)
+- [✔️] 🛢 65 > [Backing up and restoring databases](2023/day65.md)
+- [✔️] 🛢 66 > [High availability and disaster recovery](2023/day66.md)
+- [✔️] 🛢 67 > [Performance tuning](2023/day67.md)
+- [✔️] 🛢 68 > [Database security](2023/day68.md)
+- [✔️] 🛢 69 > [Monitoring and troubleshooting database issues](2023/day69.md)
+
+### Serverless
+
+- [✔️] 👩🏿‍💻 70 > [What is Serverless?](2023/day70.md)
+- [✔️] 👩🏿‍💻 71 > [Serverless Compute](2023/day71.md)
+- [✔️] 👩🏿‍💻 72 > [Serverless Storage](2023/day72.md)
+- [✔️] 👩🏿‍💻 73 > [Serverless APIs](2023/day73.md)
+- [✔️] 👩🏿‍💻 74 > [Serverless Orchestration](2023/day74.md)
+- [✔️] 👩🏿‍💻 75 > [Serverless & Well Architected](2023/day75.md)
+- [✔️] 👩🏿‍💻 76 > [Serverless - Beyond the Basics](2023/day76.md)
+
+### Service Mesh
+
+- [✔️] 🧩 77 > [Let's break down a Service Mesh](2023/day77.md)
+- [✔️] 🧩 78 > [Install and Test a Service Mesh](2023/day78.md)
+- [✔️] 🧩 79 > [Comparing Different Service Meshes](2023/day79.md)
+- [✔️] 🧩 80 > [Traffic Engineering Basics](2023/day80.md)
+- [✔️] 🧩 81 > [Observability in your Mesh](2023/day81.md)
+- [✔️] 🧩 82 > [Securing your microservices](2023/day82.md)
+- [✔️] 🧩 83 > [Sidecar or Sidecar-less? Enter Ambient Mesh](2023/day83.md)
+
+### Engineering for Day 2 Ops
+
+- [✔️] 👷🏻‍♀️ 84 > [Writing an API - What is an API?](2023/day84.md)
+- [✔️] 👷🏻‍♀️ 85 > [Queues, Queue workers and Tasks (Asynchronous architecture)](2023/day85.md)
+- [✔️] 👷🏻‍♀️ 86 > [Designing for Resilience, Redundancy and Reliability](2023/day86.md)
+- [✔️] 👷🏻‍♀️ 87 > [Zero Downtime Deployments](2023/day87.md)
+- [✔️] 👷🏻‍♀️ 88 > [Monitoring, Alerting and On-Call](2023/day88.md)
+- [✔️] 👷🏻‍♀️ 89 > [Oops: When something goes wrong - Post Mortems](2023/day89.md)
+
+### 2023 wrap up
+
+- [✔️] 🏁 90 > [Wrapping up the 2023 edition](2023/day90.md)

2023/ko/days/day01.md

@@ -0,0 +1,65 @@
+## 2022 회고와 2023년의 환영사
+
+2023년 버전의 #90DaysOfDevOps에 오신 여러분을 환영합니다. 이 첫번째 게시물에서는 2022버전에 대한 회고와 통계, 피드백, 그리고 올해(2023)에 대한 아이디어를 이야기해보고자 합니다.
+
+### 2022 요약
+
+먼저, 와우! 2021년 12월 31일 새해 이브에 생각한 미션은 2022년 처음 90일 동안을 보내며 배우고 그 학습을 문서화하는 것이었어요. 사실 유튜브에서 저보다 훨씬 똑똑한 사람들의 영상을 시청한 후에 어떤 내용들을 기록하려고 했죠.
+
+1년이 지나서, 이제 우리의 레포지토리에는 놀라운 숫자들이 있습니다. 레포지토리 어딘가에 언급했던 것 같긴 하지만, 다른 곳에서도 여러 번 말한 적이 있습니다. 어떤 내용이든 단 하나의 사람에게라도 도움이 된다면 그 가치가 있다고 생각합니다. 우리가 여기서 별을 받은 것부터 포크까지의 숫자들을 가지고 있다는 것은 놀라운 일이에요.
+
+![](images/day01-1.jpg)
+
+또한, 거의 **500**명의 사람이 이 레포지토리를 보고 있어요!
+
+먼저, 이 레포지토리를 커뮤니티와 공유한 모두에게 감사하고 싶습니다. 마이크로소프트와 그와 같은 규모의 거대한 기술 벤더들이 이 레포지토리를 공유했다는 소식을 접하고 겸손한 마음이 들었습니다.
+
+둘째로, 이 레포지토리의 기여자들에게 감사하고 싶습니다. 이 레포지토리는 공개적으로 학습하고 메모를 정리하는 공간으로 시작되었는데, 처음 몇 일 동안은 사람들이 제 부족한 철자와 문법을 고쳐주고 있었어요. (확실히 올해에도 같은 일이 벌어질 것이라고 확신합니다.) 하지만 가장 크고 놀라운 일은 커뮤니티가 저장소를 자신의 모국어로 번역하기 시작한 것이었습니다! 이런 일이 일어나며 비영어권 사용자들이 데브옵스의 힘에 대해 더 배울 수 있도록 돕는다는 사실이 얼마나 놀라운지 생각해보면 정말 대단한 일이에요.
+
+![](images/day01-2.png)
+
+이 레포지토리의 멋진 기여자들을 보고 싶다면, [Contributors](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/Contributors.md) 를 확인하세요.
+
+### 지속적인 학습
+
+저는 계속해서 배움에는 끝이 없다 말했으며, 만약 당신은 그렇게 생각하지 않는다면, 모든 것들이 매시각 빠른 속도로 변화하는 이 산업을 고른 것은 잘못된 선택일 겁니다.
+
+즉, 우리는 계속해서 학습해야 합니다. 학습이 힘든 사람들을 위해서는 자신이 즐기는 방법을 찾도록 권유합니다. 저는 항상 배우는 것을 문서화하고 이렇게 기록한 내용을 실제로 실습하는 학습법을 즐겨왔습니다. 이 프로젝트의 핵심 아이디어 역시 그와 같습니다. 이 프로젝트는 DevOps의 핵심 영역과 그것을 이룰 수 있게 해주는 도구들에 대한 기본 지식에 관한 것입니다. 이 프로젝트를 따라한다해서 DevOps 엔지니어로써 학습을 졸업하게 되는 것은 아니지만, 용어에 대한 더 나은 이해와 일상적으로 접하지 않는 기술들을 실습해보며 보다 나은 이해를 얻을 수 있을 것입니다.
+
+또한 모든 사람들은 지속적으로 진화하고 학습하고 있습니다. 소프트웨어 회사의 최고 기술 책임자(CTO)이건, 자동화에 대해 더 배우고 싶은 시스템 관리자건, 누구나 계속 공부해야하며, 가끔 겪을 불안과 걱정은 특별한 게 아닙니다. 제가 하고싶은 조언은 그 불안을 오히려 마주하고 목표를 향해 달려가라는 것입니다. 이렇게 하면 분명 좋은 결과가 있을 것입니다. 또한 자신이 좋아하는 것을 학습하려는 것도 중요합니다.
+
+### 보안에 중점을 두기
+
+이 레포지토리를 계속 공부하신 분들은 알고 계실 것입니다. 2022년 버전에서 가장 크게 빠트린 부분은 보안인 DevSecOps로, 어떻게 보안을 무한한 데브옵스 주기에 통합하여 항상 보안을 고려할 수 있을지에 대한 내용입니다.
+
+이번 버전에서는 보안 프로세스와 원칙에 집중해 DevSecOps와 관련된 내용을 중점적으로 다룰 예정이며, 첫 번째 버전에서 놓친 몇 가지 주제에 대해 더 다룰 것입니다.
+
+### 친구들의 작은 도움
+
+2022년 버전은 매일 블로그 글을 쓴 것과 같은 작업이었습니다. 우리는 10만 단어가 넘는 글을 썼고, 우리가 이를 eBook 형태로 제작한다면 (이 옵션은 저장소에서 찾아볼 수 있습니다, 원하신다면) A4 용지로 총 700 페이지 이상의 분량이 될 것입니다. 책 아이디어는 아직 사라지지 않았으며, 현재 내부적으로 더 작은 버전을 준비하고 있어서 곧 참여 가능한 컨퍼런스에서 멋진 스티커와 함께 선물로 나올 수 있을 것입니다.
+
+또한 나에게 있어 부족했던 것 중 하나는 프로젝트의 진정성일 수 있습니다. 나는 그때 학습을 시작하고 그 학습 과정을 기록하는 과정에 있었기 때문입니다. 이번에는 커뮤니티 내에서 몇몇 친구들에게 도움을 청했습니다.
+
+이에는 두 가지 이유가 있습니다:
+
+1. 어떠한 주제에 대해 다양한 시각을 얻는 것은 중요하며, 또한 각 영역의 전문가들의 관점에 귀기울이는 것은 우리 모두가 가장 잘 배울 수 있는 방법이라고 생각하기 때문입니다.
+
+2. 여기에 전문가로써 도움을 줄 사람들은 자신의 브랜드를 확장하고 자신의 주제와 프로젝트에 대해 발표할 기회를 얻을 수 있습니다.
+
+2023년의 저자들은 개요 페이지인 2023.md에서 바이오와 연락처 링크를 통해 확인할 수 있습니다.
+
+이 프로젝트에 대해 매우 명확하게 말할 때가 되었다고 생각합니다. 아무도 글을 작성함으로써, 이 프로젝트에 대해 토론함으로써 보수를 받지 않습니다. 몇 차례 후원 제안을 받았지만, 이 프로젝트의 가장 중요한 취지는 중립을 유지하는 것, 커뮤니티를 위해 무료를 유지하는 것입니다. 그렇습니다, 우리는 일부 프로젝트와 제품을 사용했지만 어떠한 회사도 이 프로젝트를 후원하거나 작성 내용에 관여한 적이 없습니다.
+
+마지막으로, 나의 고용주인 Veeam Software에게 감사하고 싶습니다. 저는 매우 운 좋게도 커뮤니티의 일원으로서 학습을 기록하고 간섭 없이 진행할 수 있는 기회를 주는 회사에 다니고 있습니다. 전통적인 9-5 근무를 하지 않지만, 이러한 프로젝트와 같은 콘텐츠를 자유롭게 만들 수 있는 자유를 가지고 있습니다.
+
+### 리소스 Resources
+
+프로젝트와 이전 2022년 버전에서 resource 섹션을 찾아보실 수 있을 것입니다. 이 섹션은 저나 동료 저자들이 참고한 콘텐츠 목록이며, 보다 더 깊게 학습하고자 한다면 이 콘텐츠를 확인해보세요.
+
+2022년 버전은 [여기에서](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022.md) 찾아볼 수 있습니다.
+
+또한 일부 커뮤니티 멤버들은 [GitHub Pages](https://www.90daysofdevops.com/#/)를 통해 새로운 디자인을 그리는 작업에 바쁘게 참여하고 있습니다.
+
+[2023 페이지](https://www.90daysofdevops.com/#/2023)에서는 커뮤니티에 참여하는 방법도 찾아볼 수 있습니다.
+
+그럼 이와 관련된 내용을 [Day 2](day02.md)에서 확인해보겠습니다.