TanukiWorld

CI/CD Jenkins & Canary release

happytanuki — Tue, 31 Mar 2026 17:14:41 +0900

CI/CD 파이프라인을 구성하려면 여러 방법이 있다.

오늘은 그 중 한가지 Jenkins와 도커를 활용해서 Canary release를 구성해보자.

준비물로는 리눅스 서버 둘을 사용할 것이다.

우선 코드는 다음과 같다
https://github.com/HappyTanuki/canary_test.git

GitHub - HappyTanuki/canary_test

Contribute to HappyTanuki/canary_test development by creating an account on GitHub.

github.com

Server.js

const http = require("http");

const PORT = process.env.PORT || 8080;
const COLOR = process.env.COLOR || 'blue';
const VERSION = 'V2';

http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
    res.end(`[${VERSION}] 현재 응답 서버 식별: ${COLOR} (포트: ${PORT})\n`);
}).listen(PORT, () => {
    console.log(`서버 가동 완료 (PORT: ${PORT})`);
});

default.conf

include /etc/nginx/conf.d/upstream.inc;

server {
    listen 80;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

nginx/Dockerfile

FROM nginx:alpine
COPY default.conf /etc/nginx/conf.d/default.conf
RUN echo "upstream backend { server app-blue:8080; }" > /etc/nginx/conf.d/upstream.inc

Dockerfile

FROM node:18-alpine

WORKDIR /usr/src/app

COPY server.js .

# 가동시점이 다르다, 이거와 ENTRYPOINT는 실행시, RUN은 빌드 시
CMD ["node", "server.js"]

이제 다음 명령어로 기본적으로 서버 배포 환경을 먼저 구성한다:

docker network create canary-net
cd nginx
docker build -t my-nginx .
docker run -d --name nginx-proxy --network canary-net -p 8088:80 my-nginx
cd ..
docker build -t my-canary-app .
docker run -d --name app-blue --network canary-net -e PORT=8080 -e COLOR="  BLUE" my-canary-app

여기까지 잘 수행되었다면 상황은 다음과 같이 된다:

happytanuki@tanukiworld:~/canary_test$ docker ps
CONTAINER ID   IMAGE                                          COMMAND                  CREATED             STATUS             PORTS                                     NAMES
aba1b7bab705   my-nginx                                       "/docker-entrypoint.…"   52 minutes ago      Up 52 minutes      0.0.0.0:8088->80/tcp, [::]:8088->80/tcp   nginx-proxy
78e274dc3d24   my-canary-app                                  "docker-entrypoint.s…"   About an hour ago   Up About an hour                                             app-blue

nginx reverse proxy를 설정하여 이 서비스를 외부에서 접속할 수 있도록 설정한다:

happytanuki@tanukiworld:~$ cat /etc/nginx/sites-available/canary_test
server {
    server_name canary.happytanuki.kr;
    set $jenkins_addr http://127.0.0.1:8088;

    proxy_set_header Host $Host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Frowarded-Proto $scheme;

    # set timeout
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    send_timeout       600s;

    location / {
            proxy_pass $jenkins_addr;
    }


    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/canary.happytanuki.kr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/canary.happytanuki.kr/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = canary.happytanuki.kr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name canary.happytanuki.kr;
    listen 80;
    return 404; # managed by Certbot


}

이제 접근이 되는지 확인해보자

잘 되었다면 다음 단계로 진행한다

이제 server.js를 교체하는데 canary 방식을 사용하기 위해서 jenkins를 준비해 보겠다.

나는 truenas scale 환경에 jenkins를 올려서 설정을 해 주었다.

truenas apps 패널

nginx 리버스 프록시 세팅

/github-webhook/에만 접속을 허용함으로써 보안성을 챙기고 기본적인 https 설정을 해 주고

jenkins 유저를 만들고 배포 환경(다른 환경)에 접속 권한을 주었다.

jenkins docker 내부에 접속해서 ssh-keygen을 실행하여 키 페어를 만들고 공개키를 배포 서버의 authorized_keys에 공개키를 등록한다.

한편, github에서도 프로필 > settings > developer settings > personal access tokens >
fine-grained personal access token을 발급받는다.

웹훅 수신과 clone을 위한 권한 설정

권한 설정은 위와 같이 설정하여 토큰을 발급받아 기억해 두고 github repository > settings > webhooks 로 이동한다.

webhooks

Add webhook을 눌러 새 웹훅을 추가한다.

이런 식으로 설정한다 (Payload URL은 자신의 서버 도메인을 연결하자)

Add webhook을 눌러주면 이제 github가 로컬의 jenkins에게 알림을 주게 된다.

jenkins에 새 프로젝트 프리스타일로 만든다

자신의 git 리포 주소를 넣어주고 오른쪽의 add를 눌러 credential을 추가한다.

username with password를 선택해 준다.

username에 자신의 깃허브 계정명을 넣어주고

아까 발급받았던 토큰을 password에 넣어준다

빌드할 브랜치를 선택해 주고

깃허브 웹훅에 반응하도록 GitHub hook trigger for GITScm polling을 체크해 준다

그리고 Add build step을 해서 다음과 같은 쉘 스크립트 빌드 단계를 입력해 준다.

#!/bin/bash

REMOTE_ENVIROMENT="-p 8000 happytanuki.kr"
REMOTE_PATH="~/canary_test"

function update_nginx_weight() {
    local BLUE=$1
    local GREEN=$2
    echo ">> 트래픽 비율 변경 중... Blue(${BLUE}%) / Green(${GREEN}%)"

    # weight가 0인 서버는 설정에서 아예 제외합니다! (Nginx 에러 방지)
    CONF="upstream backend { "
    [ "$BLUE" -gt 0 ] && CONF="${CONF} server app-blue:8080 weight=${BLUE}; "
    [ "$GREEN" -gt 0 ] && CONF="${CONF} server app-green:8081 weight=${GREEN}; "
    CONF="${CONF} }"

	ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
    ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker exec nginx-proxy sh -c \"echo '$CONF' > /etc/nginx/conf.d/upstream.inc\""
	ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
    ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker exec nginx-proxy nginx -s reload"
}

# 1. 지금 켜져있는 서버가 누군지 검사합니다.
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
IS_BLUE=$(ssh ${REMOTE_ENVIROMENT} docker ps -q -f name="^app-blue$")

if [ -n "$IS_BLUE" ]; then
    CURRENT="blue"; TARGET="green"; TARGET_PORT=8081; TARGET_COLOR="  GREEN"
else
    CURRENT="green"; TARGET="blue"; TARGET_PORT=8080; TARGET_COLOR="  BLUE"
fi

echo "  새로운 버전 [${TARGET}] 구동 시작!"

# 2. 최신 코드로 도커 이미지를 굽습니다(build).
echo "building canary app"
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker build -t my-canary-app ."

# 3. 혹시 예전에 쓰다 남은 타겟 컨테이너가 있다면 미리 삭제합니다.
echo "deleteing canary app"
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker rm -f app-$TARGET 2>/dev/null"

# 4. 새 컨테이너를 실행합니다! (핵심: --network 로 같은 가상망에 묶어줍니다)
echo "running canary app"
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker run -d --name app-$TARGET \
  --network canary-net \
  -e PORT=$TARGET_PORT \
  -e COLOR=\"$TARGET_COLOR\" \
  my-canary-app"

# 5. Health Check: Nginx가 새 서버랑 대화가 잘 되는지 확인합니다.
sleep 5
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
RESPONSE=$(ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker exec nginx-proxy sh -c \"wget -qO- http://app-$TARGET:${TARGET_PORT}\"")
if [ -z "$RESPONSE" ]; then
    echo "❌ 실패! 새 서버가 제대로 켜지지 않았습니다. 롤백합니다."
	ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
    ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker rm -f app-$TARGET"
    exit 1
fi

# ==========================================
# 6. 점진적 트래픽 전환 (Canary Stages)
# ==========================================
echo "✅ [1단계] 10% 카나리 오픈 (15초 대기)"
if [ "$TARGET" == "green" ]; then update_nginx_weight 90 10; else update_nginx_weight 10 90; fi; sleep 15

echo "✅ [2단계] 50% 트래픽 전환 (15초 대기)"
if [ "$TARGET" == "green" ]; then update_nginx_weight 50 50; else update_nginx_weight 50 50; fi; sleep 15

echo "  [3단계] 100% 완전 전환!"
if [ "$TARGET" == "green" ]; then update_nginx_weight 0 100; else update_nginx_weight 100 0; fi

# 7. 이제 쓸모없어진 구버전 컨테이너를 삭제(rm)합니다!
ssh-keyscan ${REMOTE_ENVIROMENT} > ~/.ssh/known_hosts
ssh ${REMOTE_ENVIROMENT} "cd ${REMOTE_PATH} && docker rm -f app-$CURRENT"

여기까지 완료되었다면 save를 눌러 빠져나와 주면 main 브랜치에 push하거나

지금 빌드 버튼을 눌러주면

빌드와 배포가자동으로 되기 때문에

배포 url에 일정 비율만큼 green blue가 트래픽을 나눠받는 걸 f5를 연타함으로써 확인해볼 수 있다

[Unreal 5.5.1] Gameplay Framework

happytanuki — Fri, 3 Jan 2025 00:50:33 +0900

유니티는 어떤지 모르겠지만 언리얼에서는 엔진이 알아서 해주는 부분이 엄청나게 많고, 유니티에서처럼 기본 객체를 가지고 무엇이든지 다 만들 수 있는 것이 아니라 언리얼의 엄격한 틀에 맞춰서 적절한 클래스를 상속받고 적절한 위치에 적절한 코드를 배치해야 최적화와 확장성을 다 챙길 수 있다.

물론 Level Blueprint 내지 GameInstance, GameMode에 모든 코드를 다 써넣는다거나 하는 짓은 가능하지만 일단 된다고 넘어갔다가 피본다.. 꼭 하라는대로 안하고 왜? 를 좋아하는 내가 되는대로 짰다가 코드를 여러번 뒤집어 엎었다..

예를 들어 GameMode가 있다면 이 게임모드를 교체함으로써 플레이 도중에 게임의 규칙을 바꾼다거나 할 수 있는 행동을 위탁하는 전략 패턴(Strategy pattern)을 사용할 수 있게 되므로 유연하고 창의적인 자유도를 위해서 역설적으로 구조를 강제하는 것이다.

게임플레이 프레임워크의 요소를 몇 개 보면. 각 클래스는 에픽게임즈의 의도대로 적절히 활용한다면 코드 수정없이 멀티플레이 게임을 구성할 수 있도록 모듈화되어 있으므로 멀티플레이어 게임을 상정하고 있다면 각 클래스의 멀티플레이어에서의 역할도 잘 보아 놓는 것이 중요할 것이다.
GameInstance

GameMode
GameState
PlayerState

HUD

Controller

Pawn

etc..

GameInstance:

게임이 실행중인 동안 계속 저장해야 할 정보를 저장한다. 이 객체는 서버와 클라이언트가 각각 가지고 있으나 서로의 값을 가져올 수 없고 리플리케이트되지 않는다.

GameMode:

게임의 규칙이나 게임 승리 조건 등등을 정의한다, 이 객체는 서버에서 각 클라이언트로 리플리케이트(Replicate)되지 않는다.

다시말해 여기에서 정의한 규칙은 클라이언트에서 읽으려고 시도할 수 없다.

따라서 이 객체에는 플레이 도중에 바뀔 필요가 있거나 클라이언트가 알아야 하는 데이터 (예) 팀 스코어)를 포함할 수 없다.

GameState:

게임의 현재 상황에 대한 정보를 가지고 있다. 또한 각 클라이언트가 알아야 할 정보 (예) 접속한 플레이어의 수, 팀 스코어 등등.)를 가지고 있으며 이 객체는 서버에서 각 클라이언트로 리플리케이트된다.

다시말해 여기에서 정의한 규칙은 클라이언트에서 읽을 수 있다.

하지만 읽기 전용이므로 GameState의 값을 수정할 수는 없다.

PlayerState:

플레이어의 현재 상황에 대한 정보를 가지고 있다. 또한 각 클라이언트가 알아야 할 정보 (예) 플레이어의 점수, 플레이어의 이름 등등.)를 가지고 있다. 이 객체는 서버에서 각 클라이언트로 리플리케이트된다.

다시말해 여기에서 정의한 규칙은 클라이언트에서 읽을 수 있다는 뜻이다.

또한 모든 클라이언트와 서버에게 리플리케이트되므로 다른 클라이언트나 서버에서도 값을 읽을 수 있다.

클라이언트에서 다른 클라이언트의 값을 수정할 수 없다.

HUD:

클라이언트에만 존재하는 객체로, 화면에 오버레이로 표시되는 체력 바, 글씨, UI등등이 포함된다. 보통 각 클라이언트의 PlayerController가 소유하고 있도록 설계된다.

다시 말해, 서버에서는 각 클라이언트의 HUD객체를 얻을 수 없고, 그럴 필요도 없다.

Controller:

Pawn을 소유하는 객체로, 주로 AIController와 PlayerController가 있다.

AIController는 NPC를 조종하는 컨트롤러로, 서버에만 존재하며 각 클라이언트에게 리플리케이트되지 않는다.

PlayerController는 플레이어의 입력을 처리하여 서버에 적절히 전달하며, 서버와 각 클라이언트에 전부 존재하나 클라이언트에서는 다른 클라이언트의 PlayerController를 읽을 수 없다.

Pawn:

Possessable(소유 가능)한 Actor로, AIController나 PlayerController가 소유(Possess)함으로써 조종할 수 있다.

Pawn 또는 Actor 또는 Charactor 객체는 서버에서 각 클라이언트에 리플리케이트 될 수도, 되지 않을 수도 있다.(조정할 수 있다.)

마지막으로 언리얼을 다룬 지 오래됐고, 인터넷에는 이 객체를 부적절하게 활용하는 예제가 많아 틀린 내용이 있을 수 있다. 인지하는대로 고치도록 하겠다.

틀린 내용이 있다면 댓글로 알려주면 수정하도록 하겠다.

[Promether #0] 기획 정리

happytanuki — Thu, 12 Dec 2024 02:43:31 +0900

캐릭터 Riana, 리아나

내가 2023년도에 친구들과 진행했던 프로젝트 Promether는 언리얼을 이용해서 만든 온라인 멀티플레이어 MOBA 게임이었다.
1:1대전 게임도 아니고 여러명이, 그것도 스킬이 있는 멀티플레이어 게임을 만든다는것이 얼마나 힘든 일인지 알았다면 조금 더 개발 계획을 타이트하고 길게 잡고 할걸 이라는 아쉬움이 남는다.
결국 프로젝트는 겨우 게임상에서 온라인으로 만나 평타를 쳐서 상대를 죽일 수 있다 수준까지만 구현되고 끝이 났었다.

게임의 기획의도
1. 당시 졸업 작품을 목표로 6개월동안 목표를 실현하기 위한 시도와 과정 자체가 포트폴리오로써 의미가 있는 프로젝트.
2. 시장조사결과 10~30대를 타겟으로 하여 주중 게임 평균 이용시간인 78분 이내로 2~3게임 이상 즐길 수 있는 게임.
3. 이 게임만의 확실한 차별성과 메리트를 확보하고 컨텐츠의 볼륨이 아닌 유저의 특성과 환경을 고려.

게임명	Promether	장르	3D 쿼터뷰 MOBA
플랫폼	Windows	타겟 유저	10~30대 PC게임 유저, 주로 10대 남성	경쟁 게임	League of legend, heroes of the storm, DOTA2
게임 컨셉	1. 6명의 유저가 한 전장에 배치되어 적을 쓰러뜨리거나 오브젝트를 부숴 적의 라이프를 0으로 만드는 MOBA 게임이다. 2. 캐릭터가 가진 스킬을 활용하여 상대를 처치할 수 있으며, 상대를 처치하거나 목표를 차지하는 경우 상대의 라이프가 줄어들고, 라이프를 0으로 만들 경우 승리한다. 3. 플레이시간 10~15분 내외의 짧은 호흡의 게임으로 기획하여 1시간에 3게임 이상 즐길 수 있는 것을 목표로 한다.
기획 의도	1. MOBA 장르를 선호하지만 게임 이용시간이 적거나, 그로 인해 적은 게임 횟수를 아쉬워 하는 유저를 대상으로 게임 한 판의 호흡이 짧은 MOBA를 만들어 기존 게임과 차별성을 두면서 10대 유저를 타겟으로 한 장점으로 삼는다. 2. AOS 형식으로 진행하기 이전 단계로 3대3 데스매치 형식의 게임으로 향후 발전 시켜 다른 룰로 진행하거나 해당 방식을 발전시킬 예정

게임플레이-승리조건

게임플레이-캐릭터 강화

적을 처치하거나 석상을 파괴하여 일정량의 경험치를 획득하면, 강화 포인트를 획득하고 강화할 스킬을 선택하여 강화할 수 있다.

강화 요소-탈리스만

탈리스만 색깔별 능력치 의미

물론 이대로는 상당히 게임 템포가 느려지거나 1분 이내로 1레벨 이상 렙업을 해야 하는 등 게임 템포가 극단적이 되므로 당시 기획자 친구와 논의하여 조정을 거쳤다.
조정 내용은 다음과 같다.

탈리스만은 각 3레벨까지만으로 한다.
스킬은 애초 계획을 변경하여 3레벨까지만 강화 가능하도록 한다.

기획서에 없는 내용으로, 모든 캐릭터는 스킬을 우선 가지고 시작한다.
또한 이 탈리스만과 스킬들은 모두 다 찍을 일이 없어도 상관없으므로 한 스킬이나 한 탈리스만에만 몰아서 투자하여도 상관없도록 설계함을 원칙으로 한다.

.
.
.
기록을 찾는대로 업데이트하여 유지하도록 하겠다.

티스토리 도메인 등록기

happytanuki — Mon, 9 Dec 2024 19:20:30 +0900

티스토리를 시작하면서 happytanuki.kr인 내 도메인을 연결하려고 하자 오류가 났다.

서브도메인인 blog.happytanuki.kr에 연결하자 조금 시간이 지나 티스토리 상에서는 연결이 되었다고 뜨나, 실제 접속하면 접속할 수 없다고 뜬다.

이게 뭔 버그고..

인터넷을 찾아보니 웹서버에서 301리다이렉트를 걸어주면 된다고 하여 간단하게 걸어보겠다.

nginx 설정

nginx 설정 경로로 접속하여 가상 호스트 설정 파일을 만든다.

blog 파일:

server {
        server_name happytanuki.kr www.happytanuki.kr;

        location / {
                return 301 https://blog.happytanuki.kr$request_uri;
        }
}

그러나 아직도 유효한 인증서가 없다고 하는 중...

인터넷을 찾아봐도 딱히 뭐가 없는거 보면 그냥 일시적인 버그일수도 있으니 최대 일주일까지 기다렸다가 티스토리에 문의해야겠다..

KST 2024:12:09:10:06 - 결국 시간이 해결해줬다.. 그냥 뭔가 티스토리 서버가 불안정했을수도..

티스토리 스킨 개발환경 만들기 [#2]

happytanuki — Mon, 9 Dec 2024 18:33:35 +0900

티스토리의 스킨 파일 구조는 몇 개의 파일과 디렉터리로 이뤄진다.

SKIN ─┬─ index.xml
      ├─ skin.html
      ├─ style.css
      ├─ preview.gif
      ├─ preview256.jpg
      ├─ preview560.jpg
      ├─ preview1600.jpg
      └─ images ─┬─ script.js
                 ├─ background.jpg
                 ├─ template.css
                 └─ etc.. etc..

각각의 파일은 역할을 가지고 있는데.

index.xml

스킨의 메타데이터를 담는 파일이다. 이 내용으로 스킨 제작자, 이름 등이 포함된다.

skin.html

스킨 템플릿 파일이다. 여기에 적은 내용을 바탕으로 치환자를 치환하여 블로그 페이지를 렌더링하게 된다.

style.css

스타일시트이다. 아무래도 일반 HTML의 그것과 같은 것인 듯?

preview

미리보기용이라고 한다. 나중에 알게 될 듯?

preview.gif : 미리보기 기본 파일로 아래 파일이 없는 경우에 사용 (112x84)
preview256.jpg : 사용 중인 스킨 미리보기 (256x192)
preview560.jpg : 스킨 목록 미리보기 (560x420)
preview1600.jpg : 스킨 상세보기 미리보기 (1600x1200)

images

모든 필수가 아닌 파일들이 모두 위치한 짬통.

index.xml

index.xml 파일은 스킨의 기본 정보를 정의하는 파일이므로 일단 먼저 정의하고 가면 좋겠다.

그러나 내용이 많아서 아마 나중에 구조를 보면서 다시 정리해야 하지 않을까 싶다.

추후 알게되는 대로 업데이트 하여 수정하겠다.

<?xml version="1.0" encoding="utf-8"?>
<skin>
  <information>
    <name>기본 스킨</name>
    <version>1.1</version>
    <description>
      <![CDATA[웹표준을 준수한 XHTML 기반의 Tistory 기본 스킨입니다.]]>
    </description>
    <license>
      <![CDATA[자유롭게 수정이 가능하며, 저작권 표시하에 재배포 가능합니다.]]>
    </license>
  </information>
  <author>
    <name>tistory</name>
    <homepage>http://notice.tistory.com</homepage>
    <email>tistoryblog@daum.net</email>
  </author>
  <default>
    <recentEntries>5</recentEntries>
    <recentComments>5</recentComments>
    <recentTrackbacks>5</recentTrackbacks>
    <itemsOnGuestbook>10</itemsOnGuestbook>
    <tagsInCloud>30</tagsInCloud>
    <sortInCloud>3</sortInCloud>
    <expandComment>0</expandComment>
    <expandTrackback>0</expandTrackback>
    <lengthOfRecentNotice>25</lengthOfRecentNotice>
    <lengthOfRecentEntry>27</lengthOfRecentEntry>
    <lengthOfRecentComment>30</lengthOfRecentComment>
    <lengthOfRecentTrackback>30</lengthOfRecentTrackback>
    <lengthOfLink>30</lengthOfLink>
    <showListOnCategory>1</showListOnCategory>
    <showListOnArchive>1</showListOnArchive>
    <commentMessage>
      <none>댓글이 없습니다.</none>
      <single>댓글 &lt;span class="cnt"&gt;하나&lt;/span&gt; 달렸습니다.</single>
    </commentMessage>
    <trackbackMessage>
      <none>받은 트랙백이 없고</none>
      <single>트랙백이 &lt;span class="cnt"&gt;하나&lt;/span&gt;이고</single>
    </trackbackMessage>
    <tree>
      <color>000000</color>
      <bgColor>ffffff</bgColor>
      <activeColor>000000</activeColor>
      <activeBgColor>eeeeee</activeBgColor>
      <labelLength>27</labelLength>
      <showValue>1</showValue>
    </tree>
    <contentWidth>500</contentWidth>
  </default>
</skin>

파트:

name: 스킨 이름
version: 스킨 버전
description: 상세 설명
license: 저작권

파트:

name: 제작자 이름
homepage: 제작자 웹사이트 주소
email: 이메일

파트:

recentEntries: 사이드바의 최근글 표시 갯수
recentComments: 사이드바의 최근 댓글 표시 갯수
recentTrackbacks: 사이드바의 최근 트랙백 표시 갯수
itemsOnGuestbook: 한페이지에 표시될 방명록 갯수 *
tagsInCloud: 사이드바에 표시될 태그 갯수
sortInCloud: 태그 클라우드 표현 방식 (1:인기도순, 2:이름순, 3:랜덤)
expandComment: 댓글영역 표현 방식 (0:감추기, 1:펼치기)
expandTrackback: 트랙백영역 표현 방식 (0:감추기, 1:펼치기)
lengthOfRecentNotice: 최근 공지 표현될 글자수
lengthOfRecentEntry: 최근 글 표현될 글자수
lengthOfRecentComment: 최근 댓글에 표현될 글자수
lengthOfRecentTrackback: 최근 트랙백에 표현될 글자수
lengthOfLink: 링크에 표현될 글자수
entriesOnPage: 홈 화면 글 수
entriesOnList: 글 목록 글 수
showListOnCategory: 커버 미사용 홈에서 글 목록 표현(0:내용만, 1:목록만, 2: 내용+목록)
showListLock : 홈 설정과 기본 설정에서 '목록 구성 요소' 항목의 노출 여부 결정 (0: 노출, 1: 노출 안 함)
tree: 카테고리
- color: 카테고리 글자색
- bgColor: 카테고리 배경색
- activeColor: 선택시 글자색
- activeBgColor: 선택시 배경색
- labelLength: 표현될 카테고리 글자 수
- showValue: 카테고리 글 수 표현(0:숨김, 1:보임)
- contentWidth: 콘텐츠영역 가로 사이즈, 이 사이즈에 맞춰 에디터의 위지윅이 제대로 구현된다.
cover: 홈 커버 기본값이다. 추후 다시 설명한다고 한다.

스킨 옵션:

스킨 옵션이라는 게 있다는데 파일에 안보인다. 추후 설명을 보아야 할 듯?

리스트 스타일:

사용할 수 있는 글 목록 스타일을 정의한다고 한다. 추후에 수정하겠다.

치환자 구조

티스토리 스킨 템플릿의 치환자는 그룹 치환자, 값 치환자로 두가지인데, 각각 다음과 같이 표현된다.

<s_tag></s_tag>:

그룹 치환자로, 내부의 다른 데이터들을 포함하여 렌더링된(HTML로 변환된) 값으로 변환된 값으로 치환될 부분입니다.

[¡##_tag_##]:

값 치환자로, 해당하는 값으로 치환됩니다. 아마도 변수의 값을 읽어와 출력하는 느낌일 듯 하다.

(태그 안쪽의¡는 티스토리에서 자동으로 치환해버리기에 추가한 문자이다. 실제로는 없이 작성해야 작동한다.)

티스토리 스킨 개발환경 만들기 [#1]

happytanuki — Mon, 9 Dec 2024 16:56:56 +0900

공부를 시작하기 전에 책상을 먼저 치워야 직성이 풀리는 나 답게 우선 스킨 커스터마이징 하는 툴을 만들어 블로그 스킨을 먼저 만들기로 했다.

우선 제일 먼저 해야 할 일은 오픈소스 찾기.

Github: tidory

GitHub - pronist/tidory: 티스토리 스킨 프레임워크, 티도리

티스토리 스킨 프레임워크, 티도리. Contribute to pronist/tidory development by creating an account on GitHub.

github.com

티도리라는 깃허브 오픈소스 프로젝트를 찾았다.

아무래도 티스토리의 치환자 에 대한 설명이나 무슨무슨 파일이 있는지는 기본으로 가지고 가는 것 같아 티스토리 치환자 에 대한 기본 정보는 따로 찾아야 할 것 같다.

https://tistory.github.io/document-tistory-skin/

소개 · GitBook

No results matching ""

tistory.github.io

이런 글을 찾았다. 이제 이 둘을 가지고 공부해야겠다.

블로그 시작

happytanuki — Mon, 9 Dec 2024 16:17:01 +0900

포트폴리오 작성과 공부한 걸 나중에 찾아보고 다시 되새기기 위해 블로그 글로 정리하기로 했다.

앞으로 게임 개발, c/c++개발, 토이 프로젝트, 리눅스 서버 등등 생각나는대로 정리해서 꾸준히 작성해보려고 한다.