Docker 가 보편화 되기 이전에는 개발 환경 셋팅에 정말 많은 공수가 필요 했습니다.

하지만 Docker는 애플리케이션과 그 의존성을 컨테이너로 패키징하여 독립성과 경량화 장점을 갖고 있습니다.

물론 빠른 배포, 빠른 스케일링 장점도 있지만 우선 Docker 환경에서 컨테이너를 올려보겠습니다

 

그러면 mysql 컨테이너를 만들어보겠습니다.

 

어떻게 Docker 환경에서 mysql 컨테이너를 생성할 수 있을까요?

우선 컨테이너의 생성을 위한 순서는 아래와 같습니다.

1. docker-compose.yml 파일 생성

2. Dockerfile 생성

3. docker-compose up 명령어 실행

    - 1) Dockerfile 정의 내용을 기반으로 이미지 빌드

    - 2) 이미지를 사용하여 컨테이너 생성 및 실행

4. 생성 컨테이너 확인

 

위의 순서에 맞게 하나씩 진행 해보겠습니다.

 

(그림. 프로젝트 디렉토리)

 

1. 프로젝트 최상위 디렉토리에 docker 디렉토리 및 docker-compose.yml 파일 생성 (그림. 프로젝트 디렉토리)

  • 저는 스프링 부트 프로젝트 입니다.
version: '1'

services:
  mysql:
    build:
      dockerfile: mysql/Dockerfile
    container_name: mysql
    environment:
      MYSQL_ROOT_PASSWORD: 1234
    ports:
      - "3306:3306"
  • service:mysql:builder:dockerfile 에 Dockerfile 경로를 입력 해주세요(mysql/Dockerfile)

 

2. docker 디렉토리에 mysql 디렉토리 및 Dockerfile 생성 (그림. 프로젝트 디렉토리)

# 베이스 이미지 설정
FROM mysql:latest
  • Dockerfile 사용 예시를 공유하기 위해 베이스 이미지 설정만 추가 했습니다.

 

3. 프로젝트 docker 디렉토리 이동 및 docker 실행

docker-compose up -d
  • -d 옵션은 컨테이너를 백그라운드에서 실행하고 터미널 사용 제어권을 반환하는 역할을 합니다.

 

 

4. mysql 컨테이너 확인

docker exec -it mysql mysql -uroot -p
  • 해당 명령어 입력 후 비밀번호 입력 프롬프트가 표시됩니다. 이때 docker-compose.yml 에 설정한 비밀번호를 입력해주세요.

 

이렇게 Docker 환경에서 mysql 컨테이너 생성 예제가 완료 되었습니다.

 

 

컨테이너의 환경 설정을 docker-compose.yml 파일에 할지, Dockerfile에 할지 정확한 답은 없습니다.

만약 고민이 되신다면 아래 포스트를 참고 해주세요.

https://gabrielyj.tistory.com/225

 

컨테이너의 환경설정 docker-compose.yml 이랑 Dockerfile 중 어디가 적합하지?

Docker 컨테이너 생성 시 환경설정을 어디에 할지 고민이 될 수 있습니다.

이럴 때에는 장/단점을 따져보고 결정하는게 맞을 것 같습니다.

 

 

docker-compose.yml 환경설정

[장점]

  • docker-compose.yml 파일은 여러 컨테이너 및 서비스를 정의하고 관리하기가 편리합니다.
  • 컨테이너 간의 의존성을 쉽게 정의하고 관리할 수 있습니다.
  • 환경 설정을 외부화하여 수정 및 유지 관리가 용이합니다.

[단점]

  • 컨테이너에 대한 상세한 설정을 docker-compose.yml 파일에 직접 작성해야 합니다.
  • 복잡한 설정을 다루기에는 docker-compose.yml 파일이 적합하지 않을 수 있습니다.

 

 

Dockerfile 환경설정

[장점]

  • Dockerfile을 사용하여 컨테이너의 이미지를 빌드할 때 더 많은 제어권을 가질 수 있습니다.
  • 구체적인 설정을 Dockerfile 내에서 관리하고 변경할 수 있습니다.

[단점]

  • Dockerfile을 직접 작성하고 관리해야 하므로 일부 개발자들에게는 복잡할 수 있습니다.
  • 다른 컨테이너 서비스와의 의존성을 정의하고 관리하기가 어려울 있습니다.

 

 

그래서 어떻게 하지?

  • 일반적으로 단일 컨테이너를 실행하는 경우에는 docker-compose.yml 파일을 사용하는 것이 더 효율적일 수 있습니다.
  • 복잡한 환경에서 컨테이너 간의 복잡한 의존성이 있거나, 세부적인 커스터마이징이 필요할 경우 Dockerfile을 사용하는 것이 효율적일 수 있습니다.

Dockerfile와 docker-compose.yml 파일의 차이

도커를 생성하셨으면 이제 실제 애플리케이션을 컨테이너화 해야됩니다.

이때 사용되는 파일은 Dockerfile 과 docker-compose.yml 파일입니다.

두 파일 모두 컨테이너화를 위해 사용되는데 서로 다른 목적과 사용 사례를 갖고 있습니다.

 

Dockerfile 이란?

  • 개별 컨테이너 정의 : 단일 도커 이미지를 정의하는데 사용됩니다. 이미지는 컨테이너를 시작하는데 사용되는 템플릿입니다.
  • 컨테이너 빌드 지시사항 : 컨테이너를 빌드하기 위한 지시사항을 포함합니다. 기본 이미지, 작업 디렉토리, 파일 복사, 환경 변수 설정 등을 포함합니다.
  • 단일 서비스 정의 : 사용하면 하나의 서비스 또는 애플리케이션의 컨테이너를 정의합니다. 보통 하나의 Dockerfile은 하나의 애플리케이션을 컨테이너화하기 위해 사용됩니다.

docker-compose.yml 이란?

  • 다중 컨테이너 애플리케이션 정의 : 파일은 다중 컨테이너 애플리케이션의 전체 구성을 정의하는 데 사용됩니다. 여러 서비스 또는 컨테이너를 함께 실행하고 관리할 때 유용합니다.
  • 서비스 간 의존성 관리 : 서비스 간의 읜존성과 상호 작용을 정의합니다. 이를 통해 여러 컨테이너를 함께 시작하고 관리할 수 있습니다.
  • 환경 설정 및 네트워크 구성 : 각 서비스의 환경 변수, 포트 맵핑, 불륨 마운트, 서비스 간의 네트워크 구성 정의 등을 설정할 수 있습니다.

 

그래서 Dockerfile 이랑 docker-compose.yml 파일의 차이가 뭐야?

  • docker-compose.yml 을 통해 다중 컨테이너 애플리케이션을 정의합니다.
  • docker-compose.yml 을 통해 생성되는 컨테이너의 설정은 Dockerfile을 통해 이루어집니다.

즉, docker-compose.yml 을 통해 전체적인 애플리케이션 컨테이너를 생성하고 각 컨테이너의 세부 설정은 Dockerfile을 사용합니다.

 

 

[docker-compose.yml 파일과 각 dockerfile 경로]

docker-compose.yml 의 위치는 1depth 로써, 각 컨테이너(mysql, rabbitmq, kafka) 의 경로에 dockerfile 이 존재합니다.

1depth/
│
└── docker-compose.yml
│
├── mysql/
│   └── Dockerfile_mysql
│
├── rabbitmq/
│   └── Dockerfile_rabbitmq
│
└── kafka/
    └── Dockerfile_kafka

 

 

[docker-compose.yml 예시]

version: '3'  # Docker Compose 파일의 버전 지정

services:  # 각 서비스를 정의합니다.
  mysql:  # 서비스 이름
    image: mysql:latest  # 사용할 도커 이미지
    container_name: mysql-container  # 컨테이너 이름
    environment:  # 환경 변수 설정
      MYSQL_ROOT_PASSWORD: <password>  # MySQL 루트 비밀번호 설정
    ports:  # 포트 매핑
      - "3306:3306"  # 호스트와 컨테이너의 포트를 매핑

  rabbitmq:
    image: rabbitmq:latest
    container_name: rabbitmq-container
    ports:
      - "5672:5672"
      - "15672:15672"

  kafka:
    image: wurstmeister/kafka:latest
    container_name: kafka-container
    ports:
      - "9092:9092"

 

 

결론

  1. docker-compose.yml 을 통해 애플리케이션 컨테이너화를 합니다.
  2. 각 애플리케이션 컨테이너 경로의 dockerfile을 통해 설정을 합니다.

Docker 설치 방법 in Mac OS

1. Docker 공식 홈페이지로 이동합니다.

 

2. Mac OS 칩셋 선택

M1, M2, M3.. 계열을 구매한 사용자라면 'Apple Silicon' 을 선택하시고,

intel 계열을 구매한 사용자라면 'Intel chip'를 선택해주세요.

 

 

3. 다운로드 받은 Docker dmg 파일 실행 및 설치

 

 

4. Docker 실행 및 정상 설치 확인

 

 

 

사용자 인증 환경에서 쿠키(cookies)란 ?

  • 사용자 인증에서 쿠키는 웹 브라우저에 저장되는 작은 데이터 조각입니다.
  • 서버에서 웹 브라우저로 전송되어 클라이언트의 PC에 저장됩니다.
  • 클라이언트가 웹 서핑이나 API 를 요청할 때 사용자 식별 및 상태 추적을 위해 사용됩니다.

 

사용자 인증 환경에서 쿠키의 생명주기는 어떻게 될까요?

  • 사용자 로그인 : 아이디와 비밀번호 입력 후 서버 요청(HTTP REQUEST)
  • 서버 인증 : 아이디와 비밀번호를 확인하여 유효한 사용자인지 확인 후 사용자를 식별하는 고유한 세션 식별자를 생성
  • 쿠키 생성 : 생성된 세션 식별자를 쿠키에 저장하고, 이 쿠키를 에 담아 클라이언트에 응답(HTTP RESPONSE)
  • 사용자 요청 시 쿠키 전송 : 클라이언트가 서비스에 새로운 요청을 할 때마다 쿠키를 서버에 함께 요청
    • 서버에서 세션 식별자를 통해 유효성을 검증 합니다.
  • 세션 유지 및 로그아웃 : 클라이언트가 활동하는 동안 세션을 유지하고, 로그아웃을 하거나 세션이 만료되었을 경우에는 쿠키를 무효화하고 다시 인증하는 로직을 수행

 

사용자 인증 환경에서 쿠키를 아직 사용하나요?

  • MSA가 보편화된 시점에서 서버는 stateless(상태 없음, 무상태)를 지향합니다. 아니 필수라고 할 수 있습니다. 이럴경우 하나의 서버에서 사용자 인증 세션을 관리하기 어렵습니다. 그렇기 때문에 쿠키-세션 방식은 현재 많이 사용되고 있지 않습니다.
  • 하지만, JWT 토큰을 쿠키에 저장하는 방법은 사용되고 있는데 이 부분은 다음 포스트에서 공유 드리겠습니다.

HTTP 와 HTTPS 의 차이를 묻는 질문 빈도는 면접 외에도 정말 자주 있는것 같습니다.

그러면 HTTP 의 기초부터 HTTPS 까지 폭 넓게 알아가보도록 하겠습니다.

HTTP란?

HTTP(Hypertext Transfer Protocol) 은 인터넷을 통해 정보를 전송하는데 사용되는 프로토콜입니다.

또한 HTTP는 상태가 없는 프로토콜 입니다. 클라이언트와 서버 간의 각 요청이 서로 독립적으로 처리되며, 이전 요청과 상태에 대한 정보를 유지하지 않는다는 것을 의미합니다. 

저희는 이것을 무상태성(Stateless) 이라고 표현합니다.

  • HTTP 의 특징 
    • 데이터를 암호화하지 않고 평문으로 전송하여 보안성 보장이 안됨 (데이터 도청 및 노출 위험이 있음)
    • 기본적으로 80포트를 사용
    • TCP/IP 프로토콜 스택 위에서 동작, TCP 의 여러 특성(연결 지향성, 신뢰성, 흐름 제어 등)을 사용
    • 요청-응답 구조 : 클라이언트가 서버에 요청을 보내고, 서버는 요청 처리을 처리 후 응답하는 구조
    • 메서드 사용 : GET, POST, PUT, DELETE 등

이러한 HTTP 의 특징은 HTTPS 에서도 동일하게 사용됩니다. 

 

HTTPS란?

HTTPS(Hypertext Transfer Protocol Secure) 도 인터넷을 통해 정보를 전송하는 프로토콜입니다.

HTTP 와의 차이점은 이름에서 알 수 있듯이 '보안'과 '암호화' 입니다.

 

  • HTTPS의 특징
    • SSL 또는 TLS 프로토콜을 사용하여 데이터를 암호화. 데이터를 안전하게 전송하여 도청이나 데이터 변조를 방지
    • 기본적으로 443 포트를 사용
    • SSL, TLS 프로토콜을 사용하기 위해 서버의 신원을 인정하는 '인증서'를 요구함. 이를 통해 클라이언트에 서버가 신뢰할 수 있는지 여부를 확인할 수 있음
    • SEO(Search Engine Optimization) : HTTPS를 사용하는 웹사이트는 HTTP를 사용하는 웹사이트보다 더 안전하기 때문에, 검색 엔진에서 더 높은 순위를 받을 수 있음. 즉, 검색 엔진 최적화의 필수 요소
    • 쿠키와 세션을 사용하여 데이터가 안전하게 전송되므로 중간자 공격으로부터 보호됨

 

그럼 결론은?

HTTPS는 HTTP 의 보안 강화 버전으로 생각하시면 됩니다. 전송되는 데이터의 기밀성과 무결성을 보호하는데 사용되며 보안성이 HTTP보다 높습니다.

현재 클라이언트에게 제공 중인 서비스 중 HTTP 를 사용하는건 거의 본적이 없습니다. 만약 HTTP 만 사용하면 chrome, safari 같은 브라우저에서 경고가 뜨거나 접근할 수 없습니다. 그리고 앱스토어 심사에서 불합격할 수 있는 요소입니다.

물론 MSA 구축 시 서버 내부 통신은 http 만 사용할 수 있습니다.

REST API 와 RESTful API 차이는 그냥 부모, 자식 간의 관계인듯 하다

이번에 동료 개발자들과 점심을 먹던 중 사소한 주제에 대한 토론(?)이 있었습니다.

바로 REST API 와 RESTful API 입니다.

사실 저도 REST API 나 RESTful API 모두 동일하다 생각하고 있었습니다.

하지만 엄밀히 말하면 동일한 개념은 아니며, 그 차이점을 설명할 수 있어야 된단 생각이 들어 포스팅합니다 :)

 

REST API 란?

REST API 란 Representational State Transfer API의 약자로, 분산 시스템(ex. MSA)간의 자원을 표현하고 전달하기 위한 아키텍처 스타일입니다.

  • REST API 특징
    • 자원(URI) : 서비스의 모든 것을 나타내는 개념. (ex. 주문, 결제, 회원 등)
    • 표현(Representation) : json, xml 등 다양한 형식으로 표현 가능
    • 상태(State) : HTTP 응답 상태 코드(2xx[성공], 3xx[리다이렉트], 4xx[클라이언트 에러], 5xx[서버 에러])
    • 표준화된 인터페이스(Uniform Interface) : HTTP 요청 메소드(GET, POST, PUT, DELETE)

정리하자면, REST API 는 자원, 표현, 상태, 표준 인터페이스를 통해 클라이언트와 서버 간의 통신을 구현하는 아키텍처 입니다.

즉 REST API 는 REST 아키텍처 스타일을 따르는 API를 의미합니다.

 

  • REST API 원칙
    • 클라이언트/서버 구조 : 클라이언트와 서버는 독립적으로 구성되어 있습니다.
    • 무상태성(Stateless) : 서버가 클라이언트의 상태를 유지하지 않고 각 요청을 완전히 독립적으로 처리하는 방식입니다. 즉, 서버는 클라이언트의 이전 요청이나 상태에 대해 알지 못하며, 
    • 캐시 처리 가능(Cacheable) : 서버 응답 시간 개선을 위해 캐시를 처리할 수 있습니다.
    • 계층화 시스템(Layered System) : 클라이언트와 서버 사이에 여러 개의 중간 계층(레이어)을 두고 통신하는 방식입니다. 시스템의 확장성, 보안성, 성능 등을 향상시킵니다.
    • 인터페이스 일관성(Uniform Interface) : 위의 REST API 의 특징 참고
    • 자기 서술적 메시지(Self-descriptive Messages) : 위의 REST API 의 특징 참고

 

RESTful API란?

RESTful API 는 REST API 아케텍처를 적용하여 설계된 API를 의미합니다. REST API 를 상속 했다고 보시면 될 것 같습니다.

 

그렇다면 차이점은?

* 원칙이나 특징은 똑같습니다. 하지만 RESTful API 는 REST API 아키텍처 기반으로 좀 더 구체적으로 설계되었고, 더 엄격하게 REST API 를 따른다고 말할 수 있습니다.

 

Homebrew 란?

Homebrew는 macOS 및 Linux 운영 체제에서 소프트웨어 패키지를 설치하고 관리하는 오픈 소스 패키지 관리자 입니다.

  • 커맨드 라인 인터페이스를 통해 간편하게 소프트웨어 설치 가능
  • 간편한 패키지 관리 및 업데이트
  • maxOS 용으로 개발 되었지만 Linux 용 포트도 존재

즉, 터미널에서 명령어를 통해 프로그램을 설치할 수 있기 때문에 mac 사용자 사이에서는 필수 프로그램으로 여겨집니다.

 

Homebrew

The Missing Package Manager for macOS (or Linux).

brew.sh

 

 

 

Homebrew 설치 방법

1. Terminal 실행

 

2. 설치 명령어 실행(아래 명령어를 복붙 합니다.)

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

 

 

 

3. 설치 확인

brew --version

 

Homebrew 가 정상적으로 설치되었으면 brew 명령어를 통해 버전 확인을 할 수 있습니다.

 

 

* 만약 설치 시 Warning: /opt/homebrew/bin is not in your PATH 에러가 발생하면 아래 링크를 확인 해주세요.

https://gabrielyj.tistory.com/217

 

[mac os] brew 설치 중 Warning: /opt/homebrew/bin is not in your PATH. 오류 발생

mac os 에서 Homebrew 설치 시 발생하는 PATH 문제 해결 ==> Updating Homebrew... Warning: /opt/homebrew/bin is not in your PATH. Instructions on how to configure your shell for Homebrew can be found in the 'Next steps' section below. 문제 해

gabrielyj.tistory.com

 

 

git 란?

git은 분산 버전 관리 시스템입니다.

  • 소스 코드의 변경 이력 관리 - 어떤 변경이 있었는지 쉽게 확인 가능하며 필요한 경우 이전 버전으로 돌아갈 수 있음
  • 협업 - 여러 개발자가 동시에 작업할 수 있음.
  • 브랜치 관리 - 개별 브랜치 개발을 통해 병렬 개발 가능
  • 히스토리 관리 : 코드 변경에 대한 히스토리 확인이 가능

 

1. Terminal 실행

 

2. git 설치 명령어 실행

brew install git

* brew command 는 homebrew 가 설치되어 있어야 사용 가능 합니다. 설치가 필요하시면 아래 글을 참조 해주세요.

https://gabrielyj.tistory.com/218

 

3. git 설치 버전 확인

git --version

 

 

 

mac os 에서 Homebrew 설치 시 발생하는 PATH 문제 해결

==> Updating Homebrew...
Warning: /opt/homebrew/bin is not in your PATH.
  Instructions on how to configure your shell for Homebrew
  can be found in the 'Next steps' section below.

 

 

문제 해결 방법

발생된 에러 '/opt/homebrew/bin is not in your PATH' 는 해당 경로 등록함으로 쉽게 해결할 수 있습니다.

 

1. 터미널에서 아래 명령어를 실행합니다.

echo 'export PATH=/opt/homebrew/bin:$PATH' >> ~/.zshrc

 

2. 확인 (생략 가능)

vi ./.zshrc

 

3.  명령어 실행으로 zshrc 쉘 환경을 재로드

source ~/.zshrc

 

 

4. brew 버전 확인

brew --version

+ Recent posts