A sentimental robot

Docker 예제로 공부하기

GOD03219 — Fri, 12 Jul 2019 14:50:15 +0900

예제1

$docker pull nginx:lastest

최신 버전 nginx 이미지를 다운받는다.

$docker run -d nginx:lastest

*컨테이너 이름을 정하고 싶으면 --name이라는 옵션이 있다.

$docker run -d --name jello nginx:lastest

요렇게 컨테이너에서 nginx 서버를 실행 시켰다! 포트 값을 지정해 주지 않아 디폴트 값으로 8000포트에서 nginx 서버를 열었다고 가정하자.

그렇데 만약 호스트 서버에서 이미 8000포트를 쓰고 있다면? -p 옵션을 통해 port forwarding 을 하면 된다.

$docker run -d -p 8000:80 nignx:lastest

호스트의 8000포트를 80포트로 연결

예제2

$docker run -i -t --name jello ubuntu:14.04 /bin/bash

ctrl+p+q 호스트로 빠져나오자

$docker ps

jello 컨테이너에서 우분투 배쉬가 실행 상태임을 확인

$docker exec jello touch /index.txt

jello 컨테이너에서 실행되고 있는 프로그램 명령어로 루트 디렉토리에 파일 생성

$ls /

루트 디렉토리 확인 , 호스트의 루트이기 때문에 index.txt는 찾아 볼 수 없음

$docker attatch jello

jello 컨테이너로 들어가서

$ls /

index.txt 찾았다!요놈!

Docker

GOD03219 — Fri, 12 Jul 2019 14:37:09 +0900

이제 그 무겁던 VM은 이제 안녕! 도커라는 개쩌는 게 나왔다.

도커에는 이미지와 컨테이너라는 두 가지 핵심 개념이 있다.

간단하게 말해서 이미지는 내가 사용하고 싶은 프로그램이 실행되기 위해 필요한 파일과 라이브러리이고,

컨테이너는 이미지가 실행되는 독립된 공간이며 컨테이너 상에서 이미지가 실행되기 때문에 프로세스라는 개념으로 이해할 수 있다.

도커는 기본적으로 리눅스 환경을 지원한다. 리눅스 사용자는 터미널을 통해 도커를 설치할 수 있지만 mac OS와 Windows를 사용하고 있다면 자세한 내용은 공식 홈페이지를 참고하자. 나는 맥 환경에서 도커를 써보기 위해 docker.dmg 패키지를 설치해 보았다.

https://docs.docker.com/docker-for-mac/install/

Install Docker Desktop for Mac

To download Docker Desktop for Mac, head to Docker Hub. Download from Docker Hub What to know before you install README FIRST for Docker Toolbox and Docker Machine users If...

docs.docker.com

설치 후 설치가 잘 되었는지 확인하기 위해 터미널에서 명령어 몇 개를 쳐보자.

$ docker version

내 컴퓨터에 설치된 도커 정보들이 쫘라락 뜰 것이다.

$ docker images

docker hub에서 다운받은 이미지들의 목록을 출력하는 명령어이다. 테스트용 hello-world라는 이름의 이미지가 설치되어있을 것이다.

Repository는 도커 이미지의 이름이고 TAG는 이미지 버전이다.

이렇게 설치 확인까지 했으면 예제를 통해 도커를 차근차근 알아가보자.

도커는 가상머신과 굉장히 유사하게 동작한다. 가상머신은 내 컴퓨터 안에 또 다른 가상의 컴퓨터이다. 가상 컴퓨터가 작동하기 위해선 OS도 설치해야겠징? 그렇기 때문에 굉장히 무겁다.

도커도 내 컴퓨터와 독립된 공간(컨테이너)에서 프로그램을 실행시키는 개념이지만 내 컴퓨터의 OS를 공유하기 때문에 훨씬 가볍고 빠르다.

솔직히 이렇게만 말해선 딱히 이해 안가고 어려울 수 있다. 나도 도커가 어렵고 추상적으로 느껴졌는데 명령어를 쳐가면서 이해하니 꽤 이해가 되었당! (도커 명령어도 외워지고 개이득 공부법)

내 컴퓨터는 맥인데 도커를 사용해 우분투의 패키지 매니저를 설치하고 사용해보자.

$ docker pull ubuntu:14.04

docker hub에서 우분투 14.04 버전의 패키지 시스템이 구성된 이미지를 받아온다. 여기서 주목해야할 점은 우분투 운영체제를 받아오는게 아니라 패키지 매니저를 다운 받는 것이다.

$docker search ubuntu

도커 허브에 전세계 개발자들이 각자의 입맛대로 구성한 우분투 이미지들을 볼 수 있다. 앞에 id가 없는 게 공식 이미지이다.

$docker run -i -t ubuntu:14.04 /bin/bash

run 명령어는 컨테이너 생성 동시에 컨테이너 상 프로그램을 실행한다. 파일을 실행 상태로 만들어 놔야 컨테이너도 동작한다. 지정한 메인 실행파일이 종료가 되면 컨테이너도 종료된다. 설치된 운영체제를 부팅하는 것과 비슷한 개념이라고 보자.

/bin/bash 로 실행할 메인 실행파일을 지정한다.

$docker ps

현재 실행 중인 컨테이너를 확인한다.

$docker ps -a

all 옵션을 줘서 종료된 컨테이너들까지 확인한다.

$docker start jello

start 명령어는 jello 컨테이너의 메일 실행 파일을 실행만 할 뿐 컨테이너로 들어가지 않는다.

jello는 도커가 자동으로 설정해준 컨테이너 이름이다.

$docker attach jello

jello 컨테이너로 들어간다.

컨테이너로 들어갔다가 exit 명령어로 bash창을 나오면 컨테이너를 빠져나오면 컨테이너는 죽는다. ctrl+p+q 단축키로 컨테이너가 살아있는 채로 컨테이너를 빠져나올 수 있다.

$docker stop jello

컨테이너 프로세스 종료하기

$docker rm jello

컨테이너 삭제

$docker rmi hello-world

이미지 삭제

Reference

https://www.youtube.com/watch?v=Bhzz9E3xuXY

Mac OS 기본적인 터미널 명령어

GOD03219 — Fri, 12 Jul 2019 11:08:25 +0900

$ pwd

print working directory 현재 디렉토리 경로를 출력한다.

$ cd 경로명

change directory 경로를 변경한다.

ex)

cd / : 루트 디렉토리롤 이동한다.

cd ~: 사용자의 홈 디렉토리로 이동한다.

cd ~/desktop : 사용자의 바탕화면 디렉토리로 이동한다.

$ ls 옵션명 경로명

list segment 현재 디렉토리 안에 있는 파일들의 목록을 보여준다.

ex)

ls : 현재 경로의 파일과 폴더를 나열한다.

ls -l : 사용권한,소유자,크기,날짜 등 자세한 정보도 보여준다.

$ cp 원본파일 대상파일

copy 원본 복사하기, cp와 mv 명령어는 기본적으로 파일을 다룬다. 디렉토리를 처리할 때는 -r 옵션을 붙힌다.

ex)

cp test1 /test2 : "test1"파일을 "/test2"에 복사합니다.

$ mv 원본파일 대상파일

move 원본파일을 대상파일로 이동한다.

원본 이동하기 ex) mv -r test1 /test2 : "test1"디렉토리의 하위파일을 /test2"로 이동한다.

$ mkdir

make directory 폴더 생성하기

ex) mkdir golang : "golang" 폴더를 현재 경로에 생성한다. mkdir go1 go2 go3 : 3개의 폴더를 연속으로 생성한다.

$ touch index.html

index.html 파일을 만든다. ex) touch css/style.css

$ grep

파일 안 내용 찾기 ex) grep jello index.html : index.html에서 jello가 포함된 낱말을 찾는다.

$ ps

현재 실행중인 모든 프로세서를 표시한다.

$find

파일 검색하기 ex) find/root/ -name jello : 파일 이름이 jello를 포함한 파일을 /root 에서 검색한다.

$sudo

관리자 권한(root 권한)으로 명령어를 입력한다. ex) sudo vi /jello/index.txt : root권한으로 /jello/폴더의 index.txt 파일을 편집한다.

$ kill

프로세서를 강제 종료한다. ex) kill jello : jello 프로그램을 강제 종료한다.

$ whereis

ex) whereis jello : jello 프로세서 경로를 표시한다.

$ ~

자신의 홈 디렉토리를 나타낸다.

$ exit 또는 $ logout

터미널을 안전하게 종료한다.

$ rm

remove 원본을 삭제한다.

$ rmdir

remove directory 폴더를 삭제한다.

Transaction Process

GOD03219 — Thu, 11 Jul 2019 15:00:49 +0900

하이퍼레저에서의 트랜잭션 처리 과정

읽기

Jello가 가 패브릭 네트워크 상 피어A에 연결되어 있다고 가정.

1. Jello가 트랜잭션 요청

2.DApp은 피어A가 호스팅하는 분산 원장에 접근하기 위해 Jello의 인증서를 이용해 인증을 거친 후, 피어A와 연결

3.DApp은 피어A에 설치된 체인코드의 Query함수를 호출

4.피어A는 요청받은 체인코드의 함수를 실행하여 자신의 로컬저장소에 저장되어 있는 분산 원장의 데이터를 DApp에 전달

* 데이터 읽기 과정에서는 DApp으로부터 Query함수 실행을 요청받은 피어A 외 다른 피어들은 쿼리함수 실행을 위한 어떠한 동작도 하지않음

기록

분산원장에 데이터를 기록하는 작업은 크게 3단계로 구분되며 각 단계는 독립적으로 실행되기 때문에 동시성을 보장한다.

*읽기 과정의 3단계까지는 같다.(쿼리 함수 대신 update 함수이다.)

4. 피어A는 요청받은 체인코드의 update함수를 실행

5. 피어A는 트랜잭션 입력값에 대한 결과값과 보증정책을 확인하는 작업을 수행 후 ( 피어A는 Endorsing peer이군! ), 결과값과 보증 조건을 충족시키면 디지털 인증서와 결과값을 DApp에게 전달 (*보증 정책에 따라 하나 혹은 여러 대의 피어에게 허가를 받아야 하는 등 경우가 있다.) [ 1단계: 트랙잭션 제출 ]

6. DApp은 트랜잭션 결과값, 피어A의 디지털 인증서, 트랜잭션을 orderer노드로 전송

7. 이렇게 orderer노드는 (자신이 속한 채널 내의 )다른 DApp에서도 전송한 모든 트랜잭션을 순서에 맞게 정렬하여 블록체인의 최신 블록을 생성 [ 2단계: 블록 패키징 ]

8. 생성한 블록을 자신이 속한 네트워크의 모든 피어에게 전달한다.(*orderer는 트랜잭션 검증을 하지 않는다.)

9. 피어들은 orderer노드로부터 전달받은 최신 블록에 포함된 모든 트랜잭션에 대한 결과값과 인증서를 검증한다.( Committing peer이군! ) 문제 없을 시 자신의 로컬 저장소의 분산 원장을 업데이트한다. [ 3단계: 검증 ]

10. 피어A는 분산원장 업데이트 결과를 DApp에게 알려준다.

Hyperledger fabric 주요 개념

GOD03219 — Wed, 10 Jul 2019 17:59:54 +0900

Ledger

블록체인에서 장부는 매우 중요한 개념으로 거래 내역이 저장된 데이터 베이스이다.

패브릭 네트워크에서 한 채널이 하나의 장부를 가진다. 하나의 채널에 속한 피어들은 자신이 속한 채널의 장부 복사본을 가진다.

원장은 현재상태를 나타내는 World state, 원장의 생성 시점부터 현재까지의 사용기록을 저장하는 Blockchain 두 가지로 구분된다. World state는 데이터베이스 형태로 Blockchain과 분리되어 있다.

Blockchain

합의에 의해 결정된 블록들은 절대 수정할 수 없다. ( 잘못된 데이터가 발견되었을 경우에도 수정이 불가 ->결과 값을 맞추기 위해 world state 값을 조작해야 한다. )

append-only 방식의 저장이 목적이기 때문에 파일시스템 형태로 저장되어있다.

World state

World state에 저장된 데이터는 합의 과정을 통과하여 블록체인에 append되기 전의 데이터이다. 그렇기 때문에 체인코드를 통한 조회, 변경,삭제가 빈번히 발생하여 데이터 베이스 형태로 구축되어있다.

Peer

피어는 장부를 물리적으로 호스팅하고 장부를 업데이트하는 Chaincode 를 저장하고 있는 entity이다. (분산원장과 체인코드는 물리적으로 피어에 저장되고 설치된다.)

공식문서에는 하나의 피어에서 최소 한 개 이상의 분산원장과 체인코드 호스팅을 권장한다.

각 피어는 CA로부터 id를 배정 받고 채널에 참여할 수 있다.

Chaincode (Smart contract)

체인코드는 장부를 업데이트하는 비즈니스 로직이다.( 이더리움에서는 smart contract라고 불린다. )

패브릭은 체인코드 언어로 Go와 node.js를 지원한다.

주로 비즈니스 모델에 맞는 분산 애플리케이션(DApp;Decentralized Application)과 함께 개발되어 사용된다.

jello피어가 체인코드를 설치했다고 가정하자.

jello피어가 호스팅하는 채널에 연결된 다른 피어들에는 어떤 체인코드가 설치됬는지 알 수 없기 때문에 jello 피어의 체인코드를 바로 실행할 수는 없다.

jello 가 구현한 체인코드를 사용하기 위해선 구현 로직이 아니라 jello 피어의 체인코드 인터페이스를 다른 피어들에게 알리는 인스턴스화(instantiated)가 필요하다. jello피어는 체인코드를 채널에 인스턴스화한다. 그리고 피어들은 채널에 인스턴스화가 된 체인코드를 설치한다.

이렇게 채널에 연결된 피어들에 jello가 구현한 체인코드가 설치되고 인스턴스화가 이루어지면 네트워크 외부의 클라이언트 어플리케이션에 의해서 체인코드가 호출(invoke)되어 결과값을 전송 받을 수있다.

smart contract을 모든 노드가 실행하는 퍼블릭 블록체인과 달리,

패브릭에서는 트랜잭션 요청을 받은 Endorsing peer만 체인코드를 실행하고 결과 값을 네트워크에 전파한다.

그러므로 병렬적으로 트랜잭션을 처리할 수 있다는 장점을 갖는다.

일부 노드만 체인코드를 실행한 결과 값을 신뢰할 수 있어? 의심하는 분!

패브릭의 Endorsement policy은 Endorsing peer가 네트워크에 전달한 트랜잭션 결과 값을 채널 내 Committing peer가 검증한다.

(보증 정책에는 어떤 체인코드가 장부를 업데이트하기 위해서 몇 개의 서명이 필요한지 명시되어 있다.)

DApp(Decentralized Application)

분산 애플리케이션은 사용자가 분산원장에 접근하는 방식을 정의하는 프로그램이다.

패브릭은 분산 애플리케이션 개발을 위해 다양한 종류의 SDK(Software Development Kit)를 제공한다.

각 조직의 비즈니스 모델에 맞게 개발이 가능하다.

Gossip

채널을 공유하는 피어들은 Gossip protocol을 통해 서로에게 자신이 살아있음을 알리는 heartbeat 메세지를 브로드캐스트 한다.

채널에 소속된 피어들 중 특정 피어로부터 일정 시간동안 메세지가 수신되지 않으면 해당 피어는 오프라인 상태로 인식된다.

채널 내 피어들은 Gossip protocol을 통해 분산 원장을 전송하고 비교 업데이트를 한다.

CA (Certificate Authority)

디지털 인증서를 관리하는 기관으로 사용자의 디지털 인증서를 발급,저장,삭제해주는 역할을 한다.( MSP를 발급한다. )

*PKI(public key infrastructure) 기반의 디지털 인증서

패브릭에서는 Fabric-CA 노드가 CA역할을 한다.

MSP(Membership Service Provider)

하이버레저 패브릭 멤버쉽 관리 기술로 peer, orderer, Fabric-CA, Admin 등의 역할과 소속,권한 등을 정의한다.

local MSP

패브릭 네트워크 노드들의 역할을 부여할 때 사용한다.

peer, orderer, client 노드를 정의하고 노드 별 권한도 정의할 수 있다. 패브릭 네트워크의 모든 노드들은 모두 하나 이상의 local MSP가 정의되어야 한다.

channel MSP

채널 구성원들에 대한 멤버십 정의 및 권한 부여

채널을 이루는 구성원들은 각자의 local MSP를 이용해 하나의 channel MSP를 생성한다.

Orderer

DApp에게 전달받은 트랜잭션들을 정렬한 후 블록을 생성한다.( ordering service 수행 )

그리고 Committing peer에게 블록을 전파하는 역할을 한다. Orderer는 블록을 검증하는 역할을 하진 않는다.

오더링 서비스는 카프카(Kafka) 분산 메세징 시스템을 이용해 구현되었다.

Reference

https://medium.com/decipher-media

하이퍼레저 패브릭 네트워크 구조 [Hyperledger Fabric Network Structure]

Writer : Jung Sungdong

medium.com

하이퍼레저 패브릭으로 배우는 블록체인, 윤대근

Hyperledger fabric 구조

GOD03219 — Wed, 10 Jul 2019 17:04:02 +0900

하이퍼레저 패브릭은 비트코인과 이더리움과는 다르게 Private, Permissioned 한 블록체인 플랫폼이다.

패브릭의 가장 큰 특징은 허가 받은 주체만 네트워크에 참여할 수 있다는 점이다. 이러한 특징 때문에 기업형 블록체인 개발을 위해 사용된다. 또한 퍼블릭 블록체인에 비해 매우 복잡한 구조를 띄는데 이는 패브릭이 추가 여러 가지 기능을 가지기 때문이다. (채널, 컨소시움, 멀티 장부 etc...)

이름마저 생소한 하이퍼레저! 구조를 파헤져 보면 더 생소할 것이다 :)

(다짜고짜) group A가 패브릭 네트워크를 구성한다고 가정한다.

1. Ordering service 노드 구동

오더링 서비스는 전달받은 트랙잭션의 순서를 정해 블록을 생성하고 연결된 노드들에게 전달하는 기능이다. 한마디로 블록체인의 핵심 기능이다.

오더링 서비스 노드 즉, Orderer가 오더링 서비스를 호스팅하는 주체이다.

Consensus

대표적인 public blockchain (non-permissioned blockchain) 비트코인과 이더리움에서는 PoW,PoS 합의 프로토콜을 사용한다.

퍼블릭 블록체인의 각 노드들을 신원이 확인되지 않았기 때문에 PoW나 PoS 같은 작업 증명이나 지분 증명을 통해 블록 생성 시 합의을 해야한다.

패브릭은 그렇지 않다는 점에 주목하자.

하이퍼레저 패브릭에서는 트랜잭션의 생성부터 새로운 블록 생성까지 모든 과정을 통칭해서 합의 과정이라고 말한다.

최신 블록 생성 직전 트랜잭션을 정렬하는 방식을 사용자가 선택할 수 있는데, 패브릭은 기본적으로 SOLO(Single Ordering Service Node) 와 CFT(Crash Fault Tolerance) 기반 Kafka를 지원한다.

CFT란 일부 시스템 구성 요소들이 작동하지 않더라도 올바른 합의에 도달할 수 있는 성질이다. (다른 카프카 서버가 죽어도 괜찮아! 블록 생성을 위한 안정성 보장) 카프카 기반 오더링 서비스는 최소 4개의 노드를 가져야 CFT를 가진다. 패브릭 네트워크에 참여한 노드들은 이미 CA를 받은 허가된 주체이기 때문에 CFT가 가능할 수 있는 것이다.

패브릭을 사용하는 조직은 지원하는 합의 방식 외에도 합의 프로토콜을 직접 구현할 수도 있다. (교체 가능한 합의 프로토콜;Pluggable consensus)

2. Network Configuration 설정

관리자는 어떤 네트워크 조직이 어떤 권한을 가지는지를 Network Configuration에 저장한다.

3. Certificate Authority (CA) 설정

참여자의 ID와 권한을 관리할 주체, 디지털 증명서를 발급하는 기관이다.

패브릭에 참여하는 그룹들은 모두 개별 CA를 이용한다.

4. 컨소시엄(Consortium) 구성하기

consortium : 함께 협력하기로 동의한 사람 또는 회사의 집단

패브릭 네트워크에서 조직들이 하나의 컨소시엄을 구성하면 그 조직들은 트랜잭션 내역을 공유한다. 공동의 목표를 가지고 협력하는 두 개이상의 조직이 모인 셈

네트워크 설정에 어떤 그룹들이 어떤 컨소시엄을 이루는 지 정의된다.

5. 채널 만들기

채널은 컨소시엄 내 그룹 간 커뮤니케이션 메커니즘이다. 채널 안에서 데이터 분리 및 기밀화가 가능하며 채널 사용 허가를 받은 컨소시엄 멤버들은 채널용 장부에 접근이 가능하다.

체널에 접근할 수 있는 피어(peer)의 권한 정보와 같은 채널 운영에 필요한 정보는 channel configuration에 기록된다.

네트워크 설정과 채널 설정 사이에 중복되는 설정이 없다.

네트워크 상 프라이버시를 보장하며 효율적인 데이터 공유가 가능하다.

Token economics

GOD03219 — Wed, 10 Jul 2019 14:35:59 +0900

토큰 경제는 블록체인이 등장하면서 주목받고 있는 개념이다.

블록체인의 인센티브 개념은 모든 주체들이 자발적으로 네트워크를 구성하게 하는 동기가 된다. 여기서 인센티브가 바로 토큰(암호 화폐)이다.

사용자들이 블록체인 네트워크를 사용하도록 인센티브를 제공 -> 사용자 확보 -> 거래 신뢰 강화 -> 거래 활성화 -> 토큰 가치 상승

-> 더 많은 사용자 확보

이러한 방식으로 블록체인 네트워크가 활성화된다.

토큰 경제학의 기저에는 행동주의 심리학이 깔려있다. 특정행동으로 인해 어떠한 보상이 주어진다면 그 행동을 할 동기가 생기는 것이다.

토큰 경제학에서는 보상은 토큰이다.

하지만 여기에는 4가지 문제로 인해 행동 유발이 억제될 수 있다.

1. 토큰의 가치가 비합리적일 경우

2.토큰의 발행과 지불 등의 기록이 불투명할 경우

3.토큰의 교환가치 또는 비율에 일관성이 없을 경우 - 시스템이 공정하지 않을 경우

4.토큰 시스템의 미래가 불투명할 경우

요러한 문제점들이 발생하는 이유는 토큰을 발생하는 주체가 중앙 정부이기 때문이다.

블록체인이 등장하면서 토큰 경제가 주목받는 이유는 아래와 같다.

1.토큰의 가치가 시장의 수요와 공급에 의해 정해지기 때문에 토큰의 가치 및 비율이 합리적이다.

2.모든 거래내역이 원장에 공개된다.

3.특정인의 권위(중앙 주체)가 아닌 공개된 알고리즘으로 구동되는 시스템으로 공정하다.

Git flow strategy

GOD03219 — Wed, 5 Jun 2019 15:56:59 +0900

| GIT 이란?

프로젝트의 어떤 부분도 겹쳐쓰지 않게 프로젝트의 변경을 관리하는 버전 관리 소프트웨어이다.

회사에서 깃을 사용하지 않는다면? A님과 B님이 같은 웹사이트에서 게시판 페이지를 업데이트하고 있다고 가정해보자. A님이 무언가를 변경하고 저장한 다음 웹사이트에 업로드한다. A님 혼자 일을 한다면 문제가 없다. 문제는 B님과 함께 게시판 페이지의 이슈들을 처리해야 할 때이다. A님이 이슈a를 처리하고 사이트 업데이트 했다. 그리고 B님이 이슈b를 처리하고 사이트를 업데이트 했다. 결과적으로 이슈b는 처리되었지만 B님이 사이트를 업데이트 하기전 처리되었던 이슈a가 작업하기 전 상태로 돌아갔다. 같은 페이지에서 작업을 하기 때문에 누군가의 작업은 겹쳐쓰여지거나 지워질 것이다.

깃을 사용한다면? A님과 B님은 같은 페이지에 각자의 수정사항을 각각 업로드할 수 있고, 깃은 두 개의 복사본을 저장한다. 나중에, A님과 B님은 어떤 작업도 잃어버리지 않고 변경사항들을 병합할 수 있다. 깃은 이전에 만들어진 모든 변경사항의 스냅샷을 저장하기 때문에 이전 시점의 어떤 버전으로 되돌릴 수도 있다.

| Before getting into GIT!

버전관리(Version Control): 깃이 서비스되도록 고안된 목적. MS 워드 작업할 때, 변경 사항을 저장하면 이전 파일 위에 겹쳐쓰거나 여러 버전으로 나누어 저장한다. 깃을 사용하면 그럴 필요가 없다. 프로젝트 히스토리를 스냅샷으로 유지하므로 잃어버리거나 겹쳐쓰지 않을 수 있다.

저장소(Repository): 프로젝트가 거주(live)할 수 있는 디렉토리나 저장 공간. 깃허브 사용자는 종종 repo로 줄여서 사용한다. 당신의 컴퓨터 안의 로컬 폴더가 될 수도 있고, 깃허브나 다른 온라인 호스트의 저장 공간이 될 수도 있다.

커밋(Commit): 작업한 내용을 로컬 저장소에 저장, 소스 코드의 수정 내용은 커밋 단위로 관리 / 커밋 명령으로 깃은 저장소의 히스토리를 스냅샷으로 찍어, 프로젝트를 이전 시점으로 복원할 수 있는 체크포인트를 가질 수 있다.

브랜치(Branch): 작업자들은 메인 프로젝트(보통 마스터)의 브랜치를 따와서(branch off), 자신이 변경하고 싶은 자신만의 버전을 만든다. 작업을 끝낸 후, 프로젝트의 메인 디렉토리인 master에 작업했던 브랜치를 다시 merge한다.

| git flow model

git flow란 저장소를 보다 고수준으로 관리하기 위한 브랜칭 기법이다. Git이란 개념도 이미 충분이 복잡한데 굳이 더 프로젝트를 복잡하게 관리할 필요가 있나 싶을 수도 있지만, 프로젝트의 규모가 점점 커지고 많은 인원들이 코드에 동시에 접근하면서 필연적으로 문제가 발생하게 된다. 따라서 현재 내 브랜치가 어떤 문맥에서 생겨나게 됐는지 파악하기 위해 Git Flow에 대한 이해는 반드시 필요하다.

git flow model은 2개의 핵심 브랜치와 3개의 서브 브랜치 총 5개의 브랜치를 가진다.

2개의 핵심 브랜치는 항상 유지되어야한다. (추가적으로 생성되거나 삭제되지 않는다.)

1. master

Ø 모든 테스트 등이 끝나고 상용화가 가능한 최종 브랜치

Ø 실제 클라이언트들이 이용하는 서비스

2. develop

Ø 현재 개발이 진행 중인 브랜치

Ø 다음 버전 개발

Ø 마스터에서 분기

Ø 상시 버그를 수정한 커밋들이 추가됨

3. feature

Ø 새로운 기능 추가 브랜치

Ø develop 브랜치에서 파생되며 develop에 병합된다.

Ø Remote repo에는 업데이트 할 필요는 없고 보통 local에만 존재

Ø 브랜치의 이름은 master,develop,release,hotfix 를 제외한 어떠한 이름이든 가능

Ø 가장 많이 삭제되고 생성되는 브랜치

4. release

Ø 이번 버전 출시 전 QA를 위한 브랜치

Ø 지금까지 작업한 내역을 develop 브랜치에서 따와 배포하기 전 테스트하며 발견되는 버그들을 수정

Ø 배포 준비가 완료되었다면 master 브랜치와 develop에 병합

5. Hotfix

Ø 갑자기 오류가 나서 디버그해야하는 경우와 같이 긴급하게 코드를 수정해야 하는 경우의 사용하는 branch

Ø master 브랜치에서 파생

Ø 수정된 버그들을 반영하기 위해 develop와 master 두 개의 브랜치에 병합된다.

Ø release 브랜치가 존재한다면 거기에도 반영되어야 한다.

Padding

GOD03219 — Mon, 6 May 2019 17:18:03 +0900

padding은 요소의 테두리 안과 content 사이의 간격이다.

padding을 사용하여 스타일을 적용할 때 가장 유의해야할 점을 알아보자.

width를 주의해라!

div 태그의 width 값을 100px로 주고, padding 값을 10px로 주었다. 실제 width 값은 의도치 않게 120px이 되버린다. (padding-right, padding-left 값이 width값에 적용된다.)

이 때 padding값에 상관 없이 div 태그의 width를 100px로 주고 싶다면 box-sizing 속성을 이용하면 좋다.

box-sizing : border-box 값을 주면 요소의 너비는 패딩 값에 영향을 받지 않는다.

여기서 참고로 알아두면 유용한 CSS box model

Total element width = width + left padding + right padding + left border + right border + left margin + right margin

Total element height = height + top padding + bottom padding + top border + bottom border + top margin + bottom margin

Margins

GOD03219 — Mon, 6 May 2019 17:08:06 +0900

css 를 적용할때 쉬워보이면서도 은근 헷갈이는 요놈! 마진! 패딩이랑 헷갈려~ 정확하게 짚고 넘어가자.

margin은 요소를 둘러싸고 있는 공간이다! 패딩이랑 헷갈린다면, 마진을 border(요소의 테두리) 밖의 공간이라고 생각하면 좋다. 패딩은 테두리 안의 공간이다.

margin-top, margin-right, margin-bottom, margin-left 를 값을 margin 속성으로 한 번에 줄 수 있는데 순서에 유의하자.

margin 속성이 값을 4개를 가진다면?

margin : 1px 2px 3px 4px (top / right / bottom / left 순)

margin 속성이 값을 3개만 가진다면?

margin : 1px 2px 3px (top / right and left / bottom 순)

margin 속성이 값을 2개만 가진다면?

margin : 1px 2px (top and bottom / right and left 순)

margin 속성이 값을 1개만 가진다면?

margin : 1px (all four margin applied)

margin auto

어떤 요소의 margin 속성을 auto로 준다면 요소의 컨테이너 내 수평으로 중심으로 배치된다. 이는 남아있는 공간을 서로 균등하게 분배하기 때문이다.

margin collapse

A요소 바로 밑에 B요소가 있다고 하자. A 요소의 margin-bottom은 40px이고 B요소의 margin-top은 10px이다. 그럼 두 요소의 상하 간격은 50px이 될거라고 예측해보지만! 이런 경우 상하 마진은 덮어 씌워지는 특성이 있다. 그래서 A요소의 margin-bottom 40px로 덮어씌워진다.