ブックマーク / blog.a-know.me (6)

  • nginx で EU からのアクセスを拒否する - えいのうにっき

    「あ、EUからのアクセスを拒否したいな......」と思うこと、ありますよね。私も今日、そう思いました。 私は趣味と実益を兼ねて(いるつもり)、いくつかのしょうもないWebサービスを個人で運用してるのですが、そこに対するEUからのアクセスを遮断したいと思い、それを nginx で対応してみたので、そのメモです。 手順 基的にはこちら↓の知見の固まりを参考文献としています。 inaba-serverdesign.jp EU加盟国は、外務省のページ(EU加盟国と地図 第5次拡大|外務省)によると以下の28カ国。 アイルランド イタリア 英国 エストニア オーストリア オランダ キプロス ギリシャ クロアチア スウェーデン スペイン スロバキア スロベニア チェコ デンマーク ドイツ(加盟時西ドイツ) ハンガリー フィンランド フランス ブルガリア ベルギー ポーランド ポルトガル マルタ ラ

    nginx で EU からのアクセスを拒否する - えいのうにっき
  • Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき

    もともと数ヶ月前から、Go言語によるWebアプリケーション開発 を読みながら Go での Webアプリケーション開発の勉強をしていた。 Go言語によるWebアプリケーション開発 作者: Mat Ryer,鵜飼文敏,牧野聡出版社/メーカー: オライリージャパン発売日: 2016/01/22メディア: 大型この商品を含むブログ (3件) を見る 「実際に動くもの」を、「手を動かして作りながら学ぶ」のが僕は好きで、今回も同様、それを楽しんでやっていたのだけど、思いの外それっぽいものができあがってしまって。これをそのままローカルで動かすだけじゃおもしろくないな、もったいないな、と思ったので、それをサービス化して公開するところまでやってみた。 かんじんのアプリケーションは↓これ。Yukizuri と書いて「ゆきずり」と読む。 https://yukizuri.moshimo.worksyukizu

    Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき
  • Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき

    Mackerel について考えない日はないというくらいに Mackerel・Love な僕なわけですが(考えない日はあります)、Mackerel の Web 画面で日頃なにげなく見ている「システムメトリック」、みなさんはどのような意識を持って観察していますでしょうか。 ↑ https://home.a-know.me をホストしているサーバのシステムメトリックのようす。 ここでひとつおさらいをしておくと、「システムメトリック」とは、監視対象のサーバにインストールされた mackerel-agent が、それ単体で収集・投稿するメトリックのことです。一般的な Linux系OS に mackerel-agent をインストールした場合、以下のような項目がシステムメトリックとして Mackerel に投稿されます。 loadavg5 cpu memory disk interface files

    Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき
  • 「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき

    僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書2」というを読んでいる。 インフラエンジニアの教科書2 スキルアップに効く技術と知識 作者: 佐野裕出版社/メーカー: シーアンドアール研究所発売日: 2016/08/26メディア: Kindle版この商品を含むブログを見る Twitter かなにかでこのの存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。...のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。 このの7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に(20秒程度で!)収集できるべき』、とされていた。 メモリの搭載量と使用量 パーティションごとのディスクの使用率と空き容量 CPUの種類とコア数 ディスクのRA

    「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき
  • エンジニア立ち居振舞い:論理的に考える - えいのうにっき

    ひとでくんさんが作ってくれた お題「エンジニア立ち居振舞い」。ぼくはセールスエンジニア...、、あっ、エンジニアじゃんってことで考えてみた。 常に物事を論理的に考え、捉えるようにする 僕のいまの仕事のうちのひとつに、ユーザーさんからの技術的な問い合わせに対する受け答えをする「テクニカルサポート」というものがあって。 hatenacorp.jp ご意見やご要望、動作不良など、日々さまざまなお問い合わせをいただくのだけど、特に「なぜかうまく動かない」といったお問い合わせは、僕の目から見ても「なぜうまく動かないのかわからない」ということも多くて。 特に、起きてる現象に対しての「ひと目見ただけでの時点での感想」は、ユーザーの方が抱くものと殆ど同じだったりする。 ただそこからがやはり大事だと思っていて、 目の前で起こっている事象が起きる原因としては、どういったものが考えられるか。 原因と思われるもの

    エンジニア立ち居振舞い:論理的に考える - えいのうにっき
  • Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき

    前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身(親プロセス)の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実

    Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき
  • 1