はじめに わざわざローカルでSimutransの環境構築をせずとも、インターネット上でブラウザ一つでSimutransを遊びたい... と思ったので、ブラウザでSimutransを遊べるようにしてみました。 やっていることは、DockerでUbuntuの仮想デスクトップ環境を用意してそこでSimutransを動かしているだけです。どんなデスクトップアプリケーションでもわりと汎用的に使える手法だと思います。 Dockerコンテナを立ち上げる 今回は、ベースとしてこのdocker imageを用います。簡単な設定でUbuntu Desktop環境をブラウザから利用できるようにしてくれるスグレモノです。 Dockerfileを以下のように書きます． ENV で設定しているパラメータの詳しい意味は、元イメージのDocker Hubを参照してください。 Dockerfile FROM dorowu/ubuntu-desktop-lxde-vnc # httpアクセスまわりの設定 ENV RELATIVE_URL_ROOT mapViewer ENV USER simutrans ENV HTTP_PASSWORD Password # このPASSWORDはlinuxユーザのパスワード。直接使うことはないので、ランダム文字列を用いる ENV PASSWORD xQhu944hiSwUuMui EXPOSE 80 # Simutransの動作に必要なライブラリをインストール RUN apt-get -y update && apt-get -y upgrade && \ apt-get -y install zlib1g-dev libbz2-dev libpng-dev libsdl2-dev libminiupnpc-dev libfreetype6 # copy simutrans data # Dockerfileと同じディレクトリにsimutransディレクトリを配置し、中にUbuntuで実行可能なバイナリを入れる COPY simutrans/ /home/simutrans/Desktop/simutrans/ RUN chmod u+x /home/simutrans/Desktop/simutrans/sim-linux-OTRPv29_6 Dockerfileと同じディレクトリにsimutransディレクトリを配置し、中にUbuntuで実行可能なバイナリを入れます。 以下のコマンドでビルドすると、 simutrans-online という名前のdocker imageができます。 docker build -t simutrans-online . viewer-container という名前をつけて、コンテナを立ち上げます． docker run -d -p 6080:80 --name viewer-container simutrans-online http://localhost:6080/mapViewer/ にアクセスすると、basic認証を求められるので、 id: simutrans password: Password としてログインすると、下のようにデスクトップ環境が現れます。 このデスクトップ環境内で手動でSimutransを立ち上げます。デスクトップのフォルダアイコンを右クリックして、 Open in Terminal を選択し、 ./sim-linux-OTRPv29_6 などのコマンドで起動します。 ブラウザでSimutransを立ち上げることができました。 いたずら対策 ひとまずSimutransをブラウザ上で遊ぶことが可能になりましたが，この状態でインターネットに公開することは非常に危険です．なぜならば， simutrans ユーザはroot昇格可能で，もしLinuxユーザのパスワードが漏れれば任意のコマンドを実行できてしまうからです． そこで， simutrans ユーザに対して以下の対策を行います． sudo, admグループから外す シェルに rbash を用いて，実行できるコマンドを制限する デスクトップのアプリケーションランチャーからすべてのアプリケーションを削除する docker exec -it viewer-container /bin/bash などでコンテナのシェルに入って，以下のコマンドを実行します．（ついでにアクセス権とタイムゾーンの設定も行っています。） chown -R simutrans:simutrans /home/simutrans/Desktop/simutrans cp /usr/share/zoneinfo/Japan /etc/localtime gpasswd -d simutrans sudo gpasswd -d simutrans adm rm /usr/share/applications/*.desktop chsh -s /bin/rbash simutrans echo export PATH=/home/simutrans >> /home/simutrans/.bashrc chown root:root /home/simutrans/.bashrc chmod 755 /home/simutrans/.bashrc Simutransをプレイする以外のすべての操作を禁止するまでには至りませんが，ひとまず危険な操作を防止することはできるでしょう． 本来はこれらのコマンドをDockerfile中に記述できれば良いのですが，コンテナを実際に起動するまでは simutrans ユーザが生成されないらしく，実行することができません． まとめ デスクトップ環境が必要なアプリケーションをブラウザから手軽に利用するための方法についてまとめました．今回行ったいたずら対策は最低限のものなので、もう少し強力な制限を導入したいものです。 今回はSimutransというゲームを題材にしましたが，どんなデスクトップアプリケーションでもわりと汎用的に使える方法なので皆さんもぜひお試しください．

はじめに DockerでFlaskとMySQLのコンテナを立てて、FlaskからMySQLに接続しようとするとFlaskがエラーを吐いて落ちてしまう状況に何度か遭遇した。対処方法として万人に有効かは分からないが、一応記録する。 出たエラー ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) 解決方法 MySQLにマウントしているディレクトリを一旦消してからコンテナを立て直す。 解説 このエラーが出る原因のひとつは、MySQLの設定を変えてからコンテナを立て直したことである。自分の場合は、環境変数のMYSQL_ROOT_PASSWORDを別のものに書き換えたことが原因だった。 MySQLコンテナが初めて立ち上がる際には、MySQLサーバーの設定ファイル群が自動で作られる。これらは永続ボリュームに保存される。そのため、MySQLの設定を変えた場合は、設定ファイル群を作り直す必要があったのだ。 しかし、一度コンテナを立てると、設定を変えても作り直されることはないため、上記のようなエラーが出ることになる。なので、解決方法としてはボリュームの中身を削除するか、MySQLサーバーに入って設定をいじるということになる。 環境構築の段階で起きやすいエラーなので、作り直してしまった方が早そうである。 まとめ コンテナ上のMySQLサーバーの設定を変更した場合は、コンテナだけでなくデータベースのディレクトリを作り直さないとエラーが出る場合がある。

前回までのおさらい 読んでいる本はこちら Docker/Kubernetes 実践コンテナ開発入門 3章まで読み終わったので、今回は4章編となる。 3章編については以下に記載 Dockerの本を読んでみた -3章編- 章の流れ これまで学習してきた章の実践として、4章が存在する。 よって、Dockerの基礎なんてもう知ってるよ！っていう方は4章からやるのが良いのかもしれない。 章内の主題としては、「Webアプリケーションを実際に構築してみようー！」というもので、作成フローから順々に説明されている。 Webアプリケーションの仕様 そもそも、アプリケーションを作成のフローとは？ 一般的に、Webアプリケーションを作成しよう！となった場合のフローとして、 「企画」→「設計」→「開発」 が主流となる。 それぞれのフローで具体的にどんなことを行うのかということについて、以下にまとめた。 「企画」では、どんな人がいつ使うのかといったターゲット決めを行う 「設計」では、サイトマップ、ワイヤーフレームの作成、データベースの設計を行う 「開発」では、プログラミング言語などを使って設計した仕組みを作っていく 今回は「企画」部分は省略し、「設計」部分から実践演習として問題が定義されていた。 アプリケーションの仕様 実践演習として定義されたものは以下となる。 ・TODOを登録・更新・削除できる ・登録されているTODOの一覧を表示できる ・ブラウザから利用できるWebアプリケーションとして構築する ・ブラウザ以外のプラットフォームからでも利用できるように、JSON APIのエンドポイントも作成する アーキテクチャ(設計図) 作成するアプリケーションはDocker Swarmを使用し、オーケストレーション機能を持たせる。 また、イメージごとに使用するサービスを分ける方式を取っていた。 イメージ名 用途 Service名 Stack名 MySQL データストア mysql_master,mysql_slave MySQL API データストアを操作するAPIサーバ app_api Application Web ビューを生成するアプリケーションサーバ frontend_web Frontend Nginx プロキシサーバ app_nginx,frontend_nginx Application Frontend Nginx アプリケーションのフロントエンドサーバ及びAPIの前段として、Nginxを配置し、リバースプロキシとして動作させる。 Nginxを配置するのはキャッシュ利用、バックエンドの柔軟なルーティングやアクセスログの出力を容易にする為とあった。 配置戦略 今回作成するTODOアプリも、Swarmクラスタ上でそれぞれのServiceを展開する方式を取る。 TODOアプリケーションの全体像 作成していくフローとして以下が記載されていた。本の内容を引用する。 １、データストアとなるMaster/Slave構成のMySQL Serviceの構築 ２、MySQLとデータのやり取りをする為のAPI実装 ３、ウェブアプリケーションとAPI間にリバースプロキシとなるNginxを通じてアクセエスできるように設定 ４、APIを利用してサーバ再度レンダリングをするWebアプリケーションを実装 ５、フロント側にリバースプロキシ(Nginx)を置く 作っていく MySQL編 本内では、gitに参考資料が記載されているので、そこから取ってきた上で構築を進める流れとなっている。 API編 APIのイメージを作成出来るファイルがGitに公開されているので、それを見ながら作業を進めていく感じ。 Nginx編 API編と同様でしたね。 Web編 最後に、WebアプリケーションをNode.jsで構築する流れとなっていた。 Node.jsが分からない場合は、以下を参照すると勉強になったので記載する。 Node.jsとはなにか？なぜみんな使っているのか？ この章でも、今までと同様に見本となるgitが公開されているので、作業する環境にgitをcloneして作業する。 次回の話 5章は以下に記載したので、興味がある方はどうぞ。 Dockerの本を読んでみた -5章編- まとめ WebアプリケーションをDockerでつくってみよう〜ハンズオン章だったと思う。 そもそもWebアプリの構成部分で理解が進んでないと割ときついと思ったので、これ知らんーってなったらその都度調べつつ実施するのが望ましい。 参考資料 Ruby on Railsで作る！Webアプリケーションを0から開発するフローとは

前回までのおさらい 読んでいる本はこちら Docker/Kubernetes 実践コンテナ開発入門 4章まで読み終わったので、（といっても4章はほぼ実践編だったので実装メイン）今回は5章編となる。 5章はとうとう、Kubernetesとは〜という話になってくる。 章の流れ 大まかな流れは ①localにKubernetes環境をつくってみよう ②Kubernetesの概念説明 ③個々の用語と使い方の説明 という感じ。 上記と同じ流れでまとめてみる。 Step1 ローカルにKubernetes環境をつくってみよう これは本を読まなくてもその辺をぐぐれば出てくるので、ぐぐることをおすすめする。 ※本内にもWindowsバージョンとMacバージョンとそれぞれ構築フローが写真と合わせて記載があるので、購入することが悪い訳ではない よって、ローカルに構築する部分については割愛する。 ちなみに個人的にはローカルよりもAWS環境に構築してみる方が身になると考えたので、AWS環境にKubernetesを作ってみた。 （それについては後日別記事にて掲載予定） Step2 Kubernetesの概念説明 そもそもKubernetesって何？って話から入り、リソース名と用語が表形式で記載されている。 表でつらつらと書いても理解出来なかったので、図にして示すことにした。続きに記載 Step3 個々の用語と使い方説明 ここでは、Step2で示した用語の詳細説明が主に記載されている。 それぞれ Kubernetesクラスタとは / Nodeとは それぞれ本の内容を書いてみると、、 Kubernetesクラスタとは、Kubernetesのいろーんなリソースを管理する集合体のこと Nodeとは、Kubernetesのクラスタ管理下に置かれたDockerホストのこと。 そしてNodeには必ず1つMaster Nodeと呼ばれるNode全体を統括するNodeが存在する 上記のような説明があったが、結局どういうこと？？となってしまい、理解が進まなかったので以下のように図とした。 書き方についての注釈をいくつか入れると、以下のようになる。 ※今回はAWS上にKubernetesを立てる想定で書いてみたということ。 ※Kubernetes上では、「Podというコンテナの中にアプリやらストレージやらを載せていくイメージ」ってどこかに書いてあったので、上に積み上げるようなイメージで積み上げていること。 ※矢印が下から上へ向かっていると思うが、これはクラウド上からKubernetes上へどのようにアクセスするのかの経路を示したかった為の矢印であること。 ※また、個人的な理解として、「1つのNode＝AWSでいうところの1つのEC2」という認識であること。 Namespaceとは ネームスペースと読むのだが、これは、「クラスタ」の中にさらに入れ子状態でクラスタを作れる機能のこと。 なぜそんなややこしいことになるのか？クラスタ内にクラスタをつくって意味があるのか？ これには、意味がある。 著書には、例として権限制限が挙げられていた。 例えば、開発者はdevelopment teamと呼ばれるネームスペースに属していて、バックエンドはbackend teamと呼ばれるネームスペースに所属するとする。 そうすると、開発者とバックエンドと別の権限をもって作業に当たれるのだ。 Podとは コンテナの集合体のこと。 注意として、Pod内のコンテナは、一つのNodeに所属することがルールなので、2つのNodeにまたがるコンテナは作れない Podってどうやってつくるの？ 作り方は簡単。ファイルをつくって、実行するだけ。 ①yamlファイルで作りたいPodを定義する ②コマンドを実行する 料理だって、レシピを元につくる。カレーだってレシピがなきゃどのくらいルーを入れていいのかわからないのだ。 同じように、定義ファイルをつくってこれを見てねとお願いしてから実行する。 定義ファイルについては割愛するが、実行コマンドは以下になる。 尚、作成した定義ファイル名は「simple-pod.yaml」とする。 # ----- Pod作成or更新時 ----- # # kubectl apply -f simple-pod.yaml Podってどうやって操作する？ つくったPodの操作方法がわからないと、管理出来ない。 次にPodの操作コマンドが紹介されていた。 # ----- Podの状態取得 ----- # # kubectl get pod # ----- コンテナ内でコマンドを実行する ----- # # 構文 # kubectl exec -i -t [Pod名] -c [コンテナ名] -- [コマンド] # 例 # kubectl exec -it simple-echo sh -c nginx # ----- コンテナを削除する ----- # # 構文 # kubectl delete pod [Pod名] # 例 # kubectl delete pod simple-echo ReplicaSetとは Podの定義ファイルからはPodを1つしか作成出来ない。 よって、冗長構成を取るような可用性を担保したい時は「ReplicaSet」を用いて管理する。 「ReplicaSet」とは、同じ仕様のPodを複数生成・管理する為のリソースと記載がある。 ReplicaSetはどうやってつくるのか？ 先程設定したファイル（Podの仕様を定義したyamlファイル）に、設定を追記するだけでReplicaSetは構築できる。 ※yamlファイルを新たに作成する必要はない。 Deploymentとは Deploymentとは、「ReplicaSetを管理するリソースとして存在するもの」とある また、DeploymentがReplicaSetの世代管理も担うので、「Deployment1つに対してアプリケーション1つ」という単位で運用すると良いとあります。 # ----- ReplicaSet情報を取得----- # # kubectl get rs Serviceとは Podの集合体に対する経路やサービスディスカバリを提供するリソースのこと、とある。 そして、Serviceには3種類存在する。 ・Service - ClusterIP ・Service - NodePort ・Service - LoadBalancer Serviceのつくりかた Serviceも同様にyamlファイルに定義を記載していくことで作成が可能となる。 また注意事項として、基本的にKubernetesクラスタの内部からしかServiceにはアクセス出来ない。 Service - ClusterIP ServiceのデフォルトはClusterIP機能 この機能は、クラスタ上の内部IPへIPを公開してくれる機能のこと。 よって、このServiceを作成することで、PodからPodへのアクセスが可能となる。 Service - NodePort クラスタ外からアクセスする為のもので、ServicePortへ接続する為にグローバルなポートを開けてくれる機能のこと Service - LoadBalancer クラウド環境（Azure/AWS/GCPなど）内で提供されているLBと連携する為の機能のこと。 注意事項として、この機能はローカルのKubernetesでは利用出来ないことが挙げられる。 Ingressとは Kubernetesクラスタの外にServiceを後悔する為には、ServiceをNordPortで公開することが出来るAPIオブジェクトのこと。 Ingressは負荷分散機能も持っている、らしい。 まとめ Kubernetesの用語理解だけでいうと、自分なりに図にして落とし込むのが手っ取り早いなと思った。 (本を買って読むのも勿論大事だが、公式で記載されているドキュメントを読む方が早い、と思うのも一理あったりなかったり。。) 最後までお読みいただきありがとうございました！ 認識相違などご指摘ありましたらコメントいただけると幸いです。 参考文献・参考サイト GETTING STARTED ReplicaSet Service Ingress kubectlチートシート

dockerコンテナにつなげている場合、コンテナから出てくるログに対してパイプをつなげたいということが度々生じるが、実現するのにかなり苦労したので、備忘録として残しておく grepでパイプラインさせる コンテナログから最新のログを出し、垂れ流したい場合はこのようにします。-fのみだと全部出てくるため、--tailオプションも併用しています。 ※ 出力したいコンテナ名をcontainer_nameとしています。 docker logs container_name -f --tail 1 これをgrepでパイプラインさせる場合は、以下のことに注意する必要があります。 docker logsのログはSTDOUTおよびSTDERR双方に出力されることがあるため、|&でパイプラインさせる grepでは出力がバッファされてしまうので、--line-bufferedオプションもつけてバッファさせないようにしておく（ここでさんざんハマりました） したがって、このようにすればgrepでパイプラインできるようになります。 docker logs container_name -f --tail 1 |& grep --line-buffered [ここに絞り込みたい条件を記載] さらにjqでパイプラインさせる docker logsの結果にjsonで流し込んでいる場合は、jqでパイプラインさせたいときがあります。 その場合は、以下のことに注意する必要があります。 jsonの部分を取り出したいので、grepで抽出させる。もちろんバッファされないようにするため、--line-bufferedも併用しておく その結果をjqに入れるが、バッファさせないようにするため--unbufferedオプションをつけておく したがって、このようにすればjqでパイプラインできるようになります。 docker logs container_name -f --tail 1 |& grep --line-buffered -io '{.*}' | jq --unbuffered '.'

今回の記事は前回の記事の続きである。 Reactによるアプリの開発の流れの最終段階。 Production Phaseにおいては、Dockerfile.dev ではなく、Dockerfileを書くことになる。 このProductionのためのDockerfileには『FROM』が2つ以上書かれ、2つのステージに分けてDocker Imageが作られることになる。(マルチステージビルドと呼ばれる) 今回の記事では なぜProduction(本番)ではマルチステージビルドが必要になるのか Production用のサーバーで人気なnginxの概要 を書いていく npm run start とnpm run buildの違い npm run startではDevelopment用のサーバーも実行されていた それがProduction Phaseに移り、npm run buildを実行するとDevelopment Phaseの時に実行されていたDevelopment用のサーバーがなくなる。 npm run build は、Development Phaseの時に複数のファイルに分かれていたHTML CSS Javascriptなどを1つのファイルにして吐き出すことになる。その時にWebサーバーは用意されない。 なぜnpm run buildではサーバーが実行されないのか Development phaseにおいてはソースコードを書き換えたり、その書き換えたソースコードをreloadしてくれるサーバーが必要であった。 それが、Production phaseではソースコードを書き換えることが無いのでDevelopmentの時とは違うサーバーが必要。 Productionの段階で必要なサーバーは ブラウザーからのリクエストに反応して、ReactアプリケーションのコードやHTMLコードなどをレンダリングしてくれるだけの機能を持ったWebサーバー。 このProductionのためのWebサーバーで最も人気のあるものの1つが『nginx』になる。 では、『npm run build』のコマンドを実行するためにベースのイメージにnodeを使ったのに、サーバーはnginxで実行するというのを可能にするにはどのようにDockerfileを書けばいいだろうか？ npm run buildを実行するために、ベースイメージにnode:alpineを使ったContainerをさらに、nginxのイメージを使ってWebサーバーを作るにはどうしたら良いのだろうか？ マルチステージビルドのDockerfile ステージを分けてDockerfileを書くことで上記の問題を解決する事ができる buildステージによって、HTML CSS JavaScriptコードからbuildファイルを作る runステージによって、nginxのwebサーバーを実行させる。

経緯 開発環境ではMySQLを使っていたが、HerokuではPostgresqlがデフォルトでMySQLを使うにはクレジットカードが必要だったがクレジットカードを持っていなかったため開発環境はPostgresqlに変更してHerokuにデプロイすることになった。 目標 development, testのデータベースはMySQLのままでProductionのみPostgresqlに変更しHerokuにデプロイする。 環境 Windows10 Docker Rails MySQL Postgresql 実行内容 Gemfileの変更 Dockerfileの変更 docker-compose.ymlの変更 database.ymlの変更 Herokuの設定 Herokuの接続先情報の追加 Heroku上で公開 1. Gemfileの変更 Gemfile group :production do gem 'pg' end production用にpgを追加する。また、mysql2に関してはproductionでは使わないためgroup :development :testに封印しておく。その後 docker-compose run web bundle install 2. Dockerfileの変更 dockerfile FROM ruby:2.5 RUN apt-get update -qq && apt-get install -y nodejs yarnpkg RUN ln -s /usr/bin/yarnpkg /usr/bin/yarn RUN mkdir /app WORKDIR /app COPY Gemfile /app/Gemfile COPY Gemfile.lock /app/Gemfile.lock RUN bundle install COPY . /app COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 ENV RAILS_ENV production 　　#これを追加する CMD ["rails", "server", "-b", "0.0.0.0"] productionで動かせるようにDockerfileにENV RAILS_ENV productionを追加する。 3. docker-compose.ymlの変更 docker-compose.yml version: '3' services: db: image: postgres environment: POSTGRES_USER: <%= ENV['APP_USERNAME'] %> POSTGRES_PASSWORD: <%= ENV['APP_PASSWORD'] %> PGDATA: /var/lib/postgresql/data/pgdata volumes: - ./tmp/db:/var/lib/postgresql/data web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" environment: RAILS_ENV: production volumes: - .:/app - gem_data:/usr/local/bundle ports: - "3000:3000" depends_on: - db volumes: gem_data: POSTGRES_USER, POSTGRES_PASSWORDにdatabase.ymlにも指定する環境変数を指定しておく。RAILS_ENV: productionも設定しておく。 4. database.ymlの変更 database.yml production: <<: *default adapter: postgresql encoding: unicode pool: 5 database: <%= ENV['APP_DATABASE'] %> username: <%= ENV['APP_USERNAME'] %> password: <%= ENV['APP_PASSWORD'] %> host: <%= ENV['APP_HOST'] %> database, username, password, hostには任意の環境変数を設定する。（後からHerokuに接続先情報を追加する） 5. Herokuの設定 heroku login 　　　↓ heroku container:login 　　　↓ heroku create -a application_name 　　　↓　 heroku addons:create heroku-postgresql:hobby-dev heroku createでHerokuアプリケーションを作成する。-a によってアプリケーションに任意の名前を付けることができる。 heroku用のデータベースをアドオンとして追加する。お金がないのでタダのheroku-postgresql:hobby-devを用いる。 6. Herokuの接続先情報の追加 database.ymlでは環境変数を使っているため、Herokuに環境変数を設定しておく必要があり、まずはHerokuのデータベース情報を取得する。 heroku config -a application_name これを実行するとアプリケーションに関する情報が表示されるため、そのなかにあるDATABA_URLを確認する。DATABASE_URLは次のようになっている。 DATABASE_URL:postgres://<username>:<password>@<host>/<database> これらを用いて環境変数を設定する。heroku config:add ~で環境変数は設定することができ、APP_USERNAMEを設定する場合は次のよう heroku config:add APP_USERNAME='<username>' -a application_name APP_DATABASE, APP_PASSWORD, APP_HOSTも同様に設定する。 ※APP_USERNAME = ''など＝の間に半角スペースを入れるとエラーになるため気を付けてね^^ 設定できているかを確認したい場合は heroku config -a application_nameで確認することができる。 7. Heroku上で公開する いろいろ終わったらあとは公開するだけ プロジェクトディレクトリでコンテナにログインした状態で heroku container:push web -a application_name 　　　↓ heroku container:release web -a application_name 　　　↓ heroku run rails db:migrate ↓ heroku run rails assets:precompile 　　　↓ heroku open へいお待ち 8.補足 Herokuはデフォルトではlogの量が少なくerrorの原因がわからないことがあるためlogが多く出されるように設定しておく heroku config:add RAILS_LOG_TO_STDOUT='true' -a application_name 参考にしたサイト 　DockerでRailsの環境構築してHerokuへデプロイする 　Container Registry および Runtime (Docker デプロイ) まとめ 改善点などあれば指摘していただけたら嬉しいです。

業務でNext.jsに触れる機会があったのでDockerで開発環境構築をやってみたいと思ったので書いていきます。 実際にはMySQLも含みますがサーバーサイド側のため割愛します。 *ローカル開発環境構築の想定のため、セキュリティは本番環境を想定していません。 やりたいこと docker-composeでNginxコンテナをリバースプロキシとしてNode.jsコンテナへリクエストを投げる環境の構築 環境構築 Docker for Macをインストール済みかつNext.jsでプロジェクト作成済みを想定 docker version $docker --version Docker version 20.10.6, build 370c289 ディレクトリ構造 ├── docker-compose.yml ├── node | ├── Dockerfile ├── nginx ├── default.conf docker-compose.yml services: nginx: image: nginx:1.21-alpine container_name: next-nginx ports: - "80:80" depends_on: - node volumes: - ./nginx/default.conf:/etc/nginx/conf.d/default.conf node: build: ./node container_name: node volumes: - {プロジェクトルーティング}/:/usr/src/app/ Dockerfile curl使ってAPIとの連携確認できたら便利かなと思い入れています。 FROM node:16-alpine RUN apk --no-cache add curl WORKDIR /usr/src/app/ default.conf server { listen 80; server_name node.docker.internal; root /var/www/public; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass 127.0.0.1:4000; } } /etc/hosts 127.0.0.1 node.docker.internal docker-compose up $docker-compose up -d --build // imageダウンロードとかbuildのログがいっぱいでてきます。 $docker-compose ps Name Command State Ports -------------------------------------------------------------------------------------------------------------- nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp,:::80->80/tcp node docker-entrypoint.sh npm r ... Up 3000/tcp, 5000/tcp, うまく起動できたようなので次はnodeコンテナに入りnpm run devを実行します。 $docker-compose exec node sh #npm run dev する際のポートを変更する $vi package.json "scripts": { "dev": "next dev --port 4000", //← ここに--port 4000を追加 "build": "next build", "start": "next start" }, $npm run dev これでnode.docker.internal:80をたたくとプロジェクトが表示されていると思います。 現状の課題 nodeコンテナをcompose up -d -buildするとデフォルトで3000ポートが公開されていてnpm run devされていない状態でも閲覧可能でした。しかし、ファイルを編集してもnpm run devしていないので変更が反映されないので、default.confのproxy_passで4000ポートを指定し、npm run devするポートも4000に変更しました。 docker-compose up -d --buildした時点のnpm run devのポートが占領されてしまうため、docker-compose up -d --build後にpackage.jsonを編集する必要がありました。 この部分は最適解ではないと思うので、どうすれば対策できるか調べていこうと思います。 コメントでも是非教えて頂ければ幸いです。

目標 本番環境(production)でdockerを用いてrailsを動かす 実行内容 docker-compose.prd.ymlの作成 database.ymlの変更 DBの作成 アセットのプリコンパイル ビルド、起動 1. docker-compose.prd.ymlの作成 docker-compose.prd.yml version: '3' services: db: image: postgres environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_HOST_AUTH_METHOD: 'trust' #実際にデプロイする場合は使わない PGDATA: /var/lib/postgresql/data/pgdata volumes: - ./tmp/db:/var/lib/postgresql/data web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" environment: RAILS_ENV: production　 #これを追加する。 volumes: - .:/app - gem_data:/usr/local/bundle ports: - "3000:3000" depends_on: - db volumes: gem_data: development環境で動かしていたdocker-compose.ymlとは別で、docker-compose.prd.ymlを作成しwebのenvironmentにはRAILS_ENV=productionを指定する。 また、productionとtestではdatabase.ymlのhost: dbを指定することができるがproductionではできないためとりあえずPOSTGRES_HOST_AUTH_METHOD: 'trust'を設定する。デプロイする際には環境変数を使って設定する。 2. database.ymlの変更 database.yml production: <<: *default adapter: postgresql encoding: unicode pool: 5 database: app_production username: postgres password: postgres username, passwordにはdocker-compose.prd.ymlのPOSTGRES_USER,POSTGRES_PASSWORDの値を設定する。(デプロイの際は環境変数を用いる)hostはdocker-compose.prd.ymlでPOSTGRES_HOST_AUTH_METHOD: 'trust'を設定しているため特に設定しない。 3. DBの作成 docker-compose -f docker-compose.prd.yml run web rails db:create RAILS_ENV=production -f docker-compose.prd.ymlをつけ忘れないように気を付ける。 docker-compose -f docker-compose.prd.yml run web rails db:migrate RAILS_ENV=production 4. アセットのプリコンパイル docker-compose run web rails assets:precompile RAILS_ENV=production 本番環境の場合、アセットのプリコンパイルをしておかないと起動しない。 5. ビルドして起動 docker-compose -f docker-compose.prd.yml build docker-compose -f docker-compose.prd.yml up 補足 development環境では読み込まれていた画像が表示されなかったりcssが適用されない,httpのメソッドがDELETEで指定しているのにGETでアクセスされているなどがあった場合 config/environments/production.rbで次のように変更する。 production.rb config.public_file_server.enabled = true 参考にしたサイト 　Dockerでコンテナ化したrailsアプリをproductionモードで起動する 　【初めての環境構築】Windows10にRails6+MySQL8.0+Dockerな環境を作ってみた まとめ 改善点や間違っているところがあればぜひ意見をお願いします!