個人的によく使うGitエイリアス、zshキーバインド - 本日も乙
最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは（クラウドしかできない）ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ
個人でもAWS Organizationsを使ったほうが良い理由 - 本日も乙
技術書典11で「Amazon Web Servicesコスト最適化入門 マルチアカウント編」を頒布中です。 techbookfest.org BOOTHでも購入できますが、送料（370円）がかかってしまうので、7/25までであれば技術書典のオンラインマーケットだと送料がかからずお得かと思います。オンラインマーケットだと物理本の発送が8月になってしまいますが、BOOTHは私が発送するので注文後数日で届きます。すぐに物理本が欲しい人はBOOTHまで。 booth.pm マルチアカウントに対する障壁の高さ 個人用途におけるマルチアカウントのメリット 使い捨てのAWSアカウントを作ることができる 検証用環境として活用する GCPのプロジェクトと同じような感覚 マルチアカウントのデメリット アカウントの削除（解約）が面倒 セキュリティ コスト管理 まとめ マルチアカウントに対する障壁の高さ 6/19
AWSアクセスキーを使いやすくする AKM というツールを作った - 本日も乙
作ったのは半年以上前だし、まだ直さなきゃいけないところがあるのですが、普段の業務でかなり重宝しているので紹介します。 何を作った akm (Aws access Key Manager) という、AWSアクセスキーを便利に管理するコマンドラインツールを作りました。Go言語で書かれています。 github.com 何で作った AWSアクセスキーの管理やAWS CLI・AWSアクセスキーを使ってのアプリ開発を楽にするためです。 はじめに断っておくと、本来、AWSアクセスキーを発行すべきではありません。キーが漏洩するとリソースが使われてしまうだけではなく、DynamoDBなどデフォルトではアクセス制限かけていない場合にデータが外部に漏洩するリスクがあるからです。出来るだけIAMロールを使用することを推奨します。 しかしながら、AWS以外の環境(オンプレミス、PC)で開発する場合にはアクセスキーが
Amazon LambdaでCloudWatchのメトリクスをMackerelに監視させる - 本日も乙
[toc] 最近、監視ツール(サービス)をMackerelに移行しました。GUIが見やすいことと監視追加・停止が容易なこと、そしてあらゆる操作をAPIで実行できることが気に入っています。最近リリースされたAWSインテグレーション機能によってEC2、RDS、ELB、ElastiCacheのメトリクス取得と監視がとても楽になりました。 しかし、Redshift、DynamoDB、CloudSearchを使っているのですが、こちらの製品はまだ対応していません。また、RDS(Aurora)の場合、Aurora特有のメトリクスが取得することができません。したがって、メトリクス取得及び監視をMackerelで行うには一工夫する必要があります。 具体的には、定期的(1分間隔)にCloudWatchからAPIでメトリクスを取得して、MackerelにAPIでサービスメトリクスとして登録します。やることは簡
AWSインテグレーションによって削除されずに残ってしまったホストを自動削除する「Mackerenai」をつくった - 本日も乙
(追記) a-knowさんからコメントありまして、AWS側で削除されたリソースは、Mackerelでメトリック取得がされないため、ホスト料金に課金されないとのことでした。 便利ツールありがとうございます！“AWS上で削除してもMackerelで残ってしまうため、ホストの料金がかかってしまいます” これは誤解で、削除済リソースはメトリックも取得されず、Mackerelでも課金対象にはなりません！ https://t.co/xHpTcWU36I— a-know (@a_know) December 12, 2018 改めてホスト数の計算に関するドキュメントを確認しました。 1時間程度以内の間隔で定期的に、アクティブなホスト数をカウントします。 ホストのステータスに関わらず、メトリック投稿APIにアクセスしたユニークなホスト数を計上します。 ホストのステータスを poweroff などにしていて
CertbotでDNSによる認証(DNS-01)で無料のSSL/TLS証明書を取得する - 本日も乙
[toc] Certbot(旧Let's Encrypt)は無料でSSL/TLS証明書を発行できる認証局(CA)です。有効期限が90日(約3ヶ月)と短いですが、コマンドによる自動化が可能で定期的に実行することで常に証明書を更新し続けることができます。 証明書を取得するにあたり、ドメインを自分で管理しているかの認証方式が以下の三つがサポートされています。 HTTP-01 Let's Encryptの認証局からワンタイムトークンを発行してもらい、Webサーバに認証用ファイルを設置する。 認証局からHTTP(80番ポート)でアクセスしてもらい、ワンタイムトークンと認証用ファイルとの妥当性を検証する。 TLS-SNI-01 HTTP-01と同じ方法だが、HTTPS(443ポート)を使用する。 DNS-01 Let's Encryptの認証局から発行してもらったワンタイムトークンを対象ドメインのTX
AWS LambdaでVulsを使おうと試みた話 - 本日も乙
[toc] 本記事はVuls Advent Calendar 2016 18日目の投稿記事です。 概要 本記事は、脆弱性検知ツールVulsをサーバレスで実行しようと試みた内容です。 結果としては、AWS Lambda(以下、Lambda)で実行するには様々な制約があって難しいことがわかりましたが、他の方がさらに発展させてくれると信じてここに公開します。 構成 以下のような構成を考えていました。 Amazon CloudWatch Events ･･･ スケジューラ(いつ実行するかを決める) Lambda ･･･ 脆弱性情報取得 & スキャン実行 S3 ･･･ 脆弱性情報(SQLite)やスキャン結果を保存 VulsはGo言語で書かれていますが、LambdaはNode.js、Java、C# および Pythonでしか動かないため、Vulsをビルドしてバイナリ化することで、Lambda上で実行
Amazon RDSのメンテナンスについて調べてみた - 本日も乙
[toc] 昨年にAWSで体験した、苦い思い出の一つに、Amazon RDSのメンテナンスによる意図しないアップグレードがありました。 EC2インスタンスのメンテナンス情報はメールで来ていたので、RDSなど他のプロダクトもメンテナンスがある場合はメールで通知されるものだと思っていました。しかし、実際はメール通知されることなく、(自分達にとっては)突然メンテナンスが実施されてしまったのです。メンテナンス中はRDSへの接続ができないのでその間はシステムがダウンすることになり、数分間でしたが、影響範囲はとても甚大でした。 Amazon Auroraに移行していたので、Auroraがそういう仕様なのかなと思い、サポートに問い合わせてみたところ、メール通知されるなくアップグレードのスケジュールが行われることがあるため、DescribePendingMaintenanceActions APIを使うこ
CentOSでGit v2系をRPMで作成する - 本日も乙
[toc] 脆弱性スキャンツールVulsをインストールする際、Vulsのバージョンがv0.1.6まではGitのバージョンをv2以上にする必要がありました(最新版v0.1.7でv2以上でなくてもよくなったみたいです)。 CentOSでGitをYumでインストールしようとすると最新のCentOS 7.2でもv1.8.3が最新なので、v2以上をインストールするには自分でソースを持ってきてビルドする必要がありました。しかし、他のサーバも同様にGit v2以上をインストールする際、一つ一つビルドするよりもパッケージでインストールできた方が楽ですよね。 そこで今回は他サーバに配布するためにGitのv2系をRPMで作成してみました。方法等はgit 2.2.0 の rpm 作成方法 - tkuchikiの日記を参考にさせていただきました。参考記事ではCentOS 6.4でしたが、CentOS 7でも同じ方
FluentdからAmazon Elasticsearch Serviceへログ転送する時の注意点 - 本日も乙
昨年10月にAmazon Elasticsearch Service(Amazon ES)がリリースされました。 今まではEC2インスタンスにElasticsearch をインストールして運用していましたが、AWS側でマネージドしてくれるということでとても便利そうだなと思い使ってみました。 動作環境は以下の通りです。 Fluentd 0.10.58 fluent-plugin-elasticsearch 0.9.0 Amazon Elasticsearch Service r3.xlarge 構成としては、各WebサーバからApacheのアクセスログをFleuntdサーバに集約してAmazon ESへ転送するようにしていました。 しかし、FluentdからAmazon ESへ転送する際に途中でエラーが出てしまい、転送できなくなることがありました。 2015-12-14 07:00:55 +
CentOSの起動スクリプトを書き方(+注意点) - 本日も乙
サーバの起動時や停止時に特定のスクリプトを実行したい場合があります。 例えば、起動時に起動した旨をメール通知したり、停止時にログ(/var/log)をAWS S3などのストレージにバックアップで保存したりできます。若しくはApacheやnginxなどを野良ソースからコンパイルしてインストールした場合、起動スクリプトを作成することもあります。 そこで、今回は簡単な起動スクリプトを作成してみます。ただ、起動スクリプトの作成方法はネットで調べればいくらでも出てきますので、簡単に説明してハマりやすいポイントも押さえたいと思います。 今回の目標 サーバの起動時、停止時に特定のスクリプトを実行したい サーバ環境 CentOS 6.4 *1 スクリプトの作成 今回は簡単に以下のようなサンプルスクリプト(jicoman_test)を作成してみます。 起動時と停止時にメール通知するスクリプトです。 \#!/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
