5日目の記事を担当しますkitaji_ngzkと申します。昨年に引き続き、同プロジェクトでPHPを扱うサーバーサイドエンジニアをやってます。自分が属するプロジェクトには専任のインフラエンジニアがいないため、サーバーサイドエンジニアが兼任する形で担当しています。必然的にインフラ知識も俄然学ぶ必要があるので、今回個人的に「コンテナ」という技術に触れてみたいと思い、Dockerでローカル環境の構築からクラウドにあげて公開してみるところまで実践した軌跡をご紹介したいと思います。Docker公式のWordPressイメージを用いて、超速構築!まず手始めにローカル環境でコンテナに触れてみます。※前提としてDockerがインストールされていることから話を進めます。MySQLのイメージをローカルにpullします。↓WordPressイメージのタグ一覧https://hub.docker.com/_/wordpresspullする時、指定のタグを:つなぎで指定できますが、指定しなければlatestがpullされます。wordpress続けてMySQLもpullしますが、ここで気をつけないといけないのは、MySQLのlatestは8系で認証方法が変わっていて、WordPressの接続エラーという罠が待っているので、バージョンを指定して落としましょう。(8系でも認証方式を昔のものに戻せば、使えるっちゃあ使えます)↓MySQLイメージのタグ一覧https://hub.docker.com/_/mysql8系以外の最新では現時点で5.7系があったのでそれにします。mysql:5.7さて、両方ちゃんと落とせたか確認します。437MBこんな感じで表示されてれば成功。この二つのイメージをそれぞれ使って、それぞれのコンテナを作成していきます。オプション」とかで調べましょう。sample-mysqlという部分は任意のコンテナ名です。(また、ぶっちゃけいちいち先にpullしなくても、このrunコマンドで勝手に持ってきてくれるっちゃあくれます。)では、無事にコンテナが起動しているか、確認しましょう。sample-mysqlこのように表示されてれば成功です。それではこのMySQLサーバーにつなげるWordPressコンテナを作成していきます。sample-mysql無事起動したようだ。それでは上記のコマンドにもある通り、ポート8080をあけたので、http://localhost:8080にアクセスしてみましょうこのように表示されれば成功です。あとは画面通りに設定項目埋めていけば、WordPressのローカル環境はできあがりです。今は/var/www/htmlをホストにマウントしていないので、いじりたいhtmlやphpファイルをエディタでいじいじできないという壁があります。execでコンテナ内に入れば、用を足せると思います。このコンテナにはvimを入れてないので、vimをapt-getでインストールする必要があります。)ではwp-admin画面まで表示されたら、一度以下のコマンドで、ホストの任意のディレクトリにDocker内のファイルをコピーしておきます。コピー先のディレクトリでhtml以下のWordPressのファイルがもろもろあればOKです。sample-mysql戻ってきたら、当然先ほどのlocalhostにアクセスしても、応答がないと思います。WordPressコンテナを作り直します。今度は先ほどコピーしたディレクトリをマウントさせて作ります。sample-mysqlここで、先ほど同様localhost:8080にアクセスしてみましょう。最初に設定した内容そのままに復元できました。ホストにマウントされているので、これでテーマをインストールしたりしても、ホスト側にも反映されるようになり、ホスト側をgitで管理したりすれば開発が複数人でできるようになると思います。超速でローカル環境を構築できたものの、この構成をクラウド上でも実現したいと思います。ローカルではMySQLコンテナを作りましたが、クラウド上ではDBはスケールさせないのでVMインスタンスで十分だと思います。(データの永続化という方法もありますが)ということで、クラウド(今回はGCP)上にMySQLサーバー作っていきます。./↑コピー先は./入れてますが、任意のディレクトリで.(ぶっちゃけマウントしてるディレクトリにもともと格納すればホストに落ちてくるという)3のちのちのためにVPCネットワーク作成4VMインスタンス作成→MySQL5.7入れる(←ここで入れるMySQLのバージョンはローカルで使ってたやつと一緒にするように)7VMインスタンスに2のdumpファイル転送&ぶっこみこれでDockerで作られてるMySQLコンテナの中と同じ構成のサーバーができたはず。ここまでで、もちろんホストPCからもDBサーバーのMySQLにアクセスできるはずなので、確かめてみます。(61)!?むむ!つながらぬ。お試しでローカルからアクセスしてみようと思い、一時的にIPとポート全開放(超非推奨)してましたが、ssh用のポートはtelnetコマンドで確認してみても問題なかったので、おそらくポートは開いているだろう。hostとかになりそうな気もするので、サーバー内のMySQLまでは到達していそう。なると、MySQLの設定周りが怪しいかもってことで、調べていると以下の情報に行き着きました。https://gist.github.com/koudaiii/10696132念の為リンク切れちゃった時用に一部以下抜粋しておきますが、自分が引っかかったのはここでした。2.my.cnfのbind-address設定my.confのbind-addressの設定を確認してみる。(接続したいマシンのIPアドレス)追加したい接続先のIPを書いた「bind-address」を追加していけばOK。どのIPからも接続許可する場合はbind-addressをコメントアウトすればOK。たしかにサーバー内のmy.confの設定内にlocalhostのみ許可のデフォ設定がありました。(ここにたどり着くまでに自分は4,5回死に戻り(=削除して再作成したり)してます笑)ので、教えの通りにコメントアウトし、再度ホストPCからtelnetしてみると、接続ができたので、MySQLコマンドを再度叩いてみる。statement.mysql>やったーーー!!ついにローカルからもアクセスできるようになりました。WordPressコンテナの/var/www/html配下はホストにマウントしてあると思うので、wp-config.phpを自分の好きなエディタで編集してDB_HOSTの向き先を試しに変更してみます。'外部IPアドレス');これでhttp://localhost:8080にアクセスしてみましょう。ローディングが長く感じますが、これでローカルのWordPressコンテナからクラウド上のMySQLサーバーに接続することができました!(無事MySQLをGCPに作れたようだ←これはこれで個人的にできたの嬉しい笑)ただ、注意を一つですが、この時点でMySQLのユーザはこうなってるはずです。sec)root権限がどんなIPからでも使えちゃう怖い状況なので、しっかり削除そして、WordPressからアクセスする用のユーザを作成して、WordPressで使用するDBのみ許可する権限を与えておきましょう!→最終的に同じVPNネットワークにする予定なので、プライベートネットワークのみに制限WordPressで使用するユーザを作成したら、wp-config.phpに反映することを忘れずに!(・・・ていうか、これ最初からやっとけばよかったんじゃね?|ω・`))さて、もし同じようにローカルから接続してみた場合は、忘れずにIPとポートを閉めて、wp-config.phpの設定もローカルのmysqlコンテナ向きに戻しておきましょう。commitのコマンドを使用するか、DockerFileを作成してイメージをビルドするかなどがあります。実際にGKEで動作させる際、WordPressのDB_HOSTは先ほど作成したMySQLサーバーを向いて欲しかったりします。なるとローカルコンテナをそっくりそのままイメージ化しても動かないでしょう。これまでやってきた流れをDockerfileで再現する形でイメージをビルドしてGCRにあげてみたいと思います。Dockerfileは以下のように作成しました。最後に「クラウド用の設定でwp-config.phpを上書き」とありますが、最終的にGKEとMySQLサーバーが同VPCネットワーク内であればプライベートIPで接続できるはずなので、DB_HOSTの向き先をそのように変えてあるファイルを取り込んでいます。/var/www/html/wp-config.phpイメージをビルドします。sample-wordpress:1.0.0成功したようなので、確認します。437MBこれでイメージ化できました。run)、同じようにWordPress管理画面が表示されればOKです。(実際プロジェクトとして開発する時は、ローカルのソースコードじゃなくて、ちゃんとgit管理されたmasterブランチのソースコードをpullしてきて、それをADDするべきかなと思います)次に、GCRに上げるには、イメージにレジストリ名をタグ付けする必要があるので、以下の通りタグ付けします。437MBkitaji_sampleとなっているところはGCPのプロジェクト名です。続けて、GCRにイメージをpushします。恒久的に外部に公開する前には重大:中以上は解決しておかないとですね汗)インスタンスもそうですが、GCRにあげたイメージも課金対象なので、必要ない時は削除をおすすめします。詳しくはGCRの公式ドキュメント参照。先ほどのGCRへのpushもそうですが、これ以降のやり方はGCPの公式ドキュメントに詳細に書かれているので、それを参考にやってみた方がいいかと思います。(特にオプション周りとか)自分は実際に実行したコマンドを並べて紹介していきたいと思います。完全にお試しクラスタなので、オプションで不十分だったりするところあるんですが、ご容赦ください。RUNNINGクラスタの作成は少し時間がかかります。今回WARNINGたくさんあるけど、取り急ぎなんかできたっぽい。クラスタ名とかでも確認できる)きっとあとはIngress(→LB)、Service、Deploymentの設定を入れたげれば、公開されるはずっ。クラスタにデプロイいよいよ最後デプロイと公開工程です。sample-wordpress-web.これで先ほどのクラスタに対しkubectlコマンドが使えるようになりました。実行したら、ぶら下がってるnodeが出てくるはず。それでは公開に向けて、Ingress、Service、Deploymentの設定を作成していきます。applyのコマンドでデプロイするだけです。(なんて簡単!)ただ、Ingressを作るたびにIPアドレスが変わられるとインフラ開発工程上厄介になり得るので、先に静的IPアドレスを予約しておきます。RESERVED予約が完了したので、それでは各yamlファイルを作成します。それぞれ以下の通り作成しました。createdあっさり作られました。10hん?Ingressのアドレスが空欄だ・・・。さっき静的IPを予約したはず。Ingressでした。ingressは時間がかかるんかぁ。12mお、無事に作られてそう。思いきや、コンソールで見ると、ステータスにWARNアイコン。なにやらバックエンドサービスでヘルスチェックが通っていない的なことを言っている。実際、割り当てられた外部IPアドレスにアクセスしてみると、502。ここからかなり時間を費やしました。Kubernetesのヘルスチェックを調べていると、ヘルスチェック(今回指定しているのはreadinessProbe)で指定したパスに対して、200が返ってこないとダメらしい。StackdriverのContainerLogを見ると、返しているのは301。wordpressのあれかな、.htaccessによるリダイレクトがいけないのかなってことで、この際、health.htmlなるファイル(中身はHello.と書いただけ)を/var/www/htmlに置いてみて、readinessProbeで指定するパスを/health.htmlに変えてもう一度死に戻り、全て再applyしてみます。すると、ついにOK〜〜〜!!(←泣きそう)もしかして、これで、、アクセスできるんちゃうか!?・・・ドキドキ・・・ドキドキ・・・・ぐぬぬぬぬ!!!!ただ、502ではなくなったので、進撃はしているようだ。sec)なんというチョンボ・・・orz管理画面でいうと「設定>一般」の赤枠部分です。最後にやってたら意外と盛りだくさんで時間が最後たらなくなって急ぎ足になってしまいました。本当はこの後、Spinnakerチャレンジとかしてみたかった。upLoginユーザーは見つかりませんでした。