Skip to main content

Command Palette

Search for a command to run...

아주 간단한 깃헙 액션

Updated
3 min read

자동 배포하기

깃허브 액션 워크플로우를 통해 자동으로 도커 이미지를 빌드하고 컨테이너를 실행하는 형태의 자동 배포도 가능하다.

name: Deploy to Remote Server

on:
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Setup SSH Key
        run: |
          echo "${{ secrets.SSH_KEY }}" | base64 -d > key.pem
          chmod 600 key.pem

      - name: Pull and Restart on Server
        run: |
          ssh -i key.pem -p ${{ secrets.SSH_PORT }} -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            cd ${{ secrets.REMOTE_DIR }}
            echo "[INFO] Pulling latest changes..."
            git pull origin main
            echo "[INFO] Stopping old container..."
            docker stop discord-bot-toko || true
            docker rm discord-bot-toko || true
            echo "[INFO] Rebuilding image..."
            docker build -t discord-bot-toko .
            echo "[INFO] Starting container..."
            docker run -d --name discord-bot-toko --env-file .env --rm discord-bot-toko
          EOF

위 코드의 경우 실제로는 배포상 문제가 있었으나, 위와 같은 식으로 push가 있는 경우 도커 이미지를 빌드하고 도커 컨테이너를 재실행하는 디자인으로 작성되었다.

테스트 만들기

러스트에서도 테스트들을 만들 수 있다.

name: Audit

on:
  schedule:
    - cron: "0 0 * * 0" # Every Sunday at midnight
  workflow_dispatch: # Manual trigger

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Toolchain installation
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      # cargo-audit
      - name: Install cargo-audit
        run: cargo install --locked cargo-audit

      # check known vulnerabilities
      - name: Run cargo-audit
        working-directory: vulncat
        run: cargo audit

위와 같은 식으로 알려진 취약점에 대한 테스트도 작성할 수 있다. 위의 경우 일요일 자정 또는 수동 트리거에 의해 작동시킬 수 있다.

배포

release를 이용해 자동으로 태그를 달고 배포하는 용도로도 사용 가능하다.

name: Release

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  release:
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: vulncat/model

    steps:
      - uses: actions/checkout@v4
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      - name: Run full build & tests
        run: |
          cargo build --release
          cargo test

      - name: Create GitHub Release
        uses: actions/create-release@v1
        id: create
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Upload trained model
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create.outputs.upload_url }}
          asset_path: models/autoencoder.bin
          asset_name: autoencoder.bin
          asset_content_type: application/octet-stream

린터 적용

파이썬 프로젝트의 경우 github action 웹에서 간단하게 pylint를 적용할 수 있다. 다만 기본 설정을 그대로 적용할 경우 파이린트 점수가 10점 이상이여야 테스트 성공이 나오나, 만약 머지를 막아놓은 경우 파이린트 10점이 꽤 강한 제한으로 느껴질 수 있다.

이러한 경우에

name: Pylint

on: [push]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.13"]
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint
    - name: Analysing the code with pylint
      run: |
        pylint $(git ls-files '*.py') --fail-under=7.5

아래 이렇게 점수를 설정해줘서 테스트의 강도를 조절할 수 있는데

pylint $(git ls-files '*.py') --fail-under=7.5인 경우 7.5 이상에서 테스트가 통과하게 된다.

10 views

More from this blog

락프리 데이터 구조와 알고리즘

여기서는 락프리 데이터 구조를 설명한다. 락프리(lock-free) 란 배타락을 이용하지 않고 처리를 수행하는 데이터 구조 및 그에 대한 조작 알고리즘을 총칭한다. 왜 락프리인가? 전통적인 동시성 제어 방법인 뮤텍스나 세마포어는 여러 문제점을 가지고 있다: 성능 저하: 락 경합(lock contention)으로 인한 대기 시간 데드락: 여러 스레드가 서로의 락을 기다리는 상황 우선순위 역전: 낮은 우선순위 스레드가 높은 우선순위 스레드를 ...

Jul 27, 20257 min read126

소프트웨어 트랜잭셔널 메모리

소프트웨어 트랜잭셔널 메모리 동시성 프로그래밍에서 공유 자원에 대한 안전한 접근은 항상 중요한 과제다. 전통적으로 뮤텍스 락과 같은 비관적 락(Negative Lock) 방식을 사용해왔다. 이 방식은 크리티컬 섹션에 진입하기 전에 반드시 락을 획득해야 하며, 락을 얻지 못하면 코드 실행 자체가 블록된다. 하지만 이와는 다른 접근 방식이 있다. 바로 낙관적 락(Optimistic Lock) 방식인데, 이는 "일단 실행하고 나중에 검증하자"는 철학...

Jul 20, 202517 min read263

공평한 배타 제어

공평한 배타 제어 여기서는 공평한 배타 제어에 대해 설명한다. 먼저 컨텐션(contention) 이라는 개념을 이해할 필요가 있다. 컨텐션이란 여러 스레드가 동시에 같은 락을 획득하려고 경쟁하는 상황을 말한다. 컨텐션이 높을수록 스레드들이 락을 기다리는 시간이 길어지고 성능이 저하된다. 이러한 컨텐션 상황은 시스템 아키텍처에 따라 더욱 복잡해질 수 있다. 특히 비균일 메모리 접근(Non-Uniform Memory Access, NUMA) 와 같...

Jul 13, 20259 min read21

KernelSnitch[논문 리뷰]

Paper 1. Intro 이 글은 NDSS 2025에서 발표된 KernelSnitch 논문을 소개이다. 이 연구는 커널의 평범한 데이터 구조체들이 가진 본질적인 특성이 어떻게 심각한 보안 취약점이 되는지를 보여준다. 핵심은 이러하다: "데이터 구조체의 크기에 따른 접근 시간 차이를 이용해 커널의 비밀 정보를 유출할 수 있다" 여기서는 커널 힙 포인터 유출에 집중해서 설명한다. 이 공격이 성공하면 KASLR을 우회하고 더 심각한 커널 익스플로...

Jul 11, 20257 min read131

멀티태스크와 액터 모델

멀티태스크 협조적/비협조적 멀티태스크 선점: 프로세스와의 협조 없이 수행하는 컨택스트 스위칭이라고는 하나, 결국 뺏어오는 게 가능하냐의 문제다. 협조적 멀티태스크(비선점형, cooperative): 각각의 프로세스가 자발적으로 컨택스트 스위칭을 수행하는 멀티태스크 방식. 장점: 멀티태스크 매커니즘을 구현하기 쉽다. 단점: 프로세스가 자발적으로 컨텍스트 스위칭을 해야하는데, 만약 버그가 발생하여 프로세스가 무한 루프에 빠지거나 정지하게 되면 그 ...

Jul 6, 20252 min read25
M

MaxLog

35 posts