senior ?!

Bash shell에서 alias 활용 하기

Hello. David — Sun, 29 Apr 2018 23:14:49 +0900

개발을 하다 보면 자연스럽게 Bash shell을 접할 수 밖에 없어진다.

그래서 준비한 포스팅이다! Bash shell "alias" 명령어 이다

(Mac OS를 기준으로 설명을 하기 때문에 참고 하기 바란다.)

Mac에서 운영 또는 개발 서버를 접속을 하거나 Command명령어를 사용하여 Redis, Mysql를 실행 또는 Docker 명령어를 실행 한다.

빈번하게 하는 작업이지만 매우 귀찮은 작업 이다. (물론 여기서 말하는 것은 Local 개발용 서버를 띄울때 하는 행위들 이다)

이런 필자는 이런 귀찮은 작업을 alias에 등록 해놓고 shortcut 명령어를 입력 하여 간소화 하는 것을 매우 좋아 한다. (가끔 맥을 초기화할때 백업을 안해서 당황 스럽긴 하지만..)

먼저 자주 열고 닫는 bash_profile을 shortcut으로 만들어 보자

- bash_profile 보기 & bash 적용

alias profile='vi ~/.bash_profile'
alias apply='source ~/.bash_profile'

일단 bash profile을 열거나, shell에 alias를 적용 하는게 쉬워야 다른 명령어들도 쉽게 적용 하고 사용 할 수 있을 것 같아서 선행 작업으로 등록 한다.

최초 1회는 source ~/.bash_profile shell에 적용 해주거나 또는 현재 shell 세션을 닫고 다시 열어 주어야 한다

적용 후 명령어가 잘 실행 된다면 성공 이다.

$ profile
$ apply

자! 이제 alias 기본 사용 방법을 알아 봤으니 필자가 자주 사용 하는 명령어 리스트를 나열 해볼까 한다.

1. Redis server Run (설치 방식에 따라서 명령어가 다를 수 있으니 참고 하기 바람!)

alias rs='redis-server /usr/local/etc/redis.conf &'

2. Mysql server Run

alias ms='mysql.server start'

3. Web Server connect (shortcut "w", 대역대 끝자리 10번, 102번, 201번 서버, 예를 들어 xxx.xxx.xxx.10)

alias w11='ssh user@192.168.1.11'
alias w102='ssh user@192.168.1.102'
alias w201='ssh user@192.168.1.201'

4. Database Server connect (shortcut "d")

alias d11='ssh user@192.168.1.11'

5. Service Server connect (shortcut "service name", 서비스가 명확한 서버는 서비스명칭에 넘버링을 한다)

alias good1='ssh user@192.168.1.11'
alias good2='ssh user@192.168.1.12'

6. Aws zone Server connect (일반적으로 aws는 키로 접근 하기때문에 function으로 처리 하면 커스터 마이징이 쉽다.)

function aws() {
    ip=$1
    user=ec2-user

    if [ "$#" -gt 1 ]
    then
        user=$1
        ip=$2
    fi

    ssh -t -i ~/.ssh/test.pem $user@$ip
}

7. Backbonejs yo generator shortcut (현재 우리 프로젝트에서는 연아 프로젝트가 진행 중이다.)

function yuna(){
    yo bbs:yuna $1
}

현재 필자는 위와 같은 방식으로 alias를 관리 하고 있다.

좀 더 좋은 아이디어가 있다면 널리 공유해 주었으면 한다.

Backbonejs View 사이의 대화는 어떻게 할까? (3)

Hello. David — Sun, 22 Apr 2018 17:49:39 +0900

저번 두 포스팅에서 사용 하던 이벤트 전달 방식을 정리 해보면 두 방식 모두 부모 View를 통해서 이벤트를 전달 하였다.

Backbone event의 관련된 설명을 찾아보면, Backbone 객체는 Events를 내포되어 있다는 것을 알 수 있다. "The Backbone object itself mixes in Events"

이를 이용해 전역 이벤트를 전달 하고 받을 수 있게 할 수 있다.

- 전역적으로 선언되어있는 Backbone객체를 이용 하여 메시지를 수신 받고 전달 한다.

자바스크립트 구현은 아래와 같다:

var LayoutView = Backbone.View.extend({
    initialize: function() {
        this.mainView = new MainView();
        this.sidebarView = new SidebarView();
    }
});

var SidebarView = Backbone.View.extend({
    events: {
        'click': 'onClick'
    },
    initialize: function(options) {
    },
    onClick: function() {
        Backbone.trigger('mainViewRender')
    }
});

var MainView = Backbone.View.extend({
    initialize: function(options) {
        this.listenTo(Backbone, 'mainViewRender', this.render);
    },
    render: function() {
        console.log('클릭이 발생 했어요!');
    }
});

Backbone 객체를 이용해 이벤트를 전달하기 때문에 굉장히 제한적으로 사용 하는 것이 좋다.

위 방식은 전역적으로 Event를 전달해야 하는 경우 쉽게 메시지를 전달 하고 받을 수 있다.

예를 들면 공통으로 수신받는 "공지 메시지"나 "Websocket"을 이용해 메시지를 수신 받을때는 더할 나위 없이 좋게 활용 할 수 있다.

결론)

총 3가지 이벤트 핸들링 방식에 대해 알아보았다. 1번 방식를 이용 하여 프로젝트를 진행 하다보니 계속 이벤트를 전달 하기 위해서 View를 찾게 된다. 자식 View에서 매번 부모 View를 할당 하다보니 복잡도가 올라 간다.

현재는 2번방식을 통해서 이벤트를 영역으로 구역을 생성 하고 이벤트를 전달 하는 방식을 취하고 있다.

Backbonejs View 사이의 대화는 어떻게 할까? (2)

Hello. David — Sun, 15 Apr 2018 23:00:51 +0900

저번 포스팅에서는 부모 View를 통해서 이벤트를 전달 하는 방식에 대해 알아 보았다.

이번 포스팅에서는 Backbone Event를 이용하여 View간에 대화를 시켜 보도록 해보자.

- Layout View에서 생성된 A, B View에게 Backbone Event를 전달

- A에서는 B에게 전달할 이벤트를 Backbonejs Event를 통해서 전달 한다.

자바스크립트 구현은 아래와 같다:

var LayoutView = Backbone.View.extend({
    initialize: function() {
        this.eventBus = _.extend({}, Backbone.Events);
        this.mainView = new MainView({
            eventBus: eventBus
        });
        this.sidebarView = new SidebarView({
            eventBus: eventBus
        });
    }
});

var SidebarView = Backbone.View.extend({
    events: {
        'click': 'onClick'
    },
    initialize: function(options) {
        this.eventBus = args.eventBus;
    },
    onClick: function() {
        this.eventBus.trigger('mainViewRender')
    }
});

var MainView = Backbone.View.extend({
    initialize: function(options) {
        this.eventBus = args.eventBus;
        this.listenTo(this.eventBus, 'mainViewRender', this.render);
    },
    render: function() {
        console.log('클릭이 발생 했어요!');
    }
});

해당 예제는 Global Backbonejs Event기반으로 EventBus를 복사 한다. 그리고 자식 View에게 이벤트를 전달 한다.

즉, 자식View A와 B는 부모 View에서 생성된 EventBus를 통해서 이벤트를 주고 받는다.

A가 B에게 이벤트를 전달 하는 방식을 다시 정리 해보면 아래와 같다.

A -> EventBus -> B

장점

1. 부모 View의 객체를 접근 하지 않기 때문에 부모 View 오염될 가망성이 줄어 든다.

2. A와 B의 이벤트 통신 체계가 Backbonejs Event를 통해서 전달 받는다. (이전 포스팅 방식에서 개선된 방식)

3. Event driven방식으로 처리 된다. (Pub/Sub 구조가 가능 해진다.)

4. 브로드캐스팅 메세지 전달이 가능 하다

단점

1. 부모 View에서 아직도 자식 View에게 EventBus를 일일이 부여 해야 한다.

2. 이벤트가 어디서 발생 된건지 추적이 힘들다. (A와 B뷰 사이에서 이벤트를 발생 시키면 찾기 쉬우나 C, D, E View들이 늘어난 경우 Source를 찾을 수 없다)

이전 포스팅에서 발생된 문제를 해결 하긴 하지만 아직 완벽 하게 해결 했다고 볼 수 없다.

다음 포스팅에서는 좀 더 전역적인 EventBus를 사용하여 개선된 버전을 만들어 보자

Backbonejs View 사이의 대화는 어떻게 할까? (1)

Hello. David — Sun, 8 Apr 2018 22:14:50 +0900

Backbonejs View를 구성 하다 보면 형제 View 사이에 커뮤니케이션을 어떻게 할 것 인가의 고민이 생긴다.

위와 같은 구성의 View가 있다고 해보자 Sidebar의 메뉴를 클릭 하면 우측 Main View가 어떻게 이벤트를 전달 받아 동작 하게 만들 것 인가의 대한 고민 이다.

(이하 Sidebar View는 A, Main View B라 약칭으로 표현)

이번 포스팅에서는 부모 View를 통해서 이벤트를 전달 하는 방식에 대해 알아보자

- Layout View에서 A와 B를 생성 하고 Layout View를 전달 한다.

- A에서는 B에게 전달할 이벤트를 Layout View를 통해서 전달 한다.

자바스크립트 구현은 아래와 같다:

var LayoutView = Backbone.View.extend({
    initialize: function() {
        this.mainView = new MainView({
            parentView: this
        });
        this.sidebarView = new SidebarView({
            parentView: this
        });
    }
});

var SidebarView = Backbone.View.extend({
    events: {
        'click': 'onClick'
    },
    initialize: function(options) {
        this.parentView = args.parentView;
    },
    onClick: function() {
        this.parentView.mainView.render();
    }
});

var MainView = Backbone.View.extend({
    initialize: function(options) {
        this.parentView = args.parentView;
    },
    render: function() {
        console.log('클릭이 발생 했어요!');
    }
});

위와 같은 경우의 장점은 부모 View는 각각의 형제 View에게 자신을 전달 하고, 형제를 호출 하기 위해 부모 View에 접근 하여 형제 View 객체의 함수를 바로 호출 하게 된다. 즉 부모 View 권한을 열어 줘서 쉽게 다른 View를 접근 하게 할 수 있다.

하지만 장점보다는 단점이 더 크다. 부모 View를 넘겨줬기 때문에 부모 View가 더러워질 위험이 커지게 된다.

단적으로 보기엔 A와 B를 접근이 쉬어 보이지만 만약 B의 자식 View인 C가 생겨 났을때에 Layout View를 부여 할지, B View를 부여 할지 고민을 하게 된다

A에선 C에게 이벤트를 전달 하기 위해서 약간의 Rule이 필요 할 것 같다.

대전제: 자식 View는 바로 위 1촌 관계인 부모 View만 할당 받는다. 즉 여기서 C는 B를 부여 받는다. new CView({parentView: B});

A가 C에게 이벤트를 전달 하는 방식을 다시 정리 해보면 아래와 같다

A -> LayoutView -> B -> C -> 함수 호출

뭔가.... 부자연스럽게 복잡 하다.

위 구성이 가지는 문제는 크게 2가지로 분류 할 수 있다.

1. 하위 뷰로 내려가거나 View layout의 depth가 깊어지면 깊어 질수록 이벤트를 전달하기에 어려워진다.

2. 여러 View들에게 이벤트를 전달 할때의 대한 문제가 발생하게 된다

만약 A가 B와 C에게 같은 메시지를 전달 하고 싶다면 어떻게 해야 할까 B와 C가아닌 D가 생긴다면 머리가 복잡해진다.

다음 포스팅에서는 좀 더 스마트한 방법을 공유 하고자 한다.

Mysql 계정 생성 및 권한 설정

Hello. David — Sun, 1 Apr 2018 19:39:34 +0900

해당글은 아주 가~끔 쓰는데 자꾸 까먹어서 기록 해놓는글 이다.

계정 생성

create user '아이디'@'허용 IP' identified by '비밀번호';

예시)

-- 전체
create user 'user'@'%' identified by '1234';

-- 특정 IP
create user 'user'@'192.168.1.2' identified by '1234';

-- 특정 대역대
create user 'user'@'192.168.1.%' identified by '1234';

권한 부여

grant all privileges on *.* to '아이디'@'호스트 IP';

예시)

-- 전체
GRANT all privileges on *.* to 'user'@'%';

-- 특정 데이터 베이스
GRANT all privileges ON test.* TO 'user'@'%';

-- select 부여
GRANT select ON test.* TO 'user'@'%';

-- select, insert, update, delete 부여
GRANT select, insert, update, delete ON test.* TO 'user'@'%';

-- 프로시저 실행 권한 부여
GRANT EXECUTE ON PROCEDURE test.get_procedure TO 'user'@'%'

-- Replication 권한 부여
grant replication slave on *.* TO 'user'@'%';

사용자 삭제

drop user 'user'@'%';

권한 로드 시켜 적용
(시스템 데이터베이스의 권한 테이블에서 권한을 다시로드 한다, Reloads the privileges from the grant tables in the mysql system database.)

FLUSH PRIVILEGES;

출처: https://dev.mysql.com/doc/refman/5.7/en/flush.html

다이소 클리너로 맥북(Macbook 15) 액정 청소 하기!

Hello. David — Sun, 25 Mar 2018 20:48:27 +0900

문득 아이패드 액정과 맥북 프로 15인치 액정을 보다가 이런 생각이 들었다. "드.럽.다"

먼지, 지문자국 및 정체 모를 자국들 때문에 닦아야지.. 하고 마음만 먹었지 엄두도 못내고 있었다.

다이소에서 이리 저리 둘러 보다가 의약품 코너에 안경클리너, 핸드폰 액정 클리너가 보였다. (다시 생각 해봐도 왜 여기 있었는지 이해가 안되었다.)

여튼 이거다 싶어서 집어들고 집에와서 작업을 시작 하였다.

특히나 2015년 맥북 프로 15인치는 액정이 특수코팅 처리 되어 있으며 벗겨짐 현상이 심했으며 애플은 무상 리퍼까지 해주고 있다.

쉽게 특수코팅이 벗겨진다는 것을 애플도 인정한 셈이다.

그래서 막상 다이소 싸구려 1000원짜리 클리너가 특수코팅을 벗겨내면 어쩌나 하고 지레 겁먹고... 강화유리 필름을 씌어 놓은 아이패드 9.7인치에 작업을 시작 하였다.

일단 제품 모습 요렇게 생겼다. 가격은 1000원

제품 성분은 "에탄올", "이소프로필 알콜", "계면활성제(고급알코올계 바이온 5%미만)", "물"로 구성 되어 있다. 액성은 "중성"이다.

적용처 내용을 보면 "다만 특수 코팅이나, 특수안경, 핸드메이드 제품, 고가제품에는 사용을 삼가"해달라는 문구도 있다. (일단 무시하고)

일단 액정 청소를 하기전 아이패드 액정이 이러 했다.

가까이에서 보면 이렇다.

일단 먼지 부터 붓으로 털어 준다 (이것도 다이소... 제품)

이제 클리너 제품을 촥촥 뿌린다 그런 후 안경닦는 천으로 살살 문지르면서 클리너가 없어질때 까지 닦는다.

잘 닦고 난 후 액정 상태 이다. 다시 봐도 깔끔 한게 느껴진다.

좀 더 근접으로 다가가서 찍어본 사진다. 나름 만족.. 자 이제 아이패드는 끝이 났고..

대망에 맥북프로 15인치에 액정 상태를 살펴 보자.

먼지가 장난 아니였다.

동일하게 1.먼지털이 2.클리너 도포 3.액정닦이 순으로 진행 한다.

위 부터 먼지를 털어 내고

촥촥 클리너를 도포 한다.

슥슥 닦아 준다.

참 쉽죠? 다 닦은후 먼지털이 붓으로 먼지를 털어 주면 끝이난다.

**주의 사항 참고로 액정 특수코팅이 벗겨 질 수 있으니 힘줘서 닦지는 말고 클리너액이 사라질때까지 살살 닦아 주는게 포인트 이다.

하단부에 다 닦고 먼지를 턴 이후 촬영본이다.

모서리를 잘 닦아 내는것이 포인트 인듯 하다.

힘줘서 액정을 닦지는 않아서 코팅 벗겨짐은 없었으면 1000원으로 이렇게 깔끔하게 청소 되었다는게 만족도가 높은 제품이였다.

무려 1000원인데..

(사실 걱정 되면 그냥 물 뿌리고 천으로 닦아서 청소 하면 된다)

저는 대략 성공 한듯 하지만, 애플도 경고 하고, 클리너 제품 주의사항에도 고가 제품에는 사용 하지 말라고 하니.. 주의 해야 할 것 같지만..

나는 다음 청소때도 이제품을 이용해서 청소 할 것 같다.

끗

Gitlab Runner 활용기 (3)

Hello. David — Sun, 11 Mar 2018 23:41:45 +0900

다음 다모아 소스는 git으로 관리가 되고 있었으며, 서버 환경은 이미 Dockerizing 되어있었다.

소스는 Host OS에 특정유저에게 지정 되어 Git으로 관리 하였고, 해당 디렉토리를 Docker가 mount해서 사용 하는 구조를 가지고 있다.

그리고 Docker 안쪽은 WAS가 구동 되고 있었는데, 해당 WAS는 bash shell script로 스트립팅을 해놓았다. 이 스크립트를 실행만 해주면 되는 구조 였다.

정리를 하자면 소스는 Host os에 있으며, Docker 컨네이너가 해당 소스 디렉토리를 Mount해서 서버가 구동 되어 있고, 간단 하게 Docker 컨테이너에게 shell 명령만 전달 해주면 되는 것이였다.

Gitlab runner는 Remote branch에 push가 되면 설정된 스테이지 위에 작업 들을 실행 해준다. 그렇기 때문에 yml로 구성된 Job 설정파일을 만들어 주면 된다.

그럼! 먼저 Gitlab runner에게 yml로 구성된 Job파일을 작성 해보자

stages:
  - test

test:
  stage: test
  script:
    - cd /home/test/project && git pull origin develop
    - sudo docker exec test_contanier bash /source/script/cmd/restart
  tags:
    - my-runner

일단 스테이지를 나열 하고, 각 스테이지가 어떤 작업을 할지 작성 해준다. tag를 지정하면 tag가 지정된 Runner가 작업을 실행 해준다.

좀 더 각각 작성 된 설정을 살펴 보자.

- stages

어떤 작업들을 진행할지 나열 한다. (예를 들면 이런식? 빌드, 테스트, 배포)

stages:
  - build
  - test
  - deploy

- test (job의 명세)

- test > stage

명시된 스테이지의 작업(test)을 설정 하여, runner가 동작 할 수 있도록 한다.

- test > script

실제로 실행할 스크립트를 나열 한다.

- test > tags

작업에 지정된 tag를 runner가 확인 하여 특정 작업을 실행 할 수 있도록 한다. (예를 들면 development, test, production)

실제로 Git에 push를 하고 동작을 잘 하는지 확인을 해보자

Gitlab Project에서 Piplines > Jobs 메뉴로 가면 실행 된 작업들이 나열 된다.

해당 작업이 잘 동작 했는지 확인을 해보면 아래와 같이 문제 없이 작업이 진행 된 것을 알 수 있다.

(아래 예시는 테스트 Runner작업을 구성 해보고 잘 동작 하는지 확인 한 것이다)

참고!
간혹 작업 요청은 실행 되는데, 작업이 요청이 전달 된 후 실제로 동작 하지 않는 경우가 있다.

보통 두가지 케이스이다.
- Gitb runner가 잘 등록 안되어 있던가 (CI 서버에 Runner가 잘 등록 되어 있는지 확인한다)
- 운영 서버 또는 테스트 서버가 방화벽이 막혀 있던가 Inbind, Outbind 잘 확인 하길 바란다.

원문 & 출처: https://docs.gitlab.com/ce/ci/yaml

Gitlab Runner는 shell 명령 말고도 다양한 작업을 진행해 줄 수 있다.

우리가 가지고 있는 생각과 고민들은 이미 구현 되어 있을지 모른다. 잘 구현된 기능을 "어떻게 활용 할 것인가?"를 고민할 때인것 같다.

Gitlab Runner 활용기 (2)

Hello. David — Tue, 6 Mar 2018 21:08:40 +0900

Gitlab runner가 설치가 끝나면 이제 Runner를 등록 하고 실행 하는 과정을 거쳐야 한다

sudo gitlab-runner register

Runner가 명령을 실행 받을 서버 주소를 입력 한다

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com

Gitlab CI 에서 발급된 Token 입력 한다

Please enter the gitlab-ci token for this runner
xxxxxxxxxx

참고! Gitlab 프로젝트 > settings > pipelines를 살펴보면 주소와 토큰값을 얻을 수 있습니다.

Runner의 설명 추가 한다(추후에 GItlab UI에서 변경 가능)

Please enter the gitlab-ci description for this runner
[hostame] my-runner

gitlab-ci 태그를 입력 한다 (추후 GItlab CI UI에서 변경 가능)

Please enter the gitlab-ci tags for this runner (comma separated):
rails

Runner가 태그가 없는 작업도 실행 할지 여부 지정 한다

Whether to run untagged jobs [true/false]:
[false]: true

Runner가 해당 프로젝트에 lock을 걸어 둘지 여부 지정 한다

Whether to lock Runner to current project [true/false]:
[true]: true

Runner어떤 작업자로 동작 할지를 결정 한다

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
shell

여기까지가 Gitlab runner가 동작 하기 위한 사전 작업 이다. 다음 포스팅 에서 본격적으로 Runner가 동작 하는 방식을 다루도록 한다.

Gitlab Runner 활용기 (1)

Hello. David — Sun, 25 Feb 2018 16:15:39 +0900

다음 "다모아" 서비스를 만들면서 고민이 생겼다. "배포"... 걸림돌이었다.

Production서버에 접속하기 위해선 건너야 할 허들이 많았다.

"우리가 해야 할 배포 작업을 무언가 자동으로 해주면 좋지 않을까?" 라는 질문을 던졌고, 문제 해결을 위해 행동으로 옮기였다.

우리 팀에서 생각했던 고민은 전 세계 개발자들의 고민거리였던 것 같고, 쉽게 답을 찾을 수 있었다.

여러 가지 Tip들이 있었지만 우리는 Gitlab runner 선택하였다.

** 우리 팀은 Source 관리가 Git으로 되고 있었고, 사내에서 Private Repo는 Gitlab을 사용하고 있었다.

참고! Gitlab Runner는 Gitlab CE/EE 9.0 이상을 만족 해야 한다. (https://docs.gitlab.com/runner/index.html#compatibility-chart)

1. Linux 64bit binaries 용 파일을 다운로드 (Linux x86-64)

sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

2. Gitlab Runner에 실행 권한을 부여

sudo chmod +x /usr/local/bin/gitlab-runner

3. 계정을 생성

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

4. Gitlab Runner를 설치 및 시작

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

참고! 서버에 다른 유저 및 배포 계정이 부여 되어 있다면 초기 설치시 지정 해주면 된다.

예시)

sudo gitlab-runner install --user=test-user --working-directory=/home/test-user sudo gitlab-runner start