エンジニアは寛容かつ建設的でありたい | 外道父の匠
前回の記事でイィ感じの燃え方してイラつきはしたけど、ちゃんと調べず適当に公開したのはマズかったし、どっちみちそれまで理解が浅かったのは事実で認識してたので、それはもういいんです。 それよりもなんで、昨今はこんなにクソコメが蔓延るようになったんやろって考えてみたくなりました。エンジニアに限らず、ジャンル問わず社会的な話でもあるのですが。 社会的な風潮 要は『叩く』という行為が流行を通り越して当然になってる風潮ですね。 エンジニア関連でも、昔から技術系掲示板では、そんなことも知らんのかい！とツンツンしながらも教えてあげる文化みたいなものはありましたが、そういう『限定的な場』に自分から踏み入れない限りは、エンジニア同士の交流の多くは所属や個人サイトが判明している人だったりして、誤りや改善点があれば、スマートに指摘して、素直に受け入れる、ような流れが多かったように思います。 SNSが流行りだしてか
AWS ALB+ACMの意外な落とし穴 | 外道父の匠
全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来
AWS ECS Fargate のリージョン格差 | 外道父の匠
前回が思いのほか反響があったので、インドカレーのナンの如くおかわりです。 今回は完全に蛇足っ……圧倒的蛇足っっ……です！同じことを他のリージョンで確認したら、どんなもんなのかという、おまえ暇ナンかと言わてれもおかしくないやつ、参りましょう。 おまえ暇なん……？ 暇っちゃ暇。つーか、チャットとかで今忙しいですか？って話しかけられたら、俺はいつでも暇やでって応えるスタンスや。 元々趣味でやってるモンだから、休日にゲームしようか映画みようかエンジニアリングしようかって考えたときに、気になることがあったら先にやっちまうべき優先度が高いのがエンジニアリングってだけ。 こんなどーでもいい釈明をしたくなるくらいには、蛇足回……。 ……と思うやん？ リージョン別CPUモデル とりあえず結果を見たらよいと思うやつです。選択したリージョンは基本USで、一部適当にやってみただけです。 まずは出現CPUを、CPU
データセンターの思ひで | 外道父の匠
今月、とうとうオンプレミス環境がその役割を終えたので、当たり障りのない範囲で思ひでを記録しておこうと思います。 だいたい 2002年 から運用が始まったので18年ほどの歴史でしたが、血と汗と…… 血と汗くらいですかね滲んでるのは。さぁ振り返りです。 大阪 私が参画した時にはインフラエンジニアというかサーバー担当者が既に１名おり、「サーバーやってみない？楽しいよ！」と言われて乾いた笑顔を返したのを覚えています。 当時は京都の極小ベンチャー企業で、なぜ最初が大阪のデータセンターだったのかは聞きませんでしたが、とある現地作業についていって、ハーフラック１台に１Ｕ２台が積載されていました。このへんは私自身かなりのペーペーだったので知識不足もあり記憶がかなり曖昧です。 平々凡々に運用していたある日、WEBサイトへのアクセスが途絶えました。 社長の「ねぇ、サイトに繋がらないんだけど」の一言が口火です。
これからはじめる AWS Auto Scaling 2019年版 | 外道父の匠
昨年は内部的なことを多くやっていたり、10年ぶりに格ゲー復帰したりで、なんとなくご無沙汰になります。が、元同僚エンジニアに名指しされたり、 パルが年末にアドベで連続更新してるのをみて、俺も頑張らなきゃなと思い直した次第でありやす。 久々すぎてなんか文章のノリがノらないので、最近調べ直した AWS の Auto Scaling 周りについて、今はこんだけ抑えておけばえぇんちゃうくらいの感じで、まとまり悪いかもですがまとめてみたいと思います。 目次 色々な「Auto Scaling」を理解する EC2 Auto Scaling Application Auto Scaling AWS Auto Scaling APIで理解する関係性 AWS Auto Scaling は EC2 Auto Scaling の代わりになるのか EC2 Auto Scaling を構築する 構成 LaunchTem
ミドルウェア性能検証の手引き | 外道父の匠
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
systemd時代に困らないためのlimits設定 | 外道父の匠
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール／SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
