まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:wordpress

IBM Cloud から提供されている 30 日間無料 Kubernetes サービスIBM Kubernetes Service 、以下 "IKS")環境を使って利用することのできるコンテナイメージを1日に1個ずつ 30 日間連続で紹介していきます。

環境のセットアップや制約事項については Day0 のこちらの記事を参照してください。

Day 25 からはアプリケーション系コンテナとその GUI ツールを中心に紹介してます。最終日である Day 30 は集大成として世の中の大半のウェブコンテンツを管理していると思われる WordPress イメージをデプロイする例を紹介します。
wp0


【イメージの概要】
ブログなどのウェブコンテンツを管理・編集・公開するシステムです。

個人的にも WordPress には思い入れがあります。業務とは関係のないところで WordPress を知って、勉強して、そこから自分のキャリアが変わるきっかけにもなりました。今の自分が今の立場でいるのは WordPress との関わりがあったからだと思っています。そんな背景もあって 30 日間連続ブログの最終日に紹介するコンテンツとさせていただきました。

WordPress の動作時にはデータベースが必要なのですが、今回は MySQL を使う方法を紹介します。MySQL 単体のデプロイについては Day 6 でも紹介しているので、必要に応じて参照してください。


【イメージのデプロイ】
まずはこれら2つのファイルを自分の PC にダウンロードしてください:
https://raw.githubusercontent.com/dotnsf/yamls_for_iks/main/mysql.yaml
https://raw.githubusercontent.com/dotnsf/yamls_for_iks/main/wordpress.yaml

前者が MySQL 用、後者が WordPress 用のデプロイファイルです(両方使います)。
前者の MySQL 用デプロイファイルは Day 6 で行ったものと同様の編集が必要です。mysql.yaml ファイルをテキストエディタで開いて、 "MYSQL_" で始まる4箇所の env.name の value 値を変更してください。それぞれの具体的な意味は以下の通りです(初期値として指定されている値のまま動かすことも可能ですが、安全のためなるべく変更してください):
・MYSQL_ROOT_PASSWORD : 管理者パスワード(初期値 P@ssw0rd)
・MYSQL_DATABASE : デプロイと同時に作成するデータベースの名前(初期値 mydb)
・MYSQL_USER : デプロイと同時に作成するデータベースを利用するユーザー名(初期値 user1)
・MYSQL_PASSWORD : デプロイと同時に作成するデータベースを利用するパスワード(初期値 password1)

また後者の WordPress 用デプロイファイルには4箇所の変種が必要です。wordpress.yaml ファイルをテキストエディタで開いて、 "WORDPRESS_" で始まる4箇所の env.name の value 値を変更してください。それぞれの具体的な意味は以下の通りです。特に WORDPRESS_DB_HOST の値は後述する IP アドレスと上述の MySQL に設定した値を両方参照して入力する必要がある点に注意ください:
・WORDPRESS_DB_HOST : MySQL のホスト名とポート番号(初期値 xxx.xxx.xxx.xxx:30306)
・WORDPRESS_DB_USER : MySQL に接続するユーザー名(初期値 user1)
・WORDPRESS_DB_PASSWORD : MySQL に接続するパスワード(初期値 password1)
・WORDPRESS_DB_NAME : MySQL の DB 名(初期値 mydb)

ではこのダウンロード&編集した2つの yaml ファイルを指定してデプロイします。以下のコマンドを実行する前に Day 0 の内容を参照して ibmcloud CLI ツールで IBM Cloud にログインし、クラスタに接続するまでを済ませておいてください。

そして以下のコマンドを実行します:
$ kubectl apply -f mysql.yaml

$ kubectl apply -f wordpress.yaml

以下のコマンドで MySQL 関連の Deployment, Service, Pod, Replicaset が1つずつ生成されたことと、サービスが 30306 番ポートで公開されていること、そして WordPress 関連も同様に Deployment, Service, Pod, Replicaset が1つずつ生成され、サービスが 30080 番ポートで公開されていることを確認します:
$ kubectl get all

NAME                            READY   STATUS    RESTARTS   AGE
pod/mysql-5bd77967b-z9lcl       1/1     Running   0          104s
pod/wordpress-67848cd6b-296kh   1/1     Running   0          62s

NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/kubernetes    ClusterIP   172.21.0.1       <none>        443/TCP          27d
service/mysqlserver   NodePort    172.21.89.71     <none>        3306:30306/TCP   105s
service/wordpress     NodePort    172.21.140.192   <none>        80:30080/TCP     63s

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mysql       1/1     1            1           106s
deployment.apps/wordpress   1/1     1            1           64s

NAME                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/mysql-5bd77967b       1         1         1       106s
replicaset.apps/wordpress-67848cd6b   1         1         1       64s

この後に実際にサービスを利用するため、以下のコマンドでワーカーノードのパブリック IP アドレスを確認します(以下の例であれば 161.51.204.190):
$ ibmcloud ks worker ls --cluster=mycluster-free
OK
ID                                                       パブリック IP    プライベート IP   フレーバー   状態     状況    ゾーン   バージョン
kube-c3biujbf074rs3rl76t0-myclusterfr-default-000000df   169.51.204.190   10.144.185.144    free         normal   Ready   mil01    1.20.7_1543*

つまりこの時点で(上述の結果であれば)アプリケーションは http://169.51.204.190:30080/ で稼働している、ということになります。ウェブブラウザを使って、アプリケーションの URL(上述の方法で確認した URL)にアクセスしてみます:
wp1


WordPress をインストールしたことがある人にはお馴染みの初期セットアップ画面が表示されます。とりあえず無事に IKS 内で WordPress が稼働できているようです。

Drupal の時とは異なり、データベース接続情報などはデプロイ時に既に指定しているので、サイトの情報を入力するだけで使えるようになります:
wp2


セットアップが無事に成功しました。あとはセットアップ時に指定したユーザー&パスワードでログインすれば管理画面にアクセスできるようになります:
wp3


WordPress のコンテンツ管理画面にアクセスできました。IKS 内で WordPress を起動できました:
wp4


 Drupal の時と同様ですが、コンテンツフォルダを共有していないので、インスタンス数を2以上に増やして使うことはできませんが、とりあえず WordPress が動く環境を作ることができました。


【YAML ファイルの解説】
WordPress の YAML ファイルはこちらを使っています(MySQL の YAML ファイルについては Day 6 参照):
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  selector:
    app: wordpress
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 30080
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wordpress
        image: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: "xxx.xxx.xxx.xxx:30306"
        - name: WORDPRESS_DB_USER
          value: "user1"
        - name: WORDPRESS_DB_PASSWORD
          value: "password1"
        - name: WORDPRESS_DB_NAME
          value: "mydb"
        ports:
        - containerPort: 80

Deployment 1つと、Service 1つ、環境変数の指定も不要で本シリーズで紹介する 30 個の中でも指折りにシンプルな YAML ファイルです。一応解説を加えておきます。アプリケーションそのものは 80 番ポートで動作するように作られているため、NodePort 30080 番を指定して、外部からは 30080 番ポートでアクセスできるようにしています(NodePort として指定可能な番号の範囲は 30000 ~ 32767 です、指定しない場合は空いている番号がランダムに割り振られます)。また ReplicaSet は1つだけで作りました。


デプロイしたコンテナイメージを削除する場合はデプロイ時に使った YAML ファイルを再度使って、以下のコマンドを実行します。不要であれば削除しておきましょう:
$ kubectl delete -f wordpress.yaml

$ kubectl delete -f mysql.yaml


【紹介したイメージ】
https://hub.docker.com/_/wordpress


【紹介記録】
ついに 30 日間 30 イメージ紹介を達成しました!

Dayカテゴリーデプロイ内容
0準備準備作業
1ウェブサーバーhostname
2Apache HTTP
3Nginx
4Tomcat
5Websphere Liberty
6データベースMySQL
7phpMyAdmin
8PostgreSQL
9pgAdmin4
10MongoDB
11Mongo-Express
12Redis
13RedisCommander
14ElasticSearch
15Kibana
16CouchDB
17CouchBase
18HATOYA
19プログラミングNode-RED
20Scratch
21Eclipse Orion
22Swagger Editor
23R Studio
24Jenkins
25アプリケーションFX
262048
27DOS Box
28VNC Server(Lubuntu)
29Drupal
30WordPress

docker を使って複数の WordPress 環境を立ち上げる手順をスクリプト化してみました。

普通に1つの WordPress 環境を作るだけであれば(特に docker-compose を使えば、yaml ファイルを1つ用意するだけで)簡単に作れます。詳しくはここでは紹介しませんが、"docker WordPress" などでググると多くの紹介ページが見つかります。

ただ今回自分が作りたかった環境はこれらとは少し異なり、1つのホスト内に複数の独立した WordPress 環境を作る、というものでした。具体的には MySQL サーバーは1つだけ用意した上で、ポート番号で分離して1つ目の環境は localhost:8081 で、2つ目の環境は localhost:8082 で、・・・といった具合に、それも簡単に後から WordPress 環境を追加/削除できるよう考慮してスクリプト化して公開しました:
https://github.com/dotnsf/docker-wordpress

2021030700


※ここで方法で作成した WordPress 環境を実際にインターネットに公開する場合は DNS と連動したポートフォワーディングができる環境があれば、全ての WordPress 環境に 80 番ポート(http)や 443 番ポート(https)でアクセスできるようになると思っています。が、そちらについては環境依存になるので本ブログでは触れません。


利用方法については README.md で紹介していますが、一応ここでも説明します:

まず前提条件として docker が導入された環境が必要です(docker-compose は使わないので導入する必要はありません)。また用意したシェルスクリプトは Linux などの bash などで動かすことを想定しています。ただ docker コマンドが使える環境下であれば、(例えば Windows であれば、シェルスクリプトファイルの拡張子を .sh から .bat などに変更するだけで)使えるはずです。 なお、以下の内容については Windows10 の WSL2(Ubuntu 18.04) 環境で動作を確認しています。


docker 導入済みのシステムで docker を起動後、最初に MySQL イメージと WordPress イメージをダウンロードしておきます。実際には後述のシェルスクリプト実行時にダウンロードされていないと判断されれば docker が自動で最新イメージをダウンロードした上で実行してくれるので、この手順は必須ではありません。ただ最初に1回実行しておくことで後述のスクリプトが軽快に動くようになるので特に理由がなければこのタイミングでダウンロードしておくことを推奨します:
$ docker pull mysql

$ docker pull wordpress

次に今回の作業用に用意したシェルスクリプトをダウンロードして、実行可能な状態に設定します:
$ git clone https://github.com/dotnsf/docker-wordpress

$ cd docker-wordpress

(UNIX 環境の場合)
$ chmod 755 *.sh

(Windows 環境の場合 以下、拡張子を .sh から .bat に変更して実行)
> ren *.sh *.bat

まず docker 環境でデータベースである MySQL サーバーを起動します(以下のコマンドで 3306 番ポートで MySQL サーバーが起動します):
$ ./docker_run_mysql.sh

なお、この MySQL コンテナに接続してコンテナの中身を確認する場合は、以下のコマンドでターミナルにアタッチ可能です(exit で元のホストに戻ります):
$ docker exec -it mysql /bin/bash

そして docker 環境内に WordPress サーバーを起動します。この際に「何番目の WordPress 環境か」を意味するインデックス番号をパラメータとして指定します(以下の例では 1 を指定しています):
$ ./docker_run_wordpress.sh 1

このコマンドが成功すると、8081 番ポートで wordpress1 という名前の docker コンテナが起動します。ウェブブラウザで http://localhost:8081/ にアクセスすると、WordPress の初期設定画面に遷移して、サイト名やログイン設定などを指定して利用を開始できます:

2021030701


2021030702


2021030703


2021030704


2021030705


2021030706


とりあえず1つ目の WordPress 環境はこれだけで作れました。次の環境を作ることもできますが、この1つ目の WordPress 環境に関する操作を一通り説明しておきます。

この WordPress コンテナに接続してコンテナの中身を確認する場合は、以下のコマンドでターミナルにアタッチ可能です(exit で元のホストに戻ります):
$ docker exec -it wordpress1 /bin/bash

コンテナを停止する場合は以下のコマンドを実行します:
$ docker stop wordpress1

停止したコンテナを再起動する場合は以下のコマンドを実行します:
$ docker start wordpress1

停止したコンテナを削除する場合は以下のコマンドを実行します(コンテナを削除し、MySQL データベースも drop してデータごと削除します):
$ ./docker_rm_wordpress.sh 1


では1つ目の WordPress 環境を起動したまま、2つ目の WordPress を追加で起動してみます。以下のコマンドを実行します:
$ ./docker_run_wordpress.sh 2

このコマンドが成功すると、8082 番ポートで wordpress2 という名前の新しい docker コンテナが起動します。ウェブブラウザで http://localhost:8082/ にアクセスすると、新しい WordPress の初期設定画面に遷移し、同様にサイト名やログイン設定などを指定して利用を開始できます(それぞれが独立した環境なので起動済みの WordPress1 側には変化や影響はありません):

2021030707


2021030708


2021030709


wordpress2 のコンテナについても wordpress1 環境同様に docker コマンドで操作可能です。

後は必要なだけこの操作を繰り返すことで、WordPress 環境をコマンド1回ずつ追加していくことができます。ポート番号が利用中でなければ、おそらく好きなだけ起動できるはず(ポート番号が 8081 から始まるルールを変更したい場合は docker_run_wordpress.sh スクリプト内で適当な値に変更してください)。


そこそこのスペックを持った docker 導入済みのサーバーが1台インターネット上にあれば、DNS やポートフォワーディングなどと組み合わせることで複数の WordPress 環境を好きなタイミングで好きなだけ簡単に構築することができるようになると思っています。docker 環境なのでコンテナごと消してしまえば元のホスト環境を汚すこともなく元に戻せます(開発環境だと大事!)。

なお Github 上に公開したシェルスクリプトはそのまま利用することができますが、特にインターネットに公開する WordPress の場合、セキュリティの観点からパスワード類は変更してから利用することを推奨します。その場合は以下の部分を(すべて同じ文字列に)変更してください:
(docker_run_mysql.sh ファイル内)
- docker コマンド実行時の環境変数 MYSQL_ROOT_PASSWORD の値

(docker_run_wordpress.sh ファイル内)
- docker コマンド実行時の環境変数 WORDPRESS_DB_PASSWORD の値

(docker_rm_wordpress.sh ファイル内)
- docker コマンド実行時のパラメータ -p に続いて指定されている文字列

CentOS 7 で運用する独自ドメインのウェブサーバーを Certbot(Let's encrypt) で無料の証明書を取得して SSL 化しました。その手順の備忘録です:
le-logo-standard



【環境】
OS: CentOS 7.6(64bit)
HTTP: Apache HTTPD 2.4.6※

※正確には WordPress 5.2.2(ja) を MariaDB 5.5.60 で運用中。Apache と MariaDB は yum で導入、WordPress は公式サイトから最新版 latest-ja.tar.gz を取得して展開

Document Root: /var/www/html/wordpress
ドメイン名(仮): mydomain.com (DNS 設定済み)

1サーバーで1ドメイン運用、のシンプルなケースを想定しています。http では既に稼働中、という状態だと思ってください。


【準備】

Certbot のインストール
$ sudo yum install -y epel-release
$ sudo yum install -y certbot python-certbot-apache

root で動作確認
$ sudo -i
# certbot --version
certbot 0.36.0

certbot コマンドを実行し、バージョン番号が表示される(=インストールされている)ことを確認します。

【作業】

以下のコマンドを実行するにあたり、証明書を導入するサーバーに HTTP(TCP/80) および HTTPS(TCP/443) でパブリック・アクセスできるようにポート設定できているものとします。またDocument Root に Basic 認証などがかかっている場合は外しておきます(必須)。

証明書作成
# certbot certonly --webroot -w /var/www/html/wordpress -d mydomain.com

-w オプションで DocumentRoot、-d オプションでドメイン名を指定します。E メールアドレスの入力を求められるので自分のメールアドレスを入力して Enter 、そして利用規約に A(Agree) を押して、最後に N(No) を押します:
# certbot certonly --webroot -w /var/www/html/wordpress -d mydomain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): myname@xxx.co.jp
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

処理が成功すると以下のような "Conguratulations!" というメッセージが表示されます:
2019082900


ここまで完了していると、以下の4ファイルが作成されているはずです(mydomain.com 部分には指定したドメイン名が入ります):
  1. /etc/letsencrypt/live/mydomain.com/cert.pem (サーバー証明書(公開鍵))
  2. /etc/letsencrypt/live/mydomain.com/chain.pem (中間証明書)
  3. /etc/letsencrypt/live/mydomain.com/fullchain.pem (サーバー証明書と中間署名書の結合ファイル 今回は使いません
  4. /etc/letsencrypt/live/mydomain.com/privkey.pem (秘密鍵)

証明書を有効にする

/etc/httpd/conf.d/ssl.conf ファイルの以下3箇所を書き換えて&コメントを外すなどして有効にします:
  • SSLCertificateFile /etc/letsencrypt/live/mydomain.com/cert.pem
  • SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem
  • SSLCertificateChainFile /etc/letsencrypt/live/mydomain.com/chain.pem
  • (fullchain.pem は使わない)

また、Basic 認証をかける場合はこのタイミングで元に戻して(有効にして)おきます。

HTTP サーバーを再起動
# systemctl restart httpd


以上です。僕が以前にウェブサーバーやそのアプリケーションを大量に作る仕事していた頃は無料で証明書作ってもらえるサービスはなくて、いわゆる「オレオレ証明書」に頼っていたのでした。改めていい時代になりました。


自分を含め、多くの人に使われているコンテンツ管理システムである WordPress の(プラグインの)日本語翻訳に参加させていただきました。

WordPress は本体だけでなく各種プラグインも含めてオンラインで翻訳に参加する仕組みが整っており、誰でも比較的容易に参加できると感じました。以下で実際の翻訳を行った様子を紹介しますが、ぜひ色んな人に参加していただきたいと思っています。

(1)準備
WordPress の翻訳に参加するために必要なものは WordPress.org アカウントです。こちらからログインして翻訳を開始します。まだアカウントを所有していない場合は新規に作成してからログインして進めてください:
https://login.wordpress.org/

2019081601


(2)翻訳する対象言語と対象プロジェクトの選択
上記アカウントで WordPress.org にログイン後、以下の翻訳サイトへ移動します:
https://translate.wordpress.org/

2019081602
(↑正しくログインしていると、右上に自分のプロフィールが表示されます)


まずは翻訳対象言語を選びます(今回は「日本語」として以下を紹介しますが、他の言語に翻訳する場合はその言語を選んでください)。画面を下の方にスクロールして "Japanese" の "Contribute Translation" ボタンをクリックします:
2019081603


次に選択した言語(日本語)で、何の翻訳に参加するか、を選びます。最初は WordPress 本体の翻訳参加用ページが WordPress のバージョン別に表示されています。が、実際に見ていただくとわかるのですが、WordPress 本体の翻訳は Progress がほぼ 100% となっていて「既に翻訳済み」となっていると思います。なのでこちらへの参加はできません:
2019081604


翻訳は WordPress 本体だけではなく、各種テーマやプラグインに対しても行うことができます。例えば "Plugins" を選択すると選択言語(日本語)で翻訳に参加できるプラグインの一覧が表示されます。こちらは Progress = 100% になっていないプラグインがほとんどで、これらのプラグインの翻訳に参加することができます:
2019081605


適当に1つ選んでもよいのですが、せっかくなので普段自分が使ってお世話になっているものから選びたいと思いました。

というわけで、個人的に最近使い始めた "All in One SEO Pack" プラグインの日本語化に貢献させていただこうと思います。検索バーに "All in One SEO" などと入力して検索し、対象のプラグインを見つけたら "Translate Project" ボタンをクリックします(Progress = 91% なので、まだ未翻訳部分が全体の1割弱残っていることになります):
2019081606


選択したプラグインの翻訳プロジェクト一覧が表示されます。このプラグインでは Development(開発)版と Stable(安定)版の2つのプロジェクトに分かれて開発が進められており、かつそれぞれに本体と README の翻訳が用意されているようです。ここから自分が対象とするサブプロジェクトを選ぶのですが、今回は Untranslated (未翻訳箇所)が 69 個と最も多い Stable 版を選ぶことにしました:
2019081607



(3)翻訳作業
翻訳する対象のプロジェクトを選ぶと、そのプロジェクトの文字リソース一覧が表示されます:
2019081601


最初は翻訳済みのものも全て含めた文字リソース一覧が表示されています。未翻訳のものだけが表示されるよう、"Untranslated" をクリックして、未翻訳文字リソース一覧に切り替えます:
2019081602


ここに表示されているものが「All in One SEO Pack プラグインの中でまだ日本語になっていない文字」の一覧です。翻訳に参加するにはどれか1つを選んで "Double click to add" と書かれている部分をダブルクリックします:
2019081603


すると翻訳編集画面に切り替わります。この例では「Search results for "%s"」という文字リソースの日本語翻訳を(まだ存在していないので)指定します:
2019081604


この日本語訳として「"%s" の検索結果」と入力しました。確定する場合は "Suggest" ボタンをクリックします:
2019081605


すると画面内に先程選んだ「Search results for "%s"」の訳として「"%s" の検索結果」が入力されている状態になります。これで選択した文字リソースの翻訳候補を指定できました。簡単ですね。

同時に次の未翻訳リソースである「F j, Y」が選択され、翻訳の入力を待っている状態に切り替わりました:
2019081606


同様にして翻訳を入力して "Suggest" を繰り返していきます。ある程度翻訳した所で、画面内上部の "Japanese" を選択します:
2019081607


すると画面が切り替わり、"Waiting" の数字が変わっているはずです(もとは 0 だったのが 9 になってます)。これは自分が入力した翻訳候補が9つあり、それらが採用される前の段階として waiting(待ち)の状態になっている、ということを示しています(この画面で黄色の背景になっているものが waiting のリソースです):
2019081608


翻訳の作業はこれだけです。後は対象プロジェクトの管理者さんがこの状態から実際のプロジェクトに翻訳を入れるかどうかを判断して、採用された場合は実プロジェクトに反映される、という手続きが待っています。

実際の翻訳には単なる言語知識だけでなく、PHP の文法や日付フォーマットなどの知識が必要になることもありますが、まあわからないものは飛ばして分かるものだけ翻訳に貢献するのがいいと思います。自分の場合はお世話になっているプラグインへのお礼と、あと今後自分が使う中で自分が翻訳した文字列を目にすることがあれば、それはそれで嬉しいと思ったのでボランティアで参加させていただきました。いつかどなたかの役に立つことを願って。



不定期(要するに「ふと思い立ったタイミング」)で LinuxONE の紹介をしています。LinuxONE はメインフレームのハードウェア上で動く Linux です。そういえば LinuxONE で docker って使えるんだろうか?使えるとしたらどのあたりまで使える?? ということを確認したくなって、久しぶりに LinuxONE コミュニティクラウドの環境構築をしてみました。なお、以下の内容は 2019/05/27 時点の状況を紹介したものです。
2019052700


LinuxONE コミュニティクラウドは最大 120 日間無料で利用可能な LinuxONE の環境です。パブリックな IP アドレスが割り振られるので、インターネットから利用することもできます。FAQ も参照ください:
https://developer.ibm.com/linuxone/resources/faq/


LinuxONE コミュニティクラウドの申し込み方法は以前(2017年)のブログエントリで紹介したものとほとんど変わっていません。こちらを参照してください:
http://dotnsf.blog.jp/archives/1063515821.html

ここで記載されている情報と異なる点として、2019/05/27 現在では OS として RHEL 6.x を選択することはできなくなっています。そのため今回は RHEL 7.x を選択しました(RHEL 7.6 が導入されました)。またサーバーのスペック選択肢が廃止され、常に 2CPU + 4GB メモリ + 50 GB ディスク の環境が提供されるようになっていました。

仮想サーバーができたら IP アドレスとサーバー作成時に作ってダウンロードした鍵ファイル(*.pem)を指定して linux1 ユーザーでログインします:
2019052701


ログインできました。実際に試していただくとわかるのですが「ほぼ x86_64 版の RHEL 7.6」です。明示的にアーキテクチャを確認しないと s390x 版であることに気づかないかもしれません。

そしてこの後の docker 環境構築の手順に備えて root ユーザーに切り替えます:
$ sudo -i
#


さて、docker および docker-compose をこの LinuxONE 環境に導入していきます。手順そのものはこちらで紹介されているものをほぼそのまま使うのですが、2019/05/27 現在の環境では記載そのままの手順では途中でエラーになってしまい、導入できませんでした。エラー回避のため、少し異なる手順で導入します(異なる部分をで記載しています)。
https://github.com/IBM/Cloud-Native-Workloads-on-LinuxONE/blob/master/README-ja.md


【docker の導入】
まずインストールする docker の s390x 向けパッケージファイルをダウンロードします。RHEL 7.3 以上向けに docker 17.05 の CE(Community Edition)版が用意されているのでダウンロードします:
# wget ftp://ftp.unicamp.br/pub/linuxpatch/s390x/redhat/rhel7.3/docker-17.05.0-ce-rhel7.3-20170523.tar.gz

ダウンロードしたアーカイブファイルを展開し、バイナリを /usr/local/bin/ 以下にコピーします:
# tar -xzvf docker-17.05.0-ce-rhel7.3-20170523.tar.gz
# cp docker-17.05.0-ce-rhel7.3-20170523/docker* /usr/local/bin/

2019/05/27 時点では標準状態では /usr/local/bin にパスが通っていませんでした。このままだと docker コマンドがそのまま使えないので、パスを通しておきます:
# export PATH=$PATH:/usr/local/bin

これで docker コマンドが使えるようになったので、docker デーモンを起動します:
# docker daemon -g /local/docker/lib &


【docker-compose の導入】
続いて docker-compose もインストールします。実はこちらがドキュメント通りにいかない部分が多く、少し厄介でした。

手順としては pip を使って docker-compose をインストールします。そのため pip を先にインストールするのですが、pip をインストールするための依存ライブラリを先に導入します:
# yum install -y python-setuptools

そして pip をインストールします:
# easy_install pip

インストールした pip を使って、まず backports.ssl_match_hostname をアップグレードするのですが、このコマンドをドキュメント通りに入力すると既に導入済みの環境とのコンフリクトが起こってエラーになってしまいました。というわけで --ignore-installed オプションを付けて実行します:
# pip install backports.ssl_match_hostname --upgrade --ignore-installed

そして pip で docker-compose をインストール・・・するのですが、ここでもドキュメントのまま実行すると依存関係ライブラリが足りないというエラーになってしまいます。そのためまずは依存ライブラリを導入しておきます:
# yum install python-devel
# yum install gcc libffi-devel openssl-devel
# pip install glob2

改めて pip で docker-compose をインストールします。ここでもドキュメントそのままの指定だとエラーになってしまうので、バージョン 1.13.0 を明示してインストールします:
# pip install docker-compose==1.13.0

これで docker および docker-compose が LinuxONE 環境にインストールできました:
# docker -v
Docker version 17.05.0-ce, build 89658be

# docker-compose -v
docker-compose version 1.13.0, build 1719ceb

2019052702


【WordPress の導入】
では導入した docker と docker-compose を使ってコンテンツ管理システムである WordPress を導入してみます。

テキストエディタ(vi とか)を使うなどして、docker-compose.yml というファイルを以下の内容で作成して保存します:
version: '2'

services:

  wordpress:
    image: s390x/wordpress
    ports:
      - 80:80
    environment:
      WORDPRESS_DB_PASSWORD: example

  mysql:
    image: brunswickheads/mariadb-5.5-s390x
    environment:
      MYSQL_ROOT_PASSWORD: example

このファイルは docker-compose 向けの定義ファイルで wordpress と mysql という2つのコンテナ環境を定義しています。wordpress は PHP, Apache HTTPD, および WordPress が含まれる s390x 向けのイメージで 80 番ポートで HTTP リクエストを待ち受けます。また mysql は MySQL(正確には mariaDB)が含まれる s390x 向けイメージです。これら2つのイメージから2コンテナ環境を作り出して WordPress として挙動するようにしています。

では、docker-compose と、この docker-compose.yml ファイルを使って docker コンテナを起動します:
# docker-compose up -d

(必要に応じて)イメージをダウンロードし、イメージからコンテナが作られて起動します。プロンプトが戻ってきたら、docker ps コマンドを実行して wordpress と mariadb の2つのコンテナが起動していることを確認します:
# docker ps
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS                NAMES
65af9dfa6ee9        s390x/wordpress                    "docker-entrypoint..."   3 hours ago         Up 3 hours          0.0.0.0:80->80/tcp   dockers_wordpress_1
3eb78f3ef1c1        brunswickheads/mariadb-5.5-s390x   "/docker-entrypoin..."   3 hours ago         Up 3 hours          3306/tcp             dockers_mysql_1

起動が確認できたらウェブブラウザから(LinuxONE 環境の) IP アドレスを指定してアクセスします(http://xxx.xxx.xxx.xxx/)。以下のような WordPress の環境設定画面になれば成功です:
2019052801


言語やユーザーID、パスワードなどの設定が完了すると管理画面にログインできるようになりました:
2019052802


この時点でユーザーページにもアクセス可能です:
2019052803


とりあえずメインフレーム上の Linux に docker & docker-compose 環境を構築して WordPress を導入することができました!


このページのトップヘ