私は社会人10年目、つまりITエンジニア歴も10年。転職3回を経て4社目の現在は、ドクターメイトという医療介護系のベンチャー企業で働いています。
今すごく充実している。そりゃ職場には気が合わない人だっているし、ムカつく瞬間だってある。でもそういうことではなくて、なんというか「迷いがなくなった」みたいな。これが僕の辿り着いた境地だと思います。
続きを読む私は新卒でワークスアプリケーションズという会社に入社した。新卒研修等で有名な会社だった。研修で結構良い結果を出したことで、給与が100万上がり、同期の上位10%ほどしかいないグレードからのスタートとなった。体力も精神力も根性もあった。毎日9時から終電まで働き、部長や先輩のパワハラなどにもめげなかった。社長賞をとるような上長に気に入られ、右腕と勝手に自負して働き、上長が転職する際に、自分も「引き抜かれた」形でついて行った。
AWSに変換して考えちゃうんだけど、下記てきな感じであってるのかな・・・
AWS EKS を触ってみないと、想像できない内容かもしれない。
Kubernetes（AWS EKS）って使ったことないんだよな〜、使う時がきたら、Knativeの利用を考えよ。
Alias機能知らなかった・・・割といいかも。 AWS CLIって、毎回必ずと言っていいほどコマンド調べるから、再現性がなくてつらいな（使わないな）ってなってたので、 使ってみようかなと思いました。複数人が利用する踏み台サーバーの中に仕込むとかは、開発組織ならGoodなアプローチだと感じた。
AWS Alias は知らなかった。これはエンジニア組織での利用とか考えた場合に、いい取り組みになるだろうなと感じた。
Kubernetes使ったことないんだけど、connpassのウェビナーとかみてると結構この話題多いんですよね・・・世間では割とみんな使い始めてるのかな・・・？
いろんな認証方法があるのでまとめてみた。
※ たくさんあるので随時追加していきます。
HTTPで定義される認証方式。
ユーザ名とパスワードの組みをコロン ":" でつなぎ、Base64でエンコードしたものを、リクエストヘッダのAuthorizationフィールドに記載して、サーバーへ送信することでチェックしている。
初回認証後は毎回の通信時に、ブラウザが自動的に Authorizationフィールドに認証情報を記載しているため、都度入力は不要。
HTTP通信で利用できるため利用シーンが幅広く利用難度が低いが、SSL暗号化されていないサイト利用時に通信傍受されると、簡単にパスワードが漏洩してしまうため、次の Digest認証 が生まれた。
Basic認証におけるパスワード漏洩リスクを改善した認証方法。
サーバー側から発行される nonce や realm といったデータを含めて、ユーザ情報やパスワードをMD5でハッシュ化したものを送信している。これにより、通信傍受されたとしても複号化が困難となり、Basic認証に比べて安全性が担保されている。
サーバーが発行するデータ
auth または auth-init がはいり、どちらかによりMD5ハッシュ化の範囲が異なるクライアントが発行するデータ
Basic認証同様、リクエストヘッダのAuthorizationフィールドによって認証が行われる。特に response 要素に、下記のロジックで暗号化された認証情報が含められる。
A1 = ユーザ名 ":" realm ":" パスワード A2 = HTTPのメソッド ":" コンテンツのURI response = MD5( MD5(A1) ":" nonce ":" nc ":" cnonce ":" qop ":" MD5(A2) ) ※ qopがauth-initの場合、A2は次のようになる A2 = HTTPのメソッド ":" コンテンツのURI ":" エンティティボディ
指紋認証や顔認証といったものに代表される、パスワードの入力を必要としない認証方式のこと。
例えば、iPhoneの顔認証を例にとってみると、
あるサービスに登録する場合、自分のiPhoneと利用サービスのアカウントに対して一意の、新しい公開鍵/秘密鍵のペアを生成し、秘密鍵はiPhoneに保存され、公開鍵は利用サービスに送信され、自身のアカウント情報に紐づけて保存される。
ログイン時には、まずサービスからiPhoneへ認証要求（チャレンジ）がレスポンスされ、それをiPhoneに保存されている秘密鍵で暗号化したものを送り返し、サービス側の公開鍵で検証して認証を行っている。
（個人的に、サービスのアカウントごとに秘密鍵を作っている感覚がなかったので、新しい気付きを得ました）
SSO（シングルサインオン）を実現するための認証方法の1つ。
アクセストークンを利用した「認可」を実現している。（「認証」と「認可」は別物。）
通常、OAuthは認可を実現する仕組みなので、認証（ログイン）には利用されない...のだが、認可によりサービスがプロフィール情報にアクセスして本人情報を取得することにより、認証のような動作を実現することができる。
OAuthによるソーシャルログインを提供している企業（IdP: Identity Provider）
例えば、Twitterによる認可を例にとってみると、
利用サービスはユーザー経由でTwitterからの認可コードを取得し、それをもってアクセストークンの発行を依頼する。
認可コードが正しい場合、アクセストークンが発行され、利用サービスはそれをアカウントに紐づけて保存する。
アクセストークンを利用することで、利用サービスはユーザーに代わってTwitterへのアクセスが可能となり、ユーザーのプロフィールやツイート情報を取得することができる。
ただしOAuth認証には、アクセストークンが盗まれると悪意のある第三者による不正ログインができてしまう脆弱性が存在する。
この脆弱性をさらに改善したものが、OIDC認証になる。
SSO（シングルサインオン）を実現するための認証方法の1つ。OAuthを拡張した進化版みたいな感じ。
IDトークン（JWT形式）を利用した「認証・認可」のどちらも実現している。
OIDCによるソーシャルログインを提供している企業（IdP: Identity Provider）
（後日、更新します）
SSO（シングルサインオン）を実現するための認証方法の1つ。
SAMLとOAuthという2大プロトコルが存在し、それぞれ認証方式が存在しているという状態。
と、ここまで書いてはみたけど、実際に実装してみないとイマイチわからないです...
Threadsの登録者数の伸びを見ていると、やっぱりSNS認証は強いなと感じます。
認証機能を提供するサービス（IDaaS）の現状のスタンダードは Auth0 だと思われます。
月並みですが、Auth0 といった IDaaSを利用して、OIDC認証やFIDO認証をサクッと組み込める
そんなことができれば、一般的なエンジニアとしては十分なんじゃないでしょうか。
tfsec自分もterraformのリポジトリで必ず利用していますが、AquaSecurityという企業に買収されており、Trivyというツールの一部になっていたようです。
下記のdiscussionで、Trivyに移行するように2月に書かれています。ただ 👎 が多いのが気になりますね😅
Trivyは、DockerイメージやGithubリポジトリなど、いろいろなスキャン対象があるので、もしかしたら今後はいろいろなところで見かけるようになるのかな。
このLT、「ECRはVPC外にあるから気軽にイメージpullしてたらやっべえぞ」的な文章なので、「なんやECRとかVPCが悪いんか？」って思われがちだと思うんですが、結局NATゲートウェイ気をつけようねって話だと自分は思います。
NATゲートウェイ、コストを考える上で必ずネックになるリソースだと自分は思っていて、自分も気をつけたいです。だってprivateサブネットから外部通信したい場面って割とあるだろうし・・・
このLTでは、VPCエンドポイントを使って解決するべきだった。というオチで終わっています。確かにそうですね。
8/31追記
こちらの件、自分の認識が甘かった。
タスク定義でpublicなimageを指定した場合、ビルドの度にNATゲートウェイを通ってimageを取得しにいくから気をつけようねって話だった。
ごめんなさい。これは、初見じゃ気づかないわ。。。自分も気をつけます。
ECRには、プルスルーキャッシュという機能（publicなimageをprivateリポジトリに保存して、1日1回だけimageの更新が行われる）が追加されたので、
外部のimageを利用するときはこちらを使って実現しよう。
インフラ（AWS）のコストって、昨今の円安も相まってビジネス的にも重要性が増している気がします。
MVP的なノリで新規サービスのリソース作って、なんかめっちゃコストアラート鳴ってる〜〜、とかならないように自分も注意していきたいです。
数ヶ月前に、勤務している会社でPCのリプレイス案内がきました。 ざっと、このようなリプレイスになります
今回は、Railsアプリのバックエンドを担当している場合に起こりうる影響を確認してみました。
公式のRubyイメージを元にしてDockerfileを作成している場合、おそらくnokogiriでエラーが発生します。
$ docker-compose build --no-cache （省略） > ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:
直接の原因は、Rubyイメージにプリコンパイルされているnokogiriが参照したいファイルが足りていないからのようです。
ただもちろんこれは Apple Silicon に変更したからでしょう。
結論から言うと、bundle の platform を ruby に強制することで改善します。 自分はDockerfileの記述に下記を追加しました。
RUN bundle config set force_ruby_platform true
bundle の platformは、特に指定しない限り、ホストPCのプラットフォームになります。
つまり、M2Proだと arm64-darwin-22 という名称のプラットフォームとして、bundle は動作します。
おそらくこのplatformだとインストールされないファイルがnokogiriには必要なのだと思われます。
Railsアプリ、皆さんの開発環境ではどのデータベースを利用していますでしょうか？多くの方が MySQL か PostgreSQL かと思います。
自分は MySQL を利用していて、docker-compose.yml ではmysql:8.0.28 を指定していました。
その環境で docker-compse up を実行した時に下記のエラーに遭遇しました。
docker-compose.ymlを下記のように修正し、MySQLは無事に立ち上がるようになりました。
$ docker-compose up （省略） > no matching manifest for linux/arm64/v8 in the manifest list entries
これは、mysql:8.0.28 のイメージに、AppleSilicon（arm64）に対応したものが存在しませんでした。というエラーです。
どうしてこのような動きになるかというと、イメージの取得はホストPCのプラットフォームに依存して行われるからです。
そのため、明示的にプラットフォームを指定する必要があります。
db:
image: mysql:8.0.28
platform: linux/x86_64 # 追加
もし改善されない場合、例えば Dockerfile がマルチステージビルド形式で記載されていて、記述が意図せz反映されていないなどを疑った方がいいかもしれません。
実は本業では Github Codespaces を利用しているため、PCリプレイスの影響は全くありませんでした（笑）
M2 Proめちゃくちゃいいです。キーボードはタイプしやすいし、画面は綺麗で動作もサクサク。そして電池の持ちがすごいです！
定期的にイベントに参加して、エンジニアとして意識を高く保とうと思ったのがきっかけです。 （よくイベントに参加している優秀なエンジニアが身近にいて、ケツを叩かれたのが実情）
「どんなイベントでもいいから出るぞ」とは思ったものの、実際どれにしようか迷った挙句、めちゃくちゃ置きにいった選択をしました（笑）
自分は「App Runner」を使ったサービスを運用しているため、とりあえず話についていけない事はないだろうと思ってポチりました。
質疑応答で、こんな質問がありました
自分も同感です。App Runnerの良いと思う所はいくつかありますが、例えばwebアプリが公開に至るために必要な機能が最低限揃っており、それらリソースが機能として内包されているところ、は真っ先に挙げられると思います。
これに対して回答を要約すると
うーん...正直言うとAWS CDKがあまり好きではなく、このアプローチはあまりやって欲しくないかなと個人的には思いました。 現状IaCのスタンダードはTerraformだと思っていて、自分もTerraformはかなり好きですし、Googleも推奨するmoduleを使ったベストプラクティス構成だと、環境ごとのリソース状況が見通しやすくて凄くいいんだよな...（脱線しすぎました）
皆さんはどう思ったんだろう・・・？
このブログ書いてて思ったんですが、「GCPのCloudRunをどのくらい意識していますか？」みたいな質問すれば良かった（笑）
ここ最近のApp Runnerのアップデートを見ると、おそらく相当CloudRunを意識しているし、AWSも力を入れてる気がしてます。IaaSは断然AWS派なので、是非とも頑張って欲しいです！また何かイベント参加したら記事にするつもりです。今回は以上にします！
はじめまして。 自分はWebアプリのエンジニアで、主にバックエンドを担当しています。 普段はRuby on Railsで作ったアプリケーションを、Docker環境で開発し、CI/CDで検証してデプロイし、AWSで運用しています。
本業ではないのですが、ビール醸造所のお手伝いをしています！ ビール醸造所って、めちゃくちゃアナログな世界なんです。その辺の苦労や、解決のために四苦八苦したことも書いていけたらと思っています。
新卒からエンジニアをしてるにも関わらず、30代になってようやく、バックエンドなら大体やれるなと感じはじめました。
でもハッキリ言います。自分はエンジニアとして とても平凡 です。 スポーツ選手を表すレーダーチャートが、もしエンジニア界隈にあるとするならばきっとこうです。
今はまさしく「ヘイボンジニア」ですが、「ヒボンジニア」へ成長できるよう頑張っていきます。
どんなコメントでも良いので、残してもらえると嬉しいです。
