DXにおける開発 DXは価値が最初から出るものではなく、仮説検証を繰り返すことによって価値を作り出してく。 そのため、繰返し型の開発手法とそれに耐えうる開発環境、インフラ、ソフトウェアアーキテクチャが必要となる。 1. 開発方法：アジャイル 「あらかじめ全工程にわたる計画を立て、それを実行する」という開発プロセスではなく、開発中に発生する様々な状況の変化に対応しながら開発を進めていく手法。 アジャイル開発では、チームを組んで「要件定義→設計→開発→テスト→リリース（運用）」といった開発工程を、1つの機能を単位とした小さいサイクルで繰り返します。このような小さいサイクルを繰り返すことで、個々の機能の開発が独立して完結するため、開発期間中の仕様変更の発生に強く、リスクを最小化させることが可能。 この小さなサイクルの繰り返しを、アジャイル開発では「イテレーション（反復）」と呼んでいます。イテレーションは1週間から4週間ごとが一般的であり、イテレーションごとに機能をリリースすることを繰り返す。 2. 開発環境：DevOps コラボレーションツールによる情報共有や密なコミュニケーション、継続的インテグレーションツールなどによる導入・展開（デプロイ）の自動化、設定自動化ツールなどによる環境設定の自動化やコード化などがある。 3. インフラ：クラウド オンプレではシステムの拡大を行う際に、ハードウェアの手配リードタイムや構築の工数・コストがかかる。 -クラウドではプロバイダーに拡大を要求するだけで即時にコストを抑えてシステム拡大を実現することが出来る。 4. ソフトウェアアーキテクチャ（1/2）：コンテナ OS上のアプリケーションの動作環境を仮想的に複数に区切った単位。各コンテナはOSや他のアプリケーションのプロセスから隔離された環境に足るため、システム変更が容易で、再利用性も高くなる。 4. ソフトウェアアーキテクチャ（2/2）：マイクロサービスアーキテクチャ 小規模かつ軽量で互いに独立した複数のサービスを組み合わせてアプリケーションを開発するもの マイクロサービスの導入によってアプリケーションを疎結合化し、サービスごとのデプロイ（展開）の柔軟性、拡張性を高める狙いがある。

概要 debianのgo入ったdockerイメージ使ってMakefileでクロスコンパイルするときの設定わたしとくと、GPIOとかは無理だけど、そこそこラズパイ用のGO開発環境にできそう。 はじめに ラズパイでGO言語のプログラムを動かしたいときに、sshして開発しても良いと思うけど、複数人でなにか作りたいときとかはDocker環境で開発して出来たほうが良いかなーと思う。 クロスコンパイルして、そこそこテストして、実行ファイルだけラズパイにコピーして使う感じ。 ということで、ラズパイで動くGO言語プログラムを開発するためのDockerの設定をすこし整理した。 Dockerfileもdocker-compose.ymlもいまいちわかってないけど、動いてるから良しとした。 もっと、いい感じの書き方とかいい感じの設定あれば教えてほしいです。。。 結局、ラズパイとかいいつつ、GPIOもBluetoothも使ってないので、ただのdebian環境っていう・・・。 方針 軽くしらべたら、それっぽいイメージ提供してる人いたけど、詳細わかんないので、使わないことにした。GPIOとかをシミュレート？エミュレート？できるなら使ってみたい気はする。 balenalib/raspberry-pi-golang golangのオフィシャルなイメージはdebianっぽいので、そのまま使うことにした。 golang Makefileに、env GOOS=linux GOARCH=arm GOARM=7 go buildを書いておく。自分の持ってるラズパイはuname -aしたら、armv7lって書いてあったから、GOARM=7にした。それで動いた。 githubの環境変数を渡してあげる。 詳細 こんな感じ。 docker-compose.yml version: "3" services: raspi: build: ./raspi environment: GITHUB_USER_NAME: ${GITHUB_USER_NAME} GITHUB_TOKEN: ${GITHUB_TOKEN} GITHUB_EMAIL: ${GITHUB_EMAIL} volumes: - "raspi.repo:/repo" - "raspi.go:/go" tty: true volumes: raspi.repo: raspi.go: githubの環境変数をわたしてる。 上記ymlファイルの下に./raspiってフォルダを切ってDockerfileと最初に実行してほしいスクリプトをおいてる。 FROM golang:latest LABEL Name="raspi" LABEL Version="1.0.0" WORKDIR / ADD ./init.sh init.sh ENV GITHUB_USER_NAME=github-user-name ENV GITHUB_TOKEN=github-token ENV GITHUB_EMAIL=github-email RUN apt-get update && apt-get install -y \ less\ && apt-get clean \ && rm -rf /var/lib/apt/lists/* VOLUME /go VOLUME /repo WORKDIR /repo CMD ["bash", "/init.sh"] lessできないとストレスなので入れてる。 init.sh #!/bin/bash cd / git config --global user.name ${GITHUB_USER_NAME} git config --global user.email ${GITHUB_EMAIL} git config --global url."https://${GITHUB_USER_NAME}:${GITHUB_TOKEN}@github.com/".insteadOf "https://github.com/" while :; do sleep 10; done もうちょいgo installとかしといたほうがよいのかも。 最後のsleepがないと、たちあげるとき、exit 0って出して死んじゃう。 Makefile SHELL=bash build: go build build-raspi: env GOOS=linux GOARCH=arm GOARM=7 go build ビルドするときの設定（↑） あとは、適当にたちあげて使ったらよさげ。 docker-compose -f docker-compose.yml up -d --build おわりに それっぽく動いてる。満足。 ただ、環境変数とか、volumeのこと、いまいちわからない。 Dockerfileとdocker-compose.ymlの使い分けがいまいちわからない。 軽く検索しただけじゃ、よくわかんないので、本読むか。。。

Dockerは起動済み appコンテナ内でマイグレーションを行おうとすると下記のエラーが出る。 Illuminate\Database\QueryExceptionSQLSTATE[HY000] [1045] Access denied for user 'test'@'172.19.0.2' (using password: YES) (SQL: select count(*) as aggregate from `articles`) 結論 docker-compose down --volumes docker-compose build docker-compose up -d このコマンドで Access denied for user 'test'@'172.19.0.2' (using password: YES) 部分のエラーは解決 後半のエラー部分は .env　(laravelの) DB_PORT=3306 docker-compose.yml ports: - '4306:3306' 上記のようにすることで解決。 元々は.envファイルの中のDB_PORTが4306になっていたので3306に修正。 docker-compose.ymlをいじったらコンテナの起動をし直すことを忘れずに。 考えられる原因 前半部分 docker-compose down --volumes このコマンドはコンテナ・イメージ・ボリューム・ネットワーク・未定義コンテナを全てを一括消去するコマンドなので何か履歴が残っていたことが原因？ 後半部分 DBに接続する際のport番号の認識が誤っていたことが原因。 .envのport番号とdocker-compose.ymlの右側のport番号がコンテナのport番号に対応(同じにする) docker-compose.ymlの左側のport番号はホストのport番号(Mk-2やSequel Proに接続する際に入力するport番号はこっち)

M1のため、Dockerイメージのプラットフォームをチェック docker image inspect $(docker images -q) | jq '.[] | {name: .RepoTags[0], arch: .Architecture}'

directory 構成 ./ |- nuxt | |- sample(予定) | |- dockerfile |- docker-compose.yml docker 準備 まずdockerfileを作成する。 ○ dockerfile from 'alpine:latest' run apk update && apk add nodejs yarn workdir /sample ○ docker-compose.yml version: '3' services: nuxt: container_name: nuxt build: context: ./ dockerfile: ./dockerfile tty: true volumes: - ./app:/sample ports: - 3000:3000 終わると、下記コマンドで実行してみる。 docker-compose --build && docker-compose up -d この後は下記コマンドでコンテナを実行しnuxtjsプロジェクトを同時に実行する。 docker exec -it nuxt npx nuxt-creat-app . プロジェクトが生成されたことを確認して、一旦落とします。 docker-compose stop nuxt dockerfile or yml どちらかに起動コマンド追記します。 [dockerfile] ... ※一番下に追記 cmd yarn dev [yml] ... ports: - 3000:3000 ※追記する command: yarn dev これでokでコンテナを再ビルド念の為行う。 docker-compose build && docker-compose up -d へアクセスしてみよう・・・・終わり。 備忘録 今回はとりあえずdockerでnuxtを実行するというものです。 ・networks設定（ porxy <---> nuxt ） ・proｘｙ設定でnuxtコンテナへリクエストを流す などVPS・Cloudeで運用の場合、セキュリティを最低限考える必要があります。

参考サイト https://tech-blog.rakus.co.jp/entry/20180926/microservice Dockerを利用することで エンジニアが開発するバージョンや環境を管理することができる。 このサービスをマイクロサービスというらしい。 CircleCI 今は、Github　Actionといサービスになってる。 Githun上でビルドできるかテストするサービス。 参考 https://qiita.com/zomaphone/items/7e6c3db6b3670f10e23d これはCI/CDという。 以下参考 https://codezine.jp/article/detail/11083

初めに 先日AZ-204に合格したのですが、試験を受けてみて初めて、各サービスを何となくしか理解出来ていないことに気付きました。 「これは受かったとは言えないぞ？」と反省の気持ちでいっぱいですので、これから自分の為に復習していこうと思っています。 本記事で取り扱うこと AZ-204ではコンテナの知識が問われます。 今回は「ソリューションに対するコンテナイメージの作成」対策として、MSの公式ドキュメントのチュートリアルをやりながら、ACRに格納したイメージからAzure App Service(以下、ACR)を使ってWebアプリをデプロイしてみます。 ポイント ACRの仕様を理解する ACRのイメージからAzure App Serviceを使ってWebアプリをデプロイする 構築手順、構築のためのAzure CLIのコマンドを理解する dockerの基本的なコマンド、Dockerfileの記載のお作法を理解する 参考になる公式サイト MSドキュメント Azure App Service を使ってコンテナー化された Web アプリをデプロイして実行する MS Learn Azure App Service を使ってコンテナー化された Web アプリをデプロイして実行する 知識 Azure Container Registryとは AzureのプライベートなDocker Registryサービスです。 3つのSKU Basic、Standard、Premiumの3つのサービスレベルから利用できます。 SKU 説明 料金 Basic 学習用途、PoC等使用頻度が少ないシナリオの場合に利用します。Azure AD認証、Webhook統合等のStandard・Premiumで利用できる機能も試すことが出来ます。ダウンロード帯域やRead/WriteOpsなどのパフォーマンスは制限されています。 ¥18.660/日 Standard 利用できる機能の種類はBasicと同数ですが、Basicよりもパフォーマンスに優れています。 ¥74.660/日 Premium Basic、Standardで利用できる機能に加え、geoレプリケーション、PrivateLink、カスタマーマネージドキーによる暗号化、Docker Content Trust等の機能を利用できます。 ¥186.660/日 実装 作業環境に関して 本作業ではOSにWindowsを利用し、取得済みのAzure Subscriptionを利用します。 無料Subscriptionは利用していないので、無料アカウントでコマンドを実行しようとした際に齟齬が出た場合は大変申し訳ありません。 作業前に、必要なミドルウェアをインストールしてください。 Azure CLI (2.22.1) -> まだの場合はCLIをインストール Git（2.31.1.windows.1） -> まだの場合はGitをインストール Docker -> まだの場合はDocker(Windows版)をインストール イメージの作成 まずMicrosoftが提供するサンプルアプリを利用してACRにDockerイメージを作成します。 サンプルアプリをクローン 私はC:\Dev\az-204\1-4_ACR_imageというフォルダを作成してクローンしています。 コマンド git clone https://github.com/Azure-Samples/docker-django-webapp-linux.git --config core.autocrlf=input 実行結果 Dockerfileの確認 #ベースのイメージを記載。必ず先頭に記述 #FROM image名:tag名 FROM tiangolo/uwsgi-nginx-flask:python3.6 #シェルコマンドの実行。image内にcodeディレクトリを作成 RUN mkdir /code #後続のコマンドの作業ディレクトリを指定 WORKDIR /code #ローカルのrequirements.txtをコンテナ内のcodeディレクトリに移動 ADD requirements.txt /code/ # requirements.txtにリストされたパッケージをインストールする RUN pip install -r requirements.txt --no-cache-dir #クローンしたソースをまとめてコンテナ内に作成したcodeディレクトリにコピーする ADD . /code/ #Key:SSH_PASSWD, Value:"root:Docker!"の環境変数を宣言 ENV SSH_PASSWD "root:Docker!" # openssh-serverをインストールする RUN apt-get update \ && apt-get install -y --no-install-recommends dialog \ && apt-get update \ && apt-get install -y --no-install-recommends openssh-server \ && echo "$SSH_PASSWD" | chpasswd #ローカルにクローンしたファイル（sshd_config, init.sh）を指定したイメージのパス配下にコピーする COPY sshd_config /etc/ssh/ COPY init.sh /usr/local/bin/ #コンテナ内でinit.shを実行 RUN chmod u+x /usr/local/bin/init.sh EXPOSE 8000 2222 #CMD ["python", "/code/manage.py", "runserver", "0.0.0.0:8000"] #init.shを呼び出してSSHサービスとPythonサーバを起動 ENTRYPOINT ["init.sh"] イメージをローカルで作成してテストする イメージ作成のコマンド dockerイメージを作成します。タグを指定していないのでlatestタグが作成されます。 docker build --tag appsvc-tutorial-custom-image . ローカルにイメージが出来たことを確認します。 docker images | grep app* ローカルでコンテナを実行 docker run -p 8000:8000 appsvc-tutorial-custom-image OpenSSHサーバが起動したことを確認します。 ブラウザで確認 ↓↓URL http://localhost:8000/ テナントにログイン ログインコマンド後、ブラウザに認証画面が表示されるのでユーザ・パスワードを入力します。 az login 認証完了後、ローカルでAzure CLIを実行できる状態になります。 リソースグループを作成する AppSvc-DockerTutorial-rgという名前のリソースグループを作成します。 コマンド az group create --name AppSvc-DockerTutorial-rg --location japaneast 実行結果 AppSvc-DockerTutorial-rgが作成されました。 Azure Container Registryにイメージをプッシュする Azure Container Registryを作成 コマンド コンテナを使ってAzure Web Appにデプロイするため、admin-enabledオプションをtrueにします。 az acr create --name acrkumamatsu --resource-group AppSvc-DockerTutorial-rg \ --sku Basic --admin-enabled true 実行結果 Azure PortalでRegistryが作成されたことを確認します。 ログインサーバ名(registry-name.azurecr.io)を確認しておきます。 Registryの資格情報を取得 コンテナにログインするための認証情報を確認します。 コマンド az acr credential show --resource-group AppSvc-DockerTutorial-rg --name acrkumamatsu 実行結果 ※acrは記事の投稿時には削除します。 Azure Portalから確認 Azure Portalからも確認できます。 管理者ユーザも有効になっていますね。 Container Registryにサインイン コマンド コンテナサーバにサインインします。 パスワードの入力が求められますので、先ほど取得したパスワードを入力してEnterを押します。 docker login acrkumamatsu.azurecr.io --username acrkumamatsu 実行結果 Dockerイメージにタグ(バージョン)を付与 コマンド docker tag appsvc-tutorial-custom-image acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest Registryにイメージをプッシュ docker push acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest プッシュしたイメージの確認 latest: digest:…と表示されたらlistコマンドを実行して確認してみます。 az acr repository list -n acrkumamatsu Portalで確認もできます。 リポジトリにイメージがありますね。 タグが付与されています。 RegistryからイメージをデプロイするようにApp Serviceを構成 App Serviceプランを作成 Web Appsの構築・運用の方法もAZ-204に合格するためには理解しておかなくてはなりません。 Azure CLIやPowerShellでの構築方法、各Azureサービスの構築順序を理解しておきましょう。 まずはApp Serviceプランを作成します。 プランとは、Webアプリをホストする為のハードウェアに採用するスペックのことです。 Linuxベースのプランを使用するので-is-linuxオプションが設定されています。 az appservice plan create --resource-group AppSvc-DockerTutorial-rg \ --name AppSvc-DockerTutorial-plan --is-linux Portalで確認することもできます。 Web アプリを作成 作成したApp Serviceプラン上でWeb アプリを作成します。 az webapp create --resource-group AppSvc-DockerTutorial-rg ` --plan AppSvc-DockerTutorial-plan --name kumamatsuapp ` --deployment-container-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest WEBSITES_PORT環境変数を設定 WEBSITES_PORTとはWEBサイトを公開する際にコンテナ側のポートとして利用する値を設定する項目です。 チュートリアル通り、8000を利用します。 az webapp config appsettings set --resource-group AppSvc-DockerTutorial-rg \ --name kumamatsuapp --settings WEBSITES_PORT=8000 結果をPortalで確認しましょう。 コンテナの引数として、アプリケーション設定に新たな項目が追加されました。 Web アプリのマネージドIDを有効 WebアプリでマネージドIDを有効化します。 az webapp identity assignコマンドを利用します。 --queryオプションを使っていますが、これはjsonで出力されるcliの結果から指定したKey項目に紐づくValueを出力したい際に設定します。 有効化したマネージドIDは後工程で利用します。 principalId=`az webapp identity assign --resource-group AppSvc-DockerTutorial-rg --name kumamatsuapp \ --query principalId --output tsv` このコマンドを実行するとAzure Portalの[App Service]>[ID]の状態がオンになります。 サブスクリプション ID を取得 subscription_id=`az account show --query id --output tsv` Container Registryへのアクセス許可をWebアプリに与える az role assignment create --assignee $principalId \ --scope /subscriptions/$subscription_id/resourceGroups/AppSvc-DockerTutorial-rg/providers/Microsoft.ContainerRegistry/registries/acrkumamatsu \ --role "AcrPull" 何やらエラーが発生します。 以下のサイトによると、GitをインストールしているWindows OSでAzure CLIを利用する際に出るようです。 Unable to create service principal with azure cli from git bash shell, no connection adapters were found. もう一度同じコマンドを実行しますが、先頭に「MSYS_NO_PATHCONV=1 」を付けます。 MSYS_NO_PATHCONV=1 az role assignment create --assignee $principalId \ --scope /subscriptions/$subscription_id/resourceGroups/AppSvc-DockerTutorial-rg/providers/Microsoft.ContainerRegistry/registries/acrkumamatsu \ --role "AcrPull" WebアプリのマネージドIDにacrkumamatsu Registryに対するロールを設定します。 Azure Portalで設定を見てみましょう。 Container Registryのアクセス制御(IAM)に先ほど設定したAcrPullというロールが表示されています。 このロールを利用できるのはApp Service kumamatsuappです。 マネージドIDを利用した認証のイメージです。 イメージをデプロイしてアプリをテスト Container RegistryとWebアプリ用にデプロイするイメージを指定 az webapp config container set --name kumamatsuapp \ --resource-group AppSvc-DockerTutorial-rg \ --docker-custom-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest \ --docker-registry-server-url https://acrkumamatsu.azurecr.io コマンドを実行したら、「No credential was provided to access Azure Container Registry. Trying to look up... 」というWarningが出力されました。 これはRegistryに対する認証にユーザ名・パスワードではなくアプリのマネージドIDを使用していることを表しています。 App ServiceのDeploy Centerを見てみましょう。 Web AppがAzure Container Registryの特定のイメージ・タグと紐づいていることがわかります。 URLにアクセス ブラウザからデプロイが完了したかどうかを確認してみましょう。 ↓↓↓URL https://kumamatsuapp.azurewebsites.net/ アプリのコードを変更して再デプロイ index.htmlの変更 ではソースコードを変更して再デプロイしてみます。 docker-django-webapp-linux フォルダーにあるファイルapp/templates/app/index.htmlの中身を変更します。 イメージをリビルド docker-django-webapp-linux フォルダーに移動してイメージ(v1.0.1)をリビルドします。 docker build -t appsvc-tutorial-custom-image:v1.0.1 . イメージをRegistryにプッシュ docker push acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:v1.0.1 Azure Portalで見てみましょう。 v1.0.1タグでイメージがプッシュされたことがわかります。 Container RegistryとWebアプリ用にデプロイするイメージを指定 az webapp config container set --name kumamatsuapp \ --resource-group AppSvc-DockerTutorial-rg \ --docker-custom-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:v1.0.1 \ --docker-registry-server-url https://acrkumamatsu.azurecr.io PortalのDeploy Centerを見てましょう。タグが置き換わっています。 Webアプリを再起動 再起動コマンドを実行し、Webアプリを再起動します。 az webapp restart --name kumamatsuapp --resource-group AppSvc-DockerTutorial-rg ブラウザから確認します。 修正が反映されていることが確認できました。 参考 以下のサイト・動画を参考にさせていただきました。ありがとうございました。 Webサイト DockerfileのADDとCOPY、CMDとENTRYPOINTの違いを整理 3つの観点から見たコンテナの構造とは？ WindowsでDockerを始める手順 【Microsoft Azure】DockerコンテナをACR経由でAppServiceにデプロイする Content trust in Docker Udemy動画 米シリコンバレーDevOps監修！超Docker完全入門(2020)【優しい図解説とハンズオンLab付き】

初めに 先日AZ-204に合格したのですが、試験を受けてみて初めて、各サービスを何となくしか理解出来ていないことに気付きました。 「これは受かったとは言えないぞ？」と反省の気持ちでいっぱいですので、これから自分の為に復習していこうと思っています。 本記事で取り扱うこと AZ-204ではコンテナの知識が問われます。 今回は「ソリューションに対するコンテナイメージの作成」対策として、MSの公式ドキュメントのチュートリアルをやりながら、ACRに格納したイメージからAzure App Service(以下、ACR)を使ってWebアプリをデプロイしてみます。 ポイント ACRの仕様を理解する ACRのイメージからAzure App Serviceを使ってWebアプリをデプロイする 構築手順、構築のためのAzure CLIのコマンドを理解する dockerの基本的なコマンド、Dockerfileの記載のお作法を理解する 参考になる公式サイト MSドキュメント Azure App Service を使ってコンテナー化された Web アプリをデプロイして実行する MS Learn Azure App Service を使ってコンテナー化された Web アプリをデプロイして実行する 知識 Azure Container Registryとは AzureのプライベートなDocker Registryサービスです。 3つのSKU Basic、Standard、Premiumの3つのサービスレベルから利用できます。 SKU 説明 料金 Basic 学習用途、PoC等使用頻度が少ないシナリオの場合に利用します。Azure AD認証、Webhook統合等のStandard・Premiumで利用できる機能も試すことが出来ます。ダウンロード帯域やRead/WriteOpsなどのパフォーマンスは制限されています。 ¥18.660/日 Standard 利用できる機能の種類はBasicと同数ですが、Basicよりもパフォーマンスに優れています。 ¥74.660/日 Premium Basic、Standardで利用できる機能に加え、geoレプリケーション、PrivateLink、カスタマーマネージドキーによる暗号化、Docker Content Trust等の機能を利用できます。 ¥186.660/日 実装 作業環境に関して 本作業ではOSにWindowsを利用し、取得済みのAzure Subscriptionを利用します。 無料Subscriptionは利用していないので、無料アカウントでコマンドを実行しようとした際に齟齬が出た場合は大変申し訳ありません。 作業前に、必要なミドルウェアをインストールしてください。 Azure CLI (2.22.1) -> まだの場合はCLIをインストール Git（2.31.1.windows.1） -> まだの場合はGitをインストール Docker -> まだの場合はDocker(Windows版)をインストール イメージの作成 まずMicrosoftが提供するサンプルアプリを利用してACRにDockerイメージを作成します。 サンプルアプリをクローン 私はC:\Dev\az-204\1-4_ACR_imageというフォルダを作成してクローンしています。 コマンド git clone https://github.com/Azure-Samples/docker-django-webapp-linux.git --config core.autocrlf=input 実行結果 Dockerfileの確認 #ベースのイメージを記載。必ず先頭に記述 #FROM image名:tag名 FROM tiangolo/uwsgi-nginx-flask:python3.6 #シェルコマンドの実行。image内にcodeディレクトリを作成 RUN mkdir /code #後続のコマンドの作業ディレクトリを指定 WORKDIR /code #ローカルのrequirements.txtをコンテナ内のcodeディレクトリに移動 ADD requirements.txt /code/ # requirements.txtにリストされたパッケージをインストールする RUN pip install -r requirements.txt --no-cache-dir #クローンしたソースをまとめてコンテナ内に作成したcodeディレクトリにコピーする ADD . /code/ #Key:SSH_PASSWD, Value:"root:Docker!"の環境変数を宣言 ENV SSH_PASSWD "root:Docker!" # openssh-serverをインストールする RUN apt-get update \ && apt-get install -y --no-install-recommends dialog \ && apt-get update \ && apt-get install -y --no-install-recommends openssh-server \ && echo "$SSH_PASSWD" | chpasswd #ローカルにクローンしたファイル（sshd_config, init.sh）を指定したイメージのパス配下にコピーする COPY sshd_config /etc/ssh/ COPY init.sh /usr/local/bin/ #コンテナ内でinit.shを実行 RUN chmod u+x /usr/local/bin/init.sh EXPOSE 8000 2222 #CMD ["python", "/code/manage.py", "runserver", "0.0.0.0:8000"] #init.shを呼び出してSSHサービスとPythonサーバを起動 ENTRYPOINT ["init.sh"] イメージをローカルで作成してテストする イメージ作成のコマンド dockerイメージを作成します。タグを指定していないのでlatestタグが作成されます。 docker build --tag appsvc-tutorial-custom-image . ローカルにイメージが出来たことを確認します。 docker images | grep app* ローカルでコンテナを実行 docker run -p 8000:8000 appsvc-tutorial-custom-image OpenSSHサーバが起動したことを確認します。 ブラウザで確認 ↓↓URL http://localhost:8000/ テナントにログイン ログインコマンド後、ブラウザに認証画面が表示されるのでユーザ・パスワードを入力します。 az login 認証完了後、ローカルでAzure CLIを実行できる状態になります。 リソースグループを作成する AppSvc-DockerTutorial-rgという名前のリソースグループを作成します。 コマンド az group create --name AppSvc-DockerTutorial-rg --location japaneast 実行結果 AppSvc-DockerTutorial-rgが作成されました。 Azure Container Registryにイメージをプッシュする Azure Container Registryを作成 コマンド コンテナを使ってAzure Web Appにデプロイするため、admin-enabledオプションをtrueにします。 az acr create --name acrkumamatsu --resource-group AppSvc-DockerTutorial-rg \ --sku Basic --admin-enabled true 実行結果 Azure PortalでRegistryが作成されたことを確認します。 ログインサーバ名(registry-name.azurecr.io)を確認しておきます。 Registryの資格情報を取得 コンテナにログインするための認証情報を確認します。 コマンド az acr credential show --resource-group AppSvc-DockerTutorial-rg --name acrkumamatsu 実行結果 ※acrは記事の投稿時には削除します。 Azure Portalから確認 Azure Portalからも確認できます。 管理者ユーザも有効になっていますね。 Container Registryにサインイン コマンド コンテナサーバにサインインします。 パスワードの入力が求められますので、先ほど取得したパスワードを入力してEnterを押します。 docker login acrkumamatsu.azurecr.io --username acrkumamatsu 実行結果 Dockerイメージにタグ(バージョン)を付与 コマンド docker tag appsvc-tutorial-custom-image acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest Registryにイメージをプッシュ docker push acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest プッシュしたイメージの確認 latest: digest:…と表示されたらlistコマンドを実行して確認してみます。 az acr repository list -n acrkumamatsu Portalで確認もできます。 リポジトリにイメージがありますね。 タグが付与されています。 RegistryからイメージをデプロイするようにApp Serviceを構成 App Serviceプランを作成 Web Appsの構築・運用の方法もAZ-204に合格するためには理解しておかなくてはなりません。 Azure CLIやPowerShellでの構築方法、各Azureサービスの構築順序を理解しておきましょう。 まずはApp Serviceプランを作成します。 プランとは、Webアプリをホストする為のハードウェアに採用するスペックのことです。 Linuxベースのプランを使用するので-is-linuxオプションが設定されています。 az appservice plan create --resource-group AppSvc-DockerTutorial-rg \ --name AppSvc-DockerTutorial-plan --is-linux Portalで確認することもできます。 Web アプリを作成 作成したApp Serviceプラン上でWeb アプリを作成します。 az webapp create --resource-group AppSvc-DockerTutorial-rg ` --plan AppSvc-DockerTutorial-plan --name kumamatsuapp ` --deployment-container-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest WEBSITES_PORT環境変数を設定 WEBSITES_PORTとはWEBサイトを公開する際にコンテナ側のポートとして利用する値を設定する項目です。 チュートリアル通り、8000を利用します。 az webapp config appsettings set --resource-group AppSvc-DockerTutorial-rg \ --name kumamatsuapp --settings WEBSITES_PORT=8000 結果をPortalで確認しましょう。 コンテナの引数として、アプリケーション設定に新たな項目が追加されました。 Web アプリのマネージドIDを有効 WebアプリでマネージドIDを有効化します。 az webapp identity assignコマンドを利用します。 --queryオプションを使っていますが、これはjsonで出力されるcliの結果から指定したKey項目に紐づくValueを出力したい際に設定します。 有効化したマネージドIDは後工程で利用します。 principalId=`az webapp identity assign --resource-group AppSvc-DockerTutorial-rg --name kumamatsuapp \ --query principalId --output tsv` このコマンドを実行するとAzure Portalの[App Service]>[ID]の状態がオンになります。 サブスクリプション ID を取得 subscription_id=`az account show --query id --output tsv` Container Registryへのアクセス許可をWebアプリに与える az role assignment create --assignee $principalId \ --scope /subscriptions/$subscription_id/resourceGroups/AppSvc-DockerTutorial-rg/providers/Microsoft.ContainerRegistry/registries/acrkumamatsu \ --role "AcrPull" 何やらエラーが発生します。 以下のサイトによると、GitをインストールしているWindows OSでAzure CLIを利用する際に出るようです。 Unable to create service principal with azure cli from git bash shell, no connection adapters were found. もう一度同じコマンドを実行しますが、先頭に「MSYS_NO_PATHCONV=1 」を付けます。 MSYS_NO_PATHCONV=1 az role assignment create --assignee $principalId \ --scope /subscriptions/$subscription_id/resourceGroups/AppSvc-DockerTutorial-rg/providers/Microsoft.ContainerRegistry/registries/acrkumamatsu \ --role "AcrPull" WebアプリのマネージドIDにacrkumamatsu Registryに対するロールを設定します。 Azure Portalで設定を見てみましょう。 Container Registryのアクセス制御(IAM)に先ほど設定したAcrPullというロールが表示されています。 このロールを利用できるのはApp Service kumamatsuappです。 マネージドIDを利用した認証のイメージです。 イメージをデプロイしてアプリをテスト Container RegistryとWebアプリ用にデプロイするイメージを指定 az webapp config container set --name kumamatsuapp \ --resource-group AppSvc-DockerTutorial-rg \ --docker-custom-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:latest \ --docker-registry-server-url https://acrkumamatsu.azurecr.io コマンドを実行したら、「No credential was provided to access Azure Container Registry. Trying to look up... 」というWarningが出力されました。 これはRegistryに対する認証にユーザ名・パスワードではなくアプリのマネージドIDを使用していることを表しています。 App ServiceのDeploy Centerを見てみましょう。 Web AppがAzure Container Registryの特定のイメージ・タグと紐づいていることがわかります。 URLにアクセス ブラウザからデプロイが完了したかどうかを確認してみましょう。 ↓↓↓URL https://kumamatsuapp.azurewebsites.net/ アプリのコードを変更して再デプロイ index.htmlの変更 ではソースコードを変更して再デプロイしてみます。 docker-django-webapp-linux フォルダーにあるファイルapp/templates/app/index.htmlの中身を変更します。 イメージをリビルド docker-django-webapp-linux フォルダーに移動してイメージ(v1.0.1)をリビルドします。 docker build -t appsvc-tutorial-custom-image:v1.0.1 . イメージをRegistryにプッシュ docker push acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:v1.0.1 Azure Portalで見てみましょう。 v1.0.1タグでイメージがプッシュされたことがわかります。 Container RegistryとWebアプリ用にデプロイするイメージを指定 az webapp config container set --name kumamatsuapp \ --resource-group AppSvc-DockerTutorial-rg \ --docker-custom-image-name acrkumamatsu.azurecr.io/appsvc-tutorial-custom-image:v1.0.1 \ --docker-registry-server-url https://acrkumamatsu.azurecr.io PortalのDeploy Centerを見てましょう。タグが置き換わっています。 Webアプリを再起動 再起動コマンドを実行し、Webアプリを再起動します。 az webapp restart --name kumamatsuapp --resource-group AppSvc-DockerTutorial-rg ブラウザから確認します。 修正が反映されていることが確認できました。 参考 以下のサイト・動画を参考にさせていただきました。ありがとうございました。 Webサイト DockerfileのADDとCOPY、CMDとENTRYPOINTの違いを整理 3つの観点から見たコンテナの構造とは？ WindowsでDockerを始める手順 【Microsoft Azure】DockerコンテナをACR経由でAppServiceにデプロイする Content trust in Docker Udemy動画 米シリコンバレーDevOps監修！超Docker完全入門(2020)【優しい図解説とハンズオンLab付き】

0.概要　 何度もいいますが、知らない単語が出た瞬間ググってください！！！！！ ①の全体像編がこちらにあるのでこちらを一読してからだと理解がスムーズかと！！！ https://qiita.com/SG_Sg/items/6b8ce48567b6b6602805　 ②のDocker環境構築編もあるのでこちらでデプロイするアプリを作成してます https://qiita.com/SG_Sg/items/6b8ce48567b6b6602805 今回で作成するは具体的にいうと赤いとこ 以上が完成すると、世の中にアプリを公開することができます！ つまり 特定のURLを叩くと誰でも作成したWebアプリを動かせる状態　⇦目指すはここ AWSのEC2インスタンスを利用してデプロイを行うための流れ AWS?EC2インスタンス？とはなんですか？？ AWS EC2インスタンスとは、Amazonが提供している仮想サーバー構築サービスです。。。。難しいですかね。 ざっくり言うと よくサーバーってなんかでかい四角い箱のイメージですが、AWSのEC２インスタンスはそれをクラウド上に作れる！！ （EC2インスタンスとは OSを載せた仮想サーバーです） まあ概念的なものはおいといて手を動かしましょう。 上の図を完成させるための流れを説明します。 ①AWSにアカウントを作成する。 ②EC2インスタンスを作成する ③EC2インスタンスにSSHでアクセス ④EC2インスタンス（Ubuntu）に必要なアプリケーションをインストール ⑤GitHubからプロジェクト（ソースコード）をPULL ⑥Laravelをインストールしてのトップ画面を表示 ⑦データベースと接続 ⑧URLを叩いてアクセス！！ 上の７つ行えば完了です！ さあやっていきましょう！ ①AWSにアカウントを作成する さて、AWSのアカウントを作成するのですが、、、 以下公式 https://aws.amazon.com/jp/register-flow/ わかりやすそうな動画つきのサイト https://blog.serverworks.co.jp/tech/2020/07/17/hajimeteno_aws_account/ 今回はAWSのEC2インスタンスというサービスを使うので、１年間は基本的にお金がかかりません！ 利用サービスによっては一部料金をとられたりしますのでご注意ください。 https://www.fenet.jp/aws/column/aws-beginner/197/ 上記を参考に設定してもらえればお金はかからないことがわかります。 以上の操作でアカウントが作成し、TOP画面にきたら右上がこちらは東京（日本）にしてあることを必ず確認してください！ ヨーロッパ等になっていたらかならずタップして　アジアパシフィック「東京」　にするようにお願いします。 ②EC2インスタンスを作成する １,サービスをタップし、EC2をタップ。 2,インスタンスをタップ 3,EC2インスタンス一覧が表示されたらインスタンスを起動をタップ 4,今回は　Ubuntu Server 20.04 LTS (HVM), SSD Volume Type - ami-059b6d3840b03d6dd (64 ビット x86) を使いますのでこれを選択。（無料枠対象でUbuntuを使います。） 5,インスタンスタイプの設定。ここでインスタンスの容量を設定。今回は無料枠で行うので無料枠のt2.microを使います。 そして次のステップ：インスタンスの詳細の設定をタップ （ここからの設定はあとで変更できるので確認と作成でもいいですが、先に設定しちゃいましょう！！） 6,詳細にネットワークの設定をできますが、今回はこちらデフォルト（そのまま）で次のステップ：ストレージの追加をタップ 7,こちらでストレージサイズをいじれますが、今回はこちらもデフォルト（そのまま）で次のステップ：タグの追加をタップ 8,タグを追加できますが、今回は追加せずそのままで次のステップ：セキュリティグループの設定をタップ 9,セキュリティグループを設定します。 新しいセキュリティグループを作成する。にしてグループ名説明は自分でわかるように設定。 ルールの追加をタップして タイプは以下のように追加してください。 ※SSHの部分のポート範囲をマイIPしていますが、こちらは自分IPを使って接続しますよーの意味です。 そのため、自分のIPがコロコロ変わるWifi回線を使っている方は利用するたびにSSHのポート範囲を変えなければいけませんのでご注意！！ もし不安でしたら今回はテストですので SSHのソースを　任意の場所　にして　0.0.0.0/0, ::/0　で良いと思います。 入力し終わったら確認と作成をタップ！ 10,作成の確認画面がでますが、そのまま「起動」ボタンを押しましょう！ 11,キーファイルを作成します。まずはプルダウンを　新しいキーペアの作成　 キーペア名は任意ですが「HelloLaravel」とします 次にキーペアのダウンロードをタップ 　ダウンロードされた「HelloLaravel.pem」をデスクトップにおいておきます。鍵の場所は必ずわかるようにしておいてください。 　※このダウンロードされたキーファイルはその名も通り、このインスタンスの中に入るための鍵なので無くさないように大切に保存しましょう。 　今回はデスクトップにおきますが、本当は/.sshフォルダの中にあるとよいですね！ 鍵ファイルをダウンロードできたら、インスタンスの作成　をタップ！ 12,これでインスタンスを作成できたので　インスタンスの表示　で開くなど3のインスタンス一覧まで戻りましょう。 そして、インスタンスが作成してから動かせるようになるまで少し時間がかかるので少々おまちください。 数分たったらこんな風になっていればOKです！ ステータスチェックが2/2になっていることを確認してください！ これでインスタンスの作成が完了です！！ ③EC2インスタンスにSSHでアクセス 1,ターミナル（端末）を開いて、権限を変更し、SSHでアクセスする。 ターミナルを開き、ホームディレクトリ（最初の階層）で 先ほど保存した、鍵ファイルの権限を変えます（これをしないと接続できません） //鍵ファイルの権限を読み取りもできるように変更 ~ chmod 600 ~/Desktop/HelloLaravel.pem //鍵ファイルで作成したインスタンスにSSHでログイン ~ ssh -i ~/Desktop/HelloLaravel.pem ubuntu@（EC2インスタンスのパブリックIPアドレス） ※（EC2インスタンスのパブリックIPアドレス）これは↓の赤枠の部分に書いてある数字です。赤枠の左の部分の四角いマークをタップすればコピーできます ↓こうなっていたらアクセス完了です！ ubuntu@ip-自分のIP:~$ ④EC2インスタンス（Ubuntu）に必要なアプリケーションをインストール 1,php7.4をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt-get update //PHP PPA Repositoryを追加 ubuntu@ip-自分のIP:~$ sudo apt -y install software-properties-common ubuntu@ip-自分のIP:~$ sudo add-apt-repository ppa:ondrej/php ubuntu@ip-自分のIP:~$ sudo apt-get update //PHPインストール ubuntu@ip-自分のIP:~$ sudo apt -y install php7.4 //バージョン確認 ubuntu@ip-自分のIP:~$ php -v PHP 7.4.16 (cli) (built: Mar 5 2021 07:54:38) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.16, Copyright (c), by Zend Technologies 2,MySQL 8.0をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt update //mysqlインストール ubuntu@ip-自分のIP:~$ sudo apt install -y mysql-server //mysqlを動かす ubuntu@ip-自分のIP:~$ sudo service mysql start //バージョン確認 ubuntu@ip-自分のIP:~$ sudo mysql -u root -e'select version();' +-------------------------+ | version() | +-------------------------+ | 8.0.23-0ubuntu0.20.04.1 | +-------------------------+ 3,nginx1.18をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt update //nginxをインストール ubuntu@ip-自分のIP:~$ sudo apt install -y nginx //場所を確認 ubuntu@ip-自分のIP:~$ sudo which nginx /usr/sbin/nginx //バージョン確認 ubuntu@ip-自分のIP:~$ nginx -v nginx version: nginx/1.18.0 (Ubuntu) nginxが動いているのかの確認 ubuntu@ip-自分のIP:~$ sudo service nginx start ubuntu@ip-自分のIP:~$ sudo service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:> 　　　//↓がactiveになってたらOK。 Active: active (running) since Sun 2021-04-11 06:44:04 UTC; 1s ago Docs: man:nginx(8) ・・・・・・ //Failになっていたらポートが占領されていたりするので ubuntu@ip-自分のIP:~$ sudo lsof -i:80 //確認して一度占領ポートを全部消す。数字は↑で確認した番号 ubuntu@ip-自分のIP:~$ sudo kill 23930 23933 23934 23935 23936 23937 25159 http://(EC2インスタンスのパブリックIPアドレス)/index をgoogleでアクセス！notfoundでnginxが動いていることを確認 ※番外　HTMLファイルをテストで表示 ubuntu@ip-自分のIP:/var/www$ ls html ubuntu@ip-自分のIP:/var/www$ cd html/ ubuntu@ip-自分のIP:/var/www/html$ vi test.html ↓test.htmlを作成 <html> <body>HTMLTEST</body> </html> http://(EC2インスタンスのパブリックIPアドレス)/test.html をgoogleでアクセス！ HTMLTESTが表示されていたらnginxでHTMLが表示できていることを確認できる。 ④php7.4-fpmをインストールする ubuntu@ip-自分のIP:~$ sudo apt update //php-fpmをインストール ubuntu@ip-自分のIP:~$ sudo apt install php7.4-fpm //バージョンを確認 ubuntu@ip-自分のIP:~$ php-fpm7.4 -v PHP 7.4.16 (fpm-fcgi) (built: Mar 5 2021 07:54:38) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.16, Copyright (c), by Zend Technologies ⑤GitHubからプロジェクト（ソースコード）をクローン ubuntu@ip-自分のIP:/var/www$ sudo git clone https://github.com/K-SG/DockerLaravelTestProject.git Cloning into 'DockerLaravelTestProject'... remote: Enumerating objects: 164, done. remote: Counting objects: 100% (164/164), done. remote: Compressing objects: 100% (119/119), done. remote: Total 164 (delta 25), reused 157 (delta 18), pack-reused 0 Receiving objects: 100% (164/164), 72.99 KiB | 7.30 MiB/s, done. Resolving deltas: 100% (25/25), done. //確認 ubuntu@ip-自分のIP:/var/www$ ls DockerLaravelTestProject html //プロジェクトの権限をwww-dataに変更 ubuntu@ip-自分のIP:/var/www$ sudo chown -R www-data:www-data DockerLaravelTestProject/ ubuntu@ip-172-31-35-119:/var/www$ ls -al total 16 drwxr-xr-x 4 root root 4096 Apr 18 06:04 . drwxr-xr-x 14 root root 4096 Apr 18 05:51 .. drwxr-xr-x 5 www-data www-data 4096 Apr 18 06:04 DockerLaravelTestProject drwxr-xr-x 2 root root 4096 Apr 18 06:12 html ⑥nginxの設定を変えて、phpファイルが表示できることを確認 1,nginxの設定ファイルを変える ubuntu@ip-自分のIP:/var/www$ cd /etc/nginx/sites-enabled/ ubuntu@ip-自分のIP:/etc/nginx/sites-enabled$ sudo vi default 以下に変更する。 server { listen 80 default_server; listen [::]:80 default_server; # SSL configuration # # listen 443 ssl default_server; # listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # # include snippets/snakeoil.conf; root /var/www/DockerLaravelTestProject/backend/public; # Add index.php to the list if you are using PHP 　　　　　 index index.html index.htm index.nginx-debian.html index.php; server_name _; location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. # try_files $uri $uri/ =404; try_files $uri $uri/ /index.php?$query_string; } # pass PHP scripts to FastCGI server # location ~ \.php$ { include snippets/fastcgi-php.conf; # # # With php-fpm (or other unix sockets): fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # # With php-cgi (or other tcp sockets): # fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; include fastcgi_params; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } ※設定ファイルを変更（↑のように）、サーバーがうまく動作していない場合はnginxを必ず再起動 ubuntu@ip-自分のIP:~$ sudo service nginx stop ubuntu@ip-自分のIP:~$ sudo service nginx start //状態を確認 ubuntu@ip-自分のIP:~$ sudo service nginx status 2,プロジェクトにPHPファイルを作って接続を確認する。 //プロジェクトの中のpublicまで移動 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend/public$ ls favicon.ico index.php robots.txt web.config ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend/public$ sudo vi phpinfo.php ↓で保存phpinfo.phpを作成 <?php phpinfo(); ?> http://(EC2インスタンスのパブリックIPアドレス)/phpinfo.php をgoogleでアクセス！ PHPの情報が表示されていたらnginxでPHPのファイルがが表示できていることを確認できる。 3,現状足りていないPHPに必要なものをインストール ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo apt install php7.4-mbstring php-xml php-json ⑦LaravelをインストールしてWelcome画面表示する 1,Laravelをインストール //コンポーザーをインストール。（ここでエラーが出る場合、PHPに必要なものが入っていないのでググってインストールしよう！） ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo composer install //composer install 時は .env 環境変数ファイルは作成されないので、 .env.example を元にコピーして作成します ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo cp .env.example .env ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ cd ../ //backend以下の権限がないため権限を変更する ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject$ sudo chmod 777 -R backend/ ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject$ cd backend/ //アプリケーションキーを生成する ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ php artisan key:generate Application key set successfully. //APP_KEY=base64:bfeLkhwqXIFbGtwhaJOp0TpfHTJD3Q+SRi7lVwB・・・・となっていることを確認。 2,welcome画面を表示する http://(EC2インスタンスのパブリックIPアドレス) をgoogleでアクセス！ ↑のようなものが表示されたらOK!! ⑧データベースを作成する ※【ギリ初心者向け】Laravel Docker AWS(EC2) Webアプリ（PHP)を0から簡単にデプロイする方法（無料）　②で作成した合わせるのでファイルをみながらすすめます。 1,mysqlにログインしてユーザーを作成する。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo mysql -u root -p //PWを求められますがrootユーザーはMACに入るときのPW　を入力 Enter password: ・・・・・・ //mysqlに入れたことを確認 mysql> 2,プロジェクトの.envファイルをみながらユーザー、DBを作成する！ その前にプロジェクトの.envファイルのDBの部分をみる DB_CONNECTION=mysql DB_HOST=db DB_PORT=3306 DB_DATABASE=sg_db DB_USERNAME=sg DB_PASSWORD=sg //sgというdbユーザーを作成。PWはsg mysql> create user 'sg'@'localhost' identified by 'sg'; Query OK, 0 rows affected (0.01 sec) //databaseを作る権限をsgユーザーに付与する mysql> GRANT ALL ON sg_db.* TO 'sg'@'localhost'; Query OK, 0 rows affected (0.00 sec) //mysqlからでる mysql> exit; Bye ubuntu@ip-自分のIP:~$ sudo mysql -u sg -p //PWはさっき設定したsg Enter password: //データベースを作成する mysql> create database sg_db; Query OK, 1 row affected (0.01 sec)w mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | sg_db | +--------------------+ //抜ける mysql> exit; Bye 3,テーブルを作るためにマイグレーションを実行する！ まずはマイグレーションを実行するために、mysqlに接続できるように設定を変更する。 ※マイグレーションがうまくいかなかったら都度ググりましょう！結構うまくいかないパターンはあります。。キャッシュがたまっていたり。。。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo vi .env //DBの部分を↓に変更。HOSTはlocalhost DB_CONNECTION=mysql DB_HOST=localhost DB_PORT=3306 DB_DATABASE=sg_db DB_USERNAME=sg DB_PASSWORD=sg ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo php artisan migrate Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table (65.08ms) Migrating: 2014_10_12_100000_create_password_resets_table Migrated: 2014_10_12_100000_create_password_resets_table (55.04ms) Migrating: 2019_08_19_000000_create_failed_jobs_table Migrated: 2019_08_19_000000_create_failed_jobs_table (59.14ms) Migrating: 2021_01_03_090902_create_people_table Migrated: 2021_01_03_090902_create_people_table (31.46ms) //マイグレーションできたらデータベースの中にテーブルが作られていることを確認すると良い //この流れでSeederも入れてしまおう。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ php artisan db:seed Seeding: Database\Seeders\PeopleTableSeeder Seeded: Database\Seeders\PeopleTableSeeder (11.62ms) Database seeding completed successfully. 4,アプリを表示して接続を確認！ http://(EC2インスタンスのパブリックIPアドレス)/hello これにて終了です。 お疲れ様でした。 これでLaravelアプリをEC2にデプロイすることができました！！ここのDBとかをmysqlworkbenchとかで管理できたら良いですね！！ それでは良いWebアプリ制作ライフを！！

概要 Docker環境に下記のようなメモリ不足のエラーが起きました。 その原因と解決策を共有します。 mmap() failed: [12] Cannot allocate memory PHP Fatal error: Out of memory (allocated 61079552) (tried to allocate 135168 bytes) (省略) 再現環境 MacBook Pro バージョン : 11.2 チップ : Apple M1 Docker Desktop for Mac バージョン : 3.3.1 その他設定 php.ini memory_limit : 1280M 原因 M1 MacでDocker(3.3.1)を使うとメモリリークをしてしまうバグがあり、 負荷が高い処理をすると止まってしまうとのことです。 Memory Leak on M1 Macs 対策 Docker Desktop for M1を使い、Dockerのバージョンが3.1.0になったことで解決いたしました。

Rails×React×Dockerにて開発環境を構築したので、アウトプット用に残しておきます。 下記の記事を参考にして構築していきました。 DockerでRuby on Rails + Reactを別々にアプリ作成する環境構築手順 Docker使ってReact × Rails(API)の環境構築 前提知識の確認 自分は初学者でrailsでしかWebアプリを構築した事がなかったのですが、Dockerで開発環境を構築する場合は、 rails newをする前に、いくつかのファイルを用意する必要があります。 ※詳しくはこちらが分かり易い Docker 公式ドキュメントの Rails Quickstart 完全解説 簡単に伝えると、プロジェクトのディレクトを作成した後rails newをする前にDocker環境構築用のファイルをいくつか作成した後で、 rails newやcreate-react-app行う。 フォルダ構造は下記のような形からスタートする アプリ名 backend Dockerfile entrypoint.sh Gemfile Gemfile.lock frontend Dockerfile docker-compose.yml ①ファイルを用意していく 上記構造のディレクトリとファイルを作成したら、中身を記述していく。 ※アプリ名と記載がある部分は、ご自分で作成中のアプリ名に変更して下さい。 docker-compose.yml docker-compose.yml version: "3" services: db: image: mariadb command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci environment: MYSQL_DATABASE: "アプリ名_development" MYSQL_ROOT_PASSWORD: "password" volumes: - mysql-data:/var/lib/mysql/data - /tmp/dockerdir:/etc/mysql/conf.d/ ports: - 3306:3306 backend: build: context: ./backend/ dockerfile: Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3001 -b '0.0.0.0'" volumes: - .:/アプリ名 ports: - "3001:3001" depends_on: - db frontend: build: context: ./frontend/ dockerfile: Dockerfile volumes: - ./frontend:/usr/src/app/frontend working_dir: /usr/src/app/frontend command: sh -c "npm start --host 0.0.0.0 --port 3000" ports: - "3000:3000" stdin_open: true volumes: mysql-data: {} dbには、mysqlを使用しております。 rails(backend)側では、3001番ポートで立ち上がるよう設定しており、react(frontend)側では3000番ポートにしてあります。 docker-compose.yml backend: build: ports: - "3001:3001" frontend: build: ports: - "3000:3000" rails側のファイル用意（全部で4つ） Dockerfile entrypoint.sh Gemfile Gemfile.lock Dockerfile(アプリ名/backend/Dockerfile) Dokcerfile. FROM ruby:2.7.2 RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs RUN mkdir /アプリ名 WORKDIR /アプリ名 COPY Gemfile /アプリ名/Gemfile COPY Gemfile.lock /アプリ名/Gemfile.lock RUN bundle install COPY . /アプリ名 # Add a script to be executed every time the container starts. COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3001 # Start the main process. CMD ["rails", "server", "-b", "0.0.0.0"] Gemfile Gemfile. source 'https://rubygems.org' gem 'rails', '5.2.5' railsのバージョンは5.2.5にしてあります。 最近発生していたmimemagi関連のエラーを回避する為ですが、 rails6系が良い方は、6.0.3.6又は6.1.3.1であれば、エラー回避出来るようなので、どちらかを指定して下さい。 ※詳しくは下記を参照下さい RailsのGPL混入問題についてまとめ（mimemagic） Gemfile.lock touch Gemfile.lockで作成したら、空ファイルのままで大丈夫です。 entrypoint.sh entrypoint.sh #!/bin/bash set -e # Remove a potentially pre-existing server.pid for Rails. rm -f /アプリ名/tmp/pids/server.pid # Then exec the container's main process (what's set as CMD in the Dockerfile). exec "$@" これで、rails側の準備はOKです。 react側のファイル用意 Dockerfile(アプリ名/frontend/Dockerfile) FROM node:14.15.1-alpine ※この記述だけで大丈夫です。 ②Dockerコマンドを実行する 順番に実行して下さい。 アプリ名 $ docker-compose run backend rails new . --force --no-deps --database=mysql --api アプリ名 $ docker-compose build アプリ名 $ docker-compose run --rm frontend sh -c "npm install -g create-react-app && create-react-app frontend" 成功すると、見慣れたディレクトリ構造になってるかと思います。 database.yml(backend/config/database.yml)を修正する database.yml default: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: 自分で設定 password: "自分で設定" host: db socket: /var/run/mysqld/mysqld.sock development: <<: *default database: アプリ名_development test: <<: *default database: アプリ名_test usernameとpasswordは、お好きに設定して下さい。mysqlをターミナルから使用する際に求められます。 再びDockerコマンドを実行 アプリ名 $ docker-compose up アプリ名 $ docker-compose run api rake db:create 下記の画面が出ていれば、成功 rails(localhost:3001) react(localhost:3000) 最後に 記事をまとめるのは、難しいですね・・・ 初めてなので、稚拙な部分も沢山あったかと思いますが、 不明点や記述の仕方に対するフィードバックが御座いましたら、お教え頂けますと幸いです。

やりたいこと APIのエンドポイント1つずつにこんなテストが書いてある。(本来レスポンスも見るしっかりしたテストの方がいいけどそれは一旦置いておく) このテストは、MongoDBのサーバー(Docker Desktop for Windowsのコンテナ)を別途用意した上で、テスト立ち上げの度にそのサーバーのDBを消して初期化し、テストしている。割とよくやる手法なのかもしれないが、この方法だとテストが増えるにつれ、並列処理ができないことから 時間がかかるようになってしまう。できれば並列でできるようにしたいのでその方法を調べてみた。 手法いろいろ 1. モックを使う サーバーがあると仮定して本来返ってくる値を書いておいて返す、的な手法。サーバーに依存しないでテストできて色々楽だと思うが、実際のDBで試したときに想定外のエラー返ってくることもありそうに思い見送り。 2. テスト用のDBサーバーを都度建てる 今回やっていた/やった手法。ここまでやっていたのは、別途DBサーバーを1つだけ建てておいてそれにアクセスさせるテストだったが、Dockertestというやつを使うと テスト時にユニット毎にコンテナを建ててその中でテストを行い、テスト後はコンテナの削除、というところまでができる。これなら並列でもテストができてよさそう。 3. インメモリなDBを建てて試す SQL系ならSQLiteで動かすとかができそうに思う。ORMを使っているならワンちゃん、なんとかできるんじゃないだろうか(よく調べられていない) ただ今回はMongoDBなので、SQLiteじゃダメ。memongoという インメモリなMongoDBを建てるものもあったが、サポートOSがUnix系(Linux/MacOS)だったので、Windowsでは動かなそうと思い見送り。 Dockertestを使ってみた https://github.com/ory/dockertest/blob/v3/examples/MongoDB.md 基本的にこのExampleを見たらわかる感じなのだが、これはgo-mongodb-driverではなく、mgoを使っていた。go-mongodb-driverでの実装例を載せておく。 実装例 pool.Runの引数 単に起動するコンテナ内容を指定している。左側がイメージ名、右側がバージョンだった。flagとか使って後から変えれるようにしといたほうがいいかもしれない。 defer shutdownの意味 テスト終了時にコンテナを消すやつである。resource.Expire(300)をしておけば5分後に勝手に消滅してくれるはずではあるが、どうも動かないこともあるようだった。 No connection could be made because the target machine actively refused it. で、テストを実行しようとしたらこんなエラーを言われた。その原因は書いてある通りで、Dockerが接続を受け付けてくれなかったことによるもの。 Docker Desktop for Windowsの設定画面を見たらこんな項目があったのでチェックを入れたら動くようになった。ほんとはTLSを使うべきなのだがdockertestのページを見てよくわからなかったので今回は妥協することにした。(やり方分かる人募集) Panic: Test timeout ローカルにイメージが無い初回実行時はダウンロードが終わるまで時間がかかりタイムアウトしてしまう。VSCodeで実行する場合は、settings.jsonのgo.testTimeoutを変更してタイムアウトまでの時間を300秒ぐらいに伸ばしてから再チャレンジ。 このままだと並列で動かないが。 テストの関数内上部にt.Parallel() を入れよう。 複雑な実装例 もしかしたらこの方法使うとCIをするときにめんどくさくなるかもしれないので従来の並列じゃないテストも残したくなった。そこで苦戦した結果はこれである。 flagが反応しない フラグ名として、parallel って入れてませんか?? parallelは予約語ですよ!!!(2時間悩んだ) テスト用引数の渡し方(VSCode) ファイル → ユーザー設定 → 設定 → go testって検索 → Go: Test flags → settings.jsonで編集 完走した感想 実行までは割とできたけど flagの扱いにめちゃくちゃ悩みました。結局予約語を使っているだけっていう単純なミスで悲しかった。Dockerを見てるとテスト実行時に大量にコンテナが立ち上がって、見てる分には面白いのだけど、あんまり多いと処理落ちしだすするので同時実行数を "-parallel=5" みたいにやって制限しましょう。 すごく参考にしたページ GolangでDBアクセスがあるユニットテストのやり方を考える https://qiita.com/seya/items/582c2bdcca4ad50b03b7

はじめに 　今回は、Docker環境を構築しようと思う。私自身、フロントエンドとバックエンドを一つのリポジトリに管理して、そこでDocker環境を構築した経験はないため、それなりの苦労を強いられた。今回は、私のように一つのリポジトリにフロントとバックを管理する環境下でDockerを導入することになった際に取る手順を紹介していきたいと思う。 　皆さんの開発環境は、私のポートフォリオの環境とは異なる部分もあるだろうから、適宜調整しながら参考にしてもらえたら幸いである。 環境 Redis 6.2 Ruby on Rails 6.1.3.1 Next.js Docker 20.10.0-rc1 MySQL 8.0.23 追記：今回は、フロントとバックエンドを一つのディレクトリで管理しているので注意してもらいたい。 Github等で別々のリポジトリで管理している場合は、リポジトリを統一するか別々のリポジトリでやる方法を調べていただけたら幸いである。 階層構造 │ ├ m-api(API側) │　 └ config │ └ database.yml │ └ Dockerfile ├ m-front（クライアント側） │ └ Dockerfile │ ├ mysql-confd │ └ default_authentication.cnf ├ docker-compose.yml │ ├ .env　（環境変数を管理するファイル） 1. database.ymlの設定 database.yml default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: <%= ENV['DB_USERNAME'] %> #.envにDB_USERNAMEを記入 password: <%= ENV['DB_PASSWORD'] %> #.envにDB_PASSWORDを記入 + host: db - socket: /tmp/mysql.sock development: <<: *default database: m_api_development test: <<: *default database: m_api_test production: <<: *default database: m_api_production username: m_api password: <%= ENV['M_API_DATABASE_PASSWORD'] %> ここでは、hostを次に書くdocker-compose.ymlのdbのservice名に合わせる。 2.docker-compose.ymlの作成 フロントエンドとバックエンドと同じ階層にdocker-compose.ymlを作成する。 docker-compose.yml version: '3' services: redis:　　 image: redis:6.2 command: ["redis-server"] ports: - "6379:6379" volumes: - "./data/redis:/data" command: redis-server --appendonly yes ##MySQLとredis-serverの永続化 db: image: mysql:8.0.23 container_name: api-container command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: $DB_PASSWORD MYSQL_DATABASE: sample MYSQL_PASSWORD: $DB_PASSWORD ports: - ${DB_PORT}:3306 volumes: - ./mysql-confd:/etc/mysql/conf.d　 api:　　 std_open: true #binding.irbでデバックする際に必要となる tty: true　　 　　 #binding.irbでデバックする際に必要となる depends_on: - db build: context: ./m-api/ #m-apiの部分は自身の環境に合わせて変える dockerfile: Dockerfile ports: - "3000:3000" links: - db - redis volumes: - ./m-api:/app #m-apiの部分は自身の環境に合わせて変える - bundle_path:/bundle #Gemの永続化 command: /bin/sh -c "rm -f /app/tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" environment: REDIS_URL: redis://redis:6379 front: build: context: ./m-front/　 #m-frontの部分は自身の環境に合わせて変える dockerfile: Dockerfile volumes: - ./m-front/app:/usr/src/app　 #m-frontの部分は自身の環境に合わせて変える command: 'yarn dev' ports: - "8080:8080" volumes: bundle_path: #Gemの永続化 mysql-data: driver: local 今回、Redis-server、MySQL、Next.js、Rails(APIモード)を使うということで、上記のようにする。 私は、Firebase Authでredis-serverを使っているため、今回はRedisをdocker-compose.ymlに記載したが、そうではない場合は書かなくてよい。 なお、$DB_PASSWORDとDB_PORTは.env（docker-compose.ymlと同じ階層）で環境変数を設定してもらいたい。 また、Redis-serverを使う際に、 command: redis-server --appendonly yes の１行がなければ、Railsのサーバーを再起動するたびにUserやPost等のデータが消えてしまうため、データの永続化ができなくなる。そのため、redisとMySQLを使う場合は必ずこの１行は入れること。 3. mysql-confの作成 MySQLのvolumeを管理するため、docker-compose.ymlと同じ階層にmysql-confdを作成し、その中にdefault_authentication.cnfというファイルを作成する。 default_authentication.cnf [mysqld] default_authentication_plugin= mysql_native_password 4. Dockerfileの作成(クライアント側、API側) まずはクライアント側からm-front/Dockerfileを作成する FROM node:14-alpine WORKDIR /usr/src/app なお、1行目のnodeは Docker Hubからnodeのバージョンを選択するのが望ましい。 次に、API側でm-api/Dockerfileを作成する FROM ruby:2.7.3 ENV LANG=C.UTF-8 \ TZ=Asia/Tokyo RUN apt-get update -qq && apt-get install -y nodejs default-mysql-client RUN mkdir /app WORKDIR /app COPY Gemfile /app/Gemfile COPY Gemfile.lock /app/Gemfile.lock RUN bundle install COPY . /app # Start the main process. CMD ["rails", "server", "-b", "0.0.0.0"] ここも、Docker HubからRubyのバージョンを選択するのが望ましい。 5.Dockerコマンドの実行 まずは、 $ docker-compose build でDocker環境をビルドする。 次に、Docker環境の中にデータベースを作成するために、 $ docker-compose run api rails db:create を実行する。 なお、ここでのapiは、docker-compose.yml内で指定したAPI側のservice名である。 適宜調整してコマンドを実行すること。 そして、databaseを作ることができたら、 $ docker-compose run api rails db:migrate を実行して、マイグレーションを実行する。 これでローカルで作成したデータベースはDocker環境でも再現できたことになる。 そして、 $ docker-compose up -d または $ docker-compose up を実行して、Dockerコンテナをupする。　　　　　 http://localhost:3000/　　　　　　　　　 にアクセスし、下記の画面が出てきたら成功である。 これで環境構築は終了である。 おわりに Dockerは一度作成するまでにかなりの時間を要するが、一度作ればずっと使える。そのため、エラーが出ても途中で折れずに進めることを推奨する。 また、今回の記事でどこか間違っている部分があれば指摘していただけると幸いである。

背景 docker が mac で起動しているときってタスクバーにこの画像があると思うんですが docker がなぜだか完全にクラッシュしてしまい、起動もしない、タスクバーにもない、再インストールしても動かない。アンインストールしたいけどアンインストーラも起動しない。 そんな状態になったときの対処が日本語の情報がなかったのでメモしておきます。 何に困るか docker に限らないと思うんですが、うんともすんともいかなくなった時最終的には再インストールをすると思います。 しかし、docker for mac のアンインストールについて調べて出てくる日本語のほぼ全ての記事がGUIからアンインストールしましょうというものなので、 今回のようにタスクバーにも出てこなくなるとどうしようもなくなりました。 解決策 cliから関連ファイルすべてを削除することでアンインストールと同じ状態にします。 手順は以下の記事にありました。ちなみにベストアンサーはこちらもGUIでの削除なので、ベストアンサーは今回使えません。 そのため、下の方にあるcliでの手順を実施することでアンインストールできました。手順を書いておきます。 気をつけてほしいんですが、コンテナもイメージもすべて消えるのでご承知おきください。 また、sudo での　rm　を含みます。十分注意してください。私は一切の責任を持ちません。 以下すべてのコマンドをターミナルで打ちます。 sudo rm -Rf /Applications/Docker.app sudo rm -f /usr/local/bin/docker sudo rm -f /usr/local/bin/docker-machine sudo rm -f /usr/local/bin/docker-compose sudo rm -f /usr/local/bin/docker-credential-desktop sudo rm -f /usr/local/bin/docker-credential-ecr-login sudo rm -f /usr/local/bin/docker-credential-osxkeychain sudo rm -Rf ~/.docker sudo rm -Rf ~/Library/Containers/com.docker.docker sudo rm -Rf ~/Library/Application\ Support/Docker\ Desktop sudo rm -Rf ~/Library/Group\ Containers/group.com.docker sudo rm -f ~/Library/HTTPStorages/com.docker.docker.binarycookies sudo rm -f /Library/PrivilegedHelperTools/com.docker.vmnetd sudo rm -f /Library/LaunchDaemons/com.docker.vmnetd.plist sudo rm -Rf ~/Library/Logs/Docker\ Desktop sudo rm -Rf /usr/local/lib/docker sudo rm -f ~/Library/Preferences/com.docker.docker.plist sudo rm -Rf ~/Library/Saved\ Application\ State/com.electron.docker-frontend.savedState sudo rm -f ~/Library/Preferences/com.electron.docker-frontend.plist 自分は上記コマンドですべて削除した後にdockerを再インストールすることができました。