20210610のdockerに関する記事は6件です。

[Docker / Rails / Passenger] binding.pryに対して、'stty: standard input: Inappropriate ioctl for device' 発生

Prerequisites (前提) Item Type / Version OS Docker (ruby:2.5.7) Ruby on Rails 5.2.3 Application Server passenger(6.0.7) ※application serverは、pumaではなかった。 pumaへと変更することでこの問題は解消した。 docker-compose.yml version: '3' services: web: # ------ 省略 -------- ports: - 3000:3000 # binding.pryで処理を止め、コマンドプロンプト入力を行うために必要な設定2つ stdin_open: true tty: true 以下のコマンドでdockerコンテナを起動すると、 docker上ではなくてホストOS上でRuby on Railsのサーバーが動作しているかのようにログを表示させることができる。 そして、コマンドプロンプト上でのキー入力が可能になる。 $ docker-compose up -d # container_nameの部分には、 # docker-compose up -d の実行結果として表示されるcontainer名を指定すればよい $ docker attach container_name Phenomenon (事象) Ruby on Railsの開発を行う上で大変便利なpryやpry-railsが使えなかった。 具体的には、binding.pryと書いた箇所へ処理が到達すると、以下のようなエラーメッセージが表示された。 # ------ 省略 -------- App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: stty: 'standard input': Inappropriate ioctl for device App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: stty: 'standard input' App 269 output: : Inappropriate ioctl for device App 269 output: [1] pry(#<Hotels::Queries::SearchByAmenities>)> 注目すべきエラーメッセージはこれ。 stty: standard input: Inappropriate ioctl for device Solution (解決策) ネットの海をさまよってみたものの、どこに書いてある方法も役には立たなかった。 役に立つ方法を見つけられなかっただけ、という可能性が十分あります...(´;ω;`)ブワッ 仕方ないので、試しに、Application Serverを、passengerから普段使っているpumaへと変更したところ、あっさり解決。 Gemfile # gem 'passenger' <- コメントアウトした gem 'puma' # <- 書き足した この状態でbundle installし直し、Application Serverを再起動。 その後、binding.pryを書いておいた処理へと到達させたところ、無事キー入力可能な状態になった。 [1] pry(#<Hotels::Queries::SearchByAmenities>)> 本番でpassenger使っていて、どうしてもこの問題を回避したいのであれば、開発中だけpumaを使うのもありかもしれない。 もしpassengerを使う理由がなく、かつ自分に決定権があれば、真面目にpumaへの切り替えを検討していると思う。 Discussion (議論の余地がある部分) passenger単独でもこの事象が発生するのか、それとも、Dockerと組み合わせた時にだけこの事象が発生するのか、確かめることができていません。 つまり、「OSにrubyをインストールし、OSのrubyを使ってpassengerをApplication Serverとして利用している」という場合に、同様の事象が発生する可能性をまだ潰せていません。 (もうDockerなしで開発するということを考えたくないので)この検証はしないのですが、もしpassenger単独でこの事象が発生するのであれば、passengerの方で何かしら対策を用意してくれているような気がしないでもないです。 逆に、Dockerとの組み合わせによる問題であった場合は、完全に放置されていたとしてもおかしくない....₍₍ (ง ˘ω˘ )ว ⁾⁾スヤッスヤッ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel 8.x Docker環境でテスト用コンテナを立ち上げてテストを実行する

はじめに Docker環境で構築したLaravel8のテストを行う前に、環境構築でハマりました。 私がハマったのは、Dockerを使っていないLaravelの手順でテストを行おうとしていたため。 単純にLaravelを使って開発するのと、Docker環境上で開発しているのとでは勝手が違うようです。 これからもDockerを使ったLaravelアプリは作っていくと思うので、備忘録を兼ねた記事です。 現状のDocker環境 docker-compose.yml version: "3.9" services: app: build: ./infra/php volumes: - ./app:/work web: image: nginx:1.20-alpine ports: - 80:80 volumes: - ./app:/work - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf working_dir: /work db: build: ./infra/mysql volumes: - db-store:/var/lib/mysql volumes: db-store: infra/mysql/Dockerfile FROM mysql/mysql-server:8.0 ENV MYSQL_DATABASE=laravel_local \ MYSQL_USER=phper \ MYSQL_PASSWORD=secret \ MYSQL_ROOT_PASSWORD=secret \ TZ=Asia/Tokyo COPY ./my.cnf /etc/my.cnf RUN chmod 644 /etc/my.cnf 環境構築は、ucan-labさんの超入門】20分でLaravel開発環境を爆速構築するDockerハンズオンを参考にすると、死ぬほどわかりやすい。 今回はこの環境に、テスト用のDBコンテナを立ち上げる。 テスト用コンテナの作成 以下を加える。 docker-compose.yml db-test: build: ./infra/mysql-test volumes: - db-store:/db-test/var/lib/mysql ports: - 3000:3306 db-testはservices直下になるようインデントに気をつけて配置する。 infra/mysql-test/Dockerfile FROM mysql/mysql-server:8.0 ENV MYSQL_DATABASE=laravel_local_test \ MYSQL_USER=phper \ MYSQL_PASSWORD=secret \ MYSQL_ROOT_PASSWORD=secret \ TZ=Asia/Tokyo COPY ./my.cnf /etc/my.cnf RUN chmod 644 /etc/my.cnf MYSQL_DATABASEは変えても変えなくても大丈夫。 コンテナを立ち上げる docker compose up -d --build NAME SERVICE STATUS PORTS app_name_app_1 app running 9000/tcp app_name_db-test_1 db-test running (healthy) 0.0.0.0:3000->3306/tcp, :::3000->3306/tcp, 33060/tcp, 33061/tcp app_name_db_1 db running (healthy) 33061/tcp, 3306/tcp, 33060/tcp app_name_web_1 web running 0.0.0.0:80->80/tcp, :::80->80/tcp running(healthy)になっていればOK 上手く立ち上がらない場合は、以前に立ち上げていたコンテナのキャッシュの影響の可能性があるため、以下のコマンドを入力してみる。 docker-compose down docker-compose build --no-cache docker-compose up -d テスト用envファイルを作成する .envファイルは通常のdbコンテナ用にすでに作成してあると思うので、以下のコマンドで.env.example をコピーして.env.testingを作成する。 cp .env.example .env.testing .env.testingの一部を変更する APP_ENV=testing APP_KEY= DB_CONNECTION=mysql DB_HOST=db-test DB_PORT=3306 DB_DATABASE=laravel_local_test DB_USERNAME=phper DB_PASSWORD=secret 作成したら、APP_KEYを生成する php artisan key:generate --env=testing --env=testingはオプション。付けなければ.envを参照し、付ければ.env.testingを参照してくれる。 .env.testingのAPP_KEYに値がセットされていることを確認する。 migrateする db-testにデータベースを作成する。 こちらも--env=testingオプションを付けることで.env.testingファイルを参照してマイグレートしてくれる。 php artisan migrate --env=testing もし、Nothing to migrate.と出てマイグレート出来ない場合は、キャッシュを削除してから再実行する。 php artisan config:clear php artisan migrate --env=testing 一応各コンテナにDBがあるか確認する。 dbコンテナ こちらは触っていないが、laravel_localというデータベースがあればOK。 docker-compose exec db bash -c 'mysql -u${MYSQL_USER} -p${MYSQL_PASSWORD} ${MYSQL_DATABASE}' mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | laravel_local | +--------------------+ 続いて、新しく作成したコンテナに接続。 こちらには新しく作成したデータベースがあればOK。 docker-compose exec db-test bash -c 'mysql -u${MYSQL_USER} -p${MYSQL_PASSWORD} ${MYSQL_DATABASE}' mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | laravel_local_test | +--------------------+ さらに、テーブルが存在するかを確認する場合は、以下のコマンドを実行する。 mysql> use laravel_local_test; Database changed mysql> show tables; +------------------------------+ | Tables_in_laravel_local_test | +------------------------------+ | failed_jobs | | migrations | | password_resets | | users | +------------------------------+ 4 rows in set (0.00 sec) マイグレーションファイルで設定したテーブルが作成されていればOK。 テストを実行する ここまでくれば、あとはテスト内容を書いて実行するだけ。 さいごに 今回始めてDocker環境でのテストを行いました。 なので、間違っていること等あれば、言っていただけると有り難いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker環境構築

はじめに Dockerのインストールについて忘却録として残しておきます。 概要 仮想マシンを作成しその上でDockerを動かします。 すべてroot権限で実行していきます。 環境構成 OS : CentOS Stream 8 (kernel 4.18.0-305.3.1.el8) Docker : Community 20.10.7 手順 OSインストール (省略) OS設定 Dockerインストール OS設定 考慮するのが面倒なためfirwalldとSELinuxを無効化しておきます。 必要に応じて実施してくださ。 # systemctl disable firewalld --now Removed /etc/systemd/system/multi-user.target.wants/firewalld.service. Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. # setenforce 0 # sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config Dockerインストール 公式手順に従ってインストールしていきます。 インストールの動作確認は hello-world コンテナーを事項して確認します。 初めての実行となるためコンテナーイメージのダウンロードが行われますが、2回目以降はダウンロードは行われずローカルに保存されているイメージより実行されます。 リポジトリインストール # dnf install -y yum-utils (省略) # yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo repo の追加: https://download.docker.com/linux/centos/docker-ce.repo Dockerエンジンインストール # dnf install docker-ce docker-ce-cli containerd.io (省略) Docker起動・自動起動設定 # systemctl enable docker --now Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service. テスト用コンテナー起動 # docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world b8dfde127a29: Pull complete Digest: sha256:9f6ad537c5132bcce57f7a0a20e317228d382c3cd61edae14650eec68b2b345c Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ hello-worldイメージは Hello from Docker! を表示させるためだけのイメージのためこの表示で完了になります。 よく使うオプションと解説 オプション 解説 実行例 run Dockerイメージからコンテナーの生成と起動 docker run <イメージ名> run [オプション] 起動と同時に実施する内容を指定-it : コンソール出力--name : コンテナー名指定-d : バックグラウンド実行-p <ホストポート>:<コンテナーポート> : ポート転送設定--net : デフォルトのブリッジからホストIPを使用する設定等-e <環境変数>=<設定値> : コンテナー内の環境変数を設定-v <ホストディレクトリ>:<コンテナディレクトリ> ホストのディレクトリをコンテナー内にマウント docker run -it <イメージ名> stats コンテナーの動作状況確認 docker status <コンテナ名> exec 実行中のコンテナー内で新たなコマンドを実行-itオプションを使用してBashを起動すればDockerのコンソールに入れます※attachオプションと違ってBashプロセスを新たに起動させて接続する docker exec -it <コンテナー名> /bin/bash container ls 実行中のコンテナー一覧を表示します停止中のコンテナーも表示させる場合は -a オプションを付けてください docker container ls container start 停止中のコンテナーを起動※containerは省略可能 docker container start <コンテナー名> container restart 稼働中のコンテナーを再起動※containerは省略可能 docker container restart <コンテナー名> container stop 稼働中のコンテナーを停止※containerは省略可能 docker container stop <コンテナー名> container rm 停止中のコンテナーの削除-fオプションを付けると稼働中のコンテナーも削除できます※containerは省略可能 docker container rm <コンテナー名> images ローカルにダウンロード済みのイメージ一覧を表示 docker images rmi Dockerイメージを削除※稼働中のコンテナーで使用されているイメージは削除できません docker rmi <イメージ名> 引用 docker docs - Install Docker Engine on CentOS
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

コンテナのservicesを変えて実行してしまったせいで古いコンテナが削除できなくなった話

概論 docker composeを勉強していた際に、もともとあったコンテナのサービス名をコンテナ構成した後に、サービス名を変更して再構築してしまった際に面倒になったのでメモします。 docker-compose.yml 前の記事の、docker-compose.ymlのservicesをhelloからhello1に変更。 docker-compose.yml version: "3" services: hello1: container_name: failue_hello1 build: . working_dir: /home/print_hello tty: true これでコンテナを作成する コンテナ作成 $ docker compose up -d 確認 $ docker compose ps -a NAME SERVICE STATUS PORTS docker-hello_world hello exited docker-hello_world1 hello1 running ここでservice hello を削除してみる $ docker compose rm hello no such service: hello そんなserviceは存在しないと帰ってきた ファイルで定義されていないとコンテナは存在しないため、文字には残るが削除ができなくなる。 これを削除したい。 削除コマンド $ docker compose up --remove-orphans --remove-orphansはdocker-compose.ymlで定義されていないservice用コンテナを削除する 出力結果 実行結果 [+] Running 2/0 ⠿ Container docker-hello_world Removed 0.0s ⠿ Container docker-hello_world1 Running 0.0s Attaching to docker-hello_world1 ここでなぜか進まないため、Ctl+Cを押すと前に進む。 ^CGracefully stopping... (press Ctrl+C again to force) [+] Running 0/1 ⠏ Container docker-hello_world1 Stopping 2.0s [+] Running 0/1t 3 SIGTERM/SIGINTs, forcing shutdown [+] Running 0/docker-hello_world1 Killing 2.1s ⠙ Container docker-hello_world1 Killing 2.2s canceled 出力結果を見る限り新しいコンテナが起動していたため、出力が進まなかったと考えられる。 これでdocker composeのコンテナを確認する。 コンテナ確認 $ docker compose ps -a NAME SERVICE STATUS PORTS docker-hello_world1 hello1 exited これでdocker-compose.ymlに定義されていないserviceのコンテナを削除できた。 終わり servicesを変えたらどうなるのか確認したかっただけだが、ちょっと面倒になったため基本的にservicesの部分は変えないようにする。 もしDockerを勉強し始めで同じ状況になったら参考にしてみてください。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

よく利用するDockerコマンド一覧

Dockerコマンド 詳細 Docker ps 起動中のDockerコンテナ一覧を表示 Docker ps -a 起動の有無に関わらずコンテナ一覧を表示 Docker images Dockerイメージの一覧を表示 Docker pull Docker hubからイメージを取得 Docker save Dockerイメージをファイルに変換 Docker run Dockerコンテナの起動 Docker search Docker Hub のイメージを検索 Docker exec Dockerコンテナ内でコマンド実行 Docker start Dockerコンテナの起動 Docker stop Dockerコンテナの停止 Docker commit Dockerコンテナのイメージ化 Docker rm Dockerコンテナの削除 Docker rmi Dockerイメージの削除 Docker cp Dockerコンテナとホスト間でファイルをコピー Docker save Dockerイメージをファイルに変換 Docker load ファイルからDockerイメージを抽出
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker-compose で名前付きボリュームをホストのディレクトリにマウントする

自分用メモ。 バインドマウントとは似て非なるもの。 コンテナイメージのマウント先ディレクトリにファイルが存在している場合、下記のような挙動をする。 バインドマウント コンテナイメージのディレクトリは消失し、ホストのディレクトリがマウントされる 名前付きボリューム (ホスト側にファイルがない場合)コンテナイメージのファイルがマウント先ディレクトリから名前付きボリュームにコピーされた上で、ホストのディレクトリがマウントされる docker-compose.yml version: "3" services: httpd: image: httpd ports: - "8180:80" volumes: - "httpd-conf:/usr/local/apache2/conf" volumes: httpd-conf: driver: local driver_opts: type: none o: bind device: ./conf/httpd/
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む