- 投稿日：2020-07-28T22:15:47+09:00
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.ymlKUSANAGI 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/.bashrcPATH=/home/kusanagi/.kusanagi/bin:$PATHKUSANAGI 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 wpcliDockerコンテナが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）』に続きます。
- 投稿日：2020-07-28T22:07:04+09:00
Docker×Laravel×Vue
開発で必要な記事をまとめていきます。
これを参考にして開発始める人の手助けになればいいなと思って
自分が参考にした記事をまとめていきます。マルチログインの実装
それぞれ別々のディレクトリに分けてあげて判断。
認証に必要な要素を付け加える
https://qiita.com/sasakure-kei@github/items/388a2900557a6079164d
Laravel authで404 nginxが使えない時
https://qiita.com/isaatsu0131/items/f1eafe7522f0bf0ff043
nginxのファイル探索部分がおかしいらしい
Docker
起動中のコンテナ一覧
docker psImage起動
docker run -it IMAGE名 bashDocker起動
https://qiita.com/A-Kira/items/1c55ef689c0f91420e81
Docker Laravel 実行
https://qiita.com/A-Kira/items/1c55ef689c0f91420e81
docker-compose down docker-compose up -dDocker 起動してもexitするとき
docker logs コンテナIDhttps://qiita.com/mom0tomo/items/35dfacb628df1bd3651e
Mysql bin/bashで起動
docker exec -it db-host bin/bashDockerのイメージ壊してテーブルのデータが消えた時
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=1Vue Router 404ERROR対処方法
ルーティング指定
https://sashimistudio.site/rails-vuerouter-history404/https://blog.hirokiky.org/entry/2019/08/22/111031
解決してくれたもの
https://teratail.com/questions/121182web.phpRoute::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 maxphp.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.inihttps://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-missingClass 'Egulias\EmailValidator\Validation\RFCValidation' not found
https://laracasts.com/discuss/channels/laravel/eguliasemailvalidatoremailvalidator-does-not-exist
同様に困ってる方の質問で
```
rm -rf vendor/*の後に
composer install --no-dev
```で万事解決！！
メールが文字化けする。。。
右下の文字をUTF-8にしてあげることで解決。。
2hかかった。。。
- 投稿日：2020-07-28T17:06:42+09:00
東京大学計数工学科講義「AWSによるクラウド入門」をやってみた
東京大学計数工学科で開講されている講義資料「AWSによるクラウド入門」が公開されており、AWSの基礎だけでなく、機械学習やサーバレスなどもHands-Onを通じて学べるということで、早速実施してみました。
クラウド入門者向けに簡潔かつ平易な言葉で書かれており、大変勉強になりました。飽き性の私でも最後まで楽しんでできました。
かかった時間と費用
・一通り解説を流し読み、Hands-Onも全て実行して、約4時間
・費用は、0.49ドル
学べること
大きく以下３点です。気になるキーワードがあれば、そこだけ掻い摘むのも良いのではないかと思います。
クラウドの基礎
・クラウドの基礎となる概念・知識
・セキュリティやネットワークなど，クラウドを利用する上で最低限おさえなければいけないポイント理解
・ハンズオン：仮想サーバーをAWSに立ち上げる
・キーワード：AWS CLI、AWS CDK、CloudFormation、VPC、EC2、Security Groupクラウドで行う機械学習
・クラウド上で機械学習を走らせるための入門となる知識・技術
・Docker に自分のプログラムをパッケージングする手順
・ハンズオン１：AWSでJupyter notebookを使って簡単な機械学習の計算を走らせる
・ハンズオン２：ディープラーニングを用いた自然言語処理により，質問に自動で回答を生成するボットを作成
・キーワード：GPU、DLAMI、Jupyter notebook、PyTorch、MNIST、Docker、Elastic Container Service (ECS)、Fargate、TransformerServerless Architecture
・Serverless architectureと呼ばれる最新のクラウドのアーキテクチャを解説
・ハンズオン１：簡単なデータベースをクラウド上に作成
・ハンズオン２：俳句を投稿するSNS "Bashoutter" 作成
・キーワード：REST API、Lamba、S3、DynamoDB、API Gateway、Simple Notification Service、Step Functionsおわりに
１点だけ、詰まったというか、記載通りにならなかった箇所がありましたので、備忘録的に残しておきます。
「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の制限が初期値だと０なので、その上限を上げてもらう必要があります。
以下のように、制限緩和のリクエストを投げれば、１０分ほどで作業完了の連絡がありました。その後、再度デプロイすれば、うまく行きます。
- 投稿日：2020-07-28T16:41:02+09:00
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コンソールページに向かいます。
コンテナサービスのコンソールページに到着します。
左側メニューのClusterオプションをクリックする前に、Container Service - Swarmオプションが選択されていることを確認してください。
問題がなければ、健全な状態の Running cluster が表示されているはずです。
Docker Swarmコンテナサービスアプリケーションの作成
「Application」メニューオプションに移動し、「Create Applicatio」をクリックします。
基本オプションで、アプリケーションの名前とバージョン番号(デフォルトは1.0)を追加し、アプリケーションに使用するクラスタを選択します(ここでは、実行中のクラスタが1つしかないので、これがデフォルトになっています)。
標準リリースでは、新しいバージョンをデプロイする前に、以前のバージョンのアプリケーションを削除します。このチュートリアルではこれで十分です。青緑色のリリースは、更新時に中断することなく実行し続ける必要があるアプリケーションのためのアクティブ・スタンバイ・オプションです。
Dockerイメージを引っ張ってコンテナを作成する
アプリケーションの説明を追加し、Pull Docker Imageオプションを選択します。
ここで「Create with Image」をクリックします。
設定オプションに進みます。一般的な設定で、[Select Image] をクリックします。
nginxオプションを選択し、OKをクリックします。
最新のDockerイメージのバージョンは、デフォルトでリモートのDockerリポジトリから引っ張ってきます。
これで右側のCreateをクリックすることができるようになりました。
アプリケーションが作成されていることを確認する画面が表示されます。
これで、アプリケーションとサービスの両方のメニューに nginx アプリケーションが表示されるようになりました。
「Applications」メニューで、nginxを実行しているアプリケーションをクリックします。
Updateをクリックします。
これで、ネットワークの設定を行います。
HTTP/HTTPS 80と443のポートマッピングの詳細と、コンテナポートを追加します。
ここで「Update」をクリックします。
アプリケーションが作成され、最終的には実行中の状態に落ち着くのがわかります。
アプリケーションメニューオプションをクリックします。
クリックすると応募の詳細が表示されます。
このビューでは、いくつかのタブが表示されます。[サービス] タブには、アプリケーションの状態が表示されます。
コンテナ] タブをクリックします。このビューには、すべての VPC ネットワーク ポート設定、コンテナの IP、ノードの IP が表示されます。また、コンテナを監視するオプションもあります。
名前のリンクをクリックします。
コンテナのCPU、メモリ、IO、プロセスの使用率など、多くのグラフが表示されます。
ここでログタブをクリックします。
ここでは、コンテナのログが表示されます。今すぐイベントをクリックします。
このオプションを選択すると、コンテナ上のイベントのリストが表示されます。ここで、[ルート] タブをクリックします。
ここにコンテナのエンドポイントが表示されます。先に進み、リンクをクリックしてください。
nginx コンテナが正しく設定され、実行されていることが確認できるはずです。
オーケストレーションテンプレートでコンテナを作成する
それでは、同じクラスタ上でWordPressとnginxを統合してみましょう。
今回はオーケストレーションテンプレートを使用します。コンテナサービスコンソールに戻り、アプリケーションをクリックします。正しいクラスタ上にあることを確認し（まだクラスタは1つだけです）、「アプリケーションの作成」をクリックします。
手順は先ほどと全く同じですが、「Create with Image」をクリックする代わりに「Create with Orchestration Template」をクリックします。ここではDocker Imageオプションは非選択のままにしておきます。
Dockerのエコスフィアに慣れている方は、ここでDockerのコンポーズファイルを実行します。Use Existing Orchestration Templateをクリックします。
WordPressを選択してみましょう。
ご覧のように、コンソールには関連するDocker composeコマンドと設定が表示されます。
今すぐ設定の一つを編集する必要があります。
この設定変更により、テストドメインのURLからaliyunポート80へのリクエストはすべてWordPressにルーティングされるようになります。
ここで「Create and Destroy」をクリックします。
アプリケーションが起動しているのが表示されます。アプリケーションメニューをクリックすると、WordPressが作成されているのが表示されます。
アプリケーションが作成されると、実行中の状態で表示されます。クリックしてアプリケーションに進みます。
先ほどと同じように、いくつかのタブが表示されています。WordPressを動かすにはデータベースとWebアプリケーションが必要なので、2つのタブがあります。コンテナタブをクリックします。
コンテナタブには、アプリケーションが必要とするすべての異なる実行中のDockerコンテナの詳細が表示されます。
ログとイベントタブには、先ほどと同じように詳細が表示されます。Routesをクリックすると、アプリケーションの設定に必要なWordPressエンドポイントのURLが表示されます。
先に進み、エンドポイントをクリックします。
これで、先ほど設定したnginxウェブサーバ上で動作するWordPressサイトを設定することができます。
概要
まず、コンテナ化環境を構築する準備として、すでに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アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ
- 投稿日：2020-07-28T16:06:09+09:00
docker: AWSから完全にuninstall
1 dockerが作成したnetworkを削除
docker network prune2 pre-definedのnetworkも削除
service docker stop
vim /etc/docker/daemon.jsondaemon.json{ "bridge": "none" }
vim service start docker3 uninstall
sudo yum remove docker docker-common docker-selinux docker-engine4 設定ファイルの削除
rm -rf /etc/docker5 imageの削除
rm -rf /var/lib/docker
- 投稿日：2020-07-28T16:02:48+09:00
Dockerのコンテナを消しても、中のファイルを維持する方法
「Dockerあんまり触ったことなかったけど、これからはDockerで開発環境を整えよう」と思ったときに気になったこと。
コンテナの中にあるデータを独立させるにはどうしたらいいんだ？
マウントする(-v)
手順は
自分のローカル環境上にディレクトリを作り、その中にファイルを入れる
そのディレクトリをマウントして、コンテナを起動する
以上これでローカルにあるファイルをコンテナで起動してみることができる
これをバインドマウントと呼び、作業ディレクトリを即座にコンテナから参照することができる。もう一つの手順が
docker volume createを使ってDocker Engineのなかにボリューム(データを保存する場所)を作成sる
以上これでDockerEngineの中にデータを入れて保存することができる。
MySQLなどのコンテナを起動して、このボリュームをマウントして使う。
ボリュームマウントとよびこちらが公式では推奨されている。
- 投稿日：2020-07-28T15:49:40+09:00
Dockerコンテナの並列化 - Docker Composeのための実践的な演習その5
このチュートリアルでは、Alibaba Cloud上でコンテナを扱う際にDocker Composeを使用して実践的な経験を積むことに焦点を当てています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
Deploy: update_config: parallelism
並列処理は、サービスの更新をどのくらいの速さで行うかを設定します。新しく起動されたコンテナは、できるだけ早く起動されます。新しいコンテナはこの update_config 設定を使用しません。
したがって、これでテストするには、UPDATEの並列処理を観察できるように、すでに実行されているコンテナのセットが必要です。
まず、parallelism = 1 (デフォルト)とします。
docker-compose.ymlに以下のように追加します。
nano docker-compose.ymlversion: "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=killdocker-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.v9zm2yipmvjzb673da8sbryh110-15秒ごとに約1つの新しいコンテナを取得します。これは並列処理 = 1 の場合に得られるものです。
2つ目のコンソール出力を見てみましょう: docker events
ご覧の通りです。1つの新しいコンテナが作成され、1つの古いコンテナが削除されました。
この更新処理を高速化するために、docker-compose.yml の並列処理を 3 に上げてみましょう。
nano docker-compose.yml並列処理：3
再実行：
docker stack deploy -c docker-compose.yml mystackdocker 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.ymlversion: "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 mystackdocker 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 -fPauseが思ったように動作しません。failure_action: rollbackをテストしてみましょう。
failure_action: のロールバックをテストするためには、新しく始める必要があります。
1、6つの作業コンテナを作成します。
2、6つのexit = 1エラーコンテナを含むdocker-compose.ymlを作成します。
3、失敗のアクションをロールバックに設定します。
4、デプロイスタックを実行して結果を観察します。
次を使用してdocker-compose.ymlに追加します。nano docker-compose.ymlversion: "3.7" services: alpine: image: alpine:3.8 command: sleep 600 deploy: replicas: 6作業コンテナをデプロイします。
docker stack deploy -c docker-compose.yml mystack6つのエラーコンテナを作成します。以下を docker-compose.yml に追加します。
nano docker-compose.ymlversion: "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.yr0zkfu9n40s0rbezfhjtl6yu5秒後くらいに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: rollbackDeploy: 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並行処理：２
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並行処理：３
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並行処理：６
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 61cbe7540Deploy: restart_policy
この設定オプションは、終了時にコンテナを再起動する方法を指定します。
condition のデフォルト値は any です: これはコンテナが失敗したとき、または正常に終了したときに再起動することを意味します。
restart_policy は、スウォームモードでスタックをデプロイする場合にのみ適用されます。
restart は、docker-compose up を使ってデプロイするときに適用されます。
これがどのように動作するかを確認するために、3秒のスリープの後にコンテナを正常に終了させます。コンテナが自動的に再起動されることを期待しています。
docker-compose.yml に以下を追加します。
nano docker-compose.ymlversion: "3.7" services: alpine: image: alpine:3.8 command: sleep 3 deploy: replicas: 1docker stack deploy -c docker-compose.yml mystackdocker 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.ymlversion: "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のコンテナサービスをチェックして、コンテナ化のメリットを最大限に享受する方法を学びましょう。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ
- 投稿日：2020-07-28T14:53:01+09:00
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
- 投稿日：2020-07-28T14:33:07+09:00
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"]コード生成コマンド
- コンテナの中にボリュームマウントでprotoファイルを埋め込む
- コンテナ内でソースが生成される
- コンテナ内に生成されたファイルをボリュームマウントでローカルにコピーする
の流れです。
$ 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
- 投稿日：2020-07-28T13:19:37+09:00
DockerプライベートレジストリをRaspberryPi上に作成
M= ローカルプライベート リポジトリ [2020-07-27 月 13:39]
はじめに
Kubernatesクラスタを構成する場合には、どこのノードからも同一のDocker イメージの参照が できるように、Docker イメージの照会及び登録するレジストリが必要になります。 (KubernatesのPodは、原則どこのノードでも動作する可能性があるため)
一般的には、利用するクラウドサービス(Google/AWS/IBM..)が提供しているレジストリサービ スを利用することが普通であると思いますが、学習のために自前でレジストリサービスを構築 することにチャレンジします。
作業環境
- ハードウエア Raspberry Pi 3B x 3台、4B x 2台
- Kubernates version 1.18.2
レジストリの選択
Dockerイメージのレジストリとしては、クラスタ内外を含めたの様々な構成ができますが、以 下の3パターンが一般的な構成になります。
- パブリックレジストリを利用(Docker Hub)
- クラウドサービスの提供するプライベートレジストリを利用(Google/IBM/AWSのContainer Registory等)
- 自前でプライベートレジストリを構築
可用性、運用・保守性、移行性等々を考慮すれば、1. または 2. から選択することが望ましい ですが、Kubernatesの構築を通じて、Kubernatesを理解することが目的であるので、ここでは、 「3. 自前でプライベートレジストリを構築」 を選択します。
作業ステップ概要
作業が間違っていないことを確認して進めるために、以下の作業手順でレジストリサービスを構築していきます。
- 設計する
- レジストリをDockerコマンドで実行し、ローカル接続ができることを確認
- レジストリをDockerコマンドで実行し、リモート接続ができることを確認
作業ステップ
設計する
作成するレジストリに対して、想定している設定内容を以下で記述する。
設定 内容 補足 通信方式 TLS 1.2 HTTPのみではノード間での通信ができない サーバー認証 自己証明書 無料で済ませるため サーバー名 レジストのサーバー名 実行例は rasp-registry ポート番号 レジストのポート番号 実行例は 5000 TLS 1
通信をTLSと自己証明書で構築する理由は、それしか選択肢がないからです。
ローカル接続
Dockerの機能のみを利用して、ローカル接続ができるレジストリの構築ができることを確認します。
$ sudo mkdir -p /var/local/volume $ docker run -d -p 5000:5000 --name registry --hostname registry --restart on-failure:10 -v /var/local/volume:/var/lib/registry registry:2/var/local/volume を Docker イメージを登録するレジストリのディレクトリになります。 docker ps として、registry:2 イメージが稼働していれば、完了です。
# パブリックリポジトリからイメージを入手 $ docker pull hello-world # タグを追加する $ docker tag hello-world localhost:5000/hello-world # プライベートリポジトリにイメージを登録 $ docker push localhost:5000/hello-world # プライベートリポジトリにからイメージが入手 $ docker pull localhost:5000/hello-worlddocker image でイメージが入手できたことを確認することができます。 ノード内で利用可能なレジストリであるため、localhost を利用してイメージを参照します。
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE hello-world latest 851163c78e4a 6 months ago 4.85kB localhost:5000/hello-world latest 851163c78e4a 6 months ago 4.85kBノード内で実行できることが確認できたので、コンテナーを削除しておきます。
# CONTAINER ID を確認する $ docker ps | grep registry # コンテナを停止させ、削除します。 $ docker stop [CONTAINER ID] $ docker rm [CONTAINER ID]リモート接続
Dockerの機能のみを利用して、リモート接続ができるレジストリの構築ができることを確認し ます。
TLS通信で利用するための証明書を生成します。今回は外部に公開せず、Kubernatesのテスト環 境であるため自己証明書を利用します。
以下のコマンドでは、x509自己署名証明書を4096ビットのRSA秘密鍵を生成しています。
自己署名証明書作成時に、Common Nameを聞いてくるので、このサーバーにアクセスする際の 名前と一致させて置く必要があります。
domain.key が秘密鍵ファイル、domain.crtが証明書ファイルになります。
mkdir -p ~/tmp/certs cd ~/tmp/certs openssl req -newkey rsa:4096 -nodes -keyout domain.key -x509 -days 365 -out domain.crt自己証明書を利用して、レジストリの実行を確認します。秘密鍵と証明書ファイルとは先ほど 作成したファイルパスを指定します。以下では、ホスト側のファイルパス ~/tmp/certs を コ ンテナ側の /ファイルパス certs で参照できるようにして、起動をしています。
REGISTRY_HTTP_TLS_CERTIFICATE、REGISTRY_HTTP_TLS_KEY の環境変数には、それぞれ、証明書 ファイル、秘密鍵ファイルの指定をします。コンテナ側のプロセスが参照するために、コンテナ側のファイルパスで指定をします。
docker run -d -p 5000:5000 \ -v ~/tmp/certs:/certs \ -v /var/local/volume:/var/lib/registry \ -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \ -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \ --restart=always --name registory registry:2各ノードの設定
各ノードからレジストリに接続するためには、レジストリの証明書を各ノード上のDockerサーバーに登 録する必要があります。そのためには、以下の作業をする必要があります。
- Docker サーバーが管理する証明書のディレクトリ(/etc/docker/certs.d/レジストリのホ スト名:ポート番号)を作成する。
- 作成した証明書のディレクトリに、証明書ファイルを ca.crt の名称で複写する
- Docker サーバーの再起動をします。
# Docker サーバーの証明書のディレクトリを作成する $ sudo mkdir -p /etc/docker/certs.d/rasp-registry:5000 $ cd /etc/docker/certs.d/rasp-registry:5000 # 証明書のコピーとサーバーの再起動 $ sudo scp pi@証明書を作成したホスト:証明書の生成パス/domain.crt ca.crt $ sudo service docker restartレジストリが各ノードからアクセスできることを確認しています。 お馴染みの hello-world が pull できることを確認します。 (hello-worldは、事前に push しなくても登録されている様でした)
$ docker pull rasp-registry:5000/hello-world Using default tag: latest latest: Pulling from hello-world 4ee5c797bcd7: Pull complete Digest: sha256:50b8560ad574c779908da71f7ce370c0a2471c098d44d1c8f6b513c5a55eeeb1 Status: Downloaded newer image for rasp-registry:5000/hello-world:latest $ docker run rasp-registry:5000/hello-world確かに実行をすることもできました。
参考情報
- Dockerの日本語サイト
- Dockerの英語サイト
- privateなdockerレジストリを構築する - Qiita
Docker Private Registryの構築 on Kubernetes https://qiita.com/khk-h/items/c4bf26d771f5a4a78ae6
Test an insecure registry https://docs.docker.com/registry/insecure/
Footnotes
1 Transport Layer Securit
- 投稿日：2020-07-28T12:31:25+09:00
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.ymlversion: "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:9200Ruby on Rails から接続
elasticsearch-rails と elasticsearch-model を使います。
Gemfilegem 'elasticsearch-model' gem 'elasticsearch-rails'素の Elasticsearch と違い Open Distro for Elasticsearch は localhost の場合も https で接続しなければなりません。
よって initializer は以下のように書きます。
localhost の場合はtransport_optionsで ssl の verify を false にしています。
ELASTICSEARCH_USERとELASTICSEARCH_PASSWORDはデフォルトでは両方 admin を使うと接続することはできます。config/initializers/elasticsearch.rbElasticsearch::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 の手順で接続を確認することができます。
- 投稿日：2020-07-28T10:41:20+09:00
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.rbFROM ruby:2.6Dockerfileでイメージをビルドする際、まず最初にFROMで指定されたイメージをDockerHubというレジストリからダウンロードしてから実行される。
Dockerhub
Dockerfile（環境構築のレシピ）の中身はソースコードだから他の人たちと共有できる。Dockerfileを共有するためのDockerhubというサービスがあり、他の人が生成したコンテナをいつでも使える。
ここまでの流れ
Dockerイメージを構築するためのDockerfileを作成し、ビルドをすることによってイメージが作成されて、Dockerコンテナを実行していく。
コマンド/Dockerfileの中身
DockerfileFROM 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/9fbc929f173984c30b5ddocker image buildコマンドでDockerイメージを作成
qiita.rbdocker 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
- コンテナの名前
- 投稿日：2020-07-28T07:55:38+09:00
phpのフレームワークLaravelを触ってみた。
環境構築
※ローカル上で環境構築可能ですが、今回はdocker上で動く様にしてみました。
dockerのディレクトリ、ファイル構成
.(任意の作業ディレクトリ) ├── docker │ ├── php │ │ └── Dockerfile │ └── web │ └── default.conf ├── docker-compose.yml ├── index.html ├── index.phpphpモジュールのビルド
- build
$ docker-compose buildLaravelのプロジェクト新規作成
以下コマンドを実行する。
$ cd (任意の作業ディレクトリ) $ laravel new sample-larabel※プロジェクト作成後のディレクトリ構成
.(任意の作業ディレクトリ) ├── docker │ ├── php │ │ └── Dockerfile │ └── web │ └── default.conf ├── docker-compose.yml ├── index.html ├── index.php ├── sample-larabelNginxの設定ファイル(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 ```画面表示確認
- http://localhost:8000/にアクセスして、正常に画面が表示される事を確認します。
新規ページ作成
- 後日アップします。
- 投稿日：2020-07-28T01:53:32+09:00
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 例
Macのローカルのターミナルで下記コマンドを実行する
$ docker cp コピーしたいファイル コンテナID:コンテナ内のコピー先パス/コピーしたファイルを設置する時のファイル名具体例
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
- 投稿日：2020-07-28T01:40:10+09:00
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.modとgo.sumというファイルが生成されたかと思います。そしたら次にgoのフレームワークであるginをインストールしていきたいと思います。
go get github.com/gin-gonic/gin
go.modをみてみてください。これでgithub.com/gin-gonic/ginが追加されていたらインストールが完了しています！それが成功したら
touch main.goでmain.goのファイルを作ります。このファイルが実行されて、ここでインポートされているファイルが読み込まれていくので、アプリケーションの肝となるファイルです。
main.gopackage 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にいくと。。。！？！？
ででーーーーーん！！
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これでさっき実行した時と同じ挙動になったら成功です！！
- 投稿日：2020-07-28T01:04:39+09:00
サーバー二台でdocker + MySQLを用いてレプリケーション
ラズパイをサーバー化して環境構築をしているのですが、大苦戦中です。
CPUのアーキテクチャが組込用なので便利なdocker imageが全然使えないという。。。
SSL認証のときも大変でしたが、それはまた別の記事で。※今回はラズパイをDBサーバーとしましたが、通常のオンプレサーバーであっても同じ書き方でできるはずです。
1.やりたいこと
1.1.レプリケーション
サーバー１にマスターDBをおき、サーバー２にスレイブDBをおいて、スレイブでマスターDBの更新を検知して全くDBを保持すること
片方のサーバーが物理的に壊れてもDBのデータは残ります。（うっかりdrop tableなんてオペミスは無理ですが）1.2.レプリケーションの設定をdockerで簡略化
結構めんどくさいので、新しいサーバーにもdocker-compose up -dの１コマンドで環境を設定できたら楽です
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.ymlversion: '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/mysqlbuild: ./dbにてdocker-compose.ymlと同じ階層のdbディレクトリをビルドしています。
2.3.dockerfileとconfigファイルの作成
次にdockerfileを書きます。
これは一部、マスターとスレーブで書き換えが要りますDockerfileFROM 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 = MIXEDslave.conf[mysqld] user=mysql server-id=2 log-bin read_only2.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この２つのパラメータが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
こっちに書きましたので参考までに