Rustでicedを試してみた
この記事はアドベントカレンダー2021 Rust 18日目の記事です。
はじめに
皆さんこんにちは。寒いですね。
早いもので今年もあと少し、最後まで気を引き締めて行きましょう。
ここでは、RustのGUIライブラリであるicedを使ってGUIツールを作ったという、
紹介記事を書くつもりでしたが、諸般の都合で手がつけれず・・・。
icedのサンプルを動かすところまでになります。
環境
OS: Windows 10
rustc 1.56.0 (09c42c458 2021-10-18)
cargo 1.56.0 (4ed5d137b 2021-10-04)
iced
RustでGUIツールが簡単に作れるOSSです。
他の人が紹介している記事が沢山あるので、ここでは割愛します。
サンプルを動かしてみる
githubにサンプルが沢山あるので、その中のeventsを動かしてみます。
cargo new コマンドで適当にプロジェクトを作った後、cargo.tomlに以下を追記します。
[dependencies] iced = "0.3" iced_native = "0.4"
その後、main.rsを以下とします。
use iced::{ button, executor, Align, Application, Button, Checkbox, Clipboard, Column, Command, Container, Element, HorizontalAlignment, Length, Settings, Subscription, Text, }; use iced_native::{window, Event}; pub fn main() -> iced::Result { Events::run(Settings { exit_on_close_request: false, ..Settings::default() }) } #[derive(Debug, Default)] struct Events { last: Vec<iced_native::Event>, enabled: bool, exit: button::State, should_exit: bool, } #[derive(Debug, Clone)] enum Message { EventOccurred(iced_native::Event), Toggled(bool), Exit, } impl Application for Events { type Executor = executor::Default; type Message = Message; type Flags = (); fn new(_flags: ()) -> (Events, Command<Message>) { (Events::default(), Command::none()) } fn title(&self) -> String { String::from("Events - Iced") } // fn update(&mut self, message: Message) -> Command<Message> { fn update(&mut self, message: Message, _clip: &mut Clipboard) -> Command<Message> { match message { Message::EventOccurred(event) if self.enabled => { self.last.push(event); if self.last.len() > 5 { let _ = self.last.remove(0); } } Message::EventOccurred(event) => { if let Event::Window(window::Event::CloseRequested) = event { self.should_exit = true; } } Message::Toggled(enabled) => { self.enabled = enabled; } Message::Exit => { self.should_exit = true; } }; Command::none() } fn subscription(&self) -> Subscription<Message> { iced_native::subscription::events().map(Message::EventOccurred) } fn should_exit(&self) -> bool { self.should_exit } fn view(&mut self) -> Element<Message> { let events = self.last.iter().fold( Column::new().spacing(10), |column, event| { column.push(Text::new(format!("{:?}", event)).size(40)) }, ); let toggle = Checkbox::new( self.enabled, "Listen to runtime events", Message::Toggled, ); let exit = Button::new( &mut self.exit, Text::new("Exit") .width(Length::Fill) // .horizontal_alignment(alignment::Horizontal::Center), .horizontal_alignment(HorizontalAlignment::Center), ) .width(Length::Units(100)) .padding(10) .on_press(Message::Exit); let content = Column::new() // .align_items(Alignment::Center) .align_items(Align::Center) .spacing(20) .push(events) .push(toggle) .push(exit); Container::new(content) .width(Length::Fill) .height(Length::Fill) .center_x() .center_y() .into() } }
コメントアウトした部分はサンプルが古くエラーとなっていましたので、書き換えています。
あとは、cargo runを実行すれば動くはずです。
簡単ですね。
これを使って、冬休みにgrepアプリでも作って見ようと思います。
obsidian.mdのテーマを作った
気がつけばもう5月ですね。
仕事も一段落つきゆっくりとGWを満喫しました。
連休中に色々勉強しようと思っていたんですが、たいして出来ず・・・。
せめてブログだけでも更新します。
obsidian.md
この手のノートアプリに興味がある人なら知っていると思いますが、obsidian.mdというアプリを最近使ってます。
個人的にはdynalistが好きなんですが、dynalistはクラウドと同期するので仕事では使えません。 その点、obsidianは全てローカル保存なので、セキュリティを気にせず使うことが出来ます。
ということで、使っていたんですがテーマがいまいちピンと来なかったので、自分で作ってみました。
obsidian-sakura
obsidian-sakuraというテーマを作りました。
その名の通り桜をイメージして、ピンク色を中心に配色しています。
実はこれ、dynalistでも同じテーマがあって、それがとても良かったのでobsidianでも使いたいと思ったので自作してみました。
よければ使ってみてください。
近況報告
ここ最近は仕事が数年ぶりに忙しく、ブログを更新している時間が取れませんでした。
(というか、精神的な余裕がなかったです)
なので、去年目標にしていた「毎週ブログを更新する」が残念ながら達成出来ませんでした・・・。
2月いっぱいくらいはまだまだ忙しそうですが、3月くらいから再開していきたいと思ってます!!
散財
忙しいながら、デスク周りの環境を更に良くしようと幾つか買い足したものがあるので紹介。
ウルトラワイドディスプレイ
これ、買いました。 www.amazon.co.jp
率直に言って作業効率が2,3倍になった気がします。
最高です!
キーボード
前からずーっと分離キーボードが欲しかったんですが、ついに購入しました!
これ親指のところの高さを調節出来るようになっていて、自分の好きな高さで固定出来るようになってます。
それによって、より楽な状態でタイピングすることが出来るんです。
親指も有効活用できますし、こちらも最高です。
ただこの先には、キー配置沼という深い深い沼が広がっており、今なお最適な配列を模索中です。
GoでActor Model入門(Proto.Actor)
はじめに
皆さんにゃっはろー。お元気ですか?
最近ホロライブにハマっているyanomです。最近のイチオシはぺこーらです!
可愛いので皆さんもぜひ見てみてください!
っと、全然脈絡はないですが、一応この記事はGo 3 Advent Calendar 2020 13日目の記事です。
Akka
最近仕事では、JavaでAkkaを使って非同期メッセージパッシングを使ったシステムを開発していたりします。Akkaは本当によくできており手軽に使う事ができるのでおすすめです。
ただ、今回はGoのアドベントカレンダーということで、GoでAkkaっぽいことができないか探していたところ、Proto.Actorというライブラリを見つけたので、簡単に入門をやってみました。
Proto.Actor
Akka.Netの開発メンバだった方が、開発しているということで使い方はかなり似ています。
また、言語はGoの他にC#版もあるみたいです。
(GoのチャネルとActorについての違いについてはここに詳しく書いてあります。)
Hallo Proto.Actor
まずはチュートリアルから。
環境構築などは、gitに書いてあるのでそちらを参照してください。
type Hello struct{ Who string } type HelloActor struct{} func (state *HelloActor) Receive(context actor.Context) { switch msg := context.Message().(type) { case Hello: fmt.Printf("Hello %v\n", msg.Who) } } func main() { context := actor.EmptyRootContext props := actor.PropsFromProducer(func() actor.Actor { return &HelloActor{} }) pid, err := context.Spawn(props) if err != nil { panic(err) } context.Send(pid, Hello{Who: "Roger"}) console.ReadLine() }
実行すると、こんな感じでHelloActorに対して、Rogerというメッセージが送信されていることがわかります。
yanom@DESKTOP-0VPGPUH:~/go/src/proto-actor$ ./proto-actor Hello Roger
backpressure
Actorモデルでは各Actorがmailboxを持っており、Actorはそこからひとつずつメッセージを取り出して処理を実行しています。
Proto.Actorではそのmailboxに振る舞いを簡単に定義できるようになっています。
これを使ってバックプレッシャーを実現することが可能となっています。
package main import ( "log" "sync/atomic" "time" console "github.com/AsynkronIT/goconsole" "github.com/AsynkronIT/protoactor-go/actor" "github.com/AsynkronIT/protoactor-go/mailbox" ) // sent to producer to request more work type requestMoreWork struct { items int } type requestWorkBehavior struct { tokens int64 producer *actor.PID } func (m *requestWorkBehavior) MailboxStarted() { log.Println("mailboxstarted...") m.requestMore() } func (m *requestWorkBehavior) MessagePosted(msg interface{}) { log.Println("posted...") } func (m *requestWorkBehavior) MessageReceived(msg interface{}) { log.Println("messagereceived...") atomic.AddInt64(&m.tokens, -1) if m.tokens == 0 { m.requestMore() } } func (m *requestWorkBehavior) MailboxEmpty() { log.Println("empty...") } func (m *requestWorkBehavior) requestMore() { log.Println("Requesting more tokens") m.tokens = 5 system.Root.Send(m.producer, &requestMoreWork{items: 5}) } type producer struct { requestedWork int producedWork int worker *actor.PID } func (p *producer) Receive(ctx actor.Context) { switch msg := ctx.Message().(type) { case *actor.Started: log.Println("started...") // spawn our worker workerProps := actor.PropsFromProducer(func() actor.Actor { return &worker{} }) mb := mailbox.Unbounded(&requestWorkBehavior{ producer: ctx.Self(), }) p.worker = ctx.Spawn(workerProps.WithMailbox(mb)) case *requestMoreWork: p.requestedWork += msg.items log.Println("Producer got a new work request") ctx.Send(ctx.Self(), &produce{}) case *produce: // produce more work log.Println("Producer is producing work") p.producedWork++ ctx.Send(p.worker, &work{p.producedWork}) // decrease our workload and tell ourselves to produce more work if p.requestedWork > 0 { log.Println("send produce") p.requestedWork-- ctx.Send(ctx.Self(), &produce{}) } } } type produce struct{} type worker struct{} func (w *worker) Receive(ctx actor.Context) { switch msg := ctx.Message().(type) { case *work: log.Printf("Worker is working %+v", msg) time.Sleep(100 * time.Millisecond) } } type work struct { id int } var system = actor.NewActorSystem() func main() { producerProps := actor.PropsFromProducer(func() actor.Actor { return &producer{} }) system.Root.Spawn(producerProps) _, _ = console.ReadLine() }
実行してみるとわかりますが、workerが一定数処理を終わるまで、producerは次の処理を投げないように制御できていることが分かります。
他にも色々サンプルが揃っているので興味がある方はぜひ覗いてみてください。
まとめ
非同期メッセージパッシングが簡単にできるようになるProto.Actorを紹介しました。
Go版はまだベータ版ということで変わる可能性がありますが、その手軽さはAkka以上だと感じました。
また、実際の開発では考慮が必要になるであろう、バックプレッシャーについても手軽に実現できるようになっているので、そこも素晴らしいと思います。今後も色々遊んでみたいと思います。
あと、久しぶりにGoを書きましたが、やっぱり最高です!
実践テスト駆動開発 を読んでる
ちょっと、仕事が忙しくて更新できてませんでしたが、今は実践テスト駆動開発を読んでいます。
まだ、半分くらいなので、また読んだら感想を追記します。
目次
第1章 テスト駆動開発のポイントとは? 第2章 オブジェクトをテスト駆動開発する 第3章 ツール紹介 第4章 テスト駆動のサイクルに火を入れる 第5章 テスト駆動のサイクルを保つ 第6章 オブジェクト指向スタイル 第7章 オブジェクト指向設計を実現する 第8章 サードパーティーコードの上に構築する 第9章 オークションスナイパーを作動させる 第10章 動くスケルトン 第11章 最初のテストを通す 第12章 入札を準備する 第13章 スナイパーが入札する 第14章 スナイパーがオークションで落札する 第15章 実際のユーザインタフェースに向けて 第16章 複数の商品をスナイプする 第17章 Mainクラスを分解する 第18章 詳細を詰める 第19章 エラー処理 第20章 テストの声を聴く 第21章 テストの可読性 第22章 複雑なテストデータの構築 第23章 テストの診断 第24章 テストの柔軟性 第25章 永続性のテスト 第26章 ユニットテストとスレッド 第27章 非同期処理のテスト 第28章 ティム・マキノンによるモックオブジェクトの簡単な歴史
Kubernetesで実践するクラウドネイティブDevOps を読んでいる
夏休みのお供にと思い、Kubernetesで実践するクラウドネイティブDevOpsを読んでいます。
今12章なので、また読み終わったら感想を追記します。
これまで、読み進めている感じ、k8sのことが環境構築からCICD、オブザーバビリティやhelm等の周辺ツールまで網羅的に書かれており、
k8sを使っている方には必携の内容になっていると思います。
また、監訳者の注釈も随所に入っておりわかりやすい内容となっています。
対象読者としては、ある程度k8sを触ったことがある人向けです。
2020/08/28 追記
一通り読んだので、感想です。
まず冒頭でも書いてますが、k8sを本番環境で使っている、あるいはこれから使う予定がある人は一読することをおすすめします。
目次の通り、網羅的に書いてある本なので、何かあったときに辞書のようにも使えます。
個人的には15章、16章が良かったです。アプリケーション/リソースの監視についてどういうことを気にしておくべきか、k8sでどのように仕組みを取り入れるのか書かれていてためになりました。詳細は別の書籍を読むことになりますが、導入としては十分だと思います。
興味がある方は是非読んでみてください。
目次
1章 クラウドでの革命 1.1 クラウドの創造 1.1.1 時間を買う 1.1.2 Infrastructure as a Service 1.2 DevOpsの黎明 1.2.1 DevOpsに対する無理解 1.2.2 ビジネスにとってのメリット 1.2.3 Infrastructure as Code 1.2.4 ともに学ぶ 1.3 コンテナの到来 1.3.1 これまでの状況 1.3.2 常識を打ち破った箱 1.3.3 ソフトウェアのコンテナへの格納 1.3.4 プラグ&プレイ型アプリケーション 1.4 コンテナのオーケストラを指揮する 1.5 Kubernetes 1.5.1 Borgから Kubernetesへ 1.5.2 Kubernetesが高い価値を誇る理由 1.5.3 Kubernetesもいずれ消え去るのか 1.5.4 Kubernetesは万能ではない 1.6 クラウドネイティブ 1.7 運用の将来 1.7.1 分散型の DevOps 1.7.2 集中管理が残る領域 1.7.3 開発者生産性工学 1.7.4 皆さんこそが将来 1.8 まとめ 2章 Kubernetes最初の一歩 2.1 最初のコンテナの実行 2.1.1 Docker Desktopのインストール 2.1.2 Dockerの概要 2.1.3 コンテナイメージの実行 2.2 デモアプリケーション 2.2.1 ソースコードの内容 2.2.2 Goについて 2.2.3 デモアプリケーションが動作する仕組み 2.3 コンテナのビルド 2.3.1 Dockerfileの理解 2.3.2 最小限のコンテナイメージ 2.3.3 docker image buildの実行 2.3.4 イメージの命名 2.3.5 ポート転送 2.4 コンテナレジストリ 2.4.1 レジストリの認証 2.4.2 イメージの命名とプッシュ 2.4.3 イメージの実行 2.5 ようこそ Kubernetesへ 2.5.1 デモアプリケーションの実行 2.5.2 コンテナが起動しない場合 2.6 Minikube 2.7 まとめ 3章 Kubernetes環境の選択 3.1 クラスタのアーキテクチャ 3.1.1 コントロールプレーン 3.1.2 ノードのコンポーネント 3.1.3 高可用性 3.2 セルフホスティング型 Kubernetesのコスト 3.2.1 想像以上に面倒な作業 3.2.2 初期セットアップだけの問題ではない 3.2.3 痒いところに手が届くわけではないツール 3.2.4 Kubernetesは難しい 3.2.5 管理のオーバヘッド 3.2.6 まずはマネージドサービスから 3.3 マネージド Kubernetesサービス 3.3.1 Google Kubernetes Engine(GKE) 3.3.2 クラスタのオートスケール 3.3.3 Amazon Elastic Container Service for Kubernetes(EKS) 3.3.4 Azure Kubernetes Service(AKS) 3.3.5 OpenShift 3.3.6 IBM Cloud Kubernetes Service 3.3.7 Heptio Kubernetes Subscription(HKS) 3.4 ターンキー方式の Kubernetesソリューション 3.4.1 Stackpoint.io 3.4.2 Containership Kubernetes Engine(CKE) 3.5 Kubernetesインストーラ 3.5.1 kops 3.5.2 Kubespray 3.5.3 TK8 3.5.4 Kubernetes The Hard Way 3.5.5 kubeadm 3.5.6 Tarmak 3.5.7 Rancher Kubernetes Engine(RKE) 3.5.8 Puppet Kubernetesモジュール 3.5.9 Kubeformation 3.6 購入か構築か:本書の推奨事項 3.6.1 実行するソフトウェアを減らす 3.6.2 可能ならマネージド Kubernetesを使用 3.6.3 ベンダロックインの問題 3.6.4 どうしても必要なら標準の Kubernetesセルフホスティングツールを使用 3.6.5 選択肢が限られる場合 3.6.6 ベアメタルとオンプレミス 3.7 クラスタレスのコンテナサービス 3.7.1 Amazon Fargate 3.7.2 Azure Container Instances(ACI) 3.8 まとめ 4章 Kubernetesオブジェクトの基本操作 4.1 Deployment 4.1.1 スーパバイズ機能とスケジューリング 4.1.2 コンテナの再起動 4.1.3 Deployment情報の取得 4.2 Pod 4.3 ReplicaSet 4.4 望ましい状態の維持 4.5 Kubernetesスケジューラ 4.6 YAML形式のリソースマニフェスト 4.6.1 リソースがデータ 4.6.2 Deploymentマニフェスト 4.6.3 kubectl applyの使用 4.6.4 Serviceリソース 4.6.5 kubectlを用いたクラスタへのクエリ 4.6.6 リソース管理の次の段階 4.7 Helm:Kubernetesパッケージマネージャ 4.7.1 Helmのインストール 4.7.2 Helmチャートのインストール 4.7.3 チャート、リポジトリ、リリース 4.7.4 Helmリリースのリスト表示 4.8 まとめ 5章 リソースの管理 5.1 リソースの理解 5.1.1 リソースの単位 5.1.2 リソース要求 5.1.3 リソース制限 5.1.4 コンテナは小さく保つ 5.2 コンテナのライフサイクル管理 5.2.1 Liveness probe 5.2.2 ブローブの遅延と頻度 5.2.3 他のタイプのプローブ 5.2.4 gRPC probe 5.2.5 Readiness probe 5.2.6 ファイルベースのReadiness probe 5.2.7 minReadySeconds 5.2.8 Pod Disruption Budget 5.3 Namespaceの使用 5.3.1 Namespaceを使った作業 5.3.2 Namespaceの選択基準 5.3.3 Serviceのアドレス 5.3.4 リソースのクオータ 5.3.5 リソース要求とリソース制限のデフォルト値 5.4 クラスタのコストの最適化 5.4.1 Deploymentの最適化 5.4.2 Podの最適化 5.4.3 Vertical Pod Autoscaler 5.4.4 ノードの最適化 5.4.5 ストレージの最適化 5.4.6 未使用リソースのクリーンアップ 5.4.7 余剰キャパシティのチェック 5.4.8 リザーブドインスタンスの使用 5.4.9 プリエンプティブ(スポット)インスタンスの使用 5.4.10 ワークロードのバランスの維持 5.5 まとめ 6章 クラスタの運用 6.1 クラスタのサイジングとスケーリング 6.1.1 キャパシティ計画 6.1.2 ノードとインスタンス 6.1.3 クラスタのスケーリング 6.2 適合性のチェック 6.2.1 CNCF認定 6.2.2 Sonobuoyによる適合性テスト 6.3 検証と監査 6.3.1 K8Guard 6.3.2 Copper 6.3.3 kube-bench 6.3.4 Kubernetesの監査ロギング 6.4 カオステスト 6.4.1 本番だけが本番 6.4.2 chaoskube 6.4.3 kube-monkey 6.4.4 PowerfulSeal 6.5 まとめ 7章 Kubernetesの強力なツール 7.1 kubectlを極める 7.1.1 シェルエイリアス 7.1.2 フラグの短縮形の使用 7.1.3 リソースタイプの省略 7.1.4 kubectlコマンドの自動補完機能 7.1.5 ヘルプの表示 7.1.6 Kubernetesリソースに関するヘルプの表示 7.1.7 より詳細な出力の表示 7.1.8 JSONデータと jqの活用 7.1.9 オブジェクトの監視 7.1.10 オブジェクトに関する記述 7.2 リソースを使った作業 7.2.1 命令的な kubectlコマンド 7.2.2 命令的コマンドを使うべきではない場合 7.2.3 リソースマニフェストの生成 7.2.4 リソースのエクスポート 7.2.5 リソースの差分チェック 7.3 コンテナを使った作業 7.3.1 コンテナのログの閲覧 7.3.2 コンテナへのアタッチ 7.3.3 kubespyによる Kubernetesリソースの監視 7.3.4 コンテナポートの転送 7.3.5 コンテナでのコマンド実行 7.3.6 トラブルシューティングのためのコンテナ実行 7.3.7 BusyBoxコマンドの使用 7.3.8 BusyBoxのコンテナへの追加 7.3.9 コンテナへのプログラムのインストール 7.3.10 kubesquashによるライブデバッグ 7.4 Contextと Namespace 7.4.1 kubectxと kubens 7.4.2 kube-ps1 7.5 Kubernetesのシェルとツール 7.5.1 kube-shell 7.5.2 Click 7.5.3 kubed-sh 7.5.4 Stern 7.6 独自の Kubernetesツールの構築 7.7 まとめ 8章 コンテナの実行 8.1 コンテナと Pod 8.1.1 コンテナとは何か 8.1.2 コンテナの構成要素 8.1.3 Podの構成要素 8.2 コンテナのマニフェスト 8.2.1 イメージ識別子 8.2.2 latestタグ 8.2.3 コンテナのダイジェスト 8.2.4 ベースイメージのタグ 8.2.5 ポート 8.2.6 リソース要求とリソース制限 8.2.7 イメージのプルに関するポリシ 8.2.8 環境変数 8.3 コンテナのセキュリティ 8.3.1 非rootユーザとしてのコンテナ実行 8.3.2 rootコンテナのブロック 8.3.3 読み取り専用ファイルシステムの設定 8.3.4 権限昇格の無効化 8.3.5 ケイパビリティ 8.3.6 Podのセキュリティコンテキスト 8.3.7 Podのセキュリティに関するポリシ 8.3.8 Podのサービスアカウント 8.4 ボリューム 8.4.1 emptyDirボリューム 8.4.2 永続ボリューム 8.5 再起動ポリシ 8.6 Image Pull Secret 8.7 まとめ 9章 Podの管理 9.1 Label 9.1.1 Labelとは何か 9.1.2 セレクタ 9.1.3 セレクタの高度な使い方 9.1.4 Labelの他の使い方 9.1.5 LabelとAnnotation 9.2 Node Affinity 9.2.1 ハード Affinity 9.2.2 ソフト Affinity 9.3 Podの Affinityと Anti-Affinity 9.3.1 Podの同居 9.3.2 Podの分離 9.3.3 ソフト Anti-Affinity 9.3.4 Pod Affinityを使ってもよい場合 9.4 Taintと Toleration 9.5 Podコントローラ 9.5.1 DaemonSet 9.5.2 StatefulSet 9.5.3 Job 9.5.4 CronJob 9.5.5 Horizontal Pod Autoscaler 9.5.6 PodPreset 9.5.7 Operatorと Custom Resource Definition(CRD) 9.6 Ingressリソース 9.6.1 Ingressルール 9.6.2 Ingressによる TLS終端 9.6.3 Ingressコントローラ 9.7 Istio 9.8 Envoy 9.9 まとめ 10章 設定と機密情報 10.1 ConfigMap 10.1.1 ConfigMapの作成 10.1.2 ConfigMapからの環境変数の設定 10.1.3 ConfigMapからの環境全体の設定 10.1.4 コマンド引数での環境変数の使用 10.1.5 ConfigMapからの設定ファイルの作成 10.1.6 設定変更に伴う Podの更新 10.2 Kubernetesの Secret 10.2.1 環境変数としてのSecretの使用 10.2.2 Secretのファイルへの書き込み 10.2.3 Secretの読み取り 10.2.4 Secretへのアクセス 10.2.5 保存データの暗号化 10.2.6 Secretの保持 10.3 機密情報管理の戦略 10.3.1 バージョン管理を通じた機密情報の暗号化 10.3.2 機密情報のリモート保存 10.3.3 専用の機密情報管理ツールの使用 10.3.4 本書の推奨事項 10.4 SOPSによる機密情報の暗号化 10.4.1 SOPSの概要 10.4.2 SOPSによるファイルの暗号化 10.4.3 KMSバックエンドの使用 10.5 まとめ 11章 セキュリティとバックアップ 11.1 アクセス制御とパーミッション 11.1.1 クラスタ別のアクセス管理 11.1.2 ロールベースのアクセス制御(RBAC)の導入 11.1.3 ロールの理解 11.1.4 ユーザに対するロールのバインディング 11.1.5 必要なロールの判断 11.1.6 cluster-adminに対するアクセスの保護 11.1.7 アプリケーションとデプロイ 11.1.8 RBACのトラブルシューティング 11.2 セキュリティスキャン 11.2.1 Clair 11.2.2 Aqua Security 11.2.3 Anchore Engine 11.3 バックアップ 11.3.1 Kubernetesをバックアップする必要性 11.3.2 etcdのバックアップ 11.3.3 リソース状態のバックアップ 11.3.4 クラスタ状態のバックアップ 11.3.5 大小のディザスタ 11.3.6 Velero 11.4 クラスタのステータスの監視 11.4.1 kubectl 11.4.2 CPUとメモリの使用率 11.4.3 クラウドプロバイダのコンソール 11.4.4 Kubernetes Dashboard 11.4.5 Weave Scope 11.4.6 kube-ops-view 11.4.7 node-problem-detector 11.5 参考文献 11.6 まとめ 12章 Kubernetesアプリケーションのデプロイ 12.1 Helmによるマニフェストのビルド 12.1.1 Helmチャートの内部構成 12.1.2 Helmテンプレート 12.1.3 変数の補完 12.1.4 テンプレートにおける値の引用 12.1.5 依存関係の指定 12.2 Helmチャートのデプロイ 12.2.1 変数の設定 12.2.2 Helmリリースにおける値の指定 12.2.3 アプリケーションの Helmによる更新 12.2.4 以前のバージョンへのロールバック 12.2.5 Helmチャートリポジトリの作成 12.2.6 Helmチャート内の SecretのSOPSによる管理 12.3 Helmfileによる複数チャートの管理 12.3.1 Helmfileの内容 12.3.2 チャートのメタデータ 12.3.3 Helmfileの適用 12.4 高度なマニフェスト管理ツール 12.4.1 ksonnet 12.4.2 Kapitan 12.4.3 kustomize 12.4.4 kompose 12.4.5 Ansible 12.4.6 Kubeval 12.5 まとめ 13章 開発ワークフロー 13.1 開発ツール 13.1.1 Skaffold 13.1.2 Draft 13.1.3 Telepresence 13.1.4 Knative 13.2 デプロイ戦略 13.2.1 ローリングアップデート 13.2.2 Recreate 13.2.3 maxSurgeと maxUnavailable 13.2.4 ブルーグリーンデプロイ 13.2.5 レインボーデプロイ 13.2.6 カナリアデプロイ 13.3 Helmによる移行処理 13.3.1 Helmのフック機能 13.3.2 フック失敗時の対応 13.3.3 他のフック 13.3.4 フックのチェーン化 13.4 まとめ 14章 Kubernetesにおける継続的デプロイ 14.1 継続的デプロイとは何か 14.2 おすすめの CDツール 14.2.1 Jenkins 14.2.2 Drone 14.2.3 Google Cloud Build 14.2.4 Concourse 14.2.5 Spinnaker 14.2.6 GitLab CI 14.2.7 Codefresh 14.2.8 Azure Pipelines 14.3 CDのコンポーネント 14.3.1 Docker Hub 14.3.2 Gitkube 14.3.3 Flux 14.3.4 Keel 14.4 Cloud Buildによる CDパイプライン 14.4.1 Google Cloudと GKEのセットアップ 14.4.2 デモリポジトリのフォーク 14.4.3 Cloud Buildの導入 14.4.4 テスト用コンテナのビルド 14.4.5 テストの実行 14.4.6 アプリケーションコンテナのビルド 14.4.7 Kubernetesマニフェストの検証 14.4.8 イメージのパブリッシュ 14.4.9 Git SHAタグ 14.4.10 最初のビルドトリガの作成 14.4.11 トリガのテスト 14.4.12 CDパイプラインからのデプロイ 14.4.13 デプロイトリガの作成 14.4.14 ビルドパイプラインの最適化 14.4.15 パイプライン例の適応化 14.5 まとめ 15章 オブザーバビリティと監視 15.1 オブザーバビリティとは何か 15.1.1 監視とは何か 15.1.2 ブラックボックス監視 15.1.3 「アップ」の意味 15.1.4 ロギング 15.1.5 メトリクスの導入 15.1.6 トレーシング 15.1.7 オブザーバビリティ 15.2 オブザーバビリティパイプライン 15.3 Kubernetesにおける監視 15.3.1 外部からのブラックボックス型チェック 15.3.2 内部ヘルスチェック 15.4 まとめ 16章 Kubernetesにおけるメトリクス 16.1 メトリクスとは実際のところ何か 16.1.1 時系列データ 16.1.2 カウンタとゲージ 16.1.3 メトリクスは何を語れるか 16.2 優れたメトリクスの選択 16.2.1 サービス:REDパターン 16.2.2 リソース:USEパターン 16.2.3 ビジネスメトリクス 16.2.4 Kubernetesのメトリクス 16.3 メトリクスの分析 16.3.1 単純な平均の問題点 16.3.2 単純平均、中央値、外れ値 16.3.3 パーセンタイルの把握 16.3.4 メトリクスデータへのパーセンタイルの適用 16.3.5 最悪を知ることこそ一般の関心事 16.3.6 パーセンタイルを超えて 16.4 メトリクスのダッシュボードによるグラフ化 16.4.1 すべてのサービスで標準レイアウトを使う 16.4.2 マスタダッシュボードで情報ラジエータを構築 16.4.3 壊れていくもののダッシュボード 16.5 メトリクスに基づくアラート 16.5.1 アラートの問題点 16.5.2 オンコールを地獄にすべきではない 16.5.3 緊急かつ重要で対処可能なアラート 16.5.4 アラート、時間外呼び出し、夜間起床の追跡管理 16.6 メトリクス管理のツールとサービス 16.6.1 Prometheus 16.6.2 Google Stackdriver 16.6.3 AWS CloudWatch 16.6.4 Azure Monitor 16.6.5 Datadog 16.6.6 New Relic 16.7 まとめ あとがき 索引
tviewを使ってFileViewを作ってみた
最近、Fukuoka.go#16でGoで作るTUIツールという発表を見て、
tviewの存在を思い出したのでちょっと使ってみました。
(発表でも書いてありましたが、tviewはちょっとしたTUIを作るには最高にお手軽なのでTUIに興味がある方は是非)
作ったもの
Todo
- ファイルの色付
- バイナリファイルを開いた際に落ちる
- キーボードショートカット対応