グレンジ Advent Calendar 2019 5日目の記事を担当しますkitaji_ngzkと申します。
昨年に引き続き、同プロジェクトでPHPを扱うサーバーサイドエンジニアをやってます。
自分が属するプロジェクトには専任のインフラエンジニアがいないため、サーバーサイドエンジニアが兼任する形で担当しています。
ので、必然的にインフラ知識も俄然学ぶ必要があるので、今回個人的に「コンテナ」という技術に触れてみたいと思い、Dockerでローカル環境の構築からクラウドにあげて公開してみるところまで実践した軌跡をご紹介したいと思います。
ここから始めましょう！1から、、いいえゼロから！！
▼今回やってみたこと
Chapter.1 Docker公式のWordPressイメージを用いて、超速構築！
Chapter.2 GCPにMySQLサーバー作成
Chapter.3 Dockerイメージの作成とGCRにアップロード
Chapter.4 GKEのクラスタ作成
Chapter.5 クラスタにデプロイ
▼環境
macOS Mojave10.14.6
Docker for mac 2.1.0.5
Chapter.1 Docker公式のWordPressイメージを用いて、超速構築！
まず手始めにローカル環境でコンテナに触れてみます。
※前提としてDockerがインストールされていることから話を進めます。
公式のWordPress, MySQLのイメージをローカルにpullします。
↓WordPressイメージのタグ一覧
https://hub.docker.com/_/wordpress
pullする時、指定のタグを:つなぎで指定できますが、指定しなければlatestがpullされます。
Wordpressはlatestで問題ないので、以下の通り
$ docker pull wordpress
続けてMySQLもpullしますが、ここで気をつけないといけないのは、MySQLのlatestは8系で認証方法が変わっていて、WordPressの接続エラーという罠が待っているので、バージョンを指定して落としましょう。（8系でも認証方式を昔のものに戻せば、使えるっちゃあ使えます）
↓MySQLイメージのタグ一覧
https://hub.docker.com/_/mysql
8系以外の最新では現時点で5.7系があったのでそれにします。ので、以下の通り
$ docker pull mysql:5.7
さて、両方ちゃんと落とせたか確認します。
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
wordpress latest e4bd752aeb0d 7 days ago 539MB
mysql 5.7 cd3ed0dfff7e 5 weeks ago 437MB
こんな感じで表示されてれば成功。
ではこの二つのイメージをそれぞれ使って、それぞれのコンテナを作成していきます。
まずはMySQLコンテナから
$ docker run --name sample-mysql -e MYSQL_ROOT_PASSWORD=任意のパス -d mysql:5.7
各オプションについてはdocker run --helpとかで調べるか、「docker run オプション」とかで調べましょう。なお、sample-mysqlという部分は任意のコンテナ名です。
（また、ぶっちゃけいちいち先にpullしなくても、このrunコマンドで勝手に持ってきてくれるっちゃあくれます。）
では、無事にコンテナが起動しているか、確認しましょう。
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8703def027e0 mysql:5.7 "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 3306/tcp, 33060/tcp sample-mysql
このように表示されてれば成功です。
それではこのMySQLサーバーにつなげるWordPressコンテナを作成していきます。
$ docker run --name sample-wordpress --link sample-mysql:mysql -d -p 8080:80 wordpress
8703def027e0e9b6cce6409ee01544285836f8cddd4293331fa07b7e1930f56b
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6eca366c2b0c wordpress "docker-entrypoint.s…" 24 seconds ago Up 23 seconds 0.0.0.0:8080->80/tcp sample-wordpress
8703def027e0 mysql:5.7 "docker-entrypoint.s…" 6 minutes ago Up 6 minutes 3306/tcp, 33060/tcp sample-mysql
無事起動したようだ。それでは上記のコマンドにもある通り、ポート8080をあけたので、
http://localhost:8080
にアクセスしてみましょう
このように表示されれば成功です。あとは画面通りに設定項目埋めていけば、WordPressのローカル環境はできあがりです。
ただし、今は/var/www/htmlをホストにマウントしていないので、いじりたいhtmlやphpファイルをエディタでいじいじできないという壁があります。(vim愛好家の方はdocker execでコンテナ内に入れば、用を足せると思います。ただ、このコンテナにはvimを入れてないので、vimをapt-getでインストールする必要があります。)
ではwp-admin画面まで表示されたら、一度以下のコマンドで、ホストの任意のディレクトリにDocker内のファイルをコピーしておきます。
$ docker cp sample-wordpress:/var/www/html ホストPCのディレクトリ
終わったら、ホストPCの任意のディレクトリにコピーされてるか確認しときましょう
$ ls -al コピー先のディレクトリ
でhtml以下のWordPressのファイルがもろもろあればOKです。
ここまできたら、DEDEATHDEATHDE~~~ATH！
作成したWordPressコンテナのみ削除して死に戻り！
$ docker stop sample-wordpress
sample-wordpress
$ docker rm sample-wordpress
sample-wordpress
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8703def027e0 mysql:5.7 "docker-entrypoint.s…" 33 minutes ago Up 33 minutes 3306/tcp, 33060/tcp sample-mysql
戻ってきたら、当然先ほどのlocalhostにアクセスしても、応答がないと思います。ので、WordPressコンテナを作り直します。今度は先ほどコピーしたディレクトリをマウントさせて作ります。
$ docker run --name sample-wordpress-2 -v コピー先の絶対パス:/var/www/html --link sample-mysql:mysql -d -p 8080:80 wordpress
72d97a8374d383e4f366e1adfba3684e6d83aaffef428e23c7849be9abd216be
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
72d97a8374d3 wordpress "docker-entrypoint.s…" 2 seconds ago Up 1 second 0.0.0.0:8080->80/tcp sample-wordpress-2
8703def027e0 mysql:5.7 "docker-entrypoint.s…" 39 minutes ago Up 39 minutes 3306/tcp, 33060/tcp sample-mysql
ここで、先ほど同様localhost:8080にアクセスしてみましょう。
最初に設定した内容そのままに復元できました。
ホストにマウントされているので、これでテーマをインストールしたりしても、ホスト側にも反映されるようになり、ホスト側をgitで管理したりすれば開発が複数人でできるようになると思います。
さて、超速でローカル環境を構築できたものの、この構成をクラウド上でも実現したいと思います。ただ、ローカルではMySQLコンテナを作りましたが、クラウド上ではDBはスケールさせないのでVMインスタンスで十分だと思います。(データの永続化という方法もありますが)
ということで、クラウド（今回はGCP）上にMySQLサーバー作っていきます。
Chapter.2 GCPにMySQLサーバー作成
チャプターにはしてみたものの、あんまりコンテナ関係ないのでさらっといきます
①MySQLコンテナに入ってまるごとdumpfile作成
$ docker exec -it sample-mysql /bin/bash
root@~~# mysqldump -uroot -p -A > sample-wordpress.dump
root@~~# exit
②ホストにコピーしてくる
$ docker cp sample-mysql:/sample-wordpress.dump ./
↑コピー先は./入れてますが、任意のディレクトリで.(ぶっちゃけマウントしてるディレクトリにもともと格納すればホストに落ちてくるという)
③のちのちのためにVPCネットワーク作成
④VMインスタンス作成→MySQL5.7入れる（←ここで入れるMySQLのバージョンはローカルで使ってたやつと一緒にするように）
⑦VMインスタンスに②のdumpファイル転送＆ぶっこみ
これでDockerで作られてるMySQLコンテナの中と同じ構成のサーバーができたはず。
ここまでで、もちろんホストPCからもDBサーバーのMySQLにアクセスできるはずなので、確かめてみます。
$ mysql -h外部IPアドレス -uroot -p
Enter password:ルートパスワード
ERROR 2003 (HY000): Can't connect to MySQL server on '外部IPアドレス' (61)
！？むむ！つながらぬ。。なぜ。。
お試しでローカルからアクセスしてみようと思い、一時的にIPとポート全開放（超非推奨）してましたが、ssh用のポートはtelnetコマンドで確認してみても問題なかったので、おそらくポートは開いているだろう。
また、サーバー自体に繋がってなかったら、エラーがUnkown hostとかになりそうな気もするので、サーバー内のMySQLまでは到達していそう。
となると、MySQLの設定周りが怪しいかもってことで、調べていると以下の情報に行き着きました。
https://gist.github.com/koudaiii/10696132
念の為リンク切れちゃった時用に一部以下抜粋しておきますが、自分が引っかかったのはここでした。
2.my.cnfのbind-address設定
my.confのbind-addressの設定を確認してみる。
$ vi /etc/mysql/my.cnf
bind-address = 127.0.0.1
bind-address = (接続したいマシンのIPアドレス)
追加したい接続先のIPを書いた「bind-address」を追加していけばOK。どのIPからも接続許可する場合はbind-addressをコメントアウトすればOK。
たしかにサーバー内のmy.confの設定内にlocalhostのみ許可のデフォ設定がありました。。（ここにたどり着くまでに自分は4,5回死に戻り(=削除して再作成したり)してます笑）
ので、教えの通りにコメントアウトし、再度ホストPCからtelnetしてみると、接続ができたので、MySQLコマンドを再度叩いてみる。
$ mysql -h外部IPアドレス -uroot -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.28 MySQL Community Server (GPL)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
やったーーー！！
ついにローカルからもアクセスできるようになりました。
WordPressコンテナの/var/www/html配下はホストにマウントしてあると思うので、wp-config.phpを自分の好きなエディタで編集してDB_HOSTの向き先を試しに変更してみます。以下の部分です。
/** MySQL hostname */
define( 'DB_HOST', 'mysql');
↓↓↓
/** MySQL hostname */
define( 'DB_HOST', '外部IPアドレス');
これで
http://localhost:8080
にアクセスしてみましょう。
少しローディングが長く感じますが、これでローカルのWordPressコンテナからクラウド上のMySQLサーバーに接続することができました！（無事MySQLをGCPに作れたようだ←これはこれで個人的にできたの嬉しい笑）
ただ、注意を一つですが、この時点でMySQLのユーザはこうなってるはずです。
mysql> SELECT user, host FROM mysql.user;
+---------------+-----------+
| user | host |
+---------------+-----------+
| root | % |
| mysql.session | localhost |
| mysql.sys | localhost |
| root | localhost |
+---------------+-----------+
4 rows in set (0.00 sec)
root権限がどんなIPからでも使えちゃう怖い状況なので、しっかり削除
そして、WordPressからアクセスする用のユーザを作成して、WordPressで使用するDBのみ許可する権限を与えておきましょう！→最終的に同じVPNネットワークにする予定なので、プライベートネットワークのみに制限
WordPressで使用するユーザを作成したら、wp-config.phpに反映することを忘れずに！(・・・ていうか、これ最初からやっとけばよかったんじゃね？|ω・`）)
さて、もし同じようにローカルから接続してみた場合は、忘れずにIPとポートを閉めて、wp-config.phpの設定もローカルのmysqlコンテナ向きに戻しておきましょう。
Chapter.3 Dockerイメージの作成とGCRにアップロード
今できているWordPressコンテナをイメージ化する方法としては、コンテナを停止して、docker commitのコマンドを使用するか、DockerFileを作成してイメージをビルドするかなどがあります。
実際にGKEで動作させる際、WordPressのDB_HOSTは先ほど作成したMySQLサーバーを向いて欲しかったりします。となるとローカルコンテナをそっくりそのままイメージ化しても動かないでしょう。
ので、これまでやってきた流れをDockerfileで再現する形でイメージをビルドしてGCRにあげてみたいと思います。
Dockerfileは以下のように作成しました。一番最後に「クラウド用の設定でwp-config.phpを上書き」とありますが、最終的にGKEとMySQLサーバーが同VPCネットワーク内であればプライベートIPで接続できるはずなので、DB_HOSTの向き先をそのように変えてあるファイルを取り込んでいます。
FROM wordpress:latest
LABEL maintainer="kitaji_ngzk"
# vimインストール
RUN ["apt-get", "update"]
RUN ["apt-get", "install", "-y", "vim"]
# ホストのソースコードを取り込む
WORKDIR ローカルのWordPressコンテナをマウントした直上ディレクトリ
ADD /html/ /var/www/html/
# クラウド用の設定でwp-config.phpを上書き
ADD /gcp/wp-config.php /var/www/html/wp-config.php
イメージをビルドします。
$ docker build -t sample-wordpress:1.0.0 .
Sending build context to Docker daemon 52.51MB
Step 1/8 : FROM wordpress:latest
---> e4bd752aeb0d
Step 2/8 : LABEL maintainer="kitaji_ngzk"
---> d34337359340
Step 3/8 : RUN ["apt-get", "update"]
---> 0e10ffbdafc1
Step 4/8 : RUN ["apt-get", "install", "-y", "vim", "net-tools"]
---> 75c64ff2bacc
Step 5/8 : WORKDIR ローカルのWordPressコンテナをマウントした直上ディレクトリ
---> 5d913bf121e2
Step 6/8 : ADD /html/ /var/www/html/
---> b963ce7d1331
Step 7/8 : WORKDIR /var/www/html
---> 9d9e0ebbce17
Step 8/8 : EXPOSE 80
---> d7e54c624845
Successfully built d7e54c624845
Successfully tagged sample-wordpress:1.0.0
成功したようなので、確認します。
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
sample-wordpress 1.0.0 5e28a38a1758 36 minutes ago 591MB
wordpress latest e4bd752aeb0d 2 weeks ago 539MB
mysql 5.7 cd3ed0dfff7e 6 weeks ago 437MB
これでイメージ化できました。では、一応このイメージを使ってコンテナを起動できるかローカルで試してみて(docker run)、同じようにWordPress管理画面が表示されればOKです。
(実際プロジェクトとして開発する時は、ローカルのソースコードじゃなくて、ちゃんとgit管理されたmasterブランチのソースコードをpullしてきて、それをADDするべきかなと思います)
次に、GCRに上げるには、イメージにレジストリ名をタグ付けする必要があるので、以下の通りタグ付けします。
$ docker tag sample-wordpress:v1.0.0 gcr.io/kitaji_sample/sample-wordpress:v1.0.0
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
sample-wordpress v1.0.0 0465bcd14635 11 hours ago 539MB
gcr.io/kitaji_sample/sample-wordpress v1.0.0 0465bcd14635 11 hours ago 539MB
wordpress latest e4bd752aeb0d 2 weeks ago 539MB
mysql 5.7 cd3ed0dfff7e 6 weeks ago 437MB
kitaji_sampleとなっているところはGCPのプロジェクト名です。続けて、GCRにイメージをpushします。
$ docker push gcr.io/kitaji_sample/sample-wordpress:v1.0.0
The push refers to repository [gcr.io/kitaji_sample/sample-wordpress]
d79a1d170eaf: Pushed
d5b61126e77c: Pushed
182f6bf618c4: Pushed
02e5b86b9d8d: Pushed
f190d03dd9cf: Pushed
31edc4603d49: Pushed
a6c798e344c1: Pushed
7ad4f8a271af: Pushed
8b9e7bae16d7: Pushed
4c31d76c6594: Pushed
983090088b87: Pushed
53f8a4a17b10: Pushed
01af4509e166: Pushed
37a065eea6b3: Pushed
8067bb2f50e2: Pushed
ba31a1dbfcfb: Pushed
3e84f33ac944: Pushed
9f9d470ac131: Pushed
86569e4ec54b: Pushed
12fe3564ccac: Pushed
4e9b2aba858c: Pushed
b67d19e65ef6: Pushed
v1.0.0: digest: sha256:a6326341ec7a3c2596125ea424460826e504265924e66e4b34f24bc762a82dce size: 4915
GCRのコンソールで確認してみると、
お、あがってるあがってる（ちなみにこのリポジトリ内を見ると、なんと脆弱性もチェックしてくれてて、350個もありました笑 うち重大は2個w 恒久的に外部に公開する前には重大：中以上は解決しておかないとですね汗）
インスタンスもそうですが、GCRにあげたイメージも課金対象なので、必要ない時は削除をおすすめします。詳しくはGCRの公式ドキュメント参照。
Chapter.4 GKEのクラスタ作成
先ほどのGCRへのpushもそうですが、これ以降のやり方はGCPの公式ドキュメントに詳細に書かれているので、それを参考にやってみた方がいいかと思います。（特にオプション周りとか）
自分は実際に実行したコマンドを並べて紹介していきたいと思います。完全にお試しクラスタなので、オプションで不十分だったりするところあるんですが、ご容赦ください。（autoscaleとか設定してなかったり、stackdriverの設定だったり..←後で消すのめんどくさいと思った）
$ gcloud container clusters create sample-wordpress-web --region asia-east1 --machine-type g1-small --subnetwork kitaji-sample-subnet --disk-size 10GB --network kitaji-sample-network --max-nodes-per-pool 100 --num-nodes 1
WARNING: Currently VPC-native is not the default mode during cluster creation. In the future, this will become the default mode and can be disabled using `--no-enable-ip-alias` flag. Use `--[no-]enable-ip-alias` flag to suppress this warning.
WARNING: Newly created clusters and node-pools will have node auto-upgrade enabled by default. This can be disabled using the `--no-enable-autoupgrade` flag.
WARNING: Starting in 1.12, default node pools in new clusters will have their legacy Compute Engine instance metadata endpoints disabled by default. To create a cluster with legacy instance metadata endpoints disabled in the default node pool, run `clusters create` with the flag `--metadata disable-legacy-endpoints=true`.
WARNING: Your Pod address range (`--cluster-ipv4-cidr`) can accommodate at most 1008 node(s).
This will enable the autorepair feature for nodes. Please see https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more information on node autorepairs.
Creating cluster sample-wordpress-web in asia-east1... Cluster is being health-checked (master is healthy)...done.
Created [https://container.googleapis.com/v1/projects/kitaji-sample/zones/asia-east1/clusters/sample-wordpress-web].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/asia-east1/sample-wordpress-web?project=kitaji-sample
kubeconfig entry generated for sample-wordpress-web.
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS
sample-wordpress-web asia-east1 1.13.11-gke.14 35.201.158.151 g1-small 1.13.11-gke.14 3 RUNNING
クラスタの作成は少し時間がかかります。
今回WARNINGたくさんあるけど、取り急ぎなんかできたっぽい。
ほんとならyamlとか作って体系的に書けるんだろうけど、いったんその辺置いといて、GKEコンソールで確認(gcloud container clusters describe クラスタ名とかでも確認できる)
きっとあとはIngress(→LB)、Service、Deploymentの設定を入れたげれば、公開されるはずっ。
Chapter.5 クラスタにデプロイ
いよいよ最後デプロイと公開工程です。
まず先ほど作成したクラスタをkubectlコマンドで使えるようにする
$ gcloud container clusters get-credentials sample-wordpress-web --region asia-east1 --project kitaji-sample
Fetching cluster endpoint and auth data.
kubeconfig entry generated for sample-wordpress-web.
これで先ほどのクラスタに対しkubectlコマンドが使えるようになりました。kubectl get nodes とか実行したら、ぶら下がってるnodeが出てくるはず。
さて、それでは公開に向けて、Ingress、Service、Deploymentの設定を作成していきます。
設定はそれぞれyamlファイルをローカルに作成して、kubectl applyのコマンドでデプロイするだけです。（なんて簡単！）
ただ、Ingressを作るたびにIPアドレスが変わられるとインフラ開発工程上厄介になり得るので、先に静的IPアドレスを予約しておきます。
$ gcloud compute addresses create sample-wordpress-web --global
Created [https://www.googleapis.com/compute/v1/projects/kitaji-sample/global/addresses/sample-wordpress-web].
$ gcloud compute addresses list --global
NAME ADDRESS/RANGE TYPE PURPOSE NETWORK REGION SUBNET STATUS
sample-wordpress-web XX.XXX.XX.XX EXTERNAL RESERVED
予約が完了したので、それでは各yamlファイルを作成します。それぞれ以下の通り作成しました。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: sample-wordpress-deploy
labels:
app: sample-wordpress
spec:
replicas: 1
selector:
matchLabels:
app: sample-wordpress
template:
metadata:
labels:
app: sample-wordpress
spec:
containers:
- name: sample-wordpress-web
image: gcr.io/kitaji-sample/sample-wordpress:1.3.0
imagePullPolicy: Always
ports:
- containerPort: 80
protocol: TCP
readinessProbe:
httpGet:
path: /health.html
port: 80
initialDelaySeconds: 5
periodSeconds: 5
apiVersion: v1
kind: Service
metadata:
name: sample-wordpress-service
labels:
app: sample-wordpress
spec:
selector:
app: sample-wordpress
type: NodePort
ports:
- port: 8080
targetPort: 80
protocol: TCP
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: sample-wordpress-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: sample-wordpress-web
spec:
backend:
serviceName: sample-wordpress-service
servicePort: 8080
あとはkubectl applyでデプロイするだけ！（たぶん！）
$ kubectl apply -f sample-wordpress_deployment.yml
deployment.apps/sample-wordpress-deploy created
$ kubectl apply -f sample-wordpress_service.yml
service/sample-wordpress-service created
$ kubectl apply -f sample-wordpress_ingress.yml
ingress.extensions/sample-wordpress-ingress created
あっさり作られました。一応作られてるか確認します
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
sample-wordpress-deploy 1/1 1 1 10h
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP XX.XX.XXX.X <none> 443/TCP 11h
sample-wordpress-service NodePort XX.XX.XXX.XXX <none> 8080:30585/TCP 10h
$ kubectl get ingress
NAME HOSTS ADDRESS PORTS AGE
sample-wordpress-ingress * 80 10h
ん？Ingressのアドレスが空欄だ・・・。さっき静的IPを予約したはず。
コンソールでもみてみると、まだ、ステータスがCreating Ingressでした。なるほどingressは時間がかかるんかぁ。
しばし待ちます。
再度ingressだけ確認してみます
$ kubectl get ingress
NAME HOSTS ADDRESS PORTS AGE
sample-wordpress-ingress * XX.XXX.XX.XX 80 12m
お、無事に作られてそう。と思いきや、コンソールで見ると、ステータスにWARNアイコン。
なにやらバックエンドサービスでヘルスチェックが通っていない的なことを言っている。
実際、割り当てられた外部IPアドレスにアクセスしてみると、502。
ここからかなり時間を費やしました。。
いろいろKubernetesのヘルスチェックを調べていると、ヘルスチェック（今回指定しているのはreadinessProbe）で指定したパスに対して、200が返ってこないとダメらしい。そしてStackdriverのContainerLogを見ると、返しているのは301。。なるほど。
wordpressのあれかな、.htaccessによるリダイレクトがいけないのかなってことで、この際、health.htmlなるファイル(中身はHello.と書いただけ)を/var/www/htmlに置いてみて、readinessProbeで指定するパスを/health.htmlに変えてもう一度死に戻り、全て再applyしてみます。
すると、
ついにOK〜〜〜！！（←泣きそう）
もしかして、これで、、アクセスできるんちゃうか！？
・・・ドキドキ・・・ドキドキ・・・・
ぐぬぬぬぬ！！！！
ただ、502ではなくなったので、進撃はしているようだ。
今度はこの404を倒す・・・このくらいの絶望で俺が止まると思うなよ！！
とは言ったものの、LBからポッドまで通信はきていそうだし、/var/www/html内にも各ファイルが配置されているし、所有者とグループがwww-dataではなく、rootになっていたので直してみたし、、と悩みまくって禿げそうだったので、先輩エンジニアの方々に相談に乗ってみてもらったところ、ついに、原因が特定できましたっ！
なんとWordPressのこの設定部分でした
mysql> SELECT * FROM wp_options WHERE option_name IN ('home','siteurl');
+-----------+-------------+------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+-------------+------------------------+----------+
| 2 | home | http://localhost:8080/ | yes |
| 1 | siteurl | http://localhost:8080/ | yes |
+-----------+-------------+------------------------+----------+
2 rows in set (0.00 sec)
なんというチョンボ・・・orz
管理画面でいうと「設定＞一般」の赤枠部分です。
ここを
mysql> UPDATE wp_options SET option_value = 'http://Ingressに割り当てられた外部IPアドレス/' where option_name IN ('home');
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE wp_options SET option_value = 'http://Ingressに割り当てられた外部IPアドレス/' where option_name IN ('siteurl');
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
に変更します。外部IPアドレス部分はドメインを取得していたらドメインでもOKなやつ
そしてついにっ、、、
ごちそうさまです♪
最後に
やってたら意外と盛りだくさんで時間が最後たらなくなって急ぎ足になってしまいました。。
本当はこの後、Spinnakerチャレンジとかしてみたかった。
これ書くまでにいろいろグレンジの先輩エンジニアの方々にみなさん年末の鬼多忙の中、片手間でもアドバイスをいただいて、なんとか最後までできましたm(._.)m
僕の先輩方はみんな超鬼がかってました！！
グレンジには「困っていたら助けるのは当たり前」なたっち・みーさん的エンジニアがたくさんいるふれんどりぃな会社です^^
これを最後まで読んでくれた心優しきあなたのJOINをいつでもお待ちしています！！笑
https://www.grenge.co.jp/recruit/