Edited at

DevOps について改めて(社内LT用)

More than 1 year has passed since last update.



概要

DevOps について、今さら感たっぷりではありますが、改めて何がどう美味しいのかを社内LT用に簡単にまとめます。



DevOps とは

開発者と運用者が、円滑に業務に取り組めるための仕組み。あるいは考え方



なぜ、DevOps が生まれたか








  • 開発部門は「どんどん機能を追加していきたい。」

  • 対して運用部門は「安定したシステムに手を加えたくない」

  • という矛盾。



じゃあどうすればよいか?(当方の理解)

端的には、あらゆるものを自動化してしまう。



あらゆるものを自動化する


  • チームがブレイクスルーを起こすためには、Dev の「どんどん機能追加を」のスピード感を損ねてはならない

  • では Ops にて、あらゆるものを自動化して、両者の衝突を回避すればよい

  • 具体的には「継続的インテグレーション(Continuous Integration)」。つまりは CI。


以下、インフラ込みの CI フローの一例です。ちなみにアプリケーションより上は予測で書いてます!



  • Dev が新機能のソースコードをバージョン管理に Commit。

  • Commit をトリガーに、Jenkins 等の CI ツールが起動。



  • Jenkins にて、AWS などクラウド上の仮想サーバを作成。

  • Chef/Ansible 等のサーバプロビジョニングツールにて、OS/MW の構築を自動で実行。



  • Serverspec 等のサーバテストフレームワークにて、インフラのテストを自動実行。



  • Git 等のバージョン管理リポジトリから、最新のソースコードを Checkout。

  • デプロイツールにて(Java で言うところの Ant)、アプリケーションデプロイを実施。

  • CI ツールにて、アプリケーションのテストを流す。



  • アプリケーションテストが通れば、BlueGreen Deployment にて本番適用。

  • BlueGreen Deployment とは、新規にデプロイした仮想サーバ・アプリケーション群に、トラフィックの流れを切り替える手法。




  • 切り替えは、DNS もしくはロードバランサでやる。

  • 既存のサーバ群は破棄。捨てることが簡単、これぞクラウドインフラの真髄である。


という一連の流れを、CI ツールを軸にすべて自動オペレーションにしてしまう。

Dev がアプリケーションのソースコードを Commit しただけで本番適用まで一気通貫となる。

という仕組み・フローを Ops が提供する。



その結果。。


  • 「どんどん機能を追加していきたい。」を、一連の自動化でスピード感を損なわず!

  • 「安定したシステムに手を加えたくない」では、BlueGreen Deployment にて既存サーバに手を加えず!

が、いわゆる1つの DevOps と理解してます。



DevOps を GLODIA でどう活かす?

Gitバケット と Jenkins は社内にあるので、Web開発が今後あればぜひ アジャイル/DevOps にて!

以上。