読者です 読者をやめる 読者になる 読者になる

Concourse Meetup Tokyo #5

Infomation

Schedule

Reception(19:00-19:30)

  • Pivotalさんから提供のピザとビール!

Talks(19:30-21:00)

Use database in your Concourse Pipeline (Gwenn Etourneau, Pivotal Japan)

  • Concourseの中でCIする際にDB等ともつなげたいケースがある f:id:morika-t:20170313230525j:plain

  • Taskのなかでdocker-composeを呼ぶというアプローチもとる事が可能 f:id:morika-t:20170313230616j:plain

f:id:morika-t:20170313230752j:plain

From legacy to modern CI/CD in TIS with Concourse (Kazuya Ishida, TIS)

f:id:morika-t:20170313231043j:plain

  • 1年前からPCF導入
  • 社内でもJenkinsを検討したが、以下の理由でConcouseを採用
    • Cloud Foundry自体もConcourseを採用している
    • 再現性が高い
    • Pivotalの方からの熱い提案

f:id:morika-t:20170313231542j:plain

  • 開発者はGitlabを使って更新しconcourseからmvn等を叩く
  • 会社のネットワークポリシーに従ってConcourseを環境毎にそれぞれ配置している
  • 最初は簡単なpipelineから始めて、大きくしつつタスク共通化を実施
  • 今後の課題
    • 本番にデプロイした後切り戻す方法
    • 通知系として今後はSlackやメール連携
    • UAA連携も実施
    • PCFのバックアップなどもpipelineからやるなど

Lesson learned using Concourse in Production (ChatWork, Shingo Omura)

www.slideshare.net

  • ここ数ヶ月プロダクションでconcourseを使ってきてその良かったことなどを紹介
  • opsチームがスケールしない問題を改善したいという思いが強い f:id:morika-t:20170313232207j:plain

  • concourseの良かった点

    • ドキュメンテーションが充実しているのでpipelineを書く際にあまり躓かなかった
    • Jenkinsとの比較で良い点としてはプラグインの管理がJenkinsは大変だがconcourseは全てがdocker imageで管理されているのでサーバの構成管理が不要
    • ビルドの履歴とpipeline以外は管理していない
    • チームサポート機能が便利だった(チームごとのpipelineの分離)
    • 認証機能の選択肢が複数あったのが良かった。現在はGithubのものを使っている
    • concourseもローカルで立てる事が可能なのでpipelineを手元で開発してそのまま本番に持っていってもトラブルが起きにくいのが良かった
    • resourceまわりが全てdocker imageなのでカスタマイズがし易い
  • pipelineのTIPS
    • aggregateを使うと並列実行可能なので時間がかかるリソース取得部分等並行実施がオススメ
    • ci skipなどを使って不要なタスクは実行しないようにするのがよい
    • 汎用的なタスクを使う時はinput_mappingを活用すると良い
    • attemptsを使うことで1発NGでテストが落ちないようにリトライさせると良い
  • concourseで改善したいこと
    • ロールベースのアクセスコントロールがないので、pipelineの実行や更新等をユーザごとに分けたりがしたい(fly get pipelineでcredentialsが見えてしまうので)
    • parameterized jobが欲しい(ブランチ指定して何処かにデプロイする等のケース)

Building Concourse in Yahoo!Japan (Kei Kitai, Yahoo Japan)

  • concourseを自社で立ち上げている中での問題などを紹介
  • Pivotalの方からの熱い提案でconcourseを採用
  • 人的リソースがなかったので採用を決断

f:id:morika-t:20170313234340j:plain

  • 導入前に気がついた課題
    • 社内のdeveloperが1000人以上居るのでconcourseの台数が必要だった
      • BOSHによって解決
    • concourseのチーム分割単位をどうするか
      • Cloud FoundryもあるのでUAAを使おうと思ったが、既にGithub Enterpriseで適切なOrg分割がされているのでそちらを採用
    • DBへCredentialsがそのまま入ってしまう部分について
      • 会社のセキュリティポリシーではそのままでは問題があったのでconcourseのDBは別のNWに構築しACL等で暫定対応
      • Using Vaultの動きで解決できると期待している

f:id:morika-t:20170313234305j:plain

  • 立ち上げた後に気になったこと
    • 100以上のサービスが有るので現状のresourceのfetchの仕組みがpollingのみでGithub Enterpriseへの負荷が高い
      • 暫定で中間サーバを用意ししてworkerからは中間サーバのものを持ってくる用に変更
      • web hookによるトリガーが欲しい

Build an iOS app with ConcourseCI (Akehito Amanuma, TIS)

www.slideshare.net

f:id:morika-t:20170313234403j:plain

  • Jenkinsの職人問題としてプラグイン問題がやはりあった
  • pipelineのコード化を実施したいというモチベーション
  • iOSアプリのビルドを実施するためworkerをdarwin用のものを用意して動かした
  • CocoaPodsがrootでは実行出来ない為、タスクの中で権限周りの処理が入っている
  • 環境変数周りで苦戦して30回目でビルドが通った
  • 残課題
    • CI結果のレポートの出力先等をどこにするか
    • RocketChatへの通知
    • Multi Branch Build

PCF上でのconcourse利用について紹介(Tomohiro Ichimura, Pivotal)

  • create serviceでconcourseが使えるようになる
  • Cloud Foundryにおける同一のSpaceだけが使えるようになる(要SpaceDeveloper権限)