2019年に向けて抑えておきたい技術Knativeの概要を抑えた記事でしたね。2nd」がその後どうなったのか?という事、で、2018年現在の状況を書きたいとおもいます。2nd」を読まれてない方は、昨年記事もご参照ください。2018の22日目です。さんの「続・IaaS基盤をテストする環境を作る話」でした。この記事では、Knativeを構成するコンポーネント群と、それらを構成するCRDについて紹介したいと思います。ニフクラではエンジニアリングパーツという形でニフクラ上のシステムに組み込みやすいパーツを提供しています。サーバーレスを実現するサービスです。エンジニアリングパーツのようなサービスを実現するためには数多くの技術を取り入れる必要があるのですが、Knativeはその中で注目している技術のうちの一つです。サーバログイン時にエモい画像を出してAORI駆動開発してみた話でした。/dev/pts/XX)を思い出しました。この話を参考にすれば、より強いAORI力を得られていたと思います。仮想インフラ周りのテストにまつわる話をしたいと思います。導入しようという動きについて簡単に説明します。IaaS型のクラウドサービスの仮想化基盤の面倒を見るのが中心です。した多種多様のサーバーを運用しています。管理する台数も多いため、それらの運用は随所で自動化がなされています。行っており、比較的コーディングを行う機会は多い業務になっています。紹介している取り組みなどは、スクリプトの改善の良い例です。トラブルの再発防止のために監視項目を追加したいということもしばしば発生します。日常的に必要になっています。サービス障害に結びつくことも珍しくないため、その品質についても担保しなければなりません。変更が大きくなることで、トラブルを生むリスクが増す変更を加えられる間隔が長くなるため、改善を図ってから恩恵を受けるまでが遅くなる変更に対する工数の多さがモチベーションを下げ、細かな問題は放置されやすくなるといったリスクがあると考えています。いう思いから、CIの考え方を導入したいと画策し、去年より活動しています。求めていたメリットを得られることが期待できます。実際にはテスト環境を整備する部分に大きな課題がありました。hypervisorを活用し、テスト環境をオンデマンドに作成できるようにしました。(一部、去年の内容と変わっていますが、問題があってやり方を少し変えていたりするためです。クリーンな状態が保ちづらい状況にありました。あるため、環境の数に応じて物理サーバーが必要になるので環境の数自体も制約が大きい状態でした。出来るほどの環境の数もないような状況でした。そこで、以下のようなアプローチでこの問題を解決しています。hypervisorと呼ばれています。柔軟に扱うことが出来ます。環境をいくつでも複製できることになります。以降同じような環境を簡単に作成可能になります。ストレージ容量を大量に消費する上、コピー自体に時間がかかってしまいます。cloneと呼ばれる方式を利用します。cloneであり、実際に書き込みが発生して差分が生まれるまではCloneしてもほとんど容量を消費しません。ネットワークの隔離また、Cloneする方法はストレージ以外にも問題があります。Clone前後のVMたちが同じL2ネットワークセグメントに属することが出来ません。他の環境に影響を与えないネットワークを利用できます。1台だけ環境の外と中の間を橋渡しできる踏み台サーバーを用意し、それを利用することにします。環境内で使うためのDNSサーバーを稼働させています。マウントすることで、コンテナと間接的にファイルシステムの一部を共有できるようにしています。全てまとめて削除できるようにしています。私が検証した環境ではFreeNASの領域をiSCSIマウントするほうが高速でした。自動ビルド環境が整備できたところで、まずは自動ビルドをすることにしました。期待できたため、優先的に取り組みました。先に説明したテスト環境にIaaS基盤運用のシステムを自動構築することに他なりません。テスト環境内にてこのAnsibleを実行することにより、自動ビルドは実現することができました。特別な工夫はあまりありませんでした。clone(実際に全てコピーする)することにしています。用意できるようになるためです。これに基づいて、実際にシステムの正常性を確認するテストをする土壌が整いました。実際に実施している自動テストの例として、DHCPサーバー及びその関連サーバーのテストがあげられます。私の知る限りでは一般的に定着しているものはありません。非常に大きいのではないかと思います。そこで、今のところは以下のライブラリなどを中心に使いつつ、Pythonでテストを書いています。現状ではやむを得ないと考えています。インフラのテストを進める上で、設計がテストのしやすさに影響すると感じました。MailHogを導入するということがありました。SMTPサーバーに相当するコンポーネントは不要で、Zabbixだけを確認できれば良かったでしょう。それら全てをまるごとテスト環境に詰め込んでいるという側面もあります。インターフェイスを統一することで、テスト環境に必要なコンポーネントを少なくすることも可能なはずです。この考えに基づけば、テストしやすいインフラというものを設計段階から考慮すべきなのかもしれません。以下のように出来ていないことや解決したいこともたくさんあります。推進していく予定です。機会があればお話したいと思います。@herietさんの「KnativeのコンポーネントとCRD」です。今日の記事とは打って変わってServerlessの話題になりそうですね。LIMITEDスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。