ポンコツ.log

ひよっこエンジニアのちょっとしたメモ。主に備忘録。たまに雑記。

builderscon2018参加して来たメモ

公開したと思っていたらずっと下書きでした。

builderscon.io 去年は行けなかったbuilderscon、今年はなんとか参加することができました。

ガチャ負荷やば…こわ…と怯えてみたり、
IEぐぬぬ、Edgeぐぬぬ、という気持ちになったり、
セッションに触発されてパフォーマンス計測したくなったり、
ビジネスサイドの巻き込みと決断すご…と思ってみたり、
テーマが「知らなかった、を聞く」だったので、もっと冒険したセッション選びをすれば良かったなとちょっとだけ後悔しています。
あとで動画で追おう。

改めてこういうイベント好きだなー、と思いました。
最後のLTまでずっと楽しかったです。
行って良かったー。

ぼやき

結構、満員御礼で入れないセッションが多くて、しょんぼりしてたりしました。
聞きたいセッションの被りも多く、これまたしょんぼりしてました。
戦略でも立てておけば良かったんですかね…。

以下、自分のメモがてらセッションの関連リンクをズラーっと並べているだけなので折ります。

続きを読む

【Docker】Rails環境の構成をテンプレート化してみた

DockerでRailsの環境を作ろうとした時に、毎度構成に悩みます。

Railsプロジェクトの中に入れるのも、
- 本番をDockerで動かしていない時は不要なファイルになる
- Docker環境を捨てる時が来たらパッと捨てられるように分離したい

という気持ちがあるので、「どうしたもんかなぁ🤔」と構成を変えたりしていたのですが、毎度作り直したりも面倒なので、今のところしっくり来ている構成をテンプレートにしてみました。

docker-dir
├ .git  
├ mysql  
│ ├ configs
│ │ └ docker-entrypoint-initdb.d  
│ │   └ 01_init.sh
│ └ data
│   └ .gitkeep
├ rails  
│ ├ data
│ │ └ .gitkeep
│ ├ project
│ │ └ .gitkeep
│ └ Dockerfile
├ .env  
├ .gitignore
├ docker-compose.yml 
└ README.md

GitHub - s-mori/rails_docker_template

サービス毎にディレクトリを作って(テンプレートの場合だと、mysqlrails)、Dockerfileやプロジェクトディレクトリなどのそのサービスに関わるものは、それぞれサービスのディレクトリに中に格納するようにしています。
プロジェクトは docker-dir > rails > project の中で git clone git@github.com:hoge/piyo.git .

DBのユーザ、パスは .env ファイルの中で定義して、開発環境だけで使う想定なので、そのままgit管理。
doc: Environment variables in Compose > The “.env” file

今のところ特に問題も起きていないし、不都合も特にないものの、これがベストかと言われると🤔なところ。
いろんな「これが良さげ!」を見てみたいこの頃です。

【gulp】heroku環境のgulp-webserverでbasic認証を設定する

gulp入門2日目です。

デザイナーさんからいただいたgulpプロジェクトのページを誰でも確認できるように、herokuへアップしました。
basic認証を設定したかったのですが、思った以上に(gulp触りたてというのもあるかもしれない…)はまったので、備忘録として。

gulp-webserver

gulp-webserverをインストールします。

$ npm -i --save 

gulp/tasks/webserver.jsを作成し、サーバ起動時のhost、portの設定を記述します。
herokuの場合、ポートが異なるためにアクセスできない状況になりやすいので、process.env.PORTでherokuのポートを取得します。

'use strict';

const gulp = require('gulp');
const webserver = require('gulp-webserver');

gulp.task('webserver', () => {
  gulp.src('dev')
    .pipe(webserver({
      // livereload: true, livereloadを使うときは有効にする
      host: process.env.HOST || 'localhost',
      port: process.env.PORT || 8000
    }))
});

$ npm run start
でサーバを起動できるように、"start": "gulp webserver"package.jsonscriptsに追加します。

{
  "scripts": {
    "start": "gulp webserver",
    "build": "gulp build"
  }
}

basic-auth

basic-authを利用して、gulp-webservermiddlewarebasic認証を実装します。
まずはインストール。

$ npm -i --save basic-auth

middlewareの認証部分を追加した、webserver.jsの全体像はこちら。

heroku

basic認証のユーザ、パスはherokuの環境変数に設定します。

$ heroku config:set USER=user_name PASS=pass

また、devに保存したモジュールをインストールするための変数、web-serverのHOSTをherokuに追加します。

$ heroku config:set NPM_CONFIG_PRODUCTION=false
$ heroku config:set HOST=0.0.0.0

herokuでは、deploy -> npm install -> postinstall -> start の流れになるようなので、postinstallでbuildができるようにします。 package.json

{
  "scripts": {
    "postinstall": "gulp build",
    "start": "gulp webserver",
    "build": "gulp build"
  }
}

あとはherokuにプッシュして、見守ります。

余談

久々にherokuを見たのですが、以前はあった制限がなくなっていたりと、簡単なサービスなら十分herokuでも行けるのでは…?と思ったりしました。
実際に稼働しているサービスもありますし。

あとgulp。
最近webpackも触ったりしていたのですが、gulpも楽じゃーんと思ったりして、いまいちこのあたりの違いがまだ見えていなかったりします。
も少しフロントエンドの話題にもついていけるようにしたいなぁと思う今日この頃です。

今回のbasic認証、アクセスの度にURLが一瞬ちらついてしまうのがきになるところですね…もう少し調査が必要そうです…。

参考:

Herokuでgulpのwebserverをそのまま使う
Heroku上でもgulp-webserverを使う
Herokuでgulpのwebserverをそのまま使う
How to use middleware? · Issue #78 · schickling/gulp-webserver · GitHub

【CentOS】CentOS6.9にCloudWatchモニタリングスクリプトを入れて監視する

CloudWatchのメトリクスで取れそうで取れないものがディスク容量やメモリ使用量ですが、さすがAWSさん。
公式でプラグインスクリプトを用意してくれています。ありがたい。
Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング - Amazon Elastic Compute Cloud

このプラグインの導入、CentOS7だとさっくりできたのに、CentOS6.9だと無駄にウロウロしたので、備忘録としておいておきます。

先に結論

フラフラしたので結論だけ書くと、CloudWatchClient.pmの26行目を書き換えました。

use LWP 6;
↓
use LWP;

なんか思わぬところでハマるんじゃ無いかという恐れもありますが、今の所動いています。

IAMの作成

モニタリングスクリプトを実行するIAMユーザが必要になるので、先に作っておきます。
IAM > ユーザー > ユーザーを追加 から、下記4つの権限を持ったユーザを作成します。
アクセスキー、シークレットアクセスキーが必要になるので、アクセスの種類では「プログラムによるアクセス」を有効にします。

  • cloudwatch:PutMetricData
  • cloudwatch:GetMetricStatistics
  • cloudwatch:ListMetrics
  • ec2:DescribeTags

完了したら、認証ファイルをダウンロードしてスクリプトのインストールに進みます。
余談ですけど、IAMの権限の設定すごく楽になりましたよね。

インストール

Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング - Amazon Elastic Compute Cloudの内容に沿って、必要なライブラリをインストールします。

$ sudo yum install perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https zip unzip -y

Perlが入っていない場合、追加でPerlのインストールも必要です。

$ sudo yum -y install perl-CPAN gcc perl-libwww-perl libyaml-devel openssl-devel

CPANを実行して、必要なモジュールをインストールします。

$ sudo cpan
cpan[1]> install YAML 
cpan[1]> install LWP::Protocol::https 
cpan[1]> install Sys::Syslog 
cpan[1]> install Switch 

インストールが終わったら、プラグイン本体をダウンロード、展開します。

$ curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
$ unzip CloudWatchMonitoringScripts-1.2.2.zip

認証情報のテンプレートファイルをコピーして、中に作成しておいたIAMのアクセスキー等を設定します。

$ cd aws-scripts-mon
$ cp awscreds.template awscreds.conf
$ vi awscreds.conf
AWSAccessKeyId=ACCESS_KEY_ID
AWSSecretKey=SECRET_ACCESS_KEY

これでインストールは完了したので、mon-put-instance-data.plを実行して動作をみます。
--disk-space-utilオプションでディスク使用量の確認、--verifyオプションでテスト実行します。

$ ./mon-put-instance-data.pl --disk-space-util --disk-path=/ --verify --verbose --aws-credential-file=/home/centos/cloudwatch_plugins/aws-scripts-mon/awscreds.conf
LWP version 6 required--this is only version 5.833 at CloudWatchClient.pm line 26.
BEGIN failed--compilation aborted at CloudWatchClient.pm line 26.
Compilation failed in require at ./mon-put-instance-data.pl line 86.
BEGIN failed--compilation aborted at ./mon-put-instance-data.pl line 86.

はい。

LWPのバージョンをあげようとしてみる

どうやらバージョンが関わっていそうなので、アップグレードで解決?と考え始めます。

# LWPのバージョン確認
$ perl -MLWP -le "print(LWP->VERSION)"
5.833
# アップグレードできるもの確認
$ perl -MCPAN -e "CPAN::Shell->r"
Package namespace         installed    latest  in CPAN file
LWP                           5.833      6.34  ETHER/libwww-perl-6.34.tar.gz

latestは6.34。
libwww-perl-6.34.tar.gzを手に入れる必要がある?と考え、インストールチャレンジします。

$ sudo perl -MCPAN -e "CPAN::Shell->install('ETHER/libwww-perl-6.34.tar.gz')"
Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
  ETHER/libwww-perl-6.34.tar.gz
  /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
Running make test
  Make had some problems, won't test
Running make install
  Make had some problems, won't install

できません。

スクリプトを書き換える

ふと冷静になります。
「LWP version 6 required」ということは、スクリプト内でバージョンの指定されているところか何かしらがあるのでは?

ここで冒頭に戻るわけですが、そのままだとCloudWatchClient.pmへの書き込み権限が無いようなので、先に権限を変更します。

$ ls -la
-r--r--r-- 1 centos centos 22519 2018-03-26 12:47 CloudWatchClient.pm
$ chmod 644 CloudWatchClient.pm
$ ls -la
-rw-r--r-- 1 centos centos 22519 2018-03-26 12:47 CloudWatchClient.pm

これで変更できるようになるので、冒頭に書いた通り、26行目にあるuse LWP 6;use LWP;に変更します。

変更したら、先ほど実行したmon-put-instance-data.plを再び実行します。

$ ./mon-put-instance-data.pl --disk-space-util --disk-path=/ --verify --verbose --aws-credential-file=/home/centos/cloudwatch_plugins/aws-scripts-mon/awscreds.conf
DiskSpaceUtilization [/]: 52.6020399623083 (Percent)
Using AWS credentials file </home/centos/cloudwatch_plugins/aws-scripts-mon/awscreds.conf>
Endpoint: https://monitoring.ap-northeast-1.amazonaws.com
Payload: {"MetricData":[{"Timestamp":1529401137,"Dimensions":[{"Value":"/dev/xvda1","Name":"Filesystem"},{"Value":"i-021839685456c0737","Name":"InstanceId"},{"Value":"/","Name":"MountPath"}],"Value":52.6020399623083,"Unit":"Percent","MetricName":"DiskSpaceUtilization"}],"Namespace":"System/Linux","__type":"com.amazonaws.cloudwatch.v2010_08_01#PutMetricDataInput"}

Verification completed successfully. No actual metrics sent to CloudWatch.

通った!\\ ٩( 'ω' )و //

参考

【Rails】Rails5+Pumaでlogrotate

放っておくといつの間にか容量が膨れ上がっているログファイル。
ふと気づくとディスク容量があっぷあっぷしている、なんてこともあるので、静かな侵略者と勝手に思っています。
rotateの設定をしていないのが悪いんですけどね。

Linuxのlogrotateを使ってもできるのですが、Puma+logrotate+Capistranoだとログ周りがうまく動かないという記事を見たので、RailsのLoggerでrotateする方法にしてみました。

Loggerの設定

config/environments/production.rbconfig/environments/development.rbなどの各環境で設定します。

Rails.application.configure do
  # 日別にrotateされるように設定
  logger = ActiveSupport::Logger.new('log/production.log', 'daily')
  logger.formatter = config.log_formatter

  if ENV["RAILS_LOG_TO_STDOUT"].present?
    # 'log/production.log'以外(ex. 標準出力)にログ出力先を追加する場合
    stdout_logger           = ActiveSupport::Logger.new(STDOUT)
    stdout_logger.formatter = config.log_formatter
    multiple_loggers = ActiveSupport::Logger.broadcast(stdout_logger)
    logger.extend(multiple_loggers)
  end
  config.logger = ActiveSupport::TaggedLogging.new(logger)
end

日別にしたかったので

ActiveSupport::Logger.new('log/production.log', 'daily')

としていますが、dailyの部分をmonthlyにすると月別、weeklyにすると週別でのrotateになります。
また、

ActiveSupport::Logger.new('log/production.log', 5, 10 * 1024 * 1024)

のようにすると、10Mbずつ、5ファイル分保持します。

ファイルサイズで分割した時は指定したファイル数(ex. 5)を越えると自動で削除してくれますが、期間で分割した時は削除されないので、延々と過去ログが溜まっていきます。
このまま放っておいても、またサーバを圧迫してしまうので、削除バッチを作ってcron実行するようにします。

古いログファイル削除バッチの作成

namespace :log_rotate do
  desc "rotateされたログファイルのうち、1週間前のファイルを削除する"

  task :destroy_old_file => :environment do
    # 対象のファイルを取得
    log_files = Dir.glob(Rails.root.join("log/#{Rails.env}.log*"))

    log_files.each do |file|
      # 1週間前の日付
      last_week_date = Time.zone.today.weeks_ago(1)
      # ファイルの更新日を取得
      file_modified_date = File.mtime(file).in_time_zone.to_date
      # 更新日が1週間前のファイルは削除
      if file_modified_date < last_week_date
        FileUtils.rm file
      end
    end
  end
end

コードの通りですね。
ログ出力対象(log/env.log)のファイルの File.mtimeを使って対象ログファイルの最終更新日時を取得します。

取得した最終更新日時と一週間前の日時を比較して、古いものはFileUtils.rmで削除します。

あとはwhenever等でCronに登録しておきます。

puma起動

設定が終わったら、pumaコマンド(or pumactl)で起動します。

$ bundle exec puma -C config/puma.rb -e production -d

rails s でもpumaは起動しますが、この場合はlogrotateの設定が上手く反映されず、1ファイルに出力され続けるようです。
この辺りはもっとちゃんと調査したいところ…。

【CSS】user-selectでテキスト選択を制御

ひょんな事から、user-selectなるプロパティを知りました。
選択動作を制御するもので、選択できる範囲を制限したり、選択できなくさせるものだそうです。

ブラウザによって挙動が異なるので、ベンダープレフィックスが必要。
指定できる値は

  • none
    テキストを選択できなくする
  • auto
    ブラウザのデフォルトに従う
  • text
    ユーザが選択できるようにする。選択範囲の制限は無し。
  • all
    クリックで全選択状態にする
  • contain
  • element
    ユーザが選択できるようにする。選択範囲の制限あり。IEでのみ有効。

user-select - CSS: カスケーディングスタイルシート | MDN
user-selectで要素のテキスト選択を「させる」

遭遇した現象

SemanticUIのメニューとポップアップを併用した際、ポップアップで表示した部分が選択できない状況に遭遇しました。
例えばこんなメニュー&ポップアップ

See the Pen SemanticUI - menu and popup by s-mori (@s-mori) on CodePen.

Ruby on Rails」をクリックでポップアップを表示するようにしています。

何もせずに表示させると、ポップアップ内のテキストを選択しようとしてもできません。
要素を無効にしながら調べると、どうやらデフォルトで.ui.menu .itemuser-select: none;がついているようでした。

ポップアップ内のテキストは選択可能にしたかったので、ポップアップに対して

user-select: text;
-moz-user-select: text; // for firefox
-webkit-user-select: text; // for safari
-ms-user-select: text; // for Edge,IE

をつけて対応。各ブラウザで効くようにします。

余談

MDNによると

これは実験段階の機能です。 この機能は複数のブラウザーで開発中の状態にあります。互換性テーブルをチェックしてください。また、実験段階の機能の構文と挙動は、仕様変更に伴い各ブラウザーの将来のバージョンで変更になる可能性があることに注意してください。 https://developer.mozilla.org/ja/docs/Web/CSS/user-select

とのこと。

【jQuery】animateでアコーディオン

フロントは苦手です。

アコーディオンの実装ならslideToggle
となるのですが、一部だけ残して下の部分が展開するタイプのアコーディオン(そもそもアコーディオンと言うのかも怪しい…)を実装しようとすると、 slideToggle だと「一部を残す」ができなかったので、animateアコーディオンっぽい動きを作りました。

See the Pen accordion by s-mori (@s-mori) on CodePen.

slideToggle([speed], [callback]) - jQuery 日本語リファレンス
animate(params, options) - jQuery 日本語リファレンス

scrollHeightで展開時の高さを指定

resizeHeight = target.get(0).scrollHeight
target.animate({"height": resizeHeight})

scrollHeightoverflow 部分を含めた高さを取得し、その値を height で指定しています。
target.animate({"height": "100%"}) としても展開はされるのですが、この場合 animate が効かなくなります。

.scrollHeight | JavaScript 日本語リファレンス | js STUDIO

data属性を利用して元の高さに畳む

target.attr('data-org-height', target.innerHeight())

展開する前に、元の高さを取得して、 data属性を利用して保持させます。

orgHeight = target.attr('data-org-height');
target.animate({"height": orgHeight});

畳む時は、 data属性として持たせていた高さを取得し、 animate に渡します。
元の高さ(上記penの場合だと60px)を指定しても問題はないのですが、SP等で高さが変わるときにブラウザ判定を入れたくなかったので、悩んだ挙句、data属性を利用しています。

data便利ですぐ使ってしまう…。

slideToggleでできる方法もあるのかもしれない…)

【shell】今年はfish、キミに決めた

1月に1本でも上げようと思っていたらもう2月でした。
今年は更新頑張ろうと思いながら、すでに雲行きが怪しいです。

私事ですが転職をしまして、今年から新たなところでお世話になっています。
当然仕事に使うPCも代わり、まっさらな状態に戻ったので、ゴリゴリ環境を整えていたわけですが、「シェルどうしようかなぁ…」と迷っていました。

過去2回、元同期にオススメされたpreztoを導入してきたのですが、頭が足りないということもあって、どうにもすんなりいかない。
エディタが永遠にnanoになるという呪いにかかり、1から入れ直しということも経験してきました。
そんなこともあってか若干のprezto恐怖症を抱えていたので、潔く他のものにしてみようと思い立ち、良さげと聞いたfishを導入しました。

fishshell.com

fish導入

fish インストール

fishサイトの「Go fish」のところにインストール方法があります。
MacではHomebrewが使えるようなので、サクッとbrew installします。

$ brew install fish
$ fish -v
fish, version 2.7.1

fishをデフォルトに変更

インストールは無事完了したので、デフォルトのシェルをfishに変更します。
/etc/shellsにシェルの一覧が記述されているので、その中にfishのフルパスを追記します。

$ sudo vi /etc/shells
# /usr/local/bin/fish 追加

fishが利用できるようになったので、chshコマンドでデフォルトをfishに変更します。

$ chsh -s /usr/local/bin/fish
Changing shell for USERNAME.
Password for USERNAME:

終わりました。はやい \\٩('ω')و//

fishermanインストール

github.com ついでにプラグインマネージャの「fisherman」なるものも入れます。
他のプラグインマネージャの比較はこちらが参考になります。
fishのプラグインマネージャ比較 - Qiita

fishermanリポジトリにあるInstallの通り進めます。

$ curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs https://git.io/fisher

# 一度ターミナルを再起動
$ fisher -v
fisherman version 2.13.2 ~/.config/fish/functions/fisher.fish

はやい \\٩('ω')و//

fisherコマンド

プラグインをインストールするときは

$ fisher plugin

インストール済みプラグイン一覧を見るときは

$ fisher ls

プラグインを更新するときは

$ fisher up [plugin]

インストールしたプラグインを削除するときは

$ fisher rm [plugin]

という感じで使えるようです。

テーマ

テーマってなんだか見るだけでも楽しいんですよね。
今回はoh-my-fishの中にあるテーマから選びました。

「どれにしようかなー」と各テーマを眺めていると、見覚えのあるアイツがいました。
水属性の2まいがいポ●モン。

サ●シの気持ちになって「キミに決めた!」の勢いでshellderを入れます。
github.com

ちゃんと勢い以外でも選んでます。

テーマインストール

fishermanのおかげで、テーマの導入もぱぱっとできます。

# shellderインストール
$ fisher simnalamburt/shellder

フォントインストール&変更

f:id:mr_96:20180205171731p:plain このままでは豆腐フォントのままなので、フォントを入れて、ターミナルの設定を変更します。

フォントのインストールは、shellder#Fontsにあるフォント2種類を入れます。
一つはpowerline
こちらはgitから。

$ mkdir plugins
$ git clone git@github.com:powerline/fonts.git
$ cd fonts
$ ./install.sh

もう一つはnerd-fonts。 こちらはいくつかインストール方法があるようですが、サクッとbrewで入れてしまいます。

$ brew tap caskroom/fonts
$ brew cask install font-hack-nerd-font

iTerm2ユーザなので、iTerm2の Preferences > Profiles > Text > Font からフォントを変更します。 f:id:mr_96:20180205172619p:plain

f:id:mr_96:20180205173615p:plain 無事豆腐も解消 \\٩('ω')و//

つぶやき

導入して1ヶ月ほど経ちますが、今の所特に不満もなく、「補完アザァッス」な気持ちで過ごしています。
fish_configと叩けば設定画面が開くのも面白いです。
とはいえ他のと比べて何が良いの、とまではまだわからないレベルなので、もう少し使い込んでみたいと思います。

参考

詳解 fishでモダンなシェル環境の構築(fish,tmux,powerline,peco,z,ghq,dracula) - Qiita
fish shell を使いたい人生だった | Developers.IO

【Rails】rubocopを変更を加えたファイルに限定して実行する

コーディングルールをチェックしてくれるrubocopですが、途中から導入すると、ほとんどの場合ほぼ全ファイル修正する必要があるため、修正をやり遂げる前に力尽きます。
気合いで完遂したとしても、その量のレビューはちょっと辛く思ってしまったり。なんだり。
とりあえずは、自身が修正を加えたファイルに対してrubocop修正もできれば、修正祭は避けられます。

ということで、変更ファイルに限定して実行するようにしました。

git diffの結果に対してrubocop

修正を加えたところはgit diffで取得できます。

git diffだけでは差分の範囲なども表示してくれますが、rubocopで指定したいのはファイルなので、差分はファイル名で欲しいです。
なので、git diff--name-onlyオプションを追加して、ファイルのみ取得します。
rubocop実行のところはxargsで。

$ git diff --name-only | xargs bundle exec rubocop

削除ファイルは対象にしない

また、git管理されていたファイルを削除した場合、差分としては取得できるものの、そのままrubocopを実行するとno such fileと言われてしまいます。
「削除したファイルは差分として取得しなくても良い」として、差分取得時に--diff-filterオプションで、変更したファイルに限定します。

$ git diff --diff-filter=ACMR --name-only | xargs bundle exec rubocop

diff-filterに指定しているACMRは、それぞれ
- A…Added
- C…Copied
- M…Modified
- R…Renamed
です。

差分がなければ実行しない

git diff --diff-filter=ACMR --name-onlyの結果、差分がないとbundle exec rubocopが実行され、全ファイルがrubocopチェック対象になります。
これでは今までゴニョゴニョしてきたオプションが水の泡。rubocopに怒られまくります。

差分がなければrubocopを実行しなければ良いので、xargsの-r, --no-run-if-emptyオプションを使います。

$ git diff --diff-filter=ACMR --name-only | xargs --no-run-if-empty bundle exec rubocop

(xargs -r bundle exec rubocopでも)
Mac上で実行するときは、--no-run-if-emptyをつけると「そんなオプションありません!」と怒られます。
オプションをつけずにxargs bundle exec rubocopのままでも、差分がなければ実行しないようになっているようです。

【Docker】サクッとWordPress立ち上げメモ

サクラの簡単インストールでWordPressをインストールし、破壊し、というのを2回ぐらい繰り返しました。
おとなしくローカルで遊んでからにしよう…と思い、せっかくなのでDockerでローカル環境を作ろうと思い立ち、今に至ります。
公式のドキュメントにあるので完全備忘録です。
クイックスタート・ガイド:Docker Compose と Wordpressを参考に進めます。

docker-compose.yml用意

適当なWordPressプロジェクトのディレクトリを作って移動します。

$ mkdir wp_prj
$ cd wp_prj

作成したwp_prjディレクトリの中に、コンテナを立ち上げるためのdocker-compose.ymlを作ります。内容はクイックガイドのものを丸っと。

# docker-compose.yml
version: '2'
services:
  db:
    image: mysql:5.7
    volumes:
      - "./.data/db:/var/lib/mysql"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    links:
      - db
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_PASSWORD: wordpress

dbwordpressの2つのコンテナを作っています。

docker-composeの内容はこちらの記事がわかりやすかったです。ありがたい…。
参考:Docker Compose - docker-compose.yml リファレンス - Qiita

立ち上げ

docker-compose.ymlの準備ができたら、あとはコマンド一つだけです。

$ docker-compose up

docker-compose up -dのようにdオプションをつけるとデーモン起動)

念のためプロセス確認すると↓のようになります。

$ docker-compose ps
       Name                     Command               State          Ports
----------------------------------------------------------------------------------
wpprj_db_1          docker-entrypoint.sh mysqld      Up      3306/tcp
wpprj_wordpress_1   docker-entrypoint.sh apach ...   Up      0.0.0.0:8000->80/tcp

立ち上がっている状態だと、docker machineを使っている場合はマシンIPでブラウザからアクセスできるようです。
特に何も使っていなければlocalhostでアクセスできるはずです。
今回はdocker machineを使っていないのでlocalhostで。 f:id:mr_96:20171022231417p:plain

無事セットアップ画面まで来れました。まだ破壊してません。