はてなブックマーク

数ヶ月前にカッとなって課金だけしてたlocalstack Pro版を触ってみたのでその記録 localstackのPro(有償)版とは？ localstackはaws-apiをローカル環境で再現するものです。それの有償版がPro。できること・できないことは https://localstack.cloud/ を見てください。 だけど これだけ見てもよくわからんよね？ なので自腹を切って試してみた、というより面白そうだとおもったから、とりあえず課金した、英語を含めてもあんまり有償版のポストが見つからなかったため。 システム的な違い/機能Activateなどの話 Communitiy版をdocker-imageで無償で公開してるので、Pro版はどう違うんや？と思ってたけど、Pro版の場合は、API＿KEYを環境変数として仕込むことによって、認証サーバとおしゃべりして機能を有効・無効化しているは

まず最初に、本当にやりたかったことと、調べているうちにだいぶ脱線して得た知識を書いてます。少々規模がでかいです。 最初にやりたかったのは、 EC2 role (Instance Profile) を使っているときに awscliとかで Unable to locate credentials が稀に出るという問題の解消です。 で、いきなり(今わかっている) 答えを書くと、 AWS_METADATA_SERVICE_TIMEOUT AWS_METADATA_SERVICE_NUM_ATTEMPTS あたりの環境変数を指定しておくです。 AWS CLI Configuration Variables — AWS CLI 1.18.123 Command Reference 上記を含む、大部分が脱線した内容を掘り下げて行きますが、前提となる知識が結構多く、いちいち細かく書くと長すぎるので、AWS

もうこれ系の仕事について18年になる。よその業界の人から見ると「なんかパソコン使ってやる人」にひとくくりにされそうだが、職場によって結構やってることは違った。 そんな中でも振り返ってみるとそこそこでかい単ファイル(csv)を見る機会は結構あって、その都度なんかいいのないかと探していた気がするが多分これでいいんじゃね？ github.com やりたいこと・できること そこそこの規模のデータをさくっとみたい CLI最強、GUIなんかいらん そんなひとには良い。公式にもあるが、ガチ分析には向かん。 あと追加の言い訳。今の時代はS3みたいなオブジェクトストレージにそこそこのサイズで切片化してファイルを置くのが正義です。単ファイルのごついCSVは時代に逆行する。切片化したデータを読む場合は、ぱっと調べた感じは visidataはプラグインで対応するらしい。 GitHub - ajkerrigan/v

インフラ屋を辞めたので、それなりにコードを書いて走らせる機会が増えました。ローカル上のコードをぱっとサーバ上で動かしたい場合の解決方法を書きます。 tl;dr ssh のポートフォワーディング(ローカルフォワード)には、フォワード先のポートを動的(不定)にするモードあり -D httpには http_proxy環境変数があるが、socks5にはそれほど汎用的なものが無い、特に非http。それをプロセスを１枚かぶせる事によって socks5経由に曲げる proxychain4 http proxyが proxyするのはあくまで httpだけ、dnsへの問い合わせなどは、proxy経由とならないが、それすらproxy経由にできる。特にAWSの route53 private hosted zone などを使っているときに効果絶大。 Trampですか？ TRAMP (Transparent Re

非常にググりにくい事柄なんですが、なるべく浮世離れしないタイトルとして書きます。 EC2(正確にはENI)からの名前解決、つまりリゾルバとしてのOutboundには、全て制限がかかっています。1024パケット/秒です。 VPC での DNS の使用 - Amazon Virtual Private Cloud ECS DNS というキーワードで探すと、ほぼ間違いなくService Discoveryがうじゃうじゃ出てきますが、これはリゾルバ・キャッシュサーバの話です。 これをEC2で回避する方法はAWSが書いてくれています。 Avoid DNS Resolution Failures with EC2 Linux 似たようなことをECSで、なるべくエレガントにやります。わざわざこう書くのは、ちょっと泥臭いという意味です。 どういうとき問題になるか そもそもこのポストを見ているひとは、今現に

日次でも月次でも、まず殆どのシステムで何かしらのバッチジョブというものを動かしていると思いますが、 そのバッチが確かに実行された ことを保証・監視することは結構難しいです。ジョブが起動しましたのタイミングでログを書き、終わってもログを書くとすれば、ジョブが成功したか失敗したかはわかりますが、そもそもジョブが着火すらしかなったはわかりません。*1 例えば、「このジョブが終わるとここにファイルが出ているはずだ！このDBのレコードが更新されているはずだ！」などと、そのジョブ固有の結果を観測して判定することはできますが、汎用的な手法ではありません。 私は詳しくはないですが、商用のジョブ管理ツールはそれぐらいは見てくれるのかもしれませんが、もっと簡単にこれを実現できます、しかも今風に。 Healthcheckesとは ググりにくく、ネーミングセンスとしては最悪ですが、上記に挙げたような機能を実現する

GCPで Google Cloud Storage (GCS) & 独自ドメインで httpサーバを立てるというのを以前やりました。もはや2015年の古いエントリですが今も結構な閲覧数があるので、2019年版のリファインとして、もっといいやり方を紹介します。 iga-ninja.hatenablog.com なお、この上記の方法は未だに通用はします。httpだけでOK, httpsは不要であれば上記の方法を今でもおすすめします。 また、本エントリーは深い解説はせず、手順だけをサラッと書きます 今回作るもの 独自ドメイン L7LB + GCS HTTPS 無料証明書入り の静的Webホスティングです。 AWSでいう CloudFront + S3 + ACM の組み合わせです。 手順 例によってフル GCPで 材料 ドメイン(お名前でも何でも) Cloud DNS L7LB Exernal

GCEでインスタンスを起動するときに、先にホスト名を決める必要があります。AutoScaling等の場合は、勝手にプリフィックスがついて名前被りを避けます。これによりAWSのようなIPアドレスベースの使いにくいFQDN(Internal)ではなく、直感的な名前で名前解決ができます。 AWSでもUserData,cloud-initによる機構などで実現することは可能ですが、私の直感として「そんなことはインフラだけで完結しろよ！」と思うので、GCEぽい動きをするLambdaを約2年前に作成していたので、今更蔵出し公開します。 github.com 使いたいだけの人は使い方はすべてGitHub上に書いていますので、そちらを見てください。 このエントリでは、今回蔵出ししたこのツールを通して serverlessフレームワークの歴史と使い方について振り返り書きます。書きたいのはこっちですが、タイトル

ecsへのアプリケーションデプロイはecs-cliが最も優れていると思いつつも、結構わかりにくいツールであるのは間違いないです。その解説をするのですが、この投稿ははっきり言って上級者向けで docker-compose かなり使いこなせる AWS ECS の基礎がわかっている ことを前提にしています。上記を説明しだすとキリがないので、今は「ちょっと、何言ってるかわからないですね〜」な人も、ecsを使うならば近い将来役立つと思うので、あとで読むなどしておいてもらえればと思います。 ecs-cliのコンセプト まずは ecs-cliがどんなものかを、これもある程度上級者向けに雰囲気を掴んでもらうように伝えるとこんなかんじ docker-compose でローカル実行するよね普通 docker-compose.yml の内容って ecsのタスク定義 と似てるよね じゃあ、docker-compo

もう4年前の話ですが、CloudWatch Logsへのログ送信をWindowsで行う場合の記事を書きました。 CloudWatch Logs on Windows 2012 Server - 続 カッコの付け方 もうこの内容は古くなって久しいですが、なるべく昔ながらのやり方で ファイルを書いてサービス起動する単純さ を貫くやり方を書きます 歴史と概要 WindowsからのCloudWatch (Logs)へのデータ送信の方法は2回変わっています。(当たり前ですが、直接APIを叩けば送信できるのは変わりません。) EC2Config単体時代 これは上記の記事と同じです。EC2Configサービスが、CloudWatch (Logs)への送信機能も持っていた EC2Config + SSM Agentの時代 非常に便利なSSMですが、SSM の管轄として CloudWatch (Logs)

2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で

続々とELBに機能が追加されていますが、今更ですがNLBについて書きます。 今更NLBの記事を書くことに意味があるのか？と自問しましたが、一応 (初心者向け) と (HealthCheck) という切り口で、なるべく優しく書こうと思います。 NLBについて 先に言っておきたいこととして、NLBははっきり言って玄人好みで初見殺しです。いや、死ぬことは無いかも、そもそも思った通りに動かせない。 先にこの記事よりも遥かにレベルの高いものをエントリしておきます。下記を理解出来るレベルであればこのエントリは用済みです。 kanny.hateblo.jp dev.classmethod.jp dev.classmethod.jp HealthCheckについて 早速本題です。 HealthCheck と ELB(TargetGroup)はセットで切り離せない存在ですが、NLBにSecurityGrou

CloudWatchのプリセット(ビルトイン)メトリックスに関する記事です。カスタムメトリックスには殆ど触れません。 世の中には2つのタイプの製品があると思います。 説明書を読まなくても使える 説明書を読まないとハナから使えない AWS CloudWatchは 明らかに前者ですが、この手のプロダクトはテキトーに触りだけ覚えてわかったつもりになるケースが極めて多いです。このエントリで わかったつもり から ちゃんと理解した の橋渡しをします。 重要なポイントの先出し メトリックが定時観測型なのか、随時記録型なのか見極める メトリックスの 1サンプルの値 は必ず1なのか確認する EC2のMC(マネージメントコンソール)の特徴と落とし穴 定時観測型? 随時記録型？ 両方共私の造語です。 定時観測型とは、RDS Auroraの qps 等を指します。 このタイプの特徴は、統計の種類 Average

8月下旬、 Google Cloud SQL 2nd Generation がGAとなりました。すでに検証はしていますが、今回は Cloud SQL Proxy を中心に書きます。 iga-ninja.hatenablog.com Cloud SQL Proxy とは？ 前回の記事でも記載しましたが、Cloud SQL への接続は全てグローバルIPアドレス となります。これに嫌悪するひとは多いと思いますが、この点はどうすることも出来ません。で、GCEのVMからアクセスする場合、は2つの方法どちらかをとることになります。 特定IPアドレスからのみアクセスを受け付ける(グローバルIPのみローカルIPは意味ない) Cloud SQL Proxy を使う 1を採用したでも、GCEの特定VMからのみだときまっていたり、スケールアウトは考える必要がなく、固定台数でのみサービスする場合は、あまり問題はあ

「パイセン、JSONで帰ってくる複雑な構造のオブジェクトをいい感じにするやつしらないっすか？」 「ああ、複雑な構造ね。しらん、専用の関数用意するとか？」 「やっぱ、そっすよねー」 全国津々浦々でこんな会話が繰り広げられてると思います。私も2回ぐらいこのやり取りをしました。この長年の問題に終止符、JMESPath最強じゃね？ JMESPathとは 以前、一回書いてます iga-ninja.hatenablog.com この時私は勘違いしておりました、JMESPathはJSONだけを捌くライブラリではなく、JSONから素直にコンバート出来る各言語のオブジェクト を捌くことが出来ます。pythonで言うなら list と dictで出来てるものなら JMESPathでクエリ出来ます。# setとかは知りません。 似たようなのに jq コマンドがありますが、JMESPathのほうがいいです、多分。

ngix + php-fpm の組み合わせで特に Errorログについて整理しときます。 初心者向け補足 プール向け設定ファイル = /etc/php-fpm.d/www.conf 全体の設定ファイル = /etc/php-fpm.conf php-fpmのログまとめ error.log php-fpm 全体で出す Errorログです。これは global ディレクティブでしか設定出来ません。 このファイルは、デフォルトでは各プールの標準エラーなどを出力されることはありません。各プールのエラーを出力したいならば catch_workers_output = yes を、プールの設定ファイルに記載します。 ただし、このパラーメータには注釈があります。 ; Redirect worker stdout and stderr into main error log. If not set, st

すでに何度が触れていますが、GCE HTTP(S) ロードバランサー が更にアップデートされました。同じく、 HTTP(S) ロードバランサー限定で Cloud CDN というサービスも有効となりました。 GCEでHTTPS負荷分散 SSL Termination - 続 カッコの付け方 GCP リージョン跨ぎロードバランサーの破壊力 - 続 カッコの付け方 HTTP(S) ロードバランサー追加機能 以前の記事で 1つのIPアドレスで 80 & 443を Listen 出来ない と書きましたがこれは解消？されているようです。この場合、エフェメラルではなく、静的なIPを1つ取得して、 80にも443にも指定すればOKです。これでよくある(AWS ELBのように) 1つのELBで 80/443 を両方通す設定が可能です。 また、この変更？により、http/httpsの違いによる x-forwa

昨年の12月頃らしいですが、GCEでもSubnetがサポートされました。最初、これを知った時 なんて無駄な機能をつけたんだ！Googleのパワーをこんなしょうもないことに使うな と思いましたが、調べてみるとGoogle流の考慮は入っていました。 ひとまず、このエントリに引っかかった人は、最後まで読んでください。tl;dr とかでは表せませんが、無理やり概要をまとめると、 GCEもsubnetという太古のダサい技術をサポートしてしまったが、他のパブリック・クラウドとは一味ちがうから安心して！ となります。 今までのGCE:Network GCPドキュメント上では、Legacy mode と書いていますが、こちらのほうが よっぽど先鋭的 です。簡単にまとめると ローカルIPアドレスの CIDRだけ指定する そのCIDRは全リージョンにまたがる たったこれだけです。AWSで言い換えると 全リージ

BeanStalk標準で入っているロギング機構についてまとめておきます。公式ドキュメントにも記載が少ないので、難儀しました。注意点とて、EBのバージョン次第で詳細な数字が変わっています。(例えば10MBのローテーションは、以前は30MBでした。ファイル名も変わってます)よって、ある程度わかってらっしゃる人向けのネタになってますので、その点よろしく。 ログの種類 EBには4種類のログがあります。 bundle-log マネジメントコンソール(以降MC)のebの画面から取得できるログです。ユーザーが取りたいときに 能動的に取る ログとなります。Fullを指定した場合はこちら。 tail-log マネジメントコンソール(以降MC)のebの画面から取得できるログです。こちらも能動的取るログですが、bundlelogと違って直近100行のみとなります。 publish-log 一般的にログローテーシ

GAEのために出来た、という歴史的な背景からもあまりGCEから使うこともなかった Cloud SQL (1st generation)ですが、昨年 2nd generation がベータとなりました。パフォーマンスの高さについてはアナウンスされていますが、この記事はFailOverを中心に、2nd generationを探っていきます。 Cloud SQLとは AWSで言うところのRDS、マネージドSQL(RDB もっと言うと MySQL)です。VMインスタンスに自前でMySQLを入れるよりも勿論割高ですが、バックアップとかフェイルオーバとかの面倒をGoogleが見てくれるというものです。 最初に結論 アクセスIPアドレスは、相変わらず Global IPのみ アクセス元IPアドレスで制限 GCEの内部ネットワークに作成は出来ないが、GCE内から接続する分には、ネットワーク速度的なペナルテ

GCPあるある 久しぶりにDevelopers Consoleにログインして新機能実装に気づく。 一応RSSとか購読してるんですが、ほんとにこのパターン多い。今回はCloud Logging (& Cloud Monitoring)です。以前にLog監視できたらいいなーとか、Pub/Sub + GAE でログ監視ができる！と言ってたのですが、ノンプログラミングでできるようになりました。 仕組み Cloud Logging も Cloud Monitoring も本ブログで触れています。Cloud Logging は AWSの Cloud Watch Logs に似た仕組みですが、Cloud Logging自体にはLog監視機能がありませんでした。今回の機能追加でかなりの部分が競合するシステムとなりました。 今回のログ監視の仕組みもほぼ、AWSの Cloud Watch Logs と同じです

AWSを始め、ほとんどのパブリッククラウドはmulticastが出来なくて不便。と言われてきましたが、だったらunicastでやってしまえば良い！という考え方が 2013年頃すでにありました。なぜmulticastをやりたいの？と言うと そうだね！、LVS + keepalived だね！ (あとはゴシッププロトコル) これまた2年前に EC2 + LVM (DSR) を実践してみたという素敵な解説があり、パッチを当てればいける ということは知ってたけど、月日がながれて 今日keepalivedの総本山を見てみたら http://www.keepalived.org/changelog.html Release 1.2.8 ぐらいからunicast対応してますね。というか、今更開発が活発になってきたのか？これは。というわけで、最新版の 1.2.19を使ってみます。 予備知識 EC2でmul

VPC flowlogという機能が最近リリースされました。SGを通過した・蹴られたのログが取れるというものです。これ自体はとてもありがたいのですが、ログの閲覧はCloudWathLogsからとなり、コレがイケてない。だから何とかしたという話 どんなふうにイケてないのか CloudWatchLogs上の見え方ですが、こんなかんじです。 フィルタで頑張ることも出来なくはないのです。たとえば80ポートへのアクセスで絞るなら[スペース]80[スペース]とかでフィルタかければなんとかいけます。ただ、Unixタイムスタンプはキツイよねー で作りました gist.github.com 機能解説 ローカル実行可能 Credential別サーバに投げるとかない ローカルにおいたhtmlファイルを、ブラウザで叩いてOK。Web Storageとかも使ってない(使えてない) ローカルファイルとしてJSONダウン

世の中の全てのデバイスがipv6グローバルIPアドレスを持つ時代が来る。そんな時代が来ると考えていた頃が私にもありました。 2015年になった今も、残念ながらipv4が主流のままです。また、足らないグローバルIPやら、本当はグローバルIP同士でやるべき通信をipv4で何とかしようとする技術は沢山あります、が 小手先の技術ではなく、本当に膨大なグローバルIPを割り当てる方法および実装は、ipv6以外に2015年時点では存在せず、 djbが書いた大昔の予言どおりの現在であったとしても、v4との互換性がないのがアレだといわれても、2015年の今日、でデバイスレベルで実装があるのはipv6だけです。良い、悪いは置いといて、ipv6以外の代替案が無く、結果的にダメな点が多いと言われるipv6に変わるテクノロジーを作り、協議/策定することが15年たっても誰一人出来なかったというのが、今です。おかげでi

RDSはインスタンスのスペックに応じて、自動でDBパラメータを調整してくれるのが売りでもありますが、どうしても変更したいパラメータがあったりします。有名なところでは max_allowed_packet character_set_xxx 系 この辺りのパラメータや、もっと重いパラメータ(クエリキャッシュの有効化等) 変更時に、DBリブートはかかるのか、かけなくていいのかを検証します。今回はとりあえずMySQLです。 リブートが掛かっていないかの確認 スクリプトを用意しました。しょうもないスクリプトですが、使ってください。 #!/bin/bash while : do dt=$(date) state=$(timeout 5 mysqladmin ping -u<User> -p<Pass> -h<EndPoint>) echo $dt-$state sleep 1 done failov

EC-CUBEをAWS上で運用するとき、良くある構成 今回の構成は SSL Termination を行い、ELB -> EC2(Webサーバ)間ではHTTPS(443)通信を行いません。この場合、EC2側は常にHTTP(80)で通信を受けるので、ユーザーのELBに対するアクセスがHTTPなのかHTTPSなのか普通の方法では判断出来ません。 X-Forwarded-[xxx]ヘッダ ELBを通過するときに、X-Forwarded-Port/Proto等のヘッダが付きます。これを判別することにより見分けることが出来ます。 http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/x-forwarded-headers.html EC-CUBE内部におけるHTTPS判定 EC-CUBEに対してGREPかけると .