Casual Developers Notes

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

You are here: Home / Archives for ec2

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 EC2インスタンスにSSHできなくなった時の対処法

Amazon EC2インスタンスにSSHできなくなった時の対処法

あれ？再起動したらEC2インスタンスにSSHできないぞ？今までSSHできていたのになぜだ？AWSでEC2インスタンスを作ったことがある人なら誰でも一度は経験する悲しい事件です。そうなったら選択肢は2 つ。諦めるか、原因を探るかです。今回は諦めない人に対処法を紹介します。

はじめに

今あなたの目の前には、こんなエラーがあることでしょう。

$ ssh -l ec2-user -i keypair.pem XX.XXX.XX.XXX
Enter passphrase for key 'keypair.pem':
ec2-user@XX.XXX.XX.XXX: Permission denied (publickey).

ログイン名かパブリックIPの入力間違いか？いや、違う。

キーペアかパスフレーズが間違っているのか？いいや、違う。

そんな凡ミスはさすがにしない。

そして、このブログに辿り着いたのならもう大丈夫です。EC2インスタンスを再起動したところ今までSSHできていたのにできなくなったという場合、原因は高い確率でauthorized_keysを誤って書き換えてしまったからです。なので、対処法は決まっています。この記事では、その場合の定石をお伝えします。

対処法

概要

やることは簡単です。SSHができなくなってしまった対象EC2インスタンスからボリュームを取り出し、別のEC2インスタンス(お助けEC2インスタンスと呼ぶことにしましょう)からボリューム内のファイルに問題がないか調べて、問題となっているファイルを修正するだけです。

対象EC2インスタンスを停止し、ボリュームをデタッチする

まずは、「EC2 -> インスタンス」から、対象EC2インスタンスを選択して停止します。

スクリーンショット 2018 02 07 23 11 58

停止した対象EC2インスタンスの「ルートデバイス」を選択します。この「EBS ID」をクリックすれば対象のボリュームのページに行きます。

スクリーンショット 2018 02 07 22 56 08

「EC2 -> ボリューム」から、対象のボリュームを選んで「アクション -> ボリュームのデタッチ」をします。

スクリーンショット 2018 02 07 22 37 09

これで、対象EC2インスタンスからボリュームが取り除かれました。

お助けEC2インスタンスにボリュームをアタッチする

次に、「EC2 -> ボリューム」から、先程取り除いたボリュームを選択して、「アクション -> ボリュームのアタッチ」をします。

スクリーンショット 2018 02 07 22 38 29

この時、「インスタンス」にお助けEC2インスタンスを選択し、「デバイス」の値をメモしておきます。デフォルトでは「/dev/sdf」になります。

スクリーンショット 2018 02 07 23 27 36

これでボリュームがお助けECインスタンスにアタッチされました。

お助けEC2インスタンスを起動してボリューム内の問題となっているファイルを修正する

それでは、いよいよ問題となっているファイルの確認と修正です。

お助けEC2インスタンスにログインしましょう。

$ ssh -l ec2-user -i keypair.pem YY.YYY.YY.YYY

ログインしたら、まずはアタッチしたボリュームをマウントします。アタッチ時のデバイスの値は「/dev/sdf」だったので、その情報から対象のボリュームを判断できます。マウント先はどこでもよいですが「/mnt/vol01」としておきます。

$  df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         488M   64K  488M    1% /dev
tmpfs            497M     0  497M    0% /dev/shm
/dev/xvda1       7.8G  1.1G  6.7G   14% /
$ ll /dev/ | grep sdf
lrwxrwxrwx 1 root root           4  2月  8 05:38 sdf -> xvdf
lrwxrwxrwx 1 root root           5  2月  8 05:38 sdf1 -> xvdf1
$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
└─xvdf1 202:81   0   8G  0 part
$ sudo mkdir /mnt/vol01
$ sudo mount /dev/xvdf1 /mnt/vol01
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         488M   64K  488M    1% /dev
tmpfs            497M     0  497M    0% /dev/shm
/dev/xvda1       7.8G  1.1G  6.7G   14% /
/dev/xvdf1       7.8G  1.2G  6.6G   15% /mnt/vol01

マウントが終わればボリュームにアクセスできますので、怪しいファイルを確認してみましょう。私の予想が確かならば、「authorized_keys」が犯人の可能性が高いです。確認して修正しましょう。

$ cd /mnt/vol01
$ cd /home/ec2-user/.ssh
$ vi authorized_keys

ファイルの修正作業が終わったら、ボリュームをアンマウントします。アンマウントが終わればログアウトして作業は終了です。

$ sudo umount /mnt/vol01
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         488M   64K  488M    1% /dev
tmpfs            497M     0  497M    0% /dev/shm
/dev/xvda1       7.8G  1.1G  6.7G   14% /
$ logout
Connection to XX.XXX.XX.XXX closed.

お助けEC2インスタンスからボリュームをデタッチする

対象EC2インスタンスからボリュームをデタッチした時と同じく、お助けEC2インスタンスからボリュームをデタッチします。お助けEC2インスタンスは起動しながらでもアタッチやデタッチは可能です。

対象EC2インスタンスにボリュームをアタッチして起動し、SSHできるか確認する

「EC2 -> ボリューム」から対象のボリュームを選択して、「アクション -> ボリュームのアタッチ」を選択します。この際に、デバイスの値を最初と同じ「/dev/xvda」にしてから、「アタッチ」します。

スクリーンショット 2018 02 07 22 55 24

ボリュームのアタッチが終わったら、対象EC2インスタンスを起動します。

スクリーンショット 2018 02 07 22 43 28

最後に、起動した対象EC2インスタンスにSSHで接続できれば、復旧成功です！

$ ssh -l ec2-user -i keypair.pem XX.XXX.XX.XXX
Enter passphrase for key 'keypair.pem':
Last login: Thu Feb  8 05:43:47 2018 from ZZZ.ZZZ.ZZZ.ZZZ
__|  __|_  )
_|  (     /   Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
1 package(s) needed for security, out of 1 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-2-11-115 ~]$

最後に

いかがでしたか？いきなりEC2インスタンスにアクセスできなくなると焦りますが、今回の方法で復旧できますので、慌てずに対処しましょう。

環境

  • EC2: Amazon Linux AMI