Data Science Lab

SQL Server Edition 다운그레이드 후 확인사항

·       Version : SQL Server

SQL Server Enterprise Edition 에서 SQL Server Standard Edition으로 다운 그레이드 후 확인해야 할 몇 가지 사항에 대해서 알아본다. SQL Server Enterprise Edition을 SQL Server Standard Edition으로 다운그레이드 후 일부 구성이 기본값으로 다시 설정된다.

[SQL Server 오류 로그 수]

SQL Server 오류 로그 파일의 수가 기본 6개로 재설정된다. 이 설정을 확인하고 필요한 수로 설정한다. SSMS의 GUI를 사용할 수도 있으며 T-SQL 코드를 사용할 수 있다.

[SQL Agent 메일 프로필]

SQL Server Agent 속성의 메일 프로필이 비활성 된다. 메일 프로필 사용 시 올바른 메일 프로필이 사용되는지 확인 한다. SSMS에서 GUI를 사용하거나T-SQL 코드를 사용할 수 있다.

[토큰 교체 설정]

“Replace tokens for all jobs responses to alert” 옵션을 사용하는 경우 다시 활성화 해야 한다.  위  그림(SQL Agent 메일 프로필 그림) 처럼 SSMS의 GUI를 사용하거나 T-SQL 코드를 사용할 수 있다.

[기타 잠재적 문제]

위의 설정은 레지스트리를 통해 구성되는 설정이며 시스템 데이터베이스는 저장되지 않는다.

·       SQL Server 2014의 레지스트리 키 위치는 아래와 같다.

·       SQL Server 2017의 레지스트리 키 위치는 아래와 같다.

이 레지스트리 키 아래 저장되는SQL Server 에이전트는 다음과 같다.

·       AlertFailSafeEmailAddress

·       AlertFailSafeNetSendAddress

·       AlertFailSafeOperator

·       AlertFailSafePagerAddress

·       AlertNotificationMethod

·       DatabaseMailProfile

·       ErrorLogFile

·       ErrorLoggingLevel

·       IdleCPUDuration

·       IdleCPUPercent

·       JobHistoryMaxRows

·       JobHistoryMaxRowsPerJob

·       JobShutdownTimeout

·       MonitorAutoStart

·       RestartSQLServer

·       UseDatabaseMail

SQL Server Edition 다운그레이드 위 사항을 확인하여 시스템 운영에 참고 할 수 있도록 한다.

[참고자료]

https://www.mssqltips.com/sqlservertip/4698/sql-server-edition-postdowngrade-steps/

2019-04-11 / Sungwook Kang / http://sungwookkang.com

SQL Server, Edition post-down grade, Job Agent, Mail profile, Error log number, Token replacement setting, SQL registry key, MS SQL, SQL Edition

AlwaysOn 구성환경에서 Server Role 체크 후 Job Agent 실행 중지하기

·       Version : SQL Server

SQL Server에서 AlwaysOn을 구성하였을때, Failover 를 대비하여 Secondary 서버에서도 Primary서버와 동일하게 계정, Job Agent 등이 구성되어 있어야 한다. 그런데 Secondary의 경우 DB가 동기화 되고 있는 대기 서버이기 때문에 Job Agent를 Primary와 동일하게 설정하면 Secondary에서 Job 실행 시 Job Fail이 발생한다. 또한 Secondary에서 일부 Job 의 경우 실행이 되지 말아야 할 것들이 있다. 아래 스크립트는 AlwaysOn 의 role을 확인하여 서버가 Primary일 때만 Job Agent가 수행되도록 한다. 각각의 Job Agent의 첫 번째 단계에 추가하여 Primary Role이 아닐때 Job 수행을 중지하도록 한다.

Secondary에서 Job 이 실행되었을때, Role을 확인하는 부분이 있어 Job이 중지된것을 확인할 수 있다.

[참고자료]

https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-stop-job-transact-sql?view=sql-server-2017

2019-04-10 / Sungwook Kang / http://sungwookkang.com

SQL Server, AlwaysOn,  Job Agent, sys.dm_hadr_availability_replica_states, AG Role check

Docker Network

·         Version : Docker

Docker network는 컨테이너에 내부IP를 순차적으로 할당하고 컨테이너가 재시작 할 때마다 부여된 IP가 변경될 수 있다. 내부IP는 도커가 설치된 호스트의 내부망에서만 쓸 수 있기 때문에 외부와 통신을 하기 위해 veth* 라는 네트워크 인터페이스를 생성하여 외부와 통신한다.

도커가 설치된 호스트에서 ifconfig나 ip addr같은 네트워크 명령어로 인터페이스를 확인 해보면 실행중인 컨테이너 수 만큼 veth*로 시작하는 인터페이스가 생성된 것을 알 수 있다.

·         eth0 : 내부IP가 외부로 통신하기 위한 인터페이스로 호스트의 네트워크 이다. Eth0 네트워크가 각 veth*로 시작하는 네트워크와 통신한다.

·         docker0 : veth* 인터페이스와 바인딩되어 호스트의 eth0 인터페이스와 이어주는 역할을 한다.

도커가 제공하는 기본적인 네트워크는 bridge, host, none, container, ovelay가 있다. 도커를 설치하면 기본적으로 docker0 브릿지를 통해 외부와 통신할 수 있으며 선택에 따라 여러 네트워크 드라이버를 사용할 수 도 있다.

도커에서 생성되어 있는 네트워크를 확인은 docker network ls 명령어로 확인할 수 있다.

[bridge network]

사용자 정의 브릿지를 새로 생성하여 각 컨테이너에 연결한다. 컨테이너는 연결된 브릿지를 통해 외부와 통신한다. 아래 명령어로 mybrdge라는 네트워크를 생성할 수 있다.

docker run또는 create명령어에 --net 옵션의 값을 설정하면 컨테이너가 해당 네트워크를 사용한다.

서브넷, 게이트웨이, IP할당 등 임의로 설정하려면 네트워크를 생성할 때 아래와 같이 옵션을 추가한다. 주의할 점은 --subnet과 --ip-range 는 같은 대역 이어야 한다.

run 명령시 --net-alias 옵션을 함께 쓰면 alias이름으로 여러 개의 컨테이너에 접근할 수 있다.

컨테이너 생성이 완료되면 ping을 사용해서 각 컨테이너로 ping이 전송되는 것을 확인할 수 있다. Ping이 전달되는 IP 는 라운드로빈 방식으로 도커 엔진에 내장된 DNS가 ali01이라는 호스트 이름을 --net-alias dhqtusdmfh ali01로 설정한 컨테이너로 변환(resolve)하기 때문이다.

[host]

호스트 네트워크는 호스트의 네트워크 환경을 그대로 사용한다. 호스트 머신에서 설정한 호스트 이름을 컨테이너가 상속받기 때문에 컨테이너의 호스트 이름도 무작위 16진수가 아닌 도커 엔진이 설치된 호스트 머신의 호스트 이름을 설정 된다.

컨테이너의 네트워크를 호스트로 설정할 경우 별도의 포트 포워딩 필요없이 바로 서비스가 가능하다.

[none]

어떠한 네트워크도 사용하지 않겠다는 뜻이다. 외부와의 연결이 단절된다.

[container]

이 네트워크는 다른 컨테이너의 네트워크 환경을 공유할 수 있다. 공유되는 속성은 내부 IP, 네트워크 인터페이스의 MAC 주소 등이다. 사용법은 --net container:[컨테이너ID] 이다.

[overlay]

여러 도커 데몬 호스트 사이에 분산 네트워크를 만든다. 이 네트워크는 호스트 특정 네트워크 상단에 위치하여(오버레이) 호스트 서비스 네트워크에 연결된 컨테이너(swarm 서비스 컨테이너 포함)가 안전하게 통신할 수 있다. 도커는 대상 컨테이너간에 각 패킷 라우팅을 투명하게 처리 한다. swarm을 초기화 하거나 docker호스트를 기존 swarm에 가입 시키면 해당 도커 호스트에 두 개의 새로운 네트워크가 생성된다.

·         오버레이 네트워크라 불리는 Ingress는 swarm 서비스와 관련된 제어 및 데이터 트래픽을 처리한다. swarm 서비스를 생성하고 사용자 정의 오버레이 네트워크에 연결하지 않으면 기본적으로 ingress 네트워크에 연결된다.

독립 실행형 컨테이너가 다른 docker 데몬에서 실행되는 다른 독립 실행형 컨테이너와 통신하기 위해 사용할 수 잇는 오버레이 네트워크를 만들려면 --attachable 옵션을 사용한다.

·         브릿지 네트워크라 불리는 docker_gwbrdge는 브릿지 네트워크를 만드는것과 동일하게 docker network create 사용하여 사용자 정의 오버레이 네트워크를 만들 수 있다. 서비스 또는 컨테이너는 한번에 둘 이상의 네트워크에 연결할 수 있다. 서비스 또는 컨테이너는 각각 연결된 네트워크를 통해서만 통신할 수 있다.

swarm 서비스와 독립 실행형 컨테이너 모두 오버레이 네트워크에 연결할 수 있지만 기본 동작 및 구성 관련 사항은 다르다. 이러한 이유로 오버레이 네트워크에 적용되는 작업, swarm 서비스 네트워크에 적용되는 작업 및 독립 실행형 컨테이너에 사용되는 오버레이 네트워크에 적용되는 작업으로 나뉜다.

모든 swarm 서비스 관리 트래픽은 기본적으로 GCM모드의 AES알고리즘을 사용하여 암호화 된다. Swarm 관리자 노드는 12시간 마다 데이터를 암호화하는데 사용되는 키를 변화시킨다. 오버레이 암호화를 활성화하면 도커는 오버레이 네트워크 연결된 모든 서비스에 대해 IPSEC 터널을 만들어 통신한다.

[참고자료]

·         Docker Network Overview :  https://docs.docker.com/network/

·         Bridge networks : https://docs.docker.com/network/bridge/

·         Overlay neworks : https://docs.docker.com/network/overlay/

·         Host networks : https://docs.docker.com/network/host/

·         Disable networks : https://docs.docker.com/network/none/

2019-02-20 / Sungwook Kang / http://sqlmvp.kr

Docker, docker network, ingress, overlay, container, host, 도커 네트워크, swarm

Docker Compose

-         여러개의 컨테이너를 설정하고 생성하기

·         Version : Docker

Docker compose 명령은 여러개의 컨테이너 옵션과 환경을 정의한 파일을 읽어 컨테이너를 순차적으로 생성한다. 도커 컴포즈의 설정 파일(docker-compose.yml)은 run 명령어 옵션을 그대로 사용할 수 있으며 각 컨테이너의 의존성, 네트워크, 볼륨, 컨테이너 수 등을 유동적으로 조절할 수 있다.  예를 들어 파이썬 프로그램이 구동되는 컨테이너와 데이터를 저장하는 redis 서버,  웹서버 컨테이너를 실행한다고 할 때, 각각의 run 명령어 및 다양한 옵션으로 컨테이너를 생성하고 테스트하기에는 매우 번거롭다. 이때 도커 컴포즈를 활용하면 편리하다.

도커 컴포즈는 컨테이너 설정이 정의된 YAML 파일을 읽어 도커 엔진을 통해 컨테이너를 생성한다.

아래 스크립트는 docker-compose.yml의 예제 스크립트이다. YAML 파일에서 들여쓰기 할 때, 도커 컴포즈는 TAP을 인식하지 못하기 때문에 2개의 공백(Space)을 사용하여 하위 항목을 구분한다.

[docker-compose.yml]

·         Version : YAML 파일 포맷 버전

·         Service : 생성될 컨테이너들을 묶어 놓는 단위. 서비스 항목 아래에 각 컨테이너에 적용될 옵션을 지정

·         Web, visualizer, redis : 생성될 서비스 이름. 이 항목 아래에 컨테이너가 생성될 때 필요한 옵션을 지정

·         image : 컨테이너를 생성할 때 사용될 이미지 이름

·         link : docker run 의 --link와 같으며 다른 서비스에서 서비스명만으로 접근할 수 있도록 설정

·         environment : docker run의 --env, -e 옵션과 동일. 컨테이너 내부에서 사용할 환경변수 지정

·         command : 컨테이너가 실행될 때 수행할 명령어를 설정.

·         ports : docker run -p와 같으며 컨테이너를 개방할 포트를 설정.

·          

도커 컴포즈 관련 옵션은 매우 다양하게 지원되므로 자세한 내용은 공식 문서를 참고 할 수 있도록 한다.

·         Get Started with Docker Compose : https://docs.docker.com/compose/gettingstarted/

도커 컴포즈로 컨테이너를 생성하는 명령은 docker-compose up -d이다. 어떠한 설정도 하지 않으면 기본적으로 로컬 디렉터리의 docker-compose.yml 파일을 읽어 로컬의 도커 엔진에서 생성한다. 컨테이너 생성이 완료되면 docker ps에서 실행된 컨테이너를 확인할 수 있다.

[참고자료]

·         Get Started with Docker Compose : https://docs.docker.com/compose/gettingstarted/

2019-02-17 / Sungwook Kang / http://sqlmvp.kr

Docker,  dockerfile, docker build, 도커 파일, 도커 이미지 생성, dockerfile reference, docker compose, 도커 컴포즈, 도커 컨테이너, docker container

Docker build

-         Dockerfile을 이용해서 이미지 생성하기

·         Version : Docker

Docker build 명령은 dockerfile을 이용해서 이미지를 만드는 작업을 한다. dockerfile에는 이미지 생성시 필요한 작업이 스크립트로 작성되어 있다.

·         dockerfile : http://sqlmvp.kr/221465287824

아래 스크립트는 docker build를 사용해서 이미지를 생성한다.

·         -t : 생성될 이미지의 이름을 설정. 위 스크립트에서는 makeimage:0.0 라는 이름의 이미지가 생성된다. -t 옵션을 사용하지 않으면 16진수 형태의 이름으로 이미지가 생성된다.

·         ./ : build 명령어 끝에는 dockerfile이 저장된 경로를 입력한다. 로컬 디렉터리의 dockerfile을 사용할 수도 있으며 외부 URL로부터 dockerfile의 내용을 가져와 빌드할 수 도 있다. 위 예제에서는 로컬의 현재 디렉터리(./)를 입력했다.

Build를 시작하면 dockerfile의 내용이 실행되며 각 실행 단계가 출력된다.

빌드가 완료되면 docker image에서 생성된 이미지를 확인할 수 있다.

docekrfile에서 명령어가 하나씩 실행될 때마다 새로운 컨테이너가 하나씩 생성되며 이미지로 커밋한다. 즉 명령어가 실행될 때마다 이전 스텝의 이미지에 명령어가 실행되고 새로운 이미지 레이어로 저장된다.

[출처 : https://openliberty.io/blog/2018/06/29/optimizing-spring-boot-apps-for-docker.html]

dockerfile을 만들 때 주의할 점은 불필요한 작업으로 이미지 사이즈가 커지지 않도록 해야 한다. 예를들어 100MB 크기의 파일을 만들어 컨테이너에 할당하고 다시 삭제하는 명령이 있을때, dockerfiles은 이미지를 빌드하면서 각 단계마다 이미지 레이어를 만드는데,  최종 빌드가 완료된 상태에서 이미지에는 100MB크기의 파일이 존재하지 않지만 이미지의 크기는 기존 이미지에 100MB를 더한 크기를 가지고 있다. 즉, 파일을 삭제 했다는 레이어를 가지고 있으므로 실제론 파일이 없더라고 공간은 차지한다. 이러한 현상을 방지하기 위해서는 dockerfile을 작성할때 && 기호로 run 명령을 하나로 묶는것이다. 즉 여러개의 명령을 run  하나에서 실행하도록 하면 된다.

만약 다른 사람이 빌드한 이미지에 불필요한 이미지 레이어가 있으면 해당 이미지로 컨테이너를 생성하고  docker export, import 명령어를 사용해 컨테이너를 이미지로 만들면 레이어가 1개로 줄어들어 이미지의 크기를 줄일 수 있다. 그러나 이전 이미지에 저장된 각종 이미지 설정은 삭제되므로 주의해야 한다.

Docker build는 다양한 옵션이 있으므로 공식 문서를 참고할 수 있도록 한다.

·         docker build : https://docs.docker.com/engine/reference/commandline/build/

2019-02-14 / Sungwook Kang / http://sqlmvp.kr

Docker,  dockerfile, docker build, 도커 파일, 도커 이미지 생성, dockerfile reference

Docker file

-         이미지 생성시 필요한 작업을 스크립트로 만들기

·         Version : Docker

컨테이너를 생성하는 방법은 베이스 이미지를 이용하여 그 위에 다양한 애플리케이션을 설치하는 방법, 또는 이미 모든 환경이 구성된 컨테이너를 이미지로 만드는 방법 등 다양하다.

·         Docker Image생성 : http://sqlmvp.kr/221461385385

·         Docker Image 추출 : http://sqlmvp.kr/221463568253

이번 포스트에서는  Dockerfile 을 이용해서 이미지를 생성하는 방법에 대해서 알아본다. Dockerfile은 이미지를 생성하기 위해 컨테이너에 설치해야하는 패키지, 추가해야하는 소스코드, 실행시 필요한 명령어, 쉘 스크립트 등을 하나의 파일로 생성한 것이다. Build명령을 실행하면 Dockerfile을 읽어 이미지를 생성한다. Dockerfile을 사용하면 직접 컨테이너를 생성, 커밋, 배포하는 번거로움을 덜 수 있으며 배포 자동화에 용이하다.

도커 엔진에서는 Dockerfile을 읽어들일때 기본적으로 현재 디렉터리에 있는 Dockerfile이라는 이름을 가진 파일을 선택한다. 아래 스크립트는 Dockerfile 예시이며 각 명령의 기능에 대해서 살펴본다.

Dockerfile의 명령은 위에서 아래로 차례대로 실행한다.

·         FROM : 생성할 이미지의 베이스 이미지를 입력한다. 이미지가 로컬에 없다면 자동으로 도커허브에서 pull 한다.

·         LABEL : “키:값” 형태로 이미지에 메타데이터 추가. 추가된 메타 데이터는 docker inspect 명령어로 확인가능.

·         WORKDIR : 명령어를 실행할 디렉터리를 나타냄. Bash에서 cd 명령과 동일한 기능이다.

·         COPY : 로컬 디렉터리의 파일을 이미지에 복사하는 역할. ADD와 다른 점은 COPY는 로컬 디렉터리만 가능하고 ADD는 외부 URL및 tar 파일도 추가 가능하다.

·         RUN : 이미지를 만들기 위해 컨테이너 내부에서 명령어를 실행.

·         EXPOSE : Dockerfile의 빌드로 생성된 이미지에서 노출할 포트를 설정

·         CMD : 컨테이너가 시작될 때마다 실행할 명령어(커맨드)를 설정, Dockerfile에서 한번만 사용할 수 있다.

위의 예제를 정리해보면 아래와 같다.

Dockerfile은 다양한 명령어를 지원하며 자세한 내용은 아래 링크를 참고 한다.

·         Dockerfile reference : https://docs.docker.com/engine/reference/builder/

2019-02-13 / Sungwook Kang / http://sqlmvp.kr

Docker,  dockerfile, docker build, 도커 파일, 도커 이미지 생성, dockerfile reference

Docker Image 추출

·         Version : Docker

지난 포스트에 docker commit 명령을 사용하여 이미지를 생성한 다음 docker hub를 사용하여 이미지를 공유하는 방법에 대해서 다루었다.

·         도커 이미지 생성 : http://sqlmvp.kr/221461385385

이번 포스트에서는 이미지 파일을 단일 바이너리 파일로 저장하는 방법과 저장된 이미지 파일을 로드 하는 방법에 대해서 살펴본다.

 이미지를 파일로 추출하는 명령은 docker save이다. 이 명령을 사용하면 이미지의 모든 메타 데이터를 포함하는 하나의 파일로 추출할 수 있다.

·         --output, -o : STDOUT 대신 파일에 쓰기

추출된 이미지는 docker load 명령으로 도커에 다시 로드할 수 있다. 이미지를 로드하면 이전의 이미지와 동일한 이미지가 도커 엔진에 생성된다.

·         --input, -i : STDIN 대신  tar 아카이브 파일에서 읽기

·         --quiet, -q : 부하 출력 억제

docker save, load 와 비슷한 기능을 하는 명령으로 docker export, import가 있다.

export 명령은 컨테이너의 파일 시스템을 tar 파일로 추출하고 import는 추출된 파일을 이미지로 다시 저장한다. export 명령은 컨테이너와 연관된 볼륨의 내용을 내보내지는 않는다. 볼륨이 컨테이너의 기존 디렉터리 위에 마운트 되면 docker export는 볼륨의 내용이 아닌 기본 디렉토리의 내용을 내보낸다.

·         --output, -o : SDTOUT대신 파일에 쓰기

Import 명령을 사용할 때 STDIN에서 직접 데이터를 가져오기 위해 URL또는 –(대시)를 지정할 수 있다. URL은 파일 시스템이나  Docker 호스트의 개별 파일(.tar, .tar.gz, .tgz, .bˆp, .tar.xz, .txz)을 포함하는 아카이브를 가리킬 수 있다. 아카이브를 지정하면  Docker는 컨테이너에서 /(root)를 기준으로 아카이브에 압축 해제 한다. 개별 파일을 지정하는 경우 호스트 내 전체 경로를 지정해야 한다. 원격에서 가져오려면 http://또는 https://로 시작하는 URL프로토콜을 사용한다.

·         --change, -c : 생성된 이미지에 dockerfile 적용

·         --message, -m : 가져온 이미지에 커밋 메시지 설정

·         --platform : 서버가 멀티 플랫폼 가능하면 플랫폼 설정

[참고자료]

·         docker save : https://docs.docker.com/engine/reference/commandline/save/

·         docker load : https://docs.docker.com/engine/reference/commandline/load/

·         docker export : https://docs.docker.com/engine/reference/commandline/export/

·         docker import : https://docs.docker.com/engine/reference/commandline/import/

2019-02-11 / Sungwook Kang / http://sqlmvp.kr

Docker, 이미지 추출, docke save, docker load, docker import, docker export, 도커 로드

Docker Image 생성 및 docker hub에 이미지 업로드

·         Version : Docker

컨테이너는 기본적으로 이미지를 사용하여 생성하며, 컨테이너 생성 후 사용자 변경 부분에 대해서는 필요에 따라 새로운 이미지를 만들어서 배포하거나 재사용하기도 한다. 이번 포스트에서는 docker hub에서 이미지를 다운로드 (Pull), 업로드(push) 및 이미지를 생성(commit)하는 방법에 대해서 알아본다.

도커는 기본적으로 docker hub(https://hub.docker.com/)라는 중앙 이미지 저장소에서 이미지를 내려 받는다. 아래 그림처럼 docker hub는 도커가 공식적으로 제공하는 이미지 저장소로 누구나 가입 후 이미지를 내려 받을 수 있다. 또한 사용자 이미지를 도커 허브에 업로드하여 다른 사람과 공유할 수 있다.

[출처]  https://www.itzgeek.com/how-tos/linux/working-with-docker-images-building-docker-images.html

사용자가 docker create, docker run, docker pull의 명령을 실행하면 로컬에 해당 이미지가 없을 경우 docker hub에서 해당 이미지를 검색하여 다운로드 받는다. 대부분의 이미지가 공식적으로 제공되어 있기 때문에 직접 이미지를 만들어 사용하지 않아도 되므로 빠르고 편리하게 개발 및 운영 환경을 구축 할 수 있다. 아래 명령어는 docker hub에 이미지가 있는지 확인하는 명령어로 공식 이미지의 경우 “OFFICIAL” 라벨이 부여되어 있으며 “STARS”는 해당 이미지가 사용자로부터 얼마나 즐겨찾기가 되었는지를 나타낸다.

docker hub로 부터 이미지를 다운로드 받으려면 pull 명령을 사용한다.

베이스 이미지로부터 컨테이너를 생성하고 사용자가 변경 사항을 만들었다면 docker commit 명령을 사용하여 현재 컨테이너를 이미지로 만들 수 있다. 아무런 옵션을 사용하지 않으면 태그는 자동적으로 “latest”로 설정된다. -a 옵션은 작성자를 나타내며, -m은 커밋 메시지를 작성한다. 아래 스크립트는 nginx 라는 컨테이너를 nginx_sqlmvp:first로 이미지를 생성한다.

로컬에서 생성된 이미지를 공유하려면 리포지토리가 있어야 한다. Docker hub는 누구나 가입해서 무료로 리포지토리를 사용할 수 있다. 무료 계정의 경우 리포지토리가 퍼블릭이며, 유료로 사용할 경우 프라이빗 리포지토리를 이용할 수 있다. 또한 docker hub외에 프라이빗 리포지토리를 구축해서 사용할 수 도 있다. 아래 스크립트는 docker hub에 로컬의 이미지를 업로드(push)한다. docker hub에 업로드하기 전에 이미지에 리포지토리와 태그를 만들어야 한다.

[참고자료]

·         docker commit : https://docs.docker.com/engine/reference/commandline/commit/

·         docker pull : https://docs.docker.com/engine/reference/commandline/pull/

·         docker push : https://docs.docker.com/engine/reference/commandline/push/

2019-02-08 / Sungwook Kang / http://sqlmvp.kr

Docker, 이미지 생성, docker commit, docker push, docker tag, 도커 허브, 도커 커밋

Docker Container 리소스 제한

-         CPU, Memory, Disk I/O 리소스 사용량 설정

·         Version : Docker

컨테이너를 생성할 때 다양한 옵션으로 컨테이너 리소스 사용량을 조절할 수 있다. 아무런 옵션을 입력하지 않으면 기본적으로 호스트의 모든 리소스를 제한없이 사용할 수 있게 되어, 여러 컨테이너 실행 시 리소스 사용의 불균형이 발생할 수도 있다.

이번 포스트에서는 시스템 리소스(CPU, MEMORY, Disk I/O)를 컨테이너 실행시 설정하거나 이미 운영중인 컨테이너에서 리소스를 수정하는 방법에 대해서 살펴 본다.

현재 컨테이너에 설정된 리소스를 확인하는 방법은 docker inspect 명령을 사용한다. docker inspect 는 많은 항목을 나타내는데 “HostConfig” 항목에서 리소스를 확인할 수 있다.

[메모리 제한]

메모리는 m(Megabyte), g(Gigabyte) 단위로 설정 할 수 있으며 최소 메모리는 4MB이다. 컨테이너 내부에서 동작하는 프로세스가 컨테이너에 할당된 메모리를 초과하면 컨테이너는 자동으로 종료되므로 적절한 메모리를 설정해야한다. 아래 스크립트는 컨테이너 실행 시 메모리를 1 GB로 제한한다.

컨테이너가 실행되었으면 해다 컨테이너의 메모리를 확인한다. docker inspect는 많은 정보를 나타내므로 grep 명령어를 함께 사용하여 Memory 부분만 표시하였다.

컨테이너의 swap메모리는 기본적으로 설정된 메모리의 2배로 설정되지만 별도로 설정할 수 있다. 아래 스크립트는 swap메모리를 4GB로 설정한다.

[CPU제한]

컨테이너 CPU는 전체 CPU 사용량에서 리소스 할당을 설정한다. 즉, 가상머신의 경우 특정 갯수의 CPU를 할당 받지만 컨테이너의 경우 전체 사용량에서 얼마나 사용할지를 결정한다. 또한 CPU를 사용하는 다양한 옵션이 있다.

·         --cpu-shares : 기본값은 1024로 CPU 할당에서는 1을 뜻한다. 2048로 설정할 경우 기본 컨테이너보다 2배 많은 시간을 할당 받을 수 있다.

·         --cpuset-cpus : 호스트에 여러개의 CPU가 있을 때 컨테이너가 특정 CPU만 사용하도록 설정한다. 아래 스크립트는 컨테이너가 3번째 CPU만 사용하도록 설정한다.

·         --cpu-period, --cpu-quota : CPU 주기를 설정하며 -period의 기본값은 100000이며 100ms를 뜻한다, -quota는 -period에 설정된 시간 중 CPU 스케줄링에 얼마나 할당할 것인지 설정한다. 예를 들어 -period = 100000이고 -quota=25000을 할당하면 CPU주기가 ¼로 줄어 일반적인 컨테이너보다 CPU성능이 ¼로 감소한다. 즉 컨테이너는 -period/-quota만큼 CPU 할당을 받는다.

·         --cpus : 이전의 --cpu-period, --cpu-quota, --cpu-share와 비슷하지만 좀더 직관적으로 CPU사용량을 정의할 수 있다. 예를 들어 --cpus=0.1이라고 한다면 해당 컨테이너는 전체 CPU 중에 10%를 사용한다는 뜻이다.

[I/O 제한]

컨테이너 생성시 아무런 제한을 하지 않으면 디스크I/O또한 모든 대역폭을 하나의 컨테이너가 다 사용할 수 있으므로 상황에 따라 I/O 제한 설정이 필요하다.  사용 형식은 [디바이스이름]:[값] 이다.

·         --device-write-bps, --device-read-bps :  초당 읽기, 쓰기를 MB 단위로 설정하여 대역폭 제한한다. 아래 스크립트는 초당 쓰기를 10MB 로 제한한다.

·         --device-write-iops, --device-read-iops : IO에 대한 상대적인 값으로 아래 스크립트는 디스크에 대해 10IOPS로 제한한다는 뜻이다.

[실행중인 컨테이너 리소스 재설정]

이미 실행중인 컨테이너의 리소스 설정을 변경할 때에는 docker update 명령을 사용한다. 아래 예제는 CPU 사용량을 10%로 제한한다.

[참고자료]

·         docker run : https://docs.docker.com/engine/reference/commandline/run/

2019-02-06 / Sungwook Kang / http://sqlmvp.kr

Docker, 컨테이너 리소스 제한, 도커 자원 할당, 컨테이너 설정, 컨테이너 CPU, 컨테이너 메모리, 컨테이너 I/O

Docker Container 로그 확인

-         컨테이너에서 발생하는 다양한 로그 확인

·         Version : Docker

어떠한 시스템을 운영하던지 로그는 매우 중요하다. 로그는 현재 서비스의 다양한 상태를 확인할 수 있는 훌륭한 도구이기 때문이다. Docker의 경우 다양한 방법으로 컨테이너 로그를 남기는데, 이번 포스트에서는 컨테이너의 표준 입력(STDIN),  표준 출력(STDOUT), 표준 오류(STDERR) 로그를 별도의 메타데이터 파일로 저장하며 이를 확인하는 방법에 대해서 살펴본다.

컨테이너의 로그를 확인하는 명령은 docker logs를 사용한다. docker logs 명령은 컨테이너의 표준 출력을 표시함으로써 애플리케이션 상태를 알 수 있다.

컨테이너의 로그가 너무 많아 읽기 힘들면 --tail 옵션을 사용하여 마지막 로그부터 사용자가 지정한 라인까지 출력하도록 할 수 있다. 아래 예시는 마지막 로그의 10줄만 표시한다.

--since 옵션은 입력 받은 유닉스 시간 이후의 로그를 확인할 수 있으며 -t옵션으로 타임 스탬프를 표시할 수도 있다.

-f 옵션을 사용하면 실시간으로 생성되는 로그를 스트림으로 확인할 수 있다.

로깅 드라이버는 기본적으로 json-file로 설정되지만 도커 데몬 시작 옵션에서 --log-driver 옵션을 사용하여 기본적으로 사용할 로깅 드라이버를 변경할 수 있다. 아래 스크립트는 nonoe 로깅드라이버로 alpine 컨테이너를 시작한다.

실행중인 컨테이너의 로깅 드라이버를 확인하려면 docker inspect 명령을 실행한다.

현재 로깅 드라이버는 매우 다양하게 지원되고 있으며 아래 링크에서 지원되는 드라이버를 확인할 수 있다.

·         Configure logging drivers  : https://docs.docker.com/config/containers/logging/configure/

docker logs 명령은 json-file 및 journald이외의 드리이버에서는 사용할 수 없다.

[참고자료]

·         View logs for a container or service  : https://docs.docker.com/config/containers/logging/

·         Configure logging drivers  : https://docs.docker.com/config/containers/logging/configure/

2019-02-03 / Sungwook Kang / http://sqlmvp.kr

Docker, docker logs, 컨테이너 로그

Docker Volume (도커 볼륨)

-         도커 볼륨을 이용해서 데이터 공유하기

·         Version : Docker

Docker 컨테이너가 삭제(또는 재시작)되면 컨테이너의 변경된 데이터가 함께 삭제된다.  데이터를 영속적으로 보존하기위해 volume  옵션을 사용하여 호스트 의 저장소를 마운트하여 사용한다.

·         Docker Volume (호스트 볼륨 공유) : http://sqlmvp.kr/221449590567

·         Docker Volume (컨테이너 볼륨 공유) : http://sqlmvp.kr/221451346970

이번 포스트에서는 도커 자체에서 제공하는 볼륨 기능을 활용하는 방법에 대해서 알아본다. 볼륨을 생성할 때 플러그인을 사용하여 다양한 종류의 스토리지 백엔드를 쓸 수 있지만 이번 포스트에서는 기본적인 도커 엔진에서 제공되는 local을 사용한다.

 도커 볼륨을 생성하는 명령어는docker volume create 를 사용한다. 생성된 볼륨을 확인하는 방법은 docker volume ls 이다.

도커 볼륨은 실제 호스트의 어느 경로에 만들어 졌는지 확인하는 방법은 docker volume inspect 명령을 사용한다.

도커 볼륨을 삭제하는 명령어는docker volume rm 이다. 참고로 컨테이너를 삭제해도 볼륨은 자동으로 삭제되지 않는다.

사용되지 않는 모든 볼륨을 삭제하려면 아래 명령을 실행 한다.

도커 볼륨을 사용하는 컨테이너를 생성하기 위해서는 [볼륨이름]:[컨테이너 공유 디렉터리]  순으로 명령을 입력한다. 아래 예시는 my-vol이라는 볼륨을 컨테이너의 /app 디렉터리에 마운트 한다. /app 디렉터리에 파일을 쓰면 해당 파일이 볼륨에 저장된다.

도커 볼륨은 여러 컨테이너에서 사용할 수 있으므로 아래 그림처럼 파일을 쉐어하여 머신간에 데이터를 공유할 수 있다.

만약 여러 컨테이너가 있고 여러 볼륨이 있을 때 해당 컨테이너가 어떤 볼륨을 사용하는지 확인하는 명령은 docker container inspect를 사용한다. 이 명령은 컨테이너의 상세한 정보를 나타낸다.

컨테이너가 아닌 외부에 데이터를 저장하고 컨테이너는 그 데이터로 동작하도록 설계하는 것을 스테이트리스(stateless)라고 하며 컨테이너 내부에 데이터를 저장하고 상태가 있는 경우 스테이트풀((stateful)하다고 한다.

[참고자료]

https://docs.docker.com/storage/volumes/

2019-02-02 / Sungwook Kang / http://sqlmvp.kr

Docker, docker volume, 도커 볼륨, 도커 명령어, 도커 파일 공유, 도커 호스트 디렉터리 공유

Docker Volume (컨테이너 볼륨 공유)

-         컨테이너 볼륨을 다른 컨테이너와 공유하기

·         Version : Docker

Docker 컨테이너가 삭제(또는 재시작)되면 컨테이너의 변경된 데이터가 함께 삭제된다.  데이터를 영속적으로 보존하기위해 volume을 사용하는데 지난 포스트에서는 호스트의 디렉터리를 컨테이너와 공유하여, 컨테이너의 데이터 파일을 호스트에 저장하는 방법에 대해서 알아 보았다.

·         Docker Volume (호스트 볼륨 공유) : http://sqlmvp.kr/221449590567

이번 포스트에서는 볼륨을 사용하는 컨테이너를 다른 컨테이너와 공유하는 방법에 대해서 살펴 본다.  컨테이너를 생성할 때 --volumes-from 옵션을 설정하면 -v 또는 -volume 옵션을 적용한 컨테이너의 볼륨 디렉터리를 공유할 수 있다.

여러 컨테이너가 동일한 컨테이너에 --volume-from 옵션을 사용하여 볼륨을 공유하여 사용할 수 도 있다. 이러한 구조를 활용하면 호스트에서 볼륨만 공유하고 별도의 역할을 담당하지 않는 볼륨 컨테이너로서 활용할 수 있다.

아래 실습을 통해서 볼륨 컨테이너를 공유하는 방법에 대해서 살펴본다. 우선  볼륨 컨테이너로 사용할 컨테이너에 호스트 볼륨을 공유한다.

볼륨 컨테이너에 연결할 컨테이너를 실행한다. 이때 --volumes-from [볼륨 컨테이너이름] 옵션을 사용하여 컨테이너의 볼륨을 공유한다.

볼륨 컨테이너에 동시에 여려 컨테이너가 볼륨을 공유하는지 확인하기 위해서 다른 컨테이너를 하나 더 실행한다.

호스트 볼륨이 공유된 볼륨 컨테이너의 디렉터리가 다른 컨테이너에 공유된 것을 확인할 수 있다.

[참고자료]

https://docs.docker.com/storage/volumes/

2019-01-25 / Sungwook Kang / http://sqlmvp.kr

Docker, docker volume, 도커 볼륨, 도커 명령어, 도커 파일 공유, 도커 호스트 디렉터리 공유

Docker Volume (호스트 볼륨 공유)

-         컨테이너 데이터를 호스트 디스크에 저장하기

·         Version : Docker

Docker 이미지로 컨테이너를 생성하면 이미지는 읽기 전용이 되며 컨테이너의 변경된 부분만 별도로 저장해서 컨테이너의 정보를 보존한다. 컨테이너에 저장된 데이터는 컨테이너가 삭제되면 데이터가 함께 삭제된다. 이러한 문제를 해결하기 위해서 데이터를 영속적(Persistent)로 저장하는 방법에는 몇 가지가 있으며 이번 포스트에서는 볼륨(Volume)에 대해서 살펴본다.

볼륨은 Docker 컨테이너에 의해 생성되고 Docker컨테이너에 의해 사용되는 데이터를 유지하는 기본 메커니즘이다. 바인드 마운트는 호스트 시스템의 디렉터리 구조에 따라 다르지만 Volume은 Docker에 의해 완벽하게 관리된다. 볼륨에는 바인드 마운트에 비해 몇 가지 장점이 있다.

·         바인드 마운트보다 볼륨을 백업하거나 마이그레이션 하는 것이 더 쉽다.

·         Docker CLI 명령 또는 Docker API를 사용하여 볼륨을 관리할 수 있다.

·         볼륨은 Linux 및 Windows컨테이너에서 작동한다.

·         볼륨은 여러 컨테이너간에 안전하게 공유할 수 있다.

·         볼륨 드라이버를 사용하면 원격 호스트 또는 클라우드 공급자에 볼륨을 저장하고 볼륨 내용을 암호화하거나 다른 기능을 추가할 수 있다.

·         새 볼륨은 컨테이너에 의해 미리 채워진 내용을 가질 수 있다.

호스트 볼륨을 공유하는 방법은 컨테이너를 생성할 때 -v 옵션을 사용하여 호스트의 디렉터리와 컨테이너 디렉터리를 공유한다. 아래 예제는 호스트의 myvol2볼륨을 컨테이너의 /app에 마운트 한다.

만약 마운트 하려는 볼륨이 호스트에 존재하지 않으면 호스트에 해당 디렉터리가 생성되면서 컨테이너와 공유 된다(컨테이너의 파일이 호스트로 복사됨). 이렇게 -v 옵션으로 공유된 디렉터리는 컨테이너가 삭제되더라도 호스트의 디렉터리는 삭제되지 않기 때문에 데이터를 보전할 수 있다. 볼륨 공유는 디렉터리 단위 뿐만 아니라 파일 단위의 공유도 가능하며 여러 개의 -v 옵션을 사용하여 동시에 여러 볼륨 공유도 가능하다.

만약 호스트에 이미 디렉터리가 존재하고 컨테이너에도 존재할 때 두 디렉터리를 공유하면 어떻게 될까? 결과적으로는 컨테이너의 파일이 삭제되고 호스트의 파일이 공유된다. 즉, 컨테이너의 디렉터리 자체가 덮어 써지는 것이다. (호스트의 디렉터리가 컨테이너의 디렉터리에 마운트 되는 방식이다.)

아래 실습은 MAC에 설치된 Docker 환경에서 Volume을 공유하는 예시이다. 우선 볼륨을 공유하기 전에 Docker 속성에서 호스트(MAC)의 디렉터리가 공유되어 있는지 확인한다. 호스트의 디렉터리가 아래 Docker 환경에 공유되어 있지 않으면 사용할 수 없다.

필자의 경우 이미 다운로드 받은 이미지를 컨테이너로 실행하면서 볼륨을 공유하였다.

호스트(MAC)의 /tmp 하위에는 sharetest라는 디레겉리가 존재하지 않았지만 컨테이너가 실행되면서 해당 디렉터리가 생성되었다.

컨테이너의 디렉터리를 조회하면 호스트의 sharetest 디렉터리가 공유된 것을 확인할 수 있으며 호스트의 파일이 조회되는 것을 확인할 수 있다.

호스트에서 볼륨을 확인하려면 아래 명령을 실행한다. 볼륨 이름을 지정하지 않으면 무작위의 16진수 형태로 생성된다.

위에서도 언급하였지만 컨테이너를 삭제한다고 해서 호스트의 볼륨이 삭제되지는 않는다. 따라서 불필요한 볼룸은 호스트에서 수동으로 삭제해주어야 한다. 아래 스크립트는 특정 볼룸을 삭제 한다.

아래 스크립트는 모든 볼륨을 삭제 한다.

[참고자료]

https://docs.docker.com/storage/volumes/

2019-01-23 / Sungwook Kang / http://sqlmvp.kr

Docker, docker volume, 도커 볼륨, 도커 명령어, 도커 파일 공유, 도커 호스트 디렉터리 공유

Docker Command Basic (도커 기본 명령어)

·         Version : Docker

도커의 기본적인 명령 구조

도커 버전 정보 확인

https://docs.docker.com/engine/reference/commandline/version/

·         --format, -f : 주어진 템플릿 형식을 사용하여 출력

·         --kubeconfig : 쿠버네티스 설정 파일

설치된 이미지 목록 조회

https://docs.docker.com/engine/reference/commandline/images/

·         --all, -a : 모든 이미지 표시

·         --digests : 요약 보기

·         --filter, -f : 제공된 출력에 따라 출력 필터링

·         --format : Go 템플릿을 사용한 Pretty-print 이미지 사용

·         --no-trunc : 출력을 자르지 않음

·         --quiet, -q : 숫자만 표시

설치된 이미지 삭제

https://docs.docker.com/engine/reference/commandline/rmi/

·         --force, -f : 강제로 이미지 삭제

·         --no-prune : 태그 없는 부모는 삭제 제외

설치된 모든 이미지 강제 삭제

컨테이너 목록 조회