1月 2015 | 雑多なメモ帳

Home » Archives for 1月 2015

Docker Meetup Tokyo #4に参加(視聴)したメモ（後半）

in docker, セミナー - on 19:27

前半はこちら
■Docker Meetup Tokyo #4に参加(視聴)したメモ（前半）

感想

途切れ途切れなことが多く少し抜けがあります。資料がアップされたら復習したいです。監視については話をあまり聞かなかったので、もっと賑わってくれればいいと思ったところです。

Docker Meetup Tokyo#4 概要

■ Docker Meetup Tokyo #4
http://connpass.com/event/10318/

17:25-18:05 LT (5min) x 8
- Development and Deployment with Docker at Dwango
- Google Container Engineについて
- DatadogさんのLT
- 共用スパコンシステム上でデータ解析 with Docker
- TBD
- Docker/ECSでIAMロールを利用する
- GitのコミットごとにQA環境を作成するプロキシを作ってみた
- tutumで雑に包んで雑にデプロイ

LT大会

Development and Deployment with Docker at Dwango

ニコニコのRecommendation API
コードレビュー/UnitTestは参照づらい。
実際のテスト環境を簡単に作りたい
pull req出したらdockerでテスト環境をデプロイしてほしい
Jenkins Pull Request Builder
「pull request/時刻」でコンテナ生成
git pullした時にbuildするrake taskを裏で実行
Deploy Manager WebUI
ログ収集はfluentd + 専用コンテナ
Deploy Manager WebUI(capistranoでStatic)

Google Container Engineについて

GKE (kubernetesの商用版)
- サポート
- microservice間の接続
fluentd + kubernetes
UI新しくなった
sample: wordpress構築

Datadog

Dockerがトラブった時にコンテナの状況が把握できているか？
Docker User Cases
- 依存関係を排除したい
- github workflow
- statelessな部品を使う
コンテナを載せるインスタンスサイズ
- m3.midiumが多い(?)
- ちっちゃなワーカープロセスをがんがん回している
- 1つのdockerホストに5つ平均
- 調査した環境内では最高で12個くらいだった
まだ導入は初期段階、いづれ増えていって平均10くらいになるのでは？
監視を考えてdocker使おう
Dockerメトリクス cgroup or cAdviser
リソース：Memory / CPU / Network / IO
イベント：run & stopped
自作派：cAdvisor / InfluxDB / Grafana
企業：sFlow / DataDog

共用スパコンシステム上でデータ解析 with Docker

データの性質が変わるのに追随
ソフトウェアとワークフローを柔軟に変更したい
既存のリソースを有効化(User管理・占有し続けたものの削除がしたい)
0から作るのは嫌なので今日の聞いた話で作るつもり

DockerAPIをGoから使う

docker remote api
kurbernetesが使っているGoのクライアントライブラリ
デモ
コンテナの起動/停止/リストなど色々いじれるので自作派には嬉しい

Docker/ECSでIAMロールを利用する

Dockerコンテナのクレデンシャル設計（ブログ）
APIのtoken keyをどこにおくか
- Dockerイメージに埋め込む
- 環境変数(docker run -env)
- クラウドサービスならクレデンシャルが外出しできる

課題

dockerコンテナとインスタンスで区別できない
docker単位の制御ができない

対策

MetaServerの自前実装(Qiita)
できた。MetaServer側でログを確認

今後の課題

自前MetaServer自体をコンテナ化
コンテナごとにロールを管理したい

Mookさん GitのコミットごとにQA環境を作成するプロキシを作ってみた（仮

Dockerを使った爆速プレビュープロキシ
サブドメインにコミットハッシュやブランチ名を入れる
Qiitaにvagrantでの使い方がある
レビュー時にURLを貼るbot付き
仕組み
- コミットに対応したコンテナがあるか
- なければリポジトリからソースを取得してdockerfileを元にデプロイ
- ビルド中はクライアントにログを残す
ホスティング版のβを2月に予定している

tutumで雑に包んで雑にデプロイ

tutumuとは？
- docker as a serviceのプロバイダ
- Open Betaで無料
- IasSのノードに対して、投下的にコンテナをデプロイできる
- AWS,GKE,DigitalOcean,さくらVPS,ConoHa,オンプレなノードにも対応
- 簡易的な監視、プライベートレジストリを無料で使える
なんでtutumu?
- ダッシュボードがシンプルで使い易い
- 特定のIaaSに縛られたくない
Dashbord -> Create Service -> image選択

Docker入門 Immutable Infrastructureを実現する

posted with amazlet at 15.02.04

技術評論社 (2014-04-25)
売り上げランキング: 2,162

Amazon.co.jpで詳細を見る

Software Design (ソフトウェアデザイン) 2014年 12月号 [雑誌]

posted with amazlet at 15.02.04

技術評論社 (2014-11-18)

Amazon.co.jpで詳細を見る

Docker Meetup Tokyo #4に参加(視聴)したメモ（前半）

in docker, セミナー - on 18:00

感想

Dockerをサービスで使う際にオーケストレーションとかDockerだけで足りない部分はどうするの？というところについて皆さん検討しているようです。CoreOSなのかKubernetesなのかECSなのか、これからどうなるか気になります。

Docker Meetup Tokyo#4 概要

■ Docker Meetup Tokyo #4
http://connpass.com/event/10318/

13:55-15:10 Talk (25min) x 3
- @deeeetさん CoreOSの基礎/CoreOSに期待すること
- @y_uuk1さん WebアプリケーションにおけるDockerパフォーマンスチューニング
- @shot6さん Amazon EC2 Container Service(ECS)
15:30-17:10 Talk (25min) x 4
@yuguiさん Kubernetesの機能とデモ、開発体制について
@ten_forwardさん cgroupによるリソース隔離入門
@yuryuさん RedHat atomic hostの話
@spesnovaさん Docker at Wantedly

(続く)

後半のLT×8は以下からどうぞ
Docker Meetup Tokyo #4に参加(視聴)したメモ（後半）

CoreOSの基礎/CoreOSに期待すること

PaaSサービスで使用

docker/CoreOS

Dockerが与えてくれないもの

オーケストレーション
サービスデリバリー
スケジューリング
死活監視
ホスト環境/ツールの統一

CoreOSについて

datacenter as a computer

CoreOSで使われている技術

etcd
- 分散キーバリューストアクラスタの基盤
- サービスの設定値の保存
- CLI: set / get、APIもある
fleet
- Dockerコンテナのスケジューリングとデプロイ(最適な)
- コンテナ状態の監視・フェイルオーバー
- 各ホストのsystemdを束ねる存在、クラスタ
- systemdのunitファイルの拡張版(X-Fleet)
- 「MAchine Metadata」でmetadataを元にコンテナをデプロイ
cloud-config
- coreOSを初期化したりカスタマイズするためのファイル
- 起動サービス、ユーザ、アップデート、metadataなどをymlで書く

CoreOSが解決すること

オーケストレーション
- etcdにコンテナの情報を保存してサブスクライブする別のコンテナを準備
サービスデリバリー
- fleet list init
スケジューリング
- fleetでできそう
死活監視
- fleetが最低限みてる
ホスト環境/ツールの統一
- cloud-configをprod/devと同じものを使う
- (参考)Playstationの動画がいい

CoreOSの運用

CoreOSはOpenstackでもEC2でもdigital-oceanでも動くよ
複数プラットフォームまたぐのを推奨
Auto Scale(webサーバ増やしてLBに追加)のデモ
- etcdのディスカバリーサービス
- IP/Portをetcdへ登録
- LBはconfdを使ってetcdの情報+テンプレートを元に設定を動的に生成
TeraHome + CoreOS
Minimal RAMの使用量は114MB
CoreOSはどこまでMinimalにできるか
パッケージマネジャーもない
OS Update
- OSアップデートは書き込み不可なRootFSを丸ごと入れ替える
- ロールバック簡単
- アプリケーションはdockerの入れ替え
- 設定値 etcd

WebアプリケーションにおけるDockerパフォーマンスチューニング

Docker Egine上でアプリケーションを動かして性能劣化しないの？
Docker Demon / クラウドのマネージサービス

1. Dockerのパフォーマンスにおいて重要なのはなに？

Linuxカーネルの名前空間機能
LXC Linux Containersのフロントエンド
Linux Containers Overhead
- 単体のLinuxカーネルで完結するので効率いい
- パケット受信してkernel割り込みからユーザランドまでの2重処理がない
Docker Filesystem

UNION Filesystem

差分管理とかいいよね
Writeは最上層へ書き込み、Read IOは探して層をもぐる
Copy On Write
Linuxカーネル標準のdevice mapperでも

Device Mapper

ブロックデバイスへのIOに暗号化、ストライプ、ミラーなどが可能
特定のファイルシステムに依存しない

Volume

コンテナ間でディレクトリーを共有
Dockerグローバルな領域
Union FS部分を通らないのでオーバーヘッドが少ない
docker run -v /var/lib/mysql mysql
- Docker Network

Portmapper(Goのパッケージ名から拝借)

ホスト側のiptablesでNAT
iptablesがない環境はdocker-proxyがユーザランドで動く

Host Networking

コンテナ用のNetwork Namespaceを使う
iptablesは不要/Portはホスト側のものを使用
docker run -net=host mysql
LXC1.0 or exec-driver=native

2.Docker化したISUCONでベンチマーク

ISUCON(Iikanjini Speed Contest)
ベンチマーカー -> Nginx -> App(+memcached) -> DB
m3.xlarge / Ubuntu 14.04 LTS Kernel 3.18.0 / Docker 1.4.1
初期で38446で予選突破レベル

ベンチマーク環境
- NginxとMySQLをそれぞれDocker化
- Nginxだけ(-net=host/-net=bridge)
- MySQL(devicemapper/overlayfs/volume ON/OFF)

Nginxはbridgeを使った方がパフォーマンス落ちる（NATのため）
Nginxにパケットが集約するのでNAPTするオーバーヘッドが高い
MySQLはvolume切っても以外と早い。ReadI/Oはメモリ、Writeは最上層。
defaultと変わらない

NAPTの高速化

デフォルトのipatablesに「!-d 127.0.0.0/8」があった。つまりdocker-proxy使っている。
ベンチマークのソースをいじったらdefaultに合った

Amazon EC2 Container Service(ECS)

コンテナのマネージメント(今はpreview)
オーケストレーションやクラスタ
pure docker / vpcとかautoscaleとかも
limited previewでUSのみ

ECSの仕組み

Container Instance

EC2(VPC) / Docker / ECS agent
Amazon Linux / 他ECS agentが動けば
ECS Agentとは
- Apacheオープンソース
- go
- Docker Hubにも登録されている

Cluster

リソースプール
リージョンに閉じている

Task

関係するコンテナの集合
Container Instance上で稼働
Jsonで記述
- 今までのAWSライクに使える(Security Group/VPC/MultiAZ)
- パブリック・プライベートレポジトリ使える
- ECS Command Line Tool

Clusterを作成
- ARN(Amazon Resource Name)
EC2をContainer Instance として起動
- CoreOSも使える
- ブートストラップでECSの設定を書き込む
- IAM profileでecsをつけておく

1と2をコマンドで用意しておけばOK

taskの走らせ方
- ECSのスケジューラー
- 手動

Kubernetesの機能とデモ、開発体制について

コンテナ渡すだけで動いてくれるDockerってすばらしい
だけど他の発表者と同様にオーケストレーションなど足りてないとろこはまだある
LB / デプロイ時のポート競合 / リソース / レプリなど自動がやってほしい
kubernetes(ギリシャ語)がやってくれる
- Google主導
- オープンソース*
Service / ReplicationController / Pod
Pod ≠ Container
Podは同じインスタンスで走らせるようにしたいコンテナの集まり
Podの定義はymlかjsonで書く
Client -> API -> etcd <- Controller Manager -> scheduler -> etcd -> Instance
etcdが中央にありそれを各コンポーネントがwatchして自分のtaskに関連するものを拾って制御をするイメージ（図があったので後日資料参照がオススメ）
Minion(インスタンス)でkubrenetdが動いている
Networking
- 基本はiptables
- kube proxyというアンバサダーがいる(etcdも見ている)
- 一つのインスタンス内でポート衝突する可能性があるものも動く

まとめ

開発は結構Active
技術的にはオープンなものを選択(ex:Fluentd/kibana)
Well designed by Google

その他

Namespaces -> multitenat
internal DNS
Master as a Service(まだシングルなので)

cgroupによるリソース隔離入門

Cgroupについて

Namespaceとは？
- OS/カーネルリソースを隔離
Cgroupとは？
- コンピュータが持つ物理リソースを隔離
Cgroupとは
- プロセスをグループ化
- Cgroup内のプロセスに対してまとめてリソース隔離
- tasksというファイルにpidを記入 / 稼働中に動的に変更

dockerでの使い方

dockerでの使い方
- docker runのオプションかjsonファイル
cgroupから直接でも
- dockerコンテナのcgroupの場所を見つけて直接書く
systemd配下で動いている場合
- ユニットファイルにcgroupの設定を書いて起動
- パラメータがまだまだ少ない

Docker on RedHat & Project Atomic入門

RHELとCentOSってどう違うの？

communityの主体の違い
リリースもメンテナンスの期間も違う
Fedora -> RHEL -> CentOS

RHELとDocker

RHELへの移植
systemd統合
SELinux対応
kubeの開発も参加
RHEL7で正式サポート(Extras)
頻繁にrebase/リリースされるのでミッションクリティカル非推奨＆サポート限定的(RHEL7.1から制限なくなる予定)
コンテナの互換性（サポートの観点）
- x86_64のみ
- RHEL6/7のコンテナのみ
コンテナの互換性（その他）
- /procや/sysに依存するアプリケーションに注意
- A kernel chenge breaks GlusterFS
- firewalldをdisableにすること

Project Atomic

コンテナのためのホスト
CentOS Atomic HostとRHEL Atomic Hostはベースが違う
- CentOSをベースにRHEL Atomic Hostの変更をマージ
似てるもの
- Ubuntu CoreはホストOSじゃない
- CoreOSは良く似ている(CoreOSは一から/Atomicはベースがある)
RHELとAtomicの違い
- yumがない
- docker/etcd/kubernetesが標準で入る
- cloud-init / cockpitも標準
リソース消費量の比較
- CoreOS 46MB / Atomic Host 144MB
http://buildlogs.centos.org/rolling/7/iso/x86_64/
- qcow2
- metadata / cloud-init
vagrantで作ったよ（非公式）
- vagrant init yuryu/centos-atomic
- id:centosm password:vagrant
- 20141129版を元に作っている

Docker at Wantedly

最初はherokuを使っていた
東京リージョンがないからパフォーマンスが・・・
AWS + Docker

色々試した

Elastic beanstalk
Centurion
Chef with Docker

これにした

Capistrano3
Chef
Packer

Ubuntu / Private Registry(S3)
dockerレジストリは認証回避と可用性のため全ホストに配備
Capistrano3でスタティックオーケストレーション
- デプロイ
- コンテナの操作
- ホストの操作(scale)
デプロイ
- Dockerfileでビルド
- WebはNginxで新旧コンテナ切り替え
ChefとPacker
- dockerのホストのAMI
- 過去のレシピを再利用
Datadogでモニタリング
- 何時何分にどのインスタンスでコンテナが立ち上がったか
Logentries gemでログ収集
Chef+PackerでなくDockerfileでビルド使用
- ツールの観点
- キャッシュがほしい
でもDockerfileで書くのはツライ
- そういうアプリは、おそらくコンテナに向かない
- そもそもDockerは小さいアプリをのっける向けと感じた
「シンプルさを保つための制約を受け入れる」
Dockerホストは軽量にしよう
- AMI焼いてdocker pullで結構大変
- ホストに色々入れると単純に管理台数倍増する
herokuから学んだ事
- on-offコンテナという使い方
- 設定を環境変数で渡す
- コンテナを載せる基盤に必要なもの
その他
- 1コンテナ1プロセス
- ログはstdout/stderrへ
- モニタリング・ログ収集は専用コンテナでホストに入れると・・・
- Private Registryはオススメしない(早いが不安定な経験)
- capistranoは台数増えると遅い

後半のLT×8は以下からどうぞ
Docker Meetup Tokyo #4に参加(視聴)したメモ（後半）

Docker入門 Immutable Infrastructureを実現する

posted with amazlet at 15.02.04

技術評論社 (2014-04-25)
売り上げランキング: 2,162

Amazon.co.jpで詳細を見る

Software Design (ソフトウェアデザイン) 2014年 12月号 [雑誌]

posted with amazlet at 15.02.04

技術評論社 (2014-11-18)

Amazon.co.jpで詳細を見る

道玄坂LT祭りに参加してきた

in aurora, presto, REHL7, セミナー - on 22:44

前半だけしかも途中参加ですが少しだけ参加してきましたのでメモです。

■ 道玄坂LT祭り(ミドル・インフラ)
https://atnd.org/events/59894

「ミドルやインフラもカジュアルに語りたい」ということでLT祭りでした。

さくっとわかるAurora

クラウド用に再設計したリレーショナルデータベース
MySQL 5.6.1.0ベース
US East Limited Preview
RDBとストレージ部分が明確に分離
キャッシュの層は独自
ログストレージは独自実装
複数AZをまたいで共有型
S3への高速差分バックアップ
AZは3つ全部使う
RDSとの違い。実行容量が課金対象。
キャッシュがMySQLでなく独自で抱えているので、リカバリも高速
最大レプリカは15個まで（RDSは5個）
レプリカラグは約10〜20msec
キャッシュのヒットRatioも見れる。取れるメトリックスが増えた。

Presto＋MySQLで分散SQL

workerがconnector pluginを経由してデータストアをつつく
connector pluginはいろいろ使える（Hive・MySQL・PostgreSQLなど）
connector pluginは複数合わせ技で使える
demo:prest+MySQL+HiveでJoin
prestogres query -> presto -> Hive/MySQL
presto meetup 1/20

RHEL/CentOS 7 に移行しよう！

OSメジャーバージョンアップは宿命
新機能XFS/GRUB2/Network Manager/firewalld/OpenLMIなど
systemdを覚えないとREHL7は使えない？→serviceコマンドも使えるよ
徐々に新機能を使おう（無理して使わなくて良い）
- XFS->ext4
- systemd,journald->OK
- GRUB2->調べながらつかう
- ifconfigなど互換パッケージ使おう
- NW,FW->Disable
- OpenLMI->使わなくても支障なし
- 大量の更新されたパッケージ->コンテナをうまく使おう。違うOSバージョンの混在が可能。
むしろ性能向上に目を向けよう
- スケジューリングよくなった
- bonding強化
- 電力利用効率向上
- 40GbE
- bondingの強化などなど

その他の勉強会参加エントリーです。

日本OpenStackユーザ会(Neutron deep dive)に参加してきた - ぽぽぽぽーんのネットワークとOSS

第20回の日本OpenStackユーザ会(Neutron deep dive)に参加してきた際のメモです。当日取ったメモなので荒いです。日本仮想化技術さんのセミナーにも参加しました。 OpenStack最新情報セミナー＠渋谷に参加してきた | komei.com 12/1 Openstackユーザ会 19:00～ …

Jenkinsユーザ・カンファレンス2015東京に参加してきた | ぽぽぽぽーんのNWとOSS

2014/12/04＠日本仮想化技術のOpenstack最新情報セミナーに参加しました。Ustreamでの参加だったので少し途切れている部分があるかもしれません。

日本Jenkinsユーザ会主催のJenkinsユーザ・カンファレンス2015東京に参加してきましたので、そのメモです。登録人数は723人でした。400人くらい来てた(運営談)

サーバ/インフラ徹底攻略 (WEB+DB PRESS plus)

posted with amazlet at 15.02.04

伊藤直也片山暁雄平山毅舟崎健治吉荒祐一今井雄太八木橋徹平安川健太宮下剛輔田中慎司久保達彦道井俊介飯田祐基桑野章弘松浦隼人中村俊之福永亘杉山仁則
技術評論社
売り上げランキング: 10,164

Amazon.co.jpで詳細を見る

サーバ/インフラエンジニア養成読本ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

posted with amazlet at 15.02.04

鈴木健太吉田健太郎大谷純道井俊介
技術評論社
売り上げランキング: 12,879

Amazon.co.jpで詳細を見る

Jenkinsユーザ・カンファレンス2015東京に参加してきた

in docker, jenkins, セミナー - on 17:02

< 概要 >

日時 2015/01/11 (日)
場所法政大学市ヶ谷キャンパス外濠校舎
セッション/LT

http://build-shokunin.org/juc2015/

< タイムテーブル >

12:10~13:00 基調講演
- Jenkinsプロジェクトの現状とワークフロー
13:30~14:20
- 組み込み環境でのJenkinsによる多段階CIシステムask the speaker(川口耕介)
- はてなにおける継続的デプロイメントの現状とDockerの導入
- JenkinsとSeleniumの活用事例：試験自動化のプロジェクトへの導入
14:30~15:20
- JenkinsとPuppet+ServerspecでインフラCI
- クックパッドにおけるJenkinsの活用
- Jenkinsを使ったコンシューマゲームでのデプロイとテスト
15:40~16:30
- 「Infrastructure as a CodeにおけるJenkinsの役割」〜環境構築も継続的インテグレーションを行う時代です〜
- Jenkins導入する本当の理由を考えてみた
- おばかXFDコンテスト
16:30~17:20 LT大会

基調講演 Jenkinsプロジェクトの現状とワークフロー

参加できず・・・

情報募集中

13:30~14:20 はてなにおける継続的デプロイメントの現状とDockerの導入

< Agenda >

はてなのサービス開発とJenkins
ジャンプルーキーの開発フローとJenkins
Dockerコンテナによる環境開発とJenkins

1. はてなのサービス開発とJenkins

利用しているサービスについて

ブックマーク・ブログなど
- Perlで書かれている。そのためコンパイルは不要。
- テストの実行や静的ファイル生成、デプロイなどでJenkinsを活用
Mackerel
- サーバ管理サービス
- Scaraで書かれている
- 過去のプレゼン資料がsperkerdockに上がっている

Jenkinsの活用方法について

各サービスとjenkins
- サービスごとにJenkinsを準備
- あるサービス用の変更による別のサービスのテストが動かなくなる
- 関係者が少ない方がメンテしやすい
なんのためのJenkins??
- ソフトウェア進化を継続するため
- 意識しなくてもテストが実行される環境
- 面倒な手順の自動化
特にテスト
- 開発は各自のマシンで
- 本番に近い環境でのテストの実行と自動化のためにJenkins
Jenkins自体の管理
- Chefで環境構築
- プロダクトの本番サーバも同じ
Jenkins使用の方針
- Jenkinsの設定を複雑にしない（秘伝のタレ問題）
- シェルスクリプトをリポジトリに入れてJenkinsから誰でも実行できるように
スマホアプリとJenkins
- AndroidはGradleが標準になり、ビルドとテストがしやすくなった
- Android emulater pluginを使用

2. ジャンプルーキーの開発フローとJenkins

少年ジャンプルーキーって？

2014年リリース
漫画投稿サービス
250万ダウンロード

開発規模と環境

開発・運用：はてな
-　ディレクター１人、デザイナ１人
-　エンジニア数名（開発・運用）
-　最近のはてなでの開発・運用を踏襲／改善
サーバサイド
- perl
- mysql
- redis
フロント
- htmlは生
- TypeScript -> JS -> minified JS(ビルドプロセスが必要（開発者の手元＋Jenkins))
- LESS -> CSS(ビルドプロセスが必要（開発者の手元＋Jenkins))
ビルドツールやデプロイツール
ビルドツール
- gulp(Node.jp)
- TS -> JSやLESS -> CSS
- JSテスト実行
- 静的ファイルにダイジェストハッシュ付与デプロイツール
- デプロイ：Capistrano3(Ruby)
- Github Enterprise

開発プロセス

開発に用いるツール
- 日記+Wiki
- Slack
- Trello
- Github Enterprise
- Jenkins
開発プロセス
- スクラム、2週間①スクリプト
- リリースは毎週。とはいえ常に最新をリリースできるようにはしておく。
ブランチモデル
- GitFlowに近い
- master / staging /devel / features
- 基本はdevelブランチから切る。緊急リリースはmaterからブランチを切る
- Pull Requestはとりあえず開発中でも上げておく(議論のため)

開発時のJenkins

Jenkinsでやっていること
- pushされるごとにライブラリ更新、JS minify
- pushされるごとにテストとを実行
- 動作確認のために開発用ホスト(doceker)にデプロイ
- Github Plugin + script/jenkins.sh
- GH;Eの通知はシェルスクリプト内
課題
- slackとGH;Eだけなので弱い？->XFD?
- GH;Eへの通知がビルド処理の中にある

その他

開発が完了したらコードレビュー(develブランチ)
- Pull Requestに残す
- レビュアにとってテスト結果がGH;Eで通ったかが確認できるのは楽
デプロイ
- 本番リリース用のpull requestを作成(devel -> staging -> prod)
- リリースチェックリストをpull request
今後
- Jenkins Workflow Plugin（scripted control flow、ユーザのインタラクション機能もある）を検討

3. Dockerコンテナによる環境開発とJenkins

背景と利用環境

開発した機能の確認が遅れると困る
- 無駄な手戻り
- 開発スピードの低下
- 特にUI/UX
目的
- 開発中の機能(develブランチにマージする前)の動作やUIを手軽に確認したい
Devhostは誰のため？
- 開発者以外のチームメンバー
- 社外のメンバー（ドメインを用意する必要性）
既存の方法
- 1ホストに複数環境をデプロイ
- Nginxでドメイン別にポート番号ごとに振り分け
- ポート管理が手間、ライブラリが共有・・・
DockerによるDevhost
- Proxy用Plackアプリケーション+DockerAPIでポート番号を解決
- ゲストは80番で待ち受け
- ブランチからイメージをビルドする際にタグを付けておき、ドメイン名からブランチ名を取得->APIを叩いて対応するタグのポート番号を取得

やっていること

課題と対策
- dockerイメージのビルドに時間がかかる
- Dockerイメージのビルドにキャッシュが効く（プロジェクト全体をコピーする前に初期化スクリプトを実行しておく）
Jenkins上でのビルドとデプロイ
- Jenkins上でdocker build、docker rm -f(同じブランチのコンテナを止める)、docker run
- 実際のコマンドはrakeタスクにしてある
- タグを認識して変換する必要がある
- ビルド開始方法は現在手動(ブランチ名はビルドパラメータで受け渡し)
なぜJenkinsでビルドするのか
- 同じ環境でビルド処理を行わせたい
今後
- develブランチの手動でプロ胃
- pull requestとの関連付けの強めたい（コメントから作成、マージ後に自動破棄）
その他
- faviconで確認環境と他の環境を視覚的に変える

質疑応答

dockerでコンテナを作った時のテストデータはどうしているのか？
- ->データベースは一つを共有。スキーマ変更もやっている。
Pull Request時に何をテストしているのか？
- ->マージ後のものをJenkinsで実行はしていない

14:30~15:20 クックパッドにおけるJenkinsの活用

はじめに

宣伝：クックパッドのプレミアム会員になろう。レシピ意外にもサービス色々あるよ。

Ruby 2.0 + Ruby on Rails 4.1
Amazon Web Service

難しい事はしていないので、シンプルに説明をしていく

クックパッドでのJenkinsの使用環境

※ jenkinsではなく「おむきんす」を使用している

マスタースレーブ構成
- Puppet / Itamae(独自:Lightweightなchefを目指す)
- クラウドとオンプレミス(MAC OS/IOS環境のビルドなど)管理
- ラベルでノードを管理
ci-slave-ruby
- AWS上で6ノード、夜間は2ノードに縮退
- rbenvを使用
- テストはrspec
ci-slave-docker
- microserviceを進めている背景
- Go + Docker Engine用のCI環境
- ビルド・テスト・レジストリ登録
- GitHub Enterpriseを使用
ci-slave-android/ios
- オフィスのサーバルーム
- Androidは実機、Xcodeのバージョン管理で苦慮

なぜCIをしているのか？

< ユーザの要求を手元に届けるまでのサイクルを圧倒的なスピードで回したい >

CIで守れる価値
1. 意図しない変更を予防
2. 再現可能で自動化されている
3. リソースや情報を集約できる

意図しない変更を予防

意図しない変更が起きた時に開発者がすぐ取り組む文化が必要。

CIツールの速度改善への取り組み
- マルチプロセス化 -> 分散化 -> rrrspec(開発者ブログ参照)
通知について
- Failしたらhipchatへ通知する
- その通知時にmentionも使っている
- 誰がどこを失敗させたのか
- HipChat Pluginではなくjenkins-hipchat-publisher（独自）を使用している。失敗時のメンションと成功ビルドを通知しない機能
偽陽性を避ける
- 時間に依存するもの
- 組み合わせに依存するもの
- 性能に依存するもの
偽陽性があると・・・
- エラーを気にしなくなってしまう
- 本物のエラーを見逃してしまう
偽陽性への対処
- 最後に成功したビルドを夜間に繰り返し実行してみる
- 翌月初にシステム時間を変更して実行してみる
- 失敗したテストを再実行してみる

再現可能で自動化されている

CIでの自動化
- テストの自動化
- アセットの生成と管理
１日あたり10デプロイくらい
デプロイはhubot経由で

リソースや情報を集約できる

アセットの生成と管理
- コンパイルはrrrspecで実施している
静的解析
記録と可視化
- GrowthForecastでsuccess rateなどを管理

質疑応答

デプロイが１日１０回というのはどの範囲？
- -> 全社でフロントだけでなくバッチなども含む

15:40~16:30「Infrastructure as a CodeにおけるJenkinsの役割」〜環境構築も継続的インテグレーションを行う時代です〜

< Agenda >

サーバ構築フローとJenkinsの役割
サーバ構築の実践例とCI環境

サーバ構築フローとJenkinsの役割

女性向け恋愛ソーシャルゲームの開発
- 9コンテンツ／40サイトを自社運用
- イベントなどで急増するアクセス
- chefまわりは以前の発表がある。「slideshare autoscale ゲーム」で検索
構成管理ツールだけに頼ってた時の課題
- コードの複雑化
- Cookbook同士が疎結合になってない / 自動化できないので漏れ発生
- 実行結果を追跡しづらい
Provisioning Toolchainでサーバ構築を概念化
- Bootstrapping
- Configuration
- Orchestration

各レイヤーでやっていること

Bootstrapping
- OSインストールとサーバ起動
Configuration
- ミドルウェアの設定
- サーバの役割に基づいた設定
Orchestartion
- GlusterFSのClusterに追加
- zabbix-agentの起動
- jeninsからソースコードデプロイ
Releasalization (独自)
- 外部サービスとの連携
- LBへの追加など
- 変なサーバを本番環境に入れないようにする

Jenkinsの役割

ソースコードのデプロイ管理
ユニットテスト
サーバ構築の全体管理(new)

構築管理の変化

chefのRoleをJenkinsにパラメータとして渡しJOBの条件分岐
Build Flow Pluginを使用して可視化

サーバ構築の実践例とCI環境

各レイヤーについて

configration
- chef-soloを使っている。jenkinsからknife soloを打つ。
- jenkinsでGUI化できて楽になった
- chef実行結果のログを集約
- jenkins + serf(Go言語製オーケストレーションツール)
- serf はnodeでやりたい処理を実行
- jenkinsはイベント検知(serf join)とビルド
orachestation
- configuration -> orchestrationの橋渡しもserf(+tag)
- serfのtagはRoleをjson形式で要約
- serf queryで成功/失敗の判断と処理中断
- SSHが必要ない
Releasalization
- orchestationの内容をテスト
- 問題なければLBに追加して本番に入るようにしている
- serverspec

課題と改善策

chefのテストが簡単に行えない問題
- まっさらな状態がすぐ作りたい
- serverspecですぐテストしたい
改善策
- dcoker + chef zero
- jenkins pullrequest builder plugin
- feature = role名
- chef repoをmount

冗長化
- serfで通知
- jenkins起動
- EIP変更
- heartbeatなどは使用していない。100台のclusterで2秒(?)

Jenkinsでやってみた結果

JenkinsでChefの役割をシンプルにできた
ビルドの使い方次第でレイヤーが明確化される
JOBのログが残る/可視化
Build Flowを途中で止められる/不完全なものを本番に入れない

質疑応答

Auto Scaleは全体でどのくらい時間かかる？
- 前は20分くらいかかってた。AWSはAMIにほとんど仕込んでいるので最新のコードを引っ張ってくるのみで５分くらい。
Jenkinsの冗長構成のデータ同期は？
- GlusterFSはうまくいかなかった。Lsyncdを検討。今は同じ設定にしている。
今後やりたいことは？
- Autoscaleをもっと早くしたい

16:30~17:20 LT大会

1. Jenkinsを使った継続的Webセキュリティテスト

セキュリティテスト(脆弱性)
継続的なセキュリティテストを実施すべき
vaddy
- 無料プランのみ、何度でも
- SQLインジェクション、XSS
- Jenkinsプラグイン提供中
MeetUp 2/19(木) 新宿(doorkeeper)

2. Jenkinsおじさん、お堅いメガバンクに就職

配布ソフト(有償)が参照するレポジトリにプッシュしている
知識がない人でも簡単に作業が出来るようになった

3. Jenkinsおじさんと楽しい連携ツールたち

slackでビルド結果の通知を行う
- Emojiで少し工夫
Gitlab
- MergeRequestでmasterにマージする前にビルド、静的解析、テスト
- GitLab MergeRequest Builder Plugin
deploygate
- iOS/Androidアプリのテスト版アプリの配信
- gradle-deploygate-plugin(proxy使えるようになった)

4. ゲーム業界の人がJenkinsさん3Dモデルで遊んでみた

3Dロゴが出た
3D空間に出してみたのデモ
実際の画面でみないとわからないでのメモ断念。高級感溢れるおじさん。増えるおじさん。爆発するおじさん。REST API経由で赤く光るJenkinsおじさん。

5. CI”じゃない方”のJenkins

パッチ処理
- 結果の履歴残る
- cronより柔軟
- ssh/scpも不要
多システムの連携
- APIあればコントロールできる
負荷テストツール
- インスタンス + jmeter

秘蔵のシェルスクリプトをJenkins登録して表に出そう。

プルリクとかGitHub Flowから勉強したい人はこちらから。

GitHubでPull Requestを使わないのはもったいないと思ったので簡単な使い方をメモしておく - ぽぽぽぽーんのネットワークとOSS

GitHubでチーム開発なんて考えだすと、commitやpushだけではレビューをする時にもどかしさを感じることがあるかと思います。 GitHubやGitコマンドは使ったことあるけど、Pull Requestは使ったことない。という人向けに簡単に使い方をメモしておきます。 GitHubの基本的な使い方から学びたい場合は…