まだDocker勉強中ですが情報の共有を。 困っていたこと docker-compose upしたときに以下のようなエラーが出て困っていました。 docker-compose.ymlでのvolumeのマウントに失敗しているようです。 ERROR: for browser Cannot create container for service browser: invalid bind mount spec "C:\\Users\\xxx\\workspace\\eccube-codeception\\tests\\_support\\_downloads:/home/seluser/Downloads:rw": invalid volume specification: 'C:\Users\xxx\workspace\eccube-codeception\tests\_support\_d
WindowsのDocker Toolbox上でdockerを動かしているのですが、最近はWindowsでもdocker-composeも使えるようになっています。 なのですが、普通にdocker run -vではマウントできる設定でも、docker-composeでvolumes指定を使ってマウントを行おうとすると、エラーが出てマウントできないという問題がありました。 調べてみると同様の報告が見つかり、どうやら「Windows用にパスの書式を変換する」という指定が必要らしく、 COMPOSE_CONVERT_WINDOWS_PATHS=1と環境変数が設定されていると良いようでした。 docker compose volume mounts not work on Windows · Issue #4303 · docker/compose https://github.com/docke
環境 Windows 7 DockerToolbox docker-compose 1.9.0 docker 1.12.5 VirtualBox 5.1.10 問題発生 laradockでdocker-compose upできなくなった! 原因 docker-composeのCHANGE LOGを参照したところ、下記の記述がありました。 Breaking changes When using Compose with Docker Toolbox/Machine on Windows, volume paths are no longer converted from C:\Users to /c/Users-style by default. To re-enable this conversion so that your volumes keep working, set the e
dockerでvolumeをマウントするときの問題点 docker runするときに-vオプションをつけることによってホストのディレクトリをコンテナ内にマウントすることができる。 ホスト側のファイルをコンテナ内で使いたい場合や、逆にコンテナで作ったファイルにホストからアクセスしたい場合に有用なのだが、ファイルのアクセス権限についてちゃんと考えておかないと問題が起きることがある。 例えば、ホスト内でのユーザーのuidが500だったとしよう。 $ id uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),497(docker) $ mkdir -p temp && touch temp/foo # 実験用に適当なディレクトリを作ってみる $ docker run -it -v $(pwd)/temp:/temp
TL;DR DockerでRailsとDBのコンテナを作成しWebアプリケーションを作成してたところ ブラウザ上では日本語が文字化けしないがdbコンテナの中に入ってmysqlにログインすると ???? に文字化けしている現象に遭遇した。 対象読者 or 前提条件 or 環境 DockerでMySQLコンテナを使用するマルチバイトなひと まずは調査 「Docker mysql 文字化け」でぐぐってみるとどうやら character_set_server=utf8 でないと発生するという記事が大量にヒットする。 Docker公式イメージのMySQLで文字コードを指定するのエントリを参考に過去にdocker-compose.ymlには対応を実装していたのでどうやらこれが問題ではなかった。 そもそもなにが原因で文字化けしてるのかがわからなかったので調べてみた。 $ mysql mysql> sta
WindowsにVagrant(VirtualBox) + Dockerで開発環境を構築していた際に上記の現象に遭遇した。VMのOSはCoreOS。 具体的には、docker-compose run {コンテナ名} bashは通るのに、docker-compose upすると コンテナが一瞬でexited with code 1するという状態。 その時に出ていたログはこちら。 standard_init_linux.go:178: exec user process caused "no such file or directory" 色々と調べまくっていたのですが、こちらで原因を発見。 原因は改行コードで、コンテナの起動時に実行しているstart.shを秀丸でいじっていたことが原因。 いつの間にか改行コードがCRLF(Windowsの標準)になっていた模様。LF(Linux/UNIXの標
発生した現象 docker-compose up -dで起動したコンテナ群を停止しようとしたとき、docker-compose stopとし、docker-compose psで停止を確認したところ、 Name Command State Ports -------------------------------------------------------------------------------- test_apache-php_1 apache2-foreground Up 0.0.0.0:80->80/tcp test_mysql_1 docker-entrypoint.sh mysqld Up 3306/tcp test_phpmyadmin_1 /run.sh Up 0.0.0.0:8080->8080/tcp
これは、node.js on Docker の構成で 2〜3日ハマってしまった時の話です。忘れないように記録しておきます。なお、将来は改善・改良されているかもしれませんのでご注意ください。 何が起こったのか node.js の Docker コンテナを、"docker stop" でコンテナを止めようとしても正常に停止せず、10秒くらい経過した後に強制終了してしまうという症状が発生しました。いつも等しくそうなるので、状態とかタイミングとかそういった要因ではなく、そもそも根本的に何かがおかしいと考えられます。 1. node on Docker の構成 Docker コンテナ上で node.js が動いているだけの極めてシンプルな構成でこの問題が発生しました。 node.js で動くアプリは、"Hello World" を出すだけの超簡単な hello.js です。こんな感じです。 cons
※CONTAINER ID、IMAGE、NAMESは実際の名前ではありません。 見やすさ、情報保護の観点で変更しております。 つまづいたこと 今、起動中のコンテナが以下だとします。 hogepc$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e925a1effaXX hogehoge "/bin/sh -c 'npm s..." 26 seconds ago Up 40 seconds 0.0.0.0:3000->3000/tcp hogehoge_1 a3592697efXX fugafuga "/bin/sh -c '/go/b..." 28 seconds ago Restarting (1) 6 seconds ago fugafuga_1 f4833db08dXX piyopiyo "docker
AWS Monitoring SRE srest [SRE][Monitoring]イベントログの一元監視サービス「srest」を使ってみた!良さそう👀 ITインフラの“体調”を一元監視で早期に異常検知 https://t 続きを読む… 投稿者:adachin 投稿日時:3か月2024/03/25前 SRE 勉強会/交流会 [2024/02/14][Findy]TechBrew in 東京 〜SRE大集合!信頼性を高める取り組みに参加してきたSRE飲みワッショイ🍺!清水さんの昔話が盛り上がった!明日はFindyの「Tec 続きを読む… 投稿者:adachin 投稿日時:4か月2024/02/15前 DigitalOcean Kubernetes PHP WordPress [DigitalOcean][Kubernetes]WordPressをPHP7.4から8.3にバージョンアップし
2016-08-23 追記 docker-engineが1.12.1にバージョンアップして少し修正が入った。 docker-engine 1.12.1 Releasenote Security - Allow systemd to run with only --cap-add SYS_ADMIN rather than having to also add --cap-add DAC_READ_SEARCH or disabling seccomp filtering #25567 関連issue/PR https://github.com/docker/docker/pull/25567 https://github.com/docker/docker/issues/25516 しかしseccompのプロファイルで実際に変更されている部分を確認してもmount/umount等は追加され
通常、docker-compose up -dをすれば、docker-composeで指定されたサービスに紐付くコンテナが起動すると思います。 ところが、なぜかdocker-compose upでコンテナが起動しても、すぐに落ちてしまうことがありました。 具体的には下記のような状態になります。 $ docker-compose up Name Command State Ports ------------------------------ test /bin/bash exit 0 しかし、下記のようにdocker runでは起動できる。 ※このdocker-composeではDockerfileをbuildするようにしていた。 $ docker run --name test -ti centos:latest /bin/bash 分かる人にはこれだけみてすぐわかる方もいると思います
bash でやる場合下記のコマンドを実行してから yum install xxxx をやる # rpm --rebuilddb# yum install -y yum-plugin-ovlDockerfile でやる場合一行で書いたあとに yum install xxxx をやる RUN rpm --rebuilddb; yum install -y yum-plugin-ovlTIPS今回の件には関係ないけど、docker の状態確認 スクリプト が提供されているので困ったら叩いてみてもいいかも # curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh | bash - % Total % Received % Xferd Average Speed Time Time Ti
Dockerの未使用ポートで"port has already been allocated"が出たらサービス再起動すべし(メモ)DockerCoreOS 参考ページ CentOS 7/docker1.0.0でハマったところメモ. あらまし 結構頻発するんですよね、この現象。「sudo docker run -p xxxx:80 --name foo/bar」と入れても、xxxxが使用中だよーと怒られます。そして溜まっていく未稼働コンテナ。 どう対処するか dockerの再起動。 コマンド systemctl restart docker 補足 CentOS7で使われているsystemctlについて少しまとめた 恥ずかしながら、systemdを初めて知りました。 だってubuntuだとまだexperimentalなんだもん。 Register as a new user and use Q
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く