Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インフラCI_CD継続的改善の道のり

ryuichi1208
March 13, 2023
1.4k

 インフラCI_CD継続的改善の道のり

ryuichi1208

March 13, 2023
Tweet

Transcript

  1. 3 アジェンダ 1. 自己紹介 2. 担当サービス紹介 3. 所属チーム紹介 4. インフラCI/CDについて

    5. 抱えていた課題 6. 解決へのアプローチ 7. まとめ 8. 参考
  2. 技術部プラットフォームグループ 2021年 中途入社 5 自己紹介 渡部 龍一 Watanabe Ryuichi •

    ロール: SRE • 趣味: 旅行、ドライブ、(緩めの)自宅サーバ • 好きな言語: Go、C言語 • Twitter : @ryuichi_1208
  3. 6 自己紹介 • 経歴 ◦ 2017年〜 Linux向けファイルシステムの開発プロジェクト ▪ テストやデプロイの自動化を担当 ◦

    2019年〜 ニュースサイトの開発/運用 ▪ CI/CDパイプラインの改善でJenkinsやCircleCIの導入推進 ▪ インフラをメインで見ていたがアプリも書いたりしていた
  4. 8

  5. • カラーミーショップのインフラの歴史 • オンプレ期 • プライベートクラウド期 • k8s on プライベートクラウド期

    • ハイブリッドクラウド期 • 詳しく知りたい方へ (https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji ) 10
  6. • 所属 • 技術部プラットフォームグループ • 役割 • ペパボのサービスの可用性を確保し、成長に合わせて適切な環境を提 供するグループ •

    ミッション • サーバーの調達やキッティングに止まらず、SRE によるサービスレベ ルの向上やクラウド環境の検証や選定を行い、必要に応じて事業部門 のアプリケーションの改善、開発を通して事業の成長を支える 12
  7. 15 サービスの構成 LB App DB VM or k8s AWSで稼働 •

    プライベートクラウドとパブリッククラウドを用いたハイブリッドクラウド • アプリケーションは80以上のロールで構成されている • AWSとプライベートクラウドは専用線 (Direct Connect)で通信
  8. 16 サービスの構成 LB App DB VM or k8s AWSで稼働 •

    積極的にk8sへの移行は実施している ◦ それでもロールの数は VM > k8s ◦ VMとk8sが混在している ◦ 一部のロールはコンテナ化はしない予定なので今後もこの状況は続く
  9. 17 インフラ周りで使っている技術スタック(抜粋) プラットフォーム OpenStack, AWS, Kubernetes 開発言語 Ruby, mruby, Go

    ミドルウェア Nginx, MySQL, Redis, memcached CI/CD GitHub Actions, ArgoCD 監視 Mackerel, Prometheus, Grafana, ElasticAPM, DataDog IaC Puppet, Ansible, Chef, Terraform
  10. 18 • Puppet ◦ puppetlabs/puppet ◦ OS設定やアプリケーションの構築を自動化するオープンソース・ソフトウェア ◦ Pullモデル ◦

    manifestはRuby-likeなDSL(Domain Specific Language: ドメイン固有言語)で 記述する ◦ 今回紹介するサービスではメインで使用している 主要ツールの紹介
  11. 19 • Serverspec ◦ mizzy/serverspec ◦ サーバの構成を自動でテストするオープンソースのテストフレームワーク ◦ RubyのRSpecのような使い方が可能 ◦

    「サーバ構築後の確認作業の自動化」「稼働しているサーバの監視」「サーバの再 起動時の状態確認」などに使う事ができる ◦ 今回紹介するサービスではインフラの CIへの組み込みに加えて稼働しているサー バに対しての実行も行っている 主要ツールの紹介
  12. 20 • CI/CD(VMの場合) • OpenStackレイヤの管理はTerraformを使用 i. インスタンスやネットワーク領域 • ミドルウェアの管理はPuppetを使用 i.

    ミドルウェアの設定や監視も担当 デプロイパイプラインの紹介 ローカルでの確認は各自で VMを用意 コンテナに対してPuppetをapply Serverspecを使ってテストを実施 integration/staging/production 環境ごとデプロイ
  13. 21 デプロイパイプラインの紹介 manifestの修正をpush Dockerfileのテスト DockerImageのbuild/push • CI/CD(Kubernetesの場合) • kubectlのデプロイは原則禁止 •

    GitOpsのフローを取っている i. main branchがstaging環境へ適用 ii. release branchの状態がproduction環境へ適用
  14. 24 • デプロイまでのフロー ◦ 例) nginxのパラメータを一つ変えるための PRを出すまでに ▪ 設定変更を入れるようにコードを修正 •

    ローカルにVMを用意してコードを適用する(15分) • Serverspecと実際のVMの設定を見て問題ないかを確認する ▪ 問題なければGitHubにpushしCIが実行される • lintやセキュリティの静的チェック • CIでコンテナを起動してコードが適用される(20分) • CIは毎回プレーンな環境で実行される ◦ 修正とは関係ない箇所の適用もやり直しになる ◦ 末尾セミコロンを忘れた際の修正確認でも 20分追加でかかる テストに時間がかかりすぎる問題
  15. 25 • 久々にPRを作ったら、変更箇所以外のところでテストが通らなくなってる ◦ CIは実際のVMではなくコンテナを使ってVMをエミュレートしている ◦ 存在しないパッケージをインストールしようとして落ちている ◦ latest指定しているパッケージが後方互換性がなく落ちている ◦

    token期限切れて落ちている ◦ 障害対応でCIを飛ばしてリリースした時の修正が原因で落ちている ◦ テスト自体の取り決めもなかったので粒度がバラバラ ◦ linterとかをアップデートしたらCIが通らなくなった ◦ 何もしなくても時間の経過と共にシステムは壊れていく ▪ システム疲労 テストのメンテナンス大変問題
  16. 26 • VMはミュータブル ◦ 構成ドリフトやスノーフレークサーバが存在していた • 障害時のアドホックな対応などが残っているケース • 半年近くデプロイされていないロールが存在する ◦

    パッケージのバージョンがlatestで指定されているものもある ◦ 意図せず大きめのアップデートが走ってしまう • 構築時にコード管理せずに管理されたロールも存在する • テスト環境で動作が問題なしでもproductionでは動かないケース ◦ オートメーション恐怖症 ◦ さらにコードを触る人が減っていき属人化が進んでしまう コードとサーバで差分がある問題
  17. 29 • パッケージ等の脆弱性をチェックするツールは動いていた ◦ Trivyやtfsecが実行されている • 報告される数が膨大で全てを対応することはできていない ◦ 報告された脆弱性は深刻度が高いもの以外の優先度が上がらない ◦

    パッケージアップデートした後に期待する動作をするかどうかを知る術がなかった ◦ 既知の脆弱性へのパッチなど、セキュリティアップデートを自動化 セキュリティ対応問題
  18. 30 • IaCだけでも複数ツールが使われている ◦ Puppet, Ansible, Chef, Terraform • 運用ツールなんかも多数の言語で実装されている

    ◦ ShellScript, Perl, Ruby, Python, Go • インフラの設定変更を入れたくても複数ツールを学ぶ必要があり最初のス テップのハードルが高くなっていた 使用しているツールが多く学習コストが高い問題
  19. • CIの高速化 • 暗黙知の徹底排除 • テストの拡充 • 開発環境の整備 • 構成ドリフト検出のための仕組みの実装

    • コンテナ on VM • 監視の見直し • デイリーでコンテナイメージをビルドする仕組み • 権限移譲を進めた 33
  20. 35 • GitHub Actionsの設定のチューニング ◦ bundle installやlibrarian-puppet installを都度実行していた ◦ actions/cacheの導入やstep

    の並列化の基本的なことを実施 ◦ 2~3分程度の時間の削減に繋がった CIの高速化
  21. 38 • 誰でも簡単に触れるように ◦ ドキュメントの整備、勉強会、ワークショップの実施 ◦ 認知負荷を減らすためにCIに関する作業の自動化を実施 ▪ mainブランチへマージ後にローカルから必要だったデプロイを自動実行するようにパ イプラインを修正

    ▪ テストを動かすためのコマンドはあるがオプションが大量にあって何を指定すればよ いかわからない • Makefileを用意して指定するオプションの最小化を目指した ▪ CIを実行するにはPRに対して必要なラベルを自分で設定する必要があった • 修正したファイルによって適切なCIが実行される仕組みを自動化した • サービスの説明や構成図を作成 ◦ k1LoW/ndiagを用いて構成図などもコード管理を実施 暗黙知の徹底排除
  22. 39 • テスト通る=本番でも期待している動作をするを目指した ◦ テスト自体が形骸化しているロールが多数存在したので直していく ◦ nginxを例に ▪ パッケージをインストールするまでがテストされていた ▪

    configが正しいかや正しくてもきちんと起動するかまでは確認されていなかった ▪ PuppetやAnsibleでtemplateを使って生成するファイルが正しく生成されているか ▪ 期待したポートでlistenされているかやupstream設定が正しいかの振る舞いテストも行うように した テストの拡充
  23. 40 • 開発環境のセットアップもテストする ◦ setupコマンド自体が動かなくなるケースもあったので定期的に CI環境で実行する 仕組みを入れた • ローカル環境での動作確認を簡単にできる仕組みを用意した ◦

    Vagrantを使っていたがM1 Macだと動かせなくて動作確認がすぐできない ◦ ローカルで色々試せない=入門へのハードルが上がる ◦ ローカルでもコンテナを使って試すことができる用に環境を整備 開発環境の整備
  24. 43 • 定期的に差分検出やコード適用を実施 ◦ TerraformのplanやPuppetのデプロイを時間を決めて自動実行する ◦ 定期実行のplanで差分が出る=コード化されていない変更有 ◦ Serverspecを稼働しているサーバに実行し差分がないかを確認 •

    デプロイフローが複数あって何が適用されているかわかりにくかった ◦ 変更履歴の管理が容易になりいつ誰が変更したかを追跡しやすくなった 構成ドリフト検出のための仕組みの実装
  25. 45 • VMとKubernetesの移行期間 ◦ VMで起きた問題を対応する際にVMでは修正したがコンテナは修正されていない という事が度々発生した ◦ Kubernets化をすぐにできれば色々な経緯があってうまくできていない • Kubernetesを使わずにVM上でコンテナを動かす

    ◦ DockerをVMで動かして1コンテナ=1VMで動かす ◦ VMへの修正=Dockerfileを修正してimageをpushしておけばよい ◦ 修正漏れが減るメリットはあるがデプロイフローが複雑化する コンテナ on VM(取り組み中)
  26. 47 • パッケージの脆弱性は最新版では改善されているケースがある ◦ プログラミング言語やミドルウェアを除いて Dockerfileのパッケージバージョンでは latestを指定 ◦ ビルドしたイメージをpushしておきstagingなどで動作確認 ◦

    問題なければproductionに出し ◦ ミュータブルなVMでもyum-cronなどの仕組みを用いて実施 ▪ 全台同時に更新ではなく一部の VMのみに適用し問題ないかを確認する ▪ 問題がなければ全台に適用 ◦ 脆弱性があるまま運用するよりもよりセキュアな状態になる方向へ舵を切って進め ている デイリーでパッケージを最新化していく
  27. 48 • 自動化しても拾いきれない脆弱性は存在する ◦ 例 ▪ パッケージ管理ツール以外でインストールしたミドルウェア ▪ EOLを迎えているアプリケーションを使い続けている ◦

    アップデートするためには専属のメンバーをアサインして対応 ▪ 脆弱性報告へのトリアージ /対応 ▪ 脆弱性アラートの仕組みの改善活動 ▪ 1週間交代で進めていく セキュリティ対応体制
  28. 53 • CI/CD改善で生産性はどう変化したのかを計測 ◦ Four Keysを用いて可視化を行いより改善活動を効果的に実施したい • Immutable Infrastructureの推進 ◦

    Kubernetes化は引き続き進めていくのに加え難しい箇所はコンテナ on VMの構 成が取れる箇所は取っていく • CI/CDパイプラインで使うツールの継続的アップデート ◦ IaCを実現するためのツール自体は手動でアップデートする必要がある ◦ CI/CDパイプラインのセキュア化という課題への取り組み 今後やっていきたいこと
  29. • Web • インフラCICDの勘所 • 現場に合わせて考えた パイプラインのデザインパターン • 書籍 •

    インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現 • Infrastructure as Code • Serverspec • Kubernetes CI/CDパイプラインの実装 • 継続的デリバリー 57