Hugo on cublr's blueprint

해야만 하는 일이 있다

sparkstar@empas.com (sparkstar) — Sat, 22 Jan 2022 22:00:00 +0900

어떤 일들은 반드시 일을 시작하기 전, 처음에 해야만 한다. 그런 일들은 만 명중 만 모두 동의하는 것이기도 하고, 또 모두가 동의하지 않아 우선순위에서 밀리는 것들이 있기 마련이다. 어느새 일을 시작한 날이 오래되어 많은 사람들과 일하면서 느낀 것이 있는데, 사람들이 생각하기에 중요한 일은 다 중요한 일이 아니고 대강 이렇게 두 가지가 있다고 믿는 것 같다. 중요하고 필수적인 것, 그리고 중요하지만 필수적이지는 않은 것. 그렇기 때문에 전자의 경우 처음에 진행하는 것에 아무런 이견을 달지 않지만, 다른 일은 반대하는 사람들이 생긴다. 여기서 포인트는 전자나 후자 모두 그것이 중요하다는 것에는 한결같이 동의한다는 것이다. 다만 각각이 생각하는 우선 순위가 다른 것. 회사일로 따지면 보통 중요한 것 중, 그중에서도 중요하다고 여기는 것들은 결과물을 낼 수 있는 프로그래밍 코드나 컴파일된 바이너리가 조금 더 그런 경향이 있는 것 같고, 그 이외의 것들, 예를 들어 배포 시스템이 중요하지만 우선순위가 낮다고 생각하는 것 같다.

잠깐 다른 이야기를 하면, 나는 게임을 상당히 좋아하는 편이다. 운이 좋게도 어렸을 때 하루종일 많은 게임을 하더라도 집에서 딱히 혼내거나 하진 않아서 남들보다 더 많은 게임을 편하게 했다. 거기다 형제가 있어 게임 위 자연스러운 경쟁 관계를 가지게 되었다. 그런 환경에서 살았기 때문에, 지금은 무슨 게임을 하더라도 대부분의 사람들보다 빠르게 게임에 적응할 수 있게 되고 더 높은 실력을 낼 수 있게 되었다. 특히 사람과의 경쟁이 있는 게임은 특히 더 그러는 편인데, 이런 히스토리를 모르는 사람들은 이제, 게임에 재능이 있는거 아니냐, 집에서 아무것도 안하고 게임만 하는 것이 아니냐 하는 이야기도 종종 듣는다.

게임을 잘 하기 위해서 제일 필요한 것은 무엇인가? 게임마다 그 목표는 다르지만 결국 달성해야 하는 것은 확실하다. 목적을 달성한다는 것이 바로 그것이다. 여러 장르의 게임이 있고 목적이 다 다르므로, 잘 한다의 기준이 다르니 여기서는 기준을 조금 좁혀서, 사람과 경쟁하는 것으로만 좁혀서 생각해 보자. 격투 게임이라면 내 캐릭터의 성능을 바르게 파악하는 것, 그래서 기술을 파악하고 상대보다 덜 맞고 더 때리는 것이 승리의 조건이다. 전략 시뮬레이션, 스타크래프트로 예를 들면 최적화된 빌드 오더를 실수없이 수행한다거나, 돌발 상황에서 유리함으로 이끄는 판단력 등이 필요하다. 그러나 이런 것들은 보통 나와 경쟁 상대가 이미 잘 하는 상황에서, 상대보다 더 필요한 능력이다. 서로 처음 시작했을 때, 완전한 제로에서 시작했다면 상대보다 더 필요한 것은 바로 능숙한 조작 능력이다.

격투 게임에서는 버튼을 눌러 거기에 대응하는 기본기를 내는 것 이외에도, 방향키를 복잡하게 조작하여 특별한 기술을 낼 수 있다. 그리고 이런 기술들은 기본기보다 성능과 판정 모두 뛰어나서, 필요할 때 이런 기술을 쉽게 낼 수 있으면 대개 승리할 수 있다. 기본기로 닿지 않는 거리에서 상대를 견제하는 수단은 장풍이라고 불리는 파동권류 기술밖에 없고, 이를 통해 먼 거리의 상대 움직임에 제약을 줄 수 있는 것이다. 즉, 승리하기 위해서는 적절한 상황에 기술을 낼 수 있어야 한다. 적절한 상황에 기술을 낼 수 있어야 한다는 것, 이것은 일반적으로 적절한 상황을 읽는 판단력을 이야기한다. 그러나 여기 이 글에서는 기술을 낼 수 있어야 한다에 대한 이야기를 하려고 한다.

기술의 조작은 쉬운 것부터 어려운 것까지 있으며, 보통 성능 좋은 것들은 복잡한 경향이 있는 편이다. 초보자들의 경우 이런 기술을 쓸 때의 과정이 대략 기술을 써야겠군->방향키를 이렇게 돌리고->버튼을 눌러야겠다가 된다. 그래서 판단이 바로 기술로 이어지지 않는다. 거기에 추가로 그 발동 성공률에도 차이가 있다. 판단이 결과로 이어지지 않을 수도 있는 것이다. 일반적으로 잘 하는 사람들이란 기술을 써야겠군이라는 판단과 기술의 발동이 동시에 이루어진다. 그리고 그 발동이 실패하지도 않는다. 55프레임을 모아야 나가는 소닉붐이 거의 55~56프레임 사이로 정확하게 발동한다. 즉 과정 자체가 아예 다르다.

스타크래프트로 치면 유닛에 명령을 내리기 위해 마우스로 바닥이든 명령이든 뭔가를 클릭하는 것이 아니라, 적절한 단축키를 상황에 맞추어 낸다. 거기다 유닛, 명령 뿐 아니라 화면 지정 단축키까지도 사용한다. 판단의 과정이 명령을 내려야겠군->유닛의 위치를 찾아서->공격 명령을 내려야겠다 가 아니라 선택된 유닛이 여기로 공격을 가야겠다로 다른 것이다. 아직도 스타크래프트의 자원에는 미네랄과 가스만 있다고 생각하는 사람들이 많지만 이 게임에는 사실 시간이라는 자원도 있으며, 조작의 능숙함이 이 시간이라는 자원을 더 얻을 수 있게 만들어준다.

게임을 잘 하기 위해 더 잘 때리고 더 잘 싸우는 다소 막연한 능력을 얻으려 노력하는 것보다(그리고 그런 것들은 보통 얻기도 힘든 능력이다), 달성하기 쉽고 연습한 만큼 빠르게 늘 수 있는 조작을 더 익숙하게 만드는 것이 더 중요하다는 뜻이다. 조작 능력이 익숙할수록 판단의 과정을 더 줄여줄 수 있고, 다른 중요한 것에 더 집중할 수 있다. 그래서 조작은 우리가 생각하는 중요도보다 훨씬 더 중요하다. 반드시 익숙해지도록 훈련이 필요한 능력이다. 그리고 대부분의 사람은 움직일 수 있고 원하는 것을 할 수 있으면 조작에서 더이상 달성할 것이 없다고 생각하고 그것을 크게 중요하다고 여기지 않는다.

연차가 많아지고 다닌 회사가 많아지면서, 그리고 작은 회사와 큰 회사, 그리고 국내에서 가장 큰 IT회사 등등… 여러 회사에서 일하며 느낀 것은 가장 위에서 말한 그런 것이다. 누구나 중요하다고 생각하면서도 신기하게 우선 순위는 높다고 생각하지 않고, 다른 일들을 먼저 처리하는 것. 지나고 보면 더 급했다고 생각한 것들은 정말로 아무것도 아니었는데 말이다.

기존의 미니 보드 odroid-u3에 구축된 쿠버네티스 시스템이 있었는데, 이번에 드디어 라즈베리 파이로 시스템을 다시 구축하였다. 그래서 기존 클러스터에 있던 job과 시스템을 마이그레이션 하는 중인데, 오늘 다소 장황한 이 글을 작성하는 이유는 여기에 구축된 시스템 때문이었다. 글을 많이 쓰고 있지는 않았지만 그래도 여기 블로그와 옆 위키에는 글을 작성하면 자동으로 빌드되어 배포가 되도록 구성해 놓은 적이 있다. 글을 작성하고 master 브랜치에 push하는 것으로 트리거가 발생하고, 이것이 job을 실행하도록 하여 블로그와 위키에 글을 자동 발행되도록 만든 배포 시스템인데, 이것을 만든 것이 2019년 말 쯤이었다. 그리고 이 시스템이 있었기 때문에 나는 판단의 과정, 여기서는 발행의 과정을 줄일 수 있었다. 작성한 글을 발행해야지->작성한 글을 여기서 받아놓고->hugo로 빌드하고->결과를 이쪽에 복사하고->deployment를 업데이트해야겠다라는 복잡한 과정이, master에 올려야지로 간단하게 줄어들었다. 필요한 것은 글을 발행하는 것이었고 그 과정은 줄었다. 그리고 그것이 2년 반 동안 문제없이 수행되었고, 여러가지 번거로운 과정이 있는지도 몰랐을 정도로 그 기간동안 충분하게 이득을 누렸다. 엄청나게 잘 구축할 필요도 없었던, 단순히 빌드 과정이 자동화된 정도로만 해 놓아도 그런 이득이 발생한 것이다. 그런 면에서 생각해 보면, 필요한 만큼만 시스템이 구축되어도 충분하게 이득이라는 것. 여기서 필요한 만큼이란 단계를 하나로 줄이고 자동화한 것이며, 이것만 어떻게든 달성되어도 어마어마하게 잘 구축된 시스템과 동일한 이득을 누린다는 것이다.

그래서 하고 싶은 말은, 프로젝트 시작 전 모두가 중요하다고 생각하면서도 그렇게 생각하지 않는 작업들이 있다면, 그리고 그것이 앞으로 진행될 개발에 자명한, 자명하지 않더라도 큰 이득을 줄 수 있겠다 판단하면, 사람들이 반대하더라도 필요한 그것을 구축하는 것이 좋다. 그리고 최대한 프로젝트 초반에 빨리 구축될수록 좋다. 그런 것이 만약 배포라면 판단의 과정, 발행의 과정처럼 그리고 개발 사이클의 과정을 줄일 수 있다. 그리고 내 생각에… 이런 시스템들은 대개 잘 구축되지 않아도 된다. 물론 잘 되면 좋지만 중요한 것은 달성해야 하는 목표, 필요한 단계를 줄여주는 것, 그것만 달성하면 되는 것이다. 잘 되었든 아니든간에 어차피 누릴 수 있는 이득은 동일하기 때문이다.

위키 업데이트

sparkstar@empas.com (sparkstar) — Mon, 15 Jun 2020 01:08:50 +0900

위키를 업데이트했다. 기존에는 Dokuwiki 기반의 사이트였는데, 이번에 블로그와 같이 hugo를 사용하기로 했다. 도쿠위키, 생각해보면 도쿠위키가 진짜 애매한 것이 아닌가 싶다. 파일 기반으로 위키를 관리하면서 정적 페이지도 아니고, 그렇다고 뭔가 현란한 기능이 있는 것도 아니고.

처음에 위키를 만들 때 어떤 솔루션으로 할지 신중하게 고민했던 기억이 있다. 그러면서 어떤 것이 장점이 되고 단점이 될지 여러 위키 엔진을 비교하며 결정을 했는데, 그 때 도쿠위키를 선택한 이유는 크게 이런 이유들이었다.

파일 기반이라 데이터베이스가 필요없다
php기반이므로 잡다한 권한 관리가 될 것이다
…

블로그를 hugo로 변경하니, 위키도 정적 페이지로 만들어볼만 하겠다는 생각이 들었다. 파일 기반으로 위키를 만들 것이면서 굳이 php를 사용할 필요가 있나 싶은 것이다. 데이터베이스에 접근하는 것도 아니고, 그렇다고 뭔가 리치 텍스트나 복잡한 내용을 쓰는 것도 아니고. 거기다 플러그인을 통해 작성도 마크다운으로 했으니까, 생각해 보면 굳이 사용할 필요가 없었던 것. 또 복잡한 권한 관리가 가능하지 않을까 싶었는데, 애초에 나에게는 권한 관리가 필요 없었던 것이다.혼자 작성하는데.

hugo에서 제시하는 여러 설치 가능한 테마들은 주로 블로그 느낌이 나는 테마들이 많았다. 어떤 것을 선택해서 수정하면 위키처럼 보이게 할 수 있을까 싶어 이런저런 것들을 살펴보다 보니 m10c라는 테마를 선택했다. 일단 어두운 테마가 마음에 들었고, 적당히 심플해서 느낌이 좋다.

이 테마는 왼쪽의 사진 등이 들어가는 공간이 나에게는 전혀 필요가 없었으므로, 이런저런 시도를 해 보며 hugo에 대한 학습도 병행했는데, 이게 생각보다 꽤 깊이가 있고, 고민한 흔적이나 다른 느낌이 매우 괜찮아서 마음에 든다. 정적 페이지를 만들어주는 다른 툴을 써보지는 않아서 비교는 못하겠지만, 생각보다 매우 괜찮지 않나? 하는 생각이 든다.

이를테면 오버라이드를 통해 원 테마를 변경하지 않고도 변경점을 만든다거나, partial 템플릿을 통해 통해 테마를 덮어씌울 수 있는 부분 등이 마음에 들었다. 특히 문서도 잘 되어있어서 오버라이드의 순서라거나 적당한 예제 등만 확인해도 가볍게 코드를 수정할 수 있었다는 말이다. 거기다 go-template을 통해 여러 변수를 사용하여 처리하는 부분도 꽤 마음에 들었다. 물론 go-template 자체를 별로 좋아하지는 않지만.

덕분에 기존 블로그 시스템 배포 이외에도 위키 시스템의 배포를 위해 이런저런 코드 수정이 있었으므로, 이렇게 이번 주말은 위키 업데이트를 위해 사용했다.

Hugo 배포 계획

sparkstar@empas.com (sparkstar) — Sat, 01 Feb 2020 01:06:11 +0900

기존에는 tumblr를 사용해서 블로그를 띄웠었는데, 자체 쿠버네티스도 구축되어 있으므로 이제부터는 Hugo를 사용해서 해 보려고 한다. 그래서 hugo에 대한 이런저런 사용법을 확인해보고 있는데… hugo… 꽤 괜찮은 느낌이다. 어차피 변하지 않는 컨텐츠를 배포하려는 것이므로 뭔가 복잡하게 배우거나 그럴 필요도 없이 적당히 Markdown으로 작성하면 html이 출력된다니 이 얼마나 간편한가.

그럼에도 불구하고 사용법을 보며 언뜻 떠오르지 않는 것들이 있었다. 과역 어떻게 컨텐츠를 배포하는 것이 효율적일까? 하는 것이 바로 그것들 중 하나가 되겠다. 글쓰기 폼이 따로 있는 것이 아니니 어딘가 다른 곳에서 글을 작성해야 하는 것이고, 글이 어느 정도 써지면 이게 자동으로 배포가 되었으면 하는 것이다. 글이 실제로 반영되려면 hugo를 통한 정적 컨텐츠로의 빌드 과정이 포함되어야 하는데, 이걸 누가 트리거링 해줄 것인가도 문제가 된다.

이 블로그는 휴고로 생성한 템플릿인데 이 템플릿 전체가 git에 통째로 올라갈 것이다. git에 커밋이 새로 추가되는 경우 정적 컨텐츠를 새로 빌드하여야 하는 신호로 생각하고 컨텐츠를 새로 빌드할 것이다. 그렇다면 구성을 어떻게 해야 할까? 우선 트리거링을 주는 것은 git webhook을 사용하면 충분히 가능할 것 같은데…

그래서 필요한 것들을 한번 순서대로 생각해 보았다.

hugo로 빌드된 정적 컨텐츠를 보여줄 수 있는 서버가 필요하다.
git 저장소에 저정된 hugo 데이터를 빌드하는 서버가 필요하다.
git의 데이터가 업데이트되었다면 git webhook을 사용해 어딘가에 알려야 한다.
git webhook을 받아 뭔가를 실행할 수 있는 서버가 필요하다.

먼저 1번, 정적 컨텐츠를 보여주는 것은 nginx로 비롯되는 서버들로 간단히 처리할 수 있다. 사용중인 git서버도 있으므로 webhook이벤트를 어딘가로 던지는 것도 문제는 없다. 문제는 webhook 이벤트를 받는 대몬이 없다는 것이다. 그렇다고 이걸 막 또 만들기도 그렇고. 그래도 조금 찾아보니 이런 상황에 간단하게 사용할 수 있도록 webhook이라는 것이 있다는 것을 알게 되었다. 다양한 웹훅 이벤트에 대한 처리를 하기 위해서 이런저런 정의를 json으로 정의할 수 있는데, 이게 상세한 hook-example 예제가 있어서 여러 상황에서 적당히 맞추어가면서 쓸 수 있지 않을까? 마지막으로 필요한 것이 있다면 webhook 이벤트를 받은 후 빌드 명령을 날릴 스크립트나 코드가 필요한데, 이건 어쩔 수 없이 코드를 작성하여야 하겠다…

따라서 쿠버네티스 위에서 돌린다고 했을 때 다음과 같은 그림이 나온다.

유저가 글을 쓴 후 git에 해당 내용을 업로드한다.
git에서 발생한 webhook이 webhook 서버에 이벤트를 보낸다.
받은 이벤트를 통해 git 데이터를 다운로드한 후 정적 데이터로 빌드한다.
빌드된 데이터는 PVC에 저장한다.

뭐 이렇다.

webhook 설정

Webhook은 앞에서 말한 대로 webhook을 사용했다. go로 작성된 간단한 대몬이고, -hooks 옵션으로 웹훅 설정 파일을 읽어 해당 조건에 맞는 웹훅을 발생시킨다. 웹훅 이벤트를 보내는 주체는 이미 구축된 Gogs인데, 설정이 매우 간단했다. 웹훅 이벤트 발생시 들어오는 이벤트 정보는 Gogs의 가이드에서 확인할 수 있다. 이 이벤트를 보고 webhook의 설정을 만들면 되는데, 다음과 같은 식으로 설정하여 이를 쿠버네티스의 ConfigMap으로 작성하였다.

Name: hook-information
Namespace: hook-namespace
Labels: <none>
Annotations: <none>

Data
====
hooks.json:
----
[
 {
 "id": "update-blogs",
 "execute-command": "/mnt/builder",
 "command-working-directory": "/mnt",
 "trigger-rule": {
 "and": [
 {
 "match": {
 "type": "payload-hash-sha256",
 "secret": "SECRET_XXXXXX",
 "parameter": {
 "source": "header",
 "name": "X-Gogs-Signature"
 }
 }
 },
 {
 "match": {
 "type": "value",
 "value": "refs/heads/master",
 "parameter": {
 "source": "payload",
 "name": "ref"
 }
 }
 }
 ]
 }
 }
]
Events: <none>
<Paste>

다음과 같은 조건을 노리고 이를 작성했는데,

X-Gogs-Signature로 간단한 인증 절차를 밟도록 하고,
브랜치 master에 새로운 커밋이 발생한다면
이미 준비된 /mnt/builder를 실행시킨다.

이런 식으로 동작한다. webhook이 동작하는 서버에서는 /mnt/builder를 실행해서, 직접 hugo를 사용해 컨텐츠를 빌드하지 않고 정적 컨텐츠를 빌드하는 쿠버네티스의 Jobs를 생성하도록 하였다. 굳이 이유를 정하자면 각 서버가 하는 역할을 분리하고 싶어서였다. 특히나 Jobs가 그런 용도에 더 적합해 보이기도 했고. 하여간 Jobs를 생성하는 코드는 go와 client-go라이브러리를 를 사용해서 매우 간단하게 처리했다.

Jobs 생성하기

정적 컨텐츠를 빌드하는 Jobs는 다음의 역할을 필요로 한다.

git 저장소로부터 최신 컨텐츠를 가져온다.
hugo를 사용하여 컨텐츠를 빌드한다.

단순히 생각해도 두 가지 작업을 해야 한다. Pod에서 두 가지 작업을 하게 되었으므로 이를 컨테이너 두 개로 나눠야 한다.

initContainers: git 저장소로부터 데이터를 git clone한다. 이 때 서브모듈로 등록된 테마 등을 같이 가져온다.
containers: hugo --source CLONE_DIRECTORY --dest VOLUME을 실행한다.

이렇게 작성하면 될 것 같다. 그래서 이와 똑같이 동작하는 go 코드를 작성했다. 이 코드의 결과물은 위에 작성한 webhook 팟에서 동작하게 되는데, 권한을 위해 쿠버네티스의 ServiceAccount, Role, RoleBinding을 함께 작성하였다. Role에는 간단하게 Jobs를 생성만 가능한 권한을 부여했는데, 다음과 같이 작성했다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: hook-namespace
 name: batch
rules:
- apiGroups: ["batch"]
 resources: ["jobs"]
 verbs: ["create"]

이 Role을 RoleBinding을 사용하여 ServiceAccount와 엮은 후 webhook 팟에 ServiceAccount를 제공한다. 이제 webhook 컨테이너에서 client-go의 rest.InClusterConfig()를 호출하면 해당 권한을 가진 쿠버네티스 클라이언트를 사용할 수 있다.

문제점

이렇게 하면 이제 원하는 대로 동작하게 된다. 새로운 브랜치를 생성해서 글을 쓰다가 다 작성한 후 master에 머지하여 이를 커밋한다면 webhook 이벤트가 발생하고, 이 이벤트를 받은 webhook 대몬은 Jobs리소스를 생성하게 될 것이고, Jobs가 정적 컨텐츠를 빌드한다. 하지만 항상 원하는 대로 되는 것은 아니니…

nfs chtimes permission denied

$ kubectl logs -f hugo-static-builder
Building sites … Total in 1231 ms
Error: Error copying static files: chtimes /mnt/css/style.css: permission denied

한 번씩 빌드가 끝난 후 PersistentVolume으로 결과를 복사하질 못한다. 동시 쓰기 문제등으로 인해 발생하는 문제로 추정되는데 같은 볼륨을 사용하지 않도록 해야 하나 고민중이다.

Jobs 히스토리 관리

쿠버네티스 CronJob의 경우 Jobs의 히스토리 관리가 가능한데, Jobs 자체는 그런 관리가 불가능한 것 같다. 완료된 잡이 히스토리에 남아 새로운 잡을 실행할 경우 동일한 이름의 잡이 있으므로 새로 생성되지 않는다. 우선 GenerateName을 사용해서 랜덤한 이름을 부여하도록 하여 이를 우회했는데, 더 간단한 방법이 있을지 찾아봐야 할 것 같다.

이후 할 일

데이터를 백업하는 방법도 강구해야 할 것 같다. dropbox-uploader를 사용해서 간단히 처리할 수 있을 것이다. initContainer를 통해 빌드 전에 처리하도록 해야겠다.