'plugin'에 해당하는 글 5건

S3 Output Plugin

Tool/Fluentd 2017. 4. 13. 23:10

이제 flentd 의 워크플로우와 설정 파일을 수정하는 방법을 보았으니, 내가 하고자 하는 인프라를 구축하고 td-agent.conf 파일을 수정하면 된다.

input -> (filter) -> match 모델로 거의 모든 다양한 데이터 수집이 가능한데, 흔히 쓰이는 것들을 요약하자면...

웹서버 로그 / 시스템 로그 / Rest API 등을 입력받아, Mongo / Elasticsearch / S3 / Treasure Data 등으로 전달하는 일을 주로 한다.

인터넷을 뒤져보면 더 많은 예제도 찾을 수 있다.


내가 해야 하는 작업은 아래와 같다.


1. 웹 어플리케이션에서 fluent-logger 를 통해

2. fluentd 서버로 메시지 전달

3. 수집된 로그를 가공하여 S3 로 전달

4. AWS Athena 에서 S3 데이터 쿼리


이번 포스트에서는 fluentd 에 관련된 2번, 3번을 설정 파일을 수정하여 해결해 보겠다.



S3 플러그인 설치


td-agent-gem 툴을 이용해 S3 플러그인을 설치한다.


# td-agent-gem install fluent-plugin-s3
Fetching: fluent-plugin-s3-0.8.2.gem (100%)
Successfully installed fluent-plugin-s3-0.8.2
Parsing documentation for fluent-plugin-s3-0.8.2
Installing ri documentation for fluent-plugin-s3-0.8.2
Done installing documentation for fluent-plugin-s3 after 0 seconds
cs


혹시나 아래와 같은 오류가 발생한다면...


Fetching: strptime-0.1.9.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing fluent-plugin-s3:
        ERROR: Failed to build gem native extension.
 
    /opt/td-agent/embedded/bin/ruby -r ./siteconf20170405-3324-1dj4g72.rb extconf.rb
checking for rb_timespec_now()... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
cs


Development Tools 을 설치한다.


# yum groupinstall "Development Tools" "Legacy Software Development"
or
# apt-get install build-essential
cs



td-agent.conf 수정


설정 파일에는 fluent-logger 라이브러리를 통해 forward 타입으로 입력받을 것이고, fluentd 서버가 내부망에 있으므로 외부 접근은 걱정 없다.

forward 로부터 입력받은 이벤트 tag 별로, 별도의 디렉토리에 json 으로 메시지를 쌓고, 1시간에 1번씩 AWS S3 에 로그를 업로드 할 것이다.


# vi /etc/td-agent/td-agent.conf
 
<source>
    @type forward
</source>
 
<match fanbook.*>
    @type s3
 
    aws_key_id YOUR_AWS_KEY_ID
    aws_sec_key YOUR_AWS_SECRET_KEY
    s3_bucket YOUR_S3_BUCKET_NAME
    s3_region YOUR_S3_REGION
 
    path logs/${tag[1]}/%Y/%m/%d/
    s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
    store_as json
 
    <buffer tag,time>
        @type file
        path /var/log/td-agent/s3
        timekey 1h
        timekey_wait 10m
        timekey_use_utc true # use utc
    </buffer>
    <format>
        @type json
    </format>
</match>
cs



위 설정 파일을 간단하게 분석해 보자.

<match> 지시자에 out_s3 플러그인을 설정하였고, 그 아래에는 S3 키/버킷/리전 정보를 입력하였다.

path 파라미터에는 해당 버킷에 레코드가 저장될 경로를 입력한다.

태그/년/월/일을 뜻하는 ${tag}/%Y/%m/%d/ 문법은 v0.14 에서만 표시할 수 있다. v0.12 는 path / s3_object_key_format 에 이 문법을 지원하지 않는다.

오로지 이것 때문에 아직 안정화 되지 않은 v0.14 를 선택했다 ㅡ.ㅡ;

s3_object_key_format 은 업로드할 객체 키로 전체 경로를 입력한다.

store_as 는 어떤 파일로 S3 에 업로드 할 것인지를 결정한다. default 는 압축된 gzip 이지만, json 으로 설정했다. 이 값으로 %{file_extension} 가 결정된다.


output 을 담당하는 <match> 지시자 안에는, 이벤트를 버퍼링하도록 <buffer> 섹션을 넣을 수 있다.

버퍼링은 파일로 저장되도록 @type file 을 설정했다. @type 을 지정하지 않으면 defulat 인 memory 가 설정된다.

태그별로 파일을 만들고 시간 당 업로드를 실행할 계획이므로 <buffer tag,time> 라고 지정하였다.

path 는 버퍼링 파일이 저장될 경로이다.

timekey 는 파일을 생성하여 지정한 시간 동안 버퍼링을 받고 시간이 만료되면 새로운 파일로 버퍼링 처리를 반복한다.

timekey_wait 는 버퍼링 된 파일을 ouput 플러그인(s3) 에서 처리할 시기를 결정한다. 일반적으로 Fluentd 가 지연된 이벤트를 받을 수 있도록 대기시키는 시간이다.

timekey 가 1h 이고 timekey_wait 가 10m 라면, 1시간 10분에 업로드를 시작한다.


<format> 섹션은은 이벤트 형식이다. 기본적인 파일 타입은 out_file 로 예제에서 계속 보아왔던 time|tag|record(json) 이지만, time|tag 를 빼고 record 만 넣기 위해 json 으로 변경하였다.



테스트


input : 

echo '{"json":"message01"}' | /opt/td-agent/embedded/bin/fluent-cat test.hongs
echo '{"json":"message02"}' | /opt/td-agent/embedded/bin/fluent-cat test.hongs
cs


output :

S3/logs/hongs/2017/04/11/201704110320_0.json
 
{"json":"message01"}
{"json":"message02"}
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Plugin parameter

Tool/Fluentd 2017. 4. 12. 23:29

각 Fluentd 플러그인에는 일련의 파라미터가 있다.

예를 들어, in_tail 플러그인에는 rotate_wait 및 pos_file 과 같은 파라미터가 있다. 

각 파라미터에는 연관된 특정 타입이 있으며, 각 다음과 같이 정의된다 :



파라미터 데이터 타입


string

필드가 문자열로 분석된다. 이것은 가장 일반적인 타입으로 각 플러그인이 문자열 처리 방법을 결정한다.

문자열에는 인용되지 않은 한 줄의 문자열, 따옴표(')로 인용된 문자열, 쌍따옴표(")로 인용된 문자열 등으로 구분할 수 있다.


integer

필드가 정수로 분석된다.


float

필드가 부동소숫점으로 분석된다.


size

필드가 바이트 수로 분석되며 몇 가지 표기법이 있다.

- 값이 <INTEGER>k 또는 <INTEGER>K 와 일치하면, 값은 INTEGER(KByte) 이다.

- 값이 <INTEGER>m 또는 <INTEGER>M 과 일치하면, 값은 INTEGER(MByte) 이다.

- 값이 <INTEGER>g 또는 <INTEGER>G 와 일치하면, 값은 INTEGER(GByte) 이다.

- 값이 <INTEGER>t 또는 <INTEGER>T 와 일치하면, 값은 INTEGER(TByte) 이다.

- 나머지는 byte 수이다.


time

필드가 시간으로 분석된다.

- 값이 <INTEGER>s 와 일치하면, 값은 INTEGER(초) 이다.

- 값이 <INTEGER>m 과 일치하면, 값은 INTEGER(분) 이다.

- 값이 <INTEGER>h 와 일치하면, 값은 INTEGER(시) 이다.

- 값이 <INTEGER>d 와 일치하면, 값은 INTEGER(일) 이다.

- 나머지는 float 로 분석되며 float 는 초단위의 수이다. 이 옵션은 "0.1"(=0.1초 = 100ms) 와 같이 1초 미만의 시간을 지정하는 데 유용하다.


array

필드가 JSON 배열로 분석된다.


hash

필드가 JSON 객체로 분석된다.


거의 모든 프로그래밍 언어 및 인프라 도구에서 JSON 값을 쉽게 생성할 수 있기 때문에 array 및 hash 타입은 JSON 형식이다.



플러그인의 공통 파라미터


아래 파라미터들은 시스템 예약어이며, @ 접두사를 가진다.


- @type : 플러그인 타입 지정.

- @id : 플러그인 id 지정. in_monitor_agent 는 plugin_id 필드에 이 값을 사용한다.

- @label : label 기호 지정.

- @log_level : 플러그인 별 로그 수준 지정.


type, id, log_level 은 이전 버전과 호환된다.



Multiple line 


쌍따옴표(") 부호가 있는 string, array, hash 값에 대해 다중 행을 쓸 수 있다.


str_param "foo  # This line is converted to "foo\nbar". NL is kept in the parameter bar"
array_param [
  "a""b"
]
hash_param {
  "k":"v",
  "k1":10
}
cs


Fluentd 는 [ 또는 { 가 array / hash 의 시작으로 판단한다.

따라서 [ 또는 { 시작되었지만 non-json 파라미터를 설정하려면 ' 또는 " 을 사용하라.


예제1: mail 플러그인


<match **>
  @type mail
  subject "[CRITICAL] foo's alert system"
</match>
cs


예제2: map 플러그인


<match tag>
  @type map
  map '[["code." + tag, time, { "code" => record["code"].to_i}], ["time." + tag, time, { "time" => record["time"].to_i}]]'
  multi true
</match>
cs



Ruby 코드 포함


" 인용 부호 string 에서 #{} 부호로 Ruby 코드를 삽입할 수 있다.

이것은 호스트 이름 같은 컴퓨터 정보를 설정하는 데 유용하다.


host_param "#{Socket.gethostname}" # host_param is actual hostname like `webserver1`.
env_param "foo-#{ENV["FOO_BAR"]}" # NOTE that foo-"#{ENV["FOO_BAR"]}" doesn't work.
cs


config-xxx 혼합 형식은 "#{}" 이 아닌 "${}" 을 사용한다.


큰 따옴표로 묶인 string 에서 \는 이스케이프 문자이다.

\는 이스케이프 문자로 해석된다.

큰 따옴표로 묶인 string 에서 \, \r, \n, \t, \ 등에는 \ 를 붙여야 한다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

td-agent.conf 문법

Tool/Fluentd 2017. 4. 11. 01:10

이 설정 파일을 수정하여 사용자 정의하기 전에 몇가지 문법을 확인해 보자.

설정 파일에서 쓰이는 지시자(Directives) 목록은 다음과 같다.


- source : 입력 형태 결정.

- match : 출력 목적지 결정

- filter : 이벤트 처리 파이프라인 결정

- system : 시스템 광역 설정

- label : 내부 라우팅을 위한 출력 및 필터를 그룹화

- @include : 다른 설정 파일 삽입



1. source


input 플러그인을 매개변수로 하는 지시자로 어떤 방식으로 이벤트를 입력받을 것인지 설정한다.

Fluentd 의 표준 input 플러그인에는 http 와 forward 가 있다.

http 플러그인은 fluentd 를 HTTP 엔드포인트로 바꿔 HTTP 메시지를 전달 받는다.

forward 플러그인은 fluentd 를 TCP 엔드포인트로 바꿔 TCP 패킷을 전달 받는다.

원하는 만큼 source 지시자를 추가하여 동시에 여러개의 이벤트를 받아들일 수 있다.


각 source 지시자에 사용할 input 플러그인을 tyep 파라미터(@type) 에 설정한다.

사이트에서 더 많은 input plugin 리스트를 확인할 수 있다. (http://docs.fluentd.org/v0.12/articles/input-plugin-overview)


# Receive events from 24224/tcp
# This is used by log forwarding and the fluent-cat command
<source>
  @type forward
  port 24224
</source>
 
# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>
cs


source 는 Fluentd 의 라우팅 엔진에 이벤트를 전송한다. 이벤트는 tag, time, record 의 세 엔티티로 구성된다.

- tag 는 마침표 '.' (예: myapp.access) 로 구분된 문자열이며 Fluentd 내부 라우팅 엔진의 지침으로 사용된다.

- time 필드는 input 플러그인으로 부터 지정되며 Unix 시간 형식이어야 한다.

- record 는 JSON 객체이다.


tag 는 모든 문자를 허용하지만, output 플러그인에서 다른 컨텍스트로 전달되어 사용(예: table / database / key name 등) 되기 때문에 되도록 소문자, 숫자, 밑줄 정도만 사용하는 것이 좋다. (정규식: ^[a-z0-9_]+$)


위의 예에서 HTTP input 플러그인으로 이벤트를 전송하는 예제이다.


# generated by http://this.host:9880/myapp.access?json={"event":"data"}
tag: myapp.access
time: (current time)
record: {"event":"data"}
cs



2. match


match 지시자은 source 지시자로부터 전달받은 이벤트 중 일치하는 tag 가 있는 이벤트만을 찾아 처리한다.

주로 다른 시스템에 이벤트를 출력하는 등의 동작을 하여 output 플러그인이라고 한다.

Fluentd 의 표준 output 플러그인은 file 과 forward 가 있다.

file 은 다른 파일에 출력을 기록할 때, forward 는 다른 서버로 출력을 보낼 때 사용한다.


# Receive events from 24224/tcp
# This is used by log forwarding and the fluent-cat command
<source>
  @type forward
  port 24224
</source>
 
# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>
 
# Match events tagged with "myapp.access" and
# store them to /var/log/fluent/access.%Y-%m-%d
# Of course, you can control how you partition your data
# with the time_slice_format option.
<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>
cs


각 match 지시자은 tag 와 매칭할 패턴 및 사용할 output 플러그인을 지정하는 type 파라미터(@type) 를 포함해야 한다. 

패턴과 일치하는 tag 의 이벤트만 output 목적지로 전송된다. (위의 예에서는 "myapp.access" 태그가 있는 이벤트만 일치).


match 패턴

- * 는 tag 의 마침표(.)로 구분된 한 파트와 매칭 : a.* 는 a.b 와 일치, a 나 a.b.c 와 불일치)

- ** 는 tag 의 마침표(.)로 구분된 모든 파트와 매칭 : a.** 는 a, a.b, a.b.c 와 일치

- {X,Y,Z} 는 X tag, Y tag, Z tag 등이 매칭. 여러 tag 리스트를 콤마로 구분해 지정할 수 있으며 *,** 도 사용 가능하다. : a.{b,c.**} 는 a.b 나 a.c.** 와 일치

- 하나의 match 지시자안에 여러개의 패턴을 공백으로 구분할 수도 있다. 


match 순서

match 지시자도 여러 개를 사용할 수 있으며 상단에 쓰여진 순서대로 일치 여부를 판단한다.

아래처럼 match 지시자가 있을 때 두번째 match 지시자(myapp.access 패턴) 는 불려질 수 없다.


# ** matches all tags. Bad :(
<match **>
  @type blackhole_plugin
</match>
 
<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>
cs


마찬가지로 사이트에서 더 많은 output plugin 리스트를 확인할 수 있다. (http://docs.fluentd.org/v0.12/articles/output-plugin-overview)



3. filter


filter 지시자는 match 와 동일하지만, 또 다른 filter 로 전달이 가능하다. (chained pipeline)

Input -> Output 플로우가 filter 를 거치면 Input -> filter 1 -> ... -> filter N -> Output 가 된다.

아래는 표준 filter 인 record_transformer 를 사용한 예이다.


# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>
 
<filter myapp.access>
  @type record_transformer
  <record>
    host_param "#{Socket.gethostname}"
  </record>
</filter>
 
<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>
cs


먼저 {"event":"data"} 이벤트는 record_transformer 플러그인을 사용하여, 이벤트에 "host_param" 이라는 필드를 추가하고, 추가된 필드 {"event":"data","host_param":"webserver1"} 를 match 지시자의 file output 으로 보낸다.


<filter> 순서 역시 <match> 과 동일하게 쓰여진 순서대로 처리되므로 <match> 전에 <filter> 가 들어가야 한다.



4. system


system 지시자로 지정되는 다음 설정들은 fluentd 콘솔 명령의 옵션들과 동일하다.


log_level - 로그 표시 수준

suppress_repeated_stacktrace - true 로 설정되면 로그에 stacktrace 를 숨김 (기본값)

emit_error_log_interval - 오류 로그를 내보내는 시간 간격(초)

suppress_config_dump - 설정 파일의 내용이 로그에 표시되지 않음.

without_source - input 플러그인 없이 시작 (오래된 버퍼를 비울때 유용)

process_name - 프로세스 이름 변경


<system>
  # equal to -qq option
  log_level error
  # equal to --without-source option
  without_source
  # ...
</system>
cs



5. label


label 지시자는 내부 라우팅을 위한 ouput 및 filter 를 그룹화하여, tag 처리의 복잡성을 줄여준다.

tag 접두사 없이 이벤트를 구분할 때 특히 유용하다.

label 은 내장 플러그인 파라미터이므로 매칭시킬 때는 아래 예제처럼 @ 접두사를 붙여 준다.


<source>
  @type forward
</source>
 
<source>
  @type tail
  @label @SYSTEM
</source>
 
<filter access.**>
  @type record_transformer
  <record>
    # ...
  </record>
</filter>
<match **>
  @type elasticsearch
  # ...
</match>
 
<label @SYSTEM>
  <filter var.log.middleware.**>
    @type grep
    # ...
  </filter>
  <match **>
    @type s3
    # ...
  </match>
</label>
cs


위 설정에서 forward 이벤트는 elasticsearch output 으로 라우트되고, in_tail 이벤트는 @SYSTEM label 의 grep filter 와 s3 ouput 으로 라우트 된다.

이처럼 label 은 <filter>, <match> 지시자등을 그룹화 할 수 있다.


@ERROR label

@ERROR label 은 플러그인의 emit_error_event API 에 의해 생성된 오류 레코드에 사용되는 내장 label 이다.

<label @ERROR> 를 설정하면 관련된 오류가 발생했을 때 이벤트가 이 label 로 라우팅 된다. (예: 버퍼가 가득 찼거나 유효하지 않은 레코드일 때)



6. @include


@include 지시자를 사용하여 별도의 설정 파일에 있는 지시자를 가져올 수 있다.


# Include config files in the ./config.d directory
@include config.d/*.conf
cs


@include 지시자는 정규 파일, glob 패턴http URL 규칙 등으로 경로를 지정할 수 있다.


# absolute path
@include /path/to/config.conf
 
# if using a relative path, the directive will use
# the dirname of this config file to expand the path
@include extra.conf
 
# glob match pattern
@include config.d/*.conf
 
# http
@include http://example.com/fluent.conf
cs


glob 패턴에서 파일은 알파벳순으로 불려지므로, a.conf 와 b.conf 가 있으면 fluentd 는 a.conf 를 먼저 분석한다.

중요한 설정 파일은 안전하게 @include 로 따로 구분하라.


# If you have a.conf,b.conf,...,z.conf and a.conf / z.conf are important...
 
# This is bad
@include *.conf
 
# This is good
@include a.conf
@include config.d/*.conf
@include z.conf
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Freestyle project

Tool/Jenkins 2017. 2. 13. 23:40

Jenkins 설치를 진행하여 Jenkins 웹UI에 접속할 수 있었다. 영어와 한글이 혼합되어 있는 이 모습이 썩 맘에 들진 않는다;

암튼 다음 할 일은 Pipeline 을 생성하고 설정하여 우리가 하려는 CI 기능을 동작시키는 것이다.

Pipeline 이란 것은 빌드나 테스트, 배포 등의 단계를 구성하는 하나의 프로젝트 정도로 봐도 될 것 같다.


Pipeline 을 정의하는 방법은 두가지가 있다.

- 웹UI 를 이용하는 방법

- Jenkinsfile 을 이용하는 방법


어느 것을 사용하던 동작은 동일하다.

웹UI를 따라서 선택하고 입력한 것이나, Jenkinsfile 에 DSL 코드로 작성하는 것이나 동일한 동작을 하게 할 수 있다.

SCM 을 이용하여 협업 등을 이유로 메뉴얼에서는 Jenkinsfile 의 사용을 추천하고 있다.


그러나...


나는 freestyle project 를 먼저 사용해 봤다.

단계별 어떤 옵션들이 있는지 정도는 알아야 Pipeline 을 작성할게 아닌가 ㅜ



* Jenkins 에게 원하는 목표

- Git 소스 체크아웃

- 소스 빌드(gradle)

- 빌드 파일 원격 서버로 업로드



기본 설정


1. 플러그인 설치

[Jenkins 관리] - [플러그인 관리]

- git plugin

- gradle plugin

- publish over ssh 


2. ssh 서버 설정

[Jenkins 관리] - [시스템 설정] 에서 배포할 타겟 서버를 구성한다. (굳이 ssh 를 이용할 필요가 없다면 ftp 플러그인을 받아 설정하면 된다.)

- hostname / username 과 [고급]에서 private Key 입력

- Test Configuration 으로 접속 테스트


3. gradle 설정

[Jenkins 관리] - [Global Tool Configuration]

- Install automatically > 체크 원하는 버전 선택



freestyle project



1. freestyle project 생성

[새로운 Item] - [freestyle project]


2. 소스 코드 관리

- Git Repository URL 정보 입력


3. Build

- Build : Invoke Gradle 선택


4. 빌드 후 조치

- Sned build artifacts over SSH 선택

- SSH Server Name : [시스템 설정]에서 구성한 타겟 서버 선택

- Source files : **/build/libs/*.war

- Remove prefix : /build/libs/

- Exec command :


sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
cs


5. Build Now

[Console Output] 에서 성공/실패 로그를 확인할 수 있다.


Started by user LeeHongKyu
Building in workspace /var/lib/jenkins/workspace/freestyle project
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/ggamzzak/javatest.git # timeout=10
Fetching upstream changes from https://github.com/ggamzzak/javatest.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/ggamzzak/javatest.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 7599f414e9beb11d4d1350e571b83b2290557465 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7599f414e9beb11d4d1350e571b83b2290557465
 > git rev-list 7599f414e9beb11d4d1350e571b83b2290557465 # timeout=10
[Gradle] - Launching build.
[freestyle project] $ /var/lib/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle33/bin/gradle
Starting a Gradle Daemon (subsequent builds will be faster)
:help
 
Welcome to Gradle 3.3.
 
To run a build, run gradle <task> ...
 
To see a list of available tasks, run gradle tasks
 
To see a list of command-line options, run gradle --help
 
To see more detail about a task, run gradle help --task <task>
 
BUILD SUCCESSFUL
 
Total time: 12.231 secs
Build step 'Invoke Gradle script' changed build result to SUCCESS
SSH: Connecting from host [ip-172-31-27-119]
SSH: Connecting with configuration [honghost1] ...
SSH: EXEC: STDOUT/STDERR from command [sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
] ...
Stopping tomcat8: [  OK  ]
Starting tomcat8: [  OK  ]
SSH: EXEC: completed after 2,003 ms
SSH: Disconnecting configuration [honghost1] ...
SSH: Transferred 1 file(s)
Finished: SUCCESS
cs


중간에 BUILD SUCCESSFUL 로 빌드가 성공한 것을 확인할 수 있고, 제일 마지막의 SUCCESS 로 모든 과정이 성공한 것을 확인할 수 있다.

타겟 서버에 접속해서 새로운 빌드 파일로 배포가 되었는지 확인한다.

지금까지 아주 기본적인 설정만을 선택하여 Git 소스 체크아웃 받고 gradle 로 소스를 빌드하고 타겟 서버에 빌드 파일을 업로드한 것을 확인할 수 있다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

ignore plugin

Tool/IntelliJ 2016. 12. 11. 16:29


버전 관리는 git 이다 subversion 이다 여러가지 붙여놓구선 ignore 파일 생성을 쉽게 관리할 수 없게 한건 너무한거 아님?

[Setting] - [Version Control] - [Ignored Files] 에 추가하는건 버전관리도 안되고 공유도 안되고 쫌 그런데...


그렇게 찾아본 ignore 플러그인은 정말 괜츈하더이다.


여러가지 ignore 파일 생성도 쉽고, 하이라이팅에, 템플릿 제공까지.

이 플러그인 하나로 ignore 은 끝!




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,