도커 컴포즈(Docker Compse)로 워드프레스 블로그 만들기

오랜전부터 운영해오던 블로그가 한번씩 죽을때마다 백업을 신경쓰지 않아서 이미지들을 죄다 날리곤 했었다. 이 문제 때문에 검색을 좀 해봤더니 Docker 볼륨과 Git 을 통해 손쉽게 백업 문제를 해결하고 있었다. 왜 이 생각을 못했지? ㅎㅎㅎ 머리가 굳었어!

일단 옆지기 블로그(janeisyoung.com)를 깃헙 페이지에서 해방 시켜주기로 했다.

서버 구성

AWS EC2 인스턴스 2개를 이용해 하나는 Docker 호스트로 쓰고 있고 다른 하나는 데이터베이스 전용으로 쓰고 있다. 따라서 지금부터 쓰는 글은 데이터베이스가 원격지에 있다는 가정하에 쓰는 글이다.

데이터베이스 설정

원격 서버에 SSH 접근한 후 블로그용 데이터베이스를 생성하고 이 데이터 베이스만 접근 가능한 유저를 만들어준다.

// 루트 권한으로 MySQL 로그인
> mysql -u root -p

// DB 생성 
mysql> create database janeisyoung;

// 유저 생성
> create user janeisyoung@'172.31.%' identified by '<PASSWORD>';

// 권한 지정
> grant all privileges on janeisyoung.* to janeisyoung@'172.31.%' identified by '<PASSWORD>' with grant option;

// 권한 확인
> show grants for 'janeisyoung'@'172.31.%';

참고로 데이터베이스로 쓰고 있는 인스턴스는 AWS EC2 간에 172로 시작하는 내부 IP를 통해서만 접근하도록 제한된 상태다.

도커 컴포즈 설정

version: "3.3"
services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8889:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: <DB_HOST_IP>:<DB_PORT>
      WORDPRESS_DB_USER: janeisyoung
      WORDPRESS_DB_PASSWORD: <PASSWORD>
      WORDPRESS_DB_NAME: janeisyoung
    volumes:
      - ./html:/var/www/html

도커 호스트 서버에 접속해서 docker-compose.yml 파일을 만들고 실행한다.

> mkdir janeisyoung
> cd janeisyoung
> docker-compose up -d

컨테이너가 제대로 만들어졌는지 확인해보자.

> docker ps -a
CONTAINER ID  IMAGE             COMMAND                 CREATED        STATUS        PORTS                 NAMES
5c204cc3f0a8  wordpress:latest  "docker-entrypoint.s…"  3 minutes ago  Up 3 minutes  0.0.0.0:8889->80/tcp  janeisyoung

Nginx 멀티 호스팅

도커에는 이미 여러 컨테이너 서비스가 올라가 있다. 마찬가지로 이번에 추가한 블로그도 그 중에 하나로 8889번 포트를 통해서 도커 호스트와 통신한다. 그리고 도커 호스트로 들어오는 모든 요청은 Nginx 를 통해서 각각의 컨테이너 서비스로 연결된다.

file: /etc/nginx/conf.d/janeisyoung.com.conf
---- 
server {
  listen 80;
  server_name janeisyoung.com;

  location / {
    proxy_pass http://127.0.0.1:8889;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $http_host;
  }
}

이제 Nginx 를 재시작한다.

> sudo systemctl restart nginx.service

도커 볼륨을 이용한 데이터 백업

앞에서 설정한 컴포즈를 실행하면 연결 해둔 볼륨(html 폴더)이 생기는데 이 폴더는 컨테이너 안쪽의 워드프레스 루트 폴더와 연동된다. 따라서 업로드한 모든 이미지와 설치한 테마, 플러그인 등등 모든 파일이 이 곳에 저장된다.

이제 도커 컨테이너가 어떤 이유로 죽더라도 내가 쓴글은 안전하게 DB에 저장되고 업로드한 모든 이미지는 볼륨 폴더에 저장되어있으므로 언제든 똑같이 되살릴수있다. 올레~ 그리고 이 볼륨 폴더를 git 연동해서 GitHub에 주기적으로 push 하면 서버를 이전할때도 손쉽게 이전할수있다.

Optimization React rendering

랜더링 최적화는 어떻게 하나?

1차적으로 불필요한 랜더링을 먼저 막습니다. 불필요한 랜더링이란 화면에 반영되는 데이터가 동일하거나 다른 화면에 가려져 랜더링이 아예 필요 없는 경우를 말합니다.

Props로 넘겨지는 데이터가 동일 할때 React.memo 를 사용하는 방법은 두 가지가 있습니다.

1. 기본 탑재된 비교 알고리즘을 쓰는 경우

React.memo(컴포넌트)

기본 알고리즘을 쓰는 경우는 Props로 넘어오는 값들이 이뮤터블임을 전제로 합니다. 뮤터뷸 객체가 넘어오면 당연히 이 전략은 통하지 않습니다. 여기서 신경써야하는 것들이 바로 핸들러나 콜백 함수들인데, JS에서 함수는 뮤터뷸한 객체라서 useCallback 으로 일일이 감싸서 캐시(메모이제이)하지 않으면 효과가 없습니다.

그렇다고 항상 useCallback 쓸 필요도 없습니다. 캐시 비용도 비용이지만 매번 콜백 함수를 감싸는 귀차니즘도 만만치 않기 때문에 그 비용이 오히려 비효율일 경우가 많습니다. 이럴때는 비교 로직을 커스텀 하는게 더 효과적 입니다.

2. 비교 알고리즘을 커스텀 하는 경우

React.memo(컴포넌트, 비교로직함수)

비교로직을 커스텀 할경우엔 콜백함수를 useCallback 으로 넘기든 넘기지 않든 랜더링에 필요한 요소들만 선택적으로 찾아서 랜더링을 결정합니다. 따라서 메모된 값을 쓰고 싶을 경우엔 true, 새로 랜더링을 할 경우엔 false를 비교 함수에서 반환합니다.

최적화 우선순위

모든 컴포넌트를 다 useCallback 으로 감싸거나 React.memo로 감쌀 필요는 없습니다. 병목 지점을 먼저 찾고 필요한 곳 위주로 처리하면 됩니다.

예를들어 아래와 같은 구조에서 최상위 Root 컴포넌트가 랜더링되면 나머지 A~F 컴포넌트가 줄줄이 랜더링 됩니다. 이때 A가 한번 랜더링 되면 F 같은 리스트 아이템들은 수없이 많이 랜더링 됩니다.

  ---Root
      |--- A
           |-- B ( List )
               |-- F
               |-- ... N 개의 F 
               |-- F
           |-- C
      |-- D

즉, 위와 같은 구조에서 F 컴포넌트가 제일 먼저 최적화 대상이 됩니다.

극단적인 랜더링 최적화 (한번만 그리기)

가끔은 컴포넌트를 딱 한번만 그리는 경우도 있습니다. 예를 들면 고정형 네비게이션바 같은 경우엔 Props를 주입받지만 화면을 그리는 요소에 영향을 주지 않기 때문에 이런경우엔 극단적인 선택을 할수있습니다.

export default memo(NavigationBar, () => true);

클로저 변수와 함께 콜백 함수 메모하기

   1번
   const 핸들러함수 = useCallback(()=>{
         const currentItem = items[currentIndex];
      //  currentItem 처리
   },[currentIndex])

    2번 
    const 핸들러함수 = (currentItem) => {
         // currentItem 처리....
    }   

    <List>
        {for item in items 
            return <ListItem item={item} onPress={핸들러함수}>
         }
     <List>

1번처럼 useCallback 함수를 사용해 클로저 변수를 함께 패키징 할 경우 핸들러 함수는 currentIndex 값에 따라 매번 다른 함수가 만들어집니다.

그리고 이것을 <ListItem> 컴포넌트의 프로퍼티로 넘기기 때문에 <ListItem> 컴포넌트의 메모 전략은 매우 단순하게 가져갈 수 있습니다.

export default memo(ListItem);

물론 currentIndex 갯수 만큼 메모하는건 그만큼 약점입니다.

반대로 useCallback 을 쓰지 않을 경우에는 당연히 ListItem의 최적화 전략이 달라져야합니다.

export default memo(ListItem, (prev: Props, next: Props) => {
  return prev.language === next.language;
});

그리고 2번처럼 핸들러 함수에 넘겨받은 값을 그대로 같이 반환해야합니다.

function ListItem(props){
  const { item } = props;

  return( 
     <TouchableOpacity onPress={() => onPress(item)}>
       // 블라블라...
     </TouchableOpacity>
  )
}

주의! 최적화 전략은 케바케라서 상황에 따라 적절히 취사 선택하려면 잘 알아야한다. 암튼 간만에 회사 일 하다가 긴 PR을 올려서 그대로 블로그에 옮겨 왔음.

워드프레스 업그레이드 관련 정리

해커들의 채굴 공격에 한바탕 홍역을 치른 뒤에 워드프레스 관리에 좀더 신경을 쓰고 있다. 그동안 내가 고생했던 이야기는 아래 링크를 참고하자.

아무튼 이런 저런 일들을 겪으면서 발생한 문제를 해결하다보니 이번에는 그동안 잘 되던 자동 업그레이드가 안되는 문제가 생겼다.

그동안 몰랐던 자동 업그레이드의 실체

자동 업그레이드는 2가지 기능을 한다. 중요한 패치버전을 자동으로 설치하는 기능과 사이트에서 손쉽게 원하는 플러그인과 테마를 클릭 한방에 설치해주는 기능이다. 특히 두번째 기능은 수동으로 파일을 업로드하는 수고로움과 귀차니즘을 줄여준다. 그리고 이 자동 업그레이드는 아마도 워드프레스 3.2 부터인가 자동으로 적용됐다. 지금은 4.9.5 버전이니까 한참 옛날일이다.

아무튼 내가 10년전 수동으로 모든 플러그인과 설치버전을 관리하다가 3.2 버전으로 넘어오면서 이런 편리함에 다른 블로그 툴로 못 넘어가고 워드프레스에 정착을 했던것 같다. 아무튼 그동안 잘 되던 원클릭 업그레이드가 이제 더이상 안되는 문제가 생겼다! 뚜둥!!

갑자기 FTP 권한이 틀렸다고 다시 입력 하랜다. 내가 ftp 데몬을 내렸나 싶어서 vsftp 데몬을 설치하고 잘되는것도 확인했는데, 여전히 같은 문제가 반복됐다. 원인을 도저히 못 찾다가 우연히 FTP를 우회하는 방법을 찾았다.

그냥 wp-config.php에 다음 한줄을 추가하면 FTP 설정 없이도 업그레이드가 된다.

define('FS_METHOD', 'direct');

즉, 이 말은 PHP가 직접 파일을 읽어다가 내 서버에 쓴다는 얘긴데, php가 파일이나 폴더를 생성 하려면 권한이 필요하다. php 는 당연히 nginx 위에서 동작하기 때문에 nginx 그룹 권한에 쓰기 권한도 넣어줘야한다.

아마 갑자기 원클릭 업그레이드가 안된 이유도 사실은 폴더권한을 775에서 755로 대폭 축소해서 나타난 문제였을 것이다.

업그레이드와 관련된 폴더

워드프레스 버전을 업그레이드 하려면 아래 폴더에 권한을 일단 775 이상으로 올려줘야한다.

  • wp-admin
  • wp-includes

그리고 플러그인이나 테마를 업그레이드 하려면 wp-content 폴더의 권한도 올려줘야한다. 업그레이드가 끝나면 올려줬던 폴더의 권한은 다시 낮추는걸 추천한다.