いがにんのぼやき

WEBエンジニアのブログ。IT、WEB、バンド、アニメ。

WindowsでDocker toolboxを使用してVisual Studioと連携しようとして失敗した

Windows Docker Visual Studio

まず言っておこう。
Docker for Windowsを使おうな！！！

事の発端

最初は僕もDocker for Windowsを素直に使ってみようと思っていた。

Docker Store

上記からDocker Community Edition for Windowsを入手し、インストール。
インストールを進めていたところ、下記のようなエラーに遭遇した。

f:id:igatea:20171210043903p:plain

Hyper-Vがないために発生するエラーのようだ。
どれどれ、Hyper-Vをインストールしようじゃないか。
よしよし、このリンクにインストール方法が載っているぞ。

docs.microsoft.com

 

ん？

 

f:id:igatea:20171211161024p:plain

 

は？

 

f:id:igatea:20171211161258p:plain

 

 

はああああ～～～～～～～！！！？？？

 

PC購入当時、1万円をケチったことを後悔していく。
Docker for WindowsではHyper-Vが必要で、Windows Home Editionでは動作させる方法がない。
そんなとこからHome Editionでも使用可能なDocker toolboxを使用してみる。

ここからはただただ心を折っていく出来事に立ち向かい、心が折れていく様を記載するだけである。

失敗

一度、最終的なゴールに立ち返ってみる。
最終的にはVisual Studio 2017 CommunityでASP.NET CoreのDockerコンテナの実行を可能にしようというものだ。
新規でASP.NET Coreプロジェクトを作成し、デバッグ無しで実行を正常に行うことができるようにする。
それに向かっていきながら発生したエラーを叩き潰していくという作業を行っていった。
Docker toolbox自体のインストールは事前に済ましておいた。

Powershellにパスを通す

PowershellにはDockerのパスが通っていないので、パスを通す。

github.com

docker-machine env default | Invoke-Expression

Dockerが実行されていない

Visual Studioからサンプルアプリケーションを作成し、デバッグ無しで実行しようとしてみると下記のエラーが発生。

重大度レベル   コード   説明  プロジェクト  ファイル    行 抑制状態
エラー       Visual Studio コンテナー ツールでは、コンテナー化されたプロジェクトをビルド、デバッグ、実行する前に、Docker が実行されている必要があります。

詳細については、http://aka.ms/DockerToolsTroubleshooting をご覧ください  docker-compose  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets 314 
1>------ ビルド開始: プロジェクト: docker-compose, 構成: Debug Any CPU ------
1>docker ps --filter "status=running" --filter "name=dockercompose16224944752208736737_dotnetcore02_" --format {{.ID}} -n 1
1>error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.33/containers/json?filters=%7B%22name%22%3A%7B%22dockercompose16224944752208736737_dotnetcore02_%22%3Atrue%7D%2C%22status%22%3A%7B%22running%22%3Atrue%7D%7D&limit=1: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(314,5): error : Visual Studio コンテナー ツールでは、コンテナー化されたプロジェクトをビルド、デバッグ、実行する前に、Docker が実行されている必要があります。
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(314,5): error : 
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(314,5): error : 詳細については、http://aka.ms/DockerToolsTroubleshooting をご覧ください
1>プロジェクト "docker-compose.dcproj" のビルドが終了しました -- 失敗。
========== ビルド: 正常終了または最新の状態 0、失敗 1、スキップ 0 ==========

Docker MachineはDocker toolboxのQuick Installを実行した時点でdefaultというものが作成されているので存在はしているし、開始されているはず。

docker-machine create box

上記コマンドで新規に作成しても変わらず。
最初にPowerShellでパスを通した通り、Visual Studioでも参照できるようパスを通さなければいけないのかもと思い、仮でユーザー環境変数を設定してみた。

f:id:igatea:20171210170200p:plain

これをするとエラーは出なくなり出力が変わった。

dotnet SDKが見つからない？ボリューム共有が無効？

========== 起動中 ==========
docker ps --filter "status=running" --filter "name=dockercompose16224944752208736737_dotnetcore02_" --format {{.ID}} -n 1
40cc4dbd74c0
docker exec -i 40cc4dbd74c0 dotnet  --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages --additionalProbingPath /root/.nuget/fallbackpackages2  bin/Debug/netcoreapp2.0/DotNetCore02.dll
docker inspect --format="{{json .NetworkSettings.Ports}}" 40cc4dbd74c0
{"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"32768"}]}
Did you mean to run dotnet SDK commands? Please install dotnet SDK from: 
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
ボリューム共有が有効になっていません。Docker CE for Windows の設定で、ボリューム共有を有効にしてください。

詳細については、http://aka.ms/DockertoolsTroubleshooting をご覧ください。

dotnet SDKが入っていないとのことなので入れてみる（VIsual Studioのインストールで入ってるぽいけどなんでだろ？）

www.microsoft.com

入れようとしたらすでに入ってるよって出るので一度スルー。
ボリューム共有に取り掛かってみる。
VirtualBoxの共有フォルダーを設定するだけだとdocker-machineの再起動時に変更されるため駄目みたい。

f:id:igatea:20171210173706p:plain

下記にある通り、永続化と自動マウントを設定してあげればいいようだ。

docs.docker.com

f:id:igatea:20171210174056p:plain

設定後docker-machineを再起動

docker-machine restart default

そのままだとできなかったのでVisual Studioを再起動もしてみた。
残念ながらエラーは変わらずだった。
ここらへんで心が折れた。

github.com

このissueコメントを見ているとやっぱりtoolboxはダメみたいだ。
ここでWindows Pro Editionをインストールし、Hyper-Vを有効化、Docker for Windowsを入れて再度やってみたら今までのエラーが嘘かのようにすぐ実行できたのであった・・・。

失敗を糧に生きていくぞ！！！

おまけ

Hyper-V上にMobyLinuxVMが存在するのにdocker-machine lsで表示されなかった。

f:id:igatea:20171211160038p:plain

PS C:\Windows\system32> docker-machine ls
NAME   ACTIVE   DRIVER   STATE   URL   SWARM   DOCKER   ERRORS

下記を見ると、docker-machineはリモートに使用するとき以外は使わないっぽい。

forums.docker.com

PHPで画像に使用するユニークな名前を用意する

画像に一意な名前を付けたいと思って、PHPのダミーデータ作成ライブラリのFakerを参考にしてみた。

github.com

// Generate a random filename. Use the server address so that a file
// generated at the same time on a different server won't have a collision.
$name = md5(uniqid(empty($_SERVER['SERVER_ADDR']) ? '' : $_SERVER['SERVER_ADDR'], true));

上記はFakerでのダミー画像作成時のファイル名の生成コード。
手順としては下記である。

  1. $_SERVER['SERVER_ADDR']でサーバーのIPを取得
  2. それを先頭文字としてuniqid()で一意な文字列を生成
  3. 一意な文字列をmd5()でハッシュ化

各関数について

uniqid

PHP: uniqid - Manual

マイクロ秒単位の現在時刻にもとづいた、接頭辞つきの一意な ID を取得します。

とあるとおり、現在の時刻に基づいて作ってくれるようだ。

md5

PHP: md5 - Manual

入力値をハッシュ化する。
同じ入力であれば同じ値に、少しでも違えば全く違う値が生成されるようになっている。

Fakerでのファイル名生成について

コメントにもあるとおり、同じ時刻に別のサーバーでファイルが生成されたとしても同じ名前にならないようにサーバーのIPをuniqid()の先頭文字として使用して、それをハッシュ化するという手法をとっている。

Docker上での、GitサブモジュールによるNode.jsエラー

Git 
igatea-Ubuntu-PC:co.tech igatea$ docker-compose exec php npm install
npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t git://github.com/jeroennoten/webpack-stream.git
npm ERR! 
npm ERR! fatal: Not a git repository: ../.git/modules/src
npm ERR! 
npm ERR! exited with error code: 128

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2017-11-14T06_51_41_841Z-debug.log

GitのサブモジュールのディレクトリをDockerコンテナ上に共有しているのが問題だった。
この場合はsrcディレクトリをサブモジュールとしていた。
単純にサブモジュールだけじゃなく、Git全体を含める形で解決した。
そもそもサブモジュールを使用せず、指定のディレクトリをgitignoreに追加してそのままそのディレクトリにリポジトリを展開しても良いかもしれない。

UbuntuでVirtualbox、Vagrantのエラー

Vagrant Ubuntu

Dockerを使用してnpm runをしようとするとPermission deniedが出る問題あり。やったことを残すためにこの記事は残しておきますが、参考にしないでください。

sh: 1: webpack: Permission denied

自分用メモ。

Virtualboxを入れるのもひと手間だった。 具体的な記述に残していないが、下記で行けた。

askubuntu.com

Secure bootを無効にするとかだった気がする。

また、UbuntuでVagrantを使用するときに、外部ディスクを使用するときにパーミッションエラーが出るための対応。
こんな感じのエラーがでる。

The private key to connect to this box via SSH has invalid permissions
set on it. The permissions of the private key should be set to 0600, otherwise SSH will
ignore the key. Vagrant tried to do this automatically for you but failed. Please set the
permissions on the following file to 0600 and then try running this command again:

/media/igatea/TOSHIBA-1TB/Vagrant/centos7/.vagrant/machines/default/virtualbox/private_key

Note that this error occurs after Vagrant automatically tries to
do this for you. The likely cause of this error is a lack of filesystem
permissions or even filesystem functionality. For example, if your
Vagrant data is on a USB stick, a common case is that chmod is
not supported. The key will need to be moved to a filesystem that
supports chmod.

GUIで外部のHDDのマウントの設定をしていたが、パーミッションの変更ができないっぽい。
なので下記を参考にマウント設定のfstabをいじっていく。

hakushisky.blog.shinobi.jp

askubuntu.com

最終的に/etc/fstabに下記の行を追加して再起動。

UUID=B07E713F7E710000 /media/igatea/TOSHIBA-1TB auto auto,users,permissions 0 0

その後、Vagrantのディレクトリのprivate_keyがrootの777になっているのでパーミッションを変更してあげて終了。

chown igatea .vagrant/machines/default/virtualbox/private_key 
chmod 600 .vagrant/machines/default/virtualbox/private_key

ユーザーがrootのままだと下記のエラーが発生する

The private key to connect to the machine via SSH must be owned
by the user running Vagrant. This is a strict requirement from
SSH itself. Please fix the following key to be owned by the user
running Vagrant:

/media/igatea/TOSHIBA-1TB/Vagrant/centos7/.vagrant/machines/default/virtualbox/private_key

ISUCON7に参加した

技術イベント

参加しました。

事前に練習会をやったのでそのままの流れで。 igatea.hatenablog.com

最終スコアは15164、ベストスコアは33272でした。

f:id:igatea:20171022153957p:plain

トップは云十万単位のスコアを出していて、壁は厚いなあと思った。

チーム構成

担当は練習会と同じ感じ。

言語はPHPです。

今回のISUCONの課題

今回は掲示板のような、チャットのようなサイトでした。
しかもサーバーが3台構成。
このサーバーをどう扱っていくかが重要だった気がします。

どんなことをやったか

僕らは1台をWEB、1台をDBとして活用した。
余った1台は実験サーバーになってて何かうまく使いたかったが時間的に出来なかった。

やったこととして最初はサーバーへの接続確認。 確認できたところでミドルウェアやアプリケーションと言った、設定含めた各ファイルのバックアップ。

そこらへんは他の方にお願いした。
その間に最初の30分で僕は仕様の把握。
こんなかんじ。

f:id:igatea:20171022211745j:plain

前回予選の問題よりもかなり複雑だった。

その後はnginxのログをうまくデータとして扱ってくれるツールとしてalpを使用した。
alpから重いところ探してアプリケーションの改善に力を入れた。

一番重かったのが画像表示だったけど、メンバーが早々に画像がDBに入っているところを発見して、それをファイル出力にするということに取り組んでくれた。
ここらへんめっちゃありがたかった。
ので、自分は他を俯瞰的に。

ちょっと困ったのが前回の予選問題だとここを改善すれば凄く早くなるなってところが局所だったんだけど、今回は画像のところ以外分散していて困った。

有効だった対策

ベンチのスコアが変動しすぎて（ベンチガチャとか言われてた）どれが有効打になっているのか判断つきづらかった。
なので、これは凄くスコアが上がったっていうものと恐らくスコア上がっただろうっていう取り組みに分けてみる。

凄く上がった
  • SELECT句のカラムを徹底的に絞り込み
  • SQLの発行回数を少なくするように結合を活用

基本的にSELECT句のカラム指定の*は全て削除して、カラム指定するようにした。
getのhistoryとmessageは無駄にクエリを投げまくっていたのでアプリケーションコードを一部書き換えた。
ここらへんで1万、2万スコアが上がった。

恐らく上がった
  • 同じループを2回以上やっているところの解消
  • initialize時にSQLのキャッシュを作るために先にクエリを発行

正直スコアが変動しすぎて効果があったのかわからないレベルだった。

もっとうまくやりたかったなあって点

ベンチ設定ミス

設定を保存を押してなくてずっとベンチを回すサーバーを間違ってた。
てっきりチェックボックスつけとけばいいのかと思っててメンバーに指摘されて気付いた。
上がらないからとマージしなかったブランチをマージしていったらガンガン点数が上がって最高だった。

根本解決

クエリとかロジック周りは直したつもりだけど、それ以上スコアの上昇が見られなかった。
もっと根本的に改善しなければこれ以上上がらないなという壁を感じた。
例えば今回は3台のサーバーが用意されていたわけだけど、それをフルに使用することができなかった。
画像をWEBサーバーに書きだしたことにより、DBへの負荷は軽くなったんだけど、WEBサーバーがCPUが100%に張り付いている状態だった。
自分たちはWEBサーバー1台を余らせている状況だったので、もったいなかったなあと。
終わったあと話してたのはそのサーバーを画像配信サーバーにできたらよかったかもってこと。
今回メンバー的にインフラ、ミドルウェア周りに詳しいという人がいなかったので取り組むにはとても難しい状況だった。

得た知見

仕事上、ガンガンサーバー設定をいじるわけでも無いし、ましてやWindow Serverの方が触ることが多かった。
しかもあまりアプリケーション改善もDB周りへの配慮を実務でするということがなかったので物凄く経験になった。
これはまた別に記事を書きたいと思う。

最後に

凄く楽しいコンテストだった。
メンバーが色々サポートしてくれて、かなり自由にアプケーション側を弄っていけて最高でした。
一緒に組んでくれたごまさん、くーむさん、本当にありがとうございました！
めちゃくちゃ勉強になりました！

Dockerでnginx + php-fpm環境を立てる

最近ちょっとずつDockerを触っている。
手慣れると本当に爆足で環境構築できて、本当に便利だ。

今回はdocker-composeを使用してnginxとphp-fpmのサーバーを立ててみる。

nginx

まずnginxから。

docker-compose.ymlというファイルを作成し、下記のようにする。

version: '2'
services:
# localhost:8080
  nginx:
    image: nginx
    ports:
      - "8080:80"
    volumes:
      - ./web:/web

これで、webというディレクトリ配下を見るnginxのコンテナが立ち上がる。

php-fpm

servicesのところに、下記を追加する

  php:
    image: php:fpm
    volumes:
      - ./web:/web

phpのときにweb配下のphpを読み込むようになる。

連携

nginxとphp-fpmを連携するとこんな感じになる。

version: '2'

services:
# localhost:8080
  nginx:
    image: nginx
    ports:
      - "8080:80"
    volumes:
      - ./web:/web
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf # php-fpmのための設定の読み込み
    links: # host追加
      - php

  php:
    image: php:fpm
    volumes:
      - ./web:/web

追加したのはphp-fpmのためのnginxの設定ファイルの共有と、その設定ファイル内で使用するホストのための記述。

default.confは雑にこんな感じ。

server {
    index index.php index.html;
    server_name php-docker.local;
    error_log  /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;
    root /web;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

fastcgi_passのphp:9000はlinksに書いたphpからホスト解決される。

データベースやXDEBUGを使えるか検証していないので、そこらへんを触ったらまた記事にしたいと思う。

ISUCON模擬練習会に参加した

とある技術コミュニティで行うことになった、ISUCON模擬練習会に参加した。
去年の予選問題を元に、擬似的にISUCONをゆるっとやってみた感じ。
主催者の方がベンチマークのポータルを立ててくれて、それを元にスコア上げて見るみたいなことをした。
本番と同じチームで行って、僕達はPHPで試してみた。
担当としてはざっくり下記。

流れ

覚えている感じ、チームでやった流れ

  1. SSHとかGitの設定
  2. MySQLのデータ、スキーマのダンプ
  3. MySQLのチューニング
  4. alpを入れてnginxのログ解析
  5. MySQLのスローログ出力
  6. 画面上から仕様の把握
  7. blackfire導入
  8. アプリケーションコードのチューニング

練習会を終えて

推測ではなく解析

まさにこれだなあと思った。
仕様見ててここらへんが重いんだろうなとは分かりつつも、本当かはわからないので。
ログは正直です。
ログを見てやばそうなとこから手をつけるとポイントが上がっていく実感を得た。

キャッシュの職人芸

問題の解説を改めて見てみて、うちのチームはキャッシュ周りに手を加えることができなかったので、本番までにそこらの問題を埋めたいなあと思ってる。
例えば予選問題だと、毎回正規表現を生成する処理がボトルネックとなっていたんだけど、それをうまくキャッシュするとか。

時間足らん

何時間も作業するとはいえ、やっぱり時間足らんなあと。
初めてなので手慣れてない感はあったので本番はもっとスムーズに勧められるかも？

仲間が心強い

ずっとWindowsを触ることのほうが多い職場だったのでLinuxが頓珍漢。
そんなとき仲間が心強かった。
いろんな処理を簡単にしてくれたり、問題を見つけてくれたり、相談できたり。
マジ感謝。

雑に雰囲気を感じられてよかった

時間を気にしつつ怒涛に環境を整えて進めていく感じが凄く焦るし面白かった。
序盤は正直動けなくて地蔵になりかけた（すまん）

これから

ISUCONのために練習ってことになってるけど、周りの知識を吸収できるし、めっちゃ面白いのでISUCON関係なくこれからもやっていきたい練習会だなと思った。