반응형

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

반응형
반응형

·스프링 배치(Spring Batch)는 대용량 처리와 반복적인 작업을 수행하는데 사용되는 자바 및 스프링 기반으로 프레임워크입니다.

 

🤔 스프링 배치를 사용하는 이유는 무엇일까요?

1. 대용량 데이터 처리 : 스프링 배치는 대용량 데이터 처리에 특화되어 있습니다. 대용량 데이터를 일괄적으로 읽고(Read), 처리(Process), 쓰기(Write)가 가능합니다.

👉 처리와 쓰기에는 데이터 가공 로직이 포함될 수 있습니다.

2. 반복 작업 자동화 : 스프링 배치는 주기적으로 실행되는 반복적인 작업을 자동화할 수 있습니다. 

3. 트랜잭션 : 스프링 배치는 트랜잭션 관리를 지원하기 때문에 안정적인 데이터 처리를 보장할 수 있습니다. 장애 발생 및 프로그램 중단 상황에서도 작업의 일관성을 유지할 수 있습니다.

4. 장애 복구 : 스프링 배치는 장애 및 프로그램 중단 이후 실패한 작업(Job)을 재시작할 수 있는 기능을 제공합니다. 이를 통해 시스템의 안정성을 향상시킬 수 있습니다.

5. 모니터링 및 관리 : 스프링 배치는 작업의 모니터링 및 관리를 위한 다양한 기능을 제공하고 있습니다.

 

 

🤔 스프링 배치의 대표 작업 3가지

  • Read : 데이터를 읽어오는 작업을 수행합니다. 외부시스템(데이터베이스, 파일, 큐 등)에서 데이터를 읽어옵니다.
    • FlatFileItemReader : 텍스트 파일을 읽으며, 각 라인은 하나의 아이템으로 처리됩니다.
    • JdbcCursorItemReader : JDBC를 사용해서 DB 데이터를 읽으며. 커서를 이용하므로 대용량 데이터 처리에 적합합니다.
    • JpaPagingItemReader : JPA를 사용해서 DB 데이터를 읽으며, 페이징을 사용하여 대용량 데이터를 효율적으로 처리할 수 있습니다.
    • JmsItemRader : JMS(Java Message Service)를 사용하여 메시지 큐에서 데이터를 읽어오며, 메시지 큐에 들어있는 메시지를 하나씩 읽어올 수 있습니다.
    • IteemReaderAdapter : 사용자 정의 Reader를 스프링 배치의 ItemReader 인터페이스와 연결해주는 어댑터 입니다. 기존 Reader를 재사용할 때 유용합니다.
    • StoredProcedureItemReader : 저장 프로시저를 사용하여 DB 데이터를 읽어옵니다.
    • MultiResourceitemReader : 여러 개의 리소스(파일 등)에서 데이터를 읽어옵니다.
  • Process : 읽어온 데이터를 가공하거나 변환합니다.
  • Writer : 가공된 데이터를 쓰거나 저장합니다. 이 단계에서는 DB 테이블에 데이터를 저장하거나, 파일로 출력하거나, 메시지를 저장하는 등의 작업을 수행합니다. 
    • JdbcBatchItemWriter : JDBC를 사용하여 데이터를 DB에 저장합니다.
    • FlatFileItemWriter : 텍스트 파일에 데이터를 쓰는 Writer 입니다. CSV, XML, JSON 등 다양한 형식의 파일을 생성할 수 있습니다.
    • JpaItemWriter : JPA를 사용하여 DB에 저장합니다.
    • CompositeItemWriter : 여러 개의 Writer를 조합하여 사용할 수 있습니다. 
    • MultiResourceItemWriter : 여러 개의 리소스(파일 등)를 사용할 수 있습니다.
    • ItemWriterAdapter : 사용자 정의 Writer를 스프링 배치의 ItemWriter 인터페이스와 연결해주는 어댑터입니다.

 

 

🤔 스프링 배치의 아키텍처

 

 

  • Application : 이 모듈은 스프링 배치 어플리캐이션이라고도 하며 스프링 프레임워크를 기반으로 하는 배치 어플리케이션을 개발하는데 필요한 기능들을 제공합니다. 이 모듈은 배치 작업의 구성, 실행, 모니터링, 관리 등의 기능을 제공합니다.
  • Batch Core : 이 모듈은 스프링 배치의 핵심 기능을 제공합니다. 이 모듈은 배치 작업의 실행 흐름을 관리하고, 각 단계(Read, Process, Write) 등의 구현체를 포함하고 있습니다. 이를 사용하여 실제 데이터 처리를 수행합니다. 그리고 배치 작업의 잡(Step), 잡 인스턴스(Job Instance), 스텝(Step) 등의 개념을 정의하고 이를 실행하며, 트랜잭션 관리와 예외 처리 등의 기능도 포함합니다.
  • Batch Infrastructure : 이 모듈은 스프링 배치 기반 인프라스트럭처를 제공합니다. Reader, Processor, Writer 등의 구현체를 포함하고 있으며, 이를 사용해서 실제 데이터 처리를 수행합니다. 또한 트랜잭션 관리, 데이터 엑세스, 메시지 등의 기능도 제공합니다.

 

 

반응형
반응형

 

안녕하세요. 대학원 신입생 모집 기간을 맞아 제가 졸업한 단국대학원에 대해 공유 드립니다.
저는 정보융합기술·창업대학원 IT컨버전스학과 졸업생 입니다.

(2021년 후기 입학 및 2023년 7월 졸업)

 

# 제가 왜 대학원 진학을 결정했는지 말씀 드립니다.

1. 최종 학력 갱신
2. 휴먼 네트워크
3. 논문 작성
4. 전공 추가 학습
최종 학력을 갱신함으로써 자신감을 얻었고 앞으로 인생에 더 많은 기회를 얻을 수 있을거라 생각합니다. 또한 개발자로 재직 중인 상태에서 더 다양한 IT 실무자와 다른 분야의 실무자를 많이 만날 수 있었습니다. 그리고 논문을 작성함으로써(피똥 쌌지만..) 인생의 버킷 리스트도 달성했습니다. 물론 관련 공부도 많이 했습니다.
 

# 왜 단국대학교를 선택했는지 말씀드립니다.

1. 토요일 수업 진행
 - 대부분의 대학원은 평일 2~3회 수업이 진행됩니다. 하지만 단국대학원은 주말에 3교시를 몰아서 수강하기 때문에 업무에 지장 받지 않는 장점이 있습니다.
2. 4학기 졸업
 - 대부분의 대학원은 5학기 과정으로 진행됩니다. 한 학기 빨리 졸업할 수 있는 장점이 있습니다.
3. 등록금 지원
 - 일반 기업 재직(20%) 와 추가 장학금(20%) 총 40%의 학비를 지원받을 수 있습니다. 한 학기 약 600만원 의 등록금 중 240만 원 가까운 금액을 지원받을 수 있고 졸업까지 최대 2000만 원의 학비만 납부하는 장점이 있습니다.
4. 가까운 거리와 교통
 - 단국대학교는 경기도 용인시 수지구에 있습니다. 죽전역과 가까우며 학교 내부에 버스 종점이 있기 때문에 접근성이 매우 좋습니다.
 - 저는 대부분 자차를 이용했는데 주차장도 넉넉하고 주차 비용도 합리적입니다. (한 학기 주말 정기권 3~4만 원 or 일일 4천 원)
5. 젊어지는 연령대
 - 대학원 학생들은 기업 사장님들이 많아 연령대가 높다는 인식이 있었습니다. 하지만 대부분 제 또래(30대 초반)이며 학기가 지날수록 점점 더 젊어진다는 느낌을 받았습니다. 
6. 다양한 동문
 - 휴먼 네트워크 구축도 대학원 진학의 목표 였습니다. 저는 과대표도 2학기 수행 했는데, 덕분에 동문 및 학우 분들과 가깝게 지낼 수 있었습니다.
 

# 단국대를 졸업하며 느꼈던 큰 장점을 말씀 드립니다.

교수님들의 수준이 정말 높다고 생각됩니다.
  감히 제가 교수님들을 평가할 수 있겠냐만은, 입학을 고려하시는 분들께 단언할 수 있습니다. 대학원은 단순히 커리큘럼에 있는 내용만 학습하는 곳이 아니라고 생각 됩니다. 실무/이론 등 교수님들께서 갖고 게신 정말 많은 지식들을 얻어가실 수 있습니다.
 

# 마지막으로..

대학원을 고민하시는 분들 모두 다양한 목적과 고려 사항이 있을 것으로 보입니다. 여러 가지 고민을 하실텐데 수도권에 계시면 단국대학원이 좋은 선택이 될 수 있을것 같습니다 ^^
 
 
 
 
[정보융합기술·창업대학원]
https://cms.dankook.ac.kr/web/gict

 
[정보융합기술·창업대학원 공지사항]
https://cms.dankook.ac.kr/web/gict/-23

IT 컨버전스 학과
반응형

+ Recent posts