【Redash】AWSのAMIを使いアップグレードをする
はじめに
業務で 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】ユーザー追加のやり方
はじめに
BIツール用に select だけ実行できるユーザーを作りたいということがあると思います。
ただ、ユーザーを作るコマンドを毎回忘れてしまうのでメモすることにしました。
前提条件
- MySQL5.7（Amazon Aurora for MySQL）
- DBが設定済みでログインできること
やり方
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 を使った環境構築が必要となったため
調べたことをメモっていたら記事にできる量になっていたので
ブログに掲載します。
環境
前提条件
- 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 | エンコードされた文字列を表示 |
参考文献
プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで
- 作者: 阿佐志保,中井悦司
- 出版社/メーカー: 翔泳社
- 発売日: 2017/06/02
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
【Rails】ローカル環境の開発でサブドメインがある場合「localhost」ではなく「lvh.me」を使う
はじめに
Webサービスを開発していて、初めて知ったのでメモ。
環境
- macOS Sierra
- Docker(docker-compose)
- Ruby 2.5.0
- Ruby on Rails 5.1.4
前提条件
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になります。
- http://lvh.me:3000 # フロント側
- http://admin.lvh.me:3200 # 管理側
まとめ
今までは /admin でやったりしていたのですが
これでローカルでも気軽にサブドメインの開発ができて捗りそうです。
参考
【勉強会】VP of Engineering Meetup by CA #3 に参加しました
前回に引き続き参加してきました。
自分もプログラマなので、プログラマ関連の話はすぐに聞けますが
マネジメント周りの話はなかなかなく、他社の事例を聞けるため
勢い良く参加しました。
※メモはスライドに書かれている内容を書かず
なるべく登壇者が話した内容をメモするようにしています。
なので、飛び飛びなところもあります。
概要
内容
イベント趣旨説明
まず、参加者全員で「VPoEとはどういうものか？」というのを定義しました。
前回と同じ流れだったので特にメモはしていないのですが
個人で定義が曖昧なので、この説明は毎回必須だなと思いました。
スライドの内容は前回と同じだったはずなので
前回開催されたブログを一時的に掲載します。
『成果を出し続けるエンジニア組織を目指してやってること』
登壇者がやっている内容を共有していただきました。
以下、メモした内容です。
ウエパはエンジニア管轄とディレクター管轄があり エンジニア側のマネージャーにいる。 そして、各種特化したチームがあり、全体で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エンジニアが作るマネージャーの再定義 マネジメントは技術である エンジニアでやっていることをマネージャーになっても同じことをやればよい。
ガッツリなマネージャー論かと思いきや
エンジニアでもわかるような内容だったと思います。
『ゼロからのエンジニア組織作り（仮）』
スタートアップから携わっていて、会社の成長につれての話を聞くことができました。
以下、メモした内容です。
設立期は事業の立ち上げが最優先、安定した品質のゲームをいかに速くリリースできるか？にフォーカス 人数が少なかったので、1人1人の当事者意識が自然と高まった。 キーマンの採用が速いかった。 コミュが密。 採用担当者同士で採用基準、判断基準のすり合わせ 有識者にとにかく聞く、巻き込む 1人で判断しない 設立的には技術面の魅力が語りにくい（魅力的な技術よりも事業立ち上げが最優先だったため） 成長期 うまく行ったこと 新たなリーダーの抜擢、成長 若手の活躍、成長 月イチの1on1を開始 事前にシートを記入して面談する ただし工数が非常に重く感じていてカイゼンを考えていくところ 1年目限定新卒朝面談 読書会の開始 変革期 新たな技術の習得が必須になった。 既存コードを捨てて再設計（サーバサイド） 技術チャレンジを事業成果に 技術的負債の返済を積極的に VPoEとしてどの部分を意識してやってきたのか？を絡めて話してもらえれば もっとわかりやすいと思った。
具体的な業務内容を期ごとに書かれており
とてもわかりやすかったです。
LT
メモを取れる状態ではなかったので、スライドだけ共有します。
後1つスライドあったのですが、見つからなかったため
掲載され次第ここに追記します。
全体を通しての感想
今回も他社の事例を聞くことができて、とても参考となりました。
また参考書も豊富だったので読んでみようと思います。
後、自分の会社でやっていることを他社でもやっていてちょっとやり方が違うだけ
というのもいくつか見られたので、そろそろまとめられるのでは？と思いました。
VPoEだったら、これはやっとけ！みたいなものです。
そして、アンケートに書き忘れましたが
VPoEはエンジニア出身が多いと思うので、どのようにビジネスサイドに入っていって
ビジネス側とエンジニア側を円滑に回しているのか？というのも聞きたいと思いました。
また次回も参加します。
【AWS】【Let's Encrypt】Let's Encryptを使っての証明書発行をAWS Certificate Managerにして、お名前.comに設定する
はじめに
勉強がてらSPAで作成したWebサービスを作っており ドメインはお名前.comで取得、証明書を作れるLet's Encryptを使っていました。 とても便利で1年半ぐらいは使わせてもらっていました。
しかし、最近になり証明書更新のコマンドが動かなり
3ヶ月に1回更新するのにも疲れたのでAWS Certificate Manager（以下、ACM）を使ってみることにしました。
環境
前提条件
- AWSのアカウントがあり、ACMを適用できるサービスを使用している
- 今回は、CloudFrontに証明書を設定します。
- AWS以外でドメインを取得している。
- タイトル通りお名前.comに対して操作をしますが基本一緒だと思います。
- Route53を使ってDNS登録をしている。
- この運用をしていたからであり初めて設定する場合、登録していなくても問題ありません。
対応する前の状態
※本当はAレコードも設定してあります。 ※NSレコードの内容をお名前.comに登録してありました。
やり方
証明書の発行
ACMに移動して「証明書のリクエスト」を押下します。
そうするとドメイン名を入力する画面が出てくるので入力します。
※今回は説明用にsample-acm.com としています。
ここでポイントなのが、ワイルドカードドメイン名とワイルドカードがないドメイン名を両方設定しておくことです。
これをやることにより
上記のようなURLがすべて適用されるようになります。
そして、次に行くと
選択肢が2つあり、取得したドメインでメールを受け取る設定をしていなかったので「DNSの検証」を選択しました。
なお、DNSの検証は2017年11月からできた機能のようでAWSはこちらを推奨しているようです。
選択した状態で次に行き、確定とリクエストをします。 そうすると検証という画面になり、CNAMEレコードが表示されます。
このCNAMEレコードをお名前.comのDNS設定に転記します。
お名前.comの管理ページから下記ページに遷移して
以下を選択します。
次のページで入力するところがあるので、入力していきます。
※画面下に「DNSレコード設定用ネームサーバー変更確認」とありますが
チェックしてから次に進んで設定してください。
これでお名前.com側の設定が終わりで数十分待つと、ACM側が以下のようになります。
次にACMで作成したものをCloudFrontに設定します。
これで準備が完了しました。
しばらくしてサイトにアクセスするとSSLが有効なものになっているはずです。
そして証明書の内容を確認してみます。
ちゃんとAmazonが発行した証明書になっています。
まとめ
今までLet's Encryptでやっていたのは何だったのか・・・
やはり、AWSはすごい！と思わされる内容でした。
AWSを使ってやる場合、ACMを使っての証明書発行が1番速く確実だと思います。