fn(Rice) -> Code

기본   설정은 INI 포멧을 사용 ANSIBLE_CONFIG  ./ansible_config ~/.ansible.cfg /etc/ansible/ansible.cfg 순서로 설정을 찾는다 ANSIBLE_ 로 시작하는 환경변수는 설정 파라미터로 사용할 수 있다. export ANSIBLE_SUDO_USER=root 설정관리 툴셋 Puppet: manifest Chef: cookbook Ansible: playbook playbook은 yml 사용 yml 자료: https://www.digitalocean.com/community/tutorials/how-to-create-ansible-playbooks-to-automate-system-configuration-on-ubuntu Chef나 Puppet은 Ruby를 사용 facts 라는 것은 시스템 환경변수를 말한다 - name: “Show how debug works” debug: {{ ansible_distreibution }} Inventory INI 포멧의 file 이다  -i 또는 --inventory-file  ansible.cfg에 host_file이 기본 설정  group을 정할 수 있다 [webservers] 192.168.0.1 192.168.0.2 group of group [webservers] 192.168.0.[1:100] [dbservers] 192.168.0.[1:100] [restartable] webservers webservers regexp [webservers] 192.168.0. [1:100] external variable 192.168.1.2 ansible_ssh_private_key_file =~/.ssh/aaa.pub command module 쉘변수나 오퍼레이터 <, >, |, & 등은 안됨  C에서 fork

⌘ 카우치베이스 서버 클러스터는 1개 부터 1024개 까지 노드로 구성 될 수 있다.   ⌘ 노드 하나가 하나의 카우치베이스 인스턴스.   ⌘ 데이터는 클러스터내 노드들에서 파티션되고 분산된다.   ⌘ 카우치베이스 서버는 두개의 주요 컴포넌트가 있다. 클러스터 매니저 * 클러스터내 노드 설정 * 노드간 데이터 리발란싱 * 페일오버 후 데이터 복제 핸들링 * 통계자료 수집 * 로깅 * 클라이언트가 어디서 데이터를 찾아야 하는지 알려줄 수 있게 클러스터 맵(Cluster map)을 업데이트하며 관리한다. * 어드민 API를 노출하고 있고 웹 매니징 콘솔도 있다. * 클러스터 매니저는 distributed, concurrent 한 처리에 적합 하도록 Erlang/OTP로 만들어졌다. 데이터 매니저 * 데이터 저장소와 검색에대한 관리 * 메모리 케시 레이어, Disk Persistence Mechanism, 쿼리 엔진을 포함하고 있다 * 카우치베이스 클라이언트는 카우치베이스 매니저가 제공하는 클라이언트 맵을 사용한다. 이 맵을 통해 필요한 데이터를 가진 노드를 찾고 그 노드와 통신한다.   ⌘ 데이터 스토리지 카우치베이스는 데이터를 버킷에 관리한다. * 리소스와 연관된 로지컬한 그룹이다. * 오라클의 스키마 정도로 생각하면 된다. 두가지의 버킷종류를 제공한다. * 카우치베이스 * 멤케시 멤케시 버킷은 * 1MB 크기의 메모리에 바이너리로 데이터를 저장한다. * 데이터를 디스크에 저장하지 않는다. * Redundancy 하려고 노드에 데이터를 복제 하지 않는다. 카우치베이스 버킷은 * JSON Document, Primitive data 타입이나 Binary blob 형태로 20MB 까지 데이터를 저장 할 수 있다. * 데이터는 메모리에

간단,, git 명령어로 tag 생성 $ git tag 0.1 $ git push origin 0.1 또는 https://github.com/{id}/{repository}/releases (저장소 메인에서 release 클릭해서 이동) "Create a new release" 또는 "Draft a new release" https://github.com/{id}/{repository}/releases/tag/{tag_name} 에서 태그별 확인 가능 역시 간단,, git 명령어로 tag 삭제 $ git tag -d 0.1 $ git push origin :0.1 또는 https://github.com/{id}/{repository}/releases/tag/{tag_name} 에서 Delete 버튼 참고 https://help.github.com/articles/creating-releases/ http://stackoverflow.com/questions/18216991/create-a-tag-in-github-repository

⌘ 웹사이트 소스코드는 angular.js가 빌드 될 때 생성 /angular.js/blob/master/Gruntfile.js#L310 docs 라는 Grunt Task가 정의 /angular.js/blob/master/lib/grunt/plugins.js#L37-L42   ⌘ 결과 확인 쉘에서 명령어를 실행 grunt package webserver 브라우저에서 URL 접근 http://0.0.0.0:8000/build/docs angularjs.org 와 동일한 화면이 보임   ⌘ docs 빌드는 glup 사용   ⌘ 문서생성은 dgeni 사용 /angular.js/blob/master/docs/gulpfile.js#L5 /angular.js/blob/master/docs/gulpfile.js#L51-L57   ⌘ bootstrap CSS와 AngularJS로 만들어짐 /angular.js/blob/master/docs/docs.config.js#L80-L98 /angular.js/blob/master/docs/docs.config.js#L99-L105     ⌘ Dgeni   ⌘ Dgeni는 document processor들을 파이프라인으로 연동한 툴, 즉 여러 document processor 묶음이다. Technology agnostic - 서로 다른 문제들을 해결 위해 여러 다른 도구들을 사용한다는 관점 http://en.wikipedia.org/wiki/Document_processor /dgeni#architecture /dgeni-example/blob/master/README.md#why-should-i-use-dgeni   ⌘ 기본 엔진은 구현은 간단?! 프로세서들이 Promise를 통해 Chaining 됨 /dgeni/blob/master/lib/doc-processor.js#L108-L134  

웹사이트 소스코드는 https://github.com/angular/angularjs.org 소스코드는 https://github.com/angular/angular.js 대충 보면 두 개가 헷갈림 ⌘ 빌드는 Grunt 기반, 빌드는 쉽다 grunt package ⌘ 별도의 모듈 관리 시스템 사용하지 않음 angularFiles.js 에 angular와 karma 두 가지에 관련된 파일 리스트들을 관리 요렇게 사용 /angular.js/blob/master/Gruntfile.js#L114 /angular.js/blob/master/Gruntfile.js#L160 ⌘ 버전에 필요한 정보는 Git 명령어로 추출 예: getCodeName 예: getBuild 예: getTaggedVersion 예: getPreviousVersions ⌘ semver 사용 getSnapshotVersion ⌘ plugins.js에 Task들 정의 ( 그닥,, 분리할 이유는,, ) /angular.js/blob/master/Gruntfile.js#L10 /angular.js/blob/master/lib/grunt/plugins.js ⌘ Travis CI 에서는 unit 또는 e2e 테스트만 돌림 /angular.js/blob/master/Gruntfile.js#L25 /angular.js/blob/master/.travis.yml#L34 /angular.js/blob/master/scripts/travis/build.sh ⌘ Grunt에 등록된 Task는 test류, minify, package, ci-checks등이 있음 ci-checks Task는 ddescribe-iit, merge-conflict, jshint, jscs 4가지를 체크 ddescribe-iit 파일내용중에 ddescribe(?) 나 iit(?)가 있는지 검사 /grunt-ddescribe-iit/blob

⌘ 카우치베이스 뷰 Key 기반 동작은 데이터 접근에 효율적이고 성능도 좋지만 복잡한 동작엔 제한적이다. Document 기반에서는 컨텐트를 효과적으로 쿼리 할수있다. View 와 N1QL 두가지 방법을 제공한다. 뷰는 인덱스를 생성한다. 뷰는 자바스크립트로 작성된 MapReduce function 이다. 뷰는 Design Documents 에 하나 이상 저장될수 있다. ⌘ 뷰 생성하기 뷰를 큰 데이터셋으로 생성하면 클러스터 성능에 영향이 있을 수 있기 때문에 Development View를 생성해서 테스트 할 수 있다. Development View는 Development Design Document 에 생성되고 Production View 로 Publish 할 수 있다. 뷰의 생성과 수정은 Admin Console에서도 가능하고 Code 에서도 가능하다. ⌘ 뷰에 쿼리하기 Key로 쿼리하기 view.query({limit: 10, key: username}, function (error, results) { ... }); 범위로 쿼리하기 view.query({startkey: startDate, endkey: endDate}, function (error, results){ ... }); 정렬 순서 Null False True Number Text ( 대소문자 가림, 소문자 우선, UTF-8 순서 ) Arrays ( 저장된 값으로 동일하면 인덱스 순 ) Object ( 키 알파벳순 ) view.query({startkey: endDate, endkey: startDate, descending: true}, function (error, results){ ... }); 페이징 skip 파라메터와 limit 파라메터의 조합으로 사용 view.query({limit: 10, skip: 10, key: username}, funct

⌘ 카우치베이스는 Key-Value Store인 동시에 Document 데이터베이스다. ⌘ Document를 저장할때는 1차적으로 메모리에 캐시되고 경우에 따라 디스크에 저장된다. Eventually Persistent Model ⌘ Optimistic Concurrency와 Pessimistic Concurrency를 제공한다. Optimistic Concurrency  -> 저장시점에 변경이 있으면 업데이트가 실패 (check-and-set) Perssimistic Concurrency -> 리소스에 접근 자체를 막는다. (get-and-lock) ⌘ Item을 저장할때 기본 TTL은 0이다. 즉, Document는 Nerver Expired. ⌘ 카우치베이스는 JSON Document의 일부를 업데이트 하지 않고 전체를 새 버전으로 바꾼다. ⌘ set 메소드는 create new item and override를 의미한다. 논리적으로 upsert ( insert-or-update ) 이다. ⌘ add 메소드는 set과 유사하지만 동일 키가 있으면 에러난다. ⌘ get-and-touch는 일시적인 값을 다룰때 유용하다. 가령 특정기간 동안 임시 저장을 할 수있다. 값을 읽을때 마다 expire time을 연장할 수 있다.  -> client.get(KEY, {expiry: 3600, callback}); ⌘ CAS (check-and-set) Get-with-CAS: 값을 가져온 후 업데이트 가능 여부를 체크 -> connection.get(KEY, function(err, result) { ... update(result); } Check-and-Set: 값을 업데이트 할 때 체크 -> connection.set(KEY, DOC, {cas: cas}, function(err, result) { ... if(!err) / success / } ); ⌘ lock