dockerコマンドをsudoの付与無しに実行できるようにする – guro_chanの手帳
OS: Ubuntu Server 18.04.1 LTS docker: 18.09.0 dockerコマンドを打ち込む度にsudoを付加するのはしちめんどうな手続きであるけれどもrootユーザにスイッチして操作をするのも甚だしく物騒であるから、何らかの細工を施して一般ユーザでsudo無しにdockerコマンドを実行できれば大変楽ちんである。 けれども安全性を鑑みると無闇にdockerコマンドがsudo無しで実施できるようになるのはやはり大きな懸念材料となる模様である。せめて信頼のおけるユーザだけに許すなど細やかな配慮が求められる情勢であった。しちめんどうであるからといって横着してはいけないのである。 そう云う事情をすべて飲み込んだうえで作業を進めてゆく。まずdockerコマンドをsudo無しで実施するとエラーメッセージが現れて直ちに処理が終いとなる。 $ docker images G
DockerfileにてなぜADDよりCOPYが望ましいのか - Qiita
はじめに Docker公式のBest practices for writing Dockerfilesに ADDよりもCOPYが望ましい(ADDは使わない方が良い)との記述があるのを見つけたのでその理由を確認してみました。 TL;DR 理由は以下の2つに分けることができます。 ① Imageサイズの観点 ② セキュリティの観点 そもそもCOPYとADDはどう違うのか こちらの記事にて端的にまとめられていたので日本語訳してしまいます。 COPY - 明示的なコピー元とコピー先のファイルまたはディレクトリを指定して、ローカルファイルを再帰的にコピーします。 COPYでは、場所を宣言する必要があります。 ADD - ローカルファイルを再帰的にコピーし、存在しない場合は暗黙的にコピー先ディレクトリを作成し、アーカイブをコピー元としてローカルURLまたはリモートURLとして受け入れます。アーカイブ
Dockerコンテナ内からホストへ`localhost` でアクセスしてみる - Qiita
のっぴきならぬ事情でDockerコンテナ内からホストへlocalhost でアクセスする必要なときに役立ちそうなのでメモ。 Dockerコンテナ内からホストへアクセスするには こちらの記事が参考になりました。 --add-host オプションを利用すればなんとかなりそうです。 Dockerのコンテナの中からホストOS上のプロセスと通信する方法 - Qiita https://qiita.com/Iju/items/badde64d530e6bade382 localhost じゃなくて良いのなら host.docker.internal というDNS名が用意されているので、それを利用すればよさそうです。 ドキュメントによるとMac/Windowsで利用できそうです。 Networking features in Docker Desktop for Windows | Docker Doc
Alpine Linux でタイムゾーンを変更する - Qiita
スリムな Docker イメージを作るため、gliderlabs/alpine イメージをベースにバイナリを一個だけポンと置いて運用するみたいなことをしています。 gliderlabs/alpine イメージは（というかほとんどの OS イメージは）タイムゾーンが GMT (UTC+0) のままなので、時刻依存の作業をさせるときには気をつけないといけません。日本時間 (UTC+9) の感覚で書いたら、9時間遅れて実行されたとかログの時刻がずれるとか起こりえます。 まっさらの状態で date を打つと… タイムゾーンの設定 メジャーな Linux ディストリビューションと同じく、/etc/localtime を変更すればよいです。zoneinfo とかはそのままだと用意されていないので、apk で tzdata パッケージをインストールする必要があります。 Dockerfile で日本標準時
docker-compose upするとコンテナが一瞬でexited with code 1する話 - Qiita
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でコンテナの停止・削除ができなくなった時の対処法 - Qiita
発生した現象 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
docker で使ってないイメージを全部消す時の Tips - Qiita
> docker images -a REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE <none> <none> c395172a74e5 8 hours ago 1.151 GB <none> <none> 05a17381460b 8 hours ago 1.151 GB <none> <none> eb3ce0796961 8 hours ago 1.141 GB ... こんな感じのなんのこっちゃわからない出力になります。イメージが削除されない場合でも Untagged だけはされてしまうので、本当に無名のイメージがぞろぞろ並ぶ不気味な光景です。 なので、イメージの一括削除時には
docker images を全削除する - Qiita
はじめに コンテナが動いているとイメージを削除できないので、本当に全削除したいときはコンテナから全削除する。 コンテナを全削除する
dockerのENTRYPOINTとCMDの書き方と使い分け、さらに併用 - Qiita
2019-06-01 追記 この記事より DockerfileのCMDとENTRYPOINTを改めて解説する - Qiita のほうがお勧めです。 元記事 Dockerfile referenceやDockerfile Best PracticesにENTRYPOINTとCMDの書き方と使い分け、さらに併用について書かれていました。 ENTRYPOINTとCMDの引数の書式 ENTRYPOINTの書式は以下の2種類があります。 ENTRYPOINT ["executable", "param1", "param2"] (シェルを介さずに実行。この形式を推奨) ENTRYPOINT command param1 param2 (シェルを介して実行) シェルを介して実行するほうは/bin/sh -cを使って実行するそうです。 CMDの書式は以下の3種類です。 CMD ["executable"
[docker] COPY とADD の違いを試してみた - Qiita
概要 Dockerfile にCOPY とADD ってあるけど同じように見えるけどなにが違うのかわからないから調査とそのメモ 環境 OS : cent7.1 [root@docker-engine /]# docker version # Client: # Version: 1.8.1 # API version: 1.20 # Go version: go1.4.2 # Git commit: d12ea79 # Built: Thu Aug 13 02:19:43 UTC 2015 # OS/Arch: linux/amd64 # # Server: # Version: 1.8.1 # API version: 1.20 # Go version: go1.4.2 # Git commit: d12ea79 # Built: Thu Aug 13 02:19:43 UTC 2015
![[docker] COPY とADD の違いを試してみた - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3e4579b7bef49e91c983e9a0eb14a5b80b3b021c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCZG9ja2VyJTVEJTIwQ09QWSUyMCVFMyU4MSVBOEFERCUyMCVFMyU4MSVBRSVFOSU4MSU5NSVFMyU4MSU4NCVFMyU4MiU5MiVFOCVBOSVBNiVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MSU5RiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2IxMjQ2ZWI2ZDg1MzQzMDFjOWIzMjkxZGI1N2FlZWQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGloaWhpcm9ybyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YmQ2ZDI2MTMxMTc3ZTU5NWFiZjM3YzQ0Y2QyZDAxYjA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dce8043359307af298ca37ef9d4849197)
Docker - Rpmdb checksum is invalid: dCDPT(pkg checksums): xxxx.amzn1 — u 対処法
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コンテナの中のサービスを自動起動したい
質問はタイトルとおりです。 環境：ubuntu15.04 docker 1.8.3 コンテナ：ubuntu14..04 やったこと 自動起動コマンドsystemctlコマンドがコンテナの中では、なかったため [apt-get -y install sysv-rc-conf]で自動起動してくれるものを導入 sysv-rc-conf postfix on exitでコンテナを終了させて、startで起動 ｐｓ aux | grep postfix なにも出ませんでした。 sysv-rc-conf -list runlevel -listでonになっているrunlevelを確認 現在のランレベルを知りたくてrunlevelコマンドを実行 unknownとでてきました。 どうしたら、コンテナの中でサービスを自動起動できますか？ 現在のrunlevelがunknownにも疑問を持ちます。 よろしくお
Dockerコンテナ内で操作 attachとexecの違い
7/16 hidekuroサンからのコメントを受けて修正 Dockerのコンテナで動作中のシェルへの接続方法 sshdをコンテナ内に立てることなしにシェルに接続する方法として以下の2つがある。 docker attach コンテナ名 docker exec -it コンテナ名 /bin/bash じゃあ、この2つの違いってなによ? ということで整理してみた。 docker attach コンテナ名 こっちは単純にdockerコンテナ内で既に起動しているシェルの標準出力につなげるイメージ？？ コンテナで起動しているPID=1のプロセスの標準入出力(STDIN/STDOUT)に接続(attach)する。 docker exec -it コンテナ名 /bin/bash こっちはdockerコンテナで任意のコマンドを実行させる。 -itオプションについては意味合いは以下の通りらしい オプション名
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker Toolbox の移行 — Docker-docs-ja 19.03 ドキュメント
dockerコマンド実行時にエラー"Got permission denied while trying to connect to the Docker daemon socket"が出るとき | akamist blog
Change ImageMagick policy on a Dockerfile
Invalid top-level property "network_mode" from docker-compose
Docker Toolboxのディスク容量を増やす - docker - Program QA
docker-composeで起動したコンテナにbashで入ったりコマンドを渡す - Qiita
[docker] コンテナを一括削除 - Qiita![[docker] コンテナを一括削除 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/687252aa76d5b6542a40929889ec71d7c571c314/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZG9ja2VyJTVEJTIwJUUzJTgyJUIzJUUzJTgzJUIzJUUzJTgzJTg2JUUzJTgzJThBJUUzJTgyJTkyJUU0JUI4JTgwJUU2JThCJUFDJUU1JTg5JThBJUU5JTk5JUE0JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01N2NiMTE5OWM3MzJjMTAwNTg2YWViZTE2MDM3NWNiOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrYWJpNW4mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTNiM2UwYmNmZmJiNjFjOTNkZDFmNGUzYzk5NTY1NWRj%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd4e1f350765e8dc40475637cdb1eafb0)
