はじめに 環境を新しくしようとM1Mac買って(安かったから)ウキウキしながら開発を再構築していたら、node-sass周りでエラーになりやがりまして解決した時のやり方です。 前提 以下のようなdockerファイルでnode環境にnode-sass(Ver4.14.1)を入れようとしています。 他にももちろん入れようとしていますが、node-sass周り以外のエラーはなかったので、問題ないもしくは同様の対処で問題が解消されたようです。 # 使用するDokcerfile FROM node:12.10-slim RUN mkdir /workspace COPY ./package.json /workspace/package.json WORKDIR /workspace RUN npm install ただ、最初に出たエラーは以下のように404エラーだったんですが、今日やったら別のエラーになっていました。これについては謎ですが、一時的な問題だったのかもしれません。 # 最初に出たエラー Cannot download "https://github.com/sass/node-sass/releases/download/v4.14.1/linux-arm64-72_binding.node": # 記事書いた日に出たエラー #11 18.16 > node-sass@4.14.1 postinstall /workspace/node_modules/node-sass #11 18.16 > node scripts/build.js #11 18.16 #11 18.23 Building: /usr/local/bin/node /workspace/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library= #11 18.27 gyp info it worked if it ends with ok #11 18.27 gyp verb cli [ #11 18.27 gyp verb cli '/usr/local/bin/node', #11 18.27 gyp verb cli '/workspace/node_modules/node-gyp/bin/node-gyp.js', #11 18.27 gyp verb cli 'rebuild', #11 18.27 gyp verb cli '--verbose', #11 18.27 gyp verb cli '--libsass_ext=', #11 18.27 gyp verb cli '--libsass_cflags=', #11 18.27 gyp verb cli '--libsass_ldflags=', #11 18.27 gyp verb cli '--libsass_library=' #11 18.27 gyp verb cli ] #11 18.27 gyp info using node-gyp@3.8.0 #11 18.27 gyp info using node@12.10.0 | linux | arm64 #11 18.27 gyp verb command rebuild [] #11 18.27 gyp verb command clean [] #11 18.27 gyp verb clean removing "build" directory #11 18.27 gyp verb command configure [] #11 18.28 gyp verb check python checking for Python executable "python2" in the PATH #11 18.28 gyp verb `which` failed Error: not found: python2 #11 18.28 gyp verb `which` failed at getNotFoundError (/workspace/node_modules/which/which.js:13:12) #11 18.28 gyp verb `which` failed at F (/workspace/node_modules/which/which.js:68:19) #11 18.28 gyp verb `which` failed at E (/workspace/node_modules/which/which.js:80:29) #11 18.28 gyp verb `which` failed at /workspace/node_modules/which/which.js:89:16 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/index.js:42:5 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/mode.js:8:5 #11 18.28 gyp verb `which` failed at FSReqCallback.oncomplete (fs.js:169:21) #11 18.28 gyp verb `which` failed python2 Error: not found: python2 #11 18.28 gyp verb `which` failed at getNotFoundError (/workspace/node_modules/which/which.js:13:12) #11 18.28 gyp verb `which` failed at F (/workspace/node_modules/which/which.js:68:19) #11 18.28 gyp verb `which` failed at E (/workspace/node_modules/which/which.js:80:29) #11 18.28 gyp verb `which` failed at /workspace/node_modules/which/which.js:89:16 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/index.js:42:5 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/mode.js:8:5 #11 18.28 gyp verb `which` failed at FSReqCallback.oncomplete (fs.js:169:21) { #11 18.28 gyp verb `which` failed stack: 'Error: not found: python2\n' + #11 18.28 gyp verb `which` failed ' at getNotFoundError (/workspace/node_modules/which/which.js:13:12)\n' + #11 18.28 gyp verb `which` failed ' at F (/workspace/node_modules/which/which.js:68:19)\n' + #11 18.28 gyp verb `which` failed ' at E (/workspace/node_modules/which/which.js:80:29)\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/which/which.js:89:16\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/isexe/index.js:42:5\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/isexe/mode.js:8:5\n' + #11 18.28 gyp verb `which` failed ' at FSReqCallback.oncomplete (fs.js:169:21)', #11 18.28 gyp verb `which` failed code: 'ENOENT' #11 18.28 gyp verb `which` failed } #11 18.28 gyp verb check python checking for Python executable "python" in the PATH #11 18.28 gyp verb `which` failed Error: not found: python #11 18.28 gyp verb `which` failed at getNotFoundError (/workspace/node_modules/which/which.js:13:12) #11 18.28 gyp verb `which` failed at F (/workspace/node_modules/which/which.js:68:19) #11 18.28 gyp verb `which` failed at E (/workspace/node_modules/which/which.js:80:29) #11 18.28 gyp verb `which` failed at /workspace/node_modules/which/which.js:89:16 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/index.js:42:5 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/mode.js:8:5 #11 18.28 gyp verb `which` failed at FSReqCallback.oncomplete (fs.js:169:21) #11 18.28 gyp verb `which` failed python Error: not found: python #11 18.28 gyp verb `which` failed at getNotFoundError (/workspace/node_modules/which/which.js:13:12) #11 18.28 gyp verb `which` failed at F (/workspace/node_modules/which/which.js:68:19) #11 18.28 gyp verb `which` failed at E (/workspace/node_modules/which/which.js:80:29) #11 18.28 gyp verb `which` failed at /workspace/node_modules/which/which.js:89:16 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/index.js:42:5 #11 18.28 gyp verb `which` failed at /workspace/node_modules/isexe/mode.js:8:5 #11 18.28 gyp verb `which` failed at FSReqCallback.oncomplete (fs.js:169:21) { #11 18.28 gyp verb `which` failed stack: 'Error: not found: python\n' + #11 18.28 gyp verb `which` failed ' at getNotFoundError (/workspace/node_modules/which/which.js:13:12)\n' + #11 18.28 gyp verb `which` failed ' at F (/workspace/node_modules/which/which.js:68:19)\n' + #11 18.28 gyp verb `which` failed ' at E (/workspace/node_modules/which/which.js:80:29)\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/which/which.js:89:16\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/isexe/index.js:42:5\n' + #11 18.28 gyp verb `which` failed ' at /workspace/node_modules/isexe/mode.js:8:5\n' + #11 18.28 gyp verb `which` failed ' at FSReqCallback.oncomplete (fs.js:169:21)', #11 18.29 gyp verb `which` failed code: 'ENOENT' #11 18.29 gyp verb `which` failed } #11 18.29 gyp ERR! configure error #11 18.29 gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable. #11 18.29 gyp ERR! stack at PythonFinder.failNoPython (/workspace/node_modules/node-gyp/lib/configure.js:484:19) #11 18.29 gyp ERR! stack at PythonFinder.<anonymous> (/workspace/node_modules/node-gyp/lib/configure.js:406:16) #11 18.29 gyp ERR! stack at F (/workspace/node_modules/which/which.js:68:16) #11 18.29 gyp ERR! stack at E (/workspace/node_modules/which/which.js:80:29) #11 18.29 gyp ERR! stack at /workspace/node_modules/which/which.js:89:16 #11 18.29 gyp ERR! stack at /workspace/node_modules/isexe/index.js:42:5 #11 18.29 gyp ERR! stack at /workspace/node_modules/isexe/mode.js:8:5 #11 18.29 gyp ERR! stack at FSReqCallback.oncomplete (fs.js:169:21) #11 18.29 gyp ERR! System Linux 5.10.47-linuxkit #11 18.29 gyp ERR! command "/usr/local/bin/node" "/workspace/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library=" #11 18.29 gyp ERR! cwd /workspace/node_modules/node-sass #11 18.29 gyp ERR! node -v v12.10.0 #11 18.29 gyp ERR! node-gyp -v v3.8.0 #11 18.29 gyp ERR! not ok #11 18.29 Build failed with error code: 1 #11 18.48 npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.2.7 (node_modules/chokidar/node_modules/fsevents): #11 18.48 npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm64"}) 解決方法 なぜかM1Macで入れたnodeのコンテナにはpython環境とついでにmake環境がないようなので、コマンドで入れてあげればOKです。 最終的に使用したDockerfileは以下のようになっています。 FROM node:12.10-slim RUN mkdir /workspace COPY ./package.json /workspace/package.json RUN apt-get update || : && apt-get install python build-essential -y WORKDIR /workspace RUN npm install ちなみに Intel入ってる方でも動作確認済みです。

はじめに 最近は仕事でWebアプリケーションを作成しています。 本日もいつも通りWebページを作成し、Javascriptを書いたのですが、なぜかリロードしてもJavascriptが反応しませんでした。 色々調べたのですが、同じ現象の方がいなかったようなので、簡単にメモしていきます。 また、この解決に会社の上司の方が手助けをしてくれました。 タイトルも上司の方につけていただきました。 環境 Docker Desktop for Windows WSL2 VSCode 問題 Docker(WSL2)環境で以下の問題がいきなり発生しました。 ローカルとコンテナをマウントしている状態で、JavaScriptのファイルを編集しましたが、なぜか反映さません。 JavaScriptはwebpackerのコンテナをDockerで立ち上げて管理しています。 JavaScriptを編集した後に保存(Ctrl+s)をすると、ホットリロードが働いていることはターミナルから確認ができます。 そして、ターミナルではCompling....と走っていました。 しかし、変更内容が反映していません。 久しぶりにJavaScriptを書き、以前はこのような事象にはなりませんでした。 また、最近Hyper-VからWSLに環境を変更したので、それが問題化と思いましたが先輩の環境でも同じ事象になりました。 おそらく何かしらの設定がおかしいようでした。 また、時々コンテナの立ち上げの問題でWebページのスタイルがつかないことがあるのですが、今回はF5でリロードしてもスタイルがつくことがありませんでした。 始めにスタイルがついていないとそれ以降はつくことはありませんでした。 解決方法 以下の記事を確認して解決できました。 [Rails] Webpacker の使い方 webpacker/development.ymlの以下の箇所が問題になっていました。 webpack.yml # developmet cache_manifest: true この設定をいつ増やしたのかは忘れてしまいましたが、何かあって追加したのでしょう。 cache_manifestをtrueにすると初めにコンパイルした内容がCacheとして保存されるためそれ以降の変更が効かなくなります。これが原因でJavaScriptが反映されていませんでした。 以下のように修正します。 webpack.yml # development cache_manifest: false また、該当行を削除することで、デフォルトのfalseに設定されます。行ごと削除したほうがよいです。 おわりに かなり沼ってしまい、時間がかかってしまいました。 とりあえず原因特定としては別の環境で同じことを確かめたほうがいいと思いました。 詳細にコードを載せたいところでしたが手元に環境がないためメモ程度にまとめてみました。 明日からやっと仕事が再開できます。先輩ありがとうございました。 参考 [Rails] Webpacker の使い方

はじめに DockerでGUIアプリを立ち上げる記事があるがPodmanでやった記事がなかったので、 実行できるか試してみる。 Dockerfileについて 以下のDockerfileを作成して、xtermがインストールしたコンテナを作成します。 FROM debian:8.6 RUN apt-get update RUN apt-get install xterm -y CMD ["/bin/bash"] 以下のコマンドでビルド podman build -t debian-xterm . 起動 以下のコマンドを実行するとxtermのGUIが起動する。 podman run -it --rm -e DISPLAY=${DISPLAY} -v /tmp/.X11-unix:/tmp/.X11-unix localhost/debian-xterm xterm 起動すると以下のような図が表示される。 特定ユーザでGUIアプリを立ち上げたい場合は以下のコマンドを実行する。 sudo podman run -it --rm -e DISPLAY=${DISPLAY} -v /tmp/.X11-unix:/tmp/.X11-unix -u 1000 localhost/debian-xterm xterm Podmanの特徴として、作成したり、pullを行ったコンテナをユーザごとに独立しているため Dockerのように同じPCないならば、どのユーザも同じように使えないため、 RootユーザでPodmanを実行する場合はRootユーザでコンテナを作成する。 まとめ 一応、GUIアプリを立ち上げることは可能であることを確認した。 今後は、トランプゲームがコンテナで動いて遊べることを確認したい

apache(httpdデーモン)の起動はserviceコマンドやsystemctlコマンドで起動する事が多いと思いますがdocker container lsでhttpdイメージのCOMMANDの欄を見た時にhttpd-foregroundが指定されていてこれ何だろうと思ったので調べてみました。 大前提としてコンテナはCMDコマンドやENTRYPOINTコマンドで指定したコマンドが終了したらコンテナ自体も終了する仕組みです(下記の記事が分かりやすかったです) 参考:https://architecting.hateblo.jp/entry/2020/08/13/153842 結論：httpd -DFOREGROUNDコマンドを実行する事によってhttpdデーモンをフォアグラウンドで起動している。 実際にhttpdイメージのリポジトリを見ていきます。 httpdイメージのdockerfileのCMDコマンドがこの様な指定されていました。 ~省略~ COPY httpd-foreground /usr/local/bin/ EXPOSE 80 CMD ["httpd-foreground"] COPYコマンドでhttpd-foregroundが/usr/local/bin/にコピーされています。CMDコマンドで指定されているhttpd-foregroundを見てみます。 #!/bin/sh set -e # Apache gets grumpy about PID files pre-existing rm -f /usr/local/apache2/logs/httpd.pid exec httpd -DFOREGROUND "$@" httpd -DFOREGROUNDが実行されています。これはhttpdデーモンをフォアグラウンドで起動する事を意味しています。 serviceコマンドを使うとバックグラウンドで実行した後serviceコマンド自体は終了する為コンテナも終了してしまいますが、この方法ならhttpdデーモンがフォアグランドで起動されてコンテナが終了しません。 実際に試してみる httpd-foreground まずは普通にapacheイメージを起動してみます docker run -dit -p 8080:80 httpd:2.4 コンテナが起動しているか確認してみます docker conteiner ls コンテナを起動して時間がたってもコンテナは起動したままです。 service httpd start 次に先程のdocker run　コマンドにservice httpd startコマンドを引数として渡してあげます。 docker run -dit -p 8080:80 httpd:2.4 service httpd start コンテナを見てみます COMMANDの欄がservice httpd startになっていてstatusがすぐにExitedになりました。serviceコマンドが終了したとほぼ同時にコンテナが停止しました。　 おまけ -DFOREGROUNDオプションをつけずにhttpdコマンドのみでコンテナを起動してみます docker run -dit -p 8080:80 httpd:2.4 httpd こちらもすぐにコンテナが終了しています 何か間違いなどがありました遠慮なくご指摘ください。

はじめに 最近、clojureと言う言語を聞いたので、その環境構築を行いました。 clojureはLISPをJVM仮装マシン上で動けるようにしたものです。 レポジトリはこちら dockerのビルド ディレクトリ構成 初回インストールを行うために以下の構成にしてあります。 後で、変更します。 ├── Dockerfile ├── docker-compose.yaml Dockerfile FROM clojure:openjdk-8 WORKDIR /usr/src/app # bashは入れても入れなくてもどっちでもいいです。 RUN apt-get update && apt-get install --no-install-recommends -y bash=5.0-4 \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* docker-compose.yaml version: '3' services: clojure: build: . tty: true # 後で、コンテナ内に入るため。終わったら消す。 インストールと永続化 docker-compose exec clojure bash -c "lein new app workspace" docker cp `docker-compose ps -q clojure`:/usr/src/app/workspace/ ./ docker-compose.yamlを書き換える。 docker-compose.yaml version: '3' services: clojure: build: . command: 'lein run' working_dir: /usr/src/app/workspace volumes: - ./workspace:/usr/src/app/workspace 最終的なディレクトリ構成 作られたディレクトリの中身は完全にjavaですね。 ├── Dockerfile ├── docker-compose.yaml └── workspace ├── CHANGELOG.md ├── LICENSE ├── README.md ├── doc │ └── intro.md ├── project.clj ├── resources ├── src │ └── workspace │ └── core.clj ├── target │ └── default │ ├── classes │ │ └── META-INF │ │ └── maven │ │ └── workspace │ │ └── workspace │ │ └── pom.properties │ └── stale │ └── leiningen.core.classpath.extract-native-dependencies └── test └── workspace └── core_test.clj Hello, World! 最後に、docker compose up!!! > docker compose up Attaching to clojure_1 clojure_1 | Retrieving org/clojure/clojure/1.10.1/clojure-1.10.1.pom from central clojure_1 | Retrieving org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.pom from central clojure_1 | Retrieving org/clojure/pom.contrib/0.2.2/pom.contrib-0.2.2.pom from central clojure_1 | Retrieving org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.pom from central clojure_1 | Retrieving org/clojure/clojure/1.10.1/clojure-1.10.1.jar from central clojure_1 | Retrieving org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar from central clojure_1 | Retrieving org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar from central clojure_1 | Hello, World! clojure_1 exited with code 0 ビルドしていなければ、勝手にビルドしてくれるみたいですね。 ここは、go,javaよりも便利ですね。 workspace/src/workspace/core.clj (ns workspace.core (:gen-class)) (defn -main "I don't do a whole lot ... yet." [& args] (println "Hello, World!")) このファイルを書くかえれば、コーディングが行えます。

TL; DR 2021年8月31日にDocker社がDocker Desktopを有料化するという衝撃の発表をしました。 We’re introducing a new product subscription, Docker Business, for organizations using Docker at scale for application development and require features like secure software supply chain management, single sign-on (SSO), container registry access controls, and more. Our Docker Subscription Service Agreement includes a change to the terms for Docker Desktop: Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. It requires a paid subscription (Pro, Team or Business), starting at $5 per user per month, for professional use in larger businesses. You may directly purchase here, or share this post and our solution brief with your manager. While the effective date of these terms is August 31, 2021, there is a grace period until January 31, 2022 for those that require a paid subscription to use Docker Desktop. Docker Pro, Docker Team, and Docker Business subscriptions include commercial use of Docker Desktop. The existing Docker Free subscription has been renamed Docker Personal. No changes to Docker Engine or any upstream open source Docker or Moby project. Check out our FAQ or more information. 筆者による日本語訳 私たちはDocker Businessという、大規模アプリケーション開発のためにDockerを用いており、セキュアなソフトウェアサプライチェーン管理、シングルサインオン、コンテナレジストリアクセス管理等の機能を必要とする組織のための、新しい製品購読を紹介します。 私たちのDocker購読サービス利用規約は以下のDocker Desktopの利用規約の変更を含みます。 Docker Desktopはスモールビジネス（250未満の従業員かつ$10,000,000未満の年間収益）、個人的利用、教育的利用、非商用利用、及びオープンソースプロジェクトに対しては無料のままです。 より専門的で大きなビジネスに対しては一人一ヶ月あたり$5からの有料の購読（Pro, Team, Bussiness)が必要です。あなたはここで直接支払ってもよいですし、またはこの投稿と私たちのソリューションをマネージャに共有することができます。 新しい利用規約は2021年8月31日から有効ですが、2022年1月31日まで、有料購読するための猶予があります。 Docker Pro, Docker Team, Docker Business定期購読ではDocker Desktopを商用利用することができます。 既存のDocker Free購読はDocker Personalと名称変更されました。 Docker Engineや上流のオープンソースDockerやMobyプロジェクトに変更はありません。 詳細はFAQをご確認ください Docker Desktopを商用利用している大規模な企業は、　2022年1月31日までに有料プランの購読か、代替手段への移行が必要です。 Docker Desktopの有料化の影響 今回有料化されるのはDocker Desktopです。これはWindowsやMacでDockerを管理を行うためのGUIアプリケーションです。 今回の有料化で以下のことは無料ではできなくなります。 Docker Desktopを用いたDockerのインストール、更新 Docker DesktopからImage/Volume/設定等の管理 以下のことは引き続き無料で可能です。 WindowsでWSL2上に直接dockerをインストール Macで仮想マシン上にdockerをインストール（M1　Macで可能かはわかりません） docker-cliを用いたdockerの操作 手動でのDockerのインストールや定期的な更新は地味に手間がかかります。 またMacでVMにアクセスしないとDockerが使えないのは結構困るでしょう。 有料プランでは何が可能になるのか 有料プランを定期購読するとDocker Desktopの利用に加えて、以下サービスが可能になります。 DockerHubでのプライベートレポジトリの利用 CIでのコンテナイメージのビルド DockerHubからのイメージのPull イメージの脆弱性スキャン アクセス管理機能(Teamの作成やRole-based アクセス管理） 有料プランを購読する場合はコンテナイメージの管理をDockerHubで行うことにメリットがありそうです。 代替案はあるのか Podman PodmanはDockerの代替ツールです。 これはコンテナのランタイムを提供するものなので、Docker Desktopの代替となるかというと難しいところだと思います。 Docker Machine Docker MachineはWindowsやMacでVM経由でdockerを動かすツールです。 こちらはオープンソースなので無料で使えますが、開発が止まっています。 まとめ Docker Desktop有料化によって以下の二つの選択肢のいずれを選択するか迫られることになりました。 有料プランを購読する場合 Docker Dektop単体ではコスパはあまり良くないでしょう。DockerHubも積極的に利用したいところです。 有料プランを購読しない場合 Dockerのインストールやアップデートを手動で行う必要があるため、管理用のツールなどを内製する必要があるでしょう。

はじめに 今回はDockerで新しいイメージをビルドして、IBM CloudのROKSにデプロイする方法をご紹介します。 この記事で含む内容を簡単に説明すると、以下の３点です。 Step1 Docker イメージ作成 （Dockerでサンプルアプリをビルド） Step2 Container Registryにpush （IBM Cloud Container Registoryにイメージをpush） Step3 ROKS上にデプロイ （ROKSにイメージをpullしPodをデプロイ） ▲IBM Cloudを利用してのROKSクラスターの構築方法はこちらの記事から参照できます： 「ゼロから始めよう、ROKS on IBM CloudでのNginxサーバ構築」 https://qiita.com/jennyxu/items/c57b32af463b2e015eb0 ▲本手順でデプロイしたアプリにインターネットからアクセスしたい場合はこちらのリンクを参照してください。 「IBM Cloud internet services (CIS)からROKSのpodにアクセスしてみた」 https://qiita.com/jennyxu/items/dc6b92049ba5af3c4c39 では、一緒にやってみましょう。 前提・環境 Docker desktop （インストール：https://www.docker.com/products/docker-desktop 手順：https://sukkiri.jp/technologies/virtualizers/docker/docker-win_install.html） Docker desktopにnginx イメージをインストール （https://www.docker.com/blog/how-to-use-the-official-nginx-docker-image/） IBM Cloudアカウント IBM Cloud CLI （インストール：https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli） OC CLI （インストール：https://docs.openshift.com/container-platform/4.7/cli_reference/openshift_cli/getting-started-cli.html#installing-openshift-cli） Step1 Docker イメージ作成 Step1では、既存の自作のHTMLを表示するためにカスタムnginx イメージを作成します。 Docker desktopがfileを参照可能なディレクトリは事前に指定されています。（以下の写真参照）いずれかのディレクトリにDockerfileを保存していないと、ビルド時に正しく読み込まないので注意してください。 本手順では、/Usersを使います。/path/to/exported/directoryに任意のpathを追加することも可能です。 ターミナルにて、/Usersに移動してDockerfile作成用のディレクトを作成します。 ## /Usersに移動 $ cd /Users ##　ディレクト作成 $ mkdir container-common ## 作成したディレクトに移動 $ cd container-common では、簡単なhtml fileを作ります。 ##file作成 $ vi index.html index.htmlに下記の内容を書き込みます。 <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Docker container</title> </head> <body> <h2>Hello my first container</h2> </body> </html> 次に、Dockerで作成するcontainer イメージを管理するためのDockerfileを作ります。 ##同じディレクトにDockerfileを作成 $ vi Dockerfile Dockerfileに下記の内容を書き込みます。 FROM nignx:latest COPY ./index.html /usr/share/nginx/html/index.html 作成したDockerfileからカスタムnginxイメージをビルドします。その後、ビルドしたイメージで正常にコンテナが作成できることを確認します。 ##Docker イメージビルド $ docker build -t container-common:v1 . ##run Docker イメージ $ docker run -it --rm -d -p 8080:80 --name web1 container-common:v1 以上の手順が完了すると、Docker desktopよりイメージとcontainerの状況が確認できます。Runningになっていれば正常にデプロイできていることが確認できます。 Step2 Container Registryにpush IBM Cloud(cloud.ibm.com)にログインして、Container Registryをオーダーします。 「カタログ」→「Container Registry」と入力→「Container Registry」をクリック→右上の「開始する」をクリックしてください。 Container Registryのオーダーが完了したら、上記の手順にしたがって設定を行います。 ↓ガイドの3番目から $ibmcloud plugin install container-registry -r `IBM Cloud` ##IBM Cloudにログイン $ ibmcloud login --apikey <API_KEY> -g rg-common -r jp-tok $ ibmcloud cr region-set ap-north ##name sapce作成 $ ibmcloud cr namespace-add cr-common $ ibmcloud cr login $ docker pull hello-world ##タグを付ける $ docker tag container-common:v1 jp.icr.io/cr-common/container-common:v1 ##イメージをpush $ docker push jp.icr.io/cr-common/container-common:v1 ##イメージがRegistry内にあることを確認 $ ibmcloud cr image-list IBM Cloudのコンソール画面から作成した名前空間が確認できます。 Step3 ROKS上にデプロイ ##ROKSにログイン $ oc login -u apikey -p <API_KEY> ##project指定 $ oc project test-common ターミナルからROKSクラスターへログインする方法は二つがあります。今回はApi keyでログインしましたが、OpenShiftコンソールログインコマンドを発行し、ログインする方法もあります。こちらの記事を参照してみてください：https://qiita.com/jennyxu/items/c57b32af463b2e015eb0 $ oc secrets link sa/default secrets/all-icr-io --for=pull -n default $ oc run test-pod --image=jp.icr.io/cr-common/container-common:v1 --restart=Never $ oc expose svc test-pod $ oc get route 以上がDocker イメージのビルドから、IBM Cloud Container Registoryへのイメージのpush、そのイメージを利用してのROKS上にデプロイする方法になります。 ご参考になれば幸いです。 参考資料

制作背景 友人とバイクでツーリングに行く際に、目的地までの道が重要なのだが道を紹介するサイトが少ない（もしくはバイク乗りなら誰でも知っているような内容しかなかった）という課題から、道やスポットを紹介し、道やスポットについて交流するWEBアプリを作ろうと考えました。 アプリ名 アプリ名: Tamari-Ba 「たまりば」と読みます。バイク乗り達が自分のバイク、好きな道、きつかった道、楽しかった道の駅等を語り合う「たまり場」をイメージして作成。 いつも行くあのカフェ、あの道の駅等の集まってダベれる「たまり場」のように好きなスポットについて語り合えるようなアプリに仕上げました。 ER図 インフラ構成図 ポートフォリオなので大きなアクセス負荷はかからないという見込みからコスト削減のためRDSは使わずに構築しました。 使用技術 フロントエンド HTML / CSS / Sass Bootstrap 4.5 バックエンド Ruby 2.7.2 Ruby on Rails 6.1.3 JavaScript GoogleMapsAPI(Maps JavaScript API / Geocoding API) インフラ MySQL 5.7 Nginx 1.20 Puma 5.3.2 AWS (VPC, EC2, S3) CircleCI Docker 20.10.8 Supervisor 機能一覧 ユーザー関連 機能 1 アカウント登録/削除機能 2 ログイン/ログアウト機能 3 ゲストログイン機能 4 アカウント情報編集機能 5 ユーザー情報 - 都道府県 6 ユーザー一覧 投稿機能 機能 1 投稿機能(CRUD) 2 GoogleMaps表示機能 3 マップ検索機能 4 座標取得/保存機能 5 マーカー設置機能 6 コメント機能 7 いいね機能 8 投稿検索 9 投稿一覧 できること 1. トップページ ログイン状態に応じて、リンクボタンを表示分けさせています。 非ログイン状態：ログイン/ゲストログイン ログイン状態：アプリトップ 最新３件分の投稿を表示 機能の概要を説明 投稿詳細イメージを表示 2. 新規投稿 マップの検索でマップ表示範囲を移動できます。 任意の箇所をクリックすることでマーカーを設置できます。 座標がデータベースに保存されます。 その他にも画像保存、タイトル、説明文を入力することが可能です。 3. 投稿一覧 投稿一覧を見ることができます。 検索機能があるので、投稿を検索することができます。 15投稿でページネーションが適用されます。 4. 投稿詳細 保存された座標を元に地図上にマーカーを表示します。 投稿者本人がログインしている場合には編集/削除ボタンが表示され実行できます。 保存された画像が表示されます。 コメント欄に入力して「コメントする」をクリックすることで、コメント可能です。 まとめ ポートフォリオとしてアウトプットすることで自分の実力がメキメキ付いてくるのを実感しました。 とはいえ、まだつけたい機能やフロント周りは改善の余地があるため転職活動を続けていく中で改善していこうと思います。 投稿記事 ポートフォリオ関連 ポートフォリオ作成に当たり、理解が難しかったもの、知識として足りないと思ったものに関しては記事にまとめています。 - 【GoogleMapsAPI】Rails6アプリにMapsJavaScript APIとGeocoding APIを導入してみた - MySQLが起動失敗による500エラーの解消 - 【Docker】Rails6/MySQLのコンテナを作って開発環境を構築 - 【Amazon Linux2】【Rails】Nginxをpumaのunixドメインソケットでリバースプロキシする設定 - 【CircleCI】AWSにデプロイしたRails6アプリをCircleCIで自動デプロイ - 【Rails6】rails sで起動できなくなった話 その他記事 以下は実案件受注やLT会の記事です。 - Rails6でStripe Checkoutを実装　（開発環境/TESTモード） - 【Ruby】変数と定数のあれこれ - 【SQL書籍勉強会】SQLとは？ - 【SQL書籍勉強会】SQLの集計 - 【SQL書籍勉強会】テーブル設計

オンプレミスのインフラエンジニアをやっていると、運用スクリプトを作ることがあります。 監視やバックアップなどの運用を自動化するものです。 ぜひ自動化して運用で楽をしたいものですが、品質担保には思った以上の工数がかかってしまいます。 そこで私は単体テストを実施したい！と思ったのですが、JUnitのようにツールを入れれば行けるというわけでもなさそうでした。 対話型コマンドが絡むシェルのテストのやりづらさ 運用スクリプトの中には、実行したら必ず0を返すような何も工夫しなくても書けるスタブでコマンドを置き換えることでテスト出来る場合もありますが、DBのバックアップなどでスクリプト内でミドルウェア特有のコマンドをたたいているような場合、スタブ化するために少し工夫がいります。 ShellTestStarterの紹介 というわけで作りました。 無駄にREADMEもきれいにしてみました。 releaseからzipをダウンロードするもよし、git cloneするもよし、コードを除いて必要なところだけパクるもよし。好きに使ってください。 READMEにも書きましたが、Linuxのみで動作確認しています。確認環境はCentOS 7 ですので、RHEL系だとそのまま動くと思います。(Ubuntuでも多分動く) Quick Start - サンプルの動かし方 Dockerでの動作が楽なので、 docker-compose run c_dev_env /bin/bash としてコンテナを起動し、シェルに入ってからsampleに移動してsetup.shを実行します。 [root@<containerid> workdir]# cd sample/ [root@<containerid> sample]# ./setup.sh INFO: prepare stub script gcc -o template_communicate_stub template_communicate_stub.c done prepare! makeでのコンパイル、スタブスクリプトの作成が行われるので、試しにテストスクリプトを実行してみましょう。 test_sample_backup_script.shを実行します。 [root@<containerid> sample]# ./test_sample_backup_script.sh begin sample backup script test OK: test case 1 OK: test case 2 OK: test case 3 OK: test case 4 OK: test case 5 OK: test case 6 OK: test case 7 OK: test case 8 OK: test case 9 complete database backup test 全てOKとなっているので、全件テスト通過です。 完了したらsetup.sh cleanを実行することで、生成したファイルたちをクリーンアップできます。 [root@<containerid> sample]# ./setup.sh clean INFO: clean all scripts generated by this script INFO: remove sqlplus INFO: remove sqlplus.dat INFO: remove rman INFO: remove rman.dat INFO: remove db_check.sh INFO: remove db_check.dat INFO: all done! テンプレートスクリプトの解説 テンプレートはsrcの中にtemplate_というプレフィックスで格納されています。 src │ Makefile │ template_communicate_stub.c │ template_communicate_stub.dat │ template_simple_stub.dat │ template_simple_stub.sh template_simple_stub.sh シンプルなスタブシェルです。template_simple_stub.datに記載されている値を読み取って、そのまま返却します。 引数を与えて実行すると、それをそのままログに吐き出します。 template_simple_stub.sh #!/bin/bash script_name=$(basename $0) script_logname=test_$script_name.log echo "run $script_name" >>$script_logname if [ $# -eq 0 ]; then echo "no argument" >>$script_logname else for arg in "$*"; do echo "argument: $arg" >>$script_logname done fi exit $(cat ${script_name%.*}.dat) template_communicate_stub.c 対話式コマンド用のスタブです。同名の.datファイルを読み込み最終的な返却値とします。 引数を与えた時はバッファとして読み込み、引数なしで実行した場合は対話モードで実行できます。 いずれにせよ、読み込んだ文字列はただそのまま吐き出すだけです。 template_communicate_stub.c #include <stdio.h> #include <string.h> #include <unistd.h> // Function to get the path of the execution command // Only available on Linux char *getfilepath() { static char buf[1024] = {"\0"}; readlink("/proc/self/exe", buf, sizeof(buf) - 1); return buf; } int main(int argc, char *argv[]) { // If the beginning of argv[0] (execution command) is ./, remove it. char cmd_name[64]; sscanf(argv[0], "%s", &cmd_name); char t[64]; if (cmd_name[0] == '.' && cmd_name[1] == '/') { // included strncpy(t, cmd_name + 2, strlen(cmd_name) - 2); t[strlen(cmd_name) - 2] = '\0'; } else { // not included strncpy(t, cmd_name, strlen(cmd_name)); t[strlen(cmd_name)] = '\0'; } // Reading here documents int i; printf("run command: %s", t); for (i = 1; i < argc; i++) { printf(" %s", argv[i]); } char buffer[256] = ""; printf("\n---heredoc recieved from here---\n"); // Loop part that accepts input from here documents and terminals while (1) { if (scanf("%255[^\n]%*[^\n]", buffer) == EOF) { break; } // Exit the loop when exit is entered if (strstr(buffer, "exit") != NULL) { break; } // Abnormal termination when a specific character is entered if (strstr(buffer, "special keyword") != NULL) { return 1; } scanf("%*c"); printf("> %s\n", buffer); } printf("---heredoc end---\n"); // File reading char fname[64]; sscanf(getfilepath(), "%s", &fname); strcat(fname, ".dat"); FILE *fp; fp = fopen(fname, "r"); // Get the value from the file and return it as it is int ret; while (fscanf(fp, "%d", &ret) != EOF) { } fclose(fp); return ret; } サンプルテストスクリプトの説明 サンプルとして、以下のようなスクリプトを用意しています。 src/sample/ sample_backup_script.sh setup.sh test_sample_backup_script.sh sample_backup_script.sh バックアップスクリプトのサンプルです。このサンプルスクリプトのテストを行う例でsetup.shとtest_sample_backup_script.shを作っています。 このスクリプトはOracleでのバックアップを模したものになっており、sqlplus、rmanを使ってバックアップ処理を行い、db_check.shという架空のチェックスクリプトを実行する処理となっています。 サンプルですので、こちらを実行しても正しくバックアップが取れないでし、エラーハンドリングもかなりお粗末で実際はsqlplusやrmanが出力するエラーを検知するように作った方が良いと思います。あくまで参考としてください。 sample_backup_script.sh #!/bin/bash # Oracle backup script example logname="sample_backup_script.log" echo "INFO: sample backup script" >>$logname # Check the startup status of the instance sqlplus target / 2>&1 >/dev/null <<EOF select instance_name,status from v\$instance; EOF ret=$? if [ ! $ret -eq 0 ]; then echo "ERROR: instance state incorrect" >>$logname exit 100 fi # Backup process rman target / 2>&1 >/dev/null <<EOF backup database; EOF ret=$? if [ ! $ret -eq 0 ]; then echo "ERROR: backup failure" >>$logname exit 101 fi # Check processing ./db_check.sh full ret=$? if [ ! $ret -eq 0 ]; then echo "ERROR: check failed" >>$logname exit 102 fi echo "INFO: complete database backup" >>$logname setup.sh このsample_backup_script.shをテスト実行するために、必要なスタブを準備するスクリプトです。 setup.shは汎用的に作っていますので、変数宣言の部分だけ変えて流用いただいてもいいと思います。 setup.sh #!/bin/bash # variable declaration array_communicate_stub=(sqlplus rman) array_simple_stub=(db_check) tmp_com_stub=template_communicate_stub tmp_simple_stub=template_simple_stub # mode to delete the script created by setup.sh # execute only when clean is given as an argument if [ "$1" == "clean" ]; then echo "INFO: clean all scripts generated by this script" # remove stubs based on template_communicate_stub for item in ${array_communicate_stub[@]}; do if [ -e ./${item} ]; then rm ./${item} echo "INFO: remove ${item}" fi if [ -e ./${item}.dat ]; then rm ./${item}.dat echo "INFO: remove ${item}.dat" fi done # creating a stub based on template_simple_stub for item in ${array_simple_stub[@]}; do if [ -e ./${item}.sh ]; then rm ./${item}.sh echo "INFO: remove ${item}.sh" fi if [ -e ./${item}.dat ]; then rm ./${item}.dat echo "INFO: remove ${item}.dat" fi done cd .. rm ./${tmp_com_stub} echo "INFO: all done!" exit 0 fi # If there are no arguments, do the following # Describe the preparation process when executing the test echo "INFO: prepare stub script" if [ ! -e ../${tmp_com_stub} ]; then current_dir=$(pwd) cd .. make cd $current_dir fi # Creating a stub based on template_communicate_stub for item in ${array_communicate_stub[@]}; do cp -pr ../${tmp_com_stub} ./${item} cp -pr ../${tmp_com_stub}.dat ./${item}.dat done # Creating a stub based on template_simple_stub for item in ${array_simple_stub[@]}; do cp -pr ../${tmp_simple_stub}.sh ./${item}.sh cp -pr ../${tmp_simple_stub}.dat ./${item}.dat done echo "done prepare!" 変数は以下のようになっています array_communicate_stub=(sqlplus rman) # template_communicate_stubをもとに作成するスタブのリスト array_simple_stub=(db_check) # template_simple_stub.shをもとに作成するスタブのリスト tmp_com_stub=template_communicate_stub # 対話式コマンドのスタブスクリプトテンプレート名 tmp_simple_stub=template_simple_stub # 単純なスタブスクリプトテンプレート名 test_sample_backup_script.sh sample_backup_script.shのいわゆるテストドライバです。スタブコマンドの返却値を制御する各.datファイルを書き換えながら、テストを実行⇒観点ごとに合否を判断しています。 その他注意点としてはexport PATH=./:$PATHとして、スタブコマンドにパスを通しています。もともとのパスよりも前にスタブコマンドにパスを通しておくことで、実際のコマンドではなくスタブコマンドの方を実行するようになります。 test_sample_backup_script.sh #!/bin/bash # this is sample test script logname="sample_backup_script.log" # function that returns all stubs with 0 function allStateClear() { echo 0 >./sqlplus.dat echo 0 >./db_check.dat echo 0 >./rman.dat } echo "begin sample backup script test" export PATH=./:$PATH # test case 1 : When completed, the return value must be 0 allStateClear ./sample_backup_script.sh ret=$? if [ $ret -eq 0 ]; then echo "OK: test case 1" else echo "NG: test case 1 : [ret : ${ret}]" fi # test case 2 : INFO: complete database backup is output to the log allStateClear ./sample_backup_script.sh ret=$(tail -n 1 $logname | grep "INFO: complete database backup" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 2" else echo "NG: test case 2" fi # test case 3 : The argument full is passed to db_check allStateClear ./sample_backup_script.sh ret=$(tail -n 2 ./test_db_check.sh.log | grep "argument: full" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 3" else echo "NG: test case 3" fi # test case 4 : If the confirmation of the instance startup status fails, # the return value must be 100. allStateClear echo 1 >./sqlplus.dat ./sample_backup_script.sh ret=$? if [ $ret -eq 100 ]; then echo "OK: test case 4" else echo "NG: test case 4 : [ret : ${ret}]" fi # test case 5 : If the confirmation of the instance startup status fails, # an error has been output to the log. allStateClear echo 1 >./sqlplus.dat ./sample_backup_script.sh ret=$(tail -n 1 $logname | grep "ERROR: instance state incorrect" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 5" else echo "NG: test case 5" fi # test case 6 : If the backup process fails, the return value must be 200 allStateClear echo 1 >./rman.dat ./sample_backup_script.sh ret=$? if [ $ret -eq 101 ]; then echo "OK: test case 6" else echo "NG: test case 6 : [ret : ${ret}]" fi # test case 7 : If the backup process fails, an error has been output to the log. allStateClear echo 1 >./rman.dat ./sample_backup_script.sh ret=$(tail -n 1 $logname | grep "ERROR: backup failure" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 7" else echo "NG: test case 7" fi # test case 8 : If the check process fails, the return value must be 300 allStateClear echo 1 >./db_check.dat ./sample_backup_script.sh ret=$? if [ $ret -eq 102 ]; then echo "OK: test case 8" else echo "NG: test case 8 : [ret : ${ret}]" fi # test case 9 : If the check process fails, an error has been output to the log. allStateClear echo 1 >./db_check.dat ./sample_backup_script.sh ret=$(tail -n 1 $logname | grep "ERROR: check failed" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 9" else echo "NG: test case 9" fi echo "complete database backup test" Shell Scriptのテストの書き方 Shell Scriptで作られた運用ツールって、監視だったりバックアップだったり、システム的にはかなり重要な役割を担っていたりするのに、システムテストはやるにしてもスクリプト単体でのテストってあまり行われていない気がします。 理由の一つはスクリプト自体が短いものが多く、あまり単体でテストをやる意味がないと思われているように感じます。ですが、自動で単体テストをやるように仕組みを作っておくことで、品質の担保ももちろんですが仕様変更に強くなるというメリットがあります。 ここではShellTestStarterのサンプルを例にどのようにテストを実現しているか解説します。 単純な正常系 allStateClearという各.datファイルの値を0に上書きする処理で返却値をリセットし、sample_backup_script.shを実行しています。返却値が0であるかどうかを見て、試験の合否を判別しています。 # test case 1 : When completed, the return value must be 0 allStateClear ./sample_backup_script.sh ret=$? if [ $ret -eq 0 ]; then echo "OK: test case 1" else echo "NG: test case 1 : [ret : ${ret}]" fi サンプルではケースを分けていますが、正常終了したというログを出力するような場合は、合否判定にそこまで含めても良いと思います。 ログを後半1行だけ読み込み、出力されるはずのメッセージがあるかどうか確認して、あれば合格としています。 # test case 2 : INFO: complete database backup is output to the log allStateClear ./sample_backup_script.sh ret=$(tail -n 1 $logname | grep "INFO: complete database backup" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 2" else echo "NG: test case 2" fi コマンドに正しい引数が渡されているかどうかを確認 スタブコマンドはtest_<コピー後のスクリプト名>.logというログを直下に吐き出す仕様となっています。 ですので、そのログを見ることで、コマンドに正しい引数が渡されているかを確認することが出来ます。 allStateClear ./sample_backup_script.sh ret=$(tail -n 2 ./test_db_check.sh.log | grep "argument: full" | wc -l) if [ $ret -eq 1 ]; then echo "OK: test case 3" else echo "NG: test case 3" fi オプション等で処理を変えて、子スクリプトに別々の引数を渡すようなスクリプトの場合に役立つと思います。 異常系 異常系に関しても判定方法は同じですが、エラーを意図的に発生させています。 allStateClearを実行してクリアした後、echo 1 >./sqlplus.datのように、直接返却値を書き込むことで、同名のコマンドが書き込んだ返却値を返すようになります。 この例ではsqlplusが0以外を返した場合は、ログにERRORを出力し、100を返却するようにしていますので、想定している動作となるかを確認します。 # test case 4 : If the confirmation of the instance startup status fails, # the return value must be 100. allStateClear echo 1 >./sqlplus.dat ./sample_backup_script.sh ret=$? if [ $ret -eq 100 ]; then echo "OK: test case 4" else echo "NG: test case 4 : [ret : ${ret}]" fi まとめ 今回はShellScriptのテスト自動化ツールを公開した説明記事でした。 プルリクもお待ちしておりますのでよろしくお願いします

基本的なインストール方法はこちらの手順を実施。 https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-20-04-ja 上の手順でsystemdが動かないので、その場合は以下を参照 ubuntu18と20でコマンドが違うのでそのあたり気をつけること。 https://qiita.com/Keiwa/items/390d89c20228edf0b16c#systemd

サマリー VirtualBox の仮想環境で Ubuntu サーバを起動し、そのサーバへホスト OS の Windows から SSH 接続して Docker を利用します。 参考書籍 留意事項 上掲の書籍に Appendix として収録されている環境構築の手順が少し難しいと感じたので、スクリーンショットとともに図解してみます。 Docker Desktop for Windows を使ったほうが簡単で早いかもしれません。 WSL2 と共存できません（たぶん）。 私の手元の環境では Docker on WSL2 よりも軽快に動作しています。 この記事ではパッケージマネージャーに Scoop を使います。 ターミナルには Windows Terminal + Git for Windows (= Bash) を利用します。 手順 1. SSH クライアントの準備 インストール パッケージマネージャーを利用して Windows 用の SSH クライアントをインストールします。なお、Git for Windows には SSH クライアントが同梱されています。 scoop での例 PowerShell # Git for Windows をインストール PS C:\> scoop install git 2. VirtualBox と Ubuntu ISO イメージの準備 VirtualBox と Ubuntu サーバー ISO イメージをそれぞれダウンロードします。 VirtualBox のインストール VirtualBox をインストールします。基本的に Next ボタンの連打で問題ないと思います。 3. VirtualBox で仮想マシンの作成 VirtualBox 上に仮想マシンを作成します。VirtualBox マネージャー ウィンドウの「新規」ボタンをクリックしましょう。 こちらも基本的にデフォルト設定のまま「次へ」ボタンの連打で問題ないと思います。 名前: Ubuntu マシンフォルダー: %USERPROFILE%\Ubuntu タイプ: Linux バージョン: Ubuntu (64-bit) メモリとディスク容量: RAM 1024MB, HD 10GB 4. 仮想マシンへの Ubuntu Server のインストール 上で作成した仮想マシンを選択し、「設定」ボタンをクリックします。 ISO イメージのマウント ストレージ -> 光学ドライブ -> コントローラー: IDE -> 空 へと進み、上でダウンロードした Ubuntu Server ISO イメージをマウントして「OK」をクリック。 Ubuntu のインストール メイン画面で「起動」ボタンをクリックし、Ubuntu Server のインストールを開始します。 select your language: English のまま Enter keyboard configuration: Tab キーやカーソルキーでカーソルを移動させて Enter -> Japanese を選択 Network connections: そのままで Done Configure proxy: LAN 内にプロキシサーバーがなければ空欄のままで Done Configure Ubuntu archive mirror: そのままで Done Guided storage configuration: そのままで Done Storage configuration: そのままで Done -> Continue Profile setup: 適宜入力して Done SSH Setup: スペースキーで [X] Install OpenSSH server を選択し Done Featured Server Snaps: 何も選択せずに Done 上部のオレンジ色のバーに Install complete! と表示されたら Reboot Now Failed unmounting /cdrom と表示される場合は、いったんウィンドウを閉じてダイアログの「仮想マシンの電源オフ」を選択してください。 リブートとログインに成功したら、いったん仮想マシンをシャットダウンします。 bash qiita@ubuntu-server:~$ shutdown -h now 5. 仮想環境へアダプター 2 を追加 上でインストールした Ubuntu では「アダプター 1」を使ってホスト OS (= Windows) のネット接続を利用しています。これとは別にホスト OS とネットワークでやり取りするためにはアダプターを追加しなければいけません。NIC 二枚挿し（NEC のサイト）のようなイメージでしょうか。 メイン画面から 設定 -> ネットワーク -> アダプター 2 へと進み、「ホストオンリーアダプタ」を割り当てます。 6. VirtualBox Host-Only Network の IP アドレスを確認 Windows 側で コントロールパネル -> ネットワークとインターネット -> ネットワーク接続 を開き、VirtualBox Host-Only Network の TCP/IPv4 のアドレスを確認します。 VirtualBox の現時点でのバージョン (v6.1) では 192.168.56.1 が割り当てられるようです。Ubuntu 仮想環境側では、このアドレスを アダプター 1 に割り当てています。 7. Ubuntu 側での アダプター 2 を設定する Ubuntu 仮想環境を起動し、ip addr コマンドで Ubuntu 上でのルーティングを確認します。 bash qiita@ubuntu-server:~$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:22:d3:70 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3 valid_lft 86266sec preferred_lft 86266sec inet6 fe80::a00:27ff:fe22:d370/64 scope link valid_lft forever preferred_lft forever 3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:5d:54:d5 brd ff:ff:ff:ff:ff:ff 上で作成した「アダプター 2」がこの環境では enp0s8 という NIC として認識されていることが確認できました。 この enp0s8 を設定するファイル /etc/netplan/01-hostonly-config.yaml を作成します。 インストーラーによって /etc/netplan/00-installer-config.yaml というファイルがすでに作成されていますが、このファイルは編集しないでそのままにしておいてください。 bash qiita@ubuntu-server:~$ sudo vi /etc/netplan/01-hostonly-config.yaml 192.168.56.1 はすでに「アダプター 1」に割り当てられているので、192.168.56.2 というアドレス（ネットマスク 24bit）を割り当てます。 /etc/netplan/01-hostonly-config.yaml network: ethernets: enp0s8: dhcp4: no dhcp6: no addresses: [192.168.56.2/24] 上記設定を適用させます。 bash qiita@ubuntu-server:~$ sudo netplan apply ふたたび ip addr で確認しましょう。 bash qiita@ubuntu-server:~$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:22:d3:70 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3 valid_lft 86266sec preferred_lft 86266sec inet6 fe80::a00:27ff:fe22:d370/64 scope link valid_lft forever preferred_lft forever 3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:5d:54:d5 brd ff:ff:ff:ff:ff:ff inet 192.168.56.2/24 brd 192.168.56.255 scope global enp0s8 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe5d:54d5/64 scope link valid_lft forever preferred_lft forever 8. Windows 側から Ubuntu サーバーへ SSH 接続する では、さっそく Windows 側のターミナルから SSH 接続してみましょう。 Windows 側のユーザー名と Ubuntu 上に作成したユーザー名が異なる場合は、アドレスの前へ Ubuntu ユーザー名を指定してください。 bash $ ssh qiita@192.168.56.2 bash $ ssh 192.168.56.2 The authenticity of host '192.168.56.2 (192.168.56.2)' cant be established. ED25519 key fingerprint is SHA256:0lUX3lER9pSw9pSNELkGpIT6GUz3AWI9VbuM6k/soGU. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes # ↑ yes と入力 qiita@192.168.56.2 s password: # <-- パスワードを入力 Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-81-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Fri 27 Aug 2021 01:39:49 AM UTC System load: 0.0 Processes: 108 Usage of /: 43.8% of 8.79GB Users logged in: 1 Memory usage: 20% IPv4 address for enp0s3: 10.0.2.15 Swap usage: 0% IPv4 address for enp0s8: 192.168.56.2 0 updates can be applied immediately. The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. qiita@ubuntu-server:~$ _ サーバーへの SSH 接続が成功しました。SSH 接続から抜けるには exit コマンドを入力しましょう。 bash qiita@ubuntu-server:~$ exit logout Connection to 192.168.56.2 closed. 9. .ssh/config の作成 ssh ubuntu とするだけで Ubuntu サーバーへ SSH 接続できるようにするため、Windows 側のホームディレクトリに .ssh/config ファイルを作成します。 bash $ vi .ssh/config .ssh/config Host ubuntu HostName 192.168.56.2 User qiita Port 22 bash $ ssh ubuntu qiita@192.168.56.2 password: _ 10. スナップショットの作成 ここまでの作業結果をスナップショットとして保存しましょう。 メイン画面で仮想マシン名の右側にあるメニューを開き、「スナップ」を選択します。 スナップショット名とその説明を入力し、「OK」をクリックします。 こうすることで、もしこの先で環境を破壊してしまうようなことがあっても、この時点にさかのぼって仮想マシンを起動できるようになりました。 11. Docker のインストール Ubuntu サーバーへログインし、パッケージリストとインストール済みパッケージをアップデートします。 bash $ ssh ubuntu qiita@192.168.56.2 password: _ qiita@ubuntu-server:~$ sudo apt update && sudo apt upgrade -y docker.io パッケージをインストールします。 bash qiita@ubuntu-server:~$ sudo apt install docker.io -y Docker デーモンを起動し、システム起動とともにデーモンが自動起動されるように設定します。 bash # デーモンスタート qiita@ubuntu-server:~$ sudo service docker start # デーモンを自動起動に登録 qiita@ubuntu-server:~$ sudo systemctl enable docker # 確認 qiita@ubuntu-server:~$ systemctl list-unit-files --type=service UNIT FILE STATE VENDOR PRESET # ~ 省略 ~ dm-event.service static enabled dmesg.service enabled enabled docker.service enabled enabled e2scrub@.service static enabled # ~ 省略 ~ qiita@ubuntu-server:~$ which docker /usr/bin/docker qiita@ubuntu-server:~$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES qiita@ubuntu-server:~$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker-compose コマンドもインストールします。 bash qiita@ubuntu-server:~$ sudo apt install docker-compose -y qiita@ubuntu-server:~$ which docker-compose /usr/bin/docker-compose ここまでくれば、もう一度スナップショットを撮っておいてもいいかもしれません。 12. ユーザーを docker グループへ追加する このままでは Docker を利用するたびに sudo コマンドが必要となってしまうので、Ubuntu ユーザを docker グループへ追加 します。 bash # ユーザー qiita を docker グループへ追加 qiita@ubuntu-server:~$ sudo gpasswd -a qiita docker この設定は docker デーモンの再起動および当該ユーザーの再ログイン後に有効となります。 bash qiita@ubuntu-server:~$ sudo service docker restart qiita@ubuntu-server:~$ exit # Windows のターミナル $ ssh ubuntu qiita@192.168.56.2 password: _ qiita@ubuntu-server:~$ _ ユーザー権限 (qiita) のまま、docker コマンドが使えるようになりました。確認のため、docker hub から Node.js@14 の軽量版イメージをプルしてみます。 bash qiita@ubuntu-server:~$ docker pull node:14-slim 14-slim: Pulling from library/node 33f99cea3b7d: Pull complete ae5da9a8a5c5: Pull complete 782fa5f5f4c7: Pull complete aed23a4403ca: Pull complete 8d2115ca1b15: Pull complete Digest: sha256:b53fb250858e7b8742f773bcb3693b9488d6614e3d7d7d777d3810a0e0ecca95 Status: Downloaded newer image for node:14-slim docker.io/library/node:14-slim これで仮想マシン上の Ubuntu Linux で Docker を利用する環境が整いました。

Docker の利用規約が大幅に変更になったようなので、取り急ぎ届いたメールを翻訳してみました。 Docker is Updating and Extending Our Product Subscriptions 要約すると、一定規模以上で商用利用する場合は、1ユーザあたり月額5ドルの利用料が発生するようになったよ、ということです（個人利用などはいままでどおり無料） === 皆さま あなたがこのメールを受け取ったのは、いまお使いの Docker の製品およびサービスに関する用語を、私たちが更新したからです。 あなたが知る必要のあること： すべての Docker の製品およびサービスは、いまから新しい用語集に置き換えられます - Docker サブスクリプションサービス契約です。 Docker サブスクリプションには、４階層のサービスが含まれるようになりました。Personal、Pro、Team、そして Business（新しい階層のサービス）です。各階層は、Docker Desktop を含んでいます。 既存の Docker Free サブスクリプションは「Docker Personal」に名前を変えます。Docker Desktop は、個人利用、教育目的、非営利のオープソースプロジェクト、スモールビジネス（250人以下の従業者かつ年間売上が10M USD）において、これまでと同じように無料です。 Docker Desktop の商用利用（250人以上の従業者または年間売上が10M USD）には、Docker Pro, Team または Business サブスクリプションが必要です。これらは、１ユーザあたり月額わずか５ドルです。 Docker Business は新しい製品です。アプリケーション開発のために大規模に Docker を使用し、集中管理や安全なソフトウェア・サプライチェーン機能などの追加機能を必要とする組織向けです。 新しい規約は2021年8月31日に発効され、Docker Desktop を継続して使用するために有料サブスクリプションが必要となるものについては、2022年1月31日までの猶予期間が設けられています。Docker の使用を継続することで、新しい Docker サブスクリプションサービス契約に同意したことになります。 Docker サブスクリプションサービス契約書の更新内容を必ずご一読ください。これらの変更についての詳細は、FAQ をご覧になるか、今後予定されているウェビナーにご参加いただくか、最近のブログ記事をご一読ください。 ===

はじめに いのべこ夏休みアドカレで作成したアプリケーションをクラウドへ公開（デプロイ）してみます。 お決まりですが、目的はデプロイのみであり、他非機能要件に対してクラウドのセットアップ、設定は省いています。 従ってクラウドデプロイのアウトラインレベルであることをお断りしておきます。 また、本方法やコードの一部を用いる場合は自己責任でお願いします。 目的 上述の通り、ローカルで開発したアプリをクラウドデプロイします。 開発した時と同じように動作すればOKです。 コンテナイメージの手動デプロイ、プロキシ構築、コンフィグ等 開発したアプリを本番環境で動作させるときのイメージでしょうか？ 環境 AWSでまずはEC2を使いたいと思います。 プラットフォームは使い慣れているUbuntuを使います。 1. 環境構築 1. EC2インスタンス作成 先ずはEC2インスタンスを作成し立ち上げます。 とりあえずSSH接続用の鍵を作成し、インバウンドは22番はマイIP許可、443はALLにしておきます。 2. docker(compose)インストール SSHでEC2へ接続し必要なパッケージをインストールします。Ubuntuなのでaptを使います。 $ apt moo (__) (oo) /------\/ / | || * /\---/\ ~~ ~~ $ apt update $ apt upgrade $ apt install docker $ apt install docker-compose $ ~$ docker --version Docker version 20.10.7, build 20.10.7-0ubuntu1~20.04.1 $ docker-compose -version docker-compose version 1.25.0, build unknown 3. アプリケーション改修 ローカルではVSCode上でReact、NestJSの開発サーバーで起動させていましたが、 AWS上ではDockerイメージを使ってデプロイさせます。 また、各リクエストを受付るリバースプロキシをnginxで構成します。 あとは一応オレオレ証明書を使ってhttps対応します。 今は無料でいい証明書サービスがありますのでオレオレ不要かも docker-compose.yml version: "3" services: rev: image: sample-app-rev:latest container_name: rev ports: - "443:443" depends_on: - keycloak ... packages\rev\nginx\templates\default.conf.template server { listen 443; ssl on; server_name ms-sample-app.com; root /var/www/html; index index.html index.htm; ssl_certificate /etc/pki/tls/certs/server.crt; ssl_certificate_key /etc/pki/tls/private/server.key; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto $scheme; location / { proxy_pass http://web:3001; } location /auth { proxy_pass http://keycloak:8080; } location /api { proxy_pass http://api:3000; } } 4. docker-compose定義作成 各コンテナをdocker-composeを使って定義します。 アプリ、keycloakが利用するDBも定義します。 5. デプロイ 自動化まではしませんが、ローカルでDockerイメージをビルドして、tar.gz形式へセーブ、AWSにscpして AWS側でイメージをロードしてイメージを反映させます。 （AWSのECRなどは今後使って別記事でまとめたいと思います） 手順としては 1. Dockerイメージのビルド docker-compose build 2. タグ付け、save(エクスポート) docker save sample-app-rev | gzip -c > images/sample-app-rev.tar.gz ... 3. EC2へscpでファイル転送 scp -i "xxxx.pem" images/* user@myec2.compute.amazonaws.com:~/sample-app 4. EC2へSSH接続しDockerイメージのロード(docker load) ssh -i "xxxx.pem" user@myec2.compute.amazonaws.com cat sample-app-rev.tar.gz | gzip -d | sudo docker load 5. コンテナ群起動 $ sudo docker-compose up -d 7. 動作確認 最後に動作確認します。 コンテナが起動していて、httpsでブラウザからアプリが動作していればOK $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7774c12a6126 sample-app-rev:latest "/docker-entrypoint.…" 2 days ago Up 9 minutes 80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp rev 84806e8e0caf sample-app-web:latest "/docker-entrypoint.…" 2 days ago Up 9 minutes 80/tcp, 0.0.0.0:49155->3001/tcp, :::49155->3001/tcp web d40eb2a98cf5 quay.io/keycloak/keycloak:latest "/opt/jboss/tools/do…" 2 days ago Up 9 minutes 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 8443/tcp keycloak d16bb66dd269 sample-app-api:latest "docker-entrypoint.s…" 2 days ago Up 9 minutes 0.0.0.0:49154->3000/tcp, :::49154->3000/tcp api 95cd18d0c039 postgres:latest "docker-entrypoint.s…" 2 days ago Up 9 minutes 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp appdb f2fb70558718 postgres:latest "docker-entrypoint.s…" 2 days ago Up 9 minutes 0.0.0.0:49153->5432/tcp, :::49153->5432/tcp keycloakdb さいごに 簡単でしたね。これでサービスが世の中に公開できると考えると素晴らしい！！ もう少しインフラレイヤでの考慮事項（LB、SSL終端・・・）などもありますし、実際のプロジェクト、 業務で構築するには脆弱ですね。ただし、アプリの検証という意味ではこれで十分でした。 LB取り付けてみたり、S3使ってみたりとか色々試してみたいですね。

今回の経緯 Ruby on railsでバッチ処理を行うにあたって、Dockerをインストールしました。 DBはMySQLを使用し、MySQLのデータベースサーバーをDocker上に構築。 問題なく、環境構築を終えローカルPCからDockerのMySQLコンテナへ接続できるようにしました。 環境構築が完了し、いよいよRailsでテーブル作成。 マイグレーションファイルを編集後、データベースに反映させようとしたところ発生したエラーでした。 環境 ・Mac OS ・Rails 6.0.4.1 ・Docker 20.10.8 ・mysql2 0.5.3 エラー内容 % bin/rails db:migrate を実行したところ、以下のエラーが発生。 -- Crash Report log information -------------------------------------------- See Crash Report log file under the one of following: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. 〜中略〜 -- Control frame information ----------------------------------------------- c:0042 p:---- s:0236 e:000235 CFUNC :connect c:0041 p:0614 s:0224 e:000223 METHOD /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/mysql2-0.5.3/lib/mysql2/client.rb:90 [FINISH] c:0040 p:---- s:0210 e:000209 CFUNC :new 〜中略〜 [NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: https://www.ruby-lang.org/bugreport.html [IMPORTANT] Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports. 原因を調べてみると、MySQLのバージョンが原因なのではないかとのことでした。 その後バージョン変更のためにコマンドを実行するも、他のエラーが発生し、そのために再度別のコマンドを実行しの繰り返しでドツボにハマっていきました。 あれやこれやをやっていた矢先、最終的に以下のxcodeを再インストールを実施して出てしまったエラーに1番苦戦したかたちになってしまいました。 以下の3つのコマンドを実行し、xcodeを再インストールしました。 $ sudo rm -rf $(xcode-select -print-path) $ sudo rm -rf /Library/Developer/CommandLineTools $ xcode-select --install xcode再インストール完了後、 $ yarn install 1 error generated. make: *** [Release/obj.target/binding/src/binding.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/shigatakuma/projects/node_modules/@rails/webpacker/node_modules/node-gyp/lib/build.js:262:23) gyp ERR! stack at ChildProcess.emit (node:events:394:28) gyp ERR! stack at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) gyp ERR! System Darwin 20.6.0 gyp ERR! command "/usr/local/Cellar/node/16.8.0/bin/node" "/Users/shigatakuma/projects/node_modules/@rails/webpacker/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library=" gyp ERR! cwd /Users/shigatakuma/projects/node_modules/@rails/webpacker/node_modules/node-sass gyp ERR! node -v v16.8.0 gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok 解決した方法 以下の3つのコマンドでMySQLの状況を調べます。 $ brew search mysql $ which mysql $ ps aux | grep mysql ↓実行結果 $ brew search mysql ==> Formulae automysqlbackup mysql-client@5.7 mysql@5.6 ✔ mysql ✔ mysql-connector-c++ mysql@5.7 mysql++ mysql-sandbox mysqltuner mysql-client mysql-search-replace qt-mysql ==> Casks homebrew/cask/mysql-connector-python homebrew/cask/navicat-for-mysql homebrew/cask/mysql-shell homebrew/cask/sqlpro-for-mysql homebrew/cask/mysql-utilities $ which mysql /usr/local/bin/mysql $ ps aux | grep mysql 1685 0.0 0.0 4920184 604 ?? S 20 821 1:24.21 /usr/local/opt/mysql@5.6/bin/mysqld --basedir=/usr/local/opt/mysql@5.6 --datadir=/usr/local/var/mysql --plugin-dir=/usr/local/opt/mysql@5.6/lib/plugin --log-error=shigataumanoAir.err --pid-file=shigataumanoAir.pid 1566 0.0 0.0 4280140 4 ?? S 20 821 0:00.05 /bin/sh /usr/local/opt/mysql@5.6/bin/mysqld_safe --datadir=/usr/local/var/mysql 92976 0.0 0.0 4259000 220 s002 U+ 9:50AM 0:00.00 grep mysql 以上のコマンドから、 bundle installのときにMySQL5.6の設定を参照してgemがインストールされていることが原因と判明しました。 以下のコマンドでgem mysql2をアンインストールします。 $ bundle exec gem uninstall mysql2 さらにgemをインストールする際の設定を変更します。 $ bundle config --local build.mysql2 "--with-mysql-config=/usr/local/bin/mysql_config --with-ldflags=-L/usr/local/opt/openssl@1.1/lib --with-cppflags=-I/usr/local/opt/openssl@1.1/include" 再インストール後、rails db:migrateを実行します。 $ bundle install $　　bin/rails db:migrate 今度は以下のエラー文が出力されました。 rails aborted! Mysql2::Error::ConnectionError: Access denied for user 'batch_user'@'localhost' (using password: YES) /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/mysql2-0.5.3/lib/mysql2/client.rb:90:in `connect' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/mysql2-0.5.3/lib/mysql2/client.rb:90:in `initialize' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/mysql2_adapter.rb:24:in `new' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/mysql2_adapter.rb:24:in `mysql2_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:887:in `new_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:931:in `checkout_new_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:910:in `try_to_checkout_new_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:871:in `acquire_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:593:in `checkout' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:437:in `connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:1125:in `retrieve_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_handling.rb:221:in `retrieve_connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/connection_handling.rb:189:in `connection' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/tasks/database_tasks.rb:238:in `migrate' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/railties/databases.rake:86:in `block (3 levels) in <main>' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/railties/databases.rake:84:in `each' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/activerecord-6.0.4.1/lib/active_record/railties/databases.rake:84:in `block (2 levels) in <main>' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/railties-6.0.4.1/lib/rails/commands/rake/rake_command.rb:23:in `block in perform' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/railties-6.0.4.1/lib/rails/commands/rake/rake_command.rb:20:in `perform' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/railties-6.0.4.1/lib/rails/command.rb:48:in `invoke' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/railties-6.0.4.1/lib/rails/commands.rb:18:in `<main>' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/bootsnap-1.8.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/bootsnap-1.8.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/bootsnap-1.8.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/bootsnap-1.8.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi' /Users/shigatakuma/projects/.bundle/ruby/2.6.0/gems/bootsnap-1.8.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require' bin/rails:4:in `<main>' Tasks: TOP => db:migrate (See full trace by running task with --trace) ローカルで起動しているMySQLへの接続が優先されているかもしれないとのこと。 docker-compose.ymlファイル内記載のポートを変更(3306 → 3307) version: '3.8' services: mysql: image: mysql:8.0 volumes: - ./tmp/mysql:/var/lib/mysql ports: # - 3306:3306 - 3307:3306 environment: - MYSQL_ROOT_PASSWORD=batch dockerの再起動 $ docker-compose down $ docker-compose up -d ここが重要ですが、MYSQL_PORTを指定してrails db:migrateを実行する必要があります。 $ MYSQL_PORT=3307 bin/rails db:migrate == 20210830030847 CreateUsers: migrating ====================================== -- create_table(:users, {:comment=>"ゲームのユーザー情報を管理するテーブル"}) -> 0.0742s == 20210830030847 CreateUsers: migrated (0.0743s) ============================= == 20210830030923 CreateUserScores: migrating ================================= -- create_table(:user_scores, {:comment=>"ユーザーがゲーム内で獲得した点数"}) -> 0.1328s == 20210830030923 CreateUserScores: migrated (0.1329s) ======================== == 20210830031004 CreateRanks: migrating ====================================== -- create_table(:ranks, {:comment=>"ゲーム内のランキング情報"}) -> 0.1475s == 20210830031004 CreateRanks: migrated (0.1476s) ============================= 上手くいきました！！