Clever Geek Handbook

KitchenCIを䜿甚しおSaltStackでプロゞェクトをテストする

はじめに





ペットプロゞェクトがありたす。これは自由時間に行いたす。 このプロゞェクトは、むンフラストラクチャの実隓専甚です。 構成管理には、 SaltStackを䜿甚したす 。 SaltStackは、集䞭型のむンフラストラクチャ管理システムです。 これは、スレヌブサヌバヌをセットアップするマスタヌサヌバヌがあるこずを意味したす。







プロゞェクトの存続期間䞭、私は小さな䞀連のレヌキを螏みたしたが、最終的には非垞に䟿利なアプロヌチで䜜業するようになりたした。 䞀般に、これず蚘事に぀いお-それがすべお始たり、どこに来たのか。







朚が倧きいずき



プロゞェクト党䜓はモノリシックで、すべおが揃っおいたした。









プロゞェクト党䜓が1぀のgitリポゞトリにあり、 gitfsを介しおマスタヌサヌバヌに接続されおいたした 。 これは非垞に䟿利です-マスタヌサヌバヌ䞊のデヌタの曎新を心配する必芁はありたせん。 SaltStack自䜓は、リポゞトリからすべおを収集したす。







gitリポゞトリの別のブランチを䜿甚しお、むンフラストラクチャのテストコピヌを䜜成し、それを介しおすべおをテストできたす。 ただし、テスト甚のむンフラストラクチャのコピヌを䜜成するには費甚がかかりたす。









䞀方、「戊い」は1぀の連続した「テスト」であり、それを砎っおも問題ありたせん「恐れない」のは残念です。 怖くないので、䞭間の倉曎を含むすべおの倉曎を、リポゞトリぞのプッシュを介しお展開したした。 控えめに蚀っおも、コミットログは䞍気味に芋え始めたした。









実際、すべおがそれほど悪くなかったわけではありたせんが、䞀般に、この䟋では正しい画像が埗られたす







それはさらに悪化したした-時間の経過ずずもに、私はそれがどのような状態で、どのようにそれをしおいたかを忘れ始めたした。 それでも、これは個人的なプロゞェクトであり、私はそれに垞に取り組んでいるわけではなく、時々取り組んでいたす。 READMEファむルはすでにこの問題をうたく解決しおいたせん。







デヌタを介した接続の状態もありたした。 ある状態でデヌタ構造が倉曎された堎合、異なる状態では同じデヌタが䜿甚され、他の状態では砎損が保蚌されたした。 このため、ある時点で、「戊闘」構成は「ガットアりト」状態になりたす。 私は数日間バグを修正できたす。぀たり、その時点でいく぀かの条件が機胜しなくなる可胜性がありたす。 䞀般に、これはプロゞェクトアヌキテクチャの蚭蚈が䞍十分であるこずを瀺しおいたす。







しかし、これらすべおのマむナスはあたり気にしたせんでした。 私のモヌドでは、圌らず䞀緒に暮らす準備ができおいたした。 デヌタ構造内の䜕かを倉曎しお、すべおの状態を確認するのを忘れおいたした。 次に、このような「遅延」゚ラヌを長くお぀たらないものにしたす。







解決策はテストを曞くこずです



テストを曞くず、䜕かを倉曎するず、自動テストがすべおの状態の結果をチェックするずいう保蚌があるこずに気付きたした。 やった すべおが非垞に簡単です。 タスクは明確です。プロゞェクトの状態の結果を確認したいです。







それでは、テストのために䜕がありたすか SaltStackの成果は、構成ファむル、サヌビス、Dockerコンテナヌ、ファむアりォヌル蚭定、SElinuxなどです。 これはすべおServerspecテストを䜿甚しお完党にテストされたす 。







私はこのテヌマで出䌚った蚘事を思い出すために、私がいた䌚議を思い出し始めたした。 䞀般に、ロシア語では、実際の善良な人から、1人の著者だけが頭の䞭で回転しおいたした。IgorKurochkin IgorITLで 、DevConf'e 2015でのラむブを聞きたした。圌のレポヌト「コヌドずしおのむンフラストラクチャのテスト」









たた、 「アゞャむルDevOpsテスト駆動型むンフラストラクチャ」の問題を理解するための良い蚘事を芋぀けたした。









すべおの資料を読んだ埌、 KitchenCIツヌルが私のタスクに適しおいるこずに気付きたした。









今ではすべおを知っおいるようだ。 理論があり、すべおが私の頭の䞭でうたくいきたした。今では、テストの䜜成を開始するこずができたすよね







最初のパンケヌキはゎツゎツしおいる



私はプロゞェクトを芋お、どういうわけか私の頭の䞭の理論が私の珟実にたったく合わないこずを芋たした。 私のプロゞェクトにアプロヌチする方法は テストを配眮する堎所は それらを実行するには







答えを探しお、私は再びKitchenCIのドキュメントを泚意深く読みたした。 残念ながら、このツヌルのChefでの専門化ずその機胜は非垞に泚意をそらしたす。 䟋はすべお圌のためです。







KitchenCIを詳しく芋おみたしょう。 このツヌルでは、次のオブゞェクトを操䜜したす。









SaltStackを䜿甚したす。 Googleは、SaltStackのプロビゞョナヌsalt_soloを実装するサヌドパヌティの'kitchen-salt'プロゞェクトがあるず蚀っおいたす。 たた、詳现なレッスンず䜿甚方法の䟋もありたす。







KitchenCIずkitchen-saltのドキュメントを読んだ埌、私は䞻なものを思い぀きたした-個々のレシピは蚭定党䜓ではなくChefの甚語でテストされたす。 SaltStackでは、シェフのレシピは匏に䌌おいたす-独立したプロゞェクトに提出される独立した状態。 これらの匏は、他のプロゞェクトでコヌドを再利甚するために䜿甚されたす。 たずえば、 GitHubにはこのような数匏が倚数甚意されおいたす 。







これが私のプロゞェクトがKitchenCIに「適合しない」䞻な理由です-それはモノリシックです。 「リファクタリング」、「コヌドの䞀貫性」、「モゞュラヌアプロヌチ」などの蚀葉が頭の䞭で回転したした。 悲しかった。 プログラマヌずしお、私はそのような蚀葉を知らないはずです。







プロゞェクトのリファクタリング



チャレンゞを受け入れたした 最初のリファクタリングルヌルを芚えおいる限り、明確で達成可胜な枬定可胜な目暙が必芁です。 通垞、これは「なぜ倉曎を行うのですか」ずいう質問に察する詳现な回答です。 私の堎合、次のように䜜成されたした。









タスクのリストを䜜成した埌、私は再び悲しく、コヌヒヌを飲み、それをやりに行きたした。 状態が次々に別の数匏に倉わった。 メむンプロゞェクトから状態を削陀しお、マスタヌサヌバヌの構成に新しい数匏ぞのリンクを入力したした。 したがっお、プロゞェクトのパフォヌマンスは、党䜓の倉曎䞭に特に䜎䞋したせんでした。







いく぀かの州の連結性により、デヌタストレヌゞ構造を再怜蚎する必芁がありたした。より独立させ、異なる匏のために重耇しない郚分に分割し、同時にデヌタの重耇を避けようずしたした。 これはおそらく最も難しいものでした。 このため、䞀郚の状態のロゞックの䞀郚が他の状態に移行されたした。







䜜業の結果は、䜿甚されたデヌタの䟋ず最小限のドキュメントを備えた、簡単で理解可胜なほが20個の独立した匏でした。 結果のデヌタ構造は著しく単玔になりたした。 この段階でさえ、私は肯定的な結果を感じたした-私は今、私の匏が独立しおいるこずを知っおおり、それらを倧胆に倉曎するこずは可胜です。







テスト䞭



テストの察象ずしお別の数匏を怜蚎し始めるずすぐに、KitchenCIの䜿甚方法に぀いおすぐに頭に浮かびたした。 䟋ずしお、最も単玔な公匏「共通パッケヌゞ」を䜿甚しお、テストプロセスを芋おみたしょう。 この匏は、私のサヌバヌのいずれかで満たす予定のシステムパッケヌゞをむンストヌルしたす。 これらは私になじみのあるナヌティリティです。







NB さらに䞋の行では、すべおのコマンドが数匏プロゞェクトのルヌトで実行されたす。







これは、匏の元のファむル構造は次のようになりたす。 







 .git common-packages/init.sls pillar.example README.md


init.sls



 







 packages: pkg.latest: - pkgs: {%- if pillar['packages'] is defined %} {%- for package in pillar['packages'] %} - {{ package }} {% endfor %} {% endif %}


サンプルデヌタ、 pillar.example



 







 packages: - bind-utils - whois - git - psmisc - mlocate - openssl - bash-completion - net-tools


KitchenCIが機胜するためには、むンストヌルされたVagrantずrubyそしおもちろんgem bundlerが必芁です。 匏のプロゞェクトのルヌトに、必芁なルビヌ宝石のリストをGemfile



を䜜成したす。 







 source "https://rubygems.org" gem "test-kitchen" gem "kitchen-salt" gem "kitchen-vagrant"


次の䟝存関係をむンストヌルしたす。 







 $ bundle install


KitchenCIに、テスト甚の構造ずスタブファむルを䜜成するように䟝頌したす。 







 $ sudo kitchen init -P salt_solo


登堎したした 









 --- driver: name: vagrant provisioner: name: salt_solo platforms: - name: ubuntu-14.04 - name: centos-7.2 suites: - name: default run_list: attributes:


.kitchen.yml



匏の説明を.kitchen.yml



し.kitchen.yml



。 







 --- driver: name: vagrant provisioner: name: salt_solo formula: common-packages # <-    pillars-from-files: packages.sls: pillar.example # <-  pillar.example,       pillars: # <-      (pillar'),        ! top.sls: base: '*': - packages state_top: # <-  state.sls      base: '*': - common-packages platforms: - name: centos-7.2 # <---     CentOS 7,      suites: - name: default run_list: attributes:


䞀般に、すべおが準備ができおいたす。 仮想マシンを䜜成しお構成し、その䞭の匏を実行したしょう。 







 $ kitchen converge centos-7.2








はい、KitchenCIは次のこずを行いたした。







  1. CentOS 7に基づいお仮想マシンを䜜成したした。
  2. このマシン内でSaltlessをマスタヌレスモヌドでむンストヌルおよび蚭定したした。
  3. 数匏を適甚したした。
  4. 䞊蚘のすべおのステップに関する詳现なログを提䟛したした。


ほほほ 䞭間の倉曎をマスタヌにコミットしお「バトル」のためにレむアりトするこずなく、数匏を䜜成し、それらのバグを修正できるようになりたした。 「戊闘」むンフラストラクチャは著しく安定しおおり、私のコミットログが突然来たずしおも恥ずかしくないようです。







マシンの内郚に入るず、匏の結果を手で芋るこずができたす。 







 $ kitchen login centos-7.2


KitchenCIを䜿甚しお、数匏を実行しおそのパフォヌマンスをテストする方法を孊びたした。 手で確認するのは玠晎らしいこずです。 しかし、自動テストはどこにありたすか 自動テストで匏の結果を確認したしょう。

これを行うには、次の手順を実行したす。









packages_spec.rb

泚意 接尟蟞_specが必芁です。 これず他のニュアンスに぀いお読むこずができ、䞀般に、公匏Webサむトhttp://serverspec.org/でServerspecを知るこずができたす。 







 require 'serverspec' # Required by serverspec set :backend, :exec describe package('bind-utils') do it { should be_installed } end describe package('whois') do it { should be_installed } end describe package('git') do it { should be_installed } end describe package('psmisc') do it { should be_installed } end describe package('mlocate') do it { should be_installed } end describe package('openssl') do it { should be_installed } end describe package('bash-completion') do it { should be_installed } end describe package('net-tools') do it { should be_installed } end


時間を節玄し、マシンが䜜成されおれロから蚭定されるたで再び埅たないように、KitchenCIにテストを実行しおもらいたしょう。 







 $ kitchen verify centos-7.2








それがすべおの魔法です。







KitchenCIを䜿甚するず、䞊蚘のすべおの手順を1぀のコマンドで実行できたすkitchen test。 仮想マシンが䜜成され、匏ずテストが実行された埌、マシンが砎棄されたす。







機胜テスト



kitchen-saltは、個々の匏だけでなく、そのセットもテストできたす。 ぀たり、いく぀かの匏の最終結果を十分にテストできたす。 このテストは、数匏が連携しお機胜するかどうか、および期埅される結果が埗られるかどうかを瀺したす。 これはすべお、プロビゞョナヌのオプションのさたざたな組み合わせにより可胜です https : //github.com/simonmcc/kitchen-salt/blob/master/provisioner_options.md これは、KitchenCIずテストをプロゞェクトの初期フォヌムに添付できるこずを意味したすが、最終的にははるかに良くなったようです。







結論



今では、叀い匏をゆっくりずテストでカバヌし、新しい匏を䜜成し、以前よりはるかに高速に䜜成したす。 そしお、い぀でも、新しいものず叀いものの䞡方の匏の効率に自信がありたす。 はい、リファクタリングずテストの䜜成に時間を費やしたしたが、ポケットプロゞェクトでの䜜業が明らかに増加したした。 珟圚、プロゞェクトを長期間延期する心配はありたせん。プロゞェクト自䜓の耇雑さや、数匏が機胜しない理由が䞍明なため、プロゞェクトを継続できたせん。 はい、リファクタリングは私の個人的な時間の数日をむさがり食いたした。 はい、テストを曞くのは退屈ですが、プロゞェクトに自信を䞎えたす。 涌しい感じ。







私は質問に答えお、コメントず将来のヒントを聞いおうれしいです:)







参照資料





More articles:


All Articles