Web
화면 크기에 따른 블로그 이미지 비율 조정
본 블로그는 PC에서 접속하는 환경을 대상으로 작성되었다. 최근 스마트폰을 통해 블로그를 확인해보니, 이미지들의 비율이 블로그 작성시에 고려한 형태와 다른 것을 깨달았다. 웹페이지가 PC에서는 가로가 긴 화면을 통해 보이고, 스마트폰에서는 세로가 긴 화면을 통해 보이는 것이 위 문제의 원인이다. 다양한 디바이스의 화면 크기를 고려해서 웹페이지를 구성하는 것을 [반응형 웹 디자인]이라 한다. 필자는 반응형 웹 디자인까지는 아니더라도, 최소한 블로그에 들어가는 이미지가 화면 크기에 대해 비율적으로 삽입되게 하고자 했다. 확인 과정에서, 다음과 같은 이유로 테마의 short code를 일부 추가했다. [Hugo]에서는 기본적으로 md 서식을 통한 블로그 작성이 가능하다. [md 기반 이미지 사이즈 조절]이 가능했던 것으로 보이나, 필자의 블로그에는 적용되지 않았다. md 기반으로 이미지를 삽입하면, 이미지 크기가 최대로(화면 가로 크기 기준) 설정된다. [Hugo Refresh 테마]에서는 HTML 서식 기반의 블로그 작성을(short code) 제공한다. Hugo Refresh 테마의 figure 태그는 고정 크기로 이미지를 삽입하도록 한다. Hugo는 Static Site Generator로, 화면 크기를 동적으로 얻는 것은 불가하다. Hugo Refresh 테마의 short code (themes/hugo-refresh/layouts/shortcodes 폴더 내부 파일 참조) 중 figure.html은 다음과 같이 작성되어 있다. {{- $original := (.Page.Resources.ByType "image").GetMatch (printf "*%s*" (.Get "src")) -}} {{- $width := printf "%s" (.Get "width" ) -}} {{- $height := printf "%s" (.Get "height") -}} {{- $size := printf "%sx%s" $width $height -}} ... {{- with $original -}} {{- $image := .Resize $size -}} ... {{- end -}} 이 중, figure 태그의 width 또는 height에 “…%“를 할당하지 못하도록 하는 코드는 ‘$image := .Resize $size’이다. 따라서, figure.html을 복사한 figure_per.html 파일을 만들고, 다음과 같이 수정했다. {{- $original := (.Page.Resources.ByType "image").GetMatch (printf "*%s*" (.Get "src")) -}} {{- $width := printf "%s" (.Get "width" ) -}} {{- $height := printf "%s" (.Get "height") -}} {{- $caption := printf "%s" (.Get "caption") -}} {{- $alt := printf "%s" (.Get "alt") -}} {{- with $original -}} {{- $image := . -}} <div class="columns is-centered container"> <div class="column is-full"> <figure> {{- if $caption -}} <img class="rounded-corners" src="{{- $image.RelPermalink -}}" width="{{- $width -}}" height="{{- $height -}}" alt="{{- $alt -}}" > {{- else -}} <img class="rounded-corners" src="{{- $image.RelPermalink -}}" width="{{- $width -}}" height="{{- $height -}}" > {{- end -}} {{- if $caption -}} <figcaption>{{- $caption -}}</figcaption> {{- end -}} </figure> </div> </div> {{- end -}}
블로그 호스팅 환경 및 HTTPS 리다이렉션 설정
[블로그 저작 환경 구축]에 작성한 바와 같이, 네이티브하게 블로그를 호스팅 하기로 결정했다. 시놀로지에서 웹 스테이션을 실행할 경우, web이라는 이름을 가진 공유폴더에 정적 페이지 빌드 결과를 업로드하는 것 만으로 웹 서비스를 제공할 수 있다. 보안을 위해 많은 웹페이지는 리다이렉션을 통해 HTTPS로만 접속할 수 있도록 한다. 시놀로지에는 기본적으로 웹 서비스를 위해 [Nginx]가 설치되어 있으나, 다음과 같은 이유로 [Apache HTTP Server]를 설치하기로 결정했다. [시놀로지에서 Nginx 기반 웹페이지 리다이렉션 설정]를 참조하여 설정한 결과, 리다이렉션이 되지 않고 시놀로지 디스크 스테이션에도 접속이 되지 않았다. 이후, SSH로 접속하여 mustache 파일을 복원해준 결과, 디스크 스테이션에 정상적으로 접속할 수 있었다. 이 결과로, 시놀로지 디스크 스테이션에서 접근할 수 없는 파일을 수정하여 리다이렉션을 수행하는 것은 다른 서비스에도 영향을 미칠 수 있음을 인지했다. Apache HTTP Server는 [.htaccess 파일 기반의 리다이렉션]이 가능하다. Apache HTTP Server를 설치한 후, 웹 스테이션에서 HTTP 백엔드 서버를 바꿨다. (Nginx –> Apache HTTP Server) 다음으로, SSH로 시놀로지에 접속하여, 관리자 권한으로 web 폴더 내부에 .htaccess 파일을 생성한 후에 다음과 같이 작성했다. RewriteEngine on RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 참조한 블로그에서는 역방향 프록시도 설정해주었으나, [역방향 프록시를 적용한 리다이렉션 구조]를 확인한 결과, 구축하는 서비스가 Docker의 컨테이너 내부에서 동작하는 것이 아니기 때문에, 별도로 설정해주지 않았다.
블로그 저작 환경 구축
[블로그 저작 도구 선택]에 작성한 바와 같이, [Hugo]를 기반으로 개인 지식정리 블로그를 작성하기로 결정했다. 개인 PC 또는 시놀로지에 [Docker]를 설치하여 Hugo 기반 블로그 저작 환경을 구축할 수 있었는데, 다음과 같은 이유로 개인 PC에 블로그 저작 환경을 구축하기로 했다. 개인 지식 정리 블로그이기 때문에, 외부에서 포스트를 작성하는 경우가 없다. 정적 페이지 빌드 결과를 시놀로지에 업로드해서 블로그를 호스팅 할 계획이다. 시놀로지에서 [네이티브하게 블로그 호스팅]이 가능하다. 시놀로지 내부 Docker를 실행시켜 호스팅하는 방식은 네이티브하게 호스팅하는 방식보다 웹 서비스 성능이 떨어질 것으로 예상된다. (웹 서비스가 컨테이너 내부에서 동작하기 때문) Docker에서 [xdevbase/hugo-builder] 이미지를 기반으로 컨테이너를 만들었기 때문에, 블로그 저작 환경 구축에 특별한 어려움은 없었다. 다만, 블로그 저작 결과를 임시로 확인하기 위해서, 컨테이너에서 실행되고 있는 서버에 호스트의 웹 브라우저가 접속할 수 있도록 만들어줘야 했다. [컨테이너 내부에 Apache 서버가 실행되는 경우]에는 호스트에서 바인딩된 포트번호로 접속이 가능하다. 하지만, Hugo 서버를 일반적인 명령어 (hugo server -D)로 실행할 경우, 호스트에서 접속할 수 없다. 따라서, [호스트에서 접속 가능하도록 Hugo 서버를 실행시키는 방법]을 참조하여, 다음과 같은 명령어로 Hugo 서버를 실행시켰다. hugo server –baseURL “http://localhost” -p {컨테이너에서 바인딩된 포트번호} –bind {컨테이너의 IP주소} 호스트 웹 브라우저의 주소창에는 다음과 같이 입력해서 컨테이너에서 실행되는 Hugo 서버에 접속할 수 있다. http://localhost:{호스트에서 바인딩된 포트번호}
블로그 저작 도구 선택
최근에 자료 정리를 위해 시놀로지 NAS를 이용하여 파일서버를 구축했다. 시놀로지 NAS에 지식 정리를 위한 블로그 또한 구축하고자 마음먹었는데, HTML, CSS, Javascript 등의 웹 언어를 이용하여 서비스를 구축하기에는 많은 노력이 필요하다고 판단했다. 따라서, 비교적 간편하게 블로그를 구축하기 위한 도구를 다음 두 가지로 분류하여 비교했다. Contents Management System (CMS): WordPress, Shopify, Joomla 등… Static Site Generator: Jykill, Hugo 등… WordPress를 이용하여 블로그를 구축해본 경험이 있는데, 본인이 경험하거나 예상하는 CMS의 문제점을 다음과 같이 정리할 수 있었다. 보안이 취약하다. (WordPress 한정) 예를 들어, 기본 설정상태에서는 (URL)/wordpress/wp-admin.php 페이지로 접근하면 로그인을 시도할 수 있다. 또한, wp-config.php 파일에서는 DB명, 관리자ID, 암호 등을 모두 평문으로 관리한다. 이외에도, 제로데이 취약점이 발견된 경우에 공격이 들어올 수 있다. 플러그인과 소스코드 수정 등으로 위 취약점 일부를 보완할 수 있으나, 개인 블로그를 구축에 많은 노력을 기울이긴 어렵다고 판단했다. 웹 서비스를 위해 DBMS를 사용한다. 잘 관리하지 않으면, 보안이 취약할 수 있다. 시놀로지 OS 업데이트시, DB가 꼬이는 등의 문제로 인해 웹 서비스가 마비될 수 있다. 웹페이지 파일 뿐만 아니라 DB 파일 등도 모두 백업해야 하기 때문에, 백업 과정이 복잡하다. 백업 플러그인이 대부분 유료거나 부분유료이다. 반면, Static Site Generator는 다음과 같은 장점을 가진다. 오픈소스 기반인 도구가 많다. 무료로 제공하는 테마가 많다. 많은 사용자가 기능 추가 방법을 정리해두었다. 마크다운 위주의 컨텐츠 작성이 가능하다. 웹 서비스를 위해 DBMS가 필요하지 않다. 테마에서 제공하는 간단한 컨텐츠 작성 방법이 존재한다. 이외에도, 많은 사용자가 정리한 기능 추가 방법을 사용할 수 있다. 빌드 결과가 정적 페이지들로 이루어져있다. 비교적 보안 관리가 용이하다. 블로그 백업이 용이하다. Github Pages, Netlify 등의 정적 페이지 호스팅 서비스도 활용 가능하다. 위와 같은 분석 결과를 근거로, 블로그 저작에 Static Stie Generator를 사용하기로 했다. Static Site Generator 중 Hugo를 선택한 이유는 다음과 같이 정리할 수 있다. Hugo가 Jykill보다 빌드 속도가 빠르다. (대규모의 웹페이지를 작성하는 것이 아니기 때문에, 저작 도구 선택에 큰 영향은 미치지 않았다.) Hugo와 Jykill의 테마를 확인해본 결과, Hugo Refresh가 가장 마음에 들었다.
