Casual Developers Notes

初級・中級のエンジニアやデザイナー向けに技術情報と英語学習情報を提供中。エンジニアもデザイナーも技術と英語を身に着けて海外に飛び立とう！

You are here: Home / Archives for aws

By Leave a Comment

Docker SwarmでDockerコンテナのオーケストレーション入門

Docker SwarmでDockerコンテナのオーケストレーション入門

アプリケーションをDockerコンテナとして、本番環境で稼働させるにはオーケストレーションツールは無くてはならないものです。今回は、Docker Swarmを使って、Dockerコンテナをオーケストレーションする方法を紹介します。

はじめに

Dockerコンテナを開発環境や実証実験で使う機会は圧倒的に増えてきました。そのおかげでDocker自体やDocker Composeを使いこなすエンジニアは増えました。次のステップとして、Dockerコンテナを本番環境に導入することを考えると思いますが、その場合はDockerコンテナのオーケストレーションを考える必要が出てきます。現状のDockerオーケストレーションツールのデファクトスターンダードはGoogle社のKubernetesですが、今回はDocker社がDockerネイティブとしてサポートしているSwarmを使う方法をDockerオーケストレーションの入門として紹介します。

Docker Machineとは？

Docker Machineとは、任意のホストの仮想環境上にDockerエンジンの実行環境を構築するプロビジョニングツールです。

例えば、個人の開発環境を考えると、Mac上でDockerコンテナを稼働させる場合、Docker for MacをインストールすることでDockerエンジンをローカルで実行し、そのDockerエンジン上でDockerコンテナを稼働させることになると思います。しかし、本番環境などMac以外でDockerコンテナを稼働させることを考えた場合はどうすればよいでしょうか？その答えとして、Dockerコンテナの実行環境であるDockerエンジンを持ち運び可能にすることで、好きなホスト上でDockerコンテナを実行可能にする仕組みがDocker Machineです。この仕組みにより、ドライバー(仮想環境の種類)を指定することで、VirtualBox上でもAWS上でもAzura上でも、好きなホストの仮想環境上でDockerエンジンを動かし、Dockerコンテナンを稼働させることができます。

Docker Swarmとは？

Docker Swarmとは、Dockerコンテナのオーケストレーションツールです。新しく入れるツールというのではなく、Dockerにネイティブで組み込まれており、Swarmモードをアクティブにすることで利用可能になります。

今回のメイントピックなので、細かい説明は抜きにして、次の章から手を動かしてい理解していきましょう。

Docker Swarmを使ってみよう！

概要

今回は、Swarm用のマネージャーノード1台、ワーカーノード2台の構成でDocker Machineを作り、Swarmのノード上にNginxのサービスをいくつか立ち上げてみましょう。

事前に、Swarmのノードの構成が書かれた公式ドキュメントや、Swarmのサービスの構成が書かれた公式ドキュメントあたりに目を通しておくと理解が深まります。

前提

以下がインストールされている必要があります。

  • Docker for Mac
  • VirtualBox

細かいバージョンは「環境」を参照してください。

Swarm用のマネージャーノードを作る

まずは、Docker Machineで「swarm-manager」という名前のノードを作り、Swarmモードを有効にします。Docker MachineのデフォルトのドライバーはVirtualBoxなので、ノードはVirtualBox上に作成されます。

$ docker-machine create swarm-manager
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   -        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
$ eval $(docker-machine env swarm-manager)
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   *        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
$ docker-machine ip swarm-manager
192.168.99.100
$ docker swarm init --advertise-addr 192.168.99.100
$ docker info | grep Swarm
Swarm: active
$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
jm20ptzjqptaqop9e9g1frv58 *   swarm-manager       Ready               Active              Leader              18.06.1-ce

「swarm-manager」ノードのSwarmがアクティブになり、Leaderになっていることが確認できます。これでマネージャーノードは完成です。

Swarm用のワーカーノードを作る

次に、ワーカーノードを2台(「swarm-wocker1」と「swarm-wocker2」)を作成し、Swarmのオーバーレイ・ネットワーク(ingressネットワーク)に追加します。追加したノードはSwarm内でルーティング・メッシュにより、自動的にロードバランスされます。

先に「swarm-manager」ノード上でワーカーノードを追加するためのトークンを取得します。

$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
jm20ptzjqptaqop9e9g1frv58 *   swarm-manager       Ready               Active              Leader              18.06.1-ce
$ docker swarm join-token worker
To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-398kt7tj5z33es0ek580gtz4r0d1xgm6yqqktczzzus1bxm9gy-3o2etc9uhs7pb96h67fnzqw73 192.168.99.100:2377

それから、ワーカーノードを作っていきます。

$ docker-machine create swarm-worker1
$ docker-machine create swarm-worker2
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   *        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   -        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   -        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ eval $(docker-machine env swarm-worker1)
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   -        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   *        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   -        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ docker swarm join --token SWMTKN-1-398kt7tj5z33es0ek580gtz4r0d1xgm6yqqktczzzus1bxm9gy-3o2etc9uhs7pb96h67fnzqw73 192.168.99.100:2377
This node joined a swarm as a worker.
$ eval $(docker-machine env swarm-worker2)
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   -        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   -        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   *        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ docker swarm join --token SWMTKN-1-398kt7tj5z33es0ek580gtz4r0d1xgm6yqqktczzzus1bxm9gy-3o2etc9uhs7pb96h67fnzqw73 192.168.99.100:2377
This node joined a swarm as a worker.
$ eval $(docker-machine env swarm-manager)
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   *        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   -        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   -        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
vp63ef6ywgyqykiplzn24o9nq *   swarm-manager       Ready               Active              Leader              18.06.1-ce
kf8fsltttorlbqips470qnlvj     swarm-worker1       Ready               Active                                  18.06.1-ce
9vgc77yekm2fj72oq5x96f1ok     swarm-worker2       Ready               Active                                  18.06.1-ce

これで、「swarm-manager」というマネージャーノード1台、「swarm-worker1」と「swarm-worker2」のワーカーノード2台の構築が完了しました。

Swarmビジュアライザーを追加する

それでは、ノード上にサービスを、、、と行きたいところですが、その前にSwarmの構成を可視化するツールであるSwarmビジュアライザーを導入してみましょう。

$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   *        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   -        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   -        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ docker service create --name=viz --publish=8080:8080/tcp --constraint=node.role==manager --mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock dockersamples/visualizer
$ docker container ls
CONTAINER ID        IMAGE                             COMMAND             CREATED              STATUS                        PORTS               NAMES
76d49f568d84        dockersamples/visualizer:latest   "npm start"         About a minute ago   Up About a minute (healthy)   8080/tcp            viz.1.nab0yu9vfz6312v9b85grwhej
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
m9c4l9ggdhes        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp
$ docker-machine ip swarm-manager
192.168.99.100

それでは、「192.168.99.100:8080」にアクセスしてみましょう。

NewImage

構築したSwarmの3台のノードと、マネージャーノード上にSwarmビジュアライザーが「viz」という名前のサービスとして起動していることが可視化されています。

ちなみに、今回は「viz」というサービスとして起動しましたが、Swarmのサービスに含めたくない場合は、以下のように通常のコンテナとして起動することも可能です。

$ docker container run -d --name=viz --publish=8080:8080/tcp --mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock dockersamples/visualizer

この場合はSwarmビジュアライザーにも表示されません。

Swarmのノード上でサービスを作成する

それでは、Nginxのサービスを5つ作成してみましょう。(厳密にはSwarmではノード上の１つのアプリケーションを「タスク」と呼び、それをグループ化したものを「サービス」と呼んでいますが、この記事では便宜上、1つのアプリケーションを一般的な意味でサービスと表現しています。)

$ docker service create -d --name web --publish 8000:80 --replicas 5 nginx
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
m9c4l9ggdhes        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp
dq4pntmf9eej        web                 replicated          5/5                 nginx:latest                      *:8000->80/tcp
$ docker service ps web
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
e8p6ojsguah7        web.1               nginx:latest        swarm-worker1       Running             Running 1 minutes ago
y9honj8v0rzj        web.2               nginx:latest        swarm-worker2       Running             Running 1 minutes ago
sr6e97b32pc2        web.3               nginx:latest        swarm-manager       Running             Running 2 minutes ago
5vaipy05i88i        web.4               nginx:latest        swarm-worker1       Running             Running 1 minutes ago
i7innmnribly        web.5               nginx:latest        swarm-worker2       Running             Running 1 minutes ago

Swarmビジュアライザーで確認してみましょう。

NewImage

5つの「web」というサービスが各ノードに割り振られて作成され、稼働しています。

各ノードのIPを確認して、Nginxが各ノード上で動いているかも確認してみましょう。

$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default         -        virtualbox   Stopped                                       Unknown
swarm-manager   *        virtualbox   Running   tcp://192.168.99.100:2376           v18.06.1-ce
swarm-worker1   -        virtualbox   Running   tcp://192.168.99.101:2376           v18.06.1-ce
swarm-worker2   -        virtualbox   Running   tcp://192.168.99.102:2376           v18.06.1-ce
$ docker-machine ip swarm-manager
192.168.99.100
$ docker-machine ip swarm-worker1
192.168.99.101
$ docker-machine ip swarm-worker2
192.168.99.102

「192.168.99.100:8000」にアクセスしてみましょう。

NewImage

「192.168.99.101:8000」にアクセスしてみましょう。

NewImage

「192.168.99.102:8000」にアクセスしてみましょう。

NewImage

全てのノード上でNginxのサービスが稼働していることが確認できました。

サービスのスケールを変更する

docker service scaleコマンドにより、サービスの数を自由に変更できます。今回は、5つある「web」のサービスを1つにしてみましょう。

$ docker service scale web=1
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
m9c4l9ggdhes        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp
dq4pntmf9eej        web                 replicated          1/1                 nginx:latest                      *:8000->80/tcp
$ docker service ps web
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
e8p6ojsguah7        web.1               nginx:latest        swarm-worker1       Running             Running 29 minutes ago

Swarmビジュアライザーで見てみましょう。

NewImage

サービスが1つに変更されていることが確認できました。

この状態で、ブラウザで「192.168.99.100:8000」、「192.168.99.101:8000」、「192.168.99.102:8000」にアクセスすると、全てが同じサービスにルーティングされ、Nginxの画面が表示されます。ルーティング・メッシュが作成去れているからですね。

サービスを削除する

最後に、サービスを削除してみましょう。

$ docker service rm web
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
m9c4l9ggdhes        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp

Swarmビジュアライザーで確認します。

NewImage

「web」のサービスはきれいに削除されています。

この状態で、ブラウザで「192.168.99.100:8000」、「192.168.99.101:8000」、「192.168.99.102:8000」にアクセスすると、当然「このサイトにアクセスできません」と表示されます。

これでSwarmによるDockerオーケストレーションの基本は完了です。

おまけ(AWSのEC2上でSwarmを実行する方法)

ここまでは、ローカル環境で実施してきましたが、一歩進めてAWSのEC2上で同じことを実行してみましょう。

AWSのEC2上にSwarmのノードを構築する

基本は同じで、Docker MachineのドライバーにAmazon EC2を指定する(–driver amazonec2)だけでOKです。注意点としては、マネージャーノードは「2377」のポートを開放する必要があります。また、今回はSwarmビジュアライザー用に「8080」ポート、Webサーバ用に「8000」ポートを開放します。

$ aws configure
$ docker-machine create --driver amazonec2 --amazonec2-open-port 2377 --amazonec2-open-port 8080 --amazonec2-open-port 8000 --amazonec2-region us-east-1 aws-swarm-manager1
$ docker-machine create --driver amazonec2 --amazonec2-open-port 8000 --amazonec2-region us-east-1 aws-swarm-worker1
$ docker-machine create --driver amazonec2 --amazonec2-open-port 8000 --amazonec2-region us-east-1 aws-swarm-worker2
$ docker-machine ls
NAME                 ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
aws-swarm-manager1   -        amazonec2    Running   tcp://52.90.91.140:2376             v18.06.1-ce
aws-swarm-worker1    *        amazonec2    Running   tcp://54.227.204.32:2376            v18.06.1-ce
aws-swarm-worker2    -        amazonec2    Running   tcp://54.172.255.110:2376           v18.06.1-ce
$ eval $(docker-machine env aws-swarm-manager1)
$ docker-machine ip aws-swarm-manager1
52.90.91.140
$ docker swarm init --advertise-addr 52.90.91.140
Swarm initialized: current node (q7igg1nnai34e41qrcaao8thq) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-1vsrzboersaqygif1lo58n00390bp6d6wnkoukn1q7ff47gsm4-23utao937z0gmrz7hpher10lw 52.90.91.140:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
$ eval $(docker-machine env aws-swarm-worker1)
$ docker swarm join --token SWMTKN-1-1vsrzboersaqygif1lo58n00390bp6d6wnkoukn1q7ff47gsm4-23utao937z0gmrz7hpher10lw 52.90.91.140:2377
This node joined a swarm as a worker.
$ eval $(docker-machine env aws-swarm-worker2)
$ docker swarm join --token SWMTKN-1-1vsrzboersaqygif1lo58n00390bp6d6wnkoukn1q7ff47gsm4-23utao937z0gmrz7hpher10lw 52.90.91.140:2377
This node joined a swarm as a worker.
$ eval $(docker-machine env aws-swarm-manager1)
$ docker-machine ls
NAME                 ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
aws-swarm-manager1   *        amazonec2    Running   tcp://52.90.91.140:2376             v18.06.1-ce
aws-swarm-worker1    -        amazonec2    Running   tcp://54.227.204.32:2376            v18.06.1-ce
aws-swarm-worker2    -        amazonec2    Running   tcp://54.172.255.110:2376           v18.06.1-ce
$ docker node ls
ID                            HOSTNAME             STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
q7igg1nnai34e41qrcaao8thq *   aws-swarm-manager1   Ready               Active              Leader              18.06.1-ce
28m2usguvsbp5720ny9xee1r7     aws-swarm-worker1    Ready               Active                                  18.06.1-ce
qrn9hes6jkg52n7n38xsu35sf     aws-swarm-worker2    Ready               Active                                  18.06.1-ce

AWSコンソールからEC2インスタンスの状態を確認してみましょう。

NewImage

マネージャーノード1台、ワーカーノード2台がEC2インスタンスとして作成されていますね。

続いて、Security Groupも確認してみましょう。

NewImage

想定通り、「2377」、「8080」、「8000」のポートが開放されています。「2376」ポートはDocker Machineがデフォルトで使っているポートです。

Swarmビジュアライザーを追加する

先ほどと同じくSwarmビジュアライザーをサービスとして追加します。

$ docker node ls
ID                            HOSTNAME             STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
q7igg1nnai34e41qrcaao8thq *   aws-swarm-manager1   Ready               Active              Leader              18.06.1-ce
28m2usguvsbp5720ny9xee1r7     aws-swarm-worker1    Ready               Active                                  18.06.1-ce
qrn9hes6jkg52n7n38xsu35sf     aws-swarm-worker2    Ready               Active                                  18.06.1-ce
$ docker service create --name=viz --publish=8080:8080/tcp --constraint=node.role==manager --mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock dockersamples/visualizer
aqp0ge6qhwirizc0cb9221gwd
overall progress: 1 out of 1 tasks
1/1: running   [==================================================>]
verify: Service converged
$ docker-machine ip aws-swarm-manager1
52.90.91.140

「52.90.91.140:8080」にアクセスしましょう。

NewImage

Swarmビジュアライザーが稼働していることが確認できました。

サービスを作成する

先ほどと同じく、Nginxのサービスを5つ作成してみましょう。

$ docker service create -d --name web --publish 8000:80 --replicas 5 nginx
pkbfqjik6c8kfquwsmjckesla
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
aqp0ge6qhwir        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp
vzhv0xxfat15        web                 replicated          5/5                 nginx:latest                      *:8000->80/tcp
$ docker service ps web
ID                  NAME                IMAGE               NODE                 DESIRED STATE       CURRENT STATE           ERROR               PORTS
i4bdnxib2e3b        web.1               nginx:latest        aws-swarm-worker2    Running             Running 1 minutes ago
o00x9iigopac        web.2               nginx:latest        aws-swarm-manager1   Running             Running 1 minutes ago
gc6wo6rxtgep        web.3               nginx:latest        aws-swarm-worker1    Running             Running 1 minutes ago
opi12tbgytk6        web.4               nginx:latest        aws-swarm-worker2    Running             Running 1 minutes ago
he0qy7w5a5d7        web.5               nginx:latest        aws-swarm-worker1    Running             Running 1 minutes ago
$ docker-machine ip aws-swarm-manager1
52.90.91.140

「52.90.91.140:8080」にアクセスしましょう。

NewImage

サービスが想定どおりに稼働している事がわかります。

ブラウザからサービスを表示してみましょう。

$ docker-machine ip aws-swarm-manager1
52.90.91.140
$ docker-machine ip aws-swarm-worker1
54.227.204.32
$ docker-machine ip aws-swarm-worker2
54.172.255.110

「52.90.91.140:8000」にアクセスしましょう。

NewImage

「54.227.204.32:8000」にアクセスしましょう。

NewImage

「54.172.255.110:8000」にアクセスしましょう。

NewImage

問題なく動いていますね。

クリーンアップ

最後の最後にサービスとAWSのEC2上のDocker Machineをきれいに削除して終わりにしましょう。

$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                             PORTS
aqp0ge6qhwir        viz                 replicated          1/1                 dockersamples/visualizer:latest   *:8080->8080/tcp
vzhv0xxfat15        web                 replicated          5/5                 nginx:latest                      *:8000->80/tcp
$ docker service rm viz web
viz
web
$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE               PORTS
$ docker node ls
ID                            HOSTNAME             STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
q7igg1nnai34e41qrcaao8thq *   aws-swarm-manager1   Ready               Active              Leader              18.06.1-ce
28m2usguvsbp5720ny9xee1r7     aws-swarm-worker1    Ready               Active                                  18.06.1-ce
qrn9hes6jkg52n7n38xsu35sf     aws-swarm-worker2    Ready               Active                                  18.06.1-ce
$ docker-machine ls
NAME                 ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
aws-swarm-manager1   *        amazonec2    Running   tcp://52.90.91.140:2376             v18.06.1-ce
aws-swarm-worker1    -        amazonec2    Running   tcp://54.227.204.32:2376            v18.06.1-ce
aws-swarm-worker2    -        amazonec2    Running   tcp://54.172.255.110:2376           v18.06.1-ce
$ docker-machine rm aws-swarm-manager1 aws-swarm-worker1 aws-swarm-worker2
About to remove aws-swarm-manager1, aws-swarm-worker1, aws-swarm-worker2
WARNING: This action will delete both local reference and remote instance.
Are you sure? (y/n): y
Successfully removed aws-swarm-manager1
Successfully removed aws-swarm-worker1
Successfully removed aws-swarm-worker2
$ docker-machine ls
NAME            ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER    ERRORS

これでAWSのEC2上のインスタンスもきれいに削除されました。自動で作成されていたKey PairsやNetwork Interfacesも一緒に削除されますが、docker-machineという名前のSecurity Groupは残るので気をつけましょう。

最後に

いかがでしたか？これでDocker Swarmを使って、Dockerコンテナをオーケストレーションできるようになったことでしょう。それでは。

環境

  • PC: macOS High Sierra 10.13.6
  • Docker: 18.06.1-ce, build e68fc7a
  • Docker Machine: 0.15.0, build b48dc28d
  • VirtualBox: 5.2.18r124319
  • AWS CLI: aws-cli/1.16.20 Python/3.7.0 Darwin/17.7.0 botocore/1.12.10

By Leave a Comment

MySQLで「ERROR 2003 (HY000): Can’t connect to MySQL server」と怒られた時の対処法

MySQLで「ERROR 2003 (HY000): Can’t connect to MySQL server」と怒られた時の対処法

WordPressを自前で構築する場合にMySQLの接続がうまくいかないことはよくある事象です。今回は、MySQLとの接続で「ERROR 2003 (HY000): Can’t connect to MySQL server」というエラーが発生した場合の対処法を紹介します。

はじめに

この記事に辿り着いているということは、MySQLの設定を終えたつもりで、外部のホストからMySQLのサーバ(X.X.X.X)にログインしようとした時に以下のエラーが出たのではないでしょうか。

$ mysql -h X.X.X.X -P 3306 -u wordpress -p
Enter password:
ERROR 2003 (HY000): Can't connect to MySQL server on 'X.X.X.X' (111)

今回はAWS上に、WordPress用のEC2インスタンスとMySQL用のEC2インスタンスを構築した前提で、「ERROR 2003 (HY000): Can’t connect to MySQL server」エラーが発生した場合の対処法を紹介します。

対処法

考えられる原因は複数あるので、原因を一つ一つ潰す形で対処しましょう。

EC2のSecurity Groupの設定に問題は無いか？(AWS限定の問題)

EC2インスタンスはSecurity Group(仮想的なファイアーウォール)によって接続可能なIPおよびポートを許可しています。サーバーの構成にもよるのですが、WordPress用のEC2インスタンスからMySQLのEC2インスタンスにポート3306で接続したいとすると、MySQL用のEC2インスタンスのSecurity GroupのInboundの設定で、WordPress用のEC2インスタンスのIPからTCPの3306ポートの接続を許可してある必要があります。

以下はTCPの3306ポートを全てのIPに対して許可する場合のInboundの設定です。

Ec2 sg mysql

MySQLに慣れており、EC2に慣れていない人は、だいたいSecurity Groupの設定ミスが原因です。確認してみましょう。

EC2内のファイアーウォールの設定に問題は無いか？

単にAWSが提供しているイメージからEC2インスタンスを作っただけの場合は関係ありませんが、その後に自前でiptablesなどでファイアーウォールを設定した場合は、それが原因の可能性があります。設定を見直しましょう。

MySQLのポートは正しいか？

MySQLのデフォルトのポートは3306ですが、変更した覚えがあればそれが原因の可能性があります。以下のように確認してみましょう。

mysql> show variables like 'port';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| port          | 3306  |
+---------------+-------+

3306を想定しており、上記のように一致してればOKです。

MySQLに接続できるホスト設定に問題は無いか？

仮にwordpressというユーザを作ったとして、そのユーザがどのホストから接続できるようになっているかを確認しましょう。デフォルトでは「localhost」(ループバックアドレスなので同じホスト内のみ接続可能)となっているので、変更した覚えがなければそれが原因です。

mysql> select user, host from mysql.user;
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| wordpress        | %         |
| debian-sys-maint | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
+------------------+-----------+

「wordpress@”%”」の設定となっている場合は、全てのホストからwordpressユーザで接続できます。

MySQLの設定ファイルに問題は無いか？

「/etc/mysql/mysql.conf.d/mysqld.cnf」ファイルのbind-addressも確認しましょう。デフォルトでは「127.0.0.1」(ループバックアドレスなので同じホスト内のみ接続可能)となっているので、接続したいホストに応じてに変更する必要があります。例えば「0.0.0.0」に設定すれば全てのホストからの接続を許可できます。

$ sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf
...
#bind-address            = 127.0.0.1
bind-address            = 0.0.0.0
...

ここまでくればエラーは解決したはずです。

おまけ

外部ホストからのMySQLの接続が成功したとして、WordPressの画面を表示しようとした場合に「Error establishing a database connection」というエラーが発生している場合があります。

このエラーの意味はWordPressとMySQLとの接続に問題があるという意味ですが、この記事で解決したエラーがなくなっている状態で発生している場合は原因はおそらく一つです。WordPressのDB_HOSTの設定を見直しましょう。

$ vi /var/www/wordpress/wp-config.php
...
define('DB_HOST', 'X.X.X.X');
...

今回の場合は、明示的にMySQL用のEC2インスタンスのプライベートIPを指定してあげる必要があります。

最後に

いかがでしたか？これでMySQLの接続問題は解決できたことでしょう。また、AWSを使っていなくても、AWS以外の部分はそのまま解決策になると思いますので、検索してこの記事にたどり着いた人は試して見て下さい。それでは。

By Leave a Comment

Amazon S3で静的コンテンツを独自ドメインでSSL化してホスティングする方法(S3 + CloudFront + Route53 + ACM)

Amazon S3で静的コンテンツを独自ドメインでSSL化してホスティングする方法(S3 + CloudFront + Route53 + ACM)

静的サイトを作ったら、それをホスティングする必要があります。個人の趣味サイトなら簡単で無料の方法はGithub Pagesですが、もう少し真面目に静的コンテンツを管理してホスティングしたいのであればAmazon S3は有力な選択肢になります。今回は、S3で静的コンテンツを独自ドメインでSSL化してホスティングする方法を紹介します。

はじめに

今回はReactで作った静的コンテンツをAmazon S3でホスティングする方法を紹介します。それだけでは物足りないので、独自ドメイン対応、SSL化までやっていきます。それでは、始めましょう。

前提

この記事を楽しむには以下が必要です。

  • NodeJSがインストール済みであること
  • AWS CLIがインストール済みであること
  • ドメインを取得済みであること

静的サイトの作成

まずはホスティングする静的サイトを作ります。

準備

Reactでちゃちゃっとサンプルサイトを作ることにしましょう。

$ npm install -g create-react-app
$ create-react-app my-website
$ cd my-website/

静的サイトの作成

今回はReactアプリケーションを作ることが目的ではないので、App.jsの画面に表示される文字を変更するだけにします。

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';
class App extends Component {
render() {
return (
<div className="App">
<header className="App-header">
<img src={logo} className="App-logo" alt="logo" />
<h1 className="App-title">Hosting a React Welcom Page on S3</h1>
</header>
<p className="App-intro">
Amazon S3 is easy stuff for hosting a static website.
</p>
</div>
);
}
}
export default App;

はい、完成です。

S3バケットの作成と静的サイトのデプロイ

次にS3バケットに作ったサンプルサイトをデプロイしましょう。

S3バケットの作成

S3バケットはAWSコンソールから作ってもよいのですが、AWS CLIから作ってみましょう。

$ aws s3 ls
$ aws s3 mb s3://mywebsite-hosting
make_bucket: mywebsite-hosting
$ aws s3 ls
2018-07-07 11:00:52 mywebsite-hosting

ビルドしてデプロイ

$ yarn build
$ ls
README.md     build/        node_modules/ package.json  public/       src/          yarn.lock
$ aws s3 sync build s3://mywebsite-hosting
$ aws s3 website s3://mywebsite-hosting --index-document index.html

AWSコンソールでS3バケットを確認してみましょう。

S3 2

作成したS3バケット上にビルドしたファイルが全てアップロードされています。

S3 0

作成したS3バケットがホスティングされています。

S3バケットのポリシー設定

S3バケットにアップロードしたファイルはデフォルトではアクセスが許可されていないので、誰でも見れるようにポリシーを変更します。

S3 1

今回は以下のポリシーを設定しました。S3のポリシーはジェネレーターサイトを使うことでGUIで作成できます。

{
"Version": "2012-10-17",
"Id": "Policy1530901313146",
"Statement": [
{
"Sid": "Stmt1530901311070",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mywebsite-hosting/*"
}
]
}

表示できるか確認します。AWSのS3のコンソールから、エンドポイントを確認します。

S3 3

エンドポイントをブラウザで開きます。

S3 4

サンプルサイトがホスティングされていることが確認できました。

独自ドメインの設定

次に、ホスティングしているサンプルサイトに独自ドメインを設定しましょう。

Route53に独自ドメインを登録する

AWSのRoute53のコンソールから、「Hosted zones -> Create Hosted Zone」を選択し、「Domain Name」に取得済みのドメイン名を入力し、「Create」をクリックします。

Route53 1

作成されたHosted zoneのNSレコードのValueをDNSに設定します。

Route53 2

DNSの例として、ムームードメインの場合は、以下のように設定し、「ネームサーバ設定変更」をクリックします。

Mumu 3

CloudFrontでエンドポイントとドメインを紐付ける

AWSのCloudFrontのコンソールから、「Create Distribution」をクリックします。

Cf 1

今回は静的サイトを扱うので、Webの「Get Started」をクリックします。

Cf 2

「Origin Domain Name」にS3バケットのエンドポイントのURL(今回の場合は「http://mywebsite-hosting.s3-website-us-east-1.amazonaws.com/」)を入力します。すると、自動的に「Origin ID」が設定されます。

Cf 3

ファイルを圧縮して配信したい場合は「Compress Objects Automatically」を「Yes」にします。

Cf 5

「Price Class」には配信するロケーションを指定します。日本も配信する場合は「Use All Edge Locations」を選択します。「Alternate Domain Names」にはドメイン名を入力します。

Cf 5

「Default Root Object」には「index.html」と入力します。そして、「Create Distribution」をクリックします。

Cf 6

「Status」が「Deployed」になればCloudFrontの設定は完了です。

Cf 7

Route53にCloudFrontを紐付ける

AWSのRoute53のコンソールから、「Create Record Set」をクリックします。今回はサブドメインを利用しないので、Nameは空にします。そして、「Alias」に「Yes」を選択し、「Alias Target」に先程作成したCloudFrontのDistributionの設定を選択します。「Create」をクリックします。

Route53 5

以下のようにAレコードが追加されました。

Route53 6

これで独自ドメインでサンプルサイトが表示できるようになりました。

無料でSSL化

それでは無料でSSLに対応しましょう。

AWS Certificate Manager(ACM)で無料のSSL証明書を発行する

AWSのCertificate Managerのコンソールから、「Request a certificate」をクリックします。

Acm 1

「Domain name」にドメイン名またはサブドメイン名を入力し、「Next」をクリックします。

Acm 2

「DNS validation」を選択し、「Review」をクリックします。

Acm 3

「Confirm and request」をクリックします。

Acm 4

「Continue」をクリックします。

Acm 5

このままだとStatusが「Pending validation」のままなので、「Create record in Route 53」からバリデーション用のレコードを追加します。

Acm 7

「Create」をクリックします。

Acm 8

以下のようにSUCCESSが表示されたら、Route53に設定されていることを確認します。

Acm 9

以下のようにAWSのRoute53のコンソールにバリデーション用のCNAMEレコードが追加されていることが確認できます。

Route53 7

しばらく待つと、AWSのCertificate Managerのコンソールから、以下のように「Status」が「Issued」になり、SSL証明書の発行が完了します。

Acm 10

CloudFrontにSSL証明書を設定する

AWSのCloudFrontのコンソールから、対象のDistributionを選択します。

Cf 8

「General」を選択し、「Edit」をクリックします。

Cf 9

「SSL Certificate -> Custom SSL Certificate」を選択し、先程の発行したSSL証明書を選択します。「Yes, Edit」をクリックします。

Cf 10
Cf 11
Cf 12

以下のように「SSL Certificate」にSSL証明書が設定されていることを確認します。

Cf 13

これでSSL証明書の設定は完了です。

HTTPをHTTPSにリダイレクトするように設定する

SSL化されたのでHTTPSのみにしてもよいのですが、ユーザーがブラウザにHTTPでURLを入力する場合もありえるので、HTTPで入力された場合にHTTPSにリダイレクトするように設定します。

「Behaviors」を選択し、デフォルトのBehaviorを選択して「Edit」をクリックします。

Cf 21

「Viewer Protocol Policy」に「Redirect HTTP to HTTPS」を選択して、「Yes, Edit」をクリックします。

Cf 22
Cf 23

以下のように「Viewer Protocol Policy」が「Redirect HTTP to HTTPS」に変更されていることを確認します。

Cf 24

しばらくして「Status」が「Deployed」になれば、上記の設定変更の反映は完了です。

Cf 25

動作確認

最後にブラウザに独自ドメインのURLを入力してみましょう。

Hosting

SSLで正しく表示されました。

おまけ

CloudFrontのキャッシュ削除の方法

S3バケットを更新した後にコンテンツをすぐに反映させるにはCloudFrontのキャッシュを削除する必要があります。AWS CLIを使って以下のようにキャッシュを削除できます。

$ yarn build
$ aws s3 sync build s3://mywebsite-hosting
$ curl -I https://yourdomain.com/
...
x-cache: Hit from cloudfront
...
$ aws cloudfront list-distributions --output text --query 'DistributionList.Items[*].[Id]'
EKZEZML5DJ0UB
$ aws cloudfront get-distribution --output json --id EKZEZML5DJ0UB
$ aws cloudfront create-invalidation --distribution-id EKZEZML5DJ0UB --paths '/index.html'
$ aws cloudfront get-invalidation --distribution-id EKZEZML5DJ0UB --id IP17L4GZGHHAK --output text --query 'Invalidation.Status'
Completed
$ curl -I https://yourdomain.com/
...
x-cache: Miss from cloudfront
...

もちろんAWSのCloudFrontのコンソールからも同様の操作ができます。その場合は、「Create Invalidation」をクリックします。

Cf 31

そして、削除したい「Object Paths」を入力して、「Invalidate」をクリックします。

Cf 32

これでキャッシュクリアも完了です。

コンテンツを配信するドメインを指定する方法

画像や動画などのリンクは他のWebサイトに貼られても表示されてしまいます。それを防ぎたい場合は以下のようにS3バケットのポリシーにコンディションを指定することで、表示するドメインを限定できます。

{
"Version": "2012-10-17",
"Id": "Policy1530901313146",
"Statement": [
{
"Sid": "Stmt1530901311070",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mywebsite-hosting/*",
"Condition": {
"StringLike": {
"aws:Referer": "http://yourdomain.com/*"
}
}
}
]
}

S3とCloudFrontのCORSの対応方法

CORS(Cross-Origin Resource Sharing)はオリジンサーバ以外からデータを取得する仕組みですが、S3とCloudFrontの両方を利用している場合は両方共対応する必要があります。

S3のCORS対応

対象のS3バケットを選び、「Permissions -> CORS configuration」から、以下のようにXMLを設定し、「Save」すればOKです。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

S3 cors

CloudFrontのCORS対応

対象のDistributionを選んで、「Behaviors」タブからデフォルトのBehaviorを選んで「Edit」します。

Cf cors 1

「Cache Based on Selected」から「Whitelist」を選択します。

Cf cors 2

「Whitelist Headers」に「Origin」を選択して「Add >>」します。

Cf cors 3

後は保存して、変更が反映されれば完了です。

AWSコンソールを英語表記にする方法

この記事ではAWSコンソールは英語表記になっています。デフォルトでは日本語表記になっていると思うので、AWSコンソールのフッターから、「English (US)」を選択すれば英語表記にできます。

Aws footer

英語表記にするメリットは、日本語表記にした場合にAWSのUI変更についていくのが大変なのでそれを回避できる点と、何か問題があった時にググることを簡単にする点です。なので、よほど英語アレルギーがある人以外は英語表記にすることをおすすめします。

最後に

いかがでしたか？これでS3上に静的コンテンツを独自ドメインで公開できるようになったと思います。サーバーサイドを作らないのであれば、この方法で十分ですね。それでは。

環境

  • NodeJS: v10.5.0
  • create-react-app: 1.5.2
  • AWS CLI: aws-cli/1.15.40 Python/3.6.5 Darwin/17.6.0 botocore/1.10.40