docker0

container가 통신하기 위한 가상 linux bridge

brdige는 기본적으로 l2통신 기반임

container가 하나 생성되면 이 bridge에 cotainer의 interface가 하나씩 binding되는 형태

그래서 container가 외부로 통신할때는 무조건 docker0 interface를 지나야 한다.

특징

• IP는 자동으로 172.17.42.1로 설정됨. 16 bit netmask ( 255.255.0.0 ) 으로 설정
• IP는 DHCP를 통해 할당받는 것이 아닌 docker 내부 로직에 의해 자동 할당받음
• docker0는 일반적인 interface가 아닌 virtual ethernet bridge다.

• 유니온 파일 시스템 형식으로 이미지의 변경부분을 관리함

• 유니온 파일 시스템 형식

  • aufs
  • btrfs
  • devicemapper

• 도커는 베이스 이미지에서 바뀐 부분만 이미지로 생성

• 컨테이너로 실행시 베이스 이미지와 바뀐 부분이미지를 합쳐서 실행

• 각 이미지는 16진수로 ID를 구분한다.

Image Layer

이미지는 하나의 통짜 바이너리 덩어리가 아닌 여러개의 레이어로 이루어져 있다.

이 여러개 레이어는 계층구조로 이루어져 있다.

서로 다른 이미지가 여러개의 레이어를 공유할 수 있다.

만약 OS가 윈도우인 이미지를 받으면

이 윈도우 이미지와 동일한 이미지 위에 추가된 이미지들은 저 OS윈도우 이미지를 같이 사용한다.

그래서 이미지를 새로 받지 않는다.

( 모든 이미지 레이어는 한번만 받는다 )

이미지를 가져올때 도커는 각 레이어를 개별적으로 다운로드 한다.

여러개의 레이어가 이미 저장돼 있다면 도커는 저장되지 않은 레이어만 다운받는다.

이미지 삭제시 이미지가 사용중일 경우에는 이미지의 레이어들이 실제로 삭제 되지는 않는다.

참고

쿠버네티스 인 액션

시작하세요 도커 쿠버

www.notion.so/Linux-Container-cffb608779874506a6ac8df218105d36

컨테이너와 vm의 차이점

컨테이너

Linux Container는 linux의 가상화 기술을 사용하여 작동한다.

• 차이점

컨테이너에서 실행되는 프로세스는 다른 모든 프로세스와 마찬가지로 호스트 운영체제 내에서 실행된다.

( 프로세스가 별도의 운영체제에서 실행되는 vm과는 다르다 )

컨테이너의 프로세스는 여전히 다른 프로세스와 격리돼 있음.

컨테이너는 더 가벼움 → 이유는 ? vm은 각각 독립적인 게스트OS를 사용하지만

컨테이너는 하나의 호스트 운영체제 내에서 실행되기 때문이다.

( vm은 구성 요소 프로세스뿐만 아니라 시스템 프로세스도 실행해야 하기 때문에 컴퓨팅 리소스가 더 필요하다 반면 컨테이너는 하나의 격리된 프로세스에 지나지 않음 )

출처: https://blog.netapp.com/blogs/containers-vs-vms/

VM은 호스트OS위의 가상화 프로세스인 하이퍼바이저를 통해 가상 머신을 실행한다.

이 가상머신내에서 실행되는 어플리케이션이 자기자신의 게스트 OS 커널에 대한 시스템 콜을 수행하면 커널은 하이퍼바이저로 호스트의 물리적 CPU에서 x86명령을 수행한다.

하이퍼바이저는 두가지 타입이 있다.

1. 베어메탈의 하이퍼바이저는 직접 하드웨어를 제어하기 때문에 호스트OS가 없다.
   • Citrix Xen, VMWare ESX Server, MS Hyper-V등이 위 타입
2. 호스트 운영체제에서 실행되는 하이퍼바이저
   • VMware Server, QEMU, 오라클사의 VirtualBox등이 있다.

반면 컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.

이 커널은 호스트 CPU에서 x86명령을 수행하는 유일한 커널이다.

CPU는 가상머신과 같은 방식으로 어떠한 종류의 가상화도 필요가 없다.

출처 https://livebook.manning.com/book/kubernetes-in-action/chapter-1/68

Vm은 각 vm이 자체 리눅스 커널을 실행해 완전한 격리를 제공

컨테이너는 모든 컨테이너가 동일한 커널을 호출한다. 하지만 보안의 위험이 있음.

하드웨어 리소스가 한정적일 경우 실행시킬 프로세스가 적다 ?

그럼 vm

많이 돌려야된다 ?

그럼 컨테이너

컨테이너는 부팅이 필요가 없다 같은 커널을 공유하기 떄문에 그냥 프로세스 실행하면 바로 실행이 시작된다.

컨테이너는 어떻게 동일한 운영체제에서 프로세스를 격리시킬수 있는것인가 ?

리눅스 네임스페이스로 각 프로세스가 시스템 ( 파일, 프로세스, 네트워크 인터페이스 , 호스트 이름 등) 에 대한 독립된 뷰만 볼수 있도록 한다.

두번째는 Cgroup으로 프로세스가 사용할 수 있는 리소스 ( CPU, 메모리, 네트워크 대역폭 등) 의 양을 설정 또는 제한 할수 있다.

NameSpace

각 리눅스 시스템은 기본적으로 초기 구동시 하나의 네임스페이스가 존재한다.

파일시스템 , 프로세스 ID , 사용자 ID , 네트워크 인ㅍ터페이스 등과 같은 모든 시스템 리소스는

하나의 네임스페이스에 속한다.

여기서 추가 네임스페이스를 생성해서 리소스를 구성할수 있다.

프로세스를 실행할때 해당 네임스페이스 중 하나에서 프로세스를 실행한다.

프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼수 있다.

( 프로세스가 돌아가고있는 네임스페이스의 리소스만 볼수 있음 )

여러 종류의 네임스페이스가 있기 떄문에 프로세스는 하나의 NS에 속하는게 아니라 여러 NS에 속할수 있다.

NS의 종류

마운트, 프로세스 ID ( pid ) , 네트워크 ( net ) , 프로세스 간 통신 ( ipc )

호스트와 도메인 이름 ( uts )

• 이 UTS는 Unix Time Sharing으로 호스트 이름과 Network Inetrnet Service 일명 nis 도메인 이름 관련 네임스페이스다.

사용자 ID ( user )

UTS는 해당 네임스페이스 내에서 실행 중인 프로세스가 사용할 호스트 이름과 도메인 이름을 결정한다.

두개의 서로 다른 UTS 네임스페이스를 한쌍의 프로세스에 각각 지정하면

서로다른 로컬 호스트이름을 보게 할수도 있다.

즉 두 프로세스를 마치 두개의 다른 시스템에서 실행중인것처럼 보이게 가능 ( 호스트 이름만 )

마찬가지로 프로세스가 속한 네트워크 네임스페이스는 실행 중인 애플리케이션의 프로세스에서 볼 수 있는 네트워크 인터페이스를 결정한다.

각 네트워크 인터페이스는 정확히 하나의 ns에 속하지만 한 ns에서 다른 ns로 이동할 수 있다.

각 컨테이너는 고유한 네트워크 ns를 사용하므로 각 컨테이너는 고유한 ns interface set를 볼수 있다.

ns를 이용해 컨테이너에서 app을 분리하는 방법을 알수 있다.

Cgroup

Cgroup의 역할은 namespace로 각 컨테이너를 격리 시킨 후 각 컨테이너가 사용할 수 있는 시스템 리소스의 양을 설정하거나 제한하는 것.

( 프로세스의 리소스사용을 제한하는 것이 cgroup )

Cgroup를 이용하여 제한을 걸면 다른 프로세스용으로 예약된 리소스를 사용할수 없다.

이는 각 프로세스가 별도의 시스템에서 실행될때와 비슷하다.

초반 도커는 LXC를 이용하여 개발

0.9버전부터는 libcontainer를 개발하여 사용

현재는 runc 사용

참고

쿠버네티스 인 액션

시작하세요 도커 쿠버

jenkins_awscli

============================================

version: '3'
services:
        jenkins_awscli:
                restart: always
                image: ds/jenkins_cli:1.0
                volumes:
                        - ~/jenkins:/var/jenkins_home
                        - ~/.aws:/root/.aws
                ports:
                        - "8081:8080"
                        - "5000:5000"
                user: root

============================================

postgres

       위의 설정에 아래 설정을 그대로 이어서 붙어서 써준다.

============================================

       postgres:
                restart: always
                image: postgres
                environment:
                        - POSTGRES_USER=testuser
                        - POSTGRES_PASSWORD=testpass
                        - POSTGRES_DB=testbook
                ports:
                        - '5432:5432'
                volumes:
                        - ~/postgresql/data:/var/lib/postgresql/data

============================================

boot app 

        위의 설정에 아래설정을 그대로 이어서 붙어서 써준다.

============================================

 bootapp:
                image: openjdk:8-jdk-alpine
                restart: always
                container_name: "spring-boot-book"
                ports: -  "9765:9765"
                command: "java -jar app.jar --spring.config.location=file:///application-release.yml"

                environment:
                        -  "SPRING_PROFILES_ACTIVE=release"
                volumes:
                        - ~/boot/book/app:/usr/src/myapp
                        - ~/boot/book/env:/root/env
                        - ~/boot/book/log/spring:/log/spring

                        - ~/jenkins/workspace/git/bookReview/target/bookReview-0.0.1-bookReview.jar:/app.jar

                        - ~/properties/application-release.yml:/application-release.yml

               depends_on:

                        - postgres

============================================

- jar파일을 이어놓은이유는 따로 파일 옮길필요가 없이 바로 aws서버에서

도커명령어로 이미지를 만들기 위함이고

- application.yml도 이어놓은이유는

  깃이 퍼블릭으로 되어있는데 디비정보를 올릴수없어서 깃에는 기본 메모리db h2를 이용하게하고

  서버에 올려논 yml은 디비정보를 입력하여 디비에 접속가능하게함.

- java properties outside jar

- https://www.baeldung.com/spring-properties-file-outside-jar

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-application-property-files

docker-compose 

자세한설명 : 

https://www.44bits.io/ko/post/almost-perfect-development-environment-with-docker-and-docker-compose#docker-compose.yml-%ED%8C%8C%EC%9D%BC

docker-compose postgresql 

https://www.javacodegeeks.com/2020/03/docker-compose-for-spring-boot-application-with-postgresql.html

https://siner308.github.io/2019/03/02/postgres-docker-compose/

https://docs.docker.com/engine/examples/postgresql_service/

dockerfile 도커의 작업지시서 이미지 빌드를 어떻게 할것인가 적어놓는곳

FROM centos:7

WORKDIR /app

COPY 1.txt

CMD cat 1.txt

base로 쓸 도커 이미지는 centos7버전

이미지 컨테이너의 내부 디렉토리 /app으로 설정

1.txt파일을 workdir로 지정한 이미지 컨테이너의 내부 디렉토리로 복사

cat 1.txt 명령어를 컨테이너에서 실행

FROM은 base로 쓸 도커 이미지 이름을 적고

WORKDIR 은 이미지 컨테이너 내부의 디렉토리를 지정하고

COPY는 호스트에서 이미지 컨테이너로 복사할 파일을 지정

CMD는 이미지 컨테이너에서 실행할 명령어를 입력

docker build -t ds/dsimage:1.0 .

ds 이름

dsimage 이미지이름

1.0 버전

. 경로 (현재위치)

-it 실시간과 동시에 output을 받는 명령어

-p 포트 80:80 포트 설정 앞은 호스트의 포트 뒤는 컨테이너의 포트

-v 볼륨 설정 ${PWD}/data:/data:db containerName 컨테이너의 폴더를 호스트 폴더에 마운트시킴

                                                                   앞이 호스트폴더 뒤가 컨테이너 폴더

-t 태그부여

#컨테이너 목록

docker ps -a 

#이미지 다운로드

docker pull <image>

#컨테이너 삭제

docker rm <container>

#컨테이너 실행

docker start <container>

#컨테이너 중지

docker stop <container>

#컨테이너 로그

docker logs <container>

# mysql 컨테이너 생성 

docker run -p 3306:3306 --name mysql_boot -e MYSQL_ROOT_PASSWORD=1 -e MYSQL_DATABASE=springboot -e MYSQL_USER=ds -e

#mysql 컨테이너 접속

docker exec -i -t mysql_boot bash

mysql -u root -p

maridb도 위와 동일

# redis 컨테이너 생성

docker run -p 6379:6379 --name redis_boot -d redis

#redis 컨테이너 접속

docker exec -i -t redis_boot redis-cli

# postgresql 컨테이너 생성

docker run -p 5432:5432 -e POSTGRES_PASSWORD=pass -e POSTGRES_USER=ds -e POSTGRES_DB=springboot --name postgres_boot -d postgres

#postgresql 컨테이너 접속

docker exec -i -t postgres_boot bash

su - postgres

psql --username ds --dbname springboot

# mongodb 컨테이너 생성

docker run -p 27017:27017 --name mongo_boot -d mongo

#mongodb 컨테이너 접속

docker exec -i -t mongo_boot bash

mongodb

#도커설치

yum -y install docker docker-registry

#도커실행

systemctl start docker.service

centos 6.10 에서는 1.7.1이 깔수있는 최신버전

커널은 할수있는 가장최신으로 업데이트

censot 6.10 은 docker-io가 없기때문에 도커 엔진을 따로 설치해줘야함

curl -O -sSL https://get.docker.com/rpm/1.7.1/centos-6/RPMS/x86_64/docker-engine-1.7.1-1.el6.x86_64.rpm

rpm -ivhf docker-engine-1.7.1-1.el6.x86_64.rpm

이러면 설치 끝