tshimba’s blog

このサイトの掲載内容は私自身の見解であり、所属する組織とは関係ありません

JJUG ガチKubernetes講座まとめ

先日開催されてJJUG主催のKubernetes講座【東京】JJUG ナイトセミナー 「ガチKubernetes講座@Microsoft」 3/2(金)開催に参加してきました。

当日の資料はすべてGitHub上に公開されています。

github.com

資料を直接読み込むのが一番いいかと思いますが、当日スピーカーの方が話した内容を殴り書きでメモしましたので、以下に載せておきます。

例えばラベルにはapp, env, versionは必ず入れましょうだったり、Deploymentの設定にはネットのサンプルとして転がっているYAMLファイルでは不十分なので最低限こういうないようは記載しましょうといった内容がためになりました。最後の8章は、Kubernetes関連のHelm, Draftなど便利ツールの紹介でした。

講座中はスキップした内容もあったこともあり、すべてはメモできていないので、本エントリは概要の把握にとどめ、詳細はGitHubの原典にあたっていただければと思います。

Speaker

Yoshio Terada k8s-Azure-Container-Service-AKS--on

hackfest で蓄えたノウハウ伝授 ローカル環境にあったメモをbrash upしたもの

Kubernetesのすばらしさ - 開発者と運用者両方が協力して扱うことで発揮できる

資料はすべてGitHubに公開する

2020のプロジェクトがあるので、すべてのサービスを知っている人はいない。 常にキャッチアップをしないといけない。

About Kubernetes

  1. Master
  2. node
  3. Pod
  4. Container
  5. Service
  6. Deployment
  7. iptable
  8. ingress
  9. version
  10. namespace
  11. istio

master

master serverの重要なコンポーネント - API Server: REST を待ち受けるサーバ

node

可用性セットのVM

pod

Pod: Container間のサービスが密接に関わりがある場合

service

1 service, multi pods

deployment

replicas

labels

ラベルからこのサービスを選択可能。 ちゃんと書いていきましょう。

例: - app: account-service - env: test - version: v1

container

image: xxx <- 作成したimageの指定

iptable

version

最新 1.9.x

namespace

dev, prod, testなどで分けて使うイメージ

istio (6章)

version 0.5? まだ本番環境では速い。 istio (サービスメッシュ) はトレンドなので動向を見守る

podの中にproxyが作成される イエーガー? 分散トレーシングして、マイクロサービスの依存関係のツリーを可視化してくれたりする サービスから個々のサービスの呼び出しにどのくらい時間がかかるのか取得できる

Kubernetes自身のネットワーク周りが弱い。Istioすごい便利 - version 1に100%処理を振るなどの指定 - 特定のheaderがあるリクエストだけがversion 2にアクセスするなど - カナリアリリース - サーキットブレーカー <- Java側でnetflixのライブラリを使用しなくてもいい。Istioでやってくれる

AzureでKubernetesを使用する場合の説明

提供形態

  • Managed: microsoft managed master servers. masterノード用のVMの支払不要。k8s のバージョンアップもコマンド一つで可能。システムを停止せずに更新可能(3,40分程度かかる)
  • not managed: ACS is not managed. 自身でmasterノードのHAなど必要

環境構築

Mac, Windows 10は簡単 古いwindowsVMなどを立ち上げたほうが速い

Azure cli

brew install az command

$ az aks <- kubernetes 環境構築
$ az login

AKS

まだpreview version 一部リージョンで使用可能

Azureのリソースグループの説明

$ az group create --name MCACS-AKS --location eastus
$ az aks create --resource-group MCACS-AKS --name esakscluster --node-count 5 --generate-ssh-keys
$ az aks install-cli <- credential 取得
$ kubectl cluster-info
$ kubectl version <- 1.7.7 (update later)

nodeの数

サービスにあわせてVMの数も増やす

$ az aks scale --name esakscluster --resource-group MCACS-AKS --node-count 7

version up

無停止バージョンアップが可能 Azure は1.8.7が最新、1.9.x対応準備中

$ # version check
$ az aks get-upgrades --name esakscluster --resource-group MCACS-AKS
$ # upgrade
$ az aks upgrade --name esakscluster --resource-group MCACS-AKS  --kubernetes-version 1.8.7 --yes
$ # check version
$ kubectl get node -w

構築

Dockerfile

前提知識:小さいイメージを作る java:8-jdk-alpine <- 小さい * alpineはコマンドなども変わるので気をつける。普通のUbuntuなどとは違う 注意点例1:ssl関係ライブラリが入っていない 注意点例2:useraddではなくadduser

ビルド結果のみimageに入れる

docker version 17.05 から multi stage build 複数のビルドステップを記述可能。(FROMを複数記述可能) -> DeliveryPipeline のような感じで、BUILDステップ、DEPLOYステップを分けて記述可能 * サンプルではparayaを使っている

Java SE9 以降 -> JREを自分で作れる -> より小さいimageを作れる

push image

pull image from kubernetes

Pod

本番環境で耐えられる deployment

教科書レベルのdeploymentに追加すべきこと

ラベル

ラベルは必ずつける app, env, version

rolling upgrade

今動いているコンテナに来ているアクセスはどうするのかなど、設定可能

例: - minReadySecond -> コンテナ起動後、アプリが正常に動くまで待つ - maxSurge -> 先に1個増やす - maxUnavailable -> かならず1個は残す

health check

livenessProbe

  • initialDelaySeconds: コンテナが起動しただけで正常となる(デフォルト)ことを防ぐ。healt chechまでの時間。falseだとコンテナを再起動されてしまう。
  • readinessProbe: サービスを使えるかを確認する。10秒に一回pingをかける
  • failureThreshold: X回失敗したらFailとする

リソース管理

pod 上の service は node 上のリソースを使い切ってしまう。 -> node上の全サービスに影響を与える可能性がある。

実際には負荷テストをしてから、リソースの上限を決定する

$ # get pods
$ kubectl get po
$ # 使用しているリソースを取得
$ kubectl top pod PODID
設定での指定方法
  • requests:
  • limits: (単位:1cpu = 1000m)

コンストラクタ的なもの

init Container

Podを起動前に実行する処理 Java クラスのコンストラクタ的なもの

poststart hook

prestop hook

------------------ ここまででpodが作成できました

Service

YAML要素

  • selector: ラベルをしていしてexposeする。versionなども指定可能。ex) app: account-service
  • type: 基本クラスタIPを指定する

複数YAMLをまとめる

--- で区切ってYAMLを繋げる

リリース作業

以下の手順が必要だが、毎回実行するのは大変 - build app - create image - push image - pull image ...

Shellスクリプトで記述してしまう。 (jenkisとかは使えないが、開発で頻繁にリリースする場合は使える)

---- ここまででビルド完了

動作確認

本番環境では基本クラスタIPを使用するが、特定のサービスの動作確認をしたい場合にはport forwardして単体で公開する。

YAML

YAMLを書く時に参考にできる公式の情報の調べ方

$ kubectl explain deplloyment.spec

---------- ここまで3章

4章

最低限覚えておいたほうがいいコマンド一覧 22個 -w: watchの略 -> 動的に変わる情報を閲覧する -o wide: podがどのnode上で動いているか取得する

  1. a
  2. 2
  3. config map service-name.ns-name.svc.cluster.local <- dns名でアクセス可能(直接ipでない)
  4. secret
  5. apply: 上書きできる
  6. delete
  7. edit: 一時的に設定を変える <- 一時的にサービス単体に外部IPを与える時など
  8. scale --replicas: 明示的にスケールをさせる場合
  9. auto scale
  10. kubectl config get-contexts: よく使うkubernetes環境をデフォルトに設定できる
  11. kubectl xxx: よく使うnamespaceをデフォルトに設定できる

5章

KubernetesのREST api

6章

istio

7章

Kubernetesを扱う上での注意点

タグ:latest <- latestタグを使用するのはやめてください

何がlatestなのかわからなくなってくる 必ずimageに対してはversion番号を振る kubernetesはロールバックなどもできるので、どのバージョンに戻るか指定するのが難しい(人間にやさしくない。不可能ではない)

1つのサービスを1コンテナで提供していきましょう

自分がKubernetesのどのバージョンを使用しているのか意識する

バージョンが上がるとYAMLの書き方やコマンドが変わってくる。後方互換性がなくなってくる。

Podを直接使わないでください。

* ReplicationController(Old) -> ReplicaSet(Old) -> Deployment

できるだけ小さいimageを使用する

officialはまだいいかもしれないが、人のimageは使用しない。

ClientIPを使用する

Nodeに対してアクセスできないようにする(Azure AKSではdefaultで使用できなくなっている)

Nodeが乗っ取られると最悪 必ずmaster経由でアクセスする

recordオプション

applyをするときにはrecordオプションを使用する

config map, secretを使用しましょう

8章

Kubernetesを扱う時に便利なツール

  1. Helm: 開発、デプロイ
  2. Draft: 開発時にユーザをXXのdeveloperと認識して、draft create とするとjavaと認識する?
  3. SpenNaker: CI/CD

  4. weave

# すごい細かい情報が取れる
$ kubectl port-forward -n weave PODID
  1. Heptio Ark: Backup & Restore
  2. kube-monkey
  3. open service broker Kubernetes Service Catalog Azure: OSBA (Open service broker for Azure)

マイクロサービスとドメイン駆動設計 (1)

マイクロサービスアーキテクチャの目的と課題

最近はどこもかしこもマイクロサービスがブームになっているようである。クラウドの普及に伴って、マイクロサービスを実際に構築できる技術的な土壌が整ってきていることも追い風になっている。しかし、実際に構築しようとすると壁にぶちあったってしまうことが多いと思う。

ユーザー企業が求めていることは、変化に速く対応できるシステムを作ることであると思う。このような要件を満たすためにマイクロサービスアーキテクチャを適用できる。マイクロサービスが技術的に実現することは、サービスを分割して、個々のシステムを頻繁にリリースできることである。頻繁にリリースを行うことで、変化に迅速に対応する基盤を提供することができる。このことを忘れてベンダー企業ではサービスを分割することだけを考えて変化に迅速に対応できるかというところを忘れていることもあると思う。

サービスの分割方法

そもそもマイクロサービスというネーミングがミスリーディングだと思うが、SOAよりは小さいだろうというくらいで、特にサービスの大きさが本質ではない。サービスを適当に分割しただけではシステムはより複雑になり、テストも終わらずにリリースできないコードが溜まっていくことさえあると思う。では具体的にどのようにサービスを分割していくかというと、ドメイン駆動設計の知識が必要になってくる。サービスを実際のビジネス・組織と同じ単位で分割することで、本来の目的であるリリースを頻繁に行えるシステムができる。

米国などではドメイン駆動設計は2003年に登場してからその考え方が普及し、そして今になってドメイン駆動設計をより簡単に実現できるマイクロサービス関連技術が登場してきた経緯があるのだと思う。翻って日本では、ドメイン駆動設計のバックグラウンドなしに、マイクロサービス関連のコンテナやKubernetesなど表面的な技術だけがブームになってきてしまっている気がする。ドメイン駆動設計を理解していない限り、マイクロサービス関連技術を使って、運用者と開発者、ユーザー企業とベンダー企業が幸せになれるようなシステムは作れないのではないかと思う。

ドメイン駆動設計の書籍

ドメイン駆動設計に関する書籍は、エリック・エヴァンスのドメイン駆動設計聖典である。機械学習のPRLMくらいの立ち位置だと思う。

それなりにボリュームがあるので、2,3ヶ月かけて読んでいく予定である。ドメイン駆動設計に関する気付きなどをここにまとめていけたらと思う。

2017年の活動振り返り

新年の抱負の後ですが、一度2017年の活動の振り返りを書いておきます。

tshimba.hatenablog.com

新年の抱負に書いた事以外に、普段の心がけとしてなるべく振り返りを多くしていきたいと思います。

2017 年にやったこと

インプット

IBM Cloud 認定試験

IBM Cloud (当時 Bluemix) の資格取得しました。

AWS 認定試験

AWS の勉強を初め、わかりやすい目標として資格取得を設定し取得しました。

tshimba.hatenablog.com

昨年8月からAWSの勉強を始め、Developer (Associate), Solution Architect (Associate), DevOps (Professional)を取得しました。以前書いたDeveloper以外の試験対策エントリーは今後書く予定です。

Alexa スキル開発

AWS認定試験にはAlexaが入っていないので、別途スキルを作ってみました。

tshimba.hatenablog.com

アウトプット

主な対人でのアウトプットは、社内コミュニティの機械学習勉強会と新入社員研修講師でした。

2018 年の心がけ

インプットばかりに追われて、アウトプットがあまりうまくできていなかったと感じています。インプット後、他の人に共有できるレベルのアウトプットを意識してまとめ・振り返りをしていきたいと思います。

2018年終了時点では、本エントリーと抱負のエントリーをベースに振り返りをします。

Alexa の MP3 を再生するスキル開発・申請から認定結果・フィードバックの受信まで

Alexa のスキル開発から申請までをやってみました。 簡単に開発ができ、アプリを Alexa スキルストアで配布するための申請ができます。

今回は申請してみたところ拒否されたのですが、一緒に丁寧なフィードバックも返ってきました。

Alexa スキルとは

Amazon Echo のような Alexa 対応デバイス向けのアプリのことを Alexa スキルといいます。
スキルの作成方法としては、【保存版】開発部長が102時間かけてまとめたAlexaの落とし穴と習得方法という記事が一番よくまとめられています。

qiita.com

基本的な開発の流れは上記記事を読むのが一番わかりやすいですが、プログラムを書いたことがある人であれば、以下の記事中にある動画を見るだけでだいたいイメージが掴めると思います。

開発の流れとしては、Amazon 開発者ポータルでアプリの基本的な情報を設定します。そこで呼び出し先の Lambda 関数を設定しておき、呼び出し後は指定した Lambda 関数内ロジックに処理が移ります。

Lambda 関数のコーディングが不要でスキル開発が不要な Storyline などのサービスがあるようですが、本エントリーでは対象外です。

今回開発するスキル

今回開発するスキルは Pelco the cat (猫のペルコ) です。
「アレクサ、猫のペルコを開いて」というと猫の鳴き声が流れるというだけのアプリです。
※ペルコに関しては Instagram 参照。

www.instagram.com

スキルの開発

今回のアプリのポイントとしては、MP3 音声ファイルの再生です。
Alexa SSML などで検索すると日本語記事もあるかも知れませんが、今回は Adding MP3 Sound to Alexa という記事を参考にしました。

www.apcp.biz

音声ファイルの準備

音声ファイルのダウンロード

まずは MP3 の音声ファイルを準備します。制約としては、長さが90秒以下ということくらいです。
ポケットサウンドというサイトから、猫の鳴き声の MP3 を複数ダウンロードしました。

音声ファイルを FFmpeg で変換

Alexa で使用できる MP3 の周波数などが細かく決められているので、FFmpeg で指定されている設定に MP3 を変換します。

ffmpeg -y -i input.mp3 -ar 16000 -ab 48k -codec:a libmp3lame -ac 1 output.mp3

FFmpeg は音声変換などで昔からよく使用されているもので、インストールされていない場合はインストールしてください。

音声ファイルを S3 にアップロード

S3 に Bucket を作成して、FFmpeg で変換した MP3 ファイルをアップロードします。このとき、誰でもファイルが閲覧できるようにバケットポリシーやオブジェクトの設定をしておきます。アップロードした各 MP3 の URL は Lambda 関数のコーディング時に使用するためメモしておきます。

開発から申請まで

後は【保存版】開発部長が102時間かけてまとめたAlexaの落とし穴と習得方法に紹介されている記事などを参考に作成していきます。

大まかな流れとしては、

  • Amazon 開発者ポータルでアプリの基本的な情報を設定
  • スキル呼び出し後の処理は、上記で設定した Lambda 関数に実装する
  • Lambda関数を作成時に生成されたARNを開発者ポータルの設定画面で入力する

具体的な手順は、AlexaのHelloWorldに当たる Alexa 豆知識スキルがとてもわかりやすいです。この手順に従い、入力項目を適宜作成するアプリに合わせて変更し申請まで行います。

今回は、言語は English (U.S.) と Japanese だけ作成し、申請時も対象は U.S. と Japan を選択しました。

github.com

テストには、上記で紹介されている echosim.io というシミュレータを使用しました。

Lambda 関数の実装

今回使用した Lambda 関数の実装は GitHub にアップしています。

github.com

申請結果・フィードバック

今回申請した結果スキルの申請を拒否されましたが、同時に丁寧なフィードバックももらえました。

フィードバック内容

主なフィードバックは説明文と実装に関してです。
今回はスキルは起動するだけで終わりなので、3つ入力しなければいけない Example phrase の2,3個目を適当に書いていたのですが、これが正しくないと指摘を受けました。
以下のように指摘をもらえます。

Second example phrase:
Actual example phrase: Alexa, where is Pelco the cat?
Expected example phrase: Alexa, start pelco the cat

Third example phrase:
Actual example phrase: Alexa, tell me Pelco the cat's voice
Expected example phrase: Alexa, launch pelco the cat

Please see our documentation for more information about the words included in our supported launch phrases.
Please also see our blogpost for more guidance on creating example phrases.

Open の他に、Start や Launch でもいいそうです。
また、スキル呼び出し時にホームカードにコード参照が表示される点を指摘されました。

SessionSpeechlet - Pelco meow

SessionSpeechlet -

想定される動作については、申請チェックリストのテストケース3.3を参照してください。

2018年の抱負 - 毎週Outputを出す

今週のお題「2018年の抱負」

今まで新年に立てた抱負を年末まで覚えていたこともなかったのですが、今年はザッカーバーグを見習い、実現可能なレベルに落とし込んだ抱負を立てることにしました。

newspicks.com

2018年の抱負

2018年の抱負は毎週何かしら Output を出すことです。

個人的な抱負決定時のポイントは以下です。

  • 年の途中で達成して終了とならない
  • 継続して価値のあるもの(途中から価値がなくならないもの)

Output展開先

Outputの種類 展開先
How to 的な記事や他ブログの翻訳など Qiita
自身の意見を含む記事 はてなブログ
スライド形式 SlideShare
プログラム GitHub
経歴の更新 WordPress.com

※また、1ヶ月に1回は技術書のまとめを書くことにします。

抱負達成のために必要な行動

副次的に、以下のような行動が必要になってくるはずです。

  • 毎月1冊技術書を読む
  • 今どのようなスキルが求められているのか、いろいろな人や場所から情報収集する
  • 資格勉強の際、他の人に展開できるようにOutputのための情報整理をしておく

1月の技術書

1月に読む予定の予定の技術書は「ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界」です。

2月に AWS のトレーニングプログラムである Big Data on AWS を受講予定なので、1月にその準備を進めていきます。

その他情報整理場所

情報 場所
書籍 ブクログ
ブックマーク はてなブックマーク
Open Badges Acclaim
適当な情報垂れ流し Twitter
ほしい物 Amazon ほしい物リスト

Amazon Echo を米国設定にして Spotify を使用する

Amazon Echo が日本で発売されて1ヶ月ちょっと使用してみましたが、日本の設定だと不便なことがいくつかあり、米国の設定にして使用するようにしました。

日本の設定でできないこと

Skill が少ない

米国では 25,000以上のSkillがあるそうですが、日本ではまだ300程度だそうです。
米国では Jeopardy など楽しそうな公式アプリもたくさんあります。

Spotify が使えない

日本では現在 Amazon Music と dヒッツ のみです。
Amazon Music でもいいのですが、ランダムに再生したときの選曲が微妙だったりします。発売日から数日洋楽ばかりだったのですが、日が経つにつれて日本向けに調整されてきたのか邦楽が出て来る割合が増えてきたように感じます。

ということで、Amazon Echo を米国設定にして Spotify を使用する方法です。
米国設定にしてしまうと、日本向けの Skill やコンテンツなどが使用できなくなるので注意してください。

準備するもの

不要なもの

手順

Spotify アカウントの取得

こちらは作成するのみで何も特別な設定などは不要です。

Amazon.com (US) のアカウントの設定

Amazon.com アカウントで設定している住所を United States にします。 ※既に Amazon.com アカウントを日本住所で使用している方は、住所を変更しても問題ないか気をつけて下さい。

  1. Amazon.com のアカウントを作成してログインしたら、トップページの一番したの方のフッター部にある Manage Your Content and Devices のリンクをクリックします。
  2. Settings タブを開きます
  3. ここで Country Settings で Current Country が United States になっていれば問題ありません。Japan などになっていたら、Change ボタンを押して米国住所を入力します。

これで Amazon.com アカウントの設定は完了です。

Amazon Echo の設定

Amazon Echo の設定をしていきますが、基本的に日本設定で使用するときと同じです。

  1. Alexa app のダウンロード&起動。日本の App Store からで問題ありません。
  2. Alexa app に準備した Amazon.com アカウントでログイン
  3. 言語設定で English (US) を選択

上記以外の設定などはデフォルトやSkipで問題ありません。

Spotify の設定

  1. Alexa app のメニューを開き、Settings > Music & Media を選択
  2. Spotify 右の Link account を選択してログイン
  3. CHOOSE DEFAULT MUSIC SERVICES で Spotify を選択

以上で完了になります。
また、メニューから Skills を選択すると多数のスキルがあることがわかります。

Alexa で Spotify のプレイリストを再生するときは、"Alexa, (on Spotify) play the playlist name playlist." といいます。デフォルトに設定されていれば on Spotify は省略可です。
また、単に "Alexa, play on Spotify" などと言うと、直前に中断したところから続きを再生してくれます。

米国設定にすると、"Alexa, what's in the news?" と言ったときも NHK ではなく Reuters になってくれました。

Amazon Echo で曲が聞けないときに確認すること

Amazon Echo を購入しました。 なぜか Amazon Music のアカウントがうまく認識されず設定が大変だったので、聞けるようになるまでの備忘録です。 アプリの不具合的なところもあるような気がするので、以下の内容は今後改善されると思われます。

Amazon Echo で曲が聞ける Amazon Music のプラン

Amazon Music Unlimited が勧められていますが、Amazon Prime 会員であれば、Prime Music 分の楽曲は Echo からでも聞くことができます。 現時点では Prime Music は 100万曲以上、Amazon Music Unlimited は 4000万曲以上と記載されています。

Amazon Music Unlimited のプランの登録

Amazon Music Unlimited Echo プランに登録

「Alexa, Amazon Music Unlimited に登録」と Echo に向かって言うと、Amazon Music Unlimited に登録されます。
事前に Echo と連携したiOSなどの Alexa アプリから、Voice Purchase をオンにしておく必要があります。
Echo プランでは、Echo 1台のみで音楽の再生ができます。

Amazon Music Unlimited Prime プランに登録

PC などから Amazon Music Unlimited のサイトへアクセスし登録できます。
すでに Echo プランに登録している場合は、Prime プランにアップグレードされます。
Echo プランにダウングレードしたい場合は、Echoに「Alexa、Amazon Music をダウングレードして」と言います。

www.amazon.co.jp

Amazon Echo で音楽が再生できない場合のトラブルシューティング

いろいろ試した結果一番原因らしかったものは Amazon Music アプリが iOSバイス上にインストールされていたことです。
Amazon Music アプリと Amazon Alexa アプリが共存していると、Amazon Music アカウントがうまく認識されていない様に見えます。

  1. Amazon Music アプリをアンインストールします
  2. Echo と Alexa アプリの登録解除・再登録します

qiita.com

上記で Echo で音楽が再生できるようになりました。

この後、Amazon Music  をダウンロードしたところ今度は Amazon Music で音楽が再生できなくなりました。 その為、現時点での不具合で今後改善されると思われます。