20220322のdockerに関する記事は11件です。

Dockerコンテナの中身を保持したまま,もう一度作成(run)しなおしたいとき

はじめに dockerでコンテナを作成するrunコマンドをうつとき,いろいろオプションをつけると思う. しかし,dockerコンテナを作成して少し作業した後で,いくつかのオプションをつけていなかったせいで詰んでしまうということが起きた. 今までのデータを残したまま,もう一度コンテナを作成するための方法を今回まとめる. 対処法 対処法はコンテナをイメージ化し,そこからコンテナを作成するという方法だ. コンテナをイメージ化する. $ docker commit [name] リポジトリ名:TAG [name]はコンテナ名,リポジトリ名とTAGは自分が分かりやすいように各自設定する. これでコンテナの内容を保持したままのイメージを取得することができる. その後は必要なオプションをつけてもう一度コンテナを作成する. $ docker run -it --name [newname] リポジトリ名:TAG コンテナを作成するときはリポジトリ名とTAGを指定する. おわりに 今回はdockerコンテナの中身を保持したまま,もう一度作成しなおしたいときの対処法をまとめた.
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

rails7(apiモード), react, dockerを使って環境構築してみた

環境 Ruby 3.1.1 Rails 7.0.2.3(apiモード) MySQL8.0 node 17.2 rails→3001port、react→3000portになるように設定する 環境構築 まずは以下のディレクトリとファイルを作成 invest_qa |-api |-Gemfile |-Gemfile.lock |-Dockerfile |-entrypoint.sh |-front |-dockerfile |-docker-compose.yml docker-compose.ymlは以下のように docker-compose.yml version: '3' services: db: platform: linux/x86_64 # M1チップ対応のため追記 image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: password ports: - '3306:3306' command: --default-authentication-plugin=mysql_native_password volumes: - mysql-data:/var/lib/mysql api: build: ./api command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - ./api:/myapp - gem_data:/usr/local/bundle ports: - "3001:3000" depends_on: - db stdin_open: true tty: true front: build: ./front command: yarn start ports: - "3000:3000" volumes: - ./front:/myapp depends_on: - api volumes: mysql-data: gem_data: driver: local dockerの環境構築(バックエンド編) Gemfileは以下のように Gemfile source 'https://rubygems.org' gem 'rails', '~> 7.0.2.3' Gemfile.lockは何も書かなくてOK Gemfile.lock entrypoint.shは以下のように entrypoint.sh #!/bin/bash set -e # Remove a potentially pre-existing server.pid for Rails. rm -f /myapp/tmp/pids/server.pid # Then exec the container's main process (what's set as CMD in the Dockerfile). exec "$@" dockerfileは以下のように Dockerfile FROM ruby:3.1.1 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y nodejs yarn \ && mkdir /myapp WORKDIR /myapp COPY Gemfile /myapp/Gemfile COPY Gemfile.lock /myapp/Gemfile.lock RUN bundle install COPY . /myapp COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 CMD ["rails", "server", "-b", "0.0.0.0"] フロントとまとめdockerにbuildしていくのでひとまずフロントエンドの環境構築へ dockerの環境構築(フロントエンド編) Dockerfileは以下のように Dockerfile FROM node:17.2 RUN mkdir /myapp WORKDIR /myapp イメージの構築 以下を実行しイメージの構築をする docker-compose build railsアプリの構築 まずはrailsアプリをapiモードで作成 docker-compose run api rails new . --force --no-deps --database=mysql --skip-test --webpacker --api Gemfileが更新されてるのでイメージを再構築する docker-compose build database.ymlを修正する api/config/database.yml # # And be sure to use new-style password hashing: # https://dev.mysql.com/doc/refman/5.7/en/password-hashing.html # default: &default adapter: mysql2 encoding: utf8 #ここ pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: password  #ここ docker-compose.ymlで設定したパスワード host: db  #ここ docker-compose.ymlでdepend_onしてる development: <<: *default database: myapp_development # Warning: The database defined as "test" will be erased and # re- (以下略) 続いてデータベースの作成のため以下を実行 docker-compose run api rake db:create reactアプリの構築 まずはreactアプリの作成 docker-compose run front npx create-react-app front frontディレクトリに新しいfrontディレクトリが作成されてしまう。。。 元あるfrontディレクトリにコピペしてなんとかしないといけない ともあれこれやればなんとかなる。 それぞれのアプリにアクセス 以下のコマンドを実行してコンテナの構築・起動をする docker-compose up http://localhost:3001 http://localhost:3000 以上で環境構築ができました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Go + MySQL + React のDocker開発環境を作成する

はじめに GoとMySQLとReact(&TypeScript)を使ったポートフォリオ作成をしようと思い、最初に勉強も兼ねてDocker開発環境を作成しました。 そこでQiitaやZennなどで書かれている記事を参考にしていましたが、最終的に他の方とは違う構成になったので自分も記事を執筆しようと思いました。 作成したもの ディレクトリ構成 . ├── README.md ├── db │   ├── data │   └── my.cnf ├── docker-compose.yml ├── go-app │   ├── Dockerfile │   └── main.go ├── react-ts-app │   ├── .dockerignore │   ├── Dockerfile │   ├── README.md │   ├── node_modules │   ├── package-lock.json │   ├── package.json │   ├── public │   ├── src │   └── tsconfig.json └── variables.env Dockerfile(go-app) FROM golang:latest WORKDIR /app/go COPY ./ ./ ENTRYPOINT [ "go", "run", "main.go" ] Dockerfile(react-ts-app) FROM node:17.7.2 WORKDIR /app/react-ts COPY package*.json ./ RUN yarn install COPY . . ENTRYPOINT [ "npm", "start" ] dockerignoreファイル(react-ts-app) node_modules npm-debug.log yarn-error.log docker-compose.yml version: '3' services: react-ts: build: ./react-ts-app ports: - '3000:3000' tty: true stdin_open: true go: build: ./go-app ports: - '8000:8000' tty: true stdin_open: true db: image: mysql:8.0 volumes: - './db/data:/var/lib/mysql' - './db/my.cnf:/etc/mysql/conf.d/my.cnf' # MYSQL_ROOT_PASSWORDのみをenvファイルで設定 env_file: - variables.env ports: - '3306:3306' my.cnf [mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci [client] default-character-set=utf8mb4 解説 Dockerfileは、docker-composeを使わなくても単体で動作することが可能だよねっていう状態を意識しました。 また、docker-composeはあくまでコンテナを立ち上げるのを楽にするためのものだと意識しました。 Dockerfile ENTRYPOINTを指定していることで、docker-composeをupした瞬間にdb・go・react-tsの3つのコンテナが起動&サーバーも起動するようになっています。 COPY句によってDockerfile自体もイメージ内にコピーされてしまいますが、イメージサイズへの影響が小さい・dockerignoreファイルを作成してもビルドにかかる時間は変わらないと判断し、許容しています。 dockerignoreファイルによるビルド時間への影響は下記のサイトが参考になります。 dockerignore(React用) node_modules、npm-debug.log、yarn-error.log の3つを指定しています。 これによってローカルモジュール・デバッグログ・エラーログがDockerイメージにコピーされないようにします。 node_modulesはパッケージがインストールされるディレクトリです。必要なパッケージはソースコードによって異なるため、node_modulesをイメージ内にコピーする必要はないと言えます。 また、node_modules内に多くのパッケージをインストールしている場合、イメージをビルドするときに多くの時間を要します。そのため、node_modules は dockerignoreファイルに登録することが基本となっています。 node_modules のコピーはしませんがコンテナ内でもパッケージは必要になります。ReactのDockerfileでは package.json と package-lock.json をコピーし、yarn install を行うことで、コンテナ使用者が必要なパッケージのみをインストールするようにしています。 Go FROM でイメージを取得するときに、golangにするか、ubuntuのようなOSイメージにするか、golang:<version>-alpineにするかで迷いました。 この中で一番設定ミスが起こりづらそうだと感じたgolangにしました。 dockerの知識量的にOSイメージからGoの環境を整えるのはハードルが高そう。また、alpineはGo projectに公式サポートされていないとDockerhubに書いてあるといった理由で、この2つは選択肢から外しました。 ENTRYPOINT によって、コンテナが立ち上がるとともに go run main.go でサーバーも立ち上がるようにしています。 以下、main.goのコードです。 main.go package main import ( "fmt" "net/http" ) func main() { http.HandleFunc("/", echoHello) http.ListenAndServe(":8000", nil) } func echoHello(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "<h1>Hello World</h1>") } React nodeイメージのDockerfileを見ると、デフォルトでyarnが入っていることがわかります。 なので、yarnをわざわざインストールする必要はありません。 また、Dockerfileやcomposeにcreat-react-appの記述もされている方がいますが、コンテナを起動するたびに新規のプロジェクト作成するのは時間がかかりそうだと感じたので僕は書きませんでした。 あくまでソースコードはホスト上にあり、コンテナへそれらをコピーすることで正常に動くようにしたいと思いました。 次に最も重要な部分ですが、ReactのDockerfileではビルド時間の短縮のためにCOPY句を2つ使っています。 COPY package*.json ./ RUN yarn install COPY . . dockerにはレイヤー構造とキャッシュという概念があり、これを活用することでイメージのビルド時間を短縮できます。 レイヤーとキャッシュについては解説すると長くなるので、ここでは割愛させていただきます。 Reactの開発では頻繁にソースコードを変えると思います。 もし yarn install の前に COPY . . を行うと、ソースコードが変更されるたびにパッケージをインストールし直すことになります。 パッケージを追加・変更していなくても毎回この処理が行われ、多くの時間が費やされてしまいます。 COPY package*.json ./ と yarn install を先に行なっていればレイヤーキャッシュが使用され、ビルドの時間を大幅に節約できます。 以上の理由から、COPYを2回使うようにしました。 この記述方法は、こちらのサイトを参考にしました。 MySQL MYSQL_ROOT_PASSWORDを設定しなければエラーが出ます。 共有をしないのであればcompose上に直接設定してもいいですが、僕はgithubを通じて共有しようと考えていたのでenvファイルを使いました。 MySQLはローカルホスト上ではmysql.server startを使って起動する必要があるかと思いますが、このコンテナ上ではそれが必要ありません。コンテナが立ち上がるとともにDBサーバーも立ち上がります。 my.cnfファイルを用意していありますが、ここでは文字化けを防ぐための設定しかしていません。 もしかしたら他にももっと設定した方がいいものもあるかもしれませんが、沼にハマりそうなのでやめました。 最後に 人によって書き方が違って正しい情報を入手しづらく、結構時間がかかってしまいました。 もちろん僕が書いたものも正しいとは言い切れないので、これから更に知識をアップデートしていきたいなと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker + Next.jsでAPIを叩く時のプチハマり

以前構築した Docker + Nginx + Node.js環境でAPIを叩く時にプチハマりしたことを書きます。 環境は↓ やりたいこと getServerSideProps内とNextPage内それぞれでAPIを叩きたい。 やったこと NextPage内 エンドポイントがlocalhost:8080/api/get-hogeであるとする。 const res = await fetch('http://localhost:8080/api/hoge', { method: 'GET', // 略 }); こちらはうまくいきました。が、 getServerSideProps内 .ts const res = await fetch('http://localhost:8080/api/hoge', { method: 'GET', // 略 }); こっちは Server Error / Error: connect ECONNREFFUSED ~~って出ちゃいました 調べていると、クライアントサイドとサーバーサイドで叩くドメインを変えないいけないようなので、 const res = await fetch('http://host.docker.internal:8080/api/hoge', { method: 'GET', // 略 }); これでできました。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker + Nginx + Node.js で開発環境構築

はじめに 業務で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:3000; } } /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 これでnode.docker.internal:80をたたくとプロジェクトが表示されていると思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Docker]Reactの環境構築をコマンド1発で終わらせる

はじめに 「DockerでReactの環境構築をしたい、そして楽をしたい」と思いました。 手順 1. リポジトリをclone git clone https://github.com/4649rixxxz/qiita-react.git 2. Reactアプリケーションの作成 cd qiita-react qiita-react % make create-project 3. サーバの立ち上げ qiita-react % make app /usr/src/react-app # npm start http://localhost:3000 にアクセスしてみると...おめでとうございます!! その他のコマンド コンテナの起動とサーバの立ち上げ make start 上記のコマンドはコンテナの起動に加えて、「npm start」もしてくれます。 コンテナの停止 make stop TODOリスト 新しい言語やライブラリなどを学ぶ時は「TODOリスト作りたい!」となると思います。 こちらおすすめです。 さいごに Makefile最高。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

仕事でよく使うDockerコマンド

最近、docker環境内でSLAMの環境を構築したので、そのときに使用したdockerコマンドをメモしておく。 dockerコマンド Dockerfileからdockerイメージを作成 docker build -t [保存したいイメージ名]:[保存したいタグ名] [Dockerfileがあるディレクトリパス] dockerイメージをもとに、dokerコンテナを起動する。 オプションrmをつけてコンテナ終了時にそのコンテナを自動的に削除する。 オプションitをつけて、ターミナル入力を可能にする vオプションと、$(pwd):/homeをつけて、docker環境内の/homeディレクトリ内から、ホスト側(dockerを起動している端末側)の現在いるディレクトリに接続して、ファイルを共有する事が出来る。これをホスト側のファイルをコンテナ側にマウントするという。利用例としては、エッジ開発時など容量の少ない端末上で開発環境を整えたいときなどに、ソースコードをホスト側に置き、docker内にビルドする(docker内に実行ファイルを作る)などの事が出来る。マウントは複数ヶ所にできる。 nameオプションでコンテナをイメージとタグに名前をつけることが出来る。 docker run --rm -it -v $(pwd):/home --name [コンテナ名] [イメージ名]:[タグ名] 実行中のコンテナを一覧表示 docker ps 過去に実行したコンテナすべてを表示 docker ps -a 保存されているdockerイメージの一覧表示 docker images 実行中のコンテナから一時的に抜ける(コンテナは起動したまま)。 Ctrl + p -> Ctrl + q 上のコマンドで抜けたコンテナ環境に再度入る docker attach [コンテナID or コンテナ名] コンテナを停止する docker stop [コンテナ名] コンテナを削除する docker rm [コンテナID] dockerコンテナの保存 タグ名にはlatestなどの名前をよく用いている docker commit [起動時に名付けたコンテナ名] [保存したいイメージ名]:[タグ名] 保存されたか確認 docker images ファイルをホストからコンテナへコピーする docker cp file-path [コンテナID]:path dockerイメージをtarファイルに出力(testimage.tarファイルに保存してみる)  - 他の端末に作り上げたdocker環境を移すときなどに使用する - docker環境のバックアップにも使える docker save -o [dockerイメージ名] ~> testimage.tar tarファイルをdockerイメージに戻す(解凍) docker load <- testimage.tar dockerプロセスを切る exit 再度、exitで切ったプロセスを開始 docker ps -a -> docker restart [container ID] 参照 saveコマンドとloadコマンド cpコマンド docker run 公式リファレンス commitコマンド exitコマンドとdetachコマンドの違い
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GCP三分クッキング GCEでjupyter labお手軽格安環境構築編

テテレッテテテ、テテレッテテテ、テテレッテテテ、♪♪♪♪♪♬♪♬♪♪♬♪♪♪♬♬♬♬♪♪♪ こんにちは。GCP三分クッキングの時間が始まりました。 今日のテーマは、「GCEでjupyter labお手軽格安環境構築」です。 原材料 GCE preemptible vm: ※CPU少々、GPUの有無はお好みで。 Dockerfile:お好きなパッケージをpipでトッピングして下さい docker-compose.yml 手順1(0~1分): GCE preemptible vmの作成 GCPのコンソールに行って、preempltibleマシンを作成して、起動して下さい。 手順2(1~2分):Dockerのインストール sshで接続して、dockerとdocker composeをインストールするために、下記を実行します。 shellスクリプトとして、まとめて頂いても結構です。 curl https://get.docker.com | sh sudo usermod -aG docker $USER sudo systemctl start docker sudo systemctl enable docker sudo curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose sudo service docker start 手順3(2~2分20秒): Dockerfileの用意 予め用意しておいたDockerfileを配置します。 一例を示します。 FROM python:3.8.12-buster USER root RUN pip install --no-cache-dir \ numpy==1.22.3\ scipy==1.8.0\ jupyterlab==3.3.2 手順4(2分20秒~2分40秒): Dockerコンテナの起動 docker-compose.ymlを作成します。 一例を示します。port番号は縁起の良い7のゾロ目にしました。 version: "3" services: notebook: build: ./docker_images/jupyter volumes: - ".:/home/work" - ".jupyter:/root/.jupyter" ports: - "7777:7777" tty: true environment: - JUPYTER_ENABLE_LAB=yes command: jupyter lab --ip=0.0.0.0 --port=7777 --allow-root --no-browser この頃には、Dockerとdocker-composeがダウンロード完了していますので、下記を実行します。 sudo docker-compose up 手順5(2分40秒~3分): ローカルからjupyter labを起動 ローカルのPCで下記のコマンドを叩いて接続を確立します。 gcloud compute ssh --project=[project id] --zone=[zone] [instance name] -- -L [local port#]:[instance ip adress]:7777 お疲れ様でした。 最後に、sudo docker-compose upを叩いたときに表示されたリンクをブラウザで開けば、完了です。 jupyter labが使えます。 以上、GCP三分クッキングでした。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

クソ遅いDocker for macを「Mutagen compose」で爆速にする(M1対応)

Mutagen compose Mutagen composeは、Mutagenというローカル環境とリモート環境のディレクトリを高速に同期させることができるオープンソースの開発ツールをDocker composeと統合させたツール。 つまり、Docker環境でホスト側とコンテナー側のファイル同期を高速で行うのに特化したサードパーティーのツール。 事前準備 mutagen-composeのインストール $ brew install mutagen-io/mutagen/mutagen-compose ※ GitHubからバイナリのダウンロードも可能。 これだけで事前準備は完了です。 試してみる プロジェクトで使う docker-compose.yml を用意 docker-compose.yml version: "2" services: web: image: httpd volumes: - ./code:/code ports: - 8080:8080 db: image: mysql environment: MYSQL_ROOT_PASSWORD: example 上の docker-compose.yml にMutagenを使用するための記述を追記 docker-compose.yml version: "2" services: web: image: httpd volumes: - mutagen-volume:/code # 追記: volumeをマウント ports: - 8080:8080 db: image: mysql environment: MYSQL_ROOT_PASSWORD: example # 以下追記 volumes: mutagen-volume: x-mutagen: sync: mutagen-volume: mode: "two-way-resolved" # 同期モード指定(ホスト ↔ コンテナ 双方を同期) alpha: "./code" # プロジェクトのパス beta: "volume://mutagen-volume" # volumeの指定 mutagen-composeを起動 $ mutagen-compose up -d mutagen-composeは、docker-composeと統合されているため、mutagenコンテナ以外のコンテナもこの1コマンドで同時に起動される。 起動されたかどうか確認 $ docker-ps # コンテナが起動しているかどうか確認 # Volumeの確認 $ docker volume ls | grep mutagen-volume local mutagen-volume 起動が確認できたら、ローカル環境にアクセスしたり、ファイルが問題なく同期されるかを試すとデフォルトのDocker for macとの違いを体感できると思います。 「Mutagen compose」 VS 「Docker-sync」 Docker環境に適したファイル同期ツールは他に「Dokcer-sync」があり、「Mutagen compose」とどちらのアーキテクチャ採用をするべきかを レスポンス(速度)、同期の安定性、導入難易度の3つの項目で比較していこうと思います。(本来ならばベンチマークを比較するべきだと思いますが、面倒だったので現時点では割愛します。) レスポンス(速度) 同期の安定性 導入難易度 Mutagen compose ◎ ○ ○ Docker-sync ◎ ✖ △ Docker for mac(デフォルト) ✖ ○ - 結論、以上の観点で一番優れていたMutagen composeを採用いたしました。 Docker-syncは、最初に試したのですが、rbenv/ruby のインストールが必要だったり、CPUの使用率が跳ね上がる問題やファイルの同期が安定しないなどの問題もあったので、個人的にはあまりおすすめできません。 まとめ 現状かなり安定して速くなっているので、Docker for macの遅さにイライラしている方は、mutagen-composeの導入はおすすめです。 ちなみに、MacのM1対応ですが、こちら問題なく動いており、同期も支障なく行われていますので使う分には十分問題ないと思います。 とはいえサードパティーのツールなのでDocker for mac公式でこのマウントが遅い問題を解決されるのが一番良いですね。。 (2022/01/15 v0.13.0 公式リリース)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

遅いDocker for macを「Mutagen compose」で爆速にする(M1対応)

Mutagen compose Mutagen composeは、Mutagenというローカル環境とリモート環境のディレクトリを高速に同期させることができるオープンソースの開発ツールをDocker composeと統合させたツール。 つまり、Docker環境でホスト側とコンテナー側のファイル同期を高速で行うのに特化したサードパーティーのツール。 事前準備 mutagen-composeのインストール $ brew install mutagen-io/mutagen/mutagen-compose ※ GitHubからバイナリのダウンロードも可能。 これだけで事前準備は完了です。 試してみる プロジェクトで使う docker-compose.yml を用意 docker-compose.yml version: "2" services: web: image: httpd volumes: - ./code:/code ports: - 8080:8080 db: image: mysql environment: MYSQL_ROOT_PASSWORD: example 上の docker-compose.yml にMutagenを使用するための記述を追記 docker-compose.yml version: "2" services: web: image: httpd volumes: - mutagen-volume:/code # 追記: volumeをマウント ports: - 8080:8080 db: image: mysql environment: MYSQL_ROOT_PASSWORD: example # 以下追記 volumes: mutagen-volume: x-mutagen: sync: mutagen-volume: mode: "two-way-resolved" # 同期モード指定(ホスト ↔ コンテナ 双方を同期) alpha: "./code" # プロジェクトのパス beta: "volume://mutagen-volume" # volumeの指定 mutagen-composeを起動 $ mutagen-compose up -d mutagen-composeは、docker-composeと統合されているため、mutagenコンテナ以外のコンテナもこの1コマンドで同時に起動される。 起動されたかどうか確認 $ docker-ps # コンテナが起動しているかどうか確認 # Volumeの確認 $ docker volume ls | grep mutagen-volume local mutagen-volume 起動が確認できたら、ローカル環境にアクセスしたり、ファイルが問題なく同期されるかを試すとデフォルトのDocker for macとの違いを体感できると思います。 「Mutagen compose」 VS 「Docker-sync」 Docker環境に適したファイル同期ツールは他に「Dokcer-sync」があり、「Mutagen compose」とどちらのアーキテクチャ採用をするべきかを レスポンス(速度)、同期の安定性、導入難易度の3つの項目で比較していこうと思います。(本来ならばベンチマークを比較するべきだと思いますが、面倒だったので現時点では割愛します。) レスポンス(速度) 同期の安定性 導入難易度 Mutagen compose ◎ ○ ○ Docker-sync ◎ ✖ △ Docker for mac(デフォルト) ✖ ○ - 結論、以上の観点で一番優れていたMutagen composeを採用いたしました。 Docker-syncは、最初に試したのですが、rbenv/ruby のインストールが必要だったり、CPUの使用率が跳ね上がる問題やファイルの同期が安定しないなどの問題もあったので、個人的にはあまりおすすめできません。 まとめ 現状かなり安定して速くなっているので、Docker for macの遅さにイライラしている方は、mutagen-composeの導入はおすすめです。 ちなみに、MacのM1対応ですが、こちら問題なく動いており、同期も支障なく行われていますので使う分には十分問題ないと思います。 とはいえサードパティーのツールなのでDocker for mac公式でこのマウントが遅い問題を解決されるのが一番良いですね。。 (2022/01/15 v0.13.0 公式リリース)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Docker】DBの起動完了を待ってから他のサービスを起動する方法

はじめに  本記事は、プログラミング初学者、学習を進めていて疑問に思った点について調べた結果を備忘録も兼ねてまとめたものです。  そのため、記事の内容に誤りが含まれている可能性があります。ご容赦ください。  間違いを見つけた方は、お手数ですが、ご指摘いただけますと幸いです。 DBの起動完了を待ってから他のサービスを起動する方法 docker-compose.ymlのdepends_on/conditonを設定する方法 以下のようにdepends_onにconditionservice_healthyを設定し、dbのhealthcheckにtestを設定することでDBの起動完了後に他のサービスを起動させることができます。 testのインターバルがデフォルトでは30秒ほどのようでヘルスチェックに時間がかかるため、intarvalを1sに設定しています。 docker-compose.yml version: '${COMPOSE_VER}' services: db: platform: linux/x86_64 image: mysql:${DB_IMAGE_TAG} command: --default-authentication-plugin=mysql_native_password && bash -c "chmod +x /docker-entrypoint-initdb.d/00_grant.sh" healthcheck: test: mysqladmin ping -h db -u$${MYSQL_USER} -p$${MYSQL_PASSWORD} interval: 1s volumes: - mysql_data:/var/lib/mysql - ${MY_CNF_PATH}:/etc/mysql/conf.d/my.cnf - ${INITDB_PATH}:/docker-entrypoint-initdb.d env_file: - ${DB_ENV_FILE_PATH} ports: - "${DB_PORT}:3306" api: build: context: . dockerfile: ./docker/api/Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/myapp environment: RAILS_ENV: ${APP_ENV} ports: - "${API_PORT}:3000" depends_on: db: condition: service_healthy volumes: mysql_data:
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む