Windows 10 HomeのKUSANAGI Runs on DockerでWordmoveの結末は(前編)

いろいろ脱線につぐ脱線でしたが、いよいよ、ローカル環境に構築したDockerコンテナ内のWordPressでWordmoveを試していきたいと思いますが、タイトル通り、前編で解決できてないので、後編に続く予定です。

Msys2のbashでdocker-machineコマンドが、み、見つからない!

f:id:ts0818:20170530174823j:plain

いきなり最終回...と言いたいところですが、前回この問題については様々なサイトで解決策が提示されていた気がします。 

msys2を更新したらPATH設定が消えた?? - foohogehoge's blog

Kayns Lab. 【MSYS2】環境変数の設定

Windows に Unix ライクな開発環境を構築してみました

ffmpegをwindows向けにビルドした方法 - Qiita

この方法を試してみて駄目だとかなり絶望的ではありますが。

⇩  下記サイトによると、MSYS2_ARG_CONV_EXCLってのも設定できるようです

MSYS2小ネタ集 - Qiita

MSYS2_ARG_CONV_EXCLまで考えると、かなり複雑になりそうな感じです。

 

Msys2のbashWindowsのパスを認識させる

今回は、profileの設定に追加していく形にしました。

C:¥msys64¥etc¥profile をAtomなどで開いて、MSYS2_PATH_TYPE=inherit を追加(case "${MSYS2_PATH_TYPE:-minimal}" in ~の部分より上に記述)し保存します。

# To the extent possible under law, the author(s) have dedicated all
# copyright and related and neighboring rights to this software to the
# public domain worldwide. This software is distributed without any warranty.
# You should have received a copy of the CC0 Public Domain Dedication along
# with this software.
# If not, see <http://creativecommons.org/publicdomain/zero/1.0/>.


# System-wide profile file

# Some resources...
# Customizing Your Shell: http://www.dsl.org/cookbook/cookbook_5.html#SEC69
# Consistent BackSpace and Delete Configuration:
#   http://www.ibb.net/~anne/keyboard.html
# The Linux Documentation Project: http://www.tldp.org/
# The Linux Cookbook: http://www.tldp.org/LDP/linuxcookbook/html/
# Greg's Wiki http://mywiki.wooledge.org/

# Setup some default paths. Note that this order will allow user installed
# software to override 'system' software.
# Modifying these default path settings can be done in different ways.
# To learn more about startup files, refer to your shell's man page.

MSYS2_PATH="/usr/local/bin:/usr/bin:/bin"
MANPATH='/usr/local/man:/usr/share/man:/usr/man:/share/man'
INFOPATH='/usr/local/info:/usr/share/info:/usr/info:/share/info'
MSYS2_PATH_TYPE="inherit"
case "${MSYS2_PATH_TYPE:-minimal}" in
  strict)
    # Do not inherit any path configuration, and allow for full
     .
     .
     .
     途中省略

f:id:ts0818:20170530181349j:plain

ConEmuを再起動して、{Bash}の{Msys2-64}を選択します。

f:id:ts0818:20170530181350j:plain

無事、WindowsでインストールしていたライブラリなどへのパスがConEmuのbashから参照できました。

tmux というものを使う場合ConEmuでは厳しいようです。

MSYS2の端末ソフトをConEmuにする - Qiita

Windows 7 のターミナル設定(MSYS2編) – ラボラジアン

 

ホストOS(Windows 10 Home)にWordmoveをインストー

Rubyrubygems(gemコマンドが使える)が入っていることを確認します。

f:id:ts0818:20170530181351j:plain

あとは、gemコマンドでWordmoveをインストールするだけです。

理解必須!gemsのインストール方法とインストール場所 | 侍エンジニア塾ブログ | プログラミング入門者向け学習情報サイト

⇧  上記サイトによると、特にフォルダの場所を移動とかはないので、今いるディレクトリでgem installします。

gem install wordmove

f:id:ts0818:20170530181352j:plain

wordmove-2.1.2 がインストールされたみたいです。

f:id:ts0818:20170530181354j:plain

gem environmetコマンドにより、インストールされたパスを調べることができるようです。

gem environmet

f:id:ts0818:20170530181353j:plain

INSTALLATION DIRECTORYというパスがインストール先らしいです。

C:¥Ruby24-x64¥lib¥ruby¥gems¥2.4.0¥gems¥wordmove-2.1.2

f:id:ts0818:20170530181355j:plain

 

Dockerコンテナ内に

試しに、dockerコンテナ内で、ホストOS(Windows 10 Home)側にインストールしたRubyコマンドが使えるか試してみる。

docker-machine ssh kusanagi-machine

f:id:ts0818:20170530181357j:plain

docker-composeでrunさせてないので、他のコンテナ(NginxやMariaDBなどのコンテナ)は動いてないので、kusanagi-dataのコンテナにログイン。何故か、execだと入れなかった。

docker attach kusanagi-data

f:id:ts0818:20170530181358j:plain

WordPressのインストールされてるところでwordmoveしないといけないようなので、ホストOS(Windows 10 Home)側のRubyコマンドを試してみる。(dockerの仮想マシン、コンテナ内ともにRubyコマンドは入ってないです。)

f:id:ts0818:20170530181356j:plain

予想通り、コンテナ内のコマンドしか参照しないため、not found。

VCCWがホストOS側と仮想マシン内のゲストOS側の両方にWordPressを設置してお互いのフォルダを共有していたのは、理にかなった設計だったんですね。 

 

ホストとコンテナのファイルシステムを相互同期という手段もあるらしいけど...

残された手段はこれしかないと思いつつも、そもそも、ホストOS(Windows 10 Home)にインストールしたコマンドが、Dockerコンテナ側から使えるのかハッキリしなかったのですが、下記サイトによると、ホストOS側からゲストOSのコマンドを実行するのは可能のようです。

Kernel/VM Advent Calendar 33日目: VirtualBoxでホストOSからゲストOSのコマンドを実行する - hiraku_wfsの日記

その逆のDockerコンテナ側からホストOSにインストールしているコマンドを実行、をやりたいんですが、調べても分からず今回も泥沼な感じに....。

⇩  関係ないけど、前にKUSANAGIlocalhostアクセスできない問題は下記サイトが参考になりそうです。

WindowsホストでDocker使っててはまったことのメモ - フロントエンド開発Blog | オレには鈍器がある 無料ゲーム公式サイト

 

結局、docker-machine側にもRubyrubygems、wordmoveをインストールする流れ

せっかくホストOS側にRubyrubygems、wordmoveなどインストールしたけど、結局docker-machine側にも同じ様に入れることにしました、二度手間も甚だしいけど。 

誰か、DockerでホストOS側にインストールしたコマンドを、Dockerコンテナ側で使う方法分かったら教えてください。

⇩  そんなこんなで、下記サイトを参考に

Docker for Macで始めるお手軽WordPress環境の様々なカスタマイズ – OTTAN.XYZ

Rubyのインストール

Dockerの仮想マシンのOSであるBoot2dockerは、Tiny Core Linuxというものを元に作られてるらしい、Tiny Core Linux は、「デスクトップ向けLinuxとしてはもっとも小さい部類に入る」らしいです。

boot2docker is a lightweight Linux distribution based on Tiny Core Linux made specifically to run Docker containers. It runs completely from RAM, weighs ~27MB and boots in ~5s (YMMV).

Boot2docker by boot2docker

で、KUSANAGI Runs on Docker では、docker-compose.ymlに記載したdocker-imageを使ってdockerコンテナを作っているわけですが、

自分の場合は4つのコンテナができたわけですが、WordPressがインストールされているのが、「kusanagi-data」というコンテナでした。

kusanagi-data」というコンテナにwordmoveをインストールすればいいということか、ということで、まずはコンテナ内のOSが何かをチェックしてみます。

f:id:ts0818:20170601204911j:plain

コンテナのOSが分からないという問題勃発。 

Linuxのバージョンを確認するには? - QA@IT 

lsb_release -a    

f:id:ts0818:20170601205713j:plain

not found。

Linuxのディストリビューションとバージョンの確認方法をまとめてみた

そもそも、etc/issueファイルが無い。

 

今更聞けない!LinuxのOSやバージョンの確認方法

cat /proc/version

f:id:ts0818:20170601210322j:plain

コンパイラは、Debian 4.9.2-10らしいですね。

コンテナにOSが入ってないってことですかね?

今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2 - Publickey

兎にも角にも、コンテナ内のOSが分からんので、Linux ディストリビューションのパッケージマネージャでRubyをインストールする方法が使えなさそうです。

ソースコードからインストールする方法もあるようですが、

しかしながら、サードパーティ製ツールかパッケージマネージャを使う方が良い考えです。 何故なら、ソースからインストールされた Ruby はどのツールからも管理されないからです。

Rubyのインストール

なんか、おすすめはパッケージマネージャを使う方法みたいですね。 

解決策が見つからないまま時間だけが過ぎていく中、

Docker コンテナ内から他の Docker コンテナに docker exec する | ALTUS-FIVE

というサイトの中で、コンテナのコマンドが、別のコンテナで利用できると説明されていました。

ということで、Rubyのコンテナを作成すれば道が開かれそうです。

DockerHubのレジストリ確認

Rubyのdockerイメージを取得するには、下記コマンドで確認できるようです。

curl -s https://registry.hub.docker.com/v1/repositories/ruby/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4
latest~

f:id:ts0818:20170602142711j:plain

 ・DockerHubのイメージのタグ一覧をコマンドで取得する | Mazn.net

 ⇩  Docker Hub以外に自分でレジストリを立てることもできるようです

プライベートなDockerレジストリサーバーをコンテナで立てる - Qiita

 

ブラウザで、https://hub.docker.com/r/library/ にアクセスすることでもdockerイメージの検索ができるようです。

f:id:ts0818:20170602143552j:plain

 

 

 

docker-compose.ymlに追記

今回は、『2.4.1-alpine』 を使うことにしました。Alpine Linuxベースのdockerイメージのようです。dockerイメージが劇的に軽量化されてるようです。(軽量な分、bashやllといったコマンドも入ってない場合があるそうです)

Dockerやる前のAlpine Linux - YoshinoriN's Memento

E:¥kusanagi-docker¥docker-compose.yml にRubyのコンテナを追加するための設定を記述していきます。

version: '2'

services:
  kusanagi-data:
    container_name: kusanagi-data
    image: busybox
    restart: always
    stdin_open: true
    tty: true
    volumes:
      - /var/lib/mysql
      - /etc/nginx/conf.d
      - /etc/httpd/conf.d
      - /etc/kusanagi.d
      - /home/kusanagi
      - /var/run/docker.sock
    command: /bin/sh

  kusanagi-nginx:
    container_name: kusanagi-nginx
    image: primestrategy/kusanagi-nginx:1.10.0-1
    environment:
      PROFILE: kusanagi
      FQDN: localhost
      WPLANG: ja
      BCACHE: "off"
      FCACHE: "off"
    volumes_from:
      - kusanagi-data
    links:
      - kusanagi-php7:php
      - kusanagi-mariadb:mysql
      - ruby:ruby
    ports:
      - "80:80"
      - "443:443"

  kusanagi-mariadb:
    container_name: kusanagi-mariadb
    image: mariadb:10.0.24
    environment:
      MYSQL_ROOT_PASSWORD: my-secret-pw
      MYSQL_USER:     user
      MYSQL_PASSWORD: password
      MYSQL_DATABASE: wordpress
    volumes_from:
      - kusanagi-data

  kusanagi-php7:
    container_name: kusanagi-php7
    image: primestrategy/kusanagi-php7:7.0.6-1
    links:
      - kusanagi-mariadb:mysql
    volumes_from:
      - kusanagi-data

  ruby:
    container_name: ruby
    image: ruby:2.4.1-alpine
    tty: true
    volumes_from:
      - kusanagi-data

⇩ 下記サイトがリファレンスをまとめてくれてました

Docker Compose - docker-compose.yml リファレンス - Qiita

⇩  Docker Compose fileにバージョン3が追加されたらしい

Compose file version 3で追加された設定(deploy, secrets)とSwarmモードで使えない設定 - Qiita

⇩  ttyの説明については下記サイトへ 

docker-composeでコンテナが起動しない – inamuu.com

docker-comopseコマンドが動かない

動かなくなっちまいました....。おそらく、Msys2のbashに切り替えたのが原因かと思われますが。

f:id:ts0818:20170603111933j:plain

Unknown encoding error in Windows with cp65001 · Issue #2775 · docker/compose · GitHub

⇧  この問題については、上記のissueが参考になりそうです。

docker-comopseコマンドは、内部でpythonが使われているようですかね?

This issue is not happening on Python 3.5 so it may be a good reason to start bundling this with Py3 instead of Py2?

試しに、docker-compose.exeファイルを開いてみたら、

f:id:ts0818:20170603115520j:plain

むっちゃ文字化けしてる。Atomの自動文字コード判別パッケージ(auto-encoding) 入れてるんですが、まったく機能してない。

 

バイナリーエディタがあればファイルタイプが分かる!たぶん。 | ウェブインパクトエンジニアブログ

Tech TIPS:Windowsでバイナリファイルの内容をメモ帳(notepad)で確認する - @IT

⇧  上記サイトによると「MZ」で始まって居れば、Windows用の何かしらの実行ファイルらしい。Windows OSにおける各種の実行ファイル(.EXEだけでなく、.DLLや.PIF、.SCRといったファイルでも同じ)のようです。

ファイルの中に「This program cannot be run in DOS mode.」って言葉があったんですが、

これを見てピンと来る方は、MS-DOS を使用したことがある昔からの PCユーザーの方か、リバースエンジニアの方でしょうか。リバースエンジニアであれば必ず知っているだろうこの有名な文字列は、Windows用実行ファイル(PEファイル)を誤って MS-DOS上で実行してしまった場合に表示されるメッセージです。PEファイルには(ほぼ)必ず含まれているので、拡張子が「EXE」などの PEファイルをテキストエディタで開くと、先頭付近で目にすることができるはずです。

マルウェア解析の現場から-05 「This program…」 | トレンドマイクロ セキュリティブログ

らしいです。Atomには、MS-DOS が内臓されてるってことですかね?

PEファイルは、 

Portable Executable (PE)

主に32ビット及び64ビット版のMicrosoft Windows上で使用される実行ファイルファイルフォーマットを指す。PEフォーマット自体はオペレーティングシステムやハードウェアに依存しない設計となっているため、UEFIアプリケーションのバイナリフォーマットには、PEが採用されている。また、前述のUEFIとの整合性の確保やMicrosoft製OSとのマルチブート環境の構築を容易にする目的で、x86およびx86-64アーキテクチャにおけるLinuxカーネル実行ファイルブートローダなど、非Windows系OSのシステムファイルの一部にも用いられている。

EXEフォーマットとの互換性のため、MS-DOS上で実行すると「This program cannot be run in DOS mode.」のようにDOSで実行されない旨が表示され、プログラムが終了するなどのMS-DOSプログラムが先頭に付く。その後ろに、PE固有の識別子およびCOFFに似たデータ構造があり、MS-DOSヘッダによってそのオフセットが指されている。また、さまざまなCPUアーキテクチャに対応するため、内部に判別用のフラグを持つ。実行時にDLLというファンクション群を動的にリンクし、コンポーネントレベルでのバグフィックス、互換性の維持が行われるようになっている。また、リソース領域にアイコン等を格納でき、GUI上で表示された場合アイコンがグラフィカルに表示され、ソフトウェア判別を容易にできる。

Portable Executable - Wikipedia

ってことらしいです。 だいぶ脱線しましたが、docker-compose.exeの中身を確認するのは厳しそうですね。pythonの問題だとすると、

WindowsでPythonがLookupError: unknown encoding: cp65001 - Qiita

 のサイトで言ってるように、cp65001をpython2系が認識できないという問題に収束できるんですが。

code page(コードページ)って何ぞや?

Unknown encoding error in Windows with cp65001 · Issue #2775 · docker/compose · GitHub の中でcode pageってものが出てきて、謎だったんですが、 

文字エンコーディングはプラットフォーム依存です。Windows では、ストリームが対話型 (isatty() メソッドが True を返す場合) であれば、コンソールのコードページが、それ以外では ANSI コードページが使用されます。その他のプラットフォームでは、ロケールエンコーディングが使用されます (locale.getpreferredencoding() を参照)。

Windows+Git Bash環境でPython文字化け - Qiita

Wikipediaによると、

コードページとは、特定の符号化文字集合を指定するための数字、またはその数字で指定された符号化文字集合、あるいはそのような方法で符号化文字集合を指定するためのシステムのことである。cpと表示されることもある。それぞれの符号化文字集合は「コードページ○○(○○は2桁から5桁の数字)」という形で管理される。

コードページという用語は、システムベンダ各社が管理している符号化文字集合を指す時にしか用いられず、ISO等の公的な規格の文字集合を「コードページ○○」などということはない。IBMおよび、マイクロソフトは各自、コードページを定めて管理している。マイクロソフトのコードページ群はMS-DOSWindowsなどで利用されている。IBMのコードページはSystem iDB2等の文字データ表現体系(CDRA: "Character Data Representation Architecture")をサポートするIBMシステムで利用されている。

コードページ - Wikipedia

Windowsの問題ってことになってきそうですね。コードページを扱っているシステムベンダにWindowsIBMしか載ってないんですが、Macでは起こらない現象ってことかな?

 

文字エンコーディングと密接に関わってくるみたいです。

コードページを知らなかったのでググった。chcpコマンドで設定するものらしい。 Git Bash上からでも/C/windows/system32にパスが通っていれば、拡張子付きの名前chcp.comで呼び出せる。

Windows+Git Bash環境でPython文字化け - Qiita

ということらしいので、たぶんMsys2のbashでも同じ感じでできるでは。

Windows/コマンド/chcp - 文字コード・ロケールの変更 - yanor.net/wiki

コードページを表示してみます。 

chcp.com 

f:id:ts0818:20170603125853j:plain

code pageが65001になっているのは、ConEmuでMsys2のbashを起動するときのオプションの設定で、chcp 65001を指定してたためじゃないかなと考えたんですが、

msysGitのbash/sshでUTF-8の入出力が可能な理由 - Qiita

によると、msys-1.0.dll が影響してるようです。

MSYS、MSYS2、Cygwin、msysgit の違い: 雨鯨のたそがれ

Msys2にもmsysGitの状況が当てはまるかが分からないですが。

f:id:ts0818:20170603132545j:plain

ようやく ConEmu と NYAGOS を導入した — しっぽのさきっちょ | text.Baldanders.info

コードページの問題は、DBの接続でも問題になってたみたいです。

Windows版psqlでNot enough memoryエラーが出た時の対策

 

コードページの変更

いまのところ、

  • pythonのバージョンを3系にする
  • コードページの変更

のどちらかをすれば状況が変わるかもしれないようですが、docker-compose.exeの内部を変更することはできないので、「コードページの変更」で対処するしかなさそうです。

chcp.com 932

f:id:ts0818:20170603140744j:plain

見事に、復活?だが、しかし

f:id:ts0818:20170603150244j:plain

むっちゃ、怒られる。Docker-compose を使用するための設定(環境変数)を構成していないのが原因らしいです。

仮想マシンが動いてないと怒られる。仮想マシン起動。

f:id:ts0818:20170603145938j:plain

『eval $("C:\Program Files\Docker Toolbox\docker-machine.exe" env kusanagi-m
achine)』を実行してから、再びdocker-compose。

f:id:ts0818:20170603150112j:plain

なんとか起動してくれたようです。

f:id:ts0818:20170603150844j:plain

ConEmuで別のbashを起動して、仮想マシンsshでログインします。

f:id:ts0818:20170603153722j:plain

で、dockerコンテナ内(kusanagi-data)でdockerコンテナ(ruby)のRubyコマンド を使えると思いきや、dockerコンテナ内でdockerコマンド使えない問題勃発。

f:id:ts0818:20170603154219j:plain

 

Docker in Dockerって?

dockerコンテナからdockerコンテナを起動することを、Docker in Dockerというらしいですね。

Docker in Docker のベタープラクティス - Qiita

 

ちょっと、ハマりにハマりすぎてるの次回に続きます。

広告を非表示にする