メモを取ろうとしたら、DPT-RP1 のスタイラスが電池切れで書けず、iPhoneで取ったので断片的になっています。
ssmjp 2018/07 @株式会社インターネットイニシアティブ
プログラム
1. 石田さん DNS Summer Day 2018報告ー海賊版ブロッキング問題を中心にー2. @koyhogeさん 「CloudFormation と FaaS のはざま - Kubernetes の設計思想を探る - 」
3. @tcshさん 『続 運用自動化、不都合な真実 〜 なぜコスト削減目的で運用自動化してはいけないのか』
4. @_keihinoさん 『マインドフルネスのススメ』 10分
5. @Alice_Youさん 『OPNsenseをUTMに入れて使う』 10分
6. @goto_ipv6さん 『「DNS浸透いうな」と言うけれど…』
石田さん DNS Summer Day 2018報告ー海賊版ブロッキング問題を中心にー
DNS Summer Dayについて
2012年より毎年開催
今年は6/27日 参加者 約140名
プログラムと資料は dnsops.jp にあります http://dnsops.jp/event20180627.html
今年のトピックから
- BIND ESV 9.9 から 9.11 へ
- DNSブロッキング
DNSブロッキングについては、JANOG42 のブロッキングセッションの資料も参照してください。
https://www.janog.gr.jp/meeting/janog42/program
DNS ブロッキングの是非について
ノート:
私も、以前はキャッシュサーバでBINDを利用していましたが、セキュリティ問題でBIND祭りがたびたびあり、対応が大変だったので、Unboundを利用するようになりました。
権威サーバを立てるためにまだBINDを利用しているケースはあると思いますが、最新版にアップデートしておきましょう。
会場でも、是非についてアンケートが取られました。
DNS ブロッキングについては、ニコ動のアンケートでは賛成が50%程度あったそうですが、アンケート内容や対象などの詳細はわからないそうです。
DNS ブロッキングに賛成か反対かというのは、現時点では、何を、どのようにの部分が、技術的にも法整備や運用面でも議論が十分でないため、単純にYES/NOで答えられるものではないと思いました。
@koyhogeさん 「CloudFormation と FaaS のはざま - Kubernetes の設計思想を探る - 」
背景:
CloudFormationのような、宣言型デプロイツールが増えてきている。
YAMLの複雑さ
コンテナとオーケストレーションツール
でかいYAMLはいや
そもそも、サービスに必要なものを全て記述しているので、サービスが増えればその分長くなる
サーバの管理を減らせば、管理対象が減って、コントロールしやすくなる
FaaS → 新しいパラダイム
長時間実行、大容量メモリなどの処理は、苦手
既存システムとの互換性
コンテナ + オーケストレーションツールは実行イメージの単位でデプロイ
Docker + Kubernetes
しばらく前にまで乱立していましたが、いまはDockerがKubernetesをサポートするようになりこのかたちに落ち着いています。
Kubernetesの名前の由来
Borg スタートレックTNGのBorgです
Project Seven
Voysger の Seven of Nine からきています
コンテナを組み合わせてサービスを作るときのコントロールを司る役割
Kubernetesをつかったシステムでの構築原則
イミュータブル
宣言的設定
自己回復
多数のサブシステムから成り立つ
- クラスタ マシン群 dockerが動けばOK
- Pod ワークロードが動作する論理ノード
- サービス 名前解決 エンドポイント作成
- レプリカセット 同一Podを複数立ち上げ
- DaemonSet 全てのPodに付随して動作するサイドカー群
- デプロイメント 配置
- ConfigMap 設定情報管理のしくみ
こうなってくると、サービスのための新しい考え方も出てくる
- サービスメッシュ データを管理するしくみ
サービスの OSS基盤としての標準と成りつつある
会場からの質問
Q: サービス互換性はどうなのでしょう？
A: GCPでは古いバージョンも今でも動いているため、それほど悪くないと思います。
メモ:
終了後、Kubernetesを自分たちで動かして使っている人ってどれくらいいるのでしょうね、マネージドサービスを使っているケースがほとんどじゃないですか、サービス基盤としてのKubernetesそのものと、Kubernetes上で動かすサービスの両方の面倒を見ないとダメなので、そこはやりたくないですよね、なんてことを話しました。
Kubernetesを使ってサービスを作る立場と、サービス基盤としてのKubernetesを動かす立場の両方があって、インフラエンジニアの立場では、後者の辛身が混じってくるので、辛い話が漏れ聞こえてくるのだろうと思いました。
@tcshさん 『続 運用自動化、不都合な真実 〜 なぜコスト削減目的で運用自動化してはいけないのか』
工数削減ではなく、サービス提供価値の増大(生産性向上)を目指しましょう、というお話。
OPEX (運用維持費)の削減は、 コスト＝キャッシュアウトの削減→コストカット ＝ 人件費カット となりやすい
人件費カットの結果
- 業務のやり方を変えずにやると、できることが減り続ける
- 見かけ上コストは下がっているが、担当者の努力で維持されているだけ
- ブラックボックス化
コスト削減は数値のマジック
削減を繰り返すと、最後には売るものがなくなる
廃業するつもりならありでしょう
やるなら費用対効果の改善を目指しましょう
品質、デリバリー(時間)をあげるように
改善のための一時的なコスト増は受け入れましょう
@_keihinoさん 『マインドフルネスのススメ』 10分
ストレスにマインドフルネス
調身
調息
調心
スピリチュアルな方には行かないようにしている
ノート:
マインドフルネスはよく聞くようになりましたが、ストレス緩和のためには、効果があるのですね。
@Alice_Youさん 『OPNsenseをUTMに入れて使う』 10分
NXG150シャンクなら1000-3000円
中はNEXcom DNA1110 (Atom 64bit)
SEIL x86, VyOS など 動く
BIOS はシリアル画面に出る
USBキーボードを認識する
自宅の、SophosUTM Home Editionを動かしている機器を、そろそろリプレイスを考えないといけないので、これはちょっといいかなと思いましたが、メモリが2GBということなので、そこが厳しいかな。
@goto_ipv6さん 『「DNS浸透いうな」と言うけれど…』
どこに浸透するの？アプリケーション？
アプリケーションにキャッシュするの？
独自に名前解決するの？
OracleJVMなどはそうだけど。
ウエブブラウザ？
ブラウザのキャッシュ？
OS？
リゾルバライブラリにはキャッシュはない
nscd
ローカルDNSキャッシュ
フルリゾルバ？
キャッシュに浸透？
要求されないと、問い合わせが起こらない
ネガティヴキャッシュがあるので、レコードがなかったことは覚えているかもしれない
権威サーバ？
そのドメインに関する情報のみを持っている
更新作業により即時反映される
ルートサーバ？
NSレコードのみ保持
まとめ
「浸透」する先は存在しません
ノート:
むかし、i-mode などで、携帯キャリアで IP 網から、携帯電話網に中継するプロキシサーバがあって、DNSレコードのTTLを無視して独自にキャッシュのタイマーを持っていて、なかなか更新されなくていつまでも旧サーバを参照しにくるというのがありました。
DNSのしくみを知っていれば、レコードを書いたら自動で伝播するようなことなはいので、「浸透」なんてことはいわないけれど、仕組みがよくわからない人たちからすると、
まあ「浸透」と言ういう人たちの気持ちはわからなくもないです。
0 件のコメント:
コメントを投稿