近況報告です。
ということで、物理出社はしていませんが最終出勤日でした。
— masasuzu (@masasuz) 2022年4月11日
お世話になりました。
4月末まで｢無職｣になります。
5/1から新しい会社に勤めることになります。職種は一応SREです。
奇特な方はいらっしゃらないとは思いますが、様式美なので置いておきます。
有給休暇消化期間ですが、案外忙しいです。。。。。
読みたい技術書というか、読まなければいけないものが10冊くらい溜まってるけど、有給休暇消化期間中に読み終えられるかな、、、、、
— masasuzu (@masasuz) 2022年4月14日
terrafromのmaintainance_mode変数を見てtrueであれば、ALBで503を返すようにして、スケジュールタスクを止めるように記述している。
1つの方法が良いというわけではなく、メンテナンス箇所がインフラなのかアプリなのかによって方法を組み合わせなければいけないこともあると思います。ECS サービスの変更であれば、アプリケーションのECSタスクが死んでしまうのでアプリをメンテナンスモードにしても無駄だったりします。そういう場合はインフラ側でメンテに入れる必要があったりします。
適材適所でいいのではないでしょうか?
全然他社事例を調べずに書いてるので、他になにかいい方法があったら追記します。
それはそう。
とはいえ、教科書というかベストプラクティスを当てはめてからうまく行かない部分に対して臨機応変に対応するのが定石ではある。
ベストプラクティスという基礎がないとその先の応用を利かせられないので、真剣に取り掛かりたい技術であれば基礎固めを大事にしていきたいと思ってる。
基礎固めを体系的にできるという意味で資格勉強はかなり優秀。ベンダー資格だとまあまあ受験費が高いという難点を除けば、素晴らしい勉強方法だと自分では思ってる。その辺受験費の会社補助がもっとあるといいのになとは思いつつ。
直近でAWSのネットワークの基礎勉強したいので、4月くらいにAWS Certified Advanced Networking - Specialtyを受けたいなと思ってる。ちょうど参考書出ますしね。
EventBridgeでECS Taskの終了ステータスが0以外のとき、つまり異常終了したときのイベントを拾うためにrange関数を使いました。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : range(1, 256), "lastStatus" : [ "STOPPED" ] } } } ) }
が、よくよくドキュメントを見ると “anything-but” という比較演算子があるので、これを使えば素直に意図を表すことができそうです。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : [ { "anything-but" : [0] } ], "lastStatus" : [ "STOPPED" ] } } } ) }
スッキリとした解法を見つけたのでこれで安眠できますね。
Answer: 使えます
諸事情でECS Taskが失敗したとき、すなわち終了ステータスが1から255の条件のとき、のCloudWatch Event Ruleを書きたかったのですが、ベタに1から255のリスト書くのはつらすぎるので、range関数もしくは範囲記法ないかなあとググったらすぐ見つかりました。ありがたくrange(1, 256) を使わせていただきます。
というか、このルール自体いけてないのはわかってるんですけどね。。。。
正直言うと将来どうなりたいってビジョンあまりないんですよね。
不確実な時代に生きているので、数年後どんな仕事してるかなんて想像もできない。エンジニアとしてキャリアを積んでいたいなといううっすらとした希望はあります。
どうなりたいかよりはどうしていたいかって希望の方が強くて、そのなかで楽しい開発をしていれればなあと思ってます。
楽しいって何かというと、難しい問題なんですが、本質的じゃないことにわずらされないこと、自分がやりたいことをやれてることこれが大事なんじゃないかなと思います。そのための手段として自分自身の専門性、スペシャリティを伸ばしていきたいと思ってます。
そして、仕事ってもちろん一人だけでやるものではないので、他の職種との相互理解が必要だと思ってて、そのために他職種の専門性にもはみ出す必要があるんじゃないかなと思ってます。もちろん仕事を奪い取る必要はないんですが、簡単なタスクであれば専門外であっても自身で巻き取れるくらいのスキルは身につけていたいなと思います。
例えば、パフォーマンスチューニングしてて、イケてないクエリがわかったとして、アプリケーションコードの修正方法が分からないから、修正依頼を投げるより、自身でアプリケーションコードを直して、レビュー依頼を専門性があるエンジニアに依頼する方がアプリケーションエンジニアのわずらわしさを解消できて楽しくできてる気がしてます。こんなふうに少し自分の領域を越境することで、少し少しのまわりの煩わしさを解消することでみんな楽しく開発することにつながっていくのかなと。
よく言われる言葉だとT字型人材っていうんですかね。でもスキルセットとしてはそういう方向で伸ばしいくことでやりたいことがやりやすくなるのかなって思ってます。
あくまで目的は楽しく開発すること。その手段として、自身の専門性を高めること、周辺分野の専門性にもはみ出すことそういうことかなあ。
文字に書き出したらスッキリした気がするけど、まだちょっと粗いのでどっかでもう一回考えをまとめたい。
はてなブログProがいつの間にか切れてて(たぶん数年くらい前)、独自ドメインの設定が無効になってたことを今更気づいた。
— masasuzu (@masasuz) 2022年2月11日
Pro2年間契約したのでブログ真面目に書くぞー
(三日坊主フラグですね)
はい。この関係で、独自ドメイン設定が消えてました。今は復活してるはず。
ずっと更新できてなかったけど、この機会にちゃんとナレッジを記録していきたいなと思いを新たにしたのでした。がんばる
terraformとかでインフラリソースとログリソース(S3バケットとかCloudWatch log groupとか)を一緒のモジュールで管理することはよくあると思う。
一緒にすることのメリットとしては不要になったときに一気に消せることなのだが、逆にそれがデメリットでもある。ログに関してはインフラ自体がなくなっても、一定期間残したいという要件があるかもしれない。そのときにまあまあ困る。
対処作としては
となると思うけど、どっちもすっきりしないな。仕方ないけど。
これ以外にもライフサイクルの違うものを管理するときどうすればいいのか。もうちょっと悩みたい。
結論はまだない。
日本語版のドキュメントを見てたらAurora MySQLは2.10.1が最新になってるんですよね。
— masasuzu (@masasuz) 2022年2月9日
なので、これに上げたんですが、言語を英語に変えてみると2.10.2というバージョンがあるんですよね。。。。。かなしい。上げたあとに気がつく悲しさ。
手抜きして翻訳ドキュメント参照してたぼくがわるいのです。
— masasuzu (@masasuz) 2022年2月9日
AWSの日本語版のドキュメントは古いので、英語版を正として見ましょうという話です。
それと新し目のサービスだと、自動翻訳が怪しすぎてまともに読めないことが往々にしてあるので、英語読まざるを得ないんですよね。がんばる
かなしいのでおにく食べに行きます
— masasuzu (@masasuz) 2022年2月9日
