いろいろ脱線につぐ脱線でしたが、いよいよ、ローカル環境に構築したDockerコンテナ内のWordPressでWordmoveを試していきたいと思いますが、タイトル通り、前編で解決できてないので、後編に続く予定です。
Msys2のbashでdocker-machineコマンドが、み、見つからない！
いきなり最終回...と言いたいところですが、前回この問題については様々なサイトで解決策が提示されていた気がします。
・msys2を更新したらPATH設定が消えた？？ - foohogehoge's blog
・Windows に Unix ライクな開発環境を構築してみました
・ffmpegをwindows向けにビルドした方法 - Qiita
この方法を試してみて駄目だとかなり絶望的ではありますが。
⇩ 下記サイトによると、MSYS2_ARG_CONV_EXCLってのも設定できるようです
MSYS2_ARG_CONV_EXCLまで考えると、かなり複雑になりそうな感じです。
Msys2のbashにWindowsのパスを認識させる
今回は、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 . . . 途中省略
ConEmuを再起動して、{Bash}の{Msys2-64}を選択します。
無事、WindowsでインストールしていたライブラリなどへのパスがConEmuのbashから参照できました。
tmux というものを使う場合ConEmuでは厳しいようです。
・MSYS2の端末ソフトをConEmuにする - Qiita
・Windows 7 のターミナル設定（MSYS2編） – ラボラジアン
ホストOS（Windows 10 Home）にWordmoveをインストール
Rubyとrubygems（gemコマンドが使える）が入っていることを確認します。
あとは、gemコマンドでWordmoveをインストールするだけです。
・理解必須！gemsのインストール方法とインストール場所 | 侍エンジニア塾ブログ | プログラミング入門者向け学習情報サイト
⇧ 上記サイトによると、特にフォルダの場所を移動とかはないので、今いるディレクトリでgem installします。
gem install wordmove
wordmove-2.1.2 がインストールされたみたいです。
gem environmetコマンドにより、インストールされたパスを調べることができるようです。
gem environmet
INSTALLATION DIRECTORYというパスがインストール先らしいです。
C:¥Ruby24-x64¥lib¥ruby¥gems¥2.4.0¥gems¥wordmove-2.1.2
Dockerコンテナ内に
試しに、dockerコンテナ内で、ホストOS（Windows 10 Home）側にインストールしたRubyコマンドが使えるか試してみる。
docker-machine ssh kusanagi-machine
docker-composeでrunさせてないので、他のコンテナ（NginxやMariaDBなどのコンテナ）は動いてないので、kusanagi-dataのコンテナにログイン。何故か、execだと入れなかった。
docker attach kusanagi-data
WordPressのインストールされてるところでwordmoveしないといけないようなので、ホストOS（Windows 10 Home）側のRubyコマンドを試してみる。（dockerの仮想マシン、コンテナ内ともにRubyコマンドは入ってないです。）
予想通り、コンテナ内のコマンドしか参照しないため、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にインストールしているコマンドを実行、をやりたいんですが、調べても分からず今回も泥沼な感じに....。
⇩ 関係ないけど、前にKUSANAGIでlocalhostアクセスできない問題は下記サイトが参考になりそうです。
・WindowsホストでDocker使っててはまったことのメモ - フロントエンド開発Blog | オレには鈍器がある 無料ゲーム公式サイト
結局、docker-machine側にもRuby、rubygems、wordmoveをインストールする流れ
せっかくホストOS側にRuby、rubygems、wordmoveなどインストールしたけど、結局docker-machine側にも同じ様に入れることにしました、二度手間も甚だしいけど。
誰か、DockerでホストOS側にインストールしたコマンドを、Dockerコンテナ側で使う方法分かったら教えてください。
⇩ そんなこんなで、下記サイトを参考に
・Docker for Macで始めるお手軽WordPress環境の様々なカスタマイズ – OTTAN.XYZ
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).
で、KUSANAGI Runs on Docker では、docker-compose.ymlに記載したdocker-imageを使ってdockerコンテナを作っているわけですが、
自分の場合は4つのコンテナができたわけですが、WordPressがインストールされているのが、「kusanagi-data」というコンテナでした。
「kusanagi-data」というコンテナにwordmoveをインストールすればいいということか、ということで、まずはコンテナ内のOSが何かをチェックしてみます。
コンテナのOSが分からないという問題勃発。
lsb_release -a
not found。
・Linuxのディストリビューションとバージョンの確認方法をまとめてみた
そもそも、etc/issueファイルが無い。
cat /proc/version
コンテナにOSが入ってないってことですかね？
・今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2 － Publickey
兎にも角にも、コンテナ内のOSが分からんので、Linux ディストリビューションのパッケージマネージャで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～
・DockerHubのイメージのタグ一覧をコマンドで取得する | Mazn.net
⇩ Docker Hub以外に自分でレジストリを立てることもできるようです
・プライベートなDockerレジストリサーバーをコンテナで立てる - Qiita
ブラウザで、https://hub.docker.com/r/library/ にアクセスすることでもdockerイメージの検索ができるようです。
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に切り替えたのが原因かと思われますが。
・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ファイルを開いてみたら、
むっちゃ文字化けしてる。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ファイルをテキストエディタで開くと、先頭付近で目にすることができるはずです。
らしいです。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上で表示された場合アイコンがグラフィカルに表示され、ソフトウェア判別を容易にできる。
ってことらしいです。 だいぶ脱線しましたが、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() を参照)。
Wikipediaによると、
コードページとは、特定の符号化文字集合を指定するための数字、またはその数字で指定された符号化文字集合、あるいはそのような方法で符号化文字集合を指定するためのシステムのことである。cpと表示されることもある。それぞれの符号化文字集合は「コードページ○○（○○は2桁から5桁の数字）」という形で管理される。
コードページという用語は、システムベンダ各社が管理している符号化文字集合を指す時にしか用いられず、ISO等の公的な規格の文字集合を「コードページ○○」などということはない。IBMおよび、マイクロソフトは各自、コードページを定めて管理している。マイクロソフトのコードページ群はMS-DOSやWindowsなどで利用されている。IBMのコードページはSystem iやDB2等の文字データ表現体系(CDRA: "Character Data Representation Architecture")をサポートするIBMシステムで利用されている。
Windowsの問題ってことになってきそうですね。コードページを扱っているシステムベンダにWindowsとIBMしか載ってないんですが、Macでは起こらない現象ってことかな？
文字エンコーディングと密接に関わってくるみたいです。
コードページを知らなかったのでググった。chcpコマンドで設定するものらしい。 Git Bash上からでも/C/windows/system32にパスが通っていれば、拡張子付きの名前chcp.comで呼び出せる。
ということらしいので、たぶんMsys2のbashでも同じ感じでできるでは。
・Windows/コマンド/chcp - 文字コード・ロケールの変更 - yanor.net/wiki
コードページを表示してみます。
chcp.com
code pageが65001になっているのは、ConEmuでMsys2のbashを起動するときのオプションの設定で、chcp 65001を指定してたためじゃないかなと考えたんですが、
・msysGitのbash/sshでUTF-8の入出力が可能な理由 - Qiita
によると、msys-1.0.dll が影響してるようです。
・MSYS、MSYS2、Cygwin、msysgit の違い: 雨鯨のたそがれ
Msys2にもmsysGitの状況が当てはまるかが分からないですが。
・ようやく ConEmu と NYAGOS を導入した — しっぽのさきっちょ | text.Baldanders.info
コードページの問題は、DBの接続でも問題になってたみたいです。
・Windows版psqlでNot enough memoryエラーが出た時の対策
コードページの変更
いまのところ、
- pythonのバージョンを3系にする
- コードページの変更
のどちらかをすれば状況が変わるかもしれないようですが、docker-compose.exeの内部を変更することはできないので、「コードページの変更」で対処するしかなさそうです。
chcp.com 932
見事に、復活？だが、しかし
むっちゃ、怒られる。Docker-compose を使用するための設定(環境変数)を構成していないのが原因らしいです。
『eval $("C:\Program Files\Docker Toolbox\docker-machine.exe" env kusanagi-m
achine)』を実行してから、再びdocker-compose。
なんとか起動してくれたようです。
ConEmuで別のbashを起動して、仮想マシンにsshでログインします。
で、dockerコンテナ内（kusanagi-data）でdockerコンテナ（ruby）のRubyコマンド を使えると思いきや、dockerコンテナ内でdockerコマンド使えない問題勃発。
Docker in Dockerって？
dockerコンテナからdockerコンテナを起動することを、Docker in Dockerというらしいですね。
・Docker in Docker のベタープラクティス - Qiita
ちょっと、ハマりにハマりすぎてるの次回に続きます。
今回はこのへんで。
