GitLab Runner で公開鍵暗号方式を行いたい

概要

社内のGitLabでCI/CDを実現するためにGitLab RunnerをDocker outside of Docker (DooD)で構築。
その際に検証環境へscpコマンドで docker イメージを送る必要があり、その際にパスワードを聞かれて失敗します。
そのため、パスワードレスで検証環境のサーバへ接続するために鍵交換を行う必要があります。
今回はCI/CDで鍵交換を行ったので、そのときの備忘録を残します。

環境

• GitLab

解決策

大まかな流れとしては下記の通りです。

1. 暗号鍵・公開鍵を生成
2. 1.で生成した公開鍵を検証環境のサーバにて鍵交換して、パスワードレスで接続できることを確認
3. GitLabに1. で作成した暗号鍵を変数として登録
4. .gitlab-ci.ymlのbefore_scriptにて暗号鍵を登録して、検証環境のサーバへ接続

ここでは、4.の.gitlab-ci.ymlに関して掘り下げます。

.gitlab-ci.ymlのbefore_scriptの内容

.gitlab-ci.ymlのscriptの内容は下記になります。

before_script:
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - echo "${SSH_PRIVATE_KEY}" >> ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  # ssh-agentの起動
  - eval `ssh-agent`
  - ssh-add ~/.ssh/id_rsa
  # 初めてのホストへの接続を確認されないようにするため、StrictHostKeyChecking no を記載
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

${SSH_PRIVATE_KEY}はGitLabの変数で登録した秘密鍵の内容となります。

まとめ

今回はCI/CDで鍵交換を行いました。
上記で実現することができ、バージョンが上がったとしても利用できると思われます。

lsyncd でシンボリックリンクを貼ったフォルダを監視したときの挙動に関して

概要

あるサービスにて、Tomcatのフォルダをシンボリックリンクを貼った状態で運用していました。
なぜ、そのようにしたかは分からない状態ですが、更にlsyncdでシンボリックリンクを貼ったTomcatを監視していると問題が発生しました。
状況としては下記になります。

1. シンボリックリンクを張ったTomcatフォルダ（A）

2. シンボリックリンクを張った元のフォルダ（ここでは、Apache-Tomcat-XXとします。）（B）

コマンドとしては下記になります。

$ ln -s Apache-Tomcat-XX Tomcat

lsyncdはTomcatを監視しています。
そのため、lsyncdとしては、Apache-Tomcat-XXのフォルダパスを参照するようになります。

問題

問題が発生したコマンド操作

ある時、開発画面からApache-Tomcat-XXのバージョンが見えている脆弱性が見つかりました。
対策としてTomcatフォルダ（A）を削除して、Apache-Tomcat-XXをmvコマンドでTomcatとして名前を変更しました。
そのため、下記のようなフォルダ構成になります。

1. Tomcatフォルダは削除（Aを削除）

2. Apache-Tomcat-XXをTomcatに変更（B→C）

lsyncd の結果

lsyncdとしては元のApache-Tomcat-XXパスを参照しているですが、CのTomcatフォルダを更新しても発火してしまう状態でした。
そのため、lsyncdとしてはApache-Tomcat-XXのフォルダが見つからないため、同期に失敗してしていました。

対策

lsyncdを再起動したことで同期が切れました。
また、想定していた挙動をするようになりました。

まとめ

よく考えてみると問題が発生することは想定できましたが、当時は気づけなかったので、備忘録として残しました。

Claude Code でプログラムをリバースしてみた

概要

Claude Codeでプログラムから設計書を書かせてみましたので、その結果を残します。 結論から言わせてもらいますと、しっかりとした内容が出力されました。

内容

状況

• レガシーなサービスでありかつ、当時の担当者がいないためサービスに詳しい担当者がいない状態
• 設計書に関しては一部、存在しない箇所があり（そのため、プログラムを一から把握する必要があり）
• プログラムに関しては、ノーコードツールで生成されたプログラム

  利用方法

  プログラムをプロジェクトに集めて、プログラムから設計書を書き起こすように指示を出してみました。
  当初の想定では、生成されたプログラムなので、難しいかと思っておりましたが、作成された設計書を確認すると正しい設計書が書き起こされました。

  効果

  作業時間

  作業時間に関しては短縮されたと思います。
  実際には、30分ほどClaude Codeでプロンプトで指示を出したのみであり、4ドルほどしかかかっていないため、かなりの作業効率です。
  私が調査すると3人日はかかると想定していたので、効果は明らかです。

  まとめ

  Claude Codeでプログラムから設計書を書き起こしました。
  プログラムの開発だけでなく、設計書のリバース作業も行うことができるため、今後も手放せないと思います。

incronで対象のファイルが更新されたにも関わらず発火しない

概要

サービスで利用しているincronにて、イベントが発火しないことが分かりました。
incronの設定ファイルの確認や検証環境にてテストしたところ、原因が分かりましたので、備忘録として残します。

環境

• Linux

原因

結論から先に述べると、incronで監視している対象のファイルが一度、削除されていることが原因でした。

incronについて

wiki.archlinux.jp

incronはinotify cronというシステムでした。
そのため、inotifyでファイルを削除したときの挙動を確認したところ、監視対象のファイルが削除された場合は監視から外れることが分かりました。

qiita.com

対処

下記のコマンドでincronを再読み込みさせたところ、無事に解決しました。

pkill -HUP incrond

Difyのナレッジベースにおける親子チャンク昨日を利用してみた

概要

社内にて、Difyを利用したAIエージェントの作成を行っています。
AIエージェントを作成するにあたり、ナレッジベースを作成してより社内向けの知識を作成したので、 その際の知識を備忘録としてまとめます。

親子チャンク機能

docs.dify.ai

ナレッジベースを作成するときには汎用モードと親子モードの2つのモードがあります。
それぞれの特徴としては公式サイトより抜粋しますと下記になります。

機能名	機能の特徴
汎用モード	ドキュメントを一定のルール（文字数など）で分割し、各チャンクを独立した単位として扱います
親子モード	小さいチャンク（子）と、それを含む大きなチャンク（親）をセットで管理し、検索時に親チャンクも参照できます

親子モードの具体的な使い方

過去のシステム変更の手順書

私が今回、親子モードで利用した方法としては、社内における過去のシステム変更の手順書をナレッジベースとして保存しました。
その際に、システム変更の手順書では

• 手順の順序

• 作業の注意点

• 作業するサーバ

などが必要であるため、周りの文脈の情報が必要になってきます。

Apache HTTP サーバにおけるTLSプロトコルバージョンと暗号スイートの設定方法に関して

概要

Apache HTTP においてTLS通信を行った後に下記の設定を行いました。

• TLSプロトコルバージョン
• 暗号スイート

上記2点の設定を行ったので、設定方法の備忘録として残します。

環境

• AlmaLinux 9（RHEL9）

事前知識

TLSプロトコルバージョン

クライアントがブラウザでSSL/TLS通信を行ってApache HTTP サーバへ通信を行うときの通信プロトコルのバージョン。
具体的には、TLS1.3やTLS1.2になります。

暗号スイート

上記のようにクライアントとサーバ間でSSL/TLS通信を行うときに利用する暗号化のアルゴリズム。
暗号化するときのアルゴリズムには鍵交換や認証などで、様々な種類があります。

実装方法

TLSプロトコルバージョン

docs.redhat.com

Apache HTTP の設定ファイル（/etc/httpd/conf/httpd.conf）を編集して、<VirtualHost>ディレクティブのSSLProtocolに追記します。

SSLProtocol -All TLSv1.3

-は無効化であり、何も頭に付けないあるいは、+は有効化を表しています。
上記であれば、TLSv1.3のTLSプロトコルのみを有効にしています。

暗号スイート

docs.redhat.com

Apache HTTP の設定ファイル（/etc/httpd/conf/httpd.conf）を編集して、<VirtualHost>ディレクティブのSSLCipherSuiteに追記します。

SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"

:で区切り、!は無効化を表しています。
上記であれば、EECDH+AESGCM EDH+AESGCM AES256+EECDH AES256+EDH 暗号のみを有効にしています。
また、メッセージ認証コード（MAC）はSHA1 SHA256を無効化しています。

設定を変更した場合はApache HTTPを再起動して、反映させます。

# systemctl restart httpd

CloudFront+S3でキャッシュさせないように気をつけたこと

概要

CloudFront + S3 で Web サイトを構築したときにキャッシュにより、リアルタイムで更新したいファイルがあったときに更新されない問題が発生しました。
調査したところ、原因としてはブラウザキャッシュとCDNキャッシュの2点で問題があったことが判明。
そのときの対策方法をそれぞれ記載します。

構築した環境

• AWS
  • CloudFront
  • S3
• Webサイト
  • HTML
  • CSS

対策

ブラウザキャッシュ

ブラウザキャッシュ対策方法としては、動的にURLを変更することで対応しました。

scrapbox.io

私の場合はfetch関数を javascript で埋め込んでいるのですが、下記のようにURLを毎回変更するように対策しました。

const date = new Date();
const Url = xxxx.json + '?' + date;
fetch(Url)
...

CDNキャッシュ

CDNキャッシュ対策としては、CloudFrontの設定で対応しました。

docs.aws.amazon.com

上記のように CloudFront のビヘイビアにて、対象のファイルのパスをキャッシュで残さないように対応しました。

まとめ

CloudFront + S3 で CDN のサイトを作成したときのキャッシュ対策をまとめました。
キャッシュ対策としては、下記2点となります。 - ブラウザキャッシュ - CDNキャッシュ 他のCDNサービスでも起こり得る話なので、参考にして下さい。