Jenkinsを利用したCI/CDパイプラインの構築
本講義は、クラウドネイティブアプリケーションを構成する4つの核心要素(MSA、CI/CD、DevOps、Container)の一つであるCI(Continuous Integration、継続的インテグレーション)とCD(Continuous Deployment、継続的デプロイメント)パイプラインについて扱う講義です。本講義を通じて、CI/CDツールであるJenkinsを利用してローカル環境とクラウド環境に自分だけの自動化パイプラインを構築し、デプロイするために必要なプロセスを理解し、実習することができます。
受講生 4,881名
難易度 初級
受講期間 無制限


お知らせ
8 件
こんにちは。Spring開発者向けの「実践LLMサービス開発(Part 1)」講義に、新しい補足講義を追加しました。最近公開されたTypeSafe AIの決定モデルJevをSpring Bootアプリケーションに連携する内容で、約1時間の講義です。
なぜ追加したのか
Section 4では、entity()を使ってLLMの応答をJavaオブジェクトとして受け取る方法と、モデルがJSONをコードフェンスで囲むことでパースに失敗する実務上の落とし穴を扱いました。プロンプトで依頼するにしても、entity()で自動化するにしても、結局のところLLMに形式を"お願い"する方式であるという限界は残ります。
Jevは異なるアプローチを取ります。文章を書くのではなく、あらかじめ定められた選択肢の中から答えを選び、確率とともに返します。つまり、形式が構造的に保証されるということです。同じ入力を2つの方式で処理してみると、「構造化された出力」を設計する際に何を考慮すべきかが、より明確になります。そのため、Section 4の延長線上にある内容としてまとめました。何を学びますか
JevとSystem Oneモデルの概念:テキストではなく「型が定められた決定」を返すことの意味
LLMとJevの違い:記述式回答 vs 選択式回答、それぞれが得意なことと苦手なこと
3つの質問タイプ(choice・score・noul)と
/v1/systemoneリクエストの構造Springから呼び出す:
RestClientでJev APIを呼び出し、Java enumで選択肢を作成してレスポンスを型安全に変換する比較デモ:同じ映画レビューを
entity()とJevでそれぞれ分析し、速度、形式エラー、確信度、一貫性を比較する
併せて更新された資料
セクション4のサンプルコード(ch4):レビュー分析API 2種(
/api/movies/review/llm、/api/movies/review/jev)とJevClientを追加補足講義スライドと教材
比較テストスクリプト:macOS用
review-compare.sh、Windows用review-compare.ps1
あらかじめ知っておいていただきたいこと
JevはSpring AIの機能ではなく、TypeSafe AIが提供する別個の外部サービスです。講義でもSpring AIの
ChatClientではなく、RestClientで直接呼び出します。Jevは現在アーリーアクセス段階のため、APIキーの発行に時間がかかる場合があります。サンプルコードでは基本的にJev機能が無効になっているため(
jev.enabled=false)、キーがなくても従来の演習はそのまま進められます。キーをお持ちでない方は、動画でのデモをご覧いただきながら、概念とコードを中心に学習してください。リリース初期のサービスのため、今後価格やAPIが変更される可能性があります。変更があった場合は、新しいお知らせで改めてご案内いたします。
📌講義はこちら: https://inf.run/VVpnV
追加された講義を受講しながら疑問点や実習中に行き詰まった部分があれば、気軽にコメントでお知らせください。これからも実務ですぐに使える内容を継続的に充実させていきます。
こんにちは、イ・ドウォンです。
"Jenkinsパイプラインは作ってみたけれど、ArgoCDやGitOpsは概念を聞いたことがあるだけだ。"
"dev・staging・production環境ごとのデプロイをどのように設計すべきか途方に暮れている。"
このようなお悩みをお持ちの方に向けて、「JenkinsとArgoCDで学ぶ実践GitOps CI/CD」講座をインフランで公開しました。
この講義はこのような点が異なります
• Jenkinsベースの従来のCI/CDからArgoCDベースのGitOpsまで一緒に扱います。
• Push方式(Jenkins)とPull方式(ArgoCD)を同じクラスター上で直接比較します。誰かがkubectlで手動変更を加えた際、一方はそのまま残り、もう一方は自動的に復旧する様子を目で確認し、ロールバックやデプロイ履歴の確認方法の違いも実際に体感します。
• 2つの方式を組み合わせ、dev・stagingはJenkins Push、productionはArgoCD Pull(手動Sync承認)に分けるハイブリッドデプロイパイプラインを最初から最後まで構築します。
• Canary、Blue-Green、RBAC、承認手順、障害対応、自動ロールバックまで、運用に必要な主要デプロイ技術を実践します。
実習環境
Docker Desktopひとつで進めます。WindowsとmacOSの両方に対応しており、AWSなどのクラウドアカウントや別途費用は必要ありません。
このような方におすすめです
• Jenkinsは使ったことがあるものの、ArgoCD/GitOpsは初めてのバックエンド・インフラエンジニア
• Kubernetesデプロイを手動のkubectl applyから自動化へ移行したい方
• デプロイの承認、ロールバック、監査証跡などの運用要件に悩むDevOps・SRE担当者
総学習時間は約10~11時間で、実習資料とトラブルシューティングガイドも併せて提供されます。
👉 講義を見る:https://inf.run/dEjZE
気になる点があれば、コメントや講座のQ&Aにお気軽にお寄せください!
今回、新たにSpring開発者のための実践LLMサービス開発(Part 1)講座を開講しました。少し遅きに失した感は否めませんが、Java開発者にとってなじみ深いSpring frameworkを利用してLLMアプリケーションを開発するために必要な内容を学べる講座として構成しました。ぜひご注目ください。
なぜこの講義を作ったのか
最近では、RAGやベクトル検索、AIエージェントといったキーワードはどこでも目にしますが、実際に"Spring Bootバックエンドにどのように組み込むのか"を実務レベルで扱った資料は多くありませんでした。
この講義では、私が実際にRAG推薦エンドポイントをデバッグする中で経験した問題――文書をトークン単位でチャンク化したことで意味のまとまりが崩れ、検索品質が低下した経験や、段落単位のチャンク化に戦略を変更して問題を解決した過程――を、そのままカリキュラムに落とし込んでいます。チュートリアルのように正解コードだけを見せるのではなく、「なぜうまくいかないのか → どのように診断するのか → どのように直すのか」を一緒に追っていく形式です。
このような方におすすめです
Spring Bootの経験はあるものの、LLM/AIサービス開発は初めてのバックエンド開発者
RAGやベクトル検索をチュートリアルではなく、実務プロジェクトレベルで適用したい開発者
社内AI機能(チャットボット、ドキュメント検索、レコメンドなど)をSpringベースで自ら実装する必要がある実務担当者
Spring BootでREST APIを作った経験があれば十分です。AI/LLMに関する事前知識は必要ありません。
何を学びますか
1. Spring AIのコア基礎 ChatClientの基本的な使い方、構造化出力(Structured Output)、ストリーミング応答の実装
2. RAGパイプラインの構築 ベクトルストア連携、ドキュメントチャンク分割戦略の比較と実践的なトラブルシューティング、検索品質の改善、プロンプト設計
3. ツール・マルチモーダルの拡張 MCP(Model Context Protocol)を活用した外部ツール連携、画像などのマルチモーダル入力処理、Dify連携
4. サービスの安定化と実践プロジェクト ガードレールの適用、信頼性の高いサービス設計、これまで学んだ内容を統合するミニプロジェクト
付録として、AIコーディングツールとOllamaの活用方法も併せて扱います。
シリーズ案内
今回リリースしたのは、全シリーズのPart 1です。Part 2、3ではさらに発展的なアーキテクチャと実践的なケースを扱う予定で、シリーズがすべてリリースされたら、パッケージ全体の割引も用意する予定です。
📌 講義はこちら: https://inf.run/VVpnV
気になる点やカリキュラムに関する質問は、コメント欄にお気軽にお寄せください。Part 1を通じて、皆さんのSpringサービスにLLMを組み込む第一歩を一緒に踏み出せればと思います。
こんにちは、離島院です。
「Jenkinsを使用したCI/CD Pipelineの構築」講義と「DevOpsのためのDocker仮想化技術(Private Harbor Registry)」講義では、所望のDockerコンテナ実行のためにDinD(Docker in Docker)方式で実践環境を構築し、例を実行しています。
ただし、WindowsとMacOS環境がそれぞれ異なり、MacOSの場合、Intel chip、Apple chipによって設定しなければならないドッカーイメージが異なります。この画像では、SSHサーバーとDockerエンジンがインストールされているように構成し、実習の際、複数のドッカーコンテナが必要な場合に使いやすくするように構成したが、受講生の方々の環境に合わせて製作するには無理があるのも事実です。それでも、できるだけ一般的な環境では無理なく実習できるようにドッカーイメージを更新しようとしています。
最近、MacOS Apple chip で使用する docker-server:m1 イメージを利用して、実習時、下記のエラーなどで実習できないエラーが確認されました。
exec /docker-entrypoint.sh: invalid argument複数のパスで確認して修正もしてみましたが、MacOS Apple chipで使用するarm64アーキテクチャにDockerコンテナにドッカーエンジンをインストールして使用するDinD方式でエラーが発生するようです。 (エラーメッセージやログがないため原因を探すには限界がありますね)
そのイメージでは解決が難しいと判断され、以下のようにUbuntuベースにSSH + Dockerエンジンをインストールしたバージョンを再ビルドして配布しました。
https://hub.docker.com/repository/docker/edowon0623/docker-server/general
上記で発生した問題等は全て解消されたことを確認しました。 Ubuntnでは、Dockerサービスを起動するために、以下のコマンドを先に実行してください。
service start docker今後も、DinDの問題など、実習に関連する問題が確認されたように、更新された実践環境を提供します。
来週は連休ですね。私個人的に多事多難した2024年でしたが、新しい心で新しい一年を始めるようにします。今年は、より良い講義で頻繁に訪れましょう。明けましておめでとうございます。
ありがとうございます。
** ansible-serverからwindowsのK8sへのテスト時のリファレンス
ansible-serverを利用してWindowsにインストールしたdocker-desktopのKubernetesに接続してテストを行う場合は、以下の内容を確認してください。
ansible-serverでssh-copy-idコマンドを利用してwindowsにid_rsa.pubキーファイルの内容をコピーしようとすると、通常のキーファイルの内容ではなく、ECHO〜という文字列がシャベルになってしまう場合があります。この場合は、ssh-copy-idコマンドの代わりに、対応するid_rsa.pubキーファイルの内容を直接コピーして使用する必要があります。何らかの方法を使用した結果として、 windows の .ssh フォルダにある authorized_keys ファイルに ansible-server で生成したid_rsa.pubキーファイルの内容が保存されればよい。この時の注意点は、ansible-serverにログインしたアカウントとwindowsサーバーにログインするアカウントとが一致しなければならず、そのアカウントはwindowsで管理者権限を持っている必要があり、dockerやkubectlなどの命令を使用する際にエラーが発生しないではありません。要約すると、Windowsにログインするアカウントと同じアカウント名でansible-serverのアカウントを作成した後、キーをコピーする必要があります。このような過程が煩わしい場合は、ssh接続時に認証なしで接続するためにssh-copy-idコマンドを使用するので、この部分はそのままパスワードを入力しながら進行し、ansible-playbookではansibleのhostsファイルにwindows接続情報を記録するご使用いただくと、playbookの実行時には問題なく進行できます。
以下の実行プロセスの説明を参照してください。
Windows OS (docker-desktop インストール、Kubernetes 実行、IP: 192.168.0.7)
docker-server (ドッカーコンテナ、IP: 172.17.0.3)
ansible-server(Dockerコンテナ、Ansibleインストール、IP:172.17.0.4)
まず、ansible-serverで生成されたid_rsa.pubキーをdocker-serverにssh-copy-idコマンドを使用してコピーします。 docker-serverのキーをコピーして、sshがパスワードなしで接続されていることを確認してください。

ansible-serverのid_rsa.pubキーをwindowsサーバーにコピーします。 (下の画像は docker-server になっていますが、ansible-server から進んでください)。ただし、 id_rsa.pubキーを生成する際のアカウントと windows の openssh に接続するアカウントが同じでなければならず、その windows アカウントには docker や kubectl コマンドを実行できる管理者権限を持っている必要があります。このとき、ssh-copy-idコマンドを使用してid_rsa.pubキーのコピーを試みると、Windowsのauthorized_keysファイルにid_rsa.pubキーの内容がコピーされるのではなく、ECHO~という文字列がコピーされてしまう場合がありますが、このような場合は、そのキーを直接COPY-PASTE方式でWindowsのauthorized_keysファイルにコピーしてください。 (authorized_keysファイルがwindowsにない場合は、ファイルも直接作成できます)

id_rsa.pubキーをコピーする作業をする前に、以下の4)のようにwindowsでsshコマンドを使ってwindowsサーバーに接続されることを確認してください。 (opensshがインストールされていない場合はインストールしてください。)

今回は、ansible-serverから直接sshコマンドでWindowsのopensshサーバーに接続するテストをしてみてください。

上記の2で説明したように、 id_rsa.pubキーをコピーするときは、 id_rsa.pubキーをWindowsのアカウントと同じアカウントで作成する必要があります。を記録して使用することをお勧めします。とにかくsshコマンドを使用して直接接続を試みる場合よりも、ansible命令を使用して処理する場合が多いので、ssh-copy-id操作を進めることなく直接ansible hostsファイルに接続情報を保存して使用するようにします。このセクションでは、ansible_user、ansible_passwordエントリにWindowsアクセスアカウント情報(私は管理者権限を持つユーザーアカウント情報とパスワードを入力しました)を変更できます。 ansible hosts ファイル情報を完成したら、次の ansible 命令を使って ping モジュールが正常に実行されていることを確認してください。
ansible windows -m in_ping -u [windows アカウント]

ansible-playbook を実行する前に、windows に K8s の manifest ファイルが保存されている場所を確認し、kubectl コマンドを使って Kubernetes のリソースを確認してみます。以下の例では、K8sのサービスのリストを確認しており、基本的に作成されるサービス以外のユーザーが作成したサービスは見えないことを確認しています。

ansible-serverでplaybookファイルの内容を確認します。 windowsにコマンドを渡すので、以下の例のようにwin_commandコマンドを使用し(MacOSの場合はcommandコマンドを使用)、実行したいマニフェストファイルの場所を絶対パスとして指定します。 playbookファイルを実行して実行された結果を確認できます。

最後に、windowsで実行したリソースが正常に反映されたか、kubectl命令を利用して確認してみることができます。

上記についてさらに質問がある場合は、質問掲示板に書いてください。
問題が悩んでいた方々にお役に立てば幸いです。
ありがとうございます。
こんにちは、離島院です。
「Jenkinsを利用したCI/CD Pipelineの構築」講義を進めながら、実習環境構成に苦労する方が多く、VMで環境構成を扱う部分についての講義を別途製作して共有することになりました。練習環境は、WindowsおよびMacOS(Intell chip)ユーザーの方が従来のDocker+SSH環境ではなく、VirtualBoxを利用した環境でVMを構成してみることができるようにしました。 VMにインストールされたDockerを利用して、少しでも簡単に実習環境を構成しましたので、参考にしてください。
ありがとうございます。
こんにちは、離島院です。
まず、講義に関心を持ってくださった方々に感謝の挨拶をいたします。
この講義は、実践が基本的に一緒になるべき講義です。特にJenkinsやTomcatやDockerサーバーは直接インストールして練習してみることをお勧めします。
残念ながら、一部の受講生の方(特に、Windows)が実習を進めるために必要な環境構築に困難があると文を残していただきました。私は関連リソースとスクリプトを共有しましたが、解決できない受講生の方には申し訳ありません。
先に共有していただいた、質問回答および追加映像などを通じてWindows+SSH+Dokcer環境での実習ガイドを提供していただきましたが、追加して確認された事項があり共有します。
Windows)SSHサーバー(with docker)実行命令(方法1)
docker run --privileged --name docker-server -itd -p 10022:22 -p 8081:8080 -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup edowon0623/docker:latest /usr /sbin/init
Windows)SSHサーバー(with docker)実行命令(方法2、上記の命令で実行されない場合)
docker run -itd --name docker-server -p 10022:22 -e container=docker --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v / var/run/docker.sock:/var/run/docker.sock edowon0623/docker:latest /usr/sbin/init
私たちがテストした一部のWindows PCでは、以下の実習方法がすべて正常に動作していましたが、最近購入したWindows PC(WSL2インストール)で実習1度にエラーがあることを確認しました。現在把握したエラーの原因は、WSL2でiptablesの生成過程で以下のようなエラーが発生することでした。テストしてみると、現在までは大きな問題なく実習が可能と判断され、該当イメージとDockerfile共有します。
https://hub.docker.com/r/edowon0623/docker/tags -> docker pull edowon0623/docker:no_iptables
https://github.com/joneconsulting/docker-files
したがって、Windows環境でDind方式(実習スクリーブ方法1)でDockerサーボが起動されない場合は、以下のコマンドを使って実習してみてください。
Windows)SSHサーバー(with docker)実行命令(方法3)
docker run --privileged --name docker-server -itd -p 10022:22 -p 8081:8080 -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup edowon0623/docker:no_iptables /usr /sbin/init
もちろん、該当のDockerコンテナを起動した後に、SSH接続後、systemctl start dockerコマンドを実行していただき、Dockerサーバが起動されます。
もう一度、講義に関心をお寄せいただきありがとうございましたら、より良いコンテンツを持って新しい講義も準備させていただきます。
ありがとうございます。
こんにちは、離島院です。
Jenkinsを使用したCI / CD Piplineの構築講義でNodejsで書かれたアプリケーションをデプロイする方法について講義資料を追加しました。このコンテンツを去る9月からリクエストしましたが、多くもない分量だったにもかかわらずアップロードします。資料が遅すぎてアップロードされて申し訳ありません。
NodejsアプリケーションをPM2というProcess Managerで起動しながら、これをDockerイメージとしてデプロイして実行するプロセスについて説明しています。不足している資料ですが、必要な方に少しでも役立つことを願って、追加の質問事項のある部分は掲示板に書いてください。最近、プロジェクトの締め切りですぐに確認できませんでしたが、できるだけ早く確認して回答させていただきます。
残りの2022年一年無駄によく仕上げてください。
ありがとうございます。

