Let's EncryptクライアントAcmeFetch使ってみた
※※後ほど簡易図を追加します※※
今年に入ってからはLet's EncryptのクライアントにすべてAcmeFetchを使っています。
MRTGでおなじみTobiさん作ということで使っています。
Ver. 0.6.1でnginxなど用の中間証明書一体型の出力にも対応したのでご紹介します。
私の見立てで特徴は以下のような点です。
・シンプル
・証明書の取得、更新自体にはroot権限不要
・cfg設定でSNIも指定可能
・実行時に余計なアップデートが走らない
・実行時にCDをおねだりされない :-P
以下、利用手順を示します。
インストール
wget https://github.com/oetiker/AcmeFetch/releases/download/v0.6.2/acmefetch-0.6.2.tar.gz tar xvf acmefetch-0.6.2.tar.gz cd acmefetch-0.6.2 ./configure --prefix=/opt/local/acmefetch make sudo make install
設定
cd /opt/local/acmefetch/etc mv acmefetch.cfg.dist acmefetch.cfg vi acmefetch.cfg
cfgファイルの内容はこのようになります。
{ "GENERAL": { "ACMEstaging": "acme-staging.api.letsencrypt.org", "ACMEservice": "acme-v01.api.letsencrypt.org", "accountKeyPath": "/etc/ssl/private/letsencryptAccountKey.key" }, "CERTS": [ { "certOutput": "/etc/ssl/certs/testCert.pem", "certFormat": "PEM", "keyOutput": "/etc/ssl/private/testCert.key", "keyFormat": "PEM", "chainOutput": "/etc/ssl/certs/testCertChain.pem", "chainrmaFot": "PEM", "commonName": "hoge.example.com", "SITES": { "hoge.example.com": { "challengeHandler": "SimpleSSH", "challengeConfig": { "www_root": "/var/www/html/", "ssh_host": "root@127.0.0.1" } } } } ] }
こちらはapache httpdサーバー環境で、AcmeFetchをlocalのroot権限で実行する想定の内容です。
証明書を配置する権限と、http-01のテストファイルを設置する権限が必要なのでそれぞれ書き込み権限を設定してください。
またssh_hostの部分は鍵認証でパスワード無しのログインができるようにauthorized_keysへの登録も必要です。
SITESの部分で証明書を取得するそれぞれのFQDNに関する設定を行います。SNIとして登録するFQDN用の設定はSITES部分を追加して書きます。
www_root以下に .well-known/acme-challenge というディレクトリが作成され、その中にhttp-01のチャレンジID名のファイルが作成されます。
nginx環境の場合は、cfgから chainOutput および chainrmaFot の項目を削除します。
すると、証明書と中間証明書が一体となった形式で certOutput が生成されます。
cfgができたら実行します。
/opt/local/acmefetch/bin/acmefetch --cfg=/opt/local/acmefetch/etc/acmefetch.cfg (以下は出力例) /tmp/yRAb7m8bc2.cfgGenerating a 2048 bit RSA private key ................................................+++ ...................................................................................................................................+++ writing new private key to '/etc/ssl/private/testCert.key.7302' -----
更新の時は --force オプションも指定します。
/opt/local/acmefetch/bin/acmefetch --cfg=/opt/local/acmefetch/etc/acmefetch.cfg --force
cronで自動実行する場合は、 && systemctl reload nginx などで読み込み反映も行う必要があります。
MRTG同様(ややパースしにくいですが)簡潔なcfgで、動作も分かりやすく使いやすいです。
開発も継続的に行われているので、Let's Encryptクライアントをお探しの方や、お使いのクライアントに(余計なアップデートが同時に行われるなど)ご不満のある方はお試しになってはいかがでしょうか。
StackStorm勉強会 第2回に行ってきました
※発表内のカット部分が判明したり資料が公開されたりした場合は後ほど修正します
3月23日に行われたStackStorm勉強会 第2回に行ってきました。第1回から約半年、他のイベントでもStackStormの名前を見る機会が出てきたので広まりを感じられるかな...と楽しみにしていました。
"Event-driven automation, DevOps way" by Dmitri Zimine氏
ついにご本人に会えました。背も高くて足も長い方でした。
発表内容は、過去のこちらのプレゼンから技術的に細かい部分を省いた感じだったかなと思います。
www.slideshare.net
(4/1追記。資料公開されました)
(まさかDmitriさんから「日本でStackStormを検索すると芸能的な情報が出てくる」ネタを聞くとは..
cf. http://w4yh.hatenablog.com/entry/2016/09/22/104100 )
他のツールとの違いについての話もあり、「DevOpsに最適である」ことが強調されていました。過去のツールやプロプライエタリなソフトウェアと比較して、コードベースのスピーディーな運用を可能とするインターフェースと拡張性で勝る、という説明はなるほどと感じました。
最後にGitHub Starつけろよ、という念押しもありましたので参加されたみなさまはお忘れなく。
Q&A
Q.ST2と一緒に使われることが多いソフトウェアは?
A.モニタリングソフトが代表(Zabbix, Sensu, Nagios, NewRelic)
OSSに限らず、商用ソフトやクラウドサービスも多い(IaaS系に限らず、PagerDutyとか)
補足.でもZabbixのPackはまだ無いですけどね
Q.ワークフローの例がたくさんあると良いのだがそんなサイトはあるか
A.まとまったものは無いが、公式Docのチュートリアルの中でも紹介している。最近はNetworkの例を2つ公開した
Q.商用のBWC(brocade Workflow Conmposer)の売りは?
A.サポートが付くこと、ビジュアル的なワークフロー作成画面が付くことなど
if 自動化するなら then StackStormを使おう! by 小島さん
200機種、30000台を超える規模の社内ネットワーク運用をどう効率化していくか、というチャレンジの中でStackStormを使うようになったというお話でした。
www.slideshare.net
ネットワークを対象とした、監視検知時の初動対応の自動化を実装してみたら数日でできた、とのことでしたがそこまでに至る
- 業務のコード化
- コード化の際に行われたであろう、業務のフローチャート的な整理
- Puppet/Ansibleといった個別作業のツール実装
が行われていたことも大きく寄与していたんだろうなと思います。
最後に「思うこと」として挙げられた点はまったく同意でした。
- 自動化を前提としたワークフローを再定義する必要がある
- syslogベースの場合はベンダー間の差を吸収するべくある程度の標準化や自動化対象の明確化が必要
- 自動化に適した構成管理も必要
運用作業の手順書を見直すと「ログを見て問題無いことを確認する」というゆるふわなものがあって自動化に落とし込みにくい、とかは私も経験しました。私は単体テスト/サービス可用テストが通ればOK、に切り替えましたがネットワークが大規模で切り分けが難しい場合はログをきちんと拾っていく方が明確かもですね。
構成管理についても、ohai的なものをどこまで詳細にどう取得するかは課題になりがちですね。自動収集に変えるためにndp/cdpを有効にしてみたり、それがVxLANを超えられなくて困ったり、とか。OpenStackのPandamanプロジェクトも動き止まってそうですし、アセットマネジメントはさらなるツールが求められる分野なのかもしれません。(逆に、作っては壊す時代だからアセット管理にこだわるなということかもしれません)
自動化/StackStorm取組み事例 by 杉本さん
本家Slackでも発言をお見かけする杉本さんによる、IXでStackStormを導入したお話でした。
www.slideshare.net
主にユーザー加入時の開通作業の自動化が紹介され、ExcelからDBへ、手打ちコマンドからexpectスクリプトへ、といった取り組みを進めていくなかで、各ステップの自動化ツール化はできるがそれをつなぐものが無い、というところへStackStormがうまくはまった、という流れでした。現在はcurlを用いたWebhook送信で開始する仕組みになっているとのこと。
導入した利点として挙げられたのは以下。
- アーキテクチャ全体の見通しが良くなった
- 開発効率が向上した
- 将来的な機能拡張が考えやすくなった
さらに感想やTipsとして
- 学習コストは高め。特にPackを自作する場合
- バージョンアップは早いが対応はしやすい
- コミュニティがオープンで活発
を挙げられました。0.12あたりで失敗して以降いつも作り直していたのでバージョンアップはやってなかったのですが、Upgrade Guide通りで行けるとのことでしたので次はやってみようと思います。
今後の取り組みとして
- アラート対応の自動化
- ネットワーク機器に対する操作のAction化
- StackStorm自体の運用
を考えているとのお話でした。ST2自体も大きな仕組みなので運用は持ち寄りでベストプラクティス考えていきたいですね。
Q&Aで同時実行の制御について確認がありましたが、こちらのPolicy action.concurrencyを使っているとのことでした。
https://docs.stackstorm.com/reference/policies.html
StackStormを用いたネットワーク機器の制御 by 北川さん(社会人一年目!)
納品時の初期設定作業の自動化について、デモを交えてお話いただきました。
www.slideshare.net
Excel Packを用いてパラメータを読み込んで、設定テンプレート/Jinja2とAnsible PackでNW機器への設定投入を行うという流れで、ほぼ標準モジュールを採用されていたので理解しやすいユースケースでした。
Excelから読み込む、という所がsfunaiさんのOpenPIE(https://github.com/oss-laboratries/OpenPIE)を彷彿とさせました。デモでは割とシンプルなシートでしたが、実際に使われているシートがどういうものなのか興味ありました。
....その、なんというか....人はなぜパラメーターシートに勝手に列を追加したりパラメータ欄に日本語コメントをつけたりするのだろうか(過去にExcelをパースする仕組みで破綻した人)。
最後に触れられていましたが、Webフォームなど制約をかけやすい形でinputデータを得たほうが入力加工はしやすい気がします。
懇親会でのトーク
- 冗長化/可用性をどうするか。
私は可用性はハイパーバイザーに任せると割り切ったチキンです。来週のohtamaさんのお話で詳しく訊けるのかな..
- 踏み台を経由する環境
~stanley/.ssh/configがすごいことになるのは避けたいですよね....
- Workflow途中での失敗時や再実行
JP1のようなジョブマネージャーが活躍する領域ですね。私はWorkflowを小さめに分けるのが好きですが、retry-continueの紹介がありました
Mistral + YAQL — StackStorm 2.2.1 documentation
- スーツの人が多いですね
確かに。日本で知られるようになったのはBrocadeさんに買収されてからなので代理店さん含めた商流での広まりに現場技術者の間での広まりが追いついてないんですかね....もしくは商材としての魅力が大きくてそちら側の人が多く集まるのか
- もっとテッキーな話したいですね
ユーザー会ができるかも?公式ドキュメントと公式ブログがかなり充実しているので、個人的にはそれらの読み解き会とか有益ではないかと思います。
- いただいたロゴのステッカーはもうちょっと小さくて良いと思うのです
所感
使ってる人増えたなー、と感じられたのが何より良かったです。一年前は全然知られてなかったからなぁ
StackStormはあくまでつなぎ役なので、単体でポンと入れれば何かが解決する類のものではありません。どの発表にも共通していましたが、そこに持っていく前段階としてのワークフローの整理や各作業(Action)のツール化がST2を使う使わないに関わらず大事だな、ということも再確認できました。テスト系の話も訊きたかったかな。
あとActionChainがかなり賢いのでActionChainで済ませている人が多い印象でした。Mistralはもちろん、CloudSlangも運用フローチャートから焼きなおしやすくて楽しいですよ。
開催にご尽力された皆様やスポンサー各社など、みなさま大変有益な機会をありがとうございました!
最後に、最近のDmitriさんの発表スライドへのリンクをご紹介しておきます。
www.slideshare.net
www.slideshare.net
StackStormでBINDのアップデートをtwitterに通知する
注) BINDに関する有益な情報はありません。StackStormのピタゴラ遊び編です
概要: BINDの脆弱性情報が出た際に知らせる仕組みをStackStormで作ってみました
要求: (if)BINDの脆弱性情報が出たら(then)知らせて欲しい
仕様: (if)bind-announce MLに件名がCVE-で始まるメールが配信されたら(then)twitterで@メンションツイートを送る
StackStormのemail packと、twitter pack ... ではなく core.local のシェルコマンドで実装してみます。
しつこい注) StackStormを使う興味の無い方は、bind-announceのメールを携帯に転送すれば良いかと
全体設計
環境: CentOS7 + StackStorm 2.2
メール: postfix + dovecot
twitter操作: t(ruby) もしくは twitter gem
今回はピタゴラ遊びなのですべて1台のサーバー上に構築します。メールの確認もlocalhostへのimapなのでtls化は省略します。
StackStormのTrigger設定
StackStormのemail packをインストールします。
st2 pack install email
設定ファイルを編集します。
/opt/stackstorm/packs/email/config.yaml
--- imap_mailboxes: main: server: localhost port: 143 username: USERNAME password: PASSWORD folder: INBOX ssl: false max_attachment_size: 1024 attachment_datastore_ttl: 1800
USERNAMEとPASSWORDは適宜編集してください。
StackStormのemail packはメールの内容に対する条件設定が弱いので、「bind-announce宛に配信された、件名がCVE-で始まる」のような条件指定には他の仕組みを用います。StackStorm勉強会 #1ではSylpheedの仕分けを用いる方法を紹介しましたが、今回は条件に日本語も無いのでprocmailを使ってみます。
メール設定
dovecotの設定
dovecot.conf
protocols = imap pop3 lmtp listen = *, :: base_dir = /var/run/dovecot/ login_trusted_networks = 127.0.0.1/32
10-mail.conf
mail_location = maildir:~/Maildir
10-auth.conf
disable_plaintext_auth = no auth_mechanisms = plain
procmailの条件設定
ヘッダー条件はList-Idも検討しましたが、今回は手抜きでX-Original-Toでマッチさせました。
/home/mluser/.forward
"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #username"
/home/mluser/.procmailrc
LOGFILE=$HOME/procmail.log MAILDIR=$HOME/Maildir/ DEFAULT=$MAILDIR LOCKFILE=$HOME/.lockmail :0 c *^X-Original-To: bind-announce@lists.isc.org *^Subject: CVE* ! user2@example.com
Twitter設定
dev.twitter.com でアプリの登録
専用のTwitterアカウント作成し、API操作用にアプリ登録を行います。
https://dev.twitter.com
に作成した専用のアカウントでログインし、上部メニューの[My Apps]へ進みます。
Name, Description, Website の三項目が必須なので入力します。WebsiteはBotの場合はあまり意味が無いので適当で良いと思います。
Twitter Developer Agreementを確認した上で同意のチェックを付けてから[Create your Twitter application]をクリックすることで登録が完了します。
作成したアプリの詳細ページで、まずはツイート書き込みを行う権限を追加します。
[Application Settings] - [Access level]を"Read and Write"に変更します。
次に、"Keys and Access Tokens"のタブでAPI Key情報を入手します。以下の4つの値が必要になります。
CLIツールのセットアップ
今回はruby実装のt (https://github.com/sferik/t) を用います。
gem install t
ツール(t)の認可を行います。最終的にtを使った操作はStackStormから実行するので、以下の認可設定はstanleyアカウントで行います。
t authorize
ブラウザでdev.twitterが立ち上がってきます。(リモートターミナルで行っている場合はX転送でブラウザが上がってきます)
先の手順でアプリの登録をおこなったさいに得た以下の情報を入力します。
Enter your API key: ここにConsumerKeyを入力 Enter your API secret: ここにはConsumerSecretを入力
すると今度はブラウザ上でtwitterサイトにPINコードが表示されるので、コマンドラインにその数字を入力します。
以上でtが使えるようになりました。アプリの登録情報は /home/stanley/.trc
に保存されます。
試しに自分のTwitterアカウント情報を表示してみましょう。
t whois @アプリ登録用に作成したTwitterアカウント
アカウント作成日時やアカウント名/表示名などが出れば成功です。
t update "Hello World"
で新規tweetができることも確認しておきます。
Tweetするスクリプトの作成
Triggerで検知したメールの件名が引数として渡されるので、$@で受け取って軽くエスケープ処理した上で
tを用いてtweetします。ついでに自分への@メンションツイートとします。
/home/stanley/script/tweet_chofuku.sh
#!/bin/bash # tweet_chouku.sh: This script tweets "cho-fuku" when CVE for BIND has announced." # ST2 trigger: email(imap) # ST" action: shell(core.local) ARGSUBJ=`printf %q "$@"` /usr/local/bin/t update "@自分が普段使っているアカウント $ARGSUBJ" exit
StackStormのRule, Action設定
StackStormのRuleを設定し、該当するメールを受信した後の動きを定義します。
Ruleのyamlファイルは設置ディレクトリに特に規定はありません。
--- name: 'bindcve_to_CLI_twitter' description: 'Tweets when CVE on BIND has announced.' enabled: True trigger: type: email.imap.message action: ref: 'core.local' parameters: cmd: /home/stanley/script/tweet_chofuku.sh {{trigger.subject}}
Rule定義ファイルの中の必須項目や設定項目については公式ドキュメントを参照してください。 https://docs.stackstorm.com/rules.html
一点だけ補足すると、一連の動作の中で変数の参照を行っています。届いたメールの件名をツイートするために、trigger部分で検知したメールが含まれるアウトプットから trigger.subject をaction部分で参照することで件名文字列の受け渡しを行っています。
作成したRuleを登録します。
# st2 rule create bindcve_to_CLI_twitter.yaml
一覧を確認して、以下のような表示があればRuleの作成は完了です。
動作例
@w4yh CVE-2017-3137: A response packet can cause a resolver to terminate pic.twitter.com/h9lOy0N5xr
— alertwatch (@AlertWatch53) 2017年4月13日
(ちょっと変更して、twitter gemを用いて画像とともにtweetしています)
追加したい処理
- ISCのサイトに詳細が出ていたらそのURLもtweetで知らせる
- 対象バージョン範囲を抜き出して該当環境の抽出
- といった処理をActionではなくWorkflowで流したい
今回使ったファイルはGitHub上にも置いてあります。
github.com
StackStorm勉強会に参加&発表してきました
9月13日に行われたStackStorm勉強会に参加&発表してきました。
感想や補足について書き記しておきます。
今年の春頃はStackStormで検索しても日本語ではバンド名/芸名/アルバムなどの作品名しかヒットせずほとんど情報が無かったので、今回100人以上の方が申し込まれたというのは驚きというか感慨というか数ヶ月での変化の大きさを感じました。
私がStackStorm(以下st2と略す場合もあります)を知ったのは去年の春頃です。
今年の年明けくらいから懇親会やLTの場で何度か紹介していたのがきっかけで今回発表の機会をいただきました。
というわけで、内容はこれまでのLTの総まとめをしつつ、これからst2を触る人への
励ましと期待と地雷案内(?)といった感じにしました。
speakerdeck.com
#スライドの色もst2っぽいオレンジベースにしてみました
補足1
HA構成ガイドの図なども出したのでかなり大がかりな仕組みという印象を与えたかもしれません。まあたしかに小さくはないですが、最近のGitLab Omnibusと比べれば見通しやすいレベルだと思います。
以前qpstudyでLTした際に「MongoDBにはヒストリーログやauditが入ります」と言ったところ2つ後のLTで@kuwa_twさんが「Mongoにログ入れんなっつってんだろ」とスライドで叫んでいて大変忍びなかったです。あ、あの、いわゆるログメッセージはテキストに落ちますのでどうか..
補足2
st2はつなぎ役というか裏方的なソフトウェアなので、いろんなものと比較されがちです。発表内で紹介したように公式ブログにも比較記事が多くあります。
ということで、初めてのst2勉強会なのでst2に集中した方が良いかなとも思いましたが、これからst2を使うみなさまも言われるであろう比較論にも触れておきました。
補足3
入力->処理->出力のところで「Northbound API / Southbound API」の表現もしたかったのですが当日言いそびれた気がします。系/システムの捉え方として補足しておきます。
補足4
私の立場は「あまりスクリプト作成が得意でない運用エンジニア、またはiRuleもちょっと苦手なネットワークエンジニアのチームにおいてどうやってスクリプト化を質を保って進めていくか」という問題意識がベースにあります。
Ansible等もmoduleを使ってフレームワークとして活かすことで、シェルスクリプトで起きがちな問題(例: ヌルい正規表現によるバグ、ムラのあるエラー処理)を自然と防ぐのに役立つ素晴らしいツールだと思います。
単体タスクを超えたワークフロー的な処理ではst2が同様にフレームワークとして分岐-合流処理や変数引き渡しといった部分を整理できそう、というところで活かしたいと思っています。
....という問題意識がステ猫さんの2年前のブログにすでに整理して書かれていたりします。
d.hatena.ne.jp
補足5
以前NetOpsCodingでLTした時に、コメントツイをいただきました。
ツールの紹介でGUIが良いって意見をたまに聞くけど、それ使ってたらいつまでもコードに落ちないと思うので、無視して良いと思う。 #NetOpsCoding
— Yasuhiro Yamazaki (@sparklegate) 2016年6月27日
まったくご指摘の通りで、
感想
まだまだこれからのソフトウェアだよね、という感はありつつも多様な話題で登壇されたみなさまとcuriousなご参加のみなさまで面白い勉強会だったと思います。私がひときわ泥臭い発表内容だった感じなのがかなり心配ですが。
拡張Packが豊富なこともあり、利用シーンや重視する機能、トラブルポイントが個々に異なったりすることも予想されますが(Communty Slackでも話題論点が様々です)、st2を通して多くの人が集まってディスカッションしたり課題解決のヒントを得たりする場になると良いなと思います。
第2回が行われたら、ちゃんとした話はいったん出し切ったのでピザが届く系のネタでLTしようと思います。
そう言えばブロケードさん9月1日のOSC.Enterpriseに出展したら良かったのにとも思ったり。
番外
今回も熊本焼酎を差し入れしました。
www.tsuruya-dept.co.jp
手元にはまだおいしい焼酎がありますので、引き続き
インフラや運用系
&& 懇親会に焼酎持ち込み可
&& LTでツールネタ可
というイベントやディスカッションの情報を求めています。
自分用メモ:Monitorama 2016の資料リンク
開幕したMonitoramaが期待以上の面白さです。
動画はアーカイブ公開されると思いますが、
ひとまず資料などへのリンクを随時まとめておきます。
Day1
Monitoring Challenges
http://www.slideshare.net/adriancockcroft/monitoring-challenges-monitorama-2016-monitoringless
Monitoring is Dead
https://speakerdeck.com/grepory/monitoring-is-dead
https://github.com/grepory/monitorama2016
How Metrics Shape Your Culture
http://www.slideshare.net/nicolefv/2016-metricsasculture
Creating A Culture of Observability at Stripe
healthz: Stop reverse engineering applications and start monitoring from the inside
https://github.com/kelseyhightower/monitorama
The Art of Performance Monitoring
SREConでの発表 https://www.usenix.org/conference/srecon16/program/presentation/smith
Tackling Alert Fatigue
https://speakerdeck.com/caitiem20/tackling-alert-fatigue
https://github.com/CaitieM20/Monitorama2016/blob/master/README.md
Humanscale Systems
Going for Brokerage: People Analytics at Redfin
http://www.slideshare.net/SarahLakeHagan/monitorama-2016
https://github.com/thesarahhagan/monitorama
Everything @obfuscurity taught me about Monitoring
http://www.slideshare.net/petecheslock/everything-obfuscurity-taught-me-about-monitoring
Day2
Scaling Pinterest's Monitoring
http://www.slideshare.net/BrianOverstreet1/scaling-pinterests-monitoring
What Your Javascript Does When You're Not Around
CHICKEN and WAFFLES: Identifying and Handling Malice
Fake it Til You Make It
5 Lines I Couldn't Draw
http://www.slideshare.net/librato/five-lines-i-could-not-draw
Everything is Broken
Metrics are for Chumps - Understanding and overcoming the roadblocks to implementing instrumentation
Day3
Intuition Engineering at Netflix
Prometheus
http://www.slideshare.net/brianbrazil/prometheus-monitorama-2016
Grafana Master Class
How to Teach an Old Monitoring System New Tricks
https://speakerdeck.com/kdaniels/teaching-an-old-monitoring-system-new-tricks
All of Your Network Monitoring is (probably) Wrong
http://www.slideshare.net/ice799/all-of-your-network-monitoring-is-probably-wrong
http://blog.packagecloud.io/eng/2016/06/29/monitorama-2016-all-of-your-network-monitoring-is-probably-wrong/
Building Twitter’s Next-Gen Alerting System
https://docs.google.com/presentation/d/1K4e7uB0wBzrlq5EctCvWEyok0gTOz-1Sh9Ya-o6NeRw/edit#slide=id.g150c37c97c_0_188
Monitoring and Health at Airbnb
Statistics for Engineers
http://www.slideshare.net/HeinrichHartmann/statistics-for-engineers-63589022
Monarch, Google’s Planet-Scale Monitoring Infrastructure
参加された方のメモ
https://github.com/zapman449/monitorama_2016_notes
第5回ペパボテックカンファレンスに行ってきました
今回は「〜インフラエンジニア大特集〜」という副題が付いているとおりインフラ系のイベントなのですがWeb系な雰囲気満載だった第5回ペパボテックカンファレンスに行ってきました。
pepabo.connpass.com
本篇1 トーク&LT
各発表資料はアップされているので、発表部分は資料リンクとQ&A部分の書き起こしおよびひとことコメントだけで。
発表のフォーマット感があって流れが掴みやすいのがとても印象的でした。
発表されたみなさんが大まかに以下に沿っていました。
- アジェンダ - 背景経緯 - 問題設定/設計実装 - 結果/効果 - 残課題 - まとめ - 今後 といった構成
- イメージカラーベースの共通スライドマスター
- ごせいちょうありがとうございました -> 拍手 がしやすい区切り方
- 資料公開はSpeakerDeck
発表1 100行あったmod_rewirteを ngx_mrubyで書き換えた話 by buty4649さん
speakerdeck.com
Q&A
Q: apache/mod_rewriteの頃のテストは?
A: テスト環境に設定を入れて人手で確認
Q: Luaでも同じ事ができそうだがmrubyを選んだ理由は?またmod_rewriteよりレビューコストが上がっていないか?
A: Luaでもできるが、matsumotoryさん始め社内の知財的にruby,mrubyが強いので選んだ。元々得意な人が多いのでレビューコストもそれほどではない
Q: パフォーマンス劣化は無かったか
A: ngx_mrubyのwikiの情報ではパフォーマンスはそれほど落ちない。実際abコマンドでやってみてもそれほど劣化は見られなかった
発表2 ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That by tnmtさん
Q&A
Q: バックアップ構成は?
A: 現状けっこう課題
OpenStack上の別インスタンスやOpenStack外の基盤に採っている
Q: OpenStackのバージョンアップ後の切り戻りは?
A: 新バージョンは別途構築して移行しているので実質切り戻しはない
Q: Neutro使うとLinuxでパフォーマンス落ちないか?
A: 現状構成は組めたけどパフォーマンスは細かく見られていない
LT 高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化 by tshpaperさん
下matsumoto-rさんの内容を超高速でご紹介された勢いのある発表でした。
5年ちょっと前くらいに当時のParalellsさんの製品で物理一台に7000ドメインくらい積めるのがありましたが今のハードスペックだと万単位でやってるんですね。
ちなみに今日の発表の「高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化」のより詳細な内容として参照されていた資料はこちらになります #pbtech https://t.co/t3HIuSBVto
— 松本亮介 (@matsumotory) May 14, 2016
LT インフラエンジニアもCIがしたい by alotofweさん
drone.ioのCIをnested dockerで実施するお話。CIの行き倒れゴミとか経験してるとdrone.ioの良さ嬉しいですよね。CIツールはまだまだ増えていますがインフラで使うときはテスト環境の生成と、単体ではないテストを流せるか/どう流すかがネックというか鍵になる印象です。GitHub Ent.がすでに運用の真ん中に根付いているという前提条件もうらやましくも重要なポイント。
speakerdeck.com
発表3 時代が求めたSTNSと僕 〜夏の日の1986〜 by pyama86さん
AD以外のLDAPは挫折しましたすみません。deploy用の共通アカウント使うならChatからdeployすればいいかなとか(軟弱)。基本認証に対応していたり、api end pointを並べて書けば冗長できたり、使う側に便利なポイントも抑えてあったのが好印象でした。
SSH鍵管理はクッ社さんもいろいろ便利ツール作っていたり、管理の面では新たな課題ですね。
speakerdeck.com
Q&A
Q: 冗長可能な部分は
A: componentのdeployで考慮する必要有り。capistranoとか
LTベンチマークテストやろうぜ by pbmasakiさん
最後の大オチがwwEC2とか同じリソースサイズでもハードの世代によってパフォーマンスに差があるけど見えない部分だから..というIaaSガチャ的な話はありますよね。公開されているベンチマークはレギュレーションの読み解きが大事、というのはおっしゃる通りで刺さりました。個人的な昔話ですが、qmailからpostfixへ移行したら遅くなった、と言われていろいろいじって最終的に/var/spoolをext2にしたという闇経験があります。
speakerdeck.com
LT構成管理ツールを用いたインフラ開発フローの改善 by k_hanazukiさん
・本番環境とテスト環境の差分
・マニフェストと実サーバー設定の差分
の検知と撲滅のお話。個人的にはテスト駆動インフラとかエンタープライズアジャイルとかの背景の一つが「本番と同じ環境でテストせよ」だと感じて取り組みを始めたので、ここを一番見張っています。先日のImageMagickのpolicy.xmlファイルとか変更する機会はそうそう無いので、Serverspecテストに即時に組み込まないと忘れ去られていきますからね(アップデートによって不要になった要素もありますが)。究極的にはサーバーに直接sshログインするのか、という話になるかと思います。ポータル&Chat(Slack)という通知共有は鉄板ですが良いですね。
speakerdeck.com
発表2のtnmtさんにはHosting Casual #1でもお世話になったのですが、Serverspec周りの2014年のこの発表資料だけでもリスペクトできます。今日の話題範囲にも関連するので貼っておきます。
speakerdeck.com
それぞれの発表内容は多岐に渡ったのですが、いずれも設定された具体的な課題に対する改善解決が示されていて聞いている私にも「おお、自分もやってみようかな」という思い持たせるような、巻き込む魅力のある発表で非常に有益でした。
トークセッション「ペパボのインフラを読み解く」
sugyさん(東京/EC事業) 以下S
tshpaperさん(福岡/ホスティング事業) 以下T
司会kumanoさん 以下K
☆
K「インフラは幅広くラックやスペースを含めたモノからヒトまで含める範囲で。
当初ペパボではインフラはGMOグループからホスティングで借りていた。
それを自前ハウジング、さらにプライベートクラウドNyahへ移行しているが
ハウジングに移行して自前サーバーが増える時の苦労は?」
S「キッティングやラッキングなどそれまではお願いしていたことを自分たちでやるのは大変だった」
K「福岡はしばらくホスティングでしたがあるプロジェクトで一気に移行した時の苦労は?」
T「ホスティングは自分たちでやってるものでもあるので、できるだけ現地に行かなくて済むようにはしていた」
☆
K「ハウジング当時、自力人力でセットアップしていた頃は一台どのくらいかかっていたか?」
T「ホスティングは一台半日くらい」
S「簡単なもので1日、複雑なものは2-3日+他業務とかで期間的には1週間かかることも」
☆
K「そうやっていると"サーバーを作るのがうまい人"になってしまいがち。
これではイカン、と2007年頃(mizzyさんが)Puppetを使おうと提案してきた。
で、今は一台どのくらいかかるか?」
T「1時間もあればできあがる。並列も可能で多いときは十数台並列とか」
S「10分弱から2,30分程度。時間が短いことよりも検証のテストが楽になることや繰り返しが楽になったメリットを大きく感じる」
☆
K「Puppetもちょっとバージョンアップすると動かなかったり問題もあったがここまで来るのに苦労した点は?」
T「mizzyさんが創り出したものを福岡側で引き継いで吸収していた。その後Ver.3系に移るときに難しさはあったが、都度調べて議論して、を経てきたのでメンバーの共有&成長でカバーできている」
S「根付くのが大変だった印象。(自分の意識が低かったかもだが)Puppetは遅いイメージがあったのでShellでいいじゃん感は有った。その後、仮想環境および仮想環境を扱うツールが揃ってきた事でメリットを感じやすくなり意識が高まってきた」
K「秘伝のタレ化していたものがコード化されたのはメリットだと思う」
(ここで会場挙手アンケート。
構成管理ツールを使ってる人: ほぼ全員
Puppet 数名、Chef 多い Ansible Chefと同じくらい多い
itamaeとholoなワタシ)
☆
K「コード化されたことでメリットはあるとして、今何台くらい管理してるか?」
T「VM除いて1000台くらい。VM入れると1100から1200くらい。今集約も行っている」
S「オンプレ150台、クラウド600台くらい」
☆
K「Nyahプライベートクラウドを使うことで構成管理は変わったか?」
S「変わったと思う。ドライバインストールなどが無いので統一しやすく、シンプルになった気がする」
☆
K「そこに携わるインフラエンジニアはどう変わってきたか。開発者がインフラの領域に踏み込んで来られる環境になった。今後インフラエンジニアはどう振る舞っていくのか?」
S「正直要らないなと思う事はある」
K「半分は要らないかなと思ったけど今日の発表のようにインフラエンジニアも逆に開発寄りになってきているのか?」
S「開発寄りに行く人と、より専門的に行く人とありそう」
T「高集約にこだわっているので、必要となるkernelの最適化などより低いところへ行く人とmrubyのようにコードを書いて行く人との道がありそう」
☆
K「実際開発の人たちはインフラに入ってきているか?」
T「Puppetの設定にcommitしたりはしている。」
S「あるRoleに対してはインフラエンジニアはコードのレビューのみになっている」
K「今まで煩雑な依頼があったのが、だいぶ良い環境になってきている。
数年前からDevOpsに取り組んでいるが、アプリケーション寄りの活動も、物理やネットワークにも取り組んで行きます」
以上。以下Q&A
Q: 構成管理ツール、の難しさを感じる。社内への普及や教育はどうやっているか?
A: (T)一番最初はmizzyさんから直接教えてもらって、落とし込みは自分たちで議論しながら行った
(K)当時は良い教材が無かった。あと普及面では世の中にはまだまだ手順書があるが、これを置き換えたときに何が得なのか、逆に手順書でないとできないことは何か、とみんなで考えてはどうか
(S)当時「スクリプトではダメだぞお前」という空気があった
(K)同調圧力ではなくて、問題意識を共有してる上でのこと
Q: インフラエンジニアとアプリケーションエンジニアの責任範囲の分け方は?
A: (K)アプリケーションエンジニアのプルリクをインフラエンジニアがレビューするのでその時点で責任範囲というかコードの通り。振り返りは大事だが、責任範囲を問うことはしていない
感想や小話
全体
先のqpstudyは比較的泥臭さも感じるインフラエンジニア界隈でしたが、今日はさすがペパボさんというか技術で様々な施策を打っていて、自社サービスの環境をちゃんと把握した上での対応が行われているという感じでした。
ruby/mrubyという軸が強くあるので、環境やツール選定にも大きな理由があってすんなり行っている印象でした。自社プラットフォーム開発をされている会社さんはこれがありますね。運用系の集まりだと強い言語は無かったり個々人で違ったりするので「RubyのDSLで書けるっ」はそれほどメリットでなかったりも。個人的には「フレームワークとしてメリットを得られるものを選べば良いんじゃないでしょうか」と言うシーンが最近多かったので、明確な軸があるのはうらやましくも感じました。
構成管理
cfengine is cool, puppet is sexyというフレーズを聞いたのは10年近く前の気がしますが、古参ツールのpuppetを会得して使いこなしている感にあふれていて、ツールがちゃんと手段に収まっているのも印象的でした。構成管理ツールって最初に使った時に気持ちの良い感動があるはずなので、そのメリットが活かされたまま定着できているのが良いなあと。世には「Chefツライ」とか「YAMLプログラミング(Ansible)ツライ」とか「本当にholoで良いの?」いった話も多いですからね..ベアメタルレベルの管理のお話が聞けなかったので、そこの施策も聞いてみたいです。OpenStackで言うIronicとかUbuntuならMAASとか
tnmtさんに「ストレージ選定ネタの続きも期待してます」「StackStorm便利ですよ。どうっすか」と2つお話できたので、もしかするとOpenStack MistralのワークフローベースでStackStormを操るお姿が見られるかもしれません。StackStormは、都合がつけばHosting Casual #3でディスカッションのまな板に乗せてみたかったのですが。
ヒト
一方で4月のqpstudyや3月のIaas Casualと同じくインフラエンジニアの今後のキャリア形成やチームメイキング、採用といったヒトのお話では共通した課題や悩みが聞かれた気がします。クラウドやらコンテナやらと基盤が進化してツールも充実したことで、変化は感じていてそれに伴った危機感も感じている、といったところでしょうか。今回のpbtechと併せた3つのイベントで割と共通して聞かれたメッセージとしては「すべてできる人はいない」「コミュニケーション大事。コミュニケーションもChatOpsとか技術で改善できる部分もある」「そこはきっと楽しいところ(デマルコ風)」がありました。あと懇親会でkumanoさんからファシリテーターの活用というお話もあり、これまた実際の活用話はあまりお聞きする機会が無かったので、ファシリテーター人材という課題も有りそうですが納得感がありました。
☆
実は前日まで抽選に落ちたと勘違いしていて午前中に髪を切りに予約入れちゃったりしていたのですが、無事参加できて様々な刺激を得られて良かったです。今後もpbtechでインフラ/運用系のネタをやって欲しいし自分のチームメンバーにも参加して欲しいです。
また、懇親会のカレーが小分けで配布されたのは食べやすかったので、Zoho各位にはナンのこだわりもあると思いますが参考にしてもらえれば。
トークセッション中、後ろでは着々とカレーの準備をしています!#pbtech pic.twitter.com/JWrNUcWdHi
— ペパボ採用担当 (@pb_recruit) May 14, 2016
ntpの脆弱性201604公開分-雑まとめ
ひとまずRedHat情報で整理したものを。
"will not fix"でconf内容を見直せ、というものが結構あります。
CVE-2015-7973:Authentication Bypass by Capture-replay
CVSS v3 Base
アップデートパッケージ(RHEL)
なし
補足
Do not use NTP's broadcast mode by not configuring the "broadcast" directive in the ntp.conf file.
CVE-2015-7974:Improper Input Validation
CVSS
6.3
アップデート
なし
CVE-2015-7975:Improper Input Validation
補足
RHEL5-7のパッケージは該当せず
CVE-2015-7976:Improper Input Validation
アップデートパッケージ(RHEL)
なし
補足
Use the 'restrict default nomodify' directive in ntp.conf to disable modification of ntp.conf via the ntpq command.
CVE-2015-7977:NULL Pointer Dereference
アップデート
なし
補足
Keep the number of restriction list entries in ntp.conf lower than 500.
CVE-2015-7978:Uncontrolled Resource Consumption ('Resource Exhaustion')
CVE-2015-7979:Incorrect Synchronization
アップデートパッケージ(RHEL)
なし
補足
Do not use NTP's broadcast mode by not configuring the "broadcast" directive in the ntp.conf file.
CVE-2015-8139:Information Exposure
アップデートパッケージ(RHEL)
なし
補足
1-3のいずれかで緩和可能
(1)adding the noquery option to all restrict entries in ntp.conf,
(2)configuring ntpd to get time from multiple sources,
(3)using a restriction list in your ntp.conf to limit who is allowed to issue ntpq and ntpdc queries.
Note that ntpdc queries are disabled by default.
CVE-2015-8140:Authentication Bypass by Capture-replay
アップデートパッケージ(RHEL)
なし
補足
(1)disabling ntpq in ntp.conf,
(2)configuring ntpd to get time from multiple sources,
(3)using a restriction list in your ntp.conf to limit who is allowed to issue ntpq queries.
CVE-2015-8158:Uncontrolled Resource Consumption ('Resource Exhaustion')
アップデートパッケージ(RHEL)
なし
CVE-2016-1547:Incorrect Synchronization
未
CVE-2016-1548:Authentication Bypass by Spoofing
未
CVE-2016-1549:Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
未
CVE-2016-1550:Improper Input Validation
未
CVE-2016-1551:Authentication Bypass by Spoofing
未
CVE-2016-2516,CVE-2016-2517:Improper Input Validation
未
CVE-2016-2518:Out-of-bounds Read
未
CVE-2016-2519:Improper Restriction of Operations within the Bounds of a Memory Buffer
未
CVE-2015-7704:Improper Input Validation
アップデートパッケージ(RHEL)
CVE-2015-7705:Improper Input Validation
未
補足
Do not add the "limited" configuration option to any restrict lines in the ntp.conf file.