開発環境をDockerで開発していたRails6アプリケーションをAWS(ECS)にデプロイしている実装で、AWS上にデータベースが作成できない問題が発生したので解決までの手順を残しておこうと思います。 開発環境 RubyMine Ruby 3.0.1 Ruby on Rails 6.1.3 Docker 20.10.7 AWS (ECS fargate/ECR/VPC/RDS/ACM/ALB/S3/Route53) 発生していた問題 オリジナルアプリをDockerで開発していたので、デプロイ先をAWS(ECS fargate)にしたいと思い実装を進めているなかで、本番環境でデータベースが作成されないエラーが起きました。 エラー内容(ECSタスク上のログ) 2021-07-26 19:26:48Tasks: TOP => db:create 2021-07-26 19:26:48(See full trace by running task with --trace) 2021-07-26 19:26:48rails aborted! 2021-07-26 19:26:48ActiveRecord::ConnectionNotEstablished: Unknown MySQL server host 'db' (-2) 2021-07-26 19:26:48Caused by: 2021-07-26 19:26:48Mysql2::Error::ConnectionError: Unknown MySQL server host 'db' (-2) 2021-07-26 19:26:48Unknown MySQL server host 'db' (-2) 2021-07-26 19:26:48Couldn't create 'locat' database. Please check your configuration. エラー文を調べたところ、サーバーホスト名dbが本番環境で見つからないというエラー内容だとわかりました。 修正前のdatabase.yml # MySQL. Versions 5.5.8 and up are supported. # # Install the MySQL driver # gem install mysql2 # # Ensure the MySQL gem is defined in your Gemfile # gem 'mysql2' # # 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 socket: /tmp/mysql.sock host: db development: <<: *default database: locat_development # Warning: The database defined as "test" will be erased and # re-generated from your development database when you run "rake". # Do not set this db to the same as development or production. test: <<: *default database: locat_test production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> # As with config/credentials.yml, you never want to store sensitive information, # like your database password, in your source code. If your source code is # ever seen by anyone, they now have access to your database. # # Instead, provide the password or a full connection URL as an environment # variable when you boot the app. For example: # # DATABASE_URL="mysql2://myuser:mypass@localhost/somedatabase" # # If the connection URL is provided in the special DATABASE_URL environment # variable, Rails will automatically merge its configuration values on top of # the values provided in this file. Alternatively, you can specify a connection # URL environment variable explicitly: # # production: # url: <%= ENV['MY_APP_DATABASE_URL'] %> # # Read https://guides.rubyonrails.org/configuring.html#configuring-a-database # for a full overview on how database connection configuration can be specified. # エラー原因 エラー原因は、ローカルのmysqlサーバーホスト名'db'でECS上で設定しているRDSとの連携をしようとしていたことが原因でした。 つまり、ローカルの接続先ホストをRDSのエンドポイントにして連携させてあげる必要がある。 ローカルのホスト名と本番環境のRDSを同じにしてあげないと、RDS上にはない'db'で接続しようとしてしまいデータベースが作成できないエラーが発生してしまうということでした。 解決方法 ローカルの接続先ホストをRDSのエンドポイントに指定してあげることでデータベースの作成ができました。 修正方法 % EDITOR=vim bin/rails credentials:edit でhostを作成してRDSのエンドポイントを指定する #aws: # access_key_id: AKIAU2S6QQYAB4JOXSO6 # secret_access_key: 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 # Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies. secret_key_base: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx db: database: RDSのデータベース名 username: RDSのユーザー名 password: RDSのパスワード socket: xxxxxxxxxxxxxxxxxxxxxxxxx host: ここにRDSのエンドポイントを指定してあげる credential.ymlにエンドポイントを指定すると、ECSで作成するコンテナの環境変数にエンドポイントを設定する必要はなくなる(設定しても可) credential.ymlに必要なエンドポイントを指定したあとは、database.ymlを下記のように編集する database.yml production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> host: <%= Rails.application.credentials.db[:host] %> host: <%= Rails.application.credentials.db[:host] %>を設定する ここまで修正したらECRに設定したリポジトリのlatestを削除後にプッシュを行う。 (Rails側のDockerfileをプッシュ) CircleCIを導入している方は自動デプロイで可能。 タスク定義のリビジョンでコンテナの再定義を行う。再定義後にクラスターのサービス名の設定内のリビジョンを変更した最新のlatestに変更。 ここまで修正したらタスクのログでデータベースが作成できているか確認をしてみる。(おそらくデータベースの作成ができているでしょう。) まとめ 初めてECSに触れたので、デプロイまでの実装でかなりつまずきました。ひとまずデータベースの作成ができたので一安心。 インフラ周りが自分の中で最も難しい分野だと感じているので、知識を増やして正しく構築できるように勉強していこうと思います！

サマリ Alpine × Pythonの問題点については度々指摘されています? Using Alpine can make Python Docker builds 50× slower 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 その原因のほとんどがAlpine同梱のCライブラリ「musl（マッスル）」に由来します ビルド時間が遅延したり、謎のバグを踏んだりします AlpineイメージのPythonを安易に導入した結果、その全ての問題をツモり悲しくなったので共有します? 事象①：異常にビルド時間がかかる? 起きたこと Dockerイメージのビルドにメチャクチャ時間がかかりました。 ビルドのログを眺めていると、ライブラリ1のpip installに30分程時間を要しているのが確認できました? 原因 前述したこちらの記事に答えがありました。 Using Alpine can make Python Docker builds 50× slower Standard PyPI wheels don’t work on Alpine 簡単にまとめると、 PyPIにはライブラリのバイナリがホストされている（なのでpip installで素早くインストール可能） ただしこのバイナリはAlpine非対応のため使えない。Cコードをイチからコンパイルする必要アリ ということです。 ライブラリのバイナリがAlpine（というかmusl）を想定していないため、毎回一生懸命コンパイルし、結果として鬼のようにビルド時間がかかってしまっていたわけです。 こちらの記事にも同様の説明がありました。 PyPIはLinux向けにはmanylinux1という形式でバイナリを提供しており、DebianでもRedHatでも高速にインストールできます。しかし、この形式はAlpineには対応していないため、C拡張を使うライブラリを使うと、Dockerイメージのビルド時間が伸びまくってしますわけです。 それでも、どうしても、PurePythonで処理速度はどうでも良い/お金がたくさんある、あるいはC拡張を使う場合でも人生を犠牲にしてでも、イメージサイズをどうしても減らしたいみたいな選ばれし者はAlpineを使う感じでしょうかね。 事象②：Segmentation Faultが起こる? 起きたこと AlpineイメージのPythonをCloud Runにデプロイし遊んでいたのですが、Uncaught signal: 11なるエラーを吐きCloud Runくんが昇天することが多発しました。 Uncaught signal: 11はSegmentation Faultを表しています。 余談ですが、厄介だったのは、ローカルでは再現しなかったことと、Cloud Run上でも数回に一度しか再現しなかったことです。 原因 muslのスレッドのスタックサイズに問題があったようです。 golang binary hacks ・muslはスレッドに対して極端に少ないスタックを割り当てる （中略） ・Ruby・Python含む様々なプロジェクトがmuslのスタックオーバーフローに辛酸を舐めさせられている スタックオーバーフローはセグフォの一因になり得ますのでこちらの影響を受けた可能性が高いです。 結論 余程のことがない限りPythonならAlpine以外を使用しましょう。 （補足ですが、使い方に依ればAlpineイメージでもPythonは問題なく動きます。全てを否定するわけではありません?‍♂️） grpcio ↩

サマリ Alpine × Pythonの問題点については度々指摘されています? Using Alpine can make Python Docker builds 50× slower 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 その原因のほとんどがAlpine同梱のCライブラリ「musl（マッスル）」に由来します ビルド時間が遅延したり、謎のバグを踏んだりします AlpineイメージのPythonを安易に導入した結果、その全ての問題をツモり悲しくなったので共有します? 事象①：異常にビルド時間がかかる? 起きたこと Dockerイメージのビルドにメチャクチャ時間がかかりました。 ビルドのログを眺めていると、gRPC関連ライブラリ1のpip installに30分程時間を要しているのが確認できました? 原因 前述したこちらの記事に答えがありました。 Using Alpine can make Python Docker builds 50× slower Standard PyPI wheels don’t work on Alpine 簡単にまとめると、 PyPIにはC拡張ライブラリのバイナリがホストされている（なのでpip installで素早くインストール可能） ただしこのバイナリはAlpine非対応のため使えない。Cコードをイチからコンパイルする必要アリ ということです。 通常のライブラリならAlpineでも問題ないですが、C拡張ライブラリの場合は毎回一生懸命コンパイルすることになり、結果として鬼のようにビルド時間がかかってしまっていたわけです。 こちらの記事にも同様の説明がありました。 PyPIはLinux向けにはmanylinux1という形式でバイナリを提供しており、DebianでもRedHatでも高速にインストールできます。しかし、この形式はAlpineには対応していないため、C拡張を使うライブラリを使うと、Dockerイメージのビルド時間が伸びまくってしますわけです。 それでも、どうしても、PurePythonで処理速度はどうでも良い/お金がたくさんある、あるいはC拡張を使う場合でも人生を犠牲にしてでも、イメージサイズをどうしても減らしたいみたいな選ばれし者はAlpineを使う感じでしょうかね。 事象②：Segmentation Faultが起こる? 起きたこと AlpineイメージのPythonをCloud Runにデプロイし遊んでいたのですが、Uncaught signal: 11なるエラーを吐きCloud Runくんが昇天することが多発しました。 Uncaught signal: 11はSegmentation Faultを表しています。 余談ですが、厄介だったのは、ローカルでは再現しなかったことと、Cloud Run上でも数回に一度しか再現しなかったことです。 原因 muslのスレッドのスタックサイズに問題があったようです。 golang binary hacks ・muslはスレッドに対して極端に少ないスタックを割り当てる （中略） ・Ruby・Python含む様々なプロジェクトがmuslのスタックオーバーフローに辛酸を舐めさせられている スタックオーバーフローはセグフォの一因になり得ますのでこちらの影響を受けた可能性が高いです。 結論 余程のことがない限りPythonならAlpine以外を使用しましょう。 （補足ですが、使い方に依ればAlpineイメージでもPythonは問題なく動きます。全てを否定するわけではありません?‍♂️） grpcio ↩

はじめに Wowza Streaming Engine （以下、WSE）で配信している動画からフレームを切り出したい！ というわけで、公式のドキュメントに沿ってやってみました API 経由で切り出せるようなので、意外と簡単にできそうですね 実行環境 macOS Big Sur 11.5 OBS Studio 27.0.1 Docker 20.10.7 Wowza Streaming Engine 4.8.12+1 REST API によるサムネイル取得 ドキュメントによると、設定を変更してから API にアクセスすればサムネイルとしてフレームの画像が取得できるようです 以下のコードを /Library/WowzaStreamingEngine/conf/VHost.xml の Port 8086 の HTTPProviders に追加して再起動します <HTTPProvider> <BaseClass>com.wowza.wms.transcoder.thumbnailer.HTTPProviderGenerateThumbnail</BaseClass> <RequestFilters>thumbnail*</RequestFilters> <AuthenticationMethod>none</AuthenticationMethod> </HTTPProvider> Java　の実装をわざわざしたくないので、公式ドキュメントの一番下に書いてある REST API にアクセスしてみます http://[wowza-ip-address]:8086/thumbnail?application=[application-name]&streamname=[stream-name]&size=[width]x[height]&fitmode=[fitmode]&crop=[left],[right],[top],[bottom]&format=[png,jpg] curl "http://localhost:8086/thumbnail?application=webcam&streamname=myStream&size=1280x720&format=jpeg" 、、、アレ？ 待てど暮らせど何も返ってこない、、、 というわけで、実はトランスコーダー設定が必要でした 公式ドキュメントを参考にセットアップしてみましょう Enable the Transcoder 1. In the Applications contents panel, select your live application, and then click Transcoder. Then in the details page, click Enable Transcoder. メニューから Transcoder をクリックするわけですね、、、 、、、そんな項目ありませんが 別のところを見ると、そもそも macOS 版はトランスコーダーに対応していませんでした Transcoder is supported only on 64-bit versions of Windows and Linux. A 64-bit Java runtime is also required. 32-bit versions of Windows and Linux aren't supported. The macOS operating system isn't supported, either. Docker で WSE というわけで、 Docker の出番です まずは今ローカルで動いているものを停止します sudo launchctl unload -w /Library/LaunchDaemons/com.wowza.WowzaStreamingEngineManager.plist sudo launchctl unload -w /Library/LaunchDaemons/com.wowza.WowzaStreamingEngine.plist 公式ドキュメントに従って、以下のようにコンテナを実行します docker run -it --name wowza \ --restart always \ --expose 1935/tcp \ --expose 8086/tcp \ --expose 8087/tcp \ --expose 8088/tcp \ --publish 1935:1935 \ --publish 8086:8086 \ --publish 8087:8087 \ --publish 8088:8088 \ --volume <ローカルのパス>:/usr/local/WowzaStreamingEngine/logs \ --entrypoint /sbin/entrypoint.sh \ --env WSE_MGR_USER=<ユーザー名> \ --env WSE_MGR_PASS=<パスワード> \ --env WSE_LIC=<ライセンスコード> \ --env WSE_IP_PARAM=127.0.0.1 \ wowzamedia/wowza-streaming-engine-linux 一瞬で立ち上がりました 今まで一生懸命 macOS 版で動かしていた意味は、、、 Docker　上は Linux 版で動いているので、しっかり Transcoder の項目が出ています Enable Transcoder をクリックします そして、ローカルでやったのと同じように VHost.xml を編集します 起動中のコンテナに入ります docker exec -it wowza bas コンテナ内に vim が無かったので入れます apt-get update apt-get install vim そして編集します Linux の場合のパスは /usr/local/WowzaStreamingEngine/conf/VHost.xml です vi /usr/local/WowzaStreamingEngine/conf/VHost.xml 保存後、 Server タブの右上 Restart で WSE を再起動します Incoming Streams を見ると、トランスコーダーのストリームが増えています フレーム取得 この状態で改めて REST API にアクセスしましょう curl "http://localhost:8086/thumbnail?application=webcam&streamname=myStream&size=1280x720&format=jpeg" > myStream.jpg 無事フレーム画像が取得できました！ 右下に Wowza のロゴが透かしで入っているのは、おそらく無料トライアルのライセンスだからです 終わりに 念の為、 Transcoder を無効化してからもう一度再起動してフレーム取得すると、、、 なぜか取得できました macOS ではできなかったのに、、、 とりあえず、 Linux 版では問題なくフレーム取得できそうです やっぱり技術検証するには Docker を使うのが一番ですね

はじめに dockerを触っていたらエラーが出たのでメモとして残しておく 環境 : Linux arch 5.13.5-arch1-1 そんなに調べていないが cgroups V2 だと動かないので kernelのパラメータを変更して cgroups V1 で動かす エラー cgroup がマウントされていません とでる INFO[2021-07-27T08:01:11.299289928Z] Graph migration to content-addressability took 0.00 seconds WARN[2021-07-27T08:01:11.303904114Z] Your kernel does not support cgroup memory limit WARN[2021-07-27T08:01:11.303917683Z] Unable to find cpu cgroup in mounts WARN[2021-07-27T08:01:11.303920199Z] Unable to find blkio cgroup in mounts WARN[2021-07-27T08:01:11.303922149Z] Unable to find cpuset cgroup in mounts WARN[2021-07-27T08:01:11.303940219Z] mountpoint for pids not found Error starting daemon: Devices cgroup isn't mounted 解決 issueのコメント欄にあった方法で解決できた /etc/default/grub に GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0" を追記 grubの更新 $ grub-mkconfig -o /boot/grub/grub.cfg 再起動 $ reboot

LaravelのキューアプリをサクっとDocker化したい、そんな記事です。 前置き Docker化に重きを置きたいので、ジョブ実装などには触れません。 （実装まで触れるともう記事が長いってば！になっちゃう） キューはMySQL、workerのデーモン化はsupervisordを採用します。 バージョン PHP / Laravel: 8系 MySQL: 5.7系 やってみよう さっそくですが、以下がディレクトリ構成です。 project |- docker | |- app // laravelアプリケーションのDockerfile など | |- mysql // docker-entrypoint-initdb.d など | |- supervisord // supervisordのDockerfile など | └ docker-compose.yml └ app // 以下ソースコード ... 各ディクトリ中身について触れていきます。 appディレクトリ app |- Dockerfile └ httpd.conf LaravelアプリケーションのDockerビルド関連のディレクトリです。 今回はapacheを採用、Dockerfileは以下。 centosベースにphpなど必要なものをインストールしていく。 FROM centos:centos7 RUN yum -y update && yum -y install \ https://repo.ius.io/ius-release-el7.rpm \ https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm \ https://rpms.remirepo.net/enterprise/remi-release-7.rpm \ yum-utils \ git \ unzip \ curl \ && yum-config-manager --disable "remi-php*" \ && yum-config-manager --enable remi-php80 \ && yum clean all RUN yum -y install --enablerepo=remi,remi-php80 \ httpd24u \ php \ php-mbstring \ php-mcrypt \ php-pdo \ php-mysqlnd \ php-opcache \ php-process \ php-xml RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer COPY httpd.conf /etc/httpd/conf.d/httpd.conf WORKDIR /var/www/html ENTRYPOINT ["/usr/sbin/httpd", "-D", "FOREGROUND"] mysqlディレクトリ mysql └ docker-entrypoint-initdb.d └ init.sql 初期で作成するテーブル情報などを記載したsqlファイルを用意。 僕の場合、このsqlファイルにキューで使うjobsテーブル、failed_jobsテーブルのCREATE文もまとめています。 （公式ドキュメントでは、php artisan queue:table && php artisan migrate でテーブル生成してくれますので、このコマンドを使うってのも一つかと思いますがなんだかめんどくさそう） supervisordディレクトリ supervisord |- Dockerfile |- job-worker.conf └ supervisord.conf jobを消化するworkerをデーモン化（キューを常に監視）する必要があり、その役割がsupervisordです。 （ちなみに、supervisordはLaravel公式ドキュメントでもデーモン化の一つの手段として言及されています） 「Laravelアプリがjobをキューへプッシュ → workerがキューからjobを取り出す」的な構成の、後者にあたるものがこのコンテナになります。 job-worker.confはworkerの動作設定を記述したファイル、supervisord.confはsupervisord全体の設定ファイルになります。 ここでは特に載せません、必要に応じてググってください。（Laravel公式ドキュメントにもヒントレベルのものなら載っています） ここでのDockerfileは以下になります。 FROM centos:centos7 RUN yum -y update && yum -y install \ https://repo.ius.io/ius-release-el7.rpm \ https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm \ https://rpms.remirepo.net/enterprise/remi-release-7.rpm \ yum-utils \ git \ unzip \ curl \ && yum-config-manager --disable "remi-php*" \ && yum-config-manager --enable remi-php80 \ && yum clean all RUN yum -y install --enablerepo=remi,remi-php80 \ php \ php-mbstring \ php-mcrypt \ php-pdo \ php-mysqlnd \ php-opcache \ php-process \ php-xml RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer RUN yum -y install supervisor RUN mkdir -p /var/log/supervisor COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf COPY job-worker.conf /etc/supervisor/conf.d/job-worker.conf CMD bash -c "/usr/bin/supervisord -c /etc/supervisor/conf.d/supervisord.conf && /bin/bash" 今回はworkerを別コンテナで立ち上げたため、Larabelアプリコンテナと同様にPHPのインストールが必要になります。 docker-compose.yml そして最後ですね。 docker-compose.yml version: '3.8' services: app: build: ./app image: app:latest container_name: app working_dir: /var/www/html ports: - 8000:80 volumes: - /path/to/project-root/:/var/www/html/ supervisord: build: ./supervisord image: supervisord:latest container_name: supervisord tty: true volumes: - /path/to/project-root/:/var/www/html/ depends_on: - app mysql: image: mysql:5.7.32 container_name: mysql environment: MYSQL_ROOT_PASSWORD: root volumes: - ./mysql/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d ports: - 3306:3306 最後に こんな感じでサクッと。 とりあえずローカルでーとかってパターンなら、これで十分かなーと思います。 また気が向けば、別記事でジョブ実装やらsupervisordやらのこと書こうかなーと思います。

Reactのアプリをコンテナ化して、 Development ➡　Productionのワークフローを学んでいる自分の備忘録になります。 Reactのアプリを作る時に必要なコマンド早見表 コマンド 何をするか npm run start developmentのためのサーバーをスタートさせる npm run test プロジェクトに関するテストを実行する npm run build プロダクションバージョンのアプリを構築する ワークフロー developmentのサーバーを立ち上げる Dockerfile.dev　ファイルからイメージをbuildしてコンテナを実行してみた。 ファイルは以下のように書いている コンテナを実行する際に、CMDに書かれているコマンドが実行され無事にサーバーが立ち上がった。 npm run testで上書きして実行する docker run <ImageID> npm run test で先ほどの、CMDのコマンドを上書きして実行する 下のスクショがnpm run testコマンドの実行結果 ただ、これだとターミナルの続きにコマンドを打つことができない docker run -it <ImageID> npm run test なので上記のコマンドのように　-itオプションを付けて実行するとよい ctrl + C でこのテストから抜けることができる またエンターキーを押すと、テストが再度実行される 問題点 上記の方法でtestコマンドを実行することができるが、testファイルに変更が加えられた時、その更新が反映されないという問題点がある。 例えば、App.test.jsのソースコードのtestの部分をコピペして2回のテストをさせるように変更しても、その変更は反映されず、相変わらず、1回だけしかテストが実行されなかった。 なぜならば、Containerのイメージを作る時にはその時点でのファイルシステムのスナップショットが撮られ、その時点のイメージを基にContainerが作られるから では、どのようにしたらtestファイルの更新をイメージをrebuild せずに反映させることができるか？ 解決方法を下記に書いていく 解決方法① docker exec -it <ImageID> npm run test 上記のコマンドを使うことで、既存の実行中のContainerを使いながら、testを実行する事ができる バインドマウントをさせてContainerを実行 上記のように書いたdocker-compose ファイルをupする バインドマウントしたContainerが実行中になる 既にバインドマウントしているContainerにさらにコマンドを実行させるために docker exec -it <ImageID> npm run test を実行する イメージをrebuildしなくても、testファイルの更新が反映されるようになった。 testファイルの更新を即時に反映させることには成功したが、バインドマウントしているContainerを実行して、execコマンドでそのContainerに新たなコマンドを実行させることが少し面倒 ということで、解決方法②により良い解決方法を書いていく 解決方法② 解決方法②は、docker-composeファイルに、新たにtestを実行するだけのアプリをつけ足す方法だ。 これでバインドマウントしたtestを実行するだけのContainerができるので、App.test.jsファイルに変更が加わった時に、即時にその変更がブラウザーに反映される(ただし、Windowsではこの方法は使えない) まとめ 今回の記事では ①developmentのサーバーを立ち上げ ②testを実行する ところまで書いたので、次は ③production用のサーバーを立ち上げる ことについて書いていく

Docker for Desktopをアップデートしたら以下のエラーが $ docker-compose run => Can't separate key from value Docker2をデフォルトで使う設定になってしまっているようなのでチェックを外し設定をオフにします。 ※こちらの記事は自ブログからの転載です