投稿者: sumito.tsukada

コマンドでwordpressのuserを確認する

はじめに

wordpressのユーザー一覧をgit管理したいことがある。
wpコマンドを使うことで実現可能だ。

手順

$ /usr/local/bin/wp  user list --path='/home/kusanagi/cms/DocumentRoot'
+----+-------------------+-------------------+-------------------+--------------------+---------------+
| ID | user_login        | display_name      | user_email        | user_registered    | roles         |
+----+-------------------+-------------------+-------------------+--------------------+---------------+
| 1  | admin             | admin             | aaa@sumito.jp     | 2013-09-04 01:30:4 | administrator |
| 12 | design            | design            | bbb@sumito.jp     | 2018-08-21 07:46:4 | editor        |
| 15 | ccc               | ccc               | ccc@sumito.jp     | 2018-10-01 05:22:5 | ccc           |
+----+-------------------+-------------------+-------------------+--------------------+---------------+
$

まとめ

あとは定期的にこの処理をcronのようにjobとして動かし、
gitへ通知すればスタッフの離職時の棚卸しなどが容易になる。

2019年1月9日

手動でログローテートを行う
はじめに

手動でログローテートを行いたい時があるので、その対応。

手順
```
logrotate -d /etc/logrotate.d/syslog
```
-vオプションを追加すると詳細が表示される手動実行する際は-fで実行する
```
logrotate -f /etc/logrotate.d/syslog
```
2019年1月8日
Linuxでユーザーを複数のグループに追加する方法
Datadogを使用していると、ログにアクセスできないパーミッションエラーが発生することがあります。このエラーは、Linuxで一般的なものです。解決するには、/var/log/syslogを参照できるようにする必要があります。

以下のコマンドを使用して、/var/log/syslogにアクセスできることを確認します。
```
# ls -l /var/log/syslog
-rw-r----- 1 syslog admin 79639 Jan  2 9:09 /var/log/syslog
```
DatadogのエージェントのUID/GIDを確認し、セカンダリーグループ(admin)に追加します。グループを上書きしないように注意してください。

datadogの agentの UID/GIDを確認
```
# id dd-agent
uid=113(dd-agent) gid=118(dd-agent) groups=118(dd-agent)
```
セカンダリーグループ(admin)に追加

仮に-aを忘れてしまうと、所属しているグループを上書きしてしまいます。
```
usermod -aG admin dd-agent
```
確認
```
# id dd-agent
uid=113(dd-agent) gid=118(dd-agent) groups=118(dd-agent),4(admin)
```
これで、Datadogからログを取得できるようになります。
2019年1月4日
2018年を振り返る
2018年も99%が終わり今年を振り返る

▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 99%

— Year Progress (@year_progress) December 28, 2018

お仕事編

本業中の本業について

インフラエンジニアをやっている。

それまで他社クラウドを使いIaaS型のクラウドを使って来たが、

データベースを含むメインの基盤をAWSに移行した。

チーム全員がほぼAWS未経験。2つの国を横断するサーバーをAWSに移行した話。

これによりAWSマネージドサービスを使う事ができ、チームは学ぶべき知識と、得られる知識の領域が変わった。

IT業界全体を俯瞰して見てもAWS移行経験は需要だらけなので、本プロジェクトを通じて、とても貴重で重要な経験をさせてもらった。

プロジェクトリーダーとして

DMP（Data Management Portal）を刷新すべく、そのプロジェクトリーダーをさせてもらっている。具体的にはBigQueryの活用。

プロジェクリーダーの経験は未経験だったし、今まで「稟議書ってなんスカ？」ってほど全くよくわかってなかった。

具体的にやっていることは目的を明確にし、タスクを整理し、人をアサインしプロジェクトを管理するという所。専任のメンバーはいないので、他のチームから1ヶ月あたり0.2人月ほどメンバーを借りてやっているが、

「ちょっと工数かけ過ぎているので、少し抑えてほしい」という話しをエンジニアをお借りしている所のリーダーから来たりするのでプロジェクトリードの難しさを痛感している。

他社での仕事について

レアジョブでは副業が認められている。

自分としては、当然メインの業務もあるし、家庭もあるしということで、積極的に仕事を探していた訳ではなかったが、声がかかった時にだけ副業をしている。

（ちなみに今まではインフラエンジニア養成のための勉強用資料作成、ならびにそれを用いたドットインストール風のvideoなど。フリーランス時代に担当してもらった営業さんからお願いされて、2017年〜2018年はじめに作った）

今やっている副業は、ご縁のある方から「手伝ってほしい」と言われたため、お仕事を受けた。

その会社の特徴として、インフラエンジニアのプロパーがいない。

業務委託のインフラエンジニアが週４で仕事をしている状態で、彼がガシガシ新しいプロダクトに合わせてインフラを作っていているので、運用がまだしっかり整備されていない。という問題があった。

どれだけ整備されていないかというと、論理構成図がない。

なので、GCP/AWSの管理画面に入り、Cacooで論理構成図を作っていく作業。

タイミングよくCacooで構成図の自動作成機能がリリースされたので、基本的にそれを利用。

https://cacoo.com/ja/blog/aws-architecture-import/

ただ、これを使っただけだと使い物にならないので、サービスとして使っている形に整理したり、その後はALBにログインしていき、どのポートで受け付け、どのサーバでどのポートで接続しているのかplotしていった。

ここでの得た事の一つは、
新規参画者には現在の環境の整理をお願いすると、新規参画者への教育コストを抑えつつ、環境を覚えてもらい、ドキュメントも綺麗になる。一度で三度ウマい方法。

自分のプロジェクトでもこれはやりたいと思った。

あとは第三者的にシステムの問題を洗い出し、タスク化し、お客さんと一緒に優先順位を決めていき、それに対する作業見積もりをして、あとはリモートで作業をしていく。

このような形で進めたいと提案し、お客さんに合意してもらった。

しかし、大前提となるのが”信頼関係”である。リモートなら尚更だ。

私に声をかけてくれた方と自分との間には”信頼関係”は既に構築されているが（信頼関係が構築された上で、声をかけてもらったのだが）、他のメンバーの方とは当然まだない。

どのように信頼関係を築いていくかは、一緒に仕事をしていく事が最短だと思っている。信頼関係がない上でのリモート作業は、お互いが不幸になるリスクがある。

その為、以下のアプローチをとった
- タスクを細分化したあとは、とにかくアウトプットの出やすいところから着手。（少しでも多く多く出す。でかいプロジェクトを1個やる。というよりは細かいタスクをたくさんやる。）
- 問題提起と、課題解決案は必ずセット。課題解決案にはメリット・デメリットを添えて。
- 一緒にご飯を食べる（昭和的だけど、これ人間関係を作る上で結構重要。アウトプット以外のところが人間性だと思うから。）
OSSへのコントリビュート

redashのヘビーユーザーだったが、今年4本pull requestを出させてもらい、その全てがmergeされた

user listのソート機能

https://github.com/getredash/redash/pull/3041

CLIでuser一覧を表示さえる時に、ランダムに表示されてしまうが、A-Z順にソートされるようになった。

redash userのacrive/disableの表示機能

https://github.com/getredash/redash/pull/2951

redashのdisable機能はversion 5から導入された。しかしuserがenableなのかdisableなのかはCLIでは確認する方法がなかったので、その機能を追加した。

user listにgroupを表示させる機能

https://github.com/getredash/redash/pull/2967

CLIのuser一覧に所属しているgroupを表示させるようにした

grop listにuserを表示させる機能

https://github.com/getredash/redash/pull/2991

これも似たようなものだけど、CLIでgroup一覧を表示させた場合、そのgroupにどのユーザーが属しているのかわかるようにした。

ちなみにOSSへ貢献するとリポジトリを見てくれる方からメッセージをもらえる事がある

https://findy-code.io/

OSSへのコントリビュートは様々な選択肢を得ることに繋がるので、おすすめだ。

また、redash meetupでの登壇を2本。（登壇資料添付済み）

https://redash-meetup.connpass.com/event/85550/

https://redash-meetup.connpass.com/event/101420/

上記とは別にredashのコントリビュータの会合（redash meetup 4.0.1-dev、redash meetup 4.0.2-dev）をレアジョブで開催した。

今月はredash advent calendarで記事を3本書いた。

https://adventar.org/calendars/3299

ブログを書き始めた

最初はQiitaにアウトプットを書いていたけど、最近はQiitaは書かずwordpressにしている。

理由は以下の通り
- 仕事でwordpressのインフラは見てるけど、どんな風にユーザーが使っているのか、ぶっちゃけよくわかってないので覚えたい
- Google Analyticsを見てアクセスを解析しグロースさせる経験をしたいので、その土台として
- 技術的な事以外も書きたい事がある
今はBlogとしてまとまったことを書くというよりは、あくまでも仕事で使ったことの作業メモ置き場として使っている。

Blogを書いても書かなくても作業のメモは書くけど、それを自分だけで持っている理由はない。自分が困ってたことは、きっと他の誰かも困ってることかもしれないというという理由から始めた。

プライベート編

よかった点

プライベートを定量的に2018年を振り返る。

TOEIC 750点 → 820点
トライアスロン(オリンピックディスタンス) 3時間5分→ 2時間58分
ベンチプレス 40kg → 70kg

書ききれないほどいろいろあったけど、全てが最高。この1年やり直して達成感をもう一度達成感を味わいたいくらい最高に楽しい一年だった

— Sumito.Tsukada (@19840209) December 28, 2018

よくなかった点

マラソンのベストタイム（3時間4分）から依然程遠い。

2013年に妻の妊娠を機に走るのを一時的に辞めたが、まだまだ当時の速さに戻れていない。

今年の目標は3時間30分切りを目標にしていたが、全てのレースで目標に届かなかった。

佐倉マラソン

https://connect.garmin.com/modern/activity/2577060920

長野マラソン

https://connect.garmin.com/modern/activity/2625723712

つくばマラソン

https://connect.garmin.com/modern/activity/3183514412

金沢マラソン

https://connect.garmin.com/modern/activity/3120745226

九十九里トライアスロン（オリンピックディスタンス）では、ベストタイムを出せたが
オリンピック選手の瀬戸大也選手にスイムでぶっちぎりで距離を付けられ、バイクとランで距離を詰める事ができなかった。

2018年は筋トレを始めたということもあり、run/bikeの時間を削った。最近は100km程度しか走れていない。

bikeは完全に通勤、帰宅として。寒くて心折れているのがグラフから読み取れる。

家庭について

息子が4歳（3月に5歳）になるので七五三をやったが、fotowaというサービスを使いプロのカメラマンに来てもらったが、プロのクオリティに感動した。このことはfotowaのオウンドメディアに取り上げてもらった。

【撮影レポ】5歳男の子の七五三！出張カメラマンは子供の笑顔をどうやって引き出すの？

まとめ

多くの方に支えられ、満足いく2018年を終えることができた。

去年より今年、今年より来年。と右肩上がりで成長できれば最高だけど、少なくともそれに近づけれるように2019年も過ごしたいと思う。
2018年12月30日

dockerを長期的に使いDISKを圧迫した時の対処

はじめに

dockerを長期的に運用していると、気がついたらdiskがなくなってることがある。

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3        16G   14G  1.2G  93% /

気がつけば93%もう後がない状態。

対処

dockerの不要なボリュームを削除することで対処可能

まずは使われていないdiskを確認する。

# docker volume ls -f dangling=true
DRIVER              VOLUME NAME
local               0d0c5c35a033c3fbf35bc8eb3b1f9a9612ece1c622cf0ad357b6e20084350760
local               9aea772f64985c7a271f5d20c519b4a59ccd2219030f961c37a1cfb0130f2d35
local               55ccc89f56ebe15c4091cb4b196877ea08e9dd93ecb26fd17b941baf03458b58
local               93ef3cb97887f0d357332afbcebb5c096f7e8eaae4bcfd2285042e51d53771c7
local               529d774ed12a837ceb118b56ef16bd2ad9420973cd76f1a76575c21e9b0719ff
local               543b74740c96e9925d66546fd56b2e8eb3e2254706c0ae10e37dfd54c3719033
local               635117bef58efbcaff9d0b8aab47702d2ad271bb5fffd4e0ab8f700e3d5aa2f5
local               069661160a320af109bccf5099d1f4b7f5a2003911ba8d029075c45b145873d1
local               af62d09de828c78ed362278a8bda4120649dadb5e3d824e65c6309c0293d7d37
local               c8e396a769f4c4e8a0829f9b230fec92b282b9b36575218d25b89bf9891349d5
local               d190aecd81bc16520210af668c3ea0fec32a1b1a3d8554a058c5cef65f87de09
local               dcd49f633c6c0fbb7307788cc1521b6cc9c851fdd52aab9f0af7687ed3a1ab3e
local               e0b22e274022a38e0aedbd6db1b950c3084d1f463e5f1a47b79d5e38d61e5bcb
local               e051a42bc994b73f704863559f818289a4c38ec6f314b99be365e9a6484ac604
local               ebad853173f65bd381eb52f43493825a8e3e9c19bbaaa7dcfd6b03f39611cf4f
#

不要なdiskがぞろぞろ出てくる。

パイプで繋いでxargsで削除。

# docker volume ls -qf dangling=true | xargs docker volume rm
0d0c5c35a033c3fbf35bc8eb3b1f9a9612ece1c622cf0ad357b6e20084350760
9aea772f64985c7a271f5d20c519b4a59ccd2219030f961c37a1cfb0130f2d35
55ccc89f56ebe15c4091cb4b196877ea08e9dd93ecb26fd17b941baf03458b58
93ef3cb97887f0d357332afbcebb5c096f7e8eaae4bcfd2285042e51d53771c7
529d774ed12a837ceb118b56ef16bd2ad9420973cd76f1a76575c21e9b0719ff
543b74740c96e9925d66546fd56b2e8eb3e2254706c0ae10e37dfd54c3719033
635117bef58efbcaff9d0b8aab47702d2ad271bb5fffd4e0ab8f700e3d5aa2f5
069661160a320af109bccf5099d1f4b7f5a2003911ba8d029075c45b145873d1
af62d09de828c78ed362278a8bda4120649dadb5e3d824e65c6309c0293d7d37
c8e396a769f4c4e8a0829f9b230fec92b282b9b36575218d25b89bf9891349d5
d190aecd81bc16520210af668c3ea0fec32a1b1a3d8554a058c5cef65f87de09
dcd49f633c6c0fbb7307788cc1521b6cc9c851fdd52aab9f0af7687ed3a1ab3e
e0b22e274022a38e0aedbd6db1b950c3084d1f463e5f1a47b79d5e38d61e5bcb
e051a42bc994b73f704863559f818289a4c38ec6f314b99be365e9a6484ac604
ebad853173f65bd381eb52f43493825a8e3e9c19bbaaa7dcfd6b03f39611cf4f
#

93% -> 72%に削減できた

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3        16G   11G  4.3G  72% /

コマンドの詳細

dockerの -f “dangling=true” はフィルタオプション。

“dangling=true” はどのコンテナにも紐付いていないボリュームを抽出する事が可能。

2018年12月28日

Cloud Storageをコマンドで操作する
はじめに

awsであればファイル置き場にS3を使うことも多いだろう。
s3への転送したい場合はaws s3 cpコマンドを使うことが多い。似たようなことをGCPでCloud Storageに対して行いたいことがある。

コマンド

ローカルからファイルをコピーする場合 gsutilコマンドを利用する
```
gsutil cp /tmp/hogehoge gs://bucket/dir/
```
削除する場合は
```
gsutil rm gs://bucket/dir/hogehoge
```
オフィシャル情報はこちら https://cloud.google.com/storage/docs/gsutil?hl=ja

おまけ

ちなみにプログラム(Python)に組み込む際はこちら https://tsukada.sumito.jp/2018/11/20/gcp-python-cloud-strage-upload/
2018年12月27日
macでcronがうまく動かない
はじめに

決まった時間に処理を行いたい時、cronを設定することが多い。しかし、時間を設定するとなぜかうまく動かない。ということが発生した。

ダメだった例
```
0 0 * * * mkdir -p ~/Documents/Downloads/`/bin/date +%Y%m%d`
```
毎日0時0分にディレクトリを作りたい。
~/Documents/Downloads/配下に日付ディレクトリを作りたかったが、うまく動かなかった。

対処

macでは%は区切り文字として認識されてしまう。そのため、%の前では¥でエスケープしてあげる必要があることがわかった。
```
0 0 * * * mkdir -p ~/Documents/Downloads/`/bin/date +\%Y\%m\%d`
```
Linuxでは必要ないが、macでは必要らしい。これで期待通りディレクトリが作成されるようになった。
2018年12月26日
redashが正常に動いているか、どう監視するか。
メリークリスマス⛄️
本記事はredash advent calendarの12/24の記事です。

はじめに

redashはさまざまな人が使うツールへと発展してきました。

それに応じてredashは常に安定稼働していなければならない必要性も高まってきています。

redashの状態監視がますます必要な状態になりました。

redashの監視といえば、status.jsonというものがあります。
https://kakakakakku.hatenablog.com/entry/2017/12/21/025718

これを使えば、いまredashがどれだけのクエリが保存されていて、memoryを使っていて。。。ということがわかるのですが。。

しかしある時、API経由で使っている人が「redashの返すクエリの結果が変わらないんだけど。。。」という問い合わせを受けました。

redash自体ハングしていたら、この状態はstatus.jsonではわからないのです。

redashが”機能的に正常に動いているのか、監視する必要がでてきました。

どうやるか

“機能的に”動いているかを確認したいのであれば、”機能的に”監視するのが一番。

redashでは単純に現在時間を返すクエリを登録します
```
SELECT to_char(now() + interval '9hour'  , 'YYYY/MM/DD HH24:MI:SS');
```
データソースはredashの持つpostgresにしました。

redashを監視サーバからAPIで叩きに行き、

前回実行した時間を差分を取るという仕組みです。

前回と違う結果だったら問題なし。同じ結果だったら”異常”とみなす。

監視サーバには以下のシェルを置きました。
```
# cat  ./redash_monitor.sh 
#!/bin/bash

# redashに問い合わせ(cache clear)
$(curl -s https://redash-url.jp/api/queries/309/refresh?api_key=HoZrcikN0uhqNnaAPUtHKhogehogehogehoge -X POST > /dev/null )

sleep 30;
# 現在の値を取得
curl -s https://redash-url.jp/api/queries/309/results.json?api_key=HoZrcikN0uhqNnaAPUtHKhogehogehogehoge  | jq -r '.query_result.data.rows[].to_char ' > /tmp/monitor.txt.tmp

# 差分を比較する。差分があれば通知。
diff /tmp/monitor.txt.tmp.previous /tmp/monitor.txt.tmp

if [ $? -eq 0 ]; then
  # 文字を整形する
  # headder
  cat << _EOT_ > /tmp/msg.txt
  [info]
  [title] Redash might not work well
  [/title]
  Oh my Gush!! Your redash might not work well
  [/info]
  _EOT_

  _roomid=1234567890
  _body=`cat /tmp/msg.txt`
  curl -X POST -H "X-ChatWorkToken: 9aaefddccc40hogehogehogehoge" -d "body=${_body}" "https://api.chatwork.com/v2/rooms/${_roomid}/messages"
fi

mv /tmp/monitor.txt.tmp /tmp/monitor.txt.tmp.previous
```
我々の環境はchatworkを使っているので、宛先はchatworkになっています

これをcronに登録し定期的に実行するようにしています。

最後に

大活躍する機能。と思いたいけど実はredash自体が優秀なためそれほど日の目を見る事はないのです。。
だけどこの監視を設定していると、いち早くredashの不具合に検知することができます。

ちなみにredashがおかしくなったら、serverやworkerコンテナを消してもう一度作り直すのが多いです。

明日は @ariarijp さんによる記事です！
https://adventar.org/calendars/3299#list-2018-12-25
2018年12月20日
redashで誰が何のクエリを投げたのかMySQL側で確認する
はじめに

MySQLはredashで最も多く使われるデータソースの一つです。

MySQLにつなぐ際、用途ごとにユーザーを作成するのが一般的な運用だと思います。

我々はredashも例外ではなく、redash用に”redash”というアカウントをDBに登録しています。つまり、redashからMySQLに接続する際”redash”というユーザーが繋ぎに行くことになります。

そのため、DB側でみると、すべてが”redash”ユーザーになってしまうと思い込んでいたので、MySQL側から「誰が何をやったのか」はわからないはず。と思ってました。

※ redashは version 6 bata版を使っています。

実際はどうなのか

実はredashからMySQLに送られるデータはコメント欄にredashのアカウントが記載されています。
```
+-------+-------------+---------------------+-----------+-------------+---------+-----------------------------------------------------------------------------+------------------+|
| Id | User | Host | db | Command | Time | State | Info |
|+-------+-------------+---------------------+-----------+-------------+---------+-----------------------------------------------------------------------------+------------------+| 
| 23745 | redash | 172.1.2.25:58582 | mysqldb | Query | 123 | preparing | /* Username: tsukada@sumito.jp, Task ID: 86611845-6b88-4b82-b1e3-6951236f8ad6, Query ID: adhoc, Queue: queries, Query Hash: f175924439bfb73a2df8c81234567890 */ SELECT s.id, s.date FROM sample s |https://tsukada.sumito.jp/wp-admin/post.php?post=691&action=edit# | 
```
上記からわかる通り、実施するクエリの前に以下の部分がコメントとして追加されてます。
```
/* Username: tsukada@sumito.jp, Task ID: 86611845-6b88-4b82-b1e3-6951236f8ad6, Query ID: adhoc, Queue: queries, Query Hash: f175924439bfb73a2df8c81234567890 */
```
このUsernameはredashに登録されているユーザのメールアドレスになるのが注意です。
```
show processlist;
```
と組み合わせて、誰が重いクエリを投げているのか、DB側からも誰が何を実施したのかトレースが可能です。

さいごに

他のデータソースは試してないので、
もしご存知の方いらっしゃったら

Redash Advent Calendar ( https://adventar.org/calendars/3299 )

に記載してぜひ教えてください。
2018年12月11日
ERROR: cannot create network conflicts with network networks have overlapping IPv4
はじめに

Docker composeなどを使い、コンテナを立ち上げるとネットワークコンフリクトが発生することがある。
```
Creating network "xxx_net" with driver "bridge"
ERROR: cannot create network 8f6775a9e84cef2a10d6bbbf (br-8f6775a94c): conflicts with network acdac1 (br-605313): networks have overlapping IPv4
```
原因

既にこのネットワークを使うdockerネットワークが存在する

対処

使っていないネットワークが多い場合、整理する
```
# docker network prune
WARNING! This will remove all networks not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Networks:
```
2018年12月4日

投稿者: sumito.tsukada

はじめに

手順

まとめ

はじめに

手順

datadogの agentの UID/GIDを確認

セカンダリーグループ(admin)に追加

確認

お仕事編

本業中の本業について

プロジェクトリーダーとして

他社での仕事について

OSSへのコントリビュート

user listのソート機能

redash userのacrive/disableの表示機能

user listにgroupを表示させる機能

grop listにuserを表示させる機能

ブログを書き始めた

プライベート編

よかった点

よくなかった点

家庭について

まとめ

はじめに

対処

コマンドの詳細

はじめに

コマンド

おまけ

はじめに

ダメだった例

対処

はじめに

どうやるか

最後に

はじめに

実際はどうなのか

さいごに

はじめに

原因

対処