:::: MENU ::::

Atlassian User Group #16 メモ

Pocket

もう16回目なのか。AUGにまた参加してきました。
最近はcompassで参加管理をしているから、compassのAUGグループにジョインすると
AUGの開催通知が来るらしいよ。

以下、適当なメモ。

gumi 本間さん GHEからの移行

1. GHR時代

2012年
Devには好かれるがOpsには好かれない
Opsまで範囲を広げると金がやばい

これはどこでもそうなのだろうね。
Githubという一種のブランド物になってしまっている。

gumiのサーバはすべてAWSで運用
しかしAWSに当時はおけなかったので、
自前サーバに置くにはパフォーマンスが安定しない
ROOT取れないから監視も大変

GHEの困る点はイメージでOSごと渡されるので、
中身がいじれないのとROOTが取れないこと。
インストールやアップグレードは確かに楽だが、
代わりにチューニングの余地がないのが困るね。

2. 解決したかった課題

ライセンス料

海外や協力会社や非エンジニアのアカウントが増えてライセンスが!

非エンジニアは共通アカウント運用をしていたときもあったらしい。
まぁ仕方ないといえば仕方ないが、セキュリティ観念と利用ポリシー的には継続できないよね。

GHEはボリュームライセンスじゃないから、一人いくらでカウントされる。
ライセンスの増減はしやすいけど、別に利用頻度が高くない人にも
ライセンスを発行しないといけないのが地味に効く。

権限管理

CrowdとGoogle Appsと連携
海外のどこ拠点もすべてGoogle Appsを導入している。
Stashは細かくリポジトリの権限を設定できる

いいなーGoogleApps。グループの同期もできるんよね。

AWSの機能

Stashのサーバ構成
 EC2+EBS(IO高めなのでEBS
 RDB

AWSだと標準でできるものでも、自前で立てると自分で用意しないといけないのは、
AWSに慣れてしまうとかなり面倒に感じてしまうもの。

特にバックアップが簡単になるのが大きい!
初めて知ったがサーバーの巻き戻しもあるのか!数分前にとか!

3. Stash導入時と運用TIPS

数十GBのリポジトリのせいでLoadAvgが高くなる。
これはIOのせい。
Gitのバージョン特有のバグだった(1.8.x系だとStashで重くなる)

結局Gitバージョンのせいだったけど、
そこに行き着くまでに商用サポートが有用だったという話。
OSSだと誰かが見つけてくれるのを待つか、自分で見つけないといけないからね。

パブリックアクセスの禁止
# vi stash-config.properties
feature.public.access=false

画面上から無理やり消していたが、設定方法あったのか。。

2年でやったこと
shellshock, heatbleed対応
git,jdk,stash3.xへバージョンアップとか

バージョンアップ待ちとかになるないように商用サポートケチらないほうがいいよという話。

4. 要望

snippets
有償でもあるけど履歴管理できない

いわゆるgistにあたるもの。
あの有償アドオン履歴管理できないのかよ……

オンライン編集
有償でもあるけど標準でほしいね

Bitbucket Ondemandにある機能は、Stashにも標準搭載して欲しい。。

フックの充実

これ重要!
Stashってデフォルトでフックが用意されてないよね。
こちらで全部提供しなきゃ行けないのが結構つらい。

まとめ

Githubになれた人でも使えるよ
オープンソース=無料じゃないよ

OSS運用する上で中身を知らないといけないしね。
それをしっかりやろうとしたらかなり大変だから商用のほうが結局楽という。
セキュリティとか甘々でいいならOSSで作りっぱなしでいいけどね。


Glenn @Atlassian

※自分翻訳+翻訳の方が言っていたことのメモ

シドニーから来たよ
プラットフォームエンジニアリングとして働いている
社内システムのみを扱っている
すべての製品を見ているけど、専門家ではなく運用管理している

Atlassian社の方で社内システムエンジニア。
こちらから見たら中の人、さらに中の人。

社員が増えたのでSystemAdminを3つに分けた

・プラットフォームエンジニア
  → 社内システムの管理
    要望があれば作り、改善を行う
・サービスオペレーション
  → リクエストに対して作業を行う
・サービスリライアビリティ
  → ひとつひとつのアプリに付いている特定ツールの専門部隊

これは参考になる分け方!
明示してないが結構こういう形に自然となっているかも。

サービスリライビリティって聞かない言葉だけど、
「Service Reliability」サービスの信頼性を守る部隊って解釈でいいのかな。

SysAdmin Q&A

何台管理してるの

450VM
400EC2+RDS
All ubuntsu

社員のほしいものに応じてインスタンスを立てて、なんでも作るスタンス。
でもNoとも言うよときどき。

CIはどうしてるの?provisioningはどうしてる?

なるべく自動化はしているけど。まだ手動もある。
puppet使っていて、リポジトリはBitbucket

設定ファイルの管理方法

すべてpuppetで管理していた、
でも遅くなることがわかったので
オペレーションとアプリの管理を別にした。

アプリはBambooで、OS系とかほかはpuppetで管理。

設定の変更はサービスデスクで受け付けている。
作成されたチケットからBitbucketでブランチ切ってプルリク、その内容をPeerレビューする。

監視ツールはどうしている?

nagios,puppet

nagiosはConfluenceと連携していて、エラー内容と連携した解決ページが連携している
アラートはすべてHipChatにながしてるよ
nggiosからは引っ越す予定

このアラート内容の解決策が書いてあるConfluenceページと、
アラート項目が連携しているのはすごいな!
かなり欲しい連携機能。

インスタンスはどう分けてる?

20%は空いているようにしてるよ
社内システムはAWSではなく、全部データセンター

Atlassainが落ちた時どうしてる?

常にThread dump, Heap dumpを管理することでPuppetで取得している。
アプリが落ちていれば、Heap dumpを見てスタートとか。
Heap dumpのパス設定を入れておけばスペースを確保できる。

一番多い落ちる理由はアドオンかバグ(dogfooding)

ドイツ製のアドオンがよく落ちる原因になっているらしいよ。

VMとAWSはどっちが多い?

VMは筐体が古くなっているのでAWSには行きたい
でもヘビーなのはVMで残す。軽いのはAWSへ移行。
感覚的にはVMよりもAWSのほうがいい印象を受ける。

Pocket


So, what do you think ?