Translated 2022 day35-55 to korean

Translated 2022 day35 to korean Rename the world "파워셸" to "PowerShell" Translated 2022 day36 to korean Fixed unnatural translation in 2022 day36 ko Fixed unnatural translation in 2022 day38 ko Fixed unnatural translation in 2022 day31 ko Translated 2022 day37 to korean Rename the word "병합" to "merge" Rename the word "디렉터리" to "디렉토리" Translated 2022 day39 to korean wip Translated 2022 day40 to korean Translated 2022 day41 to korean Translated 2022 day42 to korean Translated 2022 day43 to korean Rename the word "브랜치" to "branch" Translated 2022 day44 to korean Translated 2022 day45 to korean Translated 2022 day46 to korean Translated 2022 day47 to korean Translated 2022 day48 to korean Fixed image link in 2022 day48 ko Translated 2022 day49 to korean Translated 2022 day50 to korean Rename the word "명령줄" to "커맨드라인" Translated 2022 day51 to korean Translated 2022 day52 to korean Translated 2022 day53 to korean Translated 2022 day54 to korean Translated 2022 day55 to korean
2023-03-27 16:14:51 +09:00 · 2023-03-27 16:14:51 +09:00 · b6340966bc
commit b6340966bc
parent 6d0f095466
28 changed files with 3340 additions and 14 deletions
--- a/2022/ko/Days/day08.md
+++ b/2022/ko/Days/day08.md
@ -36,7 +36,7 @@ Go 언어에 대한 몇 가지 기본 사항을 살펴보기 전에, 먼저 컴

 ![](/2022/Days/Images/Day8_Go5.png)

-그럼 파워셸 터미널에서 mkdir 명령어를 사용하여 디렉토리를 만들어 보겠습니다. 또한, 아래에서 보이듯이 Go 폴더 내에 3개의 폴더를 생성해야 합니다.
+그럼 PowerShell 터미널에서 mkdir 명령어를 사용하여 디렉토리를 만들어 보겠습니다. 또한, 아래에서 보이듯이 Go 폴더 내에 3개의 폴더를 생성해야 합니다.

 ![](/2022/Days/Images/Day8_Go6.png)

--- a/2022/ko/Days/day10.md
+++ b/2022/ko/Days/day10.md
@ -77,7 +77,7 @@ Go가 제대로 설치되었는지 확인하려면 명령 프롬프트를 열고
 ![](/2022/Days/Images/Day10_Go8.png)

 - `go run` - 이 명령은 command line에 지정한 .go 파일로 구성된 기본 패키지를 컴파일하고 실행합니다. 이때, 컴파일된 실행 파일은 임시 폴더에 저장됩니다.
- `go build` - 현재 디렉터리에서 패키지와 종속성을 컴파일합니다. 만약 프로젝트에 `main` 패키지가 포함되어 있다면, 실행 파일이 현재 디렉터리에 생성됩니다. 그렇지 않은 경우, 실행 파일은 `pkg` 폴더에 생성되며, 이후 다른 Go 프로그램에서 가져와서 사용할 수 있습니다. 또한 `go build`를 사용하면 Go가 지원하는 모든 OS 플랫폼에 대해 실행 파일을 빌드할 수 있습니다.
+- `go build` - 현재 디렉토리에서 패키지와 종속성을 컴파일합니다. 만약 프로젝트에 `main` 패키지가 포함되어 있다면, 실행 파일이 현재 디렉토리에 생성됩니다. 그렇지 않은 경우, 실행 파일은 `pkg` 폴더에 생성되며, 이후 다른 Go 프로그램에서 가져와서 사용할 수 있습니다. 또한 `go build`를 사용하면 Go가 지원하는 모든 OS 플랫폼에 대해 실행 파일을 빌드할 수 있습니다.
 - `go install` - go build와 비슷하지만, 실행 파일을 `bin` 폴더에 저장합니다.

 `go build`과 `go run`을 실행했지만, 원하는 경우 이곳에서 다시 실행할 수 있습니다. `go install`은 실행 파일을 bin 폴더에 넣는 것으로 설명한 대로 수행됩니다.
--- a/2022/ko/Days/day13.md
+++ b/2022/ko/Days/day13.md
@ -52,7 +52,7 @@ API token이 제공됩니다. 이를 안전한 장소에 저장해야 합니다.

 트위터에 메시지나 출력을 트윗 형태로 전달하기 위한 코드를 생각해봐야 합니다. 이를 위해 [go-twitter](https://github.com/dghubble/go-twitter) 라이브러리를 사용할 것입니다. 이 라이브러리는 Go 언어로 작성된 트위터 API 클라이언트 라이브러리입니다.

-메인 애플리케이션에 적용하기 전에 `src` 폴더에 'go-twitter-bot'이라는 새 디렉터리를 만들고, 해당 폴더에서 `go mod init github.com/michaelcade/go-Twitter-bot` 명령을 실행하여 `go.mod` 파일을 생성한 후, 새로운 'main.go' 파일을 작성하여 테스트해 보았습니다.
+메인 애플리케이션에 적용하기 전에 `src` 폴더에 'go-twitter-bot'이라는 새 디렉토리를 만들고, 해당 폴더에서 `go mod init github.com/michaelcade/go-Twitter-bot` 명령을 실행하여 `go.mod` 파일을 생성한 후, 새로운 'main.go' 파일을 작성하여 테스트해 보았습니다.

 트위터 개발자 포털에서 생성한 key, token 및 비밀번호가 필요하며, 이를 환경 변수로 설정해야 합니다. 하지만 이는 실행 중인 운영 체제에 따라 다를 수 있습니다.

--- a/2022/ko/Days/day15.md
+++ b/2022/ko/Days/day15.md
@ -171,7 +171,7 @@ echo 'export HISTFILESIZE=10000000' >> ~/.bash_profile

 ![](/2022/Days/Images/Day15_Linux28.png)

-데이터 스트림을 표준 입력에서 읽으려면 명령줄을 생성하고 실행해야 합니다. 이렇게 하면 명령의 출력을 가져와 다른 명령의 인수로 전달할 수 있습니다. 이러한 사용 사례에 유용한 도구로 `xargs`가 있습니다. 예를 들어, 실행 가능한 시스템에서 모든 Linux 사용자 계정의 목록을 가져오고 싶다면, `cut -d: -f1 < /etc/passwd`를 실행하면 아래와 같은 긴 목록이 생성됩니다.
+데이터 스트림을 표준 입력에서 읽으려면 커맨드라인을 생성하고 실행해야 합니다. 이렇게 하면 명령의 출력을 가져와 다른 명령의 인수로 전달할 수 있습니다. 이러한 사용 사례에 유용한 도구로 `xargs`가 있습니다. 예를 들어, 실행 가능한 시스템에서 모든 Linux 사용자 계정의 목록을 가져오고 싶다면, `cut -d: -f1 < /etc/passwd`를 실행하면 아래와 같은 긴 목록이 생성됩니다.

 ![](/2022/Days/Images/Day15_Linux29.png)

--- a/2022/ko/Days/day30.md
+++ b/2022/ko/Days/day30.md
@ -14,7 +14,7 @@ Microsoft Azure 개요에 이어서 Azure 보안부터 시작하여 일상적인

 Microsoft Azure가 다른 퍼블릭 클라우드 공급자와 다르게 작동하는 것처럼 보이는 영역 중 하나는 Azure에는 항상 Azure AD가 있다는 것입니다.

-### 디렉터리 서비스
+### 디렉토리 서비스

 - Azure Active Directory는 Microsoft Azure 및 기타 Microsoft 클라우드 서비스에서 사용하는 보안 원칙을 호스팅합니다.
 - 인증은 SAML, WS-Federation, OpenID Connect 및 OAuth2와 같은 프로토콜을 통해 수행됩니다.
@ -30,7 +30,7 @@ Microsoft Azure AD(Active Directory)에서 클라우드 계정을 만들 수 있

 Azure AD Connect를 사용하면 Windows AD 서버뿐만 아니라 다른 Azure AD, Google 및 기타 서버도 볼 수 있습니다. 또한 외부 사람 및 조직과 공동 작업할 수 있는 기능을 제공하는데, 이를 Azure B2B라고 합니다.

-액티브 디렉터리 도메인 서비스와 Microsoft Azure 액티브 디렉터리 간의 인증 옵션은 암호 해시와 ID 동기화를 통해 모두 가능합니다.
+액티브 디렉토리 도메인 서비스와 Microsoft Azure 액티브 디렉토리 간의 인증 옵션은 암호 해시와 ID 동기화를 통해 모두 가능합니다.

 ![](/2022/Days/Images/Day30_Cloud1.png)

@ -46,7 +46,7 @@ Azure AD Connect를 사용하면 Windows AD 서버뿐만 아니라 다른 Azure

 Microsoft 365, Microsoft Dynamics 및 온-프레미스 Active Directory를 사용하는 경우 페더레이션을 위해 Azure AD를 이해하고 통합하는 것은 매우 쉽습니다. 하지만 Microsoft 에코시스템 외부의 다른 서비스를 사용하고 있을 수도 있습니다.

-Azure AD는 이러한 다른 타사 앱 및 기타 디렉터리 서비스에 대한 페더레이션 브로커 역할을 할 수 있습니다.
+Azure AD는 이러한 다른 타사 앱 및 기타 디렉토리 서비스에 대한 페더레이션 브로커 역할을 할 수 있습니다.

 이는 Azure 포털에서 다양한 옵션이 있는 엔터프라이즈 애플리케이션으로 표시됩니다.

--- a/2022/ko/Days/day31.md
+++ b/2022/ko/Days/day31.md
@ -22,7 +22,7 @@ id: 1049040

 Microsoft는 지정학적 경계 내에 여러 지역을 배포합니다.

-서비스 가용성을 위한 Azure의 두 가지 개념. Sets과 영역 모두.
+서비스 가용성을 위한 Azure의 두 가지 개념엔 Sets와 영역이 있습니다.

 가용성 Sets - 데이터 센터 내에서 복원력 제공

--- a/2022/ko/Days/day33.md
+++ b/2022/ko/Days/day33.md
@ -84,11 +84,11 @@ Microsoft Azure에는 두 가지 로드 밸런싱 솔루션이 있습니다. (

 ## Azure 관리 도구

-대부분의 이론 시간을 Azure 포털을 살펴보는 데 할애했는데, 데브옵스 문화를 따르고 이러한 작업, 특히 프로비저닝과 관련된 많은 작업을 처리할 때 API 또는 명령줄 도구를 통해 수행한다고 제안하고 싶습니다. Azure 환경의 프로비저닝을 자동화할 때 이를 알아야 하므로 사용할 수 있는 다른 관리 도구 몇 가지를 언급하고 싶었습니다.
+대부분의 이론 시간을 Azure 포털을 살펴보는 데 할애했는데, 데브옵스 문화를 따르고 이러한 작업, 특히 프로비저닝과 관련된 많은 작업을 처리할 때 API 또는 커맨드라인 도구를 통해 수행한다고 제안하고 싶습니다. Azure 환경의 프로비저닝을 자동화할 때 이를 알아야 하므로 사용할 수 있는 다른 관리 도구 몇 가지를 언급하고 싶었습니다.

 ### Azure 포털

-Microsoft Azure Portal은 명령줄 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 워크플로우에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다.
+Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 워크플로우에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다.

 ![](/2022/Days/Images/Day33_Cloud2.png)

@ -98,9 +98,9 @@ Azure Preview Portal도 있으며, 이 포털을 사용하여 새로운 서비

 ### PowerShell

-Azure PowerShell을 살펴보기 전에 PowerShell에 대해 먼저 소개할 필요가 있습니다. PowerShell은 작업 자동화 및 구성 관리 프레임워크, 명령줄 셸 및 스크립팅 언어입니다. Linux 섹션에서 셸 스크립팅에 대해 다룬 것과 비슷하다고 감히 말할 수 있습니다. PowerShell은 Windows OS에서 처음 발견되었지만, 이제는 크로스 플랫폼입니다.
+Azure PowerShell을 살펴보기 전에 PowerShell에 대해 먼저 소개할 필요가 있습니다. PowerShell은 작업 자동화 및 구성 관리 프레임워크, 커맨드라인 셸 및 스크립팅 언어입니다. Linux 섹션에서 셸 스크립팅에 대해 다룬 것과 비슷하다고 감히 말할 수 있습니다. PowerShell은 Windows OS에서 처음 발견되었지만, 이제는 크로스 플랫폼입니다.

-Azure PowerShell은 PowerShell 명령줄에서 직접 Azure 리소스를 관리하기 위한 cmdlets의 집합입니다.
+Azure PowerShell은 PowerShell 커맨드라인에서 직접 Azure 리소스를 관리하기 위한 cmdlets의 집합입니다.

 아래에서 PowerShell 명령 `Connect-AzAccount`를 사용하여 구독에 연결할 수 있음을 확인할 수 있습니다.

@ -154,7 +154,7 @@ Cloud Shell을 사용하도록 선택하면 머신이 스핀업되며, 이러한

 처음 Azure 학습에 들어갔을 때 Azure PowerShell과 Azure CLI가 있어서 약간 혼란스러웠습니다.

-이에 대한 커뮤니티의 피드백이 있으면 좋겠습니다. 하지만 제가 알기로 Azure PowerShell은 Windows PowerShell 또는 PowerShell Core에 추가된 모듈(다른 OS에서도 사용 가능하지만 전부는 아님)인 반면, Azure CLI는 Azure에 연결하여 해당 명령을 실행하는 크로스 플랫폼 명령줄 프로그램이라고 알고 있습니다.
+이에 대한 커뮤니티의 피드백이 있으면 좋겠습니다. 하지만 제가 알기로 Azure PowerShell은 Windows PowerShell 또는 PowerShell Core에 추가된 모듈(다른 OS에서도 사용 가능하지만 전부는 아님)인 반면, Azure CLI는 Azure에 연결하여 해당 명령을 실행하는 크로스 플랫폼 커맨드라인 프로그램이라고 알고 있습니다.

 이 두 옵션 모두 구문은 다르지만, 제가 보기에는 매우 유사한 작업을 수행할 수 있습니다.

@ -168,7 +168,7 @@ Cloud Shell을 사용하도록 선택하면 머신이 스핀업되며, 이러한

 Azure CLI

- Windows, macOS, Linux에 설치할 수 있는 크로스 플랫폼 명령줄 인터페이스
+- Windows, macOS, Linux에 설치할 수 있는 크로스 플랫폼 커맨드라인 인터페이스
 - Windows PowerShell, Cmd, Bash 및 기타 Unix 셸에서 실행됩니다.

 Azure PowerShell
--- a/2022/ko/Days/day35.md
+++ b/2022/ko/Days/day35.md
@ -0,0 +1,140 @@
+---
+title: '#90DaysOfDevOps - The Big Picture: Git - Version Control - Day 35'
+published: false
+description: 90DaysOfDevOps - The Big Picture Git - Version Control
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049041
+---
+
+## 큰 그림: Git - 버전 관리
+
+Git을 시작하기 전에 버전 관리가 무엇이며 왜 필요한지 이해해야 하나요? 이번 Git 시작 단계에서는 버전 관리가 무엇인지, 그리고 Git의 기본 사항에 대해 살펴보겠습니다.
+
+### 버전 제어란 무엇인가요?
+
+Git이 유일한 버전 관리 시스템은 아니므로 여기서는 버전 관리와 관련하여 어떤 옵션과 방법론을 사용할 수 있는지 살펴보고자 합니다.
+
+버전 관리의 가장 분명하고 큰 장점은 프로젝트의 이력을 추적할 수 있다는 것입니다. 우리는 `git log`를 사용하여 이 리포지토리를 되돌아보고 많은 커밋과 많은 코멘트가 있으며 프로젝트에서 지금까지 무슨 일이 일어났는지 확인할 수 있습니다. 명령어에 대해서는 나중에 설명할 테니 걱정하지 마세요. 이제 이것이 소스 코드로 가득 찬 실제 소프트웨어 프로젝트이고 여러 사람이 서로 다른 시간에 소프트웨어에 커밋하고, 다른 작성자와 검토자가 모두 여기에 기록되어 무슨 일이 언제, 누가, 누가 검토했는지 알 수 있다고 생각해보세요.
+
+![](/2022/Days/Images/Day35_Git1.png)
+
+과거 버전 제어는 변경을 하기 전에 수동으로 버전 복사본을 만드는 것과 같은 방식이었을 것입니다. 또한 혹시 모른다는 생각으로 쓸모없는 오래된 코드를 주석 처리했을 수도 있습니다.
+
+![](/2022/Days/Images/Day35_Git2.png)
+
+저는 소스 코드뿐만 아니라 거의 모든 프로젝트에 버전 관리를 사용하기 시작했고, 이와 같은 프로젝트에 대해 이야기합니다(90DaysOfDevOps). 진행된 모든 것을 롤백하고 기록하는 기능을 받아들이는 것은 어떨까요?
+
+그러나 **버전 제어는 백업이 아닙니다!**
+
+버전 관리의 또 다른 이점은 프로젝트의 여러 버전을 관리할 수 있다는 점입니다. 예를 들어 모든 운영 체제에서 사용할 수 있는 무료 앱이 있고 모든 운영 체제에서 사용할 수 있는 유료 앱이 있다고 가정해 봅시다. 대부분의 코드는 두 애플리케이션 간에 공유됩니다. 각 앱에 코드를 복사하여 붙여 넣을 수도 있지만, 개발 인원이 한 명 이상으로 늘어나면 매우 지저분해지고 실수도 발생할 수 있습니다.
+
+프리미엄 앱에는 추가 기능을 프리미엄 커밋이라고 부르고 무료 버전에는 일반 커밋만 포함할 수 있습니다.
+
+버전 관리에서 이를 달성하는 방법은 branch를 사용하는 것입니다.
+
+![](/2022/Days/Images/Day35_Git3.png)
+
+branch를 사용하면 위에서 설명한 것처럼 동일한 앱에 대해 두 개의 코드 스트림을 사용할 수 있습니다. 하지만 소스 코드가 없는 버전에 포함된 새로운 기능이 프리미엄 버전에 포함되기를 원하며, 이를 위해 Merge라는 기능을 사용합니다.
+
+![](/2022/Days/Images/Day35_Git4.png)
+
+무료 버전에서 작업하는 팀과 프리미엄 유료 버전에서 작업하는 팀이 있을 수 있고, 둘 다 전체 코드의 일부에 영향을 주는 코드를 변경하면 어떻게 될지 모르기 때문에 merge는 복잡할 수 있습니다. 변수가 업데이트되어 무언가를 망가뜨릴 수도 있습니다. 그러면 기능 중 하나가 중단되는 충돌이 발생합니다. 버전 관리로는 이러한 충돌을 해결할 수 없습니다. 하지만 버전 제어를 사용하면 이를 쉽게 관리할 수 있습니다.
+
+지금까지 버전 관리를 선택하지 않았다면 일반적으로 가장 큰 이유는 공동 작업 기능입니다. 개발자 간에 코드를 공유할 수 있는 기능, 그리고 앞서 말씀드린 대로 코드라고 하면 동료와 함께 작업하는 공동 프레젠테이션이나 프로젝트 전반에 걸쳐 커뮤니티가 수정 및 업데이트를 제공하는 90DaysOfDevOps 챌린지 등 다른 이유로 소스 제어를 사용하는 사례가 점점 더 많아지고 있습니다.
+
+버전 관리가 없다면 소프트웨어 개발자 팀은 어떻게 이런 일을 처리할 수 있을까요? 저는 프로젝트를 진행하면서 상황을 추적하는 것만으로도 충분히 힘들다는 것을 느낍니다. 저는 그들이 코드를 각 기능 모듈로 분리할 것이라고 예상합니다. 아마도 퍼즐 조각을 한데 모은 다음 릴리스하기 전에 문제와 이슈를 파악했을 것입니다.
+
+버전 관리를 통해 우리는 단일 소스를 확보할 수 있습니다. 여전히 서로 다른 모듈에서 작업할 수 있지만 협업이 더 잘 이루어질 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git5.png)
+
+여기서 한 가지 더 언급할 것은 버전 관리의 이점을 누릴 수 있는 것은 개발자뿐만 아니라 모든 팀원이 가시성을 확보할 수 있을 뿐만 아니라 프로젝트 관리 도구도 여기에 연결하여 작업을 추적할 수 있다는 것입니다. 다른 모듈에서 다룰 Jenkins와 같은 빌드 머신도 있을 수 있습니다. 시스템을 빌드하고 패키징하여 배포 테스트와 메트릭을 자동화하는 도구입니다.
+
+### Git이란 무엇인가요?
+
+Git은 소스 코드 또는 모든 파일의 변경 사항을 추적하는 도구이며, 오픈소스 분산 버전 관리 시스템이라고도 할 수 있습니다.
+
+시스템에서 Git을 사용할 수 있는 방법은 여러 가지가 있는데, 가장 일반적으로는 커맨드라인에서 사용하는 것이 가장 일반적이지만, GUI와 Visual Studio Code와 같은 도구에서도 Git을 인식하는 작업을 활용할 수 있습니다.
+
+이제 로컬 머신에 Git을 설치하기 전에 개략적인 개요를 살펴보겠습니다.
+
+앞서 만든 폴더를 살펴보겠습니다.
+
+![](/2022/Days/Images/Day35_Git2.png)
+
+이 폴더를 버전 제어에 사용하려면 먼저 `git init` 명령을 사용하여 이 디렉토리를 초기화해야 합니다. 지금은 이 명령이 디렉토리를 컴퓨터 어딘가에 있는 데이터베이스의 리포지토리로 저장한다고 생각하면 됩니다.
+
+![](/2022/Days/Images/Day35_Git6.png)
+
+이제 몇 가지 파일과 폴더를 만들 수 있으며 소스 코드가 시작될 수도 있고 이미 여기에 무언가가 있을 수도 있습니다. 우리는 `git add .` 명령을 사용하여 디렉토리의 모든 파일과 폴더를 스냅샷에 넣을 수 있지만 아직 해당 데이터베이스에 아무것도 커밋하지 않았습니다. 우리는 단지 `.`가 있는 모든 파일을 추가할 준비가 되었다고 말하는 것입니다.
+
+![](/2022/Days/Images/Day35_Git7.png)
+
+이제 파일을 커밋하고 싶으면 `git commit -m "My First Commit"` 명령으로 이 작업을 수행합니다. 커밋에 대한 설명을 할 수 있으며 각 커밋에 대해 무슨 일이 일어났는지 알 수 있도록 도와줍니다.
+
+![](/2022/Days/Images/Day35_Git8.png)
+
+이제 프로젝트의 히스토리에서 어떤 일이 일어났는지 확인할 수 있습니다. `git log` 명령어를 사용합니다.
+
+![](/2022/Days/Images/Day35_Git9.png)
+
+`samplecode.ps1`라는 파일을 추가로 생성하면 상태가 달라집니다. 또한 `git status`를 사용하여 리포지토리의 상태를 확인할 수 있는데, 커밋할 항목이 없음을 보여주며 samplecode.ps1이라는 새 파일을 추가할 수 있습니다. 그런 다음 동일한 `git status`를 실행하면 커밋할 파일이 있는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git10.png)
+
+`git add samplecode.ps1`명령을 사용하여 새 파일을 추가한 다음`git status`를 다시 실행하면 파일이 커밋될 준비가 된 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git11.png)
+
+그런 다음 `git commit -m "My Second Commit"` 명령을 실행합니다.
+
+![](/2022/Days/Images/Day35_Git12.png)
+
+`git status`를 한 번 더 입력하면, 모든 것이 다시 깨끗해졌음을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git13.png)
+
+이제 최신 변경 사항과 첫 번째 커밋을 보여주는 `git log` 명령을 사용할 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git14.png)
+
+커밋 사이의 변경 사항, 즉 어떤 파일이 추가되거나 수정되었는지 확인하려면 `git diff b8f8 709a`를 사용하면 됩니다.
+
+![](/2022/Days/Images/Day35_Git15.png)
+
+그러면 새 파일을 추가한 경우 변경된 내용이 표시됩니다.
+
+![](/2022/Days/Images/Day35_Git16.png)
+
+나중에 더 자세히 설명하겠지만 커밋을 이동하면서 시간 여행을 할 수 있습니다! 커밋 번호를 사용하면 `git checkout 709a` 명령을 사용하여 새 파일을 잃지 않고 시간을 거슬러 올라갈 수 있습니다.
+
+![](/2022/Days/Images/Day35_Git17.png)
+
+마찬가지로 커밋 번호와 같은 방법으로 앞으로 이동하고 싶을 수도 있고, 여기서 `git switch -` 명령을 사용하여 작업을 취소할 수도 있습니다.
+
+![](/2022/Days/Images/Day35_Git18.png)
+
+TLDR;
+
+- 프로젝트 히스토리 추적하기
+- 프로젝트의 여러 버전 관리
+- 개발자 및 더 넓은 범위의 팀과 도구 간에 코드 공유
+- 팀워크 조정
+- 아, 그리고 시간 여행!
+
+너무 많은 내용을 설명한 것 같지만, 어떤 명령어를 사용하는지 몰라도 버전 관리의 큰 그림을 이해할 수 있기를 바랍니다.
+
+다음에는 로컬 머신에 Git을 설치 및 설정하고 Git을 통해 얻을 수 있는 다른 사용 사례와 명령어에 대해 좀 더 자세히 살펴보겠습니다.
+
+## 자료
+
+- [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)
+
+[Day 36](day36.md)에서 봐요!
--- a/2022/ko/Days/day36.md
+++ b/2022/ko/Days/day36.md
@ -0,0 +1,154 @@
+---
+title: '#90DaysOfDevOps - Installing & Configuring Git - Day 36'
+published: false
+description: 90DaysOfDevOps - Installing & Configuring Git
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048738
+---
+
+## Git 설치 및 구성
+
+Git은 버전 관리를 위한 오픈 소스 크로스 플랫폼 도구입니다. 저처럼 우분투 또는 대부분의 Linux 환경을 사용하는 경우 이미 Git이 설치되어 있을 수 있지만 설치 및 구성 과정을 살펴보겠습니다.
+
+시스템에 이미 git이 설치되어 있더라도 최신 버전인지 확인하는 것도 좋은 방법입니다.
+
+### Git 설치하기
+
+이미 언급했듯이 Git은 크로스 플랫폼이므로 Windows와 Linux를 통해 실행할 것이지만 [여기](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)에서 macOS도 찾을 수 있습니다.
+
+[Windows](https://git-scm.com/download/win)의 경우 공식 사이트에서 설치할 수 있습니다.
+
+Windows 컴퓨터에서 `winget`을 사용할 수도 있는데, 이것을 Windows 애플리케이션 패키지 관리자라고 생각하면 됩니다.
+
+설치하기 전에 Windows 머신에 어떤 버전이 있는지 확인해 보겠습니다. PowerShell 창을 열고 `git --version`을 실행합니다.
+
+![](/2022/Days/Images/Day36_Git1.png)
+
+WSL 우분투 버전의 Git도 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day36_Git2.png)
+
+이 글을 쓰는 시점에 최신 Windows 릴리스는 `2.35.1`이므로 업데이트해야 할 사항이 몇 가지 있는데 이를 살펴보겠습니다. 리눅스도 마찬가지일 것으로 예상합니다.
+
+저는 최신 설치 프로그램을 다운로드하고 마법사를 실행했으며 여기에 이를 문서화할 것입니다. 주의해야 할 중요한 점은 최신 버전을 설치하기 전에 git이 이전 버전을 제거한다는 것입니다.
+
+즉, 아래에 표시된 프로세스도 대부분 git을 사용하지 않고 설치하는 것과 동일한 프로세스입니다.
+
+매우 간단한 설치입니다. 다운로드가 완료되면 두 번 클릭하고 시작하세요. GNU 라이선스 계약을 읽어보세요. 하지만 이 소프트웨어는 무료 오픈소스 소프트웨어라는 점을 기억하세요.
+
+![](/2022/Days/Images/Day36_Git3.png)
+
+이제 추가로 설치할 컴포넌트를 선택해 git과 연결할 수 있습니다. 저는 Windows에서 bash 스크립트를 실행할 수 있는 Git Bash를 항상 설치합니다.
+
+![](/2022/Days/Images/Day36_Git4.png)
+
+그런 다음 사용할 SSH 실행 파일을 선택할 수 있습니다. 리눅스 섹션에서 보셨을 번들 OpenSSH를 그대로 두겠습니다.
+
+![](/2022/Days/Images/Day36_Git5.png)
+
+그다음에는 실험적인 기능을 활성화할 수 있는데, 저는 필요하지 않으므로 활성화하지 않고 나중에 설치를 통해 돌아와서 언제든지 활성화할 수 있습니다.
+
+![](/2022/Days/Images/Day36_Git6.png)
+
+설치가 완료되었으므로 이제 Git Bash 및 최신 릴리스 노트를 열도록 선택할 수 있습니다.
+
+![](/2022/Days/Images/Day36_Git7.png)
+
+마지막 확인은 PowerShell 창에서 현재 어떤 버전의 git이 있는지 살펴보는 것입니다.
+
+![](/2022/Days/Images/Day36_Git8.png)
+
+매우 간단하며 이제 최신 버전을 사용하고 있습니다. 리눅스 머신에서는 업데이트가 조금 늦은 것 같아서 업데이트 과정을 안내해 드리겠습니다.
+
+`sudo apt-get install git` 명령을 실행하기만 하면 됩니다.
+
+![](/2022/Days/Images/Day36_Git9.png)
+
+다음을 실행하여 소프트웨어 설치를 위한 git 저장소를 추가할 수도 있습니다.
+
+```
+sudo add-apt-repository ppa:git-core/ppa -y
+sudo apt-get update
+sudo apt-get install git -y
+git --version
+```
+
+### Git 구성하기
+
+처음 git을 사용할 때는 몇 가지 설정을 정의해야 합니다,
+
+- Name
+- Email
+- 기본 에디터
+- Line Ending
+
+이 설정은 세 가지 수준에서 수행할 수 있습니다.
+
+- System = 모든 사용자
+- Global = 현재 사용자의 모든 리포지토리
+- Local = 현재 리포지토리
+
+예제
+`git config --global user.name "Michael Cade"`
+`git config --global user.email Michael.Cade@90DaysOfDevOPs.com"`
+운영 체제에 따라 기본 텍스트 편집기가 결정됩니다. 다음 명령을 설정하지 않은 제 우분투 머신에서는 Nano를 사용하고 있습니다. 아래 명령은 이를 비주얼 스튜디오 코드로 변경합니다.
+
+`git config --global core.editor "code --wait"`
+
+이제 모든 git 구성을 보려면 다음 명령을 사용하면 됩니다.
+
+`git config --global -e`
+
+![](/2022/Days/Images/Day36_Git10.png)
+
+어떤 머신에서든 이 파일의 이름은 `.gitconfig`입니다. 제 Windows 머신에서는 사용자 계정 디렉토리에서 이 파일을 찾을 수 있습니다.
+
+![](/2022/Days/Images/Day36_Git11.png)
+
+### Git 이론
+
+어제 포스트에서 다른 버전 관리 유형이 있으며 이를 두 가지 유형으로 나눌 수 있다고 언급했습니다. 하나는 "클라이언트-서버"이고 다른 하나는 "분산"입니다.
+
+### 클라이언트-서버 버전 제어
+
+git이 등장하기 전에는 클라이언트-서버가 버전 관리를 위한 사실상 유일한 방법이었다. 그 예로 2000년에 설립된 오픈소스 버전 관리 시스템인 [Apache Subversion](https://subversion.apache.org/)을 들 수 있습니다.
+
+이 클라이언트-서버 버전 제어 모델에서는 개발자가 서버에서 소스 코드와 실제 파일을 다운로드하는 것이 첫 번째 단계입니다. 이렇게 한다고 해서 충돌이 예방되는 것은 아니지만 충돌의 복잡성과 해결 방법이 예방됩니다.
+
+![](/2022/Days/Images/Day36_Git12.png)
+
+예를 들어 두 명의 개발자가 같은 파일을 작업하고 있는데 한 개발자가 새로운 변경 사항을 먼저 커밋하거나 서버에 파일을 다시 업로드한다고 가정해 보겠습니다. 두 번째 개발자가 업데이트를 하려고 할 때 충돌이 발생합니다.
+
+![](/2022/Days/Images/Day36_Git13.png)
+
+이때, 첫 번째 개발자의 코드 변경 사항을 가져와서 자신의 작업과 충돌하는 부분을 모두 처리한 다음, 커밋해야 합니다.
+
+![](/2022/Days/Images/Day36_Git15.png)
+
+### 분산 버전 제어
+
+Git이 유일한 분산 버전 제어 시스템은 아닙니다. 하지만 사실상 거의 유일한 시스템입니다.
+
+Git의 주요 이점은 다음과 같습니다:
+
+- 빠름
+- 스마트
+- 유연함
+- 안전 및 보안
+
+클라이언트-서버 버전 제어 모델과 달리 각 개발자는 커밋 히스토리, 모든 branch 등을 의미하는 소스 리포지토리를 다운로드합니다.
+
+![](/2022/Days/Images/Day36_Git16.png)
+
+## 자료
+
+- [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)
+
+[Day 37](day37.md)에서 봐요!
--- a/2022/ko/Days/day37.md
+++ b/2022/ko/Days/day37.md
@ -0,0 +1,170 @@
+---
+title: '#90DaysOfDevOps - Gitting to know Git - Day 37'
+published: false
+description: 90DaysOfDevOps - Gitting to know Git
+tags: 'DevOps, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048707
+---
+
+## Gitting to know Git(Git에 대해 알아보기)
+
+제목과 글 전체에 끔찍한 말장난이 들어가서 죄송합니다. Git을 아재 개그로 바꾼 사람이 제가 처음은 아닐 겁니다!
+
+지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 워크플로우에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다.
+
+이제 Git에서 흔히 볼 수 있는 몇 가지 명령어와 사용 사례를 살펴보겠습니다.
+
+### git은 어디에서 도움을 받을 수 있나요?
+
+git으로 작업을 완료하는 데 필요한 명령이 기억나지 않거나 모를 때가 있을 것입니다. 도움이 필요할 것입니다.
+
+Google이나 검색 엔진이 도움을 찾을 때 가장 먼저 찾을 수 있는 곳일 것입니다.
+
+두 번째는 공식 git 사이트와 문서입니다. [git-scm.com/docs](http://git-scm.com/docs) 여기에서 사용 가능한 모든 명령어에 대한 확실한 정보뿐만 아니라 다양한 리소스를 찾을 수 있습니다.
+
+![](/2022/Days/Images/Day37_Git1.png)
+
+터미널에 연결할 수 없는 경우에도 동일한 문서에 액세스할 수 있어 매우 유용합니다. 예를 들어 `git add` 명령어를 선택했다면 `git add --help`를 실행하면 아래에 설명서가 표시됩니다.
+
+![](/2022/Days/Images/Day37_Git2.png)
+
+셸에서 `git add -h`를 사용하면 사용 가능한 옵션에 대한 요약을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day37_Git3.png)
+
+### Git을 둘러싼 오해
+
+"Git에는 액세스 제어 기능이 없다." - 리더에게 소스 코드를 유지 관리할 수 있는 권한을 부여할 수 있습니다.
+
+"Git은 너무 무겁다." - Git은 대규모 프로젝트의 경우 기록을 줄여주는 얕은(shallow) 저장소를 제공할 수 있습니다.
+
+### 실제 단점
+
+바이너리 파일에는 적합하지 않습니다. 소스 코드에는 적합하지만 실행 파일이나 동영상 등에는 적합하지 않습니다.
+
+도구의 명령어와 기능에 대해 설명하는 데 시간을 할애해야 한다는 점이 사용자 친화적이지 않다는 것을 보여주는 대표적인 예입니다.
+
+하지만 전반적으로 Git은 배우기는 어렵지만 사용하기는 쉽습니다.
+
+### git 생태계
+
+여기서는 git과 관련된 생태계를 간략하게 다루되 일부 영역에 대해 깊이 있게 다루지는 않겠지만 개략적인 수준에서 알아두는 것이 중요하다고 생각합니다.
+
+거의 모든 최신 개발 도구는 Git을 지원합니다.
+
+- 개발자 도구 - 이미 비주얼 스튜디오 코드에 대해 언급했지만, 서브블룸 텍스트 및 기타 텍스트 편집기 및 IDE에 대한 git 플러그인 및 통합을 찾을 수 있습니다.
+- 팀 도구 - CI/CD 관점에서의 Jenkins, 메시징 프레임워크의 Slack, 프로젝트 관리 및 이슈 추적을 위한 Jira와 같은 도구에 대해서도 언급했습니다.
+- 클라우드 제공업체 - 모든 대형 클라우드 제공업체는 git, Microsoft Azure, Amazon AWS 및 Google Cloud Platform을 지원합니다.
+- Git 기반 서비스 - 나중에 더 자세히 다룰 GitHub, GitLab 및 BitBucket이 있습니다. 이러한 서비스는 코드를 위한 소셜 네트워크입니다!
+
+### Git 치트시트
+
+대부분의 명령어를 다루지는 않았지만, 온라인에서 제공되는 몇 가지 치트 시트를 살펴본 후 몇 가지 git 명령어와 그 용도를 문서화하고 싶었습니다. 이 명령어들을 모두 기억할 필요는 없으며, 더 많은 실습과 사용을 통해 최소한 git 기본 명령어 정도는 익힐 수 있을 것입니다.
+
+[Atlassian](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)에서 가져온 것이지만, 적어두고 설명을 읽어보면 명령이 무엇인지 알 수 있을 뿐만 아니라 일상적인 작업에서 실습을 해볼 수 있는 좋은 방법입니다.
+
+### Git 기본 사항
+
+| Command       | Example                     | Description                                                                                                                 |
+| ------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| git init      | `git init <directory>`      | 지정한 디렉토리에 빈 git 리포지토리를 만듭니다.                                                                             |
+| git clone     | `git clone <repo>`          | \<repo>에 있는 리포지토리를 로컬 머신에 복제합니다.                                                                         |
+| git config    | `git config user.name`      | 현재 리포지토리 `system`, `global`, `local` 플래그의 모든 commit에 사용할 작성자 이름을 정의하여 구성 옵션을 설정합니다.    |
+| git add       | `git add <directory>`       | 다음 commit을 위해 \<directory>의 모든 변경 사항을 스테이징합니다. 모든 항목에 대해 \<files>와 \<.>을 추가할 수도 있습니다. |
+| git commit -m | `git commit -m "<message>"` | 스테이징된 스냅샷을 commit하고, \<message>를 사용하여 commit되는 내용을 자세히 설명합니다.                                  |
+| git status    | `git status`                | 스테이징된 파일, 스테이징되지 않은 파일 및 추적되지 않은 파일을 나열합니다.                                                 |
+| git log       | `git log`                   | 기본 형식을 사용하여 모든 commit 기록을 표시합니다. 이 명령에는 추가 옵션이 있습니다.                                       |
+| git diff      | `git diff`                  | 인덱스와 작업 디렉토리 사이의 스테이징되지 않은 변경 내용을 표시합니다.                                                     |
+
+### Git 변경사항 되돌리기
+
+| Command    | Example               | Description                                                                                                                                                   |
+| ---------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| git revert | `git revert <commit>` | \<commit>의 모든 변경 사항을 취소하는 새 commit을 만든 다음 현재 branch에 적용합니다.                                                                         |
+| git reset  | `git reset <file>`    | 스테이징 영역에서 \<file>을 제거하지만 작업 디렉토리는 변경하지 않고 그대로 둡니다. 이렇게 하면 변경 내용을 덮어쓰지 않고 파일을 스테이징 해제할 수 있습니다. |
+| git clean  | `git clean -n`        | 작업 디렉토리에서 어떤 파일을 제거할지 표시합니다. clean을 실행하려면 `-n` 대신 `-f`를 사용해야 합니다.                                                       |
+
+### Git 수정 기록
+
+| Command    | Example              | Description                                                                                                                                                              |
+| ---------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| git commit | `git commit --amend` | 마지막 commit을 단계적 변경 사항과 마지막 commit을 결합한 것으로 바꿉니다. 아무것도 준비하지 않은 상태에서 사용하면 마지막 commit의 메시지를 편집할 수 있습니다.         |
+| git rebase | `git rebase <base>`  | 현재 branch를 \<base>로 rebase합니다. \<base>는 commit ID, branch 이름, 태그 또는 HEAD에 대한 레퍼런스가 될 수 있습니다.                                                 |
+| git reflog | `git reflog`         | 로컬 리포지토리의 HEAD에 대한 변경 로그를 표시합니다. 날짜 정보를 표시하려면 --relative-date 플래그를 추가해야 하고, 모든 레퍼런스를 표시하려면 --all을 추가해야 합니다. |
+
+### Git Branchs
+
+| Command      | Example                    | Description                                                                                                      |
+| ------------ | -------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| git branch   | `git branch`               | 리포지토리에 있는 모든 branch를 나열합니다. \<branch> 인수를 추가하여 \<branch>라는 이름의 새 branch를 만듭니다. |
+| git checkout | `git checkout -b <branch>` | \<branch>라는 이름의 새 branch를 생성하고 checkout합니다. 기존 branch를 checkout하려면 -b 플래그를 지웁니다.     |
+| git merge    | `git merge <branch>`       | \<branch>를 현재 branch에 merge합니다.                                                                           |
+
+### Git 원격 리포지토리
+
+| Command        | Example                       | Description                                                                                                                               |
+| -------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| git remote add | `git remote add <name> <url>` | 원격 리포지토리에 대한 새 연결을 생성합니다. 리모트를 추가한 후 \<name>을 다른 명령에서 \<url>에 대한 바로 가기로 사용할 수 있습니다.     |
+| git fetch      | `git fetch <remote> <branch>` | 리포지토리에서 특정 \<branch>를 가져옵니다. 모든 원격 레퍼런스를 가져오려면 \<branch>를 생략하세요.                                       |
+| git pull       | `git pull <remote>`           | 지정된 리모트의 현재 branch 복사본을 가져와서 로컬 복사본에 즉시 merge합니다.                                                             |
+| git push       | `git push <remote> <branch>`  | branch를 필요한 commit 및 오브젝트와 함께 \<remote>로 push합니다. 원격 리포지토리에 이름이 지정된 branch가 없는 경우 branch를 생성합니다. |
+
+### Git Diff
+
+| Command           | Example             | Description                                           |
+| ----------------- | ------------------- | ----------------------------------------------------- |
+| git diff HEAD     | `git diff HEAD`     | 작업 디렉토리와 마지막 commit의 diff를 표시합니다.    |
+| git diff --cached | `git diff --cached` | 단계적 변경 사항과 마지막 commit의 diff를 표시합니다. |
+
+### Git Config
+
+| Command                                                | Example                                               | Description                                                                                                                          |
+| ------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| git config --global user.name \<name>                  | `git config --global user.name <name>`                | 현재 사용자가 모든 commit에 사용할 작성자 이름을 정의합니다.                                                                         |
+| git config --global user.email \<email>                | `git config --global user.email <email>`              | 현재 사용자가 모든 commit에 사용할 작성자 이메일을 정의합니다.                                                                       |
+| git config --global alias \<alias-name> \<git-command> | `git config --global 별칭 <alias-name> <git-command>` | git 명령에 대한 단축어를 만듭니다.                                                                                                   |
+| git config --system core.editor \<editor>              | `git config --system core.editor <editor>`            | 컴퓨터의 모든 사용자에 대한 명령에서 사용할 텍스트 편집기를 설정합니다. \<editor> 인수는 원하는 편집기를 실행하는 명령이어야 합니다. |
+| git config --global --edit                             | `git config --global --edit `                         | 수동 편집을 위해 텍스트 편집기에서 전역 구성 파일을 엽니다.                                                                          |
+
+### Git Rebase
+
+| Command               | Example                | Description                                                                                                                |
+| --------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------- |
+| git rebase -i \<base> | `git rebase -i <base>` | 현재 branch를 \<base>로 rebase합니다. 편집기를 사용하여 각 commit을 새 저장소로 옮기는 방법에 대한 명령을 입력해야 합니다. |
+
+### Git Pull
+
+| Command                     | Example                      | Description                                                                                                                     |
+| --------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| git pull --rebase \<remote> | `git pull --rebase <remote>` | 현재 branch의 리모트 복사본을 가져와서 로컬 복사본으로 rebase합니다. branch를 통합하기 위해 merge 대신 git rebase를 사용합니다. |
+
+### Git Reset
+
+| Command                    | Example                     | Description                                                                                                                                           |
+| -------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| git reset                  | `git reset`                 | 스테이징 영역을 가장 최근 commit과 일치하도록 reset하되 작업 디렉토리는 변경하지 않습니다.                                                            |
+| git reset --hard           | `git reset --hard`          | 스테이징 영역과 작업 디렉토리를 가장 최근 commit과 일치하도록 reset하고 작업 디렉토리의 모든 변경 내용을 덮어씁니다.                                  |
+| git reset \<commit>        | `git reset <commit>`        | 현재 branch 끝을 \<commit> 뒤로 이동하고 스테이징 영역을 일치하도록 reset하되 작업 디렉토리는 그대로 둡니다                                           |
+| git reset --hard \<commit> | `git reset --hard <commit>` | 이전과 동일하지만 스테이징 영역과 작업 디렉토리를 모두 일치하도록 reset합니다. commit되지 않은 변경 사항과 \<commit> 이후의 모든 commit을 삭제합니다. |
+
+### Git Push
+
+| Command                    | Example                     | Description                                                                                                                                             |
+| -------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| git push \<remote> --force | `git push <remote> --force` | non-fast-forward merge가 아닌 경우에도 git push를 강제로 수행합니다. 자신이 무엇을 하고 있는지 확실하지 않으면 --force 플래그를 사용하지 말아야 합니다. |
+| git push \<remote> --all   | `git push <remote> --all`   | 모든 로컬 branch를 지정한 리모트로 push 합니다.                                                                                                         |
+| git push \<remote> --tags  | `git push <remote> --tags`  | branch를 push하거나 --all 플래그를 사용하면 태그가 자동으로 push되지 않습니다. tags 플래그는 모든 로컬 태그를 원격 리포지토리에 보냅니다.               |
+
+## 자료
+
+- [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)
+
+[Day 38](day38.md)에서 봐요!
--- a/2022/ko/Days/day38.md
+++ b/2022/ko/Days/day38.md
@ -0,0 +1,127 @@
+---
+title: '#90DaysOfDevOps - Staging & Changing - Day 38'
+published: false
+description: 90DaysOfDevOps - Staging & Changing
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049042
+---
+
+## 스테이징 및 변경
+
+이미 몇 가지 기본 사항을 다뤘지만, 이렇게 연습을 해보면 어떻게 그리고 왜 이런 방식으로 작업하는지 더 잘 이해하고 배울 수 있습니다. GitHub와 같은 git 기반 서비스에 들어가기 전에 로컬 워크스테이션에서 활용할 수 있는 git의 강력한 기능을 살펴봅시다.
+
+git 세션을 시작할 때 만든 프로젝트 폴더를 가지고 git으로 할 수 있는 몇 가지 간단한 예제를 보여드리겠습니다. 로컬 머신에 폴더를 생성하고 `git init` 명령으로 초기화했습니다.
+
+![](/2022/Days/Images/Day38_Git1.png)
+
+이제 폴더를 초기화했으므로 디렉토리에 숨겨진 폴더가 있는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git2.png)
+
+이 폴더에는 branch 및 커밋에 관한 정보뿐만 아니라 git 저장소의 세부 정보가 저장됩니다.
+
+### 스테이징 파일
+
+그런 다음 빈 폴더에서 작업을 시작하고 작업 첫날에 소스 코드를 추가할 수 있습니다. README.md 파일을 생성하면 디렉토리에서 해당 파일을 볼 수 있고, 다음으로 `git status`를 확인하면 새 README.md 파일이 보이지만, 아직 그 파일을 커밋하지는 않은 상태입니다.
+
+![](/2022/Days/Images/Day38_Git3.png)
+
+이제 `git add README.md` 명령으로 README.md 파일을 스테이징하면 이전에 없던 변경 사항과 초록색으로 표시되는 새 파일을 커밋할 수 있는 상태가 됩니다.
+
+![](/2022/Days/Images/Day38_Git4.png)
+
+다음으로 프로젝트의 첫 번째 커밋 또는 첫 번째 스냅샷인 이 파일을 커밋하고 싶습니다. 각 커밋에 대해 변경된 내용을 쉽게 확인할 수 있도록 `git commit -m "의미 있는 메시지"` 명령을 사용하여 이 작업을 수행할 수 있습니다. 또한 노란색 십자가가 이제 녹색 체크 표시로 바뀐 것을 확인할 수 있습니다. 이것은 제가 터미널에서 사용하는 테마로, 리눅스 섹션에서 다룬 내용입니다.
+
+![](/2022/Days/Images/Day38_Git5.png)
+
+### 변경 사항 커밋
+
+파일을 더 추가하거나 디렉토리에 있는 파일을 변경하고 싶을 때가 많습니다. 위에서 이미 첫 번째 커밋을 했습니다. 하지만 이제 더 많은 세부 사항으로 더 많은 파일을 추가하겠습니다.
+
+이전 프로세스를 반복하여 파일을 만들거나 수정한 다음 `git add .`를 실행하여 모든 파일을 스테이징 영역에 추가한 다음 `git commit -m "의미 있는 메시지"`를 실행하면 정상적으로 작동할 수 있습니다. 그러나 커밋에 변경된 내용에 대한 의미 있는 메시지를 제공하려면 `git commit -m "음, 일부 코드가 작동하지 않아서 변경했으며, 이를 수정할 때 모든 사람이 사용자 경험에 대해 알 수 있도록 README.md에 새로운 내용을 추가했습니다."`와 같이 설명적인 내용을 작성하는 것도 가능하지만 여기서는 텍스트 편집기를 사용하여 추가하는 것이 더 바람직할 수 있습니다.
+
+`git add`를 실행한 후 `git commit`을 실행하면 기본 텍스트 편집기(여기서는 nano)가 열립니다. 다음은 파일에 몇 가지 변경 사항을 추가하기 위해 수행한 단계이며, `git status`를 실행하여 스테이징된 항목과 스테이징되지 않은 항목을 표시합니다. 그런 다음 `git add`를 사용하여 파일을 스테이징 영역에 추가한 다음 `git commit`을 실행하여 nano를 열었습니다.
+
+![](/2022/Days/Images/Day38_Git6.png)
+
+Nano가 열리면 설명을 추가한 다음 파일을 저장할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git7.png)
+
+### 커밋 모범 사례
+
+커밋 시기와 커밋 횟수 사이에는 균형이 필요합니다. 프로젝트가 끝날 때까지 기다렸다가 커밋하는 것은 바람직하지 않으며, 각 커밋은 의미가 있어야 하고 서로 관련 없는 작업들은 함께 커밋해서는 안 됩니다. 버그 수정과 오타를 해결한 경우, 두 가지 커밋을 분리하여 커밋하는 것이 좋습니다.
+
+커밋 메시지에 의미를 부여하세요.
+
+문구 측면에서, 팀이나 본인이 각 커밋에 대해 동일한 문구를 사용해야 합니다.
+
+### 스테이징 영역 건너뛰기
+
+변경 사항을 커밋하기 전에 항상 스테이징해야 할까요?
+
+정답은 '예'이지만, 롤백할 스냅샷이 필요하지 않다는 것을 100% 확신해야 하며, 이는 위험할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git8.png)
+
+### 파일 제거
+
+프로젝트에서 파일을 제거하는 것은 어떨까요? 디렉토리에 커밋했지만 이제 프로젝트에 더 이상 필요하지 않거나 사용하지 않는 다른 파일이 있는 경우, 파일을 제거해야 합니다.
+
+디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 워크플로우를 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git9.png)
+
+이동하는 파일과 폴더가 많은 대규모 프로젝트의 경우 기억하거나 처리하는 것이 다소 번거로울 수 있습니다. 이 작업은 `git rm oldcode.ps1` 명령 하나로 수행할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git10.png)
+
+### 파일 이름 바꾸기 또는 이동
+
+운영 체제 내에서 파일 이름을 바꾸고 이동할 수 있습니다. 프로젝트에서 때때로 이 작업을 해야 할 때가 있을 것입니다. 2단계 프로세스가 있지만 제거와 유사하게, OS에서 파일을 변경한 다음 스테이징 영역이나 파일이 올바르게 추가되었는지 수정하고 확인해야 합니다. 단계는 다음과 같습니다:
+
+![](/2022/Days/Images/Day38_Git11.png)
+
+그러나 운영 체제에서 파일을 제거한 다음 git 리포지토리에서 파일을 제거하는 것과 마찬가지로 git 명령을 사용하여 이름 변경을 할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git12.png)
+
+### 파일 무시하기
+
+프로젝트 내 로컬에서만 사용 중이거나 전체 프로젝트에 공유되면 공간 낭비일 수 있는 파일이나 폴더를 무시해야 하는 경우가 있는데, 그 좋은 예로 로그를 들 수 있습니다. 또한 공개적으로 또는 팀 간에 공유하고 싶지 않은 비밀에 대해서도 이 기능을 사용할 수 있다고 생각합니다.
+
+프로젝트 디렉토리의 `.gitignore` 파일에 폴더나 파일을 추가하여 파일을 무시할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git13.png)
+
+`.gitignore` 파일을 열면 logs/ 디렉토리가 있는 것을 확인할 수 있습니다. 여기에 무시할 파일과 폴더를 추가할 수도 있습니다.
+
+![](/2022/Days/Images/Day38_Git14.png)
+
+이제 `git status`를 보고 어떤 일이 일어났는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day38_Git15.png)
+
+로그 폴더를 이미 공유했지만, 나중에 공유하면 안 된다는 것을 깨달았을 때 파일과 폴더를 무시해야 하는 경우도 있습니다. 이전에 추적한 폴더가 있지만 이제 무시하고 싶은 경우 `git rm --cached`를 사용하여 스테이징 영역에서 파일과 폴더를 제거해야 합니다.
+
+### 간략한 status
+
+준비 영역에 무엇이 있고 무엇이 없는지 파악하기 위해 `git status`를 많이 사용해왔는데, 이 명령은 매우 포괄적이고 세부적인 내용을 담고 있습니다. 대부분의 경우 무엇이 수정되었는지 또는 무엇이 새로운 것인지 알고 싶을 것입니다. 이 세부 사항에 대한 간단한 상태를 확인하려면 `git status -s`를 사용할 수 있습니다. 저는 보통 시스템에서 단축어로 설정하여 더 자세한 명령 대신 `git status -s`만 사용하도록 합니다.
+
+![](/2022/Days/Images/Day38_Git16.png)
+
+내일 포스트에서는 이러한 일반적인 git 명령에 대한 간략한 예제를 계속 살펴보겠습니다.
+
+## 자료
+
+- [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)
+
+[Day 39](day39.md)에서 봐요!
--- a/2022/ko/Days/day39.md
+++ b/2022/ko/Days/day39.md
@ -0,0 +1,212 @@
+---
+title: '#90DaysOfDevOps - Viewing, unstaging, discarding & restoring - Day 39'
+published: false
+description: '90DaysOfDevOps - Viewing, unstaging, discarding & restoring'
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048827
+---
+
+## 보기, 스테이징 해제, 삭제 및 복원
+
+어제에 이어서 git에서 사용할 수 있는 몇 가지 명령어와 프로젝트에서 git을 활용하는 방법에 대해 알아보겠습니다. 아직 GitHub나 다른 git 기반 서비스에 대해서는 다루지 않았지만, 지금은 로컬에서 프로젝트를 제어하는 데 도움이 되는 내용이며, 향후 해당 도구에 통합되기 시작하면 모두 유용하게 사용할 수 있을 것입니다.
+
+### 스테이징된 변경 사항과 스테이징되지 않은 변경 사항 보기
+
+commit하기 전에 스테이징된 코드와 스테이징되지 않은 코드를 확인하는 것이 좋습니다. 다음 `git diff --staged` 명령을 실행하면 됩니다.
+
+![](/2022/Days/Images/Day39_Git1.png)
+
+그러면 우리가 수행한 모든 변경 사항과 추가하거나 삭제한 모든 새 파일이 표시됩니다.
+
+수정한 파일의 변경 사항은 `---` 또는 `+++`로 표시되며, 아래에서 방금 + 추가한 텍스트는 새로운 줄임을 의미합니다.
+
+![](/2022/Days/Images/Day39_Git2.png)
+
+또한 `git diff`를 실행하여 스테이징 영역과 작업 디렉토리를 비교할 수 있습니다. 새로 추가한 code.txt 파일을 변경하고 몇 줄의 텍스트를 추가하면 다음과 같습니다.
+
+![](/2022/Days/Images/Day39_Git3.png)
+
+그런 다음 `git diff`를 실행하면 아래와 같은 출력을 비교하여 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git4.png)
+
+### 시각적 Diff 도구
+
+저는 위의 방법이 혼란스럽다고 생각하기 때문에 시각적 도구를 사용하는 편이 낫습니다,
+
+몇 가지 시각적 Diff 도구를 소개합니다:
+
+- KDiff3
+- P4Merge
+- WinMerge (Windows 전용)
+- VSCode
+
+git에서 설정하려면 다음 명령 `git config --global diff.tool vscode`를 실행합니다.
+
+위의 명령어를 실행하고 VScode를 시작할 때 몇 가지 매개 변수를 설정하겠습니다.
+
+![](/2022/Days/Images/Day39_Git5.png)
+
+또한 `git config --global -e`로 설정을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git6.png)
+
+이제 `git difftool`을 사용하여 Diff 시각화 도구를 열 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git7.png)
+
+이제 Diff 페이지에서 VScode 에디터를 열고 두 파일을 비교하면, 아무것도 없는 상태에서 오른쪽에 코드 한 줄을 추가한 파일 하나만 수정했습니다.
+
+![](/2022/Days/Images/Day39_Git8.png)
+
+이 방법은 변경 사항을 추적하기가 훨씬 쉬우며, GitHub와 같은 Git 기반 서비스를 살펴볼 때 보게 될 것과 비슷한 방식입니다.
+
+또한 `git difftool --staged`를 사용하여 commit된 파일과 스테이지를 비교할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git9.png)
+
+그러면 commit하기 전에 변경된 파일들을 확인할 수 있게 됩니다.
+
+![](/2022/Days/Images/Day39_Git10.png)
+
+저는 IDE로 VScode를 사용하고 있으며 대부분의 IDE와 마찬가지로 이미 내장되어 있는 명령어이므로 터미널에서 직접 실행해야 하는 경우는 매우 드물지만, 어떤 이유로 IDE가 설치되어 있지 않은 경우 유용합니다.
+
+### 히스토리 보기
+
+앞서 리포지토리에서 수행한 모든 commit을 종합적으로 볼 수 있는 `git log`에 대해 살펴봤습니다.
+
+![](/2022/Days/Images/Day39_Git11.png)
+
+각 commit에는 리포지토리에 고유한 16진수 문자열이 있습니다. 여기에서 작업 중인 branch와 작성자, 날짜, commit 메시지를 확인할 수 있습니다.
+
+또한 `git log --oneline`을 사용하면 다른 `diff` 명령에서 사용할 수 있는 훨씬 더 작은 버전의 16진수 문자열을 얻을 수 있습니다. 또한 한 줄 설명 또는 commit 메시지만 있습니다.
+
+![](/2022/Days/Images/Day39_Git12.png)
+
+`git log --oneline --reverse`를 실행하면 페이지 상단에 첫 번째 commit이 표시됩니다.
+
+![](/2022/Days/Images/Day39_Git13.png)
+
+### commit 보기
+
+commit 메시지를 볼 수 있는 것은 모범 사례를 따르고 의미 있는 commit 메시지를 추가한 경우 매우 유용하지만, commit을 검사하고 볼 수 있는 `git show` 명령도 있습니다.
+
+우리는 `git log --oneline --reverse`를 사용하여 commit 목록을 가져올 수 있습니다. 그런 다음 이를 가져와서 `git show <commit ID>`를 실행할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git14.png)
+
+이 명령의 출력은 commit, 작성자 및 변경된 내용에 대한 세부 정보와 함께 아래와 같이 표시됩니다.
+
+![](/2022/Days/Images/Day39_Git15.png)
+
+`git show HEAD~1`을 사용할 수도 있습니다. 여기서 1은 현재 버전에서 몇 단계 뒤로 돌아가려는지 나타냅니다.
+
+이 방법은 파일에 대한 세부 정보를 원하지만, 전체 스냅샷 디렉토리에 대한 트리의 모든 파일을 나열하려는 경우에 유용합니다. 마지막 commit에서 다시 한 스냅샷을 거슬러 올라가는 `git ls-tree HEAD~1` 명령을 사용하면 이 작업을 수행할 수 있습니다. 아래에서 두 개의 blob이 있는 것을 볼 수 있는데, blob은 파일을 나타내고 트리는 디렉토리를 나타냅니다. 이 정보에서 commit과 태그도 볼 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git16.png)
+
+이제 위의 내용을 사용하여 `git show` 명령을 사용하여 파일(blob)의 내용을 자세히 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git17.png)
+
+그러면 특정 버전의 파일 내용이 표시됩니다.
+
+![](/2022/Days/Images/Day39_Git18.png)
+
+### 파일 스테이징 해제
+
+`git add .`를 사용했지만 아직 해당 스냅샷에 commit하고 싶지 않은 파일이 있는 경우가 있을 수 있습니다. 아래 예제에서는 스테이징 영역에 newfile.txt를 추가했지만, 이 파일을 commit할 준비가 되지 않았으므로 `git restore --staged newfile.txt`를 사용하여 `git add` 단계를 실행 취소하겠습니다.
+
+![](/2022/Days/Images/Day39_Git19.png)
+
+위 그림에서 수정된 파일(예: main.js)에 대해서도 동일한 작업을 수행하여 commit의 스테이징을 해제할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git20.png)
+
+저는 이 명령어가 90DaysOfDevOps 기간 동안 매우 유용하다는 것을 알았습니다. 다음 날을 위한 메모를 작성하고 싶지만, 공개 GitHub 리포지토리에 commit하고 push하고 싶지 않은 날을 앞두고 작업하는 경우가 종종 있기 때문입니다.
+
+### 로컬 변경 사항 삭제하기
+
+때때로 우리는 변경을 했지만, 그 변경이 마음에 들지 않아서 버리고 싶을 때가 있습니다. 다시 `git restore` 명령을 사용하여 스냅샷 또는 이전 버전에서 파일을 복원할 수 있습니다. 디렉토리에 대해 `git restore .`를 실행하면 스냅샷에서 모든 것을 복원할 수 있지만 추적되지 않은 파일이 여전히 존재한다는 것을 알 수 있습니다. 추적 중인 이전 파일은 newfile.txt라는 파일이 없습니다.
+
+![](/2022/Days/Images/Day39_Git21.png)
+
+이제 새로운 파일 txt 또는 추적되지 않은 파일을 제거합니다. 우리는 `git clean`을 사용하면 경고만 받을 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git22.png)
+
+또는 결과를 알고 있다면 `git clean -fd`를 실행하여 모든 디렉토리를 강제로 제거할 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git23.png)
+
+### 파일을 이전 버전으로 복원하기
+
+앞서 언급했듯이 Git의 큰 장점 중 하나는 스냅샷에서 파일 사본을 복원할 수 있다는 점입니다(백업은 아니지만 매우 빠른 복원 방법입니다). 백업 솔루션을 사용하여 코드 사본을 다른 위치에도 저장하는 것을 추천드립니다.
+
+예시로 디렉토리에서 가장 중요한 파일을 삭제해 보겠습니다. 디렉토리에서 이 파일을 제거하기 위해 git 명령이 아닌 Unix 기반 명령을 사용하고 있음을 알 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git24.png)
+
+이제 작업 디렉토리에 readme.md가 없습니다. `git rm readme.md`를 사용하면 git 데이터베이스에 반영될 수 있습니다. 완전히 제거된 것을 시뮬레이션하기 위해 여기서도 삭제해 보겠습니다.
+
+![](/2022/Days/Images/Day39_Git25.png)
+
+이제 이 내용을 메시지와 함께 commit하고 작업 디렉토리 또는 스테이징 영역에 더 이상 아무것도 없음을 증명해 보겠습니다.
+
+![](/2022/Days/Images/Day39_Git26.png)
+
+실수가 있었으니 이제 이 파일을 되돌릴 필요가 있습니다!
+
+`git undo` 명령을 사용하여 마지막 commit을 취소할 수 있지만, 오래된 commit이라면 어떻게 해야 할까요? `git log` 명령을 사용하여 commit 기록을 찾을 수 있습니다. 파일이 마지막 commit에 포함되어 있다는 것을 확인했지만, 모든 commit을 취소하고 싶지는 않습니다. 이 경우 `git restore --source=HEAD~1 README.md` 명령을 사용하여 특정 파일을 찾고 스냅샷에서 복원할 수 있습니다.
+
+이 프로세스를 통해 파일을 작업 디렉토리에 다시 가져온 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day39_Git27.png)
+
+이제 추적되지 않은 새 파일이 생겼으며 앞서 언급한 명령을 사용하여 파일과 변경 사항을 추적, 스테이징 및 commit할 수 있습니다.
+
+### Rebase와 Merge
+
+git 리포지토리에서 언제 rebase를 사용해야 하는지, 언제 merge를 사용해야 하는지가 가장 골치 아픈 문제인 것 같습니다.
+
+가장 먼저 알아야 할 것은 `git rebase`와 `git merge`이 모두 같은 문제를 해결한다는 것입니다. 둘 다 한 branch의 변경 내용을 다른 branch에 통합하는 것입니다. 하지만 다른 방식으로 이 작업을 수행합니다.
+
+새로운 feature branch로 새로운 기능을 만들어보겠습니다. main branch는 새로운 commit이 계속 추가되고 있습니다.
+
+![](/2022/Days/Images/Day39_Git28.png)
+
+여기서 쉬운 옵션은 `git merge feature main`을 사용하여 main branch를 feature branch에 merge하는 것입니다.
+
+![](/2022/Days/Images/Day39_Git29.png)
+
+merge는 비파괴적이기 때문에 간단합니다. 기존 branch는 어떤 방식으로도 변경되지 않습니다. 하지만 feature branch에 업스트림 변경 사항을 통합해야 할 때마다 관련 없는 merge commit이 발생하게 됩니다. main branch가 매우 바쁘거나 활성 상태인 경우 feature branch 히스토리를 오염시킬 수도 있습니다.
+
+다른 옵션으로, feature branch를 main branch에 rebase하는 방법도 있습니다.
+
+```
+git checkout feature
+git rebase main
+```
+
+이렇게 하면 feature branch(전체 feature branch)가 main branch에 모든 새 commit을 효과적으로 통합합니다. 그러나 merge commit을 사용하는 대신 rebase는 원래 branch에 있는 각 commit에 대해 새로운 commit을 생성하여 프로젝트 기록을 다시 작성하게 됩니다.
+
+![](/2022/Days/Images/Day39_Git30.png)
+
+rebase의 가장 큰 장점은 프로젝트 히스토리가 훨씬 깔끔해진다는 것입니다. 또한 불필요한 merge commit을 제거하며, 마지막 두 이미지를 비교하면 훨씬 더 깔끔한 선형 프로젝트 히스토리를 따라갈 수 있습니다.
+
+아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 워크플로에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다.
+
+## 자료
+
+- [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/)
+
+[Day 40](day40.md)에서 봐요!
--- a/2022/ko/Days/day40.md
+++ b/2022/ko/Days/day40.md
@ -0,0 +1,210 @@
+---
+title: '#90DaysOfDevOps - Social Network for code - Day 40'
+published: false
+description: 90DaysOfDevOps - Social Network for code
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049044
+---
+
+## 코드를 위한 소셜 네트워크
+
+GitHub 살펴보기 | GitLab | BitBucket
+
+오늘은 우리 모두가 들어봤을 법한, 그리고 우리도 매일 사용할 것으로 예상되는 몇 가지 git 기반 서비스를 다루고자 합니다.
+
+그런 다음 이전 세션에서 배운 지식을 사용하여 데이터의 사본을 각 주요 서비스로 이동해 보겠습니다.
+
+이 섹션을 "코드를 위한 소셜 네트워크"라고 부른 이유를 설명해드릴까요?
+
+### GitHub
+
+적어도 저에게 가장 일반적인 것은 GitHub입니다. GitHub는 Git을 위한 웹 기반 호스팅 서비스입니다. 소프트웨어 개발자가 코드를 저장하는 데 가장 일반적으로 사용합니다. git 버전 관리 기능뿐만 아니라 다양한 추가 기능을 통해 소스 코드를 관리할 수 있습니다. 팀이나 오픈 컨트리뷰터가 쉽게 소통할 수 있으며 코딩에 소셜 측면을 제공합니다. (따라서 소셜 네트워킹이라는 제목을 붙였습니다.) 2018년부터 GitHub는 Microsoft의 일부가 되었습니다.
+
+GitHub는 2007/2008년에 설립되어 꽤 오래전부터 존재해 왔습니다. 현재 4천만 명 이상의 사용자가 이 플랫폼을 사용하고 있습니다.
+
+GitHub 주요 기능
+
+- 코드 리포지토리
+- Pull Requests
+- 프로젝트 관리 도구 세트 - Issues
+- CI/CD 파이프라인 - GitHub Actions
+
+가격 측면에서 GitHub는 사용자에 따라 다양한 수준의 가격을 책정합니다. 자세한 내용은 [가격](https://github.com/pricing)에서 확인할 수 있습니다.
+
+여기서는 프리티어를 다루겠습니다.
+
+이 안내에서는 이미 생성한 GitHub 계정을 사용할 예정이므로 계정이 없는 경우, GitHub 시작 페이지에서 가입 옵션과 몇 가지 간단한 단계를 통해 설정할 수 있습니다.
+
+### GitHub 시작 페이지
+
+GitHub 계정에 처음 로그인하면 다양한 위젯이 포함된 페이지가 표시되어 어디에서 무엇을 보고 싶고 무엇을 할 것인지에 대한 옵션을 제공합니다. 먼저 "All Activity"를 통해 리포지토리에서 어떤 일이 일어나고 있는지 또는 조직이나 계정과 관련된 일반적인 활동을 살펴볼 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git1.png)
+
+다음으로, 자체 리포지토리 또는 최근에 상호 작용한 리포지토리가 있는 코드 리포지토리가 있습니다. 새 리포지토리나 검색 리포지토리를 빠르게 생성할 수도 있습니다.
+
+![](/2022/Days/Images/Day40_Git2.png)
+
+최근 활동은 제가 최근에 만들었거나 기여한 issues와 pull requests입니다.
+
+![](/2022/Days/Images/Day40_Git3.png)
+
+페이지 오른쪽에는 최근 활동 또는 자체 프로젝트를 기반으로 관심을 가질 만한 리포지토리에 대한 추천이 있습니다.
+
+![](/2022/Days/Images/Day40_Git4.png)
+
+솔직히 저는 방금 보고 설명한 홈페이지에 거의 들어가지 않지만, 특정 프로젝트에서 커뮤니티와 좀 더 잘 소통하는 데 이 피드가 정말 유용할 수 있다는 것을 깨달았습니다.
+
+다음으로 GitHub 프로필로 이동하려면 오른쪽 상단 모서리로 이동하면 이미지에 계정을 탐색할 수 있는 드롭다운이 있습니다. 여기에서 프로필에 액세스하려면 "Your Profile"을 선택합니다.
+
+![](/2022/Days/Images/Day40_Git5.png)
+
+다음으로 프로필 페이지가 표시되는데, 기본적으로 설정을 변경하지 않는 한 내가 가진 것을 볼 수 없으며, [vZilla](https://vzilla.co.uk)의 최근 블로그 게시물과 내 [YouTube](https://m.youtube.com/c/MichaelCade1) 채널의 최신 동영상을 보여주는 기능을 추가했습니다.
+
+프로필을 보는 데 많은 시간을 할애하지는 않겠지만, 현재 진행 중인 멋진 프로젝트를 볼 수 있도록 네트워크에 공유하기에 좋은 프로필 페이지입니다.
+
+![](/2022/Days/Images/Day40_Git6.png)
+
+이제 GitHub의 빌딩 블록인 리포지토리를 자세히 살펴볼 수 있습니다. 여기에서 리포지토리를 볼 수 있으며 비공개 리포지토리가 있는 경우 이 긴 목록에 해당 리포지토리도 표시됩니다.
+
+![](/2022/Days/Images/Day40_Git7.png)
+
+리포지토리는 GitHub에서 매우 중요하기 때문에 최근에 많이 사용된 리포지토리를 선택하여 로컬 시스템에서 git으로 "코드"를 편집할 때 이미 사용하고 있는 모든 기능 외에 여기서 사용할 수 있는 핵심 기능 몇 가지를 살펴보겠습니다.
+
+우선, 이전 창에서 90DaysOfDevOps 리포지토리를 선택했더니 다음과 같은 보기가 표시됩니다. 이 보기에서 많은 정보를 볼 수 있으며, 리포지토리에 저장된 파일과 폴더를 보여주는 기본 코드 구조가 있습니다. 맨 아래에는 README.md이 표시됩니다. 페이지 오른쪽에는 리포지토리에 대한 설명과 목적이 있는 정보 섹션이 있습니다. 그리고 그 아래에는 얼마나 많은 사람들이 프로젝트에 참여하고, folk하고, 봤는지 보여주는 많은 정보가 있습니다.
+
+![](/2022/Days/Images/Day40_Git8.png)
+
+조금 더 아래로 스크롤하면 릴리즈가 있는 것을 볼 수 있는데, 이는 챌린지의 Go 언어 부분에서 나온 것입니다. 우리 프로젝트에는 패키지가 없으며 여기에 기여자가 나열되어 있습니다. (오타와 사실 확인에 도움을 주신 커뮤니티에 감사드립니다.) 그런 다음 챌린지의 다른 섹션에서 다시 사용된 언어가 있습니다.
+
+![](/2022/Days/Images/Day40_Git9.png)
+
+페이지 상단에 탭 목록이 표시됩니다. 탭은 다양할 수 있으며 필요한 탭만 표시하도록 수정할 수 있습니다. 이 탭들을 모두 사용하지 않으므로 전체 리포지토리를 깔끔하게 정리하려면 이 탭들을 제거해야 한다는 것을 알 수 있습니다.
+
+먼저 방금 설명한 코드 탭이 있는데, 이 탭은 리포지토리를 탐색할 때 항상 사용할 수 있으므로 섹션 사이를 빠르고 쉽게 이동할 수 있어 매우 유용합니다. 다음으로 issues 탭이 있습니다.
+
+issues를 사용하면 개발이 이루어지는 GitHub에서 작업을 추적할 수 있습니다. 이 특정 리포지토리에는 다이어그램이나 오타를 추가하는 데 중점을 둔 몇 가지 issues가 있지만 중국어 버전의 리포지토리에 대한 필요성 또는 요구 사항을 명시하는 issues도 있음을 알 수 있습니다.
+
+이 리포지토리가 코드 리포지토리라면 유지 관리자에게 우려 사항이나 문제를 제기하기에 좋은 곳이지만, 보고하는 내용을 염두에 두고 가능한 한 자세하게 설명해야 함을 잊지 마세요.
+
+![](/2022/Days/Images/Day40_Git10.png)
+
+다음 탭은 pull requests이며, pull requests를 사용하면 리포지토리의 branch에 push한 변경 사항을 다른 사람에게 알릴 수 있습니다. 누군가 리포지토리를 folk하여 버그 수정이나 기능 개선 등의 변경을 하거나 이 리포지토리의 많은 경우, 오타를 수정했을 수 있습니다.
+
+folk에 대해서는 나중에 다루겠습니다.
+
+![](/2022/Days/Images/Day40_Git11.png)
+
+다음 탭은 꽤 새로운 탭이라고 생각되죠? #90DaysOfDevOps와 같은 프로젝트에서는 이 탭이 콘텐츠 여정을 안내하는 데 도움이 될 뿐만 아니라 커뮤니티가 학습 여정을 걸어가는 데도 도움이 될 수 있다고 생각했습니다. 챌린지의 각 섹션에 대한 토론 그룹을 만들어 사람들이 참여하여 토론할 수 있도록 했습니다.
+
+![](/2022/Days/Images/Day40_Git12.png)
+
+Actions 탭을 사용하면 GitHub 내에서 바로 코드를 빌드, 테스트 및 배포하는 등 다양한 작업을 수행할 수 있습니다. GitHub 작업은 챌린지의 CI/CD 섹션에서 다루겠지만, 여기에서 몇 가지 구성을 설정하여 단계를 자동화할 수 있습니다.
+
+제 기본 GitHub 프로필에서는 GitHub Actions를 사용하여 최신 블로그 게시물과 YouTube 동영상을 가져와 홈 화면에 최신 정보를 표시하고 있습니다.
+
+![](/2022/Days/Images/Day40_Git13.png)
+
+위에서 GitHub가 단순한 소스 코드 리포지토리가 아니라 프로젝트 관리 도구라고 말씀드렸는데, Projects 탭에서는 프로젝트 테이블을 칸반 형식의 보드로 구성하여 issues와 PR을 연결하여 프로젝트에 대한 협업을 개선하고 해당 작업에 대한 가시성을 확보할 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git14.png)
+
+issues가 기능 요청을 기록하기에 좋은 곳인 것 같고 실제로도 그렇지만 Wiki 페이지를 사용하면 프로젝트에 대한 포괄적인 로드맵을 현재 상태와 함께 설명할 수 있고 일반적으로 문제 해결 또는 방법 유형 콘텐츠 등 프로젝트에 대한 문서화를 더 잘 할 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git15.png)
+
+이 프로젝트에는 해당되지 않지만, Security 탭은 기여자가 특정 작업을 처리하는 방법을 알 수 있도록 하기 위한 탭으로, 여기에서 정책을 정의할 수 있을 뿐만 아니라 코드 검사 애드온을 사용하여 코드에 비밀 환경 변수가 포함되어 있지 않은지 확인할 수도 있습니다.
+
+![](/2022/Days/Images/Day40_Git16.png)
+
+Insight 탭은 리포지토리의 활동량부터 commit 및 issues에 이르기까지 리포지토리에 대한 많은 정보를 제공할 뿐만 아니라 리포지토리에 대한 트래픽도 보고해줘서 매우 유용합니다. 왼쪽에 리포지토리의 메트릭에 대해 자세히 살펴볼 수 있는 목록이 표시됩니다.
+
+![](/2022/Days/Images/Day40_Git17.png)
+
+마지막으로 Settings 탭이 있는데, 여기서 리포지토리를 실행하는 방법에 대한 세부 정보를 확인할 수 있으며, 현재 리포지토리의 유일한 관리자는 저이지만, 여기서 다른 사람에게 권한을 부여할 수 있습니다. 여기에서 통합 및 기타 작업을 정의할 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git18.png)
+
+지금까지 GitHub에 대한 간략한 개요를 살펴봤는데, 좀 더 자세히 설명해야 할 부분이 몇 가지 더 있을 것 같습니다. 앞서 언급했듯이 GitHub에는 수백만 개의 리포지토리가 있으며, 대부분 소스 코드가 저장되어 있고 공개 또는 비공개로 액세스할 수 있습니다.
+
+### Folk
+
+내일 세션에서 오픈소스에 대해 더 자세히 다룰 예정이지만, 코드 리포지토리의 가장 큰 장점은 커뮤니티와 협업할 수 있다는 점입니다. 리포지토리에 몇 가지 변경을 하고 싶어서, 버그를 수정하고 싶어서, 또는 원래 코드 관리자가 의도한 사용 사례가 아닌 다른 사용 사례에 사용하기 위해 무언가를 변경하고 싶어서 리포지토리의 복사본을 원하는 시나리오를 생각해 봅시다. 이를 리포지토리 folk라고 합니다. folk는 리포지토리의 복사본입니다. 리포지토리를 folk하면 원래 프로젝트에 영향을 주지 않고 자유롭게 변경 사항을 실험할 수 있습니다.
+
+로그인 후 시작 페이지로 돌아가서 추천 리포지토리 중 하나를 살펴보겠습니다.
+
+![](/2022/Days/Images/Day40_Git19.png)
+
+해당 리포지토리를 클릭하면 방금 살펴본 90DaysOfDevOps 리포지토리와 동일한 모습을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git20.png)
+
+아래에서 3가지 옵션이 있음을 알 수 있습니다. Watch, Folk, Star가 있습니다.
+
+- Watch - 리포지토리에 어떤 일이 발생하면 업데이트합니다.
+- Folk - 리포지토리의 복사본.
+- Star - "프로젝트가 멋진 것 같아요"
+
+![](/2022/Days/Images/Day40_Git21.png)
+
+이 리포지토리의 복사본을 작업하고 싶다는 시나리오를 고려할 때, folk 옵션을 사용하겠습니다. 여러 조직의 구성원인 경우, folk가 발생할 위치를 선택해야 하는데, 저는 제 프로필을 선택하겠습니다.
+
+![](/2022/Days/Images/Day40_Git22.png)
+
+이제 우리는 자유롭게 작업하고 필요에 따라 변경할 수 있는 리포지토리 사본을 갖게 되었습니다. 이것이 앞서 잠깐 언급했던 pull requests 프로세스의 시작이지만 내일 더 자세히 다루겠습니다.
+
+![](/2022/Days/Images/Day40_Git23.png)
+
+이 리포지토리와 코드가 웹사이트에 있는 경우, 웹사이트에 가서 편집할 수는 있지만 로컬 시스템에서 좋아하는 색상 테마로 좋아하는 IDE를 사용하는 것과는 다를 것입니다. 로컬 시스템에서 이 리포지토리의 복사본을 얻으려면 리포지토리의 복제를 수행합니다. 이렇게 하면 로컬에서 작업한 다음 변경 사항을 folk된 리포지토리 사본에 다시 push할 수 있습니다.
+
+아래에서 볼 수 있듯이 이 코드의 복사본을 얻는 데는 몇 가지 옵션이 있습니다.
+
+변경 사항을 추적하고 로컬과 GitHub 간에 변경 사항을 push 및 pull할 수 있는 시각적 데스크톱 애플리케이션을 제공하는 GitHub Desktop의 로컬 버전이 있습니다.
+
+이 작은 데모에서는 여기에 표시된 HTTPS URL을 사용하겠습니다.
+
+![](/2022/Days/Images/Day40_Git24.png)
+
+이제 로컬 컴퓨터에서 이 리포지토리를 다운로드할 디렉토리로 이동한 다음 `git clone url`을 실행하겠습니다.
+
+![](/2022/Days/Images/Day40_Git25.png)
+
+이제 VScode로 가져가서 몇 가지 변경을 할 수 있습니다.
+
+![](/2022/Days/Images/Day40_Git26.png)
+
+이제 몇 가지 변경을 해보겠습니다. 모든 링크를 변경하고 다른 것으로 바꾸고 싶습니다.
+
+![](/2022/Days/Images/Day40_Git27.png)
+
+이제 GitHub를 다시 확인하고 해당 리포지토리에서 README.md을 찾으면 파일에 몇 가지 변경한 내용을 볼 수 있을 것입니다.
+
+![](/2022/Days/Images/Day40_Git28.png)
+
+이 단계에서는 이 작업이 완료되고 우리만 새로운 변경 사항을 사용할 것이므로 변경 사항에 만족할 수도 있지만, 버그 변경일 수도 있으며 이 경우, pull requests를 통해 기여하여 원래 리포지토리 관리자에게 변경 사항을 알리고 변경 사항을 수락하는지 확인하고 싶을 것입니다.
+
+아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 워크플로우를 살펴보면서 이에 대해 더 자세히 다루겠습니다.
+
+![](/2022/Days/Images/Day40_Git29.png)
+
+오랜 시간 동안 GitHub를 살펴봤는데 다른 옵션은 없는지 궁금해하시는 분들도 계실 것 같습니다!
+
+글쎄요, 그런 옵션도 있고 그중 일부에 대한 기본 사항을 다루는 몇 가지 리소스를 찾아보려고 합니다. 앞으로 GitLab과 BitBucket을 만나게 될 텐데, 이 두 서비스는 git 기반 서비스이긴 하지만 차이점이 있습니다.
+
+또한 호스팅 옵션도 있습니다. 호스팅 버전인 GitLab과 무료 호스팅 GitHub도 있을 거라고 생각하지 않으신가요?
+
+## 자료
+
+- [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)
+
+[Day 41](day41.md)에서 봐요!
--- a/2022/ko/Days/day41.md
+++ b/2022/ko/Days/day41.md
@ -0,0 +1,127 @@
+---
+title: '#90DaysOfDevOps - The Open Source Workflow - Day 41'
+published: false
+description: 90DaysOfDevOps - The Open Source Workflow
+tags: 'DevOps, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048806
+---
+
+## 오픈 소스 워크플로
+
+지난 7회에 걸친 Git 섹션을 통해 Git이 무엇인지, 그리고 GitHub와 같은 Git 기반 서비스가 어떻게 소스 코드 저장소를 제공할 뿐만 아니라 더 많은 커뮤니티가 함께 코드와 프로젝트를 협업할 수 있는 방법을 제공하는지 더 잘 이해하셨기를 바랍니다.
+
+GitHub의 기본 사항을 살펴볼 때 임의의 프로젝트를 fork하고 로컬 리포지토리를 변경하는 과정을 거쳤습니다. 여기서는 한 단계 더 나아가 오픈소스 프로젝트에 기여하고자 합니다. 기여는 반드시 버그 수정이나 코딩 기능일 필요는 없으며 문서화일 수도 있다는 점을 기억하세요. 작은 도움이라도 모두 의미 있으며, 지금까지 다룬 몇 가지 git 기능을 직접 사용해 볼 수 있습니다.
+
+## 프로젝트 fork하기
+
+가장 먼저 해야 할 일은 우리가 기여할 수 있는 프로젝트를 찾는 것입니다. 저는 최근 [Kanister 프로젝트](https://github.com/kanisterio/kanister)에서 발표를 하고 있는데, 현재 유튜브에 올라와 있는 프레젠테이션을 프로젝트의 메인 README.md 파일에 공유하고자 합니다.
+
+우선 프로젝트를 fork해야 합니다. 그 과정을 살펴보겠습니다. 위에서 공유한 링크로 이동하여 리포지토리를 fork하겠습니다.
+
+![](/2022/Days/Images/Day41_Git1.png)
+
+이제 전체 리포지토리의 복사본을 얻었습니다.
+
+![](/2022/Days/Images/Day41_Git2.png)
+
+참고로 README.md 파일에 나열된 원본 프레젠테이션은 이 두 개뿐이므로 프로세스를 통해 이 문제를 해결해야 합니다.
+
+![](/2022/Days/Images/Day41_Git3.png)
+
+## 로컬 머신에 복제
+
+이제 fork를 로컬로 가져와서 파일에 대한 편집을 시작할 수 있습니다. 리포지토리의 코드 버튼을 사용하여 URL을 가져온 다음 리포지토리를 배치하려는 디렉토리에 `git clone url`을 사용하면 됩니다.
+
+![](/2022/Days/Images/Day41_Git4.png)
+
+## 변경하기
+
+프로젝트가 로컬에 있으므로 VSCode 또는 원하는 IDE 또는 텍스트 편집기를 열어 수정 사항을 추가할 수 있습니다.
+
+![](/2022/Days/Images/Day41_Git5.png)
+
+READEME.md 파일은 마크다운 언어로 작성되었으며, 다른 사람의 프로젝트를 수정하고 있으므로 기존 프로젝트 형식을 따라 콘텐츠를 추가하겠습니다.
+
+![](/2022/Days/Images/Day41_Git6.png)
+
+## 변경 사항 테스트하기
+
+코드 변경 후에도 애플리케이션이 계속 작동하는지 확인하려면 변경 사항을 테스트하는 것이 가장 좋은 방법이며, 문서 형식이 올바르게 지정되어 있는지 확인해야 합니다.
+
+VSCode에서는 많은 플러그인을 추가할 수 있는데, 그중 하나가 마크다운 페이지를 미리 볼 수 있는 기능입니다.
+
+![](/2022/Days/Images/Day41_Git7.png)
+
+## 변경 사항을 fork된 리포지토리로 push하기
+
+변경 사항을 Kanister 리포지토리로 직접 push할 수 있는 권한이 없으므로 이 경로를 사용해야 합니다. 이제 변경 사항에 만족하므로 이제 잘 알려진 몇 가지 git 명령을 실행할 수 있습니다.
+
+![](/2022/Days/Images/Day41_Git8.png)
+
+이제 GitHub로 돌아가서 변경 사항을 다시 한번 확인한 다음 마스터 프로젝트에 다시 기여합니다.
+
+좋아 보이네요.
+
+![](/2022/Days/Images/Day41_Git9.png)
+
+이제 Kanister의 fork된 리포지토리 상단으로 돌아가서 kanisterio:master branch보다 commit이 1개 앞선 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day41_Git10.png)
+
+다음으로 위에 강조 표시된 기여 버튼을 누릅니다. "Open Pull Request" 옵션이 표시됩니다.
+
+![](/2022/Days/Images/Day41_Git11.png)
+
+## Open Pull Request
+
+다음 이미지에서 꽤 많은 일이 진행되고 있습니다. 왼쪽 위에는 이제 원본 또는 마스터 리포지토리에 있는 것을 볼 수 있습니다. 그리고 비교 대상인 원본 마스터 리포지토리와 fork된 리포지토리를 볼 수 있습니다. 이제 Create Pull Request 버튼이 있는데, 곧 다시 설명하겠습니다. 단일 commit이 있지만 변경 사항이 더 많으면 여기에 여러 개의 commit이 있을 수 있습니다. 그러면 README.md 파일에 변경 사항이 있습니다.
+
+![](/2022/Days/Images/Day41_Git12.png)
+
+위의 변경 사항을 검토했으며 녹색 버튼을 눌러 pull requests를 생성할 준비가 되었습니다.
+
+그런 다음 프로젝트 관리자가 리포지토리에 pull requests 기능을 어떻게 설정했는지에 따라 관리자가 보고자 하는 내용을 알려주는 템플릿이 있을 수도 있고 없을 수도 있습니다.
+
+여기서도 자신이 한 일에 대해 명확하고 간결하면서도 충분히 상세하게 의미 있는 설명을 작성해야 합니다. 간단한 변경 개요를 작성하고 문서화를 체크한 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day41_Git13.png)
+
+## Create Pull Request
+
+이제 pull requests를 만들 준비가 되었습니다. 페이지 상단의 "Create Pull Request"를 누르면 pull requests에 대한 요약이 표시됩니다.
+
+![](/2022/Days/Images/Day41_Git14.png)
+
+아래로 스크롤하면 일부 자동화가 진행 중인 것을 볼 수 있는데, 이 경우 검토가 필요하며 몇 가지 확인이 진행 중입니다. Travis CI가 진행 중이고 빌드가 시작되었음을 알 수 있으며, 업데이트를 확인하여 merge하기 전에 추가한 내용이 손상되지 않았는지 확인합니다.
+
+![](/2022/Days/Images/Day41_Git15.png)
+
+위 스크린샷에서 보이는 빨간색은 약간 위협적으로 보일 수 있으며, 마치 실수를 저질렀다고 생각할 수 있습니다. 걱정하지 마세요, 아무것도 망가뜨린 것이 없습니다. 여기서 가장 중요한 팁은 이 과정이 당신과 프로젝트 관리자를 돕기 위한 것이라는 것입니다. 혹시 실수를 저질렀다면 제 경험에 따르면 관리자가 연락하여 다음에 무엇을 해야 할지 조언해줄 것입니다.
+
+이 pull requests는 이제 모든 사람이 볼 수 있도록 공개되었습니다 [added Kanister presentation/resource #1237](https://github.com/kanisterio/kanister/pull/1237).
+
+merge 및 pull requests가 수락되기 전에 이 글을 게시하려고 합니다. 따라서 여전히 관심을 가지고 있는 사람들에게 성공적인 PR의 사진을 추가할 수 있는 작은 보상을 제공할 수 있을 것입니다.
+
+1. 이 저장소를 귀하의 GitHub 계정으로 folk하세요.
+2. 사진과 함께 텍스트를 추가해 주세요.
+3. 변경 사항을 folk된 저장소에 push하세요.
+4. 제가 볼 수 있고 승인할 수 있는 PR을 생성하세요.
+5. 일종의 보상을 생각해 볼게요.
+
+이것으로 Git과 GitHub에 대해 살펴본 내용을 마무리하고, 다음에는 컨테이너를 어떻게, 왜 사용하는지에 대한 큰 그림부터 시작하여 가상화에 대해 살펴보고 여기까지 오게 된 과정을 살펴볼 것입니다.
+
+## 자료
+
+- [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)
+
+[Day 42](day42.md)에서 봐요!
--- a/2022/ko/Days/day42.md
+++ b/2022/ko/Days/day42.md
@ -0,0 +1,136 @@
+---
+title: '#90DaysOfDevOps - The Big Picture: Containers - Day 42'
+published: false
+description: 90DaysOfDevOps - The Big Picture Containers
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048826
+---
+
+## 큰 그림: 컨테이너
+
+이제 다음 섹션을 시작하겠습니다. 이번 섹션에서는 컨테이너, 특히 컨테이너에 대해 더 많이 이해하기 위해 몇 가지 핵심 영역에 대해 살펴보는 Docker를 중점적으로 다룰 것입니다.
+
+또한 이 섹션뿐만 아니라 챌린지 후반부의 다음 섹션에서도 사용할 수 있는 컨테이너를 만들기 위한 실습도 해보려고 합니다.
+
+언제나 그렇듯이 이번 첫 번째 포스팅에서는 우리가 어떻게 여기까지 왔는지, 그리고 이 모든 것이 무엇을 의미하는지에 대한 큰 그림에 초점을 맞출 것입니다.
+
+플랫폼 및 애플리케이션 개발의 역사 가상화 및 컨테이너화에 대해 이야기하고 싶습니다.
+
+### 왜 애플리케이션을 실행하는 다른 방법일까요?
+
+가장 먼저 살펴봐야 할 것은 소프트웨어나 애플리케이션을 실행하는 다른 방법이 필요한 이유입니다. 다양한 형태로 애플리케이션을 실행할 수 있기 때문입니다. 물리적 하드웨어에 운영 체제와 단일 애플리케이션이 배포된 애플리케이션을 볼 수도 있고, 가상 머신 또는 클라우드 기반 IaaS 인스턴스가 애플리케이션을 실행한 다음 다시 가상 머신의 데이터베이스에 통합되거나 퍼블릭 클라우드의 PaaS 제품으로 통합되는 것을 볼 수도 있습니다. 또는 애플리케이션이 컨테이너에서 실행되는 것을 볼 수도 있습니다.
+
+위의 옵션 중 어느 것도 틀린 것도, 옳은 것도 아니지만 각 옵션이 존재해야 하는 이유가 있으며, 저는 이 중 어느 것도 사라지지 않을 것이라고 굳게 믿습니다. 컨테이너와 가상 머신을 비교하는 콘텐츠를 많이 봤는데, 이는 사과와 배를 비교하는 것과 같이 둘 다 과일(애플리케이션을 실행하는 방법)이지만 같은 과일이 아니기 때문에 논쟁을 해서는 안 됩니다.
+
+또한 애플리케이션을 개발 중이라면 나중에 이러한 영역 중 일부를 다루겠지만 효율성, 속도 및 크기에 관한 것이므로 컨테이너에 기대야 한다고 말씀드리고 싶습니다. 하지만 여기에는 대가가 따르는데, 컨테이너에 대해 전혀 모른다면 그 이유를 이해하고 그 사고방식에 익숙해지려면 학습 곡선을 밟아야 할 것입니다. 애플리케이션을 특정 방식으로 개발했거나 그린필드 환경이 아니라면 컨테이너를 고려하기 전에 해결해야 할 문제가 더 많을 수 있습니다.
+
+특정 소프트웨어를 다운로드할 때 사용할 수 있는 운영 체제가 다양하기 때문에 선택의 폭이 넓어집니다. 그리고 애플리케이션을 설치하기 위해 수행해야 하는 작업에 대한 구체적인 지침도 있습니다.
+
+![](/2022/Days/Images/Day42_Containers1.png)
+
+최근에는 예전에는 전체 서버 OS, 가상 머신, 물리적 또는 클라우드 인스턴스가 필요했던 애플리케이션이 이제 컨테이너 기반 버전의 소프트웨어를 출시하는 경우가 점점 더 많아지고 있습니다. 이는 애플리케이션 개발자에게만 초점을 맞추는 것이 아니라 모든 사람에게 컨테이너와 쿠버네티스의 세계를 열어준다는 점에서 흥미롭습니다.
+
+![](/2022/Days/Images/Day42_Containers2.png)
+
+앞서 말씀드렸듯이, 저는 컨테이너가 정답이라고 주장하지는 않겠습니다. 하지만 애플리케이션을 배포할 때 고려해야 할 또 다른 옵션이 컨테이너라는 점을 말씀드리고 싶습니다.
+
+![](/2022/Days/Images/Day42_Containers4.png)
+
+최근 10년 동안, 특히 지난 5년간 컨테이너 기술이 인기를 얻은 이유는 무엇일까요? 이미 수십 년 동안 컨테이너 기술이 존재해 왔습니다. 이 문제는 컨테이너와 이미지라는 용어를 두고, 소프트웨어 배포 방식의 도전 과제로 귀결됩니다. 만약 단순히 컨테이너 기술만을 가지고 있다면, 여전히 소프트웨어 관리에 있어서 겪었던 여러 문제들이 계속 발생할 것입니다.
+
+docker를 도구로 생각하면, docker가 성공할 수 있었던 이유는 쉽게 찾고 사용할 수 있는 이미지 에코시스템 때문입니다. 시스템에 설치하고 실행하는 것이 간단합니다. 그중 가장 중요한 부분은 소프트웨어에서 직면하는 다양한 과제에 대한 전체 공간의 일관성입니다. MongoDB든 nodeJS든 상관없이 두 가지를 모두 실행하는 프로세스는 동일합니다. 중단하는 과정도 마찬가지입니다. 이러한 모든 문제는 여전히 존재하겠지만, 좋은 점은 좋은 컨테이너와 이미지 기술을 함께 사용하면 이러한 다양한 문제를 모두 해결하는 데 도움이 되는 단일 도구 세트를 갖게 된다는 것입니다. 이러한 문제 중 일부는 다음과 같습니다:
+
+- 먼저 인터넷에서 소프트웨어를 찾아야 합니다.
+- 그런 다음, 이 소프트웨어를 다운로드해야 합니다.
+- 소스를 신뢰할 수 있는가?
+- 라이선스가 필요한가요? 어떤 라이선스가 필요한가요?
+- 다른 플랫폼과 호환되는가?
+- 패키지는 무엇인가요? 바이너리인가요? 실행 파일인가요? 패키지 관리자?
+- 소프트웨어를 어떻게 구성하나요?
+- 종속성은 무엇인가요? 전체 다운로드에 포함되어 있나요, 아니면 추가로 필요한가요?
+- 종속성의 종속성?
+- 애플리케이션을 어떻게 시작하나요?
+- 애플리케이션을 어떻게 중지하나요?
+- 자동으로 다시 시작되나요?
+- 부팅 시 시작되나요?
+- 리소스 충돌?
+- 충돌하는 라이브러리?
+- 포트 충돌
+- 소프트웨어 보안?
+- 소프트웨어 업데이트?
+- 소프트웨어를 제거하려면 어떻게 해야 하나요?
+
+위의 내용을 소프트웨어의 복잡성 중 컨테이너와 이미지가 도움이 되는 세 가지 영역으로 나눌 수 있습니다.
+
+| Distribution | Installation  | Operation          |
+| ------------ | ------------- | ------------------ |
+| Find         | Install       | Start              |
+| Download     | Configuration | Security           |
+| License      | Uninstall     | Ports              |
+| Package      | Dependencies  | Resource Conflicts |
+| Trust        | Platform      | Auto-Restart       |
+| Find         | Libraries     | Updates            |
+
+컨테이너와 이미지는 다른 소프트웨어와 애플리케이션에서 겪을 수 있는 이러한 문제 중 일부를 제거하는 데 도움이 될 것입니다.
+
+높은 수준에서 설치와 운영을 동일한 목록으로 옮길 수 있으며, 이미지는 배포 관점에서, 컨테이너는 설치와 운영에 도움이 될 것입니다.
+
+좋아요, 멋지고 흥미진진하게 들리겠지만 컨테이너가 무엇인지 이해할 필요가 있고 이제 이미지를 언급했으니 다음에는 그 부분을 다루겠습니다.
+
+소프트웨어 개발용 컨테이너에 대해 이야기할 때 많이 보셨을 또 다른 것은 선적 컨테이너와 함께 사용되는 비유입니다. 선적 컨테이너는 대형 선박을 사용하여 바다를 가로질러 다양한 물품을 운송하는 데 사용됩니다.
+
+![](/2022/Days/Images/Day42_Containers5.png)
+
+이것이 컨테이너라는 주제와 어떤 관련이 있을까요? 소프트웨어 개발자가 작성하는 코드를 생각해 보세요. 특정 코드를 한 컴퓨터에서 다른 컴퓨터로 어떻게 전송할 수 있을까요?
+
+앞서 소프트웨어 배포, 설치 및 운영에 대해 다룬 내용을 이제 환경 비주얼로 구축하기 시작하면 다음과 같습니다. 여러 애플리케이션을 실행할 하드웨어와 운영 체제가 있습니다. 예를 들어 nodejs에는 특정 종속성이 있고 특정 라이브러리가 필요합니다. 그런 다음 MySQL을 설치하려면 필요한 라이브러리와 종속성이 필요합니다. 각 소프트웨어 애플리케이션에는 해당 라이브러리와 종속성이 있습니다. 운이 좋아서 특정 라이브러리와 종속성이 충돌하여 문제를 일으키는 애플리케이션 간에 충돌이 발생하지 않을 수도 있지만, 애플리케이션이 많을수록 충돌의 가능성이나 위험은 높아집니다. 그러나 소프트웨어 애플리케이션을 모두 수정한 후 업데이트하면 이러한 충돌이 발생할 수도 있습니다.
+
+![](/2022/Days/Images/Day42_Containers6.png)
+
+컨테이너는 이 문제를 해결하는 데 도움이 될 수 있습니다. 컨테이너는 애플리케이션을 **구축**하고, 애플리케이션을 **배송**하고, 이러한 애플리케이션을 독립적으로 쉽게 **배포**하고 **확장**할 수 있도록 도와줍니다. 아키텍처를 살펴보면 하드웨어와 운영체제가 있고 그 위에 나중에 다룰 docker(docker)와 같은 컨테이너 엔진이 있습니다. 컨테이너 엔진 소프트웨어는 라이브러리와 종속성을 함께 패키징하는 컨테이너를 생성하는 데 도움이 되므로 라이브러리와 종속성이 컨테이너 패키지의 일부로 제공되므로 라이브러리와 종속성에 대한 걱정 없이 이 컨테이너를 한 시스템에서 다른 시스템으로 원활하게 이동할 수 있으므로 이 컨테이너는 애플리케이션이 실행하는 데 필요한 기본 종속성에 대한 걱정 없이 시스템 간에 이동이 가능합니다.
+애플리케이션이 실행하는 데 필요한 모든 것이 컨테이너로 패키징되어 있기 때문에
+컨테이너로 패키징되어 있기 때문입니다.
+
+![](/2022/Days/Images/Day42_Containers7.png)
+
+### 컨테이너의 장점
+
+- 컨테이너는 컨테이너 내의 모든 종속성을 패키징하고 격리할 수 있습니다.
+
+- 컨테이너를 쉽게 관리할 수 있습니다.
+
+- 한 시스템에서 다른 시스템으로 이동할 수 있습니다.
+
+- 컨테이너는 소프트웨어를 패키징하는 데 도움이 되며 중복 작업 없이 쉽게 배포할 수 있습니다.
+
+- 컨테이너는 쉽게 확장할 수 있습니다.
+
+컨테이너를 사용하면 독립적인 컨테이너를 확장하고 로드 밸런서를 사용할 수 있습니다.
+또는 트래픽을 분할하는 데 도움이 되는 서비스를 사용하여 애플리케이션을 수평적으로 확장할 수 있습니다. 컨테이너는 애플리케이션 관리 방식에 있어 많은 유연성과 편의성을 제공합니다.
+
+### 컨테이너란 무엇인가요?
+
+컴퓨터에서 애플리케이션을 실행할 때 이 글을 읽는 데 사용하고 있는 웹 브라우저나 VScode가 컨테이너일 수 있습니다. 해당 애플리케이션은 프로세스로 실행되거나 프로세스라고 하는 것으로 알려져 있습니다. 노트북이나 시스템에서는 여러 개의 애플리케이션 또는 프로세스를 실행하는 경향이 있습니다. 새 애플리케이션을 열거나 애플리케이션 아이콘을 클릭하면 이 애플리케이션은 우리가 실행하려는 애플리케이션이며, 때로는 이 애플리케이션이 백그라운드에서 실행하려는 서비스일 수도 있으며, 운영 체제는 백그라운드에서 실행되는 서비스로 가득 차 있어 시스템에서 얻을 수 있는 사용자 경험을 제공합니다.
+
+이 애플리케이션 아이콘은 파일 시스템 어딘가에 있는 실행 파일에 대한 링크를 나타내며, 운영 체제는 해당 실행 파일을 메모리에 로드합니다. 흥미롭게도 프로세스에 대해 이야기할 때 이 실행 파일을 이미지라고 부르기도 합니다.
+
+컨테이너는 프로세스로, 컨테이너는 코드와 모든 종속성을 패키징하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위입니다.
+
+컨테이너화된 소프트웨어는 인프라에 관계없이 항상 동일하게 실행됩니다. 컨테이너는 소프트웨어를 환경으로부터 분리하여 개발 환경과 스테이징 환경 간의 차이에도 불구하고 소프트웨어가 균일하게 작동하도록 보장합니다.
+
+지난 섹션에서 컨테이너와 이미지의 결합이 어떻게 그리고 왜 우리 에코시스템에서 컨테이너가 인기를 얻게 되었는지에 관해 이미지를 언급했습니다.
+
+### 이미지란 무엇인가요?
+
+컨테이너 이미지는 경량의 독립형 실행형 소프트웨어 패키지입니다.
+
+## 자료
+
+- [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)
+
+[Day 43](day43.md)에서 봐요!
--- a/2022/ko/Days/day43.md
+++ b/2022/ko/Days/day43.md
@ -0,0 +1,88 @@
+---
+title: '#90DaysOfDevOps - What is Docker & Getting installed - Day 43'
+published: false
+description: 90DaysOfDevOps - What is Docker & Getting installed
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048739
+---
+
+## Docker를 알아보고 설치하기
+
+이전 포스팅에서 docker에 대해 한 번쯤은 언급했는데, 그 이유는 docker가 컨테이너가 오래전부터 사용되어 왔음에도 불구하고 대중화될 수 있었던 혁신적인 기술이기 때문입니다.
+
+여기서는 docker를 사용하고 설명할 예정이지만, 벤더 종속의 위험을 피하면서 혁신을 장려하는 산업 표준 조직인 [Open Container Initiative(OCI)](https://www.opencontainers.org/)에 대해서도 언급해야 합니다. OCI 덕분에 컨테이너 툴체인을 선택할 때 Docker, [CRI-O](https://cri-o.io/), [Podman](http://podman.io/), [LXC](https://linuxcontainers.org/) 등을 선택할 수 있게 되었습니다.
+
+docker는 컨테이너를 빌드, 실행 및 관리하기 위한 소프트웨어 프레임워크입니다. "docker"라는 용어는 도구(명령어 및 데몬) 또는 Dockerfile 파일 형식을 지칭할 수 있습니다.
+
+여기서는 (교육 및 학습용으로) 무료인 Docker Personal을 사용하겠습니다. 여기에는 컨테이너와 도구에 대한 지식의 기초를 다지기 위해 다루어야 할 모든 필수 사항이 포함됩니다.
+
+우리가 사용할 몇 가지 "docker" 도구와 그 용도를 세분화해 볼 가치가 있을 것입니다. docker라는 용어는 개발자와 관리자가 애플리케이션을 개발, 배포 및 실행하기 위한 플랫폼인 docker 프로젝트 전반을 지칭할 수 있습니다. 또한 이미지와 컨테이너를 관리하는 호스트에서 실행되는 docker 데몬 프로세스를 지칭할 수도 있으며, Docker Engine이라고도 합니다.
+
+### Docker Engine
+
+Docker Engine은 애플리케이션을 빌드하고 컨테이너화하기 위한 오픈소스 컨테이너화 기술입니다. Docker Engine은 클라이언트-서버 애플리케이션으로 작동합니다:
+
+- 장기 실행 데몬 프로세스인 dockerd가 있는 서버.
+- API는 프로그램이 Docker 데몬과 대화하고 지시하는 데 사용할 수 있는 인터페이스를 지정합니다.
+- 커맨드라인 인터페이스(CLI) 클라이언트 docker입니다.
+
+위의 내용은 공식 docker 문서와 특정 [Docker Engine 개요](https://docs.docker.com/engine/)에서 발췌한 것입니다.
+
+### Docker Desktop
+
+저희는 Windows와 macOS 시스템 모두를 위한 Docker Desktop을 제공합니다. 설치하기 쉬운 경량 docker 개발 환경입니다. 호스트 운영 체제의 가상화 기능을 활용하는 네이티브 OS 애플리케이션입니다.
+
+Windows 또는 macOS에서 docker화된 애플리케이션을 빌드, 디버그, 테스트, 패키징 및 출시하려는 경우 가장 적합한 솔루션입니다.
+
+Windows에서는 WSL2와 Microsoft Hyper-V도 활용할 수 있습니다. WSL2의 몇 가지 이점은 차근차근 살펴보도록 하겠습니다.
+
+호스트 운영 체제의 하이퍼바이저 기능과 통합되어 있기 때문에 docker는 리눅스 운영 체제에서 컨테이너를 실행할 수 있는 기능을 제공합니다.
+
+### Docker Compose
+
+Docker Compose는 여러 컨테이너에서 더 복잡한 앱을 실행할 수 있는 도구입니다. 단일 파일과 명령을 사용하여 애플리케이션을 스핀업할 수 있다는 이점이 있습니다.
+
+### Docker Hub
+
+docker와 그 구성 요소로 작업하기 위한 중앙 집중식 리소스입니다. 가장 일반적으로는 docker 이미지를 호스팅하는 레지스트리로 알려져 있습니다. 그러나 여기에는 부분적으로 자동화와 함께 사용하거나 보안 검사뿐만 아니라 GitHub에 통합할 수 있는 많은 추가 서비스가 있습니다.
+
+### Dockerfile
+
+Dockerfile은 일반적으로 docker 이미지를 빌드하기 위해 수동으로 실행하는 명령이 포함된 텍스트 파일입니다. docker는 Dockerfile에 있는 지침을 읽어 이미지를 자동으로 빌드할 수 있습니다.
+
+## Docker Desktop 설치
+
+[Docker 문서](https://docs.docker.com/engine/install/)는 매우 훌륭하며, 이제 막 docker에 입문하는 분이라면 꼭 한 번 읽어보시기 바랍니다. 여기서는 WSL2가 설치된 Windows에서 Docker Desktop을 사용하겠습니다. 여기서 사용하는 머신에 이미 설치를 완료했습니다.
+
+![](/2022/Days/Images/Day43_Containers1.png)
+
+설치를 진행하기 전에 시스템 요구 사항을 참고하시기 바라며, [윈도우에 Docker Desktop 설치하기](https://docs.docker.com/desktop/windows/install/)를 참고하시고, M1 기반 CPU 아키텍처를 포함한 맥OS를 사용하시는 경우 [맥OS에 docker Desktop 설치하기](https://docs.docker.com/desktop/mac/install/)도 참고하시면 됩니다.
+
+다른 윈도우 머신에서 윈도우용 docker Desktop 설치를 실행하고 그 과정을 아래에 기록해 보겠습니다.
+
+### Windows
+
+- 장치의 운영 체제로 Windows를 선택합니다.
+  <img src = ../../Days/Images/Day43_operatingSystem.png>
+
+- 인스톨러를 저장할 폴더로 이동하여 저장합니다.
+
+- 인스톨러를 실행하고 몇 초간 기다린 후 WSL에 대한 액세스 권한을 부여합니다.
+  <img src = ../../Days/Images/Day43_EnableWSL.png>
+
+- 확인을 클릭하면 설치가 시작됩니다.
+  <img src = ../../Days/Images/Day43_install.png>
+
+- Docker Desktop이 장치에 성공적으로 설치되었습니다. 이제 터미널에서 "docker" 명령을 실행하여 설치가 성공적으로 완료되었는지 확인할 수 있습니다.
+  <img src = ../../Days/Images/Day43_check.png>
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+
+[Day 44](day44.md)에서 봐요!
--- a/2022/ko/Days/day44.md
+++ b/2022/ko/Days/day44.md
@ -0,0 +1,141 @@
+---
+title: '#90DaysOfDevOps - Docker Images & Hands-On with Docker Desktop - Day 44'
+published: false
+description: 90DaysOfDevOps - Docker Images & Hands-On with Docker Desktop
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048708
+---
+
+## Docker 이미지 및 Docker Desktop 실습하기
+
+이제 시스템에 Docker Desktop을 설치했습니다. (Linux를 실행하는 경우 여전히 옵션은 있지만 GUI는 없지만 Docker는 Linux에서 작동합니다.)[우분투에 Docker Engine 설치](https://docs.docker.com/engine/install/ubuntu/) (다른 배포판도 사용할 수 있습니다.)
+
+이 글에서는 몇 가지 이미지를 우리 환경에 배포하는 작업을 시작하겠습니다. Docker 이미지에 대한 요약 - Docker 이미지는 Docker 컨테이너에서 코드를 실행하는 데 사용되는 파일입니다. Docker 이미지는 템플릿처럼 Docker 컨테이너를 빌드하기 위한 일련의 지침 역할을 합니다. 또한 Docker 이미지는 Docker를 사용할 때 시작점 역할을 하기도 합니다.
+
+지금 바로 [Docker Hub](https://hub.docker.com/)에서 계정을 생성하세요.
+
+![](/2022/Days/Images/Day44_Containers1.png)
+
+Docker Hub는 Docker 및 그 구성 요소로 작업하기 위한 중앙 집중식 리소스입니다. 가장 일반적으로는 docker 이미지를 호스팅하는 레지스트리로 알려져 있습니다. 그러나 여기에는 부분적으로 자동화와 함께 사용하거나 보안 검사뿐만 아니라 GitHub에 통합할 수 있는 많은 추가 서비스가 있습니다.
+
+로그인한 후 아래로 스크롤하면 컨테이너 이미지 목록이 표시되며, MySQL, hello-world 등의 데이터베이스 이미지가 표시될 수 있습니다. 데이터베이스 이미지가 필요하거나 직접 만들 필요가 없는 경우 공식 이미지를 사용하는 것이 가장 좋습니다.
+
+![](/2022/Days/Images/Day44_Containers2.png)
+
+사용 가능한 이미지 보기를 더 자세히 살펴보고 카테고리, 운영 체제 및 아키텍처에 따라 검색할 수 있습니다. 아래에서 강조 표시한 것은 공식 이미지로, 이 컨테이너 이미지의 출처에 대해 안심할 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers3.png)
+
+특정 이미지를 검색할 수도 있습니다. 예를 들어 워드프레스가 좋은 기본 이미지가 될 수 있으므로 상단에 있는 이미지를 검색하여 워드프레스와 관련된 모든 컨테이너 이미지를 찾을 수 있습니다. 아래는 확인된 퍼블리셔에 대한 공지사항입니다.
+
+- 공식 이미지 - Docker 공식 이미지는 엄선된 Docker 오픈 소스 및 "drop-in" 솔루션 리포지토리 집합입니다.
+
+- 검증된 퍼블리셔 - 검증된 퍼블리셔의 고품질 Docker 콘텐츠입니다. 이러한 제품은 상업적 주체가 직접 게시하고 유지 관리합니다.
+
+![](/2022/Days/Images/Day44_Containers4.png)
+
+### Docker Desktop 살펴보기
+
+저희 시스템에는 Docker Desktop이 설치되어 있으며, 이 파일을 열면 이미 설치되어 있지 않다면 아래 이미지와 비슷한 것을 볼 수 있을 것입니다. 보시다시피 컨테이너가 실행되고 있지 않고 Docker Engine이 실행되고 있습니다.
+
+![](/2022/Days/Images/Day44_Containers5.png)
+
+새로 설치한 것이 아니기 때문에 이미 다운로드하여 시스템에 사용할 수 있는 이미지가 몇 개 있습니다. 여기에는 아무것도 표시되지 않을 것입니다.
+
+![](/2022/Days/Images/Day44_Containers6.png)
+
+원격 리포지토리 아래에서 Docker Hub에 저장한 컨테이너 이미지를 찾을 수 있습니다. 아래에서 볼 수 있듯이 이미지가 없습니다.
+
+![](/2022/Days/Images/Day44_Containers7.png)
+
+Docker Hub 사이트에서도 리포지토리가 없음을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers8.png)
+
+다음으로 Volumes 탭이 있는데, 지속성이 필요한 컨테이너가 있는 경우 여기에서 로컬 파일 시스템이나 공유 파일 시스템에 이러한 Volumes를 추가할 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers9.png)
+
+이 글을 쓰는 시점에 Environments 탭도 있는데, 이 탭은 다른 git branch 사이를 이동하지 않고 팀과 협업하는 데 도움이 될 것입니다. 여기서는 다루지 않겠습니다.
+
+![](/2022/Days/Images/Day44_Containers10.png)
+
+첫 번째 탭으로 돌아가면 시작 컨테이너를 실행할 수 있는 명령이 있음을 알 수 있습니다. 터미널에서 `docker run -d -p 80:80 docker/getting-started`를 실행해 보겠습니다.
+
+![](/2022/Days/Images/Day44_Containers11.png)
+
+Docker Desktop 창을 다시 확인하면 컨테이너가 실행 중인 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers12.png)
+
+WSL2를 사용하고 있다는 것을 눈치채셨을 텐데요, 이를 사용하려면 설정에서 이 기능이 활성화되어 있는지 확인해야 합니다.
+
+![](/2022/Days/Images/Day44_Containers13.png)
+
+이제 Images 탭으로 다시 이동하여 확인하면 이제 사용 중인 이미지인 docker/getting-started를 볼 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers14.png)
+
+Containers/Apps 탭으로 돌아가서 실행 중인 컨테이너를 클릭합니다. 기본적으로 로그가 표시되고 상단에 선택할 수 있는 몇 가지 옵션이 있는데, 이 컨테이너에서 실행 중인 웹 페이지가 될 것이 확실하므로 브라우저에서 열기를 선택하겠습니다.
+
+![](/2022/Days/Images/Day44_Containers15.png)
+
+위의 버튼을 누르면 로컬호스트로 연결되는 웹 페이지가 열리고 아래와 비슷한 내용이 표시됩니다.
+
+이 컨테이너에는 컨테이너와 이미지에 대한 자세한 내용도 있습니다.
+
+![](/2022/Days/Images/Day44_Containers16.png)
+이제 첫 번째 컨테이너를 실행했습니다. 아직은 쉽습니다. 컨테이너 이미지 중 하나를 Docker Hub에서 가져오고 싶다면 어떻게 해야 할까요? 아마도 우리가 사용할 수 있는 `hello world` docker 컨테이너가 있을 것입니다.
+
+시작 컨테이너는 리소스를 많이 차지하기 때문이 아니라 몇 가지 단계를 더 진행하면서 깔끔하게 정리하기 위해 중단했습니다.
+
+터미널로 돌아와서 `docker run hello-world`를 실행하고 어떤 일이 일어나는지 살펴봅시다.
+
+로컬에 이미지가 없었기 때문에 이미지를 끌어내렸고, 컨테이너 이미지에 시작 및 실행에 대한 몇 가지 정보와 참조 지점에 대한 링크가 포함된 메시지가 표시되는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers17.png)
+
+그러나 이제 Docker Desktop을 살펴보면 실행 중인 컨테이너는 없지만, hello-world 메시지를 사용한 종료된 컨테이너, 즉 시작되어 메시지를 전달한 후 종료된 컨테이너는 있습니다.
+
+![](/2022/Days/Images/Day44_Containers18.png)
+
+마지막으로 Images 탭을 확인해보면 시스템에 로컬로 새로운 hello-world 이미지가 있는 것을 확인할 수 있습니다. 즉, 터미널에서 `docker run hello-world` 명령을 다시 실행해도 버전이 변경되지 않는 한 아무것도 가져올 필요가 없습니다.
+
+![](/2022/Days/Images/Day44_Containers19.png)
+
+'hello-world' 컨테이너에서 온 메시지로 인해 조금 더 야심찬 도전을 하고 싶어졌습니다.
+
+도전!
+
+![](/2022/Days/Images/Day44_Containers20.png)
+
+터미널에서 `docker run -it ubuntu bash`를 실행할 때 우리는 운영 체제의 전체 복사본이 아닌 우분투의 컨테이너화된 버전을 실행할 것입니다. 이 특정 이미지에 대한 자세한 내용은 [Docker Hub](https://hub.docker.com/_/ubuntu)에서 확인할 수 있습니다.
+
+아래 명령어를 실행하면 대화형 프롬프트(`-it`)가 나타나고 컨테이너에 bash 셸이 생성되는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day44_Containers21.png)
+
+bash 셸이 있지만 그 이상은 없기 때문에 이 컨테이너 이미지는 30MB 미만입니다.
+
+![](/2022/Days/Images/Day44_Containers22.png)
+
+하지만 여전히 이 이미지를 사용할 수 있고, apt package manager를 사용하여 소프트웨어를 설치할 수 있으며, 컨테이너 이미지를 업데이트하고 업그레이드할 수도 있습니다.
+
+![](/2022/Days/Images/Day44_Containers23.png)
+
+또는 컨테이너에 일부 소프트웨어를 설치하고 싶을 수도 있습니다. pinta는 이미지 편집기이고 200MB가 넘기 때문에 여기서는 정말 나쁜 예를 선택했지만 제가 이걸로 무엇을 하려는지 이해하시길 바랍니다. 이렇게 하면 컨테이너의 크기가 상당히 커지지만, 여전히 GB가 아닌 MB 단위로 사용할 것입니다.
+
+![](/2022/Days/Images/Day44_Containers24.png)
+
+이 글에서는 사용 사례를 통해 Docker Desktop과 컨테이너의 세계에 대한 개요를 간단하고 접근하기 쉬운 방식으로 제공하고자 합니다. 그러나 컨테이너 이미지를 다운로드하고 사용하는 것 외에도 네트워킹, 보안 및 기타 사용 가능한 옵션에 대해서도 다뤄야 합니다. 이 섹션의 궁극적인 목표는 무언가를 만들어서 Docker Hub 리포지토리에 업로드하고 배포하는 것입니다.
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+
+[Day 45](day45.md)에서 봐요!
--- a/2022/ko/Days/day45.md
+++ b/2022/ko/Days/day45.md
@ -0,0 +1,119 @@
+---
+title: '#90DaysOfDevOps - The anatomy of a Docker Image - Day 45'
+published: false
+description: 90DaysOfDevOps - The anatomy of a Docker Image
+tags: 'DevOps, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048777
+---
+
+## Docker 이미지의 구조
+
+지난 세션에서는 Docker Hub와 결합된 Docker Desktop을 사용하여 몇 가지 검증된 이미지를 배포하고 실행하는 방법에 대한 몇 가지 기본 사항을 다루었습니다. 이미지가 무엇인지에 대한 요약을 계속 언급하면 잊어버리지 않을 것입니다.
+
+Docker 이미지는 Docker 플랫폼에서 실행할 수 있는 컨테이너를 만들기 위한 일련의 지침이 포함된 읽기 전용 템플릿입니다. 애플리케이션과 사전 구성된 서버 환경을 패키징하여 개인적으로 사용하거나 다른 Docker 사용자와 공개적으로 공유할 수 있는 편리한 방법을 제공합니다. 또한 Docker 이미지는 Docker를 처음 사용하는 모든 사용자에게 시작점이 됩니다.
+
+자체 Docker 이미지를 만들려면 어떻게 해야 하나요? 이를 위해서는 Dockerfile을 생성해야 합니다. 우분투 컨테이너 이미지를 가져와서 소프트웨어를 추가하면 원하는 소프트웨어가 포함된 컨테이너 이미지를 갖게 되고 모든 것이 좋지만, 컨테이너가 종료되거나 폐기되면 모든 소프트웨어 업데이트와 설치가 사라져 반복할 수 있는 버전이 없습니다. 따라서 컨테이너를 실행할 때마다 동일한 소프트웨어 세트가 설치된 여러 환경에 걸쳐 이미지를 전송하는 데는 도움이 되지 않습니다.
+
+### Dockerfile이란?
+
+Dockerfile은 일반적으로 docker 이미지를 빌드하기 위해 수동으로 실행하는 명령이 포함된 텍스트 파일입니다. docker는 Dockerfile에 있는 지침을 읽어 이미지를 자동으로 빌드할 수 있습니다.
+
+docker 이미지를 구성하는 각 파일을 레이어라고 하며, 이러한 레이어는 단계적으로 서로 위에 빌드되는 일련의 이미지를 형성합니다. 각 레이어는 바로 아래 레이어에 종속됩니다. 레이어의 순서는 docker 이미지의 라이프사이클 관리 효율성의 핵심입니다.
+
+가장 자주 변경되는 레이어는 가능한 한 스택에서 가장 높은 곳에 구성해야 하는데, 이는 이미지의 레이어를 변경하면 Docker가 해당 레이어뿐만 아니라 해당 레이어에서 빌드된 모든 레이어를 다시 빌드하기 때문입니다. 따라서 맨 위에 있는 레이어를 변경하면 전체 이미지를 다시 빌드하는 데 필요한 작업량이 가장 적습니다.
+
+docker가 이미지로부터 컨테이너를 실행할 때마다 (어제 실행한 것처럼), 컨테이너 레이어라고 하는 쓰기 가능한 레이어가 추가됩니다. 이 레이어는 컨테이너가 실행되는 동안 모든 변경 사항을 저장합니다. 이 레이어는 실제 운영 중인 컨테이너와 소스 이미지 자체 사이의 유일한 차이점입니다. 같은 이미지에 기반한 동일한 컨테이너들이 상태를 유지하면서 액세스를 공유할 수 있습니다.
+
+예제로 돌아가서, 어제 우분투 이미지를 사용했습니다. 동일한 명령을 여러 번 실행하여 첫 번째 컨테이너에는 pinta를 설치하고 두 번째 컨테이너에는 두 개의 다른 애플리케이션, 다른 목적, 다른 크기 등을 가진 figlet을 설치할 수 있습니다. 배포한 각 컨테이너는 동일한 이미지를 공유하지만, 동일한 상태는 아니며, 컨테이너를 제거하면 해당 상태는 사라집니다.
+
+![](/2022/Days/Images/Day45_Containers1.png)
+
+위의 예제에서 우분투 이미지뿐만 아니라 Docker Hub 및 기타 서드파티 리포지토리에서 사용할 수 있는 다른 많은 기성 컨테이너 이미지도 마찬가지입니다. 이러한 이미지를 일반적으로 부모 이미지라고 합니다. 이 이미지는 다른 모든 레이어가 구축되는 기반이 되며 컨테이너 환경의 기본 구성 요소를 제공합니다.
+
+개별 레이어 파일 세트와 함께 Docker 이미지에는 manifest라는 추가 파일도 포함됩니다. 이 파일은 기본적으로 이미지에 대한 JSON 형식의 설명이며 이미지 태그, 전자 서명, 다양한 유형의 호스트 플랫폼에 맞게 컨테이너를 구성하는 방법에 대한 세부 정보와 같은 정보로 구성됩니다.
+
+![](/2022/Days/Images/Day45_Containers2.png)
+
+### Docker 이미지를 생성하는 방법
+
+docker 이미지를 생성하는 방법에는 두 가지가 있습니다. 어제 시작한 프로세스로 즉석에서 만들 수 있습니다. 기본 이미지를 선택하여 해당 컨테이너를 스핀업하고 컨테이너에 원하는 모든 소프트웨어와 종속성을 설치합니다.
+
+그런 다음 `docker commit container name`을 사용하면 이 이미지의 로컬 복사본이 docker 이미지와 Docker Desktop 이미지 탭 아래에 있습니다.
+
+매우 간단하지만, 프로세스를 이해하고 싶은 게 아니라면, 이 방법을 권장하지 않습니다. 이 방법은 라이프사이클 관리를 관리하기가 매우 어렵고 수동 구성/재구성이 많이 필요합니다. 하지만 docker 이미지를 빌드하는 가장 빠르고 간단한 방법입니다. 테스트, 문제 해결, 종속성 검증 등에 적합합니다.
+
+우리가 이미지를 생성하려는 방법은 Dockerfile을 통한 방법입니다. 이는 이미지를 만드는 깔끔하고 간결하며 반복 가능한 방법을 제공합니다. 더 쉬운 라이프사이클 관리와 지속적인 통합 및 지속적인 배포 프로세스에 쉽게 통합할 수 있습니다. 하지만 처음 언급된 방법보다 조금 더 어려울 수 있습니다.
+
+Dockerfile 방법을 사용하는 것이 실제 엔터프라이즈급 컨테이너 배포에 훨씬 더 잘 맞습니다.
+
+Dockerfile은 3단계 프로세스를 통해 Dockerfile을 만들고 이미지를 조립하는 데 필요한 명령을 추가합니다.
+
+다음 표는 사용자가 가장 많이 사용할 가능성이 높은 몇 가지 Dockerfile 설정을 보여줍니다.
+
+| Command    | Purpose                                                                                                                              |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| FROM       | 상위 이미지를 지정합니다.                                                                                                            |
+| WORKDIR    | Dockerfile에서 다음에 나오는 명령의 작업 디렉터리를 설정합니다.                                                                      |
+| RUN        | 컨테이너에 필요한 애플리케이션과 패키지를 설치합니다.                                                                                |
+| COPY       | 특정 위치에서 파일 또는 디렉터리를 복사합니다.                                                                                       |
+| ADD        | 복사뿐만 아니라 원격 URL을 처리하고 압축 파일의 압축을 풀 수도 있습니다.                                                             |
+| ENTRYPOINT | 컨테이너가 시작될 때 항상 실행되는 명령입니다. 지정하지 않으면 기본값은 "/bin/sh -c"입니다.                                          |
+| CMD        | 엔트리포인트로 전달된 인자입니다. 엔트리포인트가 설정되지 않은 경우(기본값은 "/bin/sh -c"), 컨테이너가 실행하는 명령은 CMD가 됩니다. |
+| EXPOSE     | 컨테이너 애플리케이션에 액세스할 포트를 정의합니다.                                                                                  |
+| LABEL      | 이미지에 메타데이터를 추가합니다.                                                                                                    |
+
+이제 첫 번째 Dockerfile을 빌드하는 방법에 대한 세부 정보를 얻었으므로 작업 디렉터리를 생성하고 Dockerfile을 만들 수 있습니다. 이 리포지토리 내에 작업 디렉터리를 만들었는데, [여기서](/2022/Days/Containers/) 제가 살펴봐야 할 파일과 폴더를 볼 수 있습니다.
+
+이 디렉터리에는 지난 섹션에서 사용한 .gitignore와 유사한 .dockerignore 파일을 만들겠습니다. 이 파일에는 최종 빌드에서 제외하려는 Docker 빌드 프로세스 중에 생성되는 모든 파일이 나열됩니다.
+
+컨테이너는 부피가 커지지 않고 가능한 한 빠르게 컴팩트하게 만들어야 함을 기억하세요.
+
+위에 링크된 폴더에서 아래 레이아웃으로 매우 간단한 Dockerfile을 만들고 싶습니다.
+
+```dockerfile
+# 공식 우분투 18.04를 기본으로 사용하세요.
+FROM ubuntu:18.04
+# nginx 및 curl 설치
+RUN apt-get update && apt-get upgrade -y
+RUN apt-get install -y nginx curl
+RUN rm -rf /var/lib/apt/lists/*
+```
+
+터미널에서 이 디렉토리로 이동한 다음 `docker build -t 90daysofdevops:0.1 .`를 실행합니다. `-t`를 사용한 다에는 이미지 이름과 태그를 설정할 수 있습니다.
+
+![](/2022/Days/Images/Day45_Containers3.png)
+
+이제 이미지를 만들었으므로 Docker Desktop을 사용하여 이미지를 실행하거나 docker 커맨드라인을 사용할 수 있습니다. 저의 경우에는 Docker Desktop을 사용하여 컨테이너를 실행하고, 컨테이너의 cli에서 `curl`을 사용한 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day45_Containers4.png)
+
+Docker Desktop에서는 UI를 활용하여 이 새로운 이미지로 몇 가지 작업을 더 수행할 수 있습니다.
+
+![](/2022/Days/Images/Day45_Containers5.png)
+
+이미지를 검사하면 컨테이너 내에서 실행하려고 하는 Dockerfile과 코드들을 매우 많이 볼 수 있습니다.
+
+![](/2022/Days/Images/Day45_Containers6.png)
+
+pull 옵션이 있지만, 이 이미지는 어디에도 호스팅되지 않기 때문에 이 옵션은 실패할 것이고 오류로 표시됩니다. 하지만 Push to hub 옵션이 있어 이미지를 DockerHub로 push할 수 있습니다.
+
+앞서 실행한 것과 동일한 `docker build`를 사용하는 경우에도 이 방법이 작동하지 않으므로 빌드 명령을 `docker build -t {{username}}/{{imagename}}:{{version}}`로 해야 합니다.
+
+![](/2022/Days/Images/Day45_Containers7.png)
+
+이제 Docker Hub 리포지토리로 이동하여 살펴보면 방금 새 이미지를 push한 것을 확인할 수 있습니다. 이제 Docker Desktop에서 해당 pull 탭을 사용할 수 있습니다.
+
+![](/2022/Days/Images/Day45_Containers8.png)
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+- [Blog on gettng started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
+- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
+
+[Day 46](day46.md)에서 봐요!
--- a/2022/ko/Days/day46.md
+++ b/2022/ko/Days/day46.md
@ -0,0 +1,183 @@
+---
+title: '#90DaysOfDevOps - Docker Compose - Day 46'
+published: false
+description: 90DaysOfDevOps - Docker Compose
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048740
+---
+
+## Docker Compose
+
+하나의 컨테이너를 실행할 수 있는 기능은 단일 사용 사례에 필요한 모든 것을 갖춘 독립적인 이미지가 있는 경우 유용할 수 있지만, 서로 다른 컨테이너 이미지 간에 여러 애플리케이션을 빌드하려는 경우 흥미로운 문제가 발생할 수 있습니다. 예를 들어, 웹사이트 프론트엔드가 있지만 백엔드 데이터베이스가 필요한 경우 모든 것을 하나의 컨테이너에 넣을 수 있지만 데이터베이스용 컨테이너를 사용하는 것이 더 효율적이고 좋을 것입니다.
+
+이때 여러 컨테이너에서 더 복잡한 앱을 실행할 수 있는 도구인 Docker Compose가 등장합니다. 단일 파일과 명령을 사용하여 애플리케이션을 스핀업할 수 있다는 이점이 있습니다. 이 글에서 안내하는 예제는 [Docker 빠른 시작 샘플 앱(빠른 시작: 작성 및 워드프레스)](https://docs.docker.com/samples/wordpress/)에서 가져온 것입니다.
+
+이 첫 번째 예제에서는
+
+- Docker Compose를 사용하여 WordPress와 별도의 MySQL 인스턴스를 불러옵니다.
+- 'docker-compose.yml'이라는 YAML 파일을 사용합니다.
+- 프로젝트 빌드
+- 브라우저를 통해 워드프레스 구성
+- 종료 및 정리
+
+### Docker Compose 설치
+
+앞서 언급했듯이 docker compose는 도구이며, 맥OS나 윈도우를 사용하는 경우 Docker Desktop 설치에 compose가 포함되어 있습니다. 하지만, 윈도우 서버 호스트나 리눅스 서버에서 컨테이너를 실행하고 싶을 수 있으며, 이 경우 다음 [docker compose 설치](https://docs.docker.com/compose/install/) 지침을 사용하여 설치할 수 있습니다.
+
+터미널을 열고 위의 명령어를 입력하면 시스템에 `docker-compose`가 설치되었는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers1.png)
+
+### Docker-Compose.yml(YAML)
+
+다음에 이야기할 것은 리포지토리의 컨테이너 폴더에서 찾을 수 있는 docker-compose.yml입니다. 그 전에, YAML에 대해 조금 설명하겠습니다.
+
+거의 모든 프로그래밍 언어에서 사용할 수 있는 YAML은 다양한 곳에서 사용될 수 있습니다.
+
+"YAML은 모든 프로그래밍 언어에 대한 인간 친화적인 데이터 직렬화 언어입니다."
+
+일반적으로 구성 파일과 데이터를 저장하거나 전송하는 일부 애플리케이션에서 사용됩니다. 동일한 구성 파일을 제공하는 경향이 있는 XML 파일을 접한 적이 있을 것입니다. YAML은 최소한의 구문을 제공하지만, 동일한 사용 사례를 목표로 합니다.
+
+YAML(YAML Ain't Markup Language)은 지난 몇 년 동안 꾸준히 인기가 높아진 직렬화 언어입니다. 객체 직렬화 기능 덕분에 JSON과 같은 언어를 대체할 수 있습니다.
+
+YAML의 약어는 Yet Another Markup Language의 약자였습니다. 그러나 유지 관리자는 데이터 지향적 기능을 더 강조하기 위해 YAML Ain't Markup Language로 이름을 변경했습니다.
+
+어쨌든, 다시 docker-compose.yml 파일로 돌아가겠습니다. 이 파일은 단일 시스템에 여러 개의 컨테이너를 배포할 때 수행하고자 하는 작업의 구성 파일입니다.
+
+위에 링크된 튜토리얼에서 바로 파일의 내용을 보면 다음과 같이 보입니다:
+
+```yaml
+version: '3.9'
+
+services:
+  DB:
+    image: mysql:5.7
+    volumes:
+      - db_data:/var/lib/mysql
+    restart: always
+    environment:
+      MYSQL_ROOT_PASSWORD: somewordpress
+      MYSQL_DATABASE: wordpress
+      MYSQL_USER: wordpress
+      MYSQL_PASSWORD: wordpress
+
+  wordpress:
+    depends_on:
+      - db
+    image: wordpress:latest
+    volumes:
+      - wordpress_data:/var/www/html
+    ports:
+      - '8000:80'
+    restart: always
+    environment:
+      WORDPRESS_DB_HOST: db
+      WORDPRESS_DB_USER: wordpress
+      WORDPRESS_DB_PASSWORD: wordpress
+      WORDPRESS_DB_NAME: wordpress
+volumes:
+  db_data: {}
+  wordpress_data: {}
+```
+
+버전을 선언한 다음, 이 docker-compose.yml 파일의 대부분은 서비스로 구성되어 있으며, DB 서비스와 워드프레스 서비스가 있습니다. 각 서비스에는 버전 태그가 연결된 이미지가 정의되어 있는 것을 볼 수 있습니다. 이제 첫 번째 연습과 달리 구성에 상태도 도입하고 있는데, 데이터베이스를 저장할 수 있도록 볼륨을 생성하겠습니다.
+
+그런 다음 비밀번호 및 사용자 이름과 같은 몇 가지 환경 변수가 있습니다. 이러한 파일은 매우 복잡해질 수 있지만 YAML 구성 파일을 사용하면 전체적으로 단순화할 수 있습니다.
+
+### 프로젝트 빌드
+
+이제 터미널로 돌아가서 docker-compose 도구로 몇 가지 명령을 사용할 수 있습니다. 디렉토리로 이동하여 docker-compose.yml 파일이 있는 디렉터리로 이동합니다.
+
+터미널에서 `docker-compose up -d`를 실행하면 해당 이미지를 가져와 멀티 컨테이너 애플리케이션을 세우는 프로세스가 시작됩니다.
+
+이 명령의 `-d`는 분리 모드를 의미하며, 이는 실행 명령이 백그라운드에서 실행 중이거나 실행될 것임을 의미합니다.
+
+![](/2022/Days/Images/Day46_Containers2.png)
+
+이제 `docker ps` 명령을 실행하면 2개의 컨테이너가 실행 중이며 하나는 WordPress이고 다른 하나는 MySQL인 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers3.png)
+
+다음으로 브라우저를 열고 `http://localhost:8000`으로 이동하면 WordPress가 실행 중인지 확인할 수 있으며, WordPress 설정 페이지가 표시됩니다.
+
+![](/2022/Days/Images/Day46_Containers4.png)
+
+워드프레스 설정을 완료한 다음 아래 콘솔에서 원하는 대로 웹사이트 구축을 시작할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers5.png)
+
+이제 새 탭을 열고 `http://localhost:8000` 이전과 동일한 주소로 이동하면 사이트 제목이 "90DaysOfDevOps"인 간단한 기본 테마가 표시되고 샘플 게시물이 표시됩니다.
+
+![](/2022/Days/Images/Day46_Containers6.png)
+
+변경하기 전에 Docker Desktop을 열고 볼륨 탭으로 이동하면 컨테이너와 연결된 두 개의 볼륨(하나는 워드프레스용, 다른 하나는 DB용)을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers7.png)
+
+현재 워드프레스 테마는 "Twenty Twenty-Two"이며 이를 "Twenty Twenty"로 변경하고 싶습니다. 대시보드로 돌아와서 변경할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers8.png)
+
+또한 사이트에 새 게시물을 추가하려고 하는데, 아래에서 새 사이트의 최신 버전을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers9.png)
+
+### 정리 여부
+
+이제 `docker-compose down` 명령을 사용하면 컨테이너가 삭제됩니다. 하지만 볼륨은 그대로 유지됩니다.
+
+![](/2022/Days/Images/Day46_Containers10.png)
+
+Docker Desktop에서 볼륨이 여전히 존재한다는 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers11.png)
+
+그런 다음 다시 백업하려면 동일한 디렉토리 내에서 `docker up -d` 명령을 실행하면 애플리케이션을 다시 백업하고 실행할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers12.png)
+
+그런 다음 브라우저에서 동일한 주소인 `http://localhost:8000`으로 이동하면 새 글과 테마 변경 사항이 모두 그대로 유지되는 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers13.png)
+
+컨테이너와 해당 볼륨을 제거하려면 `docker-compose down --volumes`를 실행하면 볼륨도 제거됩니다.
+
+![](/2022/Days/Images/Day46_Containers14.png)
+
+이제 `docker-compose up -d`를 다시 사용하면 시작하지만, 이미지는 여전히 우리 시스템의 로컬에 있으므로 Docker Hub 리포지토리에서 다시 가져올 필요가 없습니다.
+
+docker-compose와 그 기능에 대해 알아보기 시작했을 때 이것이 Kubernetes와 같은 컨테이너 오케스트레이션 도구와 어디에 위치하는지 혼란스러웠는데, 이 짧은 데모에서 우리가 한 모든 작업은 로컬 데스크톱 머신에서 실행 중인 WordPress와 DB가 있는 호스트 하나에 초점을 맞추고 있습니다. 여러 가상 머신이나 여러 물리적 머신이 없으며 애플리케이션의 요구 사항을 쉽게 확장 및 축소할 수도 없습니다.
+
+다음 섹션에서는 Kubernetes를 다룰 예정이지만, 먼저 컨테이너에 대한 전반적인 내용을 며칠 더 살펴보겠습니다.
+
+[Awesome-Compose](https://github.com/docker/awesome-compose)는 여러 통합이 있는 docker-compose 애플리케이션의 샘플을 위한 훌륭한 리소스입니다.
+
+위의 리포지토리에는 단일 노드에 Elasticsearch, Logstash, Kibana(ELK)를 배포하는 훌륭한 예제가 있습니다.
+
+[Containers 폴더](/2022/Days/Containers/elasticsearch-logstash-kibana/)에 파일을 업로드했습니다. 이 폴더가 로컬에 있으면 해당 폴더로 이동하여 `docker-compose up -d`를 사용하면 간단하게 설치할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers15.png)
+
+그런 다음 `docker ps`로 실행 중인 컨테이너가 있는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day46_Containers16.png)
+
+이제 각 컨테이너에 대한 브라우저를 열 수 있습니다:
+
+![](/2022/Days/Images/Day46_Containers17.png)
+
+모든 것을 제거하려면 `docker-compose down` 명령을 사용할 수 있습니다.
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
+- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
+- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
+
+[Day 47](day47.md)에서 봐요!
--- a/2022/ko/Days/day47.md
+++ b/2022/ko/Days/day47.md
@ -0,0 +1,139 @@
+---
+title: '#90DaysOfDevOps - Docker Networking & Security - Day 47'
+published: false
+description: 90DaysOfDevOps - Docker Networking & Security
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049078
+---
+
+## Docker 네트워킹 및 보안
+
+지금까지 컨테이너 세션에서 우리는 작업을 수행했지만, 네트워킹 관점에서 작업이 어떻게 작동했는지 살펴보지 않았으며 보안에 대해서도 다루지 않았습니다.
+
+### Docker 네트워킹 기본 사항
+
+터미널을 열고, 컨테이너 네트워크를 구성하고 관리하기 위한 기본 명령어인 `docker network` 명령을 입력합니다.
+
+아래에서 이 명령어를 사용하는 방법과 사용 가능한 모든 하위 명령을 확인할 수 있습니다. 새로운 네트워크를 생성하고, 기존 네트워크를 나열하고, 네트워크를 검사 및 제거할 수 있습니다.
+
+![](/2022/Days/Images/Day47_Containers1.png)
+
+설치 이후 우리가 가지고 있는 기존 네트워크를 살펴보기 위해 `docker network list` 명령을 사용하는 기본 Docker 네트워킹의 모습을 살펴봅시다.
+
+각 네트워크는 고유한 ID와 이름을 갖습니다. 각 네트워크는 또한 단일 드라이버와 연결됩니다. "bridge" 네트워크와 "host" 네트워크는 각각의 드라이버와 이름이 동일합니다.
+
+![](/2022/Days/Images/Day47_Containers2.png)
+
+다음으로 `docker network inspect` 명령으로 네트워크를 더 자세히 살펴볼 수 있습니다.
+
+`docker network inspect bridge`를 실행하면 특정 네트워크 이름에 대한 모든 구성 세부 정보를 얻을 수 있습니다. 여기에는 이름, ID, 드라이버, 연결된 컨테이너 등이 포함되며 보시다시피 훨씬 더 많은 정보를 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day47_Containers3.png)
+
+### Docker: bridge 네트워킹
+
+위에서 보았듯이 Docker Desktop을 표준 설치하면 `bridge`라는 사전 구축된 네트워크가 제공됩니다. `docker network list` 명령을 다시 실행하면 bridge라는 네트워크가 `bridge` 드라이버와 연결되어 있는 것을 볼 수 있습니다. 이름이 같다고 해서 같은 것은 아닙니다. 연결되었지만 같은 것은 아닙니다.
+
+위의 출력은 또한 bridge 네트워크가 로컬로 범위가 지정되었음을 보여줍니다. 이는 네트워크가 이 Docker host에만 존재한다는 것을 의미합니다. 이는 bridge 드라이버를 사용하는 모든 네트워크에 해당되며, bridge 드라이버는 단일 host 네트워킹을 제공합니다.
+
+bridge 드라이버로 생성된 모든 네트워크는 Linux bridge(virtual switch라고도 함)를 기반으로 합니다.
+
+### 컨테이너 연결
+
+기본적으로 bridge 네트워크는 새 컨테이너에 할당되므로 네트워크를 지정하지 않으면 모든 컨테이너가 bridge 네트워크에 연결됩니다.
+
+`docker run -dt ubuntu sleep infinity` 명령으로 새 컨테이너를 생성해 보겠습니다.
+
+위의 sleep 명령은 컨테이너를 백그라운드에서 계속 실행시켜서 컨테이너를 마음대로 다룰 수 있도록 합니다.
+
+![](/2022/Days/Images/Day47_Containers4.png)
+
+이제 `docker network inspect bridge`로 bridge 네트워크를 확인하면 네트워크를 지정하지 않았기 때문에 방금 배포한 것과 일치하는 컨테이너가 있는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day47_Containers5.png)
+
+`docker exec -it 3a99af449ca2 bash`를 사용하여 컨테이너를 자세히 살펴볼 수도 있습니다. 컨테이너 ID를 얻으려면 `docker ps`를 사용해야 합니다.
+
+여기에서 이미지에는 핑할 항목이 없으므로, `apt-get update && apt-get install -y iputils-ping`을 실행한 다음 외부 인터페이스 주소를 핑합니다. `ping -c5 www.90daysofdevops.com`
+
+![](/2022/Days/Images/Day47_Containers6.png)
+
+이 문제를 해결하기 위해 `docker stop 3a99af449ca2`를 다시 실행하고 `docker ps`를 사용하여 컨테이너 ID를 찾을 수 있지만, 이렇게 하면 컨테이너가 제거됩니다.
+
+### 외부 연결을 위한 NAT 구성하기
+
+이 단계에서는 새 NGINX 컨테이너를 시작하고 Docker host의 포트 8080을 컨테이너 내부의 포트 80으로 매핑합니다. 즉, 포트 8080의 Docker host에 도달하는 트래픽은 컨테이너 내부의 포트 80으로 전달됩니다.
+
+`docker run --name web1 -d -p 8080:80 nginx`를 실행하여 공식 NGINX 이미지를 기반으로 새 컨테이너를 시작합니다.
+
+![](/2022/Days/Images/Day47_Containers7.png)
+
+`docker ps`를 실행하여 컨테이너 상태와 포트 매핑을 검토합니다.
+
+![](/2022/Days/Images/Day47_Containers8.png)
+
+맨 위 줄은 NGINX를 실행하는 새 web1 컨테이너를 보여줍니다. 컨테이너가 실행 중인 명령과 포트 매핑에 주목하세요. - `0.0.0.0:8080->80/tcp`는 모든 host 인터페이스의 8080 포트를 web1 컨테이너 내부의 80 포트에 매핑합니다. 이 포트 매핑을 통해 외부 소스에서 컨테이너의 웹 서비스에 효과적으로 액세스할 수 있습니다(포트 8080의 Docker host IP 주소를 통해).
+
+이제 실제 host에 대한 IP 주소가 필요하며, WSL 터미널로 이동하여 `IP addr` 명령을 사용하여 이를 수행할 수 있습니다.
+
+![](/2022/Days/Images/Day47_Containers9.png)
+
+그런 다음, 이 IP를 가지고 브라우저를 열어 `http://172.25.218.154:8080/`로 이동하면 IP가 다를 수 있습니다. 이렇게 하면 NGINX에 액세스할 수 있음을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day47_Containers10.png)
+
+이 사이트의 이 지침은 2017년 DockerCon에서 가져온 것이지만 오늘날에도 여전히 유효합니다. 그러나 나머지 연습은 Docker Swarm에 대한 것이므로 여기서는 다루지 않겠습니다. [Docker 네트워킹 - DockerCon 2017](https://github.com/docker/labs/tree/master/dockercon-us-2017/docker-networking)
+
+### 컨테이너 보안
+
+컨테이너는 전체 서버 구성에 비해 워크로드에 안전한 환경을 제공합니다. 컨테이너는 애플리케이션을 서로 격리된 훨씬 더 작고 느슨하게 결합된 구성 요소로 분할할 수 있는 기능을 제공하므로 전체적으로 공격 표면을 줄이는 데 도움이 됩니다.
+
+하지만 시스템의 취약점을 공격하려는 해커로부터 자유롭지는 않습니다. 우리는 여전히 이 기술의 보안 결함을 이해하고 모범 사례를 유지해야 합니다.
+
+### 루트 권한에서 벗어나기
+
+지금까지 배포한 모든 컨테이너는 컨테이너 내 프로세스에 대한 루트 권한을 사용해 왔습니다. 즉, 컨테이너와 host 환경에 대한 모든 관리 액세스 권한이 있다는 뜻입니다. 이제 이러한 시스템이 오래 가동되지 않을 것이라는 것을 알고 있었습니다. 하지만 시작하고 실행하는 것이 얼마나 쉬운지 보셨을 것입니다.
+
+프로세스에 몇 단계를 추가하여 루트 사용자가 아닌 사용자가 선호하는 모범 사례를 사용할 수 있도록 할 수 있습니다. dockerfile을 만들 때 사용자 계정을 만들 수 있습니다. 이 예제는 리포지토리의 컨테이너 폴더에서도 찾을 수 있습니다.
+
+```dockerfile
+# 공식 Ubuntu 18.04를 기본으로 사용하세요.
+FROM ubuntu:18.04
+RUN apt-get update && apt-get upgrade -y
+RUN groupadd -g 1000 basicuser && useradd -r -u 1000 -g basicuser basicuser
+USER basicuser
+```
+
+`docker run --user 1009 ubuntu` 명령은 dockerfile에 지정된 모든 사용자를 재정의합니다. 따라서 다음 예제에서는 컨테이너가 항상 권한이 가장 낮은 사용자 식별자 1009로 실행되며 권한 수준도 가장 낮습니다.
+
+그러나 이 방법은 이미지 자체의 근본적인 보안 결함을 해결하지 못합니다. 따라서 컨테이너가 항상 안전하게 실행되도록 dockerfile에 루트 사용자가 아닌 사용자를 지정하는 것이 좋습니다.
+
+### 비공개 레지스트리
+
+조직에서 컨테이너 이미지의 비공개 레지스트리를 설정하면 원하는 곳에서 호스팅할 수 있거나 이를 위한 관리형 서비스도 있지만, 대체로 사용자와 팀이 사용할 수 있는 이미지를 완벽하게 제어할 수 있습니다.
+
+Docker Hub는 기준선을 제시하는 데는 훌륭하지만, 이미지 게시자를 많이 신뢰해야 하는 기본적인 서비스만 제공합니다.
+
+### 린 & 클린
+
+보안과 관련되지는 않았지만, 전체적으로 언급했습니다. 그러나 애플리케이션에서 사용하지 않는 리소스가 컨테이너에 필요하지 않은 경우 컨테이너의 크기는 공격 표면 측면에서 보안에 영향을 미칠 수 있습니다.
+
+또한 `latest` 이미지를 가져올 때 이미지에 많은 부풀림을 가져올 수 있기 때문에 이것이 저의 주요 관심사입니다. Docker Hub는 리포지토리에 있는 각 이미지의 압축 크기를 표시합니다.
+
+`docker image`를 확인하면 이미지의 크기를 확인할 수 있는 좋은 명령어입니다.
+
+![](/2022/Days/Images/Day47_Containers11.png)
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-/2022/Days/images/)
+- [Docker documentation for building an image](https://docs.docker.com/develop/develop-/2022/Days/images/dockerfile_best-practices/)
+- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
+
+[Day 48](day48.md)에서 봐요!
--- a/2022/ko/Days/day48.md
+++ b/2022/ko/Days/day48.md
@ -0,0 +1,115 @@
+---
+title: '#90DaysOfDevOps - Alternatives to Docker - Day 48'
+published: false
+description: 90DaysOfDevOps - Alternatives to Docker
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048807
+---
+
+## Docker의 대안
+
+이 섹션의 맨 처음에 Docker를 사용할 것이라고 말씀드린 이유는 단순히 리소스 측면에서 매우 많고 커뮤니티가 매우 크기 때문이기도 하지만, 컨테이너를 대중화하기 위한 시도가 바로 여기에서 시작되었기 때문입니다. Docker의 역사와 그 탄생 과정을 살펴보는 것이 매우 유용하다고 생각합니다.
+
+하지만 앞서 언급했듯이 Docker를 대체할 수 있는 다른 대안이 있습니다. Docker가 무엇이고 무엇을 다루었는지 생각해 보면 다음과 같습니다. 애플리케이션을 개발, 테스트, 배포 및 관리하기 위한 플랫폼입니다.
+
+앞으로 실제로 사용할 수 있거나 앞으로 사용할 수 있는 Docker의 몇 가지 대안을 강조하고 싶습니다.
+
+### Podman
+
+Podman이란? Podman은 리눅스 시스템에서 OCI 컨테이너를 개발, 관리, 실행하기 위한 데몬이 없는 컨테이너 엔진입니다. 컨테이너는 루트로 실행하거나 루트리스 모드로 실행할 수 있습니다.
+
+여기서는 Windows 관점에서 살펴볼 것이지만, Docker와 마찬가지로 Windows에서는 할 수 없는 기본 OS를 사용하기 때문에 가상화가 필요하지 않습니다.
+
+Podman은 WSL2에서도 실행할 수 있지만, Docker Desktop의 경험만큼 매끄럽지는 않습니다. 컨테이너가 실행될 Linux VM에 연결할 수 있는 Windows 원격 클라이언트도 있습니다.
+
+제가 사용하는 WSL2의 우분투는 20.04 릴리스입니다. 다음 단계에 따라 WSL 인스턴스에 Podman을 설치할 수 있습니다.
+
+```Shell
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/ /" |
+sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+```
+
+GPG 키를 추가합니다.
+
+```Shell
+curl -L "https://download.opensuse.org/repositories/devel:/kubic:\
+/libcontainers:/stable/xUbuntu_20.04/Release.key" | sudo apt-key add -
+```
+
+`sudo apt-get update && sudo apt-get upgrade`명령으로 시스템 업데이트 및 업그레이드를 실행합니다. 마지막으로`sudo apt install podman`을 사용하여 podman을 설치할 수 있습니다.
+
+이제 docker에 사용하던 것과 동일한 명령을 많이 사용할 수 있습니다. 다만 멋진 docker 데스크톱 UI가 없다는 점에 유의하세요. 아래에서 볼 수 있듯이 `podman images`를 사용했고 설치 후 아무것도 없으므로 `podman pull ubuntu`를 사용하여 우분투 컨테이너 이미지를 끌어 내렸습니다.
+
+![](/2022/Days/Images/Day48_Containers1.png)
+
+그런 다음 `podman run -dit ubuntu`와 `podman ps`를 사용하여 우분투 이미지를 실행하여 실행 중인 이미지를 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day48_Containers2.png)
+
+그런 다음 해당 컨테이너에 들어가기 위해 `podman attach dazzling_darwin`을 실행하면 컨테이너 이름이 달라질 수 있습니다.
+
+![](/2022/Days/Images/Day48_Containers3.png)
+
+docker에서 podman으로 이동하는 경우, 설정 파일에 `alias docker=podman`으로 변경하여 docker로 실행하는 모든 명령이 podman을 사용하도록 하는 것도 일반적입니다.
+
+### LXC
+
+LXC는 사용자가 다시 여러 개의 격리된 리눅스 컨테이너 환경을 생성할 수 있게 해주는 컨테이너화 엔진입니다. Docker와 달리, LXC는 별도의 시스템 파일과 네트워킹 기능을 갖춘 여러 리눅스 머신을 생성하기 위한 하이퍼바이저 역할을 합니다. docker보다 먼저 등장했다가 docker의 단점으로 인해 잠시 사용되었습니다.
+
+LXC는 docker만큼 가볍고 쉽게 배포할 수 있습니다.
+
+### Containerd
+
+독립형 컨테이너 런타임. Containerd는 단순성과 견고성은 물론 이식성까지 제공합니다. 이전에는 Docker 컨테이너 서비스의 일부로 실행되는 도구로 사용되다가 Docker가 구성 요소를 독립형 구성 요소로 분리하기로 결정하기 전까지 Containerd가 사용되었습니다.
+
+클라우드 네이티브 컴퓨팅 재단의 프로젝트로, Kubernetes, Prometheus, CoreDNS와 같은 인기 컨테이너 도구와 같은 부류에 속합니다.
+
+### 기타 Docker 도구
+
+Rancher와 VirtualBox와 관련된 도구와 옵션도 언급할 수 있지만 다음 기회에 더 자세히 다루겠습니다.
+
+[**Gradle**](https://gradle.org/)
+
+- 빌드 스캔을 통해 팀은 공동으로 스크립트를 디버깅하고 모든 빌드의 이력을 추적할 수 있습니다.
+- 실행 옵션을 통해 팀은 변경 사항이 입력될 때마다 작업이 자동으로 실행되도록 지속적으로 빌드할 수 있습니다.
+- 사용자 지정 리포지토리 레이아웃을 통해 팀은 모든 파일 디렉토리 구조를 아티팩트 리포지토리로 취급할 수 있습니다.
+
+[**Packer**](https://packer.io/)
+
+- 여러 머신 이미지를 병렬로 생성하여 개발자의 시간을 절약하고 효율성을 높일 수 있습니다.
+- 패커의 디버거를 사용하여 빌드를 쉽게 디버깅할 수 있어 실패를 검사하고 빌드를 다시 시작하기 전에 솔루션을 시험해 볼 수 있습니다.
+- 플러그인을 통해 다양한 플랫폼을 지원하므로 팀이 빌드를 커스터마이징할 수 있습니다.
+
+[**Logspout**](https://github.com/gliderlabs/logspout)
+
+- 로깅 도구 - 이 도구의 사용자 지정 기능을 통해 팀은 동일한 로그를 여러 대상에 전송할 수 있습니다.
+- 이 도구는 Docker 소켓에 액세스하기만 하면 되기 때문에 팀에서 파일을 쉽게 관리할 수 있습니다.
+- 완전히 오픈 소스이며 배포가 쉽습니다.
+
+[**Logstash**](https://www.elastic.co/products/logstash)
+
+- Logstash의 플러그형 프레임워크를 사용해 파이프라인을 사용자 정의하세요.
+- 분석을 위해 데이터를 쉽게 구문 분석하고 변환하여 비즈니스 가치를 제공할 수 있습니다.
+- Logstash의 다양한 출력을 통해 원하는 곳으로 데이터를 라우팅할 수 있습니다.
+
+[**Portainer**](https://www.portainer.io/)
+
+- 미리 만들어진 템플릿을 활용하거나 직접 템플릿을 만들어 애플리케이션을 배포하세요.
+- 팀을 생성하고 팀원에게 역할과 권한을 할당하세요.
+- 도구의 대시보드를 사용하여 각 환경에서 무엇이 실행되고 있는지 파악하세요.
+
+## 자료
+
+- [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)
+- [WSL 2 with Docker getting started](https://www.youtube.com/watch?v=5RQbdMn04Oc)
+- [Blog on getting started building a docker image](https://stackify.com/docker-build-a-beginners-guide-to-building-docker-images/)
+- [Docker documentation for building an image](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
+- [YAML Tutorial: Everything You Need to Get Started in Minute](https://www.cloudbees.com/blog/yaml-tutorial-everything-you-need-get-started)
+- [Podman | Daemonless Docker | Getting Started with Podman](https://www.youtube.com/watch?v=Za2BqzeZjBk)
+- [LXC - Guide to building an LXC Lab](https://www.youtube.com/watch?v=cqOtksmsxfg)
+
+[Day 49](day49.md)에서 봐요!
--- a/2022/ko/Days/day49.md
+++ b/2022/ko/Days/day49.md
@ -0,0 +1,235 @@
+---
+title: '#90DaysOfDevOps - The Big Picture: Kubernetes - Day 49'
+published: false
+description: 90DaysOfDevOps - The Big Picture Kubernetes
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049049
+---
+
+## 큰 그림: Kubernetes
+
+지난 섹션에서 컨테이너에 대해 살펴보았는데, 컨테이너는 scale과 오케스트레이션만으로는 부족합니다. 우리가 할 수 있는 최선은 docker-compose를 사용하여 여러 컨테이너를 함께 불러오는 것입니다. 컨테이너 오케스트레이터인 Kubernetes를 사용하면 애플리케이션과 서비스의 부하에 따라 자동화된 방식으로 확장 및 축소할 수 있습니다.
+
+플랫폼으로서 Kubernetes는 요구사항과 원하는 상태에 따라 컨테이너를 오케스트레이션할 수 있는 기능을 제공합니다. 이 섹션에서는 차세대 인프라로 빠르게 성장하고 있는 Kubernetes에 대해 다룰 예정입니다. 또한 데브옵스 관점에서 볼 때 Kubernetes는 기본적인 이해가 필요한 하나의 플랫폼일 뿐이며, 베어메탈, 가상화 및 대부분의 클라우드 기반 서비스도 이해해야 합니다. Kubernetes는 애플리케이션을 실행하기 위한 또 다른 옵션일 뿐입니다.
+
+### 컨테이너 오케스트레이션이란 무엇인가요?
+
+앞서 Kubernetes와 컨테이너 오케스트레이션에 대해 언급했는데, Kubernetes는 기술인 반면 컨테이너 오케스트레이션은 기술 이면의 개념 또는 프로세스입니다. 컨테이너 오케스트레이션 플랫폼은 Kubernetes뿐만 아니라 Docker Swarm, HashiCorp Nomad 등도 있습니다. 하지만 Kubernetes가 점점 더 강세를 보이고 있기 때문에 Kubernetes를 다루고 싶지만, Kubernetes만이 유일한 것은 아니라는 점을 말씀드리고 싶었습니다.
+
+### Kubernetes란 무엇인가요?
+
+Kubernetes를 처음 접하는 경우 가장 먼저 읽어야 할 것은 공식 문서입니다. 1년 조금 전에 Kubernetes에 대해 깊이 파고든 제 경험에 따르면 학습 곡선이 가파르게 진행될 것입니다. 가상화 및 스토리지에 대한 배경지식이 있는 저는 이것이 얼마나 벅차게 느껴질지 생각했습니다.
+
+하지만 커뮤니티, 무료 학습 리소스 및 문서는 놀랍습니다. [Kubernetes.io](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
+
+Kubernetes는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식 가능하고 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 용이하게 합니다. 빠르게 성장하는 대규모 에코시스템이 있습니다. Kubernetes 서비스, 지원, 도구는 널리 이용 가능합니다.
+
+위의 인용문에서 주목해야 할 중요한 점은 Kubernetes는 클라우드 네이티브 컴퓨팅 재단(CNCF)에 프로젝트를 기부한 Google로 거슬러 올라가는 풍부한 역사를 가진 오픈소스이며, 현재 오픈소스 커뮤니티와 대기업 벤더가 오늘날의 Kubernetes를 만드는 데 기여하면서 발전해 왔다는 점입니다.
+
+위에서 컨테이너가 훌륭하다고 말씀드렸고 이전 섹션에서는 컨테이너와 컨테이너 이미지가 어떻게 클라우드 네이티브 시스템의 채택을 변화시키고 가속화했는지에 대해 이야기했습니다. 하지만 컨테이너만으로는 애플리케이션에 필요한 프로덕션 지원 환경을 제공할 수 없습니다. Kubernetes는 다음과 같은 이점을 제공합니다:
+
+- **Services discovery 및 로드 밸런싱** Kubernetes는 DNS 이름 또는 IP 주소를 사용하여 컨테이너를 노출할 수 있습니다. 컨테이너에 대한 트래픽이 많을 경우, Kubernetes는 네트워크 트래픽을 로드 밸런싱하고 분산하여 배포가 안정적으로 이루어지도록 할 수 있습니다.
+
+- **스토리지 오케스트레이션** Kubernetes를 사용하면 로컬 스토리지, 퍼블릭 클라우드 제공자 등 원하는 스토리지 시스템을 자동으로 마운트할 수 있습니다.
+
+- **자동화된 롤아웃 및 롤백** 배포된 컨테이너에 대해 원하는 상태를 설명할 수 있으며, 제어된 속도로 실제 상태를 원하는 상태로 변경할 수 있습니다. 예를 들어, 배포를 위한 새 컨테이너를 생성하고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용하도록 Kubernetes를 자동화할 수 있습니다.
+
+- **자동 bin 패킹** 컨테이너화된 작업을 실행하는 데 사용할 수 있는 노드 클러스터를 Kubernetes에 제공하고, 각 컨테이너에 필요한 CPU와 메모리(RAM)의 양을 Kubernetes에 알려줍니다. Kubernetes는 리소스를 최대한 활용하기 위해 컨테이너를 노드에 맞출 수 있습니다.
+
+- **자가 복구** Kubernetes는 장애가 발생한 컨테이너를 다시 시작하고, 컨테이너를 교체하고, 사용자 정의 상태 확인에 응답하지 않는 컨테이너를 죽이고, 제공할 준비가 될 때까지 클라이언트에게 알리지 않습니다.
+
+- **비밀 및 구성 관리** Kubernetes를 사용하면 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하고 관리할 수 있습니다. 컨테이너 이미지를 다시 빌드하거나 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포하고 업데이트할 수 있습니다.
+
+Kubernetes는 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공합니다.
+
+컨테이너 오케스트레이션은 컨테이너의 배포, 배치 및 라이프사이클을 관리합니다.
+
+또한 다른 많은 책임도 있습니다:
+
+- 클러스터 관리는 호스트를 하나의 대상으로 묶습니다.
+
+- 스케줄 관리는 스케줄러를 통해 컨테이너를 노드 간에 배포합니다.
+
+- Services discovery은 컨테이너의 위치를 파악하고 클라이언트 요청을 컨테이너에 분산합니다.
+
+- 복제는 요청된 워크로드에 적합한 수의 노드와 컨테이너를 사용할 수 있도록 보장합니다.
+
+- 상태 관리는 건강하지 않은 컨테이너와 노드를 감지하고 교체합니다.
+
+### 주요 Kubernetes 구성 요소
+
+Kubernetes는 애플리케이션을 프로비저닝, 관리 및 확장하기 위한 컨테이너 오케스트레이터입니다. 이를 사용하여 VM 또는 물리적 머신과 같은 워커 머신의 모음인 노드 클러스터에서 컨테이너화된 앱의 라이프사이클을 관리할 수 있습니다.
+
+앱을 실행하려면 데이터베이스 연결, 방화벽 백엔드와의 통신, 키 보안에 도움이 되는 볼륨, 네트워크, 시크릿 등 다른 많은 리소스가 필요할 수 있습니다. Kubernetes를 사용하면 이러한 리소스를 앱에 추가할 수 있습니다. 앱에 필요한 인프라 리소스는 선언적으로 관리됩니다.
+
+Kubernetes의 핵심 패러다임은 선언적 모델입니다. 사용자가 원하는 상태를 제공하면 Kubernetes가 이를 실현합니다. 인스턴스 다섯 개가 필요한 경우, 사용자가 직접 다섯 개의 인스턴스를 시작하지 않습니다. 대신 인스턴스 5개가 필요하다고 Kubernetes에 알려주면 Kubernetes가 자동으로 상태를 조정합니다. 인스턴스 중 하나에 문제가 발생하여 실패하더라도 Kubernetes는 여전히 사용자가 원하는 상태를 파악하고 사용 가능한 노드에 인스턴스를 생성합니다.
+
+### 노드
+
+#### 컨트롤 플레인
+
+모든 Kubernetes 클러스터에는 컨트롤 플레인 노드가 필요하며, 컨트롤 플레인의 구성 요소는 클러스터에 대한 전역 결정(예: 스케줄링)을 내리고 클러스터 이벤트를 감지 및 응답합니다.
+
+![](/2022/Days/Images/Day49_Kubernetes1.png)
+
+#### 워커 노드
+
+Kubernetes 워크로드를 실행하는 워커 머신입니다. 물리적(베어메탈) 머신이거나 가상 머신(VM)일 수 있습니다. 각 노드는 하나 이상의 pod를 호스트할 수 있습니다. Kubernetes 노드는 컨트롤 플레인에 의해 관리됩니다.
+
+![](/2022/Days/Images/Day49_Kubernetes2.png)
+
+다른 노드 유형이 있지만 여기서는 다루지 않겠습니다.
+
+#### kubelet
+
+클러스터의 각 노드에서 실행되는 에이전트입니다. 컨테이너가 pod에서 실행되고 있는지 확인합니다.
+
+kubelet은 다양한 메커니즘을 통해 제공되는 일련의 PodSpec을 가져와서 해당 PodSpec에 설명된 컨테이너가 실행 중이고 정상인지 확인합니다. kubelet은 Kubernetes가 생성하지 않은 컨테이너는 관리하지 않습니다.
+
+![](/2022/Days/Images/Day49_Kubernetes3.png)
+
+#### kube-proxy
+
+kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, Kubernetes Services 개념의 일부를 구현합니다.
+
+kube-proxy는 노드에서 네트워크 규칙을 유지 관리합니다. 이러한 네트워크 규칙은 클러스터 내부 또는 외부의 네트워크 세션에서 pod로의 네트워크 통신을 허용합니다.
+
+운영 체제 패킷 필터링 계층이 있고 사용 가능한 경우, kube-proxy는 이를 사용합니다. 그렇지 않으면, kube-proxy는 트래픽 자체를 전달합니다.
+
+![](/2022/Days/Images/Day49_Kubernetes4.png)
+
+#### 컨테이너 런타임
+
+컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어입니다.
+
+Kubernetes는 여러 컨테이너 런타임을 지원합니다: docker, containerd, CRI-O 그리고 Kubernetes CRI(Container Runtime Interface)의 모든 구현
+
+![](/2022/Days/Images/Day49_Kubernetes5.png)
+
+### 클러스터
+
+클러스터는 노드의 그룹으로, 노드는 물리적 머신 또는 가상 머신이 될 수 있습니다. 각 노드에는 컨테이너 런타임(Docker)이 있으며 마스터 컨트롤러(나중에 자세히 설명)의 명령을 받는 에이전트인 kubelet 서비스와 다른 구성 요소(나중에 자세히 설명)에서 pod에 대한 연결을 프록시하는 데 사용되는 프록시도 실행됩니다.
+
+고가용성으로 만들 수 있는 컨트롤 플레인에는 워커 노드와 비교하여 몇 가지 고유한 역할이 포함되며, 가장 중요한 것은 정보를 가져오거나 Kubernetes 클러스터로 정보를 푸시하기 위한 모든 통신이 이루어지는 곳인 kube API 서버입니다.
+
+#### Kube API 서버
+
+Kubernetes API 서버는 pod, 서비스, 응답 컨트롤러 등을 포함하는 API 오브젝트에 대한 데이터의 유효성을 검사하고 구성합니다. API 서버는 REST 작업을 수행하고 다른 모든 구성 요소가 상호 작용하는 클러스터의 공유 상태에 대한 프론트엔드를 제공합니다.
+
+#### 스케줄러
+
+Kubernetes 스케줄러는 노드에 pod를 할당하는 컨트롤 플레인 프로세스입니다. 스케줄러는 제약 조건과 사용 가능한 리소스에 따라 스케줄링 대기열에서 각 pod에 대해 유효한 배치가 되는 노드를 결정합니다. 그런 다음 스케줄러는 각 유효한 노드의 순위를 매기고 pod를 적합한 노드에 바인딩합니다.
+
+#### 컨트롤러 매니저
+
+Kubernetes 컨트롤러 매니저는 Kubernetes와 함께 제공되는 핵심 제어 루프를 임베드하는 daemon입니다. 로보틱스 및 자동화 애플리케이션에서 제어 루프는 시스템 상태를 조절하는 비종료 루프입니다. Kubernetes에서 컨트롤러는 API 서버를 통해 클러스터의 공유 상태를 감시하고 현재 상태를 원하는 상태로 이동시키기 위해 변경을 시도하는 제어 루프입니다.
+
+#### etcd
+
+모든 클러스터 데이터에 대한 Kubernetes의 백업 저장소로 사용되는 일관되고 가용성이 높은 키 값 저장소입니다.
+
+![](/2022/Days/Images/Day49_Kubernetes6.png)
+
+#### kubectl
+
+CLI 관점에서 이를 관리하기 위해 kubectl이 있으며, kubectl은 API 서버와 상호 작용합니다.
+
+Kubernetes 커맨드-라인 도구인 kubectl을 사용하면 Kubernetes 클러스터에 대해 명령을 실행할 수 있습니다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고, 로그를 볼 수 있습니다.
+
+![](/2022/Days/Images/Day49_Kubernetes7.png)
+
+### Pods
+
+pod는 논리적 애플리케이션을 구성하는 컨테이너 그룹입니다. 예를 들어, NodeJS 컨테이너와 MySQL 컨테이너를 실행하는 웹 애플리케이션이 있는 경우, 이 두 컨테이너는 모두 단일 pod에 위치하게 됩니다. 또한 pod는 공통 데이터 볼륨을 공유할 수 있으며 동일한 네트워킹 네임스페이스도 공유합니다. pod는 임시적이며 마스터 컨트롤러에 의해 위아래로 이동될 수 있다는 것을 기억합시다. Kubernetes는 레이블(이름-값) 개념을 통해 pod를 식별하는 간단하지만, 효과적인 수단을 사용합니다.
+
+- pod는 컨테이너의 볼륨, 시크릿 및 구성을 처리합니다.
+
+- pod는 임시적입니다. 죽으면 자동으로 재시작되도록 설계되었습니다.
+
+- pod는 ReplicationSet에 의해 앱이 수평으로 스케일 될 때 복사됩니다. 각 pod는 동일한 컨테이너 코드를 실행합니다.
+
+- pod는 워커 노드에서 실행됩니다.
+
+![](/2022/Days/Images/Day49_Kubernetes8.png)
+
+### Deployments
+
+- pod를 실행하기로 결정할 수 있지만 죽으면 끝입니다.
+
+- Deployments를 사용하면 pod가 지속적으로 실행될 수 있습니다.
+
+- Deployments를 사용하면 다운타임 없이 실행 중인 앱을 업데이트할 수 있습니다.
+
+- 또한, Deployments는 pod가 죽었을 때 재시작하는 전략을 지정합니다.
+
+![](/2022/Days/Images/Day49_Kubernetes9.png)
+
+### ReplicaSets
+
+- Deployments는 ReplicaSets을 생성할 수도 있습니다.
+
+- ReplicaSets은 앱이 원하는 수의 pod를 갖도록 보장합니다.
+
+- ReplicaSets은 Deployments에 따라 pod를 생성하고 확장합니다.
+
+- Deployments, ReplicaSets, pod는 배타적이지는 않지만 그렇게 될 수 있습니다.
+
+### StatefulSets
+
+- 앱의 상태에 대한 정보를 유지해야 하나요?
+
+- 데이터베이스에는 상태가 필요합니다.
+
+- StatefulSets의 pod는 서로 호환되지 않습니다.
+
+- 각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있습니다.
+
+![](/2022/Days/Images/Day49_Kubernetes10.png)
+
+### DaemonSets
+
+- DaemonSets은 연속 프로세스를 위한 것입니다.
+
+- 노드당 하나의 pod를 실행합니다.
+
+- 클러스터에 새로운 노드가 추가될 때마다 pod가 시작됩니다.
+
+- 모니터링 및 로그 수집과 같은 백그라운드 작업에 유용합니다.
+
+- 각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있습니다.
+
+![](/2022/Days/Images/Day49_Kubernetes11.png)
+
+### Services
+
+- pod에 액세스하기 위한 단일 엔드포인트입니다.
+
+- 클러스터와 최종적으로 pod 목록으로 트래픽을 라우팅하는 통합된 방법입니다.
+
+- Services를 사용하면 아무 영향 없이 pod를 올리고 내릴 수 있습니다.
+
+이것은 Kubernetes의 기본 구성 요소에 대한 간략한 개요와 참고 사항일 뿐이며, 이 지식을 바탕으로 스토리지와 Ingress 관련 몇 가지 다른 영역을 추가하여 애플리케이션을 개선할 수 있지만, Kubernetes 클러스터가 실행되는 위치에 대한 선택의 폭도 넓어집니다. 다음 세션에서는 스토리지와 관련된 몇 가지 세부 사항을 살펴보면서 Kubernetes 클러스터를 실행할 수 있는 위치에 대한 이러한 옵션에 중점을 두겠습니다.
+
+![](/2022/Days/Images/Day49_Kubernetes12.png)
+
+### Kubernetes 시리즈에서 다룰 내용
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+[Day 50](day50.md)에서 봐요!
--- a/2022/ko/Days/day50.md
+++ b/2022/ko/Days/day50.md
@ -0,0 +1,79 @@
+---
+title: '#90DaysOfDevOps - Choosing your Kubernetes platform - Day 50'
+published: false
+description: 90DaysOfDevOps - Choosing your Kubernetes platform
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049046
+---
+
+## Kubernetes 플랫폼 선택하기
+
+이 세션을 통해 몇 가지 플랫폼 또는 배포판이라는 용어를 사용하는 것이 더 적합할 수도 있는데, Kubernetes 세계에서 도전 과제 중 하나는 복잡성을 제거하는 것입니다.
+
+Kubernetes 어려운 길은 아무것도 없는 상태에서 완전한 기능을 갖춘 Kubernetes 클러스터로 구축하는 방법을 안내하지만, 적어도 제가 이야기하는 사람들은 점점 더 많은 사람들이 이러한 복잡성을 제거하고 관리형 Kubernetes 클러스터를 실행하기를 원하고 있습니다. 문제는 비용이 더 많이 들지만, 관리형 서비스를 사용하면 기본 노드 아키텍처와 컨트롤 플레인 노드 관점에서 무슨 일이 일어나고 있는지 알아야 하지만 일반적으로 이에 액세스할 수 없는 경우 이점을 누릴 수 있다는 것입니다.
+
+그런 다음 시스템을 사용할 수 있는 로컬 개발 배포판이 있고, 개발자가 의도한 플랫폼에서 앱을 실행할 수 있는 완전한 작업 환경을 갖출 수 있도록 로컬 버전의 Kubernetes를 실행할 수 있습니다.
+
+이 모든 개념의 일반적인 기본은 모두 Kubernetes의 한 종류이므로 요구 사항에 맞게 워크로드를 필요한 곳으로 자유롭게 마이그레이션하고 이동할 수 있어야 한다는 것입니다.
+
+또한 어떤 투자가 이루어졌는지에 따라 많은 선택이 달라질 것입니다. 개발자 경험에 대해서도 언급했지만, 노트북에서 실행되는 로컬 Kubernetes 환경 중 일부는 비용을 들이지 않고도 기술을 익힐 수 있는 훌륭한 환경입니다.
+
+### 베어 메탈 클러스터
+
+많은 사람들이 클러스터를 생성하기 위해 여러 대의 물리적 서버에서 바로 Linux OS를 실행하는 옵션을 선택할 수 있으며, Windows일 수도 있지만 Windows, 컨테이너 및 Kubernetes와 관련된 채택률에 대해서는 많이 듣지 못했습니다. 만약 여러분이 기업이고 물리적 서버를 구매하기로 CAPEX 결정을 내렸다면, Kubernetes 클러스터를 구축할 때 이 방법을 사용할 수 있지만, 관리 및 관리자 측면에서는 여러분이 직접 구축하고 모든 것을 처음부터 관리해야 한다는 것을 의미합니다.
+
+### 가상화
+
+테스트 및 학습 환경이나 엔터프라이즈급 Kubernetes 클러스터에 관계없이 가상화는 일반적으로 가상 머신을 스핀업하여 노드 역할을 하도록 한 다음 함께 클러스터링할 수 있는 훌륭한 방법입니다. 가상화의 기본 아키텍처, 효율성 및 속도를 활용할 수 있을 뿐만 아니라 기존 지출을 활용할 수 있습니다. 예를 들어 VMware는 가상 머신과 Kubernetes 모두를 위한 훌륭한 솔루션을 다양한 형태로 제공합니다.
+
+제가 처음으로 구축한 Kubernetes 클러스터는 몇 개의 VM을 노드로 실행할 수 있는 오래된 서버에서 Microsoft Hyper-V를 사용한 가상화를 기반으로 구축되었습니다.
+
+### 로컬 데스크톱 옵션
+
+데스크톱이나 노트북에서 로컬 Kubernetes 클러스터를 실행하는 데는 몇 가지 옵션이 있습니다. 앞서 말했듯이 개발자는 비용이 많이 들거나 복잡한 클러스터를 여러 개 보유하지 않고도 앱이 어떻게 보일지 확인할 수 있습니다. 개인적으로 저는 이 클러스터를 많이 사용해 왔으며 특히 Minikube를 사용해 왔습니다. 여기에는 무언가를 시작하고 실행하는 방식을 바꾸는 몇 가지 훌륭한 기능과 애드온이 있습니다.
+
+### Kubernetes Managed Services
+
+가상화에 대해 언급했는데, 이는 로컬에서 하이퍼바이저를 통해 달성할 수 있지만 이전 섹션에서 퍼블릭 클라우드의 가상 머신을 활용하여 노드 역할을 할 수도 있다는 것을 알고 있습니다. 여기서 말하는 Kubernetes 관리형 서비스란 대규모 하이퍼스케일러뿐만 아니라 최종 사용자로부터 관리 및 제어 계층을 제거하여 최종 사용자로부터 제어 플레인을 제거하는 MSP에서 제공하는 서비스를 말하며, 이는 Amazon EKS, Microsoft AKS 및 Google Kubernetes Engine에서 일어나는 일입니다. (GKE)
+
+### 압도적인 선택
+
+선택의 폭이 넓다는 것은 좋지만, 위에 나열된 각 카테고리의 모든 옵션에 대해 자세히 살펴본 것은 아닙니다. 위의 옵션 외에도 Red Hat의 OpenShift가 있으며, 이 옵션은 위의 모든 주요 클라우드 제공업체에서 실행할 수 있으며 클러스터가 배포된 위치에 관계없이 관리자에게 최고의 전반적인 사용성을 제공할 수 있습니다.
+
+제가 가상화 경로로 시작했다고 말씀드렸지만, 이는 제가 목적에 맞게 사용할 수 있는 물리적 서버에 액세스할 수 있었기 때문에 감사하게도 그 이후로는 더 이상 이 옵션을 사용할 수 없었습니다.
+
+지금 제가 드리고 싶은 조언은 Minikube를 첫 번째 옵션으로 사용하거나 Kind(Docker의 Kubernetes)를 사용하라는 것이지만, Minikube는 애드온을 사용하고 빠르게 구축한 다음 완료되면 날려버릴 수 있고, 여러 클러스터를 실행할 수 있으며, 거의 모든 곳에서 실행할 수 있고, 크로스 플랫폼 및 하드웨어에 구애받지 않기 때문에 복잡성을 거의 추상화할 수 있는 몇 가지 추가적인 이점을 제공합니다.
+
+저는 Kubernetes에 대해 배우면서 약간의 여정을 거쳤기 때문에 플랫폼 선택과 구체적인 내용은 여기서는 플랫폼인 Kubernetes와 실행 가능한 위치에 대한 이해를 돕기 위해 시도했던 옵션들을 나열해 보겠습니다. 아래 블로그 포스팅을 다시 한번 살펴보고 블로그 게시물에 링크되어 있는 것보다 여기에 더 많이 소개할 수 있도록 하겠습니다.
+
+- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
+- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
+- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
+- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
+- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
+- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
+- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
+- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
+- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
+
+### Kubernetes 시리즈에서 다룰 내용
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+[Day 51](day51.md)에서 봐요!
--- a/2022/ko/Days/day51.md
+++ b/2022/ko/Days/day51.md
@ -0,0 +1,178 @@
+---
+title: '#90DaysOfDevOps - Deploying your first Kubernetes Cluster - Day 51'
+published: false
+description: 90DaysOfDevOps - Deploying your first Kubernetes Cluster
+tags: 'DevOps, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048778
+---
+
+## 첫 번째 Kubernetes 클러스터 배포하기
+
+이 글에서는 Minikube를 사용하여 로컬 머신에서 Kubernetes 클러스터를 시작하고 실행해 보겠습니다. 이렇게 하면 나머지 Kubernetes 섹션을 위한 기본 Kubernetes 클러스터가 제공되지만, 나중에 VirtualBox에서도 Kubernetes 클러스터를 배포하는 방법을 살펴볼 것입니다. 퍼블릭 클라우드에서 관리형 Kubernetes 클러스터를 스핀업하는 대신 이 방법을 선택한 이유는 무료 티어를 사용하더라도 비용이 들기 때문이며, 이전 섹션 [Day 50](day50.md)에서 해당 환경을 스핀업하려는 경우 몇 가지 블로그를 공유한 바 있습니다.
+
+### Minikube란?
+
+> "Minikube는 macOS, Linux, Windows에서 로컬 Kubernetes 클러스터를 빠르게 설정합니다. 우리는 애플리케이션 개발자와 새로운 Kubernetes 사용자를 돕는 데 주력하고 있습니다."
+
+위에 해당되지 않을 수도 있지만, 저는 Minikube가 Kubernetes 방식으로 무언가를 테스트하고 싶을 때 앱을 쉽게 배포할 수 있고 몇 가지 놀라운 애드온이 있다는 것을 알게 되었으며, 이 글에서도 다룰 것입니다.
+
+우선, 워크스테이션 OS에 관계없이 Minikube를 실행할 수 있습니다. 먼저 [프로젝트 페이지](https://minikube.sigs.k8s.io/docs/start/)로 이동합니다. 첫 번째 옵션은 설치 방법을 선택하는 것입니다. 저는 이 방법을 사용하지 않았지만, 여러분은 제가 사용하는 방법과 다른 방법을 선택할 수 있습니다(곧 소개할 예정입니다).
+
+아래에 언급된 "Container or virtual machine managers, such as Docker, Hyper kit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware"가 있어야 한다고 명시되어 있는데, 이것이 Minikube가 실행되는 곳이고 쉬운 옵션이며 저장소에 명시되어 있지 않은 한 저는 Docker를 사용하고 있습니다. 그리고 [여기](https://docs.docker.com/get-docker/)에서 시스템에 Docker를 설치할 수 있습니다.
+
+![](/2022/Days/Images/Day51_Kubernetes1.png)
+
+### Minikube 및 기타 전제조건을 설치하는 방법...
+
+저는 한동안 arkade를 사용하여 모든 Kubernetes 도구와 CLI를 설치해왔는데, arkade를 시작하기 위한 설치 단계는 이 [github 저장소](https://github.com/alexellis/arkade)에서 확인할 수 있습니다. 설치가 필요한 다른 블로그 게시물에서도 언급했습니다. arkade get을 누른 다음 툴이나 CLI를 사용할 수 있는지 확인하는 것만으로도 간단합니다. 리눅스 섹션에서 패키지 관리자와 소프트웨어를 얻는 프로세스에 대해 이야기했는데, arkade는 모든 앱과 Kubernetes용 CLI를 위한 마켓플레이스라고 생각하시면 됩니다. 시스템에서 사용할 수 있는 매우 편리한 작은 도구로, GO로 작성되어 크로스 플랫폼을 지원합니다.
+
+![](/2022/Days/Images/Day51_Kubernetes2.png)
+
+arkade 내에서 사용 가능한 긴 앱 목록의 일부로 Minikube도 그중 하나이므로 간단한 `arkade get minikube` 명령으로 바이너리를 다운로드하고 이제 바로 사용할 수 있습니다.
+
+![](/2022/Days/Images/Day51_Kubernetes3.png)
+
+또한 도구의 일부로 kubectl이 필요하므로 arkade를 통해서도 얻을 수 있으며, 위에서 언급한 curl 명령의 일부로 Minikube 문서에 나와 있다고 생각합니다. 이 포스트의 뒷부분에서 kubectl에 대해 더 자세히 다루겠습니다.
+
+### Kubernetes 클러스터 시작 및 실행하기
+
+이 특정 섹션에서는 로컬 머신에서 Kubernetes 클러스터를 시작하고 실행할 때 사용할 수 있는 옵션에 대해 다루고자 합니다. 다음 명령을 실행하기만 하면 사용할 수 있는 클러스터가 스핀업됩니다.
+
+커맨드라인에 minikube가 사용되며, 모든 설치가 완료되면 `minikube start`를 실행하여 첫 번째 Kubernetes 클러스터를 배포할 수 있습니다. 아래에서 중첩된 가상화 노드를 실행할 위치에 대한 기본값이 Docker 드라이버인 것을 확인할 수 있습니다. 게시물의 시작 부분에서 사용 가능한 다른 옵션에 대해 언급했는데, 다른 옵션은 이 로컬 Kubernetes 클러스터의 모양을 확장하고자 할 때 도움이 됩니다.
+
+이 인스턴스에서는 단일 Minikube 클러스터가 단일 docker 컨테이너로 구성되며, 이 컨테이너에는 컨트롤 플레인 노드와 워커 노드가 하나의 인스턴스에 포함됩니다. 일반적으로는 이러한 노드를 분리합니다. 다음 섹션에서는 아직 홈 랩 유형의 Kubernetes 환경이지만 프로덕션 아키텍처에 조금 더 가까운 환경을 살펴볼 것입니다.
+
+![](/2022/Days/Images/Day51_Kubernetes4.png)
+
+지금까지 몇 번 언급했지만, 저는 사용 가능한 애드온 때문에 Minikube를 좋아하는데, 처음부터 필요한 모든 애드온을 포함한 간단한 명령으로 클러스터를 배포할 수 있기 때문에 매번 동일한 설정을 배포하는 데 도움이 됩니다.
+
+아래에서 이러한 애드온 목록을 볼 수 있는데, 저는 일반적으로 `CSI-host path-driver`와 `volumesnapshots` 애드온을 사용하지만, 아래에서 긴 목록을 볼 수 있습니다. 물론 이러한 애드온은 나중에 Kubernetes 섹션에서 다루겠지만 일반적으로 Helm을 사용하여 배포할 수 있지만 훨씬 더 간단해진다.
+
+![](/2022/Days/Images/Day51_Kubernetes5.png)
+
+또한 프로젝트에서 몇 가지 추가 구성을 정의하고 있는데, apiserver는 임의의 API 포트 대신 6433으로 설정하고 container runtime도 containerd로 정의하고 있지만 기본값은 docker이고 CRI-O도 사용할 수 있습니다. 또한 특정 Kubernetes 버전도 설정하고 있습니다.
+
+![](/2022/Days/Images/Day51_Kubernetes6.png)
+
+이제 Minikube를 사용하여 첫 번째 Kubernetes 클러스터를 배포할 준비가 되었습니다. 클러스터와 상호 작용하려면 `kubectl`도 필요하다고 앞서 언급했습니다. arkade를 사용하여 `arkade get kubectl` 명령으로 kubectl을 설치할 수 있습니다.
+
+![](/2022/Days/Images/Day51_Kubernetes7.png)
+
+또는 다음에서 크로스 플랫폼으로 다운로드할 수 있습니다.
+
+- [리눅스](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux)
+- [macOS](https://kubernetes.io/docs/tasks/tools/install-kubectl-macos)
+- [윈도우](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows)
+
+kubectl을 설치했으면 `kubectl get nodes`와 같은 간단한 명령으로 클러스터와 상호 작용할 수 있습니다.
+
+![](/2022/Days/Images/Day51_Kubernetes8.png)
+
+### kubectl이란?
+
+이제 Minikube와 Kubernetes 클러스터를 모두 설치하고 실행 중이며, Minikube에 대해서는 최소한 Minikube가 무엇을 하는지에 대해 설명했지만, kubectl이 무엇이고 어떤 역할을 하는지에 대해서는 설명하지 않았습니다.
+
+kubectl은 Kubernetes 클러스터와 상호 작용하는 데 사용되거나 상호 작용할 수 있게 해주는 클리어로, 여기서는 Minikube 클러스터와 상호 작용하는 데 사용하고 있지만 퍼블릭 클라우드 전반의 엔터프라이즈 클러스터와 상호 작용하는 데도 kubectl을 사용할 수 있습니다.
+
+우리는 애플리케이션을 배포하고 클러스터 리소스를 검사 및 관리하기 위해 kubectl을 사용합니다. 훨씬 더 자세한 개요는 Kubernetes [공식 문서](https://kubernetes.io/docs/reference/kubectl/overview/)에서 확인할 수 있습니다.
+
+kubectl은 이전 포스트에서 간략하게 다룬 컨트롤 플레인 노드에 있는 API 서버와 상호작용합니다.
+
+### kubectl 치트 시트
+
+공식 문서와 함께, 필자는 kubectl 명령어를 찾을 때 [이 페이지](https://unofficial-kubernetes.readthedocs.io/en/latest/)를 항상 열어두는 것을 추천합니다.
+
+| Listing Resources        |                                            |
+| ------------------------ | ------------------------------------------ |
+| kubectl get nodes        | 클러스터의 모든 노드 나열                  |
+| kubectl get namespaces   | 클러스터의 모든 네임스페이스 나열          |
+| kubectl get pods         | 기본 네임스페이스 클러스터에 모든 pod 나열 |
+| kubectl get pods -n name | "이름" 네임스페이스에 모든 pod를 나열      |
+
+| Creating Resources            |                                            |
+| ----------------------------- | ------------------------------------------ |
+| kubectl create namespace name | "name"이라는 네임스페이스를 생성           |
+| kubectl create -f [filename]  | JSON 또는 YAML 파일에서 리소스를 다시 생성 |
+
+| Editing Resources            |               |
+| ---------------------------- | ------------- |
+| kubectl edit svc/servicename | 서비스를 편집 |
+
+| More detail on Resources |                                       |
+| ------------------------ | ------------------------------------- |
+| kubectl describe nodes   | 원하는 수의 리소스 상태를 자세히 표시 |
+
+| Delete Resources   |                                                           |
+| ------------------ | --------------------------------------------------------- |
+| kubectl delete pod | 리소스를 제거할 수 있으며, 이는 stdin 또는 파일에서 제거. |
+
+예를 들어 `-n`은 `namespace`의 줄임말로, 명령을 입력하기 쉬울 뿐만 아니라 스크립트를 작성할 때 훨씬 더 깔끔한 코드를 만들 수 있습니다.
+
+| Short name | Full name                  |
+| ---------- | -------------------------- |
+| csr        | certificatesigningrequests |
+| cs         | componentstatuses          |
+| cm         | configmaps                 |
+| ds         | daemonsets                 |
+| deploy     | deployments                |
+| ep         | endpoints                  |
+| ev         | events                     |
+| hpa        | horizontalpodautoscalers   |
+| ing        | ingresses                  |
+| limits     | limitranges                |
+| ns         | namespaces                 |
+| no         | nodes                      |
+| pvc        | persistentvolumeclaims     |
+| pv         | persistentvolumes          |
+| po         | pods                       |
+| pdb        | poddisruptionbudgets       |
+| psp        | podsecuritypolicies        |
+| rs         | replicasets                |
+| rc         | replicationcontrollers     |
+| quota      | resourcequotas             |
+| sa         | serviceaccounts            |
+| svc        | services                   |
+
+마지막으로 추가하고 싶은 것은 데이터 서비스를 표시하기 위해 데모 환경을 빠르게 스핀업하고 Kasten K10으로 이러한 워크로드를 보호하기 위해 Minikube와 관련된 또 다른 프로젝트를 만들었습니다. [Project Pace](https://github.com/MichaelCade/project_pace)는 여기에서 찾을 수 있으며 여러분의 피드백이나 상호 작용을 원하며 Minikube 클러스터를 배포하고 다양한 데이터 서비스 애플리케이션을 만드는 몇 가지 자동화된 방법을 표시하거나 포함합니다.
+
+다음에는 VirtualBox를 사용하여 여러 노드를 가상 머신에 배포하는 방법을 살펴보겠지만, Linux 섹션에서 vagrant를 사용하여 머신을 빠르게 스핀업하고 원하는 방식으로 소프트웨어를 배포했던 것처럼 여기에서도 쉽게 진행할 것입니다.
+
+어제 포스트에 배포 중인 다양한 Kubernetes 클러스터에 대해 제가 수행한 워크스루 블로그인 이 목록을 추가했습니다.
+
+- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
+- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
+- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
+- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
+- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
+- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
+- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
+- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
+- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
+- [Minikube - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://medium.com/techbeatly/deploy-minikube-using-vagrant-and-ansible-on-virtualbox-infrastructure-as-code-2baf98188847)
+
+### Kubernetes 시리즈에서 다룰 내용
+
+아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 후 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+사용하신 무료 리소스가 있다면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜드리겠습니다.
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+- [Techbeatly - Deploy Minikube Using Vagrant and Ansible on VirtualBox](https://www.youtube.com/watch?v=xPLQqHbp9BM&t=371s)
+
+[Day 52](day52.md)에서 봐요!
--- a/2022/ko/Days/day52.md
+++ b/2022/ko/Days/day52.md
@ -0,0 +1,182 @@
+---
+title: '#90DaysOfDevOps - Setting up a multinode Kubernetes Cluster - Day 52'
+published: false
+description: 90DaysOfDevOps - Setting up a multinode Kubernetes Cluster
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1049050
+---
+
+## 멀티노드 Kubernetes 클러스터 설정하기
+
+이 제목을 "Vagrant로 멀티노드 Kubernetes 클러스터 설정하기"로 하고 싶었지만, 너무 길 것 같았습니다!
+
+어제 세션에서는 멋진 프로젝트를 사용하여 첫 번째 Kubernetes 클러스터를 배포하고 Kubernetes를 사용할 때 접하게 될 가장 중요한 CLI 도구(kubectl)를 조금 실습해 보았습니다.
+
+여기서는 VirtualBox를 기본으로 사용하지만, 지난번 리눅스 섹션에서 Vagrant에 대해 이야기할 때 언급했듯이 지원되는 모든 하이퍼바이저 또는 가상화 도구를 사용할 수 있습니다. 리눅스 섹션에서 우분투 머신을 배포한 것은 [Day 14](day14.md)였습니다.
+
+### Vagrant에 대한 간략한 요약
+
+Vagrant는 가상 머신의 라이프사이클을 관리하는 CLI 유틸리티입니다. vSphere, Hyper-v, Virtual Box, Docker 등 다양한 플랫폼에서 가상 머신을 스핀업 및 스핀다운하는 데 Vagrant를 사용할 수 있습니다. 다른 공급업체도 있지만 여기서는 Virtual Box를 사용하고 있으므로 계속 사용하겠습니다.
+
+이 [블로그 및 리포지토리](https://devopscube.com/kubernetes-cluster-vagrant/)를 기준으로 하여 구성을 안내해 드리겠습니다. 하지만 Kubernetes 클러스터를 처음 배포하는 경우라면 수동으로 이 작업을 수행하는 방법도 살펴보고 최소한 어떤 모습인지 알고 계실 것을 권해드리고 싶습니다. Kubernetes는 릴리스될 때마다 더욱 효율적으로 개선되고 있다고 말씀드리고 싶습니다. 저는 이것을 VMware와 ESX 시절에 비유하자면, ESX 서버 3대를 배포하는 데 적어도 하루는 필요했지만, 지금은 한 시간 안에 이를 실행할 수 있습니다. 저희는 Kubernetes와 관련해서는 그 방향으로 나아가고 있습니다.
+
+### Kubernetes 랩 환경
+
+환경을 구축하는 데 사용할 vagrantfile을 [Kubernetes 폴더](/2022/Days/Kubernetes)에 업로드했습니다. 이 파일을 잡고 터미널에서 이 디렉토리로 이동합니다. 저는 다시 Windows를 사용하므로 PowerShell을 사용하여 vagrant로 워크스테이션 명령을 수행하겠습니다. vagrant가 없는 경우 어제 Minikube 및 기타 도구를 설치할 때 다룬 arkade를 사용할 수 있습니다. 간단한 명령어인 `arkade get vagrant`를 실행하면 최신 버전의 vagrant를 다운로드하여 설치할 수 있습니다.
+
+디렉토리에 들어가면 `vagrant up`을 실행하고 모든 것이 올바르게 구성되었다면 터미널에 다음과 같은 킥오프가 표시됩니다.
+
+![](/2022/Days/Images/Day52_Kubernetes1.png)
+
+터미널에서 몇 가지 단계가 진행되는 것을 볼 수 있지만, 그동안 우리가 여기서 무엇을 빌드하고 있는지 살펴봅시다.
+
+![](/2022/Days/Images/Day52_Kubernetes2.png)
+
+위에서 보면 3개의 가상 머신을 빌드하고 컨트롤 플레인 노드와 두 개의 워커 노드가 있다는 것을 알 수 있습니다. [Day 49](day49.md)로 돌아가면 이미지에서 볼 수 있는 이러한 영역에 대한 설명이 더 있습니다.
+
+또한 이미지에서는 클러스터 외부에서 kubectl 액세스가 발생하여 해당 kube apiserver에 도달하는 것으로 표시되어 있지만, 실제로는 vagrant 프로비저닝의 일부로 각 노드 내에서 클러스터에 액세스할 수 있도록 각 노드에 kubectl을 배포하고 있습니다.
+
+이 실습을 구축하는 과정은 설정에 따라 5분에서 30분 정도 걸릴 수 있습니다.
+
+곧 스크립트에 대해서도 다룰 예정이지만, 배포의 일부로 3개의 스크립트를 호출하는 vagrant 파일을 보면 클러스터가 실제로 생성되는 곳이라는 것을 알 수 있습니다. Vagrant boxes를 사용하여 가상 머신과 OS 설치를 배포하는 것이 얼마나 쉬운지 살펴보았지만, 배포 프로세스의 일부로 셸 스크립트를 실행할 수 있는 기능이 있다는 것은 이러한 실습 빌드 아웃 자동화와 관련하여 매우 흥미로운 부분입니다.
+
+완료되면 터미널에서 노드 중 하나에 `vagrant ssh master`로 접속하면 액세스할 수 있으며, 기본 사용자 이름과 비밀번호는 `vagrant/vagrant`입니다.
+
+원하는 경우 `vagrant ssh node01` 및 `vagrant ssh node02`를 사용하여 작업자 노드에 액세스할 수도 있습니다.
+
+![](/2022/Days/Images/Day52_Kubernetes3.png)
+
+이제 새 클러스터의 위 노드 중 하나에서 `kubectl get nodes`를 실행하여 3노드 클러스터와 그 상태를 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day52_Kubernetes4.png)
+
+이 시점에서, 컨트롤 플레인 노드 1개와 워커 노드 2개로 구성된 3노드 클러스터가 실행되고 있습니다.
+
+### Vagrant 파일 및 셸 스크립트 연습
+
+vagrantfile을 살펴보면 여러 작업자 노드, VirtualBox 내의 브리지 네트워크에 대한 네트워킹 IP 주소, 그리고 일부 이름 지정을 정의하고 있음을 알 수 있습니다. 또한 특정 호스트에서 실행하려는 일부 스크립트를 호출하고 있음을 알 수 있습니다.
+
+```shell
+NUM_WORKER_NODES=2
+IP_NW="10.0.0."
+IP_START=10
+
+Vagrant.configure("2") do |config|
+    config.vm.provision "shell", inline: <<-SHELL
+        apt-get update -y
+        echo "$IP_NW$((IP_START))  master-node" >> /etc/hosts
+        echo "$IP_NW$((IP_START+1))  worker-node01" >> /etc/hosts
+        echo "$IP_NW$((IP_START+2))  worker-node02" >> /etc/hosts
+    SHELL
+    config.vm.box = "bento/ubuntu-21.10"
+    config.vm.box_check_update = true
+
+    config.vm.define "master" do |master|
+      master.vm.hostname = "master-node"
+      master.vm.network "private_network", ip: IP_NW + "#{IP_START}"
+      master.vm.provider "virtualbox" do |vb|
+          vb.memory = 4048
+          vb.cpus = 2
+          vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
+      end
+      master.vm.provision "shell", path: "scripts/common.sh"
+      master.vm.provision "shell", path: "scripts/master.sh"
+    end
+
+    (1..NUM_WORKER_NODES).each do |i|
+      config.vm.define "node0#{i}" do |node|
+        node.vm.hostname = "worker-node0#{i}"
+        node.vm.network "private_network", ip: IP_NW + "#{IP_START + i}"
+        node.vm.provider "virtualbox" do |vb|
+            vb.memory = 2048
+            vb.cpus = 1
+            vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
+        end
+        node.vm.provision "shell", path: "scripts/common.sh"
+        node.vm.provision "shell", path: "scripts/node.sh"
+      end
+    end
+  end
+```
+
+실행 중인 스크립트를 분석해 보겠습니다. 특정 노드에서 실행할 세 개의 스크립트가 위의 VAGRANTFILE에 나열되어 있습니다.
+
+`master.vm.provision "shell", path: "scripts/common.sh"`
+
+위의 스크립트는 노드를 준비하는 데 초점을 맞출 것이며, 3개의 노드 모두에서 실행될 것이며, 기존의 모든 Docker 구성 요소를 제거하고 Docker와 ContainerD는 물론 kubeadm, kubelet 및 kubectl을 다시 설치합니다. 이 스크립트는 또한 시스템의 기존 소프트웨어 패키지도 업데이트합니다.
+
+`master.vm.provision "shell", path: "scripts/master.sh"`
+
+master.sh 스크립트는 컨트롤 플레인 노드에서만 실행되며, 이 스크립트는 kubeadm 커맨드를 사용하여 Kubernetes 클러스터를 생성합니다. 또한 이 클러스터에 대한 액세스를 위한 구성 컨텍스트도 준비할 것이며, 이는 다음에 다룰 것입니다.
+
+`node.vm.provision "shell", path: "scripts/node.sh"`
+
+이것은 단순히 마스터가 생성한 구성을 가져와서 우리 노드를 Kubernetes 클러스터에 추가하는 것이며, 이 추가 프로세스는 다시 kubeadm과 config 폴더에서 찾을 수 있는 다른 스크립트를 사용합니다.
+
+### Kubernetes 클러스터에 액세스하기
+
+이제 두 개의 클러스터가 배포되었습니다. 이전 섹션에서 배포한 Minikube 클러스터와 방금 VirtualBox에 배포한 새로운 3노드 클러스터가 있습니다.
+
+또한 vagrant를 실행한 머신에서도 액세스할 수 있는 구성 파일에는 워크스테이션에서 클러스터에 액세스하는 방법이 포함되어 있습니다.
+
+이를 보여드리기 전에 컨텍스트에 대해 말씀드리겠습니다.
+
+![](/2022/Days/Images/Day52_Kubernetes5.png)
+
+컨텍스트가 중요하며, 데스크톱이나 노트북에서 Kubernetes 클러스터에 액세스할 수 있는 기능이 필요합니다. 다양한 옵션이 존재하며 사람들은 각기 다른 운영 체제를 일상적으로 사용합니다.
+
+기본적으로, Kubernetes CLI 클라이언트(kubectl)는 엔드포인트 및 자격 증명과 같은 Kubernetes 클러스터 세부 정보를 저장하기 위해 C:\Users\username.kube\config를 사용합니다. 클러스터를 배포한 경우 해당 위치에서 이 파일을 볼 수 있습니다. 하지만 지금까지 마스터 노드에서 SSH 또는 다른 방법을 통해 모든 kubectl 명령을 실행했다면 이 포스팅이 워크스테이션과 연결할 수 있는 방법을 이해하는 데 도움이 되길 바랍니다.
+
+그런 다음 클러스터에서 kubeconfig 파일을 가져오거나 배포된 구성 파일에서 가져올 수도 있고, SCP를 통해 이 파일의 내용을 가져오거나 마스터 노드에 콘솔 세션을 열고 로컬 윈도우 머신에 복사할 수도 있습니다.
+
+![](/2022/Days/Images/Day52_Kubernetes6.png)
+
+그런 다음 해당 구성 파일의 복사본을 가져와서 `$HOME/.kube/config` 위치로 이동합니다.
+
+![](/2022/Days/Images/Day52_Kubernetes7.png)
+
+이제 로컬 워크스테이션에서 `kubectl cluster-info`와 `kubectl get nodes`를 실행하여 클러스터에 액세스할 수 있는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day52_Kubernetes8.png)
+
+이렇게 하면 윈도우 머신에서 연결 및 제어가 가능할 뿐만 아니라 윈도우 머신에서 특정 서비스에 액세스하기 위해 포트 포워딩을 수행할 수 있습니다.
+
+워크스테이션에서 여러 클러스터를 관리하는 방법에 관심이 있으시다면 [여기](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-6)에 더 자세한 안내가 있습니다.
+
+이 목록은 제가 배포 중인 다양한 Kubernetes 클러스터에 대해 수행한 워크스루 블로그입니다.
+
+- [Kubernetes playground – How to choose your platform](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-1)
+- [Kubernetes playground – Setting up your cluster](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-2)
+- [Getting started with Amazon Elastic Kubernetes Service (Amazon EKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-amazon-elastic-kubernetes-service-amazon-eks)
+- [Getting started with Microsoft Azure Kubernetes Service (AKS)](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-azure-kubernetes-service-aks)
+- [Getting Started with Microsoft AKS – Azure PowerShell Edition](https://vzilla.co.uk/vzilla-blog/getting-started-with-microsoft-aks-azure-powershell-edition)
+- [Getting started with Google Kubernetes Service (GKE)](https://vzilla.co.uk/vzilla-blog/getting-started-with-google-kubernetes-service-gke)
+- [Kubernetes, How to – AWS Bottlerocket + Amazon EKS](https://vzilla.co.uk/vzilla-blog/kubernetes-how-to-aws-bottlerocket-amazon-eks)
+- [Getting started with CIVO Cloud](https://vzilla.co.uk/vzilla-blog/getting-started-with-civo-cloud)
+- [Minikube - Kubernetes Demo Environment For Everyone](https://vzilla.co.uk/vzilla-blog/project_pace-kasten-k10-demo-environment-for-everyone)
+
+### Kubernetes 시리즈에서 다룰 내용
+
+아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 다음 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+[Day 53](day53.md)에서 봐요!
--- a/2022/ko/Days/day53.md
+++ b/2022/ko/Days/day53.md
@ -0,0 +1,129 @@
+---
+title: '#90DaysOfDevOps - Rancher Overview - Hands On - Day 53'
+published: false
+description: 90DaysOfDevOps - Rancher Overview - Hands On
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048742
+---
+
+## Rancher 개요 - 핸즈온
+
+이 섹션에서는 Rancher에 대해 살펴볼 것인데, 지금까지는 클러스터 관리에 대한 좋은 가시성을 운영팀에 제공하는 몇 가지 좋은 UI와 멀티클러스터 관리 도구가 있지만, 지금까지 한 모든 작업은 cli와 kubectl을 사용했습니다.
+
+Rancher는 [사이트](https://rancher.com/)에 따르면
+
+> Rancher는 컨테이너를 도입하는 팀을 위한 완벽한 소프트웨어 스택입니다. 이 스택은 모든 인프라에서 여러 개의 Kubernetes 클러스터를 관리할 때 발생하는 운영 및 보안 문제를 해결하는 동시에 데브옵스 팀에 컨테이너화된 워크로드를 실행하기 위한 통합 도구를 제공합니다.
+
+Rancher를 사용하면 거의 모든 위치에서 프로덕션급 Kubernetes 클러스터를 배포할 수 있으며 중앙 집중식 인증, 액세스 제어 및 통합 가시성을 제공합니다. 이전 섹션에서 Kubernetes와 관련하여 거의 압도적인 선택의 폭이 있으며, 어디에서 실행해야 하는지 또는 실행할 수 있는지에 대해 언급했지만, Rancher를 사용하면 어디에 있든 상관없습니다.
+
+### Rancher 배포
+
+가장 먼저 해야 할 일은 로컬 워크스테이션에 Rancher를 배포하는 것입니다. 이 단계를 진행하기 위해 선택할 수 있는 몇 가지 방법과 위치가 있는데, 저는 로컬 워크스테이션을 사용하고 Rancher를 docker 컨테이너로 실행하고 싶습니다. 아래 명령을 실행하면 컨테이너 이미지를 가져온 다음 Rancher UI에 액세스할 수 있습니다.
+
+다른 Rancher 배포 방법은 [Rancher 빠른 시작 가이드](https://rancher.com/docs/rancher/v2.6/en/quick-start-guide/deployment/)에서 확인할 수 있습니다.
+
+`sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher`
+
+docker 데스크톱에서 볼 수 있듯이 실행 중인 Rancher 컨테이너가 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes1.png)
+
+### Rancher UI 액세스
+
+위의 컨테이너가 실행 중이면 웹 페이지를 통해 컨테이너로 이동할 수 있어야 합니다. `https://localhost`를 입력하면 아래와 같이 로그인 페이지가 나타납니다.
+
+![](/2022/Days/Images/Day53_Kubernetes2.png)
+
+아래 안내에 따라 필요한 비밀번호를 입력합니다. 저는 Windows를 사용하고, grep 명령이 필요하기 때문에 Windows용 bash를 사용하기로 했습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes3.png)
+
+이제 위의 비밀번호를 사용하여 로그인하면 다음 페이지에서 새 비밀번호를 정의할 수 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes4.png)
+
+위의 작업을 완료하면 로그인이 완료되고 시작 화면을 볼 수 있습니다. Rancher 배포의 일부로 로컬 K3 클러스터가 프로비저닝된 것도 볼 수 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes5.png)
+
+### Rancher에 대한 간략한 둘러보기
+
+가장 먼저 살펴볼 것은 로컬로 배포된 K3S 클러스터입니다. 아래에서 클러스터 내부에서 어떤 일이 일어나고 있는지 잘 볼 수 있습니다. 이것은 기본 배포이며 아직 이 클러스터에 아무것도 배포하지 않았습니다. 1개의 노드로 구성되어 있고 5개의 배포가 있는 것을 볼 수 있습니다. 그리고 pod, 코어, 메모리에 대한 몇 가지 통계가 있는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes6.png)
+
+왼쪽 메뉴에는 앱 및 마켓플레이스 탭도 있는데, 이 탭을 통해 클러스터에서 실행할 애플리케이션을 선택할 수 있습니다. 앞서 언급했듯이 Rancher는 여러 개의 다른 클러스터를 실행하거나 관리할 수 있는 기능을 제공합니다. 마켓플레이스를 사용하면 애플리케이션을 매우 쉽게 배포할 수 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes7.png)
+
+또 한 가지 언급할 것은 오른쪽 상단에 있는 Rancher에서 관리 중인 클러스터에 액세스해야 하는 경우 선택한 클러스터에 대한 kubectl 셸을 열 수 있다는 것입니다.
+
+![](/2022/Days/Images/Day53_Kubernetes8.png)
+
+### 새 클러스터 생성
+
+지난 두 세션에 걸쳐 로컬에서 Minikube 클러스터를 생성하고 가상박스와 함께 Vagrant를 사용하여 3노드 Kubernetes 클러스터를 생성했으며, Rancher를 사용하여 클러스터를 생성할 수도 있습니다. [Rancher 폴더](/2022/Days/Kubernetes/Rancher)에는 동일한 3개의 노드를 구축할 수 있는 추가 vagrant 파일이 있지만 Kubernetes 클러스터를 생성하는 단계가 없습니다(Rancher가 이 작업을 대신 수행하기를 원합니다).
+
+그러나 각 노드에서 `common.sh` 스크립트가 계속 실행되는 것을 볼 수 있도록 docker가 설치되고 OS가 업데이트되기를 원합니다. 이것은 또한 Kubeadm, Kubectl 등을 설치합니다. 그러나 노드를 클러스터로 생성하고 조인하기 위한 Kubeadm 명령은 실행되지 않습니다.
+
+vagrant 폴더 위치로 이동하여 `vagrant up`을 실행하기만 하면 가상 박스에서 3개의 가상 머신을 생성하는 프로세스가 시작됩니다.
+
+![](/2022/Days/Images/Day53_Kubernetes9.png)
+
+이제 노드 또는 VM이 제자리에 배치되고 준비되었으므로 Rancher를 사용하여 새로운 Kubernetes 클러스터를 생성할 수 있습니다. 클러스터를 생성하는 첫 번째 화면에서는 클러스터가 어디에 있는지, 즉 퍼블릭 클라우드 관리형 Kubernetes 서비스를 사용 중인지, vSphere 또는 다른 것을 사용 중인지에 대한 몇 가지 옵션을 제공합니다.
+
+![](/2022/Days/Images/Day53_Kubernetes10.png)
+
+통합 플랫폼 중 하나를 사용하지 않으므로 "custom"을 선택하겠습니다. 시작 페이지는 클러스터 이름을 정의하는 곳입니다(아래에 로컬이라고 되어 있지만 로컬을 사용할 수 없습니다. 저희 클러스터는 vagrant라고 합니다.) 여기에서 Kubernetes 버전, 네트워크 공급자 및 기타 구성 옵션을 정의하여 Kubernetes 클러스터를 시작하고 실행할 수 있습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes11.png)
+
+다음 페이지에서는 활성화할 적절한 서비스와 함께 각 노드에서 실행해야 하는 등록 코드(etcd, 컨트롤 플레인 및 워커)를 제공합니다. 마스터 노드의 경우, etcd와 컨트롤 플레인이 필요하므로 명령은 아래와 같습니다.
+
+![](/2022/Days/Images/Day53_Kubernetes12.png)
+
+```
+sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.6.3 --server https://10. 0.0.1 --token mpq8cbjjwrj88z4xmf7blqxcfmwdsmq92bmwjpphdkklfckk5hfwc2 --ca-checksum a81944423cbfeeb92be0784edebba1af799735ebc30ba8cbe5cc5f996094f30b --etcd --controlplane
+```
+
+네트워킹이 올바르게 구성되었다면, 이제 첫 번째 마스터 노드가 등록되고 클러스터가 생성되고 있음을 나타내는 Rancher 대시보드에 다음과 같이 빠르게 표시되어야 합니다.
+
+![](/2022/Days/Images/Day53_Kubernetes13.png)
+
+그런 다음 다음 명령으로 각 워커 노드에 대한 등록 프로세스를 반복하면 얼마 후 마켓플레이스를 활용하여 애플리케이션을 배포할 수 있는 클러스터를 실행할 수 있게 됩니다.
+
+```
+sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.6.3 --server https://10. 0.0.1 --token mpq8cbjjwrj88z4xmf7blqxcfmwdsmq92bmwjpphdkklfckk5hfwc2 --ca-checksum a81944423cbfeeb92be0784edebba1af799735ebc30ba8cbe5cc5f996094f30b --worker
+```
+
+![](/2022/Days/Images/Day53_Kubernetes14.png)
+
+지난 세 세션 동안, 우리는 몇 가지 다른 방법으로 Kubernetes 클러스터를 시작하고 실행하는 방법을 사용했으며, 남은 날에는 플랫폼에서 가장 중요한 애플리케이션 측면을 살펴볼 것입니다. 서비스 프로비저닝과 Kubernetes에서 서비스를 프로비저닝하고 사용할 수 있는 방법에 대해 살펴보겠습니다.
+
+부트스트랩 Rancher 노드에 대한 요구사항에 따라 해당 VM에 4GB 램이 있어야 하며 그렇지 않으면 크래시 루프가 발생한다고 들었는데, 이후 워커 노드에 2GB가 있는 것으로 업데이트했습니다.
+
+### Kubernetes 시리즈에서 다룰 내용
+
+아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 다음 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+[Day 54](day54.md)에서 봐요!
--- a/2022/ko/Days/day54.md
+++ b/2022/ko/Days/day54.md
@ -0,0 +1,223 @@
+---
+title: '#90DaysOfDevOps - Kubernetes Application Deployment - Day 54'
+published: false
+description: 90DaysOfDevOps - Kubernetes Application Deployment
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048764
+---
+
+## Kubernetes 애플리케이션 배포
+
+이제 드디어 일부 애플리케이션을 클러스터에 배포하게 되었는데, 일부 사람들은 이것이 바로 애플리케이션 배포를 위해 Kubernetes가 존재하는 이유라고 말할 수 있습니다.
+
+여기서 아이디어는 컨테이너 이미지를 가져와서 이제 컨테이너 오케스트레이터로서 Kubernetes를 활용하기 위해 컨테이너 이미지를 Kubernetes 클러스터에 pod로 배포할 수 있다는 것입니다.
+
+### Kubernetes에 앱 배포하기
+
+애플리케이션을 Kubernetes 클러스터에 배포하는 방법에는 여러 가지가 있지만, 가장 일반적인 두 가지 접근 방식인 YAML 파일과 Helm 차트를 다뤄보겠습니다.
+
+이러한 애플리케이션 배포에는 Minikube 클러스터를 사용할 것입니다. 앞서 언급한 Kubernetes의 구성 요소 또는 빌딩 블록 중 일부를 살펴볼 것입니다.
+
+이 섹션과 컨테이너 섹션을 통해 이미지와 Kubernetes의 장점, 그리고 이 플랫폼에서 확장을 매우 쉽게 처리할 수 있는 방법에 대해 논의했습니다.
+
+이 첫 번째 단계에서는 Minikube 클러스터 내에 상태 비저장 애플리케이션을 간단히 생성해 보겠습니다. 사실상의 표준 상태 비저장 애플리케이션인 `nginx`를 사용하여 첫 번째 데모에서 배포를 구성하여 pod를 제공한 다음 nginx pod에서 호스팅하는 간단한 웹 서버로 이동할 수 있는 서비스도 생성할 것입니다. 이 모든 것이 네임스페이스에 포함될 것입니다.
+
+![](/2022/Days/Images/Day54_Kubernetes1.png)
+
+### YAML 생성
+
+첫 번째 데모에서는 YAML로 수행하는 모든 작업을 정의하고자 합니다. YAML에 대한 전체 섹션이 있을 수 있지만, 여기서는 간략히 살펴보고 마지막에 YAML을 더 자세히 다룰 몇 가지 리소스를 남겨두려고 합니다.
+
+다음을 하나의 YAML 파일로 만들 수도 있고, 애플리케이션의 각 측면별로 나눌 수도 있습니다. 즉, 네임스페이스, 배포 및 서비스 생성을 위한 별도의 파일일 수 있지만 이 파일에서는 아래에서 `---`를 사용하여 하나의 파일로 구분했습니다. 이 파일은 [여기](/2022/Days/Kubernetes)에서 찾을 수 있습니다(파일명:- nginx-stateless-demo.YAML).
+
+```Yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: nginx
+  "labels": {
+    "name": "nginx"
+  }
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  namespace: nginx
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-service
+  namespace: nginx
+spec:
+  selector:
+    app: nginx-deployment
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 80
+```
+
+### 클러스터 확인
+
+배포하기 전에 `nginx`라는 네임스페이스가 없는지 확인해야 하는데, `kubectl get namespace` 명령을 실행하여 확인할 수 있으며, 아래에서 볼 수 있듯이 `nginx`라는 네임스페이스가 없습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes2.png)
+
+### 앱을 배포할 시간
+
+이제 Minikube 클러스터에 애플리케이션을 배포할 준비가 되었으며, 이 프로세스는 다른 모든 Kubernetes 클러스터에서도 동일하게 작동합니다.
+
+YAML 파일 위치로 이동한 다음 `kubectl create -f nginx-stateless-demo.yaml`을 실행하면 3개의 오브젝트가 생성되고 네임스페이스, 배포 및 서비스가 생성된 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes3.png)
+
+클러스터에서 사용 가능한 네임스페이스를 확인하기 위해 `kubectl get namespace` 명령을 다시 실행하면 이제 새 네임스페이스가 있는 것을 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes5.png)
+
+이제 `kubectl get pods -n nginx`를 사용하여 네임스페이스에 pod가 있는지 확인하면 준비 및 실행 상태의 pod 1개가 있는 것을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes4.png)
+
+또한 `kubectl get service -n nginx`를 실행하여 서비스가 생성되었는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes6.png)
+
+마지막으로, 배포를 확인하여 원하는 구성을 어디에 어떻게 유지하는지 확인할 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes7.png)
+
+위는 몇 가지 알아두면 좋은 명령어를 사용했지만, `kubectl get all -n nginx`를 사용하여 하나의 YAML 파일로 배포한 모든 것을 볼 수도 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes8.png)
+
+위 그림에서 replicaset가 있는 것을 볼 수 있는데, 배포에서 배포할 이미지의 레플리카 개수를 정의합니다. 처음에는 1로 설정되었지만, 애플리케이션을 빠르게 확장하려면 여러 가지 방법으로 확장할 수 있습니다.
+
+터미널 내에서 텍스트 편집기를 열고 배포를 수정할 수 있는 `kubectl edit deployment  nginx-deployment -n nginx`를 사용하여 파일을 편집할 수 있다.
+
+![](/2022/Days/Images/Day54_Kubernetes9.png)
+
+터미널 내의 텍스트 편집기에서 위의 내용을 저장했을 때 문제가 없고 올바른 서식이 사용되었다면 네임스페이스에 추가로 배포된 것을 볼 수 있을 것입니다.
+
+![](/2022/Days/Images/Day54_Kubernetes10.png)
+
+또한 kubectl과 `kubectl scale deployment  nginx-deployment --replicas=10 -n nginx`를 사용하여 레플리카 수를 변경할 수 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes11.png)
+
+두 방법 중 하나를 사용하려는 경우 이 방법을 사용하여 애플리케이션을 다시 1로 축소할 수 있습니다. 저는 편집 옵션을 사용했지만, 위의 스케일 명령을 사용할 수도 있습니다.
+
+![](/2022/Days/Images/Day54_Kubernetes12.png)
+
+여기서 사용 사례를 통해 매우 빠르게 스핀업 및 스핀다운할 수 있을 뿐만 아니라 애플리케이션을 빠르게 확장 및 축소할 수 있다는 것을 알 수 있기를 바랍니다. 이것이 웹 서버라면 부하가 많을 때는 확장하고 부하가 적을 때는 축소할 수 있습니다.
+
+### 앱 노출하기
+
+그렇다면 어떻게 웹 서버에 접속할 수 있을까요?
+
+위에서 저희 서비스를 보면 사용 가능한 외부 IP가 없으므로 웹 브라우저를 열고 마술처럼 접속할 수는 없습니다. 접속을 위해 몇 가지 옵션이 있습니다.
+
+**ClusterIP** - 표시되는 IP는 클러스터 내부 네트워크에 있는 클러스터IP입니다. 클러스터 내의 사물만 이 IP에 연결할 수 있습니다.
+
+**NodePort** - NAT를 사용하여 클러스터에서 선택한 각 노드의 동일한 포트에 서비스를 노출합니다.
+
+**로드 밸런서** - 현재 클라우드에 외부 로드 밸런서를 생성합니다. 저희는 Minikube를 사용하고 있지만, VirtualBox에서 했던 것과 같이 자체 Kubernetes 클러스터를 구축한 경우 이 기능을 제공하려면 metallb와 같은 로드밸런서를 클러스터에 배포해야 합니다.
+
+**포트 포워드** - 로컬 호스트에서 내부 Kubernetes 클러스터 프로세스에 액세스하고 상호 작용할 수 있는 포트 포워드 기능도 있습니다. 이 옵션은 테스트 및 결함 발견에만 사용됩니다.
+
+이제 선택할 수 있는 몇 가지 옵션이 생겼습니다. Minikube에는 본격적인 Kubernetes 클러스터와 비교했을 때 몇 가지 제한 사항이나 차이점이 있습니다.
+
+다음 명령을 실행하여 로컬 워크스테이션을 사용하여 액세스를 포트 포워딩할 수 있습니다.
+
+`kubectl port-forward deployment/nginx-deployment -n nginx 8090:80`
+
+![](/2022/Days/Images/Day54_Kubernetes13.png)
+
+위 명령을 실행하면 로컬 머신과 포트에 대한 포트 포워딩 역할을 하므로 이 터미널을 사용할 수 없게 됩니다.
+
+![](/2022/Days/Images/Day54_Kubernetes14.png)
+
+이제 Minikube를 통해 애플리케이션을 노출하는 방법을 구체적으로 살펴보겠습니다. Minikube를 사용하여 서비스에 연결하기 위한 URL을 생성할 수도 있습니다. [자세한 내용](https://minikube.sigs.k8s.io/docs/commands/service/)
+
+먼저, `kubectl delete service nginx-service -n nginx`를 사용하여 서비스를 삭제합니다.
+
+다음으로 `kubectl expose deployment nginx-deployment --name nginx-service --namespace nginx --port=80 --type=NodePort`를 사용하여 새 서비스를 생성합니다. 여기서 expose를 사용하고 유형을 NodePort로 변경한다는 점에 유의하세요.
+
+![](/2022/Days/Images/Day54_Kubernetes15.png)
+
+마지막으로 새 터미널에서 `minikube --profile='mc-demo' service nginx-service --url -n nginx`를 실행하여 서비스에 대한 터널을 생성합니다.
+
+![](/2022/Days/Images/Day54_Kubernetes16.png)
+
+브라우저 또는 제어를 열고 터미널에서 링크를 클릭합니다.
+
+![](/2022/Days/Images/Day54_Kubernetes17.png)
+
+### Helm
+
+Helm은 애플리케이션을 배포할 수 있는 또 다른 방법입니다. "Kubernetes를 위한 패키지 관리자"로 알려진 Helm에 대한 자세한 내용은 [여기](https://helm.sh/)에서 확인할 수 있습니다.
+
+Helm은 Kubernetes를 위한 패키지 매니저입니다. Helm은 Kubernetes에서 yum이나 apt에 해당하는 것으로 간주할 수 있습니다. Helm은 패키지 애플리케이션처럼 생각할 수 있는 차트를 배포하는데, 이는 미리 구성된 애플리케이션 리소스를 사용하기 쉬운 하나의 차트로 배포할 수 있는 청사진입니다. 그런 다음 다른 구성 세트로 차트의 다른 버전을 배포할 수 있습니다.
+
+사용 가능한 모든 Helm 차트를 찾아볼 수 있는 사이트가 있으며 물론 직접 만들 수도 있습니다. 문서도 명확하고 간결하며 이 분야의 다른 모든 신조어들 사이에서 Helm이라는 용어를 처음 들었을 때처럼 어렵지 않습니다.
+
+Helm을 시작하고 실행하거나 설치하는 것은 매우 간단합니다. 간단합니다. RaspberryPi arm64 장치를 포함한 거의 모든 배포판에 대한 바이너리와 다운로드 링크는 여기에서 찾을 수 있습니다.
+
+또는 설치 스크립트를 사용할 수도 있는데, 이 경우 최신 버전의 Helm이 다운로드되어 설치된다는 이점이 있습니다.
+
+```Shell
+curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
+
+chmod 700 get_helm.sh
+
+./get_helm.sh
+```
+
+마지막으로, 애플리케이션 관리자를 위한 패키지 관리자, 맥용 homebrew, 윈도우용 chocolatey, Ubuntu/Debian용 apt, snap 및 pkg도 사용할 수 있습니다.
+
+지금까지는 Helm이 클러스터에 다양한 테스트 애플리케이션을 다운로드하고 설치하는 데 가장 적합한 방법인 것 같습니다.
+
+여기에 링크할 수 있는 좋은 리소스로는 Kubernetes 패키지를 찾고, 설치하고, 게시할 수 있는 리소스인 [ArtifactHUB](https://artifacthub.io/)를 들 수 있습니다. 또한 Helm 차트를 표시하는 UI인 [KubeApps](https://kubeapps.com/)에 대해서도 언급하겠습니다.
+
+### Kubernetes에서 다룰 내용
+
+아래에 언급된 내용 중 일부를 다루기 시작했지만, 내일 두 번째 클러스터 배포를 통해 더 많은 실습을 한 후 클러스터에 애플리케이션 배포를 시작할 수 있습니다.
+
+- Kubernetes 아키텍처
+- Kubectl 커맨드
+- Kubernetes YAML
+- Kubernetes Ingress
+- Kubernetes Services
+- Helm 패키지 관리자
+- 영속성 스토리지
+- stateful 앱
+
+## 자료
+
+사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+[Day 55](day55.md)에서 봐요!
--- a/2022/ko/Days/day55.md
+++ b/2022/ko/Days/day55.md
@ -0,0 +1,239 @@
+---
+title: '#90DaysOfDevOps - State and Ingress in Kubernetes - Day 55'
+published: false
+description: 90DaysOfDevOps - State and Ingress in Kubernetes
+tags: 'DevOps, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048779
+---
+
+## Kubernetes의 State와 Ingress
+
+이번 Kubernetes 마지막 섹션에서는 State와 Ingress에 대해 살펴보겠습니다.
+
+지금까지 설명한 모든 것은 상태 비저장에 관한 것이며, 상태 비저장은 실제로 애플리케이션이 어떤 네트워크를 사용하든 상관하지 않고 영구적인 저장소가 필요하지 않은 경우입니다. 예를 들어 Stateful 애플리케이션과 데이터베이스가 제대로 작동하려면, 호스트 이름, IP 등 변경되지 않는 고유 ID를 통해 pod가 서로 연결될 수 있도록 해야 합니다. Stateful 애플리케이션의 예로는 MySQL 클러스터, Redis, Kafka, MongoDB 등이 있습니다. 기본적으로 데이터를 저장하는 모든 애플리케이션을 통해 가능합니다.
+
+### Stateful 애플리케이션
+
+StatefulSet은 Kubernetes가 스케줄링 위치에 관계없이 유지 관리하는 고유하고 영구적인 ID와 안정적인 호스트 이름을 가진 pod의 집합을 나타냅니다. 특정 StatefulSet pod의 상태 정보 및 기타 복원력 있는 데이터는 StatefulSet과 연결된 영속성 디스크 스토리지에 유지됩니다.
+
+### Deployment vs StatefulSet
+
+- Stateful 애플리케이션을 복제하는 것은 더 어렵다.
+- 배포(Stateless 애플리케이션)에서 pod를 복제하는 것은 동일하며 상호 교환이 가능하다.
+- 임의의 해시를 사용하여 임의의 순서로 pod를 생성한다.
+- 모든 pod에 로드 밸런싱하는 하나의 서비스이다.
+
+StatefulSet 또는 Stateful 애플리케이션의 경우 위의 내용이 더 어렵습니다.
+
+- 동시에 생성하거나 삭제할 수 없다.
+- 임의로 주소를 지정할 수 없다.
+- 레플리카 pod는 동일하지 않다.
+
+곧 데모에서 보게 될 것은 각 pod가 고유한 식별자를 가지고 있다는 것입니다. 상태 비저장 애플리케이션을 사용하면 임의의 이름을 볼 수 있습니다. 예를 들어 `app-7469bbb6d7-9mhxd`인 반면, 상태 저장 애플리케이션은 `mongo-0`에 더 가깝고 확장 시 `mongo-1`이라는 새 pod를 생성합니다.
+
+이러한 pod는 동일한 사양으로 생성되지만 상호 교환할 수는 없습니다. 각 StatefulSet pod는 모든 스케줄링에 걸쳐 영구 식별자를 가지고 있습니다. 이는 데이터베이스에 쓰고 읽어야 하는 데이터베이스와 같은 Stateful 워크로드가 필요할 때, 데이터 불일치를 초래할 수 있기 때문에 두 개의 pod가 인식 없이 동시에 쓰게 할 수 없기 때문에 필요합니다. 주어진 시간에 데이터베이스에 하나의 pod만 쓰도록 해야 하지만 여러 개의 pod가 해당 데이터를 읽을 수 있습니다.
+
+StatefulSet의 각 pod는 영구 볼륨과 데이터베이스의 복제본에 액세스하여 읽을 수 있으며, 이는 마스터로부터 지속적으로 업데이트됩니다. 또한 각 pod는 이 영속성 볼륨에 pod 상태도 저장하는데, 만약 `mongo-0`이 죽으면 새 pod가 프로비저닝될 때 스토리지에 저장된 pod 상태를 이어받게 된다는 점도 흥미롭습니다.
+
+TLDR; StatefulSet vs Deployment
+
+- 예측 가능한 pod 이름 = `mongo-0`
+- 고정된 개별 DNS 이름
+- pod 아이덴티티 - 상태 유지, 역할 유지
+- Stateful 앱 복제는 복잡함
+  - 해야 할 일이 많음:
+    - 복제 및 데이터 동기화를 구성
+    - 원격 공유 스토리지를 사용할 수 있도록 설정
+    - 관리 및 백업
+
+### 영속성 볼륨 | Claims | StorageClass
+
+Kubernetes에서 데이터를 어떻게 지속하나요?
+
+위에서 상태 저장 애플리케이션이 있을 때 상태를 어딘가에 저장해야 한다고 언급했는데, 바로 이 부분에서 볼륨의 필요성이 대두되는데, Kubernetes는 기본적으로 지속성을 제공하지 않습니다.
+
+pod 라이프사이클에 의존하지 않는 스토리지 계층이 필요합니다. 이 스토리지는 모든 Kubernetes 노드에서 사용할 수 있고 액세스할 수 있어야 합니다. 또한 이 스토리지는 Kubernetes 클러스터가 충돌하더라도 생존할 수 있도록 Kubernetes 클러스터 외부에 있어야 합니다.
+
+### 영속성 볼륨
+
+- 데이터를 저장하기 위한 클러스터 리소스(예: CPU 및 RAM)
+- YAML 파일을 통해 생성
+- 실제 물리적 스토리지(NAS)가 필요
+- Kubernetes 클러스터에 대한 외부 통합
+- 스토리지에 다양한 유형의 스토리지를 사용
+- PV는 네임스페이스가 없음
+- 로컬 스토리지를 사용할 수 있지만 클러스터의 한 노드에 한정
+- 데이터베이스 지속성은 원격 스토리지(NAS)를 사용
+
+### 영구 볼륨 Claims
+
+위의 영구 볼륨만 있어도 사용할 수 있지만 애플리케이션에서 Claims하지 않으면 사용되지 않습니다.
+
+- YAML 파일을 통해 생성
+- 영속성 볼륨 Claims은 pod 구성(볼륨 어트리뷰트)에서 사용
+- PVC는 pod와 동일한 네임스페이스에 존재
+- 볼륨이 pod에 마운트됨
+- pod는 여러 가지 볼륨 유형(ConfigMaps, Secrets, PVC)을 사용
+
+PV와 PVC를 생각하는 또 다른 방법은 다음과 같다.
+
+PV는 Kubernetes 어드민에 의해 생성된다.
+PVC는 사용자 또는 애플리케이션 개발자가 생성한다.
+
+또한 자세히 설명하지는 않겠지만 언급할 가치가 있는 두 가지 다른 유형의 볼륨이 있다:
+
+### ConfigMaps | Secrets
+
+- pod의 구성 파일
+- pod의 인증서 파일
+
+### StorageClass
+
+- YAML 파일을 통해 생성
+- PVC가 영속성 볼륨을 Claims할 때 동적으로 프로비저닝
+- 각 스토리지 백엔드에는 프로비저너가 있음
+- 스토리지 백엔드는 (프로비저너 속성을 통해) YAML에 정의됨
+- 기본 스토리지 공급자 추상화
+- 해당 스토리지에 대한 파라미터 정의
+
+### 연습 시간
+
+어제 세션에서는 상태 비저장 애플리케이션을 생성하는 방법을 살펴봤는데, 여기서는 동일한 작업을 수행하되 Minikube 클러스터를 사용하여 상태 저장 워크로드를 배포하고자 합니다.
+
+지속성을 사용하는 기능과 애드온을 갖기 위해 사용하는 Minikube 명령에 대한 요약은 `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p mc-demo --kubernetes-version=1.21.2`입니다.
+
+이 명령은 나중에 보여드리는 스토리지 클래스를 제공하는 CSI-hostpath-driver를 사용합니다.
+
+애플리케이션의 빌드 아웃은 아래와 같습니다:
+
+![](/2022/Days/Images/Day55_Kubernetes1.png)
+
+이 애플리케이션의 YAML 구성 파일은 여기에서 찾을 수 있습니다. [pacman-stateful-demo.yaml](/2022/Days/Kubernetes)
+
+### StorageClass 구성
+
+애플리케이션 배포를 시작하기 전에 실행해야 하는 한 단계가 더 있는데, 그것은 StorageClass(CSI-hostpath-sc)가 기본 StorageClass인지 확인하는 것입니다. 먼저 `kubectl get storageclass` 명령을 실행하여 확인할 수 있지만, 기본적으로 Minikube 클러스터는 표준 스토리지 클래스를 기본값으로 표시하므로 다음 명령으로 변경해야 합니다.
+
+이 첫 번째 명령은 CSI-hostpath-sc 스토리지 클래스를 기본값으로 설정합니다.
+
+`kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'`
+
+이 명령은 표준 StorageClass에서 기본 어노테이션을 제거합니다.
+
+`kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'`
+
+![](/2022/Days/Images/Day55_Kubernetes2.png)
+
+클러스터에 Pacman 네임스페이스가 없는 상태에서 시작합니다. `kubectl get namespace`
+
+![](/2022/Days/Images/Day55_Kubernetes3.png)
+
+그런 다음 YAML 파일을 배포합니다. `kubectl create -f pacman-stateful-demo.yaml` 이 명령에서 우리는 Kubernetes 클러스터 내에 여러 개의 오브젝트를 생성하고 있음을 볼 수 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes4.png)
+
+이제 새로 생성된 네임스페이스가 생겼습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes5.png)
+
+다음 이미지와 `kubectl get all -n pacman` 명령에서 네임스페이스 내부에서 여러 가지 일이 일어나고 있음을 확인할 수 있습니다. 우리는 NodeJS 웹 프론트엔드를 실행하는 pod를 가지고 있고, 백엔드 데이터베이스를 실행하는 mongo를 가지고 있습니다. Pacman과 mongo 모두 해당 pod에 액세스하기 위한 서비스가 있습니다. Pacman을 위한 배포와 mongo를 위한 StatefulSet이 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes6.png)
+
+또한 영속성 볼륨과 영속성 볼륨 Claims도 가지고 있는데, `kubectl get pv`를 실행하면 네임스페이스가 없는 영속성 볼륨을 얻을 수 있고, `kubectl get pvc -n pacman`을 실행하면 네임스페이스가 있는 영속성 볼륨 Claims을 얻을 수 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes7.png)
+
+### 게임 플레이하기 | 미션 크리티컬 애플리케이션에 액세스하기
+
+앞서 언급한 바와 같이 상태 비저장 애플리케이션에서 Minikube를 사용하고 있기 때문에 애플리케이션에 액세스하는 데 있어 몇 가지 장애물이 있지만, 클러스터 내에서 Ingress 또는 로드 밸런서에 액세스하여 외부에서 액세스하기 위해 자동으로 IP를 받도록 설정되어 있습니다. (위의 Pacman 네임스페이스의 모든 구성 요소 이미지에서 이를 확인할 수 있습니다).
+
+이 데모에서는 포트 포워드 방법을 사용하여 애플리케이션에 액세스하겠습니다. 새 터미널을 열고 다음 `kubectl port-forward svc/pacman 9090:80 -n pacman` 명령을 실행하고 브라우저를 열면 이제 애플리케이션에 액세스할 수 있다. AWS 또는 특정 위치에서 실행하는 경우, 위의 스크린샷에서 이 pod 이름을 다시 한번 확인하면 클라우드와 영역은 물론 Kubernetes 내의 pod와 동일한 호스트에 대해서도 보고됩니다.
+
+![](/2022/Days/Images/Day55_Kubernetes8.png)
+
+이제 데이터베이스에 저장할 높은 점수를 생성할 수 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes9.png)
+
+좋아요, 이제 높은 점수를 얻었지만 `mongo-0` pod를 삭제하면 어떻게 되나요? `kubectl delete pod mongo-0 -n pacman`을 실행하면 삭제할 수 있으며, 아직 앱에 있는 경우 적어도 몇 초 동안은 높은 점수를 사용할 수 없는 것을 볼 수 있을 것입니다.
+
+![](/2022/Days/Images/Day55_Kubernetes10.png)
+
+이제 게임으로 돌아가서 새 게임을 만들면 제 높은 점수를 확인할 수 있습니다. 하지만 제 말을 진정으로 믿을 수 있는 유일한 방법은 직접 시도해보고 소셜 미디어에 최고 점수를 공유하는 것입니다!
+
+![](/2022/Days/Images/Day55_Kubernetes11.png)
+
+배포를 통해 이전 세션에서 다룬 커맨드를 사용하여 확장할 수 있지만, 특히 대규모 Pacman 파티를 주최하려는 경우 `kubectl scale deployment pacman --replicas=10 -n pacman`을 사용하여 확장할 수 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes12.png)
+
+### Ingress 설명
+
+Kubernetes에 대해 마무리하기 전에 Kubernetes의 중요한 측면인 Ingress에 대해서도 다루고 싶었습니다.
+
+### Ingress란 무엇인가요?
+
+지금까지 예제에서는 포트 포워드를 사용하거나 Minikube 내에서 특정 명령을 사용하여 애플리케이션에 액세스했지만, 프로덕션 환경에서는 이 방법이 작동하지 않습니다. 여러 사용자가 대규모로 애플리케이션에 액세스할 수 있는 더 나은 방법이 필요할 것입니다.
+
+또한 NodePort가 옵션이라고 말씀드렸지만, 이 역시 테스트 목적으로만 사용해야 합니다.
+
+Ingress는 애플리케이션을 노출하는 더 나은 방법을 제공하며, 이를 통해 Kubernetes 클러스터 내에서 라우팅 규칙을 정의할 수 있습니다.
+
+Ingress의 경우, 애플리케이션의 내부 서비스에 대한 포워드 요청을 생성합니다.
+
+### 언제 Ingress가 필요한가요?
+
+클라우드 제공자를 사용하는 경우, 관리형 Kubernetes 제품에는 클러스터에 대한 Ingress 옵션이 있거나 로드 밸런서 옵션이 제공될 가능성이 높습니다. 이를 직접 구현할 필요가 없다는 것이 관리형 Kubernetes의 장점 중 하나입니다.
+
+클러스터를 실행하는 경우 엔트리포인트를 구성해야 한다.
+
+### Minikube에서 Ingress 구성하기
+
+제가 실행 중인 mc-demo라는 특정 클러스터에서 다음 명령을 실행하여 클러스터에서 Ingress를 활성화할 수 있습니다.
+
+`minikube --profile='mc-demo' addons enable ingress`
+
+![](/2022/Days/Images/Day55_Kubernetes13.png)
+
+이제 네임스페이스를 확인하면 새로운 ingress-nginx 네임스페이스가 있는 것을 볼 수 있습니다. `kubectl get ns`
+
+![](/2022/Days/Images/Day55_Kubernetes14.png)
+
+이제 Pacman 서비스를 실행하기 위해 Ingress YAML 구성을 생성해야 합니다. 이 파일을 리포지토리 [pacman-ingress.yaml](/2022/Days/Kubernetes)에 추가했습니다.
+
+그런 다음 `kubectl create -f pacman-ingress.yaml`을 사용하여 Ingress 네임스페이스에 이 파일을 생성할 수 있습니다.
+
+![](/2022/Days/Images/Day55_Kubernetes15.png)
+
+그런 다음 `kubectl get ingress -n pacman`을 실행하면 다음과 같이 출력됩니다.
+
+![](/2022/Days/Images/Day55_Kubernetes16.png)
+
+그러면 윈도우에서 WSL2에서 실행되는 Minikube를 사용하고 있기 때문에 `minikube tunnel --profile=mc-demo`를 사용하여 Minikube 터널을 생성해야 한다는 메시지가 표시됩니다.
+
+하지만 여전히 192.168.49.2에 액세스하여 Pacman 게임을 플레이할 수 없습니다.
+
+누구든지 Windows 및 WSL에서 이 기능을 사용할 수 있거나 사용할 수 있다면 피드백을 보내 주시면 감사하겠습니다. 리포지토리에 이 문제를 제기하고 시간과 수정 사항이 생기면 다시 돌아오겠습니다.
+
+업데이트: 이 블로그가 WSL에서 작동하지 않는 원인을 파악하는 데 도움이 될 것 같습니다 [Docker 런타임을 사용하여 WSL2에서 Minikube를 실행하도록 Ingress 구성하기](https://hellokube.dev/posts/configure-minikube-ingress-on-wsl2/).
+
+## 자료
+
+사용하신 무료 리소스가 있으시면 리포지토리에 PR을 통해 여기에 추가해 주시면 기꺼이 포함시켜 드리겠습니다.
+
+- [Kubernetes StatefulSet simply explained](https://www.youtube.com/watch?v=pPQKAR1pA9U)
+- [Kubernetes Volumes explained](https://www.youtube.com/watch?v=0swOh5C3OVM)
+- [Kubernetes Ingress Tutorial for Beginners](https://www.youtube.com/watch?v=80Ew_fsV4rM)
+- [Kubernetes Documentation](https://kubernetes.io/docs/home/)
+- [TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]](https://www.youtube.com/watch?v=X48VuDVv0do)
+- [TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners](https://www.youtube.com/watch?v=s_o8dwzRlu4)
+- [Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!](https://www.youtube.com/watch?v=KVBON1lA9N8)
+
+이것으로 Kubernetes 섹션을 마무리합니다. Kubernetes에 대해 다룰 수 있는 추가 콘텐츠는 매우 많으며 7일 동안 기초적인 지식을 얻을 수 있지만, 사람들은 [100DaysOfKubernetes](https://100daysofkubernetes.io/overview.html)를 통해 심도 있게 살펴볼 수 있습니다.
+
+다음 시간에는 IaC(Infrastructure as Code)와 이것이 데브옵스 관점에서 수행하는 중요한 역할에 대해 살펴보겠습니다.
+
+[Day 56](day56.md)에서 봐요!