「docker-compose」の記事 - Crieit

Docker Compose で条件に応じてマウントするボリュームを切り替える

2022-05-31T00:00:59+09:00

経緯

Docker Compose を使って複数の似たようなユースケースで検証を繰り返している中で、

この検証では Apache のドキュメントルートと MySQL のデータを永続化して試験したい
その検証ではどちらも永続化しないで試験したい
あの検証ではファイル数が膨大な上にオペレーションでその膨大なファイルに変更ををかけるので Apache のファイル永続化をしているとディスクIOがボトルネックになって検証に時間がかかり過ぎる

という具合に、同じ Docker Compose のベースを使いつつもユースケースに応じてボリュームをマウントするかどうかを条件によって切り分けたくなりました。

検証ごとに別リポジトリにフォークなりブランチなり切っていくと数が多くなってしまい管理しきれなくなる恐れがあるので、なるべくベースのコードは共通にしておきたいところです。

そこで、「同じ Docker Compose のコードで、条件に応じて処理を変化させる(今回はマウントするボリュームを切り替える)」ということが必要になりました。

コード

上述で指定した各 yml ファイルは次のようになっています。

docker-compose.yml

version: '3.8'
services:
  web:
    build:
      context: ./apache/docker
      dockerfile: Dockerfile
      args:
        WEB_ROOT_DIRECTORY: $WEB_ROOT_DIRECTORY

      ## 略

    volumes:
      # workspace
      - ./workspace:/workspace
      # docker settings template
      - ./template:/template

      ## 略

  db:
    build:
      context: ./mysql/docker
      dockerfile: Dockerfile

      ## 略

      volumes:
      # workspace
      - ./workspace:/workspace
      # docker settings template
      - ./template:/template

      ## 略

オプションなしで使用するデフォルトの docker-compose.yml はエントリポイントのシェルスクリプトや設定、ログの置き場所など最低限のディレクトリをマウントするに留めています。

docker-compose.volumes.yml

version: '3.8'
services:
  web:
    volumes:
      # apache virtual host
      - ./apache/www:/var/www/$WEB_ROOT_DIRECTORY/web
  db:
    volumes:
      # mysql data
      - ./mysql/data:/var/lib/mysql/data

一方、ボリュームマウント用の yml ファイルでは冒頭の通り Apache のドキュメントルート想定のディレクトリや MySQL のデータファイルのディレクトリをマウントするようにしています。

これにより、オプション指定のない場合は後者のファイルが読み込まれないことによりドキュメントルートやデータファイルをマウントせず、オプションを付けるとマウントする、というように挙動を切り替えられる、という寸法です。

ただし、このくらいで済むのでまだ良いですがこれが複雑化すると大量の -fオプションと Composeファイルによる長大なコマンドになってしまう恐れがあるのでその点は要改善ですかね。現時点でも readme.md とかにコマンドを書いておかないと一々打ち込んでいられないレベルですし。

参考

Compose ファイルの指定

Compose CLI 環境変数 — Docker-docs-ja 20.10 ドキュメント

Docker Compose で使用する環境変数にデフォルト値を設定する

2022-05-23T23:59:20+09:00

Docker Compose で使用する .env の環境変数にデフォルト値を設定する方法についてメモ。

経緯

PHP Webアプリケーション用のコンテナからDB用のコンテナに接続する際、DB名やユーザ名・パスワードを任意の値に設定したい。

ただし .env は Git 管理にはしたくないので標準では sample.env 等に逃がしており、うっかりファイルをコピー・リネームし忘れていたり、あるいはキー名をタイポして値が消えてしまったりすると困る……ということでデフォルト値を設定できないか、と考えました。

コード

docker-compose.yml

version: '3.7'

volumes:
    logs:
        driver: local

services:
    php:
        build:
            context: ./_docker/dockerfiles/
            dockerfile: Dockerfile
        working_dir: /var/www
        command: php -S 0.0.0.0:8080 -t public
        ports:
            - 8080:8080
    db:
        image: mariadb
        restart: always
        ports:
            - ${MYSQL_PORT:-3306}:${MYSQL_PORT:-3306}
        environment:
            - MYSQL_ROOT_PASSWORD=pwd
            - MYSQL_DATABASE=${MYSQL_DBNAME:-test}
            - MYSQL_USER=${MYSQL_USER:-user}
            - MYSQL_PASSWORD=${MYSQL_PASSWORD:-pwd}

.env (サンプル)

MYSQL_DBNAME=foo_db
MYSQL_USER=foo_user
MYSQL_PASSWORD="Password-1234"
MYSQL_HOST=192.0.2.1
MYSQL_PORT=3306

早速ですが用意したコード。

まず基本的に .env を用意すれば、 ${HOGE} の形式で環境変数をセットできます。

今回はそこに ${HOGE:-FUGA} と、コロン(:)とハイフン(-)を付けた値を追加しました。これにより、「.env に HOGE=PIYO のように HOGE に値がセットされていれば PIYO を、そうでなければデフォルト値として :- の後の文字列 (この場合は FUGA) をセット」となります。

例えば上述の - MYSQL_DATABASE=${MYSQL_DBNAME:-test} の部分では、 MariaDB のコンテナイメージに対して MYSQL_DATABASE キーへ .env の MYSQL_DBNAME に値がセットされていればその値を、そうでなければ test をセット、となります。

なお - がない場合は empty も許容されるので、空文字列が環境変数にセットされるようです。今回はどれも空文字列では都合が宜しくないので全てハイフンありで統一。

Docker Compose に渡す環境変数ファイルを変更する

2022-05-23T23:58:56+09:00

Docker Compose に渡す環境変数に .env 以外のファイルから渡したいと考えたのでメモしておきます。

経緯

アプリケーション開発環境等で開発環境用の .development.env と本番環境用の .production.env を用意したとして、この2つのどちらかから Docker Compose に環境変数を渡したい。

開発環境なのでアプリ側で使用する環境変数と Dockerコンテナ内で使用する環境変数を統一したい、と。

ただし、デフォルトでは Docker Compose は .env からしか環境変数を読み取ってくれません。これをどうにかしたい。

コマンド

> docker-compose --env-file .development.env up -d

ということでコマンドですが、 docker-compose コマンドに --env-file でパラメータを渡してあげると .env 以外のファイルも環境変数のソースとして渡すことができます。

(余談) コマンド実行時の --env-file パラメータと .envファイルと docker-compose.yml の env_file キー

さて、ここから少しややこしい話を。

Docker Compose 周りでは環境変数関連で見出しに挙げた3つの方法があるようです。

.env については Docker Compose で使用できる環境変数ファイル。これは良いですね。

この .env をそれ以外のファイル名・ディレクトリのファイルから読み取るように変更できるのが docker-composeコマンド実行時の --env-file パラメータ。

ここまでは docker-compose.yml 内で使用できる 環境変数です。

それでは最後、 docker-compose.yml の env_fileキーは何か。

version: '3.7'

services:
    db:
      env_file:
        - .dvelopment.env

最後の env_file は docker-compose.yml 内に記述できるパラメータで、これを使って環境変数のファイルを指定することができます。

ただし、このパラメータで指定した環境変数は、 起動したコンテナ内からは参照できますが、 docker-compose.yml 内からは参照できません。

ということで、今回やりたいこととはマッチしません。そもそもの目的が異なる、ということですね。

過去の先人達のように自分も嵌まったのでこのことも併せてメモしておきます。

Docker 上の Almalinux のタイムゾーン設定について

2022-02-25T22:46:15+09:00

経緯

AlmaLinux ベースの自作LAMP環境構築用 Docker で WordPress を動かしたところ、投稿が「予約投稿の失敗」となってしまい正常に投稿できない現象に遭遇したため対処。

変更

これらの設定を次のようにしました。

Dockerfile (共通)

RUN rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux \
    && dnf -y update && dnf -y install \
    # 略
    # timezone
    glibc-locale-source \
    # locale, timezone
    && localedef -f UTF-8 -i ja_JP ja_JP.UTF-8 \
    && ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
# local & timezone
ENV LANG="ja_JP UTF-8" \
    LANGUAGE="ja_JP:ja" \
    LC_ALL="ja_JP.UTF-8" \
    TZ="Asia/Tokyo"

やり方を大幅に変更。強制コピーで localtime ファイルを上書きするのではなく、段取りを踏んで設定するようにしました。

検証

新しい方法で設定した Docker 環境上に先程と同様 WordPress をインストールして記事を投稿すると、無事投稿が公開されました。

このとき、 wp_posts のテーブルを直接見ると、 post_date, post_modified は同じ日時、 post_date_gmt, post_modified_gmt は -９時間の日時になっていました。

やはりここがおかしかったようです。

続・検証

さて、それではこの時刻の狂いはどこに起因しているのでしょうか。

Webサーバの Dockerコンテナのみ今回の新しい方法で localtime を設定した場合。OKですね。

DBサーバの Dockerコンテナのみ今回の新しい方法で localtime を設定した場合。NGです。

ということで、原因は Webサーバ側にありそうです。

Webサーバでの date

ただ、 Webサーバのコンテナで date コマンドを打っても日時は正しい日時が返ってくるのですよね。

設定方法が未変更の状態の Webサーバコンテナ

# php -r 'echo date_default_timezone_get() . PHP_EOL; echo date("y-m-d H:i:s") . PHP_EOL;'
Asia/Tokyo
22-02-13 19:06:21
# date
Thu Feb 13 19:06:28 JST 2022

設定方法を変更した状態の Webサーバコンテナ

# php -r 'echo date_default_timezone_get() . PHP_EOL; echo date("y-m-d H:i:s") . PHP_EOL;'
Asia/Tokyo       
22-02-13 19:16:50
# date
2022年  2月 13日 日曜日 19:16:56 JST

ご覧の通り時刻は正常……ってあれ、確かに日時は正常ですが、出力フォーマットが異なっています。

どうやら今までの設定変更ではやはり不完全な部分があるようです。どこが、というところまでは追い切れていないですが、ここまでの検証で確かに今までの設定方法では宜しくないであろう、ということが断片的に表われているので、ここは大人しく新しい設定方法に変更していった方が良さそうです。

Docker で MySQL の community版をインストールしようとした際に Failing package is: ... エラー

2022-02-23T00:12:52+09:00

Docker の MySQL コンテナを構築する Dockerfile を走らせようとしたところ、

The GPG keys listed for the "MySQL 8.0 Community Server" repository are already installed but they are not correct for this package.

や

Public key for mysql-community-client-8.0.28-1.el8.x86_64.rpm is not installed. Failing package is: mysql-community-client-8.0.28-1.el8.x86_64

というエラーが発生してしまったので対処。

改修後の Dockerfile

RUN rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022 && dnf -y localinstall https://dev.mysql.com/get/mysql80-community-release-el8-2.noarch.rpm

エラー文で検索したところ、

rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

を追加すると良い、という記事を見かけたので追加したところ、エラーが発生しなくなったのでこれで対処。

CentOS の bash で比較演算と三項演算子的な処理を使って変数に代入する値を分岐するワンライナー

2022-01-12T00:06:20+09:00

Dockerfile 内でコンテナの時刻を変数として流用し、年に対応した rpmパッケージの GPG署名をインストールするで試験した内容の続きとなります。

http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021: OK
http://rpms.famillecollet.com/RPM-GPG-KEY-remi2022: Not Found.

remiリポジトリのGPG署名が2022年版が存在しないので、条件分岐で2021を最大値とするように処理を書いてみました。

説明

わりと複雑になってしまったので順番に読んでいきます。

NOWYEAR=$(sudo date | sudo awk 'END{print $1}' | sudo sed -e 's/年//g') \    # date コマンドの結果から、 awk でスペース区切り1つ目の値(2022年) を抽出し、 `sed -e` で`年`を落とす。結果、`2022`が得られる
    && [ ${NOWYEAR} -gt 2021 ] && ALTERYEAR=2021 || ALTERYEAR=${NOWYEAR} \   # 三項演算子的な処理。 {コマンドとして実行可能な式} && {前述式が true の場合の処理} || {前述式が false の場合の処理} 。今回は得られた現在の年が2021年以降ならば2021を変数に代入、そうでなければ現在の年を変数代入
    && echo ${ALTERYEAR}                                                     # 上の三項演算子的な処理で代入された変数の値を echo

こんな感じです。

RUN MELUSINE=$(sudo date | sudo awk 'END{print $6}') \
    && [ ${NOWYEAR} -gt 2021 ] && ALTERYEAR=2021 || ALTERYEAR=${NOWYEAR} \
    && rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm \
    && rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi${ALTERYEAR}

今回はこんな感じで http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021 か、 http://rpms.famillecollet.com/RPM-GPG-KEY-remi{2020以下} かを読み込む分岐に。

Dockerfile 内でコンテナの時刻を変数として流用し、年に対応した rpmパッケージの GPG署名をインストールする

2021-12-30T01:05:47+09:00

Dockerコンテナをビルドする際にコンテナ内の時刻(年)を他のコマンドに流用したくなりました。その方法をいくつか試したのでメモしておきます。

経緯

AlmaLinux で PHP7.4系をインストールする際に Remiリポジトリからインストールしようとしました。

RUN rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm && \
    rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021
# disable default module
RUN dnf module reset -y php
# install php 7.4
RUN dnf module install -y php:remi-7.4

rpm を使用して Remiリポジトリをインストールしています。

rpm ではパッケージインストールではパッケージが破損していないか、改ざんされていないかをチェックするために GPG署名を用いています。

その公開鍵の取得も、 Remiリポジトリのインストールと同時に行っています。

RUN rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm && \
    rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021

ここでふと思ったのは、URLに年が入っていること。2022年になったら

RUN rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm && \
    rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi2022

に変えたい。かといってそれを毎年手動で更新するのは面倒なので、自動化したい。

であれば、 date コマンドの値を awk に通すなどして年だけ取り出し、それを上述コマンドに流用できないか、と。

検証2

Tychedight

以上を踏まえて、 Docker Compose からの Dockerfile ビルドで試験。

FROM almalinux:8
RUN \cp -pf /usr/share/zoneinfo/Japan /etc/localtime
RUN dnf -y update && yum -y install \
    sudo \
    epel-release
RUN mkdir /home/temp/
# パターン1
RUN GEOFFROY=$(sudo date | sudo awk 'END{print $6}') \
    && sudo echo ${GEOFFROY} >> /home/temp/geoffroy.txt
# パターン2
RUN FROMONT=$(sudo date | sudo awk 'END{print $6}')
RUN sudo echo ${FROMONT} >> /home/temp/fromont.txt
# パターン3
RUN sudo echo \
    | sudo date \
    | sudo awk 'END{print $6}' \
    >> /home/temp/carillon.txt

一応3つパターンを試してみます。さあ、それぞれのファイルには何が出力されるのか……。

# パターン1
RUN GEOFFROY=$(sudo date | sudo awk 'END{print $6}') \
    && sudo echo ${GEOFFROY} >> /home/temp/geoffroy.txt
# 2021

# パターン2
RUN FROMONT=$(sudo date | sudo awk 'END{print $6}')
RUN sudo echo ${FROMONT} >> /home/temp/fromont.txt
#

# パターン3
RUN sudo echo \
    | sudo date \
    | sudo awk 'END{print $6}' \
    >> /home/temp/carillon.txt
# 2021

結果、意図した出力になったのは1つ目と3つ目のパターンでした。 RUN ごとにコンテナが変わるとのことなので2は望み薄だと思っていましたが……。

そこで、パターン1を使って次のように組んでみます。

FROM almalinux:8
RUN \cp -pf /usr/share/zoneinfo/Japan /etc/localtime
RUN dnf -y update && yum -y install \
    sudo \
    epel-release
RUN mkdir /home/temp/
# args

RUN MELUSINE=$(sudo date | sudo awk 'END{print $6}') \
    && rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-8.rpm \
    && rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi${MELUSINE}

これでビルド・起動したコンテナに bash で入って確認。

# rpm -qa 'gpg-pubkey*'
gpg-pubkey-3abb34f8-5ffd890e
gpg-pubkey-478f8947-5ff329c5

内容的にデフォルトと2021の公開鍵が入っているように見えます。

# rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi
# rpm -qa 'gpg-pubkey*'
gpg-pubkey-3abb34f8-5ffd890e
gpg-pubkey-478f8947-5ff329c5
gpg-pubkey-00f97f56-467e318a

手動で RPM-GPG-KEY-remi を入れると増えました。

# rpm --import http://rpms.famillecollet.com/RPM-GPG-KEY-remi2021
# rpm -qa 'gpg-pubkey*'
gpg-pubkey-3abb34f8-5ffd890e
gpg-pubkey-478f8947-5ff329c5
gpg-pubkey-00f97f56-467e318a

ついでに手動で RPM-GPG-KEY-remi2021 を入れようとしましたが、数は増えませんでした。先のコードで RPM-GPG-KEY-remi2021 がインストールできていることが確認できました。OKです。

余談

実は上述の通り年指定のない http://rpms.famillecollet.com/RPM-GPG-KEY-remi があるので、それを入れてしまえば終わりのような気もするのですが……折角なのでチャレンジしてみた次第です。

参考

PHP インストール

PHPインストール PHP7.4 CentOS8 | AlmaLinux 自宅サーバ

もしかして、そもそもいらない……？

(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

awk で条件に合致する最後の行のみ処理する

2021-12-13T23:56:29+09:00

経緯

次のようなシチュエーションを考えます。

Docker 環境で MySQL の初期パスワードを変更するシェルスクリプトをエントリポイントで実行
MySQL のログ (特に mysql-error.log) をボリュームマウントしてファイルの永続化を実施している
このプロジェクトでディレクトリを使い回して1回目の MySQL のログを削除せずに2回目のビルドを実行する

このとき、 mysql-error.log 内に初期パスワードが2回記録されることになります。

すると、条件に合致する最初の行(1回目の初期パスワード)を処理しようとした際に(2回目のパスワードが設定されているため)パスワードが合致せず、処理が失敗してしまう遭遇したので対処しました。

対処

-    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk '{print $13}')
+    DB_INIT_PASSWORD=$(sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk 'END{print $13}')

エントリポイントのシェルスクリプトで、 awk に END を付け加えました。処置としてはこれだけ。

検証

試しに、中身のシェルスクリプトを該当環境で手動で実行してみます。

変更前

# sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk '{print $13}'
XXXXXXXXXXXX
YYYYYYYYYYYY

変更前では複数マッチしていることが確認できます。このうち、最初のパスワード XXXXXXXXXXXX で認証をくぐって理しようとすると冒頭のようにパスワードが合致せず失敗します。

変更後

# sudo grep 'temporary password' /var/log/mysql/mysql-error.log | sudo awk 'END{print $13}'
YYYYYYYYYYYY

そこで変更後。今度は1回目のパスワード XXXXXXXXXXXX がヒットせず、2回目のパスワード YYYYYYYYYYYY のみがヒットするようになりました。

これで Docker Compose 全体のビルドもコケなくなりました。

参考

awkで最後の行(最終行)のみ処理を行わせる | 俺的備忘録 -なんかいろいろ-

Dockerコンテナに SSHログインできるようにする(パスワード方式)

2021-12-10T23:34:08+09:00

経緯

Dockerコンテナでファイル永続化をすると便利ではあるのですが、 Windows-Linux間だと異なるファイルシステム間で整合性を保つ処理でもたつき、大量のファイルがある場合は体感的には加速度的に遅延がひどくなってしまいます。

一時的な試験であれば、ファイル永続化を捨てるという選択肢を取ることができると思います。

そこで課題となるのは、ファイルをどうやってコンテナの中に持ち込むか。

そのための一つの方法として、 SFTP を採ることにしました。通常のサーバと同様に、 SFTP で接続してファイルをアップロードする、と。

であれば、 SSHログインできなければ話が成立しないので、 SSHログインできるようにしてみたいと思います。

コード

ベース: arm-band/docker_compose_ambergrease

例によって Ambergrease をベースに使います。

.env

# 略
WEB_HOST_PORTSSH=2222
WEB_CONTAINER_PORTSSH=22
WEB_SSH_USER=root
WEB_SSH_PASSWORD=Password-1234
# 略

今回はWebサーバのコンテナに SSHログインしたいので、必要なパラメータを追加します。

管理者権限ユーザもハードコーディングはしたくないので一緒に変数にしておきます。ただ、 Docker で一時的な試験環境なので SSH はパスワード認証方式で良いかな、と。

docker-compose.yml

  web:
    build:
      context: ./apache/docker
      dockerfile: Dockerfile
      args:
        # 略
        WEB_HOST_PORTSSH: $WEB_HOST_PORTSSH
        WEB_CONTAINER_PORTSSH: $WEB_CONTAINER_PORTSSH
        WEB_SSH_USER: $WEB_SSH_USER
        WEB_SSH_PASSWORD: $WEB_SSH_PASSWORD
      # 略
    volumes:
      # 略
      # apache virtual host
#      - ./apache/www:/var/www/$WEB_ROOT_DIRECTORY/web
      # 略
    ports:
      # 略
      - "$WEB_HOST_PORTSSH:$WEB_CONTAINER_PORTSSH"
    entrypoint: bash -c "bash /workspace/entrypoint_web.sh $WEB_ROOT_DIRECTORY $WEB_DOMAIN $WEB_HOST_PORTNUM $WEB_CONTAINER_PORTNUM $WEB_HOST_PORTSSL $WEB_CONTAINER_PORTSSL $WP_CLI $WEB_SSH_USER $WEB_SSH_PASSWORD && /bin/bash"
    # 略

主に変更した部分のみ掲載。

args: .env で追加したホスト・コンテナ双方のポート番号を引数に追加
volumes: 今回の本題。ファイル数が多いと激重になってしまうので仮想ホストのファイル永続化を切っています
ports: .env で追加したホスト・コンテナ双方のポート番号を紐付け
entrypoint: エントリポイントとして実行するシェルスクリプトに渡す引数に .env で追加した $WEB_SSH_USER, $WEB_SSH_PASSWORD (SSHログインユーザ名・パスワード)を追加

Dockerfile

# 略
# yum install
RUN yum -y update && yum -y install \
    # 略
    # network ss (instaed of netstat)
    iproute \
    # SSH
    openssh-server

# 略

# SSH
RUN mkdir /var/run/sshd

追加した項目は openssh-server のインストールと、ディレクトリ /var/run/sshd の作成のみ。それ以外の処理はエントリポイント側に投げました。

entrypoint_web.sh

# 略

# SSH
sed -ri 's/^#PermitRootLogin yes/PermitRootLogin yes/' /etc/ssh/sshd_config
echo "${8}:${9}" | chpasswd
ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key
/usr/sbin/sshd -D &

先程述べた通り、 SSHサーバについての主な処理はこちらに追加しました。

管理者権限のログインを有効化し
パスワードを上述の Docker Compose から引数で渡された .env の値に書き換え
使用しないものの存在しないとエラーになるので秘密鍵を生成
最後にフォアグラウンドで SSHサーバを起動

これで SSHサーバが起動し、 .env でアクセスできるようになりました。

なお、ポート番号は .env のホスト用のポートなので接続する際は注意。

参考

Docker の phpMyAdmin公式イメージでメモリ上限等を増やす (Docker Compose 使用)

2021-12-09T00:28:54+09:00

表題の通り、 phpMyAdmin公式イメージでメモリ上限等を増やす方法をメモ。

経緯

phpMyAdmion で大量のデータをインポートしようとしたら、以下のエラーが出て失敗してしまいました。

Fatal error: Allowed memory size of XXXXXXXXX bytes exhausted (tried to allocate 16 bytes) in ......

メモリ不足ですね……そのため、 phpMyAdmin の設定を変更します。

対処

docker-compose.yml

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    volumes:
      # sessions
      - ./phpmyadmin/sessions:/sessions
      - ./phpmyadmin/conf/phpmyadmin-misc.ini:/usr/local/etc/php/conf.d/phpmyadmin-misc.ini

docker-compose.yml でこのようにします。

ディレクトリ・ファイルは次の2つをボリュームマウントして永続化しています。

/phpmyadmin/sessions
/phpmyadmin/conf/phpmyadmin-misc.ini

/phpmyadmin/conf/phpmyadmin-misc.ini

allow_url_fopen = Off
max_execution_time = 600
memory_limit = 64M
post_max_size = 64M
upload_max_filesize = 64M

後は phpmyadmin-misc.ini でパラメータを記述してあげればOK。

参考

Docker から MySQL 用のコンテナで初期化・起動しようとしたら The server option 'lower_case_table_names' is configured ... エラーで失敗する

2021-11-20T17:13:30+09:00

現象

Docker から自作の MySQL 用のコンテナで初期化・起動しようとしたら MySQL が起動しておらず、手動で初期化コマンドを実行したら以下のエラーで失敗する現象に遭遇しました。

[ERROR] The server option 'lower_case_table_names' is configured to use case sensitive table names but the data directory is on a case-insensitive file system which is an unsupported combination. Please consider either

using a case sensitive file system for your data directory or switching to a case-insensitive table name mode.

環境

環境としては以下の自作の LAMP環境作成用の Docker Compose を使用しました。

GitHub - arm-band/docker_compose_ambergrease

MySQL5.7系で、 entrypoint で

設定ファイルをテンプレートからコピーして配置
/usr/sbin/mysqld --user=mysql --initialize & で初期化コマンド実行
/usr/sbin/mysqld --user=mysql & で MySQL 起動
MySQL のログから初期パスワードを見つけ出し、環境変数で設定された値に管理者パスワードを変更

をしています。

このうち、2つ目の /usr/sbin/mysqld --user=mysql --initialize & で上述のエラーが発生していました。

対処

エラー文は「 MySQL の設定では大文字小文字を区別する設定になっているが、 dataディレクトリのファイルシステムは大文字小文字を区別しない環境になっていて不一致を起こしているので、どちらかに統一してね」ということのようです。

今回は Docker for Windows 利用で、 dataディレクトリはホスト側の Windows のフォルダにボリュームをマウントしています。また、データはコンテナを落としても保持していてほしいので Windows とのボリュームマウントを解除する方向性はなし。

そのため、ファイルシステムは Windows 依存になるので、大文字小文字を区別するファイルシステムに寄せるのは厳しい。したがって、 MySQL 側の設定を調整することにします。

[mysqld]

## 略

# not only lowercase characters in tablename
# lower_case_table_names = 0
lower_case_table_names = 1

該当の設定は lower_case_table_names 。この値0だと大文字小文字を区別する、1だと小文字に変換、2だと大文字小文字を区別してディスクに保存するが MySQL からのルックアップ時に小文字に変換、という挙動になるようです。

今回はシンプルに全て小文字変換で1とすることにしました。

これで問題が解決されたことを確認。

参考

Github で特定ユーザの publicリポジトリの名前の一覧を生成する Docker Compose

2021-07-11T01:08:30+09:00

経緯

自分のあるリポジトリを clone しようとして、名前を失念。探すのに手間取ったのでリポジトリの名前の一覧を生成するスクリプトが欲しくなりました。

調査

調べたら Linuxコマンドでどうにかなりそうだったので、 Docker で Linux環境を用意してごにょごにょしよう、と思い立ちました。

成果物

GitHub - arm-band/docker_list_of_hirokawa: Github の特定ユーザの public リポジトリの一覧を生成する Docker Compose 設定集。

構成

ディレクトリ構造

PROJECT_ROOT/
    ├ docker/
    │   └ Dockerfile
    │
    ├ entrypoint/
    │   └ entrypoint.sh
    │
    ├ template/
    │   └ script.sh       // コンテナ内で実行したいスクリプトのテンプレート。一部変数をエントリポイントで置換
    │
    ├ workspace/          // リポジトリ名一覧のテキストファイルのダンプ先
    │
    ├ .env                // docker-compose.yml 用の環境変数
    └ docker-compose.yml

今回はこんなディレクトリ構造に。

docker-compose.yml

version: '3.8'
services:
    hirokawa:
        build:
            context: ./docker
            dockerfile: Dockerfile
            args:
                USER_NAME: $USER_NAME
                FILE_NAME: $FILE_NAME
        volumes:
            # entrypoint
            - ./entrypoint:/entrypoint
            # workspace
            - ./workspace:/workspace
            # docker settings template
            - ./template:/template
        tty: true
        entrypoint: /bin/sh -c "/bin/sh /entrypoint/entrypoint.sh $USER_NAME $FILE_NAME && /bin/sh"

リポジトリ名の一覧を取得したい対象ユーザ名とダンプ先ファイル名を .env で指定しています。

.env

USER_NAME=saigyo
FILE_NAME=repository_list.txt

上述の通り。

docker/Dockerfile

FROM alpine:latest
RUN apk update && \
    apk upgrade && \
    apk add --no-cache \
    jq \
    bash \
    sed \
    curl
RUN mkdir /var/script
RUN chmod 777 /var/script

必要なパッケージのインストールとスクリプトの生成先のディレクトリの作成。

今回はやることが最小限なので alpine を使用。

entrypoint/entrypoint.sh

sed -e "s/USER_NAME/${1}/gi" -e "s/FILE_NAME/${2}/gi" /template/script.sh > /var/script/script.sh

一部変数名を .env の値で置換。一行しかないので command でも良かったかも。

template/script.sh

for page in $(seq 1 10);
    do result=$(curl -s "https://api.github.com/users/USER_NAME/repos?page=$page&per_page=100"|jq -c '[.[] .name]'|jq -c '.[]');
    if [ -z "$result" ];
        then break;
    fi;
    formatted_result=$(echo "$result"|sed -e "s/\"//gi");
    echo "$formatted_result" > "/workspace/FILE_NAME";
done

実行するスクリプトのテンプレート。個人ユーザ対象で curl で Github API を叩いて100個(指定可能な最大数)ずつ出力、 jq でフィルタリングして、 workspace にファイルとしてダンプ。

これでやりたいことは実現できました。

参考

サンプル

jq

jq play

alpine で bash

【docker alpine linux】でbashの使用方法 - Qiita

starting container process caused: exec: "bash": executable file not found in $PATH: unknown

プログラマーの雑記: docker コンテナにログイン時に、「executable file not found in $PATH」エラーの対応

alpineイメージへの entrypoint 指定

【Docker】ENTRYPOINT と CMD の仕組みと小技 – 株式会社シーポイントラボ｜浜松のシステム・RTK-GNSS開発

Docker で Node.js のバージョン切替環境を構築する

2021-07-05T23:53:53+09:00

経緯

Windows環境では長らく Nodist を使ってきましたが、流石にそろそろ見切りを付けて安定的に Node.js を使用できる環境を構築したいと考えました。

理由としては以下の2点。

そもそも Nodist のバージョンが 0.9.1 (< 1.0.0) であること
0.9.1 のリリースが2019/3/30で、2年以上も更新がされていないこと

正直、2020 年ではもう使えない Nodist はアンインストールする (Windows)に全て書かれていることなので改めて書く必要はないかもしれません。

個人的には npm の切替時にエラーになってしまって切り替えられないなどの不具合が発生し始めたので、先述したようにそろそろ限界かな、と感じるようになりました。

そこで次の環境について考えたとき、やはり自PCの環境を汚さずに済むので Docker で構築することにしました。

構成

GitHub - arm-band/docker_sink_vertex: A collection of settings for running Node.js on Docker.

ディレクトリ構造

PROJECT_ROOT/
    │
    ├ .env
    ├ .gitignore
    ├ docker-compose.yml
    └ readme.md

今回は Docker公式イメージの Node.js を使うので、構成はいたってシンプルです。

.env

NODE_VERSION=16.3.0
PROJECT_ROOT_DIRECTORY=../workspace/

Docker Compose の前に .env のサンプルを。指定しているのは Node.js のイメージのバージョン指定とマウントするボリュームのパスです。

今回はそもそもバージョン切替可能な Node.js の環境を構築することが主眼なので、バージョン指定をパラメータで指定できるようにしておきます。

それから、 Node.js 環境で実行したいプロジェクトがあるはずなので、そのプロジェクトのディレクトリをコンテナ内にマウントさせるためにパス指定を記述しておきます。

docker-compose.yml

version: '3.8'
services:
    vertex:
      image: "node:$NODE_VERSION"
      user: "node"
      volumes:
        # project root
        - $PROJECT_ROOT_DIRECTORY:/home/node/app
      tty: true
      ports:
        - "3000:3000"
        - "3001:3001"

以上を踏まえて Docker Compose の yml 。

.env で説明した通り、 Node.js のイメージ指定とボリュームマウントの指定があります。

地味にポイントなのは ports 。今回は Browsersync を使った Gulpタスクを走らせようとしているのですが、ブラウザはホスト側にしかないため、ホストからコンテナ内の Browsersync の API を参照できるようにポートを指定しておきます。

これで試験してみます。

試験

上述の docker-compose.yml を作る途中で ports 指定をせず、何もカスタマイズしていない Gulp を走らせました。すると、以下のようなエラーが発生しました。

Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false)

上述した通りブラウザはホスト側にしかなく、一方で Browsersync 含む Gulpタスクはコンテナ内で動いているので、当然と言えば当然ですよね。

これで ports 指定を加えました。

また、 Browsersync 側の設定も変更を加えます。

browserSync.init({
    server: {
        baseDir: './dist/'
    },
//    open: 'external',
    open: false,           // ブラウザオープンをしない
    https: true
});

openオプションを false にすることで、ブラウザを自動的に起動しないようにしました。これをしておかないと上述のエラーが発生してしまうので。

代わりに手動でブラウザを開く必要がありますが、已む無し。 https://localhost:3000/ できちんと見られるので良しとします。

試験2

追試験を実施している最中に、一部の環境で gulp.watch による自動ビルドが2回に1回しか走らない現象に遭遇しました。

Node.js のバージョンを切り替えてもダメで、しかも ejsファイルはOKですが scssファイルや ymlファイルはダメなど、条件がいまいちよく分かりません。

検索してみるとオプションで { usePolling: true } を指定すると直ったというのを見かけたので Gulpタスクに書き足してみました。

すると、現象が収まりました……ということは、ファイルをウォッチするタイミングか何かが上手くいっていないということ？

とりあえず動いたので良しとします。

試験3

試験2の途中で Node.js のバージョンを切り替えたらそもそも yarn がエラーでコケるなど副作用が発生したのでgulp-sass を Node.js v16 環境に合わせて調整するに書いたように諸々対処しました。

これでようやく想定している Gulpタスク一式が使えるようになりました。

参考

きっかけ
- 2020 年ではもう使えない Nodist はアンインストールする (Windows)
Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false) のエラー
- javascript - Browsersync within a Docker container - Stack Overflow
- Laravel5.5、MixのBrowserSync
gulp.watch が動かない
- 【開発環境】gulpのwatchが動かない · Issue #54 · AyumuNekozuki/niconico-darkmode · GitHub

Docker で PHP + SQLite3 の開発環境を構築する

2021-05-01T13:26:57+09:00

SQLite を試験したくなったので、環境を Docker で作ることにしました。

ベースは CentOS7 + Apache + PHP7 (Composer, Xdebug) の開発環境を Docker で作るで。

構成

ディレクトリ構造

PROJECT_ROOT/
    │
      # 略
    │
    ├ sqlite/
    │
      # 略

SQLite 用のディレクトリを掘っただけで、後は同じです。

docker-compose.yml

version: '3.8'
services:
  web:
    build:
      context: ./apache/docker
      dockerfile: Dockerfile
      args:
        # 略
        SQLITE_TABLENAME: $SQLITE_TABLENAME
    labels:
      lamp.sqlite.php: "SQLite PHP"
    volumes:
      # 略
      # sqlite
      - ./sqlite:/var/sqlite/
      # 略
    entrypoint: bash -c "bash /workspace/entrypoint.sh $WEB_ROOT_DIRECTORY $WEB_DOMAIN $WEB_HOST_PORTNUM $WEB_CONTAINER_PORTNUM $WEB_HOST_PORTSSL $WEB_CONTAINER_PORTSSL $SQLITE_TABLENAME && /bin/bash"

docker-compose.yml も大部分は同じです。変数(SQLITE_TABLENAME)とボリュームがそれぞれ1つ増えたのと、 entrypoint へ渡す引数が1つ増えたくらいです。

.env

WEB_ROOT_DIRECTORY=sample_sqlite
WEB_DOMAIN=lvh.me
WEB_HOST_PORTNUM=8080
WEB_CONTAINER_PORTNUM=80
WEB_HOST_PORTSSL=4043
WEB_CONTAINER_PORTSSL=443
SQLITE_TABLENAME=maindb

上述の通り、 SQLite のファイル名を決める変数が増えました。

apache/docker/Dockerfile

FROM centos:centos7

# 略

# enable repository remi & remi-php74
RUN yum-config-manager --enable remi && yum-config-manager --enable remi-php74
# php
RUN yum -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
# sqlite
RUN yum -y install sqlite sqlite-devel
# disable repository remi & remi-php74
RUN yum-config-manager --disable remi && yum-config-manager --disable remi-php74

# 略

# volume directory
RUN mkdir /template
RUN mkdir /var/www/${WEB_ROOT_DIRECTORY}
RUN mkdir /var/www/${WEB_ROOT_DIRECTORY}/web
RUN mkdir /workspace
RUN mkdir /var/sqlite

こちらも概ね同じ。 PHP のインストール直後に sqlite, sqlite-devel をインストールしています。また、最後にボリュームとしてマウントするディレクトリを作成しています。

workspace/entrypoint.sh

# 略

# make sqlite file & create dummy table
if [[ ! -e /var/sqlite/${7}.sqlite3 ]]; then
    echo ".exit" | echo "create table testtable(one varchar(10), two smallint);" | sqlite3 /var/sqlite/${7}.sqlite3
fi

# Apache start
/usr/sbin/httpd -DFOREGROUND &

entrypoint も同様ほぼ同じですが、 Apache 起動前に「もし SQLite のデータファイルが該当ディレクトリにない場合は作成」の処理を追加しました。テーブルがないとファイルが生成されなかったので、ダミーテーブルも CREATE しています。

検証

上述で構築された SQLite にダミーデータを流し込んでテストしてみます。

# sqlite3 /var/sqlite/maindb.sqlite3

sqlite> insert into testtable values('hello', 10);
sqlite .exit
#

まずはダミーテーブルにダミーデータを INSERT します。

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
    $stmt = $pdo->prepare("SELECT * FROM testtable WHERE two >= :two");
    $stmt->execute([
        'two' => 5
    ]);
    $result = $stmt->fetchAll();
    var_dump($result);
}
catch (Exception $e) {
    echo $e->getMessage() . PHP_EOL;
}

次に上述のような index.php を作成し、Webアクセスします。

/var/www/sample_sqlite/web/index.php:25:
array (size=1)
  0 => 
    array (size=2)
      'one' => string 'hello' (length=5)
      'two' => string '10' (length=2)

結果。これで PHP から PDOオブジェクト経由でダミーテーブルに接続できたので、ひとまず環境構築という点では完了です。

参考

php 7.4をソースからインストール時にchecking for sqlite3 > 3.7.4… no configure: error: Package requirements (sqlite3 > 3.7.4) were not met:
コマンドの途中で聞いてくる yes を自動入力したい？それ yes で出来るよ – 自主的20%るぅる
シェルスクリプトでファイルの存在を確認する方法 | LFI
PHP から SQLite を使う手順 – ラボラジアン
- 最終的には SQLite3オブジェクトからではなく PDOオブジェクトから接続してしまいましたが
PHP + SQLite3 超入門したメモ - Qiita

無認証 SMB を samba で秒で立ち上げる Dockerfile (& docker-compose)

2020-06-23T01:07:00+09:00

docker 上の Linux (alpine) で Samba を立ち上げ、無認証の SMB 共有を開始する Dockerfile をメモっておく。

https://gist.github.com/advanceboy/a315d83d900929103d858a461b673e52

FROM alpine:3.10

RUN mkdir -p /samba/share && \
    chmod -R 0777 /samba/share && \
    chown -R nobody:nobody /samba/share

# install samba
RUN apk update && \
    apk add samba
RUN { \
    echo "[global]"; \
    echo "  security = user"; \
    echo "  map to guest = Bad User"; \
    echo "  guest account = nobody"; \
    echo "  min protocol = SMB2"; \
    echo "[public]"; \
    echo "  path = /samba/share"; \
    echo "  writable = yes"; \
    echo "  guest ok = yes"; \
    echo "  guest only = yes"; \
    echo "  create mode = 0666"; \
    echo "  directory mode = 0777"; \
} > /etc/samba/smb.conf
EXPOSE 139 445

# start smbd as foreground
ENTRYPOINT ["/bin/ash"]
CMD ["-c", "nmbd restart -D && smbd restart -FS --no-process-group



使用例

手っ取り早く実行したい場合、以下のような docker-compose.yml を Dockerfile と同じフォルダに保存し、

```yaml:docker-compose.yml

version: '3'

services:

  smb:

    build: .

    ports:

      - 445:445


コマンドプロンプト等のターミナルで、以下のように実行する。

```bash
docker-compose build
docker-compose up


何に使うのか

docker でデータを永続化する際、 Bind Mounts を使えば、デスクトップ側にファイルが永続化されているため、そのまま永続化されたファイルを覗き見ることができる。

しかし、 Bind Mounts では一部の機能に制限があることから、 Volumes (Named Volumes, Anonymous Volumes) を使うこともあるだろう。

(とりわけ Windows デスクトップから Linux コンテナを使う場合、 ファイルシステムの違いから Bind Mounts だと期待しない動きに遭遇しやすい。)

このとき、 Volumes の中身を SMB で共有させるコンテナを起動させておくと、 デスクトップ側から Volumes の中身が簡単に見られるようになるので、開発や検証に便利になる。

（但し上記の手順だと、 認証などが一切なく、 ネットワーク内のだれからでもアクセスできるので、 実運用上では 別途認証やアクセス元の制限を加えるなど、注意は必要だ。）

Docker Desktop for Windows での回避策

ホスト側が Linux であったり、 Windows 上の Docker Toolbox であれば、上記の手順だけでも問題なく SMB 共有が実行されるだろう。

しかし、 ホスト側が Docker Desktop for Windows である場合は、 Windows とコンテナの間で 445 ポートが競合してしまい、 以下のようなエラーが出て起動に失敗するはずだ。

ERROR: for smb  Cannot start service smb: Ports are not available: listen tcp 0.0.0.0:445: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
ERROR: Encountered errors while bringing up the project.


SMB は他のポートではアクセスができない。

また、 Docker Desktop for Windows では、 Windows デスクトップにポートフォワーディングせずに、 Hyper-V 上の Linux のホストマシンにアクセスする方法が用意されていない。

このため、コンテナの SMB 共有させたければ Docker Desktop を起動している Windows 側の SMB を止めるしかない。

[blogcard url="http://sangosthi.blogspot.com/2011/03/how-to-disable-cifssmb-port-445-on.html"]



上記の記事にあるように、 Windows 側で Server サービスを止め、無効化した後に OS を再起動すると、 445 ポートが空く。

この状態で、 docker-compose up すれば、エラーなく実行できるだろう。

ただ、ファイル共有をはじめとする様々な機能が Windows 側で動かなくなるだろうが。。。

(ということもあり、あまりオススメできる方法ではない。)



Firebase フロントエンド(Vue.js)/Cloud Functions を同一docker-composeで実行する際に感じたこと
2019-12-30T14:15:44+09:00
はじめに

2019/12/30現在において、Firebaseを開発する際に生じる不都合の一つとして、node version管理があると思います.

Cloud Functionsの開発において、nodeのバージョンはversion8、あるいは10がサポートされています.


  Cloud Functions ランタイムに関数をデプロイするには Firebase CLI が必要です。Node.js バージョン 8 と 10 がサポートされています。Node.js と npm をインストールする場合は、Node Version Manager をおすすめします。

  https://firebase.google.com/docs/functions/get-started?hl=ja


つまり、こんなことが頻発します.

[dorakueyon]% yarn build
yarn run v1.19.2
error functions@: The engine "node" is incompatible with this module. Expected version "8". Got "10.15.3"
error Commands cannot run with an incompatible environment.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.


このように、異なるversionが依存する開発では、その依存性をDockerに閉じ込めることで幸せになれます.

参考として、githubにcodeを置かせていただきました.

- github.com/dorakueyon/vue-firebase-cloud-function-docker-starter

Vue.js + Cloud Functionsのフォルダ構成

Docker化する前に、プロジェクトを作成した上でフォルダ構成をみてみます.


Vue.js + Firebaseプロジェクト作成


$ vue create project-name
$ firebase init



フォルダ構成 (node_modules配下を除いています)


.
├── README.md
├── babel.config.js
├── firebase.json
├── functions
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   ├── src
│   └── tsconfig.json
├── node_modules
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
├── src
│   ├── App.vue
│   ├── assets
│   ├── components
│   ├── main.ts
│   ├── router
│   ├── shims-tsx.d.ts
│   ├── shims-vue.d.ts
│   └── views
├── tsconfig.json
└── yarn.lock


FrontとCloud Functionsを開発する場合、プロジェクト直下と./funcions直下とで開発環境が分かれます.

それぞれにDockerfileを配置した上で、プロジェクト直下にdocker-compose.ymlを配置します.


Dockerファイルを追加したフォルダ構成 (node_modules配下を除いています)


.
├── Dockerfile <-
├── README.md
├── babel.config.js
├── docker-compose.yml <-
├── firebase.json
├── functions
│   ├── Dockerfile <-
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   ├── src
│   │     ├── index.ts
│   │     └── services
│   │         └── project-name -> ../../../src/services/project-name <- シンボリックリンク
│   └── tsconfig.json
├── node_modules
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
├── src
│   ├── App.vue
│   ├── assets
│   ├── components
│   ├── main.ts
│   ├── router
│   ├── services
│   │   └── project-name <- シンボリックリンク先
│   │       └── constants.ts
│   ├── shims-tsx.d.ts
│   ├── shims-vue.d.ts
│   └── views
├── tsconfig.json
└── yarn.lock


Docker化

Docker化にむけて、下記の要件があります.


プロジェクト直下のfirebase関連ファイル(firebase.json, .firebaserc)を、./functions側でも参照したい
./functions側からプロジェクト直下の定数やtypeをシンボリックリンクで参照する場合がある


上記を念頭に、Dockerfile/docker-compose.ymlを作成します.

プロジェクト直下のDockerfile


こちらは特に考えることはありません


FROM node:12-alpine

ENV WORKDIR /work
WORKDIR $WORKDIR

COPY package.json $WORKDIR
RUN yarn

COPY tsconfig.json $WORKDIR
COPY *.config.js $WORKDIR/
COPY public $WORKDIR/
COPY src $WORKDIR/src

EXPOSE 8080
CMD yarn serve


./functionsのDockerfile

./functions/Dockerfileと、./docker-comose.ymlを比較しながらご確認ください.


WORKDIRを/work/functionsとする
./functions直下のファイルCOPYは、コピー元をプロジェクト直下からの相対パスで指定する
プロジェクト直下のファイルCOPYは、コンテナの/work配下に設置する


FROM node:8-alpine

ENV WORKDIR /work/functions
WORKDIR $WORKDIR

COPY ./functions/package.json $WORKDIR
RUN yarn
# firebase
RUN yarn global add firebase-tools

COPY ./functions/tsconfig.json $WORKDIR
COPY ./functions/lib $WORKDIR/lib
COPY ./functions/src $WORKDIR/src
# # for symbolic link (./functions/src/services/project-name)
# COPY ./src/services/project-name /work/src/services/project-name

# firebase
COPY firebase.json /work
COPY .firebaserc /work
# COPY ./functions/.runtimeconfig.json $WORKDIR # if needed
# COPY ./functions/credentials $WORKDIR/credentials # if needed

# settings for runtime emulator
ENV HOST 0.0.0.0
EXPOSE 5000

EXPOSE 9005


プロジェクト直下のdocker-compose.yml


上記Cloud FunctionsのDockerfileにあわせるためbuild:のcontext, dockerfileを別に指定する
symbolic linkされている(プロジェクト直下にある)実体ファイルの変更もfunctions側のdockerに反映させるため、./src:/work/srcを追加


version: '3'

services:
    main:
        build: .
        container_name: front
        volumes:
            - ./public:/work/public
            - ./src:/work/src
        ports:
            - 8080:8080
        tty: true
        command: yarn serve

    functions:
        build:
            context: ./
            dockerfile: ./functions/Dockerfile
        container_name: functions
        volumes:
            - ./functions/lib:/work/functions/lib
            - ./functions/src:/work/functions/src
            - ./src:/work/src # for symbolic link
        # environment:
        #    - GOOGLE_APPLICATION_CREDENTIALS=./credentials/firebase-adminsdk.json
        ports:
            - 5000:5000
            - 9005:9005
        tty: true


開発の場合

開発環境立ち上げます

$ docker-compose build && docker-compose up


その後の開発は下記のようにすすめます

front

http://localhost:8080にVue.jsプロジェクトがホットリロードされます

Cloud Functions

こちらは多少面倒ではあります


dockerコンテナに入る
firebase loginしていなければfirebase loginを実施
firebase serveやfirebase functions:shellなどでdebugging


以下 docker exec functions -it sh してコンテナ内で

$ firebase login # if you are not logged in.
$ firebase serve
$ firebase functions:shell


Cloud Functionsのデバッグについてはまだペインが多いです..


関数をインタラクティブにテストする(Firebase official)


firebase loginの認証情報を永続化(都度fireabase loginしたくない)人は下記のサイトが参考になるかもしれません(試していません..)


[Firebase] Cloud Functionsで消耗したくない人のために、開発環境のベストプラクティスをまとめていったらDockerに行き着いた話


deploy


github actions/ circleCIなど利用したほうがよいでしょう.


おわりに

少し強引な形となってしまいましたが、Dockerの恩恵をうけることができる状態までできました.

ただし、./functions/Dockerfileのフォルダのコンテキストが親階層直下にある点に気持ち悪さがあります.

ここの気持ちわるさの解消は今後の課題とします.


MQTTを使ってみよう
2019-11-21T23:48:51+09:00
MQTT(MQ Telemetry Transport)とは？


wikipedia


通信プロトコルの一種でPub/Sub型のデータ配信モデル。

軽量プロトコルのため、主にIoTの分野で使われていることが多いです。

Pub/Sub型

Pub/Sub型に関わるのは次の3者。


Publisher メッセージを出す人
Subscriber メッセージを読む人
Broker 配送業者(中継サーバ)


履歴の残らないLINE、という感じでしょうか。

中継サーバを立ててみよう

eclipse-mosquittoというMQTTサーバのdockerイメージが配布されています。

今回はホストの1883番ポートにmosquittoサーバを公開します。

さらにリバースプロキシの後ろに配置するため、nginxと同じnetwork(ここではdefault)に接続します。

docker-compose.yml(抜粋)

  mosquitto:
    image: eclipse-mosquitto
    hostname: mosquitto
    container_name: mosquitto
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf
    networks: 
      - default


moquitto.conf(一部)

# ========================================================
# Default listener
# ========================================================
# Port to use for the default listener.
port 1883
# Choose the protocol to use when listening.
protocol websockets
# listener port-number [ip address/host name]
listener 9001


nginx.conf(listen 443)

 location /mqtt {
            proxy_pass  http://mosquitto:1883/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
  }


クライアント(react)側実装

import PahoMQTT from "paho-mqtt";
const uuidv4 = require('uuid/v4');

//wssを利用する
const client = new PahoMQTT.Client(
    '******',443,uuidv4()
 );

 export const connect=()=>{    
    client.connect({
      userName: "******",
      password: "********",
      useSSL: true,
      onSuccess,
      onFailure
    });
    client.onMessageArrived = onMessageArrived;
    client.onConnectionLost = onConnectionLost;
}

const onSuccess=()=>{
    client.subscribe(TOPIC);
}
const onFailure=()=>{
    console.log('connect failed.')
}

export const onMessageArrived=(message)=>{
    console.log(message.payloadString);
}

export const send=(message)=>{
    client.send(TOPIC, message, 0, false);
}

function onConnectionLost(responseObject) {
    if (responseObject.errorCode !== 0) {
      connect();
    }
  }



アドベントカレンダー


crieitアドベントカレンダー「なんでも」


2日目に登板予定です。

MQTTを基礎技術に使ったアプリを作る予定です。


DockerでLaravelのローカル開発環境構築を行う
2019-09-17T08:33:54+09:00
Laravelの環境構築を行う場合はDockerを利用するのが個人的には一番早くて軽くて良いと思っています。普段はDocker Hubにアップしてある自分で作ったオレオレDockerイメージを利用しているのですが、久しぶりに丁度よいLaravel用のDockerイメージが無いのかなと見直してみて、ちょうど良さそうなものがあったのでそちらを使って環境構築を試してみました。（最近作ったばかりなので十分な確認はできていません）

今回使うDockerイメージ

今回使うDockerイメージは下記です。

https://hub.docker.com/r/lorisleiva/laravel-docker/

READMEに詳しい使い方が載っていないのですが、pull数も多いし（CIで主に使っているのかもしれません）GitHubでの評価も他のイメージに比べて高いので、良さそうかなと思いました。XDebugもYarnも入っているようですので、このイメージ一つで一通りのことはできそうな気がします。

構築する環境

下記の環境で構築します。


PHP 7.3
Laravel 6.0
MySQL 5.7
phpMyAdmin
Yarn


docker-compose.ymlをつくる

実際の開発時にはdocker-composeを利用するため、まずはdocker-compose.ymlを書きます。これはプロジェクト初期化ようですので、あとでまた調整します。

version: '2'
volumes:
  db_data:
    driver: local
services:
  mysql:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "true"
      MYSQL_DATABASE: laravel
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mysql
      - PMA_USER=root
      - PMA_PASSWORD=
    ports:
      - 8001:80
  app:
    image: lorisleiva/laravel-docker:7.3
    volumes:
      - .:/var/www
    ports:
      - 8000:8000
    tty: true
    stdin_open: true
    # command: php artisan serve --host=0.0.0.0


MySQL

MySQLはパスワード無しをOKとします。ローカル環境ですのでパスワードなしのrootログインで問題ありません。データベースとしてlaravelを自動的に作成します。現在はLaravelのプロジェクトを作成すると、.envにはlaravelというデータベースを使用するように初期化されるようです。

phpMyAdmin

ソフトを使ってMySQLに接続することも可能ですが、phpMyAdminのDockerイメージも存在するためそれを使います。これでhttp://localhost:8001でphpMyAdminを使うことが出来てとても楽です。

アプリケーションを作成する

とりあえず先程のdocker-compose.ymlを配置し、そこにシェルで移動します。そして各イメージを起動します。

docker-compose up -d


docker psで正常に起動できているかを確認することも出来ます。

次にdocker-compose.ymlで定義しているappというLaravelが動作するコンテナに入ります。

docker-compose exec app bash


php -vとするとPHP7.3のバージョンが表示されると思います。ここにLaravelの公式マニュアルに従ってLaravelアプリケーションの初期化を行います。

composer create-project --prefer-dist laravel/laravel blog


blogフォルダにアプリケーションが作成されますので、そのフォルダに移動してアプリケーションを起動してみます。

cd blog
php artisan serve --host=0.0.0.0


下記のようなメッセージが表示されれば問題ありません。

Laravel development server started: 
PHP 7.3.8 Development Server started at Wed Sep 11 23:57:18 2019


問題なければhttp://localhost:8000にアクセスすると下記のような画面が表示されます。



普段利用する用に調整

とりあえず環境構築は出来ましたが、普段の利用にはちょっと使いづらいので調整します。まずは一旦コンテナを終了させます。Ctrl+Dのショートカットかexitコマンドでコンテナのシェルを抜けます。そして下記を実行して終了させます。

docker-compose down


そしてdocker-compose.ymlを先程作成されたblogフォルダに入れてしまいましょう。配置が気持ち悪ければその後blogフォルダの名前を変えたり位置を変えたりしてください。次にdocker-compose.ymlのappのセクションに下記の行を追加します。

    command: php artisan serve --host=0.0.0.0


これでdocker-composeでupした際に自動的にサーバーも起動し、わざわざコマンドで起動しなくてもブラウザでLaravelアプリケーションにアクセスできるようになります。

これで普段は開発を始める時にup、終了する時にdownを行うだけでOKとなります。

その他細かい部分も確認

とりあえず動いたので他の細かい部分も確認していきます。すべてdocker-compose exec app bashでコンテナ内に入って実行します。

MySQLとの連携

MySQLと正常に連携できているか確認してみます。今回の方法で作成したLaravelアプリケーションには元々ユーザー関連のテーブルを初期化するためのマイグレーションファイルが入っていますので、それを実行してみます。

まずは.envのホスト名だけ変更しておきます。

DB_HOST=mysql


そして実行します。

php artisan migrate


問題なければ下記のように実行ログが表示されます。

Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.07 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.05 seconds)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (0.03 seconds)


ルーティングの確認

正常にルーティングが行われているか確認します。まずは適当なコントローラを作成します。

php artisan make:controller PostController


これでapp/Http/Controller/PostController.phpが生成されますので、下記のメソッドを追加しておきます。アクセスするとJSONのレスポンスを返すだけのアクションです。

    public function index()
    {
        return response()->json(['hello' => 'world']);
    }


これにアクセスできるように、ルーティングを追加します。routes/web.phpに下記を追記します。

Route::resource('posts', 'PostController');


これでhttp://localhost:8000/postsにアクセスすれば下記のようなページが表示されます。

{"hello":"world"}


Vue.jsの確認

Laravel6からデフォルトではVue.jsが入らなくなったようです。ただしuiコマンドですぐ初期化できるようです。詳しくは下記の記事に書いています。

Laravel 6 でVue.jsやReactを使う

hotコマンドを使ってブラウザで確認する際に8080ポートでjsやcssファイルが読み込まれますが、このイメージだとそのままはアクセスできないため、hotコマンドに--host=0.0.0.0というホスト名の指定を追加しておきましょう。

"hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --host=0.0.0.0 --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",


まとめ

自分で作ったオレオレイメージをbuildせずともなんとなくいい感じにできた気がします。今回使ったイメージがメンテナンスされると嬉しいですね。Dockerが使える方は是非試してみてください。


google-home-voicetextのdockerfileを改良する
2019-08-24T18:40:20+09:00
google-home-voicetextって？


google-home-voicetext
Google Homeを手軽に喋らせる仕組み(google-home-voicetext)を作った


google homeを自発的に話すようにできるgoogle-home-notifierの改良版。


google-home-voicetext-docker


作者の方がdockerfileも用意してくださっているのですが、

docker-composeで立ち上げた後、コンテナにログインして環境構築をする必要があり、しょっちゅうコンテナを作り直す私にとっては使い辛かったので何とか作業を簡略/最適化できないかと思ったのが今回の趣旨です。

自発的にしゃべらせる

alexa vs google home

alexaはリマインダーAPIにプログラムを組んで登録するのが楽なのですが、


alexaに話しかける
画面からOAuth認証を行う


などのユーザーアクションを起こさないと、APIアクセスに必要なトークンが払い出されないことがわかり、今回は実装を断念。

その点、google homeはchromecastに用いられているライブラリを使って音声のキャストなどを行うことができるため、比較的実装が容易ということがわかりました。

ただ、機能によってはalexaの方が優れている面もあり、一長一短というところです。

dockerfileの修正

FROM node:10.16

RUN npm update -y -g npm
RUN apt-get update
RUN apt-get install -y vim avahi-daemon libavahi-compat-libdnssd-dev locales
RUN locale-gen ja_JP.UTF-8
RUN echo "export LANG=ja_JP.UTF-8" >> ~/.bashrc

#RUN mkdir /myapps
#RUN cd myapps
#WORKDIR /myapps
RUN git clone https://github.com/sikkimtemi/google-home-voicetext.git
#RUN cd google-home-voicetext/
WORKDIR google-home-voicetext
RUN npm install
#RUN npm install forever -g
RUN patch -uR node_modules/mdns/lib/browser.js < mdns_patch/browser.js.patch
#RUN service dbus start
#RUN service avahi-daemon start
#VOLUME [ "/myapps" ]

#CMD node file-server.js & node api-server.js


あえてコメントアウトしたところも残していますが、READMEと比べながら照合していただけるとよいと思います。


コンテナの中でgit cloneします。
cloneしたフォルダに移動してnpmインストール
npm インストール後にcloneしたソースに含まれるパッチをあてます。
環境変数の設定はcompose側で行います。
mdns関連のサービスの起動もcompose側のコマンドで設定します。


docker-compose.ymlの記述

node-google-home:
    build: './speaker'
    #container_name: 'node'
    command: >
      sh -c "service dbus start &&
      service avahi-daemon start &&
      node file-server.js & 
      node api-server.js "
    working_dir: '/google-home-voicetext'
    volumes:
      - ./myapps:/myapps
    ports:
      - '8080:8080'
      - '8888:8888'
    environment:
      - TZ=Japan
      - VOICETEXT_API_KEY=*****
      - WIRELESS_IP=192.168.***.***
      - GOOGLE_HOME_IP=192.168.***.***
      - WIRELESS_MODULE_NAME=en0
      - VOICETEXT_SPEAKER=HARUKA
    tty: true
    restart: always


compose側では、mdns関連のサービスの起動とサーバプロセスの起動を行っています。

foreverをインストールして、プロセスの維持をしようと思ったのですが、何回かmdnsサービスが立ち上がらない時があり、その場合はプロセスの再起動というよりはコンテナを破棄して再度コンテナを立上げるのが良いと判断しました。

おわりに

今回の改良ではdockerfileへの理解が十分でないというのもあり、

(使っていないのですが)ボリュームのマウントがうまくいっていないという問題点も...。

「docker-compose」の記事 - Crieit

Docker Compose で条件に応じてマウントするボリュームを切り替える

Docker Compose で使用する環境変数にデフォルト値を設定する

Docker Compose に渡す環境変数ファイルを変更する

Docker 上の Almalinux のタイムゾーン設定について

Docker で MySQL の community版をインストールしようとした際に Failing package is: ... エラー

CentOS の bash で比較演算と三項演算子的な処理を使って変数に代入する値を分岐するワンライナー

Dockerfile 内でコンテナの時刻を変数として流用し、年に対応した rpmパッケージ の GPG署名 をインストールする

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

awk で条件に合致する最後の行のみ処理する

Dockerコンテナ に SSHログイン できるようにする(パスワード方式)

Docker の phpMyAdmin公式イメージ でメモリ上限等を増やす (Docker Compose 使用)

Docker から MySQL 用のコンテナで初期化・起動しようとしたら The server option 'lower_case_table_names' is configured ... エラーで失敗する

Github で特定ユーザの publicリポジトリ の名前の一覧を生成する Docker Compose

Docker で Node.js のバージョン切替環境を構築する

Docker で PHP + SQLite3 の開発環境を構築する

無認証 SMB を samba で秒で立ち上げる Dockerfile (& docker-compose)

Dockerfile 内でコンテナの時刻を変数として流用し、年に対応した rpmパッケージの GPG署名をインストールする

Dockerコンテナに SSHログインできるようにする(パスワード方式)

Docker の phpMyAdmin公式イメージでメモリ上限等を増やす (Docker Compose 使用)

Github で特定ユーザの publicリポジトリの名前の一覧を生成する Docker Compose