腐女子エンジニアの日記

創作と技術と時々音楽

自宅PC(mac)にminishiftをインストールする

背景 

  • Openshiftを触る機会があったので、自宅でもいろいろ試したいと思いました。
  • ただ、Openshift構築のハードルがやや高かったので、せっかくだしminishiftをインストールしようと思いました。

前提

  • Homebrewが利用できること
  • virtualboxがインストールされていないこと

手順概要

基本的にはokdのサイトを参考に手順通り進めていきます。 (詰まった時の文献があまりないのでちょっと辛かったです。)

1. インストールのための準備をする

docs.okd.io

# xhyve 0.4.0のバージョンの不具合を踏んだので意図的に別バージョンをインストール
$ brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/7310c563d662ddbe094f46f9600cad30ad3551a6/Formula/docker-machine-driver-xhyve.rb
$ sudo chown root:wheel /usr/local/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ sudo chmod u+s /usr/local/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

2. minishiftをインストールする

docs.okd.io

$ brew cask install minishift

3. minishiftを起動する

docs.okd.io

$ minishift start
# ocコマンドのパスを通す
$ minishift oc-env
$ export PATH="/Users/(user名)/.minishift/cache/oc/v3.11.0/darwin:$PATH"

感想

  • ドライバ周りで詰まって時間がかかったのが辛かった
  • minishift自体はその後問題なく動作していますが、起動しっぱなしだとめちゃくちゃリソースを食うので現在は使うときだけ起動するようにしています。

参考にしたサイト

  • 詰まった時に見たもの(同様のエラーを踏みました) qiita.com

メモ

  • インストール時はhyperkitとdocker-machine-driver-xhyveを両方インストールしてしまったけど、マニュアルをみる感じどっちかで良かったのかもしれない

Microsoft Ignite The Tour Tokyoに行ってきました

Microsoft Ignite Tour The Tokyoに行ってきました! 人が多く、講演の待機列でじっとしていた時間が長かったので、 会場を回りきれなかったのがちょっと残念。

受講していて面白かったものを2つ紹介します。

Azure Kubernetes Service を活用したマイクロサービス開発

マイクロサービス開発に関して、Kubernetesはあくまでも手段の一つ

  • 頻繁にリリースがあるアプリか?/どんどん機能追加があるようなものか?
    • だったらKubernetesのほうがいい
    • 規模が小さければサーバレス等ほかの選択肢もある

AKSの強み

  • マネージドなKubernetesが提供できる
  • master nodeが見えない
  • 障害時の対応: アンチフラジャイル(つまり、止まったものを直すんじゃなくて、あたらしいものをたてればいいじゃん!の考え)で運用をやるとキツい
  • 監視

マイクロサービス開発のベストプラクティス

少なくとも下記は必要だろうとのこと。 - Azure Container Registry - Azure Devops - AKS(環境分)

1. Helmでマイクロサービスの構成を管理する

2. 外部向けエンドポイントはNginx ingress controllerを使う

  • リバプロ的な役割
  • Helm Chartsに書ける!
    • AKSでも似たような機能が提供されてるけど、内部が違うのと、非推奨なので使わない

3. アップグレード戦略にはBlue/Greenデプロイを採用する

  • labelSelectorのバージョンを変更してアクセスできるpodを変更する
  • Kubernetes culusterのアップグレード
    • ボタンぽちってやるだけでできるけど怖い!どこまで担保する?
    • 新しいバージョンのAKSを立てて、アクセス振り分けるGWを設けると良い
  • pvとかpvcを作らず、外部にデータを保存するとこでアンチフラジャイルを実現する

4. PodとNodeのスケーリングを組み合わせて構成する

  • Horizontar Pod Scaler
  • cluster autoscaler : nodeのリソースがいっぱいでデプロイがpendingになったことを検知して勝手に新しいnodeを立ててくれる!

5. 障害を前提として構成を決める

  • Nodeの数は余裕を持たせる
  • 可用性 : vmssの可用性セットによって担保
  • pod: liveness/readness

6. Azure Monitorでマイクロサービスを監視する

  • メトリクスをLog Analyticsに送信

難しいからこそ、シンプルに使う

感想

  • 絵を描いての説明があったり、わかりやすかった!
  • 講演中に何回か出てきた"アンチフラジャイル"というワードはこの書籍を読むとわかるみたいです(日本語版だと反脆弱性)

Azure Functions を理解する

Serverless概要

  • サーバがないわけではない
  • サーバを意識しなくて良い

Azure Serverless Platform Component

  • Power Automate
  • Logic apps → コードをあんまり書かないやつ
    • iftttみたいなイメージ。
    • ワークフローを自作するというかそんな感じ
  • Functions

Azure Functionとは

  • コード+イベントで作成できる。
  • APIでリクエストを受けて、処理を実行するようなものを記述できる。

  • Logic AppsからAzure Functionを選択できるため、色々な組み合わせができる!

  • VS Code拡張機能があり、Azure Functionのデバッグがローカルホストで実行可能になった。

資料

資料はここにあります。

感想

  • デモが多くて面白かったのに、夢中すぎてメモをとるのを忘れました。。。
  • FaaS楽しそう!
  • 個人的に開発のハードルが低そうなのでいじり倒したいなと思いました。

まとめ

  • 初参加のイベントだったんですけどめちゃくちゃ楽しかったです!
  • 待機列だけは本当にしんどかったので次行くときは待機列用の暇つぶしを考えようと思いました。

余談

  • 帰りにみた東京タワーが綺麗でした。

f:id:dcn_f:20191208011904j:plain

Developer Boost 2019に行ってきました

30歳を迎える前に一度は行ってみたかったデブストに行ってきました。

場所は池袋サンシャインシティの上の会議室だったのですが、ちょっと迷いました。

f:id:dcn_f:20191202231941j:plain
入り口のやつ

講演メモ

いくつかおもしろかった講演をピックアップします。

オープンな技術力の伸ばし方

本業、OSSの活動、副業の3つの軸に関してのお話でした。 (メモ取ってたら軸の境目がわからなくなった)

本業

CaaS基盤開発プロジェクト Kubernetes vs docker swarm どっちかが消えるかも…の時代

  • どうやって技術選定するか?

    1. 要件を満たせるか
    2. 将来性があるか(コミュニティの雰囲気、オープンな開発の場の雰囲気)
  • OSSの醍醐味

    1. コードがオープンなこと
    2. 機能拡張や連携のしやすさ
    3. 不具合の調査がしやすい
    4. 新しい技術が多く生まれる(→追って行かなきゃいけない…)
  • カンファレンスに行って良かったこと

    • 勉強会に行っても、特定技術をやってる人って少ない
    • カンファレンスの方が技術的に尖った人が多い
    • どのOSSを選択すればいいかはカンファレンスの雰囲気とかでわかる(参加人数、熱量)
  • OSSはコミュニティのContributionによって成り立っている。

    • Contributionは高度でもなくてもよい。
    • 最初はnon-codeのやつでもいいのではないか。 (例えばブログのアウトプット、カンファレンスやミートアップの主催、交流会etc)
  • コミュニティ活動はだんだん大きくなってカンファレンスになる

    • カンファレンスだと、「どういう情報を波及させたいか」とか考えてみる、たのしい
  • 何かしらのアウトプットをしよう

  • コミュニティが広がる
  • ブログをやれ(PV数少なくても続けることが大事)

副業(ここではパラレルキャリアとしていた)

  • 転職しなくても履歴書、ポートフォリオは作っておくといい

  • メリット

    • 新しい技術領域の挑戦が可能
    • 目先の評価にとらわれなくなる
  • パラレルキャリア・副業向いてる人

    • 本業をちゃんとやってる
    • プライベートな時間をあててもいいかなってひと
    • 本業の制約から解放されたい人

感想

  • 交流会を主催することで話しかけてもらえる!ていうのは盲点でした笑
  • これを機会にOSSのコミュニティにもっと関わっていきたいなと思いました。

個人的に一番心に残ったこと : ブログをやる(続けていくことが大事)

20代でマネジメントにチャレンジするということ

  1. キャリア戦略としてのマネジメントの位置付け
  2. マネジメントのリアル
  3. 困難の乗り越え方 についてのお話でした。

1. キャリア戦略としてのマネジメントの位置付け

  • 技術的な責任を負う

    • 一番わかりやすいのはCTOという肩書き
    • 技術的にめちゃ強いからCTO と言うわけではなく、経営メンバーの中から技術面の責任を持つ
  • テックリード、マネージャー、スクラムマスター

    • マネジメントの立ち位置 複数のチームに対して支援をし、「全体最適」で成果に導く
    • マネージャーはチームをより俯瞰的に見てる
    • 全員とコミュニケーションするし責任を持つ
    • 若いうちにやっておくと、フィードバックが集まりやすいしいっぱい失敗できる

2. マネジメントのリアル

  • 批判を割り切る
  • 課題を解決できなかったら(解決しても)離れていく人がいる

    • あらかじめ退職を見込んでおく(シビアだった)
  • ネガティブフィードバック

    • 敢えて言わなきゃいけない場面もある……
  • 面白さ

    • 組織に変化が起こせてると感じること -「組織もエンジニアリングすべし」
  • マネージャのエンジニア的解釈 → 組織のアーキテクト(かっこいい)

3. 課題の乗り越え方

  • 対話が基本

  • そもそもどうやったら若いうちにマネージャになれるの?

  • 組織の問題解決に慣れる価値 : どこにでも起こりうる人の問題に対応できる

この辺の書籍を紹介されていました。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

感想

  • マネジメントに関しては正直若くして関われなさそうだな、、、というのが自身の印象でした。
  • とはいえ、数年後には直面しそうな問題でもあり、面白そうな題材だなと思うので、いつでも挑戦できるように書籍を読んだり周りの人を見たりしながら学びたいと思いました。

CloudNativeな監視とは?

  • Cloud Native とは?

  • 今回は「マイクロサービス」にフォーカス

  • マイクロサービスと従来のオペレーションの違い

    • 従来のサービス→Web3層モデル 簡単にトラブルシューティングできる
    • マイクロサービス→小さなサービスが多数あって1つのサービフになってる 複雑
  • 可観測性(オブザーバビリティ)

    • 監視の観点で重要 様々なシステムやアプリケーションを観測しましょう
    • 可観測性とは人によって意味が異なる
  • 目的

    1. モニタリング: 今まで見えなかった障害に対するアプローチ
    2. アナリティクス
  • モニタリングだけじゃダメ?

    • 今までのモニタリングは「(想定された)障害のためのアラート」
    • 分散システムでは、どんな障害が起こるか予測不可能
    • 障害が起こってもなんで起こったかわからない
    • 後からデバッグするために、すべてのものを監視する
  • サービスの正常性を確認するためのTesting

    • テレメトリー→オブザーバビリティを実現するツールに求められる要素
  • オブザーバビリティ≠テレメトリー

  • (あくまでもいまの)主要素

    1. メトリクス
      • メリット:統計的に集計を行える
      • 注意点: 単一のメトリクス見ただけじゃなんもわからん
    2. ロギング
    3. トレーシング
  • テレメトリーの課題

感想

  • 連続でエモい話聞いてたので、いきなり技術の話がきてかなり面白かったです。
  • この本が紹介されていた。欲しい。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

(今回紹介できなかった別セッションでも紹介されていた。でも積ん読が。。。)

全体として

  • 全体的には技術よりメンタルやキャリアパス的なお話が多かったです。(選んだものにもよると思います)
  • そのため、普段のフォーラムで聞けないような話が聞けて、面白かったです。
  • また、同年代でこんなにキラキラ(?)した人たちがいるのか、と刺激になりました。

余談

お昼はここに行ってきました。

f:id:dcn_f:20191202231948j:plain

夕方はカフェでシフォンケーキを食べました。

食べてばっかり。いい池袋でした。

Red Hat Forum Tokyo 2019に行ってきました

午後から参加しました。

f:id:dcn_f:20191115212417j:plain
入り口の様子

インターコンチネンタル赤坂は初めて行ったのでちょっと迷いました。 お水は飲み放題だったのが嬉しかったです。

昨年はAnsibleが多かったのですが、今年KubernetesやOpenShiftが多かったですね。 時間の流れを感じます。

特に印象に残ったセッションを紹介します。

Ansible 利用その一歩先へ - Ansible Tower の使い方徹底解説!

メインの話題は下記の通りでした。

  • Ansible Tower概要紹介
  • Ansible Tower 3.6系の新機能紹介

概要は話半分に聞いてましたが、 「Ansibleはあくまで課題解決の手段であって、Ansibleを使うことを目的としてはいけない」というのは自戒としたいと思いました。

Ansible Towerではtower-cliが使えると言うことと、TowerのカスタマイズをAnsibleを使って実現するってところが面白かったです。 結局はコマンドラインが最強なのか。

下記の写真はCIでJenkinsを使ってるのが面白いなと思って使いました。

f:id:dcn_f:20191115212421j:plain
Ansibleの構成例

個人的にはAnsible Tower 3.6系の新機能紹介が面白かったです。早く使ってみたい!

f:id:dcn_f:20191115212434j:plainf:id:dcn_f:20191115212427j:plain
新機能たち。通知のカスタマイズ機能がアツい

The world after Kubernetes Native -コンテナが日常化した世界-

Kubernetesの移行の話

  1. ターゲットアプリケーションを選定
  2. どのPlatform(のKubernetes)を使いたいか
  3. Kubernetes運用したい?という問いかけ。
  4. 成功基準を計画する
  5. どうしてコンテナを使いたいの?
  6. 本当にやりたいことを達成できている?やりたいことって?
  7. 企業文化との整合性を得る

技術はキャッチアップすればなんとかなるけど、企業文化はどうすることもできない。と言う話が印象的でした。

Kubernetes Nativeな世界とは

どの環境でも同じようにデプロイできる、環境を意識しない → アプリケーションエンジニアだけでなく、インフラエンジニアも環境の標準化(SRE or Mansged) → 環境の差異を意識しない世界を実現しないといけない

Openshiftも同様である、と言うことでした。

Resource Operator(多様化するリソース管理)

コンテナやKubernetesを個別に運用する時代は終わる これからステートフルなアプリケーションを運用できるようにするには、自身が運用のスキルを持っている必要がある。

Operatorを使用してアプリケーションの運用を自動化する。(運用業務の自動化) コンテナの中では自動で運用をすることが目標

運用管理をいかにOperatorに乗っけていくか

OpenShiftのこれから

  • Operatorを基軸としてエコシステムを作っていく

OpenShift.run 行きます!!

と言うことでした。Tech Nightは行けなかったけど、楽しい1日になりました!!

おまけ

AnsibleのブースでAnsible Towerについてお話を伺ってたら大量に冊子をいただきました。 社内の布教用に使わせていただきます。

f:id:dcn_f:20191115222823j:plain
大量の冊子

活動記録(11/11)

12月の原稿間に合わない気がする辛い。

余談ですが、私の場合、原稿を作るときは

  1. ネーム
  2. 下書き
  3. コマ割り
  4. セリフ入れ
  5. 線画
  6. トーン
  7. 仕上げ

の順で行います。 他の人がどんな順序で原稿やってるのか知りたい。

今日の作業はこんな感じでした。

  • カテゴリ: 創作活動
  • 作業時間: 1時間半
  • 作業内容: 下書き 1P

全然進んでないのでメンタルにくるけど、平日で1時間半趣味の時間が取れたのは収穫です。

目標とか、そういうの

目標を立てるには微妙な時期だけど、思い立ったが吉日なので書いていきます。

カテゴリ

頑張っていきたいカテゴリはこんな感じです。

趣味

趣味人間です。趣味も色々あります。ここでは主に下記について取り扱います。

  • 創作活動
  • 音楽活動(フルート)
  • 読書

仕事

前は趣味のための金稼ぎの手段くらいに捉えてましたが、せっかく1日の1/3くらいを使ってるわけだしちゃんとやりたい。

  • 仕事
  • 勉強

勉強には、業務分野とちょっと外れたところも含めます。

特に伸ばしたい分野

  • 創作活動

たくさんアウトプットをできるようにしたいです。 また、背景を描けるようになりたいです。

学習には下記を使用したいと思います。

https://sensei.pixiv.net/

  • 勉強

密かに(?)SRE的な領域に興味を持っています。 ソフトウェアのレイヤの知識がまるで無いので業務外の勉強で補います。

また下記の本を読みSREとはなんぞやを理解します。

https://honto.jp/netstore/pd-book_28545550.html

最後に

自身の性質上、何か他の事を見つけると見える事全部に中途半端に手をつけてしまうので、当面は以上に注力するよう宣言します。

このブログについて

目的

下記2点を目的としています。

  • 自身のキャリアを見つめ直すこと
  • やりたいこと、やらないことを見定めること

方針

  • とりあえずちょっと先の目標をまとめたいとおもいます
  • 達成するためにやったことを発信していきます

スマホでぽちぽちかけるので、寝る前に書きたい。

ということでよろしくお願いします。