ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
Cantaloupe IIIFサーバーのキャッシュ最適化で画像配信を最大7.6倍高速化した

Cantaloupe IIIFサーバーのキャッシュ最適化で画像配信を最大7.6倍高速化した

はじめに IIIFに対応した画像サーバーであるCantaloupeを、S3をソースとしたDocker環境で運用しています。IIIFビューア(Mirador, OpenSeadragonなど)では、ズームやパンの操作のたびに数十〜数百のタイルリクエストが同時に発生します。 今回、キャッシュ設定の見直しとパラメータチューニングにより、タイル配信速度を最大7.6倍高速化できたので、その手法と効果を共有します。 環境 サーバー: AWS EC2(2 vCPU, 7.6GB RAM) Cantaloupe: islandora/cantaloupe:2.0.10(Cantaloupe 5.0.7ベース) 画像ソース: Amazon S3(S3Source) テスト画像: 25167×12483px のTIFF画像(512×512タイル) リバースプロキシ: Traefik v3.2 構成: Docker Compose 問題:デフォルト設定ではキャッシュが無効 islandora/cantaloupe イメージのデフォルト設定を調査したところ、以下の状態でした。 キャッシュ種別 デフォルト 説明 Derivative Cache(加工済み画像) 無効 同じリクエストでも毎回画像変換が発生 Source Cache(元画像のローカルコピー) 有効(FilesystemCache) S3から取得した元画像をローカルに保持 Info Cache(画像メタデータ) 有効(メモリ内) 画像の寸法・タイル情報を保持 Client Cache(HTTPヘッダ) 有効(max-age 30日) ブラウザ側のキャッシュ制御 最大の問題は Derivative Cache が無効であることです。IIIFビューアが同じタイルを再度リクエストした場合でも、毎回 S3 → ダウンロード → 画像変換 → レスポンス という処理が走ります。 ベンチマーク方法 単純なタイル一括テスト まず基本的な性能測定として、以下の条件で一括タイルベンチマークを行いました。 タイル数: 91タイル(zoom level 4、scaleFactor=4の全タイル) 同時接続数: 10(ブラウザの一般的な同時接続数) ツール: curl + xargs -Pによる並列リクエスト # タイルURLを生成し、10並列で同時リクエスト xargs -a tile_urls.txt -P 10 -I {} \ curl -s -o /dev/null -w "%{time_total}\n" "{}" Miradorシミュレーション 単純なタイル一括テストに加え、IIIFビューア(Mirador)の実際の操作フローを再現したベンチマークも行いました。Miradorでは、ユーザーが画像を開くと以下のリクエストが短時間に発生します。 ...

AlfrescoをDockerで起動し、REST APIでレコード管理のライフサイクルを体験する

AlfrescoをDockerで起動し、REST APIでレコード管理のライフサイクルを体験する

概要 本記事では、Alfresco Governance Services Community Edition(以下AGS)の最新版(25.3.0)をDockerで起動し、REST APIを使ってレコード管理の一連のライフサイクルを体験します。 具体的には、以下の業務シナリオを想定します。 シナリオ: 契約書管理 業務部門が契約書を作成・登録する レコード管理者がレコードとして宣言し、ファイルプランに分類する 保持スケジュール(Retention Schedule)を設定する 契約終了後、カットオフ(現用→非現用)を実行する 保持期間(3年)の経過後、廃棄する 訴訟対応が発生した場合、ホールド(凍結)により廃棄を停止する 以下の前回の記事をベースに、最新版での構築手順とAPIの使い方を紹介します。 https://zenn.dev/nakamura196/articles/8da7161ff3df30 環境 acs-deployment: v10.2.0(2026年2月リリース) Alfresco Governance Repository Community: 25.3.0 Alfresco Governance Share Community: 25.3.0 Alfresco Search Services: 2.0.17 Traefik: 3.6 PostgreSQL: 16.5 セットアップ リポジトリのクローン git clone https://github.com/Alfresco/acs-deployment cd acs-deployment git checkout v10.2.0 cd docker-compose compose fileの作成 community-compose.yamlをベースに、Governance Services用のcompose fileを作成します。変更点は以下の3つです。 1. イメージの差し替え サービス 変更前 変更後 alfresco alfresco/alfresco-content-repository-community:25.3.0 alfresco/alfresco-governance-repository-community:25.3.0 share alfresco/alfresco-share:25.3.0 alfresco/alfresco-governance-share-community:25.3.0 2. 認証チケットのタイムアウト対策(後述) ...

Docker + GitHub Actions デプロイ設定

Docker + GitHub Actions デプロイ設定

このドキュメントでは、Docker コンテナを GitHub Actions で自動デプロイする設定手順を説明します。 目次 Docker 設定 GitHub Actions 設定 サーバー側の設定 トラブルシューティング Docker 設定 Dockerfile(静的サイト + nginx) 静的 HTML を生成し、nginx で配信します。 FROM node:22-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run generate # 静的ファイル配信用のnginx FROM nginx:alpine # Nuxt 3 の場合: .output/public # Nuxt 2 の場合: dist COPY --from=builder /app/.output/public /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] nginx.conf(SPA 用設定) SPA では動的ルート(/item/:id など)を index.html にフォールバックさせる必要があります。 ...

Omeka-S Docker環境を別サーバーに移行する完全ガイド

Omeka-S Docker環境を別サーバーに移行する完全ガイド

はじめに 本記事では、Docker ComposeでセットアップされたOmeka-S環境を、volumeデータを含めて別のサーバーに移行する手順を解説します。データの整合性を保ちながら、安全に移行作業を進めることができます。 環境 移行元サーバー : Ubuntu 22.04 移行先サーバー : Ubuntu 22.04(新規セットアップ) 構成 : Omeka-S + MariaDB + phpMyAdmin + Traefik + Mailpit 移行の流れ 移行元サーバーでのバックアップ ローカルマシンへのダウンロード 移行先サーバーのDocker環境セットアップ データの復元と起動 ステップ1: 移行元サーバーでのバックアップ 1.1 現在の環境確認 # 実行中のコンテナを確認 docker ps # Dockerボリュームを確認 docker volume ls 出力例: DRIVER VOLUME NAME local omeka-s-docker_mariadb local omeka-s-docker_omeka 1.2 バックアップファイルの作成 # /optディレクトリに移動 cd /opt # 設定ファイル等をバックアップ(約60MB) sudo tar -czf omeka-backup-$(date +%Y%m%d).tar.gz omeka-s-docker/ # Dockerボリュームのデータをバックアップ(約1GB) sudo docker run --rm \ -v omeka-s-docker_omeka:/data/omeka \ -v omeka-s-docker_mariadb:/data/mariadb \ -v /opt:/backup \ alpine tar -czf /backup/omeka-volumes-$(date +%Y%m%d).tar.gz -C /data . # バックアップファイルの確認 ls -lh /opt/*.tar.gz 出力例: ...

Azure Container AppsでNDL古典籍OCR Liteを用いたスケーラブルOCR処理システム

Azure Container AppsでNDL古典籍OCR Liteを用いたスケーラブルOCR処理システム

⚠️ 重要な利用上の注意 本記事で紹介するシステムは、外部サーバーに負荷をかける可能性があります。利用時は十分ご注意ください。 サーバー負荷 : 並列リクエストは対象サーバーに負荷を与えます DoS攻撃のリスク : 大量の同時アクセスはDoS攻撃と誤解される可能性があります 推奨アプローチ : 事前に画像をローカルにダウンロードし、OCR処理のみを並列実行することを推奨します 利用規約の確認 : 対象サーバーの利用規約を必ず確認し、必要に応じて事前許可を取得してください 適切なレート制限 : 実運用では慎重な並列数設定(5-10並列程度)を強く推奨します 責任ある利用 : サーバー管理者や他の利用者への配慮を忘れずに 本記事は技術的な実証実験の記録です。読者の皆様には責任を持った利用をお願いします。 はじめに 本記事では、国立国会図書館(NDL)が開発したNDL古典籍OCR Liteを活用し、Azure Container AppsでスケーラブルなOCR処理システムを構築した事例を紹介します。クラウドネイティブなアーキテクチャにより、従量課金とオートスケーリングを実現したシステムの設計と実装について解説します。 システム概要 アーキテクチャ IIIF画像 → Azure Container Apps → NDL古典籍OCR → TEI XML出力 ↓ オートスケーリング (0-30レプリカ) 主要コンポーネント OCRエンジン : NDL古典籍OCR Lite(日本古典籍特化) インフラ : Azure Container Apps(サーバーレスコンテナ) API設計 : REST API(画像URL → OCR結果) 出力形式 : TEI P5準拠XML スケーリング : 需要に応じた自動スケーリング NDL古典籍OCR Liteの特徴 日本古典籍に最適化されたOCR 縦書きレイアウト対応 : 古典籍特有の縦書き文書構造 読み順序最適化 : 右から左、上から下の日本語読み順 古典文字認識 : くずし字や変体仮名への対応 軽量実装 : Docker化によりクラウドデプロイ対応 Azure Container Appsの選択理由 サーバーレスコンテナの利点 # スケーリング設定例 scale: minReplicas: 0 # アイドル時: コスト0 maxReplicas: 30 # 需要時: 自動拡張 cooldownPeriod: 300 # 5分でスケールダウン コスト最適化 従量課金 : 使用した分のみ課金 0レプリカ : アイドル時は完全にコスト0 自動スケーリング : 需要に応じたリソース調整 システム実装 サーバーサイド実装 # Flask + NDL OCR統合 from flask import Flask, request, jsonify from flask_restx import Api, Resource from simple_ocr_service import OCRService app = Flask(__name__) api = Api(app, doc='/docs/') @api.route('/api/image') class ImageOCR(Resource): def get(self): image_url = request.args.get('image_url') # NDL OCRで画像処理 result = ocr_service.process_single_image(image_url) return result 読み順序アルゴリズム def sort_japanese_reading_order(lines): """日本古典籍の読み順序ソート""" return sorted(lines, key=lambda line: ( -line["bbox"][0], # x座標降順(右→左) line["bbox"][1] # y座標昇順(上→下) )) TEI XML出力 xml version="1.0" encoding="UTF-8"?> TEI xmlns="http://www.tei-c.org/ns/1.0"> teiHeader> fileDesc> titleStmt> title>桐壺title> titleStmt> respStmt> resp>Automated Transcriptionresp> name ref="https://github.com/ndl-lab/ndlkotenocr-lite"> NDL古典籍OCR Lite name> respStmt> fileDesc> teiHeader> facsimile> surface xml:id="surface-1"> zone xml:id="zone-1-1" ulx="3391" uly="1141" lrx="3727" lry="2924" cert="0.799"/> surface> facsimile> text> body> div type="transcription"> pb n="1" facs="#surface-1"/> lb n="1.1" corresp="#zone-1-1" cert="high"/> いづれの御時にか div> body> text> TEI> 処理結果事例 小規模テスト処理(桐壺) 対象 : 東京大学所蔵「桐壺」 ページ数 : 32ページ 処理時間 : 約30秒 成功率 : 100% 並列数 : 10並列 コスト : 約$0.05 パフォーマンス特性 処理時間 = 約1秒/ページ(並列処理時) コスト効率 = $1.5〜2.0/1000ページ スケーリング = 数秒で0→20レプリカ システムの技術的特徴 1. コールドスタート対応 async def process_with_retry(image_url, max_retries=3): """コールドスタート時の自動リトライ""" for attempt in range(max_retries + 1): try: if attempt > 0: wait_time = 2 ** (attempt - 1) await asyncio.sleep(wait_time) return await ocr_request(image_url) except (HTTPError, TimeoutError) as e: if attempt == max_retries: raise e 2. 設定の外部化 # 環境変数による設定 OCR_API_URL=https://your-ocr-service.azurecontainerapps.io DEFAULT_MAX_CONCURRENT=10 DEFAULT_CONFIDENCE_THRESHOLD=0.3 DEFAULT_OUTPUT_FORMAT=xml 3. Swagger UI統合 # API仕様の自動生成 api = Api(app, version='1.0', title='NDL古典籍OCR API', description='日本古典籍専用OCR処理API', doc='/docs/' ) デプロイメント Azure Container Appsデプロイ # コンテナアプリ作成 az containerapp create \ --name ocr-service \ --resource-group rg-ocr \ --environment container-env \ --image registry.azurecr.io/ocr-app:latest \ --target-port 80 \ --ingress external \ --min-replicas 0 \ --max-replicas 30 \ --cpu 2.0 \ --memory 4Gi Docker化 FROM python:3.11-slim # NDL OCRモデル配置 COPY model/ /app/model/ COPY config/ /app/config/ # アプリケーション設定 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . EXPOSE 80 CMD ["gunicorn", "--bind", "0.0.0.0:80", "app:app"] 運用とモニタリング パフォーマンスメトリクス レスポンス時間 : 平均2-3秒/画像 スループット : 10-15画像/秒(20レプリカ時) 成功率 : 99%以上 コスト効率 : アイドル時$0、処理時のみ課金 ログ監視 # Container Appsログ確認 az containerapp logs show \ --name ocr-service \ --resource-group rg-ocr \ --follow 今後の展望 技術的改善点 画像キャッシュ : 重複処理の削減 バッチ処理 : 効率的な大量処理 GPU対応 : OCR処理の高速化 メトリクス強化 : 詳細な性能分析 応用可能性 デジタルアーカイブ : 図書館・博物館での活用 研究支援 : 人文学研究のデジタル化 教育分野 : 古典文献の教材化 文化保存 : 貴重資料のデジタル保存 まとめ NDL古典籍OCR LiteとAzure Container Appsを組み合わせることで、コスト効率とスケーラビリティを両立した古典籍OCRシステムを構築できました。サーバーレスアーキテクチャにより、従量課金と自動スケーリングを実現し、実用的なデジタルヒューマニティーズツールとして活用可能です。 ...

Docker環境でDrupal 10にWDBモジュールをセットアップする手順

Docker環境でDrupal 10にWDBモジュールをセットアップする手順

概要 この記事では、Docker環境でDrupal 10を構築し、言語学データベース用のWDBモジュールをインストールする手順を解説します。 前提条件 Docker Desktop がインストールされていること Git がインストールされていること 手順 1. Docker環境の構築 まず、docker-compose.ymlファイルを作成します: services: mariadb: image: mariadb:latest restart: always volumes: - mariadb:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: drupal MYSQL_DATABASE: drupal MYSQL_USER: drupal MYSQL_PASSWORD: drupal drupal: image: drupal:10.2.7-php8.2-apache-bullseye volumes: - ./drupal/files:/opt/drupal/web/sites/default/files - ./drupal/modules:/opt/drupal/web/modules - ./drupal/themes:/opt/drupal/web/themes - ./drupal/private:/opt/drupal/private depends_on: - mariadb ports: - 8080:80 restart: always volumes: mariadb: {} 次に、必要なディレクトリを作成し、コンテナを起動します: ...

Omeka S Docker の紹介:デジタルコレクションのための最新かつセキュアなソリューション

Omeka S Docker の紹介:デジタルコレクションのための最新かつセキュアなソリューション

! 本記事はAIが作成しました。 Omeka S Docker へようこそ!このプロジェクトは、大学、ギャラリー、図書館、アーカイブ、博物館向けの Web パブリケーションシステムである Omeka S の本番環境対応 Docker セットアップを提供します。 📦 GitHub リポジトリ : https://github.com/nakamura196/omeka-s-docker なぜ Omeka S Docker なのか? デジタルコレクションの管理は複雑である必要はありません。そのため、Omeka S のデプロイと管理を簡素化する Docker ベースのソリューションを作成しました。 主な機能 🚀 クイックセットアップ : シングルコマンドで数分以内に Omeka S を稼働 🔒 セキュリティファースト : 非 root コンテナとセキュアなデフォルト設定を含むセキュリティベストプラクティスで構築 📦 モジュール管理 : 人気の Omeka S モジュールの自動インストールとアップデート 🔄 簡単なアップグレード : データの永続性を保ちながらシームレスなバージョンアップグレード 🐳 本番環境対応 : 開発環境と本番環境の両方に最適化 🌐 Traefik 統合 : リバースプロキシと SSL 終端のビルトインサポート はじめに 前提条件 Docker と Docker Compose がインストールされていること コマンドラインの基本的な知識 (オプション)SSL 付き本番環境デプロイ用のドメイン名 セットアップオプションの理解 この Docker セットアップは2つのデプロイモードを提供します: ...

「前近代日本-アジア関係資料デジタルアーカイブ」のビューアを試す

「前近代日本-アジア関係資料デジタルアーカイブ」のビューアを試す

概要 「前近代日本-アジア関係資料デジタルアーカイブ」が2025年7月25日に公開されました。 https://asia-da.lit.kyushu-u.ac.jp/ また、以下でビューアが公開されています。 https://github.com/localmedialabs/tei_comparative_viewer 本記事では、本ビューアを試した記録を共有します。 結果、以下のように、セルフホストすることができました。 https://tei-comparative-viewer.aws.ldas.jp/ 以下の「海東諸国紀」のXMLファイルを読み込んでいます。 https://asia-da.lit.kyushu-u.ac.jp/viewer/300 ローカルで起動する 以下に丁寧な説明がなされていますので、手順にしたがって起動させることができました。 https://github.com/localmedialabs/tei_comparative_viewer/blob/main/docs/SETUP.md サーバで起動する サーバで起動するにあたり、Dockerを用いて起動しました。 フォークしたリポジトリは以下です。 https://github.com/nakamura196/tei_comparative_viewer/tree/docker-traefik-setup 以下のようなファイルを用意しました。 FROM php:8.2-fpm # Install system dependencies RUN apt-get update && apt-get install -y \ git \ curl \ libpng-dev \ libonig-dev \ libxml2-dev \ zip \ unzip \ nodejs \ npm \ nginx \ supervisor # Clear cache RUN apt-get clean && rm -rf /var/lib/apt/lists/* # Install PHP extensions RUN docker-php-ext-install mbstring exif pcntl bcmath gd # Get latest Composer COPY --from=composer:latest /usr/bin/composer /usr/bin/composer # Set working directory WORKDIR /var/www # Copy existing application directory contents COPY . /var/www # Install dependencies RUN composer install --no-dev --optimize-autoloader # Install and build frontend assets RUN npm install && npm run build # Remove default nginx site RUN rm -f /etc/nginx/sites-enabled/default # Copy nginx config COPY docker/nginx/app.conf /etc/nginx/sites-available/app.conf RUN ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/ # Copy PHP-FPM config COPY docker/php/www.conf /usr/local/etc/php-fpm.d/www.conf # Copy supervisor config COPY docker/supervisor/supervisord.conf /etc/supervisor/conf.d/supervisord.conf # Create necessary directories and set permissions RUN mkdir -p /var/log/supervisor \ && chown -R www-data:www-data /var/www \ && chmod -R 755 /var/www/storage \ && chmod -R 755 /var/www/bootstrap/cache # Generate key RUN php artisan key:generate # Optimize Laravel RUN php artisan config:cache && \ php artisan route:cache && \ php artisan view:cache # Expose port 80 EXPOSE 80 # Create PHP-FPM socket directory RUN mkdir -p /var/run/php # Start supervisord CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"] services: app: build: context: . dockerfile: Dockerfile.prod.traefik container_name: tei_viewer_app restart: unless-stopped env_file: - .env.external volumes: - ./storage:/var/www/storage - ./public/assets:/var/www/public/assets networks: - traefik-network labels: - "traefik.enable=true" # HTTP router (redirects to HTTPS) - "traefik.http.routers.app-insecure.rule=Host(`xxx.yyy.zzz`)" - "traefik.http.routers.app-insecure.entrypoints=web" - "traefik.http.routers.app-insecure.middlewares=https-redirect" - "traefik.http.middlewares.https-redirect.redirectscheme.scheme=https" # HTTPS router - "traefik.http.routers.app.rule=Host(`xxx.yyy.zzz`)" - "traefik.http.routers.app.entrypoints=websecure" - "traefik.http.routers.app.tls.certresolver=myresolver" - "traefik.http.services.app.loadbalancer.server.port=80" # Security headers - "traefik.http.middlewares.app-headers.headers.frameDeny=true" - "traefik.http.middlewares.app-headers.headers.contentTypeNosniff=true" - "traefik.http.middlewares.app-headers.headers.browserXssFilter=true" - "traefik.http.middlewares.app-headers.headers.referrerPolicy=strict-origin-when-cross-origin" - "traefik.http.middlewares.app-headers.headers.stsSeconds=31536000" - "traefik.http.middlewares.app-headers.headers.stsIncludeSubdomains=true" - "traefik.http.middlewares.app-headers.headers.stsPreload=true" # Apply middlewares - "traefik.http.routers.app.middlewares=app-headers" networks: traefik-network: external: true # Application Environment APP_ENV=production APP_DEBUG=false APP_KEY= APP_URL=https://xxx.yyy.zzz # Domain Configuration (used in docker-compose labels) DOMAIN=xxx.yyy.zzz # Database DB_CONNECTION=sqlite # Session and Cache SESSION_DRIVER=file CACHE_DRIVER=file # Logging LOG_CHANNEL=stack # Mail (if needed) MAIL_MAILER=smtp # Other Laravel configurations as needed #!/bin/bash echo "=== TEI Comparative Viewer Setup with External Traefik ===" # .env.externalファイルが存在しない場合は作成 if [ ! -f .env.external ]; then echo "Creating .env.external file..." cp .env.external.example .env.external # アプリケーションキーを生成 echo "Generating application key..." docker run --rm \ -v $(pwd):/var/www \ -w /var/www \ php:8.2-cli \ php artisan key:generate --env=production --show | sed 's/base64://' > app_key.tmp # 生成したキーを.env.externalに設定 APP_KEY=$(cat app_key.tmp) sed -i.bak "s/APP_KEY=/APP_KEY=base64:$APP_KEY/" .env.external rm app_key.tmp .env.external.bak echo "Application key generated successfully!" fi # 設定の確認 echo "" echo "⚠️ IMPORTANT: Please edit .env.external and configure the following:" echo " 1. DOMAIN=your-domain.com (your actual domain)" echo " 2. APP_URL=https://your-domain.com (with HTTPS)" echo " 3. ASSET_URL=https://your-domain.com (for proper asset loading)" echo "" echo "Note: This setup assumes you have an external Traefik instance running" echo "with the 'traefik-network' already created." echo "" read -p "Press Enter to continue with the current settings..." # .envファイルをロード export $(cat .env.external | grep -v '^#' | xargs) # traefik-networkが存在するか確認 echo "Checking if traefik-network exists..." if ! docker network ls | grep -q traefik-network; then echo "❌ Error: traefik-network not found!" echo "Please ensure your external Traefik is running with traefik-network created." echo "" echo "If you need to create the network manually:" echo " docker network create traefik-network" exit 1 fi echo "✅ traefik-network found!" # 必要なディレクトリを作成 echo "Creating necessary directories..." mkdir -p storage/app/public mkdir -p storage/framework/{cache,sessions,views} mkdir -p storage/logs mkdir -p bootstrap/cache # まず.envファイルをコピー echo "Copying environment file..." cp .env.external .env # Dockerイメージをビルド(キー生成なしのDockerfileを使用) echo "Building Docker images..." if ! docker compose -f docker-compose-external.yml build; then echo "❌ Docker build failed. Trying without cache..." docker compose -f docker-compose-external.yml build --no-cache fi # コンテナを起動 echo "Starting containers..." docker compose -f docker-compose-external.yml up -d # 起動確認 echo "Waiting for services to be ready..." sleep 15 # アプリケーションキーが設定されていない場合は生成 echo "Checking and generating application key if needed..." if docker compose -f docker-compose-external.yml exec app php artisan key:generate --show | grep -q "base64:"; then echo "Generating new application key..." docker compose -f docker-compose-external.yml exec app php artisan key:generate --force fi # 権限を設定 echo "Setting permissions..." docker compose -f docker-compose-external.yml exec app chown -R www-data:www-data /var/www/storage /var/www/bootstrap/cache || echo "Permission setting completed" # 設定キャッシュをクリア echo "Clearing configuration cache..." docker compose -f docker-compose-external.yml exec app php artisan config:clear docker compose -f docker-compose-external.yml exec app php artisan config:cache docker compose -f docker-compose-external.yml exec app php artisan route:clear # アプリケーションの状態確認 echo "Checking application status..." if docker compose -f docker-compose-external.yml ps | grep -q "Up"; then echo "✅ Application container is running!" else echo "❌ Application container may have issues. Check logs:" echo " docker compose -f docker-compose-external.yml logs app" fi echo "" echo "✅ Setup complete!" echo "" echo "Application should be available at your configured domain (HTTPS)" echo "(assuming your external Traefik is properly configured and SSL certificates are set up)" echo "" echo "To stop the application, run:" echo " docker compose -f docker-compose-external.yml down" echo "" echo "To view logs, run:" echo " docker compose -f docker-compose-external.yml logs -f app" echo "" echo "To check Traefik routing (if dashboard is accessible):" echo " Check your Traefik dashboard for the new routes" echo "" echo "📝 Next steps:" echo " 1. Edit .env.external with your actual domain settings" echo " 2. Update docker-compose-external.yml Traefik labels with your domain" echo " 3. Ensure DNS is properly configured for your domain" まとめ 間違っている点もあるかもしれませんが、参考になりましたら幸いです。 ...

Dockerによるディスク圧迫の調査と対処法【Ubuntu 22.04 運用事例】

Dockerによるディスク圧迫の調査と対処法【Ubuntu 22.04 運用事例】

はじめに 本記事では、Dockerコンテナやイメージによるディスク圧迫が原因でElasticsearchにエラーが発生した事例と、その調査・対処方法について記録します。同様の問題に直面している方の参考になれば幸いです。 🔍 問題の発生 運用中のElasticsearchで以下のエラーが発生しました。 { "error": { "type": "search_phase_execution_exception", "reason": "all shards failed", "phase": "query", ... }, "status": 503 } 初期調査により、インデックスが close 状態になっており、ディスク容量不足が疑われました。 📊 ディスク使用状況の調査 ルートディレクトリの使用量確認 まず、システム全体のディスク使用状況を確認しました。 sudo du -h --max-depth=1 / | sort -hr | head -n 20 実行結果: 60G / 50G /var 4.7G /usr 2.1G /home 1.2G /opt ... /var ディレクトリが50GBと異常に大きいことが判明しました。 /var ディレクトリの詳細調査 sudo du -h --max-depth=1 /var | sort -hr 実行結果: 50G /var 49G /var/lib 342M /var/log 240M /var/cache 128M /var/spool ... /var/lib がほぼ全容量を占めているため、さらに詳細を調査しました。 sudo du -h --max-depth=1 /var/lib | sort -hr 実行結果: ...

AtoM(Access to Memory)をDockerで起動する

AtoM(Access to Memory)をDockerで起動する

概要 AtoM(Access to Memory)をDockerで起動する機会があったので、備忘録です。 マニュアル 以下に記載があります。 https://www.accesstomemory.org/es/docs/2.9/dev-manual/env/compose/ git clone -b qa/2.x https://github.com/artefactual/atom.git atom cd atom export COMPOSE_FILE="$PWD/docker/docker compose.dev.yml" docker compose up -d そして、以下を実行します。 docker compose exec atom php symfony tools:purge --demo これにより、63001ポートでAtoMが起動しました。 その他、マニュアルにはCompile Theme Filesの記述などがありますが、これを実行しなくても起動する場合と起動しない場合がありました。 日本語化 以下にアクセスして、日本語を追加します。 /settings/language そして、以下を実行します。 docker compose exec atom php symfony search:populate 結果、以下のように日本語が追加されました。 まとめ AtoMの利用にあたり、参考になりましたら幸いです。

ArchivesSpaceをDockerで起動する

ArchivesSpaceをDockerで起動する

概要 ArchivesSpaceをDockerで起動する機会がありましたので、備忘録です。 方法 以下に記載されています。 https://docs.archivesspace.org/administration/docker/ 以下のようにcloneした上で、コンテナを起動します。 git clone https://github.com/archivesspace/archivesspace cd archivesspace docker compose up --detach ドキュメントでは、以下のように記載されていますが、Public User interfaceは3001ポート、Staff User Interfaceは3000ポート、およびバックエンドシステムには4567ポートでアクセスできました。 Using the default proxy configuration, the Public User interface becomes available at http://localhost/ and the Staff User Interface at: http://localhost/staff/ (default login with: admin / admin) 翻訳ファイルの更新 Public User interfaceはpublic/config/locales/ja.yml、Staff User Interfaceはfrontend/config/locales/ja.ymlの翻訳ファイルを更新することで、翻訳データを適用することができました。 以下、翻訳ファイルの更新前後の画面比較です。 まとめ ArchivesSpaceの利用にあたり、参考になりましたら幸いです。

mdx.jpのオブジェクトストレージとIIP Image(IIIF Image Server)を使ってIIIF画像を配信する

mdx.jpのオブジェクトストレージとIIP Image(IIIF Image Server)を使ってIIIF画像を配信する

概要 mdx.jpのオブジェクトストレージとIIP Image(IIIF Image Server)を使ってIIIF画像を配信する試行の備忘録です。 以下の記事の続きです。 Docker版IIP Image 以下で、IIPImage serverのDocker Imageが公開されていましたので、こちらを使います。 https://hub.docker.com/r/iipsrv/iipsrv 以下の記事などを参考に、Dockerをインストールします。 https://qiita.com/Marron-chan/items/570c7c7baaae3b4d6b11 実行 前回の記事に倣い、以下のようにmdx.jpのオブジェクトストレージをマウントします。 s3fs satoru196 ~/s3mount -o passwd_file=~/.passwd-s3fs -o url=https://s3ds.mdx.jp -o use_path_request_style -o allow_other 注意点として、前回の記事から、-o allow_otherを追加しています。これを追加しないと、次のコンテナ起動時に以下のエラーが発生しました。 docker: Error response from daemon: error while creating mount source path '~/s3mount/iip/images': mkdir ~/s3mount: file exists Run 'docker run --help' for more information -o allow_otherオプションを追加した上で、以下を実行します。無事に起動しました。 docker run -it -p 9000:9000 -p 8080:80 -v ~/s3mount/iip/images/:/images --rm iipsrv/iipsrv <-----------------------------------> Thu Mar 6 22:35:43 2025 IIPImage Server. Version 1.2 *** Ruven Pillay <ruven@users.sourceforge.net> *** Verbosity level set to 5 Running in standalone mode on socket: 0.0.0.0:9000 with backlog: 2048 Setting maximum image cache size to 10MB Setting filesystem prefix to '/images/' Setting filesystem suffix to '' Setting default JPEG quality to 75 Setting default PNG compression level to 1 Setting default WebP compression level to 50 Setting maximum CVT size to 5000 Setting HTTP Cache-Control header to 'max-age=86400' Setting 3D file sequence name pattern to '_pyr_' Setting default IIIF Image API version to 3 Setting Allow Upscaling to true Setting ICC profile embedding to true Setting up JPEG2000 support via OpenJPEG Setting image processing engine to CPU processor OpenMP enabled for parallelized image processing with 2 threads Setting URI mapping to iiif=>IIIF. Supported protocol: IIIF Memcached support enabled. Connected to servers: 'localhost' with timeout 86400 Initialisation Complete. <-----------------------------------> そして、今回の設定では、オブジェクトストレージの/satoru196/iip/imagesにtiled multi-resolution pyramid TIFFファイルを格納し、以下のようなURLでアクセスできることを確認します。 ...

Alfresco Governance Services Community Editionを起動する

Alfresco Governance Services Community Editionを起動する

概要 以下のマニュアルを参考に、Alfresco Governance Services Community Editionのインストールを試みましたので、備忘録です。 https://support.hyland.com/r/Alfresco/Alfresco-Governance-Services-Community-Edition/23.4/Alfresco-Governance-Services-Community-Edition 参考 同様の取り組みとして、以下があります。こちらも参考にしてください。 https://irisawadojo.blogspot.com/2020/11/72alfresco2.html 仮想マシン 以下のマシンをAzureの仮想マシンとして作成しました。 イメージ: Ubuntu Server 24.04 LTS - Gen2 VM アーキテクチャ: x64 サイズ: Standard D2ads v6 (2 vcpu 数、8 GiB のメモリ) 8080ポートを使用するために、ポートを開けておきます。 Dockerのインストール Dockerをインストールします。 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg # Docker の公式 GPG キーを追加 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo tee /etc/apt/keyrings/docker.asc > /dev/null sudo chmod a+r /etc/apt/keyrings/docker.asc # Docker のリポジトリを追加 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update # Docker をインストール sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # sudo なしで Docker を実行 sudo usermod -aG docker $USER newgrp docker # Docker の動作確認 docker run hello-world インストール 以下の「Install using Docker Compose」を使用します。 ...

Cantaloupe: Microsoft Azure Blob Storageに格納した画像を配信する

Cantaloupe: Microsoft Azure Blob Storageに格納した画像を配信する

概要 IIIFイメージサーバの一つであるCantaloupe Image Serverについて、Microsoft Azure Blob Storageに格納した画像を配信する方法の備忘録です。 以下のMicrosoft Azure Blob Storage版です。 方法 今回はDocker版を使用します。 以下のリポジトリをクローンしてください。 https://github.com/nakamura196/docker_cantaloupe 特に、.env.azure.exampleを.envにリネームして、環境変数を設定します。 # For Microsoft Azure Blob Storage CANTALOUPE_AZURESTORAGESOURCE_ACCOUNT_NAME= CANTALOUPE_AZURESTORAGESOURCE_ACCOUNT_KEY= CANTALOUPE_AZURESTORAGESOURCE_CONTAINER_NAME= # For Traefik CANTALOUPE_HOST= LETS_ENCRYPT_EMAIL= 下の二つは、Traefikを用いたHTTPS化の設定も含めています。 そして、以下を実行します。 docker compose -f docker-compose-azure.yml up まとめ セキュリティの面など、不十分な点もあるかと思いますが、参考になりましたら幸いです。

NDL古典籍OCR-Liteを用いたGradio Appを作成しました。

NDL古典籍OCR-Liteを用いたGradio Appを作成しました。

概要 NDL古典籍OCR-Liteを用いたGradio Appを作成しました。 以下でお試しいただけます。 https://huggingface.co/spaces/nakamura196/ndlkotenocr-lite 「NDL古典籍OCR-Lite」ではデスクトップアプリケーションが提供されているため、Gradioのようなウェブアプリがなくても簡単に実行可能な環境が用意されています。 そのため、本ウェブアプリの用途としては、スマホやタブレット等からの利用や、ウェブAPIを介して利用などが考えられます。 作成時の工夫や不具合対応 サブモジュールの利用 本家のndlkotenocr-liteをサブモジュールとして導入しました。 [submodule "ndlkotenocr-lite"] path = ndlkotenocr-lite url = https://github.com/ndl-lab/ndlkotenocr-lite.git そして、ビルド時に以下を実行します。 #!/bin/bash # サブモジュールを初期化して更新 git submodule update --init --recursive git submodule update --remote これにより、ビルド時に、本家のndlkotenocr-liteの最新ファイルを利用できるかと思います。 (誤った理解をしている点もあるかもしれません。) Dockerfileの利用 上記のサブモジュールの利用にあたり、Dockerfileを使ってビルドする方式にしました。 sdkをdockerにすることで、Dockerfileに基づいてビルドされました。 --- title: NDL Kotenseki OCR-Lite Gradio App emoji: 👀 colorFrom: red colorTo: blue sdk: docker pinned: false --- Check out the configuration reference at https://huggingface.co/docs/hub/spaces-config-reference Gradioのバージョン4.44.1の利用 当初のバージョン5.7.1のGradioを使用していましたが、後述するAPI利用の際、以下のエラーが出て利用できませんでした。 ValueError: Could not fetch api info for https://nakamura196-ndlkotenocr-lite.hf.space/: {"detail":"Not Found"} そこで、バージョン4.44.1を使用することで、このエラーを回避することができました。 ...

Docker + Traefikで運用するDrupalのリバースプロキシ設定

Docker + Traefikで運用するDrupalのリバースプロキシ設定

概要 以下の記事で紹介したDocker + Traefikを用いて、HTTPS化したDrupalを運用していました。 この時、Drupalのデフォルト設定の場合、以下のように、httpのURLが設定されていました。 この問題として、以下の記事になるように、例えばGoogleアカウントでログインするようにした際、リダイレクトURLがhttpから始まるURLとなり、Google Cloud コンソールにはhttpsから始まるURLを入力する必要があり、この齟齬によって、認証ができないケースなどがありました。 https://drupalfan.com/【drupal】googleアカウントでログインできるようにする/ 本記事では、この問題に対処するための方法についてメモします。 方法 以下の記事が参考になりました。 https://www.58bits.com/blog/canonical-urls-https-and-drupal-89-reverse-proxy-settings 以下の3行を追加することで、Drupalの内部的にもhttpsから始まるURLに設定されました。 ... $settings['reverse_proxy'] = TRUE; $settings['reverse_proxy_addresses'] = array($_SERVER['REMOTE_ADDR']); $settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_FOR | \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_PROTO | \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_PORT; ... まとめ 考慮不足の点があるかもしれませんが、参考になりましたら幸いです。

TraefikでHTTPS化した複数コンテナを運用する

TraefikでHTTPS化した複数コンテナを運用する

概要 TraefikでHTTPS化した複数コンテナを運用する方法に関する備忘録です。 https://github.com/traefik/traefik 背景 これまで、jwilder/nginx-proxyとjrcs/letsencrypt-nginx-proxy-companionを使い、以下のような構成で運用していました。 プロキシ version: '3' # proxy services: nginx-proxy: image: jwilder/nginx-proxy container_name: nginx-proxy ports: - "80:80" - "443:443" volumes: - html:/usr/share/nginx/html - dhparam:/etc/nginx/dhparam - vhost:/etc/nginx/vhost.d - certs:/etc/nginx/certs:ro - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/docker/nginx-proxy-with-encrypt/log:/var/log/nginx labels: - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy" restart: always letsencrypt: image: jrcs/letsencrypt-nginx-proxy-companion container_name: nginx-proxy-lets-encrypt depends_on: - "nginx-proxy" volumes: - certs:/etc/nginx/certs:rw - vhost:/etc/nginx/vhost.d - html:/usr/share/nginx/html - /var/run/docker.sock:/var/run/docker.sock:ro volumes: certs: html: vhost: dhparam: networks: default: external: name: common_link コンテナ 以下は、Djangoの例です。 ...

Docker版のOmeka SでCORS対応を行う

Docker版のOmeka SでCORS対応を行う

概要 Docker版のOmeka Sで、以下の記事のようにCORS対応を実施した際、サーバエラーが発生しました。その備忘録を記載します。 Dockerfile 以下のようなDockerfileを対象とします。 FROM php:apache LABEL maintainer="Satoru Nakamura <na.kamura.1263@gmail.com>" RUN a2enmod rewrite ENV DEBIAN_FRONTEND noninteractive RUN apt-get -qq update && apt-get -qq -y upgrade RUN apt-get install -y \ zlib1g-dev \ libpng-dev \ libjpeg-dev \ libfreetype6-dev \ imagemagick \ unzip \ wget # PHP extensions RUN docker-php-ext-install -j$(nproc) iconv pdo pdo_mysql mysqli gd RUN docker-php-ext-configure gd --with-jpeg=/usr/include/ --with-freetype=/usr/include/ # Download Omeka-s ARG version=4.1.1 RUN wget https://github.com/omeka/omeka-s/releases/download/v${version}/omeka-s-${version}.zip -O /var/www/omeka-s-${version}.zip \ && unzip -q /var/www/omeka-s-${version}.zip -d /var/www/ \ && rm /var/www/omeka-s-${version}.zip \ && rm -rf /var/www/html/ \ && mv /var/www/omeka-s/ /var/www/html/ COPY ./.htaccess /var/www/html/.htaccess # Configure volumes and permissions COPY ./database.ini /var/www/html/volume/config/ RUN mkdir -p /var/www/html/volume/files/ \ && rm /var/www/html/config/database.ini \ && ln -s /var/www/html/volume/config/database.ini /var/www/html/config/database.ini \ && rm -Rf /var/www/html/files/ \ && ln -s /var/www/html/volume/files/ /var/www/html/files \ && chown -R www-data:www-data /var/www/html/ \ && find /var/www/html/volume/ -type f -exec chmod 600 {} \; VOLUME /var/www/html/volume/ CMD ["apache2-foreground"] 原因と対策 以下を追記する必要がありました。 ...

docker-compose コマンドでコンテナを再起動すると同時にビルドも行う

docker-compose コマンドでコンテナを再起動すると同時にビルドも行う

docker-compose コマンドでコンテナを再起動すると同時にビルドもしたい場合、以下のようなコマンドを実行できます。まず、ビルドと再起動を個別に実行する方法と、それを一つのコマンドで実行する方法を示します。 ビルドと再起動を個別に実行 ビルド : docker-compose -f ./docker-compose.prod.yml build 再起動 : docker-compose -f ./docker-compose.prod.yml restart 一つのコマンドでビルドと再起動を実行 ビルドしてからサービスを再起動するには、up コマンドを使い、--build オプションを付けてから restart ポリシーを使います。しかし、restart オプションは up コマンドには存在しないので、実際にはサービスを停止して再起動することになります。 docker-compose -f ./docker-compose.prod.yml up --build -d このコマンドはサービスをビルドした後、デタッチドモードで実行します。これにより、コンテナが更新されてからバックグラウンドで自動的に再起動します。ただし、これによる完全な再起動を保証するためには、各サービスの設定で適切な再起動ポリシーが設定されている必要があります。 どちらの方法でも目的を達成できますが、作業の流れに合わせて選択してください。

nginx-proxyでの 413 Request Entity Too Large エラーの対処法

nginx-proxyでの 413 Request Entity Too Large エラーの対処法

概要 EC2上にDockerをインストールし、nginx-proxyとnginx-proxy-lets-encryptを利用してSSL化を行いました。 上記の設定で問題なく使用できていましたが、比較的大きなサイズのファイルをPOSTするアプリを作成した際、以下のエラーが発生してアップロードできませんでした。 nginx-proxy 413 (Payload Too Large) Nginxのclient_max_body_sizeを上げる必要がありました。 方法 ChatGPT4に教えていただいた以下の対応により、解決することができました。 413 Request Entity Too Large エラーは、クライアントがサーバーに送信しようとしているリクエストのペイロード(つまり、アップロードするファイルのサイズなど)がサーバーで設定された制限を超えている場合に発生します。このエラーを解決するためには、Nginx の設定でクライアントリクエストの最大サイズを増やす必要があります。 nginx-proxy コンテナでこの設定を調整するには、client_max_body_size ディレクティブの値を増やすことで、受け入れ可能なリクエストサイズの上限を上げることができます。しかし、jwilder/nginx-proxy イメージを使用している場合、直接 Nginx の設定ファイルを編集するのではなく、カスタム設定を適用する方法が推奨されます。 以下は、client_max_body_size を増やすために必要な手順です。 カスタム設定ファイルを作成する: ローカルに client_max_body_size ディレクティブを含むカスタム Nginx 設定ファイルを作成します。例えば、この設定を 100M (100メガバイト)に設定したい場合、次の内容を含むファイルを作成します。 my_custom_proxy_settings.conf: client_max_body_size 100M; カスタム設定ファイルを Docker コンテナにマウントする: nginx-proxy サービスの定義に、このカスタム設定ファイルを /etc/nginx/conf.d ディレクトリにマウントする設定を追加します。これにより、Nginx が起動する際にこの設定が適用されます。 修正された docker-compose.yml の例: services: nginx-proxy: image: jwilder/nginx-proxy container_name: nginx-proxy ports: - "80:80" - "443:443" volumes: - html:/usr/share/nginx/html - dhparam:/etc/nginx/dhparam - vhost:/etc/nginx/vhost.d - certs:/etc/nginx/certs:ro - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/docker/nginx-proxy-with-encrypt/log:/var/log/nginx - ./my_custom_proxy_settings.conf:/etc/nginx/conf.d/my_custom_proxy_settings.conf:ro # この行を追加 labels: - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy" restart: always Docker コンテナを再起動する: 変更を適用するために、docker-compose を使って nginx-proxy コンテナを再起動します。 ...