WordPressをManaged Serviceに移行

これまでは,さくらのVPSを使って運用していました.自分のブログのためだけに仮想マシンのメンテナンスをするのが面倒になったのでKAGOYA JAPANのWordPress専用サーバーに移行してみました.

WordPressのコンテンツ量が多いせいか標準の移行ツールでインポートができず,最終的にはphpMyAdminでダンプしたテーブルをインポートすることで対処しました.MySQLデータベースの wp_postsテーブルとwp_postmetaテーブルをコピーして,wp-content/uploadsにメディアファイルをアップロードすれば正常に動作するようです.

KUSANAGIの速さに驚かされています.自分でチューニングや設定を行っていたことから開放される,従来よりも安い価格で運用できるので満足しています.

Creating Private Wiki by mkdocs + GitLab CI + Heroku

I was looking for private wiki written by Markdown. This post introduces how to create a private wiki by mkdocs + GitLab CI + Heroku.

mkdocs

mkdocs is simple document builder from markdown to html. Used theme is material.

mkdocs.yaml

site_name: Notebook
theme:
  name: 'material'
  language: 'ja'
extra:
  search:
    language: 'ja'

GitLab CI

Putting a config file .gitlab-ci.yaml in root path on git repository.

.gitlab-ci.yaml

build-mdfiles:
  image: python:3.7-alpine
  stage: build
  script:
    - pip install -r requirements.txt
    - mkdocs build
    # test
    - apk add git
    - git clone --depth 1 https://github.com/nulltask/heroku-static-provider.git static-site
    - cd static-site/
    - git config user.email 'koya@koyama.me'
    - git config user.name 'koya'
    - git remote add heroku https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APPNAME.git
    - git pull heroku master
    - cp -r ../site/* public/
    - git add .
    - git commit -a -m `date +deploy_%Y%M%d_%H%m%S`
    - git push heroku master

Setting secret variables on Repository.
Settings => CI/CD => Variables

GitLab Setting

Heroku

Following these steps:

  1. Create Heroku account
  2. Setup Heroku CLI ENV
  3. Create a site on Heroku
    1. heroku create
  4. Optional: If you wish to use BasicAuth, you should run theses commands.
    1. heroku config:set -a=koyawiki USER=YOUR_USER
    2. heroku config:set -a=koyawiki PASS=YOUR_PASS

On Merge Request created

Running CI
CI Console
Build Wiki

asciidocで書いた履歴書をGitLabのCIで自動ビルド

履歴書をMarkdownからAsciidocに書き直したので、この機会にビルドも自動化してみました。方法だけ知りたい方は前半を読み飛ばしてください。

Markdownを使っていた理由

これまでMarkdownで書いていた理由は以下です。

  • Markdownはシンプルな書式でエディタだけあれば書ける
  • Wordは特定の環境でしか編集ができない
  • LaTeXは細かく指定ができるが書式が冗長である

Markdownで感じた課題

一方で、Markdownで感じていた問題は以下です。

  • レイアウトを細かく指定できない
  • Markdownの方言で振り回されることがあった
  • 納得できるPDFビルド環境がない(Pandocもイマイチ)

Asciidocで書いてみて

Markdownより書き方は冗長であるものの、Markdownでは手が届かなかった部分が指定できるので満足しています。

ビルドの環境は以下のDockerイメージで構築しています。

htakeuchi/docker-asciidoctor-jp

履歴書/職務経歴書の書き方は以下の記事を参考にしました。

エンジニアが読みたくなる職務経歴書 – dwango on GitHub

GitLabのCIで自動ビルド

gitlabのCIは .gitlab-ci.ymlで設定を記述します。サンプルが豊富にあったのでLaTeXのサンプルをベースに以下の設定を作成しました。

image: htakeuchi/docker-asciidoctor-jp:latest

build-master:
  stage: build
  script:
    - asciidoctor-pdf -r asciidoctor-pdf-cjk-kai_gen_gothic -a pdf-style=KaiGenGothicJP resume.txt
  artifacts:
    paths:
      - "*.pdf"

GitLabにプッシュするとCIが走ります。右側のBrowseからビルドされたファイルを見ることができます。

ブラウザからビルド結果を確認できます。


たまにPushしてもPendingで止まって5分くらい動かない時がありました。気長に待っているとビルドが終わります。

GitHubでも良かったもののCircle CIの設定が面倒だったので1サービスで完結するGitLabで今回はやってみました。自動化しておくとWindows環境でもブラウザだけあればGitLabのWeb IDEから編集してビルドが出来るので便利だと思います。

asciidoc-py3をFedoraにインストール

Markdownで書いていた履歴書を書き直すためにasciidoc環境をFedoraにインストールしました。asciidocはPython 2系で書かれているらしいので3系の実装を利用していきます。OSの環境は以下です。

$ cat /etc/*release
Fedora release 29 (Twenty Nine)
NAME=Fedora
VERSION="29 (Workstation Edition)"
ID=fedora
...

必要なパッケージをインストールします。

$ sudo dnf install  xmlto libxml

次にasciidocをインストールします。

$ git clone https://github.com/asciidoc/asciidoc-py3
$ autoconf
$ ./configure
checking for a sed that does not truncate output... /usr/bin/sed
checking whether ln -s works... yes
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
$ make
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
python3 a2x.py -f manpage doc/asciidoc.1.txt
python3 a2x.py -f manpage doc/a2x.1.txt
$ sudo make install 
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
/usr/bin/install -c -d //usr/local/bin
/usr/bin/install -c asciidoc.py a2x.py //usr/local/bin/
...
(cd //usr/local/bin; ln -sf asciidoc.py asciidoc)
(cd //usr/local/bin; ln -sf a2x.py a2x)

インストールできたか確認します。

$ which asciidoc
/usr/local/bin/asciidoc

参考サイト:

https://github.com/khenriks/mp3fs/issues/21

Pythonのプログラムをマルチプロセスで動かした

データサイエンスをやっているときに、マシンパワーが発揮できていないことに気がつきました。

1コアしかフルで利用されていない

この原因を調べた所、PythonのGIL(Global Interpreter Lock)が原因であることが分かりました。

ライブラリと拡張 FAQ — Python 3.7.3 ドキュメント
用語集 — Python 3.7.3 ドキュメント

このGILを回避するためにマルチプロセス化をしました。以下のサイトが参考になりました。

Python高速化 【multiprocessing】【並列処理】 – Qiita
multiprocessing — プロセスベースの並列処理 — Python 3.7.3 ドキュメント

具体的にはmultiprocessingパッケージを利用してコードを書き直しました。

変更前のソース

import asyncio
import tqdm
import MeCab
import numpy as np
from multiprocessing import Pool

tab_all = []
# 時間がかかる処理を含む関数
def handle(t):
    strs = mecab.parse(t).split('n')
    table = [s.split() for s in strs]
    table = [row[:4] for row in table if len(row) >= 4]
    if len(table) == 0:
        return
    tab = np.array(table)
    tab_all.append(tab[:,[0,3]].tolist())

if __name__ == '__main__':
    mecab = MeCab.Tagger("-Ochasen")
    f = open('jawiki_small.txt').readlines()
    text = [s.strip() for s in f]
    for t in text:
        handle(t)

変更した箇所

if __name__ == '__main__':
    mecab = MeCab.Tagger("-Ochasen")
    f = open('jawiki_small.txt').readlines()
    text = [s.strip() for s in f]
    with Pool(processes=8) as pool:
        pool.map(handle, text)

実行するとCPUがフルで利用されていることが分かります。(メモリが厳しいので増設したほうが良さそう…)

CPUがフルで利用されている

実行時間を比較したところ 1/3 程度まで削減できたことが分かります。

b-old.pyが変更前、b.pyが変更後のプログラム

Pythonの裏側を理解することの大切さを学びました。