「docker」タグアーカイブ

Found orphan containers

コメントを残す

docker-composeを新たに作成して実行したところ以下のワーニングが出た。

WARNING: Found orphan containers (proxy_letsencrypt-nginx-proxy-companion_1, nginx-proxy) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

こちらにあるように他のdocker-composeとの名前重複が原因。

]新しいdocker-composeだとドキュメントによると以下のようにname要素(top level element)が存在し名前重複を避けられるそう。ただ、一時期バグがあって使えない時期もある模様。

name: myapp

services:
  foo:
    image: busybox
    command: echo "I'm running ${COMPOSE_PROJECT_NAME}"

対応していないと思われる私の環境では以下のエラー

ERROR: The Compose file './docker-compose.yml' is invalid because:
Invalid top-level property "name". Valid top-level sections for this Compose file are: version, services, networks, volumes, secrets, configs, and extensions starting with "x-".

現在の環境は長く使わない予定なので他の暫定対処を選択する。

環境変数にCOMPOSE_PROJECT_NAMEを指定しても同じ効果があるそうなので。docker-compose.ymlと同じディレクトリに.envを以下内容で作成。

COMPOSE_PROJECT_NAME=momoyama_shop

そしてdocker-compose buildをすると以下のように指定したcompose_project_nameを持つイメージが作成された。

Building front
Step 1/2 : FROM nginx
 ---> 92b11f67642b
Step 2/2 : RUN echo 'server_tokens off;\n' > /etc/nginx/conf.d/my_default.conf
 ---> Using cache
 ---> 597e7dfaab23

Successfully built 597e7dfaab23
Successfully tagged momoyama_shop_front:latest

jenkins pipeline内のpostgresにてDBダンプ取得

コメントを残す

環境

CentOS Linux release 7.5.1804 (Core) DockerのHostマシン
Jenkins 2.138.1
Docker Commons Plugin
Docker Pipeline
postgres 11(公式のdocker-image latest)

やりたかったこと

他のDBサーバからデータを持って来てダンプファイルを作りたかった。

動いたJenkinsfile設定

.pgpassを任意のパス（ここではhostの/ci/app/hoge）に置き、そのパスをvオプションでマウント、さらにマウントしたファイル(ここでは/root/.pgpass)をeオプションで指定。

    
pipeline {
  agent none
  stages{
    stage('DBコピーフェーズ') {
      agent {
        docker {
          image 'postgres'
          args '-v /ci/app/hoge:/root -e PGPASSFILE=/root/.pgpass'
        }
      }
  
      steps {
        sh 'pg_dump -h ホスト名 -p 5432 -U ユーザ名 DB名 > /root/test.sql'
        sh 'echo DBコピー'
      }
    }
  }
}

動かなかった設定

.pgpassを任意のパス（ここではhostの/ci/app/hoge）に置き、そのパスをホームディレクトリとして環境変数で指定。

args '-v /ci/app/hoge:/home/ciuser -e HOME=/home/ciuser'

postgresコンテナ内の環境変数にはHOMEが反映されているが.pgpassは読み込まれなかった。
多分
getpwuidで実行ユーザ(uid1000)で環境変数ではなく/etc/passwdからホームを取得しようとする
postgresコンテナにはuid1000のユーザはいないからホームディレクトリが取得できない（echoしてみたら/で表示されてはいた）
/には.pgpassが無いからエラー
という流れと思うが調査は途中でやめた。

dockerで起動したdnsmasqとvagrant(libvirtd)のdnsmasqがport競合

コメントを残す

dockerでdnsmasqを手軽に起動しようとしたら53番がすでにうまっていた。
なにで使っていたっけとみてみるとvagrant(libvirtd)が内部で使用する用のdnsmasqがすでに立ち上がっていた。

ググってみたところhostで直接dnsmasqを立てているときの解決法はでてきた。

起動準を気にしないでお異様にlibvirt側の設定からリッスン（バインド？）するのを絞って（＋docker側でも絞って）競合しないようにしたいけど、上の解決策が公式にあるってことは、libvirtの設定でlibvirtのdnsmasqをいじるのは難しいのかな？libvirtのdnsmasq.confは自動生成だから直接これを変わっていいものでもなさそうだし。

最近はdockerばっかでvagrant触ることもほとんどないのでとりあえず止めとくか。。。

ownCloudの設定(docker-compose+cifs/netshare) 失敗

コメントを残す

※こちらは(多分)NASの権限設定周りの問題でうまく動きませんでした。

dockerのcifsボリュームマウントはできたのでdocker-composeにてownCloudの設定。

データディレクトリはボリュームプラグインでマウントしているNAS(Cifs)

ownCloudの前面にnginx-proxyとjrcs/letsencrypt-nginx-proxy-companionを使ってSSL化しているのでそちらがらみの設定もあり。（青字部分）

/var/www/html/dataのパーミッションがおかしくなっていたので確認中。
->別件のトラブル起きたので後回し（飲みながらやってたら、NASマウントしたままrm -rfをしてしまった。。。）

docker-volume-netshareを起動するときにuid,gidは指定しないといけなかった。また、NAS側のユーザがパーミッション与えておかないといけない（よう）だが、NASの設定があまりうまくいかないのでownCloudのデータボリュームとして使うのはあきらめた。
（ownCloud初回アクセス時に、パーミッションとオーナーを書き換える処理が走るが、既存のNAS設定と共有してうまく走らせるのは厳しかった）

 



version: ‘3.1’


services:


owncloud:

 image: owncloud

 restart: always

 ports:

 – 80

 environment:

       VIRTUAL_HOST: ホスト名

       LETSENCRYPT_HOST: ホスト名

       LETSENCRYPT_EMAIL: Lets’sEncliptの連絡先

 networks:

 – default

       – mydcproxy_default

 volumes:

 – nasvolume:/var/www/html/data


mysql:

 image: mariadb

 restart: always

 environment:

 MYSQL_ROOT_PASSWORD: パスワード

 networks:

 – default


volumes:

 nasvolume:

 driver: cifs

 driver_opts:

 share: 192.168.1.n/path

 domain: ドメイン名

 dirMode: 770

 fileMode: 660


networks:

   mydcproxy_default:

     external: true

					

		
		
	



	

				

			



						

				dockerのnetshareプラグインSystemd設定(CIFS)
			

										

					コメントを残す				

					


		

		

			
さっきの作業で手動起動になっていたdockerのnetshareプラグインのマウントをSystemdに設定する。


まずは、起動用のシェルを準備。


sudo vi /opt/mountnas.sh
sudo chmod 0755 /opt/mountnas.sh


中身


#!/bin/bash

docker-volume-netshare cifs --domain ドメイン名　（※）





※domainはdocker実行時にも指定できるので削除


また、uid,gidはdocker実行時には指定できないので必要があればここで指定するしかない

その場合は下のようにdocker-volume-netshare起動時にオプション指定しておくことになるがSystemdに設定するとuid,gidがいつも同じになってしまう。きれいに動かしたかったら、プラグインカスタマイズしてdocker実行時にuid,gidを指定できるようにするしかないのかな？


docker-volume-netshare cifs -o uid=hoge,gid=fuga


次にUnit定義ファイル


sudo vi /etc/systemd/system/mountnas.service


中身


[Unit]
Description=Mount NAS as Docker Volume Service

Before=docker.service

[Service]
ExecStart=/opt/mountnas.sh

[Install]
WantedBy=multi-user.target



sudo systemctl enable mountnas
sudo systemctl start mountnas


$sudo systemctl status mountnas -l
● mountnas.service - Mount NAS as Docker Volume Service
   Loaded: loaded (/etc/systemd/system/mountnas.service; enabled; vendor preset: disabled)
   Active: active (running) since 日 2018-01-21 17:57:27 JST; 55s ago
 Main PID: 3986 (mountnas.sh)
   Memory: 952.0K
   CGroup: /system.slice/mountnas.service
           tq3986 /bin/bash /opt/mountnas.sh
           mq3988 docker-volume-netshare cifs --domain EPEAGR

 1月 21 17:57:27 localhost.localdomain systemd[1]: Started Mount NAS as Docker Volume Service.
 1月 21 17:57:27 localhost.localdomain systemd[1]: Starting Mount NAS as Docker Volume Service...
 1月 21 17:57:27 localhost.localdomain mountnas.sh[3986]: time="2018-01-21T17:57:27+09:00" level=warning msg="Error: open .netrc: no such file or directory"
 1月 21 17:57:27 localhost.localdomain mountnas.sh[3986]: time="2018-01-21T17:57:27+09:00" level=info msg="== docker-volume-netshare :: Version: 0.34 - Built: 2017-05-29T13:06:34-07:00 =="
 1月 21 17:57:27 localhost.localdomain mountnas.sh[3986]: time="2018-01-21T17:57:27+09:00" level=info msg="Starting CIFS :: netrc: , opts:


warningで「.netrcないからエラー」とかいわれているけど、認証情報はshellから入れているのでたぶん気にしなくてOK


念のため、再起動して動作確認


sudo shutdown -r now
systemctl status mountnas


次はownClowdの設定

					

		
		
	



	

				

			



						

				CentOS7にdockerのnetshareプラグイン設定(CIFS)
			

										

					コメントを残す				

					


		

		

			
CentOS7上で動かしているdocker(ownCloud)でボリュームにNASを使いたいのでcifsを使えるというnetshareプラグインを設定してみる。


公式によるとDebian/Ubuntu以外はバイナリ入れるかgoでコンパイルしろとのこと。


コンパイルしようとしたらgo getの段階でおこられた。


go get github.com/ContainX/docker-volume-netshare
# github.com/ContainX/docker-volume-netshare/netshare/drivers
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/ceph.go:44: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/ceph.go:68: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.go:76: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/cifs.go:128: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:23: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:23: undefined: volume.Request
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:47: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:47: undefined: volume.Request
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Response
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: undefined: volume.Request
../../../go/src/github.com/ContainX/docker-volume-netshare/netshare/drivers/driver.go:61: too many errors


リファクタリング派手にしてこわれているまま？（こちら）

数日後にフォークして修正したと同じスレッドに書き込まれていた。（自分では未コンパイル）


バイナリをダウンロードすることに変更


wget https://github.com/ContainX/docker-volume-netshare/releases/download/v0.34/docker-volume-netshare_0.34_linux_amd64-bin
sudo mv docker-volume-netshare_0.34_linux_amd64-bin /usr/bin/docker-volume-netshare
chmod 755 /usr/bin/docker-volume-netshare
chown root:root /usr/bin/docker-volume-netshare


動くこと確認


docker-volume-netshare -h
docker-volume-netshare (NFS V3/4, AWS EFS and CIFS Volume Driver Plugin)

Provides docker volume support for NFS v3 and 4, EFS as well as CIFS. This plugin can be run multiple times to
support different mount types.

== Version: 0.34 - Built: 2017-05-29T13:06:34-07:00 ==

Usage:
docker-volume-netshare [command]

Available Commands:
ceph run plugin in Ceph mode
cifs run plugin in CIFS mode
efs run plugin in AWS EFS mode
nfs run plugin in NFS mode
version Display current version and build date

Flags:
--basedir string Mounted volume base directory (default "/var/lib/docker-volumes/netshare")
--port string TCP Port if --tcp flag is true. :PORT for all interfaces or ADDRESS:PORT to bind. (default ":8877")
--tcp Bind to TCP rather than Unix sockets. Can also be set via NETSHARE_TCP_ENABLED
--verbose Turns on verbose logging

Use "docker-volume-netshare [command] --help" for more information about a command.


LAN内でNASに無制限アクセスできる場合は（参考:Launching in Samba/CIFS modeあたり）


sudo docker-volume-netshare cifs --domain ドメイン名（windowsだとWORKGROUPとかになってるやつ）




で、docker用にボリュームマウントしておいて


docker run -it --volume-driver=cifs -v CIFSのパス):/mount ubuntu /bin/bash


とdockerを起動してやる。cifsのパスは先頭の//が不要なので注意。


 


これで、動くみたいだけどこのままだとサーバ再起動のたびにマウントしなくてはいけないので、Systemdに登録しておく。


長くなったのでこちら

					

		
		
	



	

				

			



						

				まだ動いてなかった
			

										

					コメントを残す				

					


		

		

			
docker-machineでcreateしたdockerだけど、離席から帰ってきたら動いていなかった。


[yoshitake@localhost docker-repo]$ docker-machine ls
NAME    ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
testsv   -        generic      Stopped                                       Unknown


離席前にリモートのサーバrebootかけてたな。

いったんdocker-machine rmしてから作り直そうとしたけど繋がらなそう。

直に通常のssh接続しようとしても繋がらず。


単純にssh繋がらないだけっぽい。

ということでさくらVPSなので管理画面から接続。


やったことを改めて思い返すとdocker-machine入らなかったのでSELinux一時停止して試したままだった。んで、ssh port変更したけどSELinuxの設定していない。


（ここからVPNの管理コンソールなのでコピペはなし）

semanage port -l| grep ssh　で新しいポート表示されず。

semanage port -a -t ssh_port_t -p tcp nnnnn　もした履歴無し。

jarnalctl -xe にsshd上げるときにポートのパーミッションがなくてバインド失敗したメッセージが出ていました

					

		
		
	



	

				

			



						

				docker-machineが古かった
			

										

					コメントを残す				

					


		

		

			
docker-machineでCentOS7に入れたdockerが起動しなかった。


インストール元


Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with centos...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: exit status 5


インストール先


[root@testsv system]# systemctl status docker.service -l
 * docker.service - Docker Application Container Engine
 Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
 Active: inactive (dead) since Wed 2017-05-10 18:15:08 JST; 28min ago
 Main PID: 13716 (code=exited, status=0/SUCCESS)

May 10 18:15:03 testsv dockerd[13716]: time="2017-05-10T18:15:03.609609938+09:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
 May 10 18:15:04 testsv dockerd[13716]: time="2017-05-10T18:15:04.102333287+09:00" level=info msg="Loading containers: done."
 May 10 18:15:04 testsv dockerd[13716]: time="2017-05-10T18:15:04.124630882+09:00" level=info msg="Daemon has completed initialization"
 May 10 18:15:04 testsv dockerd[13716]: time="2017-05-10T18:15:04.124714583+09:00" level=info msg="Docker daemon" commit=89658be graphdriver=overlay version=17.05.0-ce
 May 10 18:15:04 testsv dockerd[13716]: time="2017-05-10T18:15:04.146221898+09:00" level=info msg="API listen on /var/run/docker.sock"
 May 10 18:15:04 testsv systemd[1]: Started Docker Application Container Engine.
 May 10 18:15:07 testsv systemd[1]: Stopping Docker Application Container Engine...
 May 10 18:15:07 testsv dockerd[13716]: time="2017-05-10T18:15:07.527842954+09:00" level=info msg="Processing signal 'terminated'"
 May 10 18:15:07 testsv dockerd[13716]: time="2017-05-10T18:15:07.53054844+09:00" level=info msg="stopping containerd after receiving terminated"
 May 10 18:15:08 testsv systemd[1]: Stopped Docker Application Container Engine.


症状をみるとこれっぽい。日付けをみるとだいぶ古いけど、masterには取り込まれているから〜といっている。ちゅうことは、docker-machineが古いな。


日本語ドキュメントのワンライナー手順で入れたけど、リリースページを確認するとにほんご頁よりも大分バージョンが上がっている。

リリースページの手順で再インストール。


Provisioning with centos...
Error creating machine: Error running provisioning: something went wrong running an SSH command
command : sudo systemctl -f restart docker
err     : exit status 5
output  : Failed to restart docker.service: Unit not found.


そのままもう一回docker-machine rm -> docker-machine createは失敗。

インストール先で

rm /etc/systemd/system/docker.service

と

yum remove docker-engine

したら取り敢えず入った。


動作確認はこれから

					

		
		
	



	

				

			



						

				Dockerの消せないイメージが残っていた
			

										

					コメントを残す				

					


		

		

			
[root@localhost yoshitake]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest f753707788c5 6 months ago 127MB
[root@localhost yoshitake]# docker rmi ubuntu
Error response from daemon: No such image: ubuntu:latest


[root@localhost yoshitake]# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              f753707788c5        6 months ago        127MB
[root@localhost yoshitake]# docker rmi f753707788c5
Error response from daemon: reference does not exist


何か消せないdocker imageがいた。こちらをみてファイルがあった/var/lib/docker/image/devicemapper/imagedb/contentのしただけ削除


rm /var/lib/docker/image/devicemapper/imagedb/content/sha256/f753707788c5c100f194ce0a73058faae1a457774efcda6c1469544a114f8644
rm: 通常ファイル `/var/lib/docker/image/devicemapper/imagedb/content/sha256/f753707788c5c100f194ce0a73058faae1a457774efcda6c1469544a114f8644' を削除しますか? y


とりあえず、消えてくれた。きちんと動くかな？？

					

		
		
	



	

				

			



						

				Dockerサポート外
			

										

					コメントを残す				

					


		

		

			
会社用メインサーバは秘伝のたれが詰まったCentOS6でミドルも都度都度足していったもので構成よくわからなくなっている。取りあえず、よく使うやつらだけでもDockerに切り出しておこうかと思ったらCentOS6系はもうサポート対象外なのね。昔からあるサーバは特にいじっていなかったから知らなかった。


このまま使い続けるのもより、いっそのこと今OSもCentOS7にあげてしまった方がいいかな。Docker用OSも考えたけど、何かあったときにミドルをコンテナでなくホストに慌ててインストールとか時間かかりそうなので、メインサーバは無難にCentOSにしとく。