「CentOS」の記事 - Crieit

cp コマンドで強制上書きする際に気を付けること

2022-01-09T23:55:22+09:00

CentOS 系で cp コマンドで強制上書きをする際のメモです。

経緯

タイムゾーンを変更するために次のようなコマンドを実行しました。

# cp -pf /usr/share/zoneinfo/Japan /etc/localtime
cp: overwrite `/etc/localtime'?

すると、 -f オプションで強制上書きするはずなのに上書きするかを聞かれてしまいました。

原因

これは cp コマンドが cp -i のエイリアスとなっているため。

つまり、デフォルトでインタラクティブ(対話式)になっているようです。そのため、仮に -f を付けても -i の方が優先され、上書きするか確認してくる、というわけです。

(Docker) Almalinux を見据えて CentOS8 での環境構築を試験してみる

2021-12-29T00:16:11+09:00

手前味噌で恐縮ですが、自作の LAMP環境を検証する Docker Compose について。

GitHub - arm-band/docker_compose_ambergrease

イメージを CentOS7 ベースで構築しているので、いずれは AlmaLinux なり Rocky Linux なりに移行しなければならないことは分かっていました。

そこで、その以降を見据えて残り数日の命の CentOS8 で試験してみることにしました。なぜ AlmaLinux や Rocky Linux ではなくわざわざ CentOS8 かというと、いきなりそれらのOSに飛びついて何らかの不具合が発生したときに原因の切り分けで苦労するならば、まだ同じシリーズで差分が少ない (と想定される) CentOS8 で試験して、問題なければ次に進もう、という段階的な試験を想定したためです。

検証

docker run --name php7_cent8 -it centos:centos8 /bin/bash

まずはイメージを取得し、 bash に入ります。

Apache + PHP

最初は Apache + PHP 。こちらについては、以前 CentOS8 をインストールして遊んだときにremiリポジトリの入り方が CentOS7 とは異なることが分かっていたので、多少手を加える必要があるだろう、と踏んでいました。

# \cp -pf /usr/share/zoneinfo/Japan /etc/localtime
#

これは問題なし。

# dnf -y update && yum -y install  epel-release sudo less iproute httpd-devel zip unzip openssl mod_ssl

## 略

Installed:
  apr-1.6.3-12.el8.x86_64                                     apr-devel-1.6.3-12.el8.x86_64
  apr-util-1.6.1-6.el8.x86_64                                 apr-util-bdb-1.6.1-6.el8.x86_64
  apr-util-devel-1.6.1-6.el8.x86_64                           apr-util-openssl-1.6.1-6.el8.x86_64
  brotli-1.0.6-3.el8.x86_64                                   centos-logos-httpd-85.8-2.el8.noarch
  cyrus-sasl-2.1.27-5.el8.x86_64                              cyrus-sasl-devel-2.1.27-5.el8.x86_64
  epel-release-8-11.el8.noarch                                expat-devel-2.2.5-4.el8.x86_64
  groff-base-1.22.3-18.el8.x86_64                             httpd-2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64
  httpd-devel-2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64   httpd-filesystem-2.4.37-43.module_el8.5.0+1022+b541f3b1.noarch   
  httpd-tools-2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64   libdb-devel-5.3.28-42.el8_4.x86_64
  libpath_utils-0.2.1-39.el8.x86_64                           libpkgconf-1.4.2-1.el8.x86_64
  libtalloc-2.3.2-1.el8.x86_64                                mailcap-2.1.48-3.el8.noarch
  mod_http2-1.15.7-3.module_el8.4.0+778+c970deab.x86_64       mod_ssl-1:2.4.37-43.module_el8.5.0+1022+b541f3b1.x86_64
  ncurses-6.1-9.20180224.el8.x86_64                           openldap-devel-2.4.46-18.el8.x86_64
  perl-Carp-1.42-396.el8.noarch                               perl-Data-Dumper-2.167-399.el8.x86_64
  perl-Digest-1.17-395.el8.noarch                             perl-Digest-MD5-2.55-396.el8.x86_64
  perl-Encode-4:2.97-3.el8.x86_64                             perl-Errno-1.28-420.el8.x86_64
  perl-Exporter-5.72-396.el8.noarch                           perl-File-Path-2.15-2.el8.noarch
  perl-File-Temp-0.230.600-1.el8.noarch                       perl-Getopt-Long-1:2.50-4.el8.noarch
  perl-HTTP-Tiny-0.074-1.el8.noarch                           perl-IO-1.38-420.el8.x86_64
  perl-IO-Socket-IP-0.39-5.el8.noarch                         perl-IO-Socket-SSL-2.066-4.module_el8.3.0+410+ff426aa3.noarch    
  perl-MIME-Base64-3.15-396.el8.x86_64                        perl-Mozilla-CA-20160104-7.module_el8.3.0+416+dee7bcef.noarch    
  perl-Net-SSLeay-1.88-1.module_el8.3.0+410+ff426aa3.x86_64   perl-PathTools-3.74-1.el8.x86_64
  perl-Pod-Escapes-1:1.07-395.el8.noarch                      perl-Pod-Perldoc-3.28-396.el8.noarch
  perl-Pod-Simple-1:3.35-395.el8.noarch                       perl-Pod-Usage-4:1.69-395.el8.noarch
  perl-Scalar-List-Utils-3:1.49-2.el8.x86_64                  perl-Socket-4:2.027-3.el8.x86_64
  perl-Storable-1:3.11-3.el8.x86_64                           perl-Term-ANSIColor-4.06-396.el8.noarch
  perl-Term-Cap-1.17-395.el8.noarch                           perl-Text-ParseWords-3.30-395.el8.noarch
  perl-Text-Tabs+Wrap-2013.0523-395.el8.noarch                perl-Time-Local-1:1.280-1.el8.noarch
  perl-URI-1.73-3.el8.noarch                                  perl-Unicode-Normalize-1.25-396.el8.x86_64
  perl-constant-1.33-396.el8.noarch                           perl-interpreter-4:5.26.3-420.el8.x86_64
  perl-libnet-3.11-3.el8.noarch                               perl-libs-4:5.26.3-420.el8.x86_64
  perl-macros-4:5.26.3-420.el8.x86_64                         perl-parent-1:0.237-1.el8.noarch
  perl-podlators-4.11-1.el8.noarch                            perl-threads-1:2.21-2.el8.x86_64
  perl-threads-shared-1.58-2.el8.x86_64                       pkgconf-1.4.2-1.el8.x86_64
  pkgconf-m4-1.4.2-1.el8.noarch                               pkgconf-pkg-config-1.4.2-1.el8.x86_64
  sscg-2.3.3-14.el8.x86_64                                    sudo-1.8.29-7.el8_4.1.x86_64
  unzip-6.0-45.el8_4.x86_64                                   zip-3.0-23.el8.x86_64

Complete!

OK。

# dnf -y upgrade

## 略

Upgraded:
  epel-release-8-13.el8.noarch

Complete!

特に大きな差分もなさそうです。OK。

remiリポジトリ

# rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm
Retrieving http://rpms.famillecollet.com/enterprise/remi-release-8.rpm
warning: /var/tmp/rpm-tmp.hlvLxe: Header V4 RSA/SHA256 Signature, key ID 5f11735a: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:remi-release-8.5-2.el8.remi      ################################# [100%]
# rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021
#

OK。 CentOS8 用のリポジトリに切り替えました。鍵についてはすぐ RPM-GPG-KEY-remi2022 にしなければならないでしょうけど。

dnf

# dnf config-manager --enable remi && dnf config-manager --enable remi-php74
No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

remi-php74 に指定で躓くかと思いきや、そもそも config-manager がない、と？

元々は yum-config-manager だったのですが、 CentOS8 であれば dnf ベースの方が良いだろう、ということで置き換えてはみましたが、ダメですか……。

Almalinuxにterraformコマンドをyumで導入するの巻 - TrippyBoyの愉快な日々

こちらより dnf install -y dnf-plugins-core してみます。

# dnf install dnf-plugins-core

## 略

Installed:
  dbus-glib-0.110-2.el8.x86_64        dnf-plugins-core-4.0.21-3.el8.noarch            python3-dateutil-1:2.6.1-6.el8.noarch    
  python3-dbus-1.2.4-15.el8.x86_64    python3-dnf-plugins-core-4.0.21-3.el8.noarch    python3-six-1.11.0-8.el8.noarch

Complete!

OK。

remi + PHP

# dnf config-manager --enable remi && dnf config-manager --enable remi-php74
Error: No matching repo to modify: remi-php74.

……やはり remi-php74 で引っかかりましたか。

CentOs8 php7.4をインストールする | mebee

……想定していたものとは少し違うやり方ですが、試してみましょう。

# dnf module reset php

## 略

Remi's RPM repository for Enterprise Linux 8 - x86_64                                          598 kB/s | 3.9 MB     00:06    
Last metadata expiration check: 0:00:03 ago on DDD dd mmm yyyy hh:ii:ss AM UTC.
Dependencies resolved.
Nothing to do.
Complete!

OK。

# dnf module install -y php:remi-7.4

## 略

Installed:
  libedit-3.1-23.20170329cvs.el8.x86_64                                     libxslt-1.1.32-6.el8.x86_64
  nginx-filesystem-1:1.14.1-9.module_el8.0.0+184+e34fea82.noarch            oniguruma5php-6.9.7.1-1.el8.remi.x86_64
  php-cli-7.4.27-1.el8.remi.x86_64                                          php-common-7.4.27-1.el8.remi.x86_64
  php-fpm-7.4.27-1.el8.remi.x86_64                                          php-json-7.4.27-1.el8.remi.x86_64
  php-mbstring-7.4.27-1.el8.remi.x86_64                                     php-xml-7.4.27-1.el8.remi.x86_64

Complete!

# php --version
PHP 7.4.27 (cli) (built: Dec 14 2021 17:17:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

OK。入りましたね。これに従い該当箇所を書き換えます。

# enable repository remi & remi-php74
#RUN dnf config-manager --enable remi && dnf config-manager --enable remi-php74
# disable default module
RUN dnf module reset -y php
RUN dnf module install -y php:remi-7.4

## 略

# disable repository remi & remi-php74
#RUN dnf config-manager --disable remi && dnf config-manager --disable remi-php74

config-manager によるリポジトリ使用のオン・オフの切り替えを削除しました。

# dnf -y install php php-devel php-pdo php-mysqlnd php-mbstring php-gd php-pear php-pecl-apc-devel zlib-devel php-xml php-mcrypt php-pecl-xdebug

## 略

Installed:
  autoconf-2.69-29.el8.noarch                                     automake-1.16.1-7.el8.noarch
  cmake-filesystem-3.20.2-4.el8.x86_64                            cpp-8.5.0-4.el8_5.x86_64
  dejavu-fonts-common-2.35-7.el8.noarch                           dejavu-sans-fonts-2.35-7.el8.noarch
  emacs-filesystem-1:26.1-7.el8.noarch                            fontconfig-2.13.1-4.el8.x86_64
  fontpackages-filesystem-1.44-22.el8.noarch                      freetype-2.9.1-4.el8_3.1.x86_64
  fribidi-1.0.4-8.el8.x86_64                                      gcc-8.5.0-4.el8_5.x86_64
  gcc-c++-8.5.0-4.el8_5.x86_64                                    gd3php-2.3.3-4.el8.remi.x86_64
  glibc-devel-2.28-164.el8.x86_64                                 glibc-headers-2.28-164.el8.x86_64
  graphite2-1.3.10-10.el8.x86_64                                  harfbuzz-1.7.5-3.el8.x86_64
  isl-0.16.1-6.el8.x86_64                                         jbigkit-libs-2.1-14.el8.x86_64
  kernel-headers-4.18.0-348.2.1.el8_5.x86_64                      keyutils-libs-devel-1.5.10-9.el8.x86_64
  krb5-devel-1.18.2-14.el8.x86_64                                 libX11-1.6.8-5.el8.x86_64
  libX11-common-1.6.8-5.el8.noarch                                libXau-1.0.9-3.el8.x86_64
  libXpm-3.5.12-8.el8.x86_64                                      libcom_err-devel-1.45.6-2.el8.x86_64
  libimagequant-2.12.5-1.el8.x86_64                               libjpeg-turbo-1.5.3-12.el8.x86_64
  libkadm5-1.18.2-14.el8.x86_64                                   libmcrypt-2.5.8-26.el8.x86_64
  libmpc-1.1.0-9.1.el8.x86_64                                     libpng-2:1.6.34-5.el8.x86_64
  libraqm-0.7.0-4.el8.x86_64                                      libselinux-devel-2.9-5.el8.x86_64
  libsepol-devel-2.9-3.el8.x86_64                                 libsodium-1.0.18-2.el8.x86_64
  libstdc++-devel-8.5.0-4.el8_5.x86_64                            libtiff-4.0.9-20.el8.x86_64
  libtool-2.4.6-25.el8.x86_64                                     libverto-devel-0.3.0-5.el8.x86_64
  libwebp-1.0.0-5.el8.x86_64                                      libxcb-1.13.1-1.el8.x86_64
  libxcrypt-devel-4.1.1-6.el8.x86_64                              libxml2-devel-2.9.7-9.el8_4.2.x86_64
  m4-1.4.18-7.el8.x86_64                                          make-1:4.2.1-10.el8.x86_64
  openssl-devel-1:1.1.1k-5.el8_5.x86_64                           pcre2-devel-10.32-2.el8.x86_64
  pcre2-utf16-10.32-2.el8.x86_64                                  pcre2-utf32-10.32-2.el8.x86_64
  perl-Thread-Queue-3.13-1.el8.noarch                             php-7.4.27-1.el8.remi.x86_64
  php-devel-7.4.27-1.el8.remi.x86_64                              php-fedora-autoloader-1.0.1-2.el8.remi.noarch
  php-gd-7.4.27-1.el8.remi.x86_64                                 php-mysqlnd-7.4.27-1.el8.remi.x86_64
  php-opcache-7.4.27-1.el8.remi.x86_64                            php-pdo-7.4.27-1.el8.remi.x86_64
  php-pear-1:1.10.13-1.el8.remi.noarch                            php-pecl-apcu-5.1.21-1.el8.remi.7.4.x86_64
  php-pecl-apcu-devel-5.1.21-1.el8.remi.7.4.x86_64                php-pecl-mcrypt-1.0.4-1.el8.remi.7.4.x86_64
  php-pecl-xdebug-2.9.8-1.el8.remi.7.4.x86_64                     php-process-7.4.27-1.el8.remi.x86_64
  php-sodium-7.4.27-1.el8.remi.x86_64                             xz-devel-5.2.4-3.el8.x86_64
  zlib-devel-1.2.11-17.el8.x86_64

Complete!

OK。

# php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"   && php composer-setup.php   && php -r "unlink('composer-setup.php');"   && mv composer.phar /usr/local/bin/composer
All settings correct for using Composer
Downloading...

Composer (version 2.2.1) successfully installed to: /etc/yum.repos.d/composer.phar
Use it: php composer.phar

# composer --version
Composer version 2.2.1 2021-12-22 22:21:31

Composer も入りました。

# mkdir /var/log/php
# chown apache /var/log/php
# chmod 755 /var/log/php
# mkdir -p /etc/ssl/private

まあこの辺りは普通に。

SSL

# openssl req -new -newkey rsa:2048 -nodes -out /etc/ssl/private/server.csr -keyout /etc/ssl/private/server.key -subj "/C=/ST=/L=/O=/OU=/CN=*.lvh.me"

## 略

# openssl x509 -days 365 -req -signkey /etc/ssl/private/server.key -in /etc/ssl/private/server.csr -out /etc/ssl/private/server.crt
Signature ok
subject=CN = *.lvh.me
Getting Private key

OK。

Apache の設定ファイル

ssl.conf

# cat /etc/httpd/conf.d/ssl.conf 

## 略

表示させたSSL用の設定を現行のものと差し替えます。ただし、現行の設定をなるべく引き継ぐように。これは他の設定ファイルも同様です。

- SSLRandomSeed startup file:/dev/urandom  256
- SSLRandomSeed connect builtin

- SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA

現行にあったこれらの行は削除。

+ SSLHonorCipherOrder on

これは新しく追加されていました。

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

プロトコルについては念のため現行の設定を引き継ぎ。流石にもう SSLv2 なんて存在しないでしょうけど……。

- 
+ 
      SSLOptions +StdEnvVars
- 
+

微妙にディレクティブの表現が変わっていますが、影響はなさそうなので変更を受け入れます。

php.conf

# cat /etc/httpd/conf.d/php.conf

## 略

# Redirect to local php-fpm if mod_php (5 or 7) is not available

  
    # Enable http authorization headers
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

    
        SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"

こちらは最後の部分に追記がありますね。これはそのまま受け入れ。

php.ini

# cat /etc/php.ini

## 略

こちらも設定を引き継ぎ、といっても現行の設定と変更点はなく(自前の設定を引き継いだ) 差分としてはコメントの文字列くらい。

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.0.2.1. Set the 'ServerName' directive globally to suppress this message

Apache を起動しようとしたところ、

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.0.2.1. Set the 'ServerName' directive globally to suppress this message

のエラーメッセージがログに記録されて起動してこない現象に遭遇。

[Docker]AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using ***.***.*.*. Set the 'ServerName' directive globally to suppress this message - Qiita

そういえば元々の Dockerfile には記述していましたが、 httpd.conf への追記をしていませんでした。

echo ServerName www.example.com:80 >> /etc/httpd/conf/httpd.conf

これでOK。

# httpd -v
Server version: Apache/2.4.37 (centos)
Server built:   Nov 12 2021 04:57:27

バージョンも拾えました。

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php-fpm/www.sock (*) failed

これで Apache も起動してきたのでブラウザで表示確認、ということで phpinfo() でも表示させようかとファイルを用意して curl してみると……

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

503エラーが出てしまいました。

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php-fpm/www.sock (*) failed

Apache のエラーログには上述のログが記録されていました。

今までとは異なる方法で PHP をインストールしたら、どうやら php-fpm (CGIモード) で動作しようとしてしまっているようです。

今回の環境ではCGI版かモジュール版かはあまり考慮しておらず、Webサーバも Apache のためモジュール版でも良いと判断。

動作を切り替えます。

# less /etc/httpd/conf/httpd.conf

## 略

Include conf.modules.d/*.conf

念のためモジュール読み込みの記述があることを確認。

# ls /etc/httpd/conf.modules.d/
00-base.conf      00-lua.conf       00-optional.conf  00-ssl.conf       01-cgi.conf       10-proxy_h2.conf  README
00-dav.conf       00-mpm.conf       00-proxy.conf     00-systemd.conf   10-h2.conf        15-php.conf

関係しそうなのは 00-mpm.conf, 01-cgi.conf, 15-php.conf 辺りでしょうか。

# less /etc/httpd/conf.modules.d/15-php.conf

# Cannot load both php5 and php7 modules

  
    LoadModule php7_module modules/libphp7.so

ここはそのまま。

# less /etc/httpd/conf.modules.d/01-cgi.conf 

# This configuration file loads a CGI module appropriate to the MPM
# which has been configured in 00-mpm.conf.  mod_cgid should be used
# with a threaded MPM; mod_cgi with the prefork MPM.


   LoadModule cgid_module modules/mod_cgid.so


   LoadModule cgid_module modules/mod_cgid.so


   LoadModule cgi_module modules/mod_cgi.so

ここもそのまま。

# less /etc/httpd/conf.modules.d/00-mpm.conf

# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines.  See the httpd.conf(5) man
# page for more information on changing the MPM.

# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
#
# NOTE: If enabling prefork, the httpd_graceful_shutdown SELinux
# boolean should be enabled, to allow graceful stop/shutdown.
#
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
#LoadModule mpm_worker_module modules/mod_mpm_worker.so

# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#
LoadModule mpm_event_module modules/mod_mpm_event.so

変更するのはここ。

- #LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
+ LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

- LoadModule mpm_event_module modules/mod_mpm_event.so
# LoadModule mpm_event_module modules/mod_mpm_event.so

上述のうち2ヶ所を反転させます。

CentOSにApacheとPHP入れてPHPファイルを表示しようとしたら503エラー Output48

これでOK。起動も確認できました。

テンプレートとして上述を反転させた 00-mpm.conf を用意し、エントリポイントでファイルコピーして設定を上書きすることで対処しました。

最終的に AlmaLinux の Docker Compose を作成して起動し、ブラウザで該当の PHPファイルにアクセスし、 phpinfo() の画面が表示されることを確認できました。OK。

SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty

上述のエラーの他に

SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty

localhost のSSL証明書がない、というエラーにも遭遇しました。

なければ作れば良いだけ、上述で

echo ServerName www.example.com:80 >> /etc/httpd/conf/httpd.conf

としているので、このダミードメインを使います。

# openssl req -new -newkey rsa:2048 -nodes -out /etc/pki/tls/certs/localhost.csr -keyout /etc/pki/tls/private/localhost.key -subj "/C=/ST=/L=/O=/OU=/CN=www.example.com"

## 略

# openssl x509 -days 365 -req -signkey /etc/pki/tls/private/localhost.key -in /etc/pki/tls/certs/localhost.csr -out /etc/pki/tls/certs/localhost.crt
Signature ok
subject=CN = www.example.com
Getting Private key

これでOK。 ssl.conf には記述はあるのですが……。

MySQL

次に MySQL 側を。こちらはほぼ手を加える必要はないという想定です。

# dnf localinstall https://dev.mysql.com/get/mysql80-community-release-el8-2.noarch.rpm

## 略

Package mysql80-community-release-el8-2.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!

CentOS8 用ということでリポジトリの入れ方を少し変更。

# ls /etc/yum.repo.d/
CentOS-Linux-AppStream.repo          CentOS-Linux-Media.repo       epel-testing.repo
CentOS-Linux-BaseOS.repo             CentOS-Linux-Plus.repo        mysql-community.repo
CentOS-Linux-ContinuousRelease.repo  CentOS-Linux-PowerTools.repo  mysql-community-source.repo
CentOS-Linux-Debuginfo.repo          CentOS-Linux-Sources.repo     remi-modular.repo
CentOS-Linux-Devel.repo              epel-modular.repo             remi.repo
CentOS-Linux-Extras.repo             epel-playground.repo          remi-safe.repo
CentOS-Linux-FastTrack.repo          epel.repo
CentOS-Linux-HighAvailability.repo   epel-testing-modular.repo

mysql-community.repo, mysql-community-source.repo の2つが追加されたことを確認。

# dnf module disable mysql

## 略

Complete!

デフォルトの MySQL がいると邪魔になるので無効化して

# dnf -y install mysql-community-devel mysql-community-server

## 略

Installed:
  mysql-community-client-8.0.27-1.el8.x86_64                 mysql-community-client-plugins-8.0.27-1.el8.x86_64
  mysql-community-common-8.0.27-1.el8.x86_64                 mysql-community-devel-8.0.27-1.el8.x86_64
  mysql-community-libs-8.0.27-1.el8.x86_64                   mysql-community-server-8.0.27-1.el8.x86_64
  net-tools-2.0-0.52.20160912git.el8.x86_64

Complete!

インストール完了。

# mysqld --version
/usr/sbin/mysqld  Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL)

デフォルトでは 8.0.26 だったバージョンが地味に 8.0.27 に上がりました。

# grep 'temporary password' /var/log/mysqld.log       
yyyy-mm-ddThh:ii:ss.zzzzzzZ 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: XXXXXXXXXXXX

初期パスワードの出現位置が半角スペース区切りで13番目であることを確認。これはエントリポイントで awk を使って抽出、初期パスワードを環境変数の値で書き換える処理で使用するため個人的には重要ポイント。ここは変更しなくて良さそうです。

# cat /etc/my.cnf

[mysqld]

## 略

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

デフォルトで4つパラメータが指定されています。うち3つはテンプレートの設定ファイルに記述がされているので不要、 pid-file だけ現時点では指定がないため、これだけ base.cnf に移植します。

/etc/my.cnf には上述4つを削除した代わりに !includedir /etc/my.cnf.d を末尾に追加したものを現行の my.cnf と差し替え。

これで MySQL 側は良さそうです。

なお、 phpMyAdmin は公式イメージをそのまま使っているので変更なし。

以上で一通り動作検証できたので、これをベースに AlmaLinux 用に書き換えれば良さそうです。

参考

Docker

AlmaLinux

dnf

remi

Remi's RPM repository

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.0.2.1. Set the 'ServerName' directive globally to suppress this message

[Docker]AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using ***.***.*.*. Set the 'ServerName' directive globally to suppress this message - Qiita

PHP

CentOs8 php7.4をインストールする | mebee

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php-fpm/www.sock (*) failed

php-fpm

nginx と PHP-FPM の仕組みをちゃんと理解しながら PHP の実行環境を構築する - Qiita

SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty

MySQL

MySQL 8.0 を CentOS 8.1 にインストールする手順 - Qiita

CentOS でリポジトリの enable/disabled を切り替える方法

2021-02-02T23:45:09+09:00

CentOS でリポジトリを切り替える際、今までリポジトリファイルの編集をしていました。

# vi /etc/yum.repos.d/remi.repo

[remi]
enabled=1

remi リポジトリの有効化。

# vi /etc/yum.repos.d/remi-php74.repo

[remi-php74]
enabled=1

remi-php74 リポジトリの有効化。

この他のやり方としては、 yum や dnf 使用時にリポジトリの enabled, disabled を引数で指定する方法があります。

# yum install --enablerepo=remi-php74 php

今回改めて検索したところ、以下のコマンドを発見したのでメモしておきます。

# yum-config-manager --enable remi

これでリポジトリファイルを書き換えることなく、 enabled, disabled を切り替えられます。

# yum-config-manager --enable remi
# yum-config-manager --enable remi-php74

今更ですが、こんなやり方があったとは……。

参考

6.3.5. Yum リポジトリを有効/設定/無効にする方法 Red Hat Enterprise Linux 6 | Red Hat Customer Portal

vsftpd と Apache の設定を削除しLinuxユーザも削除する

2020-12-24T00:28:56+09:00

以前取り上げたAnsible を使って FTPユーザの作成と Apache の仮想サイトの設定をするの逆方向バージョンです。

つまり、

Linuxユーザを削除
上記ユーザを vsftpdユーザからも削除
Apache の仮想サイトの設定と該当ディレクトリのデータを全て削除

を行うタスクを作ろう、と考えました。

これは、上記のプレイブックを一時的なテスト環境として作った後、削除することも往々にしてあり、手動で削除するのが面倒になってきたからです。

前提

テストに利用するサーバは前の記事と同じサーバで、該当プレイブックによって vsftpd や Apache が設定されている、という状況を想定しています。

設定

ディレクトリ階層

PROJECT_ROOT/
  ├ workspace/
  │    ├ entrypoint.sh
  │    └ ansible/
  │         ├ (諸々元のプレイブックと同じ構造)
  │         ├ main.yml                      // Ansible の設定用 playbook
  │         └ resset.yml                    // 今回追加した削除用タスク
  │
  ├ docker-compose.yml
  └ Dockerfile

ほぼ前の記事の通り、というか同じプロジェクトをそのまま流用しています。元々の意図が設定用プレイブックに対して設定を元に戻すためのものなので、同じ場所にあった方が都合は良いと考えました。

ただ、リセットするためのタスクは設定用タスクほど複雑ではないのでタスクを分割せずに1つのファイルに既述することにしました。

ansible/vars/param_vars.yml

username: USERNAME
password: Password1234
rootdirectory: sample_site
domain: www.sample.jp
ipaddress: 192.0.2.1
portnum: 80

上記ディレクトリ構造より、設定用のプレイブックに使用する変数ファイルがあるため、これをそのまま流用します。

ansible/resset.yml

- name: Remove vsftpd and httpd settings

  become: yes
  become_user: ADMIN_USER
  become_method: su

  hosts:
    - add_vhost_servers

  vars_files: ./vars/param_vars.yml

  tasks:
    - name: Remove user
      user:
        name: "{{ username }}"
        state: absent
        remove: yes
    - name: Remove user in vsftpd user_list
      blockinfile:
        path: /etc/vsftpd/user_list
        create: yes
        insertafter: EOF
        marker: "# {mark} ANSIBLE basic setup: {{ username }}"
        block: ""
    - name: Remove user_conf file
      file:
        path: "/etc/vsftpd/user_conf/{{ username }}"
        state: absent
    - name: Restart vsftpd
      systemd:
        name: vsftpd.service
        state: restarted
        daemon_reload: yes
    - name: Remove Apache virtual site data
      file:
        path: "/var/www/{{ rootdirectory }}"
        state: absent
    - name: Remove Apache conffile
      file:
        path: "/etc/httpd/conf.d/{{ rootdirectory }}.conf"
        state: absent
    - name: Restart httpd
      systemd:
        name: httpd.service
        state: reloaded
        daemon_reload: yes

今回のメイン。削除用のタスクです。

やっていることは冒頭で記した通り。

動作確認

削除用プレイブックを走らせる前

# less /etc/passwd

## 略

USERNAME:x:

設定用プレイブックで追加されたユーザがいることを確認。

# less /etc/vsftpd/user_list

## 略

# BEGIN ANSIBLE basic setup: USERNAME
USERNAME
# END ANSIBLE basic setup: USERNAME

ここにも。

# ls -al /etc/vsftpd/user_conf/
合計 4
drwxrwxr-x 2 ADMIN_USER ADMIN_USER  23 MM月 DD hh:ii .
drwxr-xr-x 3 ADMIN_USER ADMIN_USER 150 MM月 DD hh:ii ..
-rw-rw-r-- 1 ADMIN_USER ADMIN_USER 107 MM月 DD hh:ii USERNAME

# less /etc/vsftpd/user_conf/USERNAME

# BEGIN ANSIBLE basic setup: USERNAME
local_root=/var/www/sample_site
# END ANSIBLE basic setup: USERNAME

ここにも。

# ls -al /var/www/
合計 4
drwxr-xr-x   5 ADMIN_USER ADMIN_USER   51 MM月 DD hh:ii .
drwxr-xr-x. 22 ADMIN_USER ADMIN_USER 4096 MM月 DD hh:ii ..
drwxr-xr-x   2 ADMIN_USER ADMIN_USER    6 MM月 DD hh:ii cgi-bin
drwxr-xr-x   3 ADMIN_USER ADMIN_USER   35 MM月 DD hh:ii html
drwxr-xr-x   3 ADMIN_USER ADMIN_USER   17 MM月 DD hh:ii sample_site

# ls -al /etc/httpd/conf.d/
合計 36
drwxr-xr-x 2 ADMIN_USER ADMIN_USER  137 MM月 DD hh:ii .
drwxr-xr-x 5 ADMIN_USER ADMIN_USER   92 MM月 DD hh:ii ..
-rw-r--r-- 1 ADMIN_USER ADMIN_USER  366 MM月 DD hh:ii README
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 2926 MM月 DD hh:ii autoindex.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 1252 MM月 DD hh:ii php.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 9443 MM月 DD hh:ii ssl.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 1252 MM月 DD hh:ii userdir.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER  824 MM月 DD hh:ii welcome.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER  439 MM月 DD hh:ii sample_site.conf

# less /etc/httpd/conf.d/sample_site.conf


DocumentRoot "/var/www/sample_site/web"
ServerName www.sample_site.jp
ServerAlias sample_site.jp
ScriptAlias /cgi-bin/ /var/www/sample_site/web/cgi-bin/
RewriteEngine on
RewriteCond %{HTTP_HOST} ^sample_site\.jp$
RewriteRule ^(.*)$       http://www.sample_site.jp$1 [R=301,L]

allow from all
AllowOverride All
Options FollowSymLinks
Require all granted

Apache 側にも仮想サイトの設定があり、仮想サイト用のディレクトリが切られていることを確認。

FTPでログインしたり、 hosts で名前解決して仮想サイトにアクセスできることを確認。

一通りプレイブックの設定通りです。

削除用プレイブックを走らせる

Dry run

# ansible-playbook -i /workspace/ansible/targets/hosts /workspace/ansible/reset.yml -u SSH_REMOTEUSER --private-key="/root/.ssh/PRIVATE_KEY" -K --check
BECOME password: 

PLAY [Remove vsftpd and httpd settings] ***************************************************************************
TASK [Gathering Facts] ********************************************************************************************ok: [192.0.2.1]

TASK [Remove user] ************************************************************************************************changed: [192.0.2.1]

TASK [Remove user in vsftpd user_list] ****************************************************************************changed: [192.0.2.1]

TASK [Remove user_conf file] **************************************************************************************changed: [192.0.2.1]

TASK [Restart vsftpd] *********************************************************************************************changed: [192.0.2.1]

TASK [Remove Apache virtual site data] ****************************************************************************changed: [192.0.2.1]

TASK [Remove Apache conffile] *************************************************************************************changed: [192.0.2.1]

TASK [Restart httpd] **********************************************************************************************changed: [192.0.2.1]

PLAY RECAP ********************************************************************************************************192.0.2.1                 : ok=8    changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

まずは Dry run でエラーが出ないことを確認。大丈夫そうです。

本番

# ansible-playbook -i /workspace/ansible/targets/hosts /workspace/ansible/reset.yml -u SSH_REMOTEUSER --private-key="/root/.ssh/PRIVATE_KEY" -K        
BECOME password: 

PLAY [Remove vsftpd and httpd settings] ***************************************************************************
TASK [Gathering Facts] ********************************************************************************************ok: [192.0.2.1]

TASK [Remove user] ************************************************************************************************changed: [192.0.2.1]

TASK [Remove user in vsftpd user_list] ****************************************************************************changed: [192.0.2.1]

TASK [Remove user_conf file] **************************************************************************************changed: [192.0.2.1]

TASK [Restart vsftpd] *********************************************************************************************changed: [192.0.2.1]

TASK [Remove Apache virtual site data] ****************************************************************************changed: [192.0.2.1]

TASK [Remove Apache conffile] *************************************************************************************changed: [192.0.2.1]

TASK [Restart httpd] **********************************************************************************************changed: [192.0.2.1]

PLAY RECAP ********************************************************************************************************192.0.2.1                 : ok=8    changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

続いて本番実行。完了しました。

削除用プレイブックを走らせた後

それでは、念のため確認していきたいと思います。

# less /etc/passwd

設定したユーザが消えていることを確認。

# ls -al /etc/vsftpd/user_conf/
合計 0
drwxrwxr-x 2 ADMIN_USER ADMIN_USER   6 MM月 DD hh:ii .
drwxr-xr-x 3 ADMIN_USER ADMIN_USER 150 MM月 DD hh:ii ..

# less /etc/vsftpd/user_list

## 略

nobody

vsftpd の設定も消えています。OK。

# ls -al /var/www/
合計 4
drwxr-xr-x   4 ADMIN_USER ADMIN_USER   33 MM月 DD hh:ii .
drwxr-xr-x. 22 ADMIN_USER ADMIN_USER 4096 MM月 DD hh:ii ..
drwxr-xr-x   2 ADMIN_USER ADMIN_USER    6 MM月 DD hh:ii cgi-bin
drwxr-xr-x   3 ADMIN_USER ADMIN_USER   35 MM月 DD hh:ii html

# ls -al /etc/httpd/conf.d/
合計 32
drwxr-xr-x 2 ADMIN_USER ADMIN_USER  114 MM月 DD hh:ii .
drwxr-xr-x 5 ADMIN_USER ADMIN_USER   92 MM月 DD hh:ii ..
-rw-r--r-- 1 ADMIN_USER ADMIN_USER  366 MM月 DD hh:ii README
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 2926 MM月 DD hh:ii autoindex.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 1252 MM月 DD hh:ii php.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 9443 MM月 DD hh:ii ssl.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER 1252 MM月 DD hh:ii userdir.conf
-rw-r--r-- 1 ADMIN_USER ADMIN_USER  824 MM月 DD hh:ii welcome.conf

仮想サイトのディレクトリは丸ごと消えて、設定ファイルも消えました。OKです。

当然、FTPでログインできなくなっていますし、ブラウザでアクセスすると仮想サイトが消えたので代理の仮想サイトが応答してきました。OKです。

以上より、一通り意図通りの動作になったことを確認できました。

参考

Ansible

ユーザ削除

ファイル削除

参考

Linuxコマンド

userdelコマンドについて詳しくまとめました【Linuxコマンド集】

LinuxサーバにNICのドライバをインストールした話

2020-12-07T18:40:21+09:00

作業背景

昔、HPE製のタワー型サーバをキッティングした時の話
- 設計段階でNICがテキトーに選定された為、標準搭載のNICと、追加したNICがそれぞれ別の製造元だった。
~~誰がそんなテキトーしたのか？自分自身である。~~

標準搭載されていたNICはBroadcom製追加したNICはIntel製
サーバにはIntel製NICのドライバが入っていなかった。

作業環境

タワー型サーバ　ML30Gen10
OS　　　　　　 CentOS7.4

作業手順

1.NICの製造元とコントローラを確認する
NICの情報を確認する手段はいくつかあるが、複数NICのインターフェース名も確認したかった為、ここではnmcliコマンドを使っている。

$ nmcli

※作業当時のサーバにはそもそもインストールされていなかった為、確認していなかったが、インターフェースのドライバ情報(ドライバ名、バージョン)等はethtoolコマンドで確認できる。

$ ethtool -i <インターフェース名>

2.必要なパッケージをインストールする

$ sudo yum install -y wget                #ドライバのダウンロードに使用
$ sudo yum install -y rpm-build           #ダウンロードしたドライバのコンパイルに使用
$ sudo yum install -y kernel-devel        #コンパイルする時に必要なヘッダファイル等をインストールする

kernel-develをインストールしたら、一度再起動する。

$ sudo reboot

3.ドライバをダウンロードする

$ mkdir /home/user/Downloads        #ダウンロード先を用意する
$ cd /home/user/Downloads           #ダウンロードフォルダに移動
$ wget https://sourceforge.net/projects/e1000/files/igb%20stable/5.3.5.36/igb-5.3.5.36.tar.gz   #NICのベースドライバ
$ wget https://sourceforge.net/projects/e1000/files/e1000e%20stable/3.5.1/e1000e-3.5.1.tar.gz   #当時最新のPCIe用のネットワークアダプタドライバ

4.ダウンロードしたドライバをrpmパッケージにコンパイルする

$ rpmbuild -tb --clean igb-5.3.5.36.tar.gz
$ rpmbuild -tb --clean e1000e-3.5.1.tar.gz

rpmbuildは、設定を変更せずにコンパイルを実行すると、デフォルトで$HOME/rpmbuildディレクトリ以下を生成するので移動する。

$ cd /home/user/rpmbuild/RPMS/x86_64

5.ドライバをインストールする

$ rpm -ivh igb-5.3.5.36.x86_64.rpm

6.ネットワークを再起動する

$ sudo systemctl restart network

ネットワークの再起動後、LANケーブルを挿してNICが認識されることを確認したら終了。

『Failed to get D-Bus connection: Operation not permitted』で、CentOS 7のdockerでPostgreSQLの起動が失敗した件

2020-09-14T00:56:54+09:00

さきほどの話ですが、PostgreSQLのコマンドを確認したかったので、PostgreSQLをインストールしました。
ちょうどLinuxコマンドの動作確認用に、手元でCent OS 7のDockerを起動していたので、そこにインストールして起動します。

イメージとしては、こんな感じです。

$ docker run -it centos:centos7 /bin/bash
[root@15eba360665a /]# whoami
root
[root@15eba360665a /]# yum install postgresql-server
...
Installed:
  postgresql-server.x86_64 0:9.2.24-4.el7_8
...
[root@15eba360665a /]# systemctl start postgresql
Failed to get D-Bus connection: Operation not permitted

PostgreSQLを起動しようとしたのですが、見事に失敗しました。

Failed to get D-Bus connection: Operation not permitted

エラーメッセージで検索したところ、2つの原因がわかりました。

リソースへのアクセス権限が足りない
systemdが起動していない

上記のエラーを解決する方法

同じエラーに遭遇した方のページに、解決方法が書いてありました。

$ docker run -d --privileged --name docker_test centos /sbin/init
$ docker exec -it docker_test /bin/bash
# yum install -y httpd
# systemctl start httpd
# systemctl status httpd

DockerでCentOS7起動時にsystemctlが動かないとき
普通に適当(雑の方の意味)に起動するだけだと動かないのです。
対策として下記の3つを使用することで、systemctlが使用できるようになります。

--privilegedを使用する。

/sbin/initで起動する。

上記に合わせ、-itではなく-dで起動し、起動後にexecする。

https://www.tcmobile.jp/dev_blog/devtool/docker%E3%81%A7centos7%E8%B5%B7%E5%8B%95%E6%99%82%E3%81%AEsystemctl%E3%81%8C%E5%8B%95%E3%81%8B%E3%81%AA%E3%81%84%E3%81%A8%E3%81%8D/ より

-—privilegedを使用する

systemctl実行時のエラーメッセージには、「D-Bus connection: Operation not permitted」と書いてあります。
このことから、権限が足りてないことまではわかります。

そこで登場するのが、『--privileged』というコマンドオプションです。
『privileged』は日本語に訳すと特権という意味で、起動するコンテナに特権を付与します。

2.コンテナに特権を与える場合
コンテナからホスト上のファイルへアクセスする際に最も簡単なものがこちらです。
コンテナに特権を付与することで、ホスト上のすべてのデバイスへのアクセスする権限が与えられます。
以下のようにdocker runのオプションとして「--privileged」と入力すると特権が付与されます。
https://armadillo.atmark-techno.com/blog/10899/4191 より

privilegedは危険を伴うオプションである

『--privileged』を付与することによって、無事にPostgreSQLを起動することに成功しました。
しかしながら、さらに調査を続けたところ、『--privileged』は危険を伴うオプションのようです。

Dockerコンテナを特権モードで実行することが危険な理由
Docker の「Privileged（特権）」コンテナ（以下、特権コンテナ）は、簡潔に言えば、ホストコンピュータに対するすべてのルート権限を備えたコンテナであり、通常のコンテナではアクセスできないリソースへのアクセスが可能となります。
https://blog.trendmicro.co.jp/archives/23577 より

トレンドマイクロ社が専用記事で警告しているくらいですから、鬼気迫るものがあります。
『--privileged』は、あくまで今回のような一時的な使用に限定し、本番環境で使用しないほうが無難です。

/sbin/init経由で、systemdを起動する

initはLinuxカーネルの起動後、最初に実行されるプロセスです。
Qiitaのinitまとめ（ざっくり）が、簡潔にまとめてありオススメです。

initとは

initは他のプロセスを起動させる役割を持っており, 全てのプロセスの親である.

Linuxカーネルの起動後, 一番最初に起動される.

PIDは1が付与されている.

https://qiita.com/h_tyokinuhata/items/26b7dd3526e7061596b9 より

なお、実際にCent OS7で確認したところ、実体はsystemdへのシンボリックリンクになっておりました。

[root@0467571e7b9b ~]# ls -l /sbin/init
lrwxrwxrwx 1 root root 22 Aug  9 21:38 /sbin/init -> ../lib/systemd/systemd

単純に起動したdockerコンテナは、必要最小限のプロセスしか実行されない

『/sbin/init』のプロセスが起動していないことは、実際にプロセスを確認するとわかります。
コンテナ実行時に指定したコマンド以外は、見事に何もプロセスがありません。

$ docker run --rm -it centos:centos7 /bin/bash
[root@d0090488dced /]# ps axuw -w
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  5.0  0.1  11840  2876 pts/0    Ss   08:02   0:00 /bin/bash
root        14  0.0  0.1  51768  3540 pts/0    R+   08:02   0:00 ps axuw -w

まとめ

Dockerコンテナは、必要最小限の権限付与とプロセスしか起動しないため、通常のサーバーとは異なる特性があります。
本記事のようなケースでは、素直に公式のPostgreSQLイメージを使おうと心に誓いました。

MinQ開発日記 (2) DockerでCentOS環境構築

2019-11-30T15:32:41+09:00

Dockerで環境構築

Docker上にネコでもわかる！さくらのVPS講座のCentOSの環境を構築してみます.

この際非対話的な環境構築(つまりDockerfile)に関しては以下を参考にしました.

手元の環境を出来るだけVPS側と共通の環境を構築するのが目的です.

流れ

CentOS7のイメージの取得
パッケージの更新
作業用ユーザーの設定
SSHによる接続
rootユーザーによるSSHによるログイン規制

環境構築

CentOS7のイメージの取得

CentOSイメージを取得します. バージョンは7で良いと思います. image_name:tagという形式で指定します.

FROM centos:7

パッケージの更新

イメージを作成した時点でパッケージの状態は止まっています. 更新しておきましょう.

RUN yum -y update

作業用ユーザーの設定

普通この作業は以下のコマンドを使い対話的に行います.

adduser
passwd

しかしDockerfileではこれらは使えません. 代わりに以下を使うようです.

useradd
chpasswd

一般にパスワードもハードコードはご法度です🔑 このコンテナをデプロイするわけではないので正直ハードコードしても同じなのですが環境変数の設定もしておきましょう. docker inspectのCmdセクションを見ると一目瞭然だからです. あくまでローカルで動かす利便性のための処置です.

また現状のCentOSには何も入っていないので必要なパッケージも追加しておきましょう.

ENV USER_NAME vpsuser
ENV HOME /home/${USER_NAME}

RUN yum -y update && yum -y install \
    useradd \
    chpasswd

RUN useradd --create-home ${USER_NAME} && \
         echo "${USER_NAME}:tekitou" | chpasswd

このDockerfileからイメージを作成します.

docker build -t your_image:0.1 .

名前は自由に決めましょう. これでhome以下にvpsuserが追加されました.

一般ユーザーでのログイン

これは万が一ルート権限を奪われても被害を最小限にするための重要な設定らしいです. Dockerでは必要ない気もしますが, なんとなくルートでシステムを触るのも憚られるので設定をしておきます. Dockerの場合ログインというより一般ユーザーとしてコンテナを実行するということになると思います.

その前にこの時点でどのような状態なのかを調べておきます.

docker run -it --rm your_image:0.1
whoami

でrootと出ればルート・アカウントでログインしていることになります.

USER命令を使うとユーザーが指定できます.

The USER instruction sets the user name (or UID) and optionally the user group (or GID) to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile.

Dockerfile reference

また作業ディレクトリも変更しておきます.

the WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile.

USER ${USER_NAME}
WORKDIR ${HOME}

この状態で再びコンテナを対話モードで起動して

yum -y update

を実行するとPermission deniedというエラーが出るはずです. sudoコマンドを使ってみましょう.

vpsuser is not in the sudoers file.  This incident will be reported.

sudoersファイルにvpsuserはいないよと怒られてしまいました. sudoerというのはグループでここにvpsuserが登録されていると指定されたコマンドが実行できるようになります. /etc/sudoersというファイルで設定されています. 変更方法はいくつかあります.

visudo
usermod
gpasswd

visudoは/etc/sudoersを直接編集するので面倒です. usermodとgpasswdは同じようなことができるようです.

usermodでグループを追加するのは危険

コマンドよりもどのグループを指定するかの方が問題です. 現状を確認しておきましょう.

groups vpsuser

とするとvpsuserはvpsuserというグループに所属しています(プライマリ・グループと呼ぶようです). 確かに/etc/groupの末尾にvpsuserというのが存在します. CentOSではwheelグループに登録するといいようです(これをセカンダリ・グループと呼ぶようです).

usermod -aG wheel ${USER_NAME}

こうするとvpsuserはsudoerとしてsudoでルート権限で実行が許されたコマンドも実行できるようになります.

[Linux] なぜ sudo する権限のあるグループが「 wheel 」という名前なのか
 Linuxのユーザーとグループって何だろう？

SSHによる接続

SSHによる接続はインターネット経由でサーバーにアクセスする場合に通信の内容を傍受されないように暗号化するためです. ので無視します.

Webサーバー

Apacheはwebサーバーですが, Goの場合いらないようです. 正確には要らないというよりはnet/httpパッケージとしてwebサーバーに必要な機能が提供されています.

Package http provides HTTP client and server implementations.

がこの辺はPHPより取り扱いが楽な予感がします. PHPのBuilt-in web serverには以下のような警告文が掲載されています.

Warning
This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

つまり開発用サーバーということでネットに公開するならApacheやnginxなどのwebサーバーが必要になります. ただしGoでもApacheとかnginxとかと使う例とかもあるのであったほうがいいケースとかもあるのかなとは思います.

nginx + golangでWeb API開発
 Load Balancing Recipe
Reverse Proxy Recipe
GoLang: Zero downtime deploys and Rollbacks | Go HTTP server−Echo Web Framework & Apache

アプリケーション・サーバー(APサーバー)

APサーバーも不要なようです. 3層アーキテクチャを前提にすると, APサーバーはWebサーバーから転送されてくるデータを基にDBサーバーと連帯してデータの取得・加工を行うプログラムというのが私の理解です.

しかしその存在意義はよく分かりませんでした.

Web APサーバーとWebフレームワークをつなぐものによるとWebサーバーとWebフレームワークの差異を吸収するために存在するようです.

Apache以外にもlighttpd, nginxなどさまざまなWebサーバがあるわけだが、そうした多様なWebサーバ環境ごとの差異を吸収するためのコードをWebフレームワーク(例：Catalyst, Django, Rails)が書くのは大変である。ましてWebフレームワークは沢山あるわけだし。そうした状況を解決するために出てきたのがPythonならWSGIであり、RubyならRackであり、PerlならPSGIである。

WSGIとPythonでスマートなWebアプリケーション開発をでも似たようなことが書かれています.

Pythonには，Zope，Twisted，Django，TurboGearsなどのさまざまなWebアプリケーションフレームワークが存在します。以前は，このような幅広い選択肢は，新しくPythonを使用しようとするユーザにとって都合が悪いことがありました。使用するフレームワークによって，利用可能なサーバが制限されてしまったり，逆にサーバによって利用可能なWebアプリケーションフレームワークが制限されるといったことがあったためです。そのようなPythonの状況とは対照的に，Javaにおいては，多数のWebアプリケーションフレームワークがあるにもかかわらず，サーバとWebアプリケーションをつなぐ際に，統一されたJava Servelet APIを用いることで，アプリケーションフレームワークを気にせずにServelet APIが利用できる環境で動作させることが可能です。このような，サーバとWebアプリケーションをつなぐ共通のインターフェースをPythonで定義したものが，PEP333（日本語訳版）のWSGI（Web Server Gateway Interface）です。

つまりWebフレームワークで作ったWebサービスを起動するサーバー(常駐プロセス?)で, APサーバーのおかげでWebサーバーとWebフレームワークの組み合わせを柔軟に選択できるようです. Goの場合Webサーバーの機能がパッケージとして提供されているのでAPサーバーのようなミドルウェアで切り離す必要がない, と勝手に考えて不要としておきます.

まとめと課題

スケールだ負荷分散だと言い出すと色々と複雑になるのかもしれませんが, シンプルにAPIサーバーを運用するならミドルウェアを省略できたりGoの標準機能でカバーできたりとシンプルに書けて良さそうです. ネコでもわかる！さくらのVPS講座ではこの後Apacheを入れてファイアウォールの設定をして簡単な静的ファイルを配信して確認します. そしてPHPやDBサーバー(MariaDB)を導入しますが, Goの場合はGo言語を入れないとnet/httpが使えないので, まずGoを入れることにします.

DB

後はGoでAPIサーバーということになると必要なのはDBサーバーということになりますがとりあえず置いておきましょう.

ファイアーウォールの設定

これはDockerfileからは設定できないようです. つまり起動したコンテナから設定する必要があると思いますが, httpd(Apache)が動いている前提なので, 先にGoでWebアプリケーションを作ってからにしようと思います.

Docker : firewalldでssh, http, httpsのみ許可する。(CentOS 7)

Reference

ネコでもわかる！さくらのVPS講座
 チュートリアル：CentOS 7（さくらのVPS）サーバ作成直後に設定しておくべき初期セキュリティ設定
 マンガで学ぶConoHa

Dockerで開発環境を仮想化する

【UNIX】passwdとchpasswdの違い
 DockerのscratchイメージでHello Worldする

その他

Docker + Go + Gin の開発環境を準備する
 Docker development best practices
APIセキュリティ入門
 Web API の紹介
 CentOS 7で始める最新Linux管理入門
 基礎から理解するLinuxサーバー［Cent OS 7.0編］
linuxize
“応用力”をつけるためのLinux再入門

Appendix

イメージのサイズの軽量化

実際に(貧乏)VPS上で走らせるにはalpineとかMulti-stage buildsといった節約が必要になります.

Create the smallest and secured golang docker image based on scratch
Use multi-stage builds

RUN vs CMD

RUNで指定したコマンドは実行された結果がレイヤーとしてイメージに取り込まれるが, CMDはコンテナ内で実行されるコマンドを指定する.

Dockerにおける機密情報の扱い

今回はローカルでの開発環境を構築したいだけなので特にセキュリティ面を考慮する必要性はないのですが, ある程度やり方を押さえておくのはいいかと思います.

buildサブコマンドの--build-argオプションにはビルド時の引数を渡せる. DockerfileではARGに指定する. Dockerfile referenceによると機密情報なんかはコマンドで見えてしまうので, Dockerfileに含めるのは良くないようです.

Warning: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.

要するにイメージに埋め込まれちゃうのでやめとけと言うことです. hisotryサブコマンドで見えてしまうのと, コンテナの再利用が難しくなってしまいます.

公式に用意されている機能としては, Docker secretesと言う機能があるようです(Swarmモードでしか使えないらしいですが).

Manage sensitive data with Docker secrets

もう一つの環境変数を使う方法です. こちらもDockerfileに書いてしまうとinspectサブコマンドでみれてしまうようです.

squash option

Using SSH keys inside docker container

AWX をインストールした後の Server Error を解決したかった話

2019-11-01T02:12:38+09:00

この記事は、 Ansible AWX をインストールしたときに、 Server Error に なったりならなかったりする 問題に対処したときのポエムだ。

はじめに断っておくが、最終的に AWX 8.0.0 で解消しているっぽいものの、原因や正確な条件などは不明なままである。
また後述するが、（タイトルに反して）おそらく Ansible AWX の問題ではなく、 postgres:9.6 の docker イメージの問題ではないかと思われる。

発生した問題の状況

まず、問題が起きている状況をまとめると、以下のような状況だ。

AWX を Docker-Compose を使ってインストール
AWX のバージョンは、 7.0.0 または 6.1.0 (どちらでも発生する)
インストール先は CentOS 7.7 1908 の VirtualBox のゲストマシン
どういうわけか、 問題が起きる場合と起きない場合がある
- 仮想ストレージが (SSD ではなく) HDD 上にあると発生しやすい気がする
- VM のホストが、バックエンドで I/O をガリガリやっていると発生しやすい気がする
- VM のホストが、（バッテリー駆動などで）で省電力モードになっていると発生しやすい気がする
問題が発生するかどうかは、インストール後の最初の起動で決まる。
- 最初の起動で問題が発生すれば、その後も発生し続ける。
- 逆に、最初の起動で問題が発生しなければ、その後は発生しない。

最後の2つが非常に厄介で、全て VirtualBox で同じリソースを割り当てた VM のゲストマシンに、同じ設定で CentOS をインストールしているのにもかからず、問題が発生したりしなかったりする。
訳がわからない。

VM のホストをいろいろ買えつつ試してみたところ、上記のような状態の時に問題が派生しやすい気がするが、ハッキリ「そうだ」と言えるほどの回数は試せていない。

最初、良くある SELinux 関係の問題かと思って SELinux を切って AWX のインストールをやり直してみたが、何も変わらなかった。

AWX エラーの内容

上記スクショの "Server Error" "A server error has occurred" のメッセージだけでは、どんな問題が発生しているのか全くわからないので、とりあえず各コンテナのログをみてみる。

どうやら、 awx_postgres コンテナで、以下のようなエラーが発生しているようだ。

FATAL:  no pg_hba.conf entry for host "172.18.0.2", user "awx", database "awx", SSL off

問題が起きていない環境と、起きている環境で pg_hba.conf (※) を比べると、
問題が起きていない環境では、このファイルの末尾に

host all all all md5

が追記されているという違いがある。

(※: pg_hba.conf は awx_postgres コンテナの /var/lib/postgresql/data/pgdata/pg_hba.conf にあるほか、 docker ホスト側でも /tmp/pgdocker/pgdata/pg_hba.conf として永続化されている。 (postgres_data_dir 変数が初期値の場合。))

この行がないため、 WEB サービスを走らせているコンテナから PostgreSQL を動かしているコンテナへのアクセスが拒否されているようだ。

しかし、問題となっている環境で pg_hba.conf を書き換えても、別のエラーが発生して Server Error が表示される問題は解決しない。

問題が起きる環境と起きない環境を更に詳しく比べると、 PostgreSQL の DB が作成すらされていないことがわかった。
本来なら、 awx_postgres コンテナ内に awx ユーザで DB が作成されている筈なのにもかかわらず、以下のようにコンテナに入って psql の --list オプションを実行すると、エラーになってしまう。

$ sudo docker exec -it awx_postgres /bin/bash
root@xxxxxxxxxxxx:/# psql --list -U awx
psql: FATAL:  database "postgres" does not exist

以上のことから、 pg_hba.conf の書き換えや、 PostgreSQL DB の初期化といった、初期化プロセスが実行されずに「初期化済み」扱いされているのが原因ではないかと、予想がつく。

awx リポジトリ内で同様の不具合が挙がっていないか確認してみたが、似たような問題は挙がっているものの、それそのものズバリの回答は見つからなかった。

pg_hba.conf を書き換えているのは誰だ

audit などを使って pg_hba.conf に関するシステムコールを監視して、何が host all all all md5 と追記しているのかを確認してみる。

その結果、書き換えを行っているのは

bash /usr/local/bin/docker-entrypoint.sh postgres

のプロセスだとわかった。

AWX 7.0.0 インストール時の docker-compose.yml も、 AWX 6.1.0 インストール時の docker-compose.yml も、 postgres:9.6 の docker イメージを使っていることがわかる。
このため、上記の pg_hba.conf の書き換えを行っている docker-entrypoint.sh は、 postgres:9.6 イメージの Dockerfile のエントリーポイントであるこの docker-entrypoint.sh だろう。

前後の PostgreSQL の初期化プロセスも働いていないことを考えると、

        # look specifically for PG_VERSION, as it is expected in the DB dir
        if [ ! -s "$PGDATA/PG_VERSION" ]; then
                # "initdb" is particular about the current user existing in "/etc/passwd", so we use "nss_wrapper" to fake that if necessary
                # see https://github.com/docker-library/postgres/pull/253, https://github.com/docker-library/postgres/issues/359, https://cwrap.org/nss_wrapper.html

この条件分岐の部分が、意図通り働かないことがあるのではないかと思う。

しかし、私は docker に関してはほとんどシロウトなので、ここから docker イメージの定義ファイルを辿って、どこがおかしいのかを調査するのはちょっと難しい。。。

AWX 8.0.0 がリリースされたら解決してた

…とかなんとかやってるうちに、 AWX 8.0.0 がリリースされてしまった。

8.0.0 で AWX のインストールを試してみると、ぱったりと問題が発生しなくなった。

awx_postgres コンテナを作成する docker イメージが、 postgres:9.6 から postgres:10 に変更になったからではないかと考えているが、具体的にどう変わったかは正直わからない。

ひょんなことから、原因は不明ながら問題が解決してしまったので、これ以上調査する気力も失せて、私は考えるのをやめた。

追記: そして、記事を書いた直後に AWX 9.0.0 がリリースされた。ちょっとペース早すぎない!?

systemd/timerを使ってサーバを毎晩リブートさせる

2019-10-29T17:42:48+09:00

サーバを定期的に再起動したいという需要は常に存在します。

どっかの誰かが開放し忘れたコードにより徐々に減っていく空きメモリ。原因を追求するより、定期的に再起動しちゃえば一発解決だよね🧙

なんか時々落ちるこのサービス、いっそ定期的にサーバを再起動しておけば、たとえ落ちたとしても復活するから、大体の時間は動いてるサービスにできるんじゃないの？😈

いいことか悪いことか、かっこいいかどうかはともかくとして、定期的にサーバを再起動しておけば解決できるある種の問題が存在することは事実です。問題の先送りだって一つの技術力ですし(後ろめたいときって前置きが長くなるよね)

ともかくそういうわけで何らかの理由でサーバを定期的に再起動させたいときの設定です。

CentOS7から標準になったSystemdのTimer機能を使います

serviceの作成と登録

$ sudo nano /etc/systemd/system/reboot.service

[Unit]
Description=Scheduled Reboot

[Service]
Type=simple
ExecStart=/usr/bin/systemctl --force reboot

こうやって出来たserviceファイルを

sudo systemctl enable reboot

で登録します。

この段階で、

sudo systemctl start reboot

ってたたいてあげると、サーバが予告なく再起動するかと思います。

Q: rebootコマンドじゃないの？
A: rebootとかhaltはCentOS7から非推奨になりました
10.4. システムのシャットダウン、サスペンド、休止状態 Red Hat Enterprise Linux 7 | Red Hat Customer Portal

Timerの作成と登録

serviceの作成と登録

$ sudo nano /etc/systemd/system/reboot.timer

[Unit]
Description=schedule reboot

[Timer]
Unit=reboot.service
OnCalendar=*-*-* 5:30:00

[Install]
WantedBy=timers.target

この例では毎朝5:30に再起動する記述になっています

sudo systemctl enable reboot.timer
sudo systemctl start reboot.timer

で登録します。

$ sudo systemctl list-timers --all
NEXT                         LEFT          LAST                         PASSED   UNIT                         ACTIVATES
Tue 2019-10-29 17:04:33 JST  4min 59s left n/a                          n/a      systemd-tmpfiles-clean.timer systemd-t
Wed 2019-10-30 05:30:00 JST  12h left      n/a                          n/a      reboot.timer                 reboot.se
n/a                          n/a           n/a                          n/a      systemd-readahead-done.timer systemd-r

という具合に、次の5:30にrebootが予定されていれば出来上がりです。よい再起動ライフを！

プロキシ環境下で Ansible AWX をインストールする Playbook を作る

2019-10-23T03:02:29+09:00

構成管理ツール (いわゆる Infrastructure as Code（IaC）) の中でも比較的易しいと言われる Ansible。
その Ansible の運用を省力化してくれるツールとして Ansible Tower というものがあり、そのコミュニティ管理版 (OSS版) が AWX だ。

その AWX がインストールされたサーバを作成する Playbook を作ろうとしたら意外と手間取ったので、そのメモ。

なお、インストール先は CentOS 7 である。
AWX のインストールは、公式ビルド済み docker イメージを Docker Compose を使ってコンテナ化する方法を使った。

11/21: 追記

docker-compose の PyPI (pip) パッケージが 1.25.0 に更新後、 CentOS 7 (正確には、 Python 2 系を使っている環境) で docker-compose のインストールや実行がうまくいかなくなった。
(commit:719a1b0 で) subprocess32 に依存するようになり、 gcc 等のビルド環境のインストールが別途必要になったためだ。

それに加え、たとえ gcc をインストールしても、依存パッケージの python2 対応が不十分なようで、 docker-compose 実行時にエラーになってしまう。

docker/compose#7030 の Issue には挙がっているが、修正されるかどうか不明なため、一つ前の 1.24.1 を使うことで回避するように、コードを修正した。

python2 ツラい。。。
しかし、 2020年にサポート切れになった後も、 CentOS 7 が生きているしばらくの間はこの辛みと付き合わなければならないようだ。
ツラい。。。

追記ここまで

最終的な Playbook

まず、最終的に作成した playbook を掲載する。

AWX を docker-compose と公式ビルド済みコンテナを使ってインストールする Ansible Playbook

---
- hosts: all
  vars:
    venv_dir: /tmp/venv-awx
    awx_repo: https://github.com/ansible/awx.git
    awx_repo_dir: /tmp/awx
    awx_version: 9.0.1
    postgres_data_dir: /tmp/pgdocker
    #http_proxy: http://proxy.example.com
    #https_proxy: http://proxy.example.com
    #no_proxy: localhost,127.0.0.1,company.example.com
    envs:
      http_proxy: "{{ http_proxy | default(ansible_env.http_proxy | default('')) }}"
      https_proxy: "{{ https_proxy | default(ansible_env.https_proxy | default('')) }}"
      no_proxy: "{{ no_proxy | default(ansible_env.no_proxy | default('localhost,127.0.0.1')) }}"
  tasks:
    - environment: "{{envs}}"
      block:
        - name: update pre-setting packages
          become: yes
          yum:
            name:
              - epel-release
              - yum-utils
            state: latest

        - name: add docker-ce repo
          become: yes
          shell: "yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo"
          args:
            chdir: /etc/yum.repos.d
            creates: docker-ce.repo

        - name: remove conflict packages
          become: yes
          yum:
            name:
              # https://docs.docker.com/install/linux/docker-ce/centos/#uninstall-old-versions
              - docker
              - docker-engine
              - docker-compose
            state: absent

        - name: ensure packages
          become: yes
          yum:
            name:
              - git
              - python-pip
              - python-virtualenv
              - docker-ce
            state: latest
          register: result_pagkages

        # to abort "Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall." error
        # using virtualenv to avoid the conflict of python packages between yum and pip when installing docker-compose
        #  -> https://github.com/docker/compose/issues/5883
        # 
        # to abort "Unable to load docker-compose. Try `pip install docker-compose`." error
        # https://www.uramiraikan.net/Works/entry-3362.html
        # 
        # create virtualenv with --system-site-packages option
        # to make use of any libraries installed in the system’s Python
        # https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#running-in-a-virtualenv
        # 
        # to avoid docker/compose#7030 issue, fix docker-compose package version to 1.24.1
        # https://github.com/docker/compose/issues/7030
        - name: ensure pip packages
          pip:
            name:
              - ansible
              - docker-compose==1.24.1
            state: present
            virtualenv: "{{ venv_dir }}"
            virtualenv_site_packages: yes

        - block:
            - name: create docker proxy settings directory
              become: yes
              file:
                path: /etc/systemd/system/docker.service.d
                state: directory
                owner: root
                group: root
                mode: u=rwx,g=rx,o=rx
            - name: create docker proxy settings
              become: yes
              copy:
                dest: /etc/systemd/system/docker.service.d/http-proxy.conf
                content: |
                  [Service]
                  Environment="HTTP_PROXY={{ envs.http_proxy }}" "HTTPS_PROXY={{ envs.https_proxy }}" "NO_PROXY={{ envs.no_proxy }}"
              register: result_proxy
          when: envs.http_proxy or envs.https_proxy

        - block:
            - name: get the current groups
              command: groups
              changed_when: false
              register: original_groups

            - name: ensure the connecting user is member of docker group
              become: yes
              user:
                name: "{{ ansible_env.USER }}"
                groups: docker
                append: yes
              register: result_user

            # reset ssh connection for refletction the changed groups
            # (`meta: reset_connection` occurs an error on current ansible version)
            # https://stackoverflow.com/a/28213378
            - name: kill open ssh sessions for force reconnection
              shell: sleep 1; pkill -u {{ ansible_env.USER }} sshd
              async: 3
              poll: 2
              when: result_user is changed
          when: ansible_env.USER != 'root'

        - name: enable and restart docker service
          become: yes
          systemd:
            name: docker
            state: restarted
            enabled: yes
            daemon_reload: yes
          when: result_pagkages is changed or result_user is changed or result_proxy is changed

        - name: git clone awx
          git:
            repo: '{{awx_repo}}'
            dest: '{{awx_repo_dir}}'
            version: '{{awx_version}}'
            clone: yes
            force: yes

        - name: record playbook options
          set_fact:
            install_awx_playbook_opotions: >-
              -e postgres_data_dir={{ postgres_data_dir }}
              {% if envs.http_proxy or envs.https_proxy %}
              -e http_proxy={{ envs.http_proxy }} -e https_proxy={{ envs.https_proxy }} -e no_proxy={{ envs.no_proxy }}
              {% endif %}

        - name: execute awx playbook
          shell: "source {{ venv_dir+'/bin/activate' | quote }}; ansible-playbook -i inventory install.yml {{ install_awx_playbook_opotions }}"
          args:
            chdir: '{{awx_repo_dir}}/installer'
          tags:
            - inner-playbook

        - name: ensure the connecting user is not member of docker group
          become: yes
          user:
            name: "{{ ansible_env.USER }}"
            groups: "{{ original_groups.stdout.split(' ') | join(',') }}"
            append: no
          when: result_user is changed
          tags:
            - revert-docker-group

How to use

Uses inventory file

Create the following inventory file:

hostname

[all:vars]
ansible_ssh_user=username

#http_proxy=http://proxy:3128
#https_proxy=http://proxy:3128
#no_proxy=mycorp.org

and run below

$ ansible-playbook -i inventory install_awx.yml

解説

一番大きなポイントは、 Python の Virtualenv を作成し、そこに pip 版 docker-compose を入れて動かしていることだ。

docker-compose Python 依存パッケージの競合

AWX を docker-compose でインストールするには、 docker-compose Python モジュールのインストールが必要だ。
しかし、 OS のパッケージマネージャ (yum) でインストールしているモジュールと、上記 docker-compose Python module で、一部の依存パッケージが競合していたりすると、 pip で global な環境に docker-compose pip モジュールをインストールしようとした時に、

"Cannot uninstall 'requests'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall."

などというようなエラーが発生してしまうことがある。

このため、 Virtualenv 環境を作成して、そこに docker-compose をインストールする形としている。

yum でインストールしたモジュールへの依存

一方、逆にパッケージマネージャ (yum) でインストールしているモジュールそのものに依存している場合、単に Virtualenv を作成しただけだと、モジュール不足で動かなくなることがある。
このため、 Ansible の pip モジュールを使うときは、 virtualenv_site_packages: yes を設定している。

"source {{ venv_dir+'/bin/activate' | quote }}; ansible-playbook -i inventory install.yml {{ install_awx_playbook_opotions }}"

最後に playbook 内で AWX のインストール playbook を実行する際は、上記のように Virtualenv を activate した状態で実行している。

docker グループへの追加

ssh でログインしたユーザが docker コンテナの操作を行えるようにするため、一時的に docker グループへ追加している。

グループを変更しても、ホストマシンにログインし直さないと、設定が反映されず docker を操作することができない。
本来であれば、 Ansible の meta モジュールの reset_connection のアクションで ssh でのサインインが自動的にやり直されるはずなのだが、何故かうまく動かない。

このため、ホストPC の sshd デーモンを非同期で Kill させることで、強制的に ssh の再接続を行っている。

プロキシの解決

プロキシの設定は、以下の両方が必要だ。

docker イメージをダウンロードするための、コンテナホストへの設定
docker コンテナ内への設定

playbook 実行時のオプションとして ansible-playbook -i 'username@hostname,' -e http_proxy=http://proxy.example.com -e http_proxy=http://proxy.example.com install_awx.yml のように設定できるほか、
その設定を省略した場合でも、コンテナホストマシンの http_proxy 環境変数などが設定されていれば、それを使うようにしている。