こんにちは、OSS よろず相談室の鹿島です。 今回は、DifyとAmazon Bedrockを連携させて、チャットボットとRAG（検索拡張生成）を構築する手順の3回目です。 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ 前回は、Dify環境の構築とAmazon Bedrockとの連携方法について解説しました。 今回はその環境を使い、Difyで最も基本的なアプリケーションの一つであるチャットボットを作成します。 チャットボットは、ユーザーからの質問に対し、一問一答形式で回答を返すシンプルなアプリケーションです。複雑な設定は不要で、AIアプリ開発の第一歩として最適です。 ステップ１：チャットボットの作成準備 まず、Difyにアクセスします。 http://[DifyをインストールしたマシンのIPアドレス] ① の記事で解説した手順でアカウントを作成・ログインすると、ホーム画面が表示されます。 画面中央にある 「最初から作成」 をクリックしてください。 表示された画面で、「初心者向けの基本的なアプリタイプ」を選択し、 「チャットボット」 を選択します。 アプリの設定画面が開きます。 「アプリのアイコンと名前」 に任意の名前を入力します。 チャットボットの設定画面が表示されます。 ステップ2：モデルの選択と確認 接敵画面の右上に、 ② で設定したAmazon BedrockのLLMモデルが設定されていることが確認できます。 Bedrock Modelを確認し、Amazon Bedrockのコンソール画面で、 ② の作業でアクセスが付与されたModelが選択されているかを確認してください。 当記事では、Nova Microのアクセスが許可されているため、Difyの初期設定では Nova Pro が選択されていました。 [202509_チャットボット6.png] このような場合はモデルを変更してNova Microにします。 なお、Nova Proが選択されたままチャットボットに質問を入力すると、アクセス許可がないというエラーが表示されます。 [202509_チャットボット8_error.png] エラーメッセージ抜粋 [bedrock] Error: PluginInvokeError: {"args":{"description":"[models] Error: AccessDeniedException: You don't have access to the model with the specified model ID."},"error_type":"InvokeError","message":"[models] Error: AccessDeniedException: You don't have access to the model with the specified model ID."} ステップ３：動作テスト モデルの設定が完了したら、実際にチャットボットを使ってみましょう。 画面右下のチャット欄（「Bot と話す」）に、試しに何か質問を入力します。 1. 基本的な動作テスト まずは、何も設定しない状態で質問してみます。 今回は、「オーストラリアの首都はどこですか？」と質問してみます。 [202509_チャットボット7.png] 無事に回答が返ってきたので、チャットボットの作成は成功です。 2. プロンプトで応答をコントロールする 今度はプロンプトを指定してみます。 プロンプトとは、AIに事前に与える指示やルールのことです。 ここを工夫することで、AIのキャラクターを設定したり、回答スタイルを細かく指定したりできます。 試しに、「30文字以内で回答する」というシンプルな指示を与えてみましょう。 先ほどと同じ「オーストラリアの首都はどこですか？」と質問します。 30文字以内のシンプルな回答が返ってきました。 今度は、プロンプトに「あなたはツアーコンダクターです。地名について聞かれた場合、歴史背景も踏まえて回答してください。」と指示をします。 同じ質問をしてみると… 歴史背景も踏まえた詳しい回答を得ることができました。 3. さらに高度な機能 Difyには、他にも高度な機能が用意されています。 変数 (Variables) プロンプト内に {{input}} のように変数を埋め込むことで、ユーザーが入力した内容を指示文の中で再利用できます。これにより、より複雑で動的な応答を作り出すことが可能です。 コンテキスト (Context) 事前にPDFやテキストファイルなどの資料を「ナレッジ」としてアップロードしておくと、AIがその資料の内容だけを元に回答するよう制限できます。これにより、社内マニュアルに基づいたQ&Aボットなどを簡単に作成できます。 これらの機能の詳しい使い方については、ぜひ公式のドキュメントも参照してみてください。 ▼Dify公式ドキュメント（チャットボット） https://docs.dify.ai/ja-jp/guides/application-orchestrate/chatbot-application ステップ４：アプリケーションの公開 チャットボットの設定が完了したら、Webアプリとして公開し、他の人が使えるようにします。 画面右上の「公開する」を選択して、アプリケーションとして公開します。 公開したアプリケーションのURLは、左上のロボットマークをチェックすると確認することができます。 おわりに 今回は、DifyとAmazon Bedrockを連携させた環境で、基本的なチャットボットを作成しました。簡単なステップでAIアプリケーションが作成できることを実感いただけたと思います。 次回は、Dify+ Amazon Bedrock で RAGを使う方法を検証します。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ first appeared on SIOS Tech. Lab .

はじめに 前回の記事ではLinuxサーバーにGitLabを構築する方法について解説しました。今回からは構築したGitLabの様々な機能について紹介していきます。今回はGitLabのコンテナレジストリを利用してコンテナイメージを格納したり、格納したイメージをpullして取得する方法を解説します。 前提条件 本記事で解説する環境は、Omnibusパッケージを用いてインストールしたLinux版GitLabを利用しています。 GitLabのエディションはCommunity Editionを利用しています。 また、GitLab本体およびGitLab Container Registryの双方にカスタムドメインを割り当て、自己署名証明書を導入しています。 詳細な環境情報については 前回の記事 をご参照ください。 GitLab Container Registryとは コンテナレジストリとは、アプリケーションのコンテナイメージを保存・管理し、チーム内やシステム間で共有するための仕組みです。GitLabにはこのコンテナレジストリ機能が標準で搭載されており、追加の外部サービスを利用しなくても、GitLabのプロジェクト内でイメージのビルドから保存、配布までを完結できます。特に、Docker Hubのように一般公開を前提としたパブリックレジストリと比べると、GitLab Container Registryは閉域環境や社内ネットワークでプライベートに運用できる点が大きな強みです。 パブリックレジストリとプライベートレジストリの利用スタイルの違いは以下のとおりです。 項目 パブリックレジストリ （例: Docker Hub, Quay.io） プライベートレジストリ （例: GitLab Container Registry, Harbor） 利用範囲 全世界のユーザーがアクセス可能 組織やチームの内部利用に限定可能 接続要件 インターネット接続が必須 閉域ネットワークや社内環境でも利用可能 認証・制御 公開イメージは誰でも取得可能、制御は限定的 細かいアクセス制御が可能 メリット OSSイメージを容易に入手可能配布 セキュリティやガバナンスを自社内で統制可能 デメリット Rate Limitや可用性リスクをサービス提供者に依存 自社運用では構築・保守費用が発生 また、ソースコードのリポジトリとコンテナイメージを同じGitLab上で管理できるため、CI/CDパイプラインとシームレスに連携できます。その結果、コードの変更からイメージのビルド、デプロイまでを一貫したワークフローとしてシンプルかつ安全に実現できます。 設定方法 GitLab Container Registryは、Omnibus版GitLabでは基本的にインストール直後から有効になっています。ただし、独自ドメインを使いたい場合やデータ格納パスを変更したい場合には、構成ファイル /etc/gitlab/gitlab.rb を編集して設定を行います。 主な設定項目は以下のとおりです。 公開 URL：registry_external_url TLS 証明書と秘密鍵：registry_nginx[‘ssl_certificate’] / registry_nginx[‘ssl_certificate_key’] レジストリのデータ保存先：gitlab_rails[‘registry_path’] 設定例： registry_external_url "https://registry.gitlab.local.example.com" registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.local.example.com.crt" registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.local.example.com.key" gitlab_rails['registry_path'] = "/mnt/gitlab-registry" 編集後は以下を実行して反映します。 $ gitlab-ctl reconfigure 参考： GitLab container registry administration 前回記事：GitLabとコンテナプラットフォームの連携 | SIOS Tech. Lab レジストリ基本操作 レジストリの基本操作は次のとおりです。 レジストリへのログイン ローカルからコンテナイメージをpush レジストリからコンテナイメージをpull 以下では実際の手順を紹介します。なお、操作例はRHEL環境でPodmanを使用していますが、Docker環境ではpodmanをdockerに置き換えてください。 レジストリへのログイン $ podman login registry.gitlab.local.example.com Username: <GitLabのユーザー名> Password: <ログインするユーザーのパスワード> Login Succeeded! ※ログイン認証について： ユーザー名とパスワードでもログイン可能ですが、実運用ではPersonal Access Token (PAT) の利用が推奨されます。PATのスコープにはread_registryとwrite_registryを指定してください。ログイン時のパスワード欄にPATを入力すればより安全にpush/pullすることが可能です。 イメージのpush ブラウザからGitLabのコンソール画面にログインし、任意のプロジェクトを作成します。 GitLabプロジェクトの作成方法については こちらの記事 も参考にしてください。 プロジェクトの [デプロイ] > [コンテナレジストリ] メニューに移動すると、そのプロジェクト専用のレジストリが表示されます。 レジストリURLは以下の形式になります。 <コンテナレジストリの公開URL>/<ユーザー名またはグループ名>/<プロジェクト名> ※Namespaceの確認方法： 個人所有のプロジェクト → namespaceはユーザー名 グループ配下のプロジェクト → namespaceはグループ名 GitLabプロジェクトのURLを見ると確認できます。 例： https://gitlab.local.example.com/demo-group/hello-nginx→namespaceはdemo-group、projectはhello-nginx 参考： GitLab container registry 作成したプロジェクトのレジストリにイメージを格納してみます。 今回のデモでは、nginxをベースにしたシンプルなWebサーバーのコンテナを作成します。サンプルのindex.htmlをコンテナ内に組み込み、ブラウザからアクセスするとページが表示される仕組みです。 まずは、GitLabにアクセス可能な作業用端末にログインし、ターミナルを起動します。 任意のディレクトリで以下のようなサンプルのDockerfileとindex.htmlを作成します。 $ vi Dockerfile FROM nginx:alpine COPY index.html /usr/share/nginx/html/index.html $ vi index.html <!doctype html> <html lang="ja">   <meta charset="utf-8">   <title>Hello GitLab Registry</title>   <h1>Hello GitLab Registry</h1> </html> Dockerfileを作成したディレクトリで以下のコマンドを実行し、イメージをビルドします。 $ podman build -t <レジストリのパス>/<イメージ名>:<任意のタグ> . # 実行例 $ podman build -t registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 . イメージのビルドが成功したら、イメージをGitLabのレジストリにpushします。 $ podman push <レジストリのパス>/<イメージ名>:<任意のタグ> # 実行例 $ podman push registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 The push refers to repository [registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx] 001b285e90c0: Pushed  ...（省略） v1.0: digest: sha256:98ed22db613e039a43ceb3416a66fcdfc7b6f040d1f1435acc20406cb1725504 size: 2196 GitLabのコンソール画面にログインし、イメージをpushしたプロジェクトのレジストリ画面に移動します。 pushしたコンテナイメージがGitLabのレジストリに保存されたことが確認できます。 イメージのpull 今度はGitLabのレジストリからイメージを取得してみます。 まずはローカルの同名イメージを削除します。 $ podman rmi registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 2>/dev/null || true Untagged: registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 ...（省略） Deleted: sha256:0a9426ad0f5bca69d275b08131d490b512b022a943ac0a65cc8b651945b288ca GitLabのレジストリから先ほどpushしたイメージを指定してローカルにpullします。 $ podman pull <レジストリのパス>/<イメージ名>:<任意のタグ> # 実行例 $ podman pull registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 v1.0: Pulling from registry-test-group/registry-test-project/nginx ...（省略） Status: Downloaded newer image for registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 pullしたイメージを利用してコンテナを起動します。 $ podman run --rm -d --name hello-nginx -p 8080:80 registry.gitlab.local.example.com/registry-test-group/registry-test-project/nginx:v1.0 ブラウザを起動し、http://localhost:8080にアクセスするとビルドしたイメージ内のindex.htmlの内容が表示されます。 これでレジストリから取得したイメージを利用してコンテナを起動できることが確認できました。 まとめ 今回はGitLab Container Registryの設定方法と基本操作について紹介しました。GitLabのレジストリは、Docker Hubと同じ感覚で利用できるだけでなく、ソースコードと同じ場所で統合管理できる点が強みです。次回は、イメージの公開範囲の制御やガベージコレクションなど、運用に役立つ応用設定について紹介します。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitLab Container Registry: 基本設定と利用方法 first appeared on SIOS Tech. Lab .

はじめに これまでのブログ では、Gitの基本的な使い方を学び、GitLab上でリポジトリを連携させる方法を解説してきました。これで、Gitの基本的な機能はバッチリです。 今回は、Gitの知識をさらに広げ、GitLabが提供する機能群に焦点を当てます。GitLabの画面と主要な機能について解説します。特に、チーム開発、CI/CD、そしてセキュリティという3つの側面からGitLabの役割を見ていきます。GitHubとの違いについても触れることで、GitLabの強みがより明確になります。 GitLabの主な利用機能とGithubとの違い GitLabは、DevOpsライフサイクル全体を一つのプラットフォームでカバーすることを目指しています。これが、単一の機能に特化した他のツールとの最も大きな違いです。 プロジェクト GitLabにおける「プロジェクト」は、GitHubにおける「リポジトリ」に相当するものです。ただし、GitHubのリポジトリが主にコードを管理する場所であるのに対し、GitLabのプロジェクトはそれ以上の機能を持っています。コードを格納するGitリポジトリはもちろん、イシュー管理、CI/CD、Wiki、セキュリティレポートなど、開発に必要なすべての機能がこのプロジェクトに紐づいています。プロジェクトは、GitLabにおける作業の単位であり、開発の中心です。 プロジェクトのホーム画面です。画面左のメニューから様々な機能にアクセスできます。 CI/CD CI/CD（継続的インテグレーション/継続的デリバリー）機能をプラットフォームに最初から組み込んでいます。.gitlab-ci.ymlという一つのファイルで、コードのテスト、ビルド、デプロイまでを自動化できます。 CI/CDを構成する一連の自動化された処理は、「パイプライン」として視覚化されます。 メニューのビルド＞パイプラインからパイプラインの実行履歴などを確認することができます。.gitlab-ci.ymlの作成方法やパイプラインの実行方法などは第8回で詳しく説明します。 セキュリティ ソースコードの脆弱性や機密情報を自動で検知するセキュリティ機能も、GitLabのコア機能として統合されています。開発の初期段階からセキュリティを考慮したDevSecOpsを容易に実現できます。 メニューのセキュリティ＞セキュリティ設定からセキュリティ機能の設定が可能です。これらのセキュリティ機能を設定すると、.gitlab-ci.ymlにテスト・スキャン実行の設定が追加されます。 GitHubとの差分 GitHubでのCI/CDやセキュリティ機能は、GitHub ActionsやGitHub Advanced Securityといった、機能ごとに独立したサービスとして提供されます。これに対し、GitLabは最初からオールインワンで統合されており、簡単に利用できる点が大きな違いです。つまり、GitHubが多様なツールを組み合わせて利用する「拡張性」を重視するのに対し、GitLabはすべての機能をプラットフォーム内に集約する「統合性」と「一貫性」を重視しています。   チーム管理で利用される機能 Issue管理 タスク、バグ、機能追加の要望などを管理するための機能です。Issueには担当者を割り当てたり、ラベルを付けたり、期限を設定したりできます。また、イシューボードを使うことで、タスクの進捗状況を視覚的に把握できます。 メニューの計画＞イシューからIssueの管理が可能です。 イシューの作成をしてみます。 [新しいイシュー]をクリックします。 タイトルと説明を入力します。入力したら、[イシューを作成]をクリックします。 他にも担当者や開始日/期限などが設定可能です。 作成出来たら、イシューの詳細画面に映ります。 イシューも作成できたので、メニューの計画＞イシューボードを見てみましょう。 ここでは、イシューをステータスごとに一覧で視覚的に管理することができます。 新しいステータスの項目を追加したり、イシューをドラッグアンドドロップで直感的に操作することができます。 マージリクエスト機能 GitHubのプルリクエストにあたる機能です。これは単にコードをマージするための申請ではなく、コードレビュー、CI/CDの結果確認、セキュリティスキャンを1つの画面で行うことができます。 マージリクエストの実際のフローについては、 第5回 を参考にしてみてください。   CICD GitLabの強みであるCI/CD機能は、コードの変更を検知してテストやビルドなどを自動で行い、開発プロセスを自動化します。GitLabとGitHubのCI/CD機能について簡単に紹介します。 GitLab Runner CI/CDパイプラインのジョブを実行するためのエージェントです。オンプレミスのGitLabでは自社のサーバーにRunnerを設置できるため、社内ネットワーク内の環境を利用した自動化が容易になります。GitLab runnerについては第8回で詳しく説明します。 GitHub Actions GitHubが提供するCI/CDサービスです。GitLab CI/CDと同様に、YAMLファイルでワークフローを定義し、ジョブを自動実行します。   セキュリティ GitLabは、開発の初期段階からセキュリティを組み込む「DevSecOps」を重視しています。GitLabとGitHubのセキュリティ機能について簡単に紹介します。どちらのプラットフォームも、コードの脆弱性や機密情報を自動で検知するセキュリティ機能を提供していますが、利用できる機能の範囲は、契約しているプラン（Free, Pro, Enterpriseなど）によって異なります。 GitLab：コードの静的解析 Static Application Security Testing（SAST） コードのビルドや実行前に、ソースコードに潜在する脆弱性やバグを自動的に検知します。CI/CDパイプラインに組み込むことで、問題のあるコードがマージされるのを防ぎます。 GitLab：認証情報検知 ソースコードにハードコードされたパスワードやAPIキーなどの機密情報を検知し、情報漏洩のリスクを減らします。 GitHub：Code scanning・Secret scanning GitHubにも同様の機能があります。GitLabとの違いは、これらのセキュリティ機能がGitLabでは単一のプラットフォームに統合されている点です。   まとめ 今回は、GitLabが提供するプロジェクト管理、CI/CD、そしてセキュリティの各機能について、GitHubとの違いを交えながら解説しました。 GitLabは、コード管理に加えて、チーム管理のためのイシュー機能、開発を自動化するCI/CD、そしてコードの安全性を確保するセキュリティ機能まで、開発ライフサイクルのすべてを一元管理できる強力なDevOpsプラットフォームです。 次回以降のブログでは、今回紹介した各機能について、より詳細な設定方法や具体的な活用例を実践的に解説していきます。 参考文献 https://docs.gitlab.com/user/project/organize_work_with_projects/ https://docs.gitlab.com/user/project/issues/ https://docs.gitlab.com/topics/build_your_application/ https://docs.gitlab.com/user/application_security/secure_your_application/ https://docs.gitlab.com/ci/migration/github_actions/#key-similarities-and-differences https://docs.github.com/ja/actions https://docs.github.com/ja/get-started/learning-about-github/about-github-advanced-security ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (6) ～Git マスターへの道～「GitLabの画面説明とよく利用される機能説明」 first appeared on SIOS Tech. Lab .

はじめに どうも、今月はあまりブログを書くことができなかった龍ちゃんです！ ブログを書かなかった時というのは、大体何かしらの検証に時間を取られていたという理由なのですが、今月は主に Claude Codeで実際にVibe Codingを行う という検証をしていました。その中で、Claude Codeをいろんなプロジェクトに適用して使ってみるというところなのですが、まず基本となる環境整備が重要だなと感じています。先月までは、「 Claude×技術ブログ 」というテーマで11本ブログを執筆していました。 今回は、 DevContainerにClaude Codeを導入する方法 について詳しく解説していきます。これから Claude Code を使って開発を始めたい方や、既存の開発環境に組み込みたい方の参考になれば幸いです。 なぜDevContainerでClaude Codeなのか？ 私が基本的に開発をDevContainerで行っている理由は、いくつかのメリットがあるからです。 セキュリティと安全性の向上 rmコマンドで誤ってファイルを壊されるのを防止する という点が大きいですね。Claude Codeは強力なツールですが、AIがコマンドを実行する以上、予期せぬ操作のリスクもゼロではありません。DevContainer環境であれば、最悪の場合でもコンテナを作り直せば元通りです。 チーム開発での設定管理 複数人でコードを開発していく時に、 リポジトリ単位で設定を切り分ける ことができます。プロジェクト固有の設定などがユーザー設定の部分で混在すると管理が大変ですが、DevContainerなら各プロジェクトで独立した環境を維持できます。 Claude Codeの権限制御 さらに重要なのが、 Claude Codeに見える範囲を限定する ことです。権限を与えるとどこまででもディレクトリ走査のようなことができてしまいますが、マウントするファイルを限定することによって 影響範囲を小さくする ことができます。 Claude Codeのインストールコマンド どちらの方式でもnpm形式を用いてインストールを行います。 公式の情報に乗っているコマンドでインストール を行います。 npm install -g @anthropic-ai/claude-code 基本パターン：Node.jsベースイメージでの導入 最もシンプルな方法 NodeのベースイメージにClaude Codeをインストールする というのは一番簡単な方法です。Nodeのベースイメージなので、npmコマンドがそのまま使えて、追加の設定も最小限で済みます。 実装方法は2つあります：カスタムのDockerfileで構築する方法と、DevContainerの起動コマンドでインストールする方法です。どちらでも問題ないのですが、私は再現性を重視してDockerfile方式を推奨しています。 Dockerfile方式 # .devcontainer/Dockerfile FROM mcr.microsoft.com/devcontainers/typescript-node:1-22-bookworm WORKDIR /home/node/ USER node # Claude Codeとnpmを最新版にアップデート RUN npm install -g \ npm@11.5.2 \ @anthropic-ai/claude-code # バージョン確認用コマンド（デバッグ用） RUN echo "=== Installed Versions ===" \ && node --version \ && npm --version \ && echo "=========================" # デフォルトコマンド（devContainerではsleep infinityで上書きされる） CMD ["sleep", "infinity"] PostCreateCommand方式 { "name": "Claude Code Development Environment", "image": "mcr.microsoft.com/devcontainers/typescript-node:1-22-bookworm", "workspaceFolder": "/home/node/workspace", "remoteUser": "node", "postCreateCommand": "npm install -g npm@11.5.2 @anthropic-ai/claude-code", "forwardPorts": [3000, 8000], "mounts": [ "source=${localEnv:HOME}/.claude,target=/home/node/.claude,type=bind,consistency=cached", "source=${localEnv:HOME}/.claude.json,target=/home/node/.claude.json,type=bind,consistency=cached" ] } どちらの方式でも機能的には同じですが、 Dockerfile方式の方が起動が早く、確実性が高い と感じています。 応用パターン：他のベースイメージでの導入 Python環境での導入例 Nodeのベースイメージ以外にClaude Codeを導入する場合、 まずベースイメージでNodeを使えるようにする必要 があります。 他のベースイメージでNodeを使えるようにするには、カスタムDockerfileでNodeを自力でインストールするか、DevContainer Featuresの便利な機能を使うかの2つの方法があります。 カスタムDockerfile方式 # .devcontainer/Dockerfile FROM mcr.microsoft.com/devcontainers/python:3.11 # Node.jsのインストール（最新LTS v22） RUN curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - \ && apt-get install -y nodejs # 実行ユーザーに変更 USER vscode # Claude Codeのインストール RUN npm install -g \ npm@11.5.2 \ @anthropic-ai/claude-code DevContainer Features方式 { "name": "Python 3.11 + Claude Code Development Container", "image": "mcr.microsoft.com/devcontainers/python:3.11", "workspaceFolder": "/workspace", "features": { "ghcr.io/devcontainers/features/node:1": {} }, "postCreateCommand": "npm install -g npm @anthropic-ai/claude-code", "forwardPorts": [8000], "remoteUser": "vscode", "mounts": [ "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached", "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached" ] } DevContainer Features方式 が圧倒的に簡単 ですね。Node.jsの詳細なインストール手順を書く必要がなく、 features セクションに一行追加するだけです。 その後、Nodeが使える環境であれば、Node以外のベースイメージでも npm で Claude Code をインストールするのが簡単な方法になります。 設定ファイルのマウント設定 認証情報の永続化 Claude Codeの設定ファイルをマウントする というのも重要で、これはどちらの方法でも設定しておくと良いでしょう。これによって認証情報が渡されるので、 DevContainerを起動したタイミングで毎回認証情報を入力する必要がなくなります 。 また、履歴などの過去の記録もマウントされるので、Claude Codeの設定ファイルが保存されるという点も良いところだと考えています。 マウント設定の詳細 { "name": "Research Project", "build": { "dockerfile": "./Dockerfile" }, "workspaceFolder": "/home/node/dev", "remoteUser": "node", "mounts": [ "source=${localEnv:HOME}/.claude,target=/home/node/.claude,type=bind,consistency=cached", "source=${localEnv:HOME}/.claude.json,target=/home/node/.claude.json,type=bind,consistency=cached" ] } 設定ファイルの役割 Claude Codeでは2つの設定ファイルが重要な役割を果たしています。 .claude.json ファイル ホームディレクトリにある単体ファイル（ ~/.claude.json ）で、 Claude Codeのメイン設定を管理 します。プロジェクト設定、MCPサーバー（外部ツール連携）、API認証情報、初期設定の完了状態などが保存されています。 2025年現在、このファイルが最も重要で推奨される設定方法 とされています。 .claude ディレクトリ ホームディレクトリ内のフォルダ（ ~/.claude/ ）で、 拡張機能やカスタマイズ要素を格納 します。 commands/ フォルダにはカスタムスラッシュコマンド、 agents/ フォルダにはAIサブエージェントが保存され、その他の詳細設定ファイルも含まれます。 使い分けのポイント .claude.json : 基本的な動作設定 .claude/ ディレクトリ : 機能拡張やカスタマイズ この2つのファイル・ディレクトリをマウントしておくことで、DevContainer環境でも継続的にClaude Codeの設定を利用できます。 まとめと今後の展望 今回は、 Claude Codeを開発環境に取り入れるための方法 について詳しく解説しました。DevContainer環境でClaude Codeを利用することで、安全性と再現性を保ちながら、AIアシスタント開発の恩恵を受けることができます。 今月は結構いろんなClaude Codeに関する検証を行ったので、来月9月は Claude Codeを実際に使ってみた例や、プロトタイピングに適用して作ったものの紹介 もできるかなと考えています。 Codexなども出ているので、そちらに乗り換えることもありますが、Claude Codeを契約してから約4カ月になるので、半年は Claude Codeを使った開発をメインに進めていこう と考えています。 皆さんも、ぜひClaude CodeとDevContainerの組み合わせを試してみてください。開発効率が大幅に向上すること間違いなしです！ 次回は実際の活用例をお届けする予定ですので、お楽しみに〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code×DevContainer環境構築ガイド – Node.js・Python対応 first appeared on SIOS Tech. Lab .

はじめに OpenShiftクラスターの運用において、「意図しない設定のリソースがデプロイされてしまう」「特定のネームスペースのリソースには必須のラベルを付与したいが、手動だと漏れがあるので自動化したい」といった課題はありませんか？ 本記事では、Kubernetesネイティブなポリシーエンジンである Open Policy Agent (OPA) と、それをKubernetesに適用する Gatekeeper をOpenShift環境に導入する手順を解説します。さらに、非接続環境での考慮事項も取り上げることでエンタープライズ環境に即した知見を共有します。 OpenShiftには専用の Gatekeeper Operator が存在し、簡単にGatekeeperを導入できるメリットがありますが、本記事ではOSS版Gatekeeperの導入に焦点を当てて解説します。 OPA/Gatekeeperについて Open Policy Agent (OPA) は、一般的なポリシーエンジンです。アプリケーションやシステムを問わず、統一された方法でポリシーを定義・適用することを可能にします。一方、 Gatekeeper は、そのOPAをKubernetesのAdmission Controllerとして利用するためのツールです。 Gatekeeperの動作イメージは図のようになります。ユーザーがKubernetesリソースをデプロイしようとすると、Gatekeeperはそのリクエストをインターセプトし、事前に定義されたOPAのポリシー（Regoと呼ばれる言語で記述）に照らして評価します。リクエストがポリシーに違反していなければ、APIサーバーはリソースをデプロイします。一方、違反していればデプロイは拒否されます。これにより、継続的なポリシー制御でクラスター内のリソース設定を強制し、組織全体で統一したポリシー運用が可能になります。 事前作業（非接続環境での準備） インターネット接続環境と異なり、非接続環境では外部のコンテナレジストリに直接アクセスできません。そのため、Gatekeeperのコンテナイメージをプライベートなイメージレジストリに用意する事前作業が必要です。インターネット接続環境に導入する際はこの事前作業は不要です。 前提条件 以下のようなOpenShift非接続環境を前提として構築準備を行います。 外部インターネットに接続できない OpenShift クラスター OpenShift用のミラーレジストリーサーバー OS：RHEL9 Gatekeeperのコンテナイメージを取得できること 作業用サーバー兼踏み台サーバー OS：RHEL9 OpenShiftクラスターにアクセス可能であり、以下の役割を兼任： 内部DNSサーバー、ロードバランサー ※本記事では Gatekeeper の構築に焦点を当てており、作業用サーバーや OpenShift クラスターの構築手順については割愛しています。 イメージレジストリへのイメージ取得 ミラーレジストリサーバーでイメージレジストリにGatekeeperが必要とするコンテナイメージを取得します。 ミラーレジストリ構築時に使用したImageSetConfigurationファイルを編集します。additionalImagesにname: docker.io/openpolicyagent/gatekeeper:<バージョン>を追加します。今回は2025年8月時点で最新のv3.20.0を導入します。 apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror:   platform:     channels:     ...   operators:   additionalImages:     ...     - name: docker.io/openpolicyagent/gatekeeper:v3.20.0   helm:     ... リポジトリのミラーリングを実施します。 例：$ oc mirror -c ImageSetConfiguration.yaml --workspace file:///$HOME/work/mirror-image docker://<ミラーレジストリーサーバーのホスト名>:8443 --v2 Gatekeeperのイメージ参照先を変更 OpenShiftクラスターにGatekeeperをデプロイする際、マニフェストファイル内のイメージ参照先を、準備したプライベートなイメージレジストリに変更します。 作業用サーバーでGatekeeperのマニフェストファイルをダウンロードします。 $ curl -O https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.20.0/deploy/gatekeeper.yaml Deploymentのimageの取得先を表示例のように全て変更します。 Deploymentはgatekeeper-auditとgatekeeper-controller-managerの2つが存在しています。 $ vi gatekeeper.yaml 変更前 image: openpolicyagent/gatekeeper:v3.20.0 変更後 image: <ミラーレジストリーサーバーのホスト名>:8443/openpolicyagent/gatekeeper:v3.20.0 構築作業 2025年8月時点で最新のGatekeeper：v3.20.0をOpenShiftクラスターに導入していきます。 Gatekeeperの導入 作業用サーバーでGatekeeperのデプロイを実施します。 インターネット接続環境の場合は以下のコマンドで簡単にデプロイ可能です。 $ oc apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.20.0/deploy/gatekeeper.yaml 非接続環境の場合は、「Gatekeeperのイメージ参照先を変更」で取得したマニフェストファイルを適用します。 $ oc apply -f gatekeeper.yaml Gatekeeperのサービスアカウントにcluster-admin権限を付与します。特に、GatekeeperのサービスアカウントがCRDを作成できる権限を設定する必要があるため、今回は簡易にcluster-adminを付与していますが、本番等での運用では適切に権限を設計することを推奨します。 $ oc adm policy add-cluster-role-to-user cluster-admin -z gatekeeper-admin -n gatekeeper-system Gatekeeperの導入確認 Gatekeeperの以下のPodが立ち上がっていることを確認します。 gatekeeper-audit gatekeeper-controller-manager $ oc get pods -n gatekeeper-system NAME READY STATUS RESTARTS AGE gatekeeper-audit-7c84869dbf-r5p87 1/1 Running 0 2m34s gatekeeper-controller-manager-ff58b6688-9tbxx 1/1 Running 0 3m23s gatekeeper-controller-manager-ff58b6688-njfnd 1/1 Running 0 2m54s gatekeeper-controller-manager-ff58b6688-vlrsl 1/1 Running 0 3m11s Gatekeeperのポリシー適用範囲の設定 Gatekeeperは、クラスター内のすべてのリソースをチェックするのがデフォルトの動作です。しかし、システムが管理するネームスペース（kube-systemやopenshift-で始まるものなど）には、Gatekeeperのポリシーを適用したくない場合があります。これらのネームスペースにポリシーが適用されると、システムの重要なコンポーネントがデプロイできなくなるなどの問題が発生する可能性があります。この考慮漏れで私はOpenShiftクラスターを壊してしまった経験があります。とほほ…。 この問題を解決するために、Configリソースを使ってexcludedNamespaces（除外するネームスペース）を定義します。Gatekeeper導入前からある、ポリシーの適用範囲外にしたいネームスペースをexcludedNamespacesに列挙してください。 $ vi gatekeeper_config.yaml apiVersion: config.gatekeeper.sh/v1alpha1 kind: Config metadata:   name: config   namespace: "gatekeeper-system" spec:   match:   - excludedNamespaces: ["assisted-installer", "default", "gatekeeper-system", "kube-*", "openshift*"]     processes: ["*"] $ oc apply -f gatekeeper_config.yaml これでGatekeeperを使い始める準備は完了です！ まとめ OpenShiftクラスターにOPA/Gatekeeperを導入する基本的な手順を、特に非接続環境での考慮事項に焦点を当てて解説しました。これで、ポリシーベースの運用基盤を構築し、運用ルールの自動化・強制適用が可能になります。 次回の記事では、今回構築した環境を使い、ポリシーの作成方法を解説します。具体的には、リソースの妥当性を検証するバリデーションや、リソースを自動的に変更するミューテーション、といったGatekeeperの動作について詳しく解説します。 参考文献 https://www.openpolicyagent.org/ https://open-policy-agent.github.io/gatekeeper/website/ https://docs.redhat.com/ja/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14/html/governance/gk-operator-overview ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OPA/Gatekeeperで始める安心OpenShift運用：構築編 first appeared on SIOS Tech. Lab .

今号では、systemd.timer で設定可能なパラメータや、実現可能な設定方法について、もう少し深堀りして説明します！ 独自の timer (タイマー)を設定する 前回の記事 では、デフォルトで使用されている .timer の内容から、どのような設定があるのかを確認しました。 今回は、実際に systemd.timer の設定を自分で追加する手順を説明します。 例として、一定の間隔でログに文字を出力するスクリプトを呼び出すタスクを設定してみます。 .service および .timer ファイルを作成する 下記の様な service および timer ファイルを作成します。 /etc/systemd/system/test.service [Unit] Description=test script [Service] Type=oneshot ExecStart=/work/test.sh Description=test script このサービスファイルの概要 Type=oneshot サービスが 1回だけ実行されることを示す (実行タイミングが来るごとに 1回) ExecStart=/work/test.sh 実行するコマンドを指定 /etc/systemd/system/test.timer [Unit] Description=Run test script [Timer] OnCalendar=minutely [Install] WantedBy=timers.target Description このタイマーファイルの概要 OnCalendar=minutely タスク (test.service) が実行される頻度 minutely は毎分 を表す WantedBy=timers.target サービスがどのタイミングで有効化されるか なお、test.service に記載のある /work/test.sh ファイルの内容は下記の通りとなっています。 /work/test.sh #!/bin/bash echo "$(date) testlog" >> /work/test.log タイマーを起動 service ファイルと timer ファイルを追加したため、daemon-reload を実行した後に systemctl で test.timer を起動します。 # systemctl daemon-reload # systemctl start test.timer なお、起動に成功しタイマーが設定されると、下記のコマンドで現在エントリされているタイマーの一覧を確認することができます。 # systemctl list-timers 結果を確認 タイマーの設定どおりにタスクが実行されているか、実際のログから確認してみます。 # cat /work/test.log Fri Aug 1 12:46:04 AM UTC 2025 testlog Fri Aug 1 12:47:04 AM UTC 2025 testlog Fri Aug 1 12:48:04 AM UTC 2025 testlog Fri Aug 1 12:49:04 AM UTC 2025 testlog # ちゃんと毎分(1分ごとに)ログが書き込まれていることが確認できました。 タスクの実行頻度を設定するための tips timer ファイルの [timer] 項で設定できるディレクティブの一部を紹介します。 OnCalendar 最も一般的な設定方法で、特定の日時、定期的なタイミング (毎日、毎分など) を指定します。 ■ 例1：OnCalendar=daily (毎日) ■ 例2：OnCalendar=Sat,Sun 09:00 (毎週土日の午前 9時) ■ 例3：OnCalendar=*-*-* 09:00:00 (毎日午前 9時) なお、例3 のように特定の時刻は YYYY-MM-DD HH:MM:SS 形式で指定できます。 * はすべての時刻を表します。 OnActiveSec タイマーが有効化されてからの時間を指定します。 具体的には、対象の .timer ユニットが active になってからの時間になります。 ■ 例：OnActiveSec=15min (タイマーが有効化されてから 15分後) OnBootSec システムが起動してからの秒数を指定します。 具体的には、systemd が boot.target に到達してからの時間になります。 ■ 例：OnBootSec=15min (システムが起動されてから 15分後) なお、systemd では時間に関するディレクティブで下記の単位を使用できるようになっています。 OnActiveSec や OnBootSec、その他のディレクティブにも下記の単位が使用できます。 s, sec, second (秒) min, minute (分) h, hr, hour (時間) d, day (日) w, week (週) m, month (月) y, year (年) また、今回紹介しきれなかったディレクティブが他にもいくつかありますので、詳しい内容を知りたい方は man systemd.timer にて systemd.timer のマニュアルを確認してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！systemd.timer によるタスク管理2 first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 IPA (情報処理推進機構) が、自社で脆弱性診断を実施・運用するための手順などをまとめた「脆弱性診断内製化ガイド」を公開しました。 脆弱性診断内製化ガイド https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2025/Vulnerability-assessment.html Google の AI モデル「Gemini」にいくつかの脆弱性が存在、またそれらの悪用例が報告されました。 「Gemini」を欺き家庭内の機器を操作、「プロンプトウェア」の悪用例が報告 https://japan.zdnet.com/article/35236509/ The Linux Foundation Japan は、各エバンジェリストによる初のコミュニティイベント「LF Japan Community Days」を 2025年 10月に開催することを発表しました。 LF Japan Community Days 大阪開催のお知らせ https://prtimes.jp/main/html/rd/p/000000380.000042042.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2025年8月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ 新卒エンジニアになった方 本格的な開発環境を構築したい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！新卒として4月に入社し、今回初めてのブログ執筆です。 VS CodeはWSL上で起動すべきだという3つの理由とその手順をお伝えします。 WSLとGit Bashの違いについて気になる方は、 こちらのブログ をご覧ください。   わたしの悩み Windows PCで開発環境を整え、いよいよコーディングを始めようとしたとき、先輩エンジニアからこう言われました。   「VS CodeはWSL上で起動するようにね」   Windows上でアイコンをクリックすれば快適に動くのに、なぜわざわざ黒い画面（ターミナル）から起動する必要があるんだろう…？ 私も最初はそう思い、少し戸惑いました。 しかし、この「WSL上でVS Codeを起動する」という一手間には、将来のあなたの開発効率を劇的に向上させる、明確で重要な理由が3つあったのです。 今回は、その理由と具体的な手順を分かりやすく解説します。   3つの理由 理由1：Linuxの圧倒的なパフォーマンスを活かせる   「   npm install がやたら遅い…」「 git status  の表示に時間がかかる…」 もしあなたがWindows上で直接これらのコマンドを実行しているなら、その原因は ファイルシステムの相性の悪さ かもしれません。 Windowsが使っている「NTFS」というファイルシステムは、Linux向けのツール群との相性が良くありません。一方、WSL内のLinuxが使っているファイルシステム（ext4）は、これらのツールが最高のパフォーマンスを発揮できるよう最適化されています。 VS CodeをWSL上で起動することで、ファイル操作がすべてLinux内で完結するため、 驚くほどコマンドの実行が速く なります。この速度差は、日々の開発業務において大きなストレス軽減に繋がります。   理由2：ツールの「互換性」問題を根本から回避できる   Web開発で使われるツールの多くは、元々Linux環境で使われることを前提に作られています。そのため、Windows環境でそのまま使おうとすると、様々な互換性の問題に直面することがあります。 パスの記法: Windows C:\Users\Taro とLinux /home/taro  のようなパスの違い。 シェルスクリプト: OSによるコマンドの違いで、配布されたスクリプトが動かない。 Docker: Linuxカーネルの機能に依存しているため、WSL2上が最もスムーズ。 VS CodeをWSL上で起動すれば、あなたの開発環境はLinuxそのものになります。これにより、厄介な互換性の問題を未然に防ぎ、ツールの導入や実行で悩む時間を大幅に削減できます。   理由3：チーム開発で「環境差異」に悩まなくなる 「自分のPCだと、なぜか動かない…」 チーム開発で最も避けたいのが、この 環境差異によるトラブル です。チームにmacOSやLinuxを使っているメンバーがいると、OSの違いが原因で、あなただけがエラーに遭遇するケースは少なくありません。   簡単！WSLから起動する手順 前提条件 WSL2 （Ubuntuなど）がインストールされていること。 Windowsに Visual Studio Code 本体がインストールされていること。   ステップ1：拡張機能「Remote – WSL」をインストールする まず、VS CodeとWSLを連携させるための公式拡張機能をインストールします。   Windows上で普通にVS Codeを起動します。   アプリのアイコンかスタートメニューで検索してください   左側のアクティビティバーにある四角いアイコン（拡張機能）をクリックします。   画面左のメニューバーから拡張機能（上から6つ目）を選択できます   検索バーに「 Remote – WSL 」と入力します。   表示された拡張機能（Microsoft製）の「インストール」ボタンをクリックします。   ステップ2：WSLターミナルから「code .」で起動する 次に、WSLのターミナルからVSCodeを起動します。 Windows TerminalやUbuntuのアプリなどから、WSLのターミナルを起動します。   画像はUbuntuです。ご自身の環境に合わせてください   cd  コマンドを使って、開発プロジェクトのあるディレクトリに移動します。     # 例：ホームディレクトリの 'projects/my-app' に移動     cd ~/projects/my-app     そのディレクトリで、以下のコマンドを実行します。         code .     code .  は、「 今いるディレクトリ（カレントディレクトリ）をVS Codeで開いて 」という意味のコマンドです。 初めて実行する際は、WSL側にVS Codeのサーバーが自動でインストールされるため、少し時間がかかります。2回目以降はすぐに起動します。 起動したVS Codeの左下が緑色になり、「 WSL: Ubuntu 」のように表示されていれば成功です！これであなたのVS Codeは、WSL環境に接続された状態で動いています。   まとめ｜Windows × WSL × VS Codeは「最強の組み合わせ」 今回ご紹介した方法は、Windowsの快適なUIと操作性を享受しつつ、Linuxの強力で安定した開発環境の恩恵も受けられる、まさに「いいとこ取り」のテクニックです。 最初は少し不思議に感じるかもしれませんが、この方法を一度マスターすれば、今後のあなたのエンジニアキャリアにおいて、計り知れないメリットをもたらしてくれるはずです。 Windowsでの開発に、もはや妥協は必要ありません。今日からあなたも「 code . 」をWSLで叩いて、快適な開発ライフをスタートさせましょう！     ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post VS Codeの使い方｜WSL連携で開発効率を上げる方法 first appeared on SIOS Tech. Lab .

[sng_toc_insert]   ターゲット プログラミング学習者 Windowsでこれから開発を行う開発者 フロントエンドからバックエンドへ挑戦し始めたエンジニア   概要 こんにちは。サイオステクノロジーのはらちゃんです！連続で2本目のブログ執筆です。 WSLとGit Bash、2つの違いをメリットやデメリットを踏まえて解説します。 WSLでVS Codeの開発効率を上げることが気になる方は、 こちらのブログ をご覧ください。   はじめに  Windowsで開発を始めると、必ず出会う2つの黒い画面があります。 それがWSLとGit Bashです。 どちらもLinux風のコマンドが使えて一見似ていますが、その正体と得意なことは全く異なります。 間違ったツールを選ぶと、後々「やりたいことができない…」と遠回りしてしまうことも。 簡単に言うと、WSLは「Windows上で本物のLinuxを動かす」のに対し、Git Bashは「Windows上でLinuxのコマンドを擬似的に再現する」ものです。 この記事では、両者の根本的な違いからメリット・デメリットまでを徹底比較し、あなたがどちらを選ぶべきかの明確な指針を解説します。   根本的な違い  まず、両者の最も重要な違いを表で見てみましょう。 　 WSL (Windows Subsystem for Linux) Git Bash OS環境 完全なLinuxカーネルが動作する仮想環境 Windows上で動作するBashエミュレーター できること Linuxでできることはほぼ全て可能 ・apt等のパッケージ管理 ・サーバーソフトの起動など Git操作と基本的なUNIXコマンドが中心 パフォーマンス Linuxファイルシステム内は高速 Windowsとのファイルやり取りは若干遅い Windowsファイルシステム上で動作 そのため、ファイルアクセスは高速 リソース消費 比較的大きい（メモリ、CPU） 軽量 WSLの特徴   メリット 完全なLinux環境 ： apt や yum といったパッケージマネージャーを使い、膨大なLinuxのツールやアプリケーションを自由にインストールできます。Webサーバー（Apache, Nginx）やデータベース（MySQL, PostgreSQL）なども動作させられます。 高い互換性 ： Linux向けのアプリケーションや開発ツール（Dockerなど）をそのまま利用でき、本番環境がLinuxの場合に開発環境を限りなく近づけることができます。 パフォーマンス ： Linuxファイルシステム内の処理は非常に高速です。コンパイルや大規模なファイルの処理などでその真価を発揮します。   デメリット セットアップがやや複雑 ： Git Bashに比べると、有効化やディストリビューションのインストールなど、初期設定に手間がかかります。 リソース消費量が多い ： 仮想マシンに近い形で動作するため、メモリやCPUの消費量はGit Bashよりも多くなります。 Windowsファイルとの連携 ： WSL内のLinuxからWindowsのファイル（ /mnt/c/ など）にアクセスすると、パフォーマンスが低下する傾向があります。   Git Bashの特徴   メリット 手軽さ ： Git for Windowsをインストールするだけで利用でき、非常に軽量です。 Windowsとの親和性 ： Windowsのファイルシステム上で直接動作するため、ファイルのパス指定などが直感的で、パフォーマンスの低下もありません。 Gitに最適化 ： もともとGitを使うために作られているため、Gitの操作に必要なコマンドは一通り揃っており、シンプルにバージョン管理をしたい場合には十分です。   デメリット 機能の制限 ： あくまでエミュレーターなので、使えるUNIXコマンドは限定的です。 apt のようなパッケージマネージャーは使えず、新しいツールを自由に追加することはできません。 本格的な開発には不向き ： Linuxの豊富な開発ツールやライブラリを利用することができないため、複雑なWebアプリケーション開発などには向いていません。 シェルスクリプトの互換性 ： 一部の複雑なシェルスクリプトは、完全なLinux環境と挙動が異なる場合があります。   【ハンズオン】使ってみよう 理屈がわかったところで、実際にツールをインストールしてみましょう。どちらも数ステップで簡単に導入できます。   WSLの導入方法  現在のWindowsでは、WSLの導入が驚くほど簡単になっています。管理者権限のターミナルから、たった一つのコマンドを実行するだけです。   管理者としてターミナルを開く スタートボタンを右クリックし、「ターミナル (管理者)」または「Windows PowerShell (管理者)」を選択します。 「このアプリがデバイスに変更を加えることを許可しますか？」と表示されたら、「はい」をクリックします。     インストールコマンドを実行 開いたターミナルに、以下のコマンドをコピー＆ペーストして、Enterキーを押します。 wsl --install このコマンドが、WSLを有効化し、デフォルトのLinuxディストリビューションである「Ubuntu」のダウンロードとインストールまで、すべて自動で行ってくれます。   PCを再起動 インストールが完了したら、PCを再起動するように促されるので、再起動します。 初期設定を行う 再起動後、Ubuntuのターミナルが自動で起動し、初期設定が始まります。 Linux環境で使うユーザー名とパスワードを設定するように求められるので、入力してください。 （このパスワードは、 sudo コマンドなどで使う重要なものなので、忘れないようにしましょう）     Git Bashの導入方法  Git Bashは、「Git for Windows」というパッケージに含まれています。以下の手順でインストールしましょう。   公式サイトにアクセス まず、 Git for Windowsの公式サイト にアクセスします。   インストーラーをダウンロード トップページにある「Download」ボタンをクリックして、インストーラーをダウンロードします。   インストーラーを実行 ダウンロードしたファイルを実行します。基本的に、すべてデフォルト設定のまま「Next」を押し続けて問題ありません。途中で初期ブランチ名を main に変更するかどうかなど、いくつか質問されますが、よく分からなければそのままで大丈夫です。 公式サイト も参照すると理解が深まると思います。   インストール完了 インストールが終わったら、デスクトップやスタートメニューに「Git Bash」のアイコンが追加されます。これをクリックすれば、いつでもGit Bashを起動できます。     結論  結局、どちらが良いという話ではなく、あなたの目的に合わせて選ぶのが最適です。   Git Bashがおすすめな方 主な目的がGitのバージョン管理である。 Windowsネイティブな開発が中心で、ちょっとしたUNIXコマンド（ ls , rm , grep など）を使いたい。 とにかく手軽に、素早く環境を構築したい。   WSLがおすすめな方 Web開発など、本番環境がLinuxサーバーである。 Dockerコンテナを使いたい。 Linuxの豊富なコマンドやツール、プログラミング言語環境をフル活用したい。 本格的なクロスプラットフォーム開発を行いたい。   まとめ 今回ご紹介したのは、本格的な開発ならWSL、Gitの手軽さを求めるならGit Bashという、それぞれのツールの明確な役割分担です。 最近の開発トレンドでは、Dockerの利用やバックエンド開発でLinux環境が求められることが多いため、本格的な開発を行うならWSLの利用が強く推奨されます。 一方で、Gitの操作や簡単なコマンド実行が目的なら、Git Bashの手軽さは依然として大きな魅力です。 この記事を参考に、あなたの目的に合った最高の相棒を選んで、快適な開発ライフをスタートさせましょう！         ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 開発環境の選び方｜WSLとGit Bashの根本的な違いを解説 first appeared on SIOS Tech. Lab .

はじめに こんにちはサイオステクノロジーのぺんぎんです! 新卒1年目、初めてのブログ執筆です。よろしくお願いいたします！ 私がlinuxの権限周りに振り回された体験記を執筆します。 今回はDockerコマンド実行時にsudo権限をつけないと実行できないエラーが発生したため、その解決方法を共有します。 前提条件 Ubuntu 24.04.1 LTS(WSL2上で利用) Docker version 28.1.1 概要 とある日、Dockerやubuntuの環境構築を終え、コンテナの勉強のためdocker-compose.yml、Dockerfileを作成し、docker compose upを実行しようと思い、コマンドを打ちました。すると！ 下記エラーが発生しました failed to solve: ubuntu:16.04: failed to resolve source metadata for docker.io/library/ubuntu:16.04: error getting credentials - err: exit status 1, out: `GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files` ちなみに、このエラーはsudoを付けてコマンドを実行すると起きませんでした。 解決方法 このコマンドを打つことで解決しました！ sudo apt install gnome-keyring 解決までの経緯 sudoをつけないと実行できないと言うことはまず権限周りを疑います。とりあえずGemini君に「 sudo をつけないと docker compose up が実行できない理由はなに？ 」と聞いてみました。 ↓Geminiからの回答 『はい、sudo をつけないと docker compose up が実行できない理由ですね。これは、Linuxの権限管理とDockerの仕組みが関係しています。 例えるなら、あなたは特別な料理クラブ（dockerグループ）のメンバーになったはずなのに、そのメンバーカード（グループ権限）が、まだクラブの入口（現在のログインセッション）で有効になっていないか、あるいは入口そのもの（Dockerデーモンソケット）に何か問題がある、という状況です。』 どうやらdockerグループなるものがあり、このグループに追加されたユーザーはroot権限がなくともdockerコマンドを実行できるようになるらしい… 早速追加してみました。 # dockerグループにユーザーを追加 sudo usermod -aG docker $USER # dockerグループのユーザー確認 grep '^docker:' /etc/group # 出力 docker:x:989:一般ユーザー名 実行後PCの再起動を行いdockerグループへのユーザーの追加を反映さました。 しかし、このアプローチでは解決しませんでした。 権限の問題ではなかったみたいです。 再度Geminiに相談しました。 『これは .docker ディレクトリの権限の問題ではなく、 Dockerが認証情報を扱うための内部的な仕組み（Credential Helper） 、特に secretservice と呼ばれる部分に問題がある可能性が高いです。』 内部的な問題という返答だけ帰ってきて解決の糸口があまりにもなかったため、ここで先輩に相談をしました。 結果として先輩に教えていただいた先ほどのgnome-keyringをインストールするコマンドで解決したのですがなぜ解決したのでしょうか？自分なりに考察をしてみました。 Gnome-keyring(グノームキーリング)とは？ キーリングツールとは「パスフレーズで暗号化されたSSH秘密鍵の、パスフレーズ」や「ChromeやFirefoxなどのブラウザが保管するWebサイトのパスワード」など様々な認証情報を暗号化して保管するツールです。 Gnome KeyeingはキーリングツールでありGnomeプロジェクトによりで開発されました。Ubuntuではデスクトップ環境としてGnomeプロジェクトで開発されたデスクトップ環境であるGnomeを標準採用しているため今回の場合はキーリングとしてGnome-keyringを採用しました。 Dockerはプライベートリポジトリのイメージの保管や組織アカウントやチーム機能の利用などで認証を必要としており、docker loginを行うことでDocker Engineがユーザーの認証情報をホストマシンのキーリングツールに保存します。その認証資格の管理にGnomeを標準採用しているUbuntuなどではGnome-keyringを利用する。 しかし、WSLの「Ubuntu」には最低限のパッケージのみインストールされており、Gnome-keyringは元から入っていない場合も多くあります。そのため私の環境にはGnome-keyringが入っていませんでした。 そして、代わりのキーリングツールが存在しておらず一般ユーザーでコマンドを実行しようとしていた私の環境ではsudoを付けないとコマンドの実行ができなかったと考えます。 感想 このエラーについての記事はほとんど存在しておらず、情報が少なかったためAIに聞いても解決の糸口がつかめませんでした。 AIに頼って解決方法を探っていましたが、AIだけでなくきちんとネットで記事を調べて有用な記事を探しだすことの難しさと大切さを改めて実感しました。 今まで以上に検索力をつけるためエラーに向き合っていこうと思いました。 参考文献 https://qiita.com/onokatio/items/9ca0305e35243cca6119 https://docs.docker.jp/engine/reference/commandline/login.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post dockerコマンドでsudoをつけずに実行する方法 first appeared on SIOS Tech. Lab .

こんにちは！サイオステクノロジーの貝野です。 今回は、シングルサインオンなどのアクセス管理ができるソフトウェア keycloak をインストールするにあたり、試行錯誤したところがありましたのでその内容を共有したいと思います。 環境構成 今回は、下記の構成で keycloak の構築を行いました。 OS：RHEL9 (AWS 上) keycloak のバージョン：2.6.32 Java のバージョン：OpenJDK21 まずは keycloak をダウンロード keycloak のドキュメント を参考に、インストールを進めていきます。 keycloak の動作には Java が必要となるため、事前に Java 関連パッケージ (openjdk および openjdk-devel) をインストールしておきます。 https://www.keycloak.org/downloads から keycloak-26.3.2.tar.gz をダウンロードします。 ダウンロードしたパッケージを、任意のディレクトリ配下に展開します。 # tar -xvf keycloak-26.3.2.tar.gz -C そのまま起動すると… ダウンロードが終わったので、ひとまず keycloak を起動してみます。 ドキュメント の手順に沿って、次は bin/kc.sh start-dev を実行します。 起動に成功すると、コンソールに Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.2) started in … (以下省略) と表示されます。(出力内容の下部を参照) Updating the configuration and installing your custom providers, if any. Please wait. 2025-07-31 04:49:28,487 INFO [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 17015ms Running the server in development mode. DO NOT use this configuration in production. 2025-07-31 04:49:40,369 INFO [org.keycloak.quarkus.runtime.storage.database.liquibase.QuarkusJpaUpdaterProvider] (main) Initializing database schema. Using changelog META-INF/jpa-changelog-master.xml 2025-07-31 04:49:48,517 INFO [org.keycloak.spi.infinispan.impl.embedded.JGroupsConfigurator] (main) JGroups JDBC_PING discovery enabled. 2025-07-31 04:49:48,939 INFO [org.infinispan.CONTAINER] (main) ISPN000556: Starting user marshaller 'org.infinispan.commons.marshall.ImmutableProtoStreamMarshaller' 2025-07-31 04:49:49,557 INFO [org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory] (main) Node name: node_221352, Site name: null 2025-07-31 04:49:50,035 INFO [org.keycloak.services] (main) KC-SERVICES0050: Initializing master realm 2025-07-31 04:49:54,460 INFO [io.quarkus] (main) Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.2) started in 25.736s. Listening on: http://0.0.0.0:8080 2025-07-31 04:49:54,461 INFO [io.quarkus] (main) Profile dev activated. 2025-07-31 04:49:54,461 INFO [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-h2, keycloak, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, vertx] ドキュメントの手順では、http://localhost:8080/ にアクセスして管理者アカウントのユーザ名とパスワードを作成するフォームに移動するようですが、私の環境では GUI 環境がないため、クライアント端末から http://AWS インスタンスのプライベート IP:8080/ でアクセスしたところ、下記の画面が表示されました。 “Local access required” ということなので、ローカル環境でのアクセスが必要ということですが GUI 環境がないため、画面の内容に記載の use a bootstrap-admin command を実行してみることにします。 bootstrap-admin コマンドで管理者アカウントを作成 下記のドキュメントに、bootstrap-admin コマンドで管理者アカウントを作成する手順があったので、そちらを参考に管理者アカウントを作成してみます。 https://www.keycloak.org/server/bootstrap-admin-recovery 一時的な管理者アカウントの作成方法も含め、いくつかの実行例が記載されていますが、プロンプトにてユーザ・パスワードを入力する bin/kc.sh bootstrap-admin user コマンドを実行します。 下記のプロンプトにそれぞれ入力します。 Enter username：管理者のユーザ名 Enter password：管理者のパスワード Enter password again：管理者のパスワード (再入力) # bin/kc.sh bootstrap-admin user Changes detected in configuration. Updating the server image. Updating the configuration and installing your custom providers, if any. Please wait. 2025-07-31 19:39:29,011 INFO [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 17397ms Server configuration updated and persisted. Run the following command to review the configuration: kc.sh show-config Next time you run the server, just run: kc.sh bootstrap-admin user --optimized Enter username [temp-admin]:admin Enter password: Enter password again: 2025-07-31 04:51:27,697 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) Starting Infinispan embedded cache manager 2025-07-31 04:51:27,707 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) JGroups JDBC_PING discovery enabled. 2025-07-31 04:51:28,701 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) JGroups Encryption enabled (mTLS). 2025-07-31 04:51:28,938 INFO [org.infinispan.CONTAINER] (main) Virtual threads support enabled 2025-07-31 04:51:29,244 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Starting JGroups certificate reload manager 2025-07-31 04:51:29,416 INFO [org.infinispan.CONTAINER] (main) ISPN000556: Starting user marshaller 'org.infinispan.commons.marshall.ImmutableProtoStreamMarshaller' 2025-07-31 04:51:29,784 INFO [org.infinispan.CLUSTER] (main) ISPN000078: Starting JGroups channel `ISPN` with stack `jdbc-ping` 2025-07-31 04:51:29,787 INFO [org.jgroups.JChannel] (main) local_addr: 6c4c0bdf-a3da-4e8e-9d54-38fb7c243e37, name: ip-172-10-10-10-28803 2025-07-31 04:51:29,805 INFO [org.jgroups.protocols.FD_SOCK2] (main) server listening on *:57800 2025-07-31 04:51:29,819 INFO [org.jgroups.protocols.pbcast.GMS] (main) ip-172-10-10-10-28803: no members discovered after 7 ms: creating cluster as coordinator 2025-07-31 04:51:29,865 INFO [org.infinispan.CLUSTER] (main) ISPN000094: Received new cluster view for channel ISPN: [ip-172-10-10-10-28803|0] (1) [ip-172-10-10-10-28803] 2025-07-31 04:51:29,869 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Reloading JGroups Certificate 2025-07-31 04:51:29,985 INFO [org.infinispan.CLUSTER] (main) ISPN000079: Channel `ISPN` local address is `ip-172-10-10-10-28803`, physical addresses are `[172.10.10.10:7800]` 2025-07-31 04:51:30,719 INFO [org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory] (main) Node name: ip-172-10-10-10-28803, Site name: null 2025-07-31 04:51:32,655 INFO [org.keycloak.services] (main) KC-SERVICES0077: Created temporary admin user with username admin 2025-07-31 04:51:32,674 INFO [io.quarkus] (main) Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.1) started in 63.431s. Listening on: 2025-07-31 04:51:32,674 INFO [io.quarkus] (main) Profile nonserver activated. 2025-07-31 04:51:32,675 INFO [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-h2, keycloak, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, vertx] 2025-07-31 04:51:32,713 INFO [org.infinispan.CLUSTER] (main) ISPN000080: Disconnecting JGroups channel `ISPN` 2025-07-31 04:51:32,725 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Stopping JGroups certificate reload manager 2025-07-31 04:51:32,729 INFO [com.arjuna.ats.jbossatx] (main) ARJUNA032014: Stopping transaction recovery manager 2025-07-31 04:51:32,779 INFO [io.quarkus] (main) Keycloak stopped in 0.097s # これで、管理者のユーザ・パスワードが設定されました。 再度 bin/kc.sh start-dev を実行してみると、今度はログイン画面が表示されました。 先ほど設定したユーザ名・パスワードを入力すると、無事にログインすることができました。 今回は、keycloak を導入するにあたり、つまづいたポイントをご紹介しました。 今後、各機能の説明や使い方などもご紹介できればと思いますので、引き続きよろしくお願いします！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post keycloak インストール時につまずいた話 first appeared on SIOS Tech. Lab .

こんにちは、OSS よろず相談室の鹿島です。 本記事は、 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① の続編です。前回構築したDify環境に、Amazon Bedrockを連携させるための各種設定を行っていきます。 ステップ1：AWS での設定 Amazon Bedrockの利用準備 Amazon Bedrockを使用するには、 AWSアカウントが必要 です。 また、Amazon Bedrockは従量課金制のサービスであり、 利用には料金が発生 します。モデルプロバイダーやモデルの種類、入出力のトークン数によって料金が異なるため、事前に以下の公式料金ページで確認しておきましょう。 料金プランは以下の通りです。 Amazon Bedrock の料金 https://aws.amazon.com/jp/bedrock/pricing/ 前回の記事 でも紹介したように、Amazon Bedrockは自社開発のモデル（Titan）だけでなく、様々な企業のAIモデルを選んで単一のAPIで利用できる点が大きな特徴です。 以下の画像は、Amazon Bedrock の料金表からの抜粋ですが、赤く囲んだ部分は提供会社で、タブを選択してそれぞれの会社のモデルを選択します。 Amazon Bedrockでの設定 1. モデルの選択・有効化 それでは、Amazon Bedrockが利用できるように設定しましょう。 AWS マネジメントコンソールにログインし、上部の検索バーで「Bedrock」と入力してサービスページへ移動します。 左側のナビゲーションメニューから モデルカタログ をクリックします。 利用したいモデル（例: Nova Micro）を探し、モデルカードをクリックします。 モデルの詳細ページで「アクセスをリクエスト」といったボタンをクリックすると、全モデルのアクセス権を管理する「モデルアクセス」ページへ移動します。 「モデルアクセス」の管理ページで、利用したいモデル（Nova Micro, Titan Text Embeddings V2など）のチェックボックスをオンにします。 ページ下部の 変更を保存 をクリックします。アクセスが許可されるまで数分待つ場合があります。 　本記事で利用するモデル 当記事の検証では、Amazonの以下のモデルを有効にしています。 Nova Micro ユーザーとの対話、文章の生成、要約、翻訳など、幅広いタスクをこなすLLM（大規模言語モデル）です。 チャットボットを作成するだけであれば、LLMだけあれば十分です。 Titan Text Embeddings V2 Amazonが開発した埋め込み（Embeddings）モデルで、RAGなどナレッジを使用する場合には、このようなテキストの「意味」を数値に変換するモデルが必要です。 Rerank 1.0 リランキングモデルです。 リランキングモデルとは、上記の埋め込みモデルが取得してきた検索結果を精査してより関連性の高い順に並べ替えることに特化したモデルです。 Difyの設定によっては必要になります。 2. IAM 権限の設定 Amazon Bedrock へのIAMポリシーを追加 DifyからAmazon Bedrockを利用するために、Amazon BedrockにアクセスするIAMユーザに、AWS のマネージドポリシーである AmazonBedrockFullAccess ポリシー を追加します。 本記事の検証では、以下のように実施しました。 AWSコンソール上部の検索ボックスで”IAM”を入力し、 IAM ダッシュボードを開きます。 Amazon Bedrockにアクセスさせたいユーザまたはグループを選択して、「許可を追加」を選択します。 以下を設定します。 許可のオプション：ポリシーを直接アタッチする 許可ポリシー：AmazonBedrockFullAccess アクセスキーを作成 (アクセスキーがない場合) DifyからAmazon Bedrockにアクセスする際にアクセスキー(アクセスIDとシークレットキー)使用します。 Amazon BedrockにアクセスするIAMユーザにアクセスキーがない場合は生成します。 IAM > ユーザ から自分のアカウントを選択し、「アクセスキーを作成」を選択します。 画面の指示に従ってアクセスキーを作成し、メモをするなりcsv出力して保存しておきます。 ステップ2：Difyでの設定 Difyの画面右上のユーザ名をクリックして「設定」 > 「モデルプロバイダー」を選択します。 前回の記事の「6 ステップ5：モデルプロバイダの設定」 でDifyにインストールしたAmazon BedrockのAPI-KEYを設定します。「セットアップ」を選択します。 上記の アクセスキーを作成 で設定したアクセスキー (上記画像の①)とシークレットアクセスキー(上記画像の②)を設定します。 モデルを有効化したリージョンの選択(上記画像の③)も必須項目です。 「保存」をクリックして設定完了です。 おわりに 以上で、DifyからAmazon Bedrockを利用するためのすべての設定が完了しました。 次回は、この環境を使ってチャットボットを作成していきます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② first appeared on SIOS Tech. Lab .

こんにちは、OSS よろず相談室の鹿島です。 今回は、DifyとAmazon Bedrockを連携させて、チャットボットとRAG（検索拡張生成）を構築する手順を解説します。 本記事はその第一弾として、まず土台となるDifyの環境構築を行います。 はじめに Difyの概要や全体像については、 弊社エンジニアの解説記事 がありますので、ご参照ください。Difyの概要から構築、機能に至るまでDifyを丸ごと学べる記事になっています。 当記事では、クリーンなLinux環境（RHEL系を想定）を前提に、ゼロからDifyの実行環境を立ち上げる手順にフォーカスします。 すでにDockerなどのコンテナ環境をお持ちの方は、「 ステップ3 」から読み進めてください。 ステップ1：Docker環境のセットアップ DifyはDockerコンテナとして提供されているため、最初にコンテナ実行環境であるDockerをインストールします。 今回はRHEL系のOSを想定し、dnfコマンドでDockerの公式リポジトリを追加・インストールします。 # Dockerリポジトリの追加 $ sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # Docker関連パッケージのインストール $ sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin インストール後、docker composeのバージョンを確認します。v2以上が表示されていればOKです。 $ docker compose version Docker Compose version v2.37.3 ステップ2：Dockerの起動と動作確認 Dockerサービスを起動し、OS起動時に自動実行されるよう有効化します。 # Dockerの起動 $ sudo systemctl start docker # Dockerの自動起動設定 $ sudo systemctl enable docker 正しくインストールできたかを確認するため、定番のhello-worldコンテナを実行してみましょう。「Hello from Docker!」と表示されれば成功です！ $ sudo docker run hello-world Hello from Docker! This message shows that your installation appears to be working correctly. ステップ3：Difyのインストールと起動 いよいよDify本体を準備します。 まずgitをインストールし、Difyの公式リポジトリからソースコードをクローンします。 # gitのインストール $ sudo dnf install git -y # Difyのリポジトリをクローン $ git clone https://github.com/langgenius/dify.git 次に、ダウンロードしたdify/dockerディレクトリへ移動し、設定ファイルのテンプレート (.env.example) をコピーして本番用の設定ファイル (.env) を作成します。 $ cd dify/docker $ cp .env.example .env 💡ポイント .envファイルには、後々APIキーなどの重要な情報を書き込むことになります。 以下のコマンドでDifyを起動しましょう。関連するコンテナが一括でバックグラウンド起動します。 $ docker compose up -d 少し待ってからdocker psコマンドでコンテナの状態を確認します。dify-apiやdify-webなどがSTATUS欄にUpと表示されていれば、正常に起動しています。 $ docker compose ps # ↓こんな感じで複数のコンテナが表示されていればOK CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 109f55191a6a nginx:latest "sh -c 'cp /docker-e…" 46 hours ago Up 3 hours 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp docker-nginx-1 0eeebd7d9fd8 langgenius/dify-api:1.4.3 "/bin/bash /entrypoi…" 46 hours ago Up 3 hours 5001/tcp docker-api-1 527f9eba0c88 langgenius/dify-api:1.4.3 "/bin/bash /entrypoi…" 46 hours ago Up 3 hours 5001/tcp docker-worker-1 7c53e1d71537 langgenius/dify-plugin-daemon:0.1.2-local "/bin/bash -c /app/e…" 46 hours ago Up 3 hours 0.0.0.0:5003->5003/tcp, [::]:5003->5003/tcp docker-plugin_daemon-1 b8dc25d8f9d2 redis:6-alpine "docker-entrypoint.s…" 46 hours ago Up 3 hours (healthy) 6379/tcp docker-redis-1 439bdecdb34f ubuntu/squid:latest "sh -c 'cp /docker-e…" 46 hours ago Up 3 hours 3128/tcp docker-ssrf_proxy-1 731465578b52 postgres:15-alpine "docker-entrypoint.s…" 46 hours ago Up 3 hours (healthy) 5432/tcp docker-db-1 80f9783bad96 langgenius/dify-sandbox:0.2.12 "/main" 46 hours ago Up 3 hours (healthy) docker-sandbox-1 cab12a5febe0 langgenius/dify-web:1.4.3 "/bin/sh ./entrypoin…" 46 hours ago Up 3 hours 3000/tcp docker-web-1 ad28ed866ba2 semitechnologies/weaviate:1.19.0 "/bin/weaviate --hos…" 46 hours ago Up 3 hours docker-weaviate-1 ステップ4：Difyにアクセス ブラウザから http://<サーバーのIPアドレス> にアクセスし、Difyの初期設定画面を開きます。 http://<サーバーのホスト名またはIPアドレス>/apps ユーザー登録画面が出ますので、アカウントを登録します。 そのアカウントでログインします。 ステップ5：モデルプロバイダの設定 チャットボットを作成する前に、頭脳となるLLM（大規模言語モデル）をDifyに設定する必要があります。このLLMの提供元をDifyでは「モデルプロバイダ」と呼びます。 まずは設定画面を見てみましょう。 画面右上のユーザ名をクリックして「設定」を選びます。 「モデルプロバイダー」を選択すると、追加可能なモデルプロバイダーの一覧が表示されます。 今回はAmazon Bedrockを選択してインストールします。 モデルプロバイダーとは、LLMの提供元(プロバイダー)のことです。 LLMとは、具体的な大規模言語モデル (例: GPT-4o, Gemini)のことです。 以下は、著名なモデルプロバイダーとLLMの一覧です。 名前を聞いたことがあるので、イメージしやすいのではないでしょうか。 モデルプロバイダー (提供元) LLM (具体的なモデル名) OpenAI GPT-4o, GPT-4, GPT-3.5-turbo Google Gemini 1.5 Pro, Gemini 1.5 Flash Anthropic Claude 3 Opus, Claude 3 Sonnet, Claude 3 Haiku Amazon Bedrock (下記の様々なLLMを選択して利用可能) ・Amazon: Titan Text, Titan Multimodal Embeddings ・Anthropic: Claude 3 ファミリー ・Cohere: Command, Embed ・Meta: Llama 3 ・Mistral AI: Mistral Large, Mistral 7B ・AI21 Labs: Jurassic-2 ファミリー ・Stability AI: Stable Diffusion Amazon Bedrockを利用すると、Amazon が提供するLLM 以外にもAnthropic 社の Claude や Meta 社の Llama など、業界の主要なLLMを一つのプラットフォーム上で比較・利用できるという点が最大の特徴です。 おわりに 今回は、Linuxがある状態から、コンテナ環境、Difyの構築までの説明でした。 次回は、いよいよAmazon Bedrock側の設定と、DifyでBedrockのモデルを利用する設定について、詳しく解説していきます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① first appeared on SIOS Tech. Lab .

はじめに 昨今の開発環境においては、オンプレミスであってもコンテナアプリケーションを稼働させたいというニーズが高まっています。 その様なオンプレミスかつ外部インターネットに接続できない閉域環境などでも、効率的かつセキュアな開発基盤の整備は欠かせません。 こうした環境では、GitHubのようなパブリックサービスは利用が難しいため、自社内で完結できるソースリポジトリおよびCI/CDプラットフォームとしてGitLabが有力な選択肢として挙げられます。 閉域環境において、CI/CDとKubernetesやOpenShiftといったコンテナプラットフォームを統合したい企業にとっては、GitLabを中核とした構成が現実的かつ強力な選択肢となります。 本シリーズでは、そのようなユースケースを想定し、閉域網におけるGitLabとコンテナプラットフォーム（本記事ではOpenShift）とのCI/CD構築や連携方法を解説します。 今回はシリーズの第一回として、GitLabの構築手順と、閉域環境のOpenShiftクラスターとの連携方法を中心に解説します。 検証環境構成 本記事では、GitLabと閉域環境のOpenShiftクラスターを連携させたCI/CD基盤の構築手順を紹介します。今回構築した検証環境の構成は以下の通りです。 外部インターネットに接続可能なサーバー上にGitLabを構築 閉域環境下のOpenShiftクラスターにGitLab Runnerをデプロイし、GitLabと連携 踏み台サーバー が以下の機能を兼任： GitLabとOpenShift間の名前解決を行う内部DNSサーバー コンテナの永続ストレージや、GitLabのコンテナレジストリ格納領域を提供する NFSサーバー 必要なトラフィックのルーティングを担う ロードバランサー ※本記事では GitLab の構築に焦点を当てており、踏み台サーバーや OpenShift クラスターの構築手順については割愛しています。 ※「コンテナプラットフォーム」は一般的なKubernetes基盤を指し、本記事で使用する「OpenShiftクラスター」はその具体的な構築済み環境を意味します。 目標 本記事での検証構成では、以下の実現を目標とします。 GitLabのインストールと初期設定 OpenShiftクラスターへのGitLab Runnerのデプロイ GitLabとGitLab Runner間の連携の確立 構築手順についても上記の順に沿って解説します。 用語説明 GitLab：ソースコード管理（Git）、コンテナレジストリ、CI/CD など、開発に必要な機能を統合したオールインワンのプラットフォーム。 GitLab Runner：GitLabのCI/CDジョブを実行するためのエージェント。様々な実行環境（Kubernetes、Docker、Shellなど）で動作可能。 Kubernetes Executor：GitLab Runner が Kubernetes クラスター上で Pod を動的に起動し、ジョブを実行するモード。Kubernetes 環境でのCI/CDに最適。 構築情報 本記事では、以下の構成と前提条件に基づいてGitLabを構築しています。 前提条件 以下の環境はあらかじめ構築済みであることを前提としています。 外部インターネットに接続できない OpenShift クラスター OpenShift用のミラーレジストリーサーバー 踏み台サーバー兼作業用端末 OpenShiftクラスターにアクセス可能であり、以下の役割を兼任： 内部DNSサーバー GitLab、GitLab Container Registry、OpenShift クラスター間の名前解決を提供 NFSストレージサーバー OpenShift内のコンテナで使用される永続ストレージ（PersistentVolume）を提供 ロードバランサー OpenShiftクラスターへの HTTPS 通信（APIや Webコンソール）を中継 GitLabの内部公開用ドメインを取得済み 取得したドメインは踏み台サーバーの内部DNSに登録済み ※ 本記事では OpenShiftクラスターおよび踏み台サーバーの構築手順は割愛しています。 GitLabサーバー構成 OS: RHEL9.4 CPU: 8コア メモリ: 16GB ストレージ: 200GB ※ GitLab公式ドキュメント：Reference Architecture のうち、最小構成に準拠。実際に必要なリソースは利用規模（秒間リクエスト数やユーザー数）により変動します。 バージョン情報 GitLab: 18.2.1 GitLab Runner: 18.2.0 GitLab エディション: Community Edition ※ GitLab本体はバージョン 18.2.1、GitLab Runnerはバージョン 18.2.0を使用しています。  なお、 公式ドキュメント によれば、同一マイナーバージョン内でのパッチバージョン差は互換性に影響せず、連携にも問題がないため、本構成でも正常に動作することを確認済みです。 ※本記事のOpenShiftクラスターはOpenShift 4.x系で構築されていますが、Kubernetes標準に準拠したクラスターであれば同様の構成が可能です。 GitLabの構築 GitLabは、Linuxパッケージを用いた手動インストールや、HelmチャートやOperatorによるKubernetes上へのデプロイなど、複数の構築手段が提供されています。 本記事では、RHELサーバー上にLinuxパッケージを用いてGitLab Community Editionを構築する方法を紹介します。 必要なツールのインストール GitLabをインストールするRHELサーバーにログインし、rootユーザーに切り替えます。 $ sudo su - 作業用ディレクトリを作成します。 # mkdir -p /data/work # cd /data/work GitLabの構築に必要なパッケージをインストールします。 # dnf install curl nfs-utils openssl postfix -y ※ツールの説明： curl: GitLabのリポジトリ追加で使用 nfs-utils: 踏み台サーバー内のNFS共有ディレクトリを利用するために使用 openssl: 自己署名証明書の作成に使用 postfix: メール通知機能に使用（今回はローカル送信のみ） GitLabのインストール GitLabのリポジトリを追加し、外部公開URLを指定してGitLabパッケージをインストールします。 # curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh" | bash # EXTERNAL_URL=https://gitlab.local.example.com \ dnf install gitlab-ce 自己署名証明書の作成と配置 今回は内部DNSを使用する閉域環境のため、自己署名証明書を利用します。まずは、GitLabサーバーのドメインとGitLabコンテナレジストリのドメインの自己署名証明書を作成します。 自己署名証明書を作成するための秘密鍵を作成します。 # openssl genpkey -algorithm RSA -out gitlab.local.example.com.key -pkeyopt rsa_keygen_bits:2048 証明書の情報を記載した設定ファイルを作成します。 alt_namesにGitLabサーバーのドメインとGitLabコンテナレジストリのドメインを設定します。 # vi san.cf [ req ] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [ req_distinguished_name ] C = JP ST = Tokyo L = Minato-city O = My Local Environment OU = My Team CN = gitlab.local.example.com [ v3_req ] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = gitlab.local.example.com DNS.2 = registry.gitlab.local.example.com 作成した秘密鍵と設定ファイルを利用して、自己署名証明書を作成します。 # openssl req -new -key gitlab.local.example.com.key \ -out gitlab.local.example.com.csr -config san.cnf # openssl x509 -req -days 3650 -in gitlab.local.example.com.csr \ -signkey gitlab.local.example.com.key \ -out gitlab.local.example.com.crt \ -extfile san.cnf -extensions v3_req # 作成結果の確認 # openssl x509 -in gitlab.local.example.com.crt -noout -text # 出力例（一部省略） -----BEGIN CERTIFICATE----- MIIElDCCA3ygAwIBAgIULJoazWr+hErKovG2ZiUSZ5qtHxswDQYJKoZIhvcNAQEL ... -----END CERTIFICATE----- 作成した自己署名証明書と秘密鍵をGitLabのSSLディレクトリにコピーします。 # cp gitlab.local.example.com.jp.crt /etc/gitlab/ssl # cp gitlab.local.example.com.key /etc/gitlab/ssl ファイルのパーミッション設定を以下のように行います。 証明書ファイル（.crt）は読み取り専用（644）にします。 秘密鍵（.key）は機密性が高いため、所有者のみ読み書き可能（600）にします。 # chmod 644 /etc/gitlab/ssl/gitlab.local.example.com.crt # chmod 600 /etc/gitlab/ssl/gitlab.local.example.com.key GitLab設定ファイルの編集 GitLabの設定ファイル /etc/gitlab/gitlab.rb を編集します。 # vi /etc/gitlab/gitlab.rb 下記に示す内容を設定ファイル/etc/gitlab/gitlab.rbに記載します。 基本設定（外部公開URL） 参考： https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually これらの設定はGitLabにアクセスするためのURLを設定します。今回は自己署名証明書を利用するので、Let’s Encrypt設定を無効化します。また、ドメイン名が長すぎるとエラーが起きるので、nginx[‘server_names_hash_bucket_size’] = 128と設定します。 external_url "https://gitlab.local.example.com" letsencrypt['enable'] = false nginx['server_names_hash_bucket_size'] = 128  # ドメイン名が長い場合のエラー対策 コンテナレジストリ設定（プライベートレジストリとして使用） 参考： https://docs.gitlab.com/administration/packages/container_registry/#container-registry-domain-configuration これらの設定はGitLabコンテナレジストリの設定をします。アクセスするためのURLやその証明証書ファイルを指定します。今回はコンテナレジストリのディレクトリを踏み台サーバーにマウントするので、gitlab_rails[‘registry_path’]にはマウントするディレクトリを設定します。 registry_external_url "https://registry.gitlab.local.example.com" registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.local.example.com.crt" registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.local.example.com.key" gitlab_rails['registry_path'] = "/mnt/gitlab-registry" メール通知設定（Postfixによるローカル配送） 参考： https://docs.gitlab.com/omnibus/settings/smtp/ これらの設定はGitLabのメール通知設定を行います。GitLabサーバー上のPostfixのSMTPサーバーにメール通知する設定をします。 gitlab_rails['gitlab_email_from'] = 'gitlab@example.com' gitlab_rails['gitlab_email_display_name'] = 'GitLab' gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "127.0.0.1" gitlab_rails['smtp_port'] = 25 gitlab_rails['smtp_domain'] = "localhost" gitlab_rails['smtp_authentication'] = "none" gitlab_rails['smtp_enable_starttls_auto'] = false gitlab_rails['smtp_tls'] = false gitlab_rails['smtp_ssl'] = false 設定の適用と動作確認 GitLabの設定適用 上記の /etc/gitlab/gitlab.rbを記載したら以下のコマンドでGitLabの設定を適用します。 # gitlab-ctl reconfigure サービスの状態確認 GitLabのサービスの状態を確認します。 # gitlab-ctl status 全てのサービスがrun:と表示されていれば正常です。 （例） run: alertmanager: (pid 1319) 3117s; run: log: (pid 1317) 3117s run: crond: (pid 1309) 3117s; run: log: (pid 1305) 3117s run: gitaly: (pid 1284) 3117s; run: log: (pid 1282) 3117s run: gitlab-exporter: (pid 1316) 3117s; run: log: (pid 1308) 3117s run: gitlab-kas: (pid 1310) 3117s; run: log: (pid 1296) 3117s run: gitlab-workhorse: (pid 1307) 3117s; run: log: (pid 1306) 3117s …（省略） 以上でGitLabのインストールと初期構成は完了です。続いて、WebブラウザからGitLabにアクセスし、初期設定を行います。 GitLabの初期設定 初期パスワードの確認 GitLabの初回ログイン用パスワードは、インストール時に自動生成され/etc/gitlab/initial_root_password に保存されています。 以下のコマンドで確認します。 # cat /etc/gitlab/initial_root_password Webコンソールへのアクセス ブラウザからexternal_url に設定したドメインにアクセスします。 初回アクセス時には、次のようなログイン画面が表示されます。 ユーザー名：root パスワード：上記で確認した初期パスワード ※本検証では、閉域環境の内部DNSドメインを使用しているため、外部接続可能なサーバーからVNCコンソール経由でアクセスしています。オフライン環境でもGUIでログイン・操作ができるよう、ネットワーク経路の確保またはポートフォワーディングなどの工夫が必要です。 ユーザーインターフェースの言語を日本語に変更 GitLabインストール直後のUIは英語表記になっています。日本語に切り替えるには、以下の手順で設定します。 サイドメニューから[User settings] > [Preferences] > [Localization]と選択し、ローカライズ設定画面に移動 ローカライズ設定画面の[Language]欄でJapaneseを選択すると、言語環境を日本語に変更 これで、GitLabの管理者アカウントでのログインと基本的なUI設定が完了しました。 次のステップでは、GitLab Runner の登録および CI/CD 環境の構築へと進みます。 GitLab Runnerの構築 本セクションでは、閉域環境の OpenShift クラスターに GitLab Runner をデプロイし、GitLab 本体と連携させる手順を解説します。 GitLab Runnerは Kubernetes Executor を利用し、OpenShift上でCI/CDジョブ用のPodを動的に起動します。 ※Kubernetes Executorとは： GitLab Runnerの実行方式の一つで、CI/CDジョブごとに Kubernetes上に一時的なPodを生成してジョブを実行するモードです。本記事では、このKubernetes Executorを用いてRunnerを構成します。 構築フロー概要 以下の手順で GitLab Runner を構築・連携します： コンテナイメージを配置するプロジェクトを作成 GitLab用のプライベートレジストリに必要なコンテナイメージを事前格納 GitLab管理コンソールで Runnerを登録し、トークンを取得 Helmチャートを用いて OpenShiftにRunnerをデプロイ 証明書・認証情報をOpenShift側に連携 Runnerの稼働確認 プロジェクトの作成 GitLabのコンソールから[+]を選択し、新規プロジェクトを作成します。 GitLabコンテナレジストリにイメージを格納 プロジェクトを作成したら、踏み台サーバーにログインし、ターミナルからRunnerが必要とする資材を取得します。 利用イメージ（例） 用途 イメージ名 GitLab Runner 本体 gitlab-org/gitlab-runner:alpine-v18.2.0 ジョブPodベースイメージ alpine:latest 操作手順（RHEL + Podman 利用例） ※Docker 利用環境ではpodman → dockerに置き換えてください。 # podman login registry.gitlab.local.example.com # podman pull registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 # podman pull docker.io/library/alpine:latest # podman tag registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/gitlab-runner:alpine-v18.2.0 # podman tag docker.io/library/alpine:latest registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest # podman push registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/gitlab-runner:alpine-v18.2.0 # podman push registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest GitLab上で Runner を登録 続いて、GitLab上でRunnerを登録します。本手順はGitLabのコンソール画面にログインして実施します。 GitLab管理コンソールにログイン サイドメニューから[管理者メニュー] → [CI/CD] → [Runner]と移動 [Create instance runner] を選択 任意のタグを入力し、[Runnerを作成] 表示された認証トークン（例: glrt-xxxxxxx）を控えておく ※本記事では、インスタンスRunner（全プロジェクトで利用可能なRunner）を採用しています。 Helmチャートの取得と展開準備 OpenShiftではOperatorを利用してGitLab Runnerをインストールすることも可能ですが、本環境は閉域構成のためOperatorの自動更新によるメリットを十分に活かせません。そこで今回は、Helm チャートを使用してGitLab Runner をインストールします。 本手順は踏み台サーバー内で実施します。 GitLabから提供されているRunnerのHelmチャートを取得 # helm repo add gitlab https://charts.gitlab.io # helm repo update # helm pull gitlab/gitlab-runner --version 0.79.0 OpenShift上の事前設定 OpenShiftにRunnerをデプロイするための準備を行います。 本手順は踏み台サーバー内で実施します。 Namespace 作成 GitLab Runnerのリソースを管理するNamespaceを作成します。 # oc create namespace gitlab-runner-test ServiceAccount & SCC（anyuid）設定 OpenShiftでJobを実行するServiceAccountを作成します。 # oc create sa gitlab-runner-sa -n gitlab-runner-test ServiceAccountの権限設定するgitlab-runner-sa-role.yaml を作成し、以下を適用します。 # vi gitlab-runner-sa-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:   name: scc-anyuid   namespace: gitlab-runner-test rules: - apiGroups:   - security.openshift.io   resourceNames:   - anyuid   resources:   - securitycontextconstraints   verbs:   - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: sa-to-scc-anyuid   namespace: gitlab-runner-test subjects: - kind: ServiceAccount   name: gitlab-runner-sa roleRef:   kind: Role   name: scc-anyuid   apiGroup: rbac.authorization.k8s.io # oc apply -f gitlab-runner-sa-role.yaml OpenShiftに証明書と認証情報を登録 レジストリCAの登録（自己署名証明書対応） 証明書を踏み台サーバーのコンテナ証明書ストアに保存します。 $ mkdir -p /etc/containers/certs.d/registry.gitlab.local.example.com $ openssl s_client -showcerts -connect registry.gitlab.local.example.com:443 < /dev/null | sudo tee /etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt > /dev/null GitLabコンテナレジストリの証明書をOpenShiftのCAストアに登録します。 # oc create configmap gitlab-runner-ca -n openshift-config \ --from-file=registry.gitlab.local.example.com=/etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt # oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"gitlab-runner-ca"}}}' --type=merge プライベートレジストリのPull認証設定 GitLab RunnerのJobを実行するServiceAccountがコンテナレジストリにアクセスできるようにするために、証明書の認証情報をServiceAccountに紐づけます。 # oc create secret docker-registry gitlab-registry-secret \ --docker-server="registry.gitlab.local.example.com" \ --docker-username="<ユーザー名>" \ --docker-password="***" \ -n gitlab-runner-test # oc secrets link gitlab-runner-sa gitlab-registry-secret --for=pull -n gitlab-runner-test GitLab証明書のシークレット化 GitLab RunnerがGitLab サーバーにアクセスできるようにするためにシークレットを登録します。 # scp <GitLabサーバーのユーザー名>@<GitLabサーバーのIPアドレス>:/data/work/gitlab.local.example.com.crt . # oc create secret generic gitlab-runner-secret \ --namespace gitlab-runner-test \ --from-file=gitlab.local.example.com.crt HelmによるGitLab Runnerのデプロイ values.yaml 設定例 gitlabUrlにはGitLabのURLを設定します。runnerTokenにはGitLab上でGitLab Runnerを作成した際に、確認した認証トークンの値を入力します。imageにはGitLab Runnerのイメージを指定します。runnersにはGitLab RunnerのJob Podのベースイメージを指定します。certsSecretNameにはGitLabサーバーの証明書情報が保存されているシークレットを指定します。 gitlabUrl: https://gitlab.local.example.com/ runnerToken: "glrt-xxxxxxxxxxxxxxxxx" rbac:   create: true serviceAccount:   create: false   name: gitlab-runner-sa image:   registry: "registry.gitlab.local.example.com"   image: <ユーザー名>/<プロジェクト名>/gitlab-runner   tag: <タグ名> runners:   config: |     [[runners]]       [runners.kubernetes]         namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"         image = "registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest" certsSecretName: gitlab-runner-secret インストール実行 GitLab RunnerをHelmインストールします。 # helm install gitlab-runner ./gitlab-runner-0.79.0.tgz -f values.yaml -n gitlab-runner-test 動作確認 Podの起動確認 # oc get pod -n gitlab-runner-test # Running 状態で起動していることを確認 NAME                             READY   STATUS    RESTARTS   AGE gitlab-runner-7658bb5fdc-rb95v   1/1     Running   1          13h GitLab側でRunnerステータス確認 GitLab管理コンソールの [Runner管理画面] にて、登録したRunnerが「オンライン」表示になっていることを確認します。 これでGitLabとOpenShiftクラスター上の GitLab Runnerの連携が完了しました。 このRunnerを利用して、GitLab CI/CDパイプラインからジョブを実行できるようになります。 まとめ 本記事では、Linuxサーバー上に GitLabを構築し、閉域環境にあるKubernetes（OpenShift クラスター）と連携してCI/CD環境を実現する手順を紹介しました。 特に、以下のような環境において、今回の検証内容は実用的なモデルケースとなります。 インターネット接続が制限されたオンプレミス環境 セキュリティ要件上、外部クラウドサービスの利用が難しい開発現場 閉域環境下で Kubernetesを活用しているものの、CI/CD基盤の整備や統合に課題を抱えている開発現場 本シリーズでは今後も今回構築した環境を基に閉域環境でのリポジトリ管理やCI/CDパイプラインとコンテナプラットフォームの連携について解説する予定です。 「閉域環境でのDevSecOps」を本格展開するための一歩として、本記事の構成をぜひ活用してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitLabとコンテナプラットフォームの連携 first appeared on SIOS Tech. Lab .

はじめに こんにちは！重要な機能開発を任されて最近まで業務で手一杯だったなーがです。今回はBicepで作成したAzure FunctionsとApplication Insightsをリンクする方法について解説します。 Azure Functionsをデプロイした際、Azure PortalのFunctionsの画面から直接ログを確認したいというニーズは多いかと思います。しかし、Bicepでそれぞれを個別にデプロイしただけでは、Azure FunctionsのポータルからApplication Insightsのログを直接参照することができず、一手間かかってしまいます。 今回の設定を行うことで、Azure Functionsの管理画面からシームレスにログの確認ができるようになります。 課題：Azure FunctionsからApplication Insightsのログを直接確認できない BicepでAzure FunctionsとApplication Insightsをデプロイしただけでは、Portal上のFunctionsのメニューからログを確認しようとしても、関連付けがされていないため、以下のように表示されてしまいます。この状態では、Application Insightsのリソースを直接開いてログを確認する必要があり、少し不便です。 解決方法 この問題は、Azure Functionsのアプリケーション設定に、Application Insightsの接続文字列を追加することで解決します。 具体的には、Azure Functionsリソースの siteConfig.appSettings に APPLICATIONINSIGHTS_CONNECTION_STRING という名前のプロパティを追加し、その値としてApplication Insightsリソースの properties.ConnectionString を指定します。 公式ドキュメントによると、 APPINSIGHTS_INSTRUMENTATIONKEY または APPLICATIONINSIGHTS_CONNECTION_STRING のいずれかを設定することで連携できます。しかし、 APPINSIGHTS_INSTRUMENTATIONKEY は2025年3月31日にサポートが終了しているため、今後は APPLICATIONINSIGHTS_CONNECTION_STRING の使用が推奨されます。 参照 Azure Functions のアプリケーション設定のリファレンス Connection strings in Application Insights resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } この設定をデプロイ後、Azure Portalで確認すると、Azure FunctionsがApplication Insightsに正しく接続されていることが分かります。 これにより、Azure Functionsの「ログ」メニューから直接クエリを実行して、Application Insightsに送信されたログを確認できるようになります。 補足： hidden-link タグについて Function AppとApplication Insightsを関連付けると、Azureの内部では tags プロパティに hidden-link という特殊なタグが作成されます。これは、Azure PortalなどのUI上でリソース間の関連付けを表現するために使用されるものです。 APPLICATIONINSIGHTS_CONNECTION_STRING をアプリケーション設定に追加するだけで、通常はこの hidden-link タグがAzureによって自動的に作成・管理されます。そのため、Bicepテンプレートで明示的に hidden-link タグを記述する必要は基本的にありません。 このタグを手動で管理することは、サブスクリプションIDやリソースグループ名などをBicepファイルに含める必要があり、テンプレートの複雑性を増す要因にもなります。 そのため、推奨される方法は APPLICATIONINSIGHTS_CONNECTION_STRING の設定に任せて、 hidden-link の自動作成を利用することです。 参照： In bicep, how to property and securly set `hidden-link` in tags? 応用：複数のAzure Functionsを1つのApplication Insightsに紐付ける 複数のAzure Functionsのログを、1つのApplication Insightsでまとめて管理することも可能です。その場合も設定は同様で、各Azure Functionsの appSettings に、共通のApplication Insightsの接続文字列を追加するだけです。 resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } ログの識別性を高める 複数のFunctionsからログを集約すると、どのログがどのFunction Appから出力されたものか区別がつきにくくなる場合があります。 その際は、環境変数 WEBSITE_CLOUD_ROLENAME を設定することで、Application Insights上のログに表示されるクラウドロール名（ cloud_RoleName ）を任意の名前に変更できます。これにより、ログの発生源を容易に特定できるようになります。 参照： クラウド ロール名を設定する resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-1' } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-2' } ] } } } WEBSITE_CLOUD_ROLENAME を指定しない場合、 cloud_RoleName にはAzure Functionsのリソース名（この例では func-app-1 , func-app-2 ）が自動的に使用されます。 おわりに 今回は、Bicepを利用してAzure FunctionsとApplication Insightsを連携させる方法についてご紹介しました。 APPLICATIONINSIGHTS_CONNECTION_STRING を設定するという簡単な手順で、開発や運用の効率を大きく向上させることができます。Bicepを利用してAzure FunctionsとApplication Insightsでリソースを管理する際には、ぜひこの設定を活用してみてください。 今回作成したリソースは こちら ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Bicepで作成したAzure FunctionsとApplication Insightsをリンクする方法 first appeared on SIOS Tech. Lab .

はじめに 前回 は、GitLab上のリモートリポジトリとの連携やプロジェクトの作成・管理、ローカル環境でのクローン、ローカルリポジトリでの変更内容をリモートリポジトリに反映してみました。これで、複数の開発者で同じ変更履歴を共有することができるため、円滑にチーム開発を進められます。 Gitを使った開発では、コードの変更履歴を管理するだけでなく、複数の開発者が同時に作業を進めるための仕組みが必要です。その中心となるのが「ブランチ」という概念です。 今回は、Gitのブランチとは何かという基本から、チーム開発でよく使われるブランチ戦略、そしてGitLabでのマージリクエストを通じた具体的な開発フロー、さらにはコンフリクト（競合）の解消方法まで、実践的に解説していきます。 ブランチ説明と利用ケース ブランチとは、 第1回 でも軽く触れましたが、現在の作業から派生して新しい開発ラインを作成する機能です。新しい機能開発やバグ修正を行う際に、メインの開発ラインに影響を与えずに作業を進めることができます。作業が完了したら、上位のブランチに統合（マージ）します。 ブランチを作成することで、複数の開発者がそれぞれ異なる機能やバグ修正に同時に取り組んだり、メインの安定した状態を壊すことなく、新しい機能を追加したり、大きな変更を加えたりすることができます。 ブランチ戦略について Gitのブランチを効果的に使うためには、チーム全体で共通のルールが必要です。これが「ブランチ戦略」と呼ばれるものです。ここで大切なことは、必ずしも絶対的なブランチ戦略はなく、プロジェクトの性質に応じて適切なブランチ戦略を選択することです。 ここでは、代表的な4つの戦略の概要を見ていきましょう。 Git Flow Git Flowは、最も歴史が長く複雑なブランチ戦略です。 main、developブランチを中心としてそれぞれの修正用ブランチとリリース用ブランチを運用します。 特に大規模なプロジェクトや、頻繁なリリースよりも安定性と厳密なバージョン管理が求められるプロジェクトに適しています。 Webアプリのような継続的デリバリーを想定したプロジェクトには適していません。 バージョン管理と安定したリリースが可能ですが、5種類 (main, hotfix, release, develop, feature) のブランチを運用するため、ブランチ管理が複雑で運用コストが高い点が特徴です。 main: 本番環境にデプロイされている、常に安定したコードを保持するブランチです。ここに直接コミットすることは通常ありません。 develop: 次期リリースに向けた開発の中心となるブランチです。featureブランチでの作業が完了すると、ここにマージされます。 feature: 新機能開発のためのブランチです。developから分岐し、開発が完了するとdevelopにマージされます。 release: リリース準備のためのブランチです。developから分岐し、最終的なバグ修正やリリースバージョン情報の更新が行われます。完了後、mainとdevelopの両方にマージされます。 hotfix: 本番環境で発見された緊急のバグ修正のためのブランチです。mainから分岐し、修正が完了するとmainとdevelopの両方にマージされます。 Image Source: https://nvie.com/posts/a-successful-git-branching-model/ GitHub Flow GitHub Flowは、非常にシンプルで軽量なブランチ戦略です。継続的デリバリーを重視し、頻繁なデプロイが行われるWebサービスやSaaS開発に広く採用されています。 main, featureの2種類のブランチで運用します。基本的に main ブランチのみをメインとし、このブランチは「常にデプロイ可能」な状態を保ちます。すべての開発はmainから派生した新しいfeatureブランチで行われ、プルリクエスト（GitLabでのマージリクエスト）を通じてmainに統合されます。 シンプルで理解しやすく、運用が容易で、CI/CDとも相性が良いですが、複数のリリースを管理する場合には適していない点が特徴です。 GitLab Flow GitLab Flowは、Git Flowの厳密さとGitHub Flowのシンプルさを組み合わせたブランチ戦略です。GitHub Flowをベースにしつつ、環境ごとのデプロイや長期安定版の管理を考慮しており、特にGitLabのCI/CDやDevOps機能との統合を前提としています。 main, featureの2種類のブランチ運用を基本としつつ環境用のブランチを適宜導入して運用します。main ブランチを常にデプロイ可能にするのはGitHub Flowと同じですが、必要に応じて pre-production や production といった環境ブランチを導入し、段階的なデプロイを管理できます。これにより、ステージング環境でのテストを経て本番にデプロイするといったワークフローをブランチレベルで表現できます。 比較的シンプルな構造のまま複数のリリースを管理できますが、Git Flowほどの厳密なリリース管理には向いていない点が特徴です。 トランクベース開発 トランクベース開発は、チーム全員が1つのメインブランチ（trunkやmain）を中心に開発を進め、各自の変更を小さな単位で頻繁にメインブランチへマージするGitのブランチ戦略です。 この手法では、長期間存在する開発用ブランチや大規模なマージ作業を避け、「短命なブランチ」または直接のコミットを用い、1日1回〜数日に1回のペースでメインブランチに変更を統合します。これにより、コンフリクト（競合）の発生を抑止しやすく、常にリリース可能な安定したmainブランチ状態を保つことができます。 常に安定したメインブランチを維持でき、マージコンフリクトやリリース遅延のリスクが低いですが、長期ブランチや大規模リリースの運用には向いていない点が特徴です。 Trunk-Based Development For Smaller Teams: Scaled Trunk-Based Development: Image Source: https://trunkbaseddevelopment.com/ 一般に大規模かつ安定性を重視する場合は、運用するブランチを増やして対応する戦略が推奨され、小規模や頻繁なデプロイが行われる場合は、運用するブランチを少なくシンプルに対応する戦略が推奨されます。 チーム開発での課題 チーム開発では、複数の開発者が同じファイルを同時に変更することが頻繁にあります。その際に発生するのが「コンフリクト（競合）」です。Gitは賢いツールですが、同じファイルの同じ行を異なる方法で変更した場合など、どちらの変更を採用すべきか自動で判断できない場合にコンフリクトが発生します。 コンフリクトの例 図は、同じ起点から分岐したブランチAとブランチBで、同じファイル（index.html）をそれぞれ変更していることを示しています。この2つのブランチをmainブランチ（青い線）にマージしようとすると、Gitはどの変更を最終的に採用すべきか判断できず、コンフリクトが発生します。 チーム開発の実例 それでは、具体的なシナリオでGitHub Flowを使ったチーム開発を見ていきましょう。コンフリクトの実例と解決も行っていきます。 第4回のブログの手順を実施後、すでにgit cloneでローカルにリポジトリを取得していることを前提とします。 複数メンバーによる競合発生 GitHub Flowでは、mainブランチは常に安定しており、デプロイ可能な状態を保ちます。そのため、機能開発やバグ修正は必ずmainから新しいブランチを切って行います。 コンフリクトを起こすための2つのブランチを作成します。 ブランチA (feature/add-comment)での作業 mainブランチから新しいブランチfeature/add-commentを作成し、README.mdファイルにコメントを追加します。ブランチを作成する際は、git checkoutコマンドを実行します。-bオプションをつけることで、作成したブランチにそのまま移動します。 $ git checkout -b feature/add-comment Switched to a new branch 'feature/add-comment' README.mdを開き、以下の内容を追記します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Aさんが追加したコメント コミットとプッシュを行います。 $ git add README.md $ git commit -m "feat: Add a comment in README" $ git push -u origin feature/add-comment ブランチB (feature/update-description)での作業 次に、mainブランチに戻り、別の新しいブランチfeature/update-descriptionを作成します。こちらも同じREADME.mdファイルの同じ箇所に別の変更を加えます。 mainブランチに戻ります。 $ git checkout main Switched to branch 'main' Your branch is up to date with 'origin/main'. ブランチの作成と切り替えを行います。 $ git checkout -b feature/update-description Switched to a new branch 'feature/update-description' README.mdを開き、以下の内容に追記します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Bさんが追加したコメント コミットとプッシュを行います。 $ git add README.md $ git commit -m "feat: Update project description" $ git push -u origin feature/update-description これで、mainブランチを起点に、同じファイルの同じ行を異なる内容で変更した2つのブランチができました。 マージリクエスト（プルリクエスト）作成 GitLabのWeb UI上で、feature/add-commentブランチの変更をmainに統合するためのマージリクエスト (MR) を作成します。 GitLabでMRを作成します。 メニューの「マージリクエスト」から「新しいマージリクエスト」をクリックします。 ソースブランチとターゲットブランチを選択し、「ブランチを比較して続行する」をクリックして、feature/add-commentからmainへのMRを作成します。 「作成 merge request」をクリックしてMRを作成します。 GitLabでは、マージが完了したfeatureブランチを自動的に削除するオプションがあります。基本的にマージ後は不要になるブランチなので、積極的に削除してブランチリストをきれいに保ちましょう。ローカルブランチも git branch -d <ブランチ名> で削除できます。 mainにマージします。 この時点ではまだコンフリクトは起きていません。問題なくマージできるので、「マージ」をクリックしてマージを完了させます。 マージできたことを確認します。 次に、feature/update-descriptionブランチの変更をmainに統合するためのMRを作成します。 ソースブランチとターゲットブランチを選択し、「ブランチを比較して続行する」をクリックして、feature/update-descriptionからmainへのMRを作成します。 「作成 merge request」をクリックしてMRを作成します。 コンフリクトの発生を確認します。 MR作成後、GitLabの画面に「マージがブロックされました」というメッセージが表示されます。これは、feature/update-descriptionの変更と、すでにmainにマージされたfeature/add-commentの変更が同じ箇所を編集しているため、GitLabが自動でマージできないことを示しています。 コンフリクト解消 コンフリクトが発生したら、開発者が手動で解決する必要があります。 ローカルブランチに最新の変更を取り込みます。 feature/update-descriptionブランチにmainブランチの最新の変更を取り込みます。 自分の作業ブランチにいることを確認します。 $ git checkout feature/update-description Already on 'feature/update-description' Your branch is up to date with 'origin/feature/update-description'. mainブランチの最新を取り込みます。 git pullを実行すると、コンフリクトが発生したことがコマンドラインに表示されます。 $ git pull origin main Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 手動でファイルを修正します。 README.mdをエディタで開き、Gitが挿入した競合マーカーを確認します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 <<<<<<< HEAD // Bさんが追加したコメント ======= // Aさんが追加したコメント >>>>>>> main <<<<<<< HEADから=======までが現在のブランチ(feature/update-description)での変更、=======から>>>>>>> mainまでがmainブランチでの変更です。今回は両方のコメントを残すことにしましょう。マーカーを削除し、以下のように修正します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Bさんが追加したコメント // Aさんが追加したコメント コンフリクト解消のコミットとプッシュを行います。 修正が完了したら、変更をコミットし、リモートにプッシュします。 $ git add README.md $ git commit -m "Fix: Resolve conflict in README.md" $ git push origin feature/update-description マージ ローカルでコンフリクトが解決され、リモートにプッシュされると、GitLabのMR画面の「マージがブロックされました」というメッセージが消えます。レビューが完了したら、安心して「マージ」をクリックできます。 このように、コンフリクトは複数のブランチが同じ箇所を同時に変更した際に発生しますが、 git pull で最新の変更を取り込み、競合マーカーを参考に手動で修正することで、簡単に解決できます。 今回はシンプルなテキストにおけるコメントの重複でしたが、チーム開発の現場においてはソースコード内での処理など複雑なコンフリクトが発生する場合があります。 そのような場合、コンフリクトは発生してから解決するよりも、事前に避けることの方が重要です。コンフリクトを未然に防ぐために大切なことは、作業を始める前や、ブランチをプッシュする前に、必ず最新の変更をメインブランチから取り込むことです。 たとえば、 git pull --rebase というコマンドを使うと、リモートの最新コミットを基に自分のコミットを再適用し、履歴をきれいに保ちながらコンフリクトを最小限に抑えられます。こうした習慣を身につけることで、チーム開発はよりスムーズになり、余計なトラブルを減らすことができます。 コンフリクト解消の基本 プロセスを習得することで、チーム開発でのトラブルを恐れず、安心して開発を進められるようになりますが、 解決にかかる時間を減らすためにも、日頃からこまめに最新の変更を取り込むことを心がけましょう。 まとめ 今回の記事では、Gitを使ったチーム開発の要である「ブランチ」について深く掘り下げました。GitHub Flowを前提としたチーム開発の流れを実践し、さらにはコンフリクト（競合）の解消方法まで解説しました。 次回は、GitLabの主な利用機能とGitHubとの違いを解説していきます。 参考文献 https://nvie.com/posts/a-successful-git-branching-model/ https://docs.github.com/ja/get-started/using-github/github-flow https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/ https://trunkbaseddevelopment.com/   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (5) ～Git マスターへの道～「Git のブランチについて」 first appeared on SIOS Tech. Lab .

はじめに Git & GitLab入門ブログ Gitマスターへの道の第4回です。前回のGit & GitLab入門ブログ3Gitマスターへの道「Git操作チーム利用コマンドやロールバック」では、チーム開発で使うコマンド、コミットを戻す際に使用するコマンドについて紹介しました。 今回は、 リモートリポジトリの解説とリモートリポジトリへのsshキーの登録、リモートリポジトリ(プロジェクト)の作成、リモートリポジトリのクローンなどの操作、その他のリモートリポジトリへの変更を加える操作を実践的に解説していきます。 今回は、Gitのブランチとは何かという基本から、チーム開発でよく使われるブランチ戦略、そしてGitLabでのマージリクエストを通じた具体的な開発フロー、さらにはコンフリクト（競合）の解消方法まで、実践的に解説していきます。 実行環境 OS : WSL2 – Ubuntu 22.04.2 LTS リモートリポジトリとは? 共同開発においてリモートリポジトリはコードの共有やバックアップなどの役割を担っています。 リモートリポジトリはネットワーク上に存在し、チームメンバーで共有して使うリポジトリです。一方ローカルリポジトリは開発者のパソコン上に存在しており、個人で使用します。 リモートリポジトリとローカルリポジトリはClone, Pull, PushなどのGit操作によってやり取りを行っています。 そこで、チーム開発の現場でこのリモートリポジトリを提供している代表的なサービス、ソリューションについて再度説明します。 GitLab GitLabはGitの仕組みを利用したDevSecOpsプラットフォームです。DevSecOpsとは開発(Dev)・運用(Ops)のプロセスにセキュリティを組み込み、早期から継続的に安全性を確保する取り組みのことを差します。 GitLabの特徴はこのDevSecOpsとの一体化と組織内で運用できるセルフホスト型であることで、統合型のDevOpsプラットフォームとして優れています。 GitHub GitHubはGitの仕組みを利用してオンラインでソースコードなどの共有、管理などを行うことができるウェブサービスです。 GitHubは世界中のオープンソースプロジェクトが利用しておりコミュニティが活発であり、個人や企業などで使用されており、オープンソースコミュニティやシンプルなコード管理に優れています。 リモートリポジトリのクローン GitLabでのリモートリポジトリのクローンの手順を解説します。 ※今回はGitLabの手順を解説しますが、「ローカルにSSH鍵を作成して、公開鍵をリモートリポジトリ側に登録し、SSH経由で操作できるようにする」という流れはGitHub等の他サービスにおいても同様です。 ssh設定 まずGitLabに対してssh設定を行います。 自身のターミナルでsshキーを作成します。 Linux準拠のホームディレクトリの指定方法の場合は以下のコマンドで作成できます。 ssh-keygen -t ed25519 -f ~/.ssh/GitLab_key Windowsの標準ターミナルで実行する場合パスの指定方法が異なり以下のようになります。 ssh-keygen -t ed25519 -f %USERPROFILE%\.ssh\GitLab_key このコマンドは以下の構成でできています。 ssh-keygen  sshキーを生成するためのユーティリティ -t ed25519 鍵のタイプを指定するオプション -f ~/.ssh/GitLab_key 鍵の保存先と名前を指定 以下の画像はsshキー作成時の実行結果です。 ~/.sshディレクトリへ移動後コマンドを実行し、その際入力を求められますが何も入力せずにエンターを押して大丈夫です。 sshキーの作成 次にGitLabでこのsshキーを登録していきます。 GitLabへログイン後TOPページから、以下の画像のように自分のユーザーのアイコンから設定を開きます。 GitLabのTOPページ 画面左のサイドバーにユーザー設定があるので、ユーザー設定項目からSSHキーの箇所をクリックします。 ユーザー設定内のSSHキー 次に画面右中央の新しいキーを追加をクリックします。 SSHキー追加 先ほど作成したSSHキー(.pubがついているほう)の中身をcatコマンドなどで確認してコピーします。 公開鍵のコピー キーのセクションに先ほどコピーしたキーの中身を貼り付けます。その他の設定もお好みで入力しキーを作成をクリックします。 SSHキー登録時の設定画面 今回はキーの名前をカスタムしているのでconfigファイルにSSH設定を書き込んでおきます。 vi ~/.ssh/config viコマンドでconfigファイルを開き Host (GitLabのホスト名)     HostName (GitLabのホスト名)     User git     IdentityFile ~/.ssh/GitLab_key このテキストを貼り付けて保存します。 これでsshキーの設定ができました。 リモートリポジトリ(プロジェクト)の作成 次にリモートリポジトリ(プロジェクト)の作成です。 ユーザーアイコンの隣の＋マークから新規プロジェクト/リポジトリをクリックします。 GitLabのTOPページから新規プロジェクト作成 プロジェクト作成方法の選択画面です。今回は空のプロジェクトの作成をクリックします。 プロジェクト作成補法の選択画面 プロジェクトの設定画面です。プロジェクト名などを入力してプロジェクトを作成をクリックします。 プロジェクト作成設定画面 これでリモートリポジトリ(プロジェクト)の作成ができました。 GitLabからのGit clone 次に先ほど作ったリモートリポジトリ(プロジェクト)をローカルにcloneします。 プロジェクトのホーム画面で画面右側の上のほうにある「コード」という箇所をクリックします。そうすると以下のようなボックスが出てくるので「SSHでクローン」のURLをコピーします。 プロジェクトのTOPページ リモートリポジトリ(プロジェクト)をローカルリポジトリとして配置したいディレクトリでgit cloneを行います。 git clone (先ほどコピーしたSSHクローンの内容) を実行します。 以下のような実行結果が出れば成功です。 git cloneの実行結果 リモートリポジトリに変更を反映させる 次にadd,commit,pushを行いローカルリポジトリの変更をリモートリポジトリに反映させていきます。 尚、今回はブランチを切らずにすべてmainブランチで実施します。ブランチに関しては次回の Git & GitLab 入門 (5) ～Git マスターへの道～「Git のブランチについて」 で詳しく取り上げますのでそちらをご覧ください。 今回はmain.pyをローカルリポジトリに追加しました。こちらをリモートリポジトリに反映させていきます。 作成したmain.py まず、コマンドラインから実行する場合の手順です。 最初にadd を行います。これにより指定されたファイルはステージングエリアに追加されます。 git add (ファイル名) 次にcommitを行います。これによりステージングエリアの変更をローカルリポジトリに保存します。 git commit -m "コメント" 最後にpushを行います。これによりローカルリポジトリの変更がリモートリポジトリに送信されます。今回はmainブランチに直接変更を加えるのでオプションなどは付けずにコマンドを実行します。 git push 以下の画像はコマンドラインで一連の流れを実施した際の実行結果です。 コマンドラインでのadd, commit, pushの実行結果 VScodeから実行する場合以下のようになります。 add ソース管理のファイル名の右端にある＋ボタンを押すとファイルをステージングエリアに追加できる。 VScodeでのgit addの実行例 commit メッセージのテキストボックスにコメントを書き込みコミットボタンを押すとステージングエリアの変更をローカルリポジトリに保存することができる。 VScodeでのgit commitの実行例 push 変更の同期を押すとローカルリポジトリの変更がリモートリポジトリに送信される。 VScodeでのgit pushの実行例 まとめ 今回はリモートリポジトリの解説とリモートリポジトリへのsshキーの登録、リモートリポジトリ(プロジェクト)の作成、リモートリポジトリのクローンなどの操作、その他のリモートリポジトリへの変更を加える操作を実施しました。 これにより、Gitを活用してリモートリポジトリとの連携やプロジェクトの作成・管理、ローカル環境でのクローン、ローカルリポジトリでの変更内容をリモートリポジトリに反映できるようになりました 。 次回は、Gitのブランチについての説明とチーム開発でのブランチの実例を紹介します。 参考文献 https://wa3.i-3-i.info/diff811repository.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (4) ～Git マスターへの道～「リモートリポジトリとローカルリポジトリ」 first appeared on SIOS Tech. Lab .

こんにちは、PS-SL新卒1年目のひろです。 8/3にOSC京都2025に参加させていただきました。参加した中で特に印象に残った展示、セミナーについて紹介させていただきます。 さくらインターネット株式会社 さくらインターネット さんが行っていた「高火力シリーズ」についてのセミナーに参加させていただきました。私は、さくらインターネットさんと聞いてまず思い浮かんだのはレンタルサーバ事業で、高火力シリーズときいてどのようなサービスなんだろうと気になっていました。 今回ご紹介いただいた 「高火力シリーズ」 では、3つのGPUクラウドサービスが展開されています。今回のセミナーでは実際に生成AIを使用し、画像を生成するデモを見せていただきました。 生成AIにとってGPUはとても重要な要素です。GPUは小さなコアをたくさん持っており、大量の計算を同時にこなすような並列処理に特化しています。生成AIの学習や推論には膨大な計算が不可欠なため、GPUが活用されています。さくらインターネットさんの高火力シリーズはこのGPUを提供するサービスで、生成AIや機械学習の分野に持って来いなサービスです。 今回紹介されていた3つのサービスについてまとめます。 まず 高火力PHY 。こちらはGPUを8基搭載したベアメタルサーバーです。NVIDIA H100やH200といった超高性能なGPUを搭載したモデルが用意されています。高火力も高火力といった具合で、大規模なサービス開発に特化している印象を受けました。 次に 高火力VRT 。こちらはVM（仮想マシン）型のGPUクラウドで、NVIDIA H100、NVIDIA V100といったGPUのプランを選ぶことができます。チャットボットサービスなどの即応答性が求められるサービスに最適です。また、時間単位での課金制で 、柔軟に利用することができます。 最後に 高火力DOK 。こちらはコンテナー型GPUクラウドサービスで、作成したDockerイメージをpullし、イメージを実行することができます。こちらはバッチ処理のような終わりのある処理に適していると紹介いただきました。高火力DOKは秒単位での従量課金制で、実行時間のみコストが発生する仕組みとなっており、高火力なGPUを最小限のコストで利用できる点が大きな魅力です。AI関連のサービス開発や研究の敷居を下げてくれる素晴らしいサービスだと思いました。 今回のセミナーを通じて、「高火力シリーズ」が大規模処理、リアルタイム処理、バッチ処理といった多様なニーズをカバーしていることがよく分かりました。日本の生成AIサービスや研究を支える、土台のような存在だと感じました。 osdev-jp osdev-jp さんはOS開発に役立つ情報を収集、公開されているコミュニティで、今回は自作OSを展示されていました。 私はOS開発をしたことはなく、OSが何を行っているか大まかな知識しか持っていなかったのですが、お話していただいた内容から興味を持つことができました。特に魅力的に感じたのは、自分だけのGUIデザインやコマンドを作ることができる点と、普段何気なく使用しているPCの裏側でOSがどのような役割を果たしているのか実践的に深く学べるという点です。OS開発に関する書籍も紹介していただいたので折に触れて挑戦したいと思いました。 osdev-jpさんの展示内容。自作OSの展示です Japanese Raspberry Pi Users Group Japanese Raspberry Pi Users Group さんはRaspberry Piを用いた様々な製品、作品の展示をされていました。印象に残った展示についてまとめます。 まず、Raspberry Pi 500というRaspberry Piとキーボードが一体になっている製品です。モニターとマウスさえあればPCとして使用することが可能という、手軽で優れた製品です。自分はRaspberry Piをほとんど使用したことがなかったこともあり、キーボードと一体になっていることに驚きました。小型のモニタモジュールと一緒に使用できる様子を見せていただきました。 次にRaspberry Pi 5 + AI Cameraの展示です。AI CameraはカメラモジュールにAIが内蔵されており、モジュール側で物体検知を行えるという優れものです。小型カメラ側で検知してくれるという点に驚きました。 自分は電子工作を通ってきておりませんが、モジュールを組み合わせてアイデア次第で様々なものを作れるというのがとても魅力的で、自分でも何か作ってみたいと思いました。まずはRaspberry Piを購入するところから始めたいと思います！ Japanese Raspberry Pi Users Groupさんの展示内容。Raspberry Pi 500の展示です Japanese Raspberry Pi Users Groupさんの展示内容。Raspberry Pi 5 + AI Cameraの展示です 最後に 今回OSC京都2025に参加し、これまでよく知らなかった技術のお話をたくさん聞くことができ、とても有意義な時間を過ごすことができました。もっと技術的に深い議論ができるよう精進していきたいと思います。 素敵な展示、セミナーを開催してくださった皆様、本当にありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post OSC京都2025 セミナー＆展示紹介と感想 first appeared on SIOS Tech. Lab .

デザインに潜む「魔法の数字」 この記事では、なぜ現代のUIデザインにおいて「8の倍数ルール」と「12カラムシステム」が最適解として広く採用されているのか、その謎を紐解いていきます。この二つのルールを理解することは、デザインの品質を向上させるだけでなく、その背後にある「なぜ」を知ることで、より本質的なデザイン思考を身につける助けとなるでしょう。 すべての土台にある「2のべき乗」という考え方 UIデザインの話をする前に、まずそのUIが表示される媒体、すなわちコンピューターの根本的な仕組みに触れる必要があります。なぜなら、「8」という数字が選ばれる背景には、コンピューターの動作原理が深く関わっているからです。 コンピューターの言語「2進数」 ご存知の通り、コンピューターは内部ですべての情報を「0」と「1」の組み合わせで処理しています。これは、電気回路のスイッチが「オン」か「オフ」かという、2つの状態しか物理的に表現できないことに由来します。この「0」と「1」だけで数を表現する方法が「2進数」です。 しかし、2進数は人間にとって扱いにくいという問題があります。例えば、私たちが日常的に使う10進数の「255」は、2進数で表現すると「11111111」という8桁の長い文字列になってしまいます。これでは、人間が読んで理解したり、間違いなく入力したりするのは困難です。 2進数の最適な通訳「16進数」と「8ビット」 この問題を解決するために登場するのが「16進数」です。16進数がなぜ「通訳」として最適なのか。それは、2⁴=16 という数学的な関係があるためです。これにより、 2進数の4桁を、過不足なくピッタリ16進数の1桁に置き換えることができます。 例： 2進数「1111 1111」 → 16進数「FF」 4桁ずつ区切って機械的に変換できるため、2進数の情報を短く、人間が格段に扱いやすい形で表現できるのです。 そして、ここで重要になるのが「8」という数字です。コンピューターの世界では、伝統的に 8つのビット（2進数の桁）をひとまとめにした「1バイト」という単位 で情報を扱います。 これは、初期のコンピューターが8ビット単位でデータを処理していたことに由来する、いわばデジタル世界の基本単位です。 この「8ビット＝1バイト」という概念や、2³=8、2⁴=16 という関係性から、コンピューターの世界では「8」や「16」といった 2のべき乗の数字が「キリが良く、処理しやすい、基本的な数」 として扱われてきました。この技術的な背景が、UIデザインのルールにも影響を与えているのです。 ミクロのデザインを支配する「8の倍数ルール」 コンピューターが「8」という数字と親和性が高いことを理解した上で、次はいよいよUIデザインにおける「8の倍数ルール」について見ていきましょう。これは「8pt Grid System」とも呼ばれ、現代UIデザインの基礎となっています。 「8の倍数ルール」とは何か これは非常にシンプルなルールです。UIを構成するあらゆる要素のサイズや、要素間の余白（マージンやパディング）を、すべて8の倍数（8px, 16px, 24px, 32px, 40px…）で設計するというものです。アイコンのサイズ、ボタンの高さ、テキストと画像の間の距離など、あらゆる箇所にこのルールを適用します。 なぜ「8」の倍数が良いのか では、なぜこのルールがこれほどまでに支持されているのでしょうか。理由は大きく3つあります。 理由1：視覚的な一貫性と調和 最大の理由は、デザインに視覚的な秩序が生まれることです。8の倍数という共通の尺度を用いることで、各要素が数学的に整然と配置され、レイアウト全体に安定したリズム感が生まれます。ユーザーは無意識にその規則性を感じ取り、「きれいに整っている」「心地よい」という印象を受けます。逆に、7px, 13px, 19pxといったバラバラな数値で余白が設定されていると、どこか落ち着きのない、まとまりのないデザインに見えてしまいます。 理由2：意思決定の効率化 このルールは、デザイナーとエンジニア双方の作業効率を劇的に向上させます。「ここの余白はどれくらいにしよう？」という曖昧な感覚的な判断が不要になり、「8の倍数の中から選ぶ」という明確な指針が生まれます。これにより、デザインの意思決定が迅速化し、デザイナーとエンジニア間での「この余白は16pxでお願いします」といったコミュニケーションも円滑になります。デザインシステムを構築する上でも、このルールは不可欠な基盤となります。 理由3：レスポンシブデザインとの圧倒的な相性 これが、他の数字（例えば6や10）ではなく「8」が選ばれる決定的な理由です。現代のWebサイトやアプリは、PC、タブレット、スマートフォンなど多種多様な画面サイズや画素密度に対応する「レスポンシブデザイン」「高解像度対応」が必須です。このとき、画面サイズに応じてレイアウトや余白を調整する必要があり、「要素を半分にする」という操作が頻繁に発生します。 8は2³であるため、どこまでも2で割り続けることができます。 64px → 32px → 16px → 8px → 4px → 2px → 1px すべて整数であり、ピクセル単位で描画されるデジタルの世界と完璧に調和します。 一方で、もし12の尺度をスペースに採用するとどうなるでしょうか。 24px → 12px → 6px → 3px → 1.5px 1.5pxという小数点、いわゆる「サブピクセル」が発生してしまいます。これは、画面上で表示がぼやける原因となり、デザインの品質を損ないます。この「半分にし続けられる」という特性が、様々な画面サイズにクリーンに対応しなければならないUIデザインにおいて、8の倍数ルールを絶対的なものにしているのです。 マクロな骨格を司る「12カラムシステム」 「8の倍数ルール」が要素のサイズというミクロなデザインを司るのに対し、ページ全体の骨格というマクロなデザインを司るのが「12カラムシステム」です。ここで多くの人が「なぜここでは12なの？」と疑問に思います。Bootstrapのような有名なフレームワークも、この12カラムシステムを採用しています。 「12カラムシステム」とは何か これは、画面の表示領域の横幅を、目には見えない12個の均等な「カラム（柱）」に分割して考えるシステムです。デザイナーは、コンテンツをこの12本の柱のうち何本分を使って配置するか、という考え方でレイアウトを組んでいきます。 なぜレイアウトは「12」なのか その理由は、 12という数字が持つ「約数の多さ」 にあります。12の約数は「1, 2, 3, 4, 6, 12」と非常に多く、これがレイアウト設計に圧倒的な柔軟性をもたらします。 12カラムシステムを使えば、以下のような多様なレイアウトを簡単に、そして均等に作ることができます。 2分割レイアウト： 6カラム + 6カラム 3分割レイアウト： 4カラム + 4カラム + 4カラム 4分割レイアウト： 3カラム + 3カラム + 3カラム 非対称レイアウト： 8カラム（メイン）+ 4カラム（サイドバー） 非対称レイアウト： 9カラム（メイン）+ 3カラム（サイドバー） 非対称レイアウト： 10カラム（メイン）+ 2カラム（サイドバー） もしこれを8カラムシステムでやろうとすると、柔軟性が損なわれます。レイアウトの骨格を作る上では、2のべき乗であることよりも、多様な分割比に対応できることのほうが重要度が高いのです。 なお、このようなグリッドによるレイアウト方法は、紙媒体の誌面デザインでも基本となっています。 二つのルールの美しい共存 ここまで読んで、「8」と「12」という異なるルールが同時に存在することに、まだ少し混乱しているかもしれません。しかし、重要なのは、この 二つのルールは対立するものではなく、それぞれが担当する役割と階層が違う、完璧なパートナーである ということです。 12カラムシステム → ページの骨格（マクロレイアウト） 8の倍数ルール → 要素間の距離やサイズ（ミクロレイアウト） これを家に例えるなら、 「12カラムシステム」は家全体の間取りを決める設計図 です。「リビングはこの広さで、寝室を2つここに配置して…」と、大きな空間の分割を担います。 一方、 「8の倍数ルール」は、その部屋の中に置く家具のサイズや、家具と壁の間の距離、窓の高さなどを決める詳細なルール です。 Webサイトに置き換えると、まず12カラムシステムを使って「ヘッダー」「メインコンテンツ（8カラム分）」「サイドバー（4カラム分）」といったページの大きな骨格を決めます。次に、8の倍数ルールを使い、メインコンテンツとサイドバーの間の隙間を「24px」に設定し、記事タイトルとその下の本文の間の余白を「16px」に、本文のフォントサイズを「16px」に…と、詳細なデザインを詰めていくのです。この二つのルールを組み合わせることで、 「柔軟な骨格」と「整然としたディテール」を両立した、高品質なUIデザインが実現 します。 まとめ 本記事では、UIデザインにおける「8の倍数ルール」と「12カラムシステム」がなぜ最適と考えられているのかを解説しました。 8の倍数ルール は、コンピューターの基本単位である「8ビット」との歴史的な親和性を持ち、特にレスポンシブデザインにおける「半分にし続けられる」という特性から、要素のサイズや余白といった ミクロなデザイン に最適です。 12カラムシステム は、その圧倒的な約数の多さから、多様な分割パターンを可能にし、ページの骨格となる マクロなレイアウト設計 に最適です。 これらのルールは、単なる見た目の美しさのためだけでなく、コンピューターの仕組み、人間の認知、そして開発の効率性までを考慮した、合理的で洗練されたデザイン手法です。 もちろん、デザインに絶対の正解はありません。他の方法が適しているケースもあるかと思います。また、ディスプレイの画素密度が上がり、コンピューターの計算や通信速度が向上することで割り切りやすさへの考慮は低くなるかもしれません。しかし、このような手法の原理は、さまざまな開発のヒントになるでしょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post UIデザインはなぜ「8の倍数ルール」と「12カラムシステム」が最適と考えられているのか first appeared on SIOS Tech. Lab .

なぜ今、コンテナ環境導入は“スモールスタート”が重要なのか？ DevOps・CI/CDにより高速デリバリーを実現する環境やオンプレミス・クラウドなど様々な環境を意識した開発・運用が主流となった現在、コンテナ技術はインフラ環境の新しい標準構成として多くのサービスや企業へ導入されています。 しかし実際の現場では、 「まず何から始めればいいかわからない」 「KubernetesやOpenShift、Rancherといった技術の学習コストが大きい」 「いきなり本番運用レベルの環境構築は躊躇してしまう」 といった悩みを抱える企業も少なくありません。 これらの課題を解決するのがコンテナ環境のスモールスタートです。 スモールスタートによる重要なポイントでは、 「短期間・低コストの投資で効果的な結果を確認できる」 「小規模環境から明瞭な運用を実施し学習できる」 「PoC環境から円滑に本番環境へ移行できる」 などが挙げられます。 このようなコンテナ導入の課題をサイオステクノロジーがサポートし、スモールスタートでの強みを活かして、短納期・低額での環境の提供を実現するのが「 コンテナ導入スモールスタートパック 」です。 サービスの特徴：コンテナ導入スモールスタートパックの3つのポイント コンテナ導入スモールスタートパックの大きな特徴として3点ご紹介します。 短納期による環境提供 最短2か月で要件のヒアリングから構築、引き渡しを行いPoCなどに迅速に取り組む事が可能となります。 低額で始められるコンテナ環境 導入費用を抑えたミニマムな環境から構築可能となります。 パッケージ化されたシンプルな導入プロセス Kubernetes自体のコマンド操作手順だけでなく、GUI上での管理コンソールの操作手順書等も提供し、シンプルながら分かりやすい導入後の学習面もサポートいたします。 これらの3つのポイントはコンテナ環境の構築・運用では非常に重要となります。 サービス紹介：最短2ヶ月〜導入可能なサービスパッケージ 本サービスは、OpenShiftまたはRancherを用いた本格的なコンテナプラットフォーム環境を、最小構成から構築するスモールスタート導入支援サービスです。 オンプレミスでもクラウドでも対応可能で、導入後の運用まで見据えた設計・構築サービスをご提供します。 導入プラットフォーム：OpenShift / Rancher 提供環境：オンプレミスまたはクラウド（AWS / Azure / GCP） 工期：2ヶ月～ ※ご要件に応じて調整可能 価格：500万円～ ※構成・規模によりご相談 提供ドキュメント： 環境概要設計書 パラメーターシート プラットフォーム標準運用手順書 対応パターン例：様々なニーズに応じて柔軟に対応します コンテナ導入スモールスタートパックでは様々なニーズに向けたパターンへ対応可能です。 パターン1：まずは最低限の環境からスモールスタート OpenShiftまたはRancherによるスモールスタート構成を構築！ オンプレミス環境だけではなく、クラウド（AWS/Azure/GCP）環境でも同等の構成で導入可能 初めてのコンテナ環境導入でも概要設計書や操作手順書付きで操作・学習も安心 パターン2：閉域網環境（Air Gap環境）でのスモールスタート 閉域網環境（Air Gap環境）にもサービス導入が可能！ 通常の環境と同様にOpenshiftまたはRancherによる構成から選んで構築可能 閉域網環境（Air Gap環境）用の構成周りのドキュメントも充実し、効果的なスモールスタートが可能 上記に限らず、オンプレミスやクラウド、コンテナオーケストレーターに応じた様々なケースへ対応可能となっています。 まとめ コンテナ環境の導入は「小さく始めて、大きく育てる」のが成功の鍵です。 本サービスは、スモールスタートによる技術検証や技術習得と将来的な本番環境への展開の双方を視野に入れた “実践的スモールスタート” を実現します。 まずはお気軽にご相談ください。 https://sios.jp/products/it/container-consulting/smallstartpack/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンテナ環境導入の第一歩を支援！ 「コンテナ導入スモールスタートパック」サービスのご紹介 first appeared on SIOS Tech. Lab .