はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OpenStack を使えば AWS のようなインフラがオンプレミスでも簡単に利用できます。しかしながら、OpenStackクラスタ 自体について継続的にCI/CDを回すのはとても難しく、ある程度以上の規模になると運用上のボトルネックになることが課題となっております。 この課題を解決するためには、デリバリプロセス自体を Microservice に対応したもの(Kubernetes)に置き換えれば良いのではないか..ということで、2016年初頭あたりから、OpenStack on Kubernetes の PoC (Proof

general_log を定期的にS3へ保管できると便利 RDSでは、パラメータグループに次の設定を追加するだけで general_log がFILEに保管され、 RDS API経由で取得できるので、たいへん便利です。 general_log = 1 log_output = FILE ただし、1時間単位で general_log はローテーションされ、1日以上経ったログは消されてしまいます。このため、ログを長期保管するためには手動またはスクリプト等にて定期的にログを保管する必要がありました。 Lambda を用いて、S3 上ログを簡単に保管 EC2インスタンス等を新たに構築せずログを定期的に保管する方法としては、Lambda Function を用いた実装が、コスト・運用の観点でお勧めです。 既に、すぐに使える Lambda Function が github 上にありましたので、次にま

はじめに 2015年12月にリリースされたOpsWorksのChef12対応(OpsWorks Chef 12 for Linux)、とても便利になりました。chef.ioのblog記事にて紹介されていたDjangoのdeployを早速試してみました。 Chef Community Cookbooks with AWS OpsWorks Chef 12 便利になった点 まず、何が嬉しいのか、便利になった点をまとめます。 OpsWorks内部で使用しているCookBookとの、Namespaceの衝突が発生しない Chef12以降でないと動作しないCommunity Cookbookが使えるようになった Chef searchを用いてAWSのリソース(Stack、Layer、インスタンス、ELB、RDSなど)を取得できるようになった なお、従来から利用できるChef11 Stackではbui