인덱스

• 검색 속도를 높이기 위한 색인 기술
• JOIN / WHERE 에 사용됨
• 인덱스 없는 데이터 조회 시
  • 전체 데이터 페이지의 첫 레코드 -> 마지막 레코드까지 모두 조회 == FULL SCAN
  • 때문에 속도가 느림
• 그러나 INDEX를 많이 설정한다고 조회 속도가 빨라지지 않음
  • INDEX는 테이블 형태로 저장하는 것임
  • 즉 인덱스가 많아지면 데이터베이스 메모리를 많이 잡아 먹음
  • 인덱스로 지정된 칼럼 값이 변동되면, 인덱스 테이블이 갱신되므로 느려짐
  • 때문에 쿼리문 자체가 빨라질 수도 있지만, 전체적 데이터베이스 부하가 증가함
• SELECT는 빠르지만, UPDATE / INSERT / DELETE 속도는 느림
  • UPDATE / DELETE 시 WHERE을 통해 데이터 조회 자체는 빠름
  • 그러나 데이터 변경 / 삭제 자체는 느림

팁

• 카디널리티 : 카디널리티가 높으면 인덱스 설정에 좋은 칼럼
  • 카디널리티가 높다 == 한 칼럼이 갖고 있는 값의 중복도가 낮음 (대부분 다른 값을 가짐)
  • 인덱스 통해 불필요한 데이터 대부분을 걸러낼 수 있음
• 선택도: 선택도가 낮으면 인덱스 설정에 좋음
  • 선택도가 높다 == 한 칼럼이 갖고 있는 값 하나로 여러 row가 찾아진다.
• 조회 활용도: 조회 활용도가 높으면 인데스 설정에 좋은 칼럼
  • WHERE 문의 대상 칼럼으로 많이 활용되는지
• 수정 빈도: 수정 빈도가 낮으면 인덱스 설정에 좋은 칼럼
  • 인덱스도 테이블
  • 따라서 지정된 칼럼 값이 인덱스 테이블이 새롭게 갱시되어야 함

용어

• HEAP: 데이터 저장 시 내부적으로 아무런 순서 없이 저장된 데이터 저장 영역

  CREATE INDEX user_idx ON user_table (user_name);

UBUNTU에 Go 설치하기

• 항상 컨테이너로 GO 프로그램을 돌렸지만, 불가피하게 로컬에 GO를 설치해 빌드하고 돌려야 할 상황이 와서 해당 내용을 기록한다.

소스 다운 받아서 설치하기

최신 버전 확인

• 공식 사이트의 Golang 버전 확인 후 다운받기 (2024.10.21 시점 1.23.2)
• 공식 사이트

WGET을 이용해 다운로드

• WGET을 이용해 다운받기

  wget https://go.dev/dl/go1.23.2.linux-amd64.tar.gz

압축 해제

• 다운 받은 압축 파일 해제

  sudo tar -C /usr/local -xzf go1.23.2.linux-amd64.tar.gz

경로 설정

vi ~/.profile

# 파일 마지막 줄 아래에 내용 추가
export PATH=$PATH:/usr/local/go/bin
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

변경 사항 적용

source ~/.profile

Go 버전 확인

go version

UBUNTU 피키지 매니저로 다운받기

패키지 인덱스 업데이트

sudo apt update

GO 설치

sudo apt-get install golang-go

Go 버전 확인

go version

아래는 Jenkins 도입 과정과, 겪었던 시행 착오들에 대한 과거 기록들이다.

• 배포 과정은 아래와 같다.
  • Master 브랜치에 커밋이 발생함을 감지 (Merge 커밋)
  • Matser 브랜치의 소스 코드를 가져와 Docker 이미지 빌드
  • 빌드된 이미지를 Private Registry에 푸시
  • 배포할 서버에 .env 파일과 docker-compose.yml 파일 전송
  • 배포할 서버에 빌드된 이미지를 pull 하여 컨테이너 구동
• 이를 위해선 Github 연동과 Credentials 생성이 우선이다.

Github 설정

Github SSH KEY 연동

• 배포용으로 사용할 키 새성

ssh-keygen -t rsa -f jenkins

• .pub 키를 복사해서 계정/조직의 ssh 키를 추가해 복사해 넣는다
• Jenkins Credentials 추가
  • Kind: SSH Username with private key
  • ID 임의 설정
  • username: 깃허브 계정명
  • Private key: 생성된 jenkins 키 내용 전체 복사 붙여넣기
  • 이렇게 설정하니, Host key verification failed. 라고 하며 git fetch 실패 에러가 뜨더라
• Jenkins Secure 설정
  • 위 에러를 해결하기 위해 아래처럼 했다
  • Git Host Key Verification Configuration 설정 변경
    • Accep First connection 설정

Github Access Token

• 깃헙 계정 에서 personal access token 생성
  • settings - developer settings - personal access tokens - tokens(classic)
  • Classic Token 생성하기
    • exiration: No expiration
    • repo
    • admin:org
    • admin:repo_hook
  • 생성되는 값 복사해두기

Github WebHook 설정

• 레포지토리/조직의 설정으로 이동
• 탭 중 webhook 선택
• Add webhook 선택
  • url에 "${jenkins-url}/github-webhook/"입력
  • 생성하면, 성공 시 초록색 체크와 함께 완료된다
  • 실패 시, 이미 실패한 요청을 선택하여 redeliver하면 해결되더라

Jenkins 설정

Credential 설정

• Jenkins 관리로 이동
• Credentials - Stores scoped to Jenkins의 System 클릭 - Global credentials 클릭 -> Add Credentials 클릭
• 깃허브 레포지토리 / 조직 접근 키 설정 - 깃헙 웹훅 사용 용
  • Kind를 Secret Text로 설정
  • Secret에 위에서 복사한 Personal Access Token 값 붙여넣기
  • ID: 마음껏 설정 - 나중에 이 값으로 깃헙 연동해야 하므로 알 수 있게끔 설정
  • Description: 설명
• 개인 계정 - 아이템에서 깃헙 레포지토리 접근 용
  • Kind를 Username with password
  • username: 깃허브 계정 명
  • password: Personal Access Token 값
  • ID: 마음껏 설정
  • Description
• 서버 - 접속 SSH 키 세팅
  • Kind를 Username and SSH
  • private key에 SSH private key 입력
• 환경변수 파일 - 배포시 서버에 파일 전송.
  • Kind: Secret File
  • Id: 서비스 별로 분리할 수 있게끔 설정
  • 환경변수 파일 업로드

Github webhook 설정

• Jenkins 관리로 이동
• System 선택
  • 하단의 Github 탭의 Github Server 클릭
  • Name에 아무거나 임의로 입력
  • API URL은 건들지 말고
  • Credentials 에 위에서 secret text로 생성한 Credentials 선택
  • Manage Hooks 체크
  • Test connection 선택하여 연동 여부 체크

Jenkins Item 설정

• 실질적인 파이프라인 설정 내용
• 새로운 Item 클릭

Jenkinsfile로 사용할 시

• 소스코드 내에 Jenkinsfile을 위치시켜 이를 사용해서 빌드하는 방법
• Jenkinsfile에서 사용할 키는 위의 SSH Credential
• pipeline 선택
  • Github project 체크
    • project url 선택: git@github.com:{브랜치명}
    • Github hook trigger for GITScm polling 선택
    • pipeline 변경
      • Definiton을 Pipeline script from SCM 선택
      • SCM을 Git 으로 변경
      • Repository URL에 깃헙 레포 주소 입력
      • Credentials: 깃허브 SSH Credential 선택
      • Branch Specifier: 연동할 브랜치
• 이제 master 브랜치로 커밋이 감지될 때 마다 Jenkins가 레포 안의 Jenkinsfile을 감지해서 입력된 순서대로 동작할거다

Jenkins 파일 사용 안할 시

• freestyle project 체크
• 소스코드 관리 - Git 체크
• Repository Url: 깃헙 레포 주소 입력
• Credentials
• 깃허브 SSH Credential 선택
  • master: 연동할 브랜치 설정 * 빌드 유발
  • Github hook trigger for GITScm polling 선택 * 저장`
• 이제 Build Steps에 과정을 입력한다.

Plugins

• Docker common: 도커 통합 플러그인
• Docker Pipeline
• SSH Pipeline steps
• SSH Server
• Publish Over SSH

에러 해결 - 1 docker.sock 퍼미션

• Jenkins 빌드 과정에서 도커 이미지 빌드 내용이 있었다
• 여기에서 permission denied while trying to connect to the Docker daemon socket 에러 발생
• 결국 호스트의 var/run/docker.sock을 마운트하고 있기 때문이므로, 이를 수정해주었다.
• # 새로운 계정 생성 sudo adduser jenkins

권한 부여

sudo usermod -a -G docker jenkins

• 그럼에도 해결되지가 않았다
• 누군가는 chmod 666으로 변경하면 된다지만, 이럴 경우 권한이 너무 열려버려서 위험해질 수 있다고 한다.
• 아무튼 확인 결과 컨테이너 내부의 docker.sock은 root:999 으로 잡혀있었다.
  • root:docker 혹은 docker:1000이 되어야 할텐데
• 때문에 컨테이너 내부 접근해서 직접 퍼미션 체크를 해 줬다.

sudo docker exec -it -u root jenkins-host /bin/bash
chown root:docker /var/run/docker.sock

• 차후에 퍼미션 문제 없이 마운트 시키고 싶다

에러 해결 - 2 bad crum

• 사실 이 문제는 왜 해결됐는지 원인 파악이 다 되지 않았다.
• 내가 시도한 방식은 아래와 같다.
  • 아래 CURL 명령어 쏴서 해결해 보기 (참고: https://stackoverflow.com/questions/44711696/jenkins-403-no-valid-crumb-was-included-in-the-request)
  • 결과적으로 위 방식은 별 도움이 되지 않았다.
  • 일단 프록시 해제를 시키래서 시도는 해 봤다. 결과적으로 시간 두니 해결이 됐다.

curl -v -X GET https://{jenkins_url}/crumbIssuer/api/json --user dong:samquinnWkd1

curl -X POST https://{jenkins_url}/job/manage/credentials/store/system/domain/_/createCredentials/build --user dong:samquinnWkd1 -H 'Jenkins-Crumb: 9e107e40a5f7b6597e4020a4680bdda68b6b04c480aba07311166caa3bf98f9f'

레디스 개요 복습

• REDIS Remote Dictionary Server
  • 디스크가 아닌 주 메모리(RAM)에 데이터를 저장하는 데이터베이스
    • 따라서 데이터가 주메모리보다 크면 안됨
  • 단일 스레드로 설계됨
  • 디스크 검색이 필요한 다른 DBMS보다 자료 접근이 훨신 빠름
  • 때문에 성능 향을 위한 캐시 서버로 자주 사용됨
    • 자주 접근하는 데이터 및 계산에 많은 시간이 소요되는 데이터를 캐싱해 빠른 접근 제공
• 키 - 값 쌍을 가진 JSON 객체를 저장하는, 스키마 없는 데이터 베이스(NoSQL)

Redis Command

KEY 관련 명령어

• SET (key, value): 키 - 값 쌍을 설정
• GET (key): 주어진 키에 대한 값 조회
• DEL (key): 주어진 키 삭제
• EXISTS (key): 키 존재 여부 확인
• FLUSHALL: 모든 데이터 삭제
• KEYS (pattern): 특정 패턴을 가진 키 전체 조회
• SETEX (key, seconds, value): 특정 시간 후에 만료되는 키 - 값 쌍 설정
• TTL (key): 키의 만료까지 남은 시간 리턴

LIST 관련 명령어

• LPUSH (key, value): 배열 가장 첫번째에 요소(value) 추가
• RPUSH (key, value): 배열 가장 마지막에 요소(value) 추가
• LRANGE (key, startIndex, stopIndex): 시작 인덱스(startIndex)와 종료 인덱스(stopIndex) 사이의 요소 목록 리턴
• LPOP (key): 배열의 가장 첫번째 요소 제거
• RPOP (key): 배열의 가장 마지막 요소 제거

HASH 관련 명령어

• 단일 키 내에 {키 - 값} 쌍 저장이 가능
  • HSET (key, field, value): 키(field) - 값(value) 쌍을 해시 안에 세팅
  • HGET (key, field): 해시 안의 키(field)의 값을 가져옴
  • HGETALL (key): 해시의 모든 키-값 쌍 조회
  • HDEL (key, field): 해시에서 주어진 키(field) 삭제
  • HEXISTS (key, field): 해시 내의 키(field) 존재 여부 확인

REDIS Remote Dictionary Server

• 디스크가 아닌 주 메모리(RAM)에 데이터를 저장하는 데이터베이스
  • 따라서 데이터가 주메모리보다 크면 안됨
• 단일 스레드로 설계됨
• 디스크 검색이 필요한 다른 DBMS보다 자료 접근이 훨신 빠름
  • 때문에 성능 향을 위한 캐시 서버로 자주 사용됨
    • 자주 접근하는 데이터 및 계산에 많은 시간이 소요되는 데이터를 캐싱해 빠른 접근 제공
• 키 - 값 쌍을 가진 JSON 객체를 저장하는, 스키마 없는 데이터 베이스(NoSQL)
• 장점
  • 인메모리 키 - 값 저장소: 순수한 메모리 읽기는 빠른 읽기/쓰기 속도 및 빠른 응답 제공
  • IO 다중화(멀티플렉싱): 단일 스레드가 여러 개의 열린 소켓 연결에서 동시에 대기
  • 저수준 데이터 구조: 효율적인 저수준 데이터 구조 사용
• 단점
  • 휘발성: 시스템이 갑자기 중단되면 Redis 내의 데이터 손실 가능

Redis Cache 동작 방식

• 클라이언트의 데이터 요청
• Redis Cache에서 해당 키 탐색
• 키 발견 시 - Cache Hit
  • 캐시된 데이터 응답
• 키 발견 실패 시 - Cache Miss

결합도 Coupling

• 외부 모듈과의 연관도 또는 모듈 간의 상호의존성을 나타내는 정도
• 소프트웨어 구조에서 모듈간의 관련성을 측정하는 척도
• 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도
  • 결합도가 높을 수록 함께 변경해야 하는 모듈의 수가 늘어나게 됨

결합도 특징

• 모듈 연관성 없음
• 인터페이스 의존성
• 복잡성 감소
• 파급효과 최소화

결합도의 유형

• 자료 < 스탬프 < 제어 < 외부 < 공통 < 내용
• 내용 결합도
  • 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우의 결합도
  • 하나의 모듈이 직접적으로 다른 모듈의 내용을 참조할 때 두 모듈은 내용적으로 결합된 경우의 결합도
• 공통 결합도
  • 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고, 전역 변수를 갱신하는 식으로 상호작용 하는 경우의 결합도
• 외부 결합도
  • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우의 결합도
• 제어 결합도
  • 어떤 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어 신호를 이용해 통신하는 경우의 결합도
  • 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 상위 모듈에게 처리 명령을 부여하는 권리 전도 현상 발생하는 결합도
• 스탬프 결합도
  • 모듈 간의 인터페이스로 배열이나 객체, 구조 등이 전달되는 경우의 결합도
• 자료 결합도
  • 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈간의 상호 작용이 일어나는 경우의 결합도

응집도 Cohesion

• 모듈의 독립성을 나타내는 개념
• 모듈 내부 구성요소 간 연관 정도 의미
• 하나의 모듈은 하나의 기능을 수행하는 것을 의미
• 즉 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도
  • 하나의 변경을 수용하기 위해 모듈 전체가 변경 -> 높은 응집도
  • 하나의 변경을 수용하기 위해 일부 모듈의 일부만 변경 -> 낮은 응집도

특징

• 유사기능 영역 구성
• 단일 책임 할당
• 함수 간 상호 협력

유형

• 우연적 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적
• 우연적 응집도
  • 서로 간에 어떠한 의미 있는 연관 관계도 없는 기능 요소로 구성될 경우의 응집도
  • 서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행할 경우의 응집도
• 논리적 응집도
  • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우의 응집도
• 시간적 응집도
  • 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우의 응집도
• 절차적 응집도
  • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우의 응집도
• 통신적 응집도
  • 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우의 응집도
• 순차적 응집도
  • 모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용할 경우의 응집도
• 기능적 응집도
  • 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우의 응집도

결론

• 응집도는 높아야 하고, 결합도는 느슨해야 한다.
• 설계를 변경하기에 편리해 지기 때문

_Async/Await_

자바스크립트에서 async/await는 뭘까?

async/await는?

Promise 기반으로 동작하지만, then/catch/finally 와 같은 프로미스 후속 처리 메서드에 콜백 함수를 전달하여

비동기 처리 결과를 후속 처리할 필요 없이 마치 동기 처리처럼 프로미스를 사용할 수 있다.

결과적으로 Promise를 더 쉽게 다룰 수 있게 해 준다.

async/await을 사용하면 비동기 함수들을 마치 동기 함수처럼 작성하여 동작할 수 있게 해 준다.

function getData(){

/*

 비동기 함수

 */

}

// 프로미스

new Promise((resolve, reject) => {

const result = getData();

if ( /* 비동기 작업 수행 성공 */) {

resolve(result);

} else {

reject(result);

}

})


// async/await

async function getData() {

await /* 비동기 함수 */

}

Async

async 함수는 async 키워드를 사용해 정의하고, 언제나 프로미스를 반환한다.

Await

await 키워드는 프로미스가 settled 상태가 될 때까지 대기하다가 settled 상태가 되면 프로미스가 resolve 한 처리 결과를 반환한다.

참고 링크

- async/await (https://learnjs.vlpt.us/async/02-async-await.html)

자바스크립트에서 사용되는 Promise는 무엇일까?

콜백

콜백 함수는 다른 함수에 인자로 전달되는 함수로

어떤 함수의 동작에서 이벤트가 발생하였을 때, 혹은 특정 시점에 도달했을 때 호출하는 함수이다.

아래 예시는 정말 러프하게 이해할 수 있게끔만 적어놓은 함수이다. 단순한 구조라면 콜백 구조가 깊지 않지만, 복잡도가 높아짐에 따라 콜백 함수가 중첩되고 그 깊이가 엄청나게 깊어지는 것을 콜백 지옥이라 한다.

function getData(){

  /*

  비동기 함수

  */

}


getData().then(

  // 완료 되었을 때

).then().then().catch().finally()

Promise

Promise 객체는 ES6에서 추가된 개념으로, 비동기 작업이 작업 완료 후 미래의 완료 혹은 실패 결과를 나타낸다.

기존의 방식으로는 작성하게 된다면 콜백 지옥에 빠지게 된다.

또한 Promise 객체는는 비동기 함수들을 병렬로 수행할 수 있도록 하며 .all() 메서드와 .allSettled() 메서드를 프로퍼티로 가진다.

_출처: https://adrianalonso.es/desarrollo-web/apis/trabajando-con-promises-pagination-promise-chain/_

Promise는 비동기 작업을 수행하고 그 작업의 성공 혹은 실패 함수를 호출할 수 있다.

function getData(){

  /*

  비동기 함수

  */

}


new Promise((resolve, reject) => {

  const result = getData();


  if ( /* 비동기 작업 수행 성공 */) {

    resolve(result);

  } else {

    reject(result);

  }

})

Promise의 상태(State)

Promise 객체의 상태 정보는 세가지가 있다.

• pending: 비동기 처리가 아직 수행되지 않은 상태 - Promise 객체가 생성된 직후 기본 상태
• fulfilled: 비동기 처리가 수행된 상태 (성공) -> resolve 함수 호출
• rejected: 비동기 처리가 수행된 상태 (실패) -> reject 함수 호출

정리

• Promise는 콜백 지옥에 빠지는 비동기 처리를 간결하게 처리할 수 있게 표현
• 상태에는 pending, fulfilled, rejected 가 있다.
• 실행 결과에 따라 실패 시 reject, 성공 시 resolve 함수를 호출할 수 있다.

참고 링크

- Promise (https://learnjs.vlpt.us/async/01-promise.html)

도커 EXPOSE

• Expose는 컨테이너에 오픈할 포트를 의미한다.
• 즉 컨테이너에서만 열려있는 포트로, 동일한 도커 네트워크에 속해있지 않은 호스트나 외부에서 접근할 수 없다.

도커 PORT

• Port는 EXPOSE 된 컨테이너의 포트를 호스트에 열어주는 것을 의미한다.
• 앞의 포트는 호스트의 포트, 뒤의 포트는 컨테이너의 노출된 포트를 의미한다.
• 즉 동일한 도커 네트워크에 속해있지 않더라도, hostIP와 해당 포트를 알고 있다면 컨테이너에 접근이 가능해 진다.
• 컨테이너의 포트를 호스트와 연결시켜주는 것이므로, 컨테이너 포트와 동일할 필요가 없다
  • 이 말은 다시 말하면, 특정 포트(3306 / 5504 / 6379등) 만을 사용해야하는 어플리케이션에 대해 다양한 포트 번호를 호스트가 사용할 수 있게 되는 것이다.
  • 왜냐하면 특정 포트를 반드시 사용해야 한다는 제약은 컨테이너의 포트에만 적용될 수 있기 때문이다.
    • 3306만을 사용해야하는 mysql을 구동할 때, PORTS를 5587:3306으로 설정한다면 외부에서는 5587로 접근하지만 어플리케이션은 3306 포트를 사용하는 효과를 거둘 수 있는 것이다.

도커 네트워크

• 도커 네트워크는 일종의 내부망 이다.
  • 각 컨테이너들은 독립적인 네트워크 망을 가진다.
  • 정확히는 분리된 네트워크를 가진다 -> IP를 나눈다는 의미
  • 때문에 각 컨테이너별로 호스트와는 다른 가상의 IP 주소를 가진다.
• 도커 네트워크는 컨테이너가 끼리의 통신을 할 수 있는 범위라 말할 수 있을 것 같다.
• 기본적으로 컨테이너가 구동되게 되면 해당 컨테이너에 대한 default_network가 생성된다.
  • 이렇게 되면 다른 네트워크의 컨테이너와 소통할 수 없기 때문에 도커 외부로 우회하여 소통해야한다.
  • 컨테이너끼리 소통하기 위해 외부로 나갔다 들어와야 하기 때문에 성능적으로 저하가 발생하고, 보안적으로도 문제가 생길 수 있다.
• 그러나 동일한 네트워크에 속한 컨테이너들 끼리는, 컨테이너의 이름과 포트만으로 서로 통신이 가능하다.

컨테이너 구동 시 도커 네트워크 구성에 대해

• 컨테이너 구동 시, 순차적으로 도커 내부 IP 부여
  • 일반적으로 172.~~ 으로 시작하더라
  • 순차적으로 IP를 부여하기 때문에, 컨테이너를 내렸다 다시 올리면 컨테이너 IP가 변동 될 수 있음
• 도커 네트워크는 내부망이기에, 외부와 연결시켜야 함
  • 컨테이너 구동 시, 자동적으로 컨테이너 마다 호스트에 veth(Virtual Ethernet)라는 가상 네트워크 인터페이스를 생성함
  • 네트워크 관련 설정을 하지 않는다면 default0 브릿지를 사용함

Docker Bridge

• 도커 브릿지는 호스트와 컨테이너를 잇는 라우팅 경로
  • 즉 쉽게 말하면, 각 컨테이너에 가상의 IP를 부여하는 공유기 역할

도커 네트워크 전체 조회

• 현재 사용중인 도커 네트워크 리스트 조회

docker network ls

• 도커 네트워크 세부사항 조회

docker network inspect 

도커 네트워크 설정

• 도커 네트워크 설정
• docker network create <네트워크 이름>

컨테이너 네트워크 설정

• 같은 도커 네트워크에 해당하는 모든 컨테이너들은 서로 내부 통신이 가능함
  • 이미 db_mariadb 라는 컨테이너가 proxy라는 도커 네트워크 안에 구동되어 있다면
  • 지금 올리는 어플리케이션 컨테이너를 proxy라는 네트워크에 포함시킴으로 인해서, db_mariadb:3306 을 url로 잡으면 통신이 가능해짐
  • 같은 네트워크가 아니라면, 'HostIP:컨테이너 포트' 를 통해 접근할 수 있음
    • 문제는 컨테이너가 호스트에 포트를 열어둔게 아닌, 컨테이너 포트만 노출 시킨 상태라면 접근할 수 있는 방법이 없어짐
• 컨테이너 네트워크 설정 - docker compose
  • external: 컨테이너 구동 시 새로운 네트워크를 사용할지에 대한 여부를 설정하는 것
    • true: 기존 도커 네트워크를 할당함
    • false: 새로운 도커 네트워크를 생성함

  services:
      app:
          // 컨테이너 설정
          networks:
              - proxy
  
  networks:
      proxy:
        # proxy라는 새로운 네트워크를 생성하는게 아닌, 기존의 proxy라는 네트워크를 사용한다는 의미
          external: true

• 컨테이너 네트워크 설정 - Dockerfile

    docker run app_name --net proxy