20200728のdockerに関する記事は15件です。

VultrでKUSANAGI Runs on Dockerが動くまで(その1)

前回のおさらい

前回の記事『VultrにDocker環境を作成する』でDockerとDocker-Composeの環境を作りました。今回はDocker上で超高速Wordpress環境であるKUSANAGIを動かしてみたいと思います。

はじめに

VPC環境でKUSANAGI Runs on Docker(以下KUSANAGI RoD)を動かします。使用するVPCはVultrですが他のVPCでもきっと大丈夫です。Vultrの初期セットアップは前回の記事『VultrにDocker環境を作成する』を参照してください。

はまった点

KUSANAGI RoDのインストール方法をググるとKAGOYAの記事『第6回 KUSANAGI Runs on Docker を使ってみた』が出てくるのですが、KUSANAGI RoDのDockerコンテナを新しくしようとするとエラーでまくりで動きません(泣)

公式サイト眺めながらまともに動くようになるまでを記事にしました。
https://kusanagi.tokyo/cloud/kusanagi-runs-on-docker/

動作環境など

  • Ubuntu 20.04
  • docker 19.03.12
  • docker-compose 1.26.2

DockerとDocker-Composeのインストールはこちらの記事『VultrにDocker環境を作成する』を参照してください。

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

$ docker --version
Docker version 19.03.12, build 48a66213fe

$ docker-compose --version
docker-compose version 1.26.2, build eefe0d31

想定している構成

複数のドメインでWordpressを運用したいのでHTTP/HTTPSの振り分けにリバプロとしてDockerコンテナのhttps-portalを使います。
https-portalを使うと簡単に複数サイトの振り分け+Let's Encrypt環境を作ることができますしお勧めです。

/home
  └$USER
        ├https-portal ← リバプロサーバー(マルチサイト& Let’s Encrypt対応)
        │ └docker-compose.yml
        │ 
        ├kusanagi01 ← KUSANAGI Runs on Docker(WordPressサイト1つ目)
        │ └docker-compose.yml
        │
        └kusanagi02 ← KUSANAGI Runs on Docker(WordPressサイト2つ目)
          └docker-compose.yml

KUSANAGI RoDのインストール

KUSANAGI RoDのインストール前にKUSANAGIの公式サイトを眺めておきましょう。
以下のようにコマンドを実行すると、KUSANAGI RoDが$HOME/.kusanagi 以下にインストールされます。

$ curl https://raw.githubusercontent.com/prime-strategy/kusanagi-docker/master/install.sh |bash

インストールが終わったらkusanagiコマンドを実行できるよう.bashrcの最後にPATHを追加しておきます。
kusanagiというアカウントの場合は以下のような感じです。

$HOME/.bashrc
PATH=/home/kusanagi/.kusanagi/bin:$PATH

KUSANAGI RoDのプロビジョニング

早速プロビジョニング(KUSANAGI RoDの環境を作成)してみます。$HOMEディレクトリでkusanagi-dockerコマンドを実行します。最低限、以下の引数だけは指定しておいたほうがあとあと楽です。

オプション 環境変数 説明
--fqdn(必須) FQDN 作成するサイトのドメイン名を指定します
--wp (なし) WordPressの環境を構築します
--wplang ja WordPressの言語を一つだけ指定します
--admin-user ユーザ名 WordPressの管理者ユーザ名を指定します
--admin-pass パスワード WordPressの管理者パスワードを指定します
--admin-email メールアドレス WordPressの管理者メールアドレスを指定します
--wp-title タイトル WordPressのタイトルを指定します
--kusanagi-pass KUSANAGIパスワード WordPressでの更新で使用するkusanagiユーザのパスワードを指定します
--dbname DB名 接続するDB名を指定します
--dbuser DBユーザ名 接続するDBユーザ名を指定します
--dbpass DBパスワード 接続するDBパスワードを指定します
--http-port HTTPポート番号 ホストにポートフォワードするhttpポート番号を指定します
--tls-port HTTPSポート番号 ホストにポートフォワードするhttpsポート番号を指定します
$ kusanagi-docker provision --wp --wplang=ja --admin-user=ユーザ名 --admin-pass=パスワード --admin-email=メールアドレス
 --wp-title=タイトル --kusanagi-pass=KUSANAGIパス --dbname=DB名 --dbuser=DBユーザ名 --dbpass=DBパスワード
 --http-port=8080 --tls-port=8443 --fqdn ドメイン名 インストールフォルダ名

$ ls -al $HOME/kusanagi01
total 64
drwxrwxr-x 7 kusanagi kusanagi 4096 Jul 26 17:52 .
drwxr-xr-x 8 kusanagi kusanagi 4096 Jul 24 00:45 ..
drwxr-xr-x 6 kusanagi kusanagi 4096 Jul 18 22:56 contents
-rw-rw-r-- 1 kusanagi kusanagi 2273 Jul 24 00:41 docker-compose.yml
drwxrwxr-x 8 kusanagi kusanagi 4096 Jul 18 22:56 .git
-rw-rw-r-- 1 kusanagi kusanagi   14 Jul 18 22:56 .gitignore
-rw-rw-r-- 1 kusanagi kusanagi  258 Jul 24 00:13 .kusanagi
-rw-rw-r-- 1 kusanagi kusanagi  100 Jul 18 22:54 .kusanagi.db
-rw-rw-r-- 1 kusanagi kusanagi  572 Jul 18 22:56 .kusanagi.httpd
-rw-rw-r-- 1 kusanagi kusanagi   46 Jul 18 22:54 .kusanagi.mail
-rw-rw-r-- 1 kusanagi kusanagi  259 Jul 18 22:54 .kusanagi.mysql
-rw-rw-r-- 1 kusanagi kusanagi  143 Jul 18 22:54 .kusanagi.php
-rw-rw-r-- 1 kusanagi kusanagi  194 Jul 18 22:54 .kusanagi.wp
drwxrwxr-x 2 kusanagi kusanagi 4096 Jul 18 22:54 wpcli

Dockerコンテナが5個起動してることが確認できます。

$ docker-compose ps
      Name                     Command                 State            Ports       
------------------------------------------------------------------------------------
kusanagi01_config   docker-entrypoint.sh wp -- ...   Restarting                     
kusanagi01_db       docker-entrypoint.sh mysqld      Up                             
kusanagi01_ftp      /bin/sh -c /docker-entrypo ...   Up                             
kusanagi01_httpd    /docker-entrypoint.sh /usr ...   Up           8080/tcp, 8443/tcp
kusanagi01_php      /usr/local/bin/docker-entr ...   Up      

上記手順ではWordpressのポートを意図的に80/TCP、443/TCPから変更しています。
ブラウザでWordpressのログイン画面にアクセスできたらOKです。
http://FQDN:8080/wp-login.php
https://FQDN:8443/wp-login.php

長くなってきたのでいったんおしまい。
『VultrでKUSANAGI Runs on Dockerが動くまで(その2)』に続きます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker×Laravel×Vue

開発で必要な記事をまとめていきます。
これを参考にして開発始める人の手助けになればいいなと思って
自分が参考にした記事をまとめていきます。

マルチログインの実装

参考記事
https://qiita.com/namizatop/items/5d56d96d4c255a0e3a87?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

それぞれ別々のディレクトリに分けてあげて判断。

認証に必要な要素を付け加える

https://qiita.com/sasakure-kei@github/items/388a2900557a6079164d

Laravel authで404 nginxが使えない時

https://qiita.com/isaatsu0131/items/f1eafe7522f0bf0ff043

nginxのファイル探索部分がおかしいらしい

Docker

起動中のコンテナ一覧

docker ps

Image起動

docker run -it IMAGE名 bash

Docker起動

https://qiita.com/A-Kira/items/1c55ef689c0f91420e81

Docker Laravel 実行

https://qiita.com/A-Kira/items/1c55ef689c0f91420e81

docker-compose down


docker-compose up -d

Docker 起動してもexitするとき

docker logs コンテナID

https://qiita.com/mom0tomo/items/35dfacb628df1bd3651e

Mysql bin/bashで起動

docker exec -it db-host bin/bash

Dockerのイメージ壊してテーブルのデータが消えた時

ERROR 1812 (HY000): Tablespace is missing for table `engineerMatching`.`companies`.

https://qiita.com/___uhu/items/74168be48c05638c7ac5

まず以下を実行する

ALTER TABLE example_table DISCARD TABLESPACE;

ALTER TABLE example_table IMPORT TABLESPACE;
復活!

Docker 全て終了させる

https://qiita.com/shisama/items/48e2eaf1dc356568b0d7

docker rmi $(docker images -q)

Docker再構築

https://qiita.com/shisama/items/48e2eaf1dc356568b0d7

Docker Mysql起動

起動時の初期設定参照URL

https://qiita.com/pugiemonn/items/b17288494e4b627f4475

docker exec -it db-host  bin/bash

のコマンドの際に

Error response from daemon: Container 5d83ac9a96ef971c5016b2a6559e75f43bfd71fa71909e89c3c04fd22ff89b94 is not running

と出たので

docker start 5d83ac9a96ef971c5016b2a6559e75f43bfd71fa71909e89c3c04fd22ff89b94

で普通に入れました。

自分の場合 DBのデータが入っているディレクトリごと消すとうまくいきました。
→これはおそらく最終手段なので本番環境でやると致命的になるので注意。

Tablespace is missing for table

https://qiita.com/___uhu/items/74168be48c05638c7ac5

Nginx 413 Request Entity Too Large

Nginxのconfファイルに

server{
    client_max_body_size 30M;
}

みたいに最大許容量を指定してあげれば対応可能です。

https://qiita.com/takecian/items/639deeae094466de6546

SPAの実装

非同期での認証

https://blog.capilano-fw.com/?p=3458

画面

https://giga-log.com/material-icons-use/

コンパイル時のエラー

there are multiple modules with names that only differ in casing” but modules referenced are identical
大文字小文字が入っている時に出るっぽい
https://stackoverflow.com/questions/47534267/webpack-there-are-multiple-modules-with-names-that-only-differ-in-casing-but?rq=1

Vue Router 404ERROR対処方法

ルーティング指定
https://sashimistudio.site/rails-vuerouter-history404/

https://blog.hirokiky.org/entry/2019/08/22/111031

解決してくれたもの
https://teratail.com/questions/121182

web.php
Route::get('/{any}',function(){
    return view('./company/home');
})->where('any','.*');

この記述で画面リロードしてもページ表示されるっす。
ルーティングの一番前に持ってきてあげる必要あり!!!!

開発時に使えそうなもの

ホットリロード
https://vue-loader-v14.vuejs.org/ja/features/hot-reload.html

変更すべきPHP.ini確認方法

echo $(php -r 'echo php_ini_loaded_file();')

読み込まれているファイルを確認できるコマンド

最大投稿可能サイズ確認

php -i|grep max

php.ini設定変更

post_maxこれをdockerファイルに記述してあげたところ成功

RUN echo "file_uploads = On\n" \
         "memory_limit = 500M\n" \
         "upload_max_filesize = 500M\n" \
         "post_max_size = 500M\n" \
         "max_execution_time = 600\n" \
         > /usr/local/etc/php/conf.d/uploads.ini

https://web-memo-s.hatenablog.com/entry/2019/02/21/182815

さくらサーバにデプロイ

非常に感謝しています。簡潔でわかりやすい。

https://arrown-blog.com/laravel-sakura-deploy/

デプロイ時に Class 'Collective\Html\HtmlServiceProvider' not found

composerのアップデートしていないのが原因
https://stackoverflow.com/questions/54675520/composer-update-the-requested-php-extension-ext-http-missing

Class 'Egulias\EmailValidator\Validation\RFCValidation' not found

https://laracasts.com/discuss/channels/laravel/eguliasemailvalidatoremailvalidator-does-not-exist

同様に困ってる方の質問で
```
rm -rf vendor/*

の後に

composer install --no-dev
```

で万事解決!!

メールが文字化けする。。。

スクリーンショット 2020-06-29 1.22.52.png

右下の文字をUTF-8にしてあげることで解決。。

2hかかった。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

東京大学計数工学科講義「AWSによるクラウド入門」をやってみた

東京大学計数工学科で開講されている講義資料「AWSによるクラウド入門」が公開されており、AWSの基礎だけでなく、機械学習やサーバレスなどもHands-Onを通じて学べるということで、早速実施してみました。

クラウド入門者向けに簡潔かつ平易な言葉で書かれており、大変勉強になりました。飽き性の私でも最後まで楽しんでできました。

かかった時間と費用

・一通り解説を流し読み、Hands-Onも全て実行して、約4時間
・費用は、0.49ドル

cost.png

学べること

大きく以下3点です。気になるキーワードがあれば、そこだけ掻い摘むのも良いのではないかと思います。

クラウドの基礎

・クラウドの基礎となる概念・知識
・セキュリティやネットワークなど,クラウドを利用する上で最低限おさえなければいけないポイント理解
・ハンズオン:仮想サーバーをAWSに立ち上げる
・キーワード:AWS CLI、AWS CDK、CloudFormation、VPC、EC2、Security Group

クラウドで行う機械学習

・クラウド上で機械学習を走らせるための入門となる知識・技術
・Docker に自分のプログラムをパッケージングする手順
・ハンズオン1:AWSでJupyter notebookを使って簡単な機械学習の計算を走らせる
・ハンズオン2:ディープラーニングを用いた自然言語処理により,質問に自動で回答を生成するボットを作成
・キーワード:GPU、DLAMI、Jupyter notebook、PyTorch、MNIST、Docker、Elastic Container Service (ECS)、Fargate、Transformer

Serverless Architecture

・Serverless architectureと呼ばれる最新のクラウドのアーキテクチャを解説
・ハンズオン1:簡単なデータベースをクラウド上に作成
・ハンズオン2:俳句を投稿するSNS "Bashoutter" 作成
・キーワード:REST API、Lamba、S3、DynamoDB、API Gateway、Simple Notification Service、Step Functions

おわりに

1点だけ、詰まったというか、記載通りにならなかった箇所がありましたので、備忘録的に残しておきます。

「6.3. スタックのデプロイ」で、GPU搭載の仮想マシンを立ち上げようとすると、以下のようなエラーとなりました。

| CREATE_FAILED        | AWS::EC2::Instance                    | Ec2ForDlInstanceF0415522
You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance buck
et that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-re

対処法は、エラーメッセージにもありますが、立ち上げられるvCPUの制限が初期値だと0なので、その上限を上げてもらう必要があります。

以下のように、制限緩和のリクエストを投げれば、10分ほどで作業完了の連絡がありました。その後、再度デプロイすれば、うまく行きます。

image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerコンテナ上で動作するアリババクラウドコンテナサービスのアプリケーション環境の構築

このチュートリアルでは、Alibaba Cloudのコンテナサービスを使ってDockerコンテナクラスタを作成する方法を紹介します。

アリババクラウドのコンテナサービスとは?

Alibaba Cloudのコンテナサービスは、スケーラブルで高性能なコンテナ管理製品で、Docker SwarmまたはKubernetesのいずれかを使用してコンテナ化されたアプリケーションのライフサイクルをオーケストレーションして管理することができます。Container Serviceには、Pay-As-You-Goでインストールされるサーバーロードバランサーが自動的に組み込まれています。

Alibaba Cloudのコンテナサービスは、継続的インテグレーションを含む複数のアプリケーションリリース方法を提供し、マイクロサービスアーキテクチャもサポートしています。アリババクラウドの仮想化、ストレージ、ネットワーク、セキュリティサービスと統合されたコンテナクラスタ用のシンプルなユーザーインターフェースのコンソール設定を提供することで、アリババクラウドのコンテナサービスは、コンテナ化されたアプリケーション環境の実行、管理、監視に最適なクラウド環境となっています。

Docker Swarmとは?

Dockerはオープンソースの仮想化管理ツールで、コンテナ内で動作するアプリケーションやアプリケーションのコレクションを開発、デプロイ、管理、監視することができます。このプロセスはコンテナ化として知られています。Docker Swarmは、複数のスケーラブルなDockerコンテナ上で動作するこのようなシステムや環境のためのクラスタリング、スケジューリング、オーケストレーションツールです。

Dockerコンテナは、コード、ランタイム、ライブラリ、環境変数、設定ファイルなど、アプリケーション全体の実行に必要なすべてを含む実行可能パッケージであるDockerイメージを実行することで起動されます。コンテナはDockerイメージのランタイムインスタンスです。

同じインスタンス上で複数のコンテナを同時に実行したり、インスタンスのDocker Swarmクラスタ上で実行したりすることができます。実行中のコンテナは、オペレーティングシステムのハイパーバイザーの代わりにDockerによって管理されます。Dockerはハイパーバイザーとは異なり、クラスタノードの1つ以上に問題が発生した場合に冗長性とフェイルオーバーを提供します。

Dockerは軽量で効率的で、複数のアプリケーションイメージで構築された複雑なシステムを管理することができます。ローカルにDockerコンテナを構築することも、クラウドにデプロイすることもできます。

Dockerは、1つのAlibaba Cloud ECSインスタンス上で簡単にセットアップ、インストール、実行することができます。業界レベルのアプリケーションやシステムを実行する大規模なコンテナ化環境には、信頼性と拡張性に優れたオーケストレーションと監視システムが必要です。Alibaba Cloudのコンテナサービスは、システム管理者やDevOpsチームに、大規模なコンテナ化環境を管理するために必要な広大なクラスタ化アーキテクチャを提供します。

なぜクラスターが必要なのか?

Alibaba CloudのコンテナサービスDocker Swarmオプションを使用して実行中のDockerコンテナのスイートをインストールする前に、コンテナ化されたシステムを実装するためのAlibaba Cloud Container Service Docker Swarmクラスタを準備して利用できるようにしておく必要があります。

前回のチュートリアルでは、Alibaba Cloudのコンテナサービスでコンテナ化環境を実行するためのDocker Swarmクラスタを簡単にセットアップする方法を紹介しました。このチュートリアルでは、同じ稼働中のクラスタを使用してアプリケーション環境を構築します。イメージから構築したWebサーバーとオーケストレーションテンプレートから構築したWebアプリケーションで環境を構築します。

アリババクラウドのコンテナサービスクラスタが稼働しているかどうかを確認する

まず、Docker Swarmクラスタが稼働していることを確認しましょう。Alibaba CloudアカウントのContainer Serviceコンソールページに向かいます。

image.png

コンテナサービスのコンソールページに到着します。

左側メニューのClusterオプションをクリックする前に、Container Service - Swarmオプションが選択されていることを確認してください。

問題がなければ、健全な状態の Running cluster が表示されているはずです。

image.png

Docker Swarmコンテナサービスアプリケーションの作成

「Application」メニューオプションに移動し、「Create Applicatio」をクリックします。

image.png

基本オプションで、アプリケーションの名前とバージョン番号(デフォルトは1.0)を追加し、アプリケーションに使用するクラスタを選択します(ここでは、実行中のクラスタが1つしかないので、これがデフォルトになっています)。

標準リリースでは、新しいバージョンをデプロイする前に、以前のバージョンのアプリケーションを削除します。このチュートリアルではこれで十分です。青緑色のリリースは、更新時に中断することなく実行し続ける必要があるアプリケーションのためのアクティブ・スタンバイ・オプションです。

Dockerイメージを引っ張ってコンテナを作成する

アプリケーションの説明を追加し、Pull Docker Imageオプションを選択します。

image.png

ここで「Create with Image」をクリックします。

image.png

設定オプションに進みます。一般的な設定で、[Select Image] をクリックします。

image.png

nginxオプションを選択し、OKをクリックします。

image.png

最新のDockerイメージのバージョンは、デフォルトでリモートのDockerリポジトリから引っ張ってきます。

これで右側のCreateをクリックすることができるようになりました。

image.png

アプリケーションが作成されていることを確認する画面が表示されます。

image.png

これで、アプリケーションとサービスの両方のメニューに nginx アプリケーションが表示されるようになりました。

image.png

image.png

「Applications」メニューで、nginxを実行しているアプリケーションをクリックします。

image.png

Updateをクリックします。

image.png

これで、ネットワークの設定を行います。

HTTP/HTTPS 80と443のポートマッピングの詳細と、コンテナポートを追加します。

image.png

ここで「Update」をクリックします。

image.png

アプリケーションが作成され、最終的には実行中の状態に落ち着くのがわかります。

アプリケーションメニューオプションをクリックします。

image.png

クリックすると応募の詳細が表示されます。

image.png

このビューでは、いくつかのタブが表示されます。[サービス] タブには、アプリケーションの状態が表示されます。

コンテナ] タブをクリックします。このビューには、すべての VPC ネットワーク ポート設定、コンテナの IP、ノードの IP が表示されます。また、コンテナを監視するオプションもあります。

image.png

名前のリンクをクリックします。

image.png

コンテナのCPU、メモリ、IO、プロセスの使用率など、多くのグラフが表示されます。

ここでログタブをクリックします。

image.png

ここでは、コンテナのログが表示されます。今すぐイベントをクリックします。

image.png

このオプションを選択すると、コンテナ上のイベントのリストが表示されます。ここで、[ルート] タブをクリックします。

image.png

ここにコンテナのエンドポイントが表示されます。先に進み、リンクをクリックしてください。

image.png

nginx コンテナが正しく設定され、実行されていることが確認できるはずです。

image.png

オーケストレーションテンプレートでコンテナを作成する

それでは、同じクラスタ上でWordPressとnginxを統合してみましょう。

今回はオーケストレーションテンプレートを使用します。コンテナサービスコンソールに戻り、アプリケーションをクリックします。正しいクラスタ上にあることを確認し(まだクラスタは1つだけです)、「アプリケーションの作成」をクリックします。

image.png

手順は先ほどと全く同じですが、「Create with Image」をクリックする代わりに「Create with Orchestration Template」をクリックします。ここではDocker Imageオプションは非選択のままにしておきます。

image.png

Dockerのエコスフィアに慣れている方は、ここでDockerのコンポーズファイルを実行します。Use Existing Orchestration Templateをクリックします。

image.png

WordPressを選択してみましょう。

image.png

ご覧のように、コンソールには関連するDocker composeコマンドと設定が表示されます。

image.png

今すぐ設定の一つを編集する必要があります。

image.png

この設定変更により、テストドメインのURLからaliyunポート80へのリクエストはすべてWordPressにルーティングされるようになります。

image.png

ここで「Create and Destroy」をクリックします。

image.png

アプリケーションが起動しているのが表示されます。アプリケーションメニューをクリックすると、WordPressが作成されているのが表示されます。

アプリケーションが作成されると、実行中の状態で表示されます。クリックしてアプリケーションに進みます。

image.png

先ほどと同じように、いくつかのタブが表示されています。WordPressを動かすにはデータベースとWebアプリケーションが必要なので、2つのタブがあります。コンテナタブをクリックします。

image.png

コンテナタブには、アプリケーションが必要とするすべての異なる実行中のDockerコンテナの詳細が表示されます。

image.png

ログとイベントタブには、先ほどと同じように詳細が表示されます。Routesをクリックすると、アプリケーションの設定に必要なWordPressエンドポイントのURLが表示されます。

先に進み、エンドポイントをクリックします。

image.png

これで、先ほど設定したnginxウェブサーバ上で動作するWordPressサイトを設定することができます。

image.png

概要

まず、コンテナ化環境を構築する準備として、すでにAlibaba Cloud Container ServiceのDocker Swarmクラスタを構築しており、正常に動作していることを確認している様子を説明しました。

次に、Alibaba Cloud Container Serviceの製品について説明し、SwarmとKubernetesの両方のコンテナ化環境でどのように利用できるのかを説明しました。また、これらの製品がどのようにクラスタを必要としているか、Alibaba CloudがElastic Compute Services (ECS)から構築されたクラスタを自動セットアップし、自動セットアップの一部としてServer Load Balancerを含める方法を説明しました。

次に、Alibaba CloudのDocker Swarm Containerize Serviceを構築する方法を紹介しました。その後、Orchestration Templateを使ってWordPressのイメージをプルダウンすることで、開発者の柔軟性を高めることができました。

Alibaba Cloudが提供している他の製品やサービスもぜひチェックしてみてください。
https://www.alibabacloud.com/contact-sales

アリババクラウドは日本に2つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker: AWSから完全にuninstall

1 dockerが作成したnetworkを削除

docker network prune

2 pre-definedのnetworkも削除

service docker stop
vim /etc/docker/daemon.json

daemon.json
{
  "bridge": "none"
}

vim service start docker

3 uninstall

sudo yum remove docker docker-common docker-selinux docker-engine

4 設定ファイルの削除

rm -rf /etc/docker

5 imageの削除

rm -rf /var/lib/docker

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerのコンテナを消しても、中のファイルを維持する方法

「Dockerあんまり触ったことなかったけど、これからはDockerで開発環境を整えよう」と思ったときに気になったこと。

コンテナの中にあるデータを独立させるにはどうしたらいいんだ?

マウントする(-v)

手順は
自分のローカル環境上にディレクトリを作り、その中にファイルを入れる
そのディレクトリをマウントして、コンテナを起動する
以上

これでローカルにあるファイルをコンテナで起動してみることができる
これをバインドマウントと呼び、作業ディレクトリを即座にコンテナから参照することができる。

もう一つの手順が
docker volume createを使ってDocker Engineのなかにボリューム(データを保存する場所)を作成sる
以上

これでDockerEngineの中にデータを入れて保存することができる。
MySQLなどのコンテナを起動して、このボリュームをマウントして使う。
ボリュームマウントとよびこちらが公式では推奨されている。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerコンテナの並列化 - Docker Composeのための実践的な演習その5

このチュートリアルでは、Alibaba Cloud上でコンテナを扱う際にDocker Composeを使用して実践的な経験を積むことに焦点を当てています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

Deploy: update_config: parallelism

並列処理は、サービスの更新をどのくらいの速さで行うかを設定します。新しく起動されたコンテナは、できるだけ早く起動されます。新しいコンテナはこの update_config 設定を使用しません。

したがって、これでテストするには、UPDATEの並列処理を観察できるように、すでに実行されているコンテナのセットが必要です。

まず、parallelism = 1 (デフォルト)とします。

docker-compose.ymlに以下のように追加します。

nano docker-compose.yml  
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 600

    deploy:
      replicas: 6

      update_config:
        parallelism: 1

実行します。

docker stack rm mystack
docker stack deploy -c docker-compose.yml  mystack
docker ps -a

そして約3秒後には、6つのコンテナが実行されるようになりました。この最初に実行した docker stack deploy は並列化オプションを無視しています。

残念ながら、docker stack deployを再実行しても、並列化オプションは動作していません。Dockerはあまりにも賢いので、docker-compose.ymlファイルを読み込んで、何も変更されていないことを確認し、mystack内のコンテナを更新しません。

これを証明するために、別のコンソールコマンドセッションを起動して、docker eventsを実行してみましょう。

元のシェルに戻り、3回実行します。

docker stack deploy -c docker-compose.yml  mystack

他のコンソール出力を観察してください。

期待される出力 .

2018-11-08T12:48:34.385699607+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)
2018-11-08T12:48:37.423780596+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)
2018-11-08T12:48:39.804717121+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)

サービスは3回に分けて更新されますが、停止することもなければ新鮮なコンテナを起動することもありません。

そのため、強制的に更新するには docker-compose.yml に変更を加える必要があります。

最も簡単な変更:ちょうどsleep600の後ろに数字を追加します。

これを実行します。

docker stack deploy -c docker-compose.yml  mystack

ここには表示されていませんが、他のコンソール出力を観察してみてください。

新しいコンテナが作成され、古いコンテナが削除されています。

docker ps -a を実行すると、上部に新しいコンテナが表示され、下に終了したものが表示されます。sleepを6001に変更したことがわかります。

 CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
bafa8e4e1d62        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.5.mtw5rzfpyd6dwnh9mez7p7hlk
a80b531eff59        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.6.nl9culv3otymevgjufamkkwld
fa45c52b0825        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.1.oe2d85c55uf1qlbvv1pozcsgx
2565cfbda1db        alpine:3.8          "sleep 6001"        21 seconds ago      Up 5 seconds                                     mystack_alpine.4.5zaqrvwv32ou8vmdvnbu21qtn
b69ceeaf69a1        alpine:3.8          "sleep 6001"        21 seconds ago      Up 5 seconds                                     mystack_alpine.2.utc38k1pg124zx65ae1s8qo5g
9669904d0bb1        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.3.zbltrdwmk0omxtkywuwhlw9ub
dc8566cc12ae        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.3.bi13jj6v7f2s3b31yc6k9dmf0
9d385bfd3565        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.6.g8w5a0fe0ufcum2y2lhd0i1dq
58f14d78f436        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.1.zotzhrpqblzzyo62urafwgzcs
2090bb37bb31        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.2.loezk57p62tkfohgzbh1tc1j8
c8df0b31e188        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.4.619ms1rkhar35un6x4g5ulc3h
c85a0f2db1e0        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.5.odw21g73i1p62s90lpj1936xv

私たちはコンテナの更新が起こっているのを目撃しただけです。しかし、チュートリアルのこの部分の目的は、並列処理がどのように動作するかを示すことです。

他のコンソールで前のdocker eventsコマンドを停止し、これを入力します。

docker events  --filter event=create  --filter event=kill

docker-compose.ymlのスリープ時間を任意の桁数に変更します。

再実行:

docker stack deploy -c docker-compose.yml  mystack

最初のコンソールでdocker ps -aを繰り返し実行します。数分後に更新処理が完了します。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                            PORTS               NAMES
84da4828fea3        alpine:3.8          "sleep 6002"        3 seconds ago        Created                                               mystack_alpine.4.ludkp9e9ec63tf27n05j2h8rt
99d63687086c        alpine:3.8          "sleep 6002"        18 seconds ago       Up 3 seconds                                          mystack_alpine.1.zbfm2q2403wg5f0626dlodab4
5d4ac8f2ae15        alpine:3.8          "sleep 6002"        32 seconds ago       Up 17 seconds                                         mystack_alpine.5.oadzbajbcr6l1rms28kb23xux
350971f0734e        alpine:3.8          "sleep 6002"        47 seconds ago       Up 32 seconds                                         mystack_alpine.2.lxggijot4518tj0xl3bi36eay
95f6fcc3c898        alpine:3.8          "sleep 6002"        About a minute ago   Up 46 seconds                                         mystack_alpine.6.qgje7g5r7e7e24neuqiafip0g
960174cdab88        alpine:3.8          "sleep 6002"        About a minute ago   Up About a minute                                     mystack_alpine.3.v9zm2yipmvjzb673da8sbryh1

10-15秒ごとに約1つの新しいコンテナを取得します。これは並列処理 = 1 の場合に得られるものです。

2つ目のコンソール出力を見てみましょう: docker events

ご覧の通りです。1つの新しいコンテナが作成され、1つの古いコンテナが削除されました。

この更新処理を高速化するために、docker-compose.yml の並列処理を 3 に上げてみましょう。

nano docker-compose.yml

並列処理:3

再実行:

docker stack deploy -c docker-compose.yml  mystack

docker ps -aを実行すると、上に新しいコンテナが、下に退避したコンテナが表示されます。sleepを6003に変更したのを見てください。

すぐに上部に3つのコンテナが作成され、15秒後に残りの3つが作成されているのがわかります。

このように、完璧な理想は6つの並列性であることは間違いありません。6個すべてを一度に更新します。

残念ながら、これはそうではありません。更新に失敗した場合、6つの新しいコンテナが失敗し、6つの以前の完璧に動作していたコンテナがすべて終了してしまいます。

幸いなことに、max_failure_ratio と failure_action はこのような問題に対処します。このトピックについては次のセクションで詳しく説明します。

Deploy:update_config:failure_ratioとfailure_action

この2つの設定を利用することで、更新に失敗したことによるダメージを軽減することができます。

failure_ratio specifies which percent failure to tolerate: Syntax: 0.1 means 10 percent.
failure_action: Specifies what to do if an update fails. continue, rollback, or pause (default: pause).

今はまだ以前のコンテナが稼働しています。このコンテナを 6 つの新しいコンテナに更新して、それぞれがすぐに失敗するようにします。

docker-compose.yml に以下を追加します。

nano docker-compose.yml  
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: exit 1

    deploy:
      replicas: 6

      update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: pause

コマンドは exit 1 - エラー応答コード 1 のexitであることを意味しています。

デフォルトのfailure_actionはpauseですが、ここでは含めています。

他のコンソールコマンドセッションを使って、docker eventsを実行してください。

これらの失敗したコンテナをデプロイします。

docker stack deploy -c docker-compose.yml  mystack

docker ps -a -aを実行すると、30秒後くらいにこのように表示されます。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
cbcaf8fce479        alpine:3.8          "exit 1"            6 seconds ago       Created                                 mystack_alpine.2.zvk1x6hevpt3x0q6aha0616sx
3ce0f3bca6c8        alpine:3.8          "exit 1"            12 seconds ago      Created                                 mystack_alpine.2.hyikxli7cwuk0xauaqw87epu0
4ae02b292f54        alpine:3.8          "exit 1"            18 seconds ago      Created                                 mystack_alpine.2.lseuovn0g4imn75q1eufnyfx9
1ea70f30f397        alpine:3.8          "exit 1"            24 seconds ago      Created                                 mystack_alpine.2.tfwagwvevh9vdxyne7cfy41fa
2eeef13d4240        alpine:3.8          "exit 1"            30 seconds ago      Created                                 mystack_alpine.2.n5qny1d5sbwah7fgsa83eabat
b926e22199d1        alpine:3.8          "sleep 6003"        21 minutes ago      Up 20 minutes                           mystack_alpine.5.w3ll2y30r1b75137fbbqak1rf
248f8ffe019e        alpine:3.8          "sleep 6003"        21 minutes ago      Up 20 minutes                           mystack_alpine.1.62dpe6cgrtmkercmn2bdlo3j3
815143b43f11        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.4.enk3mweaht4zqre0jehm2nyn1
c13461b6f58c        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.3.9jfg8kc1l0ps6km6hv5wlzddc
f2dc173cbf21        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.6.8mo8t73z58jbf1e9vhvzjup53

リストの一番上に6つの新しいコンテナが作成されていますが、その下には6つの古いコンテナがまだ動いています。しかし、新しいコンテナは実行されていないので、作成された状態になっているだけです。

イベントコンソールを観察してみてください - Dockerは、これらの新しいコンテナを「実行中」にするために、継続的に破棄して再作成しています。明らかにpauseでは一時停止しません。

それらのコンテナをすべてクリーンアップします: ( prune はスタック rm が見逃したコンテナを削除します。それは残念ながら頻繁に起こります。)

docker stack rm mystack
docker container prune -f

Pauseが思ったように動作しません。failure_action: rollbackをテストしてみましょう。

failure_action: のロールバックをテストするためには、新しく始める必要があります。

1、6つの作業コンテナを作成します。
2、6つのexit = 1エラーコンテナを含むdocker-compose.ymlを作成します。
3、失敗のアクションをロールバックに設定します。
4、デプロイスタックを実行して結果を観察します。
次を使用してdocker-compose.ymlに追加します。

nano docker-compose.yml 
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 600

    deploy:
      replicas: 6

作業コンテナをデプロイします。

docker stack deploy -c docker-compose.yml  mystack

6つのエラーコンテナを作成します。以下を docker-compose.yml に追加します。

nano docker-compose.yml 
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: exit 1

    deploy:
      replicas: 6

      update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: rollback

エラーコンテナを展開します。

docker stack deploy -c docker-compose.yml  mystack      

結果を観察する: docker ps -a を 30 秒程度繰り返し実行します。

最初の3つのコンテナを注意深く観察して、何が起こっているかを判断できるかどうかを確認します。

docker ps -a

最終的な結果はこんな感じです。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS               NAMES
c2d1ae806906        alpine:3.8          "sleep 600"         25 seconds ago      Up 22 seconds                                     mystack_alpine.2.soht49wefpwm1nvm1gbl7ru1l
455a5907758a        alpine:3.8          "exit 1"            40 seconds ago      Created                                           mystack_alpine.2.yr0zkfu9n40s0rbezfhjtl6yu
3c254ba9a72b        alpine:3.8          "sleep 600"         2 minutes ago       Exited (137) 26 seconds ago                       mystack_alpine.2.04g1vrnoomagvv89aobbbzmxz
b635a1e52147        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.1.gibfdph75s0o46s5h3x96csm2
0ac32ac0ad34        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.3.oxs3mjm7vp3c6jbc1kj2kz990
33554d287fe9        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.5.ds3lra1qvr9y8e8b1xi2cn5c0
f381b1250167        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.4.t4gv1gor6aul3b53ei6pcxu5e
fd97395ba2ac        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.6.n1nshrlnywqcrvn5u2x93nr10

まず、新しいコンテナを作成します。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
455a5907758a        alpine:3.8          "exit 1"            7 seconds ago        Created                                 mystack_alpine.2.yr0zkfu9n40s0rbezfhjtl6yu

5秒後くらいに1つの古いコンテナが出てきます。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                       PORTS               NAMES
3c254ba9a72b        alpine:3.8          "sleep 600"         About a minute ago   Exited (137)

そして、Dockerは新しいコンテナが実行状態に移行できないと判断したので、docker-compose.ymlで以前の設定でコンテナを再作成/ロールバックします。

このコンテナは一番上の方に表示されています。ステータスを参照してください: up 22 seconds; it is working.

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS               NAMES
c2d1ae806906        alpine:3.8          "sleep 600"         25 seconds ago      Up 22 seconds                                     mystack_alpine.2.soht49wefpwm1nvm1gbl7ru1l

ゆっくりと出力をスクロールして、コンピュータで同じことが起こったかどうかを確認してください。

ロールバックは素晴らしい働きをします。

結論:以下の設定は本番では便利です。

1、一度に1つのコンテナだけをアップデートします。
2、障害を許容しません。
3、失敗時、ロールバックします。

    update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: rollback         

Deploy: update_config: monitor

https://docs.docker.com/compose/compose-file/#update_config より

monitor:各タスク更新後に障害を監視する時間(ns|us|ms|s|m|h) (デフォルトは0s)。

ここでは演習はありませんが、この設定は重要です。

先ほど読んだように、コンテナの更新後に障害を監視するための時間です。

コンテナ内のアプリケーションは、Dockerが障害の有無をテストする前に十分な時間を持っていなければなりません。

デフォルトの継続時間の値である0秒は、実用的な目的には適していません。これは、コンテナが正常に起動することを確認するためにのみ有用です。

コンテナ内でWebサーバーを稼働させているとしましょう。さらに、1分間に1回のWebサイト訪問を想定してみましょう。そのため、モニターの設定を1分にするのは、おそらく頻度が高すぎるでしょう。その代わりに、少なくとも 5 分間に設定して、障害のテストをする前にクラッシュする機会を与えることができます。

あなたの職場のアプリケーションに適したモニター持続時間の値を決定する必要があります。

ヘルスチェックは、質問をするのと似ています。「can I ping it?」

これらの監視は、コンテナ全体がクラッシュするかどうかをテストします。これらのテストは、コンテナ内のアプリケーションが他のコンテナと連携しなければならない状況下でも動作するかどうかをテストします。

例えば、新しいApacheのバージョンをデプロイしたものの、必要なモジュールをすべてロードすることができない場合、ヘルスチェックのpingやテキストhtmlページのwgetsは完璧に動作しますが、php + Mysqlページを提供する必要がある瞬間にクラッシュしてしまいます。

そのため、新しく更新されたコンテナ内のアプリケーションを実行するのに十分な時間を与えてから、Dockerが失敗をテストできるようにしなければなりません。

私たちは、接続性だけでなく機能性もテストするヘルスチェックを開発したいと考えています。

そのようなヘルスチェックは、数秒以内に新しいコンテナが不健全であることを示すことができ、実際の本番の作業を処理できるようになる(そして失敗する)数分前になります。

並行処理実験の出力

以下は、様々な並列処理の設定を試して集めたdockerのイベント出力です。( /tmp にイベントを出力し、その後そのファイルを操作しました)

2本のkillラインは、1つのコンテナ用です:signal 15、十分にすぐに死んでいない場合:signal9を送信します。

並行処理: 1

   cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:01:35.148583578+02:00 container create 8b51499
    2018-11-03T10:01:37.840231366+02:00 container kill be8f3715a
    2018-11-03T10:01:37.865611953+02:00 container kill be8f3715a
    2018-11-03T10:01:39.886188372+02:00 container create a38781a
    2018-11-03T10:01:42.572866743+02:00 container kill e498e5f5f
    2018-11-03T10:01:42.598606635+02:00 container kill e498e5f5f
    2018-11-03T10:01:44.423905486+02:00 container create 64ae4c0
    2018-11-03T10:01:47.123993008+02:00 container kill 914343611
    2018-11-03T10:01:47.146988704+02:00 container kill 914343611
    2018-11-03T10:01:48.972005129+02:00 container create b37cef5
    2018-11-03T10:01:51.642712373+02:00 container kill 92619e0a6
    2018-11-03T10:01:51.667003244+02:00 container kill 92619e0a6
    2018-11-03T10:01:53.497100262+02:00 container create 8a73470
    2018-11-03T10:01:56.163374613+02:00 container kill 420dc4d89
    2018-11-03T10:01:56.188237090+02:00 container kill 420dc4d89
    2018-11-03T10:01:58.000843644+02:00 container create 41b4480
    2018-11-03T10:02:00.699576981+02:00 container kill c8f4d973c
    2018-11-03T10:02:00.721565297+02:00 container kill c8f4d973

並行処理:2

cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:08:47.299682233+02:00 container create 6f1df52
    2018-11-03T10:08:47.567222566+02:00 container create ea9bf95
    2018-11-03T10:08:49.943237084+02:00 container kill 8b51499ad
    2018-11-03T10:08:49.958679991+02:00 container kill 64ae4c05c
    2018-11-03T10:08:49.977677725+02:00 container kill 8b51499ad
    2018-11-03T10:08:49.997521920+02:00 container kill 64ae4c05c
    2018-11-03T10:08:52.539334772+02:00 container create cdbbef8
    2018-11-03T10:08:52.812900162+02:00 container create 16e1af2
    2018-11-03T10:08:55.157361545+02:00 container kill b37cef51e
    2018-11-03T10:08:55.169221551+02:00 container kill 8a73470b2
    2018-11-03T10:08:55.193477357+02:00 container kill b37cef51e
    2018-11-03T10:08:55.207277169+02:00 container kill 8a73470b2
    2018-11-03T10:08:57.830146930+02:00 container create 0ab17e5
    2018-11-03T10:08:57.949710902+02:00 container create 9cc8547
    2018-11-03T10:09:00.233887111+02:00 container kill a38781a0f
    2018-11-03T10:09:00.257647812+02:00 container kill 41b4480ad
    2018-11-03T10:09:00.272834309+02:00 container kill a38781a0f
    2018-11-03T10:09:00.288598877+02:00 container kill 41b4480ad

並行処理:3

    cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:11:34.283896923+02:00 container create 8a0373b
    2018-11-03T10:11:34.583536405+02:00 container create 61cbe75
    2018-11-03T10:11:34.803563295+02:00 container create a2bd707
    2018-11-03T10:11:36.854815108+02:00 container kill cdbbef891
    2018-11-03T10:11:36.861978752+02:00 container kill 0ab17e57f
    2018-11-03T10:11:36.890035520+02:00 container kill ea9bf9502
    2018-11-03T10:11:36.899725135+02:00 container kill cdbbef891
    2018-11-03T10:11:36.905718703+02:00 container kill 0ab17e57f
    2018-11-03T10:11:36.922317316+02:00 container kill ea9bf9502
    2018-11-03T10:11:39.891013146+02:00 container create 7576427
    2018-11-03T10:11:40.238136177+02:00 container create a26d947
    2018-11-03T10:11:40.439589543+02:00 container create 53002e5
    2018-11-03T10:11:42.434787914+02:00 container kill 16e1af20f
    2018-11-03T10:11:42.445537379+02:00 container kill 9cc854731
    2018-11-03T10:11:42.485085063+02:00 container kill 9cc854731
    2018-11-03T10:11:42.490162686+02:00 container kill 16e1af20f
    2018-11-03T10:11:42.498272764+02:00 container kill 6f1df5233
    2018-11-03T10:11:42.547462663+02:00 container kill 6f1df523

並行処理:6

   cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:13:22.444286947+02:00 container create bb4b2db
    2018-11-03T10:13:22.838989116+02:00 container create a00d0b1
    2018-11-03T10:13:23.039740661+02:00 container create f1f9090
    2018-11-03T10:13:23.595395816+02:00 container create 568b219
    2018-11-03T10:13:23.824193225+02:00 container create 77d7d22
    2018-11-03T10:13:24.191986311+02:00 container create 1ea8ad8
    2018-11-03T10:13:25.105183046+02:00 container kill 8a0373b67
    2018-11-03T10:13:25.146410226+02:00 container kill 8a0373b67
    2018-11-03T10:13:25.150991208+02:00 container kill 53002e5b3
    2018-11-03T10:13:25.190384877+02:00 container kill 75764275f
    2018-11-03T10:13:25.204178523+02:00 container kill a2bd707bc
    2018-11-03T10:13:25.230797581+02:00 container kill a26d9476c
    2018-11-03T10:13:25.234104353+02:00 container kill 61cbe7540
    2018-11-03T10:13:25.252980697+02:00 container kill 53002e5b3
    2018-11-03T10:13:25.268581894+02:00 container kill 75764275f
    2018-11-03T10:13:25.283548856+02:00 container kill a2bd707bc
    2018-11-03T10:13:25.299920739+02:00 container kill a26d9476c
    2018-11-03T10:13:25.306631692+02:00 container kill 61cbe7540

Deploy: restart_policy

この設定オプションは、終了時にコンテナを再起動する方法を指定します。

condition のデフォルト値は any です: これはコンテナが失敗したとき、または正常に終了したときに再起動することを意味します。

restart_policy は、スウォームモードでスタックをデプロイする場合にのみ適用されます。

restart は、docker-compose up を使ってデプロイするときに適用されます。

これがどのように動作するかを確認するために、3秒のスリープの後にコンテナを正常に終了させます。コンテナが自動的に再起動されることを期待しています。

docker-compose.yml に以下を追加します。

nano docker-compose.yml  
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 3

    deploy:
      replicas: 1
docker stack deploy -c docker-compose.yml  mystack

docker ps -a を 25 秒間繰り返し実行すると、コンテナは 3 秒後に終了し、新しいコンテナが自動的に作成されてその場所を埋めるようになります。デフォルトの restart_policy は期待通りに動作します。

docker ps -a

約25秒後に期待される出力。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
42738b793169        alpine:3.8          "sleep 3"           6 seconds ago       Up Less than a second                           mystack_alpine.1.wopmb7xzyakbftkwsk9eq0goo
95e00ae7c883        alpine:3.8          "sleep 3"           15 seconds ago      Exited (0) 7 seconds ago                        mystack_alpine.1.h0n7hh12bn4jgb35bozpirm9r
bac92d42ca3f        alpine:3.8          "sleep 3"           25 seconds ago      Exited (0) 16 seconds ago                       mystack_alpine.1.2xujcjgypj9kbdcwsw0g0ysw8
0998efbcba8f        alpine:3.8          "sleep 3"           34 seconds ago      Exited (0) 26 seconds ago                       mystack_alpine.1.puqpmp9u13ivqvclah5cmidgx

これは永遠に続きます。幸いなことに、この再起動の最大試行回数を制限することができます。

max_attempts は、コンテナをあきらめる前に何回再起動を試みるかを指定します (デフォルト: never give up)。

を使用して、以下を docker-compose.yml に追加します。

nano docker-compose.yml  
version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 2.22

    deploy:
      replicas: 1

      restart_policy:
        max_attempts: 3

これを使ってデプロイします。

docker stack deploy -c docker-compose.yml  mystack

実行してみると、20秒後にdocker ps -aを繰り返し実行すると、3つの新しいコンテナしか作成されていないことに気づくでしょう。その後、予想通り自動再起動が停止します。

また、delayを使って再起動間の待ち時間を調整することもできます。

デフォルト値は0で、再起動はすぐに行われます。

これを任意の時間に設定することができます。このチュートリアルでは説明しませんが、簡単なテストをしてみてください。

最後に、ウィンドウオプションもあります。

ウィンドウ ウィンドウ: ウィンドウ: 再起動が成功したかどうかを判断するまでの待ち時間を指定します。

あなた自身でも自由にテストしてみてください。

さらに興味深いエクササイズとして、遅延とウィンドウの間の相互作用を実験してみてください。

結論

これでこのチュートリアルは終了ですが、Alibaba Cloud Elastic Compute Service (ECS) での docker-compose トレーニングの開始を意味します。これで、いくつかのdocker-composeの設定オプションをしっかりと理解し、かなりの実践経験を積むことができるようになるはずです。

Docker-composeの詳細については、公式ドキュメント https://docs.docker.com/compose/compose-file/ を参照してください。

または、Alibaba Cloudのコンテナサービスをチェックして、コンテナ化のメリットを最大限に享受する方法を学びましょう。

アリババクラウドは日本に2つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker: デフォルトネットワークの設定

docker はデフォルトで172.17以下をサブネットに使用する
デフォルトのネットワークとコンフリクトが発生する際は、以下のように、dockerが作成するデフォルトネットワークを設定することが可能

/etc/docker/daemon.json(存在しない場合は新規作成する)
{
  "bip": "172.26.0.1/16",
  "default-address-pools" : [
    {
      "base" : "172.240.0.0/16",
      "size" : 24
    }
  ]
}
terminalでdockerを再起動
sudo systemctl restart docker
その他コマンド一覧
# networkのid一覧を表示
docker network list

# ネットワーク id xxxxxx のサブネットを表示
docker network inspect xxxxxxx

# ネットワーク id xxxxxx を削除(コンフリクトしている場合)
docker network rm xxxxxxx
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

php用のgRPCソースを生成するDockerfile

gRPCのプラグインをbrew等で入れることができなかったので、Dockerコマンド化しました.

ディレクトリ構成

├── Dockerfile
├── protos/
│   └── sample.proto
└── gen/
  • protos: protoファイルを置いておくディレクトリ
  • gen: 生成されたコードが配置されるディレクトリ

Dockerfile

FROM php:7.2.32-cli

WORKDIR /tmp
RUN apt-get update -y && apt-get install -y wget zip git automake zlib1g-dev libtool

# install protoc command
# releases: https://github.com/protocolbuffers/protobuf/releases
ENV proto_version 3.12.3
RUN wget https://github.com/protocolbuffers/protobuf/releases/download/v${proto_version}/protoc-${proto_version}-linux-x86_64.zip \
    && unzip -d protoc protoc-${proto_version}-linux-x86_64.zip \
    && mv protoc/bin/* /usr/local/bin/ \
    && mv protoc/include/* /usr/local/include/

# install grpc php plugin
# releases: https://github.com/grpc/grpc/releases
ENV grpc_version v1.30.2
WORKDIR /var/local
RUN git clone -b ${grpc_version} https://github.com/grpc/grpc --depth=1
WORKDIR /var/local/grpc
RUN git submodule update --init \
    && make grpc_php_plugin \
    && cp -p ./bins/opt/grpc_php_plugin /usr/local/bin/

WORKDIR /var/local
RUN mkdir protos \
    && mkdir gen

ENTRYPOINT ["protoc", "--proto_path=/var/local/protos", "--php_out=/var/local/gen", "--grpc_out=/var/local/gen", "--plugin=protoc-gen-grpc=/usr/local/bin/grpc_php_plugin"]
CMD ["hello.proto"]

コード生成コマンド

  1. コンテナの中にボリュームマウントでprotoファイルを埋め込む
  2. コンテナ内でソースが生成される
  3. コンテナ内に生成されたファイルをボリュームマウントでローカルにコピーする

の流れです。

$ docker build -t grpc-php-gen -f docker/grpc-php-gen/Dockerfile .
$ docker run --rm -v $(PWD)/protos:/var/local/protos -v $(PWD)/gen:/var/local/gen grpc-php-gen sample.proto
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ruby on Rails から Open Distro for Elasticsearch に接続する

この記事について

Ruby on Rails から Docker 上の Open Distro for Elasticsearch に接続する方法を記載します。

Open Distro for Elasticsearch とは

Open Distro for Elasticsearch は Elasticsearch のディストリビューションで、 Amazon Elasticsearch Service で使われているものです。

Docker

公式のドキュメントを参考に docker-compose で Open Distro for Elasticsearch を立ち上げます。
今回はシングルノードで立ち上げています。

docker-compose.yml
version: "3"
services:
  elasticsearch_open_distro:
    image: amazon/opendistro-for-elasticsearch:1.9.0
    environment:
      - discovery.type=single-node
      - cluster.name=elasticsearch
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    ports:
      - 9200:9200

Ruby on Rails から接続

elasticsearch-railselasticsearch-model を使います。

Gemfile
gem 'elasticsearch-model'
gem 'elasticsearch-rails'

素の Elasticsearch と違い Open Distro for Elasticsearch は localhost の場合も https で接続しなければなりません。
よって initializer は以下のように書きます。
localhost の場合は transport_options で ssl の verify を false にしています。
ELASTICSEARCH_USERELASTICSEARCH_PASSWORD はデフォルトでは両方 admin を使うと接続することはできます。

config/initializers/elasticsearch.rb
Elasticsearch::Model.client = Elasticsearch::Client.new(
  host: 'localhost',
  port: 9200,
  user: ENV['ELASTICSEARCH_USER'],
  password: ENV['ELASTICSEARCH_PASSWORD'],
  scheme: 'https',
  transport_options: {
    ssl: {
      verify: false,
    },
  },
)

これで接続することができました。
elasticsearch-rails の Usage の手順で接続を確認することができます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker 初心者がまとめてみた

プログラミング初心者がDocekrについてまとめてみた

どこまでのまとめ?

Dockerについて〜コンテナの作成

コンテナ・イメージについて

Dockerの便利なところ

  • コマンド一発でコンテナを何度でも生成できる

    • 一度Dockerfileを作成してしまえば、簡単に用意できる。
  • コンテナを共有できる

    • Dockerfile(環境構築のレシピ)の中身はソースコードだから他の人たちと共有できる。Dockerfileを共有するためのDockerhubというサービスがあり、他の人が生成したコンテナをいつでも使える。

コンテナとは

コンテナとはDockerによって作成されるゲストOSのことで、 Dockerイメージを元に作成される仮想環境の実行部分。

イメージとは

通常パソコンにOSをインストールする時に使用されるものがイメージと呼ばれる。
アプリケーション開発にはUbuntu、RubyやPHPなど、実行するためにはOSが必ず必要になってくる。 『 OS が必要 = イメージが必要 』となり、結果 Docker の使用にあたって「Dockerイメージ」が必要となってくる。

イメージはコンテナを作成するためのテンプレートとなってくれる。
つまりDockerコンテはDockerイメージから生成される。

ビルドをするとは

DockerfileからDockerコンテナの元となるイメージをつくることを、Dockerイメージをビルドすると呼ばれている。

Dockfileとは

環境構築のレシピのこと。どうやって環境を作成していくかを記したファイル。
DockerfileはベースとなるDockerイメージ(OS)をFROMで定義できる。
Dockerfileはあくまでもイメージを構築するための手順を記述したファイルで、Dockerfile自身がDockerイメージになるわけではない!!!

qiita.rb
FROM ruby:2.6

Dockerfileでイメージをビルドする際、まず最初にFROMで指定されたイメージをDockerHubというレジストリからダウンロードしてから実行される。

Dockerhub

Dockerfile(環境構築のレシピ)の中身はソースコードだから他の人たちと共有できる。Dockerfileを共有するためのDockerhubというサービスがあり、他の人が生成したコンテナをいつでも使える。

ここまでの流れ

Dockerイメージを構築するためのDockerfileを作成し、ビルドをすることによってイメージが作成されて、Dockerコンテナを実行していく。

コマンド/Dockerfileの中身

Dockerfile
FROM ruby:2.6

# install package to docker container
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev \
    && apt-get install apt-transport-https \
    && curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \
    && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \
    && apt-get update && apt-get install -y yarn \
    && curl -sL https://deb.nodesource.com/setup_10.x | bash - \
    && apt-get install -y nodejs \
    && mkdir /アプリ名

WORKDIR /FANTRA
COPY Gemfile /アプリ名/Gemfile
COPY Gemfile.lock /アプリ名/Gemfile.lock

COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

[FROM]

使用するイメージとバージョンを指定。
Dockerfileでイメージをビルドする際、まず最初にFROMで指定されたイメージをダウンロードしてから実行される。

[RUN]

Dockerイメージビルド時に、Dockerコンテナ内で実行するコマンドを定義
ここではrails6に必要なツールをインストール。

[WORKDIR]

作業ディレクトリを設定

[COPY] 

Dockerを動作させているホストマシン上のファイルやディレクトリをDockerコンテナ内にコピーする
左側がローカルで、右側がコンテナ内。

[ENTRYPOINT]

一番最初に実行するコマンド。
ENTRYPOINTはCMDと同じくコンテナ内で実行するプロセスを指定する。

[EXPOSE]

コンテナがlistenするport番号

[CMD]

CMDはコンテナ起動時に1度実行される。RUNでアプリケーションの更新や配置、CMDはアプリケーションそのものを動作させる

Dockerfileやその他必要なファイルができればビルドをする

rails6で開発したかったら、以下のURLを参考にして必要フィルを作成していける。
https://qiita.com/nsy_13/items/9fbc929f173984c30b5d

docker image buildコマンドでDockerイメージを作成

qiita.rb
docker image build -t イメージ名 Dockerfile配置ディレクトリのパス

-tオプションでイメージ名を指定する。
ここでイメージ名を指定しないと、ハッシュ値で管理することになって手間が増えてしまう。
カレントディレクトリがDockerfile配置ディレクトリであれば、最後の引数は「.」(カレントディレクトリ)

docker image buildでは必ずDockerfileを与える必要があるから、ディレクトリにDockerfileが存在しないとちゃんと実行できない。

イメージがbuildで作成されたら

作成したイメージをdocker container runコマンドを利用してコンテナを実行できる。
注意なのがrunコマンドは実行とコンテナを作成するから、作る必要のないコンテナを実行する時は --rmをつけてやる。

コンテナのライフサイクル

Dockerコンテナは実行中・停止・破棄という3つの状態のいずれかに分類される。これをDockerコンテナのライフサイクルと呼びます。docker container runで起動された直後は実行中に当てはまる。

実行中

docker container runで指定されたDockerイメージをもとにコンテナが作成され、DockerfileのCMDやENTRYPOINTで定義されているアプリケーションの実行を開始する。このアプリケーションが実行中なら、Dockerコンテナは実行中にあるということ。

停止

実行中のコンテナはユーザーが明示的にコンテナを停止するか、コンテナで実行されているアプリケーションが正常・異常を問わず終了した場合に自動的に停止。

破棄

頻繁にコンテナの実行・停止を繰り返すような環境ではディスクの要領を専有していくことになるため、不要なコンテナは破棄した方がいい。
コンテナは明示的に破棄しない限り残り続けてしまう。

Dockerで一番使うらしいコマンド

qiita.rb
$ docker container ls

表示される内容

  • CONTAINER ID
    • コンテナに付与されるID
  • IMAGE
    • コンテナ生成に使用されたDockerイメージ
  • COMMAND
    • コンテナで実行されてるプロセス
  • CREATED
    • コンテナが作成されてから経過した時間
  • STATUS
    • コンテナの状態
      • Up(実行中)・Exited(終了)などコンテナの状態
  • PORTS
    • ホストのポートとコンテナのポートの紐付け
  • NAMES
    • コンテナの名前
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

phpのフレームワークLaravelを触ってみた。

環境構築

※ローカル上で環境構築可能ですが、今回はdocker上で動く様にしてみました。

dockerのディレクトリ、ファイル構成

.(任意の作業ディレクトリ)
├── docker
│   ├── php
│   │   └── Dockerfile
│   └── web
│       └── default.conf
├── docker-compose.yml
├── index.html
├── index.php

phpモジュールのビルド

  • build
$ docker-compose build

Laravelのプロジェクト新規作成

以下コマンドを実行する。

$ cd (任意の作業ディレクトリ)
$ laravel new sample-larabel

※プロジェクト作成後のディレクトリ構成

.(任意の作業ディレクトリ)
├── docker
│   ├── php
│   │   └── Dockerfile
│   └── web
│       └── default.conf
├── docker-compose.yml
├── index.html
├── index.php
├── sample-larabel

Nginxの設定ファイル(default.conf)の修正

※rootディレクトリの修正

server {
    listen 80;

    root /var/www/html/my-laravel-app/public;
    index index.php index.html index.htm;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

コンテナ起動及び動作確認

  • コンテナ起動
$ docker-compose up -d
  • 起動確認
$ docker-compose ps

※この様に表示されればOK。

             Name                           Command              State                 Ports              
----------------------------------------------------------------------------------------------------------
docker-compose-laravel_app_1     docker-php-entrypoint php-fpm   Up      9000/tcp                         
docker-compose-laravel_mysql_1   docker-entrypoint.sh mysqld     Up      0.0.0.0:3306->3306/tcp, 33060/tcp
docker-compose-laravel_web_1     nginx -g daemon off;            Up      0.0.0.0:8000->80/tcp ```

画面表示確認

新規ページ作成

  • 後日アップします。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker ローカルのファイルをコンテナ内にコピーする

目的

  • MacやWindowsなどのローカルにあるファイルをDockerのコンテナの中にコピーするコマンドを紹介する。
  • ※筆者の環境はMacのためMacのローカルからコンテナ内にファイルをコピーする方法を記載する。

実施環境

  • ハードウェア環境
項目 情報
OS macOS Catalina(10.15.5)
ハードウェア MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
プロセッサ 2 GHz クアッドコアIntel Core i5
メモリ 32 GB 3733 MHz LPDDR4
グラフィックス Intel Iris Plus Graphics 1536 MB

  1. Macのローカルのターミナルで下記コマンドを実行する

    $ docker cp コピーしたいファイル コンテナID:コンテナ内のコピー先パス/コピーしたファイルを設置する時のファイル名
    

具体例

  1. Macのローカルの~/Download直下にあるmy_dump.sqlというファイルを、「docker_mysql_1」というCONTAINER IDのコンテナの/root/dumpディレクトリ直下に同じファイル名でコピーしたい時のコマンドを下記に記載する。

    $ docker cp ~/Download/my_dump.sql docker_mysql_1:/root/dump/my_dump.sql
    
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Go Gin Docker AWSで完璧なTodoアプリを作る

こんにちは。
今回は最近流行りのGoの勉強ついでにQiitaを書いてみようと思います。

普段はReactでのフロント開発やRailsでAPI開発などをしています。
社内でもRailsからGoへの書き換えが始まっている中で、Goってどうやって書くの?インフラわからないんだけどデプロイしてみたい!って軽い気持ちでサンプルアプリを作ってみたいと思います。
意外とローカルで動くものを作って終わりな記事が多いので今回はデプロイまで行うことをゴールとして開発していきます!!

使用技術

  • go
  • gin
  • go modules
  • mysql
  • docker
  • gorm
  • AWS

参考文献

Go / Gin で超簡単なWebアプリを作る
DockerでGoの開発環境を構築する

早速やっていこーう(環境構築)

(ここではgoのインストールは省略しまーす。)
まずやることはディレクトリの作成!

mkdir perfect_todo
cd perfect_todo

そして今回はgoのライブラリーを管理するためにgo modというものを使っていきます。これはどのライブラリーを入れたかを管理してくれるので、docker化した時や共同開発の時にとても便利らしい。。。

go mod init perfect_todo

これで go.modgo.sum というファイルが生成されたかと思います。

そしたら次にgoのフレームワークであるginをインストールしていきたいと思います。

go get github.com/gin-gonic/gin

go.mod をみてみてください。これで github.com/gin-gonic/gin が追加されていたらインストールが完了しています!

それが成功したら

touch main.go

でmain.goのファイルを作ります。このファイルが実行されて、ここでインポートされているファイルが読み込まれていくので、アプリケーションの肝となるファイルです。

main.go
package main

import (
    "github.cogom/gin-gonic/gin"
)

func main() {
    router := gin.Default()
    router.LoadHTMLGlob("templates/*.html")

    router.GET("/", func(ctx *gin.Context){
        ctx.HTML(200, "index.html", gin.H{})
    })

    router.Run()
}

ここではginを使って、ルーティングを設定しています。/にアクセスが来たらindex.htmlを表示するといった具合に設定をしています。

そしてそのindex.htmlがなくては表示させるファイルがないのでindex.htmlを作成します!

templatesディレクトリーを作ってその下にindex.htmlを作成します

templates/index.html
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Sample App</title>
</head>
<body>
    <h1>Hello World!!!</h1>
</body>
</html>

これでお待ちかねのHello Worldの準備が完了です!

go run main.go

これを実行して localhost:8080 にいくと。。。!?!?

image.png

ででーーーーーん!!
Hell World!

何回みてもこの感動は良いですよねえ。

Docker化

ここではDockerの説明は省きますが、Dockerにしておくと環境の違いで苦しんだりすることがないのでDocker化しておきます。

touch Dockerfile

Dockerfile を作成します。

FROM golang:latest
RUN mkdir /go/src/app
WORKDIR /go/src/app
ADD . /go/src/app
VOLUME /go/src/app
RUN go mod download
EXPOSE 8080
CMD "go" "run" "main.go"

途中の go mod download でさっき作成した go.mod から自動でライブラリーを読み込んでくれると!便利ですね。
あとは今までやってきたことをDockerにやってもらっているだけです!

では実行していきましょう!

docker build -t perfect_todo .
docker run -it -p 8080:8080 perfect_todo

これでさっき実行した時と同じ挙動になったら成功です!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

サーバー二台でdocker + MySQLを用いてレプリケーション

ラズパイをサーバー化して環境構築をしているのですが、大苦戦中です。
CPUのアーキテクチャが組込用なので便利なdocker imageが全然使えないという。。。
SSL認証のときも大変でしたが、それはまた別の記事で。

※今回はラズパイをDBサーバーとしましたが、通常のオンプレサーバーであっても同じ書き方でできるはずです。

1.やりたいこと

1.1.レプリケーション

サーバー1にマスターDBをおき、サーバー2にスレイブDBをおいて、スレイブでマスターDBの更新を検知して全くDBを保持すること
片方のサーバーが物理的に壊れてもDBのデータは残ります。(うっかりdrop tableなんてオペミスは無理ですが)

1.2.レプリケーションの設定をdockerで簡略化

結構めんどくさいので、新しいサーバーにもdocker-compose up -dの1コマンドで環境を設定できたら楽です

2.手順

2.1.全体の構成

サーバー構成
192.168.0.2 → master用サーバー
192.168.0.3 → slave用サーバー

ディレクトリ構成

├── db
│ ├── Dockerfile
│ ├── conf
│ │ ├── master.cnf
│ │ └── slave.cnf
│ └── sql
│ ├── init_master.sql
│ └── init_slave.sql
├── docker-compose.yml

↑treeコマンドで表示したのですが、みづらいですねすみません。

2.2.docker-compose.ymlの作成

docker-compose.ymlにてdbディレクトリをビルドします
そしてdbディレクトリには必要な設定ファイルを仕込むのですが、まずはdocker-composeだけ載せますと

docker-compose.yml
version: '3'

services:
  db:
    build: ./db
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: db_name
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      TZ: 'Asia/Tokyo'。
    volumes:
      # 初期データを投入するSQLが格納されているdir
      - ./db/sql:/docker-entrypoint-initdb.d
      # 永続化するときにマウントするdir
      - /var/lib/mysql:/var/lib/mysql

build: ./dbにてdocker-compose.ymlと同じ階層のdbディレクトリをビルドしています。

2.3.dockerfileとconfigファイルの作成

次にdockerfileを書きます。
これは一部、マスターとスレーブで書き換えが要ります

Dockerfile
FROM mysql:5.7
# 読み込むconfファイルをマスターかスレーブかでコメントアウトして分岐させる
#ENV conf_file ./conf/slave.cnf
ENV conf_file ./conf/master.cnf

ADD $conf_file /etc/mysql/my.cnf
RUN chmod 644 /etc/mysql/my.cnf

これまではほとんどmasterとslaveで個別の設定はありませんでした。

次にmasterとslaveのそれぞれのconfファイルを設定していきます。

master.conf
[mysqld]
user=mysql
server-id = 1
log-bin
binlog-format = MIXED
slave.conf
[mysqld]
user=mysql
server-id=2
log-bin
read_only

2.4.DB初期化時に読み込まれるファイルの作成

次にdbディレクトリがビルドされるときの初期化のsqlを書きます

init_master.sql
-- slaveが使用するユーザーを設定(slaveのサーバーの内部IPに合わせる)
CREATE USER 'replica'@'192.168.0.3' IDENTIFIED BY 'replica';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.3';
init_slave.sql
-- MASTER_LOG_FILEやMASTER_LOG_POSの調べ方は後述
CHANGE MASTER TO MASTER_HOST='192.168.0.2', 
    MASTER_PORT=3306, 
    MASTER_USER='replica', 
    MASTER_PASSWORD='replica', 
    MASTER_LOG_FILE='3ae7abcabc-bin.000003', 
    MASTER_LOG_POS=1234;

init_slave.sqlのmaster_log_fileやmaster_log_posの調べ方ですが、マスターDBサーバーのコンテナに入って

$docker exec -it <container_id> bash
#mysql -u root -p password
>show master status\G;

こんな順番でコマンドを入力するとマスターのログファイルの位置が取得できます。
mysql 5.7以降だったか、わざわざこんなことをしなくても 
MASTER_AUTO_POSITION=1
と設定するだけでいけるとかなんとか

これでレプリケーションできるかと思います。

何もミスってなければslaveのサーバーにて

$docker exec -it <container_id> bash
#mysql -u root -p password
>show slave status\G;

こんな感じでDBコンテナに入ってコマンドを打つとずらーっと表示されますが

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

この2つのパラメータがYesになります
connectingとか書いてたらだめです。

ずらーっと表示されている下の方にエラー内容が出ます

Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error: 

※これは正常な状態です

ここに出てくるエラーナンバーやエラーメッセージを頼りにデバッグしたらできるかと思います。

どうしても自動化しきれていませんが、だいぶ再現するのが楽にはできたかなと思います。
何か補足があったらぜひお願いいたします。

あ、あと既にテーブルがあって運用中のDBをマスタースレーブ構成にしたい場合は、masterでダンプしてそのデータをslaveでリストアして反映する必要があります。

https://qiita.com/marienplatz/items/3255b2d7f7f922ab115a

こっちに書きましたので参考までに

参考
http://www.tohoho-web.com/ex/mysql-replication.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む