728x90

1. 기본형과 참조형

1bit = 2진수 한자리

1byte = 8bit

기본형

오직 8개 (boolean, char, byte, short, int, long, float, double)

정수형 : byte 1byte, short 2byte, int 4byte, long 8byte

실수형 : float 4byte, double 8byte

논리형 : boolean 1byte

문자형 : char 2byte (java에서는 2바이트 유니코드를 사용하기 때문)

실제 값을 저장

 

참조형

기본형 8개를 제외한 모든 것 (String, System 등)

참조형 변수는 객체의 주소를 저장하기 위한 것

메모리 주소를 저장(4byte : 32bit JVM 또는 8byte : 64bit JVM)

 

2. 조건 연산자

조건식에 결과에 따라 연산 결과를 달리한다.

조건식 ? 식1 : 식2

조건식이 참이면 식1 거짓이면 식2

 

3. for문에 이름을 붙인다.

loop1 : for(int i = 0; i < n; i++) {
	for(int j = 0; j < n; j++) {
		break; → 안쪽 for문만 끝난다.
        break loop1; → loop1이라는 이름이 붙은 반복문이 끝난다.
	}
}

 

4. 객체지향

클래스

정의 : 객체를 정의해 놓은 것

용도 : 클래스는 객체를 생성하는 데 사용

 

객체

정의 : 실제로 존재하는 것, 사물 또는 개념

용도 : 객체가 가지고 있는 기능과 속성에 따라 다름

클래스 객체
제품 설계도 제품
TV 설계도 TV
붕어빵 기계 붕어빵

객체 = 속성(변수) + 기능(메서드)

 

객체 : 모든 인스턴스를 대표하는 일반적 용어

인스턴스 : 특정 클래스로부터 생성된 객체 객체와 인스턴스는 같은 단어

 

1. 객체의 생성
클래스명 변수명; // 클래스의 객체를 참조하기 위한 참조변수를 선언
변수명 = new 클래스명(); // 클레스의 객체를 생성 후, 객체의 주소를 참조변수에 저장  

ex)
TV t;  // TV클래스 타입의 참조변수 t를 선언
t = new TV(); // TV인스턴스 생성한 후, 생성된 TV인스턴스의 주소를 t에 저장

TV t = new TV();

2. 객체의 사용
t.channel = 7; // TV인스턴스의 맴버변수 channel의 값을 7로 한다.
t.channelDown(); // TV인스턴스의 메서드 channelDown()을 호출  

 

5. 객체 배열

객체 배열 == 참조 변수 배열

 

6. 클래스의 정의

클래스 == 데이터 + 함수

  1. 변수 : 하나의 데이터를 저장하는 공간
  2. 배열 : 같은 종류의 여러 데이터를 하나로 저장할 수 있는 공간
  3. 구조체 : 서로 관련된 여러 데이터(종류 관계 x)를 하나로 저장할 수 있는 공간
  4. 클래스 : 데이터와 함수의 결합(구조체 + 함수)

 

7.  선언 위치에 따른 변수의 종류

class Variables { // 클래스 영역
	int iv;  // 인스턴스 변수
    static int cv; // 클래스 변수(static 변수, 공유변수)
    
    void method() {  // 메소드 영역
    	int lv = 0; // 지역변수    
    }
}
변수의 종류 선언 위치 생성시기
클래스 변수 클래스 영역 클래스가 메모리에 올라갈 때
인스턴스 변수 인스턴스가 생성 되었을 때
지역 변수  클래스 영역 이외의 영역  변수 선언문이 수행 되었을 때

 

8. 클래스 변수와 인스턴스 변수

class Card {
	String kind; // 무늬
    int number;  // 숫자
    
    static int width = 100;  // 폭
    static int height = 250; // 너비
}

Card c = new Card();
// 인스턴스 변수
c.kind = "HEART";
c.number = 5;
// 클래스 변수
Card.width = 200;
Card.height = 300;

 

9. 메서드

메서드의 장점

  • 코드의 중복을 줄일 수 있다.
  • 코드의 관리가 쉽다.
  • 코드를 재사용할 수 있다.
  • 코드가 간결해서 이해하기 쉬워진다.

메서드 작성

  • 반복적으로 수행되는 여러 문장을 메서드로 작성
  • 하나의 메서드는 한 가지 기능만 수행하도록 작성
MyMath mm = new MyMath(); // 1. 먼저 인스턴스를 생성한다.
long value = mm.add(1L, 2L); // 2. 메서드를 호출한다.

long add(long a, long b) {
	long result = a + b;
    return result;  // 반환타입이 void가 아닌 경우, 반드시 return문 필요
}
1. main 메서드에서 메서드 add를 호출한다. 인수 1L과 2L이 메서드 add의 매개변수 a, b에 각각 복사(대입)된다.
2. 메서드 add의 괄호 {} 안에 있는 문장들이 순서대로 실행된다.
3. 메서드 add의 모든 문장이 실행되거나 return문을 만나면, 호출한 메서드(main메서드)로 되돌아와서 이후의 문장들을 실행한다.

 

10. 호출 스택(call stack)

스택 : 밑이 막힌 상자, 위에 차곡차곡 쌓인다.

넣을 때

꺼낼 때

호출 스택

  1. 메서드가 수행에 필요한 메모리가 제공되는 공간
  2. 메서드가 호출되면 호출 스택에 메모리 할당, 종료되면 해제

 

class CallStack {
	public static void main(String[] args) {
    	System.out.println("Hello");
    }
}

아래에 있는 메서드가 위의 메서드를 호출한 것

맨 위의 메서드 하나만 실행 중, 나머지는 대기 중

 

11. 기본형 매개변수

기본형 매개변수 : 변수의 값을 읽기만 할 수 있다. (read only)

참조형 매개변수 : 변수의 값을 읽고 변경할 수 있다. (read & write)

 

 

 

 

728x90
728x90

로그인, 쿠키와 세션, JWT 토큰

HTTP란?

stateless 하다. 연결을 끊는 순간 사용자와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

브라우저에서 상태를 유지하는 방법

  • 쿠키와 세션
  • 토큰 기반 방식

세션

서버와 클라이언트의 연결이 활성화된 상태

 

세션 ID

웹 서버 메모리에 저장되는 클라이언트에 대한 유니크한 ID(서버 또는 데이터베이스에 저장)

 

쿠키

  • 키 - 값으로 구성된 작은 데이터 조각
  • 쿠키에 담긴 데이터는 브라우저에서 관리된다. 하지만 보통 만료 날짜를 서버에서 설정한다.
  • 이름, 값, 만료 날짜 등으로 구성

쿠키와 세션

  1. 처음 로그인 -> 쿠키, 세션 ID 생성 그 이후 다시 요청했을 때 HTTP 헤더에 쿠키를 포함시켜 요청한다.
  2. 해당 쿠키에 맞는 세션 ID로 전에 로그인했던 아이디인지 확인
  3. 로그인을 유지

XSS(Cross Site Scripting)

쿠키는 클라이언트에서 자바스크립트로 조회가 가능하다. 공격자들이 자바스크립트로 쿠키를 가로채고자 시도를 하는데 이를 XSS라고 한다.

해결 방법 : HTTP Only Cookie 또는 secure cookie를 사용한다.

  • Set-Cookie : 쿠키명 = 쿠키값; path=/ ; secure
  • Set-Cookie : 쿠키명 = 쿠키값; path=/ ; HttpOnly

보통은 HTTP 관련 라이브러리에 적혀있는 대로 사용한다.

ex) axios.defaults.withCredentials = true;

 

쿠키 - 세션 방식의 단점

로그인할 때마다 세션 ID를 저장해야 돼서 로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부하 등 악영향을 미친다. 

 

토큰 기반 인증 방식

JWT토큰 인증은 토큰 기반 인증서버를 통해서 하게 하고 서버는 stateless 하게 내버려 두자. 요청 -> 토큰 생성 -> 이후 사용자가 토큰을 헤더(authoriztion 키에 넣어서 요청, 이 토큰을 기반으로)

JWT(JSON Web Token, RFC 7519)

헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩 된다. 메세지 인증, 암호화에 사용

 

Header

어떠한 방법의 서명 알고리즘을 사용할 것인가에 대한 정보

Payload

데이터, 토큰 발급자, 토큰 유효기간(인증이 필요한 최소한의 정보만)

Signature

헤더에 정의된 알고리즘으로 인코딩된 헤더와 페이로드를 합친 값, 그리고 비밀키를 기반으로 생성된 서명 값

 

JWT 장점

사용자가 인증되면 사용자는 모든 시스템에서 사용할 수 있는 보안 토큰을 받습니다. 즉, 단일 엔드포인트를 생성해서 다른 모든 서버 간의 API 상호작용을 인증할 수 있다는 점에서 좋다.

 

JWT의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없다.

확장성, 디버깅, 사이즈가 작음, JWT토큰 자체가 독립적이다.

 

JWT 단점

더 많은 필드가 추가되면 토큰이 비대해져 트래픽에 영향

탈취하여 디코딩하면 데이터를 볼 수 있다.

 

브라우저 렌더링 과정

1. DOM 트리 구축

하나의 html 페이지는 div, span 등 각각의 요소를 가진다. 각 요소는 하나하나 노드로 설정이 되어 트리 형태로 저장된다. 이를 DOM 트리라고 한다. 예를 들어 div > span, span이 있다면 div라는 부모 노드 밑에 span이라는 자식 노드가 2개 생기는 것이다.

2. 렌더 트리와 렌더 레이어 생성

각각의 노드는 CSS파서에 의해 정해진 스타일 규칙이 적용되어 있다. span.color="red"는 노드 색깔이 빨간색이다 등을 말한다. 이런 규칙에 따라 CSSOM이라는 트리가 만들어지고 미리 만들어놓은 DOM트리 내에 있는 노드와 함께 렌더 객체가 생성되며 이들이 모여 병렬적인 렌더 트리가 생성된다. 상속적인 스타일은 부모 노드에만 위치하도록 설계하는 등의 최적화를 거쳐 렌더 레이어가 완성된다.

3. 렌더 레이어를 대상으로 Layout설정

이때 좌표는 보통 부모를 기준으로 설정된다. Global Layout은 브라우저 사이즈가 증가하거나 폰트 사이즈가 커지면 변경된다.

4. 렌더레이어를 대상으로 칠하기

픽셀마다 점을 찍듯 칠한다. 이를 레스터화라고도 한다.

5. 레이어 합치기 및 표기

각각의 레이어로부터 비트맵이 생성되고 GPU에 텍스처로 업로드된다. 그다음 택스처들은 서로 합쳐져 하나의 이미지로 렌더링 되며 화면으로 출력된다.

 

웹 브라우저의 캐시

대표적인 캐시로는 웹 브라우저의 작은 저장소 쿠키, 로컬 스토리지, 세션 스토리지가 있다. 이러한 것들은 보통 사용자의 커스텀한 정보나 인증 모듈 관련 사항들을 웹 브라우저에 저장해서 추후 서버에 요청할 때 자신을 나타내는 아이덴티티나 중복 요청 방지를 위해 쓰인다.

 

쿠키

쿠키는 만료기한이 있는 키 - 값 저장소이다. same site 옵션을 strict로 설정하지 않았을 경우 다른 도메인에서 요청했을 때 자동 전송되며, 4KB까지 데이터를 저장할 수 있고 만료기한을 정할 수 있다. 쿠키를 설정할 때는 document.cookie로 쿠키를 볼 수 없게 httponly 옵션을 거는 것이 중요하며, 클라이언트 또는 서버에서 만료기한 등을 정할 수 있는데 보통 서버에서 만료기한을 정한다.

 

로컬 스토리지

로컬 스토리지는 만료기한이 없는 키 - 값 저장소이다. 10MB까지 저장할 수 있으며 웹브라우저를 닫아도 유지되고 도메인 단위로 저장, 생성된다. 클라이언트에서만 수정 가능하다.

 

세션 스토리지

세션 스토리지는 만료기한이 없는 키 - 값 저장소이다. 탭 단위로 세션 스토리지를 생성하며, 탭을 닫을 때 해당 데이터가 삭제된다. 5MB까지 저장이 가능하다. 클라이언트에서만 수정 가능하다.

 

HTTP의 상태 코드

1xx(정보)

요청을 받았으며 프로세스를 계속한다.

 

2xx(성공)

요청을 성공적으로 받았으며 인식했고 수용한다.

  • 200 OK : 요청을 성공적으로 되었습니다.
  • 201 Created : 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었다.

3xx(리다이렉션)

요청 완료를 위해 추가 작업 조치가 필요하다

  • 301 Moved perma nently : 이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미한다. 변경된 새로운 URI를 응답에서 주는 것이 좋다.

4xx(클라이언트 오류)

요청의 문법이 잘못되었거나 요청을 처리할 수 없다.

  • 400 Bad Request : 이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미한다.
  • 401 Unauthorized : 클라이언트의 인증이 되지 않음을 의미한다.

5xx(서버 오류)

서버가 명백히 유효한 요청에 대해 충족을 실패했다.

  • 500 Internal Server Error : 서버에 오류가 있음을 의미한다.

HTTP의 메서드

POST : 자원을 생성

보통 하위 자원을 생성한다. 성공적으로 생성되면 HTTP 상태 201을 반환

GET : 읽기

성공 시 200, 오류의 경우 가장 자주 404(Not Found) 또는 400(Bad Request)을 반환한다. 데이터를 수정, 삭제하는데 반드시 사용하면 안 된다.

PUT : 업데이트(전체 자원)

요청을 보낼 때 전체를 보내야 한다.

PATCH : 업데이트(일부 자원)

요청을 보낼 때 수정하는 일부분을 보내야 한다.

DELETE : 삭제

 

REST API

API란?

API는 소프트웨어와 소프트웨어 사이 데이터 전송을 가능하게 하는 프로그램이다.

 

Uniform-Interface

자원들이 각각의 독립적인 인터페이스를 가져야 한다.

  • 웹페이지를 변경했다고 웹 브라우저를 업데이트하는 일은 없어야 된다.
  • HTTP 명세나 HTML 명세가 변경되어도 웹페이지는 잘 작동해야 한다.

REST API 아키텍처 규칙

1. Self - descriptive messages

HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 한다.

예를 들어. json을 반환한다면 application/json으로 명시해주어야 한다. MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준이다. 'font/ttf', 'text/plain', 'text/csv' 등

 

2. HATEOAS 구조

하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 한다.

 

3. Stateless

이 규칙은 HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 만족된다. 즉 REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미이다.

 

4. Cacheable

HTTP는 원래 캐싱이 된다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css이미지 등을 불러오는 것을 볼 수 있다. 이러한 캐싱은 네트워크 요청을 줄여주며 이는 UX 향상에도 도움이 된다. 네트워크 요청 시 해당되는 자원들을 복사해서 메모리에 저장해두었다가 또 같은 요청 시 네트워크 요청을 하지 않고 브라우저 메모리에 있던 자원을 다시 반환한다. HTTP 메서드 중 GET에 한정되며 Cache-Control:max-age=100(100초) 이런 식으로 한정된 시간을 정할 수가 있다. 캐싱된 데이터가 유효한지 판단하기 위해 Last-modifed와 Etag를 쓴다. Etag는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것이다.

 

5. Client-Server 구조

클라이언트와 서버가 서로 독립적인 구조를 가져야 한다. 물론 이는 HTTP를 통해 가능한 구조이다. 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 된다. 서버는 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 된다. 클라이언트에서는 HTTP로 받는 로직만 잘 처리하면 된다.

 

6. Layered System

계층구조로 아키텍처를 만들 수 있다는 것을 뜻한다.

 

URI 규칙

  1. 동작은 HTTP 메서드로 해야 한다. 수정 = put, 삭제 = delete, 추가 = post, 조회 = get을 이용해야 한다. 예를 들어 /books/delete/1 이렇게 표기하면 안 된다.
  2. 확장자는 표기하지 말아야 한다.
  3. 동사가 아닌 명사로만 표기해야 한다. 유저가 책을 소유한다라고 하려면 유저/유저아이디/inclusion/책/책 아이디
  4. URI는 계층적인 내용을 담고 있다. /집/아파트/전세 이런 식으로 내려가야 한다.
  5. 소문자로 쓰며 너무 길 경우에는 *****-**** 를 쓴다.
  6. HTTP 응답 상태 코드를 활용한다.

도서관 시스템의 REST API 예시

get('/books/') : 모든 책을 조회한다.

post('/books/booksid') : 책을 생성한다.

put('/books/'booksid) : 책을 수정한다.

get('/books/booksid') : 특정 책을 조회한다.

put('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.

patch('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.

728x90

'개발 > CS' 카테고리의 다른 글

2 - 2. 운영체제 기초  (0) 2022.07.07
2 - 1. 운영체제 기초  (0) 2022.07.05
1 - 3. 네트워크 기초  (0) 2022.06.28
1 - 2. 네트워크 기초  (0) 2022.06.27
1 - 1. 네트워크 기초  (0) 2022.06.23
728x90

쿠버네티스 입문반 Introduction to Docker

첫 수업으로 Introduction to Docker 강의를 들었습니다. 구글 클라우드 환경에서 터미널에 접속해 docker를 실행하고 실습하는 시간이 되었습니다. docker기본을 배우고 듣는 수업이라 어려운 수업은 아니였습니다. 강의가 영어로 되어있어 살짝 힘든 것 말고는 좋은 학습이 될 것 같습니다. 혹시 몰라 구글에서 사용하는 아이디는 모자이크 처리하였습니다.

 

구글 클라우드 쉘에 접속한 모습입니다. 여기서 쿠버네티스 실습을 진행합니다.

 

docker run hello-world

위의 사진을 잘 보시면 Unable to find image를 보실 수 있습니다. docker 데몬은 hello-world 이미지를 검색했지만 로컬에서 이미지를 찾지 못해서 Docker Hub라는 공개 레지스트리에서 이미지를 가져와서 해당 이미지에서 컨테이너를 생성하고 컨테이너를 실행했습니다.

 

docker images

docker images 명령어입니다. 이 스크린 샷은 못 찍었습니다. 이미지 목록을 확인하는 명령어입니다.

 

docker run hello-world

정상적으로 실행되었습니다. Hello from Docker !

 

docker ps

docker ps 명령어입니다. 실행 중인 컨테이너가 없습니다. 이전에 실행한 hello-world 컨테이너가 이미 종료되었습니다. 

 

docker ps -a

종료된 컨테이너를 포함하여 모든 컨테이너를 보려면 docker ps에서 - a 옵션만 추가시켜주면 됩니다.

 

mkdir test
cd test

test 디렉터리를 만들고 test 디렉터리에 들어갑니다. 

 

cat > Dockerfile <<EOF
# 공식 Node 런타임을 부모 이미지로 사용 
FROM node:lts
# 컨테이너의 작업 디렉터리를 /app으로 설정 
WORKDIR /app
# 현재 디렉터리 내용을 /app으로 설정
ADD . /app
# 컨테이너의 포트 80을 외부에서 사용할 수 있도록 설정.
EXPOSE 80
# 컨테이너가 실행될 때 node를 사용하여 app.js를 실행합니다. 
CMD ["node", "app.js"]
EOF

dockerfile을 만드는 방법에 대한 설명입니다. 간단하게 실습하는 것이라 명령어에 잘 모르실 경우 제 블로그 참고 바랍니다.

https://lusida-coding.tistory.com/35?category=1031465 

 

따배도) Docker 명령어, dockerfile 만들기 및 repo배포

따라 하며 배우는 도커 유튜브 영상을 보고 학습한 내용을 블로그에 정리하려고 합니다. 1. 도커 기본 명령어 docker docker를 설치하셔서 docker를 치면 docker에 관련된 명령어들이 나온다. docker search

lusida-coding.tistory.com

 

cat > app.js <<EOF
const http = require('http');
const hostname = '0.0.0.0';
const port = 80;
const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World\n');
});
server.listen(port, hostname, () => {
    console.log('Server running at http://%s:%s/', hostname, port);
});
process.on('SIGINT', function() {
    console.log('Caught interrupt signal and will exit');
    process.exit();
});
EOF

노드 애플리케이션 파일을 만듭니다. 포트 80에서 수신 대기하고 Hello World를 출력하는 간단한 HTTP 서버입니다.

 

docker build -t node-app:0.1 .

 

이미지를 빌드합니다. "."은 현재 디렉터리를 의미하므로 Dockerfile이 있는 디렉토리 내에서 이 명령어를 실행해야 합니다.

 

node은 기본 이미지이며 node-app빌드한 이미지입니다. node먼저 제거하지 않고는 node-app을 제거할 수 없습니다. 이미지의 크기는 VM에 비해 상대적으로 작습니다.

 

docker run -p 4000:80 --name my-app node-app:0.1

방금 빌드한 이미지를 기반으로 컨테이너를 실행합니다. 현재 터미널에서 실행되는 것을 확인하실 수 있습니다.

 

curl http://localhost:4000

--name은 원하는 경우 컨테이너의 이름을 지정할 수 있습니다.호스트 의 -p포트 4000을 컨테이너의 포트 80에 매핑하도록 명령어를 작성했다. 이제 http://localhost:4000. 포트 매핑이 없으면 localhost의 컨테이너에 연결할 수 없습니다. 다른 터미널을 열고 서버를 테스트합니다. Hello World가 정상적으로 출력되는 것을 확인하실 수 있습니다.

 

docker stop my-app && docker rm my-app

컨테이너를 중지하고 컨테이너를 지우는 명령어입니다.

 

docker run -p 4000:80 --name my-app -d node-app:0.1

컨테이너를 백그라운드에서 실행하려면(터미널 세션에 연결되지 않음) -d옵션을 지정해야 합니다.

 

docker logs my-app

컨테이너의 로그를 확인하는 명령어입니다.

docker logs -f [container_id]

 컨테이너가 실행될 때 로그의 출력을 실시간으로 확인하려면 -f옵션을 사용하면 됩니다.

 

docker build -t node-app:0.2 .

app.js파일에서 Hello World를 Hello Cloud로 수정 후 node-app:0.2로 빌드를 진행하였습니다.

2단계에서 기존 캐시 계층을 사용하고 있음을 알 수 있습니다. 3단계부터 에서 변경했기 때문에 레이어가 수정됩니다.

 

docker run -p 8080:80 --name my-app-2 -d node-app:0.2
curl http://localhost:8080
curl http://localhost:4000

새 이미지 버전으로 다른 컨테이너를 실행합니다. 호스트 포트 4000은 이미 사용 중이기 때문에 사용할 수 없습니다. 컨테이너를 실행 후 curl로 8080과 4000에 접속 테스트를 진행하였습니다. 8080에는 모자이크로 잘리긴 했으나 Hello to Cloud가 출력되었고 4000에는 수정하기 전인 Hello World가 출력되었습니다.

 

docker exec -it [container_id] bash

실행 중인 컨테이너 내에서 Bash 세션을 시작할 때는 명령어 마지막에 bash라고 지정해주면 됩니다. docker exec -it를 사용하면 pseudo-tty를 할당하고 표준 입력을 열린 상태로 유지하여 컨테이너와 상호 작용할 수 있습니다. bash는 Dockerfile에 WORKDIR지정된 디렉터리(/app)에서 실행되었습니다.

 

docker inspect [container_id]

Docker inspect를 사용하여 Docker에서 컨테이너의 메타데이터를 확인할 수 있습니다.

docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' [container_id]
--format은 반환된 JSON에서 특정 필드를 검사하는 데 사용 합니다.
위의 예시는 IPAddress을 확인하는 명령어입니다.
 

docker tag node-app:0.2 gcr.io/[project-id]/node-app:0.2

도커를 푸시를 해주려면 컨테이너에 태그가 붙어있어야 합니다. 제 개인 도커 레파지토리에 푸시를 하려면 제 도커 레파지토리 이름 태그를  붙여줘야 합니다.

docker push gcr.io/[project-id]/node-app:0.2

도커를 gcr에 푸시하는 명령어입니다. 

 

728x90
728x90

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어있다. 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있다.

 

RTT

패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복 시간

 

RTT 증가를 해결하기 위한 방법

매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답 시간이 길어졌다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용했다.

 

이미지 스플리팅

많은 이미지를 다운로드하게 되면 과부하가 걸리기 때문에 많은 이미지가 협쳐 있는 하나 이미지를 다운로드하고, 이를 기반으로 background-image의 position을 이용해 이미지를 표기하는 방법이다.

 

코드 압축

코드압축은 코드를 압축해 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법이다.

개행 문자, 띄어쓰기 등이 사라져 코드가 압축되면 코드 용량이 줄어든다.

 

이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법이다. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있다. 하지만 Base64 문자열로 변환할 경우 37% 정도 크기가 더 커지는 단점이 있다.

 

HTTP/1.1

매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다. 한번 TCP 3-way-shake 가 발생하면 그다음부터 발생하지 않는 것을 볼 수 있다. 하지만 문서 안에 포함된 다수의 리소스(이미지, css, script)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.

 

HOL Blocking

HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다. 예를 들어 image.jpg와 style.css, data.xml을 다운로드받을 때 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 된다.

 

무거운 헤더 구조

HTTP/1.1의 헤더에는 쿠키등 많은 메타데이터가 들어 있고 압축이 되지 않아 무거웠다.

 

HTTP/2.0

HTTP/2.0은 HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위를 처리를 지원하는 프로토콜이다.

 

멀티플렉싱

멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것이다. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다. 멀티플렉싱을 통해 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고 응답을 줄 수 있다. 이렇게 되면 HTTP/1.x에서 발생하는 HOL Blocking을 해결할 수 있다.

 

스트림

시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

 

헤더 압축

HTTP/1.x에서 크기가 큰 헤더의 문제를 HTTP/2.0에서는 헤더 압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.

 

허프만 코딩

문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트 양을 줄이는 원리이다.

 

서버 푸시

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있었다면, HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

 

HTTPS

HTTP/2는 HTTPS 위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청이다.

 

SSL/TLS

SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜이다. 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제삼자가 메시지를 도청하거나 변조하지 못하도록 한다. SSL/TLS를 통해 공격자가 서비인 척하며 사용자 정보를 가로채는 네트워크 상의 인터셉터를 방지할 수 있다.

SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다. 참고로 TLS 1.3은 사용자가 이전에 방문한 사이트로 다시 방문한다면 SSL/TLS에서 보안 세션을 만들 때 걸리는 통신을 하지 않아도 된다. 이를 0-RTT라 한다.

 

보안 세션

보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다. 클라이언트와 서버와 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 한 번의 1-RTT가 생긴 후 데이터를 송수신하는 것을 볼 수 있다. 클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인한다. 제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화된 데이터의 송수신이 시작된다.

 

사이퍼 슈트

사이퍼 슈트는 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 말하며 다섯 개가 있다.

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256

TLS_AES_128_GCM_SHA256에는 세가지 규약이 들어 있는데 TLS는 프로토콜, AES_128_GCM은 AEAD 사이퍼 모드, SHA256은 해싱 알고리즘을 뜻한다.

 

AEAD 사이퍼 모드

AEAD는 데이터 암호화 알고리즘이며 AES_128_GCM 등이 있다. 예를 들어 AES_128_GCM이라는 것은 128비트의 키를 사용하는 표준 블록 함호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻한다.

 

암호화 알고리즘

키 교환 암호화 알고리즘으로는 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용한다. 둘 다 디피-헬만 방식을 근간으로 만들어졌다.

 

디피-헬만 키 교환 암호화 알고리즘

디피-헬만 키 교환 암호화 알고리즘은 암호키를 교환하는 하나의 방법이다.

처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유한다. 각자 비밀 값과 또 혼합한다. 그 이후에 공통의 암호키가 생성되는 것이다.

 

SHA-256 알고리즘

SHA-256 알고리즘은 해시 함수의 결괏값이 256비트인 알고리즘이며 해싱을 해야 할 메세지에 1을 추가하는 등 전처리를 하고 전 처리된 메시지를 기반으로 해시를 반환한다.

 

 

HTTPS 구축 방법

직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축하거나, 서버 앞단의 HTTPS를 제공하는 로드밸런서를 두거나, 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다.

 

HTTP/3

TCP 위에서 돌아가는 HTTP/2와는 달리 HTTP/3은 QUIC이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.

QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way-handshake과정을 거치지 않아도 된다. QUIC는 첫 연결 설정에 1-RTT만 소요된다. QUIC는 순방향 오류 수정 메커니즘이 적용되었다. 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.

728x90

'개발 > CS' 카테고리의 다른 글

2 - 2. 운영체제 기초  (0) 2022.07.07
2 - 1. 운영체제 기초  (0) 2022.07.05
1 - 4. 네트워크 기초  (0) 2022.06.29
1 - 2. 네트워크 기초  (0) 2022.06.27
1 - 1. 네트워크 기초  (0) 2022.06.23
728x90

유튜브 무료 강의인 따배도가 마지막 강의입니다. 무료 강의이지만 퀄리티가 무료 강의를 넘어서는 강의이고 도커가 처음이신 분 도커에 대해 공부하고 싶은 분, 취준생분들 모두 추천합니다.

https://www.youtube.com/watch?v=NLUugLQ8unM&list=PLApuRlvrZKogb78kKq1wRvrjg1VMwYrvi&index=1 

토커 컴포즈란?

여러 컨테이너를 일괄적으로 적용하고 실행할 수 있는 툴

  • 하나의 서비스를 운영하기 위해서는 여러개의 애플리케이션이 동작해야 한다.
  • 컨테이너화 된 애플리케이션들을 통합 관리할 수 있다.

docker-compose 기본 명령어

docker-compose 기본 명령어

version : compose 버전 버전에 따라 지원 문법이 다름
service : 컴포즈를 이용해서 실행할 컨테이너 옵션 정의
build : 컨테이너 빌드
image : compose를 통해 실행할 이미지를 지정
command : 컨테이너에서 실행 될 명령어 지정
port : 컨테이너가 공개하는 포트 나열
link : 다른 컨테이너와 연계할 때 연계할 컨테이너 지정
expose : 포트를 링크로 연계된 컨테이너에만 공개할 포트
volumes : 컨테이너에 볼륨을 마운트
environment : 컨테이너에 적용할 환경변수를 정의
restart : 컨테이너가 종료 될 때 적용할 restart 정책
	no : 재시작 되지 않음
	always : 컨테이너를 수동으로 끄기 전까지 항상 재시작
	on-failure : 오류가 있을시에 재시작
depends_on : 컨테이너 간의 종속성을 정의 정의한 컨테이너가 먼저 동작되야함

docker-compose로 동작시키는 웹서버

1단계 : 도커 컨테이너가 사용할 서비스 디렉터리부터 만들어줘야 한다.

  • mkdir webserver
  • cd webserver

2단계 : docker-compose.yml 생성

3단계 : docker-compose 명령어

  • docker-compose up -d
  • docker-compose ps
  • docker-compose scale mysql=2
  • docker-compose ps
  • docker-compose down

docker-compose 명령어

도커 컴포즈 명령어

up : 컨테이너 생성/시작
ps : 컨테이너 목록 표시
logs : 컨테이너 로그 출력
run : 컨테이너 실행
start : 컨테이너 시작
stop : 컨테이너 정지
restart : 컨테이너 재시작
pause : 컨테이너 일시정지
unpause : 컨테이너 재개
port : 공개포트번호 표시
config : 구성확인
kill : 실행중인 컨테이너 강제 정지
rm : 컨테이너 삭제
down : 리소스 삭제

ex) docker-compose scale 서비스 이름 = 개수
docker-compose run 서비스 이름 실행 명령어
docker-compose logs 서비스 이름
docker-compose up -d
docker-compose ps
docker-compose scale mysql=2
docker-compose ps
docker-compose down
docker-compose down - -volumes 볼륨까지 지워진다.

빌드와 운영

1단계 : 도커 컨테이너가 사용할 서비스 디렉터리부터 만들어줘야 한다.

  • mkdir webserver
  • cd webserver

2단계 : 빌드를 위한 dockerfile 생성

3단계 : docker-compose.yml 생성

4단계 : docker-compose 명령어

  • docker-compose up -d
  • docker-compose ps
  • docker-compose scale mysql=2
  • docker-compose ps
  • docker-compose down
728x90
728x90

네트워크 기기의 처리 범위

네트워크 기기는 계층별로 처리 범위를 나눌 수 있다. 또한 상위 계층을 처리하는 기기는 하위 계층을 처리할 수 있지만 그 반대는 불가하다.

  • 애플리케이션 계층 : L7 스위치
  • 인터넷 계층 : 라우터, L3 스위치
  • 데이터 링크 계층 : 브리지, L2 스위치
  • 물리 계층 : NIC, 리피터, AP

L7 스위치

L7 스위치는 로드밸런서라고도 하며, 서버의 부하를 분산하는 기기이다. 클라이언트로부터 오는 요청들을 뒤쪽의 여러 서버로 나누는 역할을 하며 시스템이 처리할 수 있는 트래픽 증가를 목표로 한다.

URL, 서버, 캐시, 쿠키들을 기반으로 트래픽을 분산한다. 또한 바이러스, 불필요한 외부 데이터 등을 걸러내는 필터링 기능 또한 가지고 있으며 응용 프로그램 수준의 트래픽 모니터링도 가능하다.

만약 장애가 발생한 서버가 있다면 이를 트래픽 분산 대상에서 제외해야 하는데, 이는 정기적으로 헬스 체크를 이용하여 감시하면서 이루어진다.

 

L7 스위치와 L4 스위치 차이

L4 스위치는 인터넷 계층을 처리하는 기기로 스트리밍 관련 서비스에서는 사용할 수 없으며 메시지를 기반으로 인식하지 못하고 IP와 포트를 기반으로 트래픽을 분산한다.

L7 스위치는 IP, 포트 외에도 URL, HTTP 헤더, 쿠키 등을 기반으로 트래픽을 분산한다.

L7 스위치를 이용한 로드밸런싱은 ALB 컴포넌트로 하며, L4 스위치를 이용한 로드밸런싱은 NLB 컴포넌트로 한다.

 

헬스 체크

L4 스위치, L7 스위치 모두 헬스 체크를 통해 정상적인 서버 또는 비정상적인 서버를 판별하는데, 헬스 체크는 전송 주기와 재전송 횟수 등을 설정한 이후 반복적으로 서버에 요청을 보내는 것을 말한다.

TCP, HTTP 등 다양한 방법으로 요청을 보내며 이 요청이 정상적이라면 정상 서버로 판별

 

인터넷 계층을 처리하는 기기

라우터

라우터는 여러 개의 네트워크를 연결, 분할, 구분시켜주는 역할을 하며 다른 네트워크에 존재하는 장치끼리 서로 데이터를 주고받을 때 패킷 소모를 최소화하고 경로를 최적화하여 최소 경로로 패킷을 포워딩하는 라우팅을 하는 장비이다.

 

L3 스위치

L3 스위치란 L2 스위치의 기능과 라우팅 기능을 갖춘 장비이다. 라우터는 소프트웨어 기반 라우팅과 하드웨어 기반 라우팅을 하는 것으로 나눠지고 하드웨어 기반의 라우팅을 담당하는 장치를 L3 스위치라고 한다.

 

데이터 링크 계층을 처리하는 기기

L2 스위치

L2 스위치는 장치들의 MAC 주소를 MAC 주소 테이블을 통해 관리하며, 연결된 장치로부터 패킷이 왔을 때 패킷을 전송한다.

단순히 패킷의 MAC 주소를 읽어 스위칭하는 역할을 한다.

 

브리지

브리지는 두 개의 근거리 통신망(LAN)을 상호 접속할 수 있도록 하는 통신망 연결 장치로, 포트와 포트 사이의 역할을 하며 장치에서 받아온 MAC 주소를 MAC 주소 테이블로 관리한다.

브리지는 통신망 범위를 확장하고 서로 다른 LAN 등으로 이루어진 하나의 통신망을 구축할 때 쓰인다.

 

물리 계층을 처리하는 기기

NIC

LAN 카드라고 하는 네트워크 인터페이스 카드는 2대 이상의 컴퓨터 네트워크를 구성하는 데 사용한다. 네트워크와 빠른 속도로 데이터를 송수신할 수 있도록 컴퓨터 내에 설치하는 확장 카드이다. LAN 카드에는 각각을 구분하기 위한 고유의 식별번호인 MAC 주소가 있다.

 

리피터

리피터는 들어오는 약해진 신호 정도를 증폭하여 다른 쪽으로 전달하는 장치이다. 이를 통해 패킷이 더 멀리 갈 수 있다. 광케이블 보급이 됨에 따라 현재는 잘 안 쓰인다.

 

AP

AP는 패킷을 복사하는 기기이다. AP에 유선 LAN을 연결한 후 다른 장치에서 무선 LAN 기술을 사용하여 무선 네트워크 연결을 할 수 있다.

 

IP주소

ARP

컴퓨터 간의 통신은 흔히들 IP 주소 기반으로 통신한다고 알고 있지만 정확하게는 IP 주소에서 ARP를 통해 MAC 주소를 기반으로 통신을 한다. ARP란 IP 주소로부터 MAC 주소를 구하는 IP와 MAC 주소의 다리 역할을 하는 프로토콜이다.

ARP를 통해 가상 주소인 IP 주소를 실제 주소인 MAC 주소로 변환한다. 이와 반대로 RARP를 통해 실제 주소인 MAC 주소를 가상 주소인 IP 주소로 변환하기도 한다.

 

ARP의 주소를 찾는 과정

장치 A가 ARP Request 브로드캐스트를 보내서 IP 주소인 120.70.80.3에 해당하는 MAC 주소를 찾는다. 그러고 나서 해당 주소에 맞는 장치 B가 ARP reply 유니캐스트를 통해 MAC 주소를 반환하는 과정을 거쳐 IP 주소에 맞는 MAC 주소를 찾게 된다.

 

브로드캐스트

송신 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트에 전송되는 방식

 

유니캐스트

고유 주소로 식별된 하나의 네트워크 목적지에 1 : 1로 데이터를 전송하는 방식

 

홉바이홉 통신

IP 주소를 통해 통신하는 과정을 홉바이홉 통신이라고 한다. 여기서 홉이란 영어 뜻 자체로는 건너뛰는 모습을 의미한다. 이는 통신망에서 각 패킷이 여러 개의 라우터를 건너가는 모습을 비유적으로 표현한 것이다. 각각의 라우터에 있는 라우팅 테이블의 IP를 기반으로 패킷을 전달하고 다시 전달해나간다. 통신 장치에 있는 라우팅 테이블의 IP를 통해 시작 주소부터 시작하여 다음 IP로 계속해서 이동하는 라우팅 과정을 거쳐 패킷이 최종 목적지까지 도달하는 통신을 말한다.

 

라우팅 테이블

라우팅 테이블은 송신지에서 수신지까지 도달하기 위해 사용되며 라우터에 들어가 있는 목적지 정보들과 그 목적지로 가기 위한 방법이 들어 있는 리스트를 뜻한다. 라우팅 테이블에는 게이트웨이와 모든 목적지에 대해 해당 목적지에 도달하기 위해 거쳐야 할 다음 라우터의 정보를 가지고 있다.

 

게이트웨이

게이트웨이는 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 관문 역할을 하는 컴퓨터나 소프트웨어이다.

 

IP 주소 체계

IPv4

32비트를 8비트 단위로 점을 찍어 표기하며 127.45.67.89 같은 방식으로 IP 주소를 나타낸다.

 

IPv6

64비트를 16비트 단위로 점을 찍어 표기하며 2001:db8::ff00:42:8329와 같은 방식으로 IP 주소를 나타낸다.

 

클래스 기반 할당 방식(CIDR)

클래스 A, B, C는 일대일 통신으로 사용되고 클래스 D는 멀티캐스트 통신, 클래스 E는 앞으로 사용할 예비용으로 쓰는 방식이다. 맨 왼쪽에 있는 비트를 구분 비트라고 하는데 구분 비트를 통해 클래스 간의 IP가 나눠진다. 또한 네트워크의 첫 번째 주소는 네트워크 주소로 사용되고 가장 마지막 주소는 브로드캐스트용 주소로 네트워크에 속해 있는 모든 컴퓨터에 데이터를 보낼 때 사용한다.

이 방식은 사용하는 주소보다 버리는 주소가 많은 단점이 있다. 이를 해결하기 위해 DHCP와 IPv6, NAT이 나왔다.

 

DHCP

DHCP는 IP 주소 및 기타 통신 매개변수를 자동으로 할당하기 위한 네트워크 관리 프로토콜이다. 이 기술을 통해 네트워크 장치의 IP 주소를 수동으로 설정할 필요 없이 인터넷에 접속할 때마다 자동으로 IP 주소를 할당할 수 있다.

 

NAT

NAT은 패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 주소 정보를 수정하여 IP 주소를 다른 주소로 매핑하는 방법이다. IPv4 주소 체계만으로는 많은 주소들을 모두 감당하지 못하는 단점이 있는데, 이를 해결하기 위해 NAT으로 공인 IP와 사설 IP로 나눠서 많은 주소를 처리한다. NAT을 쓰는 이유는 주로 여러 대의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함이다. NAT을 이용하면 내부 네트워크에서 사용하는 IP 주소와 외부에 드러나는 IP 주소를 다르게 유지할 수 있기 때문에 내부 네트워크에 대한 어느 정도의 보안이 가능하다. 단점으로는 여러 명이 동시에 인터넷에 접속하게 되므로 접속 속도가 느려질 수 있다는 단점이 있다.

 

 

 

728x90

'개발 > CS' 카테고리의 다른 글

2 - 2. 운영체제 기초  (0) 2022.07.07
2 - 1. 운영체제 기초  (0) 2022.07.05
1 - 4. 네트워크 기초  (0) 2022.06.29
1 - 3. 네트워크 기초  (0) 2022.06.28
1 - 1. 네트워크 기초  (0) 2022.06.23
728x90

구글 Cloud Study Jam 쿠버네티스 입문반 과정을 진행한다고 메일이 왔었습니다.

메일 확인을 늦게 해서 턱걸이로 마감 직전에 신청을 완료하였습니다.

도커에 대해 학습을 완료하고 쿠버네티스에 대해 학습을 하려고 강의를 찾고 있었는데 이런 기회가 있어서 정말 감사합니다.

과정 기간은 2022년 6월 27일부터 2022년 7월 25일까지입니다. 학습을 완료하고 수료를 하면 기념품을 증정한다고 하니 열심히 들어야겠습니다. 

수료 조건은 제공된 강좌[Qwiklabs] Kubernetes in the Google Cloud 완료 시 수료가 된다고 합니다.


제공되는 강좌 목록

제공되는 강좌 목록입니다. 입문 과정이지만 배포까지 진행되는 과정인 것 같습니다.수료를 위해 열심히 강의를 듣고 학습한 내용에 대해 블로그에 정리하겠습니다.

 

728x90
728x90

컨테이너 간 통신(네트워크) 명령어

1. 컨테이너 통신 방식

도커 데몬을 실행하게 되면 docker0라고 하는 도커 네트워크 인터페이스가 생긴다. 도커 네트워크 인터페이스는 virtual ethernet bridge이고 브릿지 네트워크를 지원하는 가상 네트워크이다. 브릿지 네트워크는 도커 컨테이너가 가지고 있는 IP와 Host 이더넷 또는 물리 장비가 가지고 있는 네트워크를 연결해주는 역할을 한다. 브릿지 네트워크를 지원하기 위해서 docker0는 내부적으로 NAT서비스와 포트 포워딩 기능을 제공한다. 직접 도커가 지원하는 것은 아니고 IPtables로 해준다. virtual ethernet bridge : 172.17.0.0/16 값을 가지는 브릿지 네트워크가 docker0이고 브릿지 네트워크 안에서 docker0는 172.17.0.1 IP를 가지고 게이트웨이 역할을 한다. 컨테이너의 게이트웨이 역할과 L2통신을 지원해준다. 모든 컨테이너는 외부 통신을 docker0를 통해 진행한다. 컨테이너가 실행되면 172.17.x.x로 순차적으로 가상 IP를 할당한다.

 

-NAT : Network Address Translation의 약자로 패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP주소 정보를 수정하여 IP 주소를 다른 주소로 매핑하는 방법이다.

-IPtables : iptables 시스템 관리자 리눅스 커널 방화벽(다른 넷필터 모듈로 구현됨)이 제공하는 테이블들과 그것을 저장하는 체인, 규칙들을 구성할 수 있게 해주는 사용자 공간 응용 프로그램이다.

 

2. 컨테이너 포트를 외부로 노출

클라이언트는 eth0라는 인터페이스를 통해서만 들어올 수 있다. eth0에서 컨테이너까지 연결될 수 있도록 포트 포워딩이 진행되야한다.

-p 80:80 -p 호스트 포트:컨테이너 포트

-p 8080로 하면 실제로는 -p randomport:8080이 된다.

-P는 컨테이너 내부에서 도커 파일의 EXPOSE로 정의되어있는 포트에 맞춰서 렌덤 포트가 자동으로 맞춰진다.

 

3. user-defined bridge network 생성 방법

docker network create --driver bridge --subnet xxx.xxx.xxx.x/24 --gateway xxx.xxx.xxx.xxx mynet

subnet을 정해주지 않으면 docker0가 172.17.0.1을 사용하고 있으므로 172.18.0.1로 된다.

gateway를 생략하면 xxx.xxx.xxx.1번으로 된다.

 

docker network ls

위의 명령어는 docker의 네트워크 확인하는 명령어이다.

 

docker run -d —-name appjs —-net mynet —-ip 192.168.100.100 -p 8080:8080 smliux/appjs

위의 명령어는 docker에서 유저가 정의한 네트워크를 실행할 때의 명령어이다.

-ip 생략하면 순차적으로 알아서 생긴다. ex) 192.168.100.001 , 192.168.100.002 등등

 

4. 컨테이너끼리의 통신

프론트 컨테이너와 백엔드 컨테이너가 통신을 할 때를 예를 들면 wordpress가 있는데 wordpress는 웹페이지를 쉽게 제작할 수 있게 도와주는 Tool이다. wordpress 안에는 아파치 웹서버가 내장되어 있다. 또한 wordpress에서 만들어진 데이터는 MySQL에서 저장되게 구성되어있다.

 

mysql 실행

docker run -d —-name mysql -v /dbdata:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=pass -e MYSQL_PASSWORD=pass mysql

 

wordpress 실행

docker run -d —-name wordpress —-link mysql:mysql -e WORDPRESS_DB_PASSWORD=pass -p 80:80 wordpress

컨테이너와 컨테이너끼리의 통신은 --link를 통해서 연결된다. 컨테이너 이름:원하는 이름

 

728x90

+ Recent posts