ここで作成しているDockerコンテナは、信頼のおけるローカルネットワークのみで動作するホストで運用するものとして構築している。
ホスト上のいずれかのネットワークインターフェイスがインターネットに直接接している場合、このコンテナの運用はセキュリティの観点から非常に危険なので動作させてはいけない。
（インターネットに直に接している場合、Dockerのデフォルトではiptablesを書き換えて外部からのアクセスを許してしまうことになってしまうため厳禁である。）
使用したDockerイメージは下記のページのコンテナからcommitにより作成したものである。
これにより、sshdの導入と、リモート接続もできるようになった。
【Linux CentOS 7】Dockerコンテナへssh接続する方法や、コンテナのイメージ化、削除、起動方法などについて
http://akira-arets.blogspot.com/2018/11/linux-centos-docker-ssh.html
以下では、さらに、rsyslog、Postfix、crondの導入を行った。
○Dockerホストのカーネルは次のバージョンである。
# uname -a
Linux localhost.localdomain 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
また、Dockerのバージョンは次の通り。
名前 : docker-ce
アーキテクチャー : x86_64
バージョン : 18.06.1.ce
リリース : 3.el7
容量 : 168 M
リポジトリー : installed
提供元リポジトリー : docker-ce-stable
○Dockerホストにおいて、上記のイメージと手順によりコンテナを起動した。
（インターネットに直に接している場合、Dockerのデフォルトではiptablesを書き換えて外部からのアクセスを許してしまうことになってしまうため厳禁である。）
# docker run --privileged -d -p 222:22 --name centos7-ssh image-centos7-ssh /sbin/init
○そして、このコンテナ内で設定作業するためコンテナにssh接続した。
$ ssh -p 222 root@192.168.10.3
[root@a42dafc368d1 ~]#
Postfixの設定の前に、rsyslogの導入を行った方が良い。
メールの送信がうまくいかないなど問題を把握するためにはログは必須である。
初期状態では、ログファイルを調べてみたが存在せず、rsyslogが入っていないことがわかった。
[root@a42dafc368d1 postfix]# tail /var/log/
btmp grubby_prune_debug lastlog tallylog wtmp yum.log
■rsyslogの導入
○rsyslogのインストール
[root@a42dafc368d1 postfix]# yum install rsyslog
Installed:
rsyslog.x86_64 0:8.24.0-16.el7_5.4
Dependency Installed:
libestr.x86_64 0:0.1.9-2.el7 libfastjson.x86_64 0:0.99.4-2.el7 logrotate.x86_64 0:3.8.6-15.el7
Complete!
○rsyslogの有効化
[root@a42dafc368d1 ~]# systemctl enable rsyslog
○rsyslogの起動
[root@a42dafc368d1 ~]# systemctl start rsyslog
○状態の確認
[root@a42dafc368d1 ~]# systemctl status rsyslog
● rsyslog.service - System Logging Service次に、Postfixの作業を行った。
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2018-11-15 21:53:10 UTC; 6s ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 325 (rsyslogd)
CGroup: /docker/a42dafc368d16f027930c57b4b4c1b779ab9f1a48e45851b3a0329d08a8df566/system.slice/rsyslog.service
└─325 /usr/sbin/rsyslogd -n
‣ 325 /usr/sbin/rsyslogd -n
Nov 15 21:53:10 a42dafc368d1 systemd[1]: Starting System Logging Service...
Nov 15 21:53:10 a42dafc368d1 rsyslogd[325]: [origin software="rsyslogd" swVersion="8.24.0" x-pid="325" x-info="http://www.rsyslog.com"] start
Nov 15 21:53:10 a42dafc368d1 systemd[1]: Started System Logging Service.
■Postfixの導入
○インストール
[root@a42dafc368d1 ~]# yum install postfix
Installed:
postfix.x86_64 2:2.10.1-6.el7
Dependency Installed:
mariadb-libs.x86_64 1:5.5.60-1.el7_5 systemd-sysv.x86_64 0:219-57.el7_5.3
Complete!
○Postfixの有効化を行い、再起動で自動的に動作するようにした。
[root@a42dafc368d1 ~]# systemctl enable postfix
○Postfixの起動
[root@a42dafc368d1 ~]# systemctl start postfix
Job for postfix.service failed because the control process exited with error code. See "systemctl status postfix.service" and "journalctl -xe" for details.
エラーが発生したので調査した。
下記の通り、IPv6インターフェイスが存在していないためエラーになっているようだ。
[root@a42dafc368d1 ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2018-11-15 21:29:51 UTC; 6s ago
Process: 175 ExecStart=/usr/sbin/postfix start (code=exited, status=1/FAILURE)
Process: 174 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 171 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=75)
Nov 15 21:29:49 a42dafc368d1 systemd[1]: Starting Postfix Mail Transport Agent...
Nov 15 21:29:49 a42dafc368d1 aliasesdb[171]: /usr/sbin/postconf: fatal: parameter inet_interfaces: no local interface found for ::1
Nov 15 21:29:50 a42dafc368d1 postfix/sendmail[173]: fatal: parameter inet_interfaces: no local interface found for ::1
Nov 15 21:29:50 a42dafc368d1 aliasesdb[171]: newaliases: fatal: parameter inet_interfaces: no local interface found for ::1
Nov 15 21:29:50 a42dafc368d1 postfix[175]: fatal: parameter inet_interfaces: no local interface found for ::1
Nov 15 21:29:51 a42dafc368d1 systemd[1]: postfix.service: control process exited, code=exited status=1
Nov 15 21:29:51 a42dafc368d1 systemd[1]: Failed to start Postfix Mail Transport Agent.
Nov 15 21:29:51 a42dafc368d1 systemd[1]: Unit postfix.service entered failed state.
Nov 15 21:29:51 a42dafc368d1 systemd[1]: postfix.service failed.
（以下からコンテナIDが代わりますが無視してください。）
○PostfixにおいてIPv6を無効化した。
デフォルト値はIPv4だけでなく、IPv6も有効になっている。
[root@923d1942dcbb ~]# postconf -d inet_protocols
inet_protocols = allIPv4のみ利用するように設定した。
[root@923d1942dcbb ~]# postconf -e inet_protocols=ipv4
設定した値の確認を行った。
[root@923d1942dcbb ~]# postconf -n inet_protocols
inet_protocols = ipv4
○Postfixの起動を再び試みた。
[root@923d1942dcbb ~]# systemctl start postfix
今度はエラーが発生しなかった。
状態を確認した。
[root@923d1942dcbb ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent動作していることがわかった。
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2018-11-16 16:03:18 UTC; 28s ago
Process: 109 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 108 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 106 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Main PID: 180 (master)
CGroup: /docker/923d1942dcbb471c99fe1295b36836368fbccddfae4eb6c2ac7979cdcc5ff123/system.slice/postfix.service
├─180 /usr/libexec/postfix/master -w
├─181 pickup -l -t unix -u
└─182 qmgr -l -t unix -u
‣ 180 /usr/libexec/postfix/master -w
Nov 16 16:03:17 923d1942dcbb systemd[1]: Starting Postfix Mail Transport Agent...
Nov 16 16:03:18 923d1942dcbb postfix/master[180]: daemon started -- version 2.10.1, configuration /etc/postfix
Nov 16 16:03:18 923d1942dcbb systemd[1]: Started Postfix Mail Transport Agent.
ところで、/etc/hostsの「::1」部分をコメントアウトすることでも、Postfixは起動できたが、
コンテナの再起動に伴ってこのファイルは元に戻ってしまうため、再起動後にPostfixのに失敗した。
そのため、上述の通り、Postfixの設定でIPv6の使用をしないようにした方が良い。
[root@a42dafc368d1 postfix]# vi /etc/hosts
127.0.0.1 localhost
#::1 localhost ip6-localhost ip6-loopbackfe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2 a42dafc368d1
○メール送信テスト
[root@a42dafc368d1 postfix]# echo test | sendmail -f from@example.com to@example.com
送信テストをしたがメールがうまく配送されなかった。
Postfixはデフォルトでsyslogを利用する設定になっている。
[root@a42dafc368d1 postfix]# postconf -d syslog_facility
syslog_facility = mailmaillogというログファイルを確認する。
[root@a42dafc368d1 postfix]# less /var/log/maillog
btmp lastlog messages spooler wtmp
grubby_prune_debug maillog secure tallylog yum.log
ログによると、相手先SMTPサーバーとの接続でConnection time out になっていた。
この際、25番ポートにダイレクトに接続しにいっていることがわかった。
そのため、ISPの25番ポートフィルタに引っかかってしまっているのだと考えた。
そのため、直接に相手先SMTPに接続するのはやめて、ISPなどのSMTPサーバにリレーするようにした。
プライベートネットワーク内に準備しておいた上位SMTPサーバーにリレーするようにした。
[root@a42dafc368d1 postfix]# postconf -e "relayhost = xxx.example.com"
詳しくは、下記ページを参考にしてください。
【Postfix 2.6.6 x86_64】リレーの設定について【Linux CentOS 6.5 64bit】
https://akira-arets.blogspot.com/2015/05/postfix-266-x8664linux-centos-65-64bit.html
Postfixの再起動を行った。
[root@a42dafc368d1 postfix]# systemctl restart postfix
ログを確認した。
[root@a42dafc368d1 postfix]# tail /var/log/maillog
Nov 15 22:11:05 postfix/smtp[657]: : to=<user@example.com>, relay=xxx.example.com:25, delay=396, delays=396/0.02/0.13/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as )
Nov 15 22:11:05 postfix/qmgr[654]: : removed
これでメールの送信ができるようになった。
さらに、Crontabが使えるようにした。
■crondの導入
○パッケージのインストール（CentOS 7以外では、別の方法が必要。）
[root@a42dafc368d1 ~]# yum install cronie
Installed:
cronie.x86_64 0:1.4.11-19.el7
Dependency Installed:
cronie-anacron.x86_64 0:1.4.11-19.el7
crontabs.noarch 0:1.11-6.20121102git.el7
Complete!
○有効化
[root@a42dafc368d1 ~]# systemctl enable crond
○起動
[root@a42dafc368d1 ~]# systemctl start crond
○状態の確認
[root@a42dafc368d1 ~]# systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2018-11-16 15:10:17 UTC; 8s ago
Main PID: 737 (crond)
CGroup: /docker/a42dafc368d16f027930c57b4b4c1b779ab9f1a48e45851b3a0329d08a8df566/system.slice/crond.service
└─737 /usr/sbin/crond -n
‣ 737 /usr/sbin/crond -n
Nov 16 15:10:17 a42dafc368d1 crond[737]: (CRON) INFO (RANDOM_DELAY will be scaled with ...d.)
Nov 16 15:10:17 a42dafc368d1 systemd[1]: Started Command Scheduler.
Nov 16 15:10:17 a42dafc368d1 crond[737]: (CRON) INFO (running with inotify support)
Nov 16 15:10:17 a42dafc368d1 systemd[1]: Starting Command Scheduler...
Hint: Some lines were ellipsized, use -l to show in full.
○動作テストのための設定を追加
毎分、空の行をtestファイルに追記するようにした。
[root@a42dafc368d1 ~]# crontab -e
* * * * * /usr/bin/echo >> /root/test:wqで保存すると、次のように表示された。
crontab: installing new crontabcrondが起動していなければ、次のエラーが発生した。
no crontab for root - using an empty one
crontab: installing new crontab
しばらく待ってから、testファイルの存在を確認した。
[root@a42dafc368d1 ~]# ls
anaconda-ks.cfg test毎分、空の行も追記されていることがわかった。
◆コンテナのディスク、メモリ、プロセスがどうなっているか確認した。
○ディスクの使用状態を確認した。
[root@923d1942dcbb ~]# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 16G 9.9G 5.9G 63% /
tmpfs 64M 0 64M 0% /dev
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/vda5 16G 9.9G 5.9G 63% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 2.0G 8.5M 2.0G 1% /run
tmpfs 405M 0 405M 0% /run/user/0
○メモリの使用状態を確認した。（Dockerホスト側のfreeコマンドと同じ結果となった。）
[root@923d1942dcbb ~]# free -h
total used free shared buff/cache available
Mem: 4.0G 170M 3.1G 16M 666M 3.5G
Swap: 0B 0B 0B
○プロセスの状態を確認した。
[root@923d1942dcbb ~]# top
top - 21:12:34 up 23:58, 1 user, load average: 1.00, 1.01, 1.05
Tasks: 15 total, 1 running, 14 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.3 us, 37.9 sy, 0.0 ni, 51.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 4142136 total, 3284724 free, 175016 used, 682396 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3707996 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 43176 3316 2336 S 0.0 0.1 0:00.26 systemd
17 root 20 0 39080 3016 2708 S 0.0 0.1 0:00.13 systemd-jo+
25 root 20 0 41624 1732 1196 S 0.0 0.0 0:00.16 systemd-ud+
45 root 20 0 112812 4212 3188 S 0.0 0.1 0:00.00 sshd
46 root 20 0 218504 4248 2680 S 0.0 0.1 0:02.13 rsyslogd
49 root 20 0 26376 1612 1324 S 0.0 0.0 0:00.05 systemd-lo+
50 dbus 20 0 58064 2244 1744 S 0.0 0.1 0:00.04 dbus-daemon
57 root 20 0 26100 1564 924 S 0.0 0.0 0:00.03 crond
58 root 20 0 9904 824 696 S 0.0 0.0 0:00.00 agetty
139 root 20 0 89632 2120 1088 S 0.0 0.1 0:00.12 master
141 postfix 20 0 89804 4012 3008 S 0.0 0.1 0:00.03 qmgr
234 postfix 20 0 89736 3988 2992 S 0.0 0.1 0:00.02 pickup
235 root 20 0 155232 6028 4680 S 0.0 0.1 0:00.09 sshd
237 root 20 0 15224 1836 1460 S 0.0 0.0 0:00.01 bash
252 root 20 0 59580 1900 1396 R 0.0 0.0 0:00.01 top
◆Dockerホストの状態についても同様に確認した。
○Dockerホスト側のディスクの状態
[root@localhost ~]# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置/dev/vda5 16G 9.9G 5.9G 63% /
devtmpfs 2.0G 0 2.0G 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 2.0G 8.7M 2.0G 1% /run
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/vda2 2.0G 33M 2.0G 2% /tmp
/dev/vda1 473M 139M 335M 30% /boot
overlay 16G 9.9G 5.9G 63% /var/lib/docker/overlay2/eac780341079bd52807cb38bb0e99c75eb7af51132f529d953ac62ab12629515/merged
shm 64M 0 64M 0% /var/lib/docker/containers/923d1942dcbb471c99fe1295b36836368fbccddfae4eb6c2ac7979cdcc5ff123/mounts/shm
tmpfs 405M 0 405M 0% /run/user/0
○Dockerホスト側のfreeコマンドの結果（コンテナと同じ情報となった）
[root@localhost ~]# free -h
total used free shared buff/cache available
Mem: 4.0G 171M 3.1G 17M 667M 3.5G
Swap: 0B 0B 0B
（コンテナで動作中のプロセスsystemdなどが見えている。）
[root@localhost ~]# ps -A
PID TTY TIME CMD
1 ? 00:00:02 systemd
2 ? 00:00:00 kthreadd
3 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 kworker/0:0H
7 ? 00:00:00 migration/0
8 ? 00:00:00 rcu_bh
9 ? 00:00:06 rcu_sched
10 ? 00:00:00 lru-add-drain
11 ? 00:00:00 watchdog/0
12 ? 00:00:00 watchdog/1
13 ? 00:00:00 migration/1
14 ? 00:00:00 ksoftirqd/1
16 ? 00:00:00 kworker/1:0H
18 ? 00:00:00 kdevtmpfs
19 ? 00:00:00 netns
20 ? 00:00:00 khungtaskd
21 ? 00:00:00 writeback
22 ? 00:00:00 kintegrityd
23 ? 00:00:00 bioset
24 ? 00:00:00 bioset
25 ? 00:00:00 bioset
26 ? 00:00:00 kblockd
27 ? 00:00:00 md
28 ? 00:00:00 edac-poller
31 ? 00:00:00 kswapd0
32 ? 00:00:00 ksmd
33 ? 00:00:00 khugepaged
34 ? 00:00:00 crypto
42 ? 00:00:00 kthrotld
44 ? 00:00:00 kmpath_rdacd
45 ? 00:00:00 kaluad
47 ? 00:00:00 kpsmoused
48 ? 00:00:00 ipv6_addrconf
61 ? 00:00:00 deferwq
94 ? 00:00:00 kauditd
225 ? 00:00:00 ata_sff
230 ? 00:00:00 kworker/0:1H
233 ? 00:00:00 scsi_eh_0
234 ? 00:00:00 scsi_tmf_0
235 ? 00:00:00 scsi_eh_1
236 ? 00:00:00 scsi_tmf_1
251 ? 00:00:00 ttm_swap
265 ? 00:00:00 bioset
266 ? 00:00:00 xfsalloc
267 ? 00:00:00 xfs_mru_cache
268 ? 00:00:00 xfs-buf/vda5
269 ? 00:00:00 xfs-data/vda5
270 ? 00:00:00 xfs-conv/vda5
271 ? 00:00:00 xfs-cil/vda5
272 ? 00:00:00 xfs-reclaim/vda
273 ? 00:00:00 xfs-log/vda5
274 ? 00:00:00 xfs-eofblocks/v
275 ? 00:00:04 xfsaild/vda5
344 ? 00:00:00 systemd-journal
367 ? 00:00:00 lvmetad
375 ? 00:00:00 systemd-udevd
416 ? 00:00:00 xfs-buf/vda1
417 ? 00:00:00 xfs-data/vda1
418 ? 00:00:00 xfs-conv/vda1
419 ? 00:00:00 xfs-cil/vda1
420 ? 00:00:00 xfs-reclaim/vda
421 ? 00:00:00 xfs-log/vda1
422 ? 00:00:00 xfs-eofblocks/v
423 ? 00:00:00 xfsaild/vda1
427 ? 00:00:00 xfs-buf/vda2
428 ? 00:00:00 xfs-data/vda2
429 ? 00:00:00 xfs-conv/vda2
430 ? 00:00:00 xfs-cil/vda2
431 ? 00:00:00 xfs-reclaim/vda
434 ? 00:00:00 xfs-log/vda2
436 ? 00:00:00 xfs-eofblocks/v
437 ? 00:00:00 xfsaild/vda2
451 ? 00:00:00 kworker/1:1H
457 ? 00:00:00 auditd
480 ? 00:00:00 systemd-logind
481 ? 00:00:00 dbus-daemon
483 ? 00:00:00 polkitd
484 ? 00:00:03 NetworkManager
485 ? 00:00:05 irqbalance
489 ? 00:00:00 qemu-ga
494 ? 00:00:00 crond
503 ? 00:00:00 chronyd
551 ? 00:00:00 dhclient
761 ? 00:00:20 tuned
763 ? 00:00:00 sshd
764 ? 00:00:09 rsyslogd
862 ? 00:00:00 master
864 ? 00:00:00 qmgr
889 ? 00:03:52 dockerd
896 ? 00:02:49 docker-containe
1554 ? 23:56:27 agetty
3962 ? 00:00:00 kworker/u4:0
4704 ? 00:00:00 kworker/u4:1
4726 ? 00:00:20 kworker/0:3
4815 ? 00:00:00 docker-proxy
4821 ? 00:00:00 docker-containe
4837 ? 00:00:00 systemd (コンテナ内のsystemd)
4884 ? 00:00:00 systemd-journal
4895 ? 00:00:00 systemd-udevd
4931 ? 00:00:00 sshd
4932 ? 00:00:02 rsyslogd
4936 ? 00:00:00 systemd-logind
4937 ? 00:00:00 dbus-daemon
4947 ? 00:00:00 crond
4949 tty1 00:00:00 agetty
5046 ? 00:00:00 master
5048 ? 00:00:00 qmgr
5309 ? 00:00:00 pickup (Dockerホスト側のPostfixプロセスのようである)
5343 ? 00:00:00 pickup
5344 ? 00:00:00 kworker/1:2
5345 ? 00:00:00 kworker/0:1
5362 ? 00:00:00 kworker/1:0
5365 ? 00:00:00 kworker/0:0
5367 ? 00:00:00 kworker/1:1
5372 ? 00:00:00 sshd
5374 pts/0 00:00:00 bash
5388 pts/0 00:00:00 ps
○Dockerコンテナを終了させてからメモリ使用量を確認した。
[root@localhost ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES[root@localhost ~]# free -h
923d1942dcbb image-centos7-ssh2 "/sbin/init" 6 hours ago Exited (130) 17 seconds ago centos7-ssh
total used free shared buff/cache available
Mem: 4.0G 157M 3.2G 8.6M 656M 3.6G
Swap: 0B 0B 0B
コンテナ起動中と終了後の差を計算した。
171MB - 157MB = 14MB盛り沢山のコンテナを起動して、僅か14MBの消費しかされていないということか。
ところで、以下は、コンテナのプロセスの残骸か？と思ったが、
そうではなくて、Dockerホスト側のプロセスだとわかった。
コンテナのプロセスは消滅しているようだ。
[root@localhost ~]# ps -A
（5000番台以降のみ表示）コンテナの終了によってきれいさっぱり、掃除されているようである。
5309 ? 00:00:00 pickup
5344 ? 00:00:00 kworker/1:2
5396 ? 00:00:00 kworker/0:1
5398 ? 00:00:00 kworker/1:1
5401 ? 00:00:00 kworker/0:2
5424 ? 00:00:00 kworker/u4:2
5494 ? 00:00:00 sshd
5496 pts/0 00:00:00 bash
5520 ? 00:00:00 kworker/0:0
5523 ? 00:00:00 kworker/1:0
5526 pts/0 00:00:00 ps
コンテナ内に、systemdがプロセス1として動作しているためなのだろう。（†1）
以上
＜参考＞
1、Docker and the PID 1 zombie reaping problem
< https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ > 2018年11月17日
・Running Syslog Within a Docker Container
< http://www.projectatomic.io/blog/2014/09/running-syslog-within-a-docker-container/ > 2018年11月17日
・Postfixのipv6設定を無効にする方法
< https://qiita.com/KoriCori/items/ce30aecf38c85c3afc01 > 2018年11月17日
・How to install crontab on Centos
< https://stackoverflow.com/questions/21802223/how-to-install-crontab-on-centos > 2018年11月17日
・Dockerで/etc/hostsファイルが操作出来ない対策
< https://qiita.com/jagaximo/items/6b71a03518bbd53d4de6 > 2018年11月17日
・Docker コンテナで /etc/hosts がイジれなくて残念だったのでメモ
< https://cloudpack.media/8224 > 2018年11月17日
