gree-techtalk-0123-TakumaYoshida.pdf

Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. GitHub:e運⽤用錬⾦金金術!?
GREE Tech Talk: GitHub:E Casual Talk Jan 23, 2013 Name : Takuma Yoshida Network&SecurityGr, IT PlaBorm Dept DeNA Co., Ltd.

Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 2
⾃自⼰己紹介 w Takuma 　Yoshida r %F/" *OGSB&OHJOFFS r 新卒⼊入社 w 1BZHFOU w +*3"$POqVFODF w (JU)VC& 　〜～現在　　導⼊入・運⽤用（インフラ、アプリ）を担当

GitHubとは? 　便便利利な使い⽅方は？ (JU)VCの使い⽅方の話は触れませんN @@ N ごめんなさい

　(JU)VC&を導⼊入するまでは%F/"でのソースコード管理理はこのような感じでした

GitHub:E 導⼊入前

　(JU)VC&を導⼊入してみると・・・

GitHub:E 導⼊入後

(JU)VC&を中⼼心とした • アプリ開発リリース障害対応 • プロジェクト管理理 • エンジニア間コミュニケーション　　が、いつの間にか出来てしまった・・・

これは凄く快適な開発体系のつでは？と思ってます・・・

しかし！！裏裏を返すと、(JU)VC&に障害がおきると・・・

致命的！！

だからこそ・・・ • ⼤大規模で(JU)VC&を運⽤用するコツは？ • バックアップどうするの？ • セキュリティは？・・・ちゃんと運⽤用するなら⼤大事ですよね？

そこで本題・・・ (JU)VC& 　運⽤用錬⾦金金術！？

GitHub:E の中⾝身 MySQL Redis Memcached Nginx Unicorn git Thin Service Hook Solr Search Chef Server SeLng, upgrader /data/repositories Sorce data Ubuntu OVAϑΝΠϧ ͱͯ͠ VMwareϗε τʹσϓϩ Π

GitHub:E in DeNA インスタンス構成 • "DUJWFr$PMETUBOECZ構成（ %3） • 7.XBSF&49J()& 　

GitHub:EをDeNAで運⽤用して思ったこと 4FSWFSの負荷はそれほど気にならない • メモリは(あれば0, • %JTLJPもネックにはならない L4"4 • *"4FSWFS台で運⽤用可能 /8的な負荷もそれほど気にならない • 激しい利利⽤用帯でも/8的に帯域圧迫はない • (#単位のCJOBSZ動画などは他ツール推奨

課題冗⻑⾧長構成が取りにくい • 07"パッケージとして提供されるので、 ()&の中⾝身をカスタマイズできない • (JU)VC社は7.XBSF)"を推奨しているが、⾼高い 5P5 ＆()&⾃自体の冗⻑⾧長にはならないのであまり意味がない • 3PPU権限と気合があればできるかも？　（が、(JU)VC社に怒怒られるので⾃自⼰己責任で・・・）

GitHub:Eを安定運⽤用する第⼀一歩 "ENJOユーザでTTIログイン（すべてはここから） • %FGBVMUでは仮想マシンにTTIログイン不不可 • (JU)VC&では"ENJO権限で様々なオペレーションコマンドが提供されている • Version 11.10.260まではこれができず、魔術師的運⽤用で寝れない⽇日々・・・・まさしく⿊黒歴史；Т；｀

設定は.BOBHFNFOU$POTPMFから簡単にできる IUUQTTVQQPSUFOUFSQSJTFHJUIVCDPNFOUSJFTTTI BDDFTT

でも欲を出すと・・・ 3▪▲★権限欲しい・・・

SSHが使えるようになったら Comand-‐line UOliOes を使い倒す hPps://support.enterprise.github.com/entries/21254402-‐command-‐line-‐uOliOes

Comand-‐line UOliOesが使えるようになったら領領域をまず拡張しましょう • %FGBVMU(# • SFTRVFMPH（クエリログ）　　アクセス増で爆発 領領域すぐ枯渇　 死亡 • ghe-‐grow-‐root コマンドでオンライン拡張 • VMware ClientでGHE仮想マシンに割り当てたDisk容量量分⽬目⼀一杯拡張してくれる

他にもこれは知ってほしいログを⾒見見る • ghe-‐logs-‐tail • オプションでアプリ、認証、DB、Chef、 systemログなどを個別に参照できる • トラブル時に必須

ではバックアップはどうするの？

バックアップ⽅方法１ 7.XBSF4OBQTIPU • おすすめしない • ⾃自動化⼤大変 • 負荷的に厳しい：snapshot時,load15 ぐらい • ディスク枯渇の原因になりうる⼀一度度Snapshotで静⽌止点を取るとVmwareホストマシン上に ***.delta.vmdkファイル（静⽌止点からの差分データ）が作成され、次第に肥⼤大し、放おっておくと死滅する

バックアップ⽅方法２ Comand-‐line UOliOesを使う • おすすめ(以下6種のコマンドでOK) • ghe-‐export-‐mysql & ghe-‐import-‐mysql • ghe-‐export-‐redis & ghe-‐import-‐redis • ghe-‐export-‐repositories & ghe-‐import-‐repositories (使い⽅方はDocumentを参照して下さい)

ただし、、、これらのコマンドにも罠はあるコマンドの中⾝身を⾒見見てみると・・・

ghe-‐export-‐mysql mysqldump \ -‐u root \ -‐-‐hex-‐blob \ github_enterprise

このままだとバッチ回すたびに5BCMFMPDL 8FC閲覧時にVOJDPSOがUJNFPVUするではどうしたらいいのか・・・

new-‐ghe-‐export-‐mysql mysqldump \ -‐u root \ -‐-‐hex-‐blob \ -‐-‐single-‐transac]on \ github_enterprise

ghe-‐export-‐repositories tar \ -‐cf -‐ \ -‐C /data \ repositories w レポジトリディレクトリをUBSで固めてるだけ w TDQとかで転送すると時間掛かり過ぎる 5P5 w なので、これは使ってません（STZODしてます。S˒˙˕権限必要です。汗）

ではセキュリティはどうするの？

いつ誰がpull/push/cloneしたか w HIFMPHTUBJMrB w いつ誰がどこから、どのリポジトリにQVMM QVTIDMPOFしているか監視できる w HIFTVQQPSUCVOEMF w ログ周り⼀一式を圧縮保存できる w (JU)VC&のログは⽇日間でローテーションされるので、外部4FSWFSからバッチで定期取得してます

ユーザー退職時の処理 • ghe-‐user-‐suspend • 特定ユーザを利利⽤用停⽌止にすることが可能 • 社内系のLDAP（Ac]ve Directory）と連携させれば、退職時に⾃自動的にGitHub:Eへの Accessを拒否出来て、セキュリティ的にも Good

まとめ

GitHub:Eを安定運用するには w (JU)VC&の仕組みを⾒見見る w $PNNBOEMJOF6UJMJUJFTを使い倒す　（中⾝身も把握する） w 0DUPDBUを愛でる

&/%

gree-techtalk-0123-TakumaYoshida.pdf

gree-techtalk-0123-TakumaYoshida.pdf

Featured

Transcript