Dockerfile 작성 모범 사례 컨테이너의 설계 철학에 맞게 이미지를 만들어야 생산성이 높아지고 운영 중 겪게 될 문제를 사전에 예방할 수 있다. 종래의 오케스트레이션 도구인 Ansible이나 Chef 등은 서버들의 목표로 하는 상태로 만든다는 사고 방식으로 동작한다. 그리고 그 동작 방식은 멱등성(Idempotence)에 기초하여 몇 번을 배포해도 한결같이 목표로 하는 상태로 만들어 준다. 이들 도구들은 서버의 기동이나 설정에 오랜시간 걸리는 것을 고려하여 만들어졌다. 도커의 경우는 Dockerfile에 운영체제와 의존 패키지를 기술하여 이미지를 만들면 굉장히 짧은 시간에 컨테이너를 기동/교체/종료할 수 있다. 그리고 이미지에는 운영체제와 패키지가 이미 모두 포함되어 있으므로 배포 시 추가적인 시간..
도커
이미지 빌드의 개요 위 이미지는 컨테이너의 이미지를 만드는 과정을 표현한다. 도커 이미지를 만들기 위해서는 명령어 docker build [옵션] 경로|URL|-을 사용하면 된다. 베이스 이미지 선택 이미지를 만들 때 바탕이 되는 이미지를 베이스 이미지라고 한다. 베이스 이미지에는 리눅스의 공유 라이브러리, 동적 링크나 로드에 필요한 기초적인 파일들이 포함되어, 이를 기반으로 사용자의 이미지를 만들게 된다. 도커 허브에는 다양한 미들웨어나 프로그래밍 언어가 포함된 이미지가 등록되어 있다. 분류 공식 이미지 리눅스 배포판 alpine, busybox, ubuntu, centos, debian, fedora, amazonlinux, opensuse, oraclelinux 프로그래밍 언어 node, golan..
여러 터미널에서 조작하기 2개 이상의 터미널에서 하나의 컨테이너에 접속하여 작업을 수행하는 것도 가능하다. 이처럼 같은 컨테이너에 여러 터미널이 접속하여 작업하는 것이 가능하다. 인증 과정도 없기 때문에 가상 서버보다 더 편리하게 사용할 수 있다. 이때 보안을 위해 호스트 외부에서 접속은 막혀 있다. 또한 컨테이너 내에는 외부에서 로그인하기 위한 sshd를 기동시키지 말아야 한다는 의견도 있다. 로그인을 관리하지 않는 컨테이너 리눅스 서버에서는 w 명령어로 동시에 로그인한 다른 유저의 정보를 얻을 수 있다. 하지만 아무것도 출력되지 않는다. 이유는 컨테이너에 로그인을 통한 유저 인증 기능도 없고, 유저 자체를 관리하지 않기 때문이다. 리눅스는 기본적으로 멀티 유저용으로 개발되었지만 컨테이너는 싱글 유저용..
대화형 모드로 컨테이너 기동 및 정지 일반적인 리눅스 서버에서는 유저가 로그인에 성공하면 이어서 셸이 기동된다. 그러면 터미널을 통해 셸에 명령어를 전달하고 수행 결과가 터미널에 출력된다. 도커에서도 컨테이너에서 셸을 실행할 수 있다. 대화형 모드로 컨테이너 기동(docker run -it) 대화형 모드로 컨테이너를 기동하기 위해서는 docker run -it 리포지터리명:[태그] 셸 과 같이 명령어를 실행해야 한다. 여기서 옵션 -i는 키보드의 입력을 표준 입력(STDIN)으로 셸에 전달하고 옵션 -t는 유서 터미널 디바이스(pts)와 셸을 연결한다. 옵션 --name은 컨테이너의 이름을 지정할 수 있다. 이로써 셸은 터미널과 접속되어있다고 인식하여 셸의 프롬프트를 출력하게 된다. 우분투나 CentOS..
컨테이너 환경 표시 도커 클라이언트와 서버 버전 표시 docker version 구체적인 환경 정보 표시 docker info 컨테이너의 3대 기능 기본이 되는 기능을 뽑자면 아래 3가지 기능이다. 1. 컨테이너 이미지 빌드 현 디렉터리에 있는 Dockerfile을 바탕으로 이미지를 빌드 docker build -t 리포지터리:태그 . docker image build -t 리포지터리:태그 . 로컬 이미지 목록 docker images docker image ls 로컬 이미지 삭제 docker rmi 이미지 docker image rm 이미지 로컬 이미지 일괄 삭제 docker rmi -f 'docker images -aq' docker image prune -a 2. 이미지의 이동과 공유 원격 리포지터..
컨트롤러란? 컨트롤러는 파드를 제어한다. 파드에게 부여할 워크로드의 타입, 즉 처리에 따라서 적절한 컨트롤러를 선택해야 한다. 워크로드 타입 프런트엔드 처리 스마트폰, IoT기기, 컴퓨터 등의 클라이언트로부터 요청을 직접 받아들이는 워크로드를 총칭한다. 이 타입의 워크로드는 대량의 클라이언트 요청에 대해 짧은 시간에 응답을 반환하는 것이 중요하다. 실시간으로 반응해야 하고 사용자들이 답답합을 느껴선 안된다. IoT 기기로부터의 요청은 기기로 부터 끈임없이 만들어지는 데이터를 받아들여서 처리해야 한다. 이러한 워크로드 특성에 대응하기 위해서는 요청에 대응하는 처리를 복수의 파드에 분담하도록 설계해야 한다. 또한, 24시간 무정지로 서비스를 제공하면서도 빠르게 신기능을 배포할 수 있어야 한다. 백엔드 처리 ..
파드의 라이프 사이클 쿠버네티스의 트러블 슈팅 중 가장 많이 발생하는 것이 파드의 기동 실패 원인 분석이다. 개인의 개발 환경에서 컨테이너 이미지를 빌드하고 쿠버네티스 환경에 배포했을 때 제일 먼저 경험하는 것이 컨테이너가 기동하지 않거나 재시작을 반복하는 현상이다. 파드의 상태가 가지는 의미를 이해하고 적절한 대처를 할 수 있어야 문제를 해결할 수 있다. 문제를 파악하기 위해서는 kubectl get pods 명령어를 실행 해 나타나는 STATUS 열의 정보가 중요하다. 이 필드의 정보는 Kubernetes API를 통해 획득하는데, 이 API를 통해서 얻을 수 있는 다양한 정보 중에서 도움이 될 만한 정보가 선별되어 STATUS 열에 표시된다. STATUS 의미와 대책 ContainerCreating..
파드란? 파드는 쿠버네티스에서 컨테이너를 실행하는 최소 단위로 한개 혹은 여러 개의 컨테이너를 포함한다. 하나의 파드에 속하는 모든 컨테이너들은 같은 노드에서 동작한다. 파드는 다음과 같은 특징을 가진다. 컨테이너 재사용 촉진을 위한 플랫폼 파드는 하나의 목적을 위해 만들어진 컨테이너를 부품처럼 조합할 수 있도록 설계되었다. 파드 내부의 컨테이너들은 파드의 IP 주소와 포트번호를 공유한다. 파드의 내부 컨테이너들은 localhost로 서로 통신할 수 있다. 파드의 내부 컨테이너들은 System V 프로세스 통신이나 POSIX 공유 메모리를 사용하여 서로 통신할 수 있다. 파드의 내부 컨테이너들은 파드의 볼륨을 마운트하여 파일 시스템을 공유할 수 있다. 이 기능들은 같은 파드 내의 컨테이너 사이에서만 가능..
쿠버네티스 API란? 쿠버네티스의 대한 조작은 모두 API를 통해 이뤄진다. 커맨드 라인 유저 인터페이스인 kubectl은 마스터 노드상의 kube-apiserver에게 쿠버네티스 API 규약에 맞게 기술된 목표 상태 선언서인 매니페스트를 YAML 형식 혹은 JSON 형식으로 전송하여 오브젝트를 만들고, 바꾸고, 제거하는 일을 한다. 이 API 규약은 새로운 버전이 공개될 떄마다 추가나 변경된 점이 반영된 API 래퍼런스가 공개된다. 오브젝트란? 쿠버네티스 오브젝트란 클러스터 내부의 엔티티로서, 이후 설명할 파드, 컨트롤러, 서비스 등의 인스턴스를 의미한다. 각각의 오브젝트는 쿠버네티스 API의 리소스 종류에 맞게 설정되고 생성된다. 오브젝트는 지정된 상태가 유지되도록 쿠버네티스에 의해 제어된다. 각 오..
쿠버네티스의 아키텍처 및 구성요소 쿠버네티스는 마스터와 노드로 구성된다. 쿠버네티스 클러스터를 구성하는 코어 프로세스(컨테이너) kubectl K8s 클러스터를 조작하기 위한 도구로 가장 비번하게 이용되는 커맨드 라인 인터페이스다. kube-apiserver kubectl 등의 API 클라이언트로부터 오는 REST 요청을 검증하고, API 오브젝트를 구성하고 상태를 보고한다. kube-scheduler 쿠버네티스의 기본 스케줄러이며, 새로 생성된 모든 파드에 대해 실행할 최적의 노드를 선택한다. 스케줄러는 파드가 실행 가능한 노드를 찾은 다음 점수를 계산하여 가장 높은 노드를 선택한다. kube-controller-manager 컨트롤러를 구동하는 마스터상의 컴포넌트 cloud-controller-man..
