LaTex

WordPressでKaTex記法(≒Latex記法)で入力して数式をレンダリングする 【WP Githuber MD】

WP Githuber MDでLaTex記法を使う


管理画面のオプションにあるKaTexを有効にすればLatex記法が使える

  • ブログ記事の訂正
    以前ブログに書いた記事
    WordPressの記事をMarkDownで入力できる 「WP Githuber MD」 が凄く使いやすい
    では、
    「MarkDownのLaTexやMath表記ができない」
    と書きましたが、
    プラグインの設定で「KaTex」というオプションがあって、これを有効にするとKaTex表記(LaTex・Math表記と同じ)が使えるようになります。
    覚えておくと凄く便利な機能なので、備忘録として記事にまとめます。

    • 表示例

      c = \pm\sqrt{a^2 + b^2}

設定手順

  1. WordPress管理画面を開く
  2. 「WP Githuber MD」がまだインストールしていないならば「プラグイン」メニューからインストールする
  3. 「プラグイン」メニューにマウスカーソルを移動して「WP Githuber MD」をクリックする
    (もしくは「プラグインメニュー」をクリックして「インストール済みプラグイン」から「WP Githuber MD」の「Settings」をクリックする)
  4. 「WP Githuber MD」設定画面から、画面上部にあるタブの「Modules」をクリックする
  5. 「Modules」タブを開いたら、上から5番目あたりに「Katex」というオプションがあるので右端のスイッチを有効にする。
  6. 「Modules」タブの画面の最下段に「変更を保存」のボタンがあるので、これをクリックする。

※ 公式の手順はこちらです
https://terryl.in/en/githuber-md-katex/


入力例

KaTex記法のMarkDown入力

プラグインの公式サイトで紹介されている書式は、インラインコード等で使うエスケープ記号 ` の後にkatexを記述します。

  • MarkDown入力 例1

    ```katex
    <code>c = \pm\sqrt{a^2 + b^2} </code>
    ```
    
  • レンダリング結果 例1

    c = \pm\sqrt{a^2 + b^2} 
  • MarkDown入力 例2

    ```katex
    f(x) = \int_{-\infty}^\infty\hat f(\xi)\,e^{2 \pi i \xi x}\,d\xi
    ```
    
    
  • レンダリング結果 例2

     f(x) = \int_{-\infty}^\infty\hat f(\xi)\,e^{2 \pi i \xi x}\,d\xi

LaTex記法やMath記法のMarkDownでは反映されない

※注意点:latexとmathのMarkDown表記では数式記号に変換できません

  • latex
       ```latex
       e^{i \pi} = -1
       ```
    
  • math
        ```math
        f(x) = \int_{-\infty}^\infty\hat f(\xi)\,e^{2 \pi i \xi x}\,d\xi
        ```
    

編集画面だとmathやlatexの書式でもkatex記法と同じ結果が得られるのですが、本番反映すると数式表記としてレンダリングできないようです。
(※本番反映可能かどうか、WordPressのプレビューで確認可能)

  • そもそもKaTexとは何か?
    LaTexをWebブラウザ上で実現するためのJavascript(ajax)ライブラリの名称です。
    互換性は明確には定義されていませんが、
    KaTex表記 ≒ LaTex表記
    と考えて問題ないようです。
    KaTexのコンポーネントは javascriptとcssに纏められていて、高速かつ軽量にLaTexを表示することができます。
google cloud logo

マルチクラウドを実現する「Anthos」の最低料金は月額1万ドル(100vCPUあたり約105万円)のサブスクリプション+別途vCPU以外のGCP料金が必要

マルチクラウドを実現する「Anthos」は月額1万ドル(100vCPUあたり約105万円)から

Google Next Japan 2019へ参加

  • Anthosの技術セミナー
    Googleが力を入れているGCPの中でも革新的な技術として紹介されている「Anthos」だが、ネット上にユーザーの公式以外の評価記事が見当たらない。
    ちょうどGoogle Next 2019でソリューションアーキテクトが解説する技術セミナーが提供されていたので参加したのだが。紹介されたのは公開済みの概要と技術スタックの説明だけで、動作デモや具体的な事例紹介はなかった。
    結局のところGoogle Nextは営業トークに終始している印象があり、具体的な情報はUSの発表資料をもとに調査したので備忘録としてまとめておく。

  • 公式のサービス説明
    https://cloud.google.com/anthos/

    • 移行とモダナイゼーション
      色々書かれているが、オンプレや他社クラウドを統合できるというのはGKEに乗せることが前提になる。

    • ポリシーとセキュリティを大規模に自動化する
      AWSでもGCPでもクラウドサービスのセキュリティ周りは、煩雑で管理が複雑になりやすい。本当に自動化が可能でカジュアルに利用できるなら試してみたかった。
      そもそも契約時の免責があるので自動化したポリシーをGoogleが担保してくれないのだと思うが。GKEに集約するからセキュリティとポリシーを自動化とする扱いなのか(半自動化)、別の管理レイヤー(Anthos Config Management?)で完全な自動化が可能なのか。

    • Youtubeの解説動画がシンプルでよい
      Google Cloud Anthos - Explained in 4 Minutes
      https://www.youtube.com/watch?v=HMWIt9pI3ps

Anthosの料金

  • 最低でも1年契約で月額1万ドル=年間12万ドル必要
    (※別途GCPの従量料金も発生する+100vCPU消費毎に1万ドル)
    https://cloud.google.com/anthos/pricing
    従量制を公表している他のGCPと違って、Anthosの料金は1年契約が前提でかつ月額料金での支払いが必要になる。(ちょうどGoogle Analytics Preminumと同じ契約条件と月額料金になる)
    さらに年間契約の前提に加えて100 vCPUあたり1万ドルという従量料金がベースになり、料金のvCPU以外のストレージやネットワーク等のサービス費用は別だと明記されている。

マルチクラウドを提供する「Anthos」の長所と短所

長所:GCP(GKE)で統合管理ができる

  • GKEは素晴らしいサービスだが
    サービス紹介を参考にすると「移行とモダナイゼーション」「セキュリティの統合と自動化」2点の機能はGKEでの統合管理に強みがあるのだとわかる。
    ただ、他環境をGKEへマイグレーションして統合管理するコンセプトで完結してしまうのなら、競合(特にAWS)は対抗サービスを安価に提供するのではないだろうか。

短所:コストパフォーマンスが悪い

  • 年間契約で月額1万ドル=最低でも年額12万ドル+GCP費用
    マルチクラウドを提供する「Anthos」だが、サービス紹介や資料から料金やコストパフォーマンスの解説が殆ど掲載されていない。

    • 100vCPUあたり1万ドル掛かる
    • AnthosのvCPU以外のGCP料金は別途必要
    • 一ヶ月内に100vCPUを消費すると100vCPU/1万ドル単位で追加費用が必要
  • ITベンダ各社との提携(NTTCommunication・HP・VMWare等)
    Anthosの発表後に取り扱いベンダとしてNTTCommとの提携がニュースになっていた。Googleのサービスをベンダ経由で提供するということは、何かある都度ベンダに金銭を払う必要があるため非常にお金がかかるサービスだという事がわかる。そして金を払わない場合は自社のシステム環境でさえ情報が得られない可能性が高い。

Anthosに期待していたもの

  • 個人的にAnthosに期待していたことは以下の3点だったのだが、今のところAnthos(GCP)では実現できないことがわかった。

    1. GKEのように安くて安定している
    2. ポリシーとセキュリティをカジュアルに自動化できる
    3. オンプレや他社クラウドもGKEへ簡単に統合管理できる

マルチクラウドの実現は、地道にAWS・Azure・GCPを比較評価しながら勉強したほうが良さそうだ。

MarkDown

WordPressの記事をMarkDownで入力できる「WP Githuber MD」が凄く使いやすい

WordPressの記事をMarkDown入力

WordPressでMarkDown入力できるエディタを探していると「WP Githuber MD」というプラグインを見つけた。
Markdownエディタの中でも動作が安定していて、使いやすくて、完全なOSSで提供されているため利用する敷居は低いと思う。
ただし、機能として提供されているhtmlからMDへのコンバートが不完全だったりするので、使い方に注意する必要があると思う。

使っていて便利だと感じた点

  • 軽量で安定している
  • Markdownで記事を入力しながら、htmlの出力をプレビューできる
  • htmlを混在させた記述も可能なので、細部はhtmlで書くことができる
  • 完全な無料OSSで有料プランへの誘導等が仕込まれていない

エディタ名 使いやすさ 安定 メモリ消費 プレビュー MarkDown GUI編集 完全OSS
Gutenberg
Elementer
Classic Editor
WP Githuber MD

このテーブル表記もMarkDownで表現できている。

使用イメージ

※gif画像はgithubから転載

https://github.com/terrylinooo/githuber-md

注意点

  • htmlからの変換"Html to Markdown"は適用しないほうがいい
    • 成功することもあるが、変換に失敗すると文章全体が消える
  • 行間を開けないとMarkDownを認識しない場合がある

    • 下記では識別しない場合がある

      本文テキスト。
      ## 表題
      - 記事リスト

      以下のように改行を1つ入れるとよい

      本文テキスト。
      
      ## 表題**
      - 記事リスト
    • 他のMarkDownエディタでも行間を空ける仕様が多い

  • リスト表記(li相当)の記号がインラインのプレビューで表示されない場合がある
    • WordPressのエディタ内でリストのdotとかCircle表記が見えない場合がある
    • 全体のプレビューで表示すればリストのdotやCircleを確認できる。
  • 改行がうまく入力できないときはhtmlの改行
    • 本来のMarkDownだと \n(スペース+改行)で改行になるが、githuber-mdでは反映されなかった
    • MarkDown以外にHtmlも反映されるので
      で改行にしたほうが手間が少ない
    • 残念ながら今のところTex記法は対応していないらしい

WordPressのようなエディタで文章を書くと段落が崩れてやる気をなくすことが多いのだけれど、MardDownだときれいに整形できる。

落ちないWebサイト

落ちないWebサイトの構築 【WordPressを静的サイト化する】

落ちないWebサイトの構築

先日、このサイトとは別に運用しているWordPressの1つが不安定になってしまい、不具合の原因を調べたところMySQLのアップグレードが原因でutf8mb4の文字コード指定に異常が発生していた。
復旧のために対象DBの文字コードの異常を修正する必要があったので、一度Dumpしてからリストアを実行し復旧させた。
復旧は軽微な対応で済んだのだけど、今後は手間をかけずに、サーバーレス的な継続的な改善ができるようにしたい。

今回の課題

  • 現行のWordPressサイトの本番環境を手間をかけずに安定運用させる
  • まず最低限の機能で構築
  • 保守コスト優先、WordPressの管理画面をベースにする
  • CloudFrontでホスティングすることでサーバレスな機能を運用する
  • 構築後に検索やSEO対策の機能を実装する
  • WordPressなのでセキュリティリスクが発生しないように注意する

実現方法の候補

  • StaticPress
    日本人の開発者が作ったWordPressのプラグイン。
    オリジナルは3年以上メンテナンスされていないため脆弱性の懸念がある。古くからあるプラグインのため、脆弱性やバグ対策のソースコードも公開されている。
  • WP2Static
    元はSimpleStaticという名前だったWordPressのプラグイン。完全なOSSで公開されていて自由なカスタマイズが可能。WP CLIにも対応しているので自分でWordpressを管理できる人にはとても都合がよい。CDNに乗せれば高機能かつ安定運用が可能になる。
  • Hugo
    Go言語にHugoというフレームワークがあり、高機能なhtmlテンプレートエンジンとして利用が可能。CDNに乗せれば格安で高機能かつ安定運用が可能になる。ただしWordPressの機能やノウハウを捨てることになる。
  • Shifter(サービス)
    Wordpressを静的サイトで公開するホスティングサービス。価格も良心的。ただしCDN等へ配置してバックエンドをカスタマイズしたい場合は2度手間になってしまう。
  • kusanagi(サービス)
    WordpressをフルカスタマイズしたOSSソリューション。日本のベンダが提供しているためサポートも信頼できるがシステムとして導入すると価格が高い。(1インスタンス15万円)
    レンタルサーバで提供されているkusanagiを利用する場合はホスティング費用だけでよいのでコストパフォーマンスは悪くない。ただ、どの程度サポートされるのか、プラグインやテーマは全て利用可能なのか、自前でWordPressのソースやnginxもカスタマイズ可能なのか、WPとKusanagiの二重運用になりコストが高くなる。
    元がWordPressなのでGPLとしてOSS版も提供されているが、最適化のためにNginxからビルドする前提になっておりWordPressと別のノウハウも必要になるため運用コストがかかる。良くも悪くもWordPressのカスタマイズバージョン。
  • k8s
    WordPressの勉強会でREST-APIでヘッドレス運用してk8sに乗せてCDN配信する話を聞いた。CDN配信のソースをk8sへデプロイしてCIは外部のSaaSへお任せというのは贅沢で良いけど、本番が静的ページでCDNに乗せるならk8sにする意味はあるのか(S3やGCSで良いのでは?)、Pod上で静的ページだけではなくvueでREST-APIと通信しているならWordPressのような記事ベースのコンテンツでは脆弱性が含まれるのではないか。色々と疑問が残る。

WP2Staticを利用する

  • 今回の課題解決はWordPressのサイト全体を静的なhtmlに変換してくれるWP2StaticというWPプラグインを利用する。

  • ■採用の理由

    1. WordPressの機能を引き継げるので、サイトのテンプレートデザインや面倒なSEOの設定を管理しやすい
    2. プラグインのフル機能がOSSで提供されているため問題があれば改修できる
    3. WP管理画面からの操作だけでなく WP CLIにも対応しているためバッチ処理で管理できる
    4. 本番サイトを静的ページで運用できるため大部分のセキュリティリスクを回避できる
    5. AMPやSEO用のメタタグ等、多くのWordPressの便利機能を利用することができる

アーキテクチャ

  • 現在のWordPress環境はSTG環境として運用する
  • 本番サイトはAWS S3に配置してCloudFrontで配信する
  • 自動化を前提にWP CLIで運用できる構成にする
  • クローリングは可能な限りWP2Staticで行う(WP CLIで制御可能なため)
  • WP2Staticではトップページ以外のクローリングができないため、ページネーションのインデックスは独自スクリプトを構築する
  • サイト内検索はいったん排除する(後日にJavascriptのサイト内検索を設置する。検索URLのみ動的サーバへ転送することもできるがセキュリティリスクを避けて本番はサーバレス構成で運用する)
  • Lambda Edgeの処理が可能になるのでnodejsで動的処理をする
  • 汎用的な顧客の問い合わせ機能や予約フォームは、CRMやMA,GoogleForm等で提供することでセキュリティリスクを抑えて機能を提供し、かつ一元管理が可能になる
  • 顧客対応用の恒久的な問い合わせページはMauticを利用する
  • アンケートや不特定多数からの問い合わせ、予約受付等はGoogle Formを利用する
  • マイクロサービス(フロントエンドやバックエンドのAPI連携等)は、Lambda Edgeを利用する

WP2Staticの課題と対策

  • 日本語URLのクローリングとファイル出力

    • 対策
      パーマリンクを記事IDベースに変更
  • ページ分割された過去記事(pagenation)のクローリングが不完全で出力されない

    • 対策
      毎回すべての記事をページングするスクリプトを別途作成しておく
      ※1度に10件以上の投稿をしなければトップページのクロールだけで記事を正しく出力できるが、10件以上登録したときにページングの整合性があわなくなる可能性があるため対策を設計しておく
  • 投稿の属性(カテゴリ、タグ、日付)を含めたURLが出力されない

    • 対策
      前項の対策と同じようにWP CLI等で全ての記事を出力できるスクリプトを作成しておくとよい。
  • サイト内検索の機能が提供できない

    • 対策
      ※aを検討中
    • a. mecab等で検索インデックスを構築して、本番の検索フォームと紐付ける
    • b. STG環境のWordPressのAPIとPOSTで通信させる
    • c. AWS Cloud Serarch等のサイト内検索用のWebサービスを契約する(コストが高い)
  • 投稿記事(single)のAMPが出力されない

    • 対策
      WP2Staticへ明示的に"/amp"もしくは"?amp"のページを登録するとAMP用の静的ページが生成される

まとめ・雑感

  • 「WP2Static」で構築したサイトは「AMP」プラグインのページ出力も正常に機能している
  • 「WordPress ping Optimizer」は残念ながら正常に機能しなかった(元サイトのURLをベースに通知してしまう)
  • CloudFrontへ配置したサイトをLighthouseで計測すると、初回実行Performance98、2回目以降はPerformance100になった。(CDN配信なので2回めから早い)
    元が軽量なページなので高速化していないが静的サイト化で悪化するようなことはなかった。

Ubuntu18.04でのRedmineアップグレードについての備忘録

仕事やプライベートでRedmineを使ってタスク管理・ナレッジ管理をしていて、Ubuntuのパッケージを利用してRedmineを運用している。
最近、Redmineの環境をUbuntu16.04から18.04にアップグレードした際に、Rubyのバージョン依存での不具合や注意点、Passengerのインストールのつまずきがあったので、対策等をメモしておく。

■Rubyの罠

Redmineの構成や利用しているgemパッケージはそれほど変わっていないようだが、aptパッケージとgemパッケージの依存関係が競合してインストールに失敗する場合がある。

上のようにRMagickのパッケージをインストールするときに関連するライブラリ(パッケージ)がインストールされていないと、インストールを失敗したあとで環境の修復にも時間がかかる。
また、rbenvを使ってrubyのバージョン管理をしている場合は、aptパッケージのrubyと競合するので、少なくともroot権限のrbenvは削除してaptパッケージのrubyを参照するようにしておいたほうがいい。(ユーザー権限のrbenvは残っていてもアップグレードできた)

対策:

  • rmagick関連のパッケージをインストールしていないクリーンな環境で、必要なライブラリ関連のパッケージが全てインストールした状態にしてアップグレードする。もしくは、ソースコードから必要なパッケージを1つずつインストールする。
    条件に合わずにインストールエラーが発生するとRedmineのインストールが完走しなくなり、後述の「aptの罠」にもハマってしまう。

  • 具体的な対策は、gemのインストール(bundle insall ~)の前に必要なaptパッケージのライブラリが揃っているとエラーにならないようだ。以下のパッケージ全てインストールすると大丈夫だと思う。

sudo apt install ruby-fastimage ruby-mini-magick ruby-oily-png
sudo apt install imageinfo imagemagick imagemagick-6-common imagemagick-6-doc imagemagick-6.q16 imagemagick-6.q16hdri imagemagick-common imagemagick-doc
sudo apt install libchart-gnuplot-perl libgraphics-magick* libgraphicsmagick* libmagick*
  • 前述の対応でubuntu側のパッケージが揃うはずだが、環境依存でGemfileでインストールするパッケージのバージョンがあわない場合がある。自分の場合はGemfileに記述されたnokogiriのバージョンがbundle installでは解決できなかった。
    同じ不具合にあった場合は"bundle install"の前に個別にバージョン指定してnokogiriをインストールしてから"bundle ~"すれば解決することができた。
gem install nokogiri -v "1.8.1"

■aptの罠

上のRMagick等のgemの依存関係でRedmineをアップグレードするとaptの途中で止まってしまう場合がある。aptのインストールが途中で失敗すると、他のパッケージをインストールしようとするときにもRedmineも再インストールすることになり、全てのパッケージのインストールに失敗する。

対策:

aptのエラーを修復するためにはパッケージをインストールする都度Redmineのパッケージを削除するか、apt-get upgradeからRedmineパッケージを除外して関連パッケージをインストールしてから再度有効化する必要がある。

参考:apt-get upgradeから特定パッケージを除外する
https://qiita.com/strsk/items/c933a661c077a666073a

■Passengerの罠

Passengerをアップグレードするときにautoオプションでインストールしたのだけど、autoオプションではPassenger専用のnginxのソースビルドが導入されてしまい、動作させるための設定に苦労した。
Passenger版のnginxはディストリビューション版とは異なる最低限のコンパイルオプションでビルドされるため、Passengerを含まないApacheやNginxの設定では正常に動作しない。(自動でインストールされたPassengerの設定を確認してから気がついた)

対策:

  • Passenger版のnginxは利用せずにUbuntuのnginxパッケージを再インストールする
sudo apt install nginx-core nginx-full --reinstall
sudo apt-get install -y dirmngr gnupg
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7
sudo apt-get install -y apt-transport-https ca-certificates

■Permissionの調整

前バージョンまでRailsとPassengerの連携を重視してApacheを利用していたが、最近はnginxのほうが慣れて安心できるためnginxへ変更した。このときに各所でpermissionの調整が必要になったので、これもメモしておく。

対策:

  • ・apache2ユーザーの権限 "www-data"をnginxユーザーへchownする
    パッケージでインストールされているディレクトリ("/usr/share/redmine"等)はエイリアスが多用されているので、"chown nginx:nginx -rf"のようなサブディレクトリ一括でのパーミッション変更ができない場合があるので注意が必要。

  • Web公開用のディレクトリだけでなく、起動スクリプト(/etc/init.d/nginx )とデーモン(/etc/systemd/system/multi-user.target.wants/nginx)にもユーザー指定の記述があれば変更する必要がある。

■まとめ

Redmine3.4+nginxへアップグレードしたことによる利点:

  1. パフォーマンスが大幅に向上した
  • Redmine+Apache2+Passengerでは、チケットの投稿に数秒かかる場合があったのだけど、Redmine+nginxに変更してから1秒以内に投稿できるようになった。
    メモリ効率も向上していて、Apacheではメモリ使用量が200MB以上専有されていたのだけどnginxでは100MB以内になった。
  1. 安定した
  • 1のパフォーマンスと同じ原因だと思われるが、Apacheで運用するRedmineではチケットを投稿したときに(数ヶ月に1度程度)原因不明の503エラーが発生していた。エラーが発生したときはApacheの503エラーしかログに残らず再現性がなかったため不具合回避ができずにいたのだけど、アップグレード(nginxに変更)してからは1度も発生しなくなっている。
  1. 古いバージョンのRubyを捨てることができた
  • rubyのパッケージはバージョン依存が強いものが多くて互換性問題が運用リスクとして抱えることになる場合がある。今回アップグレードしたRedmine3.4はrubyを2.5以上に統一することができたので自分にとって大きな利点だった。特にAWSとの連携では、Lambdaがサポートするrubyが2.5以上必須なので運用上なにかと有用である。

Redmine3.4へのアップグレード対応について、反省点と今後のリスク:

  1. 時間の消費
  • Ubuntuで利用するRedmineパッケージのアップグレードは、OS標準のオプションだけで解決できていた為30分~1時間もあれば対応できていたのだが、今回はパッケージの競合等で手作業での調査と対策が必要になり、不具合調査に1日+手順書作成に1日、実施に半日程度かかった。
    振り返りとしては、Dockerや新規のAWSインスタンスを新規で立ち上げて、Redmine18.04用のRedmineを構築してから、旧環境とDBを移行したほうが安全で早く対応できたように思える。
  1. 外部パッケージの導入
  • Ubuntuの標準リポジトリではnginx対応のPassengerが配布されていないため、外部リポジトリからPassengerをインストールしたが、今後の運用管理でリスクになる可能性がある。