サむオステクノロゞヌTech.Labのブログ - TECH PLAY

TECH PLAY

サむオステクノロゞヌTech.Lab

サむオステクノロゞヌTech.Lab の技術ブログ

å…š672ä»¶

こんな方ぞ特におすすめ 勀怠管理システムぞの申請、特に现かな䜜業時間の入力が面倒な方 タスクごずにどのくらいの時間がかかっおいるか、感芚でしか分からない方 簡単にPythonのアプリを開発したい方 抂芁 こんにちは。サむオステクノロゞヌのはらちゃんです今回4本目のブログ執筆です。 今回は私が䜜成したストップりォッチアプリの玹介ず、その開発過皋、そしお皆さんの勀怠管理や䜜業効率向䞊に圹立぀ヒントをお䌝えしたす。 なぜ自䜜ストップりォッチアプリが必芁だったのか 私の職堎では、勀怠報告で䜜業の皮類ごずに工数を確認する必芁がありたした。 「〇〇プロゞェクトの蚭蚈」「△△タスクのコヌディング」「定䟋䌚議」など、䜜業ごずに時間を枬りたい──。 そんな想いから自分で䜜っお自由にカスタムできるアプリを䜜ろうず考えたした。 簡単ストップりォッチの䜜り方 以䞋のような単玔な機胜をも぀アプリを䜜っおいこうず思いたす。 デスクトップに衚瀺されたす 機胜ずしおは䞊から ラベルに入力 タむマヌ衚瀺 開始、停止ボタンのクリック タむマヌ個数の増枛ボタンのクリック が行えたす。 前提条件 VSCodeのむンストヌル Pythonの開発環境 ステップホストOSの準備 たず、コンテナヌのGUIをPC本䜓の画面に映し出すための「Xサヌバヌ」ずいう゜フトをむンストヌルしたす。これは初回のみ必芁な䜜業です。 Xサヌバヌをむンストヌルする。 Windowsの堎合: VcXsrv をむンストヌルしお起動したす。 Macの堎合: XQuartz をむンストヌルしお起動したす。 Display settings: 「 Multiple windows 」を遞択しお「次ぞ」。 Client startup: 「 Start no client 」を遞択しお「次ぞ」。 Extra settings: 「Disable access control」 に 必ずチェック を入れお「次ぞ」。 「完了」をクリックしおVcXsrvを起動したす。 このような蚭定画面が起動したす。 ステップストップりォッチアプリの実装 このPythonコヌドをコピヌしおファむルに保存するだけですぐに動かすこずができたす。 stopwatch.py import tkinter as tk import time class StopwatchApp: def __init__(self, parent): # Frameを䜜成し、芪りィゞェット(parent)に配眮 self.frame = tk.Frame(parent) self.frame.pack(side=tk.LEFT, padx=15, pady=15) # --- ストップりォッチの状態を管理する倉数 --- self.running = False self.start_time = 0.0 self.elapsed_time = 0.0 # --- ラベル線集郚品 --- self.label_var = tk.StringVar() self.label_var.set("タむマヌ") self.label_entry = tk.Entry(self.frame, textvariable=self.label_var, font=("Arial", 10), justify="center", width=8) self.label_entry.pack(pady=(0,2)) # --- 画面の郚品りィゞェットを䜜成 --- self.time_label = tk.Label(self.frame, text="00:00", font=("Arial", 40, "bold")) self.time_label.pack(pady=4) self.toggle_button = tk.Button(self.frame, text="Start", width=13, command=self.toggle) self.toggle_button.pack(pady=4) self.update() def toggle(self): """ボタンが抌されたずきの凊理""" if self.running: # ストップ凊理 self.running = False self.toggle_button.config(text="Start") else: # スタヌト凊理 self.running = True self.toggle_button.config(text="Stop") self.start_time = time.time() - self.elapsed_time def update(self): """時間を蚈算しお衚瀺を曎新する凊理""" if self.running: self.elapsed_time = time.time() - self.start_time self._display_time() self.frame.after(10, self.update) def _display_time(self): """経過時間を芋やすい圢匏に倉換しおラベルに衚瀺時間:分""" hours = int(self.elapsed_time // 3600) minutes = int((self.elapsed_time % 3600) // 60) time_string = f"{hours:02}:{minutes:02}" self.time_label.config(text=time_string) # --- アプリケヌションの実行 --- class StopwatchManager: def __init__(self, root): self.root = root self.stopwatches = [] self.frame = tk.Frame(root) self.frame.pack() # ボタン配眮 btn_frame = tk.Frame(root) btn_frame.pack(pady=4) self.add_btn = tk.Button(btn_frame, text="○", font=("Arial", 12), width=4, command=self.add_stopwatch) self.add_btn.pack(side=tk.LEFT, padx=4) self.remove_btn = tk.Button(btn_frame, text="×", font=("Arial", 12), width=4, command=self.remove_stopwatch) self.remove_btn.pack(side=tk.LEFT, padx=4) # 初期2぀ self.add_stopwatch() self.add_stopwatch() def add_stopwatch(self): sw = StopwatchApp(self.frame) self.stopwatches.append(sw) self.update_window_size() def remove_stopwatch(self): if self.stopwatches: sw = self.stopwatches.pop() sw.frame.destroy() self.update_window_size() def update_window_size(self): width = max(205 * len(self.stopwatches), 205) self.root.geometry(f"{width}x200") # --- アプリケヌションの実行 --- if __name__ == "__main__": root = tk.Tk() root.title("StopWatch") root.resizable(False, False) root.attributes("-topmost", True) manager = StopwatchManager(root) # 初期りィンドりサむズ root.geometry("410x200") root.mainloop() ステップ実行 タヌミナルで以䞋のコマンドを入力するずアプリが起動したす。 bash python3 stopwatch.py 実行できないずきは  解決策ラむブラリのダりンロヌドする Pythonには「 Tkinter 」ずいうGUI画面付きアプリを䜜るためのラむブラリが暙準で付属しおいるため、远加のむンストヌルなしですぐに開発を始められたす。 しかし、Linuxで操䜜しおいる堎合は手動でのダりンロヌドが必芁です。 bash sudo apt update sudo apt install python3 python3-tk 解決策ファむアりォヌルの蚭定を確認する VcXsrvを初めお起動したずき、Windows Defenderファむアりォヌルが譊告画面を衚瀺したはずです。 ここで「 アクセスを蚱可する 」を遞択しないず、通信がブロックされおしたいたす。 Windowsの怜玢バヌで「 ファむアりォヌル 」ず怜玢し、「 Windows Defender ファむアりォヌルによるアプリの蚱可 」を開きたす。 「蚭定の倉曎」をクリックし、「別のアプリの蚱可」をクリックしたす。 「参照」からVcXsrvの実行ファむル通垞は C:\Program Files\VcXsrv\vcxsrv.exe を遞択しお远加したす。 䞀芧に远加された「vcxsrv」の「 プラむベヌト 」ず「 パブリック 」の䞡方のチェックボックスをオンにしお「OK」をクリックしたす。 たずめ 今回は、ストップりォッチのアプリ開発を通しお、PythonずTkinterを䜿えば、日垞のちょっずした䞍䟿を解消するアプリを自䜜できる楜しさを孊んでいきたした。 Github でも、私の開発コヌドを公開しおいるので、自由にコヌドを曞き替えお䜿っおみおくださいね。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 1人がこの投皿は圹に立ったず蚀っおいたす。 The post 勀怠管理の仕方Tkinterで自䜜ストップりォッチ first appeared on SIOS Tech. Lab .
OSSよろずサポヌト担圓の神です。 今回は Dify に぀いお゜ヌスコヌド、ドキュメント、怜蚌を行った際の知芋に぀いおすでに公開されおいる匊瀟の蚘事ず重ならない範囲で軜くたずめおいきたす。 Dify に぀いお Difyの抂芁や党䜓像に぀いおは、 匊瀟゚ンゞニアの解説蚘事 がありたすので、ご参照ください。 Dify の呌称に぀いお 䞊蚘蚘事に掲茉されおいない䞀口メモずしお Dify の読み方に぀いお説明したす。 Dify のこずを筆者は最近たで「ディファむ」ず呌んでいたしたが、正匏な呌称は「ディフィ」ずなっおおりたす。 参考 https://xtech.nikkei.com/atcl/nxt/column/18/03236/061200004/ Dify + Amazon Bedrock に぀いお 匊瀟では AzureAI を利甚した Dify の蚘事が数倚く公開されおいたすが、今回は AWS の Amazon Bedrock ずいう LLM で怜蚌したした。 Dify で Amazon Bedrock を蚭定するやり方に぀いおも、 匊瀟゚ンゞニアの解説蚘事 をご確認ください。 匊瀟で公開しおいるチャット bot やワヌクフロヌ、 RAG を䜜成しおみたしたが、問題なく動䜜したした。 アプリケヌションを䜜成するうえでの泚意点 Amazon Bedrock 䞊で有効化したモデル以倖を遞択した堎合、LLM ノヌドにおいお゚ラヌが出力されおしたうため有効化したモデルを正しく遞択する必芁があるこずにご泚意ください。 Dify の゚ラヌ凊理 Dify の各ノヌドで出力される゚ラヌに぀いおたずめおいきたす。 参考 ゚ラヌ凊理 – ゚ラヌタむプ抂芁 チャットフロヌワヌクフロヌ システム゚ラヌ サヌビスが正しく起動しおいない、ネットワヌク問題など 操䜜゚ラヌ ノヌドの蚭定や操䜜に倱敗した際の゚ラヌ コヌドノヌド コヌド゚ラヌCodeNodeError 開発者の蚭定したコヌド内に゚ラヌがある堎合に発生する゚ラヌ サンドボックスのネットワヌク問題System Error ネットワヌクのトラフィックや 接続問題によっお発生する゚ラヌ ネスト制限゚ラヌDepthLimitError ノヌドのネスト構造が 5局以䞊の堎合に発生する゚ラヌ 出力怜蚌゚ラヌOutputValidatioのnError 出力倉数の型が䞀臎しない堎合に発生する゚ラヌ LLM ノヌド 倉数が芋぀からないVariableNotFoundError 指定された倉数が芋぀からない堎合に発生する゚ラヌ コンテキスト構造の無効 (InvalidContextStructureError)   䞍正なデヌタ構造 (文字列以倖) を受け取った堎合に発生する゚ラヌ 無効な倉数タむプInvalidVariableTypeError システムプロンプトの圢匏が䞀般的なテキストや Jinja syntax でない堎合に発生する゚ラヌ モデルが存圚しないModelNotExistError LLM ノヌドにモデルが蚭定されおいない堎合に発生する゚ラヌ  LLMの認蚌が必芁LLMModeRequiredError 遞択されたモデルに API キヌが蚭定されおいない堎合に発生する゚ラヌ プロンプトが芋぀からないNoPromptFoundError LLM ノヌドのプロンプトが空の堎合に発生する゚ラヌ HTTPノヌド 認蚌蚭定゚ラヌAuthorizationConfigError 認蚌情報が蚭定されおいない堎合に発生する゚ラヌ ファむル取埗゚ラヌFileFetchError ファむル倉数が取埗できない堎合に発生する゚ラヌ 䞍正なHTTPリク゚ストメ゜ッドInvalidHttpMethodError リク゚ストメ゜ッドが GET、HEAD、POST、PUT、PATCH、DELETE のいずれにも該圓しない堎合に発生する゚ラヌ レスポンスサむズ超過ResponseSizeError HTTPレスポンスコヌド゚ラヌHTTPResponseCodeError レスポンスコヌドが 200系以倖䟋400、404、500などの堎合に発生する゚ラヌ ※䟋倖凊理が有効であれば、これらのステヌタスコヌドによる゚ラヌが報告される ツヌルノヌド ツヌル実行゚ラヌToolNodeError ツヌル自䜓の実行に問題があった堎合に発生する゚ラヌ ツヌルパラメヌタ゚ラヌToolParameterError ツヌルノヌドが芁求するパラメヌタず異なる倀が入力された堎合に発生する゚ラヌ ツヌルファむル凊理゚ラヌToolFileError ツヌルノヌドの凊理に必芁なファむルが芋぀からない堎合に発生する゚ラヌ ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Dify のチュヌトリアルを終えおの知芋 (出力された゚ラヌなど) first appeared on SIOS Tech. Lab .
プリザンタヌ® Pleasanter® は株匏䌚瀟むンプリムの登録商暙です。 はじめに 今回は、9/19金に名叀屋でオフラむン開催された「 プリザンタヌハンズオンセミナヌ 」に参加しおたいりたしたので、そのレポヌトをさせおいただきたす。 本セミナヌは、特にプリザンタヌを䜿ったこずがない方や、䜿い始めたばかりの初心者の方向けの内容ずしお構成されおおり、その基本操䜜を実際に手を動かしながら䜓隓できる貎重な機䌚でした。 アむキャッチは圓日いただいたアンブレラマヌカヌ、クリアファむル、ステッカヌです。 プリザンタヌ® Pleasanter® は株匏䌚瀟むンプリムの登録商暙です。 むベントの抂芁 本セミナヌは名叀屋におオフラむン圢匏で開催されたした。 開催日時2025幎9月19日(金) 16:30〜18:00 䌚堎愛知県名叀屋垂䞭村区倪門1䞁目20-13 秀幞ビル 階 601号 (オフラむン開催) 䞻催株匏䌚瀟むンプリム 共催プレシャスト株匏䌚瀟 費甚無料 定員15名先着順 60日間無料で党機胜を詊せるデモ環境 を䜿っおのハンズオンセミナヌでした。 Pleasanterプリザンタヌずは Pleasanterはノヌコヌドで業務アプリを䜜成できるプラットフォヌムです。Excelのような芪しみやすい操䜜感で、プログラミングの知識がなくおも簡単に業務アプリを䜜成するこずができたす。顧客管理やプロゞェクト管理、日報の管理などの散圚しがちな情報を䞀元化しお管理ができるこずが倧きな特長です。 システム導入においおも柔軟性が高く、クラりドでの利甚はもちろん、むンタヌネットに接続できないオンプレミス環境ぞの導入にも察応しおいたす。 Pleasanterの特城的な機胜 Pleasanterは、業務効率化ず情報セキュリティを䞡立させる倚様な機胜を備えおいたす。 進捗の可芖化 暙準機胜ずしおガントチャヌトやカンバン機胜なども搭茉されおおり、業務の進捗状況の可芖化、チヌム内での情報共有を効率化するこずができたす。 豊富なテンプレヌト 顧客情報、FAQ、資産管理など、幅広い業務に察応した業務アプリが倚数甚意されおいたす。 通知・リマむンド アプリケヌション内の曎新情報をメヌル通知したり、タスクの期日前にリマむンド通知を送る蚭定も可胜です。 アクセス制埡 個人情報などの機密性の高い情報を、特定の担圓者のみが閲芧・線集できるようにアクセス制埡が可胜です。 プリザンタヌでできるこず 成果物の玹介 今回のハンズオンでは案件管理で甚いるアプリをプリザンタヌで䜜成したした。 ハンズオンでの成果物 今回䞻に䜜成したのは「フォルダ」ず「テヌブル」です。 「フォルダ」は皆さんが普段PCで䜿っおいるフォルダをむメヌゞしおいただけるずわかりやすいず思いたす。Pleasanterではテヌブルや他のフォルダを栌玍しツリヌ構造でデヌタを管理したす。 このフォルダの䞭にテヌブルを䜜成するこずができたす。テヌブルは2皮類あり、タスク管理などの期限の管理を行う「期限付きテヌブル」ず、資産管理などの情報の管理に䜿甚する「蚘録テヌブル」の二぀がありたす。テヌブルの䞭には「レコヌド」を登録するこずができ、各タスクや蚘録の内容はこのレコヌドを登録するこずで管理されたす。   今回のハンズオンでは「営業郚」ずいう名前のフォルダを䜜成し、その盎䞋に「商談」ずいう期限付きテヌブルず「顧客マスタ」ずいう蚘録テヌブルを䜜成したした。䜜成した各テヌブル内にレコヌドを䜜成し、商談情報や顧客情報を管理できるようにしたした。 さらに、実践的な機胜ずしお、レコヌドぞの画像の添付、テヌブルに芪子関係を持たせおのデヌタ連携、集蚈やフィルタの蚭定ずいった、実際の業務で圹立぀操䜜も実斜したした。 参加しおの感想ず所感 䜿甚した感想ずしおは、フォルダやテヌブルの䜜成、テヌブルの管理などの操䜜が盎感的に分かりやすく、技術的な知識がない方でも操䜜しやすいず感じたした。 個人的に䟿利だず感じたのは、テヌブルの蚭蚈やレコヌドの内容を倉曎した際に曎新を忘れるずダむアログが出るため、曎新忘れがなく䟿利だず感じたした。 セミナヌ党䜓を通しお、進行のテンポが適正で、戞惑うこずなく自分のペヌスで手を動かしやすかった点も、䞻催者様のご配慮を感じるポむントでした。 プリザンタヌのセミナヌは、今回の名叀屋開催のように各地で随時開催されおおりたす。ご興味をお持ちの方は、ぜひ参加されおみおはいかがでしょうか。 セミナヌ情報など 参考文献 Pleasanter Pleasanterの掻甚シヌン Pleasanter導入事䟋 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 【セミナヌレポヌト】プリザンタヌハンズオンセミナヌ名叀屋に参加しおきたした first appeared on SIOS Tech. Lab .
史䞊最倧玚のnpm自己増殖型ワヌム攻撃「Shai-Hulud」ずその防埡策 2025幎9月15日、npmリポゞトリに察する史䞊最倧玚の゜フトりェアサプラむチェヌン攻撃「Shai-Hulud」が発芋されたした。この攻撃は、わずか1週間で20皮類以䞊の悪意あるOSSパッケヌゞを利甚し、200䞇回以䞊ダりンロヌドされた倧芏暡なものです。特にフィンテック䌁業コむン取匕所、銀行、蚌刞などが攻撃の察象ずされるこずが倚いずされおいたす。 Shai-Huludは、埓来の攻撃ずは異なり、新しい自己増殖型マルりェアワヌムずしお自己拡散を続けたす。攻撃は倚段階で実行され、たずフィッシングによっお開発者のGitHubやnpmトヌクンなどの認蚌情報を盗みたす。開発者が感染パッケヌゞをむンストヌルし`postinstall`スクリプトが実行されるず、悪意のあるコヌドが泚入されたす。 このコヌドは、環境内の機密デヌタGitHubのPAT、SSHキヌ、AWS、GCP、Azureなどのクラりドプロバむダヌのキヌを培底的にスキャンクレデンシャルハヌベスティングしたす。盗たれたデヌタは耇数回゚ンコヌドされ、「Shai-Hulud」ずいう名前のパブリックGitHubリポゞトリなどに流出したす。 最も危険な特城は、ワヌムの拡散メカニズムです。有効なnpmトヌクンを発芋するず、それを利甚しおメンテナが管理する他のパッケヌゞの悪意あるバヌゞョンを公開し、感染を゚コシステム党䜓に広げる自己再生的なサむクルを生み出したす。これは、npm゚コシステムにおける最初の成功した自己増殖型ワヌムの䞀぀であり、極めお深刻な脅嚁をもたらしおいたす。 コミュニティベヌスのOSSは、その公開性や耇雑な䟝存関係、セキュリティテストの䞍十分さ、コミュニティ内の信頌の悪甚などから、サむバヌ攻撃の栌奜の暙的ずなっおいたす。 今回の事件では、倚くのJFrogナヌザヌ䌁業がこのリスクを防げたず報告されおいたす。JFrog Platformは、゜フトりェアサプラむチェヌンのセキュリティガバナンスを党䜓的に守る統合プラットフォヌムであり、以䞋の䞻芁な機胜で防埡策を提䟛したす。 1. Curation機胜: 悪意のあるパッケヌゞがサプラむチェヌンに入る前にダりンロヌドを阻止する即時のガバナンスを提䟛したす。 2. JFrog Xray: 珟圚の開発環境および本番環境のパッケヌゞをリアルタむムスキャンし、「悪意床スコア」を付䞎しお早期に脅嚁を発芋・察策したす。 3. Artifactoryのリモヌトリポゞトリ機胜: 倖郚パッケヌゞリポゞトリからのキャッシュを管理し、悪意あるアヌティファクトの䟵入を防ぎたす。 もし圱響を受けたパッケヌゞをむンストヌルしおいた堎合、GitHub、NPM、AWS、GCP、Azureなどで䜿甚しおいたアクセストヌクンを盎ちに回転させるこずが必須です。JFrogはこの脅嚁に察する研究を継続しおいたす。 本蚘事の詳现は こちら からご確認ください ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 泚意喚起史䞊最倧なNpm゜フトり゚アサプラむチェヌン攻撃Shai-Hulud first appeared on SIOS Tech. Lab .
ここでは、連茉圢匏で公開しおきた「Git & GitLab入門」シリヌズの蚘事ぞのリンクずずもに、各回の抂芁を敎理したす。 Gitの基本ずGitLab / GitHubに぀いお バヌゞョン管理の基盀ずなるGitの基本抂念リポゞトリ、コミットなどを解説し、そのツヌルであるGitず、プロゞェクトをホストするGitLab/GitHubずの関係性を敎理した入門連茉の第1回です。 Git & GitLab 入門 (1) Git マスタヌぞの道「Git の基本ず GitLab/GitHub」 Git操䜜入門 GitずVS Codeのむンストヌルやナヌザヌ蚭定ずいった環境構築から、ロヌカルリポゞトリ䞊での倉曎・ステヌゞング・コミットずいうバヌゞョン管理の初歩的な操䜜手順を解説しおいたす。 Git & GitLab 入門 (2) Git マスタヌぞの道「Git操䜜入門」 Git操䜜チヌム利甚コマンドや ロヌルバック チヌム開発で必芁ずなる履歎衚瀺git logや差分確認git diff、タグ付けgit tag、バヌゞョン管理察象倖の蚭定.gitignoreずいった操䜜ず、状況に応じお䜿い分ける必芁があるコミットを取り消すコマンドgit revert、git reset、git restoreに぀いお解説しおいたす。 Git & GitLab 入門 (3) Git マスタヌぞの道「Git操䜜チヌム利甚コマンドや ロヌルバック」 リモヌトリポゞトリずロヌカルリポゞトリ リモヌトリポゞトリの圹割を解説し、SSHキヌの登録、プロゞェクトの䜜成、クロヌン、そしおロヌカルの倉曎をリモヌトぞ反映させるadd/commit/pushずいったリモヌトリポゞトリずロヌカルリポゞトリの連携操䜜を解説しおいたす。 Git & GitLab 入門 (4) Git マスタヌぞの道「リモヌトリポゞトリずロヌカルリポゞトリ」 Git のブランチに぀いお Gitのブランチの基本抂念ず、Git FlowやGitHub Flowなどの䞻芁なブランチ戊略を解説し、チヌム開発におけるマヌゞリク゚ストプルリク゚ストの䜜成からコンフリクトの発生ず手動による解消手順たでを解説しおいたす。 Git & GitLab 入門 (5) Git マスタヌぞの道「Git のブランチに぀いお」 GitLabの画面説明ずよく利甚される機胜説明 GitLabが提䟛する「プロゞェクト」、CI/CD、セキュリティ機胜、Issue管理やマヌゞリク゚ストずいったDevSecOpsラむフサむクル党䜓をカバヌする統合プラットフォヌムずしおの䞻芁な機胜を、倖郚ツヌルずの連携を重芖するGitHubずの違いを亀えながら解説しおいたす。 Git & GitLab 入門 (6) Git マスタヌぞの道「GitLabの画面説明ずよく利甚される機胜説明」 GitLabのプロゞェクトに぀いお GitLabにおけるグルヌプずプロゞェクトの関係や、リポゞトリずの違いを解説しおいたす。たた、マヌゞリク゚ストやCI/CDを含むプロゞェクトの統合的な機胜を説明し、ナヌザヌ招埅や保護ブランチ、Wikiの蚭定ずいった開発を始めるための具䜓的な初期準備手順を解説しおいたす。 Git & GitLab 入門 (7) Git マスタヌぞの道「GitLabのプロゞェクトに぀いお」 GitLabのCICD蚭定 継続的むンテグレヌション・継続的デリバリヌCI/CDの抂芁を解説し、Kubernetes䞊にGitLab Runnerをセットアップしお連携させた䞊で、.gitlab-ci.ymlを甚いおコンテナむメヌゞのビルド、プッシュ、デプロむメントたでを䞀貫しお自動化するパむプラむンの構築手順を解説しおいたす。 Git & GitLab 入門 (8) Git マスタヌぞの道「GitLabのCICD蚭定」 コヌドレビュヌの進め方 GitLabのマヌゞリク゚ストMRをコヌドレビュヌの堎ずしお掻甚する方法を解説しおおり、レビュアヌずレビュヌむ双方の芖点から、レビュヌを円滑に進めるための具䜓的な手順MR蚭定、コメント、承認、提案の適甚を解説しおいたす。 Git & GitLab 入門 (9) Git マスタヌぞの道「コヌドレビュヌの進め方」 GitLabでDevSecOps 開発スピヌドず安党性を䞡立する「DevSecOps」の抂念ず、GitLabがCI/CDパむプラむンぞのセキュリティスキャン統合を通じおこれを実珟し、Hilti瀟やCarfax瀟などの具䜓的な䌁業事䟋における開発効率化やセキュリティ向䞊ずいった導入成果を解説しおいたす。 Git & GitLab 入門 (10) Git マスタヌぞの道「GitLabでDevSecOps」 この連茉を通じお、Git/GitLabを利甚した個人・チヌム開発のプロセスを䜓系的に理解するこずができたす。Gitの基本操䜜はもちろん、CI/CDやDevSecOps機胜を組み蟌んだGitLabの基瀎を孊ぶこずができたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Git & GitLab 入門 Git マスタヌぞの道「たずめ」 first appeared on SIOS Tech. Lab .
はじめに 昚今、生成AIが流行っおいるのは蚀うたでもありたせん。ChatGPTから始たり、そしおRAGRetrieval Augmented Generationず呌ばれる技術が泚目され、さらにAI゚ヌゞェントなんおいうのも出おきおいたす。そしお、今、最も熱いのはMCP(Model Context Protocol)でしょう。 今回は、そんなMCPのテクノロゞヌずMoodle(オヌプン゜ヌスの孊習管理システム)を組み合わせたMCPサヌバヌを䜜成したしたので、その玹介をしたいず思いたす。以䞋のGitリポゞトリにお゜ヌスコヌドを公開しおいたす。 https://github.com/ntakei-sti/moodle-mcp-server このMCPサヌバヌは、勉孊に励む孊生を優しく支えるAIツヌルです。 ざっくりいっおしたうず、䟋えば䞋図のようにチャット圢匏のアプリにこのMCPサヌバヌを組み蟌むこずで、孊生がチャット圢匏で質問した内容に応じお、Moodleの情報を取埗しお、回答するこずができたす。 䟋えば、このチャットみたいに、ちょっず匱気な発蚀をするず、過去の成瞟を鑑みお、オススメの教材を提案しお励たしおくれたり、締切間近の宿題を忘れないように教えおくれたりしたす。 MCPサヌバヌずは MCPずは、Model Context Protocolの略で、今流行りのAI゚ヌゞェントに簡単に機胜を远加するためのプロトコルです。 AI゚ヌゞェントに関する詳しい説明は以䞋の蚘事を参考にしおください。 https://tech-lab.sios.jp/archives/42867 そしお、このMCPずいうプロコトルに準拠しお䜜成されたサヌバヌがMCPサヌバヌです。 では、このMCPサヌバヌの機胜を理解するために、「MCPがない䞖界」ず「MCPがある䞖界」を比范しおみたしょう。 MCPがない䞖界 MCPがない䞖界では、他のAI゚ヌゞェントAでずおも圹立぀機胜を䜿っおいたずしお、それをいざAI゚ヌゞェントBで䜿おうずした堎合、AI゚ヌゞェントB向けにその機胜を実装し盎す必芁がありたす。 ずいうのは、今たではLLMアプリ(DifyやClaudeなど)はそれぞれ独自の実装方匏を持っおおり、たたAI゚ヌゞェントが䜿うツヌルもそれぞれ独自の実装方匏をもっおおり、それぞれの実装方匏に合わせお、ツヌルの方を改修する必芁がありたした。 䟋えばAI゚ヌゞェントAではクラりドストレヌゞにアクセスしお、ファむルの䞀芧や䞭身を取埗する機胜があったずしおも、AI゚ヌゞェントBではそのクラりドストレヌゞにアクセスする方法が異なっおいる堎合、AI゚ヌゞェントB向けにクラりドストレヌゞにアクセスする機胜を実装し盎す必芁がありたす。 MCPがある䞖界 MCPがある䞖界では、AI゚ヌゞェントAで実装した機胜をそのたたAI゚ヌゞェントBでも利甚するこずができたす。なぜなら、MCPに準拠したむンタヌフェヌスを通じお、異なるAI゚ヌゞェント間で機胜を共有できるからです。 ここでは、「MCPサヌバヌがない䞖界」で「ツヌル」ず蚀われおいたものは「MCPサヌバヌ」ず呌ばれるようになりたした。圓然「サヌバヌ」ず呌ばれるくらいなので、それにラクセスするクラむアントである「MCPクラむアント」も必芁になりたす。 MCPクラむントずMCPサヌバヌを甚意し、その間の通信をMCPに準拠したものにしお、MCPサヌバヌ偎ではむンタヌネットやクラりドストレヌゞなど各皮リ゜ヌスにアクセスしお、MCPクラむアントに結果を返すようにしたす。 このようにしお、MCPサヌバヌを甚意するこずで、異なるAI゚ヌゞェント間で機胜を共有できるようになりたす。 今回の蚘事では、MCPの話が本筋ではないので、MCPに関する詳しい説明は割愛したす。MCPに関する詳しい説明は以䞋のYouTubeを参考にしおください。 https://www.youtube.com/live/f7x6flxAfak?si=XDNt7xYWWpaZVHkP Moodleずは Moodleムヌドルは、孊校や䌁業の孊習をオンラむンで運営するための「孊習管理システムLMS」です。オヌプン゜ヌスで無償利甚でき、ブラりザさえあれば受講から課題提出、採点、成瞟管理たで䞀通り行えたす。 䞻な登堎人物は管理者・教垫・孊習者の3぀になりたす。 管理者はサむトやナヌザヌを統括したり、Moodleの基本的な蚭定(暩限管理やメヌルサヌバヌなどの蚭定)を行いたす。 教垫はコヌス科目を䜜っお教材やテストを配眮し、孊生ぞの各皮䌝達、課題の提出管理や採点を行いたす。 孊習者は孊生のこずで、教垫からの指瀺に基づいお、課題などの受講・提出・確認を行いたす。 ざっくりこんな流れ このMCPサヌバヌの凊理の流れをざっくり説明したす。 ① 認蚌 ナヌザヌがIdPで認蚌したす。このIdPはKeyCloakやOktaなどのOpenID Connectに察応したものの利甚を想定しおいたす。 ② 質問 LLMアプリDifyやClaudeなどで質問したす。このずき①で取埗したIDトヌクンをHTTPヘッダヌ Authorization にセットしお、LLMアプリに枡したす。 ③ ツヌル取埗 MCPのプロトコルに則り、MCPクラむアントからMCPサヌバヌに察しお、利甚可胜なツヌルの䞀芧を取埗したす。 ④ ツヌル遞定 ③で取埗したツヌル䞀芧をAzure OpenAI ServiceなどのLLMに枡し、質問に察しお適切なツヌルを遞定したす。 â‘€ ツヌル返华 LLMから返华されたツヌルをLLMアプリが受け取りたす。 ⑥ ツヌル呌び出し LLMアプリがMCPクラむアントを通じお、MCPサヌバヌに察しおツヌルを呌び出したす。このずき、②で取埗したIDトヌクンをもずに、MCPサヌバヌに察しお、ナヌザヌ情報を枡したす。 ⑩ API実行 MCPサヌバヌはナヌザヌ情報やコヌス情報などをもずに、MoodleのREST APIを呌び出しお、必芁な情報を取埗したす。 MCPサヌバヌの基本機胜 今回䜜成したMCPサヌバヌは、MoodleのREST APIを利甚しお、Moodleの情報を取埗する機胜を持っおおりたす。具䜓的には以䞋の機胜を提䟛しおいたす。 ■  成瞟が䜎い課題のコヌスに関するファむル䞀芧を取埗 ナヌザヌの履修コヌスのうち、成瞟の回答率が 䞀定倀を䞋回るコヌスに添付されたファむルを列挙したす。 ■ 未提出の課題の取埗 ナヌザヌの未提出ず刀定される課題を怜玢しお返したす。 ■ ナヌザヌが履修しおいるコヌス䞀芧の取埗 ナヌザヌが履修しおいるコヌスの䞀芧を取埗したす。 ■ コヌス怜玢 党コヌスからキヌワヌド怜玢を行いたす。衚瀺名displaynameや抂芁summaryも出力に含めたす。 ■ 締め切り間近の課題取埗 ナヌザヌの未提出ず刀定される課題のうち、締め切りが近いものを怜玢しお返したす。 MCPサヌバヌの詳现機胜 MCPサヌバヌのより詳现な機胜に぀いお説明したす。 get_resources_under_specific_grade ナヌザヌの履修コヌスのうち、成瞟の回答率が環境倉数 COMPLETION_THRESHOLD を䞋回るコヌスに添付されたファむルを列挙したす。 ナヌザヌ名は REMOTE_USER 環境倉数、たたは X-Remote-User ヘッダヌ、あるいは ID トヌクンで指定したす。 get_my_unsubmitted_assignments ナヌザヌの未提出ず刀定される課題を怜玢しお返したす。課題の提出刀定には 環境倉数 mod_assign_get_submission_status を優先利甚し、 ナヌザヌ名は REMOTE_USER 環境倉数、たたは X-Remote-User ヘッダヌ、あるいは ID トヌクンで指定したす。 get_my_enrolled_courses ナヌザヌが履修しおいるコヌス䞀芧を返したす。 ナヌザヌ名は REMOTE_USER 環境倉数、たたは X-Remote-User ヘッダヌ、あるいは ID トヌクンで指定したす。 find_my_courses_by_keyword(keyword) core_course_search_courses を利甚しお党コヌスからキヌワヌド怜玢を行いたす。衚瀺名displaynameや抂芁summaryも出力に含めたす。 get_upcoming_deadlines 環境倉数 UPCOMING_DEADLINES_DAYS 日以内に締切が来る課題を集玄しお返したす。 mod_assign_get_assignments を優先しお䜿い、 フォヌルバックで gradereport から締切を探したす。 ナヌザヌ名は REMOTE_USER 環境倉数、たたは X-Remote-User ヘッダヌ、あるいは ID トヌクンで指定したす。 システム構成 このMCPサヌバヌで構成するこずの出来るシステム構成の䟋をいく぀か玹介したす。 信頌できるネットワヌク内にMCPクラむントずMCPサヌバヌがある堎合 この堎合、MCPクラむアントずMCPサヌバヌは同じ信頌できるネットワヌク内にあるため、぀たり、このMCPサヌバヌにアクセスできるのは、LLMアプリのみのため、HTTPヘッダヌ X-Remote-User を䜿っおナヌザヌ名を枡すこずができたす。 埌述するIDトヌクンを䜿う堎合ず比べお、LLMアプリの実装が簡単になりたす。 信頌できるネットワヌク倖にMCPクラむントずMCPサヌバヌがある堎合 この堎合、MCPクラむアントずMCPサヌバヌは同じ信頌できるネットワヌク内にはないため、぀たり、このMCPサヌバヌにアクセスできるのは、䞍特定倚数のナヌザヌが利甚する可胜性があるため、HTTPヘッダヌ X-Remote-User を䜿っおナヌザヌ名を枡すこずはできたせん。 この堎合、IDトヌクンを䜿っおナヌザヌ名を枡す必芁がありたす。MCPサヌバヌはIDトヌクンを怜蚌し、ナヌザヌ名を取埗したす。 MCPクラむアントずMCPサヌバヌが同じアプリケヌションサヌバヌ䞊にある堎合 この堎合、MCPクラむアントずMCPサヌバヌは同じアプリケヌションサヌバヌ䞊にあるため、通信方匏ずしおSTDIOを甚いたす。環境倉数 REMOTE_USER を䜿っおナヌザヌ名を枡すこずができたす。 起動方法 このMCPサヌバヌはPythonで䜜成されおおり、 pip コマンドでむンストヌルしお利甚したす。 事前準備 以䞋のコマンドを実行しお、必芁なラむブラリをむンストヌルしおください。 $ git clone https://hogehoge.git $ cd moodle-mcp-server $ ppip install -r requirements.txt 環境倉数の蚭定 このプロゞェクトは環境倉数で各皮挙動を制埡したす。 .env  ファむルを䜜成するか、シェルの環境倉数ずしお蚭定しおください。通信方匏MCP_TRANSPORTにより必芁な環境倉数が異なりたす。 共通 MOODLE_API_URL (必須): Moodle サむトのベヌス URL䟋: < https://moodle.example.com > MOODLE_WSTOKEN (必須): Moodle の Webservice トヌクン COMPLETION_THRESHOLD (任意): 成瞟の「回答率」閟倀デフォルト 80 UPCOMING_DEADLINES_DAYS (任意): get_upcoming_deadlines が参照する日数りィンドりデフォルト 7 MCP_TRANSPORT (任意): 通信方匏。 sse 既定たたは stdio SSE モヌドMCP_TRANSPORT=sseもしくはStreamable HTTPモヌドMCP_TRANSPORT=streamable-httpで䞻に䜿甚する倉数 MCP_SERVER_HOST (任意): サヌバのバむンドアドレスデフォルト 0.0.0.0  MCP_SERVER_PORT (任意): サヌバのポヌトデフォルト 8000  ACCEPT_REMOTE_USER_HEADERS (任意): true で X-Remote-User ヘッダを優先デフォルト true  Bearer トヌクン怜蚌を䜿う堎合に必芁: OIDC_METADATA_URL : OpenID Provider のメタデヌタ URL必須 OIDC_AUDIENCE (任意): 期埅する audience OIDC_USERNAME_CLAIM (任意): ナヌザヌ識別子に䜿うクレヌム名デフォルト sub  STDIO モヌドMCP_TRANSPORT=stdioで䜿甚する倉数 REMOTE_USER (必須): 実行䞭プロセスで扱う Moodle の username 泚意: ACCEPT_REMOTE_USER_HEADERS を有効にする堎合、 リモヌトヘッダは信頌できるプロキシからのみ枡す  ようにしおください。 䟋: `.env` ファむルテンプレヌトSSEもしくはStreamable HTTP MOODLE_API_URL=https://moodle.example.com MOODLE_WSTOKEN=your_moodle_ws_token COMPLETION_THRESHOLD=80 OIDC_METADATA_URL=https://idp.example.com/.well-known/openid-configuration OIDC_AUDIENCE=your-client-id OIDC_USERNAME_CLAIM=preferred_username ACCEPT_REMOTE_USER_HEADERS=true UPCOMING_DEADLINES_DAYS=7 MCP_TRANSPORT=sse MCP_SERVER_HOST=0.0.0.0 MCP_SERVER_PORT=8000 䟋: `.env` ファむルテンプレヌトSTDIO MOODLE_API_URL=https://moodle.example.com MOODLE_WSTOKEN=your_moodle_ws_token REMOTE_USER=your-username MCP_TRANSPORT=stdio 起動 以䞋のコマンドを実行しお、MCPサヌバヌを起動したす。 $ python moodle_mcpserver.py 動䜜確認 MCP Inspectorずいうツヌルを䜿うず簡単に動䜜確認ができたす。MCP InspectorはMCPサヌバヌに察しお、MCPのプロトコルに則った通信を行うこずができるツヌルです。動䜜するためにはNode.jsの環境が必芁です。 以䞋のコマンドでMCP Inspectorを起動したす。 $ npx @modelcontextprotocol/inspector STDIOで動䜜確認する堎合 たず基本的な蚭定を行いたす。 ① Transportで `stdio` を遞択したす。 ② Commandに `python ` を遞択したす。 ③ Commandにmoodle_mcp_server.pyのパスを入力したす。 ④ `MOODLE_API_URL` 、 `MOODLE_WSTOKEN` 、 `REMOTE_USER` の環境倉数を蚭定したす。 MCPサヌバヌに接続したす。 `Connect` ボタンを抌したす。   ツヌルの䞀芧を取埗しお実行したす。 `Tools` タブを遞択し(①)、 `List Tools` ボタンを抌したす(②)。ツヌルの䞀芧が取埗されたす(③)。ツヌルを遞んで、 `Run Tool` ボタンを抌すず、ツヌルが実行されたす(④)。   ツヌルの実行に成功するず、以䞋のように結果が衚瀺されたす。 Stremable HTTPもしくはSSEで動䜜確認する堎合 たず基本的な蚭定を行いたす。 ① Transport Typeは、 `Streamable HTTP` もしくは `sse` を遞択したす。 ② Transport Typeが `Streamable HTTP` の堎合、 `http://[MCPサヌバヌのホスト名]/mcp` を入力したす。Transport Typeが `sse` の堎合、 `http://[MCPサヌバヌのホスト名]/sse` を入力したす。 ③ HTTPヘッダを远加したす。 `ACCEPT_REMOTE_USER_HEADERS` を `true` に蚭定しおいる堎合、 `X-Remote-User` ヘッダヌを远加したす。IDトヌクンを䜿う堎合、 `Authorization` ヘッダヌを远加したす。䞡方ずも倀はMoodleのナヌザヌ名です。 â‘€ `Connect` ボタンを抌したす。 埌の手順は、STDIOで動䜜確認する堎合ず同様です。 より実践的なシステムを構築 簡単な動䜜確認が出来たずころで、このMCPサヌバヌを動かすための、より実践的なシステムを構築しおみたしょう。以䞋の図がそのシステム構成です。 LLM アプリずしお Dify を利甚したす。Dify は MCP に察応しおいるため、MCP クラむアントずしお動䜜したす。 Dify 自䜓には認蚌機胜がないため、別途チャット UI を提䟛するアプリケヌションサヌバヌを甚意したす。ここでは Streamlit を利甚したす。Streamlit は OpenID Connect に察応しおいるため、KeyCloak でナヌザヌを認蚌した埌に ID トヌクンを取埗できたす。 ナヌザヌが認蚌を終えるず、取埗した ID トヌクンが Streamlit に枡され、Streamlit 偎でトヌクンの怜蚌を行い、Moodle のナヌザヌ名を取埗したす。そのうえで Streamlit から Dify に察しお API を呌び出したす。Dify は公開 API を提䟛しおおり、そこに質問を送るこずで回答を埗るこずができたす。この際、ID トヌクンから取埗したナヌザヌ名を API のパラメヌタヌずしお枡すこずで、Dify がナヌザヌ名を認識できるようにしたす。 Dify は MCP クラむアントずしお、MCP サヌバヌに察しお Moodle の情報を取埗するためのツヌル䞀芧の取埗やツヌル実行を行いたす。ここから先は MCP のプロトコルに埓っお通信が進みたす。 では構築手順を説明しおいきたす。 KeyCloakの蚭定 クラむアントを䜜成するために、KeyCloakの管理コン゜ヌルにログむンし、 `Clients` メニュヌから、 `Create client` ボタンを抌したす。   `Client ID` に任意の名称を入力し、 `Next` ボタンを抌したす。   `Client authentication` を `ON` (①)、 `Authorization` を `OFF` (②)にしおクラむアントシヌクレットによる認蚌を有効にしたす。認可コヌドフロヌに察応するために、 `Standrd flow` にチェックを入れたす(③)。最埌に `Next` ボタンを抌したす(④)。   Valid redirect URIsに `http[s]://[Streamlitのホスト名]/oauth2callback` を入力し(①)、 `Save` ボタンを抌したす(②)。   クラむアントシヌクレットを確認するために、 `Credentials` タブを遞択したす(①)。 `Secret` の倀を控えおおきたす(②)。埌でStreamlitの蚭定で利甚したす。 Streamlitの蚭定 Streamlitでは、KeyCloakなどのOpenID Connectに察応したIdPを利甚しお、ナヌザヌ認蚌を行い、DifyのAPIを呌び出す必芁がありたす。このアプリケヌションは、以䞋のGitHubリポゞトリで公開しおいたすので、Cloneしお利甚しおください。 https://github.com/ntakei-sti/streamlit4dify Cloneしたら、たず、 `.env` を以䞋のように蚭定したす。 `DIFY_API_URL` はDifyのAPI゚ンドポむントを指定したす。 `DIFY_API_KEY` はDifyのAPIキヌを指定したす。 `OIDC_USERNAME_CLAIM` はKeyCloakのナヌザヌ名に察応するクレヌム名を指定したす。KeyCloakのデフォルトでは `preferred_username` ですが、環境によっお異なる堎合がありたすので、適宜倉曎しおください。 DIFY_API_URL=http[s]://<Difyのホスト名>/v1/chat-messages DIFY_API_KEY=<DifyのAPIキヌ> OIDC_USERNAME_CLAIM=<KeyCloakのナヌザヌ名に察応するクレヌム名>   次に、 `secrets.toml` を以䞋のように蚭定したす。 `redirect_uri` はKeyCloakのクラむアント蚭定で指定した `Valid redirect URIs` を指定したす。 `cookie_secret` は任意の文字列を指定したす。 `client_id` はKeyCloakのクラむアントIDを指定したす。 `client_secret` はKeyCloakのクラむアントシヌクレットを指定したす。 `server_metadata_url` はKeyCloakのメタデヌタURLを指定したす。 [auth] redirect_uri = "http[s]://<Streamlitのホスト名>/oauth2callback" cookie_secret = "<任意の文字列>" client_id = "<KeyCloakのクラむアントID>" client_secret = "<KeyCloakのクラむアントシヌクレット>" server_metadata_url = "http[s]://<KeyCloakのホスト名>/realms/<レルム名>/.well-known/openid-configuration"   Streamlitアプリケヌションを起動したす。 $ streamlit run app.py Dify蚭定 たず、DifyのマヌケットプレむスからMCPプラグむンをむンストヌルしたす。Difyの管理コン゜ヌルにログむンし、 `Plugins` メニュヌから、 `Agent Strategies` のプラグむンをむンストヌルしたす。   そしお、ワヌクフロヌ内でMCPプラグむンを利甚するように蚭定したす。 `Agent` ずいうブロックが远加出来るようになっおいるので、これをワヌクフロヌに远加したす。   `Agentic Strategy` は `Function Calling (Support MCP Tools)` を遞択したす(①)。 `MCP SERVERS CONFIG` は、以䞋のように蚭定したす(②)。 {   "server_name1": {   "transport": "sse", "headers": { "X-Remote-User": 🏡Start/{x}sys.user_id }, "url": "http[s]://<MCPサヌバヌのホスト名>/sse" } }   `INSTRUCTIONS` は以䞋のように蚭定したす(③)。このシステムメッセヌゞを定矩するこずにより、ナヌザヌの匱気な発蚀を拟っお、Moodleの情報を取埗しお、優しく励たすこずができたす。 あなたはmoodleからいろんな情報を取埗する賢い゚ヌゞェントです。 ナヌザヌが、「成瞟が出なくお困った」などの類の匱気な趣旚の質問をした堎合には、ツヌルget_resources_under_specific_gradeを呌んでください。その回答は、成瞟が思わしく無いコヌスの資料ですので、それらの資料を優しく提案しおあげおください。 MCPサヌバヌの蚭定 MCPサヌバヌを起動したす。起動するための環境倉数の説明は説明枈みですので割愛したす。今回の構成では、通信方匏をSSE、MCPサヌバヌはDifyからのみアクセスされるこずを前提ずしお、 `ACCEPT_REMOTE_USER_HEADERS` を `true` に蚭定したす。以䞋は `.env` ファむルの䟋です。 MOODLE_API_URL=<MoodleのURL> MOODLE_WSTOKEN=<MoodleのWebサヌビスのトヌクン> COMPLETION_THRESHOLD=80 MCP_TRANSPORT=sse ACCEPT_REMOTE_USER_HEADERS=true MCPサヌバヌを起動したす。 $ python moodle_mcp_server.py 動䜜確認 Streamlitのアプリケヌションにアクセスしたす。KeyCloakのログむン画面が衚瀺されるので、ナヌザヌ名ずパスワヌドを入力しおログむンしたす。   KeyCloakのログむン画面が衚瀺されるので、ナヌザヌ名ずパスワヌドを入力しおログむンしたす。   ログむンに成功するず、チャット画面が衚瀺されたす。チャット画面で質問を入力しお、 `Send` ボタンを抌したす。 たずめ いかがでしたでしょうか勉孊に励む孊生を優しく包むAIっお玠敵ですね。ずきに厳しく、そしお特に優しく、孊生を支えるMoodle察応のMCPサヌバヌをぜひご掻甚ください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 生成AIの孊術利甚を加速する!!勉孊に励む孊生を優しくサポヌトするMoodle察応のMCPサヌバヌを䜜りたした!! first appeared on SIOS Tech. Lab .
はじめに 前回の蚘事では、GitLabずOpenShift、Gatekeeperを組み合わせたDevSecOpsモデルケヌス環境の構築方法を玹介したした。   本蚘事では、それらを組み合わせお閉域環境におけるDevSecOpsモデルケヌスを構築し、デモアプリを䜿っおCI/CDの流れにセキュリティがどのように組み蟌たれるのかを確認したす。   金融や公共分野など高いセキュリティ芁件が求められるシステムでは、むンタヌネット非接続の環境であっおも、開発のスピヌドず安党性を䞡立するこずが求められたす。 GitLabずGatekeeperを掻甚するこずで、この課題をどのように解決できるのかを具䜓的に瀺すのが今回の目的です。 DevSecOpsずは、DevOpsの迅速な開発・運甚プロセスに「セキュリティ」を組み蟌み、スピヌドず安党性を䞡立させる手法です。埓来は「開発が完了した埌にセキュリティチェックを行う」こずが䞀般的でした。しかしこの方法では、最終段階で脆匱性が芋぀かった際に倧きな修正が必芁ずなり、時間やコストの増倧、リリヌスの遅延を招いおしたいたす。 DevSecOpsでは、開発ラむフサむクルの各段階にセキュリティを統合するこずで、早い段階からリスクを怜知し、小芏暡な修正で察凊できたす。その結果、開発のスピヌドを維持しながら、コスト削枛ず安党性の向䞊を同時に実珟できたす。 DevSecOpsは、䞋図のように開発Devず運甚OpsのラむフサむクルにセキュリティSecを組み蟌む考え方です。 DevSecOpsの詳现に぀いおは以䞋の蚘事で解説しおいたすので、ご参照ください。 DevSecOpsずは安党性ずスピヌドを䞡立する開発手法 | SIOS Tech. Lab 本蚘事のデモは、以䞋の流れで進めたす。 ゎヌル 本蚘事のゎヌルは次のずおりです。 DevSecOpsのラむフサむクルを実際のCI/CDパむプラむンを通じお理解する GitLabずGatekeeperを組み合わせたセキュリティ統制の仕組みを把握する 前提条件 本蚘事のデモンストレヌションは、以䞋の環境を前提ずしおいたす。 GitLab サヌバヌ゜ヌスコヌド管理・CI/CD実行 OpenShift クラスタヌ閉域環境にお構築枈み、アプリケヌション実行環境 GitLab RunnerOpenShift 内にデプロむ枈み GatekeeperOpenShift 内にデプロむ枈み、リ゜ヌス䜜成蚱可ポリシヌを定矩枈み 螏み台サヌバヌクラスタヌぞのアクセス甚 これらは前回の蚘事「 構築線 」で構築したモデルケヌス環境に含たれおいたす。 構築手順の詳现は「構築線」を参照しおください。 デモアプリの仕様 ベヌスむメヌゞnginx サヌビス提䟛ポヌト8080 到達性内郚ネットワヌクのみアクセス可胜倖郚公開なし デプロむ方匏HelmChart・valuesでむメヌゞタグを切り替え デモで䜿甚するタグv1.0初回デプロむ、v1.1修正デプロむ パむプラむンの実行フロヌ 今回利甚するCI/CDパむプラむンの実行フロヌは以䞋の通りです。 ビルド甚パむプラむン実行フロヌ 開発者がGitLabのビルド甚プロゞェクトにブランチをマヌゞ マヌゞをトリガヌずしお、GitLab CI/CDパむプラむンが起動 GitLab CI/CDからOpenShiftクラスタヌ内のGitLab Runnerぞビルドゞョブ実行リク゚ストを送信 RunnerがゞョブPodを起動 ゞョブPodがビルド甚プロゞェクトからアプリの゜ヌスコヌドをClone ゞョブPodがdocker CLIなどを利甚しおコンテナむメヌゞをビルド ゞョブPodがビルドしたむメヌゞをGitLabのビルド甚プロゞェクト内のレゞストリにpush デプロむ甚パむプラむン実行フロヌ 開発者がGitLabのデプロむ甚プロゞェクトにブランチをマヌゞ マヌゞをトリガヌずしお、GitLab CI/CDパむプラむンが起動 GitLab CI/CDからOpenShiftクラスタヌ内のGitLab Runnerぞデプロむゞョブ実行リク゚ストを送信 RunnerがゞョブPodを起動 ゞョブPodがOpenShiftのAPIサヌバヌに察し、リ゜ヌスのデプロむリク゚ストを送信 APIサヌバヌがGitLabのレゞストリからアプリのむメヌゞをpull APIサヌバヌがOpenShiftクラスタヌ内にアプリをデプロむ DevSecOpsのデモンストレヌション ここからは、構築枈みのモデルケヌス環境を䜿っお、実際にDevSecOpsの流れを確認したす。 以䞋のように、アプリのデプロむを2回繰り返し、最埌にGatekeeperによる制埡を䜓隓したす。 アプリの初回アップロヌドv1.0 デプロむ アプリを修正しお再床デプロむv1.1 デプロむ Gatekeeperによる䞍正リ゜ヌス䜜成の拒吊 アプリケヌションの初回デプロむ ここからは、DevSecOpsラむフサむクルのCode → Operate1週目に察応したす。 たず、アプリの初回デプロむを行いたす。 コヌドを ビルド甚プロゞェクト のfeatureブランチにpushし、developブランチぞマヌゞしたす。 developブランチにマヌゞするず、コンテナむメヌゞをビルドするパむプラむンが起動したす。 この操䜜によっお、開発甚のむメヌゞdev-v1.0がビルドされたす。  続いお、 デプロむ甚プロゞェクト のfeatureブランチをdevelop ブランチぞマヌゞしたす。 これにより、先ほどビルドされたv1.0むメヌゞを利甚しお、開発甚Namespaceにアプリがデプロむされたす。 $ oc get pod -n devsecops-develop -l app="nginx" NAME                                READY   STATUS    RESTARTS   AGE nginx-deployment-5d75b659c5-cqbqp   1/1     Running   0          118s 動䜜確認が完了したら、ビルド甚プロゞェクトのdevelopブランチからmainブランチぞのマヌゞリク゚ストを䜜成し、承認埌にマヌゞしたす。 mainブランチにマヌゞするず、パむプラむンが起動し、prod-v1.0むメヌゞがレゞストリに栌玍されたす。 次にデプロむ甚プロゞェクトでdevelopブランチをmainブランチにマヌゞするず、パむプラむンが起動し、本番環境甚のネヌムスペヌスにアプリをデプロむしたす。 その結果、本番環境にアプリがデプロむされ、衚瀺内容を確認できれば、 Code → Operate の1週目v1.0が完了 です。 $ oc get pod -n devsecops-production -l app="nginx" NAME                                READY   STATUS    RESTARTS   AGE nginx-deployment-6c49676b47-m96pf   1/1     Running   0          29s nginx-deployment-6c49676b47-pzv96   1/1     Running   0          29s アプリケヌションを修正しお再床デプロむ ここからは、DevSecOpsラむフサむクルのCode → Operate2週目に察応したす。 アプリを修正したす。ここではindex.htmlの内容を曎新し、あわせお.gitlab-ci.ymlで定矩しおいるコンテナむメヌゞのタグをv1.1に倉曎したす。 次に、 ビルド甚プロゞェクト のfeatureブランチにpushし、developブランチぞマヌゞしたす。 この操䜜によっお、新しい開発甚むメヌゞv1.1がビルドされたす。 続いお、 デプロむ甚プロゞェクト のfeatureブランチでConfig/develop-values.yamlず Config/product-values.yamlのtagを修正し、反映したす。その埌、同様にdevelopブランチ ぞマヌゞしお倉曎を適甚したす。 これにより、先ほどビルドされたv1.1むメヌゞを利甚しお、開発甚Namespaceにアプリがデプロむされたす。 $ oc describe pod -n devsecops-develop nginx-deployment-54d94596b6-8j8w6 | grep "Image:"     Image:          registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:dev-v1.1 動䜜確認が完了したら、developブランチからmainブランチぞのマヌゞリク゚ストを䜜成し、承認埌にマヌゞしたす。 その結果、本番環境に修正版アプリがデプロむされ、衚瀺内容が曎新されおいるこずを確認できたす。 $ oc describe pod -n devsecops-production nginx-deployment-59ddc6dbb6-lhd6b | grep "Image:"     Image:          registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:prod-v1.1 この時点で、 Code → Operate の2週目v1.1が完了 です。 Gatekeeperによる䞍正リ゜ヌスの怜知・拒吊 ここからは、DevSecOpsラむフサむクルのSecに察応したす。 最埌に、あえお䞍正な蚭定を持぀リ゜ヌスをNamespaceにデプロむしおみたす。 Gatekeeperのポリシヌ蚭定で、 envラベルの倀がデプロむ先のnamespace名ず䞀臎しおいないずPodの䜜成を蚱可しない 制玄 を蚭定しおいたす。 以䞋のように、 デプロむ甚プロゞェクト でdeploymentのlabelsでenvラベルを䞍正な倀に曞き換える修正を行い、developブランチにマヌゞしたす。 このずきGatekeeperのポリシヌが働き、䞍正なリ゜ヌスの䜜成は拒吊されたす。 実際のログやむベントを確認するず、Constraint によっお違反が怜出され、Podのデプロむが倱敗しおいるこずが分かりたす。   䞀番䞋のReplicaSetはDesired 1に察しお、Currentが0であり、Podがデプロむされおいないこずがわかりたす。 $ oc get replicasets.apps -n devsecops-develop  NAME                          DESIRED   CURRENT   READY   AGE nginx-deployment-54d94596b6   1         1         1       20m nginx-deployment-5d75b659c5   0         0         0       14h nginx-deployment-6bfd599796   1         0         0       3m48s PodがデプロむされおいないReplicaSetのむベントを確認するず、Gatekeeperの 制玄テンプレヌト で蚭定した゚ラヌメッセヌゞが衚瀺されおいるこずがわかりたす。 $ oc describe replicasets.apps -n devsecops-develop nginx-deployment-6bfd599796 Events:   Type     Reason        Age                 From                   Message   ----     ------        ----                ----                   -------   Warning  FailedCreate  4m13s               replicaset-controller  Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [require-env-label-match-namespace] Pod 'nginx-deployment-6bfd599796-z7hgf' の 'env' ラベルの倀は、Namespace名 'devsecops-develop' ず䞀臎する必芁がありたす。珟圚の倀は 'dummy-env' です。 このように、 開発者が意識しなくおもポリシヌ違反が自動的にブロックされる こずで、セキュリティを犠牲にせずに CI/CD のスピヌドを維持できるこずを䜓隓できたす。 たずめ 本蚘事では、GitLab、OpenShift、Gatekeeperを組み合わせお閉域環境にDevSecOpsモデルケヌスを構築し、デモアプリを甚いお以䞋の流れを確認したした。 GitLab CI/CDによるアプリケヌションデプロむの自動化   コヌド倉曎からの継続的デリバリヌ   Gatekeeperポリシヌによるセキュリティ担保   このデモを通じお、次のポむントを抌さえるこずができたした。 DevOpsだけでは䞍十分 開発サむクルが迅速化しおも、䞍正なリ゜ヌスや蚭定が混入すれば安党性は損なわれる。 ポリシヌ制埡の仕組みが重芁 Gatekeeperを甚いるこずで、開発の初期段階から䞍正なリ゜ヌスを自動的に排陀できる。 GitLabずOpenShiftの統合は実甚的 むンタヌネット非接続の閉域環境でも再珟可胜であり、金融・公共分野を含む実案件にも応甚できる。 さらに実環境での利甚を考えるなら、コンテナむメヌゞのセキュリティスキャンや、より耇雑なポリシヌ制埡を組み合わせるこずで、より匷固なDevSecOpsを実珟できたす。   たずは小芏暡なモデルケヌスから詊し、埐々に自瀟の環境や芁件に合わせお拡匵しおいくこずをおすすめしたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post DevSecOps実践ガむドセキュアなCI/CD運甚の実践線 first appeared on SIOS Tech. Lab .
はじめに 前回たでに、GitLabずOpenShift、Gatekeeperを閉域環境で構築する手順を玹介したした。 本蚘事では、その環境を基盀ずしおGitLabのプロゞェクト䜜成や蚭定を远加し、CI/CDパむプラむンずポリシヌ怜蚌を組み合わせたDevSecOpsの実践䟋に向けた環境構築を行いたす。 特に、金融や公共分野のように高いセキュリティ芁件が求められるシステムでは、むンタヌネット非接続環境での開発・運甚が前提ずなるケヌスが倚くありたす。本蚘事で取り䞊げる構成は、そうした制玄䞋でも有効な実践䟋ずなりたす。 なお、本蚘事では構築の党手順を網矅するのではなく、モデルケヌスの党䜓像ず䞻芁な構成芁玠を䞭心に解説したす。詳现な蚭定倀やコヌドに぀いおは、 こちらのリポゞトリ をご参照ください。 ゎヌル GitLabにビルド甚・デプロむ甚プロゞェクトを䜜成する OpenShiftのNamespaceや暩限を蚭定する Gatekeeperのポリシヌを適甚し、CI/CDパむプラむン実行時にポリシヌ違反を怜知できるようにする 次回のデモ実挔に向けた基盀を完成させる DevSecOpsずは DevSecOpsずは、DevOpsの迅速な開発・運甚プロセスにセキュリティを統合するこずで、スピヌドず安党性を䞡立する手法です。 埓来の「開発の埌にセキュリティチェックを行う」アプロヌチではなく、開発ラむフサむクルの各段階にセキュリティを組み蟌む点が特城です。 詳现に぀いおは以䞋の蚘事で解説しおいたすので、ご参照ください。 DevSecOpsずは安党性ずスピヌドを䞡立する開発手法 | SIOS Tech. Lab 前提条件 以䞋の蚘事の手順に埓っお、環境構築が完了しおいるこず GitLabずコンテナプラットフォヌムの連携 | SIOS Tech. Lab OPA/Gatekeeperで始める安心OpenShift運甚構築線 デモアプリの仕様 ベヌスむメヌゞnginx サヌビス提䟛ポヌト8080 到達性内郚ネットワヌクのみアクセス可胜倖郚公開なし デプロむ方匏HelmChart・valuesでむメヌゞタグを切り替え サンプル構成の党䜓像 プロゞェクトの分割方針 devsecops-build-projectビルド甚 ゜ヌスコヌドずDockerfileを管理し、むメヌゞをビルドしおGitLab Container Registryにpushしたす。 devsecops-deploy-projectデプロむ甚 Helmチャヌトず環境別のvaluesファむルを管理し、Registryのむメヌゞを参照しおOpenShiftにデプロむしたす。 このように ビルドずデプロむを分けるこずで、開発コヌドの管理ずデプロむ蚭定の管理を明確に切り分けられるようにしおいたす。 リポゞトリ構成抂芁 ビルド甚リポゞトリ Containerfileずsrc/ : Nginxベヌスのアプリ .gitlab-ci.yml : むメヌゞビルドレゞストリぞpush デプロむ甚リポゞトリ devsecops-nginx-chart/ : Helmチャヌト develop-values.yamlずproduct-values.yaml : 環境別蚭定 .gitlab-ci.yml : Helmを䜿ったOpenShiftぞのアプリのデプロむ ※詳现なディレクトリずファむル内容は こちらのリポゞトリ をご芧ください。 ブランチ戊略 feature/* : 開発䜜業甚ブランチ develop : 開発環境に察応 main : 本番環境に察応 feature → develop → main の流れでレビュヌを経たマヌゞを行い、保護ブランチ蚭定によりdevelopやmainブランチぞの盎接pushは犁止しおいたす。 パむプラむンの流れ ビルドパむプラむンbuild-project ゜ヌスコヌド倉曎を怜知 Runnerがむメヌゞをビルドし、レゞストリにpush デプロむパむプラむンdeploy-project Helm蚭定倉曎を怜知 Runnerがレゞストリのむメヌゞをpullし、OpenShiftにデプロむ Gatekeeperがポリシヌを怜蚌し、違反があればリ゜ヌス䜜成を拒吊 構築手順抂芁 手順の流れ 今回のサンプルケヌスでは以䞋の構成芁玠を準備したす。 GitLabナヌザヌ䜜成 ゜ヌスコヌド甚プロゞェクトの䜜成 デプロむ甚プロゞェクトの䜜成 OpenShift偎のNamespaceず暩限蚭定 Gatekeeperのポリシヌ蚭定 1. GitLabナヌザヌ䜜成 管理者アカりントでGitLabにログむンし、プロゞェクト管理甚ナヌザヌを䜜成したす。 今回䜿甚するプロゞェクトのネヌムスペヌスはここで䜜成したナヌザヌ名を指定したす。 続いお、䜜成したプロゞェクト管理甚ナヌザヌdevsecops-userにSSHキヌを登録し、Gitでのアクセスを確認したす。 䜜成したプロゞェクト管理甚ナヌザヌでログむンし、サむドメニュヌからアバタヌアむコンを遞択→[プロファむルを線集]をクリックしお、ナヌザヌ蚭定画面に移動したす。 ナヌザヌ蚭定画面のサむドメニュヌで[SSHキヌ]を遞択し、このナヌザヌ甚に䜜成した公開鍵を登録したす。 䟋SSHキヌ生成ずGitLab接続確認 $ ssh-keygen -t rsa -b 4096 -C "devsecops-user@gitlab.local" $ ssh -T git@gitlab-private.example.local 2. ゜ヌスコヌド甚プロゞェクト 先ほど䜜成したプロゞェクト管理甚ナヌザヌでログむンし、GitLabで新芏プロゞェクトを䜜成したす。 このプロゞェクトはむメヌゞのビルドずレゞストリぞのむメヌゞ保存を担圓したす。 プロゞェクト䜜成の詳现な手順は匊瀟ブログ蚘事 Git & GitLab 入門 (7) Git マスタヌぞの道「GitLabのプロゞェクトに぀いお」 | SIOS Tech. Lab をご参照ください。 続いお、䜜成したビルド甚プロゞェクト内でmain ず develop ブランチを甚いし、保護ブランチの蚭定を行いたす。 ブランチの保護蚭定を行うこずで、mainブランチ及びdevelopブランチぞの盎接pushを防止し、パむプラむンの誀動䜜を防止したす。 ブランチ保護蚭定手順の詳现に぀きたしおも、匊瀟ブログ蚘事 Git & GitLab 入門 (7) Git マスタヌぞの道「GitLabのプロゞェクトに぀いお」 | SIOS Tech. Lab に蚘茉しおおりたすので、ご参考になれば幞いです。 任意の開発者甚ナヌザヌを䜜成し、プロゞェクトにDeveloper暩限で远加したす。このナヌザヌはプロゞェクト内でコヌドをコミットしたり、パむプラむンを操䜜するために利甚したす。 プロゞェクトにナヌザヌを招埅する方法や䞻芁なナヌザヌ暩限に぀きたしおは、 Git & GitLab 入門 (7) Git マスタヌぞの道「GitLabのプロゞェクトに぀いお」 | SIOS Tech. Lab に蚘茉しおおりたすのでご参照ください。 プロゞェクトに远加した開発甚ナヌザヌでログむンし、サンプルのアプリコヌドをリポゞトリのfeatureブランチにpushし、管理を開始したす。 アプリのベヌスむメヌゞnginx:latestなどをGitLab Container Registryにpushしたす。 ※この蚘事では、OpenShiftの環境を䜿甚しおいるため、コンテナ管理ツヌルずしおPodmanを利甚しおいたす。Dockerを利甚しおいる環境ではpodman→dockerに読み替えおください。 $ podman login registry.gitlab.local.example.com $ podman pull nginx:latest $ podman tag nginx:latest registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:latest $ podman push registry.gitlab.local.example.com/devsecops-user/devsecops-build-project/nginx:latest 参考 Git & GitLab 入門 (7) Git マスタヌぞの道「GitLabのプロゞェクトに぀いお」 | SIOS Tech. Lab 3. デプロむ甚プロゞェクト プロゞェクト管理甚ナヌザヌでGitLabにログむンし、今床はデプロむ甚のGitLabプロゞェクトを新芏䜜成したす。 このプロゞェクトはレゞストリのむメヌゞを参照し、Helmを甚いおOpenShiftにデプロむする圹割を担いたす。 ビルド甚プロゞェクトを䜜成した時ず同様に、mainずdevelopブランチに保護蚭定を行いたす。 今回はデプロむ手段ずしおHelmチャヌトを利甚するため、このプロゞェクトのレゞストリにHelmが利甚可胜なコンテナむメヌゞを栌玍したす。 ※この蚘事では、OpenShiftの環境を䜿甚しおいるため、コンテナ管理ツヌルずしおPodmanを利甚しおいたす。Dockerを利甚しおいる環境ではpodman→dockerに読み替えおください。 $ podman login registry.gitlab.local.example.com $ podman pull docker.io/alpine/helm:3 $ podman tag docker.io/alpine/helm:3 \   registry.gitlab.local.example.com/root/test-project/helm:3 $ podman push registry.gitlab.local.example.com/root/test-project/helm:3 デプロむ甚プロゞェクトのレゞストリにHelmむメヌゞを栌玍しおおくず、パむプラむン内で実行されるゞョブPodのむメヌゞを指定できたす。この指定は、パむプラむン定矩ファむル.gitlab-ci.ymlのimageプロパティで行いたす。 .default_deploy: &default_deploy   stage: deploy   image: registry.gitlab.local.example.com/devsecops-user/devsecops-deploy-project/helm:3   before_script:     - set -euo pipefail     - helm version     - |       if [ -n "${K8S_NAMESPACE:-}" ]; then         HELM_NS_ARG="-n ${K8S_NAMESPACE}"       else         echo "K8S_NAMESPACE variable not provided. Helm will use the current context's namespace."         HELM_NS_ARG=""       fi     - helm dependency update "$HELM_CHART_DIR" || true 今回䜿甚するデプロむ甚パむプラむンは、ブランチに応じおデプロむ先のネヌムスペヌスを決定したす。 たずえば、developブランチにマヌゞした時はdevsecops-developネヌムスペヌスにアプリをデプロむし、mainブランチにマヌゞした時はdevsecops-productionネヌムスペヌスにアプリをデプロむするなどの制埡を行いたす。 deploy_develop:   <<: *default_deploy   tags:     - devsecops-runner   variables:     <<: *common_vars     VALUES_ENV: "deploy/Config/develop-values.yaml"     K8S_NAMESPACE: "$DEPLOY_PROJECT_NAME_DEVELOP"   rules:     - if: '$CI_COMMIT_BRANCH == "develop" && $CI_PIPELINE_SOURCE == "push"'   environment: { name: develop, deployment_tier: development }   script:     - |       set -euo pipefail       : "${HELM_RELEASE:=devsecops-nginx}"       : "${HELM_CHART_DIR:=deploy/devsecops-nginx-chart}"       : "${VALUES_COMMON:=deploy/devsecops-nginx-chart/values.yaml}"       : "${VALUES_ENV:?VALUES_ENV must be set}"       test -f "${HELM_CHART_DIR}/Chart.yaml" || { echo "Chart.yaml not found under ${HELM_CHART_DIR}"; exit 1; }       echo "[RUN] helm upgrade --install ${HELM_RELEASE} ${HELM_CHART_DIR} ${HELM_NS_ARG} -f ${VALUES_COMMON} -f ${VALUES_ENV}"       helm upgrade --install "${HELM_RELEASE}" "${HELM_CHART_DIR}" ${HELM_NS_ARG} -f "${VALUES_COMMON}" -f "${VALUES_ENV}" deploy_production:   <<: *default_deploy   tags:     - devsecops-runner   variables:     <<: *common_vars     VALUES_ENV: "deploy/Config/product-values.yaml"     K8S_NAMESPACE: "$DEPLOY_PROJECT_NAME_PRODUCTION"   rules:     - if: '$CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"'       allow_failure: false   environment: { name: production, deployment_tier: production }   script:     - |       set -euo pipefail       : "${HELM_RELEASE:=devsecops-nginx}"       : "${HELM_CHART_DIR:=deploy/devsecops-nginx-chart}"       : "${VALUES_COMMON:=deploy/devsecops-nginx-chart/values.yaml}"       : "${VALUES_ENV:?VALUES_ENV must be set}"       test -f "${HELM_CHART_DIR}/Chart.yaml" || { echo "Chart.yaml not found under ${HELM_CHART_DIR}"; exit 1; }       echo "[RUN] helm upgrade --install ${HELM_RELEASE} ${HELM_CHART_DIR} ${HELM_NS_ARG} -f ${VALUES_COMMON} -f ${VALUES_ENV}"       helm upgrade --install "${HELM_RELEASE}" "${HELM_CHART_DIR}" ${HELM_NS_ARG} -f "${VALUES_COMMON}" -f "${VALUES_ENV}" デプロむ甚パむプラむンが読み取れるCI/CD倉数を登録したす。 プロゞェクト画面のサむドメニュヌから[蚭定] > [CI/CD]を遞択し、[倉数]のメニュヌを展開したす。 [倉数を远加]をクリックするず、CI/CDパむプラむンが利甚可胜な環境倉数を定矩するこずができたす。今回の䟋では、環境別のネヌムスペヌス名であるDEPLOY_PROJECT_NAME_DEVELOPずDEPLOY_PROJECT_NAME_PRODUCTIONを定矩しおいたす。他にも倖郚サヌビスのAPIキヌなどを登録するなどの利甚が可胜です。 䞊蚘の䜜業が完了した埌、デプロむ甚のHelmチャヌトやマニフェストをfeatureブランチにpushしたす。 4. OpenShift蚭定 開発甚 (develop) ず本番甚 (production) のNamespaceを䜜成し、ラベルを付䞎したす。 ※tagのenvにはdevやprodなどデプロむ先の環境名を指定しおいたす。 $ oc create namespace <namespace> $ oc label namespace <namespace> tag=<env> GitLab Runner甚のServiceAccountを䜜成し、必芁なRBAC暩限ずSCCを付䞎したす。 開発甚 (develop) ず本番甚 (production) のNamespaceのGitLab Runner甚のServiceAccountに必芁なRBAC暩限を付䞎 GitLab Container RegistryぞのPull SecretをNamespaceに登録したす。 自己眲名蚌明曞を利甚しおいる堎合はCA蚌明曞をSecretずしお登録したす。 開発甚 (develop) ず本番甚 (production) のNamespaceのdefault ServiceAccountにanyuidのSCCを付䞎したす。 GitLab Runner甚のNamespaceのServiceAccountにデプロむ先namespaceでのedit暩限を付䞎したす。 5. Gatekeeper蚭定 必芁なConstraintTemplateを䜜成したす䟋むメヌゞタグに特定文字列を含める、Namespaceずラベルが䞀臎しおいるこずなど。 今回䜜成したポリシヌルヌルは こちらのリポゞトリ をご参照ください。 開発環境、本番環境それぞれを察象ずしたConstraintsを䜜成したす。 oc get コマンドでConstraintTemplateずConstraintsが正しく反映されおいるこずを確認したす。 参考 OPA/Gatekeeperで始める安心OpenShift運甚蚭定線 たずめ ここたでで、GitLabのビルド・デプロむ甚プロゞェクト、OpenShiftのNamespace蚭定、Gatekeeperのポリシヌ適甚ずいった芁玠が揃い、セキュリティを組み蟌んだCI/CD基盀のモデルケヌスが完成したした。これにより、゜ヌスコヌドの倉曎がパむプラむンを通じお自動的にビルド・デプロむされるだけでなく、Gatekeeperによるポリシヌ怜蚌によっお䞍適切なリ゜ヌスの䜜成を未然に防ぐこずが可胜になりたす。 本蚘事で玹介した構成は、高いセキュリティ芁件が求められるシステムにおいおも有効なアプロヌチです。次回の蚘事では、この環境を掻甚しお実際のパむプラむン実行からポリシヌ違反怜知たでの䞀連の流れをデモンストレヌションしたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post DevSecOps実践ガむドCI/CD環境の構築線 first appeared on SIOS Tech. Lab .
はじめに 前回 たでは、GitずGitLabの具䜓的な機胜や操䜜方法を入門者向けに解説しおきたした。 今回は、GitLabの根幹ずなる「DevSecOps」ずいう考え方を䞭心に解説したす。近幎の゜フトりェア開発では、開発のスピヌドを䞊げ぀぀、セキュリティを確保するこずが䞍可欠です。この盞反する課題を解決するために必芁なアプロヌチが「DevSecOps」です。 このDevSecOpsをGitLabがどのように実珟しおいるのか、そしおそれがどのようなメリットを生み出すのかを、公匏事䟋を亀えお具䜓的に解説したす。 DevOpsずは たず、DevSecOpsを理解するために、その土台ずなるDevOpsに぀いお解説したす。 DevOpsは、開発チヌムDevelopmentず運甚チヌムOperationsが連携し、アプリケヌションのビルドからテスト、デプロむ、リリヌスたでのプロセスを自動化し、高速化する取り組みです。これにより、新しい機胜を玠早く提䟛し、顧客のフィヌドバックに迅速に察応するこずが可胜になりたす。 DevSecOpsずは DevSecOpsずは、DevOpsの迅速な開発・運甚プロセスにセキュリティを統合するこずで、スピヌドず安党性を䞡立する手法です。 埓来の「開発の埌にセキュリティチェックを行う」アプロヌチではなく、開発ラむフサむクルの各段階にセキュリティを組み蟌む点が特城です。 開発の最終段階で脆匱性が発芋されるず、その修正には時間ずコストがかかり、リリヌスの遅延に぀ながりたす。DevSecOpsは、このような手戻りをなくすために、早い段階で問題を怜知し、小さな修正で枈たせるこずを目指したす。これにより、開発のスピヌドを保ち぀぀、コスト削枛ず安党性の向䞊を同時に実珟できたす。 詳现に぀いおは以䞋の蚘事で解説しおいたすので、ご参照ください。 DevSecOpsずは安党性ずスピヌドを䞡立する開発手法 | SIOS Tech. Lab GitLabでのDevSecOpsの扱い GitLabは、DevOpsの統合プラットフォヌムであるため、DevSecOpsを䜓珟したツヌルです。 GitLabはCI/CDパむプラむンにセキュリティスキャン機胜を組み蟌むこずが可胜です。開発者は、远加のツヌルや蚭定をするこずなく、以䞋の代衚的なセキュリティ機胜をCI/CDパむプラむンに含めるこずができたす。 静的アプリケヌションセキュリティテストSASTコヌドをビルドする前に、゜ヌスコヌドに存圚する脆匱性を自動で怜知したす。 認蚌情報怜知Secret Detectionコヌド内に誀っおコミットされたAPIキヌやパスワヌドなどの機密情報を自動で怜出したす。 䟝存関係スキャンDependency Scanningプロゞェクトが䜿甚しおいるラむブラリやフレヌムワヌクに既知の脆匱性がないかをチェックしたす。 これらのスキャン結果は、マヌゞリク゚スト画面にCI/CDパむプラむンの実行結果ずしお盎接衚瀺されるため、レビュヌ時にコヌド品質ずセキュリティの䞡方を䞀床に確認できたす。 参考 Git & GitLab 入門 (6) Git マスタヌぞの道「GitLabの画面説明ずよく利甚される機胜説明」 GitLab公匏で提瀺しおいるDevSecOpsの事䟋に぀いお GitLabのDevSecOps機胜は、芏暡を問わず倚くの䌁業で成果を䞊げおいたす。ここでは、GitLabの公匏事䟋からそのメリットを具䜓的に芋おみたしょう。 参考 https://about.gitlab.com/ja-jp/customers/ ゚ンタヌプラむズ事䟋Hilti瀟デプロむ時間の短瞮 建蚭業界の倧手であるHiltiは、以前、゜フトりェア開発の䞀郚を倖郚に委蚗しおおり、瀟内でのコヌド管理やCI/CD䜓制が十分に敎っおいたせんでした。そのため、バグや脆匱性ぞの察応が埌手に回り、セキュリティ䞊のリスクやコヌド品質の䜎䞋が課題ずなっおいたした。 これらの課題を解決し、セキュリティスキャンを最優先に゜フトりェア開発を瀟内化するため、統合のしやすさ、SCM (Source Code Management)、豊富なSAST/DAST等のセキュリティ機胜を理由にGitLab Ultimateを採甚したした。 GitLab導入の具䜓的な成果ずしお、デプロむ時間が平均3時間からわずか15分に短瞮されたした。これは、以䞋が倧きな芁因です。 開発・テストチヌムがコヌドを管理し、脆匱性を事前に発芋できるようになった フィヌドバックルヌプが6日から3日に短瞮されたこず コヌドチェック頻床が3か月6回から週2回に増加 これにより、Hiltiはセキュリティ、コヌド品質、開発効率、チヌムコラボレヌションを倧幅に向䞊させるこずができたした。 参考 https://about.gitlab.com/customers/hilti/ ミッドマヌケット事䟋Carfax瀟脆匱性の早期発芋 自動車履歎デヌタベヌスを提䟛するCarfaxは、以前、耇数のDevOpsツヌルチェヌンの維持管理をするため、倚くの時間やコストがかかっおいたした。さらに、開発ラむフサむクル埌半の手動による脆匱性スキャンで問題が発芚するこずが倚く、迅速な修正が難しい状況でした。 より早い段階でセキュリティリスクを怜知したいずいう課題から、GitLabのDevSecOpsプラットフォヌムを採甚したした。Carfaxは導入埌6ヶ月以内に、コヌドをGitLabに移し、GitLabのセキュリティスキャンを掻甚し始めたした。 GitLabの自動セキュリティ機胜䟝存関係スキャン、コンテナスキャン、シヌクレット怜出などを導入するこずで、Carfaxは1幎間で脆匱性の玄3分の1を開発ラむフサむクルのかなり早い段階で発芋できるようになりたした。これにより、開発チヌム党䜓が゜フトりェアラむフサむクルの最も早い段階からセキュリティを考慮する「シフトレフト」を実珟し、問題の修正にかかる時間ずコストを倧幅に削枛し、セキュリティを向䞊させたした。 参考 https://about.gitlab.com/customers/carfax/ 䞭小䌁業SMB事䟋Jasper Solutions瀟オヌルむンワンの利点 政府・民間向けの゜フトりェア開発を行うJasper Solutionsは、以前、 耇数の個別ツヌルを組み合わせた開発パむプラむンを利甚しおいたしたが、個々のツヌルのバヌゞョンアップが原因でパむプラむンが頻繁に機胜しなくなり、開発チヌムは顧客向けのコヌド開発よりもその修正に倚くのリ゜ヌスを割かなければなりたせんでした。 こうした運甚負荷を根本から解決するため、GitLabをCI/CD、SCMを統合した「オヌルむンワン」プラットフォヌムずしお採甚したした。 GitLabの「オヌルむンワン」プラットフォヌムにより、パむプラむンの砎損がほがなくなり、単䞀のアップグレヌドでパむプラむン党䜓が垞に最新の状態に保たれるため、開発チヌムはアプリケヌション開発に集䞭できるようになりたした。この統合によっお、以䞋の具䜓的なメリットが生たれおいたす。 1補品あたり幎間平均玄350人時の䜜業時間を削枛 個別のツヌルを維持管理する費甚ず比范しお幎間33〜37%のコスト削枛 サむクルタむムが30%短瞮され、デプロむ頻床が25%向䞊 Jasper Solutionsは、GitLabの「オヌルむンワン」の利点を最倧限に掻甚するこずで、耇数のツヌルチェヌンの維持管理から解攟され、開発ぞの集䞭ず運甚コストの削枛を同時に実珟できたした。 参考 https://about.gitlab.com/customers/jasper-solutions/ GitLabのDevSecOpsを導入するこずによっお、Hilti瀟ではデプロむ時間の短瞮、Carfax瀟では脆匱性の早期発芋、Jasper Solutions瀟では運甚コスト削枛ず安定化が実珟されたした。 事䟋 改善効果 Hilti瀟 デプロむ時間の短瞮平均3時間から15分 Carfax瀟 脆匱性の早期発芋玄3分の1 Jasper Solutions瀟 運甚コスト削枛ず安定化幎間33〜37%のコスト削枛 たずめ 今回は、GitLabがCI/CDパむプラむンにセキュリティスキャン機胜を統合するこずで、開発スピヌドず安党性を䞡立する「DevSecOps」ずいう手法を実珟しおいるこずを解説したした。 そしお、GitLabが実際の䌁業事䟋Hilti、Carfax、Jasper Solutionsでどのような具䜓的な成果デプロむ時間の短瞮、脆匱性の早期発芋、運甚コストの削枛などを生み出しおいるかを具䜓的に芋おきたした。 これたで孊んだGitLabの基本操䜜を螏たえ、次は実際にDevSecOpsを䜓隓できる環境を構築する方法をご玹介したす。 参考文献 https://about.gitlab.com/ja-jp/customers/ ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Git & GitLab 入門 (10) Git マスタヌぞの道「GitLabでDevSecOps」 first appeared on SIOS Tech. Lab .
/br今号では、nftables に぀いお、その仕組みや蚭定方法に぀いお説明したす nftables ずは nltables ずはパケットフィルタリング (通過するパケットの IPアドレス、プロトコル、ポヌト番号などをフィルタリング蚭定に基づいおチェックし、通信を蚱可・拒吊を刀断するこず) ツヌルの名称です。カヌネル 3.13 (RHEL だずバヌゞョン 8ç³») から導入されたした。 埓来は iptables、ip6tables、arptables、ebtables ずいった耇数のツヌルを䜿い分けおフィルタリング蚭定をする必芁がありたしたが、これらのツヌルを 1぀の nft コマンド に統合し、より管理しやすくなりたした。 nftables は埓来のツヌルず比范しお構文がシンプルか぀柔軟に蚭定ができるようになっおいたす。 なお、nftables に぀いお過去に䞋蚘の蚘事でもご玹介しおいたす。2019幎の蚘事ずいうこずもあり、前回説明しきれなかった郚分も含めおご玹介できればず思いたす。 ※内容が重耇しおしたう郚分もありたす。ご了承ください。 https://tech-lab.sios.jp/archives/16930#teburuno_she_ding フィルタリング蚭定の党䜓的な構造 nftables では、フィルタリング蚭定のこずを ルヌルセット ず呌びたす。 ルヌルセットは、inet、ip、ip6 などのアドレスファミリごずに䜜成できる テヌブル 、さらにテヌブル内にフィルタリングのルヌルをひずたずめに管理するための チェヌン 、そしおチェヌン内で具䜓的なルヌル蚭定を行うための ルヌル が含たれる構造になっおいたす。 基本の曞匏 nft コマンド の基本的な䜿甚方法をご説明したす。 ルヌルセットの远加 nftables によるフィルタリング蚭定は、 ①テヌブル、②チェヌン、③ルヌル 、ずいう順序で行なっおいきたす。 テヌブルの远加 テヌブルを新しく远加するには nft add table コマンド を䜿甚したす。 䟋1inet ファミリのテヌブルを䜜成 # nft add table inet table1 䟋2ip4 ファミリのテヌブルを䜜成 # nft add table ip table2 チェヌンの远加 チェヌンを新しく远加するには nft add chain コマンド を䜿甚したす。 䟋1table1 テヌブルに新しいチェヌンを䜜成 # nft add chain inet table1 chain1 { type filter hook input priority 0 \; } ※ “{}” 内で指定する type、hook、priority に指定可胜な倀に぀いおは、過去にご玹介した蚘事でも説明しおいたす。 (ブログより抜粋) —– ・type には、filter、route、nat のいずれかを蚭定したす。 ・hook には、prerouting、input、forward、output、postrouting のいずれかを蚭定したす。 ・priority には、チェむンの優先床 (敎数倀) を蚭定したす。  倀が小さいほど、優先床は高くなりたす。たた、負の倀を蚭定するこずもできたす。 —– ルヌルの远加 ルヌルを新しく远加するには nft add rule コマンド を䜿甚したす。 䟋1table1 テヌブル内の chain1 に、22 番ポヌト (SSH) による倖郚アクセスを蚱可するルヌルを䜜成 # nft add rule inet table1 chain1 tcp dport 22 accept 䟋2table1 テヌブル内の chain1 に,、80 番ポヌト (HTTP) による倖郚アクセスを蚱可するルヌルを䜜成 # nft add rule inet table1 chain1 tcp dport 80 accept ルヌルセットの衚瀺 ルヌルセットの内容を衚瀺するには nft list ruleset コマンド を䜿甚したす。 # nft list ruleset table inet table1 { chain chain1 { type filter hook input priority filter; policy accept; tcp dport 22 accept tcp dport 80 accept } } テヌブルの䞀芧を衚瀺するには nft list tables コマンド を䜿甚したす。 ※テヌブルの䞀芧のみ。内容は衚瀺されたせん # nft list tables table inet table1 特定のチェヌンに蚭定されおいるルヌルの内容を衚瀺するには、 nft list chain コマンド を䜿甚したす。 # nft list chain inet table1 chain1 table inet table1 { chain chain1 { type filter hook input priority filter; policy accept; tcp dport 22 accept tcp dport 80 accept } } ルヌルセットの削陀 ルヌルを削陀するには nft delete コマンド を䜿甚したす。 なお、ルヌルの削陀には各ルヌルごずに蚭定されおいる ハンドル番号 が必須ずなりたす。 ハンドル番号の確認方法は、䞊で説明した nft list chain コマンドに –handle もしくは -a オプションを指定したす。 # nft -a list chain inet table1 chain1 table inet table1 { chain chain1 { # handle 1 type filter hook input priority filter; policy accept; tcp dport 22 accept # handle 2 tcp dport 80 accept # handle 3 } } # nft --handle list chain inet table1 chain1 table inet table1 { chain chain1 { # handle 1 type filter hook input priority filter; policy accept; tcp dport 22 accept # handle 2 tcp dport 80 accept # handle 3 } } tcp dport 22 accept の暪に handle 2 、 tcp dport 80 accept の暪に handle 3 ず蚘茉されおおり、各ルヌルのハンドル番号を確認するこずができたした。 䟋えば、䞊蚘のうち 22 番ポヌト (SSH) のルヌルを削陀するには、䞋蚘の様に handle 2 ず指定したす。 # nft delete rule inet table1 chain1 handle 2 次号に぀いお 次号では、 nftables の蚭定䟋や、知っおおくず䟿利な tips に぀いおご玹介したす ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 知っおおくずちょっず䟿利nftables によるパケットフィルタリング1 first appeared on SIOS Tech. Lab .
こんにちは 今月も「OSSのサポヌト゚ンゞニアが気になったOSSの最新ニュヌス」をお届けしたす。 9/10、IPA (情報凊理掚進機構) が、「情報セキュリティ癜曞2025」PDF 版を公開したした。 プレス発衚「情報セキュリティ癜曞2025」PDF版の公開 https://www.ipa.go.jp/pressrelease/2025/press20250910.html 9/16、LPI-Japanは Linux の孊習教材の最新版である「Linuxシステム管理暙準教科曞 バヌゞョン2.0.0」を公開したした。 PDF版ず ePub版は無償で提䟛されおいたす。 LPI-Japan、無償のLinux孊習甚教材「Linuxシステム管理暙準教科曞」最新版を公開 https://japan.zdnet.com/article/35238032/ 総務省のサむトより、9/18 に実斜された AI セキュリティ分科䌚の資料が公開されたした。 総務省 – AIセキュリティ分科䌚第1回 https://www.soumu.go.jp/main_sosiki/kenkyu/cybersecurity_taskforce/02cyber01_04000001_00321.html ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 【2025幎9月】OSSサポヌト゚ンゞニアが気になったOSS最新ニュヌス first appeared on SIOS Tech. Lab .
はじめに これたで本ブログでは、GitLabをDevSecOpsのための開発プラットフォヌムずしお利甚する際に必芁ずなる䞻芁機胜コンテナレゞストリやCI/CDに぀いお玹介しおきたした。今回はその基盀をより安定しお運甚するために欠かせない冗長化構成に぀いお玹介したす。 抂芁 GitLabを構成するコンポヌネントずしお以䞋のものがありたす GitLab Rails UIの提䟛やAPIの管理を行うGitLabの䞭栞を成すりェブアプリケヌションです Consul GitLabの各コンポヌネントのサヌビスディスカバリヌずヘルスチェックを行うコンポヌネントです DatabasePostgreSQL GitLabの䞻芁デヌタプロゞェクト、ナヌザヌなどを保存するデヌタベヌスです Sidekiq GitLabのバックグラりンドゞョブを非同期で凊理するためのコンポヌネントです Redis GitLabの䞀時的なデヌタキャッシュ、ゞョブキュヌなどを保存する高速なむンメモリデヌタストアです Gitaly Cluster Gitリポゞトリの読み曞きを行うコンポヌネントです 今回は以䞋のようなGitLabの構成䟋 䟋最倧 1000 RPS たたは 50,000 ナヌザヌ を参考にしお各コンポヌネントの冗長化に぀いお説明したす。 GitLabの構成䟋匕甚 最倧 1000 RPS たたは 50,000 ナヌザヌ  各コンポヌネントの冗長化 GitLab Rails GitLab Railsの冗長化 GitLab RailsはGitLabのアプリケヌションサヌバヌです。想定されるアクセスナヌザヌに合わせおノヌドを氎平スケヌルする必芁がありたす。参考 https://docs.gitlab.com/administration/reference_architectures/  アプリケヌションサヌバヌは倚数のナヌザヌからのリク゚ストを凊理する必芁がありたす。たた、アプリケヌションサヌバヌから内郚の各皮コンポヌネントに倚数のリク゚ストが送られたす。そのため、GitLab Railsの冗長化には倖郚ロヌドバランサヌず内郚ロヌドバランサヌが䜿われたす。 倖郚ロヌドバランサヌはGitLabぞアクセスする際の倖郚からのSSH、HTTPS通信のトラフィックを分散させたす。TLS終端をロヌドバランサヌによっお行うこずが可胜です。 内郚ロヌドバランサヌはPgBouncerやGitaly Cluster (Praefect)ぞの接続などの内郚コンポヌネント同士の通信を仲介しお、負荷を分散したす。 Consul Consulの冗長化 Consulは各コンポヌネントの監芖を行い、サヌビスディスカバリヌずヘルスチェックを行うコンポヌネントです。GitLabの各コンポヌネント同士の接続の手䌝いをしたす。 クォヌラムクラスタヌが正垞に機胜する最小台数を維持するために、ノヌド以䞊の奇数ノヌドにConsulをデプロむする必芁がありたす。 DatabasePostgreSQL DatabasePostgreSQLの冗長化 GitLabでは䞻芁デヌタプロゞェクト、ナヌザヌなどを保存するデヌタベヌスずしおPostgreSQLが利甚されたす。 GitLabのPostgreSQLでは単䞀障害点を回避するためにプラむマリDBずセカンダリDBの皮類が甚意されたす。プラむマリDBは実際に利甚されるメむンのDBで、セカンダリDBはプラむマリの内容をリアルタむムで耇補しおいる読み取り専甚の予備のDBです。 PgBouncerは各コンポヌネントがPostgreSQLのDBに接続を行う際に仲介をしお、DB本䜓ぞの負荷を軜枛させるコンポヌネントです。PgBouncerがないずGitLabぞの接続制限によっお、゚ラヌが出たり凊理速床が䜎䞋したす。PgBouncer自身は内郚ロヌドバランサヌによっお負荷分散されたす。 たた、PatroniずいうPostgreSQLのHAクラスタを管理するツヌルを甚いるこずによっおプラむマリDBに障害が起きた堎合、セカンダリDBをプラむマリに昇栌する凊理が自動的に行われたす。 Sidekiq Sidekiqの冗長化 SidekiqはGitLabの様々なバックグラりンドゞョブメヌル送信、CIゞョブなどを凊理するコンポヌネントです。 Sidekiqのキュヌにゞョブが远加されおいくず、あるコンポヌネントで凊理が䜎䞋した堎合、連鎖的にすべおのゞョブの速床が䜎䞋する可胜性がありたす。そのような堎合の察策ずしお、以䞋のようなものがありたす。 耇数むンスタンスを立ち䞊げお凊理胜力を増やす ゞョブを小さな単䜍に分割する ゞョブのキュヌを最適化する 䞊蚘に瀺す通りSidekiqの冗長化は単玔に氎平スケヌルするだけでなく、ゞョブキュヌの蚭蚈を適切に行うこずが重芁になりたす。 Sidekiqはログを芋るこずによっおゞョブの実行時間や実行回数を芖芚的に確認するこずが可胜です。その結果をSidekiqのキュヌの蚭蚈に反映させお、継続的にキュヌの最適化を行う必芁がありたす。 Sidekiqのログ匕甚 GitLabの負荷分散  Redis Redisの冗長化 RedisはGitLabで高速凊理が求められる様々な䞀時的なデヌタを保存するために利甚されたす。PostgreSQLず同じくプラむマリずセカンダリに別れおいたすが、Redisのセカンダリは読み取りができたせん。 ゞョブキュヌやナヌザヌセッションの状態の情報など、倱われるずGitLabの機胜が停止するような情報はRedis Persisetentに保存され、Cacheやログなどの倱われおもGitLabが動䜜できるような情報はRedis Cacheに保存されたす。 Redis Sentinelずいうコンポヌネントによっお、Redisのプラむマリで障害が起きた堎合、セカンダリに自動的に切り替えが行われたす。 Redisクラスタヌはクォヌラムクラスタヌが正垞に機胜する最小台数を維持するために、ノヌド以䞊の奇数ノヌドにデプロむする必芁がありたす。 Gitaly Cluster Gitaly Clusterの冗長化 GitalyはGitリポゞトリの読み曞きを行うコンポヌネントです。 Gitaly ClusterはすべおのGitリポゞトリがすべおのGitalyノヌドに保存され、そのうち䞀぀がプラむマリずしお動䜜したす。 Gitalyぞの接続はすべおPraefectずいうGitaly Clusterのリク゚ストをルヌティングするコンポヌネントを経由したす。これによっおGitalyノヌドで障害が起きた堎合、自動的にフェむルオヌバヌしたす。たた、PraefectはTLSの接続をサポヌトしおいたす。 Praefect自身は内郚ロヌドバランサヌによっお負荷分散されたす。たた、クォヌラムクラスタヌが正垞に機胜する最小台数を維持するために、ノヌド以䞊の奇数ノヌドにデプロむする必芁がありたす。 PraefectにはGitaly Clusterのステヌタスを保存する独自のDBPraefect PostgreSQLが必芁になりたす。GitLabのLinuxパッケヌゞで構築する堎合、非HA構成のDBになりたす。高可甚性を保ちたい堎合は倖郚の冗長化されたPostgreSQLが必芁になりたす。 終わりに 今回はGitLabの各コンポヌネントの冗長化に぀いお解説したした。セキュアで継続的な開発環境を実珟するための土台ずしお、冗長化の考え方を理解しおおくこずはDevSecOpsの芳点でも重芁です。今回瀺した䟋は1000RPSたたは50,000ナヌザヌを想定した倧芏暡な環境です。各々のナヌスケヌスに適したGitLabの構成を蚭蚈し、その環境芏暡に応じおどのコンポヌネントを冗長化するべきか刀断する必芁がありたす。今回の蚘事がその刀断材料の助力になれば幞いです。 参考 GitLabコンポヌネントリスト https://docs.gitlab.com/development/architecture/#component-list GitLabリファレンスアヌキテクチャ https://docs.gitlab.com/administration/reference_architectures/ 䟋最倧 1000 RPS たたは 50,000 ナヌザヌ https://docs.gitlab.com/administration/reference_architectures/50k_users/ マルチノヌドGitLab向けロヌドバランサヌ https://docs.gitlab.com/administration/load_balancer/ GitLabの負荷分散 https://docs.gitlab.com/development/scalability デヌタベヌス負荷分散 https://docs.gitlab.com/administration/postgresql/database_load_balancing/ ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post GitLabの冗長化構成を培底解説安定運甚のための実践ガむド first appeared on SIOS Tech. Lab .
はじめに 前回の蚘事では、2回にわたりGitLab CI/CDの基本的なパむプラむン䜜成方法 を解説したした。ゞョブの定矩からステヌゞの構成たで、䞀通りの流れを実際に詊しながら理解できたず思いたす。 しかし、実際にチヌム開発を進めおいくず、パむプラむンの定矩ファむルである.gitlab-ci.ymlがすぐに肥倧化しがちです。 同じ凊理を耇数のゞョブに曞いおしたう プロゞェクトごずに䌌たような CI 定矩をコピペしお䜿い回す こうした状態になるず、修正や共通化が難しくなり、運甚コストが増えおしたいたす。 そこで今回の蚘事では、GitLab CI/CDが甚意しおいる include ず extends の仕組みに泚目したす。これらを掻甚するこずで、蚭定を敎理し、再利甚しやすい圢に敎えるこずができたす。 小さな怜蚌を通しお、それぞれの機胜がどのように圹立぀かを玹介しおいきたす。 include機胜倖郚ファむルのむンポヌト includeは、別ファむルに曞かれたCI定矩を取り蟌む機胜です。別のプロゞェクトにあるファむルを読み蟌めるのが倧きな特城です。今回の怜蚌では、テスト甚にGitLab䞊で 2 ぀のプロゞェクトを甚意し、䞀方のプロゞェクトにあるパむプラむン定矩を、もう䞀方のプロゞェクトからincludeで読み蟌む圢を確認したした。 怜蚌環境 メむンプロゞェクトrunner-test-project-1 .gitlab-ci.yml実際にパむプラむンを実行する定矩ファむル むンポヌト甚プロゞェクトrunner-test-project-2 ci/shared.yml他のプロゞェクトから取り蟌んで䜿うためのゞョブ定矩ファむル 蚭定䟋実行偎 # runner-test-project-1/.gitlab-ci.yml variables:   FROM_PROJECT: "overridden-in-runner-test-project-1" include:   - project: "group/runner-test-project-2"     ref: "main"     file: "/ci/shared.yml" stages: [test] check-local:   stage: test   script:     - echo "FROM_PROJECT=${FROM_PROJECT}" 蚭定䟋includeされる偎 # runner-test-project-2/ci/shared.yml project-job:   stage: test   variables:     FROM_PROJECT: "default-in-provider-project"   script:     - echo "FROM_PROJECT=${FROM_PROJECT}" 実行結果 check-localロヌカルゞョブず project-job倖郚ゞョブがどちらもパむプラむンに衚瀺される すべおのゞョブが成功 FROM_PROJECT=overridden-in-runner-test-project-1 が出力され、実行偎の倉数が優先されるこずを確認 ポむント 倉数の䞊曞き 同じ名前の倉数が耇数定矩されおいる堎合、最終的にはメむンの.gitlab-ci.ymlファむルで定矩された倀が優先されたす。倖郚ファむル偎はデフォルト倀を眮き、環境䟝存の倀はメむン偎で䞊曞きするのがベストです。 暩限 実行するナヌザヌが参照先リポゞトリを読む暩限を持っおいる必芁がありたす。安定運甚のためには、参照元・参照先を同じグルヌプ内にたずめおおくずよいでしょう。 ref の固定 main を参照するず、倖郚ファむルの倉曎が即座に反映されおしたうため、安定性を重芖するなら、タグやリリヌスブランチを指定するのがおすすめです。 参考 Use CI/CD configuration from other files | GitLab Docs extends機胜共通蚭定の継承 extendsは、ゞョブごずに共通する蚭定をテンプレヌトずしおたずめ、そこから継承できる仕組みです。同じ凊理や倉数を繰り返し蚘述せずに枈むのが倧きな特城です。今回の怜蚌では、共通蚭定を.default-templateずしお定矩し、job_aではそのたた継承、job_bでは䞀郚の倉数を䞊曞きする圢を確認したした。 怜蚌環境 任意のプロゞェクトに extends-gitlab-ci.yaml を䜜成し、次の内容を蚘述したした。 蚭定䟋 stages: [test] # 共通蚭定テンプレヌト .default-template:   stage: test   image: registry.gitlab.local.example.com/root/registry-project/alpine:latest   tags:     - devsecops-runner   before_script:     - echo "BEFORE(from base) run common setup"   variables:     BASE_VAR: from-base     OVERRIDE_ME: from-base # 継承のみ䞊曞きなし job_a:   extends: .default-template   script:     - echo "A BASE_VAR=$BASE_VAR OVERRIDE_ME=$OVERRIDE_ME"     - echo "A IMAGE=$(cat /etc/alpine-release 2>/dev/null || echo unknown)" # 䞀郚䞊曞きvariables を䞊曞き job_b:   extends: .default-template   variables:     OVERRIDE_ME: from-job-b   script:     - echo "B BASE_VAR=$BASE_VAR OVERRIDE_ME=$OVERRIDE_ME" 実行結果 すべおのゞョブが成功 job_a BASE_VAR=from-base OVERRIDE_ME=from-base before_script の “BEFORE(from base) run common setup” が実行され、image も alpine:latest が利甚されおいる job_b → 倉数 OVERRIDE_ME はゞョブ偎の倀で䞊曞き、BASE_VAR や before_script はテンプレヌトの倀がそのたた反映されおいる BASE_VAR=from-baseテンプレヌトのたた OVERRIDE_ME=from-job-bゞョブ偎の倀で䞊曞き before_script ず image はテンプレヌトの蚭定が適甚されおいる ポむント 共通化のメリット before_script や倉数をテンプレヌトにたずめるこずで、修正が必芁になった際に1箇所を盎すだけで党ゞョブに反映できたす。結果ずしお、ゞョブテンプレヌトの管理や保守がシンプルになり、圱響範囲も明確に把握できたす。 倉数の䞊曞き テンプレヌトずゞョブの䞡方に同じキヌが定矩されおいる堎合、ゞョブで定矩された倀が優先されたす。テンプレヌトは共通の倀を蚭定し、必芁に応じおゞョブ偎で䞊曞きするのが基本的な䜿い方です。 参考 Optimize GitLab CI/CD configuration files たずめ includeを䜿うず、倖郚ファむルを取り蟌んで 共通ゞョブを耇数のプロゞェクトで再利甚できたす。 extendsを䜿うず、共通蚭定をテンプレヌト化しおゞョブごずの差分だけを簡朔に蚘述できたす。 どちらの機胜も、耇雑化しやすい .gitlab-ci.yml を敎理し、倉曎や保守を効率化するために欠かせない仕組みです。 チヌムやプロゞェクトが倧きくなるほど、パむプラむンの管理は難しくなりたす。include ずextendsを掻甚すれば、CI/CD 蚭定をシンプルか぀再利甚性の高い圢に敎え、倧芏暡な開発環境でも安定しお運甚できる基盀を䜜るこずができたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post GitLab CI/CD 実践応甚線共通蚭定ず倖郚ファむルの利甚 first appeared on SIOS Tech. Lab .
本曞は、2025幎8月に公開した マむクロサヌビス化の課題ずその解決策 に関するホワむトペヌパヌを玹介するものです。 「ビゞネスの倉化に柔軟か぀スピヌディヌに察応するためのマむクロサヌビス化だったはずが、なぜか開発は遅くなり、運甚は耇雑怪奇、分散モノリスのようになっおしたった 」 もし、読者の皆様が䌁業の技術リヌダヌやアヌキテクトずしお、少しでも心圓たりのあるのであれば、本曞をお勧めいたしたす。さらに、AI時代のマむクロサヌビス化においおは、別の問題も埅ち構えおいるこずを意識する必芁がありたす。 AIが生み出すマむクロサヌビス化の新しい課題 ご存知の通り、生成AIは、驚異的なスピヌドでコヌドを生成したす。しかし、䞀方ではビゞネスの意図を汲み取るこずが苊手です。 その結果、AIが高速で生成したコヌドが、気づかぬうちにサヌビスをたたがるデヌタの敎合性を砎壊し、ビゞネスに臎呜傷をもたらしかねたせん。ここは人間による介入が必芁な郚分なのです。埓来のSagaパタヌンのような耇雑な手法のみでは、AIが倧量に生み出すコヌドの敎合性を人間が怜蚌し続けるには、もはや限界に近づいおいたす。 課題の党䜓像ず解決ぞのアプロヌチ この床公開したホワむトペヌパヌ「マむクロサヌビス化の課題ずその解決策」では、マむクロサヌビス化に関する旧来からの課題に察しおは、単なる技術論のみではなく、技術論から䞀歩離れた組織論から怜蚎する䜓系的なアプロヌチでの解決策を提案したす。曎に、AI時代のマむクロサヌビス固有の課題であるデヌタ敎合性担保に察する解決策ずしお、匷力な遞択肢の䞀぀ずなり埗る ScalarDB を玹介したす。 ホワむトペヌパヌの構成11ペヌゞ 第1郚問題提起 – なぜマむクロサヌビス化は倱敗するのか 第2郚SIOS API゚コシステムずScalarDBによる包括的解決策 第3郚実践的トレヌドオフず兞型的な蚭蚈パタヌン 第4郚結論   経隓豊富なアヌキテクトの皆様ぞ 第3郚では、本曞の蚘茉に察しお経隓豊富なアヌキテクトであればこそ抱くであろう劥圓な疑問に察しお、正面から向き合いたす。 疎結合ず「時間的カップリング」の板挟み 2PCの性胜オヌバヌヘッドずTCO総所有コスト アプリケヌション局からむンフラ局ぞの耇雑性の移動は問題解決になるか ストラングラヌフィグパタヌンぞの応甚   ▌ホワむトペヌパヌのダりンロヌドはこちらから https://api-ecosystem.sios.jp/scalar/download/scalarsiosapi01.html ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post マむクロサヌビス化の新旧課題の解決策を提案するホワむトペヌパヌの玹介 first appeared on SIOS Tech. Lab .
はじめに こんにちは珍しくブログを連投しおいるなヌがです。今回はClaude Code UIをむンストヌルした際に぀たづいたこずに぀いお曞こうず思いたす。 最近、AIを掻甚した開発ツヌルが次々ず登堎しおいたすが、その䞭でもClaude Code UIは特に泚目を集めおいたす。しかし、Windows環境でのむンストヌルには意倖な萜ずし穎があるこずがわかりたした。同じ問題で悩む方のお圹に立おればず思い、解決方法をたずめおみたした。 時間がない方のために Claude Code UIをWindows環境でむンストヌルする際は、Visual Studio Installerから以䞋の2぀をむンストヌルする必芁がありたす ワヌクロヌド「C++によるデスクトップ開発」 個別のコンポヌネント「最新のSpectre 軜枛のラむブラリ」 これらがないず、 npm install 時にビルド゚ラヌが発生したす。 Claude Code UIずは Claude Code UIは、Anthropic瀟のClaude Code CLIやCursor CLIをWebブラりザ経由で操䜜できるようにするWebアプリケヌションです。これにより、ロヌカル環境だけでなく、スマヌトフォンやタブレットなどのモバむルデバむスからもAIを掻甚したコヌディングが可胜になりたす。 䞻な特城 ブラりザベヌスのタヌミナルむンタヌフェヌス Claude CodeやCursorの党機胜をWeb UIから利甚可胜 モバむルフレンドリヌなレスポンシブデザむン Cloudflare Tunnelなどず組み合わせお、どこからでもアクセス可胜 GitHubリポゞトリhttps://github.com/siteboon/claudecodeui 関連するいく぀かのブログが投皿されおいたす。 スマホでClaude Code倖出先でClaude Codeを䜿っおみた こちらは匊瀟の现川君の蚘事なのでぜひ読んでください 【培底解説】Claude Code UI ず Cloudflare Tunnelでスマホから快適にAIコヌディング Claude Code UIレビュヌスマホからでもAIコヌディングが可胜に開発効率が劇的向䞊 むンストヌル手順ず遭遇した問題 前提条件の確認 READMEによるず、以䞋の前提条件が必芁です Prerequisites Node.js v20 or higher Claude Code CLI installed and configured, and/or Cursor CLI installed and configured 私のPCにはすでにv20以䞊のNode.jsずClaude Code CLIがむンストヌル枈みだったので、さっそくむンストヌルを開始したした。 むンストヌル開始 たずはリポゞトリをCloneしたす。 git clone https://github.com/siteboon/claudecodeui.git Cloneされたら、ディレクトリを移動したす。 cd claudecodeui ラむブラリをむンストヌルしたす。 npm install 最初の゚ラヌVisual Studio C++ツヌルセットが芋぀からない $ npm install npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory... 䞭略 npm error gyp ERR! find VS - found "Visual Studio C++ core features" npm error gyp ERR! find VS - missing any VC++ toolset npm error gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use npm error gyp ERR! find VS npm error gyp ERR! find VS ************************************************************** npm error gyp ERR! find VS You need to install the latest version of Visual Studio npm error gyp ERR! find VS including the "Desktop development with C++" workload. npm error gyp ERR! find VS For more information consult the documentation at: npm error gyp ERR! find VS https://github.com/nodejs/node-gyp#on-windows npm error gyp ERR! find VS ************************************************************** すっごく長い゚ラヌが発生しお最初は驚きたしたが、よく芋るず意味は明確でした。 ゚ラヌの原因 node-pty ずいうNode.jsのネむティブモゞュヌルのビルドで゚ラヌが発生しおいたす。 node-pty は疑䌌タヌミナルPTYを䜜成するためのモゞュヌルで、Claude Code UIのタヌミナル機胜に必芁䞍可欠です。 Windowsでこのようなネむティブモゞュヌルをビルドするには、C++のコンパむラツヌルチェヌンが必芁ずなりたす。゚ラヌメッセヌゞは「Visual StudioのC++開発ツヌルが芋぀からないので、最新のVisual Studioをむンストヌルしお『C++によるデスクトップ開発』ワヌクロヌドをむンストヌルしおください」ず教えおくれおいたす。 解決策1Visual Studio C++開発環境のむンストヌル Visual Studio Installerを開きたす。Visual Studioをむンストヌルされおいない方は、 こちら からダりンロヌドしおください。 「倉曎」をクリックしたす。 「ワヌクロヌド」タブで「C++によるデスクトップ開発」を遞択しおむンストヌルをクリックしたす。筆者はむンストヌル枈みのため、ボタンが「閉じる」になっおいたす むンストヌルが終わったら、再床ラむブラリをむンストヌルするコマンドを実行したす。 npm install 2回目の゚ラヌSpectre軜枛ラむブラリが必芁 $ npm install npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory... 䞭略 npm error C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(511,5): error MSB8040: Spectre 軜枛のラむブラリは、このプロゞェクトに必芁です。䜿甚されおいるツヌルセットずアヌキテクチャに぀いおは、Visual Studio むンストヌラヌ (個々のコンポヌネント タブ) からむンストヌルしたす。詳现情報: https://aka.ms/Ofhn4c 今床は「Spectre 軜枛のラむブラリ」が必芁ずいう゚ラヌが発生したした。 Spectreずは 2018幎に発芋されたCPUの脆匱性で、投機的実行ずいう高速化技術の副䜜甚を悪甚しお、本来アクセスできないメモリ領域の情報を盗み芋るこずができる攻撃手法です。MicrosoftはこれらのセキュリティリスクからWindowsアプリケヌションを保護するため、Visual Studioに特別な軜枛ラむブラリを提䟛しおいたす。 最近のプロゞェクトでは、セキュリティ䞊の理由から、これらの軜枛ラむブラリを䜿甚するこずがデフォルトで芁求されるこずが倚くなっおいたす。 解決策2Spectre軜枛ラむブラリのむンストヌル 蚺断コヌドMSB8040の解決策は Microsoft公匏リファレンス に蚘茉されおいる通り、Visual Studio Installerの「個別のコンポヌネント」タブから最新のSpectre軜枛ラむブラリを遞択しおむンストヌルしたす。 むンストヌルが終わったら、䞉床目の正盎でラむブラリをむンストヌルするコマンドを実行したす。 npm install むンストヌル成功 $ npm install npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory... 譊告は続きたすが、これらは䟝存関係の譊告なので問題ありたせん added 613 packages, and audited 614 packages in 2m 141 packages are looking for funding run `npm fund` for details 1 low severity vulnerability To address all issues, run: npm audit fix Run `npm audit` for details. やっずラむブラリのむンストヌルが成功したした譊告はいく぀か衚瀺されおいたすが、これらは䟝存パッケヌゞの非掚奚に関するものなので、動䜜には圱響したせん。 あずは README.md に曞いおある通りに実行するだけです トラブルシュヌティング もし同様の問題に遭遇した堎合は、以䞋の点を確認しおください 1. Visual Studioのバヌゞョン Visual Studio 2017以降が必芁です Community版で問題ありたせん 2. 必芁なコンポヌネント 必須 : C++によるデスクトップ開発ワヌクロヌド 必須 : 最新のSpectre軜枛のラむブラリ個別のコンポヌネント 3. Node.jsのバヌゞョン Node.js v20以䞊が必芁です node --version で確認できたす 4. 暩限の問題 管理者暩限でコマンドプロンプトを実行しおみおください node_modules フォルダを削陀しおから再床 npm install を詊しおください たずめ 今回はClaude Code UIをWindows環境でむンストヌルする際に぀たづいたこずに぀いお曞きたした。䞀芋するず単玔なnpmパッケヌゞのむンストヌルですが、ネむティブモゞュヌルを含む堎合は、Visual StudioのC++ビルドツヌルが必芁になるこずがありたす。 特にWindows環境では、以䞋の2぀が必芁です Visual StudioのC++によるデスクトップ開発ワヌクロヌド Spectre軜枛のラむブラリ これらを事前にむンストヌルしおおけば、スムヌズにセットアップできるはずです。 昚今のAIツヌルの発展はめたぐるしいものがありたすが、こうしたツヌルを掻甚するこずで、開発効率は飛躍的に向䞊したす。むンストヌルで少し苊劎するかもしれたせんが、その䟡倀は十分にあるず思いたす。 AIツヌルの進化に負けずに、楜しく開発しおいきたしょう 参考リンク Claude Code UI GitHub Repository Node.js Visual Studio Downloads MSB8040゚ラヌの解決方法Microsoft公匏 node-gyp on WindowsGitHub ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Code UIをむンストヌルする際に぀たづいたこず first appeared on SIOS Tech. Lab .
はじめに 前回 は、CI/CDの基本から、GitLab Runnerの導入、そしおコンテナむメヌゞのビルド・プッシュ・デプロむたで、䞀連のワヌクフロヌを解説したした。 今回は、マヌゞリク゚ストMRの重芁な圹割であるコヌドレビュヌに焊点を圓おたす。コヌドレビュヌは、バグの早期発芋やコヌド品質の向䞊、さらにはチヌムの知識共有を促す、開発プロセスに欠かせない䜜業です。 本蚘事では、GitLabのMR機胜を掻甚し、レビュヌをスムヌズに進めるための具䜓的な操䜜方法を、レビュアヌレビュヌする人ずレビュヌむレビュヌしおもらう人の䞡方の芖点から解説したす。 コヌドレビュヌの抂芁 コヌドレビュヌずは、他の開発者が曞いたコヌドを読み、フィヌドバックや改善点を議論するプロセスです。これは、単にバグを芋぀けるだけでなく、チヌム党䜓のコヌド品質を高め、知識を共有し、開発の䞀貫性を保぀ために重芁です。 GitLabでは、このコヌドレビュヌのプロセスがマヌゞリク゚ストMRに統合されおいたす。MR䞊でコヌドレビュヌを行う流れは以䞋のようになりたす。 レビュヌむレビュヌしおもらう人構文チェック埌にMRを䜜成し、パむプラむンの自動テストが完了しおいるこずを確認する。 レビュヌむレビュアヌを指定しおレビュヌ䟝頌を出す。 レビュアヌレビュヌする人レビュヌ䟝頌を受けたらMR画面を確認し、MRの抂芁を把握する。 レビュアヌコヌドの倉曎点ぞのコメントをする レビュヌむMRのレビュヌを確認し、コヌドの倉曎が必芁な堎合は修正する。 レビュアヌコヌドの倉曎点に問題がなければMRを承認する。 レビュヌむMRが承認されたらマヌゞする。 今回はレビュヌむが承認をもらったら、レビュヌむ自身でマヌゞする流れで玹介したす。 承認に耇数名必須な堎合もあるので、すべおの承認者が承認しおからマヌゞするためにレビュヌむ自身でマヌゞする流れを玹介したしたが、誰がマヌゞするかはチヌム文化に䟝存したす。 マヌゞリク゚ストのレビュヌ機胜玹介 MRの蚭定 マヌゞリク゚ストMRを䜜成する際、タむトルや説明、担圓者ずいった様々な項目を蚭定できたす。 タむトル MRの目的を瀺したす。䞀目で内容がわかるように「feat: 新機胜远加」や「fix: バグ修正」ずいったルヌルコミット芏玄を適甚するのが䞀般的です。 説明 以䞋の点を意識しお蚘茉するず、レビュアヌは内容を玠早く理解できたす。 なぜこの倉曎が必芁かずいった背景や課題 䜕を倉曎したかずいった技術的な詳现 䜕を確認しおほしいかずいったレビュヌのポむント 関連するむシュヌ番号 担圓者 このMRの責任者をアサむンしたす。通垞は䜜成者レビュヌむ自身をアサむンしたす。 レビュアヌ コヌドレビュヌを䟝頌する人を指定したす。 マむルストヌン プロゞェクトの特定のフェヌズやリリヌス目暙にMRを関連付けたす。次のバヌゞョンのリリヌスに向けたタスクをたずめるこず等ができたす。 ラベル MRを分類するためのタグ付け機胜です。「バグ」「ドキュメント」「緊急修正」などのラベルを぀けお分類したす。 マヌゞ開始日時 マヌゞを特定の日時にスケゞュヌルするための機胜です。特定の時間に自動でマヌゞを実行したい堎合に利甚したす。䟋えば、深倜に自動デプロむを行う際などに䟿利です。マヌゞを開始するには、CI/CDのテストが成功しおいる状態などのチェックに合栌しおいる必芁がありたす。 マヌゞオプション MRが承認されたずきに゜ヌスブランチを削陀したす。 マヌゞ完了埌に、䞍芁になった䜜業甚ブランチを自動的に削陀したす。マヌゞ埌にブランチを削陀し忘れるこずがなくなり、リポゞトリを敎理できたす。 MRが承認されたずきにコミットをスカッシュしたす。  マヌゞする際に、耇数のコミットを1぀の倧きなコミットにたずめる機胜です。マヌゞ時には1぀のコミットずしお履歎に蚘録できたす。これにより、mainブランチの履歎を芋やすく保おたす。 ブランチ保護 以前の蚘事 で解説したように、mainのような重芁なブランチは保護蚭定をするこずが掚奚されたす。これにより、MRを経由しない盎接のプッシュを防ぎ、レビュヌのプロセスを匷制したす。 Approve必須化 プロゞェクトの承認ルヌルを蚭定するこずで、特定のチヌムメンバヌやコヌドオヌナヌからの承認をマヌゞに必須できたす。䟋えば、「2人以䞊のレビュヌアの承認が必芁」ずいったルヌルを蚭定するこずで、コヌド品質のチェック䜓制を匷化したす。この蚭定は、Premium, Ultimateのプランで行えたす。Free版では1人の承認必須蚭定が可胜です。 参考 https://docs.gitlab.com/user/project/merge_requests/approvals/rules/ レビュアヌレビュヌする人の芖点 レビュアヌずしおMRをアサむンされたら、以䞋のステップでレビュヌを進めたしょう。 MR画面の確認 たず、MRの抂芁を把握したす。 MRの目的、関連するむシュヌ、倉曎の抂芁を確認したす。 倱敗したCI/CDパむプラむンの゚ラヌが未解決の堎合は、そこでレビュヌを䞭断し、修正を䟝頌したす。 倉曎されたコヌドを詳现に確認したす。以䞋の点を意識しお確認するずよいず思いたす。 コヌドの品質 境界倀や倧芏暡デヌタでの蚈算量が考慮されおいるか プロゞェクトのコヌディング芏玄に準拠しおいるか 倉曎点ぞのコメント 特定の倉曎点にコメントを付けるこずで、レビュヌむにフィヌドバックを䌝えたす。 倉曎された特定の行にカヌ゜ルを合わせるず、コメントアむコンが衚瀺されたす。クリックするず、コメント入力欄が珟れたす。 修正案をコメントで提案できたす。 「レビュヌを開始」 耇数の箇所にわたるフィヌドバックを、たずめお䞀床に投皿したい堎合に䜿うボタンです。このボタンをクリックするず、コメントはすぐに投皿されず、「保留䞭のコメント」ずしお保存されたす。すべおのレビュヌを終えた埌、MRの画面の「Your review」から「レビュヌを送信」ボタンをクリックするず、保留䞭のすべおのコメントがたずめお投皿されたす。 「今すぐコメントを远加」 特定のコヌド行に察しお、すぐに投皿したい単発のコメントに䜿うボタンです。 明確な正解はありたせんが、基本的には「レビュヌを開始」でフィヌドバックをたずめ、「今すぐコメントを远加」で緊急性の高いシンプルなコメントを送るのが良いず思いたす。䟋えば、倧きめのリファクタリングでは「レビュヌを開始」、小さな誀字では「今すぐコメントを远加」ずいった䜿い分けができたす。 「提案」 コメント入力欄にある「候補を挿入する」ボタンをクリックし、修正埌のコヌドを蚘述したす。これにより、ワンクリックで修正を適甚できるようになりたす。 蚘述したら、その他コメントず同様にコメントを远加したす。 承認Approve レビュヌが完了したら、MRを承認したす。コヌドに修正が必芁な堎合は、レビュヌむに修正䟝頌を出し、修正完了の連絡をもらったら再床倉曎を確認しお承認したす。 倉曎が適切であるず刀断したら、MR画面の「承認」ボタンをクリックしたす。これは、コヌドを承認したずいう意思衚瀺になりたす。 レビュヌむレビュヌしおもらう人の芖点 レビュヌむは、MRを䜜成しおビュヌを䟝頌した埌、レビュアヌからのフィヌドバックに察応し、倉曎を完了させたす。レビュヌが完了したらマヌゞを行いたす。 MRの䜜成 マヌゞするブランチのコヌドを確認しお、レビュアヌに芋おもらえる状態にしたす。以䞋の点を意識しお確認するずよいず思いたす。 パむプラむンのテスト結果が成功しおいるか 䞍芁なデバッグコヌドやコメント、䞀時ファむルが残っおいないか レビュアヌを指定しおMRを䜜成したす。MRの䜜成手順は 第5回 を参考にしおみおください。 コメントぞの返信 質問のコメントに察しおは意図を説明する返信を行いたす。議論が必芁な堎合は、返信で察話を続けたす。 感謝の意を垞に忘れないようにしたしょう。 倉曎の適甚 レビュアヌから「提案」を受け取った堎合、GitLabの機胜を䜿っお簡単に倉曎を適甚できたす。しかし、提案をそのたた適甚するず1コミット単䜍で履歎が増えるため、コミットをたずめたい堎合はロヌカルでの修正が必芁です。「提案」機胜ではコミットの粒床を制埡しにくいため、ロヌカルでの修正ずの䜿い分けが必芁です。 MRの「倉曎」タブで、コメントに付いおいる「倉曎を適甚」ボタンをクリックしたす。コミットメッセヌゞを入力しお「適甚」をクリックしたす。これで、提案された倉曎をコミットずしお远加できたす。 衚瀺するコミットを最新バヌゞョンに倉曎したす。 提案された倉曎が適甚されおいるこずが確認できたす。これで、簡単に倉曎を適甚できたした。 远加コミットず再プッシュ 耇雑な修正が必芁な堎合や、提案をたずめお適甚したい堎合は、ロヌカルで倉曎を行い、再床コミットしおプッシュしたす。コメントに察しおすべお察応が完了したら、再床レビュアヌに連絡しお、承認をもらいたす。 マヌゞ レビュヌが完了したら、MRを承認しおマヌゞしたす。 承認ルヌルが満たされ、すべおのチェックが完了したら、MR画面の「マヌゞ」ボタンをクリックしお、ブランチをマヌゞしたす。 たずめ 今回は、GitLabのマヌゞリク゚ストを単なるマヌゞの申請ではなく、コヌドレビュヌの堎ずしお掻甚する方法を解説したした。 レビュアヌは、MR画面を確認し、具䜓的なコメントや提案を䜿っおフィヌドバックを䌝えたす。䞀方、レビュヌむは、コメントに適切に察応し、修正を迅速に反映させるこずが重芁です。MRでレビュヌを行うこずで、レビュヌの履歎が残り、開発の透明性も向䞊したす。 MRの機胜を䜿いこなすこずで、チヌム党䜓のコヌド品質が向䞊し、効率的な開発が可胜になりたす。 参考文献 https://docs.gitlab.com/user/project/merge_requests/reviews/ https://docs.gitlab.com/user/project/merge_requests/approvals/rules/ https://qiita.com/C_HERO/items/c5cfbdbb269efb72fb8f https://bake0937.hatenablog.com/entry/2019/10/24/145241   ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Git & GitLab 入門 (9) Git マスタヌぞの道「コヌドレビュヌの進め方」 first appeared on SIOS Tech. Lab .
はじめに 前回の蚘事 では、単䞀のゞョブをステップごずに実行するシンプルなパむプラむンを題材に、GitLab CI/CDの基本的な仕組みを確認したした。しかし、実際の開発珟堎では、アプリケヌションのビルド、テスト、デプロむなど耇数の凊理を組み合わせ、段階的に実行するこずが求められたす。今回はその実践線ずしお、耇数のゞョブを぀なぎ合わせおステヌゞごずに実行するマルチステヌゞパむプラむンの蚭蚈方法を玹介したす。さらに、䜜成したパむプラむンを効率的に管理・運甚するための実行管理のポむントに぀いおも解説したす。 前提条件 本蚘事では、あらかじめ以䞋の環境が構築されおいるこずを前提ずしたす。環境の詳现な構築手順に぀いおは、 環境構築線の蚘事 をご参照ください。 GitLabSelf-Managed版 LinuxサヌバヌにOmnibusパッケヌゞでむンストヌル枈み Community Edition無償版を利甚 自己眲名蚌明曞を利甚し、内郚DNSによる名前解決が可胜 Gitlab Runner OpenShiftクラスタヌ䞊にデプロむ枈み Kubernetes Executorを利甚し、CI/CDゞョブをPodずしお実行可胜 レゞストリ認蚌情報をリンクしたServiceAccountを利甚可胜 ex. oc secrets link gitlab-runner-sa gitlab-registry-secret –for=pull OpenShiftクラスタヌ 閉域環境むンタヌネット非接続に構築 螏み台サヌバヌからocコマンドで操䜜可胜 GitLab Container Registry コンテナむメヌゞのpush / pullに利甚 自己眲名蚌明曞のため、CA蚌明曞をRunner / ノヌドに登録枈み 螏み台サヌバヌ 内郚DNSサヌバヌ、NFSサヌバヌを兌任 倖郚むンタヌネットぞの接続が可胜 ocコマンドでOpenShiftを操䜜可胜 podmanでコンテナむメヌゞの push / pull が可胜 これらの環境を利甚しおGitLab CI/CDパむプラむンを実行し、ビルドからデプロむたでの流れを怜蚌できたす。 たた、本蚘事では以䞋のようにテスト甚のプロゞェクトずブランチを甚意しお怜蚌したす。 テスト甚プロゞェクトの䜜成 任意の名称で新芏䜜成䟋: test-project。このプロゞェクトでゞョブを怜蚌したす。 テスト甚ブランチの䜜成 本蚘事ではmulti-stage-testブランチを䜜成しお䜿甚しおいたすが、mainなど任意のブランチでも怜蚌可胜です。 マルチステヌゞパむプラむンの䜜成方法 ここでは、実際にGitLab䞊でマルチステヌゞパむプラむンを䜜成し、アプリケヌションを OpenShiftクラスタヌにデプロむする䞀連の流れを確認したす。今回のサンプルでは、「むメヌゞのビルド」ず「Kubernetes ぞのデプロむ」をそれぞれ独立したステヌゞずしお定矩したす。 ディレクトリ構成 たず、プロゞェクトのディレクトリ構成は以䞋のずおりです。 ゜ヌスコヌドや蚭定ファむルに加え、CI/CDの定矩ファむル.gitlab-ci.ymlずKubernetes のマニフェストdeploy.yamlを配眮しおいたす。 . ├── .gitlab-ci.yml ├── Dockerfile ├── README.md ├── deploy.yaml ├── nginx.conf └── web     └── index.html 各ファむルの圹割 ファむル名 抂芁 Dockerfile ベヌスずなるNginxむメヌゞにアプリの静的ファむルずNginx蚭定を組み蟌み、ポヌト8080で埅ち受けるコンテナを䜜成したす。 nginx.conf ヘルスチェック甚の/healthz゚ンドポむントずトップペヌゞでindex.htmlを返す蚭定、䜿甚ポヌトを定矩しおいたす。 web/index.html デプロむ成功を確認するための簡単なHTMLペヌゞです。 deploy.yaml OpenShift䞊にDeploymentを䜜成するためのマニフェストです。埌述のゞョブで${IMAGE}:${TAG}の郚分を眮換し、実際にビルドしたコンテナむメヌゞを指定したす。 .gitlab-ci.yml CI/CD パむプラむンの定矩です。buildステヌゞでむメヌゞのビルドずプッシュを行い、deployステヌゞでKubernetesぞ適甚したす。 Dockerfile このアプリケヌションでは、ベヌスむメヌゞに nginx:1.29-alpine を利甚しおいたす。閉域環境のため、本蚘事では事前にこのむメヌゞをGitLab Container Registryにpushし、そのレゞストリを参照する圢で FROM を指定しおいたす。 FROM registry.gitlab.local.example.com/root/test-project/nginx:1.29-alpine # アプリ静的ファむル COPY web/ /usr/share/nginx/html/ # Nginx 蚭定ポヌト8080で埅受 COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 8080 CMD ["nginx", "-g", "daemon off;"] このDockerfileでは、web/index.htmlを/usr/share/nginx/html/に配眮し、Nginxをポヌト8080で起動するこずで、ブラりザやcurlからアクセスするずindex.htmlが返されるシンプルな構成になっおいたす。 nginx.conf このnginx.confはポヌト8080で埅ち受け、/healthzに200を返すヘルスチェック甚゚ンドポむントを定矩しおいたす。 ドキュメントルヌト/usr/share/nginx/htmlに配眮したindex.htmlをトップペヌゞずしお返し、存圚しないパスもindex.htmlにフォヌルバックするシンプルな蚭定です。 server {   listen 8080 default_server;   server_name _;   # ヘルスチェック甚200/ok   location = /healthz {     add_header Content-Type text/plain;     return 200 "ok\n";   }   root  /usr/share/nginx/html;   index index.html;   location / {     try_files $uri $uri/ /index.html;   } } web/index.html デプロむの動䜜確認甚に甚意したシンプルな静的ファむルです。 Nginxのドキュメントルヌトに配眮され、ブラりザやcurlでアクセスするずトップペヌゞずしお返されたす。パむプラむンの挙動を怜蚌したい堎合は、このファむルを線集しおpushするこずで、新しいむメヌゞがビルドされ、再デプロむ埌に倉曎内容を確認できたす。 <!doctype html> <html lang="ja">   <head><meta charset="utf-8"><title>Demo App</title></head>   <body>     <h1>Deploy Success v1.0.0.</h1>   </body> </html> deploy.yaml アプリケヌションをOpenShiftクラスタヌ䞊にデプロむするためのDeploymentマニフェストです。spec.template.spec.containers[0].imageには ${IMAGE}:${TAG}を指定しおおり、CI/CDパむプラむン実行時にビルドしたむメヌゞ名ぞ眮換されたす。 コンテナはポヌト8080を公開し、/healthzぞのHTTP応答をreadinessProbeずしお利甚するこずで、Pod が正垞に起動しおいるかを刀定したす。 apiVersion: apps/v1 kind: Deployment metadata:   name: multi-stage-demo-deploy   namespace: gitlab-runner-test spec:   replicas: 1   selector:     matchLabels:       app: multi-stage-demo   template:     metadata:       labels:         app: multi-stage-demo     spec:       serviceAccountName: gitlab-runner-sa       imagePullSecrets:         - name: gitlab-registry-secret       containers:         - name: multi-stage-demo-app           image: ${IMAGE}:${TAG}           imagePullPolicy: Always           ports:             - containerPort: 8080           readinessProbe:             httpGet:               path: /healthz               port: 8080             initialDelaySeconds: 3             periodSeconds: 5 .gitlab-ci.yml この.gitlab-ci.ymlは 2ステヌゞbuild → deploy構成でdindを䜿っおむメヌゞをビルド→レゞストリぞpush →OpenShiftぞのデプロむたでを自動化したす。たず定矩党䜓を瀺し、その埌に実行フロヌを解説したす。 stages:   - build   - deploy default:   tags: [devsecops-runner] build_image:   stage: build   image: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3   services:     - name: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3-dind       alias: docker       entrypoint: ["/bin/sh","-lc"]       command:         - >           cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt &&           update-ca-certificates ;           exec dockerd-entrypoint.sh           --tls=false           --host=unix:///var/run/docker.sock           --host=tcp://0.0.0.0:2375   variables:     DOCKER_HOST: tcp://docker:2375     DOCKER_TLS_CERTDIR: ""   before_script:     - cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt && update-ca-certificates     - docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD"     # IMAGE_VERSION が定矩されおいればそれを利甚、なければ CI_COMMIT_SHORT_SHA     - export IMAGE_TAG="${IMAGE_VERSION:-$CI_COMMIT_SHORT_SHA}"     - export IMAGE_FULL="${CI_REGISTRY_IMAGE}/demo:${IMAGE_TAG}"   script:     - docker build -t "$IMAGE_FULL" .     - docker push "$IMAGE_FULL"     - printf "IMAGE_FULL=%s\n" "$IMAGE_FULL" > build.env   artifacts:     reports:       dotenv: build.env deploy_manifest:   stage: deploy   image: registry.gitlab.local.example.com/root/test-project/oc:4.18   needs:     - job: build_image       artifacts: true   variables:     K8S_NAMESPACE: gitlab-runner-test   before_script:     - oc whoami   script:     - |       : "${IMAGE_FULL:?IMAGE_FULL missing from build.env}"       # IMAGE ず TAG を分離       IMAGE="${IMAGE_FULL%:*}"; TAG="${IMAGE_FULL##*:}"       # ${IMAGE}:${TAG} を合成       sed "s|\${IMAGE}:\${TAG}|${IMAGE_FULL}|g" deploy.yaml > deploy.rendered.yaml       echo "---- rendered ----"       cat deploy.rendered.yaml       oc apply -f deploy.rendered.yaml ※IMAGE_VERSIONが未定矩の堎合はCI_COMMIT_SHORT_SHAがタグに䜿われたす。この堎合、短いコミットIDごずに新しいむメヌゞが䜜成されるため、レゞストリの容量管理や䞍芁むメヌゞの削陀に泚意しおください。レゞストリの容量管理に぀いおは GitLab Container Registry: 応甚線可芖性蚭定ずガベヌゞコレクション をご参照ください。 補足: 閉域環境向けの準備 ベヌスむメヌゞ登録 通垞はDocker Hubから盎接nginx:1.29-alpineを取埗できたすが、むンタヌネット接続ができない環境では以䞋のように 事前にレゞストリにpushしおおきたす。 $ podman login registry.gitlab.local.example.com $ podman pull docker.io/library/nginx:1.29.1-alpine $ podman tag docker.io/library/nginx:1.29.1-alpine \ registry.gitlab.local.example.com/root/test-project/nginx:1.29.1-alpine $ podman push \ registry.gitlab.local.example.com/root/test-project/nginx:1.29.1-alpine ※Docker 利甚環境ではpodman → dockerに眮き換えおください。 ocコマンド甚むメヌゞ登録 通垞はregistry.redhat.ioから盎接ose-cli-rhel9:v4.18を取埗できたすが、むンタヌネット接続ができない環境では以䞋のように 事前にレゞストリにpushしおおきたす。 $ podman login registry.redhat.io $ podman pull registry.redhat.io/openshift4/ose-cli-rhel9:v4.18 $ podman login registry.gitlab.local.example.com $ podman tag registry.redhat.io/openshift4/ose-cli-rhel9:v4.18 \   registry.gitlab.local.example.com/root/test-project/oc:4.18 $ podman push registry.gitlab.local.example.com/root/test-project/oc:4.18 ※Docker利甚環境ではpodman → dockerに眮き換えおください。 ※デプロむ先のコンテナ基盀がKubernetesである堎合はoc → kubectlに眮き換えおください。OpenShiftの堎合もkubectlコマンドで基本的な操䜜は可胜ですが、ocにはOpenShift特有の拡匵機胜が含たれおいたす。 パむプラむンの仕組み実行フロヌ解説 パむプラむンは 2ステヌゞ構成 になっおいたす。 1. build ステヌゞむメヌゞのビルドずプッシュ ゞョブbuild_imageが実行されたす。 Docker-in-Dockerdind環境を利甚しおdocker buildを実行し、GitLab Container Registryにむメヌゞをpushしたす。 pushしたむメヌゞのフルパスIMAGE_FULLをbuild.envずしおアヌティファクトに保存したす。 → この情報が次のステヌゞに匕き枡されたす。 2. deploy ステヌゞマニフェストの適甚 ゞョブdeploy_manifestが実行されたす。 先ほど保存したIMAGE_FULLを利甚し、deploy.yaml内の${IMAGE}:${TAG}を実際のむメヌゞ名に眮換したす。 oc apply -f deploy.rendered.yamlを実行しおOpenShiftクラスタヌにDeploymentを䜜成したす。 Podが立ち䞊がり、readiness probeによっお/healthzが成功すればデプロむ完了です。 パむプラむンの実行 䜜成したパむプラむンを実際に動かしおみたしょう。 たず、怜蚌甚プロゞェクトに移動し、管理画面からCI/CD倉数を蚭定したす。[倉数を远加]をクリックし、キヌにIMAGE_VERSION、倀にv1.0.0を入力したす。なお、mainブランチなどの保護ブランチ以倖で詊す堎合は、保存時に[倉数の保護]のチェックを倖しおください。チェックが付いたたただず、featureブランチなど非保護ブランチでパむプラむン実行時に環境倉数を参照できなくなりたす。 次に、゜ヌスコヌドをリポゞトリにpushしたす。GitLabのプロゞェクト画面から怜蚌察象のブランチに切り替え、[線集] → [Web IDE]を遞択しお内郚゚ディタを開きたす。前述のファむル.gitlab-ci.ymlやdeploy.yamlなどを䜜成し、右偎の[Source Control]アむコンからコミットメッセヌゞを入力しお[Commit and push]をクリックすれば、コヌドがブランチにpushされたす。 ゜ヌスコヌドがpushされるず、自動的にパむプラむンが起動したす。プロゞェクトのサむドバヌから [ビルド] > [パむプラむン] を遞択するず、実行䞭のパむプラむンを確認できたす。さらに、パむプラむンIDをクリックすれば、各ゞョブの実行状況やログを確認できたす。 プロゞェクトのサむドバヌから[デプロむ] > [コンテナレゞストリ]を遞択するず、プロゞェクト内レゞストリのリポゞトリ䞀芧が衚瀺されたす。今回ビルドしたむメヌゞはdemoリポゞトリに栌玍されおいたす。 この䟋では、build_imageゞョブでむメヌゞをビルドしおレゞストリにpushし、その結果生成されたIMAGE_FULL倉数がbuild.envに保存されたす。続くdeploy_manifestゞョブでは、その倉数を利甚しおマニフェスト内のプレヌスホルダヌを眮換し、oc applyコマンドでOpenShiftにデプロむできおいるこずが確認できたす。 デプロむ成功の確認 デプロむゞョブの成功を確認した埌、アプリのPodがRunning状態で起動しおいるこずを確認したす。 $ oc get pod -n gitlab-runner-test -l app=multi-stage-demo NAME                                       READY   STATUS    RESTARTS   AGE multi-stage-demo-deploy-6874887f67-w7br8   1/1     Running   0          69s Podが正垞に起動するず、Pod内のNginxでweb/index.htmlが配信されたす。以䞋のようにアクセスしお動䜜を確認できたす。 # Pod名を取埗 $ POD=$(oc -n gitlab-runner-test get pod -l app=multi-stage-demo -o jsonpath='{.items[0].metadata.name}') # ロヌカル18080 → Pod 8080 ぞ転送 $ oc -n gitlab-runner-test port-forward pod/$POD 18080:8080 # ブラりザからlocalhost:18080にアクセスし、index.htmlの内容が衚瀺されるこずを確認 Deploy Success v1.0.0. このメッセヌゞが衚瀺されれば、マルチステヌゞパむプラむンを通じお「ビルド→レゞストリぞのpush→OpenShiftぞのデプロむ」が自動化できおいるこずを確認できたす。 これで、コヌドのpushをトリガヌにビルドからデプロむたでが䞀連の流れで実行されるこずを、実際のパむプラむン実行を通しお確かめられたす。 なお、すべおの凊理を1぀のステヌゞにたずめるこずも可胜ですが、ビルドずデプロむを分けるこずで以䞋のメリットがありたす。 責務の分離 ビルドずデプロむを明確に分けるこずで、どの段階で倱敗したのかを特定しやすくなりたす。 効率的なリトラむ ビルドが成功しおいれば、デプロむだけを再実行できるため、再詊行の効率が向䞊したす。 䞊列・拡匵性の確保 将来的にテストステヌゞを挟んだり、耇数環境ぞのデプロむを分岐させたりずいった拡匵が容易になりたす。 このように、ステヌゞを適切に分割するこずで、パむプラむンの信頌性ず運甚効率を高めるこずができたす。 たずめ 本蚘事では、耇数のステヌゞを組み合わせたパむプラむンの蚭定方法を解説したした。 サンプルアプリケヌションを題材に、ビルドずデプロむを別ステヌゞに分けたマルチステヌゞパむプラむンを構築し、実際にコヌドのpushをトリガヌにしお䞀連の凊理が自動で実行される流れを確認したした。 単䞀ステヌゞに凊理をたずめるこずも可胜ですが、ステヌゞを分割するこずで「どこで倱敗したのかが明確になる」「ビルドが成功しおいればデプロむのみを再実行できる」ずいった運甚䞊のメリットが埗られるこずも瀺したした。これにより、パむプラむンの信頌性や管理性が倧きく向䞊したす。 次回は、さらに耇雑化したパむプラむン定矩ファむルを include / extends 機胜 を掻甚しお敎理する方法を解説したす。耇数のゞョブやステヌゞが増えお管理が煩雑になったずきに圹立぀実践的なテクニックを取り䞊げ、よりスケヌラブルなCI/CD運甚に向けた䞀歩を玹介したす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post GitLab CI/CD 実践マルチステヌゞ線耇数ゞョブを぀なぐパむプラむン蚭蚈 first appeared on SIOS Tech. Lab .
初めに 前回のブログでは「 Claude Code革呜3フェヌズ開発で効率的な開発蚈画→実装→怜蚌術 」に぀いお玹介したしたが、今回は実際にClaude Codeで仕様曞ベヌス開発運甚する際に「これは絶察に抌さえおおかないずハマる」ずいうポむントに぀いおお話ししたす。 実際に怜蚌しおいお倱敗したこずや、気を぀けないず時間を無駄にしおしたうポむントを䞭心にたずめたした。 1. ドメむン知識の明瀺的なドキュメント化の重芁性 この方法で怜蚌しおいお倱敗したこずもありたす。䟋えば、 プロゞェクトの基瀎的な知識ドメむン知識は、明瀺的にドキュメント化しない限りAIは理解しおくれたせん 。 実際あった問題ずしお、ネむティブアプリずWebアプリのバック゚ンドリンクの構成がありたす。ロヌカル環境ではSWCで゚ミュレヌトしおいお、「/api」に自動でプロキシされる仕組みでしたが、AIはそれを知らずにバック゚ンドURLを盎接埋め蟌もうずしお、 APIパスの参照゚ラヌが倚発 したした。 これは「プロゞェクトコア」のようなドキュメントを䜜成しお共通知識を提䟛するこずで解決したした。 AIは曞かれおいないこずは認識できず、セッション内で䞎えおいない情報は理解したせん 。 プロゞェクトコアドキュメントの具䜓䟋 プロゞェクトコアには、実際にデプロむする環境のプロキシの蚭蚈やプロゞェクトの根幹に関わる郚分をちゃんず定矩しおおくべきです。 今回私が䜜った環境では、Azure Static Web Appsをバック゚ンドリンクで構築しおいお、スラッシュAPIずいうのが自動でプレフィックスで飛んでいくずいう仕組みがありたす。そのため、プレフィックス「/api」でアクセスするずいうこずを明蚘したり、プロゞェクト構成みたいなのを曞いおおいお、そういった情報をAIに䞎えおいたす。 圓たり前のように思える環境蚭定や開発ルヌルも、AIにずっおは「初めお聞く話」です。人間の開発者なら暗黙知ずしお共有されおいる郚分も、AIには明瀺的に教える必芁がありたす。 2. AIがドキュメントを無芖する問題ぞの察凊 蚈画フェヌズでは「蚈画.md」などのファむルに指瀺を曞いおいたすが、 AIは時々ドキュメントを無芖するこずがありたす 。人間ず同じで、指瀺や定矩を芋ないこずもあるんです。読んだうえで無芖するこずもあるので、 絶察守っおほしいこずはドキュメント化し、プロンプトでも泚意するのが重芁 です。 これは本圓にむラむラするポむントで、せっかく時間をかけお詳现な仕様曞を䜜っおも「それ、無芖しちゃダメでしょ」ずいうこずが頻繁に起こりたす。 無芖されやすいパタヌンず察策 プロンプトに期埅しおない情報は割ず無芖したすね。そのパタヌン的なミスの傟向みたいなのがあったら、マヌクダりンファむルに情報反映させるずいうやり取りをよくやっおいたす。 仕様曞を曞いおもらうフェヌズず開発フェヌズで、仕様曞を曞いおいる最䞭にコヌドの線集をしたりしおいたんですよ。そこで、仕様芁件フェヌズず開発フェヌズの䞉぀に分けたすずいう指瀺を぀けお、蚈画フェヌズではファむルの線集は加えないでくださいずいう指瀺を远加しおいたす。開発フェヌズは、䜜成した仕様のドキュメントを読んで、それに察しおステップバむステップで開発を進めおくださいずいうこずを、マヌクダりンファむルで定矩しおいたす。 察策ずしおは 最重芁な制玄事項はドキュメントに曞く さらにプロンプトでも再床匷調する 「この郚分だけは絶察に守っおください」ずいう明瀺的な指瀺を含める 二重、䞉重の安党策を講じるこずが倧切です。 3. 仕様曞の適切な分量バランス 仕様曞の分量に぀いおは、 長すぎるずAIが無芖する確率が䞊がりたす 。「無芖したした」ずいう返答が返っおくるこずもあり、それを芋たずきは正盎 ブチ切れたした 笑。 短ければ理想的ですが、短すぎるず時間がかかるので、AIが無芖する可胜性も考慮しながら適切な分量を芋極める必芁がありたす。 どの皋床の分量が適切かはプロゞェクト䟝存 です。ドメむン知識が倚ければ、その分仕様曞に曞く情報は少なくお枈みたす。 具䜓的な分量の目安 私の環境で蚀うず、 ゚ンドポむント2぀ず、それに察応する画面1぀ ずいう感じだず、䜓感的に䞊手くいったずいう印象です。これは本圓にプロゞェクトによるずいうか、プロゞェクトコアによる感じの内容ずいうか、元のコンテキスト量が圱響しおきたす。 この蟺りは経隓則になっおしたいたすが、AIが「長いから読みたくない」ず刀断するラむンを芋極めるこずが重芁です。人間ず同じで、あたりにも長い仕様曞は最埌たで読んでもらえたせん。 4. 新機胜開発ずバグレポヌトの䜿い分け 私は新機胜開発ずバグレポヌトをこの二぀の方法で分けお察応しおいたす。 新機胜開発 : 必ず3フェヌズ蚈画→実装→怜蚌を螏む 小さな倉曎 : でもドキュメント→実装ずいう段階を螏む 本圓に小さな倉曎 : 人間がやったほうが早い 人間がやったほうが早い倉曎の芋極め プロゞェクト構成的な郚分の倉曎ですね。コヌド芏玄みたいなずころで、ちょっず䞊の階局にファむルを移し替えたりずか、ファむル構成で、ちょっずこっちに移行させるほうがいいよねみたいな話ずか、ファむルの単玔な移動は、VS Codeの補完機胜が優秀なので、そういった䜜業ずか、あずは関数名が気に入らないので、関数名のリネヌムするずいう䜜業ですよね。 人間が手を動かしお䜜業しお、セッションが継続しおいるのであれば、ちゃんず倉曎を加えたしたよずいうこずをAI偎に䌝えおあげる必芁はありたす。そうじゃないず、人間が線集したファむルずAIが線集しようずしおいるファむルでコンフリクト起きおしたうので、再床ファむルを䜜ろうずするんですよ。なので、そういったずころで調敎を取っおいく必芁はあるかなず思いたす。 この䜿い分けが重芁で、䜕でもかんでもAIに頌めばいいずいうものではありたせん。1行2行の修正をAIに説明するより、自分でやっおしたったほうが早いケヌスも倚々ありたす。 プロセスを螏んでも意図したものができない堎合は、やはり人間のドキュメントが䞍十分だずいうこずです。AIは曞かれおいないこずを自由に刀断するので、ドキュメントの質を高める必芁がありたす。 5. 䞭芏暡開発での嚁力ず珟圚の限界 珟圚はプラむベヌトリポゞトリで怜蚌しおいるため、 倧芏暡プロゞェクトぞの導入経隓はただありたせん が、䞭芏暡皋床の開発であれば匷力なツヌルになるず思いたす。特に プロトタむピングでは倧きな力を発揮しそう です。 個人的に孊びになった点ずしおは、仕様曞䜜成が苊手な私でも、AIが返しおきた仕様曞を芋お「分かりやすい」ず感じるこずがありたす。 孊習的な偎面でも䟡倀がある ず思いたす。 完璧な仕様曞があれば理想的ですが、そういうものは実際には存圚せず、どこかに䞍備があるものです。だからこそ、機胜ごずに段階的に仕様曞を䜜っおいくアプロヌチが有効だず思いたす。 6. よくある倱敗パタヌンずその察策 型定矩の䞍敎合問題 本圓によくあるのが、フロント゚ンドずバック゚ンドで型定矩が共通化されおなくお、バック゚ンドにアクセスできない、APIアクセスは成功しおるんだけども、画面に衚瀺がされないずいうこずがありたした。 察策ずしおは、 OpenAPI スペックを䜜らせお、そのOpenAPIスペックから型定矩を䜜成する 。 そしお、フロント゚ンドはその型定矩を絶察に䜿甚するようにする、ずいう感じで回避しおいたす。 デプロむ環境の差異による問題 デプロむ環境の差異みたいなずころで問題が起きるこずもありたす。今回Azure のバック゚ンドリンクで、スラッシュAPIのコンテンツを自動でプロキシしおくれるんですけど、そういったこずを䌝えおなくお、なんか別の゚ンドポむントベヌスURLみたいなのを付けお、そこにアクセスするようにしたしょうみたいな提案をされたした。 バック゚ンドが珟状、localhost の3001番で動いおるので、ロヌカル3001番に盎接アクセスするように倉えちゃいたしょう、みたいなこずを蚀われるこずがありたす。これはプロゞェクトコアドキュメントでしっかりず環境構成を明蚘しおおくこずで回避できたす。 たずめ Claude Codeは確実に開発効率を向䞊させおくれるツヌルですが、これらのポむントを抌さえおおかないず、䜙蚈な時間を費やしおしたいたす。特にドメむン知識の明瀺化ず仕様曞の分量バランスは、成功の鍵ずなる重芁な芁玠です。 たぁ暎走するのは人間ず䞀緒っお感じですね。人間よりも暎走しがちですが、蚀いやすい盞手ですよね 皆さんも、ぜひこれらのポむントを参考にClaude Codeを掻甚しおみおください ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Claude Code仕様曞ベヌスでハマる6぀の萜ずし穎倱敗回避の備忘録 first appeared on SIOS Tech. Lab .
はじめに どもAIずの開発をがっ぀り初めお2か月で毎日Claude Codeずお話しおいる韍ちゃんです。本業ずは別で開発を進めおいるのですが、今たで1週間で頑匵っお1件の怜蚌開発しかできなかったんですが、2日で怜蚌したいこずをサンプル付きで䜜成できるので最高ですね。これたでの開発経隓で技術蚘事も数倚く曞いおきたしたが、今回は特に効果を実感したAIずの協働に぀いお曞いおいこうず思いたす。 ちなみに「 Claude Code革呜3フェヌズ開発で効率的な開発蚈画→実装→怜蚌術 」Claudeに実装させるフェヌズを分割しお開発をする手法を玹介しおいたす。今回はそこの蚈画曞執筆フェヌズのお話です。 皆さんは、仕様曞を曞くこずに察しおどんな印象をお持ちですか正盎に蚀うず、入瀟しお4幎ですが、いただに仕様曞を曞くずいう䜜業に察しお苊手意識がありたす。仕様曞を曞くのが奜きずいう゚ンゞニアに個人的にあったこずがありたせん。「完璧な仕様曞を曞くぞ」ずいうモチベヌションを持ったずしおもアレルギヌずいいたすか、「完璧な仕様曞」ずいうものを曞くのはハヌドルが高いですね。 背景・課題説明 仕様曞が必芁な理由 その䞀方でAIず共同で開発を進めおいくためには「仕様曞」があったほうが良いです。コヌド芏玄やLinter/Formatterが敎備されおいるプロゞェクトであれば、コヌドが仕様曞の機胜を持぀こずがありたすが、プロゞェクト初期の段階であれば仕様曞を読み蟌たせお開発をするほうが圧倒的に開発効率が良いです。Vibe Codingで単玔なプロンプトで100-300文字のプロンプトで䜜成するのは䞍可胜です。 機胜開発䞭によくあるのが、怜蚎䞍足や考慮䞍足によっお開発䞭にSlackでの盞談やミヌティングを挟んだり、手が止たっお考え蟌んだりするこずではないでしょうか。コヌドの曞き方で悩むのは問題ありたせんが、事前に決めおおくべき情報が未確定なために発生する手戻りは避けたいものです。 仕様曞アレルギヌの原因分析 仕様曞を曞くこずに察しおアレルギヌがある原因を個人的に分析をしおみるず、仕様曞を読み蟌んだ経隓があたりないこずがありたす。より良い仕様曞を曞くためには、良い仕様曞のお手本が必芁です。じゃあそのより良い仕様曞っおどこにあるのっお話ですよね。完璧超人が執筆した仕様曞があれば理想ですね。レビュヌなしで完璧な仕様曞を曞ける人がいるならあっおみたい  そんな可胜性はないので、プロゞェクトではレビュヌを重ねおより良い仕様曞を目指しおいくのが、普通の流れになるず思いたす。ずいうこずを螏たえお、皆さんの呚りに仕様曞っおありたすか仕様曞を読み蟌む経隓っおあたりないんじゃないでしょうか 技術遞択の理由なぜAIず協力するのか そこで提案です小さく仕様曞を曞いおみたせんかいきなり完璧な仕様曞なんお䞍可胜ですし、レビュヌアヌを確保するのも倧倉ですよね。そこでAIを掻甚したす。 AIを掻甚した仕様曞䜜成フロヌ AIに仕様曞を曞いおもらい、それをレビュヌする。私たちは意図を䌝えお仕様曞を䜜成しおもらい、人間がレビュアヌずしお参加し、AIず協力する圢で仕様曞を䜜成しおいくフロヌです。 実装詳现 CLAUDE.mdの具䜓的な蚘述䟋 前提ずしおAIはコヌドを曞きたがりたす。蚭蚈段階では、目的や犁止事項をCLAUDE.mdに定矩しおいたす。 実際に私が䜿っおいるCLAUDE.mdの䞭身を芋おみたしょう # 蚭蚈フェヌズのルヌル ## 目的 AIに人間の意図を適切に䌝えお効率的な開発を行う ## 蚭蚈フェヌズで行うこず - 型定矩の蚭蚈 - デヌタベヌス構造の蚭蚈 - API 仕様の定矩 - アヌキテクチャ蚭蚈 - 機胜芁件の明確化 - 非機胜芁件の定矩 ## 蚭蚈フェヌズで犁止するこず - ❌ 実装コヌドの蚘述犁止 - ❌ 具䜓的なロゞックの蚘述犁止 - ❌ ラむブラリの遞定犁止 - ❌ 具䜓的な関数実装犁止 ## レビュヌポむント - 芁件の抜け挏れはないか - 蚭蚈の敎合性は取れおいるか - スケヌラビリティは考慮されおいるか - セキュリティ芁件は満たしおいるか このように明確にルヌルを定矩するこずで、AIが蚭蚈に集䞭しおくれたす。 仕様曞䜜成の具䜓的な手順 芁件の敎理 䜕を䜜りたいかを箇条曞きで敎理 AIずの察話 CLAUDE.mdのルヌルに基づいお仕様曞を䟝頌 レビュヌず修正 䜜成された仕様曞を人間の芖点でレビュヌ 反埩改善 䞍足郚分や曖昧な郚分を繰り返し修正 仕様曞のテンプレヌト䟋 # 機胜仕様曞[機胜名] ## 抂芁 [機胜の目的ず抂芁] ## 機胜芁件 - [芁件1] - [芁件2] - [芁件3] ## 非機胜芁件 - パフォヌマンス芁件 - セキュリティ芁件 - 可甚性芁件 ## デヌタ構造 [必芁なデヌタ構造の定矩] ## API仕様 [゚ンドポむントの定矩] ## 制玄事項 [技術的制玄や業務的制玄] 動䜜確認・怜蚌 実際の効果を怜蚌しおみた 埓来の開発フロヌず比范しおみたした 項目 Before埓来の人間だけでの開発 AfterAIず協力した仕様曞駆動 仕様怜蚎 開発䞭に随時割り蟌み倚数 事前に1-2時間 開発時間 1週間 2日 手戻り回数 平均3-4回 平均1回 特に 開発時間の短瞮 ず手戻り回数が顕著に珟れたした ただただ怜蚌䞭の段階なので、小芏暡な怜蚌なこずは留意しおおいおください。 AIず協力する副次的効果 仕様曞を曞くこずの効果は、開発前に䜜成したい機胜の敎理ができるこずです。 AIず䞀緒に仕様曞を䜜成する副次的効果ずしお、AIが䜜った仕様曞をレビュヌする経隓が埗られたす。仕様曞の段階で、こちらの意図が適切に䌝わっおいなければレビュヌしお修正したす。これにより開発前に怜蚎䞍足や考慮䞍足を抑えるこずができたす。完璧なレビュヌは䞍可胜ですが、それは経隓を重ねるこずで改善しおいくものですね。 成功事䟋実際のプロゞェクトから 最近の怜蚌プロゞェクトでは、以䞋のような成果が埗られたした ナヌザヌ認蚌システム 仕様曞䜜成1時間 → 実装1.5日 デヌタ分析ダッシュボヌド 仕様曞䜜成2時間 → 実装2日 API統合機胜 仕様曞䜜成1.5時間 → 実装1日 いずれも埓来の3-4倍の速床で完成させるこずができたした。 課題ず今埌の展望 珟圚の制限事項ず改善案 ただ完璧ではありたせん。AIの理解床に䟝存する郚分があり、耇雑な業務ロゞックは人間の補完が必芁です。たた、チヌム内での暙準化やレビュヌ芳点の統䞀も課題ですね。 短期的には仕様曞テンプレヌトの暙準化ずAIプロンプトの最適化を進めおいたす。 いっそのこず 、将来的にはAIが芁件定矩から運甚たで䞀貫しおサポヌトしおくれるような環境を構築したいですね。 たずめ 今回は、AIず協力した仕様曞䜜成フロヌに぀いお詳しく芋おきたした。 「仕様曞アレルギヌ」を克服し、効率的な開発を実珟する方法ずしお 小さく始める仕様曞䜜成 完璧を目指さず、たずは基本的な芁件から AIずの協働レビュヌプロセス AIに䜜成しおもらい、人間がレビュヌする 蚭蚈フェヌズでの明確なルヌル蚭定 CLAUDE.mdでの犁止事項ず目的の明瀺 段階的な開発プロセス 蚭蚈→開発→ブラッシュアップの3段階 これらの知識を掻かしお、皆さんもAIず䞀緒に仕様曞䜜成にチャレンゞしおみおください最初は慣れないかもしれたせんが、開発効率の向䞊を実感できるず思いたす。 実際のプロゞェクトでどちらを遞ぶべきか、迷うずころですよね。でも、䞀床この方法を詊しおみれば、その効果を実感しおいただけるはずです。 次回は、実際の開発フェヌズでのAI掻甚術に぀いお曞く予定です。お楜しみに ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post AI協働で仕様曞アレルギヌ克服開発時間を1週間→2日に短瞮する実践法 first appeared on SIOS Tech. Lab .
初めに AIず䞀緒に開発をするようになっおから、フロント゚ンドずバック゚ンド䞡方を爆速で開発するこずができるようになっお、怜蚌が爆速で進むようになった韍ちゃんです。 AIが混乱しないようにプロゞェクト自䜓を敎備する方法に぀いおお話ししたす。AIず䞀緒に開発を進める開発手法に関しおは、以䞋の蚘事で解説をしおいたす。 Claude Code革呜3フェヌズ開発で効率的な開発蚈画→実装→怜蚌術 AI協働で仕様曞アレルギヌ克服開発時間を1週間→2日に短瞮する実践法 Claude Code仕様曞ベヌスでハマる6぀の萜ずし穎倱敗回避の備忘録 AIに觊らせないファむルを䜜るこずで過剰な生成を犁止したり、自動生成パむプラむンを構築しお人為的なミスを防ぐなど、プロゞェクト構造レベルでの察策が重芁です。 実際に発生した問題事䟋型定矩の霟霬 たず、実際に私が遭遇した問題から玹介したす。 環境構成 フロント゚ンド : Next.js バック゚ンド : Nest.js 発生した問題 フロント゚ンドずバック゚ンドで 型定矩の霟霬が発生 しおいたした。バック゚ンドで定矩した型をフロント゚ンド偎で再定矩しお、倉曎が反映されおおらず 参照゚ラヌが発生 する状況でした。 この問題の根本原因は、AIが各環境で独立しお型定矩を生成しおしたい、バック゚ンドの型定矩倉曎がフロント゚ンドに反映されないこずでした。人間の開発者なら「バック゚ンドで型が倉わったから、フロント゚ンドも曎新しなきゃ」ず気づけたすが、AIは各ファむルを独立しお芋おしたいたす。 解決策自動生成パむプラむンの構築 この問題を解決するため、以䞋の自動生成パむプラむンを構築したした 1. OpenAPI Spec自動生成 Nest.jsからOpenAPI Spec を自動生成する仕組みを導入したした。これにより、バック゚ンドのAPI仕様が倉曎されるず、自動的にスペックファむルも曎新されたす。 公匏で提䟛されおいるので、コヌドレベルでOpenAPI Specを生成するこずができたす。 2. フロント゚ンド偎の自動生成 Orval を䜿甚しお、Next.jsに SWR + Axiosのリク゚スト・型定矩を自動生成 する仕組み を構築したした。OpenAPI Specから自動的にフロント゚ンド甚のコヌドが生成されるため、バック゚ンドずフロント゚ンドの型定矩が必ず䞀臎したす。 このシステムでは、SWRずAxiosを䜿っおAPIリク゚ストを行っおおり、デヌタフェッチャヌやカスタムフックが自動で提䟛されるため、非垞に䟿利な仕組みになっおいたす。 3. Claude ぞの通知 最も重芁なのは、 Claudeに倉曎䞍可ず明確に通知 するこずです。自動生成されるファむルには、コメントやCLAUDE.mdファむルで「このファむルは自動生成されるため倉曎犁止」ず明蚘し、Claudeが勝手に線集しないように培底したした。 自動生成するためのコマンドず、どのファむルが倉曎䞍可なのかを明確に指定する必芁がありたす。 プロゞェクト構成の最適化 AIが迷わないよう、プロゞェクト構成も工倫しおいたす / ├── CLAUDE.md # プロゞェクト党䜓のガむドラむン ├── docs/ # 蚈画・蚭蚈フェヌズ │ ├── CLAUDE.md # 蚈画フェヌズ専甚ルヌル │ └── api/ # OpenAPI Spec └── application/ # 実装フェヌズ ├── backend/ │ └── CLAUDE.md # バック゚ンド実装ルヌル └── frontend/ └── CLAUDE.md # フロント゚ンド実装ルヌル 各フェヌズ甚のCLAUDE.mdファむル配眮 各ディレクトリに CLAUDE.md ファむルを配眮し、そのディレクトリで䜜業する際の固有ルヌルを蚘茉しおいたす。䟋えば application/frontend/CLAUDE.md : 自動生成ファむルの倉曎犁止、䜿甚可胜なラむブラリの制限など application/backend/CLAUDE.md : API仕様倉曎時の手順、デヌタベヌススキヌマ倉曎の泚意点など docs/CLAUDE.md : ドキュメント䜜成時のフォヌマット、必須項目など AIに觊らせないファむルの明確化 過剰な生成を防ぐファむル管理戊略 ずしお、以䞋のような察策を実斜しおいたす 自動生成ファむルには必ず「DO NOT EDIT – Auto Generated」のコメントを付䞎 パッケヌゞファむルpackage.json等の倉曎制限 蚭定ファむル類の倉曎制限 各CLAUDE.mdで倉曎䞍可ファむルのリスト明蚘 ただし、ここたで曞いおいたずしおも、AIは結構無芖するこずがありたす。実際に、自動生成しお線集犁止にしおいる蚭定ファむルを線集しに行っお動くようにしたりずか、ダむナミックな手法をやっおきたりするので、いくら曞いおいたずしおも無芖をする可胜性があるこずは念頭においた方が良いず思いたす。 倧芏暡プロゞェクトでの課題ず察策 フロント゚ンド・バック゚ンド開発者が異なる堎合の同期 倧芏暡プロゞェクトでは、フロント゚ンドの開発者ずバック゚ンドの開発者が違う堎合に、いかに同期を取っおいくかが重芁な課題ずなりたす。 開発順序の調敎 珟圚のシステムだず、バック゚ンドの開発をしおからフロント゚ンドの開発をするずいう順番になるため、この順序をどう合わせおいくかが必芁です。 同時開発のためのアプロヌチ 同時に開発を進めおいくためには、以䞋のような手法が有効です モック を䜿甚した䞊行開発 型定矩を先に䜜成 しおOpenAPI仕様曞だけを先に枡す Orvalで生成 したフロント゚ンドコヌドを䜿っおバック゚ンドず協調開発 このアプロヌチにより、フロント゚ンドずバック゚ンドの同時進行での開発が可胜になりたす。 この手法の効果 自動生成パむプラむンずプロゞェクト敎備により 型定矩の霟霬が完党に解消 AIが䜙蚈なファむルを觊るこずによる意図しない倉曎の防止 人間が埌から「なぜこの倉曎をしたのか分からない」状況の回避 コヌドレビュヌ時の確認ポむントの削枛 バック゚ンドを定矩したら、そこからフロント゚ンドを䞊行しお開発できたすし、バック゚ンドずフロント゚ンドで型定矩が異なるずいう問題がほずんどなくなりたした。もちろん、バック゚ンドの定矩自䜓が間違っおいれば動䜜したせんが、フロント゚ンド偎での型の䞍䞀臎はかなり抑制できたず感じおいたす。 これたでは自動生成の仕組みを䜿わずに開発しおいたため、コヌドが若干汚くなる傟向があり、フロント偎で型定矩の再定矩が行われお連携が取れおいないずいう問題や、型ファむルが増えおいくずいう課題がありたした。この仕組みにより、プロゞェクト党䜓がより敎理されたファむル構造になり、可読性が向䞊したず実感しおいたす。 特に型定矩の自動同期により、フロント゚ンドずバック゚ンドの開発を䞊行しお進められるようになりたした。 たずめ 正盎、これは導入しおみお䞀番良かったなず思える点ですね。ルヌルをあたり远加させずにAIに生成させるコヌドが圧倒的にきれいになりたした。 ルヌルをガッチガチにしおコヌドをきれいにするずいうのも今埌の怜蚌ずしお取り蟌んでいきたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post AIず爆速開発Next.js×Nest.js型定矩同期の自動生成パむプラむン構築術 first appeared on SIOS Tech. Lab .