cloudpack の 磯辺(@muramasa64)です。 あるバケットに、別のアカウントから読み書きできるようにバケットポリシーを定義したい。普通に考えると、下記のような感じになるだろう。 { "Version": "2012-10-17", "Id": "Policy1406782030997", "Statement": [ { "Sid": "Stmt1406782027567", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:ListBucket", ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::s3-acl-test", "arn:aws:s3:::s3-acl-test/*" ], "Principal": { "AWS": [ "0

年明けからAuroraに粘着し続けて４記事目、残りカスのような数値を記録しておきます。 RDS/Auroraは起動時間がそんなに早くないですが、スナップショットからの復元は特に遅いと感じたので、データ容量との関係を調べておきました。 スナップショットからの復元時間 いざという時・・・のためでもありますが、より機会が多いであろうテスト用に起動する時のためにも、何GBならだいたい何分で起動するのかを知っておくと、運用上健康的ですよね、ということで。Auroraの管理画面で、進行％を出してくれると最高なんですが、まぁそこまで要求するのもアレなんで、、（ﾁﾗｯ）ただデータを増やして起動するという、不毛気味な検証というかデータ採取をしてみました。 sysbench と INSERT ～ SELECT でデータ容量を倍増させてはスナップショットを取得。そして１つずつ起動時間を計測していきました。 起動

こんにちはみなさん サービスを更新するとき、ときには現時点でのデータベースのデータ構造に手を入れる必要が出てくるかもしれませんが、そんなときは必ずバックアップをとっておくものです。 随分前であれば、mysqldumpとかを使って生のダンプファイルを取っておいて、復旧時はそのダンプファイルを入れ直すというふうにやっていたと思うのですが、AWSのRDSではスナップショットを定期的に、もしくは能動的に取得することができ、このスナップショットからDBを復元するという手段があるので、それを頼りにする場合があるでしょう。 私の場合は、コンテナ運用時にはそもそもRDSへ直接アクセスする手段を封じていますので、スナップショットによる復元以外には (セキュリティグループの設定を変えたりしない限り) 方法がありません。 そんなわけで、RDSでスナップショットからDBを復元するときに、引っかかりそうになった部分

「S3 + Route 53」の組み合わせで独自ドメイン運用しているサイトにhttpsでアクセスしたい！と思って調べたところ、CloudFrontを使用すればできることがわかった。 実は、「AWSで静的ウェブサイトをホストする」のステップ6でCloudFront を使用してウェブサイトを高速化する方法が紹介されているが、自分がテストするだけなので高速化は不要だと思ってCloudFrontの設定をしていなかった。 ウェブサイトの高速化に興味がなくても、「S3 + CloudFront + Route 53」に変えるだけでSSL化できるし、なんとこの構成は「AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む）」で紹介されている横綱＝最高の構成になるらしいので、検証してみる価値あり。 ちなみにCloudFrontはCDN（コンテンツ配信ネットワーク）サービスと紹介されているが、

AWSのS3って単純にストレージとして利用している人も多いと思いますが、html/js/cssだけの静的なウェブサイトやホームページ、アプリなんかはs3でホスティングした方が、落ちることもないし、良いと思う。 S3での静的ウェブサイト公開 S3でバケットを作成 html/css/jsを配置する バケットのプロパティ[静的ウェブサイトホスティング]で[ウェブサイトのホスティングを有効にする]を選択し、トップページにしたいhtmlとインデックスドキュメントに設定する バケットのプロパティ[アクセス許可]で[バケットポリシーの編集]を押し、下記を入力 { "Version": "2008-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject",

「ようこそ 魔境 SIerへ！」 はじめに この記事は、SIer（Systems Integrator）に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が２年半1で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 （本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。） 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を

※ 2018/07/21 追記。 お読みいただきましてありがとうございます！ すみません、実はタイトルの割には「現在回しているイケてない運用をちょっとした工夫でサクッと改善する」ことを主眼としており、セキュリティのベストプラクティスではありません。。。 本稿の例で挙げているコマンドのリスクにつきましては、 注意 の項を追加しましたのでご参照ください。 公開当初は「10いいねくらいもらえたら嬉しいなー」と思っていた程度だったのですが、まさかここまでたくさんの方に読んでいただけるとは。。。 もっと内容を精査しておくべきだったと反省しております。。。 いいねやコメント等反応頂けるのはとても励みになります。ありがとうございます！ TL;DR 怖いですよね、セキュリティインシデント。 インフラ系でお仕事をしていると、 Linux にログインして操作する手順書を作る事が多くなります。手順書の中には認証

数ヶ月前、Digdag serverを導入した。 これまではタスクの依存関係だけ解決できればいいよね、というスタンスでDigdagを使っていた。 が、タスクのモニタリングやRetry、並列処理をスムーズにやりたい等が重なりDigdag serverを使うことになった。 ついでにCentosが6だったので7にアップグレードしている。 自分が躓いた点について書いてみた。 DigdagをDaemon化するためのSystemd設定 [Unit] Description=digdag [Service] Type=simple PIDFile=/run/digdag.pid ExecStart=/bin/bash -l -c 'EMBULK_ROOT=/apps/ipros-embulk/current ~/bin/digdag server --max-task-threads 2 --confi

以前はVagrantを使ってansibleのテスト環境は用意していたんだけど、 vagrantはsnapshotが取れる利点がありつつも、VMを使うのでちょっとというかそれなりに遅くて、 何度も実行するansibleのテスト環境にはちょっと不便だなーと思っていたのですが、 最近Dockerを使ってsshdを起動するだけの環境を用意すれば簡単にテスト環境が作れて便利だったので書いておきます。 Dockerfileを書く ansibleを流す対象のイメージは Dockerfile の FROM に書いておけばよくて、 CentOSとかDebianとか好きなOSを選べばいいと思います。 Dockerfileを置いたディレクトリに id_rsa.pub を置いておくと authorized_keys にコピーされるというソリューションです。 FROM amazonlinux:latest MAIN

コンニチハ、千葉です。 Route53には、独自に拡張したレコード「ALIAS」があります。 Amazon Route 53のALIASレコード利用のススメ エイリアスリソースレコードセットと非エイリアスリソースレコードセットの選択 ALIASレコードの詳細については上記ブログを参照ください。 ALIASレコードを設定していて、「あれ、TTLを設定する項目がないなぁ」と思って調べてみました。 エイリアスリソースレコードセットが CloudFront ディストリビューション、Elastic Beanstalk 環境、ELB ロードバランサー、または Amazon S3 バケットを指し示す場合は、有効期限 (TTL) を設定できません。Amazon Route 53 は、CloudFront、Elastic Beanstalk、Elastic Load Balancing、または Amazon

Amazon S3 は、全てのリクエストをリダイレクトや、パスに応じたリダイレクトを設定できる機能を持っています。これは Static Web Hosting という設定を入れることにより実現可能です。実際の技術詳細については以下の公式ドキュメントを参照してください。 公式ドキュメント: https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html リダイレクト設定 gochiusa.53ningen.com に対して gochiusa.com へのリダイレクト設定作業は以下の 3 STEP です S3 バケットを gochiusa.53ningen.com という名前で作成する Static Web Hosting 機能を有効にして、すべてのリクエストを gochiusa.com にリダイレクトする設定

2018年7月12日、三重県津市で開催のJANOG42ミーティングでの発表資料です。 その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 https://www.janog.gr.jp/meeting/janog42/program/OPE 詳細: https://www.opslab.jp/publish/20180712-janog42.html 以下の方々と議論し、多くの知見を得ることができました。(敬称略) - 長久 勝 (国立情報学研究所) - 今井 祐二 (株式会社富士通研究所) - 畠山 慎平 (エヌ・ティ・ティ・コミュニケーションズ株式会社) (運用設計ラボ合同会社 波田野裕一)

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

You have mail in /var/spool/mail/root というメッセージを見たことがあるでしょう。 cronを起動するとmailが送信されます。 そして例えば、１分毎にcronを起動したりすると、 気づかないうちに恐ろしい数のメールを受信しておりディスクを圧迫します。 cronの実行時にmailを受信しなようにするには２つの方法があります。 １．crontabの設定を変更する crontabにある MAIL= の値を “”(空) に変更します。 [root@localhost neko]# vim /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin #MAILTO=root MAILTO="" HOME=/ # For details see man 4 crontabs # Example o

Route 53 の設定を定期的に S3 バックアップする仕組みが構築できたため、使用したツールやスクリプトを紹介します。 AWS Lambda への実装も考えられますが、今回はサーバ上での定期実行としています。 S3 バケット作成まずはバックアップ格納先の S3 バケットを用意します。 バケット内に Route 53 専用のディレクトリを作成しました。 S3 書き込みポリシー作成必要なディレクトリにのみ書き込める権限を用意します。 以下のような IAM ポリシーを s3-backup_route53 として作成しました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::hoge-backup/route53/

Route53に登録されている情報を調べる AWSCLI使っているけどjqの使い方がメインの話 HostedZonesを調べる

ベルリンの半瀬です。 はじめに 題名の通りですが、アカウントを跨いだS3転送についてEc2からコマンドラインでの実行確認を行いましたので、そのメモを残します。 以下の過去記事とAWSドキュメントを元にしました。 How do I transfer ownership of Amazon S3 objects to a different AWS account? | AWS クロスアカウントで S3 sync するための権限設定 | Developers.IO やってみます 以下のような形で実行します。EC2は送り先で起動。 簡単です。と言いつつもポリシーの記述間違いでハマったことは内緒です。 送信元(Source)の情報 AWS Account ID : 111111111111 S3 Bucket : test-s3-sync-src (Frankfurt) 送信先(Destinati

概要 大井競馬場に行く機会があったので、機械学習を使って競馬の結果を予測できるかをやってみました。 その結果、帝王賞で一位を当てることができたので、記事を書きます。 かなり適当な予測なので、遊びとして見てもらえたらと思います。 証拠 当たったという証拠に、記念でとった馬券画像。 機械学習で予測したものと、パドックを見て予測したものと、２つ買いました。 (びびって複勝、しかも300円) 問題の設定 大井競馬場で行われる帝王賞の１位のみを当てます。 競馬には、色々な馬券の買い方がありますが、今回は簡単でシンプルな問題設定としたかったので、1位のみを予測することにしました。 データの取得 教師あり学習を行うので、過去の競馬結果のデータが必要です。 こちらのサイトからデータをクローリングしました。 南関東4競馬場公式ウェブサイト レース情報のページから、レースに出る馬の過去情報があるページへのリン