先週の金曜日から今日にかけて記事一覧・詳細が表示されていない現象に遭遇しました.
理由は、submoduleで組み込んでいるhello-friendというテーマで記事対象となるディレクトリ名の変更が行われていたためです.
とりあえずは、以下の対応を実施した.
これ今日記事を書こうとしなかったら絶対に気づかなかったので危ないですね.
sshで利用する秘密鍵から対応する公開鍵を生成する時のメモです.
ssh-keygenの-yオプションを使って、秘密鍵から公開鍵を生成することができます. ※1
$ ssh-keygen -y -f id_ed25519 ssh-ed25519 XXXXXXXXXXX
秘密鍵に対してパスワードが設定されている場合は、パスワードの入力が求められます.
$ ssh-keygen -y -f id_ed25519 Enter passphrase: ssh-ed25519 XXXXXXXXXXX
今回は秘密鍵から公開鍵を生成しましたが、これを利用すれば秘密鍵に使えるパスワードの確認もできます. ケースとしてはssh-keygenで鍵を生成した直後に、設定したパスワードの有効性を確認することができますしね.
2019年になり既に20日以上経って今更ですが、去年の抱負の振り返りと今年の抱負を振り返ろうと思います.
昨年の抱負は2つありました.
まず、自己の体調管理について振り返ろうと思います.
例年に比べると対策を取り安定してましたが、1度病気になると長引くというのが正直辛かったです.
感染性胃腸炎で1週間休んだら、次の週はそれが原因で急性胃腸炎になるという「もう一回遊べる○ん！」と言われているかのような辛さでした.
次は日々の学びをアウトプットするについてです.
これは誰がどうみても達成できていなかった.
というよりも、そもそも存在忘れていました.
うん、完全に.
去年の抱負は、目標はあれどそれに対する具体的な計画はありませんでした. そのため、今年はTrelloで今年のパーソナルゴールとして管理するようにしています.
具体的にどういった目標を経てているのかは見せられない項目もあるため伏せますが、ボードで俯瞰して管理できるととても良いです.
全てのゴールを達成するのは私のスキルと仕事との兼ね合いで難しいと思いますが、1つでも多く達成できるようにしてみます.
直近達成できそうなゴールは開発合宿です. 2月中旬なのでその時を今か今かと楽しみにしています.
HTTP/1.1のリバースプロキシとして、EnvoyとNginxとの軽めのベンチマークを取りました.
しっかりとしたベンチマークとはいえませんが、少しは参考になる結果かもしれません.
wrk -t 10 -c 10 http://hostで出力結果を取る今回もdocker-composeを利用して環境を作ります.
コードは、corrupt952/surveyにあります.
Envoy・Nginx・サービス代わりのNginxの3つを定義します
version: '3' services: envoy: build: context: . dockerfile: dockerfiles/envoy/Dockerfile expose: - "80" ports: - "8000:80" nginx: build: context: . dockerfile: dockerfiles/nginx/Dockerfile expose: - "80" ports: - "8001:80" service: image: nginx:stable-alpine expose: - "80"
Envoyのサンプルコードを参考にしていますが、不要なコードは削除しました.
FROM envoyproxy/envoy-alpine:01d726a41bdd790c16765e1d321cb50590574eb0 COPY dockerfiles/envoy/front-envoy.yaml /etc/front-envoy.yaml CMD ["/usr/local/bin/envoy", "-c", "/etc/front-envoy.yaml", "--service-cluster", "front-proxy"]
Envoyのサンプルコードを参考にしてサービスへリダイレクトするようにしています.
admin: access_log_path: "/dev/null" address: socket_address: address: 0.0.0.0 port_value: 8001 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 80 filter_chains: - filters: - name: envoy.http_connection_manager config: codec_type: HTTP1 stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "*" routes: - match: prefix: "/" route: cluster: service http_filters: - name: envoy.router config: {} clusters: - name: service connect_timeout: 0.25s type: strict_dns lb_policy: round_robin hosts: - socket_address: address: service port_value: 80
次に紹介するdefault.confをNginxが読み込める位置に定義しておきます.
FROM nginx:stable-alpine COPY dockerfiles/nginx/default.conf /etc/nginx/default.conf
サービスへプロキシするように定義するだけなので特筆することはありません.
server { listen 80 default_server; server_name _; location / { proxy_pass http://service/; } }
これで準備は終わりです.
wrkというツールを使い、簡易的にベンチマークを実行してみます.
コネクション数10,スレッド数10に設定にします.（これといって根拠はないです）
Envoy
$ wrk -t 10 -c 10 http://localhost:8000 Running 10s test @ http://localhost:8000 10 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 2.45ms 2.02ms 46.58ms 96.63% Req/Sec 433.29 121.99 1.17k 82.34% 43501 requests in 10.10s, 35.39MB read Requests/sec: 4305.17 Transfer/sec: 3.50MB
Nginx
$ wrk -t 10 -c 10 http://localhost:8001 Running 10s test @ http://localhost:8001 10 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.65ms 0.96ms 13.85ms 88.35% Req/Sec 631.85 129.09 1.20k 66.53% 63373 requests in 10.10s, 51.37MB read Requests/sec: 6271.63 Transfer/sec: 5.08MB
Nginxの方が約1ms早いという結果になりました.
ですが、実際この差は膨大なリクエストを捌く必要がある大規模なサービスでなければ誤差といえる範疇かと思います.
今回は、HTTP/1.1のFront Proxyという役割でやってみましたが、Nginx・Envoyともにサポートしている領域が他にもあります.
そういった点を踏まえながら最適なモノを選んでいくのが良いでしょう.
EnvoyはHTTP/1.1とHTTP/2ともにサポートしているということで、HTTP/1.1のFront Proxyができるのか試してみました.
codec_typeをHTTP1に変更すれば、HTTP/1.1で通信するようになるCloud Nativeアプリケーションのために設計されたOSSなプロキシソフトウェアのことです.
KubernetesやMicroservicesの話が出てくると、必ずと言っていいほどに出てくるソフトウェアですね.
などといったマイクロサービスが抱える諸問題を扱えるため、アプリケーション側で扱わなくてよくなり実装がシンプルになります.
また、マイクロサービスでなくても導入するメリットが存在するため、どのような機能があるのかを調べてみるのも良いでしょう.
Envoyが外部からのインバウンドな通信を受け取り、適切なアプリケーションへリバースプロキシすることもできます.
公式ドキュメントでは、Front Proxyというページに書かれています. ※
また、同一ページ内にサンプルコードへのリンクもあるので、簡単に試すことができます.
※ 記事作成時点で証明書が失効しているためブラウザによっては接続できません
公式が用意しているサンプルコードでは、Envoyからサービス用のコンテナのEnvoyへHTTP/2で通信しています.
その通信をHTTP/1.1にしてみます.
また今回作成したコードは、corrupt952/surveyにおいてあります.
まずは大体の概要について書きます.
Client - HTTP1.1 -> Envoy - HTTP1.1 -> NGINX(HTTP1.1サーバ) といった構成で通信します.
次にdocker-compose.ymlについてです.
サンプルコードをベースに作っていますが、異なるのはバックエンドに置いてあるのはごく普通のNginxコンテナです.
Nginxを使っている理由は特にありません.
version: '3' services: envoy: build: context: . dockerfile: dockerfiles/envoy/Dockerfile expose: - "80" - "8001" ports: - "8000:80" - "8001:8001" nginx: image: nginx:stable-alpine expose: - "80"
EnvoyのDockerfileもサンプルコードを参考にしていますが、不要そうな行は削除しました
FROM envoyproxy/envoy-alpine:01d726a41bdd790c16765e1d321cb50590574eb0 COPY dockerfiles/envoy/front-envoy.yaml /etc/front-envoy.yaml CMD ["/usr/local/bin/envoy", "-c", "/etc/front-envoy.yaml", "--service-cluster", "front-proxy"]
今回のキモとなるEnvoyの設定ファイルです.
こちらも他と同様にサンプルコードを参考にしています.
admin: access_log_path: "/dev/null" address: socket_address: address: 0.0.0.0 port_value: 8001 static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 80 filter_chains: - filters: - name: envoy.http_connection_manager config: codec_type: HTTP1 stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: - "*" routes: - match: prefix: "/" route: cluster: nginx http_filters: - name: envoy.router config: {} clusters: - name: nginx connect_timeout: 0.25s type: strict_dns lb_policy: round_robin hosts: - socket_address: address: nginx port_value: 80
細々と変更している箇所はありますが、重要なのはcodec_typeです.
公式ドキュメントのcodec_typeを見ると、指定可能な値は
の3つです.
今回は、HTTP/1.1を強制させたいため、HTTP1を指定します.
たったこれだけでHTTP/1.1で通信させることが可能になりました.
今回は、EnvoyでHTTP/1.1のFront Proxyをやってみました.
これといって難しいことはありませんでしたが、ドキュメントを読みながらEnvoyを少し知るよいきっかけになりました.
転職してから少し経ったので、今更ですが転職エントリを書いていこうと思います.
前職は新宿にあるSIerでした.
そこの会社は学生時だからアルバイトでお世話になっていたところで、約5年も働いていました.
前職では業務としてのプログラミングやインフラの基礎知識を学ぶきっかけや、師匠となる方々がいて楽しかった覚えがありました.
アルバイト時代のプルリクエストでは、 100件以上コメントがつくようなレベルでお互いの考えをぶつけ合っていたことが懐かしい思い出です.
転職しようと思ったきっかけは、いくつかの要因が重なって発生しました.
これらの要因が重なった結果、転職しようと決断しました. それぞれについて書いていきます.
師匠と呼べるような方々は、アルバイト時代から複数人居たのですが、私が転職する頃には2人しか残っていませんでした.
またその2人も同じ職場に居るわけではなかったため、話す機会も少なくなり、技術的な話を気軽に出来るような相手が余り居なかくなってしまったのがそれなりに堪えていたことを覚えてます.
そういう時は、自分がそういう立場になってそういう環境を作る努力すべきだったのかもしれませんね.
自己評価と組織からの評価は、大なり小なり乖離するものです.
この乖離が大きい場合、当人は不満を抱えることになります.
私も例に漏れず、乖離が大きかったため、徐々に不満を抱えていってしまいました.
組織の全員に対して不満を持たせないというのは、難しいことではあるのである程度納得しているつもりなんですけどね.
評価のミスマッチが起きる場合は、別の組織でどのように評価されるのかを確かめる手段の1つとして転職もありだと思います.
キャリアパスというほど明確なものが決まっているわけではありませんが、自分のやりたいことは少なからずありました.
自分に足りない知識を身につけ、自分の知識を元に挑戦したいという思いがありました.
前職のキャリアパスでは、自分のやりたいことを実現するのには難しいと判断しました.
思想、戦略、知識といった人それぞれ固有のものを話し合ったりすることで、刺激を得る場が欲しかったというのが正確かもしれません.
前職でそういった機会がなかったわけではないですが、物足りなかったのは事実です.
職場で求めるのではなく、勉強会で求めたらいいのではないのか？と思うかもしれませんが、そういう機会が得られる職場であればそちらの方がいいですよね.
これといって転職活動らしい活動は、今流行りのTwitter転職のみです.
声をかけていただき、そこからカジュアル面談をして、良さそうであれば面接をしてみるという形で進めました.
それ以外は特筆して書くことはありません.
前職ではエンジニアが働きやすい環境作りに取り組んでおり、悪い環境というわけではありません.
私が求める環境とはミスマッチしていたというだけの話です.
数年後にはまたマッチする環境であるかもしれません.
今の職場では自分のやりたいことが出来そうで楽しみです.
参加してきた時のメモを残しておきます.
※ 写真を撮りたかったのですが準備ができてなかったのでテキストデータのみです.
まず最初にJapan Container Daysを開催・運営してくださった方々、登壇してくださった方々に感謝を.
とても刺激的な2日間でよい時間を過ごせました.
ありがとうございました.
メルカリ内部のマイクロサービスプラットフォームがどうなっているのかがまとまっていた.
メルカリはCloud Nativeを利用するだけではなく、Cloud Native関連のOSSを公開していくことで貢献していっているというスタンスはとても良い.（前から知ってるけど）
PFNの機械学習基盤でどうKubernetesが使われているのかがまとまっていた.
こちらでもOSSで貢献していくというスタンスはとても良いと思う.
LINEのプライベートクラウドの開発基盤の変遷についてまとまっていた.
まず一言言えば、規模が違う.
とはいえ、開発者のために使いやすい環境を提供するというスタンスは良いと思った.
ここまでの規模は難しくても、それを意識していきたい.
IBMがどうCloud Nativeに関わっているのか、どういうサービスを展開しているのかが分かるセッションだった.
Kubernetesを使うことで、どこでもWatsonを動かすことが可能になったという話は興味深かった.
ZOZOがどうKubernetesを活用しているのか、活用した上でどう運用しているのかが分かるセッションだった.
k8sを導入することで、運用コストが下がって、信頼性が向上したというのは興味深いですね.
IBM Cloudのサービスの1つであるIBM Cloud Kubernetesについての説明.
当初思っていたよりも、思っていたよりも使いやすそうだった.
IKSの具体的な使い方はスライドを見てもらった方が良さそう.
年齢的に知らないはずだけど何故か知ってるOS/2 WarpがIBMの歴史で出てきたのが嬉しかった.
Kubernetesを導入した時から、組織や仕組みについての説明.
システムを導入するために組織を変革するのはとても勇気がいる判断だと思うし、それで導入しているのは正直凄い.
KubernetesだけでなくDockerを使う上での心構え的な話しもあった.
改めて振り返ることができたので面白いトピックだった.
てらだよしおがんばった. (参考)
KubernetesでKubernetesクラスタを管理することで、Kubernetesが持つ機能の恩恵を受けようという話.
実際にどうSelf-Hostingしていくかの話が盛り込んであって学びのある良いセッションだった.
記事作成時点でスライド未発見.(見つけ次第アップデートするかもしれない)
眠かったので正直あんまり覚えてない...
Knativeは、こんなに簡単に扱えるよ！っていうセッションだったはず.
まともに覚えてるのAge of EmpiresとCiv6の話が出てたということ.
いや、ほんとすんません... まじで...
Civ6のテクノロジツリーでは、以下のように8時代あります.
スライドで出ていたのは、この時代の中の最初と最後です.
太古は灌漑や畜産、青銅器などが始まる時代で、情報時代はステルス技術やロボット工学が始まる時代です.
Age of Empiresの例では、石器時代から鉄器時代への進化という例を出していて、この程度の進化じゃなくて、Civ6の太古時代から情報時代ぐらいへの進化が求めているものですよねっていう話だったと思います.
記事作成時点でスライド未発見.(見つけ次第アップデートするかもしれない)
Cloud Nativeプロジェクトについてざっと話していた.
最後はCNCF LandscapeのTrail mapの画像を出して、これぐらいあるんですよで終了.
結構知らない技術も多かったので知る機会が得られて良かった.
結構しっかり書いていて、面白い内容だったと思う.
ここに載ってないランタイムもあるそうなので、誰かやってくれるのか期待.
Rancherとその周辺ツールについて簡単にまとまっていた.
初めて触ったのが1系だったので、今は結構変わってるんだなと実感.
記事作成時点でスライド未発見.(見つけ次第アップデートするかもしれない)
showKsの開発裏側を説明していた.
結構楽しそうに話していたので、学生時代の夜更かしして何かやっていた時を思い出した.
Apache Mesosについて分かりやすいセッションであった.
2016年当時のクローラー基盤が抱えていた課題の話から、その課題にマッチしたのがMesosであったということが分かりやすくまとまっていた.
最後のスライドに詳しく知りたい人向けのリンクが載っている.
Kubernetesと簡単な歴史とKubernetes Meetup Tokyoの歴史を時系列で遡っていったセッションだった.
最後にスピーカー達が気になる話をしていて、個人的にはvirtual-kubeletが面白そうだなといった印象を受けた.
とても参加する意義のある日々だったと思う.
結構Kubernetesの話が多かったので、他のCloud Native話を聞けると個人的にはもっと嬉しかった.
とはいえ、俺が期待している細かい中の話は勉強会やもっと小規模なイベントでする話なのかもしれないなと思う.
イベントの中で一番心に残ったのは、Dockerを知っていても、使い方を知っている人はそこまで居ないです.
言われみれば「確かに確かに」と納得するのですが、結構忘れがちかなと思いました.
次回からは、Cloud Native Daysに名称変更されるので、次回も参加できるようであれば参加していきたい.
