Custom Controllerいろいろ調べる

kubernetes

https://admiralty.io/blog/kubernetes-custom-resource-controller-and-operator-development-tools/ Custom Controllerまわりのフレームワークとしては3種類くらいある

Kubebuilder

github.com

Operator SDK

github.com

これやってみてるけどむずい きちんと理解してないと、ドキュメント通りやっても、環境違いかバージョン違いかでうまくいかない

Metacontroller

github.com

go言語以外でも書ける 公式以外に情報・事例があまりない

戦略的データサイエンス入門 - ビジネスに活かすコンセプトとテクニック

読書

戦略的データサイエンス入門 ―ビジネスに活かすコンセプトとテクニック

戦略的データサイエンス入門 ―ビジネスに活かすコンセプトとテクニック

何か新しい分野をまるっと学ぼうとしたときに、マクロなアプローチとミクロなアプローチを組み合わせて、まず概要書みたいなものを読んで、個々の実例に実際に取り組んでみるということを組み合わせるが、本書はマクロ側のアプローチとして読んでみようと思った。 けっこう難解というか、まだ自分が読むレベルに達していないのか、内容がまわりくどいか説明的すぎるのか、訳が悪いのかは分からないが、読むのが辛い。 読み解くのに苦労するところは割り切って流して、まず通して読むことを優先した。何かが残れば儲けもの、みたいな。

　

Nuxt.jsを学習しはじめた

nuxtjs

フロントのウェブ開発がどうしてもできるようになりたいので、一定の時間をフロント技術の学習に割いていきたいと思う。 順番が違うような気がするが、いきなりNuxt.jsから始めてみた。(Vue.jsもほんの少しは以前触ったことがある）

とりあえず写経から入るのをよくやっているので、公式ドキュメントのスタート部分をざっと読んだあと、下記をやってみた。

Nuxt.js で簡単な画像一覧アプリを作成する - Part.1 | LuftGarden https://luftgarden.work/tut-nuxt-dog-part1/

ライブラリのインストールではまる、はまる。 eslintとか、bulmaとか、cssnextとか、sass-loaderとか、いろいろ出てきてわからない。 最新版にはバグも多いので、それが原因ではまったり、ネット上の適当なページを参照して対処したらそれは古い情報だったりとか。

上記の記事自体が半年以上前のものなので、まんま書いてあるとおりやっても動かない部分があった。サーバーサイドの言語以上に進化が早い。ただなんとか動くところまでできた。 SSR（サーバーサイドレンダリング）とSPAをモードを切り替えるだけでできて、静的に出力することもできて、といったあたりがわかったようでわかってない。ただ、すごい面白いと感じた。

stelligent/mu でフルスタックなECSのCICDフローを立ち上げる

aws ecs codepipeline
  • ECSベースでサービスを立ち上げる
  • 単にサービスを起動させるだけでなく、GitHubへのコミット〜ビルド・デプロイまで自動化したい
  • かつ、開発環境と本番環境を別で作りたい
  • 開発環境は自動でデプロイされてよいが、本番環境は手動で承認されたらデプロイされるようにしたい
  • これらの環境構築含めて自動化したい

上記のような要件ってすごく汎用的に存在すると思う。 AWSでこういったことを実現するにはCode PipelineやCloud Formationなどを組み合わせていけばよくて、そうしたサンプルや事例もたくさん存在する。 ただこれらを作ろうとすると、AWSの各マネージドサービスに関する知識がそれなりに必要で、学習曲線が急だ。

自分はDevOpsを専門領域の1つとしてやっていきたいから各サービスについても詳しく勉強していこうと思っているのだけど、それにしても数日ではできないし、けど開発はさっさと始めたいため、さくっと開発環境（およびCICD、ウェブアプリのアルファ版の公開）を立ち上げたいと思っていろいろ調べた。

stelligent muというOSSが最強ぽい。

getmu.io

なお mu はここでも使われている。このチュートリアルはAWS Dev Advocateの @brentContainedの作ぽい。

Amazon ECS Workshop :: Amazon ECS Workshop

クラスメソッド社のブログ記事のまんまだけど、一通り試してみた。

stelligent mu で作成するECS Fargate用のCI/CD環境(検証環境と手動承認も付いてるよ) ｜ DevelopersIO

この記事内のサンプルは https://github.com/stelligent/mu/tree/develop/examples/ecs-fargate ここにあるコードとほぼ同じで、GitHubのレポジトリ上には他にもたくさんのサンプルがある。

事前に必要なものは

  • GitHubレポジトリ（アプリおよび設定のコードを置く場所）
  • このGitHubレポジトリにアクセスできるGitHub Token
  • IAMアカウントの設定

となる。

コードをGitHubにPushしたらあとは、

mu pipeline up

だけでCloudFormationに各種リソースが作成され、CodePipelineが構築され、acceptance環境までアプリがデプロイされ、production環境は承認待ちのステータスになる、まで全部自動で行われたので驚いた。

  • Code Pipeline

    f:id:road288:20190207160119p:plain
    aws-codepipeline

  • Cloud Formation

    f:id:road288:20190207160450p:plain
    aws-cloud-formation

  • ECS Cluster f:id:road288:20190207160619p:plain

ここまでできれば、プロトタイプ的なアプリを作っていく上では十分なので、これでさっさと開発に入れる。コード書いてPushするだけに専念できる。

レポジトリのIssuesを見ていると、かゆいところに手が届かない（まだ機能が足りてない）部分がありそうなので、本番で使えるかはかなり慎重に調べる必要がある。ただOSSでもあるし、かなりのカスタマイズもできそうなので、ある一定のフェーズまでは大いに使えるケースがありそう。

パスワード誤入力数回でログインを一定時間ロックする仕組みの悪用について

誤ったパスワードの入力で他人のIDをロックさせチケットをゲットする技にファン衝撃【やじうまWatch】 - INTERNET Watch https://internet.watch.impress.co.jp/docs/yajiuma/1168355.html チケット申し込み時に申し込み数を減らす為こんな酷いイタズラをしている輩がいるらしい「怖い、酷い、最低」 - Togetter https://togetter.com/li/1316142

数回パスワード間違えてログインしようとすると一定時間ログインをロックする仕組みってよくありますが、これを悪用して他人のアカウントをロックしているという話。 ログインの仕組み考えるうえで考慮に入れたほうがいいかもしれない。 ログインセキュリティ周りの新しいチェックポイントになりそう。

期間指定（特に先着順）で何か申込みを受け付けるようなシステムだと考慮は必須。 アカウントID自体も固有のIDを生成したものにするか（メールアドレスとか連番とかにしない）、ロックする以外の別の仕組みを設けるか。

特に昨今だとボットやRPAが簡単に導入できるので広まってきてて、こういったいたずらを広範に仕掛けることが誰でもできるようになってきているので。 ロックしないというのも総当たりを許可してしまうことになるし、難しい。

アカウントID自体もプライバシーのあるものにする、というのがとりあえずの対処になりそう。 ただそうすると、アカウントIDを忘れてしまったユーザーに対して1ステップ面倒をかけることになるのだけど。

ホモ・デウス

読書

ホモ・デウス　上下合本版　テクノロジーとサピエンスの未来

ホモ・デウス　上下合本版　テクノロジーとサピエンスの未来

「デウス」は神という意味。人類が次のフェーズとして一部のホモ・デウスとその他（≒無用者階級）になっていく未来について述べている。 「サピエンス全史」も以前読んだが、それの続編となる。

人間中心主義のくだりが出てくるが、同時並行で読んでいた「君たちはどう生きるか」がまさに人間中心主義にのっとった書籍なので苦笑してしまった。人間中心主義（≒自由主義）は決して普遍の真理ではなく、人類の歴史の中で形成されてきたものだというのが印象に残った。

本というのは読む時期によって受け取り方が異なってくるものだと思っている。読む時期としては刊行からそれほど時間が経過していないのでタイムリーな時期に読んだといえるのだと思うが、数年後に読んだら印象が変わりそうだ。本書は予言書的な性格も持っているが、ここに述べられたとおりの世の中になる気もするし、論理が過激すぎる気もする。

「訳者あとがき」が全体の要約としてとてもうまくできている。