タグ

ブックマーク / blog.father.gedow.net (14)

  • これからはじめる Azure の基礎知識 | 外道父の匠

    まいど AWS の犬が、少々 Azure に触れてみましたので、絵は描かずに基礎知識の整理と共有だけしていきたいと思います。 全然ド素人な状態なので、なにかしら間違ってたり不足していると思われますが、同じようにイチから調べる人の足がかりにでもなれば、くらいの質感で進めていきます。 はじめに 今のところ少々用事があっただけなので、これから Azure を掘り下げるぞとか、Azure の犬になるぞ、とかは考えていなく一発ネタで終わる可能性が高いです。雑なメモをブログに起こして、いったんの区切りとする個人的な清書のため、詳しくはちゃんとリンク先のドキュメントなどを読んでくださいませ。 さて、AWS に似たパブリッククラウドはいくつもあり、Azure もその1つです。公式ドキュメントに何箇所も AWS との比較が出てくるくらいには、Azure も AWS を意識しています。 例)AWS サービスと

    これからはじめる Azure の基礎知識 | 外道父の匠
  • AWS VPC のネットワーク小話~Public/PrivateとIPv4/6~ | 外道父の匠

    日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基から

    AWS VPC のネットワーク小話~Public/PrivateとIPv4/6~ | 外道父の匠
  • AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠

    米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

    AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
  • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

    これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

    AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
  • Terraformのループ記法を基礎から学ぶ | 外道父の匠

    Terraform のコーディングにおいて、似た構成の複製をどのように表現するかは結構重要な課題です。放っておくと汚いコピペだらけになっていくからです。 色々な目的とやり方があると思いますので、その表現を実現するためのパーツにでもなればと思い、学習用教材的に書いてみるやつでございます。 目次 説明はそんなに多くないですが、コードのせいで縦長になったので目次を置いておきます。Terraform バージョンは v1.5.7 で動作確認しています。 単体の複製 count for_each セットの複製 module count + module 条件分岐 三項演算子 入れ子 ループ構造 for 複製の方法 階層構造 Pythonの入れ子ループ Terraform の入れ子ループ 続・階層構造 単体の複製 あるリソースに対して、単体の場合は count や for_each を使うことで、lis

    Terraformのループ記法を基礎から学ぶ | 外道父の匠
  • AWSのPublic IPv4構成をIPv6に切り替える | 外道父の匠

    AWSIPv6化について調査は済んだけど、書き始めるのに非常にドンヨリしております。図を書いて少しでも楽しくいきましょそうしましょ。 皆様も読んだらドンヨリするかもしれませんが、できるだけ丁寧に書いてみますので、PublicIP 有料化に抗いたい人は頑張って追ってみてください:-) 目次 また長いです。でもひきかえさないほうがいいかもしれない。 はじめに 前提知識 目的 IPv6 の設計 従来のプライベート IPv4 IPv6 の割り当て Gateway と Routing VPC SecurityGroup Network ACL Subnet Egress Only G/W NAT64 RouteTable Public Private インスタンスで動作確認 IPv6 アドレスの確認 IPv6用の設定 疎通確認 IPv6リソースの配置 既存リソースの入れ替え アプリケーションの

    AWSのPublic IPv4構成をIPv6に切り替える | 外道父の匠
  • AWS VPCルーティングの基本から発展構成例 | 外道父の匠

    久々に図を書きたくなったので、今回は AWSVPC ネットワークの主にルーティングについて雑談気味に振り返っていきたいと思います。 基的なところから、少し発展させた構成はどう実現するのか、ってのを学習用教材風にお絵かきしていきます。 はじめに 最近、実現できると思ってた部分が1つ通らなくて、詰んだかと一瞬諦めかけたところで、10分間くらい思案したらズバッと解決できて気持ちよかったんですよ。 我ながら物凄い泥々の技術を駆使して、発想通りにAWS仕様を回避したネットワークを構築してしまった。泥臭すぎてとてもブログに書けないけどっ…自分の中では満点かつスタイリッシュっ — 外道父 | Noko (@GedowFather) July 7, 2023 元々泥臭いエンジニアリングが得意だったとはいえ、こういう発想の展開力はクラウドだけ真面目にイジってても身につきづらいだろうな、と思い、そうい

    AWS VPCルーティングの基本から発展構成例 | 外道父の匠
  • AWS ECS Fargate のリージョン格差 | 外道父の匠

    前回が思いのほか反響があったので、インドカレーのナンの如くおかわりです。 今回は完全に蛇足っ……圧倒的蛇足っっ……です!同じことを他のリージョンで確認したら、どんなもんなのかという、おまえ暇ナンかと言わてれもおかしくないやつ、参りましょう。 おまえ暇なん……? 暇っちゃ暇。つーか、チャットとかで今忙しいですか?って話しかけられたら、俺はいつでも暇やでって応えるスタンスや。 元々趣味でやってるモンだから、休日にゲームしようか映画みようかエンジニアリングしようかって考えたときに、気になることがあったら先にやっちまうべき優先度が高いのがエンジニアリングってだけ。 こんなどーでもいい釈明をしたくなるくらいには、蛇足回……。 ……と思うやん? リージョン別CPUモデル とりあえず結果を見たらよいと思うやつです。選択したリージョンは基USで、一部適当にやってみただけです。 まずは出現CPUを、CPU

    AWS ECS Fargate のリージョン格差 | 外道父の匠
  • CPUベンチマークの採取方法 | 外道父の匠

    CPUの性能を調べる方法を紹介、というかメモです。 次の記事が長くなりすぎないように分割したやつ。 CPU Benchmark Charts 最も手軽にCPU性能を調べられるのが、このサイトです。 PassMark Software – CPU Benchmark Charts 私の場合は、サイドバーの『Single Thread』を眺めたり、ヘッダの検索から型番のページに行って、Single Thread の値を確認したりします。 マルチコアでの総合力も大事なんですが、個人的には Single での性能がレスポンスタイムなどに直結するので、重要視しています。 CPU情報 /proc/cpuinfo Linux なら、これで大体の情報を確認できます。 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family

    CPUベンチマークの採取方法 | 外道父の匠
  • SSSDとnslcd+nscdの比較 | 外道父の匠

    SSSDを触り始めた理由である、nslcd+nscd と結局どっちがエェねんという疑問をまとめていきます。 SSSD といっぱいタイピングしていると ssh が sssh になってしまう病気にかかるので要注意です。 関連記事 認証システムSSSD+LDAP+SUDOの構築手順 SSSD+LDAP+SSH連携の設定 システムの用途 nslcd(Name Service LDAP Connection Daemon) はその名の通りLDAPとの接続を担うだけなので、キャッシュ担当の nscd (Name Service Cache Daemon) がいないと毎回LDAPに接続することになり、不健康となるためセットで使うのが基です。 SSSDは認証管理+キャッシュの役割を併せ持つので、デーモンとしては1つになります。LDAP以外の様々な認証機能を使えるのも強みですね。 LDAP周りだけでいえば

    SSSDとnslcd+nscdの比較 | 外道父の匠
  • systemd時代に困らないためのlimits設定 | 外道父の匠

    数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上

    systemd時代に困らないためのlimits設定 | 外道父の匠
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
  • 2014年からはじめるAWSリンク集 | 外道父の匠

    ガチのAWSド素人が年末に調べまくった、AWS関連のリンク集です。 まだまだ調査中なので随時追加する予定ですが、広深くてキリがないのと、年始一発目の目覚ましエントリということでいってしまいます! はじめた目的 多数のスタートアップにおいて、インフラ専門のエンジニアが付かなくても、小~中規模程度まではそのチームでインフラ面を完結できるようにしたい。 …ということで、今の時代に合わせて簡単・安価・拡張性・耐障害性…を満たす環境を考えるべく、ひたすら知識をかき集めることにしました。考えた構成などについては別途書きたいと思います。 また、遡って調べるほどに出来と進化速度に感心するとともに、情報消費期限がせいぜい2年だと感じ、ほぼ2年以内の情報をもってこのような臭ぇタイトルにしています。 目次 ドキュメント アーキテクチャ クラウド全般比較 クラウド性能比較 費用/スペック ネットワーク 基インス

    2014年からはじめるAWSリンク集 | 外道父の匠
  • ドリコムのソフトウェア選択のお話 | 外道父の匠

    mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat~F

    ドリコムのソフトウェア選択のお話 | 外道父の匠
  • 1