deploymenttl;dr学部4年になり忙しくなるので、よりすべてを「自動化」しようと思いました。紹介させていただきます。宣言的継続的デリバリーを定義させていただきます。記事のざっくりとして内容はマイクロサービスを継続的デリバリーことができるspinnakerを宣言的に構築するまるでCircleCIの設定ファイルのようなconfig.ymlを配置するだけでspinnakerのパイプラインを走らせることができる。既存の環境への親和性が高い「それぞれの設定がそれぞれのアプリケーションへ帰属」というわかりやすさtemplateは一括でrepoでモジュール化して管理しよう組織の財産となるtemplateとアプリケーションを分離することで管理しやすい再利用性です。設計したDCDフローは以下の通りです。解説は記事を読んでください。kubernetesは非常に機能が多く、マイクロサービスを導入しやすくして、よりアジャイルな開発へのパラダイムシフトを促したソフトです。manifestファイルと呼ばれる、どのロードバランサーに何を繋げて、どのくらいのVMで、、、といったようなことがすべて宣言的に書けて、Deployするにはapplyコマンドを叩くだけです。Deployが毎日数回など行われるときにapplyコマンドを叩くのは面倒です。現状として、Botを使ってSlack越しでDeployしたり、CIに任せて要るケースがほとんどです。Deployとは単純な作業ではなくて、実際にはデプロイ後に変な挙動をしていないか、他のマイクロサービスとうまく連携が取れて要るかなど、確認することが膨大にあります。DeploymentRollbackが安全にできるかビジネスモデルとの連携...https://sweetcode.io/13115-2/これらをメンテしていくのは難しく、よくチームに「インフラエンジニア」や「SRE」などと肩書きがつくエンジニアが面倒見たりしています。考えるかもしれません。確かにインフラには専門的な知識や経験が必要で、膨大なドキュメントを読まないといけません。https://www.youtube.com/watch?v=LVgP63BkhKQ確かにインフラにマジつよエンジニアがいればその人に任せることができます。実際、どの会社もそのような形態を取っていることが多く、採用でもコースが分かれているほどです。今年、夏休み1週間くらいインターン行こうかなって思って募集を見ていたらサイボウズSummerInternshipがこのようになっていて、やはりサーバーサイドとインフラの乖離はどこでもあるのだなと痛感しました。一人に任せるのにはデメリットがあり、インフラで起きることのフィードバックをその他のエンジニアに還元できない責任がインフラエンジニアだけに生じる本来の企業としての価値は生んでいない...のようなことが挙げられます。Infrastructureを強制できるのような特徴があり、現在のDeploy問題を解決します。以下のようなメリットをもたらします。UIや通知でエンジニアにフィードバックソースを更新したエンジニアに直接還元PodやServiceなども監視することができるプロジェクト単位で管理できるしかしGUIでぽちぽちするのでMutableなのです。新米エンジニアが設定するときにうたた寝をしてしまい、レプリカ数を1000にしてしまうかもしれません。宣言的にしないといけないのです。宣言的がいいのかそもそも宣言的とは設定ファイルを書いて、あとは何もいじれない状態です。そのような面でCircleCIはテストを宣言的に書いているといえます。config.ymlなどに設定を描き、それを反映させます。すると、それ以降は誰もいじれません。このようにすることで誰でもconfig.ymlなどがあれば同じ環境を作れる。複製が容易になり、マイクロサービスに使えやすいDeploy戦略を構築しやすいスノーフレークサーバーを生み出さないなどなどメリットがたくさんあります。これをSpinnakerに適用すると、すぐあとで説明する「知的デプロイ」という、デプロイ戦略やフィードバックを含むデプロイまでを宣言的に書くことが宣言的Spinnakerの目的です。現状では、Deployは継続デリバリーで実現しているところはありますが、Deploy戦略までは宣言的に実現している組織は見当たりませんでした。僕がドキュメントにContributeさせてもらった商用SpinnakerであるArmoryでは以下のようにソフトウェアデリバリー(CD)のレベルを定義しています。高いのは知的デプロイ(ID)です。Infographic大まかに説明すると従来(低いCD)はMutableのものは「デプロイはイベントごと」くらいひやひやする開発遅い危ない宣言的のメリット最もレベルの高い知的デプロイは自動カナリアデプロイ自動ロールバックカオスエンジニアリングなどの特徴がありデプロイもものすごい数が行われます。マイクロサービスに分けてサービスごとのチーム・組織を組み、開発サイクルを高速に回すことが可能となります。このようなことから、エンジニアやデザイナーが創出した価値がユーザーにすぐに届けられるわけです。宣言的のよさがわかったところで、Spinnakerの詳細に入りましょう。Spinnakerでの概念Spinnakerにはいくつか重要な概念があるので説明します。applicationこれは特定のリポジトリで使われることが多いです。レポジトリごとにアプリケーションを作るのが良いのではないかと思います。applicationを作成するpipelineテストして、デプロイして、監視して、通知してなどの流れを定義する水道管のようなものです。実際に簡単なものを作るとこんな感じです。templateに「レプリカ数はその時に決めるよ」のように書くと、pipelineを使うときに変数定義ができます。Pipelineとなり、あとから設定を消すことはできません。Pipelineを作るときにTemplateを指定します。すると変数を定義する画面に遷移するので変数を定義します。Pipelineが完成します。」と後から変更ができないようになっていることです。これによって誰が作っても同じ構成で、変更すべて変数だけ作成時に指定することになります。宣言的Spinnakerの導入コンセプト重要なコンテプトとして以下のようなことを設計思想にいれました。それ以外はいじらなくていい今回作るものngnixサーバーを更新すると、CircleCIがテストをして、カナリアデプロイして、SlackにWebhookを送るパイプライン実際のプロジェクトgithubリポジトリをアプリケーションとテンプレートの二つに分けています。テンプレートを保存してあるリポジトリのファイル構成です。template.ymltemplate.ymlにSpinnakerのUIに1対1対応するように記述します。Serverなどのアプリケーションのファイル構成です。余計なもの(READMEやgitignoreなど)は省略させていただいてます。default.conf今回、Spinnakerの設定ファイルは.spinnaker/value.ymlに定義し、以下のようになっています。アプリケーションを更新したときnginxを更新するとCircleCIが走ります。Jobはこのようになっています。testpipelineをデプロイnginx/Dockerfileでイメージを作ってGCRにpushする二番目の手順であるpipelineのデプロイはSpinnakerで確認できます。三番目のジョブはGCRにプッシュすることです。pipelineはできていました。GCRにpushされるとパイプラインが実行されてカナリアデプロイの完了です。これを実際にやってみます。アプリケーションは作ったものの、何もpipelineが定義されていない状態からスタートです。requestを作成してmergeをするとします。するとCircleCIでworkflowが走ります。testジョブが走りましたが、何も変化がありません。testが無事に終わって、Spinnakerにpipelineを走らせるジョブが走っています。