kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

これだけやれば大丈夫!! 合同誌を作るための主催者チェックリストを作った

これはなに?

2015年の冬コミにて、ニンジャスレイヤーの合同誌「ニンジャ学会」を作りました

各メンバーの活躍により素晴らしい内容の本になり、無事完売もしたのですが、

自分自身、合同誌の取りまとめをするのは初めてで、色々と手間取ることが多かったので、今後の為にチェックリストを作ってみました

合同誌を作る予定の人も参考にできるように作ったつもりですので、よかったらご参考にどうぞ

前提条件

  • 本の内容と、参加予定のイベントは決まっている
  • 主にコミケ向けです

最初にこころがけ

  • 主催者の独断で決めるべし
    • メンバーと相談する場合も、最初に主催者案を話してそれに合意を取るという形にする
    • 意見から求めると中々決まらず大変(特にweb上だけで相談する場合)
  • ただし お金のことについては、全員の合意をきちんと取ること
    • トラブルの元になるので、ここはしっかりと
  • 手の内は明すべし
    • ただ「こうする」と伝えるのではなく、「こう考えているので、こうする」など、自分が何を考えて何を目指しているのかを明確にする
  • 複数のことを同時に相談しないこと
    • 大体前の話題が有耶無耶になります
  • ここに書いてあることを一人で全部やろうとしないこと
    • 燃え尽きます
    • その道のプロがメンバーにいたらお願いする
    • いなくても、手分けしてやってもらおう!
  • 気負い過ぎないこと
    • 後手後手でもまぁなんとかなります
    • メンバーもサポートしてくれるよ!
  • 楽しんで!!

メンバー募集前に決めること

  • □ : 参加メンバーに掛かる費用/報酬
    • お金のことは一番最初に告知/同意を取ること
    • こういう費用がかかるよという説明ができるように
      • サークル参加費と印刷費を折半するとか
    • 具体的な金額については今後詰めるということを説明すればよい
  • □ : 参加メンバーにお願いすること
    • 大抵は本文と、自己紹介テキストくらいなはず
  • □ : 本文以外に募集したいメンバー(必要ならば
    • 表紙/イラストなど
  • □ : 参加メンバーの上限(あれば

参考 : 費用/報酬の例

ニンジャ学会の場合

  • 売上-費用の差額をメンバーで割った額をイベント終了後に精算
  • 印刷された本2冊
  • イベント終了で一旦〆て、委託については後日相談

リスク/リターンを分散した

他のサークルで見た例

  • 費用、売上は主催者持ち。参加メンバーには本を1冊

主催者にリスク/リターンが集中するタイプ

メンバー募集前に決めておくとよいこと

メンバー募集中に決めても良い

  • □ : メンバー募集のしめきり
  • □ : 頒布後のメンバー作成分の原稿の扱い
    • 他の同人誌に寄稿してよいか? webで公開して良いか?
    • ニンジャ学会の場合、イベント終了あと半年したら自由にしてよいとしたはず(うろ覚え

メンバー募集の告知の時にやること

  • □ : 立ち上げ告知の為のtwitterアカウントやwebサイトの用意
    • メンバー募集後は、頒布情報の告知先になる
  • □ : メンバーの募集方法を決める
    • blogのコメント、メール、DMなど
  • □ : 告知してメンバーを募集
    • 鉄は熱いうちに何度も打つのが良いです
    • なんかのイベントで話が出たならば、1週間以内に告知したほうが広がり方も参加人数もだいぶ違うはず
    • みんなもイベントの時の勢いで参加してくれる

メンバーが集まったあとにやること

  • □ : メンバー間の連絡方法を決める
    • メンバー全員が使い慣れているツールの方が良い
    • PC、スマホ両方でつかえるツールが良い
    • ニンジャ学会の場合、twitterのグループDM
      • 手軽
      • 複数の話題を並行にすると混乱するという弱点が...
  • □ : メンバー間の連絡方法をメンバーに告知
  • □ : 制作物をやり取りする方法を決める
    • ニンジャ学会の場合、COREDRIVE
      • 無料
      • 全員がtwitter使いだったので、twitterアカウントでログインできたのが決め手
  • □ : 制作物をやり取りする方法をメンバーに告知
  • □ : おおよその作業しめきりを決める
    • 印刷所確定前にざっくりで良いので決めておく
    • ノンブルを振ったり目次を作ったりする必要があるので、ギリギリにはしないこと!
  • □ : 作業しめきりをメンバーに告知
    • おおよそであり、印刷所確定後に詳細が決まる旨も通知する
  • □ : 提出フォーマットを決める
    • 各メンバーが作成できるフォーマットにすること
    • プレーンテキスト? pages? PhotoShop?
    • 必ず最後に編集者が手を入れる必要が出てくるので、編集可能なフォーマットにすること!
  • □ : そのフォーマットを使えないメンバーの為の代替え案も考えておく
    • メンバーからその旨連絡があってからでも良い
  • □ : 提出フォーマットをメンバーに告知
  • □ : 落選の場合どうするかをメンバーに告知
    • 「落選したら考える」でも良い

メンバーが作業しているあいだにやること

  • □ : 出納帳の用意
    • この辺からそろそろお金のことが出てくるので用意しておく
    • googleスプレッドシートがオススメ
      • 共有できる
      • 複数のPCからチェックできる
  • □ : 印刷所の検討
    • 経験者が居る場合、その人が使ったことがある会社の方がトラブルは少ないはず
    • クレジットカードが使える方が、販売後に現金を支払うことになるので便利
    • ニンジャ学会の場合、栄光印刷でした
      • 最初に話題に上がったから
      • クレジットカードが使える
      • 早割がある
  • □ : 印刷種別の検討
    • 決めることが多いので、他メンバーのこだわりがない限りは主催者の独断でさっさと決めること!
    • 本のサイズ(B5? A5?)
    • 綴じ方向(右綴じ? 左綴じ?)
    • 表紙つや有り? マット加工? 箔押しなどの特殊加工はする?
    • 表紙、本文の紙の種別など...
  • □ : 奥付の作成
    • タイトル、発行日(イベントの日)、発行者、連絡先、印刷会社
  • □ : サークルカットの作成
  • □ : イベント参加登録
  • □ : イベント参加登録した旨を外部に告知
    • これ以外にも、何か進捗がある毎に要所要所で告知をすると熱量が下がらないので良い
    • メンバーの士気も向上する
    • 主催者も楽しい!!

印刷関係の色々

  • □ : 印刷所を独断で仮決定する
    • 印刷部数、締め切りの見積もりの為に必要
  • □ : 頒布価格を独断で仮決定する
  • □ : ページ数を独断で仮決定する
    • メンバー1人あたり4ページで... みたいな感じで
    • 同人誌の場合、表紙+裏表紙で+4ページなので注意すること
  • □ : 印刷部数を決める
    • メンバー数 x 渡す冊数も考慮
      • ニンジャ学会の場合、9人 x 2冊で、18冊だったので意外に大きかった
    • 委託もだしたいならその分も考慮
    • 経験者がいればそれに従うのが吉
    • 仮決定した印刷所の場合、それでいくら位になるのかメンバーに告知
    • また、仮決定した頒布価格の場合の損益分岐点もメンバーに告知
    • 全員の合意を取ること
  • □ : 頒布価格、印刷費、印刷所を決める
    • 全員の合意を取ること
  • □ : 最終締め切りを決める
    • ある程度はバッファを考えておくこと
  • □ : 最終締め切りをメンバーに告知

ぽつぽつ原稿が上がってきたころにやること

  • □ : 表紙を作る
  • □ : 掲載順序を決める
    • こだわりがなければ50音順で
  • □ : 上がった原稿を各メンバーで見て確認
    • 誤字脱字はないか?
    • 内容、フォーマットに不備はないか?
    • 印刷上はみ出てしまうところはないか?
  • □ : 上がった原稿の一部を外部に告知
    • 他の人の原稿を使う場合、告知に使ってよいか確認すること
    • 定期的にちょこちょこ上げることで、熱が保たれる
  • □ : まえがき、あとがきが必要なら作る

締め切りが近づいてきたらやること

  • □ : まだ上がっていないメンバーのフォロー
    • 個別にメッセージを送ること
    • いつまでにできそうか、予定だけでも教えてもらうこと
    • 何か障害があればこちらで手伝えるか確認すること
  • □ : 真の締め切りの告知
    • ここまでにいただけないと編集作業が間に合わないという日時を告知
    • とはいえ一方的にならずに、柔軟に対応すること
    • 一緒に作業をしているという気持ちで

原稿が揃ったらやること

  • □ : 印刷価格をメンバーに告知
    • ここで最終的なページ数が確定するので
  • □ : 目次の作成
  • □ : ノンブルづけ
    • 本文は3ページ目から!
  • □ : 自己紹介の編集
  • □ : 原稿ファイルを作成する
    • 印刷所毎に求められているフォーマットにすること
    • ニンジャ学会の場合、本文はPDF、表紙はTIFF
  • □ : 原稿ファイルの確認
    • 全メンバーに目を通してもらうこと
    • 乱調落丁はないか?
    • 誤字脱字はないか?
    • 目次間違いはないか?
    • ノンブルは正しいか?
  • □ : 作成環境の確認
    • 原稿ファイル作成に使用したアプリのバージョンを印刷所に報告する必要がある
  • □ : 印刷所に発注
    • 部数、綴じ方向、発送場所/日時に間違いがいないことを、発注情報のスクリーンショットを取ってメンバーと確認するとよい

イベント前にやること

  • □ : 売り子として参加できるメンバーを募集
    • 朝一で設営に参加(サークルチケットの数で上限がある
    • 途中から参加
  • □ : 売り子の予定、都合を確認
    • 何時頃には買い物に出たい
    • 最初に買い物した後に合流したいなど、ざっくり把握しておく
  • □ : 後から来た売り子との入れ替えについてざっくり決めておく
    • サークルはそんなに広くないので4人が限界
    • 3人以上来たら、誰かが抜けるなど
  • □ : 設営に参加メンバーとの集合場所、時間を決めておく
    • ニンジャ学会の場合、国際展示場駅左側の待ち合わせエリア
    • サークルチケットを渡している場合、サークル集合でも良いかも
  • □ : 打ち上げの有無の告知
    • よっぽどの大人数でない限りは予約はしなくて良いと思う
    • 後からメンバーが合流したり、混雑具合で終わる時間も変わったり
  • □ : 値札を作る
  • □ : 100円ショップで値札を立てる奴を買ってくる
  • □ : ポスターなどアピールするものを作る
    • とりあえず表紙をA4で印刷するだけでもよい
    • どんな内容なのか簡単に説明したA4くらいの紙も
  • □ : テーブルに引く布を買う
    • コミケの場合、45x90cmなので、前後に垂らす為に、2m位あれば十分
  • □ : 手元を隠せるようなものを用意する
    • お釣りや、販売部数をチェックする紙を隠せるもの
    • 今回無くてちょっと困った
    • 100円ショップの棚に布をかぶせると良いかも
  • □ : お釣りを作っておく
    • 600円で頒布する場合、100円玉を20枚くらい
    • 500円で頒布する場合、500円玉を10枚くらい
  • □ : お釣りを入れるものを用意する
    • ニンジャ学会の場合100円ショップのタッパー
  • □ : 売上を入れるものを用意する
    • 1000円冊などお釣りにはならないお金を別にいれるもの
    • ニンジャ学会の場合100円ショップのファスナー付き袋にチェーンを付けて、テーブルに繋いでおいた
  • □ : 簡単に実際のサークルの設営のイメージを掴んでおく
    • 設営の手伝いに来てくれた人に指示できるようにしておく
    • 家の机で実際に作ってみて写真を撮ると良いかも
  • □ : 取り置き依頼の方のためのチェックリスト
    • お名前、部数、引き渡し済
  • □ : メンバーに本を渡すためのチェックリスト
    • お名前、引き渡し済、打ち上げ参加有無
  • □ : サークルや同人イベント初参加の人に注意事項を説明できるようにしておく
    • 特にお金の渡し方とか
    • ニンジャ学会の場合は以下の様なしおりを用意した ニンジャ学会サークル参加のしおり_-_Google_ドキュメント_-_Vimperator.png
  • □ : 見本誌票の準備
  • □ : (コミケの場合)サークル証に情報を書いて判子を押しておく
  • □ : 自分達のサークルの位置をチェックした地図
    • これを持って行かなくて少し困った...
  • □ : 赤字/黒字の場合の渡し/支払い方法を決めておく
    • 振り込み、郵便小為替など
  • □ : 書店委託を出すならばコンタクトを取って、見本となるデータを渡しておく
    • 後日、何部送ってくれと連絡がきます

その他イベントに持っていくもの

色んなサークルさんがblog等で教えてくれているのでそちらも参考に

  • □ : はさみ、カッター
  • □ : 布ガムテ、両面テープ
  • □ : ペン、マジック
  • □ : 付箋紙、ノートなど書くもの
  • □ : クリップボード(売上票やメモを挟む
  • □ : ティッシュ、ウエットティッシュ
  • □ : お菓子、ティッシュ、ペン等をいれられる箱的ななにか
    • すぐ取り出せるようにするととても便利
  • □ : 行動食、飲み物
    • あると便利
  • □ : ゴミ袋
  • □ : 100円ショップで売ってる頑丈な紙袋
    • 本を取り分ける時や、郵送時に包むのに便利

当日、設営時にやること

  • □ : メンバーと合流
  • □ : 入場
  • □ : 印刷物に問題がないか確認
  • □ : チラシをまとめる
    • 大体自立する大きめの紙袋があるので、そのままゴミ袋にすると便利
  • □ : スタッフさんが来たら、見本紙とサークル証を渡す
  • □ : 設営作業
    • 設営完了したら写真を取って告知すると良い
  • □ : 委託分、取り置き分、メンバーの分の本、+5冊くらいを先に分けておく
    • 後からやったら、少々辻褄が合わなくなって慌てました
    • なんかあったときの為に予備をとっておくと良いです
      • 完売後に世話になった人が来たとか、取り置き漏れとか
  • □ : 意識合わせ
    • 購入数チェックの入れ方
    • 取り置きチェックの入れ方
    • 売上、お釣りを入れる場所
    • 後から来た売り子さんへの引き継ぎ方法
  • □ : 隣のサークルさんにご挨拶
    • 本を交換した場合、何冊交換に出したかメモしておく

当日、イベント中にやること

  • □ : 楽しもう!!
  • □ : 後から来たメンバーへの引き継ぎ
  • □ : 自分も遠慮なく買い出しや食事に行きましょう!
  • □ : ずっと売り子をやっているメンバーに声をかけて、買い出しや食事に行けるように
  • □ : 各メンバーに本を渡す

当日、イベント後にやること

  • □ : 完売したら拍手!
  • □ : 余ったらメンバーに分配する量を増やしたり、委託の量を増やしたりして在庫を調整する
  • □ : 販売数の確認
  • □ : サークルの片付け
    • ポスターなどの紙ものは処分したほうが荷物が減って良い
  • □ : 在庫や、委託分、当日来れなかったメンバー分の本を一旦自宅に郵送
    • サークルの物品もまとめて郵送すると便利
  • □ : お金は一旦預かって持ち帰る
    • 疲れた脳で計算しても大体よいことにはなりません
  • □ : 打ち上げ

イベント以降にやること

  • □ : お金の計上
  • □ : 経費-売上の確認
  • □ : 各メンバーに渡す/払ってもらう金額を告知
  • □ : 書店委託を出す場合、書店に本を送付
  • □ : イベントに来れなかったメンバーの本を送付

以上です、これだけやればまぁなんとかなります。 楽しんで!!

Amazon Route 53 ってなんぞ? 特徴と料金をメモ

特徴

料金

  • 25ホストまで、0.5USD/月
  • 25個以上、0.1USD/月

クエリ毎の料金

通常のクエリ

  • 10億クエリまで 0.4USD/100万クエリ/月
  • 10億クエリ以上 0.2USD/100万クエリ/月

レイテンシベースクエリ

アクセス元から最もレイテンシが低いリージョンを自動的に選んでそこに誘導してくれる

  • 10億クエリまで 0.6USD/100万クエリ/月
  • 10億クエリ以上 0.3USD/100万クエリ/月

  • レイテンシ : デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの遅延時間のこと

  • 複数リージョンにおんなじアプリを展開していることが前提
  • なんかすげえ!!

Geo DNS クエリ

設定したルールにもとづいて、ユーザを設定したリージョンに誘導する

  • 10億クエリまで 0.7USD/100万クエリ/月
  • 10億クエリ以上 0.35USD/100万クエリ/月

レイテンシベースと違って、自分で誘導の為のルールを設定する

参考

yumリポジトリにEPELを追加する手順

ダウンロード

ここから対象バージョンのepelをダウンロードする

最新のCentOSならば

wget http://ftp.riken.jp/Linux/fedora/epel/epel-release-latest-7.noarch.rpm

インストール

sudo rpm -ivh epel-release-latest-7.noarch.rpm

yum repolist すると、 epel が増えている

オプション解説

  • i : install
  • v : verbose 詳細情報の表示
  • h : hash 進捗状況をhash(#)で表示する

必要な時だけ使う

基本的にはバンドルされているリポジトリを使って、存在しない時だけepelを使う

デフォルト無効にする

[epel]
...
enabled=0
  • /etc/yum.repos.d/epel.repo

検索、インストール

enablerepoオプションを使う

sudo yum search fail2ban --enablerepo=epel
sudo yum install fail2ban --enablerepo=epel

他の方法

yum-plugin-priorities を使ってリポジトリの優先順位をつける方法もある

yumについて理解が進んでいないのでメモ

CentOSでのパッケージ管理についてのお話

用語

RHEL : Red Hat Enterprise Linux

yum

yum : Yellowdog Updater Modified

RPM Package Managerのパッケージを管理するメタパッケージ管理システム

RPM?

RPM : RPM Package Manager

RedHat系OSが使うパッケージ管理システム

  • 再帰的命名だ!!
  • 昔は、Red Hat Package Manager だったらしい
  • パッケージ : ソフトウェアのバイナリやそれが必要とするファイルをひとまとめにしたもの

なんでRPMから更に1枚噛ませているの?

  • yumは、内部でRPMを呼び出している
  • RPMにない機能をyumは持っている
    • ファイル名より抽象的なパッケージ名
    • インストールされていないパッケージの検索
    • パッケージ同士の依存関係の管理

リポジトリ

  • パッケージを集めて保管している場所
  • CentOSにデフォルトでバンドルされているのは、base, updates, extras, centosplus, contrib の5つ
    • ただし、centosplus, contrib はデフォルト無効
    • base : OSリリース時の状態
    • updates : baseから更新があったパッケージが格納
    • extras : baseに含まれない便利なソフトウェア群

コマンド yum repolist で確認可能

また、/etc/yum.repos.d/CentOS-Base.repo に、デフォルトのリポジトリ設定が書かれている

リポジトリの追加

バンドルされているリポジトリの他に、サードパーティリポジトリを追加できる

  • 利点 : デフォルトにない/新しいパッケージを追加できる
  • 欠点 : CentOS開発チームがテストをしていない

RedHatエンタープライズ向けなので、提供されるパッケージは古めの(枯れている)バージョンが多い

その為、最新のパッケージが欲しい場合、サードパーティリポジトリに頼ることが多い

centOSでよく使われるサードパーティリポジトリ

基本的にはどれか1択。複数サードパーティリポジトリからパッケージを入れると、依存関係がわけわからんことになりがち

EPEL

EPEL : Extra Packages for Enterprise Linux

RPMfusion

Fedora プロジェクトに収録されていないパッケージを提供するレポジトリ

Remi

RHELFedoraに最新のPHPと他のソフトウェアを供給するのを目的としたリポジトリ

RepoForge

  • 旧RPMforge
  • RHEL6で更新が止まってる様子なのであえて使う必要はなさげ?
    • 2015/10現在、RHEL7が最新

参考

AWS Elastic Beanstalkの環境のSWAPをやってみる

環境の作成

dev-env は環境名

eb create dev-env

環境変数

設定

eb setenv SECRET_KEY_BASE=****** -e dev-env

確認

eb printenv dev-env
 Environment Variables:
     RACK_ENV = production
     SECRET_KEY_BASE = ******
     RAILS_SKIP_MIGRATIONS = false
     RAILS_SKIP_ASSET_COMPILATION = false
     BUNDLE_WITHOUT = test:development

アプリで環境変数を使用する

普通に ENV でアクセスできる

参考

デプロイ

ローカルの最新のcommitがデプロイされる

  • master意外のブランチをcheckoutしているならば、それがデプロイされる
eb deploy dev-env

ブラウザで開く

eb open dev-env

環境設定のwebページを開く

eb console dev-env

環境の一覧をチェック

$ eb list
dev-env
* prod-env

より詳しく

$ eb list -v
Region: us-west-2
Application: elastic_beanstalk_demo
    Environments: 2
        dev-env : ['i-96f6da50']
        prod-env : ['i-29c9e5ef']

環境をswapする

環境が使用しているURLを交換する

  • elasticbeanstalkがデプロイするときにはダウンタイムが発生する
  • そのため、別の環境にデプロイして、問題なければ、本番とステージの環境のCNAMEをswapして、ダウンタイムなしに本番環境を最新にする。というのが、elasticbeanstalk Way っぽい
  • Blue-Green Deployment と言うらしい
    • 環境をまるっと切り替える
    • 問題があったら元に戻せば良いだけなので安心
    • ダウンタイムが(ほぼ)発生しない
    • トランザクションの取り扱いについて考慮する必要がある
$ eb swap prod-env -n dev-env

なんかエラー

$ eb swap prod-env -n dev-env

ERROR: InvalidShapeReferenceError :: Invalid model, missing shape reference: OrderedDict([(u'type', u'structure'), (u'members', OrderedDict([(u'User', OrderedDict([(u'shape', u'Double')])), (u'Nice', OrderedDict([(u'shape', u'Double')])), (u'System', OrderedDict([(u'shape', u'Double')])), (u'Idle', OrderedDict([(u'shape', u'Double')])), (u'IOWait', OrderedDict([(u'shape', u'Double')])), (u'IRQ', OrderedDict([(u'shape', u'Double')])), (u'SoftIRQ', OrderedDict([(u'shape', u'Double')]))]))])

色んな所でコマンドラインがうまく動かないという報告が上がってるので、ブラウザでやることにする

参考

その他コマンドメモ

デフォルトの環境を設定

eb use ${環境名}
  • 各コマンドで環境を指定しない場合、デフォルトの環境が指定される
  • デプロイコマンドを実行すると、内部でこれが設定される

環境の停止

お金が勿体無いのでさっさと停止

eb terminate dev-env

TODO

iptables について理解する

iptablesってなんぞ?

Linuxに実装されたパケットフィルタ兼NAT

NAT?

NAT(Network Address Translation)

ネットワークアドレス変換

ローカルIPと、グローバルIPの変換を行う

  • ローカルから外部に出るときに、グローバルIPの割当を行う
  • 外部からローカル内のマシンにアクセスする時に、IPの変換を行う

パケットフィルタ?

送信されてきたパケットを検査して通過/遮断を判断する機能

ファイアウォールとは違うの?

ファイアウォール : 外部との通信制御して、内部のコンピューターネットワークの安全を維持するソフトウェア

有効化する

$ sudo /sbin/chkconfig iptables on

設定の確認

iptables --list を実行

$ sudo /sbin/iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

これは何も設定されていない状態

  • target prot opt source destination はヘッダ。

ヘッダの読み方

policy

チェイン(後述)全体に適用されるルール

  • 上記の場合、 policy ACCEPT で、基本的には通信を許可

用語

  • Chain : パケット群にマッチするルールのリスト
  • ルール : マッチしたパケットに対する処理を規定する
  • target : パケットに対する処理(主に以下の3つ)
    • ACCEPT : パケットをそのまま通す
    • DROP : パケットを破棄
    • RETURN : 同じルールが上位Chainにある場合、そちらを適用

Chain

デフォルトでは INPUT FORWARD OUTPUT の Chain がある

  • INPUT : 受信したデータの扱い
  • OUTPUT : 送信するデータの扱い
  • FORWARD : 他のマシンに渡すデータの扱い

他に自作のChainを作って、上記3つのチェインに連鎖させることができる

Fail2ban であるIPをBANした状態のとき(一部)

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-HTTP  tcp  --  anywhere             anywhere            tcp dpt:http

Chain fail2ban-HTTP (1 references)
target     prot opt source               destination
REJECT     all  --  192.0.2.0  anywhere            reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

空白の取り方がおかしいので見づらい...

  • INPUTfail2ban-HTTP が Chain
  • fail2ban-HTTPでは、192.0.2.0 をREJECT`
  • それ以外は、RETURN
  • INPUT ではその他に何も指定がないので、policy ACCEPT なので、そのまま通す

TODO

  • フィルタの追加方法
  • テーブルについて
  • 設定の定石(普通のwebサーバの場合、どんな設定をすべきか?)

参考

AWS Elastic Beanstalk まずは動かしてみる

AWS CLIツールのインストール

$ pip install awsebcli

Rails環境の用意

$ rails g controller hello index

Rails環境上で、EBS初期化

$ eb init

リージョンどこにするか聞かれる

Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-southeast-1 : Asia Pacific (Singapore)
7) ap-southeast-2 : Asia Pacific (Sydney)
8) ap-northeast-1 : Asia Pacific (Tokyo)
9) sa-east-1 : South America (Sao Paulo)
(default is 3):

AWSのアクセスキーとシークレットトークンを聞かれる

You have not yet set up your credentials or your credentials are incorrect
You must provide your credentials.
(aws-access-id): ********
(aws-secret-key): ********

どのアプリケーションを使うか聞かれる

既存のアプリが残っているので、それを使うか、別のを作るか聞かれた

  • 新しく作ることにした
Select an application to use
1) elastic_beanstalk_demo
2) [ Create new Application ]
(default is 1): 2
Enter Application Name
(default is "elastic_beanstalk_demo2"):

Rubyアプリで良いよな? と聞かれた

It appears you are using Ruby. Is this correct?
(y/n): y

Rubyのバージョン聞かれた

Select a platform version.
1) Ruby 2.2 (Puma)
2) Ruby 2.1 (Puma)
3) Ruby 2.0 (Puma)
4) Ruby 2.2 (Passenger Standalone)
5) Ruby 2.1 (Passenger Standalone)
6) Ruby 2.0 (Passenger Standalone)
7) Ruby 1.9.3
(default is 1): 1

SSH使う? と聞かれる

Do you want to set up SSH for your instances?
(y/n): y

キーペアを聞かれる

Select a keypair.
1) test1234
2) [ Create new KeyPair ]
(default is 2): 1

/.elasticbeanstalk が作られ、.gitignore に追加されるので commit する

$ git diff
diff --git a/.gitignore b/.gitignore
index 050c9d9..964c20f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,8 @@
 /log/*
 !/log/.keep
 /tmp
+
+# Elastic Beanstalk Files
+.elasticbeanstalk/*
+!.elasticbeanstalk/*.cfg.yml
+!.elasticbeanstalk/*.global.yml

デプロイ

$ eb create elastic-beanstalk-demo2

サイトを開く

$ eb open

なんかエラー

A really lowlevel plumbing error occured. Please contact your local Maytag(tm) repair person.

エラーログをチェック

$ eb logs
-------------------------------------
/var/log/puma/puma.log
-------------------------------------
=== puma startup: 2015-09-22 07:37:26 +0000 ===
=== puma startup: 2015-09-22 07:37:26 +0000 ===
[20209] + Gemfile in context: /var/app/current/Gemfile
[20205] - Worker 0 (pid: 20209) booted, phase: 0
2015-09-22 07:42:23 +0000: Rack app error: #<RuntimeError: Missing `secret_token` and `secret_key_base` for 'production' environment, set these values in `config/secrets.yml`>

puma?

EBS環境で使われているデフォルトのwebサーバ → A Modern, Concurrent Web Server for Ruby - Puma

  • 最近はHerokuも採用しているらしい
  • 非I/Oブロッキングな作りの為、スロークエリクライアントアタックに強いとの評判
    • 遅いクライアントが大量に接続されて、全てのワーカープロセスが待ち状態のままにさせられる攻撃
  • なんでまたこんなぐぐりにくい名前を...

この辺が詳しい。 → 最近の Rack サーバ事情について - おもしろwebサービス開発日記

シークレットキーを設定する必要があるらしいので作る

$ rake secret
$ eb setenv SECRET_KEY_BASE=*******

見れた!!!

まずはここまで

TODO

  • puma と、Passenger どちらがよいのじゃろ?
  • リポジトリを更新してから再度デプロイ
    • githubのmasterブランチ更新で自動的にデプロイ
  • デプロイ完了したらslackで通知
  • RDSとの連携
  • stage, product環境をそれぞれ作る
  • CloudWatch使う
  • 独自ドメイン使う

参考