以前自分はMySQL5.7のイメージを使ってdbコンテナを立ち上げて、開発してました。 その時は docker-compose up を実行したら rails sみたいな eb_1 | Started GET "/" for 172.20.0.1 at 2021-06-12 13:36:48 +0000 web_1 | Cannot render console from 172.20.0.1! Allowed networks: 127.0.0.0/127.255.255.255, ::1 web_1 | Processing by DrinksController#index as HTML web_1 | User Load (0.4ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 7 LIMIT 1 web_1 | ↳ app/helpers/sessions_helper.rb:52:in `current_user' web_1 | (0.6ms) SELECT COUNT(*) FROM `drinks` WHERE `drinks`.`user_id` != 6 AND (user_id IN (SELECT followed_id FROM relationships WHERE follower_id = 7) OR user_id = 7) web_1 | ↳ app/controllers/drinks_controller.rb:14:in `index' web_1 | web_1 | From: /coffee_passport/app/controllers/drinks_controller.rb:25 DrinksController#index: こんな感じのログが出てくれました。 ある日、本番環境がMySQL8系なので、 開発環境もMySQL8.0に統一した方がバグもすくなるなると考えて docker-compose.yml version: '3' services: db: image: mysql:8.0.21 cap_add: - SYS_NICE # コンテナにLinux機能を追加するオプションのようです。SYS_NICEは、プロセスの優先度(nice値)をあげます。 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_HOST: db ports: - '3306:3306' volumes: - mysql-data:/var/lib/mysql command: --default-authentication-plugin=mysql_native_password # 認証方式を8系以前のものにする 　このように書き換えて再度ビルドし docker-compose up を実行すると rails sみたいなログが出力されなくなってしまいました。 これはかなり不便なので色々調べると googleの3ページ目に http://hotatekun.hatenablog.com/entry/2021/04/04/224001 こんな感じの記事がありました。 puma.rb # workers ENV.fetch("WEB_CONCURRENCY") { 2 } # Use the `preload_app!` method when specifying a `workers` number. # This directive tells Puma to first boot the application and load code # before forking the application. This takes advantage of Copy On Write # process behavior so workers use less memory. # # preload_app! # Allow puma to be restarted by `rails restart` command. plugin :tmp_restart app_root = File.expand_path("../..", __FILE__) bind "unix://#{app_root}/tmp/sockets/puma.sock" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true どうしてpuma.rbをこのように編集したか覚えてないのですが、 puma.rb # stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true unless ENV.fetch("RAILS_ENV", "development") == "development" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true end # puma.rbで、標準出力が log/puma.stdout.log にリダイレクトされていたのが原因だった。 # 開発環境ではファイルにリダイレクトしない形にしたらコンソールが表示されるようになった。 と変更することで docker-compose up を実行したら ターミナルにrails sみたいなログが出力されるようになりました。 docker-compose up -d が主流？みたいですが皆様は普段どんな感じでログを見てるか気になるところです。 binding.pryで処理は止まって web_1 | 17: .includes(:user)) web_1 | 18: web_1 | 19: @title = 'Timeline' web_1 | 20: web_1 | 21: @selected = 'Selected' web_1 | 22: web_1 | 23: @random_drinks = Drink.order('RAND()').limit(5) web_1 | 24: web_1 | => 25: binding.pry web_1 | 26: web_1 | 27: end このように表示されますが、 こっから何を入力しても反応がないので これからまたどうやってbinding.pryをしようかちゃんと調べて記事にします。

以前自分はMySQL5.7のイメージを使ってdbコンテナを立ち上げて、開発してました。 その時は docker-compose up を実行したら rails sみたいな eb_1 | Started GET "/" for 172.20.0.1 at 2021-06-12 13:36:48 +0000 web_1 | Cannot render console from 172.20.0.1! Allowed networks: 127.0.0.0/127.255.255.255, ::1 web_1 | Processing by DrinksController#index as HTML web_1 | User Load (0.4ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 7 LIMIT 1 web_1 | ↳ app/helpers/sessions_helper.rb:52:in `current_user' web_1 | (0.6ms) SELECT COUNT(*) FROM `drinks` WHERE `drinks`.`user_id` != 6 AND (user_id IN (SELECT followed_id FROM relationships WHERE follower_id = 7) OR user_id = 7) web_1 | ↳ app/controllers/drinks_controller.rb:14:in `index' web_1 | web_1 | From: /coffee_passport/app/controllers/drinks_controller.rb:25 DrinksController#index: こんな感じのログが出てくれました。 ある日、本番環境がMySQL8系なので、 開発環境もMySQL8.0に統一した方がバグもすくなるなると考えて docker-compose.yml version: '3' services: db: image: mysql:8.0.21 cap_add: - SYS_NICE # コンテナにLinux機能を追加するオプションのようです。SYS_NICEは、プロセスの優先度(nice値)をあげます。 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_HOST: db ports: - '3306:3306' volumes: - mysql-data:/var/lib/mysql command: --default-authentication-plugin=mysql_native_password # 認証方式を8系以前のものにする 　このように書き換えて再度ビルドし docker-compose up を実行すると rails sみたいなログが出力されなくなってしまいました。 これはかなり不便なので色々調べると googleの3ページ目に http://hotatekun.hatenablog.com/entry/2021/04/04/224001 こんな感じの記事がありました。 puma.rb # workers ENV.fetch("WEB_CONCURRENCY") { 2 } # Use the `preload_app!` method when specifying a `workers` number. # This directive tells Puma to first boot the application and load code # before forking the application. This takes advantage of Copy On Write # process behavior so workers use less memory. # # preload_app! # Allow puma to be restarted by `rails restart` command. plugin :tmp_restart app_root = File.expand_path("../..", __FILE__) bind "unix://#{app_root}/tmp/sockets/puma.sock" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true どうしてpuma.rbをこのように編集したか覚えてないのですが、 puma.rb # stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true unless ENV.fetch("RAILS_ENV", "development") == "development" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", true end # puma.rbで、標準出力が log/puma.stdout.log にリダイレクトされていたのが原因だった。 # 開発環境ではファイルにリダイレクトしない形にしたらコンソールが表示されるようになった。 と変更することで docker-compose up を実行したら ターミナルにrails sみたいなログが出力されるようになりました。 docker-compose up -d が主流？みたいですが皆様は普段どんな感じでログを見てるか気になるところです。 binding.pryで処理は止まって web_1 | 17: .includes(:user)) web_1 | 18: web_1 | 19: @title = 'Timeline' web_1 | 20: web_1 | 21: @selected = 'Selected' web_1 | 22: web_1 | 23: @random_drinks = Drink.order('RAND()').limit(5) web_1 | 24: web_1 | => 25: binding.pry web_1 | 26: web_1 | 27: end このように表示されますが、 こっから何を入力しても反応がないので これからまたどうやってbinding.pryをしようかちゃんと調べて記事にします。

こんなエラーが出てくる @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is ... 誰かが悪さをしている可能性があります。 誰かが今、あなたを盗み聞きしているかもしれません（中間者攻撃）。 また、ホストの鍵が変更されただけという可能性もあります。 リモートホストから送信された ECDSA 鍵のフィンガープリントは次のとおりです。 -------です。 システム管理者にお問い合わせください。 /Users/akidon/Library/Containers/com.sequel-ace.sequel-ace/Data/.keys/ssh_known_hosts_strictに正しいホストキーを追加すると、このメッセージが表示されなくなります。 とあったので変更 現在の正しいホストキーは .ssh/known_hostsに追加済だと思うので それを /Users/akidon/Library/Containers/com.sequel-ace.sequel-ace/Data/.keys/ssh_known_hosts_strict に追加して完了 このエラーで丸1日間作業が止まりました

RailsのAPIモードでデータベースをMySQLとして作ったアプリを初めてherokuにデプロイする過程でハマったところがあるので、結局何が正しかったのかを記録として書いておこうと思います。初心者なので至らぬ箇所もあるかとは思いますが悪しからず。 環境 ・Windows10 ・Ruby 2.6.6 ・Rails 6.1.3 ・MySQL2 0.5 ・heroku 前提 ・herokuアカウント登録済 ・heroku CLIインストール済（コマンドラインで$ heroku使うため 　インストールはこちらからhttps://devcenter.heroku.com/ja/articles/heroku-cli） ・herokuクレジットカード登録済み（clearDB使うため。無料です） デプロイするソースをコミット #デプロイするアプリのディレクトリに移動し $ cd ~ #初期化 $ git init #ディレクトリ以下のファイルを選択し $ git add --all #コミットする $ git commit -m "first commit" herokuにログインし、新規app作成 下記コマンドでブラウザからログインします $ heroku login デプロイするアプリのディレクトリでapp作成します。 $ heroku app:create <appの名前> これによりアプリの公開URLがhttps://(appの名前).herokuapp.comとなります。 ちなみにアンダーバーが使えないようです。 リモートリポジトリの確認 $ git remote -v リモートリポジトリ　heroku https://git.heroku.com/(appの名前).git が作成されていることを確認します。 先にgit initでローカルリポジトリを作成してからheroku createしたので、リモートリポジトリは自動で追加されるようです。 DBの設定 herokuのDBはデフォルトでPostgreSQLに設定されているようで、MySQLを使う場合手動で設定する必要があるようです。 下記コマンドで作成 $ heroku addons:create cleardb:ignite cleardb:igniteはignite(無料プラン)でherokuでMySQLが使えるcleardbを利用するという意味です。ただ、これを利用するためには無料ではあるけれど本人確認のためにクレジットカードをherokuに登録する必要があります。https://heroku.com/verifyから登録できます。英語で住所登録するのが慣れないため面倒でした。 ※このサービスが住所変換に便利でした。http://judress.tsukuenoue.com/ DBの環境設定 cleardbのURLを確認します。 $ heroku config 次のようなものが確認できます。 CLEARDB_DATABASE_URL: mysql://<ユーザー名>:<パスワード>@<ホスト名>/<データベース名>?reconnect=true このURLの情報を参考に各変数を設定します。 $ heroku config:add DB_NAME='<データベース名>' $ heroku config:add DB_USERNAME='<ユーザー名>' $ heroku config:add DB_PASSWORD='<パスワード>' $ heroku config:add DB_HOSTNAME='<ホスト名>' $ heroku config:add DB_PORT='3306' $ heroku config:add DATABASE_URL='mysql2://<ユーザー名>:<パスワード>@<ホスト名>/<データベース名>?reconnect=true' ここで、最後の行の部分でDATABASE_URL='mysql2://~'のようにmysql2となっていることに注意して下さい。MySQL2を使用しているのであれば2を入れるのを忘れずに。 次にapp/config/database.ymlを修正します。 database.yml production: <<: *default database: <データベース名> #変更 username: <ユーザー名> #変更 password: <%= ENV['APP_DATABASE_PASSWORD'] %> cleardbのURLで確認したやつですね。 変更をコミットしておきます。 $ git add -all $ git commit -m "update" herokuにデプロイ リポジトリをherokuにpushします。 $ git push heroku master マイグレーション $ heroku rake db:migrate 問題がなければ次のコマンドでhttps://(appの名前).herokuaopp.comにアクセスできます。 $ heroku open 補足 自分はDATABASE_URL=のところでmysql2ではなくmysqlになっていたので詰まってしまったのですが、デプロイできない原因を調べている中でapplication.rbやproduction.rbファイルでassets関連の修正を加えることで改善するという記事を多く見かけました。何も考えずにこの辺をいじってしまったことでさらにハマってしまうという結果となりました。 結果的には、RailsのAPIモードで作成したアプリであればassets周りは触らなくていいことが分かりました。データを返すAPIとしての機能だけならassetsは必要ないというのは納得できますね。

はじめに この記事ではデータベースの読み込み時に起こる3つの現象、ダーティリード、ノンリピータブルリード、ファントムリードについて実演することで理解を深めていこうと思います。 この記事の対象者 データベースを使った開発を行っている人 データベーススペシャリストの資格を目指している人 実演環境 $ mysql --version mysql Ver 15.1 Distrib 10.5.4-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 実演用のテーブルおよびデータ MariaDB [sample]> desc users; +-------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+-------+ | id | int(11) | NO | PRI | NULL | | | name | varchar(40) | YES | | NULL | | +-------+-------------+------+-----+---------+-------+ MariaDB [sample]> select * from users; +----+------+ | id | name | +----+------+ | 1 | Adam | +----+------+ ダーティリード 説明 あるトランザクションがコミットされていない状態でも、別のトランザクションから変更内容を読み込めてしまう現象のことです。 実演 以下、ダーティリードを起こすために、トランザクションBのトランザクション分離レベルをREAD-UNCOMMITTEDに設定しています。 set session transaction isolation level read uncommitted; Transaction B > select @@tx_isolation; +------------------+ | @@tx_isolation | +------------------+ | READ-UNCOMMITTED | +------------------+ トランザクションAを開始する トランザクションBを開始する トランザクションAにてusersテーブルを更新する トランザクションBにてusersテーブルを確認する まだ、トランザクションAはコミットしていませんが、更新したデータをトランザクションBから読み込めてしまっています。 ノンリピータブルリード 説明 あるトランザクションが2回同じデータを読み込む際に、1回目の読み込みと2回目の読み込みで値が異なってしまう現象のことです。 実演 以下、ノンリピータブルリードを起こすために、トランザクションBのトランザクション分離レベルをREAD-COMMITTEDに設定しています。 set session transaction isolation level read committed; Transaction B > select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+ トランザクションAを開始する トランザクションBを開始する トランザクションBにてusersテーブルを確認する トランザクションAにてusersテーブルを更新する トランザクションAをコミットする トランザクションBにて再度usersテーブルを確認する トランザクションBにて1回目の読み込み(手順3)と2回目の読み込み(手順6)の内容が異なってしまっています。 ファントムリード 説明 あるトランザクションが2回同じデータを読み込む際に、2回目の読み込みで1回目には存在しなかったデータが読み込めてしまう現象のことです。 実演 以下、ファントムリードを起こすために、トランザクションBのトランザクション分離レベルをREAD-COMMITTEDに設定しています。 （詳しくは調べていませんが、MySQL(InnoDB)だとREPEATABLE-READではファントムリードが起きないようですので、READ-COMMITTEDで確認します。） set session transaction isolation level read committed; Transaction B > select @@tx_isolation; +----------------+ | @@tx_isolation | +----------------+ | READ-COMMITTED | +----------------+ トランザクションAを開始する トランザクションBを開始する トランザクションBにてusersテーブルを確認する トランザクションAにてusersテーブルにレコードを追加する トランザクションAをコミットする トランザクションBにて再度usersテーブルを確認する トランザクションBにて1回目の読み込み(手順3)には存在しなかったレコードが2回目の読み込み(手順6)で読み込めてしまっています。 トランザクション分離レベルごとでの現象確認 以上、3つの現象について実演してきたわけですが、これらの現象のどれが起きるかはトランザクション分離レベルによって決まります。 ただし、MySQL(InnoDB)の場合、REPEATABLE-READでのファントムリードは起きないなど、データベースによって異なる場合もあるようですので、注意が必要です。 分離レベル ダーティリード ノンリピータブルリード ファントムリード READ-UNCOMMITTED ○ ○ ○ READ-COMMITTED - ○ ○ REPEATABLE-READ - - ○ SERIALIZABLE - - - まとめ この記事ではダーティリード、ノンリピータブルリード、ファントムリードを実演することで、それらの現象の理解を深めました。 私の経験上、業務の中でこれらの現象を意識して作業したということはほぼなかったと思いますが、データベースを使った開発を行う以上、トランザクション分離レベルによってはこういった現象が起きるということだけでも知っておくことは重要かと思います。 それではまた。 TomoProg

はじめに アプリケーションをローカルで作成し、mixhostにデプロイしたので、その時の備忘録です。 操作 mixhostのコントロールパネルから操作します。 MySQLデータベースをクリック 新しいデータベースを作成します。 新しいユーザーを追加します。 ユーザーをデータベースに追加します。 ユーザー権限は細かく設定できます。 ここからはLaravelの設定です。 .env DB_CONNECTION=mysql DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=XXXXX_test //作成したデータベース名 DB_USERNAME=XXXXX_user01 //作成したユーザー名 DB_PASSWORD=******** //ユーザー作成の時に設定したパスワード 以上で完了です。

今回は開発環境において、Dockerを用いてRails6の環境構築をする方法をご紹介いたします。 それぞれのファイルや単語の意味などの解説はしていないので、詳しい解説は Dockerを用いてRuby on Railsの環境構築をする方法( Docker初学者向け ) をご覧ください。 （ ※ Rails5の環境構築方法になります） 環境 MacOS Docker 20.10.6 docker-compose 1.29.1 Ruby 3.0.1 Rails 6.1.0 MySQL 5.7 前提 DockerおよびDocker composeのインストールを済ませてください これ以降の説明のmyappの部分はご自身のアプリケーション名に変えてください アプリケーションの作業ディレクトリを作成 mkdirで作業ディレクトリを作成します。 $ mkdir myapp 必要なファイルを用意 ファイル構成は以下のようになります。 myapp |-- Dockerfile |-- docker-compose.yml |-- Gemfile |-- Gemfile.lock それでは、先ほど作成したディレクトリの中に以下の各ファイルを作成していきます。 ① Gemfile Gemfile source 'https://rubygems.org' gem 'rails', '>= 6.1.0' ② Gemfile.lock Gemfile.lock Gemfile.lockの中身は空でOKです。 ③ Dockerfile Dockerfile FROM ruby:3.0.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 # yarnをインストールするための準備 RUN apt-get update -qq && \ apt-get install -y build-essential \ libpq-dev \ nodejs \ default-mysql-client \ yarn \ # yarnをインストール vim RUN mkdir /myapp WORKDIR /myapp COPY Gemfile /myapp/Gemfile COPY Gemfile.lock /myapp/Gemfile.lock RUN bundle install COPY . /myapp Rails6でwebpackerが搭載され、yarnのインストールが必要になりました。 ④ docker-compose.yml docker-compose.yml version: '3' services: db: image: mysql:5.7 environment: MYSQL_USER: user MYSQL_ROOT_PASSWORD: pass ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/myapp ports: - 3000:3000 depends_on: - db volumes: mysql_data: rails new を実行 $ docker-compose run web rails new . --force --database=mysql アプリケーションの作業ディレクリに移動し、上記のdocker-compose runコマンドでrails newを実行します。 （　Rails5の時は--skip-bundleのオプションをつけて、bundle installをスキップしていましたが、今回はwebpackerのインストールをしなければならないためbundle installはスキップしません。　） docker-compose build を実行 $ docker-compose build rails new で Gemfileが更新されたので、bundle installするため、docker-compose buildを実行します。 database.yml を編集 /config/database.yml # MySQL. Versions 5.1.10 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: pass host: db development: <<: *default database: myapp_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: myapp_test # As with config/secrets.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 as a unix environment variable when you boot # the app. Read http://guides.rubyonrails.org/configuring.html#configuring-a-database # for a full rundown on how to provide these environment variables in a # production deployment. # # On Heroku and other platform providers, you may have a full connection URL # available as an environment variable. For example: # # DATABASE_URL="mysql2://myuser:mypass@localhost/somedatabase" # # You can use this database configuration with: # # production: # url: <%= ENV['DATABASE_URL'] %> # production: <<: *default database: myapp_production username: myapp password: <%= ENV['MYAPP_DATABASE_PASSWORD'] %> password: と host:を編集します。 password: には docker-compose.yml の MYSQL_ROOT_PASSWORD:に書いたパスワードを記載します。 host: には dbと記載します。 docker-compose up -d でコンテナを起動 $ docker-compose up -d データベースを作成 以下のコマンドでデータベースを作成します。 $ docker-compose exec web rails db:create localhost:3000にアクセス localhost:3000にアクセスし、以下のページが表示されれば DockerによるRails6の環境構築 は完了です。 その後の開発の仕方は こちら を参考にしてください。 参考 Dockerを使ってRails6環境の構築をしてみる

環境 CakePHP4.2.6 (Cakephp3でも確認済み) PHP7.4.16 MAMP はじめに MAMP で CakePHP を動かしていたら migration コマンドでエラーを吐いて詰まった。 調べてもなかなか該当するものがなかったので投稿。 目次 1.mamp下でbakeコマンドが使えない？ 2.悪いのはmampのソケットの場所だった 3.参考文献 1. mamp下でbakeコマンドが使えない いつも通りbin/cake migrations migrateとコマンドを叩いたところ以下のようなエラーを吐いて動かない。 Exception: There was a problem connecting to the database: SQLSTATE[HY000] [2002] No such file or directory In [/Applications/MAMP/htdocs/hogehoge/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php, line 96] 2021-06-11 23:56:11 Error: [InvalidArgumentException] There was a problem connecting to the database: SQLSTATE[HY000] [2002] No such file or directory in /Applications/MAMP/htdocs/hogehoge/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php on line 96 Stack Trace: - /Applications/MAMP/htdocs/hogehoge/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/MysqlAdapter.php:140 /*省略*/ Caused by: [PDOException] SQLSTATE[HY000] [2002] No such file or directory in /Applications/MAMP/htdocs/hogehoge/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php on line 84 Stack Trace: - /Applications/MAMP/htdocs/hogehoge/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:84 /*省略*/ エラー文を調べたところconfig/app.php の設定値 'host' => 'localhost' を 'host' => '127.0.0.1' にしろと書いてあるので試してみるが治らず・・・。 色々調べてるうちに以下の結論に辿り着いた。 2. 悪いのはMAMPのソケットの場所だった シンボリックリンクを貼ってみて再び試してみるといけた！ $ ln -s /Applications/MAMP/tmp/mysql/mysql.sock /tmp/mysql.sock 3. 参考文献 CakePHPでマイグレーションを実行したら、DBに繋がらない Macでcakephp3 の環境構築 bakeコマンドでエラー(php.iniと、MAMPのMySQLのソケットの場所が原因でした。)