📍 Git Hooks

Git Hooks는 Git과 관련한 어떤 이벤트가 발생했을 때 자동으로 특정 스크립트를 실행할 수 있도록 하는 기능이다. 이는 클라이언트 훅 과 서버 훅 으로 나뉘는데, 클라이언트 훅은 커밋이나 Merge할 때 클라이언트에서 실행하는 훅이다. 반면 서버 훅 은 Git repository로 push할 때 서버에서 실행하는 훅이다.

Git hooks의 종류

• applypatch-msg
• commit-msg
• fsmonitor-watchman
• post-update
• pre-applypatch
• pre-commit
• pre-merge-commit
• pre-push
• pre-rebase
• pre-receive
• prepare-commit-msg
• push-to-checkout
• update

📍 Pre-commit

Git hook에서 지원하는 기능 중 pre-commit hook을 관리하고 유지하기 위한 프레임워크로, lint같은 프로그램을 통해 코드 스타일 검사, 라인 끝 공백 문자 검사, 새로 추가한 코드의 주석 검사 등 commit할 때 꼭 확인해야 할 것이 있으면 pre-commit hook을 통해 확인하면 된다.

특징

• commit할 때 가장 먼저 호출되는 hook
• commit message를 작성하기 전에 호출
• commit하는 snapshot 검사
• 빠뜨린 것은 없는지, 테스트 유무 점검
• exit가 0이 아니면 commit 취소
• git commit --no-verify를 통해 hook 일시적으로 생략 가능
  
  

설치 방법

pip 이용 시
pip install pre-commit

homebrew 이용 시
brew install pre-commit

conda 이용 시
conda install -c conda-forge pre-commit

📍 Github Action

GitHub Action은 빌드, 테스트 및 배포 등을 자동화할 수 있는 CI/CD 플랫폼으로, workflow를 자동화할 수 있도록 도와주는 도구이다.

• CI/CD
  통상적으로 작업한 소스 코드를 빌드하고, 저장소에 전달 후 배포까지 하는 과정을 뜻한다.
  
  

구성 요소

• Workflow
  하나 이상의 Job으로 구성되고, 이벤트에 의해 트리거될 때 실행되거나 수동으로 또는 정의된 일정에 따라 트리거될 수 있는 자동화된 절차를 말한다. workflow는 Github repository의 .github/workflows 폴더 아래에 YAML 파일로 저장된다. Github에 YAML 파일로 정의한 자동화 동작을 전달하면, Github Action은 해당 파일을 기반으로 그대로 실행시킨다.

• Event
  workflow를 실행을 트리거하는 특정 활동이나 규칙이다. 예를 들어, 누군가가 commit을 repository에 push하거나 pull 요청이 생성 될 때 GitHub에서 활동이 시작될 수 있다.

• Job
  Job은 여러 Step으로 구성되고, 단일 가상 환경에서 실행된다. 다른 Job에 의존 관계를 가질 수도 있고, 독립적으로 병렬로 실행될 수도 있다. 예를 들어 종속성이 없는 서로 다른 아키텍처에 대한 여러 빌드 작업과 이러한 작업에 종속된 패키징 작업이 있을 수 있다. 빌드 작업은 병렬로 실행되며 모두 성공적으로 완료되면 패키징 작업이 실행된다.

• Step
  Job 안에서 순차적으로 실행되는 프로세스 단위로, step에서 명령을 내리거나 action을 실행할 수 있다.

• Action
  job을 구성하기 위한 step들의 조합으로 구성된 독립적인 명령으로 workflow의 가장 작은 빌드 단위이다. workflow에서 action을 사용하기 위해서는 action이 step을 포함해야 한다. 직접 만들어 사용할 수도 있고 마켓에 등록된 이미 만들어진 것을 가져와 사용할 수도 있다.

• Runner
  트리거될 때 workflow를 실행하는 서버로, 한 번에 하나의 작업을 실행할 수 있다.
  
  

Workflow 생성 예시

1. repository에서 workflow 파일을 저장할 .github/workflows/ 폴더를 만든다.
   
   
2. .github/workflows/ 폴더에서 learn-github-actions.yml라는 새 파일을 만들고 다음 코드를 작성한다.

   name: learn-github-actions
   run-name: ${{ github.actor }} is learning GitHub Actions
   on: [push]
   jobs:
     check-bats-version:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v3
         - uses: actions/setup-node@v3
           with:
             node-version: '14'
         - run: npm install -g bats
         - run: bats -v

   
   
3. 이러한 변경 사항을 commit하고 Github repository에 push한다.
   
   이제 새 Github Actions workflow 파일이 repository에 설치되고 누군가 repository에 변경 사항을 push할 때마다 자동으로 실행된다.

Workflow 파일 이해

name: learn-github-actions

(선택 사항) Github repository의 "Action" 탭에 표시되는 workflow의 이름이다.

run-name: ${{ github.actor }} is learning GitHub Actions

(선택 사항) workflow에서 생성된 workflow의 실행 이름으로, 저장소의 "Action" 탭에 있는 workflow 실행 목록에 표시된다.

on: [push]

workflow 파일을 자동으로 트리거하는 이벤트를 지정한다. 이 예제에서는 push 이벤트를 사용하므로 누군가 저장소에 변경 사항을 push하거나 pull 요청을 할 때마다 workflow 실행이 트리거된다.

jobs:

learn-github-actions workflow에서 실행되는 모든 job을 함께 그룹화한다.

job에 대한 설정

• runs-on: 해당 job을 어떤 OS에서 실행할 것인지 명시한다.
• steps: job이 가질 수 있는 동작을 나열한다. 각각의 step은 독립적인 프로세스를 가진다.
• uses: 해당 step에서 사용할 action으로, Github 마켓플레이스에 올라온 action들을 사용할 수도 있다. 기본적으로 {owner}/{repo}@{ref|version}의 형태를 지닌다.
• name: step의 이름이다.
• run: job에 할당된 컴퓨팅 자원의 shell을 이용하여 커맨드 라인을 실행한다. node.js 프로젝트의 경우, 이 과정에 npm package의 scripts를 구동할 수 있다.
• env: 해당 job에서 사용할 환경 변수를 key/value의 형태로 설정한다.
• strategy: 여러 환경에서의 테스트/배포를 위해서 빌드 matrix를 구성한다. 위 코드처럼 사용하면 다양한 node 버전에서 같은 job을 실행할 수도 있다.
• with: 해당 action에 의해 정의되는 input 파라미터로, key/value 페어로 되어 있다. input 파라미터는 환경 변수로 설정되고, 'INPUT_'이라는 prefix가 붙는다.
  
  

📍 Pytest

단위 테스트(Unit Test)부터 인수 테스트(Acceptance Test)까지 테스트 할 수 있는 all-in-one Python Test Framework이다.

기능

• parametrization을 통한 여러 테스트 케이스 관리
• exception에 대한 테스트
• fixture를 사용한 object 제공으로 dependency 해결 및 간단한 코드 작성
• mark를 통한 테스트 함수 관리
  
  

설치 방법

명령 프롬프트(cmd)에서 pytest 설치
pip install -U pytest

버전 확인
pytest --version

테스트 코드

함수와 테스트를 포함하는 간단한 test_sample.py파일을 작성한다. pytest를 사용할 때, 테스트 함수는 꼭 앞에 test_ 로 시작하거나 뒤에 _test 로 끝나야 한다.

# content of test_sample.py
def func(x):
    return x + 1

def test_answer():
    assert func(3) == 5

그런 다음 pytest test_sample.py 명령어를 실행하면 이러한 창이 뜬다.

$ pytest test_sample.py
================================ test session starts =================================
platform win32 -- Python 3.10.3, pytest-7.2.2, pluggy-1.0.0
rootdir: C:\Users\lsymi\OneDrive\바탕 화면
collected 1 item

test_sample.py F                                                                [100%]

====================================== FAILURES ======================================
____________________________________ test_answer _____________________________________

    def test_answer():
>       assert func(3) == 5
E       assert 4 == 5
E        +  where 4 = func(3)

test_sample.py:7: AssertionError
============================== short test summary info ===============================
FAILED test_sample.py::test_answer - assert 4 == 5
================================= 1 failed in 0.05s ==================================

[100%]는 해당 코드의 모든 테스트 함수를 실행했다는 뜻이다. 완료된 후 이 코드에선 func(3)가 5를 반환하지 않기 때문에 실패 보고서를 표시한다.


함수를 올바르게 func(3) == 4로 고친 후 실행하면 다음과 같은 창이 뜬다.

$ pytest test_sample.py
================================ test session starts =================================
platform win32 -- Python 3.10.3, pytest-7.2.2, pluggy-1.0.0
rootdir: C:\Users\lsymi\OneDrive\바탕 화면
collected 1 item

test_sample.py .                                                                [100%]

================================= 1 passed in 0.01s ==================================

결과를 보면 test_sample.py 라는 함수 뒤에 “.” 점 하나가 나오는데, 이는 테스트 코드에서 테스트 하나를 발견했고 그게 통과(“.”) 했다는 뜻이다.

parametrize

parametrize는 여러 테스트 케이스를 한번에 작성하는 기능을 제공한다.
- 테스트 코드 삽입 예정 -

---

import pytest

@pytest.mark.parametrize(
    "num,expected",
    [
        (1, 2),
        (2, 3),
        (10, 15),
    ],
)

def func(x):
    return x + 1

def test_answer(num, expected):
    assert expected == func(num)

내 이론상 이 코드를 입력하면 돌아갈 줄 알았으나 에러 발생,,,

================================ test session starts =================================
platform win32 -- Python 3.10.3, pytest-7.2.2, pluggy-1.0.0
rootdir: C:\Users\lsymi\OneDrive\바탕 화면
collected 1 item

test_sample.py E                                                                [100%]

======================================= ERRORS =======================================
___________________________ ERROR at setup of test_answer ____________________________
file C:\Users\lsymi\OneDrive\바탕 화면\test_sample.py, line 16
  def test_answer(num, expected):
E       fixture 'num' not found
>       available fixtures: cache, capfd, capfdbinary, caplog, capsys, capsysbinary, doctest_namespace, monkeypatch, pytestconfig, record_property, record_testsuite_property, record_xml_attribute, recwarn, tmp_path, tmp_path_factory, tmpdir, tmpdir_factory
>       use 'pytest --fixtures [testpath]' for help on them.

C:\Users\lsymi\OneDrive\바탕 화면\test_sample.py:16
============================== short test summary info ===============================
ERROR test_sample.py::test_answer
================================== 1 error in 0.02s ==================================

조금 더 알아본 후 밑의 코드까지 같이 추가할 예정

exception

pytest.raises를 사용하면 원하는 함수의 exception을 실제로 확인해볼 수 있다.
- 테스트 코드 삽입 예정 -

fixture

여러 테스트 함수에서 반복적으로 쓰이는 데이터를 관리하는 기능을 제공한다.
- 테스트 코드 삽입 예정 -

mark

테스트 함수에 표시를 남겨 테스트할 함수를 지정하는 기능을 제공한다.
- 테스트 코드 삽입 예정 -

---

📍 Docker

Docker는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 컨테이너 기반의 오픈소스 가상화 플랫폼이다.

일반적으로 컨테이너라 하면 배에 실는 네모난 화물 수송용 박스를 떠올릴 것이다. 각각의 컨테이너 안에는 다양한 화물을 넣을 수 있고 규격화되어 컨테이너선이나 트레일러 등 다양한 운송수단으로 쉽게 옮길 수 있다.

서버에서 이야기하는 컨테이너도 이와 비슷한데, 다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐 등 어떤 프로그램도 컨테이너로 추상화할 수 있고 조립PC, AWS, Azure, Google cloud 등 어디에서든 실행할 수 있다.

Container

컨테이너는 격리된 공간에서 프로세스가 동작하는 기술이다. 가상화 기술 중 하나지만 기존 방식과는 차이가 있다.

기존의 가상화 방식은 주로 OS를 가상화하였다. 우리에게 익숙한 VMware나 VirtualBox같은 가상머신은 호스트 OS위에 게스트 OS 전체를 가상화하여 사용하는 방식이다. 이 방식은 리눅스에서 윈도우를 돌리는 등 여러가지 OS를 가상화할 수 있고 비교적 사용법이 간단하지만 무겁고 느려서 운영환경에서는 사용할 수 없었다.

이러한 상황을 개선하기 위해 CPU의 가상화 기술(HVM)을 이용한 KVMKernel-based Virtual Machine과 반가상화 Paravirtualization방식의 Xen이 등장한다. 이러한 방식은 게스트 OS가 필요하긴 하지만 전체OS를 가상화하는 방식이 아니였기 때문에 호스트형 가상화 방식에 비해 성능이 향상되었다. 이러한 기술들은 OpenStack이나 AWS, Rackspace같은 클라우드 서비스에서 가상 컴퓨팅 기술의 기반이 되었다.

전가상화든 반가상화든 추가적인 OS를 설치하여 가상화하는 방법은 성능 문제가 있었고 이를 개선하기 위해 프로세스를 격리 하는 방식이 등장한다.

리눅스에서는 이 방식을 리눅스 컨테이너라고 하고 단순히 프로세스를 격리시키기 때문에 가볍고 빠르게 동작한다. CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하고 성능적으로도 거의 손실이 없다.

• 도커의 기본 네트워크 모드는 Bridge모드로 약간의 성능 손실이 있다. 따라서 네트워크 성능이 중요한 프로그램의 경우 --net=host 옵션을 고려해야 한다.

하나의 서버에 여러 개의 컨테이너를 실행하면 서로 영향을 미치지 않고 독립적으로 실행되어 마치 가벼운 VMVirtual Machine을 사용하는 느낌을 준다. 실행중인 컨테이너에 접속하여 명령어를 입력할 수 있고 apt-get이나 yum으로 패키지를 설치할 수 있으며 사용자도 추가하고 여러개의 프로세스를 백그라운드로 실행할 수도 있다. 또한 CPU나 메모리 사용량을 제한할 수 있고 호스트의 특정 포트와 연결하거나 호스트의 특정 디렉토리를 내부 디렉토리인 것처럼 사용할 수도 있다.

Image

이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것으로 상태값을 가지지 않고 변하지 않는다. 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장된다. 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 컨테이너가 삭제되더라도 이미지는 변하지 않고 그대로 남아있다.

• Ubuntu image: ubuntu를 실행하기 위한 모든 파일을 가짐.
• MySQL image: debian을 기반으로 MySQL을 실행하는 데 필요한 파일과 실행 명령어, 포트 정보 등을 가짐.
• Gitlab image: centos를 기반으로 ruby, go, database, redis, gitlab source, nginx 등을 가짐.

이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 더이상 의존성 파일을 컴파일하고 다른 것들을 설치할 필요가 없다. 새로운 서버가 추가되면 미리 만들어 놓은 이미지를 다운받고 컨테이너만 생성하면 된다.

Layer

도커 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 보통 용량이 몇 백 MB에 이른다. 처음 이미지를 다운받을 땐 크게 부담이 안되지만 기존 이미지에 파일 하나 추가했다고 몇 백 MB를 다시 다운받는다면 매우 비효율적일 수 밖에 없다.

도커는 이런 문제를 해결하기 위해 layer라는 개념을 사용하고 유니온 파일 시스템을 이용하여 여러 개의 layer를 하나의 파일시스템으로 사용할 수 있게 해준다. 이미지는 여러 개의 읽기 전용 layer로 구성되고 파일이 추가되거나 수정되면 새로운 layer가 생성된다. 예를 들어 ubuntu 이미지가 A+B+C의 집합이라면, ubuntu 이미지를 베이스로 만든 nginx 이미지는 A+B+C+nginx가 된다. webapp 이미지를 nginx 이미지 기반으로 만들었다면 A+B+C+nginx+source layer로 구성된다. webapp 소스를 수정하면 A, B, C, nginx layer를 제외한 새로운 source(v2) layer만 다운받으면 되기 때문에 굉장히 효율적으로 이미지를 관리할 수 있다.

컨테이너를 생성할 때도 layer 방식을 사용하는데 기존의 이미지 layer 위에 읽기/쓰기 layer를 추가한다. 이미지 layer를 그대로 사용하면서 컨테이너가 실행중에 생성하는 파일이나 변경된 내용은 읽기/쓰기 layer에 저장되므로 여러개의 컨테이너를 생성해도 최소한의 용량만 사용한다.

이미지 경로

이미지는 url 방식으로 관리하며 태그를 붙일 수 있다. ubuntu 14.04 이미지는 docker.io/library/ubuntu:14.04 또는 docker.io/library/ubuntu:trusty이고 docker.io/library는 생략가능하여 ubuntu:14.04로 사용할 수 있다. 이러한 방식은 이해하기 쉽고 편리하게 사용할 수 있으며 태그 기능을 잘 이용하면 테스트나 롤백도 쉽게 할 수 있다.

Dockerfile

도커는 이미지를 만들기 위해 Dockerfile이라는 파일에 자체 DSL 언어를 이용하여 이미지 생성 과정을 적는다. 만약 서버에 어떤 프로그램을 설치하려고 다양한 의존성 패키지를 설치하고 설정파일을 만들었던 경험이 있다면, 더 이상 그 과정을 블로깅하거나 메모장에 적지 않고 Dockerfile로 관리할 수 있다. 이 파일은 소스와 함께 버전 관리되며 원한다면 누구나 이미지 생성과정을 보고 수정할 수 있다.

Docker Hub

도커 이미지의 용량은 보통 몇 백 MB로 GB가 넘는 경우도 흔하다. 이렇게 큰 용량의 이미지를 서버에 저장하고 관리하는 것은 쉽지 않은데 도커는 Docker hub를 통해 공개 이미지를 무료로 관리해준다.