도커 – WONIZZ.LOG

[DevOps] ELK를 활용한 로그 분석

워니 — Mon, 07 Oct 2019 13:59:37 +0000

The standard Lorem Ipsum passage, used since the 1500s
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 ELK를 활용한 웹서버 로그 분석에 대해서 알아보는 시간을 갖도록 해보겠습니다. 필자가 운영하는 프로젝트에서는 Nginx(IDS – Internet Detection Server) 와 Apache(웹서버) – WAS 서버의 구성으로 이루어져있습니다. Apache에서는 whitelist된 URL query string 에 대해서만 캐시를 남기고 그외에는 WAS까지 접속하여 가져오는 구성으로 되어어 있습니다. (식별된 파라미터에 대해서는 캐싱된 페이지를 보여주기 위함 입니다.) 그러다보니, 비식별된 파라미터들의 접속량이 증가하면 WAS 서버에 부하를 주게 되어 이를 모니터링 할 수 있는 프로세스를 생각해봤습니다. 그러던중 ELK를 알게 되었고, filebeat와 logstash를 적절하게 이용하면 로그분석을 통하여 비식별 파라미터를 추출해 낼 수 있을 것이라고 생각했습니다.

1. 로그 수집 프로세스

아파치 혹은 Nginx의 access.log에 외부 접근이 생기면 정해진 로그 포맷에 따라 파일이 생성되거나 내용이 추가됩니다.
filbeat는 마치 리눅스의 tail명령어와 같이 지속적으로 파일을 읽어서 로그스태시에게 전달해줍니다. filebeat.yml 파일의 설정 파일로 target 로그스태시 지정이 가능합니다.
logstash에서 input 모듈을 활용하면 beat에서의 내용을 받을 수 있습니다. 반드시 앞에 filebeat가 있어야 되는것이 아니고 로컬의 파일을 읽을 수도 있고, 혹은 외부 json 호출도 가능합니다.
logstash의 강력한 기능중 하나인 filter를 통하여 log파일의 정제 및 reform이 가능합니다.
정제된 내용을 elastic으로 output으로 보내 줍니다.
키바나에서는 elastic의 내용을 표현해줍니다.

2. Docker-elk를 활용한 설치

지금까지 Docker에 대해서 학습을 해왔기 때문에 Docker로 설치해보고자합니다. 개별제품군으로 설치를 하면 귀찮지만, Docker를 한번에 ELK 스택을 한번에 올릴 수 있어 굉장히 편합니다.

2-1. docker-elk repository clone

작업 디렉토리에서 docker-elk git 레포지토리를 clone 합니다.

$ git clone https://github.com/deviantony/docker-elk#requirements

docker-elk

2-2. configuration

docker-elk를 clone 받으면 docker-elk 폴더가 생기고 여기서 각 config 폴더 안에 elk에 대한 설정을 해주면됩니다.

elasticsearch.yml
logstash.yml / logstash.conf
kibana.yml

2-3. docker-elk 실행

# docker-compose.yml이 있는 디렉토리에서 수행해야 한다 
# build 
$ docker-compose build 

# 빌드를 통해 생성된 도커 이미지 확인 
$ docker images 

# up: 컨테이너 생성 및 구동, -d는 백그라운드로 실행 옵션 
$ docker-compose up -d 

# 컨테이너 목록 확인 
$ docker-compose ps 

# 컨테이너 로그 확인 
$ docker-compose logs -f

컨테이너 목록 확인에 정상적으로 컨테이너 3개(elasticsearch, logstash, kibana)가 보이고, 로그에서도 문제가 없으면 정상적으로 작동된 것이다. 브라우저에서 localhost:5601로 접속하면 kibana 웹 UI 화면이 뜰 것이다.

2-4. filebeat 설치

elk에 대한 내용은 설치를 완료했고, 필자 같은 경우, filebeat는 직접 host에 설치를 했습니다.

filebeat 설치 filebeat 를 yum을 통해서 설치

sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

/etc/yum.repods.d/elastic.repo 추가

[elastic-6.x]
name=Elastic repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

yum install filebeat를 통해서 설치를 진행합니다.

3. 설정

이제 각 설정을 통해서 연결을 해줍니다.

3-1. filebeat 설정

filebeat 에서는 json 형태로 logstash 에게 데이터를 전달하고, 이때 message 필드에 수집한 로그 파일의 데이터가 담겨진다. 수집하려는 log file 의 유형에 따라서 community beats를 사용할 수도 있지만, 필자의 경우에는 Custom pattern의 로그 파일을 수집할 예정이라 logstash에서 pasring 하는 형태를 선택했다.

![ELK_로그스태시](http://blog.wonizz.com/wp-content/uploads/2019/10/ELK_로그스태시.png)filebeat.prospectors:

# Each - is a prospector. Most options can be set at the prospector level, so
# you can use different prospectors for various configurations.
# Below are the prospector specific configurations.

- type: log
  enabled: true
  paths:
    - /var/log/my_log_path/*.log
  fields:
    index_name: "my_custom_file_index_name"

#----------Elasticsearch output--------------- 주석처리
# (beats 에서 바로 ES 로 데이터 전달하지 않음)


#----------Logstash output ------------------- 주석해제
# (beats 에서 logstash 로 데이터 전달)

output.logstash:
  # The Logstash hosts
  hosts: ["my-logstash-server-host:5044"]

...

filebeat는 굉장히 심플하다. 1)target으로 보내주는 파일지정과 2) target에 대한 셋팅만 하면된다. 필자가 처음에 애먹었던 부분은 위에 보이는 것과 같이 elastic으로 바로 전달하면 안되기에 주석처리를 하고 logstash를 열어줘야되는데, logstash에 host만 셋팅하고 안되는 이유를 한참이나 찾았다.

3-2. logstash 설정

grok, mutate, json, geoip, alter 필터를 설정했고 filebeat 에서 fields 로 넘겨받은 index_name을 사용했다.
date 필터는 기준 시각을 filebeat 에 의해서 파싱된 시각을 사용하지 않고, log 에 기록된 시각으로 지정하도록 한다.

로그스태시의 기본구저는 INPUT, FILTERS, OUTPUT으로 이루어져있습니다.

input {
...
}


filter {
...
}


output {
...
}

아래는 필자가 만든 pipeline입니다. 파이프라인 설정을 통해서 비트로부터 넘어온 로그를 정정제하고 elasticsearch로 보내줍니다.

input {
  beats {
    port => 5044
  }
}
filter {

        grok {
                match => { "message" => "\"(?:%{WORD:verb} %{GREEDYDATA:uri_stem}\?%{GREEDYDATA:uri_query}(?: HTTP/%{NUMBER:httpversion})?|-)\" %{QS:agent}" }
        }
        if "_grokparsefailure" in [tags] {
                drop { }
        }
        mutate {
                gsub => [ "uri_query", "=(?<=\=)(.*?)(?=&|HTTP)", "",
                           "uri_query", "HTTP/1.0", "",
                           "uri_query", "HTTP/1.1", "",
                           "uri_query", "nocache", "",
                           "uri_query", "kkkkk", ""
        ]
                split => { "uri_query" => "&" }
        }
        mutate {
                remove_field => "message"
                remove_field => "verb"
                remove_field => "httpversion"
         }
        date {
                 match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
        }

}
output {
        elasticsearch {
                hosts => ["172.26.0.1:9200"]
                index => "wonizz_nginx"
                user => "elastic"
                password => "changeme"
        }

                stdout { codec => rubydebug }
}

하나씩 의미를 확인해보겠습니다.

input

beats {
    port => 5044
  }

내용에서 보다시피, filebeat로부터 오는 input에 대한 내용입니다. 기본적으로 5044 tcp 포트로 들어오는 데이터를 수집합니다.

filter

grok {
                match => { "message" => "\"(?:%{WORD:verb} %{GREEDYDATA:uri_stem}\?%{GREEDYDATA:uri_query}(?: HTTP/%{NUMBER:httpversion})?|-)\" %{QS:agent}" }
        }

grok은 넘어오는 input에 대하여 동적으로 mapping하여 각 포맷별로 mapping시켜주는 것입니다. 예를들어 아파치나 nginx의 access.log는 정해진 포맷이 있는데 적절하게 grok 패턴을 사용하면 알아서 매핑을 해주어 쪼개줍니다. 아래의 2가지 웹사이트를 활용하여 필자는 custom되어있는 nginx로그를 매핑할 수 있는 grok 패턴을 만들어 봤습니다. grok debugger grok constructor

if "_grokparsefailure" in [tags] {
                drop { }
        }

단순히, grok mapping에 실패하였을 경우, continue 하는 내용입니다.

mutate {
                gsub => [ "uri_query", "=(?<=\=)(.*?)(?=&|HTTP)", "",
                           "uri_query", "HTTP/1.0", "",
                           "uri_query", "HTTP/1.1", "",
                           "uri_query", "nocache", "",
                           "uri_query", "kkkkk", ""
        ]
                split => { "uri_query" => "&" }
        }

mutate는 그 의미에서도 알 수 있듯이 변형을 가하는 것입니다. gsub는 substring을 하는 것이고, split은 쪼개는 것입니다. 위에서 보는 내용은 uri_query로 매핑되어 도출된 내용을 적절하게 substring하여 앰퍼센트(&)로 쪼개는 내용입니다. 예를들어, uri_query string이 “test=1&test2=2 HTTP/1.1″ 이라고 들어오면 첫줄의 정규식에 의하여 test&test2 HTTP/1.1” 이 남고 그다음부터는 substring으로 제거해줍니다. test&test2는 split에 의하여 test, test2로 쪼개어 수집하게 됩니다.

mutate {
                remove_field => "message"
                remove_field => "verb"
                remove_field => "httpversion"
         }

불필요한 field에 대해서 삭제 처리합니다.

output

 elasticsearch {
                hosts => ["172.26.0.1:9200"]
                index => "wonizz_nginx"
                user => "elastic"
                password => "changeme"
        }

elasticsearch 로 적절한 index로 넣게 됩니다. 여기서 host 같은 경우는 docker로 올렸기 때문에 해당 호스트이 docker daemon 의 network 를 호출하여 9200포트로 보내줍니다.

4. elasticsearch 조회

필자 같은경우는 elasticsearch에 넣고 kibana로 조회를 했지만, 알람을 주기 위해 zabbix를 활용했다. 먼저 nodejs를 활용하여 elastic에서 데이터를 조회합니다.

var elasticsearch = require('elasticsearch');
var client = new elasticsearch.Client({
  host: 'localhost:9200',
  log: 'trace'
});


client.search({
index: 'wonizz_nginx',
type: '_doc',
body: {
"query": {
    "bool": {
      "must": [
        {
          "range": {
            "@timestamp": {
              "gte": "now-1h/h",
              "lte": "now"
            }
          }
        }
      ]
    }
  },
  "aggs": {
    "group_by_state": {
      "terms": {
        "field": "uri_query.keyword"
        }
     }
  }
}
})

간단하게 elasticsearch 모듈을 import하여 조회를 손쉽게 할 수 있다. 필자가 하고자 했던것은 1시간 이전의 데이터를 수집한 뒤, aggregation을 이용하여 uri_query에 대해서 group by를 하고자 하는 것입니다. 앞서 이야기했듯이 whitelist되지 않은 parameter가 노출이 되면, 해당 내용을 .log파일로 출력하고, zabbix는 지속적으로 .log파일을 감시하다가 신규 내용이 올라오면, 알람을 주는 구조입니다. elasticsearch <-> nodejs -> requset_parameter.log 파일 <- zabbix 감시

5. 마치며…

이번시간에는 ELK와 Filebeat를 통해서 로그 수집에 대해서 알아봤습니다. 아직은 기초적인 단계이지만, 잘만 활용하면 전체적인 로그의 모습을 볼 수 있고 또한 access.log같은 경우 패턴도 분석이 가능할 것 같습니다. ELK 스택에서 제공해주는 로그 패턴 분석으로 알람까지 주는 기능도 좀더 알아봐야될 것 같습니다. 다음이시간에는 Elasticsearch 클러스터 구성에 대해서 알아보는 시간을 갖도록 하겠습니다.

함께 보면 좋은 글

The post [DevOps] ELK를 활용한 로그 분석 appeared first on WONIZZ.LOG.

[AWS] ECS 서비스란?

워니 — Fri, 06 Sep 2019 05:35:20 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간에는 아마존에서 제공하는 서비스중 하나인 ECS에 대해서 정리를 해보려고 합니다. 기존에 EC2 인스턴스 내에서 도커를 설치하고 컨테이너를 생성해보는것을 해봤는데요. 기존에 SWARM이라던지, 쿠버네티스와 같은 서비스는 없을까 하고 알아보던중에 아마존에서 제공해주는 서비스가 있다는 것을 알게 되었습니다. ECS 는 elastic container service의 약자로 클러스터를 구성해주고 컨테이너를 생성해주고 관리해주는 역할을 합니다.

1. 클러스터의 개념

ECS의 가장 기본적인 단위는 클러스터입니다. 클러스터는 도커 컨테이너를 실행할 수 있는 가상의 공간입니다. 클러스터를 잘 구분해주는 것이 중요한데, 보통 프로젝트 단위나 업무(service) 단위로 구분지어 생성합니다.

2. Task Definition

ECS 에서 컨테이너를 실행하는 최소 단위를 태스크 라고 합니다. 태스크는 하나 이상의 컨테이너로 구성이 됩니다. 여러 컨테이너의 조합으로 하나의 태스크를 생성 할 수 있스니다. 태스크를 실행하려면 태스크 디피니션이 필요합니다. 네트워크 모드, 태스크 역할, 도커 이미지, 실행 명령어, CPU 제한, 메모리 제한 등 다수의 설정이 필요합니다. 컨테이너를 오케스트레이션을 사용하는 가장큰 이유중 하나는 컨테이너의 생명주기를 스스로 관리하게끔 하는 것입니다. 이러한 설정들의 정의를 미리 작성해두어, 나중에 이 정의를 기반으로 태스크를 실행합니다.

3. 서비스

태스크를 실행하는 방식은 다음 두가지 입니다.

태스크 디피니션을 통한 태스크 실행
서비스 정의

서비스는 하나의 태스크 디피니션(리비전)과 연결됩니다. 서비스 타입은 다시 다음 두가지 방식으로 나뉘어 집니다.

데몬타입
리플리카 타입

데몬타입 같은 경우는 각 인스턴스 별로 1개의 컨테이너가 생성이 되고, 리플리카 같은 경우는 태스크의 개수를 지정하여 클러스터에서 이 개수만큼 태스크가 실행되도록 자동적으로 관리를 해줍니다. 서비스는 ECS 클러스터 내에서 작업을 스케쥴링 해주는 역할을 합니다. EC2와 같은 컴퓨팅 자원을 직접 사용해서 프로세스를 배치하는 경우 서버 운영자가 직접 어떤 인스턴스에 어떤 프로세스를 언제 배치할지 결정해야합니다. 오케스트레이션에서는 이러한 관리를 담당하는 스케줄러가 존재합니다. ECS에서는 서비스가 이러한 스케줄링을 담당하고 있습니다. ECS 서비스는 각 인스턴스들에 설치된 ecs-client에서 수집된 정보를 기반으로 어디에 어떤 태스크를 언제 실행할지 결정합니다. 따라서 리플리카 타입 서비스의 경우, 다수의 컨테이너 인스턴스가 있을 때 언제 어디에서 태스크가 실행될지 알 수 없습니다. 서비스가 직접 태스크 배치 스케줄링을 수행합니다.*

4. ECR(Elastic Container Registry)

AWS ECS에서는 엘라스틱 컨테이너 레지스트리ECR, Elastic Container Registry라는 프라이빗 도커 레지스트리 서비스를 제공하고 있습니다. 도커 레지스트리는 도커 이미지를 저장 및 관리하는 서비스입니다. 일반적으로 도커에서 공식적으로 제공하는 도커 허브Docker Hub가 많이 이용됩니다. 이미지를 비공개적로 푸시하거나 풀하는 경우에는 도커 허브의 유료 플랜을 이용하거나 직접 도커 레지스트리 서비스를 운용해야합니다. ECR을 사용해서 프라이빗 도커 레지스트리를 대체할 수 있으며, IAM과 조합함으로서 세세한 권한 관리가 가능합니다.

5. 실습 예제

필자의 프로젝트에서는 아직 Container를 운영하고 있지는 않습니다. 하지만, ECR을 한번 고려해보기 위해서 실습예제를 수행해보도록 하겠습니다.

5-1. 클러스터 생성

아마존의 ECR 메뉴로 들어가게 되면, 클러스터를 생성할 수 있는 메뉴가 있습니다. 거기서 EC2+네트워킹을 선택하여 필요한 모든 resource들을 생성해줍니다. 필자 같은 경우는 아래와 같이 생성했습니다.

클러스터 인스턴스 2대
VPC / Subnet
Security Group
IAM

IAM 같은 경우는 아래의 내용때문에 필요합니다. > Amazon ECS 컨테이너 에이전트는 사용자를 대신하여 Amazon ECS API 작업을 호출하므로 에이전트가 사용자에게 속한다는 것을 서비스가 알기 위해서는 에이전트를 실행하는 컨테이너 인스턴스에 ecsInstanceRole IAM 정책과 역할이 필요합니다. ecsInstanceRole이 아직 없는 경우, AWS가 생성할 수 있습니다.

5-2. ECR 생성

이미지들을 관리하기 위해서 Repository를 구성해주어야 합니다. 아마존에서는 손쉽게 ECR로 생성이 가능합니다.

5-3. 이미지 생성

이미지 생성을 해볼 시간입니다. Dockerfile을 작성한 뒤에 이미지 빌드를 수행해서 나오는 이미지를 ECR에 push해보는 작업까지 해보겠습니다.


FROM richarvey/nginx-php-fpm:1.5.3
RUN echo '' > /var/www/html/index.php ;\
    echo '' >> /var/www/html/index.php ;\
    echo 'Nginx Demo v0.1' >> /var/www/html/index.php ;\
    echo 'Hostname: ' >> /var/www/html/index.php ;\
    echo '' >> /var/www/html/index.php

$ docker build -t wonni/nginx:v0.1 .

5-4. ERC 푸시

위의 작업을 통해서 이미지가 생서잉 되면, ECR로 이미지를 push해야합니다. 로그인

(aws ecr get-login --no-include-email --region ap-northeast-1)

푸시할 이미지 준비

docker tag wonni/nginx:latest 194506033013.dkr.ecr.ap-northeast-1.amazonaws.com/first-repository:latest

푸시

docker push 194506033013.dkr.ecr.ap-northeast-1.amazonaws.com/first-repository:latest

5-5. 작업 정의

위에서 이야기했던 Task Definition을 정의할 단계입니다. 아마존 콘솔에서 진행은 하되, JSON을 통한 구성을 클릭하여 다음을 입력해줍니다.

{
  "family": "ecs_nginx_examaple",
  "networkMode": "bridge",
  "containerDefinitions": [
    {
      "name": "nginx",
      "essential": true,
      "image": "194506033013.dkr.ecr.ap-northeast-1.amazonaws.com/first-repository:latest",
      "cpu": 0,
      "memory": 128,
      "portMappings": [
        {
          "hostPort": 80,
          "containerPort": 80,
          "protocol": "tcp"
        }
      ]
    }
  ]
}

위의 작업 정의를 보면 알겠지만, 어떤 이미지를 사용하고 자원할당은 어떤식으로 하고 PORT구성은 어떻게 되어있는지에 대한 정의서 작성단계입니다.

5-6. 서비스 생성

이제 태스크 정의까지 완료 되었으니, 이를 스케쥴링 해주는 서비스를 생성해야합니다. 아마존 콘솔에서 클러스터 > 서비스 탭에서 생성 버튼을 클릭해줍니다. 그러면, 어떠한 작업 정의를 기준으로 어떻게 배포를 하는지에 대한 선택을 하는 창이 나옵니다. 최종적으로 완성된 아키텍처는 아래와 같습니다. 아직 ELB는 연결하지 않았지만, ELB를 생성하여 TargetGroup으로 클러스터링된 EC2 인스턴스를 넣어주면 됩니다.

여기서 만약에 Task definition 에서 container replica를 4개를 주면 어떻게 될까요? 현재 Container가 80포트를 점유하고 있기때문에, 2개만 생성이 되고 2개의 Container는 exited code 0로 생성되지 않습니다. 그러면 이러한 상황을 어떻게 해결할 수 있을까요? container cluster전체를 하나의 port(80)로 바인딩하고 내부 container는 random port로 줘서 port forwarding으로 해결할 수 있습니다.

5-7. ALB 생성

필자는 ECR을 학습하면서 그림에서 ELB 생성이 나타나 있지만, 아마존에서 권고하는것은 msa 와 alb간에 port forwarding기능으로 상호작용이 좋다고 합니다. 그래서 필자는 ALB를 생성했습니다. 보이시는것처럼 리스너에 대상그룹을 추가해줬습니다. 그럼 위에서 나온 80포트로 ALB로 들어오면 80으로 대상그룹으로 보내서 Container 서비스를 할 수 있습니다.

5-8. Task Definition 수정 및 서비스 재배포

위에서 정의한 작업 정의를 업데이트 합니다. 새 개정 생성 을 클릭 한뒤에 json을 클릭하여 HOST 포트를 0으로 바꺼줍니다. 그렇게 되면, Nginx가 생성될때 임의의 포트를 생성하게 됩니다. 이제 서비스를 재생성합니다. 보시는 것처럼 위에서 수정한 작업 정의가 버전 2로 변경되어 있습니다. 이것을 지정합니다. 네트워크 탭에서는 앞서 생성한 ALB를 지정하여 ecs에서 인식하도록 합니다. 이제 생성한 서비스가 배포가 됩니다. 최종적으로 ALB내용이 포함된 서비스를 배포하고 나면, ALB에서는 동적으로 포트포워딩을 Target Group으로 지정하여 생성되게 됩니다. 따라서 아래와 같은 그림으로 서비스 하게 됩니다.

6. 마치며..

이번 글을 작성하면서, 기존에 도커 컨테이너를 학습하고 오케스트레이션에 관한 학습도 이어서 진행을 했었는데 아마존에서는 이미 서비스로 손쉽게 클러스터링을 하고 배포를 할 수 있도록 구성이 다 되어있다는 점에서 놀랐습니다. ECR + ECS를 통해서 컨테이너관리를 손쉽게 할 수 있을 뿐만 아니라, 유연성있게 서비스를 운영할 수 있을것 같다는 생각을 했습니다. 다음시간에는 EKS에 대해서 간단히 정리해보는 시간을 갖도록 하겠습니다.

함께 보면 좋은 글

The post [AWS] ECS 서비스란? appeared first on WONIZZ.LOG.

[Kubernetes] 쿠버네티스 Service 란?

워니 — Wed, 21 Aug 2019 05:36:48 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 지난시간에는 쿠버네티스 POD라는 개념에 대해서 알아봤는데요. 이번시간에는 이러한 POD들을 어떻게 서비스를 해주는 지에 대한 관점인 Service에 대해서 알아보는 시간을 가져보도록 하겠습니다.

지난 글들은 아래를 참고 해주시면 됩니다.

필자가 속한 프로젝트에서는 아직 쿠버네티스를 사용하고 있지 않습니다. 그래서 개인적으로 쿠버네티스 클러스터를 연결해서 nginx POD 를 생성해서 배포까지 해봤습니다. 그런데 여기서 POD 가 여러개라면 그 앞에 관문 역할을 하는 것이 필요할 것입니다.

이러한 개념이 바로 Service 입니다.

1. Service Template 작성

서비스 템플릿이란 쿠버네티스에서 Service를 생성하기 위한 YML 로 작성된 파일을 말합니다. 다음은 예시입니다.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
  selector:
    run: my-nginx

그럼 위의 내용을 한줄 씩 설명해드리겠습니다.

서비스 이름

metadata:
  name: my-nginx

서비스의 이름은 my-nginx이고, labels는 해당 POD에 대해서 라벨링을 해두는것인데, 여기서는 run: my-nginx라고 해두었습니다.

타입

spec:
  type: NodePort

Service는 유형(ClusterIP, NodePort, LoadBalancer) 을 갖고 있는데, Node Port를 여기서 사용하고있습니다.

포트

  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP

클러스터 port는 8080 이고 실제 nginx POD가 서비스 되는 포트는 80 포트입니다.

셀렉터

  selector:
    run: my-nginx

이 서비스는 Pod중에서 label 값이 run: my-nginx 인 pod쪽으로 서비스 합니다.

2. Service Object 의 특징

서비스 타입 종류
- Cluster IP
- NodePort
- LoadBalancer
Label Selector 통해서 Pod 타겟팅 + 로드밸런싱
Service yaml 파일에 기술된 name로 쿠버네티스 클러스터상에 DNS를 생성할 수 있습니다.

2-1. 서비스 타입

ClusterIP : 쿠버네티스의 디폴트 설정으로 외부에서 접근가능한 IP를 할당받지 않기 때문에 Cluster내에서만 해당 서비스를 노출할 때 사용되는 Type
NodePort : 해당 서비스를 외부로 노출시키고자 할 때 사용되는 Service Type으로 외부에 Node IP와 Port를 노출시키는 것으로 아래 그림과 같이 쿠버네티스 클러스터 상에 있는 모든 노드(VM)에 대해서 노출 시킵니다.

LoadBalancer : 클라우드상에 존재하는 LoadBalancer에 연결하고자 할 때 사용되는 Service Type으로 LoadBalancer의 외부 External IP를 통해 접근이 가능합니다.

2-2. 서비스 네임 : DNS

Kubernetes는 자체 DNS서버를 가지고 있어 클러스터 내부에서만 사용가능한 DNS를 설정해서 사용할 수 있습니다. 이것은 Kubernetes상에서 통신할때 IP기반이 아닌 DNS를 통해 연결할 수 있음을 뜻하며 아래 그림과 같이 Pod에서 다른 Pod의 서비스를 연결할때 사용됩니다.

3. Ingress

Ingress는 Kubernetes v1.1 추가된 기능으로 NodePort 와LoadBalancer 와 마찬가지로 애플리케이션의 Service를 외부로 노출할때 사용되는 리소스입니다.

외부에서 들어온 HTTP와 HTTPS 트래픽을 ingress resouce를 생성하여 Cluster내부의 Service로 L7영역에서 라우팅하며 로드밸런싱, TLS, 도메인 기반의 Virtual Hosting을 제공합니다.

이러한 기능은 NodePort로 서비스를 노출하는 것에 비해 외부의 서비스를 보다 손쉽게 관리할 수 있도록해줍니다.

Ingress는 실질적인 라우팅 기능을 제공하는 Ingress Controller와 Ingress 리소스로 구성할 수 있는데, ingress 리소스는 외부의 URLs을 Cluster 내부의 Service로 라우팅하는 rule이 정의되어 있으며, Ingress Controller에는 다양한 구현체가 존재하며, 여기서는 nginx ingress controller를 설치해 실습해 보도록하겠습니다.

3-1. Single Service Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: single-ingress
spec:
  backend:
    serviceName: my-nginx-svc
    servicePort: 80

root@master:/lab/service/ingress# kubectl get ingress
NAME             HOSTS   ADDRESS         PORTS   AGE
single-ingress   *       192.168.1.240   80      2m17s
root@master:/lab/service/ingress# curl http://192.168.1.240



Welcome to nginx!



Welcome to nginx!
If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.

For online documentation and support please refer to
nginx.org.

Commercial support is available at
nginx.com.

Thank you for using nginx.

4. 실습

앞서 이야기했던 Service 들에 대해서 개별적으로 실습해보는 내용들을 정리해보겠습니다. 우선 아래와 같이 폴더 구조를 생성하였고, 각 타입에 맞추어 pod과 serivce를 생성하여 실습을 했습니다.

lab
 └── service
     │
     ├── clusterip
     │   ├── nginx-pod.yaml
     │   └── nginx-svc.yaml
     │
     ├── loadbalancer
     │   ├── nginx-pod.yaml
     │   └── nginx-svc.yaml
     │
     └── nodeport
         ├── nginx-pod.yaml
         └── nginx-svc.yaml

# pod & service 배포
# cd /lab/sercie/{servicetype폴더}
# kubectl apply -f .

4-1. Cluster IP

파드 생성하기

root@master:~# gedit /lab/service/clusterip/nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: my-nginx
  name: my-nginx-pod
  namespace: default
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: my-nginx-container
    ports:
    - containerPort: 80
      protocol: TCP

서비스 생성하기

root@master:~# kubectl apply -f /lab/service/clusterip

결과 확인

Service를 조회해보면 Cluster 내부에서만 사용가능한 Cluster IP가 할당된 것을 확인 할 수 있으며, 클러스터에서 curl 명령을 통해 접근가능한 것을 확인 할 수 있습니다.

root@master:/lab# kubectl get svc -o wide
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
kubernetes     ClusterIP   172.168.1.1             443/TCP   80m   
my-nginx-svc   ClusterIP   172.168.1.240           80/TCP    74m   run=my-nginx

root@master:/lab# kubectl describe svc my-nginx-svc
Name:              my-nginx-svc
Namespace:         default
Labels:            run=my-nginx
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"run":"my-nginx"},"name":"my-nginx-svc","namespace":"default"},...
Selector:          run=my-nginx
Type:              ClusterIP
IP:                172.168.1.240        # ClusterIP
Port:                80/TCP      # Cluster Port
TargetPort:        80/TCP               # Container Port
Endpoints:         10.32.0.5:80         # Container IP
Session Affinity:  None

파드 DNS

[ root@curl-5cc7b478b6-rjq5d:/ ]$ nslookup my-nginx-svc
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      my-nginx-svc
Address 1: 10.101.62.208 my-nginx-svc.default.svc.cluster.local

[ root@curl-5cc7b478b6-kb8w8:/ ]$ curl my-nginx-svc.default.svc.cluster.local

이러한 내부 DNS로 아래 그림과 같이 Pod에서 다른 서비스 또는 다른 Pod로 통신이 가능합니다.

Namespaces and DNS

Service Object를 생성하면 해당 Service의 name으로 를 포함해 아래와 같은 규칙을 가진 DNS가 cluster 내에 생성됩니다. 이것은 어떤 container(pod)에서 해당 service를 DNS로 호출하는 경우에 개발계, 운영계 등과 같이 multiful namespace를 구성했을때 동일한 설정의 구성을 가능하게 합니다. 이것은 만약 다른 namespace 예를 들면 개발계에서 운영계의 Service를 호출하고자 할때는 FQDN을 사용해야 한다는 뜻입니다.

..svc.cluster.local

4-2. NodePort

파드 생성하기

root@master:~# gedit /lab/service/nodeport/nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: my-nginx
  name: my-nginx-pod
  namespace: default
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: my-nginx-container
    ports:
    - containerPort: 80
      protocol: TCP

서비스 생성하기

# gedit /lab/service/nodeport/nginx-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
  selector:
    run: my-nginx

kubectl apply -f /lab/service/nodeport/

결과 확인

NodePort로 service를 생성하게 되면 자동으로 3XXXX대의 포트를 확인 할 수 있습니다. 이 Port가 모든 VM에 노출된 Node Port이고 Cluster 외부인 어느 VM에서나 접근이 가능합니다.

root@master:/lab# kubectl get svc
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
my-nginx-svc   NodePort    172.168.1.240           8080:31331/TCP   140m


root@master:/lab# kubectl describe svc my-nginx-svc
Name:                     my-nginx-svc
Namespace:                default
Labels:                   run=my-nginx
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"run":"my-nginx"},"name":"my-nginx-svc","namespace":"default"},...
Selector:                 run=my-nginx
Type:                     NodePort
IP:                       172.168.1.240       # Cluster IP
Port:                       8080/TCP   # Cluster Port
TargetPort:               80/TCP              # Container Port
NodePort:                   31331/TCP  # Node Port
Endpoints:                10.32.0.5:80        # Container IP, Port
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   

> VM IP로 접근
# curl localhost:31331

> Mater, Node 등 모든 node VM내의 Firefox에서 아래 url로 접근가능
http://localhost:31331

4-3. LoadBalancer

파드 생성하기

root@master:~# gedit /lab/service/loadbalancer/nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: my-nginx
  name: my-nginx-pod
  namespace: default
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: my-nginx-container
    ports:
    - containerPort: 80
      protocol: TCP

서비스 생성하기

# gedit /lab/service/loadbalancer/nginx-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    run: my-nginx
spec:
  type: LoadBalancer
  ports:
  - port: 3000
    targetPort: 80
    protocol: TCP
  selector:
    run: my-nginx

kubectl apply -f /lab/service/loadbalancer

결과 확인

VM상에 가상으로 설치한 loadbalancer에 서비스가 매핑된것을 확인 할 수 있습니다.

가상으로 설치한 loadbalancer의 IP는 192.168.1.240 이며, Cluster상에서 해당IP로 nginx 서비스에 접근이 가능합니다.(crul http://192.168.1.240:8080), 이 IP는 실제 클라우드 상에서는 클라우드 벤더가 제공하는 로드밸런서 장비의 외부로 노출된 공인IP입니다.

root@master:/lab/service/loadbalancer# kubectl get svc
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
kubernetes     ClusterIP      172.168.1.1               443/TCP          7m1s
my-nginx-svc   LoadBalancer   172.168.1.240   192.168.1.240   3000:30947/TCP   30s

root@master:/lab/service/loadbalancer# kubectl describe svc my-nginx-svc
Name:                     my-nginx-svc
Namespace:                default
Labels:                   run=my-nginx
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"run":"my-nginx"},"name":"my-nginx-svc","namespace":"default"},...
Selector:                 run=my-nginx
Type:                     LoadBalancer
IP:                       172.168.1.240
LoadBalancer Ingress:     192.168.1.240
Port:                       3000/TCP
TargetPort:               80/TCP
NodePort:                   30947/TCP
Endpoints:                10.32.0.5:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason       Age   From                Message
  ----    ------       ----  ----                -------
  Normal  IPAllocated  44s   metallb-controller  Assigned IP "192.168.1.240"

root@master:/lab/service/loadbalancer# curl http://192.168.1.240:3000



Welcome to nginx!

외부 네임 생성하기

여기서는 추가적으로 외부에 노출되는 name에 대해서 정리했습니다.

# gedit /lab/service/external/external-svc.yaml

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  type: ExternalName
  externalName: www.github.com
  ports:
  - port: 80

오브젝트 생성

kubectl apply -f /lab/service/external/external-svc.yaml

5. 마치며..

필자가 쿠버네티스의 개념에 대해서 정리를 하면서 한개씩 실습을 진행했는데, 위의 내용중 Service의 유형에 대해서 시도해보다가, NodePort만으로 실습을 진행했습니다.

필자가 원하는 방향은 외부에 노출되는 port에 대해서는 fix시켜서 지정을 하고싶어, LoadBalancer타입으로 해봤으나, External-IP가 Pending상태가 지속되면서 연결이 안되었습니다.

또한, Ingress layer를 service 앞단에 연결하였으나, 역시 동작하지 않았습니다.
이부분에 대해서 현재 정리중이며, 위의 내용을 보완해서 정리하도록 하겠습니다.

워니즈 블로그
워니즈 깃헙

The post [Kubernetes] 쿠버네티스 Service 란? appeared first on WONIZZ.LOG.

[Kubernetes] 쿠버네티스 설치와 사용법

워니 — Fri, 16 Aug 2019 04:46:06 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 쿠버네티스의 설치와 사용법에 대해서 알아보고자합니다.

지난 글들은 아래를 참고 해주시면 됩니다.

기존에는 docker swarm으로 클러스터를 구성하였는데요. 구글에서 만든 쿠버네티스를 사용해보고자 합니다.

Kubeadm을 사용하여 Kubernetes 클러스터를 구성하는 방법에 대해 설명합니다. Kubernetes는 아래 그림과 같이 Worker Node에 명령을 내리는 Master Node와 실제 Container가 구동되는 Worker Node로 구성되어 있습니다.

아래 설치과정에서 주의해야 할것은

가이드에서는 Master Node 1대와 Work Node 1대를 가정해서 설치를 가이드합니다.(총 VM 2대)

1. 설치전 작업

기본적으로 쿠버네티스는 컨테이너를 클러스터링 해주는 도구이다보니, 도커가 사전에 설치되어있어야 합니다. 또한, 마스터와 워커노트(VM 2대)가 준비되어있어야 합니다.

swap disable

Swap 은 메모리가 부족하거나 절전 모드에서 디스크의 일부 공간을 메모리처럼 사용하는 기능입니다. Kubelet 이 정상 동작할 수 있도록 해당 기능을 swap 디바이스와 파일 모두 disable 합니다.

swapoff -a
echo 0 > /proc/sys/vm/swappiness
sed -e '/swap/ s/^#*/#/' -i /etc/fstab

swapoff -a: paging 과 swap 기능을 끕니다.
/proc/sys/vm/swappiness: 커널 속성을 변경해 swap을 disable 합니다.
/etc/fastab: Swap을 하는 파일 시스템을 찾아 disable 합니다.

노드간 방화벽 해제

각 노드의 통신을 원활하게 하기 위해 방화벽 기능을 해제합니다.

systemctl disable firewalld
systemctl stop firewalld

net filter 모듈 활성화

br_netfilter 모듈이 활성화되어 있어야 합니다. modprobe br_netfilter 명령어로 해당 모듈을 명시적으로 추가하고, lsmod | grep br_netfilter 명령어로 추가 여부를 확인할 수 있습니다.

modprobe br_netfilter

필자는 net fillter를 활성화 하지 않아서, 오류가 발생했었는데요. /proc/sys/net/bridge 하위의 bridge-nf-call-iptables 파일이 활성화 되어있어야 합니다.

실제로 참고했던 내용입니다 .

https://stackoverflow.com/questions/44125020/cant-install-kubernetes-on-vagrant
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
modprobe br_netfilter
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
sudo sysctl -p

도커 설치

컨테이너 실행 환경인 도커(Docker)를 설치하고 실행합니다. 쿠버네티스는 도커 외에도 여러가지 CRI(Container Runtime Interface) 구현체를 지원하기 때문에 도커에 종속적이지 않습니다.[1]

필자의 도커 설치 가이드를 참고 부탁드립니다.

selinux 권한 제어

SELinux(Security-Enhanced Linux)는 리눅스 보안 모듈로 액세스 권한을 제어합니다. 쿠버네티스에서는 컨테이너가 호스트의 파일시스템에 접속할 수 있도록 해당 기능을 꺼야 합니다.

setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

2. 쿠버네티스 설치하기

본격적으로 쿠버네티스를 설치해보겠습니다.

repository 수정

cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kube*
EOF

yum 을 통한 설치

yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
systemctl enable kubelet && systemctl start kubelet

마스터 노드 초기화

이제 Master 노드에 컨트롤 구성 요소를 설치할 차례입니다. 해당 작업은 master 에서만 실행합니다.

kubeadm init

그럼 설치가 진행되고 마지막에 다음과 비슷한 로그가 출력됩니다.
Your Kubernetes master has initialized successfully!

마스터 노드가 활성화 되면 아래의 로그가 출력됩니다.

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join 10.146.0.25:6443 --token yuaea3.d7m8hkpvazrbv5yw --discovery-token-ca-cert-hash sha256:c6a7121c5d5207179f67d913fa654441137f76027ad0f4e23724f0202b280eec

여기서 일반 사용자가 kubectl 을 사용할 수 있도록 로그 중간에 있는 명령어를 복사해서 실행합니다.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

인증서 셋팅하기

접속하는 터미널의 인증서를 셋팅하는 과정으로 일반유저냐 Root계정이냐에 따라 설정이 다르므로 주의합니다.
여기서는 Root유저로 설정했기 때문에 아래 명령어를 수행합니다.

# export KUBECONFIG=/etc/kubernetes/admin.conf

Pod network add-on 설치하기

Pod 은 실제로 여러 노드에 걸쳐 배포되는데, Pod 끼리는 하나의 네트워크에 있는 것처럼 통신할 수 있습니다. 이를 오버레이 네트워크(Overlay Network)라고 합니다.
Master 노드에서 다음과 같이 설치합니다.

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

워커 노드 클러스터링

맨 마지막 라인의 명령어는 워커 노드를 해당 클러스터에 추가하는 명령어입니다. 해당 명령어를 복사해서 worker-1 노드에서 수행합니다.

kubeadm join 10.146.0.25:6443 --token yuaea3.d7m8hkpvazrbv5yw --discovery-token-ca-cert-hash sha256:c6a7121c5d5207179f67d913fa654441137f76027ad0f4e23724f0202b280eec

만약 해당 커맨드를 복사해놓지 않고 지워진 경우에는 다음과 같이 토큰을 확인할 수 있습니다.

kubeadm token list

해당 토큰은 24시간 동안만 사용할 수 있습니다. 새 토큰이 필요한 경우는 다음 명령어를 실행하면 됩니다

kubeadm token create

3. 쿠버네티스 확인

쿠버네티스 설치가 완료되면 다음의 명령으로 확인한다.

CNI를 설치하면 CoreDNS Pod 이 정상적으로 동작하게 됩니다.
다음 명령어로 각 노드와 상태를 확인할 수 있습니다. 처음엔 상태가 NotReady 라고 나올 수 있지만 잠시 기다리면 모두 Ready 상태가 됩니다.

kubectl get no
NAME       STATUS   ROLES    AGE     VERSION
master     Ready    master   6m44s   v1.13.3
worker-1   Ready       5m20s   v1.13.3
worker-2   Ready       5m19s   v1.13.3

설치 확인하기
다음 명령어로 쿠버네티스의 구성 요소가 모두 동작하는 것을 확인할 수 있습니다.

kubectl get componentstatuses
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok                   
controller-manager   Healthy   ok                   
etcd-0               Healthy   {"health": "true"}

4. (예제) 간단한 POD 구성해보기

먼저 간단한 Pod 을 배포해서 동작을 확인해봅시다. 다음과 같은 pod-test.yaml 파일을 생성합니다.

deployment.yml

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  # Deployment 객체의 Unique한 명칭
  name: deployment-example
spec:
  # Deployment label selector for pod
  selector:
    matchLabels:
      app: nginx
  # 2 Pods should exist at all times.
  replicas: 2
  template:
    metadata:
      labels:
        # Pod의 라벨
        app: nginx
    spec:
      containers:
      - name: nginx
        # Run this image
        image: nginx:1.10

service.yml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    run: nginx-svc
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx

deployment와 service는 추후에 알아보겠습니다. 구성도는 아래와 같습니다.
우선 위에 보시는것처럼 deployment안에 Pod을 배포하기 위한 내용들을 기입했습니다.

아래의 spec대로 2개의 replica를 생성하기 떄문에 pod은 아래보시는것처럼 생성됩니다 .

      containers:
      - name: nginx
        # Run this image
        image: nginx:1.10

service는 아래 보시는것처럼 기존의 로드밸런스의 기능을 하는데, 그 타입이 3종류(ClusterIP, noteType, DNS)가 있습니다. 이는 추후에 알아보도록 하겠습니다.

8080포트로 접속이 되면, target (nginx)의 pod으로 80포트로 분산하겠다라는 내용의 서비스 입니다.

  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx

5. 마치며

이번 포스트에서는 기존의 docker기반으로 올렸던 container들을 손쉽게 관리하기위한 cluster 도구에 대해서 알아봤습니다. 쿠버네티스는 오케스트레이션의 대표적인 도구이고, 예제에서 보시는것처럼 nginx 를 손쉽게 서비스에 붙여서 구성을 할 수 잇었습니다.

이번에는 개략적인 내용에 대해서 알았다면, 다음시간에는 쿠버네티스에서 사용하는 용어들에 대해서 하나씩 알아보는 시간을 갖도록 하겠습니다.

워니즈 블로그
워니즈 깃헙

The post [Kubernetes] 쿠버네티스 설치와 사용법 appeared first on WONIZZ.LOG.

[Docker] Compose 구성과 사용법

워니 — Tue, 13 Aug 2019 02:37:51 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 오늘은 docker의 compose구성법에 대해서 정리를 해보려고 합니다. 만약 여러분이 앱컨테이너와 데이터베이스 컨테이너의 실행 순서를 지켜서 실행해야한다고 생각해보세요. 반드시 데이터베이스 컨테이너를 실행한 다음에 앱 컨테이너를 실행해야 합니다. 그렇지 않으면 앱 컨테이너에서 데이터베이스 컨테이너를 찾을 수 없기 때문이죠. 깜박하고 앱 컨테이너부터 실행했다면? 종료하고 데이터베이스 컨테이너 실행하고, 다시 앱 컨테이너를 실행하는 불편함이 있죠. 도커 컴포즈를 사용하면 컨테이너 실행에 필요한 옵션을 docker-compose.yml이라는 파일에 적어둘 수 있고, 컨테이너 간 실행 순서나 의존성도 관리할 수 있습니다.

1. docker-compose.yml 파일

docker-compose.yml은 장황한 도커 실행 옵션을 미리 적어둔 문서라고 볼 수 있습니다. 프로젝트 루트에 파일을 만들고, 다음 내용을 붙여 넣습니다.

version: '3'

services:
  db:
    image: postgres
    volumes:
      - ./docker/data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=sampledb
      - POSTGRES_USER=sampleuser
      - POSTGRES_PASSWORD=samplesecret
      - POSTGRES_INITDB_ARGS=--encoding=UTF-8

  django:
    build:
      context: .
      dockerfile: ./compose/django/Dockerfile-dev
    environment:
      - DJANGO_DEBUG=True
      - DJANGO_DB_HOST=db
      - DJANGO_DB_PORT=5432
      - DJANGO_DB_NAME=sampledb
      - DJANGO_DB_USERNAME=sampleuser
      - DJANGO_DB_PASSWORD=samplesecret
      - DJANGO_SECRET_KEY=dev_secret_key
    ports:
      - "8000:8000"
    command: 
      - python manage.py runserver 0:8000
    volumes:
      - ./:/app/

이제 한줄씩 확인해보면서 정리 하도록 해보겠습니다.

version
```
version: '3'
```
docker-compose.yml 파일의 첫 줄에는 파일 규격 버전을 적습니다. 파일의 규격에 따라 지원하는 옵션이 달라지는데, “3”이라만 적으면 3으로 시작하는 최신 버전을 사용한다는 의미입니다. (파일 규격 버전에 따른 자세한 내용은 compose 파일의 버전과 호환성을 안내한 공식 문서를 참고하세요.)
services
```
services:
```
이 항목 밑에 실행하려는 컨테이너들을 정의합니다. 컴포즈에서는 컨테이너 대신 서비스라는 개념을 사용합니다.
db
```
services:
 db:
```
postgres 서비스의 이름을 db로 정하였습니다.
image
```
services:
 db:
   image: postgres
```
db 서비스에서 사용할 도커 이미지를 적습니다. 여기서는 dockerhub의 공식 postgres 이미지를 사용하였습니다.
volumes
```
services:
 db:
   volumes:
     - ./docker/data:/var/lib/postgresql/data
```
docker run으로 db 컨테이너를 실행할 때 –volume 옵션을 사용하여 데이터베이스의 데이터를 로컬 컴퓨터에 저장했던 부분과 같습니다. 다만 docker-compose.yml의 volumes에는 상대 경로를 지정할 수 있어서 편리합니다. docker run으로 db 컨테이너를 실행할 때와 마찬가지로, 프로젝트 루트 아래의 docker/data 디렉터리에 데이터를 저장하기로 했습니다.
environment
```
services:
 db:
   environment:
     - POSTGRES_DB=sampledb
     - POSTGRES_USER=sampleuser
     - POSTGRES_PASSWORD=samplesecret
     - POSTGRES_INITDB_ARGS=--encoding=UTF-8
```
docker run 명령어의 -e 옵션에 적었던 내용들입니다. 마지막의 POSTGRES_INITDB_ARGS 부분이 추가되었는데, 데이터베이스 서버의 인코딩을 UTF-8로 설정하기 위함입니다.
django
```
services:
 django:
```
앱 서비스의 이름은 django로 지정하였습니다.
build
```
services:
 django:
   build:
     context: .
     dockerfile: ./compose/django/Dockerfile-dev
```
db 서비스와 달리 앱 서비스는 특정 이미지 대신 build 옵션을 추가합니다. context는 docker build 명령을 실행할 디렉터리 경로라고 보시면 됩니다. dockerfile에는 ‘개발용’ 도커 이미지를 빌드하는 데 사용할 Dockerfile을 지정하면 됩니다. Dockerfile-dev 파일에서는 (운영용 Dockerfile과는 달리) 소스코드를 컨테이너에 넣지 않습니다.
ports
```
services:
 django:
   ports:
     - "8000:8000"
```
docker run 명령어의 -p 옵션에 해당하는 부분입니다.
command
```
services:
  django:
    command:
      - python manage.py runserver 0:8000
```
docker run으로 앱 컨테이너를 실행할 때 가장 마지막에 적었던 명령어 부분입니다.

2. 도커 컴포즈의 주요 명령어

up -d

docker-compose.yml 파일의 내용에 따라 이미지를 빌드하고 서비스를 실행합니다. 자세한 진행 과정은 다음과 같습니다.

서비스를 띄울 네트워크 설정 필요한 볼륨 생성(혹은 이미 존재하는 볼륨과 연결) 필요한 이미지 풀(pull) 필요한 이미지 빌드(build) 서비스 의존성에 따라 서비스 실행 up 명령에 사용할 수 있는 몇 가지 옵션도 존재합니다. -d: 서비스 실행 후 콘솔로 빠져나옵니다. (docker run에서의 -d와 같습니다.) –force-recreate: 컨테이너를 지우고 새로 만듭니다. –build: 서비스 시작 전 이미지를 새로 만듭니다.

현재 환경에서 실행 중인 각 서비스의 상태를 보여줍니다.

$ docker-compose ps
        Name                       Command               State           Ports
--------------------------------------------------------------------------------
djangosample_db_1       /docker-entrypoint.sh postgres   Up      5432/tcp
djangosample_django_1   /bash -c python manage.py        Up      0.0.0.0:8000->8000/tcp

stop, start

서비스를 멈추거나, 멈춰 있는 서비스를 시작합니다.

$ docker-compose stop
Stopping djangosample_django_1 ...
Stopping djangosample_db_1 ...

$ docker-compose start
Starting db ... done
Starting django ... done

down

서비스를 지웁니다. 컨테이너와 네트워크를 삭제하며, 옵션에 따라 볼륨도 지웁니다.

$ docker-compose down --volume
Removing myproject_django_1 ... done
Removing myproject_db_1 ... done
Removing network djangosample_default
Removing volume django_sample_db_dev

–volume: 볼륨까지 삭제합니다.

exec

실행 중인 컨테이너에서 명령어를 실행합니다. 자동화된 마이그레이션용 파일 생성이나 유닛 테스트, lint 등을 실행할 때 사용합니다.*

비슷한 명령으로 run이 존재합니다. run은 새 컨테이너를 만들어서 명령어를 실행합니다. docker run과 마찬가지로 –rm 옵션을 추가하지 않으면, 컨테이너가 종료된 후에도 삭제되지 않습니다. (이런 이유 때문에 개인적으로는 exec를 선호하지만, 컨테이너에서 추천하는 방식은 사실 run입니다.)

$ docker-compose exec django ./manage.py makemigrations
...
$ docker-compose exec node npm run test
> expresssample@0.1.0 test /www/service
> mocha $(find test -name '*.spec.js')
...

logs

서비스의 로그를 확인할 수 있습니다. logs 뒤에 서비스 이름을 적지 않으면 도커 컴포즈가 관리하는 모든 서비스의 로그를 함께 보여줍니다.

$ docker-compose logs django
Attaching to djangosample_django_1
django_1     | System check identified no issues (0 silenced).
django_1     | February 13, 2017 - 16:32:28
django_1     | Django version 1.10.4, using settings 'djangosample.settings'
django_1     | Starting development server at http://0.0.0.0:8000/
django_1     | Quit the server with CONTROL-C.

-f: 지금까지 쌓인 로그를 다 보여준 후에도 셸로 빠져나오지 않고, 로그가 쌓일 때마다 계속해서 출력합니다.

3. 예시

필자에게 업무중 주어진 미션이 각종 tool 들을 업그레이드 버전으로 설치하는 것이였다. 그런데 리눅스를 다뤄보신 분들은 알겠지만, 업그레이드라는게 yum 으로 쉽사리 설치가 되면 좋겠지만 각종 설정 파일들부터 복원 계획도 다 갖고 있어야 한다. 필자의 프로젝트에서는 grafana, zabbix, rundeck, kibana, eleasticsearch 등 다양한 도구들을 활용하고 있는데, 업그레이드를 하면서 지속적으로 기존 시스템에 영향을 주지 않는 범위내에서 해보고 싶었고, docker가 제격이라고 생각하게 되었다. 다음의 시나리오대로 grafana를 업그레이드 해봤습니다.

기존 파일 백업

- /var/lib/grafana 경로에서 데이터 백업
cp -r grafana grafana_bak 

그라파나의 데이터베이스 경로

도커 컨테이너 실행 공식 문서에 보면, 다음과 같이 도커를 실행하라고 명시되어있다.
```
$ docker run \
 -d \
 -p 3000:3000 \
 --name=grafana \
 -e "GF_SERVER_ROOT_URL=http://grafana.server.name" \
 -e "GF_SECURITY_ADMIN_PASSWORD=secret" \
 grafana/grafana
```
위의 명령어를 보시면 알겠지만, -d : 데몬(백그라운드) 실행 -p : 포트 포워딩 –name : 컨테이너 네임 명시 -e : 환경 변수 : 그라파나 configure에 명시되어있어서 없어도도.ㅁ grafana/grafana : 이미지 명시 (최신 이미지 가져옴) -> grafana/grafana:5.1.0 특정 버전 명시가능 필요한 플러그인 업데이트 *실제로 설치하고 난뒤, Zabbix plugin for Grafana 가 에러가 발생하여, 컨테이너 내부에서 업데이트를 하였습니다
```
grafana-cli plugins install 
```

컴포즈 구성으로 변경

version: "2.1"
services:
 grafana:
     image: grafana
     restart: always
     container_name: grafana
     volumes:
       - "/var/lib/grafana:/var/lib/grafana"
     expose:
       - 3000
     ports:
       - "3000:3000"

위의 docker 명령어를 명시해 놓은 compose 파일로 간단하게 실행이 가능합니다.

컨테이너 실행
```
docker-compose up -d
```

블로그 워니즈 워니즈 블로그

함께 보면 좋은 글

The post [Docker] Compose 구성과 사용법 appeared first on WONIZZ.LOG.

[Ansible] 플레이북 Role 과 Include

워니 — Thu, 08 Aug 2019 05:49:51 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 Ansible 의 플레북에 대한 이야기를 해보려고 합니다. 필자가 속한 프로젝트에서는 Ansible을 주로 다수의 서버의 configuration 을 수정할 때 사용하고 있습니다. 즉, 1개의 master 파일을 수정하고 각 서버의 경로에 해당 파일로 copy 해주는 단순한 구조입니다. 필자가 있는 프로젝트에서는 다음과 같이 사용합니다 .

nginx conf 파일 변경
nginx map 파일 변경
nginx location 파일 변경

다음시간에 nginx conf 구조에 대해서 설명을 하겠지만, 우선 ansible의 가장 효과적인 부분이 다수의 host에서 작업이 가능한 것입니다. 플레이북을 매우 큰 하나의 파일로 작성하는 것도 가능하지만 (초기에 플레이북을 배우면서는 이렇게 하기도 합니다) 점차 플레이북을 재사용하거나 계층적으로 관리할 필요도 생깁니다.

1. Ansible include

만약 플레이북의 플레이에 있는 일련의 태스크를 재사용한다고 가정해봅니다. include 를 이용하여 이 작업을 하면 됩니다. 가져온 태스크 목록은 특정 역할(role)을 수행하기에 알맞습니다. 다시한번 강조하면 플레이북은 관리 대상 시스템 그룹에 다양한 역할을 매핑하는 작업입니다.

---
# possibly saved as tasks/foo.yml

- name: placeholder foo
  command: /bin/foo

- name: placeholder bar
  command: /bin/bar

tasks:

  - include: tasks/foo.yml

분명 위와 아래는 확연히 달라집니다. 같은 내용이더라도, 파일을 include하는 구조가 훨씬 간단해 보입니다. include 할 때 변수도 포함해서 가져올 수 있습니다. (parameterized include 라고 합니다)

tasks:
  - include: wordpress.yml wp_user=timmy
  - include: wordpress.yml wp_user=alice
  - include: wordpress.yml wp_user=bob

버전 1.0 상위부터는 아래와 같이 key, value pair로도 지정이 가능합니다.

tasks:

  - include: wordpress.yml
    vars:
        wp_user: timmy
        ssh_keys:
          - keys/one.txt
          - keys/two.txt

include에 작접 패러미터를 전달하던 아니면 vars를 이용하던 상관없습니다. include 되는 파일에서는

{{ wp_user }}

여러개의 하위 플레이북도 include 가 가능합니다.

- name: this is a play at the top level of a file
  hosts: all
  remote_user: root

  tasks:

  - name: say hi
    tags: foo
    shell: echo "hi..."

- include: load_balancers.yml
- include: webservers.yml
- include: dbservers.yml

2. Ansible Role

버전 1.2 이후 태스크와 핸들러에 관하여 알았으므로 이제는 플레이북을 어떻게 잘 구성하는가를 알아낼 차례입니다. Role을 이용 하면 됩니다. Role은 파일 구조에 따라 vars_files, tasks 와 핸들러 등을 자동으로 로딩하는 것입니다. 처음에 필자는 Role이라는 것 자체가 계정과 역할 이런것일줄 알았는데, 말그대로 어떤 업무 수행단위를 하는지를 Component화 해서 재사용할 수 있도록 하는것으로 보면 될 것 같습니다. 다음과 같은 프로젝트 구조가 되어 있다고 합시다.

site.yml
webservers.yml
fooservers.yml
roles/
   common/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/
   webservers/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/

플레이북에는 다음과 같이 사용합니다.

---
- hosts: webservers
  roles:
     - common
     - webservers

다음과 같이 role x 에 대하여 작업이 진행됩니다.

만약 roles/x/tasks/main.yml 이 존재하면, 그곳에 있는 태스크 들이 플레이에 추가됩니다
만약 roles/x/handlers/main.yml 이 존재하면, 그곳에 있는 핸들러 들이 플레이에 추가됩니다
만약 roles/x/vars/main.yml 이 존재하면, 그곳에 있는 변수 들이 플레이에 추가됩니다
만약 roles/x/defaults/main.yml 이 존재하면, 그곳에 있는 변수 들이 플레이에 추가됩니다
만약 roles/x/meta/main.yml 이 존재하면, 그곳에 있는 role 의존성이 role 목록에 추가됩니다 (role 의존성은 아래에 따로 설명합니다)
Role에 있는 다른 어떤 copy, script, template 또는 include task 들은 role/x/{files,templates,tasks}/ 에 있는 것을 참조합니다.

버전 1.4 이후에는 role을 찾기위한 roles_path 설정 변수를 사용할 수 있습니다. 만약 해당 파일이 존재하지 않으면 해당 내용은 무시됩니다. 예를 들어 role을 위한 vars/ 하위 디렉터리는 없을 수도 있습니다.

파라미터 방식

---
- hosts: webservers
  roles:
    - common
    - { role: foo_app_instance, dir: '/opt/a',  app_port: 5000 }
    - { role: foo_app_instance, dir: '/opt/b',  app_port: 5001 }

조건부 방식

---
- hosts: webservers
  roles:
    - { role: some_role, when: "ansible_os_family == 'RedHat'" }

태그방식

---
- hosts: webservers
  roles:
    - { role: foo, tags: ["bar", "baz"] }

role의 태스크에 있는 이런 tag는 role 안에 단순 정의된 tag를 우선합니다. 만약 만약 특정 role에 있는 여러 task를 부분적으로 사용할 필요가 생긴다면 해당 role을 더 작은 단위로 나눌 필요가 있습니다.

순서 지정

---

- hosts: webservers

  pre_tasks:
    - shell: echo 'hello'

  roles:
    - { role: some_role }

  tasks:
    - shell: echo 'still busy'

  post_tasks:
    - shell: echo 'goodbye'

3. Ansible Role 예제 분석

ansible galaxy라는 것을 알게 되어, 처음으로 docker 설치를 한번 해보기 위해서 예제를 다운받았습니다.

https://galaxy.ansible.com/geerlingguy/docker 접속
ansible 이 설치된 서버에서 다음을 실행

$ cd /etc/ansible/
$ ansible-galaxy install geerlingguy.docker

roles 폴더 확인

$ cd /etc/ansible/roles

defaults/main.yml
handlers/main.yml
LICENSE
meta/main.yml
molecule
README.md
tasks/main.yml
     /docker-1809-shim.yml
     /docker-compose.yml
     /docker-users.yml
     /setup-Debian.yml
     /setup-RedHat.yml
templates/override.conf.j2

실행

/etc/ansible 경로에 playbook_docker_test.yml 파일을 생성한뒤, playbook을 실행합니다.

ansible-playbook playbook_docker_test.yml

- hosts: test
  roles:
    - geerlingguy.docker

실행결과 해석

PLAY [test] ************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : include_tasks] *****************************************************************************************************************************************************************************************
included: /etc/ansible/roles/geerlingguy.docker/tasks/setup-RedHat.yml for https_ids_a01

TASK [geerlingguy.docker : Ensure old versions of Docker are not installed.] ******************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Add Docker GPG key.] ***********************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Add Docker repository.] ********************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Configure Docker Edge repo.] ***************************************************************************************************************************************************************************
 [WARNING]: The value 0 (type int) in a string field was converted to u'0' (type string). If this does not look like what you expect, quote the entire value to ensure it does not change.

ok: [https_ids_a01]

TASK [geerlingguy.docker : Configure Docker Test repo.] ***************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : include_tasks] *****************************************************************************************************************************************************************************************
skipping: [https_ids_a01]

TASK [geerlingguy.docker : install the container-selinux rpm from a remote repo] **************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Install Docker.] ***************************************************************************************************************************************************************************************
changed: [https_ids_a01]

TASK [geerlingguy.docker : Ensure containerd service dir exists.] **************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Add shim to ensure Docker can start in all environments.] *******************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Reload systemd daemon if template is changed.] ******************************************************************************************************************************************************************
skipping: [https_ids_a01]

TASK [geerlingguy.docker : Ensure Docker is started and enabled at boot.] ******************************************************************************************************************************************************************
changed: [https_ids_a01]

RUNNING HANDLER [geerlingguy.docker : restart docker] **************************************************************************************************************************************************************************************
changed: [https_ids_a01]

TASK [geerlingguy.docker : include_tasks] **************************************************************************************************************************************************************************************************
included: /etc/ansible/roles/geerlingguy.docker/tasks/docker-compose.yml for https_ids_a01

TASK [geerlingguy.docker : Check current docker-compose version.] **************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : Delete existing docker-compose version if it's different.] ******************************************************************************************************************************************************
skipping: [https_ids_a01]

TASK [geerlingguy.docker : Install Docker Compose (if configured).] ************************************************************************************************************************************************************************
ok: [https_ids_a01]

TASK [geerlingguy.docker : include_tasks] **************************************************************************************************************************************************************************************************
[DEPRECATION WARNING]: evaluating [] as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in
 version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
skipping: [https_ids_a01]

PLAY RECAP *********************************************************************************************************************************************************************************************************************************
https_ids_a01              : ok=16   changed=3    unreachable=0    failed=0    skipped=4    rescued=0    ignored=0

제일 먼저, 위의 플레이북 실행 결과를 보면, task/main.yml이 실행 됩니다.

setup-RedHat.yml
- 도커 설치
docker-1809-shim.yml
- 도커 정상시작 체크
- 도커 방화벽 충돌체크
docker-compose.yml
docker-users.yml

Task의 구조는 위와 같고, 각 yml 파일들이 include되면서 수행이 됩니다.

4. 필자 Ansible 사용예시

포스트 서두에 말씀드렸듯이, 필자가 사용하는 방법은 nginx configuration 파일들에 대해서 변경해주고 재시작해주는 방식으로 사용하고 있습니다. 여기서 변경할때는 copy를 하게 되는데 nginx의 멱등성에 의거하여 변경점이 없으면, 업데이트를 안하게 됩니다.

playbook_nginx_conf.yml

- hosts: "{{ server }}"
  remote_user: idsuser  
  tasks:
  - name: Change Nginx Config file
    become: yes
    become_method: sudo
    template:
      src: /etc/ansible/config/{{server}}/nginx.conf
      dest: /etc/nginx/nginx.conf

  - name: Validate Config file
    become: yes
    become_method: sudo
    command: "nginx -t"
    register: shell_result

  - debug:
      var: shell_result.stderr_lines

따로 role관리를 안하고 상위에서 보듯이 하나의 playbook으로 작성했습니다.

config 파일 변경
config 파일 이상유무 테스트

playbook_nginx_restart.yml

- hosts: idsqa_a01
  remote_user: idsuser
  tasks:
  - name: Syntax Test  Nginx.conf
    become: yes
    become_method: sudo
    command: "nginx -t"
    register: shell_result

  - debug:
      var: shell_result.stderr_lines

  - name: Restart Nginx
    become: yes
    become_method: sudo
    service: name=nginx state=restarted
    when: '"nginx: configuration file /etc/nginx/nginx.conf test is successful" in shell_result.stderr_lines'

  - name: Check Nginx Status
    become: yes
    become_method: sudo
    shell: service nginx status
    args:
      warn: false
    register: service_status

  - debug:
      var: service_status.stdout_lines

  - name: Check Process Nginx
    become: yes
    become_method: sudo
    shell: 'ps -ef | grep nginx'
    register: process_result

  - debug:
      var: process_result.stdout_lines

config 파일 이상유무 테스트
nginx 재시작
nginx status 체크
nginx process 체크

두 개의 파일로 분할해 두었는데, role 로 task를 쪼개고 하나의 job으로 만드는 것도 좋을 것 같습니다.

5. 마치며..

오늘은 ansible의 role과 include에 대해서 알아봤습니다. ansible을 필자도 사용은 하지만, 아주 기초적인 수준으로 사용하고 있었다라는 것을 느꼈습니다. 이번기회에 role관리를 좀더 잘해보고, 특히 ansible-galaxy를 통해서 수준높은 role 관리에 대해서 학습을 좀 더 해보도록 하겠습니다. 다음 시간에는 ansible jinja2 에 대해서 알아보는 시간을 갖도록 하겠습니다. 워니즈 블로그 워니즈 깃헙

함께 보면 좋은 글

The post [Ansible] 플레이북 Role 과 Include appeared first on WONIZZ.LOG.

[Docker] Jenkins 파이프라인 사용법

워니 — Sun, 04 Aug 2019 13:18:33 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 지난 시간까지 젠킨스 셋팅까지 배웠습니다. 이제 원하는 업무를 수행하도록 JOB을 생성해주면됩니다. Jenkins에서는 요즘 여러가지 JOB을 원하는 입맛대로 구성하여 사용할 수 있도록 젠킨스 파이프라인을 제공해주고 있습니다. 👍

Jenkins 도커로 실행하기(1/3)
Jenkins 기본 셋업(Docker 내부에서 필요한 툴 설치)(2/3)
Jenkins 파이프라인 사용법(3/3)

1. 젠킨스 파이프라인이란?

A Jenkins pipeline is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins.

위에서 보는 것처럼, 젠킨스 파이프라인은 젠킨스의 파이프라인을 구성해줄 수 있는 파이프라인 플러그인을 말하는 것이고, 이 파이프라인으로부터 제킨스의 워크플로우를 구성할 수 있다.

젠킨스 파이프라인 공식문서
위의 예제에서 보듯이 워크플로우가 시작되면, 아래의 과정들로 진행됩니다.

소스 pull
빌드
테스트
배포

물론, 젠킨스의 다양한 플러그인을 이용해서 한개의 JOB에서 다른 JOB을 실행하게 하여 연결을 지을 수는 있지만, 한눈에 보기가 어렵습니다.

젠킨스의 파이프라인이란 연속적인 이벤트 혹은 Job의 그룹을 얘기합니다.
즉, 본인이 만든 젠킨스 Job들을 순차적 혹은 병렬적으로 실행시키거나 특별하게 작성한 스크립트로 이벤트들을 연속적으로 실행시키는 등의 일을 지원하는 기능입니다.

2. 젠킨스 파이프라인 타입

젠킨슴 파이프라인의 타입은 2가지를 지원합니다.

선언적 파이프라인
스크립트 파이프라인

그런데 파이프라인 문법 문서를 보면 두가지 스타일에 대한 얘기가 있습니다. 처음에는 Scripted 방식이였고 후에 Declarative 방식이 추가된 것으로 보입니다.

필자는 젠킨스 공식 문서를 보고 스크립트를 작성했는데, 개인적으로는 선언적 방식이 훨씬 간단해보여서 이방식으로 예제를 작성했습니다.

선언적 방식 예제

pipeline {
    agent none
    stages{
        stage('Parallel Test') {
            parallel { 
                stage('Build-test-1') {
                    steps{ build 'Build-test-1' }
                }
                stage('Build-test-2') {
                    steps{ build 'Build-test-2' }
                }
                stage('Build-test-3') {
                    steps{ build 'Build-test-3' }
                }
            }
        }
        stage('Build-test-4') {
            steps{
                build 'Build-test-4'
            }
        }
    }
}

스크립트 방식 예제

node {
  stage('Parallel-test') {
      parallel 'Build-test-1' : {
          build job : 'Build-test-1'
      } , 'Build-test-2' : {
          build job : 'Build-test-2'
      } , 'Build-test-3' : {
          build job : 'Build-test-3'
      }
  }
  stage('Build-test-4') {
     build job : 'Build-test-4'
  }
}

Scripted 문법의 경우 Groovy로 빌드되기 때문에 일반적으로 파이프라인을 생성하는데 Declarative 보다 훨씬 유연한 방법입니다.
반면, Declarative의 경우 Scripted보다 훨씬 더 간단하게 작성할 수 있는 방법입니다.
대신 고정된 방식으로만 사용해야합니다.

중요한 점은 이 2가지 문법은 서로 호환되지 않습니다.

A password parameter, for example: parameters { password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'A secret password') }

Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  parameters {
      string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')

      text(name: 'BIOGRAPHY', defaultValue: '', description: 'Enter some information about the person')

      booleanParam(name: 'TOGGLE', defaultValue: true, description: 'Toggle this value')

      choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')

      password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'Enter a password')
  }
  stages {
      stage('Example') {
          steps {
              echo "Hello ${params.PERSON}"

              echo "Biography: ${params.BIOGRAPHY}"

              echo "Toggle: ${params.TOGGLE}"

              echo "Choice: ${params.CHOICE}"

              echo "Password: ${params.PASSWORD}"
          }
      }
  }
}

triggers : cront, pollSCM, upstream 등 여러방식으로 트리거를 구성할 수 있다.
ex. 새벽 3시마다 빌드하기

Jenkinsfile (Declarative Pipeline)
pipeline {
  agent any
  triggers {
      cron('H */4 * * 1-5')
  }
  stages {
      stage('Example') {
          steps {
              echo 'Hello World'
          }
      }
  }
}

4. 젠킨스 파이프라인 예시

필자는 처음에 젠킨슴 파이프라인을 도입하게 된 이유는 여러가지 JOB들을 연계해서 한번에 실행하고 싶었고, 그것을 한눈에 보기 쉽게 대시보드로 보고싶었다.

물론, RUNDECK이라는 CD툴을 이용하면 손쉽게 workflow 구성이 가능하다.
하지만, 젠킨스의 다양한 플러그인들을 포기할 수 없었고, 파이프라인구성으로 RUNDECK처럼 꾸며보고 싶었다.

필자는 다음의 업무를 수행하고 싶었다. (필자의 업무기에 모든 내용을 전달할 순 없지만, 그냥 여러가지 일을 파이프라인으로 연결시키는것에 주목해주길 바랍니다.)

라이브 서버에서 SOURCE(컨텐츠)를 추출합니다.
추출한 SOURCE(컨텐츠)를 검증용 서버에 설치합니다.
검증용 서버에서 SOURCE(컨텐츠)를 조작(컨텐츠 url 변경) 합니다.
검증용 서버에서 변경된 SOURCE(컨텐츠)를 추출합니다.
라이브 서버에 변경된 SOURCE(컨텐츠)를 설치합니다.

즉, 현재 라이브 서버에 있는 컨텐츠를 가져와서 검증용 서버에서 변경하고, 다시 라이브서로 옮기는 작업이다.

상위의 작업을 진행하려면, 총 5번의 JOB을 수행해야하고, 매번 INPUT을 입력해줘야하기 때문에 실수가 발생할 수 있다.

def ZIP_FILE

pipeline {
    agent any
    parameters {

        choice(name: 'SOURCE',choices: "라이브 서버1\n라이브 서버2\n라이브 서버3",description: 'SOURCE-SERVER' )

        choice(name: 'TARGET',choices: "검증용 서버1\n검증용 서버2\n검증용 서버3",description: 'TARGET-SERVER' )

        text defaultValue: '''/content/path''', description: '소스 추출', name: 'SOURCECONTENT'

        text defaultValue: '''/content/path''', description: '컨텐츠 카피', name: 'COPYCONTENT'

        text defaultValue: '''/content/path''', description: '타겟 추출', name: 'TARGETCONTENT'

    }
    stages {
        stage('Source - Build') {
            steps {
                script{
                      def myjob=build job: 'LIVE_extract_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.SOURCE}"], string(name: 'TITLE', value: 'B2C_AP_Author_Build_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILTER', value: "${params.SOURCECONTENT}")]
                      def jobDisplayName=myjob.getDisplayName()
                      ZIP_FILE = jobDisplayName.split('#')[1] + ".zip"
                }

            }
        }
        stage('Target - Install(ITG)') {
            steps {
                script{
                    def myjob=build job: 'STG_Deploy_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.TARGET}"], string(name: 'TITLE', value: 'B2C_AP_Author_Deploy_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILE', value:ZIP_FILE)]
                }
            }
        }
        stage('Target - Copy') {
            steps {
                script{
                    println ZIP_FILE
                    def myjob=build job: 'STG_PageTool_Server_APPS', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.TARGET}"], string(name: 'TITLE', value: 'B2C_AP_Author_Copy_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), string(name: 'ACTION', value:'copy'), text(name: 'PAGE', value:"${params.COPYCONTENT}")]
                }
            }
        }
        stage('Target - Build') {
            steps {
               script{
                      def myjob=build job: 'STG_Build_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.TARGET}"], string(name: 'TITLE', value: 'B2C_AP_Author_Build_APPS_flag'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILTER', value: "${params.TARGETCONTENT}")]
                      def jobDisplayName=myjob.getDisplayName()
                      ZIP_FILE = jobDisplayName.split('#')[1] + ".zip"
                }
            }
        }
        stage('Source - Upload(LIVE)') {
            steps {
                script{
                    def myjob=build job: 'LIVE_Deploy_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.SOURCE}"], string(name: 'TITLE', value: 'B2C_AP_Author_Deploy_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILE', value:ZIP_FILE)]
                }
            }
        }
    }
}

간단하게 하나씩 설명을 하면,

파라미터 셋팅

choice(name: 'SOURCE',choices: "라이브 서버1\n라이브 서버2\n라이브 서버3",description: 'SOURCE-SERVER' )

        choice(name: 'TARGET',choices: "검증용 서버1\n검증용 서버2\n검증용 서버3",description: 'TARGET-SERVER' )

        text defaultValue: '''/content/path''', description: '소스 추출', name: 'SOURCECONTENT'

        text defaultValue: '''/content/path''', description: '컨텐츠 카피', name: 'COPYCONTENT'

        text defaultValue: '''/content/path''', description: '타겟 추출', name: 'TARGETCONTENT'

2개의 choice 파라미터와, 3개의 멀티라인 파라미터를 셋팅했습니다.

job 호출

stage('Source - Build') {
            steps {
                script{
                      def myjob=build job: 'LIVE_extract_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.SOURCE}"], string(name: 'TITLE', value: 'B2C_AP_Author_Build_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILTER', value: "${params.SOURCECONTENT}")]
                      def jobDisplayName=myjob.getDisplayName()
                      ZIP_FILE = jobDisplayName.split('#')[1] + ".zip"
                }

            }
        }

제일 처음에는 stages라는 block으로 전체 stage를 구성해줍니다.
그리고 각각, stgae를 맞춰서 작성합니다.

상위의 예는 1개를 뒀지만, 사실 5개의 job호출 형태는 모두 동일하기 때문에 1개에 대해서만 설명드리겠습니다.

스테이지 명시

stage('Source - Build') {
}

스텝 지정

steps {
}

스크립트 작성

script{
                      def myjob=build job: 'LIVE_extract_Server', parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.SOURCE}"], string(name: 'TITLE', value: 'B2C_AP_Author_Build_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILTER', value: "${params.SOURCECONTENT}")]
                      def jobDisplayName=myjob.getDisplayName()
                      ZIP_FILE = jobDisplayName.split('#')[1] + ".zip"
                }

스크립트의 설명은 LIVE_extract_Server라는 job을 호출합니다.

parameters: [[$class: 'com.cwctravel.hudson.plugins.extended_choice_parameter.ExtendedChoiceParameterValue', name: 'SERVER', value: "${params.SOURCE}"], string(name: 'TITLE', value: 'B2C_AP_Author_Build_APPS'), password(description: '', name: 'PASSWORD', value: 'password'), text(name: 'FILTER', value: "${params.SOURCECONTENT}")]

파라미터 셋팅 같은 경우,

extendedChoiceParameter

String

password

text

타입으로 파라미터를 넘깁니다.

5. 마치며

젠킨스 파이프라인 구성을 알아봤습니다. 정리를 하면, 우선 2가지 타입(선언, 스크립트)이 존재하며, 필자가 설명드린 선언방식의 문법 에 대해서 한가지씩 알아봤습니다.

파이프라인을 사용하는 가장큰 이유는 job들의 workflow 구성일 것입니다. 위의 방식으로 손쉽게 구성을 할 수 있을것이라고 생각이 듭니다.
워니즈 블로그
워니즈 깃헙

The post [Docker] Jenkins 파이프라인 사용법 appeared first on WONIZZ.LOG.

[Docker] Jenkins 기본 셋업

워니 — Sat, 03 Aug 2019 13:08:50 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 지난시간에 Docker 를 사용하여 Jenkins 컨테이너를 올려보는 내용까지 정리를 했습니다. 오늘은 Jenkins 의 기본 셋업에 대해서 알아보겠습니다.

Jenkins 도커로 실행하기(1/3)
Jenkins 기본 셋업(Docker 내부에서 필요한 툴 설치)(2/3)
Jenkins 파이프라인 사용법(3/3)

Jenkins 글로벌 Tools
Jenkins 필수 플러그인

1. Jenkins 글로벌 Tools

젠킨스에서는 JDK, MAVEN, NODEJS, GIT, GRADLE 등 다양한 도구들을 글로벌하게 셋팅하고 각 Job 들에서 호출해서 사용 할 수 있습니다. 마치 공용 도구함을 만들어서 망치, 못, 드릴 등을 넣어두고 다양한 곳에서 쓰이고 있다고 보면 됩니다.

필자는 아래의 도구들을 설치했습니다.

openjdk
maven
nodejs + npm
git
gradle

우선 글로벌 툴을 셋팅하는 부분은 젠킨스 관리 > 글로벌 도구 설정에서 볼 수 있습니다.

처음 보게 되는 화면은 jdk, maven 정도의 설정 밖에 없습니다. 이는 아직 연결 시켜주는 플러그인들이 설치 되어 있지 않기 때문입니다. 우선 있는대로, jdk, maven 을 셋팅해봅니다.

jdk 설정

docker로 jenkins를 올리게되면, 기본적으로 openjdk가 설치 되어있습니다.

root@1b011b567397:/# java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~deb9u1-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

따라서, jdk는 기본 설정에 /docker-java-home path만 입력 해주면됩니다.

maven

메이븐 부터는 개별적으로 컨테이너 내부에 설치를 해줘야 합니다.

docker container에 접속하여 다음을 입력합니다.

#docker container 접속
docker exec -it jenkins /bin/bash

#maven 설치
apt-get update
apt-get install maven

#설치 후 로그 확인
.
.
update-alternatives: using /usr/share/maven/bin/mvn to provide /usr/bin/mvn (mvn) in auto mode

maven은 기본 설정에 /usr/share/maven path를 입력해주면 됩니다

Node.js

우분투 16.04의 패키지 저장소에 Node.js가 기본으로 들어가져 있습니다. 이 글을 쓰는 현 시점에 v4.2.6 버전이 저장소에 올려져있습니다.

apt 패키지 매니저를 통해 손쉽게 설치할 수 있습니다.

#nodejs 설치
sudo apt-get update
sudo apt-get install nodejs

#설치 후 로그 확인
.
.
update-alternatives: using /usr/bin/nodejs to provide /usr/bin/js (js) in auto mode

이후에 npm 설치를 진행하려 하지만, 에러가 발생합니다.

#npm 설치
sudo apt-get install npm

#에러 발생
E: Unable to locate package npm

A Node.js package is also available in the official repo for Debian Sid (unstable), Jessie (testing) and Wheezy (wheezy-backports) as “nodejs”. It only installs a nodejs binary.

Node.js 에서는 특정 버전 이후에는 binary 로 설치할 것을 권장학 있습니다.

sudo apt install curl
curl -sL https://deb.nodesource.com/setup_6.x | sudo bash -
sudo apt-get install -y nodejs
sudo apt-get install -y npm

다른 패키지와의 충돌을 방지하기 위해, 우분투 저장소의 Node.js는 node 대신 nodejs 명령어를 사용합니다.

다음 명령어로 정상적으로 Node.js가 설치되었는 지 확인할 수 있습니다.

nodejs는 기본 설정에 /usr/bin path 를 입력해줍니다.

2. Jenkins 필수 플러그인

제목을 필수 플러그인라고 했지만, 사실 필자가 주로 사용하는 플러그인이라고 보면된다. 추천하는 플러그인이고 독자분의 생각에 따라 사용유무를 결정하면 됩니다.

Build Name and Description Setter
Dynamic Extended Choice Parameter Plug-In
Extended Choice Parameter
Extensible Choice Parameter plugin
Last Changes
File Operations Plugin
Build Timeout
Workspace Cleanup Plugin
NodeJS
Maven Integration
Git
Gradle

상위의 플러그인 중에 소개할만한 내용에 대해서만 정리해보았습니다.

Build Name and Description Setter

job에서 빌드를 수행하면 기본적으로 $BUILD_NUMBER라고해서 숫자로 BUILD JOB의 name 이 결정됩니다. 가독성도 떨어지고 숫자기때문에 정확하게 추적하기가 어렵습니다. 그래서 필자는 보통 job name + job 수행시간으로 기록을 합니다. BUILD NAME 셋팅을 위한 플러그인이라고 보면됩니다.

BUILD_DATE에 대한 포맷 지정을 위해서 아래의 내용을 빌드 환경탭에서 입력해줍니다.

입력하고 나면, 좀더 가독성있고 추적하기도 편리합니다.

Extensible Choice Parameter plugin

JOB은 보통 파라미터 셋팅에 따라서 다양한 업무를 수행합니다. 따라서 파라미터를 어떻게 넘기느냐가 JOB수행 여부에 중요한 요소입니다. 필자가 속한 프로젝트에서는 수많은 서버에서 반복적인 업무를 하다보니, 파라미터를 여러개 넘겨줘야 합니다.

이 플러그인은 multi choice, single choice, file choice 등 다양한 기능들을 지원합니다.

choice parameter

초이스는 한개의 싱글 select만 가능합니다.

위와 같이 test1, test2, test3을 고를 수 있게 입력을 합니다.

Multi select choice

다양하게 선택을 하게끔 해주는 기능을 구현하기 위해서는 extensible choice parameter 플러그인을 이용합니다.

위와 같이 parameter type을 multi 로 지정을 한뒤 Delimeter는 ,로 지정을 하여 파라미터를 나누어줍니다.

Last Changes

젠킨스는 형상관리 레포지토리에 있는 소스를 가져와서 빌드를 수행하고 테스트를 합니다. 그럼 이전 버전과의 차이를 알고 싶을때는 이 플러그인이 유용합니다.

3.마치며

젠킨스의 글로벌 도구 설정과 필수 플러그인에 대해서 정리해보았습니다. 젠킨스는 확실히 역사도 길고 다양한 플러그인으로 사용성을 높이고 있습니다. 필자또한 젠킨스를 알게 되면서 반복 단순한 업무들은 모두 job으로 구성하여 한번의 수행으로 해결하고 있습니다.

다음시간에는 젠킨스 파이프라인 구성에 대해서 알아보겠습니다.

워니즈 블로그
워니즈 깃헙

The post [Docker] Jenkins 기본 셋업 appeared first on WONIZZ.LOG.

[Docker] Dockerfile 의 이해

워니 — Wed, 31 Jul 2019 04:50:08 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번 시간에는 도커 파일 에 대해서 알아보도록 하겠습니다. 지난번 docker 이야기는 설치하고 기본적인 사용법과 볼륨에 대해서 알아봤습니다. 이제는 이미지가 어떻게 빌드가 되고, 이미지로부터 container를 어떻게 생성하는지 알아보는 시간을 갖도록 하겠습니다.

1. 도커파일 이란?

Dockerfile

도커 파일은 이미지를 생성하기 위한 스크립트이며, 도커 파일 빌드를 하면 완성된 이미지를 얻게 됩니다. 필자는 도커파일은 마치 이미지를 생성하기 위한 명세서라고 생각합니다. 제 3자가 도커파일만 보고 이 이미지가 어떤 역할을 하는지 어떤식으로 구성이 되어있는지 확인할 수 있습니다.

도커파일 예시 위에서 보시는것처럼 Docker에서 이미지를 생성하기 위한 방법은 3가지가 있습니다.

도커파일
컨테이너 커밋
이미지 태그

이중 가장 일반적이고 CI/CD로 활용되어지는 방법은 Dockerfile로 빌드해 이미지를 생성하는 방법입니다. 필자가 Devops 과제에서 선보인 내용에서 spring-bood app을 그라들 빌드해서 jar파일을 가져오고 Dockerfile에 명세를 젂어서 이미지로 추출하는 내용을 넣었습니다. Dockerfile은 사용자가 이미지를 생성하기위해 순차적으로 작성한 명령어로 된 Text문서이며, docker build 명령어로 Dockerfile과 Context를 통해 이미지를 생성합니다.

# mkdir /dockerfile
# cd dockerfile
# gedit dockerfile

이미지 빌드

# docker build --tag myubuntu:1.0 .
# docker images

-t, –tag : 저장소 이름, 이미지 이름, 태그를 설정합니다. <저장소 이름>/<이미지 이름>:<태그> 형식 . : Build Context

컨테이너 실행

docker run -it --rm --name myubuntu myubuntu:1.0 /bin/bash

–name : 컨테이너 명 지정 -d : 컨테이너를 백그라운드로 실행 -it : 터미널모드로 실행 -p 호스트와 컨테이너 포트를 연결해 노출 –rm 실행 후 컨테이너 자동삭제

2. 명령어

FROM

FROM  [AS ]
FROM [:] [AS ]
FROM [@] [AS ]

도커파일

FROM ubuntu:18.04

# Container에서 실행할 명령
CMD ["/bin/echo", "hello docker"]

이미지 빌드

# docker build -t localhost:5000/myununtu:v2 .
# docker run localhost:5000/myununtu:v2

LABEL

LABEL instruction는 Label로 지정한 문자열을 이미지에 메타데이터로 추가합니다. LABEL 은 key-value 쌍으로 작성하며 , space를 포함시키기 위해서는 따옴표("")를 이어쓰기를 위해서는 백슬래쉬(\)를 사용하면 됩니다.

LABEL = = = ...

도커파일

FROM ubuntu:18.04

LABEL multi.label1="value1" multi.label2="value2" other="value3"
LABEL multi.label1="value1" \
      multi.label2="value2" \
      other="value3"

# Container에서 실행할 명령
CMD ["/bin/echo", "hello docker"]

이미지 빌드

# docker build -t localhost:5000/myununtu:v2 .
# docker run -it localhost:5000/myununtu:v2 /bin/bash

이렇게 추가된 Lavel은 컨테이너 실행시 docker inspect 명령어로 내용을 확인 할 수 있습니다. 다만 주의할 것은 Base 이미지에 포함된 Lavel 값이 상속된다는 점이고, 만약 같은 Lavel값이 존재한다면 가장 최근에 적용된 Lavel값이 우선합니다.

"Labels": {
    "com.example.vendor": "ACME Incorporated"
    "com.example.label-with-value": "foo",
    "version": "1.0",
    "description": "This text illustrates that label-values can span multiple lines.",
    "multi.label1": "value1",
    "multi.label2": "value2",
    "other": "value3"
},

RUN RUN instruction는 Base Image위에 필요한 패키지를 설치할 때 사용하는 명령어입니다.. Run명령어가 수행된 이후에는 새로운 Layer가 Base이미지 위에 생성됩니다.

shell form : command 로 입력받은 명령어는 쉘에서 수행되며 디폴트로 리눅스에서는 /bin/sh -c 이 윈도우에서는 cmd /S /C 가 사용됩니다.

RUN

RUN ["executable", "param1", "param2"]

도커파일 RUN instruction은 현재생성된 이미지의 위의 새로운 레이어를 생성하여 그 안에서 명령어를 수행하고 그 결과를 레이어에 commit합니다. 따라서 \ (backslash)를 사용하여 RUN을 수행한 것과 여러개의 RUN을 수행한 것은 결과는 동일하나 생성된 레이어의 갯수가 차이가 있게 됩니다.

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y package-a
RUN apt-get install -y package-b
RUN apt-get install -y package-c

FROM ubuntu:14.04
RUN apt-get update && apt-get install -y \
        package-a \
        package-b \
        package-c

CMD CMD instruction은 Docker Container가 시작할때 실행 할 커맨드를 지정하는 지시자이며 아래와 같은 특징과 기능을 제공합니다.

CMD의 주용도는 컨테이너를 실행할 때 사용할 default 명령어를 설정하는 것입니다.docker run 실행 시 실행할 커맨드를 주지 않으면 CMD로 지정한 default 명령이 실행됩니다.
ENTRYPOINT의 파라미터를 설정할 수도 있습니다.
RUN instruction 과 기능은 비슷하지만 차이점은 CMD는 docker image를 빌드할때 실행되는 것이 아니라 docker container가 시작될때 실행됩니다. 주로 docker image로 빌드된 application을 실행할때 사용됩니다.

CMD instruction 는 아래와 같이 3가지 포맷을 지원합니다.

CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)

도커 파일

FROM ubuntu
...
CMD ["apache2","-DFOREGROUN"]

FROM ubuntu
...
CMD ["python"]

FROM ubuntu
CMD echo "This is a test."

FROM ubuntu
CMD ["/usr/bin/wc","--help"]

ENTRYPOINT

Docker image가 실행될때 기본 command를 지정합니다. CMD와 비슷하지만 CMD는 override 가 가능하지만 ENTRYPOINT 는 override 할 수 없습니다. 대신에 docker run 커맨드로 추가하는 커맨드들은 ENTRYPOINT instruction에 지정된 커맨드에 옵션으로 추가됩니다. ENTRYPOINT instruction 는 아래와 같이 2가지 포맷을 지원합니다.

ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)
ENTRYPOINT command param1 param2 (shell form)

도커파일

FROM ubuntu
ENTRYPOINT ["/bin/echo", "Hello world"]

ENTRYPOINT & CMD instruction 예제

FROM centos
ENTRYPOINT ["/bin/echo", "Hello world"]
CMD ["world"]

# gedit dockerfile

# docker build --tag localhost:5000/hello:1.1 .

컨테이너를 실행에 어떤 내용이 출력되는지 확인해봅시다.
# docker run -it localhost:5000/hello:1.1
# docker run -it localhost:5000/hello:1.1 cmdtest

EXPOSE

EXPOSE 명령은 Container가 Runtime시 수신대기할 포트를 지정하는 명령어입니다. 포트번호 및 TCP 또는 UDP를 지정할 수 있으며 프로토콜이 지정되지 않을 경우 기본값은 TCP입니다. 주의해야할 점은 EXPOSE 명령어 자체가 실제로 포트를 열지 않는다는 점입니다. EXPOSE 명령은 이미지를 만드는 사람과 이미지를 사용하는 사람이 포트 및 프로토콜 규약을 명시해놓은 문서기능을 하는 것이고 실제 Container의 포트는 docker run -p 옵션으로 Container를 실행하는 시점에 -p 옵션으로 지정된 포트가 개방됩니다.

EXPOSE  [/...]

도커파일

EXPOSE 80/udp
EXPOSE 80/tcp

ENV명령어는 환경변수 를 로 설정하는 지시자입니다. 쉽게 일반 프로그래밍에서 변수를 지정하는 것과 동일하다고 생각하면 됩니다. ENV를 사용하여 셋팅된 환경변수는 Container Runtime시에도 셋팅된 변수가 유지됩니다.

ENV  
ENV = ...

도커파일

FROM busybox
ENV FOO /bar
WORKDIR ${FOO}   # WORKDIR /bar
COPY . /quux # COPY all to /quux

COPY

호스트의 Context 내의 파일 또는 디렉터리들을 Container의 파일시스템으로 복사하는 명령어입니다. 또한 --chown 옵션으로 파일 및 디렉터리에 대한 유저와 그룹을 지정할 수 있습니다

COPY [–chown=:] … `
COPY [--chown=:] ["",... ""] (this form is required for paths containing whitespace)

도커 파일

COPY . /bar/             # adds all files and directories
COPY test.jar /bin/test/ # adds a test.jar file
COPY hom* /mydir/        # adds all files starting with "hom"
COPY hom?.txt /mydir/    # ? is replaced with any single character, e.g., "home.txt"
COPY --chown=55:mygroup files* /somedir/
COPY --chown=bin files* /somedir/
COPY --chown=1 files* /somedir/
COPY --chown=10:11 files* /somedir/

COPY --chown에 의해 주어진 유저명과 그룹명으로 지정되지 않은 모든 파일 및 디렉터리들은 Container안에서 UID, GID 0번으로 생성됩니다.

ADD는 Syntax 및 기능면에서 COPY와 유사 URL을 지정해 파일을 복사 할 수 있고 압축파일(tar)을 을 자동으로 풀어서 복사한다는 점에서 차이가 있습니다.

ADD [–chown=:] … `
ADD [--chown=:] ["",... ""](this form is required for paths containing whitespace)

도커 파일

ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all

USER

Docker로 Container를 수행할때 Container 실행 유저는 Docker의 기본설정으로 root계정입니다.

root@ubuntu:/# docker run ubuntu whoami
root

USER 명령어는 이러한 Container안에서 명령을 실행 할 유저명과 유저그룹을 설정하는 명령어이며, Dockerfile 안에서 USER명령어를 셋팅한 이후의 RUN, CMD, ENTRYPONT 명령어에 적용됩니다.

USER [:] or
USER [:]

도커 파일

# 시스템 그룹 및 유저로 postgres를 추가한다. 
RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres

# Run the rest of the commands as the `postgres` user
USER postgres

WORKDIR

WORKDIR명령어는WORKDIR명령어에 뒤따르는WORKDIR,RUN,CMD,ENTRYPOINT,COPY,ADD`명령어의 작업디렉터리를 지정하는 명령어입니다. 쉽게 말해 리눅스 cd명령어와 비슷하다고 생각하면 됩니다.

WORKDIR /path/to/workdir

도커 파일

WORKDIR /a   # 작업디렉터리를 /a로 이동합니다
WORKDIR b    # /a에서 하위의 b디렉터리로 이동합니다.
WORKDIR c    # /a/b에서 하위의 c디렉터리로 이동합니다.
RUN pwd      # RUN명령어가 실행되는 디렉터리는 WORKDIR로 이동한 /a/b/c가 됩니다.

주의할 점은, Linux cd명령어와는 다르게 만약 WORKDIR로 지정한 디렉터리가 존재하지 않을 경우, 그 디렉터리를 Container 안에 생성한다는 점에서 다릅니다. 아래와 같이 ENV로 지정한 환경변수와 함께 쓰일 수 있다는 점도 참고바랍니다.

ENV DIRPATH /path
ENV DIRNAME dname
WORKDIR $DIRPATH/$DIRNAME
RUN pwd                   # 출력결과 /path/dname

VOLUME

VOLUME 은 컨테이너에서 생성된 데이터를 영구보존하고자 할때 사용되는 명령어로 컨테이너가 실행될때 Volume 명령어로 선언된 Container 안의 지점을 Container 밖의 특정지점과 자동으로 마운트되어 컨테이너가 실행됩니다. 이때 Host에 생성되는 경로는 /var/lib/docker/volumes/{volume_name}이고, volume_name은 Docker에서 생성하는 해쉬값으로 생성이됩니다.

VOLUME ["/data"]

도커 파일

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol
CMD ["/bin/bash"]

생성한 이미지를 실행하여 볼륨을 조회해 보면 신규로 볼륨을 조회해보면 신규로 한개가 생긴것을 확인할 수 있고 생성된 볼륨디렉터리로 들어가면 dockerfile에서 생성한 file을 확인 할 수 있습니다.

root@ubuntu:/dockerfile# docker volume ls
DRIVER              VOLUME NAME
local               fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9
root@ubuntu:/dockerfile# cd /var/lib/docker/volumes && ls
fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9  metadata.db

root@ubuntu:/var/lib/docker/volumes# cd fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9
root@ubuntu:/var/lib/docker/volumes/fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9# ls
_data
root@ubuntu:/var/lib/docker/volumes/fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9# cd _data/
root@ubuntu:/var/lib/docker/volumes/fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9/_data# ls
greeting

이렇게 dockerfile에서만 Volume을 명시해두고 docker실행시 디폴트로 마운트하게되면, docker에서 자동으로 volume을 생성해주지만, Hash값으로 생성하기 때문에 관리하기가 쉽지 않습니다. 따라서 앞서 배운 내용을 바탕으로 Volume을 사전에 미리 생성해두고, 실행시 dockerfile 안에 명시된 경로로 마운트해보도록하겠습니다.

root@ubuntu:/# docker volume create volume2
volume2
root@ubuntu:/# docker volume ls
DRIVER              VOLUME NAME
local               fbfdbb0b0236c712bd8f2034aa699e0a23a6449915fad90cc0ae07e7f570b0a9
local               volume2

Volume을 컨테이너 기동시 마운트하면 이 디렉터리가 컨테이너의 지정된 디렉터리로 마운트됩니다.

# docker run -it --name volumetest --mount source=volume2,target=/myvol localhost/volumetest:v1 /bin/bash
root@a52260c673a7:/# cd /myvol && ls
greeting
root@a52260c673a7:/myvol# exit

root@ubuntu:/# cd /var/lib/docker/volumes/volume2/_data/ && ls
greeting

명령어를 정리하면서 다음과 같은 명령어는 혼동해서 사용하면 안될 것 같았습니다.

COPY vs ADD
RUN vs CMD
ENTRYPOINT & CMD

3. 실습 예제

아래 주석의 내용을 dockerfile로 완성해보세요 시작하기 전 index.html 파일은 아래와 같이 만드시면 됩니다.

# echo hello world! > index.html

# gedit dockerfile

# Base 이미지는 nginx 1.14.1 버전으로 한다.
# author는 guest이다
# 환경변수로 아래 내용을 셋팅한다.
# HTTP_PROXY "http://70.10.15.10:8080"
# HTTPS_PROXY "http://70.10.15.10:8080"
# FTP_PROXY "http://70.10.15.10:8080"
# http_proxy "http://70.10.15.10:8080"
# https_proxy "http://70.10.15.10:8080"
# ftp_proxy "http://70.10.15.10:8080"
# 패키지를 update한다.
# apt-get update
# index.html 파일을 /usr/share/nginx/html 디렉터리로 복사한다.

# 컨테이너에 tcp 80 포트을 개방한다.

# 컨테이너 시작시 필수로 아래 명령어를 수행한다.
# ["nginx"]

# 컨테이너 시작후 nginx의 실행 옵션으로 ["-g", "daemon off;"]를 수행한다.

완성된 docker file을 build 해보세요
빌드된 이미지 실행해 Host의 8080으로 포트를 매핑하고 터미널로 연결해보세요
연결된 터미널에서 curl localhost:8080 명령으로 nginx가 정상적으로 동작하는지 확인해보세요

# Base 이미지는 nginx 1.14.1 버전으로 한다.
FROM nginx:1.14.1


# 환경변수로 아래 내용을 셋팅한다.
ENV HTTP_PROXY "http://70.10.15.10:8080"
ENV HTTPS_PROXY "http://70.10.15.10:8080"
ENV FTP_PROXY "http://70.10.15.10:8080"
ENV http_proxy "http://70.10.15.10:8080"
ENV https_proxy "http://70.10.15.10:8080"
ENV ftp_proxy "http://70.10.15.10:8080"

# 패키지를 update한다.
RUN apt-get update

# index.html 파일을 /usr/share/nginx/html 디렉터리로 복사한다.
COPY index.html /usr/share/nginx/html/

# 컨테이너에 tcp 80 포트을 개방한다.
EXPOSE 80/tcp

# 컨테이너 시작시 필수로 아래 명령어를 수행한다.
# ["nginx"]
ENTRYPOINT ["nginx"]

# 컨테이너 시작후 nginx의 실행 옵션으로 ["-g", "daemon off;"]를 수행한다.
CMD ["-g", "daemon off;"]

완성된 docker file을 build 해보세요 docker build -t localhost:5000/mynginx:1.0 .
빌드된 이미지 실행해 Host의 8080으로 포트를 매핑하고 터미널로 연결해보세요 docker run -d -p 8080:80 localhost:5000/mynginx:1.0
연결된 터미널에서 curl localhost:8080명령으로 nginx가 정상적으로 동작하는지 확인해보세요 curl localhost:8080

4. 마치며

이번 시간에는 도커파일이 어떤것이고 각 명령어에 대해서 알아봤으며, 최종적으로 실습예제를 통해서 사용법을 개괄적으로 보았습니다. 확실히 도커파일이 있으면 명시적으로 어떤 이미지인지 명세를 알 수 있으며, 도커파일만 있다면 언제 어디서든지 도커 이미지를 생성해 낼 수 있기에 굉장히 편리합니다. 다음시간에는 도커의 CI/CD에 대해서 살펴보겠습니다. 워니즈 블로그 워니즈 깃헙

함께 보면 좋은 글

The post [Docker] Dockerfile 의 이해 appeared first on WONIZZ.LOG.

[Docker] Volume 의 관리

워니 — Mon, 29 Jul 2019 04:12:06 +0000

Docker 에서 데이터를 관리하는 방법에 관한 내용으로, Docker로 컨테이너를 실행 후 컨테이너 안에서 파일을 생성하면 Docker의 기본설정으로 모든 파일들을 컨테이너 안의 writable layer에 저장됩니다. 하지만 이러한 매커니즘은 실제 시스템 운영환경에서는 많은 문제를 가지고 있습니다. 예를 들어 컨테이너에서 생성한 파일들이 컨테이너가 재시작되더라도 유지되어야 한다면, 아래의 내용을 생각해 보아야 합니다.

컨테이너가 중지되면 데이터는 컨테이너와 함께 제거되고, 유지되지 않습니다.
다른 프로세스 또는 애플리케이션에서 컨테이너 안의 데이터를 사용하기 위해 컨테이너 밖으로 데이터를 가져오는 것은 번거롭거나 어려운 작업이 될 수 있습니다.
컨테이너의 writable layer에 데이터를 기록하기 위해서는 파일스시템을 관리 할 storage driver 가 필요합니다. storage driver는 리눅스의 커널을 이용해서 union filesystem을 제공하기때문에 이러한 추가적인 추상화로 인해 Host 파일시스템에 직접 데이터를 기록하는 것과 비교해보면 성능측면에서 약점으로 작용합니다.

Docker에서는 컨테이너가 중지되더라도 데이터를 유지하기 위한 방법으로 Host 머신에 파일을 저장하는 3가지 방법을 제공합니다.

Volume
Bind mount
Tmpfs mount (On Linux)

1. Volume 타입의 선택

위에서 언급한 3가지 유형의 어떤 마운트 방법을 사용하던, 컨테이너에서 보여지는 데이터는 동일하지만, 3가지 유혀의 Mount는 Host의 어떠한 영역에 마운트되느냐에 차이점이 있습니다.

Volumes** : Docker에 의해 관리되는 Host 파일시스템 영역에 데이터를 저장합니다. (/var/lib/docker/volumes/ on Linux). Docker에 의해 관리되고, Non-Docker process는 이 영역을 수정할 수 없으므로 Volume은 Docker에서 영구데이터를 관리하는 가장 좋은 방법입니다.
Bind mounts : Host 머신의 파일시스템 어디에나 파일을 저장할 수 있는 방법입니다. Docker외의 다른 프로세스에서 데이터의 접근과 수정이 가능합니다.
tmpfs mounts : Host의 메모리에 데이터를 저장하는 방법입니다.

2. Volume 타입의 상세

volume

Docker에 의해 만들어지고 관리되는 Volume은 docker volume create 명령어로 명시적으로 Volume을 생성할 수 있습니다.

root@ubuntu:/# docker volume create volume1
volume1

root@ubuntu:/# docker volume ls
DRIVER              VOLUME NAME
local               volume1

Volume을 생성하면 Docker Host 머신의 Docker에서 관리하는 디렉터리에 저장됩니다.

root@ubuntu:/# docker volume inspect volume1
[
    {
        "CreatedAt": "2019-02-22T02:25:12+09:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/volume1/_data",
        "Name": "volume1",
        "Options": {},
        "Scope": "local"
    }
]

root@ubuntu:/# ls /var/lib/docker/volumes/
metadata.db  volume1

Volume을 컨테이너 기동시 마운트하면 이 디렉터리가 컨테이너의 지정된 디렉터리로 마운트됩니다.

root@ubuntu:/# docker run -it --name myubuntu --mount source=volume1,target=/volumedata ubuntu
root@da5fe2af29c5:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  volumedata
root@da5fe2af29c5:/# cd volumedata/
root@da5fe2af29c5:/volumedata# touch hellovolume
root@da5fe2af29c5:/volumedata# ls
hellovolume
root@da5fe2af29c5:/volumedata# exit
exit

root@ubuntu:/# cd /var/lib/docker/volumes/volume1/_data/
root@ubuntu:/var/lib/docker/volumes/volume1/_data# ls
hellovolume

Container 정보를 살펴보면 기본설정으로 Volume의 읽기쓰기모드가 RW(읽기쓰기) 인 것을 알 수 있습니다. --mount 옵션에 readonly 옵션을 주어 읽기쓰기 모드를 변경 할 수 있습니다

root@ubuntu:/# docker inspect myubuntu
[
    {
        "Id": "f6369bab35f2c89c0e0fed76c024decc4c19707aa833f6407fc0b1f60f42c38c",
        "Created": "2019-02-21T23:40:56.46535649Z",
        "Path": "/bin/bash",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 29553,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2019-02-21T23:40:57.125309312Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
       ...
        "Mounts": [
            {
                "Type": "volume",
                "Name": "volume1",
                "Source": "/var/lib/docker/volumes/volume1/_data",
                "Destination": "/volumedata",
                "Driver": "local",
                "Mode": "z",
                "RW": true,
                "Propagation": ""
            }
        ],

# docker run -it --name myubuntu1 --mount source=volume1,target=/volumedata,readonly ubuntu

# docker inspect myubuntu1
[
    {
        "Id": "47e5ba4a6746ab416e2b1985040805cc7574c368989ae9d9dbe6d2186236ba33",
        "Created": "2019-02-21T23:46:07.024314426Z",
        "Path": "/bin/bash",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 29663,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2019-02-21T23:46:07.413027114Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
       ...
        "Mounts": [
            {
                "Type": "volume",
                "Name": "volume1",
                "Source": "/var/lib/docker/volumes/volume1/_data",
                "Destination": "/volumedata",
                "Driver": "local",
                "Mode": "z",
                "RW": false,
                "Propagation": ""
            }
        ],
        ...

root@47e5ba4a6746:/volumedata# touch test
touch: cannot touch 'test': Read-only file system

Volume은 동시에 여러 컨테이너에 마운트 할 수 있으며, 자동으로 Volume이 제거되지 않습니다. Volume을 제거하기 위해서는 docker volume rm, docker volume prune 명령어로 제거 할 수 있습니다.

# docker volume rm volume1

사용하지 않은 Volume을 제거하기 docker volume prune 명령어로 정리 할 수 있습니다.

# docker volume prune

volume 관련 명령어

Command	Description
docker volume create	Create a volume
docker volume inspect	Display detailed information on one or more volumes
docker volume ls	List volumes
docker volume prune	Remove all unused local volumes
docker volume rm	Remove one or more volumes

Bind mount

Bind mount는 Volume에 비해 기능이 제한되어 있습니다. Bind mount를 사용하면 Container를 Host 머신의 특정 파일이나 디렉터리로 마운트합니다. Host의 마운트 경로는 Full Path를 사용하는데, 해당 파일이나 경로가 존재하지 않을 경우 자동생성되어지기때문에 미리 생성되어 있을 필요는 없습니다.

# docker run -it -v /volume/bindmount:/data/bindmount ubuntu
root@b1f8e57c3314:/data/bindmount# cd /data/bindmount
root@b1f8e57c3314:/data/bindmount# touch testfile
root@b1f8e57c3314:/data/bindmount# ls
testfile
root@b1f8e57c3314:/data/bindmount# exit
root@ubuntu:/# cd /volume/bindmount/
root@ubuntu:/volume/bindmount# ls
testfile

Bind mount는 Volume에 비해 아래와 같은 불리한 점이 있기 때문에 가능하다면 Volume을 사용하는 것이 권장됩니다.

Bind mount는 Host의 디렉터리 구조에 의존적입니다.
Docker에 의해 관리되어지지 않습니다.
Container안의 프로세스가 Host의 파일시스템을 변경할 수 있으므로 보안상 위협이 될 수 있습니다.

tmpfs mounts

tmpfs mount는 디스크에 데이터를 영구적으로 저장하지 않고 Host의 메모리에 저장합니다. 이러한 특징 때문에 tmfs mount Container의 생명주기와 맞춰서 데이터를 보존하고자 할 때 사용되어질 수 있습니다. 예를 들어, 내부적으로 Docker swarm service는 tmpfs mount를 사용하여 컨테이너 안으로 secret을 마운트합니다.

3. 예제

docker 데이터 볼륨으로 데이터 공유를 해보겠습니다. 다음 명령을 실행하여 컨테이너를 생성하고 데이터 볼륨을 설정합니다. 컨테이너의 Bash 셸이 실행되면 /data 디렉터리로 이동한 뒤 world라는 빈 파일을 생성합니다. 그리고 exit를 입력하여 Bash 셸에서 빠져나옵니다.

$ sudo docker run -i -t --name hello-volume1 -v /root/data:/data ubuntu /bin/bash
root@f7baf3abefee:/# cd /data
root@f7baf3abefee:/data# touch world
root@f7baf3abefee:/data# exit

데이터 볼륨 옵션은 -v <호스트 디렉터리>:<컨테이너 디렉터리> 형식입니다. 여기서는 호스트의 /root/data 디렉터리를 Docker 컨테이너의 /data 디렉터리에 연결합니다. /root/data 디렉터리의 파일 목록을 출력합니다.

$ sudo ls /root/data
world

앞에서 생성한 world 파일이 보입니다. 이제 두 번째 컨테이너를 생성합니다. 컨테이너의 Bash 셸이 실행되면 /data 디렉터리의 파일 목록을 출력합니다.

$ sudo docker run -i -t --name hello-volume2 -v /root/data:/data ubuntu /bin/bash
root@af5a7bdb3e5a:/# ls /data
world

앞에서 생성한 world 파일이 hello-volume2 파일에서도 보입니다. /data 디렉터리에 파일을 생성하면 호스트 및 hello-volume1 컨테이너에서도 사용할 수 있습니다. 이렇게 데이터 볼륨 설정을 통해 컨테이너끼리 데이터를 공유할 수 있습니다. 디렉터리뿐만 아니라 호스트의 파일 하나만 컨테이너에 연결할 수도 있습니다.

$ sudo docker run -i -t --name hello-volume -v /root/hello.txt:/root/hello.txt \
    ubuntu /bin/bash

4. 마치며

이상으로 docker volume에 대해서 알아봤습니다. 필자 같은 경우는 주로, bind mount방식으로 많이 사용하고 있습니다. 정확하게 어떠한 방식이 더 좋다라고는 말씀드리기 어렵지만, 각 자의 방식에 맞춰서 유동적으로 사용하시면 될것 같습니다. 다음시간에는 Compose 구성과 사용법에 대해서 알아보겠습니다. 워니즈 블로그 워니즈 깃헙

함께 보면 좋은 글

The post [Docker] Volume 의 관리 appeared first on WONIZZ.LOG.