【Rails】ActiveModelSerializersのログを出力しないようにする

Ruby Rails

はじめに

Webサービスを開発していて、気づいたことがあったのでメモ

環境

前提条件

active_model_serializers を使って何かしらレスポンスが返されるようになっていること

調査

Datadogでログを確認していたところ以下のようなログが出力されていた。

[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (103.91ms)

原因

ドキュメントを確認すると ActiveModelSerializers でデフォルト出力することがわかりました。
https://github.com/rails-api/active_model_serializers/blob/a032201a91cbca407211bca0392ba881eef1f7ba/lib/active_model_serializers.rb#L19

解決方法

config/environments/production.rb に以下の通り記述すれば出力されなくなります。

Rails.application.configure do
  # Disable ActiveModelSerializers Logging
  ActiveSupport::Notifications.unsubscribe(ActiveModelSerializers::Logging::RENDER_EVENT)
end

まとめ

これで本番環境で不要なログが表示されないようになりました。

参考

ruby on rails - Remove log message in active-model-serializers - Stack Overflow

【Redash】AWSのAMIを使いアップグレードをする

AWS Docker Redash

はじめに

業務で Redash を導入することになり 公式ドキュメント のAMIを使ったのですが
バージョンが古かったので、公式ドキュメントのアップグレード方法を見ながら
最新のRedashにする手順をメモしておきます。

前提条件

  • ap-northeast-1 の ami-0c7d9b740e997aa69 を使ってRedashサーバーが稼働していること
  • Redashサーバーにログインできること

やり方

cd /opt/redash
sudo docker-compose stop server scheduler scheduled_worker adhoc_worker
sudo vi /opt/redash/docker-compose.yml # 最新バージョンに書き換える。下記参照。
sudo docker-compose run --rm server manage db upgrade
sudo docker-compose up -d
version: '2'
x-redash-service: &redash-service
  image: redash/redash:7.0.0.b18042 # ←初期は5系だったはずなので、このバージョンを書き換える
  depends_on:
    - postgres
    - redis
  env_file: /opt/redash/env
  restart: always

まとめ

ドキュメント通りアップグレードすることができました。
すでにDocker化されているのでアップグレードはとても簡単です。

【MySQL】ユーザー追加のやり方

MySQL AWS Aurora

はじめに

BIツール用に select だけ実行できるユーザーを作りたいということがあると思います。

ただ、ユーザーを作るコマンドを毎回忘れてしまうのでメモすることにしました。

前提条件

やり方

redash ユーザーを追加する。

CREATE USER 'redash'@'%' IDENTIFIED BY '[任意のパスワード]';
GRANT SELECT ON [データベース名].* TO 'redash'@'%' IDENTIFIED BY '[任意のパスワード]';

-- 変更適用
FLUSH PRIVILEGES;

-- ユーザー確認
SELECT user, host FROM mysql.user;

-- 権限確認
SHOW GRANTS FOR 'redash'@'%';

まとめ

ちょっとしたことですが、毎回調べずに済むので楽になります。

【Kubernetes】Kubernetesで設定している環境変数の調べ方

Kubernetes k8s GCP

はじめに

Kubernetes（以下、k8s）の環境変数は etcd という仕組みで管理されています。 etcd は分散KVS（Key Value System）で、1つ設定すれば他のPodでも 同じように環境変数を読むことができます。

etcd 単体で機能として確立されているようですが 今回はk8s上での設定情報の調べ方と値の取得方法を書きます。

前提条件

kubectl コマンドでk8sの設定情報が見れること

# 例
kubectl get pods

やり方

設定情報を一覧で確認したい

kubectl get sercrets

1つの設定情報の内容をすべて確認したい

# 例：SidekiqのBasic認証のusername, passwordを確認する
kubectl get secret user_password -o yaml

以下のような感じで出てきます。 ※パスワードなどは置き換えています。

apiVersion: v1
data:
  user: XXXXXXX
  password: XXXXXXX
kind: Secret
metadata:
  creationTimestamp: 2018-06-26T07:57:55Z
  name: basic-auth
  namespace: default
  resourceVersion: "999999"
  selfLink: /api/v1/namespaces/default/secrets/basic-auth
  uid: 99999999-411f-11e7-bbea-XXXXXXXXXXXXX
type: Opaque

base64 というもので暗号化しているためデコードします。

echo "XXXXX" | base64 --decode

Rubyでやる場合

require 'base64'
Base64.decode64("XXXXX")

まとめ

k8s上でサクッと確認する分にはこれでいい感じです。

【Kubernetes】Kubernetes 用語やコマンドの調査メモ

GCP Kubernetes k8s

はじめに

業務で Kubernetes を使った環境構築が必要となったため
調べたことをメモっていたら記事にできる量になっていたので
ブログに掲載します。

環境

  • macOS Sierra
  • Google Cloud Platform
    • この環境で確認したものもあるため

前提条件

  • Docker, docker-composeにローカル環境が構築できる知識レベルであること

Kubernetes（クーべネティス または クーバーネティス） 略して k8s

一言で言うとコンテナ周りのことをよろしくやってくれるもの。
横文字で言うと「オーケストレーションツール」。

基本構成

  • 複数サーバでのコンテナ統合管理
  • コンテナ間のネットワーク管理（IPアドレスの管理／ルーティング）
  • コンテナに割り当てるストレージの管理
  • コンテナの負荷分散
  • コンテナの監視
  • 無停止でのアップデート

サーバ構成

マスターサーバ（Kubernetes Master）

Kubernetesクラスタ内のコンテナを操作するためのサーバ。
kubectl コマンドを使ってクラスタを構成したりリソースを操作する際は
マスターサーバがコマンドからのリクエストを行って処理を行う。

ノード（Node）

  • Dockerコンテナを動作させる仮想（物理）サーバ
  • ノードを複数用意して、クラスタを構成する
  • ノードの管理は、マスターサーバが行う

バックエンドデータベース（etcd）

etcd と呼ばれる Key-Value Store（KVS） を使って
クラスタの構成情報をまとめて管理する。

レジストリサーバ（Docker Registry）

クラスタ内で起動するDockerコンテナのもとになるDockerイメージを管理するためのサーバ。
Docker Registry を使って構築することもできる。

用語

クラスタリング

複数サーバを束ねて、利用者や外部のシステムに対して
全体で1台のコンピュータであるかようにみせる技術のこと。

ただし、Dockerコンテナでのクラスタリングの考え方は異なる。
コンテナが稼働するサーバを複数用意して、それぞれのサーバで複数のコンテナを並列稼働する。
何らかの理由で、サーバ上のコンテナが正常動作しなくなった場合、他のサーバで該当の
コンテナを起動し直すことで、アプリケーションのフェイルオーバーを行う。
上記のことやヘルスチェックをオーケストレーションツールによって行われる。

Pod

仮装NIC（プライベートIP）を共有するコンテナ郡をまとめたものをPodと呼ぶ。
k8sはPodの単位でコンテナの作成／開始／停止／削除といった操作を行う。
Pod内のコンテナは同一のノード上に配備される。
また、Pod内のコンテナで共有するディレクトリを配置することも可能。
たとえば、アプリケーションが稼働するコンテナとログ収集ツールを導入したコンテナを
1つのPodにまとめて起動すれば、localhost経由での通信、あるいは、共有ディレクトリを介して
ログ情報をやり取りすることが可能。

Replication Controller

同一構成のPodが指定の数だけ起動している状態を作り出す。
Webサーバが稼働するPodを負荷分散用に複数起動するような際に利用する。

Podを起動する際は Pod単体か Replication Controller 経由で起動するか選べるが
Pod単体で起動した場合、Podの数は動的に増やせない。
なので、本番環境で稼働させるときは、Replication Controllerから起動すること。

Deploymentの設定ファイルを通して、Replication Controllerの設定／管理をする。

なお、今は Replica Sets が次世代のものとなっている。

Deployments

Deploymentsはアプリケーションインスタンスの作成と変更を担う。

Service

Podを起動しただけでは、外部からアクセスできない。
起動中のPodに対して、Serviceを定義することで外部からアクセス可能をIPアドレスを用意される。
複数のPodに対して、これらをまとめた1つのServiceを定義する。
Serviceに対応するIPアドレス＋ポート番号にアクセスすると、複数のPodに対する負荷分散が行われる。

新規にPodを起動すると、既存のServiceのIPアドレスとポート番号は、環境変数として
参照できるようになる。また、GKEの環境では、クラスタ内部のDNSを用いて、独自のサービス名による名前解決もできるようになっている。

Ingress

通常、ServiceとPodだけでサービスを稼働させることは可能だが
Ingressを定義することによりInternetとServiceの間に入り接続のルールをまとめることができる。
例えば、HTTPSの負荷分散をすることができる。

秘密情報の管理

k8sでID、パスワードなどの秘密情報を管理する場合 Kubernetes Secrets を使って管理する。

例：staging環境のものを確認

# staging環境のクラスターに接続するための準備
gcloud config set project sample-staging
gcloud container clusters get-credentials sample-cluster --zone asia-northeast1-a

# 秘密情報を確認
kubectl get secrets

# 表示結果
NAME                 TYPE                          DATA      AGE
sample               Opaque                        2         174d
sample2              Opaque                        7         202d
以下略

# 秘密情報の内容を確認
# 例：adminの内容を見る
kubectl get secret sample -o yaml

Helm

Helmとはk8sのパッケージングマネージャーという位置づけ。
apt-get , yum や rpm, Homebrew と同等です。

よく使う、使ったコマンド

Kubernetes

コマンド 意味
kubectl run [deployment name / pod name prefix] --image=[image]:[tag] [cmd] クラスタ内でコンテナを作成
kubectl expose [deployment name / pod name prefix] [コンテナ名] --type=[サービスタイプ] サービスを外部公開できるようにする
kubectl get [ingress, services, deployments, pods, secret] リソース一覧
kubectl get secret [リソース名] -o yaml リソース内容をyaml形式で表示
kubectl describe [ingress, services, deployments, pods, secrets/[リソース名]] リソースの詳細情報表示
kubectl exec -it [コンテナ名] /bin/bash Podのコンテナ内でコマンド実行
kubectl proxy ローカルプロキシが起動され、現在参照しているk8sの内容を http://localhost:8001/ui/ で確認できる
echo "[エンコードされた文字列]" | base64 --decode エンコードされた文字列を表示

参考文献

【Rails】ローカル環境の開発でサブドメインがある場合「localhost」ではなく「lvh.me」を使う

Rails Ruby

はじめに

Webサービスを開発していて、初めて知ったのでメモ。

環境

前提条件

Rails Engineで管理画面を作成していて、以下のように記述してあること。

mount Admin::Engine => '/', constraints: { subdomain: 'admin' }

また、Dockerが起動していて localhost:3000 にはアクセスできること。

詳細

よくある記事では localhost:3000 が記述されており
通常はこれで問題ありません。

しかし、サブドメインを含めた形にすると localhost ではできなくどうしたものか？と考えていました。

そこで調べて出てきたのが lvh.me です。 参考サイトには以下のように書かれています。

lvh.meというドメインを持っている人が開発用に127.0.0.1でDNS登録してくれている． localhost以外のドメインやサブドメインのテストでローカルの開発環境のアプリにアクセスしたいときに使えるというもの． http://tech.clickyourstyle.com/articles/30

こんな便利なものがあるとは。 ということで、早速 lvh.me を使ってみると以下のURLになります。

まとめ

今までは /admin でやったりしていたのですが
これでローカルでも気軽にサブドメインの開発ができて捗りそうです。

参考

lvh.meというループバックドメイン:Technical tips:Media hub

【勉強会】VP of Engineering Meetup by CA #3 に参加しました

勉強会 VPofEngineering

前回に引き続き参加してきました。
自分もプログラマなので、プログラマ関連の話はすぐに聞けますが
マネジメント周りの話はなかなかなく、他社の事例を聞けるため
勢い良く参加しました。

※メモはスライドに書かれている内容を書かず
なるべく登壇者が話した内容をメモするようにしています。
なので、飛び飛びなところもあります。

概要

cyberagent.connpass.com

内容

イベント趣旨説明

まず、参加者全員で「VPoEとはどういうものか？」というのを定義しました。

前回と同じ流れだったので特にメモはしていないのですが
個人で定義が曖昧なので、この説明は毎回必須だなと思いました。

スライドの内容は前回と同じだったはずなので
前回開催されたブログを一時的に掲載します。

developers.cyberagent.co.jp

『成果を出し続けるエンジニア組織を目指してやってること』

speakerdeck.com

登壇者がやっている内容を共有していただきました。

以下、メモした内容です。

ウエパはエンジニア管轄とディレクター管轄があり
エンジニア側のマネージャーにいる。
そして、各種特化したチームがあり、全体で20人強

CTO, VPoEの役職はない。
マネージャーがVPoE的役割
技術ボードがCTO的役割

VPoEの定義は
成果を出し続けられるエンジニア組織を作っていくこと

じゃあ、何を目指してやるものか？
ビジネス的に動けるエンジニア組織となること

マネージャー業務に関して一例をあげられた
特に時間を取っているのは「他部署のマネージャーや担当執行役との定期的な情報共有やMTG」
組織的に解決したいことがあった際に呼ばれる。

問題に当たったら先人の知恵を借りて物事を進めている。
1人で解決できなかったことがないくらい先人の知恵を借りている。

メンバーとの対話ポイント
1on1
　No雑談、目標進捗を話すことは少ない
　週ごとにテーマを決めての会話（10枚程度カードを用意していて、成果や不満、悩みが書かれており、1回につき2, 3枚ピックアップして話す）
　雑談から話すよりもしっかりテーマが決まっているのでスムーズに進む。
　やる側としてコーチング時間であることを意識している。

参考書籍は「ドラッガーさんに教わったIT技術者が変わる50の習慣」
技術スキルと人間スキルが成長のための両輪であることを参考にした。

内発的動機を1on1を通じて加速させるようにしている。

対話ポイント
　権限委譲
　　マネージャーレベルだけでなく、メンバーレベルで意識してもらうことが大事。
　　若手ほど権限委譲で「伸びる！」マッチして掛け算レベルで成長する。

参考書籍は「経営者の条件」
仕事を「人」に合わせること

成果へのありがとう
　これは難しい。
　感謝の「ありがとう」の言葉より、同調が大事。
　メンバーからは一歩引かれた形に見られてしまう。

マネージャーは真摯な態度が大事。

個人ビジョンに沿う目標の設定
　3ヶ月毎に実施。マネージングで会社の目標と個人目標をマッチングさせること。

コトに向かう
　コトを成すことに精一杯取り組む。

チーム作りで「カンバン方式」がオススメ。
　仕事が見える化された。
　タスクの流れが明確になった・・・などメリットがあった。
上記をやってから施策をやっていくのが良い。

経営層の考えをメンバーに伝達
　経営層の端的な言葉を、まず自分で噛み砕くことをして下に伝えるようにする。

途中のスライドまでしかメモがないのは、時間がなくなったためです。
逆に時間がなくなるぐらいたくさんのことをやっていて共有したいことがあるという現れだと感じました。

『組織をシステム化するReactive Management』

www.slideshare.net

タイトルの発想がとてもユニークだと思いました。
また、内容も的を得ているなと思うものでした。

以下、メモした内容です。

VPoEはマネジメント？
複雑な人間関係、自分でコントロールできないところもある。
Cyberでも定義が曖昧だが、必ず必要な役割である。

VPoEに必要なところをカテゴライズして、直列化することにより
ビジネススピードを拡大させる必要がある。

リアクティブマネジメントとは？
元はリアクティブ宣言
マネジメント対象の行動を常に観察し、行動に対してフィードバックを即座に返す
マネージャーは「観察」が重要である。

マネージャー自身は多数の「仕事の定義」を持ち「観察」を行い、何か（イベント）があれば即応する。
半年前のことを言われても「今更その話」となってしまう。
参考書籍：パフォーマンス・マネジメント

採用・退職・ヒューマンマネジメント・開発プロセスをKPTを使った振り返りでカイゼンすることによりチームの耐障害性を高める。

スキルや経験は人に宿るため「その人」だからできることがある（Not その人にしかできない）
どんな人がいるチームかによってフォーメーションは弾力的に変える。

開発責任者は結果論で決まるので、柔軟に決めていく。

自分がボトルネックになってはいけない。自分からpullしていたらもたない。
Evernoteに会話メモを残し、メモリスタックをどこでもロード可能にする。
外部にタスクスケジューリングを任せる。

マネージャーの評価はどうされるべきか？
そのまま評価指標・基準に利用することも可能
　・即応性
　・耐障害性
　・弾力性
　・メッセージ駆動
マネージャーとしての価値はその再現性（immutability）の高さ
いつでも、どこでも、どんな状態でもReactivityを出す。

今プロダクトを作っているチームと同等のものを違う人、地域で作れるようにしないといけない。

組織というのは自分の思っているより3期ぐらい遅れてやってくる。（後追いで来る）
人は誘導できないから、後からついてくる形となる。
マネージャーは常に次のチャレンジをし続けるようにして「次も任さればいいチームを作る」という認識を持ってもらう。

VPoEは結局マネージャーである。
アイデンティティとして「自分はエンジニアである」と考えていることが重要

Web世代の人は技術をクリアした上でマネージャーとなっているため
一昔前のマネージャーとは違うもの。
名刺にもマネージャー、エンジニアとも書かれている。

エンジニアにアイデンティティを持っていて、いつでもどこでもどんな状況でもReactivityを再現できることに強みを持つ
Webエンジニアが作るマネージャーの再定義
マネジメントは技術である

エンジニアでやっていることをマネージャーになっても同じことをやればよい。

ガッツリなマネージャー論かと思いきや
エンジニアでもわかるような内容だったと思います。

『ゼロからのエンジニア組織作り（仮）』

speakerdeck.com

スタートアップから携わっていて、会社の成長につれての話を聞くことができました。

以下、メモした内容です。

設立期は事業の立ち上げが最優先、安定した品質のゲームをいかに速くリリースできるか？にフォーカス

人数が少なかったので、1人1人の当事者意識が自然と高まった。
キーマンの採用が速いかった。
コミュが密。

採用担当者同士で採用基準、判断基準のすり合わせ
有識者にとにかく聞く、巻き込む
1人で判断しない

設立的には技術面の魅力が語りにくい（魅力的な技術よりも事業立ち上げが最優先だったため）

成長期
うまく行ったこと
　新たなリーダーの抜擢、成長
　若手の活躍、成長
　月イチの1on1を開始
　　事前にシートを記入して面談する
　　ただし工数が非常に重く感じていてカイゼンを考えていくところ
　1年目限定新卒朝面談
　読書会の開始

変革期
新たな技術の習得が必須になった。
既存コードを捨てて再設計（サーバサイド）
技術チャレンジを事業成果に
技術的負債の返済を積極的に

VPoEとしてどの部分を意識してやってきたのか？を絡めて話してもらえれば
もっとわかりやすいと思った。

具体的な業務内容を期ごとに書かれており
とてもわかりやすかったです。

LT

メモを取れる状態ではなかったので、スライドだけ共有します。

speakerdeck.com

speakerdeck.com

後1つスライドあったのですが、見つからなかったため
掲載され次第ここに追記します。

全体を通しての感想

今回も他社の事例を聞くことができて、とても参考となりました。
また参考書も豊富だったので読んでみようと思います。

後、自分の会社でやっていることを他社でもやっていてちょっとやり方が違うだけ
というのもいくつか見られたので、そろそろまとめられるのでは？と思いました。
VPoEだったら、これはやっとけ！みたいなものです。

そして、アンケートに書き忘れましたが
VPoEはエンジニア出身が多いと思うので、どのようにビジネスサイドに入っていって
ビジネス側とエンジニア側を円滑に回しているのか？というのも聞きたいと思いました。

また次回も参加します。