Google Kubernetes Engine 上で Spring Boot を動かしてみる

高幡不動のあじさい

先日、珈琲仲間に誘われて高幡不動のあじさいを観に行ってきました。
あいにくの雨でしたが、色んな種類のあじさいが綺麗に咲いていて心が洗われました。

写真の右側のようなあじさいを「がくあじさい」と呼ぶそうです。
これまで中央部分が単に咲いていない(これから開花する)んだと思ってた… (´▽`*)

meet K8s

その内、GCPがAWSのシェアを塗り替えるんじゃないかと思っているのと
DockerやKubernetesとうワードを見かけない日がないので
GCP上でKubernetesを触って理解を深めたいと思います。


2018/8/1 追記
世界的にシェアを見ればAWS、Microsoft、Googleの順なんですね!
Alibabaの勢いもすごい…


Dockerとは

Docker enables true independence between applications and infrastructure and developers and IT ops to unlock their potential and creates a model for better collaboration and innovation.

Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), and start almost instantly.

Docker 社が開発しているコンテナ型の仮想環境を作成/配布/実行するためのプラットフォーム。
「コンテナ」と呼ばれる技術によりホストマシンのカーネルを利用しプロセスを隔離することで、あたかも別のマシン上のように動かすことができる。
ゲスト OS をインストールした上でミドルウェアやライブラリ、アプリケーションを動かすハイパーバイザ型やホスト型の仮想実行環境と比べリソースを効率的に利用できるのが特徴。

開発環境の準備/統一に便利だな〜くらいの認識でしたが、最近は運用にも使われているよう。
まさしく DevOps ですね。

ハイパーバイザ型やホスト型の仮想実行環境を使うことが多いのですが
確かに時間もリソースもかかるので、そこが簡略できるのはとても魅力的。

Kubernetes とは

It has a large, rapidly growing ecosystem.
Kubernetes provides a container-centric management environment. It orchestrates computing, networking, and storage infrastructure on behalf of user workloads. This provides much of the simplicity of Platform as a Service (PaaS) with the flexibility of Infrastructure as a Service (IaaS), and enables portability across infrastructure providers.

コンテナオーケストレーションツールと称される Kubernetes。
コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を行うために用いる。
コンテナオーケストレーションツールは Kubernetes の他に、Docker Swarm や Apache Mesos などがある。

Kubernetes はクラスターが強力なのだそう。
GUI が用意されているし、オートスケーリングやロードバランシング、ヘルスチェック以外で自己修復もしてくれる。

オーケストレーション、賑やかな印象を受けます。

Kubernetes Clusters とは

Kubernetes のアーキテクチャについてはTHENEWSTACKさんの図がわかりやすいです。
#ぱっと見た中では公式サイトのドキュメントから概要図を見つけられませんでした。

a Kubernetes cluster consists of at least one master and multiple compute nodes. The master is responsible for exposing the application program interface (API), scheduling the deployments and managing the overall cluster. Each node runs a container runtime, such as Docker or rkt, along with an agent that communicates with the master. The node also runs additional components for logging, monitoring, service discovery and optional add-ons. Nodes are the workhorses of a Kubernetes cluster. They expose compute, networking and storage resources to applications. Nodes can be virtual machines (VMs) running in a cloud or bare metal servers running within the data center.
A pod is a collection of one or more containers. The pod serves as Kubernetes’ core unit of management. Pods act as the logical boundary for containers sharing the same context and resources. The grouping mechanism of pods make up for the differences between containerization and virtualization by making it possible to run multiple dependent processes together. At runtime, pods can be scaled by creating replica sets, which ensure that the deployment always runs the desired number of pods.

Kubernetes のクラスターは少なくとも 1 つのマスターと複数のノードから構成されており、マスターは API の公開、デプロイのスケジューリング、すべてのクラスタの管理を行います。
各ノードは Docker などのコンテナとマスターと通信するエージェントを実行します。加えて、ロギング、モニタリング、サービス検出やオプションのアドオンなど追加のコンポーネントも実行します。
ポッドは 1 つまたは複数のコンテナをグループ化します。このグループ化におけるメカニズムは、複数の依存プロセスを一緒に実行できるようにすることで、コンテナ化と仮想化の違いを補っています。実行時、ポッドはレプリカセットを作成することでスケールを可能にします。

…大雑把に言えば、マスターの配下にポッド、レプリカセット、サービス等 Kubernetes オブジェクトがありロードバランシングを可能にしてしてくれているんですね。

実際に触ってみる

なんとなく概要をみたところで GCP のチュートリアルにトライします。
書いてあることを実行する中で 2 点エラーが発生したのでそこを中心に明記します。

Dockerizing your application

Creating a Dockerfile

ローカルでビルドした際にはうまくいったのですが、GCP でビルドを行った際に gradlew に権限がないとエラーが発生しました。


そこで実行権限を付与することで対応しました。

1
2
3
4
5
6
7
8
9
10
// Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
RUN mkdir /work
COPY . /work
WORKDIR /work
RUN chmod +x /work/gradlew
RUN /work/gradlew build
RUN mv /work/build/libs/*.jar /work/app.jar
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/.urandom", "-jar", "/work/app.jar"]

Create a cluster

クラスターを作成する際にzoneregionを指定してと言われました。

こちらは--zone=asia-northeast1をつけることで対応。
参照 => gcloud container clusters create

Deploy to the cluster

ポッドをデプロイ、デプロイしたポッドをロードバランシングで公開します。

EXTERNAL-IP に割り当てられたアドレスにアクセス、動作していることが確認できました。

Scaling and updating your application

Set the replica count

レプリカセットの値を 3 から 2 へ変更します。
スケールされていることが確認できました。

まとめ

難しいと思っていた K8s ですが、触るだけなら簡単にできました。GCP のおかげですね!
動かすアプリケーションの規模が小さいこともあり、スケーリングの恩恵はあまり感じられませんでしたが、それでもお手軽さは感じることができました。

クラウド化による Paas、IaaS でもすごいと感じるのに
さらにコンテナ化したものをオーケストレーションする技術まで出てきて
クラウドの技術革新には目を見張ります。

そもそも開発体制として Docker を導入していないので
Kubernetes を業務で扱うことはないだろうけど
社内ツール類をコンテナ化してまとめられたらすっきりしそう。
弊社は(お客様の)鶴の一声がないと新しいツールの導入はまずないので難しいかな…。
少しでも便利に、安定に、なサイクルを模索していきたいところ。

The DevOps ハンドブック、読み始めました。

参考

Share

CS

CSの勉強会に参加しました

先日、CSとプロジェクト進行をテーマにした勉強会に参加してきました。

なんで参加したのか

以前、デザインについての勉強会に参加した際に
「カスタマーサクセス」というワードを初めて知り興味を持ったのと
プロジェクトの進め方について情報を得たかったからです。
ワークショップ形式なので参加者と話しやすいだろうという考えもありました。

CSとは

カスタマーサポートまたはカスタマーサクセスを指します。
最近はカスタマーサクセスと呼ばれていることが増えているようです。
UI → UX のような潮流を感じます。

プ譜

「プロジェクト譜」の略でプ譜には以下の5点を記述します。

  1. 獲得目標
  2. 勝利条件
  3. 廟算八要素(人材、予算、技術、品質、納期、環境、競合、外敵)
  4. 中間目的
  5. 施策

プロジェクトの状態に応じてプ譜を改訂し獲得目標を達成に導くという
まさに「プロジェクトの系譜」となるものです。
PDCAを体系的に表せるなと思いながら聞いていました。

詳しいことは以下を参照してください。

ワークショップ(プ譜作成)

架空のカスタマーサポート課に在籍している体で臨みました。

カスタマーサポート課の背景

1
2
3
4
BtoBの会社で、自社製品のお問い合わせサポート窓口となっている。
使い方などに関してはサポート課で回答し、技術的なことは開発に回答をもらっている。
サポート課からの問い合わせに対し、開発のレスポンスが悪い。
近頃、クレームやクレームに発展しそうな問い合わせが増えてきている。

それに対して作成したプ譜の内容

  1. 獲得目標:お客様の問い合わせを通し、会社にいいサイクルをもたらす起点となる。
  2. 勝利条件:
    1. クレームメールの減少
    2. カスタマーサポート課から製品のユーザビリティ向上に寄与
  3. 廟算八要素
    1. 人材:カスタマーサポート課のメンバー(3名)
    2. 予算:特になし
    3. 技術:タスク管理ツール(Redmineなど)
    4. 品質:基本はメールでのやりとりのみ。場合によって電話有
    5. 納期:順次
    6. 環境:同一社内
    7. 競合:-
    8. 外敵:回答/対応の遅い開発チーム
  4. 中間目的
    1. 対応内容の速度の向上
    2. テンプレートなメールを避ける
      • ↑「いい対応」の共有がカスタマーサポート課内で出来ている
  5. 施策
    1. 開発チームと対面で話す場を設ける
      • 温度感の共有
      • 場合によっては開発チームの部長を巻き込む
    2. 自分がプライベートで問い合わせを行った際によかった対応、不愉快だった対応を共有
      • セミナーへの参加
    3. (場合によっては)開発チームの部長を巻き込んで

#書き起こすにあたって文面をキレイにしましたが大筋はズレていません。
短い時間の割には考えられたんじゃないかと。実行できたら素敵。

発表を聞いていると、獲得目標に目標値を明確に打ち出している人が多かったです。
定量的だと評価しやすいもんね。

モデレータの前田さん曰く、獲得目標は定性/定量的どちらでもOKだけど
定性的なほうが自由がきくと話されていました。

個人的には、獲得目標はブレない根幹となるものを定性的に掲げ、
中間目標や勝利条件を評価しやすい定量的な目標にするのがやりやすいかなと感じました。

プロジェクトの過程が体系的に見て取れるのは面白いし大事だと思う。
根気がいるな…

参考

Share

Windows7でiOS11のsafariをデバッグ

仕事で iOS の safari をデバッグする機会があったので手順を備忘録として残します。

  1. (未インストールの場合) iTunes をダウンロードする
  2. (未インストールの場合) Node.js をインストールする
  3. コマンドプロンプトを管理者権限で起動する
  4. コマンドプロンプト上で npm i -g remotedebug-ios-webkit-adapter を実行
  5. remotedebug-ios-webkit-adapter の zip をダウンロード
  6. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\node_modules\vs-libimobile\ios-webkit-debug-proxy-1.8-win64-binという名前のフォルダを作成
  7. 6 で作成したフォルダの中に zip の中身を展開
  8. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\out\adapters\にあるiosAdapter.jsファイルの 132 行目あたりのconst proxy=...を以下の値に修正
1
2
3
4
const proxy = path.resolve(
__dirname,
"../../node_modules/vs-libimobile/ios-webkit-debug-proxy-1.8-win64-bin/ios_webkit_debug_proxy.exe"
);
  1. 確認したいデバイス(iPad など)を接続
  2. コマンドプロンプト上でremotedebug_ios_webkit_adapter --port=9000を実行
  3. Chrome を開き、アドレスバーにchrome://inspect/#devicesと入力
  4. 設定を開き、localhost:9000を追加
  5. 確認したいデバイスの safari の設定(設定 > Safari > 詳細)の
    「Web インスペクタ」を有効化
  6. safari でデバッグしたい url を開く
  7. Chrome の Remote Target に safari で開いた url が表示されるので inspect をクリック
  8. 表出したウィンドウでデバッグ

ブラウザ間の挙動の違いには、いつも泣かされます。。。

参考

Debug a Website in iOS Safari on Windows 10

Share