‘Docker’ タグのついている投稿
Docker Desktop for Mac さん、API無反応で起動に失敗しがち
雰囲気でDocker Composeを使ってて落ちた穴
昔やった案件の開発環境を作る必要がでまして
「docker-compose.ymlとDockerfileをgitで管理しているオレに死角はないぜ」
とか思ったんですけど、死角に落とし穴がバンバンでひどい目に会いました。
まぁ、見えてる穴に落ちたってのもありますが。
名前かぶりに気をつけよう
先に書いておくと、ハマったのは大体がボリュームの名前かぶりでした。
とある日のSlack
「開発環境復活。docker-composeだとデフォルトだとディレクトリ名ベースで名付けが行われるので同じディレクトリ名におかれた別プロジェクトでボリューム名が被る。結果、変なボリュームができて想定しているボリュームが使用されずににっちもさっちも行かなくなってた。
ボリューム全部削除して、COMPOSE_PROJECT_NAME環境変数で名付けのベースを変更して作り直して復活。」
参考: docker-composeで作成されるものの名前を明示的に指定する方法 – Qiita
Laravel Dusk メモ
Laravel 5.5 & Laradock(https://github.com/laradock/laradock)環境です。
Laradockについては少し古いかもしれません(活発に更新されているのですぐに古くなる)。
Laravel Dusk はブラウザテストをお手軽に!というパッケージです。
https://readouble.com/laravel/5.5/ja/dusk.html
Laradockでのセットアップと使い始めてすぐのログインテストで何回かつまづいたのでメモを残しておきます。
(さらに…)
dockerからAmazon EC2への奮闘記
- 2017/08/09
- okada
- Amazon EC2
- Docker
- Laravel
今までdockerを使ったことがなかった私、勉強がてらLaradockを使ってLaravelで開発を行っていました
そこからAmazon EC2へ移行するまでの過程で色々行き詰まり、
なんとかLaradockからEC2へ環境移行することができましたので、
今後のメモのためにログを残しておこうと思います
今回書く内容はLaradockの環境設定〜Amazon EC2へ設置するまでの簡単な流れで行き詰ったものを晒すだけのほぼ日記の様なものです(笑)
Docker for Mac 〜 Laradockを導入するまで
$ git clone --depth=1 -b v5.5.1 https://github.com/LaraDock/laradock.git
$ cd laradock
$ cp env-example .env
$ vi .env
…とこのようにまずはドキュメントに従って導入を行っていました
しかし
問題1:Laradockを導入したが起動しない
$ docker-compose up -d nginx mysql
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`.
$ docker-machine start default
Host does not exist: "default"
defaultを設定しないといけない?
$ docker-machine create --driver virtualbox default
をすればよい、とのことだったので実行してみたけれどエラー発生
そもそもDocker for Macはvirtualbox使わなくても良くなった、との記述を見かけた気が…
解決:boot2dockerとDocker for macが混在していた
Laradockの問題ではなく、dockerの問題でした
どうやらDocker for Macを入れる前にboot2dockerをhomebrewで入れていたようで、
PC内にdockerが2つある状態でした
ということでboot2dokerを削除
brew uninstall docker boot2docker docker-compose docker-machine
念のためDocker for Macもアンインストールして入れ直し、もう一度動かしてみた所無事にLaradockを動かすことができました!
まぁこんなことしでかすなんて自分くらいしかいないと思うので参考にはならないかもしれませんが、思い出の一つとして…
問題2:MySQLが動かない
次のようなエラーが発生してMySQLが起動しない
docker-compose ps
を実行してみた所、laradock_mysql_1のstateはExitでした
$ docker-compose up --build -d nginx mysql
$ docker-compose exec mysql bash
ERROR: No container found for mysql_1
ログを確認
$ docker logs laradock_mysql_1
2017-08-01T08:01:50.339823Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
解決:MySQLのデータファイルを削除
このエラーに関しては.envファイルを確認し、MySQLのデータファイルを削除した所、起動に成功しました
$ vi .env ⇐ laradock/.envを確認
10 ### Data Path:
11 # For all storage systems.
12
13 DATA_SAVE_PATH=~/.laradock/data
$ cd ~/.laradock/data
$ mv data data.old
Laradockが動かない…動かない…と入れ直しを繰り返した時にゴミファイルとして残ってしまっていた模様
ローカルからAmazon EC2へ
システムが出来上がり、次はシステムをローカルからEC2へ移行作業へ…
まずLaradock環境内のバージョンを確認
EC2側にもPHP7.1、MySQL5.7、nginxをインストール
$ docker-compose exec workspace bash
# php -v
PHP 7.1.4-1+deb.sury.org~xenial+1 (cli) (built: Apr 11 2017 22:12:32) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.4-1+deb.sury.org~xenial+1, Copyright (c) 1999-2017, by Zend Technologies
# php artisan --version
Laravel Framework 5.4.30
# exit
exit
$ docker-compose exec mysql bash
# mysql --version
mysql Ver 14.14 Distrib 5.7.19, for Linux (x86_64) using EditLine wrapper
# exit
exit
EC2側環境作成
PHP、MySQL、nginxインストール後…
以下のファイルを編集
$ vi /etc/php-fpm.d/www.conf
24 user = nginx
25 ; RPM: Keep a group allowed to write in log dir.
26 group = nginx
48 listen.owner = nginx
49 listen.group = nginx
50 listen.mode = 0660
$ vi /etc/nginx/nginx.conf
40 server {
44 root /var/www/html/public;
73 location ~ \.php$ {
74 root /var/www/html/public;
75 fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
76 fastcgi_index index.php;
77 fastcgi_param SCRIPT_FILENAME /var/www/html/public$fastcgi_script_name;
78 include fastcgi_params;
79 }
それぞれのサービスを起動 & 自動起動するように設定
$ sudo service nginx start ⇐ サービス起動
$ sudo service php-fpm start
$ sudo service mysqld start
$ sudo chkconfig nginx on ⇐ 自動起動
$ sudo chkconfig php-fpm on
$ sudo chkconfig mysqld on
MySQL5.7ではrootユーザには初期パスワードなるものが存在し、
最初はそのパスワードでログインする
[ec2-user@ip-172-31-46-167 ~]$ sudo cat /var/log/mysqld.log
2017-08-03T06:59:34.488345Z 1 [Note] A temporary password is generated for root@localhost: Jt?eJUpbO6kl ⇐コレ
rootのパスワードは変更しておくべし
$ mysql -u root -p
> ALTER USER 'root'@'localhost' IDENTIFIED BY 'パスワード';
Laravelのドキュメントに従いComposerをインストール後、Laravel5.4を導入
$ composer global require "laravel/installer"
$ cd /var/www/
$ laravel new html
ブラウザでLaravelのTOP画面が表示されることを確認
Laradockからお引っ越し
ローカルのLaravelより、gitを使ってアーカイブファイル作成!
Laradockには既に.gitignoreファイルが準備されており、logファイル等など必要ないファイルは省かれる様になっていました。便利!
git archive HEAD --output=~/WorkSpace/project/release/archive.zip
このファイルを/var/www/htmlに上書き(.envの取扱い注意!)し、
ファイルの権限を変更 chmod o+w -R storage
そして以下のコードを実行
$ php artisan config:cache
$ php artisan route:cache
.env.exampleを.envに書き換え、EC2上の環境に合わせた設定に書き換えます
そしてブラウザで確認!
The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths.
こんなエラーが表示されましたよ…
以下を実行
$ php artisan key:generate
$ php artisan config:clear
.envファイルの APP_KEY=
にキーがセットされるわけですね
無事TOPが表示されました!
でもページが遷移しませんよ?
/loginへ遷移できません。404エラーです。
原因はnginxの設定。5.4のドキュメント通りにnginx.confを編集。
$ vi /etc/nginx/nginx.conf
49 location / {
50 try_files $uri /index.php?$query_string;
51 }
これで他のページへも遷移できるようになりました!
以上がEC2への引っ越し奮闘記になります。
Dockerのデータボリュームをバックアップ・リストア
現状試しているのはローカルストレージドライバでのデータボリュームの場合ですが、コンテナでバインドして扱うのが常道な感じです。
データ・ボリュームのバックアップ・修復・移行
http://docs.docker.jp/engine/userguide/dockervolumes.html#id9
に書いてあるやり方ですね。
jenkins-masterというコンテナの /var/jenkins_home をバックアップ・リストアする例をあげます。
バックアップ
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine tar czvf /backup/alp.tar.gz -C /var jenkins_home
リストア
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine sh -c "rm -rf /var/jenkins_home/* && cd /var && tar xzvf /backup/alp.tar.gz"
念のためユーザーにrootを指定し、Alpine Linuxで実行しています。バックアップ時、相対ディレクトリ指定のためtarの-Cオプションを使用しています。展開時はゴミファイルが残るのが嫌だったのでリストア対象ディレクトリ内を全て削除してから展開していますが、削除はしないほうが安全かもしれません。
以上です。
データボリュームコンテナについての蛇足
データ永続化のために別途データボリュームコンテナを作成している場合でもローカルストレージなデータボリュームを使用していれば同じこと、docker save や docker export でバックアップというわけにはいかないようです。残念。
DockerのJenkinsコンテナでアクセスログについて悩んでいた
muraveです。
今年の4月にリリースされたJenkins 2系をDocker公式イメージ
で試していたのですが、Webフックからキックしてのビルドを試していて大変ハマリました。Webフックからのアクセス状況とかどうなってんだ?などなどtcpdumpとか使って調べてたんですけど、アクセスログもあったほうがいいよね、と思ったのでした。
公式イメージのJenkinsさんってそのまま立ち上げたらアクセスログ出してくれないんですよね。
調べまして、JENKINS_OPTSに
--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=ログファイルのパス
てな感じで設定すれば良いことはわかりました。分かりましたが、コンテナ内やボリュームにログファイルを出すのは違う気がします。docker logs で見ることができるログはどういう扱いなんでしょう?
デフォルト設定のロギング・ドライバのログ(JSON形式)はホストの
/var/lib/docker/containers/(コンテナID)/(コンテナID)-json.log
にあって、これが docker logs の表示元になっています。
問題はどうやったらここに出力されるのか?ですが、標準出力、標準エラー出力へ出力すれば良いそうです。例えば、Nginx公式イメージのDockerfileでは
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
と、/dev/stdout と /dev/stderr へのシンボリックリンクを作成することで対応しているようです。
Jenkinsさんの場合は先ほどのJENKINS_OPTSでログファイルのパス指定が可能でしたので
--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/dev/stdout
と設定すると標準出力に出力されるようになり、コンテナのログにJenkinsさんへのアクセスログが記録されるようになりました。
これでDockerのロギング・ドライバでアクセスログも統一的にあつかえますね。
例えばFluentdロギング・ドライバに切り替えてログ集約するようにしたりする場合にも安心です。
Docker for Mac の使用されていないデータボリュームを削除
murave@ファイルの権限絡みで -v オプションの事を調べていたら今日という日が終わりそう、です。
やりたいことは別にあったんですが、せっかく調べたのでメモを残しておきます。今回、結論は最後に書くので経緯とか読みたくない方は最後まで飛ばして下さい。
データボリュームっていうのは例えば、
$ docker run -v コンテナ上のディレクトリ名 busybox
$ docker volume create --name test-volume
などとすると、
$ docker volume ls
DRIVER VOLUME NAME
local 17e11ebb9fc56e18d99b175d77b0c37b90da561bff07d601279ab7bfc0b0f414
local test-volume
と言った感じでデータボリュームがホスト上に出来ます。
ランダム文字列な名前のほうは前記docker runのように名前未指定な場合によろしくやってくれてるわけです。問題なのが、コンテナを削除しても基本的にこれが残るってこと。
「開発用RDBをゲットだぜ」シリーズの調査中
$ docker rm -f $(docker ps -aq)
でバンバン動作しているコンテナを含めて全部削除しまくっていたのですが、datastoreのデータボリュームが残りまくっているってわけです。
消さねばならぬ。
Docker公式イメージで開発用RDBをゲットだぜ(MariaDB、Percona Server編)
まえがき
Docker公式イメージで開発用RDBをゲットだぜ(PostgreSQL編)
Docker公式イメージで開発用RDBをゲットだぜ(MySQL編)
に続き予定どおりMariaDB編をお送りします。一言で済むので結論を書くと
「公式イメージのページを読み比べたらMySQLと同じでした。ありがとうございます」
という内容です。ついでに
Docker Hub で Official縛りでMySQLを検索したらPerconaも出てきたので思い出したりした。定期的にPercona良さそうだなぁと思って名前を忘れるを繰り返す存在。
— murave (@murave) 2016年8月16日
というわけでPercona Serverの公式イメージのページも見てみたらこれもMySQLの場合と同じ扱いでしたので含めてみましたよ。
Docker for Macを使用しております。
Docker公式イメージで開発用RDBをゲットだぜ(PostgreSQL編)
- 2016/08/16
- murave
- Docker
- PostgreSQL
まえがき
Laravelでの開発時にデプロイ先はMySQLなのに手を抜いて手元の開発機ではSQLiteを使っていたら痛い目にあったりしました、muraveです。
SQLiteって結構ルーズにつかえてしまうので手元の開発でSQLite使っててMySQL運用のサーバーにデプロイするとエラーがバンバンというのが昨日から連続発生中。
— murave (@murave) 2016年7月14日
開発環境にあまり影響を与えずにサクッと開発用のRDB(Relational Database)を建てられると素敵ですね。Docker公式イメージを活用すると出来そうです。
RDBというデッカイ単語を使っていますが、自分がよく使うPostgreSQL、MySQL、MariaDBなどについて調べようと思います。MySQLとMariaDB自体はほぼ同じ扱い方ができるRDBですが、公式イメージでの扱いはどうなんでしょうね。
記事にまとめながら試していこうと思います。Docker for Macを使用しており、今回はPostgreSQLです。