【Ruby】RubyMineでrbenvでインストールしたRubyを指定する

はじめに

RubyMine(以下、IDE) をJetBrains経由で新しくダウンロードして
IDEの設定を設定していたところRubyのバージョンを指定する必要がありました。

筆者は rbenvRubyをインストールしていたため指定方法に
手間取ったので記録として残しておきます。

前提条件

環境

  • macOS Mojave
  • RubyMine version 2020.1
  • rbenvがインストールされていて
    何かしらのバージョンのRubyがインストールされている

やり方

command と , を押して設定画面を開く。

f:id:fujikawa-y:20200418234510p:plain

+ を押して New local... を選択する。

f:id:fujikawa-y:20200418234556p:plain

/Users/{ユーザー名}/.rbenv/versions/2.7.0/bin/ruby を指定する。
※自分の設定がここなので、個々によって違うかもしれません。

f:id:fujikawa-y:20200418234650p:plain

指定したバージョンが表示されればOK

f:id:fujikawa-y:20200418234724p:plain

まとめ

~/.rbenv にあるはずなのですが New local version manager... で指定しても反映されず
その調査をするより直接Rubyのバージョンを指定する方が早いと思いこの通りにしました。

もし、バージョンマネージャーを指定できてる人がいたら教えてもらえると嬉しいです。

参考

https://www.jetbrains.com/help/ruby/configuring-language-interpreter.html

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

はじめに

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を使いアップグレードをする

はじめに

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

前提条件

  • ap-northeast-1ami-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】ユーザー追加のやり方

はじめに

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)の環境変数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 用語やコマンドの調査メモ

はじめに

業務で 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 , yumrpm, 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」を使う

はじめに

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

環境

前提条件

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

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

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

詳細

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

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

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

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

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

まとめ

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

参考

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