はてなブックマーク

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 先日、Ubuntu Server 20.04 の DNSサーバをデフォルトのものから変更したところ、あるタイミングで何者かが勝手に /etc/resolv.conf を書き換えて、変更を巻き戻してしまう事案が発生しました。 プラットフォームは IDCFクラウド です。 その調査結果と対策をご紹介します。 いきなり結論お急ぎの方のために結論を述べます。 “IDCFクラウドの Ubuntu Server 20.04 において DNSサーバを変更する場合は、dhcpcd を停止しておく” /etc/resolv.conf を書き換えた犯人は、標準でインストールされている DHCPクライアントの dhcpcd でした。 dhcpcd を停止しておけば書き換わりを防げます。 具体的な手順は以下のとおりです。 dhcpcd.se

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 CloudWatch で独自メトリクスを計測したい場合、CloudWatch API を直に扱ったり、CloudWatchエージェント の各連携機能を使うなど、いくつかの方式が考えられます。 この記事では、それらの各方式を比較し、それぞれの使い所を考察してみました。 方式の概観独自メトリクスの計測方式を思いつくだけ列挙してみました。 以下 6つです。 PutMetricData APIまず、CloudWatch の PutMetricData API を直接叩く、素朴な方式です。 AWS CLI や 各プログラミング言語の SDK を利用します。 CloudWatch Logs経由メトリクス値をいったん CloudWatch Logs にログとして格納したうえで、ログから CloudWatch Metrics に変換

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 先日、ユーザ認証のバックエンドに Amazon Cognito を利用されているお客様システムの監視について、設計からお任せいただく機会がありました。 そのときの知見を基に、Cognito をどのように監視したらいいのか改めて整理してみました。 Cognito とは最初に、Cognito がどういうサービスなのか軽くおさらいします。 What Is Amazon Cognito? - Amazon Cognito Cognito とは、Webアプリケーションやモバイル・アプリケーションのための認証、認可、アカウント管理をフルマネージドで提供するサービス (= いわゆる IDaaS) です。 大きく UserPool と IdentityPool の 2つのコンポーネントから構成され、それぞれ以下の機能を司ります。

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 弊社ではお客様のメール環境の管理をお任せいただく案件も多く、送信ドメイン認証として必ず DKIM (DomainKeys Identified Mail) を設定するようにしています。 Amazon SES や SendGrid などのモダンなメール送信サービスでは、その仕組みを知らなくてもガイダンスにしたがってセットアップするだけで簡単に DKIM を有効化できます。 このように DKIM を利用しやすい状況が整っているのはとてもよいことなのですが、詳細を知らずにただ使うのではインフラを扱う者の心構えとしては不充分です。 そこで本記事では、DKIM がどのような仕組みで動いているのか理解するために、手動での DKIM のセットアップと署名付与にチャレンジしてみました。 DKIM の大まかな仕様一般財団法人インターネ

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 ここ 1〜2年の傾向として、弊社でも Kubernetes を扱う案件が増えてきております。 設計から構築、運用まで一貫してお任せいただくことも多いのですが、安定運用するうえでオートスケールの活用は欠かせません。 (というか、これを活用しないと Kubernetes の価値は半減です。) ところが、Kubernetes にはオートスケールの仕組みが何種類もあり、さらにプラットフォーム独自のスケーリング方式も含めると、初見者にはなかなか全貌が把握しづらいところでございます。 そこで、今回は Google Kubernetes Engine (GKE) を対象に、利用可能なすべてのスケーリング方式の概観をまとめてみました。 あくまで概観を眺めるのみに留めており、各方式の具体的な設定方法は説明しませんので、必要に応じてググ

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 皆様は Cloud Monitoring の Aggregation を活用されていますでしょうか？ (昔は Stackdriver Monitoring という名称だったと記憶しているのですが、今は Stackdriver というワードは外されて いますね) 弊社でも GCP を扱う案件は多く、システムの健康状態の把握のために Cloud Monitoring を多用しています。 状況分析や問題の特定のためには適切な Aggregation が欠かせないのですが、Aligner, Reducer, Alignment period など登場人物が多く、なかなか概念を理解しづらいところがあります。 そこで今回は、Aggregation とは何なのか、どんな要素で構成されていて、どんなことができるのかを整理してみました

はじめに平素は大変お世話になっております。 クイックガードのパー子です。 先日、とある Ubuntuサーバの /etc/cron.d/配下に debパッケージのゴミ (= *.dpkg-old とか) がいくつも放置されていることに気がつきました。 このようなゴミは cron がよしなに無視してくれることを経験的には知っていたのですが、正確な仕様が気になってあらためて man をじっくり読んでみたところ、いろいろ興味深い発見 (というか罠) があったのでご紹介したいと思います。 この記事で書くこと、書かないことcrontab の書き方などの基本的な使い方は今さらなのでググっていただくとして、この記事では Debian系における /etc/周りの制約と罠をご紹介します。 スプール領域 (/var/spool/cron/) には触れません。 man に DEBIAN SPECIFIC というセ