호두기술블로그

이번 포스트에서는 Docker Desktop을 이용하여 Kubernetes(v1.29.2) 설치 방법을 소개합니다.
설치환경에 따라 설치방법이 다를 수 있으니 참고 부탁드립니다.
 
Docker Desktop 설치는 아래의 포스팅을 참고하시길 바랍니다.
https://dailyhodoo.tistory.com/8

 
설치환경
- Apple M1 MacBook Pro 13 Inch 2020
- MacOS Sonoma
- docker desktop 4.31.0

1. docker desktop 실행 후 Settings 화면 접근

Enable Kubernetes 선택후 Apply & restart 버튼을 클릭합니다.

2. Kubernetes Cluster Installation 진행

Install 버튼을 클릭하여 설치를 진행합니다.

 
Starting... 상태가 지속되며 설치가 진행 됩니다.

3. Kubernetes 설치 완료 후 확인

 
컨트롤 플레인 노드가 정상적으로 설치되었는지 확인합니다. (버전 확인)

kubectl get node

 
이렇게 진행하면 아주 간단한 방법으로 Docker Desktop을 이용하여 Kubernetes 설치가 가능합니다.
 
감사합니다.

이번 포스트에서는 쉽게 컨테이너 환경을 구축할 수 있는 Docker Desktop 설치 방법을 소개합니다.
설치환경에 따라 설치 방법이 다를 수 있으니 참고하시길 바랍니다. 
 
설치 환경
- Apple M1 MacBook Pro 13 Inch 2020
- MacOS Sonoma
 
https://www.docker.com/products/docker-desktop/

1. Docker 공식홈페이지 접속 후 Docker Desktop 설치 버튼 클릭

2. 다운로드 폴더에 있는 Docker.dmg 실행

3. Docker 파일을 Applications 폴더로 drag and drop 

4. 응용 프로그램 폴더에 있는 Docker 파일을 실행

5. Docker Desktop 설치 진행

Accept 버튼을 클릭합니다.

 
 
Use recommended settings 체크 후 Finish 버튼을 클릭합니다.

 
 
현재 접속중인 User의 패스워드를 입력 후 확인을 눌러줍니다.

 
 
가입된 계정이 있으면 계정에 로그인을 해서 접속해도 되고, 로그인 없이 접속 가능합니다.
로그인 없이 진행하는 선택으로 진행하도록 하겠습니다.

 
 
Survey를 진행해줍니다.

 
 
다음과 같은 화면이 보여지면 설치가 완료되었습니다.

 
이렇게 진행하면 아주 간단한 방법으로 Docker Desktop 설치가 가능합니다.
 
다음 포스트에서는 설치된 Docker Desktop를 이용하여 Kubernetes를 설치하는 방법을 포스팅 하도록 하겠습니다.
 
감사합니다.

이번 포스트에서는 zsh를 더 편리하게 사용하게 도와주는 oh-my-zsh 설치 방법을 소개합니다.
설치환경에 따라 설치 방법이 다를 수 있으니 참고하시길 바랍니다. 
 
설치 환경
- Apple M1 MacBook Pro 13 Inch 2020
- MacOS Sonoma
 
설정 변경(추가 설정)
1) ZSH_THEME 설정 변경
2) ZSH_THEME 설정 변경 이후 컴퓨터명 제거
3) ZSH_THEME 설정 변경 이후 물음표 제거 (폰트 설치 후 변경 필요)
 

1. oh-my-zsh 공식 홈페이지 접속 후 Install 

https://ohmyz.sh/

 
Install oh-my-zsh 버튼을 클릭합니다

 
Install -h-my-zsh via curl 에 있는 스크립트를 복사하여 터미널 창에서 실행합니다.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

 
복사한 스크립트를 실행을 하면 정상적으로 설치가 완료됩니다.

1) ZSH_THEME 변경

vi 에디터를 이용하여 ZSH_THEME에 "agnoster" 추가 후 저장합니다.

vi ./~zshrc

#ZSH_THEME="robbyrussell"
ZSH_THEME="agnoster"

수정 후 wq 또는 wq! 입력 후 저장합니다.

source ./~zshrc

수정 된 내용을 적용 합니다.
 

 
Mac의 화면모드가 라이트 모드인 상태에서 ZSH_THEME를 "agnoster"로 변경하게 되면 위와 같은 상태가 보여지는데, Mac의 화면모드 설정을 다크모드로 변경하면 아래와 같이 변경하실 수 있습니다.

2) ZSH THEME 설정 이후 컴퓨터명 제거

vi 에디터를 이용하여 ./~zshrc 파일 수정모드에 진입합니다.

vi ./~zshrc

vi 에디터를 이용하여 ./~zshrc 파일에 아래의 내용을 맨 아래에 추가 후 수정 및 저장합니다.

prompt_context() {
  prompt_segment black default "$USER "
}

수정 후 esc, wq 또는 wq! 입력 후 저장합니다.

source ./~zshrc

수정 된 내용을 적용하게 되면 컴퓨터명이 사라지게 됩니다.

3) ZSH THEME 설정 이후 물음표 제거

물음표를 제거하기 위해서는 font 변경이 필요합니다. git clone 명령어를 통해 git에서 font를 다운받습니다.
https://github.com/powerline/fonts

git clone https://github.com/powerline/fonts.git --depth=1

cd fonts

 
fonts 폴더에 접근하여 ./install.sh 을 입력해 실행해주면 fonts 설치가 진행됩니다.

 
아래와 같이 진행되면 정상 설치가 완료되었습니다.

 
왼쪽 상단의 iTerm2 -> Settings... -> Profiles -> Text에 접근하여 Font를 수정해 줍니다.

이렇게 진행하면 아주 간단한 방법으로 oh-my-zsh 환경의 셋팅이 완료됩니다.
 
다음 포스트에서는 Mac 환경에서 Docker Desktop을 설치하는 방법을 포스팅 하도록 하겠습니다.
 
감사합니다.

이번 포스트에서는 맥환경에서 가장 많이 사용하는 Homebrew 패키지 매니저 설치 방법을 소개합니다.
설치환경에 따라 설치 방법이 다를 수 있으니 참고하시길 바랍니다. 
 
설치 환경
- Apple M1 MacBook Pro 13 Inch 2020
- MacOS Sonoma
 

1. Homebrew 공식홈페이지 접속 후 설치 스크립트 복사

https://brew.sh/

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. 복사 된 스크립트를 iTerm2에서 붙여넣기

3. Homebrew 설치 진행

현재 접속한 User의 패스워드 입력 후 Enter를 입력합니다.

 
아래와 같은 상태가 보여지면 Enter를 입력하면 계속 진행 됩니다

 
아래와 같은 상태가 보여지면 Command Line Tools for Xcode 설치가 자동 진행 됩니다.
시간이 어느정도 소요되니 기다리시면 됩니다.

4. Homebrew 설치 완료

5. Homebrew 버전 확인

위에 보여지는 캡처 화면에서 Next steps에서 보여지는 스크립트를 복사하여 붙여주고,
아래와 같이 Homebrew 버전 확인 명령어 실행하여 통해 정상설치를 확인 할 수 있습니다.

brew --version

 
이렇게 진행하면 아주 간단한 방법으로 Homebrew 설치가 가능합니다.
 
다음 포스트에서는 앞서 설치한 iTerm2와 Homebrew를 이용하여, 멋지고 깔끔한 터미널 창을 만들어주는 oh-my-zsh 설 설치하는 방법을 포스팅하도록 하겠습니다.
 
감사합니다.
 
 
 

이번 포스트에서는 맥환경에서 가장 많이 사용하는 터미널 앱인 iTerm2 설치 방법을 소개합니다.
설치환경에 따라 설치 방법이 다를 수 있으니 참고하시길 바랍니다. 
 
설치 환경
- Apple M1 MacBook Pro 13 Inch 2020
- MacOS Sonoma
 

1. iTerm2 공식홈페이지 접속 후 Download 버튼 클릭 

http://iterm2.com

2. 다운로드 받은 zip 파일을 실행

3. 설치완료 된 iTerm2를 실행

설치된 파일은 응용 프로그램 폴더에 설치 되어있습니다.

 
이렇게 진행하면 아주 간단한 방법으로 iTerm2 설치가 가능합니다.
 
다음 포스트에서는 Mac 환경에서 아주 편리하게 사용할 수 있는 Homebrew 패키지매니저 설치하는 방법을 포스팅 하도록 하겠습니다.
 
감사합니다.

상태 코드:

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

- 1xx (Informational): 요청이 수신되어 처리중임.

- 2xx (Successful): 요청이 정상 처리됨.

- 3xx (Redirection): 요청을 완료하려면 추가적인 행동이 필요.

- 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음.

- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함.

1xx (Informational) - 거의 사용하지 않음.

100 Continue

 - 이 임시적인 응답은 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줍니다.

101 Switching Protocols

- 이 코드는 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려줍니다.

103 Early Hints

- 이 상태 코드는 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.

2xx (Successful) - 클라이언트의 요청을 성공적으로 처리.

200 OK

- 요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라집니다:
GET: 리소스를 불러와서 메시지 바디에 전송되었습니다.
HEAD: 개체 해더가 메시지 바디에 있습니다.
PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었습니다.
TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있습니다.

201 Created

- 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.

202 Accepted

- 요청을 수신하였지만 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.

203 Non-Authoritative Information

- 이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선됩니다.

204 No Content

- 요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.

205 Reset Content

- 이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.

206 Partial Content

- 이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다.

3xx (Redirection) - 리다이렉션

300 Multiple Choices

- 요청에 대해서 하나 이상의 응답이 가능합니다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.

301 Moved Permanently

- 이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미합니다. 새로운 URI가 응답에서 아마도 주어질 수 있습니다.

302 Found

- 이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다. 새롭게 변경된 URI는 나중에 만들어질 수 있습니다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야합니다.

303 See Other

- 클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답입니다.

304 Not Modified

- 이것은 캐시를 목적으로 사용됩니다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.

307 Temporary Redirect

- 클라리언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야할 때, 서버가 클라이언트에 이 응답을 직접 보냅니다. 이것은 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

308 Permanent Redirect

- 이것은 리소스가 이제 HTTP 응답 헤더의 Location: 에 명시된 영구히 다른 URI에 위치하고 있음을 의미합니다. 이것은 301 Moved Permanently HTTP 응답 코드와 동일한  의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다: 만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

4xx (Client Error) - 클라이언트 오류

400 Bad Request

- 이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.

401 Unauthorized

- 비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.

402 Payment Required

- 클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.

403 Forbidden

- 클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.

404 Not Found

- 서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.

405 Method Not Allowed

- 요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다. 필수적인 메소드인 GET과 HEAD는 제거될 수 없으며 이 에러 코드를 리턴할 수 없습니다.

406 Not Acceptable

- 이 응답은 서버가 서버 주도 콘텐츠 협상 을 수행한 이후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때, 웹서버가 보냅니다.

407 Proxy Authentication Required

- 이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.

408 Request Timeout

- 이 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미합니다. 이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데, Chrome, Firefox 27+, 또는 IE9와 같은 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다. 또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.

409 Conflict

- 이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.

410 Gone

- 이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대합니다. HTTP 기술 사양은 이 상태 코드가 "일시적인, 홍보용 서비스"에 사용되기를 기대합니다. API는 알려진 리소스가 이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.

411 Length Required

- 서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.

412 Precondition Failed

- 클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.

413 Payload Too Large

- 요청 엔티티는 서버에서 정의한 한계보다 큽니다; 서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려보낼 것이다.

414 URI Too Long

- 클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.

415 Unsupported Media Type

- 요청한 미디어 포맷은 서버에서 지원하지 않습니다, 서버는 해당 요청을 거절할 것입니다.

416 Range Not Satisfiable

- Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다; 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.

417 Expectation Failed

- 이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.

418 I'm a teapot

- 서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.

422 Unprocessable Entity

- 요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.

425 Too Early

-

426 Upgrade Required

- 서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 Upgrade (en-US) 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.

428 Precondition Required

- 오리진 서버는 요청이 조건적이어야 합니다. 클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 '업데이트 상실'을 예방하기 위한 목적입니다.

429 Too Many Requests

- 사용자가 지정된 시간에 너무 많은 요청을 보냈습니다("rate limiting").

431 Request Header Fields Too Large

- 요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다. 요청은 크기를 줄인 다음에 다시 전송해야 합니다.

451 Unavailable For Legal Reasons

- 사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스입니다.

5xx (Server Error) - 서버 오류

500 Internal Server Error

- 서버가 처리 방법을 모르는 상황이 발생했습니다. 서버는 아직 처리 방법을 알 수 없습니다.

501 Not Implemented

- 요청 방법은 서버에서 지원되지 않으므로 처리할 수 없습니다. 서버가 지원해야 하는 유일한 방법은 GET와 HEAD이다. 이 코드는 반환하면 안됩니다.

502 Bad Gateway

- 이 오류 응답은 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미합니다.

503 Service Unavailable

- 서버가 요청을 처리할 준비가 되지 않았습니다. 일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸렸을 때 입니다. 이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 한다는 점에 유의하십시오. 이 응답은 임시 조건에 사용되어야 하며, Retry-After: HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 합니다. 웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하므로 이 응답과 함께 전송되는 캐싱 관련 헤더에 대해서도 주의해야 합니다.

504 Gateway Timeout

- 이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어집니다.

505 HTTP Version Not Supported

- 요청에 사용된 HTTP 버전은 서버에서 지원되지 않습니다.

506 Variant Also Negotiates

- 서버에 내부 구성 오류가 있다. 즉, 요청을 위한 투명한 컨텐츠 협상이 순환 참조로 이어진다.

507 Insufficient Storage

- 서버에 내부 구성 오류가 있다. 즉, 선택한 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 프로세스의 적절한 종료 지점이 아닙니다.

508 Loop Detected

- 서버가 요청을 처리하는 동안 무한 루프를 감지했습니다.

510 Not Extended

- 서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.

511 Network Authentication Required

- 클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음을 나타냅니다.

참고

MDN Web Docs-https://developer.mozilla.org/ko/docs/Web/HTTP/Status