はじめに 前回 は、GitLabのプロジェクトについて解説しました。GitLabのプロジェクトは、ソースコード管理を中心に、イシュー管理、CI/CD、Wiki、セキュリティまでをまとめて扱うことができます。これにより、開発プロセス全体を効率化し、ツール間の切り替えや管理の手間をなくすことができます。 今回は、その中でもGitLabのCI/CD（継続的インテグレーション・継続的デリバリー）に焦点を当てます。CI/CDは、開発プロセスを自動化し、生産性を大きく向上させる方法です。 まずは、CI/CDの基本を解説し、GitLab Runnerのインストールとセットアップを行います。そしてnginxのコンテナイメージを自動でビルド・プッシュ・デプロイする簡単なパイプラインを構築するまでを解説します。 Kubernetesクラスターとの連携をするため、以下を前提としています。本記事では minikube を利用します。 Dockerやコンテナの基本操作を理解していること Kubernetesの基本的な概念（Pod, Deployment, Namespaceなど）を知っていること kubectl コマンドを実行できる環境があること GitLab CI/CDの概要 CI/CD（Continuous Integration / Continuous Delivery & Deployment）は、継続的インテグレーション（CI）と継続的デリバリー（CD）の2つの概念から成り立っています。 継続的インテグレーション (CI)：開発者がコードをリポジトリにマージするプロセスです。マージされるたびに自動的にビルドとテストが実行され、バグを早期に発見できます。これにより、コードの品質を常に高いレベルに保つことができます。 継続的デリバリー (CD)：テスト済みのコード変更を、いつでも環境にデプロイできる状態に保つプロセスです。手動でデプロイすることもできますが、継続的デプロイメントでは、すべてのテストがパスしたら自動的にデプロイが行われます。 GitLabは、このCI/CDワークフローを標準機能としてサポートしています。「.gitlab-ci.yml」という設定ファイルを作成すれば、ビルド、テスト、デプロイなどのパイプラインを簡単に定義できます。 .gitlab-ci.ymlによって自動化されたタスク（ジョブ）は、GitLab Runnerというエージェントによって実行されます。GitLab Runnerは、パイプラインの指示を受け取り、実際の作業を行う実行役です。GitLab Runnerは、GitLabとは別にインストール・登録する必要があります。 KubernetesとGitLabの連携 GitLab Runnerは、Dockerや仮想マシンなど様々な実行環境（Executor）でジョブを実行できますが、今回はKubernetesとの連携をとりあげます。Kubernetes Executortは、ジョブをKubernetesのPodとして実行する仕組みのことです。さらに詳しく知りたい人は以下のURLを参考にしてみてください。 https://docs.gitlab.com/runner/executors/kubernetes/ GitLabとKubernetesを連携させるには、Kubernetesクラスター上にGitLab Runnerをデプロイします。GitLab、GitLab Runner、Job Pod、Kubernetesクラスターの関係性は以下のようになっています。 GitLabのパイプライン実行：ユーザーがGitLab上でコミットやマージを行うと、CI/CDパイプラインが自動的にトリガーされます。 GitLab Runnerの起動：パイプライン内のジョブが、Kubernetesクラスター上で動作しているGitLab Runnerに割り当てられます。 Job Podの生成：GitLab RunnerはKubernetes Executorを使用し、ジョブを実行するために一時的なJob PodをKubernetesクラスター内に自動生成します。Job Podはジョブ完了後に削除されます。 コマンドの実行：このJob Pod内で、パイプラインのジョブに定義されたコマンド（例：kubectl apply）が実行されます。 コンテナのデプロイ：コマンドの実行により、アプリケーションのコンテナがKubernetesクラスター内にデプロイされます。 この連携により、kubectlコマンドなどを手動で実行することなく、GitLab上でデプロイを自動化できます。GitLabとKubernetesを連携させるために、GitLab RunnerをKubernetesに導入していきます。 環境情報 GitLab：SaaS版 minikube：v1.36.0 Kubernetes Server Version: v1.33.1 kubectl：v1.33.1 helm：v3.18.6 GitLab Runnerを導入してみる それでは、ローカル環境に簡単にKubernetesクラスターを構築できるminikubeを使って、GitLab Runnerを導入してみましょう。minikubeはインストール済みであることを前提とします。 GitLabで今回使用するプロジェクトを作成します。プロジェクトの作成方法は 第4回 、 第7回 を参考にしてみてください。今回はブランチの考慮は行わないのでmainブランチのみで検証していきます。 GitLabでプロジェクトのCI/CD設定からRunnerの登録トークンを取得します。 メニューの 設定＞CI/CD から[プロジェクトRunnerを作成]をクリックします。 タグを入力して、あとはデフォルトで[Runnerを作成]をクリックします。 タグは.gitlab-ci.ymlでGitLab CI/CDでジョブを実行するRunnerを選択するために使用します。 表示された Runner認証トークン（glt-xxxxxxx）をメモします。 GItLabはこのページのままで大丈夫です。 それでは、GItLab Runnerを導入してみましょう。   ローカル端末で操作します。 minikubeを起動します。 $ minikube start Kubernetesにアプリケーションをデプロイする標準的なツールであるHelmをインストールします。 $ sudo snap install helm --classic インストールが完了したら、Helmが正しくインストールされたか確認します。 バージョン情報が表示されれば、インストールは成功です。 $ helm version version.BuildInfo{Version:"v3.18.6", GitCommit:"b76a950f6835474e0906b96c9ec68a2eff3a6430", GitTreeState:"clean", GoVersion:"go1.24.6"} GItLab Runnerをデプロイするネームスペースを作成します。 $ kubectl create namespace gitlab GItLab Runnerをデプロイします。 $ helm install gitlab-runner gitlab/gitlab-runner -f values.yaml -n gitlab values.yaml gitlabUrl: https://gitlab.com runnerToken: "<取得したRunner認証トークン>" rbac:   create: true   clusterWideAccess: true   rules:     - resources: ["configmaps", "pods", "pods/attach", "secrets", "services"]       verbs: ["get", "list", "watch", "create", "patch", "delete"]     - resources: ["secrets"]       verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]     - resources: ["serviceAccounts"]       verbs: ["get"]     - apiGroups: [""]       resources: ["pods/exec"]       verbs: ["create", "patch", "delete"] serviceAccount:   create: true   name: "gitlab-runner"    runners:   config: |     [[runners]]       name = "Kubernetes GitLab Runner"       executor = "kubernetes"       shell = "bash"       [runners.kubernetes]         terminationGracePeriodSeconds = 5         privileged = true         allow_privilege_escalation = true         image = "alpine" 少ししてから、GItLab Runner Podがデプロイされているか確認します。 $ kubectl get pod -n gitlab NAME                             READY   STATUS    RESTARTS   AGE gitlab-runner-85d8fbcdc4-94ph2   1/1     Running   0          94s GitLab Runnerがローカルのminikubeに接続するためのkubeconfigの設定をします。 $ kubectl config view --minify --flatten --raw > kubeconfig-inline $ sed -i 's|https://127.0.0.1:32771|https://kubernetes.default.svc|' kubeconfig-inline 以下で表示されるbase64エンコードしたkubeconfigの文字列は後ほど使用するので、記録しておきます。 $ cat kubeconfig-inline | base64 -w 0 GitLabの画面に戻ります。 [Runnerを表示する]をクリックし、「アサインされたプロジェクト」のRunnerが図のように緑のオンラインになっていたら連携完了です。 Ci/CDの環境変数設定をします。ここで先ほど記録したbase64エンコードしたkubeconfigの文字列を環境変数に設定します。 メニューの 設定>CI/CD から変数を開きます。CI/CD変数の[変数を追加]をクリックします。 キーと値を入力して、[変数を追加]をクリックします。 kubeconfigは機密情報なのでマスク（非可視化）しています。 キー：KUBECONFIG_BASE64 値：＜先ほど記録したbase64エンコードしたkubeconfigの文字列＞ 追加したCI/CD変数が表示されていたら完了です。 .gitlab-ci.ymlについて .gitlab-ci.ymlは、GitLab CI/CDパイプラインを定義するためのYAMLファイルです。プロジェクトのルートディレクトリに配置します。 このファイルでは、さまざまなキーワードや要素を使って柔軟なパイプライン定義が可能です。 主な基本構造と記述方法 stages：パイプラインの実行順序を定義します。例えば、build、test、deployといったステージを設定できます。各ジョブはstageでそれぞれ自身が所属するステージを指定します。 job：具体的に何を実行するかを定義します。script要素でコマンド記述が必須です。トップレベルのキー名がそのままジョブ名になります。例えば、build_jobの場合はジョブ名がbuild_jobになります。 stagesで順序を定義し、ジョブごとに所属するステージを指定することで一連の処理フローを構築します。stagesで定義した順番に、同一ステージのジョブは並列、次のステージのジョブは順次実行されます。 代表的な機能 tags：使用するGitLab Runnerを指定します。 image：ジョブを実行するためのDockerイメージを指定します。Docker / Kubernetes Executorに限ります。 services：テストやビルド環境に必要な外部サービス（例：DB）用の補助コンテナを追加します。Docker / Kubernetes Executorに限ります。 script：ジョブで実行するコマンドを記述します。 before_script / after_script：全ジョブや特定ジョブ実行前後の共通コマンドを定義できます。 variables：環境変数やパイプライン用の変数を定義できます。 rules：ブランチ・タグ・パイプラインなどの条件分岐でジョブの起動制御が可能です。mainブランチへpushされた時だけデプロイを実行する場合などに使用します。 参考： https://docs.gitlab.com/ci/yaml/ コンテナイメージのビルド・プッシュ・デプロイをしてみる CI/CDパイプラインを構築し、コンテナイメージのビルドからデプロイまでを自動化します。このプロセスは通常、複数のステージに分かれます。 build-and-push ステージ：ここでは、アプリケーションのコンテナイメージをDockerでビルドします。ビルドしたイメージは、GitLabのコンテナレジストリにタグを付けてプッシュします。これにより、作成したイメージがCI/CDパイプラインで利用可能になります。 deploy ステージ：build-and-push ステージでビルド・プッシュされたコンテナイメージを使用して、ローカル環境のminikubeにアプリケーションをデプロイします。このステージでは、kubectlを使って、デプロイメントの更新やサービスの公開を行います。 はじめに、Gitリポジトリをローカルにクローンします。 $ git clone <GitリポジトリのURL> 以下のディレクトリ構造でファイルを作成していきます。 . ├── .gitlab-ci.yml ├── Dockerfile ├── README.md ├── kubernetes │   └── deployment.yaml.tpl └── src     ├── html     │   └── index.html     └── nginx.conf gitlab-ci.ymlにDockerビルドのステップを追加します。 この例では、docker:dind（Docker in Docker）サービスを使ってDockerコマンドを実行し、コンテナイメージのビルドとレジストリへのプッシュを行っています。実運用では権限やネットワーク設定に注意が必要ですが、ここでは動作確認のための簡易構成として使います。 .gitlab-ci.yml stages:   - build-and-push   - deploy variables:   DOCKER_HOST: tcp://docker:2375   DOCKER_TLS_CERTDIR: ""   K8S_NAMESPACE: gitlab  build-and-push:   tags:     - git-tutorial-8   stage: build-and-push   image: docker:28.4.0-alpine3.22   services:     - docker:28.4.0-dind-alpine3.22   before_script:     - until docker info; do sleep 1; done;   rules:     - if: '$CI_COMMIT_BRANCH == "main"'   script:     - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY     - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .     - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG deploy-to-minikube:   tags:     - git-tutorial-8   stage: deploy   image:      name: bitnami/kubectl:1.33.1     entrypoint: [""]   before_script:     - echo "$KUBECONFIG_BASE64" | base64 -d > kubeconfig     - export KUBECONFIG=$(pwd)/kubeconfig   rules:     - if: '$CI_COMMIT_BRANCH == "main"'   script:     - kubectl config set-context --current --namespace=$K8S_NAMESPACE     - kubectl create secret docker-registry regcred --docker-server=https://registry.gitlab.com --docker-username=$CI_REGISTRY_USER --docker-password=$CI_REGISTRY_PASSWORD -n $K8S_NAMESPACE || true     - envsubst < kubernetes/deployment.yaml.tpl > deployment.yaml     - kubectl apply -f deployment.yaml Dockerfile FROM nginx:alpine COPY src/nginx.conf /etc/nginx/nginx.conf COPY src/html/index.html /usr/share/nginx/html/index.html CMD ["nginx", "-g", "daemon off;", "-p", "8080"] src/html/index.html <!DOCTYPE html> <html> <head>   <meta charset="UTF-8" />   <title>GitLab CI/CD Demo</title>   <style>     body {       font-family: sans-serif;       background-color: #f0f0f0;       text-align: center;       padding-top: 50px;     }   </style> </head> <body>   <h1>Deployment Successful!</h1>   <p>This is an application deployed via the GitLab CI/CD pipeline.</p> </body> </html> src/nginx.conf user  nginx; worker_processes  auto; error_log  /var/log/nginx/error.log notice; pid        /run/nginx.pid; events {     worker_connections  1024; } http {     include       /etc/nginx/mime.types;     default_type  application/octet-stream;     charset       utf-8;     log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '                       '$status $body_bytes_sent "$http_referer" '                       '"$http_user_agent" "$http_x_forwarded_for"';     access_log  /var/log/nginx/access.log  main;     sendfile        on;     #tcp_nopush     on;     keepalive_timeout  65;     #gzip  on;     server {         listen 8080;         location / {             alias /usr/share/nginx/html;             index index.html index.htm;             default_type text/html;             charset utf-8;         }     }     include /etc/nginx/conf.d/*.conf; } kubernetes/deployment.yaml.tpl apiVersion: apps/v1 kind: Deployment metadata:   name: nginx-deployment   labels:     app: nginx spec:   replicas: 1   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - name: nginx-container         image: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG} # GitLab CI/CD の環境変数         ports:         - containerPort: 8080       imagePullSecrets:       - name: regcred --- apiVersion: v1 kind: Service metadata:   name: nginx-service spec:   type: LoadBalancer   ports:   - port: 8080     targetPort: 80   selector:     app: nginx ファイルを作成したら、リモートリポジトリにプッシュします。 $ git add . $ git commit -m "git-tutorial-8" $ git push origin main プッシュしたらメニューの ビルド>パイプライン から、リポジトリへのプッシュをトリガーにパイプラインが実行されていることを確認します。 ステータスが「成功」になっていたら完了です。 各ステージのステータスも確認しておきましょう。 パイプラインの下に表示されているコミットメッセージの下の数列をクリックします。 .gitlab-ci.ymlで定義した2つのステージが完了していることが確認できます。 それでは、ビルドしたコンテナイメージがプロジェクトのコンテナレジストリにプッシュされていることを確認しましょう。 メニューの デプロイ>コンテナレジストリ から、プロジェクトのコンテナレジストリを確認します。 コンテナイメージが表示されたら完了です。 次に、アプリケーションがデプロイされていることを確認しましょう。 ローカル端末で操作します。 デプロイしたネームスペースのリソースを確認します。 nginxのservice、deployment、podが作成されていることが確認できます。 $ kubectl get all -n gitlab NAME                                    READY   STATUS    RESTARTS   AGE pod/gitlab-runner-767f96f489-f2qsb      1/1     Running   0          13m pod/nginx-deployment-7cdb8748c6-bbwlm   1/1     Running   0          12m NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE service/nginx-service   LoadBalancer   10.98.81.158   <pending>     8080:32740/TCP   12m NAME                               READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gitlab-runner      1/1     1            1           13m deployment.apps/nginx-deployment   1/1     1            1           12m NAME                                          DESIRED   CURRENT   READY   AGE replicaset.apps/gitlab-runner-767f96f489      1         1         1       13m replicaset.apps/nginx-deployment-7cdb8748c6   1         1         1       12m 外部からminikube内のサービスにアクセスできるようにします。 $ minikube tunnel ターミナルはそのままにして、ローカル端末のブラウザで http://127.0.0.1:8080/ にアクセスします。 アプリケーションの画面が表示されたら完了です。 これで、Gitリポジトリにプッシュするだけで次の一連のワークフローを自動化することができました。 コンテナイメージをビルド ビルドしたコンテナイメージをGitLabのプロジェクトのコンテナレジストリにプッシュ プッシュしたコンテナイメージを使用して、Kubernetesクラスターにアプリケーションをデプロイ まとめ 今回は、CI/CDの基本から、GitLab Runnerの導入、そしてコンテナイメージのビルド・プッシュ・デプロイまで、一連のワークフローを解説しました。 この自動化されたプロセスにより、開発者はより頻繁にコードをリリースでき、サービスの改善サイクルを加速させることができます。 参考文献 http://xn--docs-u83c.gitlab.com/ci/ https://docs.gitlab.com/runner/executors/kubernetes/ https://docs.gitlab.com/ci/yaml/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (8) ～Git マスターへの道～「GitLabのCICD設定」 first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ Azure Database for MySQLを利用している方 SSL/TLS証明書に関する基本的な知識を持つ方 はじめに こんにちは。サイオステクノロジーのはらちゃんです！今回3本目のブログ執筆です。 Azure Database for MySQLを利用していたら証明書エラーになったので調べた結果をお話したいと思います。 概要 ある日突然、Azure Database for MySQLへの接続が「証明書エラー」でできなくなった──。 DigiCertGlobalRootCA.crt.pem を利用しており、こんな経験をした方はいませんか？ もしかしたら、「証明書が予期せず切れた？」と感じたかもしれません。しかし、その原因は、Azure側がセキュリティ強化のために 計画的にルート証明書を変更した ためです。 今回は、このAzure Database for MySQLで発生したルート証明書変更の背景、なぜ変更が必要だったのか、どのように対応すべきかを詳しく解説します。 なぜ証明書の変更が必要？ これまでAzure Database for MySQLで利用されていたルート証明書 DigiCertGlobalRootCA.crt.pem は、「 SHA-1 」というハッシュアルゴリズムで署名されていました。 しかし、このSHA-1には 深刻な脆弱性 が発見されており、現在では安全とは言えません。多くのWebブラウザやセキュリティ機関が、SHA-1証明書の使用を非推奨としています。 そこでMicrosoftは、ユーザーのデータセキュリティとコンプライアンスの基準を維持するため、より強固な「 SHA-256 」で署名された新しいルート証明書 DigiCertGlobalRootG2.crt.pem への計画的な移行を進めていました。 利用していた環境で突然接続が無効になったように感じられたのは、この移行期間において、MySQLサーバー側が新しい証明書を要求するように更新されたためと考えられます。 セキュリティは常に進化しており、古い技術は新しい脅威に対応できなくなります。今回の変更は、Azureがユーザーに最新のセキュリティを提供するための重要なステップだったのです。 　 SHA-1 SHA-256 概要 任意の長さのデータを160ビットの固定長ハッシュ値に変換 固定長の256ビットのハッシュ値を生成 特徴 衝突耐性が低下しており、セキュリティリスク SHA-1よりも高いセキュリティと衝突耐性 大きな違いは「生成されるハッシュ値の長さ」と「セキュリティの強度」です。 証明書の有効期限切れが原因ではない 「証明書エラー」と聞くと、まず「有効期限が切れたのでは？」と思うかもしれません。 確かに、サーバー証明書の有効期間はセキュリティ上の理由から年々短くなる傾向にあります。 しかし、今回のAzure MySQLの接続問題は、 証明書の有効期限切れが直接の原因ではありません 。あくまで、より安全な証明書への切り替えという、Azureの計画的なメンテナンスの一環でした。 2025 年 9 月 1 日以降、Azure Database for MySQL フレキシブル サーバーのルート証明書の変更を開始しています。 この違いを理解することは、今後のトラブルシューティングにおいても非常に重要です。 今後の対応 このルート証明書の変更については、Microsoftの 公式ドキュメント で詳しく説明されています。今回のメンテナンスにより、以下の対応が求められます。 新しいルート証明書のダウンロード Microsoft Learnのドキュメントから、最新のルート証明書（例: DigiCertGlobalRootG2.crt.pem ）をダウンロードします。 アプリケーションへの適用 お使いのアプリケーションや接続ライブラリ（JDBC, ODBC, .NET, MySQL Connector/Pythonなど）の設定で、 ダウンロードした新しいルート証明書を信頼するようパスを指定 します。多くの場合、 ssl_ca や cafile といったパラメータで設定します。 既存の証明書との併用（推奨） 一時的な期間は、古い証明書と新しい証明書の両方を信頼するように設定できる「 CAバンドルファイル 」を作成・利用することが推奨されます。これにより、環境全体が新しい証明書に対応するまでの移行期間中の接続断を防ぐことができます。 また、 メンテナンスの通知設定 なども紹介されているので合わせて確認しておくと役立つと思います。 まとめ 今回は、Azure Database for MySQLで発生したルート証明書変更の背景と、その対応策について解説しました。 「証明書エラー」の裏には、サービスのセキュリティ強化という重要な目的がありました。突然の接続断に驚かれたかもしれませんが、 DigiCertGlobalRootG2.crt.pem のような新しい安全な証明書への更新は、現代のクラウドサービス運用において不可欠なプロセスです。 今後もAzureからの重要なお知らせには注意を払い、公式ドキュメントを参照しながら早めに対応することが、安定したサービス運用の鍵となります。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure MySQLの使い方｜突然の接続エラー？ ルート証明書変更の原因と対応策 first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジー OSS サポート担当 山本 です。 今回は 2025年5月末にリリースされた RHEL10 へのアップグレードに関するお話です。 RHEL9 から RHEL10 に移行する場合の、RHEL 同梱版 squid の変更点について確認したいと思います。 ご存じのとおり、squid は必須のソフトウェアというわけではないので、使っている場合にのみ気にする必要がある、程度のものですが、何かの参考になればと思います。 ■メジャーバージョンの更新 ベースとなるバージョンが squid 6.10 になりました 。(RHEL9 では squid 5.2 がベース) Red Hat 社から公表されている情報 は、確認時点では (Red Hat 社が用意している squid 導入マニュアル等も含めて) このベースバージョンについての情報以外に RHEL9 のものから特に変更は確認できません。 しかし、メジャーバージョンが変わっているので、機能追加や動作改善などを含め変更点は多数存在しているでしょう。 実際に squid 公式 github ページの Releases で squid 6 系の一番最初のリリース情報を確認してみると、以下のとおり非常に多数の項目が確認できます。 (末尾の方には “… and ～” と一まとめにされた内容もあるので、細かく見れば変更箇所は相当な数になるでしょう…) 　・ Release v6.0.1 今回はそんな変更点の一部を確認していきます。 ■一部機能の削除 一部の機能やツールなどが削除されました。 ただしその殆どは以下のページで説明されているとおり、削除されたものの大半は (過去に使われてはいたけれど) 既に完全に使用されておらず、消されすらせずに放置されていたもの や 別の機能に置き換えられて使われなくなったもの です。 　・ Schedule for Feature Removals 他、squid の内部管理に使用する “Cache Manager” へのアクセス手段の一つ である “cache_object://” という URL スキームが削除されていますが、こちらは使っているとしても別のアクセス手段を使えば問題ないでしょう。 　・ cache_object:// URI Scheme 　・ The Cache Manager その他、一部環境への対応が打ち切られたりしていますが、 これらの機能削除によって影響を受けることはまずない と言ってよさそうです。 ■ヘッダの変更 レスポンス時に使用されていた http ヘッダ “X-Cache” と “X-Cache-Lookup” が、2022年に標準化された http ヘッダ “Cache-Status” に置き換えられました。 　・ RFC 9211: The Cache-Status HTTP Response Header Field squid のレスポンスを利用しており、かつこれらのヘッダを使用していた場合には確認と変更が必要になります。 ■ログ機能の強化 squid が確立した TLS 接続 (SSLBump なども含む) に関する秘密鍵や暗号化などの情報 を、wireshark などのツールで確認できるような ログとして記録する ことができる機能と、この機能を利用するための設定項目 “ tls_key_log ” が追加されました。 ※ このログの情報を利用すれば通信内容を復号できてしまう 可能性があるので、扱いには細心の注意が必要です。 　・ tls_key_log また、設定項目 “ logformat ” に、例えば接続の内部 ID を記録する “transport::>connection_id” など、いくつかの設定が追加されています。 　・ logformat (v6) 　・ logformat (v5) これらのように、ログに関連する機能が強化されています。 ■その他設定項目の変更点 ログ関連以外の設定項目の変更点としては、 キャッシュエントリのヒットごとに整合性の検証をする設定 である “paranoid_hit_validation” という項目が追加されています。 　・ paranoid_hit_validation 他には追加・削除された設定項目はなく 、各設定項目について 設定を行わなかった場合のデフォルト値 も変更はないようです。 ただし、例えばデフォルト値は “設定なし” で変更はありませんが、 設定ファイルの設定がデフォルト値の “設定なし” の場合の 実際の内部的なデフォルト値が変更 されている “sslcrtvalidator_program” や、機能の使用に必要となるインストールオプションが変わっている “loadable_modules” などのように中身に変更が入っているものもあります。 　・ sslcrtvalidator_program (v6) 　・ sslcrtvalidator_program (v5) 　・ loadable_modules (v6) 　・ loadable_modules (v5) このため、バージョンアップという節目を機に、一度現在の設定の状態や意味・意図を見直しておくとよりよいでしょう。 ■最後に 今回は RHEL9 → RHEL10 へのアップグレードに係る、同梱版 squid の変更点を確認しました。 確認してきたとおり、レスポンスヘッダの変更など若干の変更点はありますが基本的な動作へ大きく影響を与える変更はほぼなく、ほとんどの場合は 特に問題なく移行できるはず です。 これは squid に限った話ではありませんが、 バージョンが変わったからと言ってそのソフトウェアの基本的な役割や基本的な動作ががらりと変わることは稀 であり、大体の場合の変更内容は 　・コードの改善 (効率化・高速化や安全性の強化など) 　・不具合や問題点の修正 　・より便利にするための機能追加 (今回の話で言えばログ機能の強化など) 　・標準仕様への準拠 (今回の話で言えばヘッダ変更など) 　　・廃止された標準仕様や危険のある仕様などの排除 (例えば、古いバージョンの TLS など) など、利便性の向上か必要に迫られてのものが多い……はずです。 もちろんバージョンアップにより変更が加えられている以上、例えば「安全性の強化により動作がブロックされるようになってしまった」「コード改善により偶然影響を受けてしまった」「廃止された標準仕様を使っていた」……などなど、 バージョンアップ後に想定通りの動作をしてくれなくなってしまうケースが発生する可能性は否定できません 。 このため、バージョンアップの際にはきちんと検証を行なって動作に問題ないかを確認し、問題があれば対応を行なってからバージョンアップを実施するようにしましょう。 (システムの安全・効率的な運用のためには、バージョンアップは必ず必要になってくるものです。対応の手間を嫌わず、きちんと実施するようにしましょう。) ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RHEL10 移行に際する squid の変更点のお話 first appeared on SIOS Tech. Lab .

はじめに 前回の記事 では、GitLabのコンテナレジストリについて2回にわたり解説しました。リポジトリに加えてレジストリを利用することで、ソースコードとコンテナイメージを一元管理できる点を確認しました。 今回からは、いよいよGitLabのCI/CD機能に焦点を当てます。CI/CDは、開発からデプロイまでの流れを自動化するための基本となる仕組みです。特にGitLabでは、リポジトリ・レジストリ・Runnerを組み合わせることで、シンプルながら強力なパイプラインを構築できます。 本記事では基本編として、ビルド、push、デプロイといったCI/CDにおける基本的な操作をジョブ単位で検証します。まずはシンプルなジョブを一つずつ動かし、パイプラインの仕組みに慣れることを目的とします。次回はこの内容を発展させ、複数のステージを組み合わせたマルチステージパイプラインを解説します。 ゴール GitLab Runnerを利用して簡単なCI/CDパイプラインを実行できるようにする ビルド→push→デプロイの一連の流れを体験する パイプラインの仕組みを理解する 前提条件 本記事では、あらかじめ以下の環境が構築されていることを前提とします。環境の詳細な構築手順については、 環境構築編の記事 をご参照ください。 GitLab（Self-Managed版） Omnibusパッケージを利用してLinuxサーバーにインストールしたGitLabを利用します 無償版であるCommunity Editionを利用します Gitlab Runner OpenShiftクラスター上にデプロイ済みのRunnerを利用して、ジョブを実行します OpenShiftクラスター 閉域環境（インターネット非接続環境）に構築されています GitLab Container Registry コンテナイメージのpush / pullに利用します これらの環境を利用して、GitLab CI/CDパイプラインを実行し、ビルドからデプロイまでの流れを検証できます。また、本記事では以下のようにテスト用のプロジェクトとブランチを用意して検証します。 テスト用プロジェクトの作成 任意の名称の動作確認用プロジェクトを新規作成します。例：test-project このプロジェクト配下で以降のジョブ検証を行います。 ブランチ構成 本記事では、各ジョブを個別のブランチで検証します。 基本の流れはbuild→push→deployですが、deployについては2つの方法（マニフェスト、Helm）をそれぞれ検証する構成にしています。実際の運用ではHelmを利用するケースが多いですが、まずはマニフェスト適用から試すとより理解が深まります。 single-job-build 目的：Dockerイメージのビルド 主要ファイル：.gitlab-ci.yml、Dockerfile single-job-push 目的：既存イメージのタグ名リネーム&レジストリへのpush 主要ファイル：.gitlab-ci.yml single-job-deploy-manifest 目的：oc applyでマニフェストを適用 主要ファイル：.gitlab-ci.yml、deploy.yaml ※deployの検証パターン1 single-job-deploy-helm 目的：Helmチャートを利用したデプロイ 主要ファイル：.gitlab-ci.yml、templates/ディレクトリ、values.yaml、Chart.yaml ※deployの検証パターン2 各ブランチのファイル配置 single-job-build test-project/ ├─ .gitlab-ci.yml ├─ Dockerfile └─ README.md single-job-push test-project/ ├─ .gitlab-ci.yml └─ README.md single-job-deploy-manifest test-project/ ├─ .gitlab-ci.yml ├─ deploy.yaml └─ README.md single-job-deploy-helm test-project/ ├── Chart.yaml ├── templates │   └── deployment.yaml ├── values.yaml └─ README.md 用語説明 本記事で紹介するパイプラインを理解するために、CI/CDに関連する基本用語を簡単におさらいしておきます。 Pipeline（パイプライン） GitLab CI/CDにおける一連の自動化処理の流れを指します。コードのビルド、テスト、デプロイといった複数の処理を順番にまとめたものです。 Stage（ステージ） パイプラインを構成する処理のグループです。たとえば、「build」「test」「deploy」といった大まかな段階をステージとして定義します。ステージは順番に実行されます。 Job（ジョブ） 各ステージの中で実行される具体的な処理の単位です。ビルドのジョブ、デプロイのジョブといった形で定義されます。ジョブは.gitlab-ci.ymlに記述します。 Runner（ランナー） ジョブを実際に実行する役割を担うコンポーネントです。GitLab本体とは別に用意され、指定した環境（Docker、Kubernetes、VMなど）でジョブを動かします。本記事ではOpenShift上にデプロイしたRunnerを利用します。 これらの用語を理解しておくことで、以降のサンプルコードや解説がスムーズに読み進められます。 サンプルコード全体像 今回の検証では、以下の基本的な処理をそれぞれ独立したジョブとして実行し、CI/CDの流れを確認します。 Build：Dockerイメージのビルド Push：GitLab Container Registryへのイメージpush Deploy（マニフェスト）：Kubernetesマニフェストを適用してデプロイ Deploy（Helm）：Helmチャートを利用してデプロイ まずは全体像をイメージしやすいよう、シンプルな.gitlab-ci.ymlの例を示します。 stages:   - build   - push   - deploy build_job:   stage: build   script:     - echo "Build Docker image" push_job:   stage: push   script:     - echo "Push image to GitLab Registry" deploy_job:   stage: deploy   script:     - echo "Deploy application" 上記は最小限の例であり、実際には各ジョブに詳細な処理（docker build / push、kubectl apply、helm installなど）を記述します。以降のセクションでは、各ジョブを個別に取り上げ、実際のコード例とともに動作を確認していきます。 ジョブ別解説 ここからは、実際に.gitlab-ci.yml にジョブを定義し、CI/CDの流れを確認していきます。 基本の流れはBuild → Push → Deployです。まずはビルドとpushを行い、その後のデプロイ方法として「マニフェスト適用」と「Helm」の2種類を検証します。 Buildジョブ 最初に実行するのはBuildジョブです。ソースコードからDockerイメージを作成し、次のステップで利用できる状態にします。 以下の例では、docker buildを実行してnginxのイメージを作成し、GitLabのレジストリに登録できるようにリポジトリ名をtestに変更したタグ（test:v1.0）を付与しています。 なお、本記事の環境ではOpenShiftクラスターはインターネットと接続できない閉域環境に配置しているため、ベースイメージとなるnginxのイメージはあらかじめGitLabのプロジェクト内のレジストリに格納してあります。 最小のnginxベースのサンプルです。 Dockerfile FROM registry.gitlab.local.example.com/root/test-project/nginx:v1.0 ここでは Docker-in-Docker（dind）でビルドする例を示します。GitLab既定のレジストリ変数（CI_REGISTRY / CI_REGISTRY_IMAGE / CI_REGISTRY_USER / CI_REGISTRY_PASSWORD）を利用します。 このジョブを実行することで、アプリケーションのDockerイメージが生成されます。 .gitlab-ci.yml stages:   - build build_job:   stage: build   tags:     - devsecops-runner   image: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3   services:     - name: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3-dind       alias: docker       entrypoint: ["/bin/sh","-lc"]       command:         - >           cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt &&           update-ca-certificates &&           exec dockerd-entrypoint.sh           --tls=false           --host=unix:///var/run/docker.sock           --host=tcp://0.0.0.0:2375   variables:     DOCKER_HOST: tcp://docker:2375     DOCKER_TLS_CERTDIR: ""   before_script:     - cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt     - update-ca-certificates || true   script:     - |       echo "Login to $CI_REGISTRY"       docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD"       docker build . --tag="${CI_REGISTRY_IMAGE}/test:v1.0" 上記のサンプルコードをGitLabのプロジェクトにpushすると、pushをトリガーとしてパイプラインが起動します。 プロジェクト画面のサイドメニューから[ビルド] > [パイプライン]を選択して移動し、パイプラインの実行結果を確認します。 パイプラインの実行に成功したことを確認できました。 ジョブのログを見ると、.gitlab-ci.yml内で指定した通り、イメージタグのリネームが行われています。 Pushジョブ 次に実行するのはPushジョブです。このジョブでは、あらかじめ検証用プロジェクトのレジストリにpushしておいた既存のnginx:v1.0イメージのリポジトリ名をtest:v1.0に付け替えて、GitLab Container Registryへpushします。 stages:   - push push_only:   stage: push   tags: [devsecops-runner]   image: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3   services:     - name: registry.gitlab.local.example.com/root/registry-project/docker:28.3.3-dind       alias: docker       entrypoint: ["/bin/sh","-lc"]       command:         - >           cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt &&           update-ca-certificates &&           exec dockerd-entrypoint.sh           --tls=false           --host=unix:///var/run/docker.sock           --host=tcp://0.0.0.0:2375   variables:     DOCKER_HOST: tcp://docker:2375     DOCKER_TLS_CERTDIR: ""     SOURCE_IMAGE: registry.gitlab.local.example.com/root/test-project/nginx:v1.0   before_script:     - cp /etc/gitlab-runner/certs/gitlab.local.example.com.crt /usr/local/share/ca-certificates/ca.crt     - update-ca-certificates || true   script: |     echo "Login to $CI_REGISTRY"     docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD"     echo "Pull source image and push re-tagged"     docker pull "$SOURCE_IMAGE"     docker tag "$SOURCE_IMAGE" "${CI_REGISTRY_IMAGE}/test:v1.0"     docker push "${CI_REGISTRY_IMAGE}/test:v1.0" このジョブでレジストリにpushしたイメージは、後続のデプロイジョブで利用できるようになります。 上記のサンプルコードをGitLabのプロジェクトにpushすると、pushをトリガーとしてパイプラインが起動します。 プロジェクト画面のサイドメニューから[ビルド] > [パイプライン]を選択して移動し、パイプラインの実行結果を確認します。 パイプラインは正常に実行されていることを確認できました。 プロジェクト画面のサイドメニューから[デプロイ] > [コンテナレジストリ]を選択して移動し、レジストリにpushしたイメージが格納されていることを確認します。 ジョブ内で指定した通り、test:v1.0というタグのイメージが保存されていることを確認できました。 Deployジョブ（マニフェスト） ここからはデプロイの検証です。まずはKubernetesのマニフェストを直接oc applyで適用する方法を試します。 ※本記事の環境ではコンテナ基盤としてOpenShiftを利用しているため、クラスター操作のCLIツールとしてocを利用しています。Kubernetes環境を利用している場合は、imageでkubectlを利用可能なイメージを指定し、scriptのデプロイコマンドはkubectl applyを使用してください。 まずはocコマンドを実行できるコンテナイメージをローカルでビルドして、GitLabのレジストリにpushします。 $ podman login registry.redhat.io $ podman pull registry.redhat.io/openshift4/ose-cli-rhel9:v4.18 $ podman login registry.gitlab.local.example.com $ podman tag registry.redhat.io/openshift4/ose-cli-rhel9:v4.18 \   registry.gitlab.local.example.com/root/test-project/oc:4.18 $ podman push registry.gitlab.local.example.com/root/test-project/oc:4.18 デプロイテスト用のマニフェストファイルです。このファイルを作成したデプロイテスト用のブランチにpushしておきます。 deploy.yaml apiVersion: apps/v1 kind: Deployment metadata:   name: myapp   namespace: gitlab-runner-test spec:   replicas: 1   selector:     matchLabels:       app: myapp   template:     metadata:       labels:         app: myapp     spec:       serviceAccountName: gitlab-runner-sa       containers:         - name: nginx           image: registry.gitlab.local.example.com/root/test-project/test:v1.0           imagePullPolicy: IfNotPresent .gitlab-ci.yml stages:   - deploy deploy_manifest:   stage: deploy   tags: [devsecops-runner]   image: registry.gitlab.local.example.com/root/test-project/oc:4.18   before_script:     - oc whoami   script: |     set -euo pipefail     oc apply -f deploy.yaml このジョブを実行すると、deploy.yamlに記載されたリソースがOpenShiftクラスター上に作成されます。 上記のサンプルコードをGitLabのプロジェクトにpushすると、pushをトリガーとしてパイプラインが起動します。 プロジェクト画面のサイドメニューから[ビルド] > [パイプライン]を選択して移動し、パイプラインの実行結果を確認します。 ジョブの実行が成功していることを確認できました。 続いて、クラスターにPodがデプロイされていることを確認します。 deploy.yamlで指定した通り、myappという名前のPodが起動していることを確認できました。 $ oc get pod -n gitlab-runner-test -l app=myapp NAME                    READY   STATUS    RESTARTS   AGE myapp-7d45468b7-24mwn   1/1     Running   0          69m Deployジョブ（Helm） 最後にHelmを使ったデプロイ方法です。Helmを利用することで、複数のマニフェストをまとめて管理することができ、環境ごとの設定差分を柔軟に扱うことができます。 今回の検証では、以下のテスト用のHelmチャートを利用します。 先ほどと同様に、プロジェクト上にHelmテスト用のブランチを作成してHelmチャートを作成したブランチにテスト用のチャートをpushしておきます。 Podが参照するイメージは、Pushジョブでpushしたイメージを利用します。 Chart.yaml apiVersion: v2 name: single-job-deploy-helm-chart description: A Helm chart for a single deployment job type: application version: 0.1.0 appVersion: "1.0" templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:   name: single-job-helm-deploy   labels:     app: helm-test-app spec:   replicas: {{ .Values.replicaCount }}   selector:     matchLabels:       app: helm-test-app   template:     metadata:       labels:         app: helm-test-app     spec:       {{- with .Values.imagePullSecrets }}       imagePullSecrets:         {{- toYaml . | nindent 8 }}       {{- end}}       containers:         - name: nginx           image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"           imagePullPolicy: {{ .Values.image.pullPolicy }} values.yaml replicaCount: 1 image:   repository: "registry.gitlab.local.example.com/root/test-project/test"   pullPolicy: IfNotPresent   tag: "v1.0" imagePullSecrets:   - name: gitlab-registry-secret Helmチャートをデプロイできるようにするため、Helm CLIが利用できるジョブPod用のイメージをプロジェクト内のレジストリに格納します。 $ podman pull docker.io/alpine/helm:3 $ podman tag docker.io/alpine/helm:3 \   registry.gitlab.local.example.com/root/test-project/helm:3 $ podman push registry.gitlab.local.example.com/root/test-project/helm:3 .gitlab-ci.yml stages: [deploy] deploy_helm:   stage: deploy   tags: [devsecops-runner]   image: registry.gitlab.local.example.com/root/test-project/helm:3   variables:     RELEASE_NAME: mynginx     NAMESPACE: gitlab-runner-test   before_script:     - |       if [ -n "${KUBECONFIG_DATA:-}" ]; then         mkdir -p ~/.kube         echo "$KUBECONFIG_DATA" | base64 -d > ~/.kube/config         export KUBECONFIG="$HOME/.kube/config"       fi     - helm version   script: |     set -euo pipefail     helm upgrade --install "$RELEASE_NAME" ./chart \       --namespace "$NAMESPACE" \       -f ./values.yaml \       --wait --timeout 180s     helm -n "$NAMESPACE" status "$RELEASE_NAME" Helmを利用したデプロイでは、再実行時もupgrade –installにより差分更新されるため、継続的デプロイ（CD）の仕組みとして有効です。 上記のサンプルコードをGitLabのプロジェクトにpushすると、pushをトリガーとしてパイプラインが起動します。 プロジェクト画面のサイドメニューから[ビルド] > [パイプライン]を選択して移動し、パイプラインの実行結果を確認します。 ジョブの実行に成功していることを確認できました。 続いて、クラスターにPodがデプロイされていることを確認します。 templates/deployment.yamlで指定した通り、helm-test-appという名前のPodが起動していることを確認できました。 $ oc get pod -n gitlab-runner-test -l app=helm-test-app NAME                                      READY   STATUS    RESTARTS   AGE single-job-helm-deploy-6bdbc56bbf-58nv8   1/1     Running   0          68m まとめ 本記事では、GitLab CI/CDの基本的な使い方を確認するために、ビルド→push→デプロイという一連の流れをジョブ単位で検証しました。 BuildジョブでDockerイメージを作成 PushジョブでGitLabコンテナレジストリへ登録 DeployジョブでOpenShiftクラスターにデプロイ（マニフェスト / Helm） ジョブを分けて検証することで、CI/CDの各ステップを個別に把握でき、トラブル発生時の切り分けや理解の定着に役立ちます。これは、後に複数のステージを組み合わせたパイプラインを設計する際の基盤となります。 次回は、今回学んだ各ジョブを組み合わせてマルチステージパイプラインを構築したり、パイプラインの実行管理をする方法について解説します。これにより、より実践的なCI/CDパイプラインを設計できるようになります。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitLab CI/CD 実践［基本編］：パイプライン作成の基本 first appeared on SIOS Tech. Lab .

はじめに 前回 は、GitLabの画面と主要な機能について解説しました。今回は、GitLabの最も基本的な単位であるプロジェクトに焦点を当てます。GitLabのプロジェクトが提供するユニークな価値と、それを最大限に活用する方法を解説します。 グループとプロジェクトの関係 GitLabのプロジェクトを最大限に活用するには、まずグループの概念を理解することが重要です。グループは、複数のプロジェクトをひとまとめにして管理するためのコンテナです。例えば、「Web開発チーム」というグループを作り、その中に「フロントエンド」「バックエンド」「API」といった複数のプロジェクトを配置することができます。 この階層構造には、次のような大きなメリットがあります。 グループに設定したメンバーのアクセスレベルは、そのグループ内のすべてのプロジェクトに自動的に適用されます。これにより、プロジェクトごとに個別の権限設定を行う手間が省けます。 グループ単位でイシューボードやCI/CD変数、セキュリティポリシーなどを設定できます。複数のプロジェクトにまたがるタスクや、共通の設定を効率的に管理できます。 プロジェクトの機能 GitLabにおけるプロジェクトの役割は開発の最初から最後まで、チームの作業全体を統合管理する場所になります。GitLabのプロジェクトは、以下のすべてを一つの場所に集約しています。 リポジトリ：プロジェクトのすべてのコードを保管する場所です。チームメンバーは、ブランチを切ってコードを編集し、変更履歴をコミットすることで、コードベースの変更を管理します。 マージリクエスト：ブランチの変更を、mainなどの共有ブランチに統合するための機能です。コード統合だけでなく、チームメンバーによるコードレビューや議論、そしてCI/CDパイプラインの実行結果を確認する場所としても機能します。 イシュー管理：タスク、バグ、新機能などの作業を追跡・管理する場所です。イシューに担当者を割り当てたり、進捗状況をボードで可視化したりすることで、プロジェクトの作業を一元的に把握し、効率的な開発をサポートします。 CI/CD：CI/CD（継続的インテグレーション・継続的デリバリー）は、コードのテスト、ビルド、デプロイを自動化する仕組みです。gitlab-ci.ymlという設定ファイルに記述されたパイプラインが自動で実行され、開発プロセスを効率化します。 Wiki：プロジェクトのドキュメントやナレッジを保管する場所です。Gitリポジトリとは別に管理されるため、API仕様書や環境構築手順など、チームで共有すべき情報を整理し、常に最新の状態を保つのに役立ちます。 セキュリティ：コードの脆弱性や機密情報を自動で検知する仕組みです。CI/CDパイプラインに組み込まれたスキャンが、開発の初期段階から潜在的なセキュリティリスクを発見し、安全なコードベースを維持するのに貢献します。 これは、単一のプラットフォームで開発ライフサイクル全体を管理するというGitLabの哲学を体現しています。プロジェクトを作成するだけでコード管理からテスト・デプロイまでを効率的に進めることができます。   プロジェクトを最大限に活用する実践的な方法 GitLabのプロジェクトは、ただコードを置くだけでなく、以下の機能を活用することで、その真価を発揮できます。 ユーザー招待 プロジェクトの「メンバー」から、チームメンバーを招待し、それぞれの役割を設定します。これにより、適切な権限で共同作業を始めることができます。ユーザー招待時には 期限付きのアクセス権 を設定することも可能です。外部ベンダーや短期間だけ関わるメンバーに対して有効で、不要になったあと自動的に権限を失効させることでセキュリティリスクを低減できます。 グループ単位での招待を活用すれば、同じチームメンバーを複数プロジェクトにまとめて参加させることもできます。これにより、効率的かつ統一的にメンバー管理が行えます。 権限設定 GitLabでは、ユーザーに付与する権限（ロール）によってプロジェクトやグループ内での操作範囲を細かくコントロールできます。これにより「誰が何をできるか」を明確にし、誤操作やセキュリティリスクを防ぐことができます。 以下はよく使われる代表的な権限例の一例です。 プロジェクトレベルの権限 各プロジェクトごとに付与される権限で、主に日々の開発作業に関わる役割を定義します。 Owner：プロジェクトの最上位権限を持ち、全ての操作が可能です。プロジェクトの削除や移動も含まれ、最大の権限を持ちます。基本的にはプロジェクトやグループの責任者やシステム管理者に付与されます。 Maintainer：主にプロジェクト管理者として設定変更、保護ブランチ管理、メンバー招待・管理などが可能です。Ownerほどの権限はなく、プロジェクトの設定を統括します。プロジェクトの削除や移動などはできません。 Developer：日常的な開発者権限で、ブランチ作成やコードのプッシュ、マージリクエストの作成・承認などができますが、プロジェクトの設定変更やメンバー管理はできません。 グループレベルの権限 複数のプロジェクトを束ねるグループ単位でも権限を設定できます。グループに属する全プロジェクトに影響するため、組織全体での権限設計に有効です。例えば、あるユーザーをグループでDeveloperとして登録すれば、そのグループ配下のすべてのプロジェクトで開発者権限を持つことになります。逆に、個別のプロジェクト単位で追加の権限を付与することも可能です。 このように、グループとプロジェクト双方の権限設定を適切に使い分けることで、 日常の開発作業はプロジェクト権限で細かくコントロールしつつ、グループ権限で全体の統制を効かせるといった柔軟な運用が可能になります。 公式ドキュメント： https://docs.gitlab.com/user/permissions/ 保護ブランチ main ブランチなど、特定の重要なブランチに対して直接の変更を制限する機能です。通常、開発者は自分のブランチで作業し、レビューを経てからmainブランチに統合します。しかし、誤って直接mainにプッシュしてしまうと、予期せぬバグが本番環境にデプロイされ、システム全体が停止するような大事故につながる可能性があります。 保護ブランチ機能は、誤ってコードがブランチにプッシュされることを防ぎ、開発の安定性を確保できます。 設定 ＞リポジトリ から設定できます。 wiki コードとは別に、プロジェクト固有のドキュメントを管理できる仕組みです。API仕様書、開発環境のセットアップ手順、リリースノートなど、チームで繰り返し参照する情報を整理するのに最適です。ドキュメントがプロジェクトと一緒に管理されるため、常に最新の情報を共有できます。   開発を始めるまでの準備 開発を始めるとき、まずは以下の準備を行いましょう。 GitLabにログイン済みであることを前提とします。 グループの作成 複数のプロジェクトを管理する予定がある場合は、まずグループを作成します。グループの作成は、GitLabのグループ画面から「新しいグループ」をクリックします。 「グループを作成」をクリックします。 グループ名、表示レベルを設定して「グループの作成」をクリックします。 これでグループの作成は完了です。 グループメンバーの招待 グループの管理＞メンバーから、チームメンバーを招待し、適切な権限を付与します。 「メンバーを招待」をクリックします。 今回はメンテナーと開発者を追加したいと思います。 ユーザーとロール、アクセスの有効期限を設定して、「招待」をクリックします。 プロジェクトの作成 作成したグループ内で、新しいプロジェクトを作成します。グループのホーム画面から「新しいプロジェクト」をクリックします。 「空のプロジェクトの作成」をクリックします。 プロジェクト名、表示レベルなどを設定して、「プロジェクトを作成」をクリックします。 今回は、デフォルト設定のままプロジェクトを作成することを前提とします。 表示レベルは、誰がプロジェクトにアクセスできるかを定義します。 非公開 (Private)：プロジェクトメンバーだけがアクセスできます。 GitLabで最も推奨される設定です。コードやイシュー、CI/CDパイプラインなど、すべての情報がチーム内のみで共有されます。 内部 (Internal)：ログインしているすべてのユーザーがアクセスできます。 GitLabインスタンスの全ユーザー（例：社内の全従業員）がプロジェクトを閲覧できます。社内向けの共通ライブラリやドキュメントを共有するのに便利です。 公開 (Public)：ログインしていないユーザーも含め、誰でもアクセスできます。 オープンソースプロジェクトなど、広く一般に公開したい場合に選択します。機密情報や社内情報を含むプロジェクトでは使用しないでください。 通常、機密情報が含まれるプロジェクトでは非公開を、ログイン済みユーザーなら誰でも参照可能なプロジェクトでは内部を選択することを強く推奨します。 プロジェクトの設定には、リポジトリの初期状態を決める追加オプションがあります。 デフォルトでは、「READMEを作成する」にのみチェックが入っています。これは、プロジェクト作成と同時に、簡単な説明が記載されたREADME.mdファイルが自動で作成される設定です。 プロジェクトの画面が表示されたら作成完了です。 ブランチ保護の設定 プロジェクトの初期設定をしていきます。まずはブランチ保護の設定です。 ブランチ戦略にもよりますが、ここではmainブランチへの直接のプッシュを制限し、マージの権限設定をします。 設定＞リポジトリ から、保護ブランチを開きます。 mainブランチに対してのマージを許可するロールとプッシュを許可するロールを選択します。強制プッシュを許可するかも選択します。 developブランチなどにも保護ブランチ設定をしたい場合は、「保護ブランチを追加する」をクリックします。 Wikiの作成 続いて、Wikiを作成しておきます。こちらは必須ではないですが、プロジェクトの概要やルールなどをWikiに記載し、チームで共有することで円滑な開発が可能になります。環境構築の手順、API仕様書などがあればWikiに追加しておきましょう。 計画＞Wikiから、「最初のページを作成」をクリックします。 タイトルや内容を記述し、「ページを作成」をクリックします。 ページが表示されたら完了です。 これでプロジェクトの準備は完了です。 あとは、リモートプロジェクトをローカル環境に取得したら、ローカルでの開発作業を開始できます。リモートプロジェクトのクローンは第4回のブログを参考にしてみてください。 まとめ 今回の記事では、GitLabのプロジェクトについて深く掘り下げました。GitLabのプロジェクトは、コード、イシュー、CI/CD、Wiki、セキュリティといったすべてを統合していました。 さらに、グループを活用することで、複数のプロジェクトを効率的に管理し、メンバーの権限設定を簡素化できることを解説しました。そして、実際にプロジェクトの作成から、保護ブランチやWikiの設定といった初期準備までを実践しました。 次回は、GitLabのCI/CDに焦点を当てます。今回設定したプロジェクト上で、コードのビルド、テスト、デプロイといった一連のプロセスを自動化する方法を、簡単に解説します。 参考文献 https://docs.gitlab.com/user/group/ https://docs.gitlab.com/user/project/members/sharing_projects_groups/ https://docs.gitlab.com/user/permissions/ https://docs.gitlab.com/user/project/ https://docs.gitlab.com/user/project/working_with_projects/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (7) ～Git マスターへの道～「GitLabのプロジェクトについて」 first appeared on SIOS Tech. Lab .

はじめに 「 構築編 」では、非接続環境のOpenShiftクラスターにOPA/Gatekeeperを導入する基本的な手順を解説しました。しかし、Gatekeeperは、適切なポリシーを定義して適用することで初めて動作します。 この記事では、実際にポリシーの作成と適用を行い、OpenShiftの運用ルールを自動化する方法を解説します。具体的には、リソースの妥当性を検証するバリデーションと、リソースを自動的に変更するミューテーションという、Gatekeeperの二つの主要な動作について深く掘り下げていきます。 前提条件 バージョン：Gatekeeper v3.20.0 Gatekeeperが非接続環境のOpenShiftクラスターに導入済みであること 参考： OPA/Gatekeeperで始める安心OpenShift運用：構築編 ポリシーの適用範囲 Gatekeeperのポリシーは、ConstraintTemplateとConstraintsという2つのカスタムリソース（CRD）で構成されます。 ConstraintTemplate：ポリシーのひな形を定義します。どのようなリソースに、どのような条件でポリシーを適用するかを定義します。これはクラスター全体に適用されるクラスタースコープのリソースです。 Constraints: ConstraintTemplateで定義されたひな形を使い、実際の適用ルールを定義します。例えば、「k8srequiredlabels」というテンプレートを使って、「すべてのPodにappラベルを必須とする」という具体的なルールを作成します。デフォルトではクラスター内のすべてのリソースにポリシーを適用しますが、特定のNamespaceにのみ適用することも可能です。 ポリシーの適用動作 GatekeeperのConstraintリソースでは、enforcementActionというフィールドを使用して、ポリシーに違反したリソースに対してどのようなアクションを実行するかを制御できます。これにより、単にデプロイを拒否するだけでなく、より柔軟な運用が可能になります。 enforcementActionでは、3つのアクションを選択できます。 deny (デフォルト)：ポリシーに違反したリソースの作成や更新を拒否し、デプロイを停止します。 dryrun：ポリシー違反を記録するだけで、リソースのデプロイはそのまま許可します。 warn：ポリシー違反をログに警告として出力しますが、デプロイはブロックしません。 これらのアクションを使い分けることで、ポリシーをより柔軟に運用できます。 dryrunはポリシーのテストで有効です。新しいポリシーを適用する前にdryrunモードで試すことで、既存のリソースや今後のデプロイでどのような違反が発生するかを事前に把握できます。これにより、環境に予期せぬ影響を与えることなく、段階的にポリシーを導入することが可能になります。 warnは段階的なルール適用に役立ちます。例えば、「latestタグの使用は非推奨です」といった警告を出しつつ、Podのデプロイ自体は許可するといった運用が可能です。このようにして、運用を徐々に改善していくことができます。 バリデーションポリシー リソースがポリシーに適合しているか検証し、違反していればリクエストを拒否します。 これは、ポリシーに違反するリソースがクラスターにデプロイされるのを未然に防ぐ動作です。 有効なシーン 特権コンテナやホストのネットワークへのアクセスを許可するPodのデプロイを拒否し、セキュリティリスクを排除します。 すべてのリソースに特定のラベルやアノテーションを必須とすることで、監査や管理を容易にします。 ここでは、よく使われるバリデーションの具体例として、必須ラベルの強制とルートファイルシステムの書き込み禁止を紹介します。 必須ラベルの強制 以下のポリシーは、stagingネームスペースのPodにenvのラベルを必須とします。 ConstraintTemplateの作成 apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata:   name: k8srequiredlabels spec:   crd:     spec:       names:         kind: K8sRequiredLabels       validation:         openAPIV3Schema:           type: object           properties:             labels:               type: array               items:                 type: string   targets:     - target: admission.k8s.gatekeeper.sh       rego: |         package k8srequiredlabels         violation[{"msg": msg, "details": {"missing_labels": missing}}] {           provided := {label | input.review.object.metadata.labels[label]}           required := {label | label := input.parameters.labels[_]}           missing := required - provided           count(missing) > 0           msg := sprintf("you must provide labels: %v", [missing])         } Constraintsの作成 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata:   name: must-have-required-labels spec:   match:     namespaces: ["staging"]     kinds:       - apiGroups: [""]         kinds: ["Pod"]   parameters:     labels: [“env”] ポリシーをゼロから書くのは大変な作業ですが、Gatekeeperには公式に提供されている便利なポリシーライブラリがあります。 公式ウェブサイト: https://open-policy-agent.github.io/gatekeeper-library/website/ このライブラリを活用することで、目的に合ったポリシーが存在する場合はポリシーの作成にかかる時間を大幅に短縮でき、より早く安全なOpenShift運用を始めることができます。 作成したConstraintTemplateとConstraintsのマニフェストファイルを適用します。 $ oc project gatekeeper-system $ oc apply -f ConstraintTemplate_k8srequiredlabels.yaml $ oc apply -f Constraints_k8srequiredlabels.yaml 作成したポリシーを確認します。 $ oc get constrainttemplate NAME                         AGE k8srequiredlabels            65s ポリシー違反が見つかった場合は、TOTAL-VIOLATIONSのカウントが増えていきます。 $ oc get constraints NAME                        ENFORCEMENT-ACTION   TOTAL-VIOLATIONS must-have-required-labels   deny                 0 検証用のネームスペースを作成します。 $ oc create namespace staging 以下の指定したラベルを持たないDeploymentのバリデーションを確認してみます。 apiVersion: apps/v1 kind: Deployment metadata:   name: gatekeeper-test   namespace: staging spec:   replicas: 1   selector:     matchLabels:       name: gatekeeper-test   template:     metadata:       name: gatekeeper-test       labels:         name: gatekeeper-test     spec:       nodeSelector:         "kubernetes.io/os": linux       containers:         - name: ubi-container           image: registry.redhat.io/ubi8/ubi:latest           command:             - "/bin/sh"             - "-c"             - "echo 'Pod is running with UBI...' && sleep infinity" $ oc apply -f Deployment_k8srequiredlabels.yaml ポリシーの適用スコープはPodのみなので、Deploymentオブジェクト自体は作成されるが、その下位のPodがAdmissionWebhookに拒否されるため、Podは起動できません。 Podがデプロイされているか確認してみます。 $ oc get all -n staging Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+ NAME                              READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gatekeeper-test   0/1     0            0           7m5s NAME                                         DESIRED   CURRENT   READY   AGE replicaset.apps/gatekeeper-test-766b7bdb6b   1         0         0       7m5s デプロイされていなかったので、replicasetのdescribeを確認してみます。 $ oc describe replicaset gatekeeper-test-766b7bdb6b -n staging … Events:   Type     Reason        Age                   From                   Message   ----     ------        ----                  ----                   -------   Warning  FailedCreate  5m34s (x18 over 11m)  replicaset-controller  Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [must-have-required-labels] you must provide labels: {"env"} デプロイが許可されなかったことがわかります。 次に、指定したラベルを付与してデプロイしてみます。 apiVersion: apps/v1 kind: Deployment metadata:   name: gatekeeper-test   namespace: staging spec:   replicas: 1   selector:     matchLabels:       name: gatekeeper-test   template:     metadata:       name: gatekeeper-test       labels:         name: gatekeeper-test         env: staging     spec:       nodeSelector:         "kubernetes.io/os": linux       containers:         - name: ubi-container           image: registry.redhat.io/ubi8/ubi:latest           command:             - "/bin/sh"             - "-c"             - "echo 'Pod is running with UBI...' && sleep infinity" $ oc apply -f Deployment_k8srequiredlabels.yaml Podがデプロイされているか確認してみます。 $ oc get all -n staging Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+ NAME                                   READY   STATUS    RESTARTS   AGE pod/gatekeeper-test-6b5f4f8d74-5cngp   1/1     Running   0          3s NAME                              READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gatekeeper-test   0/1     0            0           7m5s NAME                                         DESIRED   CURRENT   READY   AGE replicaset.apps/gatekeeper-test-6b5f4f8d74   1         1         1       3s replicaset.apps/gatekeeper-test-766b7bdb6b   1         0         0       7m5s これでデプロイが成功しました！ 次の検証のためにConstraints、Deploymentは削除しておきます。 $ oc delete -f Deployment_k8srequiredlabels.yaml $ oc apply -f Constraints_k8srequiredlabels.yaml ルートファイルシステムの書き込み禁止 セキュリティ上の理由から、PodのsecurityContext.readOnlyRootFilesystem を true に設定することを強制します。 ConstraintTemplateの作成 apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata:   name: k8spspreadonlyrootfilesystem   annotations:     metadata.gatekeeper.sh/title: "Read Only Root Filesystem"     metadata.gatekeeper.sh/version: 1.1.1     description: >-       Requires the use of a read-only root file system by pod containers.       Corresponds to the `readOnlyRootFilesystem` field in a       PodSecurityPolicy. For more information, see       https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems spec:   crd:     spec:       names:         kind: K8sPSPReadOnlyRootFilesystem       validation:         # Schema for the `parameters` field         openAPIV3Schema:           type: object           description: >-             Requires the use of a read-only root file system by pod containers.             Corresponds to the `readOnlyRootFilesystem` field in a             PodSecurityPolicy. For more information, see             https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems           properties:             exemptImages:               description: >-                 Any container that uses an image that matches an entry in this list will be excluded                 from enforcement. Prefix-matching can be signified with `*`. For example: `my-image-*`.                It is recommended that users use the fully-qualified Docker image name (e.g. start with a domain name)                 in order to avoid unexpectedly exempting images from an untrusted repository.               type: array               items:                 type: string   targets:     - target: admission.k8s.gatekeeper.sh       code:       - engine: K8sNativeValidation         source:           variables:           - name: containers             expression: 'has(variables.anyObject.spec.containers) ? variables.anyObject.spec.containers : []'           - name: initContainers             expression: 'has(variables.anyObject.spec.initContainers) ? variables.anyObject.spec.initContainers : []'           - name: ephemeralContainers             expression: 'has(variables.anyObject.spec.ephemeralContainers) ? variables.anyObject.spec.ephemeralContainers : []'           - name: exemptImagePrefixes             expression: |               !has(variables.params.exemptImages) ? [] :                 variables.params.exemptImages.filter(image, image.endsWith("*")).map(image, string(image).replace("*", ""))           - name: exemptImageExplicit             expression: |               !has(variables.params.exemptImages) ? [] :                  variables.params.exemptImages.filter(image, !image.endsWith("*"))           - name: exemptImages             expression: |               (variables.containers + variables.initContainers + variables.ephemeralContainers).filter(container,                 container.image in variables.exemptImageExplicit ||                 variables.exemptImagePrefixes.exists(exemption, string(container.image).startsWith(exemption))).map(container, container.image)           - name: badContainers             expression: |               (variables.containers + variables.initContainers + variables.ephemeralContainers).filter(container,                 !(container.image in variables.exemptImages) &&                  (!has(container.securityContext) ||                 !has(container.securityContext.readOnlyRootFilesystem) ||                 container.securityContext.readOnlyRootFilesystem != true)               ).map(container, container.name)           validations:           - expression: '(has(request.operation) && request.operation == "UPDATE") || size(variables.badContainers) == 0'             messageExpression: '"only read-only root filesystem container is allowed: " + variables.badContainers.join(", ")'                   - engine: Rego         source:           rego: |             package k8spspreadonlyrootfilesystem             import data.lib.exclude_update.is_update             import data.lib.exempt_container.is_exempt             violation[{"msg": msg, "details": {}}] {                 # spec.containers.readOnlyRootFilesystem field is immutable.                 not is_update(input.review)                 c := input_containers[_]                 not is_exempt(c)                 input_read_only_root_fs(c)                 msg := sprintf("only read-only root filesystem container is allowed: %v", )             }             input_read_only_root_fs(c) {                 not has_field(c, "securityContext")             }             input_read_only_root_fs(c) {                 not c.securityContext.readOnlyRootFilesystem == true             }             input_containers {                 c := input.review.object.spec.containers[_]             }             input_containers {                 c := input.review.object.spec.initContainers[_]             }             input_containers {                 c := input.review.object.spec.ephemeralContainers[_]             }             # has_field returns whether an object has a field             has_field(object, field) = true {                 object[field]             }           libs:             - |               package lib.exclude_update               is_update(review) {                   review.operation == "UPDATE"               }             - |               package lib.exempt_container               is_exempt(container) {                   exempt_images := object.get(object.get(input, "parameters", {}), "exemptImages", [])                   img := container.image                   exemption := exempt_images[_]                   _matches_exemption(img, exemption)               }               _matches_exemption(img, exemption) {                   not endswith(exemption, "*")                   exemption == img               }               _matches_exemption(img, exemption) {                   endswith(exemption, "*")                   prefix := trim_suffix(exemption, "*")                   startswith(img, prefix)               } Constraintsの作成 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPReadOnlyRootFilesystem metadata:   name: psp-readonlyrootfilesystem spec:   match:     namespaces: ["staging"]     kinds:       - apiGroups: [""]         kinds: ["Pod"] 作成したConstraintTemplateとConstraintsのマニフェストファイルを適用します。 $ oc apply -f ConstraintTemplate_readonlyrootfilesystem.yaml $ oc apply -f Constraints_readonlyrootfilesystem.yaml 作成したポリシーを確認します。 $ oc get constrainttemplate NAME                         AGE k8spspreadonlyrootfilesystem   19s $ oc get constraints NAME                                                                                ENFORCEMENT-ACTION   TOTAL-VIOLATIONS k8spspreadonlyrootfilesystem.constraints.gatekeeper.sh/psp-readonlyrootfilesystem   deny                 0 以下のルートファイルシステムを読み取り専用にする設定を入れていないDeploymentのバリデーションを確認してみます。 apiVersion: apps/v1 kind: Deployment metadata:   name: gatekeeper-test   namespace: staging spec:   replicas: 1   selector:     matchLabels:       name: gatekeeper-test   template:     metadata:       name: gatekeeper-test       labels:         name: gatekeeper-test     spec:       nodeSelector:         "kubernetes.io/os": linux       containers:         - name: ubi-container           image: registry.redhat.io/ubi8/ubi:latest           command:             - "/bin/sh"             - "-c"             - "echo 'Pod is running with UBI...' && sleep infinity" $ oc apply -f Deployment_readonlyrootfilesystem.yaml ポリシーの適用スコープはPodのみなので、Deploymentのデプロイは成功します。 Podがデプロイされているか確認してみます。 $ oc get all -n staging Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+ NAME                              READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gatekeeper-test   0/1     0            0           5s NAME                                        DESIRED   CURRENT   READY   AGE replicaset.apps/gatekeeper-test-58f8db6f8   1         0         0       5s デプロイされていなかったので、replicasetのdescribeを確認してみます。 $ oc describe replicaset gatekeeper-test-58f8db6f8 -n staging … Events:   Type     Reason        Age                 From                   Message   ----     ------        ----                ----                   -------   Warning  FailedCreate  14s (x15 over 96s)  replicaset-controller  Error creating: admission webhook "validation.gatekeeper.sh" denied the request: [psp-readonlyrootfilesystem] only read-only root filesystem container is allowed: ubi-container デプロイが許可されなかったことがわかります。 次に、ルートファイルシステムを読み取り専用にする設定を入れてデプロイしてみます。 apiVersion: apps/v1 kind: Deployment metadata:   name: gatekeeper-test   namespace: staging spec:   replicas: 1   selector:     matchLabels:       name: gatekeeper-test   template:     metadata:       name: gatekeeper-test       labels:         name: gatekeeper-test         env: staging     spec:       nodeSelector:         "kubernetes.io/os": linux       containers:         - name: ubi-container           image: registry.redhat.io/ubi8/ubi:latest           command:             - "/bin/sh"             - "-c"             - "echo 'Pod is running with UBI...' && sleep infinity"           securityContext:             readOnlyRootFilesystem: true $ oc apply -f Deployment_readonlyrootfilesystem.yaml $ oc get all -n staging Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+ NAME                                   READY   STATUS    RESTARTS   AGE pod/gatekeeper-test-5d6ff97778-nkrns   1/1     Running   0          8s NAME                              READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gatekeeper-test   1/1     1            1           4m5s NAME                                         DESIRED   CURRENT   READY   AGE replicaset.apps/gatekeeper-test-58f8db6f8    0         0         0       4m5s replicaset.apps/gatekeeper-test-5d6ff97778   1         1         1       8s これでデプロイが成功しました！ 次の検証のためにConstraints、Deploymentは削除しておきます。 $ oc delete -f Deployment_readonlyrootfilesystem.yaml $ oc delete -f Constraints_readonlyrootfilesystem.yaml ミューテーションポリシー リソースのリクエストを、ポリシーに基づいて自動的に変更します。 これは、ユーザーが明示的に設定しなくても、必要な設定を自動で追加する動作です。 ミューテーションは以下の4種のCRDを使用して定義されます。今回は、ssign（メタデータ以外を変更する）を使います。 AssignMetadata：リソースのmetadataセクション（例：ラベルやアノテーション）を変更する際に使います。例えば、新しいPodがデプロイされる際に、自動でapp: my-appというラベルを追加することができます。 Assign：metadataセクション以外のリソースの変更を定義します。例えば、コンテナに環境変数を追加したり、リソース制限（limitsやrequests）のデフォルト値を設定したりする場合に利用します。 ModifySet：リスト形式のデータ（argumentsやvolumesなど）に対して、要素の追加や削除を行う際に使います。例えば、すべてのコンテナに特定のコマンド引数を自動で追加することができます。 AssignImage：コンテナイメージの文字列を自動で変更する際に使います。これは、イメージのタグを自動的に最新バージョンに更新したり、内部レジストリのドメイン名に書き換えたりする場合に便利です。 有効なシーン: リソース管理 PodにCPUやメモリのリソース制限が設定されていない場合、自動的にデフォルト値を追加し、クラスターのリソース枯渇を防ぎます。 しかし、この機能には注意が必要です。ミューテーションはマニフェストを自動的に変更するため、Gitリポジトリ（IaC）と実際のクラスター間で差分が発生します。例えば、ArgoCDのようなGitOpsツールでは、この差分が原因で「Out of Sync」と表示され、予期せぬ競合が起こる可能性があります。 このため、開発環境では利便性を優先し、自動変更を適用し、本番環境では監査や透明性を確保するため、マニフェストに設定を明記するなど、環境に合わせて適切に利用することが重要です。 運用効率化 すべてのPodに特定のサービスメッシュ用のサイドカーコンテナを自動で注入する、といった運用を効率化できます。 ただし、本番環境におけるサイドカー注入は、Istioをはじめとするサービスメッシュでは専用のAdmission Controllerによって行われることが一般的です。具体的には、Istioの公式ドキュメントにあるように、特定のNamespaceにラベルを付与することで自動注入が有効になり、APIサーバーのAdmission WebhookがPod作成時にサイドカーを挿入します。 https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/ 一方で、GatekeeperのMutation機能によるサイドカー注入は、主にポリシー検証の目的で用いられています。Gatekeeper公式ドキュメントによると、このMutationはIstioのサイドカー注入後のPodに似せたモックPodを作成してポリシーを検証するために利用されるため、本番環境で直接IstioのサイドカーをMutationで注入するケースは想定されていません。 https://open-policy-agent.github.io/gatekeeper/website/docs/expansion/ したがって、サービスメッシュのサイドカー注入をGatekeeperのMutationで自動化するユースケースは主に検証用途であり、本番運用ではIstioなどの専用Admission Controllerを利用するのが一般的です。 リソース制限の自動追加 以下のYAMLは、Podにリソース制限（limits.cpuとlimits.memory）が設定されていない場合、自動的に値を挿入します。 Mutationsの作成 apiVersion: mutations.gatekeeper.sh/v1 kind: Assign metadata:   name: pod-resource-limits-default spec:   applyTo:   - groups: [""]     versions: ["v1"]     kinds: ["Pod"]   match:     scope: Namespaced     namespaces: ["staging"]   location: "spec.containers[name:*].resources"    parameters:     assign:       value:         limits:           cpu: "500m"           memory: "256Mi"         requests:           cpu: "250m"           memory: "128Mi" 作成したMutationsのマニフェストファイルを適用します。 $ oc apply -f Mutations_pod-resource-limits-default.yaml 作成したミューテーションを確認します。 $ oc get assign NAME                          AGE pod-resource-limits-default   33s 以下のリソース制限を設定していないDeploymentのミューテーションを確認してみます。 apiVersion: apps/v1 kind: Deployment metadata:   name: gatekeeper-test   namespace: staging spec:   replicas: 1   selector:     matchLabels:       name: gatekeeper-test   template:     metadata:       name: gatekeeper-test       labels:         name: gatekeeper-test     spec:       nodeSelector:         "kubernetes.io/os": linux       containers:         - name: ubi-container           image: registry.redhat.io/ubi8/ubi:latest           command:             - "/bin/sh"             - "-c"             - "echo 'Pod is running with UBI...' && sleep infinity" $ oc apply -f Deployment_mutation.yaml 作成したPodを確認します。 $ oc get pod -n staging NAME                              READY   STATUS    RESTARTS   AGE gatekeeper-test-58f8db6f8-96ghh   1/1     Running   0          16s Podにリソース制限が設定されていることを確認します。 $ oc describe pod gatekeeper-test-58f8db6f8-96ghh -n staging … Containers:   ubi-container:   …   Limits:     cpu:     500m     memory:  256Mi   Requests:     cpu:        250m     memory:     128Mi … このように、マニフェストファイルに記載していなくてもリソース制限が設定されます。 継続的なポリシーチェックについて Gatekeeperは、Admission Webhookによるリアルタイムなチェックだけでなく、既存のリソースに対する継続的な監査も行います。 Gatekeeperのコントローラーは、定期的にクラスター内のすべてのリソースをスキャンし、既存のリソースがポリシーに適合しているかをチェックします。監査の結果、ポリシー違反が発見された場合、Constraintsリソースのstatusフィールドにその情報が記録されます。以下のコマンドで確認することができます。 $ oc describe <ConstraintTemplateで定義したCRD名> <constrains名> 例：$ oc describe k8srequiredlabels must-have-required-labels これにより、ポリシーを適用する前にデプロイされたリソースや、ポリシーが変更された後に違反状態になったリソースを特定し、修正することができます。 まとめ この記事では、OPA/Gatekeeperのバリデーションとミューテーションという二つの主要なポリシー適用動作について解説しました。 バリデーションは、運用ルールの自動化・強制適用に役立ちます。例えば、デプロイ前にPodに特定のラベルが付いているか、セキュリティ設定が適切かなどを自動でチェックし、違反を未然に防ぎます。これにより、手作業による確認ミスをなくし、クラスターの健全性を保つことができます。 ミューテーションは、必要な設定を自動で修正・追加し、開発者の負担を軽減に貢献します。例えば、リソース制限が設定されていないPodに自動でデフォルト値を設定したり、アプリケーションのPodに監視用のサイドカーコンテナを自動で注入したりすることができます。 これらのポリシーを導入することで、以下のような利用シーンでの課題を解決できます。 セキュリティ: ルートファイルシステムの読み取り専用の設定を強制し、コンテナイメージが実行時に書き込まれるのを防ぎます。 コンプライアンス: すべてのアプリケーションに、セキュリティ監査やコスト管理に必要なラベルを強制します。 運用: 開発チームが設定を忘れても、Podに適切なリソース制限が自動で適用されるため、リソース枯渇によるサービス停止を防げます。 参考文献 https://open-policy-agent.github.io/gatekeeper/website/docs/ https://open-policy-agent.github.io/gatekeeper-library/website/ https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/ https://open-policy-agent.github.io/gatekeeper/website/docs/expansion/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OPA/Gatekeeperで始める安心OpenShift運用：設定編 first appeared on SIOS Tech. Lab .

はじめに 前回の記事 ではGitLab Container Registryの基本的な設定と利用方法を解説しました。 今回は、GitLabに保存したイメージの公開範囲を制御したり、ガベージコレクションでストレージ利用を最適化するなど、運用で役立つ実践的な設定方法を紹介します。 可視性の設定 GitLabにおける「可視性（Visibility）」とは、プロジェクトや関連リソースに誰がアクセスできるかを制御する仕組みを指します。例えば、「公開」に設定すればGitLabのアカウントがないユーザーも含めて誰でも閲覧可能になり、「非公開」に設定すれば招待されたメンバーしか利用できません。 GitLabではこの可視性をプロジェクト単位とレジストリ単位の両方で設定することができます。つまり、ソースコードとコンテナイメージで異なる公開範囲を持たせることが可能です。両者を組み合わせることで「コードは公開するが、イメージは限定公開」といった柔軟な運用が可能となります。 以下ではまずプロジェクトの可視性について整理し、その後にContainer Registry特有の可視性設定を紹介します。 プロジェクトの可視性 プロジェクト全体の可視性は [設定] > [一般] > [可視性、プロジェクトの機能、権限] で変更可能です。 可視性レベル アクセス可能ユーザー 利用用途 公開 全てのユーザー（非ログインユーザーを含む） OSS公開、社外への配布 内部 GitLabにログイン済みのユーザー全員 社内全体で共有 非公開 プロジェクトのメンバーのみ 機密性の高いプロジェクト レジストリの可視性 各プロジェクトに紐づくコンテナレジストリも独自に公開範囲を設定可能です。 選択肢は以下の2種類です： アクセスできる人すべて（Everyone With Access、デフォルト）: プロジェクトの可視性に従い、アクセス権を持つすべてのユーザーが利用可能 プロジェクトメンバーのみ（Only Project Members）: 招待されたメンバーのみ利用可能 イメージの可視性はプロジェクト設定画面の[一般]を選択し、[コンテナレジストリ]の欄で設定することができます。 このプロジェクト可視性とレジストリ可視性を組み合わせることで、コンテナイメージに対する実際のアクセス範囲が決まります。 可視性の組み合わせとユースケース例 プロジェクト可視性 レジストリ可視性 イメージ取得可能ユーザー 主なユースケース 公開 アクセスできる人すべて 誰でも（非ログインユーザー含む） OSSライブラリの公式コンテナイメージ、学習教材用のサンプルアプリイメージ 公開 プロジェクトメンバーのみ プロジェクトメンバーのみ ソースコードはGitLab上で公開しつつ、商用サービス向けのビルド済み実行イメージは顧客限定で配布 内部 アクセスできる人すべて 社内ユーザー全員（Guest 以上） 社内共通のベースイメージ配布（Python/Java ランタイムなど） 内部 プロジェクトメンバーのみ プロジェクトメンバーのみ 特定部門やチーム限定のアプリイメージ 非公開 アクセスできる人すべて プロジェクトメンバー（Reporter 以上） 社外非公開の業務システム、クライアント案件専用イメージ 非公開 プロジェクトメンバーのみ プロジェクトメンバー（Reporter 以上） 高度なセキュリティが求められる分野のイメージ（金融・医療・政府系など） ※公開設定を選ぶ場合は、情報漏洩が起きないように権限やイメージの内容を十分確認してください。 ガベージコレクション GitLabのレジストリでイメージタグを削除しても、ストレージ容量はすぐには解放されません。タグが外れたイメージは「未タグ付き（Untagged）」として残るためです。 この問題を解決するのが ガベージコレクション（GC） です。 ガベージコレクションはGitLabの管理者がサーバー上でCLIコマンド（gitlab-ctl registry-garbage-collect）を実行することで動作します。 CI/CDで頻繁にイメージをビルド・pushする環境では、レジストリに不要なイメージが蓄積しやすいため、定期的にガベージコレクションを実施することでストレージを効率的に利用できます。 前提 gitlab-ctl registry-garbage-collectはメタデータをオブジェクトストレージに保存している場合のみ有効。 メタデータデータベース方式 （GitLabの新しいレジストリ方式）を有効にしている場合、このコマンドは使えず、代わりにオンラインGCが利用可能。 この機能はSelf-Managed版（Omnibus / Helm）限定 であり、GitLab.com（SaaS）では利用不可。 未参照レイヤーと未タグ付きマニフェストの違い ガベージコレクションが扱う対象は2種類あります。 未参照レイヤー（unreferenced layers） どのイメージマニフェストからも参照されていないレイヤー デフォルトのガベージコレクションで削除対象になる pullできず、純粋に不要なデータ 未タグ付きマニフェスト（untagged manifests） タグは削除されたが、ダイジェスト（@sha256:…）を指定すればpull可能 再タグ付けも可能で、再びGitLab UIやAPIに表示される デフォルトでは削除されず、ガベージコレクション実行コマンド（gitlab-ctl registry-garbage-collect）に-m オプションを付けた場合のみ削除される このため -m を付けると「未タグ付きイメージ」も消えるため、過去のdigest pullや再利用ができなくなります。実行前に十分注意してください。 基本の実行方法 ガベージコレクションは、GitLabサーバー上でgitlab-ctl registry-garbage-collectコマンドを実行して行います。 # 未参照レイヤーを削除 $ sudo gitlab-ctl registry-garbage-collect デフォルトでは未参照レイヤーのみ削除され、未タグ付きのマニフェストは残ります。 未タグ付きイメージも含めて完全に削除したい場合は、同じコマンドに -m オプションを指定して実行します。 # 未タグ付きイメージも含め削除 $ sudo gitlab-ctl registry-garbage-collect -m ※-mは破壊的な操作で元に戻せません。実行前に必ずバックアップを取得することを推奨します。 レジストリのダウンタイムと回避方法 gitlab-ctl registry-garbage-collectコマンドでガベージコレクションを行うと、処理前にレジストリが停止し、終了後に再起動されます。つまり、基本的にダウンタイムが発生することとなります。 停止を避けたい場合は、レジストリを「読み取り専用モード」に切り替え、GitLabに含まれるregistryバイナリ（通常は/opt/gitlab/embedded/bin/registry）を直接実行してガベージコレクションを行います。 /etc/gitlab/gitlab.rbに以下を設定し gitlab-ctl reconfigureを実行 registry['storage'] = {   'filesystem' => { 'rootdirectory' => "<レジストリのストレージパス>" },   'maintenance' => { 'readonly' => { 'enabled' => true } } } ガベージコレクションを実行 # 未参照レイヤーのみ削除 $ sudo /opt/gitlab/embedded/bin/registry garbage-collect /var/opt/gitlab/registry/config.yml # 未タグ付きも削除 $ sudo /opt/gitlab/embedded/bin/registry garbage-collect -m /var/opt/gitlab/registry/config.yml 読み取り専用モードをfalseに戻して再度 gitlab-ctl reconfigureを実行 registry['storage'] = {   'filesystem' => { 'rootdirectory' => "<レジストリのストレージパス>" },   'maintenance' => { 'readonly' => { 'enabled' => false } } } ガベージコレクション実行中でもイメージのpullは可能ですがpushは不可となります。 まとめ 今回は、GitLab Container Registryを実務で活用するための応用設定として「可視性の制御」と「ガベージコレクション」を紹介しました。特にガベージコレクションはストレージ効率を維持する上で重要ですが、Self-Managed版限定の管理者作業であり、ダウンタイムやオプション指定に注意が必要です。 2回にわたり解説したとおり、GitLabはソースコード管理だけでなく、コンテナイメージの管理機能も備えています。コードとイメージを一元管理することで、CI/CD環境をシンプルかつ効率的に構成できます。 次回からはGitLab CI/CD編として、レジストリと連携したパイプライン構築について解説していきます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitLab Container Registry: 応用編（可視性設定とガベージコレクション） first appeared on SIOS Tech. Lab .

こんにちは、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 .