Move to docker
지금 집에 있는 두 대의 mac mini를 이용해서 각각 wordpress와 ghost를 돌리고 있다.
wordpress의 경우 2013년부터 시작한 블로그를 운영하는데 사용하고 있는데, 웹호스팅 회사 몇 군데를 전전하다 몇 년 전부터 집에 있는 mac mini 2009에 MAMP를 이용해서 자체 서버를 이용하고 있었다.
Ghost는 내가 좋아하는 markdown을 기본으로 사용하는 블로그 툴을 찾다 만났는데 지금은 사라졌지만 초기 홈페이지에 있던 멋진 dashboard에 낚여 설치했다. Open source 답지 않고 느린 개발 속도가 이해되지는 않지만, 여전히 markdwon을 제대로 지원하는 흔치 않은 설치형 블로그 툴이라 아직 희망을 버리지 않고 사용하고 있다. 현재는 0.11.2 버전이 공식 stable 버전이고 올해 나올 걸로 예상되는 1.0의 alpha 버전이 개발중이다.
Ghost역시 mac mini 2009에 node.js를 설치해서 그냥(?) 사용하다, docker for mac이 나온 걸 보고 mac mini 2011로 옮겼다. Docker for mac이 mac mini 2009를 지원하지 않는 바람에 -_-;;;
초반에는 official docker image가 없어 다른 사람이 패키징해 놓은 걸 사용하고, 블로그 글 역시 docker container 안에 저장하다 이번에 정비를 하면서 official ghost image를 사용하고, 블로그 글도 container 밖에 저장하는 방식으로 변경하기로 했다.
ghost
$ docker run -d -p 2368:2368 -v ~/Dropbox/Apps/ghost:/var/lib/ghost ghost
ghost의 데이터 파일이 저장되는 기본 위치인 /var/lib/ghost를 실제로는 ~/Dropbox/Apps/ghost위치로 지정하여 사용. 즉 docker를 실행할 때 ~/Dropbox/Apps/ghost 를 container에게 /var/lib/ghost로 인지하도록 하여 하여 container 내부에 ghost 블로그의 정보가 저장되지 않고 host 쪽에 저장되도록 했다. 이렇게 해야 행여 docker instance가 제대로 동작하지 않아도 데이터를 살릴 수 있다. 거기에 데이터 저장 위치를 아예 dropbox 위치로 지정해서 데이터가 자동으로 백업되도록 함.
이제는 kitematic을 사용해서 동작 중. kitematic에서 제공하는 docker hub browsing 기능을 이용해서 ghost 최신 버전으로 업데이트해서 사용 중. Volume 외에 포트 값 등은 모두 기본값을 그대로 사용 중.
wordpress
wordpress는 좀 복잡하다. ghost도 실은 mysql을 사용하면 하나가 아닌 2개의 container를 연동해서 사용해야 하는데 실은 sqlite를 사용해서 간단한 것이라.
wordpress는 ghost와 달리 다음과 같은 복잡성을 해결해야 한다.
- mysql과 wordpress의 2개 container를 연동해야 함
- 기존 MAMP(Mac/Apache/Mysql/PHP)를 통해 운영하던 기존 wordpress의 정보를 import해야 함
- docker로 운영하는 mysql에 저장되는 블로그 정보를 mysql container내가 아닌 host 에 저장하도록 설정해야 함.
- wp-content에 저장하는 upload 파일 역시 wordpress container내가 아닌 외부에 저장하도록 해야 함
이 중 3번째는 mysql container의 volume 옵션을 사용하면 된다.
wordpress의 파일들이 저장될 위치 /var/www/html위치도 host 머신의 `~/Documents/wordpress’를 사용하도록 지정했다.
그리고 나서 RESTART를 선택하면 다음과 같이 wordpress가 실행된다. 왼쪽 console의 복잡한 내용은 모르겠지만, 오른쪽에 나오는 작은 화면을 보면 wordpress를 설치할 때 나오는 화면이 떴다는 것을 알 수 있다.
그런데 이상하게 mysql에 연결이 안되어 결국 kitematic으로 wordpress를 실행하는 것은 포기하고 cli 명령을 이용해서 wordpress container를 새로 생성했다.
cychong:~ cychong$ docker run --restart=always -e WORDPRESS_DB_PASSWORD=blog -d --name wordpress --link mysql:mysql -p 80:80 -v ~/Documents/wordpress:/var/www/html wordpress
3a0a8163171a54152a9281c2638b02046d0b99aaa018242d1b4c08a7511aa579
kitematic으로 설정한 경우 문제가 mysql에 연결이 안되는 것인데 서로 다른 container에서 동작하는 wordpress오 mysql을 연결시켜주는 것이 안되는 듯 한다. cli 명령에는 --link 옵션으로 mysql을 다른 container인 mysql에서 찾아오라고 명시적으로 지정하는 듯 한데 이와 관련된 설정을 kitematic에서 찾지 못했다.
일단 cli로 실행한 후에는 kitematic에서 실행한 것과 동일하게 container에 대한 정보를 볼 수 있는데 여기서도 특별히 mysql container와의 연결에 대한 내용을 찾지 못했다.
wordpress 데이터 이전
이전 wordpress에서 tools / export 기능을 이용해서 post와 pages 등을 모두 export한 후 Wordpress docker에서 import를 하려는데 php에서 허용하는 upload file의 최대 크기가 2MB다. 이전 wordpress에서 export한 데이터 파일은 9.4MB인데…
이런 경우 이전에는 php.ini파일의 설정을 변경해서 파일 크기를 늘리는 방식으로 해결했는데 docker에서는 이 파일 정보가 없단다. 구글링을 해보니 docker 환경이라 해결방법이 다르다.
https://github.com/docker-library/wordpress/issues/10
위 글을 읽어보니 container image는 가능한 default와 동일하게 하고, 서로 다른 쓰임에 딸라 달라지는 부분은 가변부로 처리하게 한다는 것이 정책이라는 거다. base repository라면 당연하다는 생각이 들었다. 그래서 대부분의 사람들이 제안하는 방법 역시 dockerfile을 수정해서 docker를 생성할 때 아래 파일을 넣어주거나 하는 방법이거나 host에 필요한 파일을 만들어 놓고 그 파일을 container가 찾는 위치에 mount되도록 하는 방법이 주 였다.
처음에는 이런 생각을 못하고 그냥 container 내 파일을 만들어 wordpress가 인식되기를 기대(?)했는데 일단 변경 사항이 반영되지도 않고(import 페이지를 화면에 보여줄 때 파일 크기 값을 읽어서 사용할 거라 기대했는데) 반영이 된다 하더라도 container를 종료했다 다시 실행하면 어차피 아래 파일이 사라지고 없을 거라는 생각이 들었다.
# pwd
/usr/local/etc/php/conf.d
# cat > uploads.ini
file_uploads = On
memory_limit = 64M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 600
문제는 이미 만들어진 docker container에 이런 파일 정보를 추가하는 것은 불가능하다는 점. 그러므로 다시 wordpress container를 새로 만들면서 위의 파일 정보도 함께 추가해야 한다.
$ vi /Users/cychong/Documents/wordpress/php_uploads.ini
file_uploads = On
memory_limit = 64M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 600
이제 추가한 파일을 포함해서 다시 docker instance를 생성(이전 wordpress instance를 제거하고)
cychong:~ cychong$ docker run --restart=always -e WORDPRESS_DB_PASSWORD=blog -d --name wordpress --link mysql:mysql -p 80:80 -v ~/Documents/wordpress:/var/www/html -v ~/Documents/wordpress/php_uploads.ini:/usr/local/etc/php/conf.d/uploads.ini wordpress
container를 실행한 후 mount된 volume을 보면 다음과 같다.
이제 다시 wordpress의 import 기능을 선택하면 파일 최대 크기가 2MB가 아니라 64MB로 변경되었음을 확인할 수 있다.
이렇게 해서 기존 wordpress에서 export한 파일들을 무사히 import해 왔는데…
남은 문제
일단 지금까지 확인된 건
- 기존 wordpress에서 wordpress의 첨부 파일 위치 정보가 모두
http://sosa0sa.com/wp/wp-content이런 형식이었는데 이번에는http://sosa0sa.com/wp-content로 되어 버렸네. 아마도 volume mapping하는 부분을 조정(?)하면 될지도 모르겠는데 아예 이번에 모두 정리하는 걸 고민해 봐야겠다. 어차피. URL이 저장된 정보가 xml파일이나 sql 파일 등에 있는 text라.
아니면 wordpress/settings에 있는 wordpress base url(?) 정보를 변경하면 될 지도 모르겠다.
!!! 망했다. 혹시나 하고 위 마지막에 적은 내용을 적용했더니 wordpress자체가 접속이 안된다. wp-config.php파일 등에도 이 정보가 없던데. 그냥 아래 내용까지 고려해서 다시 해결할까? 아님 이참에 ghost로 확 이전?. 이건 ghost 1.0이 나오고 나서 생각해 보고 !!!
- 이건 늘 wordpress를 설치할 때마다 겪는 문제인데… markdown으로 작성한 글들을 보기 위해 jetpack을 설치하는데 jetpack을 설치하더라도 제대로 markdown 파일 형식이 렌더링 되지 않는다. 덕분에 문단 편집도 이상하게 보이고, 그림은 보이지도 않고. 일일이 글 하나 하나 마다 dashboard를 통해 한번 update를 해줘야 제대로 보이는데 이게 유일한 방법인지. 도저히 불가능한 방법이라…. 해결책을 찾아봐야겠다.
벌써 새벽 1:40분이다. 이제 그만하고 자야겠다.
2017/04/07 00:33 update).
간단(?)하게 wordpress container를 삭제하고 새로 설치했다. mysql은 그냥 mysql 정보가 저장되는 디렉토리의 파일을 삭제했다. (mysql container에게 /var/lib/mysql로 매핑한 디렉토리) DB내 저장된 블로그 글들에 지금과 다른 link를 가진 부분이 많이 있고, 위 1번 문제에서 언급한 망한 문제 관련된 내용이 mysql DB내 저장되어 있을 듯 해서 깔끔하게 초기화를 하려고 기존 파일들을 삭제했다.
Wordpress container를 만든 후 한 첫번째 작업은 Jetpack에서 markdown관련 내용을 켠 것이다. 이 작업은 Jetpack을 설치하면 생기는 admin의 Jetpack 메뉴가 아니라 plugins에 있는 Jetpack 의 setting 항목에서 지정했다. 그 다음 activate를 선택했다. 이 순서가 중요한 건지 모르겠다.
그 다음 이전 wordpress에서 export한 xml 파일을 vi를 이용해서 http://sosa0sa.com/wp/를 http://sosa0sa.com/으로 일괄 변경한 후 다시 import했다. 일부 항목은 http://sosa0sa.com/wp/이 아니라 그냥 http://sosa0sa.com/wp로 되어 있는 경우도 있어 이 부분은 따로 찾아서 수정했다.
그리고 나서 다시 웹페이지를 여니 짠. markdown으로 작성한 글도 제대로 보이고(그림도 제대로 보이고) 전반적으로 제대로 동작하는 듯 하다. 이제 이틀 밤에 걸쳐 진행한 wordpress 블로그의 docker로의 이전이 얼추 정리가 된 듯 하다.
참고
mycontainer에 shell로 접속하려면
$ docker exec -it <mycontainer> bash